Bases de données & Datalakes
Avant le moindre tableau de bord, il faut une donnée fiable. C'est la partie invisible du travail, et souvent la plus importante.
Trois logiciels, trois façons d'écrire le même client. Le vrai travail commence exactement là.
Harmoniser, concrètement
Chaque logiciel a sa nomenclature. Tant que ces trois lignes ne sont pas reconnues comme un seul et même client, aucun rapport ne peut être juste.
- ERP
- NomLAITERIE DU VAL SAS
- IdentifiantCLI-00482
- PaysFR
- CRM
- NomLaiterie du Val
- Identifiant482
- PaysFrance
- Finance
- NomLaiterie Val (SAS)
- Identifiant00482
- PaysFRA
- Datalake, zone métier
- Nom?
- Identifiant?
- Pays?
- Sources?
Exemple fictif.
Datalake ou base de données ?
En pratique, les deux se complètent : le Datalake conserve tout, les tables métier qui en sortent servent les rapports.
Le chemin d'une donnée
Chez Synerlink, le Datalake existait déjà à mon arrivée : mon rôle était de le maintenir à jour et de l'améliorer, pour qu'il alimente de façon fiable tous les rapports Power BI.
- SourcesERP, CRM, finance, RH
- IngestionExtractions planifiées
- Zone bruteCopie fidèle, historisée
- Zone nettoyéeFormats et doublons corrigés
- Zone métierTables prêtes à l’analyse
- RestitutionRapports Power BI
En SQL, ça ressemble à ça
Une fois les identifiants alignés, une seule requête croise ce que trois logiciels savaient chacun de leur côté.
-- Chiffre d'affaires par client, vu par les trois sources
SELECT e.client_id,
TRIM(e.raison_sociale) AS client,
c.segment,
SUM(f.montant_ht) AS ca_ht
FROM erp.clients AS e
JOIN crm.comptes AS c ON c.code_erp = e.client_id
LEFT JOIN finance.factures AS f ON f.client_id = e.client_id
GROUP BY e.client_id, e.raison_sociale, c.segment
ORDER BY ca_ht DESC;