Coût de la dette technique : les heures sont déjà payées

Une équipe fictive de six développeurs, 468 600 € de coût annuel, dont 182 196 € que le calculateur attribue à la dette technique. Personne ne les a vus partir : aucune facture ne les porte. Demandez à un dirigeant ce que lui coûte sa dette, il cherchera cette facture. Supprimer la dette ne retire pas un euro de la masse salariale, et il la paie pourtant, chaque semaine, sur la ligne qu’il regarde le moins : les heures de son équipe.

Ce montant représente une part de capacité : une part des heures déjà payées qui part dans les corrections, l’attente autour des mises en production, les tâches refaites à la main, la prudence qu’exige un code que plus personne n’ose toucher. Cette part ne se voit pas, parce que personne ne la compte. Le calculateur de coût de la dette technique sert à ça : la rendre visible, en euros parce que c’est la langue d’un comité de direction. Pas à produire un chiffre exact. Il porte sur le code, l’outillage et la livraison ; les cinq visages de la dette technique rappellent que la dette organisationnelle ou de sécurité coûte ailleurs.

Le calcul part de deux chiffres que vous connaissez : la taille de l’équipe et le salaire brut annuel moyen d’un développeur. Le salaire est multiplié par 1,42 pour approcher le coût employeur, un ordre de grandeur inspiré du simulateur Mon-entreprise de l’Urssaf pour un CDI cadre, réglable. Divisé par 1 820 heures, 52 semaines de 35 heures, il donne un taux horaire ; multiplié par le nombre de développeurs, ce que l’équipe vous coûte par an. Chaque poste estime ensuite combien d’heures partent dans un travail que la dette impose. Le résultat est de la capacité perdue, pas une dépense en plus. Une équipe qui récupère ces heures ne vous coûte pas moins cher. Elle peut enfin consacrer ces heures à la roadmap que vous attendez.

Y a-t-il une part normale ? Le seul repère public que j’ai pu vérifier est une moyenne déclarée : dans The Developer Coefficient, enquête de Stripe avec Harris Poll en 2018 auprès de plus de 1 000 développeurs, les répondants estimaient passer 17,3 heures par semaine en maintenance, sur une semaine moyenne de 41,1 heures. Environ 42 %, et ce ratio est mon calcul, pas un chiffre de l’étude. Ce n’est pas un seuil sain, c’est ce que des développeurs disent vivre.

Un chiffre dont on cache la formule ne vaut rien devant un comité de direction. Voici le moteur, constantes comprises.

Poste	Formule
Bugs en production	bugs par semaine × 4 h de correction × taux horaire × 52 semaines
Friction de déploiement	heures perdues par développeur et par semaine × nombre de développeurs × taux horaire × 52
Manque de tests	max(0, seuil de couverture − couverture en points) / 100 × 25 % × coût annuel de l’équipe, plafonné à 15 % de ce coût
Processus manuels	heures manuelles par semaine pour l’équipe × taux horaire × 52
Entropie de la base de code	max(0, âge en années − 3) × 3 % × coût annuel de l’équipe
Absence de CI/CD	2 h par développeur et par semaine × nombre de développeurs × taux horaire × 52

La friction va de 0,5 heure par développeur et par semaine en déploiement quotidien à 5 heures en mensuel. Les 4 heures par bug, le taux de charges de 42 % et le seuil de couverture, fixé à 60 % par défaut, se règlent ; le plafond de 15 % ne bouge pas. Le total est rapporté au coût annuel de l’équipe : risque 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 €.

Équipe fictive, moteur réel. Six développeurs à 55 000 € brut par an en moyenne, soit 78 100 € de coût employeur chacun, 468 600 € pour l’équipe, un taux horaire de 42,91 €. Déploiement toutes les deux semaines, sans CI/CD, trois bugs de production par semaine, cinq heures de tâches manuelles, 30 % de couverture de tests, une base de code de six ans. Le portrait vous est peut-être familier ; ces chiffres restent des hypothèses.

Poste	Calcul	Coût annuel
Bugs en production	3 × 4 h × 42,91 € × 52	26 777 €
Friction de déploiement (palier bimensuel)	3 h × 6 × 42,91 € × 52	40 166 €
Manque de tests	30 / 100 × 25 % × 468 600 €	35 145 €
Processus manuels	5 h × 42,91 € × 52	11 157 €
Entropie de la base de code	3 × 3 % × 468 600 €	42 174 €
Absence de CI/CD	2 h × 6 × 42,91 € × 52	26 777 €
Total		182 196 €

Le total fait 38,9 % du coût annuel de l’équipe, classé « critique » par le modèle. Converti en heures, ce total représente environ 4 250 heures par an, affichées en 607 jours-développeur : l’équivalent arithmétique de 2,3 postes sur six. Ce ne sont pas 2,3 postes que vous pouvez rendre à la roadmap. Avant de parler de capacité perdue, il faut vérifier ce que chaque poste compte, retirer les chevauchements et distinguer le travail nécessaire du travail évitable. Le modèle vous dit où regarder. Il ne sait pas ce qu’il y a dans votre code.

