Audit initial et analyse préalable d’une migration tenant to tenant Microsoft 365

Avant d’engager le moindre transfert de données, les DSI et chefs de projet doivent disposer d’une vision exhaustive de leur environnement : licences actives, configurations Exchange Online, sites SharePoint Online, équipes Teams, identités Entra ID et flux Power Platform. C’est précisément l’objet d’un diagnostic préalable de l’environnement M365 structuré, tel que le préconise Eliadis dans sa pratique de conseil en migration cloud. Cet audit initial du tenant Microsoft 365 permet d’objectiver les dépendances techniques, d’identifier les configurations critiques et de réduire les zones d’incertitude avant d’entrer en phase d’exécution. Les sections suivantes détaillent les axes concrets de cette analyse de l’existant avant migration.

Comprendre les objectifs et le périmètre de l’audit initial

Avant de démarrer toute migration tenant to tenant Microsoft 365, définir précisément les objectifs et les limites de l’audit initial est une étape non négociable. Ce cadrage conditionne directement la fiabilité de la planification projet et la maîtrise des risques opérationnels.

Clarifier les enjeux : volumétrie, dépendances métiers et contraintes

Le pré-audit de migration tenant to tenant commence par une cartographie des enjeux. La DSI et le chef de projet migration doivent quantifier la volumétrie des données concernées : boîtes aux lettres, bibliothèques SharePoint, équipes Teams, licences actives. Cette volumétrie détermine les contraintes techniques (bande passante, durée de migration, fenêtres de basculement) et influence directement les choix d’outillage.

Au-delà des chiffres, il s’agit d’identifier les dépendances métiers critiques : quels workflows s’appuient sur des automatisations Power Automate ? Quelles applications métiers sont connectées à l’annuaire Azure Active Directory ? Ces interdépendances, souvent invisibles dans un état des lieux superficiel, sont précisément celles qui provoquent des incidents post-migration. Les contraintes juridiques, notamment celles liées au RGPD, doivent également être recensées à ce stade : résidence des données, durées de conservation, obligations de portabilité.

Selon Microsoft Learn, la phase de planification et découverte inclut un inventaire complet des données, des comptes utilisateurs et des licences du tenant actuel (Source : Microsoft Learn — 2025-09-18). Cette approche confirme que l’évaluation sécurité et conformité avant migration ne peut pas se limiter à un simple export CSV : elle exige une analyse structurée, service par service.

Périmètre typique de l’audit : messagerie, fichiers, identités, sécurité

Le périmètre d’un audit initial couvre plusieurs couches fonctionnelles et techniques. La messagerie Exchange Online constitue généralement le premier volet : volume de boîtes aux lettres, règles de flux, calendriers partagés, groupes de distribution. Vient ensuite la couche fichiers : SharePoint Online, OneDrive Entreprise, Teams (canaux, onglets, connecteurs). L’analyse des identités — comptes synchronisés via Azure AD Connect ou gérés en cloud-only, groupes de sécurité, rôles d’administration — forme le troisième axe. Enfin, la sécurité et la gouvernance M365 (politiques de conformité, étiquettes de sensibilité, stratégies DLP) doivent être auditées pour éviter toute régression de la posture de sécurité lors du basculement.

Pour aller plus loin sur la structuration de cette démarche, la stratégie de migration tenant to tenant Microsoft 365 détaille comment articuler chaque composant du périmètre avec les phases du projet.

Relier l’audit à la gouvernance et à la planification projet

L’analyse des risques de migration entre locataires ne produit de la valeur que si ses conclusions alimentent directement le plan de gouvernance. Les livrables de l’audit — inventaire des services, matrice des risques, cartographie des dépendances — doivent être formalisés dans le Centre d’administration Microsoft 365 et partagés avec les parties prenantes métiers. Ce lien entre audit et gouvernance garantit que les décisions de priorisation (quels services migrer en premier, quelles exceptions traiter manuellement) reposent sur des données factuelles plutôt que sur des suppositions.

La définition du périmètre étant posée, l’étape suivante consiste à sélectionner les outils et les méthodologies concrètes pour collecter ces données de manière exhaustive et fiable.

Réaliser l’inventaire technique et fonctionnel du tenant source

L’inventaire du tenant source constitue le socle de toute migration tenant to tenant réussie : sans cartographie précise des ressources, aucun plan de migration ne peut être fiable. Cette phase de discovery et de collecte d’informations doit couvrir l’ensemble des workloads Microsoft 365 et des paramètres d’infrastructure avant d’envisager le moindre déplacement de données.

Inventorier les workloads Exchange Online, SharePoint, OneDrive, Teams et Power Platform

