12.08 — Ocarina dans l’industrie du test#
Ocarina n’est pas un meilleur pytest, pas un meilleur Robot Framework, pas un meilleur Cypress. Il est structurellement ailleurs. Ce chapitre essaie d’expliquer le shift qu’il représente, et la longueur d’avance qu’il prend.
1. La cartographie actuelle de l’industrie#
Trois grandes familles d’outils e2e#
| Famille | Exemples | Modèle |
|---|---|---|
| DSL textuels | Robot Framework, Cucumber + Gherkin | Couche de traduction permanente entre texte et code |
| Plugins de runner | pytest-selenium, pytest-playwright, pytest-bdd | Greffés sur pytest, héritent de son lifecycle |
| Vendor SaaS | BrowserStack, Sauce Labs, LambdaTest, Cypress Dashboard | Test runner local + cloud d’exécution payant |
Trois grandes surfaces de friction communes#
| Friction | Manifestation |
|---|---|
| Marketing > Technique | Outils vendus sur démos, conferences et certifications orientées. La hype pilote l’adoption. |
| Vendor lock-in | Une fois adopté, refactor coûteux, prise d’otage. |
| Effort cognitif déplacé | Comprendre l’outil prend plus de temps que de faire son travail. |
2. Le pari technique d’Ocarina#
- Pas de DSL textuel → Python pur, embedded DSL.
- Pas de plugin pytest → runner intégré, fidélité ISTQB absolue.
- Pas d’
async/await→ simplicité, compatibilité Selenium synchrone, pas de « trucs de geeks ». - Pas de SaaS → tout en local, noyau dur très dense, boîte blanche.
Voir aussi : ../11-independence/03-explicit-refusals.md
Ces refus ne sont pas sans raison.
Chacun est justifié par un compromis explicite.
Enfin, leur conjonction produit une solution sans équivalent direct sur le marché.
3. Le shift qu’Ocarina représente#
Premier axe : revenir au vocabulaire du test (ISTQB)#
L’industrie e2e moderne a un vocabulaire mélangé : « fixture pytest », « step def Gherkin », etc. Aucun acteur métier (testeur fonctionnel certifié ISTQB) n’a ce vocabulaire en tête.
| ISTQB | Ocarina |
|---|---|
| Pas de test | act |
| Cas de test | Test |
| Suite de test | TestSuite |
| Campagne | TestCampaign |
| Cycle | TestCycle |
C’est un shift : le code devient lisible par un testeur fonctionnel.
Pas seulement par un développeur Python.
Deuxième axe : faire du typage strict une discipline métier#
Aucun framework e2e populaire n’a mypy strict = true comme prérequis.
Ocarina, si.
- Les erreurs sont attrapées avant l’exécution.
- Le DSL est renforcé par le compilateur (mélanger des POMs hétérogènes dans un
drive_pageest une erreur mypy, pas une erreur runtime). - La maintenance est extrêmement guidée (le type checker revérifie la cohérence après chaque changement).
C’est un shift : on déplace l’effort du moment où ça pète vers le moment où on l’écrit.
Troisième axe : faire de l’IA un client de première classe#
Ocarina expose activement vers les LLMs :
llms.txt,llms-full.txt.CLAUDE.md,CLAUDE.slim.md.- 40+ skills versionnés (
SKILL.md). - Une suite e2e entière co-écrite par Claude (
ocarina-with-ai-example).
Aucun framework de test concurrent n’a cette surface IA.
C’est un shift : on conçoit le DSL pour être consommable par l’IA et l’humain, pas juste par l’humain.
Quatrième axe : faire de la souveraineté grammaticale une promesse#
Ocarina ne fournit pas un DSL fixe. Il fournit :
ChainRunner[T]comme point d’extension.- Pattern « adapter projet » comme convention.
- Composition par closures plutôt qu’héritage.
→ Chaque projet écrit son propre framework au-dessus du framework (act, match_page, TestSuite adapter, TestCampaign adapter, EnvGetters).
C’est un shift : on rend la grammaire au projet, plutôt que d’entièrement la confier à l’outil.
4. Longueur d’avance#
Sur quoi Ocarina est en avance#
| Axe | Avance estimée vs l’industrie |
|---|---|
| Typage strict en e2e | 5-10 ans (la plupart des frameworks restent en Any partout) |
| IA-first | 2-5 ans (les autres commencent à exposer des MCP/AI hooks, bien qu’avec une approche discutable) |
| DSL embedded vs textuel | Permanent (différence philosophique, pas de rattrapage prévu) |
| Vocabulaire ISTQB | Permanent (différence philosophique) |
| Auditabilité (1 dep d’exécution) | Permanent (différence philosophique) |
| ROP comme cœur | 5-10 ans (la plupart utilisent des exceptions classiques) |
Sur quoi Ocarina n’est pas en avance#
| Axe | Réalité |
|---|---|
| Notoriété | Inexistant grand public. Audience cible : testeurs avancés. |
| Écosystème de plugins | Délibérément minimaliste. L’écosystème Python est l’un des plus énormes de l’industrie et peut être directement embarqué dans un projet Ocarina sans friction. |
| Cloud-as-a-service | Aucun (volontaire). En revanche, Ocarina est nativement pensé pour le scaling horizontal. |
| Multi-langage | Python uniquement (volontaire). |
Vision#
Ocarina part des hypothèses suivantes :
- Le marché va se déplacer vers moins de plateformes, plus de code propre, plus de développement interne. L’évolution Sanity → Markdown (Lee Robinson, Cursor, décembre 2025, confirmé par Sanity eux-mêmes dans leur réponse publique) en est un signal.
- L’IA va remplacer les frameworks à courbe d’apprentissage longue. Pourquoi apprendre Robot Framework si Claude peut écrire un test Python en 5 secondes ? C’est ce que l’auteur appelle une presse Juicero
- Les testeurs fonctionnels seront revalorisés parce qu’ils porteront la vision métier, pendant que l’IA portera la technique.
Si ces trois hypothèses se vérifient (et il y a des signaux qu’elles vont se vérifier), Ocarina est exactement à la bonne place.
Si elles ne se vérifient pas, Ocarina restera un projet de niche, mais l’auteur l’accepte explicitement (« C’est ma voiture »).
5. Le marché — analyse honnête#
Court terme (2026-2028)#
- Ocarina restera niche. Pas de tooling enterprise, pas de SLA, pas de support payant.
- Adoption par les consultants qui veulent un outil portable (« Ocarina dans sa poche »).
- Adoption par les testeurs fonctionnels qui veulent délivrer plutôt que de perdre leur temps avec des « trucs de geeks » interminables.
- Adoption par les solo dev / agences boutique qui écrivent leurs propres tests.
- Adoption par les équipes paranoïaques sécurité qui ne peuvent pas recourir à un SaaS.
Moyen terme (2028-2032)#
Trois scénarios :
Scénario A — Ocarina reste niche#
- 500-2000 utilisateurs.
- Communauté petite mais soudée.
- Pas d’influence sur le marché.
- L’auteur s’en fout complètement. L’aventure continue. Le code reste auditable.
Scénario B — Ocarina influence sans être adopté#
- Plus probable. Les idées d’Ocarina (typage strict en e2e, vocabulaire ISTQB, IA-first) se diffusent et sont reprises par des frameworks plus populaires.
- Ocarina n’est pas adopté massivement, mais devient la référence intellectuelle qu’on cite.
- Comme Hindley-Milner pour les langages de programmation : peu de gens l’écrivent en pratique, mais tous les langages modernes en sont héritiers.
Scénario C — Ocarina est adopté largement#
- Moins probable. Exige un événement déclencheur.
- Si ça arrive : Ocarina aura attendu son moment.
Long terme (2032+)#
Ocarina est conçu pour survivre à son auteur.
Le code est petit, audité, MIT. Il peut être forké, repris, maintenu par d’autres.
6. Comparaison qualitative avec quelques alternatives#
| Aspect | Ocarina | Robot Framework | Playwright | Cypress | Selenium IDE |
|---|---|---|---|---|---|
| DSL textuel | ❌ Python pur | ✅ .robot files | ❌ TS pur | ❌ JS pur | ✅ Steps file |
| Plugin runner | ❌ Runner interne | ❌ Runner interne | ✅ Jest/Mocha | ❌ Runner interne | (UI) |
| Typage strict (mypy/strict) | ✅ ALL | ❌ (Typage Python encore rare) | ⚠️ Support TS mais POMs souvent typés en any | ⚠️ JSDoc rare | ❌ |
| ROP | ✅ Central | ❌ Exceptions | ❌ Exceptions | ❌ Exceptions | ❌ |
| IA-first | ✅ documenté, technologie pensée pour depuis le départ | ❌ | ⚠️ Playwright CodeGen | ⚠️ AI tooling tiers | ❌ |
| Vocabulaire ISTQB | ✅ strict | ⚠️ partiel | ❌ Jest-like | ❌ describe/it | ❌ |
| Vendor lock-in | ❌ Aucun | ❌ Aucun | ⚠️ Microsoft | ⚠️ Cypress.io | ⚠️ Selenium project |
| Auditabilité | ✅ 1 dep d’exécution | ❌ Écosystème interne | ❌ Node deps massives | ❌ Cypress runtime | ⚠️ |
| Async/await | ❌ Refus | ❌ | ✅ Obligatoire | ✅ Obligatoire | ❌ |
| Parallélisation | ✅ ThreadPool + Sémaphore + Stratégie de parallélisation simple et personnalisable par l’utilisateur sans magie | ⚠️ pabot | ✅ Workers JS | ✅ Parallel CI | ❌ |
| Approche anti-flakiness native | ✅ Parallélisation + Clonage de tests + Analyse fine par IA | ❌ | ❌ | ❌ | ❌ |
7. Les valeurs qu’Ocarina porte#
Le code de test :
- doit être lisible par les testeurs fonctionnels (vocabulaire ISTQB)
- doit être un outil de communication inter-équipes avant tout (idem)
- doit être lisible par l’IA (typage strict + linter strict + grammaire bien définie)
- doit rester maintenable (séparation fond/forme très forte)
- doit être piloté par la stratégie de test sans compromis (batterie de skills énorme)
- doit être auditable et portable (une seule dep, MIT, copiable)
- n’a pas besoin d’une plateforme pour fonctionner
- n’a pas à réinventer la roue (retours aux fondamentaux)