Recette d'un site web : méthode et checklist

La recette est le moment où l'agence et son client vérifient ensemble que le site livré correspond à ce qui a été commandé. Mal préparée, elle s'étire, se transforme en liste de retouches sans fin et retarde la facturation du solde. Bien cadrée, elle tient en quelques jours et se termine par une décision claire. Voici une méthode en cinq étapes et une checklist utilisable sur tout projet web.

Ce que recouvre le mot « recette »

Dans le vocabulaire du test logiciel, la recette correspond aux tests d'acceptation. Le glossaire de l'ISTQB les définit comme un niveau de test qui sert à décider si l'on accepte le système. La recette n'est donc pas une simple relecture : c'est une vérification organisée, menée contre des critères d'acceptation fixés à l'avance, c'est-à-dire les conditions qu'un livrable doit remplir pour être accepté par les parties prenantes (définition ISTQB).

On distingue en pratique deux temps :

la recette interne (ou technique), menée par l'agence avant de présenter le site ;
la recette client (ou utilisateur), menée par le client, qui débouche sur le procès-verbal de recette.

Préparer la recette avant la fin du développement

Fixer les critères d'acceptation

Une recette se gagne au moment du devis. Chaque fonctionnalité vendue doit avoir un critère vérifiable : « le formulaire de contact envoie un e-mail à l'adresse X et affiche un message de confirmation » est testable ; « le formulaire fonctionne bien » ne l'est pas. Les critères flous produisent des désaccords au moment de signer.

Rédiger le cahier de recette

Le cahier de recette liste les scénarios à dérouler. Pour chacun : l'objectif, les préconditions (compte de test, données), les étapes, le résultat attendu, puis une colonne pour le résultat obtenu. Organisez-le par parcours utilisateur plutôt que par page : inscription, achat, prise de rendez-vous, recherche, demande de devis. C'est ainsi que le client utilisera le site.

Prévoir l'environnement de recette

La recette se déroule sur un environnement aussi proche que possible de la production : même configuration serveur, contenus réels ou réalistes, services tiers (paiement, e-mail, CRM) branchés en mode test. Notez précisément la version recettée : un PV qui ne dit pas quelle version a été validée perd beaucoup de sa valeur.

La méthode en cinq étapes

1. Recette interne

L'agence déroule tout le cahier de recette avant de solliciter le client. Objectif : que le client ne découvre pas d'anomalie bloquante. C'est aussi le moment de passer les contrôles techniques (liens, formulaires, affichage mobile, accessibilité de base).

2. Recette fonctionnelle des parcours

Chaque scénario est exécuté et son résultat noté : conforme, non conforme, ou non testable (avec la raison). Une capture d'écran accompagne chaque écart. Sans preuve, une anomalie devient vite une discussion.

3. Classer les anomalies

Une grille simple suffit, à condition d'être définie au contrat :

bloquante : empêche un parcours essentiel (paiement impossible, formulaire qui n'envoie rien) ;
majeure : le parcours aboutit, mais avec un défaut important (mauvais calcul, affichage cassé sur mobile) ;
mineure : défaut sans impact sur l'usage (coquille, alignement).

Cette grille sert ensuite à décider : en général, une anomalie bloquante empêche la signature, des mineures peuvent faire l'objet de réserves.

4. Corriger et re-tester

Après correction, on rejoue le scénario concerné, mais aussi les parcours voisins. C'est le test de non-régression : vérifier qu'une modification n'a pas introduit ou révélé de défaut dans des parties inchangées (définition ISTQB). C'est l'étape la plus répétitive, donc la première candidate à l'automatisation.

5. Recette client et décision

Le client déroule ses propres vérifications, idéalement sur la base du même cahier. La recette se conclut par une décision écrite : acceptation, acceptation avec réserves, ou refus motivé. C'est l'objet du PV de recette.

Checklist de recette avant mise en ligne

Parcours et formulaires

Chaque parcours du cahier de recette aboutit, du premier clic à la confirmation.
Les formulaires refusent les saisies invalides avec un message compréhensible.
Les e-mails transactionnels partent, arrivent, et contiennent les bonnes informations.
Le paiement fonctionne en mode test, y compris les cas d'échec et d'annulation.

Affichage et compatibilité

Le site s'affiche correctement sur les tailles d'écran prévues au contrat (mobile, tablette, ordinateur).
Les navigateurs listés dans le devis ont été testés.
Les éléments interactifs restent utilisables au doigt sur mobile.

Liens et contenus

Aucun lien interne cassé ; les redirections des anciennes URL sont en place en cas de refonte.
Les textes provisoires (« lorem ipsum », prix fictifs) ont disparu.
Chaque page a un titre et une meta description propres ; le blocage de l'indexation hérité de la préproduction (robots.txt, balise noindex) a été retiré.

Obligations légales

Mentions légales : identité de l'éditeur, coordonnées, hébergeur, conformément à la LCEN (voir la fiche du ministère de l'Économie).
Cookies : aucun traceur soumis au consentement n'est déposé avant le choix de l'internaute, et refuser doit être aussi simple qu'accepter (règles de la CNIL).
Accessibilité : vérifiez au minimum les contrôles de base (alternatives des images, contrastes, étiquettes de formulaires, navigation au clavier). Selon le client, des obligations légales s'appliquent ; elles sont détaillées dans notre article sur le RGAA avant livraison.

Technique

Le certificat HTTPS est valide et toutes les ressources sont servies en HTTPS.
Les pages d'erreur (404, 500) existent et sont présentables.
Les sauvegardes et la procédure de retour arrière sont prêtes pour la mise en production.

Ce qui s'automatise, ce qui reste humain

Les vérifications répétitives se prêtent bien à l'automatisation : rejouer les parcours après chaque correction, détecter les liens cassés, repérer une partie des défauts d'accessibilité. Elles gagnent à tourner à chaque livraison plutôt qu'une seule fois en fin de projet.

D'autres contrôles demandent un regard humain : la pertinence d'un texte, la cohérence d'une alternative d'image, l'adéquation au besoin métier, le jugement esthétique. Une bonne recette combine les deux : l'automatique pour la couverture et la répétition, l'humain pour le jugement.

Conclusion

Une recette efficace repose sur trois choses : des critères d'acceptation écrits avant le développement, des parcours testés et prouvés par des captures, et une décision formalisée dans un PV. Le reste est de la discipline.

Avalyz automatise la partie répétitive : tests automatisés de vos parcours, rapport de recette partageable avec le client, PV de recette en PDF, et contrôles d'accessibilité automatiques (qui couvrent une partie des critères seulement et ne remplacent pas un audit). Essayez Avalyz gratuitement pendant 14 jours, sans carte bancaire.