Glossaire · Le vocabulaire de la QA et de l'IA

Un programme qui pilote un grand modèle de langage pour enchaîner des actions sur un vrai système, au lieu de se contenter de produire du texte. Dans SAPFX, cinq agents planifient, génèrent, réparent, vérifient et documentent les tests en pilotant un vrai système SAP via MCP, toujours sous relecture humaine.

L'optimisation d'un contenu pour qu'il soit compris et cité par les assistants IA comme ChatGPT, Claude, Perplexity ou Gemini, et non par les seuls moteurs de recherche classiques. En pratique : des données structurées, des réponses autoportantes et des faits vérifiables.

Le réentraînement d'un modèle existant sur un corpus spécifique pour le spécialiser. CabrIA prévoit de l'appliquer localement, sur les exécutions de tests réelles du client, afin que le modèle parle le vocabulaire de son métier sans que les données quittent l'infrastructure. Le premier fine-tuning reste à réaliser : au 9 octobre 2026, le jeu d'entraînement compte 1 892 exemples admis.

Un modèle entraîné sur de grands volumes de texte, capable de comprendre une consigne en langage naturel et d'y répondre. En QA, il sert à générer des cas de test, à expliquer un échec ou à traduire une spécification en scénario exécutable.

Un protocole ouvert qui expose des outils et des sources de données à un modèle d'IA de façon normalisée. SAPFX s'appuie sur le serveur rf-mcp pour laisser un agent piloter Robot Framework et un vrai système SAP, plutôt que de deviner ce qui se passe à l'écran.

L'ensemble des techniques qui permettent à une machine d'analyser du langage humain. En QA, le NLP sert notamment à rapprocher une spécification rédigée en français des cas de test qui la couvrent.

Un déploiement sur l'infrastructure du client, plutôt que dans un cloud public. Chez AI Cabra, la règle d'or est le 100 % on-premise ou le cloud souverain (France, UE) : les données de test, le code source et les journaux ne sortent pas de votre périmètre.

Une technique qui combine recherche documentaire et génération : le modèle répond à partir de documents retrouvés au moment de la question, et non de sa seule mémoire d'entraînement. CabrIA l'utilise dans son serveur qa-brain, en service (4 119 passages indexés au 9 octobre 2026, recherche dense avec BM25 en appoint) : chaque réponse cite ses passages, et une réponse sans citation est rejetée et remplacée par les passages bruts.

L'analyse automatique d'images. En test logiciel, elle permet de repérer un élément d'interface ou une régression visuelle quand aucun identifiant technique fiable n'est disponible dans le DOM.

Une architecture de réseau de neurones où seuls certains sous-réseaux spécialisés (« experts ») sont activés pour chaque token généré. Dans CabrIA, un modèle MoE de 35 milliards de paramètres au total n'active qu'environ 3 milliards de paramètres par token, ce qui conserve une vaste capacité de raisonnement avec un débit relevé d'environ 100 tok/s sur station de travail locale, variable selon les conditions.

