Pourquoi plus d’échecs signalés ne signifie pas une IA moins fiable

Une couche de contexte gouvernée peut donner l’impression que la fiabilité de l’IA se dégrade

Une entreprise peut déployer une couche de contexte gouvernée pour améliorer ses agents IA, puis constater une détérioration de sa fiabilité déclarée. Une enquête VB Pulse de juillet 2026 a porté sur 101 entreprises qualifiées de plus de 100 employés et a interrogé les répondants sur les réponses d’agents IA assurées mais erronées, attribuées à un contexte métier manquant ou incohérent au cours des six mois précédents. Les réponses montrent à quel point le problème est répandu et récurrent.

Ces échecs deviennent plus faciles à interpréter lorsque la maturité de la gouvernance entre en jeu. Les agents ont besoin de sens métier en plus des informations récupérées, notamment de définitions cohérentes des métriques, de savoir si les documents sont à jour et d’un moyen fiable d’interpréter les données de l’entreprise. Les entreprises peuvent fournir ce contexte via différentes architectures, et une couche gouvernée offre une référence commune que les enquêteurs peuvent utiliser pour examiner une mauvaise réponse.

Cette référence commune change la manière dont les équipes doivent lire un tableau de bord de fiabilité, car le reporting dépend en partie de ce qu’une équipe est capable de détecter. Les 22% qui ne signalent aucun échec lié au contexte ne peuvent pas automatiquement être classés comme le groupe le plus sain ; un bilan vierge peut aussi résulter de contrôles ou d’une instrumentation limités. À mesure que le diagnostic s’améliore, des problèmes auparavant invisibles peuvent se voir attribuer des causes identifiables ; ainsi, un déploiement initial de la gouvernance peut dégrader le score de fiabilité déclaré alors même que l’organisation gagne en visibilité.

Deux lectures des données montrent pourquoi l’observabilité compte

La première comparaison porte sur les entreprises capables d’identifier si elles avaient connu cet échec. Parmi les 91 répondants en mesure de répondre, 50% des entreprises exploitant ou construisant une couche de contexte gouvernée ont signalé des échecs récurrents, contre 21% parmi les entreprises qui n’en avaient pas. Une lecture simple de la performance associerait la gouvernance à un taux de signalement des échecs récurrents plus de deux fois supérieur, mais l’enquête mesure les échecs identifiés plutôt que le taux d’erreur sous-jacent.

Une couche gouvernée peut améliorer l’identification parce qu’elle donne aux agents et aux outils analytiques un modèle partagé du sens métier. Au lieu de déduire indépendamment ce que signifie une métrique, une table ou un concept métier, ces systèmes peuvent se référer à des définitions gouvernées. Lorsqu’un agent renvoie un chiffre incorrect, les enquêteurs peuvent comparer le contexte qu’il a utilisé à cette référence et rechercher une définition défaillante, une table obsolète ou un autre défaut de contexte ; sans une telle référence, une équipe peut classer le résultat de manière générale comme un problème de modèle.

Ce problème de traçage est antérieur à la génération actuelle de systèmes d’IA. Kyle Nesbit, fondateur de la startup de couche sémantique Credible Data, a décrit cette continuité dans un entretien avec VentureBeat le mois précédent : “It’s the same pain point people have had for 30 years, the lack of governed data analysis,” a déclaré Nesbit. “Now with AI, it’s the same problem, but orders of magnitude more chaos and pain.” Credible Data vend des technologies dans ce domaine, et bénéficie donc commercialement lorsque les entreprises considèrent l’analyse gouvernée comme nécessaire ; le point soulevé par Nesbit est que les agents augmentent les conséquences, car les systèmes consomment désormais des définitions métier pour produire des réponses et agir sur le contexte à grande échelle.

La taille de l’entreprise fournit une deuxième comparaison, même si elle ne permet pas à elle seule d’identifier la cause de l’écart. Les grandes entreprises signalent plus souvent des échecs récurrents, tandis qu’une part plus faible déclare disposer d’une couche gouvernée en production. Les chiffres dissocient le signalement des échecs de l’adoption d’une couche en production, plutôt que de montrer que la gouvernance en production explique à elle seule les niveaux de signalement.

