Comment rédiger un cahier des charges pour un projet de refonte de site web étape par étape

Quand un cahier des charges de refonte est le bon document

Un cahier des charges de refonte n'est pas un formulaire d'admission général. Il existe pour un site qui fonctionne déjà d'une certaine manière et échoue d'une autre, et le cahier doit décrire le changement, pas seulement le désir. Si l'équipe répare un site web d'entreprise de 40 pages, une page d'atterrissage ou un portail produit, le cahier doit indiquer ce qui doit changer et ce qui doit rester en place.

Cela compte parce que le travail de refonte commence avec une réalité héritée. Il y a déjà un plan du site, un ancien contenu, un code de suivi, des formulaires et un CMS avec des habitudes intégrées. Un bon cahier indique à un designer ou à une agence où se situe la douleur, quelles parties sont stables et quelles parties sont dangereuses à toucher sans un plan.

Considérez-le comme un document de gestion du changement. Cela peut sembler sec, mais cela garde tout le monde honnête. Un freelance peut mieux évaluer le travail, une équipe interne peut éviter de deviner, et le côté client peut cesser de traiter chaque ancienne page comme une toile vierge.

Si vous cherchez comment rédiger un brief de site web pour un projet de refonte étape par étape, commencez par décider que le brief est pour une transformation, et non pour une découverte à partir de zéro. Cette décision change les questions que vous posez et les détails que vous collectez.

Auditez le site actuel avant d'écrire quoi que ce soit

Commencez par le site en direct. Pas des captures d'écran du dernier trimestre. Pas un souvenir du « problème de la page d'accueil ». Ouvrez les pages actuelles et dressez la liste de ce qui existe, de ce qui est cassé et de ce que personne ne devrait oublier lors de la refonte.

Faites un audit simple avec des chiffres. Comptez les pages qui resteront, les pages qui changeront et les pages qui seront supprimées. Notez toute page avec un fort trafic, tout formulaire avec des abandons, toute section qui confond les utilisateurs et tout contenu qui est obsolète depuis un an ou plus.

Les contraintes techniques appartiennent aussi ici. Si le site actuel dépend d'un CMS hérité, d'un flux de paiement personnalisé ou d'une intégration fragile, le brief devrait le mentionner avant que quiconque ne dessine une nouvelle mise en page. Une refonte qui ignore le système actuel crée souvent un deuxième projet : le contrôle des dommages.

Incluez des problèmes concrets des utilisateurs. Par exemple : les tickets de support mentionnent des problèmes de recherche sur mobile ; les ventes disent que la page de tarification provoque des appels répétés ; l'équipe éditoriale ne peut pas mettre à jour les FAQ sans l'aide d'un développeur. Ces détails sont meilleurs que des affirmations générales comme « le site est difficile à utiliser ».

Si vous avez déjà une documentation interne, liez-la. Une équipe qui gère un la sécurité des sites webLes briefs de refonte échouent lorsque le périmètre reste flou. Écrivez ce qui est dans le périmètre en termes simples, puis écrivez ce qui ne l'est pas. La deuxième liste est tout aussi importante que la première, car elle empêche l'équipe de dériver vers des modèles supplémentaires, des fonctionnalités supplémentaires et des boucles d'approbation supplémentaires.

Définissez les limites de la refonte et les non-objectifs

Soyez spécifique sur les limites. Si la page d'accueil, les pages produits et le flux de contact sont inclus, dites-le. Si l'archive du blog, les versions linguistiques ou la zone de compte ne font pas partie de cette phase, dites-le aussi. Une refonte peut toucher 12 modèles sans toucher à l'ensemble du système.

Les non-objectifs ne sont pas un signe de paresse. Ce sont une protection. Si le nettoyage du contenu SEO est hors du périmètre, dites-le. Si la nouvelle photographie n'est pas incluse, dites-le. Si la refonte doit conserver le même fournisseur de paiement, écrivez-le clairement pour que personne ne propose un remplacement au cours de la semaine 3.

Une ligne utile dans un brief de refonte est : « Gardez le flux de paiement actuel intact. » Une autre est : « Ne changez pas le tableau de bord client dans cette phase. » Simple. Direct. Difficile à mal interpréter.

Le brief de refonte a besoin de contexte, mais pas d'un manifeste de marque. Résumez la raison commerciale en un court bloc : objectifs de revenus, qualité des prospects, charge de support, besoins en recrutement ou lancement sur un nouveau marché. Si la refonte soutient une fusion, un rebranding ou un passage de B2B à B2B2C, nommez-le.

