Refonte site web : rédiger un brief qui protège SEO, conversion et mesure
Une refonte de site web mérite un brief qui tranche avant les maquettes : pages et parcours à préserver, information à clarifier, actions à mesurer et conditions d’une publication française, arabe et anglaise réellement utile. Le résultat attendu n’est pas seulement une nouvelle interface, mais des critères vérifiables pour le SEO, la conversion, le tracking et le contenu localisé.
La requête « refonte site web » est associée à un volume de 10 et à une intention commerciale/informationnelle dans le plan fourni : Ahrefs Morocco estimate, 22 October 2026. Cette estimation signale une demande de recherche ; elle ne prédit ni trafic, ni position, ni demande, ni revenu.
Partir du problème métier, pas de la maquette
Un brief n’est pas une collection de couleurs et de sites inspirants. Il explique la décision que le site doit mieux soutenir. Sans ce cadre, une interface plus récente peut rendre une offre moins claire, déplacer une page utile, casser un formulaire ou publier une traduction incomplète.
Écrivez une ou deux fonctions prioritaires : expliquer un service, aider un prospect à évaluer l’adéquation, obtenir une prise de contact ou partager une preuve. Précisez publics, offres, langues, validations et étape attendue.
Ce qu’un brief de refonte doit contenir
Un brief peut rester court s’il désigne les décisions, les responsables et les preuves attendues.
| Élément | Question à résoudre | Livrable ou preuve |
|---|---|---|
| Objectif et publics | Quel parcours doit devenir plus utile ? | Priorités, intervenants et critères d’acceptation |
| Inventaire | Que faut-il conserver, fusionner, retirer ou créer ? | URL, contenu, médias, formulaires et dépendances |
| Architecture | Comment atteindre l’offre et la prochaine étape ? | Navigation, liens internes et parcours mobile |
| Migration | Que devient chaque adresse significative ? | Table URL ancienne → destination, redirections et tests |
| Langues | Quelle information est utile dans chaque version ? | Plan localisé, relecture et état de publication |
| Mesure | Quelle action informe une décision ? | Plan de marquage, test et déduplication |
| Réception | Comment vérifier la livraison ? | Cas de test, responsable et date de validation |
Protéger le SEO pendant une nouvelle architecture
Une refonte sans changement d’URL demande encore de contrôler les liens internes, les canoniques, les directives noindex, le rendu mobile et les erreurs. Si les adresses changent, le brief doit traiter le projet comme une migration.
Cartographier avant de développer
Exportez les URL depuis le CMS, le sitemap, les outils de recherche et les données analytics. Pour chaque page qui compte, choisissez la destination la plus pertinente. Une ancienne page de service doit conduire vers l’équivalent ou vers une page consolidée qui répond réellement au même besoin. Envoyer de nombreuses pages retirées vers l’accueil n’est pas un remplacement utile d’une décision de correspondance.
Google recommande, lorsque c’est techniquement possible, les redirections permanentes côté serveur, notamment 301 ou 308. Son guide de migration avec changement d’URL recommande aussi d’éviter les chaînes, d’actualiser liens internes, canoniques et sitemap, puis de tester et surveiller les erreurs. La table de correspondance devient donc une spécification technique et une liste de réception.
Définir les contrôles de lancement
En préproduction, testez un échantillon prioritaire d’anciennes URL : code HTTP, destination finale, canonique, contenu principal, navigation et formulaire. Après publication, soumettez le sitemap des nouvelles URL si nécessaire et observez les erreurs. Google indique qu’une migration peut entraîner des fluctuations temporaires ; il ne s’agit pas d’un résultat à promettre.
Une démarche SEO au Maroc peut structurer ces contrôles, sans remplacer l’approbation du propriétaire du site.
Prévoir de vraies versions localisées
Un sélecteur de langue ne constitue pas une localisation. Chaque version doit proposer une offre compréhensible, une navigation lisible, un CTA adapté et une confirmation cohérente. Désignez un responsable éditorial par langue pour vérifier le sens commercial, les termes, les dates et les appels à l’action. Pour l’arabe, prévoyez les contrôles de direction de lecture, typographie, alignement et composants mobiles.
Lorsque les pages sont de véritables équivalents, prévoyez hreflang dans l’architecture. Google précise que chaque version doit déclarer sa propre URL et ses alternatives, avec des liens réciproques. Son guide sur les versions localisées décrit les options HTML, en-têtes HTTP et sitemap. Ne présentez pas des contenus différents comme des alternatives par commodité.
Concevoir la conversion comme un parcours
Sur chaque page prioritaire, décrivez la séquence : problème reconnu, situation visée, périmètre ou méthode, preuve disponible, objection probable, action proposée et suite attendue. Ne comblez jamais un manque de preuve par des logos, témoignages, résultats ou certifications inventés. Une méthode documentée, une démonstration de livrable ou une étude de cas autorisée peuvent être utiles ; si la preuve manque, prévoyez sa production.
Les critères de réception sont observables : sur mobile et ordinateur, un visiteur peut-il identifier l’offre, comprendre le CTA, remplir les champs nécessaires et recevoir une confirmation intelligible ? Un formulaire court n’est pas nécessairement meilleur : chaque champ doit avoir un rôle de qualification ou de suivi. Une expérience dédiée peut relever de la création de landing pages, tandis que l’ordre du contenu et les priorités de canaux peuvent nécessiter une stratégie digitale.
Préserver le tracking et valider les actions utiles
Une refonte change souvent composants, sélecteurs, formulaires, pages de confirmation et scripts tiers. Créez le plan de mesure avant de reconstruire l’interface. Pour chaque action, notez le nom d’événement, la condition de déclenchement, les paramètres, les pages, le système qui détient la donnée, le responsable métier, la règle de déduplication et la décision associée.
Ne mesurez pas une interaction parce qu’elle est facile à capter. Testez erreurs de champ, abandons, doubles clics et refus de consentement afin de ne pas les compter comme des réussites. DebugView de Google Analytics permet d’observer les événements en mode débogage ; sa documentation rappelle que consentement et contrôles de confidentialité peuvent modifier ce qui apparaît. Tracking & Analytics peut relier les règles techniques aux définitions métier.
Inclure performance et accessibilité dans la réception
Une nouvelle interface peut ajouter des images lourdes, polices, animations ou scripts. Utilisez des tests de laboratoire avant lancement et les données terrain lorsqu’elles existent. Les Core Web Vitals actuels couvrent chargement, réactivité et stabilité visuelle : LCP, INP et CLS. Le guide Web Vitals donne comme repères 2,5 secondes, 200 millisecondes et 0,1 au 75e percentile, tout en précisant que les tests de laboratoire ne remplacent pas les mesures réelles. Ce sont des contrôles, pas l’assurance d’une expérience identique pour chaque visite.
Testez aussi clavier, ordre des titres, contrastes, libellés et erreurs de formulaire, alternatives textuelles, focus visible et lecture mobile. Le W3C organise WCAG 2.2 autour des principes perceptible, utilisable, compréhensible et robuste. Consultez l’aperçu WCAG du W3C et prévoyez une revue humaine : un outil seul ne détermine pas la conformité.
Choisir ce qui entre dans cette version
Priorisez chaque demande selon son effet sur le parcours, le risque si elle est oubliée, ses dépendances, l’effort de validation et sa réversibilité. Les redirections, formulaires critiques, accès aux données, consentement et contenu approuvé doivent être décidés avant la bascule. Une animation ou une section non validée peut attendre.
FAQ — Brief de refonte de site web
Faut-il modifier toutes les URL pendant une refonte ?
Non. Conserver une URL pertinente réduit le travail de migration. Lorsqu’une nouvelle adresse améliore réellement l’architecture, documentez une destination adaptée, utilisez une redirection permanente côté serveur si possible, évitez les chaînes et testez le résultat.
Qui doit valider le brief ?
Le sponsor métier fixe les priorités. Marketing et commercial valident l’offre, le contenu et les actions ; l’équipe technique confirme l’architecture, les redirections et les intégrations. Attribuez aussi une responsabilité par langue et pour la mesure.
Peut-on lancer avant que toutes les traductions soient terminées ?
Oui, si le périmètre publié est cohérent et ne présente pas les pages inachevées comme disponibles. Identifiez les véritables équivalents et mettez à jour les annotations de langue de façon réciproque lorsqu’ils existent.
Comment vérifier que le tracking a survécu ?
Exécutez les parcours prioritaires en test puis après lancement : formulaire, rappel, prise de rendez-vous ou téléchargement. Comparez événement, paramètres et confirmation avec le plan de mesure, puis recherchez les déclenchements répétés ou inattendus.