Cette tendance liée à la taille est compatible avec une explication par l’observabilité, car les grandes organisations peuvent disposer de davantage d’instrumentation et de plus de personnes chargées d’enquêter sur les raisons pour lesquelles un chiffre est erroné. Dans ce cas, des investigations supplémentaires révèlent des échecs même lorsqu’une couche de contexte gouvernée n’est pas encore en production. Avec la comparaison précédente sur la gouvernance, les données montrent pourquoi un nombre d’échecs signalés peut refléter à la fois le comportement des agents et la capacité d’une organisation à trouver des défauts de contexte.

Cette distinction fixe aussi une limite claire à ce que les chiffres établissent. Ces pourcentages mesurent les échecs que les entreprises ont signalés et retracés ; ils ne mesurent donc pas indépendamment la fréquence réelle à laquelle les agents produisent de mauvaises réponses, ni n’établissent que le contexte gouverné a causé le taux de signalement plus élevé. Ils ne permettent pas non plus d’établir que les couches de contexte ont déjà réduit l’incidence réelle des erreurs. La conclusion opérationnelle est plus étroite : les équipes doivent distinguer les mesures de détection des mesures de résultat, car le diagnostic peut s’améliorer avant que l’exactitude sous-jacente ne progresse.

Cette limite de mesure compte pendant le déploiement, car une référence stable peut transformer des problèmes génériques de modèle en défauts spécifiques et diagnostiqués. Les équipes peuvent commencer à attribuer des réponses assurées mais erronées à des définitions incohérentes, des tables obsolètes et d’autres problèmes de contexte, ce qui peut augmenter le nombre visible de défauts. Après avoir établi cette base de référence, elles ont toujours besoin d’une mesure de résultat montrant si les diagnostics conduisent à moins d’échecs récurrents et à davantage de réponses correctes au fil du temps.

Le contexte gouverné donne un sens métier aux informations récupérées

Le problème d’observabilité commence avec la manière dont les entreprises fournissent du contexte aux agents. La génération augmentée par récupération, ou RAG, consiste à trouver des contenus externes pertinents et à les fournir au modèle dans le prompt ; c’est l’approche principale pour 31% des entreprises, qui utilisent la récupération sur des documents. La similarité sémantique peut trouver un texte pertinent, mais la pertinence seule ne peut pas établir le sens métier qui doit gouverner une réponse.

Srijith Rajamohan, responsable de la recherche en IA chez Redis, a illustré cette limite dans un entretien avec VentureBeat plus tôt en 2026. “If you have a sentence like ‘Rome is closer than Paris’ and another that says ‘Paris is closer than Rome,’ and you do an embedding retrieval followed by a text search, you’re not going to be able to tell the difference,” a déclaré Rajamohan. “The same words exist in both sentences.” Redis vend une infrastructure de données utilisée pour la récupération en IA et des charges de travail associées, et a donc un intérêt commercial dans la manière dont les entreprises résolvent les problèmes de récupération et de contexte ; l’exemple montre comment un vocabulaire presque identique peut encoder des relations opposées.

La même limite devient plus lourde de conséquences lorsque les systèmes d’entreprise associent des définitions différentes à un même concept métier. Élargir une collection de documents ou un index de récupération donne à un agent davantage de matière, mais cette matière supplémentaire ne peut pas, à elle seule, réconcilier des définitions contradictoires. La gouvernance fournit un sens partagé qui permet à l’organisation de déterminer quelle définition s’applique, d’où elle vient et si le contexte derrière une réponse est valide.

D’autres entreprises s’appuient sur des approches moins structurées, et la répartition rend ces choix directement comparables.

Le chargement de contexte long place les documents directement dans la fenêtre de contexte du modèle au lieu de sélectionner les contenus via la récupération, tandis que le recours aux connaissances générales ne fournit aucun contexte métier structuré. Ensemble, ces deux dernières approches représentent près d’une entreprise sur cinq. Lorsqu’une erreur survient dans ces conditions, les équipes disposent d’une base plus faible pour distinguer des données obsolètes, des définitions incohérentes et d’autres défauts du contexte métier.