L'architecture cognitive qui sépare le savoir-faire pérenne (conventions, règles de syntaxe, réflexes d'auto-réparation), destiné aux poids du modèle par un fine-tuning LoRA SFT/DPO encore à réaliser, des faits volatils (versions d'écrans, pièges récents, tickets) conservés dans un RAG local hybride, le serveur FastMCP qa-brain, en service : 4 119 passages indexés au 9 octobre 2026. Chaque réponse du RAG cite ses passages ; une réponse sans citation est rejetée.

L'implémentation asynchrone haute performance du Model Context Protocol en Python. C'est le moteur d'interconnexion utilisé par CabrIA pour son serveur de mémoire qa-brain.

Le recours à un modèle d'IA tiers indépendant (de 30 milliards de paramètres pour CabrIA) pour noter et valider les cas de test générés, afin que le modèle principal ne soit pas seul juge de ses propres productions : le juge confirme les notes et les trace, sans prétendre éliminer tout biais.

Un environnement matériel de développement et d'inférence reposant sur deux stations de travail à mémoire unifiée (128 Go), sans cluster de centre de données : service local des modèles au format quantifié GGUF, avec un débit historique d'environ 100 tok/s selon les conditions, et premier entraînement LoRA en bf16 prévu. Il vise une IA de test souveraine et locale sans abonnement cloud facturé au token ; aucun débit n'est garanti.

La spécification formelle d'AI Cabra qui fixe les frontières d'intervention, les contrats d'entrée et de sortie et les responsabilités étanches des cinq agents de test de rf-test-agents (rf-planner, rf-generator, rf-healer, rf-verifier, rf-istqb). Aucun agent ne juge son propre travail, et quatre gardes mécaniques, exécutés en intégration continue à chaque push et par un hook d'édition de Claude Code, contrôlent ce que les agents écrivent.

Le serveur MCP standard pour Robot Framework permettant aux agents IA de piloter l'exécution de mots-clés et d'inspecter l'état du système cible en session active. Il matérialise la boucle percevoir → agir → percevoir, assurant que chaque étape d'un test est validée en direct sur l'application vivante avant toute écriture de code.

La discipline qui conçoit des systèmes où des agents IA ne se contentent pas de répondre mais agissent : elle sépare le raisonnement, l'autorisation, l'exécution et la vérification, pour qu'un résultat repose sur des faits observables plutôt que sur le verdict de l'agent. Une méthode qui utilise des agents, comme le STDD, n'est pas pour autant une architecture agentique. C'est le chantier de CabraMesh, nos travaux V2 encore en recherche.

L'approche qui choisit un modèle pour un travail précis plutôt qu'un modèle unique pour tout : ses capacités sont qualifiées sur des cas représentatifs, puis comparées en qualité, en latence et en ressources, sur une infrastructure locale. Changer de modèle ne doit pas changer les règles métier. C'est une piste de recherche de CabraMesh ; multiplier les modèles n'est pas en soi une preuve de progrès.

La représentation d'une interface telle que l'exposent le navigateur et les technologies d'assistance : des rôles, des noms, des états. Un test peut y résoudre ses cibles avec getByRole, au lieu de dépendre de sélecteurs CSS ou XPath que le moindre changement de mise en page casse ; c'est l'approche que prévoit CabraFlow, en conception.

La capacité d'un test à retrouver seul un élément dont le localisateur a changé. Dans SAPFX, la réparation est toujours journalisée, jamais silencieuse : une correction invisible transformerait un test en faux témoin.

La description d'une situation à vérifier : un état de départ, des actions, un résultat attendu. C'est l'unité de base de la QA, et ce que nos outils et agents aident à produire puis à maintenir automatiquement.

Une vue de l'écran pensée pour un agent IA : chaque cible actionnable reçoit un numéro, avec son libellé humain, son identifiant et sa valeur (Get Screen Map), et la capture annotée dessine ces numéros sur l'image (Get Annotated Screenshot). L'agent désigne un numéro, la bibliothèque agit sur un identifiant vérifié ; réservé au pilotage interactif, jamais dans une suite livrée.

L'intégration et la livraison continues : la chaîne qui compile, teste et déploie automatiquement à chaque modification du code. Des tests automatisés n'ont de valeur que branchés dessus, car c'est là qu'ils tournent sans intervention manuelle.

La part du code ou des parcours métier réellement exercée par les tests. SAPFX mesure 95 % de couverture de code en intégration continue sur ses 3 959 tests unitaires rejoués hors SAP (version 0.8.5), avec un plancher strict de 85 % imposé en CI ; ses 462 scénarios joués en direct sur des systèmes SAP réels couvrent, eux, des parcours métier.

La mesure objective et outillée des lignes de code exécutées lors de tests automatisés. Dans SAPFX, la couverture est mesurée via pytest-cov en intégration continue : 95 % à la version 0.8.5, avec un plancher strict de 85 % imposé en CI. Elle dit quelle part du code les tests exécutent, pas que ce code est exempt de défaut métier.

Un collecteur passif qui intercepte l'ensemble des interactions de test (listeners Robot Framework, reporters Playwright, hooks MCP). Il intègre un épurateur (scrubber) automatique qui masque à la volée les mots de passe, clés API et données personnelles avant tout archivage dans le corpus d'apprentissage. Au 9 octobre 2026, la collecte de CabrIA compte 4 146 190 enregistrements consolidés ; un enregistrement n'est ni un exemple admis ni un scénario validé.

Une règle stricte de salubrité interdisant l'intégration de tout scénario ou code de test synthétisé par une IA dans un jeu de données sans qu'il ait réussi un dryrun et une exécution réelle complète contre des fixtures hors ligne. Cette validation systématique du code généré reste à compléter avant entraînement. À ne pas confondre avec les tests du logiciel CabrIA lui-même : 1 070 réussis sur 1 071 le 9 octobre 2026 (le dernier interroge les services réels du laboratoire et a dépassé son délai), qui ne mesurent pas la qualité du modèle.

L'International Software Testing Qualifications Board, l'organisme dont le référentiel et le vocabulaire font office de standard pour la documentation de test. Les agents sap-istqb et rf-istqb structurent plans et cas de test d'après ce référentiel ; CabraFlow, en conception, en prévoit un export documentaire.

Une approche où le test s'écrit avec des mots-clés métier réutilisables, la mécanique technique restant dans une couche séparée. Un testeur fonctionnel lit et modifie le test sans lire de code, et un changement technique se corrige en un seul point centralisé.

L'expression qui désigne un élément d'interface pour qu'un test puisse agir dessus. Dans SAPFX, les localisateurs vivent dans une couche de ressources séparée, jamais au milieu des tests : c'est ce qui permet de les corriger sans toucher aux scénarios.

Une bibliothèque open source de pilotage de navigateur moderne par Microsoft, avec attentes automatiques et sélection par rôle d'accessibilité. SapFioriLibrary s'appuie dessus à travers la bibliothèque Browser ; CabraFlow, en conception, prévoit de s'y adosser aussi.

Un cadre d'automatisation open source, keyword-driven, où le test se lit comme une suite de phrases métier. C'est le socle de SAPFX, d'ODOOFX et de rf-test-agents, et l'une des trois cibles d'export prévues par CabraFlow, en conception.

Un test qui parcourt un processus métier complet à travers tous ses systèmes, comme le ferait un utilisateur réel. Sur SAP, un seul parcours peut traverser SAP GUI, Fiori et une API OData, ce qui explique que SAPFX couvre les trois canaux sans rupture.

Un test qui traverse plusieurs canaux d'un même système : il prépare par l'API, agit à l'écran et vérifie par un canal indépendant, dans le même rapport Robot Framework. Exemple validé en direct : un même prix de produit lu par OData, par le WebGUI et par RFC, les trois valeurs comparées entre elles. Voir neuf tests hybrides.

La mesure du comportement d'une application sous charge : temps de réponse, tenue en montée en charge, goulots d'étranglement. AI Cabra propose des audits et tests de performance dont l'analyse est assistée par l'IA.

Un script déterministe exécuté en intégration continue à chaque push, et par un hook d'édition de Claude Code, qui remplace des consignes en langage naturel données à l'IA par des vérifications mécaniques (provenance SHA256 du plan de test, rejet des sélecteurs CSS/XPath bruts, interdiction de Sleep). rf-test-agents en compte quatre : un écart fait échouer l'intégration continue, et check_conventions bloque aussi l'édition elle-même.

Le contrôle qui refuse un relevé de tableau amputé : une grille ou une table ne rend souvent qu'une partie de ses lignes, toutes propres, sans rien qui signale le manque. SAPFX confronte le nombre de lignes lues au total que le tableau déclare (Table Extract Should Be Complete), sur SAP GUI, le WebGUI, SAPUI5 et RFC.

Le registre transparent (consigné dans docs/heal-journal.md) documentant chaque recalibrage automatique de locateur opéré par rf-healer : horodatage, locateur obsolète, nouveau locateur validé et justificatif technique. Il garantit qu'aucune réparation n'est silencieuse et offre aux auditeurs une traçabilité complète de l'évolution du code.

Vérifier, avant toute lecture ou écriture, que le test parle bien au système visé, par un critère qui distingue vraiment deux systèmes : la release, le kernel, le mandant servi. Deux systèmes peuvent annoncer le même identifiant et le même nom d'hôte ; System Identity Should Be refuse alors la cible au lieu de lire le mauvais système.

Savoir quels tests rejouer quand un transport arrive sur un système SAP. SAPFX lit le transport par RFC en lecture seule, suit chaque objet sur un niveau d'utilisation, croise les noms avec les suites Robot Framework selon ce que chaque test exécute vraiment, puis un humain décide, suite par suite, de rejouer ou d'écarter avec sa raison ; la décision est consignée et liée à l'empreinte de l'impact. Publiée dans la version 0.8.5 des bibliothèques (13 octobre 2026). Voir la section.

Une règle qui décide, avant tout geste d'écriture, si SAPFX peut écrire dans le système SAP : lecture seule, exploration (une approbation par geste) ou complet, avec une piste d'audit des décisions. En mode humain, l'approbation vient d'une personne, par l'outil MCP sapfx_approve_write de l'atelier ou par une boîte de saisie où elle tape un mot de confirmation, et ne couvre qu'une cible ; un agent ne peut pas s'approuver lui-même. Un garde-fou d'exploitation, pas un contrôle de sécurité : la barrière reste l'autorisation SAP de l'utilisateur de test. Publiée dans la version 0.8.5 des bibliothèques ; l'outil MCP appartient à l'atelier, pas au paquet PyPI. Voir la section.

Une décision de livraison calculée sur le fichier de résultats d'un run de Robot Framework : tests joués, échecs, sauts sans raison, captures d'erreur dans un test vert, localisateurs réparés, plans modifiés depuis la génération. Trois profils (strict, standard, montée en charge), des critères explicites, et un critère illisible compté comme non mesuré, jamais comme zéro. Publié dans la version 0.8.5 du paquet. Voir la section.

L'état d'esprit commun de SAPFX, d'ODOOFX et de rf-test-agents. La spécification est une vision d'ensemble en langage humain, structurée ou non (objectif métier, user story, scénario BDD, cas de test existant) ; le planner la confronte au système réel et en écrit la version observée dans specs/, relue par un humain, qui devient la source de vérité ; la suite de tests en dérive (chaque étape exécutée en direct avant d'être écrite, empreinte SHA256 du plan vérifiée par un garde) ; et ce qu'un test exige sans que la bibliothèque sache le faire devient un keyword de la bibliothèque, jamais un contournement dans une suite. Le BDD est une forme de spécification, pas un concurrent ; ce qui distingue le STDD, c'est la version observée qui fait foi et qui pilote aussi le code d'automatisation. Même logique que TDD, une brique plus tôt : la spec, verte par défaut en théorie, est confrontée au système réel avant le moindre test. 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.

Voir aussi : le film STDD (8 min 34), qui le montre sur un cas SAP réel.

Le langage de programmation propre à SAP, dans lequel est écrit l'essentiel du code métier standard et spécifique. Les scénarios en direct de SAPFX sont joués contre de vrais systèmes ABAP (ABAP Platform 1909 et 2023), et non contre une simulation.

Les deux générations d'ERP SAP : ECC, historique, et S/4HANA, actuelle. SapEccLibrary pilote les deux via SAP GUI Scripting, ce qui sécurise les longues années de migration où les entreprises exploitent les deux en parallèle.

Une division logique d'un système SAP : un même système héberge plusieurs mandants (000 pour l'administration, un mandant de travail comme 001), chacun avec ses données métier, ses utilisateurs et son paramétrage. Un test qui ne vérifie pas son mandant peut lire les bonnes tables au mauvais endroit : SAPFX relit le mandant réellement servi, canal par canal, avant toute écriture.

Le code court qui ouvre un écran de SAP GUI : SE16 pour afficher une table, SM36 pour planifier un job, BP pour les partenaires commerciaux. Run Transaction de SapEccLibrary l'ouvre et juge le résultat sur le type du message de statut, jamais sur son texte traduit, ce qui fonctionne quelle que soit la langue de connexion.

L'interface d'automatisation intégrée au client lourd SAP GUI, qui permet de piloter les écrans par programme. C'est le mécanisme sur lequel repose SapEccLibrary. Elle doit être activée côté serveur et côté client par votre équipe Basis.

Le dynpro est l'écran classique d'une transaction SAP GUI, dont chaque champ et chaque bouton porte un identifiant technique ; le table control est le tableau de saisie qu'il contient, comme la liste des champs d'une table dans SE11. SapEccLibrary lit un table control par titre de colonne (Read Table Control), fenêtre par fenêtre, et ne rend que les lignes réellement remplies.

La transaction standard qui affiche le contenu d'une table SAP. SAPFX s'en sert pour compter et lire des tables par l'écran, par exemple pour confronter le nombre d'enregistrements vu dans SAP GUI à celui que rend un service OData ou le canal RFC sur le même système. Une structure, qui n'est pas une table, y est refusée par un message de type E.

La grille de liste standard de SAP (ALV, ABAP List Viewer), présente dans la plupart des rapports. Elle ne charge ses lignes qu'au défilement et rend les autres en cellules vides : un relevé peut avoir le bon nombre de lignes et être creux. Read Full Grid fait défiler la grille pour tout lire et Count Blank Grid Rows refuse un relevé creux ; les colonnes se lisent par identifiant technique, indépendant de la langue.

Le message affiché en bas d'un écran SAP après une action, qui porte un type (S succès, E erreur, W avertissement, A abandon, I information), une classe et un numéro. SAPFX juge un résultat sur le type et l'identifiant du message (par exemple MO/E/402), jamais sur son texte, traduit dans la langue de l'utilisateur.

La version navigateur de SAP GUI, servie par le serveur ABAP : les mêmes transactions, rendues en HTML. SapFioriLibrary la pilote par le SID de chaque élément, le même identifiant que le scripting de bureau, et lit ses grilles en confrontant les lignes reçues au total que la grille déclare : le WebGUI n'envoie qu'une page de lignes, renumérotées à partir de 1.

Le langage de conception des interfaces web modernes de SAP, qui succède aux écrans du client lourd. Une application Fiori est techniquement une application SAPUI5.

La bibliothèque JavaScript de SAP qui fait tourner les applications Fiori. Ses identifiants d'éléments changent dynamiquement d'une exécution à l'autre : SapFioriLibrary est prouvée compatible d'UI5 1.71 à 2.0 pour absorber cette variabilité.

Le point d'entrée des applications SAP Fiori : des tuiles regroupées par catalogue, dont certaines affichent un compteur. SapFioriLibrary ouvre une application par son intent sémantique (Open Fiori App), la voie stable qui survit au thème et à la langue, et attend qu'un compteur de tuile soit réellement chargé avant de le lire (Wait For Flp Tile Counter).

Des modèles d'applications SAP Fiori générés à partir des annotations d'un service OData : liste (List Report) et fiche (Object Page). Leurs identifiants de contrôles sont stables, ce qui en fait de bonnes ancres de test ; une table n'y rend que ses lignes instanciées, d'où la confrontation au total déclaré avant toute extraction.

Un protocole d'API REST normalisé, utilisé par SAP pour exposer ses données aux applications Fiori et aux systèmes tiers. SapApiLibrary couvre nativement OData v2 et v4.

Le composant du serveur ABAP qui publie les services OData. SapApiLibrary lit son catalogue de services et le contrat $metadata avec ses libellés, gère le jeton CSRF des écritures et regroupe plusieurs requêtes en un seul $batch. Son contrôle préalable nomme la cause d'un service inactif plutôt que de laisser un test échouer sur une erreur muette.

Une vue de données définie en ABAP Core Data Services, sur laquelle reposent les applications SAP Fiori et les services OData modernes de SAP S/4HANA. Un test SAPFX peut compter les lignes d'une vue CDS par RFC et confronter ce nombre au compteur qu'une tuile du launchpad affiche, sans arrondi ni tolérance.

Le modèle de programmation actuel de SAP pour les applications transactionnelles, brouillons compris. Le serveur ABAP génère à la volée un aperçu SAP Fiori Elements de tout service RAP publié : Build Fe Preview Path en construit l'adresse, ce qui permet de tester l'interface sans application déployée.

Le protocole natif d'appel de fonctions à distance et de BAPI sous SAP. Dans SapApiLibrary, le canal RFC, optionnel, passe par pyrfc : lecture de tables (Read Rfc Table), BAPI jugées par type de message (Call Bapi, Commit/Rollback Bapi Transaction), jobs de fond et spool (Wait For Background Job, Read Job Spool), IDoc (Create Outbound Idoc, Wait For Idoc Status), configuration et surface de sécurité ABAP en lecture seule.

Une interface de programmation métier standard de SAP, appelée par RFC pour lire ou modifier un objet (un partenaire, une commande). Call Bapi de SapApiLibrary juge son résultat sur le type des messages de la table RETURN (E, A ou X font échouer), jamais sur leur texte, et Commit Bapi Transaction valide la transaction.

Le document intermédiaire de SAP pour échanger des données entre systèmes (ALE, EDI), suivi par une suite de statuts numériques. SapApiLibrary crée un IDoc sortant, attend son statut par son code (Wait For Idoc Status ; 03 : transmis au port) et retrouve l'IDoc entrant lié par l'identifiant de transaction tRFC, jamais par l'horodatage.

Un job est un programme planifié dans SAP (transaction SM36, suivi dans SM37) ; le spool conserve la liste qu'il imprime (SP01). SapApiLibrary attend un job par sondage borné du journal des jobs (Wait For Background Job), sans pause fixe, et lit son spool par deux voies indépendantes. Une étape qui n'imprime rien n'a pas de spool, ce que SAPFX distingue d'un spool vide.

SAP BTP est la plateforme cloud de SAP ; SAP Build Work Zone y publie des sites et des launchpads, protégés par un fournisseur d'identité. SapFioriLibrary s'y connecte par le formulaire du fournisseur d'identité (Log In Via Identity Provider) et entre dans l'application ouverte dans son iframe ; SapApiLibrary ouvre le canal API du site en OAuth2 par une clé de service.

L'outil de test historique intégré à SAP Solution Manager 7.2, dont la maintenance standard s'arrête le 31 décembre 2027 (note SAP 3585220). SAP oriente vers SAP Cloud ALM, qui gère et suit les tests ; leur exécution automatisée passe par des outils qui s'y raccordent, et les scénarios CBTA existants doivent être repris dans un autre outil. SAPFX est une voie ouverte, sans licence, pour les reprendre en Robot Framework.

L'outil de test automatisé intégré au serveur ABAP (extended Computer Aided Test Tool), qui enregistre et rejoue des transactions. Il reste disponible ; ses scénarios peuvent être réécrits en Robot Framework avec SAPFX quand une équipe veut un seul outillage pour SAP GUI, SAP Fiori et les API.

SAP Solution Manager 7.2, qui porte CBTA, atteint la fin de sa maintenance standard le 31 décembre 2027 (note SAP 3585220). SAP oriente vers SAP Cloud ALM, qui gère et suit les tests ; leur exécution automatisée passe par des outils qui s'y raccordent.

La transaction standard de SAP qui analyse la charge de travail du système : fréquence, volume et temps de réponse des transactions et programmes réellement exécutés. Elle aide à choisir les transactions à tester en priorité, celles que l'entreprise utilise vraiment.

Notre écosystème open source d'automatisation de tests SAP pour Robot Framework, sous licence Apache 2.0, distribué sur PyPI sous le nom robotframework-sapfx (version 0.8.5 du 13 octobre 2026). Trois bibliothèques couvrent SAP GUI pour Windows, SAP Fiori, SAPUI5 et SAP GUI for HTML, OData et RFC/BAPI, et un même test peut traverser plusieurs canaux, sans licence à payer ni verrouillage éditeur. Pensé pour tester, il sait aussi écrire, supprimer et recouper ses écritures par un second canal, ce qui ouvre, comme cap, la génération de jeux de données, le peuplement de bases pour les tests de performance et le chargement de données de paramétrage ou de migration. Découvrir SAPFX.

Voir aussi : la page « SAPFX en images », captures prises en direct et extraits de suites validées, et le film « The SAPFX mindset » (11 min 11), qui en résume l'état d'esprit en sept principes.

Les trois bibliothèques de SAPFX, 442 keywords documentés à la version 0.8.5 : SapEccLibrary (195) pour SAP GUI pour Windows (ECC et S/4HANA), SapFioriLibrary (98) pour SAP Fiori, SAPUI5 et SAP GUI for HTML au-dessus de Playwright, et SapApiLibrary (149) pour les API OData v2/v4 et RFC/BAPI, le canal RFC, optionnel, passant par pyrfc. Référence des keywords.

Les plugins SAPFX du serveur MCP rf-mcp (SAP GUI, SAP Fiori, API) donnent à un agent IA la perception de l'écran SAP et l'exécution des keywords pas à pas ; la surcouche sapfx-mcp ajoute l'état de la session, la capture d'écran, le rechargement à chaud et, depuis le 9 octobre 2026, l'approbation par un humain d'une écriture sur SAP (sapfx_approve_write), sans modifier rf-mcp. Ils font partie de l'atelier SAPFX, pas du paquet PyPI, qui porte les bibliothèques. Le pont MCP parmi les outils de l'atelier.

Deux enregistreurs transcrivent un parcours réel en keywords Robot Framework : une extension de navigateur pour SAP Fiori et le WebGUI, un enregistreur de bureau pour SAP GUI. Ils exportent une suite complète, une paire resource et suite sans identifiant brut dans le test, un plan de test et un rapport HTML ; le déroulé enregistré reste un brouillon à relire. Les voir à l'œuvre ; leurs options et leurs limites.

Cinq agents spécialisés : sap-planner confronte la demande au système réel et écrit un plan observé, sap-generator exécute chaque étape avant de l'écrire, sap-healer répare la couche resources sans toucher aux assertions, sap-verifier relit en lecture seule et sap-istqb documente et revoit la conception selon l'ISTQB. Ils appliquent la méthode STDD, sous contrôle humain, dans l'atelier SAPFX. Les agents et leur cadre.

L'outil de l'atelier SAPFX qui note une demande de test, un prompt confié aux agents IA, avant que les agents ne la traitent : 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, local par défaut, qui compte zéro quand il ne répond pas, et 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 ; « jouable » ne dispense pas de l'exploration sur le système. Ajouté le 10 octobre 2026. Prompt Eval parmi les outils de l'atelier.

Notre suite open source d'agents d'ingénierie QA pour Robot Framework, sous licence Apache 2.0, distribuée sur GitHub (CyrilM29/rf-test-agents, version 1.0.0). Elle implémente l'architecture Agent Contract v1 (5 agents spécialisés), le protocole standard rf-mcp (RobotMCP) et 4 gardes mécaniques déterministes, exécutés en intégration continue à chaque push et par un hook d'édition de Claude Code ; 310 tests unitaires réussis en intégration continue le 5 octobre 2026. Découvrir rf-test-agents. 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.

Le nom de nos travaux V2 en ingénierie agentique : une architecture cible locale où des agents aux rôles délimités agissent dans un périmètre approuvé, avec des modèles qualifiés par tâche, des contrôles déterministes avant toute action et des preuves vérifiables, sous contrôle humain. En recherche : aucun déploiement ni gain mesuré n'est revendiqué, et aucun dépôt public n'existe. À ne pas confondre avec rf-test-agents, la V1 libre (version 1.0.0, Apache 2.0). Découvrir CabraMesh.

Notre verticale open source d'automatisation des tests Odoo pour Robot Framework, sous licence Apache 2.0, publiée sur PyPI (paquet robotframework-odoofx, version 0.2.0 du 13 octobre 2026, phase alpha). Elle vise Odoo Community et Enterprise par trois canaux : l'API RPC (XML-RPC et JSON-2) et l'interface web (connexion, navigation, lecture des vues, saisie de formulaires), opérationnelles et éprouvées sur Odoo 16 et 19, et l'introspection ORM, avec cinq agents qui appliquent le Spec-Test-Driven Development. Découvrir ODOOFX.

Notre programme de R&D, sans version publiée : un modèle d'IA ouvert à spécialiser en Quality Engineering par un fine-tuning local, prévu sur les exécutions de tests réelles, couplé à une base de connaissances RAG dont chaque réponse cite ses passages. Au 9 octobre 2026, le RAG qa-brain est en service (4 119 passages indexés), 1 070 tests automatisés sur 1 071 ont réussi et le jeu d'entraînement compte 1 892 exemples admis (au 9 octobre) ; le premier fine-tuning reste à réaliser. 100 % on-premise ou cloud souverain (France, UE), les données de test ne sortent pas de ce périmètre. Découvrir CabrIA.

Le serveur MCP de mémoire QA de CabrIA, en service : un RAG local qui combine recherche dense, BM25 en appoint et reranking sur les documentations de keywords, les plans de test, les guides et les leçons tirées d'incidents réels, soit 4 119 passages indexés au 9 octobre 2026. Les agents de test l'interrogent avant leurs décisions ; chaque réponse cite ses passages, et une réponse sans citation est rejetée et remplacée par les passages bruts. Découvrir CabrIA.

Notre programme de R&D, en conception, d'orchestrateur de tests keyword-driven au-dessus de Playwright. L'objectif : que l'utilisateur démontre son métier en le commentant à voix haute, que le test s'écrive en micro-phrases métier et se rejoue sur trois cibles (runner natif, export Playwright, export Robot Framework), en local. Au 6 octobre 2026, six spécifications sont rédigées (12 août 2026), sans code, prototype ni démonstration ; le mode vocal attend un critère chiffré (plus de 85 % d'étapes correctes, moins de 2 s de latence) jamais mesuré. Découvrir CabraFlow.