CabraFlow · De la démo commentée au test automatisé, en conception

Sélecteurs morts & scripts jetables

Les enregistreurs traditionnels figent des chemins CSS ou XPath. Au moindre changement de DOM, d'identifiant ou de mise en page, les tests cassent, et le temps passe à les réparer au lieu de valider l'application.

Fracture entre le métier et le code

Écrire du Playwright pur, ou tout autre framework de test en TypeScript, demande des compétences de développement. Les experts fonctionnels, qui connaissent la logique métier, ne peuvent ni écrire ni relire ces tests.

Formats fermés & licences par poste

Les suites de test propriétaires conservent souvent les tests dans des formats fermés, difficiles à versionner dans Git et à reprendre dans un autre outil, avec des licences facturées par poste.

Capture par la voix et le geste

Le mode visé produirait un test automatisé par la voix : vous navigueriez en commentant vos actions, et le flow s'écrirait au fil de la démonstration. La transcription serait locale (le moteur Whisper est envisagé). Ce mode ne sera construit qu'après un essai chiffré.

Arbre d'accessibilité

Les cibles seraient résolues par leurs rôles et noms accessibles, comme les perçoit un lecteur d'écran, avec les localisateurs orientés utilisateur de Playwright. Le langage de test est conçu sans sélecteur CSS ni XPath.

Micro-phrases métier

Le langage visible serait fait des mots de votre organisation (« Valider la commande urgente »), créés pendant la capture, jamais d'un vocabulaire d'outil ni de code.

Rejeu sur trois cibles

Un même flow YAML est conçu pour s'exécuter sur un runner natif et s'exporter en script Playwright (.spec.ts) ou en suite Robot Framework (.robot). Le fichier YAML resterait l'unique source.

Export documentaire ISTQB

Le même flow produirait une spécification de cas de test (étapes, résultats attendus, traçabilité par tags), régénérée depuis la source plutôt que réécrite à la main.

Local par conception

L'inférence du mode vocal est prévue entièrement locale, sans API cloud : la voix et les données d'écran resteraient sur votre poste. Sans carte graphique, un mode « voix différée » est prévu.

Démonstration vocale

Il ouvrirait l'application et parlerait naturellement (« Je sélectionne le profil client puis je valide le devis ») ; les blocs de mots-clés s'ajouteraient au fil de la navigation. Prévu en phase 4, après un essai chiffré.

Studio graphique

Il assemblerait et paramétrerait les micro-phrases métier dans un studio visuel : variables typées, jeux de données, essai isolé d'un mot-clé. Prévu en phase 3.

Fichier texte & Git

Il éditerait le fichier YAML dans son éditeur, avec une autocomplétion fournie par un schéma JSON, et pourrait consulter le code Playwright généré. Prévu dès la phase 1, la première étape exécutable.

Philosophie technique

Ni fork, ni réinvention

CabraFlow est conçu comme un orchestrateur au-dessus de Playwright, pas comme un fork. Il reprendrait de Robot Framework le principe keyword-driven et la composition, de Playwright le moteur d'exécution et les localisateurs orientés utilisateur.

Les flows sont conçus pour s'exporter vers Playwright ou Robot Framework, afin qu'une équipe ne dépende pas d'un format propre à CabraFlow.

Engagement de rigueur

Où en est le programme R&D

Au 6 octobre 2026, CabraFlow est en phase 0 : six spécifications rédigées le 12 août 2026 (vision, architecture, langage de mots-clés, mode vocal, plan de réalisation, design du studio). Aucune ligne de code, aucun prototype, aucune démonstration.

Nous décrivons l'état réel, au présent de la phase en cours : aucun chiffre de performance n'est annoncé avant d'avoir été mesuré, et rien ne sera montré avant que la phase 1 soit exécutable.

Les spécifications

Six spécifications rédigées le 12 août 2026. Restent à poser le dépôt de code et l'intégration continue, puis à choisir le nom de paquet.

Le cœur exécutable

Un moteur en ligne de commande qui exécute un flow YAML sur une petite application de démonstration locale, sans aucun sélecteur dans les tests. Critère de sortie : un profil technico-fonctionnel écrit un flow avec autocomplétion et l'exécute. C'est la condition de toute première démonstration.

Agents MCP et réparation

Exposition de la boucle aux agents par MCP, export Playwright (.spec.ts) et réparation proposée sur échec, toujours signalée dans le rapport, jamais un test vert en silence.

Le studio graphique

Une application de bureau pour assembler les micro-phrases métier en blocs, synchronisés avec le fichier YAML, avec un exécuteur intégré. Le studio de cette phase n'aura pas le mode vocal.

Le mode vocal, après un essai chiffré

D'abord un essai sur dix démonstrations commentées enregistrées. Le mode vocal ne sera intégré que si plus de 85 % des étapes sont correctes sans correction manuelle et si la latence perçue reste sous 2 s. Ces seuils n'ont pas encore été mesurés.

Écosystème

Export Robot Framework (.robot), export documentaire ISTQB, exécution en intégration continue et bibliothèques de mots-clés partageables.