Ontologie d'entreprise : pourquoi définition et runtime doivent être ouverts

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 doit être une définition d’application ouverte et typée avec un runtime open source portable, pas un « fichier ouvert » qui dépend encore du moteur d’un seul fournisseur. Ouvrez la définition et le socle d’exécution ; facturez l’expérience de production opérée.

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 : le socle portable dont dépend tout un écosystème finit par devenir ouvert — la définition comme le runtime de base qui l’interprète. Les fournisseurs conservent des revenus récurrents, mais grâce à l’expérience de production opérée : hébergement, mises à niveau, sécurité, performance, support et responsabilité. AWS en est la meilleure preuve. Linux, Kubernetes et Postgres restent ouverts ; AWS facture leur exploitation fiable.

Une couche sémantique métier est exactement ce type de socle. Vos applications, vos agents et vos systèmes d’audit dépendront du modèle d’objets, des règles de permissions, des circuits d’approbation et de la sémantique du runtime qui les applique. Plus il y a de dépendances, moins l’une ou l’autre moitié doit vivre dans la plateforme d’un fournisseur. Les définitions doivent être des fichiers lisibles et versionnés dans votre dépôt ; un runtime compatible doit être auto-hébergeable et remplaçable. Un fichier ouvert que seul un moteur payant peut exécuter n’est pas vraiment portable.

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 la définition typée d’application 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 open source ObjectStack lit la définition et en dérive les tables, l’API REST, l’interface d’administration et les outils MCP, tout en appliquant permissions et audit. Une remise supérieure à 30 % exige une validation finance ? C’est un flux attaché à l’objet : tout aussi déclaratif et versionné. ObjectOS ajoute autour de la même application l’expérience commerciale de production — Build et Ask dans le navigateur, revue et validation en équipe, exploitation cloud managée ou déploiement privé, SSO et support — sans rendre la définition ni le moteur propriétaires.

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 ObjectStack, 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 ».

La définition et le runtime portable appartiennent à la communauté ; l’exploitation 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 la forme saine de cette couche à l’ère de l’IA n’est pas « définition ouverte, moteur payant exclusif ». C’est : la définition métier typée et un runtime gouverné portable appartiennent à l’écosystème ouvert ; le produit payant est l’expérience de production opérée autour d’eux.

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

• ObjectStack est la définition d’application ouverte et typée avec son runtime open source (Apache 2.0). Objets, relations, permissions, flux, API, UI et outils IA sont définis une fois dans le dépôt ; le runtime dérive base de données, API REST, UI rendue et serveur MCP, puis applique permissions et audit à chaque appel. Définition et moteur sont versionnables, auto-hébergeables et portables.
• ObjectOS est la plateforme commerciale de production autour de ces mêmes applications ObjectStack. Elle vend Build et Ask dans le navigateur, revue et validation en équipe, exploitation cloud managée ou déploiement privé, SSO, contrôles d’entreprise et support. Ce n’est pas un moteur d’exécution fermé qui vous reprend l’ontologie.

D’un côté : une définition d’application et un runtime portable que toute équipe ou tout agent peut comprendre, auto-héberger et emporter. De l’autre : l’expérience de production que les entreprises paient réellement — création collaborative, validations, hébergement, déploiement privé, SSO, support, mises à niveau et responsabilité opérationnelle. L’application et son runtime de base sont à vous. Les exploiter de façon fiable pour une équipe est le business.

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 et regardez le runtime ouvert ObjectStack le transformer en table, API, interface d’administration et outil qu’une IA peut appeler en toute sécurité. Chaque appel porte des permissions et s’inscrit au registre. Si votre équipe veut Build et Ask dans le navigateur, des revues et validations partagées, un cloud managé ou un déploiement privé, le SSO et le support, ObjectOS exploite cette même application ObjectStack ; elle ne la remplace pas par un format propriétaire ni un moteur exclusif.