Search as Code vs API LLM classiques : le vrai enjeu pour les entreprises

En 2026, les entreprises ne comparent plus seulement des modèles comme on compare des CPU, mais des architectures entières. L’arrivée de Search as Code chez Perplexity en 2026 change profondément la manière dont les agents IA accèdent à l’information, face aux API LLM « fixes » de type OpenAI, Google ou Anthropic.

Le choix n’est plus seulement une question de prix par million de tokens. Il oppose d’un côté des API « boîte noire », et de l’autre une architecture où la recherche devient un pipeline programmable par l’agent lui‑même. La différence se traduit en précision, en coût de contexte et en gouvernance des systèmes.

Ce comparatif décortique ce que Search as Code apporte réellement aux entreprises en 2026, face aux API LLM classiques : architecture, coûts, performances, cas d’usage, et implications pour les équipes data/IT.

Search as Code : transformer la recherche en pipeline programmable

Mini‑takeaway : Search as Code donne aux agents un contrôle ligne par ligne sur la recherche, là où les API LLM classiques restent un appel unique à un service opaque.

La notion de Search as Code (SaC) désigne chez Perplexity une architecture de recherche introduite en 2026 qui expose les composants de la recherche comme des primitives programmables dans un SDK pour développeurs.

Search as Code est décrite par Perplexity comme sa nouvelle « reference search architecture », conçue pour les agents IA.

Ce que change concrètement Search as Code

Perplexity décrit SaC comme une rupture avec le modèle de recherche classique, considéré comme un service monolithique qui renvoie une liste de résultats.

Avec Search as Code :

• Un agent ne fait plus « juste » un appel de recherche.
• Il écrit du code (Python) qui assemble un pipeline de recherche personnalisé, exécuté dans un sandbox sécurisé.
• L’architecture expose des primitives au niveau le plus granulaire possible :
• Retrieval : quoi récupérer et depuis quelles sources.
• Ranking : comment scorer et prioriser les résultats.
• Filtering : quoi filtrer ou exclure.
• Fan‑outs : comment lancer plusieurs recherches en parallèle.
• Rendering : comment structurer les informations pour le LLM.
• Verification : comment croiser et valider les résultats.

Selon la documentation de Perplexity, ce pipeline suit un flot type :

• La tâche arrive (complexe, ouverte).
• Le modèle frontier génère du code Python décrivant le pipeline de recherche.
• Ce code est exécuté dans un environnement isolé.
• L’agent compose retrieval, ranking, filtrage, rendu.
• Il ajuste le pipeline en cours d’exécution selon les résultats intermédiaires.
• Seul le « meilleur » contexte est renvoyé au modèle pour la réponse.

Perplexity présente ce mécanisme comme le moteur de son Agentic Search SDK, point d’entrée pour les développeurs qui veulent construire des agents capables de piloter la recherche finement.

Benchmarks : impact sur précision et coût de contexte

Perplexity a publié en 2025 des résultats de recherche sur cette architecture, dans un article technique décrivant « Rethinking Search as Code Generation ».

Sur un cas de test ciblé impliquant l’identification de plus de 200 vulnérabilités critiques (CVE) à partir de bulletins officiels fournisseurs :

• Le pipeline Search as Code atteint 100 % de précision sur les CVE à haut risque.
• La consommation de tokens est réduite de 85,1 % par rapport à une baseline sans SaC.

Sur une suite de benchmarks plus large, l’architecture Search as Code est annoncée comme meilleure sur 4 benchmarks sur 5 face à d’autres systèmes de recherche agentiques.

Le gain clé mis en avant est sur WANDR, un benchmark conçu pour évaluer des tâches de recherche à large périmètre, typiques de scénarios d’entreprise (recherche réglementaire, veille marché, analyses techniques complexes).

💡 À retenir : Search as Code ne promet pas seulement des réponses plus pertinentes, mais surtout moins de tokens pour alimenter le LLM, donc un impact direct sur les coûts.

API fixes de LLM : un modèle simple, mais rigide

Mini‑takeaway : les API LLM classiques restent le standard de facto en entreprise par leur simplicité de consommation, mais elles offrent peu de contrôle natif sur la recherche.

Par API fixes, on entend les API type :

