Reprises après erreur

Une API distante répond trop lentement ou renvoie une erreur temporaire. Une nouvelle tentative peut réussir quelques secondes plus tard. Mais si tous les clients recommencent immédiatement et sans limite, ils ajoutent de la charge au système déjà en difficulté.

Une reprise après erreur, ou retry, répète une opération après un échec jugé transitoire. Une bonne politique définit quand réessayer, combien de fois, après quel délai et jusqu’à quelle échéance. Elle vérifie aussi que la répétition ne crée pas un second effet métier.

AWS recommande un backoff exponentiel, du jitter et un nombre maximal de tentatives. Le backoff espace progressivement les reprises. Le jitter ajoute une variation aléatoire pour éviter que de nombreux clients recommencent au même instant. [S1]

Décider si l’erreur est rejouable

Situation	Décision de départ
Limitation temporaire avec délai indiqué	Attendre le délai du fournisseur, puis reprendre dans le budget
Indisponibilité ou erreur serveur transitoire	Reprendre avec backoff, jitter et limite
Coupure réseau ou timeout avec résultat inconnu	Reprendre seulement si l’opération est idempotente ou protégée
Paramètre invalide, droit absent ou configuration incorrecte	Échouer sans reprise automatique
Dépendance durablement indisponible	Arrêter les tentatives et ouvrir le chemin de traitement prévu
Échéance métier dépassée	Ne plus reprendre, même si l’erreur paraît transitoire

Les codes d’erreur aident, mais le contrat du fournisseur fait foi. Une même famille de codes peut contenir des cas différents. Documentez les erreurs explicitement rejouables, celles qui exigent une correction et celles dont le résultat reste inconnu.

AWS distingue les erreurs transitoires, comme une limitation, une perte temporaire de réseau ou une indisponibilité, des erreurs qui ne disparaîtront pas par répétition. Une reprise sur une erreur permanente consomme des ressources sans changer le résultat. [S1] [S2]

Les quatre bornes d’une politique

Un timeout explicite

Le timeout limite le temps attendu pour une connexion ou une réponse. Une valeur trop haute conserve inutilement des ressources. Une valeur trop basse crée des échecs artificiels et davantage de reprises. Mesurez la latence réelle et testez les cas lents avant de choisir la valeur. [S3]

Un budget total

Fixez une échéance ou une durée maximale pour l’ensemble de l’opération. Chaque tentative consomme une partie de ce budget. Si le temps restant ne permet plus une tentative utile, arrêtez avant de la lancer. [S1]

Un nombre maximal de tentatives

Une limite explicite évite une boucle infinie et un arriéré qui continue de croître. Comptez toutes les tentatives, y compris celles déjà réalisées par un SDK, une file, une passerelle ou un fournisseur. [S1]

Un délai variable

Augmentez progressivement l’attente entre les tentatives, plafonnez-la et ajoutez du jitter. Sans variation, des clients qui échouent ensemble risquent de recommencer ensemble et de produire des pics artificiels. [S1]

Construire la politique

1. Nommer l’opération. Identifiez son effet, son importance et son échéance métier.
2. Vérifier l’idempotence. Ajoutez une clé ou une déduplication avant de rejouer une action non naturellement idempotente.
3. Classer les erreurs. Maintenez une liste explicite des erreurs transitoires, permanentes et ambiguës.
4. Choisir une seule couche. Évitez que le client, le SDK, la file et le workflow multiplient chacun leurs propres tentatives. [S1]
5. Définir le timeout. Séparez si nécessaire le délai de connexion du délai de réponse. [S3]
6. Fixer les limites. Nombre de tentatives, budget total, délai minimal, plafond du backoff et règle de jitter.
7. Respecter le fournisseur. Utilisez son délai de reprise lorsqu’il en fournit un et ne dépassez pas ses quotas.
8. Prévoir la sortie. Après la dernière tentative, conservez l’état, expliquez l’échec et dirigez le travail vers une reprise différée, une file d’échec ou une correction.
9. Instrumenter chaque tentative. Enregistrez la cause, le délai choisi, le numéro de tentative, le temps restant et le résultat.

Un circuit breaker peut arrêter temporairement les appels vers une dépendance qui échoue de façon répétée. Il répond à un autre besoin que le backoff : éviter des appels dont l’échec est déjà probable. [S2] [S3]

Éviter la tempête de reprises

Les reprises peuvent amplifier la panne lorsque plusieurs couches se multiplient. Trois tentatives dans le client, puis trois dans une file et trois dans un service aval peuvent produire bien plus de trois appels réels.

Pour garder le contrôle :

• désignez la couche propriétaire de la reprise ;
• exposez les tentatives déjà consommées dans le contexte de l’opération ;
• plafonnez le débit des reprises séparément du trafic normal ;
• suspendez les reprises lorsque la dépendance signale une surcharge ;
• mesurez l’effet des tentatives sur le taux de succès et la charge ;
• arrêtez lorsque le budget ou l’échéance est dépassé.

Le bénéfice d’une reprise se mesure par les opérations récupérées, pas par le nombre de tentatives exécutées.

Tester les échecs réels

Injectez des scénarios contrôlés :

• une erreur transitoire suivie d’un succès ;
• une erreur permanente qui ne doit pas être rejouée ;
• un timeout après un effet déjà appliqué ;
• une réponse de limitation avec un délai ;
• plusieurs clients qui échouent au même instant ;
• une dépendance indisponible plus longtemps que le budget ;
• un SDK qui possède déjà sa propre politique ;
• une file qui redélivre après l’arrêt du workflow.

Vérifiez le nombre total d’appels, l’écart entre les tentatives, la dispersion apportée par le jitter, l’absence de double effet, la durée finale et l’état transmis après abandon.

Limites à garder visibles

• Une reprise peut réussir tout en dépassant l’échéance métier.
• Un timeout ne prouve pas que l’opération distante n’a pas été appliquée.
• Un backoff réduit la pression, mais ne répare pas une configuration ou une autorisation incorrecte.
• Un nombre maximal trop élevé peut créer un arriéré durable.
• Des valeurs par défaut de SDK peuvent changer ou ne pas convenir au besoin.
• Une file d’échec sans propriétaire ni procédure de reprise déplace seulement le problème.

Réessayez uniquement une erreur qui peut disparaître et une opération qui supporte la répétition. Bornez le temps, les tentatives et le débit. Après la limite, rendez l’échec observable et passez au chemin prévu au lieu de continuer sans fin.