En option · Sur devis · Autour des bibliothèques v0.8.5

Les outils de l'atelier SAPFX : écrire, faire écrire et maintenir vos tests SAP

Les outils de l'atelier SAPFX sont des outils en option, délivrés sur devis, qui accélèrent l'écriture et la maintenance des tests SAP automatisés avec Robot Framework : un enregistreur SAP GUI, un enregistreur pour SAP Fiori et le WebGUI, un outil qui note les demandes de test avant de les confier aux agents, cinq agents IA et leur cadre, un pont MCP pour les assistants IA, de la maintenance préventive, une cartographie des interfaces de votre système SAP, une couche métier d'exemple et un pack d'installation pour Windows. Ils s'ajoutent aux bibliothèques SAPFX (paquet robotframework-sapfx, Apache 2.0, gratuites sur PyPI), qui pilotent SAP GUI, SAP Fiori, OData et RFC et suffisent pour écrire et exécuter vos tests. Les outils ne remplacent rien : ils produisent des tests Robot Framework ordinaires, qui appellent les mêmes keywords.

Voir les dix outils Bibliothèques sur PyPI Page SAPFX

Atelier SAPFXEn option · sur devis

Enregistreur SAP GUI Enregistreur web Prompt Eval Agents IA Contrat des agents Pont MCP Maintenance préventive Cartographie Couche métier d'exemple Pack Windows

produisent des fichiers .robot et .resource ordinaires

Bibliothèques SAPFXIncluses · gratuites

SapEccLibrarySAP GUI · 195

SapFioriLibraryFiori, WebGUI · 98

SapApiLibraryOData, RFC · 149

442 keywords · pip install robotframework-sapfx · Apache 2.0

outils autour des bibliothèques

agents IA spécialisés SAP

formats d'export par enregistreur

plugins MCP, un par canal

Inclus ou en option

Deux couches, un seul moteur

Les outils ne sont pas une autre version de SAPFX : ils s'appuient sur les bibliothèques et ne servent qu'avec elles.

Incluses · gratuites

Les bibliothèques

pip install robotframework-sapfx, licence Apache 2.0, sans inscription
442 keywords pour SAP GUI, SAP Fiori, le WebGUI, OData et RFC
Perception de l'écran, attente de l'état réel de SAP, réparation de localisateur toujours journalisée, assertions visuelles
Documentation publique des keywords et dépôt GitHub public

En option · sur devis

Les outils de l'atelier

Hors du paquet PyPI et hors du dépôt public
Délivrés sur devis, sous la forme d'un pack de déploiement Windows
Installation, formation et adaptation de la couche métier, selon le périmètre du devis
Les fichiers qu'ils produisent vous appartiennent

Une règle de conception : aucun format propriétaire. Un test enregistré, généré ou réparé par l'atelier reste un fichier .robot accompagné de fichiers .resource, lisibles, versionnés avec votre code et lancés par robot avec les bibliothèques. Retirez les outils : vos tests et vos keywords métier restent, et tournent.

Avec ou sans l'atelier

Ce que les outils changent, tâche par tâche

Tout reste possible avec les bibliothèques seules. Les outils raccourcissent les étapes longues ; aucun gain chiffré n'est annoncé, faute de mesure.

Tâche	Avec les bibliothèques seules	Avec les outils de l'atelier
Écrire un premier test	À la main, avec la documentation des keywords ; `Get Screen Map` numérote ce que l'écran contient.	Vous déroulez le parcours ; l'enregistreur en écrit le brouillon, rejouable aussitôt.
Choisir un localisateur stable	Les keywords de perception montrent les contrôles ; le choix vous revient.	L'enregistreur propose le localisateur que la bibliothèque résoudra : type de contrôle UI5, libellé vérifié, SID.
Vérifier une demande avant de la confier aux agents	Vous la relisez ; rien ne la mesure.	Prompt Eval note sa forme et huit critères, et sonde le système : une demande injouable est repérée avant la dépense.
Passer d'une demande métier à une suite	Vous traduisez la demande en étapes et vérifiez chacune.	sap-planner écrit le plan observé sur le système ; sap-generator exécute chaque étape avant de l'écrire.
Réparer après une montée de version	Chaque localisateur réparé est journalisé ; vous corrigez la couche resources.	Le rapport de dérive propose le correctif ; sap-healer le vérifie sur le système et répare, sans toucher aux tests.
Voir qu'un écran a changé	Le keyword `Check Screen Against Watch` compare un écran à sa référence.	Une suite sentinelle prête à planifier surveille une liste de transactions et rédige le rapport.
Cartographier les interfaces du système	Les keywords de lecture par RFC rendent destinations, profils IDoc et services ; l'assemblage reste à faire.	Un relevé en lecture seule, rapproché de vos référentiels, rendu en planches A3 et en rapport, avec ses preuves à l'écran.
Faire travailler un assistant IA	rf-mcp exécute des keywords, sans voir l'écran SAP.	Les plugins lui donnent l'écran SAP en texte, en différentiel ou en image annotée.
Équiper un poste de test	`pip install`, puis chaque dépendance à son tour.	`install.cmd` : environnement local, versions épinglées, intégrité vérifiée, MCP configuré.
Documenter pour la recette	Le rapport et le journal de Robot Framework.	Plans et cas de test ISTQB exportés par les enregistreurs, revus par sap-istqb.
Reprendre une mission interrompue	Repartir du début.	Un autre agent reprend depuis le fil de reprise, après avoir prouvé la cible à nouveau.

Les outils, un par un

Dix outils pour écrire et maintenir les tests SAP

Pour chacun : ce qu'il fait, ce que vous obtenez, ses limites, et la preuve qu'il fonctionne.

Enregistreur de bureau01 / 10

Enregistreur SAP GUI : déroulez le parcours, récupérez un test qui se lance

