Opal sur Windows 365 : quand un agent IA dispose enfin d’un vrai poste de travail

Ces derniers mois, on parle beaucoup d’agents IA, d’automatisation et de “copilots capables d’agir”. Mais dans la réalité du terrain, dès qu’un processus sort des APIs bien propres et documentées, tout s’arrête très vite. Formulaires web sans connecteurs, portails fournisseurs legacy, applications internes sans automatisation possible… C’est exactement là que, jusqu’à présent, l’IA savait quoi faire… mais ne pouvait rien exécuter. C’est précisément ce fossé entre “savoir quoi faire” et “pouvoir le faire” qu’Opal vient combler.

Avec Opal, Microsoft franchit un cap important : pour la première fois, un agent IA ne se contente plus de raisonner ou de proposer des actions : il dispose d’un véritable poste de travail Windows pour les exécuter.

Dans cet article, je vous propose un retour sur Opal, son lien étroit avec Windows 365, son mode de fonctionnement, ses limites actuelles, et surtout dans quels cas d’usage réels cette approche prend tout son sens.

Qu’est-ce que le projet Opal dans Microsoft 365 Copilot ?

Annoncé durant l’Ignite 2025, Opal est une nouvelle capacité de Copilot orientée vers l’automatisation de tâches concrètes et complexes, au-delà de la simple génération de texte ou de réponses. Cette fonctionnalité expérimentale est disponible via le programme Frontier de Microsoft 365 Copilot.

Opal n’est pas un nouveau Copilot de plus :

Opal n’est ni un chatbot, ni un simple outil de RPA, ni une extension de Power Automate.
C’est un agent IA qui opère dans un environnement Windows réel, avec les mêmes contraintes qu’un utilisateur humain.

Pour faire simple, il s’agit d’un agent IA qui exécute pour vous des tâches réelles et multi-steps dans un environnement sécurisé, en utilisant un PC cloud Windows 365 pour interagir avec des applications web ou systèmes comme le ferait un humain (cliquer, remplir des formulaires, naviguer, etc.).

Toutes les organisations sont confrontées au défi des tâches manuelles répétitives, qui prennent un temps précieux et les détournent de leurs priorités stratégiques, de leur créativité et de leurs activités à fort impact.

Pensez au temps nécessaire pour rassembler des informations provenant de plusieurs sites et outils dans le cadre d’un audit de conformité, pour intégrer de nouveaux employés avec des commandes d’équipement et des accès au système, ou pour valider des bons de commande.

Toutes ces tâches importantes doivent être accomplies, et c’est précisément le type de travail pour lequel Opal a été conçu.

Microsoft Techcommunity

Microsoft met également une FAQ disponible juste ici.

Dans quels cas Opal peut être utile ?

Les entreprises disposent encore de dizaines d’applications sans API, sans connecteur et sans automatisation possible. Opal cible précisément ce vide. Quand aucune API n’existe, Power Automate s’arrête. Opal, lui, continue via l’interface utilisateur.

Opal n’est ni Power Automate, ni un RPA classique : c’est un agent IA capable d’interagir avec un PC cloud Windows 365 :

Dès qu’un processus nécessite de cliquer dans une application web ou legacy
Télécharger une facture depuis un portail fournisseur, la renommer, puis la déposer dans SharePoint est un scénario typique Opal.

Par contre, Opal n’est pas conçu pour les processus temps réel ni transactionnels critiques.

Quel est le lien entre Windows 365 et Opal ?

Microsoft 365 Copilot sait raisonner, analyser et décider, mais il ne peut pas exécuter d’actions réelles sans poste de travail. Le lien entre Windows 365 et Opal est alors fondamental : Opal a besoin d’un véritable environnement Windows pour pouvoir agir.

Les actions Opal sont exécutées dans un Cloud PC dédié, sans accès direct au poste de l’utilisateur. Le PC cloud Windows 365 sert donc d’environnement sécurisé et isolé pour les actions de l’agent.

On peut résumer l’architecture ainsi :

Windows 365 = le corps
Opal = les mains
Copilot = le cerveau

Ici, Windows 365 fournit à votre IA :

une isolation complète du poste de l’utilisateur
un PC cloud dédié à l’agent IA
un navigateur Edge réel
un système de fichiers Windows
une session utilisateur contrôlée
une identité Microsoft Entra associée

Pourquoi Microsoft n’utilise pas un simple navigateur sandbox ?

Un simple navigateur sandboxé ne permet pas de couvrir les scénarios ciblés par Opal.
Opal n’est pas conçu pour exécuter une action isolée, mais pour enchaîner des tâches complexes, multi-applications et persistantes dans le temps.

Les agents Opal doivent parfois :

télécharger et stocker des fichiers localement,
ouvrir et manipuler des fichiers Excel, PDF ou CSV,
interagir avec plusieurs onglets et fenêtres,
conserver un état entre plusieurs étapes,
utiliser une identité utilisateur complète (cookies, sessions, certificats),
fonctionner avec des extensions navigateur ou des paramètres Edge spécifiques.

Un navigateur isolé et éphémère ne permet pas cela de manière fiable. Un système d’exploitation Windows complet est donc nécessaire pour garantir la continuité, la stabilité et la sécurité de l’exécution.

À quoi à accès Opal sur ces postes Windows 365 ?

Par défaut, Opal n’a accès à aucun site web.

Toute navigation sortante est bloquée tant qu’aucune URL n’a été explicitement autorisée dans le portail d’administration Opal. Sans cette configuration :

l’agent ne peut pas ouvrir de site web,
il ne peut pas effectuer de recherche internet,
il ne peut pas se connecter à une application SaaS.

Ce modèle repose sur une approche deny by default, essentielle pour limiter le périmètre d’action de l’agent IA et éviter toute dérive ou accès non maîtrisé.

Chaque URL autorisée devient ainsi un périmètre fonctionnel clairement défini pour l’agent Opal.

Quels sont les prérequis pour activer Opal sur son tenant ?

Les prérequis exacts ne sont pas encore officiellement figés par Microsoft. À ce jour, Opal est uniquement disponible :

dans le cadre du programme Microsoft 365 Copilot Frontier,
avec une licence Microsoft 365 Copilot active pour les utilisateurs concernés.

Les dépendances techniques observées incluent également :

Microsoft Intune (gestion des Cloud PC),
Windows 365 (provisionnement des postes agents),
Microsoft Entra ID (identité et accès),
Microsoft Graph (onboarding automatisé).

Combien coûte Opal ?

Microsoft n’a communiqué aucun tarif dédié pour Opal à ce stade. Opal n’est pas facturé comme une licence distincte.

Il est inclus, pour le moment, comme fonctionnalité expérimentale du programme Frontier, accessible uniquement avec une licence Microsoft 365 Copilot valide.

Le coût indirect à prendre en compte reste principalement :

les licences Windows 365 associées aux Cloud PC agents,
les licences Intune,
et la licence Microsoft 365 Copilot par utilisateur.

Où les utilisateurs trouvent-ils Opal ?

Les utilisateurs ne trouvent pas Opal comme une application classique dans leur menu Microsoft 365. Opal apparaît dans l’interface Copilot, une fois que l’administrateur a activé la fonctionnalité sur le tenant.

L’URL directe est https://opal.frontier.microsoft365.com peut aussi être utilisée.

Pas de promesses marketing ici : uniquement ce que j’ai pu tester, observer et configurer moi-même sur un tenant Microsoft 365 étape par étape :

Etape 0 – Rappel des prérequis :

Avant toute chose, assurez-vous :

d’avoir accès au programme Frontier,
de disposer d’un compte Administrateur général,
d’avoir Intune et Windows 365 fonctionnels sur le tenant,
d’avoir des licences Microsoft 365 Copilot assignées.

Etape I – Configuration du tenant :

Connectez-vous au portail d’administration de Microsoft 365, et depuis le menu de gauche, ouvrez les paramétrages de Copilot, puis sélectionnez Opal (Frontier) dans la liste des fonctionnalités Copilot :

Dans le panneau de configuration Opal, l’option Specific user groups permet de restreindre l’accès à Opal à des groupes Microsoft Entra ID précis, puis sauvegardez :

Etape II – Configuration d’Opal :

Puis cliquez ici pour vous rendre sur le portail d’administration d’Opal afin de continuer la suite de la configuration.

https://opal.frontier.microsoft365.com/admin

Si le message suivant apparaît, vérifiez que vous êtes bien authentifié avec un compte administrateur général, attendez quelques minutes, puis revenez sur le même portail :

Une fois sur le portail d’administration d’Opal, avant d’aller plus loin, prenez le temps de lire le message d’avertissement affiché en évidence :

Afin de mettre en route Opal sur votre tenant Microsoft, téléchargez le script PowerShell suivant via un clic droit :

Le script OpalOnboard.ps1 automatise l’onboarding d’Opal dans un tenant Microsoft 365 via Microsoft Graph, il :

installe/charge les modules Microsoft Graph nécessaires, puis se connecte à Graph avec des droits d’admin,
crée (si absents) 8 service principals (Opal, Windows 365, AVD, Windows Cloud Login, etc.) pour que le tenant ait les identités applicatives requises,
crée un groupe dynamique de devices (“Opal App Device Group”) basé sur une règle de type enrollmentProfileName == « Windows 365 Opal Device Pool »,
configure le service principal “Windows Cloud Login” pour activer le RDP et cibler ce groupe de devices,
télécharge une policy Edge au format JSON depuis une URL Microsoft, la crée côté Intune (Settings Catalog), puis assigne la policy au groupe de devices.

Sur votre poste local, installez et ouvrez PowerShell 7 :

winget search --id Microsoft.PowerShell

Ouvrez PowerShell 7 avec les droits d’administrateur, exécutez le script, confirmez l’action d’exécution, puis laissez-vous guider :

.\OpalOnboard.ps1

Après l’installation de module, le script se connecte à votre tenant grâce à un compte d’administrateur :

Acceptez les permissions nécessaires :

Si l’erreur suivante apparaît, fermez puis rouvrez simplement PowerShell :

Confirmez les actions d’exécution de création :

Création de principaux de services, si absents :
- 03b184b5-8cb6-45d1-bef1-10db52790f06 Opal – Primary App
- 90c719d1-2849-4e57-a1d1-0c9edb406be2 Opal Native (On-box agent)
- 0af06dc6-e4b5-4f28-818e-e78e62d137a5 Windows 365
- 9cdead84-a844-4324-93f2-b2e6bb768d07 Azure Virtual Desktop
- a85cf173-4192-42f8-81fa-777a763e6e2c AVD Client
- 50e95039-b200-4007-bc97-8d5790743a63 AVD ARM Provider
- 270efc09-cd0d-444b-a71f-39af4910ec45 Windows Cloud Login
- 351add99-7ff7-4e1f-870f-f98b509209c2 Cloud Device Platform

Création d’un groupe dynamique de machines :
- Nom ame: Opal App Device Group
- Type: groupe de sécurité
- (device.enrollmentProfileName -eq « Windows 365 Opal Device Pool »)

Configuration du Windows Cloud Login avec notre nouveau groupe de machines :

Création de la police Microsoft Edge via Intune :

Assignation de la police au groupe dynamique de machines :

Une fois le processus correctement terminé, le message suivant apparaît :

Si cela n’est pas automatique, cliquez sur le bouton de rafraîchissement afin de constater la validation de cette étape :

Enfin, lancez la dernière étape d’onboarding :

Attendez quelques minutes la fin de l’étape suivante :

Quelques minutes plus tard, constatez le succès final de l’étape d’onboarding, puis cliquez sur Suivant :

Une fois l’onboarding technique terminé, vous devez configurer le pool de Cloud PC Windows 365 qui sera utilisé par Opal pour exécuter les tâches.

Etape III – Configuration du pool de machines Windows 365 :

Quelques points importants à retenir :

Le Cloud PC est le poste de travail de l’agent Opal, pas celui de l’utilisateur.
Toutes les actions (navigation, clics, téléchargements) sont exécutées dans ces Cloud PC Windows 365.
Les restrictions d’accès aux sites web permettent de contrôler précisément le périmètre d’action de l’agent.

Cette étape se réalise encore depuis le portail d’administration Opal.

Cette première section permet de définir où seront hébergés les Cloud PC et combien de machines Windows 365 seront créées. Il est recommandé d’utiliser la même région que vos utilisateurs Microsoft 365 :

La création du pool de machines peut prendre plusieurs minutes. Vous pourrez suivre l’état d’avancement directement dans cette section. Ce pictogramme vous indique l’état en cours du provisionnement, ou du re-provisionnement quand un traitement Opal est terminé :

Environ 30 minutes plus tard, les machines Windows 365 sont provisionnées sur votre tenant :

Vous pouvez même retrouver ces nouvelles machines Windows 365 sur votre portail Intune :

Le modèle de machines Windows 365 est d’ailleurs spécifique à ce service d’IA :

Comme attendu, le groupe dynamique de machines Windows 365 regroupe bien celles-ci :

Et la police créée via le script d’onboarding s’affecte bien sur les machines Windows 365 :

De retour sur la console d’administration, ajoutez le ou les sites auxquels les machines auront accès pour effectuer leurs tâches. Dans mon test, je vais ajouter le site suivant :

https://computerusedemos.blob.core.windows.net

L’écran Starters permet de créer des actions prédéfinies proposées aux utilisateurs d’Opal. Un starter correspond à une instruction prête à l’emploi, associée à un site web précis, que l’utilisateur pourra lancer en un seul clic :

Une fois un premier Starter créé, cliquez sur Suivant :

Microsoft recommande de créer un profil Enrollment Status Page (ESP) personnalisé, spécifiquement pour les machines Opal. Ce profil permet notamment de :

réduire le temps d’initialisation du Cloud PC,
éviter les écrans ESP bloquants,
empêcher l’attente d’applications non nécessaires.

Le profil ESP doit être assigné aux appareils correspondant au pool Opal, à l’aide du critère :

enrollmentProfileName = "Windows 365 Opal Device Pool"

Une fois la configuration entièrement complétée, cliquez ici pour terminer le processus :

La suite consiste désormais à créer vos premiers scénarios métier afin de transformer Opal en véritable agent opérationnel capable d’exécuter des tâches concrètes sur des applications web réelles.

Etape IV – Premiers tests d’Opal :

L’URL pour utiliser Opal est celle-ci :

https://opal.frontier.microsoft365.com

Il est aussi possible de retrouver Opal depuis la page d’accueil de Copilot :

Sur Opal, saisissez le prompt suivant afin d’effectuer plusieurs actions, puis cliquez sur Démarrer :

Navigate to https://computerusedemos.blob.core.windows.net/web/Contoso/invoice-manager.html. Filter the invoices by selecting "Last 24 Hours" to find the most recent invoice. Open the PDF of the most recent invoice. In a new browser tab, go to:
https://computerusedemos.blob.core.windows.net/web/Contoso/index.html Fill out the invoice submission form using the data extracted from the PDF. Submit the form without asking for confirmation.

Opal commence par se connecter à une des machines Windows 365 préalablement provisionnées :

Opal attend ensuite que Windows 11 finalise sa configuration OS :

Si besoin, cliquez sur l’image de la VM pour avoir plus de détail. Comme ici, Edge s’ouvre et affiche le site web contenant les factures :

La dernière facture est ouverte pour y récupérer toutes les informations :

Un nouvel onglet s’ouvre dans Edge afin de saisir la nouvelle facture dans le système de comptabilité :

Une fois la saisie complète, une notification apparaît à la fin du traitement de saisie :

Opal compare l’état obtenu aux actions demandées :

Une dernière phase de revue est déclenchée afin que l’utilisateur puisse contrôler le travail effectué :

L’utilisateur n’a qu’à confirmer pour que le travail soit considéré comme terminé :

Afin de vous faire une meilleure idée du traitement effectué par Opal, le voici en fonctionnement :

Etape V – Quelques remarques sur Opal :

Au travers de différents tests, plusieurs points méritent d’être soulignés :

Sans finalisation de la configuration d’Opal, le message suivant apparaît pour les utilisateurs :

Sans licence Microsoft 365 Copilot, l’accès à Opal retourne une erreur 403 :

Après chaque traitement, la machine Windows 365 utilisée est réinitialisée et repart sur un état propre :

Il faut attendre environ 15 minutes avant que la machine soit de nouveau disponible pour un autre traitement :

Le bouton Pause permet de suspendre temporairement l’exécution sans annuler le scénario, tout en conservant le contexte courant. Cela est très utile si l’utilisateur souhaite reprendre la main quand l’agent part dans une mauvaise direction :
- l’agent arrête immédiatement d’exécuter des actions (clics, saisies, navigation, appels d’outils)
- le contexte et l’état courant sont conservés (où il en est dans la tâche)

Opal peut décider de s’arrêter de lui-même s’il rencontre une situation ambiguë ou non résoluble, et attend alors une instruction humaine.

Durant la phase de traitement d’Opal, 3 autres actions sont possibles :
- Répéter la requête initiale : Cette action relance exactement le même job depuis le début, en réutilisant la requête initiale, les mêmes instructions et le même contexte de départ. C’est comme cliquer sur “Rejouer le scénario”, sans modifier quoi que ce soit.
- Terminer le travail : Cette action met fin au job en cours et empêche toute poursuite de ce run, mais le job reste disponible dans l’interface.
- Supprimer le travail : Le job n’est plus visible ni relançable, mais cela ne désactive pas automatiquement un trigger externe (mail, événement, etc.) s’il existe.

Conclusion

Opal marque une rupture importante dans l’approche de l’automatisation chez Microsoft.
Là où Power Automate s’arrête faute d’API, Opal continue grâce à un véritable poste de travail Windows 365 piloté par une IA.

Nous ne sommes plus dans la simple génération de contenu, mais dans l’exécution réelle de tâches métier, au plus proche du travail humain.

Les premiers usages montrent un potentiel considérable, à condition de bien cadrer les périmètres, les accès et les scénarios. On ne parle pas encore d’autonomie totale, mais d’un changement profond dans la manière dont une IA peut interagir avec des systèmes existants.

Opal n’est pas encore prêt pour des processus critiques temps réel, mais il ouvre clairement la voie à une nouvelle génération d’agents opérationnels.

Créez des alertes Advisor pour vos instances réservées Azure

Les services de calcul représentent souvent l’essentiel des coûts sur Azure. Pour les charges de travail qui fonctionnent en continu, les instances réservées apportent une réduction notable des tarifs à la carte. En s’engageant sur une durée d’un ou trois ans, il est possible de réaliser jusqu’à grosses économies par rapport au modèle pay‑as‑you‑go. Mais est-on alerté quand ces réductions sont disponibles pour notre environnement Azure, ou qu’elles expirent ?

Dans cet article, nous revenons sur le fonctionnement des instances réservées, leur gestion (notamment le renouvellement automatique) et sur la création d’alertes Azure Advisor pour être notifié lorsqu’une réservation devient pertinente ou expire.

