Les transformations cloud accélèrent la consolidation des environnements collaboratifs, et la gouvernance des identités dans Microsoft 365 s’impose comme un prérequis structurant. Avant tout transfert entre locataires, les équipes techniques doivent maîtriser le mappage des comptes, la gestion des licences, et la synchronisation via Azure AD Connect ou Microsoft Entra ID. Une architecture de gestion des comptes cloud mal définie expose l’organisation à des conflits d’identités et à des interruptions opérationnelles.
Pour les DSI et architectes techniques, le plan de migration locataire à locataire exige une modélisation rigoureuse dès la phase de cadrage. L’architecture des identités pour migration entre tenants constitue le socle de toute démarche réussie. Eliadis, partenaire Microsoft spécialisé depuis 2001, accompagne ses clients dans la conception et l’exécution de ces scénarios complexes, en s’appuyant sur une expertise éprouvée en infrastructure et migration cloud.
À retenir :
- Préparer l’architecture des identités avant une migration MS 365 est crucial pour la continuité et la sécurité
- Maîtriser les composantes fondamentales de Microsoft Entra ID est clé pour garantir la faisabilité du projet
- Trois modèles d’identité existent : cloud-only, hybride et fédéré, chacun avec des impératifs spécifiques
- Un mappage exact des identités et une synchronisation rigoureuse sont essentiels pour éviter ruptures d’accès
- La gouvernance et la gestion des privilèges doivent être dès le départ pour assurer sécurité et traçabilité
- Anticiper la coexistence des identités et prévoir un plan de retour arrière est vital pour la réussite du projet
Comprendre les fondations d’une architecture d’identités Microsoft 365
Avant toute migration tenant to tenant, il est indispensable de maîtriser les composantes fondamentales d’une identité Microsoft 365 et les contraintes structurelles d’un locataire Entra ID. Le choix du modèle d’identité conditionne directement la faisabilité, la sécurité et la réversibilité de l’ensemble du projet.
Le locataire Microsoft Entra ID : périmètre et contraintes géographiques
Microsoft Entra ID — anciennement Azure AD — constitue la pierre angulaire de toute architecture des identités Microsoft 365. Il s’agit d’un répertoire cloud dédié qui centralise la gestion des utilisateurs, des groupes, des licences et des politiques d’accès conditionnel. Selon Microsoft, un locataire Microsoft Entra ID est un répertoire individuel définissant la zone géographique par défaut pour un tenant (Source : Microsoft — 2025-08-12). Cette zone géographique, fixée lors de la création du tenant, ne peut pas être modifiée ultérieurement, ce qui impose une réflexion préalable rigoureuse, notamment dans les contextes de fusion, d’acquisition ou de restructuration internationale. La conception du schéma d’identités pour migration locataire à locataire doit donc intégrer cette contrainte dès les premières phases de cadrage.
Les trois modèles d’identité disponibles
La conception du modèle d’identité Microsoft 365 s’articule autour de trois approches distinctes, chacune répondant à des contraintes d’infrastructure et de gouvernance spécifiques.
| Modèle | Description | Infrastructure requise | Cas d’usage type |
|---|---|---|---|
| Cloud-only | Les identités sont créées et gérées exclusivement dans Microsoft Entra ID | Aucun Active Directory on-premises | PME sans infrastructure locale, greenfield |
| Hybride | Les identités sont synchronisées depuis un Active Directory local vers Entra ID via Microsoft Entra Connect | Active Directory on-premises + connecteur de synchronisation | Grandes entreprises avec existant AD, migration progressive |
| Fédéré | L’authentification est déléguée à un fournisseur d’identité externe (ex. AD FS) | AD FS ou fournisseur IdP tiers | Exigences de conformité, SSO avec systèmes legacy |
Le modèle d’identité hybride Microsoft Entra ID reste le plus répandu dans les environnements d’entreprise structurés. Il permet de maintenir un annuaire Active Directory on-premises comme source autoritaire tout en projetant les identités dans le cloud, offrant ainsi une coexistence maîtrisée entre les deux environnements.
Pourquoi choisir son modèle avant la migration
La sélection du modèle d’identité en amont d’une migration n’est pas qu’une décision technique : elle engage la sécurité, la gouvernance et la capacité à revenir en arrière en cas d’incident. Un changement de modèle en cours de migration — par exemple, passer d’un modèle fédéré via AD FS à un modèle cloud-only — entraîne une reconfiguration majeure des politiques d’authentification et des règles d’accès conditionnel. La synchronisation Microsoft Entra ID dans un contexte de migration cross-tenant illustre précisément comment la conception du schéma d’attributs utilisateur impacte la cohérence des identités entre le tenant source et le tenant cible. Anticiper ces choix garantit une coexistence stable des comptes, évite les ruptures d’accès et simplifie la phase de décommissionnement du tenant d’origine. La suite de cet article détaille les stratégies concrètes pour orchestrer cette transition de manière contrôlée.
Cartographier et synchroniser les identités entre tenants
La réussite d’une migration tenant to tenant Microsoft 365 repose sur une stratégie de synchronisation d’annuaire rigoureuse et un mappage des identités précis dès la phase de préparation. Sans ce socle, les utilisateurs risquent de perdre l’accès à leurs données et licences lors du basculement.
Microsoft Entra Connect et Cloud Sync : moteurs de la synchronisation
Dans une migration locataire à locataire, la propagation des identités entre l’annuaire source et l’annuaire cible s’appuie sur deux outils complémentaires de Microsoft Entra ID. Microsoft Entra Connect convient aux environnements hybrides où un Active Directory on-premises alimente le tenant, tandis que Microsoft Entra Cloud Sync répond aux architectures entièrement cloud ou multi-forêts. Les deux solutions permettent de répliquer les objets utilisateurs, groupes et contacts vers le tenant de destination, mais leur configuration diffère sensiblement selon la topologie existante. Il est essentiel de choisir l’outil adapté avant d’initier toute synchronisation, car un mauvais paramétrage génère des doublons d’objets ou des conflits d’attributs difficiles à résoudre en cours de migration.
Le fichier de mappage utilisateur, pivot de la cohérence
Le fichier de mapping utilisateur migration locataire constitue l’élément central qui relie chaque identité source à son équivalent dans le tenant cible. Pour les migrations impliquant la Power Platform, Microsoft précise explicitement que ce fichier doit être au format CSV et porter le nom usermapping.csv (Source : Microsoft — 2026-04-06). Au-delà de la Power Platform, ce principe s’applique plus largement : chaque ligne du fichier établit une correspondance univoque entre l’UPN source et l’UPN cible, garantissant que les permissions, flux de travail et appartenances aux groupes sont correctement réattribués après migration.
Logique de mappage des attributs clés
Le mappage des identités entre tenants Microsoft 365 ne se limite pas au simple renommage de l’UPN. Plusieurs attributs doivent être traités avec soin :
| Attribut | Rôle dans la migration | Point de vigilance |
|---|---|---|
| UPN (UserPrincipalName) | Identifiant principal de connexion | Alignement obligatoire avec le domaine cible vérifié |
| Alias / proxyAddresses | Adresses de messagerie secondaires | Éviter les doublons avec des objets existants dans le tenant cible |
| sourceAnchor (ImmutableID) | Ancre d’identité immuable pour la synchronisation | Recalculer si l’outil de synchronisation change |
| DisplayName | Nom affiché dans Teams, Outlook, SharePoint | Cohérence avec la convention de nommage cible |
Le plan d’adressage et re-nommage des UPN doit être documenté avant toute synchronisation. Chaque domaine utilisé côté source doit être vérifié dans le tenant cible, faute de quoi les UPN basculent automatiquement vers le domaine onmicrosoft.com, ce qui perturbe l’expérience utilisateur et complique le re-nommage a posteriori. Pour approfondir la mécanique globale d’une telle opération, la vue d’ensemble de Microsoft 365 Migration Orchestrator fournit un cadre de référence utile sur l’orchestration des flux. La stratégie de mappage ainsi consolidée prépare directement la phase de provisionnement des boîtes aux lettres et des ressources associées dans le tenant cible.
Gouvernance, rôles et sécurité dans la migration des identités
Sécuriser les identités pendant une migration tenant to tenant Microsoft 365 repose sur trois piliers indissociables : la gestion des privilèges, le contrôle d’accès et la traçabilité. Selon Microsoft, le mappage d’identité est obligatoire pour toute migration tenant to tenant, les clients étant responsables de la création et de la configuration des utilisateurs dans le tenant cible (Source : Microsoft — 2025-12-16). Cette responsabilité implique de mettre en place dès le début du projet un cadre de gouvernance robuste, porté par Microsoft Entra ID Governance.
Gestion des rôles avec PIM et RBAC pour limiter les privilèges
La gestion des privilèges dans Entra ID s’appuie sur deux mécanismes complémentaires : le contrôle d’accès basé sur les rôles (RBAC) et Azure AD PIM (Privileged Identity Management). Le RBAC permet de délimiter précisément les périmètres d’action de chaque compte — administrateurs de migration, équipes techniques, auditeurs — en évitant toute élévation de droits non justifiée. PIM vient renforcer cette modélisation des rôles et privilèges dans Microsoft Entra ID en rendant l’activation des droits élevés temporaire, conditionnelle et auditable. Concrètement, un administrateur n’obtient ses droits d’accès au tenant source qu’après approbation explicite et pour une durée limitée, réduisant ainsi la surface d’exposition.
| Mécanisme | Objectif principal | Avantage clé en migration |
|---|---|---|
| RBAC | Délimiter les rôles permanents | Séparation des responsabilités par périmètre |
| Azure AD PIM | Activer les droits élevés à la demande | Réduction du risque lié aux comptes sur-privilégiés |
| Entra ID Governance | Cycle de vie des accès et revues | Révocation automatique post-migration |
Accès conditionnel et authentification multifacteur
L’architecture d’authentification moderne (MFA, accès conditionnel) constitue un levier essentiel pour la sécurisation des identités dans une migration Microsoft 365. Azure AD Conditional Access permet de définir des politiques granulaires : bloquer les connexions depuis des pays non autorisés, exiger le MFA pour tout accès aux ressources du tenant cible pendant la phase de coexistence, ou encore restreindre les appareils non conformes. Ces stratégies doivent être configurées dans les deux tenants dès l’ouverture du projet, puis harmonisées progressivement. Les licences Microsoft 365 E5 offrent l’ensemble des fonctionnalités nécessaires à cette gouvernance des identités dans Microsoft 365, notamment Microsoft Entra ID Protection pour détecter les comportements anormaux en temps réel.
Contrôles de conformité et d’audit pour assurer la traçabilité
Maintenir la traçabilité tout au long de la migration est une exigence à la fois technique et réglementaire. Les journaux d’audit d’Entra ID doivent être centralisés — idéalement vers Microsoft Sentinel ou un SIEM tiers — pour conserver une visibilité complète sur les créations de comptes, les attributions de rôles et les connexions réussies ou échouées. Des revues d’accès périodiques, pilotées via Entra ID Governance, permettent de valider que les droits octroyés en début de projet sont révoqués dès qu’ils deviennent inutiles. La mise en œuvre de ces contrôles prépare directement la phase de consolidation des données, où l’intégrité des ressources migrées dépendra de la fiabilité des identités provisionnées.
Planifier la coexistence et la continuité du service entre tenants
Pendant une migration tenant to tenant Microsoft 365, une phase de coexistence temporaire est inévitable : deux environnements distincts doivent cohabiter sans rupture de service. Anticiper cette période transitoire est la condition pour préserver la productivité des utilisateurs et sécuriser le plan de retour arrière des identités cloud.
Organiser la coexistence temporaire des identités entre deux tenants
La stratégie de coexistence des identités Microsoft 365 repose sur la capacité à maintenir des comptes actifs simultanément dans le tenant source et dans le tenant cible. Durant cette phase, les objets de messagerie Exchange Online, les sites SharePoint Online et les espaces Teams peuvent exister en parallèle dans les deux environnements. Il est indispensable de définir précisément quels utilisateurs ont basculé, lesquels restent en source, et comment les redirections de flux garantissent la continuité des échanges. Un plan de coexistence des identités entre deux tenants Microsoft 365 doit cartographier ces états intermédiaires et prévoir des règles de routage explicites pour éviter les conflits d’adresses SMTP ou les doublons d’UPN. Le Microsoft 365 Migration Orchestrator facilite la synchronisation de ces états en exposant le statut de chaque lot migré et en orchestrant les basculements de manière contrôlée.
Gérer le cycle de vie des comptes et des licences durant la transition
La gestion du cycle de vie des comptes dans le tenant cible est un levier critique souvent sous-estimé. Chaque compte provisionné dans le tenant cible doit être associé à une licence active avant le début effectif de la migration de ses données. Selon Microsoft, les licences Microsoft 365 E3/E5 ou équivalentes sont requises à la fois côté source et côté cible pour réaliser une migration tenant to tenant (Source : Microsoft — 2025-12-16). Cette contrainte implique de planifier un pic de consommation de licences Microsoft 365 E3/E5 pour migration, correspondant au chevauchement entre les deux tenants. Un tableau de suivi partagé entre les équipes IT et RH permet d’aligner les dates d’activation et de désactivation des comptes avec les vagues de migration.
| Étape de coexistence | Action sur le tenant source | Action sur le tenant cible |
|---|---|---|
| Pré-migration | Maintien des licences actives | Provisioning des comptes et assignation des licences |
| Migration en cours | Lecture seule sur les boîtes Exchange Online | Activation progressive des services Teams et SharePoint Online |
| Post-migration | Désactivation des comptes et libération des licences | Validation des accès et clôture du tenant source |
Anticiper la réversibilité du modèle d’identité et les ajustements post-migration
Un plan de retour arrière des identités cloud doit être formalisé avant le démarrage de chaque vague. La réversibilité consiste à pouvoir réactiver les comptes source, rétablir les flux Exchange Online et restaurer les permissions SharePoint Online dans un délai défini, sans perte de données. Pour être opérationnel, ce plan doit inclure des sauvegardes des attributs d’identité, des snapshots de configuration et des procédures de rollback testées en environnement de pré-production. Les ajustements post-migration — correction des UPN, réassignation de groupes, mise à jour des politiques d’accès conditionnel — doivent être intégrés dans le planning dès la phase de conception.
La maîtrise de cette période transitoire conditionne directement la qualité de la gouvernance des identités dans le tenant cible, thème central du prochain chapitre.
Conclusion
Concevoir l’architecture des identités pour une migration tenant to tenant Microsoft 365 exige une planification rigoureuse qui ne laisse aucune étape au hasard. La réussite du projet repose sur quatre piliers interdépendants : un mappage précis des comptes, une synchronisation maîtrisée via Microsoft Entra ID, une gouvernance des identités Microsoft appliquée dès le départ, et une gestion cohérente des licences tout au long du cycle de vie des utilisateurs.
Cette rigueur n’est pas qu’opérationnelle : elle conditionne directement la conformité réglementaire et la traçabilité des accès. Il est important de retenir que, selon Microsoft, l’orchestrateur de migration Microsoft 365 déplace le contenu, non les identités — celles-ci doivent être créées manuellement dans le tenant cible (Source : Microsoft — 2025-12-16). Cette contrainte technique renforce l’importance d’une planification des identités pour migration anticipée et structurée.
Au-delà du projet immédiat, la démarche ouvre vers une stratégie globale d’identité multi-tenant pensée pour durer. L’urbanisation des identités dans Microsoft 365 devient alors un levier de gouvernance pérenne. Les équipes d’Eliadis accompagnent leurs clients dans cette transformation pour bâtir un design de l’infrastructure d’identités Microsoft 365 aligné avec les enjeux métiers et sécuritaires à long terme.
