La bascule Entra Cloud First : le risque a déjà déménagé, la sécurité pas encore

Vincent Convert, responsable commercial senior, CoreView partage son analyse du sujet.

Vingt ans de doctrine de sécurité se sont construits autour de la protection de l’Active Directory, considéré comme « les clés du royaume ». Mais l’autorité sur les identités, les privilèges qui en découlent, et donc le risque réel, basculent aujourd’hui vers Entra ID à un rythme que les budgets, les équipes et la gouvernance des organisations françaises n’ont pas encore suivi.

Un calendrier Microsoft, une bascule silencieuse

Depuis juillet 2026, Microsoft notifie progressivement ses clients, via le Message Center de Microsoft 365 et Entra Connect Health, du remplacement programmé d’Entra Connect Sync par Entra Cloud Sync comme méthode principale de synchronisation entre l’Active Directory local et Entra ID. Derrière cette annonce technique se cache un changement de doctrine bien plus profond, que Microsoft documente désormais noir sur blanc dans ses guides destinés aux architectes IT : la trajectoire officielle va de l’environnement hybride vers un état « cloud-first », puis vers un état qualifié d’« AD-minimized », où l’Active Directory local ne gère plus qu’un périmètre résiduel d’applications qui ne peuvent techniquement pas s’en passer.

Le vocabulaire choisi par Microsoft pour justifier ce virage ne laisse guère de place au doute sur l’enjeu de sécurité : dans sa documentation officielle, l’éditeur rappelle que l’Active Directory a longtemps été considéré comme « les clés du royaume », ce qui en fait une cible de choix pour un attaquant. Réduire la dépendance à l’AD, en transférant l’authentification et la gestion des identités vers Entra ID, permet en théorie de bénéficier nativement de l’accès conditionnel, de l’authentification sans mot de passe et d’une gouvernance des identités plus fine. Sur le papier, c’est un progrès de sécurité. Dans les faits, c’est un changement d’autorité qui déplace le centre de gravité du risque plus vite que les organisations ne redéploient leurs efforts de protection.

Car la question qui se pose n’est pas de savoir si ce virage est justifié. Il l’est. Elle est de savoir si les équipes de sécurité, les budgets et les priorités de gouvernance ont déjà suivi ce déplacement, ou s’ils continuent, par habitude, à concentrer l’essentiel de leur vigilance sur un système qui cesse progressivement d’être la source de vérité.

Vincent Convert, responsable commercial senior, CoreView

Vingt ans d’efforts de sécurité, un centre de gravité qui a basculé

Pendant deux décennies, la doctrine de sécurité des grandes organisations s’est construite autour d’un principe simple : protéger l’Active Directory, parce que c’est là que se trouvent les comptes à privilèges, les contrôleurs de domaine, et le chemin le plus direct vers une compromission totale du système d’information. Cette doctrine a produit des pratiques solides et éprouvées : modèle de tiering (Tier0, Tier1, Tier2) pour cloisonner les comptes d’administration, durcissement systématique des contrôleurs de domaine, surveillance des mouvements latéraux via Kerberos, gestion des accès à privilèges (PAM) calée sur les groupes AD sensibles. Des années d’investissement, de formation et de maturité opérationnelle sont concentrées sur cette cible.

Le problème n’est pas que cette doctrine soit fausse. C’est qu’elle devient partielle. À mesure que la source de vérité des identités glisse vers Entra ID, une nouvelle géographie du privilège se dessine, largement sous les radars des dispositifs hérités de l’ère AD. Les rôles d’administrateur Entra, les applications enregistrées avec des permissions Microsoft Graph étendues, les principaux de service, les accès délégués aux API : ce sont ces objets-là qui, de plus en plus, ouvrent les portes d’un tenant Microsoft 365. Or ils échappent structurellement aux outils et aux réflexes construits pour surveiller un contrôleur de domaine.

