Quand faut-il conserver SAP GUI au lieu de passer à Fiori ?

Si votre organisation mène un projet S/4HANA, vous avez probablement déjà entendu une version du même message : SAP Fiori est l’avenir, SAP GUI appartient au passé, et chaque transaction devrait finir par devenir une tuile sur le Launchpad.

La réalité au sein de la plupart des environnements SAP est plus nuancée. SAP Fiori constitue une véritable amélioration pour de nombreux scénarios — validations sur téléphone, demandes en libre-service, vues d’ensemble analytiques, tâches guidées pour les utilisateurs occasionnels. Mais considérer Fiori comme un remplacement automatique de chaque transaction SAP GUI relève d’une décision de projet, et non d’une décision utilisateur, et cela se retourne souvent contre les équipes. Les équipes qui imposent une migration complète sans évaluer la manière dont le travail est réellement effectué constatent généralement les mêmes symptômes : des comptables fournisseurs qui demandent discrètement à récupérer leur ancienne transaction, des responsables d’entrepôt qui jonglent avec trois applications pour faire ce qu’un seul écran permettait auparavant, des services d’assistance submergés de tickets du type « où est passée ma transaction ? », et des rapports d’adoption qui paraissent moins bons trois mois après la mise en production qu’au premier jour.

Cet article n’est pas une défense de SAP GUI, et ce n’est pas une critique de SAP Fiori. C’est un guide pratique pour répondre à une question à laquelle chaque équipe S/4HANA et de modernisation des interfaces finit par être confrontée : pour cet utilisateur, ce processus et cette tâche spécifiques — quelle interface est réellement adaptée ?

SAP GUI et SAP Fiori résolvent des problèmes différents

Une partie de la confusion vient du fait que l’on compare les deux comme s’il s’agissait de versions concurrentes d’une même chose. Ce n’est pas le cas.

SAP GUI est centré sur les transactions. Il a été conçu autour de l’idée qu’un utilisateur formé ouvre un code de transaction — VA01, ME21N, MIGO, FBL1N — et travaille dans un écran dense, piloté au clavier, qui expose presque tout ce que l’objet métier sous-jacent peut faire. Onglets, touches de fonction, grilles ALV, variantes de mise en page, saisie par lot : la conception suppose l’expertise et la récompense. Pour quelqu’un qui exécute la même transaction deux cents fois par jour, cette densité n’est pas de l’encombrement. C’est du débit.

SAP Fiori est basé sur les rôles et orienté tâches. Au lieu de demander « de quelle transaction ai-je besoin ? », il demande « que doit accomplir ce rôle ? ». Une application Fiori isole généralement une tâche — approuver une demande d’achat, créer une demande de congé, vérifier des factures fournisseurs — et la présente dans une interface moderne, responsive et basée sur un navigateur, qui fonctionne sur ordinateur, tablette ou téléphone. Pour quelqu’un qui utilise SAP deux fois par mois, cette focalisation n’est pas une limite. C’est ce qui rend la tâche possible sans formation.

Présentée ainsi, la question « Lequel est le meilleur ? » n’a pas de réponse utile. La question utile est : lequel convient à cet utilisateur, à ce processus et à cette tâche ? Le reste de cet article décompose cette question en critères de décision concrets.

Quand SAP GUI peut encore être le meilleur choix

Il existe des scénarios récurrents où SAP GUI reste l’option la plus pratique, même dans un environnement S/4HANA mature :

