Ontologie pour l'IA d'entreprise : pourquoi la couche sémantique doit être ouverte

En bref : Palantir a prouvé que l’IA a besoin d’une couche sémantique métier gouvernée pour entrer dans l’entreprise — mais cette couche devrait être un protocole ouvert que vous possédez, comme Linux, et non enfermée dans une plateforme fermée. Ouvrez la couche de définition ; facturez le runtime.

Commençons par une histoire que vous avez probablement déjà vue se dérouler.

Une entreprise lance un projet « assistant IA ». Première semaine : la démo est éblouissante. Quelqu’un exporte une copie des données clients, la donne à un modèle, et celui-ci sait vraiment répondre à « quels comptes de la région Est risquent de ne pas renouveler ? ». La direction valide aussitôt un pilote élargi.

Mois trois : il faut connecter les données de production. L’équipe sécurité entre dans la pièce et pose trois questions :

• Quelles données l’IA peut-elle voir ? Si le commercial A demande « le classement des performances de toute l’entreprise », va-t-elle lire à voix haute les commissions des autres ?
• Elle va exécuter des actions — modifier une remise, envoyer un contrat. Avec les permissions de qui ? Et quand quelque chose tourne mal, qui est responsable ?
• Quand l’audit demandera « qui a approuvé cette remise », où est l’enregistrement de la partie effectuée par l’IA ?

L’équipe projet n’a pas de réponses. Non par négligence — mais parce que l’architecture ne contient aucune couche capable de répondre à ces questions. Les données sont éparpillées dans une douzaine de systèmes. Les permissions vivent dans le code de chaque application. La règle d’« approbation des remises » existe surtout dans la tête d’un employé chevronné. L’IA contemple des tables brutes et des endpoints bruts, et aucune intelligence ne peut lire les règles d’une entreprise là où elles n’ont jamais été écrites.

Mois neuf : le pilote s’éteint en silence. Le modèle n’a pas perdu en capacité. Il a perdu parce que personne n’a voulu signer.

L’industrie a un nom pour ce qui manquait : une ontologie — une couche sémantique structurée et lisible par les machines, qui définit explicitement quels objets métier existent, comment ils sont liés, qui a le droit de faire quoi, et où chaque action est enregistrée.

Ce que Palantir a vu juste

L’entreprise qui a transformé l’ontologie de concept de recherche en fait commercial s’appelle Palantir. Cela vaut la peine de regarder honnêtement pourquoi elle a réussi — plus le regard est juste, plus la question qui suit est tranchante.

Palantir Foundry fait deux choses essentielles. Premièrement, il intègre les données éparpillées d’une entreprise dans une couche d’ontologie unifiée : clients, équipements et commandes cessent d’être des dizaines de tables pour devenir des objets métier typés, avec relations et propriétés. Deuxièmement, il canalise toute opération d’écriture à travers des Actions gouvernées — chacune validée, soumise aux permissions et entièrement auditée. Depuis 2023, AIP pointe cette architecture droit sur les grands modèles de langage : le LLM ne touche jamais la base de données ; il ne peut qu’appeler des outils gouvernés exposés par la couche d’ontologie. Les modèles se remplacent. La frontière reste.

Pourquoi est-ce cher ? Parce que le problème résolu est réellement cher. Démêler vingt ans de systèmes hérités pour en faire une ontologie propre exige que les Forward Deployed Engineers de Palantir avancent système par système, concept par concept — de l’ingénierie à forte intensité humaine au sens le plus littéral. Ses clients sont les gouvernements, la défense, la banque, l’énergie — pour qui « chaque pas de l’IA dans les permissions, chaque pas enregistré » est une exigence dure, avec le budget assorti. Les contrats démarrent en millions, et les clients renouvellent — parce que cela répond vraiment aux trois questions qui comptent le plus pour un RSSI. Les trois mêmes que dans l’histoire d’ouverture.

Le succès de Palantir ne prouve pas seulement une machine commerciale. Il prouve un jugement d’architecture : pour que l’IA entre dans l’entreprise, une couche sémantique métier gouvernée doit d’abord exister. Ce jugement n’a plus besoin d’être défendu.

Ce qu’il faut repenser, c’est la question suivante : sous quelle forme cette couche doit-elle exister ? Car certaines choses sont en train de changer.

Le logiciel est de plus en plus écrit par l’IA

Le premier changement est le plus visible : les applications elles-mêmes sont de plus en plus écrites par l’IA.

« Construire un système sur mesure d’approbation des notes de frais pour une équipe de 50 personnes » était économiquement absurde — le coût de développement dépassait la douleur. Aujourd’hui, un agent IA le livre en un après-midi. Le logiciel métier sur mesure passe du bien rare au produit courant, et la demande totale va exploser.

