Une automatisation qui tient en réunion peut s'arrêter dès le lundi, sans que personne ne le voie. Je raconte ici comment je passe d'une démo au système que l'équipe utilise vraiment : surveiller, reprendre après une erreur, tenir un journal, documenter, et passer la main.
Le chemin heureux ne suffit pas
En démo, les données sont propres, le réseau répond, et je suis devant l'écran pour relancer à la main. En production, un formulaire arrive incomplet, une API tarde, un compte expire au milieu du parcours. Le flux doit le montrer. Ensuite il décide s'il réessaie, ou s'il attend une personne.
Je commence par le parcours, pas par l'outil. Qu'est-ce qui déclenche le travail. Quelle sortie vous attendez : un message, une fiche, un fichier. Qui reprend la main si l'assistant, ou le scénario n8n, ne suffit pas. n8n, Supabase, Docker ou une API viennent après. Si personne n'est nommé pour lire une alerte, la technique n'a personne à prévenir.
Surveiller, sinon le silence ressemble à un succès
Un flux qui ne plante pas bruyamment peut simplement ne plus rien faire. Le silence ressemble alors à une journée calme. Je ne construis pas un tableau de bord pour la forme. Je veux pouvoir répondre à trois questions, même plus tard.
- Le déclencheur a-t-il reçu l'événement.
- L'étape suivante a-t-elle répondu.
- La sortie attendue est-elle arrivée : un message, une fiche, un fichier.
Si l'une manque, ce n'est pas un calme normal. C'est un silence. Une alerte courte, lue par une personne désignée, vaut mieux qu'une courbe que personne n'ouvre. Elle dit ce qui s'est arrêté, et où reprendre.
Un système peut être techniquement en place et rester inutilisé. La surveillance sert d'abord à savoir s'il sert encore.
Reprendre après une erreur
L'erreur fait partie du parcours. Je sépare ce qui peut être retenté de ce qui doit s'arrêter. Retenter un appel réseau a du sens : le service peut répondre la fois suivante. Retenter une action déjà engagée n'en a pas, par exemple envoyer encore le même message à la personne qui attend.
Une vérification de santé, très courte, dit si le flux est en état de travailler. Elle ne juge pas le métier. Elle évite de relancer à l'aveugle, ou de croire qu'un écran de démo décrit encore la réalité.
GET /health
200 {"workflow":"parcours-client","status":"healthy"}
POST /runs/{id}/retry
202 {"status":"requeued"}
# reprises épuisées
status: needs_human
journal: raison de l'arrêt
notify: personne désignée
Quand les reprises raisonnables sont épuisées, une personne doit trancher. Le journal reçoit la raison. La personne désignée est prévenue. Mieux vaut un cas en attente, lisible, qu'un message parti une seconde fois parce que le scénario a été rejoué en entier.
Le journal est la mémoire
Chaque exécution laisse une trace que vous pouvez relire : ce qui est entré, ce qui est sorti, où cela s'est arrêté, et si quelqu'un est intervenu. Pas un roman. Assez pour reprendre le fil plus tard, sans vous souvenir de la démo ni me demander de la raconter.
J'en retire les secrets avant qu'ils n'y restent. Un jeton, une clé d'API, un numéro complet n'ont rien à faire dans un journal que l'équipe doit pouvoir ouvrir. Si la trace ne permet pas de comprendre l'arrêt, c'est la trace qui est incomplète, pas l'équipe.
Écrire pour la personne qui reprend
La documentation que je laisse tient sur peu de lignes. Si vous reprenez le flux sans moi, cette page doit suffire.
- À quoi sert le flux, en une phrase.
- Ce qui le déclenche.
- Où il écrit.
- Comment le relancer.
- Qui appeler quand l'alerte sonne.
Si je suis le seul à pouvoir le réparer, ce n'est pas encore en production. C'est une démo qui dépend de ma présence. La page de reprise est le minimum pour qu'une autre personne continue, avec le journal sous les yeux.
Passer la main à l'équipe
La passation n'est pas un dossier déposé dans un coin. Je fais tourner le flux avec l'équipe : un cas ordinaire, puis un cas qui échoue. Nous lisons l'alerte ensemble. Nous relançons, ou nous décidons d'arrêter. Nous notons qui tranche quand je ne suis pas là.
Je reste joignable le temps des premières vraies journées. Le critère n'est pas que la démo ait plu. C'est que l'équipe s'en serve quand je ne suis pas dans la pièce, et que la personne désignée sache quoi faire en ouvrant le journal.
