La crise du timeout : pourquoi le web moderne s'effondre sous le poids de l'IA agentique

Si vous avez récemment utilisé un agent IA avancé, qu’il s’agisse d’O1 d’OpenAI, de Devin ou d’un agent de raisonnement d’entreprise personnalisé, vous l’avez probablement vu. Le rouet qui tourne pendant exactement 60 secondes. Suivi de l’écran vide. Suivi du redoutable : “504 Gateway Timeout”.

Ce n’est pas un bug dans le code. Ce n’est pas un crash de serveur. Il s’agit d’une incompatibilité architecturale fondamentale entre l’Internet que nous avons construit (Web 2.0) et la charge de travail de l’Internet que nous construisons (Agentic AI).

Le Web moderne est confronté à une crise du délai d’attente, et pour y remédier, il faut abattre l’hypothèse fondamentale selon laquelle le Web est « rapide ».

L’ancien contrat : REST et la règle des 30 secondes

Au cours des 20 dernières années, le Web a été optimisé pour une seule chose : la réactivité. Le paradigme dominant est REST (Representational State Transfer). Le contrat entre Client et Serveur est synchrone et simple :

1. Demande : Le client demande des données (par exemple, « Donnez-moi le profil utilisateur »).
2. Processus : Le serveur récupère les données (requête de base de données : ~50 ms).
3. Réponse : Le serveur renvoie les données.

Si l’étape 2 prend plus de 30 secondes (ou 60 secondes sur certains cloud), l’infrastructure panique. L’équilibreur de charge (NGINX, AWS ALB, Cloudflare) suppose que le serveur est mort, « zombifié » ou coincé dans une boucle infinie. Il coupe la connexion pour protéger le système. C’était une fonctionnalité, pas un bug. Cela empêchait les processus bloqués de consommer des threads de RAM et de CPU. Il imposait une discipline de type « échec rapide ».

Entrez dans l’IA agentique : la charge de travail qui brise le temps

Classiquement, les ordinateurs étaient rapides. Si une requête prenait 5 minutes, votre SQL était mauvais. Mais Agentic AI ne consiste pas seulement à « interroger ». C’est « penser ».

Un modèle de raisonnement de classe « O1 » ou un flux de travail agent ne se contente pas de rechercher des données. Il :

1. Décompose une invite en un plan.
2. Navigue sur le Web (grattage de 10 sites).
3. Écrit le code.
4. Exécute le code dans un bac à sable.
5. Analyse les journaux d’erreurs.
6. Refactorise le code.
7. Itère.

Ce processus ne se mesure pas en millisecondes. Elle se mesure en minutes. Parfois des heures. Lorsque vous forcez un processus de réflexion de 5 minutes dans un tube REST de 30 secondes, le tube éclate. Le client (navigateur) attend toujours, mais l’intermédiaire (Load Balancer) a déjà raccroché. L’Agent termine son travail 4 minutes plus tard, mais il n’a personne à qui parler. Le résultat est une tâche perdue, un utilisateur frustré et des crédits de calcul gaspillés.

Le changement architectural : du synchrone à l’événementiel

Pour survivre à l’ère agentique, nous assistons au changement architectural le plus important depuis la mort de SOAP/XML. Nous passons de la Requête/Réponse synchrone à l’Architecture pilotée par les événements (EDA) asynchrone.

Le système “Ticket”

Dans le nouveau paradigme, lorsque vous demandez à une IA de « me construire un site Web », le serveur ne tient pas la ligne.

1. Demande : Le client envoie une invite.
2. Ack : Le serveur répond immédiatement (HTTP 202 accepté) : “Je l’ai reçu. Voici votre ID de ticket #1234. J’y travaille. Au revoir.”
3. La déconnexion : La connexion HTTP se ferme. Le navigateur est libre de faire d’autres choses.
4. Traitement : L’agent travaille en arrière-plan (minutes/heures).
5. Notification : Une fois terminé, le serveur envoie un Signal.

Protocoles de signalisation : comment le navigateur le sait-il ?

Nous assistons à une guerre de protocoles pour gérer l’étape 5 :

• Interrogation : Le navigateur demande toutes les 5 secondes : “Avez-vous déjà terminé ?” (Simple, mais gourmand en ressources).
• Webhooks : Le serveur appelle une URL spécifique une fois terminé (idéal pour le serveur à serveur, mauvais pour les navigateurs).
• Événements envoyés par le serveur (SSE) : Un canal persistant unidirectionnel où le serveur envoie les mises à jour (“Analyse…”, “Écriture de code…”, “Terminé.”). Cela devient la norme pour le streaming de jetons LLM.
• WebSockets : Communication entièrement bidirectionnelle. Exagéré pour la plupart des générations de texte mais nécessaire pour les agents voix/vidéo en temps réel.

L’exécution durable explose

La crise du délai d’attente a alimenté l’essor explosif des plates-formes Durable Execution telles que Temporal, Inngest et Hatchet.

Dans un script Python/Node standard, si le serveur redémarre ou plante alors que l’agent est engagé dans une tâche depuis 4 minutes, ces 4 minutes de travail sont perdues. L’IA est « amnésique ». Les moteurs d’exécution durable introduisent un journal persistant. Ils sauvegardent “l’état” de la fonction à chaque étape.

• Étape 1 : Plan généré (enregistré).
• Étape 2 : Scrape Google (enregistré).
• CRASH (redémarrage du serveur).
• Récupération : le serveur se réveille, constate que l’étape 2 est terminée et reprend immédiatement à l’étape 3.

Ceci est essentiel car l’IA est non déterministe et coûteuse. Vous ne pouvez pas vous permettre de réexécuter un appel d’API à 2,00 $ simplement parce qu’un pod a redémarré. Une exécution durable garantit qu’une fois qu’un agent démarre, il se terminera, c’est garanti.

L’avenir : A2A (agent à agent)

Nous approchons rapidement d’un monde dans lequel la majorité du trafic Internet ne se fait pas de humain à serveur, mais d’agent à agent (A2A). Ces agents ne se soucient pas du « chargement des spinners » ou de la « latence perçue ». Ils se soucient de la fiabilité et de l’exactitude.

Nous assistons à la naissance de nouveaux protocoles (comme MCP - Model Context Protocol) conçus spécifiquement pour permettre aux agents de se découvrir et de se parler sur de longues périodes. L’ère du « Web instantané » touche à sa fin. Le « Web réfléchi » commence. Nous devons juste arrêter de le chronométrer.

Nos sources (4)

• temporal.io Durable Execution
• platform.openai.com OpenAI: Optimizing Latency
• aws.amazon.com Asynchronous Patterns
• inngest.com Event-Driven Systems