Lorsque l’application Fiori standard couvre 80 % — et que les 20 % manquants freinent l’adoption
L’atelier fit-to-standard s’est bien passé. L’application standard de la Fiori Apps Reference Library a fait une excellente démonstration, l’analyste a coché la liste des exigences, et la diapositive de synthèse disait ce qu’elle dit toujours : 80 % de couverture, les écarts restants seront traités lors d’une vague ultérieure.
Six mois après le go-live, les approbateurs exportent la liste de travail vers Excel parce que le seul champ sur lequel ils prennent réellement leur décision ne figure pas sur l’object page. L’employé qui valide deux cents documents avant le déjeuner est discrètement revenu à la transaction GUI. L’exception du jeudi circule par e-mail.
Voici le paradoxe : les applications Fiori standard qui échouent le plus durement sont rarement celles qui, de toute évidence, ne convenaient pas. Une inadéquation évidente est rejetée tôt et à peu de frais. Une application qui couvre 80 % est approuvée, fait l’objet d’une formation et est célébrée — puis échoue silencieusement, parce que les pourcentages de couverture masquent un fait que chaque tableur d’analyse fit-gap ignore : toutes les exigences n’ont pas le même poids.
Pourquoi « adopter le standard d’abord » reste le bon réflexe
Cette position mérite d’être défendue sous son meilleur jour, car elle est en grande partie correcte.
Le fit-to-standard est la leçon accumulée de deux décennies de paysages ERP enfouis sous les transactions Z : le système où une mise à niveau prend dix-huit mois parce que dix mille objets personnalisés doivent faire l’objet de tests de régression, et où le code personnalisé dicte désormais le fonctionnement du processus.
Le principe du clean core est la réponse sensée. Les applications Fiori standard apportent quelque chose qu’aucun développement personnalisé ne fournit pleinement : SAP les maintient, les teste à chaque version et les livre intégrées avec les objets métier et les autorisations. Lorsqu’une application standard convient réellement, l’adopter est la bonne décision d’ingénierie.
La critique qui suit vise deux autres aspects : la manière dont on détermine que cela « convient », et le coût sous-estimé de la couverture des écarts que cela laisse derrière soi.
Pourquoi « 80 % de couverture » est un chiffre dénué de sens
Une analyse fit-gap typique produit une liste : quarante exigences, trente-deux couvertes, huit écarts. Couverture : 80 %. Le chiffre paraît rigoureux. C’est de l’arithmétique appliquée à une erreur de catégorie.
Les exigences sont comptées comme des unités interchangeables. Elles ne le sont pas. « L’application affiche la devise du document » et « l’approbateur peut voir les litiges ouverts du fournisseur » comptent tous deux comme une ligne — mais l’un relève de l’ornement et l’autre est la raison d’être de l’étape d’approbation. Si les 20 % manquants incluent une étape que l’utilisateur ne peut pas ignorer, l’adoption s’effondre, quelle que soit la qualité du reste.
La question qui permet de prédire l’adoption est différente : chaque utilisateur peut-il accomplir son vrai travail quotidien, y compris les cas compliqués, sans quitter l’application ? C’est une question oui/non pour chaque rôle, et la transformer en pourcentage moyen est la manière dont les déploiements échouent poliment. La couverture est une chaîne, pas un tas : un seul maillon rompu, et l’utilisateur subit la rupture.
Une taxonomie des 20 % manquants
Le cinquième manquant se regroupe en cinq familles.
Données manquantes à l’écran. L’object page affiche les données d’en-tête que SAP a considérées comme universellement pertinentes — mais cet approbateur prend sa décision sur la référence du contrat et les dépenses par rapport à l’accord-cadre, et ni l’une ni l’autre n’apparaît. Il ouvre donc SAP GUI dans une seconde fenêtre, puis finit rapidement par ignorer complètement l’étape Fiori. Un seul champ manquant rend un écran complet à 95 % suffisant à 0 %.
Validations et contrôles de conformité manquants. Le cadre de contrôle exige une vérification à quatre yeux au-delà d’un certain seuil. L’application standard ne prévoit aucun emplacement pour cela, et une politique demandant aux utilisateurs de « se souvenir de » n’est pas quelque chose que les auditeurs acceptent.
Opérations de masse manquantes. L’employé qui traitait des lots dans une grille ALV — tout sélectionner, appliquer, F8 — se retrouve face à un list report conçu pour examiner les éléments un par un. Douze minutes deviennent une heure.
Parcours d’exception manquants. Le processus réel inclut rejeter avec un motif et renvoyer, demander une clarification, réaffecter parce que l’approbateur est en congé. Sans vocabulaire pour l’exception, l’exception passe par e-mail.
Intégration manquante avec l’étape adjacente. Le résultat doit arriver quelque part que l’application n’atteint pas — une pièce jointe dans un autre module, une notification que le rôle suivant ne reçoit jamais — si bien que l’utilisateur effectue une seconde tâche manuelle pour que la première compte.
Chacun de ces points semble mineur dans une ligne de fit-gap. Chacun est fatal sur le chemin critique.
Pourquoi l’écart survit au projet — et comment l’adoption s’effondre silencieusement
Si ces écarts sont si prévisibles, pourquoi arrivent-ils en production ? À cause de quatre mécanismes structurels.
Les démonstrations montrent les scénarios idéaux. L’atelier déroule le scénario standard avec des données propres. Personne ne fait la démonstration de l’exception du jeudi.
Les ateliers sollicitent les mauvais utilisateurs. Les participants sont des responsables fonctionnels et des consultants qui comprennent le processus, mais ne l’exécutent pas deux cents fois par jour. L’employé qui sait quel champ compte vraiment est représenté par procuration.
La couverture est validée par rapport à la documentation. Le processus documenté inclut rarement les validations informelles, les recherches annexes et la gestion des exceptions qui constituent le travail réel.
La « vague 2 » est une fiction dotée d’un code projet. Après le go-live, l’équipe se disperse, le budget se clôture et les utilisateurs ont déjà construit des contournements. Le contournement devient le processus.
Et l’effondrement est silencieux. Personne ne crée un ticket intitulé « Je refuse d’utiliser l’application ». La transaction dans l’interface graphique reste accessible, l’export Excel devient la véritable liste de travail, et les approbations sont prévalidées par e-mail puis simplement enregistrées dans l’application après coup — si bien que la piste d’audit documente une fiction. Les chiffres de lancement restent honorables, car les utilisateurs ouvrent encore l’application pour le clic final. C’est pourquoi les 20 % manquants sont plus dangereux que 100 % manquants : l’échec total est visible en atelier ; l’échec partiel reste invisible jusqu’à l’audit.
Le spectre de l’extensibilité : où chaque outil s’arrête
Rien de tout cela ne signifie que les écarts ne peuvent pas être comblés. SAP propose un véritable éventail d’options, et une évaluation honnête exige de savoir où chacune d’elles s’arrête.
Extensibilité par les key users — les applications Custom Fields et Custom Logic dans S/4HANA — permet à un expert métier formé d’ajouter des champs personnalisés à un contexte métier, de les exposer dans l’interface utilisateur standard et d’y associer une logique encadrée via des BAdI publiées. La limite est exactement celle que SAP a définie : les points d’extension publiés. Un centimètre au-delà de ce que SAP a exposé, l’outil s’arrête tout simplement — et l’ajustement bloquant nécessite un développeur que personne n’avait budgété.
L’adaptation de l’interface utilisateur — adaptation à l’exécution par les key users, ou projets d’adaptation dans SAP Business Application Studio pour des variantes stables lors des mises à niveau des applications SAPUI5 standard — corrige les problèmes d’agencement : le champ important enfoui trois sections plus bas. Elle déplace les meubles ; elle n’ajoute pas de pièces. Un contrôle de conformité manquant n’est pas un problème de mise en page.
L’extensibilité par les développeurs — extensions basées sur RAP, BAdI publiées, vues CDS personnalisées — met en œuvre une véritable logique, des validations et de nouvelles actions d’une manière compatible avec le clean core. L’extensibilité side-by-side sur SAP BTP va plus loin : une application distincte consommant S/4HANA via des API et des événements, libre de construire ce que l’application standard n’a jamais modélisé. Dans les deux cas, il s’agit sans ambiguïté de projets de développement : compétences RAP ou CAP rares, transports, régression lors des mises à niveau, et un responsable pour les dix prochaines années.
La question n’a jamais été de savoir si les 20 % peuvent être comblés. Elle est de savoir ce que cela coûte — et qui supporte ce coût une fois le projet terminé.
La courbe des coûts que personne ne trace
Le coût de la couverture n’est pas linéaire. Les premiers 80 % sont venus pratiquement gratuitement — SAP les a construits, les teste, les met à niveau. Les 20 % restants relèvent du sur-mesure, et il est tout à fait normal que combler « seulement » le cinquième manquant coûte plus cher que ce qu’aurait coûté le développement de la fonctionnalité couverte — parce que vous payez l’intégration dans l’application de quelqu’un d’autre, aux tarifs des services professionnels, avec des obligations de cycle de vie associées.
Et le coût se répète. Chaque mise à niveau de S/4HANA implique des tests de compatibilité des extensions. Les extensions sur des contextes publiés sont conçues pour survivre aux mises à niveau, et y parviennent généralement — mais « stable par contrat » signifie tout de même « à tester à chaque fois ».
Ce n’est pas un argument contre l’extension. C’est un argument pour chiffrer la décision honnêtement. Lorsque le véritable coût de cycle de vie est posé sur la table, des alternatives qui semblaient être un aveu d’échec commencent à ressembler à de l’ingénierie.
Deux alternatives honnêtes : conserver SAP GUI ou repenser le processus
La première alternative est la coexistence. Pour le rôle de traitement de masse, la question mature n’est pas « comment les faire passer à Fiori », mais « quel problème cela résoudrait-il, et pour qui ? » Si l’extension nécessaire pour rendre l’application rapide représente un développement important et que la transaction GUI est prise en charge et maîtrisée, conserver SAP GUI pour ce rôle constitue une allocation correcte des efforts. Fiori mérite sa place là où il est réellement meilleur — validations sur mobile, libre-service pour les utilisateurs occasionnels, pages de listes analytiques. La version honnête de la coexistence nomme la décision, la limite au rôle concerné et la réexamine ; la version malhonnête consiste à la découvrir lors d’un audit.
La seconde alternative consiste à repenser le processus. Parfois, les 20 % manquants ne sont pas une lacune de l’application, mais un vestige du processus : l’approbation parallèle née d’un incident en 2017. Avant de financer une extension pour coder une exception, demandez-vous si cette exception devrait exister. « Il suffit de simplifier » peut être aussi désinvolte que « il suffit d’étendre » — mais la refonte du processus doit figurer dans la même liste d’options que l’extension.
Un cadre de décision : pesez les écarts, ne les comptez pas
Tout d’abord, évaluez chaque écart selon trois axes :
- Gravité : bloquant (l’utilisateur ne peut pas réaliser correctement la tâche sans cet élément) ou simplement gênant.
- Fréquence : à quelle fréquence l’écart est rencontré, et par combien d’utilisateurs.
- Périmètre d’impact : qui est affecté — un rôle opérationnel central, un utilisateur occasionnel, un auditeur.
Un écart bloquant rencontré cinquante fois par jour pèse plus lourd que n’importe quel nombre d’écarts cosmétiques. Notez les écarts ; n’en faites pas la moyenne. Puis choisissez une voie pour chaque écart — pas une seule voie pour l’application :
- Accepter l’écart — éléments de faible gravité et de faible fréquence.
- Adapter l’interface utilisateur — problèmes d’agencement et d’adaptation à l’écran.
- Extension par key user — champs manquants et logique contrainte dans les points d’extension publiés.
- Extension développeur (RAP/BAdI) — vraie logique, validations et actions, chiffrées comme un projet de développement.
- Side-by-side sur BTP — écarts suffisamment importants pour constituer leur propre application.
- Conserver SAP GUI pour le rôle — flux de travail d’utilisateurs avancés que l’application sert moins bien.
- Repenser le processus — exceptions qui méritent d’être éliminées.
Quelle que soit la voie choisie, désignez le propriétaire de la maintenance. Une extension sans propriétaire est une dette technique avec une date de livraison.
Comment mener le Fit-Gap pour éviter que cela se produise
L’endroit le moins coûteux pour détecter les 20 % fatals est avant le go-live, et le format standard des ateliers est structurellement mauvais pour cela. Quatre ajustements changent la donne :
Validez avec les véritables opérateurs. Placez l’utilisateur qui traite le plus grand volume de la transaction actuelle devant l’application standard et demandez-lui d’effectuer son mardi réel avec des volumes proches de la production. Le champ qu’il vérifie silencieusement apparaîtra en dix minutes.
Testez explicitement les cas difficiles. Scénarisez le rejet avec reprise, la délégation, le pic de fin de mois. Une application validée uniquement sur le scénario idéal a été validée sur un processus qui n’existe pas.
Exécutez un test chronométré de type journée réelle. Un ralentissement de facteur 5 constaté ici est une donnée de conception ; constaté après le go-live, c’est déjà un contournement en cours.
Rédigez la liste des écarts en termes de sévérité. Remplacez « 80 % de couverture » par une phrase par rôle : « Le rôle X peut / ne peut pas accomplir son travail quotidien dans l’application ; les écarts bloquants sont A et B ; la voie choisie est Y, sous la responsabilité de Z. » Cette phrase résiste au contact avec la réalité.
Comparaison des options de comblement des écarts
| Dimension | Accepter l’écart | Adaptation de l’interface utilisateur | Extensibilité par key user | Extensibilité développeur (RAP/BAdI) | Side-by-side sur BTP | Conserver SAP GUI pour le rôle |
|---|---|---|---|---|---|---|
| Quels écarts sont comblés | Inconvénients de faible gravité | Mise en page, visibilité, adaptation à l’écran | Champs personnalisés, logique contrainte sur des contextes publiés | Logique réelle, validations, actions personnalisées | Capacités complètes : cockpits de masse, nouveaux flux | Écarts de rapidité/densité pour les utilisateurs experts |
| Qui effectue le travail | Personne (décision uniquement) | Key user / BAS pour les projets d’adaptation | Key user formé | Développeur ABAP/RAP | Développeur BTP (CAP/RAP), plus opérations | Personne (décision + cadrage du rôle) |
| Charge du cycle de vie | Aucune | Faible ; retester lors des mises à niveau | Faible à moyenne ; stable lors des mises à niveau, mais à tester | Moyenne à élevée ; transports, régression | Élevée ; application distincte à exploiter et à sécuriser | Faible ; transaction maintenue par SAP |
| Délai typique | Immédiat | Jours | Jours à semaines | Semaines à mois | Mois | Immédiat |
| Plafond | L’écart demeure | Aucune nouvelle logique, action ni étape | Points d’extension publiés uniquement | API publiées ; disponibilité des compétences | Profondeur d’intégration, coût, latence | Aucune modernisation de l’UX pour ce rôle |
| Mode de défaillance en cas de mauvaise application | Écart bloquant accepté → contournements silencieux | Écart de logique derrière un écran plus agréable | Plafond atteint tardivement → projet de développement surprise | « Un champ » devient un backlog permanent | Sur-ingénierie d’un écart qu’un seul BAdI permettrait de combler | Coexistence accidentelle, aucune gouvernance |
Questions fréquentes
Qu’est-ce que l’extensibilité key user dans SAP S/4HANA ?
Elle permet à des experts métier formés d’étendre les applications S/4HANA standard sans projet de développement — en ajoutant des champs personnalisés via l’application Custom Fields et une logique encadrée au moyen de BAdIs publiés dans l’application Custom Logic. Elle fonctionne strictement dans les points d’extension publiés par SAP.
Quelle est la différence entre l’extensibilité in-app et l’extensibilité side-by-side ?
L’extensibilité in-app s’exécute à l’intérieur de la pile S/4HANA (outils pour key users, RAP, BAdIs), en étendant directement les objets standard. Le side-by-side consiste à créer une application distincte sur SAP BTP qui consomme S/4HANA via des API et des événements publiés. L’in-app est moins coûteux pour de petits écarts ; le side-by-side convient à des capacités plus importantes, au prix d’une deuxième application à exploiter.
Pourquoi les utilisateurs reviennent-ils à SAP GUI après des déploiements Fiori ?
Parce qu’une partie spécifique et fréquente de leur travail est moins bien prise en charge dans l’application : un champ critique pour la décision absent de l’écran, des opérations de masse plus lentes que l’ancien workflow ALV, ou des parcours d’exception que l’application ne modélise pas. Comme les transactions GUI restent accessibles, les utilisateurs y reviennent discrètement.
Comment évaluer si une application Fiori standard convient à votre processus ?
Pondérez les écarts au lieu de les compter. Faites exécuter la charge de travail quotidienne réelle, exceptions incluses, par les véritables utilisateurs au plus fort volume, dans un bac à sable, puis classez chaque écart comme bloquant ou gênant. La question décisive est de savoir si chaque rôle peut accomplir un travail réel sans quitter l’application.
Les extensions Fiori résistent-elles aux montées de version S/4HANA ?
Les extensions construites sur des points d’extension publiés — extensions key user, projets d’adaptation, extensions développeur basées sur des API publiées — sont conçues pour être stables lors des montées de version, et elles le sont généralement. « Stable » signifie néanmoins « à tester en régression à chaque montée de version », et tout ce qui touche à des objets non publiés constitue un risque permanent.
Vaut-il mieux étendre une application Fiori standard ou en créer une personnalisée ?
Un ou deux écarts au niveau des champs, dans les limites des points d’extension publiés, plaident en faveur d’une extension. Un ensemble d’écarts bloquants autour de la logique, du traitement de masse ou des flux d’exception peut rendre une application conçue spécifiquement — via RAP ou en side-by-side sur BTP — moins coûteuse sur l’ensemble de son cycle de vie que l’empilement d’extensions sur un floorplan conçu pour un autre usage.
L’écart le plus coûteux est celui que vos utilisateurs trouvent
Les applications SAP Fiori standard méritent d’être envisagées en premier — cette partie de la sagesse conventionnelle reste intacte. Ce qui ne tient pas, en revanche, c’est la manière dont la couverture est mesurée. Un chiffre de 80 % obtenu en comptant les exigences ne répond à aucune question importante ; ce qui permet de prédire l’adoption, c’est de savoir si chaque rôle peut accomplir son vrai travail quotidien, cas difficiles inclus, sans quitter l’application.
Les équipes qui évaluent les écarts un par un, avant le go-live, et désignent un responsable pour chaque voie de résolution obtiennent ce que promet le fit-to-standard. Les équipes qui notent « 80 % — couvert par le standard » puis passent à autre chose obtiennent une application qui affiche une utilisation respectable, tandis que le travail réel se déplace discrètement vers Excel, les e-mails et la transaction qui n’a jamais disparu.
L’écart le moins coûteux est celui que vous comblez en atelier. Le plus coûteux est celui que vos utilisateurs découvrent après le go-live — car à ce moment-là, ils l’ont déjà résolu sans vous.
