- Calculateur de dette technique

Qu'est-ce que la dette technique ?

La dette technique est une métaphore financière introduite par Ward Cunningham en 1992 pour décrire le coût supplémentaire engendré par des choix de développement sous-optimaux. Tout comme une dette financière, elle s'accumule avec le temps et génère des "intérêts" sous forme de bugs plus fréquents, de fonctionnalités plus lentes à développer et de systèmes plus difficiles à maintenir.

Dans la pratique, la dette technique se manifeste de nombreuses façons :

• Code dupliqué : la même logique répétée à plusieurs endroits, rendant les corrections laborieuses
• Absence de tests : impossibilité de détecter les régressions lors des modifications
• Architecture obsolète : monolithe difficile à scaler, dépendances non mises à jour
• Documentation absente : perte de connaissance lors des changements d'équipe
• Complexité excessive : fonctions trop longues, imbrications profondes, logique métier dans la vue

La dette intentionnelle vs non-intentionnelle

Martin Fowler distingue deux types de dette technique dans son quadrant de la dette technique :

La dette prudente et délibérée est parfois acceptable pour un MVP ou une livraison urgente, à condition d'être documentée et remboursée rapidement. La dette imprudente, elle, est toujours un problème.

L'impact chiffré de la dette technique

• Selon le rapport CISQ 2022, la dette technique coûte 85 milliards de dollars par an aux entreprises américaines
• Les développeurs passent en moyenne 23% de leur temps à gérer la dette technique (McKinsey, 2022)
• Les projets avec une forte dette prennent 2 à 4 fois plus de temps pour ajouter de nouvelles fonctionnalités

Les 6 indicateurs clés de la dette technique

Notre calculateur repose sur 6 indicateurs fondamentaux, chacun pondéré selon son impact réel sur la qualité d'un projet logiciel.

1. Couverture de tests (poids : 20%)

La couverture de tests mesure le pourcentage de code exécuté lors des tests automatisés. C'est l'indicateur le plus directement corrélé à la stabilité d'un projet.

• < 30% : risque élevé de régression, refactoring impossible en sécurité
• 30-60% : couverture partielle, les chemins critiques restent non testés
• > 70% : bonne couverture permettant des modifications en confiance

// Mesurer la couverture avec Jest (package.json)
{
  "scripts": {
    "test:coverage": "jest --coverage --coverageThreshold='{\"global\":{\"lines\":70}}'"
  }
}

2. Duplication de code (poids : 15%)

