Microsoft Entra ID - Guide, licences et différences avec AD

Microsoft Entra ID est la brique d’identité cloud qui relie les comptes, les applications et les appareils dans l’écosystème Microsoft. Quand je travaille sur ce type d’architecture, je le regarde moins comme un annuaire que comme un point de contrôle: qui accède à quoi, depuis quel contexte, et sous quelles règles.

Ce que Microsoft Entra ID fait vraiment dans l’écosystème Microsoft

Microsoft Entra ID est la continuité d’Azure AD, avec un positionnement plus large sur l’identité, l’accès et la sécurité des applications. Dans un tenant Microsoft, il sert de couche de décision: authentifier l’utilisateur, vérifier le contexte, puis autoriser ou bloquer l’accès selon des règles comme l’authentification multifacteur, l’état de l’appareil ou la localisation.

Concrètement, il centralise le single sign-on pour Microsoft 365, Azure et de nombreuses applications SaaS, gère les comptes invités, automatise une partie du provisionnement et fournit des journaux utiles pour l’audit. C’est ce qui en fait bien plus qu’un simple répertoire d’utilisateurs. C’est la base du contrôle d’accès dans une stratégie Zero Trust, et la comparaison avec Active Directory devient alors indispensable.

Je le vois surtout comme un moteur de confiance: l’utilisateur ne se connecte pas seulement une fois, il passe ensuite une série de vérifications qui dépendent du risque, du terminal et du service demandé. C’est précisément cette logique qui change la manière de concevoir l’accès aux outils Microsoft, mais aussi aux applications tierces.

Pourquoi il ne remplace pas toujours Active Directory

Je vois souvent la même confusion: Entra ID et Active Directory portent tous deux le mot « annuaire », mais ils ne répondent pas au même besoin. Active Directory Domain Services reste une technologie de domaine, pensée pour les postes Windows, les scripts d’administration, les GPO et les protocoles historiques comme Kerberos ou LDAP. Entra ID, lui, est conçu pour l’accès cloud et les applications modernes.

La différence est plus claire avec un tableau simple.

Si vous avez encore des applications qui s’appuient sur LDAP, des serveurs qui attendent Kerberos ou une forte dépendance aux stratégies de groupe, Entra ID ne suffit pas à lui seul. Dans ce cas, je garde Active Directory ou je passe par Microsoft Entra Domain Services pour certains besoins intermédiaires. Une fois cette frontière posée, la vraie question devient celle des licences et du niveau de contrôle attendu.

Ce que couvrent les éditions Free, P1 et P2

Pour beaucoup d’équipes, le bon choix n’est pas de prendre l’offre la plus complète, mais d’acheter juste assez de contrôle pour éviter les bricolages. Microsoft affiche P1 et P2 comme des offres payantes distinctes, avec des tarifs indicatifs à 6 USD et 9 USD par utilisateur et par mois, facturés à l’année sur son site américain. En pratique, la disponibilité exacte et les bundles dépendent du pays et des contrats existants, donc je vérifie toujours ce que l’entreprise possède déjà via Microsoft 365 ou Azure.

Microsoft indique aussi que P1 est inclus dans Microsoft 365 E3 et Business Premium, tandis que P2 est inclus dans Microsoft 365 E5. Au-dessus, Microsoft propose également Entra Suite à 12 USD/utilisateur/mois, mais je ne la considère que si l’organisation veut réunir accès réseau, protection d’identité et gouvernance dans un ensemble plus large. Le point utile ici est simple: P1 est souvent le vrai seuil fonctionnel, et P2 sert quand le risque impose des contrôles plus fins.

Cette grille de lecture change vite la discussion interne, parce qu’elle ramène le sujet à des usages réels plutôt qu’à une fiche produit. C’est exactement ce qui compte quand on passe de la théorie aux cas d’usage.

Les usages concrets qui font la différence au quotidien

La valeur d’Entra ID se voit surtout dans des situations très concrètes. Je résume les plus fréquentes parce que c’est là que les équipes sentent immédiatement la différence entre une simple authentification et une politique d’accès cohérente.

• Travail hybride : un collaborateur se connecte à Microsoft 365 depuis un ordinateur géré par Intune. Conditional Access peut exiger un appareil conforme avant d’ouvrir les données sensibles.
• Partenaires et prestataires : avec les identités externes B2B, on évite de créer des comptes locaux dispersés. L’accès reste traçable et révocable.
• Applications SaaS : SCIM, un standard de provisionnement automatique, permet de créer et de retirer les comptes dans les applications au rythme des ressources RH ou IT.
• Applications héritées : via des mécanismes comme l’Application Proxy, on peut exposer certaines applications internes sans les rendre directement accessibles sur le réseau.
• Administrateurs et privilèges : RBAC, c’est-à-dire l’attribution des droits par rôle, limite les privilèges permanents et rend l’administration plus lisible.

