Quand un employé part, le risque urgent n'est pas la lettre de démission — c'est la demi‑heure entre la notification RH et la première reconnexion non autorisée.

Lorsqu'un employé part, le risque urgent n'est pas la lettre de démission — c'est la demi‑heure entre la notification des RH et la première reconnexion non autorisée. Ce guide est une checklist pratique à exécuter le jour même pour l'offboarding de l'accès distant afin que vous puissiez révoquer l'accès aux appareils d'un employé partant le jour même et ne rien laisser d'utile derrière.

Checklist rapide et pratique en 12 étapes

Faire l'inventaire : lister les appareils, sessions, comptes de service, agents et accès VPN/RMM liés à l'utilisateur.
Désactiver immédiatement l'identité utilisateur (AD / Azure AD / IdP).
Terminer les sessions distantes actives et révoquer les clés ou jetons de session.
Désenregistrer ou révoquer les certificats d'appareil utilisés par les agents d'accès distant.
Bloquer l'accès réseau de l'appareil (VPN, règles de pare‑feu) s'il est géré par l'entreprise.
Faire pivoter les mots de passe et secrets des comptes partagés auxquels l'utilisateur a eu accès, dans les 24 heures.
Retirer l'utilisateur des groupes privilégiés et des listes d'administrateurs locaux.
Désinstaller ou désactiver les agents d'accès distant sur les terminaux connus ; si impossible, bloquer les enregistrements d'agent.
Révoquer les clés SSH et jetons API que la personne possédait ou utilisait.
Collecter les artefacts forensiques et rédiger un bref journal d'incident avec actions et horodatages.
Auditer les logs de votre relay/proxy et des hôtes cibles pour confirmer les déconnexions.
Communiquer l'état à la RH et à la sécurité ; confirmer la complétion par écrit.

Ce qu'il faut révoquer (et pourquoi c'est important)

