À ce moment-là, un seul agent commence à mélanger plusieurs types de travail en même temps. Il planifie, exécute, se vérifie lui-même et porte tout le contexte accumulé. Pour une tâche courte, cela reste encore acceptable. Pour une tâche longue, cela commence à se dégrader.

C'est là que la solution devient la décomposition du travail en plusieurs rôles, chacun étant assuré par un agent IA distinct.

Introduction

Tant que la tâche est locale, un seul agent suffit généralement : analyser un Dockerfile, lire un log, trouver un point faible dans un pipeline.

Le problème commence lorsque la tâche se compose de nombreuses sous-tâches. Il devient nécessaire d'analyser séparément, d'exécuter séparément, de vérifier séparément le résultat, tout en continuant à garder le contexte global. À ce moment-là, un rôle universel commence à fonctionner moins bien que plusieurs rôles plus spécialisés.

Prenons un scénario classique d'erreur de déploiement. Il faut d'abord collecter le contexte sur le pipeline et l'environnement. Ensuite, trouver l'endroit de l'erreur. Puis préparer une correction. Et enfin vérifier que les changements sont corrects et ne cassent rien d'autre.

Lorsque tout cela est fait par un seul agent, un problème apparaît. Il commence à mélanger les rôles.

Au même moment, il :

• analyse la tâche ;
• construit un plan ;
• exécute les étapes ;
• évalue son propre résultat ;
• essaie de ne pas oublier tout le contexte accumulé.

Et plus les étapes sont nombreuses et diverses, plus cette approche entraîne une perte d'efficacité. La qualité de la vérification baisse, l'argumentation se simplifie, le contexte commence à se disperser et le résultat se dégrade.

C'est pourquoi l'idée d'utiliser des sous-agents spécialisés pour chaque type de sous-tâche apparaît naturellement. Lorsqu'un rôle commence à cumuler trop de fonctions, il devient logique de les séparer.

Qu'est-ce que l'approche multi-agent

Il y a aujourd'hui beaucoup de rhétorique inutile autour des systèmes multi-agents. Mais si l'on enlève les buzzwords, l'idée est très simple : la tâche exige plusieurs rôles, et un seul agent gère cela difficilement.

Un rôle tient le plan et l'ordre des étapes. Un autre va dans les fichiers, les commandes et les faits de la tâche. Un troisième examine le résultat séparément de l'auteur de la solution. Si nécessaire, un rôle métier ou technique vient s'ajouter par-dessus : sécurité, infrastructure, documentation.

Cela fonctionne à peu près comme lorsqu'on essaie d'organiser un processus entre collaborateurs. Quand un travail complexe est difficile à faire avec un seul rôle, on commence à le découper en parties. Le multi-agent devient utile là où il faut diviser une tâche en sous-tâches.

À quoi cela ressemble en pratique

Dans la version la plus simple, le schéma ressemble à ceci.

1. L'agent orchestrateur collecte et structure le contexte.
2. Le deuxième agent propose une solution ou un brouillon de modifications.
3. Le troisième vérifie le résultat : où sont les risques, ce qui a été oublié et ce qu'il faut vérifier manuellement.
4. Si nécessaire, l'orchestrateur surveille l'ordre des étapes et décide quand le résultat peut être transmis à un humain.

Dans les cas plus complexes, des rôles spécialisés apparaissent. Par exemple, un agent ne regarde que la sécurité, un autre les risques d'exploitation, un troisième la documentation.

Résumé de l'approche multi-agent

Le multi-agent n'est pas apparu hier, et il existe déjà aujourd'hui des approches élaborées par la communauté pour construire ce type de systèmes.

La première est plan-and-execute. L'idée est simple : avant de lancer les exécutants, quelqu'un doit découper la tâche en étapes et dépendances. Sinon, l'exécution se transforme presque immédiatement en allers-retours chaotiques entre logs, fichiers, hypothèses et corrections. C'est là qu'apparaît le rôle d'orchestrateur.

La deuxième approche importante est ReAct. Elle définit les règles de travail de l'agent exécutant : d'abord une hypothèse, puis une action, puis l'observation du résultat. Il regarde un fichier, lance une commande, voit la sortie, puis ajuste l'étape suivante.

