Agent Router : un plan de contrôle Kubernetes pour le trafic IA, porté par Envoy Gateway

Le problème : chaque fournisseur impose son propre contrat

Une équipe applicative qui consomme plusieurs modèles finit avec un client par fournisseur, un format d'authentification par fournisseur et aucune vue consolidée de qui consomme quoi. Agent Router prend le problème par l'autre bout : le README annonce une API unique compatible OpenAI pour tous les modèles et outils, des fournisseurs hébergés à l'inférence auto-hébergée et aux serveurs MCP. Le public visé est double. Les équipes applicatives y gagnent un point d'entrée stable. Les équipes plateforme y gagnent un endroit unique où vivent les identifiants, le routage, les quotas, le basculement et l'attribution d'usage. La phrase du README, « Agent Router controls. Envoy carries. », résume le partage : le projet porte la logique de contrôle, Envoy transporte le trafic. Cette séparation a une conséquence pratique. Vous n'ajoutez pas un nouveau moteur proxy à votre pile, vous ajoutez une couche de configuration devant un proxy que votre organisation exploite peut-être déjà.

Deux niveaux de passerelle, deux responsabilités distinctes

Le README décrit un modèle à deux niveaux. La passerelle de niveau un sert de point d'entrée centralisé : authentification, routage de premier niveau, limitation de débit globale. La passerelle de niveau deux gère le trafic entrant vers un cluster d'inférence auto-hébergé, avec un contrôle plus fin sur l'accès aux modèles et la prise en charge d'un endpoint picker pour l'optimisation de l'inférence. Ce découpage n'est pas cosmétique. Il permet de placer les règles globales, celles qui concernent tous les consommateurs, à un endroit, et les règles propres à un cluster de modèles à un autre. L'endpoint picker est la partie la plus intéressante pour qui exploite du GPU : le choix du réplica qui répond à une requête d'inférence a un effet direct sur la latence, et le README le rattache explicitement au niveau deux. En revanche, le README ne détaille pas l'algorithme de sélection ni les métriques exposées par ce composant. C'est une zone où la documentation publique reste à compléter.

Les ressources Kubernetes qui portent la configuration

Trois noms de CRD apparaissent dans le README : AIGatewayRoute, AIServiceBackend et BackendSecurityPolicy, tous dans le groupe d'API aigateway.envoyproxy.io. Leur stabilité est le point central de l'annonce de renommage. Le projet s'appelait Envoy AI Gateway et devient Agent Router, un projet de l'Agentic AI Foundation, mais le README insiste : mêmes CRD, même groupe d'API, même CLI aigw, même namespace envoy-ai-gateway-system, mêmes images conteneur, mêmes charts Helm, même chemin de module Go. Seuls le dépôt et le site changent, avec des redirections depuis les anciennes adresses. Pour une équipe qui a déjà des manifestes en production, cette continuité vaut plus qu'un changement de nom réussi. Elle signifie que la migration se limite à l'endroit d'où vous tirez vos artefacts, pas à ce que vous déployez. Je note tout de même que le README énonce cette continuité sans montrer de diff ni de test de compatibilité. La promesse est crédible au vu du contenu décrit, mais elle reste une promesse documentaire.

Démarrer : aigw run en local, Envoy Gateway en cluster

Le chemin le plus court tient en une commande, telle que donnée dans le README : OPENAI_API_KEY=sk-your-key aigw run. Le routeur écoute alors sur http://localhost:1975/v1, et n'importe quel client compatible OpenAI peut pointer dessus. C'est un mode autonome, utile pour valider un format de requête ou tester un changement de modèle sans toucher au cluster. Le second chemin passe par Kubernetes et Envoy Gateway, et le README renvoie au guide Getting Started pour le déploiement. Le guide CLI couvre l'installation et l'auto-configuration des fournisseurs. Un détail à ne pas manquer : la variable OPENAI_API_KEY est passée dans l'environnement de la commande, pas dans un fichier de configuration. Pour un poste de développement c'est commode. Pour un déploiement partagé, la gestion des identifiants passe par les ressources du cluster, et le README ne détaille pas ce passage dans l'extrait fourni. Les fournisseurs listés dans le tableau du README sont OpenAI, Azure OpenAI, Google Gemini, Vertex AI, AWS Bedrock, Mistral, Cohere, Groq, Together AI, DeepInfra, DeepSeek, Hunyuan, SambaNova, Grok, Anthropic et le Tetrate Agent Router Service.

Ce que le dépôt ne dit pas encore

