# Un gabarit de session de recette avec le client, du scénario au verdict

> La recette client par échanges d'e-mails éparpillés fait perdre des critères en route. Un gabarit structuré du scénario au verdict final change la donne.

- Auteur : Clément Hadrot
- Publié le : 2024-10-22
- Mis à jour le : 2024-10-22
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/gabarit-session-recette-client-scenario-verdict/

## L’essentiel

- Un scénario écrit avant la session, jamais improvisé
- Des critères d'acceptation notés au moment même du test
- Un verdict explicite qui engage les deux parties

Comment savoir, six semaines après la mise en ligne, si le client a validé le comportement du formulaire de contact ou seulement la couleur du bouton ? Dans une agence qui livre des sites vitrines et des extensions sur mesure, la recette se fait souvent par une suite de messages courts, un fil de discussion qui mélange remarques esthétiques et bugs bloquants, sans qu'aucun document ne fasse foi.

Le résultat est prévisible : des allers-retours qui s'étirent, des points considérés comme validés par une équipe et encore ouverts pour l'autre, et une facture finale contestée parce que personne ne peut prouver ce qui a réellement été testé. Un gabarit de session de recette, rempli en direct avec le client, referme cette brèche.

## Ce que le fil d'e-mails ne permet jamais de reconstituer

Un e-mail capture une remarque à un instant donné, pas un parcours de test complet. Il manque systématiquement trois informations : quel scénario était joué au moment de la remarque, quel était le résultat attendu, et si le point a finalement été accepté, refusé ou reporté à une version ultérieure. Sans ces trois éléments, chaque relance oblige à retrouver le contexte depuis le début.

Un gabarit de session de recette répond précisément à ce manque en structurant chaque test autour de ces trois axes, consignés au fil de l'eau plutôt que reconstitués après coup.

## La structure du gabarit, scénario par scénario

Le document tient sur un tableau simple, projeté à l'écran pendant la session avec le client, rempli en direct :

| Scénario | Critère d'acceptation | Résultat observé | Verdict |
| --- | --- | --- | --- |
| Envoi du formulaire de contact avec un champ obligatoire vide | Message d'erreur visible sous le champ concerné | Message affiché en haut de page, pas sous le champ | Refusé |
| Ajout d'un produit en rupture de stock au panier | Bouton désactivé, mention « rupture de stock » | Conforme | Accepté |

Chaque ligne se termine par un verdict parmi trois possibles : accepté, refusé, ou reporté. Un verdict « reporté » engage une date de retest, jamais une promesse vague de « on regarde ça plus tard ».

### Préparer les scénarios avant la session, jamais pendant

Improviser les scénarios de test devant le client donne une impression de rigueur qui ne résiste pas à l'analyse : des cas importants sont oubliés, l'ordre est incohérent, et le client perd patience si la session s'éternise sur des essais hésitants. Les scénarios doivent être rédigés en amont, à partir du cahier des charges initial, et classés par ordre de criticité, du parcours d'achat principal jusqu'aux cas limites.

- Parcours nominal : ce que fait la majorité des visiteurs, testé en premier.
- Cas limites : champ vide, quantité négative, fichier trop lourd envoyé dans un formulaire.
- Cas de régression : ce qui fonctionnait dans la version précédente et qui doit toujours fonctionner.

> L'essentiel à retenir : Un scénario écrit avant la session, jamais improvisé ; Des critères d'acceptation notés au moment même du test ; Un verdict explicite qui engage les deux parties

## Faire signer le verdict, pas seulement le noter

Un tableau rempli mais jamais validé formellement reste discutable des semaines plus tard. La session se termine par une relecture commune de chaque ligne « refusé » ou « reporté », suivie d'une validation explicite : le client confirme par écrit, sur le document lui-même, qu'il reconnaît la liste des points restant à traiter.

> Un point noté « accepté » pendant la session n'est jamais rediscuté ensuite. C'est la règle qui donne toute sa valeur au gabarit : sans elle, il redevient un simple compte rendu de réunion.

## Tracer les retours dans le temps, pas seulement dans l'instant

Chaque session de recette s'archive dans un dossier partagé avec un identifiant unique et une date. Lors d'une session suivante, les points « reporté » de la session précédente sont reproposés en premier, avec un rappel du critère d'acceptation initial. Cette traçabilité évite qu'un point litigieux disparaisse discrètement d'une itération à l'autre faute d'être reproposé.

### Adapter le niveau de détail au projet

Pour un petit site vitrine, une dizaine de scénarios suffit généralement. Pour une extension e-commerce complexe, le gabarit peut compter plusieurs dizaines de lignes réparties en sections : paiement, expédition, comptes clients, notifications. Le format reste identique, seule la profondeur change.

## En résumé

Un gabarit de session de recette ne remplace pas les tests automatisés, il structure la part humaine de la validation, celle où un client confirme que le produit livré correspond bien à ce qu'il avait imaginé. En consignant scénario, critère et verdict au même endroit et au même moment, l'agence transforme une conversation floue en un document opposable, et gagne un temps précieux sur les relances qui, sinon, s'accumulent sans fin.