SAP Fiori pour les utilisateurs avancés : pourquoi l’adoption est plus difficile qu’il n’y paraît

Sophia Reynolds

21 Jul 2026 — 18 min read

La plupart des déploiements SAP Fiori commencent par une promesse raisonnable : une expérience utilisateur plus épurée, moderne, basée sur les rôles, qui fonctionne sur n’importe quel appareil. Pour de nombreux utilisateurs, cette promesse est tenue. Les approbations deviennent plus rapides, les tâches occasionnelles plus faciles, et les scénarios mobiles fonctionnent enfin.

Mais quelque part entre le pilote et la mise en production, un schéma familier apparaît. Les utilisateurs qui connaissent le mieux SAP — les utilisateurs clés, les spécialistes fonctionnels, les personnes que tout le monde appelle quand quelque chose ne fonctionne plus — sont ceux qui expriment le plus fortement leurs réticences. Les équipes projet interprètent souvent cela comme une résistance au changement. Parfois, c’est le cas. Mais le plus souvent, il s’agit d’une réaction rationnelle à de réels changements en matière de rapidité, de densité des écrans, de modes de navigation et de visibilité du système.

Cet article explique pourquoi les utilisateurs avancés de SAP vivent Fiori différemment, dans quels cas leurs préoccupations sont justifiées, et comment les équipes SAP peuvent concevoir une stratégie d’adoption qui respecte l’expertise au lieu de l’écarter.

Qui sont les utilisateurs avancés SAP ?

Les utilisateurs avancés ne constituent pas un rôle SAP formel. Ils correspondent à un profil que l’on retrouve dans toute installation SAP mature :

Utilisateurs clés et super-utilisateurs qui représentent leur service dans les projets SAP et accompagnent leurs collègues au quotidien
Spécialistes fonctionnels dans des domaines comme MM, SD, FI, PP ou WM, qui exécutent de grands volumes de transactions
Utilisateurs métier expérimentés qui travaillent depuis des années sur les mêmes processus métier et connaissent chaque exception
Utilisateurs support qui analysent les incidents, reproduisent les erreurs et valident les corrections
Consultants internes et externes qui interviennent sur différents modules et chez différents clients

Ce qui les réunit, c’est la profondeur de leur connaissance du système. Ils connaissent les codes de transaction par cœur, gèrent leurs propres variantes de sélection, comprennent quels champs déterminent quels comportements en aval, et peuvent retracer un flux de documents depuis une commande client jusqu’à une écriture comptable sans ouvrir la documentation.

Ils occupent également une position organisationnelle spécifique : les utilisateurs avancés sont le pont entre les équipes métier et le support SAP ou l’IT. Lorsqu’un déploiement Fiori perd ce groupe, le projet ne perd pas seulement des indicateurs d’adoption — il perd sa couche de support interne.

Pourquoi SAP Fiori fonctionne bien pour certains utilisateurs

Avant d’examiner les points de friction, il convient de préciser les domaines dans lesquels SAP Fiori améliore réellement l’expérience, car les arguments sont solides :

Tâches guidées : Les utilisateurs qui utilisent SAP occasionnellement bénéficient d’écrans qui affichent uniquement ce que la tâche exige.
Scénarios en libre-service : Les demandes de congé, les notes de frais, les demandes d’achat et la saisie des temps sont bien plus faciles dans Fiori que dans les transactions classiques.
Accès mobile : Les approbations et confirmations depuis un téléphone ou une tablette ne sont tout simplement pas réalistes dans SAP GUI.
Actions des responsables : Le modèle My Inbox consolide les éléments de workflow qui étaient auparavant dispersés entre plusieurs transactions.
Accès basé sur les rôles : Les utilisateurs voient les applications pertinentes pour leur rôle au lieu de naviguer dans une arborescence de menus conçue pour tout le monde.
Points d’entrée analytiques : Les pages de synthèse et les vignettes KPI fournissent un contexte qu’une liste de transactions n’a jamais offert.

L’objectif de cet article n’est pas de dire que SAP Fiori est mauvais et que SAP GUI est bon. L’idée est que l’expérience utilisateur dépend de l’utilisateur et de la tâche. Une interface optimisée pour la clarté et l’accompagnement convient à un profil ; une interface optimisée pour la rapidité et la densité convient à un autre. Les problèmes d’adoption de Fiori apparaissent généralement précisément là où ces profils ont été traités comme identiques.

