Tous les mois, plusieurs factures atterrissent sur votre bureau : l'hébergeur, les licences SaaS, le TJM des devs.
Une que vous ne recevez jamais : celle de votre dette technique. Pourtant elle est là, ventilée sur des dizaines de lignes invisibles. Maintenance qui dérive, évolutions qui s'étirent, recrutements qui s'éternisent, audits sécurité qui ne passent plus. Chaque ligne se paye. La somme n'apparaît dans aucun bilan.
Cet article fait le calcul. On prend un projet PHP représentatif, on sort la calculette : poste par poste, en euros, pour le total année 1. Puis on relance le compteur trois ans plus tard pour voir l'effet composé.
Pour caler les fourchettes, j'ai croisé avec les benchmarks publics : Stripe sur le temps dev, McKinsey sur le budget IT, Free-Work pour les TJM, CNIL pour les amendes RGPD. Tout est sourcé en bas.
Le projet sur la table
PHP 7.4, Laravel 8, mise en production 2018. Quelque 80 dépendances composer, dont une vingtaine n'ont plus eu de release majeure depuis trois ans. Ratio de tests sous 0.2 : moins d'un fichier source sur cinq couvert. Deux développeurs internes le maintiennent, sur une base TJM 600 € (dev senior France). Application métier critique : si elle tombe le mardi, le business le sent le mardi.
Précision méthodo avant les chiffres : ce projet n'existe pas en tant que tel. C'est un composite, fabriqué à partir de signatures que je retrouve en mission. Pas un cas pathologique, pas un site vitrine : du milieu de gamme. Les chiffres qui suivent sont défendables sur ce profil. Le vôtre a sa propre signature, à vous d'ajuster.
Poste 1. La maintenance qui dérive
C'est le poste le plus visible si on sait où regarder. Il suffit d'ouvrir le tracker des trois derniers mois, de séparer les tickets en deux piles ("bug / régression / workaround" d'un côté, "évolution / feature" de l'autre) et de compter.
Sur le profil du projet, je vois des ratios autour de 1 pour 1. Pour chaque jour-homme passé à livrer une feature, un autre jour part à colmater quelque chose qui devait déjà tenir. Sur l'année, ça représente entre 30 et 50 jour-homme qui dérivent. Disons 33 en moyenne, parce qu'on parle d'un projet pas catastrophique. À 600 €/jour, on tombe à 20 k€/an de maintenance qui ne produit rien de neuf.
Ce poste a une particularité gênante : il s'auto-alimente. Chaque modification dans un code peu testé est un coup de poker : vous corrigez le bug A, vous en réveillez un B trois écrans plus loin. Et même quand le filet de tests existe, le coverage peut mentir. Le ratio bug/feature monte tranquillement, par dérive et non par décision.
Au passage, on perd les devs. À ce rythme-là, vous payez deux développeurs senior pour qu'un seul fasse avancer le produit. L'autre éteint des feux.
Poste 2. Les évolutions qui s'étirent
Si le poste 1 est visible, celui-ci est sournois. Il ne se mesure pas en bugs corrigés. Il se mesure en features qui devaient prendre deux semaines et qui en prennent six.
Méthode : on prend les trois à cinq derniers jalons métier livrés, on compare l'estimation initiale au délai réel, et on calcule le delta. Sur le profil du projet, je vois régulièrement des facteurs x2 à x3 sur des chantiers qui touchent à plusieurs domaines fonctionnels mélangés dans le même fichier. Sur l'année, ça donne entre 25 et 40 jour-homme de glissement. Moyenne retenue : 30. À 600 €, 18 k€/an d'évolutions qui ont coûté plus que prévu, non par manque d'effort mais par friction structurelle.
Une nuance : ce chiffre, c'est le glissement facturé. Le coût direct. Ce qui n'est pas dans le tableau, c'est le coût d'opportunité : la feature qu'on n'a pas faite parce que les six semaines étaient déjà parties sur celle d'avant. Le contrat commercial qu'on n'a pas signé parce que le produit ne savait pas encore le faire.
Ces lignes-là, je ne sais pas les chiffrer sur un projet reconstitué. Mais elles existent, et sur la durée, elles pèsent souvent plus lourd que les 18 k€ visibles.
C'est le poste qui fait le plus mal au business : pas en euros directs, mais en occasions manquées.
Poste 3. Les compétences qui se raréfient
Sur le marché PHP français aujourd'hui, le tarif moyen d'un freelance senior tourne autour de 480-530 €/jour (cf. Free-Work, en bibliographie). Pour quelqu'un qui maîtrise spécifiquement PHP 7.x, Laravel 6/8 obsolète, ou Drupal 7, c'est différent. La compétence n'est pas compliquée à acquérir, elle est devenue rare. Et la rareté se paye.
En mission, je vois des renforts spécialisés legacy facturés entre 580 et 680 €/jour. C'est une prime de rareté de 80 à 150 € sur le TJM standard. Ajoutez le time-to-hire allongé (2 à 3 mois en plus pour caler le bon profil, là où sur PHP 8 + Symfony récent les CV arrivent en deux semaines), et la facture ne se limite pas au TJM.
Calcul : sur un projet qui a besoin de 30 à 50 jour-homme de renfort externe par an, la prime tourne autour de 3 à 7 k€. Ajoutez les semaines de dérive sur le recrutement (un poste vacant payé sur d'autres budgets, des features repoussées, une pression supplémentaire sur les deux mainteneurs internes), et on tombe pondéré entre 10 et 15 k€/an, soit 12 k€ en moyenne.
Ce n'est pas un montant écrasant. Mais il apparaît juste au moment où vous en avez le moins besoin : quand vous voulez aller plus vite et que vous ne trouvez personne.
Poste 4. La sécurité qu'on ne peut plus défendre
Ce poste-là se réveille au pire moment : un matin d'audit client, ou quand le DPO interne demande l'état des CVE de la stack. Là, vous découvrez qu'on ne peut plus toutes les corriger : la stack est trop vieille.
Premier bloc, remédiation manuelle. Sur un projet PHP 7.4 / Laravel 8, comptez 15 à 30 CVE déclarées dans les dépendances composer, dont 5 à 10 sans patch officiel disponible : le mainteneur a abandonné, ou le correctif n'est sorti que sur une version majeure plus récente que vous ne pouvez pas adopter. Chaque CVE non patchable demande de forker, patcher, ou contourner : 1 à 3 jour-homme la pièce. Soit 5 à 15 k€/an de travail invisible.
Deuxième bloc, risque RGPD provisionné. En 2025, la CNIL a prononcé 486 M€ d'amendes au total (cf. bibliographie). Sur la procédure simplifiée (la voie majoritaire pour les PME), les sanctions vont jusqu'à 20 k€ par dossier. Et des cas comme Spartoo ont pris 250 k€ d'un seul coup pour mauvaise gestion des données. Sur ce profil, une provision standard tourne autour de 5 à 15 k€/an, méthode assurance.
Total : entre 10 et 30 k€/an de couverture du risque, 20 k€ en moyenne, sans incident. Le jour où un incident arrive, le coût explose.
Et c'est précisément ce qu'on n'arrive plus à brancher sereinement sur du code en EOL : quand le langage n'évolue plus, les outils qui l'analysent finissent par décrocher aussi.
Poste 5. La migration qu'on repousse
Les quatre postes précédents se ressemblent : on prend une méthode, on sort un chiffre moyen, on pose la facture annuelle. Celui-ci est différent. C'est lui qui montre que la dette technique ne stagne pas : elle accélère.
Prenons l'exemple d'un Drupal 7. Le support officiel est terminé depuis 2025, le support communautaire suit son cours mais s'érode chaque trimestre. La question n'est plus "est-ce qu'on doit migrer". C'est "combien ça nous coûte de migrer maintenant, vs dans 3 ans".
Migrer un Drupal 7 aujourd'hui : entre 5 et 50 jours d'expert, soit 3 à 30 k€ sur un site moyen. La fourchette est large parce que deux facteurs déterminent presque tout :
- Le volume de code custom : un thème + quelques modules custom légers, c'est rapide. Du custom métier qui fait tourner l'application, c'est lourd.
- Les modules contrib que vous utilisez : la plupart ont été portés vers Drupal 10/11. Certains, non. Il faut alors les réécrire ou trouver un remplaçant fonctionnel.
Migrer le même site dans 3 ans ? Plus personne ne peut le chiffrer honnêtement, et c'est précisément ça le problème. Voici les 4 leviers qui font glisser l'estimation : raréfaction des prestataires Drupal 7, modules contrib qui disparaissent, hébergement PHP 7.x devenu une niche premium, version cible qui s'éloigne (passer à Drupal 12 sera plus lourd que passer à Drupal 11). Sur les migrations Drupal 6 vers 7 puis 7 vers 9, le marché a montré qu'attendre 3 ans multiplie l'effort par 1,5 à 2.
Y compris moi, je ne saurais pas chiffrer dans 3 ans. Et c'est ça qui doit alerter : un poste qu'on ne peut plus borner, c'est un poste qui prend le pouvoir sur le budget, et non l'inverse.
Total : la facture annuelle, et celle dans 3 ans
On range les chiffres dans un tableau. Année 1, c'est ce que vous payez aujourd'hui. Année 4, c'est ce que vous payerez en 2029 si rien ne change : sans nouvel incident, sans nouvelle CVE majeure, sans crise de recrutement particulière. Juste la trajectoire mécanique.
| Poste | Année 1 | Année 4 (sans rien faire) |
|---|---|---|
| Maintenance qui dérive | 20 k€ | 35 k€ |
| Évolutions qui s'étirent | 18 k€ | 30 k€ |
| Surcoût recrutement | 12 k€ | 20 k€ |
| Sécurité provisionnée | 20 k€ | 35 k€ |
| Migration Drupal 7 vers 11 | 3 à 30 k€ (si lancée) | 5 à 60 k€ (si reportée) |
| Sous-total dette opérationnelle | ~70 k€/an + migration | ~120 k€/an + migration x1,5-2 |
En clair : sur les quatre postes opérationnels, la facture annuelle tourne autour de 70 k€. Plus la migration. Trois ans plus tard, sans intervention sur la dette, on est à 120 k€/an. Pas par accélération brutale, par dérive cumulée. Le poste maintenance passe de 20 à 35 k€/an, le poste sécurité aussi. Rien de spectaculaire ligne par ligne, mais cumulé ça fait +50 k€/an de coût récurrent qui ne produit toujours rien de neuf.
La migration n'est pas dans le sous-total. Elle est en colonne à part parce qu'elle se déclenche une fois. Mais quand elle se déclenche, elle coûte entre 1,5 et 2 fois plus si on a attendu trois ans de trop.
Sur 4 à 5 ans, on parle facilement de 300 à 500 k€ de dette technique payée sans contrepartie produit. Soit une équipe junior pendant un an, ou l'évolution majeure qui aurait sauvé le contrat client de l'année dernière.
Le cas extrême : un projet noté 19 sur 100
Pour calibrer le tableau précédent par le haut, voici un cas réel que j'ai déjà documenté en détail dans l'autopsie de ce projet noté 19/100. Je ne le nomme pas : anonymisation par défaut, règle maison. Je rappelle les marqueurs techniques publics, qui suffisent à reconnaître le profil pour qui sait lire :
- Score d'audit global : 19 sur 100
- 72 CVE déclarées dans les dépendances composer, dont une majorité sans patch disponible
- 492 erreurs PHPStan au niveau 1 (le plus permissif)
- Un contrôleur unique de 822 lignes mêlant paiement, commandes et statistiques
Si vous appliquez la grille de calcul de cet article à ce profil-là, vous dépassez facilement les 100 k€/an rien qu'en sécurité provisionnée + maintenance dérivante. Les évolutions étirées ne sont même plus chiffrables : sur ce niveau de dette, livrer une feature non triviale demande des jours d'archéologie code avant la première ligne écrite.
Borne haute, donc. Votre projet n'est sans doute pas là. La plupart des projets que je vois en mission sont quelque part entre le profil reconstitué (70 k€/an) et ce cas extrême (100 k€+/an, plancher). Le tableau de la section précédente vous donne l'ordre de grandeur. À vous de placer votre curseur.
Comment chiffrer la vôtre
La grille de calcul tient en quatre étapes, faisables sur une journée pour une première estimation :
- Sortez le ratio bug / feature de votre tracker. Sur les 12 derniers mois, séparez les tickets en deux piles, multipliez par le jour-homme moyen, multipliez par votre TJM. Vous avez le poste 1. (Si vous utilisez SonarQube, le TDR ou ratio de dette technique donne un signal de tendance complémentaire, pas un chiffre euros.)
- Comptez les CVE non patchables.
composer audit,npm audit, ou l'équivalent de votre stack. Pour chaque CVE sans patch, comptez 1 à 3 jour-homme de remédiation manuelle annuelle. Vous avez le bloc 1 du poste 4. - Provisionnez le risque sécurité. Méthode standard d'assurance ou de cabinet conseil. À défaut, calez 5 à 15 k€/an sur un projet PME : le chiffre tient pour la majorité des cas que je vois. Vous avez le bloc 2 du poste 4.
- Chiffrez la migration en deux scénarios : maintenant vs dans 3 ans. Faites les deux devis. L'écart entre les deux, c'est le coût d'attendre. Et c'est souvent l'élément qui fait basculer le budget.
Les postes 2 (évolutions étirées) et 3 (recrutement) demandent un peu plus de matière historique pour être précis. Mais déjà avec les postes 1 et 4 chiffrés, vous avez de quoi tenir une réunion budget sérieuse avec votre direction.
Ces chiffres ne sont pas des projections. Ce sont des lignes que vous payez déjà, juste qu'elles ne sont écrites nulle part. Les écrire, c'est déjà la moitié du chemin.
Si vous voulez chiffrer la vôtre, c'est le genre de travail qui se fait en deux-trois jours d'audit.
Sources et méthode
Données de calibrage utilisées dans cet article :
- Stripe, The Developer Coefficient (2018, benchmark historique encore largement repris). 42% du temps dev consacré à la dette technique et au mauvais code. Cité ici comme borne haute.
- McKinsey, Recalibrating CIO technology budgets for the AI era. La plupart des CIOs estiment que 10 à 20% de leur budget tech part en gestion de dette technique. Sert d'ancrage pour les postes 1 et 2 cumulés.
- Free-Work, Barème TJM PHP / Symfony / Laravel / Drupal France 2026. Tarifs journaliers de référence par séniorité et région. Sert au TJM 600 € retenu et à la prime de rareté du poste 3.
- TuxCare, The real-world cost of not patching a critical CVE (2025). 60% des incidents cybersec dûs à une CVE patchable mais non patchée. Délai d'exploitation passé de 63 jours en 2018 à 5 jours en 2024.
- CNIL, Bilan sanctions 2025. 486 M€ d'amendes prononcées, dont 67 sanctions en procédure simplifiée allant jusqu'à 20 k€. Référence pour la provision RGPD du poste 4.
- Archimag, 1,15 Md€ d'amendes RGPD en 2025 (UE). Vue d'ensemble européenne pour calibrer le risque par contraste avec la France seule.
Méthode de calcul rappelée : chaque chiffre moyen provient soit d'un audit que j'ai conduit, soit d'une fourchette publique référencée ci-dessus. Aucune projection inventée. Le projet "type" est un composite construit à partir de signatures observées en mission. Les fourchettes sont intentionnellement larges parce que la dette technique se mesure mal au stylo fin.