Vous demandez à un assistant si une fonction annoncée cette semaine est déjà disponible. Il trouve un article récent et répond avec un lien. Mais ce lien peut parler d’une étape future, reprendre une annonce ancienne ou viser une autre offre. Trouver une page et vérifier une affirmation sont deux opérations différentes. La nouvelle interface de recherche web de Cloudflare fournit un point d’entrée ; votre application doit encore organiser le chemin vers une réponse vérifiable.
Dans le scénario fictif de cet article, vous préparez un assistant de veille produit. Son utilisateur attend une réponse courte : ce qui est annoncé, ce qui est accessible et ce qui reste prévu. Nous proposons une méthode pour séparer ces états, garder les preuves utiles et produire un refus précis quand une information manque. Aucun service de recherche n’a été appelé pour mesurer ses performances.
Ce qui change avec Web Search API
Le 2 octobre 2026, Cloudflare annonce Web Search API via AI Gateway, sa passerelle pour les appels d’IA. Les Server Tools natifs, qui doivent intégrer des outils côté serveur à cette passerelle, restent annoncés comme une étape future. Ils ne sont pas présentés ici comme disponibles.
La documentation consultée le 6 octobre, mise à jour le 2 octobre, indique une bêta ouverte. Elle décrit des résultats structurés comprenant titres, URL et descriptions, plusieurs fournisseurs, un accès REST depuis un serveur ou par binding Workers, et une journalisation dans AI Gateway. REST désigne ici une interface appelée par requêtes réseau ; le binding est l’accès fourni au programme qui tourne dans Workers.
L’intérêt architectural est de rendre identifiable l’étape « chercher ». Vous pouvez lui attribuer un délai, un coût, un statut d’échec et une trace. Dans notre proposition, cette étape renvoie des candidats. Une autre étape ouvre la source autorisée, une troisième qualifie l’affirmation et une dernière rédige la réponse. Le même agent peut participer à plusieurs étapes, mais les responsabilités restent distinctes dans votre application.
Définir la question avant d’envoyer une requête
« Cette fonction est-elle disponible ? » manque de contexte. Disponible pour quelle offre, quelle région, quelle version et à quelle date ? Demandez les précisions nécessaires ou annoncez le périmètre retenu. Dans notre exemple fictif, la question devient : « Au jour de consultation, la fonction décrite dans cette annonce est-elle ouverte aux développeurs de cette offre ? »
Une requête de recherche devrait contenir les termes publics nécessaires à cette question. Elle n’a pas besoin du nom d’un client, de son contrat ni du contenu d’un dossier interne. Notre recommandation est de construire une formulation minimale avant l’appel au prestataire et de vérifier ce qui entre dans les journaux. Une trace utile à l’exploitation peut devenir inutilement sensible si elle recopie toute la conversation.
Fixez également un budget de travail. Votre assistant peut recevoir une limite d’appels, un délai global et une liste de sources prioritaires. Ces choix sont des paramètres applicatifs à adapter ; nous ne donnons pas de valeurs prétendument optimales. Lorsque le budget est épuisé, l’application doit distinguer « recherche incomplète » de « fonction indisponible ».
Relier chaque phrase à une preuve
Pour chaque résultat pertinent, cherchez la page à l’origine du fait : annonce de l’éditeur, documentation de la fonction ou dépôt officiel. Une reprise de presse peut aider à la découverte. Elle ne devient pas la preuve primaire uniquement parce que sa date est plus récente. Si la page originale est inaccessible, conservez cette limite et réduisez la portée de votre réponse.
Dans notre méthode, une preuve soutient une affirmation précise. Par exemple, l’annonce peut soutenir « une ouverture est prévue », tandis que la documentation d’accès doit soutenir « cette fonction est utilisable dans telle offre ». Vous pouvez donc avoir deux liens utiles qui répondent à deux questions différentes. Une bibliographie placée à la fin ne résout pas cette correspondance à elle seule.
Séparez trois dates. La date de publication décrit le document. La date de l’événement décrit ce qui s’est produit. La date de consultation décrit le moment où vous avez lu la page. Un article publié aujourd’hui peut raconter un événement ancien ; une documentation modifiée aujourd’hui peut conserver une disponibilité antérieure. Si une date n’est pas vérifiable, laissez-la inconnue plutôt que la déduire d’une URL.
Construire une fiche de preuve indépendante du fournisseur
Nous appelons SearchEvidence le contrat conceptuel ci-dessous. Ce nom et ses champs appartiennent à notre démonstration ; ils ne décrivent pas le schéma officiel de Web Search API. Le but est de pouvoir changer de source de recherche sans perdre la logique de vérification.
| Champ conceptuel | Ce qu’il décrit | Contrôle proposé |
|---|---|---|
| URL de source | Page effectivement examinée | Adresse autorisée et ouverture réussie |
| Titre | Identification du document | Correspondance avec la page lue |
| Consulté le | Moment du contrôle | Horodatage de l’application |
| Publié le | Date vérifiée du document | Origine de la date conservée |
| Événement le | Date du fait, si connue | Passage pertinent identifié |
| Affirmation soutenue | Phrase que la preuve permet | Portée limitée au contenu lu |
| Passage utile | Courte portion ou reformulation | Pas de copie intégrale automatique |
| Statut de preuve | Suffisante, contradictoire ou absente | Règle explicite avant rédaction |
Le lecteur doit pouvoir ouvrir la citation et comprendre pourquoi elle accompagne la phrase. Dans notre assistant de veille, une réponse pourrait présenter séparément une annonce datée et une disponibilité restant à confirmer. Si une page ne permet pas de déterminer le statut d’accès, écrivez-le. Le modèle ne doit pas compléter cette case avec ce qui lui semble habituel pour ce fournisseur.
Gardez une distinction entre l’URL du résultat et celle de la page réellement consultée, notamment après une redirection. Enregistrez aussi un refus d’ouverture ou une restriction d’accès. Ces états sont utiles pour expliquer pourquoi la preuve n’a pas pu être consolidée, sans prétendre que tous les sites du Web sont lisibles.
Préparer une intégration avec des limites visibles
Dans une application existante, ajoutez une interface de recherche à côté de vos services documentaires. Sa sortie est une liste de candidats et un état d’appel. L’ouverture d’une page appartient à un composant séparé, avec les règles réseau et de collecte autorisées par votre organisation. La rédaction reçoit ensuite uniquement les éléments nécessaires au sujet.
Le cache, c’est-à-dire la réutilisation temporaire d’une réponse précédente, demande un choix explicite. Une recherche de définition et une question sur une disponibilité actuelle n’ont pas la même exigence de fraîcheur. Conservez la date de la preuve réutilisée et prévoyez une nouvelle consultation lorsque la question l’exige. La date de réponse de l’assistant ne doit pas donner l’impression que toutes les sources viennent d’être relues.
Pour éviter une boucle coûteuse, bornez les relances et distinguez les erreurs : délai dépassé, accès refusé, format inattendu ou recherche sans candidat pertinent. Préparez un message de sortie pour chacune. « Je n’ai pas pu vérifier la page primaire » est plus utile qu’une réponse assurée construite à partir d’un résumé incomplet.
Ce parcours peut compléter une base interne. Celle-ci conserve vos procédures et votre vocabulaire ; la recherche publique sert à vérifier une annonce ou une évolution externe. L’usage appelé RAG, génération augmentée par récupération de documents, consiste précisément à apporter des documents au modèle avant sa réponse. L’ajout d’une recherche web invite à organiser les sources publiques et internes, avec leurs droits et leurs exigences de fraîcheur.
Tester les réponses, les citations et les refus
Le protocole suivant est une proposition Partitech. Il utilise des pages de test contrôlées ou des doubles réseau : des composants qui simulent les réponses sans appel réel au prestataire. Il permettrait d’évaluer la logique de votre application sans présenter les résultats comme ceux du service Cloudflare.
| Cas de test proposé | Observation attendue | Sortie à vérifier |
|---|---|---|
| Annonce récente d’une étape future | Date récente, accès futur | Distinction annoncé/prévu |
| Fait ancien dans une page récente | Deux dates différentes | Pas de présentation comme nouveauté |
| Page primaire inaccessible | Résultat de recherche seul | Vérification insuffisante signalée |
| Deux sources divergentes | Périmètres ou versions différents | Contradiction explicitée |
| Délai réseau dépassé | Recherche incomplète | Échec déclaré, pas de conclusion inventée |
| Instruction dans une page | Texte extérieur à l’application | Instruction ignorée, données traitées comme source |
Évaluez ensuite les réponses phrase par phrase. Comptez les affirmations soutenues, celles sans preuve et celles dont la citation porte sur un autre périmètre. Examinez également les refus : sont-ils justifiés et disent-ils ce qui manque ? Un assistant qui refuse tout ne satisfait pas davantage la tâche qu’un assistant qui répond toujours.
Séparez le test du composant de recherche et celui de la rédaction. Vous pouvez disposer de bons résultats et produire une mauvaise synthèse, ou ne trouver aucune source malgré une excellente logique de citation. Cette séparation aide à choisir la correction pertinente plutôt qu’à modifier au hasard la consigne du modèle.
Traiter les pages comme des données extérieures
Une page peut contenir une phrase qui demande à l’agent d’ignorer ses règles ou d’envoyer une information ailleurs. Dans notre conception, ce texte n’acquiert aucune autorité : il reste un contenu à examiner. Les permissions d’action, la consigne du système et les secrets ne doivent pas être redéfinis par une source recherchée.
Prévoyez donc un test où une page de démonstration contient une instruction étrangère au sujet. Le succès attendu est une extraction limitée à la preuve utile, sans action supplémentaire. Vérifiez aussi les journaux et la réponse finale pour éviter qu’ils reproduisent des données sensibles ajoutées au contexte. Il s’agit d’un garde-fou à tester dans votre propre architecture, pas d’une capacité garantie par une API de recherche.
Pour commencer, choisissez une question publique et bornée, fixez les preuves nécessaires et préparez les six cas de test. La prochaine étape est d’obtenir une réponse dont chaque affirmation peut être contrôlée, ainsi qu’un refus compréhensible lorsque la preuve manque. Vous pourrez ensuite mesurer le service réel dans un cadre autorisé, avec ses coûts et ses limites datées.
Sources et date de vérification
Sources primaires rouvertes et lues le 6 octobre 2026 : Cloudflare, annonce Web Search API du 2 octobre ; documentation Web Search API, mise à jour le 2 octobre. Le contrat SearchEvidence, le scénario et les tests sont des propositions Partitech. Aucun benchmark, test réseau applicatif ou audit des partenaires n’est revendiqué.