"C’est historique."

"C’est historique." Je pense que j’entends ça depuis que j’ai commencé le dev il y a vingt ans.

"Pourquoi deux bases de données pour les users ?" "C’est historique."

"Pourquoi ce service fait la même chose que celui-là ?" "C’est historique."

"Pourquoi on ne touche jamais à ce module ?" "C’est historique."

Pendant vingt ans, c’était un coût humain que l’on retrouvait partout, quelle que soit la taille du client. On posait des questions, on reconstituait le contexte, puis on finissait par comprendre au bout de quelques semaines. Ou on refactorait, puis on découvrait le pourquoi a posteriori, généralement après avoir vu un bug remonter ^^

La connaissance se transmettait par oral et par les gens qui restaient. C’était lent, imparfait, mais ça fonctionnait tant qu’il y avait des humains pour compenser. Sur mes cinq ou six dernières expériences, j’ai dû refaire l’onboarding quasiment à chaque fois. Parfois plusieurs fois, refaire les schéma d’archis, la description des domaines ...

Là où ce n’était qu’un ralentissement, l’IA transforme maintenant ce contexte manquant en coût de production direct. Chaque décision non documentée, chaque raisonnement resté dans la tête de quelqu’un qui est parti, devient une source d’erreur potentielle.

D’un inconfort humain, on est passé à une dette opérationnelle.

Refondre sans comprendre

Sur une mission récente, on a dû refondre une partie de l’architecture d’un produit. L’ensemble était devenu tellement complexe que plus personne ne comprenait pourquoi il avait été construit comme ça. Les gens qui avaient fait ces choix n’étaient plus là. Pas d’ADR. Pas de trace du raisonnement. On a passé des semaines à se demander si cette complexité cachait une contrainte réelle qu’on ne voyait pas, ou si c’était simplement de l’over-engineering. Impossible de trancher vite. On a fini par simplifier, mais le doute a ralenti chaque décision.

Je mets toujours en place des ADRs quand j’arrive dans une organisation qui n’en a pas. Mais sur ce produit, tout ce qu’on devait refondre avait été construit avant. Un agent face à cette architecture ne challenge pas la complexité implicite. Il la propage. Il ne va pas spontanément se demander "est-ce que c’est volontaire ?". Même si on lui demande d’être critique, il n’a aucune base pour juger.

En l’absence de contexte explicite, l’existant devient la vérité. L’agent aurait continué à construire par-dessus, en supposant que si c’était là, c’était volontaire.

La donnée est partout, la vérité nulle part

Et même quand on fournit du contexte aux agents, la donnée reste souvent fragmentée entre plusieurs systèmes. Qui détient la vérité ? Où le raisonnement derrière une décision structurante a-t-il été posé ? Dans la spec technique ? Dans l’ADR ? Dans le code ? Et que fait-on des informations qui remontent d’un Notion à moitié à jour ? Des documents obsolètes depuis six mois ? Des fichiers de contexte faux générés par un agent et jamais réellement relus ?

Dans une startup que j’accompagne, les specs sont dans Notion, les échanges clients dans le CRM, les décisions techniques dans Linear, et les agents ne lisent réellement que GitHub. L’accès à l’information n’est plus le sujet. Il manque une source de vérité cohérente.

Notion vient de sortir une CLI. Les éditeurs ajoutent des fichiers de contexte. Toute l’industrie essaie maintenant de brancher les agents sur la mémoire des organisations.

Sauf que, dans la plupart des boîtes où j’interviens, quand on regarde en détail les (nombreuses) sources d’informations, on se rend compte que certaines des plus utiles ne sont au final nulle part. Personnellement, j’ai résolu une partie du problème avec un second brain local sous Obsidian. Mes agents s’en nourrissent et le pourquoi est beaucoup plus détaillé que le quoi que l’on retrouve dans le code notamment. Mais ça ne scale pas à une organisation.

Vingt minutes qui n’arrivent jamais

Personne ne refuse d’écrire. C’est simplement que ce n’est jamais prioritaire. Il y a le sprint en cours et l’incident de ce matin. Prendre vingt minutes après une décision d’archi pour noter le raisonnement passe systématiquement après. Vingt minutes qui n’arrivent jamais. Et même quand on décide de l’imposer, il faut souvent plusieurs mois avant que l’habitude s’installe réellement.

Pendant longtemps, ce coût restait diffus. Le nouveau passait trois semaines à poser des questions. Le senior passait une heure, un jour, à réexpliquer les mêmes choses. On râlait pendant les refactos. Avec l’IA, c’est passé du stade de nice to have à celui de must have. Un agent sans contexte produit du code qu’il faut relire et corriger, parfois jeter. Tous les jours. Sur chaque repo où les décisions passées ne sont pas écrites. Le coût est là, dans chaque PR à revoir, et il est proportionnel au nombre de décisions non documentées.

Dix lignes suffisent

Quand on commence à écrire, même peu, même imparfaitement, le changement est rapide. Un ADR de dix lignes : "On a choisi Postgres plutôt que DynamoDB parce qu’on avait besoin de transactions cross-tables, et on a écarté Mongo parce que l’équipe n’avait pas l’expérience." Dix lignes. L’agent qui lit ça ne va plus proposer Mongo. Il ne va plus créer un deuxième schéma qui contredit le premier.

Même chose avec un postmortem de vingt lignes après un incident : "Le déploiement de vendredi a cassé la facturation parce que le feature flag n’était pas branché sur le bon tenant." Et ca peut même se générer via un agent si le système est concu pour cela. Et l’agent qui lit ça ne reproduira probablement pas la même erreur six mois plus tard.

So what ?

La question n’est pas "faut-il documenter ?". Ça, on le sait déjà. La question est devenue : combien de temps on peut se permettre de ne pas le faire quand chaque agent amplifie le coût de chaque décision non écrite ? Mais aussi, que ne faut-il pas documenter ? Certaines informations sont tellement faciles à aller chercher maintenant dans la codebase par un agent, que le coût de la maintenance de la doc ne se justifie pas toujours.

On parle beaucoup de data governance et de pipelines propres. C’est un vrai sujet. Mais parfois, le problème est encore plus en amont : de la connaissance qui n’a jamais été écrite nulle part. Et aucun modèle ni aucun outil ne compensera le fait qu’il n’y a rien à lire. L’agent, lui, ne va pas rester bloqué.

Il va produire une justification plausible, confiante, et totalement inventée.