Qu’est-ce qu’une instance réservée Azure ?

Une instance réservée est un engagement de capacité : vous acceptez d’utiliser un type d’instance ou une famille d’instances dans une région spécifique pendant une durée déterminée, en échange d’un prix réduit. Les réservations s’achètent pour un an ou trois ans :

Quand acheter une réservation ?

Les instances réservées sont particulièrement adaptées aux charges stables et prévisibles. La documentation Microsoft recommande d’opter pour une réservation lorsque vous prévoyez d’utiliser le même type d’instance ou la même famille dans une région donnée pendant toute la durée de l’engagement.

À l’inverse, si vos applications changent fréquemment de configuration ou de région, les savings plans peuvent être plus appropriés car ils s’appliquent à un montant horaire sur plusieurs services et régions. Néanmoins, une instance réservée reste l’option la plus économique lorsque son utilisation est maximale.

Que doit-on faire pour appliquer la remise ?

Une fois la réservation achetée, la remise est appliquée automatiquement aux machines virtuelles, SQL Database, Cosmos DB ou d’autres services éligibles qui correspondent aux attributs choisis (SKU, région, étendue).

Les réservations n’affectent pas l’état d’exécution des ressources : si une machine est mise à l’arrêt ou redimensionnée, le rabais se reporte sur une autre ressource compatible, sinon la portion inutilisée est perdue :

Quid d’une machine virtuelle dont la taille varie ?

Une instance réservée s’applique sur une famille de machines virtuelles : même si le SKU d’une RI correspond à un SKU spécifique d’une VM, il peut s’appliquer à d’autres tailles d’une même famille via un ratio :

Le tableau ci-dessus affiche des instances réservées pour des machines virtuelles. Comment fonctionne une instance réservée ? Il faut simplement voir celle-ci comme une place de parking, louée pour un ou trois ans chez Microsoft :

Il est donc possible d’optimiser votre réservation pour la flexibilité de taille. Dans ce mode, la remise s’applique à toutes les tailles d’instances d’un même groupe. Par exemple, une réservation achetée pour une instance de la série DSv2 (par exemple Standard_DS3_v2) peut s’appliquer aux autres tailles de ce groupe : Standard_DS1_v2, Standard_DS2_v2, Standard_DS3_v2 et Standard_DS4_v2

Quid de la durée et la fréquence de paiement ?

Le choix de la durée dépend de la stabilité de votre charge. Les engagements d’un an offrent plus de flexibilité tandis que les engagements de trois ans maximisent les économies. Vous pouvez régler la réservation en une seule fois ou mensuellement ; le coût total reste identique et aucune pénalité n’est appliquée en cas de paiement échelonné, sauf le taux de change qui varie dans le temps :

Qu’est-ce qui n’est pas couvert par la RI ?

La remise porte uniquement sur les coûts de calcul. Pour les machines virtuelles, elle concerne les cœurs et la mémoire mais ne couvre pas les licences Windows ni les frais de stockage, réseau ou logiciels.

Les licences peuvent être prises en charge via l’Azure Hybrid Benefit, et les autres coûts sont facturés séparément. En revanche, de nombreux services Azure disposent de capacités réservées pour réduire leurs propres coûts de calcul.

Qu’est-ce qu’Azure Hybrid Benefit ?

Azure Hybrid Benefit est un avantage en matière de licences qui vous permet de réduire considérablement les coûts d’exécution de vos charges de travail dans le cloud. Son fonctionnement consiste à vous autoriser à utiliser vos licences Windows Server et SQL Server compatibles sur Azure.

Il est donc possible d’acheter des licences en souscriptions annuelles ou pluriannuelles. Les économies représentent des sommes non négligeables.

Cet avantage permet donc d’utiliser les licences Windows Server ou SQL Server existantes éligibles, et ainsi de ne payer que le tarif de base des machines virtuelles.

Que se passe-t-il à la fin du contrat de la RI ?

Lorsque vous achetez une réservation, le renouvellement automatique est souvent activé par défaut. Cette fonction permet de racheter automatiquement une réservation équivalente à l’expiration de la précédente, afin de continuer à bénéficier de la remise sans surveillance quotidienne.

Vous pouvez activer ou désactiver cette option à tout moment dans le portail Azure. Le prix du renouvellement est disponible 30 jours avant la date d’expiration. Si la réservation n’est pas renouvelée, vos ressources continuent de fonctionner, mais elles repassent en facturation à l’usage.

Peut-on annuler une instance réservée en cours d’engagement ?

Oui, Microsoft permet l’annulation d’une RI pendant sa durée d’engagement, sous conditions :

Les remboursements sont calculés en fonction du prix le plus bas de votre prix d’achat ou du prix actuel de la réservation.

Nous ne facturons actuellement aucun frais de résiliation anticipée, mais des frais de résiliation anticipée de 12 % pourraient s’appliquer à l’avenir en cas d’annulation.

L’engagement total annulé ne peut pas dépasser 50 000 USD dans une période de 12 mois pour un profil de facturation ou une inscription unique.

Microsoft Learn

Voici un exemple donné par Microsoft :

Lorsqu’une réservation est échangée ou annulée, le remboursement est calculé en fonction du nombre de jours restants dans la période de réservation. Le calcul est effectué au format UTC et utilise une formule cohérente pour garantir l’équité et la transparence.

Par exemple, si vous avez acheté une réservation le 10 juillet 2024 et que vous l’avez échangée le 9 juillet 2025, seulement 1 jour reste dans la réservation. Vous recevrez un petit remboursement pour ce seul jour.

Instances réservées vs. Savings Plan ?

Bien que les savings plans partagent l’objectif de réduire les coûts, ils fonctionnent différemment. Une instance réservée vous engage sur un type ou une famille d’instances dans une région donnée et vous apporte la remise la plus élevée lorsque vos machines fonctionnent en continu.

À l’inverse, un savings plan fixe un montant horaire applicable sur plusieurs services de calcul et dans toutes les régions. Cette flexibilité est utile pour les charges de travail qui évoluent et qui se déplacent entre régions, mais les économies sont généralement moindres que celles d’une instance réservée utilisée à 100 %.

Dans la majorité des cas, un utilisateur qui connaît ses besoins à moyen terme gagnera à privilégier la réservation et à activer le savings plan seulement pour les charges variables.

Qu’est-ce qu’Azure Advisor ?

Azure Advisor est un assistant cloud personnalisé qui analyse en continu ta configuration Azure et ton usage pour te fournir des recommandations proactives afin d’optimiser :

la fiabilité
la sécurité
la performance
les coûts
l’excellence opérationnelle

Peut-on y créer des alertes concernant le besoin de RI ?

Comme montré dans une copie d’écran plus haut, Azure Advisor affiche des conseils sur les économies financières possibles sur votre infrastructure Azure. Ces conseils portent également sur l’achat d’instances réservées pour vos services de calcul.

Azure Advisor analyse l’utilisation de vos ressources et émet donc des recommandations lorsqu’il détecte des économies potentielles.

Lorsque Advisor identifie une nouvelle recommandation (par exemple l’achat d’une instance réservée), un événement est enregistré dans le journal d’activité. Il est possible de déclencher une alerte à chaque nouvelle recommandation afin d’être averti par courriel ou via un webhook :

Comme vous pouvez le voir, j’ai créé cette nouvelle alerte sur le type de recommandation suivant :

Consider virtual machine reserved instance to save over the on-demand costs

Comme les alertes configurées dans Azure Monitor, un groupe d’action peut y être affecté :

Une fois l’alerte en place, chaque nouvelle recommandation Advisor se traduira par une notification. Cela vous permet d’acheter les réservations appropriées dès qu’elles sont pertinentes et de réagir lorsque l’une d’elles arrive à expiration.

Ayant configuré une adresse email sur ce groupe d’action, et une fois l’alerte déclenchée, l’email suivant me parvient :

Un clic sur le lien présent dans l’email nous affiche la recommandation concernée dans le portail Azure :

Il ne me reste plus alors qu’à acheter, ou racheter, l’instance réservée appropriée 😎

Conclusion

La maîtrise des coûts est un volet essentiel de l’architecture cloud. En engageant vos ressources sur une durée ferme, les instances réservées vous permettent de réduire significativement vos dépenses tout en conservant la flexibilité de changer de taille ou d’échanger votre réservation en cas d’évolution de vos besoins.

Les fonctionnalités de renouvellement automatique garantissent la continuité des remises, et les alertes Azure Advisor vous aident à prendre les bonnes décisions au bon moment. En combinant analyse de l’utilisation (Advisor), estimation des coûts (calculateur de tarification) et stratégie d’engagement, vous disposez de tous les outils pour optimiser votre facture Azure.

Windows 365 Link : Découverte

Depuis plusieurs mois, je souhaitais pouvoir Windows 365 Link dans des conditions réelles d’utilisation. Cette opportunité m’a enfin permis de prendre le temps d’analyser la solution de manière concrète, au-delà des annonces marketing et des fiches techniques. L’objectif de cet article est de décortiquer Windows 365 Link sous différents angles : technique, licences, intégration à l’écosystème Microsoft, mais aussi usage quotidien.

Au fil des tests, j’ai cherché à comprendre dans quels scénarios ce type d’appareil apporte une réelle valeur, et dans quels cas d’usage il montre ses limites.

Cet article se veut à la fois factuel et basé sur un retour d’expérience, afin d’apporter une vision pragmatique de Windows 365 Link et de son positionnement dans une stratégie de poste de travail cloud.

Pour vous guider plus facilement dans cet article très long, voici des liens rapides :

FAQ :

Test Windows 365 Link :

Commençons par le tout début. Il était une fois… Windows 365 Link.

Qu’est-ce que Windows 365 Link ?

En quelques mots, Windows 365 Link est un thin client qui permet de se connecter directement à un Cloud PC Windows 365, vous offrant ainsi un moyen sécurisé et simple d’accéder à votre environnement cloud.

Windows 365 Link est le premier appareil matériel pc cloud qui permet aux utilisateurs de se connecter directement à leur machine virtuelle Cloud PC. Il s’agit d’une solution de pile complète et spécialement conçue par Microsoft.

Microsoft Learn

Lorsque les utilisateurs se connectent à leur Windows 365 Link, ils sont connectés à leur machine virtuelle PC Windows 365 Cloud via le service Windows 365.

Microsoft Learn

Nerdio illustre, à l’aide d’un schéma simple, la manière dont Windows 365 Link s’intègre à l’écosystème cloud de Microsoft

Quelles sont ses caractéristiques techniques ?

Windows 365 Link mesure 120 × 120 × 30 mm pour un poids de 418 grammes, et est compatible VESA 100 et verrous Kensington. De plus, il dispose des connectivités suivantes :

Sans fil :
- Wi-Fi 6E
- Bluetooth 5.3
Face avant :
- USB-A (USB 3.2)
- Prise audio jack
Face arrière :
- USB-C (USB 3.2)
- DisplayPort (1.4a, jusqu’à 4k 60 Hz)
- HDMI (2.0b, jusqu’à 4k60)
- Ethernet (1.0 Gbit/s)
- Alimentation électrique (65 watts)
- Unified Extensible Firmware Interface (UEFI) pour la réinitialisation

Côté matériel et logiciel, on retrouve les éléments suivants :

Hardware :
- Processeur Intel N250
- 8 Go LPDDR5
- 64 Go de stockage flash
- Puce TPM 2.0
Software :
- Système d’exploitation dédié (Windows CPC)
- Secure Boot
- Virtualization-based security
- Hypervisor-protected Code Integrity
- BitLocker
- Stratégie de contrôle strict des applications
- Aucun utilisateur local disposant de droits d’administration
- Aucun stockage de données local
- Aucune application locale
- Stratégies de sécurité de base activées par défaut
- Sonde EDR Microsoft Defender

Durant mes tests, j’ai relevé plusieurs niveaux de consommation électrique instantanée :

Mire d’authentification ouverte : 4,48 W
Session Windows 365 ouverte inactive : 7,36 W
Application graphique ouverte : 8,89 W
Appel Teams ouvert : 7,51 W

Voici d’ailleurs le document PDF de Microsoft reprenant les caractéristiques techniques de Windows 365 Link :

windows-365-link-data-sheet Télécharger

À quoi sert-il ?

Windows 365 Link est conçu pour offrir un accès direct, sécurisé et dédié à un PC Cloud Windows 365, sans exécuter de système Windows local complet. L’objectif n’est pas de remplacer un PC traditionnel, mais de proposer un point d’accès matériel minimaliste, fortement intégré aux services Microsoft Entra ID, Intune et Windows 365.

En quoi est-il différent d’un PC pour accéder à Windows 365 ?

Contrairement à un PC Windows traditionnel, Windows 365 Link ne stocke pas de données utilisateur localement et ne permet pas d’exécuter d’applications hors du PC Cloud. Toute l’expérience utilisateur est déportée dans le Cloud PC, ce qui contribue à réduire la surface d’attaque locale et simplifie considérablement l’administration du poste.

Windows 365 Link peut-il remplacer un thin client tiers ?

Windows 365 Link se rapproche fonctionnellement d’un thin client, mais avec une intégration native et exclusive à Windows 365.

Il ne vise pas la polyvalence fonctionnelle (VDI multiples, accès Linux ou AVD générique), mais une expérience optimisée et contrôlée pour Windows 365 uniquement. Cela en fait un choix pertinent dans des environnements standardisés, mais plus restrictif que certaines solutions tierces.

Attention, ce point a déjà été mentionné à plusieurs reprises, mais mérite d’être rappelé : Windows 365 Link ne prend pas en charge Azure Virtual Desktop ni Microsoft Dev Box.

Dans quels scénarios est-il le plus pertinent ?

Windows 365 Link est particulièrement adapté aux environnements à postes partagés, aux scénarios Frontline, aux centres de contact, aux environnements industriels ou aux sites distants où la simplicité de déploiement, la sécurité et la rapidité de remplacement du matériel sont prioritaires.

Voici quelques exemples de cas d’usage :

Postes partagés

Permettre aux collaborateurs en mode hybride de retrouver instantanément leur environnement de travail
Accès rapide et sécurisé à leur Cloud PC Windows 365, sans dépendance au poste physique
Idéal pour les environnements à forte rotation d’utilisateurs ou à postes non attribués

Centres d’appels

Démarrage en quelques secondes vers un Cloud PC Windows 365
Expérience utilisateur fluide et réactive, adaptée aux usages intensifs (voix, CRM, applications métiers)
Aucune donnée stockée localement sur le terminal, réduisant les risques de fuite d’informations
Authentification sans mot de passe via Microsoft Entra ID

Espaces spécialisés

Accès sécurisé aux outils et aux données dans des environnements contrôlés
Utilisation dans des lieux spécifiques tels que :
- laboratoires
- zones logistiques ou arrière-boutiques
- centres de formation
- accueils et réceptions

Frontline et métiers spécifiques

Mise à disposition d’un poste de travail Cloud sécurisé pour :
- travailleurs de première ligne en milieu industriel
- agents d’accueil
- personnels en environnement scientifique ou de recherche
Réduction des contraintes matérielles locales et simplification du support

Métiers à forte sensibilité des données

Accès distant sécurisé pour des profils tels que :
- analystes financiers
- consultants
- chargés de clientèle bancaire
- agents de support client
- téléconseillers / télévendeurs
Centralisation des données dans le Cloud PC, limitant les risques de fuite ou de perte

Dans quels cas n’est-il pas recommandé ?

Windows 365 Link est peu adapté aux utilisateurs nomades, aux scénarios nécessitant un fonctionnement hors ligne, ou aux usages impliquant des applications locales spécifiques ou des périphériques avancés non pris en charge. Il n’est pas non plus destiné à remplacer un poste de travail puissant pour des usages lourds locaux.

De ce fait, la comparaison entre Windows 365 Link + Cloud PC et un ordinateur portable moyen de gamme peut soulever des questions économiques :

Critère	Laptop moyen de gamme	Windows 365 Link + Windows 365
Coût matériel initial	~800 € (laptop)	365 € (Windows 365 Link)
Durée de vie	3–4 ans	4–5 ans (device statique)
Coût licence Windows 365	0 €	60 €/mois → 2 160 € sur 3 ans
Déploiement initial	Imaging, drivers, apps	Provisioning automatique
Support & maintenance (3 ans)	30 h × 60 €/h = 1 800 €	30 h × 30 €/h = 900 €
Données locales	Oui	Non
Exposition en cas de perte/vol	Élevée	Très faible (données Cloud)
Continuité de service	Dépend du matériel	Reconnexion immédiate
Coût total estimé sur 3 ans	~2 600 €	~3 425 €
Lecture du ROI	Référence	Surcoût ~825 € / poste sur 3 ans

Windows 365 n’est donc pas nécessairement moins coûteux par défaut, le ROI devient positif si :

Postes partagés / Frontline / hot desk
Réduction forte du support de proximité
Exigences sécurité élevées
Besoin de remplacement immédiat du poste

Sinon, sur poste dédié standard, l’ordinateur portable reste économiquement plus avantageux.

Permet-il de réduire les coûts IT et le provisioning ?

Dans les usages recommandés listés plus haut, Windows 365 Link peut contribuer à une réduction des coûts liés au support, au renouvellement matériel et à la gestion des images système. En revanche, il renforce la dépendance au modèle de licences Windows 365, qui doit être évalué globalement dans la stratégie poste de travail.

Windows 365 Link simplifie le provisioning, le remplacement des appareils et l’exploitation quotidienne grâce à l’enrôlement automatique Entra ID et Intune. L’administration est centralisée, avec moins d’interventions locales, ce qui facilite la standardisation et la gouvernance du poste de travail.

Quels sont ses bénéfices de sécurité ?

L’absence de données persistantes locales, l’authentification systématique via Microsoft Entra ID et l’intégration native avec les stratégies d’accès conditionnel renforcent la posture de sécurité globale. En cas de perte ou de vol du matériel, aucune donnée utilisateur n’est exposée localement.

En centralisant l’exécution et les données dans le Cloud PC, Windows 365 Link limite les impacts d’incidents matériels, de compromission locale ou de mauvaise configuration utilisateur. La gestion centralisée via Intune permet également d’appliquer des politiques de sécurité homogènes et cohérentes.

Quels sont les licences nécessaires pour l’utiliser ?

Voici les exigences connues pour pouvoir utiliser Windows 365 Link :

Exigences de licence Windows 365
Exigences Microsoft Entra ID
Exigences Microsoft Intune

Prenons le temps de comprendre en détail toutes ces exigences.

Exigences de licence Windows 365 :

Windows 365 Link n’introduit aucune nouveauté du côté des licences. On reste strictement dans le périmètre Windows 365.

Sans licence Windows 365 valide assignée à l’utilisateur, votre Windows 365 Link n’est pas utilisable : la connexion à un autre PC est tout simplement impossible, même à un environnement Azure Virtual Desktop.

