Construire un datamart pour la sécurité financière, la conformité ou le KYC, c’est comme jouer à Tetris avec des pièces invisibles.
🎯 Les directions veulent souvent :
- Tout l’historique
- Des KPI calculables à la volée
- Une granularité maximale
- …et un temps de réponse < 5s dans Power BI 🤡
Et dans la vraie vie ?
🧨 Tu te retrouves avec 3 sources hétérogènes, un modèle « en l’état » livré par l’IT, et 4 métiers qui ne sont pas d’accord sur la définition d’un « false hit ».
Voici 4 erreurs à éviter, issue de ma propre expérience en projet pour anticiper un maximum de soucis :
1️⃣ Le modèle cible idéal
❌ Ne pas chercher à faire « le » modèle parfait.
✅ Concevoir un socle générique standardisé et évolutif :
- 🔍 Tables d’investigation (horodatées, brutes, normalisées)
- 📊 Tables d’indicateurs agrégés par axe réglementaire (filtrables côté BI)
- 🧾 Tables de justification réglementaire (conformes aux exigences d’audit ACPR ou BCE)
👉 En SQL : tout repose sur une chaîne de transformations lisibles, modulaire, versionnée (dbt est idéal ici).
2️⃣ Les dimensions mouvantes
Beaucoup d’attributs métiers (ex : statut client, typologie d’alerte) changent au fil du temps, mais sont modélisés comme des dimensions figées.
🎯 Solution :
- SCD de type 2: Utiliser systématiquement des dimensions à gestion de temporalité (
valid_from/valid_to) - penser à positionner un flag boolean actif/inactif -> pratique pour les analystes ad-hoc
3️⃣ Calculer les règles métiers au mauvais niveau
Certaines règles ou kpi conformité nécessitent 10 jointures entre alertes, clients, décisions, comptes, transactions, listes, seuils…
⚠️ Ces requêtes sont intenables à la volée dans un dashboard.
💡 Ce que je préconise:
- Externaliser la logique métier en tables de règles pré-calculées (
rule_id,alert_id,is_triggered) - Générer ces tables chaque nuit via un
pipelineordonnancé (Dataiku, Airflow ou dbt)
➡️ Tableau/Power BI/Looker ne feront alors que lire un booléen ou un score : rapide, traçable, maintenable.
4️⃣ Choisir une granularité trop fine
🤯 Beaucoup de datamarts sont pensés avec un « grain » trop optimiste :
Une ligne par alerte, ou une ligne par client, ou une ligne par compte.
Puis on essaie d’y coller tous les indicateurs : nombre de transactions, nombre de statuts KYC, nombre de règles AML déclenchées, etc.
Résultat :
- Jointures
LEFTdans tous les sens - Dédoublements de lignes
- KPIs faussés
- Temps de réponse catastrophique du dashboard
✅ Ce que je recommande à la place :
🔹 Créer une « table de faits principale » avec un grain maîtrisé et homogène (par exemple : alerte x client x date).
🔹 Joindre toutes les métriques à cette table en amont, via des vues ou des pipelines SQL.
🔹 Ne laisser aucune jointure trop complexe aux outils BI. Tout doit être pré-calculé.
🧠 L’objectif : une structure en étoile stable où chaque table joue un rôle clair (faits, dimensions), et surtout aucune surprise quand on additionne ou qu’on filtre.
🎬 En résumé : dans la conformité bancaire, le danger n’est pas de mal modéliser…
Mais de modéliser trop tôt, sans mécanisme d’adaptation.
👇 Si vous en avez d’autres en tête, n’hésitez pas à partager!
#dataengineering #aml #datamodelling #datapipeline #banking #sql #tableau #dbt #compliance #analytics