Windows 365 Link

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 :

Etape 0 – Configuration de base
Etape I – Activation d’Entra ID Account Recovery
Etape II – Préparation du compte utilisateur de test
Etape III – Test de récupération de compte

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 :

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.

Quelques nouveautés sur M365 Copilot

Microsoft 365 Copilot évolue constamment, et à un rythme très soutenu. Comme beaucoup, j’ai du mal à suivre ces changements en temps réel, car plusieurs facteurs entrent en jeu. D’abord, le temps nécessaire pour se tenir à jour représente déjà une contrainte importante. S’y ajoutent la diversité des canaux de communication utilisés par Microsoft pour annoncer les nouveautés, ainsi que les disparités de déploiement : certaines fonctionnalités sont disponibles plus tôt dans certains tenants ou pays que dans d’autres. Bref, chacun fait comme il peut, et c’est déjà pas mal.

Cela étant dit, j’aimerais prendre un moment pour faire le tour de quelques nouveautés que je trouve particulièrement intéressantes. Ces informations proviennent à la fois des notes officielles de Microsoft et de certaines chaînes YouTube qui font, il faut le reconnaître, un excellent travail de vulgarisation et de démonstration :

Lisa Crosbie

Elliott Pierret

Shervin Shaffie

Mike Tholfsen

Mon objectif est donc de partager avec vous certaines de ces découvertes et, lorsque c’est possible, d’y ajouter quelques retours issus de mes propres tests :

Fonctionnalité I – Utilisez plus souvent GPT-5 :

Depuis plusieurs mois maintenant, GPT‑5 est désormais intégré comme modèle principal pour Copilot. L’utilisation de GPT-5 permet une réponse plus riche : meilleure compréhension du contexte, capacité à traiter des documents volumineux ou complexes :

Copilot Chat est en train de passer au dernier modèle d’IA générative d’OpenAI, le modèle GPT-5, en tant que LLM principal de prise en charge. Essayez GPT-5 avec vos invites Copilot en sélectionnant le bouton Essayer GPT-5 en haut à droite dans Copilot Chat.

Microsoft

Vous pouvez utiliser le bouton Essayer GPT-5 dans Copilot Chat que vous disposiez ou non d’une licence Microsoft 365 Copilot, mais l’accès peut être limité en période de forte charge.

L’activation du mode GPT-5 est visible en haut à droite de Copilot :

Quelques remarques :

Vous devez activer GPT-5 pour chaque nouvelle conversation.
Vous pouvez activer GPT-5 même après avoir commencé à saisir votre premier prompt, et cela sans en perdre la saisie,
Il n’est pas possible de basculer sur GPT-5 dès que la conversation a démarré.
Une fois GPT-5 activé, la conversation continuera de travailler avec lui :

Voici un exemple de prompt que je souhaite poser à GPT-4 et GPT-5 pour voir leur réponse et les comparer :

Agis comme un architecte cloud senior chargé de présenter à la direction d’une entreprise internationale (800 employés, multi-sites, multi-fuseaux) une proposition stratégique complète pour moderniser son environnement Microsoft 365.

Contexte : L’entreprise a une infrastructure hybride (Active Directory local, Exchange on-premises, quelques workloads déjà sur Azure).
Les équipes utilisent encore des outils locaux (fichiers partagés, VPN, emails internes) et peinent à collaborer efficacement à distance.
La direction veut réduire les coûts, améliorer la sécurité, et accélérer la collaboration avec Microsoft 365 et Azure AD/Entra ID.

Tâche : 
- Rédige un document de cadrage exécutif présentant :
- Une synthèse stratégique (valeur métier, enjeux, risques, bénéfices attendus)
- Une proposition d’architecture cible (identités, sécurité, collaboration, données, gouvernance)
- Un plan de transformation (étapes, jalons, gouvernance projet, rôles, communication interne)
- Des indicateurs de succès (KPIs), différenciant la vision IT et la vision métier
- Une conclusion exécutive résumant l’impact global de la transformation

Contraintes :

- Rédige avec un ton professionnel, synthétique et narratif.
- Le document doit sembler prêt à être présenté à un COMEX.
- Utilise la mise en page Markdown avec des titres, sous-titres et éventuellement des tableaux synthétiques.
- Sois précis mais fluide : évite les listes sèches et ajoute des transitions naturelles.

