Configurez Copilot Cowork en CSP

Vous administrez un tenant Microsoft 365, Copilot Cowork vient de passer en GA, et vous voulez faire les choses bien : poser une spending policy pour cadrer la dépense avant d’ouvrir les vannes. Sauf que votre tenant est onboardé dans le programme CSP, et là, sur la page Cost management, votre compte Global Admin se prend une bannière « managed by your solution provider » en pleine figure.

On part d’un Global Admin permanent qui devrait tout pouvoir, et on déroule, capture après capture, pourquoi il est bloqué, pourquoi un License Admin se mange un 403, et pourquoi (c’est le clou) un Global Admin activé en just-in-time via PIM, lui, passe. Et tant qu’à parler d’incohérences, j’en ai relevé une seconde, côté licence, que je partage en fin d’article.

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

1. Le contexte en deux lignes
2. Le symptôme : avant et après l’onboarding CSP
3. Ce n’est pas un problème de rôle
4. Le License Administrator : l’assistant va au bout, puis 403
5. Le contournement qui marche : Global Admin en JIT via PIM
6. Première incohérence : Global Admin permanent contre JIT
7. Seconde incohérence : Cowork sans licence Microsoft 365 Copilot
8. Mes questions ouvertes à Microsoft
9. Récap : la checklist si vous êtes en CSP

Si vous débarquez sur le sujet des Copilot Credits et des spending policies, je vous renvoie d’abord à mon article précédent qui pose tout le décor de la facturation à l’usage de Cowork : Copilot Cowork passe en PAYG. Ici, on attaque un cas plus tordu, observé sur des tenants CSP.

1. Le contexte en deux lignes

Pour rappel, depuis la GA du 16 juin 2026, l’usage de Copilot Cowork se facture à la consommation en Copilot Credits, et tout se pilote depuis le centre d’administration Microsoft 365, menu Copilot puis Cost management. Le geste fondateur côté admin, c’est la création d’une spending policy : c’est elle qui décide qui peut dépenser des crédits, combien, et sur quelle méthode de facturation. Sans elle, rien ne s’active. J’ai détaillé toute cette mécanique dans l’article cité plus haut.

Le problème que je vous décris ici n’apparaît que sur les tenants passés sous gestion CSP (Cloud Solution Provider). Toutes les captures qui suivent ont été anonymisées : le tenant est nommé contoso, et le second compte d’administration admin2. La logique observée, elle, est strictement celle de mon lab.

2. Le symptôme : avant et après l’onboarding CSP

Commençons par l’état sain. Connecté avec mon compte Global Admin, j’ouvre Copilot puis Cost management. Tout est normal : l’expérience de facturation à l’usage est disponible, le bouton Get started m’est proposé, aucune restriction à l’horizon.

Maintenant, le tenant est onboardé dans le programme CSP. Même compte, même page, même navigateur. Et la page a changé de visage : une bannière s’affiche pour me dire que mon organisation est gérée par un solution provider, et que la gestion des Copilot Credits doit être configurée par ce provider. Plus de Get started, plus de configuration possible de mon côté.

La seule variable qui a changé entre les deux captures, c’est l’onboarding CSP. Pas le compte, pas le rôle, pas la page. C’est donc bien le CSP qui déclenche le blocage.

3. Ce n’est pas un problème de rôle

Premier réflexe quand un admin se fait jeter : vérifier le rôle. Direction le centre d’administration Microsoft Entra. Et c’est sans appel : mon compte porte bien le rôle Global Administrator, en assignation active, directe et permanente. Le plus haut niveau de privilège du tenant.

Le blocage de l’étape 2 n’est donc pas une histoire de droits insuffisants. Un Global Admin permanent reste bloqué. On tient là le premier vrai mystère.

4. Le License Administrator : l’assistant va au bout, puis 403

Deuxième piste : et si je tentais avec un rôle moins privilégié, par bonne hygiène de moindre privilège ? Je crée un second compte, admin2, à qui j’attribue uniquement le rôle License Administrator, en permanent.

Bonne surprise au premier abord : connecté en License Admin, l’onglet Configuration de Cost management se charge, et le bouton Add spending policy est bien là :

Un message transitoire passe au chargement, « We couldn’t load your latest policies from the admin service », mais l’assistant s’ouvre :

Je remplis le wizard de bout en bout : nom de la policy, périmètre All users, services Copilot Cowork et Work IQ API, méthode de facturation pay-as-you-go sur une souscription Azure dédiée, plafond mensuel et alertes. Tout passe, écran après écran. Puis je clique sur Create spending policy, et là, le couperet :

Le message est explicite : « Failed to create Copilot Credits billing plan: Request failed with status 403 ». L’assistant m’a laissé tout remplir pour échouer à la toute dernière étape. Frustrant, mais en fait, la documentation Microsoft éclaire ce point précis.

La page Microsoft Learn sur la gestion de la facturation à l’usage distingue deux familles de rôles. Les rôles AI Administrator et License Administrator peuvent créer des spending policies, gérer les limites et les alertes, et consulter le tableau de bord. Mais pour la méthode de facturation, c’est une autre histoire :

They can’t set or modify the billing method.
Source : Managing AI experiences enabled by usage-based billing, Microsoft Learn

Définir ou modifier la méthode de facturation est réservé aux rôles Global Administrator et Billing Administrator. Or créer une policy en pay-as-you-go, c’est précisément rattacher une méthode de facturation. D’où le 403 à l’étape finale : le License Admin pouvait dérouler le wizard, mais pas poser le billing plan.

Attention : ce 403 n’est donc pas un bug, c’est une frontière de privilège. Le bon réflexe de moindre privilège pour la partie facturation, ce n’est pas Global Admin, c’est le rôle Billing Administrator. Microsoft recommande d’ailleurs de réserver Global Administrator aux scénarios d’urgence.

Mon retour terrain : le message « couldn’t load your latest policies from the admin service » a été observé pendant la fenêtre de déploiement de la GA, les 16 et 17 juin. Possible indisponibilité intermittente du service d’administration ce jour-là, je n’ai pas pu trancher s’il a un lien avec le blocage CSP ou non.

5. Le contournement qui marche : Global Admin en JIT via PIM

Le 403 du License Admin s’explique. Mais souvenez-vous : mon compte principal, lui, est Global Admin permanent, et il reste bloqué par la bannière CSP. Alors j’ai tenté autre chose sur le second compte. En plus de son License Administrator permanent, admin2 dispose du rôle Global Administrator en éligible via Privileged Identity Management (PIM).

J’active donc Global Administrator en just-in-time pour admin2, de façon limitée dans le temps via PIM :

Le rôle passe à Activated, à côté de l’assignation License Administrator permanente :

Je relance le même assistant Add spending policy, avec exactement les mêmes choix qu’à l’étape précédente. Et cette fois :

« Spending policy created ». La policy s’affiche dans la liste Configuration et s’applique immédiatement aux utilisateurs ciblés. De retour sur mon compte Global Admin principal, je la vois bien active, pour tous les utilisateurs, facturée en pay-as-you-go.

6. Première incohérence : Global Admin permanent contre JIT

Récapitulons le paradoxe, parce que c’est lui le cœur du sujet. Sur le même tenant, contre le même backend, à quelques minutes d’intervalle :

un Global Administrator permanent est bloqué en amont par la bannière CSP, il ne peut même pas lancer la configuration :

un License Administrator atteint la dernière étape puis échoue en 403, ce qui s’explique par la frontière de privilège sur le billing :

un Global Administrator activé en just-in-time via PIM, sur un autre compte, réussit la création de bout en bout :

Le rôle effectif est pourtant le même entre le compte bloqué (Global Admin permanent) et le compte qui réussit (Global Admin JIT). La différence tient au contexte d’activation : permanent contre just-in-time. Mon hypothèse, et je le présente bien comme une hypothèse, c’est que le blocage CSP se joue au niveau du contexte de session ou d’autorisation, pas au niveau du rôle effectif. Comme si les deux chemins ne touchaient pas exactement la même condition côté backend.

Attention : ce contournement par PIM fonctionne sur mon lab, mais ce n’est pas un comportement documenté. Je ne le présente pas comme la méthode supportée, juste comme une observation. Un changement côté Microsoft pourrait le faire disparaître du jour au lendemain.

7. Seconde incohérence : Cowork sans licence Microsoft 365 Copilot

Le blocage CSP n’est pas la seule bizarrerie que j’ai relevée. En creusant sur plusieurs tenants, je suis tombé sur une seconde incohérence, cette fois côté licence. Dans mon premier article, je posais la licence Microsoft 365 Copilot comme le ticket d’entrée obligatoire de Cowork. C’est d’ailleurs la lecture que Microsoft met en avant dans sa documentation, où la licence sert de point d’entrée vers les services facturés à l’usage :

(…) licenses act as an entry point enabling access to AI services (…)
Source : Usage-Based Billing and Cost Management for Copilot Credits, Microsoft Learn

Sauf que sur le terrain, le tableau est plus flou. Sur plusieurs tenants, j’ai vu Cowork consommer des crédits sans qu’aucune licence Microsoft 365 Copilot ne soit assignée à l’utilisateur. Les crédits étaient tirés soit du pack de capacité apporté par une licence Copilot Studio, soit directement de la souscription Azure en pay-as-you-go. Dans les deux cas, pas de licence Microsoft 365 Copilot sur le compte, et Cowork fonctionne quand même.

J’avais déjà effleuré le sujet dans mon premier article, avec un utilisateur sans licence Microsoft 365 Copilot qui avait quand même pu utiliser Cowork pendant la période de grâce. Ce que je constate maintenant va plus loin : ce n’est pas un simple effet de la période de grâce, et ça se répète sur plusieurs tenants, avec des sources de crédits différentes.

Mon retour terrain : la question que ça pose est simple. La licence Microsoft 365 Copilot est-elle vraiment un prérequis dur pour Cowork, ou juste un des points d’entrée possibles, à côté des crédits Copilot Studio et du pay-as-you-go Azure ? Le « in some scenarios » de la doc laisse la porte ouverte, mais ce point n’est documenté nulle part de façon claire. À confirmer avec Microsoft.

8. Mes questions ouvertes à Microsoft

À ce stade, j’ai des observations solides, captures à l’appui, mais pas toutes les réponses. Voici les cinq questions que je porte à Microsoft, dans l’ordre d’importance :

La bannière « managed by your solution provider » est-elle le comportement attendu pour un tenant CSP ? Si oui, quel est le chemin supporté et documenté pour qu’un client CSP (ou son provider) crée et gère ses spending policies Copilot Credits ?
Pourquoi un Global Administrator permanent est-il bloqué, alors qu’un Global Administrator activé en just-in-time via PIM sur un second compte réussit, contre le même backend ?
Le 403 renvoyé au License Administrator est-il bien le comportement attendu vu la frontière de privilège sur le billing, et le rôle Billing Administrator suffit-il pour la partie méthode de facturation sur un tenant CSP ?
La licence Microsoft 365 Copilot est-elle un prérequis strict pour utiliser Cowork, ou un simple point d’entrée parmi d’autres ? J’observe Cowork consommer des crédits, via un pack Copilot Studio ou la souscription Azure, sans aucune licence Microsoft 365 Copilot assignée.
Le message « couldn’t load your latest policies from the admin service » était-il une condition transitoire du rollout des 16 et 17 juin, ou est-il lié au blocage CSP ?

Update à venir : je mettrai cet article à jour dès que j’aurai un retour officiel de Microsoft sur ces points. Si vous observez le même comportement de votre côté, ou si vous avez une explication, les commentaires sont ouverts.

9. Récap : la checklist si vous êtes en CSP

Voilà, en quelques étapes, ce qu’il faut avoir en tête si votre tenant Copilot est sous gestion CSP et que vous butez sur la création d’une spending policy.

