#vousnetespasseul
La dette technique : le cadavre dans le placard
dont tout le monde connaît l’odeur et personne ne veut ouvrir la porte
Comment elle s’accumule, pourquoi elle est systématiquement sous-estimée dans les arbitrages budgétaires, et ce qu’il en coûte de continuer à faire semblant qu’elle n’existe pas.
Dans à peu près toutes les organisations qui ont plus de cinq ans d’histoire informatique, il existe une conversation qui se tient régulièrement dans les couloirs, dans les réunions d’équipe, dans les one-to-ones entre le DSI et son équipe — mais rarement en CODIR, et encore plus rarement devant le Conseil d’Administration.
Cette conversation porte sur la dette technique. Sur ce vieux module applicatif que personne ne comprend vraiment mais que tout le monde a peur de toucher. Sur cette architecture qui aurait dû être refactorisée il y a trois ans mais qui continue de tourner parce que le projet de migration a été reporté deux fois et abandonné une. Sur ces librairies qui ne sont plus maintenues depuis 2019 et qui supportent pourtant un processus critique.
La dette technique n’est pas un problème technique. C’est un problème de gouvernance, de culture et de leadership. Et tant qu’on continuera de la traiter comme le premier, on ne résoudra jamais vraiment le second.
Ce qu’est vraiment la dette technique — et ce qu’elle n’est pas
Le terme de dette technique, popularisé par Ward Cunningham dans les années 1990, désigne initialement les choix de développement délibérément sous-optimaux faits pour aller plus vite — avec l’intention explicite de les corriger plus tard. Comme une dette financière : on emprunte du temps aujourd’hui, on rembourse avec des intérêts demain.
Dans la pratique, la notion s’est considérablement élargie. La dette technique englobe aujourd’hui tout ce qui ralentit la capacité d’une organisation à faire évoluer ses systèmes : du code mal structuré aux architectures obsolètes, des processus de déploiement manuels aux dépendances non documentées, des tests insuffisants aux environnements de développement non reproductibles.
La distinction fondamentale est entre la dette choisie — des compromis délibérés et documentés, avec un plan de remboursement — et la dette subie — des problèmes qui se sont accumulés sans décision consciente, sans documentation, et sans plan. La première est un outil de gestion. La seconde est une bombe à retardement.
La grande majorité de la dette technique dans les organisations n’est pas de la dette choisie. C’est de la dette subie, accumulée au fil de décisions prises sous pression, de projets livrés en urgence, de maintenances reportées, et de turnover d’équipes qui ont emporté avec elles la connaissance de systèmes que personne d’autre ne comprend vraiment.
Pourquoi elle est systématiquement sous-estimée — et par qui
Les équipes de développement la sous-estiment par optimisme
Les développeurs connaissent la dette technique mieux que quiconque — c’est eux qui la vivent au quotidien. Mais ils ont tendance à sous-estimer le temps nécessaire pour la résorber, pour la bonne raison que la résorption révèle souvent des problèmes supplémentaires qu’on ne soupçonnait pas. Rembourser de la dette technique, c’est souvent ouvrir une boîte de Pandore.
Le management la sous-estime par manque de visibilité
La dette technique est invisible aux yeux du management non-technique. Elle ne figure pas dans les rapports financiers, elle ne se mesure pas avec les indicateurs habituels, et ses effets — ralentissement de la vélocité de développement, fragilité croissante des systèmes, difficulté à attirer des talents — sont diffus et difficiles à attribuer directement.
Les directions financières la sous-estiment par biais budgétaire
Le budget IT est structurellement biaisé vers le run et vers les nouvelles fonctionnalités visibles. Investir dans le remboursement de la dette technique produit des bénéfices qui ne se voient pas — des problèmes qui n’arrivent pas, des projets qui avancent plus vite, des développeurs qui ne partent pas. Ce type de bénéfice est difficile à valoriser dans un arbitrage budgétaire face à une nouvelle fonctionnalité avec un ROI calculable.
Un DSI nous décrivait récemment son organisation comme un immeuble dont on aurait repeint les façades chaque année pendant dix ans sans jamais refaire les fondations. De l’extérieur, ça ressemble à un bel immeuble. De l’intérieur, les ingénieurs savent que certains murs porteurs sont fissurés.
Le vrai coût de la dette technique — celui qu’on ne met jamais dans les slides
La vélocité de développement qui s’effondre
Le symptôme le plus visible — et le plus frustrant pour le business — est le ralentissement progressif de la capacité à livrer de nouvelles fonctionnalités. Ce qui prenait deux semaines en prend désormais deux mois. Non pas parce que les développeurs sont moins compétents, mais parce que chaque modification nécessite de naviguer dans un code que personne ne comprend vraiment, avec des effets de bord impossibles à prévoir.
Les talents qui partent — et ceux qui ne viennent pas
Les meilleurs développeurs ont le luxe de choisir leur environnement de travail. Et ils ne choisissent pas les organisations où ils passeront leur temps à maintenir des systèmes legacy incompréhensibles plutôt qu’à construire des choses intéressantes. La dette technique est un repoussoir pour les talents — ce qui crée un cercle vicieux : moins de bons développeurs, moins de capacité à rembourser la dette, encore moins d’attractivité.
Les incidents qui s’accumulent
Les systèmes fortement endettés sont fragiles. Les modifications, même mineures, peuvent avoir des effets de bord imprévisibles. Les incidents de production deviennent plus fréquents, plus difficiles à diagnostiquer, et plus longs à résoudre. Et chaque incident urgent crée de la nouvelle dette — parce qu’on corrige vite, sans prendre le temps de le faire proprement.
Comment en parler au CODIR — sans perdre son audience en trente secondes
La principale difficulté du DSI ou du CTO qui veut aborder la dette technique avec le CODIR n’est pas technique — c’est rhétorique. Comment rendre visible et urgent quelque chose d’invisible et de graduel ?
Quelques traductions qui fonctionnent en pratique.
La métaphore financière
La dette technique fonctionne exactement comme une dette financière : elle génère des intérêts. Chaque trimestre où on ne la rembourse pas, elle coûte un peu plus cher à rembourser — et ses effets sur la performance de l’organisation s’aggravent. La question n’est pas si on va la rembourser, mais combien on va payer en intérêts avant de le faire.
Le coût d’opportunité
La dette technique mobilise une partie croissante de la capacité des équipes de développement sur de la maintenance plutôt que sur de l’innovation. Exprimer ce coût d’opportunité en termes de fonctionnalités non livrées ou de délais allongés rend l’abstraction concrète.
Le risque opérationnel
Certains composants de la dette technique représentent des risques opérationnels directs : des systèmes qui ne sont plus maintenus par leurs éditeurs, des dépendances sur des technologies obsolètes, des processus critiques qui reposent sur la connaissance d’une seule personne qui pourrait partir demain. Formuler la dette technique en termes de risque est souvent plus audible que de la formuler en termes de qualité technique.
Ce qu’il faut retenir
La dette technique n’est pas un problème que les équipes IT ont créé seules. C’est le résultat d’une série de décisions organisationnelles — privilégier la vitesse sur la qualité, repousser les investissements de maintenance, ne pas allouer de budget au refactoring — que les directions business et les directions financières ont prises ou validées.
La résoudre nécessite donc une conversation au bon niveau — pas une conversation technique entre développeurs, mais une conversation stratégique sur le niveau de risque acceptable, le coût réel de l’inaction, et la façon dont le budget IT est structuré pour permettre à la fois le run, l’innovation et la maintenance de la santé technique des systèmes.
Chez Kalyptus, nous rencontrons régulièrement des DSI et des CTO qui portent seuls cette conversation difficile. Faire entrer les bons profils — architectes techniques capables de rendre la dette visible, leaders IT capables de la piloter politiquement — est souvent la première étape. C’est un sujet sur lequel nous avons beaucoup à partager.
dont tout le monde connaît l’odeur et personne ne veut ouvrir la porte
Comment elle s’accumule, pourquoi elle est systématiquement sous-estimée dans les arbitrages budgétaires, et ce qu’il en coûte de continuer à faire semblant qu’elle n’existe pas.
Dans à peu près toutes les organisations qui ont plus de cinq ans d’histoire informatique, il existe une conversation qui se tient régulièrement dans les couloirs, dans les réunions d’équipe, dans les one-to-ones entre le DSI et son équipe — mais rarement en CODIR, et encore plus rarement devant le Conseil d’Administration.
Cette conversation porte sur la dette technique. Sur ce vieux module applicatif que personne ne comprend vraiment mais que tout le monde a peur de toucher. Sur cette architecture qui aurait dû être refactorisée il y a trois ans mais qui continue de tourner parce que le projet de migration a été reporté deux fois et abandonné une. Sur ces librairies qui ne sont plus maintenues depuis 2019 et qui supportent pourtant un processus critique.
La dette technique n’est pas un problème technique. C’est un problème de gouvernance, de culture et de leadership. Et tant qu’on continuera de la traiter comme le premier, on ne résoudra jamais vraiment le second.
Ce qu’est vraiment la dette technique — et ce qu’elle n’est pas
Le terme de dette technique, popularisé par Ward Cunningham dans les années 1990, désigne initialement les choix de développement délibérément sous-optimaux faits pour aller plus vite — avec l’intention explicite de les corriger plus tard. Comme une dette financière : on emprunte du temps aujourd’hui, on rembourse avec des intérêts demain.
Dans la pratique, la notion s’est considérablement élargie. La dette technique englobe aujourd’hui tout ce qui ralentit la capacité d’une organisation à faire évoluer ses systèmes : du code mal structuré aux architectures obsolètes, des processus de déploiement manuels aux dépendances non documentées, des tests insuffisants aux environnements de développement non reproductibles.
La distinction fondamentale est entre la dette choisie — des compromis délibérés et documentés, avec un plan de remboursement — et la dette subie — des problèmes qui se sont accumulés sans décision consciente, sans documentation, et sans plan. La première est un outil de gestion. La seconde est une bombe à retardement.
La grande majorité de la dette technique dans les organisations n’est pas de la dette choisie. C’est de la dette subie, accumulée au fil de décisions prises sous pression, de projets livrés en urgence, de maintenances reportées, et de turnover d’équipes qui ont emporté avec elles la connaissance de systèmes que personne d’autre ne comprend vraiment.
Pourquoi elle est systématiquement sous-estimée — et par qui
Les équipes de développement la sous-estiment par optimisme
Les développeurs connaissent la dette technique mieux que quiconque — c’est eux qui la vivent au quotidien. Mais ils ont tendance à sous-estimer le temps nécessaire pour la résorber, pour la bonne raison que la résorption révèle souvent des problèmes supplémentaires qu’on ne soupçonnait pas. Rembourser de la dette technique, c’est souvent ouvrir une boîte de Pandore.
Le management la sous-estime par manque de visibilité
La dette technique est invisible aux yeux du management non-technique. Elle ne figure pas dans les rapports financiers, elle ne se mesure pas avec les indicateurs habituels, et ses effets — ralentissement de la vélocité de développement, fragilité croissante des systèmes, difficulté à attirer des talents — sont diffus et difficiles à attribuer directement.
Les directions financières la sous-estiment par biais budgétaire
Le budget IT est structurellement biaisé vers le run et vers les nouvelles fonctionnalités visibles. Investir dans le remboursement de la dette technique produit des bénéfices qui ne se voient pas — des problèmes qui n’arrivent pas, des projets qui avancent plus vite, des développeurs qui ne partent pas. Ce type de bénéfice est difficile à valoriser dans un arbitrage budgétaire face à une nouvelle fonctionnalité avec un ROI calculable.
Un DSI nous décrivait récemment son organisation comme un immeuble dont on aurait repeint les façades chaque année pendant dix ans sans jamais refaire les fondations. De l’extérieur, ça ressemble à un bel immeuble. De l’intérieur, les ingénieurs savent que certains murs porteurs sont fissurés.
Le vrai coût de la dette technique — celui qu’on ne met jamais dans les slides
La vélocité de développement qui s’effondre
Le symptôme le plus visible — et le plus frustrant pour le business — est le ralentissement progressif de la capacité à livrer de nouvelles fonctionnalités. Ce qui prenait deux semaines en prend désormais deux mois. Non pas parce que les développeurs sont moins compétents, mais parce que chaque modification nécessite de naviguer dans un code que personne ne comprend vraiment, avec des effets de bord impossibles à prévoir.
Les talents qui partent — et ceux qui ne viennent pas
Les meilleurs développeurs ont le luxe de choisir leur environnement de travail. Et ils ne choisissent pas les organisations où ils passeront leur temps à maintenir des systèmes legacy incompréhensibles plutôt qu’à construire des choses intéressantes. La dette technique est un repoussoir pour les talents — ce qui crée un cercle vicieux : moins de bons développeurs, moins de capacité à rembourser la dette, encore moins d’attractivité.
Les incidents qui s’accumulent
Les systèmes fortement endettés sont fragiles. Les modifications, même mineures, peuvent avoir des effets de bord imprévisibles. Les incidents de production deviennent plus fréquents, plus difficiles à diagnostiquer, et plus longs à résoudre. Et chaque incident urgent crée de la nouvelle dette — parce qu’on corrige vite, sans prendre le temps de le faire proprement.
Comment en parler au CODIR — sans perdre son audience en trente secondes
La principale difficulté du DSI ou du CTO qui veut aborder la dette technique avec le CODIR n’est pas technique — c’est rhétorique. Comment rendre visible et urgent quelque chose d’invisible et de graduel ?
Quelques traductions qui fonctionnent en pratique.
La métaphore financière
La dette technique fonctionne exactement comme une dette financière : elle génère des intérêts. Chaque trimestre où on ne la rembourse pas, elle coûte un peu plus cher à rembourser — et ses effets sur la performance de l’organisation s’aggravent. La question n’est pas si on va la rembourser, mais combien on va payer en intérêts avant de le faire.
Le coût d’opportunité
La dette technique mobilise une partie croissante de la capacité des équipes de développement sur de la maintenance plutôt que sur de l’innovation. Exprimer ce coût d’opportunité en termes de fonctionnalités non livrées ou de délais allongés rend l’abstraction concrète.
Le risque opérationnel
Certains composants de la dette technique représentent des risques opérationnels directs : des systèmes qui ne sont plus maintenus par leurs éditeurs, des dépendances sur des technologies obsolètes, des processus critiques qui reposent sur la connaissance d’une seule personne qui pourrait partir demain. Formuler la dette technique en termes de risque est souvent plus audible que de la formuler en termes de qualité technique.
Ce qu’il faut retenir
La dette technique n’est pas un problème que les équipes IT ont créé seules. C’est le résultat d’une série de décisions organisationnelles — privilégier la vitesse sur la qualité, repousser les investissements de maintenance, ne pas allouer de budget au refactoring — que les directions business et les directions financières ont prises ou validées.
La résoudre nécessite donc une conversation au bon niveau — pas une conversation technique entre développeurs, mais une conversation stratégique sur le niveau de risque acceptable, le coût réel de l’inaction, et la façon dont le budget IT est structuré pour permettre à la fois le run, l’innovation et la maintenance de la santé technique des systèmes.
Chez Kalyptus, nous rencontrons régulièrement des DSI et des CTO qui portent seuls cette conversation difficile. Faire entrer les bons profils — architectes techniques capables de rendre la dette visible, leaders IT capables de la piloter politiquement — est souvent la première étape. C’est un sujet sur lequel nous avons beaucoup à partager.