Fiche concept

Visualisations SAC personnalisées — quatre options avant de construire un widget

À jour au 2026-08-02T22:00:00Z

Qu'est-ce que Visualisations SAC personnalisées — quatre options avant de construire un widget ?

« Le graphique standard de SAC ne fait pas ce qu'il nous faut » est une phrase qui mène à un widget personnalisé bien plus souvent qu'elle ne le devrait.

« Le graphique standard de SAC ne fait pas ce qu'il nous faut » est une phrase qui mène à un widget personnalisé bien plus souvent qu'elle ne le devrait. La visualisation personnalisée dans SAP Analytics Cloud n'est pas une option mais quatre, et elles diffèrent d'environ deux ordres de grandeur en coût et en maintenance. Descendre la liste dans l'ordre, c'est la différence entre une modification de deux jours et une dette de maintenance permanente.

Les quatre options, de la moins chère à la plus chère

1 — Le graphique que vous avez déjà, correctement configuré. Une part surprenante des demandes « SAC ne sait pas faire » se règle par un formatage conditionnel, une dimension calculée, une ligne de référence ou un type de graphique que personne n'a essayé. Coût : quelques heures. Maintenance : aucune. Ce n'est pas une option pour rire : elle résout plus de demandes que les trois autres réunies.

2 — La composition dans une Story ou une Analytic Application. Superposer des widgets standard, utiliser onglets et conteneurs, piloter la visibilité par script. Coût : quelques jours. Maintenance : faible, parce que tout ce que vous avez utilisé est supporté par SAP et survit aux montées de version.

3 — L'API de scripting SAC. Le scripting d'Analytic Application donne un contrôle programmatique sur les widgets standard — réagir aux événements, poser des filtres, changer ce qui est affiché. Toujours une surface supportée par SAP, toujours sûre en montée de version, et elle couvre la plupart des exigences « interactives » que l'on prend à tort pour des exigences visuelles.

4 — Un Custom Widget. Un bundle JavaScript autonome, empaqueté en Web Component, que SAC charge à l'exécution dans les Analytic Applications. C'est là que vivent réellement les diagrammes de Sankey, les projections cartographiques non standard, les bibliothèques tierces comme Highcharts ou AmCharts, les affichages animés et les formulaires de saisie spécialisés. Coût : deux à trois jours pour qu'un développeur typique livre le premier. Maintenance : chaque release de SAC peut le casser, et cette dette n'expire jamais.

Ce qu'est réellement un Custom Widget

Techniquement, un bundle JavaScript empaqueté en Web Component. Il expose des propriétés (configurables dans l'Application Designer comme tout widget standard), des événements (déclenchables vers le code de scripting) et des méthodes (appelables depuis celui-ci). Il reçoit ses données de SAC par un contrat défini — lié à un dataset ou à un modèle — et rend dans la zone de canevas qui lui est allouée. Authentification, récupération des données et cycle de vie sont gérés par SAC ; le widget ne possède que son rendu.

Il se développe hors de SAC, dans n'importe quel framework JavaScript moderne — JS natif, Lit, React via wrappers — s'empaquette en manifeste JSON plus bundle, et se téléverse dans le dépôt de Custom Widgets au niveau du tenant ; il devient alors disponible pour tous les concepteurs d'Analytic Applications.

Quand ça vaut réellement le coup

Un test : l'écart de visualisation est-il réel et récurrent sur de nombreuses Stories ? Un Sankey dont quinze tableaux de bord ont besoin est un widget. Un Sankey qu'un dirigeant a demandé une fois est une capture d'écran.

Le second test est la propriété. Un widget est un logiciel que votre organisation maintient désormais, dans un langage que l'équipe SAP n'écrit peut-être pas, avec un rythme de montée de version fixé par quelqu'un d'autre. Si personne n'en est nommé propriétaire, il cassera à la release suivant le changement de projet de celui qui l'a écrit.

Pièges

Attaquer par l'option 4. C'est la plus intéressante pour un développeur et la plus chère pour le client — une combinaison dont il faut se méfier dans son propre raisonnement.

Oublier que chaque release de SAC peut le casser. Budgétez des tests de non-régression par montée de version, ou acceptez que le widget tombe en production à un moment que personne n'a choisi.

Construire un widget par demande. Trois widgets quasi identiques valent moins qu'un widget configurable à trois jeux de propriétés, et cela se décide au premier.

Croire qu'un widget règle un problème de données. Le widget ne possède que son rendu — données, authentification et cycle de vie restent à SAC. Si le chiffre est faux, aucune couche de visualisation ne le corrigera.

Pourquoi c'est important

La quatrième option est la plus intéressante pour un développeur et la plus chère pour le client — une combinaison dont il faut se méfier dans son propre raisonnement, parce que la dette de maintenance n'expire jamais.

Sources

Ouvrir dans l'application →