Le déséquilibre est particulièrement net dans les organisations qui ont, au fil des années, construit une expertise de sécurité AD réelle et reconnue en interne, mais n’ont jamais transposé cette même exigence sur le tenant Entra. Prenons le cas d’une ETI industrielle française d’environ 5 000 collaborateurs, dotée d’un centre opérationnel de sécurité qui surveille en continu ses contrôleurs de domaine, applique un modèle de tiering strict, et déclenche une alerte au moindre comportement suspect sur un compte d’administration AD. Cette même organisation, lorsqu’on l’interroge sur le nombre exact de comptes disposant d’un rôle d’administrateur global ou d’administrateur d’applications dans son tenant Entra, ou sur le périmètre réel des permissions Graph accordées à ses applications d’entreprise, peine à répondre avec la même précision. Le SOC existe, la doctrine existe, mais elle ne couvre qu’une moitié du royaume.

Cette asymétrie se lit aussi dans la nature même des techniques d’attaque que chaque système redoute. Le vocabulaire de la sécurité AD s’est construit autour de scénarios précis, popularisés au fil des années par les retours d’expérience post-incident : extraction des empreintes de mots de passe des comptes de service via une attaque de type Kerberoasting, réplication frauduleuse de la base de comptes par un mécanisme DCSync, falsification d’un ticket Kerberos pour se maintenir indéfiniment dans le système. Ces scénarios sont connus, documentés, et les équipes de sécurité expérimentées savent, en théorie, s’en prémunir. Côté Entra ID, la nature du risque est différente et beaucoup moins bien intégrée dans les réflexes existants : un octroi de consentement excessif à une application tierce lors d’une simple connexion, une application enregistrée dont les permissions Microsoft Graph n’ont jamais été revues depuis sa création, un compte invité externe accumulé lors d’un projet ponctuel et jamais désactivé depuis. Ce ne sont pas des scénarios moins graves. Ce sont des scénarios pour lesquels la plupart des organisations n’ont tout simplement pas encore développé le même niveau de vigilance opérationnelle que celui acquis, avec le temps, sur l’Active Directory.

Cette asymétrie n’est pas propre à la France, mais elle y prend un relief particulier au moment où l’Agence nationale de la sécurité des systèmes d’information (ANSSI) publie son Panorama de la cybermenace 2025 : 3 586 événements de sécurité portés à sa connaissance sur l’année, en recul de 18 % par rapport à 2024, dont 2 209 signalements et 1 366 incidents confirmés – un volume d’incidents quasi stable par rapport aux 1 361 recensés en 2024, malgré le recul du volume brut d’événements. L’agence y voit le signe d’une menace qui se banalise et devient plus difficile à détecter, plutôt qu’un signal d’accalmie. Autre enseignement du panorama : les incidents d’exfiltration de données portés à la connaissance de l’ANSSI ont bondi de 51 % en un an, et l’agence documente des cas concrets où un attaquant compromet d’abord un prestataire ou un fournisseur, avant d’exploiter les interconnexions pour exfiltrer les données de ses clients et se latéraliser vers d’autres organisations. Ce sont précisément les scénarios que la gouvernance des identités Entra ID est censée neutraliser en priorité – à condition que l’attention et les moyens lui soient réellement consacrés, et non simplement hérités d’une doctrine pensée pour un autre système.

Ce que le transfert d’autorité change pour un comité exécutif

Le vocabulaire technique employé par Microsoft – « Source of Authority », « transfert d’autorité des utilisateurs et des groupes » – peut sembler éloigné des préoccupations d’un comité exécutif. Il ne l’est pas. Ce que ce transfert signifie concrètement, c’est que la question « qui décide de qui a accès à quoi » change de système de référence. Tant que l’AD reste la source d’autorité, c’est la gouvernance historique – souvent bien rodée, avec ses processus de création de comptes, ses groupes de sécurité documentés, ses revues périodiques – qui prévaut. Une fois l’autorité transférée vers Entra ID, c’est un nouveau système de gouvernance, avec ses propres outils (Entitlement Management, Access Reviews, Privileged Identity Management, Lifecycle Workflows), qui doit prendre le relais. Le risque n’est pas la migration en soi. Il est dans l’intervalle : la période où deux systèmes coexistent, où les repères organisationnels habituels ne s’appliquent plus intégralement au nouveau, et où personne n’a explicitement désigné qui est responsable de combler l’écart.

