Cahier des charges d’une refonte de site : les 12 décisions à prendre avant la maquette.

1. Commencer par les objectifs et les publics

Définissez le problème que la refonte doit résoudre : demandes insuffisantes, offre incomprise, site lent, administration fragile, référencement en baisse ou changement de positionnement. Associez chaque objectif à un indicateur observable.

Listez les publics prioritaires, leurs questions et l’action attendue. Un même site peut servir des prospects, clients, candidats ou partenaires ; leurs parcours ne doivent pas se mélanger au hasard.

2. Inventorier l’existant avant de supprimer

Exportez les URL, titres, statuts, trafic, requêtes, liens entrants, conversions et contenus utiles. Pour chaque page, décidez de conserver, améliorer, fusionner, rediriger ou supprimer.

Cette étape protège les acquis SEO et évite de perdre une ressource encore utilisée par des clients. Google recommande une correspondance précise entre anciennes et nouvelles URL lors d’une migration.

3. Décrire les contenus et fonctionnalités

Précisez qui fournit les textes, images, témoignages, documents et validations. Une phrase comme « contenu fourni par le client » ne suffit pas : indiquez le format, la date et la personne responsable.

Décrivez les fonctions par usage : réserver, demander un devis, filtrer, télécharger, payer ou administrer. Ajoutez les règles d’erreur, de confirmation, d’accessibilité et de protection des données.

4. Préparer la migration et la mesure

Le document doit prévoir une table de redirections 301, la conservation des métadonnées utiles, les canonicals, le sitemap, robots.txt et les données structurées. Planifiez une sauvegarde et une procédure de retour en arrière.

Définissez les événements clés avant la mise en ligne : formulaire envoyé, appel, réservation ou vente. Conservez les accès Search Console et Analytics pour comparer avant et après.

5. Écrire les critères de recette

Transformez les attentes en contrôles : affichage à 320, 768 et 1440 pixels, navigation clavier, formulaires testés, statut HTTP, redirections, vitesse, consentement, métadonnées et sauvegardes.

Nommez la personne qui valide chaque lot et le nombre d’allers-retours. Une recette définie protège le client comme le prestataire en évitant les critères subjectifs ajoutés à la fin.

Test final : le document permet-il réellement de chiffrer et de recetter ?

Donnez le cahier des charges à une personne qui n’a pas participé aux réunions. Elle doit pouvoir identifier les utilisateurs, les pages, les contenus, les fonctions, les accès, les intégrations, les contraintes et les validations attendues. Si elle doit deviner ce que signifie « site moderne et performant », remplacez l’adjectif par un scénario ou un critère observable.

Reliez chaque fonction prioritaire à une recette : contexte, action, résultat attendu et cas d’erreur. Ajoutez les responsabilités de fourniture et de validation, puis les conditions de migration. Le document ne doit pas figer chaque pixel ; il doit rendre le périmètre comparable, les dépendances visibles et la réception du projet vérifiable.

• Périmètre compréhensible sans explication orale
• Critères d’acceptation observables
• Responsables et dépendances attribués
• Migration, mesure et réversibilité prévues