Pour les DSI et architectes cloud engagés dans un projet de préparation du tenant cible pour une migration tenant to tenant, la maîtrise de cette étape est déterminante. L’application de service pour migration cross-tenant repose sur trois piliers techniques : Microsoft Entra ID pour la gestion des identités et des autorisations, Microsoft Graph API pour l’accès programmatique aux ressources, et les services Microsoft 365 — Exchange Online, SharePoint Online, OneDrive Entreprise et Microsoft Teams — comme périmètre de migration. Configurer une application Azure AD pour migration tenant to tenant implique de définir des permissions précises, de gérer le consentement administrateur et d’assurer une gouvernance rigoureuse tout au long du projet. La documentation officielle Microsoft fournit le cadre de référence pour ces opérations. Cet article détaille chaque étape de création et de configuration de l’app registration Microsoft 365 nécessaire à une migration réussie.
À retenir :
- Microsoft Entra ID est essentiel pour les migrations cross-tenant de Microsoft 365
- Une application doit être configurée avec des permissions spécifiques pour fonctionner correctement
- Les applications peuvent être single-tenant ou multi-tenant, influençant l’accès entre locataires
- Le consentement administrateur est crucial pour valider les permissions API nécessaires
- Tester, surveiller et valider les configurations est primordial avant la migration
- Le principe de moindre privilège doit guider les autorisations octroyées pour assurer la sécurité des données
Comprendre le rôle et la structure d’une application de migration Microsoft Entra ID
Une application de migration Microsoft Entra ID constitue le point d’entrée technique permettant à deux tenants distincts d’échanger des données et des autorisations de manière sécurisée. Sans cet enregistrement applicatif, aucune opération inter-locataires pilotée par Microsoft Graph API ne peut être initiée.
Application, client ID, tenant ID et autorisations Microsoft Graph
Lors de chaque enregistrement d’application dans Microsoft Entra ID, la plateforme génère automatiquement deux identifiants fondamentaux : un client ID (identifiant unique de l’application) et un tenant ID (identifiant du répertoire hôte). Ces deux valeurs sont indissociables : elles définissent précisément l’application et le locataire auquel elle appartient. C’est sur cette base que Microsoft Graph API vérifie, pour chaque appel, si l’entité appelante dispose des autorisations requises — qu’il s’agisse de droits délégués ou de permissions d’application.
Microsoft Learn indique que les enregistrements d’application Microsoft Entra ID sont propres à chaque tenant et ne peuvent pas être transférés directement d’un locataire à un autre. (Source : Microsoft Learn — 2025-11-08). Cette contrainte implique qu’une application d’intégration inter-locataires doit être enregistrée et configurée indépendamment dans chacun des tenants impliqués dans la migration, avec des secrets et des permissions propres à chaque environnement.
Single-tenant vs multi-tenant : un choix structurant
L’enregistrement d’application Azure offre deux modes de portée d’audience fondamentalement différents. Une application single-tenant n’est accessible qu’aux comptes du répertoire hôte, ce qui convient aux environnements fortement contraints. Une application multi-tenant — désignée dans la documentation sous l’appellation Accounts in any organizational directory — permet en revanche d’autoriser des appels provenant d’un tenant externe. Dans le cadre d’une migration tenant to tenant, c’est généralement le mode multi-tenant Office 365 qui est retenu côté tenant source, afin d’accorder au tenant cible les droits de lecture nécessaires sur les objets à migrer.
| Critère | Single-tenant | Multi-tenant |
|---|---|---|
| Portée des accès | Tenant hôte uniquement | Tout tenant Azure AD |
| Cas d’usage migration | Limité (tests locaux) | Recommandé pour les scénarios inter-locataires |
| Consentement administrateur | Requis une seule fois | Requis dans chaque tenant tiers |
| Complexité de configuration | Faible | Modérée à élevée |
L’application comme catalyseur OAuth 2.0 des accès inter-locataires
Le protocole OAuth 2.0, implémenté par Microsoft Entra ID via le flux client credentials, est le mécanisme qui permet à un connecteur applicatif de migration cloud d’obtenir un jeton d’accès sans interaction utilisateur. Ce jeton, émis par le point d’extrémité /token du tenant concerné, est ensuite présenté à Microsoft Graph API pour chaque opération : lecture des boîtes aux lettres, copie des données SharePoint, attribution de licences, ou encore gestion des objets MailUser. La configuration des domaines acceptés et des objets MailUser côté tenant cible est une étape complémentaire indispensable pour que ces jetons produisent les effets attendus sur les ressources destinataires.
Pour aller plus loin sur le cadre officiel des migrations inter-locataires, la documentation Microsoft sur la migration multi-tenant détaille les prérequis et les étapes de consentement à mettre en place. La prochaine étape consiste à examiner concrètement comment créer et paramétrer cet enregistrement applicatif dans le portail Azure.
Créer et configurer l’application dans le tenant source et le tenant cible
La création et la configuration d’une application de migration dans Microsoft Entra ID nécessite une approche méthodique : préparer le tenant cible en premier, puis répliquer les paramètres essentiels manuellement dans chaque environnement. Cette séquence évite les erreurs de synchronisation et garantit la cohérence des droits d’accès tout au long de la migration tenant to tenant.
Préparer le tenant cible avant toute configuration
Avant d’enregistrer une application Azure AD pour migration tenant source et cible, il est indispensable de disposer d’un tenant cible opérationnel, avec un compte administrateur global actif. Cette étape préalable conditionne la validité des URI de redirection et des secrets générés ultérieurement. Une fois le tenant cible provisionné, connectez-vous au portail Microsoft Entra ID, accédez à Entra ID > Inscriptions d’applications > Nouvelle inscription, puis renseignez un nom explicite (par exemple : MigrationApp-Source et MigrationApp-Target). Reproduisez ensuite cette opération dans chaque tenant concerné pour disposer de deux enregistrements distincts et symétriques.
Documenter et répliquer les paramètres essentiels
Selon Microsoft Learn, pour migrer des enregistrements d’application il faut les recréer manuellement en répliquant les paramètres dans le tenant cible, notamment les URI de redirection, les autorisations et les paramètres API. (Source : Microsoft Learn — 2025-11-08)
Pour une configuration multi-tenant app pour scénarios de migration réussie, documentez systématiquement les champs suivants dans chaque tenant :
| Paramètre | Tenant source | Tenant cible |
|---|---|---|
| URI de redirection | À définir selon l’outil d’orchestration | Identique ou adaptée |
| Autorisations API | Mail.Read, User.Read.All, Sites.FullControl.All | Identiques |
| Méthode d’authentification | Secret client ou certificat | Secret client ou certificat |
| Type de compte pris en charge | Mono-tenant | Mono-tenant |
Concernant la méthode d’authentification, privilégiez un certificat stocké dans Azure Key Vault plutôt qu’un secret client sécurisé key vault, notamment pour les environnements de production. Azure Key Vault centralise la gestion des secrets et réduit le risque d’exposition accidentelle des credentials. Si le projet impose un secret client, veillez à définir une durée de validité courte et à le renouveler avant chaque phase critique de migration.
Consentement administrateur et rôles nécessaires
Une application d’orchestration de migration M365 requiert le consentement administrateur explicite dans chaque tenant. Sans ce consentement, les appels Graph API échoueront, bloquant le transfert des boîtes aux lettres, des sites SharePoint ou des équipes Teams. Dans le portail Microsoft Entra ID, accédez à Autorisations API > Accorder un consentement administrateur pour chaque tenant. Les rôles minimaux requis sont Administrateur global ou Administrateur d’application pour l’enregistrement, et Administrateur Exchange pour les migrations de messagerie Office 365. Pensez également à vérifier les stratégies de Conditional Access : certaines politiques bloquent par défaut les applications non référencées dans le tenant cible, ce qui peut interrompre le flux d’authentification OAuth2.
Une fois les deux applications enregistrées, les autorisations accordées et les secrets sécurisés dans Azure Key Vault, vous disposez des fondations nécessaires pour configurer les connecteurs de migration et définir les mappages d’identités entre les deux environnements.
Étendre les autorisations et la connectivité cross-tenant
Pour qu’une migration tenant to tenant fonctionne correctement, l’application de service enregistrée dans Microsoft Entra ID doit disposer des autorisations Microsoft Graph API appropriées et bénéficier d’une connectivité inter-locataires explicitement configurée. Ces deux conditions sont non négociables avant tout transfert de données.
Configurer les autorisations d’application pour Exchange, SharePoint et OneDrive
Les autorisations d’application (Application permissions) diffèrent des autorisations déléguées : elles s’appliquent sans présence d’un utilisateur connecté, ce qui est indispensable pour les migrations automatisées. Dans le portail Microsoft Entra ID, accédez à votre enregistrement d’application, puis à API permissions. Ajoutez les autorisations Microsoft Graph suivantes selon le périmètre de migration :
| Service | Permission Graph API | Type |
|---|---|---|
| Exchange Online | Mail.ReadWrite, MailboxSettings.ReadWrite | Application |
| SharePoint | Sites.FullControl.All | Application |
| OneDrive | Files.ReadWrite.All | Application |
| Répertoire | Directory.Read.All, User.Read.All | Application |
Une fois les autorisations ajoutées, un administrateur global du tenant source doit accorder le consentement administrateur (Grant admin consent). Sans cette étape, les appels d’API échoueront avec une erreur 403. Le même processus doit être reproduit côté tenant cible pour l’application de service pour migration cross-tenant dédiée à la destination.
Mettre en œuvre les cross-tenant access settings
Les Cross-tenant access settings dans Microsoft Entra ID permettent de contrôler finement les flux d’authentification et de confiance entre deux organisations. Pour une migration tenant to tenant, accédez à Microsoft Entra ID > External Identities > Cross-tenant access settings, puis ajoutez le tenant partenaire via son identifiant (Tenant ID). Activez l’option Inbound trust côté tenant cible et Outbound trust côté tenant source afin d’autoriser la synchronisation des identités et le transfert de contenu via la migration multi-tenant Microsoft 365.
D’après Microsoft Learn, pour convertir une application single-tenant en application capable d’opérer sur plusieurs locataires, il est nécessaire de mettre à jour l’enregistrement, de basculer vers le point de terminaison /common et de gérer plusieurs émetteurs de tokens (Source : Microsoft Learn — 2024-11-13). Cette configuration s’avère pertinente lorsque l’outil de migration doit s’authentifier auprès des deux tenants simultanément.
Appliquer le principe du moindre privilège et surveiller les journaux
Conformément aux bonnes pratiques de configuration des rôles administrateur pour migration tenant to tenant, limitez les autorisations accordées au strict nécessaire : évitez Global Administrator pour le compte de service et privilégiez des rôles ciblés comme Exchange Administrator ou SharePoint Administrator. Révoquez les permissions dès la fin de la migration.
La vérification des journaux d’activité de l’application dans Azure passe par Azure Monitor et les journaux d’audit de Microsoft Entra ID (Sign-in logs et Audit logs). Configurez une stratégie de rétention adaptée et activez les alertes sur les échecs de consentement ou les appels API anormaux. Ce dispositif garantit la traçabilité exigée par les politiques de gouvernance M365. La prochaine étape consiste à tester l’ensemble de ces paramètres dans un environnement pilote avant de lancer la migration en production.
Tester, valider et maintenir l’application de migration
Avant toute migration en production, un environnement de préproduction dédié permet de vérifier l’intégrité des configurations et de limiter les risques opérationnels. Cette étape structure également la phase de décommissionnement de l’application d’orchestration de migration M365 une fois le projet achevé.
Préparer un environnement de test Entra ID
La validation fonctionnelle commence par la réplication de la configuration cible dans un tenant de test. Il s’agit de recréer les permissions déléguées, les rôles applicatifs et les secrets dans un environnement isolé, sans impact sur les données de production. Les PowerShell Modules tels que Microsoft.Graph et AzureAD facilitent l’automatisation de ces déploiements de test : un script peut provisionner l’application, affecter les consentements admin et simuler les appels API attendus lors de la migration réelle. À noter que, selon Microsoft Learn, le processus de création d’un tenant Microsoft Entra ID peut prendre jusqu’à 30 minutes (Source : Microsoft Learn — 2025-12-24), un délai à anticiper dans le planning de validation. Il convient également de tester les flux d’authentification entre le tenant source et le tenant cible, en vérifiant que l’application de transfert de données Microsoft 365 obtient bien les tokens attendus et que les scopes sont correctement accordés.
Surveiller les journaux de connexion et d’audit
Une fois les tests fonctionnels validés, la journalisation application migration devient le principal levier de détection des anomalies. Les Audit Logs Entra ID enregistrent chaque opération effectuée par l’application : consentements, modifications de rôles, appels aux API Graph. Azure Monitor peut être configuré pour centraliser ces logs et déclencher des alertes en cas d’activité suspecte, comme une volumétrie d’appels inhabituellement élevée ou une tentative d’accès à des ressources hors périmètre.
| Source de log | Type d’événement surveillé | Outil recommandé |
|---|---|---|
| Audit Logs Entra ID | Consentements, modifications de rôles | Portail Microsoft Entra / Azure Monitor |
| Sign-in Logs | Authentifications applicatives, échecs | Azure Monitor, Log Analytics |
| PowerShell Modules | Exécutions de scripts, erreurs API | Azure Automation / journaux locaux |
Les meilleures pratiques sécurité application de migration recommandent de conserver ces logs au minimum 90 jours et de les exporter vers un espace de stockage sécurisé indépendant du tenant source. La documentation officielle de Microsoft sur la migration multi-tenant Microsoft 365 précise les exigences de supervision attendues pendant toute la durée du projet.
Planifier le retrait de l’application post-migration
Le cycle de vie de l’application ne s’arrête pas à la fin des transferts de données. Une fois la migration validée, il est indispensable de révoquer les consentements admin accordés, de supprimer les secrets et certificats, puis de désactiver l’enregistrement applicatif dans les deux tenants. Cette suppression doit être tracée et documentée pour répondre aux exigences de gouvernance. Un script PowerShell automatisant cette séquence de déprovisionnement réduit le risque d’oubli et garantit qu’aucune surface d’attaque résiduelle ne subsiste après la clôture du projet.
La configuration de la supervision étant posée, il reste à examiner comment documenter et communiquer ces choix techniques auprès des équipes métiers et des administrateurs impliqués dans le projet.
Conclusion
Une application de migration Microsoft Entra ID correctement configurée constitue le socle technique de toute opération de migration tenant to tenant réussie. La rigueur apportée à sa création conditionne directement la sécurité et la traçabilité de l’ensemble du projet.
Le principe du moindre privilège reste la règle fondamentale : chaque permission accordée via la Microsoft Graph API doit être strictement nécessaire, documentée et révisée régulièrement. La rotation des secrets applicatifs, idéalement orchestrée via Azure Key Vault, s’inscrit dans une démarche de conformité sécurité durable et répond aux exigences de conformité RGPD et identité cloud. À noter que, selon Microsoft Learn, les domaines personnalisés ne peuvent être vérifiés que dans un seul tenant à la fois, imposant leur retrait de l’ancien tenant avant toute vérification dans le nouveau — un point de vigilance opérationnel à anticiper (Source : Microsoft Learn — 2025-11-08).
Enfin, la gouvernance application de migration Microsoft 365 ne s’arrête pas à la fin du projet : les connecteurs applicatifs de migration Microsoft 365 devenus obsolètes doivent être supprimés de Microsoft Entra ID pour réduire la surface d’attaque. Pour approfondir les mécanismes natifs disponibles, la documentation officielle sur la migration multi-tenant Microsoft 365 constitue une référence incontournable.
