Vos agents IA liront vos chiffres et vos politiques : lesquels ont une version officielle ?

Les définitions de vos chiffres ont un propriétaire. Vos politiques n'ont souvent qu'une date de dépôt. Un relevé de parité mesure l'écart avant l'agent.

Un agent de crédit client qui décide de bloquer une commande lit deux choses : l’encours du client, un chiffre, et la politique de crédit, un document. Le 3 novembre, un éditeur de plateforme de données a annoncé un service qui ne sert à ses agents que les définitions approuvées, chacune avec un propriétaire. Son propre texte range « quelles politiques suivre » parmi le contexte dont les agents ont besoin (traduction libre). Le retournement tient en une phrase de comité : si rien n’est écrit sur la politique, vos agents liront un chiffre qui a un propriétaire et une politique qui n’a qu’une date de dépôt.

Le contexte des agents IA a donc deux moitiés. La première, les données, reçoit une discipline que les CDO connaissent : définition approuvée, propriétaire, historique des changements. La seconde, les documents, reçoit une recherche plus pertinente et plus rapide. Rien, dans ces annonces, ne déclare lequel de vos documents est en vigueur. Or c’est la politique qui dit à l’agent quoi faire du chiffre.

La personne pour qui ce texte est inconfortable est le CDO à qui le comité de mise en production demandera de confirmer que le contexte de l’agent est gouverné. Pour l’encours, il répondra en une recherche s’il a fait ce travail sur ses indicateurs. Pour la politique de crédit, il cherchera un propriétaire, une version officielle, une date d’effet. Sur le document lui-même, il n’en trouvera peut-être aucun.

Deux réponses semblent déjà couvrir le sujet. La première est l’outil acheté : étendre le glossaire ou l’ontologie métier aux documents, s’en remettre au versionnage de la GED, ou compter sur un moteur de recherche plus précis. Un glossaire définit un terme. Déclarer qu’un texte engage l’entreprise à partir d’une date est un autre acte. La GED, de son côté, numérote les versions : la plus récente y est la dernière déposée, ce qui peut être un projet. Un moteur plus précis trouve plus vite le bon document et le mauvais. La seconde est le processus maison : la politique a été validée en comité, puis déposée. La validation existe, dans un compte rendu que l’agent ne lit pas.

Cet article s’adresse aux CDO et aux responsables de programmes d’agents qui préparent les mises en production de 2027. Si votre premier agent ne lit encore que des données, l’argument tiendra le jour où il lira sa première politique. Dans notre série AI Readiness, l’article du 28 octobre mesurait la readiness comme un délai, le temps d’arbitrer par écrit les règles d’une tâche ; celui-ci la mesure comme un écart, entre ce que vous avez déjà fait pour vos chiffres et ce qui manque à vos politiques.

Le geste proposé tient en une heure : prendre les trois politiques que lira votre premier agent et leur poser les trois questions que vous posez déjà à un indicateur. Il est détaillé plus bas.

Deux annonces de novembre : une version officielle pour les définitions, une meilleure recherche pour les fichiers

Le service annoncé le 3 novembre s’appelle Business Ontology, chez Snowflake, en préversion publique annoncée « prochainement »¹. Sa meilleure forme mérite d’être décrite telle que l’éditeur l’écrit. Une équipe définit un terme, par exemple « chiffre d’affaires net », lui donne un périmètre (finance), nomme un propriétaire, le fait approuver et le relie à la vue qui le calcule. Selon l’éditeur, seules les définitions approuvées sont servies à ses agents. Quand une définition approuvée contredit ce que le système a déduit seul, l’agent suit la définition approuvée.

C’est exactement la discipline d’un data catalog, portée jusqu’à l’agent. Et l’éditeur écrit lui-même, dans sa foire aux questions, que les agents ont besoin de références approuvées qui leur disent quelle définition croire, quelles politiques suivre et quelle connaissance de l’entreprise intégrer (traduction libre). Le produit gouverne la première de ces trois choses. Appliquer la même exigence aux politiques est notre lecture ; Snowflake ne la fait pas.

Deux jours plus tard, le 5 novembre, Box a annoncé Box Context Retrieval, disponible pour ses clients Enterprise Advanced début 2027². Son communiqué part du bon constat : le contexte des agents vient des fichiers, « contrats, politiques, historique client » (traduction libre). Le moteur promet une recherche plus précise, limitée à ce que l’utilisateur a le droit de voir, étendue aux documents scannés, et des contenus nouveaux ou mis à jour disponibles pour les agents en temps réel.

Ces trois promesses répondent à trois vraies questions : trouver, respecter les droits, être à jour. Elles laissent ouverte une quatrième, qui n’est pas l’objet du communiqué : parmi les documents trouvés, lequel engage l’entreprise aujourd’hui ? Le temps réel la rend même plus pressante. Le délai d’indexation, quel qu’il soit, laissait un brouillon hors de portée pendant un temps ; ce tampon se réduit.