• Travail opérationnel à volume élevé. Les rôles qui traitent de grandes files de documents — vérification des factures avec MIRO, mouvements de marchandises avec MIGO, saisie des commandes client avec VA01 — reposent sur la répétition, les automatismes et un nombre minimal de clics par document. Une refonte d’écran qui ajoute ne serait-ce que deux secondes par document coûte des heures par semaine à grande échelle.
• Utilisateurs qui travaillent avec des codes de transaction et des raccourcis. Les utilisateurs expérimentés naviguent dans SAP en saisissant /n et un T-code, en enchaînant les écrans avec les touches de fonction et en passant d’une session à l’autre. Remplacer cela par une navigation par tuiles et une recherche supprime une méthode de travail qu’ils ont optimisée pendant des années.
• Tâches nécessitant de nombreux champs, onglets, filtres ou grilles de données. Certains objets métier sont tout simplement complexes. Un ordre de fabrication, un élément WBS ou une fiche article complète (MM02 avec ses dizaines de vues) ne devient pas plus simple parce que l’écran est plus simple : la complexité est simplement répartie sur davantage d’étapes.
• Processus avec des transactions GUI matures et sans application Fiori équivalente. Le catalogue Fiori de SAP est vaste, mais pas complet, et la couverture varie selon le module et la version. Lorsque la transaction classique est la seule option entièrement fonctionnelle, la conserver n’est pas une résistance au changement ; c’est la seule manière d’effectuer le travail.
• Transactions fortement personnalisées. Les transactions Z, les exits d’écran, les champs personnalisés et les processus fortement enrichis par des extensions n’ont souvent aucun équivalent Fiori, et les reconstruire sous forme d’applications Fiori personnalisées est un projet de développement, pas une tâche de configuration.
• Travail technique et administratif. Les activités Basis, ABAP et de support — SE38, SM37, ST22, SU01, SPRO — s’intègrent naturellement dans SAP GUI. Il y a peu de valeur pratique à déplacer la surveillance des jobs ou le débogage vers une tuile de navigateur.
• Situations où la vitesse et la densité priment sur la simplicité visuelle. Lorsque le critère de réussite est le nombre de documents par heure plutôt que la facilité de première utilisation, l’interface plus dense l’emporte fréquemment.

Quand SAP Fiori peut être le meilleur choix

La même logique fonctionne dans l’autre sens. Il existe des scénarios où SAP GUI est clairement le mauvais outil et où Fiori apporte une valeur réelle et mesurable :

• Utilisation sur mobile et tablette. SAP GUI n’a jamais été conçu pour un téléphone. Fiori, si.
• Opérations sur le terrain. Les techniciens qui confirment des ordres de maintenance, les chauffeurs qui enregistrent des livraisons ou les inspecteurs qui saisissent des résultats sur site bénéficient directement d’applications réactives et adaptées au tactile.
• Utilisateurs occasionnels. Un employé qui soumet une note de frais par mois ne devrait jamais avoir à apprendre un code de transaction.
• Approbations par les managers. Approuver des demandes d’achat, des demandes de congé ou des feuilles de temps depuis une application de boîte de réception — souvent en quelques secondes, depuis n’importe où — est l’un des cas d’utilisation les plus solides de Fiori.
• Scénarios en libre-service. Le libre-service RH, les demandes d’approvisionnement et la gestion des déplacements fonctionnent mieux sous forme de parcours guidés que comme des transactions expertes.
• Accès basé sur les rôles. Présenter à chaque rôle uniquement les tuiles dont il a besoin réduit le bruit et simplifie l’intégration par rapport à un champ de commande GUI vide.
• Tâches ciblées à objectif unique. Lorsqu’une tâche a un début et une fin clairement définis, une application dédiée est plus facile à apprendre et rend les erreurs plus difficiles.
• Vues d’ensemble analytiques. Les pages d’aperçu, les tuiles d’indicateurs clés de performance et les analyses intégrées offrent aux managers et aux utilisateurs clés une visibilité immédiate que les transactions classiques n’ont jamais proposée.
• Parcours utilisateur simplifiés. Les processus repensés autour d’un nombre réduit d’étapes — gestion des situations, workflows guidés — peuvent réellement réduire l’effort, et pas seulement relooker l’écran.
• Nouveaux utilisateurs. Les personnes qui rejoignent l’organisation sans historique SAP apprennent le modèle de Fiori basé sur les tâches bien plus rapidement que les codes de transaction.

Une stratégie d’interface crédible reconnaît les deux listes. L’erreur consiste à appliquer l’une ou l’autre de manière universelle.

