Nerdio simplifie FSLogix

Vous avez déployé Nerdio Manager for Enterprise (peut-être en suivant mon article précédent), vous avez coché en passant « FSLogix Profiles Storage Configuration » dans le wizard, mais vous n’avez jamais vraiment creusé ce que Nerdio fabrique derrière ? Cette suite logique est pour vous. On va dérouler, étape par étape, ce que Nerdio fait à votre place sur FSLogix et surtout ce que vous auriez à faire à la main sans lui. Parce que FSLogix, c’est probablement la brique d’AVD qui génère le plus de tickets support, et ça vaut la peine de comprendre pourquoi Nerdio fait baisser ce volume.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

1. Pourquoi FSLogix à la main, c’est pénible
2. Le wizard Create Azure Files Share
3. Les FSLogix Profiles : templates réutilisables
4. La config qui descend toute seule sur les session hosts
5. Exclusions, redirections.xml, ODFC, Cloud Cache
6. Multi-storage et scoping par host pool
7. Monitoring et cleanup des profils orphelins
8. Verdict

1. Pourquoi FSLogix à la main, c’est pénible

Avant d’entrer dans Nerdio, faisons l’inventaire de ce qu’il faut faire pour avoir un FSLogix qui tourne proprement sur un host pool AVD Entra-only. La liste, que vous pouvez retrouver dans cet article, se décompose dans cet ordre :

Provisionner un storage account
Activer l’authentification Entra Kerberos
Grant admin consent
Exclure cette app des policies Conditional Access MFA
Créer le file share
Distribuer les rôles RBAC
Régler les ACL NTFS
Pousser les clés registry FSLogix
Maintenir tout ça dans le temps

Mon retour terrain : à la main, comptez une bonne demi-journée pour un déploiement propre, plus le temps de débuggage des permissions NTFS qui vient quasi systématiquement. L’étape 7 (ACL NTFS) est celle qui génère le plus de tickets support sur tout AVD. Une fausse manip d’héritage et vous y passez la journée d’anniversaire de votre fils.

Maintenant, voyons ce que Nerdio peut faire pour vous.

2. Le wizard Create Azure Files Share

Avant toute chose, je vous conseille de créer le groupe de ressources sur le portail Azure, puis de lier ce dernier dans votre console Nerdio :

Dans Nerdio, direction Settings → FSLogix Profiles → Add Azure Files Share. Vous avez le choix entre pointer un storage account existant ou laisser Nerdio créer le share complet, du SA jusqu’aux ACL NTFS. Et oui, ça inclut le scénario Entra ID joined, c’est ce qu’on va dérouler ensemble :

Le wizard se passe en seulement 5 étapes :

Étape 1 : Storage Account

Nom du SA, resource group, région, SKU (Standard ou Premium Files), réplication. Rien d’extraordinaire, mais tout se passe dans une seule fenêtre Nerdio plutôt que de naviguer dans quatre blades Azure différentes.

Étape 2 : Active Directory ou Entra ID

L’étape clé. Vous activez le toggle Join AD or Entra ID, puis vous choisissez Entra ID dans la liste déroulante. Et là, Nerdio vous met deux warnings honnêtes que vous devez lire avant de cliquer Next :

Attention : Nerdio vous prévient sur deux points avant de valider :

⚠️ Be sure to grant admin consent after storage account is joined to Entra ID.
⚠️ Entra ID Conditional Access MFA is not supported with Entra ID joined Azure Files storage accounts. The new Entra ID application must be excluded from CA MFA policies.

Ce sont les deux seules manips qu’il vous restera à faire à la fin. Nerdio s’occupe du reste : création de l’app registration, configuration Entra Kerberos sur le storage, le tout en une seule passe.

Étape 3 : Share & Permissions

Vous donnez un nom au share, sa capacité (entre 100 GB et 100 TB), et vous attribuez les rôles RBAC SMB Share Contributor aux groupes Entra ID concernés. Mais surtout, et c’est là le gros gain, vous avez un dropdown NTFS Permission Preset avec une option FSLogix.

Ce preset, c’est exactement la combinaison Authenticated Users / CREATOR OWNER / Administrators de la section 1, avec les bons héritages.

Bonus sécurité : la case Limit access to specific host pools vous permet de restreindre ce share à un ou plusieurs host pools précis. Pratique si vous avez plusieurs environnements (prod, dev, RH, finance…) et que vous voulez éviter qu’un host pool puisse écrire dans le profil d’un autre.

Étape 4 : Temporary VM Settings

Pour appliquer les ACL NTFS et finaliser le join, Nerdio doit mount le share quelque part. Il monte donc une VM temporaire dans votre vNet le temps de la config, puis la supprime automatiquement.

Vous renseignez ici la taille de VM (le défaut B2s suffit), le subnet et éventuellement l’image. C’est cette VM qui va faire le icacls du preset FSLogix sur le share, donc gardez bien le subnet AVD ou un subnet qui peut joindre le storage.

Étape 5 : Tags

Classique. Submit.

Le déploiement commence alors, et toutes les étapes sont indiquées dans le log :

Sur le portail Azure, on retrouve la machine virtuelle temporaire créée pour l’occasion :

Une fois le traitement terminé, toutes les étapes sont bien détaillées dans le log :

Le statut du compte de stockage est également visible dans le portail Azure :

Et la configuration de la gestion identitaire Entra Kerberos est faite :

Dans Entra, l’app registration est bien créée :

Les ACL de base sont bien appliquées (un durcissement des héritages NTFS reste possible si votre politique de sécurité l’exige) :

À l’issue de l’opération, la machine virtuelle temporaire se détruit automatiquement :

À la fin du traitement, trois actions restent à votre charge :

Allez dans Entra ID → Enterprise Applications, ouvrez la nouvelle app qui porte le nom de votre storage account, et cliquez sur Grant admin consent for [tenant].

Ajoutez également la prise en charge des groupes dans le manifeste de l’app :

Si vous avez des Conditional Access policies MFA, ajoutez cette app dans la liste d’exclusion :

C’est tout. Comparez avec la liste de la section 1 : on est passé de 9 étapes à 3 manips de 30 secondes.

3. Les FSLogix Profiles : templates réutilisables

Voilà la deuxième brique qui change la vie : les FSLogix Profiles au sens Nerdio du terme, à ne pas confondre avec les profils utilisateurs FSLogix !

Dans Settings → FSLogix, vous créez un profil, c’est-à-dire un template de configuration FSLogix, que vous pourrez ensuite appliquer à n’importe quel host pool.

Concrètement :

Nom du profil : par exemple « Standard AVD Users » ou « Power Users with bigger profiles ».
Excluded users group : un groupe Entra ID dont les membres ne seront PAS soumis à FSLogix. Best practice : y mettre vos admins. Comme ça, si FSLogix casse, vos admins peuvent toujours se logger en profil local et venir réparer.
Profile path : un dropdown qui vous propose tous les shares que vous avez créés à l’étape précédente. Vous n’avez plus à retaper le path UNC à la main.
Office Container (ODFC) : checkbox pour activer le container Office séparé. Honnêtement, dans la grande majorité des cas AVD vous n’en avez pas besoin (j’y reviens en section 5).
Cloud Cache : à laisser de côté sauf scénario multi-région avec DR actif-actif.

Toujours sur l’écran de configuration FSLogix, vous tombez sur la vraie matrice des réglages FSLogix. Et là, Nerdio fait deux choses qui valent la mention.

Les eye icons. Chaque setting a une petite icône œil que vous pouvez survoler pour avoir la description complète de la clé registry correspondante. Plus besoin d’aller chercher dans la doc Microsoft à chaque fois. C’est bête mais c’est ce qui transforme FSLogix d’un truc obscur en quelque chose de réellement administrable.
Les valeurs par défaut « Not configured ». Tant que vous ne touchez pas, Nerdio ne pousse rien sur cette clé : la valeur par défaut FSLogix est utilisée. Vous ne tunez que ce que vous voulez vraiment changer, ce qui rend votre conf lisible.

Les best practices que je pousse personnellement (et qui sont presque toutes pré-suggérées par Nerdio) :

Réglage	Valeur	Pourquoi
`DeleteLocalProfileWhenVHDShouldApply`	Enabled	Sur un environnement neuf, ça évite l’accumulation de profils locaux qui se baladent à côté des VHDX. À ne PAS activer si vous migrez depuis une infra existante avec des profils locaux à préserver.
`FlipFlopProfileDirectoryName`	Enabled	Met le username AVANT le SID dans le nom du folder. Indispensable pour s’y retrouver quand vous cherchez le profil d’un user dans le share.
`VolumeType`	VHDX	Disque dynamique, grandit au fil du temps. Sur Standard Files, c’est ce qui vous évite de réserver 30 Go par user dès le premier login.
`IsDynamic`	Enabled	Idem, le VHDX commence à quelques Mo et grandit en fonction de l’usage réel.
`LockedRetryCount` / `LockedRetryInterval`	Défauts, à augmenter si réseau capricieux	Si le VHD est temporairement locké (réseau qui tousse, session précédente qui ne s’est pas fermée proprement), FSLogix réessaye au lieu de filer un profil temp.
`PreventLoginWithFailure`	Enabled	Si FSLogix n’arrive pas à monter le profil, l’utilisateur est BLOQUÉ au login plutôt que de se retrouver sur un profil temporaire. Préférable : un user qui appelle le support > un user qui bosse 4 h sur un profil qui sera jeté au logoff.
`PreventLoginWithTempProfile`	Enabled	Même logique, ceinture et bretelles.
`ProfileType`	0	Mount sur un seul host à la fois. Le multi-mount (type 3) est une plaie à débugger, à n’activer que si vous avez vraiment besoin.
`SizeInMBs`	30000 (30 GB)	Plafond raisonnable. Tracez les profils qui s’en approchent dans le monitoring (section 7).
Compression au logoff	Enabled	À chaque logoff, FSLogix compacte le VHDX. Vous économisez pas mal de stockage à long terme.

Et pour les puristes : le mode Advanced vous laisse taper directement les clés FSLogix par nom et valeur si vous voulez configurer quelque chose qui n’est pas exposé dans l’UI. Nerdio ne vous enferme pas :

"DeleteLocalProfileWhenVHDShouldApply"=dword:00000001
"FlipFlopProfileDirectoryName"=dword:00000001
"IsDynamic"=dword:00000001
"LockedRetryCount"=dword:00000012
"LockedRetryInterval"=dword:00000005
"PreventLoginWithFailure"=dword:00000001
"PreventLoginWithTempProfile"=dword:00000001
"ReAttachIntervalSeconds"=dword:00000010
"ReAttachRetryCount"=dword:00000060
"ProfileType"=dword:00000000
"SizeInMBs"=dword:00025000
"VolumeType"=string:"vhdx"
"VHDCompactDisk"=dword:00000001

Une fois le profil créé, vous cliquez sur les trois points → Set as default :

À partir de là, chaque nouveau host pool que vous créez héritera de cette config FSLogix automatiquement. Et bien sûr, vous pouvez override par host pool si vous avez besoin d’une config différente quelque part.

C’est ça le vrai gain par rapport à une approche GPO : ce que vous configurez une fois s’applique partout, sans recréer une GPO ni modifier votre image golden.

4. La config qui descend toute seule sur les session hosts

À la création (ou à la mise à jour) d’un host pool, Nerdio injecte la conf FSLogix via ses Scripted Actions au boot des session hosts :

Comme c’est magnifique, et tellement simple :

Les machines virtuelles sont bien visibles dans le pool d’hôtes :

Concrètement :

Pas besoin de GPO
Ça marche sur des hosts Entra-only ou joints à un domaine AD
Ça s’applique aussi bien sur les hosts existants que sur les nouveaux (auto-scale, re-image)

Si vous allez voir le registre d’un session host après le déploiement :

La version de FSLogix correspond à celle demandée :

Vous retrouverez bien tout sous HKLM\SOFTWARE\FSLogix\Profiles, mais cette fois sans que vous ayez touché à un seul reg add ni à une GPO :

Et bien sûr, le profil VHDX se crée au premier démarrage de l’utilisateur :

Mon retour terrain : si vous changez la config dans le FSLogix Profile Nerdio, vous pouvez redéployer la conf sur tous les hosts d’un host pool en un clic, sans rebuilder l’image. Nerdio relance simplement le Scripted Action sur chaque host. C’est l’inverse du modèle « je rebuild mon image dorée à chaque tuning FSLogix » qu’on voyait avec les GPO.

5. Exclusions, redirections.xml, ODFC, Cloud Cache

Exclusions registry. Toujours dans le FSLogix Profile, vous avez un onglet Profile Exclusions où vous gérez la liste des dossiers et fichiers que FSLogix doit ignorer (typiquement les caches Teams, les logs, les téléchargements). C’est l’équivalent de la clé HKLM\SOFTWARE\FSLogix\Profiles\Exclude List, mais éditable depuis une UI au lieu d’un import de fichier .reg.

Redirections.xml. Pareil, Nerdio gère l’upload et la synchronisation du redirections.xml sur le share. Vous le modifiez dans Nerdio, il est poussé automatiquement au prochain mount des profils.

Office Container (ODFC). Comme dit en section 3, dans la majorité des cas AVD vous n’en avez pas besoin. La doc Microsoft elle-même recommande de NE PAS mélanger Profile Container et ODFC sauf cas particulier (par exemple OneDrive en mode Files On-Demand avec beaucoup de fichiers). Si vous l’activez, comptez doubler la complexité de troubleshooting.

Cloud Cache. Outil puissant pour faire du multi-storage avec basculement automatique, mais à réserver aux scénarios DR actif-actif ou multi-région avec une vraie contrainte de continuité de service. Sur un host pool en région unique, Cloud Cache n’apporte rien que le Profile Container standard ne fasse déjà.

6. Multi-storage et scoping par host pool

Pour les déploiements qui grossissent, deux features valent le coup d’être mentionnées.

Plusieurs locations FSLogix. Vous pouvez déclarer plusieurs shares dans Nerdio (même un Azure NetApp Files si vous en avez un) et les pointer depuis différents FSLogix Profiles. Pratique pour séparer prod et dev, ou pour des shares dédiés par département.

Scoping par host pool. Souvenez-vous de la case Limit access to specific host pools à l’étape Share & Permissions (section 2). Couplée aux FSLogix Profiles par host pool, ça vous permet d’avoir une isolation stricte : un host pool « Finance » ne peut pas écrire dans le share « RH », et inversement. Tout ça géré dans la même UI, sans pondre des RBAC complexes à la main.

7. Monitoring et cleanup des profils orphelins

Plusieurs features moins glamour, mais qui paient leur licence Nerdio sur le long terme.

Monitoring des tailles de profil : Nerdio remonte pour chaque session active la taille du VHDX du user. Vous voyez tout de suite les profils qui gonflent (typiquement les boîtes OST Outlook, les caches Teams mal nettoyés). Vous pouvez tirer des alertes là-dessus.

Auto-Scale du file share : Manage Auto-Scale for FSLogix permet d’automatiser le dimensionnement des ressources et la gestion des profils utilisateurs afin d’assurer performance et optimisation des coûts sans intervention manuelle, de la même façon que mon article sur la méthode scriptée dans Azure :

Cleanup des profils orphelins : Nerdio propose une Scripted Action prête à l’emploi qui scanne votre share FSLogix, compare la liste des folders aux users existants dans Entra ID, et supprime les VHDX des users qui n’existent plus (départs, comptes supprimés). Vous la planifiez en récurrent (une fois par mois par exemple) et vous oubliez.

À la main : il faut écrire le script PowerShell, le planifier (Automation Account, Function App, ou serveur dédié), le maintenir quand l’API Graph change. Avec Nerdio : checkbox + planification.

8. Verdict

Si vous gérez un seul host pool sur une infra stable, FSLogix à la main reste tenable et vous payez l’effort une fois, vous oubliez. Mais dès que vous avez :

Plusieurs host pools avec des configs FSLogix différentes,
Des changements de conf réguliers (ajout d’exclusions, redirections, tuning),
Du multi-département avec isolation des profils,

… Nerdio paye sa licence rien que sur la partie FSLogix. La création du share avec preset NTFS, le push de la conf au boot, le monitoring et le cleanup, c’est plusieurs jours de travail PowerShell que vous n’avez plus à faire ni à maintenir.

Voilà, en 8 sections vous avez fait le tour de ce que Nerdio fait pour vous sur FSLogix. Concrètement, ça donne quoi ? Vos tickets support « profil temporaire » devraient chuter de manière significative. Ce qui, dans la vie d’un admin AVD, n’a pas de prix.

Foncez tester en lab : le wizard Create Azure Files Share en mode Entra-joined, c’est cinq minutes à dérouler, et vous verrez tout de suite la différence avec le manuel. Prochain article de la série : on attaquera l’auto-scaling avec Nerdio, l’autre grande raison de payer cette licence (et la moins évidente à découvrir tout seul).

Autoscalez le stockage FSLogix

Un dimanche soir, votre stockage FSLogix sature, et personne ne le voit. Lundi matin, vos 200 utilisateurs AVD n’arrivent plus à se connecter car leur profil ne se charge plus. Que faire en ce moment d’urgence ? Vous découvrez en urgence que provisionner un share Azure avec « 8 To au cas où » , ça vous coûte un bras et demi. Ce mauvais rêve vous parle ou vous empêche de dormir ? Cet article est fait pour vous.

On va très rapidement remonter l’histoire d’Azure Files, comprendre pourquoi Provisioned v2 (GA depuis 2025) change la donne pour les workloads FSLogix, et surtout déployer ensemble, depuis Azure Cloud Shell, en moins de 5 minutes, une solution open-source qui fait grossir automatiquement le quota quand l’usage approche la saturation, avec des notifications mail à la clé.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

1. Petit rappel : Azure Files, d’où on vient
2. L’arrivée de Provisioned v2
3. FSLogix : ce que Microsoft recommande vraiment
4. Le piège du « pay-per-provisioned »
5. La solution : auto-grow runbook open-source
6. Déploiement pas-à-pas depuis Cloud Shell
7. Le moment de vérité : on déclenche un grow
8. Estimation de coûts (ordres de grandeur)
9. Pièges & vigilance

1. Petit rappel : Azure Files, d’où on vient

Plusieurs articles ont déjà été écrits sur le sujet du stockage dans Azure :

Mais pour rappel, jusqu’ici Azure Files se déclinait essentiellement en deux familles :

Standard (HDD) en pay-as-you-go : pas cher, performances modestes, facturation peu prédictible (capacité utilisée + transactions).
Premium (SSD) en provisioned : les IOPS et le throughput étaient dérivés mécaniquement de la capacité provisionnée. Vous vouliez 50 000 IOPS ? Vous provisionniez des To de capacité, que vous les remplissiez ou non.

Attribute	SSD approvisionné v1	HDD, paiement à l’utilisation
La taille minimale de stockage	100 Gio (approvisionné)	0 octets
Taille de stockage maximale	100 Tio	100 Tio
Nombre maximal de fichiers	Unlimited	Unlimited
Nombre maximal d’E/S par seconde (données)	102 400 IOPS (dépendant de l’approvisionnement)	20 000 IOPS
Débit maximal	10 340 Mio /s (dépendant de l’approvisionnement)	Jusqu’aux limites du compte de stockage

Microsoft Learn

Bursting v1 approvisionné :

Capacité (Gio)	IOPS de référence	IOPS en rafale	Lister les crédits	Débit (Mio/s)
100	3 100	Jusqu’à 10 000	24 840 000	110
500	3 500	Jusqu’à 10 000	23 400 000	150
1 024	4 024	Jusqu’à 10 000	21 513 600	203
5 120	8 120	Jusqu’à 15 360	26 064 000	613
10 240	13 240	Jusqu’à 30 720	62 928 000	1 125
33 792	36 792	Jusqu’à 102 400	227 548 800	3 480
51 200	54 200	Jusqu’à 102 400	164 880 000	5 220
102 400	102 400	Jusqu’à 102 400	0	10 340

Microsoft Learn

Ce dernier point a été le casse-tête FSLogix pendant des années. Sur un share AVD, vous n’avez pas spécialement besoin de 5 To de capacité, mais vous avez besoin de pouvoir encaisser une sign-in storm à 8 h le matin.

Sur du Premium V1, pour atteindre les IOPS nécessaires, vous étiez obligé de surprovisionner la capacité. Vous payiez alors de l’espace que vous n’utilisiez pas, contrairement au HDD pay-as-you-go.

Et si vous étiez tenté par le HDD pay-as-you-go pour dormir tranquille : à la place d’un long discours, voici une image qui a dû faire mal à de nombreux administrateurs d’AVD :

Mon retour terrain : sur la quasi-totalité des projets AVD que j’ai vus, le calcul de sizing FSLogix se faisait « en IOPS » et la capacité était une conséquence. Résultat : des shares à 2-4 To remplis à 30 %, payés plein pot.

2. L’arrivée de Provisioned v2

Provisioned v2 est GA depuis 2025, dans toutes les régions publiques Azure et toutes les régions Azure US Government. La grande nouveauté : on provisionne trois axes indépendants.

Le modèle v2 provisionné pour Azure Files associe la prévisibilité du coût total de possession à la flexibilité, vous permettant ainsi de créer un partage de fichiers qui répond précisément à vos exigences en matière de stockage et de performances.

Lorsque vous créez un partage de fichiers v2 approvisionné, vous spécifiez la quantité de stockage, d’IOPS et de débit dont votre partage de fichiers a besoin.
Source : Understand Azure Files billing — Microsoft Learn

Concrètement, vous payez trois choses séparément, même si certaines limites existent :

La capacité provisionnée (GiB)
Les IOPS provisionnés
Le throughput provisionné (MiB/s)