La troisième concerne le travail avec le contexte. Tous les agents n'ont pas besoin de tout le contexte. Plus encore, les modèles actuels ne sont pas capables de garder efficacement trop d'informations dans le contexte. Le système fonctionne donc mieux lorsque le contexte est chargé de manière dosée : uniquement les fichiers nécessaires, uniquement les instructions nécessaires, uniquement les faits pertinents. Sinon, le système commence à se noyer dans son propre bruit avant même d'avoir eu le temps d'apporter de la valeur.

La quatrième approche est le critic séparé comme rôle isolé. Le critic doit être du même niveau que le rôle principal, ou plus fort. L'isolation est importante ici. Si le critic reçoit tout le bavardage interne, les doutes précédents et les raisonnements de l'auteur, il commence très vite à vérifier non pas le résultat, mais la logique dont il a déjà été contaminé. Il est donc important que le critic voie la tâche, les critères et le résultat, mais pas la chaîne de raisonnement de l'exécutant.

La cinquième approche est une rubric explicite pour la critique. C'est un schéma concret de travail du critic. Sans cela, le critic se transforme très vite en rôle flou de type « je n'aime pas ». Quand il existe des catégories claires comme blocker, warning et suggestion, la vérification fonctionne nettement mieux. Cela apporte de la clarté aux résultats du critic, ce qui améliore leur interprétation par les autres agents.

La sixième couche est Reflexion et une bonne gestion de la fin des itérations. Il est important que le système tienne compte non seulement du contexte, mais aussi des itérations précédentes de son propre travail. Sinon, il tournera simplement en rond en brûlant des tokens. En même temps, le nombre d'itérations doit être limité. À un moment donné, le système doit être capable de dire qu'un humain est nécessaire.

Il existe aussi des amplificateurs supplémentaires. Le RAG est utile lorsque la connaissance importante se trouve hors du dialogue courant : dans la documentation, des paquets de connaissances, des standards ou des bases internes. Tree of Thoughts et Skeleton-of-Thought aident lorsque l'orchestrator doit d'abord construire le squelette d'une solution ou faire émerger plusieurs variantes de plan. Multi-Agent Debate et Mixture of Agents sont pertinents lorsqu'une seule vérification ne suffit plus et qu'il faut soit confronter des positions, soit faire passer le résultat par plusieurs niveaux d'affinage. Spec-Driven Development est utile dans les tâches où il faut d'abord se mettre d'accord sur la spécification, puis seulement ensuite passer à l'implémentation. Mais cela relève déjà d'un réglage fin selon les besoins et préférences d'un projet ou d'une personne donnée.

Comment configurer tout cela ?

Il est déjà clair qu'un système multi-agent ne peut pas reposer sur un seul gros prompt. L'industrie a déjà développé des approches pour organiser logiquement le travail de plusieurs agents.

La première chose à connaître est AGENTS.md. Il se trouve à la racine du dépôt et joue le rôle de carte du projet. Il est pratique d'y conserver le contexte de référence : ce que contient le dépôt, comment lancer le projet, où se trouvent les zones sensibles, quelles commandes existent, quelles limites et frontières de travail s'appliquent. Ce fichier est le premier lu par l'agent, comme stockage de contexte.

Des fichiers de prompt séparés pour chaque agent sont nécessaires pour la même raison que l'on sépare les rôles. L'orchestrator, l'executor et le critic ne doivent pas vivre dans un seul long texte. Ils ont des tâches différentes, des ensembles d'outils différents et une manière différente de regarder le résultat. Si l'on met tout cela dans un seul prompt, l'executor commencera à absorber une logique de vérification qui n'est pas la sienne, le critic recevra du bruit inutile, et le fichier deviendra rapidement difficile à maintenir. En pratique, un schéma où chaque rôle dispose de son propre fichier avec son contrat fonctionne beaucoup plus durablement.

Une couche séparée est celle des skills, généralement sous forme de SKILL.md. Ils sont nécessaires lorsque la connaissance se répète et ne doit être connectée qu'en cas de besoin : sécurité, documentation, patterns d'architecture, spécificités d'une stack donnée. La pratique montre que si l'on gonfle trop le prompt d'un agent, celui-ci commence à perdre le sens des mots au milieu du prompt. Il vaut donc mieux décrire dans le prompt principal les règles de connexion des skills que de tout jeter dans un seul bloc.