Vous travaillez dans SAP GUI pour Windows comme d'habitude ; l'enregistreur transcrit chaque geste en keyword de SapEccLibrary. Par défaut il écoute les événements de l'API SAP GUI Scripting, ce qui capte aussi boutons, grilles et arbres, et se replie sur une lecture de l'écran quand le serveur interdit l'enregistrement.

En mode sémantique, un champ est désigné par son libellé visible (Fill Field By Label Table Name T000) plutôt que par son identifiant technique, et seulement si ce libellé désigne bien le même élément : sinon l'identifiant reste. Le fichier produit est une suite complète, qui se lance telle quelle avec robot.

Preuve : filmé en prise réelle le 4 octobre 2026 sur ABAP Platform 1909, jusqu'au rejeu des exports par Robot Framework ; les défauts trouvés en filmant ont été corrigés le jour même.

Lanceur de l'enregistreur de bureau SAPFX pour SAP GUI — **Lanceur de l'enregistreur SAP GUI** : modes capture, survol et enregistrement, exports au choix.poste Windows

Enregistrer, puis rejouer

> python tools/recorder/sapgui_recorder.py --record --engine native --semantic --export-resources
# autres exports : --export-spec  --export-istqb  --export-report
> python tools/recorder/sapgui_recorder.py --replay parcours.robot
# recorder.cmd ouvre le lanceur graphique

Ce qu'il fait

Enregistre par les événements de l'API (moteur natif) ou par lecture de l'écran, au choix ou automatiquement
Pose des assertions pendant l'enregistrement : Ctrl+Alt+A pour la valeur du champ actif, Ctrl+Alt+V pour l'empreinte visuelle de l'écran
Rejoue un enregistrement contre la session SAP GUI ouverte et s'arrête à la première étape en échec
Convertit un script VBS du recorder intégré à SAP GUI (Alt+F12), sans session SAP
Lanceur graphique : mode, exports, panneau des étapes à réordonner, modifier ou supprimer

Ce que vous obtenez

Une suite .robot complète et rejouable
Une paire « resource et suite » : keywords métier d'un côté, test sans identifiant brut de l'autre
Un plan au format specs/, point d'entrée des agents
Un plan et des cas de test ISTQB, avec un bloc de rejeu
Un rapport HTML de documentation, captures comprises

Ses limites

SAP GUI pour Windows uniquement
Un enregistrement est un brouillon : on le relit avant d'en faire un test
La lecture de l'écran suit un rythme humain ; un parcours joué par un script s'enregistre avec le moteur natif

Extension de navigateur02 / 10

Enregistreur web : le localisateur que la bibliothèque résoudra, pas un identifiant généré

Une extension Chrome (Manifest V3) enregistre vos gestes dans les applications SAP Fiori, SAPUI5, SAP GUI for HTML et les pages hybrides. Chaque clic devient un keyword de SapFioriLibrary, avec le localisateur que la bibliothèque résout à l'exécution : le type et les propriétés du contrôle UI5, jamais l'identifiant DOM qui change d'un chargement à l'autre.

Le panneau rejoue le déroulé dans la page avant tout export, ce qui valide l'enregistrement sans lancer robot. Dans la paire « resource et suite », les étapes UI5 deviennent auto-réparables : le XPath relevé à l'enregistrement sert de repli.

Preuve : validé contre une application SAP Fiori Elements (cap-sflight, SAPUI5 1.139) : la suite exportée et la paire « resource et suite » rejouées vertes par Robot Framework, l'effet mesuré dans l'application (4 133 voyages filtrés à 91). Les exports sont tenus par une suite hors ligne.

Enregistreur web SAPFX en cours d'enregistrement sur le Demo Kit OpenUI5 — **Enregistreur web** sur le Demo Kit OpenUI5 public (SAPUI5 1.151) : le champ de recherche est désigné par son type de contrôle UI5, chaque geste devient une ligne.Demo Kit OpenUI5Écran d'une application SAPUI5 : le logo SAP et les marques SAP sont la propriété de SAP SE.

Installer l'extension

# chrome://extensions, mode développeur activé
# « Charger l'extension non empaquetée » : tools/recorder_web/extension
# puis Alt+Shift+R sur l'onglet de l'application SAP

Ce qu'il fait

Cinq moteurs de localisation : contrôle UI5 par type et propriétés, XPath de contrôles UI5, SID du WebGUI, UI5 Web Components, DOM générique par rôle et nom accessible
Enregistre clics, saisies, touche Entrée et navigation, avec attente du repos de la page UI5
Clic droit : menu d'assertions (visible, texte)
play rejoue dans la page, +test ajoute un scénario, un .robot exporté se réimporte
Raccourci Alt+Shift+R pour démarrer et arrêter

Ce que vous obtenez

Une suite .robot complète, ouverture du navigateur comprise
Une paire « resource et suite » à keywords auto-réparables
Un plan au format specs/
Un plan et des cas de test ISTQB
Un rapport HTML de documentation

Ses limites

Extension chargée depuis le pack, non publiée sur le Chrome Web Store
Iframes d'une autre origine : un panneau par frame accessible, pas de vue d'ensemble
Un brouillon, à relire avant d'en faire un test

Notation des demandes03 / 10

Prompt Eval : noter une demande de test avant que les agents ne la traitent

Une demande confiée aux agents (une fiche scénario écrite en langage humain) est un prompt, et la traiter de bout en bout, du plan aux revues, coûte de l'ordre de deux millions de tokens d'agents sur nos campagnes. Prompt Eval la note avant cette dépense, à trois niveaux : sa forme, vérifiée sans aucun appel à un modèle contre la règle de rédaction de l'atelier ; sa part de gabarit, mesurée sur le lot entier, parce qu'une ligne reprise telle quelle par d'autres demandes ne dit rien de celle-ci ; et huit critères jugés par un modèle de langage en un appel par demande (intention, faits contre hypothèses, niveau de preuve, assertion qui tranche, cible, répétabilité, capacités, posture), chacun noté de 1 à 5 avec un motif qui cite la demande.

