Documentation des opérations Microsoft 365

EasyTenant réunit dans une seule console les opérations Microsoft 365 que vous menez au quotidien pour vos clients. Au lieu d’ouvrir le portail d’administration de chaque tenant, vous travaillez depuis une interface unique, en français, et l’application agit sur le tenant que vous avez sélectionné.

Chaque action s’exécute avec les autorisations que le client a accordées à l’application, jamais avec vos identifiants personnels. Vous ne voyez et ne pilotez que les tenants rattachés à votre organisation.

Au premier accès, connectez-vous avec votre compte Microsoft professionnel : c’est lui qui vous identifie, l’application ne stocke jamais de mot de passe. Vous créez ensuite votre organisation, dont vous devenez le propriétaire.

Avant toute opération, l’abonnement doit être actif : souscrivez-le dans Paramètres → Facturation. Tant qu’il ne l’est pas, la console vous redirige vers cette page.

Il reste à rattacher un premier tenant client depuis « Ajouter un tenant client » sur le tableau de bord et, si vous travaillez à plusieurs, à inviter vos techniciens dans Paramètres → Équipe.

Pour qu’un tenant apparaisse dans la console, un administrateur du client doit autoriser l’application une première fois. Depuis le tableau de bord, le propriétaire du compte lance « Ajouter un tenant client » : il obtient un lien de consentement à suivre lui-même s’il en a les droits, ou à transmettre à l’administrateur du tenant.

Côté client, le lien ouvre une page guidée EasyTenant, valable 1 jour et à usage unique : l’administrateur s’y connecte avec un compte administrateur général, approuve le consentement, puis attribue les trois rôles d’annuaire — deux connexions Microsoft en tout, rien de plus ne lui est demandé. Pour le rassurer : l’application ne réclame que les autorisations strictement nécessaires, sans accès au contenu des e-mails ni aux fichiers ; aucun accès permanent n’est conservé, les jetons sont de courte durée et jamais stockés ; les rôles Exchange peuvent mettre jusqu’à une heure à devenir effectifs.

Le consentement accorde les permissions nécessaires. Pour les opérations sensibles (mot de passe, 2FA, gestion des comptes), Microsoft exige en plus l’attribution de rôles d’annuaire à l’application. L’assistant « Ajouter un tenant client » enchaîne cette attribution juste après le consentement. Si elle échoue ou reste incomplète, la page du tenant affiche « Dépannage » : rôles manquants et script PowerShell en repli. Sans ces rôles, les actions concernées sont refusées par Microsoft.

L’état du tenant s’affiche sous forme de pastille : rouge « Consentement inactif » tant que le consentement n’est pas accordé, orange « Configuration incomplète » une fois le consentement actif mais des rôles manquants, verte « Prêt » quand tout est en place. Une pastille grise « Rôles à vérifier » signifie que l’application ne peut pas déterminer l’état des rôles — voir « Problèmes fréquents ».

Le compte distingue deux niveaux d’accès. Le propriétaire dispose de toutes les autorisations et gère la facturation, l’équipe et les droits. Les membres qu’il invite n’obtiennent que les autorisations qu’il leur attribue dans Paramètres → Autorisations.

Si une action ne vous est pas proposée alors que le tenant est actif, c’est en général que l’autorisation correspondante ne vous a pas été accordée. Le propriétaire peut l’activer en quelques secondes.

Les autorisations accordées dans Paramètres → Autorisations valent pour tous les tenants. Le propriétaire peut aussi définir une portée par tenant : les droits personnalisés remplacent alors entièrement les droits globaux du membre sur ce tenant précis, sans toucher aux autres. Seul le droit de consulter le journal d’audit reste global, car le journal couvre l’ensemble des tenants.

Le propriétaire ajoute ses techniciens dans Paramètres → Équipe en saisissant leur adresse e-mail. L’application génère un lien d’invitation, valable 7 jours et à usage unique, que le propriétaire copie et transmet au technicien. Le membre rejoint le MSP en suivant ce lien puis en se connectant avec son compte Microsoft.

Tant qu’un membre n’a pas activé son compte ainsi, il reste marqué « En attente » dans la liste. Un nouveau membre n’a aucune autorisation par défaut : le propriétaire les lui accorde dans Paramètres → Autorisations.

Le propriétaire peut retirer un membre à tout moment, ou transférer la propriété du MSP à un membre déjà actif — il devient alors lui-même membre. Facturation, équipe, autorisations et protection des comptes administrateurs restent réservées au propriétaire.

