Une checklist de départ d’un salarié ne doit pas se contenter de rappeler aux RH de planifier un entretien de départ. Elle doit coordonner la suppression des accès, le transfert des connaissances, la récupération des actifs, la paie, les obligations légales et les changements de responsabilité entre plusieurs équipes, souvent dans des délais serrés.
Lorsque le processus de départ repose sur une feuille de calcul ou une liste de tâches générique, des étapes critiques sont oubliées. Un salarié quittant l’entreprise peut conserver des accès, un dossier client peut se retrouver sans responsable, ou personne ne peut prouver à quelle date le matériel de l’entreprise a été restitué. Un processus fiable traite chaque départ comme un workflow opérationnel gouverné, et non comme une simple formalité administrative.
Pourquoi le départ des salariés échoue entre les équipes
Le départ d’un salarié est un processus transversal plus complexe qu’il n’y paraît. Les RH peuvent initier le départ, mais l’IT, la finance, les services généraux, le juridique, la sécurité et le manager du salarié sont tous responsables d’une partie du résultat.
Cette situation crée trois points de défaillance courants.
Le départ ne déclenche pas un événement de référence unique
Les managers informent parfois les RH par e-mail, par chat ou au cours d’une conversation informelle. Chaque service travaille alors à partir d’informations différentes concernant la date de départ, le type de départ, le lieu de travail et les exigences relatives aux accès.
Votre processus a besoin d’un formulaire structuré unique qui fasse office de source de vérité. Il doit au minimum recueillir les informations suivantes :
Nom et identifiant du salarié
Manager et service
Fonction et type de contrat
Dernier jour travaillé et heure précise de désactivation
Départ volontaire ou involontaire
Lieu de travail et juridiction applicable
Actifs de l’entreprise attribués au salarié
Systèmes, comptes à privilèges et identifiants partagés utilisés
Clients, projets, fournisseurs ou processus dont il est responsable
Instructions particulières en matière juridique, de sécurité ou de conservation
Ces informations doivent alimenter le reste du workflow. Les saisir à nouveau dans plusieurs tickets augmente les délais et le risque d’erreurs.
Tous les départs sont traités de la même manière
La fin planifiée de la mission d’un prestataire ne présente pas les mêmes risques que le départ inattendu d’un administrateur. Une checklist universelle finit généralement par être trop superficielle pour les départs à haut risque ou inutilement contraignante pour les cas courants.
Utilisez plutôt des parcours fondés sur le risque. Le type de départ, la fonction, le niveau d’accès et le calendrier doivent déterminer les étapes à exécuter, les personnes chargées de les approuver et le moment où les accès sont supprimés.
Une étape est considérée comme terminée sans preuve
Une case cochée ne prouve pas qu’un compte a été désactivé ou qu’un actif a été restitué. Les étapes à fort impact nécessitent des preuves, comme une référence de ticket, une réponse du système, un reçu importé, un enregistrement d’approbation ou une confirmation du responsable du système concerné.
Cette distinction est importante lorsque vous enquêtez sur un incident, répondez à un auditeur ou résolvez un litige plusieurs mois plus tard. Une piste d’audit efficace doit montrer ce qui s’est passé, qui a effectué l’action, quand elle a eu lieu et quelle exception ou approbation a modifié le parcours normal.
Construire le processus autour du calendrier et du risque
Un workflow de départ sécurisé commence par la classification du départ. Cette classification doit piloter l’enchaînement des tâches, et pas simplement ajouter une étiquette au dossier du salarié.
Définir des parcours de départ clairs
La plupart des équipes ont besoin d’au moins trois parcours :
Départ standard planifié : Une démission volontaire ou une fin de contrat prévue laissant suffisamment de temps pour organiser le transfert.
Départ immédiat ou sensible : Les accès doivent être restreints à un moment coordonné, éventuellement avant l’annonce du départ.
Mobilité interne : La relation de travail se poursuit, mais les autorisations, le matériel, les responsabilités et les liens hiérarchiques changent.
Vous pouvez ajouter des parcours pour les congés temporaires, les travailleurs saisonniers, les fournisseurs ou les fonctions réglementées si ceux-ci nécessitent des contrôles sensiblement différents. Évitez de créer un workflow distinct pour chaque variation mineure ; utilisez des étapes conditionnelles et des variables pour gérer les différences raisonnables.
Ancrer les échéances sur l’événement de départ
Les échéances relatives sont plus fiables que les dates sélectionnées manuellement. Par exemple :
Plan de transfert des connaissances à finaliser cinq jours ouvrés avant le départ
Réattribution des clients à terminer deux jours avant le départ
Vérification de la paie à effectuer un jour avant le départ
Accès interactifs désactivés à l’heure de coupure
Récupération des actifs confirmée dans les trois jours ouvrés suivant le départ
Suppression ou archivage des comptes après la période de conservation
Les départs immédiats exigent un enchaînement différent. Les préparatifs de sécurité peuvent avoir lieu avant que le salarié soit informé, et la révocation des accès peut devoir être exécutée simultanément dans plusieurs systèmes.
Distinguer désactivation, transfert et suppression
Ces actions ne sont pas interchangeables. La désactivation empêche l’accès, le transfert préserve la continuité des responsabilités métier et la suppression efface les données ou le compte lui-même.
Supprimer un compte trop tôt peut faire disparaître des fichiers, des e-mails, des logs ou des dossiers que l’entreprise doit conserver. Votre SOP doit définir l’action appropriée et la période de conservation pour chaque système, au lieu d’utiliser une instruction vague telle que « supprimer l’utilisateur ». Pour des recommandations plus générales, consultez la conservation des données opérationnelles : combien de temps garder les données d’exécution.
Une checklist pratique pour le départ d’un salarié
La checklist suivante constitue une base solide. Adaptez les responsables, les exigences en matière de preuves et le calendrier à votre organisation et aux obligations locales.
1. Valider et approuver le dossier de départ
Les RH confirment la date définitive, la catégorie du départ, le manager, la juridiction et les éventuelles restrictions de confidentialité. Les départs sensibles doivent être approuvés avant l’envoi des notifications ou le lancement des tâches en aval.
Le processus doit également déterminer qui est autorisé à consulter le run. Les informations concernant les départs involontaires ne doivent pas être exposées dans un tableau de projet largement accessible.
2. Créer un inventaire complet des accès
Identifiez toutes les applications, tous les appareils, tous les sites physiques, comptes partagés, clés API, comptes de service et droits élevés associés au salarié.
Ne vous fiez pas uniquement au fournisseur d’identité. Les outils propres à certains services, les portails clients externes, les identifiants enregistrés dans le navigateur et les comptes provisionnés manuellement constituent souvent des angles morts. Une cartographie à jour des fonctions et des systèmes rend cette étape plus rapide et plus fiable.
3. Planifier la révocation des accès
Attribuez chaque système à un responsable nommé et précisez l’action requise : désactiver le compte, retirer l’utilisateur des groupes, renouveler les identifiants, transférer la propriété, archiver ou supprimer après la période de conservation.
Les accès à privilèges nécessitent une vérification supplémentaire. Si le salarié connaissait un mot de passe partagé ou détenait un token réutilisable, la désactivation de son compte personnel ne suffit pas. Appliquez le principe du moindre privilège pendant toute la durée de la relation de travail afin de faciliter le contrôle des départs ; ce même modèle opérationnel est présenté dans le contrôle d’accès basé sur les rôles pour les opérations humaines et IA.
4. Transférer les connaissances opérationnelles
Le manager recense les responsabilités en cours, les tâches récurrentes, les décisions non documentées, les relations externes et les problèmes susceptibles de survenir prochainement. Chaque élément doit être attribué à un nouveau responsable plutôt que d’être simplement ajouté à un document générique de passation.
Les preuves utiles du transfert peuvent inclure :
SOPs et critères de décision mis à jour
État des clients, projets et engagements en cours
Calendrier des responsabilités récurrentes
Exceptions ouvertes et historique des escalades
Coordonnées des fournisseurs et des parties prenantes
Enregistrements d’écran pour les procédures peu connues
Liens vers les fichiers sources et les systèmes de référence
Les enregistrements et les notes constituent une matière première utile, mais ils doivent être transformés en procédures maintenues lorsque les connaissances concernent un travail répétable. Découvrez comment capturer le savoir institutionnel dans des SOPs exécutables.
5. Réattribuer les responsabilités métier
Transférez les documents, boîtes de réception, calendriers, dashboards, automatisations, projets, contrats, comptes clients et responsabilités d’approbation. Le transfert de propriété doit avoir lieu avant la suppression du compte.
Accordez une attention particulière aux processus qui dépendent silencieusement du salarié sur le départ. Une automatisation peut continuer à s’exécuter avec ses identifiants, tandis qu’une approbation récurrente peut toujours être envoyée vers un compte inactif.
6. Récupérer les actifs physiques et numériques
Créez une liste des actifs couvrant les ordinateurs portables, téléphones, badges d’accès, clés de sécurité, cartes de paiement, documents, outils, uniformes et équipements loués. Pour les salariés en télétravail, il peut être nécessaire de fournir des étiquettes d’expédition, des instructions d’emballage et un suivi de livraison.
Enregistrez les numéros de série, l’état, la date de retour et la preuve de réception. Si un actif n’est pas restitué dans les délais, le workflow doit déclencher une escalade vers un responsable nommé plutôt que de laisser la tâche en retard indéfiniment.
7. Finaliser les actions liées à la paie, aux avantages sociaux et aux obligations légales
La finance et les RH doivent vérifier la rémunération finale, les notes de frais, les changements d’avantages sociaux, les documents fiscaux, les soldes de congés et tout accord de départ applicable. Les exigences varient selon le contrat et la juridiction ; le workflow doit donc orienter les dossiers en fonction du lieu de travail et du statut du salarié.
L’approbation du service juridique ou des RH doit bloquer la clôture lorsqu’un document obligatoire manque. Les gates d’approbation sont plus fiables que des commentaires demandant simplement à quelqu’un de « vérifier ».
8. Coordonner le dernier jour de travail
Le manager confirme la passation, communique le départ aux parties prenantes concernées et retire le salarié des réunions récurrentes et des rotations opérationnelles. L’IT applique les modifications d’accès à l’heure de coupure approuvée.
Pour les départs sensibles, la communication et la révocation doivent être étroitement synchronisées. Pour les départs planifiés, vous pouvez maintenir un accès limité jusqu’à la fin convenue de la journée de travail.
9. Vérifier les contrôles après le départ
Ne supposez pas que les demandes de révocation envoyées ont abouti. Confirmez le statut des comptes dans les systèmes critiques, validez les règles de transfert ou de délégation, vérifiez que les identifiants partagés ont été renouvelés et assurez-vous qu’aucune session active ne subsiste lorsque le système permet d’y mettre fin.
Pour les fonctions à privilèges ou à haut risque, cette étape doit faire l’objet d’une vérification indépendante. La personne qui demande la révocation ne doit pas toujours être la seule à la confirmer.
10. Clôturer avec les preuves et les exceptions non résolues
Avant la clôture, confirmez que toutes les étapes obligatoires, les approbations, les actifs et les preuves sont présents. Chaque exception doit comporter un responsable, un motif, une échéance et une résolution approuvée.
Un départ n’est pas terminé simplement parce que le dernier jour du salarié est passé. Il l’est lorsque votre organisation a maîtrisé les accès, préservé les connaissances nécessaires, transféré les responsabilités, respecté ses obligations et enregistré les preuves.
Transformer la checklist en workflow gouverné
Une checklist statique décrit la séquence idéale, mais elle ne coordonne pas l’exécution. Le processus devient fiable lorsque chaque départ lance un workflow actif comportant des données structurées, des attributions, des échéances, des conditions et des preuves.
Dans OKiDO, vous pouvez créer la procédure sous forme de modèle de SOP versionné et lancer un RUN pour chaque départ de salarié. Des variables telles que la date définitive, le service, le manager, le type de départ et le niveau de risque fournissent un contexte structuré qui accompagne le run.
Votre équipe peut ensuite :
Attribuer les étapes aux RH, à l’IT, à la finance, aux services généraux, au juridique ou au manager du salarié
Définir des décalages d’échéance par rapport au dernier jour travaillé
Utiliser des gates d’approbation pour les départs sensibles et les validations juridiques
Recueillir du texte, des dates, des fichiers, des sélections et d’autres preuves directement dans chaque étape
Garder les étapes confidentielles en interne lorsque cela est nécessaire
Déclencher des escalades lorsque des actions importantes sont bloquées, bientôt à échéance ou en retard
Conserver les commentaires, soumissions, approbations et modifications dans une piste d’audit
Maintenir les runs actifs associés à la version de la SOP utilisée lors de leur lancement
Les organisations plus complexes peuvent modéliser le départ sous forme d’OKiDO System. Des nœuds de décision peuvent orienter les départs selon le risque, des nœuds de division peuvent lancer des tâches parallèles dans plusieurs services et des nœuds de jonction peuvent empêcher la clôture tant que toutes les branches obligatoires ne sont pas terminées.
Les applications connectées sont également importantes. La couche d’intégration d’OKiDO couvre plus de 400 applications, permettant une exécution humaine et IA dans les systèmes où le travail a réellement lieu. Des automatisations ou des agents IA peuvent réaliser des actions délimitées, comme créer des tickets, recueillir des informations sur les comptes ou mettre à jour des dossiers, tandis que les approbations et les vérifications restent intégrées au workflow gouverné.
Le principe essentiel est que l’IA ne doit pas décider de la manière de gérer le départ d’une personne à partir d’un prompt isolé. Elle doit agir conformément à votre procédure approuvée, à vos systèmes connectés, aux autorisations attribuées et à vos exigences en matière de preuves.
Mesurer si les départs sont maîtrisés
Le seul taux d’achèvement est un indicateur trop faible. Un workflow peut atteindre le statut « terminé » en retard, sans preuve ou malgré des exceptions sérieuses.
Suivez un ensemble ciblé d’indicateurs opérationnels :
Délai de désactivation des accès : Temps écoulé entre l’heure de coupure approuvée et la confirmation de la révocation
Taux d’achèvement dans les délais : Pourcentage d’étapes obligatoires terminées avant leur échéance
Taux de vérification des accès : Pourcentage de comptes critiques contrôlés de manière indépendante
Taux de récupération des actifs : Pourcentage d’actifs attribués récupérés dans le délai prévu par la politique
Achèvement du transfert des connaissances : Pourcentage de responsabilités identifiées transférées à des responsables ayant accepté leur attribution
Taux d’exception : Pourcentage de départs nécessitant un écart par rapport au processus standard
Exhaustivité des preuves : Pourcentage d’étapes de contrôle contenant les justificatifs requis
Taux de réouverture des départs : Runs rouverts parce que des responsabilités, des accès ou des obligations ont été oubliés
Segmentez ces indicateurs par service, type de départ, lieu et niveau de risque. Si une unité métier découvre régulièrement des applications inconnues après le départ de salariés, le problème de fond est probablement une attribution incomplète de la responsabilité des systèmes plutôt qu’un manque de rigueur dans l’utilisation de la checklist.
Examinez régulièrement les runs ayant échoué ou pris du retard. Mettez à jour la SOP lorsque vous identifiez une lacune récurrente, tout en conservant l’historique des versions afin de déterminer quel processus régissait chaque départ antérieur.
Faire de chaque départ un événement opérationnel maîtrisé
Le départ d’un salarié révèle si vos procédures, vos systèmes et vos registres de responsabilités sont réellement connectés. Un processus sécurisé commence par un déclencheur unique et vérifié, suit différents parcours selon le risque, coordonne toutes les équipes responsables et exige des preuves avant la clôture.
OKiDO transforme votre checklist de départ des salariés en exécution gouvernée. Vous pouvez structurer la SOP, connecter les systèmes concernés, exécuter les tâches humaines et IA avec des approbations, puis conserver un enregistrement consultable de chaque action. Utilisez OKiDO pour rendre votre prochain départ prévisible, sécurisé et vérifiable, plutôt que d’en faire une nouvelle course contre la montre entre e-mails et feuilles de calcul.
