Dette technique : comment la détecter avant qu'elle ne vous coûte une réécriture complète

La dette technique n'est pas un mot à la mode — c'est littéral : chaque raccourci pris aujourd'hui pour livrer plus vite se paie plus tard, avec intérêts, sous forme d'heures de développement qui ne devraient pas exister. Le problème, c'est que presque personne ne la détecte avant qu'elle ne devienne coûteuse : quand ajouter une fonctionnalité simple prend des semaines, ou quand le seul développeur qui comprenait le système ne répond plus au téléphone.

Le coût réel, en pratique

L'analogie financière n'est pas qu'une figure de style. Un raccourci — sauter un test automatisé, dupliquer de la logique au lieu de l'extraire, coupler deux modules qui devraient être indépendants — ne coûte rien de visible le jour où il est pris. Le coût apparaît chaque fois que quelqu'un doit composer avec cette décision : comprendre pourquoi le code fait quelque chose d'étrange, éviter de casser une dépendance cachée, ou carrément réécrire cette partie parce que personne n'ose y toucher. Plus le temps passe entre le raccourci et le moment où quelqu'un le paie, plus il devient coûteux à corriger, parce qu'entre-temps davantage de code a été construit par-dessus en supposant que ce raccourci est « normal ».

Toute dette technique ne se vaut pas

Il est utile de répartir la dette technique selon deux axes : délibérée ou involontaire, et prudente ou imprudente. Une équipe qui décide consciemment de lancer sans une certaine optimisation parce qu'elle doit d'abord valider le produit prend une dette prudente et délibérée — un pari métier raisonnable, tant qu'il est documenté et qu'on prévoit de le rembourser. Le vrai problème, c'est la dette imprudente et involontaire : du code écrit sans bien comprendre le problème, copié d'un tutoriel sans l'adapter, ou construit sous tant de pression que personne n'a pu réfléchir aux conséquences. C'est celle-là qui s'accumule sans que personne ne la décide exprès, et c'est justement pour cela qu'elle est la plus dangereuse — elle n'apparaît dans aucune conversation jusqu'à ce qu'elle devienne un problème sérieux.

D'où elle vient réellement

• Des outils no-code utilisés pour ce pour quoi ils n'ont pas été conçus : une logique métier complexe poussée dans un éditeur visuel qui ne versionne pas le code et n'exécute aucun test.
• Des freelances qui livrent et disparaissent — sans documentation, sans passation, sans que personne d'autre ne comprenne les décisions qu'ils ont prises.
• La pression métier : « on lance maintenant, on corrigera plus tard » — et le « plus tard » n'arrive jamais parce que le système continue à vendre, même mal.
• L'absence de tests automatisés, si bien que chaque nouveau changement risque réellement de casser quelque chose qui fonctionnait déjà.

Le cas des outils no-code mérite un commentaire à part car il est particulièrement trompeur : c'est rapide et fonctionnel en démo, et pour un flux simple (une landing page avec un formulaire, un catalogue statique) c'est un outil parfaitement raisonnable. Le problème commence quand l'entreprise grandit et que la logique grandit avec elle — remises conditionnelles, intégrations de moyens de paiement, règles de stock — et que cette complexité continue d'être poussée dans le même éditeur visuel parce que « c'est déjà là ». On arrive à un point où le système a des règles métier critiques piégées dans une interface qui ne peut pas être versionnée dans Git, qui n'exécute aucun test automatisé, et qu'une seule personne dans l'entreprise sait naviguer. Ce n'est pas un mauvais outil — c'est un outil utilisé bien au-delà de sa vocation.

Signes que vous avez déjà de la dette technique

• Une fonctionnalité qui prenait des jours prend désormais des semaines, sans que le périmètre ait grandi.
• Personne dans l'équipe actuelle ne peut expliquer pourquoi le système fait quelque chose d'une manière spécifique.
• Chaque nouveau déploiement génère de l'anxiété, pas de la confiance.
• Le seul document technique qui existe est une conversation WhatsApp avec le freelance précédent.
• Ajouter un seul nouveau champ à un formulaire nécessite de toucher au code à cinq endroits différents.

Comment la mesurer sans outillage complexe

Pas besoin d'un tableau de bord sophistiqué pour commencer à voir le problème — trois signaux simples, suivis dans le temps, donnent déjà une bonne idée. D'abord, le temps qu'il faut à un nouveau développeur pour faire son premier commit utile : si dans un système sain cela prend deux ou trois jours et chez vous trois semaines, c'est un signe clair que la connaissance n'est pas dans le code mais dans la tête de quelqu'un. Ensuite, la durée des revues de code (pull requests) : si elles prennent de plus en plus de temps et suscitent de plus en plus de débats sur « ce que ça fait vraiment », le système devient plus difficile à raisonner. Enfin, le plus simple de tous : combien de fois par sprint l'équipe prononce la phrase « ne touchons pas à ça, au cas où ». Cette phrase, répétée, est la définition opérationnelle de la dette technique.

