Dette technique

La dette technique, c'est ce que vous devez à votre logiciel après avoir pris des raccourcis. Un développeur écrit le prix de livraison en dur au lieu de le rendre paramétrable, copie un bloc de code au lieu de le réutiliser, ou saute les tests pour tenir une date de lancement. Chaque choix fait gagner du temps aujourd'hui. Chacun rend aussi l'évolution suivante un peu plus lente et un peu plus risquée. Cet effort supplémentaire, payé encore et encore, ce sont les intérêts de la dette.

Le sujet vous concerne dès que vous possédez un logiciel sur mesure, même modeste : une boutique en ligne développée par un freelance, un assemblage de plugins, un script qui recopie les commandes dans un tableur. Il vous concerne aussi quand vous choisissez une plateforme, car un produit alourdi par la dette livre ses améliorations lentement et tombe plus souvent en panne.

Qu'est-ce que la dette technique ?

La dette technique est l'écart entre la façon dont un logiciel est construit et la façon dont il devrait l'être pour rester facile à faire évoluer. Le terme vient du programmeur Ward Cunningham, qui cherchait une image parlante pour les non-techniciens : livrer vite avec un code imparfait, c'est comme emprunter de l'argent. Ce n'est pas une faute en soi, à condition de savoir que l'on a emprunté et de prévoir le remboursement.

Ce n'est pas un bug. Un bug est un comportement visible et incorrect. La dette est souvent invisible pour les utilisateurs : la boutique fonctionne, mais chaque modification prend trois jours au lieu d'un. Ce n'est pas non plus une question d'âge. Un vieux système peut être propre et facile à maintenir, et un système tout neuf peut être criblé de dette dès son premier mois.

Le vocabulaire voisin :

• Refactoring (ou refactorisation) : réécrire du code pour améliorer sa structure sans changer ce qu'il fait. C'est le principal moyen de rembourser la dette.
• Code legacy (ou patrimoine applicatif) : du code ancien que l'on n'ose plus toucher, souvent parce que plus personne ne le comprend entièrement.
• Dette volontaire : un raccourci pris en connaissance de cause, pour une bonne raison, avec un plan pour le corriger.
• Dette involontaire : la dette née de l'inexpérience, de la précipitation ou d'un besoin qui a changé après l'écriture du code.
• Pourrissement du code : la dégradation lente d'un logiciel à mesure que ses dépendances vieillissent et que ses auteurs s'en vont.

Pourquoi c'est important

La dette apparaît dans votre budget sous forme de livraisons plus lentes et d'incidents plus fréquents, bien avant que quelqu'un prononce le mot.

Prenez une marque de décoration qui traite 800 commandes par mois sur une boutique développée sur mesure il y a deux ans. Au lancement, une petite modification comme l'ajout d'une zone de livraison demandait une demi-journée à un développeur. Aujourd'hui, la même modification prend deux jours, parce que les règles de livraison sont recopiées à quatre endroits et que personne n'ose y toucher sans tout retester à la main. À 450 € la journée, un changement qui coûtait 225 € en coûte maintenant 900. Si la marque demande 15 changements de ce type par an, les intérêts atteignent environ 10 000 € par an, payés sans bruit.

Vient ensuite le risque. L'une des règles recopiées est oubliée lors d'une mise à jour, et pendant un week-end les commandes internationales sont facturées au tarif national. Sur 60 commandes avec un écart de 12 €, cela fait 720 € perdus, sans compter le temps passé au support. Tôt ou tard, un développeur proposera une réécriture partielle à 6 000 € par exemple. C'est le capital de l'emprunt qui arrive à échéance.

Comment ça marche

La dette s'accumule et se rembourse selon quelques mécanismes récurrents :

• Un raccourci est pris. Sous la pression du calendrier, l'équipe choisit l'option rapide plutôt que l'option propre. C'est parfois le bon choix, par exemple pour tester une idée avant d'y investir.
• Le raccourci se propage. D'autres parties du code commencent à en dépendre. Plus il reste en place, plus il coûte cher à retirer.
• Les évolutions ralentissent. Les développeurs passent plus de temps à comprendre et contourner l'existant qu'à écrire du neuf. Les estimations gonflent pour des tâches qui semblent simples.
• Les incidents se multiplient. Les parties fragiles cassent quand quelque chose change à côté. Les corrections sont faites dans l'urgence, ce qui ajoute souvent de la dette.
• Les dépendances vieillissent. Bibliothèques et frameworks publient de nouvelles versions et des correctifs de sécurité. Reporter les mises à jour pendant des années transforme une montée de version banale en projet.
• La dette est remboursée. L'équipe refactorise, ajoute des tests, supprime les doublons ou met à jour les dépendances. Les meilleures équipes le font en continu, un peu à chaque cycle, plutôt que dans une réécriture douloureuse.

La façon dont un système est conçu, son architecture logicielle, influence fortement la vitesse d'accumulation. Des frontières nettes entre les parties empêchent un raccourci pris à un endroit de contaminer le reste.

Repères et exemples

La dette se mesure mal avec précision, mais quelques signaux ne trompent pas :