Et cela nous permet de sortir une comparaison des réponses données par Copilot en fonction de ces deux modèles, vu par ChatGPT :

Avec le même prompt, GPT-4 fait un très bon travail de structuration technique, il produit un livrable cohérent et complet.
GPT-5, lui, comprend le contexte exécutif : il ne se contente pas d’empiler des points, il raconte la transformation, hiérarchise l’information, et adapte le ton à une audience de direction.

Pourquoi devoir recliquer à chaque fois ?

Cela peut paraître agaçant, mais le bouton existe pour des questions économiques : cela permet d’éviter une activation automatique, et donc une meilleure maîtrise des coûts et des performances.

Fonctionnalité II – Explorer avec l’agent Researcher :

L’agent Researcher de Microsoft 365 Copilot s’apparente à un assistant de recherche avancé, spécialement conçu pour traiter des tâches complexes et multi-étapes.

Plutôt que de se contenter d’une réponse rapide à une question, l’agent Researcher croise vos contenus professionnels (documents, courriels, discussions, fichiers) avec des sources web fiables pour produire un rapport structuré : sections thématiques, visuels (graphiques, tableaux), et citations explicites des sources.

Researcher est donc particulièrement utile quand il s’agit de faire de la veille technologique, un benchmark, une analyse d’un domaine, ou l’élaboration d’un dossier que l’on pourra partager ou présenter :

Il diffère de la fonction de “chat classique” de Copilot : alors que celle-ci vise rapidité, synthèse simple ou support conversationnel, Researcher est optimisé pour un travail en profondeur avec plus de réflexion, plus de temps de traitement et un livrable plus riche.

Quand privilégier Research par rapport Chat classique :

Si tu dois préparer une réunion, un dossier stratégique ou un benchmark, Researcher va compiler et croiser les informations pertinentes bien au-delà de ce que le chat classique peut proposer.
Pour toute question nécessitant de vérifier, nuancer ou justifier avec des sources croisées et fiables, Researcher est clairement plus adapté.
Lorsque la rapidité n’est pas la priorité et qu’il te faut de la profondeur, de la précision et une vue d’ensemble.

Peut-être que le second agent, Analyst, pourrait aussi vous être utile :

Fonctionnalité III – Partagez vos prompts avec vos équipes

Historiquement, Microsoft 365 Copilot permettait déjà de sauvegarder des prompts dans une galerie personnelle, offrant ainsi la possibilité de retrouver facilement ses requêtes récurrentes et de les réutiliser :

Cette fonctionnalité a évolué pour aller plus loin : désormais, il est possible non seulement de conserver ses prompts, mais aussi de les partager avec une équipe, favorisant la collaboration et la cohérence dans l’usage des prompts au sein d’un groupe.

Commencez par sauvegarder un prompt dans la galerie personnelle :

Retournez dans la galerie afin de partager :

Sélectionnez d’une équipe spécifique :

Cela crée un nouvel onglet dans la galerie montrant les prompts partagés dans la galerie aux équipes :

Fonctionnalité IV – Activez Claude dans M365 Copilot :

Claude est un modèle d’intelligence artificielle développé par Anthropic, conçu pour offrir des capacités avancées de génération de texte, d’analyse et d’assistance contextuelle. Il se distingue par son approche axée sur la sécurité et la transparence, ce qui en fait un outil fiable pour les entreprises souhaitant intégrer l’IA dans leurs processus.

Depuis peu, il est possible d’activer Claude via le portail Microsoft 365 Admin Center. Cette fonctionnalité permet aux administrateurs de rendre Claude disponible pour les utilisateurs en quelques clics :

Une fois activé, le statut change dans la console, confirmant que Claude est opérationnel :

Voici l’interface avant activation, sans le bouton Claude :

Voici l’interface après activation, avec le bouton Claude :

Voici l’interface avec utilisation du modèle Claude :

Je souhaite en savoir un peu plus sur lui-même, et donc je lui pose la question sur le modèle utilisé :

Il en ressort plusieurs pistes de modèles envisagés :

Attention néanmoins une chose importante :

Lorsque votre organisation choisit d’utiliser un modèle Anthropic, elle accepte de partager ses données avec Anthropic afin d’alimenter les fonctionnalités. Ces données sont traitées en dehors de tous les environnements et contrôles d’audit gérés par Microsoft ; par conséquent, les accords clients de Microsoft, y compris les Conditions des produits et l’Addendum relatif au traitement des données, ne s’appliquent pas.