Capturez le contexte commercial, de marque et utilisateur

Le cahier des charges de la refonte a besoin de contexte, mais pas d'un manifeste de marque. Résumez la raison commerciale en un court paragraphe : objectifs de revenus, qualité des prospects, charge de support, besoins en recrutement ou lancement sur un nouveau marché. Si la refonte soutient une fusion, un rebranding ou un passage de B2B à B2B2C, mentionnez-le.

Le contexte de la marque doit inclure les éléments qui ont changé. Peut-être que l'entreprise est maintenant plus axée sur les entreprises. Peut-être que le ton est passé de ludique à expert. Peut-être que le système visuel doit sembler plus calme parce que l'ancien design paraissait trop promotionnel. Ce sont des détails utiles. « Moderne » ne l'est pas.

Le contexte utilisateur doit refléter de réels changements, pas des hypothèses. Si le public est devenu plus axé sur le mobile, cela change les modèles et la navigation. Si les clients récurrents ont maintenant besoin d'un accès au compte plus rapidement que les nouveaux visiteurs n'ont besoin d'éducation, la page d'accueil, les menus et le tableau de bord doivent refléter cette hiérarchie.

Une phrase peut faire beaucoup ici : « Le redesign doit soutenir trois publics - nouveaux prospects, clients existants et partenaires - sans faire porter tout le poids à la page d'accueil. » Cela donne à l'équipe un problème de design qu'elle peut résoudre, ce qui est mieux que de leur remettre un slogan.

Pour un projet plus important, il peut être utile de pointer vers un élément connexe site web d'entrepriseexemple de structure ou un site d'unité commerciale existant afin que l'équipe comprenne comment l'organisation se présente déjà.

Spécifiez les besoins au niveau des pages et la structure du site

Un cahier des charges de redesign ne doit pas se limiter à « nouvelle navigation ». Il doit nommer la structure du site, les principaux modèles et les pages qui nécessitent une attention particulière. Commencez par une liste de plan du site, même si elle est approximative. Ensuite, marquez d'abord les pages prioritaires.

Par exemple, un site de 20 pages pourrait avoir besoin d'une nouvelle page d'accueil, de deux modèles de service, d'une mise en page d'étude de cas, d'un hub de ressources et d'une page de contact avec un formulaire différent. Une entreprise de produits peut avoir besoin d'une page de tarification, d'une page de comparaison et d'un flux d'inscription à un essai. Un éditeur peut avoir besoin de filtres d'archives et de modèles d'articles avec des parcours de lecture plus forts.

Dites à l'équipe quels types de pages sont répétables et lesquels sont des exceptions. Si le modèle de blog peut gérer 500 articles mais que le modèle d'étude de cas nécessite une narration personnalisée, écrivez-le. Si la navigation doit faire ressortir uniquement les 6 sections principales, dites-le. Les chiffres aident ici.

C'est aussi l'endroit pour les changements de hiérarchie de contenu. Une page peut garder les mêmes informations mais nécessiter un ordre différent : preuve d'abord, caractéristiques en second, processus en troisième, FAQ en dernier. Ce type d'orientation empêche un redesign de devenir un échange cosmétique avec la même vieille structure en dessous.

Certaines équipes esquissent cela par rapport à un plateforme d'analyse et de surveillance de site web ou une carte de contenu interne afin qu'elles puissent voir quelles pages portent déjà la charge et lesquelles sont sous-utilisées.

Notez la migration de contenu, les approbations et la propriété

La migration de contenu est là où les redesigns deviennent désordonnés. Un cahier des charges doit indiquer quel contenu se déplace tel quel, ce qui doit être réécrit, ce qui doit être archivé et ce qui doit être créé de toutes pièces. S'il y a 86 anciens articles et que seulement 20 doivent migrer, indiquez ce nombre clairement.

La propriété compte tout autant. Qui écrit le nouveau texte ? Qui vérifie le langage légal ? Qui approuve le titre de la page d'accueil ? Si 4 personnes approuvent une page, le calendrier en souffrira. Un cahier des charges doit nommer le propriétaire pour chaque étape, pas seulement pour la validation finale.

Les approbations visuelles nécessitent le même soin. Le responsable marketing peut approuver le ton, le responsable produit peut approuver l'exactitude des fonctionnalités, et le fondateur peut vouloir un dernier regard sur le message de haut niveau. C'est bien, tant que le cahier des charges liste l'ordre. Sinon, le designer finit par réviser la même page trois fois pour trois opinions différentes.

