Nutanix a franchi une étape importante dans l’automatisation de l’infrastructure en lançant un serveur MCP (Model Context Protocol) pour Nutanix Cloud Platform. Open source, cette solution permet aux assistants et agents d’intelligence artificielle d’interagir avec des environnements hybrides via l’API Prism v4. L’objectif est que des outils tels que GitHub Copilot, Claude Code ou Cursor puissent consulter, diagnostiquer et automatiser des tâches sur l’infrastructure sans compromettre les contrôles d’accès et de gouvernance déjà en place sur la plateforme.

Les points clés du MCP de Nutanix en 20 secondes

• Nutanix a publié un serveur MCP open source pour Nutanix Cloud Platform.
• Les agents accèdent à l’infrastructure via les API Prism v4.
• Le système hérite de contrôles d’accès basés sur les rôles, d’audits et de limites d’utilisation.
• Il peut être utilisé avec des outils comme GitHub Copilot, Claude Code ou Cursor.
• Nutanix assure une supervision humaine et une gestion asynchrone pour les opérations longues.

Ce mouvement est particulièrement significatif car il transfère la conception d’IA agentique, traditionnellement associée à la génération de code, vers un domaine beaucoup plus sensible : la gestion réelle de l’infrastructure.

Jusqu’à présent, demander à une IA d’expliquer comment créer une machine virtuelle était relativement simple. En revanche, lui permettre de consulter l’état d’un cluster, d’identifier un problème, de planifier une opération de maintenance ou de lancer une intervention en production constitue un changement de dimension.

C’est là qu’intervient MCP.

Ce que MCP apporte à la gestion de Nutanix

Le Model Context Protocol est devenu une méthode standard pour connecter modèles et agents avec des outils, données et services externes.

Dans ce contexte, le serveur MCP agit comme un intermédiaire entre l’agent et la Nutanix Cloud Platform.

Le flux peut être simplifié ainsi :

Administrateur
     │
     ▼
Agent IA
     │
     ▼
Serveur MCP de Nutanix
     │
     ▼
API Gateway Prism v4
     │
     ▼
Nutanix Cloud Platform

Une requête formulée en langage naturel peut être traduite en une ou plusieurs appels aux APIs de Nutanix.

Par exemple, un administrateur pourrait demander :

Montre-moi les machines virtuelles qui consomment le plus de mémoire 
dans le cluster de production ces dernières heures.

L’agent peut interpréter l’intention, utiliser les outils fournis par MCP, et interroger la plateforme.

La différence fondamentale avec un Large Language Model (LLM) construisant librement des appels REST est que l’agent n’obtient pas un accès illimité automatique à l’infrastructure.

Le serveur travaille sur les API et permissions existantes de Nutanix.

Prism v4 devient la couche de contrôle

Ce qui compte, dans cette annonce, ce n’est pas tant le langage naturel, mais ce qui se trouve en dessous.

Nutanix supporte le serveur MCP via son API Gateway de Prism v4. La société recommande désormais les API v4 pour la production, en planifiant une dépréciation progressive des APIs héritées v0.8, v1, v2 et v3, prévue dans une mise à jour pour le quatrième trimestre 2026.

Les API v4 couvrent actuellement plusieurs domaines d’administration :

• machines virtuelles ;
• stockage ;
• réseaux ;
• sécurité ;
• monitoring ;
• gestion du cycle de vie ;
• AIOps ;
• opérations sur Prism ;
• administration multi-domaine ;
• licences ;
• reprise après sinistre.

Cela signifie que MCP ne crée pas une voie administrative parallèle. Nutanix souhaite que l’IA utilise les mêmes interfaces que celles sur lesquelles s’appliquent déjà des contrôles de sécurité et de gouvernance.

Pour une entreprise, cette distinction est fondamentale.

Il ne s’agit pas de connecter un chatbot directement à des identifiants administratifs, mais de permettre à un agent de travailler via une API où chaque opération est limitée et contrôlée.

Les agents disposent aussi de RBAC

Un problème traditionnel des agents d’infrastructure concerne la portée de leurs permissions.

Nutanix propose d’utiliser RBAC (Role-Based Access Control) pour restreindre l’accès de chaque agent à certaines API.

Un agent dédié à la surveillance pourrait par exemple disposer uniquement de permissions en lecture :

Agent : Observateur d'infrastructure

✓ lister les machines virtuelles
✓ consulter les alarmes
✓ lire les métriques
✓ revoir les tâches

✗ créer des VM
✗ supprimer des volumes
✗ modifier les réseaux
✗ mettre à jour le cluster

Un autre agent, spécialisé dans le provisioning, pourrait disposer de permissions supplémentaires mais limitées à certains types de ressources.

Ce modèle est nettement plus raisonnable que de donner une seule fois un accès administratif global à un assistant.