Pourquoi les utilisateurs avancés vivent Fiori différemment

Les utilisateurs avancés travaillent sous des contraintes différentes de celles des utilisateurs occasionnels. Leur travail se caractérise par :

Volume : des dizaines ou des centaines d’exécutions de transactions par jour, où les secondes gagnées ou perdues à chaque exécution s’accumulent
Travail au clavier : touches de fonction, rythmes avec la touche Entrée et tabulation de champ en champ, avec un recours très rare à la souris
Étendue : passages rapides entre de nombreuses transactions, et souvent entre plusieurs modules
Densité : le besoin de voir simultanément de nombreux champs, colonnes et postes pour repérer les anomalies
Filtrage avancé et variantes : écrans de sélection enregistrés, affinés au fil des années pour des analyses récurrentes
Exports : extraction fréquente vers Excel pour les rapprochements et les analyses ad hoc
Gestion des exceptions : travail qui commence précisément là où le processus standard a échoué
Dépannage : reproduction du problème d’un autre utilisateur, ce qui nécessite une visibilité au-delà de son propre rôle restreint

Aucun de ces besoins n’est exceptionnel. Ils constituent la réalité opérationnelle du travail SAP à fort volume. Lorsqu’une nouvelle interface modifie le coût de l’un d’entre eux — même légèrement — l’effet sur la journée d’un utilisateur avancé est multiplié par la fréquence.

La perte de rapidité des codes de transaction

Les codes de transaction méritent une discussion spécifique, car ils constituent l’un des mécanismes de productivité les plus sous-estimés dans SAP.

Pour un expert, un T-code n’est pas un raccourci de menu. C’est :

Un accès direct : /nME23N, Entrée, et la transaction est ouverte — pas de recherche, pas de balayage visuel, pas de clic
Une mémoire musculaire : la séquence s’exécute sans réflexion consciente, comme la frappe au clavier à l’aveugle
Un basculement rapide : /n et /o permettent un basculement instantané ou des sessions parallèles entre des transactions liées
Une exécution reproductible : la même transaction, la même variante, des dizaines de fois par jour avec un coût de navigation quasi nul

Fiori remplace ce modèle par des vignettes, la recherche dans le launchpad, la navigation sémantique, l’App Finder, ainsi que les espaces et les pages. Ces mécanismes remplissent réellement bien leur rôle : ils rendent les fonctionnalités découvrables, organisent le travail par rôle, et la recherche dans le launchpad (y compris sa capacité à lancer des applications en saisissant une partie du nom) est plus rapide que ne le supposent de nombreux critiques. Les utilisateurs peuvent également ajouter des applications à leurs propres pages, ce qui recrée partiellement une couche personnelle d’accès rapide.

Mais « découvrable » et « instantané » sont des qualités différentes. Rechercher « Manage Purchase Orders », attendre le chargement de l’application, puis cliquer pour y accéder constitue une opération physique et cognitive différente de la saisie de ME23N. Pour un utilisateur qui ouvre cette transaction trois fois par semaine, la différence est sans importance. Pour un utilisateur qui l’ouvre quarante fois par jour, elle ne l’est pas. Le modèle de navigation de Fiori constitue une réelle amélioration pour l’orientation — et un coût réel pour la rapidité. Ces deux affirmations sont vraies, et les stratégies d’adoption qui n’en reconnaissent qu’une seule évalueront mal la réaction des utilisateurs experts.

Densité des données : pourquoi « plus simple » peut sembler plus lent

L’un des principes de conception fondamentaux de Fiori est la simplification : moins de champs, des mises en page plus épurées, une divulgation progressive. Pour les utilisateurs occasionnels, cela réduit les erreurs et le temps de formation. Pour les utilisateurs avancés, cela peut inverser l’équation de la productivité.

Considérez la différence dans la pratique :

Une liste ALV classique peut afficher des dizaines de colonnes sur un seul écran, triables et filtrables sur place, avec des totaux et des sous-totaux visibles en même temps. Un expert la parcourt comme une feuille de calcul, repérant la ligne qui n’a pas sa place.
Un rapport de liste Fiori peut afficher moins de colonnes par défaut, déplacer les détails vers une page d’objet, et nécessiter de naviguer dans des éléments individuels puis d’en ressortir pour voir des informations qu’une transaction dense affichait directement en ligne.
Ce qui était un seul écran avec des onglets (pensez à la densité structurée de ME23N ou VA03) peut devenir une page d’objet avec des sections qui nécessitent de faire défiler, de développer et d’explorer.

