Foire aux questions · Ce qu'on nous demande le plus souvent

SAPFX (paquet PyPI robotframework-sapfx, version 0.8.5 publiée le 13 octobre 2026) est un écosystème open source pour Robot Framework qui pilote SAP par trois bibliothèques : SapEccLibrary pour SAP GUI pour Windows, SapFioriLibrary pour les applications SAP Fiori, SAPUI5 et SAP GUI for HTML (au-dessus de Playwright) et SapApiLibrary pour OData et RFC/BAPI. Il sert d'abord à automatiser des tests SAP : les tests s'écrivent en langage métier, sans identifiant technique, et un même test peut traverser plusieurs canaux. Parce qu'il sait aussi écrire, supprimer et recouper ce qu'il écrit par un second canal, il s'ouvre à d'autres usages (jeux de données, bases à garnir pour les tests de performance, paramétrage et migration de données), présentés comme un cap et non comme des fonctions livrées. Licence Apache 2.0. La page « SAPFX en images » montre des captures prises en direct et des extraits de suites validées ; le film « The SAPFX mindset » (11 min 11, en anglais, sous-titré en français) en résume l'état d'esprit en sept principes.

Publiée sur PyPI le 13 octobre 2026, elle apporte des capacités éprouvées du 7 au 13 octobre 2026 sur S/4HANA 1909 et ABAP Platform 2023 : une politique de session qui décide avant tout geste d'écriture (lecture seule, exploration, complet) avec une piste d'audit ; l'approbation d'une écriture par un humain, liée à une cible ; un verdict GO ou NO-GO calculé sur le fichier de résultats d'un run ; la vérification du certificat SSL déclaré dans STRUST et de celui que l'ICM sert réellement ; des utilisateurs et rôles de test créés puis supprimés par RFC ; la supervision du journal d'erreurs de la Gateway ; l'analyse d'impact d'un transport ; la nature d'un service OData prouvée par ses marqueurs, le mode Espaces et Pages du launchpad et les échecs d'autorisation lus dans SU53. Chiffres de la 0.8.5 : 442 keywords, chacun avec un exemple d'utilisation, 3 959 tests unitaires, 462 scénarios joués en direct. Détail sur la page SAPFX.

Oui. SAPFX est publié sous licence Apache 2.0 : aucune licence à payer, quel que soit le nombre d'utilisateurs ou de postes d'exécution, usage commercial compris. Le code source est public sur GitHub (CyrilM29/robotframework-sapfx), le paquet s'installe depuis PyPI, sans verrouillage éditeur. AI Cabra propose sur devis des prestations d'accompagnement, de migration et de formation.

Trois canaux : le SAP GUI desktop (ECC, S/4HANA, via l'API SAP GUI Scripting), le web Fiori/SAPUI5 (compatibilité prouvée d'UI5 1.71 à 2.0, y compris SAP GUI for HTML) et l'API (OData v2 et v4, RFC en option). Un même fait métier peut être vérifié par deux canaux indépendants dans la même suite de tests.

Il a été conçu pour tester, et c'est son cœur. Mais ce qui le rend fiable pour tester (écrire une donnée, la relire par un second canal indépendant, l'écran d'un côté et l'API de l'autre, la supprimer et constater qu'elle a disparu) sert aussi à d'autres usages : générer des jeux de données pour les campagnes de test, garnir des bases SAP vides ou incomplètes avant des tests de performance, charger des données de paramétrage ou sécuriser l'injection de données dans une migration, par exemple d'ECC vers S/4HANA. Pour être précis sur l'état : l'écriture, la suppression et le contrôle croisé sont validés en direct sur des systèmes SAP de développement ; le générateur de jeux de données, les volumes de performance et les chargements de migration sont un cap, pas des fonctions livrées, et aucune migration n'a encore été jouée. Sur un système client, chaque cible se traite au cas par cas, en privilégiant la réversibilité.

Sur le périmètre qu'il couvre (SAP GUI, SAP Fiori, WebGUI, OData et RFC, auto-réparation journalisée des localisateurs), SAPFX répond au même besoin que les suites de test commerciales du marché, qui sont vendues sous licence. Ce que ces suites apportent et que SAPFX n'a pas : un support éditeur et un éditeur graphique. Les tests SAPFX s'écrivent en keywords lisibles sans programmer. L'angle de SAPFX est l'absence de licence, la pérennité et l'ouverture (Apache 2.0, Robot Framework standard), pas une critique de leur qualité.

