J'ai saboté mon automatisation pour voir si elle tenait

Sabotage volontaire, résultat inattendu.

La question qui décide si une automatisation vaut quelque chose n'est pas « est-ce que ça marche ? ». C'est « qu'est-ce qui se passe dans trois mois, quand une source change d'adresse sans prévenir ? »

Alors j'ai cassé le système exprès. J'ai glissé un flux bidon dans ma liste de sources — une adresse qui ne répond pas — et j'ai laissé tourner une nuit.

Dans la majorité des automatisations, c'est fatal. Un seul maillon saute et l'ensemble s'effondre. Tu te réveilles, rien n'est généré, rien n'est parti, et personne ne t'a prévenu.

Le lendemain matin, notification. Le flux mort est nommé, avec son adresse exacte. Et juste au-dessus, l'édition du jour est bel et bien là. L'audience reçoit son contenu comme d'habitude. Personne ne s'est rendu compte de rien.

C'est la différence entre un workflow qui échoue et un workflow qui dégrade. Un site en panne ne prend pas la publication en otage : il est signalé, tu le remplaces quand tu as cinq minutes, et le reste continue sans toi.

❓ Que se passe-t-il si un flux RSS meurt dans une automatisation ?
Dans un workflow non protégé, l'exécution entière échoue. Avec une gestion d'erreur par source, le flux défaillant est isolé et signalé pendant que les autres continuent.

❓ Comment tester la robustesse d'une automatisation ?
En provoquant délibérément la panne la plus probable, puis en vérifiant que la sortie attendue est quand même produite.

❓ C'est quoi un test de santé automatisé ?
Une vérification programmée qui contrôle chaque source et alerte sur celles qui ne répondent plus, sans bloquer le reste du traitement.

Système bâti avec n8n, Supabase et Telegram.

#n8n #nocode #workflow