Les applications d’intelligence artificielle qui reposent sur des agents nécessitent une conception différente de celle des interfaces web traditionnelles, non pas nécessairement en raison d’un nouveau protocole, mais parce que le modèle de trafic lui-même est différent. Une seule conversation peut s’étendre sur des dizaines de requêtes indépendantes, tandis que l’agent continue à fonctionner à une vitesse automatisée, sans les périodes d’attente humaines qui atténuent la pression sur l’infrastructure.
L’article, publié dans The New Stack dans le cadre d’un contenu sponsorisé par Oracle, propose de réutiliser d’anciens principes des microservices pour construire des interfaces compatibles avec OpenAI et capables de monter en charge, en s’appuyant, pour le modèle de preuve de concept, sur Oracle AI Database Free.
Pourquoi le trafic des agents diffère-t-il de celui des applications web ?
Le navigateur peut conserver la session sur un seul serveur grâce à la persistance du routage et aux périodes de réflexion de l’utilisateur. L’agent, lui, peut exécuter 40 cycles consécutifs, chaque cycle arrivant sous la forme d’une requête HTTP indépendante dont le protocole ne garantit pas l’acheminement vers le même serveur. Si l’historique de la conversation reste dans la mémoire d’un processus local, la requête suivante peut perdre le contexte dès qu’elle est transférée vers une autre instance du service.
Les appels d’outils peuvent également se ramifier de manière imprévisible : une seule requête peut n’appeler aucun service supplémentaire ou en appeler plusieurs, notamment des opérations de recherche vectorielle pouvant durer 400 millisecondes. Les agents accroissent la pression par leurs propres politiques de nouvelle tentative, tandis que le trafic arrive par vagues continues, davantage déterminées par les limites de concurrence et le matériel que par le comportement de l’utilisateur.
Le problème silencieux de la conception initiale
L’auteur présente un prototype qui conserve l’historique de la conversation dans un dictionnaire au sein du processus, utilise un seul groupe pour contrôler la concurrence et exécute les appels d’outils dans le chemin même de la requête. Cette conception fonctionne lors des tests, mais elle dépend en pratique du fait que tous les rôles de la conversation accèdent au même appareil.
Lorsqu’on répartit 200 conversations, chacune comportant quatre rôles, en alternance entre plusieurs instances, les serveurs peuvent continuer à renvoyer des codes HTTP 200, tandis que le modèle répond sans disposer du bon historique de conversation. Le dysfonctionnement n’apparaît donc pas nécessairement comme une panne technique manifeste : il se manifeste plutôt par un comportement incorrect du point de vue de l’utilisateur.
Trois principes pour remédier au dysfonctionnement
- Sortir l’état du processus : l’état de la conversation et l’historique des appels d’outils sont stockés dans un magasin partagé, de sorte que n’importe quelle instance puisse traiter n’importe quel rôle d’une conversation.
- Isolation ou barrières : les différents chemins et dépendances, comme la complétion de la conversation et l’exécution des outils, reçoivent des limites de concurrence et des délais d’expiration indépendants afin d’empêcher la défaillance de l’un d’eux d’épuiser l’ensemble du système.
- Points de terminaison intelligents et pipelines simples : le protocole compatible avec OpenAI reste une couche de transport stable, tandis que la logique de routage, la gestion du budget et de la mémoire ainsi que les politiques d’appel des outils sont placées au-dessus.
Qu’est-ce qui change concrètement ?
Le modèle de preuve de concept divise le système en une passerelle qui communique via le protocole OpenAI et ne conserve pas l’état, un service de mémoire qui détient l’historique des conversations et les données d’audit, un service d’outils indépendant doté de limites de concurrence et de délais d’expiration spécifiques, ainsi qu’une base Oracle AI Database Free utilisée comme magasin partagé. La conception utilise des signaux de contrôle indépendants, comme 24 emplacements pour la concurrence des conversations et 8 pour les appels d’outils.
Cette division permet une mise à l’échelle horizontale sans dépendre du système de fichiers local ni de la persistance du routage des requêtes. Le client officiel d’OpenAI peut également utiliser l’interface sans modification du SDK, dès lors que le protocole est compatible.
La conclusion éditoriale est que la capacité des agents d’intelligence artificielle à monter en charge ne se résout pas uniquement en augmentant le nombre d’instances. Le véritable test consiste à préserver l’état, à contrôler les dépendances lentes et à empêcher les nouvelles tentatives ou les appels d’outils de transformer les vagues d’agents en défaillance en cascade. Comme il s’agit d’un contenu sponsorisé par Oracle, l’article présente une approche architecturale et un modèle de preuve de concept, et non une comparaison indépendante entre bases de données ni une garantie de performances déterminées dans tous les environnements.