SearXNG + Crawl4AI : pourquoi nous ne louons plus d'API

La surprise : l'auto-hébergement n'est pas forcément moins cher

Nous pensions faire des économies. Plutôt que de payer chaque mois une facture à quatre chiffres pour SerpAPI et Firecrawl, nous avons basculé notre infrastructure de recherche sur SearXNG et Crawl4AI. Les deux outils tournent sur nos propres serveurs, tous deux sont open source et aucun ne coûte un euro de licence. Le calcul semblait évident : le matériel serait amorti en trois mois, ensuite nous serions gagnants.

Spoiler : après six semaines d'exploitation, nous avons bien supprimé les factures d'API, mais le coût total n'a pas baissé. Ce que nous avons gagné est d'une autre nature : le contrôle des flux de données, la fin des limites de requêtes et la certitude qu'aucun prestataire tiers ne doublera ses prix demain ou n'arrêtera son service. Pour nos clients, qui prennent leur posture RGPD au sérieux, cela vaut plus que les euros économisés. Mais soyons honnêtes : qui ne regarde que le prix sera déçu.

Le problème : factures d'API et vendor lock-in

Nos deux workflows de sourcing, qui automatisent les études de marché et la recherche de contenu, reposaient sur deux services payants : SerpAPI pour des résultats Google structurés et Firecrawl pour un parsing HTML propre et l'extraction en Markdown. Les deux fonctionnent parfaitement, mais leur coût croît linéairement avec l'usage. À dix tâches de recherche par jour, aucun problème. À cent, ça devient cher. À trois cents, ça devient absurde.

Le deuxième problème était plus subtil : nous avions construit des workflows optimisés pour la structure de réponse de ces API. Si SerpAPI modifie un champ, quelque chose casse chez nous. Si Firecrawl introduit un nouveau palier tarifaire, nous devons choisir entre tout refaire ou payer. Nous avions des dépendances que nous ne pouvions pas contrôler.

L'architecture : deux services, un principe

Nous avons remplacé les deux services par des alternatives auto-hébergées qui font conceptuellement la même chose, mais tournent sur notre infrastructure. SearXNG est un métamoteur de recherche qui agrège les résultats de Google, Bing, DuckDuckGo et d'autres, et les renvoie en JSON. Crawl4AI est un framework Python qui charge des pages web, exécute le JavaScript et extrait des contenus structurés. Les deux parlent HTTP, les deux renvoient du JSON, les deux se branchent directement sur nos workflows.

La stratégie de déploiement était simple : Docker Compose sur un serveur dédié, un reverse proxy devant, terminé. SearXNG dispose d'une instance avec cache Redis, Crawl4AI tourne avec un backend Playwright pour le rendu JavaScript. Les deux services ne sont accessibles qu'en interne et nos workflows les appellent via des noms d'hôte internes. Pas d'endpoints publics, pas de clés d'API, pas de limites de requêtes.

L'intégration dans les flux de sourcing existants était la partie critique. Nous avons remplacé les anciens nœuds API par des nœuds HTTP Request qui interrogent nos propres services. Les structures de réponse diffèrent, nous avons donc construit une logique de mapping qui traduit le JSON de SearXNG dans le format attendu par nos nœuds en aval. Même chose pour Crawl4AI. Les workflows eux-mêmes n'ont pas eu besoin d'être refaits, seulement la couche d'adaptateurs.

Première décision : pourquoi SearXNG plutôt qu'Elasticsearch avec un crawler maison

Nous aurions aussi pu construire notre propre crawler et indexer les résultats dans Elasticsearch. Cela aurait été plus flexible, mais nous aurait plongés dans un gouffre de maintenance. SearXNG est stable depuis des années, bénéficie d'une communauté active et fournit des résultats exploitables dès l'installation. Nous voulions une infrastructure de recherche, pas faire de la recherche sur les moteurs de recherche.

Le compromis : SearXNG agrège des moteurs de recherche existants, il ne crawle pas lui-même. Nous dépendons donc toujours de Google, Bing et d'autres, simplement de manière indirecte. Si Google bloque demain tous les métamoteurs, nous aurons un problème. Mais soyons réalistes : pour nos cas d'usage, qui portent sur l'actualité, les données d'entreprises et les tendances de contenu, le risque est acceptable. Nous n'avons pas besoin de fouiller des archives de documents vieux de dix ans.

