Quand ça casse :
erreurs courantes, debugging, et le parc qui vieillit bien.
Tout scénario finira par échouer un jour — API en panne, mot de passe changé, champ renommé. La différence entre l’automatisation qui dure et celle qu’on abandonne : la panne prévue d’avance. Dernière leçon du module : filets, diagnostic en 4 questions, et hygiène du parc.
Vidéos de cette formation : toutes les vidéos sont en français ou sous-titrées en français. Activez les sous-titres via l’icône CC du lecteur si besoin.
« Le scénario des accusés de réception tournait parfaitement depuis quatre mois. Puis l’entreprise a changé de mot de passe email — bonne pratique de sécurité — et personne n’a pensé au scénario. Résultat : trois semaines de demandes entrantes sans aucune réponse automatique, découvertes par un prospect vexé. La panne n’était pas grave. La panne SILENCIEUSE l’était. »
Section 01Les pannes sont prévisibles — leur silence ne doit pas l’être
Quatre causes couvrent l’essentiel des échecs : la connexion expirée (mot de passe changé, autorisation révoquée — la cause n°1), le changement chez l’autre (champ renommé, application mise à jour, API modifiée), la donnée imprévue (champ vide, format inattendu — le « Müller » de la L2), et le quota dépassé (limite d’opérations atteinte en fin de mois). Aucune n’est évitable à 100 % ; TOUTES sont détectables immédiatement — si le filet de la L2 est en place : notification d’échec systématique, vers un humain nommé. La règle d’or du module se joue ici : une automatisation qui peut échouer en silence n’aurait jamais dû être activée.
Section 02La confiance dans l’automatisation est un capital — une panne mal gérée le brûle
Rappelez-vous le contre-exemple de la L4 : UNE relance envoyée à tort, et le dirigeant a tout coupé. C’est le vrai coût des pannes mal gérées : pas les minutes d’interruption, mais la défiance durable — le retour aux corvées manuelles « parce qu’on ne peut pas faire confiance à ces trucs ». À l’inverse, une panne bien gérée (détectée en minutes, diagnostiquée en dix, réparée dans l’heure) renforce la confiance : l’équipe constate que le système est TENU. Même mécanique que la réclamation client (M4 L4) — le paradoxe de la récupération vaut aussi pour vos robots. Et l’hygiène trimestrielle évite le stade terminal : le « cimetière de scénarios » que plus personne ne comprend ni n’ose toucher.
Section 03Prévenir, diagnostiquer, entretenir
Section 04Vidéo : gérer les erreurs dans Make — guide complet (en français)
Ce guide en français (par IA Suisse) détaille les gestionnaires d’erreur de Make — Break, Ignore, Resume — avec les cas d’usage de chacun. Regardez, puis équipez vos scénarios existants : notification d’échec d’abord, gestionnaires ensuite.
Section 05Deux cas types — et le cimetière de scénarios
Même cause, un an plus tard : mot de passe changé — mais cette fois, le filet
L’entreprise de l’anecdote, équipée depuis : nouveau changement de mot de passe email un mardi à 9 h. À 9 h 04, première exécution en échec → alerte à l’assistante (humain nommé). Question 1 du diagnostic : connexion → reconnexion du compte en trois clics. À 9 h 15, tout tourne — et les quatre demandes arrivées entre-temps sont rejouées depuis l’historique. Trois semaines l’an dernier, onze minutes cette année : la différence n’est pas la chance, c’est le filet testé.
« 429 Too Many Requests » — du charabia au plan d’action en une question
Une erreur cryptique bloque le scénario de facturation : « 429 Too Many Requests ». Panique évitée : le message collé dans ChatGPT (M21) avec le prompt de debug. Réponse en français : quota d’appels dépassé chez l’outil comptable, réessayer avec un délai entre les lots, ou lisser l’exécution. Correctif appliqué (traitement par paquets de 10 avec pause) en vingt minutes, sans prestataire, sans ticket support. Le duo automatisation + IA se dépanne lui-même — c’est toute la promesse de l’univers IA du catalogue.
19 scénarios, 3 auteurs partis, zéro documentation — et l’audit impossible
Trois ans d’enthousiasme sans hygiène : 19 scénarios actifs, construits par trois personnes dont deux ont quitté l’entreprise, aucune documentation, des noms comme « Test2-final-OK ». Personne ne sait ce qui casse quoi si on en coupe un — alors on n’y touche plus, on paie les quotas, et on refait À CÔTÉ (des scénarios en doublon, qui parfois se contredisent : deux emails de bienvenue différents partent au même client). Règles Dé Click : la documentation 5 lignes est obligatoire à l’activation (pas « plus tard ») ; des noms parlants (« Facturation-relance-J3 », jamais « Test2 ») ; la revue trimestrielle désactive les zombies ; et tout scénario doit avoir deux personnes capables de le réparer — le bus factor vaut aussi pour les robots.
Section 06Quiz, ressources & à retenir
Votre scénario d’accusés de réception est en échec depuis ce matin (alerte reçue). Quelle est la PREMIÈRE vérification ?
Documentation officielle
Sur Dé Click Group
Les 5 idées-clés de cette leçon
- Toute automatisation finira par échouer : la règle d’or est zéro panne silencieuse — chaque échec notifie un humain nommé.
- Les 4 causes : connexion expirée (n°1), changement externe, donnée imprévue, quota — et les 4 questions se posent dans cet ordre.
- Le filet complet : notification testée, gestionnaires d’erreur aux étapes critiques (Ignore/Resume/Break selon gravité), documentation 5 lignes, interrupteur connu.
- L’IA traduit le jargon d’erreur en plan d’action — collez le message, demandez le diagnostic en français.
- Hygiène trimestrielle : inventaire, zombies désactivés, noms parlants, et deux personnes capables de réparer chaque scénario.
« Si vous trouvez qu’une formation coûte cher, vous n’imaginez pas le prix de ne pas la faire. »
Bravo, vous êtes allé au bout ! 🎉
Le vrai déclic, c’est maintenant : appliquez ce que vous venez de voir avec l’outil de la leçon, pendant que c’est frais. Dix minutes, un livrable.
Cette leçon vous a été utile ?