La sortie est le processus le moins bien tenu
L’arrivée d’un salarié est souvent organisée. Le départ ne l’est presque jamais, et il porte pourtant plus de risque.
Les accès survivent. Boîte mail, outils métier, espace de stockage, accès distant, comptes tiers, clés d’API créées pour un projet. Chacun est ouvert par une personne différente, à un moment différent, et il n’existe généralement aucune liste. Un compte d’ancien salarié resté actif est un accès non surveillé, souvent avec un mot de passe qui ne change plus.
La connaissance part. Où en est ce dossier, qui est l’interlocuteur chez ce client, pourquoi on fait comme ça. Ce transfert se fait dans les derniers jours, quand il se fait.
Les fichiers restent bloqués. Documents créés sous un compte personnel, dossiers dont la propriété n’a pas été transférée, fichiers locaux sur un poste rendu et réinstallé.
Les automatisations cassent. Un flux qui tourne avec les identifiants de la personne s’arrête quand le compte est désactivé — et parfois en silence, ce qui est pire. Le lien de cause à effet n’est découvert que des semaines plus tard.
Ce qu’on automatise
Le déclenchement. Dès que la date de fin est connue, la procédure se crée avec toutes ses tâches datées.
L’inventaire des accès. La liste des comptes, droits, appareils et clés attribués à cette personne — constituée en continu, pas reconstituée le dernier jour.
La révocation programmée, à l’heure exacte, avec vérification que chaque coupure a bien eu lieu.
Le réacheminement des messages et des appels vers la personne qui reprend.
Le transfert de propriété des fichiers, dossiers, tâches et automatisations.
La production des documents de fin de contrat, selon vos modèles.
La restitution du matériel, avec état et accusé.
L’inventaire des automatisations tournant sous son identité, et leur réattribution.
La vérification finale, quelques jours après : plus aucune connexion active, plus aucun flux en échec.
Comment ça marche techniquement — pour qui veut le détail
L’inventaire permanent. Le problème central n’est pas la révocation, c’est de savoir quoi révoquer. La solution est de tenir l’inventaire à l’attribution plutôt qu’au départ : chaque création de compte, chaque octroi de droit, chaque remise de matériel écrit une ligne dans un registre. Idéalement, l’attribution passe par le flux d’intégration, ce qui garantit que rien n’existe hors registre. C’est le travail fait à l’arrivée qui rend la sortie possible — et c’est pour cette raison que les deux procédures se construisent ensemble.
La révocation. Appels d’API aux systèmes concernés : Microsoft Graph ou l’API Google Workspace pour la messagerie et l’identité, annuaire LDAP, fournisseur d’identité, outils métier, et surtout les accès techniques — clés SSH, jetons d’API, accès Tailscale ou VPN, comptes de dépôts de code. Chaque révocation est vérifiée par une lecture après écriture : on ne se contente pas du code de retour, on confirme que le compte est bien désactivé. L’écart entre « commande envoyée » et « effet obtenu » est réel, surtout sur les systèmes à propagation différée.
La programmation à l’heure. Tâche planifiée avec date et heure exactes, dans une table d’échéances durable — pas une minuterie en mémoire qui ne survivrait pas à un redémarrage. Un report de date de départ met à jour l’échéance ; une annulation la supprime. La révocation immédiate reste possible en un geste pour les situations qui l’exigent.
Les sessions actives. Désactiver un compte ne ferme pas toujours les sessions en cours : un jeton d’accès déjà émis peut rester valide jusqu’à son expiration. Il faut donc révoquer les jetons de rafraîchissement et forcer la fin des sessions, opération distincte et souvent oubliée. Sans elle, un navigateur resté ouvert continue d’accéder aux données plusieurs heures après la désactivation.
Les comptes partagés. C’est le point faible de toute procédure de sortie. Un mot de passe partagé connu de la personne qui part doit être changé, ce qui suppose de savoir qu’il existe et qui d’autre l’utilise. Le registre marque ces comptes comme tels, et leur rotation fait partie de la procédure. À plus long terme, la vraie réponse est de supprimer les comptes partagés, et la sortie d’un salarié est une bonne occasion de le faire.
Le transfert de propriété. Fichiers et dossiers réattribués par API avant la désactivation — l’ordre compte, puisque certains systèmes rendent le transfert plus difficile une fois le compte désactivé. Les tâches, dossiers et alertes assignés sont réattribués dans les outils métier. Un rapport liste ce qui n’a pas pu être transféré automatiquement.
Les automatisations à son nom. Requête sur les flux n8n, tâches planifiées, dépôts et clés dont le propriétaire ou les identifiants correspondent à la personne. Chacun est réattribué à un compte de service ou à un autre propriétaire avant la révocation. C’est l’étape que personne ne prévoit et qui casse des chaînes en silence — d’autant que l’échec n’est visible qu’au prochain déclenchement, parfois des semaines plus tard.
Le réacheminement. Redirection de la boîte vers la personne désignée, avec réponse automatique annonçant le changement de contact. Durée limitée — quelques mois —, et information de la personne qui part. Un réacheminement permanent et non annoncé pose un problème de conformité, et se remarque.
L’archivage. Contenu professionnel de la boîte archivé chiffré, avec une durée de conservation écrite et un accès soumis à justification et journalisé. Ce n’est pas une boîte que l’on continue de consulter librement.
La vérification à J+7. Contrôle automatique : aucune connexion réussie sous cette identité, aucun flux en échec attribuable à la révocation, aucun droit résiduel dans les systèmes inventoriés. Le rapport de sortie n’est clos qu’après ce contrôle — parce qu’une procédure qu’on ne vérifie pas est une procédure dont on ignore le taux d’échec.