Comment adopter Apache Ossie sans que vos définitions d'indicateurs divergent à nouveau

Pourquoi un même indicateur a-t-il encore un sens différent dans Power BI, Databricks et vos agents IA ?

Parce que chaque plateforme conserve sa propre copie de la logique, et que rien ne garde ces copies alignées. Le chiffre d'affaires net est une mesure DAX dans un modèle sémantique Power BI, une metric view dans Databricks, une requête SQL derrière un autre tableau de bord et, de plus en plus souvent, ce qu'un agent IA déduit des noms de colonnes. Chaque version était juste au moment où quelqu'un l'a écrite. Avec le temps, l'une exclut les commandes annulées et l'autre non.

Ossie décrit lui-même quatre symptômes : des indicateurs qui divergent d'un tableau de bord à l'autre, des rapprochements manuels coûteux, un ancrage peu fiable pour l'IA et des intégrations point à point complexes entre outils. Les agents IA rendent le troisième visible : un agent qui trouve trois mesures de chiffre d'affaires ne peut pas savoir laquelle la Finance a validée. Nous en parlons dans pourquoi votre chatbot IA donne d'autres chiffres que vos tableaux de bord Power BI.

Qu'est-ce qu'Apache Ossie, en termes simples ?

Apache Ossie est une spécification ouverte pour décrire des métadonnées sémantiques, afin que les indicateurs, les dimensions, les relations et le contexte métier circulent entre plateformes BI, analytiques et IA sans être reconstruits à la main.

Snowflake l'a lancé en septembre 2025 sous le nom d'Open Semantic Interchange (OSI), avec un groupe d'éditeurs BI, de catalogues et d'IA. La spécification a été publiée sous Apache 2.0 en janvier 2026. En juillet 2026, le projet a été accepté dans l'Apache Incubator et renommé Apache Ossie. Plus de 70 organisations figurent sur sa page écosystème, dont Snowflake, Databricks, Microsoft, Salesforce, dbt Labs, Qlik, ThoughtSpot et Tabular Editor. Databricks maintient des convertisseurs entre ses metric views et Ossie, et dbt Labs a publié MetricFlow en open source comme implémentation de référence.

Un modèle Ossie est un fichier YAML déclaratif composé de quatre éléments :

• Datasets : des entités métier qui correspondent à une table, une vue ou une requête.
• Fields : des attributs au niveau de la ligne, qui peuvent être marqués comme dimension ou dimension temporelle.
• Metrics : des agrégations, qui peuvent couvrir plusieurs datasets.
• Relationships : les clés de jointure entre datasets.

Les modèles, datasets, fields et metrics comportent chacun une description et un ai_context avec des instructions, des synonymes et des exemples pour les agents IA. Le détail le plus important pour l'adoption : un indicateur peut contenir son expression dans plusieurs dialectes, dont ANSI_SQL, DAX, DATABRICKS, SNOWFLAKE, TABLEAU, MDX et BIGQUERY. Les informations propres à un éditeur vont dans custom_extensions.

Ossie est encore en incubation et la spécification évolue. L'Apache Software Foundation précise que l'incubation ne reflète pas nécessairement le niveau d'achèvement ou de stabilité du code. C'est une raison de commencer par un ensemble limité d'indicateurs, pas une raison d'attendre. Pour en savoir plus : ossie.apache.org et la spécification sur GitHub.

Que normalise Ossie, et que vous laisse-t-il ?

Ossie normalise la façon d'écrire et d'échanger un indicateur. Il ne décide pas de ce que l'indicateur signifie, de qui en est responsable ni de qui approuve une modification.

Ce qu'Ossie vous apporte :

• une structure unique pour les indicateurs, les dimensions et les relations
• un indicateur avec une expression par plateforme
• des descriptions et du contexte IA dans le même fichier
• un format ouvert que tout éditeur peut lire et écrire

Ce qu'il vous laisse :

• convenir de ce que « chiffre d'affaires net » compte, et de ce qu'il exclut
• désigner la personne qui peut modifier cette définition
• approuver les modifications et en garder l'historique
• garder le sens métier et chaque expression de plateforme synchronisés

