Pour automatiser le départ des collaborateurs Microsoft 365, vous construisez des workflows de départ dans Microsoft Entra ID Lifecycle Workflows qui se déclenchent sur un attribut de date porté par l'objet utilisateur plutôt que sur un ticket que quelqu'un doit penser à ouvrir. Vous renseignez employeeLeaveDateTime sur le compte, et Entra exécute un workflow de pré-départ avant le dernier jour, un workflow de départ le jour même, puis un workflow de post-départ ensuite, chacun portant des tâches intégrées telles que Disable User Account, Remove user from all groups, Remove all licenses for user et Delete User Account. Le déclencheur est une date, la portée est une règle, et l'exécution laisse un historique que vous pouvez présenter à un auditeur. Ce guide parcourt toute la construction, énonce honnêtement la licence qu'elle exige, et couvre les quatre choses qu'elle ne fera pas à votre place.
Le partant qui a gardé une licence pendant quatre mois
Commencez par la défaillance que tout cela vise à corriger, car ce n'est presque jamais une défaillance technique. Quelqu'un s'en va. Le service d'assistance bloque la connexion le dernier jour, se fait happer par une urgence, et le reste de la séquence n'a jamais lieu. Quatre mois plus tard, le compte est toujours activé dans trois groupes de sécurité, détient toujours un siège complet, et figure toujours sur la facture.
L'arithmétique mérite d'être faite avec vos propres chiffres plutôt qu'avec la référence de quelqu'un d'autre. Une organisation de 250 utilisateurs avec une rotation classique peut perdre 30 personnes par an. Si chaque départ est traité en moyenne avec six semaines de retard, cela représente environ 3,5 mois-sièges de gaspillage par partant, soit à peu près 105 mois-sièges par an. À £22 le siège, cela fait un peu plus de £2,300 ; à £35, on approche £3,700. Changez n'importe quelle donnée d'entrée et la réponse bouge, et c'est bien là l'intérêt : votre responsable financier peut vérifier ce calcul de tête.
Le coût est la partie qui déclenche une conversation budgétaire. Le risque est la partie qui déclenche une conversation au conseil d'administration. Un partant dont les appartenances aux groupes sont toujours actives conserve tout ce que ces groupes accordent, et entre 50 et 600 utilisateurs, la même personne détient généralement des identifiants partagés, une appartenance à une équipe Teams contenant des données clients, et une boîte aux lettres que personne n'a lue depuis son départ. L'automatisation compte ici non pas parce que les étapes manuelles sont difficiles, mais parce qu'un processus manuel exécuté 30 fois par an sera oublié au moins une fois, et vous ne saurez pas laquelle.
Ce que couvre réellement la suppression depuis le centre d'administration
La base manuelle mérite d'être décrite avec précision. Dans le centre d'administration Microsoft 365, sous Users puis Active users, sélectionner une personne et choisir Delete user exécute un ensemble d'actions : cela peut retirer les licences, donner à quelqu'un l'accès au OneDrive et à la messagerie, puis supprimer le compte. C'est un parcours réellement utile pour un partant isolé et vous ne devriez pas avoir honte de l'utiliser.
Ce que ce n'est pas, c'est un processus. Il ne fait rien tant qu'un humain ne l'ouvre pas, il traite chaque partant de façon identique quels que soient son rôle ou son service, il ne produit aucune trace au-delà du journal d'audit que quiconque reconnaîtrait comme une preuve, et il ne peut pas s'exécuter une semaine avant le dernier jour ni trente jours après. Respecter le bon ordre des opérations compte également plus qu'on ne le croit, car retirer une licence avant d'avoir traité la boîte aux lettres fait perdre des données. La checklist de départ Microsoft 365 détaille cette séquence étape par étape, et elle reste la bonne référence de ce à quoi ressemble un traitement correct. Cet article porte sur la façon de faire tourner cette séquence toute seule.
La question de la licence, tranchée avant toute planification
Soyez clair là-dessus avant de concevoir quoi que ce soit, car cela décide si la suite de l'article vous concerne.
Lifecycle Workflows exige des licences Microsoft Entra ID Governance ou Microsoft Entra Suite. Ce n'est pas inclus dans Microsoft Entra ID P1, ni dans Microsoft Entra ID P2, et ce n'est donc pas inclus dans Microsoft 365 E3 ou E5 au titre du plan Entra qu'ils embarquent. Microsoft Entra ID Governance est un abonnement distinct qui vient s'ajouter à un plan éligible, et Microsoft a indiqué explicitement qu'aucune nouvelle fonctionnalité de gouvernance des identités ne sera ajoutée à la référence Entra ID P2.
Il vous faut également assez de licences pour couvrir chaque utilisateur membre dans la portée du workflow, plus la personne qui le configure, et non un unique siège d'administrateur. L'exemple chiffré de Microsoft lui-même porte sur un workflow de pré-départ dont la portée couvre 50 utilisateurs, ce qui nécessite 51 licences. Pour une organisation de 300 utilisateurs qui traite 30 départs par an, cela change la forme du dossier économique : vous ne licenciez pas 30 partants, vous licenciez la population que couvre la portée du workflow.
Il existe une version d'essai. Un Global Administrator dans un tenant commercial qui détient déjà un produit éligible tel que Microsoft Entra ID P1, et qui n'a pas encore utilisé l'essai, peut la démarrer depuis le centre d'administration Microsoft 365 sous Billing puis Purchase services, en recherchant Microsoft Entra ID Governance et en sélectionnant Details puis Start free trial. C'est la manière honnête de tester les workflows ci-dessous sur votre propre tenant avant que quiconque ne signe quoi que ce soit.
Construire le workflow de départ
La création d'un workflow dans le centre d'administration Microsoft Entra part toujours d'un modèle, et il y en a 14 intégrés. Quatre concernent les départs, et s'il y en a quatre, c'est parce que le départ n'est pas un moment unique.
Pre-Offboarding of an employee s'exécute par défaut sept jours avant employeeLeaveDateTime, en portant Remove user from selected groups et Remove user from selected Teams. C'est celui que l'on saute et que l'on regrette ensuite : c'est là que vous sortez quelqu'un du groupe paie et de l'équipe finance pendant qu'il est encore présent pour transmettre.
Offboard an employee s'exécute le jour du départ lui-même, avec Disable User Account, Remove user from all groups et Remove user from all Teams. C'est le workflow qui ferme la porte.
Post-Offboarding of an employee s'exécute après la date de départ, avec Remove all licenses for user, Remove user from all Teams et Delete User Account. C'est le workflow qui arrête la facturation du siège, et le décalage que vous choisissez ici est le chiffre le plus coûteux de toute la conception.
Real-time employee termination n'a aucune condition d'exécution. Il est uniquement à la demande, portant Remove user from all groups, Delete User Account et Remove user from all Teams, et il existe pour le cas du départ immédiat.
Le catalogue de tâches plus large est l'endroit où vous ajustez chacun d'eux. Aux côtés des tâches ci-dessus, il comprend Revoke all refresh tokens for user, Remove all access package assignments for user, Send email to manager before user's last day, Send email on user's last day et Send email to user's manager after their last day. Le fait que la révocation de session soit une tâche intégrée mérite d'être souligné, car bon nombre de guides de départ la présentent encore comme quelque chose à scripter.
Deux autres modèles méritent une mention même s'ils ne sont pas strictement pilotés par le départ : Pre-Offboard inactive users et Offboard inactive users se déclenchent sur l'inactivité de connexion plutôt que sur une date de départ, avec 90 et 120 jours par défaut respectivement. Ce sont les cousins automatisés du rapport présenté dans notre guide sur comment trouver les utilisateurs Microsoft 365 inactifs, et ils rattrapent les comptes qui n'ont jamais eu de date de départ parce que personne n'a jamais dit à qui que ce soit que la personne était partie.
Planification, portée, et l'attribut dont tout dépend
Trois détails de configuration décident si cela fonctionne en pratique.
L'attribut n'est pas gratuit. employeeLeaveDateTime n'est pas renseigné pour vous. Il provient d'un provisionnement piloté par les RH, de Microsoft Entra Connect, ou d'un script qui l'écrit via Microsoft Graph. L'écrire dans un contexte délégué nécessite le rôle Global Administrator ainsi que les autorisations User.Read.All et User-LifeCycleInfo.ReadWrite.All, ce qui est une exigence plus élevée que pour la plupart des tâches de reporting et mérite d'être soulevé tôt avec le responsable de votre intégration RH. Si personne ne renseigne la date, rien ne s'exécute, et le workflow paraîtra cassé alors qu'il est simplement au repos.
La planification se fait à l'initiative de l'administrateur. Les nouveaux workflows sont activés par défaut, mais pas planifiés, si bien qu'un workflow peut rester là, d'apparence correcte, sans jamais se déclencher. Une fois planifiés, les workflows sont évalués selon un intervalle valable pour tout le tenant, réglé par défaut sur toutes les trois heures et paramétrable entre 1 et 24 heures, sous ID Governance puis Lifecycle workflows puis Workflow settings dans le centre d'administration Microsoft Entra. Il vous faut au moins le rôle Lifecycle Workflows Administrator pour le modifier.
Les exécutions à la demande ignorent vos conditions d'exécution. Exécuter un workflow à la demande applique ses tâches à l'utilisateur, qu'il corresponde ou non à la portée et au déclencheur. C'est exactement ce que vous voulez pour un départ immédiat et exactement ce que vous ne voulez pas en phase de test, alors testez sur un compte que vous acceptez de perdre.
Une bonne nouvelle sur le calendrier : si la date de départ est renseignée tardivement, par exemple parce que le système RH a été mis à jour après coup, Lifecycle Workflows tentera tout de même de traiter l'utilisateur à condition que la configuration soit achevée dans les trois jours suivant l'heure de traitement prévue. Ce comportement de rattrapage ne s'applique pas à l'option Time based attribute V2 actuellement en préversion publique.
Cinq mouvements. Entra automatise le premier, le deuxième, le troisième et le cinquième. Le quatrième est celui qui décide si quelqu'un fait confiance aux quatre autres.
Les quatre choses qu'il ne fera pas
Lifecycle Workflows gouverne l'identité. Le départ d'un collaborateur Microsoft 365 va au-delà de l'identité, et ces quatre lacunes restent les vôtres.
La boîte aux lettres. Il n'existe aucune tâche pour convertir une boîte aux lettres utilisateur en boîte aux lettres partagée, et le piège de l'ordre est bien réel : la boîte aux lettres doit encore être licenciée au moment où vous la convertissez, cela doit donc se produire avant que le workflow de post-départ ne retire la licence, pas après.
Les fichiers. Donner à un responsable l'accès au OneDrive du partant relève du centre d'administration SharePoint. Rien dans les modèles de départ n'y touche.
L'appareil. Retire et wipe résident dans le centre d'administration Microsoft Intune, et aucune tâche de cycle de vie ne les atteint. Les rapports Intune planifiés sont le moyen pratique de prouver quels appareils de partants se sont réellement enregistrés et étaient conformes.
La facture. Remove all licenses for user libère l'attribution. Cela ne réduit pas la quantité d'un abonnement prépayé, l'économie n'atteint donc votre facture que lorsque quelqu'un agit au renouvellement. Si la licence provenait d'une attribution basée sur les groupes, c'est l'appartenance au groupe qui retient le siège, ce qui explique pourquoi les tâches de groupe et la tâche de licence appartiennent au même workflow.
Voici le script pour la première lacune, dimensionné pour être exécuté une fois par partant, dans la fenêtre entre le dernier jour et l'exécution du post-départ.
# Fills the gaps Lifecycle Workflows does not cover, before the licence is removed
Connect-ExchangeOnline
Connect-MgGraph -Scopes "User.RevokeSessions.All"
$Leaver = "leaver@contoso.com"
$Manager = "manager@contoso.com"
# Belt and braces: end every active session now rather than waiting for token expiry
Revoke-MgUserSignInSession -UserId $Leaver
# Convert while the mailbox is still licensed, or the conversion is not available
Set-Mailbox -Identity $Leaver -Type Shared
Add-MailboxPermission -Identity $Leaver -User $Manager -AccessRights FullAccess -InheritanceType All
Add-RecipientPermission -Identity $Leaver -Trustee $Manager -AccessRights SendAs -Confirm:$false
Write-Host "$Leaver converted to shared and delegated to $Manager"
Lisez-le avant de l'exécuter. Revoke-MgUserSignInSession est redondant si votre workflow de départ porte déjà la tâche de révocation, et inoffensif si ce n'est pas le cas. La conversion garde la messagerie et le calendrier accessibles jusqu'à 50 Go sans siège payant, ce qui rend sûr de laisser le workflow retirer la licence un jour plus tard. Ne supprimez pas le compte tant que la boîte aux lettres partagée est utilisée, car c'est le compte qui l'ancre.
Si cette séquence ressemble à quelque chose que vous préféreriez voir tourner en continu plutôt que d'y penser à chaque partant, un essai EtherInsights de 14 jours montre les mêmes contrôles sur votre propre tenant.
La limite honnête de cette automatisation
Lifecycle Workflows est bon. C'est aussi un mécanisme, pas un résultat, et trois choses séparent les deux.
Quelqu'un doit en être propriétaire. Un workflow sans propriétaire dérive : la règle de portée cesse de correspondre à un service qui a été renommé, un modèle est modifié pendant une semaine chargée, et personne ne le remarque jusqu'à ce qu'un départ ne produise silencieusement aucun effet. L'historique des workflows vous donne la matière première, consultable par utilisateurs, exécutions et tâches, mais une matière première n'est pas une revue.
Quelqu'un doit produire les preuves. Votre auditeur, votre évaluateur Cyber Essentials et le questionnaire de sécurité de votre plus gros client posent tous la même question avec des mots différents : montrez-moi que les accès ont été retirés dans le délai que vous annoncez, pour ces personnes nommées, à ces dates. C'est un travail de reporting qui vient s'ajouter au workflow, pas un sous-produit de celui-ci.
Et quelqu'un doit suivre la récupération jusqu'à la facture. Le siège libéré par le workflow n'est une économie que lorsque la quantité de l'abonnement diminue. Entre ces deux événements se trouvent une date de renouvellement et une conversation avec la finance, et c'est là que la plupart des travaux de récupération meurent discrètement. Notre guide sur prouver les économies sur le cloud explique pourquoi cette dernière étape exige un avant et un après plutôt qu'une affirmation.
Rien de tout cela n'est un argument contre la construction des workflows. Construisez-les ce mois-ci. C'est un argument pour rester lucide sur le fait que l'automatisation résout le problème d'exécution et laisse le problème de propriété exactement là où il était.
La place d'EtherInsights
EtherInsights est la console qui se pose par-dessus tout cela. Elle contrôle les départs en continu plutôt que ticket par ticket, fait remonter les partants encore activés ou encore licenciés comme des constats assortis d'un propriétaire nommé et d'une action suivante, et conserve l'avant et l'après pour qu'une récupération arrive à votre revue financière comme une preuve plutôt que comme une affirmation. Là où vous avez Lifecycle Workflows, elle vous dit si les workflows ont réellement fait ce que vous aviez conçu. Là où vous ne les avez pas, parce que la licence de gouvernance n'a pas encore été validée, elle vous donne la même visibilité sans elle.
La gestion des licences Microsoft 365 et le départ des partants fait tourner la boucle arrivée, mobilité et départ comme un seul processus sur l'ensemble des tenants, avec le travail sur les sièges dormants issu de comment trouver les licences inutilisées dans la même vue. Cela coûte £0.79 par utilisateur actif avec un essai de 14 jours, vous pouvez donc mesurer l'écart entre vos dates de départ et vos retraits de licences avant de vous engager, et c'est en général le chiffre qui tranche le débat.
Renseignez correctement la date de départ, construisez les trois workflows planifiés, scriptez la boîte aux lettres, et posez une revue mensuelle dans le calendrier. Si cette revue ne cesse de glisser, vous avez trouvé la véritable contrainte, et ce n'a jamais été l'outillage.
Découvrez la gestion des licences Microsoft 365 et le départ des partants pour voir les contrôles de départ, la récupération des licences et la piste de preuves traités comme un seul processus continu au lieu d'un workflow que personne ne surveille.