L'offboarding de l'accès distant consiste à supprimer chaque identifiant ou artefact pouvant servir à rétablir une session. Cela inclut trois catégories : les identifiants d'identité (comptes utilisateurs, dispositifs MFA), l'authentification des appareils (certificats, enregistrements d'appareil), et l'authentification de session (jetons de session actifs, clés SSH, jetons API).

Vérité importante sur les relais et les connexions directes : lorsque deux endpoints se connectent en peer‑to‑peer, la session est de bout en bout entre ces appareils. Quand une connexion bascule vers un relay, TLS se termine au niveau du relay — donc l'opérateur de ce relay peut observer la session. Pour cette raison, vous devez considérer à la fois les certificats d'appareil et les enregistrements sur le relay comme une surface d'attaque révoquable.

Étapes détaillées par plateforme et plan de contrôle

Vous trouverez ci‑dessous des commandes et modèles pragmatiques à adapter. Exécutez toujours ces commandes depuis une machine de gestion ou un jump box et testez sur un seul appareil avant toute automatisation à grande échelle.

Windows (Active Directory et endpoints)

Actions immédiates:

Désactiver le compte AD : Disable-ADAccount -Identity "jsmith" (nécessite le module ActiveDirectory).
Bloquer la connexion pour les utilisateurs Azure AD (si vous utilisez Azure AD) : soit désactiver le compte via votre IdP, soit utiliser les commandes Graph API.
Terminer les sessions RDP/distantes : exécutez query user / logoff <ID> sur l'hôte, ou utilisez votre console de gestion distante pour terminer les sessions.
Retirer les droits d'administrateur local : Remove-LocalGroupMember -Group "Administrators" -Member "DOMAIN\jsmith" (PowerShell 5.1+).
Désinstaller ou arrêter le service d'agent distant : Stop-Service -Name "RemoteAgent" -Force; sc.exe delete "RemoteAgent" — remplacez le nom du service par celui de votre agent.

macOS et Linux

Actions immédiates:

Verrouiller ou désactiver le compte utilisateur : macOS : sudo dscl . -passwd /Users/jsmith "" (ou utilisez votre MDM). Linux : sudo usermod -L jsmith && sudo chage -E 0 jsmith.
Supprimer les clés SSH de ~/.ssh/authorized_keys sur les hôtes gérés. Exemple (remplacez le commentaire ou l'empreinte) :
```
ssh admin@host 'sed -i "/user-ssh-key-comment/d" ~/.ssh/authorized_keys'
```
Arrêter et désactiver les services d'agent distant :
```
ssh admin@host 'sudo systemctl stop remote-agent.service && sudo systemctl disable remote-agent.service'
```
— remplacez par le nom du service de votre agent.

SSH, jetons API et comptes de service

Les clés SSH partagées ou personnelles et les jetons API sont des artefacts à haute valeur. Faites pivoter toute information d'identification partagée à laquelle l'utilisateur pouvait accéder. Pour SSH, supprimez les clés autorisées et faites pivoter les clés d'hôte si une exposition est incertaine. Pour les API et les systèmes CI/CD, révoquez tous les jetons émis à l'utilisateur et faites pivoter les jetons utilisés par l'automatisation que l'utilisateur pouvait modifier.

Comment révoquer en toute sécurité l'enregistrement d'un agent distant / d'un appareil

Chaque agent distant maintient généralement une identité d'appareil — un certificat, une entrée d'enregistrement sur un relay ou un registre d'appareils. Votre procédure d'offboarding doit supprimer à la fois l'enregistrement et tout certificat ou jeton permettant le réenregistrement.

Désenregistrement via la console : utilisez votre console d'administration d'accès distant pour désenregistrer ou mettre en quarantaine l'appareil. Cela empêche de nouvelles connexions et invalide les identifiants d'appareil à longue durée de vie.
Bloquer les enregistrements d'agent au niveau du relay : si vous exploitez un relay géré, créez une règle de refus pour cet ID d'appareil ou empreinte jusqu'à ce que vous puissiez réinstaller l'image de la machine ou effectuer un effacement sur site.
Désinstaller l'agent quand c'est possible — mais ne comptez pas sur l'action de l'utilisateur. Si l'appareil est distant et injoignable, bloquez l'accès réseau et révoquez l'identité de l'appareil depuis votre relay.

Modèles d'automatisation et scripts rapides

L'automatisation réduit les erreurs humaines lors d'un offboarding sensible au temps. Ci‑dessous deux scripts modèles à adapter — un PowerShell pour les tâches AD/Windows et un Bash pour les opérations sur hôtes Linux. Remplacez les variables et noms de services par ceux de votre environnement et testez d'abord dans un environnement de préproduction.

# PowerShell template (run from admin workstation with AD module)
$User = 'jsmith'
# Disable AD account
Disable-ADAccount -Identity $User
# Remove from local Administrators on a list of machines
$computers = @('PC01','$PC02')
foreach ($c in $computers) {
  Invoke-Command -ComputerName $c -ScriptBlock {
    param($u)
    Remove-LocalGroupMember -Group 'Administrators' -Member $u -ErrorAction SilentlyContinue
    # Stop remote agent service (replace 'RemoteAgent' with your agent)
    Stop-Service -Name 'RemoteAgent' -Force -ErrorAction SilentlyContinue
    sc.exe delete 'RemoteAgent' | Out-Null
  } -ArgumentList $User
}
# Rotate shared password note: call your password manager or runbook here
Write-Output 'Disabled account, removed local admin, stopped agent (where reachable)'

# Bash template (run from admin host)
USER=jsmith
HOSTS=(host1.example.com host2.example.com)
for h in "${HOSTS[@]}"; do
  ssh admin@${h} "sudo usermod -L ${USER} && sudo chage -E 0 ${USER} || true"
  ssh admin@${h} "sudo sed -i '/user-ssh-key-comment/d' /home/${USER}/.ssh/authorized_keys || true"
  ssh admin@${h} "sudo systemctl stop remote-agent.service || true; sudo systemctl disable remote-agent.service || true"
done
echo 'Locked accounts, removed ssh keys and disabled agent service where reachable.'

Vérification : prouver que l'appareil ne peut plus accéder à rien

La révocation sans vérification est une illusion d'hygiène. Votre checklist doit inclure des étapes de vérification strictes avec horodatages.

Vérifier les sessions actives : hôtes Windows : query user / quser. Linux : who et ss -tnp pour lister les connexions actives.
Auditer votre relay : vérifier que l'enregistrement ou le certificat de l'appareil est absent du registre du relay et qu'aucune session n'a été initiée par l'appareil après la révocation.
Confirmer que les logs de l'IdP indiquent la désactivation du compte et qu'aucune authentification réussie n'a eu lieu après votre action.
Confirmer la rotation des identifiants pour les comptes partagés, et lister les secrets tournés dans votre journal d'incident (ne collez pas les secrets dans les logs).
Collecter des captures d'écran/exports des logs et les stocker avec les dossiers RH et de sécurité.

Quand auto‑héberger votre relay ou utiliser un relay géré

Utilisez un relay géré par défaut. Un relay géré — en particulier le relay multi‑région de Tenvo — vous sort du cycle de maintenance : il gère la délivrance des certificats, la disponibilité et le basculement multi‑région prêts à l'emploi. Tenvo propose des clients natifs pour macOS, Windows et Linux, un client navigateur en bêta publique, et des paliers tarifaires pour le relay géré (Free $0 / Lite $2.99/mo / Pro $7.99/mo).

L'auto‑hébergement n'est pertinent que lorsqu'une exigence écrite l'impose : une règle de conformité qui interdit des infrastructures tierces, un réseau entièrement isolé, ou une exigence de résidence des données que votre fournisseur ne peut satisfaire. L'auto‑hébergement vous oblige à prendre en charge la permanence d'astreinte, le patching, le renouvellement des certificats, la garde des clés et le basculement multi‑région — ces coûts dépassent généralement le prix d'un relay géré dès que l'on prend en compte la réponse aux incidents et les SLA de disponibilité. Si vous devez auto‑héberger, consultez nos recommandations détaillées sur Remote Desktop auto‑hébergé : pourquoi, comment et ce qui casse.

Vérifications post‑offboarding, documentation et retours d'expérience

Effectuez ces actions post‑offboarding dans les 24–72 heures :

Effectuer une réconciliation des logs d'audit et exporter les logs vers votre archive longue durée. Voir nos recommandations sur journalisation d'audit pour remote‑desktop.
Réaliser un snapshot forensique rapide de l'appareil s'il existe un soupçon de compromission.
Mettre à jour les runbooks d'onboarding/offboarding et ajouter des métriques de durée : combien de temps chaque étape a réellement pris, ce qui a échoué et où l'automatisation est nécessaire.
Former les RH et les premiers intervenants sur le runbook d'offboarding afin que l'équipe technique reçoive la notification plus tôt.

Pièges pratiques et anti‑patterns

Erreurs courantes qui prolongent l'exposition :

Attendre de désactiver le compte IdP jusqu'à ce que le manager demande un accès final — désactivez d'abord, vérifiez ensuite.
Supposer qu'une désinstallation par l'utilisateur supprime les certificats ; elle laisse souvent des clés dans le profil utilisateur.
Ne faire tourner que les mots de passe sans toucher aux jetons API, clés SSH ou identifiants de comptes de service que l'utilisateur pouvait modifier.
Compter uniquement sur le blocage VPN ; si un agent maintient une connexion sortante, il peut se réenregistrer une fois le VPN rétabli à moins que l'identité de l'appareil ne soit révoquée.

Où cela s'intègre dans un programme de sécurité plus large

L'offboarding de l'accès distant fait partie du cycle de vie des identités et de l'hygiène des endpoints. Rattachez ces actions aux notifications RH (tickets automatisés), à votre PAM/vault pour la rotation des secrets, et à votre SIEM pour les audits. Pour un modèle de menace et des contrôles plus approfondis, notre article Remote Desktop sécurisé ? Un modèle de menace honnête décrit où les agents distants sont couramment abusés et quels contrôles réduisent le risque.

Pour les équipes qui gèrent de nombreux utilisateurs et endpoints, combinez l'offboarding avec des contrôles d'accès basés sur les rôles, des identifiants à courte durée de vie et des vérifications de posture des appareils afin de réduire le nombre d'étapes manuelles à exécuter en cas d'urgence.

Checklist finale (une page que vous pouvez copier)

Inventaire : IDs d'appareil, versions d'agent, sessions actives — horodatés.
Désactiver l'identité à l'IdP immédiatement.
Terminer les sessions distantes et confirmer via les logs hôtes.
Désenregistrer l'appareil du relay et révoquer les certificats d'appareil.
Bloquer l'accès réseau si l'appareil est injoignable.
Désinstaller/désactiver l'agent lorsque possible ; bloquer les nouvelles inscriptions au relay.
Faire pivoter les identifiants partagés et révoquer les jetons/clés SSH.
Exporter et archiver les logs ; créer une note d'incident avec horodatages et intervenants.
Communiquer aux RH et à la sécurité et clôturer le ticket une fois vérifié.

L'offboarding de l'accès distant est un travail opérationnel, pas une checklist théorique. Exercez le processus sur un utilisateur de test, automatisez les étapes triviales et consignez un horodatage pour chaque action. Si vous rencontrez une politique qui exige l'auto‑hébergement, lisez d'abord Remote Desktop auto‑hébergé : pourquoi, comment et ce qui casse — vous constaterez souvent que le coût opérationnel dépasse le contrôle perçu.

Si vous recherchez un outil pratique qui évite les problèmes de redirection de ports et qui vous fournit un relay géré avec une gamme de prix prévisibles, des clients natifs et une option navigateur en bêta, essayez Tenvo — téléchargez le client et testez votre runbook d'offboarding sur Télécharger Tenvo.

Offboarding de l'accès distant : révoquer l'accès aux appareils le jour même