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 génère pas d'intérêts réguliers — elle explose 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 aléatoirement et qu'on relance « en croisant les doigts »
• Pipeline CI/CD sans cache qui rebuild tout à chaque commit
• Pas de feature flags donc on accumule du code derrière 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 un merge et la prod
< 15 min → excellent
15-60 min → acceptable
> 1h → dette critique

2. Les nouvelles features prennent 3x plus de temps

Si une feature qui « devrait prendre 2 jours » en prend systématiquement 6, ce n'est pas un problème d'estimation. C'est que chaque changement nécessite de toucher à 15 fichiers, de comprendre 3 couches d'abstraction inutiles, et de 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. Le bus factor à 1

Si une seule personne comprend le système de paiement, l'intégration API, ou la config de déploiement, vous avez un bus factor de 1. 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 : une démission, et tout s'arrête.

Signaux concrets

• Les code reviews sont toujours assignées à la même personne
• Certains fichiers n'ont qu'un seul contributeur depuis 12 mois
• L'onboarding d'un nouveau dev prend plus de 2 semaines

4. Les erreurs en production sont « normales »

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

• Plus de 50 erreurs non résolues dans le tracker
• Des try/catch qui avalent les exceptions silencieusement
• Le monitoring existe mais personne ne le regarde

Chez ETX Majelan, la première chose que j'ai faite en arrivant a été de passer l'uptime 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 de 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 :

1. Cartographier — identifier les zones à risque (complexité, couplage, couverture de tests)
2. Chiffrer — estimer l'impact en vélocité (combien de temps perdu par sprint)
3. Prioriser — attaquer d'abord ce qui bloque la vélocité, pas ce qui dérange les puristes
4. Budgéter — allouer 20% de chaque sprint à la remédiation, pas 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 bonnes contraintes du moment. Le problème, c'est de ne pas la mesurer.