Que sont les applications SAP Fiori ? Types, exemples et cas d’utilisation

Les applications SAP Fiori sont des applications basées sur les rôles qui offrent aux utilisateurs SAP une façon plus moderne d’accomplir des tâches, d’analyser des données et de travailler avec des informations métier.

Dans les environnements réels, toutefois, le terme « application Fiori » prête souvent à confusion. Un utilisateur clique sur une vignette dans le Fiori Launchpad et accède parfois à une application Fiori native, parfois à une ancienne transaction SAP GUI exécutée via Web GUI. Certaines applications gèrent des transactions, d’autres prennent en charge l’analytique, et d’autres permettent d’explorer des objets métier tels que les clients, les fournisseurs, les articles, les commandes d’achat ou les factures.

Comprendre les applications Fiori demande donc plus que de mémoriser des catégories. Vous devez savoir à quoi sert chaque type, dans quels cas il est performant, et à quel moment il ne couvre pas pleinement un véritable processus métier.

Une application peut très bien prendre en charge une tâche unique tout en laissant la majeure partie du processus non couverte : les approbations, les exceptions, les transferts de responsabilité, les échéances, les données manquantes, les intégrations et la répartition des responsabilités entre les rôles.

Cet article présente les principaux types d’applications Fiori, des exemples courants, des cas d’utilisation pratiques, ainsi que la façon d’évaluer si une application standard est suffisamment adaptée à votre équipe.

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

Une application SAP Fiori suit les principes de conception Fiori de SAP et est normalement accessible via le Fiori Launchpad. Elle offre aux utilisateurs une manière orientée tâches de travailler avec les données SAP, les objets métier, les rapports, les approbations ou les demandes. Plutôt que de demander à quelqu’un de se souvenir d’un code de transaction et de se repérer dans un écran surchargé, une application Fiori est conçue autour d’un rôle ou d’un besoin spécifique.

Parmi les exemples courants, on trouve des applications qui créent une demande d’achat, approuvent un élément de workflow, examinent les factures ouvertes, surveillent les KPI d’approvisionnement, vérifient le statut des commandes clients, gèrent les demandes de congé ou affichent les informations sur les fournisseurs.

Cette orientation vers les tâches est ce qui distingue principalement Fiori de l’utilisation traditionnelle de SAP GUI. SAP GUI fournit aux utilisateurs experts des transactions denses, remplies d’options, de champs, de menus et de variantes. Fiori réduit le périmètre à une seule activité, ce qui aide en particulier les utilisateurs occasionnels, les managers, les travailleurs mobiles et les scénarios de libre-service.

Cette approche ciblée est réellement précieuse, mais elle signifie aussi qu’il faut toujours vérifier une application par rapport au travail réel qu’elle est censée prendre en charge. Une application Fiori peut sembler plus épurée qu’une ancienne transaction, mais ce qui compte, c’est de savoir si elle donne à l’utilisateur suffisamment d’informations, d’actions, de filtres et de contexte pour terminer correctement son travail.

Une tuile n’est pas toujours une application Fiori native

Une idée largement répandue est que chaque tuile du Launchpad ouvre une application Fiori native. Ce n’est pas le cas.

Une tuile n’est qu’un point d’entrée. Ce qui se charge lorsque vous cliquez dessus dépend entièrement de la configuration du Launchpad — il peut s’agir d’une application Fiori native, d’une application Fiori elements, d’une application SAPUI5 personnalisée, d’une page analytique, d’une transaction SAP GUI classique affichée via Web GUI, ou d’une autre application basée sur une URL.

Cette distinction est importante, car certains diront « nous utilisons Fiori » alors que la moitié de leurs tuiles lancent en réalité d’anciennes transactions dans un navigateur. Cela peut être une stratégie de transition tout à fait raisonnable — elle centralise l’accès dans le Launchpad sans imposer une refonte de chaque transaction en une seule fois — mais personne ne devrait la confondre avec une expérience entièrement native Fiori.

Pour l’adoption et la planification, il est utile d’être précis sur ce que chaque tuile ouvre réellement : une application Fiori native, une application SAPUI5 personnalisée, une application Fiori elements, ou une transaction classique exposée via Web GUI. Et au-delà de l’étiquette, demandez-vous si l’application améliore la tâche ou si elle ne fait que changer l’endroit où l’utilisateur clique pour la démarrer.

Un Launchpad rempli de tuiles n’offre pas automatiquement une expérience moderne. La valeur vient de ce que chaque tuile ouvre et de la façon dont cela correspond au rôle et au processus derrière la tâche.

Principaux types d’applications SAP Fiori

