La bonne et la mauvaise automatisation : 7 erreurs à éviter

L'essentiel : depuis que les outils no-code et l'IA permettent de monter une automatisation en un après-midi, on en produit beaucoup, et beaucoup sont à refaire. Une automatisation n'est pas un gadget qu'on branche, c'est un système qu'on possède. Voici les 7 erreurs qui séparent une bonne automatisation d'une mauvaise : automatiser l'inutile, le mal défini, le pas rentable, oublier les pannes, cacher l'automatisation aux gens, l'abandonner dans le désordre, négliger sa maintenance.

La différence entre un bon et un mauvais chasseur ne se voit pas au premier coup d'œil. En automatisation non plus : deux scénarios peuvent sembler identiques, l'un tourne encore dans trois ans, l'autre est abandonné dans six mois. Voici ce qui les distingue.

Avant de construire : trois erreurs de cadrage

Erreur 1 : automatiser une tâche qui ne devrait pas exister

L'erreur la plus fréquente est aussi la plus invisible : automatiser quelque chose qu'il aurait fallu supprimer. On tient un rapport hebdomadaire que personne ne lit depuis deux ans, alors on l'automatise. Bravo, maintenant personne ne le lit deux fois plus vite.

Peter Drucker l'a écrit dès 1963 : « il n'y a rien de plus inutile que de faire avec efficacité ce qui ne devrait pas être fait du tout. » L'automatisation est la forme la plus séduisante de ce piège, parce qu'elle donne le sentiment du progrès.

L'ordre est donc : supprimer, puis simplifier, puis automatiser. Dans cet ordre. On ne s'attaque à l'automatisation qu'une fois qu'il ne reste que le nécessaire. Et surtout : on n'automatise pas pour des cas qui « pourraient arriver un jour ». Des cas hypothétiques, il en existe une infinité ; les traiter tous, c'est construire une usine pour fabriquer un objet par an.

Erreur 2 : automatiser quelque chose de mal défini

Disons que vous voulez « automatiser les relances clients ». Très bien. Relancer qui ? À partir de combien de jours de retard ? Sur quel ton pour un bon client, sur quel ton pour un mauvais payeur ? On s'arrête après combien de relances ? Si vous n'avez pas les réponses, l'automatisation ne les inventera pas : elle figera votre flou et l'exécutera cent fois par jour.

Une automatisation amplifie ce qu'on lui donne. Nourrie de règles claires, elle fiabilise. Nourrie d'un processus vague ou de données fausses, elle fabrique du désordre, simplement plus vite.

Deux parades. La première est une règle de tri que nous détaillons dans notre guide agent IA ou automatisation : si vous ne savez pas écrire la tâche sous forme de procédure, c'est qu'elle ne relève pas de l'automatisation, mais d'un humain ou d'un agent IA. La seconde : documentez. Une automatisation dont personne ne sait exactement ce qu'elle fait est une automatisation que personne n'osera utiliser, et qu'on finira par débrancher « au cas où ».

Erreur 3 : passer plus de temps à automatiser qu'à faire la tâche

Le classique de l'ingénieur : trois jours pour automatiser une tâche de dix minutes hebdomadaires. Le calcul est pourtant simple. Une tâche revient à une certaine fréquence, vous fait gagner un certain temps à chaque fois, sur un horizon de quelques années. Fréquence × temps gagné × horizon = le budget que vous pouvez raisonnablement investir.

Une tâche quotidienne où vous grattez dix minutes, c'est environ 200 heures récupérées sur cinq ans : investissez sans hésiter. La même tâche une fois par mois, c'est une dizaine d'heures sur cinq ans : passé à peine plus d'une journée de travail à l'automatiser, vous êtes perdant. (Le principe est celui du célèbre tableau de xkcd, « Is It Worth the Time? ».)

Une nuance, sinon vous ne feriez jamais rien : le temps n'est pas la seule valeur. Une automatisation qui ne fait gagner aucune minute peut rester très rentable si elle supprime une erreur coûteuse, ou si elle réduit un délai. Répondre à un prospect en deux minutes plutôt qu'en deux jours ne « fait pas gagner de temps » sur le papier, et change tout au taux de transformation.

Pendant la construction : l'erreur qui casse tout

Erreur 4 : ne prévoir que le chemin idéal

Vous demandez un Rennes-Marseille à un moteur d'itinéraire. Il vous propose, très fier : départ Rennes 8h05, arrivée Paris-Montparnasse 10h10, puis départ Paris-Gare de Lyon 10h25 vers Marseille. Quinze minutes de correspondance. Sur le papier, impeccable.

Sauf que Montparnasse et la Gare de Lyon sont aux deux extrémités de Paris. En quinze minutes, il faut déjà traverser la capitale : le changement va être sportif. Et encore, ça, c'est si tout est à l'heure. Que le premier train prenne huit minutes de retard, et le plan s'effondre. Le moteur n'a vu que le chemin idéal, deux horaires qui s'emboîtent, en oubliant le monde réel entre les deux.

Une automatisation, c'est pareil. Le chemin idéal, celui où toutes les données sont présentes et tous les services répondent, est le cas facile. Le métier est dans les autres : le fichier mal formaté, l'API qui ne répond pas, le champ vide. Prévoir uniquement le chemin idéal, c'est construire un système qui marche en démonstration et casse en production. Et le pire, c'est quand il casse en silence.

Pas besoin d'un manuel de gestion des risques, trois questions suffisent :

