Agents IA en production : queues, retries et idempotence

La prod n’est pas une démo, c’est un environnement hostile

Un agent en démo vit dans un monde merveilleux :

• pas de rate limits,
• pas de timeouts,
• pas de déconnexions,
• pas de pièces jointes corrompues,
• pas d’utilisateurs qui parlent en même temps (ou cliquent 12 fois),
• pas d’auditeurs.

Un agent en prod vit dans un monde normal :

• vos APIs renvoient 429,
• vos bases ont des latences P99,
• vos webhooks arrivent deux fois,
• vos queues livrent “au moins une fois”,
• et vos utilisateurs font des choses… créatives.

Donc on remet les agents à leur place :

Un agent est un logiciel distribué, avec une couche probabiliste.

La fiabilité vient des mêmes fondations que d’habitude :

• timeouts,
• retries,
• idempotence,
• queues,
• et observabilité.

Retries : réessayer aide… jusqu’au moment où ça aggrave

Si vous ne retenez qu’une chose :

• un retry sans stratégie = un DDoS domestique.

AWS Builders’ Library documente très clairement le sujet : timeouts, retries, backoff et jitter sont des primitives de fiabilité, et des retries “mal conçus” peuvent amplifier une panne (thundering herd).¹

Timeout d’abord, retry ensuite

Sans timeout, un retry n’existe pas. Il attend. Il s’accumule. Il vous construit une file d’attente… sans vous prévenir.

AWS Builders’ Library recommande de partir des métriques de latence downstream pour choisir des timeouts raisonnables, puis de calibrer les retries.¹

Backoff + jitter : pas pour faire joli

Le backoff évite de marteler un service déjà en difficulté. Le jitter évite que tous vos workers se recollent à la même milliseconde.

La doc Builders’ Library explique précisément pourquoi l’ajout de jitter compte.¹

Retry seulement si l’opération est “safe to retry”

Et là on arrive au mot que tout le monde prononce… et que peu de systèmes respectent :

idempotence.

Idempotence : le bouton “ne pas faire deux fois”

Imaginez un agent qui :

• crée un ticket,
• envoie un SMS,
• ou déclenche un remboursement.

Il appelle l’API. Le réseau coupe. Il ne sait pas si l’action a réussi. Il retry.

Sans idempotence, vous venez de créer un duplicat.

Stripe a popularisé l’usage d’une clé d’idempotence (Idempotency-Key) sur les requêtes mutantes : envoyer la même clé sur un retry permet de garantir qu’une opération ne se produira pas deux fois (si les paramètres restent identiques).²³

Ce n’est pas “un truc de paiement”. C’est une règle d’or pour toute action irréversible.

Trois patterns d’idempotence (et celui qui marche en entreprise)

Pattern A — Idempotency-Key côté provider
Le provider gère la déduplication (comme Stripe).²³

Avantage : simple.
Limite : pas toujours disponible, et seulement pour cet outil.

Pattern B — Idempotence côté outil (votre API)
Votre endpoint accepte un idempotency_key, et stocke “clé → résultat” (ou “clé → statut”) pour rejouer proprement.

Avantage : vous standardisez pour tous les outils.
Limite : vous devez le faire correctement (atomicité).

Pattern C — Idempotence côté orchestrateur (workflow)
Le workflow conserve un state : “action X exécutée ? résultat ?”. Si retry, il n’exécute pas deux fois, il récupère.

Avantage : cohérent au niveau du process complet.
Limite : vous devez persister l’état (durable execution).

Temporal, via ses concepts d’activités, timeouts et retry policy, se prête naturellement à une approche “workflow durable + activités idempotentes”.⁴

La règle pratique

Pour chaque action outillée, posez une question :

“Si je rejoue cette action 3 fois, est-ce que le monde reste cohérent ?”

Si la réponse est non, vous n’avez pas une action “prod”. Vous avez un accident en attente.

Queues : découpler pour survivre (et scaler sans paniquer)

Les agents font beaucoup d’appels :

• bases,
• CRM,
• OCR,
• LLM,
• notifications,
• webhooks.

Si tout se fait dans une requête synchrone, vous obtenez :

• des timeouts côté client,
• des retries sauvages,
• et une expérience instable.

Le découplage par queue permet :

• d’absorber les pics,
• de lisser la charge,
• de retry proprement,
• et d’isoler les incidents.

At-least-once : acceptez-le, ou souffrez

AWS SQS documente la livraison “at least once” pour les standard queues : un message peut être délivré plus d’une fois.⁵

Ce point est fondamental :

• si votre queue peut dupliquer,
• vos consumers doivent être idempotents.

On boucle : queues → idempotence → retries.