• OpenAI (Chat Completions, Assistants, etc.)
• Google (Gemini API)
• Anthropic (Claude API)

Elles partagent trois caractéristiques structurantes :

• Un point d’entrée unique par modèle (par exemple gpt-4.1, claude-3.5-sonnet, gemini-3.5-flash).
• Des paramètres limités (temperature, top_p, max_tokens, outils externes…) mais pas de contrôle natif sur la logique interne de recherche.
• Une gestion de contexte principalement basée sur :
• un chunking / retrieval externe (RAG) géré côté développeur,
• des plugins / tools de recherche, mais en tant que « boîte noire ».

Les API LLM classiques ne donnent pas accès au pipeline de recherche sous‑jacent (indexation, ranking, filtrage, fan‑out), ce qui contraste fortement avec l’approche Search as Code.

Exemple : Gemini 3.5 et l’agentic computing

Google positionne Gemini 3.5 Flash comme un modèle fortement orienté agentic workflows :

• Utilisé par défaut dans l’app Gemini et dans le mode IA de Google Search.
• Exposé à travers Google Antigravity (plateforme de développement d’agents), la Gemini API et Gemini Enterprise.
• Capable de réaliser des workflows complexes avec exécution d’outils.

Sur les benchmarks, Google annonce par exemple :

• 76,2 % sur Terminal-Bench 2.1 (bench de coding / terminal).
• 1656 en score Elo sur GDPval-AA (agentic evaluation).
• 83,6 % sur MCP Atlas (benchmark d’agents multi‑tool).

Cela montre une évolution nette des LLM vers des comportements d’agents, mais la recherche reste intégrée et non programmable au niveau pipeline : le développeur ne contrôle pas retrieval, ranking et fan‑outs comme primitives.

Search as Code vs API fixes : comparatif structuré

Mini‑takeaway : Search as Code remplace le couple « LLM + RAG maison » par une stack unifiée et programmable, quand les API fixes obligent les équipes à fabriquer cette logique au‑dessus de l’API.

Pour clarifier les différences, on peut comparer une architecture basée sur Search as Code de Perplexity à une architecture basée sur API LLM classiques + RAG custom.

Important : les chiffres de prix de Perplexity Pro disponible au public sont bien connus (offre freemium + abonnement), mais les tarifs détaillés de l’API Search as Code pour entreprises ne sont pas publiés dans les sources accessibles. Les comparaisons de coût restent donc qualitatives côté SaC.

Tableau comparatif global

Comparaison sur la maîtrise des coûts

Sur le plan économique :

• Les API LLM classiques facturent au token (entrée + sortie), souvent avec plusieurs niveaux (modèle rapide vs avancé), et offrent parfois des remises volume.
• Search as Code, selon les benchmarks publiés, permet de réduire massivement le nombre de tokens nécessaires pour des tâches où la recherche est le facteur principal de coût.

Cela signifie que pour les cas d’usage dominés par la recherche plutôt que par la génération longue :

• Le coût marginal par tâche peut être fortement réduit avec SaC grâce à la réduction du contexte envoyé au LLM.
• À l’inverse, pour des usages centrés sur la génération (rédaction, code, multimodal), les API fixes restent le point de passage principal.

💡 À retenir : Search as Code ne remplace pas un LLM de génération, il optimise la couche d’accès à l’information qui nourrit ce LLM.

Coûts, pricing et modèles économiques en 2026

Mini‑takeaway : en 2026, le débat économique ne se limite plus aux prix par million de tokens, mais à la capacité à réduire la quantité de contexte nécessaire par requête.

Ce que l’on sait côté Perplexity

Les sources publiques décrivent clairement :

• Perplexity Pro côté utilisateur final comme une offre cloud freemium, donnant accès à la recherche temps réel avec citations et threads.
• Une API Platform de Perplexity, utilisée pour servir des milliers de requêtes par seconde à travers leurs applications et leur API, mais sans grille tarifaire détaillée accessible publiquement.

Pour Search as Code en particulier, la documentation se concentre sur :

• L’architecture (SaC comme reference search architecture lancée en 2026).
• Les gains de performance (100 % de précision sur un cas de CVE, –85,1 % de tokens, leadership sur certains benchmarks).

Les tarifs exacts de SaC pour entreprises ne sont pas détaillés dans les sources consultables. On peut raisonnablement en déduire que :

