Le BDD, ça ne marche pas... la guerre des
concombres

Avant de commencer

Le BDD, ou Behavior-Driven Development, est une démarche collaborative qui repose sur trois piliers exploration du besoin par des conversations structurées entre métier et technique, la formalisation exemples concrets en langage naturel, et automatisation de ces exemples sous forme de tests exécutables. Si vous souhaitez comprendre le BDD en profondeur, je vous recommande cet excellent article Arolla qui en fait un tour complet. Car cet article est pas un guide sur le BDD.

Ouverture : Des techniciens dans un grand groupe français

Notre histoire se déroule au sein un grand groupe français. Nous sommes au cœur un projet de
rénovation de SI à très fort enjeu stratégique destiné à de la facturation. Gros enjeux stratégiques et financiers. Qui dit gros enjeux dit gros budget, grosse pression, ultra top management aux aguets et tout ce qu’il s’en suit. Le décor est planté.

Notre application, une des trois briques majeures du futur SI, est une API. La brique principale en frontal des utilisateurs est un CRM du marché, nous sommes son « super calculateur ». Nous avons pour vocation de faire des calculs complexes à partir de données partenaires en conformité avec les milliers de décrets légaux qui régissent notre métier.

Au démarrage du projet, l’équipe se constitue d’un product manager, d’une product owner, d’un chef de projet « agile » et de 4 techniciens. Puis arrive un 2e PO. Jusqu’ici, rien d’alarmant. Puis arrive encore un autre PO. Pour cadrer un lot de livraison futur. Puis encore un autre ! pour un autre sujet…

Effectif final :
• Un scrum master,
• Un chef de projet agile,
• Un PM (qui est aussi chef de projet)
• Quatre PO.
• Quatre dev
• Un tech lead (votre serviteur),

Donc, 5 techniciens Vs 6 non technicien. Le rapport de force est en place.

ACTE I : Toc toc toc, bonjour c’est les problèmes

La première question problématique qui s’est posée sur le projet est : comment tester l’application ?

Le SI environnant est une page blanche et notre équipe est en avance de phase sur les autres. Or, une application dont le carburant est la donnée complexe des partenaires… sans données complexes des partenaires… ça ne va pas bien loin… En bon professionnels nous trouvons bien sur des solutions pour avancer. Nous jonglons avec un serveur de mock pour la consommation de données, beaucoup de scripts SQL versionnés pour l’historique et les prérequis en base de données et bien sur beaucoup
de suppositions qui s’empilent sur le fonctionnement cible des partenaires et du SI. Jusqu’ici, tout va bien.

Ce contexte si particulier n’est pas simple, mais nous sommes des pros ! On gère.
Une phrase retentit alors de plus en plus souvent.

« Nous ne pouvons pas jouer avec l’appli. »

Et un ticket revient à chaque rétro : « Pas de tests PO ».

Ah … Le dialogue qui suit est une carricature éhontée de l’auteur :

« Nous voulons conduire la voiture » …

« Oui je comprends, mais… le circuit n’est pas construit, pour l’instant nous n’avons construit qu’un bout du châssis, nous n’avons pas de carburant parce que la raffinerie n’est pas prête… Alors je peux peut-être monter un volant de fortune, et tu pourras t’assoir dans l’ébauche d’habitacle, tu pourras t’imaginer au volant et faire des premiers retours sur l’ergonomie, mais bon… ça ne sera pas comme la conduite du véhicule finale on ne va pas se mentir… Tu ne vas pas pouvoir jouer avec pour connaitre son comportement réel »,

« Un P.O ça doit VA – LI – DER, je suis le garant du bon fonctionnement du SI. Je DOIS donc conduire
le véhicule. »

« euhh… oui, mais comme je viens de le dire, on fait au mieux, mais le moteur ne peut pas démarrer
parce que la raffinerie … »

« JE DOIS JOUER AVEC L’APPLI POUR VA-LI-DER !!! »

Nous ne comprenons pas bien le besoin, mais nous comprenons que certains P.O ont une vision du testing et de leur rôle bien à eux et bien arrêtée.

