SAPFX

Automatiser SAP, c'est jongler avec deux mondes qui n'ont rien à voir : le client lourd SAP GUI et le web Fiori. Deux outils, deux compétences, et des tests qui cassent au moindre changement d'écran, d'id ou de langue. La maintenance finit par coûter plus cher que l'écriture.

Le principe

On écrit le test une fois, en langage métier. Le même mot-clé fonctionne sur le SAP GUI, sur Fiori ou via l'API OData. En dessous, trois bibliothèques Robot Framework (SapEccLibrary, SapFioriLibrary, SapApiLibrary) et une mécanique faite pour ne pas casser bêtement : attente réelle de SAP, assertions indépendantes de la langue, auto-réparation des localisateurs toujours journalisée.

Go To Transaction    VA01           # SAP GUI
Open App             Sales Order    # Fiori

Le projet en vidéo

Ce que ça fait

• Un vocabulaire, trois canaux. Le même test se lit à l'identique qu'il pilote le GUI, Fiori ou l'API.
• Des tests qui ne cassent pas pour rien. Attente réelle de SAP, assertions indépendantes de la langue, aucun identifiant technique dans les tests.
• IA-native, mais sous contrôle. Des agents planifient, écrivent et réparent les tests en pilotant le vrai système ; chaque étape générée est exécutée en direct avant d'être écrite.
• La maintenance devient préventive. Sentinelle de dérive des écrans, assertions visuelles, télémétrie des localisateurs qui dérivent.
• Capacités de suite commerciale, coût de l'open source. Sans licence ni verrouillage éditeur.

En direct, pas sur les slides

La preuve, pas la promesse

Chiffres constatés à la version 0.7.0 (août 2026). Couverture mesurée : 94 %, plancher imposé en CI : 85 %. Compatibilité UI5 prouvée de 1.60 à 2.0. Documentation bilingue français/anglais.

La même campagne, deux releases SAP

Une suite qui passe sur un seul système prouve surtout que ce système n'a pas bougé. En août 2026, la campagne d'exploration du launchpad Fiori a donc été rejouée telle quelle sur deux serveurs ABAP, l'un servant SAPUI5 1.71, l'autre 1.120, avec le même page object et sans une seule condition sur le numéro de version : 22/22 scénarios validés en direct d'un côté, 20/20 de l'autre.

• Identique des deux côtés : le catalogue rendu, à savoir 2 catalogues, 67 tuiles et 62 intents dont 61 réellement résolvables.
• Différent, et rangé dans des variables : le menu utilisateur change de nom et de type de contrôle ; le dialogue qui refuse une navigation gagne un bouton, si bien qu'acquitter en première position copie le message au lieu de fermer la fenêtre ; le nombre de contrôles rendus sur l'accueil descend de 184 à 134, de quoi faire tomber n'importe quel seuil écrit en dur.
• Le piège que la seconde release a révélé : la sonde qui lisait les tuiles de la 1.71 a continué de répondre sur la 1.120, sans erreur, avec des titres vides. Des scénarios seraient passés au vert sur du néant. Aujourd'hui l'échec porte un nom.

Ces deux serveurs restent des images de démonstration, pas un S/4HANA de production avec ses développements spécifiques. Ce qui est établi, c'est qu'une campagne survit à un changement de release sans être réécrite. Sur un paysage client, il faudra le remesurer. Les deux suites sont dans le dépôt.

Où ça se situe

Les suites commerciales de test SAP sont matures et complètes, avec un support éditeur et un mode sans code que SAPFX n'a pas ; leurs licences se chiffrent en dizaines à centaines de k€ par an. L'open source historique est mono-canal : RoboSAPiens couvre le SAP GUI seul, wdi5 le web UI5 seul, hors Robot Framework. SAPFX couvre les trois canaux dans Robot Framework, avec un seul rapport, pour 0 €.

Les questions fréquentes sur SAPFX sont regroupées sur la page FAQ du site.