Ontologie d'entreprise ouverte : qui doit posséder la couche sémantique du métier ?

En bref : La couche de définition métier dont dépendent vos applications, vos agents, vos auditeurs — et désormais plusieurs fournisseurs — ne devrait appartenir à aucune plateforme. Elle devrait être une couche neutre que vous conservez dans votre propre dépôt.

Commençons par l’histoire d’une entreprise qui a perdu un client à cause de cela. Les détails ont été anonymisés, mais chaque étape vous est probablement familière.

Yuanfeng est un fabricant d’équipements industriels, plusieurs milliards de chiffre d’affaires annuel, des milliers de clients. En 2024, il a misé son socle de données sur Microsoft et bâti dans Fabric une ontologie propre : ce qu’est un « client », quels « équipements » lui sont rattachés, quels « tickets d’intervention » dépendent de chaque « équipement » — le tout défini avec une parfaite netteté. Cette année-là, il était le cas d’école cité en boucle au sommet des fournisseurs.

En 2026, trois choses se sont abattues sur Yuanfeng presque simultanément :

• l’équipe data science a voulu faire tourner une série de prédictions de renouvellement avec Gemini, parce que sur ce cas précis il était effectivement plus précis ;
• le service conformité a reçu notification que les données des clients européens devaient rester dans l’UE et ne plus transiter par le cloud américain ;
• une acquisition s’est conclue, apportant toute une organisation commerciale de plusieurs milliers de clients tournant sur Salesforce.

Yuanfeng s’est donc retrouvé avec trois « clients » : un dans Fabric, un dans Salesforce, et un troisième dans l’environnement européen isolé pour la conformité.

Le tournant de l’histoire s’est joué sur un grand compte stratégique, le « groupe H ». Un jour, le directeur commercial a demandé à l’agent : « Quel est le risque de non-renouvellement du groupe H l’an prochain ? » L’agent a répondu : « Faible. » — car il était branché sur l’ontologie Fabric, où les commandes récentes du groupe H étaient saines et les chiffres flatteurs.

Mais ce que l’agent ne voyait pas, c’était ceci : dans la fiche Salesforce (issue de l’acquisition), le groupe H avait escaladé deux fois en six mois une réclamation jusqu’au niveau exécutif ; et dans l’environnement européen isolé, traînait un litige de recouvrement vieux de 90 jours. Trois jeux de données rattachés à trois « clients » qui s’ignoraient mutuellement, et aucune couche ne savait qu’il s’agissait en réalité du même groupe H.

Un trimestre plus tard, le groupe H est parti, plusieurs millions de pertes annuelles. La conclusion du post-mortem était d’une lucidité à faire taire la salle : l’agent n’avait techniquement commis aucune erreur — la donnée qu’il voyait indiquait bel et bien un risque faible. Le fautif n’était pas le modèle, c’était la définition du « client » sous ses pieds, découpée en trois morceaux.

Ce n’est pas une bévue de Yuanfeng. C’est la conséquence inévitable de confier « la définition de son métier » à la garde d’une plateforme — et chaque plateforme ne garde que sa propre part.

Pas un cas isolé : tout le monde se rue sur cette couche

Si la situation de Yuanfeng est si répandue, c’est parce que tout le secteur converge vers la même couche.

Il y a peu, « couche sémantique métier / ontologie » semblait encore être surtout le vocabulaire propre à Palantir. Aujourd’hui, les grandes plateformes cloud, data et IA parlent toutes de couches sémantiques, de graphes de connaissances et de définitions métier lisibles par machine. Microsoft pousse Fabric IQ, Google met le graphe de connaissances d’entreprise sur la table, et Palantir continue de vendre Foundry en l’arrimant à l’IA opérationnelle.

Pourquoi maintenant, précisément ? Parce que l’agent a crevé l’abcès. La décennie de pipelines de données ne s’est souciée que de « où coule la donnée », pas vraiment de « ce que cette donnée signifie » — de toute façon, l’humain rattrapait en bout de chaîne. L’agent n’a pas ce filet humain : face à des dizaines de tables et à des champs « client » aux définitions discordantes, soit il répond faux (comme pour le groupe H), soit il n’ose pas répondre. Beaucoup de pilotes d’agents meurent en grande partie sur cette couche manquante.

Le jugement des trois géants est donc juste, et hautement convergent : pour que l’IA entre de façon fiable dans l’entreprise, il faut d’abord une couche de définition métier lisible par la machine et gouvernée. Cela ne se discute plus. Ce qui mérite vraiment d’être débattu, c’est la question suivante : à qui doit appartenir cette couche.

Trois bonnes directions, trois verrous différents

