Un utilisateur lance Azure CLI ou Visual Studio Code et se voit soudain réclamer le MFA (authentification multifacteur), alors que vos stratégies n’ont pas bougé. C’est l’effet de la nouvelle application des périmètres de base dans l’accès conditionnel de Microsoft Entra ID (anciennement Azure AD). Ce guide vous permet de savoir si votre tenant est exposé, de choisir entre application complète, comportement personnalisé ou désactivation, puis de vérifier le résultat dans les journaux de connexion.
Ce qui change pour les stratégies « Toutes les ressources » avec exclusions
Jusqu’à ce changement, une stratégie ciblant toutes les ressources mais comportant au moins une exclusion de ressource laissait de côté, de fait, les connexions qui ne demandaient que des périmètres de base (baseline scopes). Ces connexions obtenaient leur jeton sans MFA, sans contrôle de conformité d’appareil et sans blocage. Microsoft Entra ID les évalue désormais comme un accès à l’annuaire : l’audience d’accès conditionnel devient la ressource « Windows Azure Active Directory », aussi appelée Azure AD Graph.
Côté sécurité, l’ancien comportement créait une zone sans contrôle : une application pouvait authentifier un utilisateur et lire des informations d’annuaire de base sans satisfaire les exigences de la stratégie. Le nouveau modèle ferme cette zone.
Selon l’annonce officielle de l’équipe Entra, le déploiement a commencé le 15 juin 2026, avec un calendrier décalé par rapport au billet initial. Les dates divergent selon les pages : certaines citent encore « mars 2026 » ou « mars–juin 2026 ». Un article de la communauté Tech Community situait la fin du déploiement vers la mi-août et juge l’impact faible pour la plupart des tenants, sauf pour les applications incapables de gérer un défi d’accès conditionnel. Au 10 octobre 2026, partez donc du principe que le comportement peut déjà s’appliquer à votre tenant, sauf configuration contraire.
Les périmètres de base regroupent deux familles d’étendues :
- Étendues OpenID Connect (OIDC) :
email,offline_access,openid,profile - Étendues du répertoire de base :
User.Read,User.Read.All,User.ReadBasic.All,People.Read,People.Read.All,GroupMember.Read.All,Member.Read.Hidden
Seules les connexions limitées à ces étendues sont touchées
Une application qui demande une étendue supplémentaire, par exemple Mail.Read, était déjà soumise à l’accès conditionnel : rien ne change. Pour un client public, une étendue de base plus une autre étendue suffit. Un client confidentiel exclu qui ne demande que des étendues OIDC n’est pas touché non plus. Pour le contexte général, voir notre article sur les scopes Baseline dans Entra ID et l’accès conditionnel.
Votre tenant est-il concerné ? Trois conditions à vérifier
Oui, si les trois conditions suivantes sont réunies. Si l’une manque, le changement ne vous affecte pas.
- Au moins une stratégie d’accès conditionnel cible toutes les ressources.
- Cette stratégie comporte au moins une exclusion de ressource.
- Des utilisateurs se connectent via des applications qui ne demandent que des étendues de base.
Les deux premières conditions se vérifient en lecture seule. Le filtre ci-dessous liste les stratégies qui incluent All et déclarent au moins une exclusion. Permission déléguée minimale : Policy.Read.All, avec un compte disposant d’un rôle autorisé à lire les stratégies d’accès conditionnel.
1https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies?$filter=conditions/applications/includeApplications/any(a:a eq 'All') and conditions/applications/excludeApplications/any()&$select=id,displayNameUne sortie vide signifie que vous êtes hors périmètre. Sinon, notez les exclusions : ce sont elles qui déterminent quelles applications seront évaluées différemment.
Ce que les utilisateurs verront
Prenons une stratégie type : tous les utilisateurs, toutes les ressources, exclusions pour une application cliente confidentielle et pour Exchange Online, MFA comme contrôle d’octroi. Voici le comportement avant et après le changement.
| Scénario | Avant | Après |
|---|---|---|
| Connexion à Visual Studio Code (client public, étendues openid et profile) | Pas de MFA | MFA exigé, audience Windows Azure Active Directory |
| Connexion via Azure CLI (étendue User.Read uniquement) | Pas de MFA | MFA exigé, audience Windows Azure Active Directory |
| Application confidentielle exclue, étendues User.Read et People.Read | Pas de MFA | MFA exigé, audience Windows Azure Active Directory |
| Application confidentielle exclue, offline_access et Files.Read (SharePoint) | Évalué selon SharePoint | Inchangé |
| Client de synchronisation OneDrive, offline_access et Mail.Read (Exchange Online) | Non appliqué, Exchange Online est exclu | Inchangé |
Les actions dépendent du type d’application. Pour un client public ou un client confidentiel dont vous êtes propriétaire, vérifiez d’abord si ces connexions doivent vraiment échapper à l’accès conditionnel. Pour un client confidentiel, demandez aux développeurs de passer des étendues d’annuaire comme User.Read à des étendues OIDC (openid, profile) pour les informations utilisateur de base. Pour une application d’éditeur tiers (ISV), posez la même question à l’éditeur.
Vos propres applications doivent aussi savoir traiter un défi d’accès conditionnel (MFA, conformité d’appareil). Sinon, une mise à jour s’impose : suivez le guide du développeur d’accès conditionnel. Pour rappel sur le MFA lui-même, voir notre guide Conditional Access : imposer le MFA dans Microsoft Entra ID.
Trois modes d’application, un seul recommandé
Vous pilotez la prise d’effet depuis les paramètres d’étendues de référence. Ce lien direct est requis : la page n’est pas atteignable autrement.
| Mode | Portée | Quand l’utiliser | Risque |
|---|---|---|---|
| Activer l’application forcée (recommandé) | Toutes les stratégies Toutes les ressources avec exclusions | Après revue des exclusions, idéalement validé sur un tenant de test | Nouvelles invites pour les clients n’utilisant que des étendues de base |
| Personnaliser le comportement | Uniquement les stratégies où vous conservez l’ancien comportement | Scénarios métier critiques : appareil non géré, application sans SDK Intune, application à exclure d’un blocage | Une application fictive à maintenir, et une exemption à justifier |
| Désactiver l’application | Toutes les stratégies du tenant | Non recommandé | Lacunes dans la couverture d’accès conditionnel |
Si vous ne faites rien, l’application s’active automatiquement au fil du déploiement, et aucune option n’apparaît sélectionnée dans la page de paramètres, car ce comportement devient celui par défaut. Si vous avez choisi Désactiver l’application ou Personnaliser le comportement, le déploiement ne remplace pas votre configuration. Vous pouvez basculer à tout moment vers l’application complète.
Activer l’application ou conserver l’ancien comportement
Activer l’application forcée
Rôle minimum : Administrateur d’accès conditionnel. Le paramètre est décrit comme immédiat ; aucun délai de propagation n’est documenté, prévoyez donc de tester dès l’enregistrement.
Ouvrir le centre d’administration
Connectez-vous au centre d’administration Microsoft Entra avec au moins le rôle Administrateur d’accès conditionnel.
Accéder aux paramètres des étendues de référence
Ouvrez les paramètres des étendues de référence dans l’accès conditionnel.
Activer puis enregistrer
Sélectionnez Activer l’application forcée, cliquez sur Enregistrer, puis confirmez avec Réactiver l’application.
Impact immédiat sur tout le tenant
L’activation s’applique d’un coup à toutes les stratégies Toutes les ressources qui comportent des exclusions. Des connexions auparavant non évaluées le seront, avec Windows Azure Active Directory comme ressource cible. Validez d’abord sur un tenant de test, puis prévenez le support. Pour revenir en arrière, utilisez Désactiver l’application forcée dans la même page.
Conserver l’ancien comportement pour une stratégie
L’option Personnaliser le comportement repose sur une application fictive qui sert de ressource cible aux périmètres de base. Les connexions concernées sont alors évaluées contre cette application ; comme elle est exclue de la stratégie, l’ancien comportement est conservé pour cette stratégie seule.
Inscrire l’application fictive
Inscrivez une nouvelle application à locataire unique dans Microsoft Entra ID. Aucune configuration supplémentaire n’est nécessaire.
L’exclure de la stratégie ciblée
Dans la stratégie d’accès conditionnel dont vous voulez conserver l’ancien comportement, ajoutez l’application fictive aux ressources exclues.
La sélectionner dans les paramètres
Dans les paramètres des étendues de référence, choisissez Personnaliser le comportement, cliquez sur Enregistrer, puis sélectionnez votre application fictive dans la liste.
Réservez cette option aux cas documentés : stratégie exigeant un appareil conforme alors que des applications précises doivent être accessibles depuis des appareils non managés ; stratégie exigeant une stratégie de protection des applications alors que des clients ne sont pas intégrés au SDK Microsoft Intune ; stratégie de blocage dont certaines applications doivent être exclues. Microsoft recommande de s’aligner sur le nouveau modèle.
Mise en œuvre : auditer les applications qui n’utilisent que des étendues de base
Une fois Personnaliser le comportement configuré, les connexions qui ne demandent que des étendues de base listent votre application fictive comme audience d’accès conditionnel dans les journaux de connexion. Cela donne un inventaire des applications concernées, sur une période de plusieurs jours.
La requête de référence est la suivante (endpoint beta, à adapter à votre plage de dates et à l’identifiant de votre application fictive) :
1https://graph.microsoft.com/beta/auditLogs/signIns?$filter=createdDateTime ge 2026-06-15T00:00:00Z and createdDateTime lt 2026-07-15T00:00:00Z and conditionalAccessAudiences/any(a:a eq '<your-custom-app-id>')&$select=createdDateTime,appId,appDisplayName,userDisplayName,userPrincipalName,ipAddress,conditionalAccessStatusLe script ci-dessous exécute cette requête, suit la pagination, regroupe les connexions par application et exporte le résultat en CSV. Il est en lecture seule : aucun mode simulation n’est nécessaire.
- Module :
Microsoft.Graph.Authentication(Install-Module Microsoft.Graph.Authentication -Scope CurrentUser) - Permission déléguée minimale :
AuditLog.Read.All, avec un compte autorisé à lire les journaux de connexion - Sortie : un tableau à l’écran et un fichier CSV (une ligne par application)
1#Requires -Modules Microsoft.Graph.Authentication2param(3 # ID d’application (appId) de l’application fictive créée plus haut4 [Parameter(Mandatory)][string]$CustomAppId,5 # Plage de dates analysée6 [datetime]$From = [datetime]'2026-06-15',7 [datetime]$To = [datetime]'2026-07-15',8 [string]$OutputPath = 'baseline-scopes-apps.csv'9)10 11# Connexion avec la permission de lecture des journaux de connexion12Connect-MgGraph -Scopes 'AuditLog.Read.All' -NoWelcome13 14# Construction du filtre OData : connexions dont l’audience d’accès conditionnel est l’application fictive15$fromUtc = $From.ToUniversalTime().ToString('yyyy-MM-ddTHH:mm:ssZ')16$toUtc = $To.ToUniversalTime().ToString('yyyy-MM-ddTHH:mm:ssZ')17$filter = "createdDateTime ge $fromUtc and createdDateTime lt $toUtc and conditionalAccessAudiences/any(a:a eq '$CustomAppId')"18$select = 'createdDateTime,appId,appDisplayName,userDisplayName,userPrincipalName,ipAddress,conditionalAccessStatus'19$uri = 'https://graph.microsoft.com/beta/auditLogs/signIns?$filter=' + [uri]::EscapeDataString($filter) + '&$select=' + $select20 21# Lecture de toutes les pages de résultats22$events = [System.Collections.Generic.List[object]]::new()23while ($uri) {24 $page = Invoke-MgGraphRequest -Method GET -Uri $uri25 foreach ($item in $page.value) { $events.Add([pscustomobject]$item) }26 $uri = $page.'@odata.nextLink'27}28 29if ($events.Count -eq 0) {30 Write-Warning 'Aucune connexion trouvée : vérifiez l’ID de l’application, la plage de dates et le paramètre Personnaliser le comportement.'31 return32}33 34# Regroupement par application : volume, nombre d’utilisateurs distincts, dernière connexion35$summary = $events | Group-Object -Property appId | ForEach-Object {36 [pscustomobject]@{37 AppId = $_.Name38 Application = $_.Group[0].appDisplayName39 Connexions = $_.Count40 Utilisateurs = ($_.Group.userPrincipalName | Sort-Object -Unique).Count41 DerniereConnexion = ($_.Group.createdDateTime | Sort-Object | Select-Object -Last 1)42 }43} | Sort-Object -Property Connexions -Descending44 45$summary | Export-Csv -Path $OutputPath -NoTypeInformation -Encoding utf846$summary | Format-Table -AutoSize47Write-Host "Export écrit dans $OutputPath"Exécutez-le par exemple avec ./Get-BaselineScopeApps.ps1 -CustomAppId '<appId>'. Chaque ligne du CSV est une application à classer : mise à jour pour demander des étendues OIDC, exemption justifiée, ou application à laisser sous contrôle.
Dépannage et vérification après activation
| Symptôme | Cause probable | Résolution |
|---|---|---|
| Invite MFA soudaine dans Azure CLI ou Visual Studio Code | Client public limité à des étendues de base, désormais évalué avec Windows Azure Active Directory comme audience | Contrôler la stratégie Toutes les ressources concernée ; garder l’exigence si elle est légitime, sinon passer par Personnaliser le comportement |
| Une application web exclue échoue après la connexion | Application confidentielle qui ne sait pas traiter un défi d’accès conditionnel | Adapter l’application selon le guide du développeur, ou lui faire demander des étendues OIDC au lieu de User.Read |
| Comportement inchangé pour une application | Elle demande déjà une étendue au-delà des périmètres de base, par exemple Mail.Read | Aucune action : elle était déjà soumise à l’accès conditionnel |
| Aucune ligne dans l’audit des connexions | Application fictive non sélectionnée ou option non enregistrée, ou plage de dates inadaptée | Revérifier les paramètres des étendues de référence, l’appId et les dates, puis relancer le script |
| Aucune option cochée dans la page de paramètres | L’application par défaut est active : aucun élément n’est sélectionné | Rien à corriger ; passer par le lien direct si la page reste introuvable |
Pour creuser un cas précis, la page Microsoft sur la résolution des problèmes de connexion avec l’accès conditionnel décrit la lecture des journaux.
Contrôles après changement de mode
- Une connexion pilote via Azure CLI déclenche bien le contrôle attendu (MFA ou conformité)
- Une connexion via Visual Studio Code se comporte comme prévu
- Les applications métier exclues de vos stratégies fonctionnent toujours, y compris celles qui ne demandaient que
User.Read - Le champ
conditionalAccessStatusdes journaux de connexion reflète l’évaluation attendue - Les stratégies sous Personnaliser le comportement sont documentées avec leur justification
Questions fréquentes
Que se passe-t-il si je ne change aucun paramètre ?
L’application s’active automatiquement dans le cadre du déploiement commencé le 15 juin 2026. Aucune option n’apparaît alors sélectionnée dans la page de paramètres, car c’est le comportement par défaut. Si vous aviez choisi de désactiver l’application ou de personnaliser le comportement, votre choix est conservé.
Comment revenir à l’ancien comportement après activation ?
Ouvrez les paramètres des étendues de référence et sélectionnez Désactiver l’application forcée. Pour un retour limité à certaines stratégies seulement, préférez Personnaliser le comportement avec une application fictive exclue de ces stratégies.
Quelles applications sont réellement impactées ?
Seules celles qui demandent exclusivement des étendues de base. Une application qui demande aussi Mail.Read ou Files.Read était déjà soumise à l’accès conditionnel. Concentrez la revue sur les applications explicitement exclues de vos stratégies Toutes les ressources.
Que faire si l’éditeur d’une application ne peut pas la mettre à jour ?
Évaluez d’abord si la connexion doit vraiment échapper à l’accès conditionnel. Si une raison métier valable le justifie, utilisez Personnaliser le comportement pour conserver l’ancien comportement sur la stratégie concernée.
Trois décisions à prendre avant de toucher au paramètre
Plan d’action
- Exécuter l’inventaire des stratégies Toutes les ressources avec exclusions (requête Graph ou PowerShell ci-dessus)
- Lister les applications exclues qui ne demandent que des étendues de base et trancher : mise à jour, exemption ou maintien sous contrôle
- Choisir le mode (application complète, comportement personnalisé ou désactivation) et le consigner
Si votre inventaire est vide, vous n’avez rien à décider. Si votre tenant ne comporte que des exclusions pour des applications qui demandent déjà des étendues plus larges, activez l’application forcée après un test. Si vous avez des applications sans prise en charge des défis d’accès conditionnel ou des appareils non managés légitimes, commencez par Personnaliser le comportement sur les stratégies concernées, puis réduisez cette liste au fil des mises à jour.
Pour aller plus loin
- Annonce officielle de l’équipe Entra : contexte, calendrier révisé et actions à prévoir
- Article Tech Community sur le durcissement du traitement des périmètres de base : calendrier de fin de déploiement et impact attendu
- Guide du développeur d’accès conditionnel : rendre une application capable de traiter un défi MFA ou de conformité
- Résoudre les problèmes de connexion avec l’accès conditionnel : lecture des journaux de connexion
- Scopes Baseline dans Entra ID et Accès Conditionnel : notre article sur le même sujet