Dette technique : définition, exemples et gestion

Dette technique : définition simple pour un dirigeant

Imaginez le travail qu'une équipe devra fournir demain parce qu'elle a préféré, aujourd'hui, la solution rapide à la bonne. Voilà ce que recouvre le terme. Code écrit dans l'urgence, architecture bricolée, tests jamais rédigés, documentation inexistante. Sur le moment, rien ne coince. Les ennuis arrivent après, dès qu'on veut faire évoluer le produit.

Site vitrine, logiciel métier, application mobile : en informatique, la notion s'applique partout. Viser zéro dette quand on dirige une TPE ou une PME ? Impossible. Ce qui compte vraiment, c'est de savoir combien vous en portez, où elle se loge et ce qu'elle vous coûte chaque mois.

L'origine du concept : Ward Cunningham et la dette financière

On doit l'expression à Ward Cunningham, développeur américain resté célèbre pour avoir inventé le premier wiki. En 1992, à la conférence OOPSLA, il présente un rapport où le code livré trop vite est comparé à un emprunt. Sortir une première version imparfaite fait avancer, pourvu qu'on la reprenne vite.

Pourquoi cette image a-t-elle si bien traversé le temps ? Parce que n'importe qui la comprend. Le raccourci, c'est le capital emprunté. Les heures perdues ensuite à contourner un code fragile ? Les intérêts. Quant au remboursement, il correspond au moment où l'on prend enfin le temps de réécrire proprement. Tant qu'il n'arrive pas, le compteur tourne, comme sur n'importe quel prêt.

Comment on dit dette technique en anglais et dans d'autres langues

En version originale, on dit technical debt, ou tech debt pour faire court dans les équipes. C'est donc la formule à taper si vous voulez traduire dette technique en anglais et lire la littérature spécialisée. Côté arabe, l'usage retient surtout الدين التقني (al-dayn al-taqni), calque direct de l'anglais. Le concept ne change pas d'un pays à l'autre (ce qui simplifie bien les échanges avec un prestataire étranger).

Comment la dette technique se forme dans un projet

Presque jamais d'un seul coup. Elle s'installe livraison après livraison, sans que personne l'ait vraiment décidé. Une échéance commerciale se rapproche, un client attend sa démo, et le nettoyage du code passe à la trappe « pour l'instant ». Répétez ce petit arbitrage pendant des mois : l'addition devient lourde.

Les causes les plus fréquentes

• Des délais serrés, qui poussent à livrer une fonctionnalité ni testée ni documentée.
• Aucune vision d'ensemble sur l'architecture : on empile des briques jamais pensées pour cohabiter.
• Bibliothèques, extensions ou versions de langage obsolètes, qui ne reçoivent plus de mises à jour.
• Peu ou pas de tests, si bien que la moindre modification devient risquée.
• Un développeur clé qui s'en va sans rien transmettre ni documenter.
• Le métier a évolué, mais le code, lui, est resté figé sur l'ancien fonctionnement.

Chez les PME, on croise sans arrêt le même cas : un site WordPress truffé d'extensions jamais mises à jour, qui tourne sur une version de PHP dépassée. Ça marche… et personne n'ose y toucher. Notre guide pour mettre à jour PHP montre comment ce retard se transforme en dette bien réelle.

Les types de dette selon Martin Fowler

Martin Fowler, figure reconnue du développement logiciel, propose une grille de lecture que je trouve précieuse. Il croise deux questions. Le passif a-t-il été contracté délibérément ou par accident ? Avec prudence ou à la légère ? On obtient quatre familles.

• Délibérée et prudente : l'équipe prend le raccourci en connaissance de cause, l'assume et prévoit de le corriger après le lancement.
• Délibérée et imprudente : tout le monde sait que c'est mal fait, mais « on n'a pas le temps », et aucun plan de rattrapage n'existe.
• Involontaire et prudente : le travail était sérieux, pourtant on découvre après coup qu'une autre conception aurait mieux convenu.
• Involontaire et imprudente : l'équipe manquait des compétences nécessaires pour voir le problème.