En étalant les trois solutions côte à côte, on tombe sur un point commun gênant.

	Où réside l’ontologie	Qui peut la lire	Pouvez-vous l’emporter
Palantir Foundry	Dans la plateforme Palantir	Ingénieurs sur site + outils de la plateforme	Lié à la plateforme, migrer = tout refaire
Microsoft Fabric IQ	Dans OneLake / Fabric	Écosystème 365 et Fabric	Lié à la pile Microsoft
Graphe de connaissances Google	Dans Google Cloud	Écosystème Vertex et GCP	Lié à la pile Google

Soyons justes : chacun fait du très bon travail sur son propre terrain. La qualité de modélisation ontologique de Palantir est réellement élevée ; Microsoft soude la couche sémantique dans OneLake et 365, ce qui, pour une entreprise 100 % Microsoft, se fait presque sans la moindre friction ; et Google a un vrai savoir-faire sur l’échelle des données et le raisonnement sur graphe. Tous vous aident à mettre votre métier au clair — puis verrouillent cette clarté dans leur propre plateforme.

Les vétérans de l’IT auront ici un réflexe : encore du verrouillage fournisseur, vieux problème.

Mais cette fois, le verrouillage n’est pas le plus inquiétant. Cette fois, il y a un nouveau problème, bien pire. Avant de le démonter, il faut d’abord exposer sérieusement le scénario par lequel les plateformes fermées gagnent — car il n’est pas faible.

D’abord, le scénario gagnant des plateformes fermées

Crier « l’ouverture, c’est bien » relève de la prédication, pas de l’analyse. Les plateformes fermées ont quatre cartes maîtresses bien réelles :

Premièrement, la qualité de modélisation. Digérer vingt ans de systèmes pourris accumulés par une grande entreprise pour en faire une ontologie propre et cohérente est une ingénierie extrêmement lourde. Palantir aligne, concept par concept, grâce à ses ingénieurs sur site ; à court terme, aucune communauté open source ne peut rivaliser sur la qualité. Une ontologie, mal bâtie, vaut moins que pas d’ontologie du tout.

Deuxièmement, un responsable qui répond de tout. En cas de pépin, il y a quelqu’un qui décroche le téléphone, un SLA, un contrat qui couvre. Pour un DSI, « un fournisseur unique qui porte la responsabilité de toute la couche » a une valeur en soi — c’est le fameux one throat to choke.

Troisièmement, beaucoup d’entreprises sont effectivement « presque tout chez un seul ». Si la majorité de votre activité tient dans un seul écosystème, alors « le meilleur de l’écosystème » peut être l’optimum réel, et les bénéfices de l’ouverture peuvent rester théoriques.

Quatrièmement, la profondeur d’intégration. Au sein du même écosystème, données, identités et permissions sont déjà là ; le sale boulot épargné se compte en hommes-mois.

Ces quatre cartes sont réelles. La conclusion n’est donc pas « les plateformes fermées sont des pièges » — pour les entreprises qui remplissent leurs prémisses, elles sont souvent la bonne réponse. Le problème surgit chez les entreprises comme Yuanfeng : leurs prémisses, justement, sont en train de se dissiper.

Cette fois, le scénario a une nouvelle faille : la fragmentation

Avec le verrouillage d’un fournisseur unique, votre définition métier reste au moins une seule pièce complète, simplement intransportable. Douloureux, mais complet.

Trois géants construisant simultanément des ontologies fermées fabriquent tout autre chose : la fragmentation. Le « client » de Yuanfeng n’est pas verrouillé, il est découpé en trois, chaque part gisant dans une des trois plateformes qui s’ignorent. C’est bien plus pénible que le verrouillage, et c’est pénible à juste titre — deux mécanismes font qu’il est peu probable que cela se résorbe tout seul :

Premier mécanisme : l’intérêt. Vous vous direz peut-être : il suffirait que l’ontologie de Microsoft comprenne le « client » de Salesforce, non ? Non, car aucun acteur n’a d’incitation à le faire. L’ontologie de chacun est sa douve. Si Microsoft unifiait de lui-même la sémantique « client » entre lui et Salesforce, il aiderait de ses propres mains son concurrent à déplacer ses données plus facilement et se banaliserait lui-même. Unifier est, pour chaque concurrent, un acte d’automutilation. Ce n’est pas une négligence technique, c’est un choix rationnel — alors compter sur l’un d’eux pour réparer la fragmentation est illusoire.