Les bibliothèques ouvertes les plus répandues couvrent chacune un seul canal : le SAP GUI desktop pour l'une, le web UI5 hors Robot Framework pour l'autre. SAPFX couvre les trois canaux dans Robot Framework, avec un seul rapport unifié. Les localisateurs par libellé, popularisés par la bibliothèque dédiée au SAP GUI, existent aussi dans SAPFX (filiation Apache 2.0 assumée), avec une différence de contrat : une ambiguïté est toujours signalée avec la liste des candidats, jamais résolue en silence.

Quatre mécanismes : les tests ne contiennent aucun identifiant technique (les localisateurs vivent dans une couche de ressources séparée) ; les attentes se calent sur l'état réel de SAP, jamais sur des pauses fixes ; les assertions lisent le type de message, pas le texte localisé ; et l'auto-réparation des localisateurs journalise chaque réparation, jamais en silence.

Cinq agents IA planifient, génèrent, réparent, vérifient et documentent les tests en pilotant le vrai système SAP par MCP (serveur rf-mcp et plugins SAPFX). Chaque étape générée est exécutée en direct avant d'être écrite, et l'agent de réparation corrige la couche de ressources, jamais les tests. Rien n'est silencieux : un humain relit, les réparations sont journalisées. Avant d'écrire dans SAP, un agent peut être soumis à l'approbation d'un humain (outil MCP sapfx_approve_write de l'atelier, adossé à la politique de session des bibliothèques, publiée en 0.8.5), et Prompt Eval note la demande de test avant que les agents ne dépensent leurs tokens. Ces agents font partie de l'atelier SAPFX, pas du paquet PyPI ; la suite qu'ils produisent se rejoue avec Robot Framework seul, sans agent.

pip install robotframework-sapfx (Python 3.10 ou plus, Robot Framework 7.4 ou plus). La partie SAP Fiori s'essaie sans système SAP, sur le Demo Kit OpenUI5 public ou une application SAP Fiori Elements servie en local ; SAP GUI et les API se valident contre l'image Docker gratuite d'ABAP Platform Trial. Consultez notre Guide de démarrage, et la page « SAPFX en images » pour voir des tests réels.

D'un environnement Python 3.10 ou plus avec Robot Framework 7.4 ou plus, puis du paquet robotframework-sapfx depuis PyPI ; pour SAP Fiori, l'extra robotframework-sapfx[web] ajoute la bibliothèque Browser (Playwright), et le canal RFC, optionnel, demande pyrfc. Pour le canal SAP GUI, une condition s'ajoute : SAP GUI Scripting doit être activé, côté serveur et côté poste client. C'est en général la première étape d'un projet et elle relève de votre équipe Basis. Les canaux Fiori et API n'ont pas cette contrainte.

Oui, avec une nuance selon le canal. Les tests Fiori et API s'exécutent partout, y compris sur un agent Linux headless. Les tests SAP GUI ont besoin d'un agent Windows où SAP GUI est installé : c'est une contrainte de SAP GUI Scripting, pas de SAPFX. En pratique, on fait tourner les deux familles sur deux agents différents dans la même chaîne.

Nous le maintenons, et le code est sous licence Apache 2.0 sur GitHub. C'est justement la réponse à la question : vous pouvez le récupérer, le forker et le faire vivre sans demander d'autorisation à personne. À la version 0.8.5, publiée sur PyPI le 13 octobre 2026, le projet embarque 3 959 tests unitaires rejoués hors SAP en intégration continue, 462 scénarios joués en direct sur 4 systèmes SAP réels (campagnes du 12 juillet au 13 octobre 2026) et 95 % de couverture de code mesurée en intégration continue, avec un plancher de 85 % imposé. C'est ce filet qui rend une reprise réaliste.

La maintenance standard de SAP Solution Manager 7.2, qui porte CBTA, s'arrête le 31 décembre 2027 (note SAP 3585220). SAP oriente ses clients vers SAP Cloud ALM, qui gère et suit les tests ; leur exécution automatisée passe par des outils qui s'y raccordent. Les scénarios CBTA existants doivent donc être repris dans un autre outil. SAPFX est une voie ouverte, sans licence : les scénarios se réécrivent en Robot Framework, sur SAP GUI, SAP Fiori et les API, et un guide de migration depuis CBTA accompagne les bibliothèques. La réécriture reste un travail, que nous pouvons accompagner sur devis, directement ou avec des partenaires spécialisés.

Cinq agents, chacun borné à un rôle, travaillent sur le système SAP réel par le serveur MCP rf-mcp et les plugins SAPFX, sous contrôle humain : sap-planner confronte la demande au système réel, perçu écran par écran, et écrit un plan observé dans specs/ ; sap-generator exécute chaque étape sur le système avant de l'écrire dans la suite .robot, scellée par l'empreinte de son plan ; sap-healer répare la couche resources/, jamais le test ni ses assertions, chaque diagnostic consigné ; sap-verifier fait une revue indépendante en lecture seule contre l'invariant métier et les preuves ; sap-istqb structure les plans et cas de test d'après l'ISTQB et l'ISO/IEC/IEEE 29119-3, avec un bloc de rejeu, et revoit la conception de chaque suite générée. Ils font partie de l'atelier SAPFX, pas du paquet PyPI.

Dix outils, réunis dans l'atelier SAPFX, en option et délivrés sur devis (ils ne sont ni dans le paquet PyPI ni dans le dépôt public) : un enregistreur SAP GUI et un enregistreur web pour SAP Fiori et le WebGUI ; Prompt Eval, qui note une demande de test avant de la confier aux agents ; cinq agents IA et leur cadre (contrat de mission, hook de permissions, fil de reprise) ; le pont MCP (trois plugins rf-mcp et la surcouche sapfx-mcp, dont l'approbation par un humain d'une écriture sur SAP) ; la maintenance préventive ; la cartographie des interfaces d'un système SAP (relevé par RFC en lecture seule, planches A3, rapport et preuves capturées dans SAP GUI) ; une couche métier d'exemple ; un pack de déploiement Windows. Ce qu'ils produisent reste du Robot Framework ordinaire, qui tourne sans eux. Détail sur la page des outils de l'atelier.

Avec Prompt Eval, l'outil de l'atelier SAPFX ajouté le 10 octobre 2026. Une demande de test confiée aux agents est un prompt, et la traiter de bout en bout coûte de l'ordre de deux millions de tokens d'agents sur nos campagnes. Prompt Eval la note avant : sa forme et sa part de gabarit sont vérifiées sans appel à un modèle ; huit critères (intention, faits contre hypothèses, niveau de preuve, assertion, cible, répétabilité, capacités, posture) sont jugés par un modèle de langage, servi en local par défaut et noté zéro s'il ne répond pas ; une sonde RFC en lecture seule vérifie que les transactions, tables et modules fonction nommés existent sur le système cible. La note mesure la rédaction, pas le coût, et « jouable » ne dispense pas de l'exploration sur le système. Voir Prompt Eval.

Ils vérifient les bibliothèques contre des doubles locaux : de faux objets COM à la place de SAP GUI, des doublures du navigateur et des canaux HTTP et RFC, et la logique pure testée seule. Ils tournent en intégration continue sans système SAP ni licence utilisateur, et mesurent 95 % de couverture de code (plancher de 85 % imposé en CI). Cette couverture ne garantit pas l'absence de défaut métier : elle est complétée par 462 scénarios joués en direct sur quatre systèmes SAP réels.

rf-test-agents, version 1.0.0, est une solution libre sous Apache 2.0 pour les tests Robot Framework. Cinq agents spécialisés planifient, génèrent, réparent, vérifient et documentent les tests en appliquant la méthode STDD. Les gardes logiciels vérifient les conventions et la provenance des tests ; ils ne mesurent pas la qualité générale des modèles. Le dépôt compte 310 tests unitaires, tous réussis en CI le 5 octobre 2026. Cette V1 disponible est distincte de CabraMesh, nos travaux V2 d’architecture agentique encore en recherche. Découvrir CabraMesh : ingénierie agentique V2.

Agent Contract v1 décompose le cycle de test en 5 rôles étanches pour éliminer tout conflit d'intérêts : rf-planner cartographie et spécifie les tests (fichiers specs/) avec traçabilité ISTQB ; rf-generator pilote l'application vivante pas-à-pas avant toute inscription de code ; rf-healer répare chirurgicalement les locateurs dans resources/page_objects/ sans jamais modifier le corps du test ; rf-verifier audite en lecture seule la rigueur des assertions ; et rf-istqb génère la documentation ISO/IEC/IEEE 29119-3 et les matrices de traçabilité hors ligne.

La règle d'or absolue de rf-generator est : aucun mot-clé ni scénario .robot n'est consigné dans le code sans avoir été préalablement exécuté avec succès en direct sur l'application cible. Connecté via le serveur MCP rf-mcp (RobotMCP), l'agent opère selon la boucle déterministe percevoir → agir → percevoir. Il vérifie l'état du DOM ou du système après chaque action, éliminant ainsi toute hallucination de sélecteur ou de comportement applicatif.

Pour préserver l'intégrité de la détection de bugs, le champ d'action de rf-healer est strictement borné à la couche d'automatisation (resources/page_objects/). Il lui est formellement interdit de toucher aux fichiers de test tests/, de supprimer une étape ou d'affaiblir une assertion métier. Si un sélecteur a changé par restylage technique, il le recalibre et consigne la modification dans docs/heal-journal.md. Si le parcours fonctionnel lui-même a changé, il échoue volontairement et passe la main à rf-planner pour révision humaine.

Les consignes textuelles données à une IA sont sujettes à l'oubli et aux dérives stochastiques. rf-test-agents applique 4 gardes mécaniques déterministes, exécutés en CI à chaque push et par un hook d'édition de Claude Code : check_spec_sync.py (garde de provenance SHA256 liant chaque test à sa spec approuvée), check_conventions.py (rejet strict des sélecteurs CSS/XPath bruts et interdiction absolue de Sleep), check_guidance_sync.py (vérifie que les conventions de CLAUDE.md sont reprises dans les définitions d'agents) et check_no_em_dash.py (neutralité de style). Si un garde échoue, la CI échoue ; dans Claude Code, seul check_conventions.py bloque l'édition. La synchronisation des définitions d'agents entre Claude Code et GitHub Copilot est contrôlée à part, par regen_agent_definitions.py --check.

Ces trois piliers forment un écosystème cohérent et sans dépendance propriétaire : rf-test-agents fournit l'architecture multi-agents universelle et les gardes mécaniques pour tout projet Robot Framework (web, API, mobile) ; SAPFX spécialise cette approche pour l'ERP critique (SAP GUI, Fiori, API OData / RFC avec canal RFC pleinement opérationnel) avec ses propres 5 agents (serveur MCP rf-mcp et plugins SAPFX) ; et CabrIA, programme de R&D, vise à apporter le cerveau souverain (modèle MoE 35B, entraînement local prévu, RAG hybride FastMCP qa-brain déjà en service) pour piloter ces agents 100 % on-premise ou en cloud souverain (France, UE), sans faire transiter la moindre donnée hors de votre périmètre.

Le Spec-Test-Driven Development (STDD) est l'état d'esprit commun de rf-test-agents, de SAPFX et d'ODOOFX. Trois maillons, chacun pilotant le suivant. La spécification d'abord : une vision d'ensemble en langage humain, structurée ou non (objectif métier, user story, scénario BDD, cas de test existant), que le planner confronte au système vivant pour en écrire la version observée dans specs/, relue par un humain : c'est la source de vérité. Le test ensuite : généré depuis cette spécification, chaque étape exécutée en direct avant d'être écrite, la suite scellée par l'empreinte SHA256 de son plan, et un plan modifié sans régénération fait échouer le garde. Le développement enfin : ce que le test exige et que la bibliothèque ne sait pas encore faire devient un keyword de la bibliothèque, jamais un contournement dans une suite. Le healer répare la couche resources/, jamais le test, et un flux métier qui change renvoie à la spécification. Ce qui distingue le STDD : la spécification s'écrit en langage humain, sous n'importe quelle forme (le BDD en est une) ; sa version qui fait foi est observée sur le système réel et gardée mécaniquement ; et elle pilote aussi le code d'automatisation.

STDD est une méthode qui utilise des agents, pas une architecture agentique. rf-test-agents V1.0.0 est l’outillage libre sous Apache 2.0 qui l’applique. CabraMesh désigne nos travaux V2 en ingénierie agentique : rôles délimités, modèles locaux adaptés aux tâches, actions encadrées et preuves vérifiables. CabraMesh reste en recherche ; aucun déploiement ni gain mesuré n’est revendiqué. Découvrir CabraMesh : ingénierie agentique V2.

Lu à l'aune de TDD. Le STDD garde la logique de TDD et la déplace d'une brique. TDD, c'est rouge, vert, refactor : le test d'abord, il échoue, puis le code le fait passer. En STDD, la première brique est la spec, et une spec est verte par défaut, en théorie : on l'écrit, on la croit, personne ne l'exécute, donc rien ne peut la faire échouer. Le STDD la met à l'épreuve du système réel : rouge là où le système la réfute, verte une fois observée, et seulement ensuite viennent le test et le code.

Le film STDD le montre en images : chapitre « De TDD à STDD », à 1:00 (8 min 34 en tout, en anglais, sous-titré en français).

Non. Le STDD est une méthode qui utilise des agents : elle met la spécification à l'épreuve du système réel avant d'écrire le test et le code. rf-test-agents (version 1.0.0, Apache 2.0) est l'outillage libre qui l'applique à Robot Framework. L'ingénierie agentique traite une autre question : comment organiser les rôles, les autorisations, l'exécution et la vérification d'agents qui agissent. C'est le chantier de CabraMesh, nos travaux V2, encore en recherche. Découvrir rf-test-agents · Découvrir CabraMesh.

CabraMesh est le nom de nos travaux V2 en ingénierie agentique : une architecture locale qui vise à faire agir des agents dans un cadre maîtrisé, sous contrôle humain, en appuyant chaque conclusion sur des preuves. Ses lignes directrices : des rôles spécialisés aux contextes délimités, des modèles qualifiés par tâche, une exécution encadrée par des contrôles déterministes et des preuves qui vont au-delà du verdict de l'agent. CabraMesh reste en recherche : aucun déploiement ni gain mesuré n'est revendiqué, ses mécanismes internes ne sont pas décrits publiquement et il ne fait l'objet d'aucun dépôt public. La V1 disponible en libre est rf-test-agents (version 1.0.0, Apache 2.0). Découvrir CabraMesh.

ODOOFX est la verticale Odoo d'AI Cabra : une bibliothèque Robot Framework open source (Apache 2.0) pour tester Odoo Community et Enterprise par trois canaux, l'interface web (Browser / Playwright), l'API RPC (XML-RPC jusqu'à Odoo 18, API JSON-2 à partir d'Odoo 19) et l'introspection ORM. Cinq agents (odoo-planner, odoo-generator, odoo-healer, odoo-istqb, odoo-verifier) y appliquent le Spec-Test-Driven Development défini dans rf-test-agents, comme SAPFX le fait pour SAP. La version 0.2.0 est publiée sur PyPI depuis le 13 octobre 2026 (pip install robotframework-odoofx) : ses canaux RPC et web sont éprouvés en direct sur Odoo 16 et 19 par 117 tests, le client web couvre la connexion, la navigation, la lecture des vues, la saisie et l'enregistrement de formulaires et les boutons d'action (les assistants, les lignes de section et de note et la suppression de ligne restent à couvrir) et aucun résultat sur une instance client n'est revendiqué. Le code est public sur GitHub (CyrilM29/robotframework-odoofx), la documentation des keywords est en ligne et le projet est présenté sur la page ODOOFX.

AI Cabra développe des solutions d'automatisation QA propulsées par l'IA qui combinent machine learning, vision par ordinateur, NLP et LLM pour détecter les bugs plus tôt, générer automatiquement des cas de test et optimiser vos cycles CI/CD. Nous intervenons en conseil architectural, audit de maturité, accompagnement ou orientation vers des partenaires pour vos migrations de suites legacy, et support expert niveau 3.

Des coûts QA réduits par rapport aux solutions propriétaires (aucune licence), une couverture de test accrue, des applications plus fiables et une intégration fluide dans vos workflows CI/CD. Les gains dépendent de votre contexte : nous les chiffrons avec vous lors d'un projet pilote plutôt que d'avancer un pourcentage générique sans engagement.

Non. Nous outillons une équipe, nous ne la remplaçons pas. Les tests que nous produisons sont écrits en langage métier, précisément pour que vos testeurs fonctionnels les lisent, les critiquent et les fassent évoluer sans repasser par nous. L'IA propose, la personne qui connaît le métier valide.

Oui. Notre expertise couvre l'intégration de LLM avec RAG (Retrieval-Augmented Generation), le fine-tuning de modèles IA pour la QA, l'ingénierie de prompts avancée et le développement d'agents IA intelligents pour accélérer la détection de bugs et la génération de cas de test.

Le RAG (Retrieval-Augmented Generation) combine recherche documentaire et génération pour donner des réponses précises et à jour. Nous l'utilisons pour exploiter votre base de tests, spécifications et tickets afin d'orienter les validations et les rapports de QA.

Oui, 100% conformes RGPD. Nos modèles IA sont déployés on-premise sur votre infrastructure ou en cloud souverain (France, UE). Aucune donnée sensible ne quitte vos serveurs. Nous adaptons le déploiement à vos exigences de sécurité : chiffrement, contrôle d'accès et journalisation.

Absolument. Nos agents IA fonctionnent en mode isolé sur votre infrastructure ou sur notre infrastructure sécurisée en France. Vos données de test, code source et logs restent dans votre environnement sécurisé. Nous ne stockons ni ne transmettons aucune donnée sensible à des serveurs tiers.

On le voit, et c'est tout l'enjeu. Nos agents travaillent sous relecture humaine, et quand un test se répare tout seul, la réparation est journalisée, jamais silencieuse. Un test qui se corrige en cachette cesse d'être un test : il devient un témoin complaisant. Nous préférons un échec visible à une réussite douteuse.

Notre équipe est composée d'experts en IA et QA issus des grands cabinets de conseil technologique, avec une solide expérience en automatisation de tests, machine learning et intégration de LLM pour des projets d'envergure internationale. Nous avons également une grande expertise dans le e-commerce : tunnels d'achat, paiements et UX responsive.

SAPFX ne coûte rien : il est open source sous licence Apache 2.0, sans licence à payer ni utilisateur à déclarer. Pour les prestations d'accompagnement (audit, accompagnement méthodologique ou orientation vers des partenaires pour vos migrations, formation, intégration CI/CD), nous chiffrons après un cadrage technique précis, en fonction du périmètre réel de votre SI.

CabrIA est le programme R&D d'AI Cabra : un modèle d'IA ouvert, spécialisé en Quality Engineering, destiné à un fine-tuning local sur les exécutions de tests réelles de l'équipe (Robot Framework, Playwright, agents via MCP) et couplé à une base de connaissances RAG dont chaque réponse cite ses sources. L'ensemble est conçu pour tourner on-premise, sur une station IA locale.

Un assistant généraliste connaît le test logiciel en général ; CabrIA est conçu pour apprendre votre terrain. Le fine-tuning prévu doit inscrire dans le modèle vos conventions et vos gestes (concevoir un plan de test, écrire une suite, diagnostiquer un échec, réparer un localisateur), et la base de connaissances garde les faits qui bougent : pièges connus de vos applications, procédures, versions. Elle se met à jour sans réentraîner le modèle.

L'architecture MoE de 35 milliards de paramètres au total n'active qu'environ 3 milliards de paramètres par token traité. Ce découplage offre la profondeur de raisonnement et la richesse lexicale d'un grand modèle tout en maintenant une empreinte mémoire compacte et une vitesse d'exécution élevée (débit historique d'environ 100 tok/s en inférence locale GGUF, selon les conditions, sans garantie). C'est le compromis retenu pour un déploiement réactif sur station de travail dédiée.

L'architecture ADR 0002 sépare strictement les savoir-faire pérennes des faits volatils. Le savoir-faire (conventions Robot Framework, sélecteurs accessibles Playwright, stratégies de diagnostic) doit être appris dans les poids par un fine-tuning LoRA SFT puis DPO, encore à réaliser. Les faits volatils (pièges applicatifs, versions de build, notes de cadrage) sont gérés par un RAG local hybride (FastMCP qa-brain, en service, sur base vectorielle Qdrant dense F16, BM25 en appoint et reranker, 4 119 passages indexés au 9 octobre 2026). Chaque réponse cite ses passages ; une réponse sans citation est rejetée et remplacée par les passages bruts.

Non. La base de connaissances et la restitution tournent sur une station IA locale, dans votre infrastructure, et l'entraînement (fine-tuning), encore à réaliser, y est prévu aussi. C'est le même principe de souveraineté que le reste de nos solutions : aucune donnée de test n'est envoyée à une API cloud.

En lisant ses sources. Chaque réponse de CabrIA cite les passages dont elle provient, ce qui vous permet de remonter à la spécification, au test ou au ticket d'origine ; une réponse sans citation est rejetée et remplacée par les passages bruts. C'est une contrainte de conception, pas une option : un assistant de QA qu'on ne peut pas vérifier n'a pas sa place dans une chaîne de qualité.

Deux garde-fous stricts interviennent : un enregistreur de vol universel muni d'un épurateur (scrubber) automatique qui masque à la volée identifiants, secrets d'API et données personnelles avant tout stockage ; puis une raffinerie avec juge distinct, confirmation des notes et traçabilité. La validation systématique du code généré sur fixtures hors ligne reste un jalon à compléter avant entraînement. Au 9 octobre 2026, 1 892 exemples d'entraînement sont admis (917 critiques de tests, 526 diagnostics, 313 paires spécification-suite, 136 enseignements). Le 9 octobre 2026, 1 070 tests automatisés sur 1 071 ont réussi, en un seul processus ; le test restant interroge les services réels du laboratoire et a dépassé son délai. Ces tests vérifient le logiciel, pas la qualité de chaque réponse du modèle.

AI Cabra a fait le choix délibéré de construire la chaîne sur une configuration de laboratoire à coût maîtrisé : deux stations de travail équipées de 128 Go de mémoire unifiée, pour l'inférence locale continue au format quantifié GGUF (débit historique d'environ 100 tok/s, selon les conditions) et pour le premier entraînement LoRA en bf16, encore à réaliser. L'objectif est de montrer qu'une IA de QA d'entreprise peut se passer d'un cluster de datacenter hors de prix et d'API facturées au token.

