Dette technique

La dette technique désigne l’ensemble des raccourcis, compromis et décisions dépassées qui s’accumulent dans le code d’un logiciel et rendent chaque évolution plus lente, plus risquée et plus chère qu’elle ne devrait l’être. Ward Cunningham a proposé la métaphore en 1992, dans un rapport présenté à la conférence OOPSLA, pour expliquer à sa direction pourquoi il fallait revenir sur du code livré vite. Comme un emprunt, un raccourci fait gagner du temps aujourd’hui et produit des intérêts tant qu’il n’est pas remboursé : bugs, régressions, journées perdues à comprendre le code avant de pouvoir le modifier.

Pour un fondateur de SaaS, la notion nomme un phénomène que beaucoup vivent sans l’expliquer : un produit qui avançait vite la première année et sur lequel, dix-huit mois plus tard, l’ajout d’un simple champ de formulaire prend une semaine. La dette n’est pas une faute en soi. Elle devient un problème quand personne ne la mesure et que son remboursement est toujours reporté.

Comment la dette technique s’accumule

Elle s’empile par couches, dont chacune paraissait raisonnable sur le moment.

La pression sur les délais reste la cause la plus fréquente. Un client attend sa fonctionnalité, la date de lancement est fixée. L’équipe livre sans tests, duplique une fonction au lieu de la factoriser, ignore un cas limite avec un commentaire « à corriger plus tard ». Chaque raccourci est défendable isolément. C’est leur somme qui coûte.

L’apprentissage du métier produit une dette que personne ne pouvait éviter. Le modèle de données pensé au lancement se révèle trop étroit quand les vrais clients arrivent. On sait, après coup, comment il aurait fallu coder.

Le changement d’échelle transforme de bonnes décisions en contraintes. Le code qui gérait dix clients ne convient plus à mille, l’architecture prévue pour un pays encaisse mal l’international. C’est le prix normal de la croissance plutôt qu’une erreur.

Le turnover fait partir la connaissance avec les gens. Quand le développeur qui connaissait le système par cœur s’en va, parfois le CTO lui-même, ses successeurs prennent des décisions différentes et la cohérence d’ensemble se dégrade.

Le code généré par IA est la cause la plus récente, et son effet se mesure déjà (voir plus bas).

Les quatre types de dette technique selon Martin Fowler

En 2009, Martin Fowler a proposé un quadrant qui croise deux questions : la dette a-t-elle été contractée sciemment, et l’a-t-elle été avec prudence ?

La dette délibérée et prudente est celle du fondateur qui dit « on lance le MVP sans back-office, on fera les opérations à la main le premier trimestre ». Le risque est pesé, le remboursement prévu. C’est la bonne dette, celle qui finance la validation d’une hypothèse.

La dette délibérée et imprudente sonne comme « on n’a pas le temps pour les tests ». Elle ignore les bonnes pratiques sans plan de retour, et c’est la plus destructrice.

La dette involontaire et imprudente vient d’un manque d’expérience : l’équipe crée des problèmes d’architecture sans le savoir. La réponse est la formation et l’encadrement par des seniors.

La dette involontaire et prudente est celle de l’apprentissage : « maintenant qu’on a fini, on sait comment on aurait dû le faire ». Elle est inévitable, et plutôt saine si elle est remboursée au fil de l’eau.

Quand nous auditons un projet existant, ce classement nous renseigne autant sur la culture de l’équipe précédente que sur l’état du code.

À quoi ressemble la dette technique dans un SaaS

Le code difficile à lire est la forme la plus visible : fonctions interminables, noms de variables opaques, logique dupliquée. Un développeur qui le reprend passe plus de temps à comprendre qu’à modifier.

L’absence de tests automatisés est la plus dangereuse. Sans tests, chaque modification est un pari. Le refactoring, qui consiste à améliorer la structure du code sans changer son comportement, devient risqué, donc l’équipe l’évite, donc la dette grossit. Le cercle se referme.

Les dépendances obsolètes forment une dette silencieuse, jusqu’au jour où une faille de sécurité est publiée et où la mise à niveau, devenue énorme, doit se faire en urgence.

