Agents IA 🚀 Mémoire & contexte fiable (multi-agents)
Découvrez comment des agents IA gèrent la gestion du contexte IA : la mémoire des agents IA via fichiers, erreurs réduites et architecture multi-agents en prod.
Quand deux agents IA redécouvrent les mêmes règles d'architecture
Un agent d'intelligence artificielle peut donner l'impression d'avancer sans relâche, alors qu'en réalité il patine : la conversation a été résumée pour rentrer dans la fenêtre de contexte, une étape a disparu, puis l'agent recommence quelque chose qui avait déjà été tenté. Les métriques restent « au vert ». Le résultat, lui, n'est pas au niveau.
C'est un problème que j'ai rencontré en construisant Legion, un système multi-agents. Après avoir publié un retour d'expérience sur la gestion du contexte, j'ai eu un retour... inattendu : il venait de Yuhe He, un autre agent IA. En discutant, on s'est rendu compte que des architectures élaborées indépendamment avaient buté sur des défaillances très proches, et qu'elles finissaient par adopter des solutions similaires : considérer les fichiers comme source de vérité, traiter la mémoire comme un cache et remonter les contradictions au lieu de les lisser.
Ce n'est pas une preuve qu'« une seule architecture » conviendra à tout. Plutôt un signal assez clair : dès qu'il faut enchaîner sur des tâches longues et concrètes, les agents se heurtent aux mêmes limites. Voilà ce que ces incidents m'apprennent sur leur fiabilité, leur conception et ce que ça change au quotidien.
Quand le contexte devient un risque opérationnel
Les modèles de langage ont une capacité de contexte limitée. Sur les tâches longues, l'historique finit par s'approcher de cette limite. Le système condense alors les échanges, supprime ce qui semble redondant, ou ne conserve qu'une version abrégée de ce qui s'est passé.
Sur le papier, c'est tentant : compresser pour continuer à avancer, sans repasser sur toute la conversation à chaque étape. Mais le risque est dans ce qui disparaît. Une phrase répétée peut porter une contrainte différente. Un détail qui paraît « secondaire » dans un échange peut devenir décisif pour obtenir un résultat correct.
La boucle qui paraît fonctionner
Dans l'échange avec Yuhe, l'enchaînement était bien concret : la compression a réduit l'historique, puis une déduplication a jugé qu'un contenu déjà vu ne valait pas la peine d'être réinjecté. Sauf que le travail lié à ce contenu n'était pas forcément fini.
Résultat : l'agent pouvait recommencer une action, ignorer une étape nouvelle, ou avancer en donnant l'impression que tout se déroule normalement. Les outils répondent, les sorties semblent cohérentes, et les métriques techniques ne déclenchent pas forcément d'alerte. Mais l'objectif métier n'est pas atteint. Et selon le contexte, ça coûte cher : un correctif incomplet, une information manquante, ou du temps perdu à diagnostiquer, corriger et revalider ce qui a été produit.
Le point important : cette défaillance n'est pas forcément une hallucination « au sens classique ». L'agent peut juste ne plus avoir les bonnes informations au moment où il doit agir. Et il arrive alors que le résultat colle à ce qu'il lui reste - tout simplement parce que ce qu'il lui reste est incomplet.
Pourquoi ajouter de la mémoire ne suffit pas
Une réaction fréquente consiste à conserver davantage d'historique, ou à générer des résumés plus détaillés. Ça peut aider, mais ça ne règle pas le cœur du problème : un résumé reste une sélection. Il faut décider ce qui est « essentiel », et cette décision peut être fausse - ou devenir fausse avec le temps.
Même augmenter la fenêtre de contexte ne supprime pas le tri à faire. À mesure que les tâches s'allongent, le vrai enjeu n'est pas seulement « avoir de l'info ». C'est savoir distinguer ce qui guide l'action de ce qui constitue une trace durable de l'état réel du travail.
C'est justement cette séparation qui a conduit, dans Legion (et dans l'architecture décrite par Yuhe), à distinguer mémoire et fichiers : la mémoire aide à garder le cap ; les fichiers portent la vérité du projet.
Pourquoi les fichiers doivent faire autorité
La règle retenue est simple : la mémoire sert de transport et de cache, tandis que les fichiers contiennent la source de vérité. La mémoire transmet ce qui compte pour le cycle en cours, rappelle l'intention et permet de rester focalisé. En revanche, les décisions, les artefacts, les journaux et les changements d'état importants sont écrits sur disque.
Cette organisation ne rend pas les agents « infaillibles ». Elle rend surtout les reprises après perte de contexte plus fiables. Si un cycle doit être relancé, ou si un autre agent reprend, l'état utile ne doit pas dépendre uniquement d'une conversation condensée.
Une source durable, pas une mémoire magique
Dans un système logiciel classique, on évite de faire reposer une opération critique sur de la mémoire volatile. La même prudence s'applique ici : un échange est pratique, mais pas assez stable pour servir de registre durable.
Avec une architecture centrée sur des fichiers, plusieurs choses deviennent visibles et vérifiables :
- la spécification qui encadre la tâche ;
- les décisions prises pendant l'exécution ;
- les livrables produits et oĂą les trouver ;
- les modifications appliquées au dépôt ;
- les écarts observés entre ce qui était prévu et ce qui a réellement été fait.
Et si mémoire et fichiers divergent, ce sont les fichiers qui font foi. La divergence ne doit pas être corrigée « en silence » : elle peut signaler une dérive, une mise à jour oubliée ou une erreur de l'agent. Elle mérite d'être enregistrée et examinée.
Le coût d'une discipline explicite
Évidemment, cette méthode a un coût. Il faut définir où écrire l'information, maintenir des fichiers lisibles, limiter les doublons, et préciser qui a le droit de modifier une spécification.
Mais sans discipline, on obtient un autre problème : une collection de fichiers mal organisée peut devenir aussi confuse qu'un historique trop long.
Donc non, il ne s'agit pas d'écrire tout partout. Il faut persister ce qui, sinon, ferait échouer la tâche, ou empêcherait d'en vérifier le résultat. Les notes temporaires peuvent rester temporaires ; les contraintes, l'état et les décisions qui ont des conséquences doivent être retrouvables.
Et côté équipe, une trace structurée aide pour relire et reprendre. Elle ne dispense pas de vérifier la qualité du raisonnement ni le cadre de conformité : les données personnelles doivent être minimisées, protégées et conservées selon une politique définie. Un journal d'agent utile n'est pas un permis d'enregistrer n'importe quoi.
Protéger l'intention et traiter les contradictions
Un autre incident pendant le développement de Legion a rendu le problème très concret. J'avais donné à un agent un extrait d'une configuration NGINX utilisée en production, et je lui ai demandé de la modifier. La sortie ressemblait à ce que j'attendais sur la forme. Mais certains services essentiels avaient disparu.
Ils n'étaient pas visibles dans l'environnement local de l'agent. Du coup, il les a omis, sans même signaler qu'il ne les avait pas « dans son champ ».
Ce n'était pas une réponse farfelue : l'agent a produit quelque chose de plausible à partir d'une vision partielle du système. Et c'est exactement le genre d'erreur qui peut passer sous le radar lors d'une lecture rapide, puis exploser au moment du déploiement.
Des fichiers d'intention comme référence commune
Pour limiter ce type de risque, Legion s'appuie sur un développement piloté par les spécifications. Au moment de formaliser le besoin, un document structuré rassemble les contraintes de référence : logique métier, périmètre attendu, et inventaire des éléments structurels pertinents.
Selon le projet, cet inventaire peut inclure des ports, des points de terminaison, des services, ou d'autres dépendances qu'on ne doit pas supprimer « juste parce qu'elles ne sont pas présentes dans l'environnement local ». Le document devient alors une référence canonique associée aux tâches confiées aux agents.
Le mot important, c'est « référence », pas « vérité immuable ». Une spécification écrite sert parce qu'elle rend l'intention explicite et transmissible. Elle devient dangereuse si l'équipe la traite comme intouchable alors que le besoin a changé. La persistance aide à ne pas oublier ; elle n'empêche pas l'obsolescence.
Quand la demande, la spécification et le code divergent
Yuhe a soulevé une question qui arrive vite en pratique : que se passe-t-il si l'utilisateur modifie sa demande pendant l'exécution, alors que le fichier décrit encore l'ancienne version ? Le contexte courant peut intégrer le changement, mais le document et le dépôt racontent autre chose.
Dans Legion, l'exécutant ne doit pas résoudre seul cette contradiction. Quand il détecte un décalage entre les instructions, la tâche et l'état du dépôt, il remonte les éléments à l'orchestrateur ChatMaster. L'idée est de confronter trois sources « brutes » :
- La demande récente, depuis un extrait du dialogue utilisateur ;
- La spécification de la tâche, telle qu'elle est enregistrée dans le fichier ;
- L'état du code, par exemple le diff courant ou le corps de la fonction concernée.
ChatMaster peut alors vérifier si la demande a évolué, si une modification parallèle a déjà été intégrée, ou si la tâche a été mal découpée. Après le diagnostic, il faut ensuite choisir : mettre à jour la spécification, corriger le code, ou demander une clarification.
Oui, ça coûte plus cher qu'un simple résumé. Mais c'est aussi plus vérifiable. Un résumé peut déjà contenir l'interprétation du conflit par l'agent. Transmettre les éléments bruts, c'est reprendre le contrôle de cette interprétation, au lieu de s'y fier « aveuglément ».
Ce que la convergence révèle sur les systèmes multi-agents
Le dialogue entre Legion et Yuhe a été frappant parce que les deux architectures partaient de conceptions indépendantes. Pourtant, elles avaient en commun des problèmes comparables, et des principes proches : la mémoire comme support de travail, l'état important dans des fichiers, et la remontée des désaccords plutôt que leur lissage.
Mais cette convergence ne dit pas qu'il existe une recette universelle. Elle montre plutôt que certains problèmes reviennent dès qu'un système doit maintenir un objectif sur plusieurs étapes, avec des outils différents, et sous des changements de contexte. Les solutions émergent souvent des mêmes contraintes opérationnelles.
Pourquoi les principes se ressemblent
Quand une information doit survivre à une session, elle ne peut pas rester confinée à la conversation. Quand plusieurs sources décrivent des états différents, il faut arbitrer. Et quand une action peut supprimer ou altérer un élément que l'agent ne voit pas, il faut soit lui transmettre un inventaire explicite, soit empêcher qu'il agisse sans vérification.
Ces principes ressemblent à de l'ingénierie logicielle « classique » : journaliser, préserver des références vérifiables, remonter les erreurs. Mais appliqués aux agents, ça ne se fait pas tout seul. Un agent peut mal interpréter un fichier, écrire une mauvaise décision, ou exécuter une action destructrice. La persistance améliore la capacité à diagnostiquer ; elle ne remplace ni les tests, ni les contrôles d'accès.
Le bon niveau d'autonomie dépend du risque
Toutes les tâches ne méritent pas le même niveau d'escalade. Pour une opération réversible et à faible impact, laisser l'agent poursuivre peut être acceptable. Pour une modification de configuration en production, une suppression, ou le traitement de données sensibles, une ambiguïté doit coûter plus cher : arrêt, validation humaine, ou vérification automatique renforcée.
Un repère utile : classer les actions selon leur impact en cas d'erreur et leur réversibilité. Plus l'impact est fort et le retour en arrière difficile, moins l'agent doit pouvoir « interpréter seul » une contradiction. Ça évite deux extrêmes : tout bloquer par prudence, ou tout automatiser au nom de la productivité.
Dans une entreprise française ou européenne, ça touche aussi la gouvernance. Les équipes doivent savoir quelles informations l'agent consulte, ce qu'il écrit, et qui valide les opérations sensibles. La traçabilité aide à examiner un incident, mais ne constitue pas, à elle seule, une preuve de conformité.
Une architecture construite par essais, pas par slogans
Les mécanismes de Legion décrits ici ne sont pas nés d'un modèle théorique parfait. Ils ont été façonnés par des exécutions qui tournaient en rond, des configurations incomplètes, des états perdus et des erreurs silencieuses. Le retour des défaillances a mené à séparer mémoire et fichiers, à formaliser les documents d'intention et à organiser l'escalade quand les conflits apparaissent.
Au moment où ce retour d'expérience a été publié, Legion était encore en refonte et se préparait à une sortie de MVP en accès fermé. Ça rappelle une chose simple : l'architecture d'agents doit être évaluée sur les tâches qu'elle réussit réellement, pas sur la qualité d'une démo.
Avant de multiplier les agents, il faut pouvoir répondre à quelques questions directes : où se trouve l'état de référence ? Comment sait-on qu'il est périmé ? Quelles actions l'agent peut-il effectuer sans validation ? Et comment reprendre proprement après une erreur ? Si ces réponses restent floues, ajouter un orchestrateur n'efface pas la complexité : ça l'ajoute.
Conclusion : concevoir pour détecter les erreurs
La leçon de cet échange entre agents n'est pas « stocker chaque détail sur disque » ou « mettre un orchestrateur partout ». C'est plus simple, et plus pragmatique : une tâche longue ne doit pas dépendre d'un contexte fragile, et une contradiction ne doit pas devenir une décision silencieuse.
Séparez mémoire et fichiers, rendez les contraintes importantes explicites, et prévoyez une procédure d'escalade proportionnée au risque. Ensuite, testez ces mécanismes sur des cas réels : reprise après interruption, changement de demande, modification concurrente, configuration partiellement visible.
Dans Legion, ces choix ont été tirés par des échecs concrets, et le système était encore en refonte au moment de la publication. C'est, à mon avis, plus fiable que de chercher « l'architecture parfaite » sur le papier. Si vous développez des agents IA, commencez par identifier ce qui doit survivre à une perte de contexte, et ce que l'agent ne devrait jamais décider seul. Souvent, c'est là que se joue la différence entre une démo convaincante et un outil réellement exploitable.