Et deux SKUs sont disponibles en v2 avec des redondances spécifiques :

Premium V2 (SSD) : LRS ou ZRS
Standard V2 (HDD) : LRS, ZRS, GRS ou GZRS

Voici d’ailleurs les limites officielles à connaître :

Dimension	Premium V2 (SSD)	Standard V2 (HDD)
Capacité min	32 GiB	32 GiB
Capacité max	256 TiB	256 TiB
IOPS min	3 000	500
IOPS max	102 400	50 000
Throughput min	100 MiB/s	60 MiB/s
Throughput max	10 340 MiB/s	5 120 MiB/s
Unité de provisioning	1 GiB	1 GiB

Microsoft Learn

Deux subtilités utiles à connaître :

Cooldown 24 h sur la descente : on peut augmenter le quota n’importe quand, mais on ne peut le diminuer qu’après 24 h sans changement.
Burst IOPS credit-based : sur SSD, le burst max est MIN(MAX(3 × ProvisionedIOPS, 10 000), 102 400). Pratique pour absorber les pics ponctuels sans surprovisionner.

Bursting v2 approvisionné :

IOPS provisionnées	Limite d’IOPS en rafale SSD	Crédits de rafale SSD	Limite de l’IOPS en mode bursting de disque de l’HDD	Crédits de bursting de disque de l’HDD
500	—	—	Jusqu’à 5 000	16 200 000
1 000	—	—	Jusqu’à 5 000	14,400,000
3 000	Jusqu’à 10 000	25,200,000	Jusqu’à 9 000	21 600 000
5 000	Jusqu’à 15 000	36 000 000	Jusqu’à 15 000	36 000 000
10 000	Jusqu’à 30 000	72 000 000	Jusqu’à 30 000	72 000 000
25 000	Jusqu’à 75 000	180,000,000	Jusqu’à 50 000	90 000 000
50 000	Jusqu’à 102 400	188,640,000	Jusqu’à 50 000	0
75 000	Jusqu’à 102 400	98,640,000	—	—
102 400	Jusqu’à 102 400	0	—	—

Microsoft Learn

3. FSLogix : ce que Microsoft recommande vraiment

Côté FSLogix, la doc Microsoft Learn pose deux chiffres très concrets, par utilisateur :

Profil de charge	IOPS par utilisateur
Steady state (utilisation normale en cours de journée)	10
Sign-in / Sign-out (ouverture ou fermeture de session)	50

L’exemple de ce tableau est celui d’un utilisateur unique, mais il peut être utilisé pour estimer les besoins relatifs au nombre total d’utilisateurs dans votre environnement. Par exemple, vous avez besoin d’environ 1 000 IOPS pour 100 utilisateurs et environ 5 000 IOPS lors de la connexion et de la déconnexion.
Source : Container storage options — FSLogix — Microsoft Learn

Projetons ça sur quelques tailles d’environnement classiques :

Users	IOPS steady (×10)	IOPS pic sign-in (×50)
50	500	2 500
200	2 000	10 000
500	5 000	25 000
1 000	10 000	50 000

Côté capacité, Microsoft ne fixe pas de chiffre dur officiel par utilisateur, ça dépend des applis, d’Outlook (qui crée souvent les plus gros .OST), de OneDrive Known Folder Move, etc.

Sur la majorité des environnements AVD que j’ai croisés, on tourne entre 5 et 30 GiB par profil, avec une grosse variance. C’est exactement le genre de variable difficile à prévoir à l’avance, et c’est pour ça que l’auto-grow prend tout son sens.

Attention : les 10 / 50 IOPS sont des moyennes Microsoft. Sur une population à fort usage Office + Teams + OneDrive sync, on monte assez vite. Mesurez sur votre prod plutôt que de partir tête baissée sur la table.

4. Le piège du « pay-per-provisioned »

C’est le point qui change avec le Provisioned v2, qu’il soit SSD ou HDD. Microsoft le dit noir sur blanc :

Vous payez en fonction de ce que vous approvisionnez, quel que soit le montant que vous utilisez réellement.
Source : Understand Azure Files billing — Microsoft Learn

Concrètement : vous provisionnez 8 To « au cas où » → vous payez 8 To, qu’ils soient remplis à 5 % ou à 95 %. Plus du tout le modèle Standard pay-as-you-go d’antan où vous ne payiez que le stockage consommé.

Deux stratégies s’offrent à vous :

Surprovisionner dès le départ pour ne jamais être surpris → vous payez de la capacité dormante pendant des mois.
Provisionner serré (avec un peu de marge) puis grossir à la demande, dès que l’usage s’approche d’un seuil → vous payez ce dont vous avez besoin au moment où vous en avez besoin.

L’option 2 demande de l’automatisation. C’est exactement ce que fait la solution qui suit.

5. La solution : auto-grow runbook open-source

J’ai packagé tout ça sur GitHub : jlou07/azure-files-autogrow. Le repo contient trois fichiers :

main.bicep : déploie un Automation Account avec Managed Identity, les modules PowerShell 7.2 (Az.Accounts + Az.Storage), un runbook vide, une schedule, et toute la stack Azure Communication Services pour les emails.
Grow-FslogixShare.ps1 : le runbook qui lit la capacité utilisée du share, compare au seuil, agrandit le quota, et envoie un email récapitulatif.
deploy-cloudshell.sh : script interactif qui vous pose les questions et orchestre tout depuis Azure Cloud Shell.

Le runbook est grow-only par design : il ne diminue jamais le quota et c’est volontaire : un utilisateur qui charge un gros profil un jour et le supprime le lendemain ne doit pas déclencher une décroissance.

Et de toute façon, Azure impose 24 h de cooldown avant toute baisse, donc autant ne pas s’embêter.

Pré-requis

Subscription	Vous devez être Contributor sur un Resource Group de la sub.
Storage account	Kind `FileStorage` avec SKU `PremiumV2_` ou `StandardV2_` déjà existant, avec un file share déjà créé.
Email de notif	N’importe quelle adresse (interne, externe, gmail, …). Optionnelle : si vous la laissez vide, les notifs sont désactivées et la stack ACS n’est pas déployée.
Outils	Azure Cloud Shell (Bash).

Mon retour terrain : j’ai fait le choix d’Azure Communication Services pour les emails, plutôt que Microsoft Graph. Avantage énorme : un simple rôle Contributor scopé sur la ressource ACS suffit. Pas de consentement admin tenant, pas de Mail.Send au niveau du tenant, pas de mailbox à provisionner. La solution est déployable par n’importe quel admin Azure qui a un Resource Group à sa main.

6. Déploiement pas-à-pas depuis Cloud Shell

Étape 0 — Ouvrir Cloud Shell et récupérer les fichiers

Mais juste avant, j’ai déployé un Azure File Share de 50 Go sur mon environnement de test :

Allez sur shell.azure.com ou cliquez ici :

Choisissez Bash, puis :

curl -O https://raw.githubusercontent.com/jlou07/azure-files-autogrow/main/main.bicep
curl -O https://raw.githubusercontent.com/jlou07/azure-files-autogrow/main/Grow-FslogixShare.ps1
curl -O https://raw.githubusercontent.com/jlou07/azure-files-autogrow/main/deploy-cloudshell.sh
chmod +x deploy-cloudshell.sh

Étape 1 — Lancer le script

./deploy-cloudshell.sh

Le script vous pose une série de questions, dans l’ordre :

La subscription cible (par défaut celle qui est active dans Cloud Shell)
Le Resource Group où déployer l’Automation Account (créé s’il n’existe pas)
La région (ex. francecentral, westeurope)
Le RG, le nom et le nom du share du storage cible (celui qui contient le file share v2 à monitorer)
Le seuil de déclenchement en % (défaut 80)
Le growth factor (défaut 1.25, soit +25 % à chaque grossissement)
Le quota max en GiB (défaut 4 096)
La fréquence de check (PT15M, PT30M, PT1H (défaut 30 min))
L’email de notification (vide = pas d’emails, et la stack ACS n’est pas déployée)
La data location ACS (défaut Europe)

Étape 2 — Le script déroule

Une fois que vous confirmez, le script enchaîne :

Crée le RG si besoin.
Déploie le Bicep (Automation Account + modules + runbook vide + schedule + ACS + Email Service + Managed Domain + role assignment Contributor sur ACS).
Grant Storage Account Contributor sur le storage cible à l’identité managée de l’Automation Account.
Upload le contenu du Grow-FslogixShare.ps1 dans le runbook.
Publie le runbook.
Lie la schedule au runbook avec les bons paramètres (jobSchedule).

Voici toutes les ressources Azure présentes dans mon environnement :

Étape 3 — Vérifier dans le portail Azure

Automation Account → Modules : Az.Accounts et Az.Storage en statut Available (~10-15 min après le déploiement, c’est de l’import asynchrone) :

Runbooks → Grow-FslogixShare : statut Published :

Schedules → AutoGrowSchedule : enabled, avec un lien vers le job Grow-FslogixShare :

Storage account cible → IAM : l’identité managée de l’AA a bien le rôle Storage Account Contributor :

Ressource ACS → IAM : l’identité managée a Contributor :

Nous allons maintenant tester l’action d’agrandissement, le blocage au cap, et le système de notifications par email.

7. Le moment de vérité : on déclenche un grow

Dès la mise en place de la solution, un premier job doit se lancer :

Le détail de toutes les actions est visible dans le log du job :

Pour forcer un run immédiat sans attendre la prochaine occurrence dans Azure Cloud Shell :

az automation runbook start \
  -g <aa-rg> \
  --automation-account-name <aa-name> \
  --name Grow-FslogixShare \
  --parameters \
      SubscriptionId=<sub-id> \
      ResourceGroupName=<storage-rg> \
      StorageAccountName=<storage-name> \
      FileShareName=<share-name> \
      ThresholdPercent=80 \
      GrowthFactor=1.25 \
      MaxQuotaGiB=4096 \
      NotificationEmail=alerts@mondomaine.com \
      AcsEndpoint=https://<acs-name>.europe.communication.azure.com \
      AcsSenderAddress=DoNotReply@<guid>.azurecomm.net

Les jobs manuels ou automatiques sont visibles ici :

Si vous voulez juste tester l’envoi d’email sans toucher au quota, le runbook supporte un switch -WhatIf qui simule la décision sans appliquer.

Au besoin, vous pouvez modifier la configuration planifiée en en créant une nouvelle ici :

Quand l’usage du share franchit le seuil (par défaut 80 %), comme ici :

Le runbook calcule le nouveau quota (ceil(quota_actuel × 1.25), capé à MaxQuotaGiB), appelle Update-AzRmStorageShare :

La taille du partage de fichier augmente bien de 25 % :

Et enfin il envoie un email récap :

Mais, si le share atteint le cap dur (MaxQuotaGiB), le runbook arrête de le faire grossir :

Et il envoie aussi un email d’alerte en importance haute :

Attention : le premier email envoyé depuis le domaine ACS managé (DoNotReply@<guid>.azurecomm.net) peut tomber en spam. Whitelistez *.azurecomm.net côté destinataire, ou mieux branchez un custom domain vérifié dans le portail ACS (10 minutes d’enregistrements DNS).

Et comme attendu, le service veille en continu :

8. Estimation de coûts (ordres de grandeur)

Les prix Azure Files V2 varient selon la région et la redondance, et Microsoft les ajuste régulièrement.

Les chiffres qui suivent sont des ordres de grandeur pour un déploiement de 256 Go en Europe de l’Ouest, sur un workload FSLogix sur les quatre types de stockage :

Voici d’ailleurs plusieurs hypothèses de sizing FSLogix :

~ 15 GiB par profil utilisateur (mid-range, typique AVD avec Office + OneDrive sync léger)
IOPS pic sign-in : 50 IOPS / user (recommandation Microsoft)
Throughput : ce que recommande Azure par défaut pour la capacité provisionnée

Users	Capacité visée	IOPS visés (pic)	Stratégie « provisioned sec » à la main	Stratégie « auto-grow »
50	~ 750 GiB	2 500	Surprovisionner à 1 TiB pour avoir de la marge	Démarrer à 256 GiB, grossir au fil de l’eau jusqu’à ~ 800 GiB
200	~ 3 TiB	10 000	Provisionner d’office 4 TiB	Démarrer à 1 TiB, monter par paliers de +25 %
500	~ 7,5 TiB	25 000	Provisionner d’office 8 TiB	Démarrer à 2 TiB, monter au besoin
1 000	~ 15 TiB	50 000	Provisionner d’office 16 TiB	Démarrer à 4 TiB, monter au besoin

Sur les ratios de remplissage que je vois en prod (souvent 40-60 % sur les premiers 6 mois), la stratégie auto-grow économise typiquement 30 à 50 % sur la ligne « capacité provisionnée » du share, le temps que la base utilisateurs se stabilise. L’IOPS reste à provisionner pour le pic, ou à profiter des bursts :

Coût ajouté par la solution elle-même :

Automation Account : les 500 premières minutes de runtime par mois sont incluses. Un check toutes les 30 minutes consomme quelques secondes par run, soit largement sous le seuil gratuit.
Azure Communication Services Email : facturation à l’email envoyé. Sur le volume d’un déploiement comme le nôtre (typiquement quelques dizaines d’emails par mois), c’est négligeable.

Bref : le coût de l’orchestration est ridicule face à ce que la stratégie permet d’économiser sur la capacité du share.

9. Pièges & vigilance

Attention : les modules PowerShell sont importés en asynchrone. Pendant les 10-15 minutes qui suivent le déploiement, un job qui se déclenche peut échouer avec « Could not find module Az.Accounts ». C’est normal, ça se résout tout seul. Évitez juste de tester immédiatement après le déploiement.

Attention : le Managed Domain ACS a besoin d’une à deux minutes pour être complètement provisionné après le déploiement. Le tout premier envoi d’email peut échouer ; il suffit de relancer.

Attention : le sender par défaut est DoNotReply@<guid>.azurecomm.net. Pour un envoi propre depuis alerts@mondomaine.com, il faut ajouter un custom domain vérifié dans le portail ACS (quelques enregistrements DNS, 10 minutes) puis mettre à jour AcsSenderAddress sur le jobSchedule.

Mon retour terrain : le runbook est grow-only, ne descend jamais le quota. Et tant mieux : Azure impose 24 h de cooldown avant toute baisse, et refuse toute baisse sous l’usage courant. Si vous voulez vraiment réduire, faites-le à la main après avoir mesuré sur un mois entier.

Conclusion

Voilà, en quelques minutes de Cloud Shell, vous avez :

Un Automation Account avec identité managée
Un runbook qui surveille votre share FSLogix v2 et adapte le quota automatiquement.
Une stack Azure Communication Services dédiée qui envoie les emails

Concrètement, ça donne quoi ? Vous ne surprovisionnez plus à l’aveugle. Vous démarrez serré, et la capacité suit l’usage réel, avec un email récap à chaque changement, et un garde-fou final si jamais ça part en vrille.

Foncez tester, le repo est en MIT, vous pouvez le forker, l’adapter à vos seuils, brancher Logic Apps ou un Teams Webhook à la place de l’email si c’est votre flow. github.com/jlou07/azure-files-autogrow.

Encore hésitant à passer votre stockage FSLogix en v2 ? Regardez cette vidéo :

Et si vous voulez creuser le calcul de sizing FSLogix plus en détail, dites-le moi en commentaire, il y a matière à un article dédié sur la mesure d’IOPS réelle vs la table Microsoft.

Microsoft Flex routing

Vous avez entendu parler de l’EU Data Boundary à droite à gauche, vous savez vaguement que Microsoft a passé des années à le construire comme un argument de souveraineté pour ses clients européens… et puis, en silence, un réglage par défaut a basculé le 17 avril 2026. Bienvenue dans Flex Routing : votre prompt Copilot peut désormais sortir de l’EU Data Boundary pendant les pics de charge, sans que personne ne le sache.

Cet article décortique ce qui change vraiment, pour qui, et comment décider, avec le cas particulier des tenants ADR qui ont payé pour de la souveraineté locale stricte.

Sommaire

1. C’est quoi Flex Routing, concrètement ?
2. Le calendrier et le défaut piégeux
3. Quelles données sortent réellement de l’EU ?
4. L’enjeu conformité : GDPR, NIS2, DORA
5. Pas-à-pas : désactiver dans le Microsoft 365 Admin Center
6. Le piège Power Platform : un deuxième switch
7. Le paradoxe ADR : vous avez payé pour la souveraineté locale, et ?

1. C’est quoi Flex Routing, concrètement ?

Pour rappel, jusqu’ici Microsoft s’était engagé à maintenir le traitement des données des clients Copilot EU et EFTA à l’intérieur de l’EU Data Boundary. Stockage at rest, traitement in transit, inférence du modèle : tout devait rester dans les datacenters européens.

Flex Routing change ça. Concrètement, c’est un mécanisme de load balancing géographique : pendant les pics de demande, l’étape d’inferencing (le moment où le modèle traite votre prompt pour produire une réponse) peut être routée vers des datacenters hors EU. Trois destinations sont nommées par Microsoft.

If flex routing is enabled, LLM inferencing may occur in the United States, Canada, or Australia during times of peak demand.
Source : Flex routing (EU and EFTA) — Microsoft Learn

L’idée côté Microsoft est de préserver l’expérience utilisateur quand les GPU européens saturent. Quand le moteur Azure OpenAI en EU est saturé, plutôt que de faire timeout, Copilot va frapper à la porte des datacenters US, canadiens ou australiens. C’est défendable d’un point de vue ingénierie. C’est moins défendable d’un point de vue souveraineté surtout en opt-out.

2. Le calendrier et le défaut piégeux

Le calendrier officiel, tel que documenté par Microsoft :

Tenants créés après le 25 mars 2026 : Flex Routing activé par défaut, dès la provision du tenant.
Tenants existants avant le 25 mars 2026 : Microsoft renvoie vers le Message Center pour connaître le réglage par défaut appliqué à votre tenant.

En pratique, le rollout généralisé pour les tenants existants s’est fait le 17 avril 2026, via les messages MC1269219 et MC1269223 dans le Message Center M365. Plusieurs analyses de cabinets de conformité européens convergent sur cette date.

On 17 April 2026, Microsoft enabled flex routing for all Microsoft 365 Copilot tenants in the EU and EFTA. Most organisations did not notice.
Source : LinkedIn

Attention : selon Microsoft et les retours de terrain, une modification du réglage Flex Routing peut prendre jusqu’à une semaine pour se propager. Si vous décidez de désactiver, ne considérez pas que c’est immédiat : vérifiez ensuite que le réglage est bien appliqué côté tenant.

Le piège classique : ce changement est opt-out, pas opt-in. Microsoft a effectué un changement matériel de la localisation de traitement, par défaut, sans demande de consentement explicite côté admin. C’est le cœur du débat conformité que je détaille dans la section 4.

3. Quelles données sortent réellement de l’EU ?

C’est là qu’il faut être précis, parce que les raccourcis du type « vos données partent aux US » sont à la fois vrais et faux. Microsoft fait une distinction nette entre stockage et traitement :

No matter where LLM inferencing occurs, data will be encrypted in transit and at rest. Data at rest will continue to be stored inside the EU Data Boundary, except for limited pseudonymized data which may be stored outside the EU Data Boundary for security and operational purposes.
Source : Microsoft Learn

Décortiquons concrètement ce qui se passe pendant un appel Copilot routé en flex :

Le prompt et son contexte sont assemblés en EU : votre question, plus le grounding (mails, fichiers SharePoint/OneDrive, métadonnées Graph) que Copilot va injecter pour répondre.
Le paquet part chiffré vers un datacenter hors EU (US, Canada ou Australie selon la capacité disponible).
L’inférence a lieu hors EU : le modèle traite le prompt, le contexte et produit la réponse.
La réponse revient chiffrée en EU : elle est restituée à l’utilisateur, et les données d’origine restent stockées en EU.
Des données pseudonymisées peuvent rester stockées hors EU, à des fins opérationnelles et sécurité (logs système, télémétrie).

Le mot-clé, c’est pseudonymisation au sens du RGPD Article 4 (5) : la donnée n’est plus directement attribuable à une personne sans information additionnelle, mais elle reste une donnée à caractère personnel. Microsoft applique chiffrement, masquage, tokenisation et data blurring sur ces logs, mais l’autorité de réidentification reste théoriquement possible.

Mon retour terrain : beaucoup de DPO et RSSI européens lisent « data at rest stays in the EU » et concluent que tout va bien. Le point dur, c’est le moment de l’inférence — c’est là que votre prompt, et donc potentiellement vos documents et mails, sont exposés au modèle dans un datacenter hors EU. C’est ce point-là qui doit être tracé dans vos analyses de transferts.

4. L’enjeu conformité : GDPR, NIS2, DORA

Concrètement, ça donne quoi côté conformité ? Trois cadres se cumulent et chacun a sa lecture du sujet.

RGPD : un transfert vers pays tiers, par défaut

Le traitement de données personnelles dans un pays tiers est un transfert au sens des articles 44 et suivants du RGPD. Il faut une base légale :

États-Unis : décision d’adéquation via l’EU-U.S. Data Privacy Framework (Article 45 RGPD), sous réserve que Microsoft soit listé et que le transfert tombe dans le périmètre du DPF.
Canada et Australie : Clauses Contractuelles Types (Article 46(2)(c) RGPD), accompagnées d’un Transfer Impact Assessment (TIA).

Et même quand un mécanisme de transfert s’applique, ça ne dispense pas de tracer la chose proprement. Si votre DPIA mentionne un traitement intra-EU et que l’inférence se passe désormais aux US, votre DPIA est périmée. Si votre privacy policy parle d’un traitement européen, elle est inexacte. Si votre registre des traitements (RoPA, Article 30 RGPD) ne reflète pas ce transfert, c’est un manquement.

