openserp : une API SERP auto-hébergée qui rend le navigateur, pas la clé API

Ce que le projet remplace, et pour qui

Les API SERP commerciales facturent à la requête et couvrent inégalement les moteurs non anglophones. openserp prend le problème par l'autre bout : le README annonce une API SERP libre et open source pour Google, Yandex, Baidu, Bing, DuckDuckGo et Ecosia, sans clé API ni facturation par recherche, avec un serveur qui écoute sur localhost. Le public visé est explicite dans la description du dépôt : les outils de recherche pour LLM et agents, et le suivi de position SEO. Le cas d'usage décisif est Baidu et Yandex. Ces deux moteurs apparaissent rarement dans les offres à la requête, et quand ils y figurent, c'est avec une couverture partielle. Une équipe qui suit des positions sur le marché chinois ou russophone a donc un intérêt direct à faire tourner ce binaire elle-même. Le reste, Google et Bing, est déjà largement servi ailleurs.

Le rendu navigateur comme mécanisme central

Le point d'architecture qui explique tout le reste tient en un mot du README : browser-rendered. openserp ne consomme pas une interface documentée, il pilote un navigateur sur la page de résultats, puis normalise ce qu'il en extrait. La réponse JSON le confirme : chaque résultat porte un champ engine, un rank, un display_url, un favicon, et parfois un bloc classification avec content_type et source_hint. Le serveur va plus loin avec les clusters. Dans l'exemple du README, une requête sur bing et google renvoie un tableau clusters où chaque entrée porte un canonical_url, un engines_count, un best_rank et un score : les résultats identiques trouvés par plusieurs moteurs sont regroupés sous un identifiant commun, et les occurrences gardent le moteur et le rang d'origine. Le bloc meta est tout aussi parlant : engines_requested, engines_responded, engines_failed, took_ms. Autrement dit, l'échec partiel est un état normal du système, pas une exception. C'est la conséquence directe du rendu navigateur : une page qui change de structure ou qui bloque le client fait échouer un moteur sans faire échouer la requête.

Megasearch, mode any et extraction de page

L'endpoint principal est /mega/search. Le README donne cet exemple : curl "http://127.0.0.1:7000/mega/search?engines=bing,google&text=golang+vs+rust&extract=1&mode=any". Trois paramètres structurent le comportement. engines liste les moteurs à interroger. extract=1 déclenche l'extraction de la page cible et renvoie, en plus du résultat de recherche, un bloc extracted avec title, format, content, mode_used et fetched_at. mode=any retourne le premier moteur qui répond, ce qui est une concession assumée à la latence : vous obtenez une réponse rapide, mais vous ne savez pas à l'avance lequel des moteurs a répondu, et le champ engines_responded vous le dit après coup. Le format de sortie est configurable en JSON, Markdown, Text ou NdJSON. Le NdJSON mérite l'attention de quiconque construit un pipeline : il permet de traiter les résultats au fil de l'eau plutôt que d'attendre la fin de la collecte. Le README mentionne aussi les SERP features (résumés IA, answer boxes, people-also-ask, related searches) et la recherche d'images, mais sans détailler leur schéma, contrairement aux résultats organiques.

Mise en route : trois chemins, une seule cible

Le README propose trois modes d'installation. Par Docker, avec l'image publiée sur Docker Hub : docker run --rm -p 127.0.0.1:7000:7000 karust/openserp:latest serve -a 0.0.0.0 -p 7000. Le port est lié à 127.0.0.1 côté hôte, ce qui est le bon réflexe tant que vous n'avez pas décidé qui peut appeler l'API. Le second chemin passe par Go : go install github.com/karust/openserp@latest, puis openserp search duckduckgo "open source serp api" --format markdown. Le troisième est une compilation depuis les sources, avec go build -o openserp . suivi de ./openserp serve. Les deux sous-commandes visibles dans le matériel sont donc serve et search, et les options de serve documentées sont -a pour l'adresse d'écoute et -p pour le port. Le fichier docker-compose.yml existe puisque le README indique docker compose up, mais son contenu n'est pas fourni ici : impossible de dire quelles variables il expose. Les SDK officiels (JavaScript via npm install @openserp/sdk, Python via pip install openserp, serveur MCP via npx @openserp/mcp, nœud n8n) acceptent un baseUrl pour pointer vers votre serveur ou un apiKey pour l'offre hébergée. Le choix se fait donc à la configuration du client, pas dans le code.

Ce que le rendu navigateur coûte vraiment

