Cloudflare lance Web Search API via AI Gateway, transformant la recherche en infrastructure

Cloudflare lance Web Search API via AI Gateway avec trois fournisseurs de recherche, intégrant la récupération web en direct au même plan de contrôle que l’inférence des modèles. La bêta prend en charge Ceramic.ai, Exa et Linkup via une seule interface. Les développeurs peuvent l’appeler depuis un backend, un Cloudflare Worker ou un workflow d’agent.

Le changement important n’est pas l’existence d’un endpoint de recherche web supplémentaire. Cloudflare place la recherche aux côtés du routage des modèles, des journaux, des contrôles de sécurité, des identifiants et de la gestion de l’usage. Ce positionnement transforme la récupération d’une intégration isolée en infrastructure IA gérée.

Cette initiative crée également une concurrence nette. Les développeurs peuvent utiliser des outils de recherche intégrés aux plateformes de modèles, se connecter directement à des entreprises spécialisées dans la recherche, ou placer la récupération derrière une passerelle indépendante. Cloudflare parie que les équipes privilégieront la troisième option, en particulier lorsqu’une application utilise plusieurs modèles et fournisseurs de recherche.

Le lancement de Web Search API via AI Gateway déplace le point de contrôle

Cloudflare offre désormais aux développeurs une route gérée unique vers trois services de recherche indépendants, sans lier la récupération à un modèle de langage particulier.

L’entreprise a annoncé la bêta le 2 octobre 2026. Selon l’annonce de lancement, les requêtes peuvent utiliser Ceramic.ai, Exa ou Linkup. Ceramic.ai devient le choix par défaut lorsqu’une application ne précise pas de fournisseur.

Chaque réponse suit une structure commune comprenant un titre, une URL et une description pour chaque résultat. Les métadonnées peuvent également inclure la requête, un identifiant de requête et des informations de latence. Cette cohérence compte, car les différences propres aux fournisseurs se retrouvent souvent dans le code des applications.

Les développeurs peuvent accéder au service via un endpoint REST standard. Les utilisateurs de Cloudflare Workers peuvent à la place appeler env.AI.websearch() via une liaison AI. Les deux méthodes envoient la requête via un AI Gateway existant.

La route REST accepte une requête, le nom du fournisseur, une limite de résultats et une configuration de passerelle. La liaison Workers expose des contrôles équivalents via JavaScript ou TypeScript. Le guide d’implémentation de Cloudflare indique qu’une requête peut contenir jusqu’à 1 024 caractères, tandis qu’une requête renvoie jusqu’à 10 résultats.

Cette limite montre à quoi le produit est conçu pour servir. Il s’agit d’une couche de récupération de contexte pour les appels de modèles, et non d’un remplacement d’une page conventionnelle de résultats de recherche. Une application rassemble un ensemble ciblé de sources et place les extraits pertinents dans le contexte de travail d’un modèle.

Le service prend en charge deux voies d’identifiants. Les équipes peuvent dépenser leurs crédits AI Gateway, ou stocker une clé de fournisseur et la sélectionner via un alias bring-your-own-key. Cloudflare récupère cet identifiant au sein de la passerelle plutôt que d’exiger que l’application le transmette avec chaque requête de recherche.

Cette architecture offre aux équipes une frontière commune pour l’authentification. Elle réduit aussi le nombre d’identifiants externes répartis entre les applications, les systèmes de déploiement et les machines des développeurs. Un jeton d’application compromis reste risqué, mais la prolifération des identifiants devient plus facile à contenir.

Cloudflare indique que les requêtes de recherche web apparaissent dans les journaux d’observabilité habituels d’AI Gateway. Les équipes peuvent examiner l’activité des requêtes aux côtés du trafic des modèles plutôt que d’exploiter une pile de surveillance distincte. Les politiques d’accès peuvent également déterminer quelles applications atteignent certains fournisseurs de recherche.

Cette intégration crée la tension centrale de l’article. Une API de recherche directe offre moins d’intermédiaires, tandis qu’une passerelle apporte davantage de contrôle opérationnel. Cloudflare doit démontrer que la couche de contrôle économise plus de complexité qu’elle n’en introduit.

La recherche devient une composante de la pile AI Gateway

