Erreurs et reprises
Une étape échouera. Pas peut-être : le service sera indisponible, le format changera, un champ sera vide, un quota sera atteint.
La question n’est donc pas si, mais ce qui se passe à ce moment-là. Et ça se décide en construisant, pas après le premier incident.
Les trois comportements possibles
Section intitulée « Les trois comportements possibles »Pour chaque étape, choisis lequel s’applique. Le bon choix dépend de ce que fait l’étape.
Arrêter. L’enchaînement s’interrompt et signale. Bon comportement quand la suite n’a aucun sens sans cette étape.
Continuer sans. L’étape échoue, l’enchaînement poursuit avec une valeur par défaut. Bon quand l’étape est un enrichissement facultatif, mauvais quand elle est essentielle et qu’on s’en aperçoit trop tard.
Réessayer. L’enchaînement attend et retente. Bon pour les indisponibilités passagères, dangereux pour les actions qui laissent une trace, voir plus bas.
Le pire choix est l’absence de choix : le comportement par défaut de la plateforme, que tu n’as pas regardé.
Le piège des doublons
Section intitulée « Le piège des doublons »Le problème le plus coûteux du domaine, et il est contre-intuitif.
Une étape peut réussir et signaler une erreur. Le mail est parti, le service a mis trop longtemps à répondre, l’enchaînement considère l’étape en échec, il réessaie, et le mail part une deuxième fois.
Trois protections, par ordre de solidité.
L’identifiant unique. Avant d’agir, vérifie si l’action a déjà été faite pour cet élément. Une colonne « traité le » dans le tableau source, une recherche de la référence avant création. C’est la protection la plus fiable.
Le marqueur immédiat. Écris « en cours » avant l’action, pas après. Une reprise verra le marqueur et s’abstiendra.
Pas de reprise automatique sur les actions à effet externe. Envoi, paiement, création de document chez un tiers. Sur ces étapes, en cas d’échec, on signale et un humain regarde.
Une automatisation qui envoie deux fois la même facture à un client abîme la relation davantage qu’une automatisation qui n’a rien envoyé.
Idempotent, en une phrase
Section intitulée « Idempotent, en une phrase »Le mot qu’on rencontrera dans les documentations, et qui vaut la peine d’être compris.
Une opération est idempotente si l’exécuter deux fois produit le même résultat que l’exécuter une fois.
« Mettre le statut à traité » est idempotent : le refaire ne change rien. « Ajouter une ligne » ne l’est pas : le refaire crée un doublon.
Chaque fois que tu peux formuler une action de façon idempotente, fais-le. Ça rend les reprises sans danger, et ça supprime la moitié des problèmes de cette fiche.
La branche « à vérifier »
Section intitulée « La branche « à vérifier » »La structure qui règle l’essentiel, et qu’on oublie de construire.
Prévois, dans chaque enchaînement, une sortie de secours : une ligne ajoutée dans un tableau « à traiter à la main », avec la date, la donnée d’origine et la raison de l’échec.
Trois avantages.
Rien n’est perdu. Le cas qui a échoué existe quelque part, au lieu de disparaître dans un journal que personne ne lit.
Quelqu’un peut le traiter. La tâche redevient manuelle pour ce cas-là, ce qui est acceptable.
Et le tableau devient un indicateur. S’il se remplit, l’enchaînement a un problème, et tu le vois sans rien surveiller d’autre.
Les limites de la plateforme
Section intitulée « Les limites de la plateforme »Trois plafonds à connaître avant de les découvrir en production.
La durée d’exécution. Un enchaînement trop long est coupé en cours de route, souvent au milieu d’une boucle. Résultat : la moitié des éléments traités, l’autre non, sans trace claire.
Le quota d’exécutions. Atteint, l’enchaînement ne tourne plus du tout. C’est un mode de panne silencieux, et une des premières choses à surveiller.
Les limites du service branché. Beaucoup de services limitent le nombre d’appels par minute. Au-delà, ils refusent, et l’enchaînement voit un échec technique là où il n’y a qu’un excès de vitesse.
Pour la première et la troisième, la parade est la même : traite par petits paquets, avec une pause, plutôt que tout d’un coup.
Ce qu’il faut décider avant de construire
Section intitulée « Ce qu’il faut décider avant de construire »Reprends ta cartographie du module 1, colonne « que se passe-t-il si ça rate ».
Pour chaque étape : arrêter, continuer sans, ou réessayer. Et pour les étapes à effet externe : identifiant unique ou marqueur.
Cinq minutes de décisions écrites, et tu n’auras pas à improviser le jour où ça tombe, ce qui est toujours le mauvais moment.
Vérifie ta compréhension
Question : ton enchaînement envoie un mail de confirmation puis met à jour le statut de la commande. Le mail part, la mise à jour échoue à cause d’une indisponibilité. La reprise automatique se déclenche. Que se passe-t-il ?
Réponse : le client reçoit une seconde confirmation, parce que la reprise rejoue l’enchaînement depuis le début. Deux corrections. Inverse l’ordre : mets d’abord le statut à jour, envoie ensuite, de sorte qu’une reprise voie le statut et s’abstienne. Et retire la reprise automatique sur l’étape d’envoi : en cas d’échec, elle part dans la branche « à vérifier », où un humain regarde. C’est le cas type qui justifie de décider du comportement d’erreur à la construction.
Fiche suivante : tester avant de brancher.
Une formationBaxIA