La propriété des actifs est pratique. Indiquez qui fournit des images, des icônes, des diagrammes, des témoignages et des vidéos. Si le redesign dépend de 12 captures d'écran de produits et qu'elles ne sont pas prêtes, c'est un risque pour le calendrier, pas un petit détail.

Listez les exigences techniques, d'accessibilité et d'intégration

Les notes techniques appartiennent au cahier des charges, même si le designer ne code pas tout. Indiquez le CMS, la situation d'hébergement, les outils de formulaire, la configuration des analyses et tous les systèmes auxquels le redesign doit se connecter. Si le site utilise une synchronisation CRM personnalisée ou un outil de facturation, le redesign ne peut pas l'ignorer.

Les exigences en matière d'accessibilité doivent être concrètes. Mentionnez la navigation au clavier, le contraste des couleurs, les étiquettes de formulaire, les états de focus, le sous-titrage et la compatibilité avec les lecteurs d'écran lorsque cela est pertinent. Si l'entreprise a une norme formelle, citez-la. Sinon, demandez à l'équipe de suivre les directives d'accessibilité reconnues et signalez toutes les pages qui pourraient nécessiter une attention particulière.

Le SEO appartient également ici, et pas comme une réflexion après coup. Le brief doit demander la gestion des redirections, la préservation des métadonnées si nécessaire, et un plan pour les pages qui sont renommées ou supprimées. Une mauvaise carte de redirection peut coûter du trafic pendant des semaines.

Si votre équipe a une pile personnalisée ou une configuration privée, indiquez-le. Un redesign pour un infrastructure de réseau privé est très différent d'un site de brochure public, et le brief doit refléter cette contrainte avant que les idées de design ne commencent à se multiplier.

Les exigences de test valent la peine d'être notées. Indiquez si l'équipe doit tester sur 3 navigateurs ou 5, si les points de rupture mobile sont fixes ou flexibles, et si le transfert final nécessite des notes de QA documentées. Ces détails font gagner du temps pendant la semaine de lancement.

Ajoutez des critères de décision et des questions pour les prochaines étapes pour l'équipe

Un brief de redesign ne doit pas se terminer par « veuillez proposer des idées ». Il doit demander à l'équipe de répondre à des questions spécifiques. Quelle approche conceptuelle correspond au problème actuel du site ? Quels risques voient-ils ? Qu'est-ce qui nécessite plus de découverte ? Quelles pages doivent être traitées en premier, et lesquelles peuvent attendre ?

Demandez des estimations sous forme de plages si c'est ainsi que l'équipe fonctionne. Demandez des dépendances. Demandez quelles hypothèses sont les plus importantes. Un brief solide invite l'agence ou le designer interne à répondre avec les pièces manquantes, pas seulement un mood board et un joli PDF.

Cette section peut également définir des critères de décision. Par exemple : privilégier la clarté par rapport à la nouveauté visuelle, ou privilégier la conversion sur la page de contact par rapport à la décoration sur la page d'accueil. Si le brief indique que le redesign ne doit pas ralentir les performances de la page de plus qu'une limite indiquée, l'équipe sait quel compromis est le plus important. Les chiffres gardent la discussion ancrée.

De bonnes questions pour les prochaines étapes incluent : Quels modèles ont besoin de tests de prototype ? Quelles zones de contenu nécessitent un atelier de rédaction ? Qu'est-ce qui peut être réutilisé du système de design actuel ? Où se trouve le plus grand risque de lancement ? Ces questions aident l'équipe à passer du brief au plan sans prétendre que chaque inconnue est résolue.

Certaines équipes demandent également une référence à choisir un CMS si le choix de la plateforme est encore ouvert, car les contraintes de la plateforme peuvent changer la mise en page, le flux d'édition, et même la portée du redesign lui-même.

Et si le brief doit façonner le support de lancement, ajoutez une ligne sur ce qui se passe après la mise en ligne. Un redesign qui change les URL, les formulaires ou les intégrations nécessite souvent le support du site après le lancement pendant quelques semaines, pas un transfert d'un jour.

Avant d'envoyer le brief, lisez-le comme si l'équipe n'avait jamais vu le site. Si un nombre de pages est manquant, si un non-objectif est vague, si un propriétaire d'approbation n'est pas nommé, corrigez-le maintenant. C'est la différence entre un brief de redesign qui motive le travail et un qui ne fait que commencer une réunion.