• Qu'est-ce qui peut rater ?
• Si ça rate, c'est grave à quel point ?
• Qu'est-ce qu'on fait quand ça arrive : on bloque, on met une valeur par défaut, on bascule sur un plan B, ou on renvoie le cas à un humain ?

Le minimum absolu, celui en dessous duquel une automatisation n'a rien à faire en production : quand elle échoue, quelqu'un doit le savoir. Une erreur qu'on ne voit pas est une erreur qu'on ne corrige jamais, ce qui nous amène à la suite.

En exploitation : trois erreurs qui tuent lentement

Erreur 5 : cacher les automatisations aux utilisateurs

C'est l'erreur la moins évoquée, et c'est la plus grave. Quand une automatisation travaille dans l'ombre, sans que personne ne voie ce qu'elle fait ni où elle en est, deux choses arrivent, toutes les deux mauvaises.

D'abord, le logiciel devient incompréhensible pour ceux qui l'utilisent. Un document part, un statut change, une facture se génère, et personne ne sait pourquoi ni quand. Les gens perdent confiance dans un outil dont ils ne comprennent pas le comportement, et un outil en qui on n'a pas confiance, on le contourne.

Ensuite, et c'est le plus coûteux, les erreurs ne remontent pas. Si l'automatisation se trompe dans son coin, personne ne le voit, donc personne ne le corrige, et le défaut s'installe. Une automatisation invisible ne s'améliore jamais, parce que rien ne fait remonter ce qui cloche.

La bonne pratique est l'inverse exact : rendre le travail de l'automatisation visible. Sur l'outil que nous avons construit pour SERME, un courtier en déchets dangereux, chaque étape laisse une trace lisible. On voit à quel stade en est un dossier, quel document a été généré, ce qui a fonctionné et ce qui a échoué. Cette visibilité n'est pas un luxe d'ergonomie : c'est elle qui permet aux équipes de faire confiance au système, et qui fait remonter les erreurs vers ceux qui peuvent les corriger. Une automatisation qu'on voit travailler est une automatisation qui s'améliore. Une automatisation qu'on ne voit pas est une bombe à retardement polie.

Erreur 6 : les laisser proliférer dans le désordre

Disons que vous avez quarante-trois scénarios qui tournent quelque part dans un compte Make. Il y en a un qui s'appelle « Scénario 12 final (NE PAS SUPPRIMER) ». Personne ne sait ce qu'il fait. Il a été créé un mardi de novembre 2022 par un stagiaire qui est depuis parti monter une microbrasserie dans le Cantal. Il se déclenche tous les jeudis à 4h07 du matin, envoie quelque chose quelque part, et la seule fois où quelqu'un a osé le désactiver, l'export comptable est tombé en panne pendant trois jours sans que personne ne comprenne le rapport. Alors on le laisse. On le contourne. On a même fini par le respecter un peu.

Ce scénario n'est pas une anecdote, c'est un symptôme. C'est un cimetière d'automatisations, sauf que les morts bougent encore, et il grandit tout seul. Un système que personne ne comprend est un système que personne n'utilise, et qu'on finit par abandonner en bloc, le stagiaire du Cantal compris.

Deux causes, deux parades. La première est le désordre pur : des automatisations sans nom, sans inventaire, sans lien clair avec un besoin réel. La parade tient en trois gestes :

• nommer chaque automatisation pour ce qu'elle fait ;
• tenir une liste unique de ce qui tourne ;
• rattacher chacune à un process métier identifié.

Une automatisation qui ne répond à aucun besoin nommé ne devrait pas exister.

La seconde cause est humaine, et plus profonde : une automatisation construite sans les gens qui vont vivre avec. Quand elle leur tombe dessus sans qu'on les ait consultés, ils la subissent, la contournent, et elle meurt de désusage. On automatise avec les équipes, pas contre elles. Au fond, ces deux parades disent la même chose : une automatisation n'est pas un objet isolé, elle est une pièce d'un ensemble. C'est tout le sujet de l'architecture que nous décrivons dans le système d'information d'une PME.

Erreur 7 : oublier qu'une automatisation se maintient

Une automatisation ne repose pas sur du roc. Elle s'appuie sur des outils, des API, des services qui évoluent, changent leurs règles, se mettent à jour. Tôt ou tard, un paramètre devra être adapté pour qu'elle continue de fonctionner. Ce n'est pas un risque, c'est une certitude.

Si personne n'est responsable de la maintenir, elle se dégrade jusqu'à l'abandon, généralement le jour le moins pratique. La parade tient en deux décisions simples : une personne désignée comme responsable, et un point de contrôle régulier. C'est le principe que nous martelons pour tout système sur mesure : son coût n'est pas dans sa construction, il est dans sa possession, sécurité et évolutions comprises, pour toute sa durée de vie.

La différence, en une phrase

Le mauvais chasseur et le bon chasseur automatisent tous les deux. La différence, c'est que le bon chasseur sait ce qu'il automatise, pourquoi, ce qui se passe quand ça rate, et qui s'en occupe dans deux ans. Une automatisation vite faite règle un problème aujourd'hui et en crée trois demain. Une bonne automatisation est un système qu'on a pensé pour durer.

Si vous avez un empilement d'automatisations dont vous ne savez plus lesquelles tiennent encore debout, ou un process que vous hésitez à automatiser, parlons-en. On regardera ensemble ce qui mérite d'être automatisé, ce qui mérite d'être supprimé, et ce qui vaut mieux rester entre des mains humaines.