DLQ (dead-letter queues) : là où finissent les cas bizarres

Un agent “prod” doit savoir :

• quand retry,
• quand escalader,
• quand abandonner,
• et quand mettre en quarantaine (DLQ).

La DLQ, c’est votre “bac à sable” pour les exceptions :

• messages impossibles à traiter,
• documents corrompus,
• incohérences métier.

Sans DLQ, ces messages tournent en boucle et vous consument.

Circuit breaker : quand arrêter de taper est la seule décision saine

Les retries sont utiles… jusqu’au moment où vous retry un service en feu.

Le pattern circuit breaker formalise précisément l’idée :

• si une dépendance échoue trop souvent,
• vous “ouvrez” le circuit,
• vous arrêtez d’appeler (temporairement),
• et vous basculez en mode dégradé (cache, fallback, escalade).

Microsoft documente le Circuit Breaker pattern avec ses objectifs : éviter d’épuiser une ressource, éviter de dégrader toute l’application, et donner du temps à la dépendance pour se rétablir.⁷

AWS Builders’ Library décrit aussi ce principe de manière pragmatique : protéger une dépendance en duress en évitant une surcharge soutenue (c’est littéralement l’idée du circuit breaker).⁸

Pourquoi c’est crucial pour les agents ?

Parce qu’un agent “insistant” est dangereux :

• il retry,
• il amplifie,
• il coûte,
• et il ralentit tout.

Un circuit breaker transforme l’insistance en discipline.

Mode dégradé : l’agent qui sait perdre

Mode dégradé ne veut pas dire “répondre n’importe quoi”. Ça veut dire :

• “je ne peux pas vérifier, j’escalade”,
• ou “je réponds avec une information partielle + une action alternative”.

La prod aime les systèmes qui savent perdre proprement.

Bulkhead / isolation : empêcher un agent de prendre tout l’oxygène

Quand une dépendance devient lente, un système naïf fait une chose : il empile.

Résultat : même les requêtes “saines” se retrouvent bloquées derrière des requêtes “malades”.

Le Bulkhead pattern isole les ressources (threads, connexions, pools) pour éviter qu’un sous-système en difficulté ne fasse tomber le reste.⁹

AWS Builders’ Library parle de “dependency isolation” : l’idée d’isoler les dépendances et de contenir la surcharge de concurrence, pour que les fonctionnalités non liées continuent de fonctionner.¹⁰

Pour un agent, ça se traduit par des choix très concrets :

• des pools séparés par type d’outil (CRM vs OCR vs paiement),
• des quotas de concurrence par tenant,
• des limites strictes sur les actions “chères”,
• et parfois des workers dédiés (car tout ne doit pas partager la même file).

Le multi-tenant est le piège classique : un client “bruyant” peut ruiner l’expérience des autres si vous n’isolez pas.

Compensating transactions : quand “annuler” devient une étape du workflow

Certains outils ne sont pas naturellement idempotents. Ou plutôt : l’idempotence ne suffit pas, parce que l’action a déjà eu des effets.

Exemple : vous déclenchez un workflow de remboursement. Il passe une étape, puis échoue sur une autre.

Le système distribué vous rappelle une vérité :

• vous n’avez pas de transaction ACID multi-systèmes,
• vous avez une saga.

Microsoft documente le Compensating Transaction pattern : au lieu de “rollback” classique, vous exécutez des actions de compensation pour revenir à un état cohérent dans un système à cohérence éventuelle.¹¹

En agentic, c’est une arme très utile :

• “ticket créé mais email non envoyé” → compensation : envoyer l’email plus tard
• “paiement déclenché mais confirmation non logguée” → compensation : vérifier l’état puis logguer
• “rendez-vous créé mais CRM non mis à jour” → compensation : réconciliation

Ce pattern vous sort du fantasme “tout ou rien”. Et il vous donne un langage pour décrire des workflows robustes.

Rate limits, quotas, et “pourquoi mon agent est devenu lent”

Quand vous branchez un agent sur des APIs externes, vous héritez de :

• rate limits,
• quotas,
• et parfois de règles d’usage.

En prod, vous devez donc :

• limiter la concurrence,
• mettre des backoffs,
• et prévoir des modes dégradés.

Un agent n’a pas besoin de “réessayer 30 fois”. Il a besoin de :

• reconnaître l’erreur,
• attendre,
• et escalader si besoin.

Observabilité et runbooks : le moment où l’agent devient “ops-friendly”

Une architecture agentique doit être observable. Sinon, au premier incident, tout le monde accuse “le modèle”.

Voir notre article : /blog/agents-ia/observabilite/observabilite-agents-traces-evals-2026.

