Un scénario tourne depuis des mois, personne n'en parle, tout le monde suppose que ça marche. Puis quelqu'un remarque qu'un client n'a rien reçu depuis mars. On remonte le fil : le scénario s'est arrêté un jeudi soir, l'alerte est partie sur l'adresse mail d'une personne qui a quitté l'entreprise, et cinq mois de traitements se sont volatilisés sans un bruit. Ce scénario, je l'ai vu suffisamment de fois pour savoir que le silence n'est pas un signe de bonne santé.
Les quatre causes qui reviennent
Le format d'entrée change. C'est de loin la première. Quelqu'un ajoute une colonne dans le fichier, renomme un champ dans le CRM, ou l'API du fournisseur passe une date d'un format à un autre. Le scénario ne plante pas toujours : il traite en silence des valeurs vides, ce qui est pire.
Le quota d'API saute. Un pic d'activité, une boucle un peu gourmande, et le fournisseur commence à refuser les appels. Les outils réessaient souvent, puis abandonnent. Les enregistrements de cette tranche horaire n'ont jamais été traités, et rien ne le rappelle.
Les doublons. Un scénario relancé après incident retraite ce qui l'avait déjà été. Deux factures, deux mails au même client, deux lignes dans la comptabilité. Le nettoyage manuel coûte souvent plus cher que l'incident d'origine.
L'exécution partielle. Le cas le plus vicieux. Trois étapes sur cinq réussissent : la commande est créée, le stock est décrémenté, et la notification ne part pas. Le système est dans un état incohérent que personne n'a prévu, et qu'aucune relance simple ne répare.
Les patterns qui tiennent
L'idempotence
Le principe : rejouer une opération deux fois doit produire le même résultat qu'une seule fois. C'est l'unique protection sérieuse contre les doublons, et c'est ce qui rend une relance sans danger.
En pratique, ça se joue sur une clé. Chaque enregistrement traité porte un identifiant stable — numéro de commande, identifiant de ligne, empreinte du contenu. Avant d'agir, le scénario vérifie que cette clé n'a pas déjà été traitée. Une simple table, un fichier, une colonne dans la base : peu importe le support, il faut que ça existe.
Sans idempotence, tu n'oses pas relancer après un incident. Et si tu n'oses pas relancer, tu répares à la main.
La file d'attente
Séparer la réception du traitement. Le déclencheur écrit dans une file — une table, un canal, une liste de tâches. Un second scénario dépile et traite.
Ça paraît compliqué pour rien, et ça résout trois problèmes d'un coup. Si le traitement échoue, l'élément reste dans la file au lieu de disparaître. Si un pic arrive, la file absorbe et tu traites au rythme de tes quotas. Et tu vois, à tout moment, ce qui attend — une file qui grossit est un signal visible.
Le contrat d'entrée
Avant de traiter, vérifie que ce qui arrive ressemble à ce que tu attends. Les champs obligatoires sont présents, les types sont bons, les valeurs sont dans les bornes prévues.
Ce qui échoue à cette vérification ne se jette pas : ça part dans une zone de rejet, avec la raison. Cinq minutes de travail à la mise en place, et le jour où quelqu'un renomme une colonne, tu as un fichier de rejets explicite au lieu de trois cents enregistrements traités avec un champ vide.
L'alerte sur zéro exécution
Le point le plus important de cet article, et celui qui manque presque partout.
Toutes les alertes que les gens mettent en place se déclenchent quand quelque chose se passe mal. Elles ne se déclenchent jamais quand plus rien ne se passe du tout. Or c'est exactement le mode de panne le plus fréquent : le scénario est désactivé, le serveur est tombé, le déclencheur ne se déclenche plus.
Le correctif est simple. Un contrôle indépendant qui vérifie périodiquement : « ce scénario a-t-il tourné au moins une fois depuis N heures ? » Si non, alerte. Ce contrôle doit vivre ailleurs que le scénario surveillé — sinon il tombe avec lui.
Le test du débranchement. Désactive volontairement une automatisation importante. Combien de temps avant que quelqu'un s'en aperçoive ? Si la réponse dépasse une journée, tu connais ton risque.
Le journal lisible par un humain
Une ligne par exécution, en français, dans un endroit où un non-technicien peut aller regarder : date, quoi, combien d'éléments, résultat, et le motif en cas d'échec.
Pas les logs bruts de l'outil. Un journal fait pour être lu. Sa valeur apparaît le jour où quelqu'un demande « est-ce que le client X a bien reçu son document le 12 ? » et qu'on peut répondre en trente secondes sans réveiller la personne qui a construit le scénario.
Ce qui ne rend pas robuste
Multiplier les relances automatiques. Réessayer trois fois un appel qui échoue pour une raison transitoire, oui. Réessayer un appel qui échoue parce que la donnée est invalide, c'est reproduire la même erreur en payant plus cher.
Ajouter des notifications partout. Une alerte par exécution devient un filtre mail au bout de deux semaines, puis un dossier que personne n'ouvre. Peu d'alertes, qui signifient toutes quelque chose, valent mieux qu'un flux continu.
Compter sur la vigilance. « On verra bien si ça ne marche plus » n'est pas un dispositif. C'est ce qui produit les cinq mois de silence.
La demi-journée qui rentabilise le plus
Prends tes trois automatisations les plus critiques. Pour chacune : une clé d'idempotence, un contrôle de zéro exécution logé ailleurs, et un journal lisible. Vérifie aussi à qui partent les alertes — l'adresse d'une personne partie il y a deux ans est une panne en attente. C'est le meilleur retour sur temps investi que je connaisse sur ce sujet.