Connecter un agent IA au CRM, à l’ERP ou aux bases documentaires d’une entreprise est devenu relativement accessible. Mais cet accès ne garantit en rien la pertinence de ses réponses. En effet, pour interpréter correctement les informations, l’IA doit aussi connaître leur signification, leur origine et les règles qui encadrent leur utilisation. Un prérequis (trop) souvent sous-estimé.
Connecter une IA aux données de l’entreprise est juste une première étape
Avec les architectures RAG, les API et les connecteurs applicatifs, les entreprises peuvent désormais donner à leurs assistants IA accès à des volumes considérables d’informations internes. Contrats, factures, historiques commerciaux, procédures ou indicateurs de performance deviennent interrogeables en langage naturel. Cette ouverture constitue certes un progrès important, car elle permet à l’IA de travailler sur des informations propres à l’organisation plutôt que sur les seules connaissances acquises pendant son entraînement. Mais elle expose aussi les incohérences d’un système d’information construit au fil des années.
Un CRM peut par exemple présenter un client comme actif alors que l’ERP indique plusieurs factures impayées. Tout comme deux applications peuvent conserver des adresses différentes, utiliser des identifiants incompatibles ou appliquer des règles de calcul distinctes.
L’agent dispose alors de plusieurs informations potentiellement exactes dans leur contexte, mais contradictoires lorsqu’elles sont rapprochées… Sans indication sur la source faisant autorité, il risque de produire une réponse (convaincante) à partir d’une interprétation erronée.
C’est notamment pour répondre à cette difficulté qu’un travail est aujourd’hui mené autour de la notion de « Context-Aware AI », à savoir une IA capable de tenir compte du contexte métier, opérationnel et informationnel dans lequel elle intervient.
Une même donnée peut avoir plusieurs significations selon les métiers
Mais ce contexte commence par des questions de vocabulaire que les organisations elles-mêmes n’ont pas toujours résolues.
Que désigne exactement un « client actif » dans votre entreprise ? Pour vos commerciaux, il peut s’agir d’une entreprise ayant récemment échangé avec un chargé de compte ou disposant d’une opportunité ouverte. Mais pour la finance, ce statut peut dépendre d’une facturation effective au cours d’une période donnée…
Les deux définitions répondent à des besoins légitimes, mais elles ne produiront pas les mêmes résultats si vous demandez à un agent IA de dresser la liste de vos clients actifs. Et là ça coince.
Le problème concerne aussi les indicateurs. Un chiffre d’affaires peut être exprimé en HT ou TTC, facturé ou encaissé, consolidé ou limité à une filiale. Une marge peut intégrer certains coûts dans un service et les exclure dans un autre…
Bref, la multiplication des sources rend ces différences plus visibles, et peut aussi les rendre plus difficiles à détecter lorsqu’une IA synthétise les résultats sans exposer les règles employées.
Il devient donc indispensable de définir les concepts métier avant de les rendre accessibles aux modèles. Une définition commune peut bien sûr coexister avec plusieurs variantes, à condition de préciser leurs usages et leurs conditions de calcul !
IBM présente ainsi la couche sémantique comme un moyen de traduire les structures techniques en notions métier partagées. Elle permet notamment de standardiser les indicateurs et les règles de calcul entre différentes sources.
Cette compréhension commune constitue une première étape, car l’agent doit encore pouvoir connaître la fiabilité et l’histoire des données qu’il consulte.
Métadonnées, règles métier et traçabilité : le contexte indispensable
En effet, une donnée ne se résume pas à sa valeur. Sa date de mise à jour, son origine, sa définition et les transformations qu’elle a subies déterminent aussi la manière dont elle doit être interprétée.
C’est précisément le rôle des métadonnées.
Elles documentent les informations disponibles, leurs caractéristiques et leurs conditions d’utilisation. Associées aux règles métier, elles permettent d’indiquer quel référentiel fait autorité, comment un indicateur est calculé et dans quelles situations il peut être utilisé.
La traçabilité apporte une autre garantie, puisqu’elle permet de retrouver les sources mobilisées pour produire une réponse et les traitements intermédiaires qui ont éventuellement modifié l’information.
Quant à la qualité, elle doit être évaluée selon plusieurs dimensions. Le cadre britannique de qualité des données distingue notamment l’exactitude, la complétude, la cohérence et l’actualité des informations. Une base correctement renseignée peut contenir des valeurs obsolètes, tandis qu’une donnée récente peut rester inexacte.
Cette préparation participe directement à « l’AI Readiness », autrement dit la capacité d’une organisation à mobiliser ses données, ses technologies et ses compétences pour développer des usages IA fiables.
Attention, on ne parle pas ici forcément de reconstruire toute l’architecture informatique. Dans bien des cas, une meilleure organisation des échanges et des responsabilités constitue déjà une avancée assez significative.
Comment préparer les données sans reconstruire tout son SI ?
La première étape consiste à partir des usages envisagés. Un agent chargé d’assister les commerciaux n’a, par exemple, pas besoin d’accéder à l’intégralité des données financières et logistiques, et doit surtout disposer des informations nécessaires à ses missions, avec des définitions fiables et des droits adaptés.
Vous pouvez alors identifier les applications concernées, cartographier les flux existants et repérer les principales incohérences.
Ce travail permet de concentrer les efforts sur les données réellement utiles, et évite d’engager immédiatement un gros chantier de refonte.
Vient ensuite l’harmonisation, qui porte sur les formats, les identifiants, les référentiels et les règles de calcul. Les équipes métier doivent évidemment participer à ces décisions, car elles connaissent les exceptions et les usages que la documentation technique ne suffit pas toujours à expliquer.
Pour rendre ces usages reproductibles, les entreprises doivent aussi travailler sur l’architecture qui alimente leurs modèles :
- collecte des informations,
- transformations,
- règles de qualité
- et échanges entre applications.
Cette logique rejoint une approche intégrée de la gestion des données, qui associe les différentes étapes de leur cycle de vie plutôt que de traiter chaque besoin isolément.
Les API, les plateformes d’intégration et les mécanismes de synchronisation permettent d’exposer progressivement les informations nécessaires, sans multiplier systématiquement les copies.
Cette architecture doit enfin prévoir des responsables clairement identifiés pour la qualité, les accès et les corrections.
Tester la fiabilité des données avant d’élargir les usages
Reste à vérifier que le dispositif fonctionne réellement, avant d’autoriser l’agent à intervenir sur davantage de processus.
Ce passage à l’échelle mérite une évaluation spécifique, pour établir qu’un agent saura interpréter les données réelles de l’entreprise.
Pour chaque cas d’usage, quelques questions permettent de construire une première grille d’évaluation :
- Signification : les données et les indicateurs disposent-ils de définitions métier explicites ?
- Qualité : les informations sont-elles suffisamment exactes, complètes et récentes pour l’usage prévu ?
- Traçabilité : peut-on retrouver leurs sources et les transformations réalisées ?
- Gouvernance : les propriétaires, les finalités et les droits d’accès sont-ils clairement établis ?
- Fiabilité des réponses : l’agent sait-il identifier une contradiction, signaler une information manquante et demander une vérification ?
Ces critères doivent ensuite être testés sur des cas représentatifs, y compris des données contradictoires ou incomplètes. Le NIST AI Risk Management Framework insiste d’ailleurs sur la nécessité de documenter le contexte des usages, d’évaluer les risques et de maintenir les contrôles tout au long du cycle de vie des systèmes IA.
L’objectif est de définir un niveau de confiance adapté à chaque usage. Par exemple, une réponse documentaire interne ne présente logiquement pas les mêmes conséquences qu’une recommandation commerciale ou une décision financière.
L’AI Readiness se mesure finalement à cette capacité : fournir aux modèles des données compréhensibles, contrôlées et adaptées à leurs missions. Vous pourrez alors élargir progressivement leur autonomie, sans leur demander d’interpréter seuls les incohérences que votre organisation n’a pas encore résolues.