Le défilement remplace le balayage visuel. La navigation remplace la vision périphérique. Pour un utilisateur dont le travail consiste à reconnaître des schémas parmi des centaines d’enregistrements, il ne s’agit pas d’un changement cosmétique — cela modifie le temps nécessaire pour effectuer le travail.

L’intention de conception est valable : la divulgation progressive protège les utilisateurs occasionnels de la complexité. Mais la conclusion pour les équipes de déploiement doit être tout aussi claire : un écran plus simple n’est pas toujours un écran plus rapide. La simplicité optimise la compréhension ; la densité optimise le débit. Le travail d’expert nécessite souvent la seconde.

Parcours fragmentés : lorsqu’une transaction devient plusieurs applications

SAP Fiori décompose fréquemment les transactions étendues en applications propres à une tâche. C’est délibéré et souvent bénéfique : un magasinier qui ne fait que confirmer des tâches n’a pas besoin de toute la complexité d’une transaction de supervision. Mais pour les utilisateurs qui travaillaient sur toute l’étendue d’une transaction, cette décomposition fragmente le parcours.

Quelques schémas concrets :

Achats : Le travail qui se faisait dans ME21N/ME22N/ME23N — création, modification, affichage, vérification de l’historique et accès aux documents associés — peut désormais s’étendre sur Manage Purchase Orders, Manage Purchase Requisitions, ainsi que sur des applications distinctes de supervision ou d’approbation. Chaque application est plus claire ; le parcours entre elles est plus long.
Opérations financières : Un comptable financier qui utilisait les affichages de postes individuels FBL1N/FBL3N/FBL5N comme point de départ travaille désormais avec plusieurs applications de gestion/affichage des postes individuels, avec des chemins de navigation différents vers le rapprochement, l’affichage des documents et les corrections.
Notifications qualité : Le traitement qui se faisait au sein d’une seule transaction de notification peut être réparti entre des applications de création, de traitement et d’analyse.
Entrepôt et logistique : La supervision, la gestion des exceptions et l’exécution peuvent être réparties entre des applications qui étaient auparavant des vues au sein d’une transaction de type cockpit.
Reporting et gestion des exceptions : Un expert qui examine un écart doit souvent passer d’un rapport à un document, puis à une fiche de données de base, et revenir en arrière. Dans l’interface graphique, cela se faisait via des sessions parallèles et des sauts par codes de transaction. Dans Fiori, cela dépend de la qualité de la configuration de la navigation sémantique — et du fait que les applications cibles soient ou non incluses dans le rôle de l’utilisateur.

Les applications propres à une tâche améliorent la clarté pour les rôles centrés sur une tâche. Mais les utilisateurs avancés sont, presque par définition, des travailleurs transverses à plusieurs tâches. Pour eux, la décomposition transforme un espace de travail dense en un itinéraire multi-applications, et le déploiement doit reconnaître ce parcours et le concevoir en conséquence, plutôt que de supposer que la somme des parties équivaut à l’ancien ensemble.

Accès basé sur les rôles et découvrabilité

L’accès basé sur les rôles est l’une des forces structurelles de Fiori : les utilisateurs voient ce dont leur rôle a besoin, la sécurité est plus nette, et le launchpad reste ciblé. Mais le même mécanisme crée des schémas de friction auxquels les utilisateurs de GUI n’étaient jamais confrontés :

Fonctionnalité invisible : Dans SAP GUI, un utilisateur sans autorisation pour une transaction pouvait tout de même voir qu’elle existait. Dans Fiori, une application qui ne figure pas dans votre catalogue n’apparaît tout simplement pas. Les utilisateurs ne peuvent pas distinguer « je n’ai pas accès » de « cette fonction n’existe pas dans Fiori ».
Le problème de correspondance : Les utilisateurs connaissent la transaction dont ils ont besoin. Ils ne savent pas quelle application l’a remplacée, si elle a été remplacée tout court, ou si le remplacement couvre leur scénario. Sans référence, ils concluent que Fiori « ne sait pas le faire ».
Visibilité du support : Les utilisateurs avancés qui dépannent leurs collègues ont souvent besoin de voir davantage que ce que leur propre rôle leur accorde. Une conception de rôles restreinte, parfaitement adéquate pour un opérateur de terrain, peut handicaper la personne qui assiste cet opérateur.
Charge de gouvernance : La découverte des applications ne s’organise pas toute seule. Quelqu’un doit organiser les catalogues, les espaces et les pages — et les maintenir à jour à mesure que le paysage applicatif évolue à chaque version.

