Semantic drift : le risque invisible des systèmes multi-agents

Le passage d'un agent isolé à un système composé de dizaines d'agents change la nature du problème d'architecture. Avec un agent unique, une définition métier peut encore être encapsulée dans un prompt, une knowledge base, une fonction ou quelques règles applicatives.

Avec plusieurs agents qui échangent des informations, interrogent des sources différentes et exécutent des actions sur le système d'information, une nouvelle propriété devient critique : partagent-ils réellement la même compréhension du métier ? Pas seulement les mêmes données — la même signification. C'est le problème du semantic drift.

Le semantic drift n'est pas une hallucination

Prenons une notion apparemment simple : ActiveCustomer. Pour l'agent commercial, un client actif peut être un client ayant commandé au cours des douze derniers mois ; pour l'agent financier, un compte ouvert sans incident de paiement ; pour l'agent chargé du support, un client disposant d'un contrat de maintenance valide. Les trois agents peuvent avoir raison.

Le problème apparaît lorsqu'ils commencent à échanger cette information sous une forme simplifiée :

Customer A is active.

Aucune hallucination n'a nécessairement eu lieu. La donnée source, le retrieval, le raisonnement local et l'appel d'outil peuvent tous être corrects. Et pourtant, l'agent qui reçoit l'information peut prendre une mauvaise décision parce qu'il attribue au mot active une autre sémantique.

Le semantic drift désigne ici la divergence de signification d'un concept partagé entre plusieurs composants d'un système agentique. À ne pas confondre avec le concept drift des modèles de machine learning, où la distribution des données évolue dans le temps : ici, la donnée ne change pas nécessairement — c'est l'interprétation d'un même mot qui diverge entre les composants qui l'échangent. Il ne s'agit donc pas seulement de vérifier si une réponse est vraie : il faut également savoir dans quel modèle du métier elle est vraie.

Comment le drift apparaît

Le problème existe déjà dans les systèmes d'information traditionnels : deux applications peuvent posséder des définitions différentes du client, de la commande, du chiffre d'affaires ou du risque. Les architectures agentiques augmentent toutefois la surface d'exposition. Une même règle métier peut désormais être encodée simultanément dans :

• un system prompt ;
• une knowledge base ;
• une requête SQL ;
• le code d'un outil ;
• une API métier ;
• une mémoire d'agent ;
• un modèle sémantique ;
• les instructions transmises d'un agent à un autre.

Chaque représentation peut évoluer indépendamment. Une modification apparemment anodine suffit alors à introduire une divergence.

Agent Sales
    |
    |  "Customer is active"
    v
Agent Finance
    |
    |  active = account_open && payment_status == OK
    v
Decision

Le problème n'est pas le message. Le problème est l'absence de contrat sur sa signification.

Le RAG résout l'accès à la connaissance, pas l'unicité du sens

Les architectures RAG ont largement amélioré la capacité des modèles à accéder aux informations de l'entreprise. Mais retrouver le bon document et partager un modèle métier sont deux problèmes différents.

Le RAG répond principalement à la question : quelle information faut-il fournir au modèle ?

Le semantic drift en pose une autre : quelle définition doit être utilisée pour interpréter cette information ?

Un agent peut parfaitement retrouver la dernière procédure commerciale tout en appliquant une définition du client issue d'une autre source. Augmenter le nombre de documents dans le contexte ne résout pas nécessairement ce problème — cela peut même multiplier les définitions disponibles. La qualité du retrieval reste indispensable ; elle n'est simplement pas suffisante.

Le harness ne garantit pas non plus la cohérence sémantique

Le même raisonnement s'applique au harness. Un runtime agentique robuste peut gérer le planning, le tool calling, les erreurs, les retries, les autorisations, les traces et les politiques d'exécution. Il peut garantir que l'agent exécute correctement :

plan -> act -> observe -> update -> respond

Mais une boucle parfaitement exécutée sur une définition métier incorrecte reste une boucle incorrecte — techniquement correcte et sémantiquement fausse. Le harness contrôle l'exécution ; il ne peut garantir à lui seul que deux agents donnent la même signification au concept qu'ils manipulent.

Le semantic layer change de rôle

C'est probablement l'une des évolutions architecturales les plus intéressantes du moment. Historiquement, le semantic layer a principalement été développé pour l'analytics : il permet de définir des dimensions, des mesures, des relations et des indicateurs afin que différents rapports utilisent une même interprétation des données. L'arrivée des agents étend considérablement son rôle, et Microsoft Fabric IQ illustre bien cette évolution avec une progression entre données unifiées, modèles sémantiques, ontologies et agents.

