12 000 e-mails en quatre heures : anatomie d'une automatisation qui s'emballe

Le bug classique d'un développeur, on le voit : un écran qui plante, une page blanche, une erreur affichée. Le sinistre du no-code d'automatisation est d'une autre nature. Il est silencieux, autonome et démultiplié. Vous avez branché un scénario Make ou Zapier qui se déclenche tout seul, des centaines de fois par heure, sans qu'aucun humain ne regarde. Tant que la logique est juste, c'est un gain de productivité magnifique. Quand elle dérape, c'est une machine à répéter une erreur des milliers de fois avant que quiconque s'en aperçoive.

Les causes sont presque toujours les mêmes, et toutes vous sont familières :

• Une boucle mal bornée qui se relance en cascade sur ses propres résultats.
• Un déclencheur trop large qui se réveille sur des enregistrements qu'il aurait dû ignorer.
• Un doublon de scénario ou une réactivation accidentelle après modification.
• Une condition manquante ou inversée qui laisse passer ce qu'elle aurait dû filtrer.
• Une donnée d'entrée inattendue (champ vide, format changé) qui fait dévier toute la chaîne.

Le point commun : entre le moment où l'erreur démarre et celui où on la détecte, l'automatisation a eu le temps d'agir des milliers de fois. C'est l'effet de levier du no-code qui se retourne contre tout le monde.

Déroulons un cas réaliste. Vous avez livré à une boutique en ligne un scénario d'automatisation : à chaque nouvelle commande, le système envoie un e-mail de confirmation et enregistre la facture. Une modification mineure du connecteur côté plateforme renvoie soudain les anciennes commandes comme "nouvelles". Le scénario, trop permissif, les retraite toutes. La nuit, personne ne surveille.

Voici comment le préjudice s'empile heure après heure :

Aucun serveur n'a brûlé, aucune donnée n'a fui. Et pourtant, le préjudice cumulé peut atteindre plusieurs milliers à plusieurs dizaines de milliers d'euros entre les remboursements, les heures de remise en ordre, la perte de clients agacés et l'atteinte à la délivrabilité du domaine. C'est tout le piège du dommage immatériel démultiplié : invisible sur le moment, lourd au bilan.

Pire : un envoi massif d'e-mails non sollicités peut constituer un manquement aux règles sur la prospection et exposer le client à une réclamation ou une sanction côté protection des données. Le sinistre technique se double alors d'un risque réglementaire.

Comme pour tout litige de prestation, la question n'est pas "y a-t-il eu un dommage" mais "d'où vient-il". Une automatisation qui s'emballe ne vous est pas automatiquement imputable, mais certains éléments penchent lourdement.

Vers votre responsabilité :

• Une absence de garde-fous : pas de limite d'exécutions, pas de condition de sécurité, pas d'alerte.
• Un scénario testé directement en production, sur les vraies données du client.
• Une boucle ou un déclencheur dont la logique était défaillante dès la conception.
• Une mise en service sans documentation ni consigne de surveillance remise au client.

Vers l'aléa, plus difficile à vous reprocher :

• Un changement d'API ou de comportement de la plateforme survenu après la livraison, imprévisible.
• Une intervention du client qui a modifié le scénario, ajouté une étape ou changé un réglage.
• Une donnée corrompue en amont par un autre outil hors de votre périmètre.

Ce qui distingue le professionnel diligent, ce n'est pas que son automatisation ne dérape jamais : c'est qu'il l'a conçue avec des bornes. Une limite d'exécutions, une condition de sécurité, une alerte de seuil transforment un emballement catastrophique en simple incident détecté à temps.

Le délai de détection pèse aussi lourd dans l'appréciation. Un scénario qui s'arrête au bout de 50 exécutions grâce à une alerte reste un incident maîtrisé. Le même scénario laissé tourner 12 000 fois faute de garde-fou fait basculer le dossier vers la faute caractérisée. La RC Professionnelle couvre les dommages immatériels causés au client par une faute de prestation, mais votre rigueur de conception détermine si vous êtes en faute ou dans l'aléa.

La bonne nouvelle, c'est que ce sinistre se prévient presque entièrement par des réflexes de conception. Le no-code n'exonère pas des bonnes pratiques d'ingénierie : il les rend même plus critiques, puisque l'automatisation agit sans supervision.

Les garde-fous qui changent tout :

• Une limite d'exécutions ou de débit par période, pour qu'aucun scénario ne puisse partir à l'infini.
• Des conditions de sécurité en début de chaîne (filtrer sur une date, un statut, un identifiant déjà traité) pour éviter de retraiter l'ancien.
• Une protection anti-doublon : marquer chaque enregistrement traité pour ne jamais le reprendre.
• Des alertes de seuil qui vous préviennent (ou préviennent le client) dès qu'un volume anormal est atteint.
• Un mode dégradé ou un interrupteur d'arrêt d'urgence facile à actionner.

Surtout, ne testez jamais un scénario en production sur les vraies données du client. Un environnement de test, des données factices, une validation par lots avant l'activation complète : ces étapes paraissent lentes, mais elles sont précisément ce qui empêche un emballement de toucher de vrais clients et de vraies factures. Activez progressivement : faites tourner le scénario sur dix enregistrements, vérifiez le résultat, puis cent, avant de l'ouvrir à l'ensemble du flux.

Pensez enfin à la réversibilité. Une automatisation qui envoie un e-mail est irréversible : une fois parti, on ne le rattrape pas. Une automatisation qui supprime ou modifie des enregistrements peut, elle, être rendue réversible si vous prévoyez une copie de sauvegarde avant action, ou un statut "à supprimer" plutôt qu'une suppression sèche. Concevoir l'automatisation pour qu'on puisse revenir en arrière, c'est se donner une chance de réparer un emballement avant qu'il ne devienne définitif.

Quand un scénario a déraillé, deux choses déterminent l'issue : votre capacité à prouver ce que vous avez fait, et votre couverture. Préparez les deux avant l'incident, jamais après.

Côté preuves, conservez systématiquement :

• L'historique d'exécution (logs) des scénarios, qui montre quand et pourquoi l'emballement a démarré.
• La documentation de conception : déclencheurs, conditions, garde-fous mis en place.
• Les échanges avec le client sur les limites du système et les consignes de surveillance.
• La trace des modifications apportées par le client après livraison, le cas échéant.

Côté contrat et assurance, soignez :

• Un périmètre de mission écrit qui distingue ce que vous livrez de ce que le client exploite ensuite.
• Une RC Pro couvrant les dommages immatériels démultipliés, qui sont la signature de ce métier.
• Une option Cyber pertinente dès que l'automatisation touche aux données personnelles ou à des envois en masse, vu le risque réglementaire associé.

Un emballement d'automatisation est l'illustration parfaite du risque no-code : pas de ligne de code en feu, mais une erreur répétée des milliers de fois et un préjudice qui grimpe vite. Pour un développeur no-code, l'RC Pro démarre à 9,90 €/mois ; l'option Cyber et le détail des garanties sont précisés sur la fiche développeur no-code.