Audit Dette Technique — Quantifier et Prioriser le Remboursement de votre Code

#La dette technique en chiffres — Ce que coûte réellement l'inaction

Les ordres de grandeur documentés par la recherche sont sévères. CAST Research, qui analyse des codebases en production depuis plus de 20 ans, estime le coût mondial de la dette technique à environ 1 500 milliards de dollars par an — soit davantage que le PIB de l'Espagne. Une application legacy typique présente en moyenne un défaut pour 100 à 200 lignes de code. Les équipes travaillant sur des codebases à forte dette consacrent entre 40 et 60 % de leur capacité de sprint à maintenir les systèmes existants en fonctionnement, au détriment des nouvelles fonctionnalités attendues par les métiers.

Dans notre pratique chez Nehos, les audits conduits en 2025 sur des applications ETI révèlent un SQALE ratio moyen de 28 %. Pour contextualiser : l'industrie considère qu'un ratio inférieur à 5 % est sain, qu'entre 5 et 10 % il est modéré, qu'entre 10 et 30 % il devient préoccupant, et qu'au-delà de 30 % il est critique — chaque journée de développement ajoutée coûte 30 % de temps supplémentaire juste pour ne pas aggraver la situation existante. À 28 %, une équipe de 8 développeurs travaille en réalité avec l'efficacité de 5,8 développeurs. Ce sont 2,2 équivalents temps plein perdus annuellement dans la résistance à la dette.

Trois signaux opérationnels que nous observons systématiquement avant même de lancer les outils d'analyse. Les sprints deviennent imprévisibles : les estimations s'allongent, les bugs de régression reviennent à chaque release, les revues de code prennent de plus en plus de temps. L'onboarding des nouveaux développeurs s'étale à 3-4 mois au lieu de 4-6 semaines, parce que le code n'est pas lisible sans les connaissances tribales. Les refus d'intervenir dans certains modules — le fameux "on ne touche pas au module de facturation" — signalent des zones de complexité critique non documentée.

#Les 4 types de dette technique — Comment les mesurer

#1. Dette code — Duplication, complexité, code smells

