L’accès conditionnel se construit d’ordinaire stratégie par stratégie, sans vue d’ensemble, et le moteur vient en plus de changer de comportement : depuis le 15 juin 2026, des connexions jusque-là épargnées déclenchent la MFA. Le centre d’administration Microsoft Entra expose aussi une entrée « Policy plans » pour assembler les stratégies. Vous saurez quoi auditer dans votre tenant, quelles échéances planifier et comment tester une stratégie en mode rapport seul avec Microsoft Graph PowerShell.
Plans de stratégie : une nouvelle façon d’assembler l’accès conditionnel
Dans l’espace d’accès conditionnel du centre d’administration Microsoft Entra (entra.microsoft.com), une entrée Policy plans permet de créer un plan vierge au lieu de partir d’un modèle. Un environnement « What if » est proposé au même endroit, et la liste se filtre par nom, description ou tag.
Le plan sert à regrouper des stratégies plutôt qu’à en créer une seule. L’interface les présente sous la forme d’un tracé façon plan de métro, ce qui rend lisible l’enchaînement identités, ressources, conditions et contrôles. Un plan porte aussi un propriétaire (avec des propriétaires supplémentaires possibles) et des tags de recherche, deux champs absents des stratégies classiques. Ils répondent à une vraie question de gouvernance : qui répond d’un ensemble de règles.
Statut des plans de stratégie non confirmé
Au 29 octobre 2026, je n’ai trouvé dans la documentation officielle Microsoft aucune page qui décrive les plans de stratégie. Ce qui suit relève donc d’une démonstration de l’interface : ni statut (préversion ou disponibilité générale) ni licence ne sont confirmés. Consultez le journal des nouveautés Entra avant de bâtir un processus dessus.
Construire un plan : identités, ressources, conditions, contrôles
Le parcours suit cinq étapes. Chacune regroupe ce que l’éditeur de stratégie classique répartit sur plusieurs panneaux.
Choisir les identités
Sélectionnez des utilisateurs et groupes ou des identités de charge de travail (workload identities). L’option agents n’apparaissait pas dans le tenant de démonstration, faute de licence Microsoft Copilot ; la documentation Microsoft Learn traite le ciblage des agents séparément (voir plus bas).
Pour les utilisateurs, des cases à cocher distinguent les invités internes, les invités de collaboration B2B, les membres de collaboration, B2B direct connect, les fournisseurs de services (un MSP, par exemple) et d’autres types externes. Les rôles d’annuaire sont aussi ciblables, avec inclusions et exclusions.
Définir les ressources partagées
Ciblez des ressources, des actions utilisateur ou un contexte d’authentification, avec applications incluses et exclues. Le tenant de démonstration visait Microsoft 365 et les portails d’administration, sans exclusion.
Poser les conditions
Choisissez parmi les risques, les plateformes, les emplacements réseau, les applications clientes et les filtres d’appareil détaillés dans le tableau ci-dessous.
Régler contrôles d’octroi et de session
Côté octroi : bloquer, autoriser, exiger la MFA ou une force d’authentification (par exemple MFA sans mot de passe), un appareil conforme ou l’acceptation des conditions d’utilisation. Côté session : fréquence de connexion et persistance. Dans l’interface observée, la réauthentification périodique proposait une valeur par défaut d’un jour ; elle peut descendre à une réauthentification à chaque fois, utile seulement pour des environnements très sensibles.
Nommer le plan et choisir son état
L’état se règle en haut de l’écran. Le mode rapport seul est la valeur par défaut : la stratégie est évaluée et journalisée, sans être appliquée. Une fois créé, le plan affiche ses résultats (connexions réussies, sollicitées, échouées) et s’exporte, avec une vue JSON.
Le tableau suivant résume les conditions vues dans l’éditeur et les points d’attention qui en découlent.
| Condition | Options observées | Point d’attention |
|---|---|---|
| Risque utilisateur / risque de connexion | Niveaux de risque issus d’Identity Protection | Exige Microsoft Entra ID P2 |
| Risque interne (Insider risk) | Proposé dans la liste des conditions | Non détaillé dans la démonstration |
| Plateformes d’appareil | iOS, Windows, macOS et Linux | Linux figure désormais dans la liste |
| Emplacement réseau | Tous les emplacements ou emplacements définis | S’appuie sur Global Secure Access si configuré |
| Applications clientes | Clients modernes ou anciens (Exchange ActiveSync) | Les protocoles hérités ne gèrent pas l’authentification moderne |
| Filtre pour les appareils | Propriété, fabricant, modèle | Utile pour les postes d’administration privilégiés ; remplace Device state |
| Flux d’authentification | Scénarios multi-appareils | À laisser non configuré sauf besoin identifié |
Un exemple d’usage : une équipe d’administrateurs sur site limitée à des postes d’entreprise d’un fabricant précis. Le filtre combine propriétaire de l’appareil égal à entreprise et fabricant, puis le plan impose une MFA sans mot de passe. Les stratégies d’administration restent ainsi dans un seul objet lisible.
Ce qui change dans le moteur : échéances à auditer
Les plans de stratégie sont un confort d’administration. Les changements qui suivent, eux, modifient ce que vivent vos utilisateurs.
Mars 2026
Agent d’optimisation en préversion
Le Conditional Access Optimization Agent de Security Copilot peut déployer par phases n’importe quelle stratégie en mode rapport seul (préversion).
15 juin 2026
Baseline scopes
Les stratégies ciblant All resources avec exclusions de ressources s’appliquent aussi aux connexions demandant uniquement des étendues de base.
Juin 2026
Agents IA en préversion publique
L’accès conditionnel étend sa protection aux comptes utilisateurs d’agents IA.
6 juillet 2026
Enregistrement des identifiants sans mot de passe
Les stratégies visant l’action Register security information couvrent aussi Windows Hello for Business et macOS Platform SSO (date de la page Learn).
30 septembre 2026
Retrait des Custom controls
Date de retrait fixée au profit d’External MFA ; les configurations existantes continuent de fonctionner pendant la transition.
Mai 2027
Fin de vie des Custom controls
Échéance définitive pour terminer la migration vers External MFA.
Baseline scopes : pourquoi la MFA apparaît dans VS Code ou Azure CLI
La documentation Microsoft Learn précise que depuis le 15 juin 2026, une stratégie qui cible All resources avec des exclusions s’applique aussi aux connexions qui ne demandent que des étendues de base (OIDC ou répertoire), par exemple VS Code ou Azure CLI avec User.Read. Des utilisateurs reçoivent donc une demande de MFA qu’ils n’avaient jamais vue. Les administrateurs peuvent ajuster ou reporter ce comportement dans les paramètres Baseline scopes.
Auditez vos stratégies All resources avec exclusions
Recensez toute stratégie All resources qui exclut des ressources, puis comparez les demandes de MFA de vos postes d’ingénierie avec ce changement avant d’ouvrir un incident.
Custom controls, enregistrement des identifiants, Device state
Trois autres points demandent une décision :
- Custom controls : les configurations continuent de fonctionner, mais la migration vers External MFA doit être planifiée avant la fin de vie de mai 2027.
- Register security information : la MFA reste exigée par défaut pour enregistrer des identifiants sans mot de passe. La page Learn indique le 6 juillet 2026 alors qu’un billet Tech Community annonçait le 13 juillet 2026 ; référez-vous à la page Learn.
- Device state : cette condition est obsolète. Microsoft recommande Filtre pour les appareils, que vous retrouvez dans le plan de stratégie.
Agents IA : accès conditionnel et blueprints d’identité
Depuis juin 2026, en préversion publique, l’accès conditionnel protège aussi les comptes utilisateurs d’agents IA. Vous ciblez des agents précis ou des groupes dynamiques fondés sur des Custom Security Attributes. Une condition de risque d’agent (Agent Risk), des appareils conformes (y compris Windows 365 for Agents), les plateformes et filtres d’appareil et le réseau conforme sont disponibles.
La condition réseau a une limite : pour les comptes d’agents, elle ne s’applique que si l’appareil fournit le signal requis, par exemple via le client Global Secure Access.
Un réglage de départ mérite votre attention : dans Users, puis User settings, les permissions par défaut incluent désormais la possibilité pour les utilisateurs d’enregistrer des blueprints d’identité d’agent (agent identity blueprints). Ce réglage est activé par défaut. Si vous ne voulez pas que chaque utilisateur crée ces objets, désactivez-le.
Réglage tenant activé par défaut
Le paramètre touche tous les utilisateurs. Décidez de la politique de création d’agents avant de désactiver quoi que ce soit, puis communiquez-la aux équipes qui expérimentent déjà.
Côté automatisation, le Conditional Access Optimization Agent peut aussi proposer des campagnes d’adoption des passkeys, d’abord pour les rôles administrateurs, et crée ses stratégies en mode rapport seul. Pour le volet passkeys, notre guide approfondi sur les passkeys Entra détaille le déploiement.
OneDrive et Exchange Web Services : deux réglages à vérifier
L’interface OneDrive a changé : le bouton de création et de téléversement passe à droite, avec des raccourcis pour créer un document Word, Excel, PowerPoint ou PDF. Le partage d’un dossier affiche les paramètres du lien (tout le monde, personnes de l’organisation, personnes spécifiques) et l’état de partage du dossier.
Points forts
- Paramètres du lien et état du partage lisibles au même endroit
- Raccourcis de création de documents
- Copie du lien et envoi vers un contact Outlook
Limites
- Les paramètres avancés renvoient vers les anciens réglages SharePoint
L’option « tout le monde » reste pilotable : un administrateur peut la désactiver dans les paramètres de partage du tenant.
Dans le centre d’administration Microsoft 365, sous Paramètres, Paramètres de l’organisation, Sécurité et confidentialité, le mode de sécurité de base (Baseline security mode) propose dans sa section Authentification de bloquer l’accès à Exchange Web Services. Activez-le seulement si votre migration depuis les anciennes versions d’Exchange est terminée et qu’aucune application métier n’appelle encore ce protocole. Un inventaire des clients avant bascule évite de casser un connecteur oublié.
Mise en œuvre
Les plans de stratégie ne disposent pas d’une documentation d’API que j’aie pu vérifier. Le script ci-dessous manipule donc une stratégie d’accès conditionnel classique via Microsoft Graph PowerShell : il crée en mode rapport seul le blocage des clients hérités (Exchange ActiveSync et autres protocoles hérités), avec exclusion d’un groupe de comptes de secours.
- Module :
Install-Module Microsoft.Graph.Identity.SignIns -Scope CurrentUser(etMicrosoft.Graph.Reportspour la vérification). - Rôle minimum : Conditional Access Administrator.
- Scopes :
Policy.ReadWrite.ConditionalAccess,Policy.Read.AlletApplication.Read.All. - Sortie : l’identifiant, le nom et l’état de la stratégie créée, ou le corps JSON en mode simulation.
1#Requires -Modules Microsoft.Graph.Identity.SignIns2[CmdletBinding()]3param(4 # Identifiant du groupe de comptes de secours à exclure (à remplacer)5 [Parameter(Mandatory)][string]$BreakGlassGroupId,6 [string]$PolicyName = 'CA-BLOCK-LEGACY-AUTH-REPORT-ONLY',7 # Simulation : affiche le corps sans rien créer8 [switch]$DryRun9)10 11Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess','Policy.Read.All','Application.Read.All' -NoWelcome12 13# Évite de créer un doublon14$existing = Get-MgIdentityConditionalAccessPolicy -All | Where-Object { $_.DisplayName -eq $PolicyName }15if ($existing) {16 throw ('Une stratégie nommée {0} existe déjà (Id {1}).' -f $PolicyName, $existing.Id)17}18 19# Stratégie en mode rapport seul : évaluée et journalisée, jamais appliquée20$body = @{21 displayName = $PolicyName22 state = 'enabledForReportingButNotEnforced'23 conditions = @{24 clientAppTypes = @('exchangeActiveSync', 'other')25 applications = @{ includeApplications = @('All') }26 users = @{27 includeUsers = @('All')28 excludeGroups = @($BreakGlassGroupId)29 }30 }31 grantControls = @{32 operator = 'OR'33 builtInControls = @('block')34 }35}36 37if ($DryRun) {38 Write-Host 'Mode simulation : aucune stratégie créée. Corps de la requête :'39 $body | ConvertTo-Json -Depth 640 return41}42 43$created = New-MgIdentityConditionalAccessPolicy -BodyParameter $body44$created | Select-Object Id, DisplayName, StateLancez d’abord .\New-CaLegacyAuthReportOnly.ps1 -BreakGlassGroupId '<GUID du groupe>' -DryRun, puis relancez sans -DryRun. L’état attendu en sortie est enabledForReportingButNotEnforced.
Vérifier ce que la stratégie aurait bloqué
Le bloc suivant regroupe les résultats de la stratégie dans les journaux de connexion (rôle Reports Reader, scope AuditLog.Read.All). Un résultat reportOnlyFailure désigne une connexion qui aurait été bloquée. Une sortie vide signifie qu’aucune connexion de cet échantillon ne concernait la stratégie ; un délai d’apparition dans les journaux est possible.
1$policyName = 'CA-BLOCK-LEGACY-AUTH-REPORT-ONLY'2Connect-MgGraph -Scopes 'AuditLog.Read.All' -NoWelcome3 4Get-MgAuditLogSignIn -Top 200 |5 ForEach-Object {6 $signIn = $_7 $signIn.AppliedConditionalAccessPolicies |8 Where-Object { $_.DisplayName -eq $policyName } |9 ForEach-Object {10 [pscustomobject]@{11 Utilisateur = $signIn.UserPrincipalName12 Application = $signIn.AppDisplayName13 ClientApp = $signIn.ClientAppUsed14 Resultat = $_.Result15 }16 }17 } |18 Group-Object -Property Resultat |19 Select-Object Name, CountQuand les résultats sont propres (aucun usage légitime bloqué), passez à l’application avec le bloc ci-dessous.
Activation : impact sur tout le tenant
Passer la stratégie à l’état enabled bloque réellement tous les utilisateurs non exclus qui utilisent encore des protocoles hérités. Vérifiez d’abord le groupe de comptes de secours et la liste des applications concernées. Pour revenir en arrière, repassez l’état à enabledForReportingButNotEnforced.
1# Remplacez par l’Id affiché à la création2$policyId = '<Id de la stratégie>'3Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policyId -BodyParameter @{ state = 'enabled' }4Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policyId | Select-Object DisplayName, StateContrôles après déploiement
- La stratégie affiche l’état attendu dans le portail et dans la sortie PowerShell
- Le groupe de comptes de secours figure bien dans les exclusions
- Les journaux de connexion ne montrent aucun usage légitime en
reportOnlyFailure - Les équipes concernées ont été prévenues avant l’activation
Dépannage
| Symptôme | Cause probable | Résolution |
|---|---|---|
| MFA soudaine dans VS Code ou Azure CLI | Stratégie All resources avec exclusions appliquée aux étendues de base depuis le 15 juin 2026 | Examiner les paramètres Baseline scopes pour ajuster ou reporter le comportement |
| Option agents absente de l’éditeur | Dans la démonstration, le tenant n’avait pas la licence Microsoft Copilot | Vérifier le statut dans le journal des nouveautés Entra, sans présumer de la licence |
| Conditions de risque indisponibles | Licence Microsoft Entra ID P2 manquante | Vérifier l’attribution des licences P2 |
| Condition réseau ignorée pour un agent | L’appareil ne fournit pas le signal réseau requis | Déployer le client Global Secure Access |
| Stratégie basée sur Device state | Condition obsolète | Migrer vers la condition Filtre pour les appareils |
| Contrôle personnalisé encore en place | Custom controls en retrait au profit d’External MFA | Planifier la migration avant mai 2027 |
| Erreur d’autorisation à l’exécution du script | Scope manquant ou rôle insuffisant | Se reconnecter avec les trois scopes et le rôle Conditional Access Administrator |
Questions fréquentes
Quelle licence faut-il pour les conditions de risque dans une stratégie ?
Les conditions fondées sur le risque (risque utilisateur et risque de connexion) reposent sur Identity Protection et exigent Microsoft Entra ID P2. Les autres conditions de l’éditeur n’ont pas fait l’objet d’une confirmation de licence dans les sources consultées.
Les plans de stratégie sont-ils en disponibilité générale ?
Le statut n’est pas confirmé : aucune page de documentation officielle consultée ne décrit cette fonction. Surveillez le journal des nouveautés Entra, qui précise le statut de chaque fonction (préversion ou disponibilité générale).
Pourquoi mes développeurs reçoivent-ils une MFA qu’ils n’avaient pas ?
Depuis le 15 juin 2026, les stratégies ciblant All resources avec des exclusions de ressources s’appliquent aussi aux connexions qui ne demandent que des étendues de base, comme VS Code ou Azure CLI avec User.Read. Les paramètres Baseline scopes permettent d’ajuster ou de reporter ce comportement.
Mes contrôles personnalisés cessent-ils de fonctionner immédiatement ?
Non. Leur retrait est fixé au 30 septembre 2026 et leur fin de vie à mai 2027, mais les configurations existantes continuent de fonctionner pendant la transition. La migration vers External MFA doit tout de même être planifiée.
Par où commencer : quatre vérifications ordonnées
Commencez par ce qui touche vos utilisateurs aujourd’hui, puis passez à ce qui se prépare.
- Listez vos stratégies All resources avec exclusions et comparez-les aux demandes de MFA constatées depuis le 15 juin 2026.
- Inventoriez vos Custom controls et planifiez leur migration vers External MFA avant mai 2027.
- Décidez si les utilisateurs peuvent enregistrer des blueprints d’identité d’agent, puis ajustez le réglage par défaut.
- Testez toute nouvelle règle en mode rapport seul, avec le script ci-dessus ou un plan de stratégie.
Si votre organisation expérimente déjà des agents IA, alors traitez le ciblage des agents et le réglage des blueprints avant les plans de stratégie : ce sont eux qui exposent le plus votre tenant. Si elle utilise encore Exchange Web Services pour des applications métier, repoussez le blocage du mode de sécurité de base jusqu’à la fin de l’inventaire. Pour suivre le calendrier global, notre revue des nouveautés Microsoft 365 de juillet 2026 complète ce panorama.
Pour aller plus loin
- Microsoft Entra releases and announcements (What’s new) : le journal mensuel des nouveautés Entra, avec le statut de chaque fonction.
- Improved enforcement for All resources policies with resource exclusions : le changement d’application depuis juin 2026 et les paramètres pour le piloter.
- Microsoft Entra ID security updates: What organizations need to do now : les échéances à préparer, dont le retrait des Custom controls.
- Conditional Access: Conditions : la référence sur les conditions et celles devenues obsolètes.
