Vous tapez une requête dans un moteur, vous ouvrez deux ou trois liens, vous vous arrêtez quand la réponse vous paraît solide. Un agent IA procède de la même façon, à une différence près : chaque coup d’œil lui coûte des tokens et des secondes. D’où une question qu’on se pose rarement en montant une chaîne d’agents : quel moteur lui donner, et sur quel critère ?
Artificial Analysis vient de publier le Search Index, un classement des API de recherche, ces services que l’agent interroge à la place d’un moteur grand public. Trois axes de notation : qualité des résultats, coût, vitesse. Sept fournisseurs au départ : Parallel, Exa, Firecrawl, You.com, Tavily, Keenable et Brave.
Un seul modèle, sept moteurs branchés à tour de rôle
Le protocole est simple, et c’est ce qui le rend lisible. Un seul et même modèle, GPT-5.6 Luna, dans un montage d’agent standardisé ; seul le fournisseur de recherche change d’un essai à l’autre. L’agent tourne sur Stirrup, le framework open source d’Artificial Analysis, et dispose de 25 passes par tâche pour lancer des requêtes et aller lire des pages.
Le point de comparaison est ce même modèle privé de tout outil, qui répond de mémoire : 33 points. Branchez-lui un moteur, les scores montent entre 65 et 75. Parallel, Exa et Firecrawl mènent, avec 75, 74 et 73 points.
Ces deux écarts n’ont pas la même portée. Entre le meilleur et le moins bon des fournisseurs testés, dix points. Entre un agent sans recherche et un agent équipé, plus de trente. Brancher un moteur pèse donc trois fois plus lourd que le choix du moteur lui-même.
Trois épreuves comptées à parts égales, et deux réserves
La note agrège trois jeux de tests, comptés pour un tiers chacun. DeepSearchQA aligne 900 questions de recherche qui exigent chacune plusieurs requêtes successives. Un sous-ensemble de BrowseComp, 200 cas, vise des faits difficiles à trouver, ceux qui obligent l’agent à naviguer de page en page. AA-Omniscience couvre 600 questions réparties sur six domaines de connaissance.
Deux réserves, avant de prendre ce classement au mot. La pondération égale entre les trois blocs est un choix, pas une vérité : si votre usage réel ressemble à de la vérification factuelle pointue, seul le bloc BrowseComp vous concerne, et le classement général se réorganise. Autre limite : les fournisseurs candidatent eux-mêmes pour rejoindre le banc d’essai. La méthodologie est publique, ce qui est la bonne pratique, mais un panel de volontaires ne couvre pas tout le marché.
Un bon résultat coûte moins cher qu’un résultat bon marché
Une meilleure qualité de recherche fait baisser la facture totale, et le ressort tient en une phrase : quand les bons documents arrivent dès la première passe, le modèle brûle moins de tokens à lire, filtrer et relancer.
Le chiffrage le montre sur un même fournisseur. En passant de Parallel Search Basic à la version avancée, la consommation de tokens chute de plus de 40 %. Le coût de recherche par tâche, lui, augmente. Et le coût total, celui qui tombe sur votre facture à la fin du mois, descend : 0,084 dollar contre 0,11.
C’est l’écart entre le prix à la pompe et le coût du trajet. Un carburant moins cher au litre qui vous fait consommer un tiers de plus déplace la dépense, il ne la réduit pas. Les API de recherche fonctionnent exactement pareil : leur tarif affiché ne dit rien de ce que leurs résultats font dépenser en aval, dans le modèle.
Les éditeurs de modèles raisonnent d’ailleurs sur la même grandeur. Anthropic facture son outil web_search 10 dollars pour 1 000 recherches, en plus des tokens engendrés, et lui a ajouté un filtrage qui trie les résultats avant leur entrée dans la fenêtre de contexte, précisément pour alléger cette part-là de la note.
La vitesse par requête ne dit rien du temps total
Même piège du côté de la latence. Parallel Search en mode turbo signe le meilleur temps de réponse par requête, 0,51 seconde contre 1,03 pour la version Basic. Un tableau comparatif s’arrêterait là et le déclarerait deux fois plus rapide.
Sa qualité est pourtant plus faible, 67 points contre 73, ce qui oblige l’agent à relancer des passes pour combler les trous. Au bout du compte, le temps total par tâche finit à peu près identique : la rapidité gagnée sur chaque appel a été rendue en nombre d’appels.
Verdict d’ensemble d’Artificial Analysis : Parallel, Firecrawl et Parallel en mode turbo offrent le meilleur compromis entre coût et performance. L’unité de mesure compte ici plus que le podium : pour une API de recherche, on paie la tâche menée à son terme, appels et tokens du modèle compris.
Reproduire la mesure sur vos propres tâches
Concrètement, cela change la façon d’arbitrer dans votre propre pile :
- comparez le coût complet d’une tâche réussie, recherche et tokens du modèle additionnés, jamais le tarif par requête isolé ;
- mesurez la même chose pour la latence : temps de bout en bout, nombre de passes nécessaires, pas la milliseconde par appel ;
- gardez sous les yeux votre mesure de référence sans outil, c’est elle qui dit ce que la recherche vous apporte réellement sur vos tâches et pas sur celles du banc d’essai ;
- maintenez une couche d’abstraction devant le fournisseur : sur un marché noté publiquement, les positions vont bouger tous les trimestres.
Pour un agent, la recherche rejoint le modèle dans la colonne des dépendances qu’on mesure, qu’on chiffre et qu’on remplace. Jusqu’ici, on choisissait un fournisseur de recherche à l’estime, sur une démo et un tarif. Le classement d’Artificial Analysis ne vous dira pas lequel brancher chez vous, il ne connaît ni vos tâches ni votre modèle. Il vous donne l’instrument de mesure, et le premier fournisseur qui refusera de s’y soumettre vous aura appris quelque chose.
