Agents IA et données d’entreprise : pourquoi les définitions métiers font la différence

Une question simple peut recouvrir plusieurs calculs légitimes

« Quels fournisseurs sont en retard ? » La question semble précise. Faut-il compter les commandes, leurs lignes ou les livraisons ? Comparer la réception à la date promise initiale ou renégociée ? Inclure les commandes encore ouvertes ? Sans ces réponses, un agent peut produire une requête valide, un tableau cohérent et une conclusion impropre à la décision attendue.

Un agent data associe généralement un modèle de langage à des outils permettant de rechercher des informations ou d’interroger des données. La validité technique d’une requête ne prouve pas la validité métier de son résultat. L’utilisateur attend que ses mots désignent les mêmes objets et les mêmes règles que dans ses processus de travail.

La démarche proposée ici commence donc par un contrat de sens : questions couvertes, définitions retenues, calculs disponibles et situations exigeant une clarification. L’objectif est de rendre les réponses contrôlables. Un agent doit aussi pouvoir dire qu’une information manque ou que son périmètre ne permet pas de conclure.

Construire un lexique relié aux données et aux décisions

Recueillez les expressions réellement utilisées dans les réunions, les demandes d’analyse et les rapports. Pour chaque terme, associez un identifiant stable, une définition, un domaine, des synonymes, un responsable et les objets techniques correspondants. Un synonyme rapproche deux formulations équivalentes ; il ne doit pas masquer deux concepts différents.

Ainsi, « fournisseur actif » peut signifier référencé et non bloqué pour les achats, ou facturé au cours des douze derniers mois pour la finance. Conservez ces deux définitions sous des noms explicites. Le contexte permet de sélectionner la bonne ; s’il reste insuffisant, l’agent demande laquelle appliquer. Un mot comme « activité » ne doit pas devenir un raccourci arbitraire vers une colonne.

Versionnez les définitions avec leur date d’effet et la raison des changements. Distinguez la date de validation d’une règle de la période des données concernées. Une nouvelle définition peut s’appliquer aux prochains mois, ou imposer un recalcul historique : ce choix appartient au métier et doit être documenté.

Décrire chaque indicateur comme un contrat calculable

La définition narrative doit déboucher sur une mesure testable. Voici une fiche proposée pour un taux de retard fournisseur ; elle décrit une convention illustrative, à adapter aux engagements réels de l’entreprise. Son intérêt est de rendre visibles les décisions que le nom de l’indicateur laisse habituellement implicites.

Ajoutez au contrat une requête ou une mesure de référence, quelques exemples attendus et les règles de contrôle. Pour consolider un taux, additionnez les numérateurs et dénominateurs compatibles avant de diviser. La moyenne simple des taux de sites ayant des volumes différents peut répondre à une autre question que celle du taux global.

Maîtriser le grain et les jointures avant de générer du SQL

Le grain décrit ce que représente une ligne : commande, ligne de commande, réception, facture ou instantané quotidien. Deux tables portant sur le même fournisseur peuvent avoir des grains incompatibles. Déclarez les clés primaires, les clés étrangères, les cardinalités attendues et le traitement des clés absentes. Vérifiez-les sur les données ; leur présence dans une description ne garantit pas leur respect.

Exemple : une ligne de commande de 100 euros possède deux réceptions et trois factures partielles. Joindre directement ces deux historiques à la ligne produit jusqu’à six combinaisons. Le montant de commande peut alors être répété six fois. Un DISTINCT ajouté après coup n’est pas une correction générale : deux événements distincts peuvent légitimement porter le même montant.

Préagrégez chaque flux au grain commun nécessaire, ou exposez des vues et mesures validées. Testez la conservation des montants, les multiplications de lignes et les pertes dues aux jointures internes. Microsoft souligne également l’importance d’un grain constant et de relations maîtrisées dans les modèles en étoile. Cette discipline de modélisation reste utile lorsque l’interface devient conversationnelle.

Rendre les dates, les périmètres et les absences explicites

« Le mois dernier » doit être résolu en dates précises selon le fuseau et le calendrier métier. La date de commande, la date promise et la date de réception définissent des populations différentes. La réponse doit rappeler celle qui a servi au calcul. Pour les comparaisons, contrôlez aussi les changements de périmètre : sites ouverts, fournisseurs regroupés ou activités transférées.

