Habr : comment une knowledge base obsolète sabote les agents LLM, et comment y remédier

Habr a publié la deuxième partie d'une série sur le développement avec des LLM. L'auteur explique pourquoi une knowledge base obsolète est plus dangereuse qu'une absence totale de documentation. Si l'on montre à l'agent un markdown élégant mais périmé, il le prendra pour la vérité et commencera à se tromper sur l'architecture, les statuts et les dépendances.

Pourquoi c'est important

L'idée centrale est simple : un LLM fait confiance à son contexte comme un compilateur fait confiance à ses données d'entrée. Quand la base de connaissances contient d'anciennes versions de services, des liens cassés et des plans qui se sont éloignés de la réalité depuis longtemps, l'agent s'appuie sur une fausse carte du projet. Les erreurs ne viennent alors pas d'un modèle faible, mais d'une description erronée de son environnement. Pour des équipes qui mènent des dizaines de projets en parallèle, cela devient vite un problème systémique, et non une négligence ponctuelle.

L'auteur souligne que la discipline manuelle ne fonctionne presque pas ici. Plus il y a de documents, de dépôts et de sessions avec l'agent, plus vite la knowledge base accumule de l'entropie. Même un workbench bien structuré devient obsolète dès sa création si personne ne le vérifie automatiquement. La question n'est donc plus d'écrire ou non de la documentation, mais d'intégrer au processus des mécanismes qui l'empêchent de se dégrader en silence et d'empoisonner le cycle de développement suivant.

Comment détecter l'obsolescence

La réponse de base tient en des contrôles automatiques simples, lançables à la main ou en CI. L'auteur décrit un script qu'il a d'abord exécuté sur son propre workbench et qui a immédiatement révélé des dizaines de problèmes : plus d'un tiers des liens internes ne menaient nulle part après la migration de documents entre dépôts. Pour l'agent, c'est particulièrement dangereux : il tente de suivre le lien, ne trouve pas le fichier et soit perd le contexte, soit se met à le reconstituer par des hallucinations. À grande échelle, cela devient vite une source constante de défauts.

• Vérification des liens internes entre fichiers markdown
• Contrôle de la fraîcheur des documents clés d'après leur date de mise à jour
• Vérification de la couverture : chaque projet doit avoir un fichier workspace
• Agrégation des TODO de tous les documents markdown en un seul point de vue d'ensemble

Par ailleurs, l'auteur conseille de fixer un seuil de fraîcheur, par exemple 60 jours, et de ne pas réécrire chaque document de zéro, mais de faire une courte révision des faits : versions, statuts, dépendances, plans en cours. Quelques minutes consacrées à ce passage rendent sa crédibilité au document. La même logique vaut pour les TODO : tant que les tâches sont dispersées entre logs, plans et notes, l'équipe n'a pas la vue d'ensemble. Une fois agrégées, la base de connaissances redevient un outil de travail plutôt qu'une archive de notes disparates.

Règles et pièges

Les scripts ne suffisent pas si les documents n'ont pas de cycle de vie clair. L'auteur propose de leur attribuer les statuts active, reference, draft et archived, et de ranger les anciens contenus dans archive/ plutôt que de les supprimer. Après chaque phase de travail, l'agent doit mettre à jour les documents liés, consigner ce qui reste inachevé et, si la fenêtre de contexte déborde, produire un continuation prompt pour la session suivante. La base de connaissances reste ainsi synchronisée d'une session à l'autre au lieu de se diluer dans la mémoire du modèle.

Comme l'écrit l'auteur :

«

Un plan obsolète, c'est le même contexte empoisonné, mais d'apparence inoffensive ».

La seconde partie de l'argumentaire met aussi en lumière le revers : le LLM rend l'automatisation trop bon marché, si bien que le développeur se met facilement à optimiser le processus plutôt que le produit. Un ADR de plus, un script de plus ou un pipeline parfaitement décrit ressemblent à du progrès, alors qu'en production il peut toujours manquer une fonctionnalité qui marche. Le repère pratique est strict : d'abord le produit, puis le staging, le monitoring et le CI/CD, ensuite le typage, les tests et des boucles autonomes plus complexes. Si une équipe bâtit toute la chaîne « hypothèse, génération, déploiement » avant d'avoir appris à détecter un merge cassé, elle investit dans une méta-optimisation au ROI douteux.

Ce que cela signifie

L'article de Habr touche le principal point douloureux du développement assisté par IA : la qualité de la réponse du modèle dépend de plus en plus non seulement du prompt, mais aussi de l'hygiène du contexte autour du code. Pour les équipes comme pour les développeurs solo, la conclusion est pratique : la base de connaissances doit obéir aux mêmes règles que le code, avec des contrôles, des statuts et une mise à jour régulière. Sinon, le LLM n'accélérera pas le travail, mais la propagation d'anciennes erreurs, qui paraîtront plausibles et se reproduiront de session en session.