Remarquez où elle explose : dans la longue traîne. Dans des équipes qui n’apparaîtront jamais sur la liste de prospects d’aucun éditeur enterprise — pas de processus achats, pas de budget d’intégration, pas de comités de POC. Elles disent simplement à un agent « construis quelque chose qui marche », et l’utilisent le jour même.

Un modèle qui repose sur des ingénieurs détachés et des contrats à millions ne peut structurellement pas atteindre ce marché. Ce n’est pas une critique ; ce sont simplement deux marchés différents. Mais chaque système de ce nouveau marché percutera les trois mêmes questions de sécurité qu’au début — sauf qu’au moment du choc, aucun ingénieur détaché ne se tiendra à côté.

Le prochain à choisir la technologie, c’est un agent

Le deuxième changement est plus discret mais plus profond : l’acte même de choisir une technologie passe des humains à l’IA.

Demandez aujourd’hui à un agent de « construire un système de gestion clients » : il choisira très probablement Next.js et Postgres. Pourquoi ? Personne n’a acheté de publicité dans sa tête. Ces technologies sont ouvertes, abondamment documentées et massivement présentes dans ses données d’entraînement. L’agent a vu des centaines de milliers d’usages et connaît chaque nid-de-poule.

Cela crée quelque chose qui n’existait pas avant : pour la technologie destinée aux développeurs, le texte public du protocole et le code open source sont désormais le canal de distribution lui-même. Plus un protocole est ouvert — plus on en discute, plus il y a de code à apprendre —, mieux la génération suivante de modèles le comprend, et plus les agents le choisissent par défaut. La boucle s’auto-alimente.

Une plateforme fermée ne peut pas entrer dans cette boucle. Son format d’ontologie, sa sémantique d’actions, son modèle de permissions sont derrière des murs de documentation et des contrats. Les modèles ne peuvent pas l’apprendre ; les agents ne peuvent pas y entrer en libre-service. Elle peut être sélectionnée par un processus achats, mais elle ne peut pas être choisie par un agent. À mesure que les logiciels sont écrits par des agents, ce n’est plus un problème de marketing. C’est une absence du canal.

Attendez — les plateformes fermées n’ont-elles pas déjà gagné ?

À ce stade, une objection intelligente devrait avoir surgi : l’ouverture ne gagne pas toujours. L’ère du cloud a été gagnée par AWS. Le mobile, par l’iPhone. Tous deux fermés.

L’objection mérite une réponse sérieuse, car y répondre révèle le véritable motif.

Regardez comment AWS gagne de l’argent : il héberge Linux, Kubernetes, Postgres — des standards ouverts de bout en bout. L’iPhone est fermé, mais chaque paquet qu’il envoie circule sur TCP/IP et HTTP. Remontez plus loin : les éditeurs de bases de données se sont entretués pendant que SQL, le langage lui-même, restait public ; les guerres de l’orchestration de conteneurs se sont terminées avec tout le monde sur le même format ouvert d’images OCI.

Le motif est remarquablement constant : la « couche de définition » dont dépend tout un écosystème finit par devenir ouverte — parce que personne n’ose bâtir ses actifs sur la grammaire d’un fournisseur unique. La « couche d’exécution », elle, peut rester fermée et payante — parce qu’exécuter implique exploitation continue, performance et responsabilité : des coûts réels et récurrents. AWS en est lui-même la plus grande preuve : les définitions appartiennent à la communauté ; les faire tourner, c’est le business.

Une couche sémantique métier est une couche de définition d’école. Votre modèle d’objets, vos règles de permissions, vos circuits d’approbation seront demain des dépendances de vos applications, de vos agents, de vos systèmes d’audit. Plus il y a de choses qui en dépendent, moins elle doit vivre dans la base de données de la plateforme d’un fournisseur — et plus elle doit être des fichiers dans votre propre dépôt : lisibles, versionnés, portables.

Les entreprises ont passé vingt ans à libérer leurs données d’un système fermé après l’autre. Elles ne devraient pas passer l’ère de l’IA à enfermer de nouveau quelque chose d’encore plus fondamental : la définition même du métier.

À quoi ressemble cette « définition » concrètement

Assez d’abstraction. Voici un objet opportunité commerciale dans le protocole ObjectStack, abrégé d’un exemple réel :