Constat	Ce que ça signifie	Quoi faire
Bannière « managed by your solution provider »	Le blocage est déclenché par l’onboarding CSP, pas par un rôle manquant	Vérifier la relation CSP, solliciter votre provider, et poser la question à Microsoft
403 en License Administrator	Ce rôle ne peut pas définir la méthode de facturation	Utiliser Billing Administrator pour la partie billing, pas un rôle trop faible
Global Admin permanent bloqué, JIT PIM qui passe	Le blocage semble lié au contexte de session, pas au rôle effectif	Contournement observé via PIM, mais non documenté : à confirmer avec Microsoft
Cowork actif sans licence Microsoft 365 Copilot	La licence présentée comme ticket d’entrée n’est pas toujours requise en pratique	Vérifier l’assignation réelle des licences et la source des crédits, et confirmer avec Microsoft
Message « couldn’t load your latest policies »	Possible indisponibilité transitoire du service d’admin	Réessayer, et surveiller si ça persiste hors fenêtre de rollout

Concrètement, ça donne quoi ? Sur un tenant CSP, la création d’une spending policy Copilot Credits ne se comporte pas comme sur un tenant classique, et les garde-fous de rôle de Microsoft (moindre privilège côté policy, billing réservé à Global ou Billing Admin) se doublent d’une couche CSP qui, elle, n’est pas documentée à ce jour. Les deux pièges côté CSP : un Global Admin permanent ne vous garantit pas de pouvoir configurer les crédits sur un tenant managé, et le bon rôle pour la facturation reste Billing Administrator, pas Global Admin par défaut. À ça s’ajoute la surprise côté licence : Cowork peut tourner sans licence Microsoft 365 Copilot, en tirant sur des crédits Copilot Studio ou sur le pay-as-you-go Azure, ce qui mérite d’être vérifié de près avant de bâtir votre modèle de coût.

Foncez tester en lab si vous gérez des tenants CSP, et documentez ce que vous voyez : c’est exactement le genre de cas limite qui se précise à mesure que la GA se déploie.

Je complèterai dès que Microsoft me répond.

Copilot Cowork passe en PAYG

Ces derniers jours nous ont donné le vertige côté nouveautés IA, et celle-ci n’est pas sans impact. Vous administrez un tenant Microsoft 365, vous avez vu passer l’annonce de la disponibilité générale de Copilot Cowork le 16 juin 2026, et votre première question n’est pas « qu’est-ce que ça va faire » mais « qu’est-ce que ça va coûter, et comment je garde la main dessus » ? Cet article est fait pour vous.

On va laisser de côté la démo marketing pour aller droit au sujet qui nous concerne, nous les admins : la GA de Cowork s’accompagne d’un vrai changement de modèle de facturation.

Pour rappel, jusqu’ici Microsoft 365 Copilot, c’était un tarif fixe, prévisible, par utilisateur et par mois :

Cowork, lui, a introduit le 16 juin une facturation à l’usage, comptée en Copilot Credits. On va dérouler ensemble ce que ça change, combien ça coûte réellement (chiffres à l’appui), où ça se pilote dans l’Admin Center, et comment activer tout ça sans laisser filer la facture.

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

1. Ce qui change vraiment le 16 juin
2. Le modèle de coût en clair
3. Combien ça coûte concrètement ?
4. Estimer votre budget avec le calculateur Microsoft
5. Le nouveau menu Cost management
6. Activer Cowork et créer une spending policy
7. Plafonner et surveiller la dépense
8. Calendrier et période de grâce
9. Récap : la checklist admin

1. Ce qui change vraiment le 16 juin

Le 16 juin 2026, Microsoft a annoncé la disponibilité générale mondiale de Copilot Cowork, après trois mois de preview dans le programme Frontier. Sur le papier, c’est l’arrivée d’un assistant agentique capable d’exécuter des tâches longues, multi-outils, du début à la fin : vous définissez le travail, Cowork le mène de bout en bout et vous rend un résultat fini, pas juste un brouillon ou une recommandation. Très différent du Copilot Chat que vos utilisateurs connaissent déjà.

Pour un admin, le vrai changement n’est pas la fonctionnalité, c’est le modèle économique qui vient avec. Deux points à retenir tout de suite. D’abord, Cowork est désactivé par défaut : rien ne se déclenche tant que vous n’avez pas pris la décision de l’activer dans votre tenant et de choisir qui y a accès. Ensuite, son usage se facture à la consommation, en plus de la licence. C’est ce second point qui mérite qu’on s’y attarde.

2. Le modèle de coût en clair

Première chose à comprendre : la licence Microsoft 365 Copilot (la USL, User Subscription License) reste obligatoire, mais elle ne suffit plus pour utiliser Cowork. Elle devient un simple ticket d’entrée. Microsoft le dit noir sur blanc dans sa documentation :

In some scenarios, licenses act as an entry point enabling access to AI services billed on a pay-as-you-go basis.
Source : Usage-Based Billing and Cost Management for Copilot Credits, Microsoft Learn

Concrètement, ça donne quoi ? Chaque tâche que vous lancez dans Cowork a un prix, calculé à partir de quatre paramètres qui convergent tous vers un nombre de Copilot Credits consommés :

Models : le modèle d’IA retenu pour la tâche, qui varie selon la qualité, la vitesse et le coût demandés.
Context : la récupération du contexte, vos e-mails, fichiers, réunions et historiques que la tâche doit aller comprendre.
Tools : les actions menées pour faire le travail, envoyer un mail, planifier, mettre à jour un document.
Runtime : le temps d’orchestration cloud, qui fait tourner les agents, y compris sur les tâches longues.

Côté paiement, vous avez trois options :

Le pay-as-you-go (PayGo), facturé 0,01 $ par Copilot Credit sur une souscription Azure, pour la souplesse.
Le P3, qui consiste à engager un volume d’usage à l’avance en échange d’une remise.
Le pack de capacité apporté par la licence Microsoft Copilot Studio sur votre tenant :

À vous de voir selon votre visibilité sur la consommation à venir, et on va justement parler de cette consommation.

3. Combien ça coûte concrètement ?

C’est la question que tout le monde se pose, et Microsoft y répond en classant les tâches en trois profils : légères, moyennes et lourdes :

Voici les fourchettes de crédits annoncées, auxquelles j’ai ajouté l’équivalent en dollars au tarif PayGo (0,01 $ le crédit) pour que ce soit parlant.

Type de tâche	Profil	Crédits Copilot estimés	Coût PayGo indicatif
Légère (Light)	Peu de sources, raisonnement léger, une sortie ou moins	100 à 300	1 à 3 $
Moyenne (Medium)	Sources multiples, raisonnement structuré, deux sorties ou plus	400 à 700	4 à 7 $
Lourde (Heavy)	Agrégation large, analyse profonde, nombreuses sorties	plus de 700	plus de 7 $

Pour rendre les choses concrètes, Microsoft donne des exemples :

Une tâche légère, c’est typiquement « crée une mise à jour hebdo pour mon équipe le lundi matin, avec mes priorités et mes réunions clés ».
Une tâche moyenne, c’est « prépare ma réunion client : e-mails, agenda, fichiers récents dans un doc de briefing, un aperçu Excel des ventes et une présentation prête à montrer ».
Une tâche lourde, c’est « analyse six mois de données d’usage produit et sors un rapport pour la direction ». On voit bien la logique : plus la tâche brasse de sources et produit de livrables, plus elle pèse en crédits.

Attention : ces fourchettes sont des estimations, basées sur le modèle Opus 4.8. Le coût réel d’une tâche dépend de votre configuration, du modèle choisi et de la complexité réelle. Pour modéliser votre propre consommation, Microsoft fournit un calculateur, le Customer Cowork Estimator (accès authentifié requis).

4. Estimer votre budget avec le calculateur Microsoft

Bonne nouvelle : Microsoft ne vous laisse pas deviner à l’aveugle. Un classeur Excel téléchargeable, le Customer Cowork Estimator, vous permet de modéliser votre consommation et d’obtenir une estimation de budget directionnelle, à affiner dans le temps.

Le principe est simple : pour chaque profil d’utilisateur, on multiplie le nombre d’utilisateurs par le volume de prompts attendu (légers, moyens, lourds), on applique le coût en crédits de chaque type de prompt, et on additionne le tout. Vous passez ainsi d’un coût par tâche un peu abstrait à un budget mensuel global, présentable à votre direction financière.

Concrètement, le classeur se remplit en quatre étapes :

Qui va utiliser Cowork ? Vous renseignez le nombre d’utilisateurs, répartis selon les profils définis par Microsoft.
Combien de prompts par mois ? Pour chaque profil, vous indiquez le volume mensuel de prompts légers, moyens et lourds.
Combien de crédits par prompt ? Le classeur applique un nombre de crédits par type de prompt, sur la base du modèle Opus 4.8.
Le résultat : les crédits mensuels estimés et le coût correspondant, au tarif de 0,01 $ le crédit.

Attention : ces chiffres restent directionnels. Le classeur est fourni à titre d’illustration et suppose le modèle Opus 4.8 : votre coût réel dépendra du modèle effectivement utilisé, du contexte mobilisé et de la complexité des tâches. Voyez-le comme un point de départ, à recalibrer une fois vos premières semaines de consommation observées.

5. Le nouveau menu Cost management

Si vous ouvrez votre centre d’administration Microsoft 365 ces jours-ci, vous allez remarquer que les menus ont bougé, et ce n’est pas un hasard d’affichage :

Mon retour terrain : sur mon tenant, entre le 16 et le 17 juin au matin, le menu qui s’appelait « Billing and usage » dans la section Copilot a été renommé « Cost management », et un menu « Cowork » dédié est apparu. La page de documentation Microsoft Learn correspondante est d’ailleurs datée du 16 juin 2026, soit le jour même de la GA. Le renommage suit donc le déploiement, ce n’est pas un bug local.

Le menu Cowork, lui, affiche un tableau de bord dédié au suivi de l’adoption, de la consommation et des limites de Cowork : nombre d’utilisateurs actifs, nombre de tâches lancées, période de grâce restante, demandes de crédits en attente et gestion des plugins :

Ce tableau de bord Cost management est l’endroit où tout se pilote. Il s’organise autour de trois onglets :

Overview pour la photo en temps réel de la consommation et de la capacité restante
Configuration pour activer la facturation à l’usage et définir vos politiques de dépense
Consumption pour analyser en détail qui consomme quoi.

C’est votre poste de pilotage des Copilot Credits, à mettre en favori dès maintenant :

6. Activer Cowork et créer une spending policy

Rappel important : Cowork est désactivé par défaut. Tant que vous ne faites rien, vos utilisateurs n’y ont pas accès et rien ne se facture.

L’activation côté utilisateur et le mode Frontier, je les ai déjà détaillés dans un précédent article, je vous y renvoie pour cette partie : activer et tester Copilot Cowork. Ici, on se concentre sur le nerf de la guerre côté admin : la spending policy, la politique de dépense qui encadre qui peut consommer des crédits, et combien :

Comme pour l’activation de Frontier, tout se joue au niveau du tenant, et on commence par cadrer un périmètre maîtrisé. Direction le tableau de bord Cost management, onglet Configuration, puis Add spending policy :

L’assistant se déroule en cinq étapes, visibles dans le volet de gauche :

Applies to : donnez un nom à la politique (champ Name this policy), puis choisissez qui peut dépenser des crédits. Trois options :

All users (toute l’organisation, idéal pour une politique par défaut)
Specific groups (limiter à des groupes de sécurité, la liste étant pré-remplie avec les groupes ayant déjà fait des demandes de crédits)
Specific users (Coming soon, il faut pour l’instant passer par un groupe de sécurité) :

Limits and alerts : posez le plafond de crédits de la politique et les seuils d’alerte :

Agents and services : choisissez les services couverts par la politique :

Billing method : rattachez le mode de paiement :

pay-as-you-go (PayGo) (et l’abonnement Azure qui portera la facturation)
Crédits prépayés Copilot (P3)
Pack de capacité Copilot Studio

Review & add policy : relisez le récapitulatif et créez la spending policy :

Attendez quelques minutes la création de la spending policy :

Quelques minutes plus tard, la spending policy est créée :

La spending policy est donc maintenant en place, comme on peut le voir :

Et cela est également visible dans le portail Azure :

Enfin, le message d’alerte sur la copie d’écran ci-dessous nous rappelle que Microsoft a prévu de commencer la facturation au 1er juillet :

7. Plafonner et surveiller la dépense

C’est le cœur du sujet pour un admin, et la bonne nouvelle, c’est que Microsoft a mis le paquet sur les garde-fous. Ils se rangent en trois familles.

