Le problème que personne n'a nommé : comment dix agents peuvent ignorer ce qu'un seul sait déjà

Il y a une scène qui se répète dans les équipes qui déploient leurs premiers systèmes multi-agents. On assemble un orchestrateur, des agents spécialisés — l'un pour la revue de code, un autre pour les tests, un troisième pour la documentation — et on s'attend à ce que le tout soit plus intelligent que la somme des parties. Les premières heures sont prometteuses. Puis, au troisième jour, l'agent de revue pose la même question sur l'architecture de la base de données que l'agent de tests avait déjà posée la veille. La réponse avait été donnée, documentée dans l'historique de session, mais personne n'avait pensé à la transmettre.

C'est là que l'on découvre le paradoxe fondamental du context engineering multi-agents : multiplier les agents sans architecurer leur mémoire partagée ne produit pas de l'intelligence collective — cela produit dix versions du même employé qui repart de zéro chaque matin.

Patrick Debois, l'inventeur du terme DevOps et fondateur de Tessl, a formulé ce problème avec une précision qui devrait interpeller tout architecte de systèmes agentiques : « Chaque session est un nouvel employé — un employé qui repart de zéro, sans mémoire musculaire ni conversations de couloir. ».¹ L'absence de mémoire persistante n'est pas une contrainte technique passagère — c'est une décision d'architecture à prendre explicitement.

Pour aller plus loin sur les fondamentaux du context engineering, commencez par le guide complet et l'architecture 3 tiers.

Pourquoi dix agents n'en savent pas plus qu'un seul

Le problème de la mémoire dans un système multi-agents est contre-intuitif. On croit intuitivement que diviser le travail entre spécialistes produit plus de connaissance collective. C'est faux si chaque spécialiste commence sa journée sans héritage — sans les décisions prises la veille, sans les conventions établies la semaine dernière, sans les erreurs cataloguées le mois précédent.

Aristidis Vasilopoulos, chercheur indépendant, a documenté ce problème avec une rigueur empirique rare. Sur 283 sessions couvrant 70 jours, 2 801 prompts humains et 16 522 tours autonomes d'agents, il a mesuré ce phénomène : quand l'infrastructure contextuelle est correctement construite, 80 % des prompts humains font moins de 100 mots. Le contexte pré-chargé réduit le besoin d'explication.² Dans un système mal contextualisé, c'est l'ingénieur qui comble les lacunes de mémoire — à chaque session, pour chaque agent.

L'infrastructure contextuelle représente, dans cette même étude, 24,2 % de la documentation totale du projet — le coût de la mémoire organisationnelle rendue explicite. Ce chiffre reflète un choix d'architecture : soit le contexte est codifié, versionné, transmissible, soit il reste dans la tête des ingénieurs et se perd à chaque rotation d'équipe.

L'architecture 3 tiers de Vasilopoulos : Hot, Warm, Cold

La réponse la plus rigoureuse à ce problème a été formalisée par Vasilopoulos dans ce que l'on nomme désormais l'architecture 3 tiers du contexte — Hot Memory, Warm Memory, Cold Memory. Elle a été reprise et synthétisée par SFEIR dans sa doctrine Context Engineering comme le cadre de référence pour les systèmes agentiques en production.

La Hot Memory — la constitution toujours chargée

Le Tier 1 est un fichier Markdown unique — dans l'implémentation documentée par Vasilopoulos, 660 lignes. Il est toujours chargé en contexte, pour chaque session, pour chaque agent. Son contenu ne consiste pas en instructions comportementales génériques — il encode les conventions de nommage du projet, les commandes de build, les patterns architecturaux établis, les modes de défaillance connus, et surtout : les tables de routage vers les agents spécialisés. La Hot Memory dit à l'orchestrateur quand et vers quel expert déléguer.

C'est la « culture d'entreprise » de l'agent — la connaissance que tout nouvel entrant doit absorber immédiatement, avant même d'entreprendre la moindre tâche. Elle répond au problème du « nouvel employé » de Debois non pas en supprimant la nouveauté de chaque session, mais en compressant le savoir minimal indispensable en un artefact toujours disponible.