Vous pouvez regrouper les applications Fiori de plusieurs façons. Une répartition courante orientée métier distingue les applications transactionnelles, les applications analytiques et les fiches d’information. Dans les projets modernes, vous rencontrerez aussi des modèles comme les pages d’aperçu, les rapports de liste, les pages d’objet et les pages de liste analytique. Ces termes se recoupent, mais ils décrivent des choses légèrement différentes — certains désignent le but d’une application, d’autres le modèle d’interface utilisé pour la construire.

Concrètement :

• Les applications transactionnelles aident les utilisateurs à accomplir une tâche.
• Les applications analytiques les aident à comprendre la performance, les tendances et les exceptions.
• Les fiches d’information leur permettent d’explorer un objet métier.
• Les pages d’aperçu résument ce qui compte pour un rôle ou un domaine.
• Les rapports de liste aident les utilisateurs à trouver et à traiter de nombreux enregistrements.
• Les pages d’objet permettent aux utilisateurs de consulter ou de gérer un enregistrement précis.

Le reste de l’article examine chacun de ces éléments tour à tour.

Applications transactionnelles

Les applications transactionnelles sont l’endroit où les tâches métier sont réalisées dans SAP — créer, modifier, approuver, soumettre, lancer, rejeter ou comptabiliser des données métier. Elles sont généralement au plus près du travail opérationnel quotidien.

Exemples typiques : créer une demande d’achat, approuver une commande d’achat, comptabiliser une entrée de marchandises, gérer des demandes de congé, lancer un document de facturation ou traiter une demande de service.

Elles sont particulièrement efficaces lorsque la tâche est claire et propre à un rôle, et qu’elle n’oblige pas l’utilisateur à passer par une transaction tentaculaire remplie d’options sans rapport. Un responsable qui doit seulement approuver des demandes d’achat, par exemple, n’a pas besoin de toute la profondeur d’une transaction d’achat complète. Une application d’approbation ciblée peut afficher le demandeur, le montant, le fournisseur, le centre de coûts, la justification, les pièces jointes et l’action d’approbation — rien de plus.

C’est Fiori à son meilleur : un travail guidé, spécifique à une tâche, pour un rôle défini.

Mais cela mérite tout de même une analyse attentive. Une application simplifiée peut être idéale pour les utilisateurs occasionnels et les responsables, et inutile pour les utilisateurs avancés qui traitent de grands volumes et s’appuient sur des filtres avancés, des variantes, des modifications de masse et des tableaux denses. La vraie question n’est pas de savoir s’il existe une application transactionnelle — c’est de savoir si elle correspond à la façon dont l’équipe travaille réellement.

Applications analytiques

Les applications analytiques aident les utilisateurs à surveiller la performance, repérer les exceptions et déterminer ce qui nécessite de l’attention. Au lieu de faire avancer une seule transaction, elles organisent les données en KPI, graphiques, tableaux et synthèses visuelles. Les responsables, analystes, contrôleurs et chefs opérationnels qui ont besoin de visibilité sur l’ensemble d’un processus s’y appuient fortement.

Les exemples incluent le suivi des factures en retard, des dépenses d’approvisionnement, de la performance des fournisseurs, des niveaux de stock, de la performance commerciale, de la position de trésorerie ou du carnet de demandes de service.

Une bonne application analytique aide à répondre à des questions comme : quels éléments sont en retard, quel KPI est sorti de sa plage cible, quels fournisseurs, sites ou équipes nécessitent de l’attention, et quoi examiner en premier.

Les meilleures ne s’arrêtent pas à la visualisation — elles accompagnent l’utilisateur de l’analyse à l’action. Un responsable peut partir d’une carte KPI, repérer une zone problématique, ouvrir la liste des éléments concernés et accéder directement à l’objet ou à la tâche pertinente. C’est ce qui rend les applications analytiques si utiles pour la gestion par exception : vous évitez la revue manuelle de chaque transaction et vous vous concentrez sur les cas qui s’écartent de la norme.

Tout cela repose sur la qualité des données, la performance des services, la conception des autorisations et des KPI qui ont réellement du sens. Des graphiques attrayants ne sauveront pas des indicateurs qui ne reflètent pas le fonctionnement de l’entreprise.

Fiches d’information

Les fiches d’information permettent aux utilisateurs d’explorer un objet métier précis — un client, un fournisseur, un article, une commande d’achat, une commande client, une facture, un employé, un centre de coûts ou un actif. Plutôt que de se concentrer sur une transaction ou un KPI, une fiche d’information présente l’objet et tout ce qui lui est lié.

