Nos organisations ont une fuite mémoire
Un vieux bug d'informaticien décrit ce qui arrive en ce moment à beaucoup d'organisations : la qualité est la seule grandeur qui puisse céder sans que personne ait à l'annoncer.
En 2006, alors expert technique dans une grande entreprise, j’étais appelé à statuer sur des « figeages » endurés par des milliers de conseillers clientèle, qui n’avaient pas d’autre vocabulaire pour décrire un frontal CRM qui soudainement se bloquait.
Il y avait de nombreuses pannes à découvrir, et les plus insidieuses se produisaient quand tout allait bien : les consoles de surveillance étaient au vert, aucune opération récente en production ni sur le réseau, et boum, les figeages reprenaient. Le premier réflexe était d’accuser le réseau… c’est toujours la faute du réseau ; sauf que pas du tout, bien sûr ! Le problème était côté serveur, et il nous a fallu de bonnes doses de patience et de créativité pour finalement mettre le doigt sur ce phénomène si subtil : dans certaines fonctionnalités métier, toute la mémoire n’était pas libérée à la fin de l’opération. S’accumulant avec le temps, ce bug finissait par faire planter un des multiples serveurs — provoquant un comportement parfaitement imprévisible pour l’utilisateur. Il nous a fallu poser des sondes sur les serveurs de production pour comprendre qu’à un moment donné, leur mémoire avait saturé, avant que leur pool de tâches ne se relance de lui-même et que le service ne se restaure. Les autres voyants étaient au vert ; les utilisateurs, eux, sacrifiés !
Avant de trouver le bug, la solution fut de programmer un redémarrage quotidien des serveurs : les fuites mémoire n’avaient plus le temps de faire des dégâts !
Une fuite mémoire, pour qui n’a jamais eu à en chasser une, qu’est-ce que c’est au juste ? Pourquoi ce vieux bug d’informaticien décrit-il si bien ce qui arrive, en ce moment même, à beaucoup d’organisations ? Et surtout : que regardent vos tableaux de bord pendant que ça fuit ?
Une fuite mémoire — c’est-à-dire de la mémoire qu’un programme réserve et ne rend jamais, cycle après cycle — a trois propriétés qui portent à elles seules toute cette histoire. D’abord, le programme continue de fonctionner normalement : c’est le piège, rien n’alerte. Ensuite, le coût est différé et cumulatif — chaque cycle aggrave un peu plus, aucun cycle ne déclenche d’alarme. Enfin, quand le crash arrive, il est loin de sa cause : on cherche l’erreur du jour, elle avait des semaines.
Le pont vers l’organisation se pose en une image simple. Tout projet arbitre entre périmètre, coût et délai. Quand les trois sont fixés — et ils le sont presque toujours —, une quatrième grandeur absorbe les chocs : la qualité. Elle est la seule qui puisse céder sans que personne n’ait à l’annoncer. Reporter une date se voit. Dépasser un budget se voit. Couper une fonctionnalité se voit. Baisser la qualité ne se voit pas — pas tout de suite.
Ceux qui comprennent l’agilité le savent : ce triangle a une règle. Le périmètre, le coût, le délai peuvent varier — c’est même toute la promesse de la méthode. À l’origine, la qualité n’est pas une variable d’ajustement : elle est l’invariant sur lequel tout le reste s’ajuste. La définition de fini qu’on ne négocie pas, les tests qui passent avant de livrer, le refactoring intégré au sprint plutôt que repoussé à un hypothétique « plus tard », les développeurs propriétaires et fiers de leur craftmanship — ce sont les garde-fous du système. Quand ils commencent à plier, silencieusement, sans jamais être annoncés comme un choix, ce n’est pas l’agilité qui a échoué. C’est sa règle la plus fondamentale qu’on a cessé de tenir.
Nos budgets annuels et nos investissements pilotés par projet plutôt que par produit reproduisent, à une autre échelle, exactement la même solution que mon redémarrage quotidien de serveurs : on referme le cycle avant que la fuite n’ait le temps de se voir. Le compteur revient à zéro chaque année, chaque projet est clos et livré « fini » — et ce qui n’a pas été traité ne s’accumule nulle part dans les tableaux de bord. La dette technique continue pourtant d’allouer de la mémoire qu’aucun cycle ne libère jamais.
Ce n’est la faute de personne, et certainement pas des managers : c’est une propriété structurelle de tout pilotage sous contrainte. Aucune nostalgie, aucun procès à instruire ici.
Le chiffre existe, et il est sans appel. GitClear a analysé 623 millions de lignes de code : la part des modifications qui reviennent sur du code vieux de plus d’un an a chuté de 74 % en trois ans. Le système grossit vers l’extérieur ; ses couches anciennes gèlent — personne n’y retourne plus. Et pendant que ce réflexe recule, le volume de code produit, lui, explose : une part croissante est désormais écrite par l’IA. Le robinet s’ouvre plus grand ; alors qu’on ne contrôle plus la qualité de l’eau…
Rien ne plante. Les démos passent. Les tableaux de bord sont verts — ils mesurent le débit, la vélocité, le ROI trimestriel. Ils ne mesurent pas ce qui fuit.
Une dette technique, ça s’accumule sans bruit ; et c’est la fuite mémoire de l’organisation. Chaque projet en rajoute un peu ; aucun projet n’alarme. Et le jour où quelque chose casse — un incident majeur, un produit devenu immaintenable, un expert irremplaçable, une équipe qui ne sait plus livrer — l’événement du jour n’expliquera rien. La cause aura trois ans.
Concrètement, à quoi ça ressemble, vu de l’intérieur ? La dernière fois qu’une équipe a pu ajouter des US techniques à son sprint — refactoring, spikes — sans se justifier ; la dernière fois qu’un train a réellement utilisé son sprint IP pour un hackathon, de l’innovation ou de la formation, plutôt que pour rattraper le retard des derniers sprints ; la dernière fois qu’une équipe a obtenu le droit de ralentir pour fiabiliser. Ce qui a réellement cédé au dernier délai qui a dérapé — le périmètre, le budget, ou le silence sur la qualité ? Et surtout : qui, dans votre organisation, serait aujourd’hui capable de dire où en est la dette technique — pas de l’estimer, de le dire, avec des chiffres ?
Chez vous — quand un délai dérape, qu’est-ce qui cède en premier ?
Ce texte est le premier fil d’une thèse plus large sur ce que l’arrêt des transformations coûte réellement aux organisations ; je la publierai à la rentrée.
Références : GitClear, « AI Code Quality Research 2026 — The Maintainability Gap » (623 millions de lignes analysées ; part du code réorganisé passée d’environ 21 % en 2022 à moins de 4 % en 2026, duplication en hausse de 81 %). Google Cloud, « Accelerate State of DevOps Report 2024 » (DORA) : chaque tranche de 25 % d’adoption supplémentaire de l’IA générative est associée à une baisse de 7,2 % de la stabilité des livraisons. CISQ, « The Cost of Poor Software Quality in the US », 2022 : 2 410 milliards de dollars pour la seule économie américaine, dont 1 520 milliards de dette technique accumulée.