Cross Tenant Synchronisation : comment ça marche ?

Introduction

Votre entreprise vient de racheter une filiale. Ou vous pilotez un programme multi-entités. Dans les deux cas, le constat est le même : chaque organisation a son propre tenant Microsoft 365, et faire collaborer vos équipes de façon fluide et sécurisée devient un casse-tête opérationnel. Invitations B2B manuelles, doublons dans l’annuaire, confusion entre contacts guest et externes, tickets de support qui s’accumulent… Ce scénario, tout DSI en contexte de fusion-acquisition le connaît bien.

La bonne nouvelle : Microsoft propose depuis 2023 une solution native, scalable et gouvernée pour répondre exactement à ce problème. Elle s’appelle le Cross Tenant Sync. Dans la terminologie officielle Microsoft, il s’agit de la synchronisation inter-locataires. Et elle change radicalement la manière de faire collaborer deux tenants Microsoft 365.

Cet article, appuyé sur un retour d’expérience en production sur 40 000 utilisateurs, vous donne toutes les clés pour évaluer, déployer et gouverner cette solution.

La complexité d’une synchronisation cross tenant

Les problèmes concrets d’une coexistence sans solution dédiée

Dans un monde idéal, deux entreprises qui fusionnent migreraient immédiatement vers un tenant unique. Dans la réalité, une migration inter-tenants sur un périmètre de plusieurs milliers d’utilisateurs prend entre 3 et 4 ans, entre la phase de préparation et le basculement en production. Pendant toute cette période, les équipes ont pourtant besoin de collaborer, de partager des fichiers, de se retrouver dans Teams, de consulter les disponibilités de leurs collègues.

Sans outil structuré pour gérer la coexistence, les frictions s’accumulent rapidement et pèsent à la fois sur les utilisateurs et sur les équipes IT :

Duplication des identités dans les annuaires des deux tenants, difficile à maintenir à jour manuellement.
Confusion entre comptes guest et contacts externes dans Outlook, avec le risque d’envoyer un e-mail à une adresse guest qui n’a pas de boîte de réception derrière.
Processus d’invitation B2B chronophage : chaque accès à une nouvelle ressource génère une nouvelle invitation, souvent bloquée en spam ou ignorée.
Expérience utilisateur dégradée : les collaborateurs ne savent pas toujours s’ils ont bien été invités, ni comment accéder aux espaces partagés.
Coûts d’administration élevés : les équipes IT passent un temps significatif à gérer manuellement des accès qui devraient être automatisés.

Les limites des alternatives existantes : B2B manuel et scripts PowerShell

Avant le Cross Tenant Sync, deux approches existaient. Chacune a ses limites.

La première est l’Azure B2B classique. Le principe : inviter manuellement les utilisateurs distants en tant que guests. Ça fonctionne à petite échelle. Mais ça ne passe pas à l’échelle. Chaque invitation nécessite une action manuelle. Et sur de gros volumes, la gouvernance de ces comptes guests devient vite ingérable.

La seconde approche repose sur des scripts PowerShell sur mesure. Ils permettent d’automatiser une partie du processus. Mais ils génèrent une dette technique lourde. Et une dépendance forte aux équipes qui les ont développés. Ce n’est pas une solution durable ni gouvernable pour une DSI.

La solution Cross Tenant Sync : fonctionnement et bénéfices

Les trois composantes du Multitenant Organization

Déployé en preview par Microsoft en janvier 2023 et mis en disponibilité générale mi-2023, le Cross Tenant Sync s’inscrit dans une fonctionnalité plus large appelée Multitenant Organization (MTO). C’est aujourd’hui la brique principale de ce dispositif, et la réponse la plus structurée que Microsoft ait proposée pour faire collaborer deux tenants Microsoft 365 de façon automatisée et gouvernée.

Le Multitenant Organization repose sur trois piliers complémentaires, qu’il est important de distinguer pour bien comprendre ce que le Cross Tenant Sync apporte spécifiquement :

La fédération Teams : elle permet aux utilisateurs des deux tenants de communiquer via Teams et de consulter mutuellement les disponibilités (free/busy). C’est le socle minimal de collaboration.
Le Cross Tenant Sync : la brique centrale. Elle automatise la création, la mise à jour et la suppression des utilisateurs synchronisés d’un tenant vers l’autre, via Microsoft Entra ID Provisioning et Azure B2B. C’est elle qui élimine les processus manuels d’invitation.
La fusion des contacts dans la Global Address List : elle résout un problème souvent sous-estimé, la double entrée dans l’annuaire (compte guest ET contact externe) qui génère des erreurs d’envoi de mails chez les utilisateurs finaux.

