Fiori Elements remplace-t-il les développeurs UI5 ?

Un développeur SAPUI5 ouvre SAP Business Application Studio, génère un List Report à partir d’une vue CDS, ajoute une douzaine d’annotations d’interface utilisateur et dispose, avant le déjeuner, d’une application fonctionnelle, compatible avec les brouillons et filtrable. Aucune vue XML n’a été écrite. Aucun contrôleur. Aucun formateur. Il est difficile de voir cela se produire sans se poser la question évidente : si le framework construit l’écran à partir des métadonnées, pourquoi quelqu’un aurait-il encore besoin de moi ?

La question se pose avec encore plus d’insistance aujourd’hui, car Fiori Elements n’est plus isolé. RAP génère le comportement et la couche de service côté ABAP. CAP fait de même sur SAP BTP. Les annotations CDS décrivent l’interface utilisateur de manière déclarative. Les propres applications S/4HANA de SAP reposent très largement sur Fiori Elements, et chaque diapositive de feuille de route va dans le même sens : des métadonnées en entrée, une application en sortie. Pour les développeurs qui ont construit leur carrière en écrivant des vues et des contrôleurs à la main — et pour les développeurs ABAP qui viennent tout juste de se reconvertir à Fiori — cela donne l’impression que le sol se dérobe.

Il bouge, certes, mais pas dans la direction d’une « absence de développeurs ». La version courte de cet article : Fiori Elements élimine un type précis de travail — le codage manuel d’écrans standardisés — et exige en contrepartie un autre type de travail : modéliser des services, rédiger des annotations, étendre des modèles, déboguer des applications générées et, surtout, juger quelle approche convient à quelle exigence. Cette dernière compétence ne peut pas être générée à partir de métadonnées. Examinons cela section par section.

Qu’est-ce que Fiori Elements ?

Fiori Elements est le framework d’application piloté par les métadonnées de SAP, construit sur SAPUI5. Au lieu d’écrire l’interface utilisateur, vous décrivez les données et leur présentation prévue, et le framework génère l’application à l’exécution à partir de cette description.

Le fonctionnement repose sur trois piliers :

Plans de page. Fiori Elements propose un petit catalogue volontairement limité de modèles de pages : le List Report (barre de filtres plus tableau), l’Object Page (vue détaillée avec en-tête et sections), l’Analytical List Page (graphique plus tableau avec exploration), l’Overview Page (page d’accueil basée sur des cartes) et la Worklist. Vous choisissez un plan de page ; vous ne concevez pas une mise en page.

Annotations. Les annotations sont les instructions qui alimentent le plan de page. @UI.lineItem place un champ dans le tableau. @UI.selectionField le fait apparaître dans la barre de filtres. @UI.headerInfo nomme l’objet sur sa page détaillée. @UI.facet organise l’Object Page en sections. Sur S/4HANA, elles se trouvent généralement directement dans les vues CDS ; ailleurs, elles peuvent résider dans un fichier d’annotations local du projet. La rédaction, la structuration et le débogage des annotations constituent l’activité principale de création dans un projet Fiori Elements.

Services OData. L’application consomme un service OData — historiquement V2, V4 pour tout ce qui est nouveau — qui fournit les entités, les associations, les capacités de brouillon et les actions. Le service définit ce qui est possible ; les annotations définissent ce qui est affiché.

Comme le comportement provient du modèle et le contenu des métadonnées, un schéma standardisé tel qu’une « liste consultable qui s’ouvre sur une page de détail modifiable » ne nécessite pratiquement aucun code d’interface utilisateur écrit à la main. Et comme chaque plan de page applique les directives de conception SAP Fiori, le résultat est automatiquement cohérent avec le reste du paysage SAP — même barre de filtres, même comportement de tableau, même flux de modification que l’utilisateur connaît déjà grâce aux autres applications.

Pourquoi Fiori Elements existe

Pour comprendre le framework, il faut examiner le problème auquel SAP était confronté avant son existence. S/4HANA est livré avec des milliers d’applications, et, sur le plan structurel, la plupart d’entre elles sont presque des clones : afficher une liste filtrée d’objets métier, en ouvrir un, modifier quelques champs, enregistrer. Lorsque chacune de ces applications est développée à la main — par différentes équipes, sur plusieurs années — on obtient des milliers d’implémentations qui divergent subtilement. La barre de filtres d’une application se comporte différemment de celle de la suivante. L’une gère les brouillons, une autre non. Chaque bug est corrigé à un endroit tout en restant présent dans cinquante autres.

