Agents IA en entreprise : AWS Bedrock, vos documents et des garde-fous

Tout le monde peut brancher une IA sur un site en une après-midi. La démonstration impressionne, puis vient la première vraie question d'un collaborateur : « Quelle est notre procédure pour ce client-là ? ». L'IA ne connaît ni vos procédures, ni vos clients, ni vos outils. Elle répond quand même, avec aplomb, et à côté.

Un agent IA utile en entreprise doit faire trois choses qu'un assistant grand public ne fait pas : connaître vos documents, agir dans vos outils, et ne jamais montrer à quelqu'un ce qu'il n'a pas le droit de voir. Cet article explique comment nous construisons cela sur AWS Bedrock, à partir d'un projet que nous avons conçu et mis en production : une plateforme de coaching par IA, où chaque scénario d'entraînement s'appuie sur les documents de l'organisation qui l'utilise.

Connaître vos documents : le RAG

Un modèle de langage ne sait que ce qu'il a appris avant sa sortie. Pour qu'il réponde à partir de vos documents, on ne le réentraîne pas : on lui donne, à chaque question, les passages pertinents. C'est le principe du RAG, pour génération augmentée par la recherche.

Sur AWS, la chaîne que nous avons mise en place est la suivante.

• Les documents sont déposés dans S3, le stockage d'AWS, dans le compte de l'entreprise.
• Une base de connaissances Bedrock les synchronise : elle découpe chaque document en passages et les transforme en vecteurs, des empreintes numériques du sens, avec le modèle Titan Text Embeddings d'Amazon.
• Les vecteurs sont rangés dans OpenSearch, un moteur de recherche géré par AWS, avec le texte et les métadonnées de chaque passage.
• À chaque question, l'application transforme la question en vecteur, cherche les passages les plus proches dans OpenSearch, puis les confie au modèle qui rédige la réponse.

Rien de tout cela ne quitte le compte AWS de l'entreprise. AWS indique que les fournisseurs de modèles n'ont accès ni aux journaux de Bedrock, ni aux requêtes, ni aux réponses. Pour une direction informatique, c'est souvent la différence entre un projet qui démarre et un projet bloqué en comité sécurité.

Ne montrer que ce qui est autorisé

C'est la partie que les démonstrations oublient, et celle qui demande le plus de soin.

Dans notre projet, plusieurs organisations partagent la même plateforme. Une base de connaissances peut appartenir à une organisation, être partagée avec d'autres, ou n'être rattachée qu'à certains scénarios. Chaque passage indexé porte donc son organisation, ses groupes d'accès, sa source (un document déposé, une page Confluence, un ticket Jira) et des thèmes métier.

Bedrock propose une recherche tout intégrée, pratique pour tester. Nous avons préféré que l'application construise elle-même la requête envoyée à OpenSearch, parce que c'est là que les droits s'appliquent : le filtre d'organisation, les groupes, les sources, et même des combinaisons complètes en ET, OU et NON pour les cas complexes. Le modèle ne voit que ce que la recherche lui transmet : aucune formulation habile de la question ne lui donne accès à un passage que le filtre a écarté.

Ce filtre est la ligne de défense principale du système. Il doit se relire et se tester comme du code de sécurité, à chaque modification, car un filtre mal combiné suffit pour qu'une organisation lise les documents d'une autre. C'est exactement le genre de défaut que la double vérification, par un second modèle puis par un développeur, est faite pour attraper.

Agir dans vos outils : de l'assistant à l'agent

Un assistant répond. Un agent agit : il consulte un ticket, crée un rendez-vous, interroge une base de données, lance un traitement. Le passage de l'un à l'autre change la nature du projet.

Le standard qui s'est imposé pour brancher un agent sur des outils est MCP, le Model Context Protocol. Dans notre plateforme, les serveurs MCP se déclarent depuis l'administration, avec leur authentification, y compris OAuth quand l'outil l'exige. Chaque appel d'outil décidé par le modèle est enregistré avec le message qui l'a provoqué : on sait toujours ce que l'agent a fait, et pourquoi.

Nous contribuons aussi à Hermes Agent, un agent open source qui tourne en continu sur un serveur. Les deux expériences mènent aux mêmes règles.

• Des droits au strict nécessaire. Un agent qui doit lire des tickets n'a pas besoin de pouvoir les supprimer.
• Une validation humaine pour les actions sensibles. Envoyer, payer, supprimer ou modifier des données de production passe par une personne.
• Un journal de chaque action. Sans trace, un incident ne s'explique pas, et ne se corrige pas.
• Une durée de vie pensée dès le départ. Un agent qui tourne des semaines doit survivre aux redémarrages et aux mises à jour sans perdre ses tâches.

Maîtriser les coûts et garder le choix du modèle

Un agent consomme des jetons, l'unité de facturation des modèles, à chaque question et à chaque appel d'outil. Notre plateforme enregistre les jetons consommés par chaque message et le prix de chaque modèle : le coût d'un usage se lit au lieu de se découvrir sur la facture du mois.

L'architecture garde aussi le choix du fournisseur. La recherche dans les documents passe par une interface commune, avec une implémentation AWS et une autre chez un second fournisseur. Changer de modèle, ou en combiner plusieurs, ne demande pas de reconstruire l'application. Bedrock lui-même donne accès aux modèles de plusieurs éditeurs depuis le même compte.

Ce que nous avons appris sur le terrain

La console ne suffit pas pour vérifier un index. La liste des documents indexés affichée par la console Bedrock s'est révélée peu fiable chez nous, avec une pagination capricieuse et des documents absents de la liste. Nous vérifions directement dans OpenSearch les passages réellement indexés.

Les droits se modélisent avant les écrans. Base propre, base partagée, base rattachée à un scénario : chaque cas a sa table et sa contrainte d'unicité. Les ajouter après coup aurait coûté une refonte.

La qualité des réponses dépend surtout des documents. Un modèle plus puissant ne compense pas une procédure obsolète ou trois versions contradictoires du même document. Le tri des sources est la première étape d'un projet RAG, pas la dernière.

Par où commencer

Un agent IA n'est pas toujours la bonne réponse. Parfois, une bonne recherche dans les documents ou une application métier bien conçue règle le problème plus simplement. Le premier rendez-vous sert à le dire.

S'il l'est, nous procédons comme pour tout logiciel : un cadrage humain, un prototype visuel gratuit sous 5 jours ouvrés, puis un développement au forfait ou en abonnement, sans régie, dans votre propre compte AWS si vous le souhaitez. Votre agent connaît vos documents, agit dans vos outils, et ne montre à chacun que ce qu'il a le droit de voir.