Microsoft Entra ID : Sécuriser en 13 Étapes [2026]

Sécuriser les identités est devenu le premier chantier de toute équipe infrastructure en 2026. Microsoft Entra ID, le nom officiel de la plateforme anciennement appelée Azure Active Directory, reste au centre de cette bataille pour des milliers d’organisations en France et en Europe. Ce tutoriel vous accompagne pas à pas, de l’audit initial de votre tenant jusqu’à la mise en place d’un accès conditionnel avancé, de la gestion des identités privilégiées (PIM) et de l’authentification sans mot de passe. Comptez environ 90 minutes pour suivre les 13 étapes, en incluant les tests de validation sur un tenant de préproduction. Chaque bloc du guide part d’un principe simple : ne jamais appliquer un changement d’identité en production sans l’avoir simulé au préalable, un réflexe qui évite la majorité des incidents de verrouillage que rencontrent les équipes IT.

Pourquoi sécuriser Microsoft Entra ID est devenu incontournable en 2026

Microsoft a définitivement abandonné l’appellation Azure Active Directory au profit de Microsoft Entra ID. La documentation officielle du produit le confirme explicitement : Entra ID est aujourd’hui le nom commercial du service, même si certaines URL techniques conservent encore une trace de l’ancienne marque pour des raisons de compatibilité. Ce changement de nom accompagne une évolution plus profonde du produit, désormais pensé comme le plan de contrôle central de toutes les identités d’une organisation, qu’elles soient humaines, machines ou, de plus en plus, des agents IA.

Le constat est simple : l’identité reste la cible numéro un des attaquants. Un compte compromis, une stratégie d’accès conditionnel mal configurée ou un rôle administrateur laissé actif en permanence suffisent à ouvrir la porte à un mouvement latéral complet dans le tenant. Microsoft a justement conçu son Identity Secure Score pour matérialiser ce risque sous forme de score chiffré, avec des actions concrètes et pondérées. Activer le MFA pour tous les utilisateurs rapporte 9 points, et l’exiger spécifiquement pour les rôles administratifs en rapporte 10, selon le barème documenté par Microsoft. Ces deux recommandations, parmi les plus simples à appliquer, restent pourtant ignorées dans un grand nombre de tenants observés par les équipes de support.

La pression réglementaire européenne accentue cette urgence. La directive NIS2 impose des mesures de gestion des accès et d’authentification forte aux entités essentielles et importantes, et le règlement eIDAS 2.0 pousse vers des identités numériques vérifiables. L’ANSSI publie régulièrement des recommandations sur le renforcement de l’authentification pour les entités françaises concernées par ces textes. Pour les entreprises françaises soumises à ces textes, Entra ID devient souvent la brique technique qui permet de documenter la conformité, à condition d’être configuré correctement. Nous reviendrons plus loin sur ces obligations, mais gardez en tête que la configuration que vous allez mettre en place dans ce tutoriel sert aussi de preuve d’audit.

Ce tutoriel ne couvre pas la totalité de la plateforme Entra ID, qui inclut aussi la gestion des identités externes, la fédération avec des annuaires tiers ou la gouvernance des accès applicatifs. Il se concentre volontairement sur le socle de sécurité le plus souvent audité : authentification, accès conditionnel, gestion du risque et privilèges administratifs. Une fois ce socle posé, les briques plus avancées comme Entra Verified ID ou la gouvernance des identités deviennent nettement plus simples à intégrer, car elles s’appuient sur les mêmes groupes et les mêmes stratégies que vous aurez déjà construits.

Prérequis : licences, rôles et outils nécessaires

Avant de commencer, vérifiez que votre abonnement couvre les fonctionnalités que ce tutoriel active. Microsoft structure Entra ID en plusieurs paliers de licence, et chaque étape de ce guide précise le niveau minimal requis. Le tableau ci-dessous résume les tarifs publics américains communiqués par Microsoft, exprimés en dollars par utilisateur et par mois avec engagement annuel. Le tarif exact en euros pour la France dépend de votre contrat Microsoft (CSP, EA ou abonnement direct) et doit être confirmé auprès de votre revendeur. La grille complète reste consultable sur la page tarifaire officielle Entra ID.

