Copilot in Azure : piloter des VM en langage naturel

Copilot in Azure : la gestion des VM passe au langage naturel

Microsoft Copilot in Azure s'intègre directement dans le portail Azure et permet d'interroger ou de piloter des ressources en formulant des demandes en langage courant. Dans une démonstration récente, les Principal Cloud Advocates Rick Claus et Sonia Cuff (Microsoft) illustrent ce fonctionnement sur un cas concret : vérifier l'état d'une machine virtuelle (VM), l'arrêter, puis la redémarrer, sans passer par le portail classique ni écrire une seule ligne de script.

L'intérêt ne se limite pas au confort. Pour une équipe d'exploitation ou un help desk de niveau 1, la promesse est de réduire le temps de résolution des incidents courants tout en gardant un contrôle strict sur ce que l'assistant est autorisé à faire.

Ce que montre la démonstration

Le scénario suit un déroulé simple, représentatif d'une intervention de support :

• interroger l'état d'une VM (« cette machine est-elle démarrée ou arrêtée ? ») ;
• demander l'arrêt de la ressource via une formulation en langage naturel ;
• demander le redémarrage une fois l'intervention terminée.

À chaque étape, Copilot in Azure traduit la demande en une requête technique exploitable, l'exécute dans le contexte du portail, puis restitue un résultat lisible. L'objectif affiché par les intervenants est de montrer que ce type d'assistant peut être confié à un help desk sans dégrader la sécurité opérationnelle.

RBAC : Copilot n'agit jamais au-delà des droits de l'utilisateur

Le point technique central de la démonstration porte sur les permissions. Copilot in Azure n'exécute une action qu'à hauteur des droits accordés à l'utilisateur qui formule la demande, via le modèle de contrôle d'accès basé sur les rôles (RBAC) déjà en place sur l'abonnement ou le groupe de ressources.

Concrètement :

• un utilisateur sans rôle Virtual Machine Contributor (ou équivalent) sur la ressource ne pourra pas obtenir de Copilot qu'il démarre ou arrête une VM ;
• l'assistant ne contourne aucune attribution de rôle Azure existante ;
• les administrateurs conservent la main sur qui peut solliciter Copilot pour des actions d'administration, en s'appuyant sur les rôles Azure standards plutôt que sur une couche de permissions dédiée.

Ce mécanisme est déterminant pour envisager une délégation vers un help desk de niveau 1 : l'assistant hérite du périmètre RBAC de la personne connectée, il n'élargit pas ses droits.

Confirmation avant action destructive et transparence des requêtes

Deux garde-fous supplémentaires ressortent de la démonstration :

• confirmation explicite avant toute action jugée destructive (arrêt ou redémarrage d'une VM, par exemple) : l'utilisateur valide l'intention avant exécution, ce qui limite le risque d'action déclenchée par une formulation ambiguë ;
• affichage de la requête sous-jacente générée par Copilot pour répondre à la demande en langage naturel. L'utilisateur voit ainsi la logique technique traduite depuis sa question, ce qui facilite l'audit et la compréhension du résultat obtenu.

Cette transparence sur la requête générée est un point clé pour les équipes qui doivent justifier une action en environnement réglementé ou tracer une intervention dans un ticket d'incident.

Activation de Copilot in Azure : désactivé par défaut en preview

Autre information technique à retenir : Copilot in Azure est désactivé par défaut dans son état actuel de preview. L'activation relève d'une décision explicite au niveau du tenant ou de l'abonnement, ce qui laisse aux administrateurs le temps de cadrer les rôles RBAC avant toute mise à disposition auprès des équipes.

Pour la mise en œuvre pratique, la logique reste la même que pour toute fonctionnalité preview Azure :

• activer la fonctionnalité au niveau approprié (tenant ou abonnement) ;
• définir précisément quels rôles RBAC seront exposés à l'assistant ;
• tester sur un environnement non critique avant tout déploiement vers un help desk de production.

La documentation officielle Microsoft Learn sur Copilot in Azure détaille les prérequis et le périmètre fonctionnel actuel de l'assistant.

Cas d'usage pour les équipes d'exploitation et le support

Les scénarios les plus pertinents pour ce type d'assistant restent les tâches répétitives et à faible risque :

• vérification rapide de l'état d'une ressource avant escalade ;
• redémarrage d'une VM suite à une demande utilisateur standard ;
• premier niveau de diagnostic sans ouverture d'un ticket vers l'équipe infrastructure.

Pour les opérations plus sensibles — modification de configuration réseau, suppression de ressources, changement de dimensionnement — les équipes gardent intérêt à conserver les workflows existants (Azure CLI, Azure PowerShell, Azure Automation) plutôt que de s'appuyer sur une interaction en langage naturel encore en preview.

Points clés à retenir

• Copilot in Azure permet de consulter et de piloter des VM (vérification, arrêt, redémarrage) en langage naturel directement depuis le portail Azure.
• L'assistant respecte le RBAC existant : il n'agit jamais au-delà des permissions de l'utilisateur qui formule la demande.
• Une confirmation explicite est requise avant toute action destructive, et la requête technique générée reste visible pour l'utilisateur.
• La fonctionnalité est désactivée par défaut et reste en preview : son activation et son périmètre RBAC doivent être planifiés avant toute mise à disposition d'un help desk.
• Les cas d'usage les plus solides aujourd'hui restent les vérifications et actions courantes sur VM, pas encore les opérations d'infrastructure critiques.

Avant toute généralisation à une équipe de support, il reste recommandé d'auditer les attributions de rôles Azure existantes et de tester l'assistant sur un abonnement non-production.