Observatoire de la dette technique des ETI françaises 2026

#La dette technique des ETI françaises : un problème systémique sous-estimé

En 2026, la dette technique n'est plus un sujet réservé aux DSI de grandes entreprises. Dans les entreprises de taille intermédiaire françaises, elle est devenue l'un des principaux freins à la croissance, à la compétitivité et à l'adoption de l'intelligence artificielle. L'Observatoire Nehos 2026 le confirme avec une force qui dépasse nos attentes initiales : 73 % des ETI interrogées présentent une dette technique qualifiée de critique ou sévère.

La dette technique critique est définie dans cette étude comme la situation où une équipe technique consacre plus de 30 % de son temps à corriger les effets de choix passés (correctifs, contournements, mises à jour forcées, incidents de production) plutôt qu'à créer de la valeur nouvelle. Cette définition opérationnelle, issue des travaux de Ward Cunningham et popularisée par Martin Fowler, permet de dépasser la dimension purement comptable pour mesurer l'impact réel sur la capacité d'innovation de l'entreprise.

Ce rapport présente les résultats complets de l'observatoire, avec un accent particulier sur trois dimensions souvent négligées dans les études existantes : le coût réel par collaborateur technique, le lien avec la productivité IA, et les stratégies de modernisation qui fonctionnent vraiment dans le contexte ETI.

#Le profil-type de l'ETI en dette technique critique

L'analyse combinée du sondage et de l'analyse statique des 30 projets dessine un profil-type précis de l'ETI en dette critique. Ce profil se caractérise par cinq marqueurs cumulatifs :

Marqueur 1 : Un socle applicatif vieillissant Le langage ou framework principal de l'application cœur de métier date d'au moins 8 ans dans sa version utilisée. Dans notre panel, on trouve principalement PHP < 7.4 (version fin de vie depuis novembre 2022, encore présente dans 41 % des projets analysés), Java 8 (fin de support étendu Oracle en 2030 mais base de code souvent figée depuis 2018-2020), Python 2.x (fin de vie en 2020, présent dans 12 % des projets), et des applications Symfony < 4 ou Laravel < 8.

Marqueur 2 : Couverture de tests unitaires inférieure à 20 % Dans 67 % des projets analysés en dette critique, la couverture de tests (unitaires + intégration) est inférieure à 20 %. La médiane est à 8 %. En conséquence, toute modification du code existant nécessite une phase de recette manuelle longue et coûteuse, et aucun refactoring n'est possible sans risque élevé de régression.

Marqueur 3 : Absence de pipeline CI/CD 58 % des ETI en dette critique déclarent ne pas disposer d'un pipeline de déploiement continu automatisé. Les déploiements sont manuels, peu fréquents (médiane : 1 déploiement par mois) et générateurs d'incidents. Un déploiement manuel d'une application PHP legacy prend en médiane 4,5 heures dans notre panel, contre 12 minutes pour une application avec CI/CD.