La pression concurrentielle s’exerce sur les plateformes de modèles et les fournisseurs de recherche spécialisés, car Cloudflare sépare la récupération en direct du modèle qui la consomme.

De nombreux modèles proposent déjà une recherche web native. La documentation existante de la passerelle Cloudflare répertorie les outils de recherche pris en charge d’OpenAI, Anthropic, xAI et Alibaba. Ces outils restent liés à leurs interfaces fournisseurs et à leurs capacités de modèles respectives.

La recherche native peut être pratique lorsqu’une équipe s’engage auprès d’une seule famille de modèles. Le modèle décide quand rechercher, le fournisseur formate les éléments de preuve et le même service produit la réponse. Cette voie peut réduire le travail d’orchestration pour un assistant simple.

Elle devient moins pratique lorsqu’une application change de modèles. Les schémas d’outils, les modèles pris en charge, les formats de citations, la disponibilité régionale et les conditions de conservation peuvent différer. Une équipe peut devoir créer des implémentations distinctes pour chaque fournisseur, même lorsque chaque voie effectue la même tâche de récupération de base.

Cloudflare Web Search API modifie cette frontière. La recherche devient une étape contrôlée par l’application avec un format de réponse commun. Les éléments récupérés peuvent alimenter un modèle disponible via Workers AI, un modèle routé via AI Gateway ou un autre service d’inférence.

Cette séparation importe pour les agents, qui effectuent souvent plusieurs recherches avant de produire une réponse. Un agent de recherche peut commencer par une requête large, identifier une entreprise ou un document, puis lancer des recherches de suivi plus ciblées. Ces appels nécessitent une journalisation et des autorisations prévisibles, car ils peuvent être plus nombreux que la requête finale au modèle.

L’approche par passerelle prend également en charge une sélection explicite du fournisseur. Un développeur peut router une charge de travail vers Ceramic.ai et une autre vers Exa ou Linkup. L’application n’a pas besoin de modifier son intégration globale chaque fois que le fournisseur sélectionné change.

Cloudflare décrit chaque fournisseur comme répondant à un profil de récupération différent. Sa documentation sur les fournisseurs indique que Ceramic.ai exploite un index indépendant dépassant 40 milliards de pages. Il renvoie de longues descriptions pouvant fournir un contexte substantiel à un agent.

Exa combine des méthodes par mots-clés avec une recherche fondée sur des embeddings, qui compare des représentations sémantiques plutôt que de s’appuyer uniquement sur les termes correspondants. Cloudflare le configure pour renvoyer des passages pertinents pour la requête depuis les pages récupérées. Ce format convient aux prompts nécessitant des éléments de preuve concis.

Linkup renvoie des extraits sourcés via un mode de recherche rapide sans générer de réponse synthétisée. Cela maintient la récupération séparée du raisonnement. L’application peut décider quel modèle analyse les résultats et comment les citations apparaissent.

Ces distinctions donnent à Cloudflare une raison de prendre en charge plusieurs fournisseurs. La qualité de recherche n’est pas unidimensionnelle. La fraîcheur, la couverture de l’index, la pertinence sémantique, la latence, la longueur des extraits et la sélection des sources peuvent chacune compter davantage selon les tâches.

Cette même diversité complique également le produit. Une réponse normalisée ne rend pas les fournisseurs équivalents. Les développeurs doivent toujours mener des évaluations pour mesurer si chaque service récupère les bons éléments de preuve pour leur domaine.

Cloudflare exerce donc une pression sur les entreprises de recherche dans deux directions. Elle leur offre une distribution via une plateforme de développement établie, mais les présente également comme des options interchangeables derrière une interface commune. Cela peut déplacer une partie de la relation client vers la passerelle.

Les fournisseurs de modèles font face à un défi différent. Leurs outils de recherche intégrés peuvent optimiser ensemble la récupération et la génération. L’approche de Cloudflare soutient que de nombreuses équipes valoriseront davantage la portabilité, le choix indépendant du fournisseur et une politique centralisée qu’une expérience étroitement couplée.

Vercel poursuit une stratégie connexe. Son AI Gateway a récemment ajouté des outils de search and fetch qui fonctionnent avec les modèles prenant en charge les appels d’outils. La proximité de ces lancements suggère que les passerelles s’étendent au-delà du routage des modèles pour devenir des couches complètes d’outils pour agents.