Le contrôle d’abord. Vous décidez quand Cowork s’allume, qui y accède et combien peut être dépensé :

Vous posez des plafonds de dépense au niveau du tenant, d’un groupe ou d’un utilisateur, via des politiques de facturation cadrées avec des caps par utilisateur :

Vous configurez des alertes d’usage personnalisables, avec vos propres seuils et les personnes à notifier quand ils sont franchis :

Et quand un utilisateur a besoin de crédits supplémentaires pour finir une tâche, il peut en faire la demande directement depuis Cowork, ce qui vous évite de jouer les pompiers.

La visibilité ensuite. Le reporting d’usage descend jusqu’au niveau utilisateur, groupe et fonctionnalité, avec une vraie responsabilité par périmètre. L’onglet Consumption permet de creuser par utilisateur, groupe, service ou agent, d’identifier les gros consommateurs et les postes de coût :

Avec un détail par utilisateur :

Microsoft annonce aussi, peu après la GA, l’affichage du coût de chaque tâche en crédits côté utilisateur, au moment où il la lance.

L’efficacité enfin. Au-delà du choix PayGo ou P3, là où plusieurs modèles sont disponibles, un sélecteur de modèle permet d’ajuster le coût par tâche. Et Microsoft promet trois leviers de baisse dans le temps : des modèles moins chers, un meilleur appariement modèle/tâche, et une récupération de contexte plus efficace.

Le modèle maison Cowork 1, annoncé pour bientôt, vise justement les tâches courantes à coût nettement réduit.

8. Calendrier et période de grâce

La facturation de Cowork démarre dès le 16 juin. Mais Microsoft a prévu un filet pour les early adopters :

Attention : les tenants ayant eu au moins un utilisateur actif sur Cowork pendant le programme Frontier (du 30 mars au 16 juin) bénéficient d’une période de grâce et ne seront pas facturés avant le 1er juillet 2026. Profitez de cette fenêtre pour poser vos plafonds et allouer vos budgets avant que la consommation ne monte.

J’ai par contre pu constater une petite chose étrange sur mon tenant :

Comme vous le voyez, un de mes utilisateurs n’avait pas de licence Microsoft 365 Copilot, et il y a quand même pu utiliser Cowork, en consommant des crédits non facturés durant cette période de grâce :

9. Récap : la checklist admin

Voilà, en quelques étapes, ce qu’il faut avoir en tête avant d’ouvrir Cowork à vos utilisateurs.

Action	Où / comment	Pourquoi
Estimer le budget	Customer Cowork Estimator (Excel)	Anticiper la dépense mensuelle par profil
Configurer la facturation	Cost management, onglet Configuration	Choisir PayGo ou P3, connecter l’abonnement Azure
Créer une spending policy	Configuration, Add spending policy	Cadrer qui peut dépenser et combien
Poser les plafonds et alertes	Étape Limits and alerts de la policy	Être prévenu avant le dérapage, pas après
Activer Cowork sur un pilote	Périmètre d’accès par groupe	Tester l’usage réel avant d’élargir
Suivre la consommation	Onglets Overview et Consumption	Identifier les gros postes de coût

Concrètement, ça donne quoi ? Cowork est une vraie nouvelle façon de travailler, mais c’est aussi la première fois que Microsoft 365 vous met une facturation à l’usage entre les mains. Les trois pièges à retenir :

La licence M365 Copilot ne suffit pas, l’usage de Cowork se paie en plus, en Copilot Credits.
Une tâche lourde peut dépasser 700 crédits, soit plus de 7 $ : sans plafond, une poignée d’utilisateurs actifs peut vite chiffrer.
La création de la spending policy demande un Global Admin et une source de financement (PayGo ou crédits prépayés) : sans elles, l’assistant refuse de créer le plan.

Foncez tester, mais plafonnez d’abord. Profitez de la période de grâce pour cadrer vos budgets et vos alertes pendant que la facture est encore à zéro. C’est le meilleur moment pour apprivoiser le modèle sans mauvaise surprise.

Fin des IPs basiques sur les VPNs basiques

Si vous avez lu mon article de juillet 2025 sur les VPN Azure et la deadline du 30/09, vous vous souvenez du test avec une VPN Gateway Basic SKU avec une IP publique dynamique. Le verdict était brutal : suppression de la connexion, suppression de la gateway, impossibilité de migrer l’IP dynamique, création d’une nouvelle IP Standard, recréation complète de la gateway, changement d’adresse IP à la clé. Un calvaire. Bonne nouvelle : Microsoft a depuis simplifié la procédure pour les VPN Gateways Basic SKU. En 2026, c’est un clic dans le portail, sans coupure réseau, sans changement d’IP, en moins de cinq minutes.

Pour rappel, jusqu’ici les VPN Gateways Basic SKU pouvaient être créées avec une IP publique Basic SKU. Azure a migré ces IPs en interne vers des IPs Standard SKU depuis. Il reste une dernière action à faire côté client : supprimer la référence à l’ancienne ressource IP Basic dans la configuration de la gateway. C’est ce qu’on va faire ensemble, capture après capture.

Attention : cet article concerne uniquement la VPN Gateway Basic SKU (le SKU développement/lab, sans SLA). Si vous avez une gateway VpnGw1 à VpnGw5 ou un SKU legacy (Standard, High Performance), le processus est différent : utilisez l’outil de migration dédié dans la Configuration de la gateway. Ce n’est pas ce dont on parle ici.

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

1. Pré-requis : êtes-vous concerné ?
2. Étape 0 : identifier la présence de la référence IP Basic
3. Étape 1 : vérifier la validation dans le portail
4. Étape 2 : supprimer la référence IP Basic
5. Étape 3 : vérifier le résultat
6. Étape 4 : supprimer l’ancienne ressource IP Basic
7. Pièges à éviter
8. Questions fréquentes
9. Conclusion

1. Pré-requis : êtes-vous concerné ?

Avant de toucher quoi que ce soit, vérifiez que vous êtes bien dans le cas de figure de cet article. Le piège classique : confondre « VPN Gateway Basic SKU » et « IP publique Basic SKU ». Ce sont deux ressources distinctes. Ici, on parle bien du SKU de la gateway elle-même.

Situation	Action
VPN Gateway Basic SKU avec une référence à une IP publique Basic SKU	✅ Vous êtes concerné par cet article
VPN Gateway Basic SKU sans référence IP Basic (déjà nettoyée)	✅ Rien à faire, vous êtes bon
VPN Gateway VpnGw1 à VpnGw5 (non-AZ ou AZ)	❌ Pas cet article : utiliser l’outil « Migrate to Standard IP » dans Configuration
VPN Gateway SKU legacy (Standard, High Performance)	❌ Pas cet article : suivre le guide de migration dédié Microsoft

Pour rappel, la VPN Gateway Basic SKU est un SKU développeur, sans SLA. Elle ne retire pas, contrairement à ce que beaucoup pensaient (moi y compris, au moment de mon article 2025). Microsoft a confirmé qu’elle reste disponible : c’est uniquement la référence à l’IP Basic qui doit être nettoyée.

2. Étape 0 : identifier la présence de la référence IP Basic

Deux façons de vérifier si votre gateway est concernée : depuis la CLI Azure ou directement depuis le portail.

Via Azure CLI : récupérez d’abord l’ID de l’IP publique associée à votre gateway.

az network vnet-gateway show \
    --name <nom-de-votre-gateway> \
    --resource-group <votre-resource-group> \
    --query "ipConfigurations[].publicIpAddress.id" \
    --output tsv

Copiez l’ID retourné, puis vérifiez le SKU de cette IP :

az network public-ip show \
    --ids <id-copié-ci-dessus> \
    --query "sku.name" \
    --output tsv

Si la commande retourne Basic, vous êtes concerné. Si elle retourne Standard, votre gateway est déjà propre :

Via le portail Azure : naviguez vers votre ressource Virtual network gateway. Dans le menu de gauche, sous Settings, cliquez sur Configuration. Si votre gateway est concernée, vous verrez une section Validation avec un bouton Delete Basic Public IP Reference. C’est la confirmation visuelle que vous devez agir.

Si vous ne voyez pas cette section, soit votre gateway n’a plus de référence IP Basic (déjà nettoyée), soit vous n’êtes pas sur un gateway Basic SKU.

3. Étape 1 : vérifier la validation dans le portail

Toujours sur la page Configuration, regardez la section Validation. Chaque ressource listée doit afficher le statut Succeeded avant de pouvoir continuer.

Attention : si une ou plusieurs ressources affichent un statut autre que Succeeded, ne continuez pas. Résolvez d’abord les erreurs signalées avant de déclencher la suppression.

4. Étape 2 : supprimer la référence IP Basic

Toutes les ressources sont en Succeeded ? Le moment de vérité. Cliquez sur le bouton Delete Basic Public IP Reference.

Concrètement, ça donne quoi ? Cette action retire l’association entre la ressource IP publique Basic SKU et la gateway. Ce n’est pas une migration. Azure avait déjà basculé l’IP en interne vers une ressource Standard SKU non visible dans votre subscription : vous ne faites que supprimer le pointeur côté client.

This action removes the association between your Basic SKU public IP address resource and the Basic SKU VPN gateway. It’s not a migration operation. The public IP address itself is already moved internally by Azure to a Standard SKU public IP address resource used by the VPN gateway.
Source : Remove the Basic SKU public IP Reference from a Basic SKU VPN gateway, Microsoft Learn

Mon retour terrain : dans mon article de 2025, le Test III montrait qu’il fallait supprimer la connexion VPN, supprimer la gateway, recréer une IP Standard, et tout reconstruire. L’IP changeait au passage. C’était le comportement de l’époque pour une IP dynamique. La procédure 2026 est radicalement différente pour la Basic SKU Gateway : un bouton, zéro downtime, l’IP reste la même. Microsoft a bien bossé sur ce point.

5. Étape 3 : vérifier le résultat

Une fois l’opération terminée, retournez sur la page de la gateway. Et là, surprise possible : l’adresse IP peut apparaître comme null dans le portail, ou le nom de l’ancienne ressource IP Basic est encore affiché sans lien cliquable.

Attention : ce comportement est un bug cosmétique connu et documenté par Microsoft. La gateway fonctionne parfaitement, l’IP n’a pas changé, et vos connexions S2S/P2S continuent de tourner. Ne paniquez pas.

Pour vérifier l’IP réelle utilisée par la gateway, deux options. Depuis le portail, cliquez sur JSON View en haut à droite de la page Overview de la gateway : les propriétés réelles de la ressource y sont correctement renseignées, avec l’adresse IP effective.

Ou depuis la CLI, via la propriété tunnelIpAddresses :

az network vnet-gateway show \
    --name <nom-de-votre-gateway> \
    --resource-group <votre-resource-group> \
    --query "bgpSettings.bgpPeeringAddresses[0].tunnelIpAddresses[0]" \
    --output tsv

6. Étape 4 : supprimer l’ancienne ressource IP Basic

La suppression de la référence ne supprime pas la ressource IP publique Basic SKU de votre subscription. Elle reste dans votre resource group, et Azure continue de vous la facturer tant que vous ne la supprimez pas manuellement.

Depuis le portail, naviguez vers votre resource group, repérez la ressource de type Public IP address avec le SKU Basic, et supprimez-la. Ou en CLI :

az network public-ip delete \
    --name <nom-de-votre-ip-basic> \
    --resource-group <votre-resource-group>

Une fois supprimée, la facturation de cette ressource s’arrête. La gateway continue d’utiliser une IP Standard SKU gérée en interne par Azure, non visible et non facturée séparément dans votre subscription.

7. Pièges à éviter

Piège n°1 : tenter d’upgrader l’ancienne ressource IP Basic manuellement. Après avoir supprimé la référence, vous pourriez être tenté d’upgrader la ressource IP Basic restante vers un Standard SKU via le portail ou PowerShell. Ne le faites pas. Microsoft a documenté que cette tentative provoque un état de provisionnement Failed sur la ressource. La bonne action est la suppression pure et simple, pas l’upgrade.

