L'ontologie n'est pas louable : le vrai fossé concurrentiel des agents IA
Le disconnect qui traverse l'industrie
Il existe aujourd'hui une fracture silencieuse dans la manière de concevoir des agents IA. D'un côté, l'industrie a investi massivement dans des frameworks d'orchestration : LangGraph, CrewAI, AutoGen, Semantic Kernel, OpenAI Agents SDK, AWS Bedrock, Google ADK. Chacun avec ses graphes de routage, ses machines à états, ses conventions d'appels. De l'autre, les praticiens qui poussent la frontière ont déjà tourné la page. Ils travaillent avec Claude Code, Codex, OpenClaw, Hermes — un modèle puissant logé dans un harnais puissant. Aucun framework intermédiaire. L'observation n'est pas nouvelle. Ce qui est nouveau, c'est le cadre conceptuel qui lui donne un nom, proposé par Tony Seale (Head of Data Architecture, ex-UBS) dans un post LinkedIn du 17 avril 2026.
Seale baptise cette composition l'Agent Sémantique, et propose une équation d'apparence simple qui cristallise un basculement industriel : (Modèle + Harnais) + (Ontologie + Données connectées) = Agent Sémantique. Deux patterns symétriques, aucun échafaudage parasite. Toute l'architecture d'un agent d'entreprise tient dans cette symétrie. Et surtout — c'est là le cœur de la thèse — un seul élément de l'équation n'est pas rentable : votre ontologie. Le modèle, vous le louez. Le harnais, vous le répliquez. L'ontologie, vous la construisez. Elle est la seule chose qui reste vôtre.
La force de cette formulation est qu'elle coupe à travers un débat qui s'enlise. Depuis dix-huit mois, les directions techniques oscillent entre trois questions mal posées : faut-il bâtir son propre LLM ? Faut-il mutualiser un framework agentique maison ? Faut-il attendre que les modèles frontières se stabilisent avant d'investir ? Seale renvoie les trois à leur nature : des choix techniques de court terme qui se résoudront tout seuls à mesure que les commodités se consolideront. La vraie question — celle qui mérite vingt personnes pendant cinq ans plutôt qu'une équipe R&D pendant six mois — est invisible au niveau du modèle : quelle est la structure partagée de sens sur laquelle repose l'entreprise, et qui la maintient ?
The Collapse : pourquoi les frameworks agentiques s'effondrent
Les premiers frameworks d'agents sont nés d'une contrainte réelle. Les modèles de 2023 ne savaient pas gérer de travail multi-étapes sans guidage explicite. Il fallait leur fournir un graphe d'exécution, un routeur de prompts, un orchestrateur d'outils. LangChain et ses descendants ont résolu ce problème pendant dix-huit mois.
Mais les modèles ont progressé. Anthropic a formulé la règle clairement : « chaque composant d'un harnais encode une hypothèse sur ce que le modèle ne sait pas faire seul, et ces hypothèses peuvent rapidement devenir obsolètes à mesure que les modèles s'améliorent ». Les garde-fous construits pour un modèle limité entravent un modèle capable. Le planificateur explicite, le routeur de rôles, la machine à états qui disait à l'agent ce qu'il devait faire à chaque étape — tout ce qui était utile en 2023 devient une contrainte en 2026. L'échafaudage doit décroître, pas s'accumuler.
Ce qui reste, après le retrait des échafaudages, est remarquablement simple. Un modèle puissant. Un harnais puissant. Plusieurs d'entre eux, qui interagissent, qui collaborent. Pas de framework intermédiaire. C'est exactement ce que produisent les meilleurs harnais de 2026 : Claude Code ne routerait pas les prompts via un graphe d'états explicite ; il laisse Claude Opus 4.6 décider. Codex d'OpenAI fait pareil. Et les résultats suivent. Terminal-Bench 2.0 a montré en mars 2026 que le Harness Engineering — la discipline qui conçoit le harnais minimal autour du modèle — produit plus de valeur que le choix du modèle lui-même. ForgeCode obtient 81,8% avec Claude Opus 4.6 ; Claude Code obtient 58% avec le même modèle. Vingt-trois points d'écart, entièrement explicables par le harnais. Les frameworks d'orchestration classiques ne figurent plus sur les benchmarks de pointe. Ils sont en train de s'effacer.
Le mouvement n'est pas complet. LangGraph reste utilisé dans des contextes où l'équipe a déjà construit son vocabulaire autour de la bibliothèque ; CrewAI garde une niche dans les prototypes de démonstrations multi-agents ; Semantic Kernel conserve son adoption Microsoft. Mais la direction est claire, et elle va dans un seul sens. Les équipes qui démarrent un projet agentique en 2026 ne choisissent plus d'abord un framework — elles choisissent un harnais de référence (Claude Code, Codex) et construisent les extensions minimales nécessaires à leur contexte. Le framework n'est plus le point d'entrée ; il est devenu l'exception.
Les agents isolés ne suffisent pas
Mais l'accès à l'ordinateur n'est pas la compréhension. Un harnais bien conçu donne à l'agent les bras et les yeux pour agir dans un système ; il ne lui donne pas le sens de ce sur quoi il agit. Donnez à un agent mille documents et posez-lui une question. Il cherchera. Il essayera. Il devinera. Multipliez l'exercice sur cinquante agents qui tournent en parallèle sans modèle partagé du monde, et vous obtenez un paradoxe familier : intelligents en isolation, incohérents en combinaison.
Ce paradoxe a une signature opérationnelle précise. L'agent RH qui parle de « candidat » ne relie pas ce terme à ce que l'agent commercial appelle « prospect » ni à ce que l'agent support appelle « contact ». Les trois manipulent des entités humaines apparentées, mais chacun invente sa propre typologie, ses propres relations, sa propre profondeur. Sur un processus qui traverse les trois — un ancien candidat qui devient client qui ouvre un ticket — la trajectoire se brise à chaque frontière d'agent. Intelligents en isolation, incohérents dès qu'ils doivent partager un contexte.
La même fracture surgit dès qu'on monte d'un cran en complexité métier. Un agent conformité qui instruit un dossier KYC ne sait pas qu'une entité juridique « FiliaE SA » observée dans les flux commerciaux est la même que la « Filiae Company Ltd » référencée dans les actes notariés, ni que sa société-mère a changé de nom il y a trois ans. Chaque agent reconstruit sa propre vue, et sur chaque requête cette vue est partiellement fausse. L'observation industrielle depuis 2024 est constante : les déploiements d'agents qui fonctionnent le mieux partagent tous un point commun silencieux — ils tournent sur des données déjà fortement structurées, typées, liées. Les autres butent sur les mêmes incohérences, souvent invisibles au reporting, catastrophiques en audit.
Pour que les agents opèrent à l'échelle d'une entreprise, l'environnement informationnel doit être structuré. Ils ont besoin d'un modèle de domaine partagé. Et les humains doivent rester dans la boucle, non comme opérateurs mais comme gardiens de la sémantique.
La symétrie : Harnais + Ontologie
La réponse proposée par Seale est d'appliquer la même simplification côté données que celle qui s'est imposée côté modèle. De même que le modèle vit dans un harnais qui lui donne accès à l'ordinateur, les données vivent dans une ontologie qui leur donne structure et signification.
L'ontologie définit ce qui existe, ses propriétés, ses relations. Elle est l'interface par laquelle les agents accèdent aux données. Et les données elles-mêmes — typées, liées, structurées — se connectent en un graphe de signification navigable. Dans l'équation symétrique de Seale, deux patterns se répondent. D'un côté, un modèle puissant dans un harnais puissant. De l'autre, des données puissantes dans une ontologie puissante. Assemblez les deux et vous obtenez l'agent sémantique : il ne se contente plus de générer, il commence à comprendre. (Modèle + Harnais) + (Ontologie + Données) — c'est le pattern complet. Tout le reste est échafaudage.
De la génération à la compréhension
Le glissement sémantique — du verbe generate au verbe understand — n'est pas une posture philosophique. Il décrit une capacité opérationnelle mesurable. Un agent qui reçoit « trouve-moi les dernières factures du client Acme » sans ontologie va inférer à partir du texte brut des documents indexés. Il va se tromper sur les homonymes (Acme Ventures vs Acme Industries), manquer les factures référencées par identifiant interne plutôt que par nom, confondre une facture signée avec une facture payée. Chaque requête devient un pari.
Donnez à ce même agent une ontologie qui définit Client, Facture, Relation:factureÉmisePour, PropriétéDeStatut:(émise|validée|payée), et le même prompt s'exécute différemment. L'agent ne cherche plus dans un tas de documents : il navigue un graphe. Il sait que Acme peut résoudre vers deux entités distinctes. Il sait qu'une facture a un statut. Il sait ce qu'est un lien. La génération est remplacée par une traversée. L'agent ne produit plus une réponse qui a l'air bonne — il fournit une réponse qui est tracée jusqu'à sa source.
Ce passage s'accompagne d'une autre transformation. Les erreurs que commet un agent sémantique deviennent diagnosticables. Si l'ontologie manque un type, l'agent échoue sur une catégorie précise de requêtes. Si une relation est mal définie, le symptôme remonte à la modélisation, pas au modèle. Les boucles de correction ne sont plus aveugles — elles pointent vers des zones précises de l'ontologie. C'est le même pattern cybernétique que le Harness Engineering appliqué aux données : chaque erreur déclenche une amélioration du système plutôt qu'un rafistolage localisé.
Risques et limites : l'ontologie est difficile
Il faut être clair sur ce que cette vision ne résout pas. Construire une ontologie d'entreprise est une entreprise coûteuse, politique, jamais terminée. Les tentatives historiques — du Semantic Web au Master Data Management — ont produit autant de succès que de cimetières d'initiatives. Les pièges sont connus : la sur-modélisation (une ontologie trop riche que personne ne maintient), la sous-modélisation (une ontologie trop plate qui n'apporte rien), la divergence (plusieurs équipes qui maintiennent des fragments incompatibles), et surtout l'éloignement du terrain (une ontologie pensée par les architectes sans contact avec les utilisateurs).
L'erreur typique consiste à croire qu'on peut déléguer la construction à une équipe centrale. L'ontologie qui fonctionne émerge de l'usage : elle est co-construite avec les équipes métier, versionnée comme du code, testée par les agents qui la consomment. Elle ne préexiste pas aux agents, elle se forme en dialoguant avec eux. Seale ne l'écrit pas explicitement, mais le corollaire de sa thèse est qu'une ontologie vivante exige une boucle de feedback continue entre ce que les agents demandent et ce que le domaine peut répondre.
L'autre risque est la tentation de recréer les frameworks que l'on vient de quitter, sous un autre nom. La couche sémantique peut rapidement devenir un orchestrateur déguisé, chargé de règles métier, de workflows, de logique conditionnelle qui n'appartient pas à la donnée. Il faut résister. L'ontologie décrit ce qui existe — pas ce qui doit arriver. Les agents décident du flux ; l'ontologie fournit le vocabulaire.
Leviers d'action : construire ce qui vous appartient
Pour une organisation qui veut opérationnaliser cette symétrie, trois leviers émergent. Premier : identifier le périmètre sémantique minimum viable. Pas toute l'entreprise d'un coup — un domaine où la cohérence manque aujourd'hui et où plusieurs agents vont bientôt opérer ensemble. Le plus souvent, c'est le client, la commande, ou le cycle de développement produit. Démarrer par une ontologie qui couvre cinquante entités bien définies est plus utile qu'un schéma général de trois mille qui ne servira à personne.
Deuxième levier : traiter l'ontologie comme du code versionné. Pas un document Confluence qui dérive, pas un schéma Jira qui meurt. Un fichier YAML ou OWL dans un dépôt Git, avec des revues de pull request, des tests d'intégrité, un pipeline CI qui valide la cohérence. La maintenance continue devient alors un acte d'ingénierie, pas un projet de documentation.
Troisième levier : fermer la boucle avec les agents qui la consomment. Chaque agent qui échoue à trouver une entité ou à comprendre une relation produit un signal. Ce signal doit remonter automatiquement à l'ontologie — une suggestion d'ajout, une correction de libellé, une relation manquante. Le Harness Engineering industrialise cette boucle côté code ; le même pattern doit être appliqué côté sémantique. Sans cela, l'ontologie fossilise et les agents divergent.
Quatrième levier, souvent oublié : rendre l'ontologie publiquement navigable à l'intérieur de l'organisation. Un graphe de sens qui ne sert qu'aux agents reste un artefact technique ; un graphe que les équipes produit, commerciales, juridiques et financières peuvent consulter devient un bien commun. Les meilleurs déploiements que nous voyons installent une interface humaine sur la même structure — un portail, un explorateur de concepts, un moteur de recherche sémantique — qui transforme l'ontologie en référentiel partagé. L'agent devient alors un utilisateur parmi d'autres du même modèle de domaine, ce qui crée une boucle de qualité sans laquelle l'ontologie se fige dans des définitions techniques qui ne parlent à personne.
Perspective SFEIR
Cette équation de Tony Seale résonne avec ce que nous observons sur le terrain. L'IA Mesh que nous défendons depuis dix-huit mois — un maillage distribué d'agents coopérants — reste incomplet sans une couche sémantique partagée. L'Agentic Mesh qui en encadre la sécurité (identité, zero trust, guardrails, TEE) est nécessaire mais pas suffisant : il protège contre les agents malveillants, pas contre l'incohérence sémantique. Et le Digital Twin que nous positionnons comme représentation opérationnelle de l'entreprise n'est rien d'autre, en pratique, qu'une ontologie exécutable connectée à des données connectées. Trois concepts que nous formulions séparément deviennent, dans la lecture de Seale, les facettes d'une seule architecture.
Il y a une conséquence pratique. Pour nos clients, la question n'est plus « quel framework d'agent choisir » ni « quel modèle utiliser » — ces choix s'estompent dans la commodité. La question devient « quelle est l'ontologie de notre domaine ». C'est sur ce point que se jouera le vrai fossé concurrentiel des dix prochaines années. Pas sur le modèle loué, pas sur le harnais répliqué, mais sur la structure de sens que vous aurez construite — et qui vous appartient.
Cette bascule reconfigure aussi ce que nous attendons d'un projet IA. Dans la plupart des organisations, les initiatives des trois dernières années ont porté sur l'expérimentation de modèles : quel LLM choisir, quel prompt systémique, quel framework d'intégration. Ces questions deviennent techniques et de court terme. Les questions qui gagnent en importance sont d'un autre ordre : comment structurons-nous le vocabulaire métier ? Qui est responsable de la définition des entités critiques ? Quelle est la granularité utile pour notre secteur ? Comment maintenons-nous cette structure vivante sans la transformer en bureaucratie ? Ce sont des questions d'ingénierie de la connaissance, plus proches du travail d'un architecte d'entreprise ou d'un conservateur de données que d'un développeur ML. Elles sont moins glamour et infiniment plus déterminantes.
Conclusion : le seul actif qui reste à construire
Tout le monde dispose des mêmes modèles frontières. Tout le monde peut construire un harnais — c'est une commodité qui s'affine chaque trimestre. Ce qui n'est pas commodité, c'est votre ontologie. Votre modèle de domaine. La connaissance structurée et liée qui capture comment VOTRE organisation comprend le monde. Les frameworks d'orchestration sont une phase transitoire. Les modèles sont loués. La seule chose qu'il reste à construire — et qui vous appartient — est la connaissance. That is yours, écrit Seale. C'est la phrase à retenir de tout l'article : ce que vous construisez là ne se loue pas, ne se télécharge pas, ne se réplique pas. C'est la part du long terme.
Source : cet article reprend et développe la thèse exposée par Tony Seale dans son post LinkedIn du 17 avril 2026 (LinkedIn — Tony Seale). La citation attribuée à Anthropic sur l'obsolescence des composants de harnais provient du même post.