Mozilla AI pose la question : qui effectue les recherches web pour votre agent ?

Mozilla AI remet en question la recherche groupée des agents avec Otari, qui permet aux équipes de choisir un service de recherche indépendamment de leur modèle. Qui effectue les recherches web pour votre agent ? Son billet du 19 octobre concrétise cette question : choisir un modèle d’IA ne détermine pas nécessairement où vont ses requêtes de recherche.

Otari se situe entre un agent, un logiciel qui utilise des outils pour accomplir des tâches, et le fournisseur de modèle. Mozilla AI affirme que cette position lui permet de rediriger les recherches tout en préservant les interfaces clientes prises en charge. Le changement proposé concerne qui contrôle la récupération d’informations, plutôt que le modèle qui rédige la réponse.

Les approches concurrentes sont simples : accepter la recherche fournie avec un service de modèle, ou gérer la recherche comme une dépendance distincte. Claude Code offre un point de référence utile, car sa recherche intégrée utilise le backend d’Anthropic. Otari remet en cause cet arrangement en faisant du routage de la recherche une décision indépendante, avec une responsabilité supplémentaire pour la personne qui la prend.

Qui effectue les recherches web pour votre agent ? Otari rend le choix explicite

Dans son analyse de la recherche des agents, Mozilla AI décrit trois choix : une recherche opérée par Otari, le compte de recherche d’un client, ou un point de terminaison auto-hébergé. L’entreprise cite Brave, Exa et Tavily parmi les services que les clients peuvent connecter avec leurs propres identifiants.

Selon Mozilla AI, les clients peuvent conserver Claude, GPT ou Gemini tout en changeant le service qui gère les recherches. Les identifiants de recherche restent dans la passerelle, l’intermédiaire qui achemine les requêtes, plutôt que d’atteindre l’agent. L’entreprise décrit également des contrôles d’espace de travail et des enregistrements de recherche associés à l’utilisation des modèles.

Le changement déterminant consiste à faire de la recherche une dépendance que les équipes peuvent sélectionner séparément du modèle.

Cette distinction est facile à manquer lorsqu’une application présente une unique zone de réponse. Un utilisateur pose une question, attend, puis reçoit une réponse contenant des citations. L’interface peut donner l’impression que la récupération et le raisonnement constituent une seule opération, même lorsque différents services les exécutent.

Séparer ces opérations change la manière dont les acheteurs évaluent le système. L’évaluation d’un modèle répond à la question de savoir s’il suit les instructions et raisonne efficacement. Une évaluation de la recherche demande si le système récupère des éléments probants adéquats, traite les requêtes de façon acceptable et répond aux exigences opérationnelles de l’organisation.

Aucune de ces évaluations ne remplace l’autre. Un bon raisonnement ne peut pas récupérer un document qui n’a jamais intégré l’ensemble des preuves. Une récupération performante ne peut pas empêcher toutes les conclusions non étayées. Les traiter séparément donne aux équipes une manière plus claire d’enquêter sur les défaillances sans tout attribuer au modèle.

Le billet de Mozilla AI doit aussi être lu avec précision comme une déclaration d’orientation produit et de capacités documentées. Sa date de publication n’établit pas quand chaque fonctionnalité sous-jacente est devenue disponible. L’annonce n’établit pas non plus que les clients ont déjà obtenu de meilleures réponses ou réduit leurs coûts d’exploitation.

L’actualité immédiate est donc plus limitée qu’une affirmation selon laquelle la recherche des agents serait résolue. Mozilla AI fait du fournisseur de recherche un élément explicite de la discussion sur les achats et l’architecture. Cela crée une alternative pratique à l’acceptation de tout service de récupération qui accompagne un modèle choisi.

Pour les équipes déjà satisfaites d’une recherche groupée, l’alternative doit justifier sa charge opérationnelle. Pour les équipes bloquées par un arrangement de recherche inacceptable, séparer cette dépendance résout un problème tout différent. Elles ont besoin d’un choix qu’elles peuvent évaluer, plutôt que d’un nouveau classement de modèles.

La requête elle-même mérite un examen attentif

Une requête de recherche constitue une divulgation sortante, même lorsque la réponse demandée porte sur des informations publiques.

Prenons l’exemple hypothétique d’un assistant de programmation qui enquête sur une défaillance logicielle. La requête publique utile pourrait décrire un message d’erreur et une version de bibliothèque. Une requête inutilement précise pourrait également inclure un nom de service interne, un identifiant client ou le nom d’un projet non publié.