Une mesure d’atténuation pratique adoptée par de nombreuses organisations est un catalogue interne des applications : une référence tenue à jour qui répertorie les applications Fiori disponibles, les transactions GUI auxquelles elles se rattachent, les rôles qui les contiennent, les limitations connues et la personne à contacter pour obtenir l’accès. C’est un travail de documentation peu glamour, et il figure constamment parmi les livrables d’adoption les plus précieux qu’un projet puisse produire.

Performance et confiance

La performance est le point sur lequel l’adoption de Fiori se gagne ou se perd auprès des utilisateurs experts, car leur tolérance est calibrée par la fréquence d’utilisation.

Les points de friction courants incluent :

Le temps de chargement du launchpad, en particulier lors de la première connexion ou après une invalidation du cache
Des rôles et catalogues surattribués, qui gonflent le contenu du launchpad que le navigateur doit traiter
Le comportement du navigateur : la consommation de mémoire, la discipline dans l’usage des onglets et la configuration du cache affectent toutes la vitesse perçue
Les conditions réseau, en particulier pour les sites de production distants, les entrepôts et les bureaux à domicile
La performance des services back-end : les temps de réponse OData dépendent de la configuration du branchement et de l’optimisation du back-end, pas seulement de la conception front-end
Des systèmes de test sous-dimensionnés : les pilotes s’exécutent sur des environnements QA disposant de moins de ressources, de sorte que la première impression des utilisateurs sur Fiori est plus lente que ce que sera la production — et les premières impressions persistent
Le coût de changement d’application : chaque navigation entre applications entraîne une surcharge de chargement qu’un saut de transaction /n n’avait jamais

Voici le calcul que les équipes projet manquent souvent : un délai de trois secondes n’est rien pour un manager qui approuve cinq demandes par jour. Pour un utilisateur intensif exécutant une tâche 200 fois par jour, trois secondes par exécution représentent dix minutes d’attente pure — chaque jour. De petits délais répétés des centaines de fois deviennent un sérieux problème de productivité, et ils deviennent un problème de confiance encore plus vite. Une fois que les utilisateurs experts décident que la nouvelle interface est lente, ils cessent de lui donner une seconde chance.

Les tests de performance avec de vraies charges de travail d’utilisateurs intensifs, sur une infrastructure réaliste, avant la mise en production ne sont pas un renforcement optionnel. C’est une stratégie d’adoption.

Former les utilisateurs avancés est différent

La formation générique des utilisateurs finaux — « voici le launchpad, voici comment rechercher, voici comment ouvrir une application » — est presque inutile pour les utilisateurs avancés, et peut même les irriter. Ils n’ont pas besoin d’apprendre à utiliser un logiciel. Ils doivent réapprendre où se trouve leur expertise.

Leurs questions sont précises :

« Où est passée cette fonction ? » — ce qui nécessite une mise en correspondance des transactions avec les applications, et non des présentations de fonctionnalités
« Comment recréer mes variantes ? » — ce qui nécessite une formation sur les barres de filtres Fiori, les vues enregistrées et la fonctionnalité d’adaptation des filtres
« Comment trouver des applications qui ne sont pas sur mon launchpad ? » — App Finder, la recherche et le processus de demande d’accès
« Qu’est-ce que Fiori ne sait pas encore faire ? » — une documentation honnête des écarts et des limites, qui inspire bien plus confiance que de prétendre que la parité existe
« Quand dois-je encore utiliser SAP GUI ? » — des consignes explicites, car les utilisateurs avancés découvriront de toute façon la réponse, et il vaut mieux qu’elle soit fournie par le projet

Le moment choisi est tout aussi important que le contenu. Les utilisateurs avancés doivent être impliqués avant le déploiement — dans les sessions d’analyse des écarts, les tests et la conception du launchpad — et non recevoir du matériel de formation après la mise en production. Former un expert une fois les décisions prises transforme un allié potentiel en critique crédible.