NIS2 : la chaîne d’approvisionnement IT

Pour les entités essentielles et importantes au sens NIS2, le risque de la chaîne d’approvisionnement IT est explicitement dans le scope. Un changement matériel de la localisation de traitement chez un fournisseur critique, par défaut, sans revue, c’est exactement le genre de scénario que les obligations de due diligence fournisseurs sont censées détecter.

DORA : résilience opérationnelle financière

Pour les entités financières, DORA impose une due diligence active sur les prestataires TIC critiques. Microsoft 365 Copilot relève typiquement de cette catégorie : un changement de localisation de traitement doit être tracé, évalué et documenté dans le registre des prestataires.

Attention : aucun de ces points ne nécessite une violation de données pour devenir un problème réglementaire. Un audit, une inspection CNIL ou une simple plainte suffisent. Le Message Center Microsoft n’est plus seulement un canal IT : c’est devenu un canal conformité que quelqu’un dans l’organisation doit suivre.

5. Pas-à-pas : désactiver dans le Microsoft 365 Admin Center

Si vous décidez de désactiver, voici le chemin exact. Vous aurez besoin du rôle AI Administrator (ou Global Administrator).

Connectez-vous au Microsoft 365 Admin Center.
Dans la navigation latérale, ouvrez Copilot, puis Settings.
Cliquez sur View all pour afficher les options avancées.
Trouvez l’entrée Flex routing during peak load periods.
Sélectionnez Do not allow flex routing.
Validez.

Résultat technique : tout l’inferencing LLM reste forcé dans l’EU Data Boundary, y compris pendant les pics. Le compromis assumé, c’est une dégradation potentielle de performance ou de disponibilité de Copilot pendant les périodes de surcharge régionale. Pour la plupart des usages bureautiques, c’est acceptable. Pour des usages temps réel exigeants, ça mérite un test.

6. Le piège Power Platform : un deuxième switch

Le piège que beaucoup d’admins ratent : ce premier switch ne couvre peut-être pas tous vos besoins. Le réglage du Microsoft 365 Admin Center couvre Microsoft 365 Copilot et Copilot Chat. Pour les Copilot dans Dynamics 365, Power Platform et Copilot Studio, il existe un deuxième réglage dans le Power Platform Admin Center, géré au niveau de l’environnement.

La dépendance est hiérarchique :

Si Flex Routing est désactivé côté M365 Admin Center, le réglage côté Power Platform est verrouillé sur off.
Si Flex Routing est activé côté M365 Admin Center, le réglage côté Power Platform est configurable

Pour le désactiver côté Power Platform :

Connectez-vous au Power Platform Admin Center.
Dans le panneau de navigation, allez dans Manage > Environments.
Sélectionnez l’environnement concerné.
Dans la carte Generative AI features, cliquez sur Edit.
Décochez Allow flex routing during periods of peak load.
Validez.

Ce message apparaît si vous souhaitez le modifier ici, alors qu’il a déjà été désactivé sur Microsoft 365 Admin Center :

Mon retour terrain : sur un tenant avec à la fois Microsoft 365 Copilot et des agents Copilot Studio, j’ai vu des équipes désactiver consciencieusement le réglage M365… en oubliant que les agents Copilot Studio en environnement Power Platform restaient sur le défaut hérité. Si vous opérez des deux côtés, vérifiez les deux switches, environnement par environnement.

7. Le paradoxe ADR : vous avez payé pour la souveraineté locale, et ?

Petit rappel produit pour situer : Advanced Data Residency (ADR) est un add-on M365 qui apporte un engagement durable de résidence des données dans une Local Region Geography : France, Allemagne, Norvège, Suisse, Suède, etc. C’est l’add-on que beaucoup d’entreprises européennes ont souscrit pour aller au-delà de la promesse « EU Data Boundary » de base, et garantir que leurs données restent dans leur pays.

Concrètement, ça donne quoi avec Flex Routing ?

La documentation Microsoft sur Flex Routing exclut nommément les tenants Multi-Geo du scope EU Data Boundary (donc le réglage n’apparaît pas dans le M365 Admin Center pour eux) :

Les clients qui ont acheté ou utilisé des fonctionnalités multigéographiques ne sont pas dans l’étendue de la limite de données de l’UE pour Microsoft 365, même si leur locataire est répertorié comme étant dans un pays ou une région de l’UE ou de l’AELE. Le paramètre de routage flexible n’est pas disponible dans le Centre d’administration Microsoft 365 pour les clients qui ont acheté ou utilisé des fonctionnalités multigéographiques. L’achat de fonctionnalités multigéographiques n’a pas d’impact sur la disponibilité du paramètre de routage flexible dans le centre d’administration Power Platform.
Source : Microsoft Learn

En revanche, elle ne mentionne aucune exclusion pour les tenants ADR. La conclusion logique : si vous êtes un tenant ADR localisé dans un pays EU/EFTA, vous êtes dans le scope EU Data Boundary, donc dans le scope Flex Routing. Le réglage est affiché, activable, et soumis au même défaut opt-out que les autres tenants.

Mon retour terrain : c’est là le vrai paradoxe. Les clients qui ont payé l’ADR sont précisément ceux qui ont posé un engagement de souveraineté plus strict que la moyenne. Que leur inférence Copilot puisse partir vers les US ou le Canada par défaut, sans revue documentée, c’est précisément ce qu’ils voulaient éviter en signant l’ADR. Ces tenants-là doivent vérifier le réglage en priorité, et tracer la décision dans leur RoPA et leur DPIA.

Le point dur n’est pas que Microsoft ait fait quelque chose d’illégal : les Clauses Contractuelles Types et le DPF peuvent couvrir techniquement le transfert. Le point dur, c’est que la promesse commerciale de l’ADR (résidence locale stricte) et le comportement par défaut de Flex Routing (inférence hors EU possible) ne sont pas alignés.

Conclusion

Voilà, ce que Flex Routing change pour votre tenant Microsoft 365 Copilot. Le sujet n’est pas dramatique en soi, les mécanismes de transfert juridique existent, le chiffrement tient, le stockage at rest reste en EU. Mais le défaut opt-out, sur un sujet où Microsoft avait construit une promesse forte de souveraineté, méritait largement une décision consciente de chaque admin tenant.

Les pièges principaux à retenir :

Le défaut opt-out : votre tenant est probablement déjà en flex routing actif. Vérifiez avant de conclure quoi que ce soit.
Le délai de propagation : jusqu’à une semaine après modification du réglage. Anticipez si une échéance d’audit approche.
Le deuxième switch Power Platform : désactiver côté M365 ne suffit pas si vous opérez des agents Copilot Studio ou des Copilot Dynamics 365.
Le paradoxe ADR : les tenants qui ont payé pour la résidence locale stricte sont les premiers à devoir trancher cette question, sous peine d’incohérence entre l’engagement commercial et le comportement par défaut.

Foncez vérifier votre tenant aujourd’hui. C’est cinq minutes dans l’admin center, et c’est précisément le genre de point que vous ne voulez pas découvrir le jour d’un audit CNIL ou d’une revue interne sur la souveraineté des données.

Nerdio en 2026

Vous avez entendu parler de Nerdio à droite à gauche, vous savez vaguement que ça « simplifie AVD », mais vous n’avez jamais mis les mains dedans ? Cet article est fait pour vous. On part d’une souscription Azure quasi vide et on va dérouler, capture après capture, tout ce qu’il faut faire pour aboutir à un utilisateur qui clique sur Windows App et qui ouvre un bureau AVD propre, avec son profil FSLogix qui suit.

À chaque étape je montre en parallèle ce qui apparaît côté portail Azure, parce que c’est très bien Nerdio, mais il faut comprendre ce qu’il fabrique réellement dans votre subscription. Avant de plonger dans le tuto, deux vidéos pour planter le décor :

La première fait le tour rapide des deux produits Nerdio :
- Nerdio Manager for Entreprise
- Nerdio Manager for MSP

La seconde montre un déploiement en moins de 5 minutes :

Pour vous guider plus facilement dans cet article, voici des liens rapides :

1. Les prérequis (vNet, NAT gateway, FSLogix)
2. Déployer Nerdio Manager for Enterprise depuis le Marketplace
3. Initialiser le Nerdio Manager (PowerShell + consent)
4. Enregistrer son install et premier login
5. Configuration initiale (services, vNet, AD, FSLogix)
6. Le Grant Admin Consent final
7. Tour des ressources Azure créées par Nerdio
8. Downgrade dev/test pour faire baisser la facture
9. Créer un Workspace
10. Créer un Host Pool
11. Configurer le Host Pool (RDP, SSO Entra ID, time limits)
12. Assigner les utilisateurs
13. Tester la connexion utilisateur
14. Vérifier le résultat côté Nerdio et FSLogix

1. Les prérequis

Avant de cliquer sur quoi que ce soit dans le Marketplace Azure, vous devez avoir plusieurs briques en place. Si elles ne sont pas là, vous allez avoir des erreurs classiques du genre « no subnet available » ou « FSLogix path unreachable » pendant la configuration de Nerdio. Autant les poser proprement avant.

Premier prérequis : un Virtual Network. Le vNet doit être joignable depuis votre Active Directory (ou être Entra ID joined comme chez moi), et c’est là-dedans que les session hosts vont atterrir :

Deuxième prérequis : un NAT gateway, associé à vos subnets AVD et Windows 365. La NAT gateway est la solution la plus simple, bien qu’il en existe d’autres (voir mon article) :

Troisième prérequis : un compte de stockage pour FSLogix :

Attention : sur un environnement Entra ID joined, l’authentification au file share FSLogix passe par Entra Kerberos. Pensez à activer cette option côté storage account et à attribuer les rôles RBAC Storage File Data SMB Share Contributor aux utilisateurs AVD. Sinon, vous aurez l’écran « Please wait for the FSLogix Apps Services » pendant 30 secondes puis un profil temporaire : le piège classique.

2. Déployer Nerdio Manager for Enterprise depuis le Marketplace

Direction le Marketplace Azure, on tape nerdio et on tombe sur plusieurs offres. Celle qui nous intéresse dans cet article est Nerdio Manager for Enterprise (à ne pas confondre avec Nerdio Manager for MSP qui est pour les prestataires multi-tenants) :

Sur la fiche produit, on voit que le pricing est en « BYOL via Microsoft Enterprise Contract », vous payez Nerdio sur votre facture Azure (Marketplace), pas via une licence séparée.

On clique sur Create :

L’écran Create NME Plan est un assistant Azure classique :

Premier onglet, Basics : on choisit la subscription, on crée un nouveau Resource Group dédié, et on sélectionne la région :

Attention : le compte avec lequel vous lancez le déploiement doit être Global Administrator sur Entra ID ET Owner sur la subscription. C’est rappelé dans l’écran Basics. Si vous êtes juste Contributor, ça va planter au consent.

Onglet Resource Names : on définit un préfixe et on laisse les noms par défaut. À ce stade vous voyez déjà la liste de ce qui va être déployé :

Onglet Private Endpoints : en prod vous activerez les private endpoints pour blinder la sécurité (l’App Service et le SQL deviennent inaccessibles depuis Internet). Pour notre lab dev/test on laisse décoché :

Onglet Tags : standard, vous appliquez vos tags habituels :

Et enfin Review + create. Vous validez les conditions Marketplace, vous vérifiez l’adresse mail (qui sera utilisée par Nerdio pour vous joindre support / facturation), et vous cliquez Create.

Le déploiement prend entre 5 et 15 minutes selon la région et la charge Azure du moment :

Dans l’onglet Outputs, vous récupérez l’URL de votre App Service Nerdio :

3. Initialiser le Nerdio Manager

On ouvre l’URL de l’App Service.

Premier accueil : Nerdio vous demande de lancer un script PowerShell qui va finir la plomberie (permissions, secrets, certificat dans Key Vault, app registration Entra ID) :

Cliquez sur Copy pour récupérer la commande PowerShell, puis ouvrez le Cloud Shell directement depuis l’icône en haut du portail Azure :

Vous collez la commande, vous appuyez sur Entrée et vous laissez tourner :

À la fin vous devez voir un Deployment completed successfully :

Pendant l’exécution, Entra ID vous demande de donner le consent admin pour l’app Nerdio. Cochez « Consent on behalf of your organization » et cliquez Accepter :

Si vous voulez vérifier, allez sur la page Enterprise Application nerdio-nmw-app dans Entra ID, onglet Permissions. Vous devez voir une liste impressionnante de permissions Microsoft Graph :

C’est cette app registration qui va piloter votre tenant à la place de Nerdio.

4. Premier login et registration

Une fois le script PowerShell terminé, on retourne sur l’URL Nerdio et on rafraîchit la page. Cette fois on a l’écran d’accueil avec votre tenant Entra ID et votre subscription pré-remplis. On clique sur Register Nerdio Manager.

Petit formulaire de registration côté Nerdio (Company, Name, Email, Phone) :

On clique sur Next :

5. Configuration initiale (services, vNet, AD, FSLogix)

Étape Services : Nerdio vous demande quels services vous voulez manager. Dans mon lab j’ai tout coché : Azure Virtual Desktop, Windows 365 (Cloud PCs) et Intune (Physical endpoints) :

Étape Configuration : Nerdio vous demande trois choses, dans cet ordre : un vNet, un Directory (Entra ID, AD DS, ou Entra Domain Services), et un emplacement FSLogix. On clique sur le bouton Configure à côté de Features and scope pour commencer par paramétrer Intune :

Sur la fenêtre Configure Intune, vous choisissez ce que Nerdio a le droit de faire sur Intune : Manage / Read-only / N/A pour chaque feature (devices, group membership, scripts, conditional access, app policies, etc.) :

Ensuite on revient et on configure le VNet, puis on le link au subnet AVD :

Puis Directory : C’est ce profil qui dira aux session hosts de se joindre automatiquement et de s’enrôler dans Intune au boot :

Enfin FSLogix Profiles Storage Configuration. On pointe le path UNC du share, et on coche absolument « Configure session hosts registry for Entra ID joined storage » :

Attention : pour le FSLogix sur stockage Entra ID joined, en plus de cocher la case dans Nerdio, il faut que le storage account ait été configuré avec Identity-based access côté Azure (rappel du prérequis 1) et que vos utilisateurs AVD aient le rôle RBAC Storage File Data SMB Share Contributor. C’est l’erreur n°1 sur les déploiements Entra-only.

Une fois les trois choses configurées, vous voyez l’écran de Configuration avec les trois boutons remplis (vNet sélectionné, Directory Entra ID, FSLogix location renseigné), on clique sur Done.

La console Nerdio charge alors la configuration pendant plusieurs minutes :

6. Le Grant Admin Consent final

Nerdio détecte qu’il a besoin de permissions supplémentaires pour fonctionner sur l’étendue que vous venez de définir (vNet, FSLogix, Intune).

Une popup Grant Consent apparaît, avec un warning : « The list of required permissions can take some time to fully populate. You may need to grant permissions multiple times. »

Cliquez sur le lien pour ouvrir la fenêtre de consent Entra ID.

Vous validez la longue liste de permissions et vous cliquez Accept. Vous obtenez alors l’écran « Admin Consent granted » :

Côté portail Azure, vous pouvez vérifier sur l’Enterprise App nerdio-nmw-app que les permissions Microsoft Graph sont maintenant à 29 (au lieu de 25 avant) :

De retour dans Nerdio, on coche « I have granted admin consent » et on clique OK.

Mon retour terrain : il m’est arrivé de devoir passer le consent deux fois sur cet écran. La première fois Nerdio détecte des permissions manquantes après quelques secondes et redemande. Ne paniquez pas, c’est normal, le warning vous prévient.

7. Tour des ressources Azure créées par Nerdio

Voilà, vous arrivez sur le dashboard Workspaces de Nerdio. Il est vide pour le moment, on va y revenir :

Maintenant, allez voir côté portail Azure, vous devriez voir les services Azure suivants :

App Service / App Service Plan + Application Insights
2 Automation Account
Data Collection Endpoint + Data Collection Rule + 2 Log Analytics Workspaces
Key Vault
Runbook
Smart detector alert rule
SQL database + SQL server
Storage Account

Et dans l’IAM de votre vNet, vous voyez maintenant l’app registration nerdio-nmw-app avec trois rôles : Reader et Backup Reader hérités au niveau subscription, et Network Contributor sur le vNet lui-même :

8. Downgrade dev/test pour faire baisser la facture

16 ressources Azure pour faire tourner une simple app web de management, ça pique un peu, surtout quand on découvre que Nerdio déploie par défaut :

App Service Plan en B3 (~150 €/mois)
SQL Database en S1 (~22 €/mois).

Total déploiement par défaut : autour de 248 $/mois rien que pour la console Nerdio elle-même, sans compter vos session hosts.

Nerdio le sait, et pour les environnements dev/test ou POC, ils documentent officiellement un downgrade qui fait tomber la facture à environ 60 $/mois.

Concrètement, vous allez sur la SQL Database, onglet Compute + storage, et vous basculez en Basic (For less demanding workloads) à 5 DTUs et 2 GB de data, coût estimé : 6,11 $/mois :

Puis sur l’App Service Plan, vous faites un Scale up et vous descendez de B3 vers B1 (Basic). Coût estimé : ~8,40 €/mois.

Attention : ce downgrade est officiellement supporté uniquement pour dev/test et POC. En production, gardez le B3 + S1 sinon vous allez avoir des perfs dégradées sur l’auto-scaling, les scripted actions et les opérations bulk. La KB Nerdio est claire là-dessus.

9. Créer un Workspace

On revient dans Nerdio.

Première chose à faire : aller dans Settings > Environment > Linked Resource Groups et vérifier qu’on a bien linké le RG dans lequel on veut déployer les session hosts :

Maintenant, direction Workspaces. C’est encore vide, on clique sur New Workspace.

Pour rappel, un Workspace AVD c’est juste un conteneur logique qui va regrouper vos host pools. Côté Microsoft, c’est l’objet Microsoft.DesktopVirtualization/workspaces :

Côté Azure, vous voyez maintenant apparaître la ressource de type Workspace. Nerdio a bien créé l’objet AVD pour vous :

10. Créer un Host Pool

Sur la ligne du workspace, on clique sur les trois points et on choisit Host pools :

On clique New Host Pool :

La fenêtre Add Host Pool est dense, voici mes choix pour le lab :

Host pool type : Static (pas d’auto-scale dynamique pour ce test)
Desktop experience : AVD multi-session desktop (pooled)
Directory : Default
FSLogix : Default
Initial host count : 2 pour valider le load balancing
Name (VM prefix) : nerdio-vm
Network : nerdio-vnet (AVD)
Desktop image : Windows 11 25H2 AVD + Microsoft 365 Apps (image Marketplace gallery)
VM size : D8s_v6 (8 cores, 32 GB RAM)
OS disk : 128 GB E10 Standard SSD

Nerdio prévient que la tâche est longue (entre 20 et 40 minutes pour 2 hosts), on clique OK et c’est parti. Vous pouvez suivre l’avancement dans l’onglet Tasks.

Côté Azure pendant que ça tourne, on voit déjà apparaître deux nouvelles ressources : Host pool et Application group, c’est l’objet qui va recevoir les assignations utilisateurs :

Dans l’onglet Tasks de Nerdio, on voit le déroulé : un Create host pool, puis Add hosts en parallèle pour les 2 VMs (qui prennent ~12 à 15 minutes chacune) :

Côté Azure on voit les 2 VMs apparaître avec leurs NICs respectifs, attachés au subnet AVD :

Une fois toutes les Tasks COMPLETED, on est bon :

Dans la vue Session Hosts, les deux VMs sont là, marquées Entra Joined, avec leur IP dans le subnet :

Côté Azure, sur le host pool, vous voyez le dashboard Overview : Total machines 2, Can connect 2, Can’t connect 0. Tout est vert :

11. Configurer le Host Pool (RDP, SSO Entra ID, time limits)

Le host pool tourne, mais il faut le configurer un peu avant de laisser les utilisateurs se connecter : périphériques redirigés, single sign-on Entra ID, time limits. Sur la ligne du host pool, trois points > Settings.

Onglet RDP Settings : c’est ici qu’on définit ce qui est redirigé entre le client et la session AVD. J’active Redirect microphone, Redirect speaker, Redirect cameras, Redirect clipboard, Redirect printers :

Toujours dans RDP Settings, en passant en Custom RDP configuration, je cherche la propriété enablerdsaadauth et je la mets à 1. C’est la propriété qui autorise le single sign-on Entra ID côté RDP ;:

Onglet Session Time Limits : j’active la fonctionnalité, je mets Disconnect IDLE sessions after à 1 jour et Log off DISCONNECTED sessions after à 1 heure :

Côté Azure, sur le host pool dans le portail, onglet RDP Properties, vous pouvez vérifier que Microsoft Entra single sign-on est bien sur « Connections will use Microsoft Entra authentication to provide single sign-on » :

Attention : pour que le SSO Entra ID fonctionne complètement, il faut trois choses alignées : (1) enablerdsaadauth=1 dans les RDP properties, (2) le SSO activé sur le host pool côté Azure, (3) les utilisateurs en MFA conforme aux exigences Conditional Access. C’est documenté ici : Configure single sign-on with Microsoft Entra authentication.

12. Assigner les utilisateurs

Sur la ligne du host pool, trois points > Users and groups.

Lors de l’ajout des utilisateurs, Nerdio nous propose de le faire automatiquement :

Côté Azure, sur l’Application Group, onglet Assignments, vous voyez vos utilisateurs apparaître :

Et dans l’IAM, en filtrant sur un utilisateur (avdtest4 par exemple), vous voyez bien le rôle Virtual Machine User Login qui a été attribué automatiquement par Nerdio :

