La checklist de recette d’un site web est la liste des tests qu’un site doit réussir avant sa mise en ligne : contenus, liens, formulaires, appareils, vitesse, accessibilité, bases du SEO, consentement, sécurité, outils d’analyse et sauvegardes. Suivez-la dans un ordre fixe, consignez chaque anomalie au même endroit, corrigez, testez à nouveau, et ne lancez que lorsqu’il ne reste rien de bloquant. Ce guide donne la checklist complète par domaine, un processus de recette numéroté, un tableau des types de tests avec qui les réalise et quand, et les réponses aux questions que les clients posent le plus.
Dernière mise à jour : 19 octobre 2026.
Qu’est-ce que la recette d’un site web, et pourquoi est-elle importante ?
L’assurance qualité (QA), ou recette, est la vérification planifiée d’un site web par rapport à ce qu’il est censé faire, avant que de vrais visiteurs trouvent les défauts à votre place. Ce n’est pas un rapide tour de la page d’accueil sur l’ordinateur du développeur. C’est un ensemble de tests, réalisés sur de vrais appareils et de vrais navigateurs, avec une trace de ce qui a échoué et la preuve que c’est corrigé.
C’est important, car le lancement est le moment où un site est jugé par tout le monde à la fois : les clients, les moteurs de recherche et quiconque vérifie si vos formulaires vous parviennent. Un formulaire de contact cassé, un bandeau cookies qui charge des traceurs avant le consentement ou une page qui ne défile pas sur un téléphone peuvent coûter plus que toute la phase de test.
Chez Odduel, agence créative et technologique à Barcelone et São Paulo, la recette fait partie de chaque développement dans nos projets de création de sites web, et non d’un supplément à la fin. Une grande partie des vérifications répétitives (analyse des liens, captures d’écran à de nombreuses largeurs, contrôle des mises en page dans chaque langue) est confiée à des scripts, pour que les personnes consacrent leur temps au jugement : le texte se lit-il bien, l’ensemble sonne-t-il juste, le site fonctionne-t-il pour quelqu’un qui navigue au clavier ou avec un lecteur d’écran.
En bref : la recette transforme un site qui fonctionne sur un écran en un site qui fonctionne pour tout le monde. Elle demande une checklist écrite, de vrais appareils, un registre des anomalies et un second passage après les corrections. Commencez-la quand les contenus sont définitifs, pas le matin du lancement. Gardez du temps pour les corrections qu’elle révélera.
Quand commencer les tests d’un site web ?
Les tests doivent commencer bien avant la dernière semaine. Certains contrôles relèvent du design (contraste, taille des zones tactiles, ordre des titres), d’autres du développement (formulaires, mise en page responsive), et le passage complet a lieu à la fin, une fois les contenus définitifs.
Une règle utile : on ne peut pas terminer une recette sur du texte provisoire. Les vrais titres sont plus longs, les vraies photos plus lourdes et les vraies pages légales modifient le pied de page. Prévoyez le passage complet après le gel des contenus, et gardez de la place pour une série complète de corrections et de nouveaux tests. Si vous avez un site de préproduction, testez-y d’abord, puis refaites les contrôles critiques sur l’adresse réelle juste après le lancement, car serveurs, caches et certificats diffèrent.
Si vous choisissez encore la manière dont le site sera construit, notre guide de création de site web présente les étapes qui précèdent celle-ci.
La checklist de recette, domaine par domaine
Chaque domaine ci-dessous liste ce qu’il faut tester. Notez chaque ligne réussie, échouée ou non applicable, et consignez chaque échec avec l’adresse de la page, l’appareil, le navigateur et une capture d’écran.
Contenus et textes
- Chaque page a son texte définitif : pas de lorem ipsum, pas de « XX », pas de notes de travail.
- L’orthographe et la grammaire sont vérifiées dans chaque langue du site.
- Noms, adresses, numéros de téléphone et horaires correspondent exactement à vos autres profils.
- Dates, prix et dénominations légales sont à jour et cohérents d’une page à l’autre.
- Les images sont les versions définitives, bien cadrées à chaque largeur, avec un texte alternatif utile.
- Les titres suivent un ordre logique : un H1 par page, puis H2, puis H3.
- Les pages légales (confidentialité, cookies, mentions légales) sont publiées et accessibles depuis le pied de page.
- Aucun mot ne reste seul sur la dernière ligne d’un titre aux largeurs courantes.
Liens et navigation
- Un crawler ne trouve aucun lien interne cassé (aucune erreur 404).
- Les liens externes ouvrent la bonne page et fonctionnent toujours.
- Le menu principal, le menu du pied de page et le fil d’Ariane fonctionnent sur chaque page.
- Les anciennes adresses d’un précédent site redirigent en 301 vers les nouvelles.
- Les liens téléphone appellent, les liens e-mail s’ouvrent avec la bonne adresse, les liens de carte ouvrent l’itinéraire.
- La page 404 existe, elle est conçue et aide le visiteur à retrouver son chemin.
Formulaires
- Chaque formulaire s’envoie, et le message arrive dans la bonne boîte de réception.
- Le visiteur voit une confirmation claire, et l’éventuel e-mail de confirmation arrive et se lit bien.
- Champs obligatoires, messages d’erreur et validation fonctionnent, y compris avec un formulaire vide.
- Les erreurs sont annoncées clairement et le focus se place sur le premier champ erroné.
- La protection contre le spam fonctionne sans bloquer de vraies personnes.
- La case de consentement, quand elle est nécessaire, n’est pas cochée par défaut et renvoie à la politique de confidentialité.
- Les données des formulaires ne sont stockées ou transmises que là où votre politique de confidentialité l’indique.
Navigateurs et appareils
- Les versions actuelles de Chrome, Safari, Firefox et Edge sur ordinateur.
- Safari sur iPhone et Chrome sur Android, sur de vrais téléphones, pas seulement dans un émulateur.
- Les largeurs courantes, des petits téléphones aux grands écrans, en portrait et en paysage.
- Le tactile : les menus s’ouvrent et se ferment, rien ne dépend du survol, les zones tactiles sont assez grandes.
- Les animations et effets au défilement se comportent bien et respectent le réglage système de réduction des animations.
- Le site fonctionne encore, au minimum, quand un script ne se charge pas.
Performance et Core Web Vitals
- Mesurez les trois Core Web Vitals que Google décrit dans sa documentation Search Central : Largest Contentful Paint (chargement), Interaction to Next Paint (réactivité) et Cumulative Layout Shift (stabilité visuelle).
- Testez les pages les plus lourdes, pas seulement la page d’accueil : un long article, une galerie, une fiche produit.
- Les images sont dans des formats modernes, dimensionnées pour l’espace qu’elles occupent, et chargées en différé sous le premier écran.
- Les polices sont auto-hébergées ou préchargées, avec une police de secours qui évite aux lignes de sauter.
- Cache et compression sont activés, et les fichiers statiques ont une longue durée de cache.
- Aucun script tiers ne bloque le premier affichage.
Accessibilité
- Vérifiez la conformité au niveau AA des WCAG 2.2, la recommandation actuelle du W3C, comme objectif de travail.
- Chaque page s’utilise au clavier seul, avec un contour de focus visible.
- Le contraste du texte atteint 4,5:1 pour le texte courant et 3:1 pour les grands textes, sur la vraie couleur de fond.
- Les images ont un texte alternatif qui les décrit, et les images décoratives un attribut alt vide.
- Les champs de formulaire ont des libellés, et les erreurs ne sont pas signalées par la seule couleur.
- Un test au lecteur d’écran (VoiceOver ou NVDA) sur les parcours clés : accueil, un service, le formulaire de contact.
- Si vous vendez des produits ou certains services aux consommateurs de l’UE, vérifiez si l’acte européen sur l’accessibilité s’applique : la directive (UE) 2019/882 s’applique depuis le 28 juin 2025, avec des exemptions pour les microentreprises qui fournissent des services.
Les bases du SEO
- Chaque page a un titre et une meta description uniques.
- Les adresses sont courtes, en minuscules et séparées par des tirets ; notre guide des URL SEO friendly explique comment les choisir.
- Chaque page affiche un lien canonique, et les pages traduites portent des balises hreflang.
- Un sitemap XML existe et ne liste que les pages que vous voulez voir trouvées.
- Le fichier robots.txt autorise le site en ligne, et aucun « noindex » ne reste de la préproduction.
- Les données structurées (organisation, articles, fil d’Ariane) se valident sans erreur.
- Une image et un titre de partage s’affichent correctement quand un lien est collé dans une messagerie.
Confidentialité, consentement et bandeau cookies
- Aucun traceur d’analyse ou de publicité ne se charge avant que le visiteur l’accepte, comme l’exigent le RGPD et les règles ePrivacy.
- Refuser est aussi facile qu’accepter, et le choix est mémorisé.
- Le visiteur peut modifier son choix plus tard depuis un lien dans le pied de page.
- La politique de cookies liste chaque cookie et chaque clé de stockage du navigateur que le site dépose réellement.
- Les vidéos, cartes et widgets de chat intégrés attendent eux aussi le consentement, ou utilisent un mode respectueux de la vie privée.
Sécurité
- HTTPS sur chaque adresse, avec un certificat valide qui se renouvelle tout seul.
- HTTP et la version www redirigent vers l’unique adresse préférée.
- Les en-têtes de sécurité sont en place (HSTS, type de contenu, protection contre l’intégration en cadre, politique de référent).
- Les espaces d’administration utilisent des mots de passe robustes et la double authentification ; les comptes par défaut sont supprimés.
- Logiciels, thèmes et extensions sont à jour, et ceux qui ne servent pas sont supprimés.
- Les formulaires et les pages de connexion sont protégés contre les tentatives répétées.
- Aucun fichier de test, de sauvegarde ou de configuration ne peut être téléchargé depuis le web.
Analyse et suivi
- L’outil d’analyse enregistre les pages vues et les événements qui comptent (formulaire envoyé, appel cliqué, achat).
- Le trafic de test est filtré, ou marqué, pour que les chiffres de la semaine de lancement restent propres.
- Le mode consentement, s’il est utilisé, transmet le choix du visiteur à chaque balise.
- La Search Console et les autres outils pour webmasters sont validés, et le sitemap est soumis.
Sauvegardes et retour en arrière
- Une sauvegarde complète des fichiers et de la base de données existe avant le lancement, stockée hors du serveur.
- Des sauvegardes automatiques sont programmées, et une restauration a réellement été testée.
- Vous savez remettre la version précédente en quelques minutes si le lancement tourne mal.
- La surveillance de la disponibilité est active et les alertes parviennent à une personne capable d’agir.
Comment mener le contrôle qualité (QA) d’un site web, pas à pas ?
Une checklist ne fonctionne qu’à l’intérieur d’un processus. Voici l’ordre que nous suivons.
- Gelez les contenus. Convenez que textes, images et pages légales sont définitifs pour cette série.
- Rédigez le plan de test. Listez les pages, parcours, navigateurs, appareils et largeurs que vous couvrirez, et qui teste quoi.
- Lancez les contrôles automatisés. Analyse des liens, validation HTML, scan d’accessibilité, mesures de performance, captures d’écran à de nombreuses largeurs.
- Faites les contrôles manuels. Parcourez chaque parcours clé sur de vrais appareils : trouver un service, lire un article, envoyer un formulaire, changer de langue.
- Consignez chaque anomalie au même endroit. Adresse, appareil, navigateur, étapes pour la reproduire, capture d’écran, et une gravité : bloquante, majeure ou mineure.
- Corrigez et testez à nouveau. Chaque correction est vérifiée par une autre personne que celle qui l’a faite, et la zone autour est testée de nouveau.
- Tenez la revue go / no go. Ne lancez que si aucune anomalie bloquante n’est ouverte et que les majeures sont acceptées par écrit.
- Lancez, puis testez le site en ligne. Refaites les contrôles critiques sur l’adresse réelle dans la première heure : formulaires, consentement, redirections, HTTPS, analyse.
- Surveillez la première semaine. Vérifiez les journaux d’erreurs, le journal des 404, la réception des formulaires et la Search Console, et corrigez ce que révèlent les vrais visiteurs.
Quels tests faut-il, et qui les réalise ?
Tous les tests ne demandent pas un spécialiste, et tous ne peuvent pas être automatisés. Le tableau ci-dessous présente les principaux types, qui les réalise en général, quand, et le type d’outil utilisé.
| Type de test | Qui le réalise | Quand | Outils habituels |
|---|---|---|---|
| Relecture des contenus | Client et rédacteur | Après le gel des contenus | Une checklist, un second relecteur |
| Contrôle des liens et redirections | Développeur | Avant et après le lancement | Un crawler, les journaux du serveur |
| Test des formulaires et e-mails | Développeur et client | Avant le lancement, puis en ligne | De vrais envois vers de vraies boîtes de réception |
| Navigateurs et appareils | Testeur QA ou développeur | Passage final | De vrais téléphones, des services de test de navigateurs |
| Performance | Développeur | Pendant le développement et au passage final | Lighthouse, PageSpeed Insights, données terrain |
| Accessibilité | Designer et développeur | Design, développement et passage final | Scanner automatique, clavier, lecteur d’écran |
| Les bases du SEO | Responsable SEO ou développeur | Passage final et jour du lancement | Crawler, Search Console, test des données structurées |
| Consentement et confidentialité | Développeur et conseiller juridique | Passage final | Outils de développement du navigateur, la politique de cookies |
| Sécurité | Développeur ou administrateur du serveur | Avant le lancement, puis régulièrement | Contrôle des en-têtes, rapports de mises à jour, limites de connexion |
| Recette utilisateur | Client | Dernière étape avant le lancement | Les parcours en ligne, une fiche de validation |
Ce qu’il faut retenir : les outils automatiques sont rapides et exhaustifs sur ce qui se mesure, et il faut des personnes pour tout ce qui demande du jugement. Un scanner vous dira qu’un bouton n’a pas de libellé ; seule une personne vous dira que le libellé prête à confusion.
Combien de temps dure la recette d’un site web, et de quoi dépend-elle ?
La durée dépend de la taille du site, du nombre de gabarits, du nombre de langues, du nombre de formulaires et d’intégrations, et du nombre d’appareils sur lesquels vous vous engagez. Un petit site vitrine avec un formulaire se teste bien et vite. Un site multilingue avec une boutique, un système de réservation et des animations sur mesure demande des jours de passages attentifs et au moins une série de corrections.
Ce qui ralentit le plus la recette, ce ne sont pas les tests eux-mêmes, mais les contenus en retard, l’absence de responsable clair des corrections et l’absence d’échelle de gravité convenue. Quand chacun sait ce que veut dire « bloquant », la décision go / no go devient simple.
Pour une seule page de campagne, la liste est plus courte et la logique de budget différente ; notre article sur le prix d’une landing page explique comment ces pages sont cadrées.
Qu’est-ce qui coince le plus souvent au lancement ?
Les mêmes défauts reviennent sans cesse, et presque tous coûtent peu à repérer en amont :
- Des formulaires de contact qui envoient vers une boîte de test, ou dont les e-mails arrivent en spam.
- Un réglage « demander aux moteurs de recherche de ne pas indexer » ou une balise noindex oubliés depuis la préproduction.
- Des traceurs qui se déclenchent avant le consentement, parce qu’une balise a été ajoutée en dehors de l’outil de consentement.
- D’anciennes adresses sans redirection : les liens d’autres sites et les résultats de recherche aboutissent à une 404.
- Un menu ou une fenêtre qu’on ne peut pas fermer sur un téléphone, ou une page qui ne défile pas.
- Des images envoyées à la taille d’origine de l’appareil photo, qui ralentissent le premier écran en données mobiles.
- Un cache qui continue à servir l’ancienne feuille de style aux visiteurs après une modification.
Chacun de ces points figure dans la checklist ci-dessus. L’intérêt d’une liste écrite, c’est que personne n’a besoin de s’en souvenir sous pression.
Questions fréquentes
Que doit contenir une checklist de recette de site web ?
Une checklist de recette complète couvre les contenus et textes, les liens et redirections, les formulaires et e-mails, les navigateurs et appareils, la performance et les Core Web Vitals, l’accessibilité, les bases du SEO, la confidentialité et le bandeau cookies, la sécurité, l’analyse et les sauvegardes. Chaque ligne est notée réussie ou échouée, et chaque échec est consigné avec la page, l’appareil, le navigateur et une capture d’écran.
Peut-on automatiser entièrement les tests d’un site web ?
Non. L’automatisation excelle pour l’analyse des liens, les mesures de performance, les captures d’écran à de nombreuses largeurs, la validation et les scans d’accessibilité, et elle doit tourner à chaque modification. Mais il faut toujours une personne pour juger si les textes se lisent bien, si un parcours a du sens et si un utilisateur de lecteur d’écran peut réellement remplir un formulaire.
Qui doit faire la recette d’un nouveau site web ?
Idéalement, plusieurs personnes. Le développeur mène les contrôles techniques et automatisés, un testeur ou un designer vérifie les appareils et l’accessibilité, et le client vérifie les contenus et réalise la recette finale. La personne qui corrige une anomalie ne doit pas être la seule à confirmer qu’elle est corrigée : un second regard repère ce que le premier a manqué.
L’acte européen sur l’accessibilité s’applique-t-il à mon site ?
C’est possible. L’acte européen sur l’accessibilité s’applique depuis le 28 juin 2025 à certains produits et services proposés aux consommateurs de l’UE, dont l’e-commerce, et les microentreprises qui fournissent des services en sont exemptées. Qu’il couvre ou non votre site dépend de ce que vous vendez et à qui : consultez la directive ou demandez à un conseiller juridique.
Quelle différence entre la QA et la recette utilisateur ?
La QA est le contrôle technique et qualité complet mené par ceux qui ont construit le site, à partir d’une checklist écrite. La recette utilisateur vient en dernier : le client parcourt les vrais parcours et confirme que le site fait ce qui a été convenu. La QA trouve les défauts ; la recette utilisateur confirme que le site terminé est bien celui que vous avez demandé.
Faut-il tester à nouveau après le lancement ?
Oui. Refaites les contrôles critiques sur l’adresse réelle dans la première heure, car serveurs, caches et certificats diffèrent de la préproduction. Surveillez ensuite les journaux d’erreurs, le journal des 404, la réception des formulaires et la Search Console pendant la première semaine, et gardez un contrôle régulier plus léger après chaque mise à jour d’extensions, de thèmes ou de contenus.
Si votre site approche du lancement et que vous voulez le faire tester sérieusement, ou si vous préparez un nouveau site et voulez intégrer la recette au travail dès le premier design, notre équipe de création de sites web peut vous aider : parlez-nous de votre projet et nous verrons ce dont votre lancement a besoin.
À lire aussi : Sécurité WordPress en 2027 : les menaces et les parades, Accessibilité des sites web : ce qu’exige l’European Accessibility Act, Combien de temps faut-il pour créer un site web ? Le calendrier, étape par étape, Checklist d’audit UX : quoi vérifier et comment le mener en sept étapes, Refonte de site web et SEO : la checklist pour ne pas perdre de trafic.
