Tenant Microsoft - définition, sécurité et bonnes pratiques

Une entreprise peut utiliser Microsoft 365, Azure, Intune ou Dynamics sans toujours comprendre ce qui relie ces services. Au centre de cet écosystème se trouve le tenant Microsoft, une instance dédiée qui regroupe les identités, les applications, les appareils et les règles d’accès d’une organisation. Je vous explique ici son rôle, la différence avec un abonnement Azure, les étapes de création, les bonnes pratiques de sécurité et les cas où plusieurs tenants peuvent se justifier.

Un tenant Microsoft est bien plus qu’un simple compte d’entreprise

Dans le vocabulaire Microsoft, le tenant est généralement traduit par locataire. Il correspond à une instance isolée de Microsoft Entra ID, le service cloud qui gère les identités et les accès. Microsoft Entra ID était auparavant connu sous le nom d’Azure Active Directory.

Lorsqu’une organisation souscrit à Microsoft 365, Azure, Intune ou Dynamics 365, un annuaire Entra peut être créé ou associé à son environnement. Cet annuaire devient la frontière de confiance de l’entreprise. Il sait qui sont les utilisateurs, quelles applications ils peuvent ouvrir et dans quelles conditions ils peuvent accéder aux données.

J’utilise souvent une comparaison simple. Microsoft fournit l’immeuble cloud, tandis que le tenant représente l’espace sécurisé réservé à une organisation. Deux entreprises peuvent utiliser les mêmes services Microsoft sans partager leurs utilisateurs, leurs règles d’administration ou leurs données professionnelles.

Ce que contient concrètement un environnement Microsoft

Le tenant centralise d’abord les utilisateurs et les groupes. Les groupes de sécurité servent à attribuer des droits, tandis que les groupes Microsoft 365 facilitent la collaboration dans Teams, SharePoint ou Outlook. Cette organisation évite de gérer les autorisations une personne à la fois, ce qui devient vite impraticable au-delà de quelques dizaines de comptes.

Les identités et les appareils

On y trouve aussi les appareils inscrits ou enregistrés, les applications d’entreprise, les applications personnalisées et les comptes invités. Avec Intune, l’entreprise peut relier la gestion des postes à l’identité de l’utilisateur et imposer des règles comme le chiffrement du disque, la présence d’un antivirus ou l’utilisation d’un système à jour.

Les partenaires et prestataires peuvent être ajoutés comme utilisateurs externes. Ils ne deviennent pas automatiquement des employés de l’organisation, mais leur accès doit rester limité à ce dont ils ont besoin. C’est un point souvent négligé dans les petites structures, alors que les anciens comptes invités peuvent rester actifs pendant des mois.

Les applications et les droits

Chaque application qui utilise l’authentification Microsoft peut être enregistrée dans le tenant. L’administrateur définit ensuite les utilisateurs autorisés, les permissions demandées et les règles de connexion. Une application peut donc être disponible pour toute l’entreprise, pour un groupe précis ou uniquement pour quelques administrateurs.

Les rôles d’administration doivent être séparés. Le rôle d’administrateur global donne un contrôle très large sur l’environnement et ne devrait pas être utilisé pour les tâches quotidiennes. Je recommande plutôt des rôles spécialisés, comme administrateur des utilisateurs, administrateur Intune ou lecteur de sécurité, selon les responsabilités réelles de chaque personne.

Tenant, abonnement Azure et licence ne désignent pas la même chose

La confusion entre ces trois notions provoque beaucoup d’erreurs de conception. Un tenant définit l’organisation et ses identités, un abonnement Azure regroupe des ressources et des coûts, tandis qu’une licence détermine les fonctionnalités accessibles à un utilisateur ou à un appareil.

Une même organisation peut posséder plusieurs abonnements Azure dans un seul tenant. Elle peut ainsi séparer la production, les tests et les différents services tout en conservant un annuaire commun. À l’inverse, deux organisations distinctes peuvent utiliser des tenants séparés même si elles travaillent avec des technologies Microsoft identiques.

Il existe un niveau gratuit de Microsoft Entra ID, mais les fonctionnalités avancées, notamment certaines fonctions de gouvernance, de protection des identités ou d’accès conditionnel, peuvent nécessiter des licences spécifiques. Il faut donc distinguer le coût de l’environnement lui-même et celui des services activés à l’intérieur.

Créer ou retrouver son tenant sans se tromper

La création d’un tenant est relativement rapide. La vraie difficulté consiste à prendre les bonnes décisions de nommage et d’architecture avant de commencer à distribuer des comptes et des licences.

1. Définir l’organisation et vérifier qu’un environnement Microsoft 365 ou Entra n’existe pas déjà.
2. Choisir le nom initial, qui donnera une adresse du type entreprise.onmicrosoft.com.
3. Sélectionner le pays ou la région avec soin, car ce choix peut influencer la facturation, le catalogue disponible et certaines options de résidence des données.
4. Ajouter le domaine personnalisé, par exemple entreprise.fr, après avoir réalisé la vérification DNS demandée.
5. Configurer les administrateurs, les rôles, la sécurité et les méthodes de récupération avant de créer tous les utilisateurs.