La Warm Memory — les experts invoqués à la demande

C'est ici que se joue l'essentiel du context engineering multi-agents. Le Tier 2, dans l'implémentation de Vasilopoulos, comprend 19 spécifications d'agents spécialisés pour un total de 9 300 lignes. Chacun couvre un domaine précis : revue de code, conception de protocoles réseau, gestion des RNG déterministes, synchronisation d'interface utilisateur.

La propriété la plus importante de ces agents spécialisés est leur composition interne : plus de la moitié de leur contenu est constitué de faits codebase — formules, patterns, modes de défaillance, cas limites documentés — plutôt que d'instructions comportementales. La matière SFEIR synthétise cela en une formule : « 50 % de faits, peu de directives. » Ce ratio n'est pas arbitraire. Un agent spécialisé dont le rôle est de transmettre de la connaissance à l'orchestrateur est plus utile s'il porte des faits que s'il porte des instructions — les instructions, l'orchestrateur les a déjà dans sa Hot Memory.³

La Cold Memory — la knowledge base tirée à la demande

Le Tier 3 complète l'architecture avec 34 documents de spécification (16 250 lignes dans l'implémentation de Vasilopoulos), récupérés uniquement à la demande via un serveur MCP — Model Context Protocol. La Cold Memory contient le savoir de référence massif : specs détaillées, documentation d'API, historiques de décisions architecturales. Elle n'est pas chargée par défaut. Charger l'intégralité de la knowledge base dans chaque session diluerait le signal et augmenterait le coût. On tire uniquement ce dont on a besoin, quand on en a besoin.

Pour une analyse détaillée de cette architecture, voir l'article dédié sur le CDLC.

La Warm Memory en pratique : ce que « 50 % de faits » veut dire concrètement

Les tables de déclenchement de la Hot Memory encodent une règle simple : face à un problème de domaine X, invoque l'agent spécialisé Y. Dans les 283 sessions analysées par Vasilopoulos, ce mécanisme a produit 1 197 invocations d'agents. Les deux agents les plus sollicités sont révélateurs : l'agent de revue de code (154 invocations) et l'agent de conception de protocoles réseau (85 invocations). Ces chiffres ne traduisent pas la popularité de ces fonctions — ils traduisent leur degré de spécialisation domaine. Ce sont précisément les questions où un généraliste improvisera et où un expert documenté, même s'il s'agit d'un fichier Markdown de 900 lignes, fera la différence.

L'exemple le plus frappant est le cas de l'agent RNG documenté par Vasilopoulos. Un sous-système de génération aléatoire déterministe posait des problèmes de synchronisation. Cinq tentatives avec l'agent généraliste n'avaient rien produit. Après la création d'un agent spécialisé de 915 lignes incorporant la théorie du déterminisme applicable, l'agent a identifié trois bugs subtils que toutes les tentatives précédentes avaient manqués. L'expertise n'était pas dans le modèle — elle était dans le contexte transmis à ce modèle.

C'est la définition opérationnelle de la Warm Memory : non pas un raccourci vers l'intelligence du modèle, mais un mécanisme de transmission de connaissance accumulée entre sessions et entre agents.

La documentation Anthropic sur les subagents (2025-09-29) confirme cette architecture : chaque subagent opère avec une fenêtre de contexte indépendante et des outils configurables spécifiques. Cette isolation empêche la pollution croisée de contextes entre agents — condition nécessaire pour que la spécialisation produise de la qualité plutôt que du bruit.

Mémoire de session, compaction et tool clearing : les trois angles morts

La question de la Warm Memory est relativement bien documentée. Trois problèmes opérationnels le sont beaucoup moins : la gestion de la mémoire de session quand elle déborde, la compaction du contexte, et le tool clearing. Ce sont ces angles morts qui transforment un système agentique prometteur en gouffre à tokens et en source d'erreurs incompréhensibles.

La compaction du contexte

