La préparation du tenant cible Microsoft 365 ne se limite pas à provisionner un environnement vierge : elle implique d’aligner la gouvernance, les politiques de sécurité et les performances dès la phase de conception. Microsoft Entra ID, les paramètres d’identité, les licences et les stratégies de conformité doivent être définis en cohérence avec les objectifs métier du projet. Eliadis, partenaire Microsoft spécialisé dans l’intégration d’environnements collaboratifs Office 365, accompagne ses clients dans cette démarche structurante. Cet article détaille les composantes clés d’une architecture du tenant cible Microsoft 365 solide pour garantir une migration cross-tenant réussie.
À retenir :
- Conception rigoureuse de l’architecture Microsoft 365 cruciale pour une migration cross-tenant réussie
- Topologie et modèle d’identité doivent être adaptés à l’organisation pour assurer une cohérence structurelle
- Choisir entre modèles cloud-only, hybride ou fédéré pour gérer les identités selon la stratégie de l’entreprise
- Gouvernance des groupes et stratégie des domaines essentielles pour éviter les conflits et assurer la collaboration
- Sécurité et conformité doivent être intégrées dès la conception, incluant MFA et processus de vérification des données
- La préparation minutieuse de la migration conditionne sa réussite, avec validation des connexions et mappage des identités
Définir la topologie et la stratégie d’identité du tenant cible
Avant toute migration cross-tenant Microsoft 365, il est indispensable de choisir une topologie de tenant et un modèle d’identité adaptés à votre organisation. Ces décisions structurent l’ensemble de l’architecture cible et conditionne directement la réussite des phases ultérieures de migration.
Analyser les options de topologie : single tenant, multi-tenant et organisation multilocataire
La première étape de la conception de l’infrastructure cible consiste à évaluer les différentes topologies disponibles. Le modèle single tenant centralise tous les utilisateurs, données et services au sein d’un unique environnement Microsoft 365 : il simplifie la gouvernance et réduit les coûts opérationnels, mais peut représenter un défi lors de fusions ou d’acquisitions impliquant des entités juridiquement distinctes. Le modèle multi-tenant, à l’inverse, maintient plusieurs tenants indépendants reliés par des relations de confiance inter-domaines. Enfin, la conception de l’organisation multilocataire M365 — via la fonctionnalité Multitenant Organization d’Microsoft Entra ID — permet de synchroniser les identités entre tenants tout en préservant leur autonomie administrative. Cette approche est particulièrement pertinente pour les groupes disposant de filiales aux politiques de conformité différenciées.
Microsoft Learn indique que la migration cross-tenant SharePoint déplace le contenu de la source vers la cible, laissant un lien de redirection sur la source, ce qui suppose que le lien entre tenant source et tenant cible soit établi en amont et correctement configuré (Source : Microsoft Learn — 2025-11-05). La topologie choisie détermine donc la nature et la robustesse de ce lien.
Évaluer les modèles d’identité : cloud-only, hybride ou fédéré
Le choix du modèle d’identité est tout aussi structurant que la topologie. Trois approches s’offrent aux organisations :
- Cloud-only : les identités sont gérées exclusivement dans Microsoft Entra ID, sans dépendance à un Active Directory on-premises. Ce modèle convient aux organisations nativement cloud ou souhaitant simplifier leur infrastructure à l’occasion de la migration.
- Hybride (via Entra Connect) : Azure AD Connect synchronise les comptes depuis l’Active Directory on-premises vers Entra ID. Cette option préserve les investissements existants tout en offrant une intégration progressive vers le cloud. Elle est souvent retenue lors de migrations impliquant des entités disposant d’une infrastructure Active Directory mature.
- Fédéré : l’authentification est déléguée à un fournisseur d’identité tiers (ADFS, Okta, etc.). Ce modèle répond à des exigences de conformité spécifiques, mais introduit une complexité supplémentaire dans le cadre d’une migration cross-tenant.
Pour accompagner vos équipes dans la configuration technique des relations inter-tenants, consultez notre guide sur la configuration relation organisation cross-tenant Exchange Online.
Aligner l’architecture avec la gouvernance et la sécurité existantes
La modélisation de l’infrastructure Entra ID cible ne peut être dissociée des exigences de gouvernance des identités et des accès M365 déjà en place. Il convient d’auditer les politiques d’accès conditionnel, les rôles administratifs et les périmètres de conformité avant de finaliser la configuration du tenant Microsoft 365 cible. Eliadis recommande de formaliser une matrice de gouvernance dès cette phase, intégrant les exigences réglementaires propres à chaque entité migrée.
| Critère | Cloud-only | Hybride (Entra Connect) | Fédéré |
|---|---|---|---|
| Dépendance on-premises | Aucune | Oui (AD requis) | Oui (IdP tiers) |
| Complexité de déploiement | Faible | Moyenne | Élevée |
| Adapté à la migration cross-tenant | Oui | Oui | Sous conditions |
| Gouvernance centralisée | Oui | Partielle | Variable |
Une fois la topologie et le modèle d’identité validés, il devient possible d’aborder la configuration technique du tenant cible, notamment la gestion des domaines, des licences et des règles de coexistence entre les deux environnements.
Structurer les domaines, groupes et ressources collaboratives Microsoft 365
Une architecture du locataire Microsoft 365 solide repose sur trois piliers indissociables : la stratégie de domaines, la gouvernance des groupes et la configuration des ressources collaboratives. Définir ces éléments en amont conditionne directement la réussite d’une migration cross-tenant.
Choisir les domaines primaires et secondaires adaptés au modèle d’entreprise
La stratégie de domaines Microsoft 365 doit refléter la réalité juridique et opérationnelle de l’organisation cible. Le domaine primaire constitue l’identité centrale du locataire : il s’applique par défaut aux nouvelles adresses UPN (User Principal Name) et aux alias de messagerie Exchange Online. Les domaines secondaires, quant à eux, permettent d’accommoder des entités subsidiaires, des marques commerciales distinctes ou des périmètres géographiques spécifiques. Il est conseillé de valider la propriété de chaque domaine dans le centre d’administration Microsoft 365 avant toute migration, sous peine de bloquer le provisionnement des boîtes aux lettres et des ressources SharePoint Online. Une nomenclature cohérente, documentée dès la phase de conception, évite les conflits d’alias et simplifie la gouvernance à long terme.
Configurer les Groupes Microsoft 365 pour la collaboration et Teams pour l’agilité
Les Microsoft 365 Groups constituent la brique fonctionnelle commune à Exchange Online (boîte partagée), SharePoint Online (site d’équipe), Microsoft Teams (espace de conversation) et Planner. L’urbanisation du locataire Microsoft 365 impose de définir en amont une politique de création de groupes : qui peut créer un groupe, selon quelle convention de nommage et avec quelle durée d’expiration. Sans cette gouvernance des groupes et équipes, la prolifération non contrôlée génère des doublons, des sites orphelins et des coûts de stockage inutiles. Microsoft Teams hérite automatiquement d’un groupe M365 à sa création ; anticiper cette interdépendance garantit une structure cohérente dès le premier jour dans le locataire cible.
Anticiper les quotas et exigences techniques (Exchange, SharePoint, OneDrive)
La configuration Exchange Online SharePoint Teams doit intégrer les contraintes de volumétrie dès la phase de conception. Le tableau ci-dessous récapitule les principaux seuils techniques à évaluer avant migration :
| Service | Paramètre clé | Valeur par défaut / limite |
|---|---|---|
| Exchange Online | Taille de boîte aux lettres (Plan 2) | 100 Go par utilisateur |
| SharePoint Online | Stockage par locataire | 1 To + 10 Go par licence |
| OneDrive Entreprise | Quota par utilisateur | 1 To (extensible) |
| Microsoft Teams | Membres par équipe | 25 000 membres |
| Migration cross-tenant SharePoint | Comptes planifiables simultanément | 4 000 comptes |
Selon Microsoft Learn, jusqu’à 4 000 comptes SharePoint peuvent être planifiés pour la migration à un moment donné dans le cadre d’une migration cross-tenant. (Source : Microsoft Learn — 2025-11-05). Cette limite technique doit guider le séquencement des vagues de migration et la taille des batches SharePoint Online définis dans le plan projet.
Pour aller plus loin dans la préparation opérationnelle, il est utile de consulter la checklist d’une migration Microsoft 365 réussie, qui détaille les vérifications préalables à chaque phase. Le chapitre suivant abordera la gouvernance des identités et la gestion des accès dans le locataire cible, autre pilier fondamental de l’architecture globale.
Intégrer la sécurité, la conformité et la continuité dans l’architecture du tenant cible
La sécurité et la conformité du tenant cible Microsoft 365 ne s’ajoutent pas après la migration : elles se conçoivent dès l’architecture initiale. Un design sécurité Entra ID et MFA défini en amont évite des reconfigurations coûteuses et réduit la surface d’attaque pendant le basculement.
Implémenter MFA, Identity Protection et Conditional Access dès la conception
La stratégie de sécurité Entra ID repose sur trois piliers interdépendants à activer avant tout transfert de données. L’authentification multifacteur (MFA) constitue le socle minimal : elle doit être imposée à l’ensemble des comptes, y compris les comptes de service utilisés pendant la migration. Microsoft Entra ID P2 permet d’aller plus loin en activant Identity Protection, qui détecte les connexions à risque et bloque automatiquement les comportements anormaux, ainsi que les stratégies d’Accès Conditionnel (Conditional Access) basées sur le risque utilisateur, la conformité de l’appareil et la localisation réseau.
Dans une migration cross-tenant, les comptes sont temporairement exposés dans deux environnements simultanément. Configurer des règles Conditional Access spécifiques à la phase de migration — par exemple, restreindre l’accès au tenant cible aux seuls appareils managés via Azure Virtual Network — limite l’exposition pendant la période de coexistence. Microsoft Defender for Cloud Apps complète ce dispositif en assurant la visibilité sur les accès aux applications cloud et en détectant les comportements anormaux liés aux volumes de données déplacées.
Configurer les paramètres de conformité avec Microsoft Purview et DLP
Le plan de gouvernance tenant to tenant doit intégrer Microsoft Purview comme colonne vertébrale de la conformité réglementaire. Les étiquettes de sensibilité (sensitivity labels), les politiques de rétention et les règles de prévention des pertes de données (DLP) doivent être déployées sur le tenant cible avant la migration effective des contenus. Cela garantit que chaque document migré hérite immédiatement du niveau de protection approprié.
Un point de vigilance critique concerne le chiffrement des données. Selon Microsoft Learn, il convient de vérifier que le chiffrement du service n’est pas activé avec clé client Microsoft Purview sur le locataire source, sous peine de provoquer un échec de migration. (Source : Microsoft Learn — 2025-11-05). Auditer les paramètres de conformité M365 côté source est donc une étape non négociable avant tout déclenchement de synchronisation.
Prévoir des scénarios de reprise et sauvegarde dans un contexte multi-entités
La sauvegarde et restauration Microsoft 365 dans un environnement multi-entités exige une approche structurée. Le tenant cible doit disposer d’une stratégie de sauvegarde opérationnelle dès le premier jour de migration, couvrant Exchange Online, SharePoint et OneDrive. Les fenêtres de restauration doivent être testées en amont pour valider les SLA internes, en particulier lorsque plusieurs entités juridiques coexistent dans la même infrastructure.
La définition des responsabilités de reprise (RACI) entre les équipes IT des entités fusionnées, les administrateurs du tenant cible et les partenaires d’intégration garantit une réponse coordonnée en cas d’incident. Ces scénarios de continuité forment le dernier socle d’une architecture résiliente — avant d’aborder la phase opérationnelle de mise en œuvre technique.
Préparer la migration et valider la cohérence de l’environnement cible
Avant de lancer toute migration cross-tenant, la préparation du tenant cible conditionne directement la réussite de l’opération. Chaque étape doit être validée dans l’ordre, depuis la connexion inter-tenants jusqu’au démarrage effectif du transfert des données.
Mettre en place les étapes de connexion et d’approbation entre tenants
La migration cross-tenant repose sur un protocole de confiance bilatérale entre le tenant source et le tenant cible. Il convient d’abord d’établir la connexion entre les deux locataires via PowerShell, puis de soumettre et valider mutuellement les demandes d’approbation. Cette étape conditionne toutes les suivantes : sans approbation confirmée, aucune synchronisation ni transfert de contenu ne peut être initié. Selon Microsoft Learn, les étapes pour la migration OneDrive cross-tenant incluent la connexion, l’approbation, le mappage des identités et le démarrage de la migration (Source : Microsoft Learn — 2025-04-19). La vérification de l’approbation doit être documentée et tracée, notamment pour les environnements soumis à des exigences de gouvernance renforcées via Azure AD Privileged Identity Management.
Précréer les utilisateurs et vérifier le mappage des identités
La précréation des comptes utilisateurs dans le tenant cible est une condition préalable non négociable. Chaque compte doit être créé avec les attributs nécessaires — UPN, alias SMTP, licences — avant que la migration des données ne commence. Le mappage des identités consiste à associer chaque utilisateur source à son compte cible correspondant, via un fichier de mappage structuré exploité par les outils de migration Microsoft ou des outils tiers. Une erreur de mappage entraîne des pertes d’accès ou des attributions incorrectes de données. Dans un guide DSI pour architecture tenant Microsoft 365, cette phase est souvent présentée comme le point de contrôle le plus sensible de la checklist création locataire cible. Il est recommandé de tester le mappage sur un sous-ensemble pilote avant de l’appliquer à l’ensemble du périmètre.
Assurer la compatibilité des workloads et du stockage avant migration
La cohérence de l’environnement cible ne se limite pas aux identités. Il faut également vérifier la compatibilité des workloads concernés, en particulier OneDrive Entreprise et SharePoint Online. Plusieurs vérifications s’imposent avant de démarrer :
| Workload | Point de vérification | Outil recommandé |
|---|---|---|
| OneDrive Entreprise | Quota de stockage disponible dans le tenant cible | PowerShell (Get-SPOSite) |
| SharePoint Online | Compatibilité des types de contenu et colonnes personnalisées | Outils tiers de migration |
| Identités | Cohérence UPN et licences affectées | Azure AD + PowerShell |
| Approbations | Statut d’approbation inter-tenants actif | Centre d’administration M365 |
La coexistence tenants pendant migration implique une période où les deux environnements sont actifs simultanément. Il est essentiel de planifier la gestion des conflits de noms, des doublons de boîtes aux lettres et des accès concurrents. Ce plan de montée en charge tenant Microsoft 365 doit être documenté et validé par les équipes IT avant tout basculement. L’étape suivante abordera la gouvernance post-migration et la consolidation définitive de l’environnement cible.
Conclusion
Une migration cross-tenant Microsoft 365 réussie repose avant tout sur une architecture du tenant cible rigoureusement conçue en amont. La cohérence entre la définition de l’architecture du locataire de destination, la sécurité et la gouvernance n’est pas optionnelle : elle conditionne directement la stabilité de l’environnement cloud collaboratif Microsoft après le basculement.
La préparation de migration cross-tenant impose également de respecter des contraintes techniques précises. Selon Microsoft Learn, les sites OneDrive ne doivent pas être créés avant ou pendant une migration sur le tenant cible, sous peine de compromettre l’intégrité du processus (Source : Microsoft Learn — 2025-04-19). Cette recommandation illustre à quel point les meilleures pratiques architecture M365 doivent être intégrées dès la phase de conception, en lien avec Microsoft Entra ID et Microsoft Purview.
Pour aligner sécurité, conformité et gouvernance tout au long du projet, l’expertise d’un partenaire Microsoft expérimenté fait une réelle différence. Eliadis accompagne ses clients dans la conception et l’exécution de migrations complexes, en s’appuyant sur une méthodologie éprouvée depuis 2001.
