Les Conditional Access policy plans réorganisent la gestion de l’accès conditionnel dans Microsoft Entra ID sans modifier son moteur d’évaluation. Au 1er novembre 2026, cette fonction reste en préversion : elle doit être testée comme une nouvelle couche de gouvernance, pas traitée comme une simple refonte de l’interface.
Ce que les policy plans changent dans Microsoft Entra ID
Dans Microsoft Entra ID, anciennement Azure Active Directory, les équipes organisent souvent leurs stratégies par préfixes, personas ou applications. Cette méthode devient difficile à maintenir lorsque plusieurs stratégies répètent les mêmes utilisateurs, exclusions et ressources.
Les plans regroupent ces éléments autour d’un objectif commun. Il peut s’agir d’un profil, comme les administrateurs ou les collaborateurs du siège, ou d’un objectif de sécurité, comme l’exigence d’un appareil conforme.
La documentation Microsoft Learn sur les Conditional Access policy plans précise que le menu s’appelle Policy plans (Preview). Il se trouve sous Entra ID > Conditional Access.
| Aspect | Stratégie autonome | Règle dans un plan | Conséquence opérationnelle |
|---|---|---|---|
| Organisation | Une stratégie indépendante | Une règle rattachée à un objectif commun | Le plan réduit la duplication du ciblage |
| Conditions partagées | Non | Oui | Une modification peut couvrir plusieurs règles |
| Évaluation | Indépendante | Indépendante | Toutes les stratégies et règles applicables doivent être satisfaites |
| Journaux | Une entrée par stratégie | Une entrée distincte par règle | Le diagnostic reste possible règle par règle |
| Disponibilité | Modèle existant | Préversion | Un pilote est requis avant une généralisation |
Les plans complètent donc les stratégies autonomes. Ils ne les remplacent pas et ne créent aucun ordre de priorité entre les contrôles.
L’héritage impose de concevoir le ciblage avant les règles
Un plan comporte trois parties : ses détails, ses conditions partagées et ses règles. Les détails comprennent le nom, la description, les tags et les propriétaires. Au moins une règle doit être ajoutée.
Les conditions partagées définissent le périmètre commun. Une règle hérite de ce périmètre et ajoute ses propres conditions, contrôles d’octroi ou contrôles de session.
Cet héritage suit plusieurs contraintes :
- une règle ne peut pas réduire le ciblage défini par le plan ;
- elle ne peut pas retirer une exclusion héritée ;
- elle peut ajouter ses propres exclusions ;
All usersn’est pas disponible dans les conditions partagées, mais reste utilisable dans les règles ;- les conditions partagées ne peuvent pas mélanger plusieurs types d’identité, comme des utilisateurs et des agents.
Lorsque plusieurs types d’identité doivent être couverts, le choix de l’identité doit rester au niveau des règles. Cette architecture évite de créer un plan dont le périmètre commun serait incompatible avec certains contrôles.
À l’exécution, chaque règle du plan et chaque stratégie autonome sont évaluées séparément. Il n’existe pas de priorité entre elles. L’accès n’est accordé que si tous les contrôles applicables sont satisfaits.
Les prérequis et licences à vérifier avant le pilote
Le rôle minimal documenté pour créer un plan est Conditional Access Administrator. Le principe du moindre privilège conduit à utiliser ce rôle plutôt qu’un rôle d’administration plus large.
Préparer le tenant avant de créer un plan
- Inventorier les stratégies existantes, leurs propriétaires et leurs dépendances
- Identifier les comptes d’accès d’urgence et les comptes de service
- Préparer un groupe limité pour la phase pilote
- Vérifier les exclusions au niveau du plan et de chaque règle
- Définir les journaux de connexion à contrôler avant l’activation
- Confirmer la prise en charge de la sauvegarde, de la restauration et de l’automatisation utilisées par l’organisation
- Vérifier les licences spécifiques si le plan cible des agents IA
Pour les agents, la documentation citée par Daily Entra News indique que Conditional Access nécessite une licence Microsoft Agent 365. Deux voies de licence sont mentionnées.
| Option | Composition indiquée | Usage concerné |
|---|---|---|
| Microsoft 365 E7 | Microsoft 365 E7 | Conditional Access pour les agents |
| Agent 365 avec Entra | Agent 365 associé à au moins Entra P1 | Conditional Access pour les agents |
| Agent 365 avec Microsoft 365 | Agent 365 associé à au moins Microsoft 365 E3 | Conditional Access pour les agents |
Une indication antérieure de mai 2026 mentionnait uniquement Entra P1 ou Microsoft 365 E3. Elle n’est plus à jour pour ce scénario agent. La licence doit être validée avant de construire un plan destiné aux identités agentiques.
Créer un plan pilote sans perturber la production
Le portail permet de partir de zéro ou d’utiliser un modèle. Les règles créées depuis un modèle sont initialement placées à l’état Off, selon la procédure Microsoft Learn de création d’un plan.
Une configuration type peut cibler les collaborateurs du siège. Le plan porte le groupe concerné et les exclusions communes. Deux règles imposent ensuite des contrôles différents sans répéter ce ciblage.
Définir l’objectif et la responsabilité
Créez le plan sous Entra ID > Conditional Access > Policy plans (Preview). Renseignez un nom explicite, une description, des tags et au moins un propriétaire.
Configurer le périmètre partagé
Ajoutez le groupe des collaborateurs du siège. Excluez les comptes d’accès d’urgence et les comptes de service dans les conditions partagées, conformément à la recommandation de Microsoft.
Exiger une authentification résistante au phishing
Ajoutez une première règle utilisant la force d’authentification appropriée. Passez-la de Off à Report-only pour observer son effet sans bloquer les connexions.
Exiger un appareil conforme
Ajoutez une seconde règle qui impose un appareil marqué comme conforme. Elle réutilise le ciblage et les exclusions du plan.
Contrôler les journaux de connexion
Vérifiez séparément le résultat de chaque règle. Les journaux doivent confirmer le ciblage attendu, les exclusions et les contrôles qui auraient été appliqués.
Cette validation doit couvrir les connexions ordinaires, les comptes exclus et les cas de récupération. Le framework IAMinerva de test des politiques d’accès conditionnel fournit une méthode pour éviter les blocages pendant cette phase.
Migrer les stratégies existantes sans rupture de contrôle
L’outil de migration permet de filtrer les stratégies existantes, par exemple avec un préfixe de nom, puis de les fusionner dans un plan. L’aperçu indique les ressources transformées en conditions partagées et la correspondance entre chaque stratégie et sa future règle.
Sélectionner un ensemble cohérent
Commencez par des stratégies qui partagent réellement un persona, une ressource ou un objectif. Une convention de nommage commune ne garantit pas que leurs exclusions soient compatibles.
Examiner l’aperçu de la fusion
Contrôlez les identités, les ressources, les emplacements, les contrôles d’octroi et les contrôles de session. Vérifiez surtout ce qui remonte au niveau des conditions partagées.
Tester les règles générées
Conservez les nouvelles règles en Report-only pendant la validation. Comparez leur résultat avec celui des stratégies autonomes toujours actives.
Effectuer la bascule
Activez le plan uniquement après avoir validé son équivalence fonctionnelle. Désactivez ensuite les stratégies d’origine pour éviter le maintien involontaire de contrôles en double.
Conserver une possibilité de retour
Privilégiez d’abord la désactivation des stratégies historiques plutôt que leur suppression. Leur suppression ne devrait intervenir qu’après la période de stabilisation définie par l’organisation.
Les stratégies existantes restent appliquées jusqu’à la bascule. Cette continuité réduit le risque de créer une fenêtre sans contrôle, mais elle impose de surveiller la période pendant laquelle anciennes stratégies et nouvelles règles coexistent.
Les limites de la préversion changent la stratégie de déploiement
La condition Location comporte une restriction spécifique. Pour les utilisateurs visés par un plan qui l’emploie, Microsoft émet des jetons d’accès d’une heure, sans contrôle IP instantané.
La condition Location exige un test dédié
Tony Redmond recommande, dans son analyse des Conditional Access policy plans, de vérifier la prise en charge de Microsoft Graph, de PowerShell, de la sauvegarde et de la restauration avant une gestion à grande échelle. Il souligne également que l’inventaire des stratégies existantes peut représenter une part significative du projet.
Aucun script de migration n’est donc proposé ici. Tant que l’organisation n’a pas validé les interfaces d’automatisation de la préversion dans son tenant, le portail reste l’approche la plus contrôlable pour un pilote.
Points forts
- Ciblage partagé entre plusieurs règles
- Propriétaires et tags définis au niveau du plan
- Aperçu avant la fusion des stratégies
- Diagnostic distinct pour chaque règle
Limites
- Fonctionnalité encore en préversion
- Restriction spécifique avec la condition Location
- Compatibilité des outils de sauvegarde à vérifier
- Inventaire préalable potentiellement long
Questions fréquentes
Les policy plans remplacent-ils les stratégies d’accès conditionnel existantes ?
Non. Les plans s’ajoutent au modèle existant. Les stratégies autonomes et les règles des plans sont évaluées indépendamment, sans ordre de priorité.
Peut-on utiliser All users dans les conditions partagées ?
Non. All users est disponible dans les règles, mais pas dans les conditions partagées du plan. Le ciblage doit être conçu en conséquence.
Une règle peut-elle réduire le périmètre défini par le plan ?
Non. Une règle ne peut ni restreindre le ciblage du plan ni retirer ses exclusions. Elle peut en revanche ajouter ses propres exclusions.
Les plans sont-ils prêts pour une migration complète en production ?
Au 1er novembre 2026, ils sont en préversion. Un pilote limité, une validation en Report-only et une procédure de retour sont nécessaires avant toute réorganisation étendue.
Trois décisions à prendre avant le déploiement
Le premier choix porte sur le périmètre. Une organisation disposant de nombreuses stratégies dupliquées peut commencer par un persona simple et bien documenté. Une organisation dépendante des conditions réseau doit d’abord évaluer la limite liée à Location.
Plan d’action recommandé
- Choisir un seul ensemble cohérent de stratégies pour le pilote
- Nommer un propriétaire fonctionnel et un propriétaire technique
- Placer les comptes d’accès d’urgence et de service dans les exclusions partagées
- Créer les règles à l’état
Report-only - Comparer chaque règle aux stratégies existantes dans les journaux
- Tester les changements d’emplacement réseau et les scénarios de récupération
- Désactiver les stratégies historiques avant d’envisager leur suppression
- Documenter la méthode de retour et les dépendances d’automatisation
Si le tenant utilise déjà une automatisation Microsoft Graph ou PowerShell pour sauvegarder Conditional Access, sa compatibilité avec les plans doit devenir un critère de décision. Sans cette validation, le déploiement doit rester limité au pilote.
Pour aller plus loin
- Qu’est-ce que les Conditional Access policy plans ? — le fonctionnement, l’héritage et les limites de la préversion.
- Créer un Conditional Access policy plan — la procédure Microsoft et les exclusions recommandées.
- Microsoft-managed Conditional Access policies — les stratégies gérées par Microsoft à articuler avec les plans.
- Framework de test pour les politiques d’accès conditionnel — une méthode de validation avant l’activation en production.
- Nouveautés Teams, Entra ID, Copilot et SharePoint — une vue plus large des évolutions administratives Microsoft 365.
