Un développeur doit ajouter une deuxième langue à un site web. Les traductions sont prêtes : la demande semble simple. Pourtant, plusieurs jours plus tard, l’équipe modifie encore des templates, des messages d’erreur et des intégrations où la langue avait été codée en dur. Un choix qui faisait gagner du temps au départ ralentit désormais chaque évolution.
Cet exemple fictif illustre le véritable problème de la dette technique : non pas l’ancienneté du code, mais le coût des choix passés et la possibilité de décider en connaissance de cause.
La dette technique ne signifie pas simplement « mauvais code »
Martin Fowler utilise la dette technique comme métaphore des décisions qui rendent les travaux futurs plus coûteux. Son quadrant distingue les compromis prudents ou imprudents, délibérés ou involontaires. Une première version simplifiée peut être raisonnable. Même une équipe compétente découvre parfois une meilleure conception en développant son produit.
La facture arrive lors de la modification suivante
Le site ne proposait initialement qu’une langue. Avec de nouveaux éditeurs et marchés, chaque composant gère différemment les traductions et les tests ne couvrent pas toutes les variantes. Le coût ne se limite pas à une refonte : chaque mise en production demande davantage de vérifications. « Nettoyer l’ancien code » n’explique pas le problème. Précisez plutôt quelles évolutions sont ralenties, quels utilisateurs sont touchés et quels risques augmentent.
Conserver la raison du choix initial
Un Architecture Decision Record (ADR) conserve le contexte, les options, la décision, ses motifs et ses conséquences. Pour un compromis temporaire, ajoutez un responsable et une condition de réexamen. Dans notre scénario, l’équipe aurait pu écrire : « Nous lançons une seule langue et réévaluons le modèle dès qu’une deuxième devient nécessaire. » Il s’agit d’un exemple inventé, pas d’un document de projet réel.
Tout ne doit pas être refait immédiatement
Fowler souligne que rembourser une dette peut être peu utile si son coût récurrent est minime, par exemple dans du code rarement modifié. Une runtime non maintenue et vulnérable exige une autre réponse qu’un composant interne ancien mais stable. Évaluez la fréquence des changements, les incidents, les efforts et le risque d’intervention plutôt que de chercher systématiquement la modernisation.
Tester les frontières fragiles
Les intégrations offrent un exemple parlant : une API fonctionne tant que le fournisseur répond, puis échoue lors d’une panne temporaire. Sans nouvelles tentatives adaptées, idempotence ou surveillance, l’incident peut s’étendre. Testez les scénarios d’échec et de restauration ; un pourcentage élevé de couverture de code ne suffit pas à prouver leur fiabilité.
Transformer la frustration en résultat vérifiable
Pour notre site multilingue, l’objectif peut devenir : « Ajouter une langue sans modifier les composants de présentation, avec un mécanisme documenté pour les traductions absentes. » Définissez un responsable, une manière de tester et une mesure du temps réellement économisé lors des évolutions suivantes.
Rendre les compromis discutables
La dette technique ne disparaîtra jamais totalement : les exigences changent et les équipes apprennent. L’enjeu est de savoir quels compromis existent, ce qu’ils coûtent et quand leur correction devient plus intéressante que leur report.
dossier d’architecture web · les erreurs d’intégration dans les organisations en croissance (en anglais) (BlazeForce, sponsor).
Sources
Contactez-nous
Dites-nous comment nous pouvons vous aider ; nous répondons sous deux jours ouvrés.