Il ne s’agit pas d’une compétition visant à savoir qui a relié en premier un modèle à la recherche. Il s’agit d’une compétition pour déterminer quelle plateforme gouverne cette connexion. Le gagnant contrôle les identifiants, les journaux, les décisions de routage, les paramètres de conservation et la surface d’intégration du développeur.

Le mécanisme est simple, mais le changement architectural est plus profond

Cloudflare transforme la recherche en primitive de récupération réutilisable que les applications peuvent invoquer avant, pendant ou entre les appels de modèles.

Un workflow de base commence par une question d’utilisateur. L’application envoie cette question, ou une requête dérivée, à Web Search API. Elle reçoit des résultats structurés et place des descriptions sélectionnées dans un prompt de modèle.

Un agent peut également décider quand invoquer le service. Le développeur définit un outil de fonction web_search, c’est-à-dire une opération appelable décrite au modèle. Lorsque le modèle demande cet outil, le code de l’application exécute la recherche et renvoie les résultats.

Le modèle reçoit ensuite un second appel d’inférence contenant la question initiale et les éléments de preuve récupérés. Ce modèle est souvent appelé génération augmentée par outils, car le modèle rassemble des informations externes pendant l’exécution d’une tâche. Il diffère d’une approche reposant uniquement sur les connaissances stockées dans les paramètres du modèle.

Cloudflare indique que des outils serveur natifs arriveront plus tard. Ces outils intégreraient davantage d’orchestration à AI Gateway lui-même. Pour l’instant, les développeurs doivent implémenter la boucle qui reçoit un appel d’outil, exécute une recherche et renvoie le résultat au modèle.

Cette distinction est importante. La bêta actuelle offre un service de recherche et des contrôles communs de passerelle. Elle ne fournit pas encore un agent de recherche entièrement géré qui détermine les requêtes, filtre les éléments de preuve, résout les sources contradictoires et compose une réponse citée.

Cette conception autonome présente néanmoins des avantages utiles. Les équipes peuvent inspecter les résultats bruts avant qu’ils n’atteignent le modèle. Elles peuvent rejeter les domaines bloqués, exiger des sources approuvées, supprimer les pages en double ou limiter la récupération aux documents respectant une politique interne de confiance.

Un assistant de support fournit un exemple pratique. Lorsqu’un client pose une question sur une API récemment modifiée, l’agent peut rechercher la documentation actuelle au lieu de répondre à partir d’un instantané d’entraînement plus ancien. L’application peut conserver les URL récupérées pour examen.

Un agent logiciel peut utiliser le même modèle lors de la résolution d’erreurs. Il peut rechercher une nouvelle note de version, une option de configuration modifiée ou un avertissement de compatibilité actuel. Les résultats de recherche deviennent des éléments de preuve, tandis que le modèle reste responsable de leur interprétation.

Les produits de recherche et de surveillance peuvent lancer plusieurs requêtes ciblées. Une requête peut localiser une annonce officielle, une autre peut trouver de la documentation, et une troisième peut vérifier des reportages indépendants. Un bon workflow compare ces sources plutôt que d’accepter le premier résultat.

Les travailleurs du savoir font face à un problème similaire dans les contenus privés. Un système doit combiner des évolutions externes avec des notes, des documents et un contexte organisationnel établi. Ce processus ressemble au knowledge blending, où de nouveaux éléments de preuve ne deviennent utiles qu’après avoir été reliés à des informations auxquelles un utilisateur fait déjà confiance.

La passerelle peut journaliser les appels de récupération impliqués dans de tels workflows. Cela donne aux opérateurs un historique plus clair lorsqu’une réponse échoue. Ils peuvent se demander si la requête était mauvaise, si le fournisseur a manqué une page, si l’extrait manquait de contexte ou si le modèle a mal interprété de bons éléments de preuve.

Cette séparation permet une meilleure évaluation. La qualité de récupération et la qualité des réponses peuvent être mesurées indépendamment. Sans cette séparation, une réponse de faible qualité révèle peu si la recherche ou la génération est à l’origine du problème.

