Refonte ou migration : décider à partir des contraintes du site

Refonte ou migration : quelle décision cherchez-vous à prendre ?

Une refonte transforme le site : son discours, ses contenus, son arborescence, ses parcours ou son interface. Une migration change son environnement technique, par exemple son CMS ou son hébergement. Un même projet peut comprendre les deux. Pour choisir, partez du problème à résoudre et de la cause vérifiée, avant de sélectionner une plateforme.

Un site difficile à administrer n’exige pas toujours une migration. Un formulaire défaillant ne justifie pas à lui seul une refonte complète. À l’inverse, conserver le CMS peut coûter trop d’efforts si une fonction indispensable ne peut plus être maintenue. La bonne décision décrit ce qu’il faut changer, ce qui peut rester et la manière de vérifier que le nouveau périmètre répond au besoin.

Les trois questions qui séparent les chantiers

Examinez séparément le parcours du visiteur, les opérations de l’équipe et les contraintes techniques. Une même difficulté apparente peut venir de causes différentes ; chacune appelle une vérification avant de choisir le chantier.

Le problème concerne-t-il ce que le visiteur comprend ou accomplit ?

Si les offres sont difficiles à distinguer, si une audience ne trouve pas son entrée ou si les preuves arrivent trop tard dans le parcours, le travail porte d’abord sur les contenus et l’expérience. Il peut s’agir d’une correction de quelques pages, d’une nouvelle navigation ou d’une refonte plus large. Le changement de CMS ne résout pas, à lui seul, ces problèmes.

Rassemblez une preuve précise : la page concernée, la tâche attendue et l’endroit où la compréhension se rompt. Un entretien, une demande commerciale ou une observation de parcours peut aider à formuler le problème. Évitez de transformer un avis sur l’apparence en diagnostic de toutes les pages.

Le problème concerne-t-il une opération que l’équipe doit pouvoir réaliser ?

Décrivez l’opération plutôt que le seul mécontentement : publier un cas client, modifier une offre sans casser sa mise en page, réutiliser un composant ou reprendre des contenus structurés. Vérifiez ensuite ce qui bloque : modèle CMS, organisation des champs, droits, documentation, dépendance à une extension ou limite de la plateforme.

Si une correction du modèle ou de la gouvernance suffit, une migration ajoute un chantier sans résoudre un besoin supplémentaire. Si la contrainte demeure après cet examen, la comparaison des plateformes doit reproduire l’opération attendue sur un exemple représentatif. Une démonstration générique ne prouve pas que votre équipe pourra administrer ses propres contenus.

Une contrainte technique impose-t-elle réellement un changement d’environnement ?

Identifiez la fonction indispensable, les conditions de son maintien et la responsabilité de son exploitation. Une difficulté de maintenance peut venir de l’empilement des dépendances ou d’un périmètre mal documenté. Distinguez ces causes d’une incompatibilité durable avec le CMS.

Une migration devient défendable lorsque l’environnement cible répond mieux à une contrainte explicite et vérifiable. Documentez aussi ce qu’il faudra reconstruire : formulaires, recherche, modèles de pages, intégrations ou règles de publication. Le passage à un nouvel outil ne rend pas ces fonctions équivalentes automatiquement.

Choisir entre correction ciblée, refonte, migration et projet combiné

Correction ciblée. Le besoin reste localisé et la base est exploitable. Exemple de décision : revoir une page de prestation et son appel à l’action sans toucher au CMS ni aux autres pages. La réception porte sur ce parcours précis.

Refonte dans le CMS actuel. Le contenu, la structure ou l’interface doivent être repris, tandis que la plateforme permet encore de publier et maintenir le site. Le périmètre doit nommer les pages, les gabarits et les éléments conservés.

Migration à périmètre éditorial stable. Les messages et parcours restent adaptés, mais l’environnement doit changer. Le projet consiste à reprendre les contenus et les fonctions en contrôlant leur correspondance. Une interface visuellement proche peut masquer une reprise technique importante.

Refonte avec migration. L’offre ou les parcours doivent évoluer et le changement technique est justifié séparément. Les deux décisions partagent un inventaire, mais leurs livrables restent identifiables. Il faut pouvoir expliquer pourquoi chaque transformation est nécessaire.

Ces situations sont des repères de décision, pas des cas clients ni des recettes universelles. Si les preuves ne permettent pas de départager deux options, commencez par le contrôle qui peut changer le choix. Un audit ciblé peut être plus utile qu’un engagement immédiat sur une reconstruction complète.

Un exemple réel de refonte sans changement de CMS : Lettria