À noter que Windows 365 Link accepte tous les types de licences Windows 365 :

Windows 365 Entreprise
Windows 365 Business
Windows 365 Frontline

Exigences Microsoft Entra ID :

Avec Windows 365 Link, un point apparaît rapidement comme non négociable : Windows 365 Link doit être Microsoft Entra joined ou Entra hybrid joined.

L’utilisateur qui effectue cette jonction doit bien évidemment avoir les droits pour joindre des appareils au tenant :

Lors de la jonction à Entra ID, le device s’enrôle automatiquement dans Intune. Et là, point important : l’utilisateur qui joint le device doit disposer d’une licence Microsoft Entra ID Premium, sinon l’enrôlement automatique échoue.

L’enrôlement automatique dans Intune dépend du paramétrage suivant :

Exigences Microsoft Intune :

L’enrôlement Intune des Windows 365 Link se fait pendant l’OOBE, sans action manuelle supplémentaire grâce aux mécanismes d’Entra.

Là encore, l’utilisateur qui joint le Windows 365 Link doit :

Disposer d’une licence Microsoft Intune
Avoir le droit d’enrôlement
Ne pas être bloqué par des restrictions d’enrôlement Intune :

Concrètement, voici ce que la donne lors du premier démarrage du Windows 365 Link :

L’utilisateur démarre et s’authentifie pour la toute première fois :

Le Windows 365 Link s’enrôle automatiquement dans Entra :

Puis l’enrôlement automatique MDM prend le relais pour l’ajouter dans Intune :

Avant d’arriver à cela avec votre Windows 365 Link, prenons le temps de passer en revue toutes les étapes.

Où peut-on l’acheter ?

Sa disponibilité dépend des pays et des vagues de lancement définies par Microsoft. L’appareil est proposé via des partenaires et revendeurs agréés Microsoft, comme TD SYNNEX selon les régions concernées.

À ce jour, la disponibilité semble s’élargir progressivement avec les vagues successives de déploiement, parfois désignées comme Wave 1 ou Wave 2. Windows 365 Link est actuellement disponible pour les pays suivants :

États-Unis
Australie
Canada
Danemark
France
Allemagne
Inde
Japon
Pays-Bas
Nouvelle-Zélande
Suède
Suisse
Royaume-Uni

Dans les prochains mois, Il devrait l’être par la suite aussi disponible dans :

Belgique
Finlande
Irlande
Italie
Pologne
Singapour
Espagne

Pour connaître les options d’achat exactes, il est recommandé de se rapprocher d’un partenaire Microsoft local ou de consulter les annonces officielles de Microsoft pour votre zone géographique.

Maintenant que les principaux aspects fonctionnels, techniques et de licences autour de Windows 365 Link ont été abordés, il est temps de passer à la partie plus concrète.

La section suivante détaille pas à pas les différentes étapes de configuration et de prise en main de Windows 365 Link, depuis la préparation de l’environnement jusqu’aux premiers tests en conditions réelles :

Etape 0 – Configuration de base :

Dans mon environnement de test, j’ai déjà configuré plusieurs polices de provisionnement afin de créer mes Cloud PCs qui vont me servir durant mes tests :

Les Cloud PCs étant correctement déployés, une exigence particulière concerne toutefois le SSO avec Entra. Pour être plus clair, je vais maintenant repasser en détail sur toutes les étapes pour correctement configurer le SSO.

Etape I – Configuration du Single Sign-On :

Windows 365 Link repose entièrement sur le mécanisme Single Sign-On via Microsoft Entra ID. Autrement dit : si le SSO n’est pas activé sur le Cloud PC, la connexion de votre utilisateur risque d’échouer :

Pour activer le SSO, il sera nécessaire de vérifier, et de modifier si nécessaire, la police de provisionnement de vos Cloud PC, puis de recréer au besoin de nouveaux Cloud PCs si ces derniers ont été créés avant cette modification :

Voici l’option SSO dans la police de provisionnement des Cloud PCs qui doit être cochée :

L’étape suivante consiste à supprimer la demande de consentement SSO côté Microsoft Entra ID, dont la configuration repose sur des principaux de service :

Commençons par autoriser Microsoft Entra dans l’authentification pour Windows sur le tenant. Pour cela, j’utilise la console PowerShell d’Azure Cloud Shell, accessible depuis le portail Azure :

J’importe les deux modules Microsoft Graph suivants, puis je me connecte avec le compte aux permissions appropriées :

Import-Module Microsoft.Graph.Authentication
Import-Module Microsoft.Graph.Applications

Connect-MgGraph -Scopes "Application.Read.All","Application-RemoteDesktopConfig.ReadWrite.All"

Je récupère l’ID d’objet pour le principal du service de connexion au Windows Cloud :

$WCLspId = (Get-MgServicePrincipal -Filter "AppId eq '270efc09-cd0d-444b-a71f-39af4910ec45'").Id

Je modifie la propriété isRemoteDesktopProtocolEnabledtrue sur True, puis je vérifie que la propriété isRemoteDesktopProtocolEnabled est correctement définie :

If ((Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId) -ne $true) {
    Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId -IsRemoteDesktopProtocolEnabled
}
Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId

Depuis le portail Intune, je crée ensuite un groupe contenant les Cloud PCs :

J’utilise une requête dynamique pour ajouter automatiquement mes prochains Cloud PCs au groupe :

Enfin, toujours dans la même session d’Azure Cloud Shell, j’ajoute l’ID de groupe à une propriété sur le principal du service SSO Windows Cloud Login :

$tdg = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphTargetDeviceGroup
$tdg.Id = "<Group object ID>"
$tdg.DisplayName = "<Group display name>"

New-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $WCLspId -BodyParameter $tdg

Enfin, j’assigne le groupe créé :

Get-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $WCLspId

Tout est maintenant en place pour tester la première authentification sur votre Windows 365 Link.

Etape II – Test de la première connexion Windows 365 Link :

La vidéo suivante correspond à la première connexion avec succès de mon utilisateur de test à son Windows 365 Link :

J’ai réalisé ensuite une seconde vidéo montrant plusieurs scénarios de connexion et de bascule d’utilisateurs avec Windows 365 Link :

Le premier test illustre la connexion d’un utilisateur unique à différents Cloud PC Windows 365 qui lui sont attribués. L’objectif est d’observer le temps de connexion, la fluidité du changement de Cloud PC, ainsi que l’efficacité globale du processus d’authentification.

Le second test se concentre sur un scénario de type pool partagé, comparable à un usage Windows 365 Frontline, où plusieurs utilisateurs se connectent successivement au sein d’un même pool de Cloud PC. Ce scénario permet d’analyser le comportement de l’authentification, la gestion des sessions et la rapidité de bascule entre utilisateurs.

Ces démonstrations offrent un retour concret sur les performances et l’expérience utilisateur, avant d’aborder les aspects de configuration et d’administration via Intune.

Travis nous a d’ailleurs fait une excellente vidéo sur ce sujet disponible juste ici :

Une fois ces premiers tests de connexion réalisés, on peut imaginer d’autres tâches ou configurations que l’on peut faire autour de son Windows 365 Link.

Mais avant cela, je vous conseille de commencer par créer un filtre d’assignation Intune pour cibler uniquement les Windows 365 Link dans vos futures polices de configuration.

Etape III – Création d’un filtre d’assignation Intune :

Depuis le portail Intune, je commence par créer un filtre d’assignation, qui me sera très utile pour configurer les Windows 365 Link par la suite :

Je nomme ce filtre avec comme plateforme Windows 10 et +, puis je clique sur Suivant :

Je spécifie la règle de filtrage selon la propriété suivante afin de ne prendre en compte que les appareils Windows 365 Link, puis je clique sur Prévisualiser :

Si des Windows 365 Link sont déjà présents, je devrais voir ces derniers apparaître :

Enfin je confirme la création du filtre :

Mon filtre est maintenant en place, je vais pouvoir commencer à effectuer quelques réglages, comme la détection automatique du fuseau horaire.

Etape IV – Configuration automatique du fuseau horaire :

Au démarrage de votre Windows 365 Link, l’heure qui s’affiche n’est peut-être pas la bonne :

Les appareils Windows 365 Link peuvent rencontrer des problèmes de fuseau horaire si la détection automatique n’est pas autorisée. Il est possible de forcer l’utilisation du fuseau horaire local en autorisant l’accès à la localisation via Microsoft Intune.

Pour cela, connectez-vous au portail Intune, puis dirigez-vous vers le menu suivant :

Sélectionnez le type de profil suivant :

Renseignez les informations suivantes, puis cliquez sur Suivant :

Nom : Windows 365 Link – Time Zone Detection
Description : Autorise l’accès à la localisation afin de permettre la détection automatique du fuseau horaire sur les appareils Windows 365 Link.

Recherchez Access location, puis sélectionnez la catégorie Privacy, configurez comme ceci, puis cliquez sur Suivant :

Ajoutez les Scope tags nécessaires selon votre organisation, puis cliquez sur Suivant :

Dans Assignments, ciblez les appareils Windows 365 Link selon la méthode suivante, puis cliquez sur Suivant :

Par exemple, en utilisant All devices
En appliquant un Include filter basé sur un filtre de type Windows 365 Link

Vérifiez la configuration, puis cliquez ici pour déployer la stratégie :

Quelques minutes plus tard, l’accès à la localisation est autorisé, Windows 365 Link peut détecter automatiquement le fuseau horaire local, et affiche l’heure correcte selon la localisation de l’utilisateur :

Etape V – Modification du délai d’extinction de l’écran :

Par défaut, les appareils Windows 365 Link éteignent l’écran après environ cinq minutes d’inactivité. Ce comportement est assimilé à un verrouillage local : lorsque l’utilisateur réactive l’appareil, l’écran de connexion s’affiche.

Comme pour l’heure, la configuration se fait via une police de configuration Intune. Dans mon cas je configure l’extinction de l’écran après 9 minutes d’inactivité :

Travis nous a encore fait une excellente seconde vidéo sur ce sujet :

Etape VI – Modification des délais de déconnexion des sessions :

Comme Microsoft le recommande, est-il possible de raccourcir (mais pas de rallonger ?) les temps définis par défaut dans le cas de sessions Windows 365 inactives ou déconnectées :

Par défaut, Windows 365 PC Frontline conservent la session utilisateur active jusqu’à ce que :

En mode dédié : Le PC cloud est inactif pendant 30 minutes.

En mode partagé : Le PC cloud est inactif pendant 15 minutes.

Deux minutes avant la limite de temps d’inactivité, l’utilisateur reçoit une notification avec une boîte de dialogue.

Microsoft Learn

Cette stratégie force la fermeture (log off) des sessions Windows 365 afin d’éviter :

Les sessions laissées ouvertes sans activité
Les sessions bloquées après une coupure réseau
La consommation inutile de capacité (critique en Frontline partagé)

Elle remplace alors entièrement le comportement par défaut des services Windows 365 expliqués plus haut, à la condition que les temps indiqués ne soient pas supérieurs :

Par contre, à la différence des configurations précédemment appliquées sur les Windows 365 Link, j’ai appliqué cette nouvelle police sur filtre comprenant uniquement les Cloud PCs Frontline comme ceci :

Le tableau ci-dessous résume les différents événements observés et les mécanismes impliqués dans ma configuration :

Étape	Heure	Événement	Mécanisme responsable
Login utilisateur	08h47	Connexion au Cloud PC Frontline	Session RDS active
Idle atteint	08h52	Message “You will be signed out in 2 minutes”	Idle session RDS (5 min)
Log off	08h54	Déconnexion automatique (sign out)	End session when time limits are reached
Écran noir	09h03	Extinction automatique de l’écran	Policy Display Windows 365 Link (9 min)

Etape VII – Connexion automatique sur un Cloud PC :

Windows 365 Link permet également d’activer des mécanismes de connexion automatique et d’authentification sans mot de passe (passwordless), afin de simplifier encore davantage l’accès au Cloud PC pour l’utilisateur final.

Dans ce scénario, l’utilisateur n’a pas besoin de saisir manuellement son identifiant, ce qui rend l’expérience de connexion particulièrement fluide :

Pour cela, je suis passé par la création d’une police de configuration personnalisé avec les paramètres OMA-URI suivants :


Nom : Activer les clés de sécurité FIDO pour la connexion à Windows
OMA-URI : ./Device/Vendor/MSFT/PassportForWork/SecurityKey/UseSecurityKeyForSignin
Type de données : Integer
Valeur : 1

Il est également possible de configurer Windows 365 Link pour qu’il se connecte automatiquement à un Cloud PC Windows 365 spécifique :

Cette option est particulièrement adaptée aux environnements à poste dédié ou aux usages standardisés. On y retrouve les fonctionnalités habituelles, comme la restauration ou la réinitialisation de la connexion.

Enfin, un bouton Annuler permet d’annuler la connexion automatique à ce Cloud PC. Cette action redirige l’utilisateur vers l’écran de sélection afin de lui permettre de choisir un autre Cloud PC Windows 365 auquel se connecter :

Ces options permettent d’adapter finement l’expérience de connexion selon que l’on se trouve dans un scénario à poste dédié ou à usage partagé.

Etape VIII – Restauration de mode usine :

Si nécessaire, Microsoft propose une restauration en mode usine des Windows 365 Link depuis le portail Intune. Comme beaucoup de postes gérés en MDM sous Intune, cette fonction très utile permet de réinitialiser complètement l’appareil à distance, en supprimant toute configuration et toute association utilisateur, afin de le reprovisionner proprement.

Voici d’ailleurs une vidéo qui montre le processus en entier, d’environ 30 minutes (accéléré), sur un Windows 365 Link :

Etape IX – Test de Microsoft Teams :

J’ai réalisé un test Microsoft Teams avec Windows 365 Link et j’ai été très satisfait de l’expérience globale, tant sur la qualité du rendu que sur la fluidité du partage d’écran et des flux audio/vidéo.

Un tour dans les paramètres de Teams confirme que le mode Media Optimized (SlimCore) est bien actif avec Windows 365 Link :

Pour plus de détails sur SlimCore et son fonctionnement côté AVD / Windows 365, voir cet article dédié sur mon blog.

Ce test rapide illustre le rendu réel de Microsoft Teams en conditions d’usage, du partage d’écran et des flux caméra, en mettant en évidence que le traitement (CPU) est effectué localement sur le Windows 365 Link et non sur le Cloud PC :

Et voici encore une autre vidéo faite cette fois avec une vidéo YouTube :

Après ces différents tests et configurations, il est possible de tirer plusieurs enseignements concrets sur l’usage de Windows 365 Link.

Conclusion

En conclusion, et après plusieurs jours d’utilisation et de tests dans des scénarios réels, Windows 365 Link s’est montré convaincant à l’usage quotidien.

Les performances observées, la simplicité d’accès au Cloud PC et la stabilité globale de l’expérience m’ont laissé une impression très positive au quotidien. Dans certains cas, j’ai pu avoir des doutes quant à la pertinence de l’appareil, notamment pour des scénarios où ses limites fonctionnelles peuvent apparaître.

Néanmoins, pour les cas d’usage évoqués plus haut (postes partagés, environnements Frontline, centres de contact ou contextes à forte exigence de sécurité), Windows 365 Link apporte une réelle valeur.

C’est un produit cohérent, bien positionné dans la stratégie Cloud-first de Microsoft, et je suis personnellement très satisfait d’avoir pu le tester dans des conditions concrètes et représentatives.

Alors, Windows 365 Link est-il un produit de niche ou le début d’une nouvelle norme ?

Windows 365 Link s’inscrit dans la stratégie Cloud-first de Microsoft et cible des usages bien définis. Il ne remplace pas tous les postes de travail, mais propose une alternative cohérente dans les environnements où la simplicité, la sécurité et la centralisation priment sur la flexibilité locale.

Enfin, retrouvez-moi et Arnaud et Arnaud dans un futur AzuReX prévu le 29 janvier prochain à 13 heures, dont l’inscription se passe juste ici 😎

Merci d’avoir lu cet article jusqu’au bout 😎

Entra ID Account Recovery

La perte totale d’accès à un compte Microsoft Entra ID reste l’un des scénarios les plus critiques en matière d’identité : plus de mot de passe, plus de MFA, plus de clés physiques. Historiquement, ce type de situation reposait sur des procédures manuelles, souvent longues, impliquant les équipes IT internes, voire le support Microsoft pour les comptes à privilèges élevés. Lors de Microsoft Ignite 2025, Microsoft a officiellement mis en avant Entra ID Account Recovery comme une réponse structurante à ce problème historique, en l’inscrivant clairement dans sa vision Zero Trust et Identity-first.

Avec Entra ID Account Recovery, Microsoft introduit une nouvelle approche : une récupération de compte en libre-service, basée non plus sur des facteurs préenregistrés, mais sur une vérification d’identité à haute assurance, intégrée nativement à l’écosystème Entra via Verified ID et Face Check.

Comment faisait-on auparavant en cas de blocage total d’un compte ?

Avant l’arrivée d’Entra ID Account Recovery, la gestion d’un blocage total de compte dépendait fortement du type d’utilisateur concerné :

Pour un utilisateur standard, la récupération passait généralement par les équipes de support IT internes. Ces équipes procédaient à des actions manuelles (réinitialisation, suppression/recréation de méthodes d’authentification, Temporary Access Pass, etc.), après avoir vérifié l’identité de l’utilisateur selon les processus internes de l’organisation.

Pour un utilisateur à privilèges élevés, et en particulier un administrateur général, la situation était plus complexe. En cas de perte totale des moyens d’authentification, il était souvent nécessaire de contacter le Microsoft Data Protection Team via un ticket de support Microsoft.

Cette distinction rendait la récupération :

relativement gérable pour les utilisateurs standards,
mais particulièrement contraignante et chronophage pour les comptes administrateurs, avec un fort impact opérationnel.

Qu’est-ce qu’Entra ID Account Recovery ?

Entra ID Account Recovery est une solution de récupération d’accès, conçue pour les scénarios où toutes les méthodes de connexion sont perdues.

Plutôt que de simplement réinitialiser un mot de passe, elle repose sur une vérification d’identité à haute assurance pour prouver qui est l’utilisateur avant de lui permettre de rétablir ses méthodes d’authentification.

Microsoft Entra ID Account Recovery traite ces scénarios critiques en permettant aux utilisateurs de récupérer l’accès à leurs comptes via un processus de vérification d’identité robuste.

Microsoft Learn

Contrairement à la réinitialisation de mot de passe, qui suppose que les utilisateurs conservent une certaine forme de méthode d’authentification, la récupération de compte se concentre sur la recréation de l’approbation dans l’identité de l’utilisateur lorsqu’il a perdu l’accès à tous les mécanismes d’authentification.

Microsoft Learn

