Checklist offboarding informatique 2026 : accès applicatifs oubliés, autorisations OAuth et clés API (modèle gratuit)

Quand quelqu'un part, la checklist RH couvre l'ordinateur portable, le badge et le dernier bulletin de paie. L'informatique désactive la messagerie et considère le travail terminé. Ce qui survit en général, c'est tout ce qui n'a jamais été un mot de passe : l'autorisation OAuth accordée à un outil de reporting, la clé API collée dans un script, le jeton d'accès personnel dans un pipeline CI, l'automatisation Zapier qui tourne à son nom, et les mots de passe d'administration partagés qu'elle a consultés cent fois.

Cette checklist se concentre sur cette couche oubliée. Vous pouvez télécharger le modèle et l'utiliser tel quel pour chaque départ.

La réponse courte

Une checklist d'offboarding informatique complète comporte trois couches : l'identité (compte SSO, sessions, MFA), les accès délégués (autorisations OAuth, clés API, jetons, intégrations) et les secrets partagés (les mots de passe que la personne pouvait voir). La plupart des équipes ne traitent que la première. C'est dans la deuxième et la troisième que d'anciens employés, ou des attaquants qui ont volé leurs identifiants, conservent un accès pendant des mois.

Pourquoi « désactiver le compte » ne suffit pas : le cas ConnectWise d'octobre 2026

Le 16 octobre 2026, ConnectWise a publié un avis concernant un accès non autorisé à des identités applicatives connectées à son service Cloud Backup (anciennement SkyKick). L'entreprise a désactivé sept identités applicatives le 17 octobre à 07:00 UTC et révoqué les certificats des connexions concernées. Malgré cela, son propre avis prévenait que « previously issued access tokens may remain usable until they expire or are otherwise invalidated » (les jetons d'accès émis auparavant peuvent rester utilisables jusqu'à leur expiration ou leur invalidation par un autre moyen).

Cette phrase résume à elle seule tout le problème de l'offboarding. Verrouiller la porte d'entrée ne récupère pas les clés déjà distribuées. Les actions recommandées par ConnectWise à ses clients ressemblent à une checklist d'offboarding : examiner les identifiants applicatifs et les relations de fédération (« application credentials and federation trusts »), les autorisations de consentement (« consent grants ») et les modifications récentes de stratégies (« recent policy changes »), rechercher les transferts de messagerie et règles de boîte de réception non autorisés (« unauthorized mailbox forwarding and inbox rules »), examiner les connexions (« sign-ins ») depuis le début de la fenêtre de l'incident, et ne pas supprimer l'application en première réponse (« do not delete the application as the first response »), afin de préserver la configuration et les preuves.

Un employé qui part, c'est la même situation à plus petite échelle : une identité, avec des accès délégués répartis dans des outils dont vous ignorez peut-être l'existence. (Avis de sécurité ConnectWise, consultés le 18 octobre 2026.)

Télécharger le modèle gratuit

Le modèle est un fichier CSV qui s'ouvre directement dans Excel, Google Sheets, LibreOffice ou Numbers. Chaque ligne correspond à une action, avec la phase, un responsable, une échéance relative au dernier jour, la façon de vérifier, et des colonnes pour cocher et dater.

Télécharger le modèle de checklist d'offboarding informatique (CSV)

Mode d'emploi : dupliquez le fichier pour chaque départ, supprimez les lignes des outils que vous n'utilisez pas, ajoutez une ligne pour chaque outil de votre inventaire applicatif, et conservez le fichier complété avec le dossier RH. Une checklist complétée et datée est aussi ce qu'un auditeur vous demandera.

La checklist, phase par phase

Avant le dernier jour : constituer l'inventaire

Vous ne pouvez pas révoquer ce que vous n'avez pas listé. Commencez dès que le départ est connu.