Une fiche d’information fournisseur peut afficher les détails du fournisseur ainsi que les commandes d’achat associées, les factures ouvertes, les contacts, les informations de paiement et des liens vers d’autres applications.

C’est important, car le travail en entreprise est rarement isolé. Une commande d’achat renvoie à un fournisseur, un article, un contrat, une facture, une livraison, une approbation et un centre de coûts. Une fiche d’information expose ces relations afin que les utilisateurs ne passent pas à l’aveugle d’écrans déconnectés les uns des autres. Elles sont particulièrement pratiques lorsqu’une personne a besoin de contexte avant d’agir — par exemple un approbateur ou un analyste qui doit comprendre l’historique d’un objet et les documents associés avant de décider de la suite.

Mais ne confondez pas une fiche d’information avec une visibilité complète sur le processus. Elle peut afficher des détails riches sur un objet tandis que le processus environnant — les règles, responsabilités, échéances, exceptions et transferts — reste hors champ.

Pages d’aperçu

Les pages d’aperçu fournissent un résumé, basé sur le rôle, des informations, priorités et actions. Au lieu d’ouvrir plusieurs applications et rapports distincts, l’utilisateur voit des cartes qui rassemblent ce qui compte pour son rôle : KPI, listes, graphiques, alertes, liens rapides, tâches en attente.

Un responsable des achats peut vouloir voir sur un seul écran les approbations en attente, les problèmes fournisseurs, les demandes d’achat ouvertes, les expirations de contrats et les indicateurs de dépenses. Un responsable financier peut vouloir les factures en retard, les documents bloqués, les indicateurs de trésorerie et les files d’exceptions.

Son efficacité dépend de la conception des rôles. Affichez trop d’informations et cela devient du bruit ; affichez-en trop peu et les utilisateurs retournent vers d’autres rapports, des feuilles de calcul ou SAP GUI. Une bonne page d’aperçu répond à une question : que doit savoir cet utilisateur, ou sur quoi doit-il agir en premier ? Elle y parvient en étant construite autour de responsabilités réelles plutôt qu’autour des cartes disponibles par défaut.

Rapports de liste et pages d’objet

Les rapports de liste et les pages d’objet sont les modèles de base pour gérer les enregistrements métier.

Un rapport de liste permet aux utilisateurs de rechercher, filtrer, trier et examiner de nombreux enregistrements à la fois — utile lorsqu’ils doivent localiser le bon élément avant d’agir, qu’il s’agisse de demandes d’achat ouvertes, de factures bloquées, de commandes client, d’avis de maintenance ou d’enregistrements clients. Une page d’objet traite en profondeur un seul enregistrement, en regroupant ses sections, champs, informations associées, pièces jointes, notes, statut et actions disponibles au même endroit.

Les deux fonctionnent généralement ensemble : l’utilisateur part d’une liste, la réduit avec des filtres, choisit un élément, ouvre la page d’objet, examine les détails et agit s’il est autorisé. Ce rythme — trouver l’objet, le comprendre, agir dessus — explique pourquoi ce modèle est si courant.

Il convient bien lorsque l’objet métier est clairement défini et que le parcours utilisateur est assez prévisible. Il convient moins lorsque le travail nécessite un guidage important, une logique d’interaction inhabituelle, plusieurs rôles ou des transferts complexes entre services. Dans ces cas, l’application prend en charge l’objet sans prendre en charge le processus complet qui l’entoure.

Applications Fiori natives vs GUI HTML / Web GUI

Une application Fiori native est conçue selon les principes de Fiori — basée sur les rôles, centrée sur les tâches, responsive et parfaitement intégrée au Launchpad.

Le GUI HTML, généralement appelé Web GUI, est d’une autre nature. Il exécute des transactions SAP GUI classiques dans un navigateur. L’utilisateur peut accéder à la transaction depuis une vignette du Launchpad, mais l’expérience sous-jacente reste celle de l’ancien modèle de transaction GUI.

Cette différence influence à la fois les attentes des utilisateurs et la planification des projets. Une application Fiori native offre une expérience plus claire et plus guidée, adaptée aux utilisateurs occasionnels, aux managers, aux approbateurs et aux collaborateurs mobiles. Une transaction Web GUI conserve la profondeur, la densité et la familiarité sur lesquelles comptent les utilisateurs experts.

Les deux coexistent sans difficulté. Une entreprise peut utiliser Fiori natif pour les approbations, l’analytique, le libre-service et la mobilité, tout en continuant à exposer des transactions classiques pour le travail expert ou pour les domaines où il n’existe pas d’application Fiori satisfaisante.

