Le projet en un coup d’œil
Les commandes devaient être filtrées et regroupées selon plusieurs besoins.
Instances, versions, groupes, types et vues sont devenus des objets administrables.
Une vue pouvait être ajoutée, activée ou exposée sans redessiner tout le socle.
Un tableau de bord devient vite rigide lorsque chaque nouveau regroupement impose une modification du cœur applicatif. Les besoins d’analyse changent pourtant avec les équipes, les sources et les périodes observées.
Coora BI a été conçu pour séparer la donnée opérationnelle de la définition des vues. Instances, types, versions, boutiques, commandes et lignes constituent le socle ; groupes, types BI et vues configurent la manière de l’interroger et de la présenter.
Cette réalisation d’application métier data montre un arbitrage utile : investir dans une structure administrable pour que l’analyse puisse évoluer sans transformer chaque demande en développement isolé.
1. Coora BI, un produit d’exploration construit autour des flux de commande
Faire varier les lectures sans dupliquer la donnée
Le produit devait intégrer plusieurs boutiques et sources techniques, chacune susceptible d’exister dans différents types ou versions. Les journaux d’instance complétaient ce catalogue.
Les commandes et leurs lignes formaient le matériau analytique. Les utilisateurs avaient besoin de les rechercher, les ouvrir et les regrouper dans des vues adaptées.
La configuration BI devait rester compréhensible : un groupe rassemble des lectures, un type les qualifie et une vue porte le calcul ou la présentation activable.
2. Un prototype métier développé par couches successives
Catalogue, commandes, vues puis API
Le socle a d’abord structuré les instances, types, versions, boutiques, comptes et utilisateurs. Les commandes ont ensuite rejoint le modèle avec leurs lignes et leurs écrans de recherche.
Les groupes, types et vues BI ont été ajoutés avec leurs parcours de création, recherche et activation. Les pivots et filtres, notamment par année, ont affiné la lecture.
Une API a finalement exposé les vues et leurs flux par jour. Les dernières corrections ont amélioré la performance et retiré une dépendance devenue inutile entre source et commande.
3. Le reporting se rigidifie quand la vue et la donnée sont confondues
Chaque nouvel angle devient une modification du produit
Si les regroupements sont écrits directement dans les écrans, ajouter une lecture annuelle, un pivot ou un groupe impose de toucher au même bloc de code.
Cette rigidité complique aussi la réutilisation par une autre interface : la donnée reste enfermée dans sa présentation initiale.
4. Rendre la source et la vue indépendantes
Un socle stable, des lectures configurables
Le premier objectif était d’identifier clairement les instances, leurs types, versions et boutiques afin de garder la provenance des données compréhensible.
Le second consistait à administrer les regroupements BI et à exposer leurs résultats par interface et par API.
5. Un catalogue technique relié aux commandes
Puis une couche BI organisée en groupes, types et vues
Les instances, versions et boutiques structurent l’entrée des données. Les commandes et lignes restent consultables comme objets métier, avec recherche et détail.
Au-dessus, les groupes, types et vues peuvent être créés puis activés. Les pivots et filtres temporels modifient la lecture sans dupliquer les commandes.
6. Exposer la vue plutôt que l’écran
Préparer plusieurs usages de la même analyse
L’API donne accès à une vue BI et à son flux par jour. Le calcul devient ainsi réutilisable par une autre interface au lieu d’être lié à un unique composant visuel.
Le retrait de la source directement portée par la commande a simplifié le modèle lorsque cette relation n’apportait plus la bonne information.
7. Optimiser un prototype à forte densité de données
Corrections ciblées sur les requêtes et les pivots
Les dernières itérations ont porté sur la performance, les filtres et la cohérence des vues. Ces ajustements sont essentiels lorsqu’une analyse agrège plusieurs commandes et lignes.
La séparation nette entre domaines catalogue, commandes, BI et utilisateurs facilite l’identification du niveau concerné par une anomalie.
8. Une base d’analyse plus facile à faire évoluer
Les vues deviennent des objets du produit
Les équipes peuvent configurer les regroupements et activer les lectures nécessaires sans modifier la structure des commandes. Le filtre annuel et les pivots donnent plusieurs angles sur le même corpus.
L’API prolonge ces capacités au-delà de l’interface initiale. Coora BI pose ainsi un socle où une nouvelle restitution peut réutiliser une vue existante.
9. Faire de l’analyse une capacité configurable
Le reporting gagne en durée quand il n’est pas enfermé dans un écran
Coora BI transforme les vues analytiques en éléments administrables, reliés à un catalogue de sources et à un domaine de commandes clairement séparé.
Cette architecture demande davantage de structuration au départ, mais elle évite que chaque question future devienne un tableau de bord indépendant et difficile à maintenir.
Dawap développe ces applications métier orientées données lorsque les usages analytiques doivent évoluer sans perdre la cohérence du socle.
