Agentic search vs scraping de SERP : pourquoi les agents ont besoin d'une API différente

Pendant vingt ans, une API de recherche voulait dire « scraper la page de résultats de Google ». Les agents IA ont brisé cette hypothèse. Voici ce qu'est vraiment l'agentic search, pourquoi elle a émergé, et quand l'ancien modèle SERP garde du sens.
L'essentiel
- •L'agentic search est une recherche web conçue pour être consommée par un agent IA : vous envoyez un objectif sémantique et récupérez une courte liste classée de passages de texte propres et citables, calibrés pour une fenêtre de contexte.
- •Le scraping de SERP renvoie le HTML/JSON brut d'une page de résultats de moteur de recherche — bâti pour les humains et les tableaux de bord, pas pour les modèles de langage.
- •Le basculement s'est produit parce que les LLM raisonnent sur du texte court et classé, pas sur un blob de SERP, et parce que Microsoft a fermé l'API Bing Search en août 2025, forçant une re-sélection à l'échelle du marché.
- •L'agentic search ajoute trois choses qui manquent aux API SERP : des fragments déjà nettoyés, des réponses sourcées optionnelles, et une facturation adaptée aux agents (par appel, souvent seulement en cas de succès).
- •Le scraping de SERP l'emporte encore quand vous avez véritablement besoin de la page de résultats complète de Google — classements, knowledge panels, local packs — et que vous exploitez votre propre pipeline de nettoyage.
Une définition, d'emblée
L'agentic search est une recherche web conçue pour être consommée par un agent IA plutôt qu'affichée à un humain. Vous envoyez une requête — ou un objectif sémantique de plus haut niveau — et vous récupérez une courte liste classée de titres, d'URL et de passages de texte déjà nettoyés, parfois une réponse finie et sourcée, déjà mis en forme pour s'insérer dans la fenêtre de contexte d'un modèle de langage.
C'est un produit différent de ce que « une API de recherche » a voulu dire pendant les vingt années précédentes. Pendant deux décennies, une API de recherche voulait dire : donne-moi la page de résultats qu'un humain verrait. C'est exactement cette hypothèse que les agents IA ont brisée.
L'ancien modèle : le scraping de SERP
Une API SERP (search engine results page) renvoie le JSON structuré d'une page de résultats Google ou Bing — liens organiques, knowledge panel, « people also ask », local packs, publicités, carrousels shopping. Des outils comme Serper et SerpApi font cela extrêmement bien et à bas coût. La sortie est fidèle à ce qu'une personne voit dans un navigateur :
{
"organic": [
{ "position": 1, "title": "…", "link": "https://…", "snippet": "…" },
{ "position": 2, "title": "…", "link": "https://…", "snippet": "…" }
],
"knowledgeGraph": { "title": "…", "type": "…", "description": "…" },
"peopleAlsoAsk": [ /* … */ ],
"relatedSearches": [ /* … */ ]
}C'est parfait pour un tableau de bord SEO, un suivi de classement ou un outil de recherche avec humain dans la boucle. C'est la mauvaise forme pour un modèle de langage, pour une raison brute : un modèle ne peut pas raisonner efficacement sur un blob de SERP. Il raisonne sur du texte court, étiqueté et classé. Donnez à un modèle une SERP complète et vous dépensez des tokens de contexte en métadonnées de mise en page, en publicités et en « related searches » qui n'ont rien à voir avec la réponse.
Le nouveau modèle : l'agentic search
L'agentic search jette la SERP et ne renvoie que ce qu'un agent peut utiliser. La même requête revient sous forme de liste compacte et classée de passages propres :
{
"results": [
{
"title": "Retrieval-augmented generation - Wikipedia",
"url": "https://en.wikipedia.org/wiki/Retrieval-augmented_generation",
"snippet": "Retrieval-augmented generation (RAG) combines search with\ntext generation, grounding LLM answers in retrieved documents."
}
/* …4 more, ranked */
],
"result_count": 5,
"credits_used": 15
}Cette forme encode trois décisions délibérées qu'une API SERP vous laisse :
- Des fragments déjà nettoyés. Le boilerplate — navigation, bannières de cookies, publicités — est retiré, donc le modèle dépense son contexte sur le signal.
- Un classement pour la pertinence, pas pour les publicités. Les résultats sont ordonnés par utilité à la requête, pas par une mise en page de résultats qui monétise les premières places.
- Un budget de taille. Une poignée de résultats, pas une centaine, parce que les fenêtres de contexte et les budgets de tokens sont finis.
Pourquoi le basculement a eu lieu maintenant
Deux forces ont convergé en 2025–2026.
1. Les LLM ont fait du format SERP un handicap
Dès que les agents ont commencé à appeler la recherche comme un outil, le décalage est devenu évident. Chaque token dépensé sur l'échafaudage de SERP est un token non dépensé sur les sources réelles, et chaque page non nettoyée est un endroit où le modèle peut se laisser distraire ou citer une bannière de cookies. Les équipes se sont retrouvées à écrire une couche de nettoyage et de classement par-dessus chaque API SERP — précisément la couche que l'agentic search intègre.
2. La fermeture de Bing a forcé une re-sélection
Le 11 août 2025, Microsoft a fermé les API Bing Search, mettant hors service les endpoints qui avaient discrètement ancré une grande part des pipelines LLM. Le remplaçant — Grounding with Bing Search dans Azure AI Foundry — n'est pas une API prête à brancher et facture environ $35 pour 1 000 transactions. Des milliers d'équipes ont dû choisir un nouveau fournisseur au moment exact où une vague de startups pensées pour les agents livrait : Exa a levé une série B de $85M, Parallel a levé $100M, Tavily a été acquise par Nebius pour $275M, Linkup a levé un amorçage. La catégorie n'est pas simplement apparue — elle a été financée et propulsée au grand jour.
Scraping de SERP vs agentic search : le tableau honnête
| Scraping de SERP | Agentic search | |
|---|---|---|
| Renvoie | JSON brut de page de résultats | Fragments classés, propres et LLM-ready |
| Bâti pour | Humains, tableaux de bord, suivi de classement | Agents IA, RAG, tool calling |
| Étape de nettoyage | Vous la construisez | Incluse |
| Efficacité en tokens | Faible (mise en page + publicités dans le payload) | Élevée (signal uniquement) |
| Mode réponse | Non | Souvent (intégré ou /answer séparé) |
| Prix brut / 1k | ~$0.30–$1 | ~$5–$16 |
| Prix pipeline complet | + votre extracteur + temps d'ingénierie | Plus proche qu'il n'y paraît |
| Meilleur cas | SEO, fonctionnalités SERP, pipelines maison | Ancrer des réponses LLM dans un agent |
L'économie que personne ne met sur la page de tarification
Le choc du prix affiché — « l'agentic search coûte 10x le prix de Serper » — disparaît quand vous chiffrez le pipeline entier. Une API SERP vous donne une page de résultats ; pour alimenter un modèle vous exécutez ensuite un extracteur de contenu sur les liens choisis, plus l'ingénierie pour construire et maintenir la logique de nettoyage et de classement. L'agentic search replie cela dans l'appel. Vous ne payez pas 10x pour la même chose ; vous payez une fois pour deux étapes au lieu de deux fois pour deux étapes.
Il y a un second coût, plus sournois : les réessais. Les agents se déploient en éventail et réessaient sur des échecs transitoires. Chez un facturateur de SERP par requête, chaque réessai est facturable. La défense la plus propre est la facturation seulement en cas de succès — vous payez le HTTP 200, pas les trois timeouts qui le précèdent. Pour un trafic d'agent en pics, cette seule règle de facturation économise souvent plus que la différence de prix par appel entre fournisseurs.
Construire sur l'agentic search : la boucle minimale
Parce que la sortie est déjà mise en forme pour le modèle, l'intégration est courte. Récupérez un tool schema, remettez-le à votre modèle, et laissez-le appeler la recherche comme un outil :
import anthropic, requests
# Agentic search ships a ready-made tool definition — no hand-written JSON
schema = requests.get("https://www.apipick.com/api/search/web/tool-schema").json()
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
tools=[schema["claude"]],
messages=[{"role": "user", "content": "What is agentic search, with sources?"}],
)
# The model calls /api/search/web, gets clean ranked snippets back,
# and answers with citations — no SERP parser anywhere in the loop.C'est tout l'intérêt de la catégorie : l'API de recherche rejoint l'agent là où il est déjà, donc le code de liaison qui vivait dans votre codebase passe derrière l'endpoint.
Alors laquelle devriez-vous utiliser ?
Questions fréquentes
Qu'est-ce que l'agentic search ?
L'agentic search est une recherche web bâtie pour être consommée par un agent IA plutôt qu'affichée à une personne. Vous envoyez une requête ou un objectif sémantique, et l'API renvoie une courte liste classée de titres, d'URL et de fragments de texte déjà nettoyés — parfois une réponse finie et sourcée — déjà mis en forme pour s'insérer dans la fenêtre de contexte d'un modèle de langage. Cela contraste avec le scraping de SERP, qui renvoie la page de résultats brute qu'un humain verrait.
En quoi l'agentic search diffère-t-elle d'une API SERP ?
Une API SERP (comme Serper ou SerpApi) renvoie le JSON complet d'une page de résultats de moteur de recherche : liens organiques, publicités, knowledge panels, local packs — la mise en page destinée à l'humain — et vous faites vous-même le nettoyage, le classement et l'extraction des fragments. Une API d'agentic search (comme Exa, Tavily, Linkup ou API Pick) saute entièrement la SERP et renvoie un texte propre, classé et LLM-ready. Les API SERP optimisent la fidélité à Google ; l'agentic search optimise l'usage direct par un modèle.
Pourquoi l'agentic search a-t-elle émergé en 2025–2026 ?
Deux forces. D'abord, les LLM raisonnent mal sur un blob de SERP brut mais bien sur des passages courts, étiquetés et classés — donc un format bâti pour les humains est devenu un handicap pour les agents. Ensuite, Microsoft a fermé l'API Bing Search le 11 août 2025, qui alimentait discrètement une grande partie de l'écosystème de grounding LLM, forçant des milliers d'équipes à re-choisir un fournisseur au moment précis où des startups pensées pour les agents (Exa, Tavily, Linkup, Parallel) livraient des API conçues pour le nouveau cas d'usage.
L'agentic search, est-ce juste du RAG ?
Pas tout à fait. Le RAG (retrieval-augmented generation) est le pattern global consistant à ancrer la réponse d'un LLM dans des documents récupérés. L'agentic search est une façon de faire la moitié récupération — précisément, une récupération web en direct mise en forme pour un agent. Vous pouvez construire du RAG sur une base vectorielle privée sans aucune recherche web, et vous pouvez utiliser l'agentic search sans RAG classique. Elles se composent bien, mais ce sont des couches différentes.
Quand devrais-je encore utiliser une API de scraping de SERP ?
Utilisez une API SERP quand votre pipeline a véritablement besoin de la structure de la page de résultats de Google — classements organiques exacts pour le monitoring SEO, panneaux knowledge-graph, packs local/maps, résultats shopping — ou quand vous exploitez déjà un extracteur de contenu et voulez la requête brute la moins chère. Pour ancrer une réponse de LLM, une API d'agentic search qui renvoie un texte propre supprime toute une étape de nettoyage.
L'agentic search coûte-t-elle plus cher que le scraping de SERP ?
Par requête brute, le scraping de SERP est généralement moins cher (Serper est d'environ $0.30–$1 pour 1 000). Les API d'agentic search facturent plus cher par appel (~$5–$16 pour 1 000) parce qu'elles nettoient, classent et mettent en forme le texte aussi — un travail que vous paieriez sinon dans votre propre étape d'extraction et en temps d'ingénierie. Une fois que vous chiffrez le pipeline complet, l'écart se resserre ; et la facturation seulement en cas de succès (p. ex. API Pick à 15 crédits par HTTP 200) supprime entièrement le coût des réessais d'agent.
APIs utilisées dans cet article
Sarah Choy est CEO d'API Pick. Elle écrit sur la création d'APIs prêtes pour la production destinées aux agents IA et aux workflows LLM.