Édition	Prix public (USD/utilisateur/mois)	Fonctions clés activées
Entra ID Free	Inclus avec certains abonnements	Gestion des utilisateurs, SSO basique, rapports limités
Entra ID P1	7 $	Accès conditionnel, groupes dynamiques, réinitialisation self-service
Entra ID P2	10 $	Identity Protection, PIM, accès adaptatif basé sur le risque
Entra ID Governance	Tarif non communiqué publiquement pour la France	Gouvernance des identités, extensions PIM avancées

Pour suivre l’ensemble des 13 étapes, prévoyez un tenant avec licence P2 (ou Entra ID Suite, qui inclut P1 et P2), un compte avec le rôle Administrateur de sécurité ou Administrateur Entra ID global, et les outils suivants installés sur votre poste : PowerShell 7.4 ou version ultérieure, le module Microsoft Graph PowerShell SDK (Microsoft.Graph, dernière version publiée), Terraform 1.9 ou plus récent avec le provider azuread, et un accès au portail Microsoft Entra admin center. Un tenant de test distinct de la production est fortement recommandé pour valider chaque stratégie avant son déploiement réel.

Vérifiez aussi vos rôles avant de commencer. Un compte avec uniquement le rôle Administrateur d’utilisateurs ne pourra pas créer de stratégie d’accès conditionnel, tandis qu’un compte Administrateur global dispose de tous les droits mais représente un risque disproportionné s’il n’est pas protégé par PIM. Pour ce tutoriel, le rôle Administrateur d’accès conditionnel suffit pour les étapes 1 à 6, et le rôle Administrateur des rôles privilégiés devient nécessaire à partir de l’étape 7. Documentez cette distinction dans votre procédure interne, elle évite de distribuer des droits globaux par simple facilité.

Étapes 1 à 3 : auditer votre tenant, activer le MFA et créer votre première stratégie

Étape 1 : auditer votre Identity Secure Score actuel

Commencez toujours par mesurer l’existant. Le score d’identité sécurisée donne une photographie instantanée de votre posture, avec des recommandations classées par impact. Connectez-vous au Microsoft Entra admin center, ouvrez la section Identity Secure Score, et notez votre score de départ ainsi que les trois recommandations les mieux pondérées. Vous pouvez aussi récupérer ces données par script pour les intégrer à un tableau de bord interne.

# Connexion au module Microsoft Graph PowerShell
Connect-MgGraph -Scopes "SecurityEvents.Read.All"

# Récupération du score de sécurité des identités
Get-MgSecuritySecureScore -Top 1 | Select-Object CurrentScore, MaxScore, CreatedDateTime

# Liste des contrôles non appliqués, triés par poids
Get-MgSecuritySecureScoreControlProfile |
  Where-Object { $_.ControlCategory -eq "Identity" } |
  Sort-Object -Property MaxScore -Descending |
  Select-Object Title, MaxScore, Rank

Conservez cet export. Il servira de ligne de référence pour mesurer la progression après la mise en œuvre des étapes suivantes, et constitue une pièce utile si un auditeur NIS2 vous demande une preuve d’amélioration continue.

Profitez aussi de cet audit initial pour cartographier les comptes à privilèges existants. Beaucoup de tenants accumulent des rôles administrateurs attribués il y a plusieurs années à des prestataires ou des anciens salariés, jamais révoqués faute de processus de sortie clair. Exportez la liste complète des membres de rôles privilégiés avec leur date de dernière connexion, et marquez pour révocation tout compte inactif depuis plus de 90 jours. Cette étape prend quelques minutes mais élimine souvent une part significative de la surface d’attaque avant même d’avoir touché à une seule stratégie.

Étape 2 : activer le MFA via une stratégie d’accès conditionnel

Microsoft déconseille désormais le MFA par utilisateur, une méthode historique difficile à maintenir à l’échelle. La documentation officielle Microsoft recommande de passer systématiquement par une stratégie d’accès conditionnel pour appliquer le MFA, car cette approche centralise la logique et s’adapte au contexte de connexion plutôt qu’à un simple interrupteur par compte. Si votre tenant utilise encore l’ancien MFA par utilisateur, migrez-le avant de poursuivre.

Dans le portail, créez une première stratégie nommée “Baseline – MFA tous utilisateurs”, ciblez tous les utilisateurs sauf un compte de secours exclu volontairement, et exigez l’authentification multifacteur comme contrôle d’accès. Activez-la d’abord en mode “Rapport seulement” pendant 48 heures avant de passer en mode “Activé”, afin de repérer les flux applicatifs qui casseraient sous la contrainte.

