La dette technique, tout le monde en parle. En réunion d'équipe, entre deux tâches, dans les couloirs. Et pourtant, elle finit presque toujours en bas de la pile, juste derrière la feature qui, elle, a un ticket Jira, un sponsor et une date de mise en prod. Le problème n'est pas que personne ne s'en soucie. Le problème, c'est qu'elle reste un sujet d'ambiance quand elle devrait être un sujet de comité de direction.
Le vrai souci n'est pas la dette, c'est son flou
« Il faudrait refactorer ce module. » « Ce composant, c'est un château de cartes. » On connaît tous ces phrases. Elles sont vraies, elles sont sincères, et elles ne convainquent jamais personne au-dessus du niveau tech lead. Pas parce que les décideurs ne comprennent rien au code, mais parce qu'on leur demande d'arbitrer entre quelque chose de concret (une feature, un chiffre d'affaires, un client qui attend) et quelque chose de vague : un inconfort d'ingénieur.
Tant que la dette technique reste une intuition, elle perdra systématiquement l'arbitrage. Ce n'est pas un problème de conviction, c'est un problème de langage.
Chiffrer, concrètement
Chez Olympp, on a arrêté de plaider la dette technique à l'instinct. On la mesure avec trois indicateurs simples, qui ne demandent ni outil magique ni grand chantier de mesure :
- Le temps de contournement par sprint : combien d'heures l'équipe passe-t-elle, chaque itération, à faire un détour parce que le code ne permet pas de faire les choses proprement ? Un workaround qu'on recopie trois fois, une variable de config qu'on doit modifier à la main à chaque déploiement.
- La récurrence des incidents sur un même module : un bug qui revient trois fois en six mois sur la même brique n'est pas un bug. C'est un symptôme.
- Le temps d'onboarding sur cette partie du code : combien de temps faut-il à un développeur expérimenté pour devenir autonome sur ce module précis, comparé au reste du système ?
Trois chiffres, un ordre de grandeur, et la dette technique change de statut. Elle ne parle plus le langage de l'inconfort, elle parle celui de la roadmap : temps perdu, risque de panne, coût de recrutement et de formation. Le même langage qu'une feature.
Chiffrée, elle devient négociable
Une fois qu'un module coûte objectivement quinze heures de contournement par sprint et deux incidents par trimestre, la question change de nature. Ce n'est plus « est-ce qu'on a le temps de refactorer », c'est « est-ce qu'on continue à payer quinze heures par sprint, indéfiniment, pour éviter d'en investir quarante une bonne fois ». Posée comme ça, la décision se prend en quelques minutes en comité, pas en plusieurs rétros frustrantes.
C'est aussi ce qui permet de prioriser entre plusieurs dettes techniques, plutôt que de traiter la plus bruyante au lieu de la plus coûteuse. Tout le monde a en tête le module que « tout le monde déteste » ; ce n'est pas toujours celui qui coûte le plus cher.
Un exemple terrain
« Sur une des missions où j'étais, il y avait un module que tout le monde contournait en silence depuis des mois : une synchro à relancer à la main à chaque déploiement, un correctif recopié à trois endroits dès qu'un cas limite sortait. Une fois qu'on a mis des chiffres dessus, environ douze heures de contournement par sprint, trois incidents en quatre mois, ça a changé la conversation en comité. Ce n'était plus un ressenti d'équipe, c'était un calcul. La décision de refactorer s'est prise en dix minutes. » Un Olymppien
La partie inconfortable
Chiffrer la dette technique a un effet collatéral qu'on sous-estime souvent : ça oblige à l'assumer publiquement, y compris quand on en est soi-même à l'origine. Le raccourci pris trois ans plus tôt en mode rush, la dépendance ajoutée pour tenir un deadline, l'architecture qu'on savait bancale au moment même où on l'a livrée. Un backlog de dette technique honnête commence toujours par ses propres décisions passées, pas seulement par celles de l'équipe précédente.
C'est précisément pour ça que ça fonctionne. Un backlog de dette qui ne pointe jamais vers soi-même n'est pas un backlog, c'est un procès. Et personne n'arbitre correctement un procès.
En pratique
Pas besoin d'un audit externe ni d'un outil de scoring complexe pour démarrer. Un tableau partagé, trois colonnes (temps de contournement, incidents, onboarding), et une mise à jour toutes les deux ou trois sprints suffisent à transformer une conversation d'ambiance en argument de comité. La dette technique ne disparaît jamais par la discussion. Elle se traite quand elle a un prix, et qu'on ose le dire à voix haute.
