Comment l'accès aux données façonne la performance des agents IA

Demandez à un agent d'IA de répondre à une question commerciale, et vous pourriez accidentellement en apprendre plus sur votre infrastructure de données qu'à propos de l'agent. Le modèle ne trébuche pas parce qu'il n'est pas assez intelligent. Il trébuche parce qu'il ne trouve pas ce dont il a besoin, ne peut pas faire confiance à ce qu'il trouve, ou ne comprend pas ce que les données signifient réellement dans votre contexte commercial spécifique.

C'est le schéma qui se cache derrière des milliards de dollars d'investissements en IA ratés. Et si vous êtes un leader des données ou un ingénieur de données, c'est votre problème à résoudre.

[CTA_MODULE]

Le taux d'échec dont personne ne veut parler

Les chiffres sont brutaux. L'initiative NANDA du MIT a publié "La fracture de l'IA générative : État de l'IA en entreprise 2025", une étude basée sur 150 entretiens avec des dirigeants, des enquêtes auprès de 350 employés et l'analyse de 300 déploiements publics d'IA. Le chiffre marquant : 95 % des projets pilotes d'IA générative en entreprise n'ont eu aucun impact mesurable sur le compte de résultat. Pas "performances inférieures aux attentes". Zéro impact mesurable.

Gartner prévoit que plus de 40 % des projets d'IA agentique seront annulés d'ici fin 2027, en raison de l'escalade des coûts, d'une valeur commerciale incertaine et de contrôles des risques inadéquats. Il ne s'agit pas d'expériences sous-financées. Selon Gartner, les dépenses mondiales en IA devraient dépasser 2 000 milliards de dollars en 2026, ce qui représente une croissance de 37 % d'une année sur l'autre. L'argent est là. Les résultats ne le sont pas.

L'étude 2025 sur les PDG de l'IBM Institute for Business Value le formule de manière encore plus frappante : seulement 16 % des initiatives d'IA ont été déployées avec succès à l'échelle de l'entreprise. Cela représente beaucoup de preuves de concept qui n'ont jamais vraiment prouvé grand-chose.

Alors, qu'est-ce qui ne va pas ? Les chercheurs du MIT ne pointent pas du doigt la qualité du modèle, mais ce qu'ils appellent un « fossé d'apprentissage » causé par des flux de travail fragiles et un manque d'apprentissage contextuel. En clair : l'IA ne peut pas se connecter aux données dont elle a besoin, et lorsqu'elle y parvient, elle ne comprend pas ce que ces données signifient.

C'est un problème de données, pas un problème d'IA.

L'intégration est le premier goulot d'étranglement

Un agent IA n'est aussi bon que les données auxquelles il peut accéder. Si vos données clients résident dans Salesforce, vos métriques d'utilisation produit dans un entrepôt de données, vos tickets de support dans Zendesk et vos données financières dans un système ERP, l'agent rencontre le même problème que vos analystes depuis des années. Il travaille avec des fragments.

La différence est qu'un analyste humain sait appeler l'équipe financière pour demander la feuille de calcul manquante. Un agent n'improvise pas face aux lacunes de données. Soit il hallucine une réponse qui semble sûre d'elle, soit il renvoie quelque chose de techniquement correct mais pratiquement inutile parce qu'il travaille avec une image incomplète.

L'intégration de données n'est pas nouvelle. Les équipes de données connectent des sources depuis des décennies. Mais les exigences pour l'IA agentique sont fondamentalement différentes de celles pour les tableaux de bord et les rapports.

Un tableau de bord BI peut tolérer les mises à jour par lots, la réconciliation manuelle et quelques lacunes connues. Un analyste voit un chiffre étrange, interpelle l'équipe de données sur Slack et obtient la vraie réponse en fin de journée. Un agent autonome ne peut pas faire cela. Il a besoin d'un accès fiable et programmatique à des données consolidées, et il a besoin que ces données soient à jour. Pas « mises à jour toutes les nuits ». À jour.

Pensez à ce qu'un agent fait réellement lorsque vous lui demandez d'analyser le taux de désabonnement des clients. Il a besoin des données de compte de votre CRM, des événements d'utilisation produit de votre base de données d'application, de l'historique des tickets de support de votre plateforme de service d'assistance, des données de facturation de votre système financier, et probablement de certaines métriques d'engagement de vos outils marketing. Si ne serait-ce qu'une de ces sources est manquante, obsolète ou incohérente avec les autres, l'analyse du taux de désabonnement de l'agent est compromise. Pas manifestement fausse. Subtilement fausse. Et subtilement fausse est pire, car les gens agissent en conséquence.

