Depassement licence acces conditionnel Entra : ce que révèle vraiment la nouvelle bannière

Dès le début du mois d'août 2026, les administrateurs qui ouvraient la page Accès conditionnel dans le centre d'administration Microsoft Entra voyaient apparaître une nouvelle bannière. Cette alerte de depassement licence acces conditionnel Entra indique que certaines de vos stratégies protègent plus d'utilisateurs que ne le permettent vos droits de licence actuels — et elle a largement été mal interprétée comme le premier signe d'une facturation automatisée. Ce n'est pas le cas. Il s'agit d'un signal de visibilité. Plus important encore, le chiffre affiché est calculé d'une manière qui sous-estime presque certainement le nombre réel de licences Microsoft Entra ID P1 que requiert le périmètre de vos stratégies.

Qu'est-ce que l'alerte de depassement licence acces conditionnel entra

Microsoft a déployé cet avis sans annonce officielle, et les premiers comptes rendus publics sont apparus à quelques jours d'intervalle. ourcloudnetwork (11 août 2026) a signalé son apparition « ces dernières semaines » sur la page de synthèse de l'Accès conditionnel, et LazyAdmin (12 août 2026) l'a repérée sur la même page. Les deux sources retranscrivent la bannière complète ainsi : « Dépassement de licence. Certaines stratégies d'Accès conditionnel protègent plus d'utilisateurs que ne le permettent vos droits de licence actuels. » Le MVP Microsoft 365 Tony Redmond l'a documentée le 13 août 2026, citant un message indiquant aux tenants que « certaines stratégies d'Accès conditionnel protègent plus d'utilisateurs que ne le permettent vos droits de licence actuels ».

Le lien intégré au message ouvre la documentation Microsoft sur les informations d'utilisation des licences, où résident les chiffres sous-jacents.

Le socle de licence lui-même n'a pas changé. La présentation de l'Accès conditionnel de Microsoft indique clairement que « l'utilisation de cette fonctionnalité nécessite des licences Microsoft Entra ID P1 », ajoute que les clients Microsoft 365 Business Premium peuvent également utiliser les fonctionnalités d'Accès conditionnel, et précise que les stratégies basées sur le risque (risque de connexion et risque utilisateur) nécessitent Microsoft Entra ID Protection, une fonctionnalité P2.

Comment Microsoft comptabilise les utilisateurs de l'Accès conditionnel

Le chiffre à l'origine de la bannière provient de la page Utilisation des licences, accessible via Facturation > Licences dans le centre d'administration Entra. La documentation de Microsoft décrit un modèle délibérément simplifié : une « métrique phare » par niveau de licence, répartie sur deux onglets.

Chaque onglet comporte un rapport d'utilisation des fonctionnalités qui compare la consommation aux droits de licence à l'aide de trois indicateurs : Licences utilisées, Licences non utilisées, et Pic d'utilisation — ce dernier correspondant, selon les termes de Microsoft, à une « utilisation qui dépasse le nombre de licences auquel vous avez droit ». Les droits de licence ne se limitent pas aux achats autonomes de P1/P2 : le décompte « reflète le nombre total de licences, tous produits confondus, incluant chaque niveau de fonctionnalité Microsoft Entra ID », ce qui englobe Microsoft Entra Suite, ID Governance, Verified ID, Private Access et Internet Access.

Trois mises en garde opérationnelles comptent avant d'agir sur ce chiffre :

• Les données affichent l'utilisation du mois précédent et « peuvent prendre jusqu'à trois jours pour se mettre à jour ». Vous ne regardez jamais l'instant présent.
• Le rôle le moins privilégié pouvant consulter la page est Lecteur de rapports ; Lecteur global, Lecteur de sécurité, Opérateur de sécurité, Administrateur de la sécurité, Administrateur d'applications et Administrateur d'applications cloud fonctionnent également.
• La fonctionnalité est disponible uniquement dans les clouds publics.

Redmond a corroboré la source des données en interrogeant directement les journaux de connexion et en comparant le résultat au chiffre du portail. La réconciliation ne fonctionne qu'une fois les invités isolés : son tenant a renvoyé dix utilisateurs uniques ayant réussi une connexion soumise à l'Accès conditionnel, mais seuls trois d'entre eux étaient des membres — et trois était exactement le chiffre rapporté par le portail. Sur cette base, il a jugé « probable que les journaux de connexion soient la source des informations affichées dans le centre d'administration ».