Fiori Elements est la réponse industrielle à ce problème, et ses motivations sont pragmatiques plutôt que visionnaires :

• Cohérence à grande échelle. Un modèle, des milliers d’applications. Les utilisateurs transfèrent instantanément leurs connaissances d’une application à l’autre ; l’accessibilité et la réactivité sont résolues une fois pour toutes, de manière centralisée.
• Rapidité sur les modèles courants. Lorsque le modèle CDS existe, une application fonctionnelle ne nécessite qu’une exécution de générateur et un après-midi d’annotations — une fraction de l’effort requis pour un développement freestyle équivalent.
• Maintenance moins coûteuse. La logique d’interface utilisateur réside dans le modèle de SAP, pas dans votre référentiel. Lorsque SAP livre un composant de tableau amélioré ou corrige un bug de navigation au clavier, chaque application Fiori Elements en hérite lors de la mise à niveau, sans modification de code de la part de votre équipe.
• Élimination du code répétitif. Barres de filtres, gestion des variantes, gestion des brouillons, fenêtres contextuelles de messages, mise en page à colonnes flexibles — toute la plomberie qui consommait des sprints dans les projets freestyle est fournie préassemblée.

Remarquez ce qui ne figure pas dans cette liste : remplacer les développeurs. L’objectif était d’arrêter de payer des personnes qualifiées pour réimplémenter la même page de liste pour la quarantième fois — un objectif que la plupart des développeurs partagent, honnêtement.

Là où Fiori Elements fonctionne bien

Le framework tient sa promesse lorsque l’exigence correspond à un modèle d’écran et que la standardisation est une fonctionnalité, non une contrainte. Concrètement :

• List Reports sur des entités métier. « Montrez-moi toutes les demandes d’achat ouvertes, filtrables par division et demandeur, avec navigation vers le détail. » C’est le cas canonique, et Fiori Elements le gère mieux et plus rapidement que presque toute alternative développée sur mesure.
• Object Pages avec des flux de modification standards. En-tête, sections, groupes de champs, modification/enregistrement avec prise en charge des brouillons et messages de validation — tout se fait par configuration, sans code.
• Applications CRUD simples. Maintenance des données de base (centres de coûts, catégories d’équipement, fiches fournisseurs) où RAP ou CAP fournit le comportement et où l’interface utilisateur constitue une couche fine et standard par-dessus.
• Analytical List Pages — lorsque l’analyse correspond au modèle. Si l’exigence est « graphique du volume de commandes par catégorie, avec exploration des commandes sous-jacentes », l’ALP le fait élégamment. La nuance est importante : cela fonctionne lorsque les parties prenantes acceptent les types de graphiques et les modèles d’interaction standards.
• Scénarios de déploiement à grande échelle. Un programme livrant quarante applications internes tire énormément parti du fait que trente-cinq d’entre elles soient basées sur des modèles : effort prévisible, expérience utilisateur uniforme et surface de maintenance qui ne croît pas avec chaque application.
• Applications où la cohérence prime sur la singularité. Des outils utilisés quotidiennement par des utilisateurs back-office formés, qui tiennent à ce que la barre de filtres fonctionne exactement comme toutes les autres barres de filtres — et non à ce que l’application ait une personnalité.

Un test pratique : si vous pouvez spécifier l’application en une phrase du type « une liste de ⟨entité⟩ filtrée par ⟨critères⟩, ouvrant sur une page de détail modifiable », choisir une UI5 freestyle pour cela serait de la sur-ingénierie.

Là où Fiori Elements ne remplace pas UI5 freestyle

Toutes les forces ci-dessus proviennent de la même source — un ensemble fixe de modèles — et cette source constitue également la limite absolue. En dehors des hypothèses des modèles, UI5 freestyle n’est pas une solution de repli héritée ; c’est le bon outil.

