Des machines, pas des scripts
Pourquoi la plupart des automatisations meurent au troisième mois
Presque toutes les automatisations que j'ai vues dans une PME suivent la même courbe.
Premier mois, ça marche. Quelqu'un a branché un script, un flux Zapier ou un agent IA, ça sauve quelques heures, tout le monde est content.
Deuxième mois, quelque chose bouge en dessous. Une API change un champ. Un jeton expire. Un fournisseur renomme une colonne dans son fichier. L'automatisation ne plante pas bruyamment. Elle arrête juste de faire sa job, ou elle en fait la moitié.
Troisième mois, quelqu'un s'en rend compte. Souvent un client, parfois le comptable, à l'occasion moi devant un graphique plat depuis trois semaines. Rendu là, plus personne ne se souvient qui l'a bâtie ni comment elle marche, alors on la ferme et le travail retourne à un humain.
L'automatisation n'a pas échoué parce que l'idée était mauvaise. Elle a échoué parce que c'était un script, et un script n'est pas une machine.
Ce qu'est une machine
J'utilise le mot rig, une machine, pour ce qui survit au troisième mois. C'est une machine délimitée qui roule toute seule. Elle a :
- son propre état, écrit, pour savoir ce qu'elle a déjà fait;
- sa propre boucle et son propre horaire, pour ne dépendre de personne qui pèse sur un bouton;
- sa propre politique d'échec, pour savoir quoi faire quand quelque chose brise, et qui avertir;
- un nom dans un registre central, pour qu'on ne puisse pas l'oublier.
Avant d'appeler quoi que ce soit une machine, je pose trois questions. Peut-elle rouler une semaine sans que personne n'y touche? Garde-t-elle son état d'une exécution à l'autre? Pourrais-je la remettre à quelqu'un d'autre d'un seul bloc : la boîte, l'état, l'horaire et le mode d'emploi? Trois oui, c'est une machine. Un seul non, c'est une pièce.
Une tâche cron est une pièce. Un prompt est une pièce. Un script Python est une pièce. Ce sont de bonnes pièces. Ce ne sont juste pas des machines finies, et les traiter comme des machines, c'est ce qui les tue.
L'échec qui m'a le plus appris
Une de nos machines de prospection n'a rien envoyé pendant quatre jours. Toutes les vérifications étaient au vert.
Il y en avait trois. Une confirmait qu'il y avait du travail en attente d'envoi. Une confirmait que la machine avait roulé à l'heure. Une confirmait que rien n'était coincé en quarantaine. Tout était vrai. Ce que personne ne mesurait, c'était la seule question qui comptait : est-ce que quelque chose est vraiment sorti?
Une seule adresse refusée avait déclenché une retenue, et la retenue avait été écrite trop large. Elle a gelé toute la campagne. De l'intérieur, un arrêt complet ressemblait exactement à une semaine tranquille.
La leçon est simple et je l'applique maintenant partout : être en vie, ce n'est pas être productif. Chaque machine a besoin d'une vérification sur ce qui est sorti, pas seulement sur ce qui est entré et sur le fait qu'elle a roulé.
La règle du registre
La deuxième leçon touche l'inventaire. Dans la plupart des entreprises, personne n'est capable de lister toutes les automatisations qui roulent. Elles vivent dans des outils différents, sous des comptes différents, bâties par des gens qui sont partis.
Notre règle est sèche : rien n'est en production tant que ce n'est pas inscrit au registre. Un seul fichier liste chaque machine, ce qu'elle fait, quand elle roule, qui en est responsable et comment l'arrêter. Un rapport quotidien est généré à partir de ce fichier. Si ce n'est pas au registre, ça n'a pas le droit de rouler sans surveillance.
Ça sonne comme de la paperasse. En pratique, c'est la différence entre « quelque chose cloche, je regarde la liste » et un après-midi d'archéologie.
Les alarmes qui crient au loup
La troisième façon dont les machines meurent, c'est le bruit. Un moniteur qui sonne pour tout finit en sourdine, et un moniteur en sourdine est un moniteur mort. Quand une alerte sonne et qu'elle ne valait pas mon attention, la solution est d'ajuster l'alerte, pas de commencer à ignorer le canal.
En bâtir moins, et les finir
La plupart des projets d'automatisation s'arrêtent à quatre-vingt-dix pour cent : ça marche quand tout va bien, il n'y a pas de vérification du résultat, pas de mode d'emploi, pas d'inscription au registre, et la personne qui l'a bâti est passée à la prochaine affaire brillante. Ce dernier dix pour cent, c'est là que la machine devient vraiment une machine.
Alors on en bâtit moins, et on les finit. Une machine est terminée quand elle peut rouler une semaine sans moi, me dire quand elle n'y arrive pas, et être comprise par quelqu'un qui ne l'a pas bâtie.