Un agent IA n’est puissant que s’il accède aux bonnes données.

Un modèle peut être excellent en raisonnement, en génération de code ou en planification et rester presque inutile face à un processus métier réel. Il connaît le langage, des concepts généraux et des patterns appris pendant l’entraînement. Il ne connaît ni l’état actuel d’un stock, ni la dernière version d’une procédure interne, ni les contraintes particulières d’un client.

La puissance opérationnelle d’un agent vient de la rencontre entre les capacités du modèle et les données auxquelles il peut accéder au moment d’agir. Sans données pertinentes, il raisonne dans l’abstrait. Avec les bonnes données, les bons outils et un accès correctement délimité, il peut comprendre une situation, vérifier ses hypothèses et produire une action utile.

Le modèle apporte le raisonnement, les données apportent la connaissance opérationnelle

Les poids du modèle contiennent une connaissance générale et figée à la date de l’entraînement. L’entreprise, elle, fonctionne avec des informations vivantes : documents versionnés, tickets, commandes, métriques, historiques de maintenance, conversations, bases clients et états de production. C’est dans ce différentiel que se situe l’essentiel de la valeur agentique.

Un agent chargé d’analyser une panne doit connaître la configuration réelle de la machine, les derniers événements, la documentation du composant et les interventions précédentes. Un agent logiciel doit voir le dépôt concerné, les conventions du projet, les tests et l’état du build. Le modèle ne peut pas déduire correctement ces éléments à partir de sa seule connaissance générale.

Augmenter le nombre de paramètres ne résout pas ce problème. La question structurante devient : quelles données faut-il rendre disponibles, sous quelle forme, avec quelle fraîcheur et pour quelle durée ?

Donner accès ne signifie pas verser toutes les données dans le contexte

Une fenêtre de contexte plus grande n’est pas une architecture de données. Charger indistinctement des dossiers complets augmente le bruit, le coût d’inférence et la probabilité que l’agent s’appuie sur une information secondaire ou obsolète. La qualité du raisonnement dépend souvent davantage de la précision du contexte que de son volume.

Un agent efficace construit son contexte dynamiquement. Il commence avec une mission et quelques identifiants, puis utilise la recherche, les métadonnées, les requêtes structurées ou les outils métier pour récupérer uniquement ce qui est nécessaire. Le contexte devient le résultat d’une exploration contrôlée, pas une copie massive du système d’information.

Le RAG intervient dans cette logique, mais il n’en constitue qu’une partie. La recherche sémantique convient aux documents et aux connaissances non structurées. L’état exact d’une commande, une métrique récente ou un droit contractuel doit plutôt provenir d’une source autoritative interrogée par une API ou une requête typée.

La sandbox devient une frontière de données programmable

La sandbox donne à l’agent un espace dans lequel les données utiles peuvent être composées sans ouvrir l’ensemble de l’infrastructure. Elle peut monter un corpus documentaire en lecture seule, exposer un index RAG, fournir un client d’API avec une identité dédiée et réserver un espace temporaire pour les artefacts produits pendant l’exécution.

Ce périmètre n’est pas seulement restrictif. Il définit ce que l’agent est capable de connaître. Une sandbox bien équipée constitue donc une enveloppe de connaissance autant qu’une enveloppe d’exécution. Elle réunit les données de référence, l’état nécessaire à la mission et les outils capables d’interroger les systèmes concernés.

Deux agents utilisant le même modèle peuvent ainsi avoir des compétences opérationnelles très différentes. L’un connaît le catalogue produit et le CRM nécessaires à la préparation d’une offre. L’autre accède au dépôt Git, aux logs et à l’environnement de test. La spécialisation ne vient pas uniquement du prompt : elle vient de la topologie des données et des capacités exposées.

Séparer données de référence, espace de travail et systèmes d’enregistrement

Les données de référence, telles que les procédures, contrats ou documentations techniques, peuvent généralement être consultées sans être modifiées. Elles sont adaptées à des montages en lecture seule, à des snapshots versionnés ou à des index de recherche privés.

L’agent a ensuite besoin d’un espace de travail. Il y extrait des fichiers, produit du code, convertit des documents et conserve des résultats intermédiaires. Cet espace peut être éphémère afin que chaque mission démarre dans un état reproductible et que les artefacts d’une exécution ne contaminent pas la suivante.

