Langage commun data et IA : pourquoi les organisations data-driven alignent métiers et technologie avant tout le reste

Retour d’expérience avec Skander Kouli, Lead Data Governance chez Salomon, sur la manière dont un glossaire métier partagé est devenu la fondation de l’autonomie data — et le prérequis oublié de l’IA à l’échelle.

Dans toutes les organisations, il y a un mot qui change de sens selon l’étage où on le prononce. « Client ». « Chiffre d’affaires ». « Commande active ». Le commercial en a une définition, le marketing une autre, la comptabilité une troisième, et le service client une quatrième. Chacun est convaincu de sa vérité. Personne n’est en train de mentir.

Et pourtant, le même chiffre dans trois dashboards différents raconte trois histoires différentes.

Le coût caché du désalignement linguistique en entreprise

Ce n’est pas un problème technique. C’est un problème d’alignement linguistique. Et il coûte cher : en moyenne, un jour par semaine et par collaborateur perdu à chercher, vérifier et réconcilier l’information. Multipliez ce coût par la taille de vos équipes data, et vous obtenez la facture silencieuse que paie votre organisation chaque année.

Pire : quand l’IA arrive dans cette équation, elle n’invente pas une définition commune. Elle amplifie le chaos existant — à sa vitesse propre, et dans toutes les directions à la fois.

Un sondage en temps réel pendant le webinaire l’a confirmé : la très grande majorité des participants reconnaissent qu’il n’y a pas de langage commun dans leur entreprise. Ce constat traverse tous les secteurs, toutes les tailles — PME, ETI, grands groupes internationaux, secteur public.

Les trois couches du désalignement data

Le décalage se manifeste sur trois niveaux qui s’empilent et se renforcent.

La couche sémantique. C’est la plus importante — c’est où vivent les définitions, les KPI, l’interprétation. Si le « chiffre d’affaires » n’est pas calculé de la même façon par la finance et le commercial, tous les arbitrages basés dessus sont fragiles.

La couche technique. Quand une donnée apparaît dans un rapport, personne ne sait d’où elle vient, comment elle a été calculée, qui en est responsable. Le lineage est cassé, la traçabilité est illusoire.

La couche organisationnelle. Un nouvel arrivant — disons un spécialiste finance — passe ses premières semaines à chercher où sont les données dont il a besoin. Il découvre que les noms diffèrent d’une équipe à l’autre, que les référentiels se contredisent, et que personne ne peut lui dire qui est responsable de quoi.

Tant que ces trois couches ne sont pas réconciliées, la gouvernance reste théorique et l’autonomie data reste un slogan.

Le cas Salomon : du programme PACE à la gouvernance des données

Salomon, marque historique française de l’outdoor créée en 1947 à Annecy, est présent dans plus de 40 pays et fait partie du groupe Amer Sports (Wilson, Arc’teryx). Une part croissante de son activité passe par le canal D2C — e-commerce et magasins propres — ce qui génère un volume de données considérable à maîtriser.

Pour rendre ses équipes autonomes sur l’analyse de données, Salomon a lancé un programme baptisé PACE (Power BI Adoption through Community and Empowerment), structuré autour de quatre piliers : formation Power BI par niveau, centre d’excellence avec office hours, communauté de pratique, et partage des bonnes pratiques de modélisation.

Mais très vite, un constat a émergé : on peut former les gens à Power BI autant qu’on veut, si les données derrière ne sont pas compréhensibles, trouvables et fiables, le self-service ne décolle pas. Les équipes construisaient des dashboards, mais ne faisaient pas confiance aux chiffres. Elles posaient toujours les mêmes questions : c’est quoi ce champ, d’où vient cette donnée, comment elle est calculée, est-ce que je peux m’en servir ?

La conclusion de Skander Kouli : la data governance n’est pas un sujet à part. C’est le socle qui rend le self-service possible.

La méthode en cinq étapes : commencer petit, itérer ensuite

Plutôt que de tenter de tout gouverner d’un coup — l’erreur classique qui tue la plupart des programmes — Salomon a choisi un POC ciblé sur le périmètre e-commerce, le domaine avec le plus d’enjeux et le plus de frictions.

Étape 1 : cadrage. Identifier les données e-commerce et les systèmes critiques, prioriser les modèles sémantiques qui ont le plus d’impact sur les décisions métier.