Piège n°2 : paniquer devant l’affichage null dans le portail. Comme vu à l’étape 3, le portail peut afficher l’IP comme null ou encore le nom de l’ancienne ressource Basic sans lien. C’est purement cosmétique. Fiez-vous à la vue JSON ou à la CLI pour vérifier l’état réel, et testez vos tunnels VPN : ils fonctionnent.

Piège n°3 : ne rien faire avant le 30 juin 2026. Si vous ne supprimez pas la référence avant la deadline, votre gateway continuera de fonctionner, mais dans une configuration non supportée, sans garantie de SLA. Microsoft ne viendra pas corriger ça pour vous. La VPN Gateway Basic SKU est déjà un SKU sans SLA en temps normal : sans cette action, elle perd toute couverture de support.

8. Questions fréquentes

Microsoft a publié une FAQ détaillée sur cette procédure. Voici les points que je trouve les plus utiles à avoir en tête.

Cette opération change-t-elle le SKU ou migre-t-elle ma gateway ?

Non. C’est le point qui perturbe le plus : on parle de « migration IP » partout, mais cette opération ne migre rien et ne change pas le SKU de la gateway. Elle supprime uniquement la référence côté client.

This operation doesn’t change the VPN Gateway SKU and doesn’t migrate the gateway. It only removes the reference to the Basic SKU public IP address resource from the gateway configuration.
Source : Remove the Basic SKU public IP Reference from a Basic SKU VPN gateway, Microsoft Learn

Qu’arrive-t-il exactement à mon adresse IP ?

La valeur de l’IP ne change pas. En revanche, après l’opération, la ressource IP publique Basic SKU côté client n’est plus liée à la gateway. L’IP est désormais portée par une ressource Standard SKU interne, non visible dans votre subscription.

The IP address value itself doesn’t change and continues to be used by the VPN gateway. However, after removing the reference: the customer-visible Basic SKU public IP address resource is no longer linked to the gateway. The IP address is now associated with an internal Standard SKU public IP address resource that isn’t visible in your subscription.
Source : Remove the Basic SKU public IP Reference from a Basic SKU VPN gateway, Microsoft Learn

Pourquoi ne puis-je pas accéder à la nouvelle ressource IP Standard créée par Azure ?

Parce qu’elle est intentionnellement invisible. C’est une ressource interne Azure-managed, hors du périmètre de votre subscription. Vous ne pouvez pas la gérer, la voir, ni la facturer.

The Standard SKU public IP address that’s used by the VPN gateway after this process is an internal Azure-managed resource. It isn’t customer-visible or customer-manageable.
Source : Remove the Basic SKU public IP Reference from a Basic SKU VPN gateway, Microsoft Learn

Y a-t-il des changements de facturation ?

L’opération elle-même n’entraîne aucun nouveau frais. Mais l’ancienne ressource IP Basic reste dans votre subscription et continue d’être facturée jusqu’à sa suppression manuelle. La nouvelle IP Standard interne, elle, n’est pas facturée séparément.

Dis-associating the Basic public IP reference from your VPN gateway doesn’t introduce any new charges and doesn’t result in additional billing. Once you delete it, billing for that Basic public IP resource stops. Your VPN gateway continues to use an internally managed Standard SKU public IP address provided by Azure. This internal Standard SKU public IP address isn’t customer-visible and isn’t billed separately.
Source : Remove the Basic SKU public IP Reference from a Basic SKU VPN gateway, Microsoft Learn

Que se passe-t-il si je ne fais rien avant le 30 juin 2026 ?

Votre gateway continue de tourner, mais dans une configuration officiellement non supportée. Pas de SLA, pas d’intervention Microsoft. Et contrairement à ce qu’on pourrait espérer, Microsoft ne fera rien à votre place.

If you don’t take action, your VPN gateway will continue running in an unsupported state. The VPN Gateway Basic SKU doesn’t include SLA guarantees and isn’t intended for production use. Microsoft won’t automatically modify or clean up resources in your subscription. Your gateway might continue to function, but reliability, availability, and support aren’t guaranteed.
Source : Remove the Basic SKU public IP Reference from a Basic SKU VPN gateway, Microsoft Learn

9. Conclusion

Voilà, en quatre étapes : vérification CLI ou portail, validation de la section Configuration, clic sur Delete Basic Public IP Reference, suppression de l’ancienne ressource IP Basic. Dix minutes grand maximum, zéro coupure réseau, l’IP ne change pas.

Par rapport à la situation de 2025 décrite dans mon article sur la deadline du 30/09, Microsoft a vraiment simplifié la procédure pour le cas VPN Gateway Basic SKU. En 2025, le seul chemin pour une IP dynamique était la destruction et la recréation complète, avec changement d’IP à la clé. En 2026, c’est un bouton dans le portail.

Les trois pièges à retenir :

Ne pas tenter d’upgrader l’ancienne ressource IP Basic après dissociation, sous peine de la mettre en état Failed.
L’affichage null dans le portail est cosmétique : vérifier via la vue JSON ou la CLI.
Deadline le 30 juin 2026. Microsoft ne fait rien pour vous si vous ne bougez pas.

Foncez tester en lab si vous n’êtes pas encore passé à l’acte, et planifiez la prod dans la foulée. C’est le genre d’opération qui se fait en dix minutes et qui évite une mauvaise surprise après le 30 juin.

Et pendant que vous êtes dans le portail Azure, profitez-en pour jeter un œil au Service Retirement Workbook, accessible depuis Azure Advisor > Workbooks > Service Retirement. Ce classeur liste toutes vos ressources impactées par des retraits Azure en cours, avec les dates d’échéance et les actions recommandées. Je l’avais déjà présenté dans mon article de 2025 et il reste, aujourd’hui encore, le meilleur moyen de ne rien rater dans votre tenant.

Fable 5 dans Copilot Cowork

Claude Fable 5 vient de débarquer dans Microsoft 365 Copilot, vous avez vu passer l’annonce, et vous vous posez déjà deux questions : qu’est-ce que ce modèle change concrètement, et pourquoi reste-t-il introuvable dans votre tenant ? Cet article est fait pour vous.

On va dérouler les trois temps qui comptent pour un admin ou un archi cloud : comprendre ce qu’apporte ce modèle de classe Mythos, l’activer proprement depuis le centre d’administration Microsoft 365, et garder l’œil sur le vrai point de vigilance, la rétention de données côté Anthropic et le réglage désactivé par défaut en Europe. Capture après capture, vous saurez exactement quoi cocher, et ce que vous engagez en le faisant.

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

1. Fable 5, c’est quoi au juste ?
2. Intégration : Copilot Cowork et les apps Microsoft 365
3. Activation côté admin, le pas-à-pas
4. Sélection côté utilisateur
5. Cas d’usage concrets
6. Le point de vigilance : rétention et default-off en UE
7. Conclusion

1. Fable 5, c’est quoi au juste ?

Anthropic a annoncé Claude Fable 5 le 9 juin 2026. C’est leur premier modèle de classe Mythos rendu disponible pour un usage général, et selon l’éditeur ses capacités dépassent celles de tous les modèles qu’il avait ouverts au grand public jusqu’ici. Concrètement, Fable 5 vise les tâches longues et complexes : plus la mission s’étire dans le temps, plus son avance se creuse sur les modèles précédents.

Pour un admin, retenez les points saillants :

Code et travail agentique : refactorings massifs, tâches multi-étapes qui tournent en autonomie sur la durée.
Travail de connaissance : synthèse documentaire longue, analyse de données, raisonnement financier.
Vision : extraction de chiffres précis depuis des figures, reconstruction d’une app à partir de captures.
Mémoire et long contexte : le modèle reste concentré sur des millions de tokens et améliore ses sorties grâce à ses propres notes.

Le point qui intéresse la gouvernance : Anthropic a livré Fable 5 avec des garde-fous. Quand une requête touche à la cybersécurité, à la biologie ou à la chimie, ou à la distillation de modèles, la réponse est automatiquement prise en charge par Claude Opus 4.8, et l’utilisateur en est informé. L’éditeur précise que ce repli concerne, en moyenne, moins de 5 % des sessions : pour le reste, c’est bien Fable 5 qui répond.

When Fable’s classifiers detect a request related to cybersecurity, biology and chemistry, or distillation, the response is automatically handled by Claude Opus 4.8 instead. Users will be informed whenever this occurs.
Source : Claude Fable 5 and Claude Mythos 5, Anthropic

2. Intégration : Copilot Cowork et les apps Microsoft 365

C’est là que ça devient intéressant pour un archi. Fable 5 n’arrive pas comme un simple modèle de plus dans le sélecteur : il vient nourrir Copilot Cowork, la brique agentique de Microsoft 365 Copilot. Microsoft a en effet repris la plateforme qui fait tourner Claude Cowork pour la porter dans Copilot, et l’a ouverte le 30 mars 2026 via le programme Frontier.

bringing the technology platform that powers Claude Cowork into Microsoft 365 Copilot.
Source : Copilot Cowork: Now available in Frontier, Microsoft 365 Blog

Microsoft le formule sans détour dans son billet d’annonce du 10 juin : Claude Fable 5 arrive comme modèle preview pour les workflows longs et multi-étapes, ancré dans Work IQ, avec protections entreprise, contrôles d’admin et choix du modèle. Et l’éditeur pose lui-même la réserve sur la rétention de données, à intégrer dans la décision d’activation.

Because use of Claude Fable 5 is subject to data retention by Anthropic, organizations should review this consideration as part of their enablement decision.
Source : Available today: Anthropic Claude Fable 5 in Microsoft 365 Copilot, Microsoft Community Hub

Concrètement, Cowork est pensé pour le travail long et multi-étapes directement dans M365 : il ne se contente pas de répondre, il enchaîne des actions à travers Outlook, Teams, Excel, Word et PowerPoint, vous montre son plan, et l’exécute après votre validation. Le tout reste ancré dans Work IQ (le contexte de votre organisation) et protégé par l’Enterprise Data Protection. C’est exactement le terrain de jeu d’un modèle de classe Mythos : missions asynchrones, refactoring, synthèse documentaire lourde, là où le long contexte et l’autonomie de Fable 5 font la différence.

Où le trouver à ce stade de la preview, et avec quel statut :

Copilot Cowork : via le programme Frontier.
Copilot in Excel et Copilot in PowerPoint : en private preview.
Désactivé par défaut : contrairement à des modèles précédents, personne ne l’active à votre place, c’est un choix d’admin assumé.

Un mot sur le statut, parce qu’il conditionne tout le reste. Dans la nomenclature Microsoft, un modèle est soit Experimental, soit Preview, soit GA (disponible), soit Default. Fable 5 est un modèle Preview with Data Retention : un accès anticipé qui peut évoluer ou disparaître sans préavis, et que Microsoft déconseille explicitement en production. À réserver à l’évaluation et aux tests, sur un périmètre maîtrisé.

Preview and experimental models are intended for exploration and testing and are not recommended for production use.
Source : Preview AI models in Microsoft Online Services, Microsoft Support

Côté facture, bonne nouvelle : le choix du modèle est inclus dans la licence Microsoft 365 Copilot. Vous ne payez pas un supplément au token pour préférer Claude au modèle par défaut, contrairement au prix public API d’Anthropic (10 $ le million de tokens en entrée, 50 $ en sortie), qui ne concerne que l’API directe ou Microsoft Foundry, pas votre siège Copilot. Le vrai ticket d’entrée, c’est l’inscription au programme Frontier pour l’accès anticipé à Cowork et aux agents Office, dont la tarification définitive sera calée à la disponibilité générale.

Available via Frontier program, pricing final upon GA.
Source : Microsoft 365 Copilot Plans and Pricing, Microsoft

Et c’est là que se cache le vrai sujet. Jusqu’ici, les modèles Anthropic dans Copilot (Claude Sonnet, Claude Opus 4.8) étaient déjà gouvernés par le réglage subprocesseur, mais ils tournent en Zero Data Retention. Fable 5 casse cette logique : son usage est soumis à une rétention de données obligatoire côté Anthropic, ce qui le range dans une catégorie à part, et soulève la question que tout le monde se pose trop tard, où partent physiquement mes données ? On déballe tout dans la section vigilance.

3. Activation côté admin, le pas-à-pas

L’activation se fait en deux temps : on autorise d’abord Anthropic comme sous-traitant Microsoft (le prérequis global), puis on active le modèle preview lui-même. Il vous faut le rôle Global Admin ou AI Administrator.

