Faut-il réellement refondre le site ?
Un site vieillissant n'a pas toujours besoin d'être entièrement remplacé. Une refonte devient pertinente lorsque plusieurs problèmes se cumulent : administration difficile, structure de contenu devenue incohérente, parcours utilisateurs inefficaces, dette technique importante, intégrations fragiles, problèmes d'accessibilité ou impossibilité de faire évoluer le site sans risque.
À l'inverse, si le socle reste sain et que le problème concerne surtout quelques pages, le référencement, la performance ou un parcours précis, une amélioration ciblée peut être plus rapide, moins risquée et plus rentable qu'une reconstruction complète. Un audit Drupal ou un audit plus large de l'existant permet souvent de trancher avant d'engager une reconstruction.
Avant de choisir un CMS, un framework ou une nouvelle identité graphique, il faut donc commencer par établir ce qui fonctionne, ce qui doit être conservé et ce qui empêche réellement le site d'évoluer.
Checklist avant de démarrer
1. Clarifier les objectifs métier
Listez les actions que le site doit réellement soutenir : demandes de contact, inscriptions, prises de rendez-vous, ventes, candidatures, téléchargements ou accès à une information importante. Une refonte sans objectif mesurable risque de déplacer les problèmes plutôt que de les résoudre.
2. Inventorier les contenus existants
Identifiez les pages à conserver, fusionner, réécrire ou supprimer. Repérez également les documents, médias, formulaires et contenus multilingues. Cet inventaire évite de découvrir trop tard qu'une information importante n'a pas été prévue dans la nouvelle structure.
3. Identifier les pages qui apportent déjà du trafic
Une page ancienne peut sembler peu attractive tout en étant bien positionnée dans les moteurs de recherche. Avant de modifier les URLs ou de supprimer du contenu, relevez les pages qui reçoivent des impressions, des clics ou des liens entrants. La refonte doit préserver ce capital lorsque le contenu reste pertinent.
4. Préparer les URLs et les redirections
Construisez une correspondance entre les anciennes et les nouvelles URLs. Toute URL utile supprimée ou déplacée doit avoir une destination logique. Une série de redirections improvisée au moment de la mise en ligne est une source classique de pertes SEO et d'erreurs 404.
5. Recenser les formulaires et parcours critiques
Contact, demande de devis, inscription, candidature, recherche ou espace privé : chaque parcours important doit être identifié et testé. Notez les champs indispensables, les notifications, les destinataires, les consentements et les éventuelles intégrations externes.
6. Cartographier les intégrations et API
CRM, ERP, newsletter, paiement, authentification, analytics, outils métier ou services tiers peuvent être invisibles dans la maquette mais essentiels au fonctionnement du site. Documentez les flux, responsabilités et dépendances avant de modifier l'architecture.
7. Revoir les comptes, rôles et workflows éditoriaux
Qui peut créer, relire, traduire et publier ? Une refonte est l'occasion de simplifier les permissions et les processus éditoriaux. Elle ne doit pas remplacer un système connu par une administration plus complexe pour les personnes qui publient au quotidien.
8. Traiter le multilingue comme une architecture
Les langues ne se limitent pas à traduire les textes. Il faut préserver la correspondance entre versions, les URLs, les liens de changement de langue, les métadonnées et les hreflang. Il faut aussi décider quels contenus doivent réellement exister dans chaque langue.
9. Intégrer l'accessibilité dès le cadrage
Contrastes, navigation au clavier, structure des titres, textes alternatifs, formulaires et composants interactifs doivent être pris en compte avant la phase de finition. Corriger l'accessibilité après avoir figé le design et les composants coûte généralement plus d'effort que l'intégrer dès leur conception. Une démarche d'accessibilité, SEO et optimisation est plus efficace lorsqu'elle commence dès le cadrage.
10. Mesurer la performance et les Core Web Vitals lorsque c'est pertinent
Avant la refonte, mesurez l'état de départ : poids des pages, images, scripts tiers, temps de chargement et métriques réelles disponibles. Cela permet de distinguer les problèmes de contenu, de thème, d'hébergement et de services externes, puis de vérifier objectivement si la nouvelle version progresse.
11. Examiner sécurité, maintenance et dette technique
Listez les versions, modules ou extensions, développements spécifiques, dépendances abandonnées et opérations de maintenance récurrentes. Une refonte visuelle qui conserve un socle difficile à maintenir ne règle qu'une partie du problème.
12. Préparer la mesure après mise en ligne
Décidez avant le lancement ce que vous contrôlerez ensuite : erreurs 404, indexation, formulaires, conversions, performances, logs et comportement des principales pages. La mise en ligne n'est pas la fin de la refonte ; c'est le début de sa vérification en conditions réelles.
Ce qu'un audit préalable doit produire
Un audit utile ne devrait pas se limiter à une longue liste de défauts. Il doit permettre de décider.
- Inventaire de l'existant
- Savoir ce qui doit être conservé, migré ou supprimé.
- Risques prioritaires
- Identifier ce qui peut affecter SEO, données, sécurité ou continuité métier.
- Quick wins
- Corriger ce qui ne nécessite pas forcément une refonte complète.
- Backlog priorisé
- Transformer les constats en actions ordonnées.
- Périmètre cible
- Distinguer indispensable, souhaitable et amélioration ultérieure.
- Plan de validation
- Définir comment vérifier contenu, parcours, SEO et rendu avant et après lancement.
Drupal, framework ou autre : choisir après le besoin
Le choix technologique vient après l'analyse. Drupal peut être particulièrement pertinent lorsque le projet repose sur des contenus structurés, plusieurs langues, des rôles éditoriaux et des workflows de validation. Une application métier très spécifique peut au contraire justifier un socle Symfony ou Laravel. Dans d'autres cas, conserver et améliorer l'existant reste la meilleure décision.
Le bon critère n'est donc pas « quelle technologie est la meilleure ? », mais « quelle architecture répond au besoin avec un niveau de complexité, de gouvernance et de maintenance acceptable ? ». Nos services couvrent aussi bien le cadrage que la modernisation progressive.
Préparer la mise en ligne sans casser le SEO
Avant le basculement, vérifiez au minimum les redirections, les URLs canoniques, les versions linguistiques et hreflang, le sitemap, les métadonnées essentielles et les pages qui génèrent déjà du trafic. Après le lancement, surveillez les erreurs 404, l'indexation et les parcours de conversion plutôt que d'attendre une baisse de visibilité pour intervenir.
Quand ne pas faire une refonte complète
Une refonte n'est pas nécessaire si le socle technique reste maintenable et que quelques changements ciblés peuvent résoudre le problème : amélioration d'un parcours, correction SEO, optimisation des performances, mise à jour du design system ou simplification de l'administration.
Dans ce cas, un audit suivi d'un backlog d'améliorations peut éviter un projet plus long et plus risqué sans bénéfice proportionnel. Si la reconstruction est réellement justifiée, notre approche de refonte de site Drupal part précisément de ce cadrage.
Passer du diagnostic au plan d'action
Vous hésitez entre amélioration ciblée et refonte complète ? Nous pouvons commencer par un audit de l'existant et transformer les constats en backlog priorisé avant de choisir la technologie ou le périmètre de reconstruction. Parlez-nous de votre projet.