Microsoft Learn

Cela nous amène donc à se soumettre aux règles de traitement des données émises par Anthropic :

Pour évaluer l’impact de Claude, un prompt a été testé avec et sans Claude :

Who are the key players on the [Stade Toulousain / La Rochelle] rugby team, and what are their 2025 Top 14 stats — including appearances, tries, tackles, points, and how long they've been with the club?

Prompt avec Researcher et Claude :

Prompt avec Researcher sans Claude :

L’objectif est de comparer les réponses et d’identifier les différences de raisonnement entre Research, et Research + Claude via l’analyse de chatGPT-5 :

Ce test met en évidence la valeur ajoutée de Claude en termes de précision et de contextualisation :

Critère	Key Players and 2025 Top 14 JLO.docx	Key Players and 2025 Top 14 ANNA.docx
Structure du texte	Explicative, incomplète, avec excuses techniques.	Structurée, complète, avec tableaux et données détaillées.
Niveau de données	Généralités (meilleurs marqueurs du championnat, sources officielles citées, pas de chiffres précis par joueur).	Statistiques chiffrées par joueur, par équipe (apparitions, essais, plaquages, points, année d’arrivée).
Style de ton	Excuses, proposition d’alternatives, formulation prudente et narrative.	Informatif, orienté data, structuré en tableaux avec contexte analytique.
Sources citées	LNR.fr, All.Rugby, Ultimate Rugby, RugbyPass (mais sans données concrètes).	LNR.fr et sources officielles, mentionnées à la fin de chaque section.
Degré de complétude	Faible : pas de données par joueur.	Élevé : tableau complet pour Toulouse et La Rochelle.
Langage	Rédigé à la première personne (“I apologize”, “Would you like me to…”).	Neutre et objectif (“Below is the full Toulouse squad…”).
Style d’IA reconnaissable	Typique d’un agent de type Claude (Anthropic) : ton empathique, explicatif, s’excuse pour limitations.	Typique d’un agent Research classique / GPT : structuration analytique, données brutes et tables.

chatGPT-5 identifie très facilement le fonctionnement de Researcher avec et sans Claude :

Fichier	Type probable de génération	Justification
Key Players and 2025 Top 14 JLO.docx	🧠 Claude (Anthropic)	Ton conversationnel, excuses, impossibilité d’accéder aux données, approche narrative typique d’Anthropic.
Key Players and 2025 Top 14 ANNA.docx	🔍 Research classique (type OpenAI)	Présentation analytique, structuration en tableaux complets, ton factuel et format de rapport structuré.

Fonctionnalité V – Créez une conversation de groupe Teams à la suite de prompts :

Une fois la conversation démarrée avec Copilot, un bouton apparaît en haut à droite. Il permet la création nouveau groupe de conversation avec l’IA et d’autres personnes :

Copilot vous demande le nom des participants à ce nouveau groupe de conversation, ainsi que la longueur de l’historique de conversation Copilot :

Une fois le nouveau groupe de conversation créé, celui-ci est accessible directement depuis Teams :

Les membres de ce nouveau groupe de conversation sont visibles et l’IA en fait bien partie :

Fonctionnalité VI – Activer le programme Microsoft Frontier pour Copilot :

Le mode Frontier n’est pas une simple option, mais fait partie d’un programme Microsoft d’initiative d’accès anticipé aux fonctionnalités expérimentales de Microsoft 365 Copilot :

Il permet aux utilisateurs sélectionnés (avec une licence Copilot) de tester des capacités IA avancées avant leur disponibilité générale.
L’objectif est de recueillir des retours pour améliorer les fonctionnalités avant leur lancement officiel.

Les fonctionnalités Frontier sont disponibles pour tous les clients Microsoft 365 disposant d’une licence Copilot. Les paramètres d’administration de votre organisation peuvent déterminer qui peut accéder et utiliser les fonctionnalités Frontier.

De plus, les personnes ayant un abonnement Microsoft 365 Personnel, Famille ou Premium peuvent également accéder et utiliser les fonctionnalités Frontier.

Il existe deux principales façons d’essayer les fonctionnalités Frontier :

