La dette technique
Un raccourci peut être raisonnable s’il reste suivi. Comprenez la dette technique, ses coûts et les questions à poser avant de tout reconstruire.
Sur cette page4 sections
Il y a le tiroir qu'on range correctement, et celui dans lequel on pousse tout en se disant qu'on s'en occupera samedi. Tant qu'on ne cherche rien, le deuxième a l'air de fonctionner aussi bien. Le jour où il faut retrouver une facture précise, on comprend ce qu'on avait remis à plus tard.
La dette technique me fait penser à ça. Un site peut très bien fonctionner pour ses visiteurs tout en devenant de plus en plus pénible à modifier pour la personne qui s'en occupe. Le problème ne se voit pas toujours sur la page d'accueil. Il apparaît quand on veut changer quelque chose qui semblait simple.
Le raccourci peut donc être raisonnable. Le vrai sujet, c'est ce qui se passera quand vous voudrez ajouter une deuxième formule : est-ce qu'on avait prévu l'endroit à reprendre, ou est-ce qu'il faut découvrir comment tout tient ensemble ?
La métaphore de la dette technique décrit ce décalage entre le temps gagné maintenant et le travail que cela peut ajouter ensuite. Et toute la dette n'est pas prise consciemment : le quadrant de Martin Fowler distingue aussi ce qu'on découvre avec l'expérience. On peut avoir fait un choix de bonne foi, puis comprendre qu'une autre organisation aurait mieux accompagné le projet.
Au début, recopier le prix était rapide. Ensuite, chaque modification coûte un peu plus de temps et d'attention. C'est là que l'image de la dette devient parlante : on paie le raccourci plusieurs fois, pas seulement le jour où on l'a pris.
Le même phénomène existe avec une installation connue d'une seule personne, ou avec une partie du site qu'on n'ose plus toucher parce qu'on ne sait pas ce qu'elle pourrait casser. Ce n'est pas nécessairement visible pour les visiteurs, mais ça finit par peser sur les évolutions que vous pouvez demander.
Pour le tarif recopié, une réponse peut être de le centraliser puis de vérifier les endroits qui l'affichent. Pour une mise en ligne fragile, on peut commencer par décrire la procédure et la rendre reproductible. Ce sont deux interventions très différentes ; elles ne justifient pas automatiquement une refonte complète.
À l'inverse, si chaque évolution importante oblige à contourner les mêmes limites, une reconstruction peut devenir cohérente. On compare alors le travail de reprise à celui des corrections qu'on continuerait à accumuler. Le choix se fait sur le projet, pas sur l'envie d'avoir du code neuf.
On peut noter ce qu'on reporte et le reprendre lorsqu'il commence à gêner une évolution ou à créer un risque. La maintenance peut accueillir ce travail, avec des actions précises plutôt qu'un grand chantier permanent pour rendre le code parfait.
Si vous cherchez les signes à repérer sur votre site, j'en parle plus concrètement dans cet article sur le diagnostic de la dette technique. Ici, ce que j'aimerais surtout vous laisser, c'est le droit de faire un compromis sans vous raconter qu'il est gratuit. On peut fermer le tiroir aujourd'hui. Ça aide simplement de savoir ce qu'on y a mis et quand on compte le rouvrir.
La dette technique me fait penser à ça. Un site peut très bien fonctionner pour ses visiteurs tout en devenant de plus en plus pénible à modifier pour la personne qui s'en occupe. Le problème ne se voit pas toujours sur la page d'accueil. Il apparaît quand on veut changer quelque chose qui semblait simple.
Parfois on a de bonnes raisons de fermer le tiroir
Imaginons que vous lanciez une activité avec une seule offre. On peut développer immédiatement une organisation capable de gérer vingt formules, ou commencer avec celle dont vous avez réellement besoin. Passer du temps sur les dix-neuf autres avant de savoir si l'activité fonctionne n'est pas forcément le meilleur choix.Le raccourci peut donc être raisonnable. Le vrai sujet, c'est ce qui se passera quand vous voudrez ajouter une deuxième formule : est-ce qu'on avait prévu l'endroit à reprendre, ou est-ce qu'il faut découvrir comment tout tient ensemble ?
La métaphore de la dette technique décrit ce décalage entre le temps gagné maintenant et le travail que cela peut ajouter ensuite. Et toute la dette n'est pas prise consciemment : le quadrant de Martin Fowler distingue aussi ce qu'on découvre avec l'expérience. On peut avoir fait un choix de bonne foi, puis comprendre qu'une autre organisation aurait mieux accompagné le projet.
Une petite modification qui oblige à ouvrir cinq fichiers
Prenons un tarif recopié sur la page des prestations, dans un formulaire, dans le mail de confirmation et dans un document téléchargé. Pour le changer, il faut se souvenir de tous ces endroits. Si on en oublie un, deux clients peuvent recevoir des informations différentes.Au début, recopier le prix était rapide. Ensuite, chaque modification coûte un peu plus de temps et d'attention. C'est là que l'image de la dette devient parlante : on paie le raccourci plusieurs fois, pas seulement le jour où on l'a pris.
Le même phénomène existe avec une installation connue d'une seule personne, ou avec une partie du site qu'on n'ose plus toucher parce qu'on ne sait pas ce qu'elle pourrait casser. Ce n'est pas nécessairement visible pour les visiteurs, mais ça finit par peser sur les évolutions que vous pouvez demander.
On ne vide pas toute la maison pour ranger un tiroir
Quand on découvre ça, la tentation est parfois de tout refaire. Je comprends : repartir sur quelque chose de neuf donne l'impression qu'on va enfin respirer. Mais il faut déplacer les contenus, les comptes, les données et les habitudes des utilisateurs. Ce n'est plus seulement une histoire de code.Pour le tarif recopié, une réponse peut être de le centraliser puis de vérifier les endroits qui l'affichent. Pour une mise en ligne fragile, on peut commencer par décrire la procédure et la rendre reproductible. Ce sont deux interventions très différentes ; elles ne justifient pas automatiquement une refonte complète.
À l'inverse, si chaque évolution importante oblige à contourner les mêmes limites, une reconstruction peut devenir cohérente. On compare alors le travail de reprise à celui des corrections qu'on continuerait à accumuler. Le choix se fait sur le projet, pas sur l'envie d'avoir du code neuf.
Le plus tard mérite une place dans le calendrier
Le raccourci qui m'inquiète le plus, ce n'est pas forcément celui qu'on prend pour sortir une première version. C'est celui qu'on oublie ensuite, alors que le site continue de grandir autour.On peut noter ce qu'on reporte et le reprendre lorsqu'il commence à gêner une évolution ou à créer un risque. La maintenance peut accueillir ce travail, avec des actions précises plutôt qu'un grand chantier permanent pour rendre le code parfait.
Si vous cherchez les signes à repérer sur votre site, j'en parle plus concrètement dans cet article sur le diagnostic de la dette technique. Ici, ce que j'aimerais surtout vous laisser, c'est le droit de faire un compromis sans vous raconter qu'il est gratuit. On peut fermer le tiroir aujourd'hui. Ça aide simplement de savoir ce qu'on y a mis et quand on compte le rouvrir.