La distinction concerne ce qui sort de l’organisation, et non la sûreté de la lecture d’une documentation publique. Un assistant peut avoir une raison légitime d’effectuer une recherche tout en construisant une requête inappropriée. Choisir le fournisseur de recherche traite de son destinataire ; examiner la construction des requêtes traite de leur contenu.

Cette séparation compte pour les responsables de l’ingénierie et les acheteurs en entreprise. Approuver un modèle ne répond pas à toutes les questions sur les outils qui lui sont associés. Chaque service supplémentaire introduit une relation opérationnelle qui mérite sa propre évaluation, en particulier lorsque les requêtes proviennent d’un contexte de travail privé.

La réponse raisonnable consiste à suivre une tâche réelle. Quelles informations sont entrées dans le prompt ? Quel texte est devenu une requête de recherche ? Quel service l’a reçue ? Quels résultats sont revenus, et lesquels ont influencé la réponse ?

Ces questions rendent une discussion d’achat plus concrète. Elles révèlent aussi où s’arrête une affirmation. Connaître la destination établit une visibilité sur le routage. Cela n’établit pas que chaque requête était nécessaire, formulée de manière appropriée ou couverte par des conditions de traitement acceptables.

Le même raisonnement s’applique à la recherche client. Imaginez un assistant préparant un briefing sur un compte potentiel. Les informations publiques sur l’entreprise ont leur place dans le processus de recherche. Les notes commerciales privées, les termes contractuels proposés et les évaluations internes exigent une décision distincte avant d’apparaître dans des requêtes externes.

Il s’agit de scénarios illustratifs, et non de déploiements clients Otari documentés. Leur intérêt est de montrer pourquoi le choix de la recherche compte au-delà des préférences des développeurs. Une recherche apparemment ordinaire peut franchir une limite que la réponse finale ne révèle pas.

Les travailleurs du savoir doivent également distinguer la découverte publique de la recherche dans leurs propres documents. Une base de connaissances personnelle répond à un besoin d’information différent de celui consistant à trouver de nouvelles sources publiques. Un flux de travail efficace devrait identifier le type de preuve requis par la tâche avant de choisir où rechercher.

Pour un chef de produit, cela peut signifier consulter la recherche interne avant de demander des informations actuelles sur les concurrents. Pour un ingénieur, cela peut signifier vérifier des décisions de conception privées avant de consulter une documentation publique. L’enjeu est une récupération ciblée, plutôt que d’envoyer chaque incertitude vers le web ouvert.

Cela met la pression sur les personnes qui approuvent les déploiements d’agents. Elles ont besoin d’une visibilité suffisante pour expliquer le cheminement de l’information, y compris ses limites. Un produit qui expose la destination de recherche peut étayer cette explication, mais l’organisation doit toujours décider quelles informations ont leur place sur ce chemin.

Qui effectue les recherches web pour votre agent ? Pour les acheteurs, une réponse adéquate comprend l’opérateur, l’accord concerné et l’étendue des informations envoyées. Le seul fait de nommer un modèle reconnaissable laisse inachevée la partie recherche de cette réponse.

La recherche groupée offre de la commodité, tandis qu’une recherche distincte ajoute de la responsabilité

L’argument le plus solide en faveur de la recherche groupée est la commodité. Un développeur reçoit une interface d’outils prise en charge sans devoir assembler chaque élément de la récupération. Une organisation peut préférer cet arrangement lorsque ses exigences correspondent au service et au comportement documenté du fournisseur.

L’outil de recherche web d’Anthropic illustre l’approche intégrée. Claude détermine quand effectuer une recherche, le service exécute les recherches et la réponse finale inclut des citations. Sa documentation décrit également des contrôles de domaine et différentes versions d’outils.

Ces capacités comptent, car la recherche configurable n’est pas propre à une passerelle indépendante. Les clients doivent distinguer les contrôles du comportement de recherche du contrôle du fournisseur de recherche. Un fournisseur peut proposer des restrictions utiles tout en conservant la responsabilité de l’exploitation du service sous-jacent.

Le choix central porte sur qui détient les décisions de récupération et le travail nécessaire à leur maintenance.

La proposition d’Otari séduit les équipes qui souhaitent cette maîtrise. Mais l’indépendance introduit des responsabilités que les services groupés absorbent ou simplifient. Quelqu’un doit gérer les identifiants, évaluer le comportement du service, enquêter sur les défaillances et maintenir une relation fonctionnelle entre l’agent et ses outils de recherche.

Ollama offre un autre point de comparaison utile. Sa documentation sur la recherche web hébergée spécifie une requête authentifiée vers ollama.com/api/web_search. La réponse comprend des résultats contenant des titres de pages, des adresses et des extraits de contenu.