• Parcours utilisateur personnalisés. Un assistant de configuration guidé en plusieurs étapes, un flux d’intégration, une séquence d’écrans pilotée par les décisions de l’utilisateur — les floorplans modélisent des listes et des détails, pas des parcours.
• Logique d’écran complexe et interdépendante. Des champs qui remodèlent le formulaire lorsqu’ils changent, des sections qui apparaissent conditionnellement selon des combinaisons de valeurs, des recalculs en direct sur toute la page. Les annotations peuvent exprimer certains contrôles de champs, mais au-delà d’un seuil modeste, la logique ne tient plus dans un modèle déclaratif.
• Interactions non standard. Tableaux de planification par glisser-déposer, édition en ligne sur canevas, comparaisons en écran partagé, mises à jour collaboratives en temps réel.
• Tableaux de bord avancés. Un écran de salle de contrôle combinant une carte en direct, un diagramme de Gantt, des tuiles KPI et un flux d’alertes personnalisé n’est pas une Overview Page, et prétendre le contraire produit lentement un tableau de bord moins bon.
• Bibliothèques tierces et visualisations personnalisées. Intégrer D3, un SDK de cartographie spécialisé ou un rendu SVG personnalisé de l’agencement d’un entrepôt signifie prendre en charge la couche de vue — ce qui est précisément ce que Fiori Elements retire.
• Front-ends fortement axés sur l’intégration. Orchestrer plusieurs services, combiner OData avec des sources REST ou WebSocket, ou gérer un état côté client complexe sort du cadre de la vision mono-service du framework.
• Exigences qui ne correspondent à aucun floorplan. Parfois, la réponse honnête à « quel modèle ? » est « aucun ». Forcer la correspondance la plus proche crée une application qui va à l’encontre de ses utilisateurs.

Et il existe un piège précis qui mérite d’être nommé, car les équipes expérimentées y tombent régulièrement : la mort par extension. Un projet démarre comme une application Fiori Elements propre. Les exigences augmentent. Une colonne personnalisée ici, une extension de contrôleur là, puis une section personnalisée, puis une sortie qui réimplémente la moitié de la page. Dix-huit mois plus tard, l’application est composée à 70 % de contournements, plus difficile à maintenir qu’elle ne l’aurait été en freestyle, et dépendante d’éléments internes des modèles susceptibles de changer lors d’une mise à niveau. Reconnaître — tôt — qu’une trajectoire d’exigences se dirige au-delà des limites du modèle est l’un des jugements les plus précieux qu’un développeur senior puisse porter.

Ce que les développeurs UI5 font encore

Retirez les écrans que Fiori Elements génère désormais, et la fiche de poste restante demeure longue — et sans doute plus intéressante :

• Créer des applications UI5 freestyle pour tout ce qui a été mentionné dans la section précédente.
• Étendre les applications Fiori Elements : colonnes et actions personnalisées, extensions de contrôleur, sections personnalisées de page objet — des ajouts chirurgicaux qui conservent les avantages du modèle tout en comblant les lacunes.
• Développer des cartes d’intégration UI5 pour SAP Build Work Zone et les pages d’aperçu.
• Façonner les expériences Work Zone — espaces, pages et composition d’applications en un ensemble cohérent pour un rôle.
• Déboguer les applications générées. Lorsqu’une colonne ne s’affiche pas sans signaler d’erreur, quelqu’un doit déterminer si la cause est une annotation mal formée, une fonctionnalité OData manquante, un cache de métadonnées ou une particularité du modèle. C’est réellement plus difficile que de déboguer du code que vous avez écrit vous-même, car le code que vous lisez est du code que vous n’avez pas écrit.
• Analyser les performances — regroupement des requêtes, rigueur sur $select/$expand, chargement paresseux, réponses surdimensionnées. Les applications pilotées par les métadonnées produisent des requêtes lentes avec autant d’enthousiasme que celles codées à la main.
• Dépanner OData et les services, là où la majorité des « bugs d’interface » prennent en réalité leur origine.
• Maintenir la base installée. Des années d’applications freestyle fonctionnent aujourd’hui en production et ne seront pas réécrites simplement parce qu’un modèle existe.
• Concevoir une UX personnalisée dans le langage de conception Fiori — sur mesure sans être étrangère.
• Intégrer avec RAP, CAP, BTP et des API externes, en reliant le front-end au bon back-end de la bonne manière.
• Choisir l’approche. Modèle, modèle avec extensions ou freestyle — application par application, avec les conséquences associées en matière de coût, d’UX et de maintenance. Aucun générateur ne prend cette décision.

Le fil conducteur : le framework a absorbé la saisie. Il n’a pas absorbé l’ingénierie.

Fiori Elements vs Freestyle UI5 : comparaison pratique

