Recette d’un site web : la checklist avant la mise en ligne

Une mise en ligne ratée tient rarement à une grande panne. C’est un formulaire de contact dont les messages n’arrivent nulle part, un paiement qui échoue sur téléphone, un lien vers l’ancien site, une balise oubliée qui empêche Google d’indexer les pages. Chacune de ces erreurs se repère en quelques minutes avant la mise en ligne, et coûte des clients après.

La recette sert à les attraper à temps. Dans mon poste de chef de projet digital, je coordonne une agence web et des prestataires : la recette est le moment où je vérifie que ce qui est livré correspond à ce qui a été demandé. Voici la méthode, la checklist complète et un modèle de tableau de suivi des anomalies à reprendre tel quel.

Qu’est-ce que la recette d’un site web ?

La recette est l’ensemble des vérifications faites par le client, ou par celui qui le représente, pour accepter un site avant sa mise en production. Le mot vient de « recevoir » : on réceptionne une livraison, comme on réceptionne un chantier.

Elle ne remplace pas les tests du développeur, elle les complète. Le développeur vérifie que son code fonctionne ; la recette vérifie que le site répond au besoin. On distingue souvent deux temps :

• la recette fonctionnelle : chaque fonction prévue au cahier des charges marche, sur les navigateurs et appareils ciblés ;
• la recette utilisateur : les personnes qui utiliseront le site (vos équipes, quelques clients de confiance) réalisent les parcours réels et confirment que c’est utilisable.

Elle se fait sur un environnement de préproduction, copie fidèle du futur site en ligne, jamais directement sur le site public.

Préparer le cahier de recette avant de tester

Tester « en cliquant partout » laisse passer l’essentiel. Le cahier de recette transforme le cahier des charges en liste de vérifications. Il contient :

1. Le périmètre : les pages, fonctions et parcours à recetter, et ce qui est hors recette.
2. Les environnements et accès : adresse de la préproduction, identifiants, comptes de test par profil (visiteur, client, client professionnel, administrateur).
3. Les jeux de données : produits de test, codes promotionnels, cartes bancaires de test, adresses de livraison en France et à l’étranger.
4. Les scénarios : pour chaque parcours, les étapes et le résultat attendu, écrits de façon vérifiable. Exemple type : « Je remplis le formulaire de devis sans téléphone. Attendu : message de confirmation à l’écran, e-mail reçu par l’équipe commerciale, accusé de réception reçu par le visiteur. »
5. Les appareils et navigateurs cibles, choisis d’après vos statistiques de visite si vous en avez.
6. Les critères d’acceptation : par exemple, aucune anomalie bloquante ni majeure ouverte, les anomalies mineures planifiées avec une date.
7. Qui teste quoi, et quand, avec au moins deux tours : un premier passage, puis un second après corrections.

Tester les parcours et les fonctions

Commencez par ce qui rapporte : les parcours qui mènent à un contact, un devis ou une commande. Puis élargissez.

• Menus, pied de page et fil d’Ariane : chaque lien mène à la bonne page, aucune erreur 404
• Recherche interne et filtres : résultats cohérents, cas « aucun résultat » prévu
• Création de compte, connexion, mot de passe oublié, déconnexion
• Formulaires : champs obligatoires, messages d’erreur compréhensibles, confirmation affichée, e-mail bien reçu (vérifiez aussi les indésirables), protection contre le spam
• E-mails automatiques : expéditeur, contenu, et liens qui pointent vers le site en ligne, pas vers la préproduction
• Panier et commande : quantités, frais de port, taxes, codes promotionnels, totaux
• Paiement accepté, paiement refusé, authentification forte (3D Secure)
• Espace client ou professionnel : chaque profil ne voit que ce qui le concerne

Pour les paiements, n’utilisez jamais une vraie carte en préproduction. Stripe fournit des numéros de carte de test : 4242 4242 4242 4242 pour un paiement accepté, 4000 0000 0000 0002 pour un refus, et des cartes dédiées à l’authentification forte. Shopify propose une passerelle de test et un mode test pour Shopify Payments, et rappelle qu’on peut aussi passer une vraie commande puis la rembourser, en acceptant d’éventuels frais. Le jour J, vérifiez surtout que les clés de test ont bien été remplacées par les clés de production.

Vérifier les contenus et les obligations légales

• Plus aucun texte provisoire (« lorem ipsum », « titre à venir »), ni image de démonstration
• Orthographe, prix, unités, TVA, coordonnées et horaires relus par une personne qui n’a pas écrit les textes
• Textes alternatifs des images qui portent une information
• Mentions légales complètes : identité de l’éditeur, coordonnées, hébergeur ; conditions générales de vente affichées si vous vendez à des particuliers (la liste détaillée sur Service-Public, rédigée pour un entrepreneur individuel)
• Politique de confidentialité à jour, et sous chaque formulaire une mention d’information : qui collecte, pourquoi, sur quelle base, pour qui, combien de temps, et comment exercer ses droits
• Bandeau de consentement : aucun cookie de mesure ou de publicité déposé avant l’accord, et refuser aussi simple qu’accepter

Pour le bandeau, le test est simple : ouvrez le site en navigation privée, ouvrez l’onglet Réseau des outils de développement, refusez, puis naviguez. Aucune requête ne doit partir vers un outil de mesure ou de publicité.

Contrôler le mobile, l’accessibilité et la performance

Mobile et navigateurs