Au-dessus, il existe généralement une couche commune de règles. Par exemple, des workspace instructions ou copilot-instructions.md contiennent ce qui doit s'appliquer à tous les rôles à la fois : contraintes générales, exigences de qualité, comportement de base. C'est un autre type d'information. Il est également utile de le conserver séparément afin de ne pas dupliquer les mêmes éléments dans chaque prompt d'agent.

Des fichiers de vue d'ensemble comme llms.txt peuvent aussi être utiles, ainsi que, parfois, des fichiers .prompt.md séparés pour les scénarios répétables. Le premier aide à entrer rapidement dans le projet sans longue lecture. En substance, il répète AGENTS.md, mais sous une forme moins lisible pour l'humain. Les seconds sont utiles lorsqu'une même tâche se répète souvent et qu'il est plus pratique de la formaliser comme un bloc de prompt réutilisable plutôt que de la réécrire manuellement dans chaque agent.

Ensuite viennent les artefacts du travail du système. Dès que les agents font plus d'une étape, une question apparaît presque immédiatement : où stocker le contexte de la tâche courante et comment comprendre ensuite ce que les agents ont réellement fait dans son cadre ?

C'est pourquoi, à côté des fichiers permanents, apparaît presque toujours une couche de contexte de session. Il peut s'agir d'un TASK_CONTEXT.md séparé ou d'un autre fichier de travail dans lequel s'accumulent la formulation de la tâche, les contraintes acceptées, les découvertes importantes, les tentatives précédentes échouées et le statut courant. Le sens est très simple : le passage suivant sur la tâche ne doit pas recommencer à zéro. Si l'executor s'est déjà retrouvé dans une impasse, si le critic a déjà trouvé un point faible et si l'orchestrator a déjà réduit le périmètre, cela doit être sauvegardé explicitement quelque part, et non vivre uniquement dans la mémoire du dernier dialogue.

Par-dessus cela apparaît généralement une trace des étapes des agents. En règle générale, elle sert au débogage : qui a commencé la tâche, quelle était l'itération, qui a exécuté quoi, quand le critic a renvoyé ses remarques, où l'escalade vers un humain s'est produite et à quelle étape le processus s'est bloqué.

Au final, au-delà de l'idée même de multi-agent, l'industrie moderne dispose déjà d'un certain nombre d'approches pratiques pour la mettre en oeuvre. Et tout cela évolue activement ici et maintenant.

À quoi ressemble le schéma de travail final

Si l'on rassemble ces approches en un circuit de travail normal, il ressemblera à peu près à ceci.

1. L'orchestrator reçoit la tâche et commence par la découper en étapes. Ici fonctionne le plan-and-execute : d'abord l'ordre, puis l'exécution.
2. Le système charge uniquement le contexte nécessaire. Ici comptent à la fois le chargement prudent des connaissances et l'organisation des fichiers : la carte du projet depuis AGENTS.md, le bref aperçu depuis llms.txt, les règles générales depuis les instructions, les skills nécessaires et uniquement les fichiers réellement liés à la tâche.
3. L'executor avance par cycles courts « hypothèse -> action -> observation ». C'est le ReAct pratique, sans lequel une tâche d'ingénierie se transforme vite en devinette.
4. Le critic reçoit le résultat séparément de l'executor et le vérifie selon une rubric explicite. C'est ici que se rejoignent LLM-as-Judge, l'isolation du critic et la critique selon des niveaux de gravité définis à l'avance.
5. Au fil du travail, le système met à jour le contexte de session de la tâche : ce qui a déjà été vérifié, quelles hypothèses ont été écartées, quelles remarques doivent être prises en compte au prochain passage. Sans cela, Reflexion devient vite un joli mot sans mémoire.
6. En parallèle, le journal des étapes est aussi conservé : planification, exécution, critique, nouvelle itération, escalade, finalisation. Cela rend le système observable et permet ensuite d'analyser non seulement le résultat, mais aussi le chemin qui y a mené.
7. Si de vrais problèmes sont trouvés, l'itération suivante ne repart pas de zéro, mais tient compte des erreurs précédentes. C'est là que Reflexion commence réellement à fonctionner.
8. Si les itérations ne donnent pas de résultat clair, le processus s'arrête et la tâche revient à un humain. Ce n'est pas une faiblesse du système, mais le signe d'une architecture saine.
9. Pour les actions risquées, les droits doivent être séparés à l'avance. L'executor reçoit uniquement les outils nécessaires à son rôle, le critic reste aussi proche que possible du read-only, et les étapes irréversibles sont confirmées par un humain.
10. Dans les tâches plus complexes, des rôles spécialisés et des boucles de vérification supplémentaires peuvent être ajoutés par-dessus ce schéma. Mais la logique de base reste la même : séparation des rôles, vérification isolée, itérations contrôlées, conservation du contexte et point d'arrêt clair.