Deuxième décision : pourquoi Crawl4AI plutôt que Scrapy ou Puppeteer en direct

Crawl4AI masque les détails pénibles : pilotage du navigateur, rendu JavaScript, gestion des bannières de cookies, extraction en Markdown. Scrapy est plus puissant, mais bas niveau. Puppeteer est plus flexible, mais nous devrions décider nous-mêmes comment gérer les single-page apps, le lazy loading et les mécanismes anti-bots. Crawl4AI a déjà pris ces décisions, et elles conviennent à 80 % de nos cas.

Les 20 % restants : les sites dotés d'une protection anti-bots agressive. Crawl4AI n'intègre ni contournement de Cloudflare, ni rotation de proxys, ni résolution de CAPTCHA. Pour ces cas, nous avons une solution de repli : si Crawl4AI échoue après trois tentatives, nous envoyons l'URL vers une étape de vérification manuelle. Ce n'est pas élégant, mais c'est honnête. Nous n'avons pas de solution miracle pour les sites qui luttent activement contre le scraping.

Ce qui a mal tourné : performances et attentes erronées

La première semaine a été une douche froide. SearXNG était lent. Vraiment lent. Une requête qui prenait 200 millisecondes avec SerpAPI durait soudain trois secondes. La raison : SearXNG interroge plusieurs moteurs en amont en parallèle, attend toutes les réponses, fusionne les résultats et les met en cache. Sur le papier, c'est propre, mais très coûteux en latence. Nous avons configuré le cache Redis de façon plus agressive et réduit le nombre de sources en amont. Nous sommes maintenant sous la seconde, mais toujours plus lents que l'API.

Crawl4AI posait un autre problème : des fuites de mémoire. Après quelques centaines de crawls, le conteneur était mort. En cause : Playwright, qui ne libérait pas correctement les instances de navigateur. Nous avons mis en place une tâche cron qui redémarre le conteneur toutes les six heures. Ce n'est pas un correctif, c'est un contournement. Nous avons ouvert une issue sur le dépôt de Crawl4AI, mais d'ici là, nous faisons avec.

Les coûts : pourquoi le calcul n'a pas tenu

Nous avons sous-estimé les coûts matériels. Un serveur avec assez de RAM pour SearXNG, Crawl4AI, Redis et Playwright coûte 80 euros par mois. S'y ajoutent la supervision, les sauvegardes et le temps passé sur la mise en place, le débogage et la maintenance. Sur trois mois, cela représente au moins 15 heures d'ingénierie. Si nous les valorisons en interne à 100 euros de l'heure, nous arrivons à 1 500 euros de coûts de mise en place, plus 240 euros de frais courants sur trois mois. La facture d'API s'élevait à 400 euros par mois, soit 1 200 euros sur la même période.

À court terme, nous avons payé plus. À long terme, l'investissement sera amorti, mais seulement si nous augmentons l'usage. Le vrai gain est stratégique : plus de dépendance envers des prestataires tiers, plus de limites de requêtes, plus de hausses de prix soudaines. Pour les clients qui doivent travailler en conformité avec le RGPD et ne veulent pas envoyer de données à des services américains, c'est un argument de vente. Mais qui compare seulement les coûts sera déçu.

Où nous en sommes

L'auto-hébergement n'est pas un modèle d'économies, c'est un modèle de contrôle. Nous avons appris que le choix d'une infrastructure propre ne devrait pas être d'abord financier, mais stratégique. Si tu considères les limites de requêtes, le vendor lock-in et la souveraineté des données comme des risques, l'auto-hébergement a du sens. Si tu compares seulement la facture, reste sur les API.

Pour nous, c'était la bonne décision, car nous allons de toute façon vers davantage d'infrastructure propre. Nos clients demandent explicitement des solutions auto-hébergées, et nous pouvons désormais parler d'expérience. Nous savons où sont les pièges, ce qui est réaliste et ce qui relève de la promesse marketing. Cela vaut plus que les coûts d'API économisés.

Prochaines étapes : nous construisons un tableau de bord interne qui suit les métriques de SearXNG et de Crawl4AI. Latence, taux de réussite, taux de hit du cache. Dès que nous aurons de vrais chiffres, nous publierons un article de suivi. D'ici là, une chose est sûre : l'auto-hébergement fonctionne, mais il n'est pas gratuit.

Dernière mise à jour : septembre 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.