• Listez toutes les applications utilisées par la personne. Votre portail SSO affiche les applications connectées au fournisseur d'identité. Ajoutez les outils hors SSO : facturation, comptes de réseaux sociaux, bureau d'enregistrement du nom de domaine, portails fournisseurs, tout ce qui a été ouvert avec une adresse e-mail professionnelle.
• Listez ce qu'elle possède, pas seulement ce qu'elle utilise. Drives et fichiers partagés, automatisations (Zapier, Make, Power Automate), scripts planifiés, bots, webhooks, enregistrements DNS et noms de domaine, ressources cloud. C'est la propriété qui casse quand le compte est supprimé.
• Listez les secrets qu'elle connaît. Chaque mot de passe partagé, clé Wi-Fi, code d'alarme ou de porte, et compte d'urgence auquel elle avait accès.
• Identifiez les droits d'administration. Le départ d'un administrateur représente un autre niveau de risque : il a pu créer des clés API, des inscriptions d'applications ou des comptes de service que personne d'autre ne connaît.

Le dernier jour : fermer l'identité

• Désactivez (suspendez) le compte SSO ou d'annuaire à l'heure convenue, plutôt que de le supprimer.
• Révoquez les sessions actives. Dans Microsoft Entra ID, la page de l'utilisateur propose une action « Revoke sessions » ; dans Google Workspace, la page de l'utilisateur dans la console d'administration permet de le déconnecter de ses sessions actives. La désactivation seule ne met pas toujours fin à une session déjà ouverte.
• Supprimez les méthodes MFA et les passkeys enregistrées, et réinitialisez le mot de passe pour qu'un mot de passe mis en cache ne puisse pas resservir si le compte est un jour réactivé.
• Retirez la personne des groupes et listes de diffusion, du VPN et de l'accès à distance, ainsi que de la gestion des appareils mobiles (MDM) pour pouvoir effacer les données de l'entreprise de ses téléphones personnels.
• Récupérez le matériel et les clés de sécurité physiques.

Applications et autorisations OAuth : les accès délégués

OAuth est le mécanisme par lequel un utilisateur autorise une application à agir dans une autre (« Autoriser cet outil à lire votre Google Drive »). Ces autorisations ne sont pas des mots de passe : une réinitialisation du mot de passe ne les touche donc pas forcément. Révoquez-les explicitement.

• Google Workspace : sur la page de l'utilisateur dans la console d'administration, la section sécurité liste les applications connectées avec l'accès accordé à chacune. Supprimez-les. La vue à l'échelle du domaine se trouve dans Sécurité, Commandes des API (API controls).
• Microsoft 365 / Entra ID : vérifiez dans « Enterprise applications » les consentements accordés par l'utilisateur, et dans « App registrations » les applications dont il est propriétaire. Une inscription d'application appartenant à une personne qui part contient souvent un secret client qu'elle pourrait encore utiliser.
• Slack, Teams, Notion et outils similaires : passez en revue les applications, bots et webhooks installés par la personne, et réattribuez ou réinstallez ceux que vous gardez sous un compte d'équipe.
• Messagerie : vérifiez les règles de transfert, les règles de boîte de réception et les accès délégués. Une règle de transfert vers une adresse personnelle est l'un des moyens les plus courants par lesquels des données continuent de sortir après un départ.

Clés API, jetons et clés SSH

Ce sont les identifiants qui survivent le plus longtemps, parce qu'ils sont conçus pour fonctionner sans que personne ne se connecte.

