Quand l'agent IA commence à oublier ce qu'il sait déjà

Avec Watchdog, la R&D d'Alien6 explore une question encore peu visible : comment mesurer, contenir et améliorer le travail des agents de développement sans sacrifier la qualité ni transformer leur gouvernance en système de surveillance ?

Le déclic n'est pas venu de la facture mensuelle. Il est apparu au cours d'une session devenue si volumineuse que l'agent consacrait une part croissante de son travail à retrouver ce qu'il savait déjà.

Les fichiers consultés, les résultats de tests, les sorties d'outils et les recherches déléguées s'étaient progressivement accumulés. Le modèle disposait de davantage d'informations, mais cela ne le rendait pas nécessairement plus pertinent. Le contexte, censé l'aider, commençait à devenir une charge.

Cette situation résume l'un des paradoxes de l'IA agentique : plus nous donnons de mémoire et d'autonomie à un agent, plus nous devons être capables d'observer la manière dont il les utilise.

C'est de cette expérience qu'est né Watchdog, un projet de R&D et d'expérimentation mené chez Alien6 autour de Claude Code.

Watchdog ne prétend pas apporter une réponse définitive à la gouvernance des agents. Il constitue d'abord un terrain d'essai. Son objectif est de comprendre les usages réels, d'identifier les dérives et de tester des mécanismes d'optimisation avant d'envisager leur généralisation.

Le contexte, cette dette que l'on ne voit pas

Un agent conversationnel ne mémorise pas une mission comme le ferait un humain. À chaque nouvelle étape, il doit retrouver les informations utiles dans un contexte composé de la conversation, des instructions du projet, des fichiers consultés et des résultats produits par ses outils.

Cette mémoire de travail a un coût. Plus elle grandit, plus les interactions deviennent lourdes. Une session finit parfois par contenir des résultats obsolètes, plusieurs lectures de la même ressource ou les recherches parallèles de différents sous-agents.

L'intuition voudrait qu'un contexte plus important rende nécessairement le modèle plus performant. Ce n'est pas toujours le cas. L'information utile peut se retrouver noyée dans le bruit. Le coût augmente alors que la qualité de la réponse stagne, voire se dégrade.

Le problème ne se résume donc pas au choix d'un modèle moins cher. Il faut déterminer quel niveau d'intelligence mobiliser, avec quelle quantité d'information et pour quelle tâche.

Watchdog commence par rendre ces phénomènes visibles. Son tableau de bord restitue les coûts par projet, session et modèle. Il suit l'évolution du contexte, distingue les différentes formes de cache et mesure la part consommée par les sous-agents.

Une dépense inhabituelle cesse alors d'être une simple ligne sur une facture. Elle devient un signal technique. Elle peut révéler une session trop longue, une délégation excessive ou un workflow qui mériterait d'être repensé.

Mais mesurer après coup ne suffit pas.

Watchdog peut intervenir lorsqu'une dérive apparaît. Il peut signaler qu'un contexte devient trop volumineux, recommander un compactage, proposer le démarrage d'une nouvelle session ou limiter certaines délégations redondantes.

Il peut également réduire une sortie technique très longue tout en conservant les erreurs utiles, empêcher la relecture d'une ressource inchangée ou rappeler qu'une commande élémentaire pourrait être exécutée directement.

Demander à un modèle chargé de dizaines de milliers de tokens de contexte d'exécuter une opération simple revient parfois à mobiliser une équipe d'architectes pour déplacer une chaise.

Ces contrôles reposent autant que possible sur des règles déterministes. Watchdog n'appelle pas une seconde IA pour constater qu'un fichier est trop volumineux ou qu'une image a déjà été analysée. La gouvernance ne doit pas devenir une nouvelle couche de consommation.

De l'observation à l'expérimentation

La dimension la plus intéressante du projet apparaît lorsque les données commencent à produire des enseignements.

Watchdog peut analyser localement les usages récurrents d'un projet : exploration de code, implémentation, débogage, tests, documentation, opérations ou analyse de journaux. Il ne s'agit plus seulement de savoir combien une session a coûté, mais de comprendre ce qui a réellement été fait.

Un workflow régulièrement répété peut faire apparaître l'intérêt d'un skill spécialisé. Une tâche fréquente de synthèse peut être confiée à un modèle local, dans un cadre strictement borné. L'utilisation récurrente d'un service externe peut révéler le besoin d'une intégration dédiée.

Ces recommandations ne sont pas appliquées silencieusement. Elles sont documentées, prévisualisées et laissées à la décision de l'utilisateur. Lorsqu'une optimisation est activée, elle ouvre une expérimentation.

Watchdog conserve alors un échantillon de sessions de référence et observe les nouvelles sessions correspondant à la même activité. Le coût par tour peut être comparé avant et après le changement, mais il n'est jamais interprété seul.