Le projet Lettria présenté par Gemme Studio décrit un site déjà construit sur Webflow, avec plusieurs offres techniques et des contenus à préserver. Le travail a croisé analytics, SEO et analyse des parcours avant de reprendre le sitemap, la navigation et la direction visuelle.

La mission documentée comprend notamment la homepage et les pages GraphRAG, Perseus et Pricing, ainsi que des composants réutilisables et l’intégration Webflow. Ce périmètre illustre une transformation du site dans son environnement existant : le besoin de refonte ne constituait pas, en lui-même, une raison de changer de CMS.

Le cas public décrit le travail et ses livrables. Il ne fournit pas de comparaison chiffrée permettant d’attribuer une évolution de trafic ou de conversion à la refonte. Il aide à examiner une démarche, sans promettre un résultat identique sur un autre site.

La fiche de décision à remplir avant le devis

Préparez une fiche courte que le responsable du site et le prestataire pourront relire ensemble. Pour chacun des sept points suivants, une information inconnue reste à confirmer : elle ne devient ni une exigence ni une preuve par défaut.

1 — Problème et tâche. Écrivez ce qui échoue ou prend trop de temps, pour quel visiteur ou contributeur, sur quelles pages. Associez le constat à une observation datée.

2 — Cause vérifiée. Distinguez problème de message, de structure, de fonctionnement ou d’environnement. Notez ce qui a été contrôlé et ce qui reste une hypothèse.

3 — Éléments à conserver. Recensez les contenus utiles, URL, composants et fonctions qui doivent continuer à servir le site. Un faible trafic observé ne suffit pas à décider qu’une page est inutile.

4 — Changement nécessaire. Décrivez les pages à reprendre, les gabarits à construire et les fonctions à transférer. Justifiez séparément un éventuel changement de CMS.

5 — Répartition des responsabilités. Indiquez qui fournit les informations métier, rédige, conçoit, intègre, valide et administre après livraison. Un contenu « fourni par le client » n’est pas un contenu rédigé par le prestataire.

6 — Preuve de réception. Associez chaque livrable à une vérification : contenu complet, fonctionnement d’un parcours, publication représentative dans le CMS ou continuité d’une URL. Précisez qui accepte le résultat et comment un écart sera traité.

7 — Conditions de lancement et de suivi. Nommez les prérequis, les validations attendues et les contrôles après publication. Conservez la date effective de chaque version pour la rapprocher des mesures disponibles.

Formulation à reprendre : « Nous devons permettre à ___ de réaliser ___. Le blocage observé est ___, sa cause vérifiée est ___. Nous conservons ___ et modifions ___. La réception sera fondée sur ___, sous la responsabilité de ___. La décision encore ouverte est ___. »

Ce qu’un devis doit permettre de comparer

Vérifiez si les deux propositions parlent du même nombre de pages et de gabarits, des mêmes contenus et du même travail de reprise. Un devis peut inclure le modèle CMS sans inclure l’intégration des contenus. Un autre peut prévoir la migration des pages mais laisser les formulaires et les connexions au CRM à votre charge.

Le guide du prix d’une refonte propose une grille de comparaison des périmètres. Utilisez-la après avoir arrêté votre décision de chantier ; un prix inférieur n’arbitre pas à lui seul entre deux solutions qui ne couvrent pas le même besoin.

Pour les URL, précisez si leur conservation est possible et qui prépare puis contrôle les éventuelles correspondances. Ne changez pas leur structure uniquement pour accompagner un nouvel aspect visuel. Toute modification doit répondre à une décision propre au projet.

Quel guide utiliser après la décision ?

Pour organiser les étapes, responsabilités et validations, poursuivez avec la méthode de refonte en dix étapes. Pour préparer un changement d’environnement, consultez les erreurs de migration à éviter. Le guide WordPress vers Webflow traite ce transfert particulier.

Si le doute porte encore sur la nécessité de refaire le site, commencez par l’audit avant refonte. Ces ressources répondent à des étapes différentes : décider, préparer, exécuter puis contrôler. Les lire ne remplace pas la validation du périmètre de votre propre site.

Préparer un cadrage avec Gemme Studio

Partagez votre site actuel, la tâche qui pose problème, les contenus et fonctions à conserver et vos contraintes de calendrier. Indiquez si le changement de CMS est déjà imposé ou s’il reste à justifier. Ces éléments permettent de discuter d’une intervention ciblée, d’une refonte ou d’un projet combiné.

Consultez notre offre de refonte Webflow pour connaître le périmètre présenté, puis présentez votre projet. Le cadrage doit aboutir à un choix explicite et contrôlable avant d’engager la production.