Face à une API IA en panne, la pire réaction d'une application est d'insister. La bonne : couper l'attente vite, relancer peu, avoir un plan B. Le disjoncteur, ou circuit breaker, vient ensuite, si le trafic le justifie.
Le cas : un service lent, pas mort
Un article publié sur Medium part d'un assistant de santé à plusieurs agents IA, construit avec LangGraph (un outil pour orchestrer des agents) et AWS Bedrock (l'accès d'Amazon à des modèles IA), avec Amazon Nova Pro comme modèle principal. Le scénario n'est pas la panne franche. C'est plus vicieux : le service ralentit.
Chaque requête attend 10 secondes, relance, attend encore, relance une troisième fois. Selon l'auteur, 100 utilisateurs simultanés peuvent ainsi produire 300 appels vers un service déjà en difficulté. Le mécanisme censé rendre l'application fiable l'achève.
Ça, on le voit souvent, et pas seulement avec l'IA : un ERP qui interroge un transporteur, un site qui appelle un service de paiement.
Étape 1 : raccourcir l'attente, borner les relances
Premier réglage, le timeout, le délai au-delà duquel on abandonne. Dans la documentation de Laravel, le client HTTP attend 30 secondes par défaut, 10 pour établir la connexion. Devant un écran, 30 secondes, l'utilisateur est parti. On raccourcit selon ce que l'écran peut supporter.
Deuxième réglage, les relances. Avec Http::retry(3, 100), Laravel fait trois essais, 100 millisecondes entre chaque. On peut aussi ne relancer que pour certaines erreurs, une connexion qui échoue par exemple. Tout cela est natif, donc sans coût de licence.
AWS rappelle que les retries sont "égoïstes" : ils consomment de la capacité chez le fournisseur. Sa recommandation : un délai exponentiel plafonné avec jitter (un petit décalage aléatoire, pour que tout le monde ne relance pas à la même seconde), et des relances à un seul niveau de l'application.
Côté fournisseur d'IA, la documentation d'OpenAI demande de respecter l'en-tête Retry-After (le temps d'attente indiqué par le serveur) quand il existe, et de ne jamais relancer une erreur de quota ou de facturation. Elle prévient aussi que ses SDK, les kits fournis aux développeurs, relancent déjà certains 429 (trop de requêtes) et 503 (service indisponible) : si vous ajoutez vos propres relances, vous les multipliez. Nous avons détaillé le cas du quota dans cet article sur le palier gratuit. Pour les tâches de fond, voyez les files d'attente Laravel en production.
Étape 2 : le disjoncteur, et ceux qui n'en veulent pas
Le principe vient de l'électricité. Un circuit breaker a trois états. Fermé : les appels passent, les échecs sont comptés. Ouvert : l'appel échoue aussitôt, sans attendre. Semi-ouvert : après un délai de repos, un seul appel d'essai décide si l'on referme.
L'article cite 5 échecs en 60 secondes comme seuil, en précisant que ces chiffres sont illustratifs. Nous n'avons pu lire que l'extrait : prenez-les pour un ordre de grandeur, pas pour une règle.
Martin Fowler ajoute deux garde-fous. Toutes les erreurs ne doivent pas ouvrir le circuit. Et chaque changement d'état se journalise, avec une alerte à l'ouverture. Microsoft distingue bien les rôles : le retry parie que l'appel finira par passer, le disjoncteur évite un appel probablement perdu. Il déconseille un disjoncteur unique pour plusieurs fournisseurs indépendants, et rappelle qu'un timeout trop long le rend peu efficace.
Tout le monde n'est pas convaincu. AWS préfère limiter localement les relances (un token bucket, un stock de relances autorisées qui se recharge) et juge le disjoncteur difficile à tester et lent à récupérer. Microsoft lui-même le dit peu utile quand de simples retries suffisent.
Étape 3 : prévoir un repli qui reste honnête
Disjoncteur ouvert, que voit l'utilisateur ? Microsoft cite quelques options : une valeur par défaut, une réponse en cache, une fonction dégradée, une opération alternative.
L'article de Medium met en garde contre le modèle de secours pris au hasard. S'il ne respecte pas les mêmes contraintes que le principal, mieux vaut un message franc, ou un renvoi vers une personne.
Prenons une PME de négoce dont l'assistant rédige des réponses aux clients. IA indisponible : la demande part en file d'attente et le client est prévenu qu'une réponse arrive. On n'invente surtout pas un tarif.
Dernier piège. Relancer une génération de texte donne une autre réponse, sans gravité. Relancer une réservation ou une écriture peut créer un doublon. AWS déconseille de relancer ces appels sans idempotence, c'est-à-dire sans garantie que rejouer l'action ne la duplique pas.
API IA en panne : ce qu'une PME règle dans Laravel
Pour un faible volume, timeouts courts et retries bornés suffisent souvent, sans bibliothèque. Un disjoncteur devient utile quand le trafic est assez fort pour que les relances aggravent la panne.
Laravel ne documente aucun disjoncteur natif. Un paquet de routage pour LLM existe (v0.1.5, 64 installations, licence MIT) : il propose un basculement entre fournisseurs, mais il est trop jeune pour que nous le recommandions les yeux fermés, et nous n'avons pas vérifié son code.
Ce que nous n'avons pas trouvé : un retour d'usage mesuré sous Laravel, ni le coût de mise en place d'un disjoncteur dans une source officielle.
Les pannes se testent avant qu'elles arrivent : Http::fake() avec failedConnection() ou sequence() les simule, et les événements du client HTTP alimentent les logs. Nous accompagnons des entreprises de Provence, jusqu'autour de Fos-sur-Mer, sur ces réglages, dans le cadre de nos projets Laravel et IA.
- Raccourcissez les timeouts : 30 secondes par défaut, c'est trop long pour un utilisateur.
- Bornez les retries avec un délai croissant et du jitter, et ne relancez jamais une erreur de quota ou d'authentification.
- Comptez les relances des SDK pour ne pas les multiplier.
- Prévoyez un repli honnête (file d'attente, message, humain), jamais une réponse inventée.
- Réservez le circuit breaker aux trafics importants, et journalisez ses changements d'état.
Questions fréquentes
Un circuit breaker est-il fourni avec Laravel ?
Non, la documentation de Laravel décrit les timeouts et les relances du client HTTP, mais aucun disjoncteur natif. Il faut l'écrire ou passer par un paquet, et les paquets de ce type sont encore très jeunes.
Combien de fois relancer un appel à une API IA ?
La pratique courante est de rester à quelques essais, trois au maximum dans l'exemple de la documentation Laravel, avec un délai qui s'allonge. On ne relance jamais une erreur de quota ou de facturation.
Peut-on relancer une action qui crée un rendez-vous ou une écriture ?
Seulement si l'opération est idempotente, c'est-à-dire si la rejouer ne crée pas de doublon. Sinon, on évite de relancer automatiquement.
Comment tester qu'une panne est bien gérée ?
Laravel permet de simuler un service qui ne répond pas, avec Http::fake() et failedConnection(), ou une série de réponses avec sequence(). On vérifie ainsi le comportement avant la vraie panne.