Couverture fonctionnelle : l’application Fiori remplace-t-elle vraiment la transaction GUI ?

L’erreur la plus courante — et la plus coûteuse — lors des déploiements Fiori consiste à supposer qu’une application ayant le même objectif qu’une transaction offre la même fonctionnalité. Avant de retirer une transaction GUI, les équipes doivent valider la couverture point par point :

• Champs obligatoires : Tous les champs réellement utilisés par le métier sont-ils disponibles dans l’application, y compris ceux ajoutés au fil des années ?
• Actions requises : Les utilisateurs peuvent-ils effectuer chaque opération — pas seulement créer et afficher, mais aussi annuler, bloquer, valider, réaffecter, modifier en masse ?
• Variantes : Les utilisateurs s’appuient-ils sur des variantes de sélection ou des variantes de mise en page que l’application ne peut pas reproduire ?
• Filtres : Les utilisateurs peuvent-ils filtrer et trier comme ils le font aujourd’hui, en particulier sur de grands ensembles de résultats ?
• Exports : L’export vers un tableur est-il disponible, complet et présenté dans un format exploitable ?
• Pièces jointes : Les pièces jointes aux documents sont-elles visibles, et les utilisateurs peuvent-ils en ajouter ?
• Approbations : L’application s’intègre-t-elle au même workflow, avec les mêmes agents et règles d’escalade ?
• Exceptions : Les utilisateurs peuvent-ils gérer les cas non standards — livraisons partielles, écarts de prix, documents bloqués ?
• Champs personnalisés : Les champs spécifiques au client apparaissent-ils, et sont-ils modifiables lorsque nécessaire ?
• Rapports : Les rapports en aval et les transactions de suivi restent-ils naturellement connectés ?
• Comportement des autorisations : Fiori utilise des catalogues, des groupes et des services OData en plus des objets d’autorisation classiques — l’accès effectif correspond-il à ce que les utilisateurs ont aujourd’hui ?
• Étapes de processus environnantes : L’utilisateur peut-il naviguer vers l’étape suivante du processus, ou l’application se termine-t-elle en impasse, obligeant de toute façon à revenir à SAP GUI ?

Une application Fiori qui couvre 85 % d’une transaction semble proche de l’objectif. Dans la réalité opérationnelle, les 15 % manquants contiennent souvent précisément la gestion des exceptions que les utilisateurs expérimentés traitent au quotidien. Si les utilisateurs doivent ouvrir SAP GUI pour terminer ce que l’application a commencé, la migration a ajouté une étape au lieu d’en supprimer une.

Profil utilisateur : utilisateur occasionnel, utilisateur clé ou utilisateur avancé ?

Les interfaces ne sont pas évaluées dans l’abstrait ; elles sont évaluées par des personnes ayant des relations très différentes avec le système.

Un utilisateur occasionnel évalue une interface selon qu’il peut accomplir la tâche sans aide. Un responsable l’évalue selon la rapidité avec laquelle il peut agir sur ce qui l’attend, souvent depuis un téléphone entre deux réunions. Un utilisateur clé a besoin d’une visibilité suffisante pour répondre aux questions de son équipe et repérer les problèmes de processus. Un consultant ou analyste support doit naviguer en profondeur dans les documents, les tables et les journaux afin de diagnostiquer les problèmes. Un utilisateur avancé évalue l’interface en frappes clavier et en secondes, car sa journée est faite de milliers des deux.

Implication pratique : les décisions d’interface prises par rôle et tâche seront plus performantes que celles prises par transaction. Le même processus de commande d’achat peut être dans Fiori pour le demandeur, dans Fiori pour l’approbateur, et dans GUI pour l’acheteur qui traite cinquante commandes par jour.

Fréquence des tâches et densité des données

Deux dimensions permettent de prédire l’adéquation d’une interface mieux que presque tout le reste : la fréquence à laquelle la tâche est effectuée et le volume de données qu’elle implique.

