5 motifs multi-agents qui fonctionnent vraiment

Après des mois à construire et utiliser des workflows de développement multi-agents, certains patterns continuent de faire leurs preuves. Ce ne sont pas des théories : ce sont des patterns que nous utilisons au quotidien et que d'autres développeurs adoptent de façon fiable.

En voici cinq qui fonctionnent réellement en pratique.

1. Le pipeline de revue de code

Configuration : deux tiles de terminal, reliés dans un seul sens.

Agent rédacteur → Agent relecteur

Fonctionnement : l'agent rédacteur implémente une fonctionnalité ou un correctif. Quand il termine, la sortie est routée vers l'agent relecteur avec un prompt du type "Relis les changements dans src/auth/ pour la correction, les problèmes de sécurité et les cas limites."

Pourquoi cela fonctionne : les agents IA détectent des choses différentes selon le contexte du prompt. Un agent rédacteur optimise la correction et l'achèvement. Un agent relecteur, avec des critères de revue explicites, attrape les problèmes que la vision tunnel du rédacteur a laissés passer.

Conseil : utilisez le déclencheur on-idle avec une fenêtre de silence de 8 secondes. Cela garantit que le rédacteur a vraiment fini avant le début de la revue. Ajoutez un mot-clé d'arrêt comme "LGTM" pour que la boucle se termine lorsque le relecteur approuve.

Cycle typique : 1 passe d'écriture + 1 à 2 tours de revue. Pour un changement ciblé, la convergence prend généralement moins de 10 minutes.

2. Le générateur de tests

Configuration : un agent d'implémentation, un agent de rédaction de tests.

Agent d'implémentation → Agent de tests

Fonctionnement : l'agent d'implémentation construit ou modifie une fonctionnalité. À la fin, le système de routage envoie les changements de fichiers et un prompt à l'agent de tests : "Écris des tests unitaires pour les changements apportés au middleware d'auth. Couvre le chemin heureux, les cas d'erreur et les cas limites."

Pourquoi cela fonctionne : écrire les tests juste après l'implémentation, pendant que le code est encore frais, détecte les bugs au moment le moins coûteux. L'agent de tests dispose du contexte complet de ce qui a changé et pourquoi.

Variation : inversez le sens — écrivez d'abord les tests (style TDD), puis routez les spécifications de tests vers l'agent d'implémentation.

3. Le constructeur de modules en parallèle

Configuration : plusieurs tiles de terminal, sans connexions. Un tile de note au centre pour la coordination.

Agent A (auth)    Agent B (api)    Agent C (database)
      \               |               /
       \              |              /
        Note: Architecture Plan

Fonctionnement : vous découpez une grosse tâche en modules indépendants. Chaque agent reçoit un module spécifique avec des frontières d'interface claires. Le tile de note contient le plan d'architecture partagé et les contrats d'interface que tous les agents consultent.

Pourquoi cela fonctionne : c'est le pattern au meilleur débit. Trois agents travaillant sur des modules indépendants finissent 3 fois plus vite qu'un agent travaillant en séquence. La clé est de définir des interfaces propres dès le départ pour que les modules s'intègrent proprement.

Quand l'éviter : si les modules ont un couplage serré ou un état partagé, les agents se marcheront dessus. Réservez ce pattern aux travaux vraiment indépendants avec des interfaces bien définies.

4. La boucle d'affinage itératif

Configuration : deux agents connectés bidirectionnellement avec des limites de tours.

Agent A ⇄ Agent B (max 3 rounds)

Fonctionnement : l'Agent A fait une première tentative. L'Agent B la critique et suggère des améliorations. L'Agent A révise à partir du retour. Cela continue pendant un nombre de tours défini (généralement 2 à 3).

Pourquoi cela fonctionne : chaque tour resserre la solution. La première passe pose la structure. La deuxième repère les bugs et les cas limites. La troisième polit. Les rendements décroissants apparaissent après 3 tours — fixez la limite en conséquence.

Configuration : utilisez la transformation ai-routing pour que les retours de chaque agent soient reformulés en instruction exploitable, et non en sortie brute. Définissez maxRounds: 3 et cooldownMs: 5000 pour laisser à chaque agent le temps de produire une réponse complète.

Exemples de prompts :

• Tour 1 (A→B) : "Relis cette implémentation du rate limiter pour la correction et les performances."
• Tour 2 (B→A) : "Applique ces correctifs : [problèmes précis]. Puis vérifie que le correctif gère le cas limite d'accès concurrent."
• Tour 3 (A→B) : "Revue finale du rate limiter révisé. Approuve avec LGTM s'il est prêt à être livré."

5. L'éclaireur et le constructeur

Configuration : un agent léger et rapide explore la base de code ; un agent plus capable construit.

Agent éclaireur → Agent constructeur

Fonctionnement : l'agent éclaireur (qui utilise un modèle plus petit et plus rapide, ou des prompts plus simples) explore la base de code pour répondre à des questions préliminaires : "Quels fichiers sont impliqués dans le flux de paiement ? Quels patterns la base utilise-t-elle pour la gestion d'erreurs ? Quels tests existent pour le module de facturation ?"

Une fois que l'éclaireur a rassemblé le contexte, ses conclusions sont routées vers l'agent constructeur avec la tâche d'implémentation réelle, désormais enrichie d'un contexte spécifique à la base de code.

Pourquoi cela fonctionne : les grandes tâches d'implémentation échouent souvent parce que l'agent n'a pas assez de contexte sur la base de code existante. La phase d'éclaireur est peu coûteuse (modèle rapide, opérations en lecture seule) et produit la carte de contexte qui rend le travail du constructeur précis.

Conseil : utilisez la transformation full-output pour ce pattern. La sortie de l'éclaireur est déjà une information structurée (listes de fichiers, descriptions de patterns) que le constructeur peut consommer directement sans reformulation par IA.

Choisir le bon pattern

Ces patterns se combinent. Un workflow réel peut utiliser l'éclaireur et le constructeur pour rassembler le contexte, le constructeur de modules en parallèle pour implémenter, puis le pipeline de revue de code pour valider, le tout sur le même canevas.

Anti-patterns à éviter

La boucle infinie : deux agents routés l'un vers l'autre sans limite de tours ni mot-clé d'arrêt. Ils produiront un commentaire méta de plus en plus abstrait. Définissez toujours maxRounds.

Le sac de nœuds : router la sortie de chaque agent vers tous les autres agents. Surcharge d'information. Chaque connexion doit avoir un objectif clair.

Le routeur prématuré : mettre en place un routage complexe pour une tâche qui prend 2 minutes avec un seul agent. La surcharge de configuration ne vaut pas le coup pour les tâches simples et autonomes.

Les meilleurs workflows multi-agents donnent une impression d'évidence : des agents qui travaillent en parallèle, des sorties qui vont là où elles sont nécessaires, et vous qui prenez les décisions stratégiques pendant que l'exécution se déroule autour de vous.