vdegove
commented
10 months ago Si on part sur Metabase (car c’est ce qui se dessine à 95% de chances, sauf si @thbar nous trouve un autre outil d’exploration qui coche toutes les cases, petite analyse par rapport aux contraintes :
- :orange_circle: : Conserver des ops les plus simples possibles : Quand même un serveur voir deux à déployer + un process pour copier la donnée de prod (voir après)
- :orange_circle: : Ne pas avoir de risque par rapport à la confidentialité (2FA, leak), ne pas perturber la prod, avoir des données fraîches (24h au max), lecture seule : tout ça nécessite d’avoir une sorte de duplicat de la BDD de prod, sans accès aux données sensibles
- :green_circle: Deux sources de données : prod du PAN (metadonnées) ou certaines données tabulaires (IRVE, BNLC, etc). Truc assez cool dans Metabase, on peut drop un CSV et s’en servir comme table.
- :red_circle: ne pas risquer de perdre des choses déjà faites Il n’y à pas (à priori) de backup et versionnage intégré et à part des requêtes SQL – c’est dans le backup général de l’instance
- :green_circle: autonomie importante : clairement le gros plus de la solution
- :green_circle: Ergonomique et rapide à utiliser
- :green_circle: Coût financier raisonnable en hébergement et en temps humain
D’autres limites à avoir en tête de Metabase :
- :orange_circle: C’est vraiment pas idéal pour afficher des données sous forme de carte, avec nos propres limites administratives c’est faisable mais pénible, voir https://www.metabase.com/docs/latest/configuring-metabase/custom-maps
- :orange_circle: Il n’y a pas d’ERD inclus, on est sensé connaître le schéma de la base de données pour savoir quoi jointurer (par contre il y a une aide à la jointure intégrée). Besoin donc de pédagogie sur le domain model du PAN.
thbar
Problème résolu (et ceux non résolus)
En tant que membre du PAN (bizdev ou développeur), j’ai besoin d’afficher (tableau, graphique ou carte) des données présentes dans la base de données PostgreSQL du PAN ou dans un des jeux de données aggrégés, afin de suivre mon travail et le piloter, sans devoir remouliner à la main des données exportées ou faire appel à un développement pour chaque indicateur.
En tant bizdvev, je veux me familiariser avec la base de données du PAN et explorer les données afin de mieux connaître le produit et nos données, afin de nourrir la réflexion produit.
En tant que bizdev ou dev, je veux pouvoir répondre plus facilement à une question inattendue sur les données sans devoir faire appel à du dev afin de prendre une décision rapidement ou vérifier qu’il n’y a pas une incohérence sur un point actuellement travaillé. Les devs doivent cependant pouvoir voir à postériori l’analyse faite et la corriger si erreur d’interprétation ou de requêtage SQL.
Problèmes mis de côté
Nous n’adressons pas directement ce problème : en tant qu’utilisateur du PAN (non forcément interne à l’équipe), je veux avoir accès à un dashboard du PAN idéal et durable qui me montre les grandes métriques les plus pertinentes pour l’impact du PAN et leur progression dans le temps.
Ce problème fera l’objet d’une issue séparé, et ne sera pas traité avec le même outillage que l’approche exploratoire. Il ne s’agit pas des mêmes enjeux : par exemple, les indicateurs métiers pertinents ne sont pas tous affichables avec la base de donnée actuelle, et nous n’avons pas toutes les séries temporelles demandées actuellement. Certaines solutions exploratoires peuvent casser lors d’un changement du schéma et il faut que les dashboards «durcis» soient testés afin d’éviter cela. L’approche exploratoire va en revanche nourrir ce travail de dashboard «durci».
Contraintes
Tâches