La recette d'une refonte : tester avant de lancer

Un site peut être magnifique en maquette et catastrophique en ligne. Entre les deux, il y a une étape que trop de projets sacrifient par manque de temps : la recette. Après plus de vingt ans à piloter des refontes, je peux le dire sans détour : la quasi-totalité des mises en ligne qui tournent mal auraient été évitées par une recette sérieuse. Cette page détaille ce qu'il faut tester, comment l'organiser, et pourquoi je ne laisse pas sauter cette étape.

Qu'est-ce que la recette d'un site ?

La recette est la phase de tests qui valide un site avant sa mise en ligne. On y vérifie, point par point et sur un environnement de préproduction, que tout fonctionne comme prévu : les fonctionnalités, l'affichage, le mobile, les formulaires, la performance, le référencement et les redirections. C'est la dernière barrière avant que de vrais visiteurs ne découvrent le site.

Le mot vient de la gestion de projet informatique : « recetter » un livrable, c'est le confronter à ce qui avait été commandé, c'est-à-dire aux spécifications fonctionnelles du cahier des charges, pour décider s'il est accepté ou renvoyé en correction. Appliquée à un site web, la recette répond à une seule question : ce site est-il prêt à être vu par de vrais visiteurs ? Tant que la réponse n'est pas un oui documenté, on ne met pas en ligne.