Les problèmes commencent lorsque chaque vignette est appelée « application Fiori ». Les utilisateurs s’attendent à quelque chose de moderne et obtiennent à la place une ancienne transaction dans un navigateur. Un inventaire plus honnête — application Fiori native, application Fiori elements, application SAPUI5 personnalisée, application analytique, transaction classique via Web GUI, application externe ou basée sur une URL — facilite grandement la planification de la formation, du support, de l’adoption et des feuilles de route de modernisation.

Qu’est-ce que la bibliothèque de référence des applications SAP Fiori ?

La bibliothèque de référence des applications SAP Fiori est le catalogue officiel de SAP pour explorer les applications Fiori disponibles et le contenu Launchpad associé. Les équipes l’utilisent pour rechercher des applications, comprendre ce qu’elles font et consulter les détails techniques et de mise en œuvre. Dans la plupart des projets, c’est le premier endroit où l’on va lorsqu’une personne veut savoir s’il existe déjà une application standard pour un besoin donné.

Vous pouvez rechercher les applications disponibles, les rôles métier, les composants applicatifs, les produits et versions requis, les détails de mise en œuvre, les applications associées et les informations de configuration.

La bibliothèque est réellement utile, mais elle ne remplace pas une validation métier. Trouver une application dans cette bibliothèque ne signifie pas qu’elle convient à vos utilisateurs — cela signifie que l’application est une candidate qui mérite d’être évaluée. Avant d’adopter quoi que ce soit de standard, vous devez encore confirmer que cela prend en charge le processus requis, le rôle, les données, le volume, les champs personnalisés, les autorisations, les attentes en matière de performance et les scénarios d’exception.

La bibliothèque répond à la première question : existe-t-il une application standard ? Le métier doit encore répondre à la seconde : est-elle suffisamment adaptée à la façon dont notre équipe travaille réellement ?

Comment savoir si une application standard est suffisamment adaptée

Évaluez une application Fiori standard par rapport au travail réel, et non par rapport à son nom, sa description ou son apparence soignée.

Commencez par la tâche. « Achats » est trop large pour vouloir dire quoi que ce soit ; « approuver une demande d’achat » ou « examiner la performance d’un fournisseur » est suffisamment précis pour être évalué. N’oubliez pas qu’une application peut parfaitement couvrir une tâche tout en ignorant le processus qui l’entoure.

Demandez ensuite à qui elle est destinée. Un responsable, un demandeur, un analyste, un agent de services partagés, un collaborateur terrain et un utilisateur expert arrivent tous avec des attentes différentes. Certains veulent de l’accompagnement et de la simplicité ; d’autres veulent de la rapidité, des filtres avancés, des actions de masse, des variantes et une forte densité d’informations.

Comparez ensuite l’application au périmètre fonctionnel dont vous avez réellement besoin : champs obligatoires et personnalisés, pièces jointes, notes, approbations, documents associés, gestion des exceptions, règles d’autorisation, reporting et conformité locale. C’est là que l’adoption échoue discrètement. Une application peut paraître plus claire que l’ancienne transaction et être tout de même rejetée dès que les utilisateurs constatent l’absence d’une fonctionnalité essentielle.

Examinez aussi le processus, car une application n’est pas un processus métier. Le processus couvre qui lance le travail, quelles données sont nécessaires, qui le révise, ce qui se passe en cas de rejet, quels délais s’appliquent et comment les exceptions sont traitées.

Enfin, vérifiez les performances, la formation et la documentation. Une application lente, déroutante ou mal expliquée ne sera pas adoptée, quelle que soit la qualité de son apparence. Les utilisateurs doivent savoir non seulement quelle tuile ouvrir, mais aussi quand utiliser l’application, quelle étape du processus elle couvre et ce qui se passe après leur action.

Une application standard utile n’est pas celle qui apparaît simplement dans le catalogue. C’est celle qui correspond suffisamment bien au rôle, à la tâche, au processus, aux données et au contexte de travail pour résister à l’usage quotidien.

Réflexions finales

Les applications Fiori peuvent réellement améliorer la façon dont les utilisateurs accèdent aux tâches, aux informations, aux analyses et aux objets métier dans SAP — de manière plus ciblée, davantage fondée sur les rôles, et plus facile d’accès via le Launchpad. Mais tout dépend de l’adéquation.

Une application transactionnelle mérite sa place lorsqu’elle prend en charge la tâche avec suffisamment de profondeur. Une application analytique la mérite lorsqu’elle met en évidence de vrais problèmes de performance et des exceptions. Une fiche d’information la mérite lorsqu’elle fournit un contexte pertinent. Une page de synthèse la mérite lorsqu’elle reflète les priorités réelles d’un rôle. Les rapports sous forme de liste et les pages d’objet la méritent lorsque les utilisateurs peuvent trouver, comprendre et traiter les enregistrements sans friction.