La fréquence change ce que signifie « utilisable ». Une tâche effectuée une fois par mois peut tolérer — et même bénéficier de — conseils, d’étapes de confirmation supplémentaires et d’écrans explicatifs. L’utilisateur a oublié les détails depuis la dernière fois. Une tâche effectuée des centaines de fois par semaine ne peut tolérer rien de tout cela. Chaque étape guidée qui aide l’utilisateur mensuel devient une friction pour l’utilisateur quotidien.

La densité change ce que signifie « simple ». Les grandes grilles ALV dans SAP GUI permettent aux utilisateurs de parcourir des centaines de postes, de trier, de calculer des sous-totaux, de filtrer et de modifier directement. Les écrans de liste simplifiés qui affichent moins de colonnes et paginent les résultats peuvent transformer une revue de deux minutes en un défilement de quinze minutes. Lorsque le travail consiste fondamentalement à parcourir de nombreux enregistrements — apurer des postes non soldés, examiner les résultats MRP, rapprocher des écarts de stock — un écran optimisé pour la lisibilité d’un seul enregistrement va à l’encontre de la tâche.

Aucun de ces points ne constitue un argument contre Fiori en général. Les rapports de liste Fiori avec des tables intelligentes gèrent des volumes de données importants, et certains scénarios sont nettement meilleurs dans Fiori. L’idée est que la fréquence et la densité doivent être mesurées pour la tâche réelle avant de décider — et non supposées à partir d’une démonstration avec dix enregistrements d’exemple.

Performance et productivité

Les discussions sur la performance autour de Fiori restent souvent théoriques jusqu’à la mise en production, puis deviennent très concrètes. Les équipes doivent évaluer de manière réaliste :

• Le temps de chargement du Launchpad, en particulier le premier chargement de la journée et après invalidation du cache.
• Le nombre de rôles et d’applications attribués à un utilisateur — les Launchpads fortement chargés avec des centaines de tuiles se chargent plus lentement et sont plus difficiles à parcourir.
• Le comportement du navigateur, y compris les politiques de navigateur de l’entreprise, les extensions et les limites de mémoire sur les anciennes machines clientes.
• Les conditions réseau — Fiori est plus bavard sur le réseau que le protocole optimisé de GUI, ce qui compte pour les sites de production distants, les utilisateurs VPN et les sites à faible bande passante.
• La performance du backend et des services OData, car une application bien conçue sur un branchement lent reste une application lente.
• L’écart entre les tests et la production — une application testée avec 50 documents se comporte différemment avec 50 000.
• La vitesse perçue par rapport à la disponibilité technique — un système peut être « disponible » tout en semblant lent, et les utilisateurs jugent le ressenti, pas le tableau de bord de supervision.

La performance mérite de l’attention, car ce n’est pas seulement une métrique informatique. C’est une variable d’adoption. Les utilisateurs qui font l’expérience d’un Launchpad lent au cours de leur première semaine se forgent une opinion que la formation ne pourra pas effacer, et ils retrouveront le chemin de GUI — officiellement ou non. Si l’expérience Fiori ne peut pas être rendue réactive dans des conditions réelles pour une tâche donnée, c’est une raison légitime de conserver la transaction GUI jusqu’à ce qu’elle le puisse.

Personnalisation et processus hérités

La plupart des environnements SAP datant de plus de quelques années ne sont pas standard. Ils comportent des exits utilisateur, des BAdI, des écrans personnalisés, des champs Z, une logique de validation et des transactions Z entières construites autour de la manière dont l’entreprise fonctionne réellement. Cette base installée modifie considérablement l’équation de migration. Avant de déplacer un processus personnalisé vers Fiori, les équipes doivent évaluer :