Elle permet également des solutions de repli par étapes. Une application peut interroger un fournisseur, examiner le nombre de résultats, puis réessayer avec un autre fournisseur lorsque la couverture est insuffisante. Cloudflare n’a pas affirmé que la bêta prend automatiquement ce type de décisions de qualité ; les développeurs doivent donc les concevoir et les tester.

Il en va de même pour la mise en cache. Certaines questions liées à l’actualité deviennent rapidement obsolètes, tandis que les requêtes portant sur une documentation stable peuvent réutiliser des résultats. Une application responsable a besoin de politiques d’expiration, de mises à jour des sources et de gestion des requêtes répétées.

La prise en charge existante de la recherche par gateway de Cloudflare proxyfie déjà les outils natifs de plusieurs fournisseurs de modèles. La nouvelle API ajoute une voie différente : un appel de récupération indépendant des fournisseurs et de ces outils natifs.

Les équipes disposent donc désormais de deux modèles de recherche au sein de la plateforme Cloudflare au sens large. Elles peuvent préserver le comportement des outils natifs d’un fournisseur de modèles, ou utiliser la nouvelle API autonome. Le bon choix dépend de la portabilité, du contrôle et du degré d’orchestration qu’une équipe souhaite prendre en charge.

Le mécanisme ressemble à un ajout modeste d’API. Sur le plan architectural, il confère à la recherche le même statut qu’à l’inférence, au stockage, aux files d’attente et aux autres services composables. Les agents peuvent traiter les informations web actuelles comme une infrastructure plutôt que comme une fonctionnalité spéciale intégrée à un seul modèle.

AI Gateway Web Search relève les enjeux de l’observabilité

Les journaux centralisés sont particulièrement précieux lorsque les équipes peuvent relier une affirmation générée aux étapes exactes de récupération qui l’étayent.

Cloudflare présente AI Gateway comme le plan de contrôle des applications de modèles. Il offre déjà une visibilité sur les requêtes, des contrôles de sécurité et une gestion de l’usage. L’ajout de la récupération étend cette observabilité à une étape qui détermine souvent si une réponse est à jour.

Un modèle peut raisonner avec soin tout en produisant une réponse erronée lorsque ses preuves sont incomplètes. La recherche peut renvoyer une page obsolète, un article copié ou un résultat qui partage le bon vocabulaire mais traite d’un autre sujet. Les opérateurs ont besoin de visibilité avant de pouvoir distinguer ces défaillances.

Les identifiants de requête et les métadonnées de latence constituent un point de départ. Ils peuvent aider à corréler des recherches lentes ou infructueuses à une exécution d’agent particulière. Les journaux peuvent également révéler si une application émet des requêtes inutiles ou récupère à répétition les mêmes pages.

Cependant, la journalisation du trafic de recherche soulève ses propres questions de gouvernance. Les requêtes des utilisateurs peuvent révéler des plans confidentiels, des noms de clients, des incidents de sécurité, des préoccupations médicales ou des détails de projets internes. Un gateway centralisé doit donc clairement définir les limites d’accès et les règles de conservation.

Cloudflare indique que les trois partenaires de lancement prennent en charge la conservation zéro des données pour les requêtes acheminées via ce service. La conservation zéro des données signifie qu’un fournisseur ne conserve pas les données de requête après traitement, dans le cadre de l’accord applicable. Elle ne répond pas automatiquement à toutes les questions de confidentialité concernant l’ensemble de l’application.

Le développeur contrôle toujours ce qui entre dans la requête. Cloudflare exploite toujours le gateway et ses journaux. Le fournisseur final de modèles reçoit tout contexte récupéré que l’application lui envoie. Chaque étape exige une politique de données délibérée.

La prise en charge des clés fournies par le client nécessite également une configuration soignée. La documentation de Cloudflare indique qu’un alias explicite entraîne l’échec de la requête lorsque cette clé n’est pas disponible. Sans alias explicite, le gateway peut utiliser une clé par défaut configurée ou des crédits gateway disponibles.

Ce comportement est pratique, mais les équipes doivent décider si ce repli est acceptable. Une charge de travail réglementée peut exiger un accord spécifique avec un fournisseur. Un basculement silencieux vers une autre voie commerciale peut entrer en conflit avec les contrôles internes, même lorsque le résultat technique est valide.