• Le modèle de pricing est probablement aligné sur les standards du marché (facturation à l’usage + éventuellement abonnement entreprise), mais ce n’est pas documenté publiquement dans les sources disponibles.
• L’avantage économique mis en avant repose surtout sur la réduction de tokens, pas sur un prix facial plus bas par token.

Côté API LLM fixes (OpenAI, Google, Anthropic)

Les fournisseurs de LLM publient généralement des prix :

• Par million de tokens d’entrée et de sortie.
• Par niveaux de service (hébergé cloud, déploiement dédié, offres enterprise).

En 2025‑2026, on observe :

• Une baisse régulière du coût des modèles « rapides » et de moyen niveau.
• L’arrivée de modèles « frontier » avec un prix premium, mais compensée par des performances supérieures (donc moins de tokens nécessaires pour atteindre la qualité attendue).

Cependant, pour la recherche :

• Le coût de contexte dépend énormément du design du RAG et des prompts.
• Une architecture naïve qui envoie de gros contextes à chaque requête reste très coûteuse, même si le prix nominal par million de tokens baisse.

💡 À retenir : Search as Code joue sur un levier que les API fixes exposent peu directement : comment réduire les tokens nécessaires sans perdre d’information.

Impact sur la conception d’agents IA en entreprise

Mini‑takeaway : Search as Code est une réponse aux limites des agents LLM qui surconsomment du contexte, en leur donnant plus de contrôle sur la manière dont ils trouvent et filtrent l’information.

Des agents qui écrivent leur propre pipeline de recherche

Avec SaC, un agent ne se contente pas de décider « quand » appeler la recherche, mais comment :

• Il peut par exemple :
• Lancer plusieurs branches de recherche en parallèle (fan‑outs) sur différents corpus.
• Appliquer des critères de ranking spécifiques à un métier (par exemple, priorité aux sources réglementaires officielles).
• Filtrer agressivement des documents selon la date, la source, le type de contenu.
• Vérifier une information en croisant plusieurs sources avant de la remonter au LLM.

Cela rapproche la logique de recherche de ce que ferait un analyste humain expert, mais piloté par du code généré dynamiquement.

Comparaison avec les agents des API fixes

Les grands fournisseurs de LLM avancent eux aussi sur les agents. Google, par exemple, présente Gemini 3.5 Flash comme « notre modèle d’agentic et de coding le plus puissant », avec :

• Une intégration profonde dans Google Search via des « information agents ».
• Un agent personnel (Gemini Spark) capable d’agir 24/7 dans l’écosystème Google.

Toutefois, côté développeurs entreprise :

• La logique de recherche reste encapsulée dans l’API Gemini et le moteur de recherche Google.
• Les agents peuvent utiliser des outils, mais l’architecture interne de recherche n’est pas exposée sous forme de primitives programmables comme dans SaC.

En pratique, cela signifie que :

• Les équipes doivent continuer à concevoir leur propre RAG, à choisir un moteur de recherche (Elasticsearch, OpenSearch, Azure AI Search, etc.), à définir leurs pipelines d’indexation et de ranking.
• Les agents LLM pilotent ces systèmes via des tools, mais sans contrôle direct sur ce qui se passe à l’intérieur du moteur lui‑même.

Gouvernance et traçabilité

Pour une entreprise, la gouvernance est un point clé :

• Avec Search as Code, le pipeline de recherche est du code versionné :
• traçable,
• révisable,
• auditable,
• testable.
• Avec une API fixe, la logique de recherche interne n’est pas versionnée côté client, seules les surcouches (prompts, tools, RAG) le sont.

💡 À retenir : pour les directions data/IT, SaC rapproche la recherche IA des bonnes pratiques de l’ingénierie logicielle classique (CI/CD, revue de code, tests), ce qui facilite son industrialisation.

Cas d’usage entreprise : quand Search as Code fait la différence

Mini‑takeaway : Search as Code est particulièrement pertinent là où une erreur de recherche a un coût élevé (juridique, sécurité, financier) et où le corpus est vaste et changeant.

Sécurité et gestion de vulnérabilités

Le cas de benchmark publié sur les 200+ CVE à haut risque est révélateur :