Bon. Nous essayons de comprendre le besoin.
Nous comprenons que pour éprouver le système, ils pensent impossible d’anticiper tous les cas lors des spécifications, et veulent pouvoir faire des tests exploratoires. Avoir une idée qui surgit un lundi à 10h33, « Mais… Que se passe-t-il si jamais je mets la voiture au point à mort en pleine courbe… ?
Tiens, il faut que j’essaie ça. » Rappelons que nous n’avons pour l’instant que le châssis, et que la raffinerie de carburant est en cours de cadrage…

Réunions devs type Apollo XIII : « Messieurs, les P.O nous ont posé une colle. Et pas question de sécher ! Alors, comment qu’on fait ? »

C’est dans ce contexte que naît une proposition pragmatique et brillante. Et si on construisait un pont ? Un pont de tests fonctionnels, pour que le métier puisse voir, de ses propres yeux, que nos features tiennent leurs promesses. Des tests écrits en langages humains même… En bon crafteux passionnés, nous fouillons dans notre boite à outil et la réponse est clair, il nous faut du Cucumber et du Gherkin ! Et pour alimenter Cucumber, il nous faut BDD !!! Tadaaaaa !!!

L’idée c’est que nous allons capitaliser sur le besoin et mettre en place de l’automatisation de tests fonctionnels. Nous allons leur donner la possibilité de « jouer avec l’appli » sous forme de scénario.

Gherkin consultables et lisibles par tous. Au passage pour que ça marche, on va les accompagner sur la démarche BDD. Nous résolvons le problème et nous sortons tous grandis, avec un projet encor
plus Craft ! Le plan est parfait.

En gros, nous allons mettre en place un simulateur branché à notre châssis de voiture. Ce n’est pas vraiment conduire la voiture, mais c’est ce qui s’en rapprochera le plus !
On est vraiment des pros ! On gère !!

Acte II : Entrée en scène du Concombre sauveur

Le plan de bataille se met en place. Destination BDD. Une présentation à l’équipe s’impose. Le plus chevronné s’y colle. Réunion posée, théorie étalée, exemples à la clef. Le BDD pour des gens qui font leur premier projet agile en 2025 ce n’est pas évident (déjà pour nous ça ne l’est pas quand on rentre dans le concret), mais tout le monde s’accroche. Des idées reçues sont mises à mal, mais l’approche semble bien prendre.

Nos premiers scénarios Cucumber se mettent en place. On est des pros ! Jusqu’ici, on gère !

Les refinements changent, intégrant désormais des scénarios Gherkin. Les besoins en
accompagnement émergent : il faut clarifier les formats Given/When/Then, accompagner la
méthode de rédaction, expliquer ce qu’on attend d’un « En tant que ». Expliquer pourquoi les scénarios créés doivent toujours utiliser le langage des précédents…etc…
La technique est en place, des rapports HTML sont disponibles sur nos environnements.
On est des pros ! Jusqu’ici, on gère …

Acte III : Le concombre prend ses aises

Voici le texte intégral dans lequel toutes les entités ' ont été remplacées par une apostrophe ‘ :

Le programme qui pilote la refonte de notre SI décide qu’il est temps de mettre en place des démos communes aux applications du SI.
C’est aussi un exercice politique. Chaque équipe doit enfiler son costume du dimanche et son plus beau Powerpoint pour se présenter comme le pilier du succès. Donc pas question de ne pas montrer les évolutions de l’API en comité.

Mais, comment démontrer notre valeur à des gestionnaires alors que nous n’arrivons pas encore à réellement tester notre application ? Pas de front… Pas de données… Les regards se tournent alors vers le dernier arrivant, le concombre, bien sûr ! Un peu de maquillage, et il sera parfait sur scène.

Nous voilà à présenter des scénarios Cucumber en démo. Et l’accueil est génial ! Le charme du concombre agit. C’est juste assez technique pour éveiller les curiosités, l’automatisation de tests écrit en français impressionne, ça montre des règles de calcul vérifiables en direct. Le public se sent partie
prenante, écouté. Nous obtenons même des retours d’expert métier sur nos règles de calcul.

