Comprendre avant de construire
Il existe une idée répandue selon laquelle automatiser serait toujours un progrès — que face à une tâche répétitive, la seule question à se poser serait « comment » l’automatiser, jamais « si » on doit le faire. Cette idée est fausse, et elle coûte cher à ceux qui la suivent sans y réfléchir.
Automatiser une tâche, c’est figer une façon de faire à un instant donné. Tant que cette façon de faire reste stable, l’automatisation tient sa promesse : elle évite de refaire, chaque fois, un geste identique. Mais dès que la situation change — et elle change plus souvent qu’on ne l’imagine — l’automatisation devient un obstacle plutôt qu’une aide. Comprendre ce qu’on automatise, et pourquoi, évite d’avoir à défaire ce qu’on vient tout juste de construire.
Trois signes qu’automatiser n’est pas la bonne réponse
La tâche change plus vite qu’un outil ne peut suivre
Certaines activités sont, par nature, instables : une offre commerciale encore en test, une organisation d’équipe en pleine évolution, un début d’activité où tout se cherche encore. Automatiser une tâche à ce stade, c’est parier sur une forme qui n’a pas fini de bouger. Le risque n’est pas seulement de perdre du temps à construire l’automatisation : c’est aussi de perdre du temps, ensuite, à la corriger à chaque changement — un temps souvent supérieur à celui qu’on cherchait à économiser.
Le bon réflexe, dans ce cas, n’est pas de renoncer définitivement, mais d’attendre que la tâche se stabilise. Une méthode répétée trois ou quatre fois de la même façon est un bien meilleur candidat qu’une méthode qu’on invente encore à chaque fois.
Le problème est ailleurs que dans le geste répété
Il arrive qu’une tâche semble lente ou pénible, et qu’on en conclue trop vite qu’il faut l’automatiser — alors que le vrai problème se situe une étape plus tôt. Un exemple fréquent : la relance de factures impayées prend du temps parce qu’il faut, à chaque fois, retrouver qui a payé et qui n’a pas payé. Automatiser l’envoi de la relance ne résout rien si l’information de départ — qui doit quoi — reste incertaine ou dispersée entre plusieurs fichiers, comme évoqué dans pourquoi vos fichiers finissent par diverger. Dans ce cas, automatiser reviendrait à envoyer plus vite un message qui repose, une fois sur cinq, sur une donnée fausse — ce qui abîme la relation avec un client plus que ça ne fait gagner de temps.
Avant d’automatiser un geste, il vaut mieux se demander ce qui le rend difficile. Si la réponse touche à une information mal organisée en amont, c’est cette information qu’il faut d’abord clarifier — pas le geste qui vient après.
Personne ne sait encore ce qu’il faut garder
Automatiser suppose de décider, une fois pour toutes, ce qui compte et ce qui ne compte pas dans une tâche — quelles colonnes garder dans un tableau, quelles informations inclure dans un document type, quels cas particuliers traiter à part. Quand cette décision n’a pas encore été prise clairement par les personnes concernées, automatiser revient à figer un choix que personne n’a vraiment fait.
Ce cas se reconnaît à une phrase qui revient souvent en discussion : « on verra plus tard pour les cas particuliers ». Si les cas particuliers sont encore nombreux et mal identifiés, ce n’est pas encore le moment de construire — c’est le moment de continuer à observer.
Ce que ça coûte d’automatiser trop tôt
Le coût d’une automatisation prématurée n’est pas seulement le temps passé à la construire. Il y a aussi le temps passé, ensuite, à comprendre pourquoi elle ne correspond plus à la réalité — souvent plus long, parce qu’il faut d’abord remarquer que quelque chose ne va pas, puis retrouver la logique d’origine, parfois posée par quelqu’un qui n’est plus là pour l’expliquer. Et il y a un coût moins visible encore : la confiance. Une automatisation qui produit une erreur, une fois, incite à tout revérifier à la main la fois suivante — ce qui annule exactement le bénéfice recherché au départ.
La bonne question n’est pas « comment » mais « pourquoi »
Avant d’automatiser quoi que ce soit, il est utile de répondre à une question simple, et de la répondre par écrit plutôt que de mémoire : à quoi sert exactement cette tâche, pour qui, et depuis quand se fait-elle de cette façon précise ? Si la réponse est claire, nette, et stable depuis un moment, l’automatisation a de bonnes chances d’être utile. Si elle est floue, ou si elle commence par « on a toujours fait comme ça », mieux vaut d’abord clarifier la tâche elle-même — un travail décrit dans repérer où le temps se perd vraiment.
Ce que veut dire « comprendre avant de construire »
Ne pas automatiser n’est pas un renoncement. C’est souvent la décision qui épargne le plus de travail inutile — celui de construire un outil, puis de le corriger, puis de finir par revenir, de guerre lasse, à la méthode manuelle qu’on avait justement voulu éviter. Prendre le temps de comprendre une tâche avant d’y toucher n’est pas une étape à sauter pour aller plus vite : c’est ce qui évite, la plupart du temps, de devoir tout recommencer.
La question à se poser n’est donc jamais seulement « est-ce que je peux automatiser ceci ? ». C’est d’abord « est-ce que je comprends assez bien ce qui se passe ici pour que ça vaille la peine de le figer maintenant ? ». Le reste — le choix de l’outil, la mise en place — vient toujours après, jamais avant.