Combien vous coûte votre dette technique ?

Tout part du salaire annuel brut moyen que vous indiquez. Je le multiplie par 1,42 pour obtenir un coût employeur : 42 % de charges, un ordre de grandeur pour un CDI cadre en France. C’est une hypothèse, que le réglage avancé vous laisse remplacer par votre propre taux.

Ce coût est ensuite réparti sur 1 820 heures, soit 52 semaines de 35 heures. Les congés et les jours fériés ne sont pas déduits : le coût horaire obtenu est plus bas que la réalité, et l’estimation reste prudente. Avec 55 000 € brut, on obtient 78 100 € de coût employeur et environ 43 € de l’heure.

• Coût employeur annuel = salaire brut × 1,42.
• Coût horaire = coût employeur ÷ 1 820 heures.
• Coût de l’équipe = coût employeur × nombre de développeurs.

Chaque poste est un temps perdu, valorisé au coût horaire ou exprimé en part du coût annuel de l’équipe. Les durées par défaut sont des hypothèses de terrain, pas des mesures : je les écris ici pour que vous puissiez les comparer à votre équipe.

• Bugs en production : bugs par semaine × 4 heures de correction × coût horaire × 52 semaines. Les 4 heures sont réglables.
• Friction de déploiement : heures perdues par développeur et par semaine × taille de l’équipe × coût horaire × 52 semaines. L’hypothèse suit le rythme de mise en production : 0,5 h en quotidien, 1,5 h en hebdomadaire, 3 h toutes les deux semaines, 5 h en mensuel.
• Manque de tests : 0,25 % du coût annuel de l’équipe par point de couverture sous le seuil de 60 %, plafonné à 15 %. Le détail suit.
• Processus manuels : heures manuelles par semaine pour l’équipe × coût horaire × 52 semaines.
• Âge de la base de code : 3 % du coût annuel de l’équipe par année au-delà de 3 ans. Une base de 4 ans compte pour 3 %, une base de 15 ans pour 36 %.
• Absence de CI/CD : 2 heures perdues par développeur et par semaine × taille de l’équipe × coût horaire × 52 semaines, seulement si vous répondez non.

Ce poste estime la reprise : le temps passé à corriger, revérifier ou refaire un changement que des tests auraient sécurisé. Chaque point de couverture sous le seuil coûte 0,25 % du coût annuel de l’équipe. À 40 % de couverture, l’écart de 20 points donne 5 % ; à 0 %, il donne 15 %.

C’est une hypothèse, pas le résultat d’une étude. La couverture compte les lignes exécutées par les tests, pas la protection des parcours critiques : une équipe à 30 % bien placés peut être mieux protégée qu’une autre à 70 %. Pour qu’un seul chiffre ne gonfle pas le total, le poste est plafonné à 15 % du coût de l’équipe, quel que soit le seuil choisi.

Le seuil de 60 % est réglable. À 0, le poste disparaît : c’est la façon la plus simple de refaire le calcul sans cette hypothèse.

Tous les postes sont du temps payé. Le calculateur exprime donc aussi le total en jours-développeur de 7 heures et en part de la capacité annuelle de l’équipe. Avec les réponses par défaut, pour 5 développeurs à 55 000 € brut, l’estimation atteint 85 910 € par an : 286 jours-développeur, soit 22 % de la capacité de l’équipe.

Le taux de charges change les euros, pas cette part : il augmente dans la même proportion le coût de l’équipe et celui de la dette.

Le niveau de risque retient le plus élevé de deux critères : la part du coût annuel de l’équipe et le montant absolu. Le montant fait monter le risque d’une grande équipe même quand la part reste modeste, parce que 150 000 € par an relèvent déjà d’une décision de direction. Ces seuils sont des repères de lecture que j’ai fixés, pas une norme.

• Faible : jusqu’à 8 % du coût de l’équipe et jusqu’à 60 000 € par an.
• Modéré : au-delà de 8 % ou de 60 000 €.
• Élevé : au-delà de 15 % ou de 150 000 €.
• Critique : au-delà de 25 % ou de 300 000 €.

Si vous savez quelle part du temps de l’équipe part en maintenance (corrections, mises à jour, refactoring et support technique de l’existant, planifiés ou non), le mode rapide l’applique directement au coût annuel de l’équipe, calculé comme plus haut. Pour 5 développeurs à 55 000 € brut et 30 % de maintenance : 30 % de 390 500 €, soit 117 150 € par an et 390 jours-développeur.

