SAP Fiori vs SAP GUI : ce qui change vraiment pour les utilisateurs
Pour de nombreux utilisateurs SAP, passer de SAP GUI à SAP Fiori ressemble à bien plus qu’une refonte. Cela change la manière dont les utilisateurs trouvent leur travail, ouvrent les applications et accomplissent leurs tâches.
Les utilisateurs expérimentés de SAP GUI s’appuient sur les codes de transaction, les écrans denses, les habitudes au clavier, les mises en page enregistrées et des années de réflexes acquis. SAP Fiori organise l’expérience différemment : autour du Fiori Launchpad, d’applications basées sur les rôles, de tuiles et d’une interface web moderne.
Pour les nouveaux utilisateurs, les scénarios mobiles, les approbations et les tâches en libre-service, ce changement constitue généralement une amélioration. Il crée aussi des frictions dans des cas réels : un utilisateur avancé perd en rapidité, une transaction familière est répartie entre plusieurs applications, ou une application Fiori n’atteint tout simplement pas la profondeur fonctionnelle de la transaction GUI qu’elle est censée remplacer.
La question utile n’est donc pas « ancienne interface contre nouvelle interface ». Il s’agit de déterminer quelle expérience correspond à l’utilisateur, à la tâche, à l’appareil et au processus métier.
SAP Fiori et SAP GUI en termes simples
SAP GUI est l’interface avec laquelle la plupart des utilisateurs SAP travaillent depuis des années. Elle est orientée transaction et dense, et elle est efficace pour les personnes qui savent déjà où aller. Elles naviguent au moyen de codes de transaction, de menus, de raccourcis, de variantes de mise en page et d’écrans qui affichent beaucoup d’informations à la fois.
SAP Fiori part d’un principe différent : le rôle de l’utilisateur et la tâche à accomplir. Les utilisateurs accèdent aux applications Fiori via le Launchpad, où les tuiles sont organisées par rôles, catalogues, espaces et autorisations. L’effet pratique est un point d’entrée plus ciblé — approuver quelque chose, créer une demande, consulter un KPI, examiner une liste — plutôt que « ouvrir cette transaction et comprendre le reste ».
C’est là que les réactions divergent. Un nouvel employé peut trouver un Launchpad basé sur les rôles beaucoup plus facile à utiliser que l’apprentissage des codes de transaction. Un utilisateur expérimenté peut trouver la même expérience plus lente si elle supprime les raccourcis, la densité et les options avancées qu’il utilise tous les jours. Et une seule transaction GUI ne correspond pas toujours à une seule application Fiori — parfois elle correspond à plusieurs applications, parfois à un parcours repensé, parfois à rien d’équivalent.
La différence n’est donc pas principalement visuelle. SAP GUI est centrée sur les transactions. SAP Fiori est centré sur les rôles et les tâches. Les deux sont utiles, mais ils conviennent à des utilisateurs différents et à différents types de travail.
Ce qui change réellement pour les utilisateurs
Le changement le plus visible concerne la manière dont le travail commence. Dans SAP GUI, vous saisissez un code de transaction, arrivez sur l’écran, appliquez vos filtres ou votre variante, puis lancez l’action. Pour les experts, c’est extrêmement rapide, car le schéma est mémorisé. Dans Fiori, vous partez du Launchpad et choisissez parmi les applications attribuées à votre rôle — vous sélectionnez une tâche plutôt que de vous rappeler où elle se trouve.
Ce seul changement entraîne la plupart des autres :
L’accès devient basé sur les rôles. Le Launchpad affiche ce que votre rôle est censé permettre de faire, ce qui réduit le bruit et aide les utilisateurs occasionnels. En contrepartie, vous ne verrez pas les applications qui ne vous sont pas attribuées, même lorsqu’elles existent dans le système.
Le travail devient orienté tâche. Les applications Fiori ont tendance à cibler une activité précise — approuver une commande d’achat, examiner une commande client, créer une demande. C’est idéal pour un travail guidé, mais frustrant si vous gériez auparavant un flux plus large dans une seule transaction.
Les écrans deviennent plus légers. GUI regroupe de nombreux champs, onglets et filtres sur un seul écran, ce qui explique précisément pourquoi les utilisateurs avancés l’apprécient. Fiori réduit la complexité visuelle, ce qui facilite la compréhension, mais pénalise ceux qui doivent comparer rapidement de nombreux champs.
La navigation change de forme. GUI valorise les codes de transaction, les raccourcis clavier et les séquences d’écrans connues. Fiori s’appuie sur la recherche dans le Launchpad, les listes de résultats, les pages d’objet et les liens entre objets associés — plus intuitif pour les nouveaux utilisateurs, moins direct pour les experts.
Les appareils deviennent plus variés. GUI a été conçu pour le poste de travail. Fiori a été conçu pour le web responsive, ce qui le rend beaucoup plus pratique sur tablettes et téléphones, pour les approbations en déplacement, ainsi que pour les tâches de terrain et de libre-service.
Autrement dit, la transition transforme la façon dont les utilisateurs découvrent le travail à effectuer, la quantité d’informations qu’ils voient en une fois et le degré de lien entre l’interface et les rôles. C’est pourquoi le même changement ravit un groupe et en irrite un autre.
Pourquoi certains utilisateurs préfèrent encore SAP GUI
De nombreuses critiques à l’égard de Fiori ne sont pas d’ordre esthétique. Les utilisateurs comparent deux façons de travailler, pas deux conceptions visuelles.
Pour les utilisateurs expérimentés, le GUI semble plus rapide parce que les codes de transaction, les séquences d’écrans, les raccourcis et les variantes sont déjà ancrés dans leurs habitudes. Ils ne veulent pas d’une expérience guidée — ils veulent de la rapidité et du contrôle. C’est particulièrement vrai pour les utilisateurs avancés, les utilisateurs clés, les consultants et le personnel technique dont le travail implique des transactions en grand volume, des contrôles détaillés, du dépannage ou du paramétrage sur de nombreux champs. Un écran GUI dense peut surpasser une application simplifiée qui masque les informations derrière des clics supplémentaires.
L’habitude renforce encore cet effet. Une personne qui utilise la même transaction depuis des années sait quels champs sont importants, quels avertissements ignorer et quelle variante offre la meilleure vue. Remplacer cela par une nouvelle application réduit la productivité si l’application ne correspond pas au flux de travail réel.
Il y a ensuite la profondeur fonctionnelle. Fiori n’est pas toujours un remplacement à l’identique. Certaines applications sont excellentes pour les tâches ciblées, les approbations et le travail mobile ; certaines transactions historiques couvrent des scénarios opérationnels plus larges que l’application équivalente ne prend en charge que partiellement. Lorsqu’une application ne couvre qu’une partie de ce dont les utilisateurs ont besoin, ils y voient un recul — et parfois l’interface « plus simple » est en réalité plus lente, parce qu’elle a supprimé précisément les éléments qui rendaient le travail des experts efficace.
Pourquoi les nouveaux utilisateurs préfèrent souvent SAP Fiori
Les nouveaux venus évaluent Fiori selon des critères différents. Si vous ne connaissez pas les codes de transaction ni la logique des écrans SAP, l’interface graphique est intimidante : par où commencer, quelle transaction utiliser, quels champs sont obligatoires ?
Fiori supprime une grande partie de ces frictions en organisant le travail autour d’applications, de rôles et de tâches. Au lieu de vous demander de vous souvenir d’un code, le Launchpad présente un ensemble sélectionné — approbations, demandes, rapports, actions en libre-service. C’est particulièrement précieux pour les utilisateurs occasionnels. Une personne qui ne fait que mettre à jour des données personnelles, soumettre une demande ou vérifier un statut n’a pas besoin de toute la profondeur d’une transaction traditionnelle ; une application ciblée rend la tâche facile à trouver et à terminer.
La mobilité compte aussi ici. Les responsables qui approuvent en déplacement, les employés sur des applications en libre-service, les équipes terrain qui mettent à jour des enregistrements depuis une tablette — tout cela fonctionne mieux dans une interface responsive que sur un écran limité au poste de travail. Pour ces utilisateurs, le véritable avantage n’est pas que Fiori ait une apparence moderne ; c’est qu’il correspond étroitement au travail à accomplir : ouvrir la bonne application, voir ce qui est pertinent, décider, passer à la suite.
Choisir entre les deux, scénario par scénario
La décision dépend généralement de la nature du travail. Les tâches denses, répétitives, techniques ou pilotées par des experts favorisent encore SAP GUI. Les tâches ciblées, basées sur les rôles, mobiles, analytiques ou en libre-service favorisent SAP Fiori.
| Scénario | Meilleur choix |
|---|---|
| Travail opérationnel à fort volume | SAP GUI |
| Utilisateurs experts s’appuyant sur les codes T et les raccourcis | SAP GUI |
| Écrans denses avec de nombreux champs, filtres et variantes | SAP GUI |
| Administration technique ou configuration avancée | SAP GUI / outils spécialisés |
| Transactions héritées sans couverture Fiori complète | SAP GUI ou SAP GUI for HTML |
| Dépannage fréquent par des utilisateurs clés ou des consultants | SAP GUI |
| Tâches d’approbation | SAP Fiori |
| Libre-service des employés et des managers | SAP Fiori |
| Travail mobile ou sur le terrain | SAP Fiori |
| Suivi des KPI et visibilité sur les exceptions | SAP Fiori |
| Tâches métier guidées et utilisation occasionnelle | SAP Fiori |
| Workflows d’approbation impliquant plusieurs rôles, règles et exceptions | SAP Fiori + couche BPM* |
| Gestion des demandes avec délais, escalades et traçabilité | SAP Fiori + couche BPM* |
| Processus de bout en bout qui vont au-delà d’une seule transaction ou application SAP | SAP Fiori + couche BPM* |
* Dans des scénarios comme ceux-ci, SAP Fiori peut fournir l’expérience côté utilisateur, tandis qu’une couche BPM peut gérer la logique de workflow, les approbations, les délais, les escalades, les exceptions et la visibilité opérationnelle.
Rien de tout cela ne plaide contre l’adoption de Fiori. Cela plaide contre le fait de considérer Fiori comme un remplacement automatique pour chaque scénario GUI. Pour certains rôles, la modernisation la plus intelligente conserve SAP GUI là où il reste efficace et utilise Fiori là où un accès basé sur les rôles, guidé ou mobile crée une valeur claire.
SAP Fiori remplace-t-il SAP GUI ?
SAP Fiori est l’expérience utilisateur stratégique pour SAP moderne, en particulier S/4HANA. Cela ne signifie pas que GUI disparaît de toutes les entreprises, de tous les rôles et de tous les processus selon le même calendrier.
Ce que Fiori change réellement, c’est l’orientation par défaut de la conception UX. Les nouveaux scénarios sont de plus en plus construits autour d’applications basées sur les rôles, de l’accès via le Launchpad, de tâches guidées et d’interfaces responsives. Mais de nombreuses organisations dépendent encore de GUI pour le travail d’expert, les transactions héritées, la configuration et les opérations à grand volume.
« Remplacement » est un terme trompeur, car la réalité est inégale. Parfois, une application Fiori remplace proprement une transaction. Parfois, elle n’en couvre qu’une partie. Parfois, la transaction GUI est simplement exposée via le Launchpad — offrant aux utilisateurs un point d’entrée central sans refondre l’expérience sous-jacente. À savoir ici : la SAP Fiori Apps Reference Library ne se contente pas de cataloguer les applications Fiori. Elle vous aide aussi à planifier l’utilisation d’applications SAP GUI classiques et Web Dynpro dans le Launchpad, et la documentation de SAP indique que vous pouvez vérifier si une transaction GUI peut s’exécuter dans le Fiori Launchpad en recherchant son code de transaction dans cette bibliothèque.
La meilleure question n’est pas de savoir si Fiori remplace GUI. Elle est de savoir si l’expérience Fiori prend en charge le travail réel aussi bien que — ou mieux que — la transaction qu’elle remplace. Pour y répondre, validez le cas d’utilisation réel avec les personnes qui effectuent le travail : l’application couvre-t-elle les champs, filtres, variantes, actions, exceptions, autorisations et rapports sur lesquels elles s’appuient ? Et tenez compte du profil utilisateur, car un demandeur occasionnel et un utilisateur avancé attendent des choses totalement différentes.
Pour la plupart des entreprises, l’avenir réaliste est hybride. Fiori devient le point d’entrée privilégié pour les utilisateurs métier, le libre-service, les tâches mobiles, les approbations et l’analytique. GUI continue de servir les utilisateurs et les scénarios pour lesquels la densité, la vitesse, la profondeur ou le contrôle technique restent importants. Une transition réussie ne force pas tout le monde à utiliser une seule interface : elle associe la bonne expérience à chaque rôle, tâche et processus.
Le problème caché : une application n’est pas l’ensemble du processus
Une erreur courante dans les projets Fiori consiste à supposer qu’une meilleure application produit automatiquement un meilleur processus.
Une application peut améliorer la manière dont une personne effectue une tâche — faciliter une approbation, simplifier une demande, afficher un KPI. Mais elle reste une partie d’un processus plus large qui comprend également qui lance le travail, quelles données sont requises, qui les valide, quelles règles s’appliquent, ce qui se passe lorsque des informations manquent, qui approuve, quels délais existent, comment les exceptions sont gérées et comment le résultat est suivi.
C’est pourquoi un utilisateur peut avoir une bonne expérience dans une application tout en étant confronté à un processus médiocre. Une application d’approbation peut être agréable à utiliser alors que le flux d’approbation reste flou. Une application de demande peut paraître moderne alors que personne ne sait ce qui se passe après la soumission. Une tuile KPI peut signaler une exception que l’organisation n’a aucune procédure pour résoudre.
Évaluez donc les applications par rapport au processus de bout en bout, et pas seulement à l’écran :
| Question | Pourquoi c’est important |
|---|---|
| Quel processus métier cette application prend-elle en charge ? | Maintient la sélection des applications liée au travail réel. |
| Quel rôle l’utilise, et à quel moment du processus ? | Clarifie les responsabilités et les relais. |
| Que se passe-t-il avant et après la tâche de l’utilisateur ? | Évite les parcours fragmentés. |
| Quelles exceptions sont courantes ? | Montre si l’application gère les variations opérationnelles réelles. |
| De quoi l’utilisateur a-t-il besoin pour décider ou agir ? | Empêche les écrans trop simplifiés de supprimer le contexte critique. |
| Comment les utilisateurs sauront-ils où en est le processus ? | Relie l’exécution à la visibilité et à la responsabilisation. |
C’est particulièrement important lors du remplacement d’une transaction GUI. La transaction pouvait prendre en charge un flux large tandis que l’application prend en charge une tâche plus restreinte — ce qui convient lorsque l’objectif est de simplifier le travail d’un rôle, mais devient risqué lorsque personne ne cartographie le processus complet ni la manière dont les éléments s’articulent. Une application moderne aide un utilisateur à terminer une tâche ; un processus bien conçu aide l’organisation à coordonner le travail entre les rôles, les systèmes, les règles et les délais.
Une checklist avant de remplacer GUI par Fiori
Ne fondez pas la décision sur l’existence ou non d’une application Fiori — fondez-la sur le fait que l’application prend suffisamment bien en charge l’utilisateur, la tâche et le processus.
| Question | Ce qu’il faut vérifier |
|---|---|
| L’application couvre-t-elle le travail requis ? | Les champs, actions, filtres, variantes, rapports et exceptions sur lesquels les utilisateurs s’appuient aujourd’hui. |
| Qui utilise la transaction aujourd’hui ? | Distinguez les utilisateurs occasionnels, les utilisateurs clés, les consultants, les utilisateurs techniques et les utilisateurs experts à fort volume. |
| À quelle fréquence la tâche est-elle effectuée ? | Les tâches occasionnelles bénéficient d’un accompagnement ; les tâches expertes répétitives nécessitent rapidité et densité. |
| Quelle quantité d’informations est nécessaire en une seule fois ? | Si les utilisateurs comparent de nombreux champs, enregistrements ou exceptions, une application simplifiée peut s’avérer insuffisante. |
| La tâche fait-elle partie d’un processus plus large ? | Comprenez ce qui se passe avant et après l’application. |
| Existe-t-il des parcours d’exception courants ? | Vérifiez les reprises, les données manquantes, les rejets, les escalades et les flux alternatifs. |
| La conception des rôles correspond-elle au travail réel ? | Les utilisateurs doivent voir les applications dont ils ont besoin, sans un Launchpad rempli de tuiles non pertinentes. |
| Les utilisateurs auront-ils encore besoin de GUI ? | Décidez entre remplacement complet, remplacement partiel ou coexistence. |
| Les performances ont-elles été testées avec des données réelles ? | Une application agréable visuellement échoue à être adoptée si les chargements, les filtres ou les services backend sont lents. |
| Existe-t-il une documentation et une formation ? | Les utilisateurs doivent comprendre comment l’application s’intègre à leur processus, et pas seulement quelle tuile ouvrir. |
Appliquez cela avec de vrais utilisateurs, pas seulement pendant la configuration technique. Les utilisateurs clés font ressortir les détails faciles à manquer — dépendances cachées, variantes de mise en page, contrôles manuels, exports vers des feuilles de calcul, routines d’exception. Et comparez les scénarios avant de décider : une application peut être parfaite pour un manager approuvant une demande, mais insuffisante pour un spécialiste traitant des dizaines de cas par heure. La même organisation peut légitimement avoir besoin de Fiori pour un rôle et de GUI pour un autre.
Conclusion : des problèmes différents, des outils différents
SAP Fiori et SAP GUI ne sont pas une opposition entre « moderne » et « ancien ». Ils répondent à des problèmes d’expérience utilisateur différents.
Fiori est particulièrement efficace lorsque les utilisateurs ont besoin d’un travail basé sur les rôles, guidé, mobile, analytique ou en libre-service. Il aide les personnes à trouver les tâches pertinentes, supprime la nécessité de mémoriser des codes de transaction et offre aux activités métier un point d’entrée ciblé.
GUI reste précieux lorsque les utilisateurs ont besoin de rapidité, de densité, de familiarité et d’un contrôle opérationnel approfondi. Pour les utilisateurs avancés, les consultants, le personnel technique et les rôles à fort volume, l’expérience traditionnelle peut encore surpasser une application simplifiée qui masque des informations ou ajoute de la navigation.
Dans les environnements réels, la réponse se résume rarement à un remplacement net. Certains rôles s’épanouissent avec Fiori comme point d’entrée principal ; d’autres ont encore besoin de GUI pour un travail expert ; certains scénarios exigent un parcours Fiori repensé plutôt qu’un portage à l’identique ; certains processus nécessitent les deux, selon les personnes impliquées.
La leçon est simple : l’adoption de Fiori n’est pas une migration cosmétique des transactions vers les tuiles. C’est une décision de conception centrée sur l’utilisateur et les processus. Lorsque l’application, le rôle, l’appareil, les données et le processus sont alignés, Fiori rend le travail dans SAP plus accessible et plus ciblé. Lorsque ce n’est pas le cas, les utilisateurs perdent en rapidité, en visibilité ou en profondeur. Les meilleures équipes SAP ne se demandent pas seulement : « Pouvons-nous remplacer cette transaction par Fiori ? » Elles demandent : « Quelle expérience aide cet utilisateur à mieux effectuer ce travail ? »
FAQ
SAP Fiori et SAP GUI peuvent-ils être utilisés ensemble ?
Oui. De nombreux environnements SAP utilisent SAP Fiori et SAP GUI ensemble.
SAP Fiori peut devenir le principal point d’entrée pour les applications basées sur les rôles, les validations, le libre-service, les tableaux de bord, les tâches mobiles et les activités métier guidées. SAP GUI peut rester disponible pour les transactions expertes, les travaux techniques, la configuration, le dépannage ou les scénarios hérités où les utilisateurs ont encore besoin de rapidité et de profondeur fonctionnelle.
Cette approche hybride est souvent plus réaliste que d’essayer de remplacer toutes les transactions SAP GUI en une seule fois.
Une vignette Fiori est-elle toujours une application SAP Fiori native ?
Non. Une vignette dans le SAP Fiori Launchpad est un point d’entrée, pas une garantie que l’application sous-jacente est une application SAP Fiori native.
Selon la configuration, une vignette peut ouvrir une application Fiori native, une transaction SAP GUI via le navigateur, une application Web Dynpro, une URL externe ou un autre type d’application configurée.
C’est l’une des raisons pour lesquelles les utilisateurs peuvent vivre des expériences très différentes tout en accédant à tout depuis le Launchpad.
Pourquoi SAP Fiori semble-t-il parfois plus fragmenté que SAP GUI ?
Les transactions SAP GUI sont souvent larges et centrées sur les transactions. Une seule transaction peut inclure des actions, des champs, des onglets et des rapports utilisés par différents rôles.
SAP Fiori suit généralement un modèle davantage basé sur les rôles et orienté tâches. Au lieu d’exposer une transaction large à tout le monde, l’expérience peut être divisée en plusieurs applications conçues pour des rôles ou des activités spécifiques.
Cela peut améliorer la clarté pour les utilisateurs occasionnels, mais cela peut sembler fragmenté pour les utilisateurs avancés si le parcours de bout en bout n’est pas bien conçu.
Que doivent tester les équipes avant de faire passer les utilisateurs de SAP GUI à Fiori ?
Les équipes doivent tester des scénarios de travail réels, et pas seulement vérifier si l’application Fiori existe.
Elles doivent vérifier si l’application prend en charge les champs, les actions, les filtres, les variantes, les rapports, les exceptions, les autorisations et les attentes de performance dont les utilisateurs dépendent aujourd’hui. Elles doivent également tester le parcours complet avec des utilisateurs clés et des utilisateurs avancés, car de petits détails manquants peuvent avoir un impact majeur sur la productivité.
Le meilleur test n’est pas..
L’application peut-elle s’ouvrir ?
.. mais ..
L’utilisateur peut-il accomplir le travail efficacement et correctement ?
SAP Fiori réduit-il le besoin de formation des utilisateurs ?
Pas complètement.
SAP Fiori peut rendre certaines tâches plus faciles à comprendre, en particulier pour les utilisateurs occasionnels, les managers, les approbateurs et les scénarios de libre-service. Mais les utilisateurs doivent encore savoir quelles applications utiliser, comment le Launchpad est organisé, ce que leur rôle permet, ce qui a changé par rapport à SAP GUI, et comment chaque application s’intègre dans le processus métier plus large.
Une interface moderne peut réduire les frictions, mais elle n’élimine pas le besoin d’intégration, de documentation et d’accompagnement des processus.
Pourquoi certains utilisateurs perdent-ils en visibilité après le passage à SAP Fiori ?
SAP Fiori est basé sur les rôles, de sorte que les utilisateurs ne voient généralement que les applications attribuées à leur rôle. Cela améliore la concentration et la sécurité, mais peut aussi réduire la découvrabilité si les rôles sont trop restreints ou si les utilisateurs ne savent pas quelles applications existent.
Une bonne gouvernance aide à éviter ce problème. Les équipes doivent maintenir des définitions de rôles claires, des catalogues d’applications internes, de la documentation, des supports de formation et des processus de demande d’accès afin que les utilisateurs puissent comprendre non seulement ce à quoi ils peuvent accéder, mais aussi ce qui existe et pourquoi.
