Dans les tutoriels AWS publiés le 20 octobre 2026, l’exemple Denodo fédère des données réparties entre Amazon Aurora, Amazon Redshift et PostgreSQL sur site au moment de la requête. Celui d’AtScale exécute chaque requête dans un seul moteur d’entrepôt, avec des données analytiques placées dans Amazon Redshift Serverless et une réplication en amont depuis Aurora. Le premier modèle se prête davantage aux requêtes qui doivent rapprocher des sources distribuées ; le second correspond à une organisation qui dispose déjà d’un entrepôt analytique consolidé.
Un même parcours d’agent, deux couches sémantiques
Les deux tutoriels relient un agent Strands hébergé sur Amazon Bedrock AgentCore à une couche sémantique par le Model Context Protocol (MCP). Cette couche formalise les définitions métier et les contrôles d’accès que l’agent peut utiliser pour interroger les données.
La différence décisive se situe dans l’endroit où la requête est exécutée. Le tutoriel Denodo décrit une fédération de plusieurs sources, tandis que celui d’AtScale s’appuie sur un entrepôt unique pour chaque requête.
| Dimension | Exemple Denodo | Exemple AtScale |
| Sources et exécution | Virtual DataPort planifie les requêtes sur Amazon Aurora, Amazon Redshift et PostgreSQL sur site, puis rassemble les résultats. | Les requêtes s’exécutent dans un seul moteur d’entrepôt. L’exemple place les données analytiques dans Amazon Redshift Serverless et décrit une réplication préalable des données opérationnelles d’Aurora. |
| Modèle sémantique | Des vues de base et dérivées, ainsi qu’une vue distincte pour les mesures, sont définies dans Virtual DataPort. Les requêtes utilisent VQL. | Des objets YAML de Semantic Modeling Language (SML) décrivent notamment les jeux de données, dimensions, faits, mesures, calculs et règles de sécurité. Ils sont versionnés dans Git. |
| Gouvernance illustrée | Une Global Security Policy masque les champs balisés comme sensibles pour le rôle marketing_user. Le rôle hr_user voit les valeurs non masquées dans l’exemple. | Le contrôle d’accès par rôles, la sécurité au niveau des lignes et les perspectives déterminent les données visibles. La perspective marketing exclut les champs SSN et de numéro de carte de l’exemple. |
| Connexion et déploiement illustrés | Le serveur MCP Denodo relie l’agent à Virtual DataPort. Le parcours d’identité utilise un échange de jeton On-Behalf-Of. Le tutoriel décrit Denodo Agora ou une installation autogérée sur Amazon EC2 ou Amazon EKS. | Le serveur MCP AtScale relie l’agent au modèle. AgentCore Gateway et Identity gèrent les identifiants de connexion, puis le moteur AtScale résout le rôle de l’appelant. Le déploiement de référence est autogéré sur Amazon EKS. |
Des données réparties ou un entrepôt centralisé
Virtual DataPort peut planifier le travail sur les différentes sources de l’exemple Denodo, pousser des opérations vers celles-ci et réunir les résultats intermédiaires. Cette architecture permet de traiter une requête qui rapproche des données présentes dans plusieurs environnements, dont une base PostgreSQL sur site.
Dans l’exemple AtScale, chaque requête dimensionnelle est résolue par un seul moteur d’entrepôt. Les données opérationnelles d’Aurora sont répliquées en amont vers l’environnement analytique. Pour une équipe, cette différence renvoie à un choix concret : fédérer des sources au moment de l’interrogation, ou maintenir une copie analytique consolidée avant les requêtes de l’agent.
Deux façons de définir les notions métier
Denodo organise son modèle en vues de base, vues dérivées et vues de mesures réutilisables, interrogées avec VQL. Le tutoriel crée six vues de base, puis une vue dérivée au niveau client et une vue distincte pour les mesures. Cette séparation donne un emplacement aux définitions métier avant que l’agent ne formule ses demandes.
AtScale décrit ces notions dans des objets SML en YAML, dont les dimensions, les faits, les mesures, les calculs et les perspectives. Leur versionnement dans Git inscrit le modèle dans un flux de gestion des changements. Dans les deux exemples, la couche sémantique porte les jointures, les mesures métier et les règles d’accès utilisées par l’agent.
Identité, droits et informations d’audit
Les deux architectures relient l’identité de l’appelant aux contrôles de la couche sémantique, mais leurs parcours diffèrent. Denodo transmet l’identité au moyen d’un échange de jeton On-Behalf-Of. Dans l’exemple AtScale, AgentCore Gateway et Identity gèrent les identifiants de connexion, tandis que le moteur AtScale détermine le rôle de l’appelant.
Les tutoriels illustrent aussi des politiques distinctes. Denodo masque les valeurs des champs sensibles balisés pour marketing_user, alors que la perspective marketing d’AtScale exclut les champs SSN et de numéro de carte du modèle visible. L’exemple AtScale ajoute une sécurité au niveau des lignes.
L’enregistrement d’audit illustratif d’AtScale contient la requête dimensionnelle générée par le modèle de langage et le SQL traduit pour Amazon Redshift. Il comprend aussi l’identité, les politiques appliquées, l’utilisation d’agrégats et le nombre de lignes retournées. Le tutoriel Denodo met en avant la requête VQL, le rôle associé, le plan fédéré et les résultats des politiques. Les deux parcours rapportent des vérifications portant sur trois catégories de requêtes ainsi qu’une nouvelle exécution après application des règles de gouvernance.
Quel modèle correspond à votre topologie ?
Choisissez le modèle fédéré présenté avec Denodo si les réponses de l’agent doivent réunir des données qui restent réparties entre des bases cloud et des systèmes sur site. Si les données analytiques sont déjà consolidées dans un entrepôt et qu’une réplication en amont fait partie de l’architecture, l’exemple AtScale est plus proche de ce fonctionnement.
Ce choix découle des frontières d’exécution décrites dans les deux tutoriels AWS. Il aide à faire correspondre une architecture existante à l’un des modèles présentés, sans préjuger des performances d’un déploiement particulier.
