Office 365 est un formidable outil cloud qui centralise la base des infrastructures de services requises pour une entreprise tel que la messagerie, le stockage de documents et bien d’autres. Sa facilité de mise en place et ses avantages en termes de coûts sont en parties responsables de son déploiement massif ces dernières années dans les entreprises de toutes tailles.
Lors d’un rachat ou d’une fusion de deux entreprises qui possèdent chacune un tenant Office 365 vient la question de l’uniformisation des SI.
Deux scénarios sont généralement mis en avant :
- Conserver les deux tenants et mettre en œuvre des interactions techniques et une gouvernance entre les tenants
- Fusionner en ne gardant qu’un seul tenant pour l’ensemble des collaborateurs et conserver une gouvernance unique
Que se passe-t-il si je ne souhaite pas unifier les tenants ?
Dans l’hypothèse où vous ne souhaitez pas unifier l’ensemble des utilisateurs sur un même tenant, vous devez prendre conscience que vos utilisateurs auront des difficultés pour collaborer entre les tenants. Ceci est principalement dû au fait que les tenants sont perçus comme deux entreprises distinctes au niveau technique et de fait héritent de deux stratégies indépendantes.
Gestion de l’identité
D’un point de vue utilisateur, pour interagir avec chaque tenant, ils devront s’appuyer soit sur :
- Un compte sur chaque tenant
- L’utilisation du mécanisme “d’invité” (ou “guest”), qui permet d’inclure des collaborateurs extérieurs dans l’annuaire Azure Active Directory de l’organisation et ainsi pouvoir être ajouté sur les services d’ordinaire réservés aux internes comme SharePoint ou Teams
Il est crucial pour les utilisateurs d’avoir une expérience aussi transparente que possible, au regard de l’authentification aux services.
Avoir de multiples identités pour les utilisateurs va apporter de la confusion ; sans parler des problèmes de gouvernance engendrés par la question de la domiciliation des données sur un tenant ou l’autre. Dans un fonctionnement ou les deux parties sont des partenaires occasionnels, le mécanisme des invités peut suffire à répondre aux problématiques de collaborations. Il faut cependant garder à l’esprit que ceci ne résout pas la problématique d’avoir un annuaire commun aux organisations.
Accès aux services
Il faut savoir que les utilisateurs internes et les utilisateurs dit invité n’ont pas le même niveau de droits vis-à-vis des services. On notera par exemple qu’un utilisateur invité présente des limitations par défaut (il ne peut pas être défini comme propriétaire d’un site SharePoint ou d’une équipe Microsoft Teams par exemple).
Ceci peut s’avérer bloquant pour la conception d’une stratégie de permission inter-tenant.
Messagerie
Comme évoqué précédemment concernant la gestion de l’identité, les annuaires Azure Active Directory des deux tenants n’étant pas unifiés, l’annuaire du service de messagerie souffre du même problème. Il ne sera par exemple pas possible d’effectuer une recherche rapide du destinataire lors de la rédaction d’un mail lorsque le destinataire ne se trouve pas dans le même tenant.
Une solution consiste à s’appuyer sur un provisionnement programmatique de fiches de contacts dans chaque tenant pour y inclure les contacts du tenant opposé.
Cette solution, bien que répondant aux besoins, peut rapidement devenir une usine à gaz sur la durée et un casse-tête en termes de maintenance.
Microsoft Teams
En ayant deux tenants séparés, l’expérience de collaboration à l’intérieur des équipes Microsoft Teams ne sera pas équivalente pour les internes et pour les invités.
Les invités devront basculer entre le réseau Teams de leur tenant d’origine et le réseau Teams du tenant dans lequel ils sont invités. À l’heure actuelle, les notifications de Teams sont propres au réseau sur lequel on est actuellement connecté. Ce qui veut dire que l’utilisateur devra jongler entre les réseaux afin de vérifier la présence éventuelle de notifications. Ceci est au quotidien très peu pratique si on est amené à échanger de manière intensive avec des utilisateurs de chaque tenant.
Comme mentionné plus haut, un invité ne peut être défini comme propriétaire d’une équipe Teams, ce qui veut dire par exemple qu’un invité ne pourra pas personnaliser une équipe Teams.
Partage de fichier
Le partage de fichiers est, à mon sens, l’aspect le plus dangereux en termes d’échec d’adoption par les utilisateurs : le partage vers l’utilisateur provenant de l’autre tenant sera fait sur son identité « invité » ou suivant le contexte sur l’identité « externe » ; ce qui lui demandera une validation en 2 étapes à chaque fois qu’il cherchera à accéder au dit document partagé.
Cette expérience au quotidien est loin d’être idéale pour les utilisateurs.
Domiciliation et propriété des données
Dans le cas où l’information est éclatée entre les 2 tenants, des questions vont apparaître comme par exemples :
- Dans quel tenant devrait être domicilié tel ou tel donnée ?
- Dans quel tenant devrait être hébergé tel ou tel portail SharePoint ?
Si on part du principe que la domiciliation dans un tenant implique la propriété de la donnée, un nouveau problème émerge quant à l’éventualité d’un rachat d’une des entités et par conséquent de l’accès aux données entreposées sur le tenant associé pour l’entité opposé.
Couplé au fait que le choix de la domiciliation des données sera donné à l’utilisateur final, sans contrôle possible de la part des équipes IT.
Stratégies de sécurité
Avoir deux tenants séparés signifie avoir deux stratégies de sécurités séparées également.
Dans le monde de la sécurité, le niveau est défini par le maillon le plus faible de la chaîne.
Pour une organisation, c’est un point prioritaire et par conséquent il est difficilement concevable de permettre un niveau plus laxiste pour une entité vis à vis d’une autre. Ceci oblige l’organisation au sens large à faire appliquer et maintenir un front commun sur la politique de sécurité sur tous les tenants.
Dans cette situation, avoir plusieurs tenants peut induire des challenges d’implémentation de stratégies : gestion des accès, sécurisation de la méthode d’accès ou encore cryptage des données.
Réseau social
Chaque tenant Office 365 dispose de son propre réseau social à travers le produit Yammer. Avoir des tenants séparés implique qu’il n’est pas possible de rassembler l’ensemble des collaborateurs de l’organisation, toutes entités confondues, à l’intérieur d’un même réseau social.
Dans quelle situation voudrais-je conserver les deux tenants de manière séparé ?
D’un point de vue des outils de productivité, cette approche peut être viable dans le cas où le rachat est purement administratif et n’implique pas de fusion au niveau des équipes de collaborateurs.
Les deux entités continuent de fonctionner de façon complètement autonome comme deux entreprises distinctes et n’ont pas d’exigences particulières en termes de collaboration ou d’uniformisation des systèmes.
Dans quelle situation voudrais-je unifier les tenants ?
Dans le cas où les deux parties prévoient de fusionner et mutualiser des services ou des ressources.
Conserver les deux tenants va présenter des challenges en termes d’intégration ; ce qui se traduira par une expérience utilisateur difficile à appréhender lorsque ça impliquera des interactions entre les deux tenants.
Un bon exemple est l’utilisation de Microsoft Teams entre deux tenant, l’équipe Teams sera domiciliée sur l’un des tenants et les utilisateurs devront jongler entre l’identité de leur tenant d’origine et l’identité en mode invité de l’autre tenant, en fonction de l’équipe Teams qu’ils souhaitent atteindre.
Si vous avez des questions ou avez en projet d’unifier des tenants, nos équipes d’experts sont là pour vous accompagner.
N’hésitez pas à visiter notre site dédié aux sujets du Modern Workplace avec Microsoft 365.