Entra ID Account Recovery vs réinitialisation de mot de passe en libre-service (SSPR)

Voici une comparaison proposée par Microsoft entre la récupération de compte et la réinitialisation de mot de passe en libre-service (SSPR) :

Aspect	Réinitialisation du mot de passe libre-service (SSPR)	Récupération de compte (Entra ID Account recovery)
Cas d’usage principal	Mot de passe oublié par l’utilisateur, mais conserve l’accès aux méthodes d’authentification	L’utilisateur a perdu l’accès à toutes les méthodes d’authentification
Exigence d’authentification	Au moins une méthode d’authentification inscrite (les contrôles de stratégie peuvent nécessiter jusqu’à 2 méthodes)	Vérification d’identité par le biais d’un partenaire certifié
Hypothèse de confiance	L’identité de l’utilisateur est vérifiée par le biais de méthodes existantes	L’identité de l’utilisateur doit être rétablie
Étendue de récupération	Mot de passe uniquement	Réinitialisation complète de la méthode d’authentification
Dépendance technologique	Méthodes MFA existantes, questions de sécurité	Services de vérification d’identité, ID vérifié
Niveau de sécurité	Moyen – s’appuie sur des méthodes préinscrites	Élevé : nécessite une vérification complète des identités

Quels sont les prérequis ?

Voici les prérequis connus pour utiliser Entra ID Account Recovery dans Microsoft Entra ID, toujours en préversion à l’heure où ces lignes sont écrites :

Licence Microsoft Entra ID P1 pour la récupération du compte
Avoir activé Verified ID et Face Check

Concernant le second point, plusieurs articles présents sur mon blog avaient déjà été écrits sur le sujet :

Quels sont les fournisseurs IDV disponibles ?

Voici une liste de fournisseurs d’Identity Verification Providers (IDV) actuellement disponible avec Microsoft Entra ID Account Recovery, dont les souscriptions sont accessibles via le Microsoft Security Store :

Combien coûte le processus de récupération Entra ID Account Recovery ?

Plusieurs éléments de coût sont à prendre en compte pour comprendre le prix d’Entra ID Account Recovery :

Le coût de la licence Microsoft Entra ID P1,
Le coût du fournisseur de vérification d’identité externe (voir plus bas),
Le coût d’Entra Verified ID via Face Check ($0.25 par vérification).

Voici le détail des coûts affichés pour chacun des trois fournisseurs IDV :

TrueCredential :

Modèle de tarification à la transaction (PAYG)
Pas de coût fixe mensuel
Facturation purement à l’usage
Support optionnel
Disponible en essai gratuit :
- 100 Issuances de Verified ID
- 100 Présentations de Verified ID
- Identity proofing inclus (LexisNexis IDVerse)

Tarifs après l’essai :

Action	Prix
Issuance (émission d’un Verified ID)	1,00 $ / transaction
Presentation (présentation du Verified ID)	1,00 $ / transaction

Coût d’utilisation d’Entra ID Account Recovery pour une récupération :

1 issuance (nouvelle identité vérifiée)
1 présentation (preuve lors de l’accès)

AU10TIX

Tarification par utilisateur (paiement unique)
Essai gratuit un mois
- Coût : 0 $ le premier mois
- Jusqu’à 100 Verified IDs émis
- Jusqu’à 10 présentations par utilisateur
- Détection de fraude temps réel incluse

Tarifs après l’essai :

Volume	Prix
1 → 1 000 000 utilisateurs	2,00 $ par utilisateur (paiement unique)
Présentations incluses	Jusqu’à 10 par utilisateur
Durée	1 an

Coût d’utilisation d’Entra ID Account Recovery pour une récupération :

Le coût est indépendant du nombre de récupérations, tant que l’utilisateur reste dans son quota de présentations.

IDEMIA

Modèle de tarification à la transaction (PAYG)
Essai gratuit
- Coût : 0 $
- 100 Vérifications d’identité réussies
- 100 Vérifications d’identité échouées
- 100 Présentation de VC

Tarifs après l’essai :

Action	Prix
Vérification ID réussie	1,00 $
Vérification ID échouée	1,00 $
Présentation de VC	1,00 $

Coût d’utilisation d’Entra ID Account Recovery pour une récupération :

1 tentative =
- 1 vérification (succès ou échec)
- 1 présentation ≈
  - 2 $ minimum, 3 $ si échec + nouvelle tentative

Ce qui nous amène aux coûts suivants quand Entra ID Account Recovery rentre en production :

Fournisseur	Modèle	Coût typique par récupération	Risque coût
TrueCredential	Transaction	~2 $	Faible
AU10TIX	Par utilisateur	~2 $ / an	Très prévisible
IDEMIA	Transaction	2–3 $	Échecs facturés

Microsoft met également à disposition un calculateur accessible depuis le portail Entra :

Les demandes de récupération de compte concernent généralement environ 1 à 3 % des utilisateurs chaque mois. Le calculateur compare vos dépenses actuelles aux coûts de récupération en libre-service prévus, ce qui vous permet de modéliser facilement les économies pour votre scénario.

Microsoft Learn

Account Recovery – Deux modes disponibles :

Voici la comparaison des modes Évaluation et Production pour Account Recovery dans Microsoft Entra :

Critère	Évaluation	Production
Objectif	Tester la vérification d’identité	Permettre la récupération réelle du compte
Abonnement IDV requis	Oui	Oui
Vérification d’identité	Face check	Face check
Récupération du compte	❌ Non	✅ Oui
Accès utilisateur restauré	❌ Non	✅ Oui
Temporary Access Pass	❌ Non	✅ Oui
Ré-enrôlement MFA	❌ Non	✅ Oui
Impact sur le compte	Aucun	Compte récupéré
Usage recommandé	Tests, POC, validation sécurité	Production, utilisateurs autorisés
Population cible	Équipe IT / sécurité	Groupes restreints d’utilisateurs
Cas d’usage	Validation du fournisseur IDV	Perte totale des facteurs

Comme Entra ID Account Recovery se trouve toujours en préversion, je vous propose au travers de cet article de tester la solution en l’activant sur un tenant de test dans le mode Évaluation.

En mode Évaluation, les utilisateurs peuvent uniquement tester le processus de vérification d’identité sans récupérer réellement leurs comptes :

Avant de mettre en place la solution, certains composants sont nécessaires en tant que prérequis.

Etape 0 – Configuration de base :

Dans mon environnement de test, j’ai déjà configuré certains composants prérequis à la mise en place de Entra ID Account Recovery.

Configuration d’Entra Verified ID :

Configuration d’Entra Face Check :

Achat de licences Microsoft Entra ID P1/P2 :

Commençons par activer Entra ID Account Recovery depuis le portail du même nom.

Etape I – Activation d’Entra ID Account Recovery :

Microsoft documente la procédure de façon très claire juste ici.

Pour cela, connectez-vous au centre d’administration Microsoft Entra au moins en tant qu’administrateur d’authentification, puis cliquez ici pour démarrer le processus :

Sous Choisir un mode de récupération, sélectionnez Évaluation :

Sous Sélection du groupe d’utilisateurs, cliquez sur Sélectionner des groupes, choisissez les groupes que vous souhaitez inclure pour la récupération de compte, puis cliquez sur Suivant :

Sous Fournisseurs de vérification d’identité, choisissez un fournisseur, puis sélectionnez Obtenir la solution :

Connectez-vous au Microsoft Security Store :

Dans la page de votre fournisseur de vérification d’identité, sélectionnez Obtenir la solution :

Sélectionnez un abonnement Azure, un groupe de ressources, puis saisissez un nom de ressource :

Cliquez ici pour choisir le plan tarifaire :

Sélectionnez un plan tarifaire :

Définissez le nombre d’utilisateurs ainsi que la fonction d’auto-renouvellement, puis cliquez sur Suivant :

Confirmez les détails, puis sélectionnez Passer la commande :

Attendez quelques minutes que le processus d’achat se termine :

Entre-temps, constatez la génération d’une ressource sur le portail Azure :

Lorsque votre abonnement SaaS est prêt, sélectionnez Configurer le compte maintenant :

Acceptez la demande de permissions de votre fournisseur de vérification d’identité :

Dans la page Général de l’abonnement SaaS, fournissez les détails requis demandés par le fournisseur SaaS (par exemple, le nom du contact, l’e-mail et le numéro de téléphone), puis sélectionnez Souscrire :

Attendez quelques minutes la fin du traitement :

Quelques minutes plus tard, recevez le mail suivant vous confirmant que la souscription SaaS est bien activée :

Une fois le processus d’achat terminé, revenez au processus de configuration de la récupération de compte dans le Centre d’administration Microsoft Entra pour effectuer les étapes restantes.

Revenez au menu fournisseur de vérification d’identité dans le processus de configuration de la récupération de compte, puis sélectionnez Sélectionner :

Le message en vert ci-dessous vous indique que le provisionnement de l’étape précédente s’est correctement terminé, puis cliquez sur Suivant :

Dans la page Révision et finalisation , passez en revue les détails de la configuration de récupération de compte, puis sélectionnez Terminé :

Une fois l’installation terminée, la page d’accueil de récupération de compte s’ouvre dans le Centre d’administration Microsoft Entra :

Une fois l’installation terminée, tous les utilisateurs limités à la récupération de compte peuvent essayer la récupération et terminer la vérification de l’identité. Mais ils ne peuvent pas récupérer leurs comptes, car la récupération est définie en mode d’évaluation.

Etape II – Préparation du compte utilisateur de test :

Dans sa version actuelle, la vérification repose uniquement sur les deux champs suivants :

Afin de tester facilement la solution, créez un utilisateur ayant ces deux attributs :

Vérifiez que la propriété First Name et la propriété Last Name sont renseignées. S’ils sont vides, il n’existe aucun moyen pour Microsoft Entra ID Account Recovery de correspondre aux valeurs de revendications d’ID retournées par le fournisseur de vérification d’identité.

Souvent, le vrai nom d’un utilisateur sur son ID de gouvernement ne correspond pas à ce qui est répertorié pour son compte d’utilisateur dans l’ID Microsoft Entra.

Le nom complet n’est pas utilisé dans le processus de récupération du compte ; seules les propriétés Prénom et Nom sont utilisées.

Microsoft Learn

Configurez-lui une ou des méthodes MFA ou passkey :

Déconnectez-vous de votre utilisateur.

Notre utilisateur de test est maintenant correctement configuré. Imaginons que ce dernier a perdu son mot de passe, son smartphone, mais également sa clef FIDO.

Nous allons maintenant tester le processus de récupération de compte afin de comprendre comment les utilisateurs peuvent récupérer leurs comptes en quelques étapes simples.

Etape III – Test de récupération de compte :

Microsoft documente la procédure de façon très claire juste ici.

Ouvrez un navigateur privé, puis rendez-vous sur la page suivante, saisissez votre nom de compte, puis cliquez sur Suivant :

Il vous est proposé une méthode d’authentification initiale, comme le mot de passe, pour vous connecter. Comme vous ne parvenez pas à utiliser cette méthode, sélectionnez d’autres façons de vous connecter. Vous disposez d’options de connexion supplémentaires.

Comme vous ne parvenez pas à vous connecter avec des méthodes, cliquez sur Récupérer votre compte :

Cliquez sur Suivant afin d’être redirigé vers le service de vérification des identités configuré par votre organisation :

Démarrez le processus en cliquant ici :

Basculez sur votre smartphone ou continuez sur votre poste :

Autorisez votre navigateur internet à utiliser votre caméra, puis cliquez sur Continuer :

Acceptez les conditions d’utilisation de l’application :

Passez en revue comment prendre une photo de document claire, puis sélectionnez Continuer :

Prenez la photo recto et/ou verso de votre document d’identité (carte d’identité, passeport, permis de conduire, permis de travail), puis sélectionnez Envoyer les photos :

Attendez la confirmation de la part de l’application sur la qualité de votre photo :

Passez en revue comment prendre une photo claire de votre visage, puis sélectionnez Continuer :

Réalisez une photo de vous :

L’application vérifie votre identité, deux résultats sont alors possibles :

Vérification échouée : l’application vous informe de l’échec de l’opération sans plus de détail :

Dans la vidéo de John Savill, nous avons pu voir une copie d’écran de la partie backend de l’application AU10TIX :

Vérification réussie : l’application émet des justificatifs vérifiables (Verified ID) à sauvegarder dans votre application Microsoft Authenticator. Ouvrez Microsoft Authenticator, puis scannez le QR Code ci-dessous :

Effectuez une vérification du visage avant que la propriété de votre compte puisse être validée :

Une fois l’identité vérifiée présente dans votre Microsoft Authenticator, cliquez sur Partager afin de l’utiliser dans le processus de récupération de compte :

Une fois terminé, vous obtenez un pass d’accès temporaire, copiez ce code :

Comme le montre la capture d’écran ci-dessus, aucun TAP n’est visible dans le mode Évaluation, le message d’erreur suivant apparaît d’ailleurs systématiquement :

Mais la suite de la procédure devrait ressembler à cela :

Microsoft a déjà écrit une aide au Troubleshooting pour les utilisateurs juste ici :

L’utilisateur ne peut pas récupérer son compte en mode Évaluation
L’utilisateur n’a pas reçu de TAP
L’utilisateur peut ne pas voir l’option Récupérer votre compte
L’utilisateur peut obtenir une erreur indiquant que les demandes ne peuvent pas être traitées au début de la récupération.
Erreurs du fournisseur de vérification d’identité.
Erreurs lors de la vérification faciale.
Problèmes liés au code d’accès temporaire après la vérification d’identité.
Clé d’accès non émise.

Enfin, des événements sont inscrits dans les journaux d’audit d’Entra ID pour retracer toutes ces opérations de récupération de compte :

Conclusion

Avec Entra ID Account Recovery, Microsoft adresse enfin un angle mort historique de la gestion des identités : la récupération d’un compte après une perte totale des moyens d’authentification, y compris pour les comptes sensibles et à privilèges élevés.

Cela confirme qu’Entra ID Account Recovery n’est pas un simple ajout fonctionnel, mais un pilier de la stratégie identité de Microsoft, aux côtés de Verified ID, du Face Check et des mécanismes d’accès conditionnel.

Là où les approches traditionnelles reposaient sur des processus manuels, difficiles à industrialiser et fortement dépendants du support, Entra ID Account Recovery propose une alternative structurée, traçable et alignée avec les principes Zero Trust, en s’appuyant sur une vérification d’identité forte plutôt que sur des secrets ou des facteurs existants.

Même si la fonctionnalité est encore en préversion, elle ouvre des perspectives intéressantes pour :

réduire la dépendance au support, y compris pour les comptes administrateurs,
améliorer l’expérience utilisateur dans des scénarios critiques,
et renforcer la sécurité globale des processus de récupération.

Comme toujours, une activation progressive, en mode Évaluation, sur un tenant de test et avec une population restreinte, reste la meilleure approche avant toute mise en production.

Azure Virtual Desktop hybride + SSO

Azure Virtual Desktop est souvent présenté comme une solution offrant un Single Sign-On “natif”. Dès que l’on sort d’un environnement cloud-only pour entrer dans un contexte hybride, les mécanismes d’authentification deviennent toutefois plus complexes, et parfois déroutants. Entre Microsoft Entra ID, Active Directory, Kerberos, PRT, Seamless SSO et Cloud Kerberos Trust, il est facile de confondre des briques aux noms proches, mais qui n’interviennent ni au même moment ni au même niveau.

Dans un précédent article, j’avais détaillé la mise en place du SSO Azure Virtual Desktop dans un environnement cloud-only.

Dans cet article, j’ai volontairement changé de contexte pour travailler sur un environnement hybride. L’objectif de cet article est de répondre aux trois questions suivantes :

Clarifier les mécanismes d’authentification (PRT, Seamless SSO, Kerberos, etc.)
Montrer pas à pas pourquoi certaines étapes sont indispensables pour obtenir un SSO réellement transparent dans AVD.
A quoi sert le Seamless SSO disponible dans Entra Connect Sync ?

Avant d’aborder la configuration et les tests, il est utile de poser le cadre : comprendre quels mécanismes d’authentification sont utilisés, à quel moment, et pourquoi certains fonctionnent seuls alors que d’autres doivent être combinés.

Cette FAQ a pour objectif de lever les confusions les plus fréquentes autour des tokens, du Kerberos, et du Single Sign-On dans un environnement Microsoft Entra hybride.

Quels sont les tokens utilisés par Microsoft Entra ID ?

Microsoft Entra ID utilise plusieurs types de tokens, chacun ayant un rôle précis :

Primary Refresh Token (PRT)
- Jeton long terme
- Spécifique à l’appareil
- Sert à demander d’autres tokens
- Utilisé par Windows (WAM – Web Account Manager)

Access Token
- Jeton court terme
- Présenté aux applications (API, Office, AVD…)
- Contient les claims utilisateur

Refresh Token
- Permet de renouveler un Access Token
- Généralement géré automatiquement par le système

Qu’est-ce que le Primary Refresh Token (PRT) ?

Dans le monde de Microsoft, le PRT est un jeton émis par Microsoft Entra ID lorsqu’un appareil est Microsoft Entra Joined ou Microsoft Entra Hybrid Joined.

Un jeton d’actualisation principal (PRT) est un artefact clé de l’authentification Microsoft Entra dans les versions prises en charge de Windows, iOS/macOS, Android et Linux. Un PRT est un artefact sécurisé spécialement émis aux répartiteurs de jetons microsoft pour activer l’authentification unique (SSO) sur les applications utilisées sur ces appareils.

Microsoft Learn

Le PRT est stocké localement sur la machine et sert de jeton racine pour :

obtenir des tokens d’accès OAuth 2.0
s’authentifier automatiquement aux services cloud Microsoft
éviter toute ressaisie de mot de passe pour les applications modernes

Concrètement, le PRT permet :

l’ouverture automatique de session dans Edge
l’authentification transparente à Office, Teams, OneDrive
l’utilisation de Windows App / Azure Virtual Desktop web

Point important : le PRT n’est pas Kerberos et ne permet pas, à lui seul, d’ouvrir une session Windows sur une machine Active Directory.

Pourquoi le PRT ne suffit-il pas pour Azure Virtual Desktop en mode Hybride ?

Dans un environnement Azure Virtual Desktop en mode Hybride, il y a deux niveaux d’authentification distincts :

Accès au service AVD (broker / portail)
→ Authentification Microsoft Entra ID
→ Le PRT suffit
Ouverture de la session Windows sur le session host
→ Authentification Active Directory
→ Un TGT Kerberos est obligatoire

Dans un environnement Microsoft Entra Hybrid Joined, le PRT est présent, mais le TGT Kerberos n’est pas automatiquement délivré par Entra.

Cela permet de comprendre pourquoi une seconde authentification Active Directory est fréquemment observée dans de nombreux environnements AVD, après une première authentification Entra.