Comment fonctionne concrètement le Cross Tenant Sync ?

Le principe est simple : un tenant source synchronise automatiquement ses utilisateurs vers un ou plusieurs tenants cibles. Cette synchronisation peut être unidirectionnelle (A vers B) ou bidirectionnelle (A vers B et B vers A). Dans la pratique, et notamment dans le contexte d’une collaboration entre deux entités de taille équivalente, la synchronisation bidirectionnelle est généralement retenue.

La solution offre une granularité fine sur ce qui est synchronisé :

Le scope des utilisateurs et des groupes à synchroniser (par département, par entité, par profil métier).
Les attributs à transmettre au tenant cible (département, société, titre…) qui servent ensuite à créer des groupes dynamiques pour automatiser les accès applicatifs.
Le sens de la synchronisation : unilatéral ou bidirectionnel selon les besoins.
Un provisioning à la demande, pour forcer manuellement la synchronisation d’un utilisateur spécifique hors cycle automatique.

Bénéfices du Cross Tenant Sync pour les utilisateurs et la DSI

Pour les utilisateurs finaux : la fin des frictions

L’impact le plus immédiat se mesure du côté des utilisateurs. Avant le Cross Tenant Sync, le parcours utilisateur était laborieux. Il fallait attendre une invitation. Cliquer sur un lien. Accepter une demande de consentement. Et souvent contacter le support quand quelque chose bloquait.

Avec le Cross Tenant Sync, tout cela disparaît. Les utilisateurs sont automatiquement provisionnés dans les bonnes équipes Teams et les bons espaces SharePoint. Ils peuvent collaborer immédiatement, sans aucune action de leur part.

Autre avantage visible : dans Teams, les utilisateurs d’un tenant distant ne sont plus identifiés comme « externes » dès lors qu’ils ont été passés au statut member (voir plus bas). L’expérience est quasi identique à celle d’un collègue interne.

Pour la DSI : réduction des coûts et gouvernance renforcée

Du point de vue de la DSI, les gains sont concrets et mesurables :

Fin des processus manuels d’invitation B2B et des scripts à maintenir.
Chaque utilisateur est créé, mis à jour ou supprimé automatiquement selon l’état du tenant source.
Les attributs synchronisés (département, société, etc.) permettent de créer des groupes dynamiques dans le tenant cible, membres de Teams ou de sites SharePoint. La gestion des accès devient automatisée et cohérente.
Réduction significative des tickets de support liés aux problèmes d’accès et d’invitation.
Administration centralisée depuis le portail Microsoft Entra ID, avec des logs de synchronisation intégrés.

Pour les chefs de projet : un accélérateur de transformation

Dans un projet de fusion-acquisition, le Cross Tenant Sync change la nature même du chantier collaboration. Plutôt que de passer des semaines à provisionner manuellement des accès applicatifs, les équipes projet peuvent se concentrer sur les enjeux métiers. Un projet inter-entités qui aurait pris plusieurs mois à démarrer opérationnellement se met en route en quelques jours une fois le Cross Tenant Sync en place.

REX : déploiement du Cross Tenant Sync sur 40 000 utilisateurs Microsoft 365

Les enjeux

Le déploiement dont il est question ici concernait deux sociétés de leasing automobile appartenant à un grand groupe bancaire. Quelques chiffres pour cadrer le contexte :

40 000 utilisateurs répartis sur deux tenants de taille équivalente (~20 000 de chaque côté).
Synchronisation configurée dans les deux sens.
Exigences de sécurité élevées, héritées du groupe bancaire auquel appartiennent les deux entités.
Déploiement réalisé en plusieurs phases : POC sur tenants de test, puis mise en production progressive.

Toujours commencer par un POC sur des tenants de test

Avant tout déploiement en production, les deux entités disposaient de tenants de test. Le POC a été réalisé à petite échelle sur ces environnements. Il s’agit d’une étape indispensable pour valider le mapping des attributs, le comportement des groupes dynamiques et détecter d’éventuels conflits de configuration. Sur des contextes complexes comme celui-ci, un POC bien conduit fait économiser des semaines de débogage en production.

La première synchronisation : anticiper le délai de go-live

Point d’alerte critique pour tout DSI qui planifie un go-live : la première synchronisation, celle qui crée l’ensemble des identités dans le tenant distant, est beaucoup plus longue que les cycles suivants. Sur 40 000 utilisateurs, après avoir activé la synchronisation en production, rien ne s’est passé pendant les premières heures. Ce n’est que le lendemain après-midi que les utilisateurs invités sont apparus dans les deux tenants respectifs : 16 heures en tout.