Étape 0, le prérequis global. Rendez-vous dans le centre d’administration Microsoft 365, puis Copilot > Settings > View all. Ouvrez AI providers operating as Microsoft subprocessors et activez Anthropic. C’est la porte d’entrée : sans elle, aucun modèle Anthropic n’est utilisable dans Copilot. Et si vous aviez opté à l’époque pour l’ancien réglage sous conditions commerciales Anthropic, il faut re-opter : ce toggle hérité a été déprécié, et le nouveau repart sur Off en UE, EFTA et au Royaume-Uni.

Customers within the EU Data Boundary and customers in the UK will have Anthropic models disabled by default.
Source : Anthropic as a subprocessor for Microsoft Online Services, Microsoft Learn

Étape 1, le modèle preview. Toujours dans la même zone, ouvrez la catégorie AI models in preview, puis sélectionnez Anthropic Models with Data Retention. C’est ici que Fable 5 s’active, et le libellé ne laisse aucun doute sur ce que vous engagez.

Étape 2, la portée. Au moment d’activer, vous choisissez qui y a droit. Trois options, à caler sur votre stratégie de déploiement :

Portée	Effet	Quand l’utiliser
All users	Tout le tenant	Après un pilote concluant, déploiement large
No users	Personne	Pour préparer la config sans ouvrir l’accès
Specific users and groups	Utilisateurs ou groupes Entra ID ciblés	Pilote sur une équipe (produit, R&D) avant généralisation

Mon retour terrain : commencez par Specific users and groups sur un groupe de pilotes. Vous gardez la main sur la rétention de données pendant que vous validez les cas d’usage, et vous élargissez à All users seulement une fois la décision de conformité documentée.

4. Sélection côté utilisateur

Une fois l’accès ouvert, plus rien de compliqué pour l’utilisateur. Il retrouve Fable 5 dans le sélecteur de modèles de Copilot et le choisit comme n’importe quel autre. Petit détail qui compte pour la traçabilité : un indicateur visuel signale quand un modèle Claude est à l’œuvre, l’utilisateur sait donc toujours quel moteur traite sa demande.

5. Cas d’usage concrets

Concrètement, ça donne quoi ? Voici les terrains où Fable 5 mérite le détour pendant votre pilote :

Synthèse documentaire longue : bundles de réunions, rapports volumineux, dossiers à recouper sur des centaines de pages.
Analyse de données et finance : raisonnement sur tableaux et graphiques dans Copilot in Excel, où le long contexte fait la différence.
Workflows agentiques multi-étapes : tâches qui enchaînent plusieurs actions en autonomie, là où Fable 5 garde le cap sur la durée.
Vision : lecture de captures, de schémas, de figures techniques pour en extraire des données exploitables.
Comparatif A/B : lancez le même prompt sur le modèle par défaut et sur Fable 5, et tranchez sur pièces plutôt que sur intuition.

Et quand ne pas le sortir ? Pour un résumé, un mail ou une reformulation, Fable 5 n’apporte rien de plus qu’Opus ou Sonnet, tout en consommant davantage et en déclenchant la rétention. Gardez-le pour ce qui justifierait un expert humain : réflexion longue, analyse en profondeur, agentique multi-étapes. Le réflexe à transmettre à vos utilisateurs pilotes, c’est de réserver Fable 5 aux tâches que les autres modèles ne savent pas mener à bout.

Beaucoup de tests commencent à être disponibles sur YouTube, dont certains en français :

Sa conclusion : nos usages quotidiens sont sans doute encore trop basiques pour révéler le plein potentiel de ce modèle. Autrement dit, ce n’est pas Fable 5 qui manque de puissance, ce sont nos demandes qui manquent d’ambition. Pour l’utilisateur classique, Sonnet et Opus suffisent largement ; Fable 5 attend les tâches lourdes et complexes que personne n’osait encore confier à une IA, et son coût supérieur impose de toute façon d’être sélectif. À nous d’apprendre à le prompter autrement : moins le diriger, plus lui confier des terrains à défricher.

6. Le point de vigilance : rétention et default-off en UE

C’est la section à ne pas survoler, surtout depuis l’Europe. Trois choses se cumulent et changent vraiment la donne par rapport aux autres modèles Claude déjà présents dans Copilot : la rétention obligatoire, l’absence de Zero Data Retention, et la sortie de l’EU Data Boundary.

Pourquoi Fable 5 n’est pas un Claude comme les autres

Anthropic classe Fable 5 (et Mythos 5) parmi les Covered Models. Pour cette catégorie, une rétention de données de 30 jours est exigée, et le Zero Data Retention n’est tout simplement pas disponible. La raison est directement liée aux garde-fous vus plus haut : les classifiers de sécurité qui redirigent les requêtes sensibles vers Opus 4.8 ont besoin de conserver les échanges pour fonctionner et détecter les abus. À l’inverse, Claude Sonnet et Opus restent éligibles au ZDR, et c’est toute la différence.

Zero data retention is not available for Claude Fable 5 or Claude Mythos 5.
Source : API and data retention, Claude API Docs

Les durées, côté Anthropic : 30 jours de rétention standard des entrées et sorties, après quoi elles sont supprimées (sauf enquête de sécurité ou obligation légale), jusqu’à 2 ans si un échange est signalé par les classifiers comme contraire à la politique d’usage, et jusqu’à 7 ans pour les scores de classification associés. Ces données ne sont pas utilisées pour entraîner les modèles. C’est documenté noir sur blanc dans les pratiques de rétention pour les modèles de classe Mythos, ce ne sont pas des estimations de presse.

Critère	Claude Sonnet / Opus	Claude Fable 5
Zero Data Retention	Possible	Non disponible
Rétention standard	0 (ZDR) ou selon contrat	30 jours obligatoires
Si contenu signalé	Selon politique	Jusqu’à 2 ans (scores : 7 ans)
Entraînement modèle	Non	Non

Qui contrôle quoi : le contrat chez Microsoft, la rétention chez Anthropic

Le contrat, c’est Microsoft. Depuis le 7 janvier 2026, Anthropic opère comme sous-traitant (subprocessor) de Microsoft : vous ne signez rien avec Anthropic, tout passe par votre contrat Microsoft existant, à savoir les Product Terms, le Data Protection Addendum, l’Enterprise Data Protection et la garantie copyright (Customer Copyright Commitment). Microsoft précise même qu’Anthropic opère sous sa supervision. Et la portée que vous définissez (utilisateurs ou groupes) vaut d’un coup pour Microsoft 365 Copilot et pour Copilot Studio.

La rétention, en revanche, c’est Anthropic. Microsoft l’écrit lui-même dans sa documentation : quand un modèle exige une rétention de données, comme Fable 5, c’est le fournisseur du modèle qui contrôle la manière dont elles sont stockées et traitées, pas Microsoft. L’usage de Fable 5 reste donc soumis aux conditions d’Anthropic (Commercial Terms of Use, Data Protection Addendum et pratiques de rétention Mythos).

L’image simple à retenir : Microsoft vous loue la voiture et vous assure. Mais avec Fable 5, le trajet passe par un garage Anthropic aux États-Unis, qui garde une copie du carnet de bord pendant 30 jours, selon ses règles à lui. Microsoft vous prévient honnêtement, et vous laisse décider d’activer ou non.

Où partent vos données, concrètement

Attention : dans Microsoft 365 Copilot, Anthropic opère comme sous-traitant Microsoft, sous Microsoft Product Terms et le Data Protection Addendum. Mais le traitement des modèles Anthropic a lieu hors EU Data Boundary, et hors engagements de traitement in-country quand ils s’appliquent. En clair, depuis un tenant européen, activer Fable 5 revient à accepter que les prompts concernés sortent de la frontière des données européenne et soient traités, puis conservés 30 jours, dans des systèmes Anthropic hors UE.

When Anthropic models are used in Copilot experiences in Word, Excel, or PowerPoint, data processing for these models occurs outside of the Microsoft EU Data Boundary (EUDB).
Source : Copilot in Microsoft 365 apps with Anthropic models, Microsoft Learn

Microsoft reste discret sur l’emplacement physique exact, mais l’analyse de Directions on Microsoft apporte la précision qui manque : à la différence des modèles OpenAI qui tournent dans Azure, les données traitées par Claude sont transférées depuis Azure vers des serveurs Anthropic hébergés sur des datacenters AWS ou GCP situés principalement aux États-Unis.

Pour une organisation soumise au RGPD, c’est l’information à avoir en tête : ce ne sont ni vos datacenters, ni ceux de Microsoft en Europe. L’éditeur pourrait à terme étendre Claude à ses datacenters européens, mais aucun calendrier n’est annoncé à ce jour.

Le piège classique : croire que c’est un Claude comme les autres et l’ouvrir à tout le tenant d’un clic. Et son symétrique, moins connu : certaines fonctionnalités ne marchent que si Anthropic est activé, donc couper le subprocesseur après coup peut casser des usages déjà en place.

Les garde-fous qu’Anthropic met en face

Pour être juste, la rétention ne rime pas avec accès libre. La page officielle d’Anthropic détaille les protections : ses employés n’accèdent pas à vos conversations, sauf signalement pour risque grave ou demande écrite du client. Seuls quelques relecteurs habilités peuvent le faire, via un outillage qui empêche l’export, la copie ou le téléchargement, et chaque accès est inscrit dans un journal infalsifiable. Au-delà des 30 jours, suppression automatique. Les organisations éligibles peuvent en plus ajouter leurs propres clés de chiffrement et des journaux d’audit de transparence d’accès.

Anthropic employees cannot access your conversations unless they are flagged for potential serious harm or upon a customer’s written request.
Source : Data retention practices for Mythos-class models, Anthropic

La preuve par Microsoft

Le signal le plus parlant pour un admin ? Microsoft elle-même a restreint l’usage de Fable 5 pour ses propres salariés dans ses versions internes de GitHub Copilot, le temps que ses équipes juridiques évaluent la politique de rétention, tout en vendant le modèle à ses clients. Les autres modèles Claude, eux, restent disponibles en interne parce qu’ils tournent en Zero Data Retention. Quand l’éditeur qui distribue le modèle hésite à l’ouvrir à ses propres équipes, ça mérite votre attention.

Tous les autres modèles Claude restent accessibles, car ils fonctionnent sous les règles de Zero Data Retention (ZDR).
Source : The Verge, relayé par Les Numériques

Mon retour terrain : avant d’activer, posez la question à vos équipes conformité avec trois éléments concrets : données traitées hors EU Data Boundary, rétention de 30 jours non contournable (pas de ZDR) sous les conditions d’Anthropic, et conservation prolongée possible en cas de signalement. Limitez Fable 5 à un groupe pilote, excluez les données réglementées (RGPD, données client, code propriétaire), et documentez la décision pour l’audit.

7. Conclusion

Voilà, en deux réglages dans l’admin et un clic côté utilisateur, vous ouvrez l’accès au modèle le plus capable jamais proposé par Anthropic dans Copilot. Concrètement, vous gagnez un moteur taillé pour les tâches longues, l’analyse documentaire et le travail agentique, avec un repli automatique vers Opus 4.8 sur les sujets sensibles.

Les quatre pièges à retenir avant de cliquer :

C’est une preview : statut mouvant, comportements susceptibles d’évoluer.
C’est désactivé par défaut chez nous en UE, rien ne s’active tout seul.
L’usage impose une rétention de 30 jours, sans option Zero Data Retention, contrôlée par Anthropic et non par Microsoft.
Le traitement a lieu hors EU Data Boundary, dans des systèmes hors UE, à arbitrer avec vos équipes conformité.

Si votre cadre de conformité le permet, ouvrez un pilote sur un groupe restreint et comparez Fable 5 au modèle par défaut sur vos vrais dossiers. Foncez tester, mais les yeux ouverts sur le statut preview et les termes de rétention.

AVD/W365 : Redirections basées sur le contexte

Que peut bien dire le titre de cet article ? Vous avez peut être déjà entendu parler des Context-based Redirections à droite à gauche, vous savez vaguement ce dont ça parle, mais vous n’avez jamais mis les mains dedans ? Cet article est fait pour vous. On va dérouler, écran après écran, jusqu’à voir une redirection (presse-papiers, lecteurs, imprimante, USB…) s’activer pour une machine conforme et se couper net pour une machine non conforme.