Étape 2 : cataloging. Définir les termes métier dans un glossaire partagé, avec owner et steward nommés. La vision sémantique — la partie déclarative qui nécessite l’implication des métiers — est documentée et publiée.

Étape 3 : lineage. Connecter le glossaire métier (déclaratif) au dictionnaire technique (automatisé via les connecteurs Snowflake), puis jusqu’aux usages finaux dans Power BI. C’est le pont entre le langage métier et le langage technique.

Étape 4 : qualité. Définir les règles de qualité, à la fois techniques sur les flux Snowflake et métier avec des seuils d’alerte par région EMEA, APAC, etc. Documenter ces règles dans Data Galaxy comme référentiel centralisé, puis les implémenter dans les outils d’observabilité avec des alertes automatisées.

Étape 5 : itération. Répliquer la méthode sur les autres domaines : B2B, logistique, marketing, RH. Chaque nouveau domaine reçoit au minimum un owner et un steward nommés, avec extension à mesure que le scope grandit.

Data product : le changement de paradigme qui rend tout possible

Un changement de paradigme sous-tend toute cette démarche : passer de la logique projet à la logique produit.

Un data product, ce n’est pas une table ni un schéma. C’est un actif documenté, fiable, traçable et réutilisable, avec quatre propriétés essentielles. Un owner et un steward nommés, pour l’accountability. Une documentation fiable, accessible à tous les consommateurs potentiels. Des indicateurs de qualité — complétude, exactitude, consistance, validité, unicité, intégrité — mesurés et publiés. Un monitoring régulier pour détecter les dérives avant qu’elles n’atteignent les consommateurs.

Une fois qu’un data product est bien gouverné en amont, tout ce qui en découle — dashboards, analyses ad hoc, projets IA et ML — hérite de la fiabilité. On ne construit plus 50 dashboards éphémères, on maintient un petit nombre d’actifs data partagés dans toute l’entreprise.

L’architecture technique : Data Galaxy, Snowflake, Power BI

L’écosystème mis en place chez Salomon articule trois outils.

Data Galaxy assure la gouvernance : glossaire métier, dictionnaire technique, lineage, documentation. C’est la couche de connaissance partagée. Snowflake est la plateforme data où sont exposés les modèles analytiques. Power BI est l’outil de visualisation en bout de chaîne.

Data Galaxy remplit le rôle de plateforme unificatrice : les métadonnées techniques de Snowflake remontent automatiquement via un connecteur natif, les modèles Power BI remontent également via un autre connecteur. Seule la vision métier — déclarative par nature — est maintenue manuellement par les stewards.

Résultat : quand un utilisateur voit un KPI dans un dashboard Power BI, il peut cliquer sur une extension navigateur Data Galaxy pour obtenir immédiatement la définition métier, le lineage complet, l’owner, les règles de calcul. Plus besoin d’envoyer un message à l’équipe data pour demander « c’est quoi ce champ ».

Les cinq enseignements clés pour réussir un programme de gouvernance des données

Skander a partagé cinq leçons apprises qui valent pour toute organisation qui se lance.

Commencer petit. Le POC e-commerce a permis de prouver la valeur rapidement, de générer des quick wins, et de créer l’adhésion nécessaire pour étendre aux autres domaines. Vouloir tout gouverner d’un coup est la meilleure façon de ne jamais démarrer.

Le glossaire métier est la fondation. Sans langage commun, pas de self-service fiable. Paradoxalement, c’est souvent la brique la plus négligée parce qu’elle paraît simple. Dans les faits, la pire erreur.

Une plateforme unificatrice plutôt qu’une mosaïque d’outils. Un seul référentiel qui relie la vision métier, la vision tech et les usages finaux. Cela évite la fragmentation de l’information et donne à chaque équipe la même source de vérité.

Le lineage crée la confiance. Quand les utilisateurs voient d’où vient la donnée et comment elle est transformée, ils l’utilisent. Sans transparence, ils doutent et reviennent toujours vers l’équipe data.

L’adoption est un changement de culture, pas un déploiement d’outil. C’est le combat quotidien. Il faut un sponsor métier fort — chez Salomon, l’équipe e-commerce — des relais formés (les stewards et owners), et un effort de formation initiale pour que les utilisateurs s’approprient le sujet.

Pourquoi le langage commun est aussi le prérequis de l’IA

La conclusion vaut d’être soulignée : tout ce que Salomon a fait pour permettre le self-service Power BI est exactement ce qui rend l’IA possible à l’échelle.

