.png){kind=logo}
La question n’est plus de savoir si nous avons besoin d’une interopérabilité sémantique, mais comment la rendre opérationnelle en pratique.
Le problème de l’interopérabilité n’est pas nouveau
À la fin des années 1990, le Data Mining Group (DMG) a créé PMML — Predictive Model Markup Language — une norme basée sur XML permettant de représenter et d’échanger des modèles prédictifs entre des plateformes d’analytique. Modèles de régression, réseaux de neurones, arbres de décision : PMML permettait d’exporter depuis un outil et d’importer dans un autre. Des solutions comme SAS, SPSS et les premières plateformes AutoML l’ont adopté avec succès dans certains cas d’usage de niche.
Mais PMML n’a jamais atteint une adoption universelle. La norme était complexe, la neutralité vis-à-vis des éditeurs s’est révélée difficile à maintenir, et les implémentations sont restées fragmentées selon les plateformes. PMML a fonctionné là où le périmètre était limité — des définitions de modèles portables entre outils compatibles — et a peiné partout où le périmètre était plus large.
À la même époque, l’initiative du Web sémantique promettait quelque chose de bien plus ambitieux. La vision de Tim Berners-Lee, formalisée via des standards du W3C comme RDF, OWL et SPARQL, visait à rendre l’ensemble du web lisible par les machines — des données porteuses de sens, pas seulement de structure. En 2009, lors d’un meetup à San Francisco où nous présentions les capacités AutoML de KXEN, j’ai demandé à des chercheurs ce qui viendrait après le Web 2.0. La réponse a été unanime : le Web sémantique — le Web 3.0¹.
Cette grande vision ne s’est jamais matérialisée comme prévu. Ajouter des métadonnées sémantiques était trop fastidieux, les incitations à l’adoption trop faibles, et l’approche trop académique pour accompagner la croissance organique du web. Les moteurs de recherche ont résolu une grande partie des mêmes problèmes de manière pragmatique, grâce à des méthodes statistiques et à des graphes de connaissances. Mais l’intuition de départ était juste : sans sémantique partagée, les machines ne peuvent pas interpréter les données de façon pertinente d’un système à l’autre.
Avançons jusqu’en septembre 2025 : Snowflake réunit l’industrie autour de l’Open Semantic Interchange (OSI), une norme ouverte destinée à partager des métadonnées sémantiques entre plateformes de données. Même promesse fondamentale, époque différente. Cette fois, il existe un facteur de contrainte que PMML et le Web sémantique n’avaient pas : l’IA a besoin de cohérence sémantique pour fonctionner.
Pourquoi cela compte maintenant : la couche sémantique comme socle de l’IA
Aujourd’hui, les organisations utilisent des dizaines d’outils d’analytique — plateformes BI, data warehouses, agents IA, systèmes de reporting — chacun avec sa propre interprétation des concepts métier. « Chiffre d'affaires » signifie une chose pour le Marketing, une autre pour la Finance, une troisième pour les Ventes. Les tableaux de bord affichent des chiffres contradictoires en comité de direction. Personne n’a tort, mais personne n’est d’accord.
Une couche sémantique résout ce problème en créant une couche unique gouvernée, où les métriques métier sont définies une seule fois dans le code et consommées de manière cohérente partout. Définissez « chiffre d'affaires » une fois — en incluant sa logique de calcul, ses relations dimensionnelles, sa granularité temporelle et ses contrôles d’accès — et chaque outil, chaque analyste, chaque agent IA utilisera la même définition. La mise en cache via pré-agrégation offre des performances en moins d’une seconde. La sécurité au niveau des lignes et des colonnes applique la gouvernance au niveau de l’infrastructure, plutôt que d’espérer que chaque outil l’implémente correctement.
La direction doit pouvoir faire confiance aux données pour prendre des décisions en confiance. Des définitions sémantiques universelles répondent directement à cet enjeu : elles ne se contentent pas d’améliorer la cohérence, elles évitent les écarts de compréhension métier qui ralentissent les projets et fragilisent la prise de décision.
L’arrivée de l’IA aggrave le problème de façon exponentielle. Les tableaux de bord traditionnels affichent passivement des chiffres contradictoires — quelqu’un finit par repérer l’écart. Les agents IA, eux, présentent des chiffres contradictoires avec assurance, à grande échelle, avec des explications qui paraissent autoritaires. Comme l’a indiqué l’analyste Gartner Rita Sallam dans ses prévisions 2025, les organisations qui priorisent la modélisation sémantique augmenteront la précision de l’IA de 80 % et réduiront les coûts de 60 %. Sans ancrage sémantique, on n’obtient pas de l’intelligence : on obtient une confusion sûre d’elle, automatisée.
C’est dans ce contexte qu’émerge OSI — non pas comme un exercice universitaire, mais comme une réponse de l’industrie à un problème rendu urgent par l’IA.
OSI : ce que c’est, qui le porte, et où cela en est
La spécification
OSI s’appuie sur un format YAML déclaratif, développé en collaboration avec le framework MetricFlow de dbt Labs. La spécification définit des modèles sémantiques comme des conteneurs de premier niveau comprenant des jeux de données, des relations, des mesures, des dimensions et — point crucial à l’ère de l’IA — des métadonnées de contexte.
Figure 1 : Flux OSI — Définir la couche sémantique une seule fois en YAML, la consommer de manière cohérente dans les outils et les agents IA
Les datasets représentent des entités métier logiques (tables de faits et de dimensions), avec leurs champs, clés primaires et correspondances vers les sources. Les measures définissent des calculs quantitatifs (sommes, moyennes, ratios) pouvant s’étendre sur plusieurs datasets. Les dimensions sont des attributs catégoriels permettant de segmenter/analyser les données. Les relationships précisent la logique de jointure et la cardinalité entre les datasets.
Ce qui distingue OSI des précédentes tentatives de standardisation, c’est l’existence explicite du champ ai_context — une section dédiée du YAML dans laquelle vous fournissez des instructions en langage naturel aux agents IA qui consomment le modèle. C’est ici que vous dites à un agent IA : « Utilise ce modèle sémantique pour l’analytique retail. Il prend en charge l’analyse temporelle, la segmentation client et la performance produit. » Ce n’est pas de la métadonnée décorative : c’est le pont entre des définitions structurées et la compréhension en langage naturel dont les LLM ont besoin pour interroger les données avec précision.
La promesse : définir une fois, utiliser partout — à travers les outils BI, les agents IA et les plateformes d’analytique. Le tout sous licence Apache 2.0, et conçu pour être neutre vis-à-vis des éditeurs.
Un modèle sémantique simple ressemble à ceci :
semantic_model:- name: retail_modeldescription: Retail semantic model for sales analyticsai_context:instructions: "Use this model for retail analytics.Supports time-based analysis and customer segmentation."datasets:- name: store_salessource: schema.store_salesprimary_key: [item_id, ticket_number]measures:- name: order_totalexpression: SUM(store_sales.sale_price)dimensions:- name: order_datetype: timetype_params:time_granularity: day
Point important : une réserve à garder en tête
Même si la spécification OSI définit des champs comme ai_context, dialect et synonyms, ceux-ci ne sont pas encore pris en charge dans MetricFlow. Lorsque je les ai testés dans ma stack, dbt a renvoyé une erreur de parsing : « Additional properties are not allowed ('ai_context', 'dialect', 'synonyms' were unexpected). » La spécification OSI a une longueur d’avance sur les outils : la vision est définie, mais les implémentations n’ont pas encore rattrapé leur retard.
Chronologie
Snowflake mérite un crédit significatif pour avoir fédéré l’écosystème autour de cette initiative. Le passage du concept à la spécification a été rapide :
- Février 2023 — dbt Labs acquiert Transform, intégrant MetricFlow à l’écosystème dbt.
- 23 septembre 2025 — Snowflake lance OSI avec des partenaires fondateurs : Salesforce (Tableau), dbt Labs, BlackRock, Alation, Atlan, Cube, Hex, Honeydew, Mistral AI, Omni, RelationalAI, Select Star, Sigma, ThoughtSpot, et d’autres.
- 14 octobre 2025 — dbt Labs open-source MetricFlow sous licence Apache 2.0 lors de Coalesce 2025. Ce changement de licence est déterminant : MetricFlow était auparavant sous AGPL puis sous BSL (Business Source License), deux licences qui restreignent l’usage commercial et les travaux dérivés. Passer à Apache 2.0 signifie que tout éditeur peut s’appuyer sur MetricFlow sans contraintes juridiques — un engagement réel pour qu’OSI soit porté par la communauté, et non contrôlé par dbt.
- 17 octobre 2025 — Première session du groupe de travail dans les bureaux de Snowflake à Menlo Park.
- Novembre 2025 — Starburst rejoint l’initiative.
- Décembre 2025 — Collibra, DataHub et Strategy (anciennement MicroStrategy) rejoignent l’initiative.
- 27 janvier 2026 — Publication de la spécification OSI v1.0 sur GitHub. De nouveaux membres rejoignent, notamment Databricks, AtScale, Qlik, JetBrains, Lightdash, Coalesce et Credible.
- 3 février 2026 — Collate rejoint l’initiative.
La séquence de janvier est révélatrice : la conviction progresse nettement dans l’industrie. Databricks, initialement absent, a rejoint l’initiative en même temps que la publication de la spécification. Le cas d’AtScale est particulièrement instructif : au départ, l’éditeur adoptait une posture distante, en mettant en avant son propre Semantic Modeling Language (SML) comme une approche plus complète. En janvier, AtScale a rejoint l’initiative. Ce type d’engagement critique suivi d’une participation est un signe de maturité : des éditeurs qui ne rejoignent pas par effet de mode, mais après avoir évalué la spécification sur le fond et reconnu l’intérêt de contribuer de l’intérieur plutôt que de concurrencer de l’extérieur.
La suite
La roadmap d’OSI anticipe trois phases. Nous sommes actuellement en Phase 1 (T4 2025 – T1 2026) : finalisation de la spécification, implémentations de référence et mise en place d’une gouvernance communautaire — en grande partie accomplies avec la publication de la spécification en janvier 2026. La Phase 2 (T2 – T4 2026) vise une adoption plus large avec un support natif dans plus de 50 plateformes, des extensions spécifiques à certains domaines, et des programmes pilotes avec des early adopters. La Phase 3 (2027 et au-delà) projette OSI comme un standard de facto de l’industrie, avec une possible reconnaissance internationale et une marketplace de modèles sémantiques partagés.
Absences notables
Microsoft reste de manière frappante absent. Étant donné la position dominante de Power BI sur le marché — leader du Magic Quadrant Gartner — cette non-participation crée un manque significatif. SAP, IBM et Oracle — tous dotés d’un héritage solide en matière de couche sémantique dans leurs plateformes BI — sont également absents. Côté acteurs majeurs de l’IA, seul Mistral AI participe ; OpenAI, Anthropic et Google Gemini ne sont pas impliqués.
De la spécification à la pratique : tester OSI dans ma Modern Data Stack
Lire des spécifications, c’est utile. Les exécuter, c’est mieux. Dans ce projet open source de modern data stack (Trino, dbt, Cube.js, Metabase — le tout orchestré via Docker Compose), j’avais défini des métriques dans Cube.js : calculs de chiffre d'affaires, nombre de commandes, découpages par dimensions. Ajouter MetricFlow signifiait définir ces mêmes concepts métier une seconde fois, dans une seconde syntaxe. OSI promet précisément d’éliminer ce type de duplication.
L’intégration de dbt MetricFlow a nécessité une infrastructure spécifique. Une table time spine est obligatoire — MetricFlow a besoin d’une table de dates continue pour ancrer les calculs temporels. Les dimensions préfixées par entité suivent une convention de nommage distincte (order_id__customer_name plutôt que simplement customer_name). La syntaxe YAML est plus verbeuse que les définitions JavaScript de Cube.js, mais elle est déclarative et versionnable.
Voici ce que j’ai défini dans MetricFlow pour mon modèle sémantique des commandes :
semantic_models:
- name: orders
defaults:
agg_time_dimension: order_date
model: ref('fct_orders')
entities:
- name: order_id
type: primary
measures:
- name: order_total
agg: sum
expr: revenue
- name: order_count
agg: count
expr: order_id
- name: total_revenue
description: "Sum of order amounts"
agg: sum
expr: revenue
agg_time_dimension: order_date
dimensions:
- name: order_date
type: time
expr: order_date
type_params:
time_granularity: day
Et je l’ai validé en le comparant aux mêmes métriques exposées via Cube.js. Chiffre d'affaires total : 12 629,50 $ dans les deux outils. 
Figure 3 : Les résultats du playground Cube.js sont identiques.
Les définitions sémantiques sont cohérentes. Les calculs sont justes. OSI permettrait, en théorie, de définir cela une seule fois et de laisser les deux outils consommer le même modèle. Mais c’est là que mon test s’est arrêté — et c’est normal : ce n’est pas une critique. La spécification v1.0 a été publiée le 27 janvier 2026. L’adoption en Phase 2 et le support natif par les plateformes sont prévus pour T2–T4 2026. Aucun éditeur n’a encore livré d’outillage d’import, tout simplement parce que la spécification vient à peine d’être disponible. Les fondations sont posées ; l’outillage d’interchange vient ensuite.
La route vers le succès : comment OSI doit évoluer
Le problème des 80/20
Les métriques simples de ma stack de démonstration — sommes, décomptes, moyennes ventilées par le temps et par catégorie — se modélisent naturellement en YAML. Elles représentent peut-être 80 % de l’analytique classique. Mais les 20 % restants, c’est là que vivent les entreprises, et c’est là qu’OSI a encore beaucoup de terrain à couvrir.
Prenons la couverture de stock (Stock Coverage) — une métrique que j’ai mise en place pour une grande entreprise, et qui répond à une question en apparence simple : combien de mois de demande prévisionnelle le stock actuel peut-il couvrir ?
Le calcul nécessitait de relier trois domaines de données distincts : le stock côté Supply Chain, les prévisions de ventes issues de la consolidation financière, et les attributs produits provenant d’un catalogue de référence. Il utilisait des fonctions de fenêtre avec des décalages variables sur un horizon de 24 mois — en calculant les prévisions cumulées période par période, puis en comparant le stock à ces seuils via une logique conditionnelle lourde. Certaines dimensions ne s’appliquaient qu’au stock (et pas aux prévisions), ce qui imposait un contrôle précis de la dimensionalité au niveau de chaque mesure. Des attributs classaient les centres de distribution (« Stock Corporate » vs « Stock Local »), des filtres de sécurité restreignaient la visibilité par zone géographique, et des périodes de prévision manquantes risquaient d’introduire des distorsions silencieuses. Point crucial : cette métrique devait fonctionner de manière interactive dans des dashboards — filtres ad hoc, drill-down, découpes temporelles dynamiques.
La métrique finale reposait sur une cascade de conditions sur l’horizon, avec un mécanisme de repli basé sur une moyenne lorsque le stock dépassait la période totale de prévision. Exprimer tout cela de façon complète et portable dans l’OSI actuel, basé sur YAML, est difficile.
Ce n’est pas un cas théorique : c’est le quotidien de la BI en entreprise. Fonctions de fenêtre, agrégations conditionnelles, calculs multi-domaines avec des sémantiques dimensionnelles variables, logique d’horizon dynamique. La spécification OSI gère bien les fondations, mais les discussions de la communauté sur GitHub (notamment #29 et #19) pointent déjà des lacunes critiques : pas de mesures au niveau dataset, pas de hiérarchies de dimensions, des expressions de métriques sous forme de chaînes qui limitent la compatibilité cross-plateformes, aucune distinction entre métriques additives et non additives, et un traçage de lignage limité pour les calculs dérivés.
Le “fossé” de la couche sémantique sur le marché actuel
OSI doit aussi composer avec un défi structurel — qui commence par la plateforme BI la plus largement déployée. Microsoft Power BI, leader du Magic Quadrant Gartner 2025 pour les plateformes d’Analytics et de BI, possède une couche sémantique. Mais la logique métier — mesures DAX, calculs, relations — vit à l’intérieur de modèles sémantiques individuels, et cette logique n’est pas partageable de manière modulaire entre eux. Dans les déploiements enterprise, le schéma courant « un dataset par rapport » crée des problèmes de contrôle de version, des calculs dupliqués, des KPI incohérents, et dégrade la confiance dans les données — comme l’illustrent de nombreuses analyses de projets à grande échelle.
Au-delà de ces enjeux internes, il y a la réalité multi-plateformes. Comme le souligne SQLBI, Power BI définit la logique métier via DAX — un langage propriétaire spécifique à l’écosystème Microsoft. Le Magic Quadrant Gartner 2025 note Power BI comme « limité à la stack Azure », et l’analyste indépendant Aurimas Račas a documenté que, même si Power BI joue le rôle de couche sémantique en interne, il ne peut pas servir de couche universelle pour d’autres outils BI : ses définitions ne “voyagent” pas en dehors de l’écosystème Microsoft.
Ce n’est pas un problème propre à Power BI — c’est un schéma industriel. La plupart des plateformes BI ont développé leurs capacités sémantiques comme des fonctionnalités embarquées, pas comme une infrastructure interopérable. Dans les grandes organisations qui utilisent plusieurs plateformes, cela crée de la duplication, de l’incohérence et de la dette technique. Des outils de couche sémantique indépendants comme AtScale, Cube, Mosaic de Strategy et d’autres répondent déjà à ce besoin : fournir une couche gouvernée au-dessus (ou à côté) de plateformes qui n’offrent pas une portabilité universelle. Le succès d’OSI dépend en partie de sa capacité à relier ces environnements hétérogènes — des organisations qui utilisent trois ou quatre outils BI, avec des capacités sémantiques différentes, et qui ont besoin d’un format d’échange commun précisément parce que leurs outils ne s’accordent pas aujourd’hui.
Tirer les leçons du passé
Chaque initiative de standardisation enseigne la même chose : la syntaxe est la partie facile, l’adoption est tout. PMML a réussi dans un périmètre étroit mais n’a jamais été adopté universellement — freiné par sa complexité et des implémentations fragmentées. Le Web sémantique a produit des technologies fondatrices (les graphes de connaissances alimentent aujourd’hui Google Search) mais a échoué comme standard universel, parce que le coût d’adoption dépassait le bénéfice perçu pour la majorité des acteurs.
OSI dispose d’atouts que ses prédécesseurs n’avaient pas : un puissant facteur de contrainte de marché (l’IA exige de la cohérence sémantique), le soutien de grands éditeurs qui ont des incitations commerciales, et une implémentation existante (MetricFlow) plutôt qu’une simple spécification. Mais OSI fait face à des risques familiers. Les discussions de la communauté soulèvent des points légitimes : le risque d’un standard “plus petit dénominateur commun” qui ne couvre que les cas simples, et le défi politique d’obtenir d’éditeurs concurrents un investissement réel dans l’interopérabilité, plutôt qu’un soutien de façade.
Le joker IA
Il existe un contre-argument intéressant : peut-être que l’IA rend les standards sémantiques manuels moins critiques. Si les LLM peuvent interpréter le contexte à la volée, a-t-on besoin que des humains écrivent du YAML ? Peut-être que l’avenir passera par une couche d’orchestration — un agent ancré dans la connaissance organisationnelle (via RAG) qui travaille aux côtés d’un agent “OSI-aware” pour l’interopérabilité structurelle. Des sémantiques curées par des humains et un contexte interprété par l’IA, se complétant.
Mais cela reste théorique à ce stade. Aujourd’hui, une IA sans ancrage sémantique hallucine. Le standard est important précisément parce que l’IA n’est pas encore capable d’inférer de façon fiable le contexte métier.
Où va-t-on maintenant ?
OSI est la tentative la plus crédible d’interopérabilité sémantique que l’industrie des données ait produite. L’initiative de Snowflake pour réunir cette coalition — et la vitesse à laquelle l’écosystème a grandi — signalent un véritable appétit du marché pour résoudre la fragmentation sémantique. Le timing est bon, la coalition d’éditeurs est large (et s’élargit), et le facteur de contrainte — le besoin de cohérence sémantique pour l’IA — est réel.
La v1.0 marque le passage de l’annonce à la substance. La Phase 2 en 2026, avec un support natif attendu sur plus de 50 plateformes, sera le vrai test. D’ici 2027, l’initiative vise un statut de standard de facto. C’est ambitieux, mais plausible au regard de la dynamique actuelle.
Ma position est prudemment optimiste, basée sur la reconnaissance de schémas. PMML promettait l’interchange de modèles et l’a livré partiellement — une valeur durable, avec un périmètre plus étroit que prévu. Le Web sémantique promettait un web “porteur de sens” et a produit des graphes de connaissances — une technologie transformative, sous une forme différente de celle imaginée. Les deux ont eu un impact réel, mais pas exactement comme annoncé.
OSI suivra probablement une trajectoire similaire : une valeur immense pour établir un vocabulaire commun, une interopérabilité réelle pour les 80 % de métriques les plus simples, et la persistance de solutions spécifiques aux plateformes pour les 20 % complexes. La question est de savoir si l’industrie maintiendra son engagement pendant le creux inévitable qui suit toutes les initiatives de standardisation — et si l’outillage de Phase 2 concrétisera la promesse de la spécification de Phase 1.
En pratique, le message actionnable est clair : apprenez dbt MetricFlow dès maintenant. C’est le socle d’implémentation d’OSI. Que le standard atteigne ou non une adoption totale, la maîtrise de MetricFlow se traduit directement en compétences “couche sémantique” que toute modern data platform valorisera. Mon repo de modern data stack inclut une implémentation MetricFlow fonctionnelle que vous pouvez exécuter en local — un point de départ concret.
J’observe de près quel éditeur sera le premier à livrer un véritable outillage d’import OSI pendant la Phase 2 cette année. Ce sera le signal qui fera passer OSI du standard à la pratique. D’ici là, je continue à tester, documenter et construire — parce que la couche sémantique, quel que soit le standard qui s’impose, est la fondation dont l’IA a besoin pour fonctionner réellement.
OSI pose les bases d’une interopérabilité sémantique : définir les métriques une fois, les réutiliser partout (BI et IA). Le prochain enjeu sera l’outillage et l’adoption des plateformes en 2026. En attendant, renforcer ses compétences en couche sémantique — notamment via MetricFlow — reste un choix concret pour fiabiliser les KPI et les usages IA.
Sources (FR)
- PMML (Predictive Model Markup Language) — DMG, archive officielle (v4.4) : https://dmg.org/pmml/pmml-v4-4.html
- Semantic Web (Web sémantique) — Wikipedia : https://en.wikipedia.org/wiki/Semantic_Web
- Open Semantic Interchange (OSI) — site officiel : https://open-semantic-interchange.org/
- OSI — dépôt GitHub : https://github.com/open-semantic-interchange/OSI
- Snowflake — annonce OSI : https://www.snowflake.com/blog/open-semantic-interchange/
- Snowflake — spécification OSI finalisée : https://www.snowflake.com/en/blog/open-semantic-interchanges-specs-finalized/
- dbt Labs — MetricFlow en open source : https://www.getdbt.com/blog/metricflow-open-source
- Gartner — Magic Quadrant for Analytics and BI Platforms (June 2025) : https://www.gartner.com/en/documents/6234651
- TechTarget — Agents & semantic layers parmi les top trends data/analytics : https://www.techtarget.com/searchbusinessanalytics/feature/Agents-semantic-layers-among-top-data-analytics-trends
- SQLBI — “Power BI is a Model-Based Tool” : https://www.sqlbi.com/articles/power-bi-is-a-model-based-tool/
- Aurimas Račas — “Metrics Layers and Power BI” : https://aurimas.eu/blog/2022/08/metrics-layers-and-power-bi/
- AtScale — AtScale rejoint OSI : https://www.atscale.com/blog/atscale-joins-osi-open-semantic-infrastructure/
- Starburst — Starburst rejoint OSI (communiqué) : https://www.starburst.io/press-releases/starburst-teams-up-with-snowflake-and-industry-leaders/
- Qlik — Qlik rejoint OSI : https://www.qlik.com/blog/qlik-joins-snowflake-led-open-semantic-interchange-to-bring-consistent
- ThoughtSpot — OSI & “agentic semantic layer” : https://www.thoughtspot.com/blog/the-agentic-semantic-layer-and-OSI
- Strategy — Strategy rejoint OSI (Business Wire) : https://www.businesswire.com/news/home/20251202153508/en/Strategy-Joins-Open-Semantic-Interchange
- Collate — Collate rejoint OSI : https://www.getcollate.io/blog/collate-joins-snowflake-and-industry-leaders-to-advance-open-semantic-interchange-osi-for-data-and-ai-interoperability
- Modern Data Stack — repository (démo MetricFlow) : https://github.com/vincevv017/modern-data-stack
Note (FR)
¹ À l’origine : “Semantic Web”. Aujourd’hui, “Web3” renvoie le plus souvent à la blockchain et à la propriété décentralisée.