Ce n’est pas le même calcul que le mode détaillé. Le mode détaillé reconstitue, poste par poste et à partir d’hypothèses, le temps que la dette prend. Le mode rapide part d’un temps que vous avez observé, mais ce temps contient aussi une maintenance saine : corriger un bug isolé, mettre à jour une dépendance, suivre un changement de réglementation ou d’API. Son résultat valorise ce temps déclaré. Il ne mesure ni le coût total de la dette ni son plafond : la dette peut aussi ralentir les nouvelles fonctionnalités, exclues de cette part.

Je n’ajoute ni « coût d’opportunité » ni multiplicateur. Ce que l’équipe n’a pas construit pendant ce temps a une valeur, mais elle dépend de votre produit et de votre marché : un coefficient fixe la ferait passer pour une mesure.

Pour situer une part déclarée, le seul repère publié que j’ai pu vérifier est une moyenne. Dans l’enquête The Developer Coefficient de Stripe (2018, avec Harris Poll), les développeurs interrogés estimaient en moyenne à 17,3 heures par semaine le temps passé en maintenance dans leur entreprise (mauvais code, erreurs, débogage, refactoring, modifications), pour une semaine moyenne de 41,1 heures. J’en déduis moi-même une part d’environ 42 %. Ce n’est pas un seuil sain, et je ne fixe pas de seuil à la place d’une norme qui n’existe pas.

• Coût de la maintenance = part déclarée × coût annuel de l’équipe.
• Jours-développeur = coût ÷ coût horaire ÷ 7 heures.
• Part de la capacité = la part déclarée, puisque tout est du temps payé.

Sources

• Stripe, The Developer Coefficient, septembre 2018 (PDF en anglais) (nouvel onglet)

En 2009, Martin Fowler a proposé de classer la dette technique selon deux axes : délibérée ou involontaire, prudente ou imprudente. Délibérée et prudente, c’est l’équipe qui livre plus tôt en connaissant le prix à payer ensuite. Délibérée et imprudente, c’est le « vite et mal » choisi parce qu’on croit ne pas avoir le temps de bien concevoir. Involontaire et imprudente, c’est l’équipe qui ignore les pratiques de conception et s’endette sans le savoir. Involontaire et prudente, c’est ce que découvre même une très bonne équipe : en avançant, elle comprend ce qu’aurait dû être la conception.

Pour Fowler, ce dernier cas est inévitable et doit être attendu : même les meilleures équipes accumulent cette dette au fil d’un projet. Un coût non nul n’est donc pas, en soi, le signe d’une faute. Il note aussi qu’une dette prudente logée dans du code rarement modifié peut ne pas valoir d’être remboursée, si ses intérêts restent faibles.

Le calculateur estime les intérêts : le temps que la dette prend chaque année, quelle que soit son origine. Il ne sait pas dans quel quadrant elle est née. La même semaine de corrections peut venir d’un raccourci assumé avant une échéance ou d’une conception dont on ignorait qu’elle pouvait être meilleure. Pour le savoir, il faut l’histoire des décisions : tickets, échanges, décisions d’architecture et mémoire de l’équipe.

• Ce que le calcul estime : le coût annuel des intérêts, en euros et en temps d’équipe.
• Ce qu’il ne dit pas : si la dette était délibérée ou involontaire, prudente ou imprudente, ni ce que coûterait son remboursement.
• Ce que le quadrant ajoute à la lecture : un coût porté par du code que la roadmap touche chaque semaine pèse davantage que le même coût dans une zone rarement modifiée.

Sources

• Martin Fowler, Technical Debt Quadrant, 14 octobre 2009 (en anglais) (nouvel onglet)

Le résultat sert à ordonner une discussion, pas à remplacer une mesure. Pour mesurer, il faut regarder le code, les incidents et le backlog.

• Les postes s’additionnent mais peuvent se recouvrir : des bugs fréquents et une couverture faible décrivent parfois le même temps perdu, comme l’absence de CI/CD et la friction de déploiement.
• Les durées par défaut (4 h par bug, heures de friction, 2 h sans CI/CD, 3 % par année d’âge) sont des hypothèses de terrain, pas des mesures publiées.
• L’âge n’est pas la dette : une base ancienne bien entretenue coûte moins que ce que le modèle indique, une base récente construite dans l’urgence peut coûter davantage.
• Le modèle ne compte ni les incidents vécus par les clients, ni le chiffre d’affaires perdu, ni le départ d’un développeur. Il estime de la capacité perdue, pas tout le risque.
• Sur une petite équipe aux réponses élevées, le total peut dépasser la capacité de l’équipe : c’est le signe que les postes se recouvrent.

• Vérifier les hypothèses du coût de la dette technique