La spécification ne prévoit aucun champ pour la responsabilité, le stewardship, la certification ou l'approbation. C'est un choix logique pour un format d'échange, mais cela signifie qu'adopter Ossie n'est pas qu'un projet technique. Si deux départements ne sont pas d'accord aujourd'hui sur le chiffre d'affaires, écrire les deux versions en YAML ne réglera rien. Vous aurez simplement le désaccord dans un format plus propre.

Cet accord est la partie que la plupart des organisations sous-estiment, et il a généralement déjà un lieu : le glossaire métier, où un terme a une définition, un responsable et une trace d'approbation. Si vos KPI ne sont pas encore fixés, commencez par un KPI, une définition.

Qui doit être responsable des définitions Ossie : le métier ou l'IT ?

Les deux, chacun pour sa partie : le métier est responsable du sens, l'équipe data des expressions. Un responsable financier décide que le chiffre d'affaires net exclut la TVA et les commandes annulées. Un analytics engineer écrit cette règle en DAX pour le modèle Power BI et en SQL pour la metric view Databricks. Aucun des deux ne peut bien faire le travail de l'autre.

Le risque est de séparer les deux dans des endroits différents. Si la définition métier se trouve dans un wiki et les expressions uniquement dans un dépôt Git, personne ne remarque quand l'une change et pas l'autre. Gardez les deux dans un seul enregistrement, et faites passer toute modification de l'un ou de l'autre par la même revue du responsable. Ainsi, la phrase validée par la Finance et le code qui tourne dans chaque plateforme ne peuvent pas diverger discrètement.

Comment savoir si vos rapports suivent vraiment la définition Ossie ?

En les vérifiant, et en continuant à le faire, car publier une définition ne modifie pas les mesures qui existent déjà. La plupart des environnements Power BI contiennent déjà des dizaines de mesures et de metric views qui calculent une version de vos KPI principaux. Écrire la définition validée dans Ossie n'y change rien.

Et les écarts reviennent, pour des raisons très ordinaires :

• Mesures copiées : une équipe copie un modèle sémantique et adapte une mesure à un besoin local.
• Ajustements locaux : un analyste ajoute un filtre « juste pour ce rapport » en gardant le même nom.
• Nouveaux rapports : quelqu'un crée une nouvelle mesure de zéro au lieu de réutiliser celle qui a été convenue.
• Définitions modifiées : le responsable met la règle à jour, et les anciennes implémentations restent telles quelles.

Un audit ponctuel trouve les écarts d'aujourd'hui et manque ceux du mois prochain. Pour faire d'Ossie une définition réellement appliquée, et non un document publié une seule fois, comparez en continu les mesures cataloguées à la logique de calcul convenue, et signalez celles qui ne sont pas conformes pour que leurs responsables puissent agir.

Où conserver vos définitions Ossie ?

Pour la plupart des organisations, la réponse pratique est un glossaire métier pour le sens convenu et l'approbation, avec Git à côté pour les workflows d'ingénierie. Voici comment se comparent les principales options.

Git est excellent pour les ingénieurs : gestion de versions, revue de code et déploiement automatisé. Gardez-le. Ce qu'il n'offre pas, c'est un endroit où la Finance peut lire la phrase, la contester et l'approuver. Dans la pratique, on utilise souvent les deux : le glossaire comme enregistrement gouverné, et le YAML Ossie exporté dans Git pour les pipelines et les déploiements.

Un cadre pratique : convenir, traduire, approuver, publier, surveiller

• Convenir : le responsable métier et les utilisateurs de l'indicateur s'accordent sur la définition en langage clair dans le glossaire : ce qui est compté, à partir de quelle date, et ce qui est exclu.
• Traduire : l'équipe data écrit l'indicateur Ossie, avec une expression pour chaque plateforme utilisée, ainsi qu'une description et un contexte IA.
• Approuver : le responsable désigné approuve le sens et les expressions, et chaque modification est conservée dans l'historique.
• Publier : exportez la définition en YAML Ossie vers les plateformes et les agents IA qui en ont besoin.
• Surveiller : signalez les mesures et metric views qui ne sont plus conformes, pour que leurs responsables puissent les corriger.

Par où commencer

