SearXNG + Crawl4AI : pourquoi nous avons viré SerpAPI

La facture de 847 euros qui nous a forcés à tout repenser

En mars 2024, nous avons payé 847 euros pour SerpAPI et Firecrawl réunis. Pour des requêtes de recherche et du crawling structuré. Deux services que nous avions intégrés dans quatre workflows n8n pour collecter de la matière destinée à des briefs de contenu et à des analyses de marché. La facture est arrivée, nous avons hoché la tête, payé, puis quelqu'un a demandé : « Au fait, pourquoi on ne l'héberge pas nous-mêmes ? »

Trois semaines plus tard, SearXNG et Crawl4AI tournaient sur notre propre infrastructure. Les deux flux de sourcing, l'un pour la recherche de sujets, l'autre pour la veille concurrentielle, puisent désormais leurs données dans notre propre stack. La facture mensuelle pour ces deux services : zéro. La leçon : l'auto-hébergement n'est pas toujours la réponse, mais quand tu fais le même appel d'API 40 000 fois par mois, ça devient vite rentable.

Architecture : deux outils, un objectif

Notre setup se compose de deux briques qui travaillent l'une après l'autre. SearXNG est un métamoteur de recherche qui agrège les résultats de Google, Bing, DuckDuckGo et d'autres, sans que nous ayons besoin d'une clé d'API distincte pour chaque fournisseur. Nous exploitons une instance sur un serveur dédié, accessible uniquement aux workflows internes. Les requêtes partent de workflows n8n déclenchés soit manuellement, soit par des exécutions planifiées.

Crawl4AI prend en charge la deuxième étape : le scraping structuré des URL fournies par SearXNG. La bibliothèque extrait le texte, les métadonnées et, si on le souhaite, des données structurées via un parsing assisté par LLM. Nous utilisons surtout l'export Markdown, parce qu'il s'injecte directement dans nos modèles de brief. Crawl4AI tourne dans un conteneur Python que nous appelons depuis n8n via une API HTTP.

Les quatre workflows qui s'appuient sur cette stack couvrent des cas d'usage différents : recherche de sujets pour les plannings éditoriaux, analyse concurrentielle (sur quels mots-clés les concurrents se positionnent-ils ?), enrichissement de leads (informations publiques sur les entreprises cibles) et veille des tendances (de quoi parlent les médias spécialisés ?). Chaque workflow interroge d'abord SearXNG, filtre les résultats par pertinence et envoie les 10 premières URL à Crawl4AI. Les contenus extraits atterrissent dans une base de données où d'autres systèmes les reprennent pour la suite du traitement.

Pourquoi pas tout simplement Google Custom Search ?

L'API Google Custom Search aurait été moins chère que SerpAPI : 5 dollars pour 1 000 requêtes au lieu de 50. Mais elle ne renvoie que 10 résultats par requête, et tu ne peux pas filtrer par date ou par langue aussi finement que nous en avons besoin. SearXNG agrège plusieurs sources, nous donne plus de 50 résultats par requête et tourne entièrement sur notre infrastructure. Pas de rate limit, pas de vendor lock-in, pas de dépréciation d'API soudaine.

Première décision : SearXNG plutôt que les API des fournisseurs

Nous n'avons pas viré SerpAPI pour des raisons idéologiques. L'API était stable, les résultats bons, la documentation solide. Mais nous envoyions entre 35 000 et 42 000 requêtes de recherche par mois. Chez SerpAPI, cela coûte entre 400 et 600 euros selon le forfait. SearXNG ne nous coûte que la location du serveur (80 euros/mois pour une machine dédiée qui héberge aussi d'autres services internes), plus quelques heures de mise en place.

Le seuil de rentabilité a été atteint au bout de six semaines. Depuis, nous économisons chaque mois une somme à trois chiffres. Mais le vrai gain, c'est le contrôle : nous pouvons lancer autant de requêtes que nous voulons sans que personne ne durcisse les rate limits ou ne change les prix. Et nous n'envoyons aucun log à l'extérieur ; pour des recherches sensibles au regard du RGPD (par exemple quand nous collectons des données de marché pour le compte d'un client), c'est un vrai argument.

Le revers : maintenance et disponibilité

SearXNG n'est pas un SaaS. Si l'instance tombe, le pipeline s'arrête. Au cours des deux premiers mois, Google ou Bing ont bloqué temporairement l'IP de notre serveur à trois reprises, parce que le schéma des requêtes paraissait suspect. Solution : nous faisons désormais tourner plusieurs IP de sortie et nous avons mis en place du rate limiting. Avec SerpAPI, nous n'aurions pas eu à nous en occuper.