• L’objectif était d’identifier et de agréger les vulnérabilités critiques à partir de bulletins officiels de fournisseurs.
• Le pipeline SaC atteint 100 % de précision, tout en réduisant les tokens de 85,1 %.

Transposé à un environnement entreprise, cela correspond à des scénarios comme :

• Surveillance continue des bulletins de sécurité fournisseurs.
• Production automatique de rapports de vulnérabilités par produit / version.
• Alerte contextualisée aux équipes IT & sécurité.

Dans ce type de cas, une architecture « API LLM fixe + RAG » peut être suffisante, mais :

• Elle demande un travail important de design RAG.
• Elle est plus sujette à des gaspillages de tokens si le filtrage est mal optimisé.

Recherche réglementaire et conformité

Les tâches de recherche réglementaire impliquent :

• De grands volumes de textes.
• Des mises à jour fréquentes.
• Des exigences fortes de précision et traçabilité.

Search as Code permet :

• De privilégier certaines sources (journaux officiels, régulateurs) dans le ranking.
• D’implémenter des logiques de filtrage par date, juridiction, type de document.
• De vérifier systématiquement une interprétation par cross‑checking avant de la transmettre à un LLM génératif.

Knowledge management et veille stratégique

Pour des cas plus « classiques » de knowledge management :

• FAQ internes,
• documentation produits,
• bases de connaissances support,

les API LLM fixes avec un RAG bien conçu peuvent suffire. Mais dès que :

• la volumétrie explose,
• la qualité / fraîcheur des sources est très variable,
• la précision requise est élevée,

une architecture Search as Code apporte un gain de robustesse et de coût.

💡 À retenir : SaC n’est pas nécessaire pour tous les cas d’usage ; il devient décisif là où la recherche est le cœur du problème, pas la génération.

Notre avis : qui devrait basculer vers Search as Code en 2026 ?

Mini‑takeaway : en 2026, Search as Code apparaît comme un avantage compétitif structurel pour les organisations dont le métier repose sur la recherche d’information de haute précision, mais les API fixes restent la voie la plus simple pour la majorité des projets IA.

Pour qui Search as Code est un no‑brainer

Search as Code est particulièrement adapté :

• Aux entreprises dont le risque de mauvaise information est élevé :
• banques, assurances,
• santé,
• industrie réglementée,
• cybersécurité.
• Aux équipes déjà mûres sur :
• l’ingénierie de data pipelines,
• la gouvernance de code,
• la mise en place de CI/CD pour l’IA.

Ces organisations tirent un bénéfice direct de :

• La réduction des tokens nécessaires (donc des coûts opérationnels).
• La traçabilité du pipeline de recherche comme du code.
• La capacité à ajuster rapidement la logique de recherche quand la réglementation, la concurrence ou les données évoluent.

Pour qui les API fixes restent la meilleure option

Les API LLM classiques restent plus pertinentes lorsque :

• Le cœur de valeur est la génération (rédaction, code, multimodal), et non la recherche.
• L’équipe est encore en phase d’exploration, avec peu de ressources d’ingénierie data.
• Le corpus est limité, bien structuré, et les enjeux de risques sont modérés.

Les modèles comme Gemini 3.5, GPT‑4.x ou Claude 3.5 offrent des performances remarquables en :

• rédaction,
• coding,
• multimodal,
• orchestrations d’outils,

sans demander de repenser toute l’architecture de recherche.

Horizon à 6 mois : normalisation de Search as Code ?

À horizon 6 mois, deux tendances sont probables :

• Les architectures à la Search as Code devraient inspirer d’autres acteurs : la pression sur la précision et le coût de contexte va pousser les fournisseurs de LLM à exposer davantage leurs primitives de recherche.
• Les entreprises les plus avancées vont standardiser leurs pipelines de recherche comme du code : tests, monitoring, versioning et audits deviendront des exigences de base.

La question clé pour les directions produit et IT n’est donc plus seulement : « Quel modèle choisir ? », mais :

Jusqu’où êtes‑vous prêts à aller pour reprendre la main sur la recherche, et combien de votre avantage compétitif dépend de cette capacité ?

La réponse déterminera si vous devez, dès 2026, investir dans une architecture Search as Code, ou continuer à capitaliser sur des API LLM fixes enrichies de RAG maison.