Mon retour terrain : beaucoup de gens oublient ce rôle et passent 30 minutes à se demander pourquoi leur utilisateur voit le host pool dans Windows App mais ne peut pas se connecter (erreur « Your account is configured to prevent you from using this device »). C’est ici que ça se règle, et Nerdio vous le propose automatiquement : c’est exactement la valeur ajoutée du produit.

13. Tester la connexion utilisateur

Le moment de vérité.

On se connecte avec un compte de test sur Windows App (ou windows.cloud.microsoft). Dans la vue Devices, on voit notre workspace et le host pool :

Clic sur la tuile :

Premier signe qui rassure : l’écran « Please wait for the FSLogix Apps Services ». Ça veut dire que FSLogix est en train de monter le profil VHDX depuis le file share Entra Kerberos :

Et voilà : bureau Windows 11 25H2, session AVD multi-session, prête à l’emploi :

14. Vérifier le résultat côté Nerdio et FSLogix

On retourne sur le file share dans le portail Azure.

Et là, magie : un répertoire vient d’être créé par FSLogix, contenant le VHDX du profil utilisateur :

Et côté Nerdio, sur la vue User Sessions, on voit la session active. Vous pouvez log off, disconnect ou send message à l’utilisateur depuis là :

Conclusion

Voilà, en une douzaine d’étapes vous êtes passé d’un vNet vide à un environnement AVD multi-session Entra-joined avec FSLogix profiles, SSO Entra ID, et vos utilisateurs assignés, le tout piloté depuis une console unique.

Concrètement, ça donne quoi ?

Là où Microsoft vous fait jongler entre 5 blades du portail (Workspaces, Host pools, Application groups, RDP properties, IAM), Nerdio centralise tout dans une seule UI cohérente. Il vous propose automatiquement les bons réglages, comme le rôle Virtual Machine User Login qu’on aurait pu oublier.

Les 3 pièges à retenir si vous reproduisez en lab :

Le Grant Consent peut nécessiter deux passages, soyez patient.
Pour FSLogix sur un storage Entra ID joined, n’oubliez pas la case « Configure session hosts registry for Entra ID joined storage » et les rôles RBAC sur le file share.
Pour le SSO Entra ID, les trois conditions doivent être réunies : enablerdsaadauth=1 + SSO côté host pool + utilisateurs MFA-compliant.

Et n’oubliez pas le downgrade dev/test (SQL Basic + App Service B1) si vous laissez tourner l’environnement à long terme : ~190 $/mois économisés rien que sur les composants Nerdio.

Foncez tester en lab, c’est gratuit pendant 30 jours en trial Nerdio !

Et si vous galérez sur une étape, dites-le-moi en commentaire, je referai un article plus poussé sur la partie scaling et auto-scale, qui est vraiment là où Nerdio fait la différence.

Windows 365 Business en promo

Microsoft vient d’annoncer une baisse de prix permanente de 20 % sur Windows 365 Business, effective au 1^er mai 2026, sur l’ensemble des configurations de Cloud PC. Et pour les nouveaux clients éligibles, c’est 20 % supplémentaires cumulables jusqu’au 30 juin 2026. On fait le point sur ce qui change, et surtout sur les différences avec le SKU Enterprise, parce que ce n’est pas du tout la même histoire côté gestion.

Concrètement, le Cloud PC clé en main pour les PME devient nettement plus accessible. C’est une vraie bonne nouvelle pour toutes les structures jusqu’à 300 postes qui voulaient tester l’expérience Windows dans le cloud sans se farcir un déploiement AVD ou Windows 365 Enterprise.

Ce qui change concrètement

L’annonce tient en deux points, mais ils valent le coup d’être bien compris :

Baisse permanente de 20 % sur le prix catalogue de Windows 365 Business, sur toutes les configurations de Cloud PC (toutes les tailles, du 2 vCPU / 4 Go au plus costaud). Effective au 1^er mai 2026.
Promo cumulable de 20 % supplémentaires pour les nouveaux clients éligibles, jusqu’au 30 juin 2026. C’est-à-dire que sur la période, vous pouvez démarrer un Cloud PC à environ 36 % en dessous du prix d’avant le 1^er mai.

C’est une baisse structurelle, pas un coup marketing : Microsoft ajuste son catalogue. La promo additionnelle est là pour donner un coup d’accélérateur sur l’acquisition.

Cette offre est valable du 1er mai 2025 au 30 juin 2026 et réservée aux clients qui ne sont pas encore abonnés à Windows 365. Cette offre n’est pas cessible et ne peut pas être cumulée avec d’autres offres ou remises sur Windows 365.

Cette offre n’est valable qu’une seule fois par client. Le prix de réduction sera en vigueur pendant toute la durée de l’engagement d’achat. Les achats effectués avant la date d’entrée en vigueur de l’offre ne sont pas éligibles. Les taxes éventuelles sont à la charge exclusive du destinataire.

Qu’est-ce que Windows 365 ? | Windows 365

Windows 365 Business vs Enterprise : la vraie différence est dans la gestion

C’est le point qu’on me demande tout le temps en clientèle : « C’est quoi la différence entre Business et Enterprise ? ». La réponse courte : Business, c’est du Cloud PC autonome, géré dans son propre portail ; Enterprise, c’est du Cloud PC intégré dans Intune, avec tout ce que ça implique de pré-requis et de puissance.

Côté Windows 365 Business, la gestion se fait depuis le portail dédié windows365.microsoft.com. Pas besoin d’Intune, pas besoin de licences Microsoft 365 préalables, pas besoin de monter un tenant aux petits oignons.

Vous achetez vos Cloud PC, vous les assignez à des utilisateurs Entra ID, et c’est parti. L’image de l’OS est fournie par Microsoft, vous ne la personnalisez pas en profondeur, et la configuration réseau utilise l’Microsoft Hosted Network par défaut. C’est volontairement bridé pour rester simple.

Côté Windows 365 Enterprise, on change de monde. La gestion passe par Microsoft Intune (le Microsoft Intune admin center, anciennement Endpoint Manager), avec les Cloud PC qui apparaissent comme des Devices à part entière.

Vous gérez les politiques de conformité, les profils de configuration, les apps, les baselines, exactement comme pour des postes physiques. Vous pouvez utiliser des images OS personnalisées, brancher vos Cloud PC sur votre propre réseau via une Azure Network Connection (ANC) pour atteindre des ressources on-prem, et il n’y a pas de limite à 300 postes.

En contrepartie, il faut Intune + Entra ID dans la bonne édition, et un minimum de maturité IT pour piloter tout ça proprement. Pour résumer en un tableau :

Critère	Windows 365 Business	Windows 365 Enterprise
Cible	PME, jusqu’à 300 postes	Toute taille, pas de plafond
Pré-requis licences	Aucun (M365 non requis)	Intune + Entra ID requis
Gestion	Portail `windows365.microsoft.com`	Microsoft Intune admin center
Images OS	Standard Microsoft uniquement	Standard + images personnalisées (Gallery)
Réseau	Microsoft Hosted Network (par défaut)	Microsoft Hosted Network ou Azure Network Connection (ANC) vers votre VNet
Jointure	Entra ID Join	Entra ID Join ou Hybrid Join (AD on-prem)
Achat	Direct, en self-service	Via partenaire / EA / CSP
Public visé	« Je veux du Cloud PC, vite et simple »	« Je veux gérer mon parc Cloud PC comme mes postes physiques »

La règle de décision que j’applique sur le terrain :

si le client a déjà Intune et veut une gestion homogène avec ses postes physiques, ou s’il a besoin d’images custom / de réseau on-prem, c’est Enterprise.
Si le client veut un Cloud PC clé en main, pour une équipe sous les 300 utilisateurs, sans dépendance à une infra Microsoft 365 préexistante, c’est Business. Et avec la nouvelle grille tarifaire, l’argument économique devient sérieux.

Pour qui Windows 365 Business fait sens ?

Les PME jusqu’à 300 postes qui n’ont pas (encore) Intune.
Les structures qui veulent équiper rapidement un site, une filiale, des intérimaires, des consultants externes sans gérer de matériel.
Les boîtes qui ont des postes vieillissants et qui veulent prolonger leur durée de vie via un Cloud PC accessible depuis n’importe quel navigateur ou via la Windows App.
Les scénarios BYOD où le poste perso doit accéder à un environnement Windows pro maîtrisé, sans MDM sur la machine personnelle.

Là où Business ne fait pas sens : besoin d’images OS personnalisées, besoin de joindre un AD on-prem, besoin de pousser des politiques fines via Intune, plus de 300 postes. Dans ces cas-là, c’est Enterprise ou AVD.

⚠️ Le bonus à ne pas rater : -20 % supplémentaires avant le 30 juin 2026

Attention : la promo de -20 % supplémentaires cumulable avec la baisse permanente est réservée aux nouveaux clients éligibles et expire le 30 juin 2026. Au-delà, vous restez sur le nouveau prix catalogue (-20 % par rapport à avant le 1^er mai), mais le double bonus disparaît. Si vous envisagez un POC Cloud PC en PME, c’est le moment de poser les premiers Cloud PC.

Les détails d’éligibilité (qui est considéré « nouveau client », quelles configurations sont incluses) sont à vérifier sur la page Microsoft. En général, ce type d’offre exclut les clients qui ont déjà eu une souscription Windows 365 Business active dans les X derniers mois, mais le critère exact varie.

Où est passé Windows Hybrid Benefit (WHB) ?

Ce changement d’approche sur les licences occasionne un autre changement dans les offres Microsoft concernant Windows 365 Business :

Microsoft Windows 365 | Microsoft Licensing Resources

Windows Hybrid Benefit (WHB) a été retiré au 1er mai 2026, en même temps que la baisse de 20 % :

⚠️ Effet de bord à connaître : au 1er mai 2026, Microsoft a aussi retiré de la vente la version Windows 365 Business with Windows Hybrid Benefit (les SKU qui donnaient ~16 % de remise quand l’utilisateur avait déjà une licence Windows 10/11 Pro). Les souscriptions existantes restent renouvelables, mais on ne peut plus en acheter de nouvelles, et il n’y a pas de migration automatique vers les SKU standard.

Cloud Factory

Mon retour terrain et le CTA

Windows 365 Business souffrait jusqu’ici d’un positionnement prix un peu raide pour les très petites structures, surtout face à un PC physique amorti sur 4-5 ans. Avec -20 % permanents, l’arbitrage économique change : sur une PME de 20-50 personnes qui veut s’épargner la gestion matérielle (et les vols, les pannes, les départs avec le portable…), le Cloud PC redevient une vraie option à mettre sur la table.

Et pour ceux qui hésitaient à tester : avec le double bonus jusqu’au 30 juin 2026, vous pouvez monter un POC sur 2-3 utilisateurs pour quasiment rien et vous faire votre propre idée. Foncez tester. Si l’expérience colle, vous savez où me trouver pour discuter d’un passage à Enterprise quand la boîte grossira et que les besoins de gestion fine arriveront.

Entra Passkey sous Windows

Microsoft a enfin fait passer les Microsoft Entra passkeys on Windows en General Availability fin avril 2026. Concrètement, ça veut dire qu’on peut maintenant enregistrer des passkeys FIDO2 directement dans le conteneur Windows Hello et s’authentifier à Entra ID en passwordless. Cela fonctionne que le PC soit Entra-joined, registered, ou rien !

Personnel, partagé, BYOD, peu importe. Avec le rollout en cours jusqu’à mi-juin 2026, c’est le bon moment pour tester en lab avant que la migration auto vers les passkey profiles ne tombe sur votre tenant.

Dans cet article, on va voir comment configurer ça côté tenant (avec un focus sur la distinction entre l’ancienne UI Passkey (FIDO2) settings et la nouvelle expérience Passkey profiles), comment l’utilisateur enregistre sa passkey côté poste.

Au programme

Un peu d’histoire …
Entra passkey on Windows : c’est quoi exactement ?
Pré-requis tenant, poste et utilisateur
Ancienne UI : configuration via « Passkey (FIDO2) settings »
Nouvelle UI : configuration via « Passkey profiles »
Côté utilisateur : enregistrer sa première passkey Windows Hello
Le piège du Enforce attestation
Retex : les erreurs qu’on a croisées en lab

0. Un peu d’histoire …

Au début, l’authentification sur les environnements Microsoft reposait presque exclusivement sur le mot de passe. Un simple login + password suffisait pour accéder aux ressources d’entreprise, aussi bien on-premises que cloud.

Rapidement, les limites de ce modèle sont devenues évidentes :

mots de passe faibles
réutilisation entre services
phishing
fuites de credentials
attaques par bruteforce

Pour renforcer la sécurité, le MFA est alors devenu la norme. La première vague de MFA a surtout reposé sur les SMS, les appels téléphoniques ou les codes OTP. Cela améliorait clairement la sécurité, mais avec plusieurs problèmes :

fatigue utilisateur
dépendance au réseau mobile
vulnérabilités SIM swap
expérience parfois lourde

Ensuite sont arrivées les applications d’authentification comme Microsoft Authenticator, avec les notifications push, le number matching ou les OTP locaux.

L’expérience devenait plus fluide, mais on restait encore dans un modèle “mot de passe + validation secondaire”. Puis Microsoft a commencé à pousser fortement le passwordless avec :

Windows Hello for Business
les clés FIDO2 comme YubiKey

Cette fois, l’objectif était clair : supprimer complètement le mot de passe. Le problème, c’est que ces solutions restaient souvent liées à un device d’entreprise, à un PC Entra joined, ou à une clé hardware dédiée.

Les environnements BYOD, postes partagés ou machines temporaires restaient donc compliqués à gérer proprement en passwordless. Puis sont arrivées les passkeys synchronisées sur mobile :

iPhone via iCloud Keychain
Android via Google Password Manager
Microsoft Authenticator

Et c’est là qu’apparaît aujourd’hui “Entra passkey on Windows”. Le principe change beaucoup de choses : le PC Windows peut désormais héberger lui-même une passkey FIDO2 sans avoir à être joint au tenant.

1. Entra passkey on Windows : c’est quoi exactement ?

Pour rappel, jusqu’ici, si vous vouliez du passwordless FIDO2 sur Entra ID, il fallait soit une clé hardware type YubiKey, soit Windows Hello for Business (qui exige un device Entra-joined ou registered).

Les PC perso ou partagés étaient alors condamnés au mot de passe + MFA classique.

Avec Entra passkey on Windows, Microsoft permet désormais de créer une passkey FIDO2 directement dans le conteneur Windows Hello local, sans que le device soit joint au tenant. La passkey est device-bound (elle ne quitte jamais le poste), stockée dans le TPM, et débloquée par PIN, empreinte ou reconnaissance faciale.

Plusieurs passkeys peuvent cohabiter pour plusieurs comptes Entra sur le même PC.

Attention, le piège classique : ne confondez pas Entra passkey on Windows avec Windows Hello for Business.

Les deux utilisent Windows Hello, mais ce sont deux mécanismes distincts. Voici le tableau qui devrait vous éviter de mélanger les deux en réunion :

Critère	Entra passkey on Windows	Windows Hello for Business
Standard	FIDO2	Protocole 1P Microsoft (pas FIDO2)
Device join requis	Non	Oui (Entra-joined ou registered)
Sign-in OS Windows	Non	Oui
SSO Entra après login	Non	Oui
Provisionnement	User-initiated	Auto au device registration
Plusieurs comptes / device	Oui	Non (1 device = 1 compte)
Pilotage	Authentication Methods + passkey profiles	Intune / GPO

En clair : sur un device managé Entra-joined, gardez Windows Hello for Business. Sur un poste non-joined, perso ou partagé, Entra passkey on Windows est ce qu’il vous faut.

2. Pré-requis tenant, poste et utilisateur

Avant de vous lancer dans la conf, vérifiez que vous cochez tout ça :

Périmètre	Pré-requis
Tenant	Microsoft Entra ID (toute édition). Authentication Policy Admin ou Global Admin pour configurer.
Tenant	Méthode Passkey (FIDO2) activée dans Authentication methods.
Tenant	Conditional Access qui n’exige pas un device compliant ou Entra-joined sur le flux d’enregistrement.
Poste	Windows 11 24H2 minimum (build 26100+). Le provider passkey natif n’existe pas sur 23H2 ou Windows 10.
Poste	Edge ou Chrome à jour (≥ version 124).
Poste	TPM 2.0 opérationnel (`tpm.msc` doit afficher « prêt »).
Poste	Windows Hello configuré : PIN obligatoire, biométrie recommandée.
User	Une MFA réussie dans les 5 dernières minutes avant de cliquer « Add » sur la passkey.

Attention : sans Windows 11 24H2, le flux WebAuthn ne propose pas Windows Hello comme provider de passkey, et vous retombez sur l’ancien flux « Security key » qui demande un device externe (YubiKey, smartphone). C’est la cause numéro 1 d’enregistrements qui échouent.

3. Ancienne UI : configuration via « Passkey (FIDO2) settings »

Si vous n’avez pas encore migré vers la nouvelle expérience, vous êtes encore sur la vue legacy Passkey (FIDO2) settings. Vous la reconnaissez à un bandeau bleu en haut : « Synced passkeys and passkey profiles are now available. Upgrade to the new experience » :

Tant que vous n’avez pas cliqué sur ce lien, vous restez sur l’ancien modèle, et il fonctionne très bien pour Entra passkey on Windows, à condition de bien renseigner manuellement les AAGUIDs :

Authentificateur Windows Hello	AAGUID	Description
Authentificateur matériel Windows Hello	08987058-cadc-4b81-b6e1-30de50dcbe96	Clé privée stockée dans un module TPM basé sur le matériel.
Authentificateur matériel Windows Hello VBS	9ddd1817-af5a-4672-a2b9-3e3dd95000a9	La sécurité basée sur la virtualisation (VBS) utilise la virtualisation matérielle et l’hyperviseur Windows pour stocker des clés privées dans le module TPM de l’ordinateur hôte.
Authentificateur logiciel Windows Hello	6028b017-b1d4-4c02-b4b3-afcdafc96bb2	Clé privée stockée dans un module TPM basé sur logiciel.

Étape 0 : Connectez-vous au Microsoft Entra admin center, allez dans Protection → Authentication methods → Policies → Passkey (FIDO2) :

Étape 1 : Onglet Enable and Target : activez la méthode et scopez les utilisateurs concernés (un groupe pilote pour démarrer, c’est plus sain).

Étape 2 : Onglet Configure, dans la section General :

Allow self-service set up : Yes
Enforce attestation : No (j’insiste, on en reparle plus bas)

Étape 3 : Section Key Restriction Policy :

Enforce key restrictions : Yes
Restrict specific keys : Allow

Cliquez sur Add AAGUID et ajoutez les 3 AAGUIDs Windows Hello :

AAGUID	Authenticator
`08987058-cadc-4b81-b6e1-30de50dcbe96`	Windows Hello Hardware Authenticator (TPM matériel)
`9ddd1817-af5a-4672-a2b9-3e3dd95000a9`	Windows Hello VBS Hardware Authenticator (VBS + TPM)
`6028b017-b1d4-4c02-b4b3-afcdafc96bb2`	Windows Hello Software Authenticator (TPM logiciel)

Vous pouvez aussi ajouter les AAGUIDs Microsoft Authenticator si vous voulez autoriser les passkeys via l’app mobile :

90a3ccdf-635c-4729-a248-9b709135078f : Microsoft Authenticator Android
de1e552d-db1d-4423-a619-566b625cdc84 : Microsoft Authenticator Apple

Étape 4 : Cliquez sur Save en bas. Et c’est tout pour l’ancienne UI.

4. Nouvelle UI : configuration via « Passkey profiles »

Microsoft a introduit en mars 2026 le modèle des passkey profiles, qui remplace progressivement l’ancienne config FIDO2. L’idée : pouvoir définir plusieurs profils (jusqu’à 3 par tenant) avec des règles différentes selon les groupes :

Par exemple un profil avec attestation enforced pour les admins (YubiKey obligatoire), et un autre sans pour les utilisateurs standards (Windows Hello autorisé).

L’auto-enablement de la nouvelle UI court d’avril à fin mai 2026 sur les tenants. Donc même si vous ne faites rien, Microsoft va finir par migrer votre tenant. Mon conseil : faites la bascule volontairement, comme ça vous maitrisez le moment et ce qui change.

Étape 0 : Toujours dans Authentication methods → Passkey (FIDO2), cliquez sur le lien « Upgrade to the new experience » dans le bandeau bleu.

Étape 1 : Microsoft migre votre conf existante dans un Default passkey profile. Vos AAGUIDs et restrictions actuels sont préservés. Le passkeyType du profil est déterminé par votre réglage d’attestation :

Enforce attestation	Types autorisés par défaut
Enabled	Device-bound uniquement
Disabled	Device-bound + Synced (configurable)

Attention : si vous aviez Enforce attestation = No, l’upgrade activera aussi les synced passkeys par défaut (iCloud Keychain, Google Password Manager). Si vous ne voulez pas ça pour des raisons de gouvernance (clés hors du périmètre maitrisé), repassez le profil sur « Device-bound only » juste après l’upgrade.

Étape 2 : Cliquez sur le Default passkey profile pour l’éditer. Le panneau latéral s’ouvre avec :

Name : Default passkey profile (verrouillé, on ne peut pas le supprimer ni le renommer)
Enforce attestation : décoché
Passkey types : Device-bound, Synced (ajustez si besoin)
Target specific AAGUIDs : à cocher si vous voulez forcer une allow-list explicite

Étape 3 : En théorie, depuis la GA de fin avril 2026, Microsoft a supprimé l’obligation d’allow-lister les AAGUIDs Windows Hello. Donc si votre tenant a bien reçu la bascule, vous n’avez rien d’autre à faire.