Une fenêtre de contexte n'est pas infinie — même si les modèles les ont considérablement élargies ces deux dernières années. Quand une session longue approche de la limite, l'agent doit compacter : résumer les échanges passés pour libérer de l'espace. Le risque est évident — résumer peut signifier perdre des décisions structurantes prises trente échanges plus tôt.

Patrick Debois formule un avertissement que la communauté sous-estime : les fenêtres de contexte infinies ne résoudront pas ce problème. Elles le transforment. « Le défi passe de la curation à la gouvernance ».¹ Plus la fenêtre est large, plus le contexte peut contenir de contradictions, d'informations obsolètes et de bruit accumulé. La compaction intelligente — résumer les décisions plutôt que les échanges, préserver les faits codifiés plutôt que les discussions — est une compétence d'architecture à part entière.

Le tool clearing

Un outil activé dans le contexte d'un agent occupe de l'espace. Une page web chargée via un outil de navigation représente des dizaines de milliers de tokens d'entrée — l'activation de l'outil seul ajoute environ 4 300 tokens de contexte.⁴ Dans une session type, les lectures de fichiers représentent environ 96 % du contexte total : l'agent relit sans cesse ce qu'il a déjà ingéré. Le tool clearing — retirer du contexte les outils dont l'usage est terminé — n'est pas une optimisation marginale. C'est un levier de contrôle du signal.

La gestion de session en multi-agents

C'est le problème le plus sous-estimé de l'architecture multi-agents. Chaque sous-agent maintient sa propre fenêtre de contexte. N agents opérant en parallèle consomment de 7 à 15 fois les tokens d'une session simple.⁴ Cette multiplicité pose une question d'architecture fondamentale : que doit-on transmettre à chaque agent au démarrage d'une session ? La réponse courte : les décisions, pas les échanges. La Hot Memory porte les conventions. La Warm Memory porte les faits de domaine. Ce qui se transmet entre sessions, c'est le résultat — la spec créée, la décision prise, le bug catalogué — pas le chemin pour y arriver.

Pour les implications budgétaires de cette architecture, voir l'article sur le coût des tokens en context engineering.

Le Context Flywheel : quand partager devient un avantage concurrentiel

La vraie rupture n'est pas dans la première session bien contextualisée — c'est dans l'accumulation. Patrick Debois a nommé cet effet le Context Flywheel : un volant d'inertie contextuel qui s'emballe à chaque itération du CDLC (Context Development Lifecycle).¹

Le CDLC se décompose en quatre phases : Générer (rendre l'implicite explicite), Évaluer (TDD du contexte), Distribuer (versionner le contexte), Observer (lire les hésitations de l'agent en production comme des signaux de lacunes). Ce cycle, répété, produit un effet que Debois décrit précisément : la première itération capture les conventions, la deuxième corrige les lacunes, et à la dixième, un basculement s'opère — toute l'équipe code différemment, plus vite, plus cohérent, avec moins de corrections.

Quatre retours se composent simultanément : qualité des agents, expertise clarifiée pour l'ingénieur senior, patterns absorbables par les juniors, et terminologie partagée qui traverse les frontières d'équipes.

L'argument stratégique est brutal dans sa logique : les modèles se commoditisent, les outils convergent. Seul le contexte raffiné sur dix-huit mois crée un avantage que les concurrents ne peuvent pas répliquer. La matière SFEIR le quantifie : un développeur bien outillé équivaut à cinq développeurs traditionnels — vélocité ×5 — pour un coût de maintenance estimé à 1 à 2 heures par semaine.³

La doctrine SFEIR sur le CDLC et la dépendance au contexte détaille comment traiter le contexte comme un actif versionnable.

Risques et limites : quand le contexte partagé devient surface d'attaque

Partager le contexte entre agents multiplie non seulement la productivité — il multiplie aussi les risques. Il y a trois modes de défaillance spécifiques aux systèmes multi-agents que l'architecture doit anticiper.

Le contexte qui pourrit