Connect-MgGraph -Scopes AuditLog.Read.All

$Start = (Get-Date).AddDays(-14).ToString('yyyy-MM-dd')
$End   = (Get-Date).AddDays(1).ToString('yyyy-MM-dd')

[array]$Logs = Get-MgAuditLogSignIn -All `
    -Filter "createdDateTime gt $Start and createdDateTime lt $End and conditionalAccessStatus eq 'success'"

[array]$Users = $Logs | Sort-Object UserPrincipalName -Unique |
    Select-Object UserPrincipalName, AdditionalProperties

$TenantId = (Get-MgOrganization).Id
$Guests   = ($Users | Where-Object {
    $_.AdditionalProperties.homeTenantId -ne $TenantId }).Count

Write-Host ("{0} unique users, {1} members, {2} guests" -f `
    $Users.Count, ($Users.Count - $Guests), $Guests)

Comparez le chiffre des membres au décompte des utilisateurs de l'Accès conditionnel affiché par le portail, jamais au total. Les invités sont eux aussi évalués par vos stratégies, mais ils sont facturés en tant qu'utilisateurs actifs mensuels plutôt qu'en sièges P1 — les laisser dans le calcul est le moyen le plus rapide de vous convaincre à tort que le portail se trompe.

Pourquoi l'alerte sous-estime votre exposition de licence réelle

Voici l'écart qui rend la bannière trompeuse dans les deux sens. Le portail mesure les utilisateurs dont les connexions ont été évaluées le mois dernier. La licence, telle qu'elle est généralement comprise, s'applique aux utilisateurs qui sont ciblés par une stratégie — qu'ils se soient connectés ou non.

Une stratégie dont le périmètre est Tous les utilisateurs place chaque compte membre dans son périmètre. Le personnel en congé parental, les travailleurs saisonniers, les comptes dormants mais licenciés, et quiconque ne s'est simplement pas connecté durant la fenêtre de mesure, tombent tous en dehors du décompte « évalué » tout en restant dans le périmètre de la stratégie. Le portail affichera sans problème un chiffre rassurant alors que votre besoin réel en droits de licence est bien plus élevé.

Redmond reconnaît franchement que Microsoft n'a pas levé cette ambiguïté. Dans un complément publié le 18 août 2026, il écrit que « les exigences relatives aux stratégies d'accès conditionnel sont un peu floues », qu'« il ne trouve aucune autre déclaration de Microsoft donnant une définition plus précise de l'exigence de licence », et que « les récentes notifications d'écart de licence n'expliquent pas non plus comment le périmètre de licence est calculé ». Sa lecture pratique penche du côté du ciblage plutôt que de l'évaluation : « si un tenant a déployé des stratégies d'accès conditionnel pour protéger des connexions, il est probable que la plupart, sinon la totalité, des comptes utilisateurs (membres) doivent être licenciés ».

Deux complications supplémentaires faussent la comparaison :

• Les invités sont facturés différemment. La documentation tarifaire External ID de Microsoft confirme que le modèle de facturation aux utilisateurs actifs mensuels (MAU) « s'applique à tous les utilisateurs invités » dont le UserType est défini sur Guest, et précise explicitement qu'il « ne s'applique pas aux utilisateurs originaires de l'organisation dont la valeur UserType est Member ». Le trafic des invités qui atteint vos stratégies n'est pas un problème de siège P1 — mais il peut tout de même gonfler les décomptes bruts de connexion, comme ce fut le cas dans le tenant de Redmond lui-même. Si les identités externes représentent une part importante de votre trafic, examinez séparément l'exposition des comptes invités.
• Les droits de licence peuvent exister sans atteindre les bonnes personnes. Dans le tenant de Redmond, des licences étaient disponibles, et pourtant deux des trois comptes utilisant réellement l'Accès conditionnel disposaient d'Office 365 E3, qui n'inclut ni P1 ni P2. Le stock était suffisant ; l'attribution ne l'était pas.

Ce qui se passe réellement si vos licences Entra ID P1 expirent