En pratique pendant le rollout (qui finit mi-juin 2026), le tenant peut ne pas encore avoir basculé. Si l’enregistrement échoue côté utilisateur sans raison apparente, cochez Target specific et ajoutez les 3 AAGUIDs Windows Hello. C’est le contournement que j’ai dû appliquer en lab en mai 2026 :

Authentificateur Windows Hello	AAGUID	Description
Authentificateur matériel Windows Hello	08987058-cadc-4b81-b6e1-30de50dcbe96	Clé privée stockée dans un module TPM basé sur le matériel.
Authentificateur matériel Windows Hello VBS	9ddd1817-af5a-4672-a2b9-3e3dd95000a9	La sécurité basée sur la virtualisation (VBS) utilise la virtualisation matérielle et l’hyperviseur Windows pour stocker des clés privées dans le module TPM de l’ordinateur hôte.
Authentificateur logiciel Windows Hello	6028b017-b1d4-4c02-b4b3-afcdafc96bb2	Clé privée stockée dans un module TPM basé sur logiciel.

Étape 4 : Save. Vous pouvez créer jusqu’à 3 profils différents et les assigner à des groupes différents via l’onglet Enable and target.

5. Côté utilisateur : enregistrer sa première passkey Windows Hello

Maintenant qu’on est bon côté tenant, voyons l’expérience utilisateur. Le poste doit être en Windows 11 24H2, avec PIN Hello configuré et Edge à jour. C’est important.

Étape 0 : L’utilisateur ouvre Edge en session normale, et fait une MFA fraîche sur My Sign-Ins | Security Info | Microsoft.com → Add sign-in method → choisissez Passkey dans la liste :

Attention : ne sélectionnez pas « Security key » ou « USB security key » si vous avez ces options. C’est l’ancien flux FIDO2 qui ne déclenche pas le provider Windows Hello. Le bon choix est « Passkey », qui appelle le picker WebAuthn de l’OS et propose Windows Hello comme provider.

Étape 1 : Windows ouvre une fenêtre qui demande où enregistrer la passkey. Choisissez « This Windows device » (ou « Windows Hello » selon la version d’Edge).

Étape 2 : Le prompt Windows Hello apparaît. Authentifiez-vous avec visage, empreinte ou PIN Hello.

Étape 3 : Donnez un nom à la passkey (ex : « Laptop perso », « PC bureau »). Validez.

C’est bien enregistré sur votre compte :

Mais aussi sur votre poste :

Concrètement, ça donne quoi à la prochaine connexion ? L’utilisateur tape son email sur la page de login Microsoft, le navigateur propose la passkey du device, Windows Hello se déclenche (visage / PIN) et il est connecté. Plus de mot de passe, plus de SMS, plus de prompt MFA séparé. Le rêve.

6. Le piège du Enforce attestation

C’est LE piège qui m’a fait perdre du temps en lab et que vous allez forcément rencontrer si vous avez le réflexe sécu de tout durcir :

Le réglage Enforce attestation dans le profil passkey demande à l’authentificateur de fournir une preuve cryptographique signée par le constructeur, garantissant qu’il s’agit bien d’un device authentique (typiquement une YubiKey certifiée FIDO). Sur le papier, c’est une bonne pratique sécu.

Le problème : Windows Hello ne fournit pas encore d’attestation reconnue par Entra. Microsoft le dit explicitement dans la doc :

À noter : la doc MS Learn parle encore de public preview à la date de rédaction, mais la limite est confirmée post-GA :

Attestation isn’t supported for Microsoft Entra passkey on Windows during public preview. As a result, if Enforce attestation is enabled in a passkey profile that allows Windows Hello AAGUIDs, passkey registration attempts to Windows Hello will fail.

In the Authentication methods policy in the Microsoft Entra admin center, ensure that Enforce attestation is set to No for any passkey profile that includes Windows Hello AAGUIDs during public preview.
Enable Microsoft Entra passkey on Windows — Microsoft Learn

Concrètement, si vous cochez Enforce attestation = Yes sur un profil qui scope des utilisateurs sur Windows Hello, l’enregistrement échoue à la dernière étape (juste au moment où l’utilisateur nomme la passkey).

Côté serveur Entra, la requête est rejetée parce que la « preuve » attendue n’arrive pas :

Le piège classique : vous activez Enforce attestation en pensant durcir la conf, et vous cassez tout l’enregistrement Windows Hello sans message d’erreur clair. Vos utilisateurs vous appellent en disant « ça marche pas », et vous galérez à comprendre pourquoi parce que la conf semble propre.

La solution propre : deux profils séparés

Profil « YubiKey / clés certifiées » : Enforce attestation = Yes, scopé aux admins / users à fort privilège. AAGUIDs des modèles YubiKey autorisés en allow-list.
Profil « Windows Hello » : Enforce attestation = No, scopé aux utilisateurs standards. Allow-list avec les 3 AAGUIDs Windows Hello.

C’est exactement ce que la nouvelle UI passkey profiles permet de faire (jusqu’à 3 profils par tenant). Sur l’ancienne UI, vous étiez obligé de choisir un seul réglage tenant-wide, d’où l’intérêt de migrer si vous avez des cas d’usage mixtes.

Mon retour terrain : pour le moment, sur les Windows Hello passkeys, on accepte de se passer d’attestation. Le risque est limité parce que les credentials sont stockés dans le TPM et device-bound. Le jour où Microsoft livrera l’attestation Windows Hello, on rebascule. Pour les YubiKeys, l’attestation reste obligatoire.

7. Retex : les erreurs qu’on a croisées en lab

Pour finir, le vrai retour de tests, parce que la doc Microsoft ne couvre pas les cas où ça part en sucette. Voici les deux erreurs principales rencontrées en lab et comment les diagnostiquer.

Erreur 1 : « We’re sorry, we ran into a problem »

Message qui apparait juste à l’étape Name your security key, après que la clé ait été reconnue. Avec un Correlation ID dans les détails. Frustrant parce que tout semble fonctionner jusqu’à la dernière seconde.

Cause la plus fréquente : vous êtes sur le mauvais flux. Vous avez cliqué sur « Security key » au lieu de « Passkey » dans Add sign-in method. Le flux Security key n’utilise pas Windows Hello comme provider et tente de s’enregistrer comme une clé externe, d’où le crash final.

Erreur 2 : « Passkey not registered »

Message qui apparait sur le bon flux (Passkey, pas Security key), avec le texte « This might be due to a timeout, a canceled request or a private browsing window ». Le message officiel suggère timeout / cancel / private mode, mais en pratique la cause est ailleurs.

De mon côté, je n’ai eu aucun souci en navigation privée :

Cause #1 : Windows Hello pas configuré. Vérifiez Paramètres → Comptes → Options de connexion → Code PIN (Windows Hello). Sans PIN Hello, le provider n’a rien à appeler.

Cause #2 : rollout GA pas encore activé sur votre tenant. C’est la cause que j’ai rencontrée. Microsoft a annoncé que la GA enlève l’obligation d’allow-lister les AAGUIDs Windows Hello, mais cette bascule se déploie progressivement jusqu’à mi-juin 2026. Si votre tenant n’a pas encore reçu la modification, l’enregistrement échoue silencieusement.

Fix : dans le passkey profile, cochez Target specific AAGUIDs et ajoutez explicitement les 3 AAGUIDs Windows Hello. Save, retentez. Ça contourne le délai de rollout.

Cause #3 : Windows trop vieux. Sur 23H2 ou Windows 10, le picker n’affiche pas « This Windows device » dans la liste des providers. Vous voyez seulement « iPhone/Android » et « Security key ». Pas de chemin valide pour Windows Hello passkey.

Fix : passez en 24H2.

Cause #4 : Enforce attestation = Yes sur un profil scopant Windows Hello (cf. section précédente).

Fix : vérifiez que Enforce attestation est bien à No.

Conclusion

Entra passkey on Windows comble enfin un trou dans la stratégie passwordless de Microsoft : les PC non-managés peuvent désormais s’authentifier en FIDO2 sans avoir à sortir une YubiKey ni à passer par le téléphone. Pour les contractors, les postes partagés, les BYOD, c’est une vraie avancée.

Les pièges principaux à retenir :

Windows 11 24H2 minimum côté poste, sinon vous restez bloqué sur l’ancien flux Security key
Choisir « Passkey » et pas « Security key » dans Add sign-in method
Ne pas cocher Enforce attestation sur le profil qui scope Windows Hello
Pendant le rollout GA (avril → mi-juin 2026), allow-lister explicitement les 3 AAGUIDs Windows Hello si l’enregistrement échoue
Migrer volontairement vers les passkey profiles avant l’auto-enablement de fin mai 2026

Foncez tester en lab avec un compte de test, validez le flux, puis pilotez le déploiement sur un groupe pilote avant d’ouvrir vanne large. Et surtout, anticipez la migration auto vers les passkey profiles qui tombe entre maintenant et fin mai — autant maitriser le moment plutôt que le subir.

Enfin, pour aller plus loin :

À tester d’urgence en lab !

Azure Virtual Desktop Hybride

Pendant longtemps, faire de l’AVD ailleurs que dans Azure, c’était soit du AVD on Azure Local, soit… rien. Pour ceux qui n’avaient pas encore investi dans le HCI mais qui avaient déjà du Hyper-V, du VMware ou du Nutanix qui tournait depuis dix ans en datacenter, l’équation était la même : reverse-proxy + RDS + bricolage maison. Microsoft vient enfin d’ouvrir la porte avec Azure Virtual Desktop Hybrid, en Public Preview depuis le 4 mai 2026.

Cette préversion est le fruit d’un travail continu de la part de Microsoft avant même l’annonce officielle de la fonctionnalité lors du Microsoft Ignite de 2025 à San Francisco.

Today, we’re excited to announce Azure Virtual Desktop for hybrid environments, a new capability for bringing the power of cloud-native desktop virtualization to existing on-premises infrastructure. With this update, on-premises Arc-Enabled Servers can be configured as AVD session hosts. This expands Azure Virtual Desktop’s hybrid capabilities beyond Azure Local to Microsoft Hyper-V, Nutanix AHV, VMware vSphere, physical Windows Servers, or anywhere Arc-Enabled Servers can be deployed on-premises.

Microsoft Tech Coommunity

Et la philosophie de fonctionnement est élégante : Azure Arc enrôle vos VMs on-prem, une extension AVD les transforme en session hosts, et le service AVD continue de vivre dans le cloud comme d’habitude. Bref, pas de nouvelle stack à apprendre, juste une nouvelle case à cocher.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

Quelle est la nouveauté ?

Comme annoncé en introduction, Microsoft a publié le 4 mai 2026 la préversion publique d’Azure Virtual Desktop Hybrid. Le principe est simple : on prend une VM Windows qui tourne déjà chez vous (sur Hyper-V, VMware, Nutanix ou même un serveur physique), on l’enrôle dans Azure Arc, on lui pose une extension AVD, et hop, elle devient un session host AVD à part entière. L’utilisateur se connecte via la Windows App, exactement comme s’il attaquait un host pool 100 % Azure.

With Azure Virtual Desktop Hybrid, customers can run Azure Virtual Desktop session hosts on-premises using their existing hardware and preferred hypervisor connected through Microsoft Azure Arc. The Azure Virtual Desktop service remains in Azure, while session hosts can be deployed anywhere on-premises Azure Arc-enabled servers are supported. Users can access their desktops through the familiar Windows App.

This matters because it gives customers a phased, lower-risk path to cloud adoption:

Modernize legacy VDI environments at their own pace, preserving investments in datacenters, hardware, and operational tools.

Adopt cloud-managed desktops incrementally, with a clear path to migrate session hosts to Azure when the time is right.

Keep existing partner integrations for virtual machine management and provisioning.

Microsoft Tech Community

Pour rappel, jusqu’ici, faire tourner AVD ailleurs que dans Azure imposait soit AVD on Azure Local (anciennement Azure Stack HCI). Cela exigeait d’investir dans une stack HCI Microsoft – soit de partir sur du bon vieux RDS on-prem, en sacrifiant tout l’écosystème AVD (FSLogix moderne, app groups, Insights, Windows App).

Avec AVD Hybrid, ce dilemme s’efface : la documentation Microsoft Learn confirme que les VMs on-prem se comportent comme de vrais session hosts AVD pilotés depuis le portail Azure.

C’est un vrai changement de philosophie : historiquement, AVD c’était « tu déplaces ta VDI dans Azure, et après on en reparle ». Aujourd’hui, c’est « tu gardes ton hyperviseur, on apporte juste le control plane AVD chez toi ».

Ça ouvre AVD à toute une population qui en avait été tenue à l’écart pour des raisons de souveraineté, de coûts d’egress ou tout simplement parce qu’ils avaient déjà payé leur datacenter.

Est-ce la même chose qu’AVD sur Azure Local ?

C’est le même esprit, mais pas la même mécanique. AVD on Azure Local exige une infrastructure HCI Microsoft certifiée, avec ses nœuds, ses switches, son cluster, son réseau SDN. AVD Hybrid, lui, ne demande qu’une chose : une VM Windows qui peut joindre Azure Arc. Le reste, c’est votre hyperviseur qui le gère, peu importe lequel.

Autrement dit :

Pas besoin de hardware certifié Azure Local
Pas besoin de cluster spécifique – une simple VM Windows suffit
Le control plane AVD reste dans Azure (le service est rendu par Microsoft, comme pour AVD classique)
Les session hosts vivent chez vous, et c’est Azure Arc qui sert de pont

Si vous avez déjà déployé des serveurs Azure Arc-Enabled (par exemple pour bénéficier d’Azure Policy, Defender for Cloud ou Update Manager sur du on-prem), vous êtes déjà à 80 % du chemin. Il ne reste plus qu’à poser l’extension AVD et à brancher le session host sur un host pool.

Quels hyperviseurs sont supportés ?

La réponse de Microsoft est volontairement large : tout endroit où Azure Arc peut s’installer. Concrètement, c’est confirmé pour :

Microsoft Hyper-V (Windows Server, Hyper-V Server)
VMware vSphere (ESXi 7.x / 8.x)
Nutanix AHV
Serveurs Windows physiques (oui, vous pouvez transformer un poste rack en session host)

C’est ce que dit explicitement l’annonce officielle :

On-premises Arc-Enabled Servers can be configured as AVD session hosts. This expands Azure Virtual Desktop’s hybrid capabilities beyond Azure Local to Microsoft Hyper-V, Nutanix AHV, VMware vSphere, physical Windows Servers, or anywhere Arc-Enabled Servers can be deployed on-premises.

Microsoft Tech Community

Côté partenaires de lancement, Microsoft a explicitement nommé Nerdio, ControlUp, LoginVSI et Nutanix comme étant déjà alignés avec la Preview. Si vous utilisez Nerdio Manager for Enterprise, la fonctionnalité est intégrée dès aujourd’hui.

Quels OS et quelles licences sont éligibles ?

C’est le tableau qu’il faut imprimer et coller à côté de l’écran. Voici la matrice officielle issue de la documentation Microsoft Learn :

OS	Déploiement supporté	Licences éligibles
Windows Server 2016 / 2019 / 2022 / 2025	VMs et serveurs physiques	RDS CAL avec Software Assurance, ou RDS User Licenses en souscription
Windows 11 / Windows 10 Enterprise mono-session	VMs uniquement (pas de PC physique)	M365 E3/E5/A3/A5/F3, M365 Business Premium, Windows Enterprise E3/E5, Windows Education A3/A5, Windows VDA per user
Windows 11 / 10 Enterprise multi-session	Non supporté hors Azure	n/a

Le piège classique pour ceux qui font de l’AVD depuis longtemps : Windows 11 Enterprise multi-session n’est PAS supporté en hybride. Cette SKU reste exclusive à Azure. Si vous voulez du multi-utilisateur sur du on-prem, il faudra repasser sur du Windows Server avec le rôle Remote Desktop Session Host. C’est cohérent avec la philosophie multi-session, qui est historiquement liée à un avantage Azure-only.

Concernant la fameuse licence « Windows Cloud Hybrid » annoncée pour la GA : elle n’est PAS exigée pendant la Public Preview. Vous pouvez tester avec vos licences existantes. À la GA, Microsoft annoncera les conditions tarifaires définitives.

Entra Join ou jointure de domaine ?

Tous les modes sont supportés, et c’est une très bonne nouvelle. Mes propres tests le confirment :

Microsoft Entra Join pur : la VM s’enregistre directement dans le tenant. Idéal pour les machines Windows 11 mono-session, surtout dans une logique zéro-trust. Pas besoin de contrôleur de domaine joignable depuis la VM.

Active Directory (jointure de domaine traditionnelle) : fonctionne parfaitement, surtout pour des Windows Server qui ont besoin de Kerberos pour attaquer des serveurs de fichiers SMB on-prem ou des bases SQL avec authentification intégrée.

Active Directory + Microsoft Entra Connect (jointure de domaine traditionnelle, synchronisée vers Entra) :

Mon retour terrain :

Pour Windows 11 mono-session, l'Entra Join pur est plus rapide à mettre en place et évite tout le pataquès du DC à rendre joignable depuis le réseau de l'hyperviseur. 

Pour Windows Server, j'ai gardé le domain-join classique, parce que dans les vrais projets, le serveur de fichiers SMB est très souvent encore en AD on-prem et qu'on veut éviter de mixer les modèles. Les deux cas marchent du premier coup, je le détaillerai plus loin dans les cas pratiques.

Quels sont les prérequis à respecter ?

Avant de se lancer, il faut cocher quelques cases. Voici le récap :

Prérequis	Détail
Souscription	Une souscription Azure active
Resource providers	`Microsoft.HybridCompute`, `Microsoft.HybridConnectivity`, `Microsoft.GuestConfiguration`, `Microsoft.DesktopVirtualization`
RBAC	Azure Connected Machine Onboarding + Desktop Virtualization Contributor
Identité	Microsoft Entra ID (Entra Join ou AD synchronisé)
Réseau	Sortie TCP 443 vers Azure Arc + endpoints AVD
OS	Windows Server 2016+ ou Windows 11/10 Enterprise mono-session
Hyperviseur	Hyper-V, VMware, Nutanix AHV, ou serveur physique
Host pool	Validation host pool obligatoire pendant la Preview

Le piège classique : oublier le resource provider Microsoft.HybridConnectivity, qui est nécessaire pour la connectivité SSH/RDP via Arc. Si vous l’oubliez, l’enrôlement Arc passe, mais certaines opérations downstream peuvent silencieusement échouer. Croyez-en quelqu’un qui a passé une bonne demi-heure à se demander pourquoi 🙃.

Qu’est-ce qu’un « validation host pool » ?

Un validation host pool est un host pool AVD marqué comme environnement de validation (case à cocher dans le portail). Microsoft le réserve aux features en preview, et c’est actuellement le seul mode supporté pour AVD Hybrid pendant la Public Preview. La documentation est explicite :

Azure Virtual Desktop Hybrid is currently in Public Preview and is only supported with validation host pools. If you deploy a production host pool then you will need to redeploy once Windows Cloud Hybrid is Generally Available.

Microsoft Learn

Ne mettez pas en prod votre validation host pool. Servez-vous-en pour piloter, valider votre architecture, former l’équipe, mais prévoyez le redéploiement quand la GA sortira.

Quelles fonctions ne sont PAS supportées en Preview ?

Comme toute préversion qui se respecte, il y a des trous dans la raquette. Microsoft liste explicitement :

Power management dans le portail Azure (start/stop/deallocate sur les VMs)
Auto-Scale
Start VM on Connect
Session Host Configuration

C’est logique : ces fonctions reposent toutes sur le control plane Azure pour piloter les VMs (les démarrer, les arrêter, les redimensionner). Or, en hybride, c’est votre hyperviseur qui contrôle l’alimentation et le lifecycle des VMs. Microsoft ne peut pas démarrer une VM Hyper-V chez vous… à moins de passer par des extensions Arc dédiées, ce qui n’est pas encore en place.

Attention : l’absence d’Auto-Scale signifie que vous devez prévoir vous-même la scalabilité (provisioning manuel ou via votre orchestrateur d’hyperviseur). Pour des populations de plusieurs centaines d’utilisateurs, ce sera vite un bloqueur si vous comptiez sur AVD pour faire ça à votre place.

Combien ça coûte pendant la Preview ?

Pendant la Public Preview, vous payez :

Vos licences Windows / RDS CAL / M365 (rien de neuf, ce sont les mêmes qu’avant)
L’enrôlement Azure Arc (gratuit pour les serveurs Arc-Enabled de base, payant pour certaines features Defender / Update Manager / Policy avancées)
Le service AVD lui-même (pas de coût supplémentaire spécifique au mode hybride à ce stade)

À la GA, une licence Windows Cloud Hybrid sera très probablement requise pour les session hosts hybrides. Microsoft n’a pas encore communiqué les tarifs définitifs, mais le pattern habituel sur les « extensions cloud d’AVD » laisse penser à un modèle per user / month aligné sur les RDS User License Souscriptions.

Étape 0 : rappel des prérequis

Avant tout test, assurez-vous que :

Vous avez une souscription Azure active
Votre VM on-prem (Hyper-V, VMware, Nutanix…) est installée, à jour, et joignable en TCP 443 sortant vers Internet
Votre identité (Entra Join ou jointure AD) est déjà configurée avant l’enrôlement Arc
Que vous disposiez du rôle Azure Connected Machine Onboarding pour créer et gérer les ressources Azure Arc :

Que vous disposiez du rôle Contributeur à la virtualisation des postes de travail pour la gestion des pools d’hôtes Azure Virtual Desktop.