Agents Frontier : Suivez les étapes indiquées dans « Accéder aux agents Frontier ».
Fonctionnalités principales des applications Microsoft : Suivez les étapes indiquées dans « Accéder aux fonctionnalités principales des applications Microsoft ».

L’activation du mode Frontier se fait via le portail Microsoft 365 Admin Center. Cette fonctionnalité permet aux administrateurs de le rendre disponible pour certains utilisateurs en quelques clics :

Définissez les utilisateurs concernés par les tests de Frontier :

Il faut compter plusieurs heures avant de voir apparaître les agents et les modes agents apparaître dans les environnements de vos utilisateurs :

Voici par exemple les agents Frontier disponibles :

L’autre fonctionnalité est le mode agent, disponibles sur Word ou Excel :

Le mode agent dans Word vous permet d’utiliser Copilot de manière plus interactive. Dites simplement à Copilot ce que vous voulez, par exemple « résumer les commentaires récents des clients et mettre en évidence les tendances clés », et il rédigera, affinera et mettra en forme votre document pour vous.

L’écriture devient une conversation : vous vous concentrez sur vos idées et Copilot gère les détails avec les styles et la mise en forme intégrés de Word.

Microsoft

Il est possible de demander à Copilot de rédiger, reformuler ou compléter des sections. L’IA pose des questions pour clarifier et améliore le contenu jusqu’à ce que l’on soits satisfait. C’est ce que Microsoft appelle le vibe writing :

Le mode Agent transforme Word en un espace de travail interactif où tu peux collaborer avec l’IA de manière conversationnelle, plutôt que par des commandes ponctuelles :

Fonctionnalité VII – Créez vos applications grâce à l’agent App Builder :

App Builder est un agent intégré à Microsoft 365 Copilot, disponible via le programme Frontier :

App Builder, un agent qui fonctionne avec Microsoft Copilot, transforme vos idées en applications. Aucun codage requis ! Il suffit de décrire ce dont vous avez besoin, et une application personnalisée est générée pour vous.

Quels types d’applications pouvez-vous créer ? Les possibilités sont infinies : créez une application RSVP pour des événements, une application de gestion des dépenses pour soumettre vos frais, une application pour organiser et gérer des scrums, et bien plus encore !

Microsoft

Depuis le portail Microsoft 365 Chat, vous pouvez ajouter cet agent très facilement :

Il suffit ensuite de lui demander de créer votre application, comme « Crée une app pour suivre les incidents » :

Et l’agent commence à se mettre au travail :

Quelques minutes plus tard, un premier résultat apparaît :

Comme avec tout autre agent, la conversation doit continuer afin de lui demander de faire des améliorations ou des corrections :

Un site SharePoint est même créé afin de stocker les informations de l’application, sous forme de listes :

Je teste l’application via l’ajout d’une nouvelle saisie, puis je sauvegarde :

La nouvelle saisie est bien présente :

Elle est également retranscrite dans la liste SharePoint :

Certaines demandes se terminent en erreur, mais App Builder arrive à effectuer les corrections :

Une fois l’application terminée, je peux mettre à jour la nouvelle version si je suis satisfait des modifications :

Pour le moment, l’application créée via App Builder reste uniquement accessible via ce dernier, mais peut être lancée, partagée ou modifiée :

Conclusion

À travers ces différentes fonctionnalités, une tendance se dessine : Microsoft 365 Copilot devient moins un simple assistant conversationnel et davantage un environnement complet d’agents capables d’explorer, d’analyser, de créer et de collaborer au rythme des besoins.

Les modèles disponibles, les capacités étendues de Researcher, l’arrivée d’App Builder ou encore l’ouverture aux modèles tiers enrichissent l’écosystème, tout en demandant une veille constante tant les évolutions sont rapides.

Ce panorama illustre surtout une chose : chacun peut désormais adapter Copilot à ses usages, qu’il s’agisse de mieux comprendre un sujet, de structurer un livrable, d’automatiser un processus ou de tester des fonctionnalités avant leur mise à disposition générale.

Configurez le presse-papier dans AVD/W365

Depuis la mi-2025, Microsoft renforce progressivement les paramètres de sécurité par défaut dans ses environnements Windows 365 et Azure Virtual Desktop (AVD). L’un des changements les plus visibles pour les administrateurs et utilisateurs concerne la redirection du presse-papiers (clipboard), désormais désactivée par défaut dans les nouvelles configurations.