• Le processus suit-il les hypothèses SAP standard ? Les applications Fiori sont conçues pour des processus standard. Plus un processus s’est éloigné du standard, moins l’application a de chances de convenir sans modification.
• L’application prend-elle en charge les types de documents, champs, validations ou écrans personnalisés utilisés ? Certaines extensions sont reprises via l’extensibilité intégrée à l’application ou les champs des utilisateurs clés ; la logique d’écran profondément intégrée ne l’est généralement pas.
• La transaction comporte-t-elle des améliorations locales dont les utilisateurs dépendent ? Un bouton personnalisé qui automatise une correction en cinq étapes peut être invisible dans la documentation, mais essentiel dans le travail quotidien.
• La reconstruction de l’expérience vaut-elle l’effort ? Recréer une transaction fortement personnalisée sous forme d’application Fiori personnalisée constitue un véritable développement : conception, services OData, travail avec UI5 ou Fiori elements, tests et maintenance continue.
• Conserver SAP GUI est-il tout simplement plus pratique dans ce cas ? Parfois, la réponse honnête est oui, au moins pour l’horizon de planification actuel.

Il existe également une version stratégique de cette question : si un processus est tellement personnalisé qu’aucune application standard ne convient, la bonne démarche à long terme peut être de reconcevoir le processus vers le standard plutôt que de reconstruire la personnalisation dans une nouvelle interface. Mais il s’agit d’une décision de processus qui mérite son propre projet — et non d’un effet secondaire d’une migration d’interface utilisateur.

Le mobile n’est pas toujours le facteur décisif

« Fiori est mobile » est vrai, et c’est l’un des arguments les plus forts en faveur de son adoption — pour les scénarios qui sont réellement mobiles. Confirmations d’interventions sur le terrain, tâches d’entrepôt sur terminaux portables, approbations sur téléphone, tournées de maintenance d’usine : ce sont des cas réels, à forte valeur ajoutée, où la mobilité change la manière dont le travail est effectué.

Mais une grande partie du travail SAP est, et restera, un travail sur poste de bureau. Un comptable financier qui clôture le mois, un planificateur des articles qui examine les exceptions MRP, un agent du service client avec un casque qui saisit des commandes — ces utilisateurs sont assis à leur bureau, avec de grands écrans et des claviers complets. Pour eux, « cela fonctionne aussi sur un téléphone » n’apporte aucun bénéfice, et les choix de conception axés d’abord sur le mobile (zones tactiles plus grandes, moins de champs visibles, mises en page verticales) peuvent nuire à l’expérience sur poste de bureau.

Le test est simple : quelqu’un effectue-t-il réellement cette tâche loin d’un bureau, ou le ferait-il s’il le pouvait ? Si oui, la mobilité est un argument fort en faveur de Fiori. Si non, la décision devrait reposer sur les autres critères de cet article — couverture, densité, performance, profil utilisateur — avec une pondération de la mobilité à zéro plutôt que considérée comme un bénéfice acquis.

Formation et gestion du changement

Même lorsque Fiori est clairement la bonne destination, la transition échoue sans une gestion du changement délibérée. Plusieurs réalités doivent être planifiées, et non découvertes :

Les utilisateurs ne doivent pas être forcés à passer à Fiori sans comprendre le nouveau parcours. Le changement n’est pas cosmétique. La logique de navigation, la terminologie et la forme du travail changent toutes.

Une transaction peut devenir plusieurs applications. Ce qui était un seul écran avec des onglets — afficher le fournisseur, modifier le fournisseur, consulter les postes non soldés — peut désormais correspondre à trois ou quatre vignettes. Les utilisateurs doivent savoir que c’est intentionnel, et où chaque élément se trouve désormais.

Les utilisateurs ont besoin d’une correspondance entre l’ancien et le nouveau. « Quelle vignette remplace VA02 ? » est la question la plus fréquente lors d’un déploiement Fiori. Une correspondance publiée entre transactions et applications, tenue à jour, évite des milliers de tickets de support.

Les utilisateurs clés ont besoin d’un parcours de support clair. Lorsqu’une application ne dispose pas d’une fonction ou se comporte de manière inattendue, les utilisateurs clés doivent savoir s’il s’agit d’un bug, d’un manque de formation, d’une autorisation manquante ou d’une limitation connue — et à qui s’adresser.