Étape 1 : enregistrer les resource providers

Sur la souscription cible, ouvrez Subscriptions > [votre sub] > Resource providers, puis vérifiez ou enregistrez si nécessaire :

Microsoft.HybridCompute
Microsoft.HybridConnectivity
Microsoft.GuestConfiguration
Microsoft.DesktopVirtualization

Vous pouvez aussi le faire en PowerShell :

'Microsoft.HybridCompute','Microsoft.HybridConnectivity','Microsoft.GuestConfiguration','Microsoft.DesktopVirtualization' | ForEach-Object { Register-AzResourceProvider -ProviderNamespace $_ }

Étape 2 : valider la readiness AVD

C’est l’étape clé documentée par Microsoft. L’objectif : confirmer que votre pool d’hôtes AVD de test peut être utilisé pour le test :

Ouvrez le portail Azure.
Cherchez Azure Virtual Desktop dans la barre.
Allez dans Host pools > Create.
Dans l’onglet Basics, cochez « Validation environment: Yes »

Attention : ne confondez pas validateavd (l’onglet sur la doc Microsoft, qui parle bien d’AVD) avec validatearc. Ce sont deux choses différentes : validateavd est ce qu’on cherche ici. La validation côté Arc (vérifier les resource providers, les rôles RBAC) se fait en parallèle.

Si vous ne disposez pas encore d’un pool d’hôtes AVD, veuillez le créer dans l’étape 3.

Étape 3 : créer le validation host pool, le workspace et l’application group

Si le pool d’hôtes AVD n’est pas encore créé dans votre environnement Azure, commencez par la base via l’assistant de création du host pool AVD :

Basics : nom (par exemple HP-AVDHybrid-Lab), région du metadata (dans mon cas Europe), type Pooled ou Personal selon votre besoin, et validation environment: Yes.
Virtual machines : choisir « No, I’ll add VMs later ». Les VMs seront ajoutées via l’enrôlement Arc + extension AVD, pas par le wizard Azure.
Workspace : créez-en un nouveau (par exemple WS-AVDHybrid-Lab) ou attachez-en un existant.
Tags et Review + create : validez.

Si cela n’est pas déjà le cas non plus, créez ensuite un application group (Desktop ou RemoteApp) et liez-le au workspace. C’est ce qui sera publié à l’utilisateur :

Étape 4 : onboarder la VM on-prem dans Azure Arc

Sur la VM on-prem, on va installer l’agent Azure Connected Machine, qui est le pont entre votre datacenter et Azure :

Dans le portail Azure, allez dans Azure Arc > Machines > Add.
Choisissez « Add a single server » (pour le lab) ou « Add multiple servers » (pour générer une clé partagée).
Renseignez la souscription, le group de ressources, la région.
Téléchargez le script d’onboarding PowerShell généré automatiquement.
Exécutez-le en administrateur sur la VM on-prem.

Le script télécharge l’agent (AzureConnectedMachineAgent.msi), l’installe, puis lance azcmagent connect avec les paramètres de votre tenant.

Au bout de 2 à 5 minutes, la VM apparaît dans Azure Arc > Machines avec un statut Connected.

Attention : la VM doit être déjà jointe à votre identité cible (Entra Join OU jointure de domaine) avant l’enrôlement Arc. Si vous changez de modèle d’identité après coup, il faut désinstaller l’agent Arc et tout recommencer. Ne sautez pas cette étape.

Étape 5 : installer l’extension AVD Azure Arc et enregistrer le session host

C’est ici que les deux mondes se rejoignent, et c’est l’étape qui m’a le plus surpris. Contrairement à ce qu’on pourrait croire, l’enregistrement du session host hybride ne se fait pas via le bouton « + Add » du host pool dans le portail.

Il faut exécuter manuellement un script PowerShell, qui va poser l’extension Microsoft.AzureVirtualDesktop.CloudDeviceExtension sur le compte Arc de la machine. C’est cette extension et non l’agent AVD classique qui réalise l’enregistrement.

Pré-requis : il faut avoir installé soit l’extension Azure CLI desktopvirtualization, soit le module PowerShell Az.DesktopVirtualization. Microsoft documente le détail dans Use the Azure CLI and Azure PowerShell with Azure Virtual Desktop. Personnellement, j’ai utilisé PowerShell, donc voici la séquence que j’ai jouée.

D’abord, installez les modules suivants :

Install-Module -Name Az.DesktopVirtualization
Install-Module -Name Az.ConnectedMachine

Ensuite, connectez-vous à Azure et basculer explicitement sur la bonne souscription :

Connect-AzAccount
Set-AzContext -Subscription '<SubscriptionId>'

Attention : si vous oubliez le Set-AzContext et que votre compte est rattaché à plusieurs souscriptions, le New-AzConnectedMachineExtension ira chercher la VM Arc dans la mauvaise souscription et vous tombera sur une erreur « machine not found » très peu parlante. Toujours vérifier avec Get-AzContext avant d’enchaîner.

Générez une clé d’enregistrement du pool d’hôtes AVD via ce script PowerShell :

$HostPoolRG = "AVD_HostPool_RG"
$HostPoolName = "avd-hybrid-hp3"

$expiresUtc = (Get-Date).ToUniversalTime().AddHours(24).ToString("yyyy-MM-ddTHH:mm:ss.fffffffZ")
$regInfo    = New-AzWvdRegistrationInfo -ResourceGroupName $HostPoolRG -HostPoolName $HostPoolName -ExpirationTime $expiresUtc
$token      = $regInfo.Token

Enfin, lancez l’extension AVD sur la machine Arc :

# Settings
$settings          = @{ isCloudDevice = $false }
$protectedSettings = @{ registrationToken = $token }
$ResourceGroupName = "Arc_Servers_RG"
$MachineName = "WIN-8C8AQIS3DUL"
$Region = "westeurope"

# Install extension
New-AzConnectedMachineExtension `
    -Name 'Microsoft.AzureVirtualDesktop.CloudDeviceExtension' `
    -ResourceGroupName $ResourceGroupName `
    -MachineName $MachineName `
    -Location $Region `
    -Publisher 'Microsoft.AzureVirtualDesktop' `
    -ExtensionType 'CloudDeviceExtension' `
    -Setting $settings `
    -ProtectedSetting $protectedSettings

Quelques précisions utiles :

$token = la registration key générée a une durée de vie limitée (max 27 jours), donc générez-la juste avant de jouer le script
ResourceGroupName et MachineName = ceux de la ressource Arc dans Azure (pas le hostname Windows brut, mais le nom sous lequel la VM apparaît dans Azure Arc > Machines)
Location = la région Azure du resource group de la machine Arc (francecentral, westeurope, etc.), pas la « localisation physique » de votre datacenter
isCloudDevice = $false est essentiel : c’est ce flag qui dit à l’extension qu’on est en mode hybride, et pas sur une VM Azure native
La registration key passe en protectedSettings, elle n’apparaîtra donc pas en clair dans la définition de l’extension

L’extension met 3 à 5 minutes à se déployer :

En coulisses, elle installe les composants AVD nécessaires (équivalent de l’agent et du bootloader sur les VMs Azure natives) et enregistre la machine auprès du host pool grâce au token.

Au bout de quelques minutes, la VM apparaît dans la liste Session hosts du host pool, avec un statut Available. Du point de vue d’AVD, c’est une VM « comme les autres » et c’est tout l’intérêt de la mécanique d’Azure Arc.

Comme pour les machines AVD hébergées dans Azure, des contrôles réguliers sont appliquées afin de vérifier leur disponibilité :

Un échec dans les contrôles AVD rendra la machine indisponible pour recevoir de nouvelles sessions utilisateurs :

Étape 6 : assigner les utilisateurs AVD

Dernière ligne droite :

Ouvrez votre application group (Desktop ou RemoteApp).
Allez dans Assignments et ajoutez les utilisateurs ou groupes Microsoft Entra qui doivent pouvoir se connecter.

Étape 7 : test de connexion AVD

Côté utilisateur : ouvrez la Windows App (web ou client lourd) et connectez-vous avec le compte Entra ID assigné.
Le desktop publié par votre validation host pool hybride apparaît. Cliquez, c’est parti.

Et voilà : vous êtes connecté à un Windows qui tourne chez vous, mais piloté par AVD dans le cloud. Première fois que je l’ai vu marcher, ça m’a clairement fait sourire 😅

Cas n°1 : Hyper-V + Windows Server domain-joined

Premier cas testé dans mon lab : une VM Windows Server 2022 qui tourne sur un nœud Hyper-V standalone, jointe à mon AD on-prem (lui-même synchronisé vers Entra ID via Microsoft Entra Connect).

OS : Windows Server 2022 Standard
Hyperviseur : Hyper-V (Windows Server 2022)
Identité : jointure de domaine AD on-prem + sync Entra Connect
Licence : Windows Server + RDS CAL

Déroulé : enrôlement Arc nickel en 3 minutes, extension AVD posée en 5 minutes, session host visible Available dans le host pool. Connexion via la Windows App avec un user du domaine sync vers Entra : OK, RDP qui négocie en 2 secondes, le bureau s’affiche. Aucun ajustement particulier nécessaire. C’est le scénario le plus « facile » car on retrouve une cinématique classique RDS, juste branchée sur AVD.

Mon retour : c’est le scénario à privilégier pour migrer un parc RDS existant. Vous gardez votre AD, vos GPO, vos profils, votre serveur de fichiers SMB, et vous échangez juste votre broker / gateway / web access RDS contre AVD. Le gain est majeur : vous récupérez la Windows App, FSLogix moderne, l’intégration Entra ID, les Insights, sans toucher à votre infra serveur.

Cas n°2 : Hyper-V + Windows 11 mono-session Entra-joined

Deuxième cas, plus moderne et plus zéro-trust : une VM Windows 11 Enterprise mono-session qui tourne aussi sur Hyper-V, mais cette fois sans aucune jointure AD, uniquement Microsoft Entra Join.

OS : Windows 11 Enterprise 24H2 (mono-session)
Hyperviseur : Hyper-V
Identité : Microsoft Entra Join pur (pas d’AD)
Licence : Microsoft 365 Business Premium

Déroulé : avant tout, j’ai pris soin de faire l’Entra Join AVANT l’enrôlement Arc (via Settings > Accounts > Access work or school). Une fois la VM jointe au tenant, l’agent Arc s’installe normalement, l’extension AVD se pose, et le session host apparaît dans le host pool. Connexion via la Windows App avec un user Entra : OK, single sign-on transparent grâce à Entra Join.

Mon retour : c’est le scénario qui me plaît le plus pour des nouveaux projets. Pas de DC à exposer au réseau de l’hyperviseur, pas de Kerberos, pas de GPO – juste Entra ID, les policies Intune, et c’est tout. Pour des cabinets, des équipes projet, des labs, ou tout ce qui n’a pas besoin de Kerberos vers du legacy, c’est la voie royale. Pour rappel : Windows 11 multi-session reste interdit en hybride, donc pour cette population, c’est mono-session ou rien.

Cas n°3 : VMware vSphere + Windows Server

Troisième cas, et celui qui intéressera beaucoup d’entreprises encore très VMware-centric : une VM Windows Server 2025 sur VMware vSphere 8, jointe au domaine.

OS : Windows Server 2025 Standard
Hyperviseur : VMware vSphere 8 (ESXi 8.0 U2)
Identité : jointure de domaine AD on-prem
Licence : Windows Server + RDS CAL

Déroulé : identique au cas n°1, à 100 %. C’est exactement ça qui est bluffant. Du point de vue d’Azure Arc et d’AVD, qu’il y ait du Hyper-V ou du vSphere en dessous ne change strictement rien. Tant que l’agent Connected Machine s’installe et que la VM peut sortir en TCP 443, c’est jeu. J’ai posé l’agent Arc, lancé l’extension AVD, le session host est apparu en Available, et un utilisateur du domaine s’est connecté via la Windows App sans broncher.

Mon retour : c’est le cas le plus politique. Pour beaucoup de DSI, « passer chez Microsoft » voulait jusqu’ici dire « abandonner VMware ». AVD Hybrid permet exactement l’inverse : garder vSphere, ne pas refaire toute son infra, et bénéficier quand même du control plane AVD moderne. Pour les organisations qui ont investi dans vSphere récemment (et il y en a beaucoup, surtout après les bouleversements de licensing VMware), c’est un message fort de Microsoft : pas besoin de tout casser pour profiter d’AVD.

Le résumé visuel de mes trois cas :

Cas	Hyperviseur	OS	Identité	Résultat
1	Hyper-V	Windows Server 2022	AD domain-join	OK – idéal pour reprise RDS
2	Hyper-V	Windows 11 mono-session	Entra Join pur	OK – idéal pour green-field zéro-trust
3	VMware vSphere 8	Windows Server 2025	AD domain-join	OK – idéal pour parcs vSphere existants

Et la conclusion qui me semble importante : les trois cas suivent rigoureusement la même procédure. La doc Microsoft est tenue à la lettre, les scripts d’onboarding fonctionnent à l’identique, l’extension AVD se pose pareil. Aucune divergence d’OS ou d’hyperviseur n’a nécessité de bricolage particulier. C’est rare et c’est notable.

Les limitations et pièges à connaître

Parce qu’on est en Public Preview, il y a quelques verrues à garder en tête :

Limitation	Impact
Validation host pool obligatoire	Tout passage en prod nécessitera un redéploiement à la GA
Windows 11 multi-session non supporté hors Azure	Multi-utilisateur obligatoire = Windows Server
Auto-Scale absent	Provisioning manuel ou via votre orchestrateur d’hyperviseur
Start VM on Connect absent	Les session hosts doivent être déjà allumés côté hyperviseur
Power management Azure portal absent	Le start/stop se fait dans votre console d’hyperviseur, pas Azure
Session Host Configuration absent	Pas de « build automatique » du session host depuis le portail
Identité à fixer AVANT Arc	Changer d’identité après onboarding = désinstaller / réinstaller
Pas de date de GA annoncée	À tester en pilote, pas à passer en prod critique

Et comme toujours avec les previews Microsoft, la feature peut encore évoluer avant la GA (interface, intégrations supplémentaires, prise en charge du multi-session, modèle de licence Windows Cloud Hybrid). À surveiller de près.

Conclusion

C’est clairement l’une des évolutions que beaucoup de monde attendait, et pas juste les fans de la marque AVD (comme moi 😅). AVD Hybrid règle un vrai point bloquant : pour faire du AVD ailleurs que dans Azure, il fallait jusqu’ici passer par Azure Local et son hardware certifié, ce qui excluait de fait toutes les entreprises encore en VMware ou Nutanix. Avec cette préversion, Microsoft signe un geste d’ouverture rare : votre hyperviseur, peu importe lequel, peut héberger des session hosts AVD pilotés par Azure Arc.

Ce qui me plaît particulièrement : la cohérence de la procédure entre les trois cas que j’ai testés (Hyper-V Server domain-joined, Hyper-V Windows 11 Entra-joined, VMware vSphere domain-joined), la simplicité du branchement via Azure Arc (les admins qui pratiquent déjà Arc sur du Defender for Cloud ou de l’Update Manager seront en territoire connu), et le fait qu’on retrouve l’écosystème AVD complet (Windows App, Entra ID, FSLogix, Insights) plutôt qu’une version dégradée.

Ce qui mérite vigilance : le statut Public Preview qui impose des validation host pools, l’absence d’Auto-Scale qui peut bloquer pour les gros parcs, l’interdiction du multi-session hors Azure qui force à repenser certains designs, et le flou sur la licence Windows Cloud Hybrid qui arrivera à la GA. Je l’intègre dès maintenant dans mes projets PoC, mais avec un pilote propre avant toute généralisation.

En tout cas, si vous avez du Hyper-V, du VMware ou du Nutanix qui tourne en datacenter, foncez tester : Azure portal > Azure Virtual Desktop > Host pools > Create, cochez Validation environment: Yes, puis enrôlez vos VMs via Azure Arc et posez l’extension AVD.

La documentation officielle est claire et la procédure marche du premier coup. Et dites-moi dans les commentaires ce que vous en pensez, surtout si vous avez essayé sur un hyperviseur que je n’ai pas couvert (Proxmox ? KVM ? Hyper-V Azure Local ?), je suis curieux de vos retours !

Windows 365 avec Autopilot

Pendant longtemps, on provisionnait un Cloud PC, l’utilisateur se connectait… et il attendait. Il attendait que Intune pousse ses apps, que les scripts PowerShell s’exécutent, que les policies s’appliquent. Résultat : une première connexion bancale, des tickets help desk en pagaille et une image un peu décevante de la solution. Microsoft vient enfin de régler ça avec la Device Preparation Policy (ou DPP pour les intimes) étendue à Windows 365 Enterprise, disponible en Public Preview. Et franchement, ça change vraiment la donne.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

Quelle est la nouveauté ?

Comme annoncé en introduction, Microsoft étend en préversion publique l’Autopilot Device Preparation Policy (DPP) à Windows 365. L’idée est simple : vous définissez en amont les applications et les scripts qui doivent être installés sur le Cloud PC avant que l’utilisateur puisse s’y connecter. Tant que tout n’est pas prêt, le Cloud PC reste en statut Preparing et l’utilisateur est poliment mis en attente.

Pour rappel, un précédent article avait déjà écrit sur DPP et parlant de ce que l’on appelle aussi Autopilot v2. Attention, ce terme est trompeur car Autopilot v1 est à ce jour toujours en vigueur chez Microsoft.

C’est un vrai changement de philosophie par rapport à ce qu’on connaissait : historiquement, sur Windows 365, on provisionnait le Cloud PC, on laissait l’utilisateur se connecter, et Intune rattrapait son retard en arrière-plan. Forcément, entre le moment où l’utilisateur ouvrait sa session et celui où Outlook finissait enfin d’être installé, il y avait un trou dans la raquette qui faisait mauvaise impression.

Avec la DPP, ce trou disparaît : la documentation Microsoft Learn confirme que le provisioning Windows 365 ne se termine qu’une fois les apps et scripts installés (ou que le timeout soit atteint).

Est-ce la même chose que l’Autopilot DPP pour les postes physiques ?

C’est le même moteur, mais utilisé différemment. Pour un poste physique, l’Autopilot DPP s’exécute pendant l’OOBE de Windows, juste après le premier boot. Pour un Cloud PC, il n’y a pas d’OOBE côté utilisateur : la machine est provisionnée dans Azure, et la DPP s’exécute pendant cette phase de provisioning, transparente pour l’utilisateur.

Autrement dit :

Pas besoin de hardware hash (forcément, il n’y a pas de hardware 😅)
Pas d’Enrollment Status Page côté client
On utilise le mode Automatic (Preview) de la DPP, pas le mode user-driven
La DPP se « branche » sur la Provisioning Policy Windows 365 existante

Si vous avez déjà lu mes articles sur l’Autopilot DPP pour postes physiques, vous retrouverez les concepts (groupe dynamique interdit, groupe assigné obligatoire, service principal owner, 10 apps max, 10 scripts max). Seule la « sortie » change : au lieu d’un laptop qui attend sur l’OOBE, c’est un Cloud PC qui reste en Preparing.

J’ai Windows 365 Business, est-ce que j’y ai accès ?

Non. La fonctionnalité est destinée à Windows 365 Enterprise, ce qui est logique puisqu’elle s’appuie sur Intune et sur les Provisioning Policies. Windows 365 Business, qui ne s’intègre pas à Intune, n’est pas concerné.

Si vous êtes en Business et que vous voulez ce niveau d’industrialisation, c’est le bon moment pour envisager une migration vers l’offre Enterprise.

Quels sont les prérequis à respecter ?

Avant de se lancer, il faut cocher quelques cases. Microsoft liste les prérequis officiels, et je les résume ici :

Prérequis	Détail
Licence	Windows 365 Enterprise + Intune
Jointure	Microsoft Entra Join (ou Hybrid Entra Join)
Groupe Entra	Groupe assigné (pas dynamique !)
Service principal	Intune Provisioning Client défini comme Owner du groupe
Rôle admin	Intune Administrator ou équivalent
Apps / scripts	Assignés en Required au même groupe Entra

Le piège classique : oublier d’assigner les apps au groupe en « Required ». Si l’app est uniquement tracée par la DPP mais pas assignée au groupe, Intune ne la pousse jamais et la DPP boucle jusqu’au timeout. Croyez-en un MVP qui s’est fait avoir 🙃.

C’est quoi ce « Intune Provisioning Client » ?

C’est le service principal (dans certains tenants il s’appelle aussi Intune Autopilot ConfidentialClient) qui a le droit d’ajouter des devices au groupe Entra ID lié à votre DPP. Sans lui en Owner du groupe, la DPP ne peut rien faire : les Cloud PCs provisionnés ne sont jamais ajoutés au groupe, et donc les apps ne sont jamais poussées.

Si vous ne le trouvez pas par son nom dans Entra, cherchez-le par App ID :

f1346770-5b25-470b-88bd-d5744ab7952c

Ce GUID est documenté noir sur blanc par Microsoft dans les prérequis Autopilot DPP :

Combien d’apps et de scripts peut-on pousser ?

La limite est stricte : 25 applications et 10 scripts PowerShell. Pas plus.

Et ces 10 applications, ce sont celles qui bloquent la mise à disposition du Cloud PC. Autrement dit, il faut les choisir avec soin : votre Office, votre client VPN, votre agent EDR, éventuellement votre Teams… Les petites apps « confort » (readers PDF gratuits, utilitaires divers) peuvent parfaitement être déployées en parallèle via Intune, sans bloquer le provisioning.

Mon conseil : ne mettez dans la DPP que ce qui est réellement indispensable pour que l’utilisateur puisse travailler à la première connexion. Chaque app ajoutée allonge le temps de provisioning perçu. On ne fait pas un gold master dans la DPP.

