automation

SAP Fiori vs HTML GUI : pourquoi toutes les tuiles ne sont pas des applications Fiori natives

Cela se produit dans presque tous les projets S/4HANA. Un utilisateur se connecte au SAP Fiori Launchpad, voit une grille épurée de tuiles, clique sur l’une d’elles — et arrive sur un écran qui ressemble étrangement à la transaction SAP GUI qu’il utilise depuis quinze ans, simplement exécutée dans un onglet de navigateur. La question vient alors naturellement : « Attendez, est-ce que c’est Fiori ? »

La réponse honnête est : pas nécessairement. Le SAP Fiori Launchpad est un point d’entrée, pas une garantie technologique. Derrière ces tuiles uniformes peuvent se trouver des applications très différentes : des applications SAP Fiori natives développées avec SAPUI5 ou Fiori Elements, des développements SAPUI5 freestyle, des applications Web Dynpro ABAP, des pages analytiques — ou des transactions SAP GUI classiques affichées dans le navigateur via SAP GUI for HTML (également appelé Web GUI ou HTML GUI).

Cette distinction n’est pas théorique. Elle influence ce que les utilisateurs peuvent raisonnablement attendre en matière d’expérience, d’accès mobile, de performance et de formation. Elle influence également la manière dont les équipes projet mesurent les progrès de modernisation. Cet article explique la différence, quand les tuiles HTML GUI sont pertinentes, où elles créent de la confusion, et comment savoir ce qu’une tuile ouvre réellement avant de construire un plan de déploiement autour d’elle.

Qu’est-ce qu’une application SAP Fiori native ?

Une application SAP Fiori native est une application conçue et développée selon le système de conception SAP Fiori — l’ensemble de principes de SAP pour des expériences utilisateur cohérentes, orientées tâches et basées sur les rôles.

Concrètement, une application Fiori native présente généralement les caractéristiques suivantes :

• Développée avec les technologies SAP Fiori. La plupart des applications natives utilisent SAPUI5, soit sous forme d’applications Fiori Elements (générées à partir de services OData annotés à l’aide de gabarits standard comme List Report ou Object Page), soit sous forme d’applications SAPUI5 freestyle développées pour des modèles d’interaction plus spécifiques.
• Basée sur les rôles et orientée tâches. Au lieu d’une énorme transaction couvrant des dizaines de scénarios, une application Fiori est limitée à un rôle utilisateur spécifique et à une tâche précise — approuver une commande d’achat, vérifier le statut d’un fournisseur, comptabiliser un document simple.
• Connectée à des services backend modernes. Les applications natives consomment généralement des services OData, ce qui permet des fonctionnalités comme la gestion des brouillons, la recherche et la navigation structurée entre objets liés.
• Conçue pour une expérience moderne. Cela signifie une navigation cohérente, des actions contextuelles et — selon l’application — un comportement réactif qui s’adapte aux différentes tailles d’écran.

Un modèle mental utile : une application Fiori native a été conçue comme une application Fiori dès le départ. Elle n’a pas été convertie, encapsulée ni rendue sous cette forme.

Qu’est-ce que SAP GUI for HTML (Web GUI / HTML GUI) ?

SAP GUI for HTML est une technologie qui affiche les transactions SAP GUI classiques dans un navigateur web. Au lieu d’installer SAP GUI for Windows sur un poste de travail, la génération SAP Internet Transaction Server (ITS) intégrée à la pile ABAP traduit les écrans Dynpro classiques en HTML, et l’utilisateur interagit avec la transaction via le navigateur.

Les points importants :

• L’application sous-jacente reste la transaction classique. Lorsqu’une tuile lance ME23N ou VA03 via SAP GUI for HTML, la logique métier, la séquence d’écrans et la structure des champs sont celles de la transaction Dynpro d’origine.
• Le navigateur n’est que la couche de présentation. Les écrans sont convertis en HTML à la volée, ce qui explique pourquoi ils conservent l’apparence classique — barres de menus, touches de fonction, navigation basée sur les écrans — avec certains thèmes visuels appliqués pour adoucir l’apparence.
• Ces transactions peuvent être lancées depuis le Fiori Launchpad au moyen de tuiles et de mappages de cibles, exactement comme les applications natives. C’est ce qui les rend faciles à confondre.
• L’avantage pratique est réel : les utilisateurs accèdent aux transactions sans installation locale de SAP GUI, et les administrateurs bénéficient d’un accès centralisé, basé sur le navigateur, à des fonctionnalités qui n’ont pas encore d’équivalent Fiori.

