**
Une idée architecturale largement répandue dans la communauté IA égare de nombreuses équipes.
La conclusion d'abord
Si vous envisagez de nommer plusieurs Agents IA « Chef de produit », « Architecte » et « Ingénieur test », et de leur faire passer des documents et collaborer comme des départements d'entreprise — arrêtez, s'il vous plaît.
Ce modèle semble intuitif et logique, mais il présente des défauts fondamentaux en ingénierie. Plus important encore, aucun des trois grands fournisseurs — Anthropic, OpenAI et Google — n'utilise ce modèle pour construire ses propres systèmes d'agents.
Ce n'est pas une coïncidence.
Qu'est-ce que l'architecture « Trois départements et six ministères » ?
Cette métaphore désigne une classe d'idées de conception multi-agents largement populaires dans la communauté, connues sous différents noms dans divers frameworks et articles : agents basés sur des rôles, équipes virtuelles, division du travail à la CrewAI, ou organisation à la MetaGPT. Cet article les regroupe sous le terme de modèle « Départementalisation ».
Le schéma central est le suivant : décomposer une tâche complexe en plusieurs fonctions, chaque Agent jouant un rôle — le PM pour les exigences, le Tech Lead pour l'architecture, le Dev pour l'implémentation, et le QA pour les tests. Les tâches circulent entre les Agents comme sur une chaîne de montage.
Ce modèle est très séduisant sur un diagramme. Il satisfait l'intuition humaine de la « division du travail » et rend le concept d'« équipe IA » concret et explicable. Des frameworks comme CrewAI ont accumulé de nombreux utilisateurs grâce à cela.
Le problème, c'est que cela résout les goulots d'étranglement humains, pas ceux de l'IA.
Pourquoi cette analogie est fondamentalement erronée
Les humains ont besoin de la division du travail parce que :
- Une seule personne a une attention limitée et ne peut pas traiter toutes les informations simultanément.
- Les humains ont des barrières professionnelles et des coûts d'apprentissage/de changement élevés.
- Les humains ont besoin d'interfaces pour se coordonner entre eux.
Mais les caractéristiques des LLM sont complètement différentes :
- Le même modèle peut écrire à la fois des PRD et du code ; il n'y a pas de « frontières professionnelles ».
- Le goulot d'étranglement des modèles n'est pas la capacité d'attention, mais la profondeur de raisonnement et l'intégrité des informations.
- Les modèles n'ont ni « culture » ni « compréhension implicite » pour compenser la perte d'information.
Étiqueter un Agent comme « Chef de produit » ne le rend pas plus professionnel — cela l'incite à refuser de franchir les frontières. Un Agent cantonné au rôle d'« Ingénieur test » pourrait ignorer un problème architectural parce que « ce n'est pas dans mon périmètre ». Le raisonnement le plus précieux se produit souvent aux frontières, et le modèle Départementalisation verrouille cette possibilité au niveau du système.
Le jeu de rôle crée des frontières artificielles. C'est le premier problème.
Le deuxième problème : l'information meurt en transit
Dans le modèle Départementalisation, l'Agent A produit un document et le transmet à l'Agent B.
Ce processus transmet des conclusions, pas le processus de raisonnement.
B reçoit le document, le réinterprète et reconstruit le contexte. L'intention originale se dégrade, les hypothèses cachées sont perdues, et chaque transfert accumule des erreurs. Plus le flux de travail est long, plus le résultat final devient « localement correct mais globalement déviant » — chaque nœud semble raisonnable, mais l'ensemble s'est écarté de l'objectif initial.
Les organisations humaines s'appuient sur les réunions, la culture et la communication informelle pour compenser cette perte d'information. Les Agents ne disposent pas de ces mécanismes.
Il y a une objection courante : les solutions des trois grands fournisseurs (progress.txt, fichiers de spécifications, runbooks) n'impliquent-elles pas aussi le « transfert de fichiers » ? Quelle est la différence ?
La différence réside dans qui écrit, à qui c'est destiné, et comment c'est mis à jour.
Le flux d'information départementalisé est un transfert unidirectionnel entre rôles : A termine et donne à B ; B ne regarde pas en arrière, et A ne sait pas comment B a utilisé le document. L'information est compressée en conclusions, le processus de raisonnement est perdu, et le transfert est un point de rupture.
Les fichiers d'état externes sont des journaux incrémentaux de la même tâche : L'entité exécutante ajoute au même enregistrement à chaque point de contrôle, et la session suivante lit l'historique complet de la tâche, pas la conclusion de sortie d'un « collègue » précédent. La personne qui écrit l'état et celle qui le lit sont le même rôle, juste à des moments différents. L'information n'est pas « compressée et transmise » ; elle est « continuellement accumulée ».
Cette différence détermine si la chaîne de raisonnement peut rester continue entre les sessions.
Une quantité massive de tokens est gaspillée dans des « fichiers de transfert » entre Agents plutôt que dans le raisonnement réel. Vous obtenez un système qui simule le comportement d'une entreprise, pas un système qui résout des problèmes.
Comment les trois grands fournisseurs procèdent-ils réellement
Il est notable que lorsqu'Anthropic, OpenAI et Google construisent leurs systèmes d'agents de qualité production, leurs documents d'ingénierie ne mentionnent presque jamais le « jeu de rôle » ou la « division départementale ».
Anthropic : Ingénierie du contexte + Fichiers d'état explicites
Anthropic a fait passer le « Prompt Engineering » à l'« Ingénierie du contexte » : La question n'est pas comment écrire un bon prompt, mais quelle configuration de tokens produit le mieux le comportement souhaité.
Lors de la construction des systèmes Claude Code et Research, leur défi central était : les Agents doivent travailler en sessions discrètes, et chaque nouvelle session n'a aucune mémoire de ce qui s'est passé avant. Leur métaphore est celle des « ingénieurs d'équipe » — chaque nouvelle équipe d'ingénieurs ne sait rien du travail de l'équipe précédente.
La solution n'est pas de faire jouer différents rôles aux Agents, mais :
- claude-progress.txt : Un journal de travail inter-sessions que l'Agent met à jour à la fin de chaque session et lit au début de la suivante.
- L'historique Git : Servant de points d'ancrage d'état, enregistrant chaque modification incrémentale.
- L'Agent Initializer : S'exécute uniquement dans la première session pour configurer l'environnement, développer la liste des fonctionnalités et rédiger le runbook pour toutes les sessions suivantes.
Point clé : La continuité de la chaîne de raisonnement ne repose pas sur la « mémoire » du modèle ; elle repose sur un état externe explicite pour l'ancrer.
Ils ont également constaté que coder en dur des « hypothèses de capacité du modèle » dans le harnais est dangereux. Sonnet 4.5 avait une « anxiété de contexte » — il concluait prématurément lorsqu'il approchait de la limite de contexte, ils ont donc ajouté une réinitialisation de contexte au harnais. Mais dans Opus 4.5, ce comportement a disparu, et la réinitialisation est devenue un poids mort. Cela montre que le harnais doit évoluer avec le modèle ; toute « solution permanente » n'est qu'un compromis d'ingénierie pour l'étape actuelle.
Dans les systèmes de Recherche multi-agents, l'architecture d'Anthropic est orchestrateur-travailleur : un agent principal décompose les tâches et coordonne les sous-agents, qui explorent différentes directions en parallèle, les résultats revenant à l'agent principal pour synthèse. Ils ont constaté que la consommation de tokens expliquait à elle seule 80 % des différences de performance — la valeur des multi-agents n'est pas la « division du travail », mais l'utilisation de plus de tokens pour couvrir un espace de recherche plus vaste.
Il y a un point de confusion ici : les sous-agents d'Anthropic peuvent ressembler à une « division du travail », mais l'essence est différente. La départementalisation est une division fonctionnelle — différents rôles gèrent différents types de travail (PM vers Dev vers QA). Les sous-agents d'Anthropic sont un parallélisme fonctionnel — plusieurs agents identiques recherchent différentes directions simultanément, il n'y a pas de « passage de relais », et tous les résultats convergent vers le même orchestrateur. Le premier est une course de relais ; le second est un large coup de filet.
OpenAI : Compaction + Compétences + Fichiers de spécifications structurés
Les principes d'OpenAI pour les tâches à long terme sont encore plus directs : planifier la continuité au début de la tâche.
Dans leurs expériences Codex, les ingénieurs ont donné à l'agent un fichier de spécifications (gelant l'objectif pour empêcher l'agent de faire quelque chose d'« impressionnant mais dans la mauvaise direction »), lui ont fait générer un plan basé sur des jalons, puis ont utilisé un fichier runbook pour indiquer à l'agent comment opérer. Ce runbook est également une mémoire partagée et un journal d'audit.
Résultat : GPT-5.3-Codex a fonctionné pendant environ 25 heures en continu, complétant un outil de conception complet tout en maintenant la cohérence tout au long.
La compaction côté serveur sert de primitive par défaut, pas de solution de repli d'urgence. Dans les tâches en plusieurs étapes, previous_response_id permet au modèle de continuer à travailler dans le même fil plutôt que de reconstruire le contexte à chaque fois.
Ils ont également introduit le concept de Compétences — des ensembles d'instructions réutilisables et versionnés montés dans des conteneurs, donnant aux agents des normes opérationnelles stables pour des tâches spécifiques. Ce ne sont pas des « rôles » ; ce sont des outils et des procédures opérationnelles, ce qui est fondamentalement différent.
Google : 1M de contexte + Développement piloté par le contexte
La direction de Google est de forcer la fenêtre : le contexte de 1M de tokens de Gemini est une stratégie de différenciation claire. Leur logique est que les techniques auparavant forcées comme le découpage RAG et la suppression des anciens messages peuvent être remplacées par « tout mettre dedans » avec une fenêtre suffisamment grande.
Mais ils admettent que même cela ne suffit pas. Google a lancé l'extension Conductor pour Gemini CLI, avec une idée centrale identique à celle d'Anthropic : déplacer l'intention du projet hors de la fenêtre de chat et dans des fichiers Markdown persistants dans la base de code. La philosophie : « Ne vous fiez pas à l'historique de chat instable ; fiez-vous aux fichiers de spécifications et de plans formels. »
Gemini 3 a également introduit les Signatures de Pensée : sauvegarder les nœuds clés de la chaîne de raisonnement dans les longues sessions pour éviter la « dérive du raisonnement » — le problème d'incohérence logique dans les longs contextes.
Quels sont les véritables principes architecturaux ?
À partir des pratiques d'ingénierie de ces trois entreprises, plusieurs principes communs peuvent être extraits :
La chaîne de raisonnement ne peut pas être rompue ; elle ne peut que bifurquer et fusionner. La bonne utilisation des multi-agents n'est pas une chaîne de montage, mais un agent principal détenant l'intention complète, utilisant des sous-appels pour approfondir les sous-problèmes, et les résultats revenant à l'agent principal, pas transmis à l'agent suivant.
État externe explicite, ne pas compter sur la mémoire du modèle. Que ce soit progress.txt, l'historique Git, les fichiers de spécifications ou les bases de données — la forme importe peu. Le principe est : les nœuds clés de la chaîne de raisonnement doivent être externalisés vers un stockage persistant.
La valeur des multi-agents est la couverture parallèle, pas la division du travail. La conclusion du système de Recherche d'Anthropic est claire : les gains de performance proviennent de « dépenser plus de tokens », pas d'une « meilleure division du travail ». Les multi-agents sont adaptés aux tâches en largeur d'abord — des scénarios nécessitant l'exploration simultanée de directions indépendantes. Ils ne sont pas adaptés aux scénarios nécessitant un raisonnement continu et une dépendance profonde au contexte.
L'Agent Vérificateur est un contradicteur, pas un relayeur. Si vous utilisez des multi-agents pour le contrôle qualité, la conception correcte est d'avoir un Agent qui trouve spécifiquement des problèmes dans le travail d'un autre, plutôt que de « passer le résultat du travail ». Tests adversariaux, pas transfert sur chaîne de montage.
Les outils sont des outils, pas des rôles. Les outils dont vous équipez un Agent (bash, entrée/sortie fichier, recherche, exécution de code) sont bien plus importants que l'étiquette que vous lui collez. Les outils déterminent ce qu'un Agent peut faire ; les étiquettes de rôle ne font que limiter ce qu'il est prêt à faire.
Pourquoi le modèle « Départementalisation » est-il populaire ?
Parce qu'il est facile à expliquer.
« Cet Agent est le PM, celui-là est le QA » — tout le monde peut comprendre cela. Cela satisfait le désir humain d'explicabilité des systèmes d'IA et l'imagination de la direction d'une « IA qui travaille comme une équipe ».
Il est aussi facile à démontrer. Dessiné comme un organigramme avec des départements, des flèches et des transferts, c'est très intuitif.
Mais être facile à expliquer et à démontrer est différent d'être solide sur le plan de l'ingénierie.
Une raison plus profonde est que la plupart des équipes adoptant ce modèle n'ont pas vraiment fait face au problème de la « perte de contexte lors du transfert multi-agents ». Leurs tâches ne sont peut-être pas assez complexes, ou le problème est masqué par d'autres facteurs. Une fois que la complexité des tâches augmente et que le système commence à montrer des erreurs « localement correctes mais globalement fausses », le problème est exposé.
Conseils pratiques
Le meilleur système multi-agents ne ressemble pas à une entreprise. Il ressemble davantage aux multiples brouillons d'un penseur — le même cerveau étendant le raisonnement sur différentes dimensions et les fusionnant finalement en une conclusion cohérente.
Sur la base de ce principe :
Ne demandez pas « De combien d'Agents ai-je besoin ? » ; demandez « Quelle est la structure de dépendance informationnelle de cette tâche ? »
Si une tâche nécessite un raisonnement continu et une forte dépendance au contexte (par exemple, rédiger un document de conception pour une fonctionnalité complexe), un seul Agent + une bonne ingénierie du contexte est généralement supérieur aux multi-agents.
Si une tâche nécessite l'exploration simultanée de directions indépendantes (par exemple, rechercher 10 concurrents simultanément), le parallélisme multi-agents est raisonnable — la tâche de chaque sous-agent est indépendante, et le coût de la perte d'information est minimisé.
Si une tâche s'étend sur plusieurs sessions, les fichiers d'état externes sont obligatoires. Un fichier d'état efficace doit contenir quatre types d'informations :
- Objectif de la tâche (Invariant, lu au début de la session pour éviter la dérive)
- Étapes accomplies (Ajoutées, pas écrasées, pour conserver l'historique complet)
- État actuel (Écrasé pour refléter la progression la plus récente)
- Pièges connus (Ajoutés pour éviter de répéter les erreurs dans la session suivante)
Ces quatre types d'informations, maintenus séparément et combinés, fournissent le contexte complet nécessaire au « soi suivant ».
Si vous ajoutez une étape de vérification, faites en sorte que la seule tâche de l'Agent Vérificateur soit de trouver des problèmes, pas de « prendre le relais et continuer ». Tests adversariaux, pas transfert sur chaîne de montage.
Enfin : Les capacités des modèles s'améliorent rapidement. Les solutions de contournement nécessaires dans le harnais aujourd'hui pourraient devenir un poids mort dans six mois. Anthropic l'a déjà prouvé — l'anxiété de contexte de Sonnet 4.5 a disparu dans Opus 4.5. Maintenir l'évolutivité architecturale est plus important que de choisir une « architecture parfaite ».
La départementalisation est une illusion agréable mais coûteuse sur le plan de l'ingénierie. Son véritable coût n'est pas l'échec direct, mais le fait qu'elle amène votre système à se dégrader de manière difficile à diagnostiquer à mesure que la complexité augmente — où chaque nœud « semble fonctionner », mais l'ensemble dérive.
Au moment où vous trouvez le problème, la chaîne de montage est déjà très longue.
Références : Anthropic Engineering Blog (Building Effective Agents, Effective Context Engineering, Multi-Agent Research System, Effective Harnesses for Long-Running Agents, Managed Agents) ; OpenAI Developers Blog (Run Long Horizon Tasks with Codex, Shell + Skills + Compaction) ; Google Developers Blog (Architecting Efficient Context-Aware Multi-Agent Framework, Conductor: Context-Driven Development for Gemini CLI)