L’accès à la console suppose un abonnement actif. La gestion se fait dans Paramètres → Facturation, réservée au propriétaire ; les membres n’y voient que l’état de l’abonnement.

Sans abonnement, le bouton « S’abonner » ouvre le paiement sécurisé. Une fois abonné, « Gérer l’abonnement » ouvre le portail où changer de moyen de paiement, récupérer les factures ou résilier.

Si l’abonnement devient inactif, la console redirige vers cette page et les opérations sont bloquées jusqu’à régularisation ; l’accès est rétabli dès le paiement confirmé.

Pour cesser d’opérer sur un tenant, le propriétaire utilise « Retirer » sur la carte du tenant, au tableau de bord. L’accès est coupé aussitôt et EasyTenant tente de supprimer l’application entreprise du tenant. Si cette suppression automatique échoue, la console le signale : un administrateur du tenant client doit alors la retirer à la main (Entra → Applications d’entreprise → EasyTenant → Supprimer). Tant que ce n’est pas fait, l’application reste présente côté client sans qu’EasyTenant s’en serve.

Le retrait peut aussi venir du client : un administrateur du tenant peut révoquer le consentement depuis son propre Entra à tout moment. Le tenant bascule alors en « Consentement inactif » dans la console — c’est normal ; relancez « Ajouter un tenant client » si l’accès doit être rétabli.

Pour fermer entièrement le compte, le propriétaire utilise « Supprimer le compte MSP » dans Paramètres → Compte, dans la zone de danger. L’action est définitive : l’abonnement est annulé, l’accès à tous les tenants est révoqué et les données du MSP sont supprimées. Là encore, si l’application n’a pas pu être retirée automatiquement de certains tenants, la liste concernée s’affiche : chaque administrateur client doit la supprimer à la main dans son Entra.

Un compte qui détient un rôle d’administrateur sur le tenant client (Global Admin, User Administrator, etc.) est un compte à privilèges : en changer le mot de passe, c’est changer ce qu’un administrateur du client peut faire, pas seulement un utilisateur courant. L’application applique donc une règle supplémentaire dès qu’une réinitialisation de mot de passe vise l’un de ces comptes — y compris quand son rôle n’a pas pu être déterminé, par prudence.

Le mode appliqué se règle depuis Paramètres → Compte, dans le bloc « Protection des comptes administrateurs » uniquement visible par le propriétaire. En mode « Verrouillé », la réinitialisation est refusée pour tout le monde, propriétaire du MSP compris. En mode « Validation requise » (activé par défaut), un membre qui lance l’opération ne l’exécute pas directement : elle est déposée comme une demande de validation, visible par le propriétaire depuis la page Requêtes. Le propriétaire, lui, agit directement dans ce mode — il n’a pas de demande à s’adresser à lui-même.

Sur la page Requêtes, le propriétaire valide ou refuse chaque demande en attente. Une validation exécute l’opération immédiatement, en son propre nom : le mot de passe généré s’affiche alors une seule fois, comme pour toute réinitialisation. Un refus ou une annulation ferme la demande sans qu’aucune modification ait eu lieu sur le compte visé.

Certaines opérations sensibles ne s’exécutent pas directement mais passent par une demande de validation — aujourd’hui, la réinitialisation du mot de passe d’un compte administrateur lorsque le MSP est en mode « Validation requise » (voir « Protection des comptes administrateurs »). Ces demandes se suivent depuis la page Requêtes.

Un membre n’y voit que ses propres demandes et peut annuler celles encore en attente. Le propriétaire voit toute la file et valide ou refuse chaque demande : une validation exécute l’opération aussitôt en son nom, et le résultat — par exemple le mot de passe généré — s’affiche une seule fois dans la fiche de la demande.

Chaque demande porte un statut : en attente, validée, refusée ou annulée, avec l’historique des dernières décisions sur la même page. Le nombre de demandes en attente s’affiche en pastille à côté de « Requêtes » dans le menu — sa file pour le propriétaire, ses propres demandes pour un membre.

Chaque opération est enregistrée dans le journal d’audit, qu’elle réussisse ou échoue, avec son auteur, sa cible et son horodatage. Le journal se consulte depuis l’entrée « Audit » ; la page se filtre par opération et par résultat (réussite ou échec) et se parcourt page par page.

Pour les opérations sensibles, Microsoft peut exiger une authentification récente de l’administrateur du tenant. Si une action de ce type est refusée, une nouvelle connexion de cet administrateur lève généralement le blocage.