Si « client » n'a pas la même définition partout, l'IA ne peut pas fonctionner
Le comité de direction regarde le dashboard mensuel. Le marketing annonce 12 000 clients actifs. La comptabilité en compte 9 500. Le service client en voit 10 800. Trois chiffres, trois définitions différentes, zéro confiance dans les données. Et quand l'entreprise lance un projet IA de prédiction de churn, le modèle est alimenté par ces données incohérentes et produit des résultats inexploitables. Le référentiel business résout ce problème à la racine : une définition unique, partagée et documentée pour chaque terme métier critique.
Le problème
Dans une ETI de 300 salariés, le terme « chiffre d'affaires » a au moins 4 interprétations : le CA facturé (comptabilité), le CA encaissé (trésorerie), le CA commandé (commerce) et le CA livré (logistique). Quand le directeur général demande « quel est notre CA du mois ? », il reçoit 4 réponses différentes. Et personne n'a tort — chacun répond selon sa définition.
Ce problème se retrouve partout :
- Définitions de « client » contradictoires — Le CRM compte les fiches créées (y compris les prospects jamais convertis). L'ERP compte les comptes avec au moins une facture. Le marketing compte les abonnés à la newsletter. Résultat : un écart de 20 à 40 % entre les décomptes, et des rapports mensuels qui ne s'alignent jamais.
- KPIs calculés différemment — Le taux de conversion est calculé à partir des visiteurs uniques pour le marketing et à partir des devis envoyés pour le commerce. Les deux services annoncent un taux de conversion mais il ne mesure pas la même chose. Le CODIR compare des chiffres incomparables.
- Projets IA pollués par les ambiguïtés — Un modèle de prédiction de ventes est entraîné sur le « CA commandé ». Le reporting le compare au « CA facturé ». L'écart naturel entre les deux (commandes annulées, avoir, délais de facturation) est interprété comme une erreur du modèle. Le projet IA est jugé non fiable et abandonné.
La cause racine est toujours la même : absence de référentiel partagé. Chaque service a développé ses propres définitions au fil du temps, dans ses propres fichiers Excel, sans concertation. Le référentiel business casse ces silos. Consultez notre atelier qualité des données pour une approche guidée.
La solution IA
Le référentiel business (business glossary) centralise les définitions métier et les connecte aux données techniques. L'IA accélère sa construction et son maintien à jour.
Glossaire métier centralisé
Un dictionnaire unique et accessible à tous qui définit chaque terme métier : nom, définition précise, formule de calcul, exemples, Data Owner, systèmes sources et règles de qualité. L'IA aide à rédiger les définitions en analysant l'usage réel des termes dans les requêtes SQL, les dashboards et les fichiers Excel existants. Elle détecte les incohérences entre services.
Mapping termes métier / colonnes techniques
Chaque terme du glossaire est relié aux colonnes physiques des bases de données. « Client actif » pointe vers la requête SQL exacte qui le calcule. L'IA assiste le mapping en analysant les noms de colonnes, les commentaires SQL et les formules existantes pour suggérer les correspondances. Plus besoin de demander « c'est quelle table ? » — le référentiel le dit.
Détection automatique des conflits
L'IA compare les définitions entre services en analysant les requêtes SQL utilisées par chaque équipe pour calculer les mêmes métriques. Elle identifie les écarts : « le marketing calcule le CA avec la table orders (status = completed), la compta avec la table invoices (type = facture) ». Elle quantifie l'impact de l'écart et génère un rapport de réconciliation.
Mise en oeuvre
La construction du référentiel business se fait en trois phases sur 6 à 10 semaines.
Inventaire des termes critiques (semaines 1-2)
Identifiez les 30 à 50 termes métier les plus utilisés dans votre entreprise : « client », « chiffre d'affaires », « marge », « produit actif », « commande validée », etc. Pour chaque terme, interrogez 2 à 3 services : « comment définissez-vous ce terme ? ». Documentez les définitions actuelles et les écarts. Priorisez les termes qui causent le plus de confusion.
Ateliers de définition (semaines 3-6)
Organisez un atelier d'1h30 par domaine (clients, produits, finance, RH). Réunissez les Data Owners concernés. Pour chaque terme, exposez les définitions divergentes et leurs impacts chiffrés. Convergez vers une définition unique. Documentez : nom, définition, formule, Owner, systèmes sources. Validez avec le sponsor exécutif pour les termes stratégiques.
Publication et adoption (semaines 7-10)
Publiez le référentiel dans un outil accessible à tous (Notion, Confluence, DataHub). Créez un processus de mise à jour : toute nouvelle définition ou modification passe par le Data Owner. Intégrez le référentiel dans les projets IA : chaque variable d'un modèle doit pointer vers une entrée du glossaire. Formez les équipes et instaurez une revue trimestrielle.
Résultats
Voici les résultats observés chez nos clients après mise en place du référentiel business.
Questions fréquentes
Qu'est-ce qu'un référentiel business (business glossary) ?
Un référentiel business est un dictionnaire partagé qui définit de manière unique et non ambiguë les termes métier de l'entreprise : « client actif », « chiffre d'affaires net », « produit en stock », « lead qualifié ». Pour chaque terme, il précise la définition, la formule de calcul, le Data Owner responsable, les systèmes sources et les règles de qualité associées. C'est la pierre angulaire de la gouvernance des données.
Pourquoi faut-il un référentiel avant de lancer un projet IA ?
Parce qu'un modèle IA entraîné sur des données dont les définitions varient entre les sources produira des résultats incohérents. Si « client actif » signifie « achat dans les 12 mois » pour le CRM et « compte non clôturé » pour l'ERP, le modèle mélange deux populations différentes. Les prédictions sont biaisées et les décisions basées sur ces prédictions sont fausses. Le référentiel aligne tout le monde avant que l'IA n'intervienne.
Comment gérer les conflits de définition entre services ?
Les conflits sont normaux et fréquents. La méthode : réunissez les Data Owners concernés (ex : directeur commercial + directeur financier pour la définition de « client »), exposez les définitions actuelles de chaque service, identifiez les écarts et leurs impacts (ex : 2 500 « clients » de différence entre les deux définitions). Le Data Owner principal tranche. Si le conflit persiste, le sponsor exécutif (DG ou DAF) arbitre. Documentez la décision et l'historique.
Faut-il un outil dédié pour gérer le référentiel business ?
Au démarrage, un tableur collaboratif (Google Sheets, Notion, Confluence) suffit pour documenter les 30 à 50 premiers termes. L'outil dédié (Atlan, Alation, DataHub avec glossary) devient nécessaire quand le référentiel dépasse 100 termes, quand plusieurs équipes contribuent simultanément, ou quand vous voulez lier les termes métier aux colonnes techniques (data catalog). La règle : commencez simple, outillez quand ça fait mal.
Pour les profils tech
Implémentation technique du référentiel
Metrics-as-code
dbt permet de définir les métriques métier directement dans le code SQL : semantic models, dimensions et measures. Chaque métrique a une définition unique, versionnée dans Git, avec sa formule SQL exacte. Les outils BI (Tableau, Looker, Power BI via Semantic Layer API) consomment ces définitions au lieu de recalculer localement. Fini les divergences.
Référentiel connecté au catalogue
DataHub (open source) propose un module Business Glossary intégré au catalogue de données. Chaque terme est relié aux datasets, colonnes et dashboards correspondants. Recherche full-text, tags, hiérarchie de termes et workflow de validation (draft → review → approved). Se déploie via Docker en 2 heures.
Outils recommandés
Comparatif des approches
| Critère | dbt Semantic Layer + DataHub | Tableur partagé | Atlan / Alation |
|---|---|---|---|
| Coût | Gratuit (open source) | Quasi nul | 2 000-10 000 €/mois |
| Lien données techniques | Natif (colonnes + SQL) | Manuel | Natif |
| Versionnement | Git natif (dbt) | Historique fichier | Intégré |
| Adoption non-tech | Moyenne (interface DataHub) | Excellente | Excellente (UX premium) |