L’observabilité doit aussi conserver suffisamment de détails pour l’évaluation sans stocker une quantité excessive de données sensibles. Les seuls volumes et latences ne peuvent pas expliquer les échecs de pertinence. Les requêtes complètes et les extraits de résultats offrent davantage de valeur de diagnostic, mais augmentent aussi l’exposition.

Le juste équilibre différera selon l’application. Un assistant public d’actualité peut journaliser plus de détails de récupération qu’un système interne de recherche juridique. L’avantage de Cloudflare dépend de la capacité des administrateurs à exprimer ces différences au moyen de politiques compréhensibles.

Le contrôle opérationnel inclut également la prévention des abus. Un agent pris dans une boucle d’outils peut émettre de nombreuses recherches répétées. Les limites de débit, les budgets de requêtes et les autorisations par application sont importants, car la récupération peut représenter une part significative de l’activité d’un agent.

Les journaux centralisés aident à identifier ce comportement. Ils ne l’empêchent pas à eux seuls. Les équipes ont toujours besoin d’un nombre maximal d’appels d’outils, de délais d’expiration, de politiques de domaines et de conditions d’arrêt claires dans leur framework d’agents.

Le même principe s’applique à la sécurité. Les résultats de recherche contiennent du texte non fiable, et les pages web peuvent inclure des instructions visant à manipuler un agent. Une injection de prompt survient lorsqu’un contenu externe tente de remplacer les règles prévues par une application.

Une réponse de recherche normalisée ne neutralise pas les contenus malveillants. Le modèle peut toujours interpréter un extrait hostile comme une instruction. Les développeurs doivent étiqueter les éléments récupérés comme des preuves, restreindre les actions disponibles après la récupération et éviter de placer des secrets dans des contextes où les outils sont activés.

La nouvelle API facilite la centralisation de ces pratiques, mais ne peut pas les remplacer. Cloudflare vend un meilleur point de contrôle. Les clients restent responsables du comportement de l’agent qui opère derrière ce point.

Les règles des crawlers créent une promesse utile et un test difficile

Cloudflare associe ce lancement à un crawling responsable, mais la conformité ne garantit pas des résultats de recherche complets, exacts ou représentatifs.

L’entreprise exige des fournisseurs participants qu’ils identifient leurs crawlers, respectent robots.txt et incluent des liens vers les contenus récupérés. Elle indique également que les crawlers des fournisseurs doivent satisfaire aux exigences de Cloudflare applicables aux bots vérifiés.

Un bot vérifié est un service automatisé dont Cloudflare a confirmé l’identité. Cette vérification donne aux opérateurs de sites un signal plus clair lorsqu’ils décident d’autoriser ou de bloquer un crawler. Elle réduit l’ambiguïté par rapport à un trafic non identifié prétendant représenter une entreprise de recherche.

Cloudflare présente cela comme une norme pour une relation plus équitable entre les services de recherche IA et les éditeurs. Cette politique donne aux créateurs davantage de visibilité sur les personnes qui accèdent à leurs pages. Les liens vers les sources permettent également aux utilisateurs d’examiner les documents sous-jacents.

Ces engagements distinguent ce lancement du scraping opaque. Ils sont particulièrement pertinents, car les éditeurs s’interrogent de plus en plus sur la manière dont les systèmes d’IA acquièrent, résument et commercialisent le contenu web. Les fournisseurs de recherche ont besoin d’accès, tandis que les propriétaires de sites veulent un contrôle applicable.

La contrepartie est qu’un crawling respectueux peut réduire la couverture. Certains sites bloquent l’accès automatisé, limitent certains bots ou placent des contenus derrière une authentification. Les résultats de recherche ne peuvent refléter que les pages qu’un fournisseur a indexées et qu’il reste autorisé à utiliser.

Les trois fournisseurs peuvent donc renvoyer des visions différentes du web. Ils exploitent des index, des systèmes de classement, des calendriers de rafraîchissement et des processus de génération d’extraits distincts. Un schéma d’API partagé masque ces détails d’implémentation sans en supprimer les effets.

L’attribution des sources présente un autre défi. Renvoyer une URL est nécessaire, mais cela ne prouve pas qu’une réponse générée représente fidèlement la page. Les applications doivent préserver le lien entre chaque affirmation et le résultat qui l’étaye.

