Cloudflare a ajouté une version bêta de recherche sur le Web API à AI Gateway, offrant aux agents et aux applications d'IA un moyen de rechercher sur Internet en direct via la même couche de passerelle déjà utilisée pour le trafic de modèle. La fonctionnalité est nouvelle, de faible superficie et toujours en version bêta, mais elle annonce un changement plus important : la recherche devient un outil d'IA facturable, et non seulement une intégration côté application.
La société a annoncé la version bêta le 2 octobre 2026. Lors du lancement, Cloudflare répertorie Ceramic.ai, Exa et Linkup comme fournisseurs de recherche sélectionnables. Les développeurs peuvent envoyer des requêtes de recherche via AI Gateway, faire apparaître ces requêtes dans les journaux de passerelle et les payer via des crédits AI Gateway au prix indiqué API de chaque fournisseur. Cloudflare indique qu'il n'ajoute pas de balisage supplémentaire. Les équipes peuvent également utiliser les informations d'identification du fournisseur Bring-your-own-key lorsque cela est pris en charge.
Cette combinaison est importante car elle rejoint trois préoccupations qui sont souvent traitées séparément : le routage des outils, l'observabilité et la facturation. Pour les développeurs qui créent des agents de récupération augmentée, des assistants de recherche, des robots de support ou des flux de vente automatisés, la question n'est plus seulement de savoir quel modèle a généré la réponse. Il s'agit également de savoir quel fournisseur de recherche a été appelé, sous quels identifiants, à quel prix et si les dépenses qui en résultent peuvent être liées à un client, une équipe, un projet ou une clé API.
Ce qui a changé
Jusqu'à récemment, de nombreuses discussions sur AI Gateway étaient centrées sur les appels de modèles : points de terminaison compatibles OpenAI, basculement du fournisseur, comptabilité des jetons, latence, mise en cache et journaux de requêtes. La version bêta de Web Search API de Cloudflare ajoute un type différent de transaction à ce plan de contrôle. Un appel de recherche peut prendre en charge une réponse de modèle, mais il ne s'agit pas en soi d'une demande d'inférence de modèle. Il comporte des tarifs différents, une sémantique de fournisseur différente et des questions de gouvernance différentes.
Le lancement de Cloudflare fait du fournisseur de recherche un choix de passerelle configurable plutôt qu'une dépendance d'application codée en dur. Les développeurs peuvent choisir parmi les fournisseurs répertoriés, acheminer l'appel via AI Gateway et le voir aux côtés d'autres trafics IA. Si le client utilise la facturation gérée par Cloudflare, les frais sont imputés aux crédits AI Gateway. Si le client apporte une clé de fournisseur, la passerelle peut toujours se trouver sur le chemin pour le routage et la journalisation.
Il s'agit d'une limite de produit significative. La recherche n'est plus une aide invisible cachée derrière un framework d'agents. Cela devient un événement de premier ordre dans les enregistrements de passerelle. Pour une passerelle multimodèle API pour les équipes, c'est la différence entre "l'agent était cher" et "ce workflow a dépensé de l'argent en jetons de modèle, en contexte mis en cache et en six appels de recherche en direct".
Pourquoi les équipes de passerelle devraient s'en soucier
Le public immédiat est constitué des développeurs qui utilisent déjà Cloudflare AI Gateway, en particulier ceux qui créent des applications qui ont besoin de nouvelles informations. La recherche peut aider à ancrer les réponses dans des données réelles, mais elle introduit également une autre unité de coût et une autre source de dépendance envers le fournisseur. Si un agent d'assistance recherche de la documentation, un assistant de conformité vérifie les pages de politique en vigueur ou un workflow de surveillance du marché analyse le Web à plusieurs reprises, les frais de recherche peuvent devenir importants sur le plan opérationnel, même lorsque l'utilisation des jetons semble modeste.
C'est le même modèle qui apparaît désormais dans l'infrastructure des agents. Les outils shell hébergés, l'utilisation du navigateur, les agents de révision de code et les services de récupération se transforment tous en opérations mesurées autour du modèle. Les jetons comptent toujours, mais ils ne constituent plus l’intégralité du grand livre. Une passerelle utilisable doit expliquer les dépenses tout au long du flux de travail, et pas seulement jusqu'à l'achèvement final.
Pour les entreprises, cela affecte la rétrofacturation et la marge. Un revendeur ou une équipe interne de plateforme devra peut-être décider si les dépenses de recherche sont répercutées au prix catalogue du fournisseur, majorées, regroupées dans un forfait ou bloquées par défaut. Une équipe financière peut souhaiter savoir si la facture d’un client a augmenté en raison d’invites plus volumineuses, d’un plus grand nombre de jetons de sortie, du comportement du cache ou du volume de recherche sur le Web. Les équipes produit peuvent souhaiter des rapports d'utilisation qui distinguent l'enrichissement en arrière-plan de la génération visible par l'utilisateur.
Cela crée une ouverture pratique pour une facturation unifiée de l'IA API. Le modèle de facturation doit couvrir les jetons, les jetons mis en cache et les appels d’outils sans les aplatir en une seule ligne vague « utilisation de l’IA ». Sinon, les clients ne peuvent pas déterminer quelle partie d'un système d'agent génère des coûts.
Les conséquences pour les développeurs
Les développeurs devront considérer la recherche sur le Web comme faisant partie de la conception API de l'application, et pas seulement comme une amélioration rapide. Le moteur de recherche doit être visible dans la configuration. Les informations d’identification doivent être limitées. Les journaux doivent conserver suffisamment d'informations pour déboguer le comportement des fournisseurs et les dépenses des clients sans conserver de données sensibles inutiles. La gestion des erreurs doit distinguer un échec de modèle d'un échec de fournisseur de recherche, car l'expérience utilisateur et la stratégie de nouvelle tentative peuvent être différentes.
Il y a aussi une question de routage. Ceramic.ai, Exa et Linkup ne sont pas interchangeables dans tous les cas d'utilisation. La qualité de la recherche, la couverture, la latence, le format des résultats et la tarification peuvent tous affecter le comportement du modèle en aval. Une passerelle capable d'acheminer entre les fournisseurs offre de la flexibilité aux développeurs, mais elle nécessite également une politique : quel fournisseur est approuvé pour quel locataire, quelles régions ou classes de données sont autorisées et si les informations d'identification BYOK sont requises pour certains clients.
Pour Model Gate et produits similaires, la connexion pratique est directe. Si les clients créent des services d'agent au-dessus d'une passerelle, ils finiront par demander que l'utilisation de la recherche apparaisse à côté de l'utilisation du modèle dans la même surface d'analyse. Les API partenaires peuvent également devoir exposer les enregistrements d'appels de recherche afin que les plateformes en aval puissent facturer leurs propres clients avec précision. Traiter la recherche comme un outil facturable de premier ordre s'intégrerait naturellement à côté de la gestion des APIclés, des contrôles d'équipe et de l'analyse de l'utilisation.
Cela ne signifie pas que chaque passerelle doit copier la liste exacte des fournisseurs de Cloudflare. Le point le plus important est structurel : une fois que la recherche en direct est disponible via une passerelle, la mesure des outils fait partie du contrat de la passerelle. Une IA d'équipe API contrôlant les dépenses qui ignore les appels d'outils sous-estimera le coût réel de l'agent.
Ce qui reste incertain
Le statut bêta laisse plusieurs questions ouvertes. Cloudflare a nommé les fournisseurs de recherche initiaux et décrit l'approche de facturation, mais les équipes de production devront toujours évaluer les performances spécifiques du fournisseur, la qualité des résultats, les engagements en matière de traitement des données et les limites opérationnelles. La documentation publique confirme la version bêta et la tarification de base, mais elle ne détermine pas si un fournisseur est meilleur pour toutes les charges de travail ni comment la fonctionnalité évoluera avant la disponibilité générale.
On ne sait pas non plus à quelle vitesse les développeurs standardiseront la recherche via une passerelle plutôt que les intégrations directes des fournisseurs. Les équipes disposant de piles de récupération existantes peuvent conserver la recherche au sein de leur propre infrastructure. D'autres peuvent préférer le routage par passerelle car il réduit le travail d'intégration et centralise les journaux. La décision dépendra probablement autant des besoins en matière de gouvernance que de la pertinence de la recherche.
Pourtant, la direction est assez claire. Les passerelles IA absorbent davantage de temps d’exécution de l’agent autour du modèle. La version bêta de Web Search API de Cloudflare n'est pas seulement une fonctionnalité de recherche ; c'est un autre signe que le plan de contrôle des applications d'IA doit désormais mesurer, acheminer et expliquer les outils avec autant de soin qu'il gère les modèles.