La ligne la plus lourde de l’exemple est aussi la moins mesurable. Les 3 % par année au-delà de trois ans sont une convention, pas une observation : une application de six ans bien découpée et testée paie le même montant qu’une application de six ans où chaque modification casse un autre parcours. Quatre heures par bug met une faute de libellé et une erreur de facturation au même tarif. Et le calcul ignore ce qui coûte souvent le plus cher : le client perdu après un incident, le contrat signé en retard, l’accès oublié qui expose des données. L’attente d’une validation, celle de la dette organisationnelle, n’y apparaît qu’en creux.

Donc ne budgétez pas sur ce chiffre. Confrontez-le à quelques semaines de réel : les corrections livrées sur la période, avec pour chacune le temps de diagnostic, de modification, de revue et de déploiement, séparé de l’attente calendaire. Cette moyenne remplace les quatre heures du modèle. Puis faites tourner plusieurs hypothèses prudentes dans le calculateur. Si le même poste reste en tête, vous tenez votre priorité. S’il change de rang à la moindre variation, vous n’avez pas encore assez de données pour engager un budget.

Le total du modèle additionne six postes. Dans votre équipe, leurs frontières se chevauchent : le déploiement manuel d’un correctif peut apparaître dans les bugs, dans les processus manuels et dans l’absence de CI/CD. Additionner les trois donne un gros chiffre. Cela ne crée pas trois heures dans l’agenda du développeur.

Je partirais d’un petit registre des interventions, relié aux tickets, pendant quelques semaines. Exemple fictif, indépendant de l’équipe de six développeurs ci-dessus : une correction arrive en production deux jours après son signalement. Voici le travail réellement effectué dans cet exemple.

Travail	Temps mobilisé
Diagnostic par un développeur	1 h
Modification et tests par ce développeur	2 h
Revue par un autre développeur	0,5 h
Déploiement manuel par le premier	0,5 h
Total de travail	4 h

Au taux illustratif de 42,91 € utilisé plus haut, cela représente 171,64 € de capacité mobilisée. Les deux jours calendaires racontent le délai subi par le client ; les quatre heures racontent le travail de l’équipe. La demi-heure de déploiement est déjà comprise dans les quatre heures. Si vous la classez aussi comme friction de livraison pour comprendre la cause, gardez ce second classement hors du total.

Ces quatre heures ne sont pas toutes, par définition, de la dette. Corriger un défaut comporte du travail nécessaire ; il faut identifier ce que les reprises, les dépendances ou les gestes évitables y ajoutent. Notez pour chaque intervention sa cause présumée, les personnes mobilisées et l’attente séparée. Une intervention, une ligne de temps, plusieurs causes possibles. Vous pourrez alors comparer une estimation aux traces de travail, sans présenter le total du calculateur comme une facture ni promettre que chaque heure reviendra après un refactoring.

Devant 182 196 €, le réflexe du dirigeant est de demander un plan de remboursement. Ce n’est pas la bonne question : la dette ne se rembourse pas d’un bloc, elle se renégocie poste par poste, dans un ordre qui n’est pas celui des montants.

Quand les incidents absorbent l’équipe, je regarde d’abord ce qui doit être stabilisé. Chez Gridky, où j’étais Head of Engineering, ce travail a pris la forme d’un gel des fonctionnalités d’un mois et demi. Le CTO et le CEO avaient arbitré le calendrier, toute l’équipe travaillait aux corrections et tout code touché devait être testé. À la reprise, l’équipe était réunifiée et mon tri manuel des exceptions, chaque matin, n’avait plus lieu d’être. Aucune ligne du calculateur ne vous dira de faire ça. Le calculateur n’a pas vu votre Slack.

La CI minimale suit : un build reproductible, les tests des chemins critiques, des contrôles avant d’intégrer une modification. Dans l’exemple, une CI fait passer le total de 182 196 € à 155 419 €, et un déploiement hebdomadaire le ramène à 135 336 € ; ce sont des écarts du modèle, pas un gain mesuré. L’automatisation vient en dernier, sur les deux ou trois tâches répétitives les plus coûteuses : ici, le plus petit poste, 11 157 €. Elle passe après la livraison, sauf si ce sont ces tâches qui retardent les mises en production.

Le chiffre du calculateur donne à la direction une hypothèse à vérifier : où partent les heures de l’équipe, et quelle part pourrait être évitée ? Faites-le tourner avec vos vrais chiffres, puis passez quelques semaines avec l’équipe à vérifier les deux postes les plus lourds. Pour décider quoi traiter, comparez le temps perdu qui revient chaque semaine au travail nécessaire pour en supprimer la cause. Rattacher ces postes à des causes précises, c’est le travail du diagnostic technique et organisationnel de cinq jours ; la page sur l’architecture et la dette technique décrit les situations dans lesquelles j’interviens.