Cet exemple établit un point limité mais important : utiliser un modèle local n’établit pas que ses recherches web restent locales. La requête de recherche documentée atteint un service hébergé. Les clients doivent examiner séparément l’inférence, la recherche et la récupération de pages lorsqu’ils évaluent où le traitement a lieu.

Ce n’est pas une preuve qu’une recherche hébergée est intrinsèquement inadaptée. Un service hébergé peut être un choix acceptable lorsque ses conditions, son comportement et sa fiabilité répondent aux besoins de l’organisation. L’erreur pertinente consiste à supposer qu’un choix architectural détermine automatiquement tous les autres composants.

La même discipline s’applique à la qualité des réponses. Changer de service de recherche modifie les éléments probants disponibles pour le modèle. Une évaluation qui modifie simultanément le modèle et la recherche ne peut pas facilement expliquer quel changement a amélioré ou détérioré le résultat.

Séparer ces variables permet des comparaisons plus instructives. Les équipes peuvent maintenir le modèle constant tout en examinant la récupération, puis maintenir les éléments probants constants tout en examinant la synthèse. De telles évaluations exigent toujours une conception soignée, mais elles évitent de traiter l’ensemble de l’application comme une boîte noire indivisible.

Une évaluation de recherche web Otari devrait donc commencer par les propres tâches de l’équipe. La consultation de documentation publique, la recherche récente sur des entreprises et la découverte technique spécialisée peuvent nécessiter des preuves différentes. Une affirmation universelle selon laquelle un service de recherche est le meilleur nécessiterait des preuves allant au-delà de ces charges de travail individuelles.

L’annonce de Mozilla AI ne fournit aucune étude comparative indépendante établissant un tel gagnant. L’interprétation la plus solide est que les clients devraient pouvoir choisir et tester cette dépendance. C’est un argument en faveur du contrôle et de l’évaluation, plutôt qu’un classement démontré des moteurs de recherche.

La pression porte sur les deux approches. Les fournisseurs de services groupés doivent expliquer leurs arrangements de recherche assez clairement pour que les acheteurs puissent les évaluer. L’infrastructure indépendante doit démontrer que ce contrôle supplémentaire reste utilisable lorsque les clients, les modèles et les interfaces d’outils changent.

La recherche web Otari dépend du respect des attentes du client

Un service de recherche configurable n’aide que si l’agent peut l’utiliser correctement. Les applications attendent davantage qu’une liste de liens. Elles dépendent de réponses d’outils reconnaissables, d’un comportement en cas d’erreur et de suffisamment d’informations sur les sources pour poursuivre la tâche.

La documentation d’interception des recherches d’Otari décrit la prise en charge de déclarations de recherche prises en charge et nommées d’après des fournisseurs lorsque l’interception est activée. L’interception consiste à traiter une requête qui irait autrement vers l’outil du fournisseur. La documentation distingue ce comportement du transfert de requêtes natives au fournisseur.

Il décrit également des restrictions d’espace de travail, notamment la désactivation de la recherche, la limitation des résultats et le ciblage de domaines précis. La documentation avertit que la configuration SearXNG fournie est limitée en débit pour une utilisation soutenue. Cet avertissement compte lorsqu’on évalue la préparation à la production plutôt qu’une brève démonstration.

Préserver l’interface réduit le travail d’intégration, mais n’établit pas un comportement identique.

Un client peut accepter une réponse tout en recevant des éléments probants différents. Il peut aussi traiter correctement une recherche réussie tout en réagissant mal à un service indisponible. La compatibilité doit donc couvrir le fonctionnement courant comme les situations qui l’interrompent.

Une tâche de programmation hypothétique rend la différence visible. Un assistant recherche un guide de migration, lit le résultat et propose une modification de code. Une évaluation utile vérifie si le guide récupéré correspond à la version pertinente du logiciel et étaye la modification proposée.

La même tâche doit rester compréhensible lorsque la recherche ne renvoie rien. Un agent qui signale clairement l’absence d’éléments probants se comporte différemment d’un agent qui improvise une réponse. Le format de réponse de la passerelle compte, tout comme l’interprétation de l’échec par le client.

C’est là que les comparaisons fondées uniquement sur la fluidité des réponses deviennent trompeuses. Une explication soignée peut masquer des preuves faibles. Une réponse moins élégante qui identifie ses limites peut être plus utile pour une décision technique conséquente.

La configuration de recherche d’Otari documente des instances de recherche nommées et une sélection par défaut. Elle décrit également des paramètres propres aux fournisseurs et des exigences relatives aux identifiants. Ces détails montrent que l’indépendance de recherche est une configuration opérationnelle, plutôt qu’une simple préférence exprimée dans un prompt.

