Imaginez que vous dirigez une petite entreprise du bâtiment. Dans votre boîte commune, tout arrive au même endroit : demandes clients, devis fournisseurs, questions de congés et publicité. Pendant que votre conducteur de travaux est sur un chantier, quelqu’un doit ouvrir les mails et les redistribuer. Et si vous automatisiez ce premier tri avec Copilot Studio ?
Pour cette démonstration, je me place dans cette entreprise fictive. Le but est simple : confier une tâche manuelle peu valorisante à un agent, sans demander à une personne de lancer une conversation pour chaque message. On va construire tranquillement le parcours, du mail reçu jusqu’à son transfert au bon interlocuteur, son classement et sa trace dans SharePoint.
Ce n’est pas un assistant qui négocie un devis ou décide d’un changement de cuisine. Il comprend la demande et propose son orientation. Les mails ordinaires suivent leur chemin automatiquement ; les exceptions reviennent à un humain dans Teams. C’est ce fonctionnement proactif que je veux vous montrer.
1. Le scénario : arrêter de redistribuer chaque mail à la main
Avant, une personne ouvre la boîte partagée, lit un message, cherche le chantier concerné, retrouve son responsable, transfère le mail et range l’original. Pour une question RH, elle recommence avec un autre destinataire. Rien de très compliqué, mais il faut interrompre autre chose pour le faire.
Après, l’arrivée du mail déclenche le traitement. Le système consulte les catégories et les chantiers connus, choisit un circuit, puis exécute les actions prévues. Une demande liée aux Jardins de Bellevue part vers le responsable enregistré. Une question de congés rejoint l’équipe RH. Un chantier inconnu provoque une demande de revue, pas un transfert au hasard.
Le workflow sait transférer un mail. L’agent sert à comprendre à qui il faut le transmettre, à partir de la demande et du contexte de l’entreprise.
L’agent interprète le message à partir des instructions et des informations métier qu’on lui transmet. Le workflow démarre à réception du mail, appelle cet agent et enchaîne les actions Outlook, SharePoint et Teams selon sa décision.
L’autonomie vient donc du déclenchement sur la messagerie, pas d’une personne qui tape une question dans un chat. Les instructions ne suffisent pas à envoyer des mails : nous allons aussi configurer les connexions et les branches qui réalisent le travail.
2. Préparer le terrain dans Microsoft 365
Commencez dans un espace de démonstration, avec des messages fictifs et des destinataires de test. Vous avez besoin d’un accès à Copilot Studio et de connexions autorisées à utiliser la boîte partagée, les listes SharePoint et Teams. Vérifiez aussi que votre environnement dispose des droits et de la capacité nécessaires.
À préparer
Son rôle dans la démonstration
Une boîte partagée Outlook
Recevoir les mails et permettre leur transfert, leur réponse et leur classement.
Des dossiers Outlook
Ranger les messages suivant les circuits retenus.
Deux listes de référence SharePoint
Indiquer les catégories, leurs destinataires et les responsables des chantiers.
Un journal SharePoint
Retrouver ce qui a été décidé et effectué pour chaque mail.
Un destinataire de revue dans Teams
Prendre en charge les messages nécessitant un choix humain.
Quelques catégories et un chantier connu suffisent pour démarrer. Désignez aussi une personne pour traiter les exceptions dans Teams.
3. Donner à l’agent les repères de l’entreprise
Première liste : les catégories. Pour chacune, renseignez un libellé, une description, des mots-clés et le destinataire à contacter. Vous pouvez distinguer RH, fournisseurs et commandes, livraisons, publicité et demandes à traiter. Pour RH, choisissez l’équipe ou la personne qui reçoit les questions de personnel dans votre scénario.
Les descriptions font la différence. « Livraisons » doit expliquer qu’il s’agit d’informations de transport ou de réception de matériel. « Fournisseurs / Commandes » couvre plutôt les échanges sur les achats. Si vos circuits se recouvrent, précisez où doit aller un message qui parle à la fois d’une commande et de sa livraison.
Deuxième liste : les chantiers. Renseignez le nom, les repères client, l’adresse lorsqu’elle est connue, le responsable et le statut. Ajoutez des mots-clés utiles pour retrouver le chantier dans un mail. Dans notre démo, Les Jardins de Bellevue est déjà présent ; Résidence du Parc ne l’est pas au départ.
Dans ce montage, le workflow récupère ces deux listes et les transmet à l’agent à chaque traitement. Nous ne les ajoutons pas comme une source de connaissances à parcourir séparément dans l’agent. Le référentiel reste ainsi le point de départ métier : changez un responsable dans la liste, puis vérifiez le routage au prochain test.
4. Créer l’agent et écrire ses instructions
Dans Copilot Studio, ouvrez Agents et créez un nouvel agent :
Donnez-lui un nom explicite, par exemple « Triage des mails chantier ». Si vous démarrez par une description en langage naturel, voici une base à copier :
Crée un assistant de triage des mails pour une petite entreprise du bâtiment. Il doit lire une demande entrante, utiliser les catégories et les chantiers qui lui sont fournis, proposer le bon destinataire et signaler les situations à faire revoir par une personne.
Ouvrez ensuite les instructions dans Overview, puis Instructions et Edit. Reformulez le rôle en règles simples. Voici un exemple volontairement court pour lancer vos essais :
Tu es l’assistant de triage des mails d’une petite entreprise du bâtiment. Utilise le sujet, le corps du message et les référentiels fournis. Lorsqu’un chantier connu correspond clairement à la demande, oriente le mail vers son responsable. Sinon, cherche la catégorie adaptée et son destinataire. N’invente jamais une adresse de destination. Signale une revue humaine si le choix est incertain ou si un nouveau chantier semble concerné. Pour une publicité, ne propose ni réponse ni transfert. Pour les autres demandes, propose seulement un accusé de réception neutre, sans engagement sur un prix, un délai ou une décision métier. Indique la catégorie, le destinataire, un bref résumé et la nécessité d’une revue.
Les libellés de l’interface peuvent varier suivant la langue et les évolutions de Copilot Studio.
Ce texte fixe le comportement attendu, mais ne remplace pas les réglages du workflow. Essayez quelques messages dans le test de l’agent avec leurs références, ajustez les instructions, puis publiez l’agent après vos modifications.
5. Construire le workflow qui démarre à réception d’un mail
Passons au mécanisme qui rend cette démo autonome. Dans Copilot Studio, ouvrez Workflows, puis New agent flow :
Nous allons assembler le déclencheur, les lectures SharePoint et l’appel de l’agent dans le concepteur.
Le workflow relie la réception du mail, les référentiels métier et l’appel de l’agent.
Ajoutez le déclencheur Outlook de réception d’un nouveau mail dans une boîte partagée. Choisissez votre connexion, la boîte de démonstration et le dossier Inbox :
Ajoutez une action SharePoint de récupération des éléments pour la liste des catégories :
Puis une seconde pour la liste des chantiers :
Ajoutez l’action Agent, sélectionnez votre agent et transmettez-lui le sujet, le corps du mail et les deux référentiels récupérés :
La décision de l’agent sert à choisir la suite du parcours. Configurez les conditions du workflow pour distinguer trois branches : publicité, traitement automatique et revue humaine. Une publicité est classée et journalisée, sans réponse ni transfert. Une demande dont le destinataire est identifié suit le traitement automatique. Pour un chantier connu, ce destinataire est son responsable dans le référentiel. Si le chantier est inconnu ou que l’orientation reste incertaine, le workflow demande une revue dans Teams.
Arrêtez-vous un instant ici pour tester cette première partie. Sur un mail simple, retrouvez-vous une catégorie compréhensible et un destinataire issu de vos listes ?
Corrigez les descriptions ou les instructions avant d’ajouter les envois. On construit progressivement, sans brancher immédiatement toute la boîte de l’entreprise.
6. Transférer, répondre et classer selon la décision
Ajoutez maintenant des conditions à la suite de l’appel de l’agent. Si une revue est nécessaire, le mail rejoint le circuit Teams. Si le destinataire est identifié et qu’aucune revue n’est demandée, le workflow suit la branche de traitement automatique. La catégorie publicité dispose de son propre chemin, sans réponse et sans transfert.
Dans la branche automatique, configurez les actions Outlook : envoyer l’accusé de réception lorsque votre scénario le prévoit, transférer le message au destinataire retenu, puis déplacer l’original vers le dossier choisi. Un accusé comme « Nous avons bien reçu votre demande. Elle va être orientée vers la personne concernée. » confirme la réception sans annoncer un transfert déjà effectué.
Pour les pièces jointes, l’objectif est de conserver le PDF dans le mail transféré. Nous ne demandons pas à l’agent d’analyser son contenu. Vérifiez le transfert réel dans la boîte du destinataire de test : il doit retrouver le message et pouvoir ouvrir le document.
Terminez le parcours par une écriture dans le journal SharePoint :
Gardez de quoi retrouver le mail, la catégorie retenue, la destination et les actions effectuées. Une décision proposée et un transfert réussi sont deux choses différentes : votre journal doit permettre de comprendre où le traitement en est.
Attention : prévoyez un circuit à traiter lorsque le destinataire manque ou qu’une action échoue. Dans la démo, le filtre sur « Undeliverable » permet d’écarter certains retours de non-remise. Ce filtre ciblé ne couvre pas toutes les réponses automatiques.
7. Garder la main sur les nouveaux chantiers dans Teams
Un client écrit à propos de Résidence du Parc, appartement 24. Il demande de remplacer la cuisine bois par du blanc mat. Le nom n’existe pas encore dans notre référentiel. Voilà une bonne exception : le système peut reconnaître une demande liée à un chantier, mais quelqu’un doit choisir sa destination et décider s’il faut ajouter ce chantier.
Reliez la branche de revue à une carte Teams adressée à la personne désignée. Dans la carte de la démo, elle peut choisir de répondre, de transférer, saisir l’adresse du destinataire et décider de créer le chantier avec Yes ou No, puis valider avec Submit.
Le nom proposé est Résidence du Parc, l’adresse reste vide. Les mots-clés proposés sont résidence, parc, appartement 24, rénovation et cuisine. Ne complétez pas une adresse au hasard : une information absente du mail reste à renseigner dans le référentiel.
Après validation, le workflow suit les choix de la carte. La création du chantier dépend du choix humain, elle n’est pas automatique à chaque nom nouveau. Une fois la fiche créée et son responsable renseigné, les prochaines demandes peuvent emprunter le circuit d’un chantier connu. C’est là que le référentiel devient utile au quotidien.
8. Passer les cinq mails de démonstration
Le moment de vérité. Envoyez les cinq messages à la boîte de test, puis suivez chacun jusqu’au bout :
Les parcours ci-dessous sont les attendus à vérifier, pas une promesse que toutes les exécutions réussiront au premier essai.
Publicité : « Information concernant votre abonnement ». Un message neutre sur un abonnement ne garantit pas un classement en publicité. Variante promotionnelle proposée pour ce test : « Profitez de notre offre spéciale sur votre abonnement. Découvrez nos options à prix réduit. » Attendu pour cette variante : catégorie publicité, classement et journalisation, sans réponse ni transfert. Le sujet seul ne suffit pas à reconnaître une publicité.
RH : une question sur les congés du 1er novembre. Attendu : catégorie RH et transfert au destinataire prévu dans le référentiel, sans réponse automatique sur le droit au congé.
Fournisseur : un message concernant la commande 4587 et sa livraison. Attendu : orientation vers le circuit fournisseur ou livraison défini dans vos descriptions, conservation du PDF joint et classement.
Chantier connu : une demande sur l’accès au bâtiment B des Jardins de Bellevue. Attendu : reconnaissance du chantier et transfert à son responsable, sans inventer une consigne d’accès.
Chantier absent : Résidence du Parc, appartement 24, cuisine bois à remplacer par du blanc mat. Attendu : revue Teams, choix humain du destinataire et décision sur la création du chantier, sans accepter automatiquement la modification.
Ouvrez le message reçu, retrouvez la catégorie et le destinataire choisis, puis montrez le mail transmis avec sa pièce jointe :
Revenez ensuite au dossier de classement et à la ligne du journal. Le lecteur voit une tâche réalisée, pas seulement une réponse dans un chat.
Vérifiez aussi qu’une publicité ne provoque aucun envoi :
Enfin, après avoir créé Résidence du Parc et renseigné son responsable, renvoyez une demande liée à ce chantier pour tester le nouveau trajet :
Vérifiez la réception de l’accusé de réception :
Finissez par montrer les statistiques de votre workflow :
Pensez également à regarder la consommation de crédits Copilot :
Consultez les exécutions du workflow pour repérer les erreurs techniques, puis comparez les décisions aux attendus métier. Une exécution sans erreur ne garantit pas un bon classement. Si le mail arrive au mauvais service, retravaillez d’abord la description de la catégorie ou les repères du chantier.
Sur mon lot de vingt mails du 3 octobre, j’ai relevé 248 crédits Copilot, soit 12,4 crédits par mail en moyenne pour cette démonstration. Ce relevé n’est pas un tarif fixe et ne préjuge pas de la consommation dans votre scénario.
9. Conclusion
Voilà le montage : une boîte commune, deux référentiels, un agent qui interprète les demandes et un workflow qui agit dès leur arrivée. L’humain ne redistribue plus systématiquement chaque message ; il intervient là où un choix reste nécessaire.
Retenez trois points : donnez des repères métier clairs, vérifiez les actions réellement effectuées et prévoyez une personne pour les exceptions. Commencez par vos cinq mails fictifs, montrez les PDF transférés, puis adaptez les catégories à votre activité. Foncez tester : le meilleur point de départ n’est pas un agent qui sait tout, c’est une tâche répétitive dont vous connaissez déjà le bon parcours.
🤖
Contenu assisté par IACet article a été rédigé avec l’assistance d’une intelligence artificielle et relu par l’auteur.
À la fin de mon article sur Azure Virtual Desktop Hybride, je terminais par une question ouverte : et si quelqu’un testait sur un hyperviseur que je n’avais pas couvert, du Proxmox par exemple ? Personne ne m’a répondu. Alors je l’ai fait moi-même. Le résultat tient en une phrase : ça marche, et exactement de la même façon que sur Hyper-V ou vSphere. La VM Windows 11 montée dans le premier article Proxmox sur Azure, jointe à Entra ID, devient un session host Azure Virtual Desktop à part entière. On se connecte dessus depuis la Windows App, et le bureau qui s’affiche tourne dans Proxmox.
Ce qui rend ce lab amusant, c’est l’empilement : un service AVD dans Azure, qui pilote un session host qui tourne dans Proxmox VE, lui-même hébergé dans une machine virtuelle Azure. Trois couches, et tout le monde s’en accommode.
Si vous débarquez ici sans contexte, lisez peut-être d’abord l’article Azure Virtual Desktop Hybride, qui explique ce qu’est cette préversion, ce qu’elle apporte et ses limites. Celui-ci se concentre sur un seul point : le cas Proxmox, et les deux ou trois choses qui diffèrent quand l’hyperviseur n’est pas dans la liste officielle.
Pour vous guider plus facilement dans cet article, voici des liens rapides :
La question mérite une réponse honnête, parce qu’elle a deux niveaux.
Dans son annonce, Microsoft cite nommément Hyper-V, Nutanix AHV, VMware vSphere et les serveurs Windows physiques. Proxmox n’y figure pas. Si vous cherchez une ligne de documentation qui écrit le mot Proxmox, vous ne la trouverez pas, et un support Microsoft pourra légitimement vous le rappeler.
Mais la page d’aperçu de la fonctionnalité est nettement plus large, et c’est elle qui décrit la règle réelle.
You can run Azure Virtual Desktop session hosts on your preferred on-premises hypervisor that supports Windows virtual machines.
Autrement dit, l’hyperviseur n’est pas un participant de la mécanique, il est juste le meuble sur lequel la VM est posée. Azure Arc parle à un Windows, pas à un hyperviseur. Tant que ce Windows est éligible, qu’il sort en TCP 443 et que l’agent Connected Machine s’installe, le reste suit. C’est très exactement ce que j’avais constaté entre mes trois cas Hyper-V et vSphere : la procédure est rigoureusement identique.
Attention : supporté et fonctionnel ne sont pas synonymes. Proxmox fonctionne, je l’ai vérifié de bout en bout, mais il n’est pas nommé dans la matrice Microsoft. Pour un lab, une démonstration ou un PoC, aucun problème. Pour un déploiement de production, gardez en tête que vous sortez de la liste explicitement citée, ce qui s’ajoute au fait que la fonctionnalité est déjà en préversion.
2. Le point qui mérite d’être posé clairement : Arc dans une VM imbriquée
Il y a une bizarrerie dans ce lab, et je préfère la traiter tout de suite plutôt que de laisser quelqu’un la relever en commentaire.
Azure Arc sert à gérer des machines qui ne sont pas dans Azure. Or mon nœud Proxmox est, lui, une machine virtuelle Azure. On pourrait croire qu’on essaie d’enrôler une VM Azure dans Arc, ce qui n’a pas de sens et n’est pas pris en charge :
Ce n’est pas ce qui se passe. Ce que j’enrôle, c’est la VM Windows 11 qui tourne dans Proxmox, et cette machine n’a rien d’une ressource Azure : elle n’apparaît dans aucun groupe de ressources, elle n’a pas d’identité managée, elle n’atteint pas le service de métadonnées d’instance, et son adresse est une 10.10.10.x distribuée par le dnsmasq du nœud, derrière le NAT nftables mis en place dans le premier article. Du point de vue d’Azure Arc, c’est une machine anonyme quelque part sur Internet qui sort en 443. Exactement le profil d’un serveur de datacenter.
Mon retour terrain : cette nuance n’est pas un détail de présentation, c’est ce qui fait que le lab est représentatif. Si vous refaites l’exercice sur un Proxmox posé sur une vraie machine dans votre garage ou votre salle serveur, vous obtiendrez le même résultat par le même chemin. Azure n’est ici qu’un moyen commode de disposer d’un hyperviseur.
3. Étape 0 : l’état de départ et les pré-requis
Je repars de la machine construite dans les deux articles précédents, sans rien y changer d’autre que l’identité.
Élément
Ce que j’ai
Hyperviseur
Proxmox VE 9, nœud proxmox-ve, dans une VM Azure Standard_D16s_v3
Réseau des invités
Bridge vmbr0 en 10.10.10.0/24, NAT nftables, DHCP et DNS par dnsmasq
Session host
VM Windows 11 Entreprise mono-session, 2 cœurs, 8 Gio, disque de 64 Gio
Identité
Microsoft Entra Join pur, aucun contrôleur de domaine
Licence utilisateur
Microsoft 365, éligible AVD
Abonnement
Un abonnement Azure actif, rôles Azure Connected Machine Onboarding et Desktop Virtualization Contributor
Les pré-requis côté Azure restent ceux de l’article Azure Virtual Desktop Hybride dans leurs grandes lignes, mais la documentation a évolué depuis que je l’ai écrit, et deux points ont changé. Je les signale au fil des étapes.
Azure Connected Machine Onboarding, et Desktop Virtualization Contributor
Identité du session host
Entra Join, jointure AD, ou jointure hybride pour un Windows client
Réseau
Sortie TCP 443 vers les URL requises par AVD et vers les endpoints Azure Arc
Agent Arc
Azure Connected Machine agent installé sur chaque session host
Identité managée
À assigner au host pool, avec le rôle Reader sur le groupe de ressources des machines Arc
Attention : un point d’identité que je n’avais pas détaillé dans mon article de mai et que la documentation précise désormais : un session host Windows Server ne peut pas être en Entra Join pur, à cause de la dépendance au serveur de licences Bureau à distance. Il lui faut une jointure AD ou hybride. C’est seulement sur un Windows client, comme le Windows 11 de ce lab, que l’Entra Join seul est accepté.
Attention : un rappel qui vaut pour tous les hyperviseurs et que je répète ici parce qu’il coûte cher : l’identité doit être fixée avant l’enrôlement Arc. Si vous faites l’Entra Join après avoir posé l’agent, il faut désinstaller l’agent et recommencer. Sur une VM neuve, faites l’Entra Join d’abord, Arc ensuite, extension AVD en dernier.
4. Étape 1 : vérifier l’Entra Join du session host
Ma VM Windows 11 a été jointe au tenant pendant l’OOBE, avec l’option Set up for work or school. Si la vôtre est en compte local, faites-le maintenant par Paramètres, Comptes, Accès Professionnel ou Scolaire, puis Connecter et l’option de jointure à Microsoft Entra.
La vérification se fait en une commande, dans une invite en administrateur.
dsregcmd /status
Dans la section Device State, il faut lire AzureAdJoined : YES et DomainJoined : NO. C’est la signature d’un Entra Join pur :
Vérifiez au passage dans le centre d’administration Entra que l’appareil est bien apparu dans la liste, avec son nom d’hôte :
Mon retour terrain : c’est le scénario que je préférais déjà dans mon article AVD hybride, et Proxmox ne change rien à cette préférence. Pas de contrôleur de domaine à rendre joignable depuis le réseau interne de l’hyperviseur, pas de Kerberos, pas de GPO. Avec un bridge NAT comme le nôtre, où les invités sont derrière une translation d’adresses, c’est même un vrai confort : un DC aurait demandé du routage supplémentaire. Gardez juste en tête que ce raccourci n’est ouvert qu’aux Windows client, un Windows Server exigeant une jointure AD ou hybride.
5. Étape 2 : vérifier la sortie réseau du session host
C’est le seul point où la configuration Proxmox de notre lab demande une attention particulière. Les invités sont derrière le NAT nftables du nœud, et l’agent Arc comme les composants AVD ont besoin de sortir en TCP 443.
Un test simple depuis la VM Windows, en PowerShell.
Si ces tests échouent, reprenez la configuration réseau du premier article : le routage IPv4 activé, la règle de masquerade dans la table nat, et la chaîne forward qui accepte les flux de 10.10.10.0/24 vers eth0. Côté nœud, une vérification rapide.
sudo nft list ruleset
sysctl net.ipv4.ip_forward
Attention : l’agent Arc et AVD ont besoin d’un flux sortant uniquement. Vous n’avez rien à ouvrir en entrée sur le NSG Azure, et surtout pas de RDP : la connexion utilisateur passe par le service AVD via une passerelle inversée, pas par une exposition directe du port 3389. C’est l’un des vrais bénéfices de la mécanique, et il tombe particulièrement bien dans notre montage où les invités n’ont de toute façon aucune adresse publique.
6. Étape 3 : enregistrer les resource providers
Rien de spécifique à Proxmox ici, mais c’est le préalable à tout le reste. Sur l’abonnement cible.
N’oubliez pas Microsoft.HybridConnectivity, qui porte la connectivité via Arc. Son absence laisse l’enrôlement réussir tout en faisant échouer silencieusement des opérations plus loin.
7. Étape 4 : créer le host pool et son identité managée
Ici, deux choses ont bougé depuis mon article de mai, et la seconde est un vrai piège si vous travaillez de mémoire.
Le host pool, désormais standard
Au lancement de la préversion, seul un host pool marqué comme environnement de validation acceptait un session host hybride. Ce n’est plus ce que dit la documentation, qui demande simplement de créer un host pool ordinaire sans y ajouter de machines.
Follow the Deploy Azure Virtual Desktop instructions to deploy a standard host pool without adding session hosts. Do not add virtual machines to this host pool.
Dans le portail, cherchez Azure Virtual Desktop, puis Host pools et Create.
Dans Basics, nommez le pool, choisissez la région des métadonnées et le type Pooled ou Personal.
Dans Virtual machines, choisissez No, I’ll add VMs later. La machine arrivera par Arc, pas par l’assistant.
Dans Workspace, créez ou rattachez un workspace, puis validez.
Dans Identity, assignez une identité managée. Ne sautez pas cet onglet, la suite en dépend.
L’identité managée et son rôle Reader
C’est la nouveauté qui coûte le plus cher à ignorer. L’identité managée du host pool doit disposer du rôle Reader sur le groupe de ressources qui contient vos machines Azure Arc. La documentation est explicite sur les conséquences.
If the managed identity doesn’t have Reader access to the Arc resource group, a future release will prevent session hosts from becoming available.
Ouvrez le groupe de ressources qui contient vos serveurs Arc.
Allez dans Access control (IAM), puis Add et Add role assignment.
Cherchez Reader, sélectionnez-le, puis Next.
Dans Assign access to, choisissez Managed identity, puis Select members.
Choisissez votre abonnement, le type Host pool, sélectionnez l’identité de votre host pool, et validez.
Attention : cette exigence n’existait pas au lancement de la préversion et n’apparaît donc pas dans mon article de mai. Si vous rejouez une procédure notée il y a quelques mois, c’est très précisément l’étape qui vous manquera, avec un symptôme différé et peu explicite : un session host qui ne devient jamais disponible.
8. Étape 5 : enrôler la VM Proxmox dans Azure Arc
On y est. Dans le portail, allez dans Azure Arc, Machines, Add, puis Add a single server. Renseignez l’abonnement, le groupe de ressources et la région, et téléchargez le script PowerShell d’onboarding généré :
Ouvrez PowerShell ISE puis lancez la commande suivante :
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force
Collez le script d’Azure ARC dans la VM Windows 11 et exécutez-le. Il télécharge AzureConnectedMachineAgent.msi, l’installe, puis lance azcmagent connect avec les paramètres de votre tenant :
Une fenêtre d’authentification s’ouvre pour valider :
Au bout de deux à cinq minutes, la machine apparaît dans Azure Arc, Machines, avec le statut Connected :
Ouvrez la ressource et regardez ses propriétés. C’est l’écran le plus intéressant de tout l’article :
Mon retour terrain : vérifiez la valeur d’azcmagent plutôt que de vous fier au portail seul. Sur la machine, azcmagent show vous donne l’état de l’agent, le statut de la connexion et les endpoints atteints. C’est le premier endroit où regarder si quelque chose coince, et c’est beaucoup plus parlant qu’un statut dans une liste.
azcmagent show
9. Étape 6 : poser l’extension AVD
C’est l’extension Azure Arc qui installe les composants AVD sur la machine et l’enregistre auprès du host pool. La documentation précise au passage ce qu’elle fait selon le système : sur Windows Server, elle active le rôle Hôte de session Bureau à distance, et sur Windows 11, elle active la connexion en RDP.
Attention : sur un Windows Server, l’activation du rôle entraîne un redémarrage de la machine. La documentation conseille d’installer le rôle avant de déployer l’extension pour éviter un redémarrage au milieu de la configuration. Sur notre Windows 11, la question ne se pose pas.
Bonne nouvelle par rapport à mon article de mai : il existe maintenant un chemin portail, sans génération de clé d’enregistrement à la main.
Option 1 : depuis le portail
Dans le portail, cherchez Azure Arc, dépliez Infrastructure et sélectionnez Machines.
Cliquez sur le nom de votre machine, puis dans le menu de gauche dépliez Settings et choisissez Extensions.
Cliquez sur Add, sélectionnez l’extension Azure Virtual Desktop Hybrid, puis Next.
Choisissez l’abonnement, le groupe de ressources et le host pool auquel rattacher le session host.
Validez par Review + Create puis Create.
Option 2 : en PowerShell
Le chemin script reste parfaitement valable, et c’est celui qu’on garde pour industrialiser. Installez les modules, puis connectez-vous en fixant explicitement l’abonnement :
isCloudDevice = $false est le drapeau qui indique le mode hybride. Sans lui, rien ne fonctionne.
MachineName est le nom de la ressource dans Azure Arc, pas forcément le nom d’hôte Windows brut.
Location est la région du groupe de ressources Arc, pas l’endroit où tourne physiquement la machine.
La clé d’enregistrement a une durée de vie limitée, générez-la juste avant de jouer le script.
Vérifier le résultat
Dans la vue Extensions de la machine Arc, la colonne de statut de Microsoft.AzureVirtualDesktop.CloudDeviceExtension doit afficher Succeeded.
Les différentes applications commencent à faire leur apparition dans le gestionnaire des programmes Windows :
Puis, dans le host pool, la machine apparaît dans la liste Session hosts avec le statut Available :
Mon retour terrain : ne paniquez pas si le session host n’apparaît pas immédiatement après le Succeeded de l’extension. La documentation annonce jusqu’à quinze minutes de délai entre les deux, et c’est exactement le genre d’attente pendant laquelle on relance inutilement un script qui avait très bien fonctionné.
Attention : si vous partez sur le chemin PowerShell et obtenez une erreur du type machine introuvable, vérifiez Get-AzContext. Avec plusieurs abonnements rattachés au compte, l’applet va chercher la ressource Arc au mauvais endroit et le message d’erreur n’aide pas beaucoup. C’est le piège sur lequel j’avais déjà perdu du temps lors de mes premiers tests.
10. Étape 7 : assigner les utilisateurs et se connecter
Dernière ligne droite. Ouvrez l’application group, allez dans Assignments et ajoutez l’utilisateur ou le groupe Entra qui doit pouvoir se connecter :
Puis, côté utilisateur, ouvrez la Windows App et connectez-vous avec ce compte. Le bureau publié par le host pool apparaît :
Cliquez, et le bureau s’ouvre :
Pour le plaisir de la démonstration, ouvrez côté Proxmox la console de la même VM et regardez les deux écrans côte à côte. C’est la capture que je trouve la plus parlante de tout ce lab : le même Windows, vu par son hyperviseur et vu par le service AVD :
11. Ce qui change vraiment avec Proxmox
Après ce test, la réponse honnête est : presque rien du côté d’AVD, et un peu plus du côté de l’exploitation.
Sujet
Sur Hyper-V ou vSphere
Sur Proxmox
Enrôlement Arc
Script d’onboarding standard
Identique, l’agent ignore l’hyperviseur
Extension AVD
Depuis le portail, ou CloudDeviceExtension en PowerShell
Identique
Identité
Entra Join ou jointure de domaine
Identique, Entra Join testé ici
Connexion utilisateur
Windows App
Identique
Support Microsoft
Hyperviseurs nommés dans l’annonce
Non nommé, couvert par la formulation générale de l’aperçu
Les deux dernières lignes sont les seules qui demandent un vrai effort d’adaptation, et elles découlent toutes les deux d’une limite de la préversion : AVD hybride ne pilote ni l’alimentation ni le cycle de vie des machines. Ce n’est pas propre à Proxmox, c’est documenté.
Azure Virtual Desktop Hybrid doesn’t provision or manage virtual machine state, so the following capabilities aren’t supported: Power management, Autoscale, Start VM on Connect, Session Host Configuration.
Concrètement, si vous vouliez industrialiser, c’est du côté de Proxmox que se ferait le travail : un modèle de VM Windows préparé et généralisé, un clone par session host, et un script qui enchaîne l’enrôlement Arc et la pose de l’extension. La bonne nouvelle est que l’API de Proxmox se prête bien à l’exercice, la moins bonne est qu’aucun des partenaires cités au lancement de la préversion ne couvre Proxmox aujourd’hui.
Mon retour terrain : n’oubliez pas le QEMU guest agent sur vos session hosts, dont je parle dans le second article sur les pilotes VirtIO. Sans lui, l’ordre d’arrêt envoyé depuis Proxmox n’est pas relayé proprement au Windows, et vous finissez par couper l’alimentation d’une machine qui avait des sessions utilisateurs ouvertes. Sur un hôte AVD, c’est exactement ce qu’on ne veut pas.
12. Les pièges à retenir
Le piège
Le symptôme
La parade
Entra Join après l’enrôlement Arc
Session host qui ne s’enregistre pas correctement
Fixer l’identité avant de poser l’agent Arc, sinon désinstaller et recommencer
Microsoft.HybridConnectivity oublié
Enrôlement réussi mais échecs silencieux ensuite
Enregistrer les quatre resource providers avant de commencer
Identité managée sans rôle Reader
Session host qui ne devient jamais disponible
Assigner une identité managée au host pool et lui donner Reader sur le groupe de ressources Arc
Windows Server en Entra Join pur
Non supporté, dépendance au serveur de licences RDS
Jointure AD ou hybride pour un Windows Server, Entra Join réservé au client
Impatience après le Succeeded
On relance un script qui avait marché
Attendre jusqu’à quinze minutes avant de conclure à un échec
isCloudDevice absent ou à $true
L’extension se pose mais n’enregistre rien
Passer explicitement isCloudDevice = $false
Mauvais abonnement dans le contexte
Erreur de machine introuvable
Vérifier Get-AzContext après le Set-AzContext
Sortie 443 bloquée par le NAT
L’agent Arc n’arrive pas à se connecter
Vérifier la chaîne forward nftables et le routage IPv4 sur le nœud
Windows 11 multi-session
Non éligible hors Azure
Mono-session, ou Windows Server avec le rôle RDS
Pas de guest agent sur le session host
Arrêts brutaux depuis Proxmox
Installer le QEMU guest agent sur chaque session host
Clé d’enregistrement expirée
L’extension échoue à enregistrer la machine
Générer le token juste avant de lancer le script
Conclusion
Voilà, en sept étapes, une machine Windows 11 qui tourne dans Proxmox et qui se comporte comme un session host Azure Virtual Desktop à part entière, avec sa Windows App, son identité Entra et son host pool dans le portail.
Concrètement, ça donne quoi ? Ça confirme ce que je pressentais en écrivant mon article sur AVD hybride : la mécanique ne s’intéresse pas à votre hyperviseur. Azure Arc parle à un Windows, l’extension AVD parle à Azure Arc, et ce qu’il y a en dessous est votre affaire. Microsoft a nommé quatre plateformes dans son annonce, mais la formulation de l’aperçu est délibérément plus large, et le test le vérifie.
Les trois points que je retiens : la procédure est strictement celle des autres hyperviseurs, sans le moindre ajustement ; l’Entra Join pur reste le chemin le plus court, surtout derrière un réseau NAT où un contrôleur de domaine aurait compliqué les choses ; et l’absence de gestion d’alimentation, qui est une limite de la préversion et pas de Proxmox, est ce qui demanderait le plus de travail si on voulait industrialiser.
Foncez tester, et dites-moi en commentaire si vous l’avez fait sur un hyperviseur encore différent. La dernière fois que j’ai posé la question, personne n’avait essayé Proxmox, alors j’ai fini par m’en charger.
🤖
Contenu assisté par IACet article a été rédigé avec l’assistance d’une intelligence artificielle et relu par l’auteur. Conformément à l’AI Act (UE) en vigueur depuis le 2 août 2026.
Dans le premier article, on a monté Proxmox VE 9 dans une machine virtuelle Azure et installé un Windows 11 dedans, en choisissant volontairement du matériel virtuel que Windows reconnaît tout seul : un disque SATA et une carte Intel E1000. Ça marche, c’est reposant, et c’est lent. Cette fois, on refait la même VM en VirtIO de bout en bout, pilotes chargés pendant l’installation, et on termine par le QEMU guest agent.
Si vous n’avez pas encore de nœud Proxmox sous la main, commencez par le premier article, celui-ci reprend exactement là où il s’arrête. Mais vous trouverez également une grande quantité de vidéos sur YouTube qui vous aideront à en savoir un peu plus sur Proxmox et comment le mettre en place :
Pour vous guider plus facilement dans cet article, voici des liens rapides :
1. VirtIO, pourquoi Windows ne le voit pas tout seul
Quand un hyperviseur présente un disque ou une carte réseau à un invité, il a deux façons de faire. La première est l’émulation : QEMU imite au bit près un vrai contrôleur qui a existé, un SATA AHCI ou une carte Intel E1000. L’invité croit voir du matériel qu’il connaît depuis quinze ans, il charge son pilote habituel, tout fonctionne. Le prix à payer, c’est que chaque accès disque et chaque paquet réseau doit être traduit par l’hôte, instruction par instruction.
La seconde façon est la paravirtualisation, et c’est ce qu’est VirtIO : plutôt que d’imiter un matériel existant, l’hyperviseur expose une interface conçue pour la virtualisation, avec des files de requêtes partagées entre l’invité et l’hôte. L’invité sait qu’il est virtualisé et parle directement à l’hyperviseur. Beaucoup moins de traduction, beaucoup moins de CPU consommé, nettement plus d’IOPS et de débit.
Le revers est évident : il faut que l’invité connaisse cette interface. Le noyau Linux embarque les pilotes VirtIO depuis des années, donc une VM Debian ou Ubuntu démarre en VirtIO sans que vous ayez rien à faire. Windows non. Le programme d’installation ne contient que des pilotes pour du matériel émulé classique, et c’est précisément pour ça que l’écran de sélection du disque reste désespérément vide quand on lui présente un disque VirtIO SCSI.
Les pilotes existent, ils sont développés dans le cadre du projet virtio-win, distribués sous forme d’une ISO, et signés. Toute la manipulation consiste à les rendre disponibles au bon moment.
Le rôle
Le dossier sur l’ISO
Quand on le charge
Contrôleur de disque VirtIO SCSI
vioscsi
Pendant l’installation, à l’écran de sélection du disque
Contrôleur de disque bus VirtIO simple
viostor
Même moment, si le disque est déclaré en bus virtio et non scsi
Carte réseau VirtIO
NetKVM
Pendant l’OOBE, ou après le premier démarrage
Ballon de mémoire
Balloon
Après installation, facultatif
Agent invité QEMU
guest-agent
Une fois sur le bureau
Attention : ne confondez pas vioscsi et viostor. Le bon dossier dépend de la façon dont le disque est déclaré dans Proxmox : bus SCSI avec un contrôleur VirtIO SCSI pour le premier, bus VirtIO Block pour le second. Dans cet article, le disque est en SCSI, donc ce sera vioscsi.
2. Étape 1 : récupérer et uploader l’ISO virtio-win
L’ISO se télécharge depuis le dépôt du projet Fedora, qui héberge les binaires signés. Deux versions y cohabitent, la stable et la latest. Prenez la stable.
Attention : votre VM aura le démarrage sécurisé actif, puisque Windows 11 l’exige. Un pilote dont la signature n’est pas reconnue sera refusé sans message d’erreur explicite, vous verrez simplement le pilote ne pas apparaître dans la liste. La build stable évite ce genre de surprise.
Une fois le fichier récupéré, on l’envoie sur le nœud, exactement comme l’ISO Windows dans le premier article.
Dans l’arborescence, sélectionnez le stockage local du nœud, puis ISO Images.
Cliquez sur Upload, choisissez le fichier virtio-win.iso, puis Upload.
Vous pouvez aussi passer par Download from URL si vous préférez que le nœud télécharge lui-même, ou par la ligne de commande dans le répertoire des images.
3. Étape 2 : créer la VM en VirtIO intégral
On relance Create VM. Les onglets sont les mêmes que dans le premier article, seuls trois écrans changent.
Dans General, nommez la machine, puis cliquer sur Suivant :
Dans OS, sélectionnez l’ISO Windows 11, le type Microsoft Windows et la version 11/2022/2025. Cette fois, cochez bien Add additional drive for VirtIO drivers, et surtout choisissez l’ISO virtio-win dans le champ du dessous.
Mon retour terrain : c’est très exactement l’erreur que j’ai commise à mon premier essai. Le champ propose par défaut la seule ISO présente sur le stockage, donc celle de Windows, et rien ne vous signale que le lecteur supplémentaire monte deux fois le même DVD. Vous vous retrouvez à chercher des pilotes qui n’ont jamais été là.
Dans System, rien ne change par rapport au premier article, les pré-requis Windows 11 restent les mêmes.
Machine : q35.
BIOS : OVMF (UEFI), avec Add EFI Disk sur local-1TB et Pre-Enroll keys coché.
Add TPM coché, stockage local-1TB, version v2.0.
SCSI Controller : VirtIO SCSI single.
Cochez Qemu Agent dès maintenant, ça vous évitera d’y revenir plus tard.
Dans Disks, on garde cette fois le disque en SCSI, sur le contrôleur VirtIO SCSI single. Taille 64 Gio, format qcow2, stockage local-1TB. Activez IO thread, qui donne au disque son propre thread d’entrées et sorties, ce qui n’a d’intérêt qu’avec un contrôleur de type single, précisément celui qu’on a choisi.
Les onglets CPU et Memory ne changent pas : un socket, deux cœurs, 8192 Mio.
Dans Network, on garde le modèle VirtIO (paravirtualized) proposé par défaut, sur le bridge vmbr0.
L’écran Confirm permet de tout relire avant de valider. Vérifiez ces lignes.
ide0 pointe sur virtio-win-0.1.302.iso en media=cdrom, donc les pilotes sont bien montés
tpmstate0 est en version=v2.0 et efidisk0 en pre-enrolled-keys=1
cores vaut au moins 2, exigence de Windows 11
Attention : la liste du récapitulatif est triée par ordre alphabétique et tient rarement sur un écran. Faites-la défiler jusqu’en haut pour contrôler bios et cores, ce sont les deux valeurs qu’on oublie le plus souvent de vérifier.
4. Étape 3 : vérifier l’ordre de démarrage
Avec deux lecteurs CD sur la même machine, un détail peut vous coûter un quart d’heure : si ide0, le lecteur des pilotes, passe devant ide2 dans l’ordre de démarrage, la VM tente de démarrer sur une ISO qui n’est pas bootable et vous atterrissez dans un shell UEFI sans comprendre pourquoi.
Sélectionnez la VM, puis Options.
Double-cliquez sur Boot Order.
Placez ide2 en premier, scsi0 en second, et décochez ide0.
Décocher ide0 ne le démonte pas, le lecteur reste accessible depuis Windows. Il n’est simplement plus candidat au démarrage.
5. Étape 4 : charger le pilote vioscsi pendant l’installation
Ouvrez la Console de la VM et démarrez-la. L’installation de Windows 11 commence normalement : langue, clavier, acceptation des conditions.
Puis arrive le moment qu’on attendait. L’écran de sélection de l’emplacement d’installation est vide, et Windows affiche « Install driver to show hardware ». Rien d’anormal : il ne sait pas parler à un contrôleur VirtIO SCSI.
Cliquez sur Browse.
Dans l’arborescence, descendez jusqu’au dossier vioscsi. Il est plus bas que les premiers dossiers affichés, après viorng.
Dépliez vioscsi, puis w11, puis amd64, et validez par OK.
Windows propose alors le pilote « Red Hat VirtIO SCSI controller ». Sélectionnez-le et installez-le :
Mon retour terrain : si le dossier w11 n’existe pas sous vioscsi, prenez w10 en amd64. Les deux branches partagent le même binaire sur les builds récentes, et certaines ne créent pas le dossier w11. Laissez également cochée la case Hide drivers that aren’t compatible, elle vous évite de charger un pilote pour la mauvaise architecture.
L’écran se recharge, et le disque de 64 Go apparaît.
Le reste de l’installation se déroule sans intervention.
6. Étape 5 : charger NetKVM pendant l’OOBE
Après les redémarrages, l’expérience de première ouverture de session démarre, et un second mur vous attend. Windows affiche « Let’s connect you to a network » sans proposer la moindre connexion : même histoire que pour le disque, la carte VirtIO lui est inconnue.
Bonne nouvelle, Windows 11 propose désormais un bouton pour s’en sortir sans bricolage.
Cliquez sur Install driver.
Parcourez le lecteur virtio-win, remontez la liste jusqu’à NetKVM, tout en haut.
Ouvrez NetKVM, puis w11, puis amd64, et validez par Select Folder.
Windows installe « Red Hat VirtIO Ethernet Adapter », la carte apparaît, et elle reçoit son adresse du dnsmasq configuré dans le premier article, dans la plage 10.10.10.100 à 10.10.10.200. L’OOBE enchaîne alors sur la recherche de mises à jour.
Déroulez la fin de l’OOBE normalement :
Jusqu’au moment où le bureau s’affiche :
7. Étape 6 : installer le QEMU guest agent
Dernière brique. L’agent invité n’est pas un pilote de disque ni de carte réseau : c’est un petit service qui tourne dans Windows et dialogue avec l’hôte par un canal série virtuel dédié. Il fait remonter les adresses IP dans l’interface, permet un arrêt propre demandé au système invité, et autorise le gel des écritures pendant un instantané ou une sauvegarde.
Le canal côté hôte existe déjà, puisqu’on a coché Qemu Agent à la création. Reste la moitié invitée. D’ailleurs cela se voit ici car les adresses IP ne remontent pas encore :
On voit d’ailleurs également le pont de communication n’est pas encore correctement reconnu par Windows :
Dans Windows, ouvrez l’explorateur et le lecteur virtio-win.
Entrez dans le dossier guest-agent.
Lancez le paquet en version 64 bits et déroulez l’assistant.
Attendez la fin de l’installation de l’agent :
Vérifiez ensuite dans la console des services que QEMU Guest Agent est démarré et en mode automatique.
Enfin, il faut mettre à jour le pilote au niveau du gestionnaire de périphériques :
Sur l’ISO, choisissez l’arborescence corresponde à votre OS :
Attention : si vous aviez oublié de cocher l’option à la création et que vous l’activez après coup dans Options, un redémarrage demandé depuis Windows ne suffira pas. Il faut un arrêt complet puis un démarrage depuis Proxmox, pour que QEMU recrée la machine avec son canal série. C’est la cause numéro un des agents installés qui ne remontent rien.
Profitez-en pour installer le reste des pilotes, ballon de mémoire compris, avec le programme virtio-win-guest-tools présent à la racine du lecteur. Il pose tout d’un coup.
8. Étape 7 : vérifier que tout est bien en VirtIO
Trois contrôles, deux côté Proxmox, un côté Windows.
D’abord, l’onglet Summary de la VM doit maintenant afficher les adresses IP de l’invité, ce qui prouve que l’agent répond.
Ensuite, depuis le shell du nœud, deux commandes confirment le dialogue. Remplacez 103 par votre VMID.
La première ne renvoie rien quand tout va bien, ce qui est la définition d’un bon silence. La seconde rend la configuration réseau vue de l’intérieur de Windows, au format JSON.
Vous pouvez aussi relire la configuration complète de la machine :
qm config 103
Enfin, côté Windows, le gestionnaire de périphériques doit montrer le contrôleur et la carte Red Hat VirtIO, et surtout aucun point d’exclamation jaune.
9. Les pièges à retenir
Le piège
Le symptôme
La parade
Second lecteur pointant sur l’ISO Windows
Aucun pilote disponible au moment de charger
Sélectionner explicitement virtio-win dans le champ ISO du lecteur supplémentaire
Mauvais dossier de pilote
Le pilote n’apparaît pas dans la liste
vioscsi pour un bus SCSI, viostor pour un bus VirtIO Block
Ordre de démarrage
Shell UEFI au lieu du programme d’installation
Placer ide2 devant, décocher ide0
Build latest des pilotes
Chargement refusé silencieusement avec le démarrage sécurisé
Prendre la build stable, signée
Dossier w11 absent
Rien à sélectionner dans l’arborescence
Utiliser w10 en amd64, c’est le même binaire
Pas de carte pendant l’OOBE
Impossible de terminer la configuration
Bouton Install driver, puis NetKVM, w11, amd64
Guest agent activé à chaud
Aucune adresse IP ne remonte
Arrêt complet puis démarrage depuis Proxmox, pas un redémarrage Windows
Bascule directe SATA vers SCSI
Écran bleu INACCESSIBLE_BOOT_DEVICE
Faire connaître le pilote avec un disque temporaire avant de changer le bus
Pas d’instantané avant conversion
Machine morte, rien pour revenir en arrière
Instantané systématique avant de toucher au bus du disque système
Conclusion
Voilà, en sept étapes, vous avez une machine Windows 11 entièrement paravirtualisée, disque et réseau, avec son agent invité qui dialogue avec l’hôte. La différence de confort à l’usage est immédiate : la console répond mieux, les adresses IP remontent dans l’interface, et l’arrêt depuis Proxmox devient un vrai arrêt propre.
Les trois points que je retiens : le lecteur de pilotes doit pointer sur la bonne ISO, sinon toute la suite est un mirage ; vioscsi pour le disque et NetKVM pour la carte, pas l’inverse ; et une conversion après coup se fait toujours avec un instantané et un disque temporaire, jamais en changeant le bus directement.
🤖
Contenu assisté par IACet article a été rédigé avec l’assistance d’une intelligence artificielle et relu par l’auteur. Conformément à l’AI Act (UE) en vigueur depuis le 2 août 2026.
Proxmox, vous en entendez parler partout depuis quelques mois, vous savez vaguement que c’est un hyperviseur open source qui monte, mais vous n’avez jamais mis les mains dedans ? Cet article est fait pour vous. On part d’un abonnement Azure et d’un portail vide, et on va dérouler, capture après capture, jusqu’à un bureau Windows 11 qui tourne dans Proxmox VE, lui-même hébergé dans une machine virtuelle Azure.
Je suis MVP Microsoft depuis 2024, je passe mes journées dans Azure, AVD/Windows 365 ou Copilot, mais regarder ce que fait le reste du monde m’a jamais fait de mal. Azure est d’ailleurs le lab le plus rapide à monter pour ça : pas de serveur à acheter, pas de clé USB à graver, pas de machine à démonter dans le garage. Une VM, une soirée devant vous, et vous supprimez le groupe de ressources à la fin.
Il existe déjà beaucoup de vidéos YouTube qui vous montrent Proxmox :
Ce que je voulais avoir pour tester de mon côté, c’était un premier-à-pas complet sur Azure, avec les vrais pièges du réseau imbriqué et les écrans que vous allez réellement voir. C’est ce que vous trouverez ci-dessous, avec en prime les concepts Proxmox expliqués avec des mots d’admin Azure.
Windows 11 tourne dans Proxmox VE, qui tourne lui-même dans une machine virtuelle Azure.
Pour vous guider plus facilement dans cet article, voici des liens rapides :
Proxmox VE, c’est une distribution Debian sur laquelle l’éditeur autrichien Proxmox Server Solutions a posé trois choses : KVM pour les machines virtuelles complètes, LXC pour les conteneurs système, et une interface web qui pilote le tout sur le port 8006. Pas d’agent à installer sur un poste d’administration, pas de console lourde : un navigateur suffit.
Le vocabulaire est la première marche à franchir, parce qu’il ressemble à celui que vous connaissez sans vouloir dire exactement la même chose.
Le nœud est un serveur qui exécute Proxmox VE. Dans cet article, il s’appelle proxmox-ve et il n’y en a qu’un.
Le datacenter n’est pas un bâtiment, c’est le niveau logique au-dessus des nœuds. C’est là que l’on déclare les stockages, les utilisateurs, les permissions, les sauvegardes et les règles de pare-feu communes.
Le cluster réunit plusieurs nœuds qui partagent leur configuration à travers un système de fichiers répliqué, pmxcfs, monté sur /etc/pve. Sur un nœud isolé comme ici, le service tourne quand même : c’est pour ça que pve-cluster doit être actif même sans cluster.
Le stockage se déclare au niveau du datacenter, avec un type (Directory, LVM, ZFS, NFS, Ceph, et d’autres) et une liste de contenus autorisés (ISO, disques de VM, sauvegardes, modèles de conteneurs).
Le bridge, nommé vmbr0, vmbr1 et ainsi de suite, est un commutateur Linux auquel on raccorde les cartes réseau des invités.
Enfi, si vous venez du monde Microsoft, la table de correspondance suivante vous évitera de traduire mentalement à chaque écran :
Objet Proxmox
Ce que c’est
L’équivalent que vous connaissez
Datacenter
Le niveau logique qui regroupe nœuds, stockages et utilisateurs
La console de gestion, le périmètre d’administration
Nœud
Un serveur qui exécute Proxmox VE
Un hôte Hyper-V
Cluster
Plusieurs nœuds qui partagent leur configuration
Un cluster de basculement
Stockage
Un emplacement déclaré, avec des types de contenus autorisés
Un volume partagé de cluster, un partage SMB
vmbr0
Un commutateur Linux pour les cartes des invités
Un commutateur virtuel Hyper-V
QEMU / KVM
Une machine virtuelle complète, avec son BIOS ou son UEFI
Une VM Hyper-V de génération 1 ou 2
LXC
Un conteneur système qui partage le noyau de l’hôte
Un conteneur Windows en mode process
Mon retour terrain : ne cherchez pas l’équivalent d’un groupe de ressources ou d’une souscription dans Proxmox : il n’y en a pas. La séparation se fait avec les pools de ressources et les permissions, pas avec une hiérarchie de conteneurs de facturation. Au mieux, il existe différentes vues possibles
2. Pourquoi le tester sur Azure, et ce que ça implique
Pour faire tourner Proxmox, il faut un processeur qui expose ses extensions de virtualisation. Dans une VM Azure, cela s’appelle la virtualisation imbriquée, et toutes les tailles ne la proposent pas. La série que j’ai utilisée ici, la Dsv3, la prend en charge, tout comme le stockage Premium dont on a besoin pour le disque de données.
La même page documente la taille que j’ai prise, Standard_D16s_v3, avec ses 16 processeurs virtuels et ses 64 Gio de mémoire. C’est confortable, et c’est surtout ce qui permet de donner 8 Gio et 2 cœurs à une VM Windows 11 sans que la machine hôte ne s’écroule.
Pour rappel, jusqu’ici, monter un lab Proxmox voulait dire trouver une machine physique. Là, il vous faut un abonnement, une taille de VM correcte, et une heure.
Attention : cette taille n’est pas gratuite. Le portail affichait 700,80 $ par mois sur ma capture, ce qui fait à peu près 1 $ de l’heure. Arrêtez et désallouez la VM dès que vous avez fini de jouer, et supprimez le groupe de ressources quand le lab ne sert plus. La facture d’un lab oublié est le pire souvenir que l’on puisse ramener d’un article de blog.
Trois limites à connaître avant de commencer, pour ne pas les découvrir en cours de route : le réseau des invités ne pourra pas être ponté directement sur la carte Azure, il faudra passer par du NAT, on y revient en détail plus bas ; les performances resteront celles d’un hyperviseur dans un hyperviseur, donc correctes pour un lab et pas pour de la production ; et un cluster Proxmox multi-nœuds sur Azure demanderait un travail supplémentaire, la découverte du cluster reposant sur des mécanismes réseau que le cloud n’aime pas beaucoup.
3. Étape 0 : les pré-requis
Avant de continuer les étapes de cet article, assurez-vous que vous disposez bien d’une souscription Azure active.
4. Étape 1 : créer la machine virtuelle Azure
Rien d’exotique dans cet assistant, mais quatre champs méritent votre attention.
Dans Project details, créez un groupe de ressources dédié. Le mien s’appelle proxmox-rg : tout sera dedans, donc tout partira en une seule suppression.
Dans Instance details, nommez la VM proxmox-ve, choisissez votre région, laissez Security type sur Standard et prenez l’image Debian 13 « Trixie » x64 Gen1.
Dans Size, sélectionnez Standard_D16s_v3. C’est le champ le plus important de tout l’assistant.
La taille Standard_D16s_v3 et son étiquette de prix mensuelle. C’est elle qui conditionne tout le reste.
Dans Administrator account, j’ai gardé l’authentification par mot de passe avec l’utilisateur. La clé SSH reste évidemment le bon choix si vous comptez garder la machine.
Dans Public inbound ports, choisissez Allow selected ports puis SSH (22). Le portail vous prévient que la règle sera ouverte à tout Internet : on la resserrera à l’étape suivante.
L’onglet Disks est celui qui prépare le stockage des futures VM. Le disque système de 30 Gio suffit largement pour Debian et les paquets Proxmox, mais il ne suffira pas pour les disques des invités.
Laissez le disque OS à Image default (30 GiB) en Premium SSD.
Cliquez sur Create and attach a new disk et créez un disque de 1024 Gio en Premium SSD LRS. C’est lui qui deviendra local-1TB dans Proxmox.
Le disque de données de 1 To deviendra le stockage local-1TB de Proxmox.
L’onglet Networking se contente des valeurs par défaut : un réseau virtuel neuf, un sous-réseau en 172.16.0.0/24, une adresse IP publique et un groupe de sécurité réseau en mode Basic. Retenez bien le plan d’adressage du sous-réseau, il ne devra surtout pas chevaucher le réseau interne que l’on créera dans Proxmox.
Lancez la création, prenez un café, et récupérez l’adresse IP publique dans la vue d’ensemble de la VM.
5. Étape 2 : ouvrir le port 8006 dans le NSG
L’interface web de Proxmox écoute en HTTPS sur le port 8006. Comme ce port n’existe dans aucun modèle du portail, il faut ajouter la règle à la main dans le groupe de sécurité réseau de la carte.
Ouvrez la VM, puis Networking et Network settings.
Cliquez sur Create port rule puis Inbound port rule.
Source : IP Addresses, et saisissez votre adresse IP publique. Destination : Any. Port de destination : 8006. Protocole : TCP. Action : Allow. Nommez la règle, la mienne s’appelle ProxmoxControlPlane.
Profitez-en pour resserrer la règle SSH sur la même source.
Les deux seules règles entrantes qui comptent, chacune limitée à mon adresse IP publique.
Attention : n’ouvrez jamais 8006 en source Any. Vous exposeriez à Internet une console d’administration d’hyperviseur avec un formulaire de connexion root, et les robots d’analyse de ports mettent quelques minutes à la trouver. Source restreinte, ou Azure Bastion, ou rien.
Gardez l’adresse IP publique sous la main, elle apparaît dans les propriétés de la machine.
L’adresse IP publique, à saisir dans le navigateur avec le port 8006.
6. Étape 3 : vérifier la virtualisation imbriquée et préparer Debian
Connectez-vous en SSH sur l’adresse publique, avec le compte azureuser. Première chose à faire, avant même de penser à installer quoi que ce soit : vérifier que le processeur expose bien ses extensions de virtualisation et que le périphérique KVM existe.
egrep -c '(vmx|svm)' /proc/cpuinfo
ls -l /dev/kvm
La première commande doit renvoyer un nombre supérieur à zéro, 32 dans mon cas, ce qui correspond aux cœurs logiques qui exposent vmx. La seconde doit afficher le périphérique /dev/kvm. Si l’une des deux échoue, inutile d’aller plus loin : votre taille de VM ne prend pas en charge la virtualisation imbriquée, changez-la.
Le moment de vérité. Les extensions de virtualisation sont exposées et /dev/kvm est bien là.
On regarde ensuite dans quoi on met les pieds :
cat /etc/os-release
hostnamectl
ip addr
hostnamectl confirme Virtualization: microsoft, autrement dit on tourne déjà dans un hyperviseur.
Trois informations à retenir de cet écran : la distribution est bien une Debian 13 « Trixie », hostnamectl annonce Virtualization: microsoft puisque nous sommes déjà invités d’un hyperviseur, et la carte eth0 porte l’adresse privée 172.16.0.4.
Vient ensuite la manipulation la plus discrète et la plus importante de tout l’article. Par défaut, le fichier /etc/hosts d’une image Azure ne contient pas de ligne associant le nom d’hôte à l’adresse IP privée.
cat /etc/hosts
Il faut ajouter cette ligne, avec votre adresse privée et votre nom d’hôte, avant d’installer Proxmox.
echo '172.16.0.4 proxmox-ve' | sudo tee -a /etc/hosts
La ligne qui manque presque toujours et qui fait échouer l’installation.
Attention : cette étape n’est pas cosmétique. Proxmox VE résout le nom du nœud au démarrage de pve-cluster pour construire l’arborescence de /etc/pve. Si le nom d’hôte ne se résout pas vers l’adresse privée, l’installation se passe mal et l’interface web refuse de s’afficher correctement. Adaptez l’adresse et le nom à votre machine.
7. Étape 4 : installer Proxmox VE 9
On commence par mettre la Debian à niveau. Les images Azure sont propres, mais rarement à jour au jour près.
sudo apt update
sudo apt full-upgrade -y
On ajoute ensuite la clé de signature du dépôt Proxmox pour Debian 13.
Puis le dépôt lui-même. J’utilise ici pve-no-subscription, celui qui ne demande pas de clé d’abonnement.
echo "deb [signed-by=/usr/share/keyrings/proxmox-release-trixie.gpg] http://download.proxmox.com/debian/pve trixie pve-no-subscription" | sudo tee /etc/apt/sources.list.d/pve-install-repo.list
Attention : le dépôt pve-no-subscription n’est pas destiné à la production. Il reçoit les paquets avant le dépôt entreprise et sert justement aux labs et aux tests. Pour une plateforme sérieuse, prenez un abonnement Proxmox et le dépôt qui va avec.
sudo apt update
Le dépôt Proxmox répond. On peut installer.
Place à l’installation !
sudo apt install proxmox-ve
APT annonce la couleur : 603 paquets à installer, 829 Mo à télécharger, 3,6 Go d’espace disque. On valide et on laisse travailler.
603 paquets et 3,6 Go sur le disque. Proxmox VE, ce n’est pas un petit paquet.
En cours de route, deux écrans bleus de configuration de paquet vont vous interrompre. Ils méritent chacun une réponse réfléchie.
Le premier concerne /etc/default/grub, qu’Azure a modifié pour la console série. Choisissez keep the local version currently installed :
Gardez la version locale. C’est celle qu’Azure a préparée pour votre VM.
Le second demande sur quel périphérique installer GRUB. Cochez /dev/sda, le disque système, et rien d’autre.
On coche /dev/sda uniquement, surtout pas le disque de données.
Attention : ne cochez surtout pas /dev/sdc dans cet écran. C’est votre disque de données de 1 To, il n’a rien à faire dans la chaîne de démarrage.
La fin de l’installation défile ensuite toute seule, avec la génération de la configuration GRUB et la mise en place des services Proxmox.
Le noyau pve apparaît dans la liste. Bon signe.
8. Étape 5 : vérifier que les services répondent
Avant de toucher au stockage et au réseau, on vérifie que les trois services principaux sont bien démarrés. C’est aussi une bonne occasion de comprendre qui fait quoi.
pveproxy est le serveur d’API et le frontal web, celui qui écoute sur 8006.
systemctl status pveproxy --no-pager
pve-cluster porte le système de fichiers de configuration pmxcfs, monté sur /etc/pve. Même sur un nœud isolé, s’il ne tourne pas, rien ne fonctionne.
systemctl status pve-cluster --no-pager
pvedaemon exécute les tâches demandées par l’API, du démarrage d’une VM à la création d’un disque.
systemctl status pvedaemon --no-pager
Dernière vérification, l’écoute effective du port.
sudo ss -lntp | grep 8006
Le port 8006 écoute. Reste à l’ouvrir côté Azure.
Mon retour terrain : sur ma machine, pveproxy affichait un ExecStartPost en échec, lié à la mise à jour du catalogue d’abonnement. Le service tournait très bien malgré tout : c’est une conséquence normale du dépôt sans abonnement, pas un problème d’installation.
9. Étape 6 : préparer le disque de 1 To
Le disque de données attaché à l’étape 1 est là, mais il est vierge. Première commande, et surtout ne formatez rien avant de l’avoir lue.
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS,MODEL
sdb est le disque temporaire d’Azure. Il est déjà monté sur /mnt et il ne faut rien y stocker.
Trois disques apparaissent. sda de 30 Go porte le système, sdb de 128 Go est monté sur /mnt, et sdc de 1 To est notre disque de données, encore sans partition.
Attention :sdb est le disque temporaire d’Azure. Son contenu peut disparaître à chaque désallocation ou opération de maintenance de la plateforme. Il est tentant de l’utiliser parce qu’il est déjà monté et rapide, mais n’y placez jamais un disque de machine virtuelle. Le disque à utiliser est sdc.
On vérifie une dernière fois que sdc ne contient aucune signature de système de fichiers, puis on le partitionne.
Notez l’UUID affiché ici. C’est lui qui ira dans /etc/fstab.
Reste à créer le point de montage et à le rendre permanent. Relevez l’UUID affiché par blkid et reportez-le dans /etc/fstab, l’UUID ci-dessous est le mien.
sudo mkdir -p /mnt/pve-data
sudo blkid /dev/sdc1
echo 'UUID=111c8254-c5e6-43f1-811f-497fe6a1513c /mnt/pve-data ext4 defaults 0 2' | sudo tee -a /etc/fstab
sudo mount -a
df -h /mnt/pve-data
Attention : montez toujours par UUID, jamais par /dev/sdc1. L’ordre d’énumération des disques d’une VM Azure n’est pas garanti d’un démarrage à l’autre, et un /etc/fstab qui pointe sur le mauvais périphérique donne une machine qui ne redémarre pas.
10. Étape 7 : le réseau, la partie qui change tout sur Azure
Voilà la section pour laquelle j’ai écrit cet article. Sur un Proxmox physique, la configuration réseau par défaut crée un bridge vmbr0 qui embarque la carte physique du serveur : les VM invitées se retrouvent directement sur le réseau de l’entreprise, avec une adresse du même plan que l’hôte. Sur Azure, cela ne fonctionne pas.
La raison est simple : une carte réseau Azure est associée à une configuration IP et à une adresse MAC connues de la plateforme. Une trame émise par une VM imbriquée, avec sa propre adresse MAC et sa propre adresse IP, n’est pas routée par le réseau virtuel. La documentation Microsoft sur la virtualisation imbriquée décrit d’ailleurs le même symptôme côté Hyper-V, avec le NAT comme réponse.
La réponse côté Proxmox tient en trois briques comme on pourrait faire tourner un serveur Hyper-V sur Azure : un bridge isolé sans port physique, du NAT pour la sortie, et un service DHCP et DNS interne pour que les invités reçoivent une configuration sans intervention.
On commence par regarder comment la VM est câblée aujourd’hui.
ip -br addr
cat /etc/network/interfaces
networkctl status eth0
which ifupdown2
sudo cat /etc/netplan/50-cloud-init.yaml
eth0 est piloté par netplan et reçoit son adresse en DHCP depuis Azure.
Constat : eth0 est piloté par netplan et systemd-networkd, avec une adresse obtenue en DHCP auprès d’Azure, et /etc/network/interfaces ne contient presque rien. Proxmox, lui, s’appuie sur ifupdown2 pour appliquer les changements réseau depuis l’interface web.
Attention : on ne touche pas à eth0. C’est votre seule voie d’accès à la machine : si vous la basculez sous ifupdown2 et que la configuration est mauvaise, vous perdez le SSH et il ne reste plus que la console série du portail Azure pour réparer. On laisse netplan gérer eth0 et on se contente d’ajouter vmbr0.
On déclare donc un bridge isolé, en 10.10.10.1/24, sans aucun port attaché. Ce sera la passerelle des VM invitées.
sudo tee /etc/network/interfaces > /dev/null <<'EOF'
# network interface settings; autogenerated
auto lo
iface lo inet loopback
source /etc/network/interfaces.d/*
iface eth0 inet manual
auto vmbr0
iface vmbr0 inet static
address 10.10.10.1/24
bridge-ports none
bridge-stp off
bridge-fd 0
EOF
Le paramètre qui compte ici est bridge-ports none : aucune carte physique n’est rattachée au commutateur. On active ensuite le bridge et le routage IPv4.
cat /etc/network/interfaces
sudo ifup vmbr0
ip -br addr show vmbr0
sudo sysctl -w net.ipv4.ip_forward=1
vmbr0 est là, en 10.10.10.1/24, sans aucun port physique attaché.
Pour que le routage survive au redémarrage, on l’écrit dans un fichier sysctl dédié, et on installe nftables.
sudo apt install -y nftables
sudo nft list ruleset
sudo tee /etc/sysctl.d/99-proxmox-nat.conf > /dev/null <<'EOF'
net.ipv4.ip_forward=1
EOF
sudo sysctl --system
Puis le cœur du sujet : la translation d’adresses. La table nat masque le réseau 10.10.10.0/24 derrière l’adresse de eth0, et la table filter n’autorise que ce qui doit l’être, à savoir les flux sortants des invités et les réponses associées.
sudo tee /etc/nftables.conf > /dev/null <<'EOF'
#!/usr/sbin/nft -f
flush ruleset
table ip nat {
chain postrouting {
type nat hook postrouting priority srcnat;
oifname "eth0" ip saddr 10.10.10.0/24 masquerade
}
}
table inet filter {
chain forward {
type filter hook forward priority filter; policy drop;
iifname "vmbr0" oifname "eth0" ip saddr 10.10.10.0/24 accept
iifname "eth0" oifname "vmbr0" ct state established,related accept
}
}
EOF
Le NAT est en place et la règle survivra au redémarrage.
Dernière brique, le service DHCP et DNS des invités. Sans lui, il faudrait configurer une adresse IP fixe dans chaque VM créée, ce qui est vite pénible.
dnsmasq distribue les adresses et relaie les requêtes DNS vers le résolveur Azure.
Deux détails de cette configuration valent une explication. bind-interfaces limite l’écoute à vmbr0, donc votre DHCP ne partira jamais polluer le sous-réseau Azure. Et l’adresse 168.63.129.16 déclarée comme serveur amont n’est pas une adresse au hasard : c’est l’adresse IP virtuelle de la plateforme Azure, celle qui rend entre autres le service de résolution de noms aux machines virtuelles.
L’adresse IP Azure 168.63.129.16 est une adresse IP publique virtuelle qui facilite les canaux de communication vers les ressources de la plateforme Azure.
Attention : choisissez pour vmbr0 un plan d’adressage qui ne chevauche pas celui de votre réseau virtuel Azure. Mon sous-réseau Azure est en 172.16.0.0/24 et mon réseau interne en 10.10.10.0/24 : aucune ambiguïté de routage possible.
11. Étape 8 : première connexion à l’interface web
Le moment de vérité. Ouvrez votre navigateur sur l’adresse publique de la VM, en HTTPS, port 8006.
https://VOTRE-IP-PUBLIQUE:8006
Le certificat est auto-signé, votre navigateur va râler, c’est normal. Connectez-vous avec l’utilisateur root, son mot de passe système, et le realm Linux PAM standard authentication.
Le realm Linux PAM. C’est bien le compte root du système que vous utilisez ici.
Attention : si vous n’avez jamais défini de mot de passe pour root sur cette machine, faites-le en SSH avec sudo passwd root avant d’essayer de vous connecter. Les images Azure livrent un compte root verrouillé.
Vous serez accueilli par la boîte de dialogue la plus célèbre de Proxmox. Elle vous rappelle simplement que vous utilisez le dépôt sans abonnement.
Le message d’accueil du dépôt sans abonnement. On clique sur OK et on continue.
Et voilà l’interface, avec l’arborescence Datacenter puis nœud à gauche, et le résumé du nœud au centre.
16 vCPU, 62,8 Gio de RAM et l’avertissement sur le dépôt de test, en jaune.
Mon retour terrain : regardez la ligne Kernel Version de ce résumé. Sur ma capture, la machine tournait encore sur le noyau cloud de Debian et pas sur le noyau pve, le redémarrage n’ayant pas encore eu lieu. Tout fonctionne quand même pour un lab, mais prévoyez un sudo reboot après l’installation pour démarrer sur le bon noyau.
12. Étape 9 : déclarer le stockage local-1TB
Le disque de 1 To est monté sur /mnt/pve-data, mais Proxmox ne le connaît pas encore. Un stockage se déclare au niveau du datacenter, pas du nœud, même quand il n’est physiquement présent que sur une seule machine.
Allez dans Datacenter, Storage, puis Add et choisissez Directory.
Renseignez l’ID local-1TB, le répertoire /mnt/pve-data, et le contenu Disk image.
Laissez Nodes sur All et cochez Enable, puis validez avec Add.
Vous vous retrouvez avec deux stockages. local, sur le disque système, garde les ISO, les sauvegardes et les modèles de conteneurs. local-1TB accueillera les disques des machines virtuelles.
Deux stockages : local pour les ISO, local-1TB pour les disques des machines virtuelles.
13. Étape 10 : voir vmbr0 dans l’interface et appliquer la configuration
Le bridge créé en ligne de commande apparaît maintenant dans l’interface, avec un avertissement en bas de page signalant des modifications en attente. Proxmox n’applique pas la configuration réseau à chaud sans votre accord, il vous montre d’abord le différentiel entre /etc/network/interfaces et le fichier .new qu’il a préparé.
Sélectionnez le nœud, puis System et Network.
Relisez le bloc Pending changes en bas de la vue, ligne par ligne.
Cliquez sur Apply Configuration.
Proxmox affiche le différentiel avant de l’appliquer. Relisez-le.
Après application, eth0 et le Linux Bridge vmbr0 en 10.10.10.1/24 cohabitent proprement.
Attention : c’est le seul moment de tout l’article où vous risquez de perdre l’accès à la machine. Relisez vraiment le différentiel avant de cliquer, et assurez-vous qu’aucune ligne ne touche à eth0.
14. Étape 11 : uploader l’ISO Windows 11
Pour installer un invité, il faut son image. Proxmox sait télécharger une ISO depuis une URL, mais pour Windows 11 vous passerez par l’upload depuis votre poste.
Dans l’arborescence, sélectionnez le stockage local du nœud, puis ISO Images.
Cliquez sur Upload, choisissez votre fichier, puis Upload à nouveau.
8,13 Gio qui transitent par votre navigateur puis par /var/tmp. Prévoyez le temps.
Attention : l’upload transite par /var/tmp sur le nœud, comme la boîte de dialogue le signale. Avec une ISO de 8,13 Gio et un disque système de 30 Gio, ça passe, mais de justesse si vous en montez plusieurs. Surveillez l’espace libre, ou déclarez un second stockage de type Directory autorisant le contenu ISO image sur votre disque de 1 To.
15. Étape 12 : créer la machine virtuelle Windows 11
Cliquez sur Create VM en haut à droite. L’assistant compte huit onglets, et trois d’entre eux conditionnent la réussite de l’installation.
Dans General, donnez un nom à la VM, le mien est vm-w11-test, et notez le VMID proposé, 101 dans mon cas. Ce numéro est l’identifiant que vous retrouverez partout : dans l’arborescence, dans les noms de fichiers de disques, dans les journaux.
Dans OS, sélectionnez l’ISO sur le stockage local, puis le type d’invité Microsoft Windows et la version 11/2022/2025. Proxmox propose de monter un second lecteur contenant les pilotes VirtIO, ce que je n’utiliserai pas pour ce premier article :
Celle que l’on garde pour ce lab : pas de second lecteur, pas de pilote à charger.
Dans System, on entre dans le dur. Windows 11 exige un démarrage UEFI, le démarrage sécurisé et un module de plateforme sécurisée.
Machine : q35, le jeu de puces moderne avec PCI Express.
BIOS : OVMF (UEFI), et cochez Add EFI Disk en le plaçant sur local-1TB.
Cochez Pre-Enroll keys pour que les clés Microsoft soient présentes dès le départ.
Cochez Add TPM, stockage local-1TB, version v2.0.
SCSI Controller : VirtIO SCSI single, la valeur par défaut, que l’on gardera même si notre disque sera en SATA.
UEFI et TPM 2.0. Les deux cases sans lesquelles l’installation de Windows 11 s’arrête.
Attention : sans OVMF (UEFI) et sans TPM 2.0, le programme d’installation de Windows 11 s’arrête sur le message « This PC can’t run Windows 11 ». Ces deux cases ne sont pas facultatives, et il est bien plus simple de les cocher maintenant que de les ajouter après coup.
Dans Disks, l’assistant propose par défaut un disque scsi0 sur le contrôleur VirtIO SCSI. Le piège classique : sans les pilotes VirtIO, le programme d’installation de Windows ne verra tout simplement aucun disque, et vous resterez bloqué sur un écran de sélection vide.
Je bascule donc le Bus/Device sur SATA, taille 64 Gio, format qcow2, stockage local-1TB :
Le même disque, mais en SATA. Windows le verra tout seul.
Les onglets CPU et Memory sont sans surprise. Un socket, deux cœurs, ce qui est le minimum demandé par Windows 11.
Et 8192 Mio de mémoire, largement supportables sur une VM hôte qui en a 64 Gio.
Dans Network, même logique que pour le disque. Le modèle VirtIO (paravirtualized) proposé par défaut est le plus performant, mais Windows n’en a pas le pilote.
Je choisis donc Intel E1000, sur le bridge vmbr0, en laissant le pare-feu coché. Windows embarque ce pilote depuis toujours, la carte sera donc opérationnelle dès le premier démarrage, et elle recevra son adresse de notre dnsmasq :
Intel E1000. Windows embarque le pilote, le réseau fonctionne dès le premier démarrage.
L’onglet Confirm récapitule le tout. Vérifiez la présence de bios: ovmf, machine: q35, ostype: win11, du disque sata0 et de net0 en e1000, puis validez.
Mon retour terrain : le choix SATA plus E1000 est un compromis de confort. Vous perdez en performances par rapport à VirtIO, ce qui est sans importance pour un lab, et vous gagnez une installation qui se déroule sans jamais chercher un pilote. Sur ma capture de l’onglet OS, le second lecteur censé porter les pilotes pointait d’ailleurs sur ma propre ISO Windows et pas sur une ISO virtio-win : aucun pilote n’était donc réellement disponible. Basculer un invité Windows en VirtIO après coup mérite son propre article, j’y reviendrai.
16. Étape 13 : installer Windows 11 jusqu’au bureau
Sélectionnez la VM 101 dans l’arborescence, ouvrez l’onglet Console et cliquez sur Start Now.
La console noVNC s’affiche dans votre navigateur, et le programme d’installation de Windows 11 démarre.
Et là, magie : le programme d’installation de Windows 11 démarre dans un onglet de navigateur.
Déroulez l’installation normalement. L’écran de sélection du disque est celui qui valide tous les choix de l’étape précédente. Le disque de 64 Go apparaît sans avoir eu à charger le moindre pilote. Le pari est gagné :
Le disque de 64 Go apparaît sans avoir eu à charger le moindre pilote.
Lancez l’installation de Windows 11 :
Attendez plusieurs minutes :
La VM redémarre plusieurs fois, puis enchaîne sur l’expérience de première ouverture de session.
La recherche de mises à jour est un excellent test réseau : si cet écran passe, c’est que votre chaîne bridge, NAT et DHCP fonctionne de bout en bout.
La VM sort sur Internet à travers le NAT nftables. La chaîne réseau fonctionne de bout en bout.
Nommez votre machine Windows 11 :
Définissez le type de compte Windows à créer :
Attendez la fin de configuration de Windows 11 :
Attendez encore la fin du téléchargement puis de l’installation des mises à jours OS :
Et au bout du compte, un bureau Windows 11 complet, qui tourne dans Proxmox VE, qui tourne dans une machine virtuelle Azure. La console fonctionne dans un simple onglet de navigateur, sans client RDP.
Trois niveaux de virtualisation empilés, et tout répond.
17. Étape 14 : activer le QEMU guest agent
Votre Windows tourne, mais Proxmox ne sait presque rien de lui. Dans l’onglet Summary de la VM, la ligne des adresses IP reste désespérément vide, et un clic sur Shutdown se contente d’envoyer un signal ACPI en espérant que l’invité l’écoute. Le QEMU guest agent règle ces deux points.
Concrètement, c’est un petit service qui tourne dans l’invité et qui dialogue avec l’hôte par un canal série virtuel dédié. Il ne remplace aucun pilote de disque ni de carte réseau : votre VM continue de démarrer sur son disque SATA et de communiquer par sa carte E1000. C’est justement ce qui le rend sans risque, et c’est pour ça que je le traite ici plutôt que dans un article dédié à VirtIO.
Ce qu’il apporte, une fois en place :
les adresses IP de l’invité remontent dans l’interface, ce qui évite d’ouvrir la console pour savoir quelle adresse dnsmasq a distribuée
l’arrêt et le redémarrage depuis Proxmox deviennent un arrêt propre demandé au système invité
les instantanés et les sauvegardes peuvent geler les écritures le temps de la copie, donc obtenir un état cohérent du système de fichiers
vous pouvez interroger l’invité depuis le shell du nœud, sans passer par le réseau
L’activation se fait en deux moitiés, et il faut les deux.
Côté Proxmox : ajouter le périphérique
Sur la capture de l’onglet System de l’étape 12, la case Qemu Agent était décochée, comme par défaut. On rattrape ça dans les options de la VM.
Sélectionnez la VM, puis Options.
Double-cliquez sur QEMU Guest Agent et cochez Use QEMU Guest Agent.
Validez.
Attention : cocher cette option ajoute un périphérique à la machine virtuelle. Un redémarrage demandé depuis Windows ne suffit pas, il faut un arrêt complet puis un démarrage depuis Proxmox pour que QEMU recrée la VM avec son canal série. C’est la raison numéro un des « j’ai installé l’agent et il ne remonte toujours rien ».
Côté Windows : installer le service
Le programme d’installation de l’agent est livré sur l’ISO virtio-win, la même que celle des pilotes. Uploadez-la dans le stockage local comme vous l’avez fait pour Windows :
Puis montez-la dans la VM avec Hardware, Add, CD/DVD Drive :
Dans Windows, ouvrez le gestionnaire des périphériques afin de mettre à jour le driver suivant :
Choisissez le dossier correspondant à l’OS de votre VM :
Attendez le succès de l’installation :
ouvrez le lecteur et lancez le paquet du dossier guest-agent, en version 64 bits. Il installe uniquement le service QEMU Guest Agent, visible ensuite dans la console des services, et ne touche ni au contrôleur de disque ni à la carte réseau :
Mon retour terrain : c’est le seul morceau de l’ISO virtio-win que j’installe dès le premier jour sur un invité Windows. Le reste, pilotes de disque et de carte réseau, demande une procédure plus prudente et fera l’objet d’un article à part, parce qu’un disque système basculé trop vite en VirtIO SCSI vous accueille au redémarrage avec un écran bleu INACCESSIBLE_BOOT_DEVICE.
Vérifier que ça marche
Retournez sur l’onglet Summary de la VM : les adresses IP de l’invité doivent maintenant s’afficher, avec l’adresse distribuée par votre dnsmasq dans la plage 10.10.10.100 à 10.10.10.200 :
Depuis le shell du nœud, deux commandes confirment le dialogue.
La première ne renvoie rien quand tout va bien, ce qui est la définition d’un bon silence :
La seconde vous rend la configuration réseau vue de l’intérieur de Windows, au format JSON :
Remplacez 101 par le VMID de votre machine.
18. Les pièges à retenir
Le piège
Le symptôme
La parade
Mauvaise taille de VM Azure
/dev/kvm absent, Proxmox ne démarre aucune VM
Prendre une taille qui prend en charge la virtualisation imbriquée, Dsv3 par exemple
Port 8006 fermé
L’interface web ne répond pas alors que le service écoute
Ajouter une règle entrante dans le NSG, limitée à votre adresse IP
Nom d’hôte non résolu
Installation bancale, interface web incomplète
Ajouter la ligne adresse privée et nom d’hôte dans /etc/hosts avant d’installer
Mauvais disque dans GRUB
Chaîne de démarrage incohérente
Cocher /dev/sda uniquement dans l’écran bleu grub-pc
Utilisation de sdb
Disques de VM perdus après une désallocation
Ne stocker que sur le disque de données, monté par UUID
Bridge sur la carte Azure
Les invités n’ont aucune connectivité
Bridge isolé avec bridge-ports none, plus NAT et dnsmasq
Plans d’adressage qui se chevauchent
Routage imprévisible entre invités et réseau Azure
Sous-réseau Azure et réseau interne dans deux plages distinctes
Disque en VirtIO SCSI
Aucun disque proposé par le programme d’installation Windows
Basculer le disque en SATA, ou charger les pilotes VirtIO
Pas de TPM ni d’UEFI
« This PC can’t run Windows 11 »
OVMF, disque EFI, Pre-Enroll keys et TPM 2.0 dès la création
Guest agent activé sans arrêt complet
L’agent est installé mais aucune adresse IP ne remonte
Arrêter puis démarrer la VM depuis Proxmox, pas un simple redémarrage Windows
Dépôt sans abonnement
Avertissement jaune et boîte de dialogue à chaque connexion
Parfait pour un lab, à remplacer par le dépôt entreprise en production
VM Azure laissée allumée
Une facture désagréable en fin de mois
Arrêter et désallouer, puis supprimer le groupe de ressources
Conclusion
Voilà, en quatorze étapes, vous avez un hyperviseur Proxmox VE 9 complet, avec son stockage dédié, son réseau interne routé, son interface web accessible, et une machine virtuelle Windows 11 qui tourne dedans, agent invité compris. Le tout sans acheter un seul serveur.
Concrètement, ça donne quoi ? Vous avez de quoi vous former sur Proxmox, tester des scénarios de migration, comparer honnêtement ce que fait la concurrence avec ce que vous connaissez déjà, et tout détruire d’un clic quand vous avez fini. Pour quelqu’un qui vit dans Azure toute la journée, c’est la façon la moins coûteuse de sortir de sa zone de confort.
Les trois points que je retiens de ce lab : la taille de la VM Azure décide de tout dès le premier écran, le réseau imbriqué se traite par du NAT et pas par du bridge, et le couple SATA plus E1000 fait gagner un temps fou sur l’installation d’un invité Windows.
Foncez tester, et n’oubliez pas de désallouer la VM en partant. Le prochain article sera consacré au passage en VirtIO d’un invité Windows déjà installé, disque et carte réseau : c’est le gain de performances évident de ce lab, mais c’est aussi la manipulation qui casse le plus de machines quand on la fait dans le mauvais ordre. On ira voir ensuite les instantanés et les sauvegardes.
🤖
Contenu assisté par IACet article a été rédigé avec l’assistance d’une intelligence artificielle et relu par l’auteur. Conformément à l’AI Act (UE) en vigueur depuis le 2 août 2026.
Vous avez peut-être déjà entendu parler de Display Protection, vous vous doutez que ça doit bloquer les captures d’écran sur AVD ou Windows 365, mais vous n’avez jamais mis les mains dedans ? Rassurez-vous, la préversion publique vient juste de sortir et cet article est fait pour vous. On part d’un host pool Azure Virtual Desktop tout ce qu’il y a de plus classique, où le Snipping Tool capture allègrement la session, et on va dérouler, capture après capture, jusqu’à un flux d’affichage chiffré que le poste local n’arrive tout simplement plus à copier.
Un mot tout de suite sur le statut : la fonctionnalité est passée maintenant en preview publique. Et pour vous guider plus facilement dans cet article, voici des liens rapides :
Display Protection est le volet Output Protection de la famille Input and Output Protection 😂. Le principe tient en une phrase : le flux d’affichage est chiffré avant même de quitter le Cloud PC ou la session host, et il n’est déchiffré que dans un chemin de rendu de confiance sur le poste local.
Quand le GPU de l’endpoint sait faire, et Microsoft précise que les GPU intégrés comme discrets sont supportés, le déchiffrement se fait directement dedans. Sinon, on retombe sur un rendu logiciel protégé. Dans les deux cas, un outil de capture qui tourne sur le poste local ne voit plus le contenu de la session : il n’a pas de quoi décoder ce qu’il intercepte.
« …protect display output […] against unauthorized screen capture and recording »
Trois caractéristiques structurantes à retenir de la documentation. D’abord, seuls les clients Windows App qui atteignent le niveau de protection exigé peuvent ouvrir une session protégée : c’est une exigence de confiance sur l’endpoint, pas un simple réglage cosmétique. Ensuite, le niveau de protection est configurable, avec une option d’exigence HDCP pour les écrans connectés. Enfin, la protection s’applique uniquement à la session distante affichée et ne change rien au comportement du Cloud PC lui-même.
Pour rappel, jusqu’ici, la seule réponse à la question « comment j’empêche un utilisateur de screenshoter sa session ? » était Screen Capture Protection, qui demande poliment à l’OS local de ne pas capturer. Display Protection change la nature du problème : le poste local n’a pas la clé.
2. Ne pas confondre : quatre features qui se ressemblent
C’est le point où tout le monde se mélange les pinceaux, y compris en avant-vente. Quatre fonctionnalités Microsoft parlent de protection de l’écran ou de la frappe, et elles ne font pas du tout la même chose.
Driver noyau et MSI Windows Cloud IO Protect installé sur l’endpoint
Windows 11 physique avec TPM 2.0
La nuance qui compte : Microsoft écrit noir sur blanc, à propos de Screen Capture Protection, que la fonctionnalité « doesn’t provide Digital Rights Management (DRM)-level protection ». Display Protection joue dans une autre catégorie, celle du chemin d’affichage protégé de bout en bout. Les deux ne s’excluent pas, elles se complètent dans une logique de défense en profondeur.
Attention : Input Protection et Display Protection sont deux composants distincts de Input and Output Protection, et ils se configurent indépendamment. Activer l’un n’active pas l’autre, et ils n’ont ni la même propriété RDP, ni les mêmes pré-requis côté endpoint.
3. Les trois niveaux de protection
Azure Virtual Desktop et Windows 365 exposent exactement les mêmes niveaux. C’est le cœur de la décision d’architecture, donc autant les avoir en tête avant de toucher au portail.
Niveau
Valeur RDP
Comportement
Not configured
0
Pas de protection d’affichage sur le Cloud PC ou la session host.
Hardware or software enforcement
1
La machine tente d’établir un canal d’affichage protégé matériel. Si la protection matérielle n’est pas disponible, elle bascule sur la protection logicielle.
Hardware enforcement required
2
Le canal protégé matériel est obligatoire. Si l’endpoint ne peut pas le fournir, la connexion est bloquée et l’utilisateur voit une erreur.
Dans ce pas-à-pas je reste sur le niveau 1, celui qui ne casse personne : si le GPU du poste ne suit pas, on dégrade vers le logiciel au lieu de refuser la connexion. Le niveau 2 mérite son propre article, avec un parc d’endpoints qualifié en amont, parce qu’il transforme chaque poste non conforme en ticket au support.
4. Les pré-requis
Élément
Exigence
Client
Windows App version 2.0.1236.0 ou plus récente, à mettre à jour depuis le Microsoft Store.
Poste local
Un appareil Windows 11 physique. Les machines virtuelles ne sont pas supportées comme endpoint.
Machine distante
Cloud PC Windows 365 ou session host Azure Virtual Desktop sur une version d’OS client Windows supportée, ou Windows Server.
Affichage
Un écran piloté par le GPU du poste, en sortie HDMI, DisplayPort ou USB-C DisplayPort Alt Mode. Résolution jusqu’à 4K (3840 x 2160).
Non supporté
Endpoints virtualisés, macOS, iOS, Android, navigateurs web, et appareils Windows 365 Link.
Ce tableau, lisez-le deux fois. La moitié des échecs de test viennent de là, en particulier la ligne « poste local » : si vous testez depuis une VM de démo, ça ne marchera jamais, quel que soit le nombre de fois où vous cliquerez sur Reconnect.
5. Étape 0 : la baseline de mon lab AVD
Avant de toucher quoi que ce soit, on documente l’état initial. C’est ce qui rendra la démonstration crédible auprès d’un RSSI, et ça évite de se demander plus tard si le comportement observé vient de la nouvelle configuration ou d’autre chose.
Depuis le poste Windows 11 physique, ouvrez Windows App et connectez-vous au host pool de test :
Dans la session distante, affichez quelque chose de reconnaissable : un document, une page, peu importe, tant que c’est identifiable sur une capture :
Sur le poste local, pas dans la session, déclenchez l’outil Capture d’écran de Windows et capturez la fenêtre de la session. Collez le résultat et constatez : tout est lisible. C’est la situation de départ :
Notez au passage la version exacte de Windows App et la configuration graphique du poste. Ces deux informations vous serviront si un comportement bizarre apparaît plus loin :
6. Étape 1 : la propriété RDP sur le host pool
Côté Azure Virtual Desktop, la configuration passe par une propriété RDP ajoutée sur le host pool. Pas de GPO, pas de clé de registre, pas d’extension à déployer sur les session hosts.
Dans le portail Azure, ouvrez le host pool cible.
Allez dans RDP properties, puis l’onglet Advanced.
Ajoutez la propriété suivante, puis enregistrez.
enableWindowsCloudIODisplayProtection:i:1
La valeur finale correspond au niveau choisi : 0 pour not configured, 1 pour hardware or software enforcement, 2 pour hardware enforcement required. Cette propriété active la vérification côté serveur que Display Protection est bien appliqué sur l’endpoint.
Attendez la sauvegarde du changement de la propriété avant de continuer :
Attention : activez la fonctionnalité uniquement sur les session hosts ou les Cloud PC que vous voulez inclure dans la validation de la preview. Microsoft le recommande explicitement, et sur un host pool de production partagé c’est la différence entre un test maîtrisé et une vague d’appels au helpdesk.
7. Étape 2 : préparer le poste client
La configuration est poussée vers l’endpoint à travers les propriétés de connexion RDP, puis mise en cache sur l’appareil. C’est ce cache qui explique la quasi-totalité des faux négatifs lors des tests.
Vérifiez la version de Windows App sur le poste et mettez-la à jour depuis le Microsoft Store si elle est inférieure à 2.0.1236.0 :
Dans Windows App, sélectionnez Refresh pour récupérer immédiatement la configuration à jour :
Fermez la session existante, ne vous contentez pas d’une reconnexion sur une session déjà ouverte.
Attention : sans le Refresh, un changement de configuration peut mettre jusqu’à 8 heures à atteindre un endpoint. Si vous testez juste après avoir enregistré la propriété RDP et que rien ne se passe, ce n’est probablement pas un bug, c’est le cache.
8. Étape 3 : le moment de vérité
Le moment de vérité. On ouvre une nouvelle session et on refait exactement le même geste qu’à l’étape 0.
Depuis le poste Windows 11 physique, ouvrez une nouvelle session sur le session host où Display Protection est activé :
Vérifiez que la connexion aboutit sans message d’erreur. C’est déjà une information : cela veut dire que l’endpoint satisfait le niveau demandé.
Pendant que la session est active, relancez l’outil de capture sur le poste local et capturez la fenêtre de session.
Et là, magie : le contenu capturé est bloqué ou apparaît vide. Le rectangle est là, l’image ne l’est pas :
Attention, l’accès à Azure Virtual Desktop via le portail Web ne supporte pas cette fonctionalité :
Mon retour terrain : Display Protection ne referme pas toutes les portes. Une copie d’écran réalisée dans la machine virtuelle protégée, combinée à l’autorisation du presse-papier entre les deux postes, vous permettra d’extraire l’information vers la machine hôte. Microsoft le dit d’ailleurs pour Screen Capture Protection : « you should also disable clipboard, drive, and printer redirection », précisément parce que désactiver la redirection empêche les utilisateurs de copier du contenu depuis la session distante. La même logique s’applique ici.
9. L’impact réel sur l’environnement
Une fonctionnalité de sécurité qui ne coûte rien, ça n’existe pas. Voilà ce qui change et ce qui ne change pas.
Ce qui ne change pas : le comportement de la machine distante. La protection porte sur la session affichée, pas sur le Cloud PC ou la session host. Les applications, les stratégies et les outils qui tournent à l’intérieur ne voient pas la différence.
Ce qui change, en revanche, mérite une checklist avant tout déploiement large :
Performance : quand la protection matérielle n’est pas disponible, la session bascule en protection logicielle, ce qui peut allonger le temps d’établissement de la session. Pour la meilleure expérience, il faut des endpoints avec un GPU compatible.
Résolution : le plafond est 4K (3840 x 2160). Au-delà, la session protégée n’est pas supportée. Les postes à triple écran haute définition sont à qualifier sérieusement.
Docks et adaptateurs : les écrans branchés via DisplayLink ou un adaptateur graphique USB ne sont pas supportés, parce qu’ils ne fournissent pas le chemin d’affichage protégé et n’ont généralement pas de support HDCP. La session protégée peut être bloquée (erreur 0x110) ou le contenu protégé peut ne pas s’afficher.
Câblage : le VGA n’a pas de HDCP, les vieilles stations d’accueil et les moniteurs non HDCP non plus. Il faut viser une sortie HDMI, DisplayPort ou USB-C DisplayPort Alt Mode pilotée par le GPU du poste.
Parc client : macOS, iOS, Android, les navigateurs web et les appareils Windows 365 Link sont hors périmètre. Si une population utilise ces clients, elle ne pourra pas ouvrir de session protégée.
Redirections : le presse-papier reste un chemin d’exfiltration, comme démontré à l’étape 3. Si le sujet est vraiment la confidentialité, la désactivation des redirections fait partie du même chantier.
Le piège classique dans un parc d’entreprise : la flotte de portables est branchée sur des docks universels USB en open space. C’est exactement la population qui va tomber sur l’erreur HDCP, et ce n’est pas une question de licence ou de stratégie, c’est du câble.
10. Bonus Windows 365 : le même réglage dans Intune
Sur Windows 365, on ne passe pas par une propriété RDP saisie à la main mais par le centre d’administration Intune.
Commencez par créer un groupe de machines Windows 365 :
Connectez-vous au centre d’administration Microsoft Intune, allez dans Devices, puis Manage Windows 365 Cloud PCs, Cloud PC Settings, puis Remote Connection Experience :
Sous IO Protection, sélectionnez le niveau voulu pour Display Protection :
Les niveaux sont strictement les mêmes que sur AVD, et le mécanisme de propagation aussi : la configuration part vers l’endpoint dans les propriétés de connexion, elle est mise en cache, et le Refresh de Windows App reste le raccourci pour ne pas attendre :
Ouvrez une session Windows 365 sur votre utilisateur de test :
Tout comme AVD, le mécanisme fonctionne très bien depuis un client compatible :
Et comme sur AVD toujours, rien ne passe depuis le navigateur internet :
11. Les codes d’erreur et comment les lire
Quand la protection ne peut pas être établie, la connexion peut être bloquée et un message apparaît sur le poste. Voici la grille de lecture.
Code
Code étendu
Signification
Causes fréquentes
0x204
0x11f5
Client incompatible
Connexion depuis iOS, macOS ou Android. Windows App antérieur à 2.0.1236. Configuration récemment activée ou modifiée et pas encore reçue par l’endpoint.
0x204
0x11f6
Stratégie non respectée
L’endpoint retombe sur la protection logicielle, absence de support GPU ou mauvaise configuration GPU, alors que la machine distante exige l’enforcement matériel.
0x110
aucun
Exigences HDCP non satisfaites
Vieilles stations d’accueil, adaptateurs USB et docks DisplayLink sans HDCP, câbles VGA, moniteurs non HDCP.
Le réflexe sur un 0x204 avec le code étendu 0x11f5 juste après avoir activé la fonctionnalité : sélectionner Refresh dans Windows App pour tirer la dernière configuration, ou attendre la propagation (jusqu’à 8 heures), puis retenter :
Voici l’erreur rencontrée lors d’une tentative de connexion depuis un poste compatible, mais dont l’ouverture de session est faite depuis Edge, non compatible à ce jour :
À noter que j’ai également rencontré cette erreur lors de la connexion à une session AVD depuis un poste Windows 365 qui ne le supportait pas. On aurait aimé un message d’erreur plus clair :
Si le code ne correspond à aucun de ceux listés par Microsoft, la marche à suivre est de contacter le support avec l’activity ID, l’horodatage de l’échec et les étapes de reproduction.
Tester sur un poste, c’est bien. Savoir ce qui se passe sur l’ensemble du tenant, c’est mieux, surtout si vous préparez un déploiement progressif.
Et autant vous le dire tout de suite, parce que c’est la première question qu’on se pose : il n’y a rien à vérifier dans l’OS. Ni sur le session host, ni sur le poste local. Pas de clé de registre d’état, pas de journal d’événements, pas de cmdlet. La négociation se fait à l’établissement de la connexion entre Windows App et la machine distante, et c’est le service qui en garde la trace. Le seul point de contrôle documenté est côté tenant.
Dans le centre d’administration Microsoft Intune, allez dans Reports, puis Cloud PC monitoring (preview).
Ouvrez l’onglet Connection health.
Utilisez le sélecteur de plage de temps et les filtres pour cibler les connexions à investiguer.
Sélectionnez View data pour déplier le volet, puis ouvrez la table Events.
Ajoutez la colonne du nom d’événement si elle n’est pas affichée, ou cherchez l’événement par son nom.
Deux événements existent, un par composant : KeyboardInputProtectionState pour l’input protection et DisplayProtectionState pour le display protection. Ils servent à confirmer si la protection a été négociée pour une connexion donnée, et à investiguer celles où elle ne s’est pas appliquée.
Conclusion
Voilà, en quatre étapes, de l’étape 0 à l’étape 3, vous êtes passé d’une session AVD que n’importe quel outil de capture pouvait aspirer à une session dont le flux d’affichage est chiffré jusqu’au GPU du poste.
Concrètement, ça donne quoi ? Une ligne de propriété RDP, une mise à jour de Windows App, et un argument de sécurité qui se démontre en deux captures d’écran devant un RSSI. Pas de nouvelle infrastructure, pas d’agent à déployer sur les session hosts.
Les cinq pièges à retenir :
Le poste doit être un Windows 11 physique avec Windows App 2.0.1236.0 ou plus récent.
La configuration est mise en cache sur l’endpoint et peut mettre jusqu’à 8 heures à se propager. Le bouton Refresh est votre ami.
Les docks DisplayLink, les adaptateurs graphiques USB, le VGA et les moniteurs non HDCP sont des générateurs d’erreur 0x110.
Sans GPU compatible, on bascule en protection logicielle, avec un temps d’établissement de session potentiellement plus long, et un plafond à 4K dans tous les cas.
Le presse-papier reste ouvert. Sans désactivation des redirections, l’information sort de la session protégée par un simple copier-coller.
Foncez tester en lab, et prenez le temps de qualifier votre parc d’écrans et de docks avant de rêver au niveau 2. C’est cette qualification, plus que la configuration elle-même, qui décidera du succès du déploiement.
Contenu assisté par IACet article a été rédigé avec l’assistance d’une intelligence artificielle et relu par l’auteur. Conformément à l’AI Act (UE) en vigueur depuis le 2 août 2026.
Vous avez un Cloud PC qui refuse de provisionner, un Win32 qui ne descend jamais, une session qui rame sans raison apparente, et vous passez trois jours à interroger Intune alors que le coupable est une règle de pare-feu écrite il y a deux ans ? Cet article est fait pour vous. On part d’une VM Windows toute neuve et on va dérouler, capture après capture, un diagnostic réseau complet de vos endpoints Microsoft Intune, Windows 365 et Azure Virtual Desktop, puis on va casser le réseau exprès pour vérifier que l’outil dit bien la vérité.
Il ne s’agit pas d’un produit commercial ni d’un module à installer : c’est un script PowerShell unique, sans dépendance, qui teste en un seul run l’ensemble des prérequis réseau que Microsoft publie sur quatre pages de documentation différentes.
Pour vous guider plus facilement dans cet article, voici des liens rapides :
1. Le vrai problème : des prérequis réseau éparpillés
Le problème, ce n’est pas la difficulté technique, c’est le périmètre. La documentation Windows 365 le dit noir sur blanc : les prérequis se répartissent sur quatre familles distinctes, l’appareil physique, le service Microsoft Intune, la machine virtuelle session host Azure Virtual Desktop et le service Windows 365.
Although most of the configuration is for the Cloud PC network, end user connectivity occurs from a physical device. Therefore, you must also follow the connectivity guidelines on the physical device network.
Puis extraire à la main les FQDN, les recopier dans un tableur, et lancer une boucle de Test-NetConnection maison en espérant n’avoir rien oublié…
Concrètement, ça donne quoi ? Ça donne un Cloud PC parfaitement provisionné dont l’utilisateur n’arrive pas à se connecter, parce que le poste physique dans l’agence de Lyon sort par un proxy qui ne connaît pas les endpoints du client Windows App. Vous avez validé le réseau Azure, vous n’avez pas validé le réseau du poste. Deux périmètres, deux jeux de règles, deux équipes différentes.
Mon retour terrain : le ticket qui revient le plus souvent n’est pas « rien ne marche », c’est « ça marche pour 90 % des gens ». Et un taux de 90 %, en réseau, c’est presque toujours la signature d’un site, d’un breakout Internet ou d’un profil de proxy qui diverge du reste du parc.
2. D’où vient l’outil et ce qu’il couvre
Le script a une histoire. Il démarre comme un vérificateur réseau Windows 365, publié en février 2026 sous le nom The Ultimate Windows 365 Network Validation Script. Daniel Bowker l’a ensuite élargi bien au-delà de son périmètre initial, et la version 4 marque le vrai basculement : Microsoft Intune obtient sa propre validation dédiée, à côté de Windows 365 et d’Azure Virtual Desktop.
Résultat, la version 4.1 s’appelle désormais Test-CloudEndpointNetworkHealth.ps1. L’ancien nom Test-W365NetworkHealth.ps1 reste disponible comme lanceur de compatibilité, pour ne pas casser les scripts et les runbooks écrits avant le renommage.
Élément
Valeur
Nom du script
Test-CloudEndpointNetworkHealth.ps1
Version couverte ici
v4.1
Auteur
Daniel Bowker, Microsoft MVP Windows 365
Licence
MIT
Dépendances
Aucune, PowerShell seul
Jeu d’endpoints
445 entrées, cloud Microsoft commercial
Périmètre
Microsoft Intune, Windows 365, Azure Virtual Desktop
Fichier de données
Endpoints.csv, téléchargé automatiquement
Le point qui m’a le plus intéressé n’est pas le nombre d’endpoints, c’est la nature des tests. Un script de validation réseau naïf fait un Test-NetConnection sur le port 443 et affiche un joli vert. Celui-ci va nettement plus loin :
vrai handshake TLS avec SNI, pas un simple socket ouvert sur 443
détection de l’inspection SSL probable via l’analyse de la chaîne de certificats
échecs DNS remontés séparément des échecs de port
endpoints wildcard réellement testés quand c’est possible
test UDP réel pour RDP Shortpath
test SNTP/NTP, avec mesure de la dérive d’horloge
vérification d’Azure IMDS et de WireServer
test de connectivité IPv6
mesure de la latence de connexion
détection d’interception par ZTNA ou Secure Web Gateway
validation du port 80 là où Microsoft exige 80 et 443
tests parallélisés et déduplication des couples hôte/port
Cette liste compte douze améliorations, et chacune correspond à un faux positif que vous avez probablement déjà rencontré en production sans le savoir.
3. Workload et Mode : la distinction que tout le monde rate
Au lancement, le script pose deux questions. Elles se ressemblent, elles n’ont rien à voir. C’est le point de design le plus important de l’outil et c’est aussi celui qui provoque le plus de mauvaises interprétations.
La première question, c’est le workload, autrement dit ce que vous validez :
[1] All Cloud Endpoint requirements
[2] Microsoft Intune
[3] Windows 365
[4] Azure Virtual Desktop
Workload égale QUOI, Mode égale OÙ. Retenez ces deux mots et vous ne vous tromperez plus. Un même workload Intune se teste indifféremment depuis un Cloud PC ou depuis un poste physique managé, parce que les prérequis Intune sont des prérequis d’appareil, pas des prérequis de datacenter.
Workload
Ce qui est validé
All
Tout ce qui suit. C’est la valeur par défaut.
Intune
Les prérequis réseau Microsoft Intune publiés pour les appareils Windows
Windows365
Les endpoints du service Windows 365, plus les dépendances AVD, Intune et plateforme Azure sur lesquelles il repose
AVD
Les prérequis Azure Virtual Desktop côté session host et côté client
Le choix de conception à saluer se trouve dans la ligne Windows365. Sélectionner ce workload ne teste pas seulement les FQDN du service Windows 365. Un Cloud PC est un poste managé par Windows 365 qui s’appuie sur Intune, sur les composants de connectivité Azure Virtual Desktop et sur des services de plateforme Azure. Ne tester que les endpoints *.infra.windows365.microsoft.com vous donnerait un résultat entièrement vert alors qu’une vraie dépendance reste bloquée.
Symétriquement, le workload Windows365 exclut volontairement les fonctionnalités Intune optionnelles dont un Cloud PC n’a pas besoin pour être provisionné, managé ou joignable, comme Remote Help et le Microsoft Store. Vous ne verrez donc pas de rouge sur des services que vous n’utilisez pas.
La seconde question, c’est le mode, autrement dit d’où vous testez :
[1] Host / Cloud Network
(Cloud PC, AVD session host, or Azure VNet VM)
[2] Physical Client Device
(Intune-managed Windows device, or device connecting to a
Cloud PC or AVD session host using Windows App)
[3] Both
Attention : Remote Help et Microsoft Store restent dans leurs propres catégories quand vous lancez le workload Intune. Un rouge sur ces lignes ne signifie pas que votre environnement est cassé, juste que vous n’ouvrez pas ces flux. Lisez la catégorie avant de paniquer.
4. Étape 0 : les prérequis avant de lancer quoi que ce soit
Avant la moindre commande, trois règles.
Règle 1, lisez le script avant de l’exécuter. L’auteur documente lui-même la procédure, et c’est tout à son honneur. Un irm | iex exécute du code distant sans que vous ne l’ayez vu, et cette pratique n’a rien à faire dans un environnement de production sans revue préalable :
Règle 2, exécutez en session élevée. Certaines vérifications de la fabric Azure se comportent différemment hors élévation et peuvent apparaître injoignables alors que tout va bien. Administrateur local suffit, pas besoin d’aller plus loin.
Règle 3, PowerShell 7 de préférence. Windows PowerShell 5.1 fonctionne, mais 7 est la cible recommandée par l’auteur. Pour lancer le script, rien de plus simple et aucune dépendance à installer :
irm https://bowker.cloud/endpointcheck | iex
Ce dernier point mérite d’être souligné : le script ne demande aucun rôle Entra ID, aucun consentement d’application, aucune permission Graph. Il ne lit pas votre tenant. Il teste des sockets. C’est ce qui le rend utilisable par une équipe réseau qui n’a aucun droit dans Intune, et c’est précisément le genre de cloisonnement qu’on rencontre dans les grandes structures.
Voici les paramètres disponibles, tels que documentés dans le dépôt :
Désactive le filtrage optionnel des plages IP Intune. Alias : -NoRegionFilter
Off
-SkipRegionPicker
Ancien nom de paramètre, conservé pour compatibilité
Off
-MaxParallel
Nombre de sondes concurrentes
12
Attention : ne montez pas -MaxParallel à l’aveugle. Douze sondes concurrentes, c’est déjà un profil de trafic qui ressemble beaucoup à du scan sortant. Sur un site protégé par un IPS ou une solution ZTNA agressive, vous risquez de déclencher une alerte SOC ou de vous faire jeter au bout de trente secondes, et vos résultats seront faussés. Prévenez l’équipe sécurité avant le run.
5. Étape 1 : le premier run et la baseline tout verte
Toute la démarche de cet article repose sur une idée simple : un diagnostic ne vaut rien sans point de comparaison. On commence donc par un run de référence sur une machine dont on sait que le réseau est sain, et on garde le résultat sous le coude.
Et pour la baseline de cet article, la version explicite avec export CSV, celle que je vous recommande parce qu’elle vous laisse une trace exploitable à lancer depuis une fenêtre PowerShell :
& ([scriptblock]::Create((irm https://bowker.cloud/endpointcheck))) -Workload All -Mode 2 -OutputPath .\baseline-saine.csv
Mon retour terrain : exportez systématiquement en CSV avec -OutputPath, même quand tout est vert. Le jour où un utilisateur remonte un problème, la comparaison entre le CSV du jour et celui de la mise en service vaut mille suppositions. C’est la même logique qu’un baseline de performance, appliquée au réseau.
6. Lire les résultats : OK, FAIL, DNS!, TLS!, INSP, ZONE, INFO
C’est ici que l’outil se distingue vraiment des scripts maison. La plupart des validations réseau que j’ai vues chez des clients renvoient deux états : ça passe ou ça ne passe pas. Or un problème DNS, un blocage de pare-feu et une inspection SSL cassent tous les trois le service, mais appellent trois correctifs radicalement différents, portés par trois équipes différentes.
Statut
Signification
[ OK ]
Connecté. Sur le port 443, cela signifie un handshake TLS complet avec SNI là où c’est supporté
[FAIL]
Le DNS a résolu, mais la connexion a échoué
[DNS!]
Le nom d’hôte n’a pas résolu
[TLS!]
Le TCP est établi, mais le handshake TLS a échoué
[INSP]
Le TLS aboutit, mais la chaîne de certificats suggère une inspection SSL probable
[ZONE]
Le wildcard n’a pas de nom d’hôte public stable, la zone DNS parente a été validée à la place
[INFO]
Plage IP publiée, vérification propre à Azure, entrée de référence ou autre résultat informatif
Cette granularité change la nature de la conversation. Avec un simple rouge, vous ouvrez un ticket réseau et vous attendez. Avec un [DNS!], vous savez que le pare-feu n’est pas en cause et vous allez voir l’équipe qui gère la résolution de noms. Avec un [INSP], vous savez qu’il faut demander une exclusion d’inspection, pas une ouverture de flux : le flux est déjà ouvert.
Sur ce dernier point, Microsoft est parfaitement explicite dans la documentation Windows 365 :
These traffic interception technologies can cause issues with running Azure network connection checks or Cloud PC provisioning. Make sure no network interception is enforced for Cloud PCs provisioned within the Windows 365 service.
Autrement dit, un environnement où l’inspection SSL est appliquée aux Cloud PC est un environnement hors des rails documentés, et le statut [INSP] est le seul moyen simple que je connaisse de le prouver en une capture d’écran devant l’équipe sécurité.
Deux subtilités à connaître, et elles évitent des faux diagnostics :
Certains endpoints CDN de Windows Update et Delivery Optimization sont volontairement exclus de la validation TLS, parce que les certificats renvoyés par le CDN ne couvrent pas de façon fiable le nom d’hôte Microsoft. Ces entrées sont testées en TCP seul, pour éviter de générer un faux [TLS!].
Les wildcards ne sont plus systématiquement ignorés. Quand il n’existe pas de nom d’hôte public stable derrière, c’est la zone DNS parente qui est validée, d’où le statut [ZONE]. Ce n’est ni un succès complet ni un échec, c’est une validation partielle assumée.
7. Le lab de pannes : on casse le réseau exprès
Le moment de vérité. Un outil de diagnostic qui affiche du vert quand tout va bien, ce n’est pas un exploit. Ce qu’on veut savoir, c’est s’il dit la vérité quand ça va mal, et surtout s’il désigne la bonne cause. J’ai donc monté une VM Windows jetable et j’ai cassé le réseau, panne par panne, avec un run du script après chaque manipulation.
Attention : toutes les manipulations qui suivent se font sur une machine virtuelle jetable, hors production, et de préférence non managée par Intune. Bloquer un port sortant ou casser la résolution DNS sur un poste de production vous fera perdre bien plus de temps que le diagnostic que vous cherchiez à poser.
Voici le rendu du script avant toute modification de la configuration :
Cas n°1 : la résolution DNS est cassée
Le scénario réel derrière ce cas : un serveur DNS interne injoignable, un forwarder mal configuré, ou un split-brain DNS où la zone publique Microsoft n’est plus résolue depuis le réseau interne. C’est fréquent, et c’est très mal diagnostiqué, parce que l’utilisateur décrit un symptôme applicatif alors que le problème est au niveau de la résolution.
La manipulation, dans une console élevée sur la VM de test. On note d’abord la configuration DNS actuelle pour pouvoir la remettre :
Get-DnsClientServerAddress -AddressFamily IPv4
# On pointe la carte vers un resolveur qui n'existe pas
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 127.0.0.1
Clear-DnsClientCache
Puis on relance le script. Le résultat attendu est une avalanche de [DNS!], et surtout aucun [FAIL] : le script doit dire que rien n’a résolu, pas que les ports sont bloqués.
Et là, magie : là où un script maison basé sur Test-NetConnection vous aurait affiché un mur de rouge indifférencié, envoyant l’équipe réseau chercher une règle de pare-feu inexistante pendant deux jours, vous avez immédiatement la bonne piste.
Pour restaurer, remettez l’adresse notée à l’étape précédente, ou repassez en DHCP :
Cas n°2 : DNS partiellement cassé, une seule zone tombe
Le cas précédent est brutal et facile à diagnostiquer même sans outil. Le cas vicieux, celui qui coûte vraiment des journées, c’est la panne partielle : tout résout, sauf une famille de noms. Un enregistrement de blocage laissé dans le DNS interne, une entrée hosts oubliée par un collègue en test, une politique de filtrage DNS qui sinkhole une zone.
On simule ça proprement avec le fichier hosts, en pointant un endpoint Windows 365 vers une adresse inexploitable :
notepad C:\Windows\System32\drivers\etc\hosts
Ajouter la ligne suivante, puis enregistrer
192.0.2.1 rdbroker.wvd.microsoft.com
Lancer la commande suivante pour purger le cache :
Clear-DnsClientCache
Ici le nom résout, mais vers une adresse qui ne mène nulle part. Le comportement attendu n’est donc pas le même que dans le cas n°1, et c’est tout l’intérêt de la démonstration. La ligne concernée doit basculer en [FAIL], pas en [DNS!], pendant que le reste du run reste vert :
Le piège classique : sur ce genre de panne, l’utilisateur vous dira que « AVD ne marche pas », alors que le provisioning, l’authentification et Intune fonctionnent parfaitement. Seul le broker de connexion est injoignable. Sans un test endpoint par endpoint, vous cherchez au mauvais endroit.
Pensez à retirer la ligne du fichier hosts et à vider le cache DNS avant de continuer, sinon elle va polluer tous vos runs suivants.
Cas n°3 : le port 5671 bloqué, le grand classique du provisioning
Si vous ne deviez retenir qu’un seul cas de cet article, c’est celui-là. La documentation Windows 365 exige que les endpoints d’enregistrement IoT Hub soient joignables sur deux ports, 443 et 5671, en sortie :
Or, dans la vraie vie, une équipe réseau qui reçoit une demande d’ouverture pour Windows 365 ouvre le 443 et considère le travail terminé. Le 5671, c’est de l’AMQP, ça ne ressemble pas à du web, et ça passe très souvent à la trappe. Résultat : le Cloud PC ne s’enregistre jamais auprès du service de santé, le provisioning échoue ou reste bloqué, et tous les tests web que vous ferez à la main répondront correctement.
On reproduit la panne avec une règle de pare-feu sortante :
Voilà la démonstration que je cherchais. Le script teste le couple hôte et port, pas seulement l’hôte. Vous voyez le même FQDN en vert sur une ligne et en rouge sur l’autre, et la conversation avec l’équipe réseau devient triviale : le flux existe, il manque un port.
Mon retour terrain : le 5671 est le port oublié numéro un des déploiements Windows 365 avec Azure Network Connection. Juste derrière, le port 80 sur les endpoints où Microsoft exige à la fois 80 et 443, typiquement pour les listes de révocation de certificats. Le script valide ce cas explicitement, et c’est une bonne raison de ne pas se contenter d’un test sur 443.
Cas n°4 : l’UDP coupé, la session qui rame sans jamais tomber
Celui-ci est le plus sournois de tous, parce qu’il ne produit aucune erreur. Rien ne tombe. L’utilisateur se connecte, travaille, et vous dit simplement que « c’est mou ». Vous regardez les logs, tout est vert, et vous concluez à un problème de perception.
Ce qui se passe réellement, la documentation Azure Virtual Desktop l’explique très bien. RDP démarre sur un transport TCP en reverse connect, puis tente d’établir la session en UDP. Si l’UDP réussit, le TCP est abandonné. Sinon, le TCP sert de solution de repli :
By default, the Remote Desktop Protocol (RDP) begins a TCP-based reverse connect transport, then tries to establish a remote session using UDP. If the UDP connection succeeds the TCP connection drops, otherwise the TCP connection is used as a fallback connection mechanism.
Ce mécanisme de repli est une excellente idée pour la disponibilité, et une catastrophe pour le diagnostic : il transforme une panne franche en dégradation silencieuse. C’est exactement la raison pour laquelle le test UDP réel de RDP Shortpath est, à mon sens, la fonctionnalité la plus sous-estimée de ce script.
Pour reproduire, on bloque l’UDP sortant sur la VM de test. Lancez d’abord un run normal et relevez dans la sortie le port UDP effectivement testé par le script pour Shortpath, puis créez la règle correspondante :
Regardez bien cette capture. C’est le seul rouge de tout le run. Sans ce test, votre validation réseau aurait été déclarée conforme à 100 %, et vous auriez cherché la cause du côté du dimensionnement du Cloud PC ou de la carte graphique. Une ligne rouge, quelques secondes de lecture, et vous savez qu’il faut aller ouvrir l’UDP sortant.
Les cas que je n’ai pas provoqués, mais que le script sait détecter
Par souci d’honnêteté, je ne décris ici que ce que j’ai réellement cassé et observé. Trois autres capacités de l’outil méritent d’être connues, même si je ne les ai pas mises en scène dans ce lab :
l’inspection SSL, qui remonte en [INSP] lorsque la chaîne de certificats renvoyée ne correspond pas à ce que Microsoft présente normalement
le handshake TLS qui échoue alors que le TCP passe, qui remonte en [TLS!], typiquement quand un Secure Web Gateway accepte le socket puis refuse le nom d’hôte au moment du SNI
la dérive d’horloge, mesurée via le test SNTP/NTP, cause classique et rarement soupçonnée d’échecs d’authentification
Si vous disposez d’un proxy d’inspection dans votre environnement de test, ces trois cas se provoquent facilement et feraient un excellent complément à ce lab.
8. Du symptôme utilisateur au correctif réseau
Voici la table de correspondance que j’ai construite à partir de ce lab. C’est elle que je garderais sous le coude en support N2, parce qu’elle part de ce que l’utilisateur dit, pas de ce que la console affiche.
Ce que dit l’utilisateur
Statut renvoyé par le script
Où aller chercher
Plus rien ne fonctionne depuis ce matin
[DNS!] massif
Résolution de noms, forwarders, serveurs DNS de la carte réseau
Windows 365 ne marche pas, mais je reçois mes mails
[FAIL] isolé sur un endpoint
Filtrage DNS, entrée hosts, sinkhole sur une zone précise
Mon Cloud PC est resté en cours de provisioning
[FAIL] sur azure-devices.net en 5671
Pare-feu sortant, port AMQP non ouvert
C’est lent, mais ça marche
Échec du test UDP Shortpath
UDP sortant bloqué, repli TCP en cours
Ça marche à Paris, pas à Lyon
Résultats divergents entre deux runs
Breakout Internet local, profil de proxy par site
Je n’arrive pas à me connecter mais le Cloud PC est vert dans Intune
Échecs en Mode 2 uniquement
Réseau du poste physique, pas le réseau Azure
La dernière ligne mérite un mot. C’est le scénario le plus courant et le plus mal traité, parce que les deux équipes concernées regardent chacune leur périmètre et le déclarent sain. Lancer le script en Mode 2 depuis le poste de l’utilisateur qui se plaint tranche le débat en trois minutes.
9. Ce que l’outil ne fait pas
Un article qui ne présente que les qualités d’un outil ne vous sert à rien. Voici les limites, et elles sont d’ailleurs documentées honnêtement par l’auteur, ce qui est suffisamment rare pour être signalé.
Le jeu d’endpoints couvre le cloud Microsoft commercial. Si vous êtes en GCC, GCC High ou dans un cloud souverain, les FQDN diffèrent et ce jeu de données ne vous concerne pas.
Le workload Intune valide les prérequis réseau publiés par Microsoft pour les appareils Windows. Il ne prétend pas tester tous les endpoints de tous les produits qui s’intègrent à Intune.
Les produits qui disposent de leur propre documentation réseau, comme Microsoft Defender for Endpoint ou Security Copilot, ont des prérequis supplémentaires non couverts ici.
Le script teste la connectivité, pas la configuration du tenant. Un flux ouvert ne garantit pas qu’une stratégie Intune soit correctement ciblée.
Il ne mesure pas la bande passante ni la qualité de la liaison sous charge. La latence est reportée, mais ce n’est pas un outil de capacity planning.
Cinq limites, aucune n’est rédhibitoire, et toutes sont assumées par le périmètre annoncé. C’est un outil de diagnostic de connectivité, il fait ce qu’il dit.
Attention : le fichier Endpoints.csv est téléchargé automatiquement depuis GitHub à chaque exécution. Sur un réseau très fermé, c’est justement ce téléchargement qui va échouer en premier. Récupérez le CSV depuis un poste ayant accès à Internet et passez-le en local avec -EndpointsCSV, sinon vous allez diagnostiquer l’absence d’accès à GitHub plutôt que votre problème réel.
10. Conclusion et pièges à retenir
Voilà, en une commande et quatre pannes provoquées, nous avons vérifié qu’un script PowerShell gratuit, sans dépendance et sans le moindre droit sur le tenant, sait faire la différence entre un DNS cassé, un port fermé et un transport UDP absent. C’est exactement ce qu’on demande à un outil de diagnostic.
Concrètement, ça donne quoi ? Vous gagnez la capacité de qualifier un incident réseau avant de l’escalader. Vous arrivez devant l’équipe réseau avec une ligne précise, un hôte, un port, un protocole et un statut, au lieu d’un « Windows 365 ne marche pas » qui va tourner en boucle pendant une semaine.
Les cinq pièges à retenir :
Ne confondez pas Workload et Mode. Le premier dit ce que vous validez, le second dit d’où vous testez. Un run en Mode 1 ne vous apprend rien sur le poste de l’utilisateur.
Exécutez en session élevée, sans quoi les vérifications de la fabric Azure peuvent apparaître en échec alors qu’elles vont bien.
Le port 5671 n’est pas optionnel pour Windows 365. Un pare-feu qui n’ouvre que le 443 casse le provisioning sans jamais produire d’erreur web.
Un run entièrement vert en TCP ne prouve rien sur la qualité de session. Si l’UDP est bloqué, RDP bascule silencieusement sur son repli TCP et l’utilisateur subit sans que rien ne remonte.
Gardez une baseline. Exportez en CSV le jour de la mise en service, c’est ce qui vous permettra de comparer le jour où ça se dégrade.
Foncez tester. Le script est sous licence MIT, il ne demande aucun droit, il tourne sur une VM jetable en trois minutes, et le pire qui puisse vous arriver est de découvrir que votre réseau n’est pas aussi conforme que vous le pensiez. Ce qui, précisément, est le but recherché.
Contenu assisté par IACet article a été rédigé avec l’assistance d’une intelligence artificielle et relu par l’auteur. Conformément à l’AI Act (UE) en vigueur depuis le 2 août 2026.
Vous avez acheté des instances réservées (RI) Azure, vous vous êtes toujours dit qu’en cas de changement de workload vous pourriez les échanger, et vous découvrez maintenant que ce filet de sécurité va disparaître ? Cet article est fait pour vous. On part de l’annonce Microsoft du 30 juillet 2026 et on déroule ce qui change, ce qui ne bouge pas, les scénarios chiffrés, et le plan d’action à mener avant le 1er février 2027.
Pour rappel, jusqu’ici l’échange était le joker des réservations Azure : vous aviez surdimensionné une série de VM, vous vous étiez trompé de région, vous aviez migré de Dsv3 vers Dsv5, et hop, un échange remettait le compteur d’engagement à zéro et sans pénalité :
Ce joker se referme bientôt : à partir du 1er février 2027, si un service Azure est couvert par un saving plan, la réservation correspondante n’est plus échangeable.
Pour vous guider plus facilement dans ce changement à venir, voici des liens rapides :
Mais avant de rentrer dans ce sujet bientôt brûlant, et si les réservations d’instance ne sont pas encore votre tasse de thé :
Qu’est ce qu’une instance réservée Azure ?
Pour faire simple, les Azure RIs sont comme des places de parking que vous louer pour 1 ou 3 ans, et où les VM (ou d’autres services de compute), peuvent y être affectées, afin d’économiser des frais de stationnement, donc ici des coûts d’infrastructure auprès de Microsoft.
Voici une vidéo qui va vous éclairer sur les RIs :
Et voici une vidéo expliquant cette fois les saving plans :
Voici donc comment on peut voir comment faire son choix entre instance réservée et un saving plan :
La règle tient en une phrase, et Microsoft l’écrit noir sur blanc :
Starting February 1, 2027, reservations purchased after this date aren’t eligible for exchange if the corresponding service is supported by savings plans.
En clair, à partir du moment où un service dispose d’un savings plan, Microsoft considère que vous avez déjà l’outil de flexibilité qu’il vous faut, et retire donc la flexibilité de la réservation. Deux régimes cohabitent, et tout se joue sur la date d’achat.
Date d’achat de la réservation
Droit d’échange
Avant le 1er février 2027
Échanges illimités jusqu’au 31 janvier 2027, puis un échange final après cette date
À partir du 1er février 2027
Aucun échange possible
Le mot important est final. Une réservation active achetée avant la bascule conserve le droit à un échange, un seul, et la réservation issue de cet échange n’est plus échangeable du tout. Microsoft le confirme dans la FAQ de son annonce : une fois l’échange final consommé, la réservation obtenue ne peut plus être échangée.
La politique est aussi prospective, et c’est un point que beaucoup vont rater : tout produit compute ou base de données qui deviendra éligible aux savings plans après le 1er février 2027 tombera automatiquement sous la même règle, et les réservations déjà achetées pour ce produit basculeront à leur tour sur le régime de l’échange unique.
les réservations de produits non couverts par les savings plans, Azure VMware Solution étant l’exemple cité par Microsoft ;
Attention : si vous opérez dans un cloud souverain ou un environnement où les savings plans ne sont pas disponibles, vous n’êtes pas concerné aujourd’hui. Mais la formulation Microsoft dit bien « don’t currently support », donc le jour où le savings plan y arrive, la règle vous rattrape.
La première exclusion mérite qu’on s’y arrête, parce qu’elle recoupe directement un sujet que j’ai traité récemment. Les séries D, Ds, Dv2, Dsv2, Ls, Av2, Amv2, B, F, Fs, Fsv2, G, Gs et Lsv2 ont toutes une date de retraite annoncée en 2028, et j’ai détaillé ce calendrier dans VM Azure : anticipez les dépréciations. Ces séries entrent a priori dans la catégorie des produits dépréciés et proches de la fin de vie, donc dans l’exclusion.
Attention : Microsoft ne publie aucune liste nominative des produits couverts par cette exclusion. Si une part de votre portefeuille porte sur ces anciennes séries, faites confirmer le point par votre account team plutôt que de le déduire. Et rappelez-vous que pour la plupart d’entre elles, la question ne se pose déjà plus à l’achat : les réservations ne sont plus commercialisées depuis le 1er juillet 2026.
2. Les services concernés
La page Learn se contente de « Azure Virtual Machines, Azure App Service, Azure SQL Database, and similar services », ce qui est un peu court quand on doit auditer un portefeuille d’engagements. L’annonce sur le Tech Community, elle, donne la liste exacte au moment de la publication :
Compute
Bases de données
Azure Virtual Machines, y compris les échanges entre stockage non premium et premium
Azure Database for PostgreSQL
Azure Dedicated Host
Azure Database for MySQL
Azure App Service
Azure DocumentDB
Azure Cosmos DB
Azure SQL Database
Azure SQL Managed Instance
Soit trois services compute et six services de bases de données, neuf au total. Notez la mention entre parenthèses sur les VM : l’échange F1 vers F1s, celui qu’on utilisait tranquillement pour passer une réservation vers une taille compatible stockage premium, entre lui aussi dans le périmètre.
Attention : cette liste est celle du 30 juillet 2026. Microsoft précise que d’autres services éligibles aux savings plans viendront s’y ajouter. Ne la figez pas dans votre documentation interne sans date de revue.
À l’inverse, deux familles gardent leur échangeabilité complète parce qu’elles ne sont pas couvertes par les savings plans : Azure VMware Solution et Nutanix on Azure BareMetal, qui restent d’ailleurs des cibles d’échange valides au sein de la famille compute.
3. Ce qui ne change pas
Avant de paniquer, faisons le tri. Beaucoup de choses restent en place, et Microsoft insiste lourdement sur le fait que les réservations ne sont pas en cours de retrait.
L’instance size flexibility pour les VM n’est pas touchée. Votre réservation D4s_v5 continue de couvrir deux D2s_v5 sans que vous ayez quoi que ce soit à faire.
La politique d’annulation ne bouge pas : le plafond reste à 50 000 USD de commitment annulé sur 12 mois glissants, par billing profile ou par enrollment.
Le trade-in vers un savings plan reste possible, sans limite de date, et sa politique est inchangée.
L’achat et le renouvellement de réservations restent disponibles pour tous les services concernés.
Sur la question « est-ce que Microsoft tue les réservations ? », la FAQ officielle répond non, et précise que le changement porte uniquement sur l’échangeabilité. Ce qui disparaît, c’est le droit à l’erreur, pas le produit.
4. Pourquoi Microsoft fait ça : ma lecture
Ce n’est pas la première tentative
Avant d’analyser le pourquoi, un rappel qui change la lecture de toute l’annonce : Microsoft a déjà essayé de fermer ce robinet, deux fois, et a reculé les deux fois.
Octobre 2022, au moment même du lancement du savings plan : Microsoft annonce la dépréciation de l’échange des réservations compute au 1er janvier 2024. L’argumentaire est déjà mot pour mot celui d’aujourd’hui, le savings plan apportant la flexibilité automatiquement, la politique d’échange des réservations est ajustée en conséquence.
Octobre 2023, premier recul : une période de grâce repousse l’échéance à « au moins le 1er juillet 2024 », avec déjà le principe d’un dernier échange conservé pour les réservations achetées avant la fin de cette période.
Mai 2024, deuxième recul, et cette fois sans nouvelle date.
30 juillet 2026 : la notification promise arrive, pour le 1er février 2027. Six mois et deux jours de préavis. Microsoft tient son engagement au calendrier près.
Originally with a deadline of 1 July 2024, we have extended this and customers may continue exchanging their compute reservations for different instance series and regions until we notify them again, which will be at least 6 months in advance of the new deadline.
Cette phrase de 2024 est la clé pour comprendre pourquoi il faut prendre 2027 au sérieux. Le préavis promis vient d’être consommé. Il n’existe plus aucun engagement derrière lequel espérer un troisième report, et parier sur « ils vont encore reculer », c’est parier contre la seule garantie que l’on avait.
Il y a même un précédent dans l’autre sens, et il est récent. La fin des réservations un an sur les anciennes séries de VM était initialement fixée au 15 novembre 2027 : Microsoft l’a avancée au 1er juillet 2026, soit plus d’un an plus tôt que prévu. J’ai documenté cet épisode dans VM Azure : anticipez les dépréciations. Autrement dit, une date annoncée sur les engagements Azure peut aussi bien reculer que se rapprocher, et construire un plan sur l’hypothèse d’un report est le plus mauvais des paris.
Deuxième différence de taille : en 2022, la mesure ne visait que le compute, soit les réservations Azure Reserved Virtual Machine Instances, Azure Dedicated Host et Azure App Service. La version 2027 y ajoute six services de bases de données. Ce n’est pas la même annonce repoussée de trois ans, c’est une version élargie.
Attention : la trace du sursis de 2024 est toujours en ligne. La page Learn consacrée aux échanges et remboursements contient encore la mention d’une période de grâce permettant d’échanger les réservations compute « until further notice », à quelques lignes de l’encadré annonçant le 1er février 2027. Ne vous fiez pas à ce paragraphe résiduel, c’est la nouvelle date qui fait foi.
La justification officielle est l’alignement : Microsoft explique que la mesure aligne la politique d’échange des réservations sur la flexibilité déjà offerte par les savings plans, et donne un cadre de choix clair et prévisible entre les deux mécanismes d’engagement.
Concrètement, ça donne quoi ? Depuis l’arrivée du savings plan, Azure proposait deux produits qui se recouvraient partiellement : une réservation échangeable à volonté offrait à peu près la même souplesse qu’un savings plan, avec en prime une remise plus élevée. Le portefeuille était incohérent. En retirant l’échange, Microsoft rend les deux produits réellement distincts : la réservation devient un engagement ferme sur une configuration précise, avec la remise maximale ; le savings plan devient l’engagement souple, avec une remise plus faible mais applicable partout.
Mon retour terrain : l’échange était devenu, chez pas mal de clients, une béquille de mauvais dimensionnement. On achetait large « parce qu’on pourra toujours échanger », et on ajustait six mois plus tard. Cette pratique s’arrête. La conséquence directe : le travail de sizing et de prévision remonte en amont de l’achat, là où il aurait toujours dû être.
5. Cinq scénarios concrets
Les trois premiers cas sont ceux documentés par Microsoft, les deux suivants sont les questions que l’on me pose systématiquement en atelier FinOps.
Cas n°1 : réservation achetée avant la bascule
Vous achetez une réservation compute ou base de données d’un an ou trois ans avant le 1er février 2027. Vous pouvez l’échanger autant de fois que vous voulez tant que la date n’est pas passée. Si vous l’échangez après le 1er février 2027, la nouvelle réservation issue de l’échange n’est plus échangeable, parce que l’échange est traité comme une annulation, un remboursement et un nouvel achat, et que ce nouvel achat tombe sous les conditions du 1er février 2027.
Le piège classique est là : beaucoup vont croire qu’ils « gardent le droit d’échange » indéfiniment sur une réservation ancienne. Non. Le mécanisme d’échange fabrique une réservation neuve, et une réservation neuve après la bascule est verrouillée.
Cas n°2 : réservation achetée après la bascule
Vous achetez une réservation d’un an ou trois ans après le 1er février 2027. Vous ne pouvez pas l’échanger. Point. Il vous reste deux sorties : le trade-in vers un savings plan, toujours possible, et le remboursement dans la limite du plafond de 50 000 USD.
Cas n°3 : échange partiel de quantités
C’est le cas le plus intéressant et le moins connu. Vous achetez avant la bascule une réservation avec 10 quantités. Après le 1er février 2027, vous en échangez 2. Les 8 quantités restantes sur la réservation d’origine conservent chacune leur droit à un échange supplémentaire.
Autrement dit, l’échange final se compte à la quantité, pas à la réservation. C’est une marge de manœuvre réelle si vous savez déjà que votre parc va bouger par vagues : vous pouvez étaler vos ajustements plutôt que de tout jouer d’un coup.
Cas n°4 : l’échange coûte plus cher que prévu
Vous avez une réservation trois ans à 100 USD par mois, vous avez déjà payé 18 mensualités. Votre engagement restant est de 1 800 USD. Pour échanger, la nouvelle réservation doit avoir une valeur totale d’au moins 1 800 USD, que vous payiez au mois ou en une fois. Même logique sur un achat upfront : une réservation d’un an payée 2 400 USD, échangée après six mois, laisse un engagement restant de 1 200 USD, et la nouvelle réservation doit donc valoir 1 200 USD ou plus.
Et le terme repart de zéro. La réservation issue de l’échange démarre un nouveau cycle d’un ou trois ans à compter de la date d’échange. Si vous consommez votre échange final en fin de vie d’une réservation, vous vous rengagez donc pour un cycle complet, sur un actif désormais figé.
Cas n°5 : le trade-in plutôt que l’échange
Vos réservations VM ne collent plus à votre parc, mais vous ne savez pas vers quelle série aller. Plutôt que de brûler votre échange final sur un pari, vous les échangez contre un savings plan compute. Azure annule les réservations, vous rembourse au prorata, annule les échéances futures si vous payiez au mois, et vous engage sur un nouveau commitment horaire d’un an ou trois ans.
Attention : le trade-in est un aller simple. Vous ne pouvez pas échanger un savings plan contre une réservation, ni contre un autre savings plan. Réfléchissez avant.
6. Réservation ou savings plan : la grille d’arbitrage
Le savings plan, c’est un engagement en dollars par heure sur des services compute ou bases de données éligibles, appliqué automatiquement quelle que soit la région. La réservation, c’est un engagement sur un type d’instance ou une famille d’instances, dans une région donnée.
Microsoft prend l’exemple d’une D2v4 en Japan East pour un an d’un côté, et de 5,00 USD par heure pendant trois ans de l’autre.
Critère
Réservation
Savings plan
Nature de l’engagement
Instance ou famille d’instances, région fixée
Dépense horaire, toutes régions éligibles
Niveau de remise
Le plus élevé quand l’utilisation est pleine
Remise significative, mais inférieure
Souplesse
Instance size flexibility uniquement
Application automatique sur les services éligibles
Échange
Un échange final, puis plus rien après le 1er février 2027
Non échangeable par construction
Profil de workload
Continu, stable, sans changement prévu
Dynamique, évolutif, multi-familles ou multi-régions
Microsoft propose une séquence d’optimisation en cinq temps, et elle vaut le détour parce qu’elle remet l’ordre des opérations à l’endroit :
Right-sizer d’abord, en supprimant les ressources inutilisées ou surdimensionnées. Une remise réduit un tarif, elle ne réduit pas du gaspillage.
Échanger les réservations sous-utilisées vers des configurations mieux adaptées, tant que c’est encore possible.
Basculer en trade-in les réservations sous-utilisées dont l’usage est variable.
Acheter de nouvelles réservations, uniquement sur les workloads stables et bien compris.
Ajouter des savings plans, dimensionnés sur une base de consommation déjà nettoyée.
Les points 2 et 3 ont maintenant une date de péremption. C’est tout l’enjeu des prochains mois.
7. Le trade-in en pratique
Le trade-in est le mécanisme qui survit intégralement au changement de politique, autant savoir s’en servir correctement.
Ce qui est éligible
Les réservations Azure Virtual Machines, Dedicated Hosts et Azure App Service s’échangent contre un savings plan compute, avec un nouvel engagement d’un an ou trois ans. Les réservations de bases de données s’échangent contre un savings plan database, avec un engagement d’un an. En dehors de ces produits, aucune autre réservation ni aucun pre-purchase plan n’est éligible au trade-in. Vous pouvez traiter jusqu’à 100 réservations dans une même opération d’achat de savings plan.
Les droits nécessaires
Il vous faut être owner du Reservation Order concerné, et disposer du rôle Savings plan purchaser ou être owner de la subscription qui portera l’achat. Et voici le piège qui fait échouer la moitié des premières tentatives : les permissions EA Admin write et Billing profile contributor, qui suffisent pour un achat direct de savings plan, ne fonctionnent pas pour un achat réalisé dans le cadre d’un trade-in de réservation.
Calculer le bon commitment horaire
Attention, celui-ci mérite qu’on s’y arrête. Lors d’un trade-in, le commitment horaire proposé par défaut est calculé à partir de la valeur monétaire restante des réservations retournées. Ce montant n’est pas forcément suffisant pour couvrir les VM que les réservations couvraient. Vous risquez donc de sortir de l’opération avec une couverture en baisse sans vous en rendre compte.
La méthode Microsoft pour calculer le vrai commitment, produit par produit, en partant de la calculatrice de prix Azure et d’un affichage upfront :
Récupérer le coût upfront annuel du produit concerné pour le terme de savings plan visé.
Diviser ce coût par 8 760 pour un savings plan d’un an, ou par 26 280 pour un savings plan de trois ans.
Multiplier le résultat par le nombre d’instances que vous retournez.
Répéter pour chaque produit du trade-in, puis additionner : c’est votre commitment horaire.
Attention : ce calcul suppose une utilisation à 100 % des réservations retournées. Et comme le savings plan est un bénéfice flexible, rien ne garantit qu’il s’appliquera toujours en priorité aux ressources précédemment couvertes. Vérifiez votre couverture réelle dans les jours qui suivent l’opération.
8. Les pièges à connaître
Sept points de vigilance à garder sous la main quand vous allez manipuler votre portefeuille d’engagements dans les prochains mois.
Le plafond de remboursement. 50 000 USD de commitment annulé maximum sur 12 mois glissants, par billing profile ou enrollment. Bonne nouvelle : les remboursements issus d’un échange ne consomment pas ce plafond. Mauvaise nouvelle : si l’échange n’est plus disponible, toute sortie passe désormais par un remboursement qui, lui, décompte.
Le réapprovisionnement du plafond. Il n’est pas annuel civil. Si vous annulez 2 400 USD, votre marge tombe à 47 600 USD et remonte de 2 400 USD exactement 365 jours après l’opération.
Les gros engagements bloqués. Sur une réservation trois ans à 3 000 USD par mois, soit 108 000 USD, vous ne pouvez rien annuler tant que vous n’avez pas consommé 58 000 USD de votre engagement, parce que le reste dépasse le seuil de 50 000 USD.
Pas d’échange entre familles de produits. Une réservation Cosmos DB ne s’échange pas contre une réservation SQL Database. Les échanges restent cantonnés à la famille : compute avec compute, SQL avec SQL.
Certaines réservations n’ont jamais été échangeables. Les plans Red Hat, les plans SUSE Linux et tous les pre-purchase plans sont exclus de l’échange comme du remboursement, et ce point n’a pas changé.
Les droits sur le Reservation Order. Il faut être owner ou Reservation administrator sur le Reservation Order pour échanger ou rembourser. Ce n’est pas un rôle de subscription, et ça se prépare à l’avance.
Le cas CSP. Un client CSP ne peut pas échanger, annuler, renouveler ou rembourser lui-même : c’est le partenaire qui effectue l’opération pour son compte. Si vous êtes dans ce modèle, calez le sujet avec votre partenaire dès maintenant, pas le 25 janvier 2027.
Deux précisions financières utiles pour le dossier que vous allez devoir monter en interne. Côté EA, un remboursement revient sous forme de crédit sur l’Azure Prepayment, et ce crédit n’est valable que 90 jours : passé ce délai, il est perdu. Côté frais, Microsoft ne facture pas de frais de résiliation anticipée aujourd’hui, mais la documentation mentionne explicitement la possibilité de 12 % à l’avenir, sans date annoncée.
9. Votre plan d’action avant le 1er février 2027
Il vous reste environ cinq mois. Microsoft résume l’action attendue en une ligne : passez en revue votre portefeuille de réservations, évaluez vos besoins futurs de flexibilité, envisagez les savings plans là où c’est pertinent, et planifiez la façon dont vous voulez utiliser l’échange final. Voici comment je le décline concrètement.
Inventoriez. Exportez la liste de vos réservations avec, pour chacune, le service, la date d’achat, le terme, la date d’expiration, la quantité et le taux d’utilisation. Si vous n’avez pas encore fait l’inventaire de vos VM par série, la procédure pas-à-pas est dans VM Azure : anticipez les dépréciations, et les deux exercices se font très bien dans la foulée.
Classez chaque ligne en trois piles : stable et bien dimensionnée, sous-utilisée, ou obsolète parce que le workload a bougé.
Right-sizez le parc avant de toucher aux engagements. On n’optimise pas une remise sur des ressources qu’on va éteindre, ni sur une série qui part à la retraite en 2028.
Traitez la pile « sous-utilisée » avant le 31 janvier 2027, tant que les échanges sont encore illimités. C’est votre fenêtre de correction gratuite.
Pour les workloads dont vous ne savez pas dire où ils seront dans un an, privilégiez le trade-in vers un savings plan plutôt que de consommer l’échange final sur un pari.
Documentez, pour chaque réservation antérieure à la bascule, si son échange final est encore disponible. Sans ce suivi, personne ne saura répondre en 2028.
Vérifiez dès maintenant les droits : owner ou Reservation administrator sur les Reservation Orders, rôle Savings plan purchaser pour les trade-in.
Reprenez vos gabarits d’achat et vos process internes : à partir du 1er février 2027, un achat de réservation est un engagement ferme, il mérite le même niveau de validation qu’un investissement.
Conclusion
Voilà, en neuf sections, de quoi arrêter de subir cette annonce. Le changement n’est pas une catastrophe, c’est une remise à plat : Azure vous propose désormais deux produits d’engagement clairement séparés, un rigide et très remisé, un souple et un peu moins remisé, et vous demande de choisir en connaissance de cause.
Les quatre pièges à retenir :
Un échange réalisé après le 1er février 2027 produit une réservation définitivement figée, parce qu’un échange est techniquement un rachat.
L’échange final se compte à la quantité, pas à la réservation : c’est une marge de manœuvre, à condition de la suivre.
Le commitment horaire proposé par défaut lors d’un trade-in ne garantit pas votre niveau de couverture précédent.
Sans échange, la seule porte de sortie restante est le remboursement, et lui se heurte au plafond de 50 000 USD sur 12 mois glissants.
Sortez votre export de réservations, comptez les lignes sous-utilisées, et calez l’exercice avant fin janvier. Foncez, c’est le genre de chantier qui prend deux heures maintenant et coûte très cher plus tard.
🤖
Contenu assisté par IA Cet article a été rédigé avec l’assistance d’une intelligence artificielle et relu par l’auteur. Conformément à l’AI Act (UE) en vigueur depuis le 2 août 2026.
Pas trop chaud en ce moment ? Si vous êtes en vacances, ne lisez pas cet article ! Mais si vous êtes au bureau … un fichier douteux a peut-être atterri sur votre poste, ou un exe reçu par mail, ou encore un script « lance ça pour réparer ton VPN ». Bref, vous devez l’ouvrir pour vérifier sans risquer votre machine ni le réseau de l’entreprise.
Cet article est fait pour vous. On va monter, étape par étape, une sandbox Windows jetable et durcie pour analyser un fichier hors-ligne, puis sa variante pour le dev, avant de voir comment pousser tout ça sur un parc de Cloud PC via Intune.
Pour vous guider plus facilement dans cet article, voici des liens rapides :
Pour rappel, Windows Sandbox est un environnement Windows jetable : du Hyper-V, une seule instance à la fois, calée sur le même build que l’hôte, et tout l’état part à la poubelle à la fermeture (seul un redémarrage lancé depuis l’intérieur est conservé) :
Bac à sable Windows (WSB) offre un environnement de bureau léger et isolé pour exécuter des applications en toute sécurité. Il est idéal pour tester, déboguer, explorer des fichiers inconnus et expérimenter des outils.
Les applications installées dans le bac à sable restent isolées de l’ordinateur hôte à l’aide de la virtualisation basée sur l’hyperviseur.
Vous ouvrez, vous testez, vous fermez, il ne reste rien :
En tant que machine virtuelle jetable, Bac à sable Windows garantit la persistance du redémarrage, des temps de lancement rapides et un encombrement mémoire inférieur par rapport aux machines virtuelles complètes. Sa configuration en un clic simplifie l’expérience utilisateur.
L’erreur, c’est de croire qu’il existe un seul bon réglage. En réalité, on configure la sandbox selon l’intention. Pour de l’analyse, on veut la couper du monde : réseau désactivé, entrée en lecture seule, presse-papier coupé. Pour du dev, on veut au contraire le réseau actif pour tirer les paquets. C’est le fil rouge de cet article, et ça change tout, surtout sur un Cloud PC branché sur le réseau de l’entreprise.
Le piège classique : dans Windows Sandbox, le réseau est activé par défaut :
Enabling networking can expose untrusted applications to the internal network.
Microsoft recommande d’ailleurs, pour lancer une appli non fiable, exactement la posture qu’on va construire : réseau désactivé et dossier de l’application mappé en lecture seule.
2. Étape 0 : les prérequis
Avant de commencer, trois choses côté hôte :
Savoir si la fonctionnalité Windows Sandbox est déjà activée :
L’installation de la Sandbox Windows nécessite un redémarrage du poste :
Et cela prendra une quinzaine de minutes environ :
Attention, la virtualisation doit être disponible sur la machine !
Sur un Cloud PC Windows 365, ce dernier point mérite attention : Windows Sandbox y passe par la virtualisation imbriquée, qui n’est disponible que si le Cloud PC a 4 vCPU ou plus :
Pour utiliser des charges de travail basées sur la virtualisation, le Cloud PC doit répondre à ces exigences :
PC cloud de 4 processeurs virtuels ou plus (le fait de réduire à 2 processeurs virtuels les PC cloud désactive la virtualisation imbriquée).
Être approvisionné dans l’une des régions prises en charge pour Windows 365. (La virtualisation imbriquée n’est actuellement pas prise en charge en Afrique du Sud Nord).
Certains utilisateurs peuvent rencontrer une baisse des performances de leur PC cloud 4 processeurs virtuels lors de l’utilisation de la virtualisation imbriquée. Pour plus d’informations sur la résolution de ces problèmes de performances.
3. Étape 1 : préparer les outils côté hôte
Créez un dossier de travail sur l’hôte, par exemple C:\Sandbox, qui servira à passer les fichiers et les scripts à la sandbox :
Puisque la sandbox d’analyse sera hors-ligne, on lui prépare tout depuis l’hôte. Je suis parti du repo mdevolde/windows-sandbox-malware, qui pose bien la mécanique, mais j’ai dû l’adapter : les scripts d’origine ne fonctionnaient pas tels quels chez moi.
Voici ma version, testée de bout en bout :
Le script preinstall.ps1 crée C:\Sandbox\install et y télécharge, via winget, six outils d’analyse : Notepad++, Sysinternals Suite, 7-Zip, x64dbg, Wireshark et PE-bear :
Attention : ne placez que du matériel de confiance dans C:\Sandbox. Ce dossier sera lu par la sandbox, il ne doit pas contenir l’échantillon suspect au moment de préparer les outils.
Les installeurs sont alors visibles dans le dossier suivant :
Continuons avec le fichier de configuration du premier test de la Sandbox.
4. Étape 2 : le .wsb durci d’analyse
Voici le fichier de configuration Sandbox dans le cadre d’un essai pour analyse :
Il coupe le réseau et le vGPU, désactive presse-papier, imprimante, micro et webcam, monte C:\Sandbox en lecture seule, et lance le script de préparation au démarrage. Il reprend les réglages du malware.wsb du repo mdevolde, avec deux ajouts de mon cru : le chemin vers le sous-dossier scripts, et l’option -NoExit qui garde la fenêtre PowerShell ouverte. Sans elle, la fenêtre se ferme aussitôt et vous ne voyez jamais les erreurs.
Chaque réglage a un rôle : Networking à Disable coupe toute comm réseau (pas de C2 possible) :
ReadOnly à true fait de C:\Sandbox une entrée à sens unique :
Et couper le presse-papier ferme un canal d’exfiltration.
Le compte intégré de la sandbox s’appelle WDAGUtilityAccount, d’où le chemin du bureau en sortie :
Une variante utile : on peut laisser au contraire le presse-papier actif, pour faire glisser le fichier depuis l’hôte avant de tout couper. Deux écoles : entrée par dossier en lecture seule (plus stricte) ou par presse-papier (plus pratique). À vous de choisir selon votre niveau de paranoïa.
Attention : ces configs communautaires désactivent parfois Smart App Control (WDAC) au démarrage, parce que la validation de chaque binaire écrit par un installeur peut ajouter plus de 15 minutes à une install. C’est pratique, mais c’est un abaissement de sécurité assumé, à ne pas copier sans comprendre ce que vous coupez.
5. Étape 3 : le script de démarrage
Au démarrage, la LogonCommand exécute SandboxSetup.ps1 (copié dans C:\Sandbox\scripts). Ce script installe en silence les outils depuis HostShared\install, puis prépare l’environnement pour l’analyse : affichage des extensions et des fichiers cachés, activation des chemins longs, entrées de menu contextuel (ouvrir PowerShell ou l’invite de commandes ici, éditer avec Notepad++), et quelques réglages d’ergonomie.
Voici le script tournant au démarrage de la Sandbox :
Le détail complet du script SandboxSetup.ps1 est juste ici :
Vous le copiez, vous le posez dans C:\Sandbox\scripts\, et la sandbox fait le reste. Concrètement, ça donne quoi ? En quelques secondes après le démarrage, vous avez un poste d’analyse prêt, hors-ligne, avec vos outils.
Un mot sur le débogage : le Start-Transcript en tête de script écrit tout dans C:\SandboxLog.txt. En cas de souci, c’est le premier endroit à regarder. Vous y verrez d’ailleurs une ligne TerminatingError(Set-ExecutionPolicy) qui n’est pas un plantage : c’est le message habituel indiquant qu’une policy plus spécifique prime, et le script continue sans problème.
6. Étape 4 : le moment de vérité
Le moment de vérité. Vous analysez avec ce dont vous avez besoin, sans jamais auto-exécuter le payload : c’est vous qui décidez quoi lancer et quand.
Déposez l’échantillon suspect dans C:\Sandbox côté hôte :
Double-cliquez sur le .wsb :
La sandbox démarre déjà outillé et coupé du monde :
Les applications s’installent :
Et voilà !
Il ne reste qu’à travailler dessus :
Et quand vous avez fini, vous fermez la fenêtre. Tout disparaît, l’échantillon compris. Rien n’a touché votre poste, rien n’a atteint le réseau.
7. Variante : une sandbox de dev auto-provisionnée
Le même mécanisme, posture inversée. Pour du dev, on veut le réseau actif pour tirer les paquets, et un script qui installe la toolchain au démarrage. Le repo M-d3bug fournit un Sandbox_opencode.wsb qui, au logon, installe Python, Node LTS, Git et Windows Terminal, puis opencode via npm.
J’ai retenu la seconde piste, et pour une bonne raison : je voulais la même approche hors-ligne que pour l’analyse. Or opencode passe par npm, qui a besoin du réseau pour aller chercher son paquet. VS Code, lui, existe en installeur autonome, donc on peut le stager sur l’hôte et l’installer sans la moindre connexion. Le principe reste le même que pour la sandbox d’analyse : tout ce qui touche à Internet se fait côté hôte, une bonne fois.
Jusqu’ici, tout s’est joué sur une seule machine, la vôtre. Sur un parc, la question change : comment rendre Windows Sandbox disponible sur des dizaines de postes ou de Cloud PC ?
Bonne nouvelle, il n’y a rien à déployer. Windows Sandbox n’est pas une application à installer, c’est une fonctionnalité déjà présente dans Windows qu’il suffit d’activer : Containers-DisposableClientVM. La méthode de référence est celle de Peter van der Woude : un script PowerShell Intune, exécuté en contexte SYSTEM, assigné aux appareils, avec un redémarrage pour finaliser.
Mon retour terrain : le vrai travail n’est pas le déploiement, c’est le ciblage. Le script active la fonctionnalité même là où elle ne pourra jamais tourner. Sur un parc de Cloud PC, visez un groupe qui exclut les Cloud PC GPU et les 2 vCPU, sinon vous activez une fonctionnalité morte sur une partie du parc.
Autre usage Intune, plus discutable : enrôler une Sandbox comme device de test jetable pour valider un Win32 ou une remédiation, comme le montre Damien Van Robaeys. Ça marche, mais la sandbox s’efface à la fermeture : vous devez ré-enrôler à chaque lancement, et chaque cycle laisse un objet appareil fantôme et ingérable dans le tenant. Pratique pour un lab, salissant pour l’hygiène de production.
Quelques minutes plus tard, la sandbox devient visible sur Intune :
9. Jusqu’où faire confiance ?
Soyons honnêtes sur les limites. Windows Sandbox, c’est de l’isolation renforcée, pas un airgap.
Une évasion d’hyperviseur reste théoriquement possible : la sandbox partage le build et l’hyperviseur de l’hôte.
Certains malwares détectent qu’ils sont en sandbox et restent dormants. « Il ne s’est rien passé » ne prouve donc pas l’innocuité.
Désactiver Smart App Control pour gagner du temps, c’est baisser une protection réelle.
Mon retour terrain : pour trancher « c’est louche ou pas ? » sur un fichier du quotidien, cette sandbox est parfaite. Pour disséquer un malware ciblé, montez un vrai labo isolé, hors du réseau et hors de votre poste de production.
10. Récap : prérequis et pièges
Élément
Ce qu’il faut
Le piège à éviter
vCPU (Cloud PC)
4 vCPU ou plus
Repasser à 2 vCPU désactive la virtualisation imbriquée
Type de Cloud PC
Non-GPU
Un Cloud PC GPU ne fait tourner ni Sandbox, ni WSL, ni Hyper-V
Région
Une région supportée
Non supporté en South Africa North
Réseau (analyse)
Networking sur Disable
Réseau activé par défaut, exposé au réseau interne
Réseau (dev)
Networking sur Enable
Télécharge et exécute des installeurs à chaque lancement
Activation Intune
Ciblage GPU / 2 vCPU exclus
La fonctionnalité s’active même là où elle ne tourne pas
Enrôlement Intune
Réservé au lab
Ré-enrôlement à chaque lancement, devices fantômes dans le tenant
Conclusion
Voilà, en quatre étapes plus une variante, vous avez une sandbox d’analyse jetable et durcie, une sandbox de dev auto-provisionnée, et de quoi déployer proprement la fonctionnalité sur un parc de Cloud PC. Concrètement, ce que vous y gagnez : ouvrir un truc pas net en isolation, en trente secondes, puis tout jeter, sans jamais toucher votre poste ni le réseau.
Les pièges à retenir :
Réseau activé par défaut : pour l’analyse, coupez-le explicitement.
Un réglage par intention : analyse hors-ligne, dev en ligne, ne les confondez jamais.
Sur Cloud PC : 4 vCPU minimum, région supportée, jamais de GPU.
Via Intune, la fonctionnalité s’active même là où elle ne tourne pas : ciblez.
La sandbox n’est pas un labo d’analyse de malware ciblé.
Foncez tester : préparez C:\Sandbox, récupérez les scripts, collez le .wsb d’analyse, et lancez. Une fois le réflexe pris, on n’ouvre plus jamais un fichier douteux autrement.
🤖
Contenu assisté par IACet article a été rédigé avec l’assistance d’une intelligence artificielle et relu par l’auteur. Conformément à l’AI Act (UE) en vigueur depuis le 2 août 2026.
Depuis quelques mois, à l’heure où j’écris ces lignes fin juillet 2026, vous avez peut-être déjà reçu un ou plusieurs mails d’Azure au sujet de certaines de vos machines virtuelles : des annonces sur les Reserved Instances, sur des séries qui partent à la retraite, et vous vous demandez ce qui va réellement vous tomber dessus, et surtout quand ? Cet article est fait pour vous.
Car ces annonces ne forment pas un seul événement, mais trois vagues distinctes qui convergent sur la même période. On va les démêler une par une, poser le calendrier noir sur blanc, puis dérouler, capture après capture, ce que vous devez vérifier et faire dès maintenant dans le portail Azure. Objectif : que vous ressortiez de cette lecture avec un plan d’action clair, pas juste une vague inquiétude.
Pour vous guider plus facilement dans cet article, voici des liens rapides :
Les annonces Azure mélangent plusieurs vocabulaires, et la plupart des malentendus viennent de leur confusion. Le cycle de vie d’une taille de VM passe par quatre états successifs :
Génération courante : la série recommandée, avec capacité garantie.
Previous-gen (génération précédente) : encore pleinement supportée, mais sans garantie de capacité supplémentaire. Deux nuances, next-gen available (pas encore de date de retraite) et capacity limited (plus aucune capacité déployée).
Retraite annoncée : une date de fin est fixée, la VM tourne encore mais il faut migrer.
Retirée : la taille n’est plus disponible, impossible d’en provisionner.
Deux autres termes, financiers cette fois, reviennent sans arrêt :
Reserved Instance (RI) : un engagement d’un ou trois ans sur une série de VM précise, en échange d’une remise. C’est un dispositif de facturation, pas un état de la VM.
Quota : le plafond de cœurs que votre abonnement peut déployer pour une série donnée, dans une région donnée.
Le fil rouge de tout l’article tient en deux phrases : previous-gen ne veut pas dire retirée, et fin des RI ne veut pas dire retraite de la VM. Gardez ces distinctions en tête, elles évitent la grande majorité des paniques inutiles.
Voici d’ailleurs pour info un portail très utile des décommissionnements prévus par Microsoft, accessible directement depuis le portail Azure Advisor :
Vague 1 : la fin des Reserved Instances (1er juillet 2026)
Première vague dans l’ordre chronologique, et elle est déjà passée. Depuis le 1er juillet 2026, Azure ne vend plus et ne renouvelle plus certaines Reserved Instances. Mais l’histoire a commencé bien avant cette date, car les réservations 1 an et 3 ans ne s’arrêtent pas au même moment. Voici le tableau complet des échéances :
Séries
RI 3 ans : plus d’achat ni de renouvellement depuis
RI 1 an : plus d’achat ni de renouvellement depuis
D, Ds, Dv2, Dsv2, Ls
1er mai 2025
1er juillet 2026
Av2, Amv2, Bv1, F, Fs, Fsv2, G, Gs, Lsv2
15 novembre 2025
1er juillet 2026
Dv3, Dsv3, Ev3, Esv3
1er juillet 2026
1er juillet 2026
Ce qu’il faut lire dans ce tableau : pour la plupart de ces séries, les réservations 3 ans ne sont déjà plus renouvelables depuis 2025 (mai pour la famille D et Ls, novembre pour les autres). Seules les réservations 1 an tenaient encore, et c’est cette dernière porte qui s’est refermée le 1er juillet 2026. Pour Dv3, Dsv3, Ev3 et Esv3, les deux durées s’arrêtent le même jour, le 1er juillet 2026.
Bon à savoir : cette date du 1er juillet 2026 pour les RI 1 an a été avancée. Elle était initialement fixée au 15 novembre 2027 (Azure Update 500682). Microsoft l’a donc rapprochée de plus d’un an, ce qui laisse encore moins de marge que ce qui était annoncé au départ.
Un point capital pour Dv3, Dsv3, Ev3 et Esv3 : ces séries ne sont pas retirées, elles restent « product active ». Ce sont seulement leurs réservations qui s’arrêtent. Ne confondez pas les deux.
Le piège classique : croire que le renouvellement automatique vous protège. Il ne joue plus pour ces séries. Vos réservations existantes restent valables jusqu’au bout de leur terme, un contrat 3 ans en cours court par exemple jusqu’à sa date de fin, mais à leur expiration, la charge bascule automatiquement en tarif pay-as-you-go, souvent bien plus cher, même si l’option de renouvellement automatique était cochée.
« July 1, 2026 does not terminate existing RIs. RIs remain valid until their individual expiration dates. »
Attention : le 1er juillet 2026 ne résilie aucune réservation en cours. Une RI reste honorée jusqu’à sa date d’expiration individuelle. Le risque n’est pas une coupure, c’est une hausse de facture silencieuse le jour où elle expire.
Trois leviers, selon votre situation :
Passer à l’Azure savings plan for compute : un engagement basé sur la dépense horaire, flexible entre familles de VM et entre régions. C’est la recommandation numéro un de Microsoft.
Migrer vos charges vers une série récente, qui redonne accès aux RI comme aux Savings Plans.
Ne rien faire et assumer le pay-as-you-go, mais que ce soit un choix conscient, pas un oubli.
Note : la possibilité de renouveler une dernière fois les réservations 1 an existait jusqu’au 30 juin. Depuis le 1er juillet, cette porte est fermée pour les séries listées ci-dessus, et celle des réservations 3 ans l’était déjà depuis 2025 :
Vague 2 : le gel de la croissance de capacité (31 juillet 2026)
Deuxième vague, et de loin la plus imminente puisque la première est déjà derrière nous. À compter du 31 juillet 2026, Azure gèle la croissance de capacité des anciennes séries. Concrètement, les demandes suivantes ne seront plus approuvées :
les nouveaux déploiements de VM sur ces séries,
les opérations de scale-out qui réclament de la capacité supplémentaire,
les demandes d’augmentation de quota,
vos plans de croissance future sur ces séries.
Ce qui n’est pas touché, et c’est la bonne nouvelle : vos déploiements existants continuent de tourner dans la limite de la capacité déjà allouée. Aucune interruption, aucune VM coupée du jour au lendemain à cause de ce gel.
Les séries concernées se répartissent en deux groupes. D’abord celles qui partent à la retraite et sont soumises au gel :
Attention : le gel ne coupe rien, mais il vous enferme. Si demain vous avez besoin d’ajouter des VM sur une de ces séries (montée en charge, nouveau projet, reprise d’activité dans une autre région), la demande peut être refusée. C’est précisément le scénario à anticiper avant le 31 juillet.
Je vous propose de regarder en exemple une machine virtuelle en série Bs avant la date du 31 juillet 2026. Le redimensionnement de celle-ci vers différentes tailles de la même famille est possible :
Et celui-ci fonctionne bien :
Par contre, j’avais déjà eu un refus de la part de Microsoft sur une demande d’augmentation de quota pour cette série :
Je vous referai dans quelques jours d’autres copies d’écran afin de comparer le changement à partir du 1er août.
Vague 3 : le calendrier de retraite des séries v1 à v4
Troisième vague, la plus étalée dans le temps. Voici le calendrier consolidé des retraites, de la plus ancienne (déjà effective) à la plus lointaine.
Série
Catégorie
Statut
Date de retraite
NCv3, NCv3-NC24rs
GPU
Retirée
30/09/2025
NVv3, NVv4
GPU
Annoncée
30/09/2026
M192idms_v2, M192ids_v2, M192ims_v2, M192is_v2
Mémoire
Annoncée
31/03/2027
NP-series
FPGA
Annoncée
31/05/2027
D, Ds, Dv2, Dsv2
Usage général
Annoncée
01/05/2028
Ls
Stockage
Annoncée
01/05/2028
Av2, Amv2
Usage général
Annoncée
15/11/2028
B-series (V1)
Usage général
Annoncée
15/11/2028
F, Fs, Fsv2
Compute optimisé
Annoncée
15/11/2028
G, Gs
Mémoire
Annoncée
15/11/2028
Lsv2
Stockage
Annoncée
15/11/2028
Deux lectures à retenir. D’une part, certaines séries GPU sont déjà retirées depuis septembre 2025 : si vous tournez encore dessus, vous êtes hors support et hors SLA. D’autre part, le gros des séries généralistes (D, Ds, Av2, F, G et compagnie) part en 2028, ce qui vous laisse du temps pour planifier, à condition de commencer maintenant. Le lot du 15 novembre 2028 (F, Fs, Fsv2, Lsv2, G, Gs, Av2, Amv2 et la série B) fait d’ailleurs l’objet d’une annonce dédiée, l’Azure Update 500682.
Attention : la date de retraite n’est pas le seul mur. Dès qu’une série passe en capacity limited, vous pouvez vous heurter à un manque de capacité bien avant la date officielle. Le gel du 31 juillet, c’est exactement ça. Ne calez pas votre migration sur 2028 en pensant être tranquille.
Vers quoi migrer ? Les séries cibles v5, v6, v7
Bonne nouvelle, Microsoft fournit une table de correspondance claire. Voici les cibles recommandées, série par série.
Stockage local NVMe, débit distant nettement supérieur
Ls, Lsv2
Lsv3/Lasv3, Lsv4/Lasv4
Lsv4 et Lasv4 sont la dernière génération L
Dv3, Dsv3 (RI arrêtées)
Dsv5/Ddsv5/Dasv5, Dsv6/Ddsv6/Dasv6
Pas retirées, mais plus de RI
Ev3, Esv3 (RI arrêtées)
Esv5/Edsv5/Easv5, Esv6/Edsv6/Easv6
Pas retirées, mais plus de RI
Attention : la génération v6 impose des prérequis. Elle exige le NVMe activé (donc un OS supporté), fonctionne uniquement avec des VM de Génération 2, et requiert l’adaptateur réseau MANA avec un OS compatible. Si l’un de ces points bloque, repliez-vous provisoirement sur la v5. Et vérifiez la capacité régionale de la cible, elle n’est pas garantie partout.
Ce que vous devez faire, concrètement
Assez de théorie. Voici la marche à suivre, étape par étape, capture après capture. Comptez une petite heure pour un premier inventaire propre.
Étape 1 : inventorier vos VM par série
Direction le portail Azure. Dans la barre de recherche, tapez Virtual machines pour ouvrir la liste de vos VM. Ajoutez la colonne Size (bouton Manage view puis Edit columns) pour voir d’un coup d’œil la taille de chaque machine, puis repérez celles dont la série figure dans les tableaux ci-dessus :
Vous pouvez aussi utiliser le rapport Service Retirement Workbook disponible dans Azure Advisor :
Étape 2 : auditer vos Reserved Instances
Toujours dans le portail, recherchez Reservations. Filtrez par Product type réglé sur Virtual machines, puis examinez deux colonnes, la VM family et la date d’expiration. Toute réservation dont la famille figure dans la liste de la vague 1 est concernée :
Pour aller plus loin, ouvrez le détail de la réservation concernée et vérifiez son taux d’utilisation ainsi que sa date de fin. Confirmez si la charge continuera au-delà de l’expiration : si oui, il faut agir avant :
Étape 3 : choisir votre stratégie de coûts
Pour chaque réservation ou VM concernée, tranchez entre trois options : basculer vers un Azure savings plan for compute, moderniser la VM, ou assumer le pay-as-you-go.
Passez un instant sur le calculateur de prix Azure pour chiffrer l’écart entre votre coût actuel et la cible :
Le calculateur de prix met les coûts côte à côte : de quoi éviter les mauvaises surprises en comité budget.
Étape 4 : vérifier le quota de la série cible
Avant de redimensionner, assurez-vous que votre abonnement dispose d’assez de quota pour la série visée. Ouvrez Subscriptions, sélectionnez votre abonnement, puis Usage + quotas :
Si le plafond est trop bas, cliquez sur Request increase pour demander une augmentation sur la série cible :
Étape 5 : redimensionner la VM
Dernière ligne droite. Le redimensionnement se fait en trois temps. Sur la VM, cliquez sur Stop pour la désallouer proprement avant :
Une fois la machine virtuelle arrêtée et désallouée, ouvrez le volet Size, choisissez la taille cible, validez avec Resize :
Une fois le redimensionnement réussi, cliquez sur Start pour redémarrer la machine :
Le piège classique : oublier que les données du disque temporaire et de la mémoire sont perdues à la désallocation. Les disques managés, eux, sont conservés. Prévenez donc les applications qui s’appuient sur le disque temporaire avant de lancer l’opération.
Mon retour terrain : planifiez ce chantier 6 mois avant chaque échéance, pas la veille. Alignez la bascule sur vos fenêtres de maintenance applicative et sur vos cycles d’achat de Savings Plan, et faites modéliser les coûts par votre équipe de compte Microsoft. Le faire dans l’urgence, c’est la garantie de payer plus cher et de casser quelque chose.
En résumé : les pièges à retenir
Voilà, en trois vagues, tout ce qui se joue sur vos anciennes VM Azure. Concrètement, qu’est-ce que vous devez garder en tête ?
Deux dates pivots : le 1er juillet 2026 (fin des RI 1 an, déjà passé, les RI 3 ans ayant même cessé dès 2025) et le 31 juillet 2026 (gel de capacité, imminent).
Previous-gen n’est pas retirée, mais capacity limited peut vous bloquer bien avant la date de retraite officielle.
Fin des RI n’est pas retraite de la VM : Dv3, Dsv3, Ev3 et Esv3 restent actives, seules leurs réservations s’arrêtent.
Le renouvellement automatique ne joue plus : à l’expiration, bascule silencieuse en pay-as-you-go.
La v6 impose des prérequis (NVMe, Génération 2, MANA) et une capacité régionale non garantie : testez avant.
À la désallocation, disque temporaire et mémoire perdus, disques managés conservés.
Le vrai message : aucune de ces vagues ne coupe vos VM du jour au lendemain, mais toutes récompensent ceux qui anticipent et punissent ceux qui attendent. Faites votre inventaire cette semaine, pendant que vous avez encore le temps de choisir plutôt que de subir.
Foncez auditer vos abonnements, et si cet article vous a fait gagner du temps, dites-le moi en commentaire.
Vous avez vu passer « Windows 365 Reserve » dans une release note, vous savez vaguement que ça dépanne quand un PC tombe en rade, mais vous n’avez jamais mis les mains dedans ? Cet article est fait pour vous. On part d’une licence trial fraîchement activée et on déroule, capture après capture, jusqu’au Cloud PC Reserve connecté depuis la Windows App.
Pour vous guider plus facilement dans cet article, voici des liens rapides :
1. C’est quoi Windows 365 Reserve, et à quoi ça sert ?
Windows 365 Reserve, c’est une déclinaison de Windows 365 pensée pour les utilisateurs qui travaillent d’habitude sur un PC physique. L’idée : leur fournir un Cloud PC de secours, de courte durée, quand leur machine principale n’est plus disponible. On reste dans la logique de continuité d’activité, on n’achète pas une licence Cloud PC plein temps « au cas où », on garde une réserve qu’on active uniquement quand le besoin tombe.
Concrètement, ça donne quoi ? Microsoft cible cinq scénarios :
Perte, vol ou casse de l’appareil
Retards de livraison de matériel
Pannes ou incidents cyber
Besoins de staffing temporaire
Environnements de test ou d’essai (le lab, justement)
Côté gestion, tout passe par Microsoft Intune : on prépare les policies à l’avance, et le jour J on provisionne en quelques clics.
Réserve Windows 365 est une version de Windows 365 conçue pour les utilisateurs qui travaillent principalement sur des PC physiques.
Il fournit aux organisations un accès flexible et à court terme à un PC cloud pour maintenir la productivité des employés lors d’interruptions inattendues.
Cette offre prend en charge la continuité d’activité en permettant un accès rapide et sécurisé aux PC cloud lorsque les appareils physiques ne sont pas disponibles.
Le principe d’abord. Windows 365 Reserve est un produit à part entière, avec une licence seulement disponible en annuel :
Attention : dans le centre d’administration Microsoft 365, vos licences Reserve s’affichent comme assignées à zéro utilisateur. C’est normal : elles s’appliquent au niveau du tenant et ne s’assignent pas comme une licence Microsoft 365 classique. Inutile de chercher à les coller sur un utilisateur depuis le portail M365.
Comme annoncé juste au dessus, on n’assigne pas cette licence dans la console d’administration Microsoft 365 :
La licence Reserve, elle, vient se rajouter par-dessus.
Alors comment on assigne ? Par la provisioning policy que l’on va créer sous Intune.
Quand vous créez une policy Reserve dans Intune et que vous lui affectez un groupe Entra, chaque membre du groupe reçoit une licence, tant qu’il reste assez de licences disponibles dans le tenant. Les règles à garder en tête :
Un utilisateur ne peut détenir qu’une seule licence Reserve à la fois.
Les 10 jours ne se partagent pas et ne se mutualisent pas entre utilisateurs : Microsoft conseille de prévoir une licence par utilisateur à couvrir.
Une fois son Cloud PC provisionné, sa licence ne peut plus être retirée ni réaffectée avant la fin du terme.
Le délai à anticiper : le Cloud PC d’un utilisateur ne devient éligible au provisioning que sept jours après l’affectation de sa licence. Ce délai ne s’applique que la première fois (ou après une interruption de couverture), et il se suit dans Intune sous la provisioning policy de l’utilisateur. D’où la règle d’or : on prépare et on assigne les policies bien en amont, pas le jour de l’incident.
La réaffectation, enfin : il n’y a pas de bouton « réassigner ». Tout se gère via l’appartenance au groupe Entra ou l’affectation du groupe à la policy. Et le comportement dépend de l’état du Cloud PC :
Licence non utilisée (Cloud PC jamais provisionné) : si vous retirez l’utilisateur de l’affectation, sa licence retourne au pool disponible du tenant et peut être redistribuée.
Licence utilisée (Cloud PC déjà provisionné) : si vous retirez l’utilisateur, la licence lui reste attachée jusqu’à la fin du terme et ne revient pas au pool.
Reste le piège des compteurs. Les 10 jours se décomptent dès le provisioning et se mettent en pause au deprovision. Un « jour » se mesure par tranches de 24 heures à partir de l’heure de provisioning, quel que soit le fuseau : toute fraction de journée passée provisionnée consomme la journée entière. Vous pouvez enchaîner les 10 jours d’un bloc ou les étaler sur l’année en jouant sur provisioning et deprovisioning.
Les jours non consommés expirent à la fin du terme, et à la disponibilité générale il n’y a ni cumul ni extension.
Attention : provisionnez à la demande, et déprovisionnez dès que l’utilisateur a récupéré sa machine. Chaque jour où le Cloud PC reste provisionné est décompté du crédit annuel, même s’il n’est pas utilisé.
3. Les pré-requis à poser avant de se lancer
Avant de créer quoi que ce soit, on vérifie le terrain. Voici le tableau à fixer en favori :
Brique
Ce qu’il vous faut
Licence
Windows 365 Reserve (jusqu’à 10 jours par an et par utilisateur)
Système d’exploitation
Windows 11 Enterprise ou Windows 10 Enterprise
Gestion
Microsoft Intune
Identité
Microsoft Entra ID P1
Rôle requis
Windows 365 administrator
Rôles recommandés
Intune administrator (rapports, fonctionnalités Intune), User administrator (groupes Entra)
Réseau et jonction
Pas d’Azure AD DS ni de domaine on-prem requis. Les Cloud PC Reserve sont toujours joints à Microsoft Entra, sur le Microsoft Hosted Network
Bonne nouvelle pour les setups modernes : pas de domaine Active Directory à traîner, pas de réseau Azure à câbler. Tout est Entra-joined sur le réseau hébergé par Microsoft. (Source : Managing Windows 365 Reserve, Microsoft Learn.)
4. Préparer le terrain : Intune, réseau, Entra
Quatre points à régler en amont, pour que le Cloud PC arrive déjà prêt à l’emploi le jour où on en a besoin :
Intune : appliquez vos policies et vos apps ciblées utilisateur, pour que le Cloud PC Reserve hérite des mêmes réglages que vos postes physiques.
Réseau : vérifiez que vos firewalls d’entreprise ne bloquent pas le service Windows 365 (voir les exigences réseau Windows 365).
Entra Join : assurez-vous que vos endpoints de jonction Microsoft Entra sont prêts.
Groupe Entra : créez (ou réutilisez) un groupe de sécurité qui servira à l’affectation de la provisioning policy.
Mon retour terrain : le groupe Entra dédié vaut le coup, même pour un lab. C’est lui qui pilote l’allocation des licences Reserve, et c’est tellement plus propre que de bidouiller des affectations à l’unité.
5. Créer la provisioning policy Reserve, pas-à-pas
La provisioning policy, c’est elle qui définit les réglages du Cloud PC : géographie, langue, type d’image. Et surtout, c’est en lui affectant un groupe Entra que vous allouez réellement les licences Reserve.
Attention : vous ne pouvez provisionner le Cloud PC d’un utilisateur que sept jours après lui avoir affecté sa licence. Créez et assignez vos policies bien avant le moment où vous en aurez besoin, sinon le jour de l’incident vous serez coincé par ce délai.
Dans Intune, allez dans Devices > Provision Cloud PCs et sélectionnez Create policy.
Sous Basics, saisissez un nom et une description.
Sous Experience, choisissez Access a full Cloud PC.
Sous License type, choisissez Reserve.
Choisissez la Geography des Cloud PC Reserve :
Changez l’image de la galerie si besoin :
Configurez une Device Preparation Policy (Autopilot DPP) :
Une fois activée, les applications et configurations requises sont appliquées pendant le provisioning, avant que l’utilisateur ne se connecte. Le Cloud PC affiche alors un statut Preparing le temps de la préparation.
Sélectionnez celle-ci dans votre police :
Sous Assignments, ajoutez vos groupes d’utilisateurs :
Vérifiez les réglages et sélectionnez Create :
Les Cloud PC de réserve apparaissent déjà, mais conservent pour le moment ce statut de non provisionnement :
Cela s’explique facilement, car c’est exactement à ce moment que le délai de sept jours commence :
Il ne nous reste plus qu’à patienter les sept jours afin de continuer nos tests. Mais avant cela, nous pouvons activer une autre option bien sympathique pour rendre les utilisateurs plus autonomes.
6. Laisser l’utilisateur se servir : le self-provisioning (Preview)
Par défaut, c’est l’IT qui provisionne les Cloud PC de réserve. Mais Microsoft propose aussi une option pour laisser l’utilisateur déclencher lui-même la création de son Cloud PC depuis la Windows App, sans attendre un ticket. De quoi accélérer la reprise quand chaque minute compte.
Attention : cette capacité est en Public Preview. Selon Microsoft, sa disponibilité future dépendra des résultats de cette préversion. Elle est désactivée par défaut et reste entièrement gouvernée par l’IT, à activer en connaissance de cause.
Côté admin, l’activation de cette option se fait ainsi. Dans Intune, allez dans Devices > Windows 365 > Settings et sélectionnez Create > Windows App settings :
Sous Basics, saisissez un nom et une description.
Sous Configuration settings, basculez Enable users to provision new Cloud PC instances sur Enabled :
Attention : petit garde-fou intégré, ce paramètre ne s’applique qu’aux groupes déjà assignés à une provisioning policy Reserve et licenciés pour Reserve. Pas de risque qu’il déborde sur le reste du parc.
Sous Assignments, ajoutez vos groupes d’utilisateurs :
Vérifiez les réglages et sélectionnez Create :
Côté utilisateur, une fois le réglage appliqué : il se connecte à la Windows App ou au web, voit une nouvelle carte d’appareil Set up my Cloud PC, la sélectionne, confirme via un message de consentement, et le provisioning démarre.
Un détail à ne pas zapper, même en self-service : la période de grâce de sept jours (le délai d’activation) s’applique toujours. Tant qu’elle n’est pas écoulée, à la première affectation de licence, l’utilisateur ne peut pas encore créer son Cloud PC, qu’il passe par l’IT ou par la Windows App.
Voici ce que ça donne côté IT, si l’on tente de provisionner avant la fin des sept jours :
Voici ce que ça donne côté utilisateur, si l’on tente de provisionner avant la fin des sept jours :
7. Provisionner côté IT (depuis Intune)
Le moment de vérité. Les Cloud PC Reserve se provisionnent toujours manuellement, à la demande.Avant toute nouvelle action, voici le même écran sept jours plus tard :
Ouvrez la provisioning policy, sélectionnez Cloud PC Users, choisissez un ou plusieurs utilisateurs, puis Provision :
Confirmez dans la boîte de dialogue :
Le processus de provisionnement se déclenche alors :
Le rapport sur Intune affiche également l’information de provisionnement :
Le Cloud PC passe alors en préparation :
Un détail des étapes de la DPP est disponible :
Une fois le provisionnement terminé, le Cloud PC de Réserve obtient le statut suivant :
Au besoin, il est même possible de comprendre et de relancer le provisionnement si ce dernier a rencontré une erreur :
8. Provisionner côté utilisateur (self-service)
Et quand c’est l’utilisateur qui provisionne lui-même (self-provisioning activé, voir la section 6), le déroulé côté Windows App ressemble à ça :
Le Cloud PC commence alors à se provisionner :
Comme lors du déclenchement par l’administrateur, le processus de provisionnement est aussi visible sur le portail Intune :
9. Se connecter au Cloud PC Reserve
Et là, magie : une fois provisionné, l’utilisateur accède à son Cloud PC depuis n’importe quel appareil.
Ouvrez la Windows App ou le client web sur n’importe quel appareil compatible (Windows, Mac, iOS, Android).
Connectez-vous avec les identifiants de l’organisation.
Filtrez par Windows 365 pour retrouver le Cloud PC Reserve une fois provisionné :
Depuis la carte d’appareil, lancez le Cloud PC :
Le Cloud PC de réserve s’ouvre bien, et on y trouve également les applications provisionnées par la policy Autopilot DPP :
10. Surveiller l’usage (rapports Intune)
Pour le suivi de toutes ces machines, tout est filtrable dans Intune.
Provisioning policies : filtre License Type = Reserve :
Rapports : dans la vue d’ensemble Windows 365, ouvrez le rapport Windows 365 Reserve licensing :
All Cloud PCs : filtre License Type = Reserve :
11. Rendre le Cloud PC (deprovision)
Pour rendre le Cloud PC (deprovision), côté admin depuis Intune, ou côté utilisateur via l’action Return dans la Windows App :
Allez dans Devices ou Cloud PC Users sous votre policy.
Sélectionnez un ou plusieurs Cloud PC et choisissez Deprovision now :
Confirmez dans la boîte de dialogue :
Le traitement de déprovisionnement commence alors :
Vérifiez que le statut repasse de Provisioned à Not provisioned :
Attention : le deprovision met en pause le compteur de jours, mais il supprime le Cloud PC et toutes les données non sauvegardées. Aucun snapshot, aucun délai de grâce, et il faut une action admin pour reprovisionner ensuite. Faites sauvegarder les données importantes avant de rendre la machine.
Voilà, en quelques étapes…
Voilà, en quelques étapes vous êtes passé d’une licence trial à un Cloud PC de secours connecté, prêt à dépanner un utilisateur dont le PC est out. Concrètement, ça donne quoi ? Une réserve de continuité d’activité que vous préparez une fois et que vous activez à la demande, sans gérer de PC de prêt ni de licence Cloud PC plein temps.
Les pièges à retenir :
Le délai de sept jours entre l’affectation de la licence et le premier provisioning : on prépare en avance, pas le jour de l’incident.
Le compteur de 10 jours tourne dès le provisioning : on provisionne à la demande.
Le deprovision (ou le Return côté utilisateur) supprime les données non sauvegardées, sans snapshot ni délai de grâce.
L’auto-provisioning depuis la Windows App et la Device Preparation Policy sont encore en Public Preview : à tester en lab avant de promettre quoi que ce soit en prod.
Foncez tester en lab : avec une licence trial, vous bouclez le parcours complet en une après-midi.