Le modèle final peut combiner plusieurs extraits en une affirmation qu’aucune source ne soutient explicitement. Il peut également négliger les dates de publication ou confondre un document mis à jour avec une version plus ancienne. La présence de citations ne doit pas être confondue avec l’exactitude des citations.

Le classement des recherches ajoute une incertitude supplémentaire. Des pages fortement optimisées peuvent être mieux classées que des sources primaires. Des copies syndiquées peuvent apparaître plus en évidence que les reportages originaux. Une description récupérée peut omettre des réserves qui deviennent évidentes sur la page complète.

L’API actuelle de Cloudflare renvoie des résultats de recherche plutôt qu’une vérification de page complète. Une application qui exige un haut niveau de confiance devrait récupérer les pages importantes, examiner leur contenu, comparer les dates et privilégier les documents primaires. Un appel de recherche constitue une découverte, pas une preuve.

La latence peut également façonner les décisions de qualité. Les agents font souvent face à des budgets de temps de réponse ; les développeurs peuvent donc sélectionner un fournisseur rapide ou s’arrêter après le premier résultat plausible. Cette optimisation peut entrer en conflit avec la nécessité de vérifier une affirmation sensible auprès de plusieurs sources.

Le statut bêta est important ici. Cloudflare a documenté l’interface et les caractéristiques des fournisseurs, mais les preuves publiques concernant la pertinence comparative restent limitées. Les développeurs devraient considérer les descriptions des fournisseurs comme des indications de conception, et non comme des classements de performance vérifiés indépendamment.

Il n’existe pas non plus de benchmark universel pour toutes les applications. Un fournisseur performant pour la documentation logicielle pourrait éprouver des difficultés avec l’actualité locale, la littérature scientifique ou les dépôts réglementaires d’entreprises peu connus. Les équipes ont besoin de jeux de tests tirés de leurs propres requêtes attendues.

Une évaluation utile devrait enregistrer si la bonne page apparaît, à quel rang elle figure, à quel point elle est récente et si l’extrait préserve le contexte essentiel. Elle devrait également tester des pages adversariales, des noms ambigus et des requêtes dont les réponses évoluent.

Le coût doit faire partie de cette évaluation, même lorsque les conditions commerciales exactes varient. Les workflows agentiques peuvent multiplier une question utilisateur en plusieurs recherches et appels de modèles. Les équipes devraient mesurer le coût total d’une tâche plutôt que de comparer une requête isolée.

Le positionnement sans marge de Cloudflare réduit une préoccupation, mais ne détermine pas la valeur. Une voie de récupération plus coûteuse peut valoir la peine si elle évite des appels supplémentaires ou améliore l’exactitude des réponses. Une voie moins chère peut devenir coûteuse lorsque des résultats faibles déclenchent des tentatives répétées.

La norme relative aux crawlers reste néanmoins une part importante de l’annonce. Cloudflare utilise sa position entre les sites et les clients automatisés pour fixer des exigences de participation. Le test consiste à savoir si ces règles produisent une récupération responsable sans créer d’angles morts que les développeurs ne remarqueraient pas.

Ce que les développeurs devraient surveiller après le lancement de la bêta

La prochaine phase montrera si Cloudflare Web Search API devient une primitive durable de gateway ou reste une enveloppe pratique autour des endpoints de partenaires.

Le premier signal est l’arrivée d’outils serveur natifs. Cloudflare indique que la recherche web figurera parmi les premiers outils directement intégrés au plan de contrôle d’AI Gateway. Cette version réduirait le code d’orchestration que les développeurs maintiennent actuellement.

Une implémentation utile d’outils serveur doit faire davantage que masquer un appel de fonction. Les développeurs devraient observer la manière dont elle gère les autorisations d’outils, le nombre maximal d’utilisations, les nouvelles tentatives, les délais d’expiration, la provenance des résultats et la sélection des fournisseurs. Ces contrôles déterminent si les équipes peuvent l’utiliser en toute sécurité dans des agents de production.

