Pour la plupart des nouveaux tableaux de bord que nous construisons chez Bluesquare, nous ne partons plus d’un outil de business intelligence (BI) comme Power BI, Tableau ou Apache Superset. Nous écrivons à la place une petite application web, avec un assistant de codage IA, sur des données déjà nettoyées et modélisées dans OpenHEXA.
Le raisonnement est simple. Un outil de BI remplit 2 fonctions : il modélise les données (tables, définitions des indicateurs, règles d’accès) et il restitue le résultat (graphiques, cartes, filtres). La première est celle qui concentre l’essentiel de l’effort d’ingénierie, et elle ne dépend pas de l’outil de BI. La seconde est désormais peu coûteuse à réaliser en code simple. Une fois ces 2 fonctions dissociées, la partie restitution peut être une application sur mesure.
Séparer la couche de données de la couche de restitution s’appelle généralement la BI headless, et la question de savoir si les applications créées par l’IA remplaceront les tableaux de bord de BI a été débattue à de nombreuses reprises cette année. Cet article décrit comment cela fonctionne concrètement sur OpenHEXA, et pourquoi nous pensons que cela compte pour les ministères de la Santé qui gèrent leur propre infrastructure.
Dans OpenHEXA, le travail sur les données se fait dans un espace de travail. Les pipelines sont des programmes Python (et bientôt R), écrits avec le SDK OpenHEXA et planifiés dans la plateforme. Ils récupèrent des données depuis DHIS2, IASO, des enquêtes ou des fichiers, les nettoient, calculent des indicateurs et écrivent les résultats dans la base de données de l’espace de travail.
La logique des indicateurs se trouve dans ces pipelines : quel dénominateur s’applique à la couverture vaccinale, quels établissements comptent comme déclarants, comment les rapports tardifs sont traités. Cette logique est écrite une seule fois, dans du code versionné, et les notebooks, les exports et les applications web s’appuient tous sur les tables qu’elle produit. Le versionnage est intégré à OpenHEXA, il n’est donc pas nécessaire de recourir à une plateforme distincte.
Depuis la version 5.0, OpenHEXA peut héberger des applications web statiques dans un espace de travail, à côté des pipelines et de la base de données qui les alimentent. Une application peut rester privée au sein de l’espace de travail ou être publiée publiquement.
Il existe 2 façons de les construire. OpenHEXA dispose d’un assistant IA directement dans son interface : vous décrivez l’application ou la modification souhaitée, et il écrit le code, en utilisant le fournisseur d’IA configuré par votre organisation. Vous pouvez aussi utiliser l’agent IA avec lequel vous travaillez déjà, comme Claude, Codex ou d’autres, depuis votre environnement habituel. OpenHEXA expose un serveur Model Context Protocol (MCP), ce qui permet à votre agent de créer et de modifier directement des applications web dans l’espace de travail, avec accès aux mêmes données et aux mêmes pipelines.
Il y a 3 avantages concrets par rapport à un tableau de bord de BI :
Il ne faut pas confier la base de données à une application générée, et ce n’est pas nécessaire. Dans OpenHEXA, une application web déclare des scopes (périmètres d’accès : lecture des jeux de données, lecture des fichiers, exécution de pipelines, lecture de la base de données, etc.), et ses appels d’API passent par un proxy qui ne laisse passer que les champs autorisés par ces scopes.
Pour la base de données, la règle est plus stricte : une application web ne peut exécuter que des requêtes enregistrées dans l’espace de travail. Elle ne peut pas envoyer son propre SQL. Chaque requête est journalisée, y compris celles qui sont refusées. Les requêtes enregistrées jouent donc le rôle de contrat entre la couche de données et l’application : l’équipe chargée des données décide de ce qui peut être lu, et l’application ne peut que l’afficher.
Les règles d’accès sont gérées à un seul endroit, avec les données, et une application les hérite quelle que soit la façon dont elle a été écrite.
L’objection habituelle aux tableaux de bord sur mesure est la maintenance : 10 tableaux de bord deviennent 10 petites bases de code. C’était déjà vrai avec les tableaux de bord de BI. Avec les applications web sur OpenHEXA, le coût reste faible, car les applications ne contiennent aucune logique métier. Les définitions des indicateurs se trouvent dans les pipelines, les permissions dans l’espace de travail, et l’application se contente d’interroger les données et de les afficher.
Quand une définition change, elle change une seule fois, dans le pipeline. Quand une application devient obsolète, elle se corrige souvent en quelques prompts.
Les applications web sont aussi versionnées. Chaque modification, qu’elle vienne de l’assistant intégré, d’un agent externe ou d’un développeur, crée une nouvelle version avec son auteur, son message et son diff. Vous choisissez quelle version est publiée. Essayer une modification coûte donc peu : si le résultat n’est pas assez bon, vous republiez la version précédente.
OpenHEXA est open source et enregistré comme bien public numérique. Des ministères de la Santé de la République démocratique du Congo (RDC), du Cameroun, du Burkina Faso, du Niger et de Côte d’Ivoire l’utilisent, et il peut être installé sur les serveurs propres d’un pays, de sorte que les données de santé restent dans l’infrastructure nationale. Une fois qu’il fonctionne sur une infrastructure dont vous êtes propriétaire, il n’y a plus de frais de licence récurrents liés à une carte bancaire, ni de changements de prix décidés par un fournisseur tiers.
L’installation est volontairement modeste : un paquet Debian et une stack Docker Compose sur un seul serveur Debian, avec PostgreSQL et PostGIS. Les pipelines, la base de données et les applications web fonctionnent tous sur cette machine, et une application statique n’est qu’un ensemble de fichiers servis par le même serveur. Si OpenHEXA devient l’outil de travail principal d’une grande équipe, et que les pipelines ont besoin de plus de puissance de calcul et de mémoire qu’une seule machine ne peut en fournir, il peut aussi être déployé sur Kubernetes et dimensionné selon les besoins. Cela a déjà été fait pour de grandes organisations des Nations Unies. Une autre option consiste à confier l’hébergement d’OpenHEXA à Bluesquare, qui s’en occupe, pour les équipes qui préfèrent ne pas gérer le serveur elles-mêmes. Les pipelines, les applications web et les outils d’IA fonctionnent de la même manière dans toutes les configurations.
Les outils d’IA n’interviennent que lorsque quelqu’un construit ou modifie une application. Ils écrivent le code de l’application, via l’assistant intégré ou un agent externe connecté par MCP. La diffusion des tableaux de bord aux utilisateurs ne dépend de rien d’extérieur au serveur qui héberge OpenHEXA. Pour un ministère qui gère son propre serveur avec un budget informatique limité, cela signifie que les tableaux de bord se construisent en quelques jours plutôt qu’en quelques semaines, et que le coût de fonctionnement se résume à un serveur, sans licence de BI par utilisateur et sans hébergement cloud distinct. Un exemple récent en RDC montre à quelle vitesse une équipe d’un ministère peut y parvenir.
Dans le cadre de la riposte à Ebola en RDC, les données de cas sont collectées dans DHIS2 Tracker et visualisées dans un tableau de bord de BI Apache Superset dédié. Dans la pratique, cependant, les données de DHIS2 n’étaient pas assez rapidement disponibles pour appuyer le suivi quotidien des contacts. Pour combler ce manque, le ministère de la Santé a mis en place des fichiers Excel temporaires afin d’identifier les zones de santé où le suivi des contacts devait être renforcé.
Ces fichiers Excel donnaient l’image la plus à jour de la riposte, mais aucun produit analytique n’avait été construit dessus pour appuyer des décisions fondées sur les données. Des gestionnaires de données du ministère, sans compétences en programmation, ont utilisé les fonctionnalités d’IA d’OpenHEXA pour construire un pipeline ETL qui nettoie ces fichiers. Il corrige les formats de date, rectifie les noms de provinces mal orthographiés et résout les écarts avec la pyramide sanitaire. Ils ont ensuite utilisé les fonctionnalités d’IA des applications web d’OpenHEXA pour construire un tableau de bord de suivi des contacts. En une heure et quelques itérations, le ministère disposait d’un tableau de bord opérationnel fonctionnel. Il signalait les zones de santé où le listage et le suivi des contacts devaient s’améliorer, et ces constats ont été remontés aux piliers de la riposte concernés. Le tableau de bord sert désormais à suivre les indicateurs clés (KPI) lors de la réunion quotidienne de surveillance à Bunia.
L’exemple offre 3 enseignements :
Vous pouvez l’essayer dès maintenant : démarrez gratuitement et accédez immédiatement à la plateforme, avec un essai gratuit de 30 jours, ou demandez une démo.