Un succès !

On est vraiment des pros ! Jusqu’ici, on gère …

Acte IV : Le concombre et la maman

Pour ce chapitre, il est nécessaire d’expliquer en préambule ce qu’est un Modèle d’Objet Métier, ou MOM (ça se prononce comme maman en anglais : mom). Un Modèle d’Objet Métier (MOM), c’est l’héritier des grandes méthodes de conception des années 90, un peu comme notre Merise national.
Son obsession est purement data-centrique : il ambitionne de décrire le métier au travers d’objets métiers reliés entre eux par un MCD. Il se concentre sur la forme de la donnée, pas sur ce qu’elle fait.
Les entreprises à l’époque souhaitaient un modèle de donnée unique pour tout le SI, et cette méthode promettait de ne faire l’exercice qu’une fois, et chacun derrière pouvait en théorie tirer les ficelles de son application depuis ce standard en conformité avec le métier.
Imaginez que nous voulions bâtir une ville. Les quartiers sont nos applications SI. Le MOM c’est le plan d’un bâtiment unique d’habitation qui devra servir à bâtir tous les bâtiments de la ville. Le commissariat, l’hôpital, le centre commercial… Car il ne se demande pas à quoi servent les choses ni quel sera son comportement. C’est pourquoi des approches comme le Domain-Driven Design (DDD), apparues au début des années 2000, ont tout changé. Le DDD s’intéresse d’abord à ce que les choses font (le comportement). Il préfère donc définir chaque bâtiment de la ville par son rôle, son but et le comportement des gens à l’intérieur. Chaque bâtiment a d’abord une fonction, à partir de cette fonction le plan sera dessiné. Une école maternelle ça sert à accueillir des enfants en bas âge, donc on sera vigilant sur les accès par exemple, et on évitera de leur faire une école dans laquelle à 3 ans ils doivent monter 5 étages à pied pour aller en classe. Le MOM dit juste, ton école doit se conforter au fait que dans une ville, il y a des gens, dont certains sont des enfants, et les enfants vont dans des écoles, dans une école il y a un instituteur par classe, et plusieurs élèves par classe.
Or le CRM central du SI, est conçu sur un MOM. Ils prennent un MOM, il l’injecte dans la machine standardisée, et ça fait leur base de données et leur back, et leur front … Paf , des Chocapics quoi.
Le MOM a gagné la bataille politique du SI. Il est partout… Les PO ne pensent plus métier mais MOM.
Les managers ne comprennent pas que notre base de données n’est pas un calque du MOM. Leur bâton de pèlerin, aligner le MOM et l’application.

Nous voilà donc avec des user storry, qui n’ont pour but que d’aligner les scénarios Cucumber avec le MOM… Et quand je dis des users storrys, je veux dire beaucoup de user Storry… Car le MOM évoluant sans cesse, il faut sans cesse revoir le formalisme et le langage des scénarios.

A ce stade, nous avons échoué avec certains PO à réellement mettre en place BDD. Les scénarios et les US sont rédigées seul, pas d’amigos dans la pièce… Cette pratique est vu comme de l’ingérence.

Le sujet de la séparation métier / technique est omniprésente. Le fait que Cucumber ne couvre que le domaine métier et pas la partie technique n’est pas accepté. Les PO expriment souvent la solution plus que le besoin. Nous avons aussi des demandes de montrer dans les scénarios Cucumber des sorties Json de l’Api.

La vision dev : le métier avant tout, un DDD / Hexagonal, et des tests sur le domaine pour le démontrer, la technique on s’en fiche un peu et ce n’est pas le problème des PO. La vision PO : le fonctionnel c’est aussi comment l’api sort ses données en Json ou comment on stock en base de données (et cela devrait être stocké comme le MOM)
Le métier ne lâchera pas sa vision, les devs défendent leurs convictions. Le ton monte régulièrement,l’incompréhension, les débats de valeur, les tensions apparaissent.

Dans le fond, le dev est l’exécutant. Le PO dit ce qu’on doit faire basé sur un MOM, les devs exécutent. Les lever de bouclier sont vus comme du pinaillage, de la réticence d’ego, et les devs deviennent les relous qui compliquent tout au lieu de faire ce qu’on leur demande.