Un historique des statuts est parfois indispensable. Une table décrivant uniquement l’état actuel ne permet pas toujours de reconstruire les commandes ouvertes à une clôture passée. De même, si la dernière date promise écrase la date initiale, l’agent ne peut pas mesurer la ponctualité par rapport à l’engagement d’origine. Il doit exposer cette limite.

Distinguez zéro, absence de données et donnée non accessible. Afficher zéro incident lorsqu’un site n’a rien transmis modifie le sens du résultat. Prévoyez des contrôles de couverture et de fraîcheur associés à chaque indicateur, ainsi qu’un seuil au-delà duquel la réponse est accompagnée d’une réserve ou suspendue.

Articuler catalogue, couche sémantique et contexte de l’agent

Le catalogue aide à trouver les données, comprendre leur provenance et identifier leurs responsables. La couche sémantique met à disposition des objets analytiques cohérents : mesures, dimensions, relations et règles d’agrégation. Le contexte fourni à l’agent lui indique comment utiliser ces éléments pour interpréter une question. Ces fonctions peuvent partager une plateforme, mais elles répondent à des besoins distincts.

Évitez de maintenir une définition dans le catalogue, une autre dans un fichier d’instructions et une troisième dans le modèle BI. Choisissez une source de référence par type d’information, puis organisez sa diffusion. Une règle de calcul critique gagne à être implémentée dans une mesure contrôlée plutôt que réinventée à chaque conversation.

Google documente des contextes incluant descriptions, synonymes, exemples de requêtes et relations. Microsoft recommande de préparer les modèles sémantiques utilisés par Copilot, notamment en réduisant les ambiguïtés et en organisant les champs. Ces mécanismes soutiennent une démarche métier ; ils ne valident pas automatiquement les définitions choisies.

Combiner recherche documentaire et interrogation des données

Pour expliquer une procédure achats, un système peut retrouver des passages documentaires pertinents et les fournir au modèle : c’est la génération augmentée par recherche, ou RAG. Pour calculer les lignes en retard, il faut interroger toute la population pertinente avec un moteur adapté, par exemple SQL ou une couche sémantique.

Retrouver quelques extraits proches d’une question ne garantit pas un total exhaustif. Inversement, une requête SQL peut fournir un chiffre sans expliquer une exception prévue par la procédure. Une réponse peut donc associer un calcul et une explication documentaire, avec leurs sources respectives.

Conservez cette distinction à l’écran : le résultat calculé, sa période et son périmètre ; puis la règle documentaire, sa version et son origine. Si les deux se contredisent, signalez l’écart au responsable. Une explication bien rédigée ne doit pas rendre invisible une divergence entre la règle approuvée et son implémentation.

Exemple fictif : deux définitions produisent deux taux exacts

Dans cet exemple entièrement fictif, quatre lignes de commande ont une échéance initiale en septembre. Elles sont toutes éligibles et leurs quantités sont connues. Au 30 septembre, la ligne A a été reçue intégralement avant son échéance. B a été reçue trois jours après. C a été reçue après sa date initiale, mais avant une nouvelle date négociée. D reste incomplète après son échéance.

Avec la date promise initiale, B, C et D sont en retard : le taux est de 3 sur 4, soit 75 %. Avec la dernière date négociée, seules B et D le sont : 2 sur 4, soit 50 %. Dans cet exemple, les deux dates de C restent en septembre ; une date déplacée vers octobre modifierait aussi la population mensuelle.

À la question « Quel est notre taux de retard de septembre ? », l’agent demande quelle convention appliquer si aucun défaut approuvé n’existe. L’utilisateur choisit l’engagement initial, y compris les lignes encore ouvertes. La réponse donne alors 75 %, rappelle la convention et permet de retrouver les quatre lignes. Aucun gain de performance n’est supposé : l’exemple montre comment lever une ambiguïté.

Évaluer les réponses attendues, les clarifications et les refus