Le README est un document d'accueil, pas un manuel d'exploitation, et plusieurs questions restent ouvertes après lecture. La première concerne le comportement en cas de panne d'un fournisseur : le basculement est cité parmi les responsabilités de la plateforme, mais aucune règle de retry, de timeout ou de dégradation n'est décrite dans l'extrait. La deuxième concerne les quotas : ils sont mentionnés comme centralisés, sans indication sur la granularité, par clé, par équipe ou par modèle. La troisième concerne la compatibilité entre l'API exposée et les API réelles des fournisseurs. Une API compatible OpenAI en façade ne garantit pas que chaque paramètre propriétaire d'un fournisseur traverse correctement la couche de traduction. C'est le genre d'écart qui n'apparaît qu'en production, sur des fonctionnalités comme les appels d'outils ou les formats de réponse structurés. Rien dans le matériel fourni ne permet de trancher. Si vous dépendez de ces fonctionnalités, testez-les avant de généraliser le déploiement.

Quand Agent Router n'est pas le bon outil

Le projet suppose Kubernetes et Envoy Gateway. Si votre besoin se limite à un processus local qui relaie des requêtes vers un fournisseur unique, la commande aigw run fonctionne, mais vous payez alors la complexité d'un projet conçu pour un plan de contrôle distribué. Un proxy inverse écrit en quelques dizaines de lignes, ou une bibliothèque cliente qui gère elle-même le retry, couvre ce cas avec moins de surface. De même, une équipe qui n'exploite pas Envoy et ne souhaite pas l'exploiter trouvera ici une dépendance structurante : le README est explicite, Agent Router contrôle, Envoy transporte. Adopter l'un sans l'autre n'a pas de sens. Enfin, le projet ne se présente pas comme un moteur d'inférence ni comme un serveur de modèles. Il route vers de l'inférence auto-hébergée, il ne la fournit pas. Confondre les deux mène à une déception prévisible.

Alternatives : la différence se joue sur le plan de contrôle

La comparaison la plus directe se fait avec un proxy inverse générique configuré à la main devant les API des fournisseurs. La différence n'est pas dans le transport, les deux parlent HTTP, mais dans l'endroit où vit la politique. Avec un proxy générique, le routage, l'authentification et la limitation de débit s'expriment dans la configuration du proxy, souvent en dehors de Kubernetes, et l'attribution d'usage se reconstruit après coup à partir des journaux. Agent Router place ces décisions dans des ressources Kubernetes du groupe aigateway.envoyproxy.io, ce qui les rend versionnables, relisibles et auditables comme n'importe quel autre objet du cluster. Une seconde différence tient à l'API exposée : un proxy générique transmet la requête telle quelle, alors qu'Agent Router promet une façade compatible OpenAI devant des fournisseurs dont les API diffèrent. Ce choix simplifie la vie des clients et déplace la complexité vers la couche de traduction. C'est un pari raisonnable, à condition d'accepter que les fonctionnalités les plus spécifiques à un fournisseur soient plus difficiles à atteindre.

Maintenance, licence et coût de mise à jour

Le projet est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions de licence et d'avis. Le README ne signale aucune clause additionnelle ni changement de licence lors du renommage, et indique explicitement que la licence Apache 2.0 reste la même. Sur le rythme, les versions publiées listées vont de v1.0.0-rc1 et v1.0.0 en juin 2026 à v1.1.0 en août 2026, avec un dernier push en septembre 2026. Le projet n'est pas archivé. Le coût de mise à jour dépend surtout d'Envoy Gateway : Agent Router est bâti dessus, donc suivre l'un implique de suivre l'autre. Le README ne donne pas de matrice de compatibilité entre versions d'Agent Router et versions d'Envoy Gateway dans l'extrait fourni. C'est le premier document à réclamer avant de planifier une montée de version, parce qu'une incompatibilité à ce niveau se manifeste au déploiement, pas à la compilation.

Conclusion éditoriale

Agent Router convient aux équipes plateforme qui exploitent déjà Envoy Gateway et veulent centraliser identifiants, quotas et attribution d'usage derrière une API compatible OpenAI, sans réécrire leurs manifestes puisque les CRD et le groupe d'API aigateway.envoyproxy.io restent inchangés. Il ne convient pas à qui cherche un simple proxy local sans Kubernetes ni Envoy : la commande aigw run dépanne sur un poste, mais le modèle à deux niveaux de passerelle et les politiques de sécurité supposent une exploitation de cluster. Avant de vous engager, vérifiez trois choses dans le dépôt lui-même : la compatibilité de la version d'Envoy Gateway requise avec votre installation, le contenu réel des BackendSecurityPolicy pour le fournisseur que vous visez, et la procédure de mise à jour entre v1.0.0 et v1.1.0 telle que documentée dans les notes de version.

Sources officielles

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. theagentrouter/agent-router on GitHub