Une automatisation zombie n'est pas cassée : elle tourne et ne sert à personne
Quand quelqu'un se demande quoi faire des automatisations que plus personne n'utilise, il pense presque toujours à des flux cassés. Ce n'est pas ça. Un flux cassé prévient : il plante, il envoie un mail rouge, quelqu'un râle et c'est réparé le matin même. Un zombie, lui, marche. Il s'exécute à l'heure, fait exactement ce qu'on lui a demandé il y a deux ans et livre son résultat à un processus qui n'existe plus.
Le rapport généré chaque lundi pour un comité dissous. La synchro qui déverse des commandes dans une feuille que personne n'ouvre depuis mars. L'avis qui tombe dans un canal Slack archivé. Le mail hebdomadaire qui arrive sur un alias où trois personnes ont une règle « marquer comme lu ». Tous verts, tous corrects, tous inutiles.
Ils survivent parce que personne ne se plaint. Un flux cassé a un propriétaire de fait —celui qui subit l'erreur— ; un zombie n'a personne : celui qui l'a demandé a changé d'équipe, celui qui l'a monté est parti, et celui qui le voit dans le tableau de bord ne sait pas qui en dépend. Dans le doute, personne n'y touche. Et ça dure depuis trois ans.
Le problème, c'est qu'ils ne sont pas gratuits. Ils consomment des opérations ou des exécutions de ton forfait, et c'est de l'argent réel dès que ton outil facture au volume. Ils maintiennent des identifiants vivants —jetons, comptes de service, intégrations OAuth— souvent avec droit d'écriture sur ton CRM ou ton ERP. Et ils polluent le diagnostic : à chaque incident, quelqu'un perd une demi-heure à écarter des flux qui n'ont aucune importance avant d'arriver à celui qui compte. Ce guide zoome sur la partie de la maintenance des automatisations IA qui consiste à retirer le mort, pas à soigner le vivant.
L'inventaire réel, pas celui que tu crois avoir
Le premier obstacle n'est pas de décider quoi éteindre : c'est de savoir ce que tu as d'allumé. Presque aucune entreprise ne le sait, parce que les flux ne vivent pas au même endroit. L'onglet principal de ton outil d'automatisation, c'est la partie émergée de l'iceberg.
Les six cachettes habituelles, par ordre du nombre de flux qui en sortent quand on soulève le tapis :
- L'outil principal (Make, n8n, Zapier, Power Automate), dossiers des autres utilisateurs compris, et scénarios « privés » de celui qui les a montés.
- Les flux natifs à l'intérieur de chaque SaaS : workflows HubSpot, règles Salesforce, automatisations Notion ou Airtable. Personne ne les compte comme des automatisations et ils sont légion.
- Les scripts programmés : Apps Script dans Google Workspace, macros à déclencheur, cron sur un serveur administré par quelqu'un qui n'est plus là.
- Les tâches planifiées du cloud : Cloud Scheduler, EventBridge, jobs d'un conteneur. C'est là que vit ce qui coûte cher.
- Les webhooks entrants qui pointent vers tes propres endpoints : invisibles dans le moindre tableau de bord d'automatisation, visibles seulement dans les logs du serveur.
- Les agents et les prompts en production avec leur propre déclencheur, qui dans beaucoup d'entreprises sont déjà la couche la plus récente et la plus mal inventoriée.
Chaque ligne de l'inventaire a besoin de sept colonnes, pas une de plus : nom, ce qu'il produit (la sortie concrète, pas « gère les commandes »), qui la consomme, dernière exécution, fréquence, identifiants utilisés et droits de ces identifiants. La colonne qui fait tout le travail, c'est la troisième. Si tu ne peux pas écrire un nom propre —une personne ou un système identifiable— dans « qui la consomme », tu tiens déjà ton candidat sans avoir besoin d'enquêter plus loin.
Exécution n'est pas usage : comment savoir si un flux sert vraiment
C'est là que tout le monde se plante : on trie la liste par « dernière exécution » et on valide ceux qui ont tourné hier. Sauf qu'un zombie s'exécute ponctuellement tous les jours —c'est littéralement sa définition—. L'exécution mesure que le flux est vivant, pas que son résultat intéresse quelqu'un. Ce sont deux questions distinctes et une seule est celle que tu cherches à trancher.
Trois signaux mesurent vraiment l'usage, et lequel prendre dépend de ce que le flux fait au bout :
S'il écrit dans un système
Regarde l'enregistrement qu'il produit, pas le flux. Est-ce que quelqu'un ouvre ce document ? Est-ce que cette ligne est modifiée après sa création ? Est-ce que le champ qu'il remplit apparaît dans un rapport ou une vue que quelqu'un consulte ? Les suites bureautiques et les CRM gardent la date du dernier accès : c'est la donnée la plus honnête que tu trouveras et presque personne ne la regarde.
S'il notifie
Est-ce que quelqu'un répond, réagit ou clique ? Un canal archivé, une liste de diffusion avec règle d'archivage automatique ou un avis qui cumule huit cents messages sans une seule réponse, c'est la même chose : personne ne lit. Si ta plateforme de messagerie te laisse voir les lectures ou les réactions, tu as la réponse en une minute.
S'il alimente un autre flux
Vérifie si cet autre flux figure lui aussi dans ta liste de douteux. Les zombies viennent en chaîne : quelqu'un a éteint le consommateur final il y a un an et a laissé vivante toute la tuyauterie qui le nourrissait. C'est celle qui fait gagner le plus quand elle apparaît, parce qu'il en tombe une demi-douzaine d'un coup.
Quand aucun signal n'est concluant —et ça arrivera dans un tiers des cas— il reste une méthode pas chère, honnête et étonnamment peu utilisée : le test du silence. Tu éteins le flux, tu laisses un avis visible à sa place (un message automatique « c'est en pause, écris ici si tu en as besoin », une note dans la feuille, une ligne épinglée dans le canal) et tu attends un cycle métier complet. Un mois suffit d'habitude ; un trimestre si le processus est trimestriel. Si personne ne réclame, tu as ta réponse.
La règle qui rend le test du silence légitime au lieu d'une roulette : on éteint avec préavis et avec fenêtre, jamais en douce. Éteindre en cachette pour voir ce qui se passe, c'est le moyen le plus rapide pour que plus personne n'autorise le prochain nettoyage.
Éteindre n'est pas supprimer : les trois mouvements
La vraie raison pour laquelle personne n'éteint rien, c'est qu'« éteindre » sonne irréversible. Et ça y ressemble, parce que dans la tête de tout le monde éteindre, retirer les droits et supprimer sont la même action. Elles ne le sont pas. Il y en a trois, avec des risques et des calendriers différents, et les séparer, c'est ce qui débloque la décision :
- Arrêter l'exécution. Tu désactives le déclencheur. Réversible en un clic, coût zéro, et c'est ce que tu fais le jour un. Ça n'efface rien : le flux est toujours là, son historique intact.
- Révoquer l'accès. Tu retires l'identifiant, le jeton ou le compte de service qu'il utilisait —ou au minimum tu fais passer ses droits d'écriture en lecture seule—. C'est ce que presque personne ne fait, et c'est là qu'est le vrai risque : un flux éteint avec un jeton vivant reste une clé avec droit d'écriture sur ton CRM qui circule dans la nature, sans propriétaire et sans personne pour la surveiller.
- Décider ce qu'on garde. Le flux s'exporte (JSON dans le dépôt, avec date et motif de l'extinction). Les données qu'il a produites restent où elles sont : on n'y touche pas. Les enregistrements et les logs, selon ce que dit ta politique de rétention. C'est seulement après ça qu'on le retire du tableau de bord, la seule partie vraiment irréversible.
Le calendrier compte autant que l'ordre. Les étapes un et deux, le même jour —ça n'a aucun sens d'éteindre un flux et de lui laisser les clés—. La trois, après trente ou quatre-vingt-dix jours de silence. Entre les deux, le flux est en quarantaine : désactivé, sans identifiants, récupérable en quelques minutes si quelqu'un débarque pour le réclamer. Et il y en aura : ce n'est pas un raté de la méthode, c'est la méthode qui marche.
Le critère écrit : ce qu'on éteint sans discuter
Un critère écrit transforme une décision politique —« et si quelqu'un en avait besoin ? »— en décision opérationnelle. Pas besoin que ce soit long. Quatre règles et le nom de qui signe les exceptions tiennent sur une demi-page :
- Pas de consommateur nommé → quarantaine. Si personne ne peut écrire une personne ou un système identifiable dans la colonne « qui le consomme », le flux s'éteint. « C'est les opérations qui s'en servent » n'est pas un nom.
- Pas de résultat consommé depuis 90 jours → quarantaine. Attention : résultat consommé, pas exécution. Un flux qui a tourné hier et dont personne n'a ouvert le résultat depuis trois mois remplit cette règle.
- Doublon fonctionnel d'un flux vivant → on éteint le moins bien entretenu, pas le plus ancien. L'ancienneté n'est pas un critère de qualité ; le nombre d'interventions manuelles du dernier trimestre, si.
- Identifiant d'une personne qui a quitté l'entreprise → extinction immédiate, sans fenêtre. Ce n'est plus du ménage, c'est de la sécurité, et ça n'admet pas de test du silence.
Et une règle qui gouverne les quatre autres : n'importe qui peut réclamer un flux en quarantaine, mais le réclamer, c'est accepter d'en être le propriétaire, nom et prénom. Pas « le service ». Une personne. Sans ça, le flux sauvé redevient zombie dans six mois et tu auras fait le ménage pour rien. C'est la même logique de propriétaire nommé qui soutient toute la gouvernance et le contrôle de l'automatisation : sans nom il n'y a pas de contrôle, juste un tableau de bord.
Cadence : une heure par trimestre, pas un projet de nettoyage
La tentation, c'est de monter « le projet de nettoyage des automatisations » : un mois de travail, un tableur énorme, un rapport final. On le fait une fois, ça marche bien, et deux ans plus tard tu en es au même point. Ce qui tient, c'est l'inverse : une revue courte et régulière qui tient en une heure.
Ce qui tient dans cette heure trimestrielle : passer en revue les flux dont le résultat n'a pas été consommé, mettre en quarantaine ceux qui remplissent le critère, sortir de quarantaine ceux que quelqu'un a réclamés (avec leur propriétaire déjà écrit) et supprimer définitivement ceux qui sont en quarantaine depuis un trimestre sans que personne ne les regrette. La première fois, ça pique —c'est normal de trouver entre un tiers et la moitié de l'inventaire en état douteux— ; à partir de la deuxième, c'est trente minutes.
La pièce qui évite la rechute se pose avant, pas après : chaque nouveau flux naît avec un propriétaire et une date de revue. Deux champs dans la description, trente secondes à la création. C'est la différence entre nettoyer et ne plus resalir, et ça s'emboîte avec la même habitude que détecter les pannes qui ne préviennent pas : ce qui n'est pas cher, ce n'est pas de réparer, c'est de l'apprendre à temps. Si tu montes tout ça de zéro, la carte complète est dans le guide pour automatiser avec l'IA.