Second mécanisme : la technique. Même en mettant l’intérêt de côté, l’alignement sémantique inter-ontologies est en soi un problème non résolu : le « client » du système A est-il égal au « Account » du système B ? La définition des champs, le cycle de vie, les règles de dédoublonnage, ce qui compte comme « même entité » — tout diffère de part et d’autre. Et l’IA ne peut pas le faire automatiquement de façon fiable — au contraire, c’est précisément l’absence de cette couche de définition certaine qui fait que les agents se trompent. Retour au groupe H : laisser l’agent deviner tout seul si « ces trois fiches sont la même entreprise », c’est risquer ces millions le jour où il devine faux.

En une phrase : vous pensiez avoir acheté trois outils, vous avez en réalité acheté trois « sources de vérité » qui s’ignorent. Plus il y a de systèmes, d’acquisitions, d’isolations de conformité, plus cette fragmentation s’aggrave — et l’ère de l’agent en amplifie justement le coût, car le cerveau humain peut encore aligner tant bien que mal trois systèmes à la main, mais pas l’agent : il lui faut une couche de définition certaine et cohérente entre systèmes pour raisonner.

Pour empêcher la fragmentation, il n’y a logiquement qu’une issue : la définition du métier ne peut appartenir à aucune des plateformes en lice ; elle doit être une couche neutre — une définition que vous détenez vous-même et que les outils des trois peuvent lire. Les plateformes fermées ne peuvent structurellement pas l’offrir : elles sont les concurrentes de la course, elles ne peuvent pas être en même temps l’arbitre.

Comment savoir si vous êtes en train d’être fragmenté

Ce n’est pas abstrait, il y a des symptômes précoces très concrets. Confrontez-vous aux points suivants ; si trois ou plus s’appliquent, la fragmentation est déjà à l’œuvre dans votre entreprise :

1. Un même « client / commande / équipement » a des définitions différentes selon les systèmes, ne correspond pas d’un système à l’autre, et il faut tout réconcilier à la main à chaque reporting.
2. Quand vous posez à l’agent une question transversale, soit il reste vague, soit il n’a raison qu’à moitié (il a vu un système, pas l’autre).
3. Chaque intégration d’un nouveau système vous oblige à réapprendre à l’IA « ce que c’est, ce que signifient les champs ».
4. Une acquisition remonte à plus d’un an et les données de référence des deux côtés ne sont toujours pas réellement fusionnées : chacun reporte de son côté.
5. La conformité exige d’isoler une certaine catégorie de données, si bien que la même entité se retrouve stockée en plusieurs exemplaires qui s’ignorent.

Avant de perdre le groupe H, Yuanfeng en cochait quatre sur cinq. À l’époque, on les traitait comme des « tâches de gouvernance des données à faire », sans réaliser que c’était une mine que l’agent finirait tôt ou tard par faire exploser.

D’abord une douche froide : l’ouverture n’est pas une formule magique

Il faut s’arrêter ici honnêtement, sinon cela devient du baratin de camelot.

Premièrement, remplacer la définition par un protocole ouvert ne fusionnera pas automatiquement les trois « clients » de Yuanfeng en un seul. La modélisation sémantique, le dédoublonnage, l’alignement des définitions restent à faire — il n’y a pas de formule magique sur cette partie, méfiez-vous de quiconque le prétend. Ce que l’ouverture change réellement, c’est la propriété de ce sale boulot : la définition que vous alignez aujourd’hui à la sueur de votre front est inscrite dans votre propre dépôt, et non sédimentée dans le back-office d’une plateforme. L’an prochain, quand vous changerez de modèle, de cloud, ou serez racheté, ce que vous referez, ce sont les connecteurs, pas la définition elle-même.

Deuxièmement, l’« ouverture » en soi ne garantit pas non plus la victoire. Historiquement, pour qu’un standard ouvert l’emporte vraiment, il faut souvent en plus une implémentation de référence suffisamment bonne et un écosystème actif — un protocole simplement publié mais que personne ne rend utilisable peut tout aussi bien tomber à l’eau. Choisir l’ouvert, c’est donc parier que « quelqu’un le rendra solide » : un jugement assorti d’un risque d’exécution, pas une victoire garantie.

Mais notez bien le poids de ces deux douches froides : elles disent que « l’ouvert demande aussi des efforts et comporte aussi des risques », pas que « le fermé est meilleur ». En comparaison, le risque baissier de verrouiller sa définition métier dans une plateforme — c’est-à-dire la fragmentation à la Yuanfeng — est bien plus grand et bien plus difficile à inverser. Aucun des deux côtés n’est gratuit ; simplement, l’un des deux garde l’actif le plus crucial entre vos propres mains.

Les couches dont tout le monde dépend finissent souvent neutres

Cette régularité n’est pas neuve en soi, mais elle mérite d’être illustrée par de nouveaux exemples, car elle se reproduit sans cesse.

