Dans un système de production qui consomme des API d'intelligence artificielle, le réglage des timeouts est trop souvent traité comme un détail secondaire. C'est pourtant un choix d'architecture critique. Une mauvaise politique de timeouts peut multiplier par dix la facture cloud, saturer vos workers et déclencher des cascades d'erreurs 5xx. Avec les tarifs 2026 affichés par les principaux fournisseurs — GPT-4.1 à 8,00 $/MTok en sortie, Claude Sonnet 4.5 à 15,00 $/MTok, Gemini 2.5 Flash à 2,50 $/MTok et DeepSeek V3.2 à 0,42 $/MTok — un timeout mal calibré peut représenter plusieurs milliers de dollars de tokens gaspillés chaque mois et un taux d'erreur utilisateur inacceptable.

Comparaison des coûts réels pour 10 millions de tokens de sortie par mois

Sur un volume mensuel de 10 millions de tokens générés, l'écart entre le modèle le plus cher et le moins cher atteint 145,80 $ — soit un facteur 35,7×. Chaque requête abandonnée à mi-chemin gaspille des tokens pré-facturés par le fournisseur, bloque un slot worker côté serveur et dégrade la métrique de conversion côté produit. D'où l'importance d'une configuration de timeouts rigoureuse, hiérarchisée et mesurée.

Pourquoi distinguer connect timeout et read timeout

Une requête HTTP vers une API LLM traverse plusieurs phases distinctes, chacune avec sa propre latence et son propre risque de blocage :

  1. Résolution DNS : 5-30 ms en moyenne, peut monter à 200-800 ms sur des resolvers récursifs lents ou en environnement Kubernetes fraîchement démarré.
  2. Établissement de la connexion TCP (three-way handshake) : 10-80 ms en réseau sain, plus de 2 000 ms en cas de routage défaillant ou de congestion.
  3. Handshake TLS 1.3 : 30-150 ms, davantage si l'inspection MITM d'entreprise intercepte la chaîne.
  4. Envoi de la requête (headers + body) : proportionnel à la taille du payload — 50-150 ms pour 200 Ko, 500-1 500 ms pour 5 Mo.
  5. Attente de l'inférence : variable, de 80 ms pour un modèle flash sur un prompt court à 25-60 s pour un Claude Sonnet 4.5 sur 200 000 tokens d'entrée.
  6. Réception des tokens : phase la plus longue et la plus sensible, surtout en streaming.

Appliquer le même timeout à toutes ces phases est une faute de conception fréquente. Un connect timeout de 30 000 ms est inutilement long : si la connexion TCP ne s'établit pas en 2 000 ms, elle ne s'établira pas. À l'inverse, un read timeout de 2 000 ms coupera systématiquement les requêtes de streaming légitimes au-delà de quelques centaines de tokens générés.

Stratégie hiérarchique à 3 niveaux

Après avoir audité plus de 40 déploiements de chatbots, d'agents RAG et d'outils d'analyse en production, je recommande une configuration à trois niveaux distincts, plus un timeout de pool :

Niveau 1 — connect_timeout (résolution DNS + TCP + TLS)

Valeur recommandée : 2 000 ms, extensible à 3 500 ms en environnement d'entreprise avec inspection MITM. Cette phase est purement réseau. Si elle échoue, réessayer immédiatement sur un autre endpoint via un load balancer ou lever une CapacityError explicite.

Niveau 2 — write_timeout (envoi du payload)

Valeur recommandée : 10 000 ms. Couvre l'envoi des headers HTTP et du corps de la requête sérialisé en JSON. Pour un system prompt de 50 Ko et un contexte de 500 Ko, comptez 200-400 ms ; pour 5 Mo, 800-1 500 ms.

Niveau 3 — read_timeout (réception de la réponse)

Valeur recommandée : 45 000 à 120 000 ms

Ressources connexes