Elle se distingue du développement (on ne construit plus, on éprouve) et de la maintenance (le site n'est pas encore public). La recette est le moment de vérité, celui où l'on met le projet à l'épreuve avant qu'il ne coûte cher. C'est l'une des étapes d'une refonte que je considère comme non négociable.

Ce qu'il faut tester avant la mise en ligne

Une recette complète couvre sept domaines : le fonctionnel (tout ce qui doit marcher), l'affichage sur les navigateurs, le rendu mobile, les formulaires et parcours de conversion, la performance, le SEO et les redirections. Chaque domaine se teste sur des cas concrets, pas à l'œil sur la page d'accueil.

Les sept familles de tests que je passe en revue, à chaque fois :

• Le fonctionnel. Chaque bouton, chaque lien, chaque menu, chaque fonctionnalité (recherche, filtres, panier, compte, connexion) doit faire ce qu'il annonce. On teste les parcours réels d'un visiteur, pas seulement l'existence des pages.
• L'affichage multi-navigateurs. Le site doit se comporter correctement sur Chrome, Firefox, Safari et Edge. Un rendu parfait sur un seul navigateur relève du coup de chance, pas de la recette.
• Le mobile. La majorité du trafic est mobile. On vérifie le responsive sur plusieurs tailles d'écran : lisibilité, menus, images, boutons cliquables au doigt, absence de débordement horizontal.
• Les formulaires. C'est le point le plus souvent cassé et le plus coûteux. On teste l'envoi, la réception effective du message, les messages d'erreur, les champs obligatoires et les confirmations. Un formulaire de contact muet, c'est du chiffre d'affaires perdu en silence.
• La performance. On mesure la vitesse de chargement et les Core Web Vitals sur des pages réelles. Un site lent fait fuir les visiteurs et pénalise le référencement.
• Le SEO. Balises title, hiérarchie des titres, sitemap.xml, absence de noindex résiduel, canonical corrects. C'est le contrôle qui protège le trafic (voir plus bas).
• Les redirections. Sur une refonte, chaque ancienne URL de valeur doit répondre par une redirection 301 vers sa nouvelle adresse. On teste un échantillon représentatif avant le lancement, pas après.

Comment organiser la recette

Une recette s'organise autour de deux piliers : un environnement de préproduction, copie fidèle du site futur mais invisible du public, et un cahier de recette, la liste écrite de tous les tests à passer avec leur résultat. Sans ces deux outils, on teste au hasard et on oublie l'essentiel.

La préproduction (ou « préprod ») est une copie du site hébergée à part, accessible seulement à l'équipe projet et bloquée à l'indexation des moteurs. C'est là que l'on teste tout, sans jamais exposer au public un site à moitié fini. Elle doit être aussi proche que possible de la production réelle : même version, mêmes données, même configuration. Tester sur un environnement différent de celui qui partira en ligne, c'est valider quelque chose qui n'existera pas.

Le cahier de recette est le document qui transforme les tests en méthode. C'est un tableau qui liste, ligne par ligne, chaque chose à vérifier : l'action attendue, le résultat obtenu, le statut (validé, à corriger, bloquant) et le responsable. Il garantit qu'aucun test n'est oublié et sert de preuve d'acceptation. Il structure aussi les allers-retours entre le prestataire et le client, chacun cochant ce qu'il a validé de son côté.

La recette se joue en effet à deux niveaux. Le prestataire recette d'abord ce qu'il a produit (recette technique). Puis le client valide que le site répond au besoin exprimé (recette fonctionnelle ou métier). Faire tester par des personnes qui n'ont pas construit le site est décisif : elles voient les défauts que l'équipe, trop familière du projet, ne perçoit plus. Cette répartition des rôles relève de la gestion de projet de la refonte, et le vocabulaire de la maîtrise d'ouvrage et de la maîtrise d'œuvre y prend tout son sens (voir le glossaire MOA, MOE et AMOA).

La checklist de recette avant mise en ligne

La checklist de recette regroupe les contrôles à valider avant d'ouvrir le site au public. Elle se parcourt de haut en bas, sur la préproduction, et rien ne part en ligne tant qu'une ligne bloquante n'est pas corrigée. La voici, dans l'ordre où je la déroule.

• Toutes les pages s'affichent, aucune page blanche ni erreur 500.
• Les liens internes et externes fonctionnent, aucun lien mort.
• Les menus, boutons et fonctionnalités interactives répondent correctement.
• Les formulaires envoient et le message arrive bien à destination.
• Le rendu est correct sur Chrome, Firefox, Safari et Edge.
• Le site est lisible et utilisable sur mobile et tablette.
• Les images sont optimisées, présentes et pourvues d'un attribut alt.
• Les Core Web Vitals et la vitesse sont au niveau ou meilleurs que l'ancien site.
• Les balises title et la hiérarchie des titres sont uniques et pertinentes.
• Aucun noindex résiduel, robots.txt et sitemap.xml corrects.
• Le retrait du noindex qui protège la préproduction est inscrit dans les opérations de bascule, puis contrôlé en production sitôt le site en ligne.
• Le plan de redirection 301 est en place et testé sur un échantillon.
• Les mentions légales, la politique de confidentialité et le bandeau cookies sont présents.
• Les outils de mesure (analytics, suivi de conversion) sont installés et fonctionnels.

Recette et SEO : le contrôle qui sauve le trafic

Le volet SEO de la recette vérifie que la refonte ne casse pas le référencement acquis. On contrôle les balises, l'indexabilité, le plan de redirections et la vitesse avant la bascule. C'est le contrôle le plus rentable de toute la recette : une erreur ici peut effacer des années de trafic en une nuit.

Une belle refonte qui fait disparaître le trafic organique est un échec, quel que soit le design. Pendant la recette, je traque en priorité les pièges qui coûtent des positions : un noindex de préproduction oublié qui rend le site invisible, un robots.txt qui bloque le crawl, des balises title génériques recopiées partout, ou une ancienne URL de valeur qui retombe en 404 faute de redirection.

Ce contrôle prolonge la méthode que je détaille pour refondre sans perdre son SEO, et il s'appuie directement sur le plan de redirection 301 établi en amont : la recette est le moment où l'on vérifie, une par une, que ces redirections répondent bien avant que le site ne bascule. Tester le SEO en préproduction, c'est corriger gratuitement ce qui, en production, coûterait des semaines de récupération.

Deux contrôles prolongent ce volet une fois le site basculé : vérifier que le noindex qui protégeait la préproduction a bien été retiré, faute de quoi le site part désindexé sans que rien ne le signale, et relancer un crawl pour détecter les pages orphelines, ces pages migrées que plus aucun lien interne ne dessert et que la nouvelle structure rend invisibles.

Pourquoi ne jamais sauter la recette

Sauter la recette, c'est transformer ses visiteurs en testeurs. Chaque bug découvert après le lancement coûte plus cher qu'en préproduction : perte de confiance, ventes manquées, trafic effondré et corrections en urgence. La recette est l'assurance la moins chère d'un projet de refonte.

Quand un projet prend du retard, la recette est la première variable que l'on est tenté de sacrifier, parce qu'elle se situe juste avant une date de lancement souvent annoncée. C'est exactement l'inverse qu'il faut faire. Un défaut corrigé en préproduction ne coûte qu'une correction. Le même défaut découvert en ligne coûte la correction, plus les visiteurs perdus, plus l'image écornée, plus le stress d'une équipe qui répare en urgence sous les yeux du public.

Les cas que je vois le plus souvent : un formulaire de contact qui n'envoyait rien pendant trois semaines, une balise noindex qui a fait chuter le trafic à zéro, un tunnel d'achat cassé sur mobile un jour de forte affluence. Aucun de ces incidents n'aurait survécu à une recette sérieuse. La recette protège tout le travail accompli en amont ; la traiter comme une formalité de fin de projet revient à le mettre en jeu.

La recette a une autre conséquence, que personne n'anticipe en la planifiant : c'est elle qui fixe la date de mise en service, et cette date coupe le budget en deux dans vos comptes. Ce qui est engagé après elle ne s'immobilise plus. Le mécanisme est expliqué dans la page sur le traitement comptable d'une refonte.

Tester avant de lancer n'a rien de glamour, mais c'est ce qui sépare une refonte réussie d'une mise en ligne subie. La recette s'inscrit dans la démarche complète que je décris dans mon guide de la refonte : elle en est l'avant-dernière étape, celle qui décide si tout le reste tiendra debout.