Agent IA et données d’entreprise : préparer des réponses fiables

Avant de connecter un agent IA aux données de l’entreprise, préparez moins de sources, mais rendez-les compréhensibles et vérifiables. Une connexion réussie ne garantit pas une réponse juste : l’agent peut respecter les droits d’accès tout en utilisant une mauvaise définition du revenu, une période incomplète ou une jointure qui double les commandes.

Le bon point de départ tient en six preuves : question → source → définition → droit → vérification → action. Chaque métrique importante doit avoir un sens partagé, un propriétaire, une règle de calcul, une période et un résultat de référence. L’agent ne devient utile qu’après avoir réussi des tests sur les ambiguïtés, les données manquantes et les écarts avec les rapports existants.

L’objectif n’est donc pas de rendre toutes les données parfaites. Il est de construire le plus petit périmètre capable de produire une réponse fiable, explicable et suffisamment sûre pour guider une décision réelle.

Pourquoi préparer les données avant de connecter un agent IA ?

Le 10 septembre 2026, OpenAI a présenté son Data agent dans ChatGPT Work. Le produit peut interroger des entrepôts, des bases, des documents et des outils de business intelligence, puis construire des analyses et des tableaux de bord. L’annonce insiste aussi sur deux fondations moins spectaculaires : les définitions métier et les contrôles d’accès existants.

Le guide officiel du Data plugin recommande une couche sémantique contenant les définitions et requêtes de référence. Il demande également de vérifier la source, la période, les filtres et la définition de la métrique avant de s’appuyer sur un résultat. Autrement dit, le langage naturel simplifie la demande ; il ne supprime ni la modélisation ni la recette.

Ce lancement sert ici de signal de marché, pas de conclusion technologique. La méthode reste valable avec un autre agent, un outil de business intelligence ou une interface conçue dans un logiciel métier sur mesure. Les questions à résoudre demeurent les mêmes : que signifie la mesure, où se trouve sa source, qui peut la consulter et comment reconnaître une réponse acceptable ?

Une donnée accessible n’est pas encore une donnée interprétable

Imaginons trois équipes qui parlent du « chiffre d’affaires mensuel » :

• la direction financière utilise les factures émises hors taxes ;
• l’équipe commerciale compte les contrats signés ;
• le commerce en ligne suit les commandes payées, avant retours.

Les trois nombres peuvent être exacts dans leur contexte. Aucun ne répond automatiquement à la question « pourquoi le chiffre d’affaires a-t-il baissé ? ». Sans définition explicite, l’agent choisira une table, un filtre ou un indicateur disponible. Sa réponse pourra être bien formulée et pourtant comparer des réalités différentes.

Une couche sémantique résout une partie de ce problème. Elle traduit les tables, relations et calculs techniques en concepts métier partagés. La documentation Looker la décrit comme un point central pour les définitions, le contexte et les relations utilisés par les outils de BI et les modèles. Ce n’est pas nécessairement un nouveau logiciel : une première version peut être un registre versionné de quelques métriques critiques, relié aux requêtes ou modèles qui les calculent.

Cette couche doit répondre à des questions simples :

• que compte-t-on et que laisse-t-on de côté ?
• quelle date détermine la période : commande, paiement, facture ou livraison ?
• quelle table ou quel système fait autorité ?
• comment traite-t-on annulation, remboursement, doublon et donnée tardive ?
• à quelle fréquence la mesure est-elle actualisée ?
• qui valide une modification de sa définition ?

Si deux équipes ont légitimement besoin de deux définitions, conservez les deux. Nommez-les précisément. La cohérence ne consiste pas à imposer un chiffre unique ; elle consiste à empêcher deux chiffres différents de porter silencieusement le même nom.

La matrice Zence des six preuves

Remplissez une ligne par question métier prioritaire. Une entreprise n’a pas besoin de documenter tout son patrimoine de données avant un pilote. Elle doit rendre fiable la chaîne minimale qui répond à la décision choisie.

Preuve	Question à trancher	Artefact attendu	Signal d’arrêt
Question	quelle décision la réponse doit-elle éclairer ?	formulation, public, période et action envisagée	la demande reste « trouver des insights » sans décision
Source	où se trouvent les faits nécessaires ?	systèmes, tables, documents, fraîcheur et propriétaire	plusieurs copies existent sans source de référence
Définition	comment chaque métrique est-elle calculée ?	formule, dimensions, exclusions, dates et exemples	deux équipes utilisent le même nom pour des calculs incompatibles
Droit	qui peut voir quelles lignes, colonnes et pièces ?	rôles, restrictions, finalité et trace des accès	le pilote exige un compte trop large ou partagé
Vérification	comment comparer la réponse à une référence ?	questions test, résultats attendus, tolérances et erreurs interdites	aucune réponse historique ne peut être reconstruite
Action	que peut-on faire après la réponse ?	destinataire, validation, décision et repli	l’analyse déclenche une action sensible sans approbation

