Lorsqu’une entreprise bascule ses utilisateurs d’un tenant source vers un tenant cible, la cohabitation temporaire des tenants Microsoft 365 génère des défis concrets : synchronisation des identités via Microsoft Entra ID, continuité de la messagerie sur Exchange Online, maintien de la collaboration et gestion des licences en double. Sans architecture préparée, cette interopérabilité entre locataires source et cible peut rapidement fragiliser la productivité des équipes. Pour approfondir les fondations techniques, la rubrique dédiée à l’architecture des identités en migration tenant to tenant Microsoft 365 constitue un prérequis utile. Eliadis, partenaire Microsoft spécialisé dans les environnements collaboratifs depuis 2001, accompagne ses clients tout au long de cette coexistence des environnements Microsoft 365 pour sécuriser chaque étape de la transition.
À retenir :
- Coexistence post-migration Microsoft 365 : période cruciale entre deux locataires, essentielle lors de fusions/acquisitions.
- Défis majeurs : synchronisation des identités, continuité de la messagerie Exchange, et gestion de licences.
- Rôle central de Microsoft Entra ID dans l’interopérabilité des identités et la gestion des relations.
- Configuration des relations organisationnelles nécessaire pour les migrations inter-locataires sans interruption.
- Gestion des accès B2B pour maintenir la collaboration Teams et SharePoint entre tenants.
- Importance de la gouvernance et de la conformité pour minimiser les risques lors de la coexistence.
Comprendre la coexistence Microsoft 365 tenant to tenant
La coexistence Microsoft 365 post‑migration tenant to tenant désigne la période transitoire durant laquelle deux locataires distincts opèrent simultanément, en maintenant la continuité des échanges de messagerie et la visibilité des identités. C’est un prérequis technique incontournable dans tout projet de fusion ou de cession d’entités impliquant Exchange Online.
Définition officielle et périmètre fonctionnel
Selon Microsoft Learn, la coexistence dans Microsoft 365 permet le transfert et la réécriture des e-mails entre locataires tout en conservant le domaine racine lors de la transition. (Source : Microsoft Learn — 2025-11-10). Cette définition souligne deux impératifs : la continuité du routage des e-mails cross‑tenant et la préservation de l’expérience utilisateur. Durant la période de coexistence entre tenants, les boîtes aux lettres peuvent résider dans des locataires différents sans que les utilisateurs finaux en perçoivent l’impact opérationnel. Microsoft Entra ID joue un rôle central dans la synchronisation des identités et la gestion des relations inter‑organisations (organization relationships), en garantissant que chaque objet de l’annuaire reste cohérent des deux côtés.
Rôles des objets mailUser et des redirections SMTP
Les objets mailUser (mailUser objects) constituent la pierre angulaire du mode coexistence Exchange Online entre locataires. Lorsqu’un utilisateur est migré vers le tenant cible, son homologue dans le tenant source est converti en objet mailUser, porteur d’une adresse de routage externe (ExternalEmailAddress). Les enregistrements MX records restent inchangés pour le domaine source ; c’est la réécriture SMTP qui assure la redirection transparente du flux vers le tenant de destination. Ce mécanisme évite toute interruption de distribution et permet aux deux populations d’utilisateurs de correspondre librement pendant toute la durée de la migration. La conception de cette architecture d’identités est abordée en détail dans notre article sur la conception de l’architecture des identités pour une migration tenant to tenant M365.
| Composant | Rôle | Locataire concerné |
|---|---|---|
| mailUser objects | Représenter les boîtes migrées côté source | Tenant source |
| ExternalEmailAddress | Rediriger le flux SMTP vers le tenant cible | Tenant source |
| MX records | Maintenir la résolution DNS du domaine | Les deux tenants |
| Organization relationships | Activer le partage de disponibilité (Free/Busy) | Les deux tenants |
| Microsoft Entra ID | Synchroniser les identités et les attributs | Les deux tenants |
Cas d’usage : fusions, cessions et scissions d’entités
La coexistence Exchange Online entre locataires s’impose particulièrement lors de trois scénarios récurrents : les fusions d’entreprises qui consolident deux tenants en un seul, les cessions partielles qui détachent une filiale dans un tenant indépendant, et les scissions qui séparent une entité existante. Dans chacun de ces cas, la durée de la période de coexistence entre tenants peut s’étendre de quelques semaines à plusieurs mois, selon le volume de boîtes à migrer et la complexité des dépendances applicatives. Pour en savoir plus sur la planification globale de ces migrations, Microsoft met à disposition sa documentation sur le Migration Orchestrator. Le chapitre suivant détaillera les étapes concrètes de configuration pour établir ce mode de coexistence de manière fiable et sécurisée.
Préparer la stratégie de coexistence et le routage des e-mails
Pour garantir la continuité des échanges pendant une migration inter-tenants, la stratégie de coexistence repose sur trois piliers : la configuration des relations organisationnelles, la preservation des objets de redirection et la planification rigoureuse des bascules. Ces éléments doivent être définis avant toute opération de déplacement de boîtes aux lettres.
Configurer l’OrganizationRelationship pour activer les migrations inter-tenants
La période de coexistence Microsoft 365 exige d’établir une relation de confiance explicite entre les deux locataires Exchange Online. Cette configuration s’effectue via PowerShell sur les deux tenants. Selon Microsoft Learn, la commande New-OrganizationRelationship permet d’activer les migrations de boîtes aux lettres inter-tenants en précisant les paramètres targetTenantId, appId et le scope de la relation. (Source : Microsoft Learn — 2025-02-28)
Cette organization relationship s’appuie sur une application enregistrée dans Microsoft Entra ID, disposant des permissions nécessaires pour orchestrer les déplacements. Les Connecteurs Exchange peuvent compléter ce dispositif pour maîtriser le routage des e-mails cross-tenant pendant la transition. Il est recommandé de valider la relation avec la commande Get-OrganizationRelationship avant d’initier le premier lot de migrations.
| Paramètre | Rôle | Exemple de valeur |
|---|---|---|
| Name | Identifiant de la relation | Coexistence-TenantA-TenantB |
| TargetTenantId | ID du tenant cible | xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx |
| AppId | ID de l’application Entra enregistrée | yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy |
| MailboxMoveEnabled | Autorise les déplacements de boîtes | $true |
| MailboxMoveCapability | Sens du déplacement autorisé | Inbound / Outbound / RemoteInbound |
Conserver les mailUser sources pour assurer la redirection
Un point critique de l’interopérabilité des flux de messagerie entre locataires concerne la gestion des objets MailUser dans le tenant source. Une fois la boîte aux lettres migrée vers le tenant cible, l’objet source doit être converti en utilisateur de messagerie (mailUser) avec l’adresse cible définie dans l’attribut ExternalEmailAddress. Ce contact distant assure la continuité du routage : tout e-mail adressé à l’ancienne adresse est automatiquement redirigé vers la nouvelle boîte dans Exchange Online. Sans cette configuration, les messages envoyés depuis des systèmes tiers ou des annuaires non mis à jour génèrent des NDR (Non-Delivery Reports) qui perturbent la productivité.
Organiser le calendrier de bascule et les critères de validation
La coexistence hybride et migration interlocataire doit s’inscrire dans un calendrier structuré par lots homogènes (par département, site ou criticité métier). Chaque lot doit faire l’objet d’une validation formelle avant le lot suivant : vérification des MX records, tests de réception et d’envoi, contrôle des règles de transport et audit des Connecteurs Exchange. La mise à jour des enregistrements DNS (MX records) ne s’effectue qu’à la fin de chaque vague, une fois les boîtes aux lettres migrées et les objets de redirection actifs. Pour cadrer l’ensemble du processus, Migration Orchestrator offre une vue centralisée permettant de suivre l’avancement et d’identifier rapidement les anomalies de routage. La prochaine étape consiste à examiner les mécanismes de coexistence des identités et la synchronisation entre Microsoft Entra ID des deux tenants.
Maintenir la collaboration pendant la coexistence (Teams, OneDrive, SharePoint)
Pendant une migration tenant to tenant, la continuité de la collaboration repose sur une gestion rigoureuse des accès inter-locataires, des permissions B2B et de la fédération Teams. Anticiper les contraintes techniques de chaque service évite les interruptions qui pèsent sur la productivité des équipes.
Contraintes SharePoint et OneDrive lors d’une migration inter-tenants
SharePoint Online impose plusieurs limitations structurelles qui conditionnent la séquence de migration. Selon Microsoft Learn, les sites contenant plus de 5 To de contenu ou plus d’un million d’éléments ne peuvent pas être migrés entre locataires (Source : Microsoft Learn — 2024-10-30). Au-delà de cette contrainte de volume, les chemins d’accès aux bibliothèques de documents changent après migration, ce qui casse les liens partagés existants et affecte les intégrations applicatives qui référencent des URLs absolues. OneDrive Entreprise subit les mêmes limitations sur la taille des sites utilisateurs. Il est donc indispensable d’auditer l’inventaire des sites avant de lancer toute opération, en segmentant les contenus éligibles à la migration automatisée de ceux qui nécessitent une réorganisation préalable ou un transfert manuel.
| Service | Limite de volume | Impact principal | Action recommandée |
|---|---|---|---|
| SharePoint Online | > 5 To ou > 1 million d’éléments | Site non éligible à la migration automatique | Réorganiser ou archiver avant migration |
| OneDrive Entreprise | > 5 To par utilisateur | Blocage du transfert de profil | Nettoyer ou déplacer les contenus excédentaires |
| Bibliothèques de documents | Chemins modifiés post-migration | Rupture des liens et intégrations tierces | Recréer les raccourcis et mettre à jour les références |
Cohabitation des groupes Microsoft 365 et fédération Teams
La coexistence multi-locataires Microsoft 365 implique que des Microsoft 365 Groups existent simultanément dans les deux tenants pendant la période de transition. Les équipes Teams associées à ces groupes conservent leurs canaux, fichiers et historiques dans le tenant source jusqu’à la bascule définitive. Pour maintenir la communication entre collaborateurs déjà migrés et ceux encore dans le tenant d’origine, la fédération Teams entre tenants doit être activée et configurée dans les paramètres d’accès externe de chaque organisation. Cette coexistence Teams et fédération inter-locataires permet aux utilisateurs de se contacter par message direct et de rejoindre des réunions, mais avec des restrictions : le partage de fichiers en réunion fédérée reste limité et certaines fonctionnalités avancées de canal ne sont pas disponibles en contexte cross-tenant. L’orchestrateur de migration Microsoft 365 permet de planifier et de synchroniser ces transitions de groupes pour réduire la fenêtre de cohabitation.
Gestion des accès B2B et prévention des interruptions
Azure AD B2B Collaboration constitue le mécanisme central pour maintenir les partages inter-locataires OneDrive et SharePoint lorsque des utilisateurs du tenant source doivent accéder à des ressources du tenant cible, ou inversement. Les comptes invités B2B pendant la migration doivent être provisionnés avec des politiques d’accès conditionnel adaptées pour éviter que des exigences d’authentification multifacteur (MFA) différentes entre tenants ne bloquent les connexions. Il est conseillé de documenter chaque permission de partage externe existante avant la migration, puis de les recréer explicitement dans le nouveau tenant afin d’éviter toute rupture d’accès. Une revue régulière des comptes invités actifs dans les deux tenants garantit que les droits accordés restent cohérents avec l’avancement réel de la migration.
La maîtrise de ces trois dimensions — volumétrie SharePoint, fédération Teams et gouvernance B2B — pose les fondations d’une coexistence stable. La prochaine étape consiste à examiner comment gérer les identités et les politiques de sécurité pendant cette période de double appartenance organisationnelle.
Gouvernance, conformité et supervision pendant la coexistence
Durant la coexistence entre deux tenants Microsoft 365, la supervision des flux de messagerie et le maintien des politiques de conformité constituent des priorités non négociables. Chaque semaine de coexistence représente une fenêtre de risque : messages non remis, règles de rétention incohérentes ou lacunes d’audit entre environnements.
Surveiller les logs de transport et les messages NDR
Le Centre d’administration Exchange offre une visibilité granulaire sur les flux de messagerie inter-locataires. En période de coexistence, il est conseillé de consulter quotidiennement les journaux de suivi des messages afin d’identifier les NDR (Non-Delivery Reports) qui signalent souvent une mauvaise résolution des espaces de noms ou un conflit de domaine non encore transféré. Les Azure AD audit logs complètent cette supervision en enregistrant les authentifications croisées, les délégations et les modifications de configuration susceptibles d’affecter le routage. La mise en place d’alertes automatisées sur les volumes d’erreurs anormaux permet de réduire sensiblement les interruptions de service en migration tenant to tenant avant qu’elles n’affectent les utilisateurs finaux.
Maintenir les politiques de conformité et rétention dans Microsoft Purview
Microsoft Purview est le socle de la sécurité et conformité en période de coexistence. Les politiques de rétention, les étiquettes de sensibilité et les règles DLP doivent être alignées entre les deux tenants dès le début de la phase de coexistence, et non appliquées uniquement au tenant de destination après la migration. Une divergence de politique peut entraîner la perte de données soumises à des obligations légales ou réglementaires. Le Centre de conformité permet d’exporter un inventaire des stratégies actives pour les comparer tenant par tenant. Il est recommandé de documenter chaque écart et d’en planifier la résolution dans le calendrier de migration. Selon BitTitan, il convient de planifier la migration par workload et de maintenir les deux environnements fonctionnels jusqu’à la fin complète du projet (Source : BitTitan — 2025-09-09). Pour les organisations soumises à des exigences sectorielles strictes, cette approche de gouvernance cross-tenant progressive limite considérablement les risques de non-conformité.
Prévoir un plan de retour arrière ou de rollback partiel
Aucune migration n’est à l’abri d’un incident imprévu : conflit de licence, régression applicative ou problème de coexistence de calendriers. Un plan de rollback partiel définit précisément les seuils d’alerte qui déclenchent un retour arrière, les workloads prioritaires à réactiver sur le tenant source et les responsables habilités à prendre cette décision. Ce plan doit être testé avant la phase de migration active, idéalement lors d’un pilote sur un groupe restreint d’utilisateurs. La documentation officielle Microsoft sur l’orchestrateur de migration détaille les mécanismes de contrôle disponibles pour superviser et, si nécessaire, interrompre les opérations en cours. La supervision coexistence Microsoft 365 repose ainsi sur trois piliers indissociables : monitoring continu, conformité synchronisée et capacité de réversibilité — le chapitre suivant abordera les stratégies de communication et de conduite du changement auprès des utilisateurs pendant cette période critique.
Conclusion
Une coexistence post-migration tenant to tenant réussie repose avant tout sur une planification rigoureuse et une gouvernance maintenue jusqu’à la désactivation complète du locataire source. Adopter une approche structurée permet de préserver la continuité métier tout en limitant l’impact sur l’expérience utilisateur.
La période de coexistence Microsoft 365 exige de traiter simultanément plusieurs workloads — messagerie, Teams, SharePoint — sans sacrifier l’interopérabilité entre locataires source et cible. Les Cross-Tenant Access Settings constituent le socle technique de cette phase de run parallèle des locataires, mais leur efficacité dépend d’une documentation précise et régulièrement mise à jour. Selon la Microsoft Tech Community, ce type de migration concerne principalement les contextes de fusions, acquisitions ou cessions d’entités (Source : Microsoft Tech Community — 2024-06-17), ce qui souligne l’enjeu organisationnel fort qui accompagne chaque projet.
Pour la gestion multi-tenants Microsoft 365, Eliadis recommande de formaliser chaque décision de gouvernance dès le lancement du projet et de ne pas sous-estimer la conduite du changement auprès des utilisateurs finaux. Un Digital Workplace cohérent à l’issue de la migration est le résultat d’une collaboration étroite entre équipes techniques et métier, soutenue par des outils comme le Migration Orchestrator Microsoft 365.