La « couche de définition » dont dépend tout un écosystème tend à devenir neutre. L’exemple le plus ancien est SQL : les éditeurs de bases de données se sont entretués dans un océan rouge, mais le langage de requête lui-même est public. Plus récents et plus parlants encore, ces deux-là : OpenTelemetry — la définition des données de l’observabilité, que tous les éditeurs de supervision viennent brancher, hébergée par la CNCF neutre, sans que personne puisse la monopoliser ; et le LSP (Language Server Protocol) — ouvert par Microsoft lui-même, et c’est justement parce qu’il est ouvert qu’il a été adopté par tous les éditeurs et est devenu le standard de fait.

Le cas du LSP est particulièrement savoureux, car c’est une chose que Microsoft a prouvée de ses propres mains : ouvrir la couche de définition et gagner sa vie sur la meilleure implémentation rapporte plus que de la verrouiller. La couche sémantique métier est de la même nature — elle sera demain dépendue simultanément par vos applications, vos agents, votre système d’audit, plus les outils des trois fournisseurs. Une couche dont dépendent autant de parties ne peut logiquement pas rester durablement la propriété privée de l’une d’elles. Soit elle devient neutre, soit elle continue de produire des fragmentations à la Yuanfeng.

À quoi ressemble cette couche neutre

Après tout cela, jetons un œil à l’objet concret ; l’essentiel n’est pas la syntaxe, mais où elle réside, si on peut l’emporter, et si elle permet de récupérer la fragmentation.

Supposons que Yuanfeng ait d’emblée bâti son « client » en une définition neutre : il aurait pu brancher chacun des trois systèmes comme source de données, les modéliser en objets, puis les aligner en un seul « client » gouverné grâce à une clé partagée — le numéro fiscal :

export const Customer = ObjectSchema.create({
  name: 'crm_customer',
  label: 'Client',
  fields: {
    name: Field.text({ label: 'Nom du client', required: true }),
    tax_id: Field.text({ label: 'N° SIREN' }), // une clé partagée pour aligner « le même client » entre les systèmes
  },
});

Cette définition réside dans votre dépôt Git : diffable, revisible, migrable. Ce qu’elle permet ensuite est l’essentiel — transformer le « transportable » en une action démontrable, pas en une promesse :

git add crm/*.ts          # la définition entre dans votre dépôt : auditable, réversible
os start   # la même définition tourne sur votre propre infrastructure
# puis pointez-y n'importe quel modèle — Claude, GPT, Gemini, le runtime ne change pas

Reposons maintenant la question fatidique : « Quel est le risque de renouvellement du groupe H l’an prochain ? » L’agent fait face à un seul « client » unifié, doté de permissions et d’un audit : commandes saines, mais grevées de deux réclamations escaladées au niveau exécutif et d’un litige de recouvrement à 90 jours — il répondra « risque élevé, intervention anticipée recommandée ». Même modèle, même question ; simplement parce que la définition sous ses pieds n’est plus fragmentée, la conclusion passe de « plusieurs millions perdus » à « alerte un trimestre à l’avance ».

C’est la répartition des rôles entre ObjectStack et ObjectOS, et c’est sa réponse à cette course :

• ObjectStack — le protocole ouvert de description du métier (Apache 2.0), qui réside dans votre dépôt et que les agents des trois géants peuvent lire ;
• ObjectOS — le runtime de cette définition, qui tourne sur votre propre infrastructure, applique les permissions et enregistre l’audit.

La couche de définition est neutre, la couche d’exécution fait le commerce. Le même rapport qu’entre SQL et les éditeurs de bases de données, ou entre le LSP et les éditeurs de code.

Conclusion

Ce n’est pas une question idéologique « ouvert ou fermé ». C’est un problème d’arithmétique plus froid : quand votre combinaison de fournisseurs finira par changer — multi-modèle, multi-cloud, acquisitions, isolation de conformité, elle changera forcément — à ce moment-là, qui tient entre ses mains la définition de votre métier ?

Les trois géants ont prouvé, à coups d’argent comptant, que cette couche valait la peine d’être bâtie. Mais ils ont du même coup posé ce problème d’arithmétique devant chaque entreprise. Les trois « clients » de Yuanfeng ne sont pas un accident technique, ils sont le coût inévitable d’avoir cédé la définition ; et ce groupe H mal classé en « risque faible » n’est que la première facture.

Une couche dont tout le monde dépend appartient rarement durablement à un seul fournisseur. Cette fois, il n’y a pas de raison solide pour que la couche sémantique fasse exception.

npm i -g @objectstack/cli && os start

Définissez votre premier objet métier, faites venir ses données de vos deux systèmes existants, puis git commit dans votre propre dépôt — à cet instant, la définition de votre métier vous revient, au lieu de rester dans le back-office de l’un d’eux.