Le principal mode de défaillance documenté par Vasilopoulos est contre-intuitif : ce ne sont pas les lacunes de contexte qui posent le plus de problèmes — c'est le contexte obsolète. Une spec périmée est pire que pas de spec : elle induit l'agent en erreur activement, avec une confiance que l'absence de spec n'aurait pas produite.³ Dans un système multi-agents, ce risque est amplifié : si un agent spécialisé porte une information devenue fausse, il la transmettra à l'orchestrateur avec la même assurance qu'une information correcte.

La surface d'attaque du contexte partagé

Le contexte partagé entre agents n'est pas seulement un vecteur de connaissance — c'est une surface d'attaque. Debois l'a formulé dans son CDLC : le contexte nécessite audit et contrôle d'accès, exactement comme une dépendance logicielle.¹ La matière SFEIR est tout aussi directe : « Le contexte nécessite audit et contrôle d'accès. C'est une faille potentielle. » Dans les architectures Agent Memory avec opérations lecture-écriture, un agent peut non seulement lire mais modifier la mémoire partagée. La corruption de mémoire dans ces systèmes n'est pas théorique : Monigatti documente ce risque dans son analyse de l'évolution des architectures mémoire.⁵

Pour une analyse approfondie des implications de sécurité, voir l'article sur la sécurisation du contexte des agents IA.

L'amplification des erreurs

La variabilité d'exécution dans un système agentique est structurelle : deux exécutions de la même tâche peuvent varier d'un facteur 30 en consommation de tokens.⁴ Dans un système multi-agents, cette variabilité se compose. Un agent orchestrateur qui reçoit des réponses différentes du même agent spécialisé selon la session prendra des décisions incohérentes. L'architecture contextuelle — en particulier la stabilité de la Hot Memory et la fraîcheur de la Warm Memory — est le premier levier pour réduire cette variance.

Cinq leviers pour déployer une Warm Memory robuste

De ces observations se dégagent cinq leviers concrets, validés par la pratique.

Commencer par une constitution basique, immédiatement. Vasilopoulos est explicite sur ce point dans sa première guideline : une constitution basique apporte des améliorations substantielles dès le jour 1. Il ne s'agit pas d'attendre d'avoir une architecture parfaite — il s'agit de commencer à externaliser la connaissance implicite dans un artefact explicite, aussi imparfait soit-il. La perfection est l'ennemie du contexte partagé.

Composer les agents spécialisés avec des faits, pas des instructions. Le ratio « 50 % de faits » de la Warm Memory n'est pas une contrainte arbitraire — c'est la propriété qui rend l'agent spécialisé transmissible. Une instruction comportementale n'a de sens que pour l'agent qui la reçoit. Un fait codebase — une formule, un mode de défaillance, un pattern documenté — a du sens pour n'importe quel agent qui le consulte. Construire la Warm Memory, c'est construire une encyclopédie de faits de domaine, pas un livre de règles.

Versionner le contexte comme une dépendance logicielle. Le contexte doit être traité comme un package npm ou maven — versionné, testé avant déploiement, déprécié avec intention. Les mises à jour de la Warm Memory passent par les mêmes revues que les mises à jour du code qu'elle documente.

Instrumenter la compaction des sessions longues. La compaction ne doit pas être laissée à la discrétion du modèle. La règle pratique : compacter les échanges, préserver les décisions. Les choix structurants — une décision d'architecture, une contrainte de sécurité — ne doivent pas être victimes de la compression.

Désigner un propriétaire du contexte. Sans ownership explicite, le contexte pourrit inévitablement (Debois, Context Flywheel). L'ownership repose sur trois piliers — maintenance (revue de fraîcheur, résolution de conflits), enablement (contribution facilitée en CI), gouvernance (seuil de qualité, politiques de dépréciation). Sans ces trois piliers, l'effet flywheel ne s'enclenche pas.

La question de l'évaluation du contexte — le TDD du contexte — est traitée dans l'article sur le maintien du contexte par TDD et évals.

Le point de vue SFEIR : l'ingénieur qui structure le meilleur contexte

