Dans beaucoup d’entreprises, les premiers projets d’agents IA suivent un scénario désormais classique : connecter un grand modèle de langage à quelques sources de données, ajouter une base vectorielle, construire une démo convaincante, puis la présenter à la direction. La preuve de concept fonctionne. L’enthousiasme monte. Puis les vrais problèmes commencent.
Les équipes sécurité découvrent des angles morts dans la gouvernance. Les agents deviennent lents dès qu’ils enchaînent plusieurs étapes. Les coûts liés aux modèles explosent à mesure que les requêtes s’allongent. Et l’architecture, qui paraissait souple au départ, devient une mosaïque difficile à auditer.
Le problème vient souvent d’un choix initial : déplacer les données vers une pile IA séparée, plutôt que déplacer les modèles, les outils et les agents vers l’environnement où les données sont déjà gouvernées. C’est précisément là qu’émerge le concept d’agent IA data-native.
Le vrai débat : sortir les données ou rapprocher les agents ?
Les entreprises disposent déjà d’un socle pour stocker, sécuriser et gouverner leurs données : lakehouse, catalogue de données, politiques d’accès, journalisation, outils d’observabilité, pipelines de qualité. La question n’est donc plus seulement de savoir comment connecter un LLM aux données, mais où doit vivre l’agent IA.
Deux approches se dessinent.
Le modèle externe : une pile IA séparée
Dans cette approche, les agents, les modèles, les embeddings, les bases vectorielles ou les outils de serving sont déployés en dehors de la plateforme de données principale. Les données sont exportées, répliquées ou interrogées à distance par un ensemble de services spécialisés.
Cette architecture peut sembler rapide à mettre en place pour un prototype. Elle permet de tester un cas d’usage avec peu de friction technique. Mais en production, elle impose de reconstruire autour de l’IA des mécanismes que l’entreprise possède déjà ailleurs : droits d’accès, traçabilité, règles de confidentialité, supervision, cycle de vie des données, contrôle des coûts.
Le modèle data-native : l’IA comme charge de travail de la plateforme data
Dans une approche data-native, les agents, les modèles, les outils de retrieval, la mémoire agentique et les politiques de sécurité fonctionnent dans le même périmètre que les données. L’IA devient une charge de travail supplémentaire de la plateforme de données, au même titre que l’analytique, le machine learning ou les pipelines de transformation.
Autrement dit, l’entreprise ne construit pas une infrastructure IA parallèle qu’elle tente ensuite de raccorder à son lakehouse. Elle héberge les agents là où les règles existent déjà.
Pourquoi les agents IA externes coûtent plus cher qu’ils n’en ont l’air
Les données ont une forme de gravité. Plus elles sont volumineuses, sensibles et distribuées, plus il devient coûteux de les déplacer. À l’inverse, déplacer du calcul, des modèles ou des agents est généralement plus simple.
Lorsqu’une entreprise extrait ses données de ses systèmes gouvernés pour alimenter une pile IA externe, elle s’expose à plusieurs coûts cachés :
- des risques de sécurité, car les données sensibles circulent dans davantage de systèmes ;
- une gouvernance fragmentée, avec des règles à répliquer entre plusieurs couches techniques ;
- une latence accrue, surtout lorsque l’agent effectue plusieurs allers-retours entre outils, bases et modèles ;
- une explosion des coûts tokens, car le modèle reçoit plus de contexte et répète davantage d’étapes ;
- une observabilité moins fiable, puisque les traces d’exécution sont dispersées ;
- une maintenance plus lourde, avec des dépendances externes à sécuriser, versionner et auditer.
Ce coût n’est pas toujours visible lors d’une démonstration. Il apparaît quand l’agent doit servir des utilisateurs réels, respecter des règles fines d’accès aux données, produire des résultats reproductibles et tenir une charge régulière.
La gouvernance appliquée après coup ne suffit pas
Beaucoup de dispositifs de gouvernance IA reposent encore sur une logique de filtre final : masquer des champs sensibles dans la réponse, bloquer certains sujets, analyser les journaux après usage, ou demander au modèle de ne pas révéler certaines informations.
Cette approche peut convenir à un assistant de questions-réponses simple. Elle devient insuffisante dès que l’agent calcule, agrège ou transforme des données.
Imaginons un agent chargé de produire un résumé financier. Certaines lignes de données sont soumises à une sécurité au niveau ligne : un utilisateur peut voir une partie des transactions, mais pas toutes. Si l’agent calcule une somme ou une tendance avant que cette règle ne soit appliquée, le résultat agrégé peut déjà incorporer des données auxquelles l’utilisateur n’aurait jamais dû contribuer.
Dans ce cas, masquer une partie de la réponse finale ne corrige rien. La fuite a eu lieu au moment du calcul. La décision de gouvernance devait intervenir avant et pendant l’exécution de la requête, pas après la génération de la réponse.
Le piège de la boucle qui brûle des tokens
La gouvernance tardive crée aussi un problème économique. Quand l’agent ne reçoit pas une réponse fiable et conforme dès le départ, il tente souvent de compenser : il consulte d’autres systèmes, réinterroge des sources, compare des fragments, charge plus d’historique, interprète des refus ou des sorties partiellement masquées comme des échecs, puis réessaie.
Chaque tentative ajoute du contexte. Chaque étape consomme des tokens. Une requête apparemment simple peut se transformer en une longue chaîne d’appels au modèle. C’est une spirale coûteuse : l’agent dépense des ressources non pas pour résoudre la tâche métier, mais pour contourner l’absence d’une réponse gouvernée à la source.
Ce que change une approche data-native
Un agent IA data-native ne se contente pas d’accéder aux données. Il s’exécute dans un environnement où les règles de gouvernance sont intégrées au plan de requête, au calcul, à l’accès aux outils et à la mémoire.
Concrètement, cela signifie que :
- les politiques d’accès sont appliquées avant que l’agent ne lise ou calcule sur les données ;
- les résultats intermédiaires respectent les mêmes règles que les résultats finaux ;
- les actions de l’agent sont journalisées dans le même environnement que les données ;
- les modèles, outils et dépendances peuvent être versionnés et audités ensemble ;
- les coûts diminuent grâce à moins de copies, moins d’allers-retours et moins de contexte inutile envoyé au modèle.
Cette logique est particulièrement importante dans les organisations réglementées : finance, santé, assurance, industrie, secteur public ou toute entreprise manipulant des données personnelles, contractuelles ou stratégiques.
La mémoire des agents doit elle aussi être gouvernée
Un agent IA de production ne se limite pas à lire des données. Il écrit aussi. Il conserve un état de conversation, des étapes de tâche, des préférences utilisateur, des résultats mis en cache, des traces d’outils ou des éléments utiles pour un audit ultérieur.
Cette couche d’état est souvent sous-estimée. Pourtant, elle peut contenir des informations aussi sensibles que les données d’origine. Une mémoire indiquant qu’un client est prioritaire, basé en Europe, associé à un segment premium ou concerné par un litige n’est pas une simple métadonnée technique. C’est une donnée métier qui doit respecter les mêmes règles d’accès, de résidence et de conservation.
État court terme et mémoire longue durée
Il est utile de distinguer deux notions :
- l’état, qui correspond au contexte immédiat : conversation en cours, tâche en cours d’exécution, cache temporaire, résultat d’un outil ;
- la mémoire, qui survit à la session : préférences d’un utilisateur, historique de décisions, interactions passées, informations réutilisables.
Si cette mémoire est stockée dans une base externe non couverte par la gouvernance de la plateforme data, l’entreprise crée une faille. Même si l’agent principal est bien contrôlé, sa mémoire peut devenir un angle mort.
Le sujet devient encore plus critique avec les systèmes multi-agents. Lorsqu’un planificateur délègue des tâches à plusieurs agents spécialisés, ces agents doivent partager un état cohérent. Si chacun maintient sa propre mémoire privée et échange du contexte par messages, il n’existe plus de source de vérité unique. Les écritures peuvent se contredire, les droits peuvent se perdre en route et les audits deviennent difficiles.
Databricks et l’exemple d’une plateforme d’agents data-native
La publication source de Databricks défend cette orientation : faire vivre les agents IA dans la plateforme de données, plutôt que dans une pile séparée. L’idée s’appuie sur plusieurs briques de son écosystème, notamment Unity Catalog pour la gouvernance, Model Serving pour le déploiement de modèles, MLflow pour le suivi et Lakebase pour les charges transactionnelles de type PostgreSQL.
Dans cette vision, la mémoire et l’état des agents peuvent devenir des actifs gouvernés. Les accès sont contrôlés, les écritures sont traçables, les mises à jour peuvent être atomiques et les agents partagent une couche transactionnelle commune.
Databricks mentionne aussi le rôle d’Unity AI Gateway pour appliquer des garde-fous déterministes et composables sur les requêtes et les réponses. L’intérêt n’est pas de demander au modèle de “bien se comporter” après coup, mais d’intégrer les règles dans le chemin d’exécution.
Le point important dépasse toutefois un fournisseur précis. Que l’entreprise utilise Databricks ou une autre plateforme, le principe architectural reste le même : moins les données quittent leur périmètre gouverné, plus l’IA est maîtrisable.
Les bénéfices opérationnels pour l’entreprise
Adopter des agents IA data-native ne relève pas seulement de la conformité. C’est aussi un choix de performance et d’exploitation.
Sécurité plus cohérente
Les règles existantes s’appliquent aux données, aux modèles, aux outils et aux traces d’exécution. L’entreprise évite de multiplier les exceptions et les copies non maîtrisées.
Latence réduite
Lorsque l’agent travaille près des données et des outils dont il a besoin, il limite les allers-retours réseau et les appels inutiles à des systèmes externes.
Coûts mieux contrôlés
Moins de contextes volumineux envoyés au modèle, moins de réessais et moins de duplications permettent de réduire la facture opérationnelle, notamment sur les cas d’usage à fort volume.
Auditabilité renforcée
Les décisions, accès, versions de modèles, appels d’outils et écritures de mémoire peuvent être reliés dans une même chaîne de traçabilité. C’est indispensable pour expliquer comment une réponse a été produite.
Meilleure qualité des réponses
Un agent qui reçoit une réponse gouvernée, cohérente et contextualisée dès le départ a moins besoin d’improviser. Il peut se concentrer sur la tâche métier au lieu de résoudre des incohérences d’architecture.
Par où commencer sans tout reconstruire ?
La transition vers des agents IA data-native ne nécessite pas forcément un grand projet de refonte. Dans beaucoup d’entreprises, les composants existent déjà en partie : catalogue de données, politiques d’accès, serving de modèles, observabilité, stockage transactionnel, pipelines ML.
Le changement clé consiste à considérer la plateforme data comme le domicile naturel des agents, et non comme une simple source à connecter à une pile IA parallèle.
Une démarche pragmatique peut suivre ces étapes :
- Cartographier les agents et assistants existants : où s’exécutent-ils, quelles données lisent-ils, où stockent-ils leur mémoire ?
- Identifier les sorties de périmètre : exports, bases vectorielles externes, caches, logs, historiques de conversation, outils SaaS.
- Classer les risques : données personnelles, informations financières, secrets commerciaux, données réglementées, contraintes de résidence.
- Rapprocher un premier cas d’usage critique de la plateforme data : choisir un agent à fort impact mais maîtrisable.
- Appliquer la gouvernance au moment de l’accès et du calcul, pas uniquement à la réponse finale.
- Centraliser l’état et la mémoire dans une couche gouvernée afin d’éviter les dépendances invisibles.
- Mesurer les effets : latence, coût par requête, taux d’erreur, incidents de gouvernance, qualité des réponses.
Un exemple concret : l’agent financier interne
Prenons un agent destiné à aider les équipes finance à analyser les dépenses par région, fournisseur et centre de coût. Dans une architecture externe, les données peuvent être copiées vers une base vectorielle, les règles d’accès reproduites dans une application séparée, et l’historique des conversations stocké dans une base tierce.
Ce montage fonctionne pour une démonstration. Mais en production, il soulève des questions immédiates : un manager régional peut-il influencer un total global ? Les données européennes sont-elles stockées au bon endroit ? Qui peut relire l’historique de l’agent ? Comment prouver qu’une recommandation a été produite avec les bonnes règles d’accès ?
Dans une approche data-native, l’agent interroge les données financières sous les politiques existantes. Les agrégations respectent les droits au moment de la requête. La mémoire des échanges reste dans un stockage gouverné. Les appels d’outils sont journalisés. L’entreprise peut alors auditer non seulement la réponse finale, mais aussi le chemin qui y a mené.
Ce qu’il faut retenir
Les agents IA d’entreprise ne posent pas seulement une question de modèle. Ils posent une question d’architecture. Plus un agent agit, calcule, mémorise et orchestre des outils, plus il devient risqué de le placer en dehors du périmètre où les données sont déjà gouvernées.
Les architectures externes accélèrent parfois les prototypes, mais elles reportent les difficultés sur la production : gouvernance incomplète, coûts tokens, latence, duplication des contrôles, mémoire non auditée. À l’inverse, les agents IA data-native permettent d’exécuter l’intelligence artificielle là où les règles, les données et les traces existent déjà.
Pour les entreprises, la prochaine étape n’est donc pas seulement de connecter davantage de modèles à davantage de sources. C’est de décider où ces agents doivent vivre. Et pour les cas d’usage critiques, la réponse devient de plus en plus claire : les agents doivent se rapprocher des données, pas l’inverse.