Le juge est fermé sur l'échec : un modèle injoignable, une réponse illisible ou un critère absent valent zéro avec un motif, jamais une réussite. Le juge configuré tourne en local, servi par LM Studio sur la station qui sert aussi la mémoire QA de CabrIA ; tout point d'accès compatible OpenAI peut le remplacer. Une sonde de faisabilité vérifie enfin par RFC, en lecture seule et sans un token d'agent, que les transactions, tables et modules fonction nommés par la demande existent sur chaque système cible, prouvé par sa release.

Preuve : premier passage du 10 octobre 2026 sur les 160 demandes de l'atelier : 150 hors de la forme de référence, 88 % de lignes de gabarit dans le lot du 4 octobre ; la sonde a rendu 25 demandes jouables, 71 bloquées et 64 à qualifier sur ABAP Platform 1909.

Noter, juger, sonder

> python -m tools.prompt_eval check
# forme et part de gabarit, aucun appel à un modèle ; code 1 si une demande échoue
> python -m tools.prompt_eval score --only 21,100 --samples 3
# huit critères jugés, médiane de trois jugements
> python -m tools.prompt_eval feasibility --cibles a4h
# objets SAP nommés, sondés par RFC en lecture seule
> python -m tools.prompt_eval gui --open

Ce qu'il fait

