# Le troisième grand livre : la dette de connaissance à l'ère des agents IA

> La dette opérationnelle est de la connaissance qui n'a jamais été écrite. Les personnes pouvaient toujours demander au collègue qui savait ; les agents IA ne le peuvent pas. Pourquoi l'ère de l'IA fait du contenu ratifié et de la récupération déterministe une discipline d'ingénierie.

Source: https://www.bluewise.fr/fr/the-third-ledger-knowledge-debt-in-ai-era  
Author: Marc Morel  
Published: 2026-10-13  
Category: Architecture  
Series: Tech Debt, part 2

Dans [mon article précédent](https://www.bluewise.fr/technical-debt-vs-operational-debt), j'ai décrit deux grands livres. La dette technique vit dans le code et l'architecture, et notre industrie a appris à la mesurer, à la conditionner à des barrières et à négocier du temps pour la rembourser. La dette opérationnelle vit entre les systèmes, dans les relances, les tableurs et les corrections manuelles qui font fonctionner une organisation, à terme. J'ai conclu avec l'idée que la dette opérationnelle est souvent de la dette technique qui n'a jamais été écrite, payée par mensualités par des personnes au lieu d'être remboursée une fois par un système.

J'aimerais tirer ce fil, parce que « jamais écrite » est sur le point de devenir l'une des expressions les plus coûteuses de notre métier. Pendant des décennies, la connaissance que personne n'avait consignée était tenue en lieu suffisamment sûr par les collègues qui la portaient. Nous confions désormais de plus en plus de travail à des agents IA, et les agents n'ont aucun collègue vers qui se tourner.

## Ce que porte réellement le héros

Quand nous imaginons la personne qui fait converger une organisation qui finit par fonctionner, nous avons tendance à imaginer l'effort : des soirées tardives, une relance de plus, une correction appliquée à la main. La pratique SRE de Google a donné un nom à la partie visible de cet effort, le [toil](https://sre.google/sre-book/eliminating-toil/), et un budget. L'effort est réel, mais ce n'est pas la ressource rare. Ce qui est rare, c'est ce que ces personnes savent.

Elles savent qu'une règle de la procédure a été assouplie il y a deux ans pour un segment de clientèle, et pourquoi. Elles savent laquelle des trois pages décrivant la réconciliation est encore exacte. Elles savent que le batch peut être relancé sans risque avant six heures du matin, mais pas après. Elles connaissent la décision prise lors d'une réunion sans compte rendu, et le contournement que la conformité a tacitement accepté. Michael Polanyi l'a résumé en 1966 : nous savons plus que nous ne pouvons dire.

C'est le troisième grand livre. **La dette de connaissance** est l'écart entre ce sur quoi une organisation agit et ce qu'elle a réellement écrit et reconnu comme vrai. C'est le capital sur lequel la dette opérationnelle paie ses intérêts. Chaque intervention héroïque est, au fond, une consultation d'une base de connaissance qui n'existe que dans la mémoire d'une personne.

Pendant longtemps, cet arrangement a été coûteux mais supportable, pour une raison simple : une personne qui ne sait pas quelque chose s'en rend généralement compte. Elle hésite, elle se renseigne, elle appelle le collègue qui sait. L'organisation converge lentement, mais elle converge vers ce que le héros sait être juste.

## Les agents ne peuvent pas demander à Brent

Les lecteurs de *The Phoenix Project* se souviendront de Brent, l'ingénieur auquel chaque escalade finit par aboutir. Placez maintenant un agent IA à un poste où la réponse venait autrefois de Brent.

L'agent n'hésite pas. Quand la connaissance manque, un modèle de langage ne s'arrête pas ; il produit la suite la plus plausible. La plausibilité est une propriété du texte, pas de la vérité, et les exceptions non écrites d'une organisation sont précisément ce qu'un modèle ne peut pas trouver plausible, parce qu'elles n'apparaissent nulle part où il aurait pu les apprendre.

Trois choses changent à la fois.

- **L'échelle.** Un héros humain improvise quelques fois par semaine. Les agents improvisent à chaque session, en parallèle, dans chaque équipe qui les utilise.
- **La direction.** L'organisation qui finissait par fonctionner convergeait quand même, parce que le héros connaissait la bonne réponse. Un agent auquel il manque du contexte ne converge pas. Il dérive, avec assurance, et il peut dériver différemment d'une session à l'autre.
- **La récursion.** Ce que produit un agent, que ce soit du code, un résumé, un runbook ou une note de conception, atterrit dans les dépôts et les wikis mêmes que lira le prochain agent. Une production non vérifiée devient le contexte de demain. Sans barrière, la dette de connaissance se compose à la vitesse de la machine.

Sous ces changements se cache un basculement structurel. En ingénierie agentique, le coût marginal de production du code s'effondre, et les contraintes se déplacent ailleurs : vers la qualité et la fraîcheur du contexte que nous donnons aux agents, et vers notre capacité à vérifier ce qu'ils produisent. Nous avons passé vingt ans à industrialiser la vérification, avec des tests, des revues, des pipelines et des quality gates. Presque rien n'industrialise le contexte. C'est dans cette asymétrie que le troisième grand livre fera le plus mal.

C'est aussi pourquoi je n'accepte plus « l'agent s'est trompé » comme cause racine. C'est un symptôme. La cause racine est un contexte manquant, un contexte périmé ou une évaluation manquante, et deux de ces trois causes relèvent de la dette de connaissance.

## Plausible n'est pas vrai

La réponse instinctive est de tout indexer. Pointez un pipeline de récupération vers le wiki, les partages de fichiers, le système de tickets et l'historique de chat, et laissez la recherche sémantique trouver le passage pertinent. Pour la découverte, c'est un réflexe raisonnable et utile. La génération augmentée par récupération (RAG), telle que [Lewis et ses collègues l'ont introduite en 2020](https://arxiv.org/abs/2005.11401), a été conçue pour des questions en domaine ouvert et intensives en connaissances, où le passage le plus proche est généralement suffisant. Pour tout ce qui est normatif, c'est le mauvais outil, et il vaut la peine d'être précis sur la raison.

La récupération par similarité renvoie le passage le plus proche de la question, pas le passage qui est vrai. Une page fluide et bien liée décrivant l'ancienne procédure est souvent plus proche de la question que l'amendement laconique qui l'a remplacée. La plupart des intranets contiennent plusieurs versions de la même règle, et le moteur de récupération n'a aucun moyen de savoir que l'une d'elles a été révoquée. Il peut trouver le texte le plus proche ; il ne peut pas trouver le plus faisant autorité, parce que l'autorité n'est pas une propriété du texte. C'est une propriété d'une décision que quelqu'un a prise.

La récupération par similarité n'est pas non plus reproductible. Changez le modèle d'embedding, reconstruisez l'index, ajustez le découpage ou ajoutez simplement des documents, et la même question peut recevoir une réponse différente la semaine suivante. Pour un assistant généraliste, c'est tolérable. Pour un agent qui applique une politique de crédit, une règle de conservation ou un standard de sécurité, ça ne l'est pas. Vous ne pouvez pas défendre une décision dont vous êtes incapable de reproduire le fondement, et « le moteur de récupération a classé un autre fragment mardi » n'est pas une explication qu'un auditeur acceptera.

| | Récupération de recherche | Récupération normative |
| --- | --- | --- |
| Question à laquelle elle répond | Qu'est-ce qui est lié à ceci ? | Quelle est la règle, et qui le dit ? |
| Source | Tout ce qui est indexé | Le corpus ratifié uniquement |
| Sélection | Classement par similarité | Résolution par identité et version |
| Même question, deux fois | Peut différer | Même réponse pour la même version |
| Quand rien ne correspond | Renvoie quand même le plus proche | Le dit, explicitement |
| Échec typique | Assuré, plausible, faux | Refus et escalade vers une personne |

Les deux ont leur place. L'erreur est de laisser la première remplir le rôle de la seconde.

## Le contenu ratifié : décider de ce qui est vrai avant que quiconque ne demande

Le **contenu ratifié** est une connaissance qu'une personne nommée et responsable a examinée et acceptée comme faisant autorité, pour un périmètre défini et une période définie. En pratique, chaque objet de connaissance porte cinq propriétés.

1. **Un propriétaire.** Un intendant qui en répond. Une connaissance sans propriétaire est une rumeur bien mise en forme.
2. **Un type.** Toutes les affirmations ne sont pas de même nature. Je trouve quatre types indispensables : une obligation réglementaire, une interprétation de cette obligation, une convention interne, et une assertion empirique sur le comportement d'un système. Chacun change pour une raison différente, qu'il s'agisse d'une nouvelle réglementation, d'un avis juridique, d'une décision d'architecture ou d'une observation en production, donc chacun a besoin de son propre déclencheur de revalidation.
3. **La provenance.** D'où vient l'affirmation, quelles sources la soutiennent et quel enregistrement de décision l'a créée.
4. **Une durée de validité.** Une date après laquelle l'objet n'est plus servi tant que quelqu'un ne l'a pas revalidé. La fraîcheur n'est pas un raffinement : une connaissance dérivée échoue en silence quand elle se périme.
5. **Un événement de ratification.** Enregistré et idéalement signé, qui engage l'intendant sur le contenu exact qu'il a approuvé.

La propriété qui compte le plus est celle à laquelle les équipes résistent : **une connaissance non ratifiée n'est pas récupérable.** La quarantaine signifie invisible pour les agents, pas simplement étiquetée comme brouillon. Une étiquette de brouillon est un indice qu'un modèle ignorera volontiers ; l'absence du corpus est une garantie.

Rien de tout cela ne nécessite de technologie exotique. La connaissance vit dans Git sous forme de Markdown avec un frontmatter structuré, est relue via des merge requests et publiée sous forme de packs versionnés, exactement comme nous publions du code. Des formats émergent pour le permettre. L'[Open Knowledge Format](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md) de Google Cloud empaquette la connaissance organisationnelle sous forme de fichiers Markdown liés avec un frontmatter YAML, et sa seconde version ajoute provenance, cycle de vie et signaux de confiance. Un format n'est cependant qu'un contenant. La discipline de ratification par-dessus, c'est à nous de la construire.

Il y a ici un point épistémologique qui, je trouve, aide les équipes à accepter la discipline. Dire que la Terre est ronde n'est pas faux ; c'est une simplification. Dire qu'elle est un sphéroïde aplati est plus précis, et dire qu'elle est plate est simplement faux. Un document simplifié est une sphère : suffisamment bon à sa résolution. Un document périmé est une Terre plate. Mais la connaissance de nos propres systèmes a une propriété que la Terre n'a pas. Que nous disions la Terre ronde ou plate, son orbite reste la même. Que nous disions notre système d'information juste ou faux, il ne suit pas la même trajectoire. Les agents agissent sur ce que nous leur disons, et ce que nous ratifions devient ce que nous construisons.

## La récupération déterministe : même question, même réponse

Une fois le corpus ratifié, la récupération peut changer de nature. Au lieu de demander quel texte est le plus similaire, l'agent demande quel objet de connaissance régit ce cas, et à quelle version. La réponse est résolue par identité plutôt que par classement. Je décris le contrat qui en résulte comme **le contenu exact ou rien**.

- **La recherche trouve, l'identité sert.** La recherche peut aider un agent à localiser des candidats, mais le contenu qu'il reçoit est résolu par identifiant et version, et servi mot pour mot avec son propriétaire, sa provenance et sa ratification.
- **Reproductible par construction.** La même question sur la même version de pack de connaissance renvoie la même réponse, aujourd'hui et dans deux ans, quand quelqu'un demandera pourquoi l'agent a agi comme il l'a fait.
- **Échec fermé.** Quand un objet est périmé, en quarantaine ou révoqué, la passerelle refuse avec une raison explicite. Elle ne se rabat pas sur une paraphrase, un document voisin ou une copie en cache.
- **L'absence est une réponse.** Quand aucune connaissance ratifiée n'existe, le système le dit. « Il n'existe aucune règle ratifiée pour ce cas » est peut-être la phrase la plus précieuse qu'un agent puisse recevoir, parce qu'elle transforme une improvisation en escalade vers une personne.
- **Cité, pas remémoré.** Quand un agent s'appuie sur une connaissance normative, il la cite, et la citation peut être vérifiée par rapport à la source.

Pour le code, le code lui-même reste la source de vérité, et une simple recherche textuelle dans le dépôt est déjà déterministe et toujours à jour. Le corpus ratifié sert à ce que le code ne peut pas vous dire : l'intention, les obligations, les conventions, les décisions et les raisons derrière les exceptions. Autrement dit, exactement la connaissance que portait le héros.

C'est la conception en échec fermé appliquée à la connaissance, et elle paraîtra restrictive au début. Un agent qui refuse plus souvent impressionne moins en démonstration. En production, et particulièrement en environnement régulé, c'est le seul type d'agent honnête sur les limites de ce que l'organisation sait réellement.

## Boucler la boucle : là où la dette opérationnelle est enfin écrite

Une ratification sans boucle de rétroaction se transforme vite en un énième sprint de documentation, périmé dès le trimestre suivant. La boucle qui garde le corpus vivant est la même que celle qui mesure la dette opérationnelle.

Incidents, post-mortems, corrections manuelles et accès d'urgence signalent tous que la réalité s'est écartée de ce qui était écrit. Chaque signal soit révoque un objet dont l'inexactitude a été prouvée, soit produit un candidat à la ratification. Le candidat entre en quarantaine, un intendant l'examine, et seulement alors il devient disponible pour les agents.

C'est ainsi que le contournement du héros quitte enfin sa tête. Il aboutit à l'un de deux endroits : sous forme de procédure ratifiée qu'un agent peut appliquer, ou sous forme de fonctionnalité manquante dans le backlog de dette technique. Dans les deux cas, il a été écrit, et le troisième grand livre a été remboursé une fois plutôt que par mensualités.

## Ce que cela demande aux personnes

Ce n'est pas avant tout un program d'outillage. Cela change les rôles, et il vaut la peine de le dire clairement.

- **Les héros deviennent des intendants.** Les personnes qui portent la connaissance aujourd'hui sont les bonnes personnes pour la ratifier demain. Cela devrait être reconnu comme une responsabilité à part entière, avec quelques pour cent de temps protégé, plutôt qu'ajouté à leurs soirées.
- **Les architectes deviennent des producteurs de connaissance.** Relire des schémas après coup laisse place à la responsabilité du corpus normatif, avec un niveau de service pour le garder à jour. Les décisions sont consignées au moment où elles sont prises, pas après. Pas d'ADR, pas de décision.
- **Certaines habitudes s'arrêtent.** Arrêtez d'indexer tout l'intranet pour les agents et indexez plutôt le corpus ratifié. Arrêtez de maintenir des pages parallèles pour le même fait ; choisissez un emplacement unique et redirigez le reste.
- **La télémétrie porte sur la connaissance, jamais sur les personnes.** Les enregistrements des objets de connaissance que consomment les agents sont de précieux signaux de qualité et de lacunes. Ils ne doivent jamais devenir une mesure de la performance individuelle, à la fois par un engagement écrit et par le contrôle d'accès. La confiance dans l'ensemble du système en dépend.

## Par où commencer

Les premières étapes sont volontairement petites.

1. Choisissez un domaine où les agents travaillent déjà et où les erreurs coûtent cher.
2. Listez les questions que les agents posent, ou poseraient, dans ce domaine, et les personnes qui y répondent aujourd'hui.
3. Ratifiez la vingtaine d'objets qui répondent à la plupart de ces questions, chacun avec un propriétaire, un type et une durée de validité.
4. Servez-les par identité, en échec fermé, et enregistrez chaque absence.
5. Traitez chaque absence et chaque incident comme un candidat à la ratification.

En quelques semaines, la liste des absences devient la carte la plus honnête de la dette de connaissance que l'organisation ait jamais eue.

## Ce qui change

> La question qu'un agent ne peut pas poser

Une personne qui ne sait pas dit « je vérifie ». Un agent dit quelque chose. Cette différence résume tout l'argument de cet article. Nos organisations ont fonctionné pendant des années sur une connaissance que personne n'avait écrite, parce que les personnes qui la détenaient étaient aussi celles qui remarquaient quand elle manquait. Les agents ne remarquent pas ; ils continuent.

Le travail s'est donc déplacé. Notre rôle est de faire en sorte que ce que dit un agent soit quelque chose que nous avons reconnu comme vrai, ou rien du tout. Ce n'est pas une surcharge de documentation. C'est le contexte sur lequel nos systèmes fonctionnent désormais, et, peut-être pour la première fois, une façon concrète de reconnaître les personnes qui ont porté cette connaissance depuis toujours.