Le domaine initial en .onmicrosoft.com reste associé au tenant, même si le domaine principal de l’entreprise devient ensuite personnalisé. Il vaut donc mieux choisir un nom propre, durable et compréhensible, surtout si l’environnement doit servir pendant plusieurs années ou accueillir plusieurs filiales.

Lire aussi : Migration Exchange vers Microsoft 365 - Quelle méthode choisir ?

Retrouver le Tenant ID

Pour identifier l’environnement utilisé, ouvrez le centre d’administration Microsoft Entra, puis consultez la page de présentation et les propriétés du tenant. Le Tenant ID apparaît sous la forme d’un identifiant alphanumérique long.

Ce numéro est différent du nom de l’organisation, du domaine de messagerie et de l’identifiant d’abonnement Azure. Il n’est pas secret, mais je conseille de le conserver dans la documentation technique, car il est souvent demandé lors de la configuration d’une application, d’une automatisation ou d’une connexion entre services.

Les équipes techniques peuvent aussi retrouver cette information avec des outils en ligne de commande comme Get-AzTenant ou les commandes Azure CLI. Pour un utilisateur non technique, l’interface Entra reste toutefois la méthode la plus simple et la plus sûre.

Sécuriser un tenant Microsoft au quotidien

Un tenant mal protégé peut donner accès à la messagerie, aux fichiers, aux applications et parfois aux ressources Azure. La sécurité ne doit donc pas commencer après le déploiement. Elle doit être préparée avant l’arrivée des utilisateurs.

• Activer l’authentification multifacteur pour les administrateurs en priorité, puis pour l’ensemble des utilisateurs.
• Utiliser l’accès conditionnel pour demander une authentification renforcée selon le lieu, l’appareil, le niveau de risque ou l’application.
• Limiter les privilèges en attribuant uniquement les rôles nécessaires à chaque fonction.
• Prévoir deux comptes d’urgence, protégés et surveillés, afin de conserver un accès en cas de panne d’un mécanisme d’authentification.
• Réviser les comptes invités et supprimer les accès qui ne correspondent plus à une mission active.
• Consulter les journaux de connexion et d’audit pour repérer les comportements inhabituels.

La règle la plus rentable reste la séparation entre le compte d’administration et le compte de travail quotidien. Un administrateur qui consulte ses e-mails avec un compte possédant des privilèges globaux augmente inutilement l’impact potentiel d’une attaque par hameçonnage.

J’accorde également beaucoup d’importance à la documentation. Notez les domaines vérifiés, les comptes d’urgence, les rôles attribués, les applications connectées et les personnes responsables. Sans cette cartographie, une organisation peut continuer à payer des licences ou à laisser des accès actifs sans savoir pourquoi.

Un seul tenant ou plusieurs environnements séparés

Dans la majorité des entreprises, un tenant unique est plus simple à administrer. Les utilisateurs collaborent plus facilement, les règles de sécurité sont centralisées et la gestion de Teams, SharePoint et OneDrive reste cohérente.

Plusieurs tenants peuvent cependant être pertinents pour une fusion-acquisition, une séparation juridique, une filiale totalement indépendante, un environnement de test ou des exigences réglementaires particulières. Cette approche crée une séparation plus nette, mais elle complique les comptes invités, la collaboration, la supervision et les migrations.

Créer plusieurs tenants pour corriger un simple problème de droits est rarement une bonne idée. Dans ce cas, les groupes, les rôles délégués et les stratégies d’accès conditionnel suffisent souvent. Je réserverais le multi-tenant à une véritable contrainte d’organisation, de sécurité ou de gouvernance.

Les vérifications utiles avant de faire évoluer votre environnement

Avant d’ajouter une nouvelle filiale, de migrer une messagerie ou de connecter une application sensible, je vérifierais d’abord à qui appartient le tenant, qui possède le rôle d’administrateur global et quels domaines sont déjà validés.

• Existe-t-il déjà un tenant Microsoft 365 ou Entra pour la même organisation ?
• Les domaines de messagerie sont-ils rattachés au bon environnement ?
• Les comptes administrateurs utilisent-ils l’authentification multifacteur ?
• Les abonnements Azure et leurs ressources sont-ils correctement documentés ?
• Les utilisateurs externes et les applications anciennes sont-ils encore nécessaires ?

Un tenant bien pensé n’est pas celui qui contient le plus de réglages. C’est celui dont les responsabilités, les accès et les limites sont clairs. Avec un nommage cohérent, une sécurité de base solide et une documentation tenue à jour, l’écosystème Microsoft devient beaucoup plus simple à faire évoluer sans perdre le contrôle.