Ce qu'on perd exactement quand une automatisation tombe (et pourquoi ce n'est pas « rien »)
La première question après une panne, c'est presque toujours « ça remarche ? ». La deuxième, celle que presque personne ne pose, c'est « et ce qui est arrivé pendant que ça ne marchait pas, il est où ? ». La réponse dépend d'une chose décidée le jour où le flux a été monté : est-ce que ce qui entre a une source consultable, ou est-ce que ça n'a existé que sous forme d'événement de passage ?
Les deux cas se comportent à l'opposé. Si ton flux lit quelque part où ça reste — les commandes de la boutique, les tickets du CRM, les mails d'une boîte —, tu n'as rien perdu : la donnée est toujours là, elle attend que quelqu'un la traite. Si ton flux dépend de quelqu'un qui te pousse la donnée — un webhook, une notification — et que l'émetteur ne réessaie pas et ne garde pas d'historique, cet événement s'est évaporé. Pas de trace, pas d'erreur, pas d'écran où aller le chercher.
- Ce qui est consultable se récupère. Commandes, enregistrements, documents : tout ce qui persiste à la source peut se redemander par plage de dates et se retraiter.
- Ce qui est poussé dépend de l'émetteur. Stripe, GitHub ou Shopify réessaient leurs webhooks pendant des heures ou des jours ; un script interne ou une intégration maison, presque jamais. Avant de faire confiance à un webhook, vérifie si son émetteur réessaie, et pendant combien de temps.
- Ce qui a été traité à moitié est le pire cas. Un flux qui a créé l'enregistrement mais qui est tombé avant de le marquer comme envoyé laisse le système dans un état qui n'est ni fait ni en attente. C'est celui qui produit des doublons au retraitement.
- Ce qui a été mal traité en silence n'est pas une perte, c'est une corruption. Ce plan-là ne le répare pas ; c'est la surveillance dont parle détecter les pannes dans les automatisations qui le détecte.
Cette distinction n'a rien de théorique : elle décide de ce qu'on peut promettre. Quand quelqu'un demande « on a perdu quelque chose ? », la réponse honnête, c'est « ce qui arrive par la boutique, non ; ce qui arrive par le webhook du fournisseur X, ça dépend s'il réessaie ». Et si tu ne l'as jamais vérifié, c'est la première tâche, avant tout retraitement.
L'idempotence d'abord : la réparation qui duplique les factures
Il y a une tentation énorme le jour de la panne : prendre le lot des heures noires et le repasser en entier. C'est rapide, ça donne l'impression d'agir, et c'est la façon la plus courante de transformer un petit incident en incident cher. Parce qu'une partie de ce lot a bien été traitée — les premières minutes, ce qui est passé dans les trous où le service répondait — et ce morceau-là va s'exécuter une deuxième fois.
La pièce qui empêche ça s'appelle l'idempotence, et ça veut dire exactement ceci : exécuter deux fois la même opération donne le même résultat que l'exécuter une fois. Ce n'est pas un réglage qu'on active ; c'est une propriété qu'on conçoit, et elle tient sur deux décisions concrètes.
- Une clé stable par unité de travail. Le numéro de commande, l'id du message, l'empreinte du document. Jamais l'horodatage, jamais un compteur d'exécution, jamais « l'enregistrement le plus récent » : ça change entre deux tentatives et ça casse la comparaison.
- Une étape d'écriture qui vérifie avant de créer. Chercher par cette clé et, si ça existe, mettre à jour ou sortir sans rien faire. Beaucoup d'API le règlent avec un en-tête de clé d'idempotence ou un « créer ou mettre à jour » natif ; quand il n'y en a pas, on le monte à la main avec sa propre table de clés déjà traitées.
Règle pratique qui évite des débats : si un flux n'est pas idempotent, il n'a pas de plan de reprise, il a un plan de risque. Et l'ordre compte — le rendre idempotent passe avant tout retraitement, même si le patron regarde sa montre. Retraiter un flux non idempotent pour gagner vingt minutes et sortir quarante factures en double, c'est une mauvaise affaire qu'en plus il faudra expliquer.
Réessais avec attente croissante : ce qu'on réessaie et ce qu'il ne faut jamais réessayer
La plupart des pannes n'ont besoin de personne pour être récupérées : elles se règlent seules si le système attend un peu et retente. Un délai d'attente dépassé, une limite de requêtes, un 503 d'un fournisseur en pleine mise en production. À condition que le réessai soit bien fait, et « bien fait » a une forme précise.
Attente croissante : ne pas réessayer chaque seconde, mais espacer les tentatives de plus en plus — quelques secondes, puis le double, puis le double encore —, avec un petit décalage aléatoire pour que mille exécutions tombées en même temps ne reviennent pas toutes en même temps. Réessayer en boucle immédiate contre un fournisseur à terre ne l'aide pas à se relever : ça le maintient au sol, et ça consomme ton quota au passage.
Et une distinction qui sépare les réessais utiles des réessais nuisibles : on réessaie ce qui a échoué à cause de l'environnement, pas ce qui a échoué à cause de la donnée. Un 500 ou un délai dépassé sont des candidats légitimes. Un 400 parce qu'un champ obligatoire manque, un 401 pour un identifiant expiré ou un 422 parce que le montant est négatif ne s'améliorent pas en se répétant : ça part direct dans la file d'échecs, parce que chaque réessai n'est que du bruit et du coût. Un flux qui réessaie cinq fois une erreur de validation dépense cinq fois et apprend zéro.
Combien de tentatives : entre trois et cinq couvre pratiquement tout le transitoire. Au-delà, la cause n'est plus un hoquet de l'environnement, et insister ne fait que retarder le moment où une personne l'apprend. Ce moment-là — le passage de réessayer à renoncer — c'est ce qui donne son sens à la pièce suivante.
La file d'échecs : où atterrit ce qui n'a pas pu passer et comment on le relance
Quand les réessais sont épuisés, le travail doit atterrir quelque part. Si cet endroit n'existe pas, il atterrit dans le log — c'est-à-dire nulle part. La file d'échecs, c'est cet endroit : une table, une feuille, un canal, peu importe, tant qu'elle garde trois choses pour chaque échec.
- La donnée d'origine intacte, pas un résumé ni le message d'erreur. Sans la charge complète, tu ne peux pas relancer : tu peux seulement enquêter.
- Le motif de l'échec et le moment, pour pouvoir regrouper. Deux cents échecs avec le même motif, c'est un problème ; deux cents avec des motifs différents, c'est deux cents problèmes.
- L'état : en attente, relancé, résolu ou écarté avec raison. Sans état, la file devient un cimetière que personne n'ose vider.
Ce qui change quand tu l'as, c'est la conversation. On passe de « on a perdu ce qui est arrivé hier » à « il y en a 214 en file : 190 ont échoué à cause du fournisseur à terre et se relancent telles quelles, 24 ont échoué en validation et demandent un œil ». Ça, c'est un incident gérable. Et ça ajoute un signal de santé qu'aucune alerte ne donne aussi bien : une file qui grossit prévient d'un problème systémique avant qu'un client ne le fasse.
La relance se fait par petits lots et dans l'ordre, jamais tout d'un coup. D'abord une poignée, on vérifie le résultat côté destination, et seulement ensuite le reste. Si le premier lot échoue pareil, la cause n'était pas réglée et tu viens de t'épargner deux cents répétitions de la même erreur. Tout ça suppose la section précédente : sans idempotence, relancer une file, c'est parier.
Réconciliation : comment tu retrouves ce qui n'est jamais entré
Réessais et file couvrent ce qui a échoué. Reste le vrai trou : ce qui n'a jamais été tenté. Le webhook perdu, le déclencheur désactivé, l'enregistrement écarté par le filtre pour un champ vide. Là, pas d'erreur, pas d'échec en file, rien à réessayer. Aucune trace qu'il aurait dû se passer quelque chose.
La seule façon de le retrouver, c'est d'arrêter de regarder l'automatisation et de comparer les deux bouts. Réconcilier, c'est ça : demander à la source tout ce qui a changé sur une fenêtre de temps, demander à la destination ce qui a été créé sur cette même fenêtre, croiser par la clé stable et garder la différence. Ce qui est à la source et pas à la destination, c'est exactement ce qui s'est perdu.
Trois détails décident si la réconciliation sert ou sort des faux positifs : utilise la même clé stable que l'idempotence (si tu compares par nom de client ou par montant, tu vas trouver des différences qui n'existent pas) ; laisse une marge de temps de quelques minutes aux bords de la fenêtre, parce que la donnée de source et celle de destination ne s'écrivent pas au même instant ; et décide de ce qu'elle fait de la différence : le plus prudent, c'est qu'elle l'envoie dans la file d'échecs pour la relancer par le chemin normal, pas qu'elle l'écrive directement par une voie parallèle qui saute les validations du flux.
La cadence dépend des dégâts, pas du volume. Quotidienne et automatique sur ce qui bouge de l'argent ou des engagements client ; hebdomadaire sur l'interne à faible impact. Et surtout permanente, pas seulement après une frayeur : la réconciliation vaut justement parce qu'elle retrouve la commande perdue un mardi ordinaire sans que rien ne soit tombé, celle qu'on découvre aujourd'hui quand le client écrit pour demander. C'est la même discipline de soin continu qui porte la maintenance des automatisations avec l'IA.
Le plan de reprise : qui l'exécute, dans quel ordre et avec quelle vérification finale
Les quatre pièces précédentes sont des capacités. Ce qui en fait une reprise, c'est un plan écrit à l'avance, court, que quelqu'un puisse exécuter le jour noir sans improviser et sans dépendre de la disponibilité de la personne qui a monté le flux. Ça tient en une demi-page et ça fait six étapes.
- 1. Couper l'entrée. Avant de récupérer, fermer le robinet : si le flux continue d'avaler pendant que tu retraites, tu ne sauras jamais quel lot est quoi.
- 2. Fixer la fenêtre. De quand à quand ça a été mauvais. Avec de la marge des deux côtés ; il vaut mieux trop que pas assez.
- 3. Confirmer l'idempotence du flux. S'il ne l'a pas, on la règle ici. On ne saute pas cette étape par urgence.
- 4. Réconcilier la fenêtre. Comparer source et destination, et envoyer la différence dans la file d'échecs.
- 5. Relancer par petits lots, en vérifiant la destination après le premier avant de continuer avec le reste.
- 6. Clôturer par une vérification de résultat, pas d'exécution : compter les enregistrements à la destination et les faire coller avec la source. Que le retraitement « se soit terminé sans erreurs » ne prouve rien.
Et une chose qui n'est pas technique mais qui décide du résultat : le plan a besoin d'un propriétaire avec un nom et un prénom, pas d'un service. La même règle qui gouverne tout le reste dans gouvernance et contrôle de l'automatisation : sans nom, il n'y a pas de contrôle, juste un document. Si tu montes l'ensemble depuis zéro, la carte complète est dans le guide pour automatiser avec l'IA.
La conclusion gênante, c'est que la reprise ne s'improvise pas : elle s'installe. Réessais, idempotence, file et réconciliation se montent quand tout va bien, parce que le jour où ça sert, il n'y a plus le temps de les construire. Si tes flux critiques ne les ont pas aujourd'hui, c'est exactement ce qu'on fait en laissant un processus en production chez automatisation des opérations : pas seulement que ça marche, mais que ça sache se reprendre quand ça ne marche plus.