Et si le timeout est dépassé ?

C’est vous qui décidez du comportement, et c’est paramétré directement sur la Provisioning Policy Windows 365, onglet Configuration :

Minutes allowed before device preparation fails : le temps au bout duquel on considère que ça a échoué.
Prevent users from connection to Cloud PC upon installation failure or time-out : la fameuse case à cocher.

Deux scénarios selon que la case est cochée ou non :

Case cochée ?	Statut du Cloud PC	L’utilisateur peut se connecter ?
Oui	Failed	Non – impossible de se connecter
Non	Provisioned with warnings	Oui – mais certaines apps peuvent manquer

Pour un environnement sensible (santé, finance, production industrielle), je recommande la case cochée : mieux vaut un Cloud PC refusé qu’un Cloud PC sans antivirus.

Est-ce compatible avec Hybrid Entra Join ?

Oui. Microsoft le précise explicitement : Windows 365 supporte Entra Join et Hybrid Entra Join lors du provisioning, et la DPP est compatible avec les deux modes :

Windows 365 prend en charge la jointure Entra et la jointure Entra hybride lors de l’approvisionnement. La préparation de l’appareil peut être utilisée dans les stratégies d’approvisionnement avec ces fonctionnalités activées.

Microsoft Learn

Pour mémoire, mon conseil reste le même que pour les postes physiques : privilégiez toujours l’Entra Join pur quand vous le pouvez. Sur Cloud PC, il n’y a objectivement aucune bonne raison de rester en Hybrid sauf contrainte d’authentification Kerberos sur des serveurs de fichiers on-prem.

Peut-on publier des apps Intune comme Cloud Apps via DPP ?

Et voilà la bonne surprise du package ! Microsoft a annoncé en parallèle que l’Autopilot DPP peut désormais servir à publier des applications Intune comme Windows 365 Cloud Apps. En gros : une app installée via DPP peut être exposée à l’utilisateur non pas comme un raccourci sur le bureau du Cloud PC, mais comme une Cloud App dédiée dans la Windows App.

Pourquoi c’est intéressant ? Parce que ça permet, par exemple :

De publier SAP ou un ERP maison directement comme Cloud App, sans passer par un full desktop
De capitaliser sur les Win32 apps déjà packagées dans Intune
De se rapprocher d’une logique type « RemoteApp » à la AVD, mais pilotée depuis Intune

C’est encore en Public Preview pour toutes les licences Windows 365, mais c’est clairement un signal : Microsoft veut transformer la DPP en point central de packaging pour Windows 365, qu’il s’agisse de full desktop ou de Cloud Apps.

La bonne nouvelle est que Microsoft a même publié un pas à pas sur le Microsoft Learn, juste ici. Et enfin, comme toujours, je vous propose dans la suite de cet article d’effectuer ensemble un pas à pas avec des copies d’écran.

Étape 0 : rappel des prérequis

Avant tout test, il est nécessaire de disposer d’une licence Windows 365, Entreprise ou Frontline, assignée à votre utilisateur de test.

La copie d’écran ci-dessous du portail Intune nous montre deux utilisateurs disposant de licences Windows 365, mais dont les Cloud PC n’ont pas encore été provisionnés :

Étape 1 : créer le groupe Entra ID dédié

On commence par créer un groupe Entra ID qui va servir de « réceptacle » pour les Cloud PCs provisionnés. Important : type d’appartenance Assigné (Microsoft ne supporte PAS les groupes dynamiques ici).

Ouvrez le portail Microsoft Entra.
Allez dans Groups > All groups > New group.
Type : Security.
Nom : quelque chose de parlant, par exemple SG-W365-DPP-Finance.
Membership type : Assigned.
Laissez le groupe vide, on n’a rien à ajouter manuellement : la DPP s’en chargera.

Étape 2 : attribuer le service principal à ce groupe

C’est l’étape que tout le monde oublie. Sans ça, la magie n’opère pas. Il faut que l’on donne à Intune les droits de rajouter des membres au groupe de machines.

Ouvrez le groupe que vous venez de créer.
Allez dans l’onglet Owners > Add owners.
Dans la recherche, tapez Intune Provisioning Client ou collez directement l’App ID f1346770-5b25-470b-88bd-d5744ab7952c.
Sélectionnez-le et validez.

Étape 3 : créer la Device Preparation Policy

On bascule maintenant dans le centre d’administration Intune pour créer la DPP :

Ouvrez le Microsoft Intune admin center.
Allez dans Devices > Windows > Enrollment > Device preparation policies.
Cliquez sur Create, puis sélectionnez Automatic (Preview) :

Basics : donnez un nom clair (par exemple DPP – Windows 365 Finance) et une description.
Device group : sélectionnez le groupe créé à l’étape 1.
Configuration settings : ajoutez jusqu’à 25 applications et jusqu’à 10 scripts. Les apps doivent être en system context pour être disponibles pour tous les utilisateurs :

Scope tags : par défaut, sauf besoin RBAC spécifique.
Review + create : validez :

Retournez puis vérifiez bien que votre DPP est correctement configurée :

Petit rappel important : les apps et scripts ajoutés ici doivent aussi être assignés au même groupe Entra en « Required ». Sinon Intune ne les déploie pas, et la DPP attend dans le vide :

Étape 4 : lier la DPP à la Provisioning Policy Windows 365

C’est là que les deux mondes se rencontrent.

Dans Intune, allez dans Devices > Windows 365 > Provisioning policies.
Créez une nouvelle Provisioning Policy ou éditez une existante :

Sur l’onglet Configuration, descendez jusqu’à la section Autopilot device preparation policy, puis sélectionnez la DPP créée à l’étape 3 :

Renseignez Minutes allowed before device preparation fails (je conseille entre 60 et 90 minutes selon la taille des packages).
Cochez ou non Prevent users from connection to Cloud PC upon installation failure or time-out selon votre niveau d’exigence.
Complétez le reste de la Provisioning Policy comme d’habitude (image, réseau, assignments) et validez.

Attention : si vous modifiez une Provisioning Policy existante pour y ajouter la DPP, les Cloud PCs déjà provisionnés ne sont PAS re-préparés automatiquement. Il faut déclencher un reprovision pour qu’ils passent par la DPP.

J’ai également fait une seconde police de provisionnement DPP afin de tester le mix entre Autopilot et les Cloud Apps Frontline :

Le test : on déroule un provisioning complet

Passons à la pratique, parce qu’une doc sans test, c’est juste de la théorie. Dans mon lab, j’ai ajouté dans la DPP et j’ai suivi le déploiement :

Adobe Acrobat Reader
Google Chrome
Un script PowerShell qui modifie la configuration du firewall

Mais j’ai aussi mis en obligatoire d’autres applications installées automatiquement par la suite :

Microsoft 365 Apps (Win32 package)
Company Portal

Voilà le déroulé observé :

J’assigne la Provisioning Policy à mse utilisateurs de test. Les Cloud PCs apparaissent en Provisioning :

Au bout de quelques minutes, le statut bascule en Preparing. C’est la DPP qui prend le relais.

Le Cloud PC est rajouté au groupe géré par Intune :

En cliquant sur Preparing, Intune me redirige vers le rapport Windows Autopilot device preparation deployment status.

Je vois progressivement mes apps passer de Pending à Installed, puis le script en Success.

Pareil pour le script :

Le Cloud PC passe enfin en Provisioned.

L’utilisateur se connecte via windows.cloud.microsoft ou via l’application Windows App :

Acrobat bien installé, Chrome et les autres outils Office se sont installés tout seul par la suite :

Les applications publiées via la seconde DPP s’affichent également dans l’onglet dédié :

Enfin, les règle de Firewall ont bien été modifiées par le script :

Et c’est exactement le genre de « petite fonction sympa » qui change la vie : le script PowerShell passé en system context permet de faire tout ce qu’on veut – clés registre, certificats, création d’utilisateurs locaux, configuration OneDrive Known Folders, mise en place d’un wallpaper corporate… Tout ça sans que l’utilisateur n’ait à patienter devant un bureau à moitié configuré.

Monitorer le déploiement de la DPP

Le suivi se fait à deux endroits complémentaires :

Emplacement	Ce qu’on y voit
Devices > Windows 365 > All Cloud PCs	Statut global : Provisioning, Preparing, Provisioned, Failed, Provisioned with warnings

Il y est même possible de relancer le provisionnement du PC depuis le tout début :

Emplacement	Ce qu’on y voit
Devices > Enrollment > Monitor > Windows Autopilot device preparation deployment status	Détail par device : liste des apps et scripts, statut individuel de chaque étape, codes d’erreur

En cliquant sur un device dans le second écran, vous avez le détail ligne par ligne : chaque app avec son statut (Installed / Failed / In Progress), chaque script avec son code de sortie. C’est ce qu’il vous faut pour diagnostiquer quand un provisioning finit en Provisioned with warnings.

Et bonne nouvelle : cette vue s’articule parfaitement avec la nouvelle plateforme de monitoring Windows 365 dont j’ai parlé dans mon article précédent sur le monitoring Windows 365. Vous y gagnez une vraie vue end-to-end de la santé de vos Cloud PCs, du provisioning jusqu’à l’expérience utilisateur en run.

Les limitations et pièges à connaître

Parce que ça reste une Public Preview, il y a quelques verrues à garder en tête :

Limitation	Impact
Groupes dynamiques non supportés	Il faut impérativement un groupe Assigned
25 apps / 10 scripts max	Limite dure, à arbitrer dès la conception
Apps non assignées = skip silencieux	Les apps doivent aussi être en « Required » sur le groupe
Pas de re-provisioning automatique	Ajouter une DPP sur une Provisioning Policy existante nécessite un reprovision manuel
Pas de GA annoncée	Configuration à tester en pilote, pas à passer en prod critique à l’aveugle
Timeout trop bas = faux négatifs	Un package Win32 volumineux peut dépasser 30 min, calibrez bien

Et comme toujours avec les previews Microsoft, la feature peut encore évoluer avant la GA (interface, nombre d’apps max, intégrations supplémentaires). À surveiller.

Conclusion

C’est clairement l’une des évolutions que j’attendais le plus pour Windows 365 Enterprise. Pas un gadget, pas un petit ajustement cosmétique : une vraie brique manquante qui arrive enfin. Jusqu’ici, on faisait du provisioning Windows 365 en croisant les doigts pour que les apps soient là au bon moment. Avec la DPP, on passe d’un modèle « best effort » à un modèle déterministe.

Ce qui me plaît particulièrement : la cohérence avec ce que les admins Intune connaissent déjà sur les postes physiques (même console, même logique de groupe, même service principal), la simplicité du branchement sur la Provisioning Policy (une case à cocher, une valeur de timeout), et la promesse tenue côté Cloud Apps qui positionne la DPP comme la pierre angulaire du packaging Windows 365 de demain.

Ce qui mérite vigilance : la limite des 25 apps / 10 scripts qui va obliger à faire des choix, le piège de l’assignment « Required » obligatoire, et le fait que la feature soit encore en Public Preview sans date de GA annoncée. Je l’intègre dès maintenant dans mes projets de déploiement, mais avec un pilote avant de la généraliser à des populations critiques.

En tout cas, si vous avez Windows 365 Enterprise, foncez tester : Devices > Windows > Enrollment > Device preparation policies, puis liez-la à votre Provisioning Policy. Et dites-moi dans les commentaires ce que vous en pensez, surtout si vous avez trouvé des cas tordus que j’aurais oubliés !

Monitorez Windows 365

Ah, le monitoring Windows 365. Pendant longtemps, c’était la croix et la bannière : exporter des données, bricoler des dashboards dans Excel ou Power BI, croiser les doigts pour retrouver la bonne info au bon moment… Doug Coombs de Microsoft vient d’annoncer une refonte complète de cette expérience, disponible dès maintenant en Public Preview dans le centre d’administration Intune. Et franchement, ça change vraiment la donne.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

Quelle est la nouveauté ?

Comme annoncé en introduction, Microsoft vient de lancer en préversion une toute nouvelle plateforme de monitoring et reporting pour Windows 365, directement intégrée dans le centre d’administration Intune.

Elle regroupe dans une seule interface trois onglets (Connection health, User and devices, Configuration monitoring) avec des dashboards interactifs, de la détection d’anomalies, et des tables de données exploitables sans export.

L’objectif est d’en finir avec les exports CSV et les dashboards dans Power BI.

Est-ce que cela remplace les anciens rapports Windows 365 ?

Non. Les anciens rapports (Reports > Cloud PC overview) restent disponibles en parallèle. La nouvelle plateforme vient s’y ajouter, elle ne les supprime pas.

La copie d’écran de la page web des rapports Intune vous montre la continuité des deux :

La copie d’écran ci-dessous vous montre que les objectifs des deux rapports sont différents :

Le rapport de gauche, en préversion, apporte une vue plus détaillée et plus technique du monitoring des Cloud PCs, avec des métriques d’environnement, de configuration et des données plus granulaires pour l’analyse des problèmes.
Le rapport de droite est plus orienté pilotage global : il résume rapidement l’état du parc, les alertes et les indicateurs clés, donc il est plus simple pour avoir une vision synthétique et exploitable au quotidien.

Le nouveau rapport offre une valeur ajoutée majeure en consolidant des données techniques détaillées sur la santé, les performances et les configurations des Cloud PCs dans des dashboards intégrés.

Il inclut des tendances comme le nombre actif de connexions (graphique en ligne et barre visible), filtrables par environnement et temps, pour un diagnostic proactif des problèmes.

J’ai Windows 365 Business, est-ce que j’y ai accès ?

Non, ou du moins pas pour l’instant. La plateforme est explicitement destinée aux clients Windows 365 Enterprise. Windows 365 Business n’est pas mentionné dans l’annonce ni dans la documentation officielle.

Faut-il activer quelque chose pour accéder à la preview ?

Non, aucune inscription séparée n’est nécessaire. Si vous avez Windows 365 Enterprise et l’accès au centre d’administration Intune, vous pouvez y accéder directement via Reports > Cloud PC monitoring (preview).

Attention, malgré l’annonce de la préversion publique par Microsoft, j’ai constaté encore quelques tenants où le menu de se rapport n’apparaît pas encore. Et l’URL directe du rapport n’affiche pas d’informations :

Les données sont-elles en temps réel ?

Presque, mais pas tout à fait. Les données de connexion ont un délai allant jusqu’à 15 minutes (granularité 2 min), et les données de santé des Cloud PCs jusqu’à 30 minutes. Il n’y a pas de rafraîchissement automatique : pensez à recharger la page manuellement.

Les pages de surveillance ne s’actualisent pas automatiquement. Les informations affichées reflètent l’heure à laquelle la page a été chargée ou actualisée pour la dernière fois.

Les données de connexion peuvent être retardées de 15 minutes au maximum et sont fournies à une granularité de 2 minutes.

Les données d’intégrité des PC cloud peuvent être retardées jusqu’à 30 minutes et sont fournies à une granularité d’environ 30 minutes.

Microsoft Learn

Qu’est-ce que le Round Trip Time (RTT) mesure exactement ?

Il s’agit de la médiane (P50) du temps aller-retour pour toutes les connexions Cloud PC sur la période sélectionnée. Plus il est élevé, plus l’expérience utilisateur sera dégradée (lag, lenteur, délai clavier).

Qu’est-ce que le MTTF (Mean Time to Failure) ?

C’est la durée moyenne pendant laquelle un Cloud PC fonctionne normalement avant de rencontrer une panne. Un MTTF en baisse est un signal préoccupant : les pannes deviennent plus fréquentes.

La plateforme est-elle compatible avec Frontline Shared ?

Oui. L’onglet User and devices supporte les relations « un appareil, plusieurs utilisateurs », ce qui correspond exactement aux Cloud PCs Frontline Shared où plusieurs utilisateurs se connectent au même appareil au fil du temps.

Quels sont les codes d’erreur les plus courants à connaître ?

Microsoft documente 13 codes d’erreur dans la plateforme. Les plus fréquents : ClientNetworkLost (réseau utilisateur coupé), ConnectionBroken (session interrompue), ConnectionFailedClientDisconnect (client fermé par l’utilisateur), OutOfMemory (ressources insuffisantes sur le Cloud PC).

La liste complète est disponible dans le guide de troubleshooting Microsoft et juste en dessous :

Code d’erreur	Signification typique
ClientNetworkLost	La connexion réseau de l’utilisateur a été supprimée
ClientNetworkUnavailable	Réseau de l’utilisateur non disponible
ConnectionBroken	La connexion de session a été interrompue
ConnectionBrokenMissedHeartbeatThresholdExceeded	Session perdue en raison de pulsations manquées (souvent une perte réseau)
ConnectionFailedClientDisconnect	Le client a été fermé ou déconnecté par l’utilisateur
AutoreconnectFailedBecauseSessionEnded	Tentative de reconnexion automatique, mais la session était déjà terminée
ShortpathNetworkDrop / ShortpathTransportNetworkDrop	Chutes réseau sur le transport shortpath
SocketConnectionTimedOut	Délai d’expiration de la connexion de socket réseau
TransportClosedUnexpectedly	Couche de transport fermée sans avertissement
ConnectionFailedReverseConnectStackTimeout WaitingForReply	Délai d’expiration de la connexion côté service
ConnectionInitiationSequenceTimeout	Le délai d’initiation de la connexion a expiré
FailedToAcquireAadNonce	Problème d’acquisition de jeton d’authentification
OutOfMemory	Épuisement des ressources sur le PC cloud

Pourquoi ce changement était nécessaire ?

Jusqu’à présent, la supervision d’un environnement Windows 365 reposait souvent sur des bricolages. Les admins les plus aguerris exportaient des données via des APIs, construisaient leurs propres dashboards dans Power BI, et passaient un temps fou à corréler des informations éparpillées dans Intune.

« Today, many organizations resort to exporting, processing and analyzing Cloud PC data, which can increase the complexity and total cost of ownership of Windows 365. »

Doug Coombs

Ce qui arrive en Public Preview

La nouvelle plateforme de monitoring s’intègre directement dans le centre d’administration Microsoft Intune, sous Reports > Cloud PC monitoring (preview). Elle se décompose en trois onglets principaux, et chaque sélection que vous faites en haut de la page (onglet, série de données, plage de temps, filtres) se répercute immédiatement sur tous les composants en dessous.

Onglet	Pour qui ?	Cas d’usage principal
Connection health	Équipes ops	Vue d’ensemble tenant – patterns système, tendances
User and devices	Help desk	Investigation par utilisateur ou appareil
Configuration monitoring	Admins avancés	Corrélation config/performance, fin à fin

Regardez aussi la démo YouTube de Windows IT Pro pour une présentation complète :

Connection Health : la vue d’ensemble tenant

C’est LE tableau de bord qu’on attendait. Vous avez enfin une vue agrégée de la santé de toutes vos connexions Cloud PC, avec des tendances et des alertes visuelles. Selon la documentation Microsoft Learn, voici les 6 métriques clés disponibles :

Métrique	Description	Ce qu’elle révèle
Active Connection Count	Tendance du nombre de connexions actives	Charge réelle sur le tenant
Connection Failure Rate	Nombre de connexions en échec	Fiabilité globale
Cloud PC Health	% de Cloud PCs sains sur la période	Santé du parc
Round Trip Time (RTT)	Médiane (P50) du temps aller-retour	Qualité d’expérience réseau
Mean Time to Failure (MTTF)	Durée moyenne avant une panne	Stabilité et tendance de dégradation
Sign-in Time	Temps end-to-end pour ouvrir une session	Ressenti utilisateur au démarrage

Note : Détail important sur le Cloud PC Health : la vérification se fait environ toutes les 30 minutes. Si un Cloud PC tombe à 12h10, il peut encore apparaître comme « sain » jusqu’à ~12h31. À garder en tête pour l’interprétation.

User and Devices : le meilleur ami du Help Desk

Fini les allers-retours entre plusieurs écrans pour diagnostiquer le problème d’un utilisateur. Cet onglet centralise tout ce dont le support a besoin :

Recherche par UPN (email) ou par nom d’appareil
Historique des connexions, taux d’erreur, RTT et durée d’utilisation
Support des relations 1-à-plusieurs (un utilisateur = plusieurs Cloud PCs, ou un Frontline Shared = plusieurs utilisateurs)
Actions à distance directement depuis l’interface : redémarrer ou troubleshooter l’appareil concerné :

Le workflow typique : un utilisateur appelle le helpdesk. L’agent tape l’UPN dans la barre de recherche, sélectionne le Cloud PC concerné, choisit la plage de temps autour de l’incident signalé, et il voit immédiatement les erreurs, les métriques et la config de connexion. En quelques clics, là où il fallait auparavant fouiller dans 3 ou 4 écrans différents.

Configuration Monitoring : comprendre le passé pour résoudre le présent

Voilà une feature que j’attendais vraiment. La config d’un environnement Windows 365 change constamment : policies Intune, paramètres réseau, versions de clients RDP, endpoints utilisateurs… Et quand une connexion se dégrade, il faut reconstituer ce que la config était à ce moment précis.

L’onglet Configuration Monitoring propose des visuels end-to-end qui couvrent l’intégralité du chemin de connexion :

Endpoint utilisateur (côté client)
Configuration du service Windows 365
Configuration du Cloud PC lui-même

Particulièrement utile dans les environnements BYOD, où les machines clientes ne sont pas managées par Intune. On peut enfin corréler un changement de config client avec une dégradation de performance, sans export manuel.

Détection des anomalies (Outlier Detection)

La plateforme intègre une détection automatique des métriques anormales. Le système identifie lui-même les valeurs qui sortent de la norme et les met en avant pour attirer votre attention.