Forme et part de gabarit vérifiées sans aucun appel à un modèle, avec un code de retour exploitable en intégration continue
Huit critères notés de 1 à 5 par un juge, médiane de plusieurs jugements au choix, motifs qui citent la demande
Sonde de faisabilité par RFC en lecture seule : jouable, bloquée (l'objet manquant est nommé) ou à qualifier
Runs versionnés, comparaison de deux runs avec test de significativité et rapports HTML, par notre moteur d'évaluation de prompts PEW (Prompt Eval Workflow)
Interface locale : note, critères, motifs et faisabilité demande par demande, notation lancée en arrière-plan

Ce que vous obtenez

Une note par demande, avec les constats et les motifs qui l'expliquent
La liste des demandes injouables sur une cible, avant d'y lancer un agent
La mesure de ce qu'une réécriture des demandes a changé, run contre run

Ses limites

La note mesure la rédaction d'une demande, pas son coût : l'étude initiale sur treize demandes traitées ne montre pas de relation significative
« Jouable » dit que les objets nommés existent, pas que les autorisations, les données ou le flux métier sont là : l'exploration sur le système reste à faire
Les huit critères demandent un juge ; la forme, la part de gabarit et la faisabilité s'en passent
Nouveau, pas encore dans le pack de déploiement Windows

Agents IA04 / 10

Cinq agents qui planifient, écrivent, réparent et relisent vos tests, sous contrôle humain

Les agents travaillent dans Claude Code ou GitHub Copilot et pilotent SAP à travers le pont MCP décrit plus bas. Ils appliquent la méthode Spec-Test-Driven Development : une demande écrite en langage humain est confrontée au système réel avant d'écrire le moindre test, chaque étape est exécutée sur SAP avant d'être écrite, et la suite porte l'empreinte du plan dont elle dérive.

Un contrat commun fixe ce qu'un agent peut toucher : la réparation se limite à la couche de keywords métier, jamais au test ni à ses assertions, avec un budget borné (2 candidats, 20 appels, 15 minutes) et un verdict nommé.

Demande en langage humainsap-planner : plan observésap-generator : suite exécutée avant d'être écritesap-verifier : revuesap-istqb : revue de conception

Preuve : six campagnes planifiées, générées et revues par ces agents du 24 septembre au 1er octobre 2026, sur ABAP Platform 1909 et 2023 : voyage RAP 7/7, rôle Business Partner 7/7, sentinelle My Inbox 7/7, tuile du launchpad 6/6, IDoc 12/12, job de fond et spool 11/11.

tests/robot/cross/idoc_sortant_ale_a4h.robot

*** Settings ***
# …
...                 Spec: specs/idoc-sortant-ale-a4h.md (sha256:f5ddc14105b7, 2026-10-01)
...                 Generated from specs/idoc-sortant-ale-a4h.md by sap-generator:
...                 re-run the generator rather than hand-editing locators here.
# …
1. Un IDoc sortant émis atteint le statut 03, jugé par son code, et son entrant n'est pas oublié
    # …
    ${email}=    New Run Email
    ${cree}=    Send Flight Customer Change Idoc    ${TEST_CUSTOMER}    ${email}
    # …
    Dispatch Idoc By Number    ${docnum}
    ${sortant}=    Wait For Idoc Status    ${docnum}    expected=success    timeout=${IDOC_WAIT}
    Should Be Equal    ${sortant}[status]    ${STATUS_OUTBOUND_PASSED_TO_PORT}
    # …
    ${lien}=    Get Idoc Counterpart    ${docnum}    timeout=${COUNTERPART_WAIT}
    Track Run Idoc    ${lien}[counterpart]
    ${entrant}=    Wait For Idoc Status    ${lien}[counterpart]    expected=${STATUS_INBOUND_POSTED}
    ...    timeout=${IDOC_WAIT}
    Should Be Equal    ${entrant}[status]    ${STATUS_INBOUND_POSTED}
    Flight Customer Email Should Be    ${TEST_CUSTOMER}    ${email}

Ce qu'il fait

sap-planner explore le système et écrit un plan observé dans specs/
sap-generator exécute chaque étape avant de l'écrire et scelle la suite par l'empreinte SHA-256 du plan
sap-healer reproduit un échec et répare la couche resources, jamais le test
sap-verifier relit en lecture seule contre l'invariant métier et les preuves
sap-istqb rédige plans et cas de test ISTQB et revoit la conception de chaque suite

Ce que vous obtenez

Des commandes prêtes : /sap-plan, /sap-generate, /sap-heal, /sap-verify, /sap-istqb, /sap-maintain
Des plans relus par un humain avant toute génération
Un journal de chaque réparation et un rapport de revue avec verdict
Les définitions pour VS Code et GitHub Copilot, générées depuis la même source

Ses limites

Un assistant IA est nécessaire (Claude Code ou GitHub Copilot), avec votre abonnement et votre politique de données
Les gestes importants (commit, push, suppression, installation, publication) demandent toujours un accord, même en mode autonome
Ils accélèrent, ils ne décident pas : plans et revues se relisent

Contrat et continuité05 / 10

Un cadre qui borne les agents et leur permet de reprendre après une coupure

Un agent n'agit pas seul sur un système SAP. Le plan produit un fichier de mission qui grave la cible autorisée et l'invariant métier ; un script le valide, avec les empreintes des preuves, et une revue indépendante relit le résultat. Un hook de permissions laisse passer les lectures et demande l'accord pour le reste ; le mode autonome ne s'active que par un humain, sur son poste, et les gestes importants y demandent toujours un accord.

Une mission interrompue (serveur redémarré, délai dépassé, plantage) se reprend : relevés, décisions et prochaine étape sont écrits au fil de l'eau, une entrée par fichier, jamais réécrite. Reprendre, c'est rouvrir les sessions, prouver la cible et percevoir à nouveau : le fil ne rejoue rien et n'accorde aucune permission.

Preuve : la validation des fichiers de mission tourne en intégration continue et dans un test unitaire ; le jour de sa première exécution, trois fichiers de mission sur six étaient invalides, pour trois raisons différentes, et ont été corrigés.

Contrat, politique et reprise

> python scripts/agent_contract.py handoff --all
# chaque fichier de mission : cible, invariant, empreintes des preuves
> python scripts/agent_policy.py status
# politique de permissions du poste (seul un humain la change)
> python scripts/agent_handover.py resume ma-mission
# valide le fil et rend ce qu'un agent doit savoir pour reprendre

Ce qu'il fait

Fichier de mission validé par script : cible, invariant, empreintes des preuves
Verdicts nommés du réparateur : réparé et vérifié, défaut applicatif, bloqué, humain requis, non vérifié
Hook de permissions pour Claude Code et GitHub Copilot ; politique autonome changée par un humain seulement
Fil de reprise immuable et journal des écritures métier, qui ne rejoue jamais rien
Skill sapfx : les quatre canaux, la boucle perception puis action, les conventions et le cycle des agents, en un appel

Ce que vous obtenez

Des missions traçables : quelle cible, quel invariant, quel verdict
Une reprise sans perte après une coupure, par un autre agent
Une skill embarquée dans le pack, utilisable sans accès au dépôt

Ses limites

Le cadre borne les agents, il ne garantit pas qu'ils réussissent : « je n'ai pas réussi » est une sortie prévue
Le hook agit dans les hôtes qui le chargent : son chargement se vérifie avant de s'y fier
Aucun secret dans le fil : les identifiants se donnent à nouveau à la reprise

Plugins MCP06 / 10

Le pont MCP : un assistant IA qui voit l'écran SAP avant d'agir

rf-mcp est un serveur MCP open source qui exécute des keywords Robot Framework pas à pas pour un assistant IA ; il ne connaît pas SAP. Les trois plugins SAPFX lui apportent la perception : l'écran SAP GUI sous forme de signature texte, l'arbre des contrôles UI5 d'une page SAP Fiori, l'état du canal API, et un écran déjà vu renvoyé en différentiel plutôt qu'en entier.

La surcouche sapfx-mcp lance rf-mcp tel quel et ajoute quatre outils que le contrat des plugins ne permet pas : l'état SAP lu en direct, la capture d'écran réelle (brute ou annotée de cibles numérotées), le rechargement des plugins sans redémarrer et, depuis le 9 octobre 2026, l'approbation par un humain d'une écriture sur SAP : l'agent ne peut pas s'approuver lui-même.

Preuve : parcours de bout en bout à travers rf-mcp 0.36, rejoués le 28 septembre 2026 : SAP Fiori 8/8 sur une page de test, SAP GUI 9/9 contre ABAP Platform 1909, état servi par les plugins compris ; approbation humaine à travers rf-mcp, 30/30 sur ABAP Platform 2023 et sur 1909, le 9 octobre 2026.

SAP GUI : écran de sélection SE16 de SNWD_PD, chaque champ encadré et numéroté — **Capture annotée de l'écran de sélection SE16** : 86 cibles numérotées, la vue qu'un agent reçoit en mode annoté, produite par le keyword `Get Annotated Screenshot` de la bibliothèque.A4H, release 754 · Capture du 5 octobre 2026Écran d'un logiciel SAP : le logo SAP et les marques SAP sont la propriété de SAP SE.

Serveur MCP déclaré par l'installateur

> sapfx-mcp --transport stdio --without-frontend
# rf-mcp inchangé, plus quatre outils :
#   sapfx_state          état SAP lu en direct, en différentiel
#   sapfx_screenshot     capture brute ou annotée (cibles numérotées)
#   sapfx_reload         rechargement des plugins sans redémarrer
#   sapfx_approve_write  un humain approuve l'écriture suivante

Ce qu'il fait

Routage des keywords vers la bonne bibliothèque et guidance de localisateurs propre à SAP
sapfx_state : transaction, pile de fenêtres, modal ouvert, type du message de statut
sapfx_screenshot : image de l'écran, avec des cibles numérotées que l'agent désigne par leur numéro
sapfx_reload : rechargement à chaud de la couche plugin
sapfx_approve_write : la demande d'écriture (raison, cible, système, mandant, écran) est montrée à un humain, qui approuve ou refuse ; sans réponse, c'est un refus. Quand le client MCP ne sait pas afficher la demande, une boîte de saisie s'ouvre sur le poste
Avertissement quand le code SAPFX a changé depuis le démarrage du serveur

Ce que vous obtenez

Un serveur MCP déclaré pour Claude Code (.mcp.json) et pour VS Code (.vscode/mcp.json), écrit par l'installateur
Un état du canal API sans aucun identifiant de connexion
Une approbation liée à une cible et consignée dans le journal d'audit, avec son approbateur

Ses limites

Une session SAP GUI en direct par processus serveur
Versions de rf-mcp validées de 0.31 à 0.36 : une version non validée est refusée au démarrage
L'approbation humaine s'appuie sur la politique de session des bibliothèques
Le pont sert l'agent ; il ne remplace pas la revue humaine

Maintenance préventive07 / 10

Savoir qu'un écran a changé avant que la campagne ne rougisse

Les bibliothèques réparent un localisateur perdu en le disant : un avertissement dans le journal Robot Framework et, si on l'active, une ligne dans un journal de télémétrie. L'atelier exploite ces traces : un script relit la télémétrie de plusieurs runs, repère les localisateurs réparés toujours vers la même cible et propose la correction dans la couche resources, qu'il n'applique que sur demande.

Une suite sentinelle, à planifier, compare l'écran initial d'une liste de transactions à sa référence (structure, empreinte visuelle, zones de l'écran) et produit un rapport de dérive ; /sap-maintain enchaîne sentinelle, télémétrie et agent sap-healer en un seul rapport.

Preuve : cycle référence, écran inchangé, dérive constatée, validé en direct contre ABAP Platform 1909 ; le script de dérive et les deux gardes sont livrés dans le pack, en Python sans dépendance.

tests/robot/ecc_drift_sentinel.robot

*** Variables ***
# Les écrans surveillés : l'écran initial de chaque transaction critique.
@{WATCHED_TRANSACTIONS}    SE16    SE38    SM50
# …
*** Test Cases ***
Watch Critical Screens
    # …
    ${outcomes}=    Create List
    FOR    ${tcode}    IN    @{WATCHED_TRANSACTIONS}
        Go To Transaction    ${tcode}
        Wait Until Busy Done
        ${verdict}=    Check Screen Against Watch    ${tcode}
        ...    directory=${WATCH_DIR}    fail_on_drift=${FAIL_ON_DRIFT}
        ...    per_resolution=${PER_RESOLUTION}
        Append To List    ${outcomes}    ${verdict}
    END

Rapport de dérive et garde du plan

> python scripts/healing_drift_report.py --log healing.jsonl
# propose les correctifs de la couche resources ; --apply les applique
> python scripts/check_spec_sync.py
# chaque suite est-elle encore en phase avec son plan ?

Ce qu'il fait

Rapport de dérive depuis SAPFX_HEALING_LOG : dérives stables localisées dans les fichiers .resource, dérives instables laissées à un humain
Correctif appliqué seulement avec --apply, et listé
Sentinelle : surveiller un écran de plus, c'est ajouter une transaction à une liste
Gardes : une suite encore en phase avec son plan, une suite générée sans localisateur brut ni attente fixe

Ce que vous obtenez

Des rapports Markdown lisibles
Des codes de retour exploitables par une tâche planifiée (1 = dérive à traiter)
Des références d'écran à versionner avec vos tests

Ses limites

Ne modifie jamais un test, seulement la couche resources
La sentinelle constate un changement, elle ne dit pas s'il était voulu
Les références visuelles dépendent de la résolution d'écran : une par géométrie

Cartographie des interfaces08 / 10

Cartographie : ce qui est relié à votre SAP, du groupe jusqu'à la table

Une cartographie d'interfaces se périme le jour où on la dessine. Cet outil la reconstruit depuis le système lui-même : un relevé par RFC, en lecture seule et prouvé par la release, lit les destinations, les profils et le trafic IDoc, les services Gateway, les chemins HTTP servis, les jobs, les tRFC en échec et la charge d'appels. Il le rapproche ensuite, par une règle et sur des clés stables, de votre cartographie applicative et de votre référentiel d'interfaces : groupe, entités, domaines, applications, puis système SAP, mandant, couche d'interface, objet, et jusqu'à la fonction, au programme, à la transaction et à la table.

L'outil ne tranche rien : chaque interface reçoit un verdict calculé par une règle, jamais par un modèle de langage (confirmée, non documentée, dormante, introuvable, hors de portée de SAP, non mesurée, jamais zéro), et ce qui demande un regard humain arrive avec ses sources. Les preuves visuelles sont capturées dans SAP GUI sous une politique de lecture seule (SM59, WE20, SICF, /IWFND/MAINT_SERVICE), chacune vérifiée contre l'interface qu'elle illustre. Les décisions de l'architecte (accepter, documenter, décommissionner, instruire) se reprennent d'un relevé au suivant tant que le verdict tient.

Preuve : relevés du 12 octobre 2026 sur ABAP Platform 1909 et 2023 (suite de validation 5/5 sur chacune, en lecture seule) ; preuves visuelles 19/19 vérifiées sur 1909 et 16/16 sur 2023 ; sur 1909, 28 interfaces à trancher, et les décisions reprises telles quelles au relevé suivant.

Planche A3 de la cartographie du paysage SAP du système A4H, flux colorés par verdict — **Planche du paysage** sur A4H (ABAP Platform 1909) : interfaces relevées par RFC, flux routés et colorés par verdict. Les niveaux marqués ◇ (groupe, entités, applications) viennent d'une cartographie applicative d'exemple.A4H, release 754 · Relevé du 12 octobre 2026

Extrait du rapport de cartographie : constats à vérifier, décision de l'architecte et preuve SM59 — **Ce que l'architecte doit vérifier** : une destination dormante, sa décision et sa preuve SM59, et un appelant RFC absent du référentiel.A4H, release 754 · Relevé du 12 octobre 2026Écran d'un logiciel SAP : le logo SAP et les marques SAP sont la propriété de SAP SE.

Relever, qualifier, prouver, rendre

> python -m tools.landscape_map collect --ashost <hôte> --user <utilisateur> --password-env SAP_PWD --expect-release 754 -o entree.json
# relevé par RFC, politique lecture seule posée d'abord
> python -m tools.landscape_map merge entree.json --apps applications.csv --register referentiel.csv -o qualifie.json
> python -m tools.landscape_map build qualifie.json -o releve.json
> python -m tools.landscape_map proofs releve.json -o out --conn /H/<hôte>/S/3200 --user <utilisateur> --password-env SAP_PWD --expect-release 754
> python -m tools.landscape_map render releve.json -o out --decisions decisions.json --proofs out/preuves.json --pdf

Ce qu'il fait

Relevé par RFC en lecture seule, cible prouvée par sa release avant toute lecture
Rapprochement par une règle avec la cartographie applicative et le référentiel d'interfaces (CSV ou JSON)
Verdict par interface, calculé par une règle et jamais par un modèle ; une activité illisible vaut « non mesurée », jamais zéro
Preuves capturées dans SAP GUI en lecture seule et vérifiées à l'écran, logo SAP masqué
Décisions de l'architecte liées à la clé de l'interface, reprises au relevé suivant, nommées quand le verdict change
Comparaison de deux relevés, avec un code de retour quand quelque chose a bougé

Ce que vous obtenez

Deux planches A3 : le paysage emboîté, flux routés et colorés par verdict, et l'arbre parent et enfant
Un rapport HTML et son PDF : chiffres clés, fiche de lignée par interface, constats à vérifier et leurs preuves
La liste de travail de l'architecte, un export Mermaid lisible par draw.io et un artefact déterministe

Ses limites

L'activité dépend de la collecte de charge du système : sans elle, elle est « non mesurée »
Les échanges par fichiers ou par bus d'événements échappent au regard de SAP ; les interfaces SOAP ne sont pas encore relevées
Le groupe, les entités et les domaines viennent de vos sources : sans elles, ils restent des emplacements, jamais devinés
Pas encore dans le pack de déploiement Windows

Couche métier d'exemple09 / 10

Des keywords métier et des suites d'exemple, à adapter à vos écrans

Entre les bibliothèques et vos tests se place une couche de keywords qui parle métier : ouvrir une session, compter les entrées d'une table, lire des enregistrements. L'atelier en fournit une, mesurée sur les systèmes du laboratoire, avec des noms qui se répondent d'un canal à l'autre.

C'est la couche que l'agent sap-healer répare, et celle que vous adaptez : chaque fichier s'ouvre sur le bandeau « EXEMPLE À PERSONNALISER », parce qu'une release, une langue ou une variante d'écran en changent les valeurs.

Preuve : les suites d'exemple sont tirées des campagnes du laboratoire, par exemple le produit EPM lu par trois canaux, 7/7 sur les releases 754 et 758 ; en intégration continue, le pack installé passe une exécution à blanc qui résout chaque keyword.

Des noms qui se répondent d'un canal à l'autre (couche d'exemple)
Geste	SAP GUI	WebGUI et SAP Fiori	OData	RFC
Ouvrir	`Open SAP And Log In`	`Open SAP And Log In`	`Open Api Channel`	`Open Rfc Channel`
Compter	`Count Table Entries`	`Count WebGui Table Entries`	`Count Business Entities`	`Count Business Records`
Fermer	`Close SAP`	`Close SAP`	`Close Api Channel`	`Close Rfc Channel`

Ce qu'il fait

Neuf fichiers de vocabulaire : SAP GUI, SAP Fiori et WebGUI, OData, RFC, sécurité (par RFC et à l'écran), croisement entre canaux, restitution de tableaux, données de démonstration
Vingt-cinq page objects, un par écran ou application : SE16, SE11, launchpad, Business Partner, IDoc, job de fond et spool...
Douze suites d'exemple dans le pack, dont une qui lit le même produit par trois canaux et une qui tourne sur le Demo Kit OpenUI5 public, sans identifiants

Ce que vous obtenez

Des tests qui se lisent en termes métier, sans identifiant SAP dans la suite
Un seul endroit où réparer un écran modifié
Vos propres keywords dans votre fichier (site_keywords.resource), à côté des fichiers livrés

Ses limites

Des exemples, pas un vocabulaire universel : chaque valeur a été mesurée sur nos systèmes de développement
À vérifier et adapter sur votre système : release, langue, variantes d'écran, champs spécifiques
Des points de départ, pas une couverture de vos processus

Pack de déploiement10 / 10

Un poste de test prêt en une commande, sans cloner de dépôt

Le pack est un ZIP autonome pour Windows : les bibliothèques et les plugins MCP en paquets, les deux enregistreurs, la couche métier, les douze suites d'exemple, les agents et leur skill, les scripts de maintenance. Son installateur crée un environnement Python local, installe des versions épinglées et vérifie l'intégrité de chaque fichier avant d'aller plus loin.

Le canal RFC, optionnel, a son propre script : il s'appuie sur le runtime NW RFC que SAP GUI 8.00 dépose déjà sur le poste, ou sur le SDK SAP que vous fournissez, et contrôle que l'import fonctionne vraiment.

Preuve : en intégration continue, le ZIP réel est installé par son installateur réel sur Python 3.10, puis passe une exécution à blanc ; le pack 0.8.5 a été construit et testé sur une extraction fraîche le 13 octobre 2026.

Installer le pack

> install.cmd -WithMcp -WithBrowsers
# environnement local, versions épinglées, intégrité vérifiée
> powershell -ExecutionPolicy Bypass -File install-rfc.ps1 -UseSapGuiRuntime
# canal RFC optionnel, sans archive SDK sur un poste équipé de SAP GUI 8.00

Ce qu'il fait

install.cmd : environnement .venv local, dépendances épinglées, contrôle d'import
-WithMcp : rf-mcp, plugins et configurations MCP écrites en place
-WithBrowsers : Chromium de Playwright pour SAP Fiori et le WebGUI
Refus d'un fichier altéré (SHA256SUMS.txt) et d'un Python antérieur à 3.10
install-rfc.ps1 -CheckOnly : diagnostic du canal RFC sans rien modifier

Ce que vous obtenez

Un poste qui exécute les suites d'exemple
Les configurations MCP pour Claude Code et VS Code
Un inventaire SHA-256 de chaque fichier du pack

Ses limites

Windows uniquement, comme SAP GUI pour Windows
Le SDK SAP NW RFC est sous licence SAP et non redistribuable : il n'est pas dans le pack
Le canal RFC demande Python 3.10 à 3.12 (versions de pyrfc disponibles)

Inclus, gratuit

Déjà dans les bibliothèques : les fonctions dont les outils se servent

Une partie de ce qui rend l'atelier utile vit dans le paquet PyPI lui-même. Ces fonctions sont gratuites, documentées et utilisables sans aucun outil.

Dans le paquet PyPI

Préflights

Constater avant d'échouer tard : scripting serveur, rendu des listes sur le poste, posture de sécurité du client SAP GUI, activité de la Gateway. Chacun nomme le paramètre à corriger.

Scripting Should Be Fully EnabledGateway Should Be Active

Dans le paquet PyPI

Perception numérotée

Une ligne et un numéro par cible de l'écran ; un agent désigne un numéro, le keyword agit sur l'identifiant, vérifié de nouveau avant l'action.

Get Screen MapGet Ui5 Page Map

Dans le paquet PyPI

Réparation journalisée

Un localisateur perdu est réparé avec un avertissement et, si on l'active, une ligne de télémétrie : la matière du rapport de dérive.

Resolve Element With HealingResolve Ui5 With Fallback

Dans le paquet PyPI

Surveillance d'écran

Un écran comparé à sa référence : structure, identifiants renommés appariés, empreinte visuelle et zones de l'écran. Le cœur de la suite sentinelle.

Check Screen Against Watch

Dans le paquet PyPI

Assertions visuelles

Empreintes perceptuelles d'un écran, d'un élément ou d'une page web, zones volatiles masquées : ce que l'API de scripting ne voit pas.

Screen Should Match BaselineUi5 Screen Should Match Baseline

Dans le paquet PyPI

Restitution en cinq formats

Un tableau lu sur l'un des quatre canaux s'écrit en SVG, XLSX, CSV, JSON Lines ou Parquet, puis se relit ; un relevé amputé est refusé.

Table Extract Should Be Complete

Dans le paquet PyPI

Artefact déterministe

JSON trié, empreinte SHA-256 sur un périmètre déclaré et recalculée à la relecture : un artefact modifié après coup est refusé.

Write Deterministic ArtifactCompare Deterministic Artifacts

Dans le paquet PyPI

Preuve de fermeture

En fin de campagne, prouver que les sessions SAP GUI sont refermées, sans capture d'écran et sans compter les autres sessions du poste.

Sap Gui Should Have No Open Connection

Programme CabrIA (R&D)

Deux briques CabrIA, en plus de l'atelier

Elles viennent du programme CabrIA, pas de SAPFX. Facultatives, elles se branchent et se retirent sans toucher aux tests, et le pack de déploiement ne les embarque pas.

Facultatif · CabrIA

Enregistreur de vol

Un listener sur chaque run Robot Framework, un plugin au-dessus du serveur MCP et un collecteur du journal de réparation consignent ce que chaque exécution laisse derrière elle, secrets et données personnelles masqués avant tout stockage. Les fichiers vont dans un dossier voisin, hors du dépôt de tests.

Il se retire en enlevant deux variables d'environnement.

Facultatif · CabrIA

Mémoire QA citée

Le serveur MCP local qa-brain rend interrogeable en langage naturel ce que le terrain a appris (keywords, plans, documentation, leçons écrites après incident), avec ses sources : 4 119 passages indexés au 9 octobre 2026. Les agents SAPFX le consultent avant leurs décisions de jugement quand il est monté.

L'observation sur le système réel tranche toujours : un passage cité n'est jamais une preuve. Absent, il ne bloque rien.

Découvrir CabrIA

Rigueur

Un atelier qui s'applique ses propres règles

Des gardes mécaniques, en intégration continue, tiennent ce que l'atelier promet au lieu de s'en remettre à la discipline.

Une seule version partout

À chaque release, bibliothèques, plugins, agents, extension et skill portent la même version, vérifiée par un test : 0.8.5 aujourd'hui.

Des conventions vérifiées

Pas de localisateur brut dans une suite générée, pas d'attente fixe, une suite liée à l'empreinte de son plan : contrôlé en intégration continue et à chaque édition.

Un plancher Python tenu

Les suites et la couche métier sont contrôlées pour Python 3.10, le plancher du pack : un défaut invisible sous 3.12 l'a imposé.

Des listes blanches

Le dépôt public et le pack ne portent que ce qui a été décidé : un dossier nouveau reste privé tant que personne ne choisit de le publier.

Sans promesse

Ce que les outils ne font pas

Mieux vaut le savoir avant de les demander.

Ils ne remplacent pas un éditeur graphique

Un enregistrement est un brouillon, et un test reste un fichier Robot Framework fait de keywords lisibles sans programmer : quelqu'un dans l'équipe le relit et le maintient.

Ils ne décident pas à votre place

Le plan d'un agent se relit avant génération, les gestes importants demandent un accord, et la réparation ne touche jamais une assertion.

Ils ne créent pas de dépendance

Les fichiers produits se lancent avec robot et les bibliothèques ; arrêter les outils ne casse aucun test.

Ils n'annoncent pas de gain chiffré

Aucun gain de productivité n'a été mesuré. Ce qui est mesuré, ce sont des campagnes jouées sur nos systèmes SAP de développement, jamais sur un système client.

Ils ne tournent pas partout

Le pack et l'enregistreur SAP GUI sont pour Windows, les agents demandent Claude Code ou GitHub Copilot, le canal RFC demande Python 3.10 à 3.12.

Ils ne sont pas publiés

Ni dans le paquet PyPI, ni dans le dépôt public, ni sur le Chrome Web Store : ils sont délivrés sur devis.

Obtenir les outils

Trois étapes, en commençant par le gratuit

Les outils ne servent qu'avec les bibliothèques : commencez par elles.

Installez les bibliothèques

pip install robotframework-sapfx, puis un premier test avec le guide de démarrage. Vous voyez ce que SAPFX fait sur vos écrans avant de demander quoi que ce soit.

Décrivez votre contexte

Canaux SAP, releases, poste de test, assistant IA utilisé, contraintes de sécurité : par le formulaire ou par courriel. Nous vous disons quels outils vous serviront, et lesquels non.

Recevez votre devis, puis l'atelier

Les outils utiles, leur installation, la formation et l'adaptation de la couche métier à vos écrans font l'objet d'un devis, sur un périmètre défini ensemble ; le pack de déploiement Windows vous est ensuite délivré.

Les bibliothèques restent libres et gratuites, avec ou sans les outils.

Nos prestations SAPFX

Questions fréquentes

Les outils de l'atelier SAPFX : les questions qu'on nous pose

Les réponses courtes ; le reste se discute sur votre cas.

Comment enregistrer un test SAP GUI pour Robot Framework ?

Avec l'enregistreur SAP GUI de l'atelier SAPFX : vous déroulez le parcours dans SAP GUI pour Windows, il le transcrit en keywords de SapEccLibrary à partir des événements de l'API SAP GUI Scripting et exporte une suite .robot rejouable, une paire resource et suite, un plan, des cas de test ISTQB et un rapport HTML. L'enregistrement reste un brouillon à relire.

Un agent IA peut-il générer des tests SAP ?

Oui, avec les agents de l'atelier SAPFX dans Claude Code ou GitHub Copilot : sap-planner confronte la demande au système SAP et écrit un plan observé, sap-generator exécute chaque étape sur SAP avant de l'écrire, sap-verifier et sap-istqb relisent la suite. Un humain relit le plan avant la génération.

Les outils de SAPFX sont-ils inclus dans le paquet PyPI ?

Non. Le paquet robotframework-sapfx contient les trois bibliothèques et leur socle commun, sous licence Apache 2.0. Les outils de l'atelier (enregistreurs, notation des demandes, agents IA, plugins MCP, maintenance, couche métier d'exemple, pack Windows) ne sont ni dans le paquet ni dans le dépôt public : ils sont délivrés sur devis.

Faut-il les outils pour utiliser SAPFX ?

Non. Les bibliothèques suffisent pour écrire, exécuter et maintenir des tests SAP en Robot Framework. Les outils raccourcissent l'écriture, la génération et la maintenance des tests ; ils ne sont pas un prérequis.

Les tests produits par les outils dépendent-ils des outils ?

Non. Ce sont des fichiers .robot et .resource qui appellent les keywords des bibliothèques et se lancent avec robot. Ils vous appartiennent et continuent de tourner sans les outils.

Quel assistant IA faut-il pour les agents SAPFX ?

Claude Code, ou GitHub Copilot dans VS Code, avec le serveur MCP rf-mcp et les plugins SAPFX. Les enregistreurs, les outils de maintenance et le pack fonctionnent sans assistant IA.

Les outils envoient-ils des données hors du poste ?

Les enregistreurs, les outils de maintenance et le pack tournent sur le poste et n'envoient rien ailleurs ; un mot de passe saisi pendant un enregistrement est remplacé par un marqueur. Prompt Eval envoie la demande au juge que vous configurez, par défaut un modèle servi en local. Les agents passent par l'assistant IA que vous choisissez : ce qu'ils perçoivent de l'écran SAP est transmis à ce service, selon votre contrat avec lui.

Comment savoir si une demande de test est prête pour les agents ?

Avec Prompt Eval, l'outil de notation de l'atelier SAPFX : il vérifie la forme de la demande et sa part de gabarit sans appel à un modèle, fait juger huit critères par un modèle de langage, de préférence local, et sonde par RFC en lecture seule que les objets SAP qu'elle nomme existent sur la cible. La note mesure la rédaction, pas le coût ; « jouable » ne dispense pas de l'exploration sur le système.

Peut-on cartographier les interfaces d'un système SAP ?

Oui, avec l'outil de cartographie de l'atelier SAPFX : un relevé par RFC en lecture seule lit les destinations, les profils et le trafic IDoc, les services Gateway et les chemins HTTP servis, le rapproche par une règle de votre cartographie applicative et de votre référentiel d'interfaces, et rend deux planches A3 et un rapport. Chaque interface reçoit un verdict calculé par une règle, jamais par un modèle de langage, et les écarts à vérifier arrivent avec leurs preuves capturées dans SAP GUI.

Comment obtenir les outils de l'atelier SAPFX ?

Sur devis, par le formulaire de contact ou par courriel : le devis couvre les outils utiles, leur installation, la formation et l'adaptation à vos écrans, puis le pack de déploiement Windows vous est délivré.

Atelier SAPFX

Les outils de l'atelier pour votre équipe ?

Dites-nous vos canaux SAP, vos releases et votre assistant IA : nous vous indiquons les outils utiles et vous adressons un devis pour leur mise en place.

Un échange technique, pas commercial
Vos données restent en France

Page SAPFX

ou directement par courriel :