Refondre ou corriger ? Le test avant de tout refaire

« Il faut tout refaire. » La phrase arrive vite, souvent à la suite d’un seul irritant : une page lente, un design qui date, un formulaire qui plante. Elle engage pourtant un chantier complet, avec un budget, un calendrier et un risque de perdre ce qui fonctionne. Avant de la prononcer, ou de l’accepter dans un devis, mieux vaut passer par un test simple : qu’est-ce qui est cassé, et qu’est-ce qui ne l’est pas ?

Cette fiche vous donne ce test sous forme de grille : corriger, refondre ou conserver. Elle aide à décider ; elle ne chiffre pas. Le coût d’une refonte relève d’une fiche à part, tout comme la rédaction du cahier des charges de refonte. Elle ne détaille pas non plus la procédure de redirection des anciennes adresses, qui dépend de chaque projet.

Un mot sur ce que la fiche n’est pas : elle n’est pas l’audit de votre site. La rédaction ne l’a pas vu et n’en tire aucune conclusion. Le test ci-dessous se déroule chez vous, avec vos pages sous les yeux.

Nommer les problèmes observables

Le premier piège est de partir d’un ressenti. « Le site fait vieux » n’est pas une observation : ni un chantier ne se dimensionne ni un prestataire ne se contrôle avec cela. Un problème observable se décrit de façon à ce qu’une autre personne puisse le constater.

Écrivez, pour chaque problème, quatre éléments :

• Où : la page, le parcours ou la fonction concernée.
• Quoi : ce que l’on voit, concrètement (« le formulaire de contact n’envoie rien depuis un téléphone »).
• Pour qui : visiteur, client, équipe qui met à jour le site.
• Depuis quand, si vous le savez.

Séparez ensuite les problèmes selon leur nature : un défaut de contenu (texte périmé, information fausse), un défaut de fonctionnement (une fonction en panne), un défaut de structure (les visiteurs ne trouvent pas ce qu’ils cherchent), un défaut de socle (l’outil sur lequel repose le site ne peut plus être mis à jour ou ne permet plus ce que vous voulez). Seul le dernier appelle plus facilement une reconstruction. Les trois premiers se traitent, au moins en partie, sans toucher au reste.

La page de France Num sur les cahiers des charges le rappelle indirectement : un cahier des charges bien posé sert à « imaginer la trame du site, son identité, sa structure, les choix et les fonctionnalités », et il peut servir aussi bien à créer qu’à « rénover » un site. Rénover figure donc dans le même exercice que créer. Si vous ne pouvez pas remplir la liste des problèmes, vous n’êtes pas prêt à signer une refonte.

Ce qui peut être corrigé sans reconstruction

Beaucoup de défauts se corrigent par morceaux. L’intérêt est de borner la dépense à un lot précis : le lot est un bloc de travail chiffré à part, avec sa ligne de devis. Une correction ciblée se compare facilement à une autre ; une refonte, beaucoup moins.

Le tableau ci-dessous est un modèle de tri. Il ne contient aucun résultat d’audit : c’est à vous de le remplir pour votre site.

Pour la dernière ligne, demandez au prestataire de dire explicitement si l’ajout est une évolution du site existant ou s’il suppose de changer d’outil. La réponse écrite évite qu’un simple ajout soit présenté comme une raison de tout reprendre.

Sur l’accessibilité, le W3C, via sa page de planification, décrit une approche d’« interim repairs » (réparations provisoires) pour les situations où l’on ne sait pas par où commencer : un aperçu concis pointe vers les problèmes les plus critiques. Cette idée de réparer d’abord ce qui bloque, sans reconstruire, vaut aussi comme principe pour les autres défauts.

Inventorier ce qu'il faut conserver

La refonte détruit rarement par choix ; elle détruit par oubli. Avant de décider, listez ce que vous ne voulez pas perdre. Cet inventaire est la deuxième moitié du test.

