Tous les quelques mois, un client nous expose ses difficultés : des données cloisonnées, non découvrables, non interopérables, où tout devient un goulot d'étranglement. Ou bien il nous présente sa vision d'un accès aux données à l'échelle de l'entreprise. Il souhaite une gouvernance par équipe et des charges de travail d'IA sécurisées qui exploitent les actifs de chaque département sans compromettre la confidentialité ni la conformité. Il décrit l'architecture qu'il imagine, les problèmes rencontrés et les jeux politiques internes dans lesquels il doit naviguer. Puis nous répondons : « Ce que vous décrivez tient en deux mots : Data Mesh. Vous en avez entendu parler ? »
Neuf fois sur dix, la réponse est non. C'est le pattern que nous implémentons le plus souvent pour nos clients, et pourtant, ceux qui en ont le plus besoin n'ont presque jamais entendu ce terme. Ce guide est écrit pour eux, et pour quiconque soupçonne que le problème de données de son organisation relève d'un déficit de propriété, et non d'un déficit technologique.
Data Mesh sur AWS SageMaker Unified Studio est simple sur le plan architectural. AWS a industrialisé le control plane. Ce qui fait le succès ou l'échec d'un projet, c'est la capacité de votre organisation à adopter la propriété fédérée sans créer de bureaucratie. Ce guide couvre la signification de Data Mesh, la manière dont SageMaker Unified Studio l'implémente, les trois décisions architecturales qui conditionnent tout en aval, et les patterns organisationnels qui déterminent si votre mesh survivra au contact de la réalité.
Ce que Data Mesh signifie réellement (et pourquoi votre CDO n'en a probablement jamais entendu parler)
Data Mesh n'est pas une technologie. Ce n'est pas un service AWS spécifique. Ce n'est pas un remplacement de votre data lake, et ce n'est certainement pas une raison de restructurer votre organigramme du jour au lendemain. C'est une architecture organisationnelle de propriété des données : quatre principes, opérationnalisés par la technologie.
Ces quatre principes, tels que définis par Zhamak Dehghani et conformes à l'AWS Well-Architected Data Analytics Lens :
- Propriété orientée domaine. Les données appartiennent à l'équipe qui les produit, et non à une équipe « Data » centralisée qui tente de gérer les actifs de tous.
- Les données comme produit. Chaque domaine publie des datasets découvrables, avec un contrôle de qualité et un SLA définis. Pensez-y comme un contrat d'API interne, mais pour les données.
- Plateforme de données en libre-service. Une infrastructure qui permet aux équipes de domaine d'opérer de manière autonome, sans créer de tickets ni subir un goulot d'étranglement central.
- Gouvernance computationnelle fédérée. Des standards centraux, une exécution décentralisée. Les règles viennent du sommet ; l'implémentation vit au sein des équipes.
Winston Churchill a dit : « Nous façonnons nos bâtiments ; ensuite, ce sont eux qui nous façonnent. » Le même principe s'applique à la manière dont les entreprises structurent leurs équipes. Si votre entreprise regroupe les personnes par spécialisation technique (une équipe « Data » gérant l'ensemble des données de l'entreprise, indépendamment de leur propriété), votre architecture reflétera cette centralisation. La situation échappe rapidement au contrôle à mesure que les entreprises grandissent. Data Mesh inverse cette logique.
L'analogie qui résonne le plus auprès des publics techniques est le domaine-driven development. Vous comprenez le principe de regrouper le code par domaine métier : un module Paiements, et non « tous les scripts Python » ou « tous les fichiers liés à Stripe ». Data Mesh applique le même principe aux actifs de données. Les célèbres two-pizza teams d'Amazon suivent la même idée : des groupes petits, autonomes, pluridisciplinaires et orientés vers le résultat, qui possèdent leur domaine de bout en bout.
Tout comme l'architecture applicative a évolué des monolithes vers les microservices, les équipes data modularisent leurs plateformes en solutions fédérées et décentralisées. Le AWS Well-Architected Framework Data Analytics Lens met explicitement en évidence ce parallèle.
Pourquoi les CDO expérimentés passent-ils à côté ? Parce que le concept exige de penser à un niveau d'abstraction différent. Il ne s'agit pas de nouveaux outils, mais de ce qui appartient à qui et pourquoi. Ce changement cognitif est difficile, même pour des personnes qui travaillent dans la data depuis des décennies. Il est particulièrement ardu pour les responsables data, plus proches de l'implémentation opérationnelle, sur le spectre management-exécution.
Comment SageMaker Unified Studio implémente Data Mesh
AWS SageMaker Unified Studio, disponible en général depuis mars 2025, est l'implémentation concrète par AWS des principes du Data Mesh. Il repose sur SageMaker Catalog (l'évolution d'Amazon DataZone), Lake Formation, le Glue Data Catalog et Athena. Ensemble, ces services forment le control plane d'une architecture de données fédérée.
La hiérarchie : domaines, unités de domaine, projets
La structure complète se mappe proprement sur la réalité organisationnelle :
Compte AWS → Domaine(s) → Unité(s) de domaine → Projet(s) → Membre(s)
Un domaine représente une ligne d'activité majeure. La plupart des entreprises n'ont besoin que d'un seul domaine. Les exceptions sont les grandes entreprises diversifiées, comme Siemens, où des domaines distincts pour l'énergie, l'électronique grand public et le transport auraient du sens. Lorsque nous avons construit le pipeline de données événementiel pour Siemens Energy, l'architecture multi-comptes s'est naturellement alignée sur leur structure divisionnelle, un pattern que Data Mesh formalise. En règle générale, les domaines correspondent aux grandes lignes d'activité des entreprises qui ont la main sur de nombreuses activités faiblement liées entre elles.
Le design recommandé est un domaine de gouvernance unique qui ne contient ni données ni unités de domaine et sert uniquement de control plane pour le mesh. C'est là que les règles et les bonnes pratiques s'appliquent. Les autres domaines riches en données sont intégrés afin d’y participer. Les producteurs de données comprennent des data owners et des data engineers. Les consommateurs de données comprennent des data engineers, des créateurs de rapports et des data scientists. Si possible, gardez le compte AWS de gouvernance séparé des autres comptes. Sinon, placez-les côte à côte dans un même compte AWS.
Les unités de domaine sont des subdivisions organisationnelles au sein d'un domaine : départements, équipes, capacités. C'est là que réside l'essentiel de la structure.
La règle empirique : un domaine de gouvernance, un domaine métier racine avec de nombreuses unités de domaine, et de nombreux projets par unité de domaine. Puis, cette structure est répliquée dans les comptes de développement, d'UAT et de production.
Les projets comme unité de travail
Une équipe projet n'est pas une équipe permanente. C'est une intersection pluridisciplinaire de personnes issues de différentes équipes physiques, regroupées autour d'un objectif métier précis. Les membres sont soit contributeurs, soit propriétaires, et ils vont et viennent selon les besoins du projet.
C'est ici que meurt l'objection : « Vous voulez que j'embauche un data engineer pour chaque département ? ». Les data engineers rejoignent temporairement un projet spécifique, configurent la machinerie nécessaire, puis repartent, pour revenir quand l'équipe propriétaire a de nouveau besoin d'eux. Les mêmes personnes qu'aujourd'hui. Des niveaux d'abstraction différents.
Les projets incluent les ressources nécessaires pour atteindre leurs objectifs métier : un Data Lakehouse pour les sources de données, des outils ETL (scripts, notebooks, orchestration Airflow) pour le traitement et la migration, et des serveurs de suivi MLflow pour le travail de data science. Chaque projet sélectionne des blueprints qui provisionnent ces ressources, et nous recommandons fortement de configurer tous les blueprints en ONDEMAND plutôt qu'en ONCREATE (voir la section sur les coûts ci-dessous pour plus de détails).
Un domaine corporate utilise le blueprint Tooling ; un domaine IAM personnel utilise le plus récent (mais moins complet) ToolingLite. Les différences entre les deux et quand utiliser lequel feront l'objet d'un autre article de cette série.
Le catalogue : pattern producteur/consommateur
Le Data Mesh prend vie à travers le pattern producteur/consommateur, qui se mappe directement sur l'architecture de référence Well-Architected :
- Les projets producteurs publient des actifs de données dans SageMaker Catalog, accompagnés de métadonnées, de termes de glossaire, d'informations de qualité et de lignage.
- Les projets consommateurs s'abonnent à ces actifs et les interrogent via Athena depuis SageMaker Unified Studio.
- Lake Formation applique le contrôle d'accès au niveau des partitions et sert de couche de gouvernance entre producteurs et consommateurs.
Chaque couche (producteur, gouvernance, consommateur) réside dans son propre compte AWS, conformément aux recommandations du cadre Well-Architected. Cette bonne pratique n'est pas toujours applicable. De nombreuses entreprises, même les grandes, hébergent des workloads qui partagent le même compte AWS plutôt que d'être ségrégés. La convention la plus courante consiste à créer un compte AWS pour chaque environnement (dev/uat/prd).
Projets Master Data producteurs : notre recommandation
Nous recommandons d'établir des projets dédiés autour des sources de données critiques, en ajoutant « Master Data » au nom : « CRM Master Data », « Website Analytics Master Data ». Ceux-ci sont alimentés par une source de données, utilisée par plusieurs consommateurs au sein de plusieurs projets.
Une nuance mérite d'être clarifiée : tout projet peut être à la fois producteur et consommateur de données. La plupart le seront. Cependant, les projets Master Data constituent des feuilles essentielles et atomiques. En règle générale, ils ne consomment pas. Ils exposent une source de données au catalogue du mesh. Le Well-Architected Framework recommande de mettre en place ces producteurs dès que possible, mais la réalité est plus subtile. Nous avons rencontré des exceptions : le système de gestion des polices d'assurance d'un client et son prédécesseur étaient exposés comme des datasets distincts, ainsi qu'une vue agrégée qui rétrofit l'ancien schéma dans le nouveau. Les consommateurs pouvaient interroger le référentiel de polices comme s'il n'avait jamais migré. La plomberie interne et les décisions métier historiques étaient masquées, ce qui facilitait l'interfaçage.
Seuls les data owners (le département commercial pour le CRM, l'équipe marketing pour ses analytics) sont membres permanents. Les data engineers sont invités temporairement pour configurer les blueprints et les connexions, puis retirés jusqu'à ce qu'on ait de nouveau besoin d'eux. Ces projets Master Data exposent des jeux de données nettoyés, avec des noms lisibles, des glossaires, des métadonnées, des descriptions, du lignage et des informations de qualité. Ils constituent les blocs fondamentaux de tout le travail d'analytique, de BI et d'IA en aval.
Trois décisions qui conditionnent tout
Avant d'écrire le moindre code d'infrastructure, trois décisions déterminent la complexité de votre implémentation, la granularité de votre gouvernance et votre facture mensuelle.
Décision | Option A | Option B | Notre recommandation | Raison |
|---|---|---|---|---|
Stratégie de comptes AWS | Un compte par environnement (dev/UAT/prod) avec tous les domaines et projets | Un compte par domaine (si multi-domaine) ou par projet (si uni-domaine) | Un par domaine/projet avec (dev/UAT/prod chacun) | Reflète le SDLC et respecte la bonne pratique d'un compte AWS par combinaison workload + environnement. |
Modèle d'identité | SSO via AWS Identity Center | IAM | SSO | Granularité par utilisateur, traçabilité, gouvernance fine de Lake Formation, recommandé par AWS. |
Posture réseau | Pas de VPC (défaut) | VPC uniquement | Commencer en ouvert, sauf si une politique l'impose autrement | Le VPC-only ajoute une complexité significative ; prouvez la valeur d'abord, resserrez ensuite. |
1. Stratégie de comptes AWS
L'idéal est d'avoir un compte AWS par workload et par environnement. Pour un mesh uni-domaine, cela signifie généralement un compte par environnement (dev/UAT/prd), avec la structure complète du domaine répliquée dans chacun d’eux. Pour les entreprises multi-domaines, chaque domaine (voire chaque projet majeur) dispose de son propre ensemble de comptes. Le principe : isoler le rayon d'impact et refléter votre SDLC.
Chaque compte possède son propre domaine racine. Développez le mesh comme une application : construisez en dev, testez en UAT, déployez en production.
Ne confondez pas le concept d'environnement d'AWS (au sein de Unified Studio) avec les environnements dev/UAT/prod. Ce sont des choses différentes. Chaque environnement SDLC aura la structure complète du domaine répliquée.
2. Modèle d'identité : SSO vs IAM
SSO via AWS Identity Center est fortement recommandé. Il fournit une granularité par utilisateur pour la gouvernance, la traçabilité et le contrôle d'accès fin aux données. SSO fonctionne là où IAM échoue. La console AWS de SageMaker Unified Studio continuera de vous inviter à configurer SSO tant que vous ne l'aurez pas fait.
L'alternative, IAM avec des groupes fédérés, perd en granularité. La plus petite unité de contrôle d'accès devient un groupe, ce qui est trop grossier pour une gouvernance des données significative. Si votre entreprise impose des groupes fédérés sans Identity Center, vous sacrifierez la traçabilité et l'auditabilité par utilisateur.
Voici la réalité politique : SSO est souvent l'un des éléments les plus difficiles à obtenir auprès des clients. Ils ont les mains liées par la hiérarchie. Les domaines IAM fonctionnent si les utilisateurs IAM sont autorisés, mais ce n'est pas toujours garanti.
Nous observons souvent une confusion : les clients confondent IAM/SSO (accès à l'infrastructure, qui permet de se connecter à la console AWS) avec Lake Formation (gouvernance des données, qui permet de voir quelles lignes et quelles colonnes dans les tables). Ce sont des plans de contrôle d'accès distincts. La plupart des technologistes connaissent bien IAM, mais n'ont pas encore rencontré les concepts de Lake Formation tels que l'accès par ligne, l'accès par colonne, le RBAC ou le TBAC. Chaque implémentation commence par une séance au tableau blanc pour décortiquer cette distinction.
3. Posture réseau : VPC-only vs ouvert
Les domaines VPC-only sont plus sécurisés mais augmentent considérablement la complexité d'implémentation. Attendez-vous à configurer des VPC service endpoints, à modifier des security groups et à coordonner avec l'IT pour les changements de réseau. Dans les organisations utilisant des architectures hub-and-spoke avec des Transit Gateways, où les VPC spoke n'ont pas de trafic Internet, la complexité s'accroît davantage.
Si le VPC-only est requis (par une politique ou une réglementation), commencez dès le début. Ne le laissez pas pour plus tard. Retrofiter le VPC-only sur un mesh existant est bien plus difficile que de le construire dès le premier jour.
Pour les premiers déploiements où le VPC-only n'est pas imposé, commencez par la posture ouverte par défaut, prouvez la valeur du mesh, puis resserrez. Mais uniquement si c'est véritablement une option pour votre organisation.
Une défense pratique contre les futurs audits de sécurité consiste à ajouter CDK NAG dès le premier jour. La surcharge est réelle, mais elle fournit une avance lorsque (et non si) quelqu'un demande : « Est-ce que cela a été validé par rapport aux bonnes pratiques AWS ? »
Le modèle opérationnel : là où les implémentations réussissent ou échouent
La technologie représente environ 30 % d'une implémentation de Data Mesh. Les 70 % restants relèvent de la gestion du changement organisationnel : les rôles, la propriété et la politique de contrôle des données.
Pourquoi les équipes de domaine résistent à la propriété
L'objection la plus courante est : « Vous voulez que j'embauche un data engineer pour chaque département ? » Les managers entendent « propriété fédérée » et imaginent immédiatement des demandes de headcount pour chaque équipe.
Le recadrage : une équipe projet peut être fluide plutôt que permanente. Une équipe data (l'actuel « Département Data ») est un groupe fixe de personnes. Un projet est une intersection transitoire de sous-ensembles issus de différentes équipes, assemblés autour d’un objectif métier. Les data engineers existent déjà. Nous n'en embauchons pas de nouveaux. Nous regroupons les mêmes personnes différemment selon les projets. Si une équipe occupe régulièrement un membre technique à plein temps, en tant que manager, vous avez probablement découvert un besoin local critique, et l'embauche d'un FTE dédié pourrait être une bonne idée.
La loi de Conway garantit que votre structure organisationnelle actuelle produit votre architecture actuelle. Data Mesh inverse cela : regroupez par résultat métier, pas par spécialisation technique.
Le paradoxe de la gouvernance
La gouvernance centrale définit les standards : conventions de nommage, seuils de qualité, politiques de rétention et règles de classification. Les équipes de domaine mettent en œuvre et maintiennent les contrats pour leurs propres produits de données.
La partie la plus difficile n'est pas la technologie. C'est d'amener les parties prenantes paranoïaques sur l'accès aux données à s'accorder sur la définition de « partager ». Leur faire comprendre que ce n'est ni tout ni rien. Le paradoxe de la sécurité réapparaît : moins la gouvernance d'une organisation est mature, plus la barre qu'elle fixe pour le nouveau système est élevée.
Contrats de données et responsabilité
Chaque produit de données nécessite un contrat défini : un schéma, des règles de qualité, un SLA de fraîcheur et un propriétaire nommé. Le Well-Architected Data Analytics Lens précise que les produits de données doivent être autonomes, découvrables, sécurisés et réutilisables.
Le rôle de data steward (selon l'architecture de référence d'AWS) assure la prise de décision fédérée et l'auditabilité des métadonnées. Sans contrats ni stewardship, un mesh dégénère en un désordre distribué, pire que le lac centralisé qu'il a remplacé.
Obtenir l'adhésion
L'implémentation est autant politique qu'ingénierie. Commencez par un projet Master Data producteur. Prouvez que le contrôle d'accès fonctionne : que l'équipe commerciale peut voir ses données CRM, que l'équipe marketing peut interroger ses analytics web, et qu'aucune ne peut accéder aux tables de l'autre avec un contrôle granulaire par projet.
L'argument « Marie Kondo » : avant de pouvoir exécuter des workloads d'IA à l'échelle de l'entreprise, vous avez besoin d'un accès granulaire et contextualisé à des données bien gouvernées. Data Mesh n'est pas un luxe en marge de votre feuille de route en IA. C'est le prérequis qui rend l'IA possible.
Ce que cela coûte (et ce qui surprend)
L'infrastructure du mesh elle-même est peu coûteuse. Les coûts imprévus proviennent des blueprints que vous activez sans comprendre les ressources qu'ils provisionnent.
Le piège des coûts liés aux blueprints
La mise en place de SageMaker Unified Studio n'entraîne aucun coût par domaine. Lake Formation, le Glue Catalog et la gestion des projets sont essentiellement gratuits à petite échelle. La facture provient des ressources de calcul que les blueprints provisionnent. (Consultez la tarification SageMaker pour connaître les tarifs actuels.)
La surprise la plus coûteuse : le serveur de suivi MLflow. Activé par un blueprint orienté ML, il facture quelques milliers de dollars par mois (dans les bas-chiffres, à un seul chiffre), même pour l'option de calcul la plus petite, même quand personne ne l'utilise. Nous avons vu des clients découvrir cela des semaines après l'activation, se demandant d'où venait la facture. (Note : AWS a annoncé une option MLflow serverless fin 2025 sans frais supplémentaires, mais le serveur de suivi managé provisionné par les anciens blueprints conserve ce coût.)
Les code spaces (les environnements de calcul distants JupyterLab et VS Code dans lesquels vous rédigez vos scripts) sont abordables mais pas gratuits. Une instance t3.medium coûte environ 0,60 $ pour 10 heures d'utilisation, et le délai d'inactivité minimal avant l'arrêt automatique est d'une heure.
Le stockage GP3 revient à environ 2 $ pour 15 Go par mois. Négligeable.
Le pattern : Infrastructure (domaines, projets, catalogue) = essentiellement gratuite. Calcul (endpoints, serveurs de suivi, code spaces) = là où la facture augmente. Gouvernance (Lake Formation, permissions) = gratuite. Stockage = peu coûteux.
Notre recommandation : si vous ne savez pas à l'avance de quelles fonctionnalités votre projet aura besoin, vous pouvez créer le profil de projet « All Capabilities » avec tous les blueprints ajoutés et les configurer tous en ONDEMAND, pas en ONCREATE. Si vous ne savez pas ce qu'un blueprint provisionne, ne l'activez pas. Nos prochains articles de cette série expliqueront chaque blueprint et ce qu'il crée.
Comment nous aidons sur les coûts
En tant que partenaire AWS, nous aidons nos clients à accéder à des avantages financiers au-delà de ceux disponibles grâce à l'optimisation habituelle du calcul : des économies qui ne sont pas accessibles en travaillant directement avec AWS. Tous les clients bénéficient de DoIt PartnerOps, une plateforme FinOps et de conformité multi-cloud, sans frais supplémentaires. Elle offre une visibilité précise sur les ressources provisionnées par les blueprints générant la dépense. Nous avons vu des clients économiser l'équivalent de nos honoraires de conseil grâce à l'outil d'optimisation des coûts, utilisé seul.
Le chemin pragmatique : commencer petit, prouver la valeur
Ne cherchez pas à tout faire d'un coup. Choisissez une source de données critique, une unité de domaine et un consommateur, et prouvez que le pattern fonctionne avant de demander à quiconque d'autre de changer quoi que ce soit.
Étape 1 : Identifiez votre dataset le plus demandé, celui que chaque projet obtient actuellement via des messages Slack, des drives partagés ou des exports manuels. Alternativement, choisissez un point de friction : « Nous dépensons trop sur cette plateforme SAS existante et devons migrer vers une architecture moderne. »
Étape 2 : Créez un projet Master Data producteur, attribuez le data owner et configurez l'accès à Lake Formation via SageMaker Unified Studio plutôt que directement dans la console Lake Formation.
Étape 3 : Publiez dans SageMaker Catalog avec des métadonnées, des termes de glossaire et des règles de qualité.
Étape 4 : Intégrez un projet consommateur. Prouvez qu'il peut accéder aux données et les interroger sans demander à personne. Connectez AWS QuickSight pour que les parties prenantes métier puissent dialoguer avec le tableau de bord BI. La réaction est généralement immédiate.
Étape 5 : Célébrez la victoire. Puis passez au dataset suivant. Si c'est bien fait, chaque intégration réussie crée au moins un évangéliste interne, quelqu'un qui a vu le système fonctionner et qui en parle à ses collègues. Ces évangélistes sont essentiels. Les consultants ne bénéficient pas du même niveau de confiance. Le plaidoyer entre pairs diffuse la philosophie Data Mesh bien plus efficacement que n'importe quel mandat top-down.
C'est exactement ce que le Well-Architected Lens recommande : des cycles de livraison rapides, avec des itérations tirées des leçons apprises. L'alternative (un déploiement big-bang du mesh qui exige que tout le monde change simultanément) meurt dans les comités de gouvernance.
Pour les équipes qui souhaitent automatiser ce processus avec l'Infrastructure as Code : nous maintenons une bibliothèque open-source opiniâtre de constructs L2 pour SageMaker Unified Studio, gérée avec projen. Elle provisionne des domaines, des unités de domaine, des projets et des blueprints en un seul déploiement CDK. Nous publierons sur NPM et PyPI une fois stabilisée ; suivez notre GitHub pour les mises à jour.
Quelques notes pratiques pour les équipes qui choisissent la voie IaC : à mesure que votre mesh grandit, vous atteindrez la limite de 500 ressources par stack CloudFormation. Notre approche consiste en un stage CDK séparé pour les ressources Data Mesh, un stack par domaine et des nested stacks pour les projets. Cela laisse de la marge pour évoluer sans refactorer l'ensemble du déploiement.
Automatisez vos tests CDK dès le premier jour. Il y aura une évolution significative du code, et vous voulez minimiser le temps passé à attendre des déploiements échoués. Ces minutes perdues s'accumulent.
AWS fournit également des points de départ utiles : un CLI CI/CD pour SageMaker Unified Studio et un dépôt officiel d'utilitaires avec des templates CloudFormation pour les patterns courants.
Conclusion
Data Mesh dans SageMaker Studio est simple sur le plan architectural. AWS a industrialisé le control plane : domaines, projets, catalogue et permissions de Lake Formation. La technologie fonctionne. Ce qui fait le succès ou l'échec de votre implémentation, c'est la capacité de votre organisation à adopter la propriété fédérée sans générer davantage de bureaucratie qu'elle n'en élimine.
Le constat préalable n'a pas changé : il est impossible d'exécuter des workloads d'IA sécurisés à l'échelle de l'entreprise sans un accès granulaire et contextualisé aux données gouvernées. La pyramide des besoins de l'IA s'applique ici : des données propres, gouvernées et accessibles constituent le socle sur lequel tout le reste repose. Data Mesh n'est pas un projet annexe en marge de votre feuille de route en IA. C'est ce qui rend possible l'IA d'entreprise.
Si cela décrit votre défi (une vision d'accès aux données à l'échelle de l'entreprise sans chemin clair pour y parvenir), c'est précisément ce que nous accompagnons. En tant que partenaire AWS, nous apportons des certifications, des avantages financiers et de l’expérience de terrain.