La formation doit expliquer le processus, pas seulement l’écran. Montrer aux utilisateurs où les boutons ont été déplacés produit de la conformité. Expliquer comment le processus de bout en bout s’écoule désormais — et pourquoi — produit de l’adoption. C’est particulièrement vrai lorsque le déploiement Fiori coïncide avec de véritables changements de processus dans S/4HANA, ce qui est généralement le cas.

Une checklist décisionnelle pratique

Checklist de décision SAP GUI vs SAP Fiori

Soumettez chaque transaction ou tâche importante à ces questions avant de décider :

1. Qui effectue cette tâche ? Utilisateur occasionnel, responsable, utilisateur clé, support ou utilisateur avancé ?
2. À quelle fréquence est-elle effectuée ? Tous les mois, tous les jours ou des centaines de fois par semaine ?
3. La tâche est-elle mobile ou réalisée sur poste de travail ? Quelqu’un doit-il l’effectuer loin d’un bureau ?
4. L’application Fiori couvre-t-elle toutes les fonctionnalités requises ? Champs, actions, variantes, filtres, exports, pièces jointes, exceptions ?
5. Existe-t-il des champs personnalisés ou des extensions ? Sont-ils repris dans l’application ?
6. L’utilisateur a-t-il besoin d’une forte densité de données ? Grandes grilles, traitement de masse, modification directe ?
7. L’application Fiori est-elle suffisamment rapide en conditions réelles ? Volumes de données réels, réseau réel, machines clientes réelles ?
8. L’utilisateur s’appuie-t-il sur des codes de transaction ou des raccourcis clavier ? Leur suppression ralentirait-elle le travail ?
9. Le processus nécessite-t-il plusieurs applications liées ? Une transaction deviendrait-elle un parcours à plusieurs vignettes ?
10. S’agit-il d’une transition temporaire ou d’une expérience cible à long terme ? Une meilleure application est-elle attendue dans une future version ?
11. De quelles formations et documentations les utilisateurs auront-ils besoin ? Qui les produira et les maintiendra ?
12. Quel est le coût d’une migration imposée ? En productivité, charge de support et confiance des utilisateurs — par rapport au bénéfice obtenu ?

Si les réponses pointent clairement dans une direction, la décision est facile. Si elles se contredisent — un besoin mobile mais une couverture incomplète, un utilisateur avancé mais une application analytique solide — le conflit lui-même constitue le constat : cette tâche peut nécessiter les deux interfaces, ou une refonte, plutôt qu’un choix imposé.

Stratégie hybride recommandée

Pour la plupart des organisations, l’objectif réaliste et défendable n’est pas une approche uniquement basée sur l’interface graphique ni uniquement basée sur Fiori. Il s’agit d’un hybride délibéré :

• SAP Fiori pour le libre-service, les approbations, les scénarios mobiles et de terrain, les analyses et pages de synthèse, ainsi que les tâches ciblées effectuées par des utilisateurs occasionnels — les scénarios dans lesquels la conception de Fiori correspond réellement au travail.
• SAP GUI pour les utilisateurs experts effectuant un travail opérationnel dense, des tâches techniques et administratives, des transactions fortement personnalisées, et des processus pour lesquels aucune application Fiori adéquate n’existe encore.
• Le Fiori Launchpad comme point d’entrée commun lorsque cela est approprié — y compris le lancement de transactions GUI classiques (via SAP GUI for HTML ou des tuiles WebGUI intégrées) aux côtés d’applications natives, afin que les utilisateurs disposent d’un seul endroit pour commencer, même lorsque la technologie sous-jacente diffère.
• Une documentation interne qui rend la répartition explicite. Les utilisateurs ne devraient jamais avoir à deviner quelle interface utiliser pour un processus donné. L’ambiguïté est le terrain où se développent les habitudes parallèles et le travail en double.

