La scène est toujours la même et n’a jamais l’air grave. Quelqu’un de l’équipe part — meilleure offre, déménagement, fin de contrat —, il y a un gâteau, des bons vœux et une checklist de sortie que quelqu’un déroule avec sérieux : rendre le portable, fermer la boîte mail, retirer l’accès au CRM, solder la paie. Tout est en ordre. Et quelque part, le flux que cette personne a monté il y a quatorze mois pour classer les factures qui arrivent par mail démarre encore à 7 h 05, comme chaque matin. Personne ne le note sur la checklist, parce que le processus n’est pas cassé. Il marche. C’est exactement ça, le problème.
La thèse en une ligne : le risque opérationnel de l’IA dans une entreprise sans équipe plateforme n’entre pas par une attaque, il entre par un départ. Pas d’intrusion, pas de faille, rien qu’un antivirus puisse détecter. Juste un processus vivant qui tourne avec l’identité de quelqu’un qui n’est plus là, et une logique qui vivait dans sa tête. La panne n’arrive pas le jour du pot de départ : elle arrive des semaines plus tard, quand un token expire, quand on change un mot de passe, ou quand quelqu’un décide — avec tout le bon sens du monde — de fermer enfin ce compte qui ne servait plus depuis des mois.
Et quand elle arrive, elle arrive sans piste. Ce n’est pas une erreur de code qu’un log explique : c’est un processus qui a cessé de passer et qui ne manque à personne, jusqu’au jour où un client demande où est sa facture.
Que deviennent les automatisations quand un salarié part : rien, jusqu’à ce qu’un identifiant expire
Le mécanisme vaut la peine d’être compris, parce que l’intuition se trompe ici. Quand une personne part, son automatisation ne s’arrête pas. Les flux ne sont pas attachés au contrat de travail : ils sont attachés à des identifiants, et les identifiants survivent à la personne, par construction. Un token d’API reste valide jusqu’à sa date d’expiration. Une autorisation OAuth accordée à un outil tient debout tant que le compte qui l’a accordée existe. Une clé collée dans le panneau d’un connecteur ne sait pas si celui qui l’a collée est toujours dans l’entreprise.
Donc le jour du départ, rien de visible ne se produit, et ça fabrique la fausse impression qu’il n’y avait pas de dépendance. Il y en a une, et elle se matérialise à l’un de ces quatre moments, toujours avec des semaines ou des mois de retard :
- Le token expire. Presque tout identifiant d’intégration a une durée de vie limitée. Le jour où il expire, le flux se met à renvoyer une erreur d’authentification que personne ne lit, parce que les notifications partaient vers la boîte mail de celui qui est parti.
- On supprime le compte pour de bon. Au début on suspend l’utilisateur pour ne rien casser. Des mois plus tard, pendant un nettoyage de licences — une conversation de coût, pas de risque —, on le supprime. Et avec lui partent toutes les autorisations qu’il avait accordées.
- Quelque chose change de l’autre côté. Le prestataire met à jour son API, la banque change le format du relevé, le CRM renomme un champ. Le flux a besoin d’un réglage de dix minutes que seul quelqu’un comprenant pourquoi il est monté comme ça peut faire.
- Une nouvelle exception apparaît. Le cas tordu que la logique ne couvrait pas. La personne partie savait quoi en faire parce que c’est elle qui l’avait décidé ; celle qui reste ne sait même pas que cette décision existait.
Ce n’est pas du shadow AI, et ça ne se règle pas en comptant les agents
On confond ça avec deux problèmes voisins, et la confusion coûte cher, parce que les trois choses se règlent avec des leviers différents.
Le shadow AI, c’est de l’usage non autorisé : des gens qui utilisent des outils que l’entreprise n’a pas validés. C’est un problème de demande non servie, et ça se règle en ouvrant une voie officielle. L’inventaire, c’est un problème de comptage : ne pas savoir combien d’automatisations tu as ni ce qu’elles touchent. Ça se règle en regardant.
Le départ, c’est autre chose : c’est du cycle de vie. Une automatisation peut être parfaitement autorisée, parfaitement inventoriée et parfaitement décrite dans un tableur, et rester fragile, parce que ce qui lui manque n’est ni une permission ni un registre : il lui manque un propriétaire vivant et une identité à elle. Un inventaire te dit que le flux existe. Il ne te dit pas qu’il tourne avec les identifiants de Claire, et que Claire est partie en mars.
La différence pratique : le shadow AI et l’inventaire se règlent avec une photo. Le cycle de vie ne se règle qu’avec un processus, parce que les gens vont continuer d’entrer et de sortir de ton entreprise tant qu’elle existera.
Le chiffre : le marché ne sait toujours pas révoquer les identifiants d’un agent
Il y a un chiffre qui mérite de l’attention, non pas parce qu’il parle des PME — il n’en parle pas — mais pour qui il mesure. Dans son rapport 2026 Identity Security Landscape, appuyé sur une enquête auprès de 2 930 responsables de la sécurité dans le monde, Palo Alto Networks publie deux chiffres qui, lus ensemble, décrivent ce trou mieux que n’importe quelle anecdote : 99 % des organisations ont déjà adopté des agents d’IA, et seules 37 % peuvent révoquer les identifiants d’un agent. Seules 30 % tiennent une journalisation d’audit immuable de ce que font ces agents. Source : How to Assess Maturity When Machine Identities Outnumber Humans 109:1, Palo Alto Networks, mai 2026.
Le périmètre compte et il faut le dire clairement : c’est une enquête mondiale auprès de grandes entreprises, avec une équipe sécurité, un budget et un CISO qui remplit le questionnaire. Ce n’est pas un échantillon de PME françaises, ni espagnoles, ni italiennes. Mais c’est justement ce qui en fait un plancher utile : si deux organisations sur trois ayant une équipe sécurité n’arrivent pas à couper l’accès d’un agent, la question de ce qui se passe dans une boîte de quarante personnes où le responsable des opérations a monté le flux un jeudi après-midi se répond toute seule.
Le même rapport pointe exactement où est le creux : la plupart des organisations savent expliquer à quoi sert chaque agent, et beaucoup moins savent définir à quoi il accède, comment on borne cet accès, quand on révoque ses permissions et quels autres systèmes héritent de cet accès. Ce n’est pas un problème de méconnaissance de la finalité. C’est un problème de fin de vie.
| Ce que la checklist de sortie couvre bien | Ce qu’elle ne couvre pas | Ce qui casse |
|---|---|---|
| Mail, portable, accès au CRM, solde de paie | Les identifiants avec lesquels tournent ses automatisations | Le flux reste vivant sous l’identité de quelqu’un qui n’est plus là |
| Passation des clients et des tâches ouvertes | Le jugement avec lequel elle tranchait les cas tordus | À la première exception nouvelle, personne ne sait la résoudre |
| Retirer la personne des listes de diffusion | Rediriger les alertes d’erreur de ses flux | La panne arrive et l’avertissement part vers une boîte fermée |
| Signer le départ dans la GED | Noter qui hérite de ce processus | Le processus se retrouve sans propriétaire sans que personne l’ait décidé |
Les trois questions qui manquent à ta checklist de sortie
Pas besoin d’un projet pour refermer ça. Il faut trois questions dans l’entretien de départ, posées avant le dernier jour, quand la personne est encore là et a encore envie d’aider :
- Avec quelle identité tourne chaque chose que tu as montée ? Pas « qu’est-ce que tu as monté » : avec quel compte. La réponse utile, c’est une liste de flux et, à côté de chacun, le compte ou la clé qu’il utilise. Si une ligne dit « mon compte », tu viens d’identifier ton travail de lundi. C’est la question qui décide si un départ est une formalité ou un incident reporté.
- Qu’est-ce que tu as décidé qui n’est écrit nulle part ? Toute automatisation utile a une couche de jugement absente de la configuration : ce qui compte comme facture en double, quand un mail mérite une réponse humaine, quel fournisseur est l’exception habituelle. Une demi-heure à enregistrer cette personne racontant les cas tordus vaut plus que n’importe quel manuel écrit à la va-vite.
- Qui ça doit prévenir quand ça casse ? Pas « qui tu prévenais, toi ». Qui ça doit prévenir désormais. Un flux dont les alertes partent vers une boîte qui va fermer est un flux qui échoue déjà en silence, sauf que tu ne le sais pas encore.
Les trois tiennent dans une réunion de quarante minutes et règlent l’essentiel du risque. La version complète de la première — quelle identité, avec quelle portée et ce qu’elle peut toucher — est développée dans le guide sur les permissions d’un agent IA, qui est là où se décide si cet entretien de départ est pénible ou trivial.
Que faire si la personne est déjà partie
Le cas le plus fréquent n’est pas le préventif : c’est le réactif, avec la personne dehors depuis trois mois et plus personne de sûr de ce qui tourne encore. Ordre de travail, du moins cher au plus cher :
- Ne supprime pas encore le compte. C’est tentant de le fermer par hygiène, et c’est la façon la plus rapide de transformer un risque latent en interruption de service. Suspends l’accès interactif — que personne ne puisse se connecter avec — et laisse les identifiants d’intégration vivants jusqu’à la fin de l’étape 3.
- Regarde ce qui se passe encore sous cette identité. Les journaux d’accès de tes outils principaux (mail, CRM, ERP, la plateforme d’automatisation) te disent quelle activité porte encore le nom de ce compte. C’est ça, ton inventaire réel, bien meilleur que celui que tu monterais de mémoire.
- Réémets chaque identifiant au nom de l’entreprise. Crée un compte de service avec des permissions bornées par flux et réauthentifie les connexions. C’est un travail ennuyeux, d’un après-midi, et c’est le seul qui supprime le problème au lieu de le reporter.
- Redirige les alertes vers une boîte d’équipe. Pas vers une autre personne : vers une adresse qui survivra au prochain départ. C’est ce qui transforme la prochaine panne en quelque chose que quelqu’un lit.
- Écris la logique que tu récupères pendant que tu la récupères. Ce que te racontent les journaux et ceux qui restent, écris-le sur le moment. Ce document ne s’écrira pas après ; il ne s’écrit jamais après.
Si pendant l’étape 2 tu découvres qu’un flux échoue depuis des semaines sans que personne le sache, le problème n’est plus le départ : c’est que personne ne regardait. C’est une autre conversation, et elle est dans le guide sur qui répond quand une automatisation tombe.
L’erreur de conception est en amont, le jour où on l’a monté
Tout ce qui précède est de la gestion de dégâts. La cause est bien plus tôt et bien moins chère à corriger : le jour où quelqu’un a monté le flux avec son propre compte parce que c’était ce qu’il avait sous la main et que ça marchait. Personne n’a rien fait de mal. Simplement personne n’a décidé le contraire, parce que la décision ne figurait sur aucune liste.
Pour que ça ne se reproduise pas, trois règles qui ne coûtent pas d’argent, seulement un accord : aucune automatisation ne tourne avec le compte d’une personne — comptes de service aux permissions bornées, toujours — ; chaque flux vivant a un nom à côté, celui qui en répond, et on revoit ce nom dès que quelqu’un change de poste ; et les alertes partent vers une boîte d’équipe, jamais vers un individu. Les trois ensemble transforment un départ en formalité administrative, ce qu’il devrait être. Le cadre complet de cette décision est dans le guide sur la gouvernance et le contrôle de l’automatisation avec IA.
Et il y a un cas où aucune règle interne n’arrive : quand la personne qui a monté le système n’a jamais été de la maison. Si c’est un consultant ou une agence qui a levé tes automatisations, le jour où le contrat se termine la même scène se rejoue exactement, à la différence qu’il n’y a ni entretien de départ ni pot d’adieu. C’est pour ça que maintenir ce qui tourne est un service et pas une faveur : quelqu’un doit maintenir les agents IA quand celui qui les a montés n’est plus là, et cette question se tranche avant de signer, pas après.
Une automatisation qu’une seule personne comprend n’est pas un actif. C’est une dette à échéance inconnue, et l’échéance, c’est le marché du travail qui la fixe, pas toi.