La documentation des API v4 montre que les opérations disposent déjà de permissions spécifiques selon le type de ressource. Par exemple, différentes opérations dans Prism distinguent entre rôles tels que Cluster Admin, Prism Admin, Prism Viewer ou Domain Manager Admin.

Le serveur MCP exploite cette structure, au lieu de la remplacer.

L’audit : savoir qui a fait quoi

Un autre enjeu crucial survient après l’exécution d’une opération.

Si un administrateur supprime une machine virtuelle, il faut pouvoir tracer qui a lancé cette opération.

Avec des agents, c’est la même chose, mais avec une couche supplémentaire :

utilisateur
   ↓
agent
   ↓
outil MCP
   ↓
API
   ↓
 infrastructure

Nutanix affirme que son architecture conserve des logs permettant d’identifier quel agent a initié une opération donnée.

C’est particulièrement indispensable lorsque plusieurs automatisations travaillent simultanément sur la plateforme.

Dans un contexte professionnel, il ne suffit pas que la IA indique simplement :

« L’opération a été complétée. »

Les équipes doivent pouvoir reconstituer ultérieurement :

Qui a demandé l’opération
Quel agent l’a interprétée
Quelle outil a été utilisé
Quelle API a été invoquée
Quel ressource a été affectée
Quand cela a été fait
Quel a été le résultat

Une telle traçabilité sera indispensable pour que les agents puissent passer de simples requêtes à une intervention en production véritablement contrôlée.

Nutanix ajoute des limites pour éviter les dérapages

Un autre risque associé à l’automatisation via agents concerne la vitesse d’exécution.

Une erreur humaine peut générer une requête incorrecte, que l’agent pourra répéter à l’infini.

Nutanix prévoit des mécanismes de limitation de débit (throttling) et de comptage (metering) sur les APIs pour maîtriser le volume de requêtes.

La société mentionne explicitement la protection contre des scénarios de agent swarm, où plusieurs agents pourraient générer un volume important de requêtes simultanément.

Voici le processus typique :

10 agents
   │
   │ 10 000 requêtes
   ▼
API Gateway
   │
   ├── authentification
   ├── RBAC
   ├── limitation de débit
   ├── comptage
   ├── audit
   │
   ▼
Infrastructure

Pour des administrateurs habitués aux API classiques, cette démarche peut sembler évidente.

Avec des agents autonomes, c’est encore plus crucial.

La boucle humaine avant la mise en production

Nutanix ne préconise pas forcément une infrastructure totalement autonome.

La plateforme maintient une approche human-in-the-loop, où certaines actions peuvent nécessiter une supervision ou une validation humaine.

Cela ouvre la voie à des workflows comme :

Administrateur :
"Analyse pourquoi le cluster est dégradé"

                 ↓

Agent :
"Deux hôtes doivent mettre à jour leur firmware"

                 ↓

Agent :
"Je propose d'exécuter le LCM ce soir"

                 ↓

VALIDATION HUMAINE

                 ↓

API Prism :
Lancer la mise à jour

Ce modèle est particulièrement adapté pour des opérations telles que :

• mises à jour ;
• modifications réseau ;
• migrations ;
• suppression de ressources ;
• modifications de sécurité ;
• opérations de récupération.

L’IA peut diagnostiquer et préparer le plan, mais le contrôle final reste entre les mains de l’administrateur.

Les opérations longues, en mode tâche asynchrone

L’infrastructure ne fonctionne pas toujours comme une API web classique, où chaque requête répond en quelques millisecondes.

Déplacer une VM, mettre à jour un cluster ou déployer Prism Central peut prendre plusieurs minutes.

Les API v4 de Nutanix adoptent déjà un modèle de tâches asynchrones pour de nombreuses opérations. Une requête retourne un identifiant de tâche, consultable ultérieurement pour connaître l’état d’avancement.

Par exemple, la documentation de Prism v4 utilise des réponses HTTP 202 pour indiquer une opération acceptée mais en cours, avec un lien vers la tâche correspondante.

Ce fonctionnement est idéal pour les agents :

Agent
  │
  ├── démarrer une opération
  │
  ▼
Identifiant de tâche : 12345
  │
  ├── consulter l’état
  │
  ├── attendre
  │
  ├── vérifier l’état
  │
  ▼
Terminé

L’agent n’a pas besoin de maintenir une connexion ouverte pendant toute l’opération. Il peut revenir plus tard, vérifier le statut et poursuivre le workflow.

Du langage naturel à Python, Go ou PowerShell

Le serveur MCP possède également une composante dédiée aux développeurs.

Nutanix affirme que les assistants peuvent utiliser la connaissance de leurs API pour générer du code directement dans différents langages et formats.

Parmi eux :

Python
Go
Java
JavaScript
PowerShell
curl
REST
JSON