Ce que l’agent de crédit lit, et ce qui change quand la politique est fiable

Reprenons la tâche. L’agent de crédit client reçoit une commande. Il lit l’encours du client, dans l’entrepôt de données, et la politique de crédit, dans une bibliothèque documentaire. La politique dit à partir de quel encours une commande se bloque et qui peut lever le blocage.

Côté chiffre, si votre programme data a fait son travail, l’agent lit une définition approuvée : quel encours (échu, non échu, assurance-crédit déduite), qui en répond, depuis quand. Côté document, l’agent lit le fichier que la recherche a classé en tête. Il connaît son titre, sa date de dépôt, éventuellement son auteur. Il ne connaît ni son statut, ni sa date d’effet, ni la personne qui en répond, sauf si ces mentions sont écrites sur le document.

Au comité de mise en production, le directeur du crédit demande : « Le seuil que l’agent applique, il vient d’où ? » Le CDO ouvre le catalogue et montre la définition de l’encours, son propriétaire, sa date d’approbation. Puis il ouvre la politique. Il cherche une mention « en vigueur », une date d’effet, un nom de titulaire. Il trouve un fichier, une date de dépôt, et rien d’autre qu’il puisse montrer.

Ce qui change quand la politique est fiabilisée tient en trois mentions écrites sur le document : version officielle, propriétaire, date d’effet. L’agent peut alors citer une règle et son titulaire, comme il cite un chiffre et son propriétaire. Sa décision devient défendable des deux côtés. Et le travail se fait une fois par politique, pas une fois par agent : l’agent de recouvrement qui lira la même politique en mars hérite des trois mentions. C’est là que la transition agentique s’accélère. Ce gain n’est pas mesuré ; il se vérifie au deuxième agent, quand la question du comité trouve sa réponse sur le document au lieu de la trouver en réunion.

Ce que montre le terrain : 32 % de doublons divergents dans une même base

Dans un groupe industriel du CAC 40, 32 % de la base se sont révélés constitués de doublons divergents, remontés en 2 semaines et résolus en 6. Un doublon divergent est un document présent en plusieurs exemplaires qui ne disent plus la même chose.

Ce que cette mesure établit : dans une base d’entreprise réelle, 32 % du contenu existait en exemplaires divergents, et chacun de ces cas appelait une décision sur l’exemplaire à retenir. Ce qu’elle n’établit pas : l’effet sur un agent, qui n’était pas mesuré, ni la part de politiques dans ces doublons, ni la présence ou l’absence de mentions de statut sur les documents. Elle montre que la question de l’exemplaire à retenir peut porter sur une part importante d’une base, dans un cas. Pas forcément dans le vôtre.

Le relevé de parité : trois politiques, trois questions, une heure

Le geste emprunte au CDO ce qu’il fait déjà pour ses indicateurs.

Ce qu’il produit. Un relevé de parité : un tableau de trois lignes, une par politique, et quatre colonnes. Version officielle (référence et version, telles qu’écrites sur le document). Propriétaire (un rôle nommé). Date d’effet (écrite sur le document). Indicateur associé (celui que l’agent lit à côté, avec son propriétaire déjà connu).

Son domicile. La fiche des sources de l’agent, dans le dossier de mise en production que tient l’équipe du programme. Le relevé tient en trois lignes ajoutées à un document qui existe déjà.

Son moment. À l’écriture de la liste des sources de l’agent, avant la revue de mise en production.

L’échantillon. Les trois politiques que la description de tâche de l’agent cite ou suppose. Si l’agent en lit moins de trois, toutes. La liste se constitue avec l’équipe projet, à partir de la consigne de l’agent.

Une ligne remplie. « Politique de crédit client, réf. FIN-CR-04, version 3 indiquée en pied de page ; propriétaire : directeur du crédit ; date d’effet : non écrite ; indicateur associé : encours client échu, propriétaire contrôle de gestion, définition approuvée. »

Sa règle de lecture. Les trois mentions sont écrites sur le document : l’agent peut appliquer la politique dans le périmètre accordé. Une mention manque : l’agent cite la politique et sa date, et un humain confirme avant toute action qui s’appuie sur la règle. Le propriétaire de la politique écrit la mention manquante ; c’est une attribution ajoutée à son rôle existant de responsable du processus.

Son mode d’échec. Si les trois mentions existent pour les trois politiques, vous aurez perdu une heure et gagné une pièce à montrer au comité. Si elles manquent, vous aurez trouvé l’écart avant l’agent. Le relevé daté reste une pièce opposable : si une décision de l’agent est contestée plus tard, il montre ce qui était su au moment de la mise en production. L’écrire reste préférable à ne rien savoir ; la portée juridique d’une telle pièce relève de votre direction juridique.

Son budget. Le programme d’agents 2027, au titre de la préparation des sources. Aucune ligne nouvelle.

Auditer, nettoyer, surveiller

