Quatre façons de produire des dashboards : pourquoi les architectures ne se valent pas
Data · Dépendances · Décision
Dans beaucoup d’organisations, la production de dashboards ressemble encore à un bricolage permanent : un peu de SQL ici, un export Excel là, un script Python qui tourne “quelque part”, et une base de données qui sert à tout — y compris à ce qu’elle ne devrait pas faire.
Pourtant, derrière ce chaos apparent, quatre modèles d’architecture reviennent systématiquement. Quatre façons de “fabriquer” la donnée qui alimente les tableaux de bord. Quatre philosophies, quatre niveaux de maturité, quatre implications très différentes.
Et choisir l’une ou l’autre n’est jamais neutre : cela conditionne la maintenabilité, les coûts, les compétences nécessaires, les dépendances, et même la culture technique de l’entreprise.
Voici ces quatre modèles, analysés sans concession.
1. Lecture de la base à chaque requête : le modèle naïf qui finit toujours par coûter cher
C’est le modèle le plus répandu :
- le dashboard interroge directement la base de production (ou une base miroir),
- il exécute ses agrégations,
- il renvoie le résultat “en direct”.
Sur le papier, c’est simple mais dans la réalité, c’est une bombe à retardement.
Ce que cela implique vraiment ?
Les requêtes deviennent de plus en plus lourdes.
La base métier se retrouve à faire de l’analytique.
Les dashboards ralentissent, puis cassent.
Les équipes passent leur temps à optimiser, indexer, patcher.
Le coût caché
Ce modèle paraît gratuit… jusqu’au jour où il ne l’est plus. La moindre montée en charge oblige à surdimensionner le SGBD, à ajouter des replicas, à revoir l’architecture.
2. Enregistrer des données versionnées en base : la maturité “SQL-first”
Ici, on change de philosophie : on ne lit plus la base métier à chaque requête, on matérialise les données, on les versionne, et on les stocke dans une base dédiée.
Chaque semaine, chaque mois, chaque trimestre : une nouvelle “photographie” des données.
Ce que cela apporte
- Des dashboards stables.
- Une vraie auditabilité.
- Une charge maîtrisée.
Les contraintes
- Il faut des pipelines.
- Il faut des migrations.
- Il faut des équipes SQL structurées.
3. Le schéma en étoile Snowflake : la voie royale… mais pas pour tout le monde
Snowflake a remis au goût du jour le modèle BI classique : des tables de faits, des tables de dimensions, un schéma en étoile, et un moteur analytique cloud qui scale automatiquement.
C’est propre, puissant, documenté, standard.
Les avantages
- Une maintenabilité exemplaire.
- Une performance gérée par Snowflake.
- Une architecture BI éprouvée.
Les limites
- Une expertise élevée.
- Une dépendance totale au cloud.
- Des coûts difficiles à prévoir.
4. Parquet / DuckDB / Jinja : l’architecture souveraine, simple, moderne
C’est le modèle qui monte, et pour de bonnes raisons.
Un conteneur éphémère lit les données, génère un fichier Parquet versionné, exécute DuckDB pour les transformations, produit des pages HTML via Jinja, puis s’éteint.
Les dashboards sont statiques, versionnables, souverains, et servis par un simple serveur web.
Pourquoi ce modèle séduit autant
- Zéro serveur à maintenir.
- Zéro dépendance cloud.
- Coûts quasi nuls.
- Reproductibilité parfaite.
- Auditabilité naturelle.
Tableau comparatif des quatre modèles
| Modèle | Maintenabilité | Expertise requise | Coûts & prévisibilité | Dépendances | Coûts hardware |
|---|---|---|---|---|---|
| Données à la volée | Faible : dette technique rapide | Faible → Moyenne | Imprévisibles, explosion avec la charge | Forte dépendance au SGBD métier | Élevés (SGBD surdimensionné) |
| Données versionnées en base | Bonne : tables stables | Moyenne → Élevée | Prévisibles (compute + stockage) | Dépendance au SGBD dédié | Moyens |
| Schéma en étoile Snowflake | Excellente : modèle BI standard | Élevée (BI, ELT, gouvernance) | Variables, parfois élevées | Très forte dépendance cloud | Nuls côté client (cloud) |
| Parquet / DuckDB / Jinja | Excellente : pipelines déterministes | Moyenne (Python + SQL léger) | Très prévisibles, très faibles | Très faibles (open-source) | Très faibles (conteneur éphémère) |
Conclusion : choisir une architecture, c’est choisir une philosophie
Ces quatre modèles ne sont pas seulement des choix techniques, ce sont des choix culturels.
- Le modèle “à la volée” traduit une organisation qui n’a pas encore structuré son analytique ou est en train de structurer.
- Le versionnement SQL traduit une maturité croissante, un choix de l'éprouvé.
- Snowflake traduit une volonté d’industrialiser la BI à grande échelle.
- Le modèle Parquet/DuckDB/Jinja traduit une recherche de souveraineté, de simplicité, et de maîtrise des coûts.
Dans un monde où les dashboards doivent être fiables, reproductibles, et économiques, le modèle Parquet/DuckDB/Jinja s’impose comme une alternative moderne, élégante, et étonnamment puissante.