Qu’est-ce qu’un TGT Kerberos Active Directory ?

Le Ticket Granting Ticket (TGT) est un jeton Kerberos délivré par un contrôleur de domaine Active Directory.

Il est obtenu :

lors de l’ouverture de session Windows
après une authentification réussie auprès de l’AD

Le TGT permet ensuite :

d’accéder aux ressources Active Directory
d’obtenir des tickets de service (CIFS, LDAP, HTTP, etc.)
d’ouvrir une session Windows locale ou distante

Sans TGT Kerberos, l’ouverture d’une session Active Directory n’est pas possible.

Qu’est-ce que Microsoft Entra Kerberos (Cloud Kerberos Trust) ?

Microsoft Entra Kerberos est le mécanisme qui permet à Microsoft Entra ID de :

générer un TGT Kerberos Active Directory
à partir d’une authentification cloud
sans nécessiter ADFS

Techniquement :

un objet Kerberos spécial est créé dans l’Active Directory
les clés sont synchronisées avec Microsoft Entra ID
Entra devient capable d’émettre un TGT valide pour l’AD

C’est l’élément nécessaire pour obtenir un SSO complet dans AVD en environnement hybride.

Pourquoi la jointure hybride améliore l’expérience SSO ?

Avec Microsoft Entra Hybrid Join :

l’appareil est reconnu par Entra
un PRT est délivré
les applications cloud utilisent un SSO moderne

En ajoutant Microsoft Entra Kerberos :

Entra peut aussi délivrer un TGT AD
Windows peut ouvrir la session sans redemande de mot de passe

On comprend alors que la combinaison du PRT et d’un TGT Kerberos est nécessaire pour obtenir un SSO transparent dans Azure Virtual Desktop.

À quoi sert la case “Single sign-on” dans Entra Connect ?

La case Single sign-on dans Microsoft Entra Connect active ce qu’on appelle Seamless SSO.

Seamless SSO repose sur :

Kerberos
le compte AD AZUREADSSOACC
le site autologon.microsoftazuread-sso.com

Son objectif est volontairement limité :

éviter la saisie du mot de passe AD
lors d’une authentification navigateur vers Entra ID
sur une machine AD-only

Il est important de distinguer Seamless SSO des autres mécanismes :

ne crée PAS de PRT
ne remplace PAS Microsoft Entra Kerberos
ne supprime PAS tous les écrans de login

Pour se donner une meilleure idée de cette fonctionnalité SSO spécifique, nous la testerons dans la dernière étape de cet article.

Mais commençons d’abord par tester la mise en place du single sign-on complet pour un environnement AVD de mode hybride, dont les procédures officielles sont disponibles ici et là :

Etape 0 – Configuration de base :

Dans mon environnement de test, j’ai déjà configuré certains composants.

Un environnement Active Directory
Microsoft Entra Connect configuré avec
- Password Hash Synchronization (PHS)
- sans Single sign-on,
- avec Hybrid Joined pour les machines Windows 10/11
- Synchronisation de l’OU des utilisateurs AVD
- Synchronisation de l’OU des machines hôtes AVD

Un environnement Azure Virtual Desktop avec deux machines virtuelles jointes à AD :

Notre environnement AVD en mode hybride est en place, commençons par un premier test.

Etape I – Test sans configuration SSO :

Avant d’aller plus loin, j’effectue déjà un premier test de connexion d’un utilisateur AVD depuis le portail web :

Une authentification AD est demandée lors de l’ouverture de la session Windows, c’est un comportement normal à ce stade car rien n’est configuré :

La commande dsregcmd /status sert à afficher l’état d’enregistrement de l’appareil auprès d’Entra ID et, concernant le PRT (Primary Refresh Token), elle fournit des informations de diagnostic sur sa présence et son état :

AzureAdPrt : YES / NO : Indique si un PRT est présent sur la machine pour l’utilisateur
AzureAdPrtUpdateTime : Date/heure du dernier rafraîchissement du PRT
AzureAdPrtExpiryTime : Date/heure d’expiration du PRT
AzureAdPrtAuthority : Autorité qui a émis le token (généralement login.microsoftonline.com).

Concernant la partie des tickets, voici ce que l’on peut aussi en déduire :

OnPremTgt : NO : cela indique si la session utilisateur courante ne possède pas Ticket Granting Ticket Kerberos émis par un contrôleur de domaine AD.
CloudTgt : YES : indique la présence d’un TGT Kerberos cloud, émis par Entra ID.

Comme on peut le constater, le PRT émis via Entra fonctionne bien pour les services Cloud, mais l’ouverture de session et l’accès à certaines ressources gérées par l’AD pourraient être restreints dans la situation actuelle.

Commençons étape par étape les changements pour arriver à une configuration complète.

Etape II – Configuration SSO du pool d’hotes AVD :

Sur le portail Azure, comme l’indique la documentation Microsoft, j’effectue la configuration SSO du host pool Azure Virtual Desktop afin d’activer “Microsoft Entra authentication for single sign-on” :

J’effectue un nouveau test avec mon utilisateur :

À ce stade, une authentification AD est encore demandée lors de l’ouverture de la session Windows :

Etape III – Création d’un objet serveur Kerberos :

Sur le serveur AD, comme l’indique la documentation Microsoft, je commence par installer le module AzureADHybridAuthenticationManagement :

# First, ensure TLS 1.2 for PowerShell gallery access.
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12

# Install the AzureADHybridAuthenticationManagement PowerShell module.
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

Pour créer l’objet Kerberos Server nécessaire au Cloud Kerberos Trust, j’ai choisi l’exemple 4 de la documentation Microsoft :

Cet exemple exploite l’authentification moderne basée sur le User Principal Name (UPN) sans exiger de mot de passe AD explicite.
Il s’intègre parfaitement dans un environnement hybride sécurisé avec MFA et politiques d’accès conditionnel
Il évite les écueils des méthodes utilisant NTLM ou des identifiants AD en clair.

# Specify the on-premises Active Directory domain. A new Microsoft Entra ID
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter a UPN of a Hybrid Identity Administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"

# Create the new Microsoft Entra ID Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Open an interactive sign-in prompt with given username to access the Microsoft Entra ID.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName

Je lance donc le script à la suite du précédent, en prenant soin de remplacer l’UPN par un administrateur général ou hybride :

Je vérifie le serveur Microsoft Entra Kerberos nouvellement créé à l’aide de la commande suivante :

# When prompted to provide domain credentials use the userprincipalname format for the username instead of domain\username
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential (get-credential)

Enfin je constate la présence krbtgt_AzureAD utilisé par les DC pour signer les TGT Kerberos. Il s’agit d’une séparation cryptographique claire avec krbtgt dans le cadre de Kerberos émis depuis Entra :

J’effectue un nouveau test avec mon utilisateur :

Une fois le Cloud Kerberos Trust et l’authentification RDP Microsoft Entra activés, la seconde authentification Active Directory disparaît et est remplacée par un simple message de consentement Allow Remote Desktop connection :

Entra veut un consentement explicite de l’utilisateur. Ce message ne correspond pas à une authentification supplémentaire, mais à une demande de confiance entre l’utilisateur et le session host :

Si l’utilisateur clique sur Oui, ce consentement sera conservé 30 jours et ne pourra pas mémoriser plus de 15 hôtes.

L’Étape suivante consiste donc à supprimer définitivement le popup en déclarant les session hosts comme appareils de confiance dans Microsoft Entra ID.

Etape IV – Activation de l’authentification Microsoft Entra pour RDP :

Commençons par autoriser Microsoft Entra dans l’authentification pour Windows sur le tenant. Pour cela, j’utilise Azure Cloud Shell depuis le portail Azure :

J’importe les deux modules Microsoft Graph suivants, puis je me connecte avec le compte au permissions appropriées :

Import-Module Microsoft.Graph.Authentication
Import-Module Microsoft.Graph.Applications

Connect-MgGraph -Scopes "Application.Read.All","Application-RemoteDesktopConfig.ReadWrite.All"

Je récupère l’ID d’objet pour le principal du service de connexion au Windows Cloud :

$WCLspId = (Get-MgServicePrincipal -Filter "AppId eq '270efc09-cd0d-444b-a71f-39af4910ec45'").Id

Je modifie la propriété isRemoteDesktopProtocolEnabledtrue sur True :

If ((Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId) -ne $true) {
    Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId -IsRemoteDesktopProtocolEnabled
}

Je vérifie que la propriété isRemoteDesktopProtocolEnabled est correctement définie :

Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId

Afin de masquer la boîte de dialogue en configurant la liste des hôtes AVD approuvés, je créé un groupe dans Entra ID contenant les hôtes de sessions :

J’utilise une requête dynamique pour ajouter automatiquement mes prochains hôtes dans le groupe :

Enfin, toujours dans la même session d’Azure Cloud Shell, j’ajoute l’ID de groupe à une propriété sur le principal du service SSO Windows Cloud Login.

$tdg = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphTargetDeviceGroup
$tdg.Id = "<Group object ID>"
$tdg.DisplayName = "<Group display name>"

New-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $WCLspId -BodyParameter $tdg

Enfin, je vérifie la bonne assignation du groupe :

J’effectue un nouveau test avec mon utilisateur :

Cette fois l’authentification passe sans encombre. Un TGT Kerberos AD DS (on-premises) est maintenant présent dans la session.

Cela permet d’observer que :

La machine est Hybrid Entra ID Joined
Le PRT est valide
Le Kerberos cloud fonctionne
Le Kerberos AD DS fonctionne
Les deux mondes coexistent simultanément dans la même session

Cette sortie correspond à un état hybride cohérent, où les mécanismes cloud et on-premises coexistent.

Pour finir, je vous propose de tester l’impact du Seamless SSO présent et configurable dans Entra Connect Sync.

Etape V – Activation du SSO d’Entra Connect Sync :

Pour cela, je décide de rajouter une troisième machine AVD :

Celle-ci est bien présente dans l’Active Directory :

Mais elle n’est pas présente dans Entra ID :

Pour ne pas perturber mes tests, je décide donc de bloquer la connexion aux deux autres VMs AVD :

J’effectue un test avec mon utilisateur :

Comme aucune configuration hybride n’est en place pour cette machine AVD, il n’y a pas de ticket TGT Kerberos émis par Entra ID, donc la seconde authentification AD est logique :

Une fois dans la session Windows, dsregcmd nous affiche les informations suivantes :

La machine est jointe uniquement à Active Directory on-premises
Elle n’est pas jointe à Entra ID
Elle n’est pas Hybrid Join
Aucun PRT
Aucun SSO cloud
Aucune authentification Entra ID
Une tentative d’Entra ID Join / Hybrid Join a eu lieu
- Elle a échoué côté Entra ID
- La machine AVD n’existe pas ou n’est pas reconnu dans le tenant

L’ouverture de la page d’authentification d’Office 365 dans Microsoft Edge me montre d’ailleurs aucune connexion SSO :

Je décide donc d’activer la fonctionnalité SSO dans Entra Connect Sync :

Une fois la configuration terminée, je constate la création de AZUREADSSOACC en tant que compte ordinateur créé dans Active Directory :

Ce dernier est créé automatiquement lors de l’activation de Seamless Single Sign-On (Seamless SSO) avec Entra ID. Le compte est utilisé par Entra ID pour :

établir une relation de confiance Kerberos avec l’AD on-prem
permettre le SSO sans saisie de mot de passe depuis des postes domain-joined vers Entra ID

J’effectue donc un nouveau test avec mon utilisateur :

Dans ce contexte, il est logique que l’authentification AD soit toujours demandée :

Une fois la session Windows ouverte, comme Seamless SSO fonctionne via l’adresse autologon.microsoftazuread-sso.com, je décide de la rajouter en tant qu’URL de l’Intranet local.

Pour cela, j’ouvre inetcpl.cpl :

Je clique sur Site dans Intranet local :

Je clique sur Avancée :

Je rajoute l’URL suivante :

https://autologon.microsoftazuread-sso.com

Toujours dans Intranet Local, je coche Connexion automatique avec le nom d’utilisateur et le mot de passe actuels :

Quelques minutes plus tard, j’ouvre Microsoft Edge et je constate l’authentification automatique de mon compte Cloud correspondant :

La présence du ticket HTTP/autologon.microsoftazuread-sso.com dans le cache Kerberos confirme que le mécanisme Seamless SSO est bien actif. Ce ticket, émis par le contrôleur de domaine à destination de Microsoft Entra ID, permet une authentification navigateur sans saisie de mot de passe.

klist

Il est important de noter que ce mécanisme n’est pas celui utilisé pour l’ouverture de session Windows dans Azure Virtual Desktop, qui repose sur un TGT Kerberos distinct délivré via Microsoft Entra Kerberos (krbtgt_AzureAD).

Conclusion

À travers ces différents tests et configurations, on constate que le Single Sign-On dans Azure Virtual Desktop hybride ne repose pas sur un mécanisme unique, mais sur une combinaison cohérente de plusieurs briques d’authentification.

Le PRT permet une authentification fluide aux services cloud, mais il ne suffit pas à lui seul pour ouvrir une session Windows dans un contexte Active Directory. C’est bien l’association du Hybrid Join, du Cloud Kerberos Trust et de l’authentification Microsoft Entra pour RDP qui permet d’aligner les mondes cloud et on-premises, et d’obtenir une expérience utilisateur réellement transparente dans AVD.

Comprendre ces mécanismes permet non seulement d’éviter des configurations incomplètes, mais aussi d’expliquer pourquoi certains scénarios fonctionnent “presque”, tout en continuant à demander une authentification supplémentaire.

Activez l’IA sur votre Cloud PC

Microsoft continue d’intégrer des capacités d’intelligence artificielle directement au cœur de Windows. Jusqu’à présent, ces évolutions étaient principalement associées aux Copilot+ PCs, reposant sur un NPU. Avec les AI-enabled Cloud PCs annoncés lors de l’Ignite 2025, Microsoft explore une autre approche : proposer certaines expériences IA de Windows directement dans Windows 365.

Cet article présente un pas à pas de mise en œuvre, ainsi qu’un premier retour sur les fonctionnalités actuellement disponibles dans le cadre du Frontier Preview Program.

Mais comme à chaque fois, commençons par quelques questions-réponses.

Qu’est-ce qu’un AI-enabled Cloud PC ?

Un AI-enabled Cloud PC est un Cloud PC Windows 365 configuré pour activer des fonctionnalités IA avancées de Windows, sans dépendre des capacités matérielles locales du poste utilisateur :

Nous facilitons la recherche de vos documents, photos et paramètres dans Windows 11 en introduisant l’indexation sémantique en plus de l’indexation traditionnelle. Vous n’avez plus besoin de vous souvenir des noms de fichiers, des mots exacts contenus dans les fichiers ou des noms de paramètres.

blogs.windows.com

Par exemple, vous pouvez utiliser vos propres mots pour trouver des images en tapant « pont au coucher du soleil », des documents en décrivant leur contenu, comme « budget voyage en Europe », ou des paramètres, comme « modifier mon thème ».

blogs.windows.com

Il ne s’agit pas d’un NPU virtuel exposé au système, mais d’une expérience Windows enrichie par des services IA exécutés dans le cloud, puis diffusée via le streaming Windows 365.

Copilot+ PC vs AI-enabled Cloud PC :

L’approche de l’IA dans Windows repose sur le même principe, mais comme le Cloud PC est virtuel et se trouve dans le Cloud, son IA l’est également :

Copilot+ PC : poste physique avec NPU local (capacité IA “on-device”).
AI-enabled Cloud PC : poste Windows 365 exécuté dans le cloud, avec expérience IA intégrée côté Cloud PC.

Dans l’état actuel de la Frontier Preview, deux fonctionnalités sont disponibles :

Improved Windows Search

Click to Do

Qu’est-ce qu’Improved Windows Search ?

Improved Windows Search est une évolution du moteur de recherche Windows qui s’appuie sur des capacités d’IA pour interpréter l’intention de recherche, et non plus uniquement les métadonnées des fichiers (nom, emplacement). Concrètement, cela permet :

d’effectuer des recherches descriptives (par exemple sur le contenu d’un document ou d’une image),
d’obtenir des résultats plus pertinents dans la barre de recherche Windows et dans l’Explorateur de fichiers,
d’unifier la recherche entre fichiers locaux et contenus OneDrive, y compris pour des fichiers non encore téléchargés.

La précision des résultats dépend du contenu, de l’indexation et du contexte d’usage :

Qu’est-ce que Click to Do ?

Click to Do est une fonctionnalité qui permet d’exécuter des actions contextuelles à partir de ce qui est affiché à l’écran (texte ou images). Une fois activée :

l’utilisateur peut sélectionner un élément à l’écran (via Windows + clic ou Windows + Q),
Windows propose des actions adaptées au contenu détecté (par exemple copier du texte depuis une image, envoyer le contenu vers Microsoft 365 Copilot, ou lancer des actions associées).

Tout le monde peut-il déjà en profiter ?

Tout d’abord, le nombre et le type d’actions disponibles varient selon le contenu sélectionné et l’état actuel de la Frontier Preview. Ensuite, pour le moment, le Cloud PC doit respecter un certain nombre de contraintes :

Windows 365 en SKU Enterprise
256 Go de stockage disque
8 vCPU / 32 Go de RAM
Image Windows 11 récente (24H2 ou ultérieure)
Rejoindre le canal Beta du Windows Insider Program
Être déployé dans une des régions Azure suivantes :
- West US 2
- West US 3
- East US
- East US 2
- Central India
- Central US
- South East Asia
- Australia East
- UK South
- West Europe
- North Europe

Ces exigences ne sont pas anodines : elles garantissent que le Cloud PC dispose de ressources suffisantes pour exécuter les services IA dans de bonnes conditions.

Voici la procédure Microsoft que nous allons suivre dans cet article. D’autres articles, comme celui-ci, sont aussi très bon :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer de :

Un tenant Microsoft
Une licence Windows 365 Entreprise avec au minimum 8vCPU/32GB/256GB

Avant d’aller plus loin, commençons par vérifier que notre environnement répond bien aux prérequis de la fonctionnalité pour Windows 365.

Pour cela, rendez-vous dans le portail Intune, puis l’écran affichant vos différents Cloud PC :

Vérifiez le SKU de votre Cloud PC :

Vérifiez que l’image Windows 11 utilisée pour le provisionnement est au minimum en version 24H2 :

Vérifiez également que le Cloud PC est déployé dans une région Azure supportée :

Si cela n’est pas le cas, il vous est possible de déplacer très facilement votre Cloud PC via la procédure expliquée ici.

Enfin, si tous ces points sont validés, commençons par rejoindre le programme Windows Insider.

Etape I – Activation du Programme Windows Insider :

Démarrez une session sur votre Cloud PC, ouvrez les paramétrages Windows, puis cliquez ici pour rejoindre le programme Windows Insider :

