Comment amener un product owner à formuler lui-même les critères d’acceptation d’une fonctionnalité, sans qu’il touche à un fichier .feature ni qu’il apprenne la syntaxe Gherkin de mémoire ? La question mérite d’être posée, parce que la réponse habituelle — laisser le développeur rédiger seul les scénarios après coup — produit des tests qui valident ce que le code fait, pas ce que le métier attend.
Sur un projet de plateforme d’inscription à des ateliers associatifs, nous avons testé un format d’atelier en deux temps : d’abord une discussion sans syntaxe, ensuite une formalisation guidée. Le résultat a dépassé nos attentes, autant sur la qualité des scénarios que sur l’implication du product owner dans la suite du projet.
Pourquoi la rédaction Gherkin classique échoue avec un non-développeur
Donner un gabarit Étant donné / Quand / Alors à quelqu’un qui n’a jamais écrit de test revient à lui donner un moule sans lui expliquer la matière qu’on y coule. Le product owner produit alors des phrases syntaxiquement correctes mais vides de sens métier, ou pire, il abandonne et laisse le développeur écrire à sa place — ce qui annule l’intérêt du BDD (Behavior-Driven Development) : faire converger la compréhension avant le code.
Le problème n’est pas la syntaxe elle-même, plutôt simple, mais l’ordre des opérations. On demande à quelqu’un de formaliser une règle avant même qu’elle soit clairement énoncée à l’oral.
Le déroulé d’atelier qui fonctionne
L’atelier se déroule en trois blocs de vingt à trente minutes, avec un tableau blanc ou des post-it, jamais d’ordinateur ouvert au départ :
- Le product owner raconte le parcours utilisateur à voix haute, sans structure imposée. Le développeur note les cas particuliers qui surgissent naturellement (« et si la session est complète ? »).
- Ensemble, on classe ces cas en exemples concrets avec des valeurs réelles : un nom d’atelier, un nombre de places, une date. Pas d’abstraction du type « un utilisateur », mais « Camille s’inscrit à l’atelier poterie du 14 mars ».
- Le développeur reformule chaque exemple au format Gherkin devant le product owner, qui valide ou corrige immédiatement la formulation.
Un exemple de transformation
L’échange oral « si l’atelier est complet, il ne doit plus pouvoir s’inscrire, mais on doit lui proposer la liste d’attente » devient :
Scénario : Inscription refusée sur un atelier complet avec proposition de liste d'attente
Étant donné que l'atelier "Poterie du 14 mars" affiche 0 place restante
Quand Camille tente de s'inscrire à cet atelier
Alors le formulaire d'inscription est remplacé par un bouton "Rejoindre la liste d'attente"
Et aucune ligne n'est créée dans la table des inscriptions confirmées
Ce que le product owner apporte que le développeur ne voit pas
Sur ce projet, le product owner a soulevé deux règles que personne n’avait anticipées : la liste d’attente devait respecter l’ordre d’arrivée même en cas de double clic, et un bénévole inscrit à plus de trois ateliers le même mois devait recevoir un message d’alerte plutôt qu’un blocage. Ces règles n’étaient écrites nulle part ; elles vivaient dans sa tête depuis des années de gestion manuelle.
Sans l’atelier, ces cas seraient apparus en recette, ou pire, en production, sous forme de tickets de support.
Les pièges à éviter côté développeur
- Reformuler trop vite : si le développeur traduit en Gherkin avant que l’exemple soit stabilisé à l’oral, le product owner valide par politesse sans vraiment comprendre ce qui a été écrit.
- Multiplier les scénarios abstraits : un scénario avec des valeurs génériques (« un utilisateur », « un produit ») perd toute force de conviction pour quelqu’un qui pense en cas réels.
- Vouloir tout couvrir en une session : au-delà de douze à quinze scénarios, l’attention retombe et la qualité de relecture chute nettement.
Un scénario que le product owner ne peut pas relire à voix haute sans hésiter n’est pas encore prêt à être automatisé.
En résumé
La rédaction Gherkin à deux ne demande pas au product owner d’apprendre une syntaxe, elle demande au développeur d’accepter de retarder la formalisation jusqu’à ce que l’exemple métier soit limpide à l’oral. Le gain se mesure moins en nombre de scénarios qu’en absence de surprises pendant la recette : sur ce projet, aucune des douze règles validées en atelier n’a nécessité de réécriture après la mise en ligne.
