Les processus qu'il ne faut pas automatiser

La demande d'automatisation arrive rarement sous forme de question. Elle arrive sous forme de liste, transmise par une direction métier, avec la mention « voici ce qu'on aimerait automatiser ». Une part significative de cette liste ne devrait pas l'être, et le dire tôt est un service rendu.

1. Les processus trop peu fréquents

Un processus exécuté une fois par mois pendant vingt minutes représente quatre heures par an. Aucun développement, même simple, n'est rentabilisé par quatre heures annuelles, et il faudra le maintenir.

Le seuil pratique se situe autour de deux exécutions hebdomadaires ou d'un volume unitaire important.

2. Les processus dont les règles changent tous les trimestres

Chaque changement de règle est un développement supplémentaire. Sur un processus dont la logique métier évolue à chaque campagne commerciale ou à chaque évolution réglementaire, le coût de maintenance dépasse rapidement le gain.

L'exception : si les règles changent mais que leur structure est stable, externaliser les paramètres dans une table modifiable par le métier règle le problème. Ce n'est pas toujours possible, et il faut le vérifier avant de s'engager.

3. Les processus qui n'existent pas vraiment

Il arrive qu'aucune personne ne fasse la même chose de la même façon. Chacun a sa méthode, ses vérifications, ses raccourcis. Ce n'est pas un processus, c'est une pratique.

Automatiser suppose de figer une version, donc de trancher entre les pratiques. Ce travail d'harmonisation est légitime et utile, mais c'est un projet d'organisation, pas un projet d'automatisation. Le confondre garantit l'échec des deux.

4. Les processus qui contourneraient un contrôle interne

Certains processus manuels comportent une étape de vérification humaine qui existe précisément parce qu'elle doit être humaine : validation d'un montant, contrôle de séparation des tâches, décision engageant la responsabilité.

Automatiser cette étape est parfois techniquement trivial et toujours problématique. Le sujet doit remonter au contrôle interne avant tout développement, pas après un audit.

5. Les processus dont personne ne connaît le pourquoi

« On a toujours fait comme ça » est la réponse la plus fréquente et la plus inquiétante. Un processus dont la finalité n'est plus comprise est un excellent candidat à la suppression, pas à l'automatisation.

Automatiser un processus inutile le rend permanent : il ne coûte plus assez cher pour qu'on le remette en cause, et il tournera encore dans dix ans.

6. Les processus en fin de vie

Si l'application cible doit être remplacée dans dix-huit mois, un robot développé aujourd'hui sera jeté avant d'être rentabilisé. Cette information est rarement disponible dans la demande initiale : il faut la chercher auprès de la DSI, qui connaît la feuille de route applicative.

Ce que produit un refus bien documenté

Une note d'une page par processus écarté, expliquant le critère qui n'est pas rempli et le chiffre associé. Ce document circule ensuite en interne et sert à arbitrer les demandes suivantes sans nouvelle étude.

C'est souvent le livrable le plus réutilisé d'une mission d'automatisation, et paradoxalement celui qui ne figure jamais dans les propositions commerciales.