Juste avant de pouvoir rejoindre le programme Windows Insider, cliquez sur cette alerte afin d’activer la remontée de données de diagnostic :

Activez l’option, puis retournez sur la page principale des paramètres Windows :

Puis, cliquez sur Commencer afin de l’activer sur votre Cloud PC :

Utilisez le compte de votre utilisateur de test pour joindre le programme :

Réutilisez le compte de votre utilisateur de test proposé dans la liste :

Choisissez le canal Beta, puis cliquez sur Continuer :

Cliquez sur Continuer pour accepter les conditions du programme liées aux données privées :

Redémarrez ensuite votre Cloud PC :

Une fois le Cloud PC redémarré, retournez sur les paramètres Windows, puis constatez l’apparition de nouvelles mises à jour :

Attendez l’installation complète de toutes les mises à jour, puis redémarrez au besoin. Une fois toutes les installations terminées, vérifiez la version Windows de votre Cloud PC :

À noter qu’il est également possible d’utiliser Intune pour basculer sur le canal Beta :

Le Cloud PC est maintenant à jour. La prochaine étape consiste à activer la fonctionnalité IA via Intune.

Etape II – Activation des fonctionnalités IA via Intune :

A noter que Microsoft propose une autre façon de passer par une stratégie Intune, via une stratégie locale, expliquée juste ici.

Dans le portail Intune, allez dans Windows 365, puis créez un nouveau groupe destiné à votre utilisateur de test pour cette nouvelle fonctionnalité IA :

Toujours sur Intune, allez dans Windows 365, puis créez une nouvelle stratégie Cloud PC configurations (preview) :

Nommez celle-ci, puis cliquez sur Suivant :

Activez la fonction IA, puis cliquez sur Suivant :

Filtrez au besoin via des Tags, puis cliquez sur Suivant :

Ajoutez votre groupe d’utilisateurs de test (Il est important de noter que cette activation est user-based. Elle ne s’appliquera qu’aux Cloud PCs respectant l’ensemble des prérequis techniques) :

Cliquez sur Créer pour terminer le processus :

Constatez la création de cette nouvelle stratégie dans l’onglet des paramétrages configurés pour vos Cloud PCs :

Déclenchez une synchronisation sur votre Cloud PC depuis la console Intune :

Un rapport affichant la fonctionnalité IA sur les les Cloud PC est disponible juste ici :

Après environ une heure, la fonctionnalité IA commence à se mettre en place sur le Cloud PC :

Le statut du démarre par le celui-ci :

C’est à ce moment précis qu’il faudra faire preuve d’un peu de patience afin de constater le changement côté utilisateur. Il sera même nécessaire de redémarrer le poste :

Une fois l’IA en place sur le Cloud PC, possiblement plusieurs heures après, le statut change de cette façon :

Il y est même expliqué pourquoi certains Cloud PC ne sont pas éligibles à l’IA :

Cette information est également disponible sur la fiche du Cloud PC :

Vous y êtes enfin ! Il ne vous reste plus qu’à vous reconnecter pour tester les changements :

Pour cela, j’ai ouvert côte à côte deux sessions Cloud PCs afin que vous puissiez voir les améliorations, une fois la fonctionnalité IA activée.

Etape III – Tests d’Improved Windows Search :

La première fonctionnalité visible est Improved Windows Search. Elle modifie en profondeur la manière dont Windows interprète les requêtes de recherche IA.

Plutôt que de se limiter aux noms de fichiers ou aux métadonnées, la recherche s’appuie davantage sur le contenu réel des documents, y compris ceux stockés dans OneDrive. Il devient possible de retrouver des fichiers à partir de descriptions plus naturelles, même si le nom du fichier est peu explicite.

Dans des environnements riches en documents, la différence avec la recherche traditionnelle est rapidement perceptible.

Voici un premier changement visuel des différents nouveaux champs de recherche IA dans Windows 11 :

Dans OneDrive, la nouvelle recherche IA montre bien des fichiers contenant AVD dans le nom, mais également des images contenant ce même terme :

Toujours dans OneDrive, la nouvelle recherche IA montre bien des fichiers contenant SYNNEX dans le nom, mais également des photos contenant ce même terme :

Cette nouvelle fonction de recherche IA marche plutôt bien je dois dire :

Même des objets y sont facilement identifiés dans les photos remontées dans la nouvelle recherche IA :

Passons maintenant à Click to Do.

Etape IV – Tests de Click to Do :

Click to Do propose une approche différente. L’objectif est de réduire le nombre d’étapes nécessaires pour interagir sur du contenu visible à l’écran. Une fois l’application lancée :

l’utilisateur peut sélectionner du texte ou une image,
des actions contextuelles sont proposées,
certaines actions peuvent s’intégrer avec Microsoft 365 Copilot.

Dans l’état actuel de la préversion, Click to Do doit être lancé au moins une fois après chaque redémarrage du Cloud PC pour être pleinement opérationnel :

Pour cela, retrouvez-le dans le menu de votre Cloud PC mis à jour :

Une fois lancé, il est possible de parcourir des sites web contenant des images de texte, d’appuyer sur la touche Windows + clic de souris dès que l’on souhaite interagir avec l’IA.

Cela vous donnera des options pour effectuer des actions sur ce que l’IA voit, comme copier du texte dans une image par exemple :

Le texte copié depuis l’image est assez bien repris grâce à l’IA :

Il est également possible de reprendre une image présente sur une page web, et de lui retirer automatiquement le fond grâce à l’IA :

Il est même possible de reprendre du texte pour préparer un prompt Copilot sous Word :

D’autres fonctions sont visibles, mais ne sont pas encore opérationnelles pour les Cloud PCs, comme celle-ci :

Pour le moment, rien ne bascule dans Microsoft 365 Copilot, cela est d’ailleurs confirmé sur la documentation Microsoft :

Enfin, Microsoft a mis à disposition une page de résolution de problème sur cette nouvelle fonctionnalité, si besoin.

Conclusion

Les Windows 365 AI-enabled Cloud PCs illustrent une orientation claire : faire du cloud le vecteur principal de diffusion des innovations IA de Windows. Plutôt que de conditionner ces fonctionnalités à un matériel spécifique, Microsoft choisit de les intégrer directement dans l’expérience Cloud PC, sous contrôle IT.

Plusieurs éléments doivent encore être gardés à l’esprit :

Les fonctionnalités sont encore en Frontier Preview
Le périmètre IA reste volontairement limité
La disponibilité dépend fortement de la région Azure et du sizing
Certains comportements peuvent évoluer sans préavis

À ce stade, il s’agit encore d’une approche exploratoire. Néanmoins, les fondations techniques et opérationnelles laissent entrevoir un potentiel intéressant pour les environnements Windows 365 à moyen terme, comme les Windows 365 for Agents :

Chalet Azure Romandie

Un an déjà… Quand on a lancé le Chalet Azure Romandie, on n’avait pas de roadmap parfaite, pas de machine bien huilée, juste une intuition : pour nous, il manquait en Suisse romande un lieu (physique et virtuel) pour parler écosystème Microsoft en français, entre passionnés, pros, étudiants, curieux. En cette fin 2025, après une année rythmée par les meetups, les échanges, les retours ultra positifs et quelques belles sueurs froides organisationnelles, j’avais envie de poser tout ça par écrit.

Ce billet, c’est un peu le journal de bord de cette première année, présenté un peu comme une FAQ : pourquoi ce chalet, comment ça a commencé, ce qu’on a appris… et où on veut aller en 2026.

Comment est née l’idée du Chalet Azure Romandie ?

À l’origine, on est trois : Seyfallah, Éric et moi. On se croise depuis un moment déjà autour de projets IT et d’autres communautés comme le Silicon Chalet, très active, très vivante, qui fait déjà beaucoup pour l’IT en Suisse romande.

On y participe sous plusieurs casquettes : parfois speakers, parfois organisateurs, parfois juste personnes dans le public avec un paquet de questions.

En enchaînant les événements, on s’est rendu compte d’une chose : il manquait un espace focalisé sur les technos Microsoft, avec une identité propre, un rythme, une ambiance à part, mais toujours dans l’esprit communauté et partage. L’idée du “Chalet Azure Romandie” est née de là :

garder l’ADN “chalet” (convivialité, proximité, réseau),
mais créer un nouveau groupe dédié au cloud Microsoft, à ses usages, ses architectes, ses développeurs, ses admins, ses décideurs.

Quand est-ce que ça a vraiment démarré ?

Si je devais mettre une date sur le début “officiel”, je dirais : la fin de la rentrée 2024. À ce moment-là, Microsoft prépare Ignite en novembre 2024, organisé à Chicago. De notre côté, Seyfallah et moi avons prévu d’y participer sur place.

C’est là que la discussion se cristallise : et si on profitait d’Ignite comme point de départ du Chalet Azure Romandie avec une idée toute simple :

“On est sur place, on a accès aux annonces, aux sessions, aux experts… Et si on ramenait tout ça en français, en direct, pour la Romandie ?”

On décide donc de lancer le premier “événement” du Chalet Azure Romandie sous forme de 2 lives à distance, démarrés via la page Meetup du Silicon Chalet.

Pourquoi le premier événement était un Ignite en “remote” depuis Chicago ?

Le plan initial était assez ambitieux (et naïf 😄) :

faire des lives depuis le salon,
animer des tables rondes,
permettre à la communauté romande de poser des questions en direct,
et tout ça dans un créneau de fin de journée pour les amis en Suisse et, plus largement, en francophonie.

Sur le papier, tout semblait gérable. En pratique, le jour J, on s’est retrouvés dans un salon avec près de 20 000 personnes, du bruit, des mouvements partout, une bande passante capricieuse… bref : impossible de tenir le format live comme prévu.

On a donc dû improviser :

on s’est éclatés en petits groupes,
on a enregistré des sessions à l’écart de la foule,
on a structuré des séquences d’échange plus calmes.

Mais le résultat en valait la peine :

deux sessions bien remplies,
environ une cinquantaine de personnes par session,
et surtout : la preuve que dès le départ, il y avait une vraie envie de contenu Microsoft en français.

Comment s’est organisée la première vraie année, en 2025 ?

En 2025, on a quitté le “mode online” pour entrer dans une vraie dynamique de meetups présentiels et réguliers. Concrètement, ça voulait dire :

trouver des salles,
trouver des sponsors,
trouver des speakers,
et répéter l’exercice 7 à 8 fois sur la première année.

On a organisé des événements à travers plusieurs villes de Suisse romande :

Genève,
Plan-les-Ouates,
Gland,
…

Côté sponsors, on a eu la chance d’être soutenus par :

Kyos,
Swissquote,
TD SYNNEX,
Ilem SA,
Squad,
Spaces,
Wavestone,
et un peu plus tard Microsoft directement sur certaines sessions.

Côté thématiques, on a couvert grâce à des speakers de qualité entre autres :

IA et Sécurité Microsoft,
Azure Landing Zones,
Dynamics 365,
AI Agents,
Azure Policy,
Fabric et l’intégration de Copilot,
et aussi des Hands-on pour mettre vraiment les mains dans le cambouis.

À quoi ressemble une soirée type au Chalet Azure Romandie ?

Rapidement, un format “signature” s’est dessiné. En général, on a :

1 à 2 talks maximum,
une présentation du sponsor,
un quiz lié au contenu des talks (parfois sérieux, parfois volontairement décalé),
des goodies pour les gagnants,
et surtout : un gros temps de networking.

Et ce dernier point est clé : on essaie de garder environ 50 % du temps de la soirée pour le réseau, les discussions, les pizzas, les bières et les échanges.

Pourquoi ? Parce que c’est là que :

les étudiants croisent les pros,
les personnes en recherche d’emploi discutent avec des gens qui recrutent ou qui connaissent des opportunités,
les admins, les architectes, les consultants partagent leurs galères, leurs bonnes pratiques, leurs idées.

À un moment, la magie opère : on n’a presque plus rien à faire. Les gens se parlent entre eux, échangent des cartes, des profils LinkedIn, des anecdotes de prod. Et c’est exactement ce qu’on voulait !

Comment avez-vous varié les formats et les speakers ?

On a essayé de ne jamais tomber dans la routine. Côté formats, on a alterné entre :

talks courts,
talks plus longs,
sessions très interactives,
labs individuels,
labs en équipe,
tables rondes.

Côté speakers, on a fait attention à plusieurs points :

inviter des personnes francophones,
mélanger speakers expérimentés et nouveaux venus,
mettre en avant les femmes dans l’IT.

Et en 2026, on veut pousser cet aspect encore plus loin : plus de diversité, plus de profils différents, plus de premières scènes.

Qu’avez-vous appris côté organisation (et galères) ?

Une année comme 2025, c’est une véritable école de l’organisation d’événements. Parmi les grandes leçons :

Anticiper beaucoup plus qu’on ne le pense : salles, matériel, restauration, communication, etc.
Structurer : qui fait quoi, quand, avec qui.
Et surtout… gérer le sujet qui fâche : les no-shows.

Les no-shows, c’est vraiment l’ennemi des meetups gratuits :

des personnes s’inscrivent,
ne viennent pas,
mais restent inscrites.

Résultat :

ça consomme de l’énergie côté orga,
ça démotive parfois les sponsors qui paient pour des places, de la nourriture, des boissons,
ça peut frustrer des personnes en liste d’attente qui, elles, seraient venues.

En 2026, on veut durcir un peu le jeu sur ce point : sans perdre l’esprit communautaire, rappeler que s’inscrire à un événement, c’est un engagement, surtout quand des sponsors financent et que des speakers parfois font plusieurs centaines de kilomètres pour venir.

Comment Microsoft est entré dans l’aventure ?

2025 a marqué un tournant : Microsoft Suisse a commencé à s’intéresser de près au Chalet Azure Romandie. Ce n’était pas “juste” un label, mais un vrai soutien humain et logistique :
des personnes comme Fabien, Dominique ou Philippe (et d’autres) ont joué un rôle important, soit en venant très tôt, soit en nous rejoignant en cours de route.

Concrètement, ça s’est traduit par :

des workshops avancés (IA, Fabric, Copilot, Power Platform…),
la présence d’experts Microsoft dans les sessions,
un dialogue plus constant entre la communauté et l’éditeur.

Pour nous, ça a été un vrai signal de confiance :

“Une petite communauté par la taille peut être grande par l’intérêt et l’engagement qu’elle génère autour des produits.”

Et Ignite 2025 dans tout ça ?

En 2025, Ignite se tenait à San Francisco. Cette fois-ci, on n’est pas repartis sur le même modèle que Chicago. On a opté pour quelque chose de plus posé :

une table ronde de débrief en fin d’année,
du partage d’expérience,
la présence d’experts,
et un événement de clôture qui a fait office de bilan 2025 et de tremplin pour 2026.

Pourquoi créer une page Meetup dédiée au Chalet Azure Romandie ?

Jusqu’à fin 2025, beaucoup de choses passaient encore par le Silicon Chalet. Pour clarifier l’identité, on a décidé de lancer une page Meetup propre au Chalet Azure Romandie avec pour objectifs :

rendre le groupe plus visible pour celles et ceux qui cherchent du contenu Microsoft,
faciliter la gestion des événements et des inscriptions,
et rejoindre officiellement le réseau des Azure Tech Groups dans le monde :

Aujourd’hui, le Chalet Azure Romandie fait donc partie de cette constellation de communautés Azure, chacune avec son identité locale mais un même objectif : partager, apprendre, connecter.

Et maintenant ? 2026, une année sous le signe de l’ouverture !

On a fêté les un an du Chalet Azure Romandie. L’énergie est là, la dynamique est très forte, et surtout : on ne manque ni d’idées, ni d’envie.

Pour 2026, nos principales intentions sont :

continuer à proposer un contenu varié (technique, décisionnel, retours d’expérience),
garder ce mix de formats (talks, labs, workshops, tables rondes),
renforcer la place des femmes dans les speakers,
consolider et élargir notre réseau de sponsors et de lieux,
et valider notre Call for Speakers pour toute l’année 2026.

D’ailleurs, l’appel à speakers pour 2026 est déjà lancé et les premiers créneaux se remplissent vite. Il y a encore de la place, et on veut :

des experts reconnus, ou des profils plus juniors qui veulent se lancer,
des sujets très techniques, ou pas,
tant que ça apporte quelque chose à la communauté Microsoft en Romandie.

Un mot pour finir ?

On est fiers du chemin parcouru en un an. On est très reconnaissants envers :

les sponsors qui nous ont fait confiance,
les speakers qui ont pris du temps pour préparer des sessions de qualité,
les participants qui sont venus, ont posé des questions, ont partagé,
les équipes de Microsoft qui ont rejoint l’initiative,
et bien sûr, le Silicon Chalet, qui reste un de nos points d’ancrage historiques.

On est aussi contents, très simplement, du travail que nous avons accompli tous les trois, et de l’énergie qu’on y a mise. Pour la suite, on a envie d’une chose :

que tu nous rejoignes, en tant que participant, speaker, sponsor, ou simple curieux.

Le Chalet Azure Romandie, c’est une aventure communautaire. On espère te voir avec nous en 2026 et au-delà.

Azure Disk Encryption / Encryption at Host / SSE

Le chiffrement des disques Azure existe depuis longtemps, mais il reste souvent mal compris : SSE, Encryption at Host, ADE… tout ne fonctionne pas au même niveau, et tout n’a pas le même impact. Je vous propose ici un tour d’horizon concret : explications, tests de performance et retour d’expérience sur la migration depuis Azure Disk Encryption.

Avant d’aller plus loin dans notre sujet, gardez toujours en tête que le processus de chiffrement concerne plusieurs états possibles de la donnée :

Dans cet article, nous aurons pour objectif de parler de la protection des données « au repos » sur les disques, afin qu’elles restent inexploitables en cas d’accès non autorisé, extraction de disque virtuel ou compromission de stockage.

Vue d’ensemble des options de chiffrement des disques de VM :

À ce jour, il existe plusieurs mécanismes de chiffrement disponibles pour vos disques de vos machines virtuelles Azure. Voici un premier récapitulatif des différents mécanismes de chiffrement disponibles sur Azure :

Azure Disk Storage Server-Side Encryption (SSE) : ce premier niveau de chiffrement est toujours activé pour les données au repos. Il chiffre automatiquement les données stockées sur les disques gérés Azure (disques OS et disques de données, à l’exception des disques temporaires et des caches disque).

Il est même possible de travailler avec d’autres clés que celles gérées par Microsoft :

Confidential disk encryption : ce mécanisme lie les clés de chiffrement des disques au TPM de la machine virtuelle et rend le contenu protégé du disque accessible uniquement à la machine virtuelle et ne permet pas que l’hyperviseur puisse déchiffrer les données.

Encryption at host : option au niveau de la machine virtuelle qui améliore le chiffrement côté serveur Azure Disk Storage afin de garantir que tous les disques temporaires et les caches disque sont chiffrés au repos et transférés chiffrés vers les clusters de stockage.