Cette matrice possède une intention plus étroite que le guide pour cadrer un agent IA en entreprise. Celui-ci traite la mission, les permissions et le pouvoir d’action d’un système agentique. Ici, le sujet est antérieur : rendre la question, les données et la mesure assez stables pour qu’une analyse ait un sens.

Construire un registre minimal de métriques

Commencez par cinq à dix métriques qui reviennent dans les décisions du processus choisi. Pour chacune, documentez :

1. Nommer la métrique sans abréviation ambiguë.
2. Décrire la question qu’elle aide à trancher.
3. Écrire la formule et les exclusions en langage courant.
4. Relier la définition à la requête, au modèle ou au rapport de référence.
5. Préciser la granularité, la période et la fréquence de mise à jour.
6. Attribuer un propriétaire métier et un propriétaire technique.
7. Conserver un exemple calculé sur une période figée.
8. Versionner tout changement qui rendrait deux réponses non comparables.

Prenons le taux de conversion d’un pipeline commercial. Le numérateur peut désigner les contrats signés, les premières factures payées ou les opportunités passées au statut « gagnée ». Le dénominateur peut inclure tous les contacts, les leads qualifiés ou seulement les opportunités ouvertes dans la même période. Le calcul change encore si une affaire créée en août est gagnée en septembre.

Le registre doit résoudre ces choix, pas seulement stocker une formule SQL. Ajoutez un exemple réel autorisé ou synthétique : nombre d’entrées, exclusions, résultat et explication. Lorsqu’une personne conteste la réponse de l’agent, cet exemple devient le premier point de comparaison.

Séparer les droits d’accès de la justesse du calcul

Un contrôle d’accès répond à « cette personne peut-elle consulter cette donnée ? ». Une définition métier répond à « cette donnée permet-elle de calculer la bonne mesure ? ». Les deux protections sont nécessaires, mais elles ne se remplacent pas.

OpenAI indique que les requêtes du Data agent appliquent les permissions du compte connecté, y compris les restrictions de table, ligne et colonne. Cette capacité doit être vérifiée dans l’environnement réel : rôle utilisé, connecteur, héritage des groupes et comportement lorsqu’une source secondaire est jointe. Un compte administrateur pratique pour la démonstration produirait une preuve inutilisable pour la production.

La CNIL rappelle dans son guide de sécurité que la protection des données concerne toutes les entreprises. Pour les données personnelles, les habilitations, l’authentification, la minimisation et la journalisation doivent suivre le risque et la finalité. Un agent d’analyse ne justifie pas de rendre accessibles des colonnes d’identité, de santé ou de ressources humaines lorsque la question ne les exige pas.

Testez au minimum trois profils : un lecteur autorisé, une personne qui ne doit voir qu’un périmètre et un compte sans accès. Vérifiez la réponse, mais aussi les sources proposées, les aperçus, les exports et les tableaux de bord partagés. Une restriction correcte dans la conversation peut être neutralisée si le résultat publié recopie des données dans un espace plus large.

Huit scénarios de recette avant le premier tableau de bord partagé

Une démonstration sur une question propre montre que l’agent peut fonctionner. Une recette prépare ce qui se passe lorsque la donnée ou la demande résiste.

Scénario	Test	Résultat attendu
Métrique ambiguë	demander « les clients actifs » sans autre précision	l’agent demande ou expose la définition retenue
Période incomplète	comparer le mois en cours à un mois terminé	la différence de couverture est signalée
Jointure multiplicative	relier commandes et lignes de commande	le total de commandes n’est pas doublé
Donnée tardive	rejouer une période après un import retardé	la fraîcheur et la date de calcul restent visibles
Source contradictoire	comparer entrepôt et tableau de bord	l’écart est montré avant toute conclusion
Droit insuffisant	interroger une région ou colonne interdite	l’accès est refusé sans contourner la restriction
Valeur extrême	introduire un montant exceptionnel mais valide	l’anomalie est expliquée, pas supprimée silencieusement
Action sensible	demander d’envoyer ou modifier après l’analyse	une validation explicite précède toute action

Pour chaque scénario, conservez la question exacte, les sources consultées, le résultat de référence, la réponse obtenue, l’écart, la décision et la personne responsable. Ce dossier permet de rejouer la recette après une modification de connecteur, de modèle, de définition ou de schéma.

La CNIL recommande pour les systèmes d’IA de vérifier qualité et fiabilité des sources, de contrôler les accès, de documenter le fonctionnement et de surveiller l’évolution des données. Même si cette fiche traite plus largement de conception et d’apprentissage, ces principes éclairent l’intégration d’un agent : une réponse fiable aujourd’hui n’est pas acquise pour toujours.

Exemple fictif : expliquer une baisse de revenu sans mélanger les périodes

L’exemple suivant est fictif. Une PME vend des abonnements et des prestations ponctuelles. La direction demande pourquoi le revenu a baissé au dernier trimestre.

