Le 27 mai 2026, Snowflake annonce son intention d'acquérir Natoma, une plateforme enterprise spécialisée dans la gouvernance des serveurs MCP (Model Context Protocol) pour agents IA. L'acquisition — dont les termes financiers ne sont pas divulgués — est présentée au Snowflake Summit 2026 (San Francisco, 1-4 juin) comme une pièce centrale de la stratégie « agentic enterprise » de Snowflake.
Pour comprendre pourquoi cette acquisition est significative, il faut saisir le problème qu'elle résout : le MCP permet aux agents IA d'appeler des outils externes, mais ne dit rien sur qui a le droit d'appeler quoi, dans quel contexte, avec quel niveau d'audit. Dans un environnement de test ou de démonstration, c'est acceptable. Dans une entreprise où l'agent IA accède à un ERP, à une base de données clients ou à un système de facturation, ça ne l'est pas.
Natoma apporte précisément cette couche manquante. Et le fait que Snowflake — l'un des acteurs les plus importants de la data infrastructure enterprise — mise dessus envoie un signal fort sur la direction que prend le MCP dans les environnements professionnels.
Le problème non résolu du MCP en entreprise
Réponse directe. Le Model Context Protocol résout un problème d'interopérabilité : il donne aux agents IA un standard pour appeler des outils externes (API internes, bases de données, SaaS, fichiers) sans intégration ad hoc à chaque fois. C'est sa force. Mais dans sa spécification de base, il ne résout pas les questions de gouvernance enterprise :
- Identité : qui appelle ce serveur MCP ? L'agent A ou l'agent B ? L'utilisateur Jean-Pierre ou le workflow automatique de nuit ?
- Autorisations : cet agent a-t-il le droit d'appeler cet outil avec ces paramètres ? L'accès aux données clients de l'outil CRM doit-il être restreint au contexte de support, pas au contexte de reporting ?
- Audit : qui a appelé quoi, quand, avec quels paramètres, et quelle réponse a été obtenue ? La traçabilité est indispensable pour la conformité (RGPD, ISO 27001, NIS2) et pour le debugging opérationnel.
Dans les premières phases d'adoption du MCP — des équipes techniques en mode expérimental — ces manques étaient tolérables. Dans un déploiement à l'échelle d'une ETI avec plusieurs agents actifs, plusieurs équipes et des données sensibles, ils deviennent des risques réels. Un agent sans gouvernance d'accès MCP peut appeler n'importe quel outil exposé sur le réseau avec les permissions globales de l'environnement. C'est l'équivalent d'un utilisateur avec des droits admin sur tous les systèmes.
C'est le problème que Natoma adresse — et que Snowflake a décidé d'intégrer nativement dans sa plateforme plutôt que de laisser chaque client le résoudre de son côté.
Ce que fait Natoma : une passerelle MCP avec identité et audit
Techniquement, Natoma se positionne comme une passerelle (gateway) entre les agents IA et les serveurs MCP. Plutôt que l'agent appelle directement le serveur MCP qui expose un outil, il passe par Natoma, qui évalue chaque appel selon trois dimensions :
- Identité vérifiée : Natoma vérifie l'identité de l'agent ou du workflow à l'origine de la demande, en s'appuyant sur les standards d'identité existants. Chaque appel d'outil est associé à une identité — pas simplement à un token API partagé.
- Politiques d'accès granulaires : des règles définissent quels agents ont accès à quels outils, dans quels contextes, avec quels paramètres autorisés. Ces politiques sont définies par les équipes IT/sécurité, pas codées en dur dans les agents.
- Audit au niveau de l'appel d'outil : chaque appel — quel outil, quels paramètres, quelle réponse, à quel moment, par quelle identité — est consigné dans un log d'audit exploitable. C'est une granularité que les logs applicatifs classiques ne fournissent pas.
Ce positionnement est analogue à celui d'un reverse proxy ou d'une API gateway dans une architecture REST traditionnelle — sauf que Natoma est spécialisé pour le protocole MCP et ses particularités (appels d'outils structurés, contexte d'agent, sessions longues).
La plateforme couvre une large surface d'intégration : applications SaaS, environnements cloud, VPCs et infrastructure on-premise. C'est important pour les ETI qui ont des systèmes dans plusieurs environnements — la gouvernance MCP doit être uniforme, pas fragmentée par type d'infrastructure.
Ce que ça change dans l'écosystème Snowflake
Snowflake intègre Natoma dans l'ensemble de sa suite d'agents IA, qui comprend en juin 2026 :
- Snowflake Intelligence (rebaptisé CoWork) : l'agent de productivité pour les knowledge workers, qui donne accès à des données et des workflows à travers une interface conversationnelle.
- Snowflake Cortex Code (rebaptisé CoCo) : l'agent de codage pour les développeurs et data engineers qui travaillent dans l'environnement Snowflake.
- Cortex Agents : la couche d'orchestration d'agents IA programmables sur la plateforme Snowflake.
Avec l'intégration de Natoma, tout appel d'outil MCP depuis ces agents sera gouverné nativement : identité vérifiée, politiques applicables, trace d'audit disponible. Pour les équipes IT qui déploient Snowflake, cela signifie que la gouvernance IA ne nécessite plus une couche de middleware maison — elle est fournie par la plateforme.
La logique est cohérente avec la stratégie globale de Snowflake au Summit 2026 : se positionner comme le « plan de contrôle de l'entreprise agentique ». Snowflake n'est plus uniquement un entrepôt de données — c'est une plateforme où les données, les modèles et les agents sont gérés ensemble, avec une couche de gouvernance unifiée.
Par ailleurs, Snowflake a annoncé en parallèle un accord de collaboration stratégique pluriannuel avec AWS (6 milliards de dollars sur cinq ans), renforçant la profondeur d'intégration cloud qui rend ces déploiements enterprise crédibles à grande échelle.
Ce que cette acquisition dit de l'adoption du MCP
Au-delà des produits Snowflake, l'acquisition de Natoma envoie un signal clair sur la trajectoire du MCP comme standard enterprise : assez mature pour que ses lacunes de gouvernance justifient une acquisition à part entière par un acteur de référence.
Quelques repères pour contextualiser :
- Le MCP a été lancé par Anthropic fin 2024. En moins de 18 mois, il est devenu suffisamment adopté pour qu'un écosystème de startups spécialisées émerge autour de lui (Natoma, mais aussi d'autres acteurs de l'espace MCP gateway).
- Les statistiques d'adoption MCP publiées en 2026 font état de dizaines de milliers de serveurs MCP disponibles publiquement, et de millions de déploiements en entreprise.
- Les grandes plateformes — Microsoft (via Claude en Copilot et MXC), Google (Gemini + MCP), Snowflake — ont toutes intégré ou annoncé une intégration MCP native dans leurs environnements d'agents.
Ce contexte d'adoption massive crée précisément le problème que Natoma résout : plus il y a de serveurs MCP disponibles et d'agents capables de les appeler, plus la question du contrôle granulaire des accès devient critique. La gouvernance MCP n'est plus un sujet pour les équipes de sécurité avancées — c'est une hygène de base pour tout déploiement d'agents IA sérieux.
Pour les PME et ETI qui construisent leurs propres intégrations MCP — comme nous le faisons pour nos clients dans le cadre de projets d'automatisation métier — cette tendance confirme qu'investir dans une couche de gouvernance MCP dès maintenant est un choix architectural pertinent, pas une complexité superflue.
Implications pour vos architectures IA d'entreprise
Réponse directe. Si vous construisez ou planifiez des agents IA avec accès à des outils internes via MCP, voici ce que l'acquisition Snowflake-Natoma change concrètement pour vos choix d'architecture :
1. La gouvernance MCP n'est plus optionnelle
Jusqu'ici, des équipes techniques pouvaient déployer des agents MCP en mode « permissif » — l'agent a accès à tout ce que le réseau permet. À mesure que les agents IA accèdent à des données de plus en plus sensibles (clients, finances, RH), l'absence de gouvernance granulaire devient un risque documentable. Une politique d'accès explicite au niveau du call MCP est la bonne pratique de référence.
2. Préférer les solutions avec couche d'identité intégrée
Que vous utilisiez Snowflake, Azure, AWS ou une infrastructure custom, anticipez dès la conception la question : « quelle identité est associée à chaque appel de mon agent ? ». Les bonnes pratiques de gouvernance des agents IA recommandent de traiter chaque agent comme un principal d'identité à part entière — avec ses propres permissions, son propre périmètre d'action, et un log associé.
3. L'audit MCP comme réponse aux exigences de conformité
Pour les entreprises soumises au RGPD, à NIS2 ou à des certifications ISO 27001, la traçabilité des accès IA aux systèmes est une obligation croissante. Un log d'audit au niveau de l'appel MCP — qui, quoi, quand, avec quels paramètres — est le niveau de granularité que les auditeurs vont progressivement demander. L'intégrer dès la conception est moins coûteux que de le retrofitter.
4. Ce que ça ne change pas
Les fondamentaux de la connectivité MCP sécurisée restent valides : tunnels chiffrés, périmètre réseau clair, serveurs MCP exposant uniquement ce qui est nécessaire. La gouvernance Natoma/Snowflake vient s'ajouter à cette base, pas la remplacer. Pour les outils internes sur mesure que nous développons, les deux couches sont complémentaires.
FAQ — Snowflake rachète Natoma : le MCP s'impose comme couche de gouvernance des agents IA en entreprise
Qu'est-ce que Natoma et pourquoi Snowflake l'a-t-il racheté ?
Natoma est une plateforme enterprise spécialisée dans la gouvernance des serveurs MCP (Model Context Protocol). Elle agit comme une passerelle qui s'intercale entre les agents IA et les outils qu'ils appellent via MCP, en appliquant à chaque appel des contrôles d'identité, des politiques d'accès et un audit granulaire. Snowflake l'a rachetée (annonce du 27 mai 2026) pour intégrer cette couche de gouvernance nativement dans sa suite d'agents IA — CoWork, CoCo, Cortex Agents — sans laisser les clients gérer ce problème eux-mêmes.
Le MCP standard ne suffit-il pas pour sécuriser les accès des agents IA ?
Non, pas dans un environnement enterprise. La spécification MCP de base définit comment un agent IA appelle un outil externe (le protocole, les formats, la structure des messages). Elle ne spécifie pas qui a le droit d'appeler quoi, dans quel contexte, avec quelles restrictions. Dans un cadre de test, cette absence est acceptable. En production avec des données sensibles, elle crée des risques d'accès non contrôlés. Une couche comme Natoma — ou tout équivalent — est nécessaire pour opérer du MCP en entreprise avec des exigences de sécurité réelles.
Cette acquisition concerne-t-elle uniquement les clients de Snowflake ?
Directement, oui : l'intégration Natoma est d'abord disponible pour les produits Snowflake. Mais indirectement, elle structure ce que le marché va considérer comme la bonne pratique de référence en gouvernance MCP. Les acteurs qui n'utilisent pas Snowflake — et qui déploient des agents MCP sur d'autres plateformes — vont être confrontés à la même question de gouvernance, et chercheront des solutions équivalentes. L'acquisition accélère la normalisation de ce besoin.
Comment implémenter une gouvernance MCP basique sans Snowflake ni Natoma ?
Pour une première approche, trois éléments suffisent à établir un périmètre raisonnable : (1) définir explicitement les outils MCP accessibles par chaque agent et documenter cette matrice dans un fichier de configuration versionné ; (2) associer chaque agent à une identité de service distincte (clé API dédiée, token spécifique) plutôt qu'un token global partagé ; (3) activer les logs structurés sur les appels MCP avec les champs qui, quoi, quand. Ces étapes ne remplacent pas une solution dédiée, mais elles constituent une base saine sur laquelle construire.
Quels secteurs sont les plus concernés par la gouvernance MCP en priorité ?
Les secteurs avec des données sensibles et des obligations réglementaires fortes : banque et assurance (DSP2, DORA), santé (HDS, RGPD données de santé), industrie avec données de production confidentielles, secteur public. Pour ces secteurs, un agent IA sans gouvernance d'accès MCP n'est pas déployable dans un environnement de production — c'est un bloqueur légal et assurantiel, pas juste une bonne pratique.