Cette évolution, alignée avec la Microsoft Secure Future Initiative (SFI), vise à limiter les risques d’exfiltration de données et à uniformiser la posture de sécurité entre Windows 365 et AVD.
Mais concrètement, comment ce changement s’applique-t-il ? Quels paramètres contrôlent réellement le comportement du presse-papiers ? Et comment vérifier la configuration effective entre les deux couches (Propriétés RDP et stratégies GPO/Intune) ?

Dans mon précédent article, publié fin 2024, je présentais les options de durcissement du presse-papiers AVD via Intune et les propriétés RDP. Depuis mi-2025, Microsoft est passé d’une approche configurable à une approche imposée par défaut : les redirections (presse-papiers, lecteurs, USB, imprimantes) sont désormais désactivées nativement dans Windows 365 et AVD. Ce qui était un bon réflexe de sécurité devient aujourd’hui la norme.

Une excellente référence pour cette mise à jour est l’article de Dieter Kempeneers, Configure Advanced Clipboard AND Drive Redirection for AVD and Windows 365, dans lequel il détaille non seulement la désactivation par défaut des redirections (presse-papiers, lecteurs, imprimantes) sur les nouveaux hôtes AVD et les Cloud PC Windows 365, mais aussi la façon d’en réactiver certains comportements de façon granulaire.

Dans ce nouvel article, je décortique la logique de redirection RDP, les nouvelles valeurs par défaut introduites par Microsoft, et surtout, les implications pratiques pour vos déploiements et modèles AVD / Windows 365.

Depuis quand Microsoft a changé la règle du presse-papier pour Windows 365 ?

Microsoft a introduit de nouveaux paramètres de sécurité par défaut pour Windows 365 Cloud PCs le 18 juin 2025 :

Windows 365 renforce la sécurité des PC cloud en désactivant par défaut les redirections du presse-papiers, des lecteurs, des périphériques USB et des imprimantes pour tous les PC cloud nouvellement provisionnés et reprovisionnés. Cette modification minimise le risque d’exfiltration de données et d’injection de logiciels malveillants, ce qui offre une expérience plus sécurisée et s’aligne sur le principe de l’initiative Microsoft Secure Future Initiative (SFI) visant à activer et à appliquer par défaut les protections de sécurité.

Microsoft

Un message sous forme de bandeau est bien visible lors de la création d’une police de provisionnement Windows 365 :

D’ailleurs, la police de configuration de sécurité appelée Windows 365 Security Baseline et disponible sur Intune contient bien une restriction qui concerne les lecteurs, donc, de facto, le transfert de fichiers :

Est-ce que cette restriction concerne aussi Azure Virtual Desktop ?

Oui, les nouveaux pools d’hôtes Azure Virtual Desktop sont aussi concernés par ce renforcement :

Cette modification des paramètres par défaut de redirection sera bientôt effective. Afin d’aider les administrateurs informatiques à s’y préparer, une bannière pouvant être ignorée s’affichera sur la page d’accueil « Créer un pool d’hôtes » du portail Azure. Cette bannière informera les administrateurs des nouveaux paramètres par défaut pour les nouveaux pools d’hôtes et fournira des liens vers la documentation expliquant comment les remplacer en modifiant les propriétés RDP du pool d’hôtes une fois celui-ci créé.

Microsoft

Remarque : pour les pools d’hôtes existants, aucune modification ne sera apportée à la configuration de redirection en votre nom. Cependant, nous vous recommandons de renforcer la sécurité des paramètres en désactivant les redirections qui ne sont pas nécessaires. Pour effectuer ces modifications, consultez la section relative à la redirection des appareils dans la documentation sur les propriétés RDP.

Microsoft

Voici la nouvelle option de configuration RDP mise par défaut, et visible dans les propriétés du pool d’hôtes AVD :

D’ailleurs, la police de configuration de sécurité appelée Security Baseline for Windows 10 and later et disponible sur Intune contient bien une restriction qui concerne les lecteurs, donc de facto le transfert de fichiers :

Qu’est-ce que cela change pour mes futures créations AVD et Windows 365 ?

Pour AVD : pour tout nouveau pool d’hôtes créé après la date de changement, les redirections de presse-papier, lecteurs, USB et imprimantes seront désactivées par défaut.
Pour Windows 365 : idem pour tous les Cloud PCs nouvellement provisionnés ou reprovisionnés : les mêmes redirections sont désactivées par défaut.

