Gherkin : et pourquoi pas en français ?

Pour une part importante des développeurs, la question d’écrire les Gherkins dans une autre langue que l’anglais ne se pose pas. Pour rappel, Gherkin est une syntaxe qu’utilise Cucumber pour aider à la rédaction de tests de façon fonctionnelle. Cela permet d’écrire des tests en langage naturel et donc d’inclure plus facilement le PO dans la rédaction des tests d’acceptation. Par tests d'acceptation, je parle de tests permettant de définir les différents scénarios auxquels doit répondre la nouvelle fonctionnalité. Ces tests permettent notamment d’aider les nouveaux développeurs à plus facilement comprendre les fonctionnalités du projet.

Exemple :

Scenario: Breaker guesses a word
  Given the Maker has chosen a word
  When the Breaker makes a guess
  Then the Maker is asked to score

Pour plus d’informations je vous invite à lire cet autre article : https://blog.ippon.fr/2020/08/31/cucumber-et-resttemplate/

Cependant, n’est-il pas parfois bénéfique de sortir de l’anglais ? Pourquoi ne pas utiliser ce que Gherkin nous propose, à savoir la possibilité d’utiliser le français ? Au travers de cet article, nous allons donc discuter de cette possibilité et voir ce que les Gherkins français peuvent apporter à un projet. Je m’appuierai notamment sur mon expérience lors d’une de mes missions dans une banque traitant de la collecte et de la mise à disposition de justificatifs d'identité.

En informatique, le premier réflexe est d’écrire les Gherkins en anglais qui est la langue s’étant imposée dans notre secteur. En effet, le code, la documentation et les forums sont en grande majorité écrits en anglais. D’un point de vue opérationnel, en cas de délocalisation du travail vers un autre pays, il ne faut pas non plus que le temps et les ressources investis sur le projet soient perdus. C’est donc naturellement que les développeurs français tendent très majoritairement vers l’écriture de ces Gherkins en anglais.

Cependant, l’universalité de la langue anglaise se heurte à la pratique. De mon expérience,  le niveau d’anglais global des français est faible et cette tendance impacte de facto notre métier. Si le langage technique est globalement bien intégré, le niveau baisse lorsque nous en sortons. Ces lacunes peuvent alors conduire à des approximations ou même des erreurs dans le projet. Si vous travaillez avec une équipe française, les spécifications, la documentation fonctionnelle et les tests d'acceptation soumis seront généralement pensés et exprimés en français. L’ensemble des échanges au sein de l’équipe et avec le client le seront également. Transcrire ces informations en anglais peut alors être à la source d’approximations. Lors de la traduction de termes fonctionnels d’une langue vers l’autre, certaines subtilités peuvent ainsi se perdre et compliquer la compréhension des Gherkins.

Outre les erreurs d’orthographe ou les faux-amis, un mot peut ne pas avoir de réel équivalent en anglais. C’est notamment le cas des acronymes. Je peux prendre l’exemple de l’acronyme IUP que l’on utilise souvent au sein de mon projet. Il signifie “Identifiant Unique Personne” et devrait donc être traduit UPI, “Unique Person Identifier”. Il a été fait le choix de ne pas traduire cet acronyme en anglais pour s’assurer que tous les membres de l’équipe, actuels ou futurs, le comprennent sans souci. Ce choix, s’il facilite la compréhension, crée pourtant un décalage (un terme français au milieu de Gherkins anglais).

Garder la même langue, de la formulation du besoin à sa traduction fonctionnelle, pourrait aider à résoudre ce type de problèmes. L’usage de Gherkins français pourrait permettre de mieux coller aux spécifications et même de réutiliser les tests d’acceptation qui sont souvent sous la forme suivante :

Étant donné un client créant un compte en fournissant une ou plusieurs pièces d’Identité
Quand l'événement de création de compte est reçu
Alors les informations concernant la ou les pièces fournies de l'événement sont enregistrées
Et l’utilisateur ne sera donc plus sollicitable

La conversion en Gherkin français est quasiment automatique :

On a alors un test collant directement au vocabulaire utilisé dans les spécifications et dans les discussions que l’on peut avoir avec le métier, sans déperdition d’informations due à une mauvaise traduction. L’introduction au projet d’un nouvel intervenant, qu’il soit développeur, PO ou BA, est donc d’autant plus simple. L’usage des Gherkins français peut ainsi avoir des avantages, d’autant plus qu’il n’influence en rien la langue utilisée dans le code implémentant le comportement. On peut très bien avoir :

@ÉtantDonné(“un client {string} créant un compte en fournissant {int} pièce d’identité”)
public void aClientWithIds(String customer, int ids) {
  /* Code */
}

A mon avis, la pratique actuelle et l’usage quasi-universel de Gherkins en anglais, y compris dans le cadre de projets franco-français, gagnerait à être remis en question au début de chaque projet utilisant Cucumber. Il ne faut pas s’interdire d’écrire ses Gherkins en français au nom du fait que ça fasse partie du projet. Si la documentation fonctionnelle est entièrement écrite en français, les Gherkins, étant un prolongement de cette documentation, n’ont aucune raison d’être en anglais.

Il n’en sera bien sûr pas de même si vous travaillez sur un projet potentiellement international, le français étant alors à proscrire. Dans ce cas la question ne se posera pas car les spécifications et le vocabulaire sont déjà, en partie au moins, en anglais.

Les Gherkins doivent permettre une meilleure compréhension entre métier et technique. Il serait donc dommage d’utiliser l’anglais par défaut s’il empêche d’atteindre cet objectif. Si au lancement d’un nouveau projet, nos équipes s’interrogent sur le choix d’une technologie par rapport à une autre (choix de la base de données, choix du langage…), pourquoi ne pas faire de même avec la langue des Gherkins ?

A partir de là, nous pouvons nous poser la question du langage utilisé dans le domaine. Le code devant être au plus proche du métier, le français n’est peut être pas à bannir.