Un quatrième indicateur, moins évident mais tout aussi utile, est la proportion du temps de sprint passée à « comprendre » plutôt qu'à « construire ». Il est normal et sain que comprendre comment fonctionne quelque chose prenne une partie du temps de n'importe quelle tâche — mais quand une équipe commence à passer plus de temps à lire du vieux code pour comprendre ce qu'il fait qu'à écrire la nouvelle fonctionnalité elle-même, cette proportion inversée est l'un des signaux les plus fiables que le système a accumulé plus de complexité que l'équipe actuelle ne peut confortablement porter.

Comment l'éviter, pas comment la guérir

La dette technique ne se « répare » pas en une seule session de refactoring — elle se prévient par des décisions d'architecture prises dès le départ : du code que vous possédez (pas lié à un outil contrôlé par une autre entreprise), une vraie documentation technique livrée avec le logiciel (pas comme une faveur), et une séparation claire entre logique métier et couche de présentation pour qu'un changement dans l'une n'oblige pas à toucher l'autre.

En pratique, cela se maintient avec des habitudes concrètes, pas seulement de bonnes intentions : revue de code obligatoire avant d'intégrer tout changement (même à deux), un registre bref des décisions d'architecture importantes — ce qui a été décidé et pourquoi, pas un document de vingt pages, juste de quoi permettre à quelqu'un de nouveau de comprendre le raisonnement six mois plus tard — et des tests automatisés au moins sur la logique métier critique, même sans atteindre une couverture totale dès le premier jour.

Le rôle des tests automatisés pour freiner la nouvelle dette

Une suite de tests automatisés n'élimine pas la dette technique déjà existante, mais elle joue un rôle distinct et précieux : elle freine la nouvelle dette. Sans tests, chaque changement est un saut dans le vide — personne ne sait avec certitude si quelque chose s'est cassé jusqu'à ce qu'un utilisateur le signale. Avec des tests couvrant les flux métier critiques (traiter un paiement, calculer un prix, générer une facture), l'équipe peut refactoriser avec une vraie confiance, car il existe un moyen objectif de savoir si le comportement a changé ou non. C'est ce qui permet de rembourser la dette technique existante sans crainte constante de casser quelque chose qui fonctionnait déjà — et c'est pourquoi un système sans aucun test automatisé a tendance à accumuler de la dette à un rythme croissant, pas constant.

Quand un outil no-code a réellement du sens

Il faut être juste envers l'outil : pour un prototype qui valide une idée métier avant d'investir dans du développement sur mesure, pour une landing page avec un formulaire, ou pour un flux interne simple qui change rarement, un outil no-code est une décision parfaitement raisonnable — plus rapide et moins cher qu'écrire du code sur mesure pour quelque chose qui pourrait même ne pas survivre à la validation du marché. L'outil lui-même n'est jamais le problème — c'est l'absence de plan sur le moment où migrer vers du code sur mesure une fois que la logique métier cesse d'être simple. Cette décision — « à partir d'ici, ça doit devenir du code versionné » — devrait être prise exprès, pas découverte six mois trop tard quand c'est déjà douloureux.

La migration incrémentale en pratique

Si vous en êtes déjà au point où « personne ne comprend ça », une migration complète est généralement moins coûteuse à long terme que de continuer à rustiner — mais cela ne veut pas dire arrêter l'activité pendant deux mois pour tout réécrire. Elle peut se faire de façon incrémentale, module par module, si la nouvelle architecture est conçue pour coexister avec l'ancienne pendant son remplacement : le module le plus isolé et le moins risqué est migré en premier, validé en production avec du trafic réel, et c'est seulement ensuite qu'on passe au suivant. C'est plus lent qu'un « Big Bang », mais c'est la différence entre une migration qu'on peut mettre en pause sans laisser l'activité à moitié faite et un pari du tout ou rien.

L'erreur la plus fréquente à ce stade n'est pas technique, elle concerne les attentes : traiter la migration incrémentale comme un projet avec une date de clôture fixe, plutôt que comme un processus continu priorisé avec le reste de la feuille de route. Quand l'entreprise comprend que chaque module migré réduit le risque accumulé et libère de la capacité pour construire de nouvelles fonctionnalités plus vite, il est plus facile de soutenir l'effort dans la durée — au lieu de l'abandonner à mi-chemin dès qu'apparaît une priorité métier urgente, ce qui est exactement comment un système finit avec la moitié de son architecture modernisée et l'autre moitié figée dans le temps.