Testez sur de vrais appareils, au minimum un iPhone et un téléphone Android, en plus du mode responsive de votre navigateur. Sur ordinateur, passez par Chrome, Safari, Firefox et Edge. Vérifiez les petites largeurs : les règles d’accessibilité WCAG demandent qu’un contenu reste lisible sans défilement horizontal à 320 pixels CSS de large, ce qui équivaut à un zoom à 400 % sur un écran de 1 280 pixels.

Accessibilité

• Tout le site utilisable au clavier (touche Tab), avec un repère visible sur l’élément actif
• Contrastes suffisants entre texte et fond
• Chaque champ de formulaire avec une étiquette, chaque erreur expliquée en texte
• Titres hiérarchisés, liens explicites (pas de « cliquez ici »)

En France, le référentiel de référence est le RGAA, publié par la direction interministérielle du numérique : dans sa version 4.1.2, 106 critères, avec les tests associés (une version 5 est annoncée pour fin 2026). Si vous vendez en ligne, l’accessibilité n’est plus une option : depuis le 28 juin 2025, les obligations issues de la directive européenne sur l’accessibilité s’appliquent au commerce électronique, avec une exemption possible pour les microentreprises (moins de 10 salariés et chiffre d’affaires annuel ou total de bilan inférieur à 2 millions d’euros).

Performance

Passez les gabarits principaux (accueil, page de service ou catégorie, fiche produit, article) dans PageSpeed Insights, en version mobile. Regardez l’image principale, le poids des pages et les scripts tiers. Les seuils et les corrections sont détaillés dans le guide sur les Core Web Vitals.

Le contrôle SEO du jour de la mise en ligne

Une préproduction ne doit pas être indexée ; le site en ligne, si. Le passage de l’une à l’autre est le moment où se produit l’erreur la plus coûteuse : une consigne de blocage oubliée qui empêche l’indexation du site, ou fait sortir ses pages des résultats.

• Préproduction protégée par mot de passe : Google rappelle que le robots.txt n’empêche pas une page d’apparaître dans ses résultats
• En production, plus aucune balise noindex ni en-tête X-Robots-Tag sur les pages à indexer
• Robots.txt de production relu : pas de Disallow: / hérité de la préproduction
• Balises canoniques et sitemap qui pointent vers le domaine définitif, en HTTPS
• Une seule version du site accessible (avec ou sans www, en HTTPS), les autres redirigées
• Titre (balise title) et meta description uniques sur chaque page, un titre principal h1 clair
• En cas de refonte : chaque ancienne adresse redirigée en 301 vers son équivalent, redirections conservées au moins un an
• Sitemap envoyé dans la Search Console, et quelques pages clés testées avec l’outil d’inspection d’URL

Inversement, une consigne noindex n’est lue que si la page reste accessible au robot : bloquer une page dans le robots.txt empêche Google de voir son noindex. Sur ce site, les adresses de prévisualisation reçoivent automatiquement un en-tête X-Robots-Tag: noindex, seul le domaine principal est indexable, et un script de contrôle vérifie avant chaque mise en ligne les titres, les balises canoniques, les liens internes et les données structurées de toutes les pages. Pour une refonte, la méthode complète est dans le guide refonte de site sans perte de référencement.

Mesure, sauvegarde et plan de retour arrière

La mesure d’audience

• Outil de mesure installé sur le site en ligne, et rien ne part avant le consentement
• Chaque événement important (contact, devis, achat) déclenché une seule fois, avec les bons paramètres
• Achats dédoublonnés grâce à un identifiant de transaction (voir le guide GA4 et consentement)
• Propriété Search Console validée pour le domaine définitif

La sauvegarde et le retour arrière

• Sauvegarde complète de l’ancien site (fichiers et base de données) avant la bascule, et test de restauration
• Procédure de retour arrière écrite : qui décide, en combien de temps, comment revenir à la version précédente
• Mise en ligne planifiée un jour où l’équipe et le prestataire sont disponibles le lendemain, plutôt qu’un vendredi soir
• Surveillance des premiers jours : erreurs 404, formulaires, commandes, rapport des pages dans la Search Console

Le modèle de tableau de suivi des anomalies

Une anomalie signalée par e-mail ou par message se perd. Un tableau partagé, une ligne par anomalie, suffit dans la plupart des projets. Voici le modèle que je recommande, avec trois lignes en exemple type :

Ajoutez deux colonnes utiles : la date de signalement et une capture d’écran (ou une courte vidéo). Pour la gravité, une échelle simple suffit :

• Bloquant : un parcours clé est impossible (commander, payer, envoyer une demande). Pas de mise en ligne.
• Majeur : une fonction importante est dégradée, avec un contournement possible. À corriger avant la mise en ligne, sauf décision écrite.
• Mineur : une gêne sans impact sur les parcours. Peut être planifié après la mise en ligne.
• Cosmétique : un détail d’affichage ou de texte.

Pour le statut : Ouvert, En cours, Corrigé (à vérifier), Vérifié, ou Refusé avec une explication. Une règle évite bien des discussions : seule la personne qui a signalé l’anomalie la passe en « Vérifié », après l’avoir testée de nouveau.

En résumé : décider la mise en ligne par écrit

Une bonne recette tient en quatre gestes : un cahier de recette préparé à partir du cahier des charges, des tests sur de vrais appareils avec des données de test, un tableau d’anomalies classées par gravité, et une décision écrite à la fin. Mise en ligne, mise en ligne avec réserves datées, ou report : peu importe, tant que la décision est explicite et partagée. Le jour J, gardez cette checklist ouverte et commencez par le SEO et les paiements. Si vous préparez un nouveau site et voulez être accompagné jusqu’à sa mise en ligne, voyez ma page création de site internet.