02 : le serveur impose le rythme (Retry-After honoré) #9

Partie de l'épic #6. Bloqué par #1.

🎯 À construire

Quand un 429 arrive avec un en-tête Retry-After (secondes) ou Retry-After-Ms (millisecondes), la retentative attend exactement le délai demandé par le serveur au lieu du backoff exponentiel : le serveur impose le rythme. Un 429 sans en-tête retombe sur la politique par défaut. Visible de l'extérieur via Client#evaluate : le délai demandé au stub de sommeil est celui de l'en-tête.

✅ Critères d'acceptation

• Un 429 avec Retry-After: 2 provoque une attente de 2 secondes avant la retentative
• Un 429 avec Retry-After-Ms: 250 provoque une attente de 0,25 seconde
• Un en-tête Retry-After non numérique est ignoré sans planter : retombée sur le backoff par défaut
• Un 429 sans en-tête conserve le backoff exponentiel du ticket 01

🔗 Bloqué par

• #1 — la boucle de retentative et la politique de délai par défaut y naissent ; Retry-After n'est que l'une de leurs branches

🚧 Ce que ce ticket ne fait pas

• Retenter les erreurs réseau (elles n'ont pas d'en-tête) — ticket 03

📚 Références

• Épic : retry-client: retentatives automatiques dans le client HTTP #6
• Spec : docs/plans/retry-client/spec.md — ## Décisions d'implémentation, ## Décisions de test
• Glossaire : LEXIQUE.md