Comment utiliser ce modèle
Chaque groupe ci-dessous est une zone de test ; chaque ligne est un cas à vérifier. Reprends-les dans un tableur, et pour chaque cas ajoute trois colonnes : résultat attendu (ce qui doit se passer), statut (OK / KO / non testé) et responsable. Pendant la recette, on coche. Un KO ouvre une anomalie : c'est là qu'un widget de feedback comme Couac évite la ressaisie, le testeur clique sur le problème et le ticket part avec l'URL, le navigateur, la console et la capture. Cette liste est volontairement générique : retire ce qui ne s'applique pas, ajoute tes cas métier.
Avant la mise en ligne : les bloquants à ne jamais sauter
Quatre vérifications coulent un lancement si elles sautent : le site est-il indexable par erreur en préprod (ou au contraire bloqué en prod) ? Les formulaires critiques envoient-ils vraiment leurs emails en conditions réelles ? Le paiement, s'il y en a un, passe-t-il un vrai test de bout en bout ? Le certificat HTTPS et les redirections sont-ils en place ? Ces quatre points ne sont pas cosmétiques : un seul raté et le site est en ligne mais cassé là où ça compte. Traite-les comme des cas bloquants dans ton cahier, en haut de la liste.
Formulaires et envois
Envoi d'un cas valide
Données correctes : confirmation affichée, email reçu côté cible, champs vidés.
Validation des erreurs
Champ requis vide ou email mal formé : message d'erreur clair, aucun envoi.
Protection anti-spam
Captcha ou honeypot actif, et un envoi légitime n'est pas bloqué à tort.
Destinataire et accusé
L'email part à la bonne adresse, l'expéditeur est lisible, l'accusé éventuel arrive.
Contenus et médias
Orthographe et cohérence
Textes relus, pas de Lorem ipsum résiduel, ton et casse cohérents.
Images et poids
Visuels nets, bien cadrés, compressés, aux bonnes dimensions, attribut alt rempli.
Mentions légales à jour
Mentions, politique de confidentialité et CGV reflètent la bonne entité.
Responsive et mobile
Points de rupture
Affichage correct du mobile au desktop, sans débordement ni texte coupé.
Cibles tactiles
Boutons et liens assez grands et espacés pour le doigt, au moins 44 px.
Menu mobile
Le menu burger s'ouvre, se ferme et navigue sans piéger le focus.
Performance
Temps de chargement
Première page utile rapide, même sur connexion mobile bridée.
Core Web Vitals
LCP, CLS et INP dans le vert sur les pages clés, mesurés sur mobile.
Images optimisées
Formats modernes, dimensions explicites, chargement différé hors écran.
SEO technique
Title et meta description
Uniques par page, longueur correcte, intention claire.
Indexation maîtrisée
robots.txt et balise meta robots cohérents, préprod non indexable, prod indexable.
Sitemap et canonical
Sitemap.xml à jour soumis, balises canonical correctes, pas de duplication.
Données structurées
Schema.org pertinent en place et valide là où c'est utile.
Accessibilité
Contrastes
Texte lisible, ratio de contraste conforme au niveau AA.
Navigation clavier
Tout est atteignable et activable au clavier, focus visible.
Alternatives textuelles
Images porteuses de sens décrites, champs de formulaire étiquetés.
Conformité RGPD
Bandeau cookies
Consentement réel : aucun traceur non essentiel avant acceptation.
HTTPS partout
Tout le site en HTTPS, aucun contenu mixte, redirection depuis HTTP.
Données et formulaires
Finalité indiquée, case de consentement si besoin, droits expliqués.
Questions fréquentes
Ce modèle remplace-t-il un vrai cahier de recette ?
Il en est la matière première. Une checklist devient un cahier de recette quand tu lui ajoutes, pour chaque ligne, un résultat attendu vérifiable, un statut OK/KO tenu pendant la recette et un responsable. Reprends ces groupes dans un tableur, complète ces trois colonnes, et tu as un cahier exploitable. Pour aller plus loin, vois aussi la recette d'un site web de bout en bout.
Faut-il tout tester à chaque mise en ligne ?
Non. Sur une grosse refonte, tu passes toute la checklist. Sur une petite mise à jour, tu cibles les zones touchées plus les bloquants (formulaires critiques, paiement, indexation, HTTPS). L'intérêt d'une checklist par zones, c'est justement de pouvoir n'en rejouer qu'une partie en connaissance de cause, sans tout refaire ni rien oublier d'essentiel.
Comment transformer un point KO en ticket sans tout retaper ?
C'est exactement le rôle d'un widget de feedback visuel. Quand un cas échoue, au lieu de recopier l'URL, le navigateur et les étapes dans un tableur, tu cliques sur le problème depuis la page : Couac crée le ticket avec la capture, la console, le réseau et la cible exacte, puis le range dans un tableau où tu suis l'avancement jusqu'au correctif avant de revérifier la ligne.