En régime normal, la synchronisation tourne toutes les 2 heures et dure environ 40 minutes. Ce point est souvent une source de stress lors du go-live, surtout pour des équipes habituées aux délais d’Azure AD Connect. Il est impératif d’anticiper ce délai dans le plan de déploiement et de communiquer clairement auprès des équipes concernées.

Le statut guest vs member : une distinction à ne pas négliger

Par défaut, les utilisateurs synchronisés arrivent dans le tenant cible avec le statut guest. Ce statut est plus restrictif : un guest ne peut pas être propriétaire d’une équipe Teams, ni créer des shared channels. Pour une vraie expérience de collaboration, il est généralement nécessaire de les faire passer au statut member.

Cette bascule peut se faire de deux façons. Soit via un mapping d’attributs directement dans la configuration du Cross Tenant Sync (l’attribut userType est mappé à « member » côté cible). Soit via un script PowerShell développé en interne. Dans les deux cas, c’est un point à prévoir en amont de la mise en production, et non à traiter après coup.

La limite des 130 applicatifs : un écueil à connaître

Un écueil inattendu a été rencontré en cours de projet. Au-delà d’un certain nombre d’applications autorisées (environ 130 au moment des faits), l’interface d’administration refusait d’en ajouter de nouvelles sans message d’erreur explicite. Après escalade jusqu’à l’équipe produit Microsoft, il s’est avéré que cette limite était by design.

La solution de contournement : jouer sur la configuration du tenant cible pour autoriser les accès non explicitement bloqués. Cela évite de tout lister positivement côté source. Ce comportement a très probablement évolué depuis, Microsoft étant particulièrement réactif sur ce produit. Mais il illustre l’importance de tester les cas limites avant la mise en production.

Pour aller plus loin : Plan de migration vers Microsoft 365 : par quoi démarrer ?

Sécurité du Cross Tenant Sync : accès conditionnel et confiance inter-tenants

La confiance inter-tenants et le jeton MFA

Le Cross Tenant Sync permet de configurer le niveau de confiance accordé au tenant partenaire.

Prenons un exemple concret. Un utilisateur du tenant A s’est déjà authentifié avec MFA dans son environnement natif. Si le tenant B fait confiance au jeton MFA du tenant A, cet utilisateur n’aura pas à refournir une preuve d’identité pour accéder aux ressources de B. L’expérience utilisateur s’en trouve simplifiée.

Mais cette confiance a une condition. Les deux tenants doivent appliquer un niveau de sécurité équivalent sur la délivrance de leurs jetons. Sans cet alignement, on abaisse le niveau de sécurité global, ce qui est inacceptable dans des environnements régulés.

Aligner les politiques d’accès conditionnel des deux côtés

Dans le contexte bancaire évoqué, l’une des entités autorisait le BYOD (Bring Your Own Device) tandis que l’autre l’interdisait. Avant d’établir une relation de confiance inter-tenants, il a fallu réunir les deux équipes de sécurité pour homogénéiser les exigences. Le résultat : aucun appareil personnel non géré ne peut accéder aux ressources du tenant le plus restrictif, quelle que soit l’entité d’origine de l’utilisateur.

Cette étape, souvent perçue comme une formalité, est en réalité l’une des plus structurantes du projet. Elle nécessite un vrai sponsoring DSI des deux côtés pour aboutir dans des délais raisonnables.

Supervision et logs du Cross Tenant Sync

Le Cross Tenant Sync intègre des logs de synchronisation accessibles depuis Entra ID. A savoir : les erreurs par utilisateur, statut des cycles, logs de provisioning. Il est aujourd’hui possible de connecter Microsoft Sentinel pour une supervision en temps réel. Les logs ne sont pas toujours très explicites en cas d’erreur et nécessitent parfois une analyse complémentaire. Mais la traçabilité de base est là, et elle s’est nettement améliorée depuis les premières versions en preview.

Gouvernance du Cross Tenant Sync Microsoft 365 : bonnes pratiques et conventions

Cartographier les besoins avant de tout ouvrir

La tentation est grande d’ouvrir tous les accès dès le départ pour faciliter la vie des utilisateurs. C’est une erreur. La bonne approche : cartographier précisément quelles populations ont besoin d’accéder à quels applicatifs. Puis démarrer avec un périmètre restreint. Uniquement les services Microsoft 365 strictement nécessaires — Teams, SharePoint, Power BI selon les profils. Et élargir progressivement, au rythme des besoins réels.