Dans ces cas-là, Entra ID ne sert pas seulement à « ouvrir une session ». Il sert à décider si la session est acceptable, et dans quelles conditions. Cette logique est très puissante, mais elle devient vite source de problèmes quand on la met en place trop vite ou trop largement.

Les erreurs que je vois le plus souvent lors d’un déploiement

Les erreurs les plus coûteuses ne viennent pas du produit lui-même, mais de la manière dont il est introduit. Le piège le plus courant consiste à configurer des règles trop strictes sans compte d’urgence, puis à se retrouver bloqué au premier incident. Le second consiste à laisser trop de privilèges permanents alors qu’un modèle d’accès juste-à-temps réduit nettement la surface de risque.

• Pas de compte break-glass : sans compte d’urgence hors des règles conditionnelles, une erreur de politique peut couper l’accès à l’administration.
• Conditional Access déployé d’un coup : mieux vaut tester sur un petit groupe que de bloquer toute l’entreprise le premier jour.
• Trop d’administrateurs globaux : la facilité opérationnelle se paie ensuite en risque et en complexité d’audit.
• Postes non conformes ignorés : si la conformité de l’appareil n’est pas reliée à l’accès, la politique reste théorique.
• Invités sans cycle de vie : les accès partenaires doivent expirer, sinon le tenant se remplit de comptes dormants.
• Licences choisies trop tôt : acheter P2 avant d’avoir posé les fondamentaux revient souvent plus cher que nécessaire.

Le bon réflexe consiste à traiter l’identité comme une couche critique, pas comme un simple réglage d’annuaire. Et c’est précisément ce qui change la manière de préparer le déploiement.

Comment préparer un déploiement ou une migration sans casser l’existant

Je commence toujours par une phase d’inventaire, parce qu’elle évite beaucoup de mauvaises surprises. Il faut savoir qui se connecte, à quelles applications, depuis quels appareils, avec quelles dépendances héritées. Ensuite seulement on peut choisir entre un scénario cloud natif, un modèle hybride synchronisé ou une coexistence plus longue avec Active Directory.

1. Cartographier les identités : utilisateurs internes, comptes techniques, administrateurs, invités et prestataires doivent être séparés dès le départ.
2. Identifier les applications critiques : je note celles qui acceptent SAML ou OpenID Connect, et celles qui dépendent encore de LDAP, Kerberos ou de mécanismes plus anciens.
3. Créer une base de sécurité : un compte d’urgence, une politique de mot de passe cohérente et un minimum de journalisation doivent exister avant le reste.
4. Piloter Conditional Access : je teste d’abord sur un groupe restreint, avec des exclusions contrôlées, avant d’élargir la règle.
5. Brancher la conformité des appareils : avec Intune ou un équivalent MDM, l’identité peut se combiner à l’état de sécurité du terminal.
6. Automatiser le cycle de vie : provisioning, départs, invités et revues d’accès doivent être traités comme des processus, pas comme des tâches ponctuelles.

Cette méthode est moins spectaculaire qu’un « grand basculement », mais elle marche mieux. Elle laisse le temps de valider les accès, de corriger les exceptions et de garder les équipes à l’aise pendant la transition. Une fois ce socle en place, il reste à choisir le niveau de maturité qui correspond vraiment au contexte.

Le niveau de maturité qui colle le mieux à votre contexte

Si votre environnement est majoritairement Microsoft 365, Entra ID devient très vite la colonne vertébrale de l’accès. Si vous avez encore beaucoup d’applications héritées, il doit cohabiter avec Active Directory, pas le remplacer brutalement. C’est la nuance que j’essaie toujours de faire passer, parce qu’elle évite des décisions trop abstraites.

Dans la plupart des PME et ETI, P1 est le vrai point d’équilibre. Il apporte ce qui change réellement la sécurité et l’exploitation quotidienne: Conditional Access, groupes dynamiques, politiques d’accès plus fines et meilleure maîtrise des sessions. P2 devient pertinent quand le risque, l’audit ou la gouvernance justifient les fonctions d’Identity Protection et d’accès fondé sur le risque.

Et si vous avez déjà des licences Microsoft 365 E3, Business Premium ou E5, je vérifierais toujours ce qui est inclus avant d’acheter quoi que ce soit en plus. En pratique, le bon choix n’est pas de prendre l’outil le plus complet, mais le niveau de contrôle qui correspond à votre réalité opérationnelle. C’est ce cadrage qui fait la différence entre une identité bien gérée et une couche de sécurité devenue inutilement complexe.