Ce choix est logique puisque le portail développeur de Nutanix publie déjà des exemples pour plusieurs de ces langages dans la documentation v4.

Un administrateur pourrait demander :

Génère un script PowerShell pour lister les VM 
du cluster avec plus de 16 Go de RAM.

Un développeur, quant à lui, pourrait solliciter :

Crée un exemple en Go pour consulter les tâches
actives de Prism Central.

Ainsi, l’agent dispose d’une description structurée de l’API, facilitant la compréhension des endpoints sans devoir déchiffrer une documentation non structurée.

Le cas réellement intéressant : opérations hybrides

Nutanix construit depuis des années une offre centrée sur le cloud hybride.

Nutanix Cloud Platform peut s’utiliser dans des centres de données privés, des environnements Nutanix Cloud Clusters, ou des sites edge.

La documentation v4 décrit sa couche de gestion multi-domaine comme une solution pour administrer des services NCP déployés en :

sur site
     +
Nutanix Cloud Clusters
     +
edge

Dans cette configuration, un agent peut avoir beaucoup plus d’utilité que dans un cluster isolé.

Par exemple :

"Vérifie si la capacité permet de déplacer
20 VM du datacenter à NC2 sans dépasser
70 % d’utilisation."

Pour répondre à une telle question, il faut consulter :

• capacité ;
• CPU ;
• mémoire ;
• stockage ;
• inventaire des VM ;
• réseaux ;
• politiques ;
• domaines différents.

C’est précisément le type de tâche où un agent capable de chaîner les API peut considérablement réduire le travail manuel.

MCP ne transforme pas automatiquement l’infrastructure en autonome

Attention cependant à ne pas faire d’interprétation excessive de cette annonce.

Disposer d’un serveur MCP ne signifie pas qu’un agent peut gérer de façon sécurisée toute infrastructure sans supervision.

MCP offre un mécanisme pour exposer des outils, mais la sécurité ultime dépend toujours de :

identité
+ permissions
+ conception des outils
+ validation
+ limites
+ audit
+ validation humaine

Un enjeu croissant concerne aussi le prompt injection. En effet, si un agent consulte des informations externes et dispose d’outils pour modifier l’infrastructure, un contenu malicieux pourrait tenter de l’inciter à exécuter des actions non autorisées.

Les contrôles classiques de RBAC limitent la portée de chaque agent, mais ne peuvent pas totalement éliminer ce risque.

La meilleure pratique reste d’appliquer le principe du moindre privilège, en séparant clairement les agents de simple consultation de ceux autorisés à effectuer des modifications en production.

L’administration cloud pourrait entrer dans une nouvelle ère

Pendant des années, l’évolution de la gestion d’infrastructure s’est souvent déroulée comme suit :

GUI
 ↓
CLI
 ↓
API
 ↓
Infrastructure as Code
 ↓
automatisation
 ↓
agents

MCP ne remplace pas ces couches mais s’appuie sur elles.

Le fonctionnement d’un agent repose sur une API stable, sécurisée par authentification et RBAC, et capable d’automatiser des tâches.

Ce qui diffère, c’est l’interface située au-dessus.

Un administrateur n’a plus besoin de connaître chaque endpoint précis pour investiguer un problème : il peut simplement exprimer une intention et laisser l’agent déterminer quelles API ou outils consulter.

Cela peut réduire considérablement le temps consacré aux opérations routinières, mais comporte aussi le risque que l’utilisateur perde la maîtrise de ce qui se passe réellement sous le capot.

Le positionnement de Nutanix, qui consiste à introduire des agents sans échapper aux mécanismes traditionnels de gouvernance, apparaît comme une démarche pertinente.

Le vrai défi sera lorsque ces outils seront utilisés de manière courante en environnement de production.

Questions fréquentes

Que vient de lancer Nutanix ?

Nutanix a annoncé un serveur MCP open source pour Nutanix Cloud Platform permettant de connecter agents et assistants IA à la plateforme via les APIs Prism v4.

Quels assistants peuvent l’utiliser ?

Nutanix mentionne GitHub Copilot, Claude Code et Cursor, mais le serveur peut également être utilisé avec d’autres agents compatibles avec le Model Context Protocol.

Un agent peut-il modifier l’infrastructure ?

Il peut exécuter les opérations pour lesquelles il a été autorisé. L’accès est soumis aux capacités et contrôles de l’API Prism v4, ainsi qu’au RBAC configuré dans Nutanix.

Permettre à une IA d’administrer la production, est-ce sûr ?

MCP seul ne garantit pas la sécurité. Nutanix ajoute RBAC, audit, limitation des appels, et supervision humaine, mais les organisations doivent continuer à appliquer le principe du moindre privilège et des contrôles spécifiques pour les opérations sensibles.