Azure Disk Encryption (ADE) : ce mécanisme chiffre le système d’exploitation et les disques de données des machines virtuelles Azure (VM) à l’intérieur de vos VM à l’aide de la fonctionnalité DM-Crypt de Linux ou de la fonctionnalité BitLocker de Windows. Azure Key Vault permet de contrôler et gérer les clés et les secrets de chiffrement de disque.

Quand ADE est activé, chaque disque de la machine virtuelle affiche alors cette information :

Une extension ADE est sur la machine virtuelle :

Est-ce que Azure Disk Encryption est déprécié ?

Azure Disk Encryption présente actuellement plusieurs limites importantes :

Le chiffrement réalisé directement dans l’OS peut entraîner une consommation CPU supplémentaire dans la VM.
ADE n’est pas compatible avec l’ensemble des types de disques ni toutes les distributions Linux.
Son intégration étroite avec l’OS et l’agent Azure le rend plus sensible et plus complexe à maintenir.

Partant de ce constat, je suppose que Microsoft a fait son choix et que ADE sera officiellement retiré le 15 septembre 2028, et propose même une stratégie de migration vers Encryption at host :

Azure Disk Encryption pour les machines virtuelles et les Virtual Machine Scale Sets sera mis hors service le 15 septembre 2028. Les nouveaux clients doivent utiliser le chiffrement sur l’hôte pour toutes les nouvelles machines virtuelles.

Les clients existants doivent planifier la migration des machines virtuelles ADE actuelles vers le chiffrement sur l’hôte avant la date de mise hors service pour éviter toute interruption de service.

Microsoft Learn

Qu’est-ce que Encryption at host ?

Encryption at Host est un mécanisme de chiffrement fourni par la plateforme Microsoft Azure permettant de chiffrer les disques de machines virtuelles au niveau de l’hôte (l’hyperviseur), avant que les données ne soient écrites sur le stockage.

Plutôt que de chiffrer les disques directement dans la machine virtuelle via BitLocker ou DM-Crypt, ce mode déplace le chiffrement sur l’hyperviseur Azure lui-même.

Cela permet de chiffrer l’ensemble des composants associés à la VM (disques OS, disques de données, disques temporaires et cache) tout en évitant la charge CPU dans la VM :

Quelles sont les restrictions liées à cette migration ?

Microsoft rappelle ici les différents points et limitations à prendre lorsque vous souhaitez migrer d’Azure Disk Encryption à Encryption at host, Voici quelques-unes d’entre elles :

Temps d’arrêt requis : le processus de migration nécessite un temps d’arrêt de machine virtuelle pour les opérations de disque et la recréation des machines virtuelles.
Aucune migration sur place : vous ne pouvez pas convertir directement des disques chiffrés par ADE en chiffrement sur l’hôte. La migration nécessite la création de disques et de machines virtuelles.
Machines virtuelles jointes à un domaine : si vos machines virtuelles font partie d’un domaine Active Directory, d’autres étapes sont requises :
- La machine virtuelle d’origine doit être supprimée du domaine avant la suppression
- Après avoir créé la machine virtuelle, elle doit être jointe au domaine
- Pour les machines virtuelles Linux, la jonction de domaine peut être effectuée à l’aide d’extensions Azure AD

Commençons par un rappel des prérequis.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur les différentes méthodes de chiffrements, il faut disposer de :

Un tenant Microsoft
Une souscription Azure valide

La suite se passera par la création d’une machine virtuelle depuis le portail Azure.

Etape I – Création de la machine virtuelle Azure :

Je commence par créer une machine virtuelle Windows Server 2025 avec 32 cœurs, afin d’éviter toute limitation liée aux performances de la VM pendant les tests :

Une fois la VM créée, j’ajoute un disque de données supplémentaire en plus du disque système. À ce stade, les deux disques utilisent le chiffrement au repos par défaut de type SSE, appliqué automatiquement par la plateforme :

Sur l’écran de configuration des disques, des Paramètres supplémentaires sont disponibles :

Je constate que le chiffrement au niveau de l’hôte n’est pas activé à ce stade. La VM utilise uniquement le chiffrement SSE, sans mécanisme supplémentaire de type ADE ou Encryption at Host :

Je me connecte à la machine virtuelle via Azure Bastion :

Je vérifie que le service BDESVC associé à BitLocker n’est pas actif et qu’aucun chiffrement au niveau du système d’exploitation n’a été configuré :

Get-Service BDESVC
manage-bde -status

Cela confirme que seul le chiffrement SSE au niveau du stockage est en place, et qu’aucune couche de chiffrement, au niveau de la machine virtuelle ou de l’hyperviseur est activée :

Afin d’étoffer mon analyse, il est intéressant de comparer les performances (IOPS, Débits et CPU) entre plusieurs types de chiffrement de stockage. Pour cela j’utiliserai l’outil de mesure Diskspd et les métriques disponibles sur le portail Azure.

Etape II – Installation de l’outil de mesure Diskspd :

L’installation de Diskspd se fait directement sur la machine virtuelle à tester :

DISKSPD est un outil que vous pouvez personnaliser pour créer vos propres charges de travail synthétiques. Nous utiliserons la même configuration que celle décrite ci-dessus pour exécuter des tests d’évaluation. Vous pouvez modifier les spécifications pour tester différentes charges de travail.

Microsoft Learn

Microsoft recommande d’utiliser l’utilitaire DiskSpd pour générer une charge sur un système de disques (stockage) et … pour mesurer les performances du stockage et obtenir la vitesse maximale disponible en lecture/écriture et les IOPS du serveur spécifique.

Windows OS Hub

Commençons maintenant les tests avec différentes méthodes de chiffrement, en commençant d’ailleurs avec uniquement SSE.

Etape III – Tests de performance avec le chiffrement au repos SSE :

Pour réaliser des tests avec Diskspd, et pour obtenir un maximum d’IOPS / débit, je lance les deux commandes PowerShell suivante :

C:\DiskSpd\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b8K -Sh -L -c50G E:\diskpsdtmp.dat > IOPS-PremiumSSDv2-0encryption.txt

C:\DiskSpd\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b64K -Sh -L -c50G E:\diskpsdtmp.dat > Throughput-PremiumSSDv2-0encryption.txt

J’ouvre Task Manager afin d’observer en temps réel l’activité du disque :

Je surveille l’utilisation CPU de la VM depuis le portail Azure :

Une fois les deux tests terminés, les fichiers sont générés dans le dossier courant :

le premier fichier TXT généré est pour consigner les IOPS :

Le second fichier TXT est généré pour consigner les débits :

Continuons les tests de performances avec Encryption at host d’activé.

Etape IV – Tests de performance avec Encryption at host :

Pour activer Encryption at host, il est d’abord nécessaire d’éteindre la machine virtuelle :

Sur l’écran de configuration des disques, je clique ici, j’active Encryption at host, puis je sauvegarde :

Une fois la modification appliquée, je redémarre la machine virtuelle :

L’activation de la fonctionnalité Encryption at host est aussi visible juste ici :

Je me reconnecte à la VM via Azure Bastion, puis je relance une seconde salve de tests avec Diskspd :

C:\DiskSpd\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b8K -Sh -L -c50G E:\diskpsdtmp.dat > IOPS-PremiumSSDv2-encryptionathost.txt

C:\DiskSpd\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b64K -Sh -L -c50G E:\diskpsdtmp.dat > Throughput-PremiumSSDv2-encryptionathost.txt

J’ouvre Task Manager afin d’observer en temps réel l’activité du disque :

Je surveille l’utilisation CPU de la VM depuis le portail Azure :

Une fois les deux tests terminés, les fichiers sont générés dans le dossier courant :

le premier fichier TXT généré est pour consigner les résultats IOPS :

Le second fichier TXT est généré pour consigner les résultats débits :

Continuons les tests de performances avec cette fois Azure Disk Encryption activé.

Etape V – Tests de performance avec Azure Disk Encryption :

Pour configurer Azure Disk Encryption, il est nécessaire de commencer par créer un Azure KeyVault :

Sur l’écran de configuration des disques, j’effectue les actions suivantes :

J’éteins la machine virtuelle,
Je désactive Encryption at host,
Je redémarre la machine virtuelle,
J’active Azure Disk Encryption avec mon Azure Key Vault (4096),
Je sauvegarde la configuration

Azure lance alors le déploiement automatique d’ADE :

Une extension s’installe alors sur la machine virtuelle :

Je me reconnecte, puis je vérifie que le service BDESVC associé à BitLocker démarre :

Get-Service BDESVC
manage-bde -status

Je constate le démarrage du chiffrement pour les deux disques de ma machine virtuelle :

Quelques minutes plus tard, le chiffrement est terminé :

Je constate l’apparition de la mention ADE sur le disque OS :

Je m’y reconnecte via Azure Bastion, puis relance une troisième salve de tests avec Diskspd :

C:\DiskSpd\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b8K -Sh -L -c50G E:\diskpsdtmp.dat > IOPS-PremiumSSDv2-ADEencryption.txt

C:\DiskSpd\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b64K -Sh -L -c50G E:\diskpsdtmp.dat > Throughput-PremiumSSDv2-ADEencryption.txt

J’ouvre Task Manager afin d’observer en temps réel l’activité du disque :

Je surveille l’utilisation CPU de la VM depuis le portail Azure :

Une fois les deux tests terminés, les fichiers sont générés dans le dossier courant :

le premier fichier TXT généré est pour consigner les résultats IOPS :

Le second fichier TXT est généré pour consigner les résultats débits :

Etape VI – Comparaison des performances de chiffrement :

Les mesures montrent que les performances des disques restent globalement équivalentes entre les trois modes, mais que l’usage CPU varie nettement, notamment lorsque le chiffrement est exécuté dans le système d’exploitation comme avec Azure Disk Encryption :

Mode de chiffrement	CPU moyen (%)
SSE (Storage Service Encryption)	1.5 %
Encryption at Host	1.0 %
ADE (Azure Disk Encryption)	2.8 %

SSE et Encryption at Host ont un impact CPU faible et comparable.

ADE présente une charge CPU sensiblement supérieure, liée au chiffrement effectué par BitLocker dans la VM, ce qui correspond à l’architecture même de ce mode.

La surcharge induite par ADE reste faible, mais l’hétérogénéité des latences confirme qu’il reste plus sensible que les modes opérés directement par la plateforme.

Etape VII – Migration d’ADE vers Encryption at host :

La migration depuis ADE vers Encryption at host sur une machine virtuelle n’est pas possible pour des raisons techniques. Voici ce qui se produit lorsqu’on tente d’activer Encryption at Host sur une VM, qui était auparavant configurée avec Azure Disk Encryption :

Microsoft liste donc ici les différentes étapes nécessaires pour réaliser cette migration. Nous allons commencer par désactiver Azure Disk Encryption.

Sur l’écran de configuration des disques, je désactive Azure Disk Encryption, puis je sauvegarde :

Une tâche Azure se déclenche, j’attends quelques minutes que celle-ci se termine :

Je me reconnecte à la machine via Azure Bastion, puis je vérifie que le service BDESVC est toujours activé et qu’une phase de déchiffrement vient de démarrer :

Get-Service BDESVC
manage-bde -status

Quelques minutes plus tard, le déchiffrement est entièrement terminé :

Malgré cela, l’extension ADE est toujours présente sur ma machine virtuelle :

Je la désinstalle depuis le portail Azure :

Quelques minutes plus tard, la notification Azure suivante apparaît :

Lancez la commande PowerShell suivante depuis Azure Cloud Shell pour chacun des disques afin de créer des disques qui ne portent pas sur les métadonnées de chiffrement ADE :

Attention : Ce script ne fonctionne pas sur les disques Premium SSDv2 et Ultra.

# Get source disk information
$sourceDisk = Get-AzDisk -ResourceGroupName "MyResourceGroup" -DiskName "MySourceDisk"

# Create a new empty target disk
# For Windows OS disks
$diskConfig = New-AzDiskConfig -Location $sourceDisk.Location -CreateOption Upload -UploadSizeInBytes $($sourceDisk.DiskSizeBytes+512) -OsType Windows -HyperVGeneration "V2"

# For Linux OS disks (if not ADE-encrypted)
# $diskConfig = New-AzDiskConfig -Location $sourceDisk.Location -CreateOption Upload #   -UploadSizeInBytes $($sourceDisk.DiskSizeBytes+512) -OsType Linux #   -HyperVGeneration "V2"

# For data disks (no OS type needed)
# $diskConfig = New-AzDiskConfig -Location $sourceDisk.Location -CreateOption Upload #   -UploadSizeInBytes $($sourceDisk.DiskSizeBytes+512)

$targetDisk = New-AzDisk -ResourceGroupName "MyResourceGroup" -DiskName "MyTargetDisk" -Disk $diskConfig

# Generate SAS URIs and copy the data
# Get SAS URIs for both disks
$sourceSAS = Grant-AzDiskAccess -ResourceGroupName "MyResourceGroup" -DiskName $sourceDisk.Name -Access Read -DurationInSecond 7200
$targetSAS = Grant-AzDiskAccess -ResourceGroupName "MyResourceGroup" -DiskName $targetDisk.Name -Access Write -DurationInSecond 7200

# Copy the disk data using AzCopy
azcopy copy $sourceSAS.AccessSAS $targetSAS.AccessSAS --blob-type PageBlob

# Revoke SAS access when complete
Revoke-AzDiskAccess -ResourceGroupName "MyResourceGroup" -DiskName $sourceDisk.Name
Revoke-AzDiskAccess -ResourceGroupName "MyResourceGroup" -DiskName $targetDisk.Name

Pour mon disque data configuré en premium SSDv2, je crée un snapshot manuellement :

Depuis le nouveau disque OS créé via le script plus haut, je relance la création d’une nouvelle machine virtuelle :

Je configure cette nouvelle machine virtuelle, en y intégrant le disque de data issu du snapshot, puis je lance sa création :

Une fois la machine virtuelle créée, j’éteins celle-ci, puis j’active Encryption at host dans les paramétrages des disques :

Je redémarre la machine virtuelle, puis je constate dans l’affichage du diagnostic le bon démarrage de celle-ci :

Conclusion

Au final, SSE et Encryption at Host couvrent aujourd’hui l’essentiel des besoins, avec un impact quasi nul sur la VM et une gestion simplifiée. SSE reste la base, toujours activée, tandis qu’Encryption at Host ajoute une couche complète de protection sans coût CPU notable.

ADE fonctionne encore, mais son intégration à l’OS et sa charge CPU supplémentaire en font une solution plus lourde à exploiter. Avec les résultats obtenus et sa dépréciation annoncée, il devient clairement le mécanisme à éviter pour les nouvelles machines virtuelles.

SSE : excellente base, impact minimal, tout est géré par la plateforme.

Encryption at Host : même niveau de performance que SSE, avec la garantie que toutes les couches (OS, data, cache, disque temporaire) sont chiffrées directement par l’hyperviseur.

ADE : Performances disque similaires, mais CPU plus élevé, dû au chiffrement dans la VM. Cela confirme pourquoi ce mode est progressivement remplacé par les autres mécanismes gérés par la plateforme.

Pour la majorité des workloads, Encryption at Host apparaît désormais comme l’option la plus propre, la plus simple et la plus pérenne.

Testez Microsoft Foundry

Bienvenue dans ce lab pratique consacré à Microsoft Foundry, la plateforme unifiée qui permet d’explorer, tester et déployer des expériences d’intelligence artificielle au sein de l’écosystème Azure. Cet article retrace pas à pas les différentes étapes du lab afin de permettre à chacun de revivre l’expérience ou de la reproduire en autonomie.

Lors du Chalet Azure Romandie du 27 novembre 2025, les participants ont pu découvrir concrètement comment manipuler des modèles avancés comme gpt-4o et Sora, créer leurs propres agents, générer des vidéos IA, ajouter des filtres de sécurité, traduire des documents, ou encore produire un avatar animé.

Voici donc les 5 défis que vous pouvez également essayer :

Le Chalet Azure Romandie remercie d’ailleurs Philippe Paiola de chez Microsoft pour la création de ces défis 🙏.

Etape 0 – Connexion à Microsoft Foundry :

Pour réaliser cet exercice sur Microsoft 365 Archive, il vous faudra disposer d’une souscription Azure valide.

Ouvrez un navigateur web, puis saisissez l’URL du portail Azure AI Foundry (nouvellement Microsoft Foundry) :

Authentifiez-vous avec un e-mail professionnel ou personnel :

Une fois authentifiée, conservez l’ancienne présentation du portail de Microsoft Foundry, appelée encore Azure AI Foundry, afin de suivre les consignes ci-dessous plus facilement :

Commençons le premier défi par le déploiement d’un agent.

Défi I – Création d’un Agent Smith :

Nous allons déployer un agent qui s’appuiera sur le modèle gpt-4o et répondra aux différentes questions du défi.

Pour cela, cliquez-ici pour créer votre agent :

Mais comme aucun projet IA n’est encore présent, nous allons commencer par la création de celui-ici. Pour cela, renseignez les informations pour la création de votre nouveau projet IA, puis lancez sa création :

Dans le champ Projet, saisissez projet-agent
Développez options avancées
Choisissez la souscription Azure disponible
Donnez un nom unique à votre ressource Azure AI Foundry
Nommez rg-chalet-romandie le nom de votre groupe de ressource
Vérifiez que la région Azure East US 2 est bien sélectionnée

Attendez environ 2 à 3 minutes pour la fin de la création des ressources Azure :

Une fois le déploiement terminé, cliquez sur le menu Playgrounds afin de commencer par le déploiement d’un premier modèle IA, recherchez dans la liste le modèle gpt-4o, puis cliquez sur le bouton Confirmer :

Conservez les options de base de votre modèle, puis cliquez sur le bouton Déployer :

Une fois le modèle IA déployé, retournez dans le menu Playgrounds afin de lancer le prompt suivant sur le nouvel agent, automatiquement créé et lié à votre modèle :

Générer une blague sur les informaticiens

L’erreur suivante peut apparaître. Elle indique que les ressources IA ne sont pas encore entièrement accessibles :

Après plusieurs minutes et plusieurs essais, vous devriez obtenir une réponse dans le chat de la part de votre agent IA :

Votre défi est réussi, vous pouvez le faire valider, puis passez au défit suivant.

Défi II – Génération d’une vidéo IA :

Imaginez pouvoir créer des scènes vidéo réalistes, des animations et des effets spéciaux, à partir d’instructions textuelles simples et précises. Foundry vous permet de réaliser cette prouesse à l’aide du modèle Sora d’OpenAI.

La génération de vidéos dans ce cas est un processus asynchrone. Vous créez une demande de travail avec vos spécifications d’invite (ou prompt en anglais) de texte et de format vidéo, et le modèle traite la demande en arrière-plan.

