Skip to main content
Retour au blog
Blog

De l'agent unique au multi-agent : guide pratique de migration

La plupart des développeurs commencent avec un seul agent IA. Voici comment passer à plusieurs agents travaillant en parallèle, et pourquoi cela change tout.

La plupart des développeurs qui utilisent aujourd'hui des outils de codage IA font tourner un seul agent à la fois. Vous ouvrez Claude Code, lui donnez une tâche, vous attendez qu'il termine, puis vous lui donnez la suivante. Cela fonctionne. Mais c'est séquentiel.

Dès que vous lancez deux agents en parallèle, quelque chose change. Vous cessez d'être un simple dactylo qui attend une sortie. Vous devenez un orchestrateur : vous répartissez le travail, vous faites circuler les résultats et vous concentrez votre attention là où elle compte vraiment.

Cet article explique les étapes pratiques pour passer d'un développement avec un seul agent à un développement multi-agent, ainsi que le changement de modèle mental qui le rend productif.

Le goulot d'étranglement de l'agent unique

Un seul agent IA, aussi capable soit-il, a une contrainte fondamentale : il ne peut faire qu'une chose à la fois. Quand Claude Code refactorise votre module d'auth, il ne peut pas simultanément écrire des tests pour votre couche API. Vous attendez.

Le calcul est simple. Si chaque tâche prend 5 minutes de travail agentique et que vous avez 10 tâches, un seul agent prend 50 minutes. Deux agents ramènent cela à 25. Mais le vrai gain n'est pas seulement le temps horloge — c'est la boucle de rétroaction.

Avec deux agents travaillant sur du code lié, la sortie de refactorisation de l'Agent A peut alimenter immédiatement le processus de revue de l'Agent B. Les problèmes apparaissent plus vite. Le contexte est plus frais. Vous détectez les problèmes d'intégration en quelques minutes au lieu de plusieurs heures.

Étape 1 : identifier le travail parallélisable

Toutes les tâches ne tirent pas profit de la parallélisation. Les meilleurs candidats sont :

  • Modules indépendants — Refactoriser l'auth pendant qu'on construit un nouveau point de terminaison API.
  • Étapes séquentielles — Un agent écrit le code, un autre le relit.
  • Perspectives complémentaires — Un agent se concentre sur l'implémentation, un autre sur les tests.

Les pires candidats sont les tâches fortement couplées : deux agents qui modifient le même fichier créent des conflits de fusion.

Une bonne règle empirique : si vous confieriez les tâches à deux développeurs différents, elles peuvent tourner sur deux agents différents.

Étape 2 : organisation spatiale

Les workflows par onglets s'effondrent avec plusieurs agents. Vous ne pouvez pas scanner trois onglets de terminal en même temps : ils se chevauchent, vous perdez le contexte, vous oubliez quel onglet fait quoi.

C'est là que la disposition spatiale compte. Sur un canevas, vous placez les agents là où vous pouvez les voir. Terminal A à gauche, Terminal B à droite, un tile de note au milieu pour suivre le plan. D'un coup d'œil, vous connaissez l'état de tout.

Le modèle spatial n'est pas seulement esthétique. Il est cognitif. Les recherches sur la cognition externe montrent que l'organisation physique de l'information réduit la charge de la mémoire de travail. Le canevas devient une extension de votre modèle mental.

Étape 3 : définir le flux d'information

Avec plusieurs agents, vous avez besoin d'un plan pour la circulation des informations. Trois motifs sont courants :

Pipeline

Agent A → Agent B → Agent C

La sortie de chaque agent alimente le suivant. Exemple : A écrit le code → B relit → C écrit les tests.

Fan-out / Fan-in

        → Agent B →
Agent A                 Agent D
        → Agent C →

Un agent répartit le travail, plusieurs agents exécutent en parallèle, puis les résultats convergent. Exemple : A découpe une tâche en sous-tâches → B et C traitent chacun une sous-tâche → D intègre les résultats.

Boucle de revue

Agent A ⇄ Agent B

Deux agents itèrent sur le même travail. A écrit, B relit, A révise. Cela converge plus vite qu'on ne l'imagine — généralement en 2 à 3 tours.

Étape 4 : automatiser la passation

La plus grande friction du travail multi-agent, c'est la passation. Copier manuellement la sortie de l'Agent A, la reformater en prompt et la coller dans l'Agent B est fastidieux et source d'erreurs.

Le routage automatisé supprime cette friction. Quand l'Agent A termine, le système :

  1. Détecte la complétion (via des motifs de sortie ou la détection d'inactivité).
  2. Extrait la sortie pertinente.
  3. La transforme en prompt adapté à l'Agent B.
  4. La livre.

L'étape de transformation est critique. La sortie brute du terminal est bruyante — codes ANSI, barres de progression, journaux verbeux. Un bon système de routage extrait le contenu sémantique et le reformule comme une instruction exploitable.

Étape 5 : surveiller et intervenir

Le travail multi-agent demande un autre rythme d'attention. Au lieu de vous concentrer en profondeur sur la sortie d'un seul agent, vous balayez plusieurs agents à la recherche de :

  • Agents bloqués — En attente d'autorisation ou d'entrée.
  • Agents terminés — Prêts pour la tâche suivante ou la passation.
  • Agents qui divergent — Qui partent dans la mauvaise direction.

Les indicateurs visuels aident énormément. Des indicateurs d'état codés par couleur (travail, attente, arrêté) permettent de trier l'attention d'un coup d'œil. Des animations pulsantes attirent votre regard vers les agents actifs. Une lueur au bord de l'écran vous alerte d'une activité hors du canevas.

L'objectif est de réduire la surcharge cognitive de la supervision afin que vous puissiez vous concentrer sur les décisions créatives : quoi construire, comment l'architecturer, où investir votre attention.

Le changement de modèle mental

Le changement le plus profond dans le travail multi-agent n'est pas technique. C'est la façon dont vous envisagez votre rôle.

Avec un seul agent, vous êtes en pair programming. Vous et l'agent partagez le focus sur une seule chose à la fois.

Avec plusieurs agents, vous êtes lead technique. Vous donnez la direction, répartissez le travail, relisez les résultats et prenez les décisions d'architecture. Les agents gèrent l'exécution.

Ce changement est inconfortable au début. Vous avez l'impression de devoir surveiller chaque ligne de sortie de chaque agent. Mais cela ne passe pas à l'échelle. À la place, vous apprenez à faire confiance au processus, à intervenir au besoin et à vous concentrer sur les décisions qui requièrent réellement votre jugement.

Pour commencer

Si vous faites aujourd'hui tourner un seul agent, essayez ceci :

  1. Ouvrez un deuxième terminal avec le même agent mais sur une tâche différente.
  2. Disposez-les côte à côte pour pouvoir voir les deux.
  3. Quand le premier termine, envoyez manuellement ses principales conclusions au second.
  4. Remarquez à quel point la seconde tâche avance plus vite avec ce contexte.

C'est le développement multi-agent dans sa forme la plus simple. Tout le reste — routage automatisé, organisation sur canevas, détection d'état — n'est que l'infrastructure qui rend ce schéma de base sans effort.