Les mêmes administrateurs ciblés, les mêmes comptes d'urgence exclus, recopiés dans dix stratégies : c'est le quotidien d'un accès conditionnel géré à plat. Microsoft Entra ID propose en préversion publique, annoncée fin octobre 2026, les plans de stratégie d'accès conditionnel, qui regroupent ces règles autour d'un objectif de sécurité. Ce tutoriel vous montre comment lire vos stratégies actuelles, construire un plan de durcissement et migrer en mode rapport seulement, sans surprise en production.
Ce que changent les plans d'accès conditionnel, et ce qu'ils laissent intact
Un plan est un conteneur associé à un objectif de sécurité, par exemple protéger les comptes administratifs. Il porte une configuration partagée (identités, ressources, conditions) et plusieurs règles qui ajoutent chacune leur contrôle : MFA (authentification multifacteur) résistante au phishing, appareil conforme, durée de session. Là où vous aviez trois stratégies distinctes, vous avez un plan et trois règles qui héritent du même socle.
Côté moteur, rien ne change. D'après la documentation Microsoft Learn, les plans ne remplacent pas les stratégies existantes : stratégies classiques et règles de plan sont évaluées indépendamment, sans priorité entre elles, et toutes celles qui s'appliquent doivent être satisfaites. Chaque règle apparaît séparément dans les journaux de connexion.
Un exemple d'illustration : Alex se connecte depuis un poste Windows. Une règle qui bloque les plateformes non prises en charge ne l'affecte pas, mais une seconde règle exige un appareil conforme. Si l'appareil est non conforme, l'accès est refusé, exactement comme avec deux stratégies classiques.
Préversion, licence P1 ou P2 et rôle dédié
La documentation Microsoft Learn (consultée le 8 novembre 2026) indique que les plans sont toujours en préversion publique. L'annonce officielle sur Tech Community précise la licence requise (Microsoft Entra ID P1 ou P2) et le rôle minimal (Administrateur de l'accès conditionnel). Le menu se trouve sous Entra ID > Accès conditionnel > Policy plans (Preview).
Conditions partagées ou règles : où placer chaque paramètre
Le modèle est additif et non soustractif : le plan définit un socle, les règles l'enrichissent mais ne peuvent pas le réduire. Cette contrainte structure toute la conception.
| Élément | Niveau plan (conditions partagées) | Niveau règle |
|---|---|---|
| Ciblage | Socle hérité par chaque règle, impossible à réduire | S'ajoute au socle du plan |
| Tous les utilisateurs | Non disponible | Disponible |
| Exclusions (comptes d'urgence) | Cumulées, impossibles à retirer depuis une règle | Exclusions supplémentaires possibles, qui s'accumulent |
| Contrôles d'octroi et de session | Non concerné | Définis ici, règle par règle |
| Rôles d'annuaire, applications, actions utilisateur, risque utilisateur | Possibles comme socle commun | Possibles comme précision additionnelle |
Trois conséquences pratiques. D'abord, les conditions partagées sont facultatives : un plan « accès aux appareils et aux applications » peut n'en définir aucune, chaque règle portant alors sa propre cible. Ensuite, ne mutualisez que ce que plusieurs règles partagent vraiment, comme « toujours les administrateurs, toujours sans les comptes d'urgence ». Enfin, enregistrer une modification du socle d'un plan l'applique à toutes les règles en aval.
La documentation précise aussi que les types d'identité (utilisateurs, agents, identités de charge de travail) ne se mélangent pas dans les conditions partagées. Pour ce dernier cas, voyez notre article sur l'accès conditionnel pour agents IA et la gouvernance des identités non humaines.
Créer le plan Accès privilégié pas à pas
Cet exemple construit un plan de durcissement pour les comptes à privilèges, avec trois règles. Les noms de règles suivent une convention de type CO101, CO102, CO103 : elle sert de repère lorsque vous lirez les journaux.
Ouvrir l'assistant de création
Dans le centre d'administration Microsoft Entra, allez dans Entra ID > Accès conditionnel > Policy plans (Preview) et créez un plan. Nommez-le d'après son objectif de sécurité (ici Accès privilégié). Ajoutez des propriétaires et des étiquettes (identité, administrateurs) : ce sont des repères d'organisation et de recherche, qui ne modifient pas vos contrôles RBAC existants sur la modification ou la suppression du plan.
Définir le socle partagé
Dans les identités partagées, ciblez les rôles d'annuaire concernés (la démonstration d'origine part du rôle Administrateur général, mais un socle réel couvre l'ensemble de vos rôles privilégiés) et excluez le groupe de comptes d'accès d'urgence. Ce socle s'appliquera à chaque règle du plan.
Créer la première règle
L'assistant n'accepte qu'une seule règle à la création. Créez CO101 (administrateurs, MFA résistante au phishing), laissez l'état initial en rapport seulement, puis dans les contrôles d'octroi choisissez d'exiger une force d'authentification. Les forces d'authentification intégrées et vos forces personnalisées sont proposées.
Ajouter les règles suivantes
Depuis la page du plan, ajoutez CO102 (administrateurs, appareil marqué conforme) puis CO103 (administrateurs, fréquence de connexion de 4 heures). Conservez l'état rapport seulement et ciblez toutes les ressources au niveau de chaque règle.
Exploiter le menu de chaque règle
Le menu d'une règle permet de consulter son impact sur les connexions (réussites, échecs, rapport seulement), de la dupliquer, de la déplacer vers un autre plan, de la modifier ou de la supprimer. L'action « modifier toutes les règles » affiche un avertissement : elle permet de changer l'état de toutes les règles d'un coup.
Aucun garde-fou contre le verrouillage observé en préversion
En préversion, une règle ciblant tous les utilisateurs et toutes les ressources avec une exigence de MFA, sans aucune exclusion, a pu être enregistrée puis activée sans le moindre avertissement, contrairement aux stratégies classiques. Excluez systématiquement votre groupe de comptes d'urgence au niveau du plan et passez toujours par le rapport seulement avant d'activer une règle.
Mise en œuvre : inventorier vos stratégies et lire le rapport
Avant de regrouper quoi que ce soit, il faut savoir ce que vous avez. Les scripts ci-dessous sont en lecture seule : ils inventorient vos stratégies et résument les résultats des connexions. Ils ne créent aucun plan, car les compléments de recherche signalent que Microsoft Graph, PowerShell, la sauvegarde et la restauration sont à vérifier avant une adoption à grande échelle des plans (analyse de Tony Redmond sur Office365itpros).
Inventaire et candidats aux conditions partagées
Prérequis : PowerShell 7 ou supérieur, module Microsoft.Graph.Identity.SignIns (Install-Module Microsoft.Graph.Identity.SignIns -Scope CurrentUser), permission déléguée Policy.Read.All et un compte autorisé à lire les stratégies d'accès conditionnel. Le script produit un fichier inventaire-ca.csv, le nombre de stratégies, la liste des stratégies actives sans exclusion qui ciblent tous les utilisateurs et les groupes de stratégies au ciblage identique.
1# Connexion avec le scope minimal en lecture2Connect-MgGraph -Scopes 'Policy.Read.All' -NoWelcome3 4# Récupération de toutes les stratégies d'accès conditionnel, tous états confondus5$policies = Get-MgIdentityConditionalAccessPolicy -All6 7$inventaire = foreach ($p in $policies) {8 $u = $p.Conditions.Users9 # Signature de ciblage : sert à repérer les stratégies qui répètent le même socle10 $signature = '{0}|{1}|{2}|{3}' -f (@($u.IncludeRoles | Sort-Object) -join ','), (@($u.IncludeGroups | Sort-Object) -join ','), (@($u.ExcludeUsers | Sort-Object) -join ','), (@($u.ExcludeGroups | Sort-Object) -join ',')11 12 [pscustomobject]@{13 Nom = $p.DisplayName14 Etat = $p.State15 CibleTousUtilisateurs = (@($u.IncludeUsers) -contains 'All')16 ExclusionsUtilisateurs = @($u.ExcludeUsers).Count17 ExclusionsGroupes = @($u.ExcludeGroups).Count18 Ressources = (@($p.Conditions.Applications.IncludeApplications) -join ';')19 Octroi = (@($p.GrantControls.BuiltInControls) -join ';')20 ForceAuthentification = $p.GrantControls.AuthenticationStrength.DisplayName21 FrequenceConnexion = if ($p.SessionControls.SignInFrequency.IsEnabled) { '{0} {1}' -f $p.SessionControls.SignInFrequency.Value, $p.SessionControls.SignInFrequency.Type } else { '' }22 Signature = $signature23 }24}25 26# Export complet pour analyse hors ligne27$inventaire | Export-Csv -Path .\inventaire-ca.csv -NoTypeInformation -Encoding UTF828 29# Rappel de la limite documentée de 240 stratégies par tenant30Write-Host ('{0} stratégie(s) sur 240 maximum par tenant' -f $inventaire.Count)31 32# Risque de verrouillage : stratégies actives, tous utilisateurs, aucune exclusion33$inventaire | Where-Object { $_.Etat -eq 'enabled' -and $_.CibleTousUtilisateurs -and $_.ExclusionsUtilisateurs -eq 0 -and $_.ExclusionsGroupes -eq 0 } | Format-Table Nom, Octroi -AutoSize34 35# Candidats à un plan : stratégies partageant le même ciblage non trivial36$inventaire | Group-Object Signature | Where-Object { $_.Count -gt 1 -and $_.Name -ne '|||' } | ForEach-Object { '{0} stratégies au ciblage identique : {1}' -f $_.Count, (($_.Group.Nom) -join ' ; ') }Les groupes de stratégies au ciblage identique sont vos premiers candidats à un plan. Le script n'indique pas comment les règles d'un plan sont décomptées de la limite de 240 : la documentation de planification de l'accès conditionnel recommande de consolider plutôt que d'ajouter, sans préciser ce point.
Lire le résultat des règles en mode rapport seulement
Prérequis : module Microsoft.Graph.Reports (Install-Module Microsoft.Graph.Reports -Scope CurrentUser), permission déléguée AuditLog.Read.All et un rôle autorisant la lecture des journaux de connexion. Le script regroupe, sur les sept derniers jours, le nombre de connexions par stratégie ou règle et par résultat.
1Connect-MgGraph -Scopes 'AuditLog.Read.All' -NoWelcome2 3# Fenêtre d'analyse : les 7 derniers jours, en UTC4$depuis = (Get-Date).AddDays(-7).ToUniversalTime().ToString('yyyy-MM-ddTHH:mm:ssZ')5 6# Échantillon de 500 connexions maximum7$connexions = Get-MgAuditLogSignIn -Filter ('createdDateTime ge {0}' -f $depuis) -Top 5008 9# Une ligne par stratégie ou règle évaluée pour chaque connexion10$resultats = foreach ($c in $connexions) {11 foreach ($a in $c.AppliedConditionalAccessPolicies) {12 [pscustomobject]@{ Regle = $a.DisplayName; Resultat = $a.Result }13 }14}15 16# Synthèse : les résultats préfixés reportOnly correspondent au mode rapport seulement17$resultats | Group-Object Regle, Resultat | Sort-Object Name | Select-Object Count, Name | Format-Table -AutoSizeCherchez les lignes reportOnlyFailure : elles désignent des connexions que la règle aurait bloquées si elle était activée. C'est votre liste de remédiation, à traiter avant tout passage en production. Comme chaque règle apparaît séparément dans les journaux, une convention de nommage rigoureuse rend cette synthèse lisible.
Migrer vos stratégies existantes sans rien casser
Inutile de tout recréer : un outil de migration intégré analyse les stratégies que vous sélectionnez. Chaque stratégie devient une règle et les paramètres communs deviennent des conditions partagées. La procédure Microsoft Learn de migration recommande d'avancer par groupes de stratégies cohérents.
Lancer la migration depuis la page Stratégies
Cliquez sur la bannière « Migrate to Conditional Access Policy plans » puis sur Commencer. Sélectionnez un groupe thématique, par exemple les stratégies d'appareils et d'applications : blocage du BYOD (appareils personnels) sur navigateur, restrictions d'application, protection des applications mobiles.
Nommer le plan et relire la proposition
Donnez un nom au plan (par exemple Appareils et applications). L'outil cherche des conditions réellement communes, comme « tous les administrateurs » ou « tous les comptes d'urgence » ; s'il n'en trouve pas, aucune condition partagée n'est créée. Vous pouvez ensuite modifier le plan pour ajouter vous-même des identités partagées.
Constater l'état Désactivé
Les règles générées démarrent à l'état Désactivé et les stratégies d'origine ne sont pas modifiées : elles restent actives dans la liste. Aucune bascule n'a lieu sans votre décision.
Passer les règles en rapport seulement et comparer
Mettez les règles en rapport seulement, laissez tourner quelques jours puis comparez les journaux de connexion avec le script précédent. Dans le détail d'une connexion, un clic sur la stratégie indique le plan d'origine et la règle concernée.
Activer les règles, puis désactiver les stratégies d'origine
Une fois les résultats cohérents, activez les règles du plan et seulement ensuite désactivez les stratégies d'origine. Pendant la coexistence, les deux jeux s'appliquent et tous doivent être satisfaits : conservez cette fenêtre courte.
Pour structurer votre campagne de validation, appuyez-vous sur notre framework de test des politiques d'accès conditionnel, qui détaille comment éviter les blocages en production.
Pièges de la préversion et dépannage
Les trois derniers points du tableau viennent de la documentation Microsoft Learn ; les deux premiers sont des observations faites en préversion, susceptibles d'être corrigées.
| Symptôme | Cause probable | Résolution |
|---|---|---|
| Perte d'accès après activation d'une règle de MFA | Règle ciblant tous les utilisateurs sans exclusion, sans avertissement en préversion | Exclure le groupe de comptes d'urgence au niveau du plan, tester en rapport seulement, vérifier un compte d'urgence avant activation |
| Impossible de cibler des types d'applications clientes précis, par exemple pour bloquer l'authentification héritée | Comportement observé en préversion : le type d'application « toutes » est ajouté automatiquement | Conserver la stratégie classique correspondante tant que le comportement n'est pas corrigé |
| « Tous les utilisateurs » introuvable au niveau du plan | Option disponible uniquement dans les règles | Définir ce ciblage dans chaque règle concernée |
| Exclusion du plan impossible à retirer dans une règle | Les exclusions s'accumulent, une règle ne peut pas retirer celles du plan | Revoir le découpage : placer l'exclusion dans les règles qui en ont besoin, pas dans le socle |
| Effet inattendu sur plusieurs règles après une modification | Changement du socle partagé du plan, appliqué à toutes les règles | Valider en rapport seulement et relire l'impact de chaque règle avant d'enregistrer |
Condition d'emplacement : jetons d'une heure en préversion
Selon Microsoft Learn, pour les utilisateurs ciblés par un plan qui utilise l'emplacement comme condition, Microsoft émet des jetons d'accès d'une heure, sans contrôle instantané de l'adresse IP (instant IP enforcement). Pour le géoblocage ou les restrictions d'IP, gardez vos stratégies classiques tant que la préversion n'a pas évolué et testez avant de réorganiser la production.
Questions fréquentes
Les plans d'accès conditionnel sont-ils utilisables en production ?
Ils sont en préversion publique d'après la documentation Microsoft Learn consultée le 8 novembre 2026. Rien n'oblige à les adopter : vos stratégies classiques continuent de fonctionner. Commencez par un périmètre restreint en mode rapport seulement.
Quelle licence et quel rôle faut-il pour créer un plan ?
Une licence Microsoft Entra ID P1 ou P2 est requise, et le rôle minimal est Administrateur de l'accès conditionnel. Le menu se trouve sous Entra ID > Accès conditionnel > Policy plans (Preview).
Faut-il migrer toutes mes stratégies d'un coup ?
Non. La migration peut se faire par groupes de stratégies, les règles générées démarrent désactivées et les stratégies d'origine ne sont pas modifiées. Procédez thème par thème : rapport seulement, comparaison des journaux, activation des règles, puis désactivation des stratégies d'origine.
Les règles d'un plan comptent-elles dans la limite de 240 stratégies ?
La documentation consultée mentionne une limite de 240 stratégies d'accès conditionnel par tenant, tous états confondus, mais ne précise pas comment les règles des plans y sont comptées. Dans le doute, consolidez avant d'ajouter.
Peut-on automatiser les plans avec Microsoft Graph ou PowerShell ?
L'analyse de Tony Redmond signale que Graph, PowerShell, la sauvegarde et la restauration sont à vérifier avant une adoption à grande échelle. Vérifiez la documentation Microsoft Learn avant d'automatiser, et en attendant utilisez l'inventaire en lecture seule présenté plus haut.
Par où commencer
Plan d'action pour votre premier plan de durcissement
- Vérifier la licence Microsoft Entra ID P1 ou P2 et le rôle Administrateur de l'accès conditionnel
- Exécuter l'inventaire pour repérer les stratégies sans exclusion et les ciblages répétés
- Contrôler que le groupe de comptes d'urgence est exclu et testé
- Créer un premier plan sur un thème précis (accès privilégié ou appareils et applications)
- Garder toutes les règles en rapport seulement et relire les résultats
reportOnlyFailure - Activer les règles, puis seulement après désactiver les stratégies d'origine
- Conserver les stratégies classiques pour les conditions d'emplacement tant que la limitation des jetons d'une heure s'applique
Si vous gérez plusieurs tenants avec des modèles automatisés, attendez des API et un outillage vérifiés avant d'adopter les plans à grande échelle, et limitez-vous pour l'instant à des tests. Si vous administrez un seul tenant, commencez par le plan d'accès privilégié : c'est le cas où la duplication des exclusions est la plus nette. Pour les stratégies de MFA existantes, relisez notre guide pour imposer le MFA dans Microsoft Entra ID.
Pour aller plus loin
- Qu'est-ce qu'un plan de stratégie d'accès conditionnel ? (préversion) : fonctionnement, héritage des conditions, évaluation à l'exécution et limites de la préversion.
- Migrer des stratégies d'accès conditionnel vers un plan (préversion) : la procédure officielle, du mode rapport seulement à la désactivation des stratégies d'origine.
- Scale access controls with Microsoft Entra Conditional Access policy plans : l'annonce officielle de la préversion publique, avec la licence requise.
- Microsoft Launches Preview of Entra ID Conditional Access Policy Plans : une analyse indépendante des restrictions de la préversion et des enjeux d'outillage.