L’affichage dans un navigateur ne change pas la nature de l’application. Une tuile HTML GUI correspond à SAP GUI classique fourni via un canal différent — et non à une expérience repensée.

Pourquoi les tuiles peuvent être trompeuses

Le Fiori Launchpad présente délibérément une surface unifiée. Chaque tuile se ressemble : un titre, peut-être un indicateur KPI, un style visuel cohérent. Cette cohérence est utile pour la navigation, mais elle masque la diversité technique sous-jacente.

Un seul Launchpad peut contenir des tuiles qui ouvrent, entre autres :

• Une application SAP Fiori native (par exemple, un rapport de liste Fiori Elements pour gérer les commandes client)
• Une application SAPUI5 freestyle conçue pour un scénario personnalisé
• Une transaction SAP GUI classique affichée via Web GUI
• Une application Web Dynpro ABAP, courante dans de nombreux scénarios RH et financiers
• Une application web personnalisée ou tierce intégrée via une URL
• Une page ou un rapport analytique, comme une analyse détaillée de KPI Smart Business

Pour l’utilisateur, tout cela correspond à des « tuiles dans Fiori ». Pour l’équipe projet, elles représentent des technologies différentes, avec des capacités, des limites et des cycles de vie différents. Les considérer comme interchangeables est le point de départ des problèmes d’attentes : un utilisateur qui a eu une excellente expérience avec une application d’approbation Fiori Elements cliquera sur la tuile suivante en s’attendant au même résultat, et pourra au contraire se retrouver face à une transaction classique dense avec une navigation par touches de fonction.

SAP Fiori vs HTML GUI : comparaison pratique

La comparaison n’est pas « bon contre mauvais ». C’est « expérience repensée contre accès préservé ». Les deux ont leur place — mais ils doivent être étiquetés honnêtement.

Pourquoi les organisations utilisent des tuiles HTML GUI

Il existe des raisons solides et défendables pour lesquelles les tuiles HTML GUI apparaissent dans de véritables Launchpads :

• Lacunes de couverture. Toutes les transactions SAP GUI ne disposent pas d’un équivalent Fiori natif. Même dans les versions actuelles de S/4HANA, certains domaines fonctionnels sont encore principalement pris en charge par des transactions classiques.
• Profondeur fonctionnelle. Certaines applications Fiori couvrent volontairement les 80 % les plus courants d’un scénario. Les utilisateurs avancés qui ont besoin des 20 % restants — vues de stocks spéciales, types de documents peu courants, fonctions de modification en masse — peuvent encore avoir besoin de la transaction complète.
• Migration progressive. L’adoption de S/4HANA est rarement un basculement complet pour l’expérience utilisateur. Les entreprises déplacent souvent les rôles vers Fiori de manière incrémentale, et HTML GUI permet entre-temps de garder tout accessible depuis un seul endroit.
• Un point d’entrée unique. Placer les transactions classiques derrière des tuiles Launchpad offre aux utilisateurs une seule URL, une seule structure de catalogue et un seul concept d’autorisation — au lieu de maintenir un accès SAP GUI en parallèle pour un sous-ensemble d’utilisateurs.
• Périmètre de projet maîtrisé. Reconstruire une transaction rarement utilisée sous forme d’application SAPUI5 personnalisée entraîne de réels coûts de développement et de maintenance. Si la transaction fonctionne et est utilisée par cinq spécialistes par mois, l’encapsuler est souvent le choix rationnel.

Utilisées de manière réfléchie, les tuiles HTML GUI constituent une décision architecturale légitime, et non un raccourci dont il faudrait avoir honte.

Les risques d’appeler tout « Fiori »

Les problèmes ne viennent pas de HTML GUI lui-même, mais de son mauvais étiquetage. Lorsque tout ce qui se trouve sur le Launchpad est présenté comme « notre nouvelle expérience Fiori », plusieurs risques s’accumulent :