Pour rappel, jusqu’ici une politique de redirection sur AVD ou Windows 365 était binaire : si vous bloquiez le presse-papiers (ou les lecteurs, l’USB, l’imprimante), c’était bloqué pour tout le monde, sur tous les appareils : le portable corporate conforme comme le téléphone perso en BYOD. La seule parade, c’était de maintenir deux host pools séparés.

Avec les Context-based Redirections, on peut enfin faire varier la redirection au niveau de chaque connexion, selon la conformité de l’appareil, le réseau, ou le rôle de l’utilisateur. Un seul host pool, deux comportements. C’est du Zero Trust appliqué à la redirection.

Attention : au moment où j’écris ces lignes, la fonctionnalité est en Public Preview. À tester en lab, pas en prod. Et elle n’est supportée que via les clients Windows App (Windows, web, Android, iOS, macOS), le bon vieux mstsc ne participe pas au mécanisme.

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

1. C’est quoi, les Context-based Redirections ?
2. Pourquoi maintenant ? Le durcissement par défaut depuis mi-2025
3. Comment ça marche : l’architecture en 3 couches
4. Pré-requis
5. Étape 0 : Débrayer les restrictions par défaut
6. Étape 1 : Créer le contexte d’authentification (c1)
7. Étape 2 : La policy d’accès conditionnel (les 3 cas)
8. Étape 3 : La policy Remote Connection Experience (et la variante AVD)
9. Pièges & retour terrain
10. Conclusion

1. C’est quoi, les Context-based Redirections ?

Concrètement, ça donne quoi ? C’est une capacité qui applique des politiques d’accès granulaires aux redirections client, en s’appuyant sur un contexte d’authentification Microsoft Entra. L’idée : la redirection n’est autorisée que si la session atteint le niveau de confiance exigé.

La redirection contextuelle permet aux organisations de contrôler le comportement de redirection en fonction des conditions d’utilisateur et de session.

À l’aide du contexte d’authentification, les administrateurs peuvent définir quand des fonctionnalités client spécifiques doivent être autorisées ou restreintes en fonction de facteurs tels que le rôle d’utilisateur, la conformité de l’appareil ou l’emplacement réseau.

Cela permet de s’assurer que les données sensibles sont accessibles uniquement lorsque la session répond au niveau de confiance requis.
Source : Context-based redirections (Preview) — Microsoft Learn

Le point que je veux marteler tout de suite, parce que je vais beaucoup parler du presse-papiers dans la démonstration : la fonctionnalité ne se limite pas au copier-coller. Microsoft documente quatre redirections pilotables par contexte d’authentification :

Clipboard : le presse-papiers (copier-coller texte, image, fichier… dans un sens ou dans l’autre).
Drive : les lecteurs locaux (fixes, amovibles, réseau) remontés dans la session distante.
Printer : la redirection d’imprimante.
USB : la redirection des périphériques USB.

Dans cet article, je teste le clipboard et les lecteurs, tout simplement parce que ce sont les deux redirections que j’avais déjà sous la main, restreintes via mes anciennes polices (j’y reviens juste en dessous). Mais le principe, l’enchaînement des trois couches, la logique d’évaluation à la connexion : tout est rigoureusement identique pour l’imprimante et l’USB. Si vous savez piloter le presse-papiers par contexte, vous savez piloter les quatre. Vous remplacez juste la redirection ciblée dans la dernière couche.

Pour info : la policy Remote Connection Experience expose chacune de ces redirections avec le même menu déroulant. Pour chaque ligne, vous choisissez « activé », « non configuré » ou « contexte d’authentification ». C’est ce dernier choix qui déclenche tout le mécanisme, et il se présente exactement de la même façon que vous soyez sur Clipboard, Drive, Printer ou USB.

2. Pourquoi maintenant ? Le durcissement par défaut depuis mi-2025

Petit détour utile pour comprendre pourquoi cette fonctionnalité tombe à pic. Depuis mi-2025, Microsoft a basculé d’une logique « tout ouvert, à vous de durcir » vers du secure by default : sur les nouvelles images Windows 365 et les nouveaux host pools AVD, les redirections (presse-papiers, lecteurs, USB, imprimantes) sont désactivées nativement. C’est aligné avec la Microsoft Secure Future Initiative (SFI).

J’ai déjà décortiqué ces deux sujets dans le détail, et je vous renvoie à mes articles précédents si vous voulez creuser le sujet :

Configurez le presse-papier dans AVD/W365 : le durcissement par défaut depuis le 18 juin 2025, la logique des deux couches (propriétés RDP côté client + polices GPO/Intune côté serveur), et le détail des niveaux SCClipLevel / CSClipLevel.
AVD : Restriction du Presse-papier : comment restreindre finement le copier-coller via Intune et les propriétés RDP, sens par sens et type de donnée par type de donnée.

Là où le bât blessait : cette restriction par défaut, bien qu’affinée, restait globale :

Au niveau des configurations RDP d’Azure Virtual Desktop :

Au niveau des polices de configuration Intune :

Une fois le presse-papiers (ou les autres) bloqué ou débloqué, il l’était pour toutes les connexions, sans distinction de l’appareil ou du réseau :

C’est exactement le mur que les Context-based Redirections font tomber : on garde la posture « fermé par défaut », mais on rouvre dynamiquement pour les connexions de confiance.

D’où l’enchaînement logique de cet article : on part d’un environnement où la redirection est restreinte, et on la rend conditionnelle :

3. Comment ça marche : l’architecture en 3 couches

C’est LE point à comprendre avant de cliquer partout. Le mécanisme repose sur trois couches qui s’enchaînent :

Le contexte d’authentification : un simple « jeton » d’exigence que l’on définit dans Entra et que l’on « publie ».
La policy d’accès conditionnel (CA) : elle cible ce contexte et impose une exigence (appareil conforme, réseau de confiance, MFA…). C’est elle qui décide si le claim c1 est émis ou non dans le token de session.
La policy Remote Connection Experience (RCE) côté Windows 365 (ou la propriété RDP du host pool côté AVD), qui lie une redirection donnée (clipboard, drive, printer ou USB) au contexte.

La logique de bout en bout, à la connexion :

La redirection est liée à c1 → elle est OFF par défaut, et ne s’allume que si le claim c1 est présent dans le token de session.
Le claim c1 n’est présent que si le step-up d’authentification pour c1 réussit.
Ce step-up réussit si aucune CA ne le bloque, ou si une CA qui le cible est satisfaite.

Mon retour terrain : la CA ne sert qu’à poser des exigences sur l’émission du claim c1. S’il n’y a aucune CA qui cible c1, rien ne bloque → le claim passe → vous avez vos redirections (selon ce que la RCE autorise). Dès qu’une CA cible c1, il faut la satisfaire ; si vous êtes bloqué par elle, le claim n’est jamais émis → redirection coupée. C’est aussi simple que ça, mais ça m’a pris un paquet de tests pour le formuler clairement.

4. Pré-requis

Brique	Ce qu’il vous faut
Poste de travail virtuel	Windows 365 Enterprise (Cloud PC) ou Azure Virtual Desktop
Identité & accès conditionnel	Microsoft Entra ID P1 (minimum) pour le Conditional Access
Gestion des stratégies	Microsoft Intune (config + RCE policy + conformité)
Client de connexion	Windows App (Windows / web / Android / iOS / macOS). Pas `mstsc`.
Image / agent	Cloud PC sur image récente prenant en charge la preview

Pré-requis à valider selon votre déploiement (W365 ou AVD).

5. Étape 0 : Débrayer les restrictions par défaut

Le piège classique, et il est sournois : sur les images récentes de Cloud PC (et les nouveaux pools d’hôtes AVD), les redirections client sont désactivées par défaut :

C’est précisément le durcissement dont je parlais à la section 2. Si vous laissez ça en l’état, vous allez croire que votre conf context-based « bloque bien »… alors qu’en réalité c’est juste le défaut restrictif qui parle. Et surtout : la policy la plus restrictive l’emporte. Tant qu’une stratégie restreint la redirection « en dur », le mécanisme context-based ne pourra jamais l’autoriser.

Si vous utilisez une image de galerie récente pour tester votre PC cloud ou si vous avez des stratégies existantes dans votre environnement qui affectent les redirections, modifiez-les avant le test, car la stratégie la plus restrictive l’emporte.

Par conséquent, vous devez définir les redirections que vous souhaitez tester pour qu’elles soient « non configurées » ou « activées » pour que la redirection basée sur le contexte fonctionne correctement.
Source : Context-based redirections (Preview) — Microsoft Learn

La parade : créer (ou réutiliser) une policy Settings catalog dans Intune qui remet les redirections que l’on veut tester sur Disabled au sens « Do not allow… = Disabled » :

Autrement dit, on désactive la désactivation, donc on autorise. 😅

Dans mon lab, je m’appuie justement sur le groupe et les polices que j’avais montés pour mes articles précédents sur le presse-papiers : c’est mon point de départ « fermé », que je vais rouvrir conditionnellement.

Pas à pas, dans Intune :

Intune → Devices → Manage devices → Configuration → Create → New Policy.
Plateforme : Windows 10 and later ; type de profil : Settings catalog → Create.
Basics : donnez un nom parlant et une description.
Configuration settings → + Add settings.

Pour le presse-papiers, les lecteurs et l’USB : recherchez Device and Resource Redirection, sélectionnez la catégorie, puis cochez les réglages à piloter :

Pour l’imprimante : recherchez Printer Redirection (catégorie distincte) et cochez les réglages voulus :

Basculez chaque réglage « Do not allow… » sur Disabled. On ne veut aucune interdiction « en dur » sur les redirections qu’on va confier au contexte
Scope tags (facultatif) → Next
Assignments : ciblez le groupe qui doit recevoir la policy → Next
Review + create → Create

Une fois la configuration poussée sur le poste, cela nous donne la configuration de registre suivante :

Pour info : sous le capot, ces réglages pilotent les valeurs de registre RDP côté session (par ex. fDisableClip pour le presse-papiers, fDisableCdm pour les lecteurs). « Débrayé à 0 » = redirection autorisée. Si vous voulez le détail de ces clés, des deux couches client/serveur et des niveaux SCClipLevel / CSClipLevel, tout est dans mon article Configurez le presse-papier dans AVD/W365.

6. Étape 1 : Créer le contexte d’authentification (c1)

Première vraie brique du mécanisme. Le contexte d’authentification, c’est ce « jeton d’exigence » qu’on va ensuite cibler depuis la CA et lier depuis la RCE. Pas à pas :

Entra (ou Intune → Devices) → Conditional Access → Authentication contexts
New authentication context
Donnez un nom et une description explicites
Cochez impérativement Publish to apps, puis choisissez une valeur dans le menu ID (ici c1)
Sauvegardez

Attention : si Publish to apps n’est pas coché, vous pourrez bien référencer c1 dans la RCE policy, mais il ne sera jamais sollicité à la connexion. Résultat : la CA reste en « Not Applied » et rien ne se déclenche. C’est l’oubli n°1.

7. Étape 2 : La police d’accès conditionnel (les 3 cas)

C’est ici que se joue la « condition de confiance ». Le squelette est toujours le même : la CA cible le contexte d’authentification c1 (dans Target resources, pas dans les conditions !), et c’est le Grant (ou l’exclusion) qui décide. Je vous donne trois cas de figure que j’ai testés.

Cas n°1 : Exiger un appareil conforme compliant

Le scénario BYOD par excellence : redirection autorisée depuis une machine gérée et conforme, coupée depuis une machine perso non gérée.

Conditional Access → Policies → New Policy :

Donnez un nom, puis des utilisateurs : All users sous Include (ou votre groupe de test) :

Target resources → menu Select what this policy applies to → Authentication context → cochez c1 :

Grant → Grant access → cochez Require device to be marked as compliant → Select.
Enable policy = On → Create.

Cas n°2 : Restreindre par adresse IP (Named location)

Ici on veut : redirection autorisée uniquement depuis un réseau de confiance (votre plage IP publique), coupée ailleurs.