Le taux de duplication (aussi appelé violation du principe DRY — Don't Repeat Yourself) mesure la part du code qui apparaît en plusieurs endroits. Chaque bloc dupliqué est une bombe à retardement : corriger un bug nécessite de modifier tous les exemplaires.

# Détecter la duplication avec jscpd
npx jscpd src/ --min-lines 5 --threshold 10

# Ou avec SonarQube
sonar-scanner -Dsonar.duplications.thresholdForVeryBig=0.1

3. Complexité cyclomatique (poids : 20%)

La complexité cyclomatique (McCabe, 1976) compte le nombre de chemins d'exécution indépendants dans une fonction. Une complexité élevée signifie une fonction difficile à tester, à comprendre et à maintenir.

4. Documentation du code (poids : 15%)

Une documentation insuffisante ralentit l'onboarding des nouveaux développeurs et augmente le risque de mauvaise utilisation des APIs internes. Elle comprend les commentaires JSDoc/PHPDoc, les READMEs, les ADR (Architecture Decision Records) et les guides de contribution.

5. Âge du code (poids : 15%)

L'ancienneté du code est un proxy de la dette accumulée. Un code de plus de 5 ans utilise souvent des patterns obsolètes, des dépendances en fin de vie et des architectures inadaptées aux standards actuels. L'âge seul n'est pas rédhibitoire si le code est maintenu activement.

# Identifier les fichiers les plus anciens dans un repo Git
git log --diff-filter=A --summary --pretty="%ad %H" --date=short | \
  grep "create mode" | sort | head -20

6. Maturité CI/CD (poids : 15%)

Un pipeline CI/CD mature automatise lint, tests, build, déploiement et scans de sécurité. Son absence est un multiplicateur de risque : les erreurs atteignent la production sans filet de sécurité.

Comment interpréter votre score de dette

Le score global calculé par notre outil est une moyenne pondérée des 6 indicateurs, normalisée sur 100. Plus le score est élevé, moins la dette est importante.

Le paradoxe de la dette technique

Plus la dette s'accumule, plus il est difficile de la rembourser. Les équipes entrent alors dans un cercle vicieux : la dette ralentit les développements, ce qui pousse à prendre des raccourcis pour tenir les délais, ce qui augmente encore la dette. Intervenir tôt coûte toujours moins cher qu'intervenir tard.

Stratégies pour réduire la dette technique

1. La règle du boy scout

Laissez le code dans un meilleur état que vous ne l'avez trouvé. Chaque modification est une opportunité d'améliorer un test manquant, de renommer une variable cryptique ou d'extraire une fonction trop longue. Cette approche distribuée évite les "big refactoring" coûteux.

2. Les sprints de stabilisation

Tous les 3-4 sprints, planifiez un sprint dédié à la qualité technique. Pas de nouvelles fonctionnalités — uniquement tests, documentation, refactoring et mise à jour des dépendances. Cette pratique, popularisée par Google, maintient la vélocité sur le long terme.

// Exemple de checklist sprint dette technique
const TECH_DEBT_SPRINT = {
  testing: ['Identifier les modules non testés', 'Écrire tests unitaires ciblés', 'Atteindre 70% de couverture'],
  refactoring: ['Extraire les fonctions > 50 lignes', 'Supprimer le code mort', 'Renommer les variables cryptiques'],
  dependencies: ['npm audit fix', 'Mettre à jour les packages LTS', 'Migrer les API dépréciées'],
  documentation: ['Documenter les APIs publiques', 'Mettre à jour le README', 'Créer un ADR pour les décisions importantes']
};

3. La dette technique comme critère d'acceptation

Intégrez des seuils de qualité directement dans votre pipeline CI/CD. Si la couverture de tests tombe en dessous d'un seuil, le build échoue. Cette approche automatise le contrôle de la dette et empêche sa dégradation silencieuse.

# .github/workflows/quality-gate.yml
- name: Check code quality
  run: |
    npx jest --coverage --coverageThreshold='{"global":{"lines":70}}'
    npx jscpd src/ --threshold 10
    npx eslint src/ --max-warnings 0

4. La refactorisation par le pattern Strangler Fig

Pour les systèmes legacy, le pattern Strangler Fig (Martin Fowler) consiste à construire le nouveau système autour de l'ancien, en remplaçant progressivement les fonctionnalités. Cela évite une réécriture totale risquée tout en réduisant la dette au fil du temps.

5. Mesurer et suivre dans le temps

Ce qui ne se mesure pas ne s'améliore pas. Intégrez des métriques de qualité dans votre tableau de bord projet : couverture de tests hebdomadaire, nombre de violations SonarQube, temps moyen de correction d'un bug. Ces KPIs justifient les investissements en qualité auprès du management.

Outils professionnels complémentaires

Notre calculateur est idéal pour une estimation rapide sans accès au code. Pour une analyse approfondie et automatisée, voici les outils de référence :

Intégrer SonarQube en local

# Lancer SonarQube avec Docker
docker run -d --name sonarqube \
  -p 9000:9000 \
  -e SONAR_ES_BOOTSTRAP_CHECKS_DISABLE=true \
  sonarqube:community

# Scanner votre projet
sonar-scanner \
  -Dsonar.projectKey=mon-projet \
  -Dsonar.sources=src \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.login=mon-token

Script de rapport de dette automatisé

// scripts/tech-debt-report.js
const { execSync } = require('child_process');

// Couverture de tests
const coverage = JSON.parse(
  execSync('npx jest --coverage --json --silent 2>/dev/null').toString()
).coverageMap;

// Duplication
const duplication = JSON.parse(
  execSync('npx jscpd src --output json --silent').toString()
);

console.log({
  testCoverage: Math.round(coverage.total.lines.pct) + '%',
  duplication: duplication.statistics.total.percentage + '%',
  date: new Date().toISOString()
});

FAQ — Questions fréquentes

Qu'est-ce que la dette technique ?

La dette technique est l'accumulation de compromis techniques (code mal structuré, absence de tests, documentation insuffisante) qui rendent le projet progressivement plus difficile et coûteux à faire évoluer. Elle est mesurée par des indicateurs comme la couverture de tests, la complexité cyclomatique et le taux de duplication.

Comment utiliser ce calculateur de dette technique ?

Renseignez vos 6 indicateurs en déplaçant les curseurs, puis cliquez sur "Calculer mon score". Le score global sur 100 s'affiche immédiatement avec une jauge visuelle, une catégorie (Excellent à Bloquant) et des recommandations priorisées. Vous pouvez copier le rapport complet en un clic.

Cet outil est-il gratuit ?

Oui, entièrement gratuit et sans inscription. Les calculs s'exécutent dans votre navigateur, aucune donnée n'est transmise à un serveur externe.

Quelle est la différence entre dette technique et bug ?

Un bug est un comportement incorrect du logiciel. La dette technique est une dégradation de la qualité interne du code qui ne produit pas forcément de bug immédiat, mais ralentit les développements futurs et augmente la probabilité de bugs. Un code fonctionnel peut avoir une dette technique très élevée.

Quelle alternative à ce calculateur ?

SonarQube et CodeClimate analysent automatiquement le code source et fournissent des métriques précises avec une estimation en jours/homme. Ce calculateur est idéal pour une estimation rapide lors d'un audit préliminaire ou d'une réunion d'équipe sans accès direct au code source.

Comment présenter la dette technique au management ?

Traduisez la dette technique en impact business : "Notre couverture de tests à 20% nous a coûté 3 jours de correction pour la dernière mise en production". Utilisez le rapport de notre outil comme point de départ, et proposez un plan de remboursement sur 3-6 mois avec des KPIs mesurables.

Conclusion

La dette technique est inévitable dans tout projet logiciel vivant. L'enjeu n'est pas de l'éliminer totalement, mais de la contrôler, mesurer et rembourser progressivement. Notre calculateur vous donne une photographie instantanée de votre situation en 6 indicateurs clés, avec des recommandations actionnables pour prioriser vos efforts.

Utilisez ce score comme point de départ pour vos conversations d'équipe et réunions de planification. Combinez-le avec des outils d'analyse statique comme SonarQube pour une mesure précise et automatisée dans votre pipeline CI/CD. La qualité logicielle est un investissement, pas un coût.