Cinq erreurs qui font échouer une première automatisation

Une majorité des automatisations montées par des petites entreprises sont abandonnées dans les trois mois. Presque jamais parce que l'outil ne convenait pas — les trois grands outils du marché font tous très bien ce qu'on leur demande.

Elles échouent pour cinq raisons, et les cinq se préviennent avant la première configuration.

1. Commencer par la tâche la plus critique

C'est l'erreur la plus fréquente, et elle est parfaitement logique : on veut automatiser ce qui fait le plus mal.

Le problème, c'est que la première automatisation d'une vie n'est pas un projet, c'est un apprentissage. Vous allez découvrir ce que fait l'outil quand une donnée manque, à quoi ressemble une alerte d'échec, ce qui se passe quand deux exécutions se chevauchent, ce qu'il advient quand vous modifiez un scénario en cours de route.

Ces découvertes sont inévitables et utiles. Autant les faire sur un fichier mal classé plutôt que sur une facture envoyée deux fois au même client.

À faire à la place : choisir la tâche la plus rentable parmi celles qui ne font aucun dégât en cas d'échec. Le classement automatique des pièces jointes est le cas d'école : volume suffisant, gain réel, conséquence nulle en cas d'erreur.

2. Automatiser une tâche qu'il fallait supprimer

Un rapport hebdomadaire que plus personne ne lit. Une validation qui date d'une organisation disparue. Une double saisie qui existe parce qu'un logiciel a été remplacé il y a trois ans sans nettoyer la procédure.

Automatiser une tâche inutile, c'est industrialiser du gaspillage — et c'est pire que de ne rien faire, parce que la tâche devient invisible et ne sera plus jamais remise en question.

À faire à la place : avant toute automatisation, poser la question « que se passe-t-il si on arrête complètement ? ». Dans un cas sur cinq, la réponse est « rien ». C'est le meilleur gain de temps disponible, et il ne coûte pas un centime.

3. Ne pas prévoir l'échec

Une automatisation échoue. Pas peut échouer : échoue. Une interface change, un quota est atteint, un fichier arrive dans un format inattendu, un service est indisponible vingt minutes.

Le vrai problème n'est pas l'échec, c'est l'échec silencieux. Le scénario s'arrête, personne ne le remarque, et trois semaines plus tard on découvre que les commandes ne sont plus enregistrées depuis le 14.

Une automatisation qui échoue sans prévenir coûte beaucoup plus cher que pas d'automatisation du tout — parce qu'entre-temps, vous avez cessé de vérifier.

À faire à la place : deux réflexes, dix minutes chacun.

• Activer l'alerte d'échec dès la première mise en service. Les trois grands outils l'envoient par mail, ce n'est pas activé par défaut partout.
• Prévoir un signal de bonne santé. Un message récapitulatif hebdomadaire — « 47 exécutions, 0 erreur » — vaut mieux que le silence, parce que le silence peut aussi signifier que rien ne tourne.

4. Confier une décision à une règle

Une automatisation exécute. Elle ne décide pas.

Quand vous écrivez une règle du type « si le client est important, alors… », vous n'avez pas automatisé un jugement : vous avez remplacé votre jugement par une approximation, et vous allez passer votre temps à vérifier ses sorties. À l'arrivée, la vérification coûte plus cher que la tâche d'origine.

Le test : si vous ne pouvez pas écrire la condition sans employer un mot qui demande une appréciation — important, urgent, prioritaire, sérieux, pertinent — c'est une décision, pas un déclencheur.

À faire à la place : automatiser la préparation de la décision. Le système rassemble tout ce qu'il faut, présente le dossier, et vous tranchez en dix secondes au lieu de cinq minutes. Vous gardez la décision et vous gagnez presque tout le temps.

5. Tout monter d'un coup

Le week-end où l'on découvre l'outil, on monte six scénarios d'affilée. Ils s'enchaînent, se déclenchent mutuellement, partagent des données.

Trois semaines plus tard, quelque chose ne marche plus. Impossible de savoir quoi : les six sont en cause, personne ne se souvient de la logique exacte, et on ne peut pas en désactiver un sans casser les autres. On abandonne l'ensemble.

À faire à la place : un scénario, en entier, laissé tourner deux semaines avant d'en monter un deuxième. Deux semaines, c'est le délai qu'il faut pour rencontrer les cas particuliers : la semaine avec un jour férié, le client au nom bizarre, le fichier vide, le mois qui change.

C'est frustrant. C'est aussi la seule différence observable entre les automatisations qui tournent encore un an plus tard et les autres.

---

Les trois questions à se poser avant chaque nouvelle automatisation

Elles tiennent en trente secondes et elles évitent les cinq erreurs :

1. Peut-on supprimer cette tâche au lieu de l'automatiser ?
2. Que se passe-t-il concrètement si elle se trompe, ou si elle s'arrête sans rien dire ?
3. Le déclencheur est-il factuel, ou contient-il un jugement déguisé ?

Si les trois réponses sont bonnes, montez-la. Sinon, prenez la suivante sur la liste.

Pour établir cette liste dans le bon ordre, la méthode est ici : le relevé de cinq jours. Et pour savoir ce qui rapporte réellement : les huit tâches à automatiser en premier.