Une fois terminé, récupérez la vidéo générée via une URL de téléchargement.

Cliquez sur le menu à gauche Playgrounds, puis le menu suivant afin de tester la génération de vidéos par l’IA :

Cliquez ici pour déployer un nouveau modèle IA destiné à la génération de la vidéo :

Choisissez le modèle Sora dans la liste, puis cliquez sur Confirmer :

Conservez les options de base, puis cliquez sur le bouton Déployer :

Une fois le modèle Sora déployé, retournez dans le menu Playgrounds afin de lancer le prompt de génération de la vidéo :

Sélectionnez la résolution 720p, une durée de 10 secondes, saisissez votre prompt qui générera une vidéo époustouflante, puis cliquez sur le bouton Générer.

Attendez quelques instants avant de pouvoir constater le résultat :

Après quelques instants, visionnez le résultat généré par Sora :

Votre défi est réussi, vous pouvez le faire valider, puis passer au défit suivant.

Défi III – Filtrage IA de contenu :

Microsoft Foundry embarque en standard les composants Azure AI Content Safety pour filtrer les contenus répréhensibles générés ou traités (détection de langage toxique, données personnelles partagées, etc…).

Nous allons créer un filtre et une liste de blocage basés sur le mot AWS. Nous allons dans un premier temps créer une liste de blocage :

Saisissez un nom représentant la liste, blocklistaws, puis cliquez sur le bouton suivant pour créer celle-ci :

Ajoutez un nouveau terme :

Saisissez le terme AWS, puis ajoutez-le :

Nous allons maintenant créer notre propre filtre de contenu et l’associer à notre liste de blocage. Pour cela, cliquez sur le bouton ci-dessous pour créer un filtre de contenu :

Saisissez un nom représentant le filtre, filtrereomandie, puis cliquez sur le bouton Suivant :

Dans l’étape Filtre d’entrée, pour chaque catégorie (haine, violence …), spécifiez le niveau de dureté appliqué à Highest blocking , cochez la case Liste de blocage, sélectionnez blocklistaws, puis cliquez sur Suivant :

Dans l’étape Filtre de sortie, pour chaque catégorie (haine, violence …), spécifiez le niveau de dureté appliqué à Highest blocking , cochez la case Liste de blocage, sélectionnez blocklistaws, puis cliquez sur Suivant :

Sélectionnez le modèle qui recevra ce filtre de contenu personnalisé, dans notre cas gpt-4o :

Confirmez le remplacement du filtrage de contenu de page par le nouveau :

Lancez la création du filtrage IA :

Retournez dans Playgrounds, puis cliquez sur Chat playground :

Collez le prompt suivant dans le chat :

Comment utiliser AWS ?

Un retour négatif de la part d’Azure IA Foundry, et invoquant blocklistaws, devrait apparaître. Continuez avec le prompt suivant :

Comment me faire très mal au bras ?

Un retour négatif de la part d’Azure IA Foundry, et invoquant Self-harm, devrait apparaître.

Votre défi est réussi, vous pouvez le faire valider, puis passer au défit suivant.

Défi IV – Traduction IA de documents :

La traduction automatique est l’un des domaines historiques de l’IA de Microsoft. L’entreprise propose un service de traduction basé sur des réseaux de neurones, connu sous le nom d’Azure AI Translator, capable de traduire instantanément du texte ou des documents entiers d’une langue à une autre.

Cliquez sur le menu suivant afin de générer une traduction de texte :

Cliquez sur Text translation :

Collez le texte suivant, choisissez le français comme langue de destination, puis lancez la traduction :

好⼀朵美丽的茉莉花
好⼀朵美丽的茉莉花
芬芳美丽满枝桠
又⾹又⽩⼈⼈夸
让我来将你摘下
送给别⼈家
茉莉花呀茉莉花

Constatez le résultat traduit :

Passons maintenant au dernier défi IA.

Défi V – Avatar IA :

Azure Speech permet en résumé de tester et prototyper rapidement des fonctionnalités de reconnaissance vocale, conversion texte-vers-voix, traduction audio, etc., sans avoir à tout coder ou déployer de façon complète.

Cliquez sur le menu suivant afin de générer un avatar :

Choisissez le menu Text to speech avatar, puis cliquez sur Lisa parmi la liste des avatars disponibles :

Définissez la langue française, la voix de Vivienne, collez le texte ci-dessous, puis lancez la génération de la vidéo :

Romandie un jour, Romandie toujours.

Attendez quelques secondes la fin de la génération de la vidéo :

Une fois la vidéo générée, lancez-là pour en vérifier le contenu :

Une fois tous les défis terminés :

Conclusion

Ce parcours à travers Microsoft Foundry met en lumière la richesse des outils IA disponibles aujourd’hui : agents personnalisés, génération multimédia, filtrage de contenu, traduction, ou encore avatars vocaux.

Chaque défi illustre la maturité croissante de l’écosystème et la facilité avec laquelle il devient possible d’expérimenter, prototyper et imaginer de nouvelles solutions basées sur l’IA.

Que ce lab inspire de futurs projets et continue d’alimenter la dynamique d’innovation au sein de la communauté !

FSLogix pour Entra ID !

Depuis de longues années, la communauté Azure Virtual Desktop attendait la possibilité de déployer un environnement entièrement cloud, sans dépendance à un domaine Active Directory classique ou à une architecture hybride complexe. Cette évolution permet enfin d’envisager un modèle moderne, simplifié et résolument cloud-native.

Lors du premier jour de Microsoft Ignite 2025 à San Francisco, Microsoft a dévoilé la préversion publique d’une fonctionnalité demandée depuis longtemps : la prise en charge des profils FSLogix stockés sur un compte Azure Files directement joint à Entra ID. Une étape majeure dans la modernisation de l’environnement AVD.

Au-delà du progrès technique évident (principalement la simplification de l’infrastructure) cette nouveauté transforme aussi la manière d’aborder la gestion des accès distants et des profils utilisateurs.

Elle marque le passage d’un modèle traditionnel mêlant domaine Active Directory, synchronisation, et Kerberos hybride, vers un modèle entièrement cloud-only : plus léger, plus agile et parfaitement adapté aux organisations modernes, aux partenaires externes ou encore aux environnements projet éphémères.

Cette annonce fut d’ailleurs intégrée à celle des identités externes sur AVD et Windows 365 :

Pour offrir une expérience simplifiée dans un environnement mutualisé Azure Virtual Desktop pour les identités externes, vous pouvez créer un partage de fichiers dans Azure Files afin de stocker les profils FSLogix pour ces identités.

Cette fonctionnalité est désormais disponible en préversion publique. Pour créer un partage de fichiers SMB pour les profils FSLogix pour les identités externes :

Créez un nouveau compte de stockage et un nouveau partage de fichiers configurés pour utiliser l’authentification Microsoft Entra Kerberos.(Nouveau) Lorsque vous attribuez des autorisations pour le partage de fichiers, utilisez la nouvelle page Gérer l’accès pour attribuer des listes de contrôle d’accès (ACL) au groupe Entra ID contenant vos identités externes.

Microsoft Techcommunity

Microsoft illustre également cette nouveauté avec une copie d’écran montrant la gestion native des droits NTFS d’un partage Azure Files directement depuis le portail Azure, ce qui constitue une avancée très attendue :

Qu’est-ce qu’une identité cloud-only ?

Il s’agit d’un utilisateur géré uniquement dans Entra ID, sans représentation dans un Active Directory on-prem, ni synchronisation : idéal pour des contractors, partenaires, ou utilisateurs externes.

Est-ce que FSLogix fonctionne avec ces identités externes / cloud-only ?

Oui, le support FSLogix pour cloud-only & external identities est désormais en preview, ce qui permet de gérer les profils utilisateurs de façon identique à un utilisateur « classique ».

Que change concrètement pour un architecte cloud ou un administrateur ?

Cela signifie moins de dépendances à un AD on-prem, moins de complexité, une gestion simplifiée des utilisateurs externes ou contractors, et un modèle plus cloud-native.

Plusieurs vidéos sont également disponible pour vous aider à la tâche :

Pour y parvenir, plusieurs documentations sont disponibles afin de mettre en place toute la chaîne. Le premier guide Microsoft explique comment activer Kerberos Entra sur Azure Files, tandis que le second part de ce socle et donne seulement ce qu’il faut ajouter pour FSLogix :

Je vous propose donc de passer en revue, étape par étape, l’ensemble de la configuration permettant de tester cette nouvelle fonctionnalité encore en préversion.

L’objectif est de comprendre son fonctionnement réel, ses limites et les scénarios dans lesquels elle pourra s’intégrer :

Etape 0 – Rappel des prérequis :

Pour réaliser ce test FSLogix en mode 100% Cloud-only, il vous faudra disposer de :

Un abonnement Azure valide
Un tenant Microsoft

Afin d’être sûr des impacts de nos différentes actions, je vous propose de commencer par la création d’une nouvel utilisateur 100% Cloud, donc non synchronisé à un environnement Active Directory.

Etape I – Préparation de l’environnement :

Création d’un utilisateur cloud-only pour préparer l’environnement sans synchronisation AD :

Mise en place du réseau virtuel qui servira de base à l’environnement Azure Virtual Desktop :

Déploiement d’un compte de stockage Azure Files Premium pour accueillir les profils FSLogix :

Activation de l’identité Microsoft Entra directement sur le compte de stockage :

Activation du support Microsoft Entra Kerberos pour gérer l’authentification :

Application des permissions par défaut via le rôle Storage File Data SMB Share Contributor :

Création du partage de fichiers pour FSLogix, avec l’identité Microsoft Entra toujours active :

Recherche de l’application d’entreprise générée automatiquement pour ce compte de stockage :

Attribution du consentement administrateur global pour autoriser l’application

Validation de l’autorisation accordée à l’application d’entreprise :

Vérification des permissions héritées depuis l’admin consent sur l’application liée au stockage :

Retrait du compte de stockage dans les polices d’accès conditionnel exigeant une MFA :

Création d’un environnement Azure Virtual Desktop avec deux machines virtuelles :

Activation du Single Sign-On directement dans les propriétés RDP :

Exécution du premier script PowerShell via Run Command pour activer la récupération du ticket Kerberos :


reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1 /f

Confirmation que la clé de registre est bien apparue :

Exécution du second script PowerShell via Run Command pour activer le chargement des clés d’identités pour la gestion FSLogix :

reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1

Vérification de la création de la clé de registre attendue dans Windows :

Application de la configuration complète FSLogix via les différentes clés de registre :

reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v DeleteLocalProfileWhenVHDShouldApply /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v FlipFlopProfileDirectoryName /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v LockedRetryCount /t REG_DWORD /d 3 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v LockedRetryInterval /t REG_DWORD /d 15 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ProfileType /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ReAttachIntervalSeconds /t REG_DWORD /d 15 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v ReAttachRetryCount /t REG_DWORD /d 3 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v SizeInMBs /t REG_DWORD /d 30000 /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v VHDLocations /t REG_MULTI_SZ /d "\\cloudonlysa.file.core.windows.net\profiles" /f
reg add "HKLM\SOFTWARE\FSLogix\Profiles" /v VolumeType /t REG_SZ /d "VHDX" /f

Vérification de la création des clés de registre attendues pour FSLogix :

Alternative via Intune pour gérer ces mêmes paramètres sans script :

Redémarrage des machines virtuelles du host pool pour appliquer la configuration :

Etape II – Test de connexion AVD :

Attente du retour en ligne des machines dans l’environnement AVD :

Activation du mode de drainage sur la seconde machine pour préparer les tests :

Connexion avec l’utilisateur de test pour valider le fonctionnement :

Observation du démarrage du service FSLogix App Services à l’ouverture de session :

Création du dossier de profil FSLogix directement dans le file share :

Présence du fichier VHDx correspondant au profil utilisateur :

Impossibilité de supprimer le fichier VHDx car il est monté et en cours d’utilisation :

Confirmation dans les logs FSLogix que le profil VHDx est correctement chargé :

Inversion du mode de drainage sur les deux machines AVD :

Reconnexion avec l’utilisateur de test pour valider la bascule du profil :

Montage d’un partage réseau pour inspecter le contenu du partage de fichier Azure :

Vérification que la permission générée pour l’utilisateur de test est bien présente :

Afin de finaliser correctement la configuration des permissions pour les profils FSLogix, il est nécessaire de les restreindre pour plus de sécurité.

Etape III – Configurations des permissions NTFS Access Control Lists :

Depuis l’explorateur Windows, je constate que certaines permissions restent visibles, alors qu’elles ne devraient être retirées pour des questions de sécurité :

Je constate également l’impossibilité de modifier les permissions directement depuis Windows ou via une commande ICACLS :

Comme l’indique la documentation Microsoft ci-dessous, tout ne semble pas encore au point :

Travis Roberts rencontre d’ailleurs le même souci que moi :

Pour configurer les Windows ACLs, il sera donc nécessaire de passer par le menu Manage Access, visible depuis un portail Azure en préversion, comme le recommande Microsoft dans la documentation :

Le bouton Manage access est alors visible juste ici :

Ce menu n’est d’ailleurs pas visible dans le portail classique d’Azure :

L’affichage des permissions NTFS Access Control Lists configurées par défaut :

Les permissions pour FSLogix doivent alors être reconfigurées comme telles :

Cela donne ceci sur le partage de fichier FSLogix :

Les tests initiaux montrent que l’intégration fonctionne correctement entre FSLogix et Azure Virtual Desktop. Toutefois, quelques écarts apparaissent encore entre la documentation Microsoft et le comportement observé dans mon environnement, ce qui mérite d’être signalé dans le cadre de cette préversion.

Pour compléter mon analyse, il est intéressant de comparer les performances (IOPS et Throughput) entre plusieurs types de stockage, notamment ceux intégrés avec Entra ID.

Etape IV – Tests de performances :

J’ai souhaité comparé les performances entre différents types de stockage afin de bien comprendre l’impact ou non des performances avec cette jointure à Entra ID :

Partage de fichiers sur un compte de stockage Premium joint à Entra ID
Partage de fichiers sur un compte de stockage Premium non joint à Entra ID
Disque Premium SSD v2, configuré avec 30000 IOPS et 1200 de Throughput

Pour réaliser les mesures, nous utiliserons l’outil Diskspd :

DISKSPD est un outil que vous pouvez personnaliser pour créer vos propres charges de travail synthétiques. Nous utiliserons la même configuration que celle décrite ci-dessus pour exécuter des tests d’évaluation. Vous pouvez modifier les spécifications pour tester différentes charges de travail.

Microsoft Learn

Microsoft recommande d’utiliser l’utilitaire DiskSpd (https://aka.ms/diskspd) pour générer une charge sur un système de disques (stockage) et … pour mesurer les performances du stockage et obtenir la vitesse maximale disponible en lecture/écriture et les IOPS du serveur spécifique.

Windows OS Hub

Sur votre machine virtuelle de test, téléchargez l’exécutable via ce lien Microsoft, puis ouvrez l’archive ZIP téléchargée :

Copiez le contenu de l’archive dans un nouveau dossier créé sur le disque C :

L’exécutable se trouve dans le sous-dossier amd64 :

Les 2 étapes suivantes sont dédiées aux tests de performances des disques via l’application Diskspd. Microsoft met d’ailleurs à disposition un protocole similaire de tests juste ici :

Deux séries de tests sont conseillées pour exploiter le deux caractéristiques suivantes :
- IOPS
- Débit
Le changement entre ces deux séries se fera au niveau de la taille des blocs.

Commencez une première salve de tests pour déterminer les IOPS max pour chacun des espaces de stockage :

Partage de fichiers sur un compte de stockage Premium joint à Entra ID :

Partage de fichiers sur un compte de stockage Premium non joint à Entra ID :

Disque Premium SSD v2 configuré avec 30000 IOPS et 1200 de Throughput :

Ouvrez Windows PowerShell ISE, puis lancez les commandes des test suivantes, une à une ou à la chaîne, en modifiant les paramètres si besoin :

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G Y:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-AvecEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G W:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-SansEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b8K -Sh -L -c50G E:\diskpsdtmp.dat > C:\SPD\amd64\IOPS-PSSDv2.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G Y:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-AvecEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G W:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-SansEntraID.txt 

C:\SPD\amd64\diskspd.exe -d180 -r -w100 -F4 -o128 -b64K -Sh -L -c50G E:\diskpsdtmp.dat > C:\SPD\amd64\Throughput-PSSDv2.txt

Les arguments utilisés pour diskspd.exe sont les suivants :

-d900 : durée du test en secondes
-r : opérations de lecture/écriture aléatoires
-w100 : rapport entre les opérations d’écriture et de lecture 100%/0%
-F4 : nombre de threads max
-o128 : longueur de la file d’attente
-b8K : taille du bloc
-Sh : ne pas utiliser le cache
-L : mesure de la latence
-c50G : taille du fichier 50 GB
E:\diskpsdtmp.dat : chemin du fichier généré pour le test
> IOPS-AvecEntra.txt : fichier de sortie des résultats

Une fois tous les tests terminés, les résultats sont alors compilés pour les 3 stockages :

Scenario	IOPS	Bandwidth MB/s
Avec Entra ID	12,446.88	299.95
Sans Entra ID	15,032.54	341.17
Premium SSD v2	20,378.31	1,167.25

Les résultats montrent que le Premium SSD v2 délivre les meilleures performances dans ton environnement, avec le plus haut niveau d’IOPS et de bande passante, suivi par le scénario Sans Entra ID, puis par le scénario Avec Entra ID qui obtient systématiquement les valeurs les plus faibles.

La différence entre les scénarios avec et sans Entra ID pourrait s’expliquer par la présence d’une couche d’authentification et de gestion de profils qui ajoute des opérations supplémentaires lors des accès disque, en particulier si le système doit interroger un service distant, valider un token, ou maintenir une session d’identité pour chaque opération liée au profil utilisateur.

Même si cette charge reste faible en théorie, elle peut introduire une latence additionnelle dans un flux d’I/O intensif, ce qui réduirait mécaniquement les IOPS et la bande passante observées.

Conclusion

Le support des identités cloud-only et externes pour Azure Virtual Desktop, associé à l’intégration de FSLogix, représente une évolution majeure dans l’écosystème Microsoft. Cette approche permet désormais de déployer des environnements VDI complets sans aucune dépendance à Active Directory, tout en simplifiant considérablement l’architecture.

Cette modernisation apporte davantage de flexibilité, réduit les contraintes opérationnelles et ouvre la voie à de nouveaux scénarios cloud-native, adaptés aussi bien aux entreprises qu’aux équipes projet, partenaires ou prestataires externes.

Bien que la fonctionnalité soit encore en préversion, elle laisse entrevoir un futur où les environnements virtualisés seront plus simples, plus économiques et mieux intégrés à l’identité Microsoft Entra.