Newscatcher CatchAll API : j'ai testé la recherche web rappel-first pour les agents IA
J'ai soumis une question têtue à l'API CatchAll de Newscatcher : trouver tous les incendies d'entrepôts en Europe ce trimestre. Pas les dix premiers. Tous. Une API de recherche classique vous renvoie une page de liens triés et ignore discrètement la longue traîne, ce qui convient parfaitement pour « meilleure pizza à proximité » et ne sert à rien pour une tâche d'énumération. Environ 15 minutes plus tard, en mode Base, CatchAll a fait remonter des événements issus de la presse régionale et de publications spécialisées que les API basées sur le classement de notre test best-ai-search-apis-2026 n'avaient jamais surfacés. Chaque résultat est arrivé sous forme d'un objet JSON structuré, pas d'un lien. Cet écart, c'est toute l'histoire.
Voici la version courte avant d'entrer dans les détails techniques.
Points Clés
- CatchAll est une API de recherche web rappel-first : elle retourne des enregistrements d'événements structurés, pas un SERP classé.
- Newscatcher annonce 79,8 % de rappel et un F1 de 0,705 sur 32 requêtes ; la page d'accueil arrondit ce chiffre à 86 %.
- Deux modes : Lite (en quelques secondes, limité à environ 100 résultats) et Base (asynchrone, environ 15 minutes, sans limite).
- Idéal pour les tâches d'énumération (conformité, veille concurrentielle, suivi de la chaîne logistique) ; ce n'est pas un outil de suivi de positionnement SERP.
La recherche rappel-first optimise pour tout trouver, là où la recherche classement-first optimise pour ordonner le petit nombre de résultats qu'elle remonte. Gardez cette phrase en tête et le reste de cette analyse s'emboîte parfaitement.
Qu'est-ce que CatchAll ? (La recherche rappel-first, expliquée)
CatchAll est une API de recherche web rappel-first de Newscatcher : au lieu d'une liste ordonnée de liens, elle retourne un ensemble dédoublonné d'enregistrements d'événements structurés, chacun étant un objet JSON unique avec des citations sources et des entités extraites. Rappel-first signifie que l'objectif est la complétude, trouver chaque événement pertinent, et non ordonner une courte liste par pertinence.
Newscatcher formule cela avec une analogie directe : si 200 événements valides existent et que votre système en remonte 5, votre rappel est de 2,5 %. Pour « quel est le meilleur ordinateur portable », c'est suffisant. Pour « toutes les mesures réglementaires contre les fintechs européennes cette année », une réponse à 2,5 % est pire qu'inutile, car vous ne voyez pas ce qui vous manque.
C'est l'écart de catégorie que CatchAll cible, et il vaut la peine d'être compris même si vous ne vous inscrivez jamais. Le pitch YC l'appelle une « API de recherche web rappel-first », et vous pouvez lire le positionnement directement sur la page produit de l'API de recherche web CatchAll de Newscatcher. Pour être honnête : une API SERP répond à « que devrais-je lire en premier ? » ; CatchAll répond à « quelle est la liste complète ? »
Comment fonctionne CatchAll : le pipeline de récupération et de validation
CatchAll exécute un pipeline en cinq étapes : la planification des requêtes réécrit votre prompt en plusieurs angles de récupération, la récupération à grande échelle analyse plus de 50 000 pages par traitement, l'algorithme de Leiden regroupe les pages liées en événements uniques, un LLM valide chaque cluster par rapport à votre requête, et les survivants reviennent sous forme de JSON structuré. Le rappel vient de l'analyse ; la précision vient de la validation.
Détaillons rapidement chaque étape :
- Planification des requêtes. Votre requête unique devient plusieurs prompts de récupération couvrant différentes formulations et types d'événements, de sorte qu'« incendie d'entrepôt » détecte aussi « incendie dans un dépôt logistique ».
- Récupération à grande échelle. Newscatcher indique qu'un traitement extrait plus de 50 000 pages à environ 10 000 pages par minute sans limite de résultats, atteignant la presse régionale, les publications spécialisées et les dépôts réglementaires que les SERP grand public enfouissent.
- Clustering. L'algorithme de Leiden regroupe les pages densément connectées en communautés. En termes simples : 30 articles sur le même incendie de Rotterdam se condensent en un seul événement, pas en 30 lignes.
- Validation par LLM. Chaque cluster est scoré par rapport à votre requête, et ceux qui ne correspondent pas sont éliminés. Cette étape consomme de vrais appels LLM, donc dans un stack d'agents en production vous voudrez les router via une passerelle LLM pour contrôler les coûts et gérer les fallbacks.
- Sortie structurée. Un objet JSON par événement validé, avec un schéma dynamique.
Newscatcher annonce l'indexation de plus de 2 millions d'événements réels par jour, avec de nouveaux événements disponibles en quelques heures. Le document technique « The Architecture of Completeness » couvre les détails internes du Leiden et de la validation si vous voulez aller plus loin.
C'est là que mon test sur les incendies d'entrepôts s'est déroulé. J'ai lancé la requête d'énumération en mode Base, le traitement a pris environ 15 minutes, et la valeur est apparue exactement là où le pipeline le promet : sources régionales et spécialisées, regroupées en événements distincts, qu'un SERP classé aurait enfouis en bas de page ou ignorés.
Fonctionnalités principales : Monitors, Watchlists et extraction d'événements
Au-delà de la recherche ponctuelle, CatchAll propose des Monitors et des Watchlists. Les Monitors sont des relances programmées (minimum toutes les heures) qui ne retournent que les événements nouveaux et dédoublonnés depuis la dernière exécution. Les Watchlists filtrent par entité, avec un score de pertinence de 1 à 10 et une résolution d'entités qui associe la même entreprise dans différentes langues et juridictions.
Les Monitors transforment une recherche ponctuelle en veille permanente : chaque exécution ne retourne que les événements apparus depuis la dernière. C'est la différence entre « chercher sur le web aujourd'hui » et « me prévenir dès que quelque chose change ».
Un avertissement honnête sur le positionnement « API de monitoring d'événements en temps réel » : ici, « temps réel » signifie des relances toutes les heures, pas du streaming en quasi-instantané. Si vous avez besoin de notifications push à la milliseconde, ce n'est pas l'outil approprié. Pour une équipe de conformité qui vérifie deux fois par jour, toutes les heures est largement suffisant. La Company Watchlist est la fonctionnalité phare pour la veille concurrentielle, car elle résout « Acme GmbH », « Acme Inc. » et « Acme Holdings » en une seule entité suivie plutôt qu'en trois sources de bruit distinctes.
La sortie JSON structurée (avec un exemple réel)
Chaque résultat est un événement sous forme d'un objet JSON : un cluster_id, un title, un score de relevance, un tableau entities et un tableau source_citations. Pas de scraping HTML, pas de liste de liens à analyser. C'est ce qui fait de CatchAll une véritable API de recherche web structurée plutôt qu'un simple wrapper SERP.
Voici un événement tronqué de mon test sur les incendies d'entrepôts, légèrement nettoyé mais réel dans sa forme :
{
"events": [
{
"cluster_id": "evt_8f21a",
"title": "Fire at logistics warehouse near Rotterdam",
"relevance": 9,
"entities": [
{"name": "Rotterdam", "type": "location"},
{"name": "Maasvlakte", "type": "facility"}
],
"source_citations": [
{
"url": "https://...",
"publisher": "regional trade press",
"published_at": "2026-..."
}
]
}
]
}Notez que le tableau source_citations pointe vers un média commercial régional, exactement le type de source qu'une API de classement déprioritise. Comme chaque événement est déjà structuré, vous pouvez injecter directement les enregistrements validés dans un pipeline RAG ou les stocker et vectoriser dans une base de données vectorielle sans étape de scraping ou de nettoyage intermédiaire. Ce gain de temps, c'est le vrai bénéfice discret.
Comment appeler CatchAll en Python ? (Démarrage rapide)
Vous obtenez une clé API, envoyez votre requête en POST sur /v3/search avec l'en-tête x-api-token, et analysez le tableau events. C'est tout. Voici un appel Python minimal :
import requests
resp = requests.post(
"https://api.newscatcherapi.com/v3/search",
headers={"x-api-token": "YOUR_API_KEY"},
json={"query": "warehouse fires in Europe", "page_size": 10},
)
events = resp.json()["events"]
for ev in events:
print(ev["title"], "—", ev["relevance"])Conseil pratique et piège en même temps : le mode Lite répond en quelques secondes mais est limité à environ 100 résultats, tandis que le mode Base est asynchrone et prend environ 15 minutes pour un traitement complet. Pour le mode Base, vous soumettez et interrogez plutôt que de bloquer sur un seul appel, donc concevez votre agent pour envoyer et vérifier, pas pour attendre. Si vous intégrez CatchAll dans un agent, vous l'appellerez typiquement comme outil via le function calling. Vérifiez les paramètres de requête exacts et l'indicateur Lite vs. Base dans la documentation CatchAll avant de déployer ; l'en-tête d'authentification est x-api-token.
Quel est le prix de CatchAll ? Y a-t-il un niveau gratuit ?
La tarification est à l'usage, au tarif d'environ 0,10 $ par enregistrement validé, et zéro résultat signifie zéro facturation. Il existe un niveau gratuit d'environ 2 000 crédits à l'inscription plus une dizaine de recherches par mois, sans carte bancaire requise, ce qui vous permet de mener un vrai test d'énumération avant de vous engager.
Ce modèle zéro résultat = zéro facturation compte pour les travaux d'énumération : une requête qui ne trouve légitimement aucun événement correspondant ne consomme pas de budget. Sur la question fréquente de savoir si l'API de recherche Google est gratuite, la recherche Google native et Bing ne fonctionnent pas ainsi. Elles retournent des liens classés, pas des événements structurés et validés, et l'API de recherche Bing est en cours de retrait, ce qui explique en partie pourquoi les index indépendants connaissent un regain d'intérêt.
Cas d'usage concrets
CatchAll convient à tout travail où manquer un seul élément constitue le mode d'échec. Le suivi de la conformité et réglementaire s'appuie sur les Monitors et leur couverture des dépôts réglementaires. La veille concurrentielle repose sur la Company Watchlist. Le monitoring de la chaîne logistique reprend le schéma des incendies d'entrepôts, en surveillant les événements perturbateurs. La recherche de marché utilise l'énumération sur la presse spécialisée.
Le fil conducteur entre ces quatre cas : vous construisez une liste complète, puis vous agissez sur cette base, souvent dans un workflow automatisé d'API de recherche web pour agents IA. Quelques formes concrètes :
- Conformité : Monitor permanent sur les mesures d'application dans votre secteur, toutes les heures.
- Veille concurrentielle : Watchlist sur trois entités concurrentes, résolues selon leurs noms légaux.
- Chaîne logistique : énumération des événements perturbateurs (incendies, grèves, rappels) à proximité de vos fournisseurs.
- Recherche de marché : analyse ponctuelle en mode Base de tous les lancements de produits dans un créneau ce trimestre.
Les benchmarks : CatchAll est-il vraiment 3x meilleur qu'Exa ?
Dans son propre benchmark de mars 2026 portant sur 32 requêtes, Newscatcher annonce pour CatchAll un F1 de 0,705 et un rappel de 79,8 % (4 807 événements), gagnant 27 des 32 requêtes face à Exa Websets, Parallel AI FindAll et OpenAI Deep Research. Newscatcher décrit cela comme environ 3x plus d'événements pertinents que les autres outils. Tous ces chiffres sont ceux du vendeur.
| Outil (test Newscatcher mars 2026, 32 requêtes) | F1 | Rappel |
|---|---|---|
| CatchAll | 0,705 | 79,8 % (4 807 événements) |
| Exa Websets | 0,317 | 19,6 % |
| Parallel AI FindAll | 0,103 | 5,5 % |
| OpenAI o3 / Deep Research | 0,017 | 0,9 % |
Maintenant, la partie honnête. Le benchmark rigoureux de Newscatcher indique 79,8 % de rappel ; la page d'accueil arrondit à 86 %. Nous citons le chiffre le plus bas. Le 79,8 % provient du tableau produit détaillé à 32 requêtes avec date, tandis que le 86 % est une affirmation plus arrondie d'une autre coupe sur la page d'accueil et un article de blog. Les deux sont de Newscatcher. Je préfère le plus bas car citer le chiffre interne plus conservateur du vendeur est un acte de confiance qu'une page marketing ne peut pas se permettre. Dans tous les cas, la conclusion directionnelle s'est confirmée dans mes tests : le rappel est réellement supérieur à celui des outils basés sur le classement. Pour comparer CatchAll avec 12 autres API de recherche IA, consultez notre comparatif des meilleures API de recherche IA, et vérifiez le tableau brut vous-même sur la page produit de Newscatcher.
Limites honnêtes : ce que CatchAll n'est PAS
CatchAll a quatre vraies limites que les pages marketing passent sous silence, et vous devriez les peser avant de construire. Ce n'est pas un outil à faible latence, pas illimité dans son mode rapide, pas encore plug-and-play pour les agents, et pas un outil de suivi de positionnement. Aucune n'est rédhibitoire, mais chacune exclut un cas d'usage.
- Le mode Base est asynchrone (environ 15 minutes par traitement). Mauvais outil pour un chatbot qui doit répondre en deux secondes.
- Le mode Lite est limité à environ 100 résultats. Vous voulez un rappel profond et rapide ? Vous ne pouvez pas avoir les deux ; le rappel profond paie le prix de la latence.
- Pas encore de serveur MCP officiel. Vous encapsulez vous-même le point de terminaison REST. Si vous voulez l'utiliser comme outil agent natif, vous devrez encapsuler le point de terminaison REST comme serveur MCP, de la même façon que nous construisons les serveurs MCP que nous utilisons déjà.
- Ce n'est pas un outil SERP ni de suivi de positionnement. Il ne vous dira pas où vous vous classez sur Google. C'est un travail entièrement différent.
Cette section est la partie qu'aucune page officielle n'écrira pour vous. Si la latence asynchrone ou l'absence de serveur MCP tue votre cas d'usage, mieux vaut l'apprendre ici qu'après l'intégration.
Alternatives à CatchAll et quand les choisir
CatchAll gagne en rappel brut pour l'énumération, mais ce n'est pas le bon choix pour toutes les tâches de recherche. Voici sept vraies alternatives, chacune avec la condition honnête « choisissez plutôt ceci ». Pas de strawmen.
| Outil | Positionnement en une ligne | Choisissez plutôt si... |
|---|---|---|
| Exa / Exa Websets | Recherche neurale/sémantique plus Websets énumérés | Vous voulez la découverte sémantique et la pertinence style embeddings plutôt que le rappel brut, avec des résultats plus petits et plus rapides. |
| Parallel AI (FindAll) | API d'énumération/recherche agentique | Vous êtes déjà dans l'environnement Parallel et voulez leur primitif de recherche orienté tâches. |
| OpenAI Deep Research | Recherche web multi-étapes pilotée par LLM | Vous voulez un agent de recherche clé en main dans le stack OpenAI et pouvez tolérer un échantillonnage plutôt qu'un rappel exhaustif. |
| Tavily | Recherche façon citations conçue pour RAG/LangChain | Vous voulez la recherche RAG temps réel la plus simple avec extraction en un appel et intégrations natives aux frameworks. |
| Brave Search API | Index indépendant, confidentialité, SERP rapide | Vous avez besoin d'indépendance vis-à-vis du fournisseur, d'une faible latence, et une page de résultats classés vous convient. |
| SerpAPI / Serper | Scraping SERP Google/multi-moteur | Vous avez besoin du suivi de positionnement SEO, des fonctionnalités SERP, ou de reproduire exactement ce que Google affiche. |
| Linkup | Recherche axée sur les sources européennes/éditeurs | Votre cas d'usage concerne la couverture des éditeurs européens et la provenance des sources sous licence. |
L'heuristique rapide : l'énumération et le monitoring pointent vers CatchAll, le RAG conversationnel vers Tavily, la découverte sémantique vers Exa, et le suivi de positionnement vers SerpAPI.
Comment Techsy utilise la recherche rappel-first dans ses développements d'agents
Chez Techsy, nous déployons des agents IA pour des clients B2B, et la recherche rappel-first s'intègre proprement pour les travaux d'énumération et de monitoring : pensez à un agent de conformité qui a besoin de la liste complète des mesures d'application, pas les cinq premières. Nous opterons pour une API rappel-first comme CatchAll dans ce cas, et honnêtement pour Tavily ou Exa quand la tâche est du RAG conversationnel ou une recherche sémantique. Choisir la mauvaise primitive de recherche est l'une des erreurs les plus courantes que nous corrigeons dans les développements d'agents. Vous voulez un coup de main pour choisir ? Obtenez une consultation gratuite.
À Propos de l'Auteur
Mert Batur est co-fondateur de Techsy.io, où l'équipe déploie des agents IA, des systèmes d'automatisation et des pipelines voix/SDR pour des clients B2B. Il écrit sur le stack d'outillage LLM que l'équipe Techsy utilise réellement en production. Connectez-vous sur LinkedIn.
Foire Aux Questions
Qu'est-ce que l'API CatchAll de Newscatcher ?
CatchAll est une API de recherche web rappel-first de Newscatcher. Au lieu d'une liste classée de liens, elle retourne des enregistrements d'événements structurés, un objet JSON par événement réel, chacun avec des citations sources et des entités extraites. Elle est conçue pour les agents IA, la recherche en entreprise et les tâches de monitoring où trouver chaque événement pertinent compte plus qu'ordonner une courte liste.
En quoi CatchAll diffère-t-il d'une API de recherche classique (SERP) ?
Une API SERP classe et retourne les quelques premiers liens, optimisant pour « que devrais-je lire en premier ». CatchAll optimise pour la complétude, en analysant plus de 50 000 pages par traitement et en les regroupant en événements structurés dédoublonnés. Vous obtenez un objet par événement avec des citations et des entités, pas une page de résultats HTML à scraper et analyser vous-même.
CatchAll est-il vraiment 3x meilleur qu'Exa Websets ?
Newscatcher le rapporte dans son propre test de mars 2026 portant sur 32 requêtes : CatchAll à 79,8 % de rappel et F1 0,705 contre Exa Websets à 19,6 %, gagnant 27 des 32 requêtes, ce qu'ils formulent comme environ 3x plus d'événements pertinents. Notez que la page d'accueil arrondit le rappel à 86 % à partir d'une autre coupe. Tous les chiffres sont ceux du vendeur ; traitez-les comme attribués, pas vérifiés de manière indépendante.
Quel est le prix de CatchAll ? Y a-t-il un niveau gratuit ?
La tarification est à l'usage, environ 0,10 $ par enregistrement validé, sans frais quand une requête ne retourne aucun résultat. Le niveau gratuit offre environ 2 000 crédits à l'inscription plus une dizaine de recherches par mois, sans carte bancaire. C'est suffisant pour mener un vrai test d'énumération sur votre propre cas d'usage avant d'engager un budget.
Quelle est la vitesse de CatchAll ?
Cela dépend du mode. Lite répond en quelques secondes mais est limité à environ 100 résultats. Base est asynchrone et prend environ 15 minutes par traitement, sans limite de résultats, pour une énumération profonde. Pour les traitements Base, vous soumettez et interrogez plutôt que de bloquer sur un appel, donc c'est le mauvais outil pour tout ce qui nécessite une réponse en quasi-instantané comme un chatbot en direct.
CatchAll dispose-t-il d'un serveur MCP ?
Pas encore de serveur officiel. Pour l'utiliser aujourd'hui comme outil agent natif, vous encapsulez vous-même le point de terminaison REST, le même schéma décrit dans notre guide MCP. C'est un wrapper léger autour d'un simple POST vers /v3/search, donc construire un petit serveur MCP autour de lui est simple si votre stack parle déjà le protocole.
Que sont les Monitors et les Watchlists ?
Les Monitors sont des relances programmées, au minimum toutes les heures, qui ne retournent que les nouveaux événements dédoublonnés depuis la dernière exécution, transformant une recherche ponctuelle en veille permanente. Les Watchlists filtrent les résultats par entité avec un score de pertinence de 1 à 10 et résolvent la même entreprise dans différentes langues et juridictions. Ensemble, ils couvrent le suivi de la conformité et la veille concurrentielle sans ré-interroger le web entier à chaque fois.
Puis-je utiliser CatchAll pour le suivi de positionnement SEO ?
Non. CatchAll retourne des événements structurés validés, pas des classements dans les moteurs de recherche, donc il ne vous dira pas où se situe votre page sur Google. Pour le suivi de positionnement, les fonctionnalités SERP ou reproduire exactement ce que Google affiche, utilisez plutôt SerpAPI ou Serper. CatchAll et les outils de suivi de positionnement résolvent des problèmes réellement distincts malgré le fait que les deux touchent à la « recherche web ».
Quels cas d'usage conviennent le mieux à CatchAll ?
Les tâches d'énumération et de monitoring où la complétude compte : suivi de la conformité et réglementaire, veille concurrentielle, monitoring des perturbations de la chaîne logistique, et recherche de marché sur la presse spécialisée. Le fil conducteur : manquer un seul événement pertinent est le mode d'échec, ce qui est exactement ce que la recherche rappel-first est conçue à prévenir. Pour le RAG conversationnel ou la recherche sémantique, un outil classement-first convient mieux.
En résumé : rappel-first n'est pas classé, et c'est bien le but. CatchAll échange la latence contre la complétude, et pour les tâches d'énumération c'est le bon échange. Lancez le niveau gratuit sur votre requête la plus difficile avant de décider, car vous pouvez essayer le niveau gratuit de CatchAll sans carte bancaire. Si l'attente asynchrone ou l'absence de serveur MCP est rédhibitoire, une alternative du tableau ci-dessus vous servira mieux.