Le malentendu de départ
Beaucoup d'équipes SAP abordent Fiori avec la même approche qu'une application web classique : elles pensent "JavaScript", "framework front-end", "composants custom". Résultat : elles choisissent le Freestyle UI5 par réflexe, construisent une application de toutes pièces, et se retrouvent six mois plus tard avec une interface difficile à maintenir, désynchronisée des évolutions SAP, et qui nécessite des développeurs front-end qu'elles n'ont pas en interne.
Fiori Elements est une approche radicalement différente : au lieu d'écrire une interface, vous déclarez ce que vous voulez afficher via des annotations dans vos CDS Views. C'est le framework SAP qui génère et rend l'interface. L'avantage est considérable en termes de productivité, de cohérence visuelle et de maintenance — à condition d'accepter les contraintes des floor plans disponibles.
Les cinq floor plans Fiori Elements
Fiori Elements ne produit pas "une interface générique". Il propose cinq floor plans (templates d'interface) couvrant les patterns d'interaction SAP les plus courants : List Report, Object Page, Worklist, Analytical List Page et Overview Page.
List Report
Le List Report affiche une liste filtrée d'entités (commandes, articles, factures) avec un Filter Bar avancé permettant des recherches multi-critères. Il offre des fonctionnalités puissantes pour trouver des éléments pertinents et agir dessus directement (sélection multiple, actions de masse, tri, regroupement). C'est le point d'entrée le plus utilisé pour les interfaces transactionnelles SAP.
Object Page
L'Object Page affiche le détail d'une entité, avec des sections, des onglets, des champs en lecture ou en édition, et des actions. C'est désormais le floor plan recommandé par SAP pour représenter aussi bien des objets simples que des objets complexes avec relations multiples. Combinée au List Report, elle forme le combo le plus utilisé : on liste, on filtre, puis on ouvre l'entité pour la consulter ou la modifier.
Worklist
Variante du List Report adaptée aux collections d'éléments à traiter par un utilisateur. Idéale pour les listes de travail pré-filtrées : commandes en attente de validation, alertes à traiter, tâches assignées. L'utilisateur n'a pas besoin de définir ses critères de recherche — la liste est directement opérationnelle, et l'objectif est de finaliser ou de déléguer chaque item.
Analytical List Page
Combine des visualisations analytiques (graphiques, KPIs) avec une liste détaillée. L'utilisateur peut extraire des informations via des graphiques, appliquer des filtres visuels basés sur les dimensions du graphique, puis descendre dans le détail des enregistrements. Pertinent pour les tableaux de bord opérationnels où l'utilisateur veut à la fois une vue d'ensemble et un accès au détail. Nécessite des annotations @Analytics et @UI.chart spécifiques dans les CDS Views.
Overview Page
Page d'accueil data-driven personnalisable, basée sur des "cards" (cartes d'information) qui présentent différents objets SAP utiles à un rôle métier. Permet à l'utilisateur de visualiser, filtrer et réagir aux informations rapidement, sur une page unique adaptée à son domaine. Utilisée pour les Fiori Launchpad enrichis et les home pages métier.
Comment Fiori Elements fonctionne avec RAP
La puissance de Fiori Elements éclate vraiment quand il est couplé avec RAP (RESTful Application Programming Model). Dans ce modèle :
La CDS View de projection porte les annotations @UI qui définissent quels champs apparaissent dans le List Report, quelles colonnes sont visibles par défaut, quels champs sont éditables dans l'Object Page, et quelles actions sont disponibles.
Le service OData V4 est exposé automatiquement par le framework RAP à partir de ces annotations, sans ligne de code Gateway supplémentaire.
Le Behavior Definition définit les actions disponibles (create, update, delete, actions custom) et leur rendu dans l'interface via les annotations @UI.lineItem et @UI.identification.
Le résultat : une interface Fiori Elements complète avec filtres, liste, page détail, actions et draft handling peut être produite sans toucher à une seule ligne de JavaScript. La totalité de la configuration se fait côté ABAP, dans les annotations CDS. C'est ce que nous avons mis en place sur le projet Kuhn Group, où toutes les nouvelles interfaces ont été construites via ce modèle — avec un gain de productivité estimé à 30 % par rapport aux développements Web Dynpro précédents.
Tableau comparatif
| Critère | Fiori Elements | Freestyle UI5 |
|---|---|---|
| Vitesse de développement | Très rapide (annotations CDS) | Lente (JavaScript complet) |
| Flexibilité visuelle | Limitée aux floor plans | Totale |
| Maintenance lors des upgrades SAP | Automatique (framework SAP) | Manuelle (compatibilité à vérifier) |
| Cohérence UX Fiori Design | Garantie par SAP | À implémenter manuellement |
| Compétences requises | ABAP, CDS, annotations @UI | JavaScript, XML views, OData, UI5 |
| Intégration RAP native | Oui (OData V4, draft, actions) | Partielle (OData V4 possible) |
| Adapté Public Cloud S/4HANA | Oui (modèle cible) | Limité |
| Cas d'usage typique | CRUD, listes, formulaires | Interfaces très spécifiques, mobile, dashboard sur mesure |
Quand Freestyle UI5 est vraiment justifié
Le Freestyle ne doit pas être un choix par défaut. C'est une décision consciente, motivée par un besoin réel que Fiori Elements ne peut pas couvrir. Voici les cas où il est légitime :
Interface de saisie très spécifique. Une interface de picking en entrepôt avec scan RF et logique de validation visuelle complexe ne rentre pas dans un Object Page standard. Le Freestyle permet de construire exactement l'interaction souhaitée avec des contrôles tactiles optimisés.
Dashboard analytique sur mesure. Si vous avez besoin d'un tableau de bord avec des graphiques interactifs, des filtres croisés et des visualisations qui ne correspondent pas aux cards de l'Analytical List Page, le Freestyle avec les contrôles de visualisation SAPUI5 (VizFrame, Chart, etc.) sera nécessaire.
Composant réutilisable pour Fiori Elements. Depuis SAPUI5 1.94, le Flexible Programming Model permet de créer des "custom building blocks" utilisables dans des applications Fiori Elements. C'est une zone grise productive : on garde les bénéfices de Fiori Elements (annotations, OData V4 natif) tout en ajoutant des composants custom spécifiques.
Application de type portail ou dashboard cross-systèmes. Si l'interface agrège des données de plusieurs systèmes hétérogènes (SAP + non-SAP), le Freestyle offre plus de souplesse pour les appels API multiples.
L'erreur la plus fréquente sur le terrain
Sur les projets que nous avons accompagnés, l'erreur la plus courante n'est pas de choisir Freestyle quand on aurait dû choisir Fiori Elements — c'est de choisir Freestyle parce que l'équipe ne maîtrise pas les annotations CDS. C'est un problème de compétences, pas un problème d'outil.
Les annotations @UI dans les CDS Views ont une courbe d'apprentissage réelle : il faut comprendre la hiérarchie @UI.lineItem, @UI.fieldGroup, @UI.facet, @UI.identification, et saisir comment elles se traduisent en rendu Fiori Elements. Mais une fois cette maîtrise acquise, la productivité est sans commune mesure avec le Freestyle.
C'est pour ça que nos missions d'accompagnement sur les projets Fiori incluent systématiquement un volet formation sur les annotations CDS. Sur le projet Thom Europe, nous avons formé l'équipe interne sur ce point précis — ce qui leur a permis de prendre en main la maintenance des interfaces sans dépendance externe.
Le Flexible Programming Model : le meilleur des deux mondes
Depuis SAPUI5 1.94 et SAP BAS (Business Application Studio), SAP a introduit le Flexible Programming Model : une approche hybride qui part d'une application Fiori Elements (avec ses annotations CDS et son OData V4) et permet d'y injecter des composants Freestyle ciblés via des "custom sections", "custom columns" ou "custom building blocks".
C'est la direction que SAP recommande pour les cas où Fiori Elements seul ne suffit pas mais où repartir de zéro en Freestyle serait disproportionné. L'application reste majoritairement gérée par le framework (maintenance automatique, cohérence UX), avec des zones d'extension précises pour les besoins spécifiques.
Questions fréquentes
Fiori Elements fonctionne-t-il sans RAP ?
Oui, il peut consommer n'importe quel service OData V2 ou V4. Mais RAP + Fiori Elements forment le couple recommandé par SAP : les annotations @UI sont nativement intégrées dans les CDS Views RAP, ce qui élimine tout code Gateway supplémentaire.
Peut-on personnaliser l'apparence d'une app Fiori Elements ?
Dans une certaine mesure via les annotations @UI. Pour des personnalisations plus poussées, le Flexible Programming Model permet d'ajouter des composants custom ciblés. Au-delà, il faut basculer en Freestyle.
Fiori Elements est-il adapté aux applications mobiles ?
Il génère des interfaces responsives adaptées aux mobiles dans le Fiori Launchpad. Pour des apps déconnectées ou avec des interactions tactiles très spécifiques (scan RF), SAP Mobile Development Kit (MDK) ou Freestyle sera plus adapté.
Quelle est la différence entre un List Report et un Worklist ?
Le List Report inclut un Filter Bar avancé pour les recherches multi-critères. Le Worklist affiche directement une liste pré-filtrée, adapté aux listes de tâches (commandes en attente, alertes). Le choix dépend du pattern métier : recherche ad hoc vs liste de travail.
Freestyle UI5 est-il plus difficile à maintenir ?
Oui, structurellement. Une app Freestyle est un projet JavaScript complet avec ses propres dépendances à maintenir lors des upgrades SAP UI5. Fiori Elements délègue le rendu au framework SAP — une mise à jour SAP améliore automatiquement toutes les apps Fiori Elements.
Vos équipes démarrent un projet Fiori et hésitent entre Fiori Elements et Freestyle ?
Discuter de votre architecture Fiori