• La part du temps consacrée à la maintenance. Beaucoup d'équipes réservent 15 à 25 % de chaque cycle au refactoring et aux mises à jour. Quand les corrections imprévues dépassent un tiers du temps, la dette prend en général le dessus.
• Les estimations. Si des changements similaires prennent deux à quatre fois plus de temps qu'il y a un an, le code prélève des intérêts.
• L'âge des dépendances. Un framework en retard de deux versions majeures ou plus est un signal d'alerte classique, surtout pour la sécurité.
• La peur de toucher au code. Quand un développeur dit « cette partie-là, on n'y touche pas », vous avez trouvé la dette.

Des situations typiques chez les vendeurs :

• Une boutique montée à coups de plugins. Chaque plugin réglait un problème rapidement. Trois ans plus tard, deux d'entre eux entrent en conflit, un autre est abandonné par son auteur, et les mises à jour cassent le checkout.
• Le site de formation d'une créatrice. Construit en vitesse par un ami pour un lancement, il fonctionne, mais personne d'autre ne sait le maintenir quand l'ami est indisponible.
• Le premier projet d'un freelance. La boutique est belle mais n'a aucun test, si bien que chaque nouvelle fonctionnalité risque d'en casser une ancienne.

Erreurs fréquentes

• Considérer toute dette comme mauvaise. Un raccourci volontaire pour tester une idée vite est souvent malin. Le problème, c'est la dette que personne ne connaît ou ne prévoit de rembourser.
• Ne jamais budgéter le remboursement. Si 100 % du temps de développement part dans les nouveautés, la dette grossit chaque mois jusqu'au blocage.
• Attendre la grande réécriture. Une refonte complète coûte cher, prend du temps, comporte des risques et recrée souvent les anciens problèmes. Un remboursement régulier et modeste fonctionne mieux.
• Reporter les mises à jour des dépendances. Les mises à jour repoussées s'empilent jusqu'à une migration lourde, et les anciennes versions ne reçoivent plus les correctifs de sécurité.
• Juger les développeurs uniquement sur la vitesse. Exiger des fonctionnalités à tout prix récompense les raccourcis et cache la facture.

Bonnes pratiques

• Parlez de dette au moment du recrutement. Demandez à un freelance ou à une agence comment ils gèrent les tests, les mises à jour et la documentation. Une bonne réponse est précise.
• Tenez une liste de la dette. Notez chaque raccourci connu avec sa raison et un coût approximatif de correction. Ce qui est écrit peut être priorisé.
• Réservez une part fixe du temps. Prévoyez 15 à 20 % de chaque cycle pour le nettoyage et les mises à jour, même quand la roadmap déborde.
• Remboursez là où vous modifiez souvent. Concentrez l'effort sur les parties du système que vous touchez chaque mois, pas sur les recoins qui ne bougent jamais.
• Exigez documentation et propriété. Assurez-vous qu'une autre personne que l'auteur peut comprendre et maintenir le code, et que le dépôt vous appartient.
• Confiez les briques standard à une plateforme maintenue. Panier, checkout et intégrations de paiement sont les mêmes pour la plupart des vendeurs. Les laisser à un SaaS vous évite de porter cette dette vous-même.

Dans Roctify

Avec Roctify, le panier, le checkout sur une seule page, le catalogue partagé, les paiements via Stripe, PayPal et paiement à la livraison, la livraison des produits digitaux et les réglages de TVA font partie d'une plateforme que l'équipe Roctify construit et maintient. Roctify héberge la boutique, la maintient à jour et sert chaque page en HTTPS avec un certificat SSL gratuit. Mises à jour des dépendances, correctifs de sécurité et refactoring se font côté plateforme, et ne deviennent pas une dette à votre charge.

Vous gardez la main sur vos produits, vos contenus et vos réglages, qui peuvent eux aussi dériver : fiches produit obsolètes, codes promo oubliés. Une revue rapide tous les quelques mois garde votre boutique aussi propre que le code qui la fait tourner. Si vous avez besoin de travaux sur mesure autour de la plateforme, les intégrations se discutent dans l'offre Enterprise, ce qui garde le code spécifique réduit et bien délimité. C'est l'avantage concret d'un développement logiciel assuré par d'autres : les intérêts sont à leur charge.

FAQ

La dette technique est-elle toujours une mauvaise chose ?

Non. S'endetter volontairement peut être la bonne décision, par exemple pour lancer un test avant d'investir dans une version propre. Cela devient un problème quand la dette est invisible, non planifiée ou laissée à l'abandon pendant des années. L'essentiel est de savoir ce que vous avez emprunté et quand vous le rembourserez.

Comment repérer la dette technique sans être développeur ?

Observez les signaux : des modifications simples de plus en plus chères, des bugs fréquents après les mises à jour, des développeurs réticents à toucher certaines parties, des dépendances vieilles de plusieurs années. Demandez directement à votre développeur quelles parties il nettoierait en premier et pourquoi. Une réponse claire est bon signe.

Faut-il refaire ma boutique pour se débarrasser de la dette ?

Rarement en premier recours. Une refonte coûte cher et comporte ses propres risques. Commencez par rembourser la dette dans les zones que vous modifiez le plus, et envisagez de confier les briques standard comme le panier et le checkout à une plateforme maintenue. La refonte n'a de sens que si réparer coûterait plus cher que reconstruire.