Cette précaution est importante. Une session moins coûteuse peut simplement avoir été plus courte. Elle peut aussi avoir contenu moins de fichiers, moins de tours ou un contexte initial plus réduit. Conclure trop vite à l'efficacité d'une optimisation reviendrait à confondre corrélation et causalité.

C'est pour mieux traiter cette difficulté qu'un mécanisme d'AutoML local vient d'être introduit dans Watchdog.

Watchdog transforme les usages observés en préconisations mesurables, avec une boucle d'expérimentation AutoML locale.

Le terme peut sembler ambitieux. Ici, il désigne volontairement un dispositif resserré et contrôlable. Lorsque suffisamment de sessions sont disponibles, Watchdog compare plusieurs modèles statistiques. Le premier mesure l'effet apparent de l'optimisation. Les suivants tentent de corriger l'analyse en tenant compte du volume de tours et de la taille du contexte.

Une validation croisée permet ensuite de retenir le modèle qui produit les erreurs les plus faibles sur des observations qu'il n'a pas utilisées pour s'ajuster. Autrement dit, Watchdog ne sélectionne pas l'explication qui décrit le mieux le passé, mais celle qui semble le mieux résister lorsqu'elle est confrontée à de nouvelles données.

L'objectif n'est pas de produire une prédiction spectaculaire. Il est plus modeste, et sans doute plus utile : réduire le risque d'attribuer à une optimisation une économie qui proviendrait en réalité de sessions moins complexes.

Le résultat reste accompagné d'un intervalle d'incertitude. Il est présenté comme une association observée avant et après le changement, jamais comme une preuve automatique de causalité.

L'AutoML ne décide donc pas à la place de l'utilisateur. Il aide à choisir la méthode d'analyse la plus adaptée aux données disponibles.

Une économie n'a de valeur que si la qualité résiste

L'expérimentation ne s'arrête pas à la mesure des coûts.

Watchdog examine également plusieurs signaux de qualité : résultats des tests, corrections nécessaires après validation, stabilité des modifications ou signaux de livraison. Une optimisation ne peut pas être recommandée si elle réduit la consommation tout en dégradant sensiblement le travail produit.

C'est un point qui distingue Watchdog d'un simple tableau de bord FinOps. Une économie de tokens n'est pas une fin en soi. Ce qui compte est le rapport entre les ressources consommées et la valeur effectivement créée.

La même prudence s'applique aux données utilisées pour établir ce diagnostic. Watchdog fonctionne localement. Pour comprendre les usages, il conserve des signaux dérivés tels que les catégories d'activités, les outils sollicités ou certains indicateurs de qualité. Les demandes de l'utilisateur et le contenu des fichiers examinés ne sont pas recopiés dans sa base d'analyse.

Le projet cherche ainsi à observer le système sans surveiller le développeur.

Cette distinction devient essentielle à mesure que les agents gagnent en autonomie. L'observabilité ne doit pas produire un dispositif opaque de contrôle individuel. Elle doit permettre à l'utilisateur de comprendre ce que fait l'agent, pourquoi il le fait et quelles ressources il mobilise.

Une démarche de recherche appliquée chez Alien6

Watchdog reflète la manière dont nous abordons la R&D chez Alien6.

La valeur d'une innovation ne réside pas uniquement dans la puissance d'un modèle ou dans la sophistication de son architecture. Elle apparaît lorsqu'on parvient à transformer cette innovation en un système compréhensible, mesurable et utilisable dans des conditions réelles.

Le projet se situe ainsi à la rencontre de l'architecture logicielle, de l'IA appliquée, du FinOps, de l'expérience développeur et de l'analyse statistique.

Il permet aussi de confronter des idées séduisantes à la réalité. Faut-il systématiquement déléguer une tâche à un sous-agent ? Un modèle local produit-il réellement une économie une fois le coût de coordination pris en compte ? Une réduction du contexte améliore-t-elle la session suivante ? À partir de combien d'observations peut-on commencer à tirer une conclusion raisonnable ?

Watchdog n'apporte pas encore une réponse définitive à toutes ces questions. C'est précisément son rôle en tant que projet expérimental : rendre les hypothèses explicites, construire les instruments nécessaires et accepter que certaines intuitions soient contredites par les données.

Cette démarche s'inscrit dans le travail mené chez Alien6, à l'intersection du conseil stratégique IT, de l'architecture logicielle, de l'intelligence artificielle et de la recherche appliquée.

Elle correspond également à notre manière d'aborder ces sujets : partir d'une difficulté observée, construire un système capable de la mesurer, puis tester les réponses possibles sans masquer leurs limites.

Les agents IA prendront progressivement en charge des séquences de travail plus longues. Leur autonomie augmentera. La nécessité de comprendre leur consommation, leurs décisions et leurs limites augmentera avec elle.

Demain, la question ne sera probablement plus seulement de savoir quel modèle utiliser. Elle sera de déterminer comment s'assurer que ce modèle mobilise correctement les ressources, les outils et le contexte qui lui sont confiés.