Le relevé de parité porte sur trois politiques. Le patrimoine qu’un programme d’agents ouvre peut en compter des centaines. C’est l’objet d’une catégorie distincte, la Document Knowledge Platform (DKP) : Govern, gouverner le patrimoine documentaire (propriété, autorité, cycle de vie) ; Clean, détecter et traiter anomalies, doublons, obsolescence et versions concurrentes ; Activate, n’ouvrir le corpus aux systèmes d’IA qu’une fois les deux premières étapes tenues. Une DKP ne remplace ni un data catalog, ni une ontologie métier, ni un moteur de recherche, ni une plateforme d’agents. Elle s’exécute avant eux, sur les documents qu’ils consomment.

Auditer. Dénombrer, dans les bibliothèques que l’agent lira, les documents sans version applicable identifiable, les versions concurrentes et les textes obsolètes. Pour rattacher une politique à la tâche d’un agent, l’outil propose des documents candidats ; l’équipe confirme. La lecture porte sur le contenu documentaire seul, dans un périmètre d’ingestion fixé contractuellement et validé par le Document Owner métier et le RSSI ou le DPO, sans journaux d’usage ni conversations, et sans réutilisation pour entraîner des modèles.

Nettoyer. Router chaque cas vers le propriétaire du processus, qui tranche. Les experts métier restent maîtres de la décision.

Surveiller. Une politique révisée change de version, de propriétaire ou de date d’effet. Le relevé se met à jour au même moment, sinon l’agent de mars lira la version de novembre avec les mentions de novembre.

La parité ne se décrète pas pour tout le patrimoine en une fois. Elle se gagne politique par politique, en commençant par celles que lira le premier agent. Le CDO pourra alors répondre au comité pour la politique de crédit comme il répond pour l’encours.

Foire aux questions

Nos agents ont déjà un glossaire métier approuvé. Cela ne couvre-t-il pas les politiques ?

Un glossaire définit ce que veut dire un terme. Il ne déclare pas qu’un document engage l’entreprise à partir d’une date. Les deux sont nécessaires : le terme « encours » doit être défini, et la politique qui fixe le seuil doit être désignée comme la version officielle.

Un meilleur moteur de recherche ne suffit-il pas à donner le bon document à l’agent ?

Il donne plus vite le document le plus pertinent pour la question. Si deux versions de la politique sont pertinentes, il en sert une. Désigner la version officielle reste une décision humaine, écrite sur le document, que le moteur lit ensuite.

Qui doit écrire la version officielle et la date d’effet d’une politique ?

Son propriétaire, c’est-à-dire le responsable du processus qu’elle encadre : la direction du crédit pour une politique de crédit, les achats pour une politique achats. L’équipe du programme d’agents tient le relevé ; elle ne décide pas du statut.

Que fait l’agent tant que les mentions ne sont pas écrites ?

Il cite la politique et sa date de dépôt, et un humain confirme avant toute action qui s’appuie sur la règle. Cette conduite se lève politique par politique, à mesure que les mentions sont écrites.

Une plateforme DKP lit-elle le contenu de nos politiques internes ?

Oui, dans un périmètre d’ingestion fixé contractuellement et validé par le Document Owner métier et le RSSI ou le DPO. Seul le contenu documentaire est lu, sans journaux d’usage ni conversations, et rien n’est réutilisé pour entraîner des modèles.

Notes

¹ Snowflake, billet « Business Ontology Governs Business Concepts and Metrics for AI and Analytics », 03/11/2026 : Business Ontology « (public preview soon) » ; « Only approved definitions are served to AI agents » ; les agents ont besoin de « approved references that tell them which definition to trust, which policies to follow and what corporate knowledge to incorporate ». Snowflake figure parmi les partenaires technologiques de K-AI. ² Box, communiqué Business Wire du 05/11/2026, « Box Partners With NVIDIA to Deliver the Trusted Content Layer for Enterprise AI » : contexte des agents issu des fichiers « such as contracts, policies, customer history » ; retrieval « permission-aware » ; contenus nouveaux et mis à jour disponibles « in real time » ; disponibilité générale pour Enterprise Advanced « early next year ». Les gains chiffrés annoncés par l’éditeur ne sont pas repris ici.

Sources

Pour aller plus loin

K-AI Corpus Diagnostic — 10 jours ouvrés, rapport complet des 20 anomalies les plus critiques de votre référentiel documentaire, garantie remboursement si aucune anomalie valable n’est détectée. Un échange d’une heure part de votre relevé de parité : il situe les bibliothèques où vos politiques n’ont ni version officielle, ni propriétaire, ni date d’effet écrite, et précise par où commencer. Contactez l’équipe K-AI : contact@k-ai.ai. Le périmètre de chaque diagnostic est validé conjointement par le Document Owner métier et le RSSI/DPO, jamais par la seule DSI.

K-AI accompagne déjà CMA CGM, Veolia, PwC, BNP Paribas, TotalEnergies et CEVA Logistics. Partenaires : AWS, Snowflake, Microsoft, Wavestone, Devoteam.