Le minimum prod :

• correlation_id / trace_id partout,
• logs structurés de tool calls,
• métriques (latence P95, coût, taux d’erreur, taux d’escalade),
• et replay sur des traces représentatives.

Runbook minimal (oui, un runbook)

Quand ça tombe, vous voulez des réponses simples :

1. Est-ce un problème d’outils (429/timeout) ?
2. Est-ce un problème de données (doc illisible) ?
3. Est-ce un problème de modèle (décision incohérente) ?
4. Est-ce un problème de policy (action bloquée) ?
5. Est-ce un problème d’infra (queue saturée) ?

Sans runbook, vous faites de l’astrologie.

Cas d’usage : ce que ça change vraiment

Assurance : instruction de sinistre (le pays des exceptions)

Sans queues et idempotence :

• deux tickets pour le même sinistre,
• deux demandes de pièces,
• et des clients qui rappellent (donc plus de volume).

Avec queues + state + idempotence :

• traitement asynchrone,
• priorisation par SLA,
• et escalade propre sur les cas cassés (DLQ + humain).

Marketing faceless : la factory a besoin d’une supply chain

Le pipeline “idées → scripts → voix → montage → publication” est un workflow. Donc :

• queues pour paralléliser,
• retries pour les APIs (TTS, upload),
• idempotence pour éviter double publication,
• et DLQ pour les contenus bloqués (policy).

SDR / prospection : la conformité exige des garde-fous

Un outbound agent doit :

• dédupliquer les leads,
• respecter les limites d’envoi,
• tracer consentement/opt-out,
• et éviter les boucles.

Le meilleur modèle ne compense pas un mauvais système d’idempotence.

Checklist “prod” : de POC à service fiable

1

Rendez chaque outil idempotent

Idempotency key ou state : chaque action mutante doit être safe-to-retry. Inspirez-vous des pratiques comme Idempotency-Key décrites par Stripe.²³

2

Définissez timeouts + retries avec backoff/jitter

Appliquez une stratégie explicite (pas “on retry 10 fois”). Les principes backoff/jitter sont bien expliqués par AWS Builders’ Library.¹

3

Découplez avec une queue

Vous absorbez les pics, vous lissez, et vous sortez du synchrone. Acceptez l’at-least-once et construisez l’idempotence autour.⁵

4

Ajoutez DLQ + triage

DLQ = exceptions. Exploitez-la comme dataset et comme buffer pour l’humain.

5

Instrumentez et écrivez un runbook

Traces + métriques + replay. Et un runbook simple pour diagnostiquer les incidents sans “blâmer le modèle”.

FAQ

Questions frequentes

Pourquoi mon agent “devient lent” en prod ?+

Souvent : rate limits, retrys non contrôlés, timeouts trop longs, ou outils downstream instables. Le correctif n’est pas “changer de modèle”, c’est “changer d’ingénierie” : budgets, backoff/jitter, queues, et observabilité.

Je dois utiliser Temporal ou Step Functions ?+

Pas forcément, mais vous devez adopter les principes : durable execution, retries, timeouts, et état persistant. Temporal et Step Functions documentent ces concepts et peuvent être de bons choix selon votre infra.⁴⁶

At-least-once : ça veut dire duplicats garantis ?+

Ça veut dire “possibles”. Et donc vous devez rendre vos consumers idempotents. AWS documente explicitement ce comportement pour les standard queues.⁵

Idempotence : seulement pour les paiements ?+

Non. Dès que vous faites une action mutante (ticket, email, SMS, mise à jour CRM), vous devez être safe-to-retry. Stripe est un exemple documenté, mais le principe est universel.²

Sources et references

1. [1]AWS Builders’ Library, “Timeouts, retries, and backoff with jitter”.
2. [2]Stripe, “Designing robust and predictable APIs with idempotency” (Idempotency-Key).
3. [3]Stripe docs, “Advanced error handling” (idempotency keys header).
4. [4]Temporal API docs, “RetryPolicy / Activity timeouts” (concepts).
5. [5]AWS SQS docs, “Standard queues at-least-once delivery”.
6. [6]AWS Step Functions docs, “Handling errors” (Retry/Catch).
7. [7]Microsoft Learn (Azure Architecture Center), “Circuit Breaker pattern”.
8. [8]AWS Builders’ Library, “Resilience lessons from the lunch rush” (circuit breaker discussion).
9. [9]Microsoft Learn (Azure Architecture Center), “Bulkhead pattern”.
10. [10]AWS Builders’ Library, “Using dependency isolation to contain concurrency overload”.
11. [11]Microsoft Learn (Azure Architecture Center), “Compensating Transaction pattern”.