Marqueur 4 : Documentation technique absente ou obsolète Dans 71 % des projets analysés, la documentation technique est qualifiée d'absente (aucun README à jour, aucun diagramme d'architecture, aucune documentation d'API) ou d'obsolète (datant de plus de 2 ans et ne reflétant plus l'état réel du code). Cette absence de documentation est l'un des principaux accélérateurs de la dette, car elle rend chaque intervenant sur le code dépendant des rares personnes qui le connaissent.

Marqueur 5 : Dépendances non mises à jour L'analyse Snyk et OWASP dependency-check révèle une situation alarmante : 84 % des projets analysés présentent au moins une vulnérabilité critique (CVSS ≥ 9) due à une dépendance non patchée. Le délai médian de correction d'une CVE critique est de 94 jours dans les équipes sans CI/CD, contre 8 jours avec CI/CD. Dans 23 % des projets, des bibliothèques présentant des CVE critiques publiées il y a plus de 12 mois sont toujours en production.

#Le coût réel de la dette technique : un calcul que peu d'ETI font

Le principal obstacle à la prise de décision sur la dette technique est l'absence de chiffrage précis. La dette est perçue comme un problème diffus et permanent, pas comme un coût budgétisable. Pourtant, notre méthodologie permet d'en estimer le coût avec une précision suffisante pour décider.

Décomposition du coût médian de la dette technique par développeur/an :

Temps de correction des régressions et incidents liés à la dette : 18 % du temps soit environ à partir de 1 065 €/dev/an (base salaire chargé à partir de 32 000 €/mois). Temps de compréhension du code non documenté : 11 % du temps soit à partir de 880 €/dev/an. Retards de livraison liés aux difficultés techniques (dépassements de sprint, bugs de mise en production) : 9 % du temps soit à partir de 720 €/dev/an. Temps de gestion des dépendances obsolètes et des montées de version forcées : 6 % du temps soit à partir de 480 €/dev/an. Onboarding rallongé des nouveaux développeurs sur une base de code opaque : 4 % du temps soit à partir de 905 €/dev/an.

Total : environ 38 % du temps de développement absorbé par la dette, soit à partir de 6 k€ / développeur / an en perte de productivité directe (base salaire chargé médian des développeurs ETI : à partir de 905 €/mois). Pour une équipe de 15 développeurs, cela représente67 1 920 € par an. Pour une équipe de 30 développeurs,1 250 15 872 € par an.

Les coûts indirects, souvent oubliés :

• Surcoût de recrutement : les candidats qualifiés fuient les stacks obsolètes. La durée médiane de recrutement d'un développeur est de 87 jours pour les ETI en dette critique, contre 42 jours pour celles ayant modernisé leur stack. Avec un coût de recrutement moyen de à partir de 32 000 € par poste, la différence est significative.
• Incidents de production : les ETI en dette critique rapportent en médiane 3,2 incidents critiques par mois affectant la production, contre 0,6 pour les ETI avec une dette maîtrisée. Le coût médian d'un incident critique (indisponibilité, perte de données, corruption) est estimé2 15 872 € (temps équipe + impact client).
• Blocage IA : voir section dédiée ci-dessous.

#Dette technique et productivité IA : le lien fatal

La dimension la plus nouvelle de cet observatoire — et peut-être la plus importante pour les prochaines années — est le lien entre la dette technique et l'incapacité à tirer parti de l'intelligence artificielle assistée.

81 % des ETI en dette lourde ne peuvent pas utiliser GitHub Copilot efficacement. Ce chiffre, issu du retour d'expérience des CTO interrogés, cache une réalité technique précise : les outils de codage IA (GitHub Copilot, Cursor, Windsurf, Claude Code) nécessitent, pour fonctionner efficacement, un code de qualité suffisante pour que leurs suggestions soient validables rapidement. Dans une base de code sans tests, avec des fonctions de 500 lignes, des couplages forts non documentés et des effets de bord inconnus, chaque suggestion IA doit être vérifiée manuellement pendant 15 à 30 minutes. L'outil devient alors une charge supplémentaire, pas un gain.

Les trois blocages IA causés par la dette technique :

Blocage 1 : L'absence de tests rend les suggestions IA non validables. Copilot ou Claude Code peut suggérer une refactorisation pertinente. Mais sans suite de tests, comment savoir si elle n'a pas cassé un comportement existant dans un scénario non évident ? Les développeurs dans les équipes en dette critique passent en moyenne 4 × plus de temps à valider les suggestions IA que leurs homologues avec une couverture de tests > 60 %.

Blocage 2 : La dette de documentation empêche les agents IA de comprendre le contexte métier. Les agents IA de génération de code (et les LLM en général) sont d'autant plus efficaces que le code existant est clair, documenté et cohérent. Un fichier PHP de 2 000 lignes sans commentaires, avec des variables nommées $tmp3 et $res_final_v2, produit des suggestions IA de mauvaise qualité. La documentation est le contexte que l'IA ne peut pas inventer.

Blocage 3 : Les architectures monolithiques legacy ne se prêtent pas à l'augmentation par agents IA. Les agents IA modernes (API calls, function calling, MCP tools) s'intègrent naturellement dans des architectures en microservices ou API-first. Un monolithe PHP avec une logique métier enfouie dans des vues Smarty de 1998 ne peut pas être augmenté par des agents IA sans une refactorisation préalable.

Conséquence concrète : les ETI en dette lourde qui tentent de déployer des outils IA assistés obtiennent en médiane une amélioration de productivité de seulement +8 % (vs +34 % pour les ETI avec une base de code saine). La dette technique est littéralement un multiplicateur négatif sur le ROI IA.

→ Vous évaluez vos options ? Utilisez notre estimateur de budget en ligne pour obtenir une fourchette en 2 minutes, ou consultez nos tarifs détaillés.

#Stratégies de modernisation : ce qui fonctionne vraiment

Sur la base de l'analyse des 30 projets de remédiation suivis — 18 refontes progressives et 12 refontes complètes — nous pouvons établir un comparatif factuel des deux approches.

Remédiation progressive (strangler fig pattern) : la stratégie recommandée

La remédiation progressive consiste à moderniser le système par modules successifs, en isolant progressivement la logique métier dans des composants modernes, sans arrêter le développement produit. Le principe du strangler fig (Martin Fowler) : faire croître le nouveau système autour de l'ancien, jusqu'à pouvoir « étrangler » l'ancien.

Résultats observés dans les 18 projets suivis :

• Durée médiane de retour aux niveaux de productivité d'avant-projet : 6 semaines (vs 14 semaines pour la refonte complète)
• ROI médian à 24 mois : 3,4 × l'investissement de modernisation
• Taux de succès (objectifs initiaux atteints) : 78 %
• Continuité de service : maintenue dans 100 % des cas
• Délai avant les premiers gains mesurables (première brique modernisée) : 8 semaines en médiane

Prérequis de succès de la remédiation progressive :

1. Cartographie complète des dépendances avant de commencer (outils : Deptrac, PHPStan, SonarQube)
2. Définition des frontières de module selon la valeur métier, pas la structure technique héritée
3. Introduction de tests sur les modules à moderniser avant toute modification (test harness)
4. Définition de KPI de dette pour chaque sprint (couverture de tests, complexité cyclomatique, dette SonarQube)
5. Formation de l'équipe aux patterns modernes avant le démarrage

Refonte complète : quand est-elle justifiée ?

La refonte complète (greenfield ou near-greenfield) est justifiée dans trois cas précis : lorsque la base de code est tellement dégradée qu'aucun module ne peut être isolé sans réécrire les 2/3 du système de toute façon (cas observé dans 4 projets sur 12) ; lorsque le changement de modèle de données est radical (migration d'un ERP sur mesure vers un modèle SaaS, par exemple) ; lorsque le contexte business justifie une refonte complète de l'expérience utilisateur en parallèle.

