La recherche web pour les agents IA après Bing : quelles options restent en 2026 ?
Les Bing Search APIs ont été retirées en août 2025 et Google Custom Search est fermé aux nouveaux clients. Il reste quatre types de backend de recherche pour les agents.
Pendant des années, la réponse par défaut à « comment mon agent cherche-t-il sur le web » était une clé Bing. Cette réponse n’existe plus, et le second choix évident, chez Google, est en train de fermer lui aussi. Il reste un ensemble de backends qui diffèrent sur trois points : qui décide du nombre de recherches lancées, quel index répond, et comment arrive la facture.
Qu’est-il arrivé à la Bing Search API ?
La page de cycle de vie de Microsoft indique que « Bing Search APIs will be retired on August 11, 2025 », que les instances existantes « will be decommissioned completely », et que le produit n’est plus ouvert aux nouvelles inscriptions (consulté le 19 octobre 2026 sur learn.microsoft.com).
La migration suggérée est Grounding with Bing Search, dans le cadre d’Azure AI Agents. C’est un produit d’une tout autre forme : au lieu que votre code appelle un endpoint de recherche et récupère du JSON, un agent hébergé sur Azure intègre les données web pendant que le modèle génère sa réponse. Si vous avez construit votre propre boucle d’agent sur un autre modèle ou un autre framework, il n’y a pas d’endpoint de résultats bruts à substituer.
Google Custom Search est-il encore une option ?
Seulement si vous l’avez déjà. Au 19 octobre 2026, la présentation de la Custom Search JSON API indique que l’API est « closed to new customers » et que « existing Custom Search JSON API customers have until January 1, 2027 to transition to an alternative solution ». Ses tarifs (100 requêtes gratuites par jour, puis 5 $ pour 1 000, jusqu’à 10 000 par jour) ne s’appliquent qu’à ces clients existants.
Nous avons comparé en détail Custom Search et les API SERP dans l’API de recherche officielle de Google face aux API SERP, nous ne le répéterons donc pas ici. Pour un nouveau projet d’agent, le point pratique est qu’aucune des deux API de recherche officielles ne vous est ouverte.
Quels types de backend de recherche restent pour un agent ?
1. L’outil de recherche intégré du fournisseur de modèle. Vous ajoutez un outil à l’appel du modèle et le fournisseur lance les recherches. L’outil de recherche web d’Anthropic coûte « 10 $ pour 1 000 recherches, plus les coûts de tokens standards pour le contenu généré par la recherche », et un paramètre max_uses plafonne les recherches par requête (documentation Anthropic). OpenAI affiche la recherche web à « 10,00 $ / 1k appels + tokens de contenu de recherche facturés aux tarifs du modèle », l’outil en preview sur les modèles sans raisonnement étant à 25,00 $ pour 1 000 (tarifs OpenAI). Les deux consultés le 19 octobre 2026. Le modèle décide quand chercher, et le coût atterrit dans la facture du modèle, les résultats étant comptés comme des tokens d’entrée.
2. Les API SERP. Votre code envoie une requête et récupère la page de résultats Google en JSON : résultats organiques, recherches associées, parfois People Also Ask. Vous choisissez chaque requête, et les résultats sont ceux que Google lui-même a renvoyés.
3. Les index de recherche natifs IA. Des entreprises qui explorent et indexent le web elles-mêmes et renvoient des résultats taillés pour les LLM, souvent accompagnés du texte des pages ou de passages extraits. Vous obtenez un seul appel qui en fait plus, classé selon leur index plutôt que celui de Google.
4. Les serveurs MCP qui regroupent recherche et lecture de pages. N’importe laquelle des options ci-dessus, exposée sous forme d’outils MCP, pour qu’un agent dans Claude, Cursor ou votre propre client puisse chercher puis ouvrir les pages qu’il a choisies, sans que vous écriviez de code de liaison.
Comment les options se comparent-elles ?
| Outil intégré au modèle | API SERP | Index natif IA | MCP recherche + lecture | |
|---|---|---|---|---|
| Qui choisit le nombre de requêtes | Le modèle, plafonné par max_uses |
Votre code | Votre code | L’agent, à chaque appel d’outil |
| Index | Au choix du fournisseur | Résultats Google | Leur propre index | Dépend du serveur |
| Prévisibilité du coût | Par recherche, plus les tokens des résultats | Prix fixe par appel | Fixe par appel, varie selon la profondeur | Fixe par appel |
| Peut aussi lire les pages complètes | Outil fetch séparé | Généralement un produit séparé | Souvent inclus | Oui, par conception |
| Mode de paiement | Votre compte API du modèle | Clé, souvent prépayée ou mensuelle | Clé, généralement mensuelle | Le même que l’API du serveur |
La ligne qui compte le plus pour les agents est la première. Avec un outil intégré, une question difficile peut se transformer en dix recherches à l’intérieur d’une seule requête, chacune ramenant ses résultats dans le contexte. Avec une API que vous appelez vous-même, chaque recherche est une ligne de votre propre code et un prix fixe, et c’est ce qui rend possible un plafond de dépense strict.
Où se situe FastAF ?
FastAF relève des catégories 2 et 4. /v1/serp renvoie les résultats Google pour 5 crédits, soit de 1,33 $ à 2,50 $ pour 1 000 recherches selon le pack prépayé, avec des crédits valables 12 mois et sans abonnement. La même clé couvre Google News, Google Scholar et Google AI Mode, et lit les pages via /v1/scrape à 1 crédit. Nous ne sommes pas un index natif IA : les résultats sont ceux de Google.
Voici la boucle dont la plupart des agents ont besoin, chercher puis lire, exécutée le 19 octobre 2026 :
import os, time, requests
API = "https://api.fastaf.co/v1"
HEADERS = {"Authorization": f"Bearer {os.environ['FASTAF_API_KEY']}"}
def call(endpoint, **params):
t = time.time()
r = requests.get(f"{API}/{endpoint}", params=params, headers=HEADERS, timeout=120)
r.raise_for_status()
print(f"{endpoint}: {r.headers['X-FastAF-Credits-Used']} credits, {time.time() - t:.1f}s")
return r
# 1. Chercher sur Google, garder ce dont le modèle a besoin pour choisir un lien
hits = call("serp", query="bing search api retirement", country="us").json()["organic_results"]
for h in hits[:5]:
print(h["rank"], h["title"], h["link"])
# 2. Lire la page choisie par le modèle, avec la même clé
page = call("scrape", url=hits[0]["link"]).text
print(len(page), "characters of page")La recherche a pris 4,5 secondes et 5 crédits ; le premier résultat était l’avis de retrait de Microsoft lui-même. Sa lecture a pris 0,7 seconde, 1 crédit, et a renvoyé 47 352 caractères.
Trois autres appels le même jour, chacun facturé comme indiqué :
- serp pour « bing search api retirement alternatives » : 10 résultats organiques (titre, lien, snippet, rang) et 8 recherches associées, 5 crédits, 3,3 s.
- news pour « AI agents web search » : 10 articles avec source, date relative (« 1 day ago ») et URL, 5 crédits, 8,1 s.
- ai (Google AI Mode) pour « what replaced the bing search api for ai agents » : 7 blocs de texte avec citations intégrées, 4 références et une réponse markdown de 3 772 caractères, 10 crédits, 4,8 s.
Pour les agents dans un client MCP, le serveur MCP hébergé expose les mêmes appels sous forme de 15 outils, dont search_web, search_news, ask_google_ai et scrape_page, et chaque résultat d’outil indique les crédits utilisés et restants. Pour les agents sans aucun compte, x402 facture à l’appel en USDC sur Base, 0,005 $ par recherche, réglé uniquement quand l’appel aboutit. La latence de chaque endpoint figure sur la page benchmarks.
En bref
L’API de Bing est retirée et Custom Search de Google est fermé aux nouveaux clients : un nouvel agent choisit donc entre l’outil de recherche intégré d’un modèle, une API SERP, un index natif IA ou un serveur MCP qui cherche et lit. Si vous voulez des résultats Google, un prix fixe par appel et que votre code décide du nombre de recherches lancées, une API SERP est ce qui se rapproche le plus de ce que faisait la clé Bing. Vous pouvez créer un compte gratuit avec 500 crédits, soit environ 100 recherches, sans carte.