La première étape consiste à dresser un inventaire détaillé des ressources cloud pour chaque service actif dans le tenant. Pour Exchange Online, il s’agit de recenser les boîtes aux lettres utilisateurs, les boîtes partagées, les groupes de distribution, les connecteurs de flux de messagerie et les règles de transport. Pour SharePoint Online, on cartographie les collections de sites, les modèles utilisés, les niveaux de permissions et les volumes de données stockées. OneDrive for Business requiert une évaluation des quotas consommés et des partages externes actifs. Côté Teams, l’inventaire porte sur les équipes, les canaux, les stratégies de messagerie et les intégrations d’applications tierces. Enfin, la Power Platform implique de recenser les flux Power Automate, les applications Power Apps et leurs connexions aux sources de données, qui peuvent nécessiter une requalification lors du passage vers le tenant cible. Cette cartographie multi-workloads est directement liée à la stratégie de migration tenant to tenant Microsoft 365 adoptée en amont.

Identifier les volumes, plans de licences et utilisateurs actifs

Au-delà du recensement des services, l’audit doit quantifier les volumes réels. Le tableau ci-dessous illustre les données clés à collecter par workload :

L’identification des utilisateurs actifs par opposition aux comptes dormants permet d’optimiser les coûts de licences dans le tenant cible et d’éviter de migrer des données obsolètes.

Analyser la configuration DNS, les domaines et les méthodes d’authentification

L’audit DNS et domaines personnalisés Microsoft 365 est une étape souvent sous-estimée. Il faut recenser l’ensemble des domaines vérifiés dans le tenant source, leurs enregistrements SPF, DKIM et DMARC, ainsi que les alias de messagerie associés. Cette vérification conditionne la stratégie de basculement de domaine, qui représente l’une des opérations les plus sensibles d’une migration. En parallèle, l’analyse des méthodes d’authentification — notamment le MFA et les politiques de Conditional Access — est indispensable : chaque règle conditionnelle devra être recréée ou adaptée dans le tenant cible. Il convient également d’évaluer si l’environnement source recourt à une fédération d’identité via ADFS ou à une synchronisation Azure AD Connect, car ces configurations influencent directement le séquencement de la migration. Pour aller plus loin sur les bonnes pratiques de préparation, la checklist d’une migration Microsoft 365 réussie propose un cadre de référence complémentaire. La cartographie des utilisateurs et groupes Microsoft 365, incluant les groupes de sécurité et les unités administratives, complète cet audit en préparant le chapitre suivant consacré à la gestion des identités dans le tenant cible.

Identifier les risques, dépendances et exigences de sécurité

Avant toute migration tenant to tenant Microsoft 365, cartographier les risques, les dépendances applicatives et les obligations réglementaires est une étape déterminante. Cette phase de revue technique et métier de l’existant conditionne directement la sécurité du projet et la continuité des services métiers.

Auditer les politiques de sécurité : MFA, accès conditionnel et fédération ADFS

L’analyse des dépendances identités et Entra ID constitue le socle de tout assessment technique et fonctionnel de la plateforme Microsoft 365. Il s’agit d’inventorier précisément les politiques d’accès conditionnel actives, les configurations MFA déployées et les relations de confiance établies via ADFS ou Azure AD B2B Collaboration. Chaque règle définie dans le tenant source doit être documentée : son périmètre, les groupes concernés et les applications ciblées. Une politique d’accès conditionnel non reportée dans le tenant cible peut exposer l’organisation à des accès non autorisés ou bloquer des utilisateurs légitimes dès le premier jour suivant la bascule. Il est également recommandé de vérifier la compatibilité des méthodes d’authentification entre les deux environnements, notamment lorsque des configurations hybrides (Active Directory on-premises + Azure AD) sont en place.

Identifier les interdépendances applicatives : Power Platform et SharePoint Framework

La Power Platform regroupe des actifs souvent sous-estimés lors d’un audit initial : Power Apps connectées à des sources de données SharePoint ou Dataverse, flux Power Automate déclenchés par des événements M365, et composants SharePoint Framework (SPFx) hébergés dans l’App Catalog du tenant. Ces ressources sont étroitement liées à l’identité du tenant source : un App ID, une connexion OAuth ou un connecteur personnalisé ne migre pas automatiquement. L’évaluation sécurité et conformité avant migration doit donc couvrir l’ensemble de ces objets, en distinguant ce qui peut être recréé dans le tenant cible, ce qui nécessite un redéveloppement, et ce qui doit faire l’objet d’une stratégie de coexistence temporaire. Le tableau ci-dessous synthétise les principaux éléments à auditer selon leur niveau de complexité de migration.

Évaluer la conformité RGPD et les impacts en contexte de fusion ou acquisition