Pourquoi les utilisateurs experts doivent être impliqués tôt

Au-delà de la formation, les utilisateurs experts sont la ressource de validation la plus précieuse dont dispose un projet SAP Fiori, car ils savent où le processus se déforme réellement :

Valider la couverture fonctionnelle : confirmer que les applications Fiori choisies couvrent réellement les scénarios exécutés par le service, y compris les plus difficiles
Identifier les champs ou actions manquants : repérer qu’un champ utilisé quotidiennement pour un contournement n’est pas exposé dans la nouvelle application
Tester des scénarios réels : clôture mensuelle, clôture annuelle, haute saison et flux d’exception — pas seulement le scénario idéal du script de test
Comparer les workflows honnêtement : chronométrer l’ancien et le nouveau pour les tâches à forte fréquence, afin de produire des preuves plutôt que des opinions
Trouver les cas d’exception : la commande bloquée pour crédit, la commande d’achat partiellement livrée, le mouvement de marchandises annulé — les cas qui déterminent si une application est utilisable en pratique
Soutenir la formation : une formation dispensée par un pair, un utilisateur clé respecté, surpasse tout support externe
Façonner les launchpads basés sur les rôles : décider quelles applications doivent figurer sur quelles pages pour quels rôles, en fonction de la manière dont le travail se déroule réellement
Cartographier l’impact sur la productivité : identifier honnêtement où Fiori améliore le travail et où il le ralentit

Il existe aussi une réalité politique : les utilisateurs experts influencent leurs services. Si les collègues en qui l’on a confiance disent « le nouveau système fonctionne bien, et voici comment l’utiliser », l’adoption suit. S’ils disent « il est plus lent et la moitié de nos éléments manque », aucune campagne de communication ne pourra contrebalancer leur avis.

Erreurs courantes dans l’adoption de Fiori par les utilisateurs avancés

Les mêmes schémas d’échec se répètent d’un projet à l’autre :

Supposer qu’une interface utilisateur moderne signifie une meilleure productivité — considérer la modernisation visuelle comme automatiquement équivalente à une amélioration du flux de travail
Imposer trop tôt des politiques exclusivement Fiori — interdire SAP GUI avant que la couverture et les performances de Fiori ne le justifient
Ignorer le travail à forte intensité transactionnelle — concevoir le déploiement autour des approbations et du libre-service, alors que les utilisateurs au plus fort volume sont des travailleurs transactionnels
Fournir trop de vignettes sans curation — un tableau de bord non organisé avec 200 vignettes est un menu pire que celui qu’il remplace
Masquer les applications nécessaires derrière des rôles restrictifs — un minimalisme des rôles qui compromet les flux de travail de support et de dépannage
Ne pas mapper les transactions GUI aux applications Fiori — laisser les utilisateurs deviner où leur travail est passé
Remplacer une transaction par plusieurs applications sans expliquer le nouveau parcours — décomposer le flux de travail sans documenter le nouveau chemin à suivre
Ne pas tester les performances avec de vrais utilisateurs — valider les applications fonctionnellement sur des réseaux rapides et des systèmes vides, puis découvrir la latence en production
Traiter les réclamations des utilisateurs avancés comme de la résistance plutôt que comme des retours — l’erreur la plus coûteuse, car elle écarte la meilleure source de réalité terrain du projet

Une meilleure stratégie d’adoption

Un déploiement qui fonctionne pour les utilisateurs avancés repose sur la segmentation et la transparence plutôt que sur des obligations uniformes :

