01.01 — Prendre le problème à l’envers#

Le constat#

Tous les frameworks de test e2e contemporains ont été construits sur un postulat implicite : il existe une barrière entre ceux qui codent et ceux qui définissent les tests. Cette barrière est tenue pour acquise : méthodologiquement, organisationnellement, parfois contractuellement.

La plupart des frameworks de test ont été conçus dans un monde où la barrière entre « ceux qui codent » et « ceux qui définissent les tests » était réelle et structurelle.

Les deux réponses historiques à ce postulat sont citées nommément dans le Holy Book :

Robot Framework#

Robot Framework a essayé de la contourner avec un DSL (Domain Specific Language), incluant leur propre format et leur propre écosystème de plugins. Ainsi, RF impose de-facto ses propres standards : c’est le coût immédiat de sa promesse.

Mécanique : on remplace la complexité du code par la complexité d’un autre code. Le ticket d’entrée n’est pas annulé, il est déplacé. Désormais on doit apprendre la syntaxe RF, son écosystème de librairies et de ressources, sa façon d’orchestrer.

Cucumber#

Cucumber a essayé avec le Gherkin : un langage « naturel » qui, en pratique, contraint tout le monde sans vraiment libérer personne. Coût : couche de traduction permanente, désynchronisation Gherkin/code.

Mécanique : on construit une illusion de langage naturel, qui a en réalité une grammaire stricte et une sémantique limitée. Le coût n’est pas le langage en lui-même mais la couche de traduction permanente entre le Gherkin et le code Step Definitions, qui dérive dans le temps si elle n’est pas surveillée.

Le pari opposé#

Plutôt que de déguiser la barrière, Ocarina parie qu’elle va disparaître :

Ocarina parie sur le contraire : cette barrière va disparaître. Il s’agit d’un non-débat sur lequel tout le monde s’est construit un nœud autour du cou. Outils honteusement compliqués, vendus comme « solutions ». Impact : désastre opérationnel dès lors que l’on a un besoin qui ne peut pas s’exprimer dans un « cadre » qui n’est PAS réellement générique.

Et :

Et le pire : toutes ces technologies continueront d’évoluer dans ce sens. AUCUNE d’entre elle ne prendra ce shift, puisqu’il s’agit d’un changement de paradigme et d’un retour aux fondamentaux qui contredit totalement leur proposition de valeur.

L’IA est le pont, pas le DSL#

Le verrou rhétorique du Holy Book sur ce point :

Avec l’IA, et des outils comme Claude Code, ce pari devient chaque jour plus solide. Le pont entre techniques et non-techniques n’est plus une couche d’abstraction.

C’est l’IA elle-même. IA qui travaille sur de la donnée brute.

Conséquences observables dans le code :

L’incarnation pratique est le dépôt ocarina-with-ai-example : une suite e2e réelle, écrite à 99% par Claude Code, mais dont l’intelligence est partagée à hauteur de 50-50 entre l’auteur et l’IA.

Le coût de la « créativité » des autres#

Le Holy Book formalise pourquoi le nivellement par DSL n’est pas neutre :

Le coût le plus important est un nivellement par le bas, la réduction des options et une « flexibilité » qui s’obtient en se battant contre des outils plutôt que d’utiliser des solutions.

Pourtant, ce qu’il nous reste à présent, c’est le besoin d’un code de test lisible, traçable et flexible, sous sa forme la plus brute.

Le mot brute est important : il revient ailleurs (« données brutes », « la donnée brute »), et c’est l’axe sur lequel le projet se prolonge vers l’IA. Voir 05-political-stance.md, section « Anti No-Code ».

Conséquences sur l’architecture d’Ocarina#