Acte V : La tyrannie du concombre

Les problèmes humains ont pris le pas sur les incompréhensions. Les devs se démotivent, les pos se braquent. Le constructivisme collectif a laissé place à des stratégies et des calculs. Les PO se demandent comment faire avaler la pillule aux devs en évitant les débats qui challengent les demandes. Les DEVS se demandent comment calmer les tensions en acceptant les demandes non structurantes, sans pour autant produire un legacy data centrique qui va devenir de plus en plus couteux à comprendre et maintenir…

Et surtout, le concombre est désormais partout.

Il est dans chaque discussion, chaque problème d’équipe, chaque décision.

Les refinements ne sont plus que la revue de scénarios cucumber déjà écrits, qui introduisent des évolutions fonctionnelles cachés dans des renommages. Les questions des devs portent sur les scénarios plus que le fond 75% du temps. Les PO ne passent plus les tickets à DONE si le scénario cucumber n’est pas conforme à des attentes de forme. Cette valeur devrait être plutôt sur la ligne du dessus. Cette valeur bien que prouvant qu’une multiplication marche correctement n’est pas crédible avec la réalité. Je passe ¼ de mon temps avec chef de projet et scrum master pour trouver des solutions aux batailles humaines et techniques de la guerre cucumber.

Certains sprints vont jusqu’à 40% de capacité utilisé pour du formalisme de scénario (sans rien toucher au code métier) et pour s’aligner avec le MOM.

Le BDD n’est pas là. Mais les scénarios sont omniprésents. On ne livre plus de la valeur, on livre du Cucumber. On pense Cucumber, on rédige Cucumber, on présente Cucumber, on test en Cucumber,on valide Cucumber, on s’engueule Cucumber, on parle Cucumber au café… Cucumber, Cucumber, Cucumber, Cucumber, Cucumber …

Mais comment a-t-on pu en arriver là… ?

Je crois qu’en fait, ça y’est, on ne gère plus rien du tout…
Le concombre a pris le contrôle absolu… Et ce n’est plus une démocratie.

Comment avons-nous pu nous faire piéger dans une relation toxique sans le voir venir… ? Ce facilitateur de projet, dont la promesse est le pont dev / métier, censé aligner la compréhension métier, faciliter les échanges, livrer du code avec moins de bugs… Comment est-il devenu notre pire cauchemar compliquant tout ?

PROLOGUE : L’heure des regrets

Me voici dépité, empêtré dans une équipe maintenant gangrénée par les problèmes humains. Les POS eux même ne s’entendent plus entre eux… Certains PO ne veulent plus parler aux devs, et réciproquement.

Nous passons un temps fou à livrer de la mise en conformité Cucumber qui est maintenant inscrite dans la DOD. Au final, même le code est en danger… Danger de devenir une autre rénovation de SI jetable, couplé
au MOM. Une autre version mal fichue qui s’essoufflera rapidement…

J’en arrive à cette conclusion. BDD ne marche pas… Trop complexe… Trop de problèmes… Non, BDD ne marche pas !

Je repense alors à mes expériences passées…

Cette mission start up notamment… 15 Devs, 3 PO un CTO. Un code absolument spaghetti… TDD n’y était pas la norme, DDD y était simplement inconnu et BDD était rejeté, sa simple évocation donnait des boutons à tous (une tentative d’automatisation passé infructueuse avait laissé des marques).

Mais de la valeur qui coule à flot. On faisait tout tout seul du css jusqu’au cloud. D’ailleurs, on ne gérait pas un projet, mais un produit. Un produit qui gagnait du marché, qui générait des millions de CA, avec des millions d’utilisateurs. Qui embauchait 3 fois moins de gens mais qui délivrait 3 fois plus vite pour trois fois moins cher…

Comment faisait-on nos user storry lorsque le concombre n’était pas là ?