À inventorier :

• Les contenus qui servent : pages consultées, articles utiles, documents téléchargés, fiches produits.
• Les adresses des pages : si elles changent, les anciens liens (ceux qui figurent sur d’autres sites, dans vos courriels, vos documents) risquent de mener à une page d’erreur.
• Les données : clients, commandes, abonnés, historique, dans les formats où elles peuvent être sorties.
• Les accès et les comptes : nom de domaine, hébergement, outils de mesure, messagerie.
• Les engagements en cours : contrat d’hébergement, licences, abonnements.

L’aide de Shopify sur la migration illustre la logique de cet inventaire. Elle invite à examiner la boutique existante et à décider quelles données et quels contenus transférer : produits, clients, commandes historiques, blogs, pages. Elle explique aussi que la structure des liens de la nouvelle plateforme est probablement différente de celle de l’ancienne, ce qui peut faire tomber d’anciens liens sur des pages d’erreur, et propose de préparer des redirections avant de transférer le domaine. Cette documentation concerne un seul cas, la migration vers Shopify : elle ne prouve pas qu’une règle identique s’applique à votre projet, mais elle montre le type de questions à poser quel que soit l’outil.

Autre enseignement de la même page : choisir la méthode de transfert dépend de la quantité et de la complexité des données. Quelques pages se recopient ; un catalogue important s’importe par fichier ou par outil de migration. Demandez au prestataire de dire, pour chaque type de contenu, comment il sera repris.

Le tableau suivant sert de grille corriger / refondre / conserver à remplir ligne par ligne.

Écrire les conditions d'une refonte justifiée

Une refonte est justifiée quand les problèmes nommés au premier temps ne se règlent pas par des corrections, et que l’inventaire du deuxième temps montre que ce qu’on perdrait ou ce qu’on devrait refaire est acceptable. Trois conditions, à écrire avant de commander quoi que ce soit.

1. Le critère de décision. Une phrase qui dit pourquoi les corrections ne suffisent pas : « l’outil de gestion ne peut plus être mis à jour et ne permet pas la fonction X », par exemple. Si vous ne pouvez écrire qu’un goût (« je veux autre chose »), la refonte est un choix de présentation ; elle peut rester légitime, mais ce n’est plus une nécessité.

2. Le périmètre de la première version. France Num recommande d’écrire un cahier des charges à partir des besoins identifiés, sept parties selon le JCM, que la page cite : contexte, objectifs, structure et fonctionnalités, technologie et outils tiers, grille d’évaluation, livrables et calendrier, budget. La même page précise qu’un document de cinq à dix pages bien structurées suffit largement à cadrer un projet de site vitrine ou d’e-commerce simple. Pour une refonte, ajoutez à ce plan l’inventaire du paragraphe précédent : c’est lui qui distingue une refonte d’une création.

3. L’accessibilité dans le projet dès le départ. Le W3C recommande d’intégrer l’accessibilité tout au long d’un projet et le décrit comme un sujet de gestion de projet, au même titre que d’autres exigences, avec des rôles et des responsabilités définis. Il met aussi en garde contre le fait de traiter l’accessibilité comme une simple liste de contrôle, au risque d’oublier l’expérience réelle des utilisateurs. Une refonte est le moment de l’inscrire au cahier des charges plutôt que de la corriger après coup.

Avant de signer, demandez au prestataire :

• ce qui sera repris de l’existant, ligne par ligne, et ce qui sera recréé ;
• comment les anciennes adresses seront traitées, et comment cela sera vérifié après la mise en ligne ;
• quels accès et quels fichiers vous seront remis ;
• ce qui est inclus dans le prix en cas d’écart entre l’inventaire et la réalité : ce qui est facturé en plus passe par un avenant, c’est-à-dire un document qui modifie le contrat.

Pour mettre ces réponses en forme, vous pouvez préparer le projet dans l’atelier.