C'est là que l'infrastructure compte. Si vos pipelines de données sont fragiles, vos agents héritent de cette fragilité. Si votre couche d'intégration supprime des enregistrements, produit des doublons ou prend des heures de retard alors que l'entreprise a besoin de minutes, le résultat de l'agent reflète chacun de ces défauts. Gartner a constaté que la mauvaise qualité des données coûte à elle seule aux organisations en moyenne 12,9 millions de dollars par an. Imaginez maintenant multiplier ce coût en donnant à un système autonome l'autorité d'agir sur de mauvaises données sans intervention humaine.

Les organisations qui tirent une réelle valeur de l'IA agentique ne sont pas celles qui possèdent les modèles les plus sophistiqués. Ce sont celles qui disposent d'une intégration de données fiable et automatisée, regroupant les sources dans une couche unique et interrogeable. Pas d'assemblage manuel. Pas de connaissance tacite sur la « vraie » table. Pas de « demandez à Sarah, elle sait où se trouvent les bonnes données ». Juste des données propres, consolidées et accessibles qu'un agent peut interroger sans surveillance humaine.

Données propres ou hallucinations sûres d'elles (choisissez)

Il existe un type d'échec spécifique qui empêche les ingénieurs de données de dormir la nuit : l'agent qui répond avec assurance et de manière incorrecte. Pas un plantage. Pas un message d'erreur. Une mauvaise réponse livrée avec une grammaire parfaite et une conviction totale.

Cela se produit lorsque les données sous-jacentes sont de mauvaise qualité. Des doublons de fiches clients. Des formats de date incohérents. Des valeurs nulles là où il devrait y avoir des données réelles. Des chiffres d'affaires qui ne correspondent pas d'un système à l'autre car chaque équipe les calcule différemment. L'agent ne sait rien de tout cela. Il traite ce qu'il trouve et produit un résultat.

Le Moniteur des tendances en matière de données, BI et analytique 2026 de BARC, qui a interrogé plus de 1 500 professionnels, a révélé que la gestion de la qualité des données a retrouvé la première place parmi toutes les priorités des répondants. Pour les agents d'IA, une qualité de données élevée est plus importante que jamais pour éviter les hallucinations, les biais et les recommandations erronées. Ce n'est pas une préoccupation théorique. C'est le principal obstacle le plus fréquemment cité à une IA réellement fonctionnelle.

La qualité des données pour les agents est plus rigoureuse que la qualité des données pour les tableaux de bord. Un tableau de bord avec quelques lignes obsolètes est agaçant. Un agent qui prend une décision d'achat basée sur des données d'inventaire obsolètes coûte cher. Un agent qui achemine une plainte client à la mauvaise équipe en raison d'un enregistrement en double est un problème de confiance qui s'aggrave à chaque fois que cela se produit.

Les dimensions standard s'appliquent toujours : exactitude, exhaustivité, cohérence et fraîcheur. Mais les enjeux sont plus élevés car le consommateur des données n'est pas un humain capable d'appliquer son jugement et son contexte. C'est un système qui agira en fonction de ce qu'il reçoit. La qualité de vos données n'est plus seulement un problème d'hygiène. C'est un plafond de performance pour chaque agent que vous déployez.

Le contexte distingue une démo d'une production

La plupart des projets d'agents se heurtent au mur décrit par l'étude du MIT ici même. L'agent peut accéder aux données. Les données sont raisonnablement propres. Mais l'agent produit toujours des réponses qui font grimacer vos experts du domaine. Il confond le chiffre d'affaires brut avec le chiffre d'affaires net. Il traite les trimestres fiscaux comme des trimestres civils. Il ne sait pas que « utilisateurs actifs » signifie quelque chose de différent pour votre équipe produit que pour votre équipe marketing.

C'est le problème du contexte. Un accès brut aux tables et aux colonnes ne suffit pas. L'agent doit comprendre ce que les données signifient dans votre entreprise.

AtScale a publié un scénario qui illustre cela parfaitement. La finance déclare un chiffre d'affaires de 10,2 millions de dollars dans Power BI. Le marketing affiche un chiffre d'affaires de 10,4 millions de dollars dans Tableau. Un copilote IA affiche un chiffre d'affaires de 9,8 millions de dollars dans Slack. Chaque chiffre est « correct » compte tenu de sa source et de sa logique de calcul. Mais ils se contredisent. La finance comptabilise les revenus enregistrés après les retours. Le marketing comptabilise la valeur brute des transactions. L'agent IA, dépourvu de tout ce contexte, calcule n'importe quel modèle qu'il trouve dans les tables de transactions brutes. Parfois, il inclut des données de test. Parfois, il exclut les ventes internationales. Cela dépend de la façon dont la question est formulée, et dans tous les cas, son « processus de pensée » peut même ne pas être déterministe.