Pour les équipes plateforme, la configuration soulève des questions de maintenance familières. Qui peut modifier la valeur par défaut ? Comment une modification atteint-elle les différents espaces de travail ? Quels éléments prouvent qu’une requête a utilisé le service prévu ? Les réponses déterminent si le contrôle résiste à l’activité organisationnelle ordinaire.

Un paramètre peut exister sans devenir une politique effective. Une évaluation doit établir ce qui se produit dans la configuration de déploiement réelle, y compris les exceptions autorisées. Sinon, une démonstration de recherche sélectionnable risque d’être confondue avec une garantie concernant chaque requête de production.

La distinction devient particulièrement importante lorsqu’une application dispose de plusieurs moyens d’accéder à des informations externes. Un outil de recherche, un récupérateur de pages et un navigateur peuvent représenter des chemins distincts. Contrôler un chemin n’établit pas le contrôle de tous les autres.

Cette observation relève de l’architecture, et non d’une conclusion selon laquelle Otari disposerait d’un contournement spécifique. Les acheteurs doivent demander des preuves de couverture correspondant à leurs clients et aux outils activés. Des formules générales telles que « tout le trafic des agents » exigent une vérification plus large qu’une recherche interceptée avec succès.

Le mécanisme est prometteur parce qu’il place une décision de routage en dehors du jugement du modèle. Sa valeur pratique dépend de l’utilisation cohérente de cette route contrôlée par l’application environnante. L’évaluation doit suivre la tâche complète, y compris les moments où la route attendue échoue.

L’auto-hébergement modifie la responsabilité sans éliminer les dépendances

Exploiter vous-même l’intermédiaire de recherche ne signifie pas exploiter un index web indépendant.

L’architecture de métarecherche de SearXNG agrège les résultats d’autres moteurs de recherche. Cela précise le sens de l’auto-hébergement : une organisation peut exploiter le service d’agrégation tout en restant dépendante de moteurs en amont pour les résultats.

Pour un déploiement Otari utilisant SearXNG, cette distinction évite une promesse de confidentialité exagérée. L’opérateur contrôle son instance, mais les relations amont configurées de cette instance comptent toujours. Une évaluation complète suit la requête au-delà du premier serveur de l’organisation.

C’est un test sceptique utile du message plus général. Si l’auto-hébergement est présenté comme une indépendance complète, la métarecherche complique cette promesse. S’il est présenté comme un contrôle sur un composant défini, l’affirmation est plus restreinte et plus facile à évaluer.

La même rigueur doit régir les comparaisons de coûts. Supprimer un coût de recherche intégré n’élimine pas le travail nécessaire à l’exploitation de la récupération d’informations. L’infrastructure, la maintenance, la réponse aux incidents et l’attention du personnel font partie de l’évaluation, même lorsqu’ils n’apparaissent pas sur une facture par requête.

Rien ne permet ici d’affirmer que l’auto-hébergement est systématiquement moins coûteux. La comparaison pertinente dépend de la charge de travail, des exigences de service et des capacités existantes de l’organisation. Une équipe exploitant déjà une infrastructure connexe prend une décision différente d’une équipe dépourvue de cette expertise.

Le contrôle des identifiants exige lui aussi une interprétation précise. Tenir les identifiants à l’écart de l’agent réduit une voie d’exposition. Le service qui détient ces identifiants reste un système sensible nécessitant une administration et des contrôles d’accès appropriés.

Les enregistrements de recherche créent un autre compromis. Ils peuvent aider à expliquer pourquoi un agent a produit une réponse, mais ils peuvent aussi conserver du texte de requête sensible. Une organisation cherchant à assurer la traçabilité doit décider qui peut consulter ces enregistrements et combien de temps ils restent utiles.

Une visibilité accrue crée donc sa propre tâche de gouvernance. Des enregistrements détaillés ne sont pas automatiquement meilleurs dans tous les contextes. L’objectif est de disposer de preuves suffisantes pour une enquête, avec des règles de traitement adaptées aux informations contenues dans ces enregistrements.

Les restrictions de domaine ont de même une valeur limitée. Elles peuvent restreindre le vivier de sources admissibles. Elles n’établissent pas que chaque page d’un domaine autorisé est exacte, actuelle ou appropriée à la tâche précise.

Le choix d’un fournisseur de recherche ne résout pas non plus le problème de l’injection de prompt, ce contenu malveillant conçu pour rediriger le comportement d’un assistant. Les pages récupérées restent des entrées externes. Un agent doit les traiter comme des éléments à évaluer, plutôt que comme des instructions faisant autorité sur sa tâche.