La documentation manquante laisse le fonctionnement du système dans la seule tête de ceux qui l’ont construit, et les déploiements manuels, sans pipeline de CI/CD, ralentissent chaque correctif.

L’architecture, enfin. Un monolithe n’est pas une dette en soi, c’est même souvent le bon choix de départ. Il le devient quand ses modules sont si enchevêtrés qu’on ne peut plus en modifier un sans toucher aux autres, ni déployer une partie sans redéployer le tout.

Ce que la dette technique coûte réellement

L’étude Developer Coefficient de Stripe (2018) chiffrait à 33 % la part du temps des développeurs consacrée à la dette technique et au mauvais code. Un sondage McKinsey auprès de DSI (2020) évaluait la dette à 20 à 40 % de la valeur de leur patrimoine technologique, et 10 à 20 % du budget des nouveaux produits y passait.

Les données de 2026 ne montrent pas d’amélioration. Dans l’enquête State of Code de Sonar (1 149 développeurs interrogés en octobre 2025), les répondants passent en moyenne 24 % de leur semaine à des tâches de « toil » : gérer la dette technique, déboguer du code ancien ou mal documenté. Le chiffre est identique chez les gros et les petits utilisateurs d’IA.

Pour un dirigeant, la dette se lit dans quatre signaux plus que dans le code : un délai de livraison qui s’allonge pour des fonctionnalités comparables, d’anciens bugs qui réapparaissent à chaque mise en production, une application qui ralentit ou tombe sans explication, et un nouveau développeur qui met trois mois à devenir productif.

Dette technique et code généré par IA

Les assistants de programmation ont changé la vitesse à laquelle la dette se forme. L’analyse GitClear 2025, portant sur 211 millions de lignes modifiées, montre que les blocs de code dupliqués (cinq lignes ou plus) ont été multipliés par huit en 2024, et que la part des lignes « déplacées », signe d’un travail de refactoring, est passée de 25 % des changements en 2021 à moins de 10 %. En 2024, pour la première fois, le copier-coller a dépassé le refactoring.

L’enquête Sonar va dans le même sens : 70 % des développeurs disent que l’IA a amélioré leur délai de mise sur le marché, mais seuls 47 % estiment qu’elle a réduit la dette technique.

Ces outils restent utiles. Le code qu’ils produisent doit simplement passer par les mêmes filtres que le code écrit à la main : code review humaine, tests, analyse statique. Le vibe coding, où l’on accepte du code qu’on n’a pas lu, transforme un gain de vitesse en dette invisible.

Comment mesurer la dette technique

Les métriques de code donnent des indicateurs objectifs : complexité cyclomatique (le nombre de chemins possibles dans une fonction), couverture par les tests, taux de duplication, dépendances en retard. SonarQube et Qlty (successeur de Code Climate Quality depuis fin 2024) les suivent à chaque modification, dans le pipeline d’intégration.

Le temps de cycle, entre le début du développement d’une fonctionnalité et sa mise en production, est un indicateur indirect mais parlant. S’il s’allonge d’un trimestre à l’autre pour des fonctionnalités de taille comparable, la dette en est presque toujours la cause. Le ratio entre temps passé sur les bugs et temps passé sur les nouveautés, suivi chaque trimestre, objective la discussion avec la direction.

Le ressenti de l’équipe complète les chiffres. Les développeurs savent quels modules ils redoutent et quelles modifications prennent trois fois plus longtemps que prévu. La rétrospective de sprint est le bon moment pour le noter.

Comment rembourser la dette technique

Le remboursement continu est l’approche la plus sûre. L’équipe réserve une part de chaque sprint, en général 15 à 20 %, à l’amélioration de l’existant : refactoring, ajout de tests, mise à jour de dépendances, documentation. La règle du boy-scout résume l’état d’esprit : laisser le code un peu plus propre qu’on ne l’a trouvé.

Le remboursement par bloc, une semaine ou un sprint entier, s’impose quand la dette a déjà atteint un niveau préoccupant. Il est plus risqué : un gros refactoring concentré introduit des régressions si le filet de tests est insuffisant. On commence donc par les tests.

