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.
Les 5 garde-fous obligatoires
Chaque automatisation que tu mets en production devrait avoir ces cinq mécanismes. Pas un de moins.
Garde-fou 1 : L'idempotence
Une action exécutée deux fois doit produire le même résultat qu'une seule exécution. C'est le principe le plus important et le plus souvent ignore. En pratique : avant d'agir, verifie si l'action a déjà été faite. Un ID unique par événement, un timestamp de dernière exécution, un flag "traite".
Garde-fou 2 : Les limites de volume
Définis un plafond. Si ton scénario traite normalement 20 éléments par heure et qu'il en recoit 500, quelque chose ne va pas. Un raté limiter ou un compteur avec alerte te previent avant que les degats s'accumulent.
Garde-fou 3 : Le log structuré
Chaque exécution doit laisser une tracé : quoi, quand, combien, résultat. Pas un log technique illisible, mais un registre business. "12 mars, 14h23 : 8 relances envoyees, 2 ignorees (déjà envoyees)." Sans log, tu ne peux pas diagnostiquer, tu ne peux pas auditer, tu ne peux pas améliorer.
Garde-fou 4 : Les alertes
Tu ne vas pas surveiller tes automatisations toute la journée. Mais tes automatisations peuvent te surveiller. Une alerte quand le taux d'erreur dépassé 5%. Une notification quand un scénario n'a pas tourne depuis 24h. Un email quand un volume anormal est detecte.
Les alertes sont le remplacement du regard humain. Elles sont non-negociables pour tout scénario qui touche des clients ou de l'argent.
Garde-fou 5 : Le kill switch
Un mécanisme pour tout arrêter en un clic. Pas "désactiver le scénario, chercher le bon module, cliquer sur pause". Un seul bouton. Un flag dans ta base de données que tous tes scénarios verifient en premier : automations_enabled = true. Passe-le a false, tout s'arrêté. MIT Sloan insiste sur ce point pour les entreprises agentiques : plus l'autonomie des agents augmente, plus le besoin de mécanismes d'arrêt devient critique.
Ça paraît excessif jusqu'au jour ou tu en as besoin.
Le bon workflow de mise en production
Avant de publier une automatisation, tu dois suivre ces étapes. C'est l'équivalent de construire un bon processus applique a l'automatisation elle-même.
- Teste en sandbox. Pas sur tes vraies données. Jamais. Un environnement de test avec des données fictives.
- Lance sur un sous-ensemble. 10 clients, pas 500. Verifie les résultats manuellement.
- Active le monitoring. Logs, alertes, compteurs. Avant de passer a l'échelle.
- Passe en production. Avec le kill switch actif et les limites de volume configurees.
- Revois après 2 semaines. Les premiers jours revelent les cas limites.
Ce workflow prend du temps. Moins que réparer les degats d'une automatisation lancée a l'arrache.
Automatisation progressive : le filet de sécurité
L'approche la plus sure est progressive. Au lieu d'automatiser tout d'un coup, tu augmentes le niveau d'autonomie par paliers. C'est le même principe que savoir quand automatiser un processus : chaque palier est un checkpoint.
| Palier | Description | Risque |
|---|---|---|
| Manuel assisté | L'outil prepare, tu exécutés | Minimal |
| Semi-automatique | L'outil execute, tu valides avant envoi | Faible |
| Automatique supervise | L'outil execute seul, tu vérifiés après | Modere |
| Autonome | L'outil execute seul, tu audites par échantillonnage | Eleve |
Ne passe au palier suivant que quand le précédent est stable depuis 2 semaines.
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.
PluginFactory
Cas client
