Automatiser ou simplifier : comment choisir

« On devrait automatiser ça. »

C’est souvent la bonne intuition, et presque toujours la mauvaise première étape. Parce qu’automatiser une tâche qui n’aurait pas dû exister, c’est la rendre inutile plus vite — et plus difficile à supprimer ensuite, puisqu’un système la porte désormais.

Voici comment je tranche, concrètement, entre les deux voies.

Automatiser ou simplifier : la question dans le bon ordre

Deux logiques s’opposent, et elles ne coûtent pas la même chose.

Simplifier, c’est réduire le travail : supprimer une étape, un champ, une validation, un aller-retour. Le gain est définitif et ne demande aucun entretien. Rien ne peut tomber en panne dans une étape qui n’existe plus.

Automatiser, c’est confier le travail à une machine. Le travail existe toujours, il change simplement d’exécutant. Le gain est réel, mais il s’accompagne d’une dette : l’automatisation doit être surveillée, corrigée quand un outil change, et comprise par quelqu’un le jour où elle cesse de fonctionner.

D’où la règle : on simplifie d’abord, on automatise ce qui reste. Un processus simplifié puis automatisé donne un système léger. Un processus automatisé sans avoir été simplifié donne une usine à gaz, figée et coûteuse à défaire.

Les quatre questions, dans cet ordre

1. Cette tâche est-elle nécessaire ?

La question la plus rentable, et la plus rarement posée. Test simple : si cette étape disparaît demain, quelle décision devient impossible à prendre ?

Si la réponse est « aucune », l’étape est décorative. Elle existe souvent parce qu’un incident ancien l’a fait naître, ou parce qu’une personne partie depuis longtemps y tenait. Beaucoup de contrôles, de rapports et de validations tombent dans cette catégorie. Si vous n’avez pas encore la vue d’ensemble du processus, la cartographier d’abord aide à répondre : j’explique comment sur Excelsi’Ops.

2. Peut-on la réduire ?

Si la tâche est nécessaire, elle est rarement nécessaire dans sa forme actuelle. Pistes habituelles :

• moins d’informations demandées : chaque champ facultatif est une hésitation offerte ;
• moins d’intervenants : trois validations en chaîne diluent la responsabilité au lieu de la renforcer ;
• moins de transferts : chaque passage d’un outil à l’autre est une occasion d’erreur et d’attente ;
• une saisie plus tôt : faire remplir l’information correctement à la source évite tout le travail de correction en aval.

Ce dernier point règle à lui seul beaucoup de situations. Un formulaire de demande bien conçu supprime des heures de relances.

3. La tâche est-elle automatisable ?

Une tâche ne se prête à l’automatisation que si elle réunit quatre conditions :

• elle se répète à l’identique, souvent ;
• elle suit des règles explicites, que l’on peut écrire sans dire « ça dépend » ;
• ses données d’entrée sont structurées et fiables ;
• une erreur reste rattrapable sans conséquence grave.

Si l’une manque, l’automatisation sera fragile. En particulier : une tâche qui demande du jugement n’est pas automatisable, elle est au mieux assistable — on prépare le travail, l’humain décide.

4. Le jeu en vaut-il la chandelle ?

Un calcul honnête compare trois éléments : le temps passé aujourd’hui sur une période donnée, le temps de mise en place, et le temps d’entretien annuel. C’est ce dernier que l’on oublie systématiquement — or les outils évoluent, les identifiants expirent, les formats changent.

À remplir avec vos propres chiffres : (temps par occurrence × nombre d’occurrences par an) − (temps de mise en place + entretien annuel estimé). Si le résultat n’est pas nettement positif dès la première année, attendez.

Le tableau de décision

La ligne la plus utile est la dernière. Automatiser un processus instable revient à refaire l’automatisation à chaque changement : on dépense plus qu’on ne gagne.

Ce que « simplifier » veut dire concrètement

Quatre leviers, du plus rentable au moins rentable :

1. Supprimer ce qui ne sert plus.
2. Fusionner deux étapes séparées sans raison, souvent parce qu’elles étaient tenues par deux personnes différentes.
3. Déplacer une étape en amont, là où l’information existe déjà.
4. Standardiser : un modèle de document, une liste de choix fermée, un format unique. C’est aussi ce qui rend l’automatisation possible plus tard.

J’insiste sur le quatrième : la standardisation est le pont entre les deux voies. Un processus standardisé est un processus prêt à être automatisé le jour où le volume le justifiera.

Exemple concret (illustratif)

Chiffres fictifs, donnés à titre d’illustration. À refaire avec vos propres données.

Une petite structure produit chaque mois un rapport d’activité : environ trois heures de collecte et de mise en forme, douze fois par an. La demande initiale est « peut-on automatiser ce rapport ? ».

En examinant l’usage, deux éléments apparaissent. D’abord, seules deux des huit sections sont réellement lues et discutées. Ensuite, la moitié du temps est consacrée à la mise en forme, non à l’analyse.

La première décision n’est donc pas technique : réduire le rapport aux sections utiles. Le temps passe de trois heures à environ une heure, sans le moindre outil, sans rien à maintenir.

L’automatisation redevient pertinente ensuite, sur la collecte des données de ces deux sections — une tâche répétitive, aux règles claires. Automatiser d’emblée les huit sections aurait figé six sections inutiles dans un système à entretenir.

Quand automatiser est clairement la bonne décision

Quatre familles de cas ne souffrent guère de discussion :

• la recopie d’informations d’un outil vers un autre ;
• les envois déclenchés par un événement : accusé de réception, relance, rappel d’échéance ;
• la consolidation régulière de données dispersées ;
• les contrôles systématiques : détecter une anomalie, un doublon, une valeur manquante.

Ces cas sont fréquents, régis par des règles nettes, et ne demandent aucun jugement. Ils se traitent souvent avec des outils accessibles sans compétence de développement — j’ai détaillé ces possibilités dans automatiser les tâches répétitives sans coder.

Les erreurs à éviter

• Automatiser pour ne pas avoir à trancher. Quand une règle est floue, un outil ne la clarifiera pas : il figera le flou.
• Oublier le coût d’entretien. Une automatisation est un petit logiciel. Quelqu’un doit pouvoir la comprendre et la réparer.
• Automatiser une tâche que personne ne comprend. Si l’étape est opaque aujourd’hui, elle sera invisible demain — et personne ne saura détecter qu’elle produit des résultats faux.
• Enchaîner les automatisations sans supervision. Quand une chaîne tombe silencieusement, on s’en aperçoit parfois des semaines plus tard.
• Faire dépendre l’ensemble d’une seule personne. C’est échanger une dépendance humaine contre une autre, en moins visible.
• Négliger le cas d’erreur. Que se passe-t-il si l’automatisation échoue ? Si la réponse est « on ne le saura pas », ne la mettez pas en production.

Trancher sans se tromper

De l’intérieur, il est difficile de distinguer ce qui doit disparaître de ce qui doit être outillé. Ce qui coûte le plus cher est souvent devenu invisible à force d’être habituel.

Le Diagnostic Éclair fait précisément ce tri : questionnaire de cadrage, entretien de 45 minutes, puis un rapport sous 72 heures — ce qui peut être supprimé, ce qui doit être simplifié, ce qui mérite d’être automatisé, et dans quel ordre, avec un plan d’action classé par priorité.

👉 Découvrir le Diagnostic Éclair