La réécriture complète est presque toujours une erreur. Joel Spolsky l’écrivait dès 2000 à propos de Netscape : une réécriture prend plus longtemps que prévu, reproduit des erreurs sous une autre forme et gèle le produit pendant des mois. Quand une partie du système doit vraiment être remplacée, la méthode du strangler fig (Martin Fowler, 2004) consiste à construire le nouveau à côté de l’ancien et à basculer les fonctionnalités une par une, sans interruption de service.

La priorisation par l’impact guide le tout. On rembourse d’abord la dette qui coûte le plus cher au quotidien : le module que tout le monde contourne, la dépendance critique en retard de trois versions majeures, le moteur de calcul sans tests.

Les erreurs qui aggravent la dette technique

Nier la dette. « On n’a pas le temps pour le refactoring » garantit qu’elle deviendra ingérable. L’entretien du code est l’entretien normal d’un actif.

Mélanger refactoring et nouvelle fonctionnalité dans une même modification. Si quelque chose casse, impossible de savoir lequel des deux est en cause. Les deux vont dans des pull requests séparées.

Attendre le grand chantier. Une série de petites améliorations ciblées produit des résultats mesurables en quelques semaines, là où le projet colossal qu’on imagine ne démarre jamais.

Laisser le sujet aux seuls développeurs. La dette technique est un arbitrage business : chaque nouvelle fonctionnalité coûte plus cher tant qu’elle n’est pas remboursée. Fondateurs et responsables produit doivent en comprendre le coût pour arbitrer.

Ce qu’un fondateur non technique peut vérifier

Vous n’avez pas besoin de lire le code pour évaluer la dette de votre produit. Quelle part du code est couverte par des tests automatisés, et le chiffre est-il suivi ? Combien de temps sépare une modification de sa mise en production, et ce délai augmente-t-il ? Combien de dépendances sont en retard d’une version majeure ? Et si vous prenez une fonction au hasard, son auteur peut-il expliquer pourquoi chaque ligne est là ? Si vous héritez d’un projet développé par un prestataire, notre guide de la reprise de projet logiciel détaille l’audit à mener avant de signer.

FAQ dette technique

La dette technique est-elle toujours une mauvaise chose ?

Non. Une dette contractée sciemment pour lancer plus vite, avec un remboursement planifié, est un levier légitime. Un MVP livré sans back-office pour valider un marché en trois mois est une bonne dette.

Combien de temps faut-il consacrer au remboursement de la dette technique ?

Les équipes qui la maîtrisent y consacrent 15 à 20 % de chaque sprint, en continu, et n’ont jamais besoin de chantier exceptionnel. Si la dette est déjà installée, un audit permet de choisir entre un remboursement progressif et un remplacement ciblé des parties les plus abîmées.

Faut-il réécrire un logiciel qui a trop de dette technique ?

Presque jamais en bloc. La réécriture complète coûte bien plus cher que le remboursement progressif, gèle le produit pendant des mois et perd des règles métier cachées dans l’ancien code. Elle se justifie pour un prototype jetable ou une technologie morte. Sinon, le refactoring ou le remplacement progressif par la méthode du strangler fig sont plus sûrs.

Comment Polara Studio gère la dette technique

Chez Polara Studio, la dette technique se traite dans le flux de développement, pas dans un projet séparé qu’on repousse. Nous réservons 15 à 20 % de chaque sprint à l’amélioration de l’existant. TypeScript strict et tests automatisés sur la logique métier sont la base de chaque projet, et aucun code, généré par IA ou non, ne rejoint la branche principale sans relecture humaine et tests verts.

Sur les projets que nous reprenons, nous commençons par un audit (2 000 à 5 000 EUR) qui cartographie la dette et distingue ce qui se sauve de ce qui doit être remplacé. Sur une plateforme SaaS RH de trois ans dont chaque déploiement était devenu une angoisse, nous avons isolé le moteur de calcul dans un service séparé et testé, mis en place une CI/CD et formé l’équipe à la revue de code, sans arrêter la production. En quatre mois, les bugs critiques avaient baissé de 80 % et l’équipe a livré deux fonctionnalités attendues depuis un an. Le détail de la méthode est dans notre guide complet de la dette technique.