Pour limiter le biais d'auto-évaluation (syndrome du modèle qui trouve ses propres réponses systématiquement excellentes), notre banc d'évaluation recourt à un modèle juge étalon indépendant de 30 milliards de paramètres. Ce tiers arbitre évalue la rigueur des assertions, la propreté du code produit et l'exactitude des diagnostics selon une grille stricte. Il apporte une confirmation et une traçabilité des notes, sans prétendre éliminer tout biais ; une panne de station ne vaut pas rejet du candidat. Le banc compte 77 cas, dont 19 RAG (état au 11 septembre 2026).

Pas encore en tant que produit : c'est un programme de R&D mené preuve d'abord (banc d'évaluation, capture, corpus, entraînement, mise en service). Le RAG local qa-brain est en service (4 119 passages indexés au 9 octobre 2026) ; le premier fine-tuning reste à réaliser, sur un jeu de 1 892 exemples admis au 9 octobre 2026. Nous publierons des mesures, pas des promesses. Contactez-nous pour une démonstration ou pour en parler pour votre équipe QA.

CabraFlow est un projet d'AI Cabra en conception : un orchestrateur de tests keyword-driven prévu au-dessus de Playwright. L'intention de conception : vous feriez la démonstration de votre métier dans l'application en la commentant à voix haute, et le test s'écrirait sous vos yeux, en micro-phrases métier, avec vos mots. Ce ne serait un fork ni de Robot Framework ni de Playwright, mais un orchestrateur qui marierait le keyword-driven du premier au moteur et aux localisateurs user-facing du second. État au 6 octobre 2026 : six spécifications rédigées le 12 août 2026, aucune ligne de code, aucun prototype ni démonstration. Le mode vocal attend un critère chiffré (plus de 85 % d'étapes correctes, moins de 2 s de latence) qui n'a pas encore été mesuré.

Non, c'est l'intention de conception. Le langage visible serait fait de micro-phrases métier créées à la volée avec les mots du présentateur (« Valider la commande », « Se connecter en tant qu'acheteur »), jamais de code ni de vocabulaire d'outil. Un studio graphique est prévu pour assembler et éditer les mots-clés ; les profils techniques garderaient un mode dev où le fichier YAML source s'édite directement. Rien de cela n'est encore développé : CabraFlow en est aux spécifications.

C'est un objectif de conception, pas encore un résultat mesuré. Le langage ne contiendrait ni CSS ni XPath : les cibles seraient résolues par l'arbre d'accessibilité (rôle et nom accessibles, les localisateurs getByRole de Playwright), et le test interagirait avec la page comme un utilisateur. Si un développement change la structure HTML en conservant le rôle sémantique, le test devrait tenir.

Non, par conception. Le test serait un fichier YAML lisible et versionnable, prévu pour être rejoué sur trois cibles : le runner natif, un export Playwright (.spec.ts) et un export Robot Framework (.robot), auxquels s'ajouterait un export documentaire ISTQB pour la recette formelle et l'audit. Les exports sont prévus pour se régénérer depuis le YAML. Aucun de ces éléments n'existe encore : CabraFlow est en conception.