La leçon à retenir : choisir des applications Fiori n’est pas un exercice technique de catalogue. Une bonne évaluation commence par le processus métier, le rôle, les données, les exceptions, les attentes en matière de performance et le contexte de travail. Les applications Fiori réussissent lorsque l’application, le rôle, la tâche et le processus sont alignés.

FAQ

Les applications SAP Fiori sont-elles identiques aux transactions SAP GUI ?

Non. Les applications SAP Fiori sont généralement conçues autour de rôles, de tâches et d’expériences utilisateur spécifiques, tandis que les transactions SAP GUI offrent souvent des écrans plus larges et plus denses pour les utilisateurs experts. Cependant, certaines transactions SAP GUI peuvent être accessibles depuis le SAP Fiori Launchpad via Web GUI, ce qui signifie qu’une tuile du Launchpad ne représente pas toujours une application Fiori native.

Une tuile SAP Fiori peut-elle ouvrir une transaction SAP GUI classique ?

Oui. Une tuile dans le SAP Fiori Launchpad peut ouvrir différents types de contenu, notamment des applications Fiori natives, des applications SAPUI5 personnalisées, des pages analytiques, des URL externes ou des transactions SAP GUI classiques affichées via Web GUI. C’est pourquoi les équipes doivent inventorier ce que chaque tuile ouvre réellement avant de tout qualifier d’application Fiori.

Quelle est la différence entre les applications SAP Fiori transactionnelles et analytiques ?

Les applications SAP Fiori transactionnelles aident les utilisateurs à accomplir des tâches métier, comme créer, approuver, comptabiliser ou modifier des enregistrements. Les applications analytiques aident les utilisateurs à surveiller les performances, examiner les KPI, identifier les exceptions et comprendre les tendances. En termes simples, les applications transactionnelles soutiennent l’action, tandis que les applications analytiques soutiennent la visibilité et la prise de décision.

Les applications SAP Fiori standard suffisent-elles pour chaque processus métier ?

Pas toujours. Une application SAP Fiori standard peut très bien prendre en charge une tâche spécifique, mais le processus plus large peut impliquer des approbations, des exceptions, des échéances, des champs personnalisés, des intégrations, des transferts de responsabilité et des règles métier locales. Les équipes doivent valider chaque application par rapport au processus réel avant de décider qu’elle est suffisante.

Pourquoi certains utilisateurs préfèrent-ils encore SAP GUI à SAP Fiori ?

Certains utilisateurs experts préfèrent SAP GUI, car il peut être plus rapide pour un travail dense, répétitif et à fort volume. Ils peuvent s’appuyer sur des codes de transaction, des mises en page, des variantes, des filtres avancés, des actions de masse et des tableaux compacts qu’ils connaissent bien. SAP Fiori peut être mieux adapté aux scénarios guidés, basés sur les rôles, mobiles, analytiques et en libre-service, mais il n’est pas automatiquement meilleur pour chaque utilisateur ou chaque tâche.

Comment savoir si une application SAP Fiori est utile pour mon équipe ?

Commencez par vérifier si l’application prend en charge la tâche, le rôle, les données et le processus spécifiques dont votre équipe a besoin. Validez ensuite la couverture fonctionnelle, les champs personnalisés, les autorisations, les performances, l’utilisabilité, les besoins de formation et les scénarios d’exception. Une application Fiori utile n’est pas seulement une application qui existe dans le catalogue ; elle doit correspondre à la manière dont les utilisateurs travaillent réellement.

À quoi sert la SAP Fiori Apps Reference Library ?

La SAP Fiori Apps Reference Library sert à rechercher et à évaluer les applications SAP Fiori disponibles ainsi que le contenu Launchpad associé. Elle aide les équipes à comprendre l’objectif de l’application, les rôles métier, les produits SAP requis, les détails de mise en œuvre et les informations techniques. C’est un point de départ pour l’évaluation, et non un substitut à la validation du processus métier.

Quelle est la différence entre une application SAP Fiori et un processus métier ?

Une application SAP Fiori prend en charge une tâche, un écran, un objet, un rapport ou une interaction utilisateur. Un processus métier inclut le flux complet du travail à travers les rôles, les décisions, les données, les approbations, les exceptions, les échéances, les systèmes et les responsabilités. Une application Fiori peut améliorer une partie d’un processus, mais elle ne définit ni ne gouverne automatiquement l’ensemble du processus.