• Des attentes utilisateur déçues. Les utilisateurs à qui l’on promet une expérience moderne cliquent sur une tuile et obtiennent une transaction classique. La déception est alors associée à l’ensemble du programme, y compris aux applications natives réellement réussies.
• Des plans mobiles irréalistes. La direction peut supposer que « tout est désormais dans Fiori, donc tout fonctionne sur tablette ». Les écrans HTML GUI sur un téléphone sont, au mieux, utilisables en cas d’urgence.
• Des supports de formation confus. Si la formation traite toutes les tuiles de la même manière, elle expliquera trop en détail des applications Fiori simples ou pas assez des transactions classiques complexes. Les formateurs doivent savoir ce qui relève de l’un ou de l’autre.
• Des indicateurs de modernisation gonflés. « Nous avons 300 tuiles en production » donne une impression de progrès. Si 220 d’entre elles sont des enveloppes Web GUI, la modernisation réelle de l’UX est bien moindre que ce que le chiffre suggère — et les décisions de feuille de route fondées sur ce chiffre seront erronées.
• Une refonte des processus ignorée. Enrober une transaction préserve l’ancien processus exactement tel qu’il était. Les équipes peuvent manquer l’occasion — et parfois la nécessité — de repenser le processus qu’une refonte en application native aurait imposé.
• Des tickets de support mal orientés. Un problème de rendu dans ITS, un problème de performance dans un service OData et une erreur d’écran Dynpro ont des causes racines différentes et des responsables différents. Si l’équipe de support ne sait pas distinguer les types d’applications, le triage ralentit.

Pourquoi l’interface graphique HTML n’est pas toujours une mauvaise solution

Il vaut la peine d’exposer explicitement un point de vue équilibré, car l’interface graphique HTML est souvent écartée injustement dans les discussions sur la modernisation :

• Pour les utilisateurs expérimentés, la transaction complète est souvent meilleure qu’une application simplifiée. Un spécialiste MM expérimenté travaillant toute la journée dans ME21N perd en productivité avec une interface réduite.
• Elle préserve des fonctionnalités éprouvées sans aucun risque de redéveloppement. La transaction se comporte exactement comme elle a été validée au fil des années d’utilisation.
• Elle réduit les perturbations pendant la transition. Les utilisateurs conservent des workflows familiers tandis que l’organisation développe les capacités Fiori là où elles comptent le plus.
• Elle gère la longue traîne des transactions — les centaines de fonctions rarement utilisées, mais parfois essentielles, qui ne justifieront jamais une refonte.
• Elle prend en charge la centralisation des accès : un seul Launchpad, un seul flux d’authentification, aucune installation locale de GUI à gérer pour les utilisateurs occasionnels.

La seule chose qu’elle ne fait pas, c’est offrir une expérience utilisateur Fiori native — et ce n’est pas un problème, tant que personne ne prétend le contraire.

Comment identifier le type d’application qu’ouvre une tuile

Pour toute personne évaluant un Launchpad existant ou planifiant un déploiement, ces vérifications révèlent ce qui se trouve réellement derrière une tuile :

1. Consultez la SAP Fiori Apps Reference Library. Recherchez l’application par nom ou par ID. La bibliothèque indique explicitement le type d’application — SAP Fiori (SAPUI5), Web Dynpro ou SAP GUI. Elle affiche également les composants backend requis et les versions disponibles.
2. Examinez le type d’application dans les détails techniques. Dans la configuration du contenu du Launchpad (mappages de cibles, ou contenu du launchpad dans les outils plus récents), chaque cible précise si elle lance un composant SAPUI5, une application Web Dynpro ou une transaction via SAP GUI for HTML.
3. Examinez le mappage de cible et l’objet/l’action sémantique. L’intention derrière la tuile pointe vers la configuration de lancement concrète, qui indique la technologie.
4. Inspectez l’URL lors de l’exécution. Les applications SAPUI5 chargent généralement un composant dans le shell du Launchpad ; les sessions Web GUI affichent des schémas d’URL ITS caractéristiques (comme des chemins contenant /sap/bc/gui/sap/its/webgui).
5. Appliquez le test de conception. L’écran suit-il les modèles Fiori — pages d’objet, rapports de liste, barres d’actions en pied de page ? Ou affiche-t-il des barres de menus classiques, des champs de code OK et des indications de touches de fonction ?
6. Testez sur ordinateur et mobile. Une application native et responsive s’adapte. Un écran Web GUI sur un téléphone rend la différence évidente en quelques secondes.
7. Validez par rapport au rôle et au processus. Quelle que soit la technologie, confirmez que l’application prend réellement en charge les tâches effectuées par le rôle cible — une application Fiori native qui ne couvre qu’une partie du processus peut encore nécessiter une transaction classique en parallèle.