Étape 3 : créer une stratégie d’accès conditionnel personnalisée

Une fois le socle MFA posé, affinez la logique d’accès selon vos besoins métier. Une stratégie courante consiste à exiger un appareil conforme pour les connexions aux applications RH ou financières, tout en laissant un accès plus souple pour les outils bureautiques standards, conformément aux principes décrits dans la documentation de référence sur l’accès conditionnel. Vous pouvez créer cette stratégie via Microsoft Graph pour l’intégrer à un pipeline d’infrastructure as code.

POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies
Content-Type: application/json

{
  "displayName": "Exiger appareil conforme - Apps sensibles",
  "state": "enabledForReportingButNotEnforced",
  "conditions": {
    "applications": { "includeApplications": ["APP_ID_RH", "APP_ID_FINANCE"] },
    "users": { "includeGroups": ["GROUPE_COLLABORATEURS_ID"] }
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["compliantDevice", "mfa"]
  }
}

Gardez l’opérateur sur “OR” dans un premier temps pour éviter de bloquer des utilisateurs légitimes sans appareil géré, puis resserrez vers “AND” une fois la conformité des terminaux stabilisée.

Pensez également à nommer vos stratégies de façon cohérente dès cette étape. Un préfixe par domaine (Baseline, App-Critique, Risque) facilite grandement la lecture du portail une fois que vous aurez accumulé une dizaine de stratégies actives. Un nom vague comme “Policy1” ou “Test MFA” devient rapidement un problème lors d’un audit ou d’une passation entre administrateurs, personne ne sait alors ce que la stratégie fait réellement sans l’ouvrir une par une.

Étapes 4 à 6 : bloquer l’authentification héritée et déployer les passkeys

Étape 4 : bloquer les protocoles d’authentification héritée

Les protocoles hérités comme POP, IMAP ou SMTP authentifié ne prennent pas en charge l’accès conditionnel moderne et restent une porte d’entrée privilégiée pour les attaques par pulvérisation de mot de passe. Créez une stratégie dédiée qui cible spécifiquement les clients d’authentification héritée et bloque l’accès, sans exception. Testez d’abord en mode rapport pour identifier les applications legacy encore en service, souvent des scripts métiers oubliés ou de vieux systèmes de messagerie connectés en IMAP.

Une fois l’inventaire terminé, procédez par vagues plutôt que par un blocage unique. Isolez d’abord les comptes de service identifiés sans dépendance critique, vérifiez l’absence d’échec sur une semaine, puis étendez le blocage au reste du tenant. Cette approche progressive réduit considérablement le risque d’interruption, au prix de quelques jours supplémentaires de déploiement qui restent largement préférables à un incident de production.

Étape 5 : déployer les clés d’accès et l’authentification FIDO2

Depuis le 1er septembre 2026, Microsoft a basculé les clés d’accès (passkeys) comme expérience d’authentification par défaut, activée automatiquement pour les comptes qui s’appuyaient jusqu’alors sur le SMS ou l’appel vocal. Ce changement répond à la faiblesse bien connue de ces deux canaux, vulnérables au SIM swapping et à l’interception. Profitez de cette bascule pour pousser activement l’enregistrement de clés FIDO2 matérielles ou de passkeys synchronisées sur les comptes à privilèges élevés.

