86 % des repos ont des fuites mémoire. Et c’est la dette la moins inquiétante de votre codebase.

On connaît la dette technique. On sait la mesurer, la prioriser, la négocier. Mais il existe des dettes qui ne portent pas de nom dans la plupart des organisations — et qui se payent beaucoup plus cher. Cette semaine, les sources dessinent un portrait saisissant : la vraie dette, c’est celle qu’on ne voit pas.

La comprehension debt : quand personne ne comprend le code

Addy Osmani met un nom sur un problème que beaucoup d’équipes vivent sans le formuler : la comprehension debt [1]. C’est l’écart croissant entre la quantité de code dans votre système et la quantité que n’importe quel humain comprend réellement. Contrairement à la dette technique classique — qui s’annonce par des builds lents et des dépendances emmêlées — la comprehension debt génère une fausse confiance. Le code a l’air propre. Les tests passent. Le réveil arrive au pire moment.

Une étude d’Anthropic citée dans l’article montre que les développeurs qui utilisent l’IA pour générer du code obtiennent des scores significativement plus bas en compréhension que ceux qui l’utilisent pour explorer des concepts. Le code est là, il fonctionne, mais personne ne peut expliquer pourquoi les décisions de design ont été prises ni comment les parties du système interagissent.

“The real problem wasn’t messy code. It was that no one on the team could explain why design decisions had been made or how different parts of the system were supposed to work together. The theory of the system had evaporated.”

18 mois de code à la poubelle

L’illustration la plus brutale vient d’une startup qui a jeté 18 mois de développement [2]. Le fondateur admet avoir fait le choix inverse de l’overengineering : TypeScript sans mode strict, zéro test, “just ship”. Ça a fonctionné à deux développeurs qui connaissaient tout le code. Dès qu’ils ont recruté, les bugs sont apparus de partout. Ils ont perdu un client.

Le plus révélateur : pendant longtemps, il a interdit à son équipe d’écrire des tests, convaincu que la culture du shipping rapide était plus importante. Quand il a changé d’avis, c’était trop tard pour un refactoring — il fallait tout réécrire. La comprehension debt avait atteint un point de non-retour.

Les fondations invisibles

Jim Grey retrouve le même diagnostic dans chaque organisation en souffrance qu’il accompagne : deadlines ratées, qualité en chute, équipes en mode pompier [3]. La cause racine est toujours un codebase fragile — des années de raccourcis qui se composent en quelque chose d’impossible à changer. La solution passe par trois piliers : pyramide de tests automatisés, remédiation de la dette technique, stabilisation du pipeline de déploiement.

Ce travail prend des mois et ne produit rien de montrable à un board. Mais c’est ce qui transforme une équipe qui se bat contre le système en une équipe que le système soutient.

55 864 fuites mémoire dans 500 repos

Une étude empirique a scanné 500 repositories publics React, Vue et Angular à la recherche de patterns de fuite mémoire [4]. Résultat : 86 % des repos ont au moins un pattern de cleanup manquant. 55 864 instances potentielles sur 714 217 fichiers. Chaque cycle mount/unmount sans cleanup retient environ 8 Ko de heap — invisible en développement, cumulatif en production.

Le parallèle avec la comprehension debt est direct : ces fuites existent parce que les développeurs ne comprennent pas pleinement le cycle de vie des composants qu’ils écrivent. Un useEffect sans cleanup return, un subscribe() sans unsubscribe() — chacun invisible individuellement, dévastateur collectivement.

Les conteneurs non plus ne vous protègent pas

On pourrait croire que la conteneurisation résout au moins le problème de l’isolation. Un conteneur est un processus Linux avec un peu d’isolation — il partage le kernel de l’hôte [5]. Les vrais correctifs sont connus depuis trente ans : non-root, capabilities droppées, digests épinglés, seccomp. Mais combien d’équipes les appliquent systématiquement ?

“If this workload gets compromised, what can it reach next? If the answer is the whole node, the control plane, or other tenants, then the isolation is weak.”

BuzzFeed : quand l’IA accélère la chute

BuzzFeed est au bord de la faillite, deux ans après avoir misé massivement sur l’IA [6]. L’entreprise a remplacé des rédacteurs par des générateurs de contenu IA, pariant que le volume compenserait la qualité. Le résultat : un contenu que personne ne veut lire, une audience en chute libre, et une dette stratégique qui s’est accumulée silencieusement pendant que les métriques de production semblaient bonnes.

C’est la comprehension debt à l’échelle organisationnelle : personne ne comprenait plus ce que le produit était censé être.

La sécurité IA, une dette de plus

McKinsey a construit Lilli, une plateforme IA interne pour ses 43 000 employés — chat, RAG sur 100 000 documents, 500 000 prompts par mois [7]. Une équipe de sécurité offensive a pointé un agent autonome dessus — sans credentials, sans connaissance interne. Juste un nom de domaine. Quand votre plateforme IA a accès à des décennies de recherche propriétaire, la surface d’attaque n’est plus théorique. C’est une dette de sécurité qui s’accumule à chaque document indexé.

Le doute comme antidote

Face à toutes ces dettes invisibles, quelle posture adopter ? Lincoln, en 1862, a écrit un texte que personne n’était censé lire — une méditation privée sur ses doutes et les limites de sa compréhension [8]. Mike Fisher propose que cette introspection est exactement ce qui différencie un bon leader d’un manager qui joue les certitudes.

Le lien avec la dette invisible est direct : les leaders qui doutent sont ceux qui posent les questions inconfortables. Combien de notre code est compris par quelqu’un ? Nos conteneurs sont-ils vraiment isolés ? Notre plateforme IA a-t-elle été auditée ? Les réponses sont rarement rassurantes — mais c’est justement le point.

La dette technique, on sait la gérer. La comprehension debt, les fuites mémoire silencieuses, les fondations jamais consolidées — c’est la dette qu’on ne voit pas qui fait tomber les systèmes. Et la première étape pour la réduire, c’est d’admettre qu’elle existe.

---

Sources

1. Comprehension Debt — the hidden cost of AI generated code
2. 18 Months of Code, Gone. Here’s What We Learned.
3. The invisible foundation of engineering transformation
4. Frontend Memory Leaks: A 500-Repository Static Analysis and Five-Scenario Benchmark Study
5. Containers Are Not Automatically Secure
6. BuzzFeed Nearing Bankruptcy After Disastrous Turn Toward AI
7. How We Hacked McKinsey’s AI Platform
8. How Do You Know If You’re a Good Leader?

Pour aller plus loin

• Vibe Coding and the Maker Movement — Le parallèle éclairant entre le vibe coding et le Maker Movement de 2005-2015 : mêmes promesses, mêmes “crapjects”
• 2026-01-14: The Day the telnet Died — 65 % du trafic telnet mondial disparaît en une heure — GreyNoise analyse le changement structurel
• Twenty years of Amazon S3 and building what’s next — 20 ans de S3 : des fondations invisibles qui tiennent le web, et les principes qui n’ont pas changé
• Optimizing Content for Agents — Comment Sentry optimise sa documentation pour les agents IA via la content negotiation

Cet article a été rédigé en m’appuyant sur une IA pour m’aider à synthétiser et structurer ma veille. Les idées, le choix des sources et la relecture restent les miens.