C'est précisément ce schéma qui fait du multi-agent non pas une simple théorie, mais une pratique d'ingénierie reproductible.

Où cela peut être utile

Je pense que la réponse est très simple : parce que la tâche elle-même se compose généralement déjà de différents types de travail. Infrastructure, pipeline, conteneurs, sécurité, diagnostic et documentation cohabitent ici.

Par exemple, lors de l'analyse d'un déploiement problématique, un rôle peut parcourir azure-pipelines.yml et DeploymentPackagePipline.yml, un deuxième comparer DockerfilePlamar, DockerfileScheduler et les configurations de démarrage, tandis qu'un troisième vérifie les questions de sécurité. Une grande tâche lourde et visqueuse se décompose en plusieurs étapes constitutives.

Cette logique se transpose bien à d'autres domaines d'ingénierie. En développement, un rôle peut écrire un brouillon de solution, le deuxième vérifier la cohérence architecturale, le troisième évaluer les risques des changements.

Dans la documentation, un rôle collecte les faits, le deuxième écrit l'explication, le troisième cherche les trous de raisonnement et les simplifications dangereuses.

La même chose fonctionne en QA, en analyse et dans les tâches de recherche. C'est pourquoi le multi-agent devient une partie intégrante de l'agenda IA, même s'il reproduit au fond la structure des grandes équipes, avec ses propres spécificités.

Limites de l'approche

Mais il est important de ne pas tomber dans l'excès inverse. Le multi-agent a son propre coût.

Premièrement, l'orchestration se complexifie. Il faut décider quels rôles sont réellement nécessaires, comment ils se transmettent le contexte et à quel moment le processus doit s'arrêter.

Deuxièmement, les exigences sur la qualité des règles augmentent fortement. Une formulation floue de la tâche dans un système multi-agent devient presque toujours encore plus floue. Si les frontières des rôles ne sont pas claires, le processus se désagrège rapidement.

Troisièmement, le coût des erreurs dans l'architecture du processus lui-même augmente. Une mauvaise répartition des rôles ne donne pas un effet d'amplification, mais de la duplication, des itérations inutiles et du bruit, ce qui équivaut à dépenser de l'argent sans résultat.

Enfin, il reste la tentation de compliquer le système trop tôt. Il existe beaucoup de tâches où un seul agent et une validation manuelle normale suffisent largement.

Il faut donc voir le multi-agent non pas comme une amélioration universelle, mais comme un outil qui n'est pas nécessaire partout.

Quand le multi-agent est réellement justifié

Le critère est très simple : si la tâche est courte, locale et tient bien dans une seule tête, le multi-agent ne fait que gêner. Mais si elle est longue, mélange différents types de travail, exige une vérification séparée du résultat et si le coût de l'erreur est notable, alors cette approche commence à devenir rentable.

C'est dans ce type de tâches que le multi-agent apporte un gain visible de productivité et de qualité.

Cela dit, je veux rappeler une chose importante. Même un système multi-agent reste un outil. Ce n'est pas un remplacement de l'humain, et encore moins d'une équipe. Ce n'est qu'une façon d'être encore plus efficace.

Conclusion

Au final, on peut dire que le multi-agent devient utile exactement au moment où un seul rôle ne parvient plus à porter toute la tâche.

Dès que les logs de build, un pipeline YAML, un Dockerfile, les risques de release et la nécessité de vérifier séparément le résultat se retrouvent côte à côte, la séparation des rôles commence à apporter de la valeur.

Nous avons discuté des approches et même de la structure de fichiers pour un tel système, mais cela reste encore théorique. Passons maintenant à la pratique. Dans le prochain article, nous regarderons AutoGen Framework - une bibliothèque Python créée spécialement pour construire des systèmes multi-agents.