« Depending on how customers use these insights, some organizations may experience earlier issue identification and reduced escalation, though results will vary. »

Microsoft

Ces indicateurs s’intègrent dans une méthodologie de troubleshooting structurée :

Identifier un problème ou une anomalie
Formuler une hypothèse sur la cause
Tester l’hypothèse via les séries de données et les filtres
Isoler le problème
Résoudre en traitant les conditions identifiées

Graphiques et tables de données : fini les exports !

Chaque page dispose d’un panneau « View data » en bas de l’écran, qui expose trois tables de données exploitables directement en ligne :

Table	Contenu	Usage
Environment Metrics	Métriques agrégées par période (RTT, taux d’échec…)	Identifier les plages horaires problématiques
Connection Configuration	Configuration de chaque connexion	Trouver les traits communs aux connexions en échec
Events	Événements granulaires, checkpoints, codes d’erreur	Diagnostic précis pour admins expérimentés

Le panneau est redimensionnable, les colonnes sont personnalisables, et une recherche « contient » permet de filtrer les données sans quitter l’interface. Fini les exports CSV dans Excel.

Comment accéder à la nouvelle plateforme ?

La navigation est simple :

Connectez-vous au Microsoft Intune admin center
Dans le menu de gauche, cliquez sur Reports
Sélectionnez Cloud PC monitoring (preview)
Choisissez votre onglet : Connection health, User and devices, ou Configuration monitoring

Prérequis : vous devez avoir une licence Windows 365 Enterprise. Windows 365 Business ne semble pas supporté pour l’instant. Les anciens rapports (Reports > Cloud PC overview) restent disponibles en parallèle et ne disparaissent pas. La documentation complète est disponible ici.

Les limitations connues

Comme toute preview, cette plateforme n’est pas encore finale. Microsoft documente lui-même ses limitations :

Limitation	Impact
Pas de rafraîchissement automatique	Il faut recharger la page manuellement
Données de connexion retardées jusqu’à 15 min	Granularité de 2 minutes
Données Cloud PC Health retardées jusqu’à 30 min	Granularité ~30 minutes
Filtrage incomplet sur certaines colonnes	Quelques colonnes dans View Data ne supportent pas encore le filtre
La recherche dans View Data n’affecte pas les graphiques	Deux contextes séparés
Connection Failure Rate surestime les erreurs	Inclut toutes les erreurs, pas seulement les connexions non établies
Egress point ≠ localisation physique	Si trafic via VPN, la ville affichée = point de sortie, pas position réelle

Microsoft rappelle aussi que les features en preview peuvent changer avant la GA. Pas de date de disponibilité générale annoncée à ce jour.

Conclusion

C’est clairement une évolution majeure pour l’administration de Windows 365. Pas une amélioration incrémentale : une refonte complète de la façon dont on supervise et dépanne les Cloud PCs, directement intégrée dans Intune, sans export ni outil externe.

Ce qui me plaît particulièrement : la cohérence de l’interface (une sélection en haut cascade partout), l’onglet Configuration Monitoring qui résout un vrai problème du quotidien, et la méthodologie de troubleshooting structurée que Microsoft documente avec des scénarios concrets.

Ce qui mérite vigilance : les délais de données (15 à 30 min), l’absence de date de GA, et le rappel de Microsoft que la preview est « non finie ». À tester, mais pas à utiliser comme seul outil de monitoring critique en production tout de suite.

Enfin, vous pouvez même laisser un feedback à Microsoft via ce lien ou celui disponible sur le portail Intune :

En tout cas, si vous avez Windows 365 Enterprise, allez-y : Reports > Cloud PC monitoring (preview) dans Intune, et dites-moi ce que vous en pensez dans les commentaires !

Microsoft Copilot Cowork

Comme moi, vous faites peut-être déjà partie des premiers utilisateurs de Copilot Cowork dans votre organisation ? Fraîchement accessible pour les entreprises ayant déjà activé le mode Frontier, découvrons ensemble ce que Microsoft propose avec Copilot Cowork. Voyons si cette Wave 3 peut être perçue comme une amélioration majeure de Microsoft 365 Copilot. Je vous propose quelques exemples concrets pour démarrer du bon pied.

Saviez-vous que seulement 5% des utilisateurs de Microsoft ne dépassent pas encore la phase de test ? Pourquoi cela ? Parce que Copilot classique reste bloqué une simple assistance.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

Wave 3 Copilot – Qu’est-ce que cette révolution ?

La Wave 3 est la troisième génération majeure de Microsoft 365 Copilot, annoncée le 9 mars 2026 lors de l’événement « Frontier Transformation » :

Toute cette mécanique s’appuie sur Work IQ, la couche d’intelligence contextuelle de Microsoft 365 qui agrège les signaux issus des e-mails, réunions, conversations Teams, fichiers SharePoint et relations professionnelles de l’utilisateur.

Chaque action de Copilot est transparente, réversible et soumise aux permissions et labels de sensibilité déjà en place dans l’organisation. Dit autrement, la Wave 3 veut initier une transformation opérationnelle à l’échelle de l’entreprise en plaçant l’IA agentique au cœur de la plateforme collaborative.

informatiquenews.fr

Les 5 piliers de la Wave 3 sont donc :

Copilot devient multi-modèle : Il y avait encore quelque temps, seulement OpenAI était disponible. Maintenant, vous pouvez choisir le meilleur modèle pour la tâche à réaliser :

Modèle	Cas d’usage
Claude (Anthropic)	Analyse complexe, tâches nécessitant raisonnement
OpenAI	Tâches générales, génération de contenu

Work IQ : le cerveau contextuel apportant la couche d’intelligence introduite à Microsoft Ignite 2025. Pourquoi est-ce crucial ? Car sans contexte, pas de valeur économique réelle.

Copilot Cowork : co-développé avec Anthropic, intègre la technologie Claude Co-work dans M365 Copilot. C’est la grande nouveauté de cette wave 3 :

Ce que tu peux faire	Exemple concret
Déléguer des tâches complexes	Préparer une réunion : créer une invitation Teams + générer support présentation + résumer échanges précédents.
Tasks en arrière-plan	Tâches qui tournent minutes ou heures sans que tu attendes.
Multitâche parallèle	Soumettre plusieurs tâches qu’elles exécutent en parallèle, interférer pendant l’exécution.
Actions concrètes	Déplacer réunions, créer Excel, envoyer des e-mails, planifier du temps de focalisation.

Agents agentic natifs : dans Word, Excel, PowerPoint, Outlook L’ancien mode agent devient le fonctionnement standard de Copilot dans ces applications (déjà à présent ou dans les prochains mois) :

Application	Ce que l’agent fait (nativement)
Excel	Création de vraies formules Excel, analyse de variance, structure sur le canvas
Word	Rédaction de documents complets, insertion de formules, …
PowerPoint	Transformation contenu fade → slides engageantes (objets éditables, pas images plates)
Outlook	Planification, rédaction et envoi emails (avec revue avant envoi)

Agent 365 : gouvernance & sécurité au programme, dont la disponibilité générale est prévu le 1er mai. Ce panneau de contrôle unique pour tous vos agents (Microsoft + développeurs + IT + partenaires externes)

Qu’est-ce que Claude Cowork ?

Claude Cowork est un produit d’Anthropic lancé en janvier 2026, qui change radicalement la manière d’interagir avec l’intelligence artificielle.

Alors que Claude classique se contente de répondre à vos questions ou de générer du texte dans une fenêtre de chat, Claude Cowork est conçu pour exécuter des tâches complexes de bout en bout, en travaillant directement sur votre ordinateur et dans vos fichiers.

Vous ne lui demandez plus de vous aider à écrire, vous lui déléguez un projet entier et il l’accomplit de manière autonome, pendant que vous faites autre chose.

La transparence est un principe clé du fonctionnement de Cowork.

Quand Claude exécute une tâche, des indicateurs de progression vous montrent ce qu’il est en train de faire à chaque étape. Il expose son raisonnement et son approche, ce qui vous permet de suivre le processus et de comprendre pourquoi il prend telle ou telle décision. Vous pouvez intervenir à tout moment pour corriger la direction, ou fournir des directives supplémentaires au milieu de la tâche.

Qu’est-ce que Copilot Cowork ?

Le 9 mars dernier, Microsoft a officiellement lancé Copilot Cowork, développé en étroite collaboration avec Anthropic et propulsé par le modèle Claude. Ce n’est pas une mise à jour technique de Copilot, c’est un changement fondamental de nature.

Alors que les premières versions de Copilot restaient cantonnées à un rôle d’assistance conversationnelle, Cowork introduit une nouvelle catégorie de produit : l’agent IA capable d’accomplir des tâches complexes sur plusieurs minutes voire plusieurs heures, sans intervention humaine constante.

La différence est radicale quand on compare ce que Copilot faisait avant et ce que fait Cowork maintenant. Avec la version classique, vous posiez une question, Copilot répondait par du texte généré. Vous lui demandiez de résumer un document, il le faisait. Ou alors il rédigeait un brouillon Word selon vos directives. Mais tout restait dans le domaine conversationnel.

Copilot Cowork change cette logique :

Copilot Wave 1-2	Copilot Cowork (Wave 3)
Vous posez une question → il répond du texte	Vous donnez une mission → il exécute le travail
Résume-moi ce document	Prépare ma réunion de mardi avec Romuald
Génère un brouillon Word	Crée Word + Excel + PowerPoint + envoie un e-mail + planifie un meeting
Conversation ponctuelle	Tâches en arrière-plan pendant minutes / heure

Microsoft a choisi d’intégrer la technologie Claude d’Anthropic plutôt que d’utiliser uniquement ses propres modèles OpenAI. Les raisons sont pragmatiques. Les tests indépendants placent Claude en tête pour la planification de tâches complexes, le débogage de code et l’analyse financière.

La disponibilité de Copilot Cowork est progressive. Le programme Frontier est ouvert maintenant pour les utilisateurs qui souhaitent tester les features avant leur sortie publique. La généralisation large est attendue fin mars 2026.

Qu’est-ce que Frontier chez Microsoft ?

Frontier chez Microsoft, c’est en réalité trois choses liées à l’IA :

Programme Frontier : Un espace d’accès en avant-première pour explorer les dernières innovations IA dans Microsoft 365 avant leur disponibilité générale :
- Essayer de nouvelles expériences avec Copilot (agents expérimentaux, fonctionnalités en préversion)
- Accéder à des modèles IA avancés (comme Claude dans Copilot Chat, en plus d’OpenAI)
- Partager des commentaires pour façonner les futures fonctionnalités
Frontier Transformation : Les entreprises Frontier sont des pionnières qui intègrent l’IA agentique au cœur de leurs opérations. Les 3 traits d’une Frontier Firm sont :
- Les personnes aux centres : IA dans le flux de travail (Word, Excel, Outlook), pas outil séparé
- Tout le monde peut contribuer : Chacun crée/utilise des agents IA
- Visibilité à chaque couche : vous gouvernez, contrôlez et observez les agents.
Suite Frontier (Microsoft 365 E7) : Nouvelle de licence offre premium. Lancée le 1er mai 2026, cette suite regroupera :

Composant	Ce que ça inclut
Microsoft 365 E5	Productivité, sécurité, conformité de base
Microsoft 365 Copilot	IA générative complète (Word, Excel, PowerPoint, Outlook, Copilot Chat) + Work IQ + Copilot Studio + Agent Builder
Agent 365	Plateforme de gouvernance/sécurisation des agents IA ($15/utilisateur seul)
Microsoft Entra Suite	Gouvernance des identités, accès, sécurité réseau (SSE/ZTNA)

Comment active-t-on le mode Frontier ?

Pour y accéder, il faut que votre administrateur active Frontier dans le tenant Microsoft 365 Admin Center, puis attribue l’accès à des groupes d’utilisateurs pilotes. Vous pouvez aussi participer au programme Frontier en individuel si vous avez une licence Microsoft 365 Personal ou Famille.

Pour un compte Microsoft particulier : Ouvrez Word, Excel ou PowerPoint sur le web (https://www.office.com), allez dans les Options, recherchez les paramètres Copilot, puis activez cette option :

Pour chaque application Office, il est nécessaire de l’activer (Word, Excel, PowerPoint, … ):

Pour un compte Microsoft entreprise : Dans le cadre d’une entreprise, l’activation de Frontier est géré au niveau tenant. C’est donc l’administrateur IT de votre tenant qui doit l’activer pour que les utilisateurs puissent en profiter.

Cette option se trouve sur la page d’administration de Microsoft 365 :

Comment sait-on si Frontier est activé ?

D’un point de vue utilisateur, c’est assez simple de vérifier que Frontier a bien été activé.

Pour un compte Microsoft particulier : Rendez-vous sur la page https://m365.cloud.microsoft, afin de voir apparaître l’agent suivant :

Pour un compte Microsoft entreprise : Rendez-vous sur la page https://m365.cloud.microsoft, puis recherchez si les agents Frontier vous sont accessibles dans le catalogue :

Quelles sont les limites de Copilot Cowork ?

Nous sommes encore sur une préversion de l’outil, c’est pour cela que certaines contraintes temporaires sont encore présentes :

Limitation	Détails
Appareils mobiles	Cowork n’est pas encore disponible sur mobile. Seuls le navigateur (m365.cloud.microsoft) et applications de bureau Windows/Mac sont supportés
Voix	La fonction vocale dépend du navigateur. Tous les navigateurs ne la supportent pas
Programme nécessaire	Il faut être inscrit au programme Frontier preview pour accéder à Cowork

Mais, Microsoft ne communique pas beaucoup sur sa FAQ les limites mensuelles d’usage de Copilot Cowork dans sa documentation.

Cette absence totale de chiffre officiel dans la documentation Microsoft Learn suggère que Cowork est géré en usage illimité dans le cadre de l’abonnement Microsoft 365, mais cette absence de transparence crée des incertitudes pratiques sur les limites réelles en production.

Mais d’autres limites sont déjà documentées :

Limitation	Détails
Fichiers locaux	Cowork ne peut pas accéder ni modifier les fichiers stockés localement sur votre appareil. Il travaille uniquement avec les fichiers de OneDrive et SharePoint
Suppression de fichiers	Cowork ne peut pas supprimer de fichiers ou dossiers dans OneDrive ou SharePoint
Fichiers encryptés	Cowork ne peut pas lire les fichiers chiffrés, même si l’utilisateur y a accès
Taille des fichiers	Les fichiers joints doivent faire moins de 200 Mo

Enfin, dans le cadre de mon abonnement Microsoft 365 Famille, seul l’utilisateur principal dispose de fonctions Copilot. De plus, des limitations d’usage s’appliquent bien à ces nouvelles fonctions :

Comment puis-je tester Copilot Cowork ?

Vous êtes enfin prêts à tester Copilot Cowork ? C’est parti !

Pour cela, commencez par vous rendre sur la page web de Copilot, recherchez puis ajoutez Copilot Cowork ajouté à votre liste d’agents :

Une fois l’agent Copilot Cowork ajouté, ouvrez-le afin de constater les premières fonctionnalités :

L’écran ressemble à Copilot Work, puis que les requêtes comment elles aussi par un prompt. Des tuiles sont également visibles afin de démarrer rapidement, Microsoft vous propose quatre cas d’usage de base :

Organize my inbox pour trier vos e-mails
Organize my week pour remettre de l’ordre dans ton agenda
Prep for a meeting pour préparer un rendez-vous
Research a company pour faire une recherche sur une entreprise.

Enfin, les Tasks ou tâches, correspondent à l’historique des missions que tu as déjà lancées dans Cowork. On voit dans mon exemple deux tâches déjà marquées comme terminées.

Testons maintenant Copilot Cowork ensemble.

Première tâche – recherche d’une entreprise :

Voici l’exemple le plus simple et le plus facile, la recherche d’une entreprise :

Dès que la tâche démarre, celle-ci se crée et change de statut. Microsoft documente quatre statuts :

In progress quand Cowork travaille encore dessus
Needs user input quand il attend votre réponse pour continuer
Done quand c’est fini
Failed quand la tâche a échoué

Dans mon cas, la tâche a besoin d’une réponse pour avancer :

De façon assez logique Copilot Cowork a besoin de connaître le nom de l’entreprise pour effectuer sa recherche. Pour cela, un formulaire vous invite à lui fournir le nom :

Une fois l’information fournie, Copilot Cowork repart alors travail :

Le statut de la tâche rechange à nouveau :

Pour un meilleur suivi et une traçabilité, toutes les interactions avec l’agent sont affichées à droite de l’écran :

Cowork vous montre son plan d’action détaillé, l’avancement en temps réel, les dossiers source/destination, et les skills qu’il mobilise. On peut suivre précisément ce qu’il fait. :

Barre de progression : on y voit ici les 6 étapes planifiées par Cowork :
- Researching TD SYNNEX
- Researching TD SYNNEX financial data
- Create Word document cover sheet
- Build financial spreadsheet
- Verifying findings
- Writing the report
Output folder : le dossier où Cowork va déposer les résultats
Input folder : le dossier source avec les données d’entrée
Skills : 1 compétence active appelée Deep Research

Durant toutes les phases de travail, il nous est toujours possible de re-prompter Copilot Cowork afin de lui apporter des précisions, des contre-ordres ou des informations ou fichiers :

Sur cette autre capture, Cowork est passé de 0/6 à 4/6 : la recherche TD SYNNEX est terminée, il construit un fichier .md :

Un clic sur le fichier .md nous montre directement son contenu :

Sur cette dernière capture, Cowork a terminé toutes les étapes : recherche TD SYNNEX bouclée, Word de 3 pages et Excel 5 onglets créés dans ton OneDrive, avec synthèse détaillée des comptes, trésorerie et ratios financiers :

Tout y est très bien présenté :

L’ensemble des fichiers, générés ou utilisés, sont stockés et accessibles dans un dossier OneDrive créé spécialement pour cette conversation :

Copilot Cowork vous avertit même, au besoin, via un système de notification quand il a besoin de vous ou quand le travail est terminé :

Continuons avec une autre tâche.

Deuxième tâche – optimisation d’un planning de vacances :

Dans cette seconde démonstration, que j’ai testé dans le mode Office Agent en Frontier sur un Copilot personnel, mais que j’ai aussi réalisé sur Copilot Cowork Enterprise, j’ai pris un fichier Excel de planning vacances incorrect et mal formaté. J’ai donc demandé à Cowork de le reprendre complètement, de créer une page web interactive avec toutes les activités.

Voici le prompt utilisé pour cette tâche :

J'ai un fichier Excel de planification de vacances à Londres en mai 2026. Il est bancal : dates dans 4 formats différents, prix mélangés en £ et en €, c... J'aimerais que tu fasses les choses suivantes dans l'ordre :

Diagnostic — Analyse le fichier et liste tous les problèmes que tu détectes.
Nettoyage — Corrige tous les problèmes, standardise tous les prix en livres sterling (indique le taux de conversion utilisé en note de bas de fichier), et génère un fichier Excel propre avec 4 onglets : 
ACTIVITES (activités groupées par zone géographique, avec statut Gratuit/Payant), PLANNING (jour par jour avec horaires et transport), BUDGET (formules propres, zéro erreur) et CARTE DES ZONES (carte visuelle des quartiers de Londres avec activités et budget par zone). Page web interactive — Génère un fichier HTML autonome, sans dépendance externe, utilisable hors connexion sur téléphone le jour de la visite. Il doit contenir : une carte cliquable des 7 zones de Londres (City, South Bank, West End, Kensington, North London, East London, Excursions) avec les activités de chaque zone cochables, un planning jour par jour en accordéon, un suivi de budget avec saisie des dépenses réelles, et un onglet Tips pratiques (réservations obligatoires, transport, food). Commence par le diagnostic, attends ma validation, puis enchaîne sur le nettoyage et la page web.

Et voici le fichier Excel de départ utilisé avec ce prompt :

ACTIVITE LONDON bancal Télécharger

Voyons ce que cela donne en vidéo :

Preuve que Cowork ne se contente pas de répondre, il exécute et livre des fichiers concrets.

Troisième tâche – organisation d’un calendrier :

Shervin nous montre comment apporter des optimisations intelligentes sur son calendrier :

Quatrième tâche – Création d’un rapport d’incident :

John nous propose un exemple d’analyse de rapports d’incidents dans un dossier OneDrive générant une matrice des menaces, top 5 priorités et allocation de ressources :

Autres exemples de tâches :

Enfin, d’autres bons exemples d’analyse sont proposés par Elliott :

Conclusion

Copilot Cowork marque un tournant décisif dans l’évolution de Microsoft 365 Copilot. En passant d’un simple assistant conversationnel à un agent IA exécuteur capable de mener des projets entiers de bout en bout, Microsoft répond enfin au défi majeur de l’adoption de l’IA en entreprise.

Les premiers tests montrent un potentiel immense. Copilot Cowork livre des fichiers concrets, pas juste du texte. La transparence du processus, la possibilité d’intervenir à tout moment et l’exécution en arrière-plan transforment radicalement la relation à l’IA.

Bien que certaines limitations subsistent, la technologie est déjà fonctionnelle et prête pour la production dans le cadre du programme Frontier. La disponibilité générale attendue fin mars 2026 (et la suite Microsoft 365 E7 le 1er mai) devrait démocratiser l’accès.

Le passage de « résume-moi ce document » à « prépare ma réunion de mardi avec Christophe» n’est pas une simple évolution : c’est une révolution.

L’IA agentique n’est plus de la science-fiction. Elle est déjà dans Word, Excel, PowerPoint et Outlook. Et elle ne fait que commencer à transformer notre manière de travailler.

Pour finir, voici encore une autre vidéo qui pourrait vous donner quelques idées :