Lisez le tableau comme une règle d’orientation, et non comme un classement. Le mode d’échec ne consiste pas à choisir la « mauvaise » technologie en général — il consiste à appliquer l’outil d’une colonne au problème de l’autre colonne.

Fiori Elements signifie-t-il moins de travail front-end ?

La réponse honnête comporte deux volets, et les deux sont vrais simultanément.

Dans les scénarios standardisés : oui, de façon spectaculaire. Le List Report classique qui consommait autrefois un sprint freestyle de deux semaines — barre de filtres, tableau responsive, gestion des variantes, navigation, gestion des brouillons — représente désormais une journée de modélisation et d’annotation. Multipliées sur un déploiement de quarante applications, les économies sont réelles et importantes. Quiconque prétend le contraire défend un modèle de facturation, il ne décrit pas la réalité.

Dans les applications métier complexes : non — le travail se déplace. Les heures ne sont plus consacrées aux vues XML et aux contrôleurs, mais plutôt à :

• définir correctement le modèle CDS et ses associations, car l’interface utilisateur n’est jamais meilleure que les métadonnées qui la sous-tendent ;
• rédiger et déboguer les annotations, ce qui est de la programmation sous un autre nom — avec ses propres types d’erreurs et sa propre courbe d’expertise ;
• concevoir les capacités du service OData : brouillons, actions, effets de bord, aides à la saisie des valeurs ;
• créer des extensions précisément là où le modèle s’arrête ;
• et prendre la décision architecturale pour chaque application du portefeuille.

L’effet net est un déplacement du levier, et non un rétrécissement du domaine. Auparavant, la production d’un développeur se mesurait au nombre d’écrans créés. Désormais, une petite quantité de métadonnées bien placées produit une application entière — ce qui signifie que le développeur qui comprend toute la chaîne (modèle → service → annotation → modèle → extension) produit bien plus qu’avant, tandis que celui qui savait seulement assembler des contrôles voit sa tâche spécifique automatisée. La demande n’a pas disparu. Elle est remontée dans la pile.

Comment les développeurs UI5 doivent s’adapter

Le profil que le marché récompense est celui du développeur qui intervient sur l’ensemble de la stack et oriente chaque exigence vers le bon outil. Une liste d’investissements réaliste, à peu près par ordre d’urgence :

1. Fiori Elements lui-même — le catalogue de floorplans, le vocabulaire des annotations et, surtout, les points d’extension et leurs limites. Savoir où le modèle s’arrête est aussi important que savoir ce qu’il fait.
2. OData V4 (tout en conservant une bonne maîtrise de V2) — brouillons, actions, effets secondaires et modèle de capacités dont dépendent les modèles Fiori Elements V4.
3. Annotations CDS — dans un monde piloté par les métadonnées, c’est le langage que vous écrivez le plus.
4. Fondamentaux de RAP — définitions de comportement, gestion des brouillons et manière dont la stack ABAP alimente le modèle.
5. Fondamentaux de CAP — la même logique sur BTP, pour les développements greenfield et les extensions côte à côte.
6. SAPUI5 freestyle, maintenu à niveau — c’est l’issue de secours pour tous les cas difficiles, et TypeScript devient de plus en plus le dialecte attendu.
7. Notions de base de SAP BTP — déploiement, destinations, services launchpad/Work Zone, là où les applications cloud vivent réellement.
8. UI5 Web Components — le modèle de composants qui survit à toute génération de framework particulière.
9. Maîtrise des tests et du débogage — wdi5/OPA5, ainsi que la compétence spécifique consistant à diagnostiquer les applications générées à l’aide des outils du navigateur et du traçage des annotations.
10. Culture UX et des processus métier — parce que « cela doit-il être standard ou personnalisé ? » est une question métier déguisée en question technique, et y répondre correctement exige de comprendre ce que l’utilisateur essaie réellement d’accomplir.

Acquérir de la profondeur dans ces dix domaines est un projet sur plusieurs années ; c’est normal. Le mouvement immédiat est plus ciblé : être à l’aise avec Fiori Elements, rester compétent en freestyle et être capable de lire une vue CDS sans hésiter. À elle seule, cette combinaison place un développeur devant à la fois le simple utilisateur de modèles et le partisan exclusif du freestyle.

Réponse finale : Fiori Elements remplace-t-il les développeurs UI5 ?

Non — et la question elle-même repose sur une fausse hypothèse : que la valeur d’un développeur UI5 ait jamais résidé dans le fait de taper du code.

