AWS réduit la connexion d’un nouveau jeu de données à un serveur MCP à un seul fichier JSON

Lorsqu’un seul assistant d’IA est directement connecté à une base de données, l’architecture paraît simple. Les problèmes commencent avec l’arrivée d’une dizaine d’agents et de centaines de tables : chaque client conserve sa propre connaissance des schémas, génère du SQL selon ses propres règles et vérifie les autorisations à sa manière. Toute modification d’une colonne doit être répercutée dans plusieurs applications, tandis que l’équipe de sécurité ne dispose d’aucun point d’audit centralisé.

L’équipe qui exploite le réseau nord-américain de centres de tri d’Amazon a décrit une autre approche : un serveur MCP commun placé entre les agents et le lac de données de l’entreprise. Il fonctionne sur Amazon ECS Fargate, expose l’endpoint standard /mcp et connecte Athena, Redshift et Bedrock Knowledge Bases sous forme d’outils découvrables. Sa principale promesse pratique : un nouveau jeu de données est ajouté non pas au moyen d’un nouveau connecteur, mais grâce à un seul fichier JSON de métadonnées.

Comment un fichier remplace une intégration distincte

Prenons une table de commandes. Le fichier JSON indique la base et le nom de la table, la finalité des données, les types et descriptions des colonnes, la fréquence d’actualisation ainsi que des exemples de valeurs réelles. Ces derniers sont particulièrement utiles : l’agent comprend qu’un identifiant d’entrepôt ressemble à FC-EAST-07, et non à un nom de région arbitraire. Le même fichier peut contenir des indications propres au moteur SQL, par exemple la manière de comparer une date stockée sous forme de chaîne avec une colonne de type timestamp.

Après synchronisation, le fichier est intégré au catalogue de recherche de Bedrock Knowledge Bases. Lorsqu’un utilisateur demande les dix commandes les plus coûteuses du mois précédent, l’agent commence par trouver la table pertinente et sa description, construit ensuite la requête SQL, vérifie sa compatibilité avec Athena, puis seulement l’exécute. Selon les auteurs, le cycle complet prenait 15 à 20 secondes.

Une carte de contextes supplémentaire est prévue pour les différentes applications. Si la requête provient d’un outil de planification du personnel, la recherche peut être limitée aux tables relatives aux effectifs au lieu de parcourir l’ensemble du catalogue. Cela réduit le bruit et le risque de sélectionner une table similaire, mais incorrecte. La même architecture permet de combiner, en une seule étape, le résultat d’une requête SQL avec une recherche dans les documents internes.

Où intervient le contrôle d’accès

Le serveur MCP est déployé dans un sous-réseau privé, derrière un équilibreur de charge interne. La couche cliente publique passe par AWS WAF et Cognito, tandis que l’état des conversations est stocké dans DynamoDB. Les outils Athena n’acceptent que des requêtes SELECT, et leurs appels sont consignés dans CloudWatch. Bedrock Guardrails s’applique aux interactions avec le modèle et contribue à filtrer les contenus nuisibles, à vérifier que les réponses reposent sur leurs sources et à bloquer certaines attaques reposant sur des instructions incorporées aux données.

Il ne s’agit toutefois pas d’une protection universelle prête à l’emploi. L’interdiction des opérations d’écriture n’empêche pas la lecture de lignes ou de colonnes superflues si les autorisations sont configurées trop largement. Les Guardrails ne peuvent pas non plus être considérés comme une garantie contre les injections de prompt. L’équipe a toujours besoin de politiques au niveau des lignes ou des colonnes, de plafonds sur le coût des requêtes, de contrôles visant à détecter les fuites dans les réponses du modèle et de tests vérifiant qu’il est impossible de contourner l’isolation entre locataires.

Ce qu’il faut reprendre dans sa propre architecture

La valeur de cette solution ne réside pas dans une longue liste de services AWS, mais dans la séparation des responsabilités. L’agent formule l’intention, le catalogue explique les données, la passerelle MCP contrôle les outils et le système de stockage exécute lui-même la requête. Les développeurs ont intérêt à commencer modestement : placer une source fréquemment utilisée derrière une interface MCP commune, décrire son schéma dans un fichier lisible par machine, puis mesurer la précision de sélection des tables, la latence et le coût.

Si ce pilote fonctionne, l’étape suivante consiste à mettre en place un audit centralisé et un modèle d’autorisations explicite. Le fichier JSON accélère à lui seul le raccordement des tables, mais la qualité de l’ensemble du système dépend de l’identité des personnes autorisées à lire les données, de la fraîcheur des métadonnées et du comportement adopté en cas de SQL erroné. Ce sont précisément ces contrôles qui transforment une belle démonstration en passerelle d’entreprise opérationnelle.