Si les outils serveur préservent un comportement commun entre les modèles, la thèse de Cloudflare sur le gateway devient plus solide. La plateforme prendrait en charge à la fois l’accès aux modèles et l’orchestration de la récupération. Si chaque modèle exige encore une gestion personnalisée substantielle, l’avantage se limite à la facturation et à l’observabilité.

Le deuxième signal est une portabilité mesurable entre fournisseurs. Le format de réponse partagé de Cloudflare donne l’impression qu’un changement est simple au niveau de l’API. Une véritable portabilité exige une qualité de résultats comparable, une gestion prévisible des erreurs et un comportement stable sous charge de production.

Les équipes devraient exécuter les mêmes jeux de requêtes via Ceramic.ai, Exa et Linkup. Elles devraient comparer la couverture des sources, la fraîcheur, le classement, la latence et l’utilité des extraits. Elles devraient également examiner l’évolution des résultats pour des questions ambiguës ou adversariales.

Les forces propres à chaque fournisseur ne sont précieuses que lorsque les développeurs peuvent les sélectionner délibérément. Si la plupart des applications restent sur le choix par défaut sans évaluation, la dimension de marketplace perd de son intérêt. Si les équipes acheminent les requêtes selon la charge de travail, Cloudflare obtient un rôle de coordination défendable.

Le troisième signal est la réaction des concurrents. Vercel propose déjà des outils de recherche au niveau de la passerelle, tandis que les entreprises de modèles continuent d’améliorer la navigation native. D’autres plateformes cloud peuvent combiner recherche, modèles et environnements d’exécution d’agents au sein de leurs propres plans de contrôle.

Il faudra surveiller si ces concurrents ajoutent davantage de fournisseurs de récupération indépendants, des outils d’évaluation plus solides ou des formats de citation unifiés. Cette réaction indiquera si la recherche indépendante des fournisseurs devient une fonctionnalité standard des passerelles ou un avantage différenciant temporaire.

Les développeurs doivent également suivre l’évolution des politiques relatives aux bots et des contrôles des éditeurs. La qualité de la récupération dépend d’un accès durable à des sources utiles. Une fracture croissante entre les contenus explorables et restreints affecterait tous les fournisseurs, même lorsque chaque crawler respecte les règles établies.

Pour un premier essai, choisissez une tâche dont les réponses évoluent fréquemment et disposent de sources primaires identifiables. Les notes de version, l’état des services, la documentation produit et les documents réglementaires publics offrent des cibles d’évaluation plus claires que les grandes questions d’opinion.

Créez un petit benchmark avant d’intégrer la recherche dans un agent destiné aux utilisateurs. Consignez la source attendue, la date de publication acceptable et les faits qu’une réponse correcte doit inclure. Testez ensuite séparément la récupération et la génération.

Conservez les URL des sources dans l’interface de l’application dès que possible. Les utilisateurs doivent pouvoir examiner les éléments de preuve, en particulier lorsqu’une réponse influence une décision importante. Une citation doit étayer une affirmation précise plutôt que décorer une réponse entière.

Définissez un budget de recherche pour chaque tâche. Limitez les requêtes répétées, interrompez les appels d’outils circulaires et exigez une confirmation supplémentaire avant qu’un agent n’exécute une action externe. La recherche apporte de nouvelles informations à un modèle, mais elle ne confère pas d’autorité à ces informations.

Le lancement de Introducing Web Search API via AI Gateway invite finalement les développeurs à repenser la place de la recherche. Est-elle une fonctionnalité d’un modèle, une relation directe avec un fournisseur ou un service partagé contrôlé par la plateforme applicative ?

Cloudflare a présenté un argument crédible en faveur du modèle de service partagé. La bêta réunit trois fournisseurs, une interface, les journaux de la passerelle, la gestion des identifiants et des normes explicites pour les crawlers. Sa valeur dépendra de sa fiabilité, de la qualité de la récupération et de la couche d’outils serveur promise.

Pour les équipes utilisant déjà AI Gateway ou Workers, la prochaine étape pratique consiste à réaliser une évaluation contrôlée sur de vraies requêtes. Comparez les trois fournisseurs, examinez chaque source et mesurez les résultats complets des tâches. Une couche de recherche indépendante améliorera-t-elle votre agent, ou une frontière de passerelle supplémentaire créera-t-elle davantage de travail qu’elle n’en supprime ?