1. Définissez ce que la refonte doit changer
Une checklist de refonte de site web utile remplit trois fonctions : protéger ce qui aide déjà vos clients, préciser ce qui doit être corrigé et définir comment tester le nouveau site. Partez du site actuel et de quelques tâches concrètes de visiteurs. L’apparence fait partie du travail ; les demandes clients, les contenus utiles et les liens existants doivent aussi traverser la transition sans se perdre.
Notez les problèmes que vous pouvez montrer. Les visiteurs ont peut-être du mal à comparer vos services sur un téléphone, le formulaire de contact demande des informations que votre équipe n’utilise jamais, ou le personnel ne peut pas modifier les horaires d’ouverture. À côté de chaque problème, décrivez le fonctionnement souhaité. « Un visiteur peut choisir un service et envoyer une demande sans nous appeler pour savoir comment faire » donne à la personne chargée de la validation un scénario à essayer.
Distinguez le rafraîchissement visuel des modifications du contenu, de la structure des pages et des outils connectés. Ces travaux peuvent faire partie du même projet, mais chacun doit faire l’objet d’une décision explicite. Si le problème principal est une offre qui n’est plus à jour, une nouvelle typographie ne suffira pas. Consultez le guide du brief de projet web pour le cahier des charges global ; cette checklist porte sur les éléments d’un site existant à préserver lors d’une refonte.
2. Décidez quoi garder, réviser, regrouper ou supprimer
Dressez un inventaire des pages avant de valider de nouvelles mises en page. Notez chaque adresse actuelle, sa fonction, les contenus importants et la personne habilitée à approuver les modifications. Incluez les pages absentes du menu principal, les documents téléchargeables, les versions linguistiques et les pages de destination des campagnes. Demandez à vos collègues quels liens ils envoient aux clients ; les contenus utiles ne sont pas toujours bien visibles dans la navigation.
Attribuez une décision à chaque élément :
- Garder : la fonction et les informations restent utiles, même si la présentation change.
- Réviser : la page est conservée, mais une partie identifiée de son contenu doit être validée.
- Regrouper : une autre page reprendra ses contenus utiles et répondra au même besoin du visiteur.
- Supprimer : le contenu n’a plus de raison d’être et sa suppression a été approuvée.
Préservez les informations précises qui aident à prendre une décision : périmètre des services, conditions d’accès, zones de livraison, consignes pratiques et coordonnées. Un texte plus court n’est pas forcément plus clair s’il supprime la réponse que le client cherchait. Conservez les anciens textes et images validés pour permettre aux personnes chargées de la relecture de comparer le fond autant que la forme.
Si vous disposez d’un historique des demandes clients ou de rapports sur la recherche, utilisez-les pour repérer les pages qui méritent une attention particulière. Si les données sont rares, indiquez cette incertitude. Un avis interne selon lequel une page « ne sert à rien » justifie une vérification, mais ne constitue pas une preuve suffisante pour la supprimer.
3. Prévoyez une destination pour chaque URL modifiée
Une refonte peut conserver les adresses des pages existantes. Demandez une justification chaque fois qu’une adresse change : un regroupement de services ou une structure de site plus claire peuvent le justifier, une nouvelle palette de couleurs non. Pour chaque page déplacée, notez l’ancienne adresse et la page pertinente qui la remplacera. Demandez au développeur de vérifier l’ensemble des correspondances convenues, pas seulement la page d’accueil.
Google recommande des redirections permanentes côté serveur, comme les codes HTTP 301 ou 308, lorsqu’une page change définitivement d’adresse. Le critère de validation pratique est simple : ouvrir l’ancienne adresse doit conduire le visiteur à la bonne page de remplacement, qui doit se charger correctement.
Les recommandations de Google sur les migrations de sites conseillent de rediriger directement vers la destination finale et d’éviter les destinations sans rapport, comme la redirection de toutes les pages supprimées vers l’accueil. Une page réellement supprimée sans remplacement approprié doit renvoyer une réponse 404 ou 410 correcte. Demandez au développeur de consigner cette décision.
Mettez à jour les liens internes, les références canoniques, les liens entre versions linguistiques le cas échéant et le sitemap pour tenir compte des nouvelles adresses. Google recommande de conserver les redirections pendant au moins un an, et plus longtemps lorsqu’elles restent utiles aux visiteurs. Convenez de la personne qui les maintiendra après la remise du site. Un plan de redirection protège la continuité ; il ne garantit ni une position dans les résultats de recherche ni une date d’indexation.
4. Suivez une demande jusqu’à sa réception par votre équipe
Un formulaire ne remplit sa fonction que lorsque les informations du visiteur arrivent à la destination convenue et qu’une personne peut les traiter. Notez les champs actuels, le destinataire, la confirmation et tout système de réservation ou de gestion client connecté. Décidez de ce qui doit rester identique et de ce qui doit changer. Un formulaire reconstruit peut sembler familier tout en envoyant les informations ailleurs.
Effectuez une courte série de tests ciblés
Utilisez des informations clairement identifiées comme des données de test. Envoyez une demande valide, puis vérifiez la boîte de réception ou la fiche créée dans le système connecté : le service choisi, le message, l’adresse de réponse et toute pièce jointe convenue doivent arriver correctement. Essayez d’envoyer le formulaire sans remplir les champs obligatoires et avec une adresse e-mail invalide. Vérifiez que l’explication aide le visiteur à corriger le problème.
Demandez au développeur de montrer, lors d’un test contrôlé, le comportement convenu en cas d’échec de transmission. Un message de réussite doit correspondre à l’état convenu pour un envoi réussi, et un échec doit proposer une prochaine étape utile. N’utilisez pas de données de clients réels pour tester la gestion des erreurs.
Suivez également les liens téléphoniques, les liens e-mail et les boutons de réservation depuis leur page d’origine. Si une page de service transmettait auparavant le choix du service au formulaire de contact, vérifiez qu’elle le fait toujours. Ce petit élément de contexte peut facilement disparaître lorsque les pages et les formulaires sont reconstruits séparément.
5. Évaluez le design à travers des tâches réelles
Examinez une version de prévisualisation fonctionnelle avec les contenus définitifs, pas seulement une maquette statique. Ouvrez la page de service la plus longue, une page contenant plusieurs images et le parcours principal de prise de contact. Sur les téléphones et navigateurs de bureau convenus, essayez les tâches définies au départ. Vérifiez que la navigation reste utilisable, que les textes s’affichent correctement, que les commandes répondent et que les détails importants restent visibles.
Intégrez l’accessibilité à cette évaluation. Les vérifications simples de W3C WAI proposent de premiers contrôles portant sur les titres, les alternatives textuelles des images, le contraste, l’agrandissement du texte, l’utilisation du clavier et les formulaires. Essayez de naviguer sans souris, vérifiez la présence d’un indicateur visible de focus clavier et agrandissez le texte tout en effectuant la tâche principale.
Ces contrôles constituent une première évaluation. Les recommandations d’évaluation du W3C expliquent qu’un outil seul ne peut pas établir si un site respecte les normes d’accessibilité ; une évaluation humaine compétente est nécessaire. Convenez avec votre prestataire de la norme requise, du périmètre de l’évaluation et des responsabilités. Consignez les obstacles non résolus avec les autres défauts.
Pour la vitesse, demandez des contrôles comparables sur des pages représentatives de l’ancien et du nouveau site, dans des conditions documentées. Observez ce qui se passe pendant le chargement des images et des polices, et vérifiez si l’action principale est utilisable. Considérez un score de test comme un élément de diagnostic. Les échanges sur la validation doivent identifier les problèmes réels, les pages concernées et les corrections convenues.
6. Utilisez une grille avec des critères de validation observables
Copiez la grille suivante dans votre document de projet. Remplacez chaque exemple par vos pages, vos outils et les conditions de test convenues. Ajoutez à chaque ligne un responsable, un lien vers les éléments de preuve, un résultat et une date de vérification. « Cela semble bien » ne permet pas à la personne suivante de savoir ce qui a été vérifié.
| Domaine | Ce qui doit être démontré |
|---|---|
| Contenu | Les détails des services et les coordonnées convenus figurent sur chaque page validée ; un responsable est désigné pour les révisions. |
| Liens existants | Chaque adresse de la liste de migration mène à la destination convenue ou renvoie la réponse de suppression prévue. |
| Demandes clients | Un test clairement identifié arrive à la bonne destination avec les champs convenus ; la validation des saisies et les états d’échec sont vérifiés. |
| Tâches des visiteurs | Une personne effectue le parcours principal sur les appareils et navigateurs désignés, y compris les vérifications convenues au clavier et avec le zoom. |
| Mise en ligne | Le contenu validé est en ligne, les vérifications critiques réussissent sur le domaine public et une personne désignée peut rétablir la version précédente. |
| Responsabilités | L’entreprise dispose des accès convenus, des responsabilités de maintenance définies et des instructions pour les mises à jour courantes. |
Classez les constats avant la validation finale. Une demande non reçue, une page de service inaccessible ou une action essentielle bloquée doivent empêcher la mise en ligne. Un petit ajustement d’espacement peut être confié à un responsable avec une échéance ultérieure convenue. Établissez cette distinction ensemble, pour qu’aucune des parties ne confonde une liste de travaux inachevés avec un relevé de validation.
7. Planifiez la bascule et une procédure de rétablissement utilisable
Avant la mise en ligne, identifiez la version validée, la personne chargée du changement et celle qui le vérifiera. Enregistrez une copie restaurable du site actuel et de la configuration concernée. Demandez ce qu’implique sa restauration, qui peut l’effectuer et ce qu’il advient des demandes ou des contenus soumis pendant la transition. Une sauvegarde n’est utile que si l’équipe sait comment la restaurer.
Convenez du moment où les modifications de contenu s’arrêtent et de la manière dont les changements tardifs seront reportés. C’est important même pour un petit site : un numéro de téléphone ou une description de service mis à jour risquent sinon d’être écrasés par une ancienne version. Si l’hébergement ou les paramètres du domaine changent aussi, vérifiez explicitement les services qui en dépendent, comme la messagerie de l’entreprise.
Répétez les vérifications critiques sur le domaine public immédiatement après la bascule. Contrôlez les anciens liens, le parcours principal du visiteur et la réception effective des envois de test. Demandez au développeur de vérifier que les pages publiques utilisent les paramètres d’indexation prévus et que les restrictions temporaires de prévisualisation n’ont pas été transférées en production. La personne chargée des corrections doit rester disponible pendant la période de mise en ligne convenue.
8. Clôturez le projet avec des preuves et des responsabilités claires
Organisez une vérification de suivi avec un responsable désigné. Examinez les problèmes signalés, les pages manquantes inattendues et la réception des demandes. Lorsque des rapports de recherche sont disponibles, analysez les évolutions dans leur contexte plutôt que de considérer les variations d’une seule journée comme un verdict sur la refonte. Conservez la date de mise en ligne et l’historique des changements pour pouvoir examiner les observations ultérieures.
Lors de la remise du site, rassemblez l’inventaire final des pages, la liste des redirections, les résultats de validation, les modalités d’accès et les instructions de mise à jour. Demandez quelles tâches récurrentes sont incluses et lesquelles nécessitent un accord distinct. Avant de considérer la remise comme terminée, faites réaliser une modification courante de contenu par la personne qui assurera la maintenance du site.
La refonte de site web de Digital Studio commence à 1 790 EUR pour un maximum de cinq pages existantes utilisant vos contenus actuels, avec un audit du site, une reconstruction responsive et les redirections d’URL convenues. Les migrations plus importantes font l’objet d’un devis distinct. Pour discuter d’un site existant, envoyez une demande gratuite pour une refonte en indiquant son adresse, le problème principal et ce qui doit être préservé. Aucun paiement n’est requis pour envoyer une demande.
