Un format devenu réflexe
Dans les équipes agiles, les critères d’acceptation suivent presque toujours le même schéma: Given (étant donné un contexte), When (quand une action survient), Then (alors tel résultat est attendu). Ce format, issu du BDD (Behavior-Driven Development, une approche qui exprime les exigences sous forme d’exemples de comportements lisibles par tous), s’est imposé comme standard de facto pour spécifier ce qu’une user story doit produire.
Le problème n’est pas le format lui-même, mais son application systématique à des situations où il ne convient pas. Chris Matts, praticien reconnu en gestion des risques et co-créateur du BDD, a documenté ce phénomène dès 2019: des équipes entières utilisent Given-When-Then pour tout type d’exigence, y compris celles où le format masque l’information au lieu de la révéler.
Trois types de spécifications, un seul format
Pour comprendre le problème, il faut distinguer trois catégories de spécifications dans un projet logiciel. La première concerne l’apparence du système: disposition des écrans, couleurs, typographie. La deuxième porte sur les calculs et les données: règles métier, formules, tables de correspondance. La troisième décrit les interactions et le comportement: ce qui se passe quand un utilisateur clique, soumet un formulaire ou déclenche un processus.
Given-When-Then a été conçu pour la troisième catégorie. Le format Gherkin, le langage structuré utilisé par l’outil Cucumber pour écrire des scénarios automatiquement exécutables, le précise dans sa documentation officielle: les mots-clés décrivent un comportement observable du système, pas des données internes. Appliquer ce format aux deux autres catégories revient à forcer une information tabulaire ou visuelle dans un moule narratif qui la rend plus difficile à lire.
Quand le format cache l’information
L’exemple d’un calcul de risque de crédit illustre bien le problème. Le critère d’acceptation en Given-When-Then ressemblerait à ceci: “Given une table de données de marché avec les valeurs X, Y, Z / When le calcul de risque est exécuté / Then le résultat doit être A pour le scénario 1, B pour le scénario 2, C pour le scénario 3.”
Le même contenu présenté dans un tableur tient en quelques colonnes: données d’entrée à gauche, résultats attendus à droite, un scénario par ligne. L’analyste métier identifie immédiatement les cas manquants, les valeurs limites oubliées, les incohérences entre scénarios. Dans le format Given-When-Then, cette même information est diluée dans une prose qui oblige à reconstituer mentalement le tableau.
Matts cite des cas réels dans le domaine financier (credit risk en 2003, dérivés complexes entre 2007 et 2010) où des équipes ont abandonné Given-When-Then au profit de tableurs Excel co-construits entre analystes métier, testeurs et développeurs, avec des gains mesurables en clarté et en détection d’erreurs.
L’anti-pattern du testeur isolé
Un deuxième problème apparait quand les équipes utilisent Cucumber ou SpecFlow (des outils d’automatisation de tests qui exécutent des scénarios écrits en Gherkin) non pas comme un référentiel de spécifications partagé, mais comme un outil de test automatisé classique.
Le scénario typique se déroule ainsi: l’analyste métier rédige les critères d’acceptation, le développeur code la fonctionnalité, puis le testeur traduit les critères en fichiers Gherkin après coup, en parallèle. Le résultat est un ensemble de tests automatisés que l’analyste métier ne lit jamais et qui divergent progressivement des exigences initiales.
Cette dérive transforme un outil de collaboration en outil technique réservé aux testeurs. La documentation officielle de Cucumber sur les bonnes pratiques insiste sur l’approche déclarative centrée sur la valeur métier, mais dans la pratique, beaucoup d’équipes produisent des scénarios impératifs et techniques que seuls les développeurs comprennent.
L’inversion du besoin
Le troisième anti-pattern est plus subtil. Pour combler le fossé entre analystes métier et équipe technique, certaines organisations imposent des ateliers comme l’Example Mapping ou l’Event Storming aux analystes. Ces pratiques, utiles en soi, deviennent problématiques quand elles sont imposées par les développeurs pour alimenter leur outillage technique plutôt que pour répondre aux besoins réels de spécification.
L’analyste métier se retrouve à produire des artefacts dans un format dicté par l’outil (Gherkin) au lieu de choisir le format le plus adapté à l’information qu’il doit transmettre. Un tableau Excel pour des règles de calcul, un wireframe pour une interface, un scénario Given-When-Then pour un comportement interactif: le choix du format devrait découler de la nature de l’exigence.
Le bon outil pour la bonne exigence
La Specification by Example (spécification par l’exemple), une approche où les exigences sont illustrées par des exemples concrets co-créés par le métier et l’équipe technique, ne se limite pas à un seul format. Gojko Adzic, auteur de référence sur le sujet, le résume sans détour: les gens peuvent produire de mauvaises spécifications de test avec n’importe quel outil.
La session Three Amigos (réunion entre analyste métier, développeur et testeur pour affiner les critères d’acceptation avant le développement) reste pertinente quelle que soit la forme choisie. Ce qui compte, c’est que l’exemple soit lisible par tous les participants et qu’il révèle les cas limites.
Pour un chef de projet ou un analyste métier, la question pratique est simple: avant de rédiger un critère d’acceptation en Given-When-Then, vérifier si l’exigence décrit un comportement interactif. Si elle décrit un calcul, une transformation de données ou une règle métier tabulaire, un tableur partagé sera plus clair, plus rapide à produire et plus facile à vérifier.