Impact : vos modèles, templates ou polices qui s’appuyaient sur ces redirections devront être revus. Si vous aviez des scénarios utilisateur où l’on transférait facilement du contenu local vers le poste cloud, il faudra anticiper ce nouveau comportement.

Comment identifier la configuration actuelle des postes ?

Le comportement dépend de deux couches complémentaires. Le serveur RDP n’impose pas unilatéralement la redirection : il la négocie avec le client en fonction de ces deux niveaux :

Le client (.rdp / Propriétés RDP AVD) détermine ce qui est demandé ou refusé pour la session. Exemple : redirectclipboard:i:0 dans les propriétés RDP d’un host pool.
Le serveur (Policies / GPO / Intune) définit ce qui est autorisé ou interdit de manière globale sur la machine. Exemple : fDisableClipboard dans le registre des stratégies.

Première couche : configuration client / RDP Properties :

Ces valeurs correspondent à la configuration du service RDP. Elles sont mises à jour lorsque tu modifies les RDP Properties d’un host pool dans AVD, par exemple :

Set-AzWvdHostPool -Name "pool1" -CustomRdpProperty "redirectclipboard:i:0"

Lorsqu’une session RDP s’ouvre :

Le Remote Desktop Agent (ou rdpinit.exe) initialise la session avec les paramètres .rdp transmis par le broker AVD.
Ces paramètres ne sont pas écrits dans le registre immédiatement.

Seconde couche : configuration serveur / Polices :

Pour consulter les paramètres imposés par une stratégie locale, GPO ou Intune :

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

Ces valeurs représentent la couche de gouvernance :

Elles sont prioritaires sur les paramètres locaux et sont appliquées au démarrage du service TermService.
Elles déterminent ce qui est autorisé ou interdit globalement sur la machine, indépendamment des paramètres envoyés par le .rdp.

La configuration peut se faire très facilement depuis une police de configuration Intune :

Interaction entre les deux couches :

Le comportement effectif correspond toujours à la configuration la plus restrictive :

Policy (serveur)	RDP Property (client/session)	Résultat final
Autorise	Interdit (redirectclipboard:i:0)	❌ Redirection désactivée
Interdit	Autorise (redirectclipboard:i:1)	❌ Redirection désactivée
Autorise	Autorise	✅ Redirection active

Résultats de tests : comportement réel du presse-papiers RDP

Pour mieux comprendre ces nouveaux paramètres de redirection du presse-papiers, j’ai réalisé une série de tests sur plusieurs configurations RDP (AVD et Windows 365).

Le but était de vérifier quels types de données (texte, image, HTML, binaire, etc.) pouvaient être copiés dans chaque sens selon les paramètres du serveur et du client.

Les couches de configuration RDP :

Les deux couches peuvent définir différentes valeurs, mais elles ne s’écrasent pas : le moteur RDP évalue d’abord la police, puis les propriétés RDP :

Couche	Rôle
1. Configuration RDP	Paramètres appliqués au niveau du service RDP local. C’est ce qu’utilise la session à l’exécution. Modifié par les propriétés RDP d’un host pool AVD.
2. Policy configuration (GPO / Intune)	Paramètres de gouvernance. Écrits par une stratégie (GPO/MDM) et prioritaires sur la configuration locale.

Niveaux de granularité (SCClipLevel / CSClipLevel) :

Les valeurs SCClipLevel et CSClipLevel permettent aussi d’affiner très précisément la redirection dans chaque sens :

SC (Server → Client) : copier du cloud vers le poste local.
CS (Client → Server) : copier du poste local vers le cloud.

Niveau	Formats autorisés	Exemple
`0`	Aucune redirection	Blocage total
`1`	Texte brut uniquement	Copier/coller texte simple
`2`	Texte brut + images	Exemple : capture d’écran
`3`	Texte brut + images + RTF	Texte formaté (Word, Outlook)
`4`	+ HTML	Copier/coller depuis un navigateur

Comment cela se voit pour Windows 365 ?

Voici un récapitulatif des différents tests effectués, en modifiant les propriétés pour AVD ou Windows 365 :

Et voici le détail de ces tests avec les configurations Intune appliquées pour impacter le registre Windows :

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

