L'année où le multi-agents est devenu sérieux
Pendant la majeure partie de 2024, la conversation sur les multi-agents relevait du ressenti. Les gens publiaient des démos d'« essaims d'agents » organisant des mariages ou faisant tourner de fausses entreprises, et presque rien de tout cela ne survivait au contact de la production. La promesse était immense. Les preuves étaient minces.
Cela a changé en avril 2025, lorsqu'Anthropic a publié le compte rendu d'ingénierie de son système de recherche multi-agents. L'architecture était simple dans sa forme : un agent principal Claude Opus 4 sert d'orchestrateur, décompose une question de recherche en sous-tâches, lance des sous-agents pour enquêter en parallèle, puis assemble leurs sorties. Sur l'évaluation interne de navigation d'Anthropic, cette configuration a battu une référence Opus 4 mono-agent de 90,2 %. (Anthropic engineering, « How we built our multi-agent research system »)
Voilà pour le gros titre. Les petits caractères comptent davantage. Le même article note que les systèmes multi-agents utilisent environ 15 fois plus de tokens qu'une conversation normale. La consommation de tokens expliquait environ 80 % de la variance de performance dans leur cadre d'évaluation. Vous n'obtenez pas ces 90,2 % gratuitement ; vous les achetez.
La question pour tout fondateur, CTO ou staff engineer concevant une fonctionnalité IA n'est donc plus « le multi-agents est-il un vrai schéma ? ». C'est « le multi-agents est-il le bon schéma pour cette tâche, et à quel coût ? ». 2025 et la première moitié de 2026 ont produit suffisamment de données pour répondre à cette question avec plus que de l'intuition. Les schémas qui ont gagné, ceux qui ont perdu et les modes de défaillance récurrents ressemblent beaucoup à la conception organisationnelle classique. C'est le fil conducteur de cet article.
La taxonomie des modes de défaillance : ce que Cemri et al. ont documenté
En mars 2025, Mert Cemri et ses collaborateurs à Berkeley ont publié « Why Do Multi-Agent LLM Systems Fail? » (arXiv 2503.13657). L'article a analysé cinq frameworks multi-agents populaires sur plus de 150 traces conversationnelles et a produit quelque chose dont le domaine avait cruellement besoin : une taxonomie.
Quatorze modes de défaillance distincts, regroupés en trois familles.
Défaillances de spécification et de conception du système. Les agents désobéissent à leur spécification de rôle. Ils désobéissent à la spécification de la tâche. Ils perdent l'historique de la conversation. Des étapes se répètent. Les conditions de terminaison ne se déclenchent jamais. Le système « connaît » la tâche, mais l'agent individuel devant vous ne se comporte pas comme s'il la connaissait.
Mésalignement inter-agents. Les agents réinitialisent leur progression et recommencent. Ils se cachent des informations les uns aux autres. Ils dérivent dans des échanges hors sujet. Ils font des hypothèses sur ce qu'un autre agent a fait et agissent sur ces hypothèses sans vérifier. C'est la défaillance classique du « je pensais que tu t'en occupais » de toute équipe.
Défaillances de vérification et de terminaison des tâches. La vérification est incomplète ou absente. Le système déclare le succès alors que la sortie est erronée. Aucun agent ne possède la vérification d'acceptation finale. Les humains ne détectent le problème qu'en aval, quand la mauvaise sortie s'est déjà propagée.
Lisez la liste et la forme devient évidente. Ce ne sont pas des défaillances de modèle au sens étroit. Ce sont des défaillances de coordination. Ce sont les mêmes défaillances qu'une nouvelle équipe de cinq personnes commet dans son premier mois, avant que quiconque ait écrit qui possède quoi.
Regroupez les 14 modes différemment et le parallèle avec la conception organisationnelle s'affine :
- Ambiguïté des rôles. Propriété de tâche floue. Deux agents tentent la même étape, ou aucun ne le fait.
- Ambiguïté de l'état. Pas de source unique de vérité sur ce qui a été fait, ce qui est en attente, ce qui est bloqué.
- Lacunes de responsabilité. Qui est responsable de la mauvaise sortie ? Dans les systèmes pair-à-pair, souvent personne.
- Surcharge de coordination. Le « problème de la réunion ». Les agents dépensent des tokens à négocier au lieu de produire.
- Dérive de spécification. La même instruction est interprétée différemment d'un agent à l'autre et d'un tour à l'autre.
Si vous avez déjà reconstruit une équipe qui ne livrait pas, vous avez vu les cinq. Le correctif dans les équipes humaines est le même que dans les systèmes d'agents : choisir un modèle opérationnel, écrire les rôles, définir les transmissions, instrumenter le travail.
Pourquoi les agents pair-à-pair ne fonctionnent pas
L'erreur architecturale la plus courante de 2024 et du début 2025 était la collaboration pair-à-pair : faire émerger une « équipe » d'agents avec différents prompts de rôle (PDG, chercheur, codeur, relecteur), les laisser se parler dans un chat de groupe, espérer que la coordination émerge. Les chats de groupe de style AutoGen, les premières démos CrewAI et une vague de projets « start-up IA en boîte » s'appuyaient tous sur ce schéma.
Cela a échoué en production, systématiquement. Chaque mode de défaillance de la taxonomie de Cemri s'amplifie dans une configuration P2P. Sans orchestrateur, les frontières de rôle s'estompent parce que chaque agent peut être sollicité pour n'importe quoi. L'état se disperse dans l'historique de la conversation parce qu'aucun agent ne possède le registre canonique. La responsabilité disparaît parce que le système dans son ensemble produit la sortie, et le système dans son ensemble n'a aucun nom dessus.
La surcharge de coordination est le tueur. Dans un groupe de cinq agents pairs, chaque action significative génère quatre observateurs qui se sentent obligés de commenter. Le coût en tokens explose. Le rapport signal-sur-bruit s'effondre. Cemri et al. ont constaté que la réinitialisation conversationnelle, où un agent redémarre un fil terminé parce qu'il ne peut pas dire que le fil est terminé, était l'une des défaillances les plus courantes et les plus coûteuses dans leur corpus.
Un exemple concret. Une équipe de recherche à laquelle j'ai parlé fin 2025 a construit un système d'agents P2P pour rédiger une analyse concurrentielle. Cinq agents : analyste de marché, analyste produit, analyste financier, rédacteur, éditeur. La première exécution a pris 90 minutes et produit un document de 14 000 mots. Environ 11 000 de ces mots étaient les agents discutant de ce que le document devait contenir. Les 3 000 restants étaient le document lui-même, et ils se contredisaient les uns les autres. L'équipe l'a reconstruit en configuration orchestrateur-travailleur la semaine suivante. Même tâche, 22 minutes, 4 200 mots, cohérent en interne. Environ la moitié de la dépense en tokens.
Le P2P n'a pas échoué parce que les agents n'étaient pas assez intelligents. Il a échoué parce qu'il leur demandait de faire la chose la plus difficile qu'un groupe puisse faire : s'organiser sans président.
Orchestrateur-travailleur : le schéma qui a gagné
Le système de recherche d'Anthropic est une configuration orchestrateur-travailleur de manuel. Un agent coordinateur possède la tâche de haut niveau. Il décompose la tâche en sous-tâches, confie chaque sous-tâche à un agent travailleur avec un briefing spécifique, collecte les résultats et décide quoi faire ensuite. Les travailleurs ne se parlent pas. Ils parlent à l'orchestrateur.
Cela correspond proprement à la conception organisationnelle humaine, ce qui est exactement la raison pour laquelle cela fonctionne. Une petite start-up avec un fondateur et quatre contractants fonctionne ainsi. Le fondateur détient la spécification, le budget, le calendrier et le contexte partagé. Les contractants exécutent des tâches cadrées sur la base d'un briefing. L'information remonte par le fondateur ; les tâches descendent du fondateur. On n'attend pas des contractants qu'ils se coordonnent entre eux, sauf dans des binômes soigneusement cadrés.
Le schéma possède quatre propriétés qui comptent pour la fiabilité.
Un seul propriétaire de l'état partagé. L'orchestrateur détient le registre canonique. Il n'y a pas d'ambiguïté sur ce qui a été fait.
Contextes de travailleurs cadrés. Chaque travailleur ne reçoit que ce dont il a besoin. Cela maintient les fenêtres de contexte gérables et réduit le risque de contamination entre tâches.
Transmissions définies. Les sorties des travailleurs reviennent dans un format structuré que l'orchestrateur peut vérifier. Pas de négociation en forme libre.
Surface de responsabilité unique. Quand la sortie est erronée, l'orchestrateur est responsable. Vous déboguez à un seul endroit.
L'article d'Anthropic est explicite sur la quantité de leur travail de fiabilité qui s'est déroulée à l'intérieur de l'orchestrateur : le prompt de l'agent principal est la partie la plus longue et la plus soigneusement réglée du système, parce que c'est là que vivent les définitions de rôle, les heuristiques de décomposition et la logique de terminaison. (Anthropic engineering)
La collaboration bornée est une variante utile. Deux travailleurs peuvent être autorisés à se concerter sur une transmission spécifique, mais uniquement via un canal structuré et uniquement sur un sujet défini. Pensez-y comme à un standup planifié, pas à un canal Slack. La frontière est le point.
| Schéma | Résilience aux défaillances | Coût | Complexité | Où il convient |
|---|---|---|---|---|
| Pair-à-pair (chat de groupe) | Faible. Chaque mode de défaillance s'amplifie. | Élevé. Beaucoup de tokens de négociation. | Trompeuse. Semble simple, ne l'est pas. | Démos, esquisses de brainstorming. |
| Orchestrateur-travailleur | Élevée. Un seul propriétaire, une seule surface de débogage. | Modéré à élevé. Environ 10 à 15 fois un agent unique. | Modérée. La majeure partie de la logique réside dans l'orchestrateur. | Recherche, décomposition, travail parallélisable. |
| Collaboration bornée | Moyenne à élevée. Le risque réside à la jointure. | Modéré. Moins cher que le P2P complet. | Plus élevée. Les transmissions conçues demandent du travail. | Binômes de spécialistes sous un orchestrateur. |
| Agent-flow (DAG) | Élevée. La structure statique prévient la dérive. | Faible à modéré. Réutilise les étapes mises en cache. | Modérée à la conception, faible à l'exécution. | Pipelines répétitifs, traitement par lots. |
Le cadre d'autonomie à 5 niveaux
L'autre pièce d'échafaudage de 2025 qui vaut la peine d'être connue est le cadre d'autonomie de « Levels of Autonomy for AI Agents » (arXiv 2506.12469, avec un article de gouvernance complémentaire à Knight Columbia). Les auteurs définissent cinq niveaux, vaguement analogues à l'automatisation de conduite SAE mais pour les agents IA.
Niveau 0 : Assistance. Le modèle suggère ; l'humain agit. Autocomplétion, suggestions de code en ligne, rédaction de brouillons d'e-mails.
Niveau 1 : Opérateur. L'humain émet encore chaque action, mais l'agent assemble les appels d'outils et les étapes composites sous instruction directe.
Niveau 2 : Relecteur. L'agent propose un plan et l'exécute sous relecture. L'humain approuve aux principaux points de contrôle.
Niveau 3 : Collaborateur. L'agent possède des tâches entières de manière autonome à l'intérieur d'une frontière cadrée. L'humain relit les sorties, pas les étapes.
Niveau 4 : Expert. L'agent opère indépendamment sur des travaux complexes en plusieurs étapes, l'humain n'intervenant que sur les exceptions signalées.
Niveau 5 : Agent. Autonomie complète sur un domaine. L'agent fixe les objectifs, planifie, exécute et s'auto-corrige avec une supervision minimale.
Le travail complémentaire d'Anthropic « Measuring AI agent autonomy in practice » fait une remarque connexe : dans les déploiements réels, le niveau opérationnel est rarement uniforme à travers un système. Un système « niveau 3 » contient généralement des sous-composants de niveau 1 (actions à enjeux élevés) et des sous-composants de niveau 4 (travail en arrière-plan à faibles enjeux). Ce qui compte, c'est d'adapter le niveau à la tâche, pas d'élever le niveau globalement.
Le niveau que vous visez façonne chaque décision de conception de rôle en aval. Au niveau 2, vos agents travailleurs ont besoin d'affordances claires de revue de plan. Au niveau 4, ils ont besoin de signalement d'exceptions et de traçage riche. Au niveau 5, ils ont besoin de vérification formelle des critères d'acceptation, parce que rien d'autre ne détecte une mauvaise réponse. Les bâtisseurs qui sautent cette étape choisissent d'abord l'architecture, puis découvrent, en production, que le niveau impliqué par l'architecture n'est pas le niveau que la tâche peut tolérer.
Les niveaux en pratique : le cas Devin
Devin de Cognition est devenu l'avertissement le plus cité de 2025. Lancé en mars 2024 comme « le premier ingénieur logiciel IA », Devin a obtenu 13,86 % sur SWE-bench Verified, ce qui était à l'époque l'état de l'art. Le marketing impliquait une autonomie de niveau 4 ou 5 : confiez-lui un ticket, récupérez une PR fonctionnelle.
Au milieu de 2025, plusieurs revues indépendantes ont situé le taux de réussite en conditions réelles de Devin à environ 15 %, signifiant un taux d'échec effectif autour de 85 % sur des tâches qui n'étaient pas des instances de benchmark soigneusement sélectionnées. Une revue largement citée d'Answer.AI a passé en revue 20 tentatives réelles et a signalé que 14 ont échoué d'emblée, plusieurs produisant des sorties confidemment fausses qui ont pris plus de temps à déboguer que d'écrire le code à partir de zéro.
Ce qui s'est passé, c'est l'écart benchmark vs production, aiguisé. Les tâches SWE-bench Verified sont propres : un dépôt, un problème bien décrit, un signal de test clair, une surface contrainte. Les vrais tickets d'ingénierie sont désordonnés : spécifications ambiguës, préoccupations transversales, hypothèses non documentées, décisions qui dépendent de connaissances tribales. Le même agent qui se plaçait au niveau 3 sur le benchmark est tombé à un niveau 2 chancelant en milieu naturel, parfois pire.
Devin n'est pas l'histoire d'un mauvais agent. C'est l'histoire d'un décalage de niveau. L'architecture visait la fiabilité de niveau 5 ; la capacité sous-jacente soutenait au mieux le niveau 2 sur du travail non sélectionné. Le marketing forçait les utilisateurs à exploiter le système au niveau annoncé, où il échouait. Les pivots ultérieurs de Cognition, des cas d'usage plus cadrés, plus d'affordances humain-dans-la-boucle, un cadrage plus honnête, sont une tentative de ramener le niveau opérationnel en ligne avec la capacité.
La leçon est concrète. Choisissez le niveau d'autonomie que votre système peut soutenir sur votre tâche réelle la plus difficile, pas sur votre benchmark le plus facile. Concevez les rôles, la supervision et les chemins d'escalade pour ce niveau. Si vous voulez un marketing de niveau 5, construisez un système de niveau 5 ; si vous avez un système de niveau 3, commercialisez-le comme tel.
Cursor 2.0 et le workflow soutenu par le matériel
Cursor 2.0 a été livré en février 2026 et a discrètement résolu l'un des problèmes les plus persistants du codage multi-agents : le conflit d'espace de travail. Les agents en arrière-plan de Cursor s'exécutent désormais sur des VM cloud, chacun dans son propre git worktree, l'IDE pouvant en coordonner jusqu'à huit en parallèle.
Le détail architectural qui compte : chaque agent a son propre système de fichiers. Pas d'arbre de travail partagé signifie pas de conflits de fusion en pleine édition, pas d'« agent A a écrasé les changements de l'agent B », pas d'exécutions de tests instables parce que deux agents touchaient aux mêmes fichiers. Quand un agent termine, sa branche peut être relue et fusionnée comme n'importe quelle autre PR. Quand ça tourne mal, vous jetez le worktree.
C'est de l'isolation soutenue par le matériel au même sens où les machines virtuelles ont donné l'isolation de processus dans les années 2000. Les barrières d'agent ne sont plus « nous promettons de ne pas nous marcher dessus » ; ce sont « le système d'exploitation ne nous laissera littéralement pas faire ».
Pourquoi cela importe pour la taxonomie de Cemri : l'isolation matérielle supprime toute une classe de défaillances de mésalignement inter-agents. L'état reste à l'intérieur du worktree. Les effets de bord restent à l'intérieur de la VM. L'orchestrateur (Cursor lui-même, ou l'utilisateur) ne voit que le diff que chaque agent produit. La vérification d'acceptation est structurelle (la PR passe-t-elle la CI ?) au lieu d'être conversationnelle (cet agent prétend-il que le travail est fait ?).
Les praticiens qui font tourner Cursor 2.0 aux côtés de Claude Code d'Anthropic, de Codex CLI d'OpenAI et d'autres outils d'agents parallèles se sont installés dans un schéma : faire émerger trois à huit agents sur des tâches indépendantes, surveiller leur progression via un tableau de bord unifié, fusionner les gains, écarter les pertes. Le modèle de coût est plus proche de « louer un contractant junior pendant une heure et demie » que de « poser une question à un chatbot ». Le modèle de sortie est plus proche de la revue de PR GitHub que de la complétion de chat.
Anysphere (Cursor), Bolt, Lovable et v0 chez Vercel font tous tourner désormais des variantes de cette boucle en interne. Les entreprises qui livrent le plus de code piloté par agent sont celles qui ont d'abord construit l'isolation de l'espace de travail.
Concevoir des rôles pour des coéquipiers IA
Une fois que vous acceptez que l'échec multi-agents est un problème de conception organisationnelle, les choix de conception que vous faites commencent à ressembler au management classique. Chaque rôle d'agent a besoin de quatre artefacts.
Une responsabilité cadrée. Une phrase : ce que cet agent possède et ce qu'il ne possède pas. Un agent « chercheur » qui écrit aussi de la prose, ce sont deux agents dans un trench-coat. Séparez-les.
Un briefing d'entrée structuré. Pas « va chercher X ». Un modèle qui remplit : la question, le contexte préalable que l'agent doit supposer, le format de la sortie attendue, les contraintes (temps, tokens, outils), les préférences de sources. C'est l'équivalent agent d'un briefing de projet.
Des critères d'acceptation définis. À quoi ressemble « terminé » ? Souvent c'est un schéma (la sortie doit être validée contre ce type Zod) ou une vérification déterministe (la PR doit passer ces trois fichiers de test). Là où les vérifications déterministes ne sont pas disponibles, un agent relecteur séparé tourne contre une grille explicite.
Un chemin d'escalade. Quand l'agent se retrouve coincé, que fait-il ? Valeurs par défaut raisonnables : poser à l'orchestrateur une question de clarification structurée, faire remonter une exception signalée à un humain, abandonner avec une erreur typée. La mauvaise valeur par défaut est « continuer et improviser ». C'est de là que vient le succès halluciné.
Appliquez les modes de défaillance de Cemri un par un et ces quatre artefacts en couvrent la plupart. L'ambiguïté des rôles meurt sur la responsabilité cadrée. L'ambiguïté de l'état meurt sur le briefing structuré. Les lacunes de responsabilité meurent sur les critères d'acceptation. La surcharge de coordination chute parce que l'agent n'a pas besoin de négocier ; il a un briefing et une grille. La dérive de spécification chute parce que la spécification est capturée dans le schéma, pas dans le ressenti.
La partie non évidente : écrivez le rôle comme vous écririez une description de poste pour un contractant, pas un prompt pour un chatbot. Les contractants sont le bon modèle mental. Ils ont un briefing, ils livrent une sortie, ils n'ont pas besoin de connaître tout le contexte de votre entreprise, et vous les renvoyez s'ils manquent constamment la spécification.
Le manuel multi-agents du fondateur
Voici la version pratique, distillée de l'article d'Anthropic, du papier de Cemri, des post-mortems de Devin et des données de workflow de Cursor 2.0.
Commencez au niveau 2 ou 3, pas au niveau 5. La capacité est fragile sous décalage de distribution. Même si votre benchmark dit niveau 4, votre tâche réelle la plus difficile est généralement un niveau en dessous. Visez le niveau que votre tâche la plus difficile peut soutenir.
Utilisez orchestrateur-travailleur, pas pair-à-pair. Un seul agent possède l'état partagé. Les travailleurs reçoivent des briefings cadrés. Collaboration bornée seulement aux jointures soigneusement conçues. Pas de chats de groupe.
Définissez un rôle d'agent à la fois. Résistez à l'envie de concevoir un système à cinq agents sur un tableau blanc avant qu'aucune partie ne soit livrée. Livrez un orchestrateur et un travailleur. Observez-le pendant une semaine. Ajoutez le travailleur suivant quand vous avez vu le premier échouer et l'avez corrigé.
Écrivez le briefing comme une description de poste. Responsabilité, entrées, critères d'acceptation, escalade. Si vous ne pouvez pas décrire le rôle en quatre courtes sections, le rôle n'est pas prêt à être livré.
Instrumentez avec des traces complètes. Chaque action d'agent, chaque appel d'outil, chaque sortie intermédiaire. Vous ne pouvez pas déboguer les systèmes multi-agents en lisant la sortie finale. Le bug est presque toujours en amont.
Budgétisez un coût en tokens de 15x. Le système de recherche d'Anthropic a utilisé environ 15 fois les tokens d'une référence mono-agent. Planifiez en conséquence. Si votre économie unitaire se brise à 15x, le multi-agents est le mauvais schéma pour cette fonctionnalité.
Gardez un humain dans la boucle sur les actions à conséquences. « À conséquences » signifie généralement : écrit sur un système orienté client, envoie une communication externe, dépense de l'argent, supprime des données, modifie une ressource pertinente pour la sécurité. La relecture humaine coûte des secondes ; son absence peut coûter des mois.
Construisez l'isolation de l'espace de travail avant la flotte d'agents. La leçon de Cursor se généralise. Git worktrees pour le code, transactions de base de données cadrées pour les données, VM dédiées pour le travail touchant l'environnement. L'isolation est moins chère que la coordination.
Faites un post-mortem sur chaque défaillance pendant les 90 premiers jours. Étiquetez chaque défaillance contre la taxonomie de Cemri. Les schémas émergent rapidement. La troisième défaillance « l'agent a refait du travail terminé » est le signal que vos conditions de terminaison ont besoin d'être resserrées.
Rien de tout cela n'est exotique. C'est le même manuel qu'un leader d'ingénierie compétent utilise pour intégrer une nouvelle équipe de contractants. La raison pour laquelle le multi-agents fonctionne est que c'est le même problème avec une boucle de rétroaction plus serrée.
Où tout cela se dirige
Les 12 à 18 prochains mois consistent à transformer ces schémas en infrastructure. Quelques fils à surveiller.
Protocoles agent-à-agent. Le protocole A2A de Google, la convention AGENTS.md émergeant à travers l'outillage IDE et CLI, et divers brouillons d'interopérabilité dans les groupes de travail sont une tentative de standardiser la manière dont les agents se découvrent, échangent des descriptions de capacités et s'authentifient. (L'aperçu d'Anthropic sur la construction d'agents fait un signe dans cette direction.) L'objectif est de rendre les schémas orchestrateur-travailleur composables entre fournisseurs, au lieu de les enfermer dans le SDK d'un seul fournisseur.
Autorisation par jetons de capacité. Aujourd'hui, la plupart des agents héritent des identifiants complets de l'utilisateur qui les a lancés. C'est une mauvaise idée pour le niveau 3 et au-dessus. Les jetons de capacité, étroits, bornés dans le temps, cadrés sur des appels d'outils et des ressources spécifiques, sont la manière dont les agents obtiendront les permissions dont ils ont réellement besoin sans celles dont ils n'ont pas besoin. Attendez-vous à ce que cela atterrisse dans les SDK de production en 2026.
Identités d'agents vérifiées. Quand les agents commencent à appeler d'autres agents à travers les frontières organisationnelles, le côté récepteur doit savoir qui appelle. Identités d'agents signées, attestation de l'entraînement et de la configuration, et formats d'identité inter-fournisseurs sont en cours de prototypage maintenant. Le modèle est plus proche de la transparence des certificats que d'OAuth.
Meilleure évaluation. SWE-bench, MLE-bench, GAIA et des suites similaires se sont étirées assez loin pour que les modèles de pointe les saturent. La prochaine génération d'évaluations mesurera des choses que les benchmarks ont historiquement esquivées : achèvement de tâches à long horizon, conformité soutenue aux politiques, récupération après défaillance, coût par succès. Attendez-vous à ce que la « fiabilité des agents » devienne une propriété mesurable comme l'« uptime » l'est devenu pour les services.
Étiquetage standardisé des défaillances. Cemri et al. ont donné au domaine une taxonomie. La prochaine étape naturelle est un outillage qui étiquette automatiquement les traces contre cette taxonomie, à la manière dont Sentry étiquette les exceptions. Les fondateurs qui mettent cela en place tôt déboguent leurs systèmes d'agents un ordre de grandeur plus vite que ceux qui ne le font pas.
Le travail est encore en plein vol. Aucun de ces fils n'est réglé. Mais la forme de la prochaine phase est visible : moins d'artisanat de prompt, plus d'ingénierie de systèmes ; moins de « que peut faire le modèle ? », plus de « quel rôle ai-je besoin de remplir, et à quoi ressemble terminé ? ». Les équipes qui prospéreront seront celles qui traitent les agents comme des coéquipiers, avec la même rigueur qu'elles appliqueraient à toute nouvelle embauche. Rôles, briefings, critères d'acceptation, chemins d'escalade. Les artefacts ennuyeux des organisations compétentes.
Questions fréquemment posées
Toutes les équipes devraient-elles construire des systèmes multi-agents ?
Non. La plupart des fonctionnalités IA en production fonctionnent encore mieux en configuration mono-agent avec de bons outils. Le multi-agents mérite sa place quand la tâche est véritablement décomposable (sous-tâches indépendantes pouvant tourner en parallèle), que la valeur par tâche justifie le coût en tokens de 15x, et que la fiabilité a d'abord été prouvée à la couche mono-agent. Un système mono-agent défaillant ne devient pas un système multi-agents fonctionnel. Il devient généralement un système défaillant plus coûteux.
Quel est le schéma multi-agents le plus simple prêt pour la production ?
Un orchestrateur avec deux travailleurs, tous deux avec des critères d'acceptation déterministes. L'orchestrateur possède l'état partagé. Les travailleurs reçoivent des briefings cadrés. Les sorties sont validées contre un schéma avant que l'orchestrateur ne les accepte. Cela suffit à capturer la plupart du bénéfice de la décomposition sans la surcharge de coordination des équipes plus grandes. N'augmentez le nombre de travailleurs qu'après que cette base soit fiable.
Le coût en tokens de 15x en vaut-il la peine ?
Cela dépend de la valeur de la sortie. Le système de recherche d'Anthropic a un sens économique parce que l'alternative est un chercheur humain qui passe des heures sur la même tâche. Pour du travail à faible valeur et fort volume (classification d'intention, résumé simple, extraction routinière), un coût en tokens de 15x n'en vaut presque jamais la peine ; utilisez une configuration mono-agent ou un modèle plus petit. Pour du travail à forte valeur et faible volume (recherche approfondie, tâches de codage complexes, analyse multi-sources), le calcul tient souvent.
Comment savoir quand faire émerger un sous-agent plutôt que d'utiliser un prompt plus long ?
Faites émerger un sous-agent quand le travail a une exigence de contexte différente de la tâche parente. Si la sous-tâche a besoin d'outils différents, d'un prompt système différent ou de contexte qui polluerait la fenêtre du parent, donnez-lui son propre agent. Si la sous-tâche est « fais juste cette prochaine chose » et partage le contexte du parent, un prompt plus long ou un appel d'outil est moins cher et plus fiable. La question décisive concerne généralement le contexte : voudrais-je que ce contexte soit dans la mémoire de mon orchestrateur après que la sous-tâche est terminée ?
Quelle est la différence entre un agent et un outil IA ?
Un outil est une capacité déterministe unique que le modèle peut appeler (une recherche web, une requête de base de données, un formateur de code). Un agent est une boucle : il observe, planifie, appelle des outils, évalue le résultat et décide quoi faire ensuite, souvent sur de nombreux tours. Les outils sont des noms ; les agents sont des verbes. Un agent bien construit utilise de nombreux outils. Un « outil » qui appelle un modèle en interne et fait tourner sa propre boucle est, en pratique, un agent.
En conclusion
Le cadrage le plus utile que j'ai entendu pour le moment présent venait d'un leader d'ingénierie pilotant un déploiement de codage multi-agents : « Nous avons cessé de penser aux agents comme étant intelligents et avons commencé à les considérer comme des juniors avec une endurance infinie. » Les juniors ont besoin de rôles clairs, de briefings écrits, de critères d'acceptation définis et d'un chemin d'escalade. Ils commettent des erreurs prévisibles. Ils s'améliorent avec les retours. Ils échouent quand personne ne possède leur travail.
C'est le glissement de conception organisationnelle qui se cache à l'intérieur de la conversation multi-agents. Les problèmes difficiles de 2025-2026 ne sont plus des problèmes de capacité. Les modèles sont assez bons. Les problèmes difficiles sont les mêmes que ceux qui ont toujours rendu les équipes d'humains difficiles à diriger : qui possède quoi, qui détient l'état, qui vérifie le travail, qui est responsable quand ça tourne mal. La taxonomie de Cemri, le cadre d'autonomie, le schéma orchestrateur-travailleur, le post-mortem de Devin, le modèle d'isolation de Cursor : ce sont toutes des réponses à des versions de la même question.
Si vous êtes un fondateur qui livre un produit piloté par agents en 2026, les artefacts ennuyeux sont le levier. Écrivez les rôles. Écrivez les briefings. Définissez terminé. Construisez l'isolation de l'espace de travail. Instrumentez les traces. Gardez l'humain dans la boucle là où cela compte. Les équipes qui font cela paraîtront plus lentes pendant deux mois et plus rapides pendant deux ans. Les équipes qui sautent cette étape passeront le reste de l'année à étiqueter des modes de défaillance contre une taxonomie que quelqu'un d'autre a déjà écrite.
Les agents sont des coéquipiers maintenant. Gérez-les comme tels.