La matière de SFEIR conclut son deck Context Engineering par une formule qui résume bien l'enjeu : « Le contexte est un actif, pas une dépense. L'ingénieur de demain ne sera pas celui qui écrit le meilleur code, mais celui qui structure le meilleur contexte. ».³

Cette formule n'est pas de la prospective — c'est une observation de terrain, construite sur l'analyse de 34 fiches de veille couvrant mai 2025 à février 2026. Le verrou des systèmes multi-agents n'est pas le modèle — le marché en offre plusieurs de qualité comparable — mais la capacité à construire et maintenir une infrastructure contextuelle robuste, partageable et sécurisée.

Le Harness Engineering documenté par SFEIR le confirme : à modèle égal, le harnais — guides feedforward et sensors feedback — fait gagner 20 points de performance ou davantage. La Warm Memory en est le cœur : elle nourrit les agents spécialisés, transmet la connaissance accumulée, et fait que la dixième itération est meilleure que la première sans que l'ingénieur ait réexpliqué quoi que ce soit.

Pour comprendre comment le context engineering s'articule avec le RAG ou le fine-tuning, voir l'article context engineering vs RAG et fine-tuning.

Dix agents qui savent ce qu'ils savent

Revenons à la scène du début : l'agent de revue qui pose la même question que l'agent de tests a posée la veille. Ce n'est pas un bug. C'est une architecture non prise. L'agent n'est pas stupide — il est amnésique, structurellement, parce que personne n'a décidé de lui donner accès à la mémoire de ses collègues.

L'architecture 3 tiers de Vasilopoulos, le Context Flywheel de Debois, la Warm Memory comme outil de transmission — ces concepts répondent à un problème que l'industrie commence seulement à nommer précisément. Le context engineering multi-agents n'est pas une extension du context engineering individuel : c'est une discipline à part entière, avec ses propres contraintes de compaction, de routage, de versioning et de gouvernance.

La bonne nouvelle est que les gains sont rapides. Une constitution basique améliore les sorties dès le jour 1. Des agents spécialisés bien composés débloquent des sessions qui stagnaient depuis des heures. Et l'effet flywheel, une fois lancé, transforme non pas un agent, mais toute une façon de travailler.

Le système multi-agents qui fonctionne n'est pas celui où chaque agent est le plus puissant — c'est celui où chaque agent sait précisément ce que les autres ont déjà établi.

Points clés

• L'architecture 3 tiers (Vasilopoulos, 2026) structure la mémoire en Hot Memory (constitution toujours chargée), Warm Memory (agents spécialisés invoqués à la demande, 50 % de faits) et Cold Memory (knowledge base via MCP) — c'est le cadre de référence pour le context engineering multi-agents.
• La Warm Memory n'est pas une liste d'instructions — c'est une base de faits de domaine (formules, patterns, modes de défaillance) transmissible entre agents et entre sessions.
• Les trois angles morts opérationnels : la compaction du contexte (résumer les décisions, pas les échanges), le tool clearing (purger les outils inactifs), et la gestion du surcoût multi-agents (7 à 15× les tokens d'une session simple).
• Le Context Flywheel (Debois, 2026) produit un avantage cumulé : à la 10e itération, ce n'est plus un agent qui s'améliore — c'est une façon de travailler collective. Les modèles se commoditisent ; le contexte raffiné sur 18 mois ne se réplique pas.
• Cinq leviers : commencer par une constitution basique dès le jour 1 ; composer la Warm Memory avec des faits ; versionner le contexte comme une dépendance ; instrumenter la compaction ; désigner un propriétaire du contexte.

Sources

1. Patrick Debois, Context Development Lifecycle — tessl.io, 19 février 2026.
2. Aristidis Vasilopoulos, Codified Context: Infrastructure for AI Agents in a Complex Codebase — arxiv.org, 24 février 2026.
3. SFEIR — Context Engineering, matière first-party, mars 2026.
4. SFEIR — Tokens & SDLC v3, matière first-party, 2026.
5. Leonie Monigatti, The Evolution from RAG to Agentic RAG to Agent Memory — leoniemonigatti.com, 3 novembre 2025.