Les systèmes d’enregistrement — ERP, CRM, base de production ou gestionnaire de tickets — demandent une interface différente. L’agent ne devrait pas recevoir une connexion générale à la base lorsqu’une API métier peut exposer une vue plus précise. Les opérations disponibles, les lignes visibles et la durée de l’autorisation deviennent alors des propriétés explicites de l’intégration.

L’identité de l’agent doit porter le périmètre de sa mission

L’accès aux données gagne à être attaché à une identité d’exécution courte durée. Un broker de credentials peut délivrer un jeton limité à un client, un projet ou un ensemble d’opérations, sans placer le secret principal dans le contexte du modèle. Les politiques ABAC ou RBAC, le row-level security et les façades d’outils permettent d’appliquer ce périmètre en dehors du prompt.

Cette architecture est plus robuste, mais aussi plus puissante. L’agent peut fonctionner de façon autonome à l’intérieur de droits clairement définis, sans demander une validation pour chaque lecture. L’intervention humaine se concentre sur une élévation de privilège, un changement de périmètre ou une action dont l’effet dépasse la mission initiale.

Le contrôle n’est donc pas opposé à l’autonomie. Il rend possible un accès plus profond aux données réellement utiles, parce que cet accès est attribuable, révocable et borné dans le temps.

Moins de données peut produire un meilleur agent

Limiter le périmètre ne sert pas uniquement à réduire l’exposition. Cela améliore aussi la qualité du système. Un ensemble de sources clairement identifiées réduit les collisions entre versions, les contradictions et les récupérations hors sujet. Le modèle consacre davantage de sa fenêtre de contexte aux éléments décisionnels.

Cette précision agit directement sur la latence et le coût. Les requêtes sont plus petites, les embeddings plus ciblés et les appels d’outils plus prévisibles. Elle facilite également l’évaluation : on peut relier une réponse ou une action aux documents, lignes de base ou résultats d’API qui l’ont produite.

Pour un agent, la pertinence du contexte est une ressource d’ingénierie. Elle se mesure par la fraîcheur, l’autorité de la source, la couverture de la mission et la proportion de données effectivement utilisées dans la décision.

Lire, écrire et agir sont trois niveaux différents

Un agent peut disposer d’un accès étendu en lecture tout en conservant un chemin d’écriture beaucoup plus étroit. Il analyse plusieurs sources, travaille dans sa sandbox et produit un artefact candidat. La promotion vers un dépôt, un CRM ou un système de production passe ensuite par une API dédiée, une règle ou une revue.

Cette séparation maintient la fluidité du raisonnement et de l’expérimentation. L’agent n’est pas interrompu lorsqu’il recherche, compare ou teste. Le contrôle intervient à l’endroit où l’information devient mutation, communication externe ou décision irréversible.

Le niveau d’autonomie peut évoluer avec les métriques. Une opération d’abord soumise à revue peut être automatisée lorsque son taux de réussite, sa traçabilité et ses conditions d’annulation sont suffisamment maîtrisés.

La traçabilité relie chaque action à sa connaissance

Une exécution agentique devrait permettre de reconstruire non seulement les outils appelés, mais aussi les données qui ont alimenté la décision. Les identifiants de documents, versions, requêtes, réponses d’API et artefacts peuvent être associés à la trace de l’agent.

Cette lignée de données transforme l’observabilité en outil d’amélioration. Une erreur peut provenir du modèle, d’une récupération incomplète, d’une source obsolète ou d’un contrat d’outil ambigu. Sans cette distinction, l’optimisation se limite à modifier le prompt. Avec elle, l’équipe peut agir sur le pipeline de contexte, la politique d’accès ou l’interface de données.

La puissance d’un agent dépend de la qualité de ses accès

La valeur d’un agent ne se résume ni au modèle choisi ni au nombre d’outils disponibles. Elle dépend de sa capacité à obtenir la bonne information, au bon moment, depuis une source autoritative, puis à agir dans un périmètre cohérent avec sa mission.

La sandbox matérialise ce contrat. Elle ne consiste pas à enfermer l’agent loin des données, mais à construire une interface sélective entre son raisonnement et le système d’information. Trop peu d’accès produit un agent théorique. Un accès indiscriminé produit du bruit et une architecture difficile à gouverner. L’objectif est un accès précis, dynamique et observable.

Tom Cheniaux - rephrased using AI