• Fournisseurs cloud : dans AWS IAM, listez les clés d'accès de l'utilisateur, désactivez-les, vérifiez que rien ne casse, puis supprimez-les. Le rapport d'identifiants IAM (« credential report ») indique la dernière utilisation de chaque clé. Appliquez la même logique aux clés de comptes de service ailleurs.
• GitHub et GitLab : retirez la personne de l'organisation, et passez en revue les clés de déploiement et les secrets CI des dépôts qu'elle maintenait. Les clés de déploiement et les secrets de dépôt appartiennent au dépôt, pas à la personne : ils restent donc valides après son retrait.
• Clés API SaaS : de nombreux outils (paiement, envoi d'e-mails, analytics, CRM) permettent aux utilisateurs de créer des clés API dans leurs paramètres. Retrouvez celles créées par la personne qui part, renouvelez-les et recréez-les sous un compte de service.
• Secrets que la personne connaissait : toute clé, tout jeton ou toute chaîne de connexion qu'elle a pu lire dans un fichier de configuration, un ticket ou un message de chat doit être renouvelé, même s'il appartient techniquement à l'entreprise.

Mots de passe partagés et coffre-fort de mots de passe

C'est la couche que personne ne peut révoquer : vous pouvez retirer quelqu'un d'un coffre partagé, mais pas de sa mémoire ni d'un export qu'il a réalisé.

• Retirez la personne des coffres et collections partagés dans votre gestionnaire de mots de passe, et transférez la propriété des éléments qu'elle a créés.
• Changez les identifiants partagés qu'elle pouvait lire, en commençant par les plus sensibles : consoles d'administration, finance et banque, domaine et DNS, comptes de réseaux sociaux, comptes d'urgence.
• Utilisez les journaux d'activité pour réduire la liste. Si votre gestionnaire de mots de passe enregistre les éléments ouverts par chaque membre, vous changez ce qu'elle a réellement consulté au lieu de chaque mot de passe partagé. Sans journaux, partez du principe qu'elle a vu tout ce à quoi elle avait accès. Notre guide pour partager des mots de passe en toute sécurité explique pourquoi le chat et l'e-mail sont les pires endroits pour ces secrets.

Après le départ : la revue à 30 jours

• Examinez les journaux de connexion du compte désactivé et des comptes partagés pendant au moins 30 jours. Une connexion réussie après le dernier jour est un signal d'alerte.
• Vérifiez que les intégrations fonctionnent encore après le renouvellement des clés : mieux vaut découvrir une synchronisation nocturne cassée à J+2 qu'à J+30.
• Supprimez le compte uniquement une fois les transferts de propriété confirmés et votre durée de conservation écoulée.
• Mettez à jour l'inventaire avec tout ce que vous avez découvert lors de ce départ, pour que le prochain soit plus rapide.

Où chercher : les accès oubliés par plateforme

Erreurs fréquentes

• Supprimer le compte dès le premier jour. Les fichiers, flux et intégrations appartenant au compte peuvent disparaître ou s'arrêter avec lui, et les journaux dont vous avez besoin partent aussi. Suspendez d'abord.
• Considérer la réinitialisation du mot de passe comme la fin. Dans de nombreux outils, les autorisations OAuth, les clés API et les jetons personnels ne dépendent pas du mot de passe.
• Oublier les outils hors SSO. Les réseaux sociaux, le bureau d'enregistrement et les petits outils SaaS souscrits avec une carte bancaire figurent rarement dans le fournisseur d'identité.
• Ne rien renouveler parce que « nous lui faisons confiance ». L'offboarding n'est pas une question de confiance : les appareils et comptes personnels de l'ancien employé peuvent être compromis plus tard, et chaque secret qu'il connaît encore devient celui de l'attaquant.
• Aucun responsable pour la checklist. RH, informatique et manager supposent chacun qu'un autre s'en est chargé. Mettez un nom sur chaque ligne.

Choisir des outils qui accélèrent l'offboarding

L'offboarding le plus rapide est celui où les accès ont été centralisés dès le départ : applications derrière le SSO, provisionnement via SCIM pour que la désactivation de l'identité retire l'utilisateur partout, et identifiants partagés conservés dans un gestionnaire de mots de passe professionnel plutôt que dans un tableur ou un historique de chat. Si vous comparez les solutions, notre guide du meilleur gestionnaire de mots de passe pour les entreprises couvre les fonctions d'administration et les tarifs, et le guide du provisionnement SCIM de Bitwarden montre à quoi ressemble concrètement un déprovisionnement automatisé. Pour la couche identité elle-même, consultez ce qu'est l'authentification unique (SSO) et où elle s'arrête.