Une stratégie hybride n’est pas un compromis ni le signe d’une modernisation incomplète. C’est ce à quoi ressemble une approche « consciente des processus » dans la pratique. La composition de ce mélange évoluera au fil du temps à mesure que la couverture de Fiori s’étendra, que les applications gagneront en maturité et que les processus seront repensés — c’est précisément pourquoi la stratégie doit être documentée et réexaminée, plutôt que décidée une fois pour toutes puis figée.

Ce que les équipes doivent documenter

La différence entre un paysage hybride géré et un paysage hybride accidentel réside dans la documentation. Les équipes doivent maintenir un catalogue interne des interfaces — un document vivant, dont quelqu’un est responsable — comprenant au minimum :

• Processus métier (par ex., traitement des factures fournisseurs)
• Transaction SAP GUI (par ex., MIRO, FBL1N)
• Application ou tuile Fiori (nom et ID d’application, par ex. « Create Supplier Invoice », F0859)
• Type d’application (SAPUI5 freestyle, Fiori elements, application classique dans WebGUI, Web Dynpro)
• Utilisateurs / rôles cibles (qui est censé utiliser quelle interface)
• Limitations connues (écarts fonctionnels par rapport à la transaction GUI, avec des détails précis)
• Compatibilité mobile (testée sur quels appareils, pour quelles étapes)
• Notes de performance (temps de chargement réels, goulets d’étranglement connus, limites de volume de données)
• Supports de formation (lien vers le guide, la vidéo ou l’aide-mémoire pour chaque interface)
• Responsable (qui décide et qui répond aux questions)
• Décision de migration : conserver le GUI, passer à Fiori, utiliser les deux, ou repenser le processus

Ce catalogue est rapidement rentabilisé. Il transforme la question « pourquoi utilisons-nous encore le GUI pour cela ? » d’un débat récurrent en une décision documentée, avec des raisons explicitées et une date de révision. Il donne aux équipes de formation une source unique de vérité. Et il rend le mouvement progressif vers Fiori mesurable, plutôt qu’anecdotique.

Réponse finale

Conservez SAP GUI lorsque la tâche exige de la rapidité, de la profondeur, une forte densité de données, des fonctionnalités transactionnelles matures, un contrôle technique ou un comportement personnalisé que l’application Fiori disponible ne prend pas correctement en charge. Passez à SAP Fiori lorsque le travail bénéficie d’un accès basé sur les rôles, d’une interaction guidée, d’un accès mobile, du libre-service, de l’analytique ou d’une expérience utilisateur simplifiée — et que l’application couvre réellement la tâche.

La meilleure stratégie d’interface SAP n’est ni exclusivement GUI ni exclusivement Fiori. Elle est adaptée aux processus, aux rôles et ancrée dans la manière dont le travail est réellement effectué. Les équipes qui évaluent chaque tâche selon ses propres mérites — profil utilisateur, fréquence, densité, couverture, personnalisation, performance et mobilité — obtiennent au final une meilleure adoption, des coûts de support plus faibles et des utilisateurs qui font confiance aux interfaces qui leur ont été fournies, parce que ces interfaces ont été choisies pour eux, et non imposées.

Foire aux questions

SAP Fiori remplace-t-il SAP GUI ?

SAP Fiori est l’expérience utilisateur stratégique de SAP pour S/4HANA, et les nouvelles fonctionnalités sont de plus en plus livrées sous forme d’applications Fiori. Cependant, SAP GUI reste entièrement pris en charge et largement utilisé, et de nombreuses transactions n’ont pas d’équivalent Fiori complet. En pratique, Fiori se développe plutôt qu’il ne remplace instantanément SAP GUI, et la plupart des clients S/4HANA utilisent les deux.

Les entreprises peuvent-elles encore utiliser SAP GUI avec S/4HANA ?

Oui. SAP GUI fonctionne avec S/4HANA (éditions sur site et cloud privé), et des milliers de transactions classiques restent disponibles. Certaines transactions ont été supprimées ou remplacées dans le cadre de la simplification de S/4HANA, mais SAP GUI lui-même est une méthode d’accès prise en charge, et les transactions classiques peuvent même être lancées sous forme de tuiles depuis le Fiori Launchpad.