Constituez un jeu de recette avec les métiers avant de multiplier les utilisateurs. Pour chaque question, conservez l’identité de test, les données de référence, la version des règles et le comportement attendu. Certaines questions appellent un chiffre ; d’autres une clarification, un refus ou l’explication d’une impossibilité.

Comparez les résultats et leurs justifications utiles, plutôt que la seule forme du SQL : plusieurs requêtes peuvent être correctes. Rejouez des formulations différentes, des conversations à plusieurs tours et des cas limites. Séparez les questions utilisées pour configurer l’agent de celles réservées à son évaluation.

Faire appliquer les droits à chaque accès aux données

L’accès à un agent et l’accès aux données sont deux autorisations distinctes. Google l’explicite pour sa Conversational Analytics API : les permissions sur les ressources de l’agent ne remplacent pas celles de la source interrogée. Pour votre architecture, identifiez précisément sous quelle identité chaque requête s’exécute.

Une consigne comme « ne montre pas les données confidentielles » n’est pas un mécanisme d’autorisation. Faites appliquer les restrictions de lignes, colonnes et documents par les services qui délivrent l’information. Si un compte technique est utilisé, son périmètre doit rester compatible avec les droits de l’utilisateur ; une connexion commune trop privilégiée exige un contrôle serveur robuste et testé.

Pour un assistant d’analyse, limitez les outils exposés aux lectures autorisées. Prévoyez des limites de durée, de volume traité et de coût, ainsi qu’un contrôle des sources interrogées. Une requête correcte sur le plan métier peut rester trop coûteuse ou trop large. Si l’assistant peut aussi modifier des données ou lancer un processus, séparez ces outils et définissez les validations requises avant leur exécution ; une demande ambiguë ne doit pas déclencher une action irréversible.

Contrôlez également les résultats en cache, les historiques partagés, les exports et les passages documentaires injectés dans le contexte. Testez le changement d’utilisateur et la révocation d’un droit. Les contenus trouvés dans les documents sont des données à interpréter : ils ne doivent pas pouvoir modifier les autorisations ou déclencher librement de nouveaux outils.

Publier le contexte avec des contrôles et des versions

Un tableur peut convenir pour recueillir les premières définitions avec les métiers. Les imports manuels deviennent fragiles lorsque plusieurs domaines, environnements et versions évoluent ensemble. Définissez alors un format structuré et une chaîne de publication reproductible, en utilisant les API disponibles dans les produits concernés.

Notre séquence recommandée est simple : proposition d’un changement, validation métier, contrôles automatiques, déploiement en environnement de test, recette, puis publication. Les contrôles détectent les identifiants manquants, les références à des colonnes supprimées, les synonymes conflictuels et les règles sans propriétaire. Préservez une version précédente permettant de revenir rapidement en arrière.

Google permet notamment de transmettre un contexte lors de la création d’un agent ou dans une requête sans état. Quel que soit le mécanisme, vérifiez après publication ce qui a réellement été chargé. Un appel API réussi ne prouve pas que la nouvelle définition est utilisée : rejouez les questions affectées et contrôlez la version active.

Étendre le périmètre à partir de preuves d’utilité

Commencez par un domaine cohérent, des utilisateurs identifiés et une collection de questions fréquentes. Le nombre de tables ne constitue pas, à lui seul, un critère de qualité. Il n’existe pas de règle universelle imposant dix tables par agent. Les limites propres à un produit doivent être vérifiées dans sa documentation, puis complétées par vos tests.

Plusieurs agents peuvent devenir utiles lorsque les responsabilités, les règles ou les périmètres d’accès divergent. Ce découpage ajoute aussi du routage, des échanges de contexte et des risques de réponses incompatibles. Testez d’abord si un agent correctement outillé couvre le besoin ; une architecture multiagents n’est pas un préalable.

En exploitation, journalisez les éléments nécessaires au diagnostic : version de configuration, sources consultées, requête exécutée, filtres, fraîcheur, durée, coût et résultat des contrôles. Protégez ces traces et limitez les données sensibles conservées. Suivez les erreurs métier, les clarifications, les abandons et les corrections humaines. Rejouez la recette après les changements de modèle ou de données. L’indicateur décisif reste la capacité des utilisateurs à prendre une décision correctement éclairée.

Questions fréquentes