Flux dormants : les automatisations que plus personne ne pilote

L’automatisation dangereuse n’est pas celle qui tombe. C’est celle à laquelle personne n’a pensé depuis dix-huit mois, qui détient encore un compte de service, et qui casserait quelque chose si on l’éteignait, sans que personne ne sache quoi.

Un flux n’a pas de date de fin. Il est construit pour un projet, le projet est livré, le projet se referme, et le flux garde son déclencheur. Il ne signale pas que sa raison d’être a disparu. Il tourne, ou il attend, et il reste dans la liste.

Dormant n’est pas cassé

Trois états se confondent, et ils appellent des réponses différentes.

En échec. Le flux tourne et sort en erreur. Visible, au moins en principe : la plateforme l’enregistre.

Dormant. Le flux est actif, son déclencheur est valide, et il n’a pas tourné depuis longtemps. Rien ne va mal. Rien ne se passe non plus.

Orphelin. Le flux tourne parfaitement, et son propriétaire a quitté l’entreprise. C’est le pire des trois, parce que tout a l’air normal.

Un flux peut être dormant et orphelin à la fois, et c’est la combinaison à chasser en premier.

Pourquoi un flux endormi n’est pas gratuit

Le réflexe est de les laisser tranquilles : ils tournent rarement, donc ils ne coûtent rien. Trois raisons pour lesquelles c’est faux.

Il détient une connexion. Un flux dormant garde une connexion authentifiée vers SharePoint, un CRM, une boîte mail. Cette connexion est un identifiant vivant, rattaché à un processus que personne ne surveille. Quand c’est un compte nominatif plutôt qu’un compte de service (ce qui arrive souvent, parce que le flux a été monté vite), c’est aussi un identifiant qui cassera le jour où cette personne partira, d’une façon que personne ne saura diagnostiquer.

Il occupe un siège. Selon le plan de licence, un flux désactivé ou dormant compte quand même. Vous payez l’option de le faire tourner.

Il va se réveiller. C’est ce qu’on sous-estime le plus. Un flux dormant depuis un an parce que son dossier déclencheur était vide se déclenchera le jour où quelqu’un y dépose un fichier. Il appliquera alors une logique de 2024 à des données de 2026, et il le fera en silence.

Comment les trouver, concrètement

Le signal n’est pas « n’a pas tourné récemment ». Ça remonte les flux trimestriels et annuels parfaitement légitimes, et ça vous noie sous les faux positifs.

Le signal utile est une combinaison :

• Aucune exécution depuis 60 jours : le filtre de départ, rien de plus.
• Aucune modification depuis 12 mois : un flux encore maintenu est un flux dont quelqu’un se soucie encore.
• Son auteur n’a plus de compte actif : le signal le plus fort à lui seul, et le plus facile à vérifier.
• Son déclencheur pointe quelque chose qui n’existe plus : une liste supprimée, une boîte mail fermée, le dossier d’un projet clos.

Un seul de ces signaux ne dit pas grand-chose. Trois ensemble veulent dire que le flux a très probablement survécu à sa raison d’être.

La question à poser sur chacun

Une fois la liste obtenue, la tentation est de tout éteindre d’un coup. Ne le faites pas. Le mode d’échec de cette approche, c’est de découvrir en novembre que le flux désactivé en septembre produisait le rapport dont la finance dépendait discrètement.

Pour chaque flux, une question, dans cet ordre :

1. Qu’est-ce qu’il fait, en une phrase ? Si personne dans la pièce ne sait répondre, c’est déjà le constat. Écrivez la phrase avant de faire quoi que ce soit d’autre : vous êtes en train de documenter un parc qui n’avait pas de documentation.

2. Qui s’en apercevrait s’il s’arrêtait ? Pas « qui en est propriétaire », souvent personne. Qui reçoit sa sortie, lit son fichier, reçoit son mail.

3. Cette personne est-elle encore là, et en a-t-elle encore besoin ? C’est un message. Envoyez-le.

4. Puis décidez. Garder et attribuer un propriétaire, ou éteindre et archiver.

L’archivage compte. Supprimer un flux supprime la dernière description existante d’un processus métier. Désactivez-le, exportez sa définition, gardez-la quelque part. Le stockage coûte moins cher que la reconstitution d’un processus de mémoire.

Attribuer un propriétaire, voilà le vrai correctif

Trouver les flux dormants est un nettoyage. Les empêcher est une règle, et elle est simple : aucun flux en production sans un propriétaire nommé et un suppléant nommé.

Le suppléant n’est pas une formalité. Le modèle à propriétaire unique tombe exactement au moment où vous en avez besoin : quand cette personne part, change d’équipe, ou est en congé pendant l’incident. Deux noms, c’est la différence entre « on va regarder » et « on a appelé Nadia ».

Donnez à chaque flux, au minimum :

• Un nom qu’un non-technicien comprend. Pas Flow_v3_FINAL.
• Une phrase qui dit ce qu’il fait et pourquoi il existe.
• Un propriétaire et un suppléant, tous deux encore en poste.
• Une date de revue. Même annuelle. Un flux que personne n’a rouvert depuis un an est un flux en route vers le sommeil.

La partie inconfortable

Faire ça correctement, c’est admettre qu’un bon nombre de vos automatisations ne devraient plus exister. Ce n’est pas un échec de l’équipe qui les a construites : elles avaient raison au moment où elles les ont faites. Les circonstances ont bougé, et rien dans l’outillage ne s’en est aperçu.

C’est exactement le trou. Les plateformes sont excellentes pour exécuter des flux et totalement indifférentes à la question de savoir si un flux mérite encore de tourner. Rien dans Power Automate, n8n ou Make ne vous dira jamais que le projet d’un flux s’est terminé il y a deux ans, parce qu’aucun d’eux ne sait ce qu’est un projet.

Quelqu’un doit regarder. La seule question est de savoir si ça arrive sur un rythme choisi, ou la semaine qui suit un incident.