C'est le point à vraiment intégrer, car il s'agit d'un comportement documenté et non d'une spéculation. La présentation de l'Accès conditionnel de Microsoft indique : « Lorsque les licences requises pour l'Accès conditionnel expirent, les stratégies ne sont ni automatiquement désactivées ni supprimées. Cet état gracieux permet aux clients de migrer hors des stratégies d'Accès conditionnel sans changement brutal de leur posture de sécurité. Vous pouvez afficher et supprimer les stratégies restantes, mais vous ne pouvez pas les mettre à jour. »

Lisez cela attentivement. Votre application ne s'effondre pas — ce qui relève d'une bonne conception. Mais votre plan de contrôle d'accès principal entre en gel des modifications : l'affichage et la suppression restent disponibles, la mise à jour non. Un incident qui nécessite de resserrer une stratégie en urgence, d'ajouter une exclusion pour un compte d'accès d'urgence (break-glass), ou de restreindre un périmètre, devient quelque chose que vous ne pouvez pas faire tant que la situation de licence n'est pas résolue. C'est un risque de disponibilité et de réponse à incident, pas un risque de facturation — et c'est la vraie raison de réconcilier les chiffres dès maintenant.

Détection

Partez du chiffre fourni par Microsoft pour remonter jusqu'à celui qui régit réellement votre position de licence.

Le portail ne peut pas répondre à cette dernière ligne : vous devez donc énumérer vous-même le périmètre des stratégies. Seules les stratégies activées appliquent réellement un contrôle — les stratégies en mode rapport seul évaluent sans jamais accorder ni bloquer l'accès :

Connect-MgGraph -Scopes Policy.Read.All, Directory.Read.All, User.Read.All

[array]$Policies = Get-MgIdentityConditionalAccessPolicy -All -Filter "state eq 'enabled'"

ForEach ($Policy in $Policies) {
    $Scope = $Policy.Conditions.Users
    [PSCustomObject]@{
        Policy         = $Policy.DisplayName
        IncludedUsers  = ($Scope.IncludeUsers -join ', ')
        IncludedGroups = $Scope.IncludeGroups.Count
        IncludedRoles  = $Scope.IncludeRoles.Count
        ExcludedUsers  = $Scope.ExcludeUsers.Count
        ExcludedGroups = $Scope.ExcludeGroups.Count
    }
}

Une valeur IncludeUsers égale à All place chaque utilisateur dans le périmètre, invités compris — filtrez sur userType eq 'Member' avant de compter, car seuls les membres génèrent des besoins en sièges P1. Lorsque le périmètre est défini par un groupe ou un rôle d'annuaire, résolvez-le de façon transitive — les groupes imbriqués et l'appartenance aux rôles élargissent tous deux l'ensemble effectif, c'est pourquoi Get-MgGroupTransitiveMemberAsUser et Get-MgDirectoryRoleMember ont leur place dans toute version sérieuse de ce script. Le script de réconciliation complet de Redmond, sur lequel s'appuient les requêtes de cette section, fait exactement cela et est publié dans le dépôt GitHub Microsoft 365 for IT Pros.

Établissez ensuite qui détient réellement un plan de service P1 ou P2 actif. Les identifiants de plan de service sont publiés dans la référence des plans de service de Microsoft : AAD_PREMIUM correspond à 41781fb2-bc02-4b7c-bd55-b576c07bb09d et AAD_PREMIUM_P2 à eec0eb4f-6444-4f95-aba0-50c24d67f998.

$EntraP1 = "41781fb2-bc02-4b7c-bd55-b576c07bb09d"
$EntraP2 = "eec0eb4f-6444-4f95-aba0-50c24d67f998"

Get-MgSubscribedSku -All |
    Where-Object { $_.ServicePlans.ServicePlanId -contains $EntraP1 -or
                   $_.ServicePlans.ServicePlanId -contains $EntraP2 } |
    Select-Object SkuPartNumber, ConsumedUnits,
                  @{Name = 'Prepaid'; Expression = { $_.PrepaidUnits.Enabled }}

[array]$LicensedUsers = Get-MgUser -All -ConsistencyLevel eventual -CountVariable Records `
    -Property Id, UserPrincipalName, AssignedPlans `
    -Filter "(assignedPlans/any(s:s/servicePlanId eq $EntraP1) or assignedPlans/any(s:s/servicePlanId eq $EntraP2)) and userType eq 'Member' and accountEnabled ne false"