Cette différence de diagnostic sépare la fourniture d’information de la gouvernance. Donner plus d’informations à un modèle modifie les contenus à sa disposition, tandis que gouverner ces contenus établit la manière dont l’organisation en interprète le sens et la validité. Cette distinction compte lorsque les équipes choisissent une infrastructure puis décident comment mesurer si elle fonctionne.

Les achats distinguent les critères de gouvernance des résultats d’exactitude

Le choix de l’infrastructure reflète déjà cette distinction entre contrôle opérationnel et qualité des réponses. Le contrôle d’accès et les autorisations sont devenus un critère de sélection des systèmes de récupération pour 24% des entreprises, à égalité avec la facilité d’ingestion des données à 24%. Dans cette série d’enquêtes, une propriété de gouvernance a orienté la décision d’achat pour la première fois.

Une fois le système en fonctionnement, la métrique principale se déplace vers la qualité de sa sortie. L’exactitude des réponses est la principale métrique de succès pour 38% des entreprises, tandis que la sécurité et le contrôle d’accès constituent la métrique principale la plus proche suivante à 19%, soit exactement la moitié de la part de l’exactitude. Les critères de sélection et les métriques d’exploitation répondent à des questions différentes : les équipes peuvent choisir une infrastructure en partie pour le contrôle et l’ingestion, puis juger le système déployé principalement sur la justesse de ses réponses.

Maintenir ces questions séparées rend un plan d’évaluation plus utile. Les autorisations déterminent qui peut obtenir un contexte particulier, et l’ingestion détermine si les données requises peuvent entrer dans le système, tandis que l’exactitude mesure la réponse obtenue. Une plateforme peut améliorer la gouvernance et le diagnostic tout en enregistrant davantage d’échecs de contexte identifiés, parce que ses équipes sont aussi devenues meilleures pour attribuer des causes précises aux mauvaises réponses.

Cette possibilité rend importante la base de référence avant déploiement. Un nombre d’échecs diagnostiqués reflète ce que les enquêteurs peuvent trouver autant que ce que font les agents, tandis que l’exactitude des réponses reste la mesure de résultat indiquant si le système produit le bon résultat. Les équipes peuvent utiliser les contrôles d’accès et les références gouvernées pour examiner le système, tout en suivant séparément si les échecs répétés diminuent et si les réponses correctes augmentent.

L’adoption progresse plus vite que la gouvernance achevée

Cette difficulté de mesure se manifeste alors que les entreprises se trouvent à plusieurs stades d’adoption des couches de contexte. L’enquête de juillet répartit les répondants entre usage en production, mise en œuvre active, évaluation et groupes sans trajectoire de déploiement arrêtée.

Les deux premiers groupes placent 63% des entreprises dans la catégorie en exploitation ou en construction, tandis que l’activité de mise en œuvre devance le déploiement achevé. De nombreuses organisations mesurent donc les échecs de contexte alors même que leur infrastructure de gouvernance continue d’évoluer. L’adoption reste également inégale dans les autres étapes.

L’enquête VB Pulse de juin précédente ajoute une comparaison dans le temps, car elle posait exactement la même question sur les échecs. Entre juin et juillet, les échecs liés au contexte signalés, les échecs récurrents et le déploiement en production ont tous augmenté.

Ces évolutions se sont produites simultanément, mais cette séquence n’établit pas qu’une gouvernance accrue en production a causé une hausse du signalement des échecs. La gouvernance peut rendre certains problèmes plus faciles à retracer, tandis que d’autres changements entre les vagues d’enquête peuvent aussi affecter ce que les entreprises ont signalé. Ce chevauchement compte sur le plan opérationnel, car les équipes modifient à la fois leur infrastructure et leur capacité à détecter des défauts de contexte, ce qui rend un nombre brut d’échecs difficile à utiliser seul comme mesure de la santé du système.

