Une automatisation a échoué : que vérifier avant de réessayer

Une automatisation indique une erreur et quelqu’un propose d’appuyer sur « Réessayer ». Avant cela, il convient de répondre à une question plus précise : que reste-t-il à faire ? Il peut manquer l’action, sa confirmation ou une étape ultérieure. Répéter le flux complet ne sert que pour l’une de ces situations et peut aggraver les autres.

Pour un fondateur ou une petite équipe, l’enquête doit pouvoir se poursuivre même si la personne ayant mis en place l’intégration est absente. Ce guide fournit une chronologie et une fiche pour distinguer ce qui est vérifié de ce qui est inconnu. L’exemple est fictif : il ne décrit pas d’incident Frihet et n’utilise pas de services, de clients ou d’identifiants de connexion réels.

L’erreur de l’écran et l’état du travail

Un timeout indique qu’une attente s’est terminée sans réponse à temps. À lui seul, il ne permet pas de savoir si la destination a sauvegardé quelque chose. AWS explique ce problème avec une requête qui aurait pu créer une ressource même si le demandeur n’a pas reçu de confirmation. Résoudre cette incertitude exige d’identifier l’effet et son origine.

Travaillez avec trois états : effet confirmé, absence d’effet confirmée et inconnu. « Il n’apparaît pas sur mon écran » appartient au troisième tant qu’il peut y avoir des filtres, un autre compte, un index en retard ou une exécution encore active. Notez également qui a vérifié l’état et à quelle heure : une observation a un contexte, pas une validité éternelle.

Une chronologie qui modifie la décision

Supposons un flux qui crée une tâche interne et enregistre ensuite sa référence dans une feuille de suivi. Tout ce qui suit est hypothétique. Les heures proviennent de la même horloge simulée ; dans une enquête réelle, conservez le fuseau horaire et la source de chaque horodatage.

L’étape suivante consiste à compléter uniquement le suivi manquant, selon sa procédure documentée. Redémarrer à partir de « créer une tâche » répéterait une action déjà terminée. Si la dernière ligne disait seulement « je ne le vois pas sur la feuille », nous devrions encore écarter un retard, un filtre ou un processus actif avant d’y écrire.

La référence d’opération reste stable ; l’identifiant de tentative change à chaque exécution. Un événement reçu et une tâche créée ont également des identités distinctes. Conservez leurs relations pour ne pas confondre deux tentatives d’un même travail avec deux travaux légitimes.

Conservez une fiche que quelqu’un d’autre peut poursuivre

Commencez par conserver les enregistrements existants et contenir de nouvelles écritures avec le mécanisme de pause prévu pour ce flux. Une pause n’annule pas ce qui a été exécuté et ne garantit pas d’arrêter les requêtes déjà en cours. Vérifiez la file d’attente et les nouvelles tentatives en attente avant de supposer que personne d’autre n’agira.

Copiez cette fiche dans un registre interne avec un accès approprié. Utilisez des références aux preuves, en évitant de coller des secrets ou des données personnelles dans des documents partagés. Chaque correction doit être ajoutée avec la date, sans supprimer l’observation précédente.

Incident: [référence interne]
Opération souhaitée: [un seul résultat concret]
Fournisseur / compte / environnement: [contexte de la destination]
Opération / événement / tentatives: [IDs et relations]
Version du flux: [version exécutée]
Dernière étape confirmée: [preuve et heure avec fuseau]
État de l’effet: [effet confirmé / absence d’effet confirmée / inconnu]
Preuve de la destination: [référence, requête et limites de visibilité]
Travail encore actif: [requêtes, file d'attente et tentatives en attente]
Règles de nouvelle tentative: [documentation, portée et durée de validité]
Donnée manquante: [preuve nécessaire pour décider]
Prochaine action: [consultation ou récupération délimitée]
Responsable / prochaine révision: [personne et date]
Résultat ultérieur: [nouvelle preuve, sans écraser la précédente]

« Absence d’effet confirmée » nécessite une preuve plus solide qu’une recherche vide : par exemple, un rejet préalable à l’exécution documenté par la destination, après avoir exclu d’autres tentatives susceptibles d’avoir produit l’effet. Si vous ne pouvez pas justifier cet état, conservez « inconnu ».

La clé d’idempotence a des limites

Vérifiez le contrat du fournisseur pour la requête, le compte et l’environnement spécifiques. Une clé qui protège une écriture ne protège pas automatiquement une notification ultérieure ni un autre service. Elle ne peut pas non plus être ajoutée rétroactivement à une requête qui est déjà partie sans elle. La fiche doit lier la documentation applicable, pas seulement dire « nous avons l’idempotence ».

Chez Stripe, les requêtes idempotentes — API v1 réutilisent le résultat sauvegardé de la première exécution, y compris les erreurs 500. Stripe compare les paramètres et peut supprimer les clés après au moins 24 heures ; réutiliser une clé supprimée initie une autre requête. Leur guide d’erreurs avertit des effets possibles après un 500 : changer la clé ou attendre qu’elle expire ne prouve pas qu’il est sûr de répéter une action dont le résultat reste incertain.

Ce délai est propre à Stripe. Pour une autre destination, notez sa propre fenêtre, l’identité qu’elle considère comme répétée et le traitement des requêtes concurrentes. Si une récupération exige de changer les paramètres, traitez-la comme une nouvelle décision, avec révision des effets antérieurs.

Décidez à partir des preuves, étape par étape

Le tableau suivant est un critère opérationnel proposé, non une politique universelle du fournisseur. Il sépare l’enquête de l’autorisation de modifier des données.

Les écritures irréversibles ou à fort impact nécessitent un examen humain de la récupération proposée. Ni une clé ni un bouton vert n’offrent une garantie « exactement une fois » pour tout le parcours.

Vérifiez également qui tentera à nouveau

L’outil d’automatisation, le client API et le fournisseur peuvent chacun avoir leurs propres mécanismes de nouvelle tentative. Dans les webhooks de Stripe, un renvoi manuel n’annule pas les tentatives automatiques ; de plus, les événements peuvent se répéter et arriver dans un ordre différent. Renvoyer un événement n’équivaut pas non plus à répéter de manière idempotente une écriture API : ce sont des mécanismes distincts.

Avant de fermer la fiche, vérifiez l’état actuel de la destination, les étapes en attente et les tentatives qui pourraient arriver ensuite. Définissez qui observera la prochaine exécution. Fermer la fiche n’équivaut pas à résoudre le travail : s’il reste un résultat inconnu, maintenez l’incident ouvert avec un responsable et une date de révision.

Ensuite, vous pouvez vérifier si le flux mérite de rester automatisé selon le critère supprimer, automatiser et déléguer (en anglais). Si le flux est connecté à Frihet, consultez la documentation pour les développeurs et le catalogue d’intégrations pour localiser l’interface correspondante. Conservez cette fiche à côté du flux : la prochaine personne doit pouvoir trouver le dernier état vérifié sans le reconstruire à partir d’un chat.

Sources techniques consultées le 14 septembre 2026. Les fiches, décisions et références DEMO sont des propositions didactiques propres ; ce ne sont pas des instructions pour exécuter des changements sur un service réel.