← Retour à toutes les analyses
Gouvernance · 5 min de lecture

Départ d’un salarié : quels accès IA faut-il révoquer ?

Désactiver le compte d’un salarié ne coupe pas toujours les automatisations, jetons et comptes techniques liés à ses outils. Voici le contrôle à prévoir.

Publié le · Par Équipe Pulse

Le commercial quitte l’entreprise vendredi. Son compte Google est désactivé, son accès au CRM supprimé et son ordinateur rendu. Le dossier semble clos.

Lundi matin, une automatisation continue pourtant de lire les nouveaux prospects, d’enrichir leurs fiches et de préparer des relances. Elle fonctionne avec un jeton créé six mois plus tôt, un compte technique partagé ou une connexion autorisée dans un outil tiers. Le salarié est parti. Son ancien workflow, lui, travaille encore.

Ce risque peut apparaître dès qu’une PME relie une IA au CRM, à la messagerie, aux documents ou à un outil métier. Le problème ne vient pas forcément du modèle. Il vient d’un départ traité comme une simple suppression de compte, sans inventaire des accès indirects.

À noter — Cet article présente une méthode opérationnelle générale. Il ne remplace pas l’analyse de votre DPO, de votre RSSI ou de votre conseil juridique adaptée à votre situation.

Un utilisateur, plusieurs portes d’entrée

Une même automatisation peut utiliser plusieurs moyens d’accès :

  • le compte personnel du salarié ;
  • une autorisation OAuth accordée à une application ;
  • une clé API copiée dans un outil d’automatisation ;
  • un compte de service créé pour l’équipe ;
  • une boîte email ou un dossier partagé ;
  • un webhook qui continue de recevoir des données.

Couper le compte principal peut arrêter certaines connexions, mais pas toutes. Un compte de service appartient parfois à l’entreprise. Une clé API peut rester valable. Une automatisation peut aussi avoir été créée dans l’espace personnel du salarié tout en manipulant des données collectives.

Il faut donc répondre à deux questions distinctes : qui quitte l’entreprise, et quelles autorisations dépendent encore de cette personne ?

Ce que l’IA peut préparer avant le départ

Si elle peut consulter en lecture seule les annuaires, inventaires d’applications et journaux autorisés, une IA supervisée peut aider à constituer le dossier de sortie. Elle ne découvre pas d’elle-même les connexions ou secrets absents de ces sources.

Elle peut notamment préparer :

  1. les applications connectées au compte du salarié ;
  2. les références des clés, jetons et webhooks — propriétaire, portée, emplacement, dernière utilisation et date de rotation — sans jamais exposer leur valeur secrète ;
  3. les comptes techniques auxquels il avait accès ;
  4. les dossiers, boîtes partagées et espaces CRM concernés ;
  5. les automatisations encore actives et leur responsable métier.

Cette liste reste une proposition de contrôle. L’IA ne doit pas supprimer seule une connexion, car une coupure mal préparée peut interrompre un processus commercial ou faire perdre la visibilité sur des actions en cours.

Les permissions rattachées au compte du salarié doivent être révoquées dès son départ. Les accès portés par un compte de service ou une clé appartenant à l’entreprise doivent être traités séparément : les inventorier, les rattacher à un responsable, puis les révoquer, les réattribuer ou les maintenir avec les droits minimaux après validation.

Le contrôle à réaliser le jour du départ

La CNIL recommande de supprimer les permissions dès qu’une personne n’est plus habilitée ou à la fin de son contrat. Elle rappelle aussi le principe de moindre privilège : chaque utilisateur ne doit accéder qu’aux données nécessaires à sa mission.[1]

Pour une automatisation IA, appliquez aussi le principe du moindre privilège : lecture et préparation lorsque cela suffit, sans autorisation d’agir automatiquement. À partir de ces principes, Pulse propose le contrôle opérationnel suivant :

Accès ou automatisation Situation constatée Décision attendue
Connexion personnelle au CRM Le salarié en était propriétaire Révoquer la connexion et désigner un nouveau responsable
Clé API utilisée par l’équipe La clé est connue de plusieurs personnes Révoquer et remplacer la clé, la stocker dans un gestionnaire de secrets et limiter son accès nominativement
Compte de service Le workflow reste nécessaire Conserver le compte avec des droits minimaux et un propriétaire identifié
Relances préparées Des brouillons sont encore en attente Suspendre le workflow et faire relire la file
Dossier partagé Des données clients restent accessibles Retirer l’ancien utilisateur et vérifier les autres membres
Webhook actif La destination n’est plus documentée Suspendre le flux jusqu’à clarification

La personne qui valide doit comprendre la conséquence métier. Couper une clé peut arrêter plusieurs scénarios. La conserver sans propriétaire crée une zone aveugle. Dans les deux cas, la décision mérite une trace.

Les comptes partagés compliquent tout

Un compte générique utilisé par plusieurs personnes empêche de savoir facilement qui a fait quoi. La CNIL recommande des identifiants individuels et déconseille les comptes partagés sans exception documentée, validée et revue.[1][2]

Si un compte technique reste nécessaire, il doit avoir :

  • un propriétaire métier ;
  • un responsable technique ;
  • une liste claire de permissions ;
  • une méthode de renouvellement des secrets ;
  • une date de prochaine revue.

L’objectif n’est pas d’attribuer artificiellement le compte à la personne qui vient de partir. Il faut rattacher l’automatisation à une fonction de l’entreprise et rendre sa responsabilité visible.

Vérifier ce qui s’est passé après la coupure

La seule désactivation du compte principal ne suffit pas toujours. Il faut contrôler que les flux se sont réellement arrêtés ou qu’ils ont été repris par le bon compte.

La CNIL indique que la journalisation peut aider à tracer les activités et à détecter des accès frauduleux ou des usages abusifs. Elle précise que les journaux doivent servir à la sécurité et au bon usage du système, sans être conservés plus longtemps que nécessaire.[2]

Après le départ, vérifiez donc :

  • si l’ancien identifiant tente encore de se connecter ;
  • si une clé ou un compte de service poursuit des actions inattendues ;
  • si des brouillons, tâches ou exports sont restés sans responsable ;
  • si les nouvelles autorisations correspondent bien au rôle du repreneur.

Dans un environnement autorisé et à partir des seuls événements nécessaires, l’IA peut aider à résumer les journaux et à signaler des écarts à faire vérifier. La décision de réactiver, de réattribuer ou de supprimer un accès reste humaine, selon une procédure de validation explicite.

Le test à faire cette semaine

Choisissez un workflow IA utilisé par l’équipe commerciale ou administrative. Imaginez que son propriétaire quitte l’entreprise demain.

Pouvez-vous identifier en moins de quinze minutes :

  • les outils auxquels il accède ;
  • le compte qui porte chaque connexion ;
  • la personne capable de suspendre le workflow ;
  • les actions en attente ;
  • le journal permettant de vérifier l’arrêt ?

Si la réponse dépend de la mémoire d’une seule personne, le workflow n’est pas encore exploitable sereinement. Avant d’ajouter une nouvelle automatisation, donnez un propriétaire, une procédure de sortie et une date de revue à celle qui existe déjà.

Sources

[1] https://www.cnil.fr/fr/securite-gerer-les-habilitations — Sécurité : gérer les habilitations, CNIL, 13 mars 2024

[2] https://www.cnil.fr/fr/gerer-les-utilisateurs — Gérer les utilisateurs, CNIL, 27 janvier 2020