Recette d’un site web : tester les scénarios qui comptent pour l’activité
La recette d’un site doit vérifier les actions nécessaires à l’activité, avec des données et des résultats attendus. Une visite rapide des pages ne suffit pas à valider un formulaire, un paiement ou une connexion à un outil métier. Préparez les scénarios avant la livraison pour pouvoir accepter ou refuser un résultat précisément.
Décrire les parcours à livrer
Partez des tâches : choisir une prestation, demander un devis, commander une variante ou retrouver un document. Pour chacune, indiquez le point de départ, les données saisies et le résultat attendu dans le site et dans les outils reliés.
Ajoutez les variantes qui changent le fonctionnement : téléphone, clavier, utilisateur connecté ou non, produit indisponible et réponse d’un service externe. Vous n’avez pas besoin d’une liste immense de clics sans enjeu ; concentrez-vous sur les risques du périmètre livré.
Écrire les critères d’acceptation
| Scénario | Résultat à vérifier |
|---|---|
| Demande valide | Confirmation cohérente et demande reçue une seule fois |
| Champ obligatoire vide | Erreur identifiable et autres réponses conservées |
| Produit indisponible | Achat empêché avec une explication utile |
| Transmission externe en échec | État d’échec conservé et reprise prévue |
Les explications W3C sur l’identification des erreurs précisent notamment que l’utilisateur doit comprendre ce qui a échoué. Réafficher silencieusement un formulaire n’est donc pas un résultat satisfaisant.
Tester sur les bons environnements
Utilisez des données de test et les moyens de paiement de test prévus. Vérifiez que la préproduction ne déclenche pas des messages ou opérations réels non souhaités. Les accès et connexions nécessaires doivent être préparés avant la séance de recette.
Mesurez les dimensions effectivement utilisées pour les contrôles mobiles. Une capture rétrécie ne prouve pas que le site a été testé sur une largeur mobile. Conservez les URL et la version livrée avec les résultats.
Traiter les écarts avant l’acceptation
Pour chaque défaut, gardez les étapes de reproduction, le résultat observé et le résultat attendu. Distinguez une anomalie dans le périmètre prévu d’une nouvelle demande. Après correction, rejouez le scénario concerné et les parcours proches susceptibles d’être affectés.
Le cahier des charges et la recette doivent utiliser le même vocabulaire. Une correction annoncée n’est pas une correction vérifiée ; une mise en ligne n’est pas une mesure d’amélioration commerciale. Préparez séparément le suivi des résultats après livraison.
Questions fréquentes
Par quoi commencer la recette d’un site web ?
Les parcours qui comptent pour l’activité : comprendre l’offre, choisir, commander ou prendre contact. Décrivez leurs résultats attendus avant de tester uniquement l’aspect des pages.
Qu’est-ce qu’un critère d’acceptation exploitable ?
Une condition que l’on peut vérifier, comme la réception d’une demande avec les bons champs. « Le site fonctionne » reste trop vague pour confirmer une livraison.
Pourquoi tester les erreurs autant que le parcours normal ?
Un produit indisponible, un champ incomplet ou un envoi échoué font partie des usages réels. Le site doit permettre de comprendre et corriger ces situations sans perdre le travail déjà fait.
Faut-il tester en production toutes les opérations de la préproduction ?
Préparez les environnements et moyens de test selon les opérations. Les contrôles ne doivent pas déclencher par erreur des commandes, messages ou paiements réels non prévus.
Que faut-il livrer avec le relevé de recette ?
Les scénarios, les résultats et les écarts encore ouverts, avec les éléments permettant de les reproduire. Une liste cochée sans préciser le cas testé ne suffit pas toujours à vérifier la correction.
Sources
Documentation consultée le 23 octobre 2026.