Le PO comprenait le métier, il provoquait un refinement en petit comité. Nous séchions ensemble la story entre DEV / QA / PO. Nous levions les ambiguïtés, challengeait les besoins, ébauchaient les solutions et le résultat n’étant jamais parfait, l’équipe avait cette culture de la collaboration en cours de développement entre PO /DEV et DEV / DEV. Pas de DOD formelle, pas de process résumés dans des CR de point émanant du chef. Une confiance réciproque en l’expertise de l’autre. De l’entraide et un but commun !

Et là je comprends… Sans n’avoir jamais prononcer le mot, sans jamais s’être prétendue digne héritier d’une bonne pratique, nous étions Agiles… Et nous pratiquions BDD l’automatisation en moins.

Nous appliquions les vrais fondamentaux les plus importants du BDD.

Finalement… Tout n’est peut-être pas que de la faute du concombre… Peut-être même que nous lui en avons trop demandé, le transformant en monstre… Quelle est notre responsabilité, nous les devs crafts dans ce fiasco… ?

L’intention était bonne. Répondre à un problème concret :

l’absence de possibilité de réaliser des tests manuels. Piocher dans la boite à bonne pratique : les tests fonctionnels Cucumber. Donc BDD.

L’erreur est évidente. Nous avons pris le troisième pilier de BDD, l’automatisation, et nous avons commencé par lui. Nous savions que BDD ne se résume pas à Cucumber, mais nous croyions que le reste en découlerait.

Alors que les fondamentaux n’étaient pas là. Alors que la culture de base agile et produit n’était pas là. Alors que les process, le projet, le mauvais Safe, le MOM et la politique dominaient. Alors que le système était trop gros pour le faire changer.
Nous avons foncé dans nos pratiques craft, convaincus d’apporter des bienfaits, sans nous rendre compte du fossé qui séparait notre client de ces pratiques, et de tous les blocages sur la route qui nous attendaient. Pire encore, les blocages sont tous apparus d’un coup et non au fur et à mesure de la conduite du changement. Du coup nous avons initié la dérive… Introduit l’élément perturbateur.

Nous avons été trop vite sans nous rendre compte de tous les implicites évidents pour nous qui n’étaient pas acquis par notre client. Nous sommes tombés dans le cliché des devs craft qui apportent la lumière avec des solutions théoriques et qui ne comprennent pas qu’elles ne peuvent pas fonctionner dans le contexte.

Conclusion : La Cerise, pas le Gâteau

C’est ce qu’on appelle le cargo culte.

A l’avenir, je me concentrerais sur ça. Le fond.
J’essaierai de participer à injecter du fond petit à petit dans l’amélioration continue. Bien sûr en gardant en tête mon référentiel de pratiques auquel je crois. Pour se rapprocher de BDD, je pousserai d’abord la coécriture des user storry, l’exploration commune du métier, la collaboration face à l’inconnu. Pousser à rapprocher Dev / QA / PO au plus tôt dans nos process. Je pousserai d’abord l’idée qu’une équipe qui fait du logiciel, ça marche mieux quand chacun respecte les compétences de l’autre et lui fait confiance. Et que bien sûr, ensuite, ils travaillent bras dessus bras dessous à égalité avec un unique but, livrer de la valeur à nos utilisateurs. Pas de chef, pas d’exécutants dans une dev team. Juste des passagers du même bateau qui rament ensemble pour aller plus loin.

Et si ça ne prend pas dans le système ou je suis, c’est que le système n’est pas prêt. Et qu’il vaut mieux qu’il fonctionne comme il sait le faire, même si je suis en désaccord profond avec toute son ADN.

Ne vaut-il finalement pas mieux un Cycle en V bien rodé qu’une façade de Scrum mal gérée et incomprise ? Bon peut être pas quand même… N’exagérons rien, mais vous voyez l’idée.

Pousser des pratiques sur un terreau qui n’est pas fertile n’amènera rien que des tensions, des incompréhensions, du malaise humain.

Et pousser une pratique par l’outillage, c’est l’échec assuré.
C’est ce que je retiendrai de cette triste expérience entre nous et le concombre. Mais promis, je le rappellerai un jour. Dans un autre contexte, on s’entendra surement mieux.