Résultats observés dans les 12 projets de refonte complète :

• Durée médiane du projet : 18 mois (vs 6 mois pour le premier module en remédiation progressive)
• ROI médian à 24 mois : 1,8 × (inférieur à la remédiation progressive sur la même période)
• Taux de succès : 58 % (vs 78 % pour la remédiation progressive)
• Risque de dérapage budgétaire > 30 % : 44 % des projets
• Continuité de service : perturbée dans 67 % des cas

La refonte complète n'est pas mauvaise par nature — elle est mauvaise sans plan de valeur intermédiaire. Les 5 projets de refonte complète ayant atteint leur ROI cible ont tous livré une valeur métier mesurable à mi-parcours (6-9 mois), avant la mise en production complète. Les 7 ayant échoué ou dérapé ont visé une mise en production globale trop tardive (15-18 mois) sans jalons de valeur.

#Impact sur le recrutement : la spirale silencieuse

L'impact de la dette technique sur la capacité à recruter des développeurs qualifiés est l'un des angles les plus sous-estimés du problème. Nos données révèlent une corrélation forte entre le niveau de dette et la durée de recrutement.

Durée médiane de recrutement d'un développeur senior (en jours) selon le niveau de dette :

• Pas de dette significative (score SonarQube A/B) : 38 jours
• Dette modérée (score C) : 52 jours
• Dette critique (score D) : 87 jours
• Dette sévère (score E/legacy sans mesure) : 124 jours

Les raisons déclarées par les candidats refusant des offres d'ETI en dette critique (enquête complémentaire auprès de 80 développeurs ayant refusé un poste dans les 6 derniers mois) :

• Stack technologique trop ancien (PHP 5/7, jQuery, absence de tests) : 74 %
• Absence de CI/CD et de pratiques DevOps modernes : 61 %
• Réputation de dette technique sur Glassdoor ou réseau : 38 %
• Perspective de travailler sur de la maintenance plus que sur de la création : 34 %

La spirale est vicieuse : la dette technique repousse les bons développeurs, ce qui réduit la capacité à rembourser la dette, ce qui aggrave la dette, ce qui repousse encore plus les développeurs. Les ETI en dette critique qui ne traitent pas le problème voient leur capacité technique se dégrader structurellement d'année en année.

#ROI de la modernisation vs non-action : le calcul de décision

Pour une ETI type de 15 développeurs avec une dette critique estimée67 1 920 €/an de coût direct :

Scénario 1 : Non-action

