Indispensables au fonctionnement du site (session, préférences, sécurité). Toujours actifs.
Azure Lighthouse : pourquoi l’organisation d’un MSP n’est pas un tenant
Azure Lighthouse de Microsoft permet à un MSP de gérer plusieurs tenants clients depuis son propre tenant sans fusionner les annuaires — un modèle à connaître avant de confondre organisation et tenant.
Azure Lighthouse est le modèle documenté par Microsoft qui permet à un fournisseur de services gérés de travailler sur les ressources Azure de nombreux clients depuis son propre tenant, sans fusionner l’annuaire d’un client dans celui du MSP. Microsoft appelle cela la gestion déléguée des ressources Azure : un client délègue des abonnements ou des groupes de ressources spécifiques à des utilisateurs et des rôles précis dans le tenant du MSP, et peut révoquer cet accès de façon indépendante à tout moment.

Comment fonctionne réellement la délégation
Sous le capot, l’intégration d’un client crée deux ressources dans le propre tenant du client : une définition d’inscription, qui décrit l’accès accordé et à qui, et une affectation d’inscription, qui l’active. Lorsqu’une personne du tenant du MSP tente d’agir sur une ressource déléguée, Azure Resource Manager authentifie cette demande de la même manière qu’il authentifie une demande d’un utilisateur natif du tenant du client — l’utilisateur du MSP n’a jamais besoin d’un compte dans l’annuaire du client et n’en devient jamais copropriétaire. Les clients conservent la visibilité sur ce qui a été délégué et peuvent le voir depuis leur propre portail.
Pourquoi la terminologie prête à confusion
Les propres recommandations de Microsoft sont explicites : « organisation » et « tenant » ne sont pas interchangeables : une seule organisation commerciale — une marque, une entité juridique — peut s’étendre sur de nombreux tenants Microsoft Entra, un par client, par environnement ou par acquisition. Lighthouse est construit autour de cette réalité plutôt que contre elle : il permet à une organisation d’opérer entre plusieurs tenants tout en faisant de chaque tenant une frontière stricte pour l’identité et l’accès. Effacer cette distinction — traiter « notre organisation » comme si elle était un seul tenant — est l’erreur que l’architecture de Lighthouse est conçue pour empêcher, pas seulement pour documenter.
Pour les MSP qui construisent ou achètent des outils multi-tenant, de quelque nature que ce soit, Azure Lighthouse est un point de référence utile : l’accès délégué et révocable à un tenant distinct est une conception différente, et généralement plus sûre, que de regrouper plusieurs clients sous un annuaire partagé et de les distinguer avec des indicateurs au niveau applicatif. La distinction est architecturale, pas une étiquette de conformité — il vaut la peine de la vérifier dans le modèle d’accès réel de tout fournisseur, pas seulement dans son discours marketing.
Sources : Microsoft Learn — What is Azure Lighthouse?, Microsoft Learn — Tenants, users, and roles in Azure Lighthouse.