Le point clé à intégrer : une location, c’est une CONDITION, pas un grant. On ne peut pas dire « autorise si IP de confiance ». La bonne logique est inversée : « Bloque c1 partout, SAUF depuis l’IP de confiance ».

D’abord, créez la Named location :

Conditional Access → Named locations → + New location (IP ranges)
Nommez-la et saisissez votre plage IP publique en CIDR (ex. 203.0.113.42/32)
Cochez Mark as trusted location si proposé → Create

Ensuite, la CA :

Users : All users (ou groupe de test)
Target resources → Authentication context → c1
Conditions → Locations : Include = Any location ; Exclude = Loc-Confiance
Grant → Block access → Select
Enable policy = On → Create

Attention : le Conditional Access voit l’IP publique de sortie du client. Derrière un NAT ou un proxy d’entreprise, c’est l’IP du NAT qu’il faut déclarer, pas celle du poste. Et si votre IP est dynamique (box FAI), le test peut « sauter » quand elle change. Élargissez la plage plutôt qu’un /32 figé.

Cas n°3 : Combiner conformité & adresse IP

Pourquoi pas les deux ? Pour exiger à la fois un appareil conforme et un réseau de confiance, deux approches :

Une seule CA : ciblez c1, Grant = Require device to be marked as compliant, ET ajoutez la condition Locations (Include = la location de confiance) pour ne l’évaluer que sur ce réseau. Hors réseau de confiance, prévoyez une seconde CA de blocage.
Deux CA qui ciblent c1 : une exige le compliant, l’autre bloque hors réseau de confiance. Comme toutes les CA ciblant c1 doivent passer, le claim n’est émis que si appareil conforme et sur réseau de confiance.

Mon retour terrain : quand plusieurs CA ciblent c1, elles se cumulent (« most restrictive wins » côté claim). Pour un test propre d’un seul cas, mettez les autres CA ciblant c1 sur Off le temps de l’essai, sinon vous ne saurez plus laquelle bloque.

8. Étape 3 : La police Remote Connection Experience (et la variante AVD)

C’est la couche qui lie une redirection au contexte c1. Côté Windows 365, ça passe par une policy Remote Connection Experience (preview). C’est aussi ici que vous décidez quelle(s) redirection(s) parmi les quatre (Clipboard, Drive, Printer, USB) vous confiez au contexte :

Intune → Devices → Manage Windows 365 Cloud PCs → Cloud PC Settings
Create → Remote Connection Experience (preview) :

Basics : nom et description de la police :

Dans Configuration settings → Device redirections, repérez la redirection à piloter (Clipboard, Drive, Printer ou USB) et choisissez Authentication context: Context-based redirection :
Dans le champ Entra Authentication context qui apparaît, sélectionnez c1.
Laissez les redirections non voulues sur Not configured.

Scope tags (facultatif) → Next :

Assignments → Add groups → sélectionnez un groupe de DEVICES (les Cloud PC), surtout pas un groupe d’utilisateurs → Next :

Review + create → Create :

Veillez à affecter cette stratégie d’expérience de connexion à distance Windows 365 à des groupes d’appareils (PC cloud), et non à des groupes d’utilisateurs.

La redirection basée sur le contexte étant appliquée au niveau de l’appareil, l’attribution de la stratégie aux utilisateurs n’applique pas le comportement de redirection attendu.
Source : Context-based redirections (Preview) — Microsoft Learn

Et sur AVD ?

Pas de RCE policy : la liaison se fait dans les propriétés RDP du host pool. Dans l’onglet Device redirection, au lieu d’un toggle activé/désactivé, vous choisissez « Dynamically configure using authentication context » et sélectionnez le contexte. La logique d’évaluation à la connexion est la même qu’en Windows 365.

9. Pièges & retour terrain

Le piège qui m’a rendu fou : la persistance du token Windows App : Windows App garde un token de session en cache. Tant que ce token vit, le résultat du step-up c1 (présent ou absent) est figé dedans. Vous pouvez changer la CA et la RCE mille fois, la session en cours ne réévalue rien. Il faut un token frais : vraie déconnexion/reconnexion. Ne perdez pas trois heures comme moi à modifier des policies : reconnectez-vous avec une session neuve.

Client non supporté : avec mstsc / Bureau à distance legacy, c1 n’est jamais demandé. Passez par Windows App.
Assignation RCE sur des users : la RCE/context-based s’applique au device. Assignée à un groupe d’utilisateurs, elle ne fait rien. Groupe de devices (Cloud PC) obligatoire.
« Publish to apps » oublié sur le contexte d’authentification → c1 jamais sollicité → CA « Not Applied ».
Restrictions par défaut non débrayées → « most restrictive wins » → la redirection reste coupée quoi que vous fassiez.
Direction du clipboard : le binding porte sur une direction précise (ex. « clipboard local disponible dans la session distante » = copie sur votre PC → colle DANS le Cloud PC). Testez bien la direction que vous avez liée à c1.
Propagation lente : comptez quelques minutes côté CA, et au premier déploiement la RCE peut nécessiter un redémarrage du Cloud PC avant d’être prise en compte.

10. Conclusion

Voilà, comment en 4 étapes, on est passé d’un Cloud PC tout neuf à une redirection dynamique qui s’adapte à la confiance de la connexion. Concrètement, ça donne quoi ? Un seul host pool / une seule conf, et la redirection (presse-papiers, lecteurs, mais aussi imprimante et USB sur exactement le même modèle) qui s’ouvre pour les machines conformes (ou sur le bon réseau) et qui se ferme pour le reste.

Le rêve du BYOD sans compromis. J’ai testé le clipboard et les lecteurs, mais gardez bien en tête que les quatre redirections se pilotent à l’identique : c’est la même mécanique de bout en bout.

Foncez tester en lab, c’est clairement l’une des évolutions sécurité les plus utiles de l’année sur AVD / Windows 365. Einfin pour aller plus loin : quelques lectures qui complètent bien le sujet, et que je vous recommande :

Context-based redirections (Preview) : la doc officielle Microsoft Learn, la source de vérité sur les quatre redirections pilotables.
Context-based redirection in Azure Virtual Desktop and Windows 365 — a practical guide (modern-euc.com) : un guide pas-à-pas très complet sur le même sujet.
Azure Virtual Desktop Introduces Context-Based Redirections — Big Hat Group (Kevin Kaminski) : la mise en perspective Zero Trust et BYOD, avec l’historique du durcissement AVD.
Configure Advanced Clipboard and Drive Redirection for AVD and Windows 365 — Dieter Kempeneers : pour creuser la configuration fine du presse-papiers et des lecteurs en amont du contexte.

Nouveau Azure File Share

Vous avez vu passer l’annonce Microsoft parlant d’une file share comme une ressource Azure de premier niveau et vous vous dites : mais attendez, les partages de fichiers existent depuis des années dans Azure, où est la nouveauté ? Cet article est fait pour vous. On va partir du modèle historique : le compte de stockage pour dérouler ce que change vraiment le nouveau provider Microsoft.FileShares, passé en GA en 2026, et surtout vous aider à trancher : vous migrez, ou pas encore ?

Azure Files introduit une nouvelle expérience de gestion des services de partage de fichiers, désormais généralement disponible, dans laquelle les partages sont déployés en tant que ressources Azure indépendantes et de niveau supérieur via le Microsoft.

Chaque partage de fichiers a des performances dédiées, la sécurité, la mise en réseau et la facturation, ce qui permet une meilleure isolation, des performances prévisibles et un suivi précis des coûts.

L’expérience améliore également considérablement la mise à l’échelle et l’efficacité, prenant en charge jusqu’à 10 000 partages par abonnement par région, un provisionnement plus rapide et une automatisation native cloud via des modèles ARM, des Bicep et des flux de travail CI/CD.

Il est actuellement disponible pour les partages NFS 4.1.

– Source : Microsoft Learn

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

1. Le malentendu : un type file share existe déjà
2. Avant : tout partait du compte de stockage
3. Après : Microsoft.FileShares, ressource de premier niveau
4. La démo : on crée un partage, écran par écran
5. Ce que vous gagnez concrètement
6. Les limites au jour du GA
7. Alors, je l’utilise ou pas ?
8. Conclusion

1. Le malentendu : un type file share existe déjà

C’est la première confusion qu’il faut lever, parce qu’on l’entend partout : « des partages de fichiers, Azure en propose depuis longtemps ». Vrai… et faux. Jusqu’ici, le partage de fichiers n’a jamais été une ressource Azure à part entière. C’était toujours un objet enfant, créé à l’intérieur d’un compte de stockage. La ressource Azure, celle que vous voyiez dans votre groupe de ressources, c’était le compte de stockage et pas le partage :

Cette nuance n’est pas de la sémantique : c’est elle qui explique 90 % des frictions qu’on va voir. Tant que le partage était un sous-objet, il héritait de tout ce qui appartenait au compte. Le nouveau modèle casse précisément cet héritage.

2. Avant : tout partait du compte de stockage

Pour rappel, jusqu’ici le schéma était le suivant : vous créiez un compte de stockage, vous choisissiez un SKU (général avec blobs/queues/tables, ou un SKU dédié file storage), puis vos partages SMB ou NFS sous ce compte. Tout partait de là, et c’est là que les ennuis commençaient.

Les limites sont partagées. IOPS, capacité provisionnée, débit : c’est le compte qui porte les plafonds, et tous les partages se les répartissent. Un partage gourmand peut pénaliser les autres.

Le control plane aussi est mutualisé. Créer, modifier, supprimer des partages, gérer les snapshots : ces opérations tapent dans des quotas au niveau du compte. À plusieurs administrateurs sur le même compte, ça devient un point de contention :

Le réseau est hérité. C’est le compte de stockage qui porte la configuration réseau. Vos private endpoints, vos règles, vous les héritez du compte, donc pas de granularité par partage :

La facturation est au niveau du compte. Bon courage pour faire du showback / chargeback propre par partage : il faut décortiquer une facture agrégée :

La clé de compte est toute-puissante. La fameuse account key donne accès à tout ce qui vit dans le compte de stockage. Côté sécurité, c’est un secret à très large rayon d’action :

Le piège classique : au moment de créer un compte de stockage, le nombre d’options (SKU, type, redondance, protocoles…) est tel qu’on ne sait plus exactement ce qu’on configure. Beaucoup de comptes finissent surdimensionnés ou mal typés « au cas où ».

3. Après : Microsoft.FileShares, ressource de premier niveau

Concrètement, ça donne quoi ? Microsoft introduit un nouveau provider de ressources, Microsoft.FileShares, et avec lui un nouveau type de ressource top-level : le partage de fichiers lui-même. Pas d’enfant, pas de parent compte de stockage. Vous créez directement un file share dans un groupe de ressources et un abonnement, vous lui donnez un nom, et c’est tout.

Nous annonçons la mise à disposition générale d’une nouvelle expérience de gestion des services pour les partages de fichiers SSD Premium (NFS), qui permet de créer, sécuriser, faire évoluer et facturer chaque partage de fichiers de manière indépendante, sans être lié à un compte de stockage.

Gestion familière et intuitive des partages de fichiers : l’expérience utilisateur s’aligne sur les modèles des NAS et des serveurs de fichiers sur site, ce qui améliore la convivialité par rapport au modèle classique.

Infrastructure-as-Code : définissez la nomenclature, la capacité, les IOPS, la mise en réseau, les balises et la sécurité dans des modèles Bicep ou ARM pour une automatisation simplifiée avec vos outils DevOps préférés.

Évoluez en fonction de la charge de travail : prise en charge de jusqu’à 10 000 partages de fichiers par abonnement et par région, avec une expérience de provisionnement des partages de fichiers 2,5 fois plus rapide.

Sécurité et réseau au niveau des partages : restrictions réseau, instantanés et chiffrement limités au partage individuel, ce qui permet de faire correspondre les limites d’isolation aux limites de la charge de travail.

Visibilité des coûts par partage : les compteurs de facturation s’affichent sous la ressource de partage de fichiers, ce qui permet aux équipes d’effectuer des refacturations précises, de suivre les coûts par charge de travail et d’améliorer la refacturation sans avoir recours à des solutions de contournement.

– Source : Microsoft Techcommunity

