La dette technique se chiffre sans lire une ligne de code. Elle se paie chaque mois dans des postes que votre entreprise suit déjà : le délai entre une demande métier et sa mise en service, les heures de contournement manuel, les incidents, les projets reportés et quelques risques que personne n'a encore évalués. Il suffit donc de suivre ces postes pendant trente jours à partir de vos tickets, de vos plannings et de vos factures, puis de les additionner sous forme de fourchette, pour obtenir un chiffre défendable en comité.
Quel chiffre apporter à la prochaine réunion budgétaire ?
Apportez le délai réel de vos trois dernières demandes métier, tiré de l'historique des tickets de votre DSI. Repérez-y les trois dernières évolutions livrées pour un métier, comme un champ ajouté ou un nouveau rapport, et comptez pour chacune les jours ouvrés entre la demande et la mise en production. Tout le comité lit ce nombre de la même façon.
Interrogez ensuite le métier sur la façon dont il a travaillé en attendant. La réponse décrit souvent un fichier Excel tenu à côté du système, et ce fichier est votre premier coût caché.
Pourquoi « le système est vieux » ne suffit pas à obtenir un budget ?
Un comité de direction arbitre entre des montants, et l'âge d'un logiciel n'en est pas un. Face à une demande de refonte, la direction financière pose une question simple : combien perdons-nous si nous attendons un an de plus ?
Dans un rapport présenté à OOPSLA en 1992, Ward Cunningham comparait la livraison d'un premier code imparfait à un emprunt, chaque minute passée sur du code bancal comptant comme un intérêt. Martin Fowler précise que l'effort supplémentaire pour ajouter une fonctionnalité est justement cet intérêt. Le capital (réécrire ce qui a été mal fait) se paie une fois, alors que l'intérêt revient à chaque demande, donc c'est lui que vous allez mesurer.
Les outils d'analyse de code comme SonarQube mesurent surtout le capital, en additionnant les temps de correction estimés de chaque défaut de maintenabilité. Ce chiffre sert votre DSI. En revanche, il ne dit rien des jours que vos responsables de maintenance passent à attendre un rapport.
Que coûte la dette technique, concrètement ?
Elle coûte du temps aux équipes métier qui attendent comme aux développeurs qui contournent un code fragile, et elle se paie en heures de travail manuel, en incidents, en licences. S'y ajoute le risque d'un système qu'une seule personne sait modifier, ou que l'éditeur ne corrige plus, et qui peut s'arrêter pour une durée que personne n'a estimée.
Pour un ordre de grandeur, les développeurs interrogés en 2018 par Stripe et Harris Poll aux États-Unis, au Royaume-Uni, en France, en Allemagne et à Singapour estimaient qu'un développeur de leur entreprise consacre en moyenne 13,5 heures par semaine à la dette technique, sur une semaine de 41,1 heures. Cela dit, cette estimation déclarative, ancienne et faite hors du Maroc, ne remplace pas votre propre mesure.
Quelle mesure parle le mieux à un comité de direction ?
Le délai entre une demande métier et sa mise en service se compte en jours et parle au directeur industriel comme au DAF. Les indicateurs DORA, que votre DSI connaît peut-être, suivent un délai voisin, le « change lead time », mesuré de l'enregistrement d'une modification à son déploiement. Ce compteur démarre trop tard pour votre question, car il ignore la file des demandes et les arbitrages qui précèdent le développement.
Chronométrez quatre demandes types : un nouveau champ dans un écran, un nouveau rapport, un nouveau profil d'utilisateur, une nouvelle règle de validation. Pour chacune, notez le délai réel et les heures de travail que l'équipe technique y a passées. Un champ qui demande deux heures de travail et six semaines de calendrier appelle une explication.
Tout cet écart ne vient pas de la dette. Une étude de cas industrielle parue en 2024 sur six composants logiciels trouve des effets contrastés : selon le composant, la dette explique de 5 % à 41 % de la variation des délais, et les auteurs avancent que d'autres facteurs, comme la taille des changements, leur complexité ou le nombre d'équipes impliquées, pèsent aussi. C'est pourquoi l'attente d'arbitrage se range du côté de votre gouvernance, alors que le temps de développement et de test excédentaire, quand personne n'ose toucher au module, relève bien de la dette.
Comptez aussi les décisions reportées faute d'un chiffre disponible à temps, comme l'investissement dans une deuxième ligne de conditionnement repoussé d'un mois parce que personne ne se fiait à l'extraction des temps d'arrêt. Les comptes rendus de comité des six derniers mois en gardent la trace.
Quelle grille utiliser pour chiffrer chaque poste ?
Comme un chiffre sans propriétaire sera contesté, chaque ligne a un responsable. Le coût horaire chargé, fourni par la direction financière, sert de multiplicateur commun.
| Poste de coût | Où trouver la donnée | Formule annuelle | Qui porte le chiffre |
|---|---|---|---|
| 1. Délai sur les demandes métier | Tickets, courriels, dates de mise en production | jours ouvrés au-delà du délai cible × demandes par an × heures de contournement par jour × coût horaire | Direction métier, avec la DSI |
| 2. Incidents et interruptions | Journal des incidents, tickets du support | (heures d'arrêt × personnes bloquées + heures de correction) × coût horaire | DSI, exploitation |
| 3. Contournements et ressaisies | Entretiens par équipe, fichiers Excel parallèles | heures par semaine × semaines travaillées × coût horaire | Chaque responsable d'équipe |
| 4. Projets et décisions reportés | Liste des projets, comptes rendus de comité | gain annuel attendu × mois de retard ÷ 12, en heures pour du temps gagné, en montant pour une recette | Bureau de projets, avec le contrôle de gestion |
| 5. Exploitation du socle obsolète | Factures de licences, de maintenance et d'hébergement | coût annuel actuel moins coût d'un socle à jour équivalent | DAF avec la DSI |
| 6. Dépendance à une personne clé | Liste des modules qu'une seule personne sait modifier | coût de remplacement × probabilité d'absence ou de départ dans l'année | DRH avec la DSI |
| 7. Versions non supportées | Inventaire des logiciels, dates de fin de support des éditeurs | support étendu ou mise à niveau imposée, plus une fourchette d'incident | RSSI ou DSI |
Une même heure ne se compte qu'une fois. Le contournement lié à une demande en attente va en ligne 1, la ressaisie permanente en ligne 3, et avant de valider, chaque responsable vérifie qu'aucune heure ne figure sur deux lignes.
Additionnez les heures des lignes 1 à 4 et convertissez-les en montant avec le coût horaire. Un gain reporté ne se compte en heures que s'il s'agit de temps gagné, alors qu'une recette attendue s'inscrit en montant, à côté de la ligne 5, que les factures donnent déjà chiffrée. Les deux dernières lignes restent à part, en fourchette basse et haute. Un DAF accepte volontiers une heure mesurée, beaucoup moins une probabilité.
Pour la septième ligne, les dates de fin de support sont publiques : Microsoft a ainsi cessé les mises à jour de sécurité standard de Windows Server 2012 et 2012 R2 le 10 octobre 2023.
Comment mener la mesure en trente jours ?
Le protocole ne demande ni audit de code ni outil nouveau, seulement quelques heures par semaine des équipes nommées dans le tableau.
| Période | Ce que vous faites | Qui s'en charge |
|---|---|---|
| Semaine 1 | Nommer un responsable par ligne, obtenir le coût horaire, choisir les demandes types | DG ou DSI, DAF |
| Semaine 2 | Dater les évolutions des six derniers mois, suivre chaque nouvelle demande | DSI, directions métier |
| Semaine 3 | Entretiens sur les contournements, extraction des incidents et des factures, fins de support | Responsables d'équipe, DSI, DAF |
| Semaine 4 | Relire les comptes rendus de comité, remplir la grille, faire valider chaque ligne | Contrôle de gestion |
| Jour 30 | Une page avec le total annuel, les deux postes les plus lourds et les deux risques | DSI et DAF ensemble |
Gardez ensuite le suivi trimestriel des quatre demandes types, et refaites la grille complète chaque année, au moment du budget.
Combien d'heures la grille fait-elle apparaître dans une usine ?
Une usine planifie sa production et sa maintenance sur un logiciel vieillissant, relié à l'ERP par une interface maison. Cette usine est fictive. Les valeurs ci-dessous sont des hypothèses choisies pour montrer le calcul, et elles ne décrivent ni une entreprise réelle ni une moyenne du marché.
| Poste | Hypothèses de l'exemple | Heures par an |
|---|---|---|
| Délai sur les demandes | 40 demandes par an, délai cible de 10 jours ouvrés, délai mesuré de 35 jours ouvrés, une heure de contournement par jour ouvré d'attente en trop | 40 × 25 × 1 = 1 000 |
| Ressaisies permanentes | 3 planificateurs qui ressaisissent les ordres de fabrication, 5 heures par semaine chacun, 45 semaines | 3 × 5 × 45 = 675 |
| Incidents | 6 arrêts de 4 heures, 25 personnes bloquées, 12 heures de correction par arrêt | 6 × (4 × 25 + 12) = 672 |
| Projet reporté | Planification automatique de la maintenance préventive décalée de six mois, gain attendu de 1 500 heures par an | 1 500 × 6 ÷ 12 = 750 |
| Total mesuré | 3 097 |
Le Code du travail marocain fixe la durée normale à 44 heures par semaine dans les activités non agricoles, soit 2 288 heures par an. Après congés et jours fériés, l'exemple retient 45 semaines travaillées, comme pour les ressaisies, soit environ 1 980 heures par personne. Les 3 097 heures du total représentent ainsi un peu plus d'un poste et demi à temps plein, perdu ou pas encore gagné, dont 750 heures de gain que le projet reporté n'a pas encore produites. Multipliées par le coût horaire chargé, elles donnent le montant annuel de l'intérêt. Puisque l'entreprise n'a pas encore chiffré de socle à jour, la ligne d'exploitation reste vide.
Les deux risques figurent sur la même page sans s'ajouter aux heures : une seule personne sait modifier l'interface entre le logiciel de planification et l'ERP, et le serveur qui l'héberge tourne sous Windows Server 2012. Le comité dispose ainsi d'environ 3 100 heures par an et de deux risques datés, à comparer au montant nécessaire pour corriger les deux postes les plus lourds.
Que faire du chiffre une fois la grille remplie ?
Le chiffre sert à arbitrer un périmètre. Souvent, la dette la plus coûteuse se loge entre les applications, dans l'export nocturne vers la comptabilité ou l'interface que personne n'a documentée, et c'est sur cette frontière que porte la correction. Notre article sur l'architecture par processus plutôt que par direction aide à les repérer.
Traitez d'abord les deux ou trois postes dont le coût annuel pèse le plus face au montant nécessaire pour les réduire. Réécrire une interface ou isoler un module relève du développement sur mesure et se suit avec la même grille. Si la grille montre en revanche que le socle entier pèse sur tous les postes, comparez les approches de notre guide sur la modernisation du système d'information, cette fois avec un chiffre en main.
FAQ
- Qui doit piloter ce chiffrage, la DSI ou la direction financière ?
Confiez-le aux deux, avec des rôles distincts : la DSI fournit les dates, les incidents et l'inventaire des versions, tandis que la direction financière fournit le coût horaire chargé et valide les formules. Une DSI seule s'expose au soupçon de plaider pour son propre budget, alors qu'un binôme DSI et DAF rend le chiffre bien plus difficile à contester.
- Comment retrouver les dates si nos demandes ne passent par aucun outil de tickets ?
Les courriels suffisent pour démarrer, car la date du premier message qui formule la demande et celle du message qui annonce la mise en service donnent un délai exploitable, même approximatif. Reconstituez ainsi une dizaine de demandes récentes, puis tenez un tableau partagé où chaque nouvelle demande reçoit ses dates d'entrée et de sortie.
- Que répondre si l'équipe technique conteste les chiffres ?
Invitez-la à corriger la grille plutôt qu'à la rejeter. Chaque ligne affiche sa source et sa formule, si bien qu'un désaccord porte sur une hypothèse précise et se règle en vérifiant la donnée. L'équipe technique a d'ailleurs intérêt à ce chiffrage, puisque sa plainte sur un système vieillissant devient un dossier qu'un comité peut financer.
Sources
- Ward Cunningham, OOPSLA 1992
- Martin Fowler, Technical Debt
- DORA, indicateurs de livraison logicielle
- SonarQube, métriques de code
- Stripe, The Developer Coefficient (2018)
- Paudel et al., dette technique et délais (2024)
- Microsoft, fin de support de Windows Server 2012
- Code du travail, article 184 (ministère de la Justice)
Dernière vérification : 1er novembre 2026.
Nous pouvons remplir cette grille avec vos responsables de ligne lors d'un audit gratuit, si vos équipes manquent de temps pour la collecte. Sur la septième ligne, une échéance est d'ailleurs déjà passée. Les mises à jour de sécurité étendues de Windows Server 2012 et 2012 R2, payantes pour les serveurs installés dans vos locaux, ont pris fin le 13 octobre 2026.
