Vidéos explicatives · L'IA dans les tests, la méthode STDD, les agents sur SAP, l'état d'esprit SAPFX
Quatre films d'animation tirés de cas réels de notre banc de test SAP. Ils sont en anglais, avec une voix de synthèse et des sous-titres en français, en anglais et en espagnol, découpés en chapitres et accompagnés de leur transcription. Aucune prise de vue, aucun lecteur tiers : les vidéos sont servies par ce site.
L'IA dans l'automatisation des tests : atouts, pièges et garde-fous
Les avantages et les inconvénients de l'IA pour les tests automatisés, vus depuis notre banc : ce qu'un agent fait bien (explorer le système réel, vérifier chaque étape, réparer, faire grandir la bibliothèque, ne coûter qu'une fois), ce qu'il risque (erreurs affirmées avec aplomb, suites vertes mais fausses, contournements, outils qui mentent, coût, autonomie), et les six garde-fous qui gardent le premier sans le second. Chaque exemple est un cas réel, daté.
L'IA dans l'automatisation des tests · 6 min 43 · en anglais, voix de synthèse, sous-titres français. Stedd (l'agent IA), MCP (le messager) et Terra (le système SAP réel) remplissent deux colonnes, ce que l'IA apporte et ce qu'elle risque, puis les équilibrent par six garde-fous. Leur fil rouge : l'IA propose, le système réel décide.
Lire la transcription en français
0:00 · Ouverture
Un agent IA peut-il écrire et maintenir vos tests automatisés ? Nous l'avons essayé pour de vrai, sur des systèmes SAP réels. Voici ce qu'il fait bien, où il échoue en silence, et les garde-fous grâce auxquels il en vaut la peine.
0:16 · Les personnages
Stedd est l'agent IA : un modèle de langage, avec un chapeau par métier : planifier, générer, vérifier, réparer. MCP est le messager : il porte chaque requête à Robot Framework, qui pilote SAP. Terra est le système SAP réel. Ils sont deux, Terra 2023 et Terra A4H : des jumeaux, faciles à confondre.
0:39 · Le système imaginé
Une idée traverse tout le film. Un modèle de langage connaît SAP par ce qu'il a lu : il porte un système imaginé dans sa tête. Le système réel est là, dehors, et il n'est pas toujours d'accord. C'est lui que l'on teste, jamais le système imaginé. Nous allons remplir deux colonnes : ce que l'IA apporte, et ce qu'elle risque. Chaque exemple est un cas réel de notre banc, avec sa date.
1:07 · Avantage 1 · il explore
Avantage 1 : un agent peut explorer le système réel. Avant d'écrire le moindre test, le planner envoie MCP interroger Terra, une hypothèse à la fois. Le scénario 4 demandait une application de voyage sur le Launchpad. Terra a répondu : 66 applications, 62 intents, aucun pour les voyages. Sur trois scénarios, le système réel a réfuté 3, 2 et 5 hypothèses de leurs briefs. Aucune n'est arrivée jusqu'à un test.
1:36 · Avantage 2 · il vérifie chaque étape
Avantage 2 : chaque étape est jouée sur le système réel avant d'être écrite. Le generator n'écrit que ce qu'il a vu fonctionner. Le résultat est une suite Robot Framework ordinaire, sans IA à l'intérieur. L'IA travaille à la conception ; le test tourne sans elle.
1:54 · Avantage 3 · il répare
Avantage 3 : il sait réparer. Le 12 juillet, nous avons injecté une dérive de localisateur, à l'aveugle. Le healer a lu l'écran vivant et noté les correspondances les plus proches. Il a corrigé une ligne de la couche de ressources. Tests touchés : zéro. Rejeu : 7 sur 7. Le 1er septembre, une cible publique a basculé son shell en Web Components, quatre jours après une exécution verte. La campagne est tombée à 8 sur 12. Les agents l'ont réexplorée, ont réécrit la spec d'après ce qu'ils ont mesuré, et la suite est revenue à 12 sur 12.
2:29 · Avantages 4 et 5 · il construit, et ne coûte qu'une fois
Avantage 4 : ce que l'agent ne sait pas faire devient une capacité de la bibliothèque. Le scénario 4 à lui seul en a livré six, chacune avec son test unitaire. Avantage 5 : il ne coûte qu'une fois. Les tokens se dépensent pendant la conception. Un rejeu est une simple exécution Robot : zéro token, de 2 secondes à 5 minutes.
2:49 · Ce que l'IA apporte
Ce que l'IA apporte : elle explore, elle vérifie chaque étape, elle répare, elle fait grandir la bibliothèque, puis elle s'efface.
2:57 · Inconvénient 1 · sûr de lui, même quand il se trompe
Inconvénient 1 : il est sûr de lui, même quand il se trompe. Un plan affirmait que le produit HT-1000 était présent sur nos deux systèmes. Vérifié sur le système réel : zéro résultat, par API comme par RFC. L'affirmation avait été écrite de mémoire. C'est arrivé à cette série aussi : notre film précédent contenait une ligne écrite de mémoire. Elle était fausse. Une vérification sur les sources l'a attrapée.
3:25 · Inconvénient 2 · vert, et faux
Inconvénient 2 : une suite verte peut être fausse. Trois suites générées passaient : 12 sur 12, 13 sur 13, et 7 sur 7 sur deux releases. Un vérificateur indépendant, un agent qui ne fait que lire, les a renvoyées toutes les trois : humain requis. Huit réserves, puis huit, puis six. L'une ne prouvait sa cible que sur un canal sur trois. Une autre cachait trois défauts qu'aucune exécution ne pouvait révéler : la suite passait.
3:54 · Inconvénient 3 · il contourne
Inconvénient 3 : il contourne les problèmes. Une suite lisait une grille entière de 2 665 lignes au lieu de filtrer, avec une note : cause non investiguée. La vraie cause : une session de bureau à distance dessinait l'écran 2,4 fois plus grand, et la recherche par libellé cassait. La correction avait sa place dans la bibliothèque.
4:16 · Inconvénient 4 · ses outils peuvent mentir
Inconvénient 4 : ses outils peuvent mentir aussi. Le 7 septembre, un problème de threads a fait renvoyer à notre perception des écrans vides, comptés comme un succès. Un agent qui reçoit une liste vide conclut : aucune fenêtre n'est ouverte. Faux, et silencieux. Corrigé le soir même. Et nos deux systèmes Terra partagent le même identifiant système et le même nom d'hôte. Visez la mauvaise adresse, et l'agent teste le jumeau, parfaitement vert.
4:45 · Inconvénients 5 et 6 · coût et autonomie
Inconvénient 5 : il coûte cher à la conception. Nos scénarios mesurés ont coûté de 0,69 à plus de 2,4 millions de tokens chacun, et des heures de travail d'agent. Rien que démarrer un agent coûte environ 200 000 tokens avant tout travail utile. Réfuter le brief coûte le plus cher, et rapporte le plus. Inconvénient 6 : l'autonomie. Un agent peut committer, pousser ou supprimer. Même les dumps de session MCP gardaient les mots de passe : il a fallu les purger.
5:17 · Ce que l'IA risque
Ce que l'IA risque : des erreurs affirmées avec aplomb, des suites vertes mais fausses, des contournements, des outils qui mentent, le coût, et trop d'autonomie.
5:25 · Les garde-fous
Alors, comment garder le bon et neutraliser les pièges ? Avec des garde-fous, pas avec des consignes. Un : observer avant d'écrire. La spec est confrontée au système réel : c'est le Spec-Test-Driven Development. Deux : figer le résultat. L'IA conçoit, une suite déterministe s'exécute : zéro token, et le même verdict à chaque fois. Trois : un vérificateur indépendant, un agent qui ne fait que lire, à la chasse aux assertions faibles et aux exécutions vertes mais fausses. Quatre : des scripts qui échouent bruyamment. Une spec périmée, un localisateur brut, un contournement caché : refusés par une garde, pas par une promesse. Cinq : prouver la cible sur chaque canal, et laisser une perception qui ne sait pas lire échouer, jamais passer. Six : un humain reste aux commandes. Le healer répare le vocabulaire, jamais le test, et seul un humain active l'autonomie.
6:24 · Conclusion
L'IA dans l'automatisation des tests n'est ni magique ni un gadget : c'est une exploratrice rapide et infatigable, tant que le système réel a le dernier mot. Servez-vous-en là où vérifier coûte peu, jamais là où se tromper est silencieux. Merci d'avoir marché avec Stedd, MCP et Terra.
Le premier garde-fou, observer avant d'écrire, est le cœur de la méthode STDD, racontée pas à pas dans le film suivant. Les agents du film sont ceux de rf-test-agents, appliqués à SAP par SAPFX.
Le Spec-Test-Driven Development (STDD), expliqué sur un cas SAP réel
L'état d'esprit commun de SAPFX, d'ODOOFX et de rf-test-agents, raconté sur un cas SAP réel, le scénario 4 : la spec confrontée au système réel avant tout test, le test dérivé de la spec, la bibliothèque que le test fait grandir, un vérificateur indépendant, puis la boucle de maintenance quand le système change.
Le film STDD · 8 min 34 · en anglais, voix de synthèse, sous-titres français. Un cas SAP réel, le scénario 4 (un voyage RAP créé par Fiori Elements sur ABAP Platform 2023), raconté maillon par maillon par Stedd (les agents), MCP (le messager) et Terra (le système réel).
Lire la transcription en français
0:00 · Ouverture
Une courte histoire sur le test de systèmes SAP, racontée par trois personnages : un agent, un messager, un système réel. Et sur un état d'esprit, le Spec-Test-Driven Development (STDD) : ce que l'on teste est d'abord observé sur le système réel.
0:17 · Les personnages
Stedd est l'agent IA. Un chapeau par métier : planifier, générer, vérifier, réparer. MCP est le messager : il porte les requêtes à Robot Framework et rapporte les réponses. Terra est le système SAP réel. Ils sont deux : Terra 2023, notre cible, et Terra A4H, son jumeau.
0:36 · La méthode habituelle
La plupart des automatisations de test partent de ce que l'on suppose du système : un document, un souvenir, une capture d'écran. Le test est écrit d'après la supposition, sans regarder le système. Il s'exécute. Il passe au vert. Mais le système réel n'a jamais été interrogé : la tuile n'existe pas, l'application vit ailleurs. Vert, et faux.
1:00 · De TDD à STDD
Vous connaissez peut-être TDD : rouge, vert, refactor. Le test d'abord, le code ensuite. Le STDD applique la même logique une brique plus tôt : la spec vient d'abord. En théorie, une spec est verte par défaut : personne ne la teste. Le STDD la met à l'épreuve du système réel : rouge là où elle se trompait, verte une fois observée. Seulement ensuite vient le test.
1:25 · Trois maillons
Le STDD est une chaîne de trois maillons. Chacun pilote le suivant, et chacun est contrôlé par un script. 1 · La spec, écrite en langage humain, puis confrontée au système réel par un agent, avant tout code. 2 · Le test, dérivé de la spec telle qu'elle a été observée, et scellé par l'empreinte de la spec. 3 · La bibliothèque, développée d'après ce dont le test a besoin : jamais un contournement caché dans le test. Trois scripts : agent_contract.py, check_spec_sync.py, check_conventions.py. Ils échouent bruyamment.
1:59 · Un cas réel : le scénario 4
Un cas réel : le scénario 4, sur Terra 2023 (ABAP Platform 2023) : créer un voyage avec une réservation, dans Fiori. La spec est un brief en langage courant : sept lignes, aucun code. Toute forme convient : un objectif, une user story, un scénario BDD… Celui-ci suppose deux choses : une tuile du Launchpad ouvre l'application, et la cible est la démo cap-sflight.
2:25 · Maillon 1 · la spec face au système réel
Maillon 1. L'agent planner, un LLM, confronte le brief au système vivant, avant d'écrire le moindre test. Il ne devine pas. Il envoie MCP : Robot Framework pilote SAP pour de vrai, le LLM ne fait que lire les réponses. Hypothèse 1, une tuile du Launchpad : 62 intents vérifiés sur Terra 2023. Aucun n'ouvre d'application de voyage. Réfutée. Hypothèse 2, cap-sflight : une application CAP locale sur le port 4004. Pas cette cible. Ici, l'application est en RAP : /DMO/UI_TRAVEL_D_D. L'application réelle existe pourtant : 4 136 voyages, et le serveur génère un aperçu Fiori Elements… derrière une erreur HTTP 500. La solution se lit dans le code source du serveur lui-même : l'adresse est obscurcie, +20 par caractère. Décodée : HTTP 200. Avant d'écrire quoi que ce soit : peut-on défaire ? Abandonner un brouillon exige If-Match. Essayé, puis prouvé : réversible. Côte à côte : le brief tel qu'il était supposé, la spec telle qu'elle a été observée sur Terra 2023, ligne par ligne. Pas de tuile, une autre cible, une devise obligatoire que l'écran cache, un identifiant réattribué : rien de tout cela ne se devinait. 12 écarts au total, chacun appuyé par une mesure. Un humain les relit avant que rien ne soit généré. La spec telle qu'observée, avec ses 12 écarts au brief, est écrite, scellée par un sha256 et relue par un humain. Elle devient la source de vérité. À retenir : la spec est observée, pas supposée. Les surprises arrivent avant les tests, pas après.
4:17 · Maillon 2 · le test, dérivé de la spec
Maillon 2. L'agent generator transforme la spec observée en suite Robot Framework, dans un vocabulaire métier. Chaque étape est d'abord exécutée sur Terra 2023, via MCP, et n'est écrite qu'une fois qu'elle fonctionne. Aucun localisateur deviné. La suite porte l'empreinte de la spec, son sha256 : le test sait exactement de quelle spec il est dérivé. Modifiez la spec sans régénérer, et check_spec_sync.py refuse l'exécution. Régénérée, relue : de nouveau en phase. Un script, pas une promesse. À retenir : rien n'est écrit qui n'ait d'abord tourné, et la suite reste scellée à sa spec.
5:02 · Maillon 3 · le test pilote la bibliothèque
Maillon 3. Parfois le test a besoin de quelque chose que la bibliothèque ne sait pas encore faire : un format de date, un en-tête manquant… …alors le manque devient un keyword de la bibliothèque, avec son test unitaire. Jamais un contournement dans le test : check_conventions.py veille. Six capacités, chacune avec son test unitaire : des dates saisies au format propre au champ, If-Match, la release lue par HTTP, l'adresse de l'aperçu… La bibliothèque est publiée sur PyPI, sous le nom robotframework-sapfx. Le projet suivant hérite des six gratuitement. À retenir : le test pilote la bibliothèque, et chaque manque comblé là aide le projet suivant.
5:53 · Un vérificateur indépendant
Stedd change de chapeau. Le vérificateur lit le plan, la suite et les preuves. Il n'exécute rien. Son premier verdict sur la suite verte : non vérifié. 13 réserves, dont 3 bloquantes. Les 13 corrigées, puis une contre-revue : humain requis, 7 points de plus. Corrigés aussi. Chaque garde doit être vue refuser. D'abord la référence, sur Terra 2023 : release 758, 58 services. Puis la suite est pointée sur Terra A4H, exprès : même identifiant système, même nom d'hôte que Terra 2023. Comparaison : 754 ≠ 758, 38 ≠ 58, aucun runtime UI5. Chaque garde refuse. Vu, pas supposé. Seconde provocation : un brouillon planté à la main sur Terra 2023. La garde l'a épargné, le nettoyage l'a supprimé. Trouvé, corrigé, rejoué. À retenir : une garde que personne n'a vue refuser ne prouve rien.
6:58 · Résultat
Résultat : 7 tests sur 7 sur Terra 2023. Chaque voyage créé est supprimé, et sa disparition prouvée, entité par entité. La génération a coûté 1,67 M de tokens LLM, une fois. Le rejeu coûte zéro token : du Python pur, en moins de cinq minutes.
7:19 · Quand le système change
Un cas réel, le 1er septembre : le Demo Kit public d'OpenUI5 a changé de shell du jour au lendemain. Pas une ligne de notre dépôt n'a bougé. La campagne tombe à 8 sur 12. Diagnostic du healer : pas un localisateur, le parcours lui-même a changé. La spec est marquée PÉRIMÉE. Le planner retourne sur la cible réelle, réécrit la spec d'après ce qu'il mesure, et la suite suit : 12 sur 12, de nouveau scellée. L'autre branche, testée à l'aveugle sur Terra A4H : une dérive de localisateur injectée exprès. Le healer lit l'écran vivant… …et corrige une ligne de resources/. Tests touchés : zéro. Rejeu : 7 sur 7. Le STDD est une boucle, pas un pipeline. Le healer répare resources/, jamais le test. Un parcours qui change remonte à la spec, et la suite suit.
8:15 · Conclusion
La spec d'abord, en langage humain. Le test depuis la spec. La bibliothèque depuis le test. Chaque maillon gardé par un script. Observé, dérivé, gardé, et maintenu en vie quand le système change. Merci d'avoir marché avec Stedd, MCP et Terra.
Définition au glossaire, différence avec TDD dans la FAQ, et la méthode complète dans rf-test-agents. Le film suivant montre la mécanique qui permet à ces agents de piloter SAP.
Comment des agents IA pilotent SAP : MCP, rf-mcp, les plugins SAPFX et qa-brain
Comment SAPFX branche des agents IA sur de vrais systèmes SAP, couche par couche : le protocole MCP, le serveur générique rf-mcp et ses trois plugins SAP (un par canal : SAP GUI, Fiori, API), la fine surcouche sapfx-mcp et sa garde de compatibilité, qa-brain, la mémoire QA de l'équipe servie par un second serveur MCP, les clés de chaque agent, les leçons apprises en direct, puis le point clé : MCP sert à concevoir, et la suite qu'il laisse se rejoue sans agent et sans token.
Comment des agents IA pilotent SAP · 8 min 20 · en anglais, voix de synthèse, sous-titres français. Stedd (l'agent IA), MCP (le messager), Terra (le système SAP réel) et qa-brain (la mémoire de l'équipe) suivent un aller-retour réel sur SE16, du protocole jusqu'à l'écran SAP. Leur fil rouge : l'agent parle MCP, les plugins parlent SAP, la mémoire se souvient, et le système réel décide.
Lire la transcription en français
0:00 · Ouverture
Un agent IA ne sait pas cliquer seul sur un écran SAP. Il lui faut un protocole, un moteur de test, et quelque chose qui parle SAP. Voici comment SAPFX branche des agents IA sur des systèmes SAP réels : MCP, rf-mcp, trois plugins, et une mémoire partagée.
0:20 · Les personnages
Stedd est l'agent IA : un modèle de langage, avec un chapeau par métier : planifier, générer, vérifier, réparer. MCP est le messager : le Model Context Protocol, le moyen standard pour un agent d'appeler des outils. Terra est le système SAP réel. Notre banc en compte deux : Terra 2023 et Terra A4H. qa-brain est la mémoire de l'équipe : specs, keywords et leçons d'incidents passés, que les agents peuvent interroger.
0:49 · Ce qui manque
SAP a trois portes : le client lourd SAP GUI, les applications web Fiori, et les services OData et RFC, sans le moindre écran. Un serveur MCP générique pour Robot Framework existe déjà : rf-mcp. Il découvre les keywords, les exécute en direct, et écrit des suites de test. Mais son guide des localisateurs connaît Browser, Selenium et Appium. Les contrôles UI5, le WebGUI, l'écran SAP GUI : rien.
1:19 · Composer au-dessus
Nous n'avons donc pas écrit de nouveau serveur MCP. Nous composons au-dessus de rf-mcp, avec trois plugins : un par canal SAP. rf-mcp garde le travail générique. Les plugins ajoutent ce dont seul SAP a besoin, et les bibliothèques SAPFX pilotent pour de vrai. La même règle que dans tout le projet : ne pas fusionner les paradigmes dans la couche technique. Unifier au-dessus.
1:47 · Trois points d'accroche
Chaque plugin s'enclenche dans rf-mcp par trois points d'accroche, déclarés comme points d'entrée Python : ni fork, ni patch. Accroche un, la table des keywords : Run Transaction va à la bibliothèque qui pilote SAP GUI, Click Ui5 Control à celle de Fiori. Accroche deux, les consignes : viser les contrôles UI5, jamais les id du DOM ; juger un message à son type, jamais à son texte traduit ; jamais de Sleep. Accroche trois, le fournisseur d'état : l'écran SAP vivant devient la source de page de la session. L'agent voit avant d'agir.
2:25 · Un aller-retour
Suivons un aller-retour. Stedd demande à MCP de lancer SE16 sur Terra A4H. Robot Framework l'exécute, et un ticket vert revient. Puis Stedd regarde : le fournisseur d'état renvoie l'écran réel, une ligne par contrôle, les champs modifiables marqués d'un astérisque. Il ouvre la table T000, fixe le nombre maximal de résultats à 300, et regarde de nouveau. Cette fois, seul ce qui a changé revient : un diff de 290 octets au lieu de 11 945. Le contexte de l'agent est épargné à chaque tour. Et rien de fragile ne franchit la frontière : les keywords renvoient du texte brut et des dictionnaires, jamais un objet COM vivant.
3:17 · Trois canaux
Trois canaux, trois plugins. Sur le SAP GUI, le plugin ECC sert la signature d'écran que nous venons de voir. Sur Fiori, rf-mcp demande la page à la bibliothèque Browser, alors le plugin oriente l'agent vers un keyword : Get Ui5 Page Tree, l'arbre des contrôles UI5. Le canal API n'a pas d'écran. Son plugin le dit honnêtement, et sert à la place l'état réel du canal : les sessions ouvertes, jamais les identifiants. Les deux chemins à écran ont été rejoués de bout en bout via rf-mcp : Fiori, 8 sur 8, et SAP GUI, 9 sur 9 sur un système réel.
3:58 · La surcouche sapfx-mcp
Certaines choses échappent au contrat des plugins. Alors une fine surcouche, sapfx-mcp, monte rf-mcp sans le modifier et ajoute trois outils. sapfx_state sert directement notre perception : le diff par défaut, et ce que rf-mcp ne demande jamais, comme une fenêtre d'erreur encore ouverte. sapfx_screenshot envoie une vraie image, avec des cadres numérotés sur chaque cible : l'agent lit un numéro, et agit sur un id vérifié. sapfx_reload recharge les plugins sans redémarrer le serveur. La règle : chaque câblage accepté en amont par rf-mcp rend cette surcouche plus mince. Elle ne doit jamais devenir un fork.
4:43 · La garde
Au démarrage, une garde de compatibilité vérifie la version de rf-mcp et sonde chaque point d'ancrage interne que touche la surcouche. Le 26 septembre, rf-mcp 0.36 est sortie. Deux jours plus tard, notre CI est passée au rouge, alors que personne n'avait touché à la surcouche. C'était la garde, qui refusait une version qu'elle n'avait pas validée. Nous y avons rejoué les deux chemins, puis élargi la fenêtre. Bruyante, jamais silencieuse.
5:12 · qa-brain, la mémoire de l'équipe
Place au second serveur MCP : qa-brain. Un moteur de recherche sur la mémoire QA de l'équipe, qui tourne sur nos propres machines. Il indexe des keywords Robot Framework, des specs, de la documentation, et des leçons écrites après de vrais incidents : 1 383 passages, au 29 septembre. Avant une décision de jugement, l'agent demande. Ici, le planner demande comment trouver un champ sur un écran de sélection SE16, où les champs sont numérotés par position. qa-brain répond avec ses sources : le keyword de la bibliothèque qui déduit ces champs, et la spec qui les avait signalés la première. Trois règles. Le système vivant tranche : un passage est une piste, jamais une preuve. La source est citée. Et qa-brain ne bloque jamais le travail. L'enjeu : une leçon que quelqu'un a déjà payée, sur un vrai incident, ne se paie pas deux fois.
6:09 · Qui tient quelle clé
Chaque agent reçoit seulement les clés dont il a besoin. Le planner, le generator et le healer pilotent SAP via rf-mcp. Le verifier n'a aucun outil SAP : il ne fait que lire. C'est ce qui rend sa revue indépendante. Les cinq peuvent interroger qa-brain, jusqu'au concepteur ISTQB, qui travaille hors ligne. Par-dessus, un hook de permissions laisse passer les lectures et demande avant le reste. Seul un humain active l'autonomie.
6:47 · Appris en direct
Certaines leçons se sont payées en direct. rf-mcp exécute les keywords hors du thread principal, et le scripting SAP GUI, c'est du COM : chaque thread doit d'abord l'initialiser. Le 7 septembre, un regard depuis le mauvais thread est revenu vide, et vert. Désormais, il échoue, nomme la cause, et se rattache. Le serveur garde aussi le code de bibliothèque chargé au démarrage. Quand notre code change sur le disque, les réponses d'état portent un avertissement de code périmé. Et une règle d'hygiène : une seule session SAP GUI vivante par serveur, fermée à la fin, même après un échec.
7:27 · Conception, exécution
Voici le point clé. MCP sert à la conception : explorer, vérifier chaque étape en direct, réparer, se souvenir. Ce qu'il laisse derrière lui est une suite Robot Framework ordinaire. Elle se rejoue avec la commande robot : sans agent, sans MCP, zéro token.
7:49 · Récapitulatif
Agent, protocole, moteur, plugins, bibliothèques, système, et une mémoire partagée : chaque couche fait un seul travail.
8:01 · Conclusion
L'agent parle MCP. Les plugins parlent SAP. La mémoire se souvient. Et le système réel décide. Open source, construit sur rf-mcp. Merci d'avoir volé avec Stedd, MCP, Terra et qa-brain.
Les plugins et la surcouche sapfx-mcp font partie de SAPFX ; les agents sont ceux de rf-test-agents, et qa-brain est le RAG local de CabrIA. Les chiffres cités dans le film sont ceux de sa réalisation, le 29 septembre 2026 ; au 9 octobre 2026, qa-brain indexe 4 119 passages. Le film suivant résume tout cela en sept principes.
L'état d'esprit de SAPFX : sept principes, une boîte à outils, ce que cela change
Pourquoi SAPFX est conçu comme il l'est, en sept principes appuyés sur des cas réels : unifier au-dessus des canaux SAP, laisser le système réel trancher, ne jamais être vert et faux, voir avant d'agir, l'IA conçoit et Robot rejoue, un manque devient une capacité, des règles appliquées et non seulement énoncées. Puis la boîte à outils complète, et ce qui change concrètement, y compris ce que SAPFX n'a pas (support éditeur, éditeur graphique).
L'état d'esprit de SAPFX · 11 min 11 · en anglais, voix de synthèse, sous-titres français. Les personnages des films précédents (Stedd, MCP, Terra, qa-brain) accueillent trois nouveaux venus : You (l'humain qui décide), RF (Robot Framework à l'exécution) et Gate (les gardes mécaniques). Chaque principe se clôt par une carte « Remember » (à retenir).
Lire la transcription en français
0:00 · Ouverture
Bien tester SAP ne tient pas à un seul outil. C'est une façon de travailler, et ce film raconte l'état d'esprit qui sous-tend SAPFX. Ce que nous construisons, comment nous le construisons et ce que cela change, raconté par les personnages de nos films précédents et trois nouveaux venus.
0:18 · Les personnages
Quatre habitués de nos films précédents : Stedd, l'agent IA, MCP, son messager, Terra, le système SAP réel, et qa-brain, la mémoire de l'équipe. Stedd porte un chapeau par métier : planifier, générer, vérifier, réparer. Et Terra a un jumeau sur notre banc : Terra 2023 et Terra A4H. Trois nouveaux venus. You : la personne qui décide. You écrit la spec en langage courant et relit ce qui revient. RF est Robot Framework à l'exécution. Il rejoue ce qui a été écrit, à l'identique, aussi souvent que vous voulez : pas d'agent, pas de modèle, zéro token. Et Gate : les scripts qui disent non. Sans opinion ni humeur : la même réponse à chaque fois, verte ou rouge.
1:04 · Le problème du test SAP
SAP n'est pas une seule application. Il a un client lourd, des applications web Fiori, SAP GUI dans un navigateur, et des services OData et RFC. Les tests écrits contre lui cassent pour rien : un identifiant renommé, un message traduit, une attente fixe trop courte d'une seconde. Pire, certains passent alors qu'ils ne devraient pas. Un test peut être vert et faux : il a regardé une grille vide, ou le mauvais système. Le marché compte trois familles. Les suites commerciales : complètes, supportées, sous licence. Les outils de SAP lui-même : inclus, mais limités. Et l'open source : libre et ouvert, historiquement un canal à la fois. SAPFX en fait partie et apporte ce qui manquait : les trois canaux. Il repose sur sept principes. Les voici, un par un.
1:55 · Principe 1 · Unifier au-dessus
Principe un : unifier au-dessus. Les tests parlent un seul vocabulaire métier. En dessous, trois bibliothèques parlent chacune un langage SAP. SapEccLibrary pilote le client lourd par son API de scripting. SapFioriLibrary pilote le navigateur, avec cinq façons de trouver un contrôle. SapApiLibrary parle OData et RFC. Et une logique commune, testée sans aucun système SAP, se trouve sous les trois. Les mêmes mots sur chaque canal : compter les entrées d'une table à l'écran, compter les entités métier par OData, compter les enregistrements métier par RFC. Un même fait peut donc être vérifié deux fois : 205 produits à l'écran, 205 par OData. Trois canaux s'accordent même sur le prix d'un produit. À retenir : écrire le test une fois, en mots métier. Le canal en dessous est un détail, pas une réécriture.
2:51 · Principe 2 · Le système réel tranche
Principe deux : le système réel tranche. You écrit la spec en langage courant : un objectif, une user story, un scénario BDD, un ancien test. Le planner la confronte à Terra, en direct. Ce que le système réfute passe au rouge : trois, deux, puis cinq hypothèses fausses sur trois scénarios récents. Ce qui survit est la spec observée. You la relit, puis elle est scellée : le test en est dérivé, puis la bibliothèque à partir du test. Modifiez la spec sans régénérer la suite, et Gate refuse : check spec sync compare une empreinte, à chaque fois. C'est la logique du développement piloté par les tests, une brique plus tôt : une spec que personne n'a confrontée est verte par défaut, jamais par preuve. À retenir : une spec que personne n'a confrontée est verte par défaut, pas par preuve. La spec observée pilote le test.
3:44 · Principe 3 · Jamais vert et faux
Principe trois : jamais vert et faux. Un test qui ne peut pas prouver ce qu'il a vu doit échouer, et échouer bruyamment. Les assertions lisent le type de message, jamais le texte traduit. Et les tests attendent que SAP soit au repos, jamais une pause fixe. Nos deux systèmes partagent le même identifiant et le même nom d'hôte. Seule la release les distingue, donc nos campagnes prouvent d'abord leur cible. Les tables se chargent paresseusement. Une grille a rendu 1 639 lignes, dont 137 seulement remplies. Une grille web a envoyé 200 lignes sur 2 000. Une table Fiori, 30 sur 4 133. Chaque ligne semblait parfaite. Aussi chaque extraction est-elle comparée au total que la table déclare, et refusée quand ils diffèrent. Et quand la perception ne peut pas lire l'écran, elle échoue désormais en nommant la cause, au lieu de rendre une réponse vide et verte. À retenir : un test qui ne voit pas doit échouer, bruyamment. Les cibles sont prouvées, les totaux sont déclarés.
4:53 · Principe 4 · Voir avant d'agir
Principe quatre : voir avant d'agir. Un agent n'agit jamais sur ce dont il se souvient d'un écran, seulement sur ce qu'il perçoit maintenant. Les bibliothèques lisent l'écran en direct comme du texte : chaque champ, son libellé, sa valeur. Ou comme une carte numérotée, pour que l'agent dise : remplis le numéro un. Après une action, seule la différence revient : 290 octets, au lieu de 11 945 pour l'écran entier. Les localisateurs peuvent être humains : remplir le champ libellé Table Name. Le libellé ne doit désigner qu'un seul champ, sinon l'étape échoue. Quand un identifiant dérive, la bibliothèque propose la correspondance la plus proche, notée, et journalise chaque réparation. Le healer corrige la couche partagée, jamais le test. À retenir : l'agent agit sur ce qu'il perçoit, pas sur ce dont il se souvient. Chaque réparation est journalisée, jamais silencieuse.
5:50 · Principe 5 · L'IA conçoit, Robot rejoue
Principe cinq : l'IA conçoit, Robot rejoue. À la conception, les agents travaillent par MCP, sur le système réel. Le planner explore, le generator exécute chaque étape avant de l'écrire, un verifier indépendant se contente de lire, et le healer répare. Ils consultent qa-brain avant de trancher un point de jugement. Et seul You peut activer le mode autonome : un interrupteur réservé aux humains. Ce que les agents laissent derrière eux est une suite Robot Framework ordinaire. RF la rejoue aussi souvent que vous voulez, sans agent ni modèle : zéro token. Les tokens se paient une fois, à la conception : 3,8 millions pour notre scénario Business Partner. Son rejeu prend trente secondes, et zéro token. RF exécute aussi une sentinelle de dérive : des écrans surveillés comparés à leur référence, sans test écrit. Elle signale un changement, et ne le qualifie jamais de bug. À retenir : les tokens se paient une fois, à la conception. Ce qui reste est du Robot Framework ordinaire, rejoué gratuitement.
6:59 · Principe 6 · Un manque devient une capacité
Principe six : un manque devient une capacité. Quand une campagne se heurte à un mur sur un système réel, la correction ne reste pas dans le test. Elle devient un keyword de la bibliothèque, avec son test unitaire, sa page de documentation et son entrée de changelog. Puis elle est publiée sur PyPI, pour tout le monde. Le sept septembre, une campagne a listé dix-huit choses que notre bibliothèque pour le client lourd ne savait pas encore faire, chacune reproduite par un test. Les corrections ont été livrées le soir même. Rejoué tel quel, le registre est passé au rouge dix-huit fois, en nommant chaque nouvelle capacité. C'est ainsi que nous savons qu'il mesure. À retenir : un mur rencontré sur un système réel devient un keyword de la bibliothèque. La correction est livrée à tous, jamais cachée dans un test.
7:51 · Principe 7 · Des règles appliquées
Principe sept : les règles sont appliquées, pas seulement énoncées. Une règle que personne ne vérifie n'est qu'un souhait. Gate bloque une suite plus ancienne que sa spec, un identifiant SAP brut dans un test, un fichier de code de plus de 500 lignes, un chiffre de notre communication que le code n'étaie pas. Il bloque une couverture sous 85 %, et tout fichier privé en route vers le dépôt public. Ces contrôles tournent en CI, et la plupart aussi après chaque modification. Plusieurs de ces règles sont nées d'un incident réel. Écrites dans un script, elles ne peuvent pas être oubliées, et elles ne discutent jamais : vert, ou rouge. À retenir : une règle que personne n'applique est un souhait. Ici, des scripts disent non, de la même façon à chaque fois.
8:46 · La boîte à outils
Voici toute la boîte à outils. Trois bibliothèques et leur socle commun, sur PyPI, sous Apache 2.0. Deux enregistreurs, bureau et web : You déroule un parcours à la souris, et obtient une suite Robot, des keywords métier, un brouillon de spec, un cas de test ISTQB, un rapport. Cinq agents et une skill. rf-mcp avec trois plugins SAP et sa surcouche, et qa-brain, la mémoire de l'équipe. Une sentinelle de dérive, des références visuelles, la télémétrie de réparation, un contrôle de posture de sécurité, et l'extraction de tables vers cinq formats, du CSV au Parquet. Et pour le poste de travail, un pack Windows qui s'installe en une commande, avec une documentation en anglais et en français.
9:39 · Ce que cela change
Alors, qu'est-ce que cela change ? D'abord, c'est ouvert : Apache 2.0, aucune licence à payer, aucun verrouillage, et le code des bibliothèques est lisible par tous. Un seul vocabulaire métier pour le client lourd, le web et le canal API, là où les outils open source ne couvraient historiquement qu'un canal chacun. L'IA là où elle aide, à la conception, et un rejeu déterministe à l'exécution. Et la spec est observée sur le système réel, pas supposée. Des preuves, pas des promesses : 321 scénarios validés en direct sur quatre systèmes SAP réels, et 2 560 tests unitaires avec 94 % de couverture. Ce qu'il n'a pas : un support éditeur et un mode sans code. Les suites commerciales offrent les deux, et pour certaines équipes cela compte. Notre place sur la carte : les capacités d'une suite commerciale, au coût de l'open source.
10:39 · Conclusion
Sept principes : unifier au-dessus, le système réel tranche, jamais vert et faux, voir avant d'agir, l'IA conçoit et Robot rejoue, un manque devient une capacité, et les règles sont appliquées, pas seulement énoncées. You décide de ce qui compte. Les agents font le gros du travail. RF rejoue, gratuitement. Et quoi que chacun suppose, le système réel tranche.
C'est la synthèse des trois films précédents : l'IA dans les tests, la méthode STDD et les agents qui pilotent SAP. Les bibliothèques sont celles de SAPFX, les agents ceux de rf-test-agents. Les chiffres cités dans le film sont ceux de sa réalisation, le 30 septembre 2026 ; à la version 0.8.5 du 13 octobre 2026, SAPFX compte 462 scénarios joués en direct sur quatre systèmes SAP réels, 3 959 tests unitaires et 95 % de couverture de code.
Parlons de votre projet
Automatisation SAP, IA locale ou qualité logicielle : échangez avec notre équipe technique.
- Un échange technique, pas commercial
- Vos données restent en France