# Activation de la méthode d'authentification FIDO2 pour un groupe cible
Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
  -AuthenticationMethodConfigurationId "Fido2" `
  -BodyParameter @{
    "@odata.type" = "#microsoft.graph.fido2AuthenticationMethodConfiguration"
    state = "enabled"
    includeTargets = @(@{ targetType = "group"; id = "GROUPE_ADMINS_ID" })
    isSelfServiceRegistrationAllowed = $true
    keyRestrictions = @{ isEnforced = $false }
  }

Vérifiez que vos administrateurs IT disposent d’au moins deux méthodes de secours enregistrées avant de désactiver les anciennes options, afin d’éviter un verrouillage complet en cas de perte d’un appareil.

Le choix entre passkey synchronisée et clé FIDO2 matérielle dépend du profil de risque du compte. Une passkey synchronisée via le gestionnaire de mots de passe du système convient à la majorité des collaborateurs, car elle combine confort d’usage et résistance au phishing. Pour les comptes à privilèges élevés ou les administrateurs qui gèrent l’infrastructure critique, une clé matérielle dédiée, jamais synchronisée dans le cloud, limite l’exposition même en cas de compromission complète d’un poste de travail.

Étape 6 : configurer Entra ID Protection et l’accès basé sur le risque

Entra ID Protection, inclus dans la licence P2, détecte les signaux de risque liés à l’utilisateur et à la connexion : adresse IP anonymisée, voyage improbable, fuite d’identifiants détectée sur le dark web, ou comportement de connexion atypique. Ces signaux alimentent ensuite vos stratégies d’accès conditionnel pour déclencher une action automatique, comme exiger une réauthentification MFA ou bloquer purement la session lorsque le risque est jugé élevé.

Configurez deux stratégies distinctes : une basée sur le risque utilisateur, qui force un changement de mot de passe sécurisé quand un compte est jugé compromis, et une basée sur le risque de connexion, qui exige une MFA supplémentaire pour les connexions à risque moyen ou élevé. Laissez Microsoft gérer la remédiation automatique plutôt que de construire votre propre logique. La documentation officielle insiste sur l’intérêt des stratégies de remédiation managées par Microsoft pour rester synchronisé avec l’évolution des modèles de détection.

Tableau comparatif : modèles de stratégies d’accès conditionnel

Avant d’aller plus loin dans la gestion des rôles privilégiés, voici un récapitulatif des stratégies d’accès conditionnel les plus utiles à combiner, avec le niveau de licence requis et l’ordre de priorité recommandé lors d’un déploiement progressif.

Stratégie	Licence requise	Priorité de déploiement	Risque si absente
MFA pour tous les utilisateurs	P1	1	Compromission par vol de mot de passe
Blocage authentification héritée	P1	2	Contournement du MFA via protocoles anciens
MFA renforcé pour rôles admin	P1	3	Prise de contrôle totale du tenant
Appareil conforme pour apps sensibles	P1 + Intune	4	Fuite de données depuis un terminal non géré
Accès basé sur le risque utilisateur	P2	5	Compte compromis non détecté
Accès basé sur le risque de connexion	P2	6	Connexion anormale non bloquée
Accès conditionnel pour agents IA	P1 minimum + M365 E3/E7	7	Agent autonome avec accès excessif

La dernière ligne mérite une attention particulière en 2026 : Microsoft a introduit l’accès conditionnel pour les agents, une fonctionnalité qui s’applique aux identités d’agents IA autonomes connectés au tenant. Elle est documentée comme nécessitant Microsoft 365 E7, ou l’offre Microsoft Agent 365 combinée à une licence Entra P1 au minimum. Avec la multiplication des agents IA dans les environnements d’entreprise, cette catégorie de stratégie va rapidement devenir aussi standard que le MFA l’est aujourd’hui pour les comptes humains.

Étapes 7 à 9 : détection du risque et accès privilégié juste-à-temps avec PIM

Étape 7 : activer PIM pour les rôles privilégiés

Privileged Identity Management transforme les rôles d’administration permanents en droits éligibles, activables seulement en cas de besoin et pour une durée limitée. Microsoft décrit cette approche comme un moyen de permettre aux comptes d’administration de réclamer un accès juste-à-temps, plutôt que de conserver des privilèges actifs en continu. Commencez par le rôle Administrateur global, le plus critique, et basculez chaque titulaire d’un statut “actif” à un statut “éligible”.

# Rendre un utilisateur éligible au rôle Administrateur global via PIM
New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest -BodyParameter @{
  Action = "AdminAssign"
  PrincipalId = "ID_UTILISATEUR"
  RoleDefinitionId = "62e90394-69f5-4237-9190-012177145e10"
  DirectoryScopeId = "/"
  ScheduleInfo = @{
    StartDateTime = (Get-Date)
    Expiration = @{ Type = "AfterDuration"; Duration = "P180D" }
  }
}

Un utilisateur rendu éligible pour un rôle Entra peut ensuite activer ce rôle pour une durée limitée lorsqu’il en a réellement besoin, selon le modèle décrit par Microsoft dans ses recommandations de gestion des rôles. Exigez systématiquement une justification textuelle et une MFA au moment de l’activation.

Configurez aussi les notifications d’activation PIM vers un canal visible par toute l’équipe sécurité, pas seulement vers l’utilisateur concerné. Cette visibilité collective permet de repérer rapidement une activation suspecte, par exemple en dehors des horaires habituels ou depuis une localisation inattendue. Combinez cette notification avec une durée d’activation courte, quatre à huit heures suffisent pour la grande majorité des tâches d’administration courantes.

Étape 8 : configurer PIM for Groups et l’accès juste-à-temps

PIM ne se limite pas aux rôles Entra natifs. PIM for Groups permet d’appliquer la même logique d’éligibilité temporaire à l’appartenance d’un groupe Microsoft 365 ou de sécurité, ce qui couvre aussi les accès applicatifs tiers gérés par groupe. Créez un groupe “Accès-Prod-Éligible”, activez PIM for Groups dessus, et fixez une durée maximale d’activation de quatre heures pour les interventions de production.

Étape 9 : restreindre l’accès aux applications sensibles par groupes dynamiques

Les groupes dynamiques recalculent automatiquement leur appartenance selon des règles basées sur les attributs utilisateur, comme le département ou le statut d’emploi. Associez un groupe dynamique à chaque application critique, avec une règle qui exclut automatiquement les comptes désactivés ou les contrats arrivés à terme. Ce mécanisme réduit fortement le risque d’un accès oublié après un départ, un problème récurrent dans les audits de conformité.

Testez chaque règle de groupe dynamique sur un échantillon avant de l’appliquer largement. Microsoft fournit un outil de validation qui simule l’appartenance résultante sans modifier réellement le groupe, ce qui permet de repérer une faute de syntaxe ou un attribut mal orthographié avant qu’il n’affecte des centaines de comptes. Combinez cette règle avec une revue d’accès périodique automatisée, qui demande au propriétaire de chaque application de confirmer que la liste des membres reste pertinente.

Étapes 10 à 13 : surveillance, automatisation et audit continu

Étape 10 : centraliser les journaux de connexion dans Log Analytics

Configurez les paramètres de diagnostic d’Entra ID pour exporter les journaux SignInLogs, AuditLogs et RiskyUsers vers un espace de travail Log Analytics, idéalement relié à Microsoft Sentinel si votre organisation en dispose. Cette centralisation permet de corréler les événements d’identité avec le reste de votre télémétrie réseau et endpoint, plutôt que de rester isolé dans le seul portail Entra.

Étape 11 : automatiser la détection avec une requête KQL

Une fois les journaux centralisés, écrivez des requêtes Kusto pour détecter les schémas suspects que les stratégies natives ne couvrent pas toujours, comme une activation PIM suivie immédiatement d’une modification de stratégie d’accès conditionnel.

AuditLogs
| where OperationName == "Add role to PrincipalInEligibleRole"
    or OperationName == "Update conditional access policy"
| summarize Count = count(), Operations = make_set(OperationName)
    by InitiatedBy = tostring(InitiatedBy.user.userPrincipalName), bin(TimeGenerated, 1h)
| where Count >= 2
| order by TimeGenerated desc

Branchez cette requête sur une règle d’analytique Sentinel programmée toutes les heures, avec une notification automatique vers votre canal SOC. L’objectif est de repérer en quelques minutes une activation de privilège suivie d’un changement de politique, un schéma typique d’une tentative de contournement.

Ne vous arrêtez pas à une seule règle de détection. Ajoutez des variantes qui surveillent les connexions réussies depuis des pays inhabituels pour votre organisation, les tentatives d’enregistrement de nouvelles méthodes MFA en dehors des horaires de bureau, et les suppressions de stratégie d’accès conditionnel, un événement rare qui mérite une alerte immédiate quelle que soit l’heure. Plus votre bibliothèque de requêtes KQL grandit, plus votre capacité à détecter un comportement anormal avant qu’il ne cause un dommage réel augmente.

Étape 12 : simuler l’impact avec le mode “Rapport seulement”

Avant d’activer toute nouvelle stratégie en production, utilisez systématiquement l’outil “What If” du portail Entra pour simuler son impact sur un utilisateur et une application donnés. Cet outil répond à la question centrale avant tout déploiement : quelle stratégie va s’appliquer, et avec quel effet, pour ce scénario précis. Documentez chaque simulation dans votre ticket de changement, cela évite les mauvaises surprises lors du passage en mode appliqué.

Étape 13 : documenter, revoir et planifier la sauvegarde du tenant

Clôturez le cycle en documentant chaque stratégie dans un registre interne, avec sa date de création, son objectif et son propriétaire. Planifiez une revue trimestrielle des accès PIM actifs, des exclusions de stratégie et des comptes de service à privilèges. Mettez également en place une procédure de sauvegarde de la configuration du tenant (stratégies d’accès conditionnel, rôles personnalisés, paramètres d’authentification) pour pouvoir restaurer rapidement en cas d’erreur de configuration ou d’incident majeur.

Projet complet : industrialiser la configuration avec Terraform

Pour éviter la dérive de configuration entre tenants de développement, de test et de production, déployez vos stratégies via Terraform et le provider azuread plutôt que manuellement dans le portail. Voici un exemple fonctionnel qui combine la stratégie MFA de base et le blocage de l’authentification héritée vus plus haut.

terraform {
  required_providers {
    azuread = {
      source  = "hashicorp/azuread"
      version = "~> 3.0"
    }
  }
}

resource "azuread_conditional_access_policy" "baseline_mfa" {
  display_name = "Baseline - MFA tous utilisateurs"
  state        = "enabled"

  conditions {
    client_app_types   = ["all"]
    sign_in_risk_levels = ["none"]
    user_risk_levels    = ["none"]

    applications {
      included_applications = ["All"]
    }

    users {
      included_users  = ["All"]
      excluded_groups = [azuread_group.break_glass.object_id]
    }
  }

  grant_controls {
    operator         = "OR"
    built_in_controls = ["mfa"]
  }
}

resource "azuread_conditional_access_policy" "block_legacy_auth" {
  display_name = "Bloquer authentification héritée"
  state        = "enabled"

  conditions {
    client_app_types = ["exchangeActiveSync", "other"]

    applications {
      included_applications = ["All"]
    }

    users {
      included_users = ["All"]
    }
  }

  grant_controls {
    operator         = "OR"
    built_in_controls = ["block"]
  }
}

Intégrez ce module dans votre pipeline CI/CD avec une étape de plan systématique avant tout apply en production, et stockez l’état Terraform dans un backend distant chiffré. Ce projet, combiné aux scripts PowerShell des étapes précédentes, couvre l’ensemble du cycle : audit, mise en œuvre, automatisation et reproductibilité.

Ajoutez un module de test avec Terratest ou un simple script de validation qui vérifie, après chaque apply, que les stratégies critiques (MFA, blocage legacy) sont bien dans l’état “enabled” attendu. Un apply qui réussit techniquement peut parfois laisser une stratégie en mode rapport par erreur de variable, et seul un test post-déploiement automatisé détecte fiablement ce genre de dérive avant qu’un collaborateur ne s’en aperçoive à ses dépens.

Erreurs fréquentes à éviter

Oublier le compte de secours (break glass) : sans compte exclu de toutes les stratégies d’accès conditionnel, un bug de configuration peut vous verrouiller totalement hors du tenant.
Activer une stratégie directement en mode appliqué : sautez le mode “Rapport seulement” et vous risquez de bloquer des flux métiers critiques sans préavis.
Confondre rôle éligible et rôle actif dans PIM : un rôle laissé actif en permanence annule tout l’intérêt de PIM. Vérifiez régulièrement qu’aucun compte n’a été réassigné en mode permanent par erreur.
Négliger les comptes de service : un compte applicatif avec un rôle admin permanent et sans MFA reste une cible privilégiée. Isolez-le avec une stratégie dédiée et des identités managées quand c’est possible.
Déployer le blocage d’authentification héritée sans audit préalable : certains systèmes legacy critiques utilisent encore IMAP ou SMTP authentifié, et un blocage brutal peut interrompre une chaîne de traitement métier.
Ignorer les groupes dynamiques obsolètes : une règle d’attribut mal maintenue peut inclure ou exclure silencieusement les mauvais utilisateurs après une réorganisation.
Appliquer la même durée d’activation PIM à tous les rôles : un rôle de lecture seule et un rôle d’administrateur global ne présentent pas le même niveau de risque, et mériteraient des durées maximales différentes.
Déployer Terraform sans verrouiller l’état : deux administrateurs qui appliquent des changements en parallèle sans backend distant verrouillé peuvent écraser mutuellement leurs modifications sans avertissement.

Dépannage : résoudre les problèmes courants

Même avec une configuration soignée, certains comportements reviennent régulièrement une fois les stratégies déployées à grande échelle. La plupart de ces incidents proviennent d’une interaction entre plusieurs stratégies plutôt que d’une seule règle isolée, ce qui complique parfois le diagnostic si vous n’avez pas conservé une documentation claire de l’ordre de priorité. Voici les symptômes les plus signalés et leur résolution.

Symptôme	Cause probable	Solution
Boucle de connexion infinie après activation du MFA	Conflit entre deux stratégies d’accès conditionnel contradictoires	Utiliser l’outil “What If” pour identifier la stratégie prioritaire en conflit
Utilisateur verrouillé hors du tenant	Stratégie de blocage appliquée sans compte de secours exclu	Se connecter avec le compte break glass et corriger la portée de la stratégie
Activation PIM refusée	Absence de méthode MFA enregistrée sur le compte	Enregistrer une méthode d’authentification avant de tenter l’activation
Application legacy qui cesse de fonctionner	Blocage de l’authentification héritée sans migration du client	Migrer le client vers OAuth 2.0 moderne ou créer une exception temporaire documentée
Faux positifs de risque de connexion	VPN d’entreprise détecté comme localisation improbable	Ajouter les plages IP du VPN aux emplacements nommés de confiance
Groupe dynamique vide après une mise à jour de règle	Erreur de syntaxe dans la règle d’appartenance	Valider la règle avec l’outil de validation avant de l’enregistrer
Score de sécurité qui stagne malgré les actions	Délai de recalcul du score côté Microsoft	Attendre le cycle de recalcul (généralement sous 48 heures) avant de ré-auditer
Rejets FIDO2 sur certains navigateurs	Navigateur ou système obsolète sans support WebAuthn complet	Mettre à jour le navigateur ou proposer une méthode de repli temporaire

Conseils avancés pour les environnements multi-tenants

Les groupes qui gèrent plusieurs tenants Entra, par exemple après une fusion-acquisition ou pour isoler des filiales, gagnent à centraliser leurs politiques dans un dépôt Terraform unique avec des variables par environnement plutôt que de dupliquer la configuration manuellement. Utilisez des workspaces Terraform distincts par tenant et un pipeline de validation commun. Cela garantit que toute amélioration de sécurité se propage partout sans divergence.

Pensez aussi à l’inscription des appareils. Les machines peuvent être Microsoft Entra Registered, Joined ou Hybrid Joined selon leur scénario, et cette distinction conditionne directement la capacité à exiger un appareil conforme dans vos stratégies d’accès conditionnel. Un parc mal classifié produit des exceptions silencieuses qui affaiblissent vos règles sans que personne ne le remarque avant un audit.

Enfin, surveillez les extensions personnalisées de PIM, encore documentées comme fonctionnalité en préversion par Microsoft. Elles permettent de brancher une validation externe avant l’activation d’un rôle, par exemple une approbation via un outil tiers de gestion des changements. Testez-les en isolation avant tout déploiement large. Une fonctionnalité en préversion peut évoluer sans préavis complet.

Un dernier conseil concerne la rotation des comptes de secours. Un compte break glass oublié pendant des années, avec un mot de passe jamais changé et aucune surveillance dédiée, devient lui-même une faille. Placez ce compte sous surveillance renforcée avec une alerte immédiate à chaque connexion, changez son mot de passe selon un calendrier strict, et conservez les identifiants dans un coffre-fort physique ou un gestionnaire de secrets d’entreprise plutôt que dans un fichier partagé.

Conformité : NIS2, CRA et exigences européennes

Pour les entités françaises classées essentielles ou importantes au titre de la directive NIS2, la gestion des identités et des accès fait partie des mesures techniques explicitement attendues, au même titre que la gestion des vulnérabilités ou la réponse à incident. La configuration détaillée dans ce tutoriel (accès conditionnel documenté, MFA généralisé, PIM pour les comptes à privilèges) répond directement à plusieurs de ces attentes. Pour le détail de la procédure de transposition française et son calendrier, consultez notre analyse de la procédure engagée par la Commission devant la CJUE.

Le Cyber Resilience Act ajoute une couche supplémentaire pour les éditeurs de logiciels et les fabricants de produits connectés commercialisés dans l’Union européenne, avec des obligations de gestion des vulnérabilités tout au long du cycle de vie. Si votre organisation publie des produits numériques en plus de les exploiter en interne, la journalisation produite par les étapes 10 et 11 de ce tutoriel constitue une base solide pour documenter votre réponse aux incidents de sécurité liés à l’identité.

Le règlement eIDAS 2.0 entre aussi en jeu pour les organisations qui prévoient d’intégrer le futur portefeuille européen d’identité numérique. Entra Verified ID, la brique de Microsoft pour les identités vérifiables, s’appuie sur les mêmes concepts de groupes et de stratégies que vous avez mis en place dans ce tutoriel, ce qui facilite grandement une adoption ultérieure si votre secteur d’activité l’exige. Mieux vaut construire ce socle d’identité proprement dès maintenant que de devoir le refaire sous la contrainte d’une échéance réglementaire serrée.

Résultats attendus et exemples de sortie

Une fois les 13 étapes appliquées sur un tenant de taille moyenne, voici le type de progression généralement observé. Le score Identity Secure Score augmente en priorité sur les contrôles liés au MFA et à l’authentification héritée, souvent parmi les gains les plus rapides à obtenir. Une exécution de la requête KQL de l’étape 11 sur un tenant sain retourne généralement un résultat vide, ce qui constitue le comportement attendu plutôt qu’une anomalie.

# Sortie attendue après exécution du script d'audit (étape 1)
CurrentScore MaxScore CreatedDateTime
------------ -------- ----------------
         142      210 2026-10-06T09:12:00Z

Title                                          MaxScore Rank
-----                                          -------- ----
Exiger le MFA pour tous les utilisateurs              9    1
Exiger le MFA pour les rôles administratifs          10    2
Bloquer l'authentification héritée                    7    3

Un déploiement Terraform réussi de l’étape du projet complet doit afficher deux ressources créées sans erreur, et une vérification manuelle dans le portail doit montrer les deux stratégies en état “Activé”. Si le plan Terraform affiche des changements inattendus à chaque exécution alors qu’aucune modification n’a été faite dans le portail, vérifiez qu’aucun administrateur ne modifie encore manuellement les stratégies en parallèle du pipeline.

Foire aux questions

Faut-il une licence P2 pour suivre ce tutoriel dans son intégralité ?
Oui pour les étapes de PIM et d’Entra ID Protection. Les étapes liées au MFA et à l’accès conditionnel de base fonctionnent avec une licence P1.

Azure AD et Microsoft Entra ID sont-ils le même produit ?
Oui, Entra ID est le nom actuel du service autrefois commercialisé sous le nom Azure Active Directory. Certaines pages de documentation technique conservent encore l’ancienne terminologie par compatibilité, mais la marque commerciale officielle est désormais Entra ID.

Les passkeys remplacent-elles complètement le MFA classique ?
Elles constituent une méthode de MFA résistante au phishing, mais ne dispensent pas de maintenir une stratégie d’accès conditionnel qui les exige. Depuis le 1er septembre 2026, elles sont devenues l’option par défaut pour les comptes qui utilisaient le SMS ou l’appel vocal.

Combien de temps faut-il pour voir l’effet d’une nouvelle stratégie sur le Secure Score ?
Généralement sous 48 heures, le temps que Microsoft recalcule le score après détection des changements de configuration.

Peut-on appliquer ce tutoriel à un tenant avec plusieurs milliers d’utilisateurs ?
Oui, mais privilégiez un déploiement progressif par groupes pilotes avant une activation globale, et utilisez systématiquement le mode “Rapport seulement” pour mesurer l’impact réel avant toute généralisation.

PIM for Groups fonctionne-t-il avec des applications SaaS tierces ?
Oui, dès lors que l’application tierce utilise un groupe Entra pour gérer ses accès, PIM for Groups peut rendre cette appartenance temporaire et soumise à activation.

Que faire si une stratégie bloque accidentellement tous les administrateurs ?
Utilisez le compte de secours (break glass) exclu de toutes les stratégies pour vous reconnecter, puis corrigez la portée de la stratégie fautive avant de la réactiver.

L’accès conditionnel pour les agents IA concerne-t-il toutes les organisations ?
Pour l’instant, cette fonctionnalité cible les organisations qui déploient des agents autonomes connectés au tenant via Microsoft 365 E7 ou Microsoft Agent 365. Elle devrait néanmoins se généraliser à mesure que les agents IA s’intègrent aux environnements de production.