Ce que les équipes SAP doivent documenter

La plupart des confusions liées au Launchpad peuvent être évitées grâce à un simple catalogue interne d’applications. Pour chaque tuile concernée, consignez :

• Nom de la tuile et affectation au catalogue/à l’espace
• Rôle métier qui l’utilise
• Processus pris en charge (lié à votre documentation de processus)
• Type d’application — Fiori Elements, SAPUI5 freestyle, Web Dynpro, SAP GUI for HTML, URL externe
• Classification : Fiori natif ou enveloppe HTML GUI
• Transaction SAP GUI associée (pour les transactions enveloppées ou partiellement remplacées)
• Responsable — fonctionnel et technique
• Prise en charge mobile — testée, non présumée
• Limitations connues par rapport à la transaction classique ou au périmètre attendu
• Notes de formation — ce que les utilisateurs doivent apprendre, ce qui change par rapport à avant
• Feuille de route de remplacement, si la tuile est une enveloppe transitoire prévue pour être remplacée par un successeur natif

Ce catalogue devient la référence partagée pour les équipes de formation, le support, les tests et la planification de la feuille de route — et il rend les progrès de modernisation mesurables plutôt qu’anecdotiques.

Implications pour les déploiements SAP Fiori

Savoir quelles tuiles sont natives et lesquelles sont des enveloppes change la manière dont vous menez le déploiement lui-même :

• Adoption par les utilisateurs : Communiquez avec honnêteté. Présentez les applications natives comme la nouvelle expérience et les tuiles HTML GUI comme un accès pratique, via le navigateur, aux transactions familières. Les utilisateurs pardonnent un écran classique ; ils ne pardonnent pas qu’on leur dise qu’il s’agit de quelque chose que ce n’est pas.
• Formation : Séparez les supports par type d’application. Les applications natives nécessitent une prise en main des nouveaux modes d’interaction ; les tuiles Web GUI nécessitent, tout au plus, une note indiquant que la transaction familière s’ouvre désormais dans le navigateur.
• Conception des rôles : Les catalogues et les espaces doivent refléter ce dont un rôle a réellement besoin — ce qui signifie souvent un mélange délibéré d’applications natives pour les tâches fréquentes et de transactions encapsulées pour le travail d’expert.
• Documentation des processus : Lorsqu’une application native a remplacé une transaction, les étapes documentées du processus changent généralement. Lorsqu’une enveloppe est utilisée, elles ne changent généralement pas. Documentez en conséquence.
• Tests : Les applications natives nécessitent des tests des services OData et de l’interface utilisateur ; les tuiles Web GUI nécessitent des tests de transaction ainsi que des vérifications du rendu dans le navigateur. Plans de test différents, défauts différents.
• Attentes en matière de performance : Définissez-les par type d’application. Les allers-retours écran par écran dans Web GUI se comportent différemment des applications Fiori adossées à OData, en particulier via un VPN ou des connexions à forte latence.
• Gestion du changement : Organisez la communication autour des expériences réellement nouvelles. Une annonce de lancement fondée sur des transactions encapsulées promet trop et nuit à la crédibilité des vagues suivantes.
• Feuille de route de modernisation : Utilisez le catalogue d’applications pour suivre la conversion réelle — combien de tâches à forte fréquence sont passées à des applications natives — plutôt que de compter les tuiles.

Réponse finale

Une tuile dans le SAP Fiori Launchpad n’est qu’un point d’accès. Elle ne garantit pas que l’application qui se trouve derrière soit une application SAP Fiori native. Des applications Fiori natives, des applications Fiori Elements, des applications SAPUI5 freestyle, des applications Web Dynpro et des transactions SAP GUI classiques exécutées via SAP GUI for HTML peuvent toutes se trouver derrière des tuiles visuellement identiques.

Ce n’est pas un défaut du Launchpad — c’est ainsi qu’une plateforme facilitant la transition est censée fonctionner. Le problème ne commence que lorsque les équipes cessent de faire la distinction entre les deux. Avant de prendre des décisions concernant l’adoption, la formation, l’utilisation mobile, les performances ou les progrès de la modernisation, identifiez ce que chaque tuile ouvre réellement. La technologie derrière la tuile — et non la tuile elle-même — détermine l’expérience des utilisateurs.