Quand SAP GUI est-il préférable à SAP Fiori ?

SAP GUI tend à être préférable pour le travail opérationnel à fort volume, les utilisateurs avancés qui s’appuient sur les codes de transaction et les raccourcis clavier, les tâches comportant des grilles de données denses et de nombreux champs, les transactions fortement personnalisées, les activités techniques et administratives, ainsi que tout processus pour lequel l’application Fiori disponible ne couvre pas l’ensemble des fonctionnalités de la transaction classique.

Quand SAP Fiori est-il préférable à SAP GUI ?

SAP Fiori est préférable pour les scénarios mobiles et de terrain, les validations par les managers, les tâches en libre-service, les utilisateurs occasionnels qui ne connaissent pas les codes de transaction, l’accès basé sur les rôles, les vues d’ensemble analytiques et les tâches ciblées à objectif unique. Dans ces scénarios, Fiori permet généralement une exécution plus rapide, un effort de formation réduit et une plus grande satisfaction des utilisateurs que SAP GUI.

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

Les utilisateurs avancés optimisent le débit de travail : les codes de transaction, les touches de fonction, les sessions multiples, les variantes de mise en page et les grilles ALV denses leur permettent de traiter de grands volumes avec un minimum de clics. Les interfaces simplifiées et guidées suppriment précisément la densité et le contrôle au clavier qui rendent leur travail rapide, de sorte qu’un écran qui aide un utilisateur occasionnel peut ralentir un expert.

Chaque transaction SAP GUI doit-elle être remplacée par une application Fiori ?

Non. Chaque transaction doit être évaluée en fonction du profil utilisateur, de la fréquence de la tâche, de la densité des données, de la couverture fonctionnelle, de la personnalisation, des performances et du besoin mobile. Certaines transactions se transposent clairement vers de meilleures applications Fiori ; d’autres n’ont pas d’équivalent adéquat ou servent des utilisateurs dont le travail est plus rapide dans GUI. Imposer un remplacement complet nuit généralement à la productivité et à l’adoption.

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

Oui. Les transactions classiques peuvent être exposées sous forme de tuiles Launchpad à l’aide de SAP GUI for HTML (WebGUI), afin que les utilisateurs disposent d’un point d’entrée unique même lorsque l’écran sous-jacent est une transaction classique. C’est une technique courante dans les stratégies hybrides, bien que les équipes doivent vérifier que la transaction concernée se comporte correctement dans WebGUI avant de s’y fier.

Comment les équipes doivent-elles choisir entre SAP GUI et SAP Fiori ?

Évaluez chaque tâche, et non la technologie : identifiez qui l’exécute et à quelle fréquence, si elle se fait sur poste de travail ou sur mobile, si l’application Fiori couvre tous les champs, actions et exceptions requis, si les personnalisations sont reprises, et si les performances restent acceptables avec des volumes de données et des conditions réseau réels. Documentez la décision pour chaque processus et réexaminez-la à mesure que la couverture Fiori s’améliore.

Une stratégie hybride SAP GUI et Fiori est-elle acceptable ?

Oui — pour la plupart des organisations, c’est l’approche recommandée, et non un compromis. Une approche hybride bien gérée utilise Fiori pour le libre-service, les validations, le mobile et l’analytique, conserve SAP GUI pour le travail expert, dense, technique ou personnalisé, et documente clairement quelle interface s’applique à chaque processus. Le mix évolue ensuite à mesure que les applications gagnent en maturité.

Que faut-il documenter avant de faire passer les utilisateurs de SAP GUI à Fiori ?

Les équipes doivent maintenir un catalogue qui associe chaque processus métier à sa transaction GUI et à son application Fiori, en incluant le type d’application, les utilisateurs cibles, les écarts fonctionnels connus, la préparation à l’usage mobile, les notes de performance, le matériel de formation, un responsable et la décision de migration (conserver GUI, passer à Fiori, utiliser les deux ou reconcevoir). Cette cartographie évite la surcharge du support et rend la transition mesurable.