L’entrepôt contient les factures, les avoirs et les paiements. Le CRM conserve les contrats et les opportunités. Un tableau de bord marketing suit les nouvelles commandes. Avant de connecter un agent, l’équipe écrit que le « revenu reconnu » provient des factures hors taxes, nettes des avoirs, selon la date de prestation. Le « revenu encaissé » utilise les paiements reçus. Les contrats signés restent un indicateur avancé, jamais additionné au revenu.

La première recette compare quatre questions déjà calculées manuellement : revenu par mois, nouveaux abonnements, résiliations et avoirs. Un test ajoute une facture tardive et un autre demande une ventilation par commercial à une personne qui ne doit voir que sa région.

L’agent identifie finalement une baisse des prestations ponctuelles, tandis que les abonnements restent stables. Cette réponse ne prouve pas une cause commerciale. Elle localise un écart vérifié et prépare la question suivante : moins de prestations ont-elles été vendues, réalisées ou facturées ? Le système aide à enquêter ; il ne transforme pas une corrélation en explication.

Lancer un pilote de trente jours sans ouvrir toutes les sources

Un pilote utile reste borné à un groupe, une décision et quelques métriques. La méthode peut suivre quatre temps.

Semaine 1 — fixer la référence

Choisissez cinq questions réellement posées lors d’une revue de performance. Documentez les définitions et reconstruisez les réponses de référence. Si cette étape échoue, corrigez d’abord la donnée ou réduisez le périmètre.

Semaine 2 — connecter en lecture seule

Ouvrez uniquement les sources nécessaires avec les rôles réels. Exécutez les scénarios nominaux, ambigus et interdits. Aucune action externe ne doit dépendre automatiquement de la réponse.

Semaine 3 — confronter aux usages

Faites tester l’agent par les personnes qui connaissent les décisions. Mesurez le temps total, les demandes de clarification, les écarts, les corrections et les questions qui sortent du périmètre. Une réponse plus rapide ne vaut rien si sa vérification prend davantage de temps que le rapport précédent.

Semaine 4 — décider et préparer la sortie

Comparez le résultat à la ligne de base. Décidez de maintenir, corriger, élargir ou arrêter. Exportez le registre de métriques, les questions de recette et les écarts. Révoquez les accès inutiles, même si le pilote continue.

Le canvas de preuve produit aide à écrire l’hypothèse, le signal de réussite et la condition d’arrêt. Si le choix de l’outil reste ouvert, utilisez ensuite la méthode pour comparer une solution IA sur le même jeu de test. Si le processus lui-même demeure flou, revenez au guide pour observer avant d’automatiser.

Quand ne faut-il pas construire un agent de données ?

Un agent n’est pas la bonne première réponse lorsque :

• deux équipes ne peuvent pas encore nommer la décision commune ;
• la donnée de référence n’existe pas ou n’a pas de propriétaire ;
• le besoin se résume à un rapport stable actualisé chaque semaine ;
• une requête ou un tableau de bord répond déjà de façon claire et maintenable ;
• le volume ne justifie pas le coût de connexion, de recette et d’exploitation ;
• les droits nécessaires seraient plus larges que la mission ;
• personne ne peut vérifier la réponse ni assumer la décision suivante.

Dans ces cas, un registre de métriques, un rapport corrigé ou une intégration simple peut produire davantage de valeur. Le Lean n’économise pas la qualité : il réduit le périmètre nécessaire pour obtenir une preuve complète.

Quelle première décision prendre ?

Prenez une question posée lors de la dernière réunion de pilotage. Écrivez la décision qu’elle devait éclairer, la définition de chaque métrique, la source, la période et la personne autorisée à voir le résultat. Comparez ensuite la réponse de référence à cinq formulations différentes de la même question.

Si les réponses divergent, ne connectez pas davantage de données. Corrigez la définition, la source ou la recette. Si elles restent cohérentes et que les droits tiennent, un pilote en lecture seule devient raisonnable.

Zence conçoit des produits et logiciels métier lorsque l’interface, les règles et les intégrations propres à l’entreprise justifient du sur-mesure. Pour un agent de données, le premier livrable peut rester plus petit : une cartographie des sources, un registre de métriques, huit scénarios et une décision documentée. Construire moins, mais finir ce qui compte.

Sources principales

• OpenAI — Now everyone can put data to work, publié le 10 septembre 2026 ; lancement, sources compatibles, contexte métier, permissions et actions approuvées.
• OpenAI Help — Using the Data plugin in ChatGPT Work and Codex, consulté le 16 septembre 2026 ; couche sémantique, vérifications, accès et partage.
• Google Cloud — Looker modeling, consulté le 16 septembre 2026 ; définition d’une couche sémantique, métriques, contexte et relations.
• CNIL — Sécurité des données : les règles essentielles, mis à jour le 19 juin 2026 ; accès, authentification, sauvegarde et mesures proportionnées.
• CNIL — Sécurité : intelligence artificielle, conception et apprentissage, publié le 14 mars 2024 ; qualité des sources, habilitations, documentation, tests et surveillance.