La démo se passe toujours bien. On prend le processus tel qu’il fonctionne le jour de la réunion, on l’automatise, on le chronomètre et on montre le chiffre : « de 40 heures par mois à 8 ». Trois semaines après la mise en service, une règle de remise change, le fournisseur redessine le format de ses bons de livraison et quelqu’un de la finance ajoute un champ au rapport. L’automatisation est toujours là, mais elle n’automatise plus le processus : elle automatise la version du processus qui existait le jour de la démo.
La thèse en une ligne : le critère qui manque à presque toutes les listes « quoi automatiser » n’est ni le volume ni l’économie, c’est la stabilité. Un processus qui change chaque mois consomme en maintenance ce qu’il libère à l’exécution, et le calcul de retour se fait toujours sur une version figée qui n’existe plus. Si le processus bouge plus vite que ta capacité à le reprendre, ne l’automatise pas encore : stabilise-le d’abord.
Automatiser un processus qui change souvent coûte plus qu’il ne libère
Les listes de candidats notent trois choses : combien de fois la tâche se répète, combien de temps elle prend et combien coûte l’erreur. Les trois mesurent le processus aujourd’hui. Aucune ne demande à quel point il ressemblera encore à lui-même dans six mois, ce qui décide pourtant si l’automatisation vieillit bien ou devient une facture récurrente. Voilà pourquoi un processus peut obtenir la meilleure note en volume et la pire en retour réel.
La réponse courte à la question qu’on nous pose : oui, on peut automatiser un processus qui change souvent, mais cela ne s’amortit pas quand le coût de la reprise à chaque changement approche les heures libérées. Et la maintenance est rarement budgétée, parce qu’au moment de la démo aucun changement n’a encore eu lieu.
L’arithmétique : heures libérées moins heures de reprise
Le calcul tient en une ligne : heures nettes par mois = heures libérées par mois − (changements par an × heures par changement ÷ 12). Une « heure par changement » inclut ce que presque personne ne note : comprendre ce qui a changé, modifier le flux, le retester sur des cas réels et le déployer sans casser ce qui marchait. Un exemple avec des chiffres inventés, uniquement pour montrer le calcul (remplace-les par les tiens), sur un processus qui prend 40 heures par mois à la main et qu’une automatisation stable ramène à 8 :
| Comportement du processus | Changements par an × heures par changement | Heures de reprise par mois | Heures nettes libérées par mois |
|---|---|---|---|
| Stable | 1 × 10 | 0,8 | 31,2 |
| Change chaque trimestre | 4 × 12 | 4 | 28 |
| Change chaque mois, changements de paramètres | 12 × 20 | 20 | 12 |
| Change chaque mois, changements de structure | 12 × 40 | 40 | −8 |
Regarde la dernière ligne : le processus automatisé coûte plus cher que le faire à la main. Ce n’est pas un cas exotique, c’est ce qui arrive quand le changement n’est pas une valeur qu’on ajuste mais une façon de travailler qu’on refait. Et le calcul n’inclut même pas la supervision, qui se déduit à part, comme nous l’expliquons dans pourquoi les heures libérées ne sont pas des économies.
Ce que veut dire « change » (tous les changements ne coûtent pas pareil)
Dire qu’un processus « change beaucoup » ne sert à rien : certains changements s’absorbent en quelques minutes, d’autres obligent à tout réécrire. La différence tient à ce qui bouge :
- Les valeurs changent. Un seuil, un tarif, une liste d’exceptions. Si ces valeurs vivent dans une table hors du flux, le changement coûte quelques minutes. Si elles sont écrites dans la logique, il faut une intervention.
- Le format de ce qui entre change. Un fournisseur qui redessine sa facture ou un client qui change son modèle. Le coût dépend de la robustesse de la lecture en entrée, et c’est le changement qui casse le plus en silence.
- Le système traversé change. Une migration d’ERP, un nouveau CRM, une API retirée. C’est un changement de structure : il coûte des jours, pas des minutes.
- Le critère de celui qui décide change. Ce qui était approuvé tout seul hier est relu par une personne aujourd’hui. C’est le plus cher, parce que le flux continue de tourner et produit de mauvaises décisions sans qu’aucune alarme ne sonne.
Comment mesurer la stabilité avant d’automatiser : quatre questions
Pas besoin de modèle. Il faut quatre réponses, qu’on obtient en un après-midi avec la personne qui exécute le processus :
- Combien de fois a-t-il changé ces douze derniers mois ? Avec les dates. Regarde l’historique de la consigne de travail, les e-mails « à partir de maintenant on fait comme ça » et les incidents ouverts. Si personne ne se souvient d’un changement, ce sont probablement beaucoup de petits.
- Qu’est-ce qui a bougé à chaque fois : une valeur, un format ou la structure ? Classe chaque changement avec la liste ci-dessus. Trois changements de valeur et un de structure ne pèsent pas comme quatre de structure.
- Qui décide du changement, et prévient-il avant ? Si le changement vient de l’extérieur (un fournisseur, un régulateur, un client) sans préavis, la reprise sera toujours urgente et toujours tardive.
- Le processus est-il écrit ? Un processus qui n’existe que dans la tête de celui qui l’exécute ne peut pas être repris : il faut d’abord l’extraire. C’est pourquoi documenter tes automatisations n’est pas de la bureaucratie, c’est ce qui rend le prochain changement bon marché.
Que faire du processus qui change chaque mois
Il y a quatre sorties, et presque personne n’envisage la première parce qu’elle ressemble à ne rien faire :
- Le stabiliser d’abord. Figer une version pendant un trimestre, décider qui autorise les changements et les regrouper dans une seule fenêtre. Parfois le processus change chaque mois parce que personne n’a décidé comment il doit être, pas parce que le métier l’exige.
- Automatiser le noyau stable et laisser la queue variable à une personne. 80 % des cas suivent la règle habituelle ; les 20 % qui changent, quelqu’un les traite. C’est moins spectaculaire en démo et bien moins cher à maintenir.
- Sortir les règles du flux. Que seuils, tarifs et exceptions vivent dans une table que le responsable du processus peut modifier sans toucher à l’automatisation.
- Attendre. Si le gros changement est déjà en route (une migration, une nouvelle réglementation), automatiser maintenant, c’est payer deux fois.
Quelle que soit la sortie, la reprise a besoin d’un filet : chaque changement devrait passer par un test avant de toucher la production, car un processus instable avec une automatisation sans tests, c’est exactement là que naissent les incidents que découvre le client.
Quand cela vaut quand même la peine de l’automatiser, même s’il change
Il y a des exceptions raisonnables. Si le volume est très élevé et que les changements sont presque toujours des valeurs (pas la structure), la reprise se dilue et le calcul tient. Si le coût de l’erreur est très grand, payer la maintenance peut valoir le coup pour la traçabilité. Et si le processus change parce que l’entreprise est en pleine transformation, automatiser le noyau stable et laisser le reste à une personne reste mieux qu’attendre que tout se calme. Ce qui n’est pas raisonnable, c’est de découvrir le coût de maintenance une fois le projet signé.
Par où commencer
Par la liste, avant l’outil : ajoute une colonne de stabilité à ton critère de sélection et note-la avec les quatre questions. Le guide sur quels processus automatiser avec l’IA explique comment classer les candidats par tâche ; cette colonne décide lesquels passent en premier. Et si tu préfères que quelqu’un le mesure avec toi sur tes vrais processus, c’est exactement ce que nous faisons en auditant tes processus pour l’IA : ce qui est éligible, ce que ça coûte vraiment et dans quel ordre, avec la stabilité comme filtre dès le premier jour.
La phrase à retenir est celle du début : la démo se fait sur le processus d’aujourd’hui, et tu vivras avec celui de dans six mois. Choisis d’abord celui qui bougera le moins.