Test A – Clipboard redirection isn’t available : Le presse-papiers est complètement désactivé côté session RDP. Aucun copier/coller ne fonctionne dans aucun sens :

Test B – Clipboard redirection is available : Le presse-papiers est activé côté session RDP. Le copier/coller fonctionne dans les deux sens :

Test C – Do not allow Clipboard redirection Disabled (fDisableClip=0). Le comportement dépend donc de la configuration du fichier .rdp, qui est activé. Le copier/coller fonctionne dans les deux sens :

Test D – Do not allow Clipboard redirection Enabled (fDisableClip=1). Blocage complet du copier/coller, même si le .rdp autorise la redirection :

Test E – Do not allow Clipboard redirection Disabled (fDisableClip=0), comme la configuration du fichier .rdp, qui est activé. Disable clipboard transfers from session host to client (SCClipLevel=0) et inversement (CSClipLevel=0). Aucun copier-coller descendant ou montant n’est possible :

Test F – Allow plain text : Autorise uniquement le texte brut (SCClipLevel=1 / CSClipLevel=0 / fDisableClip=0). Le copier/coller d’images fonctionne du host vers le client, mais pas inversement, et pas d’images ni de formats enrichis :

Test G – Allow plain text and image : Autorise texte brut + images (SCClipLevel=2 / CSClipLevel=0 / fDisableClip=0). Le copier/coller d’images fonctionne du host vers le client, mais pas inversement :

Test H – Ajoute le support du Rich Text (SCClipLevel=3 / CSClipLevel=0 / fDisableClip=0). Le copier/coller de texte et d’images fonctionne, mais pas HTML ni formats binaires. Le copier/coller d’images fonctionne du host vers le client, mais pas inversement :

Test I – Allow plain text, images, Rich Text Format and HTML. Ajoute HTML (SCClipLevel=4 / CSClipLevel=0 / fDisableClip=0). Formats binaires toujours bloqués. Le copier/coller d’images fonctionne du host vers le client, mais pas inversement :

Test J – Allow plain text, images, Rich Text Format, HTML and Binary. Autorise tous les formats, y compris binaires (CSClipLevel=0 / fDisableCdm=0 / fDisableClip=0). Tous les copier/coller possibles du host vers client :

Test K – Allow plain text (inverse direction). Même logique que F mais appliquée au client → host (SCClipLevel=0 / CSClipLevel=1 / fDisableClip=0). Seul le texte brut passe du poste local vers le cloud :

Test L – Allow plain text and images (inverse direction). Autorise texte et images du client vers la session (SCClipLevel=0 / CSClipLevel=2 / fDisableClip=0) :

Test M – Allow plain text, images and Rich Text Format (inverse direction). Ajoute RTF côté client → host (SCClipLevel=0 / CSClipLevel=3 / fDisableClip=0). HTML et binaire toujours bloqués :

Test N – Allow plain text, images, Rich Text Format and HTML (inverse direction). Permet HTML du client vers la session (SCClipLevel=0 / CSClipLevel=4 / fDisableClip=0) :

Test O – Allow plain text, images, Rich Text Format, HTML and Binary (inverse direction). Autorise tous les formats, y compris binaires (SCClipLevel=0 / fDisableCdm=0 / fDisableClip=0). Tous les copier/coller possibles du client vers le host :

Conclusion

La désactivation par défaut des redirections RDP dans Windows 365 et AVD s’inscrit dans une tendance claire : un durcissement progressif des environnements cloud Windows pour tendre vers le secure by default.

Pour les architectes et administrateurs, cela signifie qu’il faut désormais anticiper ce comportement dans les modèles de provisionnement, les recommandations Intune et les templates de pools AVD.

Le presse-papiers, souvent considéré comme un simple confort utilisateur, devient un point de contrôle important dans la stratégie de sécurité : il faut choisir entre flexibilité et maîtrise du flux de données entre les environnements locaux et cloud.

En maîtrisant les deux couches de configuration (Propriétés RDP et polices GPO/MDM) et les niveaux SCClipLevel / CSClipLevel, vous pouvez adapter finement le niveau de redirection autorisé, du simple texte brut jusqu’à la copie complète de formats binaires.

En résumé : ce changement n’est pas une contrainte, mais une opportunité d’élever le niveau de sécurité sans perdre la visibilité sur le fonctionnement interne du protocole RDP.