La préparation du tenant cible Microsoft 365 ne se limite pas à un inventaire technique : elle implique de gouverner les comptes Microsoft Entra ID, de cartographier les dépendances entre services et de définir une architecture sécurisée avant toute bascule. Sans cette phase amont, les risques de rupture de service ou de configuration orpheline se multiplient.
Partenaire Microsoft depuis 2001, Eliadis accompagne des projets de migration inter-tenant Microsoft 365 complexes, de la sécurisation des accès au tenant cible jusqu’à la gouvernance post-migration. Cet article détaille les étapes structurantes pour aborder cette préparation avec méthode et sérénité.
À retenir :
- Préparation des identités et sécurité essentielle avant une migration Microsoft 365 pour éviter les problèmes d’accès et de configuration
- Cartographie des identités et choix du modèle d’identité (cloud natif, hybride, fédéré) déterminent la complexité de la migration
- Nettoyage de l’annuaire Entra ID source indispensable pour éviter la propagation d’anomalies dans le tenant cible
- Sécurisation via MFA et accès conditionnels doit être mise en place avant la migration pour protéger les données
- Validation des relations d’organisation et routage inter-tenants cruciaux pour garantir la continuité du service durant la migration
- Communication claire et plan de retour arrière sont vitaux pour gérer le changement et minimiser les interruptions après la migration
Cartographier et structurer les identités avant la migration
Avant toute migration tenant to tenant, la cartographie précise des identités constitue la première action technique à mener. Sans cette étape, les conflits de routage, les doublons d’objets et les ruptures d’accès se multiplient dès les premières synchronisations.
Analyser les domaines UPN et suffixes pour éviter les conflits
Chaque utilisateur est identifié dans Microsoft Entra ID par un User Principal Name (UPN) dont le suffixe correspond à un domaine vérifié dans le tenant. Lors d’une migration cross-tenant, deux tenants peuvent partager des suffixes similaires ou des conventions de nommage identiques, ce qui génère des collisions d’attributs. Il convient donc d’inventorier l’ensemble des suffixes UPN présents dans le tenant source, de vérifier leur statut dans le tenant cible et d’arbitrer les renommages nécessaires avant toute importation. Cette analyse conditionne directement la qualité de la conception de l’annuaire Entra ID cible.
Choisir le modèle d’identité adapté au scénario
La préparation des identités Microsoft 365 impose de trancher entre trois modèles : identités cloud natives, modèle d’identité hybride Microsoft 365 avec configuration Entra Connect, ou identités fédérées via un fournisseur tiers. Dans un contexte de fusion ou de scission d’entreprise, le modèle hybride est souvent hérité du tenant source. Il faut alors évaluer si la configuration Entra Connect existante peut être adaptée au tenant cible ou si une nouvelle infrastructure de synchronisation doit être déployée. Ce choix détermine la complexité des phases de coexistence et les risques liés à la gestion des mots de passe et des attributs synchronisés.
Préparer et nettoyer l’annuaire Entra ID source
Un annuaire non nettoyé transporte ses anomalies dans le tenant cible : comptes orphelins, attributs incohérents, groupes sans membres actifs ou objets contacts en doublon. La phase de nettoyage inclut la désactivation des comptes inactifs, la vérification des attributs de messagerie (proxyAddresses, mail, mailNickname) et la suppression des objets non migrables. Ce travail préalable allège considérablement les opérations de réconciliation post-migration et réduit les incidents liés à l’attribution de licences.
Mettre en place un mappage un-à-un des identités avec CTIM
Selon Microsoft, le CTIM (Cross-Tenant Identity Mapping) fournit une méthode sécurisée pour établir des relations d’objet un-à-un entre tenants, ce qui garantit la préservation des attributs et des appartenances lors du transfert (Source : Microsoft — 2024-04-13). Ce mappage doit être documenté dans une matrice de correspondance liant chaque objet source à son équivalent cible, en incluant les comptes de service, les boîtes aux lettres partagées et les groupes de distribution. La qualité de cette matrice conditionne directement la réussite des étapes de migration de messagerie et de partage de contenu.
| Modèle d’identité | Infrastructure requise | Complexité de migration | Cas d’usage typique |
|---|---|---|---|
| Cloud natif | Aucune (Entra ID seul) | Faible | PME sans Active Directory on-premises |
| Hybride (Entra Connect) | Active Directory + Microsoft Entra Connect | Élevée | Grandes entreprises, fusion/acquisition |
| Fédéré (ADFS / IdP tiers) | Serveur de fédération + Entra ID | Très élevée | Environnements réglementés, SSO complexe |
Une fois les identités cartographiées et le modèle retenu, l’étape suivante consiste à sécuriser les accès et les permissions avant le basculement effectif des données.
Configurer la sécurité et les accès avant la bascule
Avant toute migration tenant to tenant, la sécurisation des identités Microsoft 365 doit être opérationnelle côté source comme côté cible. Négliger cette étape expose l’organisation à des accès non autorisés pendant la fenêtre de transition, période particulièrement sensible.
Définir la politique MFA et les exclusions de comptes de service
La configuration MFA et accès conditionnel constitue le socle de toute stratégie de hardening sécurité tenant Microsoft 365. Avant la bascule, chaque compte utilisateur doit être soumis à l’authentification multifacteur, sans exception pour les comptes standards. Les comptes de service méritent une attention particulière : ils ne supportent pas toujours le MFA interactif et doivent faire l’objet d’exclusions documentées, compensées par des restrictions d’IP strictes et des secrets d’application rotatifs. Cette cartographie préalable évite des blocages en production lors de la migration des données.
Mettre en place les accès conditionnels en mode test
Les stratégies d’accès conditionnel ne doivent jamais être activées en production sans phase de validation. Microsoft Entra ID Protection permet de déployer ces politiques en mode rapport uniquement, ce qui permet d’observer les impacts sans bloquer les utilisateurs. Une fois les journaux analysés et les faux positifs éliminés, les règles peuvent être basculées en mode actif progressivement, par population ou par application. Cette approche par incrément réduit considérablement le risque de rupture de service pendant la phase de migration.
Séparation des rôles administratifs avec PIM et comptes d’urgence
La préparation de la sécurité tenant Microsoft 365 implique de revoir la gouvernance des comptes à privilèges. Le recours au PIM (Privileged Identity Management) permet d’activer les rôles administrateurs à la demande, pour une durée limitée, avec journalisation complète. Cette approche s’inscrit pleinement dans le modèle sécurité Zero Trust Microsoft 365. Par ailleurs, au moins deux comptes d’urgence (break-glass) doivent être configurés hors PIM, avec des identifiants stockés de manière sécurisée, pour permettre un accès de dernier recours en cas de défaillance d’authentification. Selon Microsoft, il est recommandé d’utiliser des rôles disposant du moins d’autorisations pour améliorer la sécurité lors de la migration (Source : Microsoft — 2025-04-19).
Mesurer la posture de sécurité via Microsoft Secure Score
Le Microsoft Secure Score offre une vue consolidée de la posture de sécurité du tenant avant migration. En analysant les recommandations issues de Microsoft 365 Defender, les équipes peuvent prioriser les actions correctives à fort impact : activation du MFA, réduction des rôles globaux, restriction des accès legacy. Un tableau de suivi structuré facilite les arbitrages entre équipes IT et RSSI :
| Axe de sécurité | Recommandation Zero Trust | Priorité avant migration |
|---|---|---|
| MFA | Activer pour 100 % des comptes | Critique |
| Accès conditionnel | Mode rapport puis mode actif | Haute |
| PIM | Activer pour tous les rôles admins | Haute |
| Comptes d’urgence | Exclure du MFA, surveiller en alerte | Obligatoire |
| Secure Score | Score cible défini avant bascule | Moyenne |
Pour aller plus loin sur les étapes structurantes d’une migration réussie, la checklist d’une migration Microsoft 365 réussie propose un cadre opérationnel complet. La sécurité ainsi consolidée, il devient possible d’aborder sereinement la synchronisation et la coexistence des annuaires entre les deux tenants.
Garantir la coexistence et la communication pendant la transition
La coexistence inter-tenants Exchange Online repose sur une configuration explicite des relations d’organisation et du partage Free/Busy. Sans ce paramétrage, les utilisateurs des deux tenants ne peuvent ni consulter les disponibilités de leurs collègues ni router correctement les messages pendant la période de transition.
Configurer la relation d’organisation Exchange Online pour le partage Free/Busy
Le paramétrage de la coexistence Free/Busy entre tenants s’effectue via la fonctionnalité Organization Relationship d’Exchange Online. Cette relation doit être créée dans les deux tenants (source et cible) afin d’être bidirectionnelle. Elle définit le niveau de partage autorisé : disponibilité simple (occupé/libre), détails des créneaux ou accès complet au calendrier. Il est recommandé de commencer par un niveau de partage minimal, puis d’élargir les droits après validation des accès. La vérification des certificats OAuth et des endpoints d’autodiscover est indispensable pour éviter les échecs silencieux de synchronisation.
Assurer la reconnaissance mutuelle des domaines et le routage inter-tenants
Pour que les messages circulent correctement entre les deux tenants pendant la coexistence, chaque domaine SMTP doit être reconnu par les deux environnements. Les domaines partagés Microsoft 365 posent une contrainte structurelle : un domaine ne peut être vérifié simultanément dans deux tenants. La stratégie habituelle consiste à utiliser des sous-domaines de routage transitoires (par exemple, utilisateur@contoso.onmicrosoft.com) ou à créer des connecteurs de transport dédiés. Les règles de flux de messagerie (mail flow rules) permettent de réécrire les adresses de destination et d’orienter les messages vers le bon tenant selon la phase de migration.
Préparer les comptes, groupes et licences dans le tenant cible
La préparation des comptes et droits d’accès Microsoft 365 dans le tenant cible doit précéder toute bascule. Les objets utilisateurs (UserPrincipalName, adresses proxy SMTP) doivent être créés en amont et correspondre exactement aux attributs du tenant source pour éviter les conflits d’identité. Les Groupes Microsoft 365 doivent également être recréés avec leurs membres et permissions. Concernant les licences, selon Microsoft, tous les utilisateurs dont les comptes SharePoint migrent doivent se voir attribuer la licence SharePoint appropriée avant la migration (Source : Microsoft — 2025-10-25). Ce principe s’applique par extension à l’ensemble des workloads migrés.
Valider la cohérence entre GAL, adresses SMTP et listes d’adresses globales
| Élément à valider | Tenant source | Tenant cible |
|---|---|---|
| Adresse SMTP principale | Présente et vérifiée | Alias ou sous-domaine transitoire |
| Entrée dans la GAL | Objet actif | Contact mail ou objet synchronisé |
| Free/Busy visible | Via Organization Relationship | Via Organization Relationship |
| Groupes Microsoft 365 | Actifs avec membres | Recréés avant bascule |
La cohérence des listes d’adresses globales (GAL) garantit que les utilisateurs des deux tenants se trouvent mutuellement dans leur annuaire pendant toute la durée de la coexistence. Des outils comme GAL Sync ou la création manuelle de contacts mail permettent d’exposer les objets du tenant source dans la GAL du tenant cible. La vérification des adresses proxy SMTP doit être systématique pour prévenir les rebonds de messagerie. La phase suivante abordera la sécurisation des accès conditionnels et des politiques de conformité à mettre en œuvre conjointement.
Tester, documenter et sécuriser le retour arrière
Avant toute bascule définitive, un plan de validation structuré permet de détecter les écarts de configuration et de limiter les risques d’interruption. Cette phase finale de préparation conditionne directement la réussite opérationnelle de la migration tenant to tenant.
Concevoir un plan de tests et de validation
Le plan de tests doit couvrir quatre axes critiques : la synchronisation des identités, l’authentification multifacteur (MFA), la disponibilité des calendriers (Free/Busy) et le routage des messages. Pour chaque scénario, définissez un résultat attendu, un responsable de test et un critère de succès binaire (pass/fail). Testez notamment la propagation des comptes depuis Microsoft Entra Connect Health vers le tenant cible, en vérifiant que les attributs UPN, les groupes et les licences sont correctement reportés. Validez aussi que les règles de routage mail dans Exchange Online dirigent bien les flux vers les destinataires du nouveau tenant sans créer de boucles ou de rebonds.
Créer un environnement de préproduction
Un environnement de préproduction isolé est indispensable pour valider les configurations de design sécurité et identité pour tenant cible sans impacter les utilisateurs en production. Reproduisez-y les politiques d’accès conditionnel, les configurations MFA et les paramètres de conformité définis dans Microsoft Purview. Cet environnement permet aussi de simuler les flux de synchronisation et d’identifier d’éventuels conflits d’attributs avant la migration réelle. Selon Microsoft, la préparation des deux locataires pour le mappage d’identités requiert d’exécuter les instructions depuis le locataire source et le locataire cible de manière coordonnée (Source : Microsoft — 2025-12-16).
Documenter le plan de retour arrière et les procédures d’urgence
La documentation du plan de bascule et de retour arrière constitue un livrable non négociable dans une démarche de documentation et gouvernance sécurité. Formalisez les étapes de rollback dans Azure Portal : remise en service des connecteurs de synchronisation source, restauration des règles DNS, et réactivation des politiques de sécurité antérieures. Chaque procédure d’urgence doit préciser le seuil de déclenchement, le délai maximal d’exécution et les contacts responsables. Ce niveau de rigueur est conforme aux pratiques que recommande Eliadis dans l’accompagnement de migrations Microsoft 365 complexes.
| Axe testé | Outil principal | Critère de succès |
|---|---|---|
| Synchronisation identités | Microsoft Entra Connect Health | Attributs UPN et groupes répliqués sans erreur |
| Authentification MFA | Azure Portal | Accès conditionnel appliqué sur comptes pilotes |
| Free/Busy calendriers | Exchange Online | Disponibilités visibles entre tenants |
| Routage mail | Exchange Online / DNS | Aucun rebond ou boucle détecté |
| Conformité données | Microsoft Purview | Politiques DLP et rétention actives sur tenant cible |
Préparer la communication et la gestion du changement
La mise en conformité sécurité avant migration ne se limite pas aux aspects techniques : la gestion du changement côté utilisateurs est tout aussi déterminante. Élaborez un plan de communication qui explique les impacts concrets (nouvelle adresse UPN, reconnexion aux applications, reconfiguration des clients mail) et les délais associés. Des sessions de formation ciblées, des FAQ et un dispositif de support renforcé réduisent les tickets post-migration et maintiennent la productivité. Pour aller plus loin sur l’organisation globale de cette phase, la checklist d’une migration Microsoft 365 réussie offre un cadre complémentaire utile à intégrer dans votre feuille de route.
Une fois ces quatre piliers validés — tests, préproduction, retour arrière et communication —, votre tenant cible est prêt pour aborder la phase d’exécution de la migration dans des conditions maîtrisées.
Conclusion
Préparer les identités et la sécurité Microsoft 365 avant une migration tenant to tenant conditionne directement la réussite du projet. Une approche structurée en amont est la seule garantie d’une continuité opérationnelle réelle.
La préparation de la gouvernance des identités, l’audit des comptes et droits d’accès Microsoft 365, ainsi que l’activation d’un modèle sécurité Zero Trust Microsoft 365 ne s’improvisent pas. Chaque étape — de la cartographie des identités dans Microsoft Entra ID à la configuration du tenant cible Microsoft 365 — doit être planifiée et validée avant tout transfert de données. D’après Microsoft, la bonne exécution d’une migration tenant to tenant sécurisée repose notamment sur des prérequis techniques précis, comme la préparation de l’environnement, l’installation du module CTIM et l’attribution des autorisations d’application (Source : Microsoft — 2024-04-13).
Face à la complexité de ces projets, un accompagnement expert s’avère décisif. Eliadis, partenaire Microsoft spécialisé depuis 2001, aide les organisations à sécuriser chaque phase de leur migration Microsoft 365, de la gouvernance des accès à la validation du tenant cible. Anticiper, structurer et s’appuyer sur une expertise éprouvée reste la meilleure stratégie pour migrer sans risque.