FAQ

Chaque tuile du SAP Fiori Launchpad est-elle une application Fiori native ?

Non. Le Fiori Launchpad peut lancer des applications SAPUI5/Fiori Elements natives, des applications Web Dynpro, des transactions SAP GUI classiques via SAP GUI for HTML, et même des applications web externes. La tuile n’est que le point d’entrée ; la technologie sous-jacente varie.

Quelle est la différence entre SAP Fiori et SAP GUI for HTML ?

Les applications SAP Fiori sont des applications conçues et développées selon les principes de conception SAP Fiori, généralement avec SAPUI5 ou Fiori Elements et des services OData. SAP GUI for HTML affiche dans un navigateur des transactions SAP GUI classiques existantes sans modifier leur conception, leur logique ni leurs modes d’interaction.

HTML GUI est-il la même chose que Web GUI ?

Oui. « HTML GUI », « Web GUI » et « SAP GUI for HTML » désignent tous la même technologie : l’affichage dans un navigateur de transactions SAP GUI classiques via l’Internet Transaction Server (ITS) intégré à la pile ABAP.

Les transactions SAP GUI peuvent-elles être lancées depuis le Fiori Launchpad ?

Oui. Grâce aux mappages de cible, les transactions classiques peuvent être lancées sous forme de tuiles et s’ouvrir dans le navigateur via SAP GUI for HTML. Il s’agit d’une configuration courante et prise en charge, en particulier lors des transitions vers S/4HANA.

Pourquoi certaines tuiles Fiori ressemblent-elles à d’anciens écrans SAP GUI ?

Parce qu’il s’agit d’anciens écrans SAP GUI : des transactions Dynpro classiques affichées en HTML. La tuile lance la transaction d’origine via Web GUI, de sorte que la disposition de l’écran, les menus et la navigation restent ceux du SAP GUI classique, avec seulement un léger habillage visuel.

SAP GUI for HTML est-il mauvais ?

Non. C’est un moyen pratique de préserver l’accès aux transactions qui n’ont pas d’équivalent Fiori natif, de prendre en charge les utilisateurs avancés qui ont besoin de toute la profondeur fonctionnelle des transactions, et d’éviter des redéveloppements inutiles. Cela ne devient un problème que lorsqu’il est présenté comme une expérience Fiori moderne, créant de fausses attentes.

Comment savoir si une tuile est une application Fiori native ?

Vérifiez l’application dans la SAP Fiori Apps Reference Library, examinez le mappage de cible ou la configuration du contenu du launchpad pour le type d’application, observez l’URL d’exécution (les sessions Web GUI utilisent des chemins ITS caractéristiques) et appliquez le test de conception : les applications natives suivent les modèles Fiori, tandis que Web GUI affiche des menus classiques et des champs de code OK.

Les entreprises doivent-elles remplacer toutes les tuiles HTML GUI par des applications Fiori natives ?

Pas nécessairement. Les tâches à forte fréquence utilisées par de nombreux utilisateurs occasionnels ou mobiles bénéficient le plus des applications natives. Les transactions expertes rarement utilisées peuvent ne pas justifier un redéveloppement et peuvent rester sous forme de tuiles Web GUI. La bonne approche consiste à établir une feuille de route priorisée fondée sur l’usage, les rôles utilisateurs et la valeur métier.

Une tuile du Launchpad signifie-t-elle que le processus a été modernisé ?

Non. Une tuile qui encapsule une transaction classique préserve le processus existant exactement tel qu’il était. Une véritable modernisation implique généralement de repenser l’expérience applicative — et souvent le processus qui la sous-tend —, pas seulement de modifier la manière dont la transaction est accessible.

Comment les équipes SAP doivent-elles documenter les tuiles du Launchpad ?

Tenez à jour un catalogue d’applications interne répertoriant le nom de chaque tuile, le rôle métier, le processus pris en charge, le type d’application (Fiori Elements, SAPUI5, Web Dynpro, SAP GUI for HTML), la transaction classique associée, le propriétaire, la prise en charge mobile, les limitations connues, les notes de formation et la feuille de route de remplacement le cas échéant.

---