Segmentez les utilisateurs par profil. Les utilisateurs occasionnels, les managers, les travailleurs mobiles et les utilisateurs avancés ont des besoins différents. Concevez le déploiement par segment, et non par système.
Identifiez les tâches qui sont mieux adaptées à Fiori. Approbations, libre-service, confirmations mobiles, vues d’ensemble analytiques — migrez-les en toute confiance.
Identifiez les tâches qui doivent rester dans SAP GUI, pour le moment. Travail transactionnel à grand volume, analyse de listes denses et scénarios présentant des lacunes connues dans Fiori. Les nommer ouvertement est le signe d’un projet mature, pas d’un projet en échec.
Créez et maintenez une correspondance entre transactions et applications. Ce document unique répond à la question la plus fréquente des utilisateurs avancés avant même qu’elle ne soit posée.
Concevez soigneusement des launchpads basés sur les rôles. Des espaces et des pages sélectionnés par rôle, construits avec la contribution des utilisateurs clés, et révisés à mesure que le paysage applicatif évolue.
Publiez un catalogue interne d’applications Fiori. Applications, transactions associées, rôles, limitations et contacts pour les accès dans un emplacement facile à trouver.
Impliquez les utilisateurs avancés dans les tests — y compris les tests de performance avec des volumes réalistes, et pas seulement la validation fonctionnelle.
Documentez les limitations connues. Les utilisateurs pardonnent les lacunes dont ils ont été informés. Ils ne pardonnent pas celles qu’ils découvrent après qu’on leur a promis une parité.
Mettez en place de véritables canaux de retour d’information. Un mécanisme visible pour signaler les points de friction, avec des réponses visibles, transforme les réclamations en contributions à l’amélioration.
Adoptez une stratégie hybride lorsque c’est approprié. Ce qui nous amène au dernier point.

SAP Fiori et SAP GUI peuvent coexister

Il existe une hypothèse persistante dans la planification des déploiements selon laquelle l’utilisation de la GUI après la mise en production représente un échec d’adoption. Dans la plupart des environnements S/4HANA réels, elle représente autre chose : une division du travail pertinente.

Une stratégie d’interface mature ressemble généralement à ceci :

Fiori pour les tâches guidées, les scénarios mobiles, les approbations, le libre-service, les actions des managers et les points d’entrée analytiques — les scénarios où il s’agit clairement du meilleur outil
SAP GUI (y compris les transactions GUI intégrées dans le launchpad) pour les workflows denses, répétitifs, techniques ou destinés aux experts, où la vitesse de transaction et la densité des écrans restent avantageuses
Le Fiori Launchpad comme point d’entrée commun lorsque cela est utile, puisqu’il peut héberger à la fois des applications natives et des transactions classiques, offrant aux utilisateurs une porte d’entrée unique sans imposer un seul modèle d’interaction
Une documentation claire indiquant quelle interface est recommandée pour chaque processus, afin que le choix soit délibéré plutôt qu’accidentel

SAP lui-même a évolué dans cette direction : S/4HANA continue de prendre en charge les transactions GUI, et l’architecture du launchpad accueille explicitement les interfaces utilisateur classiques aux côtés des applications Fiori. La coexistence n’est pas un compromis destiné à être éliminé à une échéance donnée. C’est une stratégie de transition qui permet à chaque interface de faire ce qu’elle fait le mieux, tandis que la couverture, les performances et la familiarité des utilisateurs avec Fiori progressent version après version.

Réponse finale

L’adoption de SAP Fiori est plus difficile pour les utilisateurs avancés, car ils n’utilisent pas simplement des écrans — ils s’appuient sur des années de connaissances accumulées des processus, de schémas de transaction, de raccourcis clavier, de variantes et d’habitudes de navigation transverses entre fonctions. Lorsqu’un changement d’interface touche tout cela à la fois, la résistance n’est pas un problème d’attitude ; c’est la mesure d’un coût réel.

Un déploiement réussi respecte cette expertise. Il introduit Fiori là où il améliore manifestement le travail, conserve SAP GUI là où il reste le meilleur outil, établit explicitement la correspondance entre l’ancien monde et le nouveau, teste les performances à des volumes d’experts, et traite les utilisateurs avancés comme des partenaires de conception plutôt que comme des cibles d’adoption. Les équipes qui conçoivent en fonction des rôles utilisateurs réels et des processus métier réels obtiennent les deux résultats : des expériences modernes là où elles apportent de la valeur, et une productivité experte là où elle compte le plus.

FAQ

Pourquoi les utilisateurs avancés SAP préfèrent-ils souvent SAP GUI ?

Parce que leur productivité repose sur les codes de transaction, la navigation au clavier, les écrans denses de type ALV, les variantes enregistrées et le passage rapide entre transactions liées. SAP GUI est optimisé pour le travail expert à haute fréquence : pour de nombreuses tâches transactionnelles, il reste donc réellement plus rapide pour les utilisateurs expérimentés — cette préférence est opérationnelle, pas nostalgique.

