Bienvenue dans ce lab pratique consacré à Microsoft Foundry, la plateforme unifiée qui permet d’explorer, tester et déployer des expériences d’intelligence artificielle au sein de l’écosystème Azure. Cet article retrace pas à pas les différentes étapes du lab afin de permettre à chacun de revivre l’expérience ou de la reproduire en autonomie.
Lors du Chalet Azure Romandie du 27 novembre 2025, les participants ont pu découvrir concrètement comment manipuler des modèles avancés comme gpt-4o et Sora, créer leurs propres agents, générer des vidéos IA, ajouter des filtres de sécurité, traduire des documents, ou encore produire un avatar animé.
Voici donc les 5 défis que vous pouvez également essayer :
Pour réaliser cet exercice sur Microsoft 365 Archive, il vous faudra disposer d’une souscription Azure valide.
Ouvrez un navigateur web, puis saisissez l’URL du portail Azure AI Foundry (nouvellement Microsoft Foundry) :
Authentifiez-vous avec un e-mail professionnel ou personnel :
Une fois authentifiée, conservez l’ancienne présentation du portail de Microsoft Foundry, appelée encore Azure AI Foundry, afin de suivre les consignes ci-dessous plus facilement :
Commençons le premier défi par le déploiement d’un agent.
Défi I – Création d’un Agent Smith :
Nous allons déployer un agent qui s’appuiera sur le modèle gpt-4o et répondra aux différentes questions du défi.
Pour cela, cliquez-ici pour créer votre agent :
Mais comme aucun projet IA n’est encore présent, nous allons commencer par la création de celui-ici. Pour cela, renseignez les informations pour la création de votre nouveau projet IA, puis lancez sa création :
Dans le champ Projet, saisissez projet-agent
Développez options avancées
Choisissez la souscription Azure disponible
Donnez un nom unique à votre ressource Azure AI Foundry
Nommez rg-chalet-romandie le nom de votre groupe de ressource
Vérifiez que la région Azure East US 2 est bien sélectionnée
Attendez environ 2 à 3 minutes pour la fin de la création des ressources Azure :
Une fois le déploiement terminé, cliquez sur le menu Playgrounds afin de commencer par le déploiement d’un premier modèle IA, recherchez dans la liste le modèle gpt-4o, puis cliquez sur le bouton Confirmer :
Conservez les options de base de votre modèle, puis cliquez sur le bouton Déployer :
Une fois le modèle IA déployé, retournez dans le menu Playgrounds afin de lancer le prompt suivant sur le nouvel agent, automatiquement créé et lié à votre modèle :
Générer une blague sur les informaticiens
L’erreur suivante peut apparaître. Elle indique que les ressources IA ne sont pas encore entièrement accessibles :
Après plusieurs minutes et plusieurs essais, vous devriez obtenir une réponse dans le chat de la part de votre agent IA :
Votre défi est réussi, vous pouvez le faire valider, puis passez au défit suivant.
Défi II – Génération d’une vidéo IA :
Imaginez pouvoir créer des scènes vidéo réalistes, des animations et des effets spéciaux, à partir d’instructions textuelles simples et précises. Foundry vous permet de réaliser cette prouesse à l’aide du modèle Sora d’OpenAI.
La génération de vidéos dans ce cas est un processus asynchrone. Vous créez une demande de travail avec vos spécifications d’invite (ou prompt en anglais) de texte et de format vidéo, et le modèle traite la demande en arrière-plan.
Une fois terminé, récupérez la vidéo générée via une URL de téléchargement.
Cliquez sur le menu à gauche Playgrounds, puis le menu suivantafin de tester la génération de vidéos par l’IA :
Cliquez ici pour déployer un nouveau modèle IA destiné à la génération de la vidéo :
Choisissez le modèle Sora dans la liste, puis cliquez sur Confirmer :
Conservez les options de base, puis cliquez sur le bouton Déployer :
Une fois le modèle Sora déployé, retournez dans le menu Playgrounds afin de lancer le prompt de génération de la vidéo :
Sélectionnez la résolution 720p,une durée de 10 secondes, saisissez votre prompt qui générera une vidéo époustouflante, puis cliquez sur le bouton Générer.
Attendez quelques instants avant de pouvoir constater le résultat :
Après quelques instants, visionnez le résultat généré par Sora :
Votre défi est réussi, vous pouvez le faire valider, puis passer au défit suivant.
Défi III – Filtrage IA de contenu :
Microsoft Foundry embarque en standard les composants Azure AI Content Safety pour filtrer les contenus répréhensibles générés ou traités (détection de langage toxique, données personnelles partagées, etc…).
Nous allons créer un filtre et une liste de blocage basés sur le mot AWS. Nous allons dans un premier temps créer une liste de blocage :
Saisissez un nom représentant la liste, blocklistaws,puis cliquez sur le bouton suivant pour créer celle-ci :
Ajoutez un nouveau terme :
Saisissez le terme AWS, puis ajoutez-le :
Nous allons maintenant créer notre propre filtre de contenu et l’associer à notre liste de blocage. Pour cela, cliquez sur le bouton ci-dessous pour créer un filtre de contenu :
Saisissez un nom représentant le filtre, filtrereomandie, puis cliquez sur le bouton Suivant :
Dans l’étape Filtre d’entrée, pour chaque catégorie (haine, violence …), spécifiez le niveau de dureté appliqué à Highest blocking , cochez la case Liste de blocage, sélectionnez blocklistaws, puis cliquez sur Suivant :
Dans l’étape Filtre de sortie, pour chaque catégorie (haine, violence …), spécifiez le niveau de dureté appliqué à Highest blocking , cochez la case Liste de blocage, sélectionnez blocklistaws, puis cliquez sur Suivant :
Sélectionnez le modèle qui recevra ce filtre de contenu personnalisé, dans notre cas gpt-4o :
Confirmez le remplacement du filtrage de contenu de page par le nouveau :
Lancez la création du filtrage IA :
Retournez dans Playgrounds, puis cliquez sur Chat playground :
Collez le prompt suivant dans le chat :
Comment utiliser AWS ?
Un retour négatif de la part d’Azure IA Foundry, et invoquant blocklistaws, devrait apparaître. Continuez avec le prompt suivant :
Comment me faire très mal au bras ?
Un retour négatif de la part d’Azure IA Foundry, et invoquant Self-harm, devrait apparaître.
Votre défi est réussi, vous pouvez le faire valider, puis passer au défit suivant.
Défi IV – Traduction IA de documents :
La traduction automatique est l’un des domaines historiques de l’IA de Microsoft. L’entreprise propose un service de traduction basé sur des réseaux de neurones, connu sous le nom d’Azure AI Translator, capable de traduire instantanément du texte ou des documents entiers d’une langue à une autre.
Cliquez sur le menu suivant afin de générer une traduction de texte :
Cliquez sur Text translation :
Collez le texte suivant, choisissez le français comme langue de destination, puis lancez la traduction :
Azure Speech permet en résumé de tester et prototyper rapidement des fonctionnalités de reconnaissance vocale, conversion texte-vers-voix, traduction audio, etc., sans avoir à tout coder ou déployer de façon complète.
Cliquez sur le menu suivant afin de générer un avatar :
Choisissez le menu Text to speech avatar, puis cliquez sur Lisa parmi la liste des avatars disponibles :
Définissez la langue française, la voix de Vivienne, collez le texte ci-dessous, puis lancez la génération de la vidéo :
Romandie un jour, Romandie toujours.
Attendez quelques secondes la fin de la génération de la vidéo :
Une fois la vidéo générée, lancez-là pour en vérifier le contenu :
Une fois tous les défis terminés :
Conclusion
Ce parcours à travers Microsoft Foundry met en lumière la richesse des outils IA disponibles aujourd’hui : agents personnalisés, génération multimédia, filtrage de contenu, traduction, ou encore avatars vocaux.
Chaque défi illustre la maturité croissante de l’écosystème et la facilité avec laquelle il devient possible d’expérimenter, prototyper et imaginer de nouvelles solutions basées sur l’IA.
Que ce lab inspire de futurs projets et continue d’alimenter la dynamique d’innovation au sein de la communauté !
Depuis de longues années, la communauté Azure Virtual Desktop attendait la possibilité de déployer un environnement entièrement cloud, sans dépendance à un domaine Active Directory classique ou à une architecture hybride complexe. Cette évolution permet enfin d’envisager un modèle moderne, simplifié et résolument cloud-native.
Au-delà du progrès technique évident (principalement la simplification de l’infrastructure) cette nouveauté transforme aussi la manière d’aborder la gestion des accès distants et des profils utilisateurs.
Elle marque le passage d’un modèle traditionnel mêlant domaine Active Directory, synchronisation, et Kerberos hybride, vers un modèle entièrement cloud-only : plus léger, plus agile et parfaitement adapté aux organisations modernes, aux partenaires externes ou encore aux environnements projet éphémères.
Cette annonce fut d’ailleurs intégrée à celle des identités externes sur AVD et Windows 365 :
Pour offrir une expérience simplifiée dans un environnement mutualisé Azure Virtual Desktop pour les identités externes, vous pouvez créer un partage de fichiers dans Azure Files afin de stocker les profils FSLogix pour ces identités.
Cette fonctionnalité est désormais disponible en préversion publique. Pour créer un partage de fichiers SMB pour les profils FSLogix pour les identités externes :
Créez un nouveau compte de stockage et un nouveau partage de fichiers configurés pour utiliser l’authentification Microsoft Entra Kerberos.(Nouveau) Lorsque vous attribuez des autorisations pour le partage de fichiers, utilisez la nouvelle page Gérer l’accès pour attribuer des listes de contrôle d’accès (ACL) au groupe Entra ID contenant vos identités externes.
Microsoft illustre également cette nouveauté avec une copie d’écran montrant la gestion native des droits NTFS d’un partage Azure Files directement depuis le portail Azure, ce qui constitue une avancée très attendue :
Qu’est-ce qu’une identité cloud-only ?
Il s’agit d’un utilisateur géré uniquement dans Entra ID, sans représentation dans un Active Directory on-prem, ni synchronisation : idéal pour des contractors, partenaires, ou utilisateurs externes.
Est-ce que FSLogix fonctionne avec ces identités externes / cloud-only ?
Oui, le support FSLogix pour cloud-only & external identities est désormais en preview, ce qui permet de gérer les profils utilisateurs de façon identique à un utilisateur « classique ».
Que change concrètement pour un architecte cloud ou un administrateur ?
Cela signifie moins de dépendances à un AD on-prem, moins de complexité, une gestion simplifiée des utilisateurs externes ou contractors, et un modèle plus cloud-native.
Plusieurs vidéos sont également disponible pour vous aider à la tâche :
Pour y parvenir, plusieurs documentations sont disponibles afin de mettre en place toute la chaîne. Le premier guide Microsoft explique comment activer Kerberos Entra sur Azure Files, tandis que le second part de ce socle et donne seulement ce qu’il faut ajouter pour FSLogix :
Je vous propose donc de passer en revue, étape par étape, l’ensemble de la configuration permettant de tester cette nouvelle fonctionnalité encore en préversion.
L’objectif est de comprendre son fonctionnement réel, ses limites et les scénarios dans lesquels elle pourra s’intégrer :
Pour réaliser ce test FSLogix en mode 100% Cloud-only, il vous faudra disposer de :
Un abonnement Azure valide
Un tenant Microsoft
Afin d’être sûr des impacts de nos différentes actions, je vous propose de commencer par la création d’une nouvel utilisateur 100% Cloud, donc non synchronisé à un environnement Active Directory.
Etape I – Préparation de l’environnement :
Création d’un utilisateur cloud-only pour préparer l’environnement sans synchronisation AD :
Mise en place du réseau virtuel qui servira de base à l’environnement Azure Virtual Desktop :
Déploiement d’un compte de stockage Azure Files Premium pour accueillir les profils FSLogix :
Activation de l’identité Microsoft Entra directement sur le compte de stockage :
Activation du support Microsoft Entra Kerberos pour gérer l’authentification :
Application des permissions par défaut via le rôle Storage File Data SMB Share Contributor :
Création du partage de fichiers pour FSLogix, avec l’identité Microsoft Entra toujours active :
Recherche de l’application d’entreprise générée automatiquement pour ce compte de stockage :
Attribution du consentement administrateur global pour autoriser l’application
Validation de l’autorisation accordée à l’application d’entreprise :
Vérification des permissions héritées depuis l’admin consent sur l’application liée au stockage :
Retrait du compte de stockage dans les polices d’accès conditionnel exigeant une MFA :
Création d’un environnement Azure Virtual Desktop avec deux machines virtuelles :
Activation du Single Sign-On directement dans les propriétés RDP :
Exécution du premier script PowerShell via Run Command pour activer la récupération du ticket Kerberos :
Vérification de la création des clés de registre attendues pour FSLogix :
Alternative via Intune pour gérer ces mêmes paramètres sans script :
Redémarrage des machines virtuelles du host pool pour appliquer la configuration :
Etape II – Test de connexion AVD :
Attente du retour en ligne des machines dans l’environnement AVD :
Activation du mode de drainage sur la seconde machine pour préparer les tests :
Connexion avec l’utilisateur de test pour valider le fonctionnement :
Observation du démarrage du service FSLogix App Services à l’ouverture de session :
Création du dossier de profil FSLogix directement dans le file share :
Présence du fichier VHDx correspondant au profil utilisateur :
Impossibilité de supprimer le fichier VHDx car il est monté et en cours d’utilisation :
Confirmation dans les logs FSLogix que le profil VHDx est correctement chargé :
Inversion du mode de drainage sur les deux machines AVD :
Reconnexion avec l’utilisateur de test pour valider la bascule du profil :
Montage d’un partage réseau pour inspecter le contenu du partage de fichier Azure :
Vérification que la permission générée pour l’utilisateur de test est bien présente :
Afin de finaliser correctement la configuration des permissions pour les profils FSLogix, il est nécessaire de les restreindre pour plus de sécurité.
Etape III – Configurations des permissions NTFS Access Control Lists:
Depuis l’explorateur Windows, je constate que certaines permissions restent visibles, alors qu’elles ne devraient être retirées pour des questions de sécurité :
Je constate également l’impossibilité de modifier les permissions directement depuis Windows ou via une commande ICACLS :
Travis Roberts rencontre d’ailleurs le même souci que moi :
Pour configurer les Windows ACLs, il sera donc nécessaire de passer par le menu Manage Access, visible depuis un portail Azure en préversion, comme le recommande Microsoft dans la documentation :
Le bouton Manage access est alors visible juste ici :
Ce menu n’est d’ailleurs pas visible dans le portail classique d’Azure :
L’affichage des permissions NTFS Access Control Lists configurées par défaut :
Les permissions pour FSLogix doivent alors être reconfigurées comme telles :
Cela donne ceci sur le partage de fichier FSLogix :
Les tests initiaux montrent que l’intégration fonctionne correctement entre FSLogix et Azure Virtual Desktop. Toutefois, quelques écarts apparaissent encore entre la documentation Microsoft et le comportement observé dans mon environnement, ce qui mérite d’être signalé dans le cadre de cette préversion.
Pour compléter mon analyse, il est intéressant de comparer les performances (IOPS et Throughput) entre plusieurs types de stockage, notamment ceux intégrés avec Entra ID.
Etape IV – Tests de performances :
J’ai souhaité comparé les performances entre différents types de stockage afin de bien comprendre l’impact ou non des performances avec cette jointure à Entra ID :
Partage de fichiers sur un compte de stockage Premium joint à Entra ID
Partage de fichiers sur un compte de stockage Premium non joint à Entra ID
Disque Premium SSD v2, configuré avec 30000 IOPS et 1200 de Throughput
Pour réaliser les mesures, nous utiliserons l’outil Diskspd :
DISKSPD est un outil que vous pouvez personnaliser pour créer vos propres charges de travail synthétiques. Nous utiliserons la même configuration que celle décrite ci-dessus pour exécuter des tests d’évaluation. Vous pouvez modifier les spécifications pour tester différentes charges de travail.
Microsoft recommande d’utiliser l’utilitaire DiskSpd (https://aka.ms/diskspd) pour générer une charge sur un système de disques (stockage) et … pour mesurer les performances du stockage et obtenir la vitesse maximale disponible en lecture/écriture et les IOPS du serveur spécifique.
Sur votre machine virtuelle de test, téléchargez l’exécutable via ce lien Microsoft, puis ouvrez l’archive ZIP téléchargée :
Copiez le contenu de l’archive dans un nouveau dossier créé sur le disque C :
L’exécutable se trouve dans le sous-dossier amd64 :
Les 2 étapes suivantes sont dédiées aux tests de performances des disques via l’application Diskspd. Microsoft met d’ailleurs à disposition un protocole similaire de tests juste ici :
Deux séries de tests sont conseillées pour exploiter le deux caractéristiques suivantes :
IOPS
Débit
Le changement entre ces deux séries se fera au niveau de la taille des blocs.
Commencez une première salve de tests pour déterminer les IOPS max pour chacun des espaces de stockage :
Partage de fichiers sur un compte de stockage Premium joint à Entra ID :
Partage de fichiers sur un compte de stockage Premium non joint à Entra ID :
Disque Premium SSD v2 configuré avec 30000 IOPS et 1200 de Throughput :
Ouvrez Windows PowerShell ISE, puis lancez les commandes des test suivantes, une à une ou à la chaîne, en modifiant les paramètres si besoin :
Les arguments utilisés pour diskspd.exe sont les suivants :
-d900 : durée du test en secondes
-r : opérations de lecture/écriture aléatoires
-w100 : rapport entre les opérations d’écriture et de lecture 100%/0%
-F4 : nombre de threads max
-o128 : longueur de la file d’attente
-b8K : taille du bloc
-Sh : ne pas utiliser le cache
-L : mesure de la latence
-c50G : taille du fichier 50 GB
E:\diskpsdtmp.dat : chemin du fichier généré pour le test
> IOPS-AvecEntra.txt : fichier de sortie des résultats
Une fois tous les tests terminés, les résultats sont alors compilés pour les 3 stockages :
Scenario
IOPS
Bandwidth MB/s
Avec Entra ID
12,446.88
299.95
Sans Entra ID
15,032.54
341.17
Premium SSD v2
20,378.31
1,167.25
Les résultats montrent que le Premium SSD v2 délivre les meilleures performances dans ton environnement, avec le plus haut niveau d’IOPS et de bande passante, suivi par le scénario Sans Entra ID, puis par le scénario Avec Entra ID qui obtient systématiquement les valeurs les plus faibles.
La différence entre les scénarios avec et sans Entra ID pourrait s’expliquer par la présence d’une couche d’authentification et de gestion de profils qui ajoute des opérations supplémentaires lors des accès disque, en particulier si le système doit interroger un service distant, valider un token, ou maintenir une session d’identité pour chaque opération liée au profil utilisateur.
Même si cette charge reste faible en théorie, elle peut introduire une latence additionnelle dans un flux d’I/O intensif, ce qui réduirait mécaniquement les IOPS et la bande passante observées.
Conclusion
Le support des identités cloud-only et externes pour Azure Virtual Desktop, associé à l’intégration de FSLogix, représente une évolution majeure dans l’écosystème Microsoft. Cette approche permet désormais de déployer des environnements VDI complets sans aucune dépendance à Active Directory, tout en simplifiant considérablement l’architecture.
Cette modernisation apporte davantage de flexibilité, réduit les contraintes opérationnelles et ouvre la voie à de nouveaux scénarios cloud-native, adaptés aussi bien aux entreprises qu’aux équipes projet, partenaires ou prestataires externes.
Bien que la fonctionnalité soit encore en préversion, elle laisse entrevoir un futur où les environnements virtualisés seront plus simples, plus économiques et mieux intégrés à l’identité Microsoft Entra.
Microsoft 365 Copilot évolue constamment, et à un rythme très soutenu. Comme beaucoup, j’ai du mal à suivre ces changements en temps réel, car plusieurs facteurs entrent en jeu. D’abord, le temps nécessaire pour se tenir à jour représente déjà une contrainte importante. S’y ajoutent la diversité des canaux de communication utilisés par Microsoft pour annoncer les nouveautés, ainsi que les disparités de déploiement : certaines fonctionnalités sont disponibles plus tôt dans certains tenants ou pays que dans d’autres. Bref, chacun fait comme il peut, et c’est déjà pas mal.
Cela étant dit, j’aimerais prendre un moment pour faire le tour de quelques nouveautés que je trouve particulièrement intéressantes. Ces informations proviennent à la fois des notes officielles de Microsoft et de certaines chaînes YouTube qui font, il faut le reconnaître, un excellent travail de vulgarisation et de démonstration :
Mon objectif est donc de partager avec vous certaines de ces découvertes et, lorsque c’est possible, d’y ajouter quelques retours issus de mes propres tests :
Depuis plusieurs mois maintenant, GPT‑5 est désormais intégré comme modèle principal pour Copilot. L’utilisation de GPT-5 permet une réponse plus riche : meilleure compréhension du contexte, capacité à traiter des documents volumineux ou complexes :
Copilot Chat est en train de passer au dernier modèle d’IA générative d’OpenAI, le modèle GPT-5, en tant que LLM principal de prise en charge. Essayez GPT-5 avec vos invites Copilot en sélectionnant le bouton Essayer GPT-5 en haut à droite dans Copilot Chat.
Vous pouvez utiliser le bouton Essayer GPT-5 dans Copilot Chat que vous disposiez ou non d’une licence Microsoft 365 Copilot, mais l’accès peut être limité en période de forte charge.
L’activation du mode GPT-5 est visible en haut à droite de Copilot :
Quelques remarques :
Vous devez activer GPT-5 pour chaque nouvelle conversation.
Vous pouvez activer GPT-5 même après avoir commencé à saisir votre premier prompt, et cela sans en perdre la saisie,
Il n’est pas possible de basculer sur GPT-5 dès que la conversation a démarré.
Une fois GPT-5 activé, la conversation continuera de travailler avec lui :
Voici un exemple de prompt que je souhaite poser à GPT-4 et GPT-5 pour voir leur réponse et les comparer :
Agis comme un architecte cloud senior chargé de présenter à la direction d’une entreprise internationale (800 employés, multi-sites, multi-fuseaux) une proposition stratégique complète pour moderniser son environnement Microsoft 365.
Contexte : L’entreprise a une infrastructure hybride (Active Directory local, Exchange on-premises, quelques workloads déjà sur Azure).
Les équipes utilisent encore des outils locaux (fichiers partagés, VPN, emails internes) et peinent à collaborer efficacement à distance.
La direction veut réduire les coûts, améliorer la sécurité, et accélérer la collaboration avec Microsoft 365 et Azure AD/Entra ID.
Tâche :
- Rédige un document de cadrage exécutif présentant :
- Une synthèse stratégique (valeur métier, enjeux, risques, bénéfices attendus)
- Une proposition d’architecture cible (identités, sécurité, collaboration, données, gouvernance)
- Un plan de transformation (étapes, jalons, gouvernance projet, rôles, communication interne)
- Des indicateurs de succès (KPIs), différenciant la vision IT et la vision métier
- Une conclusion exécutive résumant l’impact global de la transformation
Contraintes :
- Rédige avec un ton professionnel, synthétique et narratif.
- Le document doit sembler prêt à être présenté à un COMEX.
- Utilise la mise en page Markdown avec des titres, sous-titres et éventuellement des tableaux synthétiques.
- Sois précis mais fluide : évite les listes sèches et ajoute des transitions naturelles.
Et cela nous permet de sortir une comparaison des réponses données par Copilot en fonction de ces deux modèles, vu par ChatGPT :
Avec le même prompt, GPT-4 fait un très bon travail de structuration technique, il produit un livrable cohérent et complet.
GPT-5, lui, comprend le contexte exécutif : il ne se contente pas d’empiler des points, il raconte la transformation, hiérarchise l’information, et adapte le ton à une audience de direction.
Pourquoi devoir recliquer à chaque fois ?
Cela peut paraître agaçant, mais le bouton existe pour des questions économiques : cela permet d’éviter une activation automatique, et donc une meilleure maîtrise des coûts et des performances.
Fonctionnalité II – Explorer avec l’agent Researcher :
L’agent Researcher de Microsoft 365 Copilot s’apparente à un assistant de recherche avancé, spécialement conçu pour traiter des tâches complexes et multi-étapes.
Plutôt que de se contenter d’une réponse rapide à une question, l’agent Researcher croise vos contenus professionnels (documents, courriels, discussions, fichiers) avec des sources web fiables pour produire un rapport structuré : sections thématiques, visuels (graphiques, tableaux), et citations explicites des sources.
Researcher est donc particulièrement utile quand il s’agit de faire de la veille technologique, un benchmark, une analyse d’un domaine, ou l’élaboration d’un dossier que l’on pourra partager ou présenter :
Il diffère de la fonction de “chat classique” de Copilot : alors que celle-ci vise rapidité, synthèse simple ou support conversationnel, Researcher est optimisé pour un travail en profondeur avec plus de réflexion, plus de temps de traitement et un livrable plus riche.
Quand privilégier Research par rapport Chat classique :
Si tu dois préparer une réunion, un dossier stratégique ou un benchmark, Researcher va compiler et croiser les informations pertinentes bien au-delà de ce que le chat classique peut proposer.
Pour toute question nécessitant de vérifier, nuancer ou justifier avec des sources croisées et fiables, Researcher est clairement plus adapté.
Lorsque la rapidité n’est pas la priorité et qu’il te faut de la profondeur, de la précision et une vue d’ensemble.
Peut-être que le second agent, Analyst, pourrait aussi vous être utile :
Fonctionnalité III – Partagez vos prompts avec vos équipes
Historiquement, Microsoft 365 Copilot permettait déjà de sauvegarder des prompts dans une galerie personnelle, offrant ainsi la possibilité de retrouver facilement ses requêtes récurrentes et de les réutiliser :
Cette fonctionnalité a évolué pour aller plus loin : désormais, il est possible non seulement de conserver ses prompts, mais aussi de les partager avec une équipe, favorisant la collaboration et la cohérence dans l’usage des prompts au sein d’un groupe.
Commencez par sauvegarder un prompt dans la galerie personnelle :
Retournez dans la galerie afin de partager :
Sélectionnez d’une équipe spécifique :
Cela crée un nouvel onglet dans la galerie montrant les prompts partagés dans la galerie aux équipes :
Fonctionnalité IV – Activez Claude dans M365 Copilot :
Claude est un modèle d’intelligence artificielle développé par Anthropic, conçu pour offrir des capacités avancées de génération de texte, d’analyse et d’assistance contextuelle. Il se distingue par son approche axée sur la sécurité et la transparence, ce qui en fait un outil fiable pour les entreprises souhaitant intégrer l’IA dans leurs processus.
Depuis peu, il est possible d’activer Claude via le portail Microsoft 365 Admin Center. Cette fonctionnalité permet aux administrateurs de rendre Claude disponible pour les utilisateurs en quelques clics :
Une fois activé, le statut change dans la console, confirmant que Claude est opérationnel :
Voici l’interface avant activation, sans le bouton Claude :
Voici l’interface après activation, avec le bouton Claude :
Voici l’interface avec utilisation du modèle Claude :
Je souhaite en savoir un peu plus sur lui-même, et donc je lui pose la question sur le modèle utilisé :
Il en ressort plusieurs pistes de modèles envisagés :
Attention néanmoins une chose importante :
Lorsque votre organisation choisit d’utiliser un modèle Anthropic, elle accepte de partager ses données avec Anthropic afin d’alimenter les fonctionnalités. Ces données sont traitées en dehors de tous les environnements et contrôles d’audit gérés par Microsoft ; par conséquent, les accords clients de Microsoft, y compris les Conditions des produits et l’Addendum relatif au traitement des données, ne s’appliquent pas.
Pour évaluer l’impact de Claude, un prompt a été testé avec et sans Claude :
Who are the key players on the [Stade Toulousain / La Rochelle] rugby team, and what are their 2025 Top 14 stats — including appearances, tries, tackles, points, and how long they've been with the club?
Prompt avec Researcher et Claude :
Prompt avec Researcher sans Claude :
L’objectif est de comparer les réponses et d’identifier les différences de raisonnement entre Research, et Research + Claude via l’analyse de chatGPT-5 :
Ce test met en évidence la valeur ajoutée de Claude en termes de précision et de contextualisation :
Critère
Key Players and 2025 Top 14 JLO.docx
Key Players and 2025 Top 14 ANNA.docx
Structure du texte
Explicative, incomplète, avec excuses techniques.
Structurée, complète, avec tableaux et données détaillées.
Niveau de données
Généralités (meilleurs marqueurs du championnat, sources officielles citées, pas de chiffres précis par joueur).
Statistiques chiffrées par joueur, par équipe (apparitions, essais, plaquages, points, année d’arrivée).
Style de ton
Excuses, proposition d’alternatives, formulation prudente et narrative.
Informatif, orienté data, structuré en tableaux avec contexte analytique.
Sources citées
LNR.fr, All.Rugby, Ultimate Rugby, RugbyPass (mais sans données concrètes).
LNR.fr et sources officielles, mentionnées à la fin de chaque section.
Degré de complétude
Faible : pas de données par joueur.
Élevé : tableau complet pour Toulouse et La Rochelle.
Langage
Rédigé à la première personne (“I apologize”, “Would you like me to…”).
Neutre et objectif (“Below is the full Toulouse squad…”).
Style d’IA reconnaissable
Typique d’un agent de type Claude (Anthropic) : ton empathique, explicatif, s’excuse pour limitations.
Typique d’un agent Research classique / GPT : structuration analytique, données brutes et tables.
chatGPT-5 identifie très facilement le fonctionnement de Researcher avec et sans Claude :
Fichier
Type probable de génération
Justification
Key Players and 2025 Top 14 JLO.docx
🧠 Claude (Anthropic)
Ton conversationnel, excuses, impossibilité d’accéder aux données, approche narrative typique d’Anthropic.
Key Players and 2025 Top 14 ANNA.docx
🔍 Research classique (type OpenAI)
Présentation analytique, structuration en tableaux complets, ton factuel et format de rapport structuré.
Fonctionnalité V – Créez une conversation de groupe Teams à la suite de prompts :
Une fois la conversation démarrée avec Copilot, un bouton apparaît en haut à droite. Il permet la création nouveau groupe de conversation avec l’IA et d’autres personnes :
Copilot vous demande le nom des participants à ce nouveau groupe de conversation, ainsi que la longueur de l’historique de conversation Copilot :
Une fois le nouveau groupe de conversation créé, celui-ci est accessible directement depuis Teams :
Les membres de ce nouveau groupe de conversation sont visibles et l’IA en fait bien partie :
Fonctionnalité VI – Activer le programme Microsoft Frontier pour Copilot :
Le mode Frontier n’est pas une simple option, mais fait partie d’un programme Microsoft d’initiative d’accès anticipé aux fonctionnalités expérimentales de Microsoft 365 Copilot :
Il permet aux utilisateurs sélectionnés (avec une licence Copilot) de tester des capacités IA avancées avant leur disponibilité générale.
L’objectif est de recueillir des retours pour améliorer les fonctionnalités avant leur lancement officiel.
Les fonctionnalités Frontier sont disponibles pour tous les clients Microsoft 365 disposant d’une licence Copilot. Les paramètres d’administration de votre organisation peuvent déterminer qui peut accéder et utiliser les fonctionnalités Frontier.
De plus, les personnes ayant un abonnement Microsoft 365 Personnel, Famille ou Premium peuvent également accéder et utiliser les fonctionnalités Frontier.
Il existe deux principales façons d’essayer les fonctionnalités Frontier :
Agents Frontier : Suivez les étapes indiquées dans « Accéder aux agents Frontier ».
Fonctionnalités principales des applications Microsoft : Suivez les étapes indiquées dans « Accéder aux fonctionnalités principales des applications Microsoft ».
L’activation du mode Frontier se fait via le portail Microsoft 365 Admin Center. Cette fonctionnalité permet aux administrateurs de le rendre disponible pour certains utilisateurs en quelques clics :
Définissez les utilisateurs concernés par les tests de Frontier :
Il faut compter plusieurs heures avant de voir apparaître les agents et les modes agents apparaître dans les environnements de vos utilisateurs :
Voici par exemple les agents Frontier disponibles :
L’autre fonctionnalité est le mode agent, disponibles sur Word ou Excel :
Le mode agent dans Word vous permet d’utiliser Copilot de manière plus interactive. Dites simplement à Copilot ce que vous voulez, par exemple « résumer les commentaires récents des clients et mettre en évidence les tendances clés », et il rédigera, affinera et mettra en forme votre document pour vous.
L’écriture devient une conversation : vous vous concentrez sur vos idées et Copilot gère les détails avec les styles et la mise en forme intégrés de Word.
Il est possible de demander à Copilot de rédiger, reformuler ou compléter des sections. L’IA pose des questions pour clarifier et améliore le contenu jusqu’à ce que l’on soits satisfait. C’est ce que Microsoft appelle le vibe writing :
Le mode Agent transforme Word en un espace de travail interactif où tu peux collaborer avec l’IA de manière conversationnelle, plutôt que par des commandes ponctuelles :
Fonctionnalité VII – Créez vos applications grâce à l’agent App Builder :
App Builder est un agent intégré à Microsoft 365 Copilot, disponible via le programme Frontier :
App Builder, un agent qui fonctionne avec Microsoft Copilot, transforme vos idées en applications. Aucun codage requis ! Il suffit de décrire ce dont vous avez besoin, et une application personnalisée est générée pour vous.
Quels types d’applications pouvez-vous créer ? Les possibilités sont infinies : créez une application RSVP pour des événements, une application de gestion des dépenses pour soumettre vos frais, une application pour organiser et gérer des scrums, et bien plus encore !
Depuis le portail Microsoft 365 Chat, vous pouvez ajouter cet agent très facilement :
Il suffit ensuite de lui demander de créer votre application, comme « Crée une app pour suivre les incidents » :
Et l’agent commence à se mettre au travail :
Quelques minutes plus tard, un premier résultat apparaît :
Comme avec tout autre agent, la conversation doit continuer afin de lui demander de faire des améliorations ou des corrections :
Un site SharePoint est même créé afin de stocker les informations de l’application, sous forme de listes :
Je teste l’application via l’ajout d’une nouvelle saisie, puis je sauvegarde :
La nouvelle saisie est bien présente :
Elle est également retranscrite dans la liste SharePoint :
Certaines demandes se terminent en erreur, mais App Builder arrive à effectuer les corrections :
Une fois l’application terminée, je peux mettre à jour la nouvelle version si je suis satisfait des modifications :
Pour le moment, l’application créée via App Builder reste uniquement accessible via ce dernier, mais peut être lancée, partagée ou modifiée :
Conclusion
À travers ces différentes fonctionnalités, une tendance se dessine : Microsoft 365 Copilot devient moins un simple assistant conversationnel et davantage un environnement complet d’agents capables d’explorer, d’analyser, de créer et de collaborer au rythme des besoins.
Les modèles disponibles, les capacités étendues de Researcher, l’arrivée d’App Builder ou encore l’ouverture aux modèles tiers enrichissent l’écosystème, tout en demandant une veille constante tant les évolutions sont rapides.
Ce panorama illustre surtout une chose : chacun peut désormais adapter Copilot à ses usages, qu’il s’agisse de mieux comprendre un sujet, de structurer un livrable, d’automatiser un processus ou de tester des fonctionnalités avant leur mise à disposition générale.
Depuis la mi-2025, Microsoft renforce progressivement les paramètres de sécurité par défaut dans ses environnements Windows 365 et Azure Virtual Desktop (AVD). L’un des changements les plus visibles pour les administrateurs et utilisateurs concerne la redirection du presse-papiers (clipboard), désormais désactivée par défaut dans les nouvelles configurations.
Cette évolution, alignée avec la Microsoft Secure Future Initiative (SFI), vise à limiter les risques d’exfiltration de données et à uniformiser la posture de sécurité entre Windows 365 et AVD. Mais concrètement, comment ce changement s’applique-t-il ? Quels paramètres contrôlent réellement le comportement du presse-papiers ? Et comment vérifier la configuration effective entre les deux couches (Propriétés RDP et stratégies GPO/Intune) ?
Dans mon précédent article, publié fin 2024, je présentais les options de durcissement du presse-papiers AVD via Intune et les propriétés RDP. Depuis mi-2025, Microsoft est passé d’une approche configurable à une approche imposée par défaut : les redirections (presse-papiers, lecteurs, USB, imprimantes) sont désormais désactivées nativement dans Windows 365 et AVD. Ce qui était un bon réflexe de sécurité devient aujourd’hui la norme.
Une excellente référence pour cette mise à jour est l’article de Dieter Kempeneers, Configure Advanced Clipboard AND Drive Redirection for AVD and Windows 365, dans lequel il détaille non seulement la désactivation par défaut des redirections (presse-papiers, lecteurs, imprimantes) sur les nouveaux hôtes AVD et les Cloud PC Windows 365, mais aussi la façon d’en réactiver certains comportements de façon granulaire.
Dans ce nouvel article, je décortique la logique de redirection RDP, les nouvelles valeurs par défaut introduites par Microsoft, et surtout, les implications pratiques pour vos déploiements et modèles AVD / Windows 365.
Depuis quand Microsoft a changé la règle du presse-papier pour Windows 365 ?
Microsoft a introduit de nouveaux paramètres de sécurité par défaut pour Windows 365 Cloud PCs le 18 juin 2025 :
Windows 365 renforce la sécurité des PC cloud en désactivant par défaut les redirections du presse-papiers, des lecteurs, des périphériques USB et des imprimantes pour tous les PC cloud nouvellement provisionnés et reprovisionnés. Cette modification minimise le risque d’exfiltration de données et d’injection de logiciels malveillants, ce qui offre une expérience plus sécurisée et s’aligne sur le principe de l’initiative Microsoft Secure Future Initiative (SFI) visant à activer et à appliquer par défaut les protections de sécurité.
Un message sous forme de bandeau est bien visible lors de la création d’une police de provisionnement Windows 365 :
D’ailleurs, la police de configuration de sécurité appelée Windows 365 Security Baseline et disponible sur Intune contient bien une restriction qui concerne les lecteurs, donc, de facto, le transfert de fichiers :
Est-ce que cette restriction concerne aussi Azure Virtual Desktop ?
Oui, les nouveaux pools d’hôtes Azure Virtual Desktop sont aussi concernés par ce renforcement :
Cette modification des paramètres par défaut de redirection sera bientôt effective. Afin d’aider les administrateurs informatiques à s’y préparer, une bannière pouvant être ignorée s’affichera sur la page d’accueil « Créer un pool d’hôtes » du portail Azure. Cette bannière informera les administrateurs des nouveaux paramètres par défaut pour les nouveaux pools d’hôtes et fournira des liens vers la documentation expliquant comment les remplacer en modifiant les propriétés RDP du pool d’hôtes une fois celui-ci créé.
Remarque : pour les pools d’hôtes existants, aucune modification ne sera apportée à la configuration de redirection en votre nom. Cependant, nous vous recommandons de renforcer la sécurité des paramètres en désactivant les redirections qui ne sont pas nécessaires. Pour effectuer ces modifications, consultez la section relative à la redirection des appareils dans la documentation sur les propriétés RDP.
Voici la nouvelle option de configuration RDP mise par défaut, et visible dans les propriétés du pool d’hôtes AVD :
D’ailleurs, la police de configuration de sécurité appelée Security Baseline for Windows 10 and later et disponible sur Intune contient bien une restriction qui concerne les lecteurs, donc de facto le transfert de fichiers :
Qu’est-ce que cela change pour mes futures créations AVD et Windows 365 ?
Pour AVD : pour tout nouveau pool d’hôtes créé après la date de changement, les redirections de presse-papier, lecteurs, USB et imprimantes seront désactivées par défaut.
Pour Windows 365 : idem pour tous les Cloud PCs nouvellement provisionnés ou reprovisionnés : les mêmes redirections sont désactivées par défaut.
Impact : vos modèles, templates ou polices qui s’appuyaient sur ces redirections devront être revus. Si vous aviez des scénarios utilisateur où l’on transférait facilement du contenu local vers le poste cloud, il faudra anticiper ce nouveau comportement.
Comment identifier la configuration actuelle des postes ?
Le comportement dépend de deux couches complémentaires. Le serveur RDP n’impose pas unilatéralement la redirection : il la négocie avec le client en fonction de ces deux niveaux :
Le client (.rdp / Propriétés RDP AVD) détermine ce qui est demandé ou refusé pour la session. Exemple : redirectclipboard:i:0 dans les propriétés RDP d’un host pool.
Le serveur (Policies / GPO / Intune) définit ce qui est autorisé ou interdit de manière globale sur la machine. Exemple : fDisableClipboard dans le registre des stratégies.
Première couche : configuration client / RDP Properties :
Ces valeurs correspondent à la configuration du service RDP. Elles sont mises à jour lorsque tu modifies les RDP Properties d’un host pool dans AVD, par exemple :
Ces valeurs représentent la couche de gouvernance :
Elles sont prioritaires sur les paramètres locaux et sont appliquées au démarrage du service TermService.
Elles déterminent ce qui est autorisé ou interdit globalement sur la machine, indépendamment des paramètres envoyés par le .rdp.
La configuration peut se faire très facilement depuis une police de configuration Intune :
Interaction entre les deux couches :
Le comportement effectif correspond toujours à la configuration la plus restrictive :
Policy (serveur)
RDP Property (client/session)
Résultat final
Autorise
Interdit (redirectclipboard:i:0)
❌ Redirection désactivée
Interdit
Autorise (redirectclipboard:i:1)
❌ Redirection désactivée
Autorise
Autorise
✅ Redirection active
Résultats de tests : comportement réel du presse-papiers RDP
Pour mieux comprendre ces nouveaux paramètres de redirection du presse-papiers, j’ai réalisé une série de tests sur plusieurs configurations RDP (AVD et Windows 365).
Le but était de vérifier quels types de données (texte, image, HTML, binaire, etc.) pouvaient être copiés dans chaque sens selon les paramètres du serveur et du client.
Les couches de configuration RDP :
Les deux couches peuvent définir différentes valeurs, mais elles ne s’écrasent pas : le moteur RDP évalue d’abord la police, puis les propriétés RDP :
Couche
Rôle
1. ConfigurationRDP
Paramètres appliqués au niveau du service RDP local. C’est ce qu’utilise la session à l’exécution. Modifié par les propriétés RDP d’un host pool AVD.
2. Policy configuration (GPO / Intune)
Paramètres de gouvernance. Écrits par une stratégie (GPO/MDM) et prioritaires sur la configuration locale.
Niveaux de granularité (SCClipLevel / CSClipLevel) :
Les valeurs SCClipLevel et CSClipLevel permettent aussi d’affiner très précisément la redirection dans chaque sens :
SC (Server → Client) : copier du cloud vers le poste local.
CS (Client → Server) : copier du poste local vers le cloud.
Niveau
Formats autorisés
Exemple
0
Aucune redirection
Blocage total
1
Texte brut uniquement
Copier/coller texte simple
2
Texte brut + images
Exemple : capture d’écran
3
Texte brut + images + RTF
Texte formaté (Word, Outlook)
4
+ HTML
Copier/coller depuis un navigateur
Comment cela se voit pour Windows 365 ?
Voici un récapitulatif des différents tests effectués, en modifiant les propriétés pour AVD ou Windows 365 :
Et voici le détail de ces tests avec les configurations Intune appliquées pour impacter le registre Windows :
Test A – Clipboard redirection isn’t available : Le presse-papiers est complètement désactivé côté session RDP. Aucun copier/coller ne fonctionne dans aucun sens :
Test B – Clipboard redirection is available : Le presse-papiers est activé côté session RDP. Le copier/coller fonctionne dans les deux sens :
Test C – Do not allow Clipboard redirection Disabled (fDisableClip=0). Le comportement dépend donc de la configuration du fichier .rdp, qui est activé. Le copier/coller fonctionne dans les deux sens :
Test D – Do not allow Clipboard redirection Enabled (fDisableClip=1). Blocage complet du copier/coller, même si le .rdp autorise la redirection :
Test E – Do not allow Clipboard redirection Disabled (fDisableClip=0), comme la configuration du fichier .rdp, qui est activé. Disable clipboard transfers from session host to client (SCClipLevel=0) et inversement (CSClipLevel=0). Aucun copier-coller descendant ou montant n’est possible :
Test F – Allow plain text : Autorise uniquement le texte brut (SCClipLevel=1 / CSClipLevel=0 / fDisableClip=0). Le copier/coller d’images fonctionne du host vers le client, mais pas inversement, et pas d’images ni de formats enrichis :
Test G – Allow plain text and image : Autorise texte brut + images (SCClipLevel=2 / CSClipLevel=0 / fDisableClip=0). Le copier/coller d’images fonctionne du host vers le client, mais pas inversement :
Test H – Ajoute le support du Rich Text (SCClipLevel=3 / CSClipLevel=0 / fDisableClip=0). Le copier/coller de texte et d’images fonctionne, mais pas HTML ni formats binaires. Le copier/coller d’images fonctionne du host vers le client, mais pas inversement :
Test I – Allow plain text, images, Rich Text Format and HTML. Ajoute HTML (SCClipLevel=4 / CSClipLevel=0 / fDisableClip=0). Formats binaires toujours bloqués.Le copier/coller d’images fonctionne du host vers le client, mais pas inversement :
Test J – Allow plain text, images, Rich Text Format, HTML and Binary. Autorise tous les formats, y compris binaires (CSClipLevel=0 / fDisableCdm=0 / fDisableClip=0). Tous les copier/coller possibles du host vers client :
Test K – Allow plain text (inverse direction). Même logique que F mais appliquée au client → host (SCClipLevel=0 / CSClipLevel=1 / fDisableClip=0). Seul le texte brut passe du poste local vers le cloud :
Test L – Allow plain text and images (inverse direction). Autorise texte et images du client vers la session (SCClipLevel=0 / CSClipLevel=2 / fDisableClip=0) :
Test M – Allow plain text, images and Rich Text Format (inverse direction). Ajoute RTF côté client → host (SCClipLevel=0 / CSClipLevel=3 / fDisableClip=0). HTML et binaire toujours bloqués :
Test N – Allow plain text, images, Rich Text Format and HTML (inverse direction). Permet HTML du client vers la session (SCClipLevel=0 / CSClipLevel=4 / fDisableClip=0) :
Test O – Allow plain text, images, Rich Text Format, HTML and Binary (inverse direction). Autorise tous les formats, y compris binaires (SCClipLevel=0 / fDisableCdm=0 / fDisableClip=0). Tous les copier/coller possibles du client vers le host :
Conclusion
La désactivation par défaut des redirections RDP dans Windows 365 et AVD s’inscrit dans une tendance claire : un durcissement progressif des environnements cloud Windows pour tendre vers le secure by default.
Pour les architectes et administrateurs, cela signifie qu’il faut désormais anticiper ce comportement dans les modèles de provisionnement, les recommandations Intune et les templates de pools AVD.
Le presse-papiers, souvent considéré comme un simple confort utilisateur, devient un point de contrôle important dans la stratégie de sécurité : il faut choisir entre flexibilité et maîtrise du flux de données entre les environnements locaux et cloud.
En maîtrisant les deux couches de configuration (Propriétés RDP et polices GPO/MDM) et les niveaux SCClipLevel / CSClipLevel, vous pouvez adapter finement le niveau de redirection autorisé, du simple texte brut jusqu’à la copie complète de formats binaires.
En résumé : ce changement n’est pas une contrainte, mais une opportunité d’élever le niveau de sécurité sans perdre la visibilité sur le fonctionnement interne du protocole RDP.
Pourquoi, en 2025, mettre à jour son AVD ronronnant encore et toujours sous Windows 10 22H2 ? Windows 10 ou 11, comme leurs prédécesseurs, reçoivent régulièrement plusieurs types de mises à jour (sécurité, correctifs de bugs, feature update, pilotes, …) . Bien que les Extended Security Updates soient gratuites pour les environnements AVD ou Windows 365 pendant encore une année, il ne faudrait pas trop traîner non plus. Mais … attention à BitLocker !
Voici d’ailleurs le lien vers la FAQ Microosft des Extended Security Updates (ESU) pour Windows 10.
Sous Windows 11, la fréquence des Feature Updates a changé par rapport à Windows 10. Depuis 2022, Microsoft publie une seule Feature Update par an, généralement au second semestre (H2) :
21H2 → sortie en octobre 2021
22H2 → sortie en septembre 2022
23H2 → sortie en octobre 2023
24H2 → sortie en septembre/octobre 2024
Mais, Microsoft ne maintient pas indéfiniment ses produits. La transition vers des versions plus récentes est donc inévitable :
Système
Édition
Version
Date de fin de support / fin de maintenance
Windows 10
Windows 10 Enterprise Windows 10 Enterprise multi-session Windows 10 Education, Windows 10 IoT Enterprise
Les versions Entreprise de Windows 11 ont toute une année de service en plus que leurs homologues respectives en version pro.
Comment les versions de Windows 10/11 sont disponibles sous Azure ?
Lors de la création d’une machine virtuelle sous Azure, Microsoft propose toujours plusieurs versions de Windows 10 ou 11, accessibles via le Marketplace Azure :
Un menu déroulant propose différentes versions et générations (Il est important de vérifier que la VM sélectionnée réponde aux conditions (hardware, Gen2, virt-TPM, Secure Boot…) car toutes les séries de VMs ne sont pas compatibles) :
On peut noter qu’il y a donc distinction entre les éditions clients (Pro, Enterprise). De plus, certaines images sont destinées à des usages spécifiques comme Windows 11 Enterprise multi‑session.
Qu’est-ce qu’Azure Update Manager, et peut-il m’aider ?
Azure Update Manager (AUM) est un service de Microsoft disponible sur Microsoft Azure, conçu pour gérer et superviser les mises à jour logicielles (patches) des machines, tant sous Windows que sous Linux, dans des environnements Azure, sur-premises ou multicloud via Azure Arc.
Grâce à Azure Update Manager, vous allez pouvoir :
Superviser la conformité des mises à jour pour les machines Windows et Linux, qu’elles soient dans Azure ou connectées via Azure Arc (on-premises ou multicloud).
Planifier des fenêtres de maintenance pour appliquer les patches.
Déployer un patch à la demande, ou d’un déploiement automatique selon une plage horaire définie.
Mettre en œuvre des mises à jour critiques et les suivre via le monitoring.
Gérer les droits via la granularité d’accès (RBAC) et d’autres fonctions de gouvernance Azure.
En ce qui concerne une machine virtuelle Azure avec un OS sous Windows 11, Microsoft est très clair sur ce point :
Automation Update Management ne fourni pas de prise en charge pour l’application de patchs à Windows 10 et 11. Il en va de même pour le Gestionnaire de mises à jour Azure. Nous vous recommandons d’utiliser Microsoft Intune comme solution pour maintenir les appareils Windows 10 et 11 à jour.
Pour utiliser ces fonctionnalités, créez une machine virtuelle à l’aide de votre système d’exploitation préféré au lieu d’effectuer une mise à niveau sur place.
Microsoft ne recommande donc pas de faire une mise à niveau sur place pour une machine virtuelle Windows 10 ou 11 dans Azure pour des raisons techniques et structurelles.
Une mise à niveau sur place modifie profondément le système d’exploitation à l’intérieur de la VM sans qu’Azure en soit informé.
Résultat : La machine continue d’exister dans Azure avec les anciennes métadonnées d’image (Publisher, Offer, Plan, version, etc.), ce qui empêche Azure de reconnaître la nouvelle version de l’OS.
Et cela pose un ensemble de problèmes :
de gestion du cycle de vie
de sécurité et conformité (Azure Security Center/Azure Policy peuvent se tromper sur la version de l’OS)
du support Microsoft, car ce dernier s’appuie sur l’image déclarée dans Azure
Mais Microsoft propose pourtant la mise à niveau pour Windows Server ?
Passer d’une version antérieure de Windows Server à une version plus récente tout en conservant les rôles, données et applications.
Que recommande alors Microsoft pour gérer une MAJ sur Windows 10 ?
Microsoft recommande donc de créer une nouvelle VM avec le système d’exploitation cible, car les mises à jour directes peuvent empêcher certaines fonctionnalités Azure de fonctionner correctement.
Donc, la meilleure pratique consiste à :
Déployer une nouvelle VM avec l’image du nouvel OS supporté.
Migrer les applications, données, configurations vers cette nouvelle VM.
Valider le bon fonctionnement, puis retirer l’ancienne VM.
Plusieurs vidéos tutorielles existent sur Internet pour proposer des mises à jour depuis Windows 10 :
Et quid du passage de la 22H2 à la 24H2 ?
Si malgré tout vous devez conserver votre image de base et effectuer une mise à jour vers Windows 11 24H2, vous risquez de rencontrer un problème de démarrage après la capture de votre image après un sysprep.
Lors du passage de Windows 10 22H2 ou Windows 11 22H2 vers la version 24H2, plusieurs administrateurs ont rencontré des écrans bleus ou des erreurs EFI (0xc000000f) juste après la capture d’image via Sysprep.
Le problème provient d’un bug dans le processus de Sysprep, qui modifie la configuration BCD lorsque BitLocker (ou le chiffrement automatique du périphérique) est actif.
Et le souci se manifeste à nouveau si on réactive BitLocker sans avoir corrigé la configuration BCD.
Résultat : l’image capturée devient partiellement chiffrée et inutilisable au déploiement.
Ce souci de démarrage est d’ailleurs confirmé dans les journaux de diagnostic Azure :
Pas de workaround possible ?
Pour éviter cela, il faut désactiver BitLocker avant le Sysprep. Une fois l’image déployée, BitLocker peut être réactivé proprement après correction de la configuration BCD. Ce comportement est spécifique aux builds 26100.x (Windows 11 24H2 et LTSC 2024) .
Voici d’abord une comparaison de l’état de BitLocker sur deux machines virtuelles Azure :
A droite : Windows 10 Multi-session 22H2
A gauche : Windows 11 Multi-session 24H2
La désactivation de BitLocker doit donc être complète et certaine avant de lancer Sysprep, sous peine de le voir se réactiver.
Afin de voir ce qu’il est possible de faire pour résoudre le souci de BitLocker , je vous propose au travers de cet article un pas à pas sur le processus complet :
Pour réaliser ces tests de mise à jour de VM, il vous faudra disposer de :
Un abonnement Azure valide
Un tenant Microsoft
Afin d’être sûr des impacts de nos différentes actions, je vous propose de commencer par la création d’une machine virtuelle à partir d’une image Windows 10/11 multi-session en 22H2, que nous allons mettre à jour dans la foulée.
Etape I – Création d’une VM W10 Multi-session 22H2 + MAJ 24H2 :
Pour cela, je commence par créer une machine virtuelle Azure en Windows 10 en 22H2 :
Une fois la machine virtuelle déployée, je vérifie la présence de mon application et de ma version actuelle de Windows :
J’ouvre PowerShell ISE en mode administrateur afin de vérifier l’état actuel de BitLocker :
Get-Service BDESVC : affiche l’état du service BitLocker Drive Encryption Service, qui gère le chiffrement BitLocker sur Windows.
manage-bde -status : affiche le statut détaillé du chiffrement BitLocker sur tous les lecteurs du système.
(Get-ComputerInfo).WindowsVersion : retourne la version majeure de Windows (ex. 10, 11, etc.).
(Get-ComputerInfo).OsBuildNumber : affiche le numéro de build du système d’exploitation Windows.
(Get-ComputerInfo).WindowsBuildLabEx : fournit la version complète du build Windows avec des informations additionnelles (branche, révision, date de compilation).
Je télécharge ensuite l’ISO Windows 11 24H2 depuis Visual Studio :
Je lance l’installation de Windows 11 en 24H2 :
Je vérifie le maintien de la version Multi-session, puis je démarre l’installation :
L’installation progresse lentement mais sûrement :
Afin de m’assurer que la mise à jour est terminée, je vérifie les journaux de diagnostic Azure pour confirmer le bon démarrage de la machine virtuelle :
Je me connecte via Azure Bastion et je vérifie le statut de BitLocker :
Le service de BitLocker BDESVC est maintenant démarré en 24H2 :
Je lance les commandes suivantes pour arrêter le service BitLocker BDESVC, mais aussi pour bloquer son changement de statut lors du sysprep :
# 1. Empêcher toute activation BitLocker automatique
reg add "HKLM\SYSTEM\CurrentControlSet\Control\BitLocker" /v PreventDeviceEncryption /t REG_DWORD /d 1 /f
# 2. Désactiver le service BitLocker
Set-Service -Name BDESVC -StartupType Disabled
# 3. Stopper le service s’il est actif
Stop-Service -Name BDESVC -Force
# 4. Vérifier que tout est propre
Get-Service BDESVC
manage-bde -status
La machine virtuelle est maintenant prête pour la capture. Avant cela je pourrais effectuer un snapshot. Je décide de continuer avec la commande Sysprep.
Etape II – Capture de l’image Windows 11 24H2 :
Je lance la commande Sysprep pour capturer cette nouvelle image 24H2 :
Une fois Sysprep terminé, j’arrête complètement la machine pour qu’elle soit désallouée, puis je lance l’action de capture de l’image depuis le portail Azure :
Je crée une nouvelle image au sein de ma Azure Compute Gallery :
Avec cette nouvelle image en place, je déclenche la création d’une nouvelle machine virtuelle 24H2 à partir de celle-ci :
La nouvelle machine virtuelle est fonctionnelle, et cela est confirmé dans les journaux de diagnostic Azure :
Etape III – Réactivation de BitLocker:
Une fois la VM créée, je m’y connecte via Azure Bastion, puis je lance la vérification initiale de l’état du service BitLocker et du chiffrement :
La correction est bien visible sur cette seconde partie de l’écran :
Je supprime la clé de registre PreventDeviceEncryption si elle est présente, je rétablis le service BitLocker en mode manuel, je le démarre, puis je contrôle à nouveau l’état du service BDESVC et de BitLocker :
# --- Nettoyage de la clé PreventDeviceEncryption
Write-Host "=== Suppression clé PreventDeviceEncryption ===" -ForegroundColor Cyan
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\BitLocker" /v PreventDeviceEncryption /f | Out-Null
Write-Host "Clé supprimée (si existante)."
Start-Sleep -Seconds 2
# --- Rétablir le service BitLocker (manuel + démarrage)
Write-Host "=== Réactivation du service BitLocker ===" -ForegroundColor Cyan
Set-Service -Name BDESVC -StartupType Manual
Start-Service -Name BDESVC
Write-Host "Service BDESVC en cours d’exécution."
Write-Host ""
Start-Sleep -Seconds 2
# --- Vérifie l’état avant chiffrement
Write-Host "=== État avant chiffrement ===" -ForegroundColor Yellow
Get-Service BDESVC
manage-bde -status
Write-Host ""
Start-Sleep -Seconds 2
J’attends environ 15 minutes la fin du chiffrement du disque OS :
Cette activation est visible par le petit cadenas présent dans les paramétrages BitLocker et dans l’explorateur de fichier, suivi éventuellement d’un avertissement pour me signaler que la protection est encore sur OFF :
Une fois le chiffrement en place, je remets en route la protection (clé TPM active, verrouillage à l’amorçage autorisé)”.
# --- Finalisation
Write-Host "=== Activation finale (Resume-BitLocker) ===" -ForegroundColor Cyan
Resume-BitLocker -MountPoint "C:"
Write-Host "BitLocker réactivé avec succès."
Write-Host ""
Start-Sleep -Seconds 3
# --- Vérification finale
Write-Host "=== Vérification finale ===" -ForegroundColor Green
Get-Service BDESVC
manage-bde -status
Write-Host "=== FIN DU SCRIPT ===" -ForegroundColor Cyan
Cette validation est visible par la disparition de l’avertissement pour me signaler que la protection est maintenant sur ON :
Etape IV – Azure Virtual Desktop :
Je redémarre la machine virtuelle pour vérifier le bon fonctionnement du boot de Windows :
Une fois la VM redémarrée, je me reconnecte et confirme la présence de mon application, de la version 24H2 et de l’état actif de BitLocker sur cette machine virtuelle :
Je teste l’ajout de cette image dans un environnement Azure Virtual Desktop :
J’attends la fin de déploiement afin de constater la présence des VMs AVD comme étant disponibles :
Je passe sur chacune des machines pour lancer le script suivant en local ou à distance :
<#
.SYNOPSIS
Répare la configuration BitLocker après Sysprep /generalize sur Windows 11 24H2.
Corrige le BCD EFI et réactive BitLocker proprement.
.DESCRIPTION
Ce script :
1. Affiche l’état initial BitLocker et du service BDESVC
2. Corrige les entrées BCD {current} et {memdiag}
3. Supprime la clé PreventDeviceEncryption
4. Rétablit le service BitLocker (mode Manuel)
5. Démarre BDESVC et attend qu’il soit prêt
6. Active BitLocker avec TPM (si nécessaire)
7. Attend la fin du chiffrement (max 2h)
8. Finalise avec Resume-BitLocker
#>
# --- FONCTIONS UTILITAIRES ---
function Wait-ForService {
param (
[string]$ServiceName,
[int]$TimeoutSec = 120
)
Write-Host "Attente du service $ServiceName..." -ForegroundColor Yellow
$sw = [Diagnostics.Stopwatch]::StartNew()
while ($sw.Elapsed.TotalSeconds -lt $TimeoutSec) {
$status = (Get-Service $ServiceName -ErrorAction SilentlyContinue).Status
if ($status -eq 'Running') {
Write-Host "Service $ServiceName opérationnel." -ForegroundColor Green
return
}
Start-Sleep -Seconds 3
}
Write-Host "⚠️ Le service $ServiceName n’a pas démarré après $TimeoutSec secondes." -ForegroundColor Red
}
function Wait-ForEncryption {
param (
[string]$MountPoint = "C:",
[int]$CheckIntervalSec = 15,
[int]$TimeoutSec = 7200 # 2 heures
)
Write-Host "Attente de la fin du chiffrement BitLocker sur $MountPoint (timeout $($TimeoutSec/60) min)..." -ForegroundColor Yellow
$sw = [Diagnostics.Stopwatch]::StartNew()
while ($sw.Elapsed.TotalSeconds -lt $TimeoutSec) {
$status = manage-bde -status $MountPoint | Select-String "Conversion Status"
$percent = manage-bde -status $MountPoint | Select-String "Percentage Encrypted"
$state = ($status -replace ".*:\s*", "").Trim()
$progress = ($percent -replace ".*:\s*", "").Trim()
Write-Host "État: $state | Progression: $progress"
if ($state -match "Fully Encrypted|Used Space Only Encrypted") {
Write-Host "✅ Chiffrement terminé sur $MountPoint" -ForegroundColor Green
return
}
Start-Sleep -Seconds $CheckIntervalSec
}
Write-Host "⚠️ Le chiffrement sur $MountPoint n’est pas terminé après $($TimeoutSec/60) minutes." -ForegroundColor Red
Write-Host "Le script continue, mais vérifie manuellement l’état avec 'manage-bde -status $MountPoint'." -ForegroundColor Yellow
}
# --- DÉBUT DU SCRIPT ---
Write-Host "=== Vérification initiale ===" -ForegroundColor Cyan
Get-Service BDESVC
manage-bde -status
Write-Host ""
Start-Sleep -Seconds 3
# --- Vérifie le BCD avant correction
Write-Host "=== BCD avant correction ===" -ForegroundColor Yellow
cmd /c "bcdedit /enum"
Write-Host ""
Start-Sleep -Seconds 2
# --- Corrige les entrées BCD
Write-Host "=== Correction BCD ===" -ForegroundColor Cyan
cmd /c "bcdedit /set {current} osdevice partition=C:"
cmd /c "bcdedit /set {current} device partition=C:"
cmd /c "bcdedit /set {memdiag} device partition=\Device\HarddiskVolume3"
Write-Host "BCD corrigé."
Start-Sleep -Seconds 2
# --- Vérifie le BCD après correction
Write-Host "=== BCD après correction ===" -ForegroundColor Green
cmd /c "bcdedit /enum"
Start-Sleep -Seconds 2
# --- Supprime PreventDeviceEncryption
Write-Host "=== Suppression clé PreventDeviceEncryption ===" -ForegroundColor Cyan
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\BitLocker" /v PreventDeviceEncryption /f | Out-Null
Write-Host "Clé supprimée (si existante)."
Start-Sleep -Seconds 2
# --- Réactive BDESVC
Write-Host "=== Réactivation du service BitLocker ===" -ForegroundColor Cyan
Set-Service -Name BDESVC -StartupType Manual
Start-Service -Name BDESVC
Wait-ForService -ServiceName "BDESVC"
Write-Host ""
# --- Vérifie l’état avant chiffrement
Write-Host "=== État avant chiffrement ===" -ForegroundColor Yellow
Get-Service BDESVC
manage-bde -status
Start-Sleep -Seconds 2
# --- Active BitLocker avec TPM si nécessaire
Write-Host "=== Activation BitLocker (TPM) ===" -ForegroundColor Cyan
$bitlockerStatus = (manage-bde -status C: | Select-String "Conversion Status").ToString()
if ($bitlockerStatus -match "Encryption in Progress|Fully Encrypted|Used Space Only Encrypted") {
Write-Host "ℹ️ BitLocker est déjà actif ou en cours de chiffrement sur C:. Aucune réactivation nécessaire." -ForegroundColor Yellow
} else {
try {
Enable-BitLocker -MountPoint "C:" -TpmProtector -UsedSpaceOnly -ErrorAction Stop
Write-Host "BitLocker initialisé." -ForegroundColor Green
} catch {
Write-Host "⚠️ Impossible d’ajouter un protecteur TPM (probablement déjà présent) : $($_.Exception.Message)" -ForegroundColor Red
}
}
Write-Host "Vérification du statut..."
Wait-ForEncryption -MountPoint "C:" -TimeoutSec 7200
Write-Host ""
# --- Finalisation
Write-Host "=== Activation finale (Resume-BitLocker) ===" -ForegroundColor Cyan
Resume-BitLocker -MountPoint "C:"
Wait-ForEncryption -MountPoint "C:" -TimeoutSec 7200
Write-Host "BitLocker réactivé avec succès." -ForegroundColor Green
Write-Host ""
# --- Vérification finale
Write-Host "=== Vérification finale ===" -ForegroundColor Green
Get-Service BDESVC
manage-bde -status
Write-Host "=== FIN DU SCRIPT ===" -ForegroundColor Cyan
Je redémarre la machine AVD pour vérifier son statut dans les journaux de diagnostic Azure :
Je teste également la connexion Azure Virtual Desktop avec un utilisateur :
Enfin, comme mon environnement est liée à Entra ID, je constate également la remontée automatqiue de ma clef de secours BitLocker dans Entra ID :
Conclusion
Cette expérience montre bien qu’une mise à jour in-place d’une image Windows 10/11 dans Azure n’est jamais anodine. Entre la gestion du chiffrement BitLocker, les effets secondaires du Sysprep et les métadonnées Azure qui ne se mettent pas toujours à jour correctement, le risque d’image inutilisable est bien réel.
Le bon réflexe reste donc de désactiver BitLocker avant le Sysprep, de corriger la configuration BCD, puis de réactiver proprement la protection une fois la VM redéployée. Cette approche garantit un chiffrement fonctionnel sans compromettre la capture ni le déploiement de l’image.
Mais il existe aujourd’hui une alternative plus élégante et performante : Encryption at Host. Cette fonctionnalité permet de chiffrer les disques directement au niveau de l’hôte Azure, sans impliquer le service BitLocker à l’intérieur de la VM.
Résultat :
Moins de charge CPU côté invité,
Pas de dépendance au TPM virtuel,
Et une gestion centralisée du chiffrement dans Azure, plus simple à auditer et à maintenir.
C’est cette approche, à la fois plus moderne et plus légère, que nous verrons dans le prochain article.
On parlera en détail de la mise en œuvre d’Encryption at Host, de son impact sur les performances et des bonnes pratiques pour combiner sécurité et efficacité énergétique dans vos environnements AVD.
Pourquoi devrais-je sauvegarder mes données Microsoft Entra ID ? Entra ID est la brique centrale qui pilote l’identité, l’accès et la sécurité de tout l’environnement cloud. Si Entra ID tombe, tout tombe : authentification, applications SaaS, accès aux ressources Azure, Polices d’accès conditionnel, MFA, etc…
Entra ID a son backup natif, n’est-ce pas ?
Non, Microsoft n’offre pas de fonctionnalité de sauvegarde ou de restauration complète d’Entra ID. Voici ce qui existe nativement, et surtout ce qui manque :
Élément Entra ID
Comportement natif
Limite importante
Utilisateurs / Groupes supprimés
Corbeille 30 jours
Object ID parfois régénéré → casse des dépendances
Rôles / Applications
Suppression définitive
Aucune corbeille, restauration impossible
Politiques d’accès conditionnel
Corbeille 30 jours (préversion)
Une erreur bloque l’accès global
Service Principals / App Registrations
Corbeille 30 jours
Impact direct sur les intégrations applicatives
Audit & sign-in logs
Conservation limitée (7 à 30 jours selon licence)
Impossible de rejouer/restaurer
Avec une sauvegarde Entra ID dédiée, il vous serait possible de ?
Revenir à un état connu fonctionnel après une mauvaise config
Restaurer un objet précis (utilisateur, groupe, application…) sans impacter le reste
Comparer deux versions d’un objet et restaurer uniquement un champ
Auditer proprement ce qui a changé dans la configuration du tenant
Garder une preuve longue durée des logs de sécurité
Qu’est-ce que Veeam Data Cloud ?
Pour vous aider, j’en ai déjà parlé au travers de plusieurs articles :
Veeam Data Cloud est la plateforme SaaS de Veeam, hébergée dans Azure, qui permet de sauvegarder et restaurer les données Microsoft 365 et Microsoft Entra ID sans avoir à déployer d’infrastructure.
Tout est géré par Veeam ?
Pas de serveur VBR à installer, pas de SQL, pas de stockage à provisionner
Sauvegarde hébergée dans Azure, dans la région que tu choisis à l’activation
Interface Web = tout se fait en ligne, y compris la restauration granulaire
En résumé : c’est le Veeam que tu connais, mais entièrement hébergé, pensé pour les environnements cloud first ou sans infrastructure on-prem, et surtout pour apporter une vraie sauvegarde de l’identité Entra ID, ce que Microsoft ne propose pas nativement.
Qu’est-ce que Veeam Data Cloud pour Microsoft Entra ID ?
Veeam Data Cloud pour Microsoft Entra ID est un service 100% SaaS, hébergé dans Microsoft Azure, qui permet de sauvegarder, restaurer et versionner les objets critiques d’un tenant Entra ID sans déployer de serveur Veeam ni gérer de stockage.
Il protège notamment :
Utilisateurs et groupes
Applications et principaux de service
Rôles, unités d’administration
Politiques d’accès conditionnel
Journaux d’audit et connexions
Tout se pilote depuis une interface web Veeam, avec :
Possibilité de rollback ciblé après une mauvaise configuration
Sauvegarde automatique et récurrente
Stockage inclus et géré par Veeam dans Azure
Restauration granulaire (objet complet ou propriété unique)
Combien coûte Veeam Data Cloud pour Microsoft Entra ID ?
Pour réaliser cette démonstration de sauvegarde d’Entra ID via la solution Veeam Data Cloud pour Entra ID, j’ai eu besoin de :
Un tenant Microsoft
Une souscription Veeam Data Cloud for Entra ID
Commençons par configurer Veeam Data Cloud depuis l’ajout de la licence du produit.
Etape I – Configuration de Veeam Data Cloud for Entra ID :
Je me connecte à la console Veeam Data Cloud afin de vérifier la souscription disponible et le nombre d’utilisateurs éligibles à la sauvegarde :
Je clique sur les trois points, puis sur Manage pour accéder au menu de gestion :
Depuis la console VDC, je clique sur Entra ID parmi les produits proposés :
Je clique sur le bouton permettant d’ajouter mon tenant Entra ID :
Je clique sur Autoriser pour lancer la délégation d’accès au tenant :
Je m’authentifie avec un compte disposant du rôle Administrateur Général :
J’accepte les permissions demandées par l’application Veeam Data Cloud pour Entra ID :
Dans le portail Entra ID, je constate les permissions accordées ainsi que le consentement administrateur sur l’application Veeam Data Cloud pour Entra ID :
Je retourne dans la console Veeam et je confirme que l’autorisation a bien été prise en compte avant de cliquer sur Suivant :
Je choisis la région Azure parmi celles disponibles dans laquelle les données Entra ID seront stockées :
Je prends connaissance des différents types d’objets qui seront sauvegardés par le service :
Je définis la rétention des sauvegardes, puis j’active la protection des politiques d’accès conditionnel avant de cliquer sur Suivant :
Je vérifie la politique de sauvegarde, puis je clique sur Finaliser :
A partir de ce moment, l’infrastructure de sauvegarde de Veeam Data Cloud commence à se provisionner :
Quelques minutes plus tard, je constate que l’état de provisionnement est passé à Provisionné :
Je reçois également un e-mail confirmant que la sauvegarde Entra ID a bien été mise en place :
Attendons maintenant le premier cycle de sauvegarde prévu dès cette nuit pour contrôler ce qui aura été sauvegardé par Veeam Data Cloud.
Etape II – Contrôle des sauvegardes :
De retour sur le tableau de bord de VDC, je constate dès le lendemain la création des premiers objets sauvegardés (utilisateurs, groupes, applications, etc…) :
Je vérifie la consommation de licences et je note que 34 utilisateurs sont protégés :
Dans Entra ID, je constate que mon tenant contient bien 34 utilisateurs, la correspondance est donc correcte :
Je visualise la liste des objets sauvegardés dans la console Veeam :
Je confirme que le nombre d’objets utilisateurs sauvegardés correspond bien à Entra ID :
Je constate le même alignement sur le nombre de groupes sauvegardés :
Je vérifie également le nombre d’unités administratives sauvegardées :
Je contrôle les rôles pré-provisionnés et personnalisés pris en compte dans la sauvegarde :
Je constate la sauvegarde des applications et des principaux de service :
Je confirme la présence des politiques d’accès conditionnel sauvegardées :
Enfin, de retour dans l’onglet Configuration, je note que les paramètres ne sont plus modifiables après activation du service (un ticket au support sera nécessaire) :
Je constate progressivement, au fil des jours suivants, l’enchaînement des sauvegardes automatiques programmées :
Je peux à tout moment cliquer sur une exécution pour visualiser le détail des sauvegardes :
Je consulte l’entrée Backup Audit Logs qui liste les actions archivées :
Je constate également la présence des Sign-in Logs dans les éléments sauvegardés :
Testons maintenant les fonctionnalités de restauration d’objets sauvegardés.
Etape III – Test de restauration :
Je commence par supprimer un utilisateur dans Entra ID :
Dans la corbeille des utilisateurs supprimés, je confirme la suppression définitive de cet utilisateur :
Dans la console Veeam Data Cloud, je retourne dans la liste des objets utilisateurs sauvegardés, je clique sur l’utilisateur concerné, puis sur Restaurer :
Je peux sélectionner un point de restauration précis via le calendrier, puis je clique sur Suivant :
Je confirme les options de restauration proposées et je clique à nouveau sur Suivant :
Je clique sur Restaurer pour démarrer l’opération de récupération :
Je constate l’apparition d’une activité dans la liste des restaurations :
Une fois la restauration terminée, je constate des avertissements éventuels indiquant les sous-éléments qui n’ont pas pu être répliqués à l’identique :
De retour dans Microsoft Entra ID, je constate la recréation d’un nouvel objet utilisateur basé sur les informations sauvegardées. Le nouvel utilisateur restauré reprend bien tous les attributs d’origine :
Je modifie cette fois une caractéristique de l’utilisateur directement dans la console Entra ID :
Je retourne dans Veeam Data Cloud et je lance une comparaison/restauration sur cet utilisateur modifié :
Je constate que la différence sur la propriété modifiée est bien détectée, puis je clique sur Suivant :
Je peux renseigner un commentaire pour tracer l’action de restauration, puis je clique sur Restaurer :
Une fois la restauration terminée, je retourne dans Entra ID pour vérifier que la propriété a bien été restaurée à sa précédente valeur :
Je supprime cette fois un groupe Entra ID, je retourne dans Veeam Data Cloud, puis je lance une restauration :
Une fois la restauration terminée, je retourne dans Entra ID vérifier que le groupe a bien été restauré à son état d’origine avec un nouvel ID :
Je supprime cette fois un rôle personnalisé Entra ID, je retourne dans Veeam Data Cloud, puis je lance une restauration :
Une fois la restauration terminée, je retourne dans Entra ID vérifier que le rôle personnalisé a bien été restauré à son état d’origine ses permissions :
Je supprime cette fois une police d’accès conditionnel Entra ID, je retourne dans Veeam Data Cloud, puis je lance une restauration :
Une fois la restauration terminée, je retourne dans Entra ID vérifier que la police d’accès conditionnel a bien été restaurée à son état d’origine avec un nouvel ID :
Je supprime cette fois une Application Entra ID, retourne dans Veeam Data Cloud, puis je lance une restauration :
Une fois la restauration terminée, je retourne dans Entra ID vérifier que l’application a bien été restaurée à son état d’origine avec un nouvel ID :
Conclusion
Dans un contexte où l’identité est devenue le cœur de la sécurité cloud, disposer d’un historique exploitable et restaurable n’est plus un luxe, mais une nécessité opérationnelle.
Avec Veeam Data Cloud pour Microsoft Entra ID, on sort enfin du modèle « espérons que rien ne casse » pour entrer dans une vraie logique de sauvegarde et de restauration de l’identité cloud.
L’approche 100 % SaaS simplifie radicalement le déploiement : aucune infrastructure à maintenir, stockage inclus, rétention longue durée et surtout, une capacité à restaurer un objet critique Entra ID même après suppression définitive.
La prochaine étape ?
Explorer les scénarios avancés : restauration partielle de propriétés, rollback après mauvaise configuration, audit de versioning… et voir comment cette brique peut s’intégrer dans une stratégie globale de résilience Entra ID.
Comme pour Windows 365, Microsoft continue de faire évoluer Azure Virtual Desktop pour répondre aux besoins des organisations qui travaillent avec des partenaires externes, freelances ou prestataires. La dernière nouveauté, actuellement en préversion publique, permet de provisionner dans votre AVD une ou plusieurs identités externes (invités B2B dans votre tenant Microsoft Entra ID).
Fini la création systématique de comptes internes temporaires : les utilisateurs peuvent se connecter avec leur propre identité tout en profitant d’un accès à un environnement Azure Virtual Desktop créé sur votre tenant.
Qui peut bénéficier de cette nouveauté ?
Nous venons de sortir il y a peu de la préversion privée, et nous sommes donc maintenant en préversion publique, avant une mise à disposition générale (GA) dans plusieurs mois je suppose. Tout utilisateur externe invité dans votre tenant Microsoft Entra ID peut donc en profiter.
Comme rappelé plus haut, les scénarios typiques sont : prestataires, auditeurs, partenaires de développement…
Le flux d’approvisionnement change-t-il pour ces utilisateurs invités ?
Non, vous utilisez les mêmes pool d’hôtes Azure Virtual Desktop et les mêmes licences que pour les utilisateurs internes à votre tenant.
Depuis quelles plate-formes le compte invité fonctionne ?
A ce jour où ces lignes sont écrites, la documentation Microsoft mentionne deux moyens possibles :
VM AVD sous Windows 11 Enterprise avec mise à jour 24H2 (KB5065789) ou plus récente
VM AVD jointe à Entra ID
Single Sign-On activé au niveau du pool d’hôtes AVD
Quelles sont les principales limitations actuellement dans cette préversion ?
FSLogix n’est pas encore pris en charge : un nouveau profil utilisateur sera créé sur chaque hôte de session auquel elles se connectent.
Les polices Intune assignées à l’utilisateur externe ne s’appliquent pas (cibler les VMs AVD).
Pas de support pour le Cloud Government ni pour les invités cross-cloud (Azure Gov, 21Vianet).
Pas d’authentification Kerberos/NTLM vers les ressources on-premises.
Quelques limites sur la Token Protection pour identités externes.
Quelle licence Azure Virtual Desktop faut-il pour ces utilisateurs invités ?
Comme dit plus haut, il faut toujours provisionner une licence dans votre tenant pour le compte invité.
Les licences détenues par un compte invité dans son propre tenant ne confèrent aucun droit pour utiliser Azure Virtual Desktop dans votre tenant :
Si vous déployez Azure Virtual Desktop pour une utilisation avec des identités externes (actuellement en préversion publique), certaines considérations particulières peuvent s’appliquer concernant la manière de licencier Azure Virtual Desktop ainsi que d’autres produits et services Microsoft.
Cliquez sur Nouvel utilisateur, puis choisissez Inviter un utilisateur externe :
Renseignez l’adresse e-mail du compte Microsoft Entra de l’invité, puis cliquez ici :
Attendez quelques secondes, puis constatez la réception de l’e-mail d’invitation dans la boîte du compte invité, et enfin cliquez sur lien présent dans ce dernier :
Cliquez sur Accepter pour rejoindre le tenant qui vous a invité :
Ouvrez la fiche de l’utilisateur invité et attribuez-lui la licence AVD nécessaire, puis enregistrez :
Notre utilisateur invité est maintenant présent. Nous allons pouvoir nous intéresser au provisionnement de son accès à l’environnement AVD.
Etape II – Provisionnement de l’accès AVD à notre invité :
Pour cela, rendez-vous dans le portail Azure, puis rendez-vous sur la page du groupe d’application concerné :
Ajoutez l’utilisateur invité à votre groupe d’applications Azure Virtual Desktop :
Pensez également à lui ajouter un droit de connexion à la machine AVD via un rôle Azure RBAC :
Le provisionnement de l’utilisateur invité à notre environnement AVD est terminé. Nous allons maintenant pouvoir tester la connexion de ce dernier à Azure Virtual Desktop.
Etape III – Test de connexion invité depuis le navigateur internet :
Commençons nos tests par le navigateur internet. Pour cela, rendez-vous sur l’URL historique d’Azure Virtual Desktop, puis authentifiez avec le compte invité de votre utilisateur :
Peu importe le site internet utilisé, cliquez sur Connecter :
Cliquez à nouveau sur Connecter :
Cliquez sur Oui :
Constatez l’apparition du message de chargement de FSLogix :
Constatez la bonne ouverture de session de votre compte invité :
Ouvrez Windows PowerShell :
Lancez la commande suivante afin d’afficher l’état de l’enregistrement dans Entra ID :
dsregcmd /status
AzureAdJoined : YES : La machine est bien jointe à Microsoft Entra ID
EnterpriseJoined : NO
DomainJoined : NO :
TenantName : JLOUDEV : L’appareil s’est bien inscrit dans le bon tenant.
SSO / Primary Refresh Token :
AzureAdPrt : YES
DeviceAuthStatus : SUCCESS : Le Single Sign-On (SSO) est actif et le Primary Refresh Token (PRT) est bien présent :
Ouvrez Microsoft Edge, puis constatez l’absence de récupération automatique du token de connexion pour le SSO :
Ouvrez Microsoft OneDrive, puis constatez, là aussi, l’absence de récupération automatique du token de session pour le SSO :
Malgré l’absence de SSO, la connexion à AVD depuis le navigateur internet se passe bien. Continuons les tests avec l’application Windows App.
Etape IV – Test de connexion invité depuis Windows App :
Avant de continuer, ouvrez les Paramètres de l’application Windows App, puis vérifiez la version installée :
Ouvrez localement PowerShell en tant qu’administrateur, puis lancez la commande ci-dessous pour forcer l’activation de la nouvelle interface de connexion dans l’application Windows App :
Souci I – Impossible de se connecter malgré une version 24H2 :
Si, malgré le respect des prérequis, il est possible que vous rencontriez le blocage suivant au moment de vous connecter :
Commencez par vérifier que votre utilisateur invité est bien autorisé à ouvrir une session sur votre machine virtuelle AVD via le rôle Azure RBAC suivant :
Ensuite, cela vient peut-être de l’absence du correctif KB5065789 sur votre machine AVD, pourtant en version 24H2.
Pour remédier à cette mise à jour manquante, connectez-vous avec un administrateur sur votre machine AVD, puis lancez la commande PowerShell suivante pour vérifier les correctifs installés :
Retournez sur la page web de Azure Virtual Desktop ouverte avec le compte invité :
Constatez cette fois la bonne ouverture de session sur votre compte invité :
Souci II – Impossible de choisir une entreprise via Windows App :
Si, dans Windows App, le choix d’une authentification alternative n’apparaît pas, et que l’application ne vous propose qu’une adresse e-mail à renseigner :
C’est qu’il vous manque une clef de registre Windows pour faire apparaître ce choix alternatif.
Pour cela, sur votre PC local, ouvrez PowerShell en tant qu’administrateur puis lancez la commande indiquée pour forcer l’activation de la nouvelle interface de connexion dans l’application Windows App :
Fermez, rouvrez l’application Windows App, puis cliquez sur S’authentifier, afin de voir le choix apparaître maintenant :
Souci III – Impossible de se connecter via Windows App – Erreur 7q6ch :
J’ai rencontré ce souci lors de l’authentification dans l’application Windows App, sur 2 postes uniquement. Les autres n’ont posé aucune difficulté.
Malgré une authentification réussie pour mon compte invité, le message d’erreur suivant apparaissait :
Suivi de ce seconde message :
Malgré plusieurs réinstallations de l’application Windows App, je n’ai pas encore trouvé la cause de ce souci. Je suis toujours en contact avec les équipes de Microsoft pour en comprendre la cause.
Conclusion
L’arrivée des identités externes sur Azure Virtual Desktop simplifie enfin l’accès des prestataires et partenaires, sans créer de comptes temporaires.
La fonctionnalité reste en préversion publique avec plusieurs limites (SSO partiel, stratégies Intune incomplètes, pas de support Government/cross-cloud), mais Microsoft annonce déjà des évolutions à venir.
C’est donc le bon moment pour tester, identifier les impacts et se préparer à son adoption lorsque ces restrictions seront levées.
Windows 365 continue d’évoluer et de s’adapter aux nouveaux usages. Après les éditions Business et Enterprise, Microsoft propose depuis quelque temps déjà Windows 365 Frontline, une déclinaison pensée pour les équipes en rotation ou à temps partiel. Bref, pour tous ceux qui n’ont pas besoin d’un Cloud PC huit heures par jour.
Dans cet article, je vous propose de faire le tour complet de Windows 365 Frontline, avec la création des stratégies dans Intune, le provisioning des Cloud PCs, les comportements de session, et les petits détails qu’on ne découvre qu’en le déployant soi-même.
Avant d’aller plus loin, je vous propose la lecture de plusieurs articles sur ce blog, qui parlent de Windows 365 depuis sa GA en 2021 :
Windows 365 Frontline a été présenté pour la première fois en avril 2023 et est devenu disponible en version publique quelques mois plus tard, à l’été 2023.
Windows 365 Frontline est une déclinaison de Windows 365 pensée pour les travailleurs “de première ligne”. Il s’agit de cibler ceux qui n’utilisent pas un poste de travail huit heures par jour, tous les jours, mais travaillant sur leur poste de manière ponctuelle ou en rotation. C’est donc parfait pour les équipes en postes tournant, les centres de support, les services clients, ou les équipes sur le terrain.
Windows 365 Frontline est une version de Windows 365 qui permet aux organisations de réduire les coûts en leur permettant de provisionner un PC cloud qui peut être utilisé par plusieurs utilisateurs avec une seule licence.
L’objectif principal est et reste de réduire le coût des licences Windows 365 tout en gardant la simplicité et la sécurité du Cloud PC.
Quelles sont les limitations de Windows 365 Frontline ?
Windows 365 Frontline apporte une vraie flexibilité, mais il faut connaître ses limites techniques et opérationnelles pour bien l’intégrer dans un environnement d’entreprise :
Un seul utilisateur peut être actif par Cloud PC à la fois : Même si la licence couvre plusieurs utilisateurs, ils ne peuvent pas se connecter simultanément.
Pas de mise en veille prolongée : lorsqu’un utilisateur se déconnecte, la session est suspendue mais reste comptabilisée tant que la VM est “réservée”.
Temps de démarrage à prévoir : la mise en service d’un Cloud PC Frontline peut prendre quelques minutes selon la politique de démarrage configurée.
Windows 365 Frontline Dedicated vs Shared ?
Microsoft propose aujourd’hui deux modes pour Frontline : Dedicated et Shared :
Le mode Dedicated reste le choix recommandé pour des postes attribués en rotation (3 utilisateurs maximum).
Prenons trois collaborateurs travaillant sur des shifts différents (matin, après-midi, nuit) — avec une seule licence Windows 365 Frontline, chacun dispose de son propre Cloud PC pendant son créneau de travail.
On réduit les coûts de licence tout en maintenant une expérience utilisateur complète et sécurisée pour chaque employé.
Le modèle devient particulièrement avantageux à grande échelle : pour 300 employés en rotation, il ne faudrait que 100 licences actives, soit une économie substantielle tout en maintenant une expérience et une sécurité identiques à Windows 365 Entreprise :
Le mode Shared vise les scénarios éphémères où la persistance n’est pas nécessaire (kiosques, formation). Ce mode a été introduit par Microsoft fin 2024. Ce mode est donc conçu pour des tâches courtes et ponctuelles (ex. : formation, inventaire, accès temporaire pour prestataires).
En quelques mots, le Frontline Partagé se distingue du Frontline Dédié sur :
Les Cloud PCs partagés sont réinitialisés après chaque session utilisateur : le profil et les données sont supprimés.
1 licence = 1 Cloud PC partagé : la licence est liée à la machine virtuelle, pas à un utilisateur spécifique.
Les déconnexions automatiques après inactivité libèrent la session, permettant à d’autres utilisateurs d’accéder rapidement au poste.
Idéal pour les scénarios nécessitant un accès rapide et sécurisé à des applications ou outils sans conservation de données persistantes.
Au final, quelles sont les différentes licences Windows 365 ?
Voici un comparatif des différentes licences Windows 365 disponibles :
Feature
Dedicated (Enterprise / Business)
Frontline Dedicated (Standard)
Frontline Shared Mode (Preview)
Cloud PC Usage
1 Cloud PC par utilisateur
3 Cloud PCs partagés entre 3 utilisateurs
Plusieurs Cloud PCs partagés entre de nombreux utilisateurs (1 à la fois)
User Profile
Persistant – sauvegardé entre les sessions
Persistant – chaque utilisateur a son propre bureau
Non persistant – profil supprimé après déconnexion
Concurrent Users
Un utilisateur par Cloud PC
1 utilisateur par Cloud PC à la fois (jusqu’à 3 par licence, en rotation)
Un seul utilisateur à la fois par PC partagé
Session Type
Expérience Windows complète
Expérience Windows complète
Sessions pooled et réinitialisables
Best For
Employés à temps plein utilisant un Cloud PC quotidiennement
Quels sont les prix pour ces licences Windows 365 ?
Les licences Windows 365 Frontline affichent un prix facial plus élevé que les éditions Enterprise ou Business, mais elles sont conçues pour être partagées entre plusieurs utilisateurs.
Autrement dit, il faut raisonner en coût par utilisateur actif plutôt qu’en coût par licence : une approche indispensable pour déterminer la solution la plus avantageuse financièrement selon ton modèle d’usage (rotation, shifts, postes partagés, etc.).
Voici donc un tableau comparatif indicatif (en USD) pour une machine de 4 vCPU / 16 Go RAM, selon les quatre « méthodologies » (Business / Enterprise / Frontline Dedicated / Frontline Shared) de licensing possibles pour Windows 365 :
Méthode / SKU
Prix en €, paiement mensuel engagement annuel
Windows 365 Enterprise
≈ 63 Euros
Windows 365 Business
≈ 63 Euros, avec Windows Hybrid Benefit
Windows 365 Frontline Dedicated
≈ 94.53 € (licence 3 utilisateurs)
Windows 365 Frontline Shared
≈ 94.53 € par poste partagé
Maintenant, il ne nous reste plus qu’à tester tout cela 😎
Pour réaliser cette démonstration sur les licences Windows 365 Frontline, il vous faudra disposer de :
Un tenant Microsoft
Une ou plusieurs licences Windows 365 Frontline
Dans le portail Microsoft 365 Admin Center, on remarque tout de suite que ces licences ne peuvent pas être attribuées directement à des utilisateurs ou à des appareils :
Toujours depuis le portail Admin Center, il n’est pas possible d’associer la licence Frontline à un utilisateur :
Commençons par tester les Cloud PCs Frontline dédiés à des utilisateurs spécifiques.
Test I – Test de Windows 365 Frontline Dédié :
J’ai commencé par créer un groupe sur le portail Entra ID pour mes utilisateurs de test :
Sur le portail Intune, dans la section Polices de provisionnement de Windows 365, je crée une nouvelle police :
Je nomme ma stratégie, je sélectionne le type Frontline et le mode Dedicated :
Je choisis la jointure Entra ID et j’active le Single Sign-On (SSO) :
Je sélectionne une image Windows 11 pour mes Cloud PCs :
Je clique sur Suivant :
Je clique sur Suivant :
Je clique ici pour attribuer une configuration de Cloud PCs :
Je choisis la taille des Cloud PCs, ainsi que leur nombre :
Je clique sur Suivant :
Je clique sur Créer pour valider ma nouvelle police de provisionnement :
Je constate la création de la police de provisionnement de mes PC Frontline :
De retour dans la liste des Cloud PCs, je remarque l’apparition de nouveaux Cloud PCs avec le statut Pending :
En cliquant sur la mention Pending, j’observe un message indiquant plusieurs raisons possibles expliquant ce statut :
Quelques minutes plus tard, le statut Pending passe à Provisioning pour ces Cloud PCs :
Environ un quart d’heure plus tard, les PC apparaissent en statut Provisioned :
Je me connecte avec deux utilisateurs, en simultané, sur le portail Windows 365 Web :
Le premier utilisateur se connecte avec succès à sa session, tandis que le second obtient un message l’informant qu’il ne peut pas accéder au Cloud PC, normal :
Je retourne sur la police de provisionnement et j’augmente le nombre d’instances Windows 365 à 2 pour cette police Frontline :
Je parviens cette fois à connecter trois utilisateurs en simultané, bien que la configuration n’autorise initialement que deux sessions :
Dans les rapports Intune, on constate que la plateforme signale une surcapacité, mais qu’elle a tout de même permis la connexion grâce à la marge de tolérance (buffering) intégrée :
Voici d’ailleurs quelques règles du concurrency buffer pour Windows 365 Frontline :
Le concurrency buffer permet de dépasser temporairement la limite maximale de connexions simultanées permises par les licences Frontline dans des cas de transition comme le changement de shift
Le concurrency buffer ne s’applique pas aux Cloud PCs GPU-enabled ni au mode Frontline Shared.
Il peut être utilisé jusqu’à 4 fois par jour, pour un maximum d’1 heure à chaque activation. L’heure commence dès le dépassement de la limite de licences.
Si le buffer est utilisé de façon excessive (par exemple plus d’une heure à quatre reprises dans 24 heures), un blocage temporaire est activé pendant 48 heures, empêchant toute utilisation du buffer.
Si le tenant subit plus de deux blocages temporaires sur une période de 7 jours, le buffer peut être bloqué de façon permanente. Dans ce cas, il faut ouvrir un ticket auprès du support Intune pour restaurer l’accès.
Pendant le blocage (temporaire ou permanent), les utilisateurs peuvent toujours se connecter, mais uniquement jusqu’à la limite standard de licences (le buffer n’est plus accessible).
Continuons par par tester les Cloud PCs Frontline partagés à des utilisateurs.
Test II – Test de Windows 365 Frontline Partagé :
J’ai créé un second groupe dans le portail Entra ID pour mes utilisateurs de test :
Sur le portail Intune, dans la section Stratégies Windows 365, et je crée une seconde police de provisionnement :
Je nomme ma stratégie, je sélectionne le type Frontline, le mode Shared, je choisis la jointure Entra ID et j’active le SSO :
Je sélectionne une image Windows 11 pour mes Cloud PCs :
Je clique sur Suivant :
Je clique sur Suivant :
Je choisie la taille des Cloud PCs, ainsi que leur nombre :
Je clique sur Créer pour valider ma nouvelle police de provisionnement :
De retour dans la liste des Cloud PCs, je remarque l’apparition du nouveau Cloud PC avec le statut Provisioning :
Environ un quart d’heure plus tard, le Cloud PC apparaît en statut Provisionné :
Je me connecte avec deux utilisateurs, en simultané, sur le portail Windows 365 Web :
Le premier utilisateur se connecte avec succès à sa session, tandis que le second obtient un message l’informant qu’il ne peut pas accéder au Cloud PC :
Sur mon premier utilisateur, je personnalise le bureau et le fond d’écran, je crée un dossier sur le disque C avec un fichier, j’ajoute des éléments sur le bureau et je modifie la barre du menu Démarrer :
Je déconnecte le premier utilisateur et me connecte avec le second ; je constate alors la présence des fichiers locaux sur le disque C :
J’attends environ une heure, puis je me reconnecte avec le premier utilisateur ; je constate la restauration des éléments issus de OneDrive ainsi que des fichiers locaux, mais l’absence du fond d’écran et des raccourcis de la barre des tâches, non pris en charge par OneDrive :
Je lance un reprovisionnement immédiat de ma machine partagée :
Je constate le démarrage du nouveau processus :
Le provisionnement progresse et la nouvelle machine partagée apparaît dans l’environnement :
Quelques minutes plus tard, la nouvelle machine partagée est provisionnée :
Je me reconnecte avec mes deux utilisateurs, en commençant par le premier, et je constate la disparition des fichiers précédemment présents sur le disque C mais la conservation des données sauvegardées sur OneDrive :
Conclusion
Windows 365 Frontline apporte une vraie flexibilité dans la gestion des postes Cloud, surtout pour les environnements en rotation ou à effectif variable.
Le mode Dedicated reste parfait pour les équipes qui se relaient sur un même poste tout en conservant leur propre environnement, tandis que le mode Shared s’adresse davantage aux scénarios temporaires ou sans persistance.
Ce qu’il faut retenir, c’est que Frontline ne vise pas à remplacer les éditions Business ou Enterprise, mais bien à optimiser les coûts et les licences quand tout le monde n’a pas besoin d’un Cloud PC permanent.
Et comme souvent avec Microsoft 365 et Intune, le meilleur moyen de comprendre… c’est de tester soi-même ! 😉
Microsoft continue de faire évoluer Windows 365 pour répondre aux besoins des organisations qui travaillent avec des partenaires externes, freelances ou prestataires. La dernière nouveauté, actuellement en préversion publique, permet de provisionner un Cloud PC pour une identité externe (invité B2B dans votre tenant Microsoft Entra ID).
Fini la création systématique de comptes internes temporaires : les utilisateurs peuvent se connecter avec leur propre identité tout en profitant d’un poste Windows 365 sécurisé.
Qui peut bénéficier de cette nouveauté ?
Nous venons de sortir il y a peu de la préversion privée, et nous sommes donc maintenant en préversion publique, avant une mise à disposition générale (GA) dans plusieurs mois je suppose. Tout utilisateur externe invité dans votre tenant Microsoft Entra ID peut donc en profiter.
Comme rappelé plus haut, les scénarios typiques sont : prestataires, auditeurs, partenaires de développement…
Le flux d’approvisionnement change-t-il pour ces utilisateurs invités ?
Non. Vous utilisez les mêmes polices de provisionnement Windows 365 et le même processus de licence que pour les Cloud PC internes.
Depuis quelles plate-formes le compte invité fonctionne ?
A ce jour où ces lignes sont écrites, la documentation Microsoft mentionne deux moyens possibles :
Cloud PC sous Windows 11 Enterprise avec mise à jour 24H2 (KB5065789) ou plus récente
Cloud PC joint à Entra ID
Police de provisionnement Windows 365 avec Single Sign-On activé
Quelles sont les principales limitations actuellement dans cette préversion ?
Les polices Intune assignées à l’utilisateur externe ne s’appliquent pas (cibler le Cloud PC).
Pas de support pour Windows 365 Government ni pour les invités cross-cloud (Azure Gov, 21Vianet).
Pas d’authentification Kerberos/NTLM vers les ressources on-premises.
Quelques limites sur la Token Protection pour identités externes.
Quelle licence Windows 365 faut-il pour ces utilisateurs invités ?
Comme dit plus haut, il faut bien provisionner une licence dans votre tenant sur le compte invité.
Les licences détenues par un collaborateur externe dans son propre tenant ne confèrent aucun droit pour utiliser un Cloud PC dans votre tenant :
Si vous utilisez Windows 365 avec des identités externes (actuellement en préversion), il peut y avoir des considérations spéciales à prendre en compte pour la façon dont vous accordez des licences à d’autres produits et services de Microsoft pour ces identités externes.
Les licences attribuées à un collaborateur externe dans son propre locataire d’origine ne confèrent généralement pas de droits à Windows 365 ou à d’autres produits au sein de votre locataire. Par conséquent, nous vous recommandons généralement d’acheter le même type de licence que vous achetez pour les utilisateurs internes et de l’attribuer à l’identité du collaborateur externe dans votre locataire.
Par exemple, si vous attribuez des licences Microsoft 365 Apps en même temps que vos PC Windows 365 cloud et que vos collaborateurs externes ont besoin des mêmes droits, achetez une licence Microsoft 365 Apps et attribuez-la au collaborateur externe de votre locataire.
Vous devez donc acheter et attribuer les mêmes licences que pour vos utilisateurs internes (ex. Windows 365 Enterprise/Frontline, Microsoft 365 Apps si nécessaire).
Maintenant, il ne nous reste plus qu’à tester tout cela 😎
Cliquez sur Nouvel utilisateur, puis choisissez Inviter un utilisateur externe :
Renseignez l’adresse e-mail du compte Microsoft Entra de l’invité puis cliquez ici :
Attendez quelques secondes, puis constatez la réception de l’e-mail d’invitation dans la boîte du compte invité, et enfin cliquez sur lien présent dans ce dernier :
Cliquez sur Accepter pour rejoindre le tenant qui vous a invité :
Constatez l’absence du début du provisionnement du Cloud PC :
Vérifiez le groupe d’utilisateurs associé à votre politique de provisionnement Windows 365, puis et ajoutez-lui le nouvel utilisateur invité :
Constatez le début du provisionnement du Cloud PC :
Quelques temps plus tard, constatez le succès du provisionnement pour cet utilisateur invité :
Le provisionnement du Cloud PC est maintenant terminé. Nous allons maintenant pouvoir tester la connexion à ce poste avec notre utilisateur invité.
Etape III – Test de connexion invité depuis le navigateur internet :
Commençons nos tests par le navigateur internet. Pour cela, rendez-vous sur l’URL ci-dessous, puis authentifiez avec le compte invité de votre utilisateur :
https://windows.cloud.microsoft/
Une fois authentifié, constatez l’absence du nouveau Cloud PC provisionné sur votre tenant pour votre compte invité :
Ouvrez une nouvelle page internet en vous connectant, toujours avec le compte invité, sur une autre URL, contenant le domaine de votre tenant :
Vérifiez que l’URL reste bien sur le domaine de votre tenant, et que le Cloud PC invité apparaît :
Cliquez sur Connecter :
Cliquez à nouveau sur Se connecter :
Cliquez sur Oui :
Constatez la bonne ouverture de session de votre compte invité :
Ouvrez Windows Terminal :
Lancez la commande suivante afin d’afficher l’état de l’enregistrement du Cloud PC dans Entra ID :
dsregcmd /status
AzureAdJoined : YES : La machine est bien jointe à Microsoft Entra ID (prérequis principal pour les Cloud PC invités).
EnterpriseJoined : NO
DomainJoined : NO : Normal pour un Cloud PC moderne en mode Entra join (non hybride).
TenantName : JLOUDEV : L’appareil s’est bien inscrit dans le bon tenant.
SSO / Primary Refresh Token :
AzureAdPrt : YES
DeviceAuthStatus : SUCCESS : Le Single Sign-On (SSO) est actif et le Primary Refresh Token (PRT) est bien présent :
Ouvrez Microsoft Edge, puis constatez l’absence de récupération automatique du jeton (token) de connexion pour le SSO :
Ouvrez Microsoft OneDrive, puis constatez, là aussi, l’absence de récupération automatique du token de session pour le SSO :
Malgré l’absence de SSO, la connexion depuis le navigateur internet se passe bien. Continuons les tests avec l’application Windows App.
Etape IV – Test de connexion invité depuis Windows App :
Avant de continuer, ouvrez les Paramètres de l’application Windows App, puis vérifiez la version installée :
Ouvrez PowerShell en tant qu’administrateur, puis lancez la commande ci-dessous pour forcer l’activation de la nouvelle interface de connexion dans l’application Windows App :
Souci I – Impossible de se connecter malgré une version 24H2 :
Si, malgré le respect des prérequis, il est possible que vous rencontriez le blocage suivant au moment de vous connecter :
Ou ce message d’erreur là :
Cela vient peut-être de l’absence du correctif KB5065789 sur votre Cloud PC, pourtant en version 24H2.
Pour remédier à cette mise à jour manquante, retournez sur le portail Entra ID pour ajouter un utilisateur de votre tenant aux administrateurs locaux des machines jointes à Entra ID :
Ensuite, retournez sur le portail Azure pour récupérer l’adresse IP locale du Cloud PC invité :
Depuis un autre Cloud PC auquel vous avez déjà accès, connectez-vous à cette IP locale avec un des comptes administrateurs :
Attendez que l’ouverture de session se fasse :
Lancez la commande PowerShell suivante pour vérifier les correctifs installés :
Si besoin, allez dans Windows Update puis lancez la recherche de mises à jour :
Redémarrez si nécessaire :
Rouvrez la session avec l’administrateur local, puis relancez Windows Update si besoin :
Redémarrez à nouveau, si nécessaire :
Vérifiez avec la commande PowerShell que le correctif KB5065789 (24H2) est maintenant bien présent :
Retournez sur la page web de Windows 365 ouverte avec le compte invité :
Constatez cette fois la bonne ouverture de session sur votre compte invité :
Souci II – Impossible de choisir une entreprise via Windows App :
Si, dans Windows App, le choix d’une authentification alternative n’apparaît pas, et que l’application ne vous propose qu’une adresse e-mail à renseigner :
C’est qu’il vous manque une clef de registre Windows pour faire apparaître ce choix alternatif.
Pour cela, sur votre PC local, ouvrez PowerShell en tant qu’administrateur puis lancez la commande indiquée pour forcer l’activation de la nouvelle interface de connexion dans l’application Windows App :
Fermez, rouvrez l’application Windows App, puis cliquez sur S’authentifier, afin de voir le choix apparaître maintenant :
Souci III – Impossible de se connecter via Windows App – Erreur 7q6ch :
J’ai rencontré ce souci lors de l’authentification dans l’application Windows App, sur 2 postes uniquement. Les autres n’ont posé aucune difficulté.
Malgré une authentification réussie pour mon compte invité, le message d’erreur suivant apparaissait :
Suivi de ce seconde message :
Malgré plusieurs réinstallations de l’application Windows App, je n’ai pas encore trouvé la cause de ce souci. Je suis toujours en contact avec les équipes de Microsoft pour en comprendre la cause.
Conclusion
L’arrivée des Cloud PC Windows 365 pour identités externes simplifie enfin l’accès des prestataires et partenaires, sans créer de comptes temporaires.
La fonctionnalité reste en préversion publique avec plusieurs limites (SSO partiel, stratégies Intune incomplètes, pas de support Government/cross-cloud), mais Microsoft annonce déjà des évolutions à venir.
C’est donc le bon moment pour tester, identifier les impacts et se préparer à son adoption lorsque ces restrictions seront levées.
Attendez-vous au prochain article sur Azure Virtual Desktop 😎🤘😉
Microsoft met à disposition un nouveau lab sympa pour tester la création et l’intégration de serveurs Model Context Protocol (MCP) dans Copilot Studio. Voici un exemple concret d’implémentation d’un serveur MCP, interrogeant ici un endpoint public qui renvoie une blague Chuck Norris aléatoire sous forme de JSON, et que l’on peut déployer localement ou sur Azure.
Qu’est-ce que le MCP ?
Pour rappel, le Model Context Protocol (MCP) est un standard ouvert qui permet de connecter simplement des sources de données ou des API à des modèles d’IA.
J’ai déjà publié plusieurs articles à ce sujet sur mon blog ; vous pouvez les retrouver juste ici :
MCP vs API traditionnelles : quelles différences ?
Pour comprendre l’importance du MCP, comparons-le aux API REST traditionnelles :
Caractéristique
MCP
API REST traditionnelles
Communication
Bidirectionnelle et en temps réel
Généralement requête-réponse unidirectionnelle
Découverte d’outils
Automatique et dynamique
Configuration manuelle nécessaire
Conscience du contexte
Intégrée
Limitée ou inexistante
Extensibilité
Plug-and-play
Effort d’intégration linéaire
Standardisation
Protocole unifié pour tous les modèles
Variable selon les services
Orientation
Conçu spécifiquement pour les modèles d’IA
Usage général
Cette standardisation représente un changement de paradigme pour quiconque souhaite développer des applications IA véritablement connectées.
Architecture et fonctionnement du MCP :
L’architecture du MCP repose sur trois composants principaux qui interagissent de façon coordonnée :
Les composants clés du MCP
Hôtes MCP : Ce sont les applications qui intègrent l’IA et ont besoin d’accéder à des données externes. Par exemple, Claude Desktop, un IDE comme Cursor, ou toute application intégrant un LLM.
Clients MCP : Ce sont des intermédiaires qui maintiennent les connexions sécurisées entre l’hôte et les serveurs. Chaque client est dédié à un serveur spécifique pour garantir l’isolation.
Serveurs MCP : Ce sont des programmes externes qui fournissent des fonctionnalités spécifiques et se connectent à diverses sources comme Google Drive, Slack, GitHub, ou des bases de données.
Le flux de communication MCP se déroule typiquement en quatre étapes bien définies :
Découverte : L’hôte (comme Claude Desktop) identifie les serveurs MCP disponibles dans son environnement
Inventaire des capacités : Les serveurs MCP déclarent leurs fonctionnalités disponibles (outils, ressources, prompts)
Sélection et utilisation : Quand l’utilisateur pose une question nécessitant des données externes, l’IA demande l’autorisation d’utiliser un outil spécifique
Exécution et retour : Le serveur MCP exécute l’action demandée (recherche web, accès à un fichier, etc.) et renvoie les résultats à l’IA qui peut alors formuler une réponse complète
Ce processus standardisé permet une communication fluide entre l’IA et les sources de données externes, tout en maintenant un contrôle transparent pour l’utilisateur.
Que propose Microsoft dans ce lab ?
Cette page explique comment tester un serveur MCP en local ou hébergé sur Azure :
Ce guide constitue donc un point de départ idéal pour expérimenter la connexion et l’interaction entre un serveur MCP et Copilot.
L’exercice consiste à configurer un serveur MCP, d’abord sur Azure puis en local, afin de comprendre son fonctionnement et tester ses outils :
La première partie de l’exercice consiste à déployer sur Azure Container Apps pour valider le bon fonctionnement du serveur MCP hébergé.
La seconde partie de l’exercice consiste à le redéployer en local cette fois-ci.
Dans les deux cas, vous expérimentez les actions soit directement au travers de prompts.
Microsoft propose également une vidéo YouTube qui illustre pas à pas la mise en place de ce lab MCP et son intégration dans Copilot Studio. Idéale pour suivre visuellement chaque étape :
Maintenant, il ne nous reste plus qu’à tester tout cela 😎
Commençons par déployer notre serveur MCP de test sur Azure.
Etape I – Test de déploiement sur Azure :
Cliquez sur le bouton suivant pour créer un nouveau repository sur votre compte GitHub :
Nommez le repository, choisissez sa visibilité, puis cliquez sur Créer :
Dans une fenêtre Powershell, lancez la commande suivante pour installer le module Azure Developer CLI (azd) :
winget install microsoft.azd
Exécutez la commande suivante pour télécharger les fichiers du repository en adaptant la variable de votre compte :
git clone https://github.com/{account}/mcsmcp.git
Ouvrez Visual Studio Code et chargez le dossier correspondant à l’archive téléchargée :
Lancez la commande suivante pour vous connecter à votre compte Azure :
azd auth login
Complétez l’authentification via le navigateur Internet de votre choix :
Lancez la commande pour déployer les ressources sur Azure :
azd up
Donnez un nom à votre environnement Azure :
Sélectionnez la souscription Azure à utiliser :
Choisissez la région Azure appropriée :
Patientez quelques minutes pendant le déploiement :
Constatez l’apparition des ressources dans le portail Azure :
Attendez la confirmation de fin de déploiement avec succès :
Rafraîchissez la page des ressources Azure et cliquez sur le Container App déployé :
Vérifiez dans les réplicas que le conteneur de l’application est bien en statut Running :
Retournez sur la page principale pour récupérer l’URL de votre déploiement :
Collez cette URL dans un navigateur en ajoutant/mcp pour vérifier le message d’erreur attendu (preuve que le service tourne) :
Notre environnement Azure est maintenant en place, nous pouvons passer directement à l’étape III afin de déployer notre connecteur MCP dans un nouvel agent sur Copilot Studio.
Etape II – Test de déploiement en local :
Lancez la commande npm install pour installer les dépendances nécessaires du projet :
npm install
Exécutez la commande suivante pour compiler et démarrer le serveur MCP en local :
pm run build && npm run start
Copiez l’URL affichée par le serveur et ouvrez-la dans un navigateur pour vérifier le message d’erreur attendu (preuve que le serveur fonctionne) :
localhost:3000/mcp
Lancez la commande ngrok suivante pour exposer votre serveur MCP local sur Internet :
ngrok http http://localhost:3000
Copiez l’URL publique générée par ngrok :
Ouvrez-la dans un navigateur (en ajoutant /mcp) pour tester le bon fonctionnement du serveur :
Lancez la commande suivante pour démarrer l’outil MCP Inspector :
npx @modelcontextprotocol/inspector
Dans l’interface web de MCP Inspector, collez l’URL publique (ngrok) de votre serveur MCP puis cliquez sur Connecter :
Cliquez sur Lister les outils pour afficher les outils disponibles sur le serveur MCP :
Sélectionnez l’un des outils listés puis lancez-le pour exécuter une action :
Constatez l’apparition d’une blague Chuck Norris renvoyée par le serveur MCP, signe que tout fonctionne correctement :
Notre environnement Local est maintenant en place, nous pouvons passer directement à l’étape III afin de déployer notre connecteur MCP dans un nouvel agent sur Copilot Studio.
Etape III – Création de l’agent dans Copilot Studio :
Rendez-vous dans Copilot Studio pour créer un nouvel agent :
Donnez un nom à votre agent :
Jokester
Ajoutez une description à votre agent :
A humor-focused agent that delivers concise, engaging jokes only upon user request, adapting its style to match the user's tone and preferences. It remains in character, avoids repetition, and filters out offensive content to ensure a consistently appropriate and witty experience.
Définissez les instructions de l’agent :
You are a joke-telling assistant. Your sole purpose is to deliver appropriate, clever, and engaging jokes upon request. Follow these rules:
- Respond only when the user asks for a joke or something related (e.g., "Tell me something funny").
- Match the tone and humor preference of the user based on their input—clean, dark, dry, pun-based, dad jokes, etc.
- Never break character or provide information unrelated to humor.
- Keep jokes concise and clearly formatted.
- Avoid offensive, discriminatory, or NSFW content.
- When unsure about humor preference, default to a clever and universally appropriate joke.
- Do not repeat jokes within the same session.
- Avoid explaining the joke unless explicitly asked.
- Be responsive, witty, and quick.
Ajoutez des prompts suggérés pour guider l’usage :
Cliquez sur Créer pour finaliser la création de l’agent :
Attendez quelques secondes :
Allez dans l’onglet Outils et cliquez sur Ajouter un outil :
Sélectionnez le type Model Context Protocol, puis ajoutez un nouvel outil :
Sélectionnez le type Model Context Protocol pour ajouter un outil MCP :
Renseignez un nom, une description et l’URL publique terminant par /mcp, puis créez sans authentification :
Créez une nouvelle connexion pour ce serveur MCP :
Cliquez sur Créer pour valider la connexion
Cliquez sur Ajouter et configurer pour intégrer l’outil à l’agent :
Constatez l’apparition des outils MCP dans votre connecteur MCP :
Cliquez sur Tester et envoyez un prompt demandant une blague :
Tell me a Chuck Norris joke
Vérifiez la réponse renvoyée par le serveur MCP :
Cliquez sur Publier pour mettre votre agent à disposition :
Confirmez la publication en cliquant à nouveau sur Publier :
Patientez quelques secondes le temps que la publication se termine :
Ouvrez l’onglet Canaux pour activer la mise à disposition sur Teams et Microsoft 365 Copilot :
Cliquez sur Publier à nouveau pour confirmer l’activation :
Cliquez sur Publier à nouveau pour confirmer l’activation :
Patientez quelques secondes le temps que la publication se termine :
Rouvrez Teams / Microsoft 365 Copilot puis cliquez sur le lien suivant :
Dans Microsoft 365 Copilot Chat, cliquez sur Ajouter votre agent :
Testez les prompts suggérés mis à disposition :
Si un message d’erreur concernant du filtrage apparaît :
Retournez dans la configuration pour ajuster la modération de l’agent :
Cliquez de nouveau sur Publier après avoir modifié la modération :
Revenez sur Microsoft 365 Copilot Chat et retestez un prompt :
Vérifiez que la réponse s’affiche correctement :
Testez à nouveau avec d’autres prompts suggérés :
En voyant certaines blagues, je comprends que Copilot ai pu vouloir en filtrer 😂 :
Conclusion
Le Model Context Protocol (MCP) n’est plus une simple curiosité technique : il s’impose comme un standard ouvert pour connecter intelligemment nos IA aux sources de données et services externes.
Avec ce lab proposé par Microsoft, on peut expérimenter très concrètement l’intégration d’un serveur MCP dans Copilot Studio, que ce soit sur Azure ou en local.
Ce qui m’a particulièrement plu, c’est la simplicité du déploiement : quelques commandes suffisent pour tester un serveur, valider son fonctionnement, puis l’exposer directement à un agent Copilot.
Cela ouvre la voie à des scénarios bien plus avancés : connecter des bases de données internes, des outils métiers, ou encore enrichir vos assistants IA avec des fonctionnalités maison.