export const Opportunity = ObjectSchema.create({
  name: 'crm_opportunity',
  label: 'Opportunité',
  fields: {
    name: Field.text({ label: 'Nom', required: true }),
    account: Field.lookup('crm_account', { label: 'Compte', required: true }),
    amount: Field.currency({ label: 'Montant', min: 0 }),
    probability: Field.percent({ label: 'Probabilité', defaultValue: 50 }),
    expected_revenue: Field.formula({
      label: 'Revenu attendu',
      expression: cel`amount * probability / 100`,
    }),
    discount_percent: Field.percent({ label: 'Remise %', max: 100 }),
  },
});

// Les permissions se déclarent de la même façon : les ventes lisent et écrivent, jamais de suppression
export const SalesUser: Security.PermissionSet = {
  name: 'crm_sales_user',
  objects: {
    crm_opportunity: { allowRead: true, allowCreate: true, allowEdit: true, allowDelete: false },
  },
};

L’important n’est pas la syntaxe. L’important, c’est que ces quelques dizaines de lignes sont le système. Le runtime (ObjectOS) lit cette définition et génère les tables de la base, l’API REST, l’interface d’administration — et les outils gouvernés qu’un agent IA peut appeler directement. Les remises au-delà de 30 % exigent une approbation finance ? C’est une définition de flux attachée à cet objet : tout aussi déclarative, tout aussi versionnée.

Trois conséquences en découlent directement :

1. Les trois questions de sécurité du début reçoivent des réponses structurelles. Ce que l’IA peut voir — c’est écrit dans le jeu de permissions. Avec quels droits elle agit — elle agit en tant qu’utilisateur connecté, imposé par le runtime, pas supplié dans le prompt. Où est la piste d’audit — humains et agents écrivent dans le même registre : qui, quoi, quand, pourquoi. La conformité lit un seul journal, pas deux.
2. Le changement métier devient une revue de code. L’IA veut ajouter un rappel de renouvellement ? Ce qu’elle soumet est un diff de métadonnées — quels champs changent, quelles permissions bougent, tout est visible d’un coup d’œil. Et comme les définitions sont versionnées, les erreurs se rétablissent.
3. Le système entier tient dans la fenêtre de contexte d’un agent. Un module enterprise typique se condense de dizaines de milliers de lignes de CRUD et de glu en quelques centaines de lignes de déclarations — assez petit pour qu’une IA lise chaque dépendance de bout en bout, puis refactorise en toute sécurité à travers données, API, interface et permissions en un seul changement. C’est la frontière entre « l’IA co-mainteneuse » et « l’IA autocomplétion ».

Le protocole appartient à la communauté ; le runtime est le business

Maintenant, l’argument se referme sur lui-même.

Le jugement de l’ontologie est juste — Palantir l’a prouvé pour toute l’industrie. Mais selon le motif « définitions ouvertes, runtime payant », la forme saine de cette couche à l’ère de l’IA est : le protocole sémantique métier appartient à l’écosystème ouvert, comme Linux — et un runtime gouverné l’exécute dans votre propre environnement.

C’est exactement la division du travail entre ObjectStack et ObjectOS :

• ObjectStack est le protocole ouvert de description des applications métier (Apache 2.0) : objets, relations, permissions, flux, API, interface et outils IA, définis une seule fois. Il vit dans votre dépôt — diffable, portable, lisible par n’importe quel agent — et donc sur l’internet public, dans les données d’entraînement de tous les modèles à venir.
• ObjectOS est le runtime de ces définitions : il exécute tout sur vos serveurs, contre votre base de données, en imposant les permissions et en écrivant le journal d’audit à l’exécution. La gouvernance n’est pas écrite dans le prompt ; elle est écrite dans le moteur d’exécution.

D’un côté : un protocole que toute équipe et tout agent peuvent s’offrir, comprendre et emporter — dès aujourd’hui. De l’autre : ce pour quoi les entreprises paient vraiment — l’hébergement, la conformité, la publication multi-environnements, quelqu’un qui répond de l’exploitation. Les définitions sont à vous. La peine de les faire tourner, c’est notre métier.

Conclusion

Ce pilote IA mort au neuvième mois n’a jamais perdu contre la capacité du modèle. Il a perdu contre l’absence d’une couche sémantique qu’une équipe sécurité pouvait signer. Les grands fournisseurs ont montré la valeur de cette couche. Le prochain travail, c’est de faire en sorte qu’elle cesse d’être un luxe réservé aux plus grandes entreprises.

Si vous voulez vérifier que tout cela est réel :

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

Dans cinq minutes, définissez votre premier objet métier — puis regardez-le devenir une table de base de données, une API, une interface d’administration et un outil qu’une IA peut appeler en toute sécurité. Chaque appel porte des permissions. Chaque appel s’inscrit au registre.