Dette technique d’un site web : la reconnaître et reprendre le contrôle de la maintenance
Votre site fonctionne mais chaque modification devient risquée ? Accès, formulaires, sauvegardes et options pour reprendre une maintenance maîtrisable.
Sur cette page6 sections
Votre site s’ouvre normalement, les pages sont là, et vous voulez simplement ajouter une pièce jointe au formulaire de contact. Pourtant, personne ne veut toucher au formulaire avant d’avoir retrouvé comment les mails sont envoyés, quelle extension le gère et pourquoi la dernière mise à jour avait cassé les notifications. La modification semble petite. Tout ce qu’il faut comprendre avant de la faire ne l’est plus.
C’est souvent à ce moment-là que la dette technique devient concrète pour le propriétaire du site. Pas sous la forme d’une alerte rouge, mais sous la forme d’un « surtout, ne touche pas à ça ». J’ai déjà expliqué le principe de la dette technique dans un autre article. Ici, l’idée est plus pratique : comment savoir ce qui bloque réellement la maintenance, et comment reprendre la main sans décider de tout refaire dès la première difficulté ?
À l’inverse, un vieux site n’est pas forcément mauvais. S’il remplit encore son rôle, que ses composants peuvent être entretenus et qu’on sait comment le faire évoluer, son âge ne justifie pas à lui seul une refonte. Un outil récent peut être beaucoup plus pénible si chaque modification repose sur un assemblage que personne ne comprend.
Ce que je chercherais, ce sont les moments où une opération normale devient anormalement incertaine. Une mise à jour qu’on repousse systématiquement. Un correctif qui revient trois fois. Un formulaire dont on ne sait plus qui reçoit les mails. Ce sont des indices, pas encore un diagnostic : il faut comprendre ce qui les provoque.
Le problème peut être assez local : un réglage d’envoi oublié, une adresse obsolète ou une incompatibilité précise. Dans ce cas, une correction ciblée peut suffire. Il peut aussi révéler une difficulté plus large : plusieurs formulaires différents, chacun avec son propre fonctionnement, et aucune façon fiable de tester les changements.
Ce n’est pas la même intervention. Dire « le site est mal fait » ne permet pas de les distinguer, et proposer directement un nouveau site non plus. Je préfère montrer ce qui échoue, pourquoi, et ce que chaque option résoudrait réellement.
Une extension indispensable et bien suivie n’est pas équivalente à une extension inutilisée qu’on conserve parce qu’on a peur de la supprimer. Même chose pour le no-code : ce n’est pas le nom de l’outil qui décide de la qualité. Le problème commence quand les contournements s’accumulent au point qu’une modification banale devient un projet à elle seule.
Photo d’illustration, pas le diagnostic de cette installation. Pour votre site aussi, savoir quel élément est relié à quoi est plus utile que juger l’ensemble à son apparence.
L’inventaire doit aboutir à quelque chose que vous pouvez comprendre : les éléments critiques, les accès manquants, les difficultés observées et les options pour les traiter. Pas seulement une liste de termes techniques accompagnée d’une facture.
Le retour arrière mérite aussi d’être réfléchi. Restaurer une ancienne copie d’une boutique peut faire disparaître les commandes reçues depuis cette copie. On ne traite donc pas un site vitrine et un site qui enregistre des transactions exactement de la même manière.
Ensuite, on établit quelques tests simples sur les parcours importants : envoyer une demande, recevoir la notification, réserver ou payer si le site le permet. Cela donne un point de comparaison avant et après l’intervention. Sinon, « ça a l’air de marcher » devient notre seul moyen de contrôle.
Une refonte peut se justifier lorsque la base ne permet plus de maintenir les fonctions nécessaires dans des conditions acceptables. Mais elle ne fait pas disparaître les besoins du métier, les contenus à reprendre ni les raccordements à la messagerie et aux autres outils. Il faut comparer une remise en état à une reconstruction en comptant tout cela, pas opposer un vieux site imparfait à un nouveau site imaginaire qui n’aurait aucun problème.
J’ai détaillé cette comparaison dans l’article sur la refonte d’un site. Le bon choix est celui qui remet votre fonctionnement sur une base maîtrisable, pas forcément celui qui produit le plus de nouvelles pages.
Le résultat que je cherche est assez simple : quand vous demandez une modification, on sait où intervenir, comment vérifier le résultat et quoi faire si ça se passe mal. Vous n’avez pas besoin de connaître chaque fichier du site. Vous devez en revanche savoir qui en assure la maintenance, ce qui est suivi et ce qui reste à traiter.
Si chaque changement est devenu une source d’inquiétude, on peut faire le point sur votre site. Je préfère partir de ses blocages réels et vous expliquer les options plutôt que vous vendre une refonte uniquement parce que le mot « dette technique » fait peur.
C’est souvent à ce moment-là que la dette technique devient concrète pour le propriétaire du site. Pas sous la forme d’une alerte rouge, mais sous la forme d’un « surtout, ne touche pas à ça ». J’ai déjà expliqué le principe de la dette technique dans un autre article. Ici, l’idée est plus pratique : comment savoir ce qui bloque réellement la maintenance, et comment reprendre la main sans décider de tout refaire dès la première difficulté ?
Un site qui fonctionne peut être difficile à entretenir
Voir une page s’afficher prouve que cette page s’affiche aujourd’hui. Ça ne dit pas si quelqu’un sait la modifier, si les demandes arrivent au bon endroit ou si une restauration est possible en cas de problème. C’est un peu comme une voiture qui démarre : c’est rassurant, mais ce n’est pas son carnet d’entretien.À l’inverse, un vieux site n’est pas forcément mauvais. S’il remplit encore son rôle, que ses composants peuvent être entretenus et qu’on sait comment le faire évoluer, son âge ne justifie pas à lui seul une refonte. Un outil récent peut être beaucoup plus pénible si chaque modification repose sur un assemblage que personne ne comprend.
Ce que je chercherais, ce sont les moments où une opération normale devient anormalement incertaine. Une mise à jour qu’on repousse systématiquement. Un correctif qui revient trois fois. Un formulaire dont on ne sait plus qui reçoit les mails. Ce sont des indices, pas encore un diagnostic : il faut comprendre ce qui les provoque.
Repartons de notre formulaire
Avant d’ajouter la pièce jointe, je voudrais suivre le trajet d’une demande : où elle est saisie, où elle est enregistrée, comment le mail part et qui le reçoit. Si le formulaire affiche « message envoyé » mais que la messagerie refuse le mail, le visiteur pense avoir contacté l’entreprise tandis que l’entreprise ne voit rien.Le problème peut être assez local : un réglage d’envoi oublié, une adresse obsolète ou une incompatibilité précise. Dans ce cas, une correction ciblée peut suffire. Il peut aussi révéler une difficulté plus large : plusieurs formulaires différents, chacun avec son propre fonctionnement, et aucune façon fiable de tester les changements.
Ce n’est pas la même intervention. Dire « le site est mal fait » ne permet pas de les distinguer, et proposer directement un nouveau site non plus. Je préfère montrer ce qui échoue, pourquoi, et ce que chaque option résoudrait réellement.
Faire l’inventaire, ce n’est pas compter les extensions
Je veux d’abord savoir qui possède les comptes : domaine, hébergement, messagerie, outil de paiement s’il y en a un. Puis quelles briques servent à quoi, lesquelles sont encore maintenues, et où sont les personnalisations. Une liste de vingt extensions sans explication de leur rôle ne donne pas beaucoup de prise sur le problème.Une extension indispensable et bien suivie n’est pas équivalente à une extension inutilisée qu’on conserve parce qu’on a peur de la supprimer. Même chose pour le no-code : ce n’est pas le nom de l’outil qui décide de la qualité. Le problème commence quand les contournements s’accumulent au point qu’une modification banale devient un projet à elle seule.
Photo d’illustration, pas le diagnostic de cette installation. Pour votre site aussi, savoir quel élément est relié à quoi est plus utile que juger l’ensemble à son apparence.
L’inventaire doit aboutir à quelque chose que vous pouvez comprendre : les éléments critiques, les accès manquants, les difficultés observées et les options pour les traiter. Pas seulement une liste de termes techniques accompagnée d’une facture.
Avant de réparer, vérifier qu’on peut revenir en arrière
Je ne commencerais pas une grosse série de mises à jour directement sur le site en ligne. Il faut une sauvegarde adaptée, vérifier qu’elle peut être restaurée et, quand c’est possible, reproduire le site dans un environnement de test. Un fichier appelé « sauvegarde » n’apporte pas grand-chose si personne ne sait ce qu’il contient ni comment l’utiliser.Le retour arrière mérite aussi d’être réfléchi. Restaurer une ancienne copie d’une boutique peut faire disparaître les commandes reçues depuis cette copie. On ne traite donc pas un site vitrine et un site qui enregistre des transactions exactement de la même manière.
Ensuite, on établit quelques tests simples sur les parcours importants : envoyer une demande, recevoir la notification, réserver ou payer si le site le permet. Cela donne un point de comparaison avant et après l’intervention. Sinon, « ça a l’air de marcher » devient notre seul moyen de contrôle.
Réparer, simplifier ou refaire : la réponse dépend du blocage
Si un composant précis est en cause et que le reste est entretenable, je privilégierais sa correction ou son remplacement. Si plusieurs composants font la même chose, simplifier peut éviter d’avoir à entretenir trois versions du même fonctionnement. Si les problèmes reviennent toujours au même endroit, traiter leur cause est généralement plus intéressant qu’empiler un nouveau correctif.Une refonte peut se justifier lorsque la base ne permet plus de maintenir les fonctions nécessaires dans des conditions acceptables. Mais elle ne fait pas disparaître les besoins du métier, les contenus à reprendre ni les raccordements à la messagerie et aux autres outils. Il faut comparer une remise en état à une reconstruction en comptant tout cela, pas opposer un vieux site imparfait à un nouveau site imaginaire qui n’aurait aucun problème.
J’ai détaillé cette comparaison dans l’article sur la refonte d’un site. Le bon choix est celui qui remet votre fonctionnement sur une base maîtrisable, pas forcément celui qui produit le plus de nouvelles pages.
La maintenance doit redevenir une opération normale
Je remettrais les priorités dans cet ordre : retrouver les accès et les responsabilités, sécuriser la possibilité de restaurer, rétablir les parcours qui font fonctionner l’activité, puis éliminer les causes des incidents récurrents. Le reste peut être planifié sans prétendre régler tout le passé d’un seul coup.Le résultat que je cherche est assez simple : quand vous demandez une modification, on sait où intervenir, comment vérifier le résultat et quoi faire si ça se passe mal. Vous n’avez pas besoin de connaître chaque fichier du site. Vous devez en revanche savoir qui en assure la maintenance, ce qui est suivi et ce qui reste à traiter.
Si chaque changement est devenu une source d’inquiétude, on peut faire le point sur votre site. Je préfère partir de ses blocages réels et vous expliquer les options plutôt que vous vendre une refonte uniquement parce que le mot « dette technique » fait peur.