Trois risques concrets méritent l’attention d’un DSI, d’un RSSI ou d’un DAF au moment d’aborder ce sujet. Le premier est celui d’une double exposition pendant la période de transition : tant que la bascule n’est pas achevée, l’organisation doit sécuriser simultanément deux surfaces – l’AD historique et le tenant Entra en pleine montée en puissance – sans que les moyens humains ou budgétaires n’aient nécessairement doublé pour autant. Le deuxième est celui de la reproduction des mêmes travers dans un nouvel environnement : les comptes orphelins, les groupes de sécurité trop larges, les comptes de service non documentés qui s’étaient accumulés dans l’AD au fil des années risquent fort d’être recréés à l’identique dans Entra ID, si la migration se limite à une opération technique sans remise à plat de la gouvernance. Le troisième, plus structurel, touche à la conformité : les référentiels réglementaires qui montent en puissance en France et en Europe, NIS2 en tête, avec DORA pour le secteur financier, exigent une gouvernance des accès démontrable et documentée. Un changement de source d’autorité des identités qui ne s’accompagne pas de contrôles équivalents à ceux qui existaient auparavant crée, de fait, un trou dans cette démonstration – au moment même où les organismes de contrôle renforcent leurs exigences.

Les questions qu’un dirigeant devrait poser à ses équipes ne relèvent pas de l’expertise technique pointue. Où sont recensés, aujourd’hui, l’ensemble des comptes disposant d’un rôle à privilèges dans notre tenant Entra ID ? Le Privileged Identity Management est-il activé, avec des rôles attribués de façon temporaire et justifiée plutôt que de façon permanente ? Les revues d’accès sont-elles réellement effectuées, ou existent-elles seulement sur le papier ? Le niveau d’exigence qu’on appliquait historiquement aux contrôleurs de domaine – authentification forte, moindre privilège, traçabilité – est-il aujourd’hui répliqué sur le tenant Entra, notamment via le blocage des méthodes d’authentification héritées et l’imposition d’une authentification multifacteur résistante au hameçonnage ? Si ces questions restent sans réponse claire et documentée, c’est le signe que l’attention de l’organisation n’a pas encore suivi le déplacement de l’autorité.

Cartographier avant de basculer, gouverner en migrant

La bonne nouvelle est que Microsoft, en documentant très précisément la méthode de transition recommandée, fournit lui-même le point de départ d’une approche disciplinée. Le principe directeur, martelé dans la documentation destinée aux architectes IT, tient en une phrase : commencer toujours par un inventaire applicatif complet avant d’engager le moindre transfert d’autorité. Concrètement, cela signifie recenser l’ensemble des applications qui dépendent aujourd’hui de l’Active Directory pour l’authentification, identifier pour chacune le protocole utilisé – Kerberos et NTLM pour les applications d’entreprise classiques, LDAP pour les applications qui interrogent directement l’annuaire, SAML ou OIDC pour celles qui utilisent déjà des protocoles modernes – et déterminer, application par application, la meilleure trajectoire de modernisation.

Cette cartographie n’est pas un exercice informatique isolé : c’est un exercice de gouvernance à part entière, qui devrait être piloté conjointement par les équipes infrastructure, sécurité et conformité, et non délégué au seul chantier technique de migration. Les organisations qui traitent le transfert d’autorité comme un simple projet IAM, sans y associer une remise à plat de la gouvernance des accès, prennent le risque de migrer leur dette technique et leur dette de sécurité en même temps que leurs identités.

Sur le plan de la méthode, Microsoft recommande explicitement d’éviter toute bascule en une seule fois. La transition doit se faire par vagues : les groupes de sécurité avant les utilisateurs, pour permettre de tester les contrôles d’accès applicatifs sans perturber les comptes individuels ; les applications déjà compatibles avec l’authentification moderne avant les applications historiques dépendant de Kerberos ou de LDAP, pour lesquelles Microsoft propose des solutions de transition – Microsoft Entra Domain Services pour maintenir un point d’ancrage LDAP dans le cloud, Application Proxy avec délégation Kerberos contrainte pour les applications web internes, authentification sans mot de passe combinée à la confiance Kerberos dans le cloud pour les postes de travail. Un groupe hospitalier multi-sites, confronté à un parc applicatif hétérogène accumulé au fil des rachats et des extensions successives, a par exemple structuré sa propre trajectoire en commençant par migrer la gouvernance de ses groupes de sécurité, puis en traitant ses applications par catégories homogènes – d’abord celles qui supportaient déjà l’authentification moderne, puis les applications métier critiques nécessitant une solution de transition, en réservant en dernier lieu les cas les plus complexes, ceux dont la dépendance à l’annuaire local ne peut techniquement pas être levée à court terme.

