Quand on pense à un workflow d’agents IA, la plupart imaginent un agent, une longue tâche et une attente du résultat. Cela marche pour les petits travaux. Sur quelque chose de gros, comme « migrer les paiements vers un nouveau prestataire », un seul agent cherche, planifie et implémente tout à la fois : le contexte gonfle, vous ne voyez jamais de plan, et les erreurs n’apparaissent qu’une fois le code écrit.
Cet article montre trois façons dont AgentVera répartit ce travail entre plusieurs agents : une équipe avec un manager et des rôles, une équipe parallèle qui exécute des parties indépendantes en même temps, et des flows qui transmettent la sortie d’un agent au suivant.
Pourquoi répartir un workflow d’agents IA ?
Les problèmes d’une session à un seul agent :
- Le contexte grossit. Chaque fichier lu pendant la recherche reste dans le contexte pendant l’implémentation.
- Le plan est invisible. L’agent décide quoi faire et passe directement au code.
- Les erreurs arrivent tard. Une mauvaise hypothèse n’apparaît que lorsque les tests échouent.
Plusieurs agents aux missions claires règlent cela. Un chercheur n’écrit pas de code, un planificateur n’écrit que le plan, un développeur l’implémente et un relecteur le vérifie. Chacun travaille avec son propre petit contexte.
Option 1 : une équipe avec un manager et des rôles
La vue d’équipe transforme les agents ouverts dans votre espace de travail en équipe. Dans la fenêtre Team structure, vous les placez sur un organigramme : l’un devient le manager, les autres reçoivent un rôle, des instructions, quelqu’un à qui ils rendent compte et quelqu’un à qui ils passent leur travail. Une équipe compte jusqu’à 24 agents.
Inutile de la construire de zéro. Les rôles prêts à l’emploi remplissent un chercheur, un planificateur, un développeur, un relecteur, un testeur et plus encore ; les équipes prêtes à l’emploi, comme la software team (tech lead, planificateur, développeur, relecteur et testeur), ouvrent pour vous les agents nécessaires. L’équipe et chaque rôle peuvent porter leurs propres serveurs MCP : le testeur démarre donc avec Playwright sans que vous le configuriez agent par agent.
Rien ne démarre une fois l’équipe construite. Vous saisissez le travail dans la zone en dessous et choisissez Give to the team. Il va au manager, qui le découpe, le distribue et vérifie les résultats. Les agents s’organisent via le chat entre agents et une liste de tâches partagée.
Pendant l’exécution, la vue d’équipe montre qui travaille sur quoi, les messages qui circulent entre agents et l’état de chaque tâche. Les demandes d’autorisation arrivent dans la barre d’attention au-dessus du schéma, où vous les approuvez ou les refusez sur place. Status report demande au manager un court résumé ; Interrupt all arrête tout le monde.
Cela convient au travail où les agents doivent se parler : un planificateur qui pose une question de suivi au chercheur, un relecteur qui renvoie une modification au développeur.
Option 2 : une équipe parallèle qui finit en une PR
Certains travaux se découpent en parties indépendantes : l’API, l’interface et la migration d’une nouvelle fonctionnalité, par exemple. Une équipe parallèle les exécute en même temps.
Un agent lance lui-même l’équipe quand un gros changement se découpe ainsi. Il rédige les parties, ou ne donne que l’objectif et laisse Claude Sonnet lire le dépôt et les planifier. Ensuite :
- Chaque partie va à son propre agent dans son propre worktree et sa propre branche : les agents ne touchent jamais aux fichiers des autres. Par défaut 3 tournent en même temps, 6 au maximum.
- Un agent termine par le marqueur
[[TESLİM]]quand il a fini, ou[[YARDIM]]quand il est bloqué. Une partie bloquée vous attend : acceptez ce qu’elle a fait, laissez-la continuer ou ignorez-la. - Les parties terminées fusionnent dans une branche d’intégration, et la commande de test du projet s’exécute comme vérification finale. Si une fusion entre en conflit ou si la vérification échoue, un agent d’intégration intervient.
- Vous ouvrez une pull request, ou mettez la branche dans la file de fusion.
Cela convient aux gros changements dont les parties n’ont pas besoin de se parler, seulement de s’emboîter à la fin.
Option 3 : des flows qui se passent le relais
Quand vous voulez une chaîne fixe, construisez-la dans les flows. La séquence classique recherche, plan, construction ressemble à ceci :
| Étape | Agent | Ce qu’il reçoit | Règle |
|---|---|---|---|
| Recherche | Chercheur | L’objectif | Pas de code ; rapporter l’état actuel et les options |
| Plan | Planificateur | La dernière réponse du chercheur | Objectif, hors périmètre, fichiers, étapes, stratégie de test, critères d’acceptation |
| Validation | Vous | Le plan | Nœud Human approval |
| Construction | Builder | Le plan approuvé | Implémenter le plan, lancer les tests |
Quand un agent termine son tour, sa dernière réponse est insérée dans le modèle de message de la connexion ({{output}}) et envoyée à l’agent suivant. Si le suivant est occupé, le flow attend la fin de son tour. Les nœuds qui sécurisent la chaîne :
- Condition : ne passer à la suite que si la réponse contient une expression ou correspond à une regex, pour qu’une question posée en cours de route ne déclenche pas l’étape suivante.
- Transform : n’envoyer que le dernier bloc de code ou les N premières lignes.
- Human approval : s’arrêter jusqu’à votre validation, depuis l’app ou depuis Telegram.
- Wait et Notify : laisser du temps entre les étapes et être prévenu des plus importantes.
- Turn limit : mettre en pause une connexion qui boucle.
L’étape de validation compte le plus
Quelle que soit l’option choisie, lire le plan avant l’écriture du code est le moment le plus précieux. Un mauvais plan se corrige en cinq minutes à ce stade, et en plusieurs heures une fois le code écrit. Les problèmes les plus souvent repérés :
- Un module qui devrait rester hors périmètre et qui se glisse dans le plan.
- Des tests existants absents de la stratégie de test.
- L’ordre des étapes, par exemple l’interface d’abord, puis l’implémentation.
Dans une équipe, demandez au manager de vous envoyer le plan avant de distribuer le travail. Dans un flow, placez un nœud Human approval avant le builder.
Comment rédiger un bon objectif
La première entrée est l’objectif que vous écrivez. Un bon objectif :
- Décrit le résultat : « Migrer le prestataire de paiement de X vers Y sans changer le contrat d’API actuel. »
- Fixe les limites : « Ne touche pas au module de facturation. »
- Définit le succès : « Les tests de paiement existants doivent passer, et ajoute un test d’intégration pour le nouveau prestataire. »
Un objectif comme « améliorer les paiements » pousse chaque agent à lire toute la base de code.
Lequel choisir ?
- Un seul agent : un correctif d’un fichier, une coquille ou un petit changement de style. Le découper prend plus de temps que le travail.
- Vue d’équipe : un travail continu où des agents de rôles différents doivent se parler, se poser des questions et se relire.
- Équipe parallèle : un gros changement aux parties indépendantes qui doit finir en une branche et une PR.
- Flows : une séquence fixe que vous relancez encore et encore, avec des validations et des conditions entre les étapes.
Lancer de longs travaux en votre absence
Inutile de rester devant l’ordinateur pendant un long travail :
- Notifications Telegram : validez une étape de flow depuis votre téléphone, et répondez à une notification pour envoyer du texte à cet agent.
- App mobile AgentVera : suivez le chat, le terminal et le diff de chaque agent sur iOS ou Android et répondez à ses demandes d’autorisation.
- Tâches planifiées : envoyez un message à un agent selon un planning cron, par exemple pour lancer la veille sur les dépendances chaque matin.
- Empêcher la mise en veille : le réglage qui garde l’ordinateur éveillé pendant que les agents travaillent évite que les travaux de nuit ne calent.
Checklist
- L’objectif décrit-il le résultat et les limites en un paragraphe ?
- Chaque agent a-t-il une mission claire ?
- Verrez-vous le plan avant l’écriture du code ?
- Les tests tourneront-ils avant que le travail soit déclaré terminé ?
- Serez-vous prévenu à la fin ?
Pour conclure
Répartir un workflow d’agents IA entre plusieurs agents les rend plus prévisibles sur les gros travaux : chaque contexte reste réduit, le plan est visible et les erreurs apparaissent tôt. AgentVera vous offre trois façons de le faire, d’une équipe en direct à un run parallèle qui finit en une PR.
Démarrez avec l’offre gratuite, et consultez notifications et validations pour gérer les validations à distance.