Habr : Comment une Base de Connaissances Obsolète Casse les LLM-Agents et Comment y Remédier

Habr a publié la deuxième partie d'une série sur le développement avec LLM : l'auteur explique pourquoi une base de connaissances obsolète est plus dangereuse qu'une absence totale de documentation. Si vous montrez à un agent un markdown beau mais périmé, il le prendra pour la vérité et commencera à faire des erreurs au niveau de l'architecture, des statuts et des dépendances.

Pourquoi c'est important

L'idée principale est simple : un LLM fait confiance au contexte de la même manière qu'un compilateur fait confiance aux données d'entrée. Lorsqu'une base de connaissances contient des versions anciennes de services, des liens cassés et des plans qui ont longtemps divergé de la réalité, l'agent s'appuie sur une fausse carte du projet. En conséquence, les erreurs apparaissent non pas parce que le modèle est faible, mais parce qu'on lui a donné une description inexacte de l'environnement. Pour les équipes disposant de dizaines de projets parallèles, cela devient rapidement un problème systémique plutôt qu'un simple oubli.

L'auteur souligne que la discipline manuelle fonctionne à peine ici. Plus il y a de documents, de dépôts et de sessions avec des agents, plus la base de connaissances accumule l'entropie. Même un workbench bien structuré devient obsolète au moment de sa création, si personne ne le vérifie automatiquement. La question n'est donc plus de savoir s'il faut écrire de la documentation ou non, mais comment intégrer dans le processus des mécanismes qui l'empêcheront de se dégrader silencieusement et d'empoisonner le prochain cycle de développement.

Comment détecter l'obsolescence

La réponse de base est des vérifications automatiques simples qui peuvent être exécutées manuellement ou en CI. L'auteur décrit un script qui a parcouru son workbench et a immédiatement trouvé des dizaines de problèmes : plus d'un tiers des liens internes ne menaient nulle part après les migrations de documents entre les dépôts. Pour un agent, c'est particulièrement dangereux : il essaie de suivre un lien, ne trouve pas le fichier et perd le contexte ou commence à le remplir avec des hallucinations. À grande échelle, cela devient rapidement une source constante de défauts.

• Vérification des liens internes entre les fichiers markdown
• Contrôle de la fraîcheur des documents clés par date de modification
• Vérification de la couverture : chaque projet doit avoir un fichier de workspace
• Agrégation des TODO de tous les documents markdown en un seul point d'aperçu

L'auteur recommande séparément d'introduire un seuil de fraîcheur, par exemple 60 jours, et de ne pas réécrire chaque document à partir de zéro, mais de faire un bref examen des faits : versions, statuts, dépendances, plans actuels. Quelques minutes d'une telle révision redonnent de la crédibilité au document. La même logique fonctionne pour les TODO : tant que les tâches sont dispersées dans les logs, les plans et les notes, l'équipe ne voit pas le tableau complet. Une fois agrégés, la base de connaissances redevient un outil de travail, pas une archive de notes aléatoires.

Règles et pièges

Les scripts seuls ne suffisent pas si les documents eux-mêmes n'ont pas un cycle de vie clair. L'auteur suggère de les marquer avec les statuts active, reference, draft et archived, et de mettre les anciens matériaux dans archive/ plutôt que de les supprimer. Après chaque phase de travail, l'agent doit mettre à jour les documents connexes, enregistrer les éléments inachevés et, lorsque la fenêtre de contexte se remplit, collecter un prompt de continuation pour la session suivante. De cette manière, la base de connaissances reste synchronisée entre les sessions plutôt que de se disperser dans la mémoire du modèle.

Comme l'écrit l'auteur :

"Un plan obsolète est le même contexte empoisonné, juste en l'air innocent."

La deuxième partie de l'argument révèle le revers de la médaille : LLM rend l'automatisation trop bon marché, donc le développeur commence facilement à optimiser le processus au lieu du produit. Un autre ADR, un autre script ou un pipeline parfaitement planifié ressemblent à du progrès, même si la production pourrait ne pas avoir une fonctionnalité fonctionnant. L'orientation pratique ici est stricte : d'abord le produit, puis la mise en scène, la surveillance et le CI/CD, puis la dactylographie, les tests et les cycles autonomes plus complexes. Si l'équipe construit une chaîne complète « hypothèse — génération — déploiement » avant d'apprendre à détecter une fusion cassée, elle investit dans une méta-optimisation avec un ROI douteux.

Qu'est-ce que cela signifie

Le matériel sur Habr frappe directement le principal point douloureux du développement assisté par IA : la qualité de la réponse d'un 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 et les développeurs indépendants, la conclusion est pratique : la base de connaissances doit vivre selon les mêmes règles que le code — avec des vérifications, des statuts et des mises à jour régulières. Sinon, LLM accélérera non pas le travail, mais la propagation d'anciennes erreurs qui sembleront plausibles et se reproduiront d'une session à l'autre.