5 signaux d'alerte d'une dette technique critique

La dette technique ne prévient pas

Chaque startup que j'ai auditée avait le même discours : « On sait qu'on a de la dette, mais on n'a pas le temps de s'en occuper. » Le problème, c'est que la dette technique ne se comporte pas comme une dette financière. Elle ne se rappelle pas à vous par une échéance mensuelle : elle s'accumule en silence, puis bloque tout d'un coup, quand il est trop tard.

Après 14 ans et plus de 30 audits techniques, j'ai identifié 5 signaux qui ne trompent pas.

1. Le temps de déploiement qui explose

Quand un déploiement prend plus de 30 minutes, c'est rarement un problème d'infrastructure. C'est un symptôme :

Tests instables qui échouent au hasard et qu'on relance « en croisant les doigts »
Chaîne CI/CD sans cache qui reconstruit tout à chaque commit
Pas de feature flags (interrupteurs de fonctionnalités), donc on accumule du code sur des branches de plus en plus longues

Le seuil d'alerte : si votre équipe hésite à déployer un vendredi, vous avez un problème.

Comment mesurer

Temps moyen entre une fusion et la production
< 15 min → excellent
15-60 min → acceptable
> 1 h → dette critique

2. Les nouvelles fonctionnalités prennent 3 fois plus de temps

Si une fonctionnalité qui « devrait prendre 2 jours » en prend systématiquement 6, ce n'est pas un problème d'estimation. C'est que chaque changement oblige à toucher 15 fichiers, à comprendre 3 couches d'abstraction inutiles, et à prier pour ne rien casser.

Les causes classiques :

Couplage fort entre les modules : on ne peut rien toucher sans effet de bord
Abstractions prématurées, créées « au cas où » et jamais utilisées comme prévu
Pas de documentation sur les décisions d'architecture passées

3. Une seule personne connaît le système

Si une seule personne comprend le système de paiement, l'intégration d'une API ou la configuration du déploiement, votre « bus factor » est de 1 : il suffit qu'elle parte pour que tout s'arrête. Ce n'est pas de la dette technique au sens strict, mais c'est un risque qui se matérialise de la même façon.

Signaux concrets

Les relectures de code sont toujours confiées à la même personne
Certains fichiers n'ont qu'un seul contributeur depuis 12 mois
L'intégration d'un nouveau développeur prend plus de 2 semaines

4. Les erreurs en production sont « normales »

Quand l'équipe traite les alertes Sentry comme un bruit de fond, quelque chose s'est cassé dans la culture de qualité. Les symptômes :

Plus de 50 erreurs non résolues dans l'outil de suivi
Des try/catch qui avalent les exceptions en silence
La supervision existe, mais personne ne la regarde

Chez ETX Majelan, la première chose que j'ai faite en arrivant a été de faire passer la disponibilité de 99,2 % à 99,9 %. Pas avec des outils miracles : en prenant chaque erreur au sérieux.

5. L'équipe évite certaines zones du code

Si les développeurs contournent systématiquement un module plutôt que de le modifier, c'est le signal le plus clair d'une dette toxique. Ils ont appris par l'expérience que toucher à ce code, c'est ouvrir la boîte de Pandore.

Le test simple

Demandez à 3 développeurs : « Quelle partie du code vous fait le plus peur ? » Si les 3 donnent la même réponse, c'est votre priorité numéro 1.

Comment agir

La dette technique ne se rembourse pas d'un coup. Voici l'approche que j'utilise en audit :

Cartographier : repérer les zones à risque (complexité, couplage, couverture de tests)
Chiffrer : estimer l'impact sur la vélocité (combien de temps perdu par sprint)
Prioriser : s'attaquer d'abord à ce qui freine la vélocité, pas à ce qui dérange les puristes
Budgéter : consacrer 20 % de chaque sprint au remboursement, plutôt qu'un « sprint dette » tous les 6 mois

La dette technique n'est pas un échec. C'est le résultat naturel de décisions prises avec les contraintes du moment. Le problème, c'est de ne pas la mesurer.

Pour une première mesure, le calculateur de dette technique vous donne en deux minutes un coût annuel chiffré, sans e-mail à laisser.