Refonte de site : reprendre l’existant ou repartir de zéro ?

Demandez à un prestataire s'il faut reprendre l'existant ou repartir de zéro, et la réponse penchera souvent vers la reconstruction. Ce n'est pas nécessairement de la mauvaise foi : reprendre le travail d'un autre est ingrat, mal payé et risqué. Mais ce n'est pas votre problème.

Deux questions suffisent à situer votre site, et elles sont techniques toutes les deux. Le design, le contenu et l'ergonomie n'entrent pas dans cette décision-là : ils relèvent d'une refonte éditoriale, qui se mène aussi bien sur un socle existant que sur un neuf.

Question 1 — le socle reçoit-il encore des mises à jour de sécurité ?

Tout site repose sur des briques logicielles — un moteur de publication, un langage, des bibliothèques. Chacune a une durée de vie annoncée, au-delà de laquelle plus aucun correctif n'est publié, y compris pour les failles connues.

Si votre socle a dépassé cette date, la question est tranchée : ce n'est plus une question de confort mais d'exposition, et le temps joue contre vous. Aucun prestataire sérieux ne construira dessus.

La vérification : demandez par écrit la version du moteur et du langage utilisés, puis comparez avec les dates de fin de support publiées par leurs éditeurs. C'est une information publique, gratuite, et qui ne demande aucune compétence pour être lue.

Question 2 — possédez-vous le code et les accès ?

Si le code source est introuvable, si personne ne sait comment le site est déployé, ou si les accès sont détenus par un prestataire injoignable, alors « reprendre » ne veut rien dire : il n'y a rien à reprendre. On peut réinstaller ce qui tourne, pas le faire évoluer.

Attention à un cas fréquent : le site fonctionne, il est en ligne, il semble donc exister. Mais tout ce dont on dispose est la version installée sur le serveur. Sans le code source ni la procédure d'installation, la moindre modification devient une opération de reprise en main.

Quand reprendre suffit

Si les deux réponses sont bonnes — socle maintenu, code possédé —, la reprise est presque toujours le meilleur choix, et pour trois raisons.

• Le référencement acquis reste en place. C'est l'actif le plus fragile d'une refonte, et le plus long à reconstituer.
• Le contenu ne se remigre pas. La reprise évite l'opération la plus fastidieuse et la plus génératrice d'erreurs.
• Le risque est étalé. On change une partie, on vérifie, on continue — au lieu de tout basculer une nuit.

Un design daté n'est pas un motif de reconstruction. Refaire l'apparence, la structure des pages et les textes sur un socle sain est un travail réel, mais qui ne touche pas aux fondations. C'est souvent ce dont il s'agit quand quelqu'un dit « il faut refaire le site ».

Quand il faut repartir

Trois situations, et elles se recoupent souvent.

Le socle n'est plus maintenu. Traité plus haut : c'est le cas qui ne se discute pas.

Le code est perdu ou inexploitable. Y compris lorsqu'il existe mais que personne ne peut le faire tourner en local, faute de documentation.

La technologie n'a plus de mainteneurs disponibles. Un site écrit dans un langage ou un cadriciel que plus personne ne pratique dans votre région vous laisse à la merci d'un fournisseur unique. Le logiciel fonctionne ; c'est l'écosystème autour qui a disparu.

Une quatrième situation, plus rare, mérite d'être nommée : quand le besoin lui-même a changé de nature. Un site vitrine devenu plateforme de commande n'est pas une évolution du même produit, et le forcer coûte plus cher que de le reconstruire.

Ne pas perdre son référencement — la partie qui se néglige

C'est le poste le plus souvent absent des devis, et celui dont l'oubli se paie le plus longtemps. Une refonte change des adresses ; chaque adresse qui disparaît sans instruction emporte avec elle les positions acquises et les liens qui pointaient vers elle.

1. Inventorier les adresses existantes

Avant tout développement. Récupérez la liste complète des pages actuelles — depuis le plan du site, depuis vos statistiques, depuis les outils pour webmestres du moteur de recherche. Repérez celles qui reçoivent des visites et celles vers lesquelles d'autres sites pointent : ce sont elles qu'il faut protéger, pas les cinq cents pages jamais consultées.

2. Établir le tableau des redirections

Une ligne par ancienne adresse, en face la nouvelle. Une redirection permanente — le code 301 — indique au moteur que le déplacement est définitif et lui demande de transférer ce qui avait été acquis. Une redirection temporaire ne le fait pas.

Deux erreurs classiques : renvoyer toutes les anciennes adresses vers la page d'accueil, ce qui équivaut à les supprimer du point de vue du moteur ; et enchaîner les redirections en cascade lors de refontes successives, chaque saut diluant un peu plus le résultat.

3. Publier le nouveau plan du site

Et le déclarer dans les outils pour webmestres, pour que la nouvelle structure soit parcourue rapidement plutôt qu'au rythme habituel.

4. Surveiller pendant six à huit semaines

Les erreurs 404 apparaissent d'abord, les mouvements de position ensuite. Une baisse pendant les premières semaines est normale — le moteur réévalue. Une baisse qui persiste au-delà de deux mois signale une redirection manquante, et il est encore temps de la poser.

Personne ne peut promettre qu'aucun trafic ne sera perdu lors d'une refonte. On peut en revanche promettre que chaque adresse qui recevait des visites aura une destination — et c'est ce qui doit figurer au devis.

Ce qu'on emporte, et ce qu'on laisse

Le tri se fait avant la migration, jamais après. Migrer d'abord et nettoyer ensuite revient à ne jamais nettoyer, et à traîner pendant des années des pages que personne ne lit.

Passez en revue le contenu par utilité constatée : les pages qui reçoivent des visites, celles qui répondent à une question réelle, celles qui sont obsolètes. Les images méritent le même traitement — c'est le moment de les redimensionner une fois pour toutes. Les comptes utilisateurs et l'historique des commandes se migrent presque toujours ; les données personnelles dont vous n'avez plus l'usage, non : une refonte est une bonne occasion d'appliquer vos propres durées de conservation.

Le calendrier réaliste

La partie sous-estimée n'est pas le développement, c'est la vérification après bascule : parcourir les pages, tester les formulaires, contrôler les redirections une par une sur les adresses qui comptent, vérifier que les courriels partent toujours. Comptez une à deux semaines de vigilance active après la mise en ligne, avec quelqu'un de disponible pour corriger.

Évitez de basculer un vendredi, et évitez la veille d'une période commerciale forte. Ce sont des évidences que l'on rappelle parce qu'elles sont régulièrement ignorées sous la pression du calendrier.

Nos pages Développement Web & Mobile et DevOps & Cloud couvrent la reconstruction et la bascule. Si votre question est simplement « faut-il repartir de zéro ? », les deux vérifications du début y répondent sans nous.