• Coût cumulé sur 36 mois : 630 000 × 3 =1 890 000 €
• Plus : 3 incidents critiques ×2 15 872 € × 36 mois =34 13 824 €
• Plus : surcoût recrutement × 3 postes/an ×à partir de 32 000 € × 3 ans =1 13 952 €
• Total coût inaction sur 36 mois : environ2 385 11 904 €
• Et : blocage total de l'adoption IA pendant 36 mois, manque à gagner en compétitivité non chiffré

Scénario 2 : Remédiation progressive (investissement type :18 9 472 €)

• Investissement projet sur 12 mois :18 9 472 €
• Réduction de la dette dès le 6e mois : -40 % du coût annuel soit18 5 888 € économisés
• Sur les 24 mois suivants la modernisation : dette résiduelle réduite de 80 % soit 504 000 × 2 =1 008 000 € économisés
• Valeur ajoutée : adoption IA assistée possible dès le 9e mois, gain de productivité IA +34 % soit environ274 000 € sur 24 mois
• ROI total sur 36 mois : (252 000 + 1 008 000 + 280 000) / 180 000 = 8,6 × avant coûts indirects évités
• ROI conservateur (hors gains IA) : 3,4 × sur 24 mois post-modernisation

La conclusion est sans ambiguïté : l'inaction coûte toujours plus cher que la modernisation. La question n'est pas « si » moderniser, mais « comment » et « par où commencer ».

#Les langages et frameworks legacy les plus présents dans les ETI françaises

L'analyse des 30 projets et les déclarations des 150 CTO/DSI permettent d'établir un panorama du parc applicatif legacy des ETI françaises en 2026 :

Langages/versions présentant le plus de risques actifs :

• PHP 5.6 / 7.0 / 7.1 / 7.2 / 7.3 (tous en fin de vie, support sécurité terminé) : présent dans 41 % des ETI
• Java 8 avec bibliothèques Spring 4.x non migrées : 34 % des ETI
• Python 2.7 (fin de vie décembre 2020) : 12 % des ETI
• Node.js 14 ou antérieur (fin de maintenance) : 18 % des ETI
• .NET Framework 4.5 / 4.6 (non portés sur .NET Core / .NET 6+) : 22 % des ETI

Frameworks front obsolètes les plus répandus :

• jQuery < 3.0 sans framework JS moderne : 54 % des projets analysés
• AngularJS 1.x (fin de vie septembre 2021) : 18 % des projets
• Backbone.js / Ember.js < 3 : 9 % des projets

Bases de données à risque :

• MySQL 5.6 (fin de vie fin 2021) : 28 % des projets
• Oracle 11g sans maintenance étendue : 11 % des projets

#Ce que doivent faire les CTO/DSI : plan d'action en 5 étapes

Sur la base des résultats de l'observatoire et des retours d'expérience des projets de modernisation réussis, nous proposons le plan d'action suivant pour les ETI en dette critique.

Étape 1 — Mesurer (semaines 1-4) : Lancer un audit de dette technique outillé (SonarQube, Snyk, dependency-check) sur l'ensemble du parc applicatif. Produire un rapport de dette en heures-développeur et en risques CVE. Chiffrer le coût annuel de la dette selon la méthodologie de cet observatoire. Sans mesure, pas de décision.

Étape 2 — Prioriser (semaines 4-6) : Cartographier les applications par criticité métier × niveau de dette. Identifier les 2-3 modules à fort risque et fort impact où une modernisation rapide génère le plus de valeur. Ne pas vouloir tout traiter en même temps.

Étape 3 — Commencer petit et vite (semaines 6-14) : Lancer la modernisation du premier module prioritaire selon le strangler fig pattern. Objectif : une mise en production partielle à 8-10 semaines pour démontrer la faisabilité et les premiers gains. Ce quick win est essentiel pour obtenir le soutien des directions métier.

Étape 4 — Introduire les pratiques modernes dès le premier module : Tests unitaires (objectif > 60 % de couverture), pipeline CI/CD (GitHub Actions ou GitLab CI), revues de code systématiques, documentation OpenAPI si le module expose une API. Ces pratiques deviennent le standard pour tous les développements suivants.

Étape 5 — Mesurer, communiquer, itérer : Suivre mensuellement les KPI de dette (score SonarQube, couverture de tests, fréquence de déploiement, MTTR). Communiquer les progrès à la direction générale sous forme de ROI, pas de métriques techniques. Planifier le prochain module 4 semaines avant la fin du précédent pour maintenir le momentum.