La plupart des flux multi-agents n’échouent pas sur la partie la plus difficile. L’agent écrit le code, exécute les tests, ouvre la pull request. C’est au niveau des jointures que tout déraille : à cet instant précis où le travail quitte un agent pour passer au suivant. Un agent backend finalise un endpoint, mais l’agent frontend n’est jamais informé qu’il est prêt. Un refactoring atterrit dans un worktree et y reste indéfiniment au vert, simplement parce qu’aucun humain n’a été prévenu d’y jeter un œil. Ce n’est pas la tâche qui a échoué. C’est la transition.
Dans le monde des agents IA, la transition (ou handoff) désigne le transfert d’une tâche et de son contexte d’un intervenant à un autre : d’agent à agent, ou d’agent à humain. Lorsque vous faites tourner un unique agent de développement dans un terminal, ces passages de relais sont invisibles, car ils n’existent tout simplement pas. Dès que vous lancez deux agents, ou un agent et un relecteur humain, chaque étape accomplie doit atterrir à un endroit où le prochain intervenant pourra la trouver. Et cet espace d’atterrissage fait toute la différence.
Cet article présente les modèles de transition qui fonctionnent réellement en production, en s’appuyant sur Sharkly comme moteur de workflow : la couche qui chapeaute vos agents de code et maintient une visibilité totale sur le contexte, l’avancement, les blocages, les résultats et la revue humaine, de la demande initiale jusqu’au déploiement. Vos agents de développement sont déjà en place. Ce guide résout ce qui se passe dans les interstices entre chacun d’eux.
L’essentiel en résumé
Une transition correspond au moment où le travail et son contexte passent d’un intervenant au suivant. Les passages d’agent à agent transmettent une sous-tâche terminée à l’agent suivant ; les transitions d’agent à humain interrompent le travail autonome au niveau d’un point de validation. Rendez ces deux types de transferts explicites grâce aux statuts : les agents passent une tâche à « Prêt pour révision » (Ready for review), les humains la passent à « Terminé » (Done). Lorsque la transition repose sur un changement d’état dans une tâche partagée plutôt que sur un simple message dans un terminal, rien ne passe à la trappe.
Qu’est-ce qu’une transition d’agent au juste ?
Une transition réussie repose sur trois composantes indispensables. Oubliez-en une seule, et le travail disparaît dans la nature : l’artéfact (le diff, la PR, la migration), le contexte (ce qui a été demandé, ce qui a changé, les incertitudes restantes) et le destinataire (l’agent ou l’humain précis qui prend le relais).
Les workflows cantonnés au terminal conservent l’artéfact, mais perdent les deux autres volets. Le commit est bien là, mais le raisonnement reste enfoui dans l’historique d’un terminal qu’un seul agent a vu, et la question du « qui prend la suite » dépend de celui qui pensera à aller vérifier. C’est pour cette raison qu’orchestrer des agents consiste moins à les lancer qu’à acheminer intelligemment ce qu’ils produisent.
Une transition fluide transmet ces trois éléments de concert : les modifications apportées, la synthèse de ce qui a été fait et de ce qui reste à faire, ainsi qu’un signal clair indiquant que c’est au destinataire de prendre la main. Dans l’écosystème Sharkly, l’exécution, les blocages, les résultats et les échanges de suivi sont directement réintégrés dans la chronologie de la tâche. Ainsi, l’intervenant suivant n’a qu’un seul historique à consulter au lieu d’avoir à en reconstituer trois.
Deux modèles de transition
Ces deux modèles semblent proches en apparence, mais obéissent à des logiques par défaut diamétralement opposées. Une transition d’agent à agent doit s’effectuer de manière fluide et automatique : l’agent suivant prend en charge une sous-tâche prête et poursuit l’effort. À l’inverse, une transition d’agent à humain doit marquer un arrêt par défaut : l’agent finalise son périmètre et attend, car une décision humaine est requise.
| Agent à agent | Agent à humain | |
|---|---|---|
| Déclencheur | Une sous-tâche est marquée comme prête | Le travail atteint un point de validation |
| Comportement par défaut | Poursuite automatique | Arrêt et mise en attente |
| Éléments transmis | Artéfact + contexte + critères d'acceptation | Diff + résumé des changements + limites connues |
| Risque en cas d'oubli | Travail en doublon ou conflits | Code fusionné à l'aveugle sans relecture |
Voici la grille de décision pour faire les bons choix : automatisez la transition d’agent à agent dès lors que l’étape suivante est clairement cadrée et que ses critères d’acceptation sont déjà rédigés (« exécuter la suite de tests », « générer la migration », « mettre à jour la spécification OpenAPI »). En revanche, imposez un passage de relais vers un humain lorsque l’étape suivante exige un jugement qu’un agent ne peut pas assumer : fusionner sur main, modifier un contrat d’API public, toucher à l’authentification ou à la facturation, ou valider définitivement un résultat.
L’erreur classique consiste à traiter toutes les transitions de la même manière. Automatisez tout, et vous fusionnerez du code non relu ; imposez une validation humaine à chaque étape, et vous vous retrouverez avec un pipeline manuel interminable alourdi d’étapes superflues. Tout l’enjeu est donc de savoir où placer les points de contrôle pour arrêter les agents avant les erreurs critiques, sans les bloquer pour chaque modification anodine.
Les statuts : transformer la transition en garde-fou concret
Le modèle opérationnel repose sur quatre actions et leurs responsables respectifs : qui assigne, qui exécute, qui révise, qui valide. Les agents explorent, exécutent, testent et rendent compte. Les humains donnent la direction, accordent les autorisations et valident le résultat. L’automatisation s’arrête là où le discernement de l’équipe devient indispensable.
Les statuts permettent de concrétiser ce principe dans les faits plutôt que d’en faire un simple vœu pieux. Chaque tâche suit le même parcours :
- À faire (Todo) : assignée, non démarrée. Placée ici par un humain ou par un agent coordinateur.
- En cours (In progress) : prise en charge par un agent qui travaille dans un worktree isolé.
- Prêt pour révision (Ready for review) : la limite de l’agent. Il a exécuté les vérifications de types, les tests et le build, joint le récapitulatif des modifications ainsi que les limites identifiées, puis s’est arrêté.
- Terminé (Done) : le périmètre de l’humain. Quelqu’un a validé le travail et pris la décision de le fusionner et de le publier.
La règle d’or qui rend l’ensemble limpide est la suivante : les agents passent une tâche à « Prêt pour révision » ; les humains la passent à « Terminé ». Un agent ne valide jamais son propre travail, et un humain n’a jamais à deviner si une tâche au vert peut être intégrée sans risque. Le statut incarne la transition. Quand dix agents tournent en parallèle, vous n’avez pas besoin d’éplucher dix terminaux : vous regardez le tableau de bord et identifiez immédiatement ce qui attend votre validation, ce qui dépend d’un autre agent et ce qui est en cours de traitement. Cette visibilité fait toute la différence entre suivre avec précision le travail accompli par les agents d’IA et espérer que l’historique des commits permettra de comprendre la situation a posteriori.
Exemple concret : du ticket à la PR fusionnée
Prenons une tâche représentative de la réalité, SH-312 : « Ajouter une limitation de débit (rate limiting) sur l’API publique. » Observons le cheminement des transitions plutôt que le code lui-même.
Un humain décrit le besoin en langage naturel et assigne la tâche. Un agent coordinateur analyse la base de code et les tâches antérieures, rédige le périmètre ainsi que les critères d’acceptation (limite par clé d’API, renvoi d’un code 429 avec en-tête Retry-After, couverture des trois endpoints les plus sollicités), puis découpe SH-312 en trois sous-tâches exécutables. C’est la première transition d’agent à agent : l’objectif entre, des sous-tâches prêtes à l’emploi ressortent.
Les sous-tâches s’enchaînent automatiquement. Un agent backend s’occupe de la logique de limitation ; un agent de test prend en charge la couverture de test. Comme chacun évolue dans un worktree isolé, aucun conflit de fichiers ne survient, et chaque résultat est rattaché directement à SH-312 plutôt que de rester confiné dans une session privée. Lorsque l’agent backend termine, il ne sollicite pas d’humain : il marque sa sous-tâche comme prête, et l’agent de test enchaîne en s’appuyant sur l’implémentation réelle plutôt que sur un bouchon.
C’est alors que la dynamique change. Le limiteur de débit étant développé, le typage validé, les tests au vert et le build réussi, la tâche atteint le point de contrôle humain. L’agent fait passer SH-312 à « Prêt pour révision » en joignant le diff, un récapitulatif des changements et une limite identifiée : « Le compteur adossé à Redis suppose une région unique ; le multi-région nécessitera un traitement ultérieur. » Un humain consulte ces informations au même endroit, vérifie le comportement du code 429 et passe la tâche à « Terminé », déclenchant ainsi le merge. Du ticket à la PR fusionnée, avec un historique détaillé de chaque intervention à chaque étape charnière. C’est exactement ainsi que l’on rend le parcours des exigences jusqu’au code parfaitement traçable de bout en bout.
Où les transitions échouent (et comment les fiabiliser)
Les transitions échouent généralement de trois manières prévisibles. Chacune appelle une réponse structurelle plutôt qu’un simple rappel de bonnes intentions.
Le contexte s’évapore. L’agent savait pourquoi il a fait tel choix d’implémentation ; le relecteur l’ignore. La solution : intégrer systématiquement le résumé des changements et les limites connues lors du passage au statut « Prêt pour révision », et non comme une réflexion après coup. L’attribution devient floue. Deux agents s’emparent de la même tâche, ou au contraire personne ne s’en charge. La solution : un responsable désigné (Assignee) sur chaque tâche et sous-tâche, pour que le passage de relais soit explicite dans un champ dédié plutôt qu’implicite. La revue n’a jamais lieu. Du code produit de façon autonome est fusionné en production parce que personne n’a reçu la consigne de le vérifier. La solution : instaurer un statut que l’agent ne peut pas franchir de lui-même.
Il est possible de mettre en place cette rigueur à la main à grands renforts de worktrees, de conventions de nommage et d’autodiscipline. Cette approche fonctionne jusqu’à ce que le volume d’agents, de tâches et de dépôts augmente, moment où la discipline est la première à voler en éclats. Si vous utilisez déjà plusieurs agents, Sharkly centralise la gestion de leurs tâches et de leurs résultats : des tâches partagées, des responsables attitrés par tâche, des worktrees isolés et un cycle de statut où les agents atteignent « Prêt pour révision » et où les humains décident du « Terminé ». Conservez les agents de développement auxquels vous êtes habitué ; ajoutez simplement la couche qui rend leurs transitions visibles. Téléchargez Sharkly dès lors que les frictions entre vos agents commencent à coûter plus cher que le travail qu’ils accomplissent.
FAQ
Qu’est-ce qu’une transition (handoff) d’agent IA ? C’est le transfert d’une tâche, de son contexte et du signal indiquant que le relais passe à un autre intervenant. Elle prend deux formes : d’agent à agent (une sous-tâche terminée est transmise à l’agent suivant) et d’agent à humain (le travail autonome s’arrête au niveau d’un point de validation).
Quelle est la différence entre une transition agent-à-agent et agent-à-humain ? Les transitions d’agent à agent doivent se poursuivre de façon automatique dès lors que les critères d’acceptation de l’étape suivante sont déjà formalisés. Les transitions d’agent à humain doivent marquer un temps d’arrêt, car une décision humaine est requise : fusion de code, modification d’un contrat d’API public ou validation d’un résultat.
Les agents doivent-ils pouvoir marquer leur propre travail comme terminé ? Non. Laissez les agents passer une tâche à « Prêt pour révision » après avoir exécuté les tests et joint une synthèse ; réservez le passage à « Terminé » et la décision de merge à un humain. Découper ces deux frontières est ce qui empêche du code non relu de partir en production. Consultez notre article sur les agents de développement avec intervention humaine (human-in-the-loop).
En quoi les statuts évitent-ils les oublis et les pertes de tâches ? Lorsque la transition correspond à un changement de statut sur une tâche partagée plutôt qu’à un simple message dans un terminal, l’intervenant suivant voit exactement ce qui attend son intervention. Plus rien ne repose sur la consultation opportune du bon historique au bon moment. Une boîte de réception pour agents fait remonter directement les éléments qui nécessitent votre attention.
Faut-il un outil dédié ou peut-on gérer cela manuellement ? Vous pouvez débuter avec des worktrees et un tableau de suivi partagé. En revanche, un outil spécialisé devient indispensable dès lors que vous coordonnez plusieurs agents sur plusieurs dépôts et que le suivi manuel devient un goulot d’étranglement. Pour vous orienter, comparez le modèle mental des assistants IA par rapport aux coéquipiers IA.
