Cloudflare a fusionné Workers AI et AI Gateway en un unique control plane. Qui gère des agents en production dispose désormais d’observabilité, facturation et routage dynamique sur GPU managées et providers externes depuis une seule interface, avec bindings unifiés et routage model-first.

Pourquoi ça te concerne. Si tu déploies des agents en production, le vrai problème c’est gérer qui appelle quoi, combien coûte chaque appel, et ce qui se passe quand un provider s’effondre, plutôt que de choisir quel modèle utiliser. Jusqu’à présent, ceux qui utilisaient Cloudflare devaient traiter l’inférence managée (Workers AI) et la passerelle de routage (AI Gateway) comme deux systèmes distincts : deux logs, deux compteurs, deux configurations.

Maintenant le routage décide au runtime selon le modèle demandé et l’état des providers. Si un endpoint est lent ou a une limite de débit active, la requête passe par une autre route sans que l’agent le sache. Pour qui a des agents qui tournent toute la nuit, ça signifie moins de pipelines personnalisés et moins de temps à chasser les logs dispersés.

Cette démarche s’inscrit dans le fil que nous avons suivi cette semaine : le 5 août, Cloudflare avait composé le modèle zero trust pour déployer les agents en production, et le 7 août avait fermé la pile infrastucturelle avec navigateur stateless, MCP sans état et paiements. Le control plane unifié est la pièce qui tient ensemble gouvernance et routage : la dernière couche de cette même architecture.

Si tu veux l’essayer. La documentation du control plane unifié est sur le blog de Cloudflare. Avant de configurer les bindings unifiés sur tes agents, ça vaut le coup de vérifier la disponibilité réelle des modèles que tu utilises sur les GPU managées de Cloudflare, car le catalogue ne correspond pas à celui des providers externes.

En détail

C’était comment avant.

Workers AI et AI Gateway étaient deux produits avec deux objectifs. Workers AI faisait tourner des modèles open-weight sur les GPU de Cloudflare à la périphérie : inférence managée, prix au token, rien à orchestrer. AI Gateway était un proxy en face des providers externes (OpenAI, Anthropic, Google) pour ajouter caching, rate limiting, logging et fallback. Qui voulait les deux devait les gérer manuellement : deux tableaux de bord, deux logiques de routage, deux systèmes de facturation.

Ce qui change.

L’unification ramène tout sous un seul control plane. Les concepts clés pour qui ne développe pas :

• Bindings unifiés. Dans Cloudflare Workers, un binding est la façon dont le code se connecte à un service. Désormais un seul binding donne accès aussi bien aux modèles managés sur les GPU de Cloudflare qu’aux providers externes. Plus de deux configurations séparées.
• Routage model-first. Au lieu de spécifier un endpoint et un provider, tu demandes un modèle par nom. Le système comprend tout seul où l’héberger : sur sa propre infrastructure, sur un provider externe, ou sur les deux avec fallback.
• Observabilité et facturation au même endroit. Logs, métriques et facturation convergent en une seule vue. Pour qui a des agents en production, ça résout le problème pratique de comprendre combien coûte vraiment chaque appel et où ça casse.

Comment ça s’insère dans le tableau.

Cloudflare construit une pile complète pour les agents en production : runtime, navigateur stateless, MCP sans état, paiements autonomes, zero trust. Le control plane unifié est la couche de gouvernance qui tient les autres ensemble. Si le runtime décide où tourne l’agent et le protocole décide comment il parle avec les outils, le control plane décide quel modèle répond et combien ça coûte.

Limites et questions ouvertes.

Le catalogue de Workers AI (modèles managés sur les GPU de Cloudflare) reste plus petit que celui des providers externes. Si un agent a besoin d’un frontier model spécifique, le routage model-first l’aiguille sur le provider externe, mais l’avantage du single-pane-of-glass se réduit à la gouvernance, sans réduction des coûts d’inférence. Le post n’entre pas dans les détails sur comment le routage dynamique évalue latence et disponibilité en temps réel, ni sur le caractère transparent du fallback entre providers pour l’agent ou s’il nécessite de la gestion d’état.

Comme pour toutes les annonces de cette semaine, la preuve sur le terrain dira si l’unification est réelle dans la facturation et les logs ou si c’est une couche cosmétique sur deux systèmes encore distincts.