Selon Petri.com, les organisations soumises à des réglementations telles que le RGPD doivent aligner l’audit avec leurs équipes juridiques et internes avant d’engager toute migration. (Source : Petri.com — 2025-12-22). Dans le cadre d’une fusion ou acquisition, cette exigence prend une dimension supplémentaire : les données traitées dans le tenant source peuvent être soumises à des législations différentes selon la localisation des entités impliquées. L’audit doit donc identifier les résidences de données configurées dans Microsoft 365, les rôles DPO concernés et les clauses contractuelles applicables aux sous-traitants. Pour structurer cette démarche, la stratégie de migration tenant to tenant Microsoft 365 doit intégrer dès l’amont une validation juridique formelle, au même titre que les validations techniques.

Une fois les risques, dépendances et exigences réglementaires documentés, l’étape suivante consiste à définir la gouvernance du projet de migration et à sélectionner les outils adaptés à chaque flux de données identifié.

Préparer la migration et la validation post-audit

Une fois l’audit initial complété, les résultats doivent être traduits en un plan d’action structuré définissant des critères clairs d’entrée en production et des mécanismes de validation robustes. La préparation technique du projet de migration M365 repose alors sur trois piliers : les critères de passage, le suivi post-migration et la gouvernance documentaire.

Définir les critères de passage en production

Avant de déclencher la migration, chaque pré-requis technique d’une migration tenant to tenant doit être vérifié et validé formellement. Cela implique de s’assurer que les licences cibles sont correctement provisionnées dans Entra ID, que les attributions de rôles sont conformes au modèle de gouvernance retenu, et que le plan de migration a été approuvé par les parties prenantes métiers et IT. La baseline de performance avant migration cloud doit également être capturée — temps de réponse des services, taux de disponibilité, volumétrie des boîtes aux lettres — afin de disposer d’une référence objective pour comparer l’état avant et après bascule. Le Migration orchestrator choisi doit être configuré et testé sur un périmètre pilote restreint avant tout déploiement à grande échelle. Ce pilote permet de valider les flux de données, d’identifier les incompatibilités résiduelles et d’affiner les fenêtres de migration. Consultez également notre guide sur la stratégie de migration tenant to tenant Microsoft 365 pour aligner votre planification avec les meilleures pratiques du marché.

Mettre en place un suivi post-migration et vérifier l’intégrité des données

La phase de validation post-migration est déterminante pour garantir la continuité opérationnelle. Selon Microsoft Learn, la validation post-migration doit s’assurer de l’intégrité des données migrées et de la continuité du service après transfert (Source : Microsoft Learn — 2025-11-12). Concrètement, cela signifie vérifier que chaque boîte aux lettres, site SharePoint et équipe Teams a été correctement transférée, que les permissions ont été préservées et que les utilisateurs peuvent accéder à leurs données sans interruption. Les Audit logs constituent ici un outil central : ils permettent de tracer chaque opération réalisée pendant la migration et de détecter d’éventuelles anomalies ou pertes partielles. Un tableau de suivi structuré facilite ce contrôle :

Assurer la traçabilité et la documentation complète pour la gouvernance

L’analyse des impacts métier d’une migration tenant to tenant ne s’arrête pas à la bascule technique : elle impose une documentation exhaustive de chaque décision prise et de chaque anomalie rencontrée. Microsoft Purview permet de centraliser les politiques de gouvernance, de classifier les données sensibles et d’assurer la conformité réglementaire tout au long du processus. Chaque étape — de l’audit initial à la validation finale — doit être consignée dans un registre de projet accessible aux équipes IT, juridiques et métiers. Cette traçabilité est indispensable en cas d’audit externe ou de litige post-migration. Pour compléter votre approche, cette checklist d’une migration Microsoft 365 réussie offre un cadre de référence opérationnel utile. La gouvernance documentaire devient ainsi le garant de la qualité et de la pérennité de votre nouveau tenant cible.

Conclusion

Un audit initial rigoureux est la condition sine qua non d’une migration tenant to tenant Microsoft 365 maîtrisée. Sans cette étude de l’environnement source et cible, les risques de perte de données, de rupture de service ou de non-conformité restent difficiles à anticiper.

Le pré-audit de migration tenant to tenant permet de structurer la démarche autour de trois axes essentiels : la revue de gouvernance Microsoft 365 existante, l’analyse des risques de migration entre locataires, et la coordination étroite entre les équipes IT, sécurité et métiers. Le Chef de projet migration joue ici un rôle central pour aligner les contraintes techniques avec les objectifs opérationnels. Par ailleurs, selon Petri.com, les deux tenants concernés doivent disposer de licences Microsoft 365 E3/E5 ou équivalentes pour orchestrer la migration (Source : Petri.com — 2025-12-22).

En tant que Partenaire Microsoft, Eliadis accompagne ses clients à chaque étape de cette stratégie de migration globale, de la phase d’audit jusqu’à l’adoption finale. Une préparation aussi structurée garantit non seulement la continuité du service, mais aussi la pérennité de votre Digital Workplace.