La gouvernance du contexte contrôle aussi les entrées de la couche de décision de l’IA

À mesure que la mise en œuvre progresse, les entreprises choisissent aussi où doit résider le contrôle du contexte d’exécution. Soixante-dix-neuf pour cent prévoient de conserver au moins une partie des capacités de couche de contexte en dehors de la stack d’un fournisseur unique, via des outils best-of-breed ou une approche mixte explicite. Seuls 12% prévoient de consolider sur la stack de contexte native d’un seul fournisseur, ce qui indique que la plupart des entreprises s’attendent à ce que le contrôle du contexte traverse les frontières entre fournisseurs.

Ce choix architectural relie le dépannage au contrôle des décisions de l’IA. VentureBeat a régulièrement traité ce thème du multi-fournisseur et du contrôle en 2026, et Michael Ni, analyste chez Constellation Research, l’a formulé plus tôt dans l’année lorsque l’initiative de DataHub sur la couche de contexte est apparue pour la première fois : “Whoever controls runtime context, controls the AI decision layer for enterprise data,” a déclaré Ni. Le contexte d’exécution correspond aux informations et définitions gouvernées disponibles au moment où un système d’IA prend une décision ; le contrôle de ces entrées va donc au-delà du diagnostic des mauvaises réponses.

Ce contrôle plus large fait de la portabilité un élément de la décision de gouvernance. Une entreprise utilisant une architecture mixte peut conserver davantage d’influence sur l’endroit où le sens métier est défini et fourni à mesure que les modèles, les systèmes d’agents ou d’autres fournisseurs évoluent. La référence gouvernée utilisée pour enquêter sur une mauvaise réponse peut aussi déterminer qui contrôle les informations dont dépend une décision de l’IA.

Points clés

• Distinguer détection et fiabilité : Un contexte gouverné peut révéler des échecs auparavant invisibles, ce qui peut donner l’impression que la fiabilité déclarée se dégrade pendant le déploiement. Les responsables IA doivent établir une base de référence distincte pour l’exactitude des réponses et pour les échecs de contexte diagnostiqués, puis suivre les deux dans le temps.
• Considérer l’observabilité comme une composante du signalement des échecs : Les entreprises dotées d’un contexte gouverné ont signalé des échecs récurrents à un taux plus de deux fois supérieur à celui des entreprises qui n’en avaient pas, mais l’enquête n’établit pas des taux d’erreur sous-jacents plus élevés. Les équipes plateforme doivent tenir compte de la maturité du diagnostic lorsqu’elles comparent les taux d’échec entre systèmes ou unités métier.
• Gouverner le sens métier en plus de la récupération : Le RAG et des fenêtres de contexte plus larges peuvent fournir des informations pertinentes sans résoudre des définitions contradictoires, des données obsolètes ou des concepts métier ambigus. Les équipes data et IA doivent fournir aux agents des définitions gouvernées et une provenance qu’ils peuvent utiliser à l’exécution.
• Évaluer séparément gouvernance et exactitude : Le contrôle d’accès et l’ingestion dominent la sélection des systèmes de récupération, tandis que l’exactitude des réponses est la principale métrique d’exploitation. Les équipes achats doivent évaluer les capacités de gouvernance pendant que les responsables IA mesurent indépendamment si les réponses deviennent plus précises.
• Établir une base de référence avant le déploiement de la gouvernance : L’adoption en production des couches de contexte gouvernées a progressé en même temps que les échecs de contexte signalés entre juin et juillet, ce qui rend les nombres bruts d’échecs difficiles à interpréter. Les équipes de déploiement doivent capturer des métriques avant lancement afin qu’une meilleure détection ne donne pas l’impression d’une dégradation de la santé du système.
• Préserver la portabilité du contrôle du contexte d’exécution : La plupart des entreprises prévoient de conserver une partie des capacités de contexte en dehors de la stack d’un fournisseur unique. Les équipes d’architecture doivent préserver le contrôle des définitions gouvernées et du contexte d’exécution afin que le sens métier reste portable à mesure que les modèles et les fournisseurs évoluent.