La dette code est la plus visible et la plus facilement outillée. Elle regroupe la duplication (le même bloc logique copié-collé à 12 endroits différents, qui nécessitera 12 corrections lors du prochain bug), la complexité cyclomatique excessive (une méthode de 800 lignes avec 47 conditions imbriquées que personne n'ose toucher), et les code smells au sens de Martin Fowler : God Classes, Long Methods, Feature Envy, Data Clumps, Shotgun Surgery.

Outils de mesure : SonarQube couvre l'ensemble de ce périmètre sur Java, PHP, JavaScript/TypeScript, Python, C# et une vingtaine d'autres langages. PMD (Java) et CodeClimate complètent l'analyse sur des projets multi-langages. La métrique clé à surveiller : le nombre de "blocker" et "critical" issues SonarQube (pas les "minor", qui sont souvent du bruit), et le ratio de dette code exprimé en jours de remédiation.

#2. Dette tests — Couverture insuffisante, tests fragiles, suites lentes

La dette tests est souvent sous-estimée par les équipes — jusqu'au jour où une modification anodine casse silencieusement un comportement critique non couvert. Elle prend trois formes : l'absence de tests automatisés (les modules legacy les plus anciens ont souvent 0 % de couverture), les tests fragiles qui passent ou échouent de façon non déterministe selon l'environnement, et les suites de tests si lentes qu'elles ne sont plus exécutées systématiquement.

Outils de mesure de couverture : JaCoCo (Java), Istanbul/c8 (JavaScript/TypeScript), Coverage.py (Python), PHPUnit avec Xdebug ou PCOV (PHP). Cibles industrielles : 80 % de couverture de lignes et 70 % de couverture de branches sur le code fonctionnel (hors boilerplate de configuration). Attention à l'interprétation : un taux de couverture élevé ne garantit pas la qualité des assertions — un test qui exécute le code sans vérifier les résultats gonfle la couverture sans valider le comportement. Nehos évalue systématiquement la densité d'assertions et la pertinence des cas testés.

#3. Dette architecture — Couplage fort, layers non respectées, dépendances circulaires

La dette architecturale est la plus difficile à mesurer automatiquement et la plus coûteuse à rembourser. Elle se manifeste par un couplage fort entre modules qui devraient être indépendants (l'interface utilisateur appelle directement la base de données, le module de facturation connaît les détails du module de stock), par des dépendances circulaires (le module A dépend de B qui dépend de C qui dépend de A), et par des couches architecturales non respectées (la couche de présentation contient de la logique métier, la couche de service fait des requêtes SQL directement).

Outils d'analyse : Structure101 (Java — détection des dépendances circulaires et violations de layering), NDepend (C#/.NET — métriques de couplage avancées, graphe de dépendances), Madge (JavaScript/TypeScript — visualisation des dépendances entre modules), PHP Architecture Tester (PHP — règles d'architecture vérifiables en CI), Deptrac (PHP/Symfony — contraintes de layering configurables). Nehos produit systématiquement une carte de couplage visuelle des modules : les nœuds les plus connectés sont les candidats prioritaires à l'isolation.

#4. Dette sécurité — CVE, dépendances vulnérables, secrets exposés

La dette sécurité est la seule catégorie de dette technique qui peut avoir des conséquences légales et réputationnelles immédiates, indépendamment du calendrier de remédiation que vous choisissez. Elle comprend les dépendances avec des CVE connues (Common Vulnerabilities and Exposures avec scores CVSS publiés), les secrets exposés dans le code source ou l'historique Git (tokens API, clés privées, mots de passe en clair), et les violations des 10 risques OWASP Top 10 les plus fréquents (injection SQL, XSS, authentification cassée, désérialisation non sécurisée, etc.).

Outils : Snyk (analyse des dépendances toutes plateformes — NPM, Composer, PyPI, Maven, NuGet), OWASP Dependency Check (open source, intégration CI), Dependabot (GitHub — alertes automatiques sur les CVE), GitLeaks et TruffleHog (secrets dans l'historique Git), SonarQube Security Hotspots (violations OWASP dans le code applicatif). Sur nos audits 2025, 87 % des applications ETI présentent au moins une dépendance avec une CVE de criticité CVSS ≥ 7 non corrigée.

#Métriques standards — SQALE, McCabe, Halstead, Coverage

Six métriques constituent le tableau de bord minimal d'un audit dette technique sérieux.

Ratio SQALE (Software Quality Assessment based on Lifecycle Expectations) : temps de remédiation estimé divisé par le temps de développement total estimé du codebase. Inférieur à 5 % — code sain, dette maîtrisée. 5-10 % — modéré, à surveiller. 10-30 % — préoccupant, impacte la vélocité. Supérieur à 30 % — critique, chaque nouvelle fonctionnalité est ralentie structurellement. C'est la métrique phare que nous utilisons pour les présentations COMEX et les rapports de due diligence investisseur.

Complexité cyclomatique McCabe : nombre de chemins d'exécution indépendants dans une fonction. Inférieure à 10 — bonne, testable, compréhensible. 10-20 — modérée, tests de couverture conseillés. Supérieure à 20 — critique, refactoring recommandé avant toute modification. Supérieure à 50 — quasi-intouchable sans risque de régression.

Complexité cognitive (métrique moderne SonarQube) : contrairement à McCabe qui compte les branches, la complexité cognitive pénalise les structures qui rendent le code difficile à comprendre pour un humain — imbrications profondes, breaks de flux non linéaires, opérateurs ternaires chaînés. Plus alignée sur l'expérience réelle des développeurs que McCabe.

Métriques de Halstead : issues de la théorie de l'information appliquée au code, elles mesurent le volume d'information contenu dans un programme (nombre d'opérateurs et d'opérandes distincts). Utiles pour comparer la complexité relative de modules ou de fichiers à grande échelle.

Taux de couverture de tests : cible industrielle 80 % de couverture lignes, 70 % de couverture branches. Attention : ces cibles s'entendent sur le code fonctionnel hors configuration. Un taux de 100 % sur un codebase sans assertions réelles ne signifie rien.

Taux de duplication : cible inférieure à 3 %. Au-delà de 10 %, la maintenance diverge systématiquement — corriger un bug dans une copie sans corriger les autres génère des incohérences de comportement progressives.

Métriques de taille : longueur de méthode cible inférieure à 30 lignes, longueur de classe inférieure à 300 lignes. Au-delà, les responsabilités sont mélangées et la testabilité s'effondre.

#Outils d'analyse statique — SonarQube, PHPStan, ESLint, Pylint

#SonarQube — La référence enterprise multi-langage

SonarQube est le standard de l'industrie pour l'audit de dette technique sur des codebases mixtes. Il couvre nativement Java, JavaScript/TypeScript, PHP, Python, C#, C/C++, Go, Ruby, Kotlin, Scala et une vingtaine d'autres langages dans la version Community et les versions commerciales. Ce qui en fait la référence : il expose nativement le ratio SQALE, les security hotspots catégorisés OWASP, les code smells avec leur effort de remédiation estimé, et l'intégration des rapports de couverture de tests (JaCoCo, Istanbul, Coverage.py). SonarCloud est la version hébergée pour les codebases GitHub/GitLab/Bitbucket — Nehos utilise SonarQube auto-hébergé pour les projets nécessitant que le code source ne quitte pas l'infrastructure client.

#PHPStan et Psalm — Analyse statique PHP poussée

Pour les codebases PHP (encore très nombreuses dans les ETI et PME françaises — Symfony 3/4, Laravel 5/6, WordPress, Magento 1, applications maison PHP 5/7), SonarQube ne suffit pas seul. PHPStan (niveaux 0 à 9) et Psalm détectent des classes entières de bugs que SonarQube manque : accès à des propriétés sur des types potentiellement null, appels de méthodes sur des types incompatibles, utilisation de fonctions ou classes dépréciées depuis PHP 8.0/8.1/8.2, incohérences de types dans les retours de fonctions. Le niveau PHPStan est un KPI de qualité que Nehos utilise systématiquement : un projet à PHPStan niveau 0 avec 40 000 erreurs est dans un état très différent d'un projet à niveau 6 avec 200 erreurs résiduelles.

#ESLint + SonarJS — JavaScript et TypeScript

Sur les frontends JavaScript/TypeScript (Vue.js, React, Angular, Next.js) et les backends Node.js, ESLint avec le plugin SonarJS détecte les variables non utilisées, les imports orphelins, les blocs switch sans default, les conditions toujours vraies ou fausses, les promesses non gérées, et les patterns de complexité excessive. TypeScript strict mode (strict: true dans tsconfig.json) est un indicateur de maturité : un projet TypeScript avec strict à false ou avec des dizaines de any généralisés a une dette de typage significative qui se traduira en bugs de production indétectables à la compilation.

#Pylint et Mypy — Python

Pour les applications Python (backends Flask/Django, scripts de traitement de données, pipelines ETL, services IA), Pylint couvre les code smells et la complexité, tandis que Mypy réalise l'analyse de type statique — équivalent PHPStan pour Python, il détecte les incohérences de typage qui passeraient silencieusement à l'exécution. Bandit complète l'analyse sur la dimension sécurité (injections, hashage faible, utilisation de random non cryptographique, désérialisation pickle non sécurisée).

#NDepend et SonarC# — .NET / C#

NDepend est l'outil de référence pour l'analyse de dette technique sur les stacks .NET/C# : graphes de dépendances entre assemblies, métriques de couplage afférent/efférent, abstractness et instability (Martin metrics), détection des violations de layering, règles d'architecture personnalisables en CQLinq. SonarC# (intégré dans SonarQube) couvre les code smells et security hotspots. Sur les ETI avec des ERP ou des applications métier .NET Framework 4.x à migrer, NDepend est indispensable pour objectiver l'effort de migration vers .NET 8/9.

Nehos intègre tous ces outils dans un pipeline d'analyse unifié et produit un rapport consolidé qui agrège les findings de l'ensemble des outils en un tableau de bord unique, élimine les faux positifs évidents, et pondère les résultats selon la criticité métier des modules analysés.

#Architecture analysis — Couplage, cohésion, dépendances circulaires

L'analyse architecturale dépasse ce que les outils de linting peuvent détecter. Elle s'intéresse aux relations entre les modules, les couches et les domaines métier — pas seulement à la qualité interne des fichiers individuels.

Premier signal d'alerte dans les codebases legacy : les dépendances circulaires. Le module de facturation dépend du module client, qui dépend du module de commande, qui dépend du module de facturation. Cette circularité empêche tout test isolé, rend le découpage en microservices ou en modules indépendants extrêmement coûteux, et génère des bugs de démarrage difficiles à diagnostiquer. Structure101 (Java), Madge (JavaScript/TypeScript), et PHP Architecture Tester permettent de visualiser et quantifier ces cycles.

Deuxième signal : la violation de layering. Dans une architecture en couches classique (présentation → application → domaine → infrastructure), une violation typique est une couche de présentation qui appelle directement la base de données (sans passer par la couche applicative ni la couche domaine), ou une entité de domaine qui connaît les détails d'implémentation de la couche infrastructure. Ces violations créent un couplage accidentel entre des abstractions qui devraient être indépendantes, rendant tout remplacement de base de données ou toute modification d'interface utilisateur infiniment plus risquée.

Troisième signal : les God Classes. Une classe de plus de 1 000 lignes avec plus de 50 méthodes est presque toujours le signe d'un manque de séparation des responsabilités. Elle connaît trop de choses, fait trop de choses, et attire vers elle toute la complexité du système au fil du temps. Son refactoring est possible mais doit être planifié et conduit progressivement — pas en une seule session.

Quatrième signal : le Feature Envy. Une méthode qui utilise davantage les données d'une autre classe que celles de sa propre classe appartient probablement à cette autre classe — c'est un signe que le découpage des responsabilités s'est progressivement dégradé sous la pression des livraisons.

#Rapport d'audit Nehos — 6 livrables

L'audit Nehos produit systématiquement six livrables structurés.

Livrable 1 — Executive Summary (1 page). Conçu pour être lu en moins de 5 minutes par un COMEX, un DSI, un CTO, ou des investisseurs en phase de due diligence. Contient : la note de risque globale (A/B/C/D sur le modèle SQALE), les trois findings les plus critiques avec leur impact business estimé, et la recommandation d'action prioritaire (stabiliser, rembourser progressivement, ou refondre).

Livrable 2 — Tableau de bord SQALE complet. L'ensemble des métriques mesurées comparées aux benchmarks industriels (secteur et taille de codebase). SQALE ratio, complexité moyenne, couverture de tests, duplication, dette par composant/module, évolution de la dette si un historique SonarQube existe déjà.

Livrable 3 — Rapport des findings critiques et bloquants. Liste détaillée de tous les issues de sévérité Critical et Blocker avec : localisation exacte (fichier, ligne), explication de pourquoi c'est un problème, impact potentiel, et guide de remédiation concret. Les issues Minor et Info ne sont pas listées individuellement mais agrégées statistiquement.

Livrable 4 — Audit sécurité des dépendances. Tableau complet de toutes les dépendances directes et transitives avec CVE connues, scores CVSS, version affectée, version corrigée disponible, et niveau de priorité de mise à jour (immédiat / prochain sprint / prochaine version majeure).

Livrable 5 — Analyse architecturale. Carte de couplage entre modules (nœuds et arêtes, densité de connexion), liste des dépendances circulaires, violations de layering identifiées, God Classes et modules à responsabilités trop larges. Visualisation graphique incluse.

Livrable 6 — Plan de remboursement priorisé. La partie la plus opérationnelle : actions classées par ROI décroissant, estimées en jours-homme et en euros (au coût journalier de l'équipe client), avec découpage en Quick Wins (< 1 sprint), améliorations à moyen terme (1-6 mois), et refactorings majeurs (6-18 mois). Ce plan est le document de référence pour les arbitrages de roadmap technique.

#Chiffrer la dette en jours-homme — La méthodologie SQALE/SQUALE

Transformer un ratio SQALE abstrait en impact financier concret, présentable à un COMEX ou à des investisseurs, est l'une des valeurs ajoutées les plus directes de l'audit Nehos.

Exemple de calcul sur un cas réel. Un codebase de 100 000 lignes de code (100 KLOC) avec un SQALE ratio de 28 % signifie que SonarQube estime à 28 jours de remédiation le travail nécessaire pour chaque tranche de 100 jours de développement ajoutés. Concrètement, si l'équipe consacre 100 jours à développer de nouvelles fonctionnalités dans ce codebase, elle devrait simultanément consacrer 28 jours à maintenir la dette au même niveau — pas la rembourser, juste l'empêcher de croître.

Pour une équipe de 8 développeurs (environ 200 jours de capacité de développement nette par mois) : 200 × 28 % = 56 jours/mois absorbés par la résistance à la dette, soit 7 développeurs équivalents temps partiel, soit 0,7 ETP perdus par mois. Sur 12 mois, c'est 8,4 ETP-mois, soit environ 2,2 ETP annuels au sens de la capacité nette. Au coût journalier moyen d'un développeur senior en France (à partir de 592 € HT/jour), c'est115 3 968 € HT de productivité perdue annuellement.

Cette traduction en euros est ce qui fait bouger les décisions de COMEX : "votre dette technique actuelle vous coûte l'équivalent de 2 développeurs seniors par an" est plus parlant que "votre SQALE ratio est à 28 %".

La méthode SQUALE (Software Quality Assessment based on Lifecycle Expectations — version enrichie développée par Olivier Goury) affine ce calcul en pondérant les remontées de dette selon leur probabilité d'être effectivement rencontrées dans les 6 à 18 mois à venir, selon la fréquence de modification de chaque module et le contexte business (les modules modifiés tous les sprints coûtent plus que les modules stables).

#Plan de remboursement priorisé — ROI-first

Toute la dette ne se vaut pas. Un plan de remboursement efficace priorise selon deux axes : l'impact négatif de la dette sur le business si elle n'est pas traitée, et l'effort de remédiation. La matrice résultante génère cinq niveaux de priorité.

Niveau 1 — CVE de sévérité critique (CVSS ≥ 9) sur des dépendances exposées. Traitement immédiat et non négociable. Ces vulnérabilités sont publiquement connues, des exploits existent souvent, et le risque légal et réputationnel est immédiat. Délai cible : < 48 heures pour les CVE critiques, < 1 sprint pour les CVE hautes (CVSS 7-9).

Niveau 2 — Modules à haute complexité bloquant les nouvelles fonctionnalités. Ce sont les modules où chaque story estimate est multipliée par 3 parce que personne n'ose y toucher sans 2 jours de compréhension préalable. ROI du refactoring : très élevé si le module est dans le chemin critique de la roadmap produit.

Niveau 3 — Modules sans tests modifiés fréquemment. Un module modifié toutes les 2 semaines avec 0 % de couverture de tests est une bombe à retardement. Effort relativement faible (écrire les tests de caractérisation d'abord, puis les tests unitaires), ROI élevé (réduction des bugs de régression, sécurisation des prochaines modifications).

Niveau 4 — Dead code et code obsolète. Supprimer du code mort — des classes, des méthodes, des routes non appelées depuis des années — réduit immédiatement la charge cognitive de l'équipe, la surface d'attaque sécurité, et le temps de build. ROI rapide, risque faible si bien identifié. Quick win systématiquement recommandé en début de mission.

Niveau 5 — Violations architecturales dans les bounded contexts en cours d'extraction. Si une refonte vers les microservices ou un découplage en modules est au programme, les violations de layering dans les domaines métier concernés doivent être traitées en amont, sous peine de transporter la dette dans la nouvelle architecture.

#Méthodologie de déploiement

Un audit dette technique Nehos se déroule en quatre phases.

Phase 1 — Cadrage (1-2 jours). Accès au code source (GitLab, GitHub, Bitbucket, ou dépôt auto-hébergé — NDA systématique avant tout accès), inventaire des technologies (langages, frameworks, bases de données, gestionnaires de dépendances), identification des modules critiques selon les équipes et la roadmap business, calibrage de la profondeur d'analyse selon le budget et les objectifs (audit express à partir de 13 k€ vs audit complet à partir de 40 k€).

Phase 2 — Analyse automatisée (3-7 jours selon taille du codebase). Déploiement du pipeline d'analyse : SonarQube + analyseurs spécifiques au langage + Snyk/OWASP Dependency Check + outils d'analyse architecturale. Le pipeline tourne sur infrastructure Nehos isolée, les résultats sont stockés dans l'environnement client si exigé. Pour les très larges codebases (> 500 KLOC), l'analyse peut prendre 2-3 jours de traitement.

Phase 3 — Revue experte (3-5 jours). Un ingénieur senior Nehos passe en revue les findings automatisés : validation des vrais positifs, élimination des faux positifs, analyse manuelle des patterns architecturaux non détectables automatiquement, pondération business des issues selon le contexte du client, rédaction du plan de remboursement priorisé.

Phase 4 — Restitution (demi-journée à journée complète). Présentation du rapport en deux sessions : session technique avec le CTO/lead developers (1h30 — détail des findings et du plan de remédiation), session executive avec le DSI/COMEX (45 min — executive summary, chiffrage business de la dette, décisions de priorisation). Questions-réponses, plan d'action des 30 premiers jours.

#ROI mesurable — Cas ETI SaaS PHP

Cas client référence : ETI / scale-up SaaS B2B (logiciel de gestion métier, architecture PHP 7.2 / Symfony 3.4 / MySQL 5.7, codebase 180 KLOC). Contexte : vélocité de sprint en baisse constante depuis 18 mois malgré l'agrandissement de l'équipe (paradoxe classique de la dette haute — plus on ajoute de développeurs sur un codebase très endetté, plus la coordination et la régression coûtent), préparation d'une levée Série A prévue dans 9 mois.

Audit Nehos réalisé sur 3 semaines. Résultats : SQALE ratio initial 42 %, couverture de tests 8 %, 14 CVE de sévérité haute ou critique dans les dépendances Composer, 3 God Classes (> 2 000 lignes chacune), 127 dépendances circulaires entre modules. Estimation de la dette : 840 jours-homme de remédiation complète. Coût annuel de productivité perdue : 3,4 ETP.

Sur la base du rapport Nehos, le client a conduit un programme de remboursement priorisé sur 9 mois : traitement immédiat des CVE critiques (2 sprints), extraction et refactoring des 3 God Classes (3 mois), mise en place d'une suite de tests sur les 5 modules les plus modifiés (en parallèle, 4 mois). À 9 mois, avant la levée : SQALE ratio ramené à 8 %, couverture de tests à 34 % sur les modules prioritaires, bugs de production en baisse de 58 %, vélocité de sprint en hausse de 35 %. Lors de la due diligence technique de la levée, le rapport Nehos initial a été fourni aux investisseurs avec les métriques de progression — la valorisation a été maintenue. Voir cas Scale-up SaaS B2B — audit dette SonarQube.

#Tarification —à partir de 48 k€ HT

Trois niveaux d'audit selon la profondeur souhaitée et la taille du codebase.

Audit Express (à partir de 48 k€ HT) : codebases jusqu'à 80 KLOC, un langage principal, analyse SonarQube + audit sécurité dépendances + executive summary. Délai : 2 semaines. Idéal pour une première évaluation rapide, un go/no-go pré-refonte, ou une qualification de risque avant acquisition.

Audit Standard (415 k€ HT) : codebases 80-300 KLOC, 2-3 langages, analyse SonarQube complète + analyseurs spécifiques au langage + audit sécurité + analyse architecturale + plan de remboursement priorisé complet + session de restitution. Délai : 3-4 semaines. Correspond à l'audit que font 80 % de nos clients ETI.

Audit Approfondi (à partir de 19 k€ HT) : codebases > 300 KLOC ou architectures distribuées (plusieurs services à auditer), analyse multi-langages complète, revue experte approfondie, due diligence technique complète pour investisseurs (rapport formaté pour data room), ateliers de restitution étendus avec l'équipe engineering et le management. Délai : 4-6 semaines.

Dans tous les cas : NDA systématique, accès au code source géré en isolation sur l'infrastructure Nehos ou l'infrastructure client, rapport livré en PDF et en format JSON structuré pour intégration dans les outils de pilotage projet existants. Première estimation en 30 minutes via RDV consultant : [Calendly Legacy](https://calendly.com/raphael-poirier_/decouverte15min-nehos-groupe