SAP Fiori est-il mauvais pour les utilisateurs avancés ?

Non. SAP Fiori offre aux utilisateurs avancés de réels avantages dans les applications analytiques, les boîtes de réception de workflows, l’accès mobile et la navigation pilotée par la recherche. Les problèmes apparaissent lorsque des travaux transactionnels denses et à fort volume sont déplacés vers des applications simplifiées sans évaluer l’impact sur la productivité. Le problème relève de l’adéquation, pas de la qualité.

Les utilisateurs avancés peuvent-ils utiliser SAP GUI et Fiori ensemble ?

Oui. Les transactions SAP GUI restent disponibles dans S/4HANA et peuvent même être lancées depuis le Fiori Launchpad. Une configuration hybride — Fiori pour les scénarios guidés, mobiles et analytiques ; GUI pour le travail transactionnel dense — est une stratégie courante et légitime dans les paysages S/4HANA matures.

Les entreprises doivent-elles forcer tous les utilisateurs à passer à SAP Fiori ?

En général non, et surtout pas selon une échéance fixe déconnectée de la couverture fonctionnelle et des performances. Les obligations de passer uniquement à Fiori imposées avant que le paysage applicatif ne couvre les scénarios experts tendent à produire des contournements, des processus parallèles et une perte de confiance. Une migration par tâche et par segment d’utilisateurs fonctionne mieux qu’une migration par décret.

Pourquoi SAP Fiori semble-t-il plus lent pour les utilisateurs expérimentés ?

Pour trois raisons qui se cumulent : le coût de navigation (rechercher et charger des applications plutôt que saisir un code de transaction), le coût d’interaction (faire défiler et explorer des pages d’objet plutôt que parcourir des listes denses) et la latence technique (temps de chargement du launchpad et d’OData). Chaque coût est faible, mais les utilisateurs avancés répètent des opérations des centaines de fois par jour ; les secondes se transforment donc en perte de temps significative.

Comment les équipes peuvent-elles améliorer l’adoption de SAP Fiori par les utilisateurs avancés ?

Les impliquer avant la mise en production dans les tests et la conception du launchpad, fournir une correspondance transaction-application, organiser des launchpads basés sur les rôles, tester les performances avec des volumes réalistes, documenter honnêtement les limites connues, proposer une formation de niveau expert centrée sur « où est passée ma fonction » et autoriser SAP GUI lorsqu’il reste le meilleur outil.

Que faut-il documenter avant de faire passer les utilisateurs avancés à Fiori ?

Une correspondance transaction-application, un catalogue interne des applications Fiori avec les rôles et les contacts d’accès, les lacunes fonctionnelles et limites connues par application, des recommandations sur l’interface à utiliser selon le processus, les instructions de migration des variantes et filtres, ainsi que le canal de retour pour signaler les problèmes.

Les codes de transaction sont-ils encore pertinents dans S/4HANA ?

Oui. S/4HANA continue de prendre en charge un grand nombre de transactions classiques via SAP GUI et GUI for HTML, et de nombreuses organisations y exécutent encore aujourd’hui des processus transactionnels essentiels. Certaines transactions ont été remplacées ou dépréciées au profit d’applications Fiori ; la pertinence doit donc être vérifiée transaction par transaction — mais les codes de transaction comme modèle de travail sont loin d’avoir disparu.

Quand SAP Fiori est-il meilleur que SAP GUI pour les utilisateurs avancés ?

Pour les vues d’ensemble analytiques et le suivi piloté par les KPI, le traitement des workflows et des approbations via My Inbox, les situations nécessitant un accès mobile, la recherche inter-applications et les nouvelles fonctionnalités S/4HANA fournies uniquement sous forme d’applications Fiori. Dans ces scénarios, Fiori n’est pas seulement équivalent — il fait des choses que SAP GUI ne peut pas faire.

Quelle est la meilleure stratégie de déploiement de SAP Fiori pour les utilisateurs clés ?

Segmenter par profil utilisateur et par tâche, lancer tôt un pilote avec les utilisateurs clés, construire ensemble la correspondance transaction-application, définir des launchpads organisés par rôle, valider les performances avec de réels volumes de transactions, exécuter Fiori et SAP GUI en parallèle pendant la transition, puis élargir le périmètre de Fiori sur la base d’une productivité mesurée plutôt que d’une date de bascule fixe.