L'automatisation qui tourne mal coute plus cher que le manuel
Retour terrain sur les automatisations qui ont derape et les garde-fous concrets pour garder la main sur ses workflows.
Un scénario Make qui envoie 300 emails en double a tes clients. Un webhook qui créé des factures en boucle a 3h du mâtin. Un script qui supprime des données parce qu'un champ a change de format. L'automatisation qui derape ne previent pas. Elle agit, vite, et en masse.
Le problème n'est jamais l'automatisation elle-même. C'est l'absence de garde-fous. MIT Sloan documente que 30 a 50% des projets RPA echouent lors du premier déploiement. Un sondage HBR/Fortuné va plus loin : seules 6% des entreprises font pleinement confiance a leurs agents IA autonomes. Un processus manuel a un garde-fou naturel : toi. Quand tu automatises, tu retires ce garde-fou sans le remplacer.
Trois automatisations qui ont derape
Cas 1 : L'email en boucle. Un scénario de relance client se declenche sur un webhook. Le webhook envoie un doublon. Le scénario s'execute deux fois. Chaque exécution envoie un email. Le client recoit 2 relances identiques. Pas dramatique ? Ça l'est quand ça touche 150 clients un vendredi soir.
La cause : aucun controle d'idempotence. Le scénario ne verifie pas s'il a déjà traite cet événement. La solution : un champ "dernière relance envoyee" dans le CRM, verifie avant chaque envoi.
Cas 2 : La suppression silencieuse. Un script archive les projets "termines" après 30 jours. Un client recontacte pour une modification. Son projet a été archive avec les fichiers de configuration. 4 heures pour restaurer.
La cause : pas de soft delete. La solution : un statut "archive" réversible, avec une période de grâce de 90 jours.
Cas 3 : La facture fantôme. Un webhook Stripe créé une facture dans le CRM a chaque paiement. Stripe renvoie le webhook après un timeout. Deux factures créées. Le doublon detecte en fin de mois seulement.
La cause : pas de déduplication sur l'identifiant Stripe. La solution : stocker l'ID du webhook et ignorer les doublons.
Le coût de la sur-automatisation
Il existe un seuil au-delà duquel automatiser devient contre-productif. Quand la maintenance des scénarios prend plus de temps que le processus manuel. Quand les cas limites representent 30% du volume.
L'objectif n'est pas d'automatiser le maximum. C'est d'automatiser le bon processus, au bon niveau, avec les bons garde-fous. McKinsey note d'ailleurs que les organisations les plus avancées en IA sont aussi celles qui investissent le plus dans le monitoring et les garde-fous. C'est exactement l'approche que PluginFactory applique pour ses clients : des workflows pilotes par des plugins Claude Code avec idempotence, alertes et kill switch intégrés.
En resume
- L'automatisation sans garde-fou est un risque, pas un gain.
- 5 garde-fous obligatoires : idempotence, limites de volume, logs, alertes, kill switch.
- Tester avant de déployer : sandbox, sous-ensemble, monitoring, puis production.
- Progresser par paliers : manuel assisté, semi-auto, auto supervise, autonome.
- Savoir s'arrêter : tout ne mérite pas d'être automatise.
Comme le résume Arvid Kahl dans sa newsletter The Bootstrapped Founder : automatise, puis détends-toi, mais seulement si tes garde-fous sont en place.
L'automatisation bien faite libere du temps. L'automatisation mal faite en consommé deux fois plus.