Chaque famille appelle un traitement différent. La première relève d'une décision de gestion, parfois très saine pour un MVP. La dernière trahit plutôt un souci de recrutement ou de choix de prestataire. Autre manière de classer : selon l'endroit où se loge le problème (code, tests, documentation, infrastructure, choix d'architecture).

Dette technique ou dette technologique ?

On emploie souvent l'une pour l'autre. Dans l'usage courant, pourtant, « dette technologique » désigne surtout l'obsolescence des outils : serveur vieillissant, framework abandonné, logiciel que l'éditeur ne supporte plus. L'autre notion va plus loin, puisqu'elle englobe aussi la qualité du code et de la conception. Concrètement, la première n'est souvent qu'un morceau de la seconde.

Ce que la dette technique coûte à une PME

Vous ne la trouverez pas dans votre bilan. Elle se manifeste pourtant de façon très concrète : devis qui gonflent, délais qui glissent, bugs qui reviennent. Votre site ou votre application rapporte moins, tout simplement parce qu'il évolue moins vite que le marché.

Les intérêts : un ralentissement qui s'aggrave

Ajouter une fonctionnalité prend de plus en plus de temps. Avant d'écrire la moindre ligne, il faut déchiffrer un code confus, puis s'assurer que rien ne casse ailleurs. Peu à peu, l'équipe passe ses journées à éteindre des incendies au lieu de créer de la valeur. Et un jour, la refonte complète s'impose comme seule issue, alors qu'un entretien régulier aurait suffi !

S'y greffent des risques de sécurité : une dépendance jamais mise à jour correspond souvent à une faille connue et documentée. Les performances peuvent enfin en pâtir, avec un effet direct sur le référencement et le taux de conversion.

Les signaux qui doivent alerter un dirigeant

• Changer un simple texte de formulaire demande plusieurs jours.
• Les mêmes bugs refont surface à chaque mise en production.
• Votre prestataire refuse de toucher à certaines parties du code.
• Personne n'est capable d'expliquer le fonctionnement d'un module critique.
• Depuis des mois, on repousse les mises à jour par peur de tout casser.
• Chaque déploiement se vit dans le stress.

Comment identifier et mesurer la dette technique

Ce n'est pas une science exacte. On peut néanmoins rendre le problème visible en croisant des outils automatiques et le ressenti de l'équipe : les chiffres dessinent une tendance, les développeurs disent ce qu'elle signifie réellement.

Les outils d'analyse statique

Le principe ? Un logiciel lit le code source sans l'exécuter. Il repère les duplications, les fonctions interminables, les failles connues, les mauvaises pratiques. Parmi les plus répandus, SonarQube chiffre la dette en temps nécessaire pour corriger ce qu'il a détecté. Indicatif, certes. Mais largement suffisant pour suivre l'évolution d'un mois à l'autre et comparer vos modules entre eux.

Les indicateurs à suivre

• Couverture de tests : quelle part du code est vérifiée par des tests automatisés ?
• Dépendances obsolètes ou porteuses d'une faille connue : combien en compte-t-on ?
• Délai moyen pour livrer une petite évolution, de la demande à la mise en ligne.
• Bugs remontés après chaque livraison.
• Part du temps de l'équipe passée en maintenance plutôt que sur les nouveautés.

Mon conseil : présentez ces mesures comme n'importe quel indicateur clé de performance, dans un tableau de bord partagé. Pas besoin de lire le code quand on dirige ; il suffit de suivre une courbe.

Le cas des applications mobiles natives

Une app native accumule un passif d'un genre particulier. Apple et Google font évoluer leurs systèmes chaque année : faute de mise à jour, l'application finit par afficher des écrans cassés, voire par disparaître des stores. Pour repérer le problème, regardez l'écart entre la version du système ciblée et la version actuelle, les bibliothèques tierces abandonnées, les rapports de plantage et les avertissements des consoles développeurs. Vous hésitez encore sur la technologie ? Notre comparatif application native vs PWA vous aidera à anticiper ce coût d'entretien.

Gérer la dette technique au quotidien

Gérer, c'est d'abord admettre que la dette existe, puis choisir en conscience quoi rembourser, quand, et dans quel ordre. Le pire scénario ? Un passif invisible, que personne ne note et que tout le monde subit. L'idéal, à l'inverse, ressemble à un plan d'apurement : une liste chiffrée, traitée par priorité.

Rembourser par petites tranches à chaque sprint

En méthode agile, une part de chaque sprint est réservée au remboursement. Les éléments de dette rejoignent le backlog au même titre que les demandes métier, avec estimation et priorité. Commencez par ce qui freine le plus l'équipe ou ce qui ouvre un risque de sécurité. Avancer ainsi, sans à-coups, permet de réduire la dette technique sans geler le produit des mois durant.

Une règle toute simple fait des merveilles : laisser chaque fichier un peu plus propre qu'on ne l'a trouvé. Le développeur qui intervient sur une fonction en profite pour la clarifier. À la longue, l'effet est énorme.

Les tests automatisés et la documentation

Contre la dette future, rien ne vaut les tests automatisés. À chaque modification, ils vérifient que l'existant tient toujours, ce qui rend les refactorisations bien moins périlleuses. Branchés sur un pipeline CI/CD, ils bloquent un déploiement défectueux avant qu'il n'atteigne vos clients. La documentation, elle, protège contre la perte de savoir : quelques pages à jour sur l'architecture et les grands choix épargnent des semaines de rétro-ingénierie.

Les erreurs courantes

• Voir dans la dette une faute de l'équipe, alors qu'elle découle souvent d'arbitrages commerciaux légitimes.
• Tout réécrire d'un coup : le chantier devient long, risqué, et engendre souvent son propre passif.
• Fermer les yeux tant qu'aucun incident n'éclate.
• Oublier de budgéter la maintenance dans le coût total du projet.
• Mesurer sans agir. Un tableau de bord rouge que personne ne consulte ne rembourse rien.

Questions fréquentes