Ces limites n’invalident pas l’argument en faveur d’une recherche indépendante. Elles définissent ce que cet argument peut étayer. Choisir une dépendance donne aux organisations un lieu où exercer leur jugement ; cela ne garantit pas que ce jugement sera correct.

Le résultat crédible est une responsabilité accrue pour des choix identifiables. Un acheteur peut demander pourquoi un service a été choisi, quelles hypothèses l’étayent et ce qui déclencherait un changement. Ces questions restent utiles même lorsque la réponse choisie est un fournisseur géré.

Un déploiement de recherche web Otari doit être évalué au regard de ces responsabilités concrètes. L’annonce seule n’établit ni une récupération supérieure, ni une compatibilité universelle, ni un résultat complet en matière de confidentialité. Les preuves provenant de l’environnement réel d’une équipe doivent étayer ces conclusions.

Surveiller la compatibilité, les preuves comparatives et la transparence des fournisseurs

La prochaine période d’observation devrait se concentrer sur des changements observables plutôt que sur des promesses d’une pile d’IA plus ouverte. Jusqu’à la fin de 2026 et au début de 2027, les signaux utiles indiqueront si la recherche indépendante devient plus facile à exploiter et à évaluer.

Les preuves les plus solides démontreront un contrôle fiable lors de tâches réelles, y compris pendant les échecs et les changements.

Le premier signal est la publication de preuves de compatibilité pour les clients et les interfaces d’outils que les équipes utilisent réellement. Une version utile identifierait les comportements testés, les versions prises en charge et les limites connues. Des exemples reproductibles renforceraient l’argument selon lequel les clients peuvent conserver leurs applications tout en changeant de service de recherche.

À l’inverse, des solutions de contournement répétées, propres à chaque client, affaibliraient l’affirmation pratique d’indépendance. Un service théoriquement remplaçable offre une liberté limitée si chaque remplacement exige une réparation substantielle de l’application. La compatibilité doit rester compréhensible à mesure que les logiciels environnants évoluent.

Le deuxième signal est une évaluation comparative avec une charge de travail contrôlée. Maintenez le modèle et les tâches constants, puis examinez la pertinence de la récupération, la fraîcheur, le temps de réponse, les échecs et l’effort opérationnel total. Le résultat devrait identifier où chaque arrangement fonctionne, y compris les cas où la recherche intégrée reste préférable.

Une évaluation convaincante publierait suffisamment de détails pour que les lecteurs comprennent ses limites. Les résultats d’une recherche dans la documentation ne doivent pas devenir des affirmations concernant chaque tâche de recherche. Des preuves de bénéfices ciblés seraient plus crédibles qu’une déclaration inexpliquée de supériorité globale.

Le troisième signal est une transparence plus claire ou un choix supplémentaire de fournisseurs de la part des fournisseurs intégrés. Une documentation plus explicite aiderait les clients à évaluer les services existants sans adopter un autre intermédiaire. Une sélection prise en charge par le fournisseur permettrait aussi de vérifier si les clients recherchent principalement l’indépendance ou simplement des contrôles plus clairs.

Cette évolution renforcerait l’argument sous-jacent de Mozilla AI tout en modifiant la position concurrentielle d’Otari. La recherche deviendrait une décision d’achat plus visible, même si les acheteurs exerçaient ce choix ailleurs. La question durable est de savoir qui peut prendre et expliquer cette décision.

Qui effectue les recherches web pour votre agent ? La réponse devrait devenir plus précise à mesure que ces signaux se développent. Elle devrait identifier un chemin d’information réel et les preuves étayant son utilisation, plutôt que de s’appuyer sur des hypothèses tirées du nom d’un modèle.

Avant d’étendre un workflow d’agent, examinez une tâche représentative, du prompt à la réponse finale. Identifiez la requête sortante, son destinataire, les sources renvoyées et les preuves étayant la conclusion. Demandez-vous ensuite si l’organisation correspond à la sensibilité et à l’objectif du travail. Conservez la recherche intégrée lorsque son comportement documenté répond à ces besoins. Évaluez un service de recherche distinct lorsque le choix du fournisseur, le contrôle opérationnel ou des enregistrements plus clairs répondent à une exigence concrète. Pour les tâches combinant connaissances privées et recherche publique, examinez explicitement cette frontière plutôt que de traiter toutes les recherches de la même manière. La prochaine étape utile est une décision que votre équipe peut expliquer : quel service de recherche cet agent doit-il utiliser, et quels éléments justifient ce choix ?