[array]$EffectivelyLicensed = $LicensedUsers | Where-Object {
    $_.AssignedPlans | Where-Object {
        $_.ServicePlanId -in @($EntraP1, $EntraP2) -and $_.CapabilityStatus -eq 'Enabled' }
}

Write-Host ("{0} enabled member accounts hold an active Entra P1/P2 service plan" -f $EffectivelyLicensed.Count)

La vérification du CapabilityStatus n'est pas optionnelle. Un plan de service peut encore apparaître sur un compte après le retrait d'une licence : sa seule présence surestime donc votre population licenciée.

Considérez ce résultat comme un point de départ pour l'investigation, pas comme un certificat de conformité. Redmond est explicite sur la limite de ce type de script : « je ne prétends pas que ce script prouve la conformité du tenant aux exigences de licence de Microsoft. Coder à partir d'informations imprécises est toujours difficile, et Microsoft ne publie pas de définition précise de la consommation de licence de l'Accès conditionnel ».

Remediation

1. Réconciliez avant d'acheter. Comparez l'ensemble des comptes ciblés mais non licenciés, dérivé de Graph, à votre stock de droits de licence. Une bannière de dépassement causée par une mauvaise attribution ne coûte rien à corriger.
2. Expliquez l'écart avec des preuves, pas des suppositions. Identités en double, comptes secondaires administratifs, comptes de service et invités expliquent chacun l'écart différemment. Documentez comment chaque compte secondaire correspond à une personne licenciée — c'est ce document qu'un audit ou une conversation de régularisation exigera.
3. Resserrez le périmètre délibérément, pas défensivement. Restreindre une stratégie réduit à la fois l'exposition de licence et la couverture de sécurité. Ne supprimez jamais la couverture de base pour les administrateurs, tous les utilisateurs ou toutes les applications simplement pour améliorer un chiffre.
4. Auditez les exclusions tant que vous y êtes. Les listes d'exclusion s'accumulent. Des exclusions obsolètes au niveau utilisateur et des exclusions de groupe surdimensionnées retirent silencieusement des personnes de l'application, tout en faussant le décompte des utilisateurs évalués. Conservez les exclusions délibérées — vos comptes d'accès d'urgence (break-glass) doivent rester exclus et surveillés.
5. Confirmez le P2 séparément. Les stratégies basées sur le risque de connexion et le risque utilisateur nécessitent ID Protection. Si l'onglet ID Protection affiche une utilisation que vous ne pouvez pas expliquer, vérifiez ce que vos fonctionnalités P2 couvrent réellement en matière de licence.
6. Revérifiez après le délai. Les données d'utilisation reflètent le mois précédent et peuvent prendre jusqu'à trois jours pour se mettre à jour. Ne jugez pas une remédiation sur le portail l'après-midi même où vous l'avez appliquée.

Comment EtcSec détecte cela

La bannière de licence est le symptôme de quelque chose qu'EtcSec audite directement : l'écart entre ce que vos stratégies d'Accès conditionnel prétendent couvrir et ce qu'elles appliquent réellement. Un audit Azure EtcSec énumère le périmètre des stratégies activées de la même façon que les requêtes Graph ci-dessus, puis signale CA_NO_POLICY_ALL_USERS lorsqu'aucune stratégie ne cible l'ensemble de la population de membres, CA_POLICY_REPORT_ONLY lorsque des stratégies évaluent sans jamais appliquer de contrôle, CA_EXCESSIVE_EXCLUSIONS et CA_USER_EXCLUSIONS_STALE lorsque les listes d'exclusion ont dépassé leur justification, CA_NO_BREAK_GLASS_EXCLUSION lorsque l'accès d'urgence ne dispose d'aucun chemin protégé, et CA_NO_RISK_BASED_SIGNIN lorsque des droits P2 sont payés mais inutilisés.

Ce dernier point joue dans les deux sens : une capacité P2 inutilisée est un dépassement de licence à l'envers. Pour une revue plus large de la conception des stratégies, consultez notre guide sur les failles de l'Accès conditionnel Entra ID et le guide pratique d'audit de sécurité Entra ID.