Un humain gère cette ambiguïté grâce à ses connaissances institutionnelles et à des réunions de réconciliation. Un agent a besoin que ces connaissances soient encodées et accessibles. C'est ce qu'une couche sémantique fait. Elle définit la manière dont les métriques sont calculées, associe les termes métier à des transformations de données spécifiques et s'assure que le « chiffre d'affaires » signifie une seule et même chose, quelle que soit la personne (ou l'entité) qui pose la question.

Les prévisions de Gartner pour 2026 en matière de données et d'analytique considèrent désormais les couches sémantiques universelles comme une infrastructure critique, les plaçant aux côtés des plateformes de données et de la cybersécurité. C'est une avancée majeure par rapport à un simple « atout ».

Mais les couches sémantiques ne sont pas le seul moyen de fournir du contexte. La bonne approche dépend du type de données et du type de question.

Les compétences d'agent — des instructions structurées qui indiquent à un agent comment interagir avec des outils ou des sources de données spécifiques — servent un objectif similaire pour l'exécution des tâches. Un agent doté d'une compétence bien définie pour interroger votre entrepôt de données clients sait quelles tables interroger, quelles jointures effectuer et quels filtres appliquer. Il ne devine pas. Il suit une compréhension codifiée de votre modèle de données. Les compétences sont particulièrement précieuses pour les requêtes structurées et répétables où la logique métier est bien définie et les relations de données sont stables.

Pour les données non structurées, les embeddings et les bases de données vectorielles offrent un autre type de contexte. Lorsqu'un agent doit récupérer des documents pertinents, des politiques internes, des analyses antérieures ou des conversations Slack pour éclairer une réponse, la recherche vectorielle lui permet de trouver un contenu sémantiquement similaire sans se baser sur des correspondances exactes de mots-clés. Un agent de support capable de trouver le guide de dépannage pertinent en fonction du sens de la question d'un client (et pas seulement des mots-clés) est fondamentalement plus performant qu'un agent qui ne le peut pas.

Les protocoles comme le MCP (Model Context Protocol) offrent aux agents un moyen standardisé de se connecter à des outils externes et à des sources de données, réduisant ainsi le travail d'intégration personnalisé qui ralentit tant de déploiements. Au lieu de construire des connecteurs sur mesure pour chaque outil avec lequel un agent doit interagir, le MCP fournit une interface commune. Considérez-le comme l'USB-C de la connectivité des agents. Il ne rend pas l'agent plus intelligent, mais il rend son accès aux données et aux outils considérablement plus fiable et cohérent.

Toutes ces approches partagent un point commun : elles donnent à l'agent une compréhension structurée de vos données qui va au-delà du simple accès aux tables brutes. Sans contexte, vous obtenez une démo qui impressionne les dirigeants en salle de conférence. Avec le contexte, vous obtenez un système qui produit des réponses auxquelles vos experts métier font réellement confiance.

L'étude "Data and AI Market Lens" d'ISG a révélé que plus d'un tiers des organisations ont jugé que leurs initiatives de modélisation sémantique étaient en deçà des attentes. La technologie fonctionne. C'est l'exécution qui est difficile. Mais les organisations qui investissent dans la construction de cette couche contextuelle (quelle que soit la manière dont elles la construisent) sont celles qui comblent le fossé entre le pilote et la production.

La gouvernance n'est pas une option 

Il est tentant de considérer la gouvernance comme quelque chose que l'on ajoute plus tard, une fois que l'agent fonctionne. C'est une erreur. Pour un agent IA, la gouvernance est un prérequis, pas une tâche de suivi.

Considérez ce qu'un agent fait réellement. Il accède aux données à travers différents systèmes. Il joint des ensembles de données qui peuvent avoir des contrôles d'accès différents. Il produit des résultats qui pourraient être vus par des personnes qui ne devraient pas avoir accès aux données sources sous-jacentes. Il prend des décisions ou formule des recommandations qui nécessitent une piste d'audit. Sans une gouvernance intégrée à la couche de données, vous donnez essentiellement à un système autonome une clé passe-partout pour vos données d'entreprise et espérez qu'il l'utilise de manière responsable.

Les contrôles d'accès doivent accompagner les données, et non pas se limiter à la couche applicative. La sécurité au niveau des colonnes, le filtrage au niveau des lignes et les politiques d'accès basées sur les rôles doivent être appliqués, qu'un humain ou un agent exécute la requête. La lignée des données doit être visible afin que, lorsqu'un agent produit un chiffre, vous puissiez le retracer jusqu'à sa source et comprendre comment il a été dérivé. Et la classification des données doit être explicite afin que l'agent sache quels ensembles de données il peut ou ne peut pas utiliser pour une tâche donnée.

L'enquête 2025 de PwC sur l'IA responsable a révélé que près de 60 % des dirigeants estiment que les pratiques d'IA responsable augmentent le retour sur investissement et l'efficacité, mais près de la moitié ont admis que transformer ces principes en processus opérationnels reste un défi majeur. L'écart entre l'intention et l'exécution est énorme. L'IA agentique élargit cet écart car les agents ne s'arrêtent pas pour demander : « Ai-je le droit d'utiliser cet ensemble de données ? » Ils l'utilisent tout simplement.

Le Trend Monitor de BARC le confirme : des décisions correctes ne peuvent être prises que sur la base de données fiables et cohérentes. Pour les agents, « fiable et cohérent » inclut « gouverné ». Une couche de données non gouvernée n'est pas seulement un risque de conformité. C'est un goulot d'étranglement en termes de performances, car l'alternative à la gouvernance est la révision manuelle de chaque sortie d'agent. Et cela va à l'encontre de l'objectif même de l'automatisation.

La fraîcheur est essentielle, pas un luxe

Une dimension de la qualité des données mérite une attention particulière pour l'IA agentique : la fraîcheur.

Un tableau de bord qui se rafraîchit une fois par jour convient à la plupart des revues d'affaires. Une exécution hebdomadaire de pipeline est adéquate pour le reporting de tendances. Mais un agent qui formule des recommandations, répond à des questions ou déclenche des flux de travail fonctionne selon une horloge différente. Si un client a annulé son abonnement il y a 2 heures et que l'agent recommande toujours des stratégies de vente incitative basées sur les données d'hier, ce n'est pas seulement inexact. C'est embarrassant. Et dans les industries réglementées, cela pourrait être une violation de conformité.

Les exigences de fraîcheur varient selon les cas d'utilisation, mais la direction est claire : les agents ont besoin de données qui reflètent la réalité au moment de la requête, et non la réalité telle qu'elle était lors de la dernière exécution par lots. Cela ne signifie pas que tout doit être en temps réel. Cela signifie que vous devez comprendre les exigences de fraîcheur de chaque flux de travail d'agent et construire des pipelines qui y répondent. Un agent d'inventaire a besoin de niveaux de stock quasi en temps réel. Un agent de planification trimestrielle peut travailler avec des instantanés quotidiens. L'erreur est d'appliquer une seule cadence de rafraîchissement à tout et d'espérer que cela suffira.

L'évolution vers une infrastructure de données gérée est utile ici. Lorsque votre couche d'intégration gère la fraîcheur comme un paramètre configurable par source (et non comme une tâche par lots universelle), vous pouvez adapter le comportement du pipeline aux exigences de l'agent sans reconstruire votre architecture à chaque fois qu'un nouveau cas d'utilisation est déployé.

Ce que cela signifie pour les équipes de données

Si vous êtes un leader des données et que vous voyez votre organisation lancer des projets pilotes d'agents, vous savez déjà où cela mène. Les modèles s'amélioreront. Les frameworks mûriront. Les outils d'orchestration s'amélioreront. Mais rien de tout cela n'aura d'importance si la base de données n'est pas solide.

Le travail qui assure le succès des agents est le même que celui que les équipes de données prônent depuis des années : une intégration fiable entre les sources, une qualité de données constante, des définitions métier claires et une gouvernance solide. La différence est que les agents rendent le coût de ne pas faire ce travail visible d'une manière que les tableaux de bord n'ont jamais fait. Un mauvais tableau de bord est ignoré. Un mauvais agent agit sur de mauvaises données et crée des conséquences qui se répercutent sur l'ensemble de l'entreprise.

C'est en fait une bonne nouvelle pour les équipes de données. Pendant des années, l'ingénierie des données a été traitée comme de la plomberie (nécessaire mais peu glamour) tandis que les équipes d'IA et de ML étaient sous les feux de la rampe. L'IA agentique inverse cette dynamique. La qualité de la couche de données est désormais le principal facteur de prédiction du succès d'une initiative d'IA de plusieurs millions de dollars ou de son ajout à la liste des « leçons apprises ».

Les organisations qui considèrent l'infrastructure de données comme le fondement de leur stratégie d'IA (et non comme une réflexion après coup) seront celles qui dépasseront la phase pilote. Ce taux d'échec de 95 % de l'étude du MIT n'est pas inévitable. C'est ce qui se produit lorsque vous construisez des agents sur des couches de données qui n'étaient pas prêtes pour une consommation autonome.

Vos agents ne sont pas limités par le modèle. Ils sont limités par les données. Corrigez les fondations, et les 95 % commenceront à diminuer.

Prêt à construire la base de données dont vos agents IA ont besoin ? Découvrez comment le service de lac de données géré de Fivetran fournit des données intégrées et gouvernées pour alimenter vos initiatives d'IA agentique.

[CTA_MODULE]