L'ontologie ne décrit plus seulement une structure de données. Elle peut représenter :

Customer
    |
    +-- places --> Order
    |
    +-- owns ----> Contract
    |
    +-- has -----> RiskProfile

avec les propriétés, relations et règles associées.

La couche sémantique cesse alors d'être uniquement un moyen de produire des analyses cohérentes : elle commence à fournir une représentation opérationnelle du métier utilisable par les systèmes logiciels et les agents. C'est une évolution importante — lorsque les agents commencent à agir, la sémantique devient progressivement une dépendance du runtime. Les analystes convergent vers le même constat : Gartner prévoit que 60 % des projets d'analytics agentique reposant uniquement sur des protocoles d'accès aux outils comme MCP échoueront d'ici 2028, faute d'une couche sémantique cohérente en dessous.

Du modèle sémantique au contrat sémantique

Cette évolution suggère un changement de perspective : les concepts critiques de l'entreprise devraient pouvoir être traités comme des contrats. L'idée est familière aux équipes data — c'est le prolongement naturel des data contracts, qui explicitent le schéma et les garanties d'un flux de données entre un producteur et ses consommateurs. Le contrat sémantique est aux agents ce que le data contract est aux pipelines : il explicite non plus la structure de la donnée, mais la définition métier utilisée pour l'interpréter.

Un contrat sémantique pourrait par exemple expliciter :

concept: ActiveCustomer
version: 3
 
definition:
  customer_status: OPEN
  commercial_activity_within: 365d
 
source:
  system: CRM
  entity: Customer
 
owner:
  domain: Sales
 
valid_from: 2026-09-01

Ce format n'est pas un standard. Il illustre simplement une propriété importante : la définition devient explicite, identifiable et versionnable.

Un point mérite d'être souligné : le contrat n'impose pas une définition unique à toute l'entreprise. Sales, Finance et Support peuvent conserver leurs définitions respectives — Sales:ActiveCustomer:v3 et Finance:ActiveCustomer:v1 peuvent parfaitement coexister, chacune avec son owner. Le problème n'est pas la pluralité des définitions, qui est souvent légitime ; le problème est de les échanger sous un même mot sans qualifier laquelle est utilisée. Le contrat rend la divergence explicite et adressable, là où elle était implicite et invisible.

Un agent ne devrait alors plus seulement produire :

{
  "customer": "A123",
  "active": true
}

mais être capable de rattacher cette décision au concept et à la version utilisés.

{
  "customer": "A123",
  "active": true,
  "semantic_contract": "Sales:ActiveCustomer:v3"
}

Nous obtenons alors quelque chose qui manque encore souvent aux systèmes agentiques : la provenance sémantique de la décision.

Le problème devient critique à l'échelle

Pour trois agents développés par une même équipe, maintenir cette cohérence manuellement reste possible. Pour cinquante agents répartis entre plusieurs domaines, plusieurs équipes et plusieurs plateformes, la situation change rapidement. Considérons cinq concepts seulement :

Customer
Order
Revenue
Eligible
Risk

Cinq concepts partagés entre cinquante agents, ce sont déjà deux cent cinquante interprétations locales possibles. Et la cohérence à vérifier n'est pas linéaire : elle porte sur chaque paire d'agents qui échangent ces concepts, soit potentiellement plus d'un millier de combinaisons pour un seul mot ambigu.

Si chaque équipe encode sa propre interprétation de ces concepts dans ses prompts et ses outils, les divergences deviennent combinatoires, et l'organisation recrée progressivement les silos sémantiques déjà présents dans son système d'information.

Avec une différence majeure : ces nouveaux silos peuvent prendre des décisions et déclencher des actions.

C'est probablement là que le semantic drift devient un risque architectural plutôt qu'un simple problème de qualité de réponse.

Vers une semantic observability

Les plateformes d'IA commencent à fournir une observabilité de plus en plus fine :

prompt
model
tokens
latency
tool calls
traces
errors
evaluations

Pour des systèmes multi-agents, cela pourrait ne plus suffire. Lorsqu'un agent prend une décision, plusieurs questions deviennent utiles :

Quel concept métier a été utilisé ?
Quelle définition ?
Quelle version ?
Quelle source fait autorité ?
Quels agents utilisent cette définition ?
La définition a-t-elle changé depuis la dernière évaluation ?