Ne commencez pas par tout votre modèle de données. Choisissez les 10 à 20 KPI qui font déjà débat, en général ceux du rapport de direction mensuel. Et ne partez pas d'une page blanche : les mesures et metric views que vous avez déjà montrent comment chaque KPI est calculé aujourd'hui, y compris là où les versions divergent.

1. Listez les KPI présents dans les rapports de direction et qui font débat.
2. Rassemblez les mesures DAX, metric views et requêtes SQL qui les calculent aujourd'hui.
3. Transformez ce que vous trouvez en un terme provisoire par KPI dans le glossaire, et désignez un responsable.
4. Laissez le responsable valider la définition, ajoutez les expressions Ossie et faites-les approuver.
5. Exportez ces termes en YAML Ossie et vérifiez les rapports existants par rapport à eux.

Quand le premier lot tient, ajoutez le suivant. Un petit ensemble de définitions auxquelles les gens font confiance vaut plus qu'un modèle complet sur lequel personne ne s'est mis d'accord.

La place de dScribe

Dans dScribe, la définition Ossie se trouve dans le terme du glossaire métier, à côté de la définition métier, du responsable et de l'historique d'approbation. Les métiers s'accordent sur le sens, l'équipe data ajoute les expressions de plateforme, et les deux vivent dans un seul enregistrement gouverné. Prenons un terme, Chiffre d'affaires net :

• Définition métier : « Chiffre d'affaires facturé après remises, hors TVA et hors commandes annulées. »
• Responsable : Finance.
• Historique d'approbation : chaque modification de la définition ou d'une expression, avec qui l'a approuvée et quand.
• Définition Ossie : l'indicateur avec une expression par plateforme, comme ci-dessous.

metrics:
  - name: net_revenue
    description: Invoiced revenue after discounts, excluding VAT and cancelled orders.
    expression:
      dialects:
        - dialect: ANSI_SQL
          expression: SUM(CASE WHEN orders.status <> 'cancelled' THEN orders.amount - orders.discount END)
        - dialect: DAX
          expression: CALCULATE(SUMX(orders, orders[amount] - orders[discount]), orders[status] <> "cancelled")
    ai_context:
      synonyms:
        - "net sales"
        - "revenue after discounts"

L'extrait est illustratif et suit la version provisoire actuelle de la spécification Ossie.

Voici le cycle de vie de ce terme dans dScribe :

1. Partir de l'existant. dScribe analyse la metric view « Net revenue » existante dans Databricks et propose un terme provisoire dans le glossaire.
2. Convenir et approuver. La Finance valide la définition métier et l'approuve.
3. Traduire et exporter. L'équipe data ajoute l'expression DAX, qui passe par la même revue du responsable que la définition métier. dScribe exporte le terme en YAML Ossie, seul ou avec un ensemble de termes.
4. Servir les agents IA. Un agent IA qui pose une question sur le chiffre d'affaires net obtient la définition approuvée, le responsable et la formule via le serveur MCP de dScribe.
5. Signaler les écarts. Une mesure « Net Revenue » dans un rapport Power BI régional inclut encore les commandes annulées. dScribe la signale comme non conforme au terme lié, pour que son responsable puisse la corriger avant que les chiffres divergent en réunion.

Le métier voit et approuve la phrase, l'équipe data maintient les expressions, et Power BI, Databricks et les agents IA lisent le même enregistrement approuvé. dScribe vous signale aussi quand un rapport s'en écarte. Les termes sont liés, et non copiés, aux datasets, colonnes et rapports qui les utilisent, grâce aux connecteurs pour Power BI, Microsoft Fabric, Databricks, Snowflake, dbt, Tableau, Qlik et Looker. La même définition apparaît dans la recherche dScribe, dans l'extension de navigateur sur les rapports Power BI et via l'API ouverte. Pour une vue d'ensemble, lisez comment créer une source de vérité unique pour les personnes et l'IA.

En résumé

Ossie donne à chaque plateforme le même langage pour un indicateur. Votre glossaire décide de ce que cet indicateur signifie, et vérifie que chaque rapport le suit toujours. Convenez d'abord de la définition, écrivez-la une fois avec une expression par plateforme, confiez les modifications à un seul responsable, et continuez à vérifier les mesures déjà en circulation.