Au jour du GA, le périmètre est volontairement resserré :

Tier SSD uniquement
Protocole NFS 4.1 uniquement
Facturation alignée sur le modèle provisioned v2 SSD
Côté résilience, vous choisissez LRS ou ZRS
Capacité, IOPS et débit se provisionnent indépendamment

Azure file share using Microsoft.FileShares is now generally available… shares are deployed as independent, top-level Azure resources through the Microsoft.FileShares resource provider, removing the dependency on storage accounts.
Source : Microsoft Learn

4. La démo : on crée un partage, écran par écran

Assez de théorie, passons aux mains dans le cambouis. Le mieux pour comprendre ce qui change, c’est de dérouler la création d’un partage dans le portail. Vous allez voir : il n’y a plus jamais le mot « compte de stockage » dans le parcours.

Étape 0 : Le nouveau point d’entrée « File shares »

Depuis l’accueil du portail, vous cherchez directement File shares. C’est un hub à part entière, qui liste vos partages comme des ressources autonomes :

Étape 1 : Les bases : abonnement, groupe de ressources, nom

On clique sur Create. Et là, surprise par rapport au monde d’avant : on vous demande un abonnement, un groupe de ressources et un nom de partage. Point. Exactement comme pour n’importe quelle ressource Azure de premier niveau :

Étape 2 : Tier, protocole et résilience

Au GA, le choix est volontairement cadré : tier SSD et protocole NFS 4.1 imposés. La seule décision de résilience se fait ici, au niveau du partage : LRS (redondance locale) ou ZRS (redondance inter-zones) selon la région Azure choisie :

Étape 3 : Le cœur du sujet : capacité, IOPS et débit séparés

C’est l’écran le plus important. Vous provisionnez la capacité, les IOPS et le débit de façon indépendante. Plus de « budget commun » réparti entre tous les partages du compte : ce que vous réglez ici, ce sont les limites de ce partage, et de lui seul :

Le Calculateur de prix Azure vous permet de travailler ces valeurs, tout en mesurant l’impact sur le prix :

Étape 4 : L’onglet Advanced : root squash, chiffrement et nom de montage

C’est l’onglet qu’on a tendance à survoler, et c’est dommage, parce qu’il porte trois réglages qui changent la vie côté NFS :

Protocol → Root squash. C’est le mapping de l’identité root côté client NFS. Vous choisissez entre no root squash, root squash et all squash selon le niveau de confiance que vous accordez aux clients qui montent le partage.
Security → Require encryption in transit. Vous imposez le chiffrement du flux entre le client et le partage. À garder activé sauf raison impérieuse.
Other → Mount name. Vous donnez au partage un nom de montage différent du nom de la ressource Azure. Pratique pour garder des chemins de montage propres côté clients NFS sans vous imposer la convention de nommage Azure.

Mon retour terrain : le Mount name est le petit réglage que je règle systématiquement. Découpler le chemin de montage du nom de la ressource Azure vous évite de trimballer une convention de nommage cloud jusque dans vos fstab et vos scripts. Vos clients NFS gardent des chemins courts et lisibles.

Étape 5 : Le réseau, au niveau du partage

Autre changement de fond : la configuration réseau se fait ici, pas sur un compte parent. Vous décidez pour ce partage s’il est exposé en public endpoint ou enfermé derrière des private endpoints. Chaque partage a donc sa propre posture réseau :

Étape 6 : Review + create, le moment de vérité

On valide, on crée. Et là, magie : le partage apparaît dans le groupe de ressources comme une ressource Microsoft.FileShares à part entière, avec ses propres tags, son propre coût, son propre control plane :

Aucune clé de compte à aller récupérer quelque part, parce qu’il n’y en a tout simplement pas :

Du côté des performances et de la taille, tout est toujours rectifiable :

Et c’est là que le bât blesse. Du côté de la sauvegarde, un menu Snapshots est bien présent, mais il ne permet que des déclenchements manuels :

Plus inquiétant : le service de sauvegarde Azure Recovery Services vault ne le voit même pas :

Même chose pour les Backup vaults, qui ne sauvegardent pas ce type de stockage :

Et même le service Resiliency ne le détecte pas :

Attention ! la sauvegarde, c’est LE gros angle mort du GA : côté protection des données, on est à l’os. Le menu Snapshots existe, mais en déclenchement manuel uniquement : pas de planification, pas de rétention automatique. Pire, la ressource est invisible pour Azure Backup, ni le coffre Recovery Services, ni les Backup vaults ne la voient et elle n’apparaît même pas dans Resiliency. Autrement dit : aucune sauvegarde managée au GA. Si votre donnée a la moindre valeur, prévoyez votre propre stratégie (snapshots scriptés + copie hors-partage) en attendant que Microsoft branche la protection native.

Étape 7 : On monte le partage : la lame Connect

Mais avant d’aller plus loin dans la connexion, l’intégration réseau est obligatoire :

Mon réseau est à présent configuré sur celui de ma machine Linux via un Service Endpoint :

Reste à le monter côté client. La lame Connect du partage vous donne directement la commande de montage NFS, avec le bon endpoint et les bonnes options pré-remplis : vous n’avez qu’à la copier sur votre client Linux :

Téléchargez le paquet Microsoft correspondant à votre version d’Ubuntu, afin d’ajouter le dépôt officiel Microsoft (nécessaire pour installer ensuite des outils comme aznfs) :

curl -sSL -O https://packages.microsoft.com/config/$(source /etc/os-release && echo "$ID/$VERSION_ID")/packages-microsoft-prod.deb

Installez le paquet téléchargé, puis supprimez l’installeur :

sudo dpkg -i packages-microsoft-prod.deb
rm packages-microsoft-prod.deb

La commande sudo apt-get update met à jour la liste des paquets disponibles, puis sudo apt-get install aznfs installe le client Azure NFS (aznfs) depuis le dépôt Microsoft :

sudo apt-get update
sudo apt-get install aznfs

Créez le dossier /mount/jloshare qui servira de point de montage pour le partage NFS :

sudo mkdir -p /mount/jloshare

Montez le partage Azure Files en NFS sur votre point /mount/jloshare en utilisant le client optimisé aznfs, avec des options de performance et de compatibilité NFS 4.1 :

sudo mount -t aznfs fs-vlsw3zm2p5tvmn54j.z22.file.storage.azure.net:/fs-vlsw3zm2p5tvmn54j/jloshare /mount/jloshare -o vers=4,minorversion=1,sec=sys,nconnect=4

Affichez les systèmes de fichiers montés et filtrez pour vérifier que votre partage jloshare est bien monté :

df -h | grep jloshare

Depuis le portail Azure, la modification du volume du file share apparait immédiatement sur le partage :

5. Ce que vous gagnez concrètement

Le bénéfice tient en un mot : isolation. Tout ce qui était mutualisé au niveau du compte redescend au niveau du partage.

Performance dédiée : chaque partage a ses propres limites de capacité, d’IOPS et de débit. Plus de voisin bruyant qui mange votre budget perf.
Control plane par partage : les opérations (création, modification, suppression, snapshots) consomment un quota propre à chaque partage, sur un modèle de « seau » qui se recharge en continu. Les plafonds sont tellement hauts qu’en pratique, les blocages control-plane qu’on connaissait deviennent très improbables.
Réseau par partage : public endpoint, private endpoints : vous les configurez au niveau du partage, pas d’un compte parent qui impose ses règles à tout le monde.
Plus de clé de compte : il n’y a tout simplement pas d’account key toute-puissante. Le partage est sa propre ressource, avec sa propre surface de sécurité.
Facturation et tags granulaires : le coût est porté par le partage (capacité + IOPS + débit), avec ses propres tags. Le showback / chargeback devient enfin trivial.

Mon retour terrain : le gros gain au quotidien, ce n’est pas la perf brute, c’est la traçabilité des coûts et la fin de la clé de compte. Sur des environnements multi-équipes ou multi-projets, pouvoir taguer et facturer partage par partage change la vie des FinOps.

6. Les limites au jour du GA

Soyons honnêtes : « GA » ne veut pas dire « complet ». Le modèle est jeune, et plusieurs fonctionnalités qu’on tient pour acquises côté classique ne sont pas encore là. À l’heure où j’écris, il manque notamment :

La sauvegarde managée. C’est le point noir : au GA, vous n’avez que des snapshots manuels. Pas d’Azure Backup sur ce type de ressource, ni coffre Recovery Services, ni Backup vault ne le prennent en charge et il n’apparaît pas non plus dans Resiliency (voir la démo §4). La protection de la donnée est entièrement à votre charge.
SMB. C’est NFS 4.1 uniquement. Si vos workloads sont Windows/SMB (AVD + FSLogix, partages bureautiques…), ce modèle ne vous concerne pas encore.
CMK (clés gérées par le client), soft delete / corbeille, autres protocoles. Tout ça est annoncé comme « à venir », mais pas disponible au GA.

Attention ! FSLogix / AVD, ce modèle n’est pas pour vous aujourd’hui : au GA, c’est NFS 4.1 uniquement, et SMB n’est pas disponible. Or FSLogix exige du SMB (profils VHD/VHDX montés en SMB). Mécaniquement, vous ne pouvez pas poser vos profils FSLogix sur un partage Microsoft.FileShares pour l’instant. Pour de l’AVD, restez sur le compte de stockage classique en Azure Files SMB (provisioned v2 SSD). SMB est annoncé « à venir » sur ce nouveau modèle : le jour où il arrive, l’isolation par partage et la fin de l’account key deviendront très intéressantes pour de l’AVD multi-équipes, mais on n’y est pas.

7. Alors, je l’utilise ou pas ?

La règle est simple : si vos besoins rentrent dans le périmètre actuel, c’est le futur, foncez. Sinon, le classique fait toujours le job. Voici comment je le résume.

Votre besoin	Microsoft.FileShares (nouveau)	Compte de stockage (classique)
Protocole NFS 4.1	✅ Oui	✅ Oui
Protocole SMB	❌ Pas encore	✅ Oui
Tier SSD / HDD	✅ SSD / ❌ HDD	✅ SSD / ✅ HDD
Isolation perf / réseau / coût par partage	✅ Oui	❌ Mutualisé
Sans clé de compte	✅ Oui	❌ Clé présente
Snapshots manuels	✅ Oui	✅ Oui
Sauvegarde managée (Azure Backup, Recovery vault, Backup vault)	❌ Pas encore	✅ Oui
CMK / soft delete	❌ Pas encore	✅ Oui
IaC, CLI, PowerShell	✅ Oui	✅ Oui
Scale (partages / abo / région)	✅ 10 000	1 000

8. Conclusion

Voilà : cette « nouvelle ressource file share », ce n’est pas un énième renommage, c’est un vrai changement d’architecture. Le partage cesse d’être un sous-objet du compte de stockage pour devenir une ressource Azure de plein droit, avec sa perf, son réseau, sa sécurité et sa facture à lui. À la clé : une isolation propre, la fin de la clé de compte toute-puissante, un coût traçable partage par partage et une vraie compatibilité infrastructure-as-code.

Les trois pièges à retenir avant de vous lancer :

La sauvegarde, c’est le gros trou du GA : Snapshots manuels uniquement, et aucune prise en charge par Azure Backup (Recovery Services vault, Backup vault) ni par Resiliency. La protection de la donnée est à votre charge, n’y mettez rien de critique sans stratégie maison.
NFS 4.1 / SSD uniquement : pas de SMB (donc pas de FSLogix / AVD), pas de HDD.
Facturation provisioned v2 : dimensionnez correctement capacité, IOPS et débit, vous payez le provisionné.

Si vous êtes sur du NFS, foncez tester en lab : c’est clairement la direction que prend Azure Files. Pour le reste, le classique a encore de beaux jours devant lui, le temps que la sauvegarde managée, SMB et les autres briques manquantes débarquent.

Dernier point, et il pèse lourd dès qu’on dimensionne du provisionné : la capacité réservée, vous la payez. Autant ne pas voir trop large « au cas où » et faire grossir le partage automatiquement quand le besoin arrive.

C’est exactement le sujet que je creuse côté FSLogix. À lire dans la foulée : Autoscalez le stockage FSLogix : faire grossir automatiquement le quota de vos partages Azure Files.

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.