Recette, ce que le mot veut dire vraiment
En jargon projet, faire la recette d'un site, c'est le vérifier point par point contre ce qui avait été commandé, avant de le livrer. Le mot vient de la livraison de travaux : on "reçoit" l'ouvrage, on contrôle qu'il est conforme, on signe. Pour un site web, ça couvre le fonctionnel (les formulaires partent, les liens marchent), le contenu (textes, images, mentions légales), l'affichage (responsive, navigateurs) et le non-fonctionnel (vitesse, accessibilité, SEO technique). La recette n'est pas du test sauvage : c'est une vérification cadrée par une liste de cas connue à l'avance, le cahier de recette.
Les quatre étapes d'une recette qui se passe bien
Un, tu prépares le cahier de recette : la liste des cas à vérifier, écrite avant de tester, pour ne rien laisser au hasard (pars de notre modèle de checklist). Deux, l'équipe passe une recette interne, elle attrape les gros défauts avant que le client les voie. Trois, le client fait sa recette à lui, sur un environnement de préproduction stable, et signale ce qui cloche. Quatre, tu corriges, tu fais re-vérifier les correctifs, puis tu signes le PV de recette qui acte la conformité. Sauter l'étape interne, c'est offrir tes bugs les plus visibles au client : mauvais pour la confiance.
Recette interne et recette client ne cherchent pas la même chose
L'équipe technique chasse le défaut reproductible : un formulaire qui n'envoie pas, une 404, un calcul faux. Le client, lui, juge l'usage et la conformité au brief : ce bouton est au mauvais endroit, ce texte n'est pas à jour, ce parcours n'est pas celui qu'on avait validé. Les deux comptent, mais ils n'écrivent pas le même ticket. Le client a besoin d'un outil où il pointe ce qui cloche sans connaître la taille d'écran, pendant que le dev a besoin du contexte technique pour reproduire. Un bon flux de recette réconcilie les deux dans le même ticket.
Le vrai goulot, ce n'est pas tester, c'est tracer
Tester un site, n'importe qui sait le faire. Le point qui fait dérailler une recette, c'est le suivi : un retour client par email, un autre par téléphone, un troisième en commentaire dans un Google Doc, et personne ne sait plus ce qui est corrigé. Chaque anomalie doit devenir un ticket avec un statut (nouveau, en cours, corrigé), une priorité, et tout le contexte pour la rejouer. C'est précisément le moment où un widget de feedback visuel posé sur la préproduction change la donne : le client clique sur le problème, le ticket part avec l'URL, le navigateur, la console et la capture, et tu vois l'avancement dans un tableau.
Le PV de recette : signer, mais sur quoi exactement
Le procès-verbal de recette est le document qui clôt la phase : il dit que le site est conforme, liste les anomalies restantes et leur criticité, et engage les deux parties. On ne signe pas "zéro bug" (ça n'existe pas), on signe "plus aucun bug bloquant, les mineurs sont listés et planifiés". Distingue toujours trois niveaux : bloquant (le site ne peut pas partir), majeur (à corriger vite après), mineur (cosmétique, backlog). Sans cette hiérarchie, chaque virgule devient un prétexte à repousser la mise en ligne, ou pire, on livre avec un bug bloquant noyé dans la liste.
Questions fréquentes
Recette, test et QA, c'est la même chose ?
Pas tout à fait. Le test est l'acte de vérifier un cas précis. La QA (assurance qualité) est la démarche globale qui organise ces tests sur tout le projet. La recette est la phase finale de validation, souvent contractuelle, où le client contrôle que le livrable est conforme avant de l'accepter. La recette s'appuie sur des tests, mais ajoute une dimension d'acceptation et de signature.
Sur quel environnement faire la recette d'un site ?
Sur une préproduction stable, identique à la production mais isolée : même version du code, mêmes données représentatives, jamais en direct sur le site live. Tester en production fait courir le risque d'exposer des bugs aux vrais visiteurs et de polluer les statistiques. Verrouille la version testée pendant la recette : si le code change sous les pieds du client, ses retours deviennent ingérables.
Combien de temps prévoir pour une recette de site ?
Ça dépend de la taille, mais compte une vraie fenêtre dédiée, pas un créneau volé en fin de projet. Pour un site vitrine, quelques jours de recette interne plus une semaine côté client suffisent souvent. Pour un e-commerce ou une application, prévois plusieurs cycles : recette, corrections, re-recette. Le plus gros risque, c'est de comprimer la recette parce que le projet a glissé : c'est exactement là que les bugs passent en production.