Fiori Elements remplace une tâche : coder manuellement des écrans standardisés qui étaient reconstruits, avec de légères différences, des centaines de fois dans tout l’écosystème SAP. Cette tâche méritait d’être automatisée, et les développeurs bénéficient de son automatisation de la même manière qu’ils ont bénéficié du fait de ne plus écrire d’appels XHR bruts après l’arrivée du data binding.

Ce qui reste — et prend de l’importance —, c’est tout ce que le modèle ne peut pas décider : si une exigence correspond à un floorplan, comment modéliser le service pour que les annotations restent propres, où étendre et où renoncer, pourquoi la table générée est lente, comment le front-end communique avec RAP, CAP et le reste de BTP, et ce dont l’utilisateur a réellement besoin que l’écran fasse. Les développeurs réellement sous pression sont ceux dont l’ensemble de compétences se limitait exactement à la tâche automatisée. Les développeurs recherchés sont ceux qui peuvent regarder un backlog de vingt applications et dire correctement : ces quatorze relèvent de Fiori Elements, ces trois nécessitent des extensions, et ces trois doivent être freestyle — puis construire les vingt.

Fiori Elements n’a pas remplacé les développeurs UI5. Il a remplacé la partie la moins intéressante de leur travail et a augmenté la valeur du reste.

FAQ

Fiori Elements remplace-t-il SAPUI5 ?

Non. Fiori Elements est construit sur SAPUI5 : ses floorplans sont des applications SAPUI5 générées à partir de métadonnées. Il réduit le code UI5 écrit manuellement pour les modèles standard, mais SAPUI5 reste le framework sous-jacent et l’outil requis dès que les exigences dépassent les modèles.

Le UI5 freestyle est-il toujours pertinent ?

Oui. Le UI5 freestyle est le bon choix pour les parcours utilisateur personnalisés, la logique d’écran complexe, les bibliothèques tierces, les visualisations personnalisées et toute application qui ne correspond à aucun floorplan — de plus, il alimente le vaste parc installé d’applications existantes qui fonctionneront en production pendant des années.

Fiori Elements est-il réservé aux applications simples ?

Non — il est destiné aux applications standardisées, qui peuvent être vastes et critiques pour l’activité. La limite n’est pas la taille ni l’importance, mais la forme : l’application doit correspondre à un floorplan pris en charge. Les applications très interactives, non conventionnelles ou fortement axées sur l’intégration sortent de cette forme, quelle que soit leur simplicité.

Les développeurs UI5 devraient-ils apprendre RAP ou CAP ?

Oui, au moins jusqu’à un niveau de connaissance pratique. Les applications Fiori Elements sont alimentées par RAP (sur S/4HANA/ABAP) ou CAP (sur SAP BTP), et les annotations qui définissent l’interface utilisateur résident de plus en plus dans ces modèles. Un développeur UI5 qui ne sait pas lire le modèle backend ne peut plus déboguer entièrement son propre front-end.

Quelle est la principale différence entre Fiori Elements et le UI5 freestyle ?

Fiori Elements est déclaratif : vous décrivez l’application au moyen de métadonnées et d’annotations OData, et un modèle standard l’affiche. Le UI5 freestyle est impératif : vous construisez vous-même les vues et les contrôleurs avec un contrôle total. Le compromis se fait entre la vitesse de développement et la cohérence garantie, d’un côté, et la flexibilité et la liberté UX, de l’autre.

Fiori Elements peut-il gérer des exigences personnalisées ?

Partiellement, grâce à des points d’extension définis : colonnes personnalisées, actions personnalisées, extensions de contrôleur, sections personnalisées. Une personnalisation légère fonctionne bien. Une personnalisation importante s’accumule en une prolifération d’extensions plus difficile à maintenir que du code freestyle, moment auquel changer d’approche devient la décision d’ingénierie la plus judicieuse.

UI5 reste-t-il une bonne compétence pour les développeurs SAP ?

Oui — sans doute plus stratégique qu’auparavant. UI5 sous-tend Fiori Elements lui-même, chaque extension est du code UI5, et le freestyle reste obligatoire pour les cas difficiles. Le profil le plus solide sur le marché combine les fondamentaux UI5 avec une bonne maîtrise de Fiori Elements, une connaissance approfondie d’OData et une sensibilisation à RAP/CAP.