Disponible pendant la journée et capable de continuer lorsque l’utilisateur n’est plus disponible : cette continuité exige des retries bornés, de l’idempotence et des alertes visibles.
À retenir avant de commencer
Un agent en production tombe sur des erreurs : limite de débit, délai dépassé, service momentanément indisponible. C’est le fonctionnement normal d’un service en ligne : un cabinet comptable qui lance ses relances de fin de mois croise forcément ces erreurs. La différence entre un agent fiable et un agent fragile se joue dans la reprise.
Trois mécanismes font la différence : la reprise automatique avec attente progressive, des limites claires sur le nombre d’essais, et l’idempotence : répéter la même opération doit conserver le même effet, même si plusieurs tentatives sont nécessaires.
Le 24/7 signifie une chose précise : le service reste disponible pour recevoir et traiter les événements utiles pendant les heures de travail, entre deux sollicitations et après la fin de la journée, lorsque le workflow configuré le prévoit. L’agent agit selon son périmètre. L’objectif de disponibilité, les fenêtres de maintenance et la gestion des pannes doivent être définis pour le service livré.
Les erreurs sont normales
Les fournisseurs de modèles documentent ouvertement leurs erreurs. Anthropic liste les codes d’erreur que tout appel peut renvoyer : délai dépassé, limite de débit atteinte, API momentanément indisponible, erreur de connexion. [59] OpenAI documente les limites de débit par minute et les erreurs associées, avec des recommandations de traitement. [58]
Pour une entreprise, cela signifie : l’agent est conçu pour tomber, et pour se relever. Une erreur temporaire peut se résoudre lors d’une reprise. Une erreur durable, un accès refusé ou une demande invalide nécessite un autre traitement.
La reprise automatique
Le mécanisme de base est le retry : réessayer une opération qui a échoué, avec une attente croissante entre les essais. Microsoft documente ce pattern : si une opération échoue, réessayez après une attente : le backoff exponentiel espace les tentatives. [60]
AWS ajoute une nuance importante : l’ajout de jitter, un aléa dans l’attente, pour éviter que toutes les requêtes se relancent en même temps après une panne. [61]
En clair : première erreur → attendre 1 seconde ; deuxième → 2 secondes ; troisième → 4 secondes. Avec une petite variation aléatoire qui évite les vagues synchrones. Pour un lot de relances, les délais et le nombre d’essais dépendent de la limite du fournisseur et du temps acceptable. Deux tentatives peuvent suffire dans un scénario ; ce n’est pas une règle générale.
Les limites de reprise
La reprise reste toujours bornée. Microsoft recommande de définir des limites de reprise et d’abandonner après un nombre raisonnable de tentatives. [60] Les plateformes d’automatisation appliquent la même règle : n8n permet de configurer le nombre de tentatives avant échec définitif. [62]
Dans l’exemple ci-dessous, le plafond est de trois essais. En production, le plafond et le délai maximal sont définis selon l’opération ; l’échec final devient une alerte visible.
La roue de reprise
Une demande traverse le cycle de reprise en plusieurs étapes. Clique sur les deux scénarios pour les voir.
Interaction-signature
La roue de reprise
Retry borné, idempotence, alerte : le trio qui transforme une panne en non-événement.
Le scénario normal
La demande part, le fournisseur renvoie une erreur de débit, l’agent attend, puis réessaie : la deuxième tentative réussit. L’utilisateur ne voit qu’un léger délai.
Le scénario d’échec
La demande échoue trois fois. L’agent s’arrête proprement et déclenche l’alerte, avec la trace de ce qui s’est passé. Zéro faux succès, zéro boucle infinie.
L’idempotence : éviter les effets en double
Un doublon peut être coûteux : le service accepte une opération, sa réponse se perd et l’agent réessaie. Chez Stripe, les tentatives qui réutilisent la même clé et les mêmes paramètres retrouvent le résultat enregistré pour cette opération. Cette protection dépend de sa prise en charge et de sa durée de conservation ; elle ne signifie pas que le code ne s’exécute qu’une seule fois. [63]
Pour l’agent, chaque opération logique reçoit un identifiant conservé lors des reprises. Une nouvelle relance légitime reçoit un nouvel identifiant : le seul numéro de dossier ne suffit pas. Il faut vérifier que le service destinataire empêche réellement le doublon. Si une messagerie ne fournit pas cette protection et que l’envoi reste incertain, l’agent consulte son statut ou demande une vérification avant de renvoyer.
Continuité, redémarrage et reprise
Un agent disponible en continu doit survivre aux redémarrages et aux pannes d’infrastructure, qu’ils arrivent le matin, l’après-midi ou après la fermeture de l’entreprise. Kubernetes traite les tâches d’agent comme des Jobs : une tâche se relance automatiquement après un échec, avec un nombre maximal de tentatives et une expiration temporelle. [64] Azure propose les Durable Functions pour les processus longs avec reprise intégrée. [65]
Pour une PME qui travaille avec d’autres outils, le principe reste transposable : les traitements doivent pouvoir être relancés sans dupliquer les actions, grâce à l’idempotence et aux traces.
Le résumé utile
Les erreurs sont normales : débit, délai, indisponibilité. L’agent doit savoir les encaisser.
La reprise automatique avec attente progressive, puis des limites claires.
L’idempotence évite de répéter un effet lorsque le service et la reprise la prennent en charge.
Un échec final devient une alerte visible avec sa trace complète.
La continuité se définit ainsi : faire avancer le travail autorisé lorsque l’attention humaine devient indisponible, puis rendre visibles les résultats, les erreurs et les exceptions.