Un agent IA qui interroge un data catalog bien gouverné via un serveur MCP hérite du contexte métier, des classifications de sensibilité, des règles d’accès. Un modèle entraîné sur un data product certifié hérite de sa qualité. Un décideur qui valide une recommandation IA peut la tracer jusqu’à sa source via le lineage.

Sans ces fondations, les projets IA restent des POC isolés qui ne passent jamais à l’échelle. Avec ces fondations, chaque nouvelle initiative IA accélère, parce qu’elle peut se brancher sur un socle déjà fiable.

Le « secret » des organisations data-driven en 2026 n’est pas un secret. C’est la discipline patiente de construire un langage commun, d’en faire le socle technique et organisationnel de l’entreprise, et d’y raccorder progressivement chaque nouveau cas d’usage — métier comme IA.

Découvrez comment DataGalaxy accompagne les organisations dans la construction d’un langage commun autour de la donnée et de l’IA. Regardez le replay complet du webinaire.

Q&A

Qu’est-ce qu’un langage commun de la donnée en entreprise ?

Un langage commun de la donnée est un ensemble partagé de définitions, de KPI, de termes métier et de règles de calcul auquel toutes les équipes de l’entreprise se réfèrent. Il vit généralement dans un glossaire métier hébergé par un data catalog, avec un owner et un steward identifiés pour chaque terme. Sans ce socle linguistique partagé, chaque équipe construit ses propres définitions et chaque dashboard raconte une histoire légèrement différente — ce qui mine la confiance dans la donnée et empêche le self-service.

Pourquoi le glossaire métier est-il la fondation de la gouvernance des données ?

Parce que c’est la seule couche qui réconcilie la vision business et la vision technique. Le glossaire métier définit ce que signifie un terme dans le contexte de l’entreprise (un client, un produit actif, un chiffre d’affaires reconnu), avec un owner pour l’accountability et un steward pour la maintenance. Les couches techniques — tables, schémas, dashboards — viennent se brancher dessus via le lineage. Sans glossaire, la donnée technique n’a pas de sens partagé, et les analyses produites par différentes équipes deviennent incomparables.

Qu’est-ce qu’un data product et en quoi diffère-t-il d’une table de données ?

Un data product est un actif data documenté, fiable, traçable et réutilisable, avec un owner et un steward identifiés, des indicateurs de qualité mesurés, et un monitoring régulier. Là où une table de données est un objet technique sans propriétaire ni garantie, un data product est un actif d’entreprise avec une qualité contractualisée. Cette logique produit — par opposition à la logique projet — permet de maintenir un petit nombre d’actifs data partagés dans toute l’entreprise au lieu de multiplier les dashboards éphémères.

Comment Salomon a-t-il construit son programme de gouvernance des données ?

Salomon a procédé par itérations, en démarrant par un POC ciblé sur le périmètre e-commerce — le domaine avec le plus d’enjeux et de frictions. La méthode en cinq étapes a couvert le cadrage des données critiques, le cataloging dans un glossaire partagé, le lineage entre glossaire métier et dictionnaire technique via des connecteurs Snowflake, la qualité avec des règles documentées et des seuils d’alerte régionaux, et l’extension progressive aux autres domaines. La clé : prouver la valeur sur un périmètre restreint avant de scaler.

Quel est le lien entre langage commun, gouvernance des données et IA ?

Les mêmes fondations qui permettent le self-service BI permettent l’IA à l’échelle. Un agent IA qui interroge un data catalog bien gouverné via un serveur MCP hérite du contexte métier, des classifications de sensibilité, des règles d’accès. Un modèle entraîné sur un data product certifié hérite de sa qualité et de sa traçabilité. Sans langage commun ni gouvernance, les projets IA restent des POC isolés. Avec ces fondations, chaque initiative IA peut se brancher sur un socle déjà fiable et accélérer.

À propos de l'auteur: Skander Kouli

Lead Data Governance chez Salomon

Skander Kouli est Data Product Manager et Lead Data Governance chez Salomon. Il pilote les initiatives de gouvernance des données et de gestion des produits data afin d'améliorer la qualité, la fiabilité et la valorisation des données au sein de l'entreprise. Son expertise lui permet d'accompagner les équipes dans la mise en place de pratiques data efficaces, alignées sur les enjeux métier et les objectifs stratégiques de l'organisation.