Deuxième décision : Crawl4AI plutôt que Firecrawl

Firecrawl était jusque-là notre service de scraping. Simple à intégrer, fiable, mais cher : de 0,01 à 0,03 euro par page scrapée, selon le forfait. Avec 15 000 à 20 000 pages par mois, la facture s'alourdit vite. Crawl4AI est open source, tourne en local et ne nous coûte que du temps de calcul. La bibliothèque est écrite en Python, utilise Playwright pour le rendu JavaScript et propose une intégration LLM pour le parsing structuré.

Nous avons déployé Crawl4AI comme service FastAPI, que nos workflows n8n appellent en HTTP. Une requête contient l'URL et quelques paramètres (timeout, rendu JavaScript ou non, format de sortie). La réponse est soit du Markdown, soit du JSON avec les champs extraits. Pour la plupart des cas d'usage, l'export Markdown suffit ; quand nous avons besoin de données structurées (par exemple des prix ou des coordonnées), nous envoyons la sortie Markdown à un LLM qui extrait les champs.

Ce que nous avons sous-estimé : la gestion des erreurs

Firecrawl gérait les erreurs avec élégance. Timeout ? Tu reçois un résultat partiel. Détection de bots ? Le service fait tourner automatiquement différents user agents et proxys. Crawl4AI ne fait rien de tout ça. Si une page ne charge pas, tu reçois une chaîne vide ou une erreur HTTP 500. Nous avons dû construire nous-mêmes la logique de retry, la gestion des timeouts et les stratégies de repli. Ça nous a pris deux jours et c'était pénible, mais maintenant c'est fait.

Ce qui a mal tourné : la première exécution en production

Nous avons fait tourner le système trois semaines en test avant de le passer en production. Tout semblait bon. Puis nous avons lancé la première exécution en production, 8 000 URL en quatre heures, et au bout de deux heures, le conteneur Crawl4AI était mort. Out of memory. Nous avions oublié que Playwright lance un processus de navigateur pour chaque URL, et avec 50 requêtes en parallèle, ça dévore vite 16 Go de RAM.

La solution était simple : limite de concurrence à 10, et nous avons monté un deuxième conteneur pour répartir la charge. Mais c'était un moment typique de l'auto-hébergement : avec un service SaaS, ça aurait été leur problème. Chez nous, c'était le nôtre. Nous l'avons corrigé, mais ça nous a coûté deux heures d'indisponibilité et une flopée de messages Slack.

Pas encore de chiffres (et ce n'est pas grave)

Nous ne suivons pas encore de métriques systématiques pour ce pipeline. Pas de dashboards de latence, pas de taux de réussite, pas d'analyses de coût par requête. Le système tourne depuis huit semaines et, pour l'instant, nous nous concentrons sur sa stabilité. Les analyses quantitatives viendront plus tard, sans doute au T3, quand nous aurons assez de données pour faire des comparaisons pertinentes.

Ce que nous pouvons dire sur le plan qualitatif : la qualité des résultats de SearXNG est comparable à celle de SerpAPI, parfois même meilleure, parce que nous agrégeons plusieurs sources. Crawl4AI produit un Markdown plus propre que Firecrawl, mais en contrepartie, nous devons intercepter nous-mêmes davantage de cas d'erreur. Au final : ça marche, ça fait économiser de l'argent et nous gardons le contrôle. Pour l'instant, ça nous suffit.

Où nous en sommes

L'auto-hébergement n'est pas une fin en soi. Si tu fais 500 requêtes de recherche par mois, prends SerpAPI. Si tu en fais 50 000, construis-le toi-même. Chez Blck Alpaca, nous utilisons intensivement des pipelines de recherche, pour nous-mêmes et pour des projets clients. Dans ce cas, l'effort est rentable.

La leçon la plus importante : tu échanges des coûts d'API mensuels contre un effort d'ingénierie ponctuel et une maintenance continue. Si tu n'as pas d'équipe capable de gérer des serveurs, ou si ton usage fluctue, reste sur du SaaS. Si tu traites en continu de gros volumes et que la conformité au RGPD est un argument, le passage en vaut la peine.

Nous referions la même chose. Mais la prochaine fois, nous intégrerions dès le départ des limites de concurrence et une meilleure gestion des erreurs. Et nous commencerions plus tôt à collecter des métriques, pas parce que nous en avons besoin tout de suite, mais parce qu'il est fastidieux de les ajouter après coup.

Dernière mise à jour : août 2026

Blck Alpaca est une agence d'automatisation marketing par l'IA basée à Vienne, spécialisée dans le marketing piloté par la donnée, les agents IA sur mesure et l'automatisation des workflows d'entreprise pour les entreprises de toute l'Europe.