Deux pannes, racontées en entier

Un système automatique tombe en panne un jour ou l'autre. Ce qui compte, c'est de le voir vite, de réparer sans rien casser d'autre, et que la même panne ne revienne pas. Voici deux pannes réelles, avec ce que nous avons changé.

1. Le rapport qui ne pouvait plus sortir

Découverte le 30 juin 2026 · chaîne d'analyse d'avis sur n8n Cloud (27 étapes)

Ce qui s'est passé

Notre chaîne collecte des avis publiés en ligne, les fait analyser par un modèle de langage, met le résultat en page et envoie un rapport PDF. Une mise à jour antérieure avait été faite par l'interface de programmation de n8n, avec un script qui n'écrivait pas en UTF-8 (la norme qui code les accents). Elle avait remplacé les caractères spéciaux de dix étapes par « ? » ou « � ». Dans l'étape qui construit le rapport, une expression régulière (un motif de recherche dans le texte) cherchait le symbole « ▸ » : devenue /^?\s+/gm, elle était invalide. L'étape plantait à chaque passage : aucun PDF ne pouvait plus sortir.

Pourquoi personne ne l'a vu

Aucune vente n'avait encore eu lieu, donc la chaîne n'avait jamais tourné pour de vrai depuis cette mise à jour. Et l'étape précédente annonçait déjà au client « rapport dans 10 minutes ». Le scénario le plus coûteux était possible sans aucun signal : le client paie, rien n'arrive.

Comment nous l'avons trouvée

Par un test complet du parcours payant, le 30 juin : un jeton de test, le formulaire d'accueil, toute la chaîne, jusqu'au PDF et à l'e-mail. Le test a échoué à l'endroit exact où le rapport se construit. Aucun client n'a été touché.

Ce que nous avons changé

Correction : le jour même. Nous sommes repartis de la version en ligne, pour garder les accès et les liaisons intacts, et avons réinjecté le texte propre depuis notre source versionnée. Les séparateurs décoratifs sont passés en caractères simples. En réparant, nous avons trouvé une deuxième cause : l'interface de n8n Cloud peut elle-même abîmer les longues suites de caractères spéciaux à l'écriture (2 « ═ » sur 31 devenus « � »).
Tests ajoutés : le parcours payant complet a été rejoué après chaque reprise, jusqu'au PDF accepté par le serveur d'e-mail, sans un caractère cassé. Et un piège a été levé : notre propre script de vérification mentait. Le « � » qu'il cherchait avait été déformé par l'éditeur de texte, si bien qu'il comptait zéro à tort. Ce caractère se cherche désormais par son code (U+FFFD), plus par sa forme.
Détection : avant chaque modification, un instantané, c'est-à-dire une copie complète. Après, une comparaison octet par octet du code de chaque étape avec la source. Nos outils de mise à jour comptent les caractères non-ASCII avant et après, et abandonnent si le compte change. Un gestionnaire d'erreurs central est branché sur tous les workflows de production. Depuis le 16 octobre, nous modifions les workflows par opérations partielles plutôt qu'en remplaçant tout le fichier. La méthode a été testée sur une copie qui reproduit le motif exact de l'incident : texte intact.

La leçon

Tant que le chemin du client n'est pas testé jusqu'au PDF envoyé, on peut promettre un résultat que le système ne sait plus produire.

2. Deux jours de panne, et personne ne le savait

Du 11 au 13 août 2026 · projet personnel du fondateur : collecte de données de marché et décisions automatiques en Python, sur un compte de démonstration, sans argent réel

Ce qui s'est passé

Le compte de démonstration du courtier avait expiré : c'était un essai de 14 jours. Le 11 août au matin, les ordres ont été refusés ; le soir, la collecte s'est arrêtée ; les deux jours suivants, la connexion était refusée.

Pourquoi personne ne l'a vu

La tâche planifiée de Windows affichait « En cours d'exécution » pendant qu'elle écrivait environ 19 700 erreurs en six heures. Ces erreurs partaient dans un fichier journal et une base que rien ne lisait. La vraie cause n'était pas le compte expiré : il n'existait aucun canal d'alerte.

Comment nous l'avons trouvée

Deux jours plus tard, par une simple question : « pourquoi je n'ai pas eu d'alerte ? » Deux jours de collecte perdus, aucun argent en jeu.

Ce que nous avons changé

Correction : une sentinelle de santé. Elle ne fait que lire : elle n'ouvre aucune session, car une panne de connexion ne doit pas empêcher de diagnostiquer une panne de connexion. Elle vérifie la fraîcheur des données et les erreurs, écrit un état OK, DEGRADE ou KO lu chaque matin, et ne prévient qu'en cas de problème. Ses seuils tiennent compte des week-ends, où les marchés sont fermés.
Tests ajoutés : de 359 à 381 tests, dont 10 pour la sentinelle. Six autres ont suivi quand le compte a reçu sa date d'expiration. La sentinelle passe en DEGRADE quatre jours avant ; une date absente donne DEGRADE, jamais OK.
Détection, dès le lendemain : le 14 août à 10h15, la sentinelle a signalé une deuxième panne muette. Le journal des ordres ne se refermait jamais : 25 ordres restaient « ouverts » dans la base alors qu'ils étaient fermés chez le courtier, certains depuis le 22 juillet. La base a été remise d'accord avec le courtier, et le défaut corrigé.

Le 9 septembre, l'inverse s'est produit : la sentinelle criait au loup. Elle lisait une marque horaire au lieu du vrai pouls, un relevé par seconde, et annonçait onze heures sans données alors que 27 743 relevés avaient bien été écrits. Une coupure de 90 secondes laissait l'alarme rouge six heures. Nous l'avons corrigée, avec quatre tests qui verrouillent les quatre cas limites, dont « collecte arrêtée, donc KO ». Remplacer une alarme qui ment par une alarme qui dort ne serait pas un progrès.

Depuis, une règle s'applique à toutes nos tâches planifiées : une tâche doit échouer bruyamment quand le travail n'est pas fait. S'abstenir pour une bonne raison, marché fermé par exemple, n'est pas une erreur ; une panne d'infrastructure en est une, et elle se voit.

La leçon

Une alarme muette et une alarme qui crie pour rien sont le même défaut : on ne peut plus se fier au signal.

Une question sur ces pannes, ou sur la fiabilité de vos propres automatisations : la page Contact.