Guide approfondi
Simulateur de perte de vélocité due à la dette technique : ce que coûte le travail de reprise à votre équipe d'ingénierie
Analyse sectorielle pour décideurs
La dette technique est le coût accumulé des raccourcis : du code qui fonctionne mais qu'il est difficile de modifier, des tests manquants, des dépendances enchevêtrées et de vieux systèmes que personne ne comprend. Elle apparaît rarement dans un budget. Elle se manifeste plutôt par le sentiment que tout prend plus de temps qu'avant. Les estimations dérapent, de petits changements cassent des choses sans rapport et l'équipe passe des sprints à un travail qui ne crée rien de nouveau. La facture n'arrive pas sous forme de charge mais sous forme d'un nombre plus faible de fonctionnalités livrées chaque mois pour la même masse salariale.
La structure du problème est une taxe sur la capacité. Si un cinquième de chaque sprint part en contournements et reprises, l'équipe se comporte comme si elle était d'un cinquième plus petite, alors que les salaires sont inchangés. La dette se cumule aussi. Chaque nouvelle fonctionnalité construite sur une base fragile ajoute de la complexité : la part perdue grandit donc, sauf si un effort est consacré au remboursement. Rembourser la dette coûte de la production maintenant, ce qui rend toujours tentant de reporter, et explique pourquoi la décision mérite des chiffres.
Le modèle en dominos suit la perte. La part du sprint perdue en dette réduit la capacité disponible pour le travail nouveau, ce qui réduit les fonctionnalités livrées. Moins de fonctionnalités réduisent la valeur livrée par dollar de masse salariale, et le poids des reprises, des pompiers et de la rotation grandit avec la dette. La dernière case compare la valeur livrée au vrai coût de l'équipe. Une hausse modeste de la dette peut transformer un bon rendement en perte, car la masse salariale est fixe tandis que la valeur ne l'est pas.
L'iceberg montre ce que la ligne de masse salariale cache. Le visible est la masse salariale elle-même. Sous la ligne de flottaison se trouvent la part de la masse salariale consacrée aux reprises, les pompiers que la dette provoque en production, la rotation des ingénieurs qui quittent des bases de code épuisantes et la valeur des fonctionnalités qui n'ont jamais été construites. Le dernier poste est un coût d'opportunité qui n'apparaît jamais dans les comptes, et pourtant c'est généralement le plus grand. Utilisez le simulateur pour trouver le niveau de dette où l'équipe cesse de s'autofinancer, et pour tester si un plan de remboursement en vaut la peine.
Formules et méthodologie
Le modèle est une vue mensuelle d'une équipe produit. La masse salariale est les ingénieurs multipliés par le coût chargé. Une part du sprint va à la dette et une part au remboursement délibéré, et le reste construit de nouvelles fonctionnalités. Les fonctionnalités livrées sont les ingénieurs multipliés par les fonctionnalités par ingénieur et par cette part restante, valorisées à la valeur par fonctionnalité. La dette provoque aussi des incidents, en proportion du coût des reprises, et augmente la rotation, chiffrée à quatre mois de salaire chargé par remplacement. Dans la projection, la dette dérive à la hausse chaque mois sauf si le remboursement est financé.
- Part de construction
- c = 1 − dette − remboursement
- La portion du sprint qui va dans les nouvelles fonctionnalités.
- Fonctionnalités livrées
- F = ingénieurs × fonctionnalités par ingénieur × c
- Les nouvelles fonctionnalités livrées en un mois.
- Coût des reprises
- R = masse salariale × dette
- La masse salariale qui n'a acheté aucune valeur nouvelle.
- Coût de la rotation
- A = ingénieurs × (1 % + 0,06 % × points de dette) × 4 mois × coût
- Le coût mensuel attendu du remplacement d'ingénieurs, qui augmente avec la dette.
- Résultat net
- Net = F × valeur − masse salariale − 0,15 × R − A
- La valeur livrée moins le vrai coût de l'équipe. Le point de rupture est celui où il atteint zéro.
Élasticité en cascade
La part de dette est la variable la plus élastique, car elle réduit la production tout en augmentant en même temps les coûts d'incidents et de rotation. La valeur par fonctionnalité et les fonctionnalités par ingénieur font varier l'ensemble du rendement. Le coût de la masse salariale compte parce que c'est la base fixe que la valeur doit dépasser.
Trois études de cas concrètes
Démarrage en autofinancement
Une petite équipe avec une base de code propre
Une équipe de trois personnes maintient une faible dette, livre vite et valorise fortement chaque fonctionnalité par rapport à la masse salariale. Les reprises sont faibles. Ce scénario montre l'avantage initial d'une base propre, et le peu de dette nécessaire pour commencer à l'éroder.
Croissance d'une entreprise de taille intermédiaire
Une grande équipe qui investit dans le remboursement
Une équipe de quarante-cinq personnes porte une dette modérée mais réserve un dixième de chaque sprint au nettoyage. Les fonctionnalités sortent à un bon rythme et les incidents restent rares. Ce scénario montre pourquoi un remboursement discipliné passe à l'échelle.
Crise de type cygne noir
Une base de code en forte croissance que personne ne peut modifier
Une équipe de vingt-cinq personnes a hérité d’années de raccourcis. Plus de la moitié de chaque sprint part en reprises et incidents, la rotation est élevée et le temps de remboursement est nul. Ce scénario montre une grosse masse salariale qui produit peu, et le levier qui redresse le mois.
Matrice des repères sectoriels
| Indicateur | Zone de danger | Moyenne du secteur | Élite : les 10 % meilleurs |
|---|---|---|---|
| Part du sprint perdue en reprises | Plus de 40 % | 15–25 % | Moins de 10 % |
| Temps réservé au remboursement de la dette | Zéro | 5–10 % | 15–20 % si nécessaire |
| Valeur livrée par dollar de masse salariale | Moins de 1,0 | 1,2–1,6 | Plus de 2,0 |
| Rotation mensuelle des ingénieurs | Plus de 2,5 % | 1–1,5 % | Moins de 1 % |
| Travail sur incidents en part du coût des reprises | Plus de 25 % | 10–15 % | Moins de 8 % |
Variables et leviers
Ingénieurs dans l'équipe
Les développeurs qui travaillent sur le produit, comptés en équivalents temps plein.
Levier: N'ajoutez pas d'ingénieurs à une équipe très endettée en premier lieu, car chaque nouvelle personne hérite du même frein et ralentit l'intégration.
Coût chargé par ingénieur et par mois
Salaire plus charges, avantages, équipement et frais généraux pour un ingénieur sur un mois.
Levier: Alignez les salaires sur le marché mais réduisez les frais généraux cachés, car chaque heure perdue à cause de la dette est payée au taux chargé complet.
Part du sprint perdue en dette et reprises
Part du temps d'ingénierie passée en contournements, corrections de bogues, compilations lentes et lutte contre l'ancien code au lieu de nouvelles fonctionnalités.
Levier: Rendez la dette visible : listez les pires modules, estimez les heures de reprise et corrigez d'abord ceux qui touchent le plus de fonctionnalités.
Fonctionnalités par ingénieur et par mois (sans dette)
Le nombre de fonctionnalités significatives qu'un ingénieur livrerait en un mois si aucun temps n'était perdu à cause de la dette.
Levier: Supprimez les frictions de compilation, de test et de relecture, car l'expérience des développeurs détermine le nombre de fonctionnalités qu'une personne peut livrer.
Valeur mensuelle d'une fonctionnalité livrée
Chiffre d'affaires, économies ou fidélisation qu'une fonctionnalité typique apporte chaque mois une fois livrée, selon votre propre estimation.
Levier: Livrez des fonctionnalités qui font bouger le chiffre d'affaires ou la fidélisation ; si la valeur livrée est faible, aucune vélocité ne rendra l'équipe rentable.
Part du sprint investie dans le remboursement de la dette
Part du sprint délibérément consacrée à réduire la dette. Elle coûte de la production maintenant et réduit la dette plus tard.
Levier: Réservez une part régulière de chaque sprint, souvent de dix à vingt pour cent, à la dette qui bloque les travaux à venir.
Comment utiliser ce simulateur
- 1Partez du préréglage réaliste ou saisissez la taille de votre équipe, le coût chargé et votre part de reprises estimée.
- 2Lisez les cinq cases de l'effet domino pour voir si la vélocité ou le poids de la dette passe au rouge en premier.
- 3Appuyez sur « Trouver mon point de rupture » pour voir la part de dette qui rend l'équipe non rentable.
- 4Comparez le plan actuel avec le plan de remboursement sur le graphique de 24 mois.
- 5Mesurez les reprises pendant quelques sprints et réexaminez le modèle chaque trimestre.
Erreurs à éviter
- Considérer le temps perdu à cause de la dette comme gratuit parce que les salaires sont fixes, alors que chaque heure porte le coût chargé complet.
- Ajouter des ingénieurs à une base de code lente en attendant que la vélocité augmente proportionnellement.
- Planifier une grosse réécriture au lieu de rembourser régulièrement la dette là où elle bloque les travaux à venir.
- Ignorer la rotation, qui est un coût réel et récurrent d'un code désagréable.
Questions fréquentes
Comment estimer la part du sprint perdue en dette ?
Étiquetez pendant quelques sprints les tickets et demandes de fusion qui relèvent de reprises, de corrections de bogues ou de contournements, puis divisez ce temps par le temps d'ingénierie total. Demandez à l'équipe un chiffre approximatif pour recouper.
Toute dette technique est-elle mauvaise ?
Non. Prendre un raccourci pour apprendre plus vite ou tenir une échéance peut être un bon arbitrage, à condition de le suivre et de le rembourser. La dette devient un problème quand elle n'est pas gérée et se cumule.
Combien de temps consacrer au remboursement ?
Cela dépend du niveau de dette et des travaux à venir. Un effort régulier de dix à vingt pour cent est courant, mais consacrez-le à la dette qui bloque les fonctionnalités prévues plutôt qu'à un nettoyage pour lui-même.
Comment valoriser une fonctionnalité ?
Estimez, même grossièrement, le chiffre d'affaires mensuel, la fidélisation ou les économies qu'elle apporte. Si vous n'y arrivez pas, prenez comme point de départ la croissance moyenne du chiffre d'affaires divisée par les fonctionnalités livrées.
Comment trouver le niveau de dette où l'équipe perd de l'argent ?
Appuyez sur « Trouver mon point de rupture ». L'outil pousse chaque variable vers son extrémité la plus défavorable et indique la valeur à laquelle le bénéfice mensuel atteint zéro.
Quelle est la précision de cet outil ?
C'est un modèle pédagogique aux hypothèses indiquées, et non un conseil de gestion. Les résultats réels de l'ingénierie dépendent de nombreux facteurs. Remplacez les valeurs par vos propres données.
Il s'agit d'un modèle de planification à visée pédagogique, fondé sur des hypothèses explicites. Il ne constitue ni un conseil financier, ni un conseil fiscal, ni un conseil juridique. Remplacez les données par vos propres chiffres et faites valider les décisions importantes par un professionnel qualifié.