Nous pouvons appeler cette capacité semantic observability. L'objectif n'est plus seulement de détecter : cet agent produit de mauvaises réponses. Mais également : ces deux agents ne raisonnent plus à partir du même modèle du métier. Cette distinction est importante — le premier problème peut être détecté par une évaluation locale ; le second n'apparaît parfois qu'au moment où plusieurs agents commencent à collaborer.

Deux mécanismes concrets émergent déjà côté plateformes data et peuvent être transposés aux agents : la vérification de cohérence des définitions intégrée à la CI/CD, qui détecte un conflit au moment du build plutôt qu'au runtime, et le lineage sémantique — savoir qui a modifié quelle définition, quand, et avec quel impact en aval.

Tester la sémantique comme du code

Si la sémantique intervient dans l'exécution, elle doit progressivement adopter certaines propriétés de l'ingénierie logicielle. Une modification de définition ne devrait pas être considérée comme une simple mise à jour documentaire : elle peut modifier le comportement d'un ensemble d'agents. Une chaîne d'évaluation pourrait donc inclure des tests de cohérence sémantique.

def test_active_customer_semantics():
    sales = sales_agent.classify(customer)
    finance = finance_agent.classify(customer)
 
    # Both agents declare their contract; the pair must be
    # either identical or explicitly mapped.
    assert (sales.semantic_contract == finance.semantic_contract
            or is_mapped(sales.semantic_contract, finance.semantic_contract))

Le test est volontairement simplifié, mais le principe est important : la cohérence des concepts partagés devient une propriété testable du système — y compris lorsque deux définitions distinctes coexistent légitimement, à condition que leur correspondance soit explicite. Ces divergences peuvent désormais être traitées comme une propriété mesurable du système.

Nous pouvons alors imaginer des quality gates portant sur :

• la version du modèle sémantique ;
• la compatibilité entre versions ;
• la provenance des définitions ;
• la cohérence inter-agents ;
• les impacts d'une modification ;
• les concepts utilisés pendant une décision.

Le semantic drift devient ainsi observable avant de devenir un incident métier.

Ne pas construire une ontologie universelle

La réponse au semantic drift n'est pas nécessairement de modéliser toute l'entreprise avant de développer le moindre agent : cette approche conduirait rapidement à une architecture trop lourde. Tous les concepts ne présentent pas le même risque ; la priorité doit porter sur ceux qui franchissent les frontières entre agents ou déclenchent des décisions importantes.

Un bon point de départ consiste à identifier les concepts qui possèdent au moins l'une de ces caractéristiques :

• ils sont utilisés par plusieurs agents ;
• ils déclenchent une action ;
• ils représentent une décision réglementaire ou financière ;
• ils possèdent plusieurs définitions historiques dans le SI ;
• leur interprétation erronée peut produire un effet métier significatif.

L'architecture sémantique peut ensuite croître avec le système agentique.

Une discipline d'ingénierie supplémentaire

Les architectures agentiques de production accumulent progressivement plusieurs couches :

Models
Context
Memory
Harness
Tools
Identity
Policy
Evaluation
Observability

Il faut probablement commencer à en considérer une autre explicitement :

Semantics

Non parce que les modèles seraient incapables de comprendre le langage métier, mais précisément parce qu'ils en sont capables. Un LLM peut interpréter plusieurs définitions plausibles du même concept et continuer à produire une réponse parfaitement convaincante. À l'échelle d'un agent, cette flexibilité est une force ; à l'échelle d'un système distribué d'agents, elle peut devenir une source de divergence.

La question n'est donc plus seulement : comment donner suffisamment de contexte à nos agents ? Elle devient : comment garantir qu'ils interprètent ce contexte à partir du même modèle du métier ?

Le semantic drift pourrait être l'un des premiers problèmes véritablement distribués de l'architecture agentique. Et sa maîtrise passera probablement moins par un meilleur prompt que par des pratiques déjà familières aux architectes : contrats, versioning, gouvernance, tests et observabilité.

Références

La réflexion présentée ici s'appuie notamment sur l'évolution des architectures Microsoft autour de Fabric IQ et Microsoft IQ : modèles sémantiques, ontologies, knowledge bases et contexte partagé pour les agents. Elle développe toutefois une problématique d'architecture générale, indépendante d'une plateforme particulière. Le phénomène est également documenté côté plateformes data — notamment sous les termes de semantic drift et de context drift — ce qui confirme qu'il dépasse le seul périmètre des architectures agentiques.

La prédiction citée sur les projets d'analytics agentique a été présentée au Gartner Data & Analytics Summit 2026 ; voir également Gartner, « Lack of Semantics Causes Inaccurate AI Agents and Wasted Spending », mai 2026.