Omni Apps : quand la BI sort du dashboard pour devenir une application métier
Pendant des années, la Business Intelligence a principalement produit des dashboards. Avec l’arrivée de l’IA générative, une nouvelle catégorie d’outils apparaît : des applications métier construites directement sur la couche sémantique de la BI.
Et cela change beaucoup plus de choses que leur interface.
Pendant longtemps, la promesse de la Business Intelligence pouvait se résumer assez simplement : connecter les données de l’entreprise, comprendre ce qui se passe et aider les équipes à prendre de meilleures décisions.
Dans la pratique, cette promesse a principalement pris la forme de dashboards.
Des dashboards financiers, commerciaux, marketing, opérationnels. Des tableaux, des graphiques, des KPI, des filtres et des pages organisées pour rendre la donnée accessible au plus grand nombre.
Et les dashboards remplissent très bien cette fonction.
Le problème apparaît lorsqu’on essaie de leur faire faire autre chose.
Le dashboard impose sa propre grammaire
Un outil de BI traditionnel fonctionne avec une sorte de grammaire prédéfinie : des graphiques, des tableaux, des filtres, des onglets, des drill-downs.
Cette grammaire est particulièrement efficace pour consulter, suivre ou explorer de la donnée.
Elle devient beaucoup plus contraignante lorsque le besoin métier implique de faire quelque chose avec cette donnée, par exemple :
Simuler plusieurs scénarios budgétaires.
Construire un outil de capacity planning.
Naviguer dans une hiérarchie complexe.
Créer un configurateur de prix.
Prioriser des comptes commerciaux.
Investiguer un incident de qualité de données.
Construire un workflow opérationnel.
Historiquement, lorsque nous rencontrions ce type de besoin, deux possibilités se présentaient :
La première consistait à essayer de faire rentrer le besoin dans un dashboard, quitte à multiplier les filtres, les pages ou les contournements.
La seconde consistait à construire une véritable application métier.
Et dans ce deuxième cas, le périmètre changeait immédiatement : il fallait un front-end, une API, un système d’authentification, gérer les permissions, connecter l’application au warehouse, reproduire certaines règles métier et assurer ensuite la maintenance de l’ensemble.
Le coût n’était évidemment plus le même.
L’IA fait fortement baisser le coût de fabrication d’une interface
L’arrivée des LLM change une partie de cette équation.
Les modèles actuels sont désormais capables de produire très rapidement du code front-end de bonne qualité à partir d’une description en langage naturel.
Construire une interface spécifique devient donc beaucoup moins coûteux.
On peut décrire un écran, demander un tableau particulier, ajouter un sélecteur, modifier une interaction et obtenir en quelques itérations quelque chose qui aurait auparavant demandé un travail significatif de développement.
C’est impressionnant.
Mais ce n’est pas, à nos yeux, le changement le plus important.
Car générer une application qui fonctionne aujourd’hui devient facile.
Construire une application qui donnera encore la bonne réponse dans un an est une autre histoire.
Le vrai problème : où vit la logique métier ?
Imaginons une application permettant de suivre le revenu récurrent d'une entreprise.
Au moment de sa création, l’IA peut parfaitement écrire une requête SQL calculant l’ARR.
Quelques mois plus tard, l’entreprise fait évoluer sa définition de l’ARR.
Le dashboard officiel est modifié.
Le modèle dbt est modifié.
La documentation est mise à jour.
Mais qu’en est-il de la petite application générée six mois auparavant ?
Si sa logique métier est directement embarquée dans son code, elle continuera tranquillement à afficher l’ancienne définition.
L’application fonctionne toujours. Elle est simplement devenue fausse.
Et c’est probablement l’un des risques les plus importants de la multiplication des applications générées par IA dans les entreprises.
L’approche intéressante d’Omni Apps
C’est précisément sur ce point que nous trouvons l’approche d’Omni particulièrement intéressante.
Avec Omni Apps, l’interface générée ne constitue pas une nouvelle couche indépendante de logique data.
Elle vient se placer au-dessus du modèle sémantique déjà utilisé dans Omni : les métriques, dimensions, relations entre les données et règles d’accès restent donc centralisées dans la couche sémantique.
L’interface change, mais le contrat avec la donnée reste le même.
C’est une différence essentielle.
Si une définition métier évolue dans le modèle, les applications qui l’utilisent continuent de s’appuyer sur cette définition.
Les permissions et les règles de sécurité existantes s’appliquent également aux utilisateurs des Apps.
Autrement dit, on gagne une grande liberté sur l’expérience utilisateur sans abandonner la gouvernance construite par l’équipe data.
C’est ce rapprochement entre liberté du développement applicatif et rigueur de la BI qui nous paraît particulièrement prometteur.
Un exemple : transformer un reporting marketing en simulateur
La démo réalisée par Joséphine chez Corail en donne un exemple assez simple.
Le point de départ ressemble à un dashboard marketing traditionnel.
L’utilisateur sélectionne un canal d’acquisition et observe l’évolution de son ROAS dans le temps.
Jusque-là, rien de très nouveau.
Mais l’interface propose ensuite de faire varier le budget marketing et de choisir différents horizons de projection.
À partir de ces hypothèses, l’application construit un scénario donnant notamment une estimation des dépenses futures, du revenu attribué et du nombre de nouveaux clients.
La nuance est importante car l’utilisateur ne regarde plus seulement ce qui s’est passé.
Il utilise la donnée existante pour tester une décision.
Le dashboard devient progressivement un outil de travail.
Le dashboard n’est pas mort
Chaque nouvelle génération d’outils de data s’accompagne inévitablement de l’annonce de la mort du dashboard.
Nous n’y croyons pas vraiment.
Pour suivre vingt KPI chaque lundi matin, il serait absurde de construire une application spécifique.
Pour monitorer les ventes, consulter un P&L ou suivre des objectifs trimestriels, un dashboard reste souvent l’interface la plus simple et la plus efficace.
En revanche, dès que l’utilisateur doit interagir avec la donnée de manière plus complexe, les limites du dashboard apparaissent rapidement.
C’est à cet endroit que nous voyons les Apps devenir particulièrement intéressantes.
La bonne question n'est donc pas « faut-il remplacer nos dashboards par des Apps ? ».
Elle devient : quelle est la meilleure interface pour permettre à cet utilisateur d’accomplir son travail avec la donnée ?
Et la réponse peut désormais être beaucoup plus riche qu’un ensemble de graphiques.
Cela change aussi la manière de mener un projet data
Cette évolution peut avoir une conséquence importante sur notre manière de construire des produits data.
Traditionnellement, une grande partie du travail consistait à traduire le besoin métier dans les possibilités offertes par l’outil.
« Quel graphique faut-il utiliser ? »
« Quels filtres devons-nous prévoir ? »
« Comment organiser les pages du dashboard ? »
Avec des interfaces beaucoup plus libres, nous pouvons partir d’une question différente :
« Quelle serait l’expérience idéale pour résoudre ce problème métier ? »
L’interface peut ensuite être prototypée beaucoup plus tôt dans le projet et confrontée directement aux utilisateurs.
La discussion se déplace alors vers les sujets qui comptent réellement : la qualité des données, les définitions métier, les règles de gestion, les permissions et le workflow.
Paradoxalement, plus l’IA facilite la construction du front-end, plus la qualité de la couche data qui se trouve en dessous devient importante.
Vers des équipes data qui construisent des produits, pas seulement des rapports
C’est probablement l’évolution que nous trouvons la plus intéressante chez Corail :
La frontière entre analytics engineer, data analyst et product builder devient progressivement plus poreuse.
Une équipe data équipée d’un warehouse propre, d’une modélisation solide et d’une bonne couche sémantique peut désormais aller beaucoup plus loin dans la construction d’outils destinés aux métiers.
Sans pour autant transformer chaque nouveau besoin en projet logiciel de plusieurs mois.
Nous voyons déjà beaucoup de cas potentiels : outils de simulation financière, planification des effectifs, optimisation marketing, analyse de marge, customer 360 interactif, investigation de qualité de données ou outils opérationnels très spécifiques à un métier.
Tous ne nécessitent pas une App.
Mais beaucoup ne méritent pas non plus le coût d’une application développée entièrement sur mesure.
C’est précisément l’espace qui commence aujourd’hui à devenir accessible.
L’interface devient moins chère. La donnée devient encore plus stratégique.
L’un des effets les plus intéressants de l’IA sur la data n’est donc peut-être pas la disparition des dashboards.
C’est la disparition progressive d’une contrainte : le coût de fabrication d’une interface adaptée au besoin métier.
Lorsque cette contrainte diminue, la valeur se déplace.
Vers la compréhension du métier.
Vers la modélisation.
Vers la gouvernance.
Vers la qualité de la donnée.
Et vers notre capacité à concevoir le bon outil pour permettre à quelqu’un de prendre une décision ou d’effectuer une action.
C’est exactement pour cela que nous suivons de très près Omni Apps chez Corail.
Parce qu’après des années à demander aux utilisateurs de faire rentrer leurs besoins dans les interfaces de la BI, nous pouvons enfin commencer par leur demander :
« Si nous n’avions aucune contrainte d’interface, quel outil voudriez-vous réellement utiliser ? »