Ce séquencement méthodique ne dispense pas de la question la plus structurante : celle de la répartition des moyens de sécurité. Une partie du budget et des compétences historiquement fléchés vers la protection de l’Active Directory – durcissement des contrôleurs de domaine, gestion des accès à privilèges, surveillance des mouvements latéraux – doit désormais couvrir des enjeux équivalents côté Entra ID : gouvernance des rôles à privilèges via le Privileged Identity Management, alignement continu des configurations du tenant sur des référentiels reconnus comme le CIS Microsoft 365 Foundations Benchmark, détection systématique des écarts de configuration par rapport à une base de référence validée.

Un point mérite une vigilance spécifique dans cette redistribution des moyens : la gouvernance des identités non humaines. Chaque application enregistrée, chaque principal de service, chaque automatisation connectée au tenant dispose de permissions qui lui sont propres, souvent accordées au moment de sa mise en place et rarement revues par la suite. Ces identités techniques se comptent aujourd’hui, dans la plupart des organisations de taille intermédiaire, en centaines voire en milliers d’objets – un ordre de grandeur qui dépasse fréquemment celui des comptes humains à privilèges, sans bénéficier pour autant du même niveau de surveillance. Elles constituent, de fait, l’équivalent moderne des comptes de service AD non documentés qui faisaient déjà, hier, le désespoir des audits de sécurité – à une échelle et avec une facilité de création sans commune mesure, et leur gouvernance reste, dans la plupart des organisations, la grande absente des projets de migration.

Éviter la fausse bonne idée est ici essentiel. La tentation, pour accélérer un projet de migration déjà complexe, est de considérer que la sécurité suivra naturellement une fois la bascule technique achevée. C’est l’inverse de ce que montre l’expérience des organisations qui ont déjà engagé cette trajectoire : la gouvernance et la sécurité doivent être pensées en amont de chaque vague de migration, pas en régularisation après coup. Un compte ou un groupe transféré sans revue préalable de ses droits réels emporte avec lui, dans le nouvel environnement, tous les excès accumulés dans l’ancien.

Le risque n’attend pas la fin du projet de migration

Pour la grande majorité des organisations françaises, l’échéance d’un tenant totalement « AD-minimized » restera un horizon de plusieurs années. Les dépendances applicatives héritées, les contraintes métier, la complexité des systèmes d’information construits par strates successives imposent une coexistence prolongée entre Active Directory et Entra ID. Ce n’est pas un problème en soi : Microsoft lui-même conçoit sa trajectoire comme progressive, et prévoit des solutions de transition durables pour les cas qui ne peuvent pas être modernisés à court terme.

Ce qui distingue déjà les organisations les plus matures n’est pas la vitesse à laquelle elles achèvent techniquement leur migration, mais la rapidité avec laquelle elles ont réattribué leur vigilance de sécurité au nouveau centre de gravité du risque. Ces organisations traitent aujourd’hui leur tenant Entra ID avec le même niveau d’exigence que celui qu’elles appliquaient hier à leurs contrôleurs de domaine – non pas parce que la migration technique est terminée, mais parce qu’elles ont compris que le risque, lui, ne patiente pas la fin du projet.

Le message à retenir pour les comités exécutifs est simple à formuler, plus exigeant à mettre en œuvre : la sécurité doit suivre l’autorité réelle sur les identités, pas la familiarité historique des équipes avec tel ou tel système. Le jour où Entra ID devient la source de vérité des identités d’une organisation, c’est ce jour-là – pas au terme du projet de migration – que la vigilance, les budgets et la gouvernance doivent avoir basculé avec elle.