Le README liste proxies, cache et resilient mode parmi les fonctionnalités, sans détailler leur configuration. C'est une omission gênante, parce que c'est précisément là que se joue la viabilité en production. Un serveur qui rend des pages de résultats dans un navigateur consomme beaucoup plus de mémoire et de CPU qu'un client HTTP qui interroge une API. Le champ took_ms de l'exemple indique 720 millisecondes pour une requête sur deux moteurs, mais il s'agit d'une réponse unique dans une documentation, pas d'une mesure de charge. Aucun débit, aucune consommation mémoire et aucun taux d'échec ne sont publiés dans le matériel fourni. Le mode résilient existe justement parce que les moteurs se défendent : CAPTCHA, limitation par adresse IP, redirections. Si vous lancez openserp depuis une IP de datacenter sans proxy, attendez-vous à des engines_failed fréquents. La documentation ne dit pas non plus comment le cache se configure ni quelle est sa durée de vie. Ce sont des questions à trancher avant de mettre le service derrière un agent qui appellerait l'API en boucle.

La limite juridique et le mauvais outil

Le vrai point de friction n'est pas technique. openserp récupère des pages de résultats de moteurs de recherche, et les conditions d'utilisation de ces moteurs encadrent ce type de collecte. Le README ne consacre aucun passage à cette question. La licence MIT couvre le code du projet, elle ne vous autorise en rien à interroger Google, Yandex ou Baidu, et elle n'engage aucune responsabilité de l'auteur sur l'usage que vous en faites. Sur le plan pratique, openserp est le mauvais outil dans deux situations. Si vous avez besoin d'une disponibilité contractuelle et d'un support en cas de panne, une API commerciale avec engagement de service est plus adaptée, même à la requête. Si vous ne pouvez pas faire tourner un navigateur sur votre infrastructure, le projet ne vous servira à rien : c'est un composant à héberger, pas une bibliothèque à importer. Le README mentionne une version hébergée avec la même API, mais sans tarif ni conditions, donc rien ne permet de la comparer à une offre commerciale classique.

Comparer avec un client HTTP direct

L'alternative la plus proche n'est pas une API commerciale, c'est une bibliothèque de scraping de SERP en Python qui interroge les moteurs en HTTP et analyse le HTML. La différence d'approche est nette. Un client HTTP est léger, rapide à démarrer, et se débrouille bien sur des pages simples. Il casse dès que le moteur sert une page construite côté client ou déclenche une vérification anti-robot, parce qu'il n'exécute pas de JavaScript. openserp choisit l'inverse : un processus serveur avec navigateur, plus lourd, mais capable de rendre la page et de laisser le moteur se croire face à un vrai client. Le second point de divergence est le contrat. Un script de scraping vous rend ce que vous parsez ; openserp vous rend un schéma JSON stable, identique pour les six moteurs, avec pagination, clusters et métadonnées d'échec. C'est ce schéma qui justifie de faire tourner un serveur plutôt qu'un script, surtout si plusieurs services chez vous doivent consommer la même recherche.

Maintenance, licence et rythme de publication

Le dépôt n'est pas archivé et le dernier push est daté du 22 juillet 2026. Les releases fournies montrent v0.8.3 le 12 juin 2026, v0.8.6 le 29 juin, v0.8.12 le 22 juillet, ce qui donne une cadence d'environ deux à trois publications par mois sur cette période. Un rythme soutenu sur une version 0.8.x signifie aussi que l'API n'est pas figée : les numéros restent en dessous de 1.0, et rien dans le matériel ne décrit de politique de compatibilité entre versions. Si vous construisez un pipeline sur le schéma JSON actuel, prévoyez de tester chaque montée de version plutôt que de suivre le tag latest en aveugle. La licence MIT est permissive : usage commercial, modification et redistribution sont autorisés, avec conservation du texte de licence. Elle ne dit rien de la responsabilité en cas de blocage par un moteur ni de la légalité de la collecte, deux points que vous devez trancher vous-même.

Conclusion éditoriale

openserp convient à qui doit interroger Yandex, Baidu ou Ecosia dans un pipeline automatisé et accepte d'exploiter un serveur avec navigateur. Ceux qui veulent une garantie contractuelle de disponibilité sur Google doivent passer leur chemin et regarder du côté d'une API commerciale. Avant de vous engager, vérifiez trois choses dans le dépôt : le contenu de docker-compose.yml, la présence d'une configuration de proxy dans les options de la commande serve, et le rythme réel des releases entre v0.8.3 et v0.8.12.

Sources officielles

1. karust/openserp on GitHub
2. License: MIT
3. Project website
4. README
5. Releases