Sur le projet décrit ici, c’est exactement ce qui a été fait. Le périmètre initial était volontairement limité. Il a ensuite été étendu à 147 applications au fil des mois.

Conventions de nommage et communication utilisateurs

Deux autres points de gouvernance à ne pas négliger :

Conventions de nommage : les groupes dynamiques créés à partir des utilisateurs synchronisés doivent suivre les mêmes conventions de nommage que le reste de l’environnement Microsoft 365. Si cette cohérence n’est pas imposée dès le départ, la prolifération de groupes mal nommés génère une dette technique difficile à résorber.

Communication utilisateurs : le Cross Tenant Sync change le quotidien des collaborateurs. Il faut leur expliquer qu’ils vont être automatiquement provisionnés dans certains espaces, leur montrer comment switcher de tenant dans Teams, et anticiper les questions sur les accès. Une communication proactive avant le go-live réduit considérablement les tickets de support.

Cross Tenant Sync : ROI, licences Entra ID P1 et pérennité de la solution

Scénarios

Deux situations distinctes appellent des réponses différentes. Le Cross Tenant Sync s’adapte aux deux :

Contexte fusion-acquisition avec migration planifiée : le Cross Tenant Sync assure la coexistence pendant les 3 à 4 ans que prend en moyenne un projet de migration inter-tenants à grande échelle. Il permet aux équipes de collaborer efficacement durant toute cette période, sans attendre la migration pour être opérationnelles.
Partenaire stratégique récurrent : ici, le Cross Tenant Sync n’est pas une étape vers une migration. C’est la solution définitive, installée dans la durée pour une collaboration quotidienne sécurisée et gouvernée.

Le coût des licences : un point à ne pas sous-estimer

Le Cross Tenant Sync nécessite une licence Microsoft Entra ID P1 (anciennement Azure AD Premium P1). Attention : la licence doit couvrir chaque utilisateur bénéficiant de la synchronisation. A savoir un par utilisateur, pas seulement une licence pour ouvrir le service. Sur des périmètres importants, cette exigence peut représenter un poste budgétaire significatif à intégrer dès la phase d’évaluation.

Quel ROI selon la taille de l’organisation ?

La question du retour sur investissement mérite d’être posée honnêtement selon le contexte :

Plus de 1 000 utilisateurs concernés : le ROI est quasi systématiquement positif. Le gain sur les coûts d’administration, la réduction des tickets de support et l’accélération des projets inter-entités compensent largement le coût des licences.
Entre 500 et 1 000 utilisateurs : le calcul dépend de la durée de coexistence prévue et de l’intensité de la collaboration. Un POC permet souvent de trancher rapidement.
Moins de 500 utilisateurs avec une migration à moins d’un an : la question peut légitimement se poser. Le coût des licences sur une courte période peut ne pas justifier l’investissement si la migration est imminente.

Checklist : les facteurs clés de succès d’un projet Cross Tenant Sync

Le Cross Tenant Sync est aujourd’hui la solution la plus mature, la plus native et la mieux intégrée pour faire collaborer deux tenants Microsoft 365. Microsoft fait évoluer le produit rapidement et est particulièrement réactif sur ce sujet. Ce qui est rare et notable pour un outil de cette nature.

Les facteurs clés de succès d’un déploiement réussi :

Obtenir un sponsoring DSI clair des deux côtés. C’est un prérequis pour avancer sur les sujets de sécurité et de gouvernance.
Réaliser un POC sur des tenants de test avant tout passage en production.
Anticiper le délai de la première synchronisation (jusqu’à 16h sur 40 000 utilisateurs) dans la planification du go-live.
Aligner les politiques d’accès conditionnel entre les deux tenants avant d’établir la relation de confiance.
Démarrer avec un périmètre applicatif restreint et l’élargir progressivement selon les besoins réels.
Gérer le statut guest/member dès la configuration pour éviter les frustrations utilisateurs.
Prévoir le budget licences Entra ID P1 par utilisateur concerné.
Communiquer auprès des utilisateurs finaux avant le déploiement.

Sur des contextes de grande envergure, en contexte de fusion-acquisition ou de collaboration inter-entités durable, le Cross Tenant Sync Microsoft 365 n’est plus une option. C’est l’infrastructure de collaboration qui permet à vos équipes de travailler ensemble le temps que la stratégie SI prenne sa forme définitive, et parfois, bien au-delà.