Deux types de panne : celle qui te prévient et celle qui te laisse croire que tout va bien
Quand quelqu'un demande comment savoir si une automatisation a échoué, il pense presque toujours à la panne bruyante : le flux s'arrête, l'outil envoie un mail, quelqu'un répare. C'est la bonne panne. Elle est visible, elle est bornée, et son coût est proportionnel au temps qu'il faut à quelqu'un pour regarder son téléphone.
Le problème, c'est l'autre. La panne silencieuse ne s'arrête pas : elle finit. Elle marque l'exécution en vert, ne casse rien et continue de tourner demain, tout aussi mal. Et aucune alarme ne sonne parce que, techniquement, il n'y a rien à signaler : chaque étape a fait ce qu'elle devait et est repartie sans erreur. L'outil te dit la vérité —« toutes les étapes se sont exécutées »— et toi tu lis autre chose —« le travail est fait »—. Ce n'est pas pareil.
La différence compte parce que le coût ne se ressemble pas. La panne bruyante coûte des heures. La silencieuse coûte des semaines, et quand on la découvre il faut déjà reconstruire en arrière : quelles commandes ne sont pas rentrées, quels clients n'ont pas eu de réponse, quelles factures ne se sont pas enregistrées. Ce guide s'accroche à celui de la maintenance des automatisations IA, qui explique pourquoi elles cassent. Ici, on s'occupe d'autre chose : comment tu t'en aperçois.
Les quatre visages de la panne silencieuse
En production, il y en a quatre qui reviennent, et aucune ne déclenche d'erreur. Les reconnaître, c'est déjà la moitié du travail.
1. Le succès vide
L'appel renvoie un 200 et le corps arrive vide, ou avec une liste de zéro élément. Pour le flux, c'est un succès parfait : il a demandé des données, a reçu une réponse, a continué. La boucle qui suivait n'a fait aucun tour, donc elle n'a rien créé, donc elle n'a rien raté. C'est le motif numéro un et le plus dur à repérer, parce que sur le tableau de bord ça ressemble trait pour trait à un bon jour.
2. Le filtre qui avale tout
Quelqu'un a changé un nom de champ dans le CRM, ou le format d'une date, et la condition qui laissait passer les enregistrements, plus aucun ne la remplit. Le flux s'exécute, filtre, et du filtre il ne sort rien. Exécution correcte, zéro travail fait. Ça se distingue du précédent sur un détail : ici, des données sont bien entrées, simplement aucune n'a franchi la porte.
3. La réponse inutilisable que personne ne valide
C'est la panne propre à l'automatisation avec l'IA. Tu demandes au modèle de renvoyer une catégorie ou un JSON, et il renvoie une excuse, un texte qui explique pourquoi il ne peut pas, ou le JSON enveloppé dans trois phrases de politesse. L'étape suivante l'accepte parce que c'est une chaîne de texte et qu'elle attendait une chaîne de texte. À partir de là, tout le flux travaille sur des déchets, en toute normalité. Ça se couvre avec une validation de forme avant de continuer : si ça ne respecte pas le format attendu, ça s'arrête et ça escalade. Le guide de l'humain dans la boucle détaille où poser ce filet selon ce que coûte l'erreur.
4. Le flux qui a cessé de tourner
Le plus bête et le plus fréquent. Personne ne l'a cassé : il s'est désactivé au changement de forfait, un identifiant OAuth a expiré, quelqu'un l'a mis en pause pour tester un jeudi et ne l'a jamais réactivé. Pas d'exécution, donc pas d'erreur, donc rien à signaler. Celui-là ne se détecte pas en regardant ce qui se passe. Il se détecte en remarquant l'absence de ce qui ne se passe pas.
Quoi alerter et quoi taire : une alarme qui sonne toujours, personne ne l'écoute
L'erreur inverse de ne pas avoir d'alertes, c'est de toutes les avoir. Un canal qui reçoit quarante avis par jour cesse d'être un canal d'alertes dès la deuxième semaine : on le coupe, on l'archive ou on l'ignore, et le jour où arrive l'avis qui comptait, il est noyé parmi trente-neuf autres. La fatigue d'alerte n'est pas un problème de personnes ; c'est un problème de conception.
La règle qui tient en production tient en une ligne : n'alerte que ce qui va faire lâcher à quelqu'un ce qu'il est en train de faire. Tout le reste ne disparaît pas, ça part sur un tableau qu'on regarde une fois par jour avec le café.
- Alerte une personne : le flux critique a vraiment échoué ; le flux critique n'a pas tourné depuis plus longtemps que d'habitude ; la file d'exceptions grossit deux jours de suite ; la dépense du jour sort de sa fourchette.
- Au tableau quotidien : erreurs ponctuelles résolues au réessai, cas escaladés vers une révision humaine, exécutions plus lentes que d'habitude, avis de plafond de forfait qui ne serrent pas encore.
- Ni à l'un ni à l'autre : tout ce que personne ne va jamais regarder. Si un avis n'a ni propriétaire ni action possible, ce n'est pas une alerte : c'est un log. Laisse-le dans les logs.
Commence court. Deux alertes par flux critique —il a échoué, et il a cessé de tourner— et tu n'en ajoutes une troisième que lorsqu'un incident réel démontre qu'elle manquait. Les alertes gagnent leur place ; elles ne se distribuent pas au cas où.
Le battement : repérer le flux qui a cessé de tourner
C'est la pièce que presque personne n'a et celle qui sauve le plus souvent. Un battement est une alerte qui sonne quand quelque chose N'arrive PAS. Le flux envoie un signal chaque fois qu'il finit bien ; un service externe l'attend ; s'il n'arrive pas dans la fenêtre prévue, il prévient.
Deux détails décident si ça marche. Le premier : le battement doit vivre en dehors de l'outil que tu surveilles. Si le gardien et le surveillé sont le même système, le jour où le système tombe, personne ne te prévient —et c'est justement ce jour-là que tu en as besoin—. Le second : la fenêtre se calibre sur le rythme réel du flux, pas sur l'idéal. Un flux qui tourne toutes les quinze minutes peut se permettre une heure de marge ; un flux quotidien ne devrait pas alerter pour vingt minutes de retard. Des fenêtres mal réglées produisent de fausses alarmes, et les fausses alarmes produisent des alertes coupées.
Confirmation de clôture : que la dernière étape prouve que le travail est arrivé
Le battement te dit que le flux a tourné. Il ne te dit pas qu'il a fait quelque chose d'utile. C'est là qu'intervient la confirmation de clôture : la dernière étape de chaque flux critique n'est pas l'action, c'est la vérification de l'action.
- Compte ce qui est entré et ce qui est sorti. Si quatorze enregistrements sont entrés et que zéro a été créé, ce n'est pas un jour tranquille : c'est une panne. Un flux qui traite zéro élément plusieurs jours de suite mérite un coup d'œil, pas un feu vert.
- Vérifie dans la destination, pas dans la réponse. Que l'API ait dit oui ne prouve pas que l'enregistrement existe. Une lecture retour —demander au système de destination l'enregistrement que tu viens de créer— transforme une supposition en fait.
- Réconcilie à cadence régulière. Une fois par jour, compare la source à la destination et cherche ce qui manque. C'est la seule chose qui détecte l'événement qui n'est jamais arrivé, parce qu'un webhook perdu ne génère aucune erreur : il génère une absence.
- Laisse une trace. Chaque exécution avec son identifiant, ce qui est entré, ce qui est sorti et sous quelle version. Sans ça tu ne peux pas reconstruire un cas précis quand quelqu'un le demande trois semaines plus tard ; c'est là qu'intervient la gouvernance et contrôle de l'automatisation IA.
Quand ça se déclenche : gravité, responsable et la règle des trois fois
Une alerte sans destinataire est une notification. Avant d'allumer quoi que ce soit, écris trois choses par flux critique : qui répond (une personne, pas un service), ce qu'on fait pendant que ça se répare (le plan manuel : continuer à facturer à la main n'est pas un échec, c'est le plan) et ce qui justifie d'appeler quelqu'un en dehors des heures. Presque rien ne le justifie ; mieux vaut le décider à froid qu'à 23h40.
Et une règle qui évite beaucoup d'incidents à venir : si la même panne se déclenche trois fois, arrête de la réparer et repense-la. Une erreur qui se répète n'est pas de la malchance, c'est une hypothèse fausse dans la conception du flux —un cas qui n'a pas été prévu, une API pas aussi fiable qu'on le croyait, un format qui change plus qu'on ne l'avait supposé—. Rafistoler une troisième fois garantit juste qu'il y en aura une quatrième.
Rien de tout ça n'est cher. Un battement externe, une confirmation de clôture et deux alertes bien choisies se montent en une après-midi par flux, et c'est la différence entre l'apprendre toi-même et l'apprendre par un client. Ce qui coûte, c'est de le tenir quand tu as vingt flux vivants et personne dont c'est le métier de les regarder : là, ce n'est plus monter des automatisations, c'est les opérer —et c'est exactement ce qu'on fait en automatisation des opérations—. Si tu es encore en train de décider quoi automatiser et avec quoi, reviens au guide pour automatiser avec l'IA ; si c'est déjà monté, commence par le flux qui ferait le plus de mal en échouant en silence.