DeepSeek Search et Fetch fixent l’accès au web en direct à 0,75 $

DeepSeek a ouvert ses API Search et Fetch à 0,75 $ pour 1 000 requêtes réussies, fixant un tarif remarquablement bas pour l’accès au web en direct des agents d’IA. La sortie de DeepSeek Search et Fetch sépare la récupération web de l’inférence du modèle, afin que les développeurs puissent rechercher ou extraire des pages via deux endpoints JSON bruts.

Cela modifie l’économie des agents de recherche, des assistants de programmation et de la génération augmentée par récupération, ou RAG, qui fournit à un modèle des informations externes au moment de l’exécution. La recherche est souvent considérée comme une fonctionnalité secondaire. Dans un agent de production, toutefois, les recherches répétées et la récupération de pages peuvent devenir une dépense d’infrastructure distincte.

Le faible tarif affiché a immédiatement attiré l’attention. Pourtant, la compétition la plus importante n’oppose pas DeepSeek à un seul fournisseur de recherche. Elle oppose une récupération peu coûteuse à une récupération fiable. Les développeurs ont encore besoin de preuves que DeepSeek peut renvoyer des sources pertinentes, extraire des pages difficiles, protéger les requêtes sensibles et soutenir un trafic de production.

La comparaison s’étend également aux plateformes de modèles intégrées. OpenAI facture séparément les appels de recherche web et les entrées de modèle associées, tandis que des fournisseurs spécialisés vendent la recherche, l’extraction ou la recherche approfondie en tant que services indépendants. DeepSeek parie qu’une interface simple et un prix agressif par requête peuvent faire de l’accès au web une primitive courante des agents.

DeepSeek Search et Fetch répartissent la récupération entre deux API

DeepSeek a transformé deux actions courantes des agents en services facturables indépendamment : trouver des pages et les lire.

Le guide Search et Fetch documente deux endpoints sous le domaine API existant de l’entreprise. Search accepte une requête et renvoie des résultats structurés. Fetch accepte une URL et renvoie le titre et le contenu de la page en Markdown.

L’endpoint Search peut renvoyer entre un et 50 résultats. Sa réponse comprend le titre, l’URL, un extrait, un résumé plus long, la date de publication lorsqu’elle est disponible et un score d’autorité. DeepSeek indique que les scores de trois ou quatre identifient des sources très fiables, tandis que moins un signifie que l’autorité est inconnue.

Les développeurs peuvent également demander le contenu complet de la page avec chaque résultat de recherche. L’option need_content permet cette opération dans l’appel de recherche, bien que le contenu reste vide lorsque la récupération échoue. Cette conception peut réduire le travail d’orchestration des agents qui ont besoin à la fois de découverte et de texte lisible.

La syntaxe des requêtes prend en charge les expressions exactes, les exclusions, les restrictions linguistiques, les limites de date et les filtres de sites. Un développeur peut limiter les résultats à certains domaines ou exclure une source sans créer un traducteur de requêtes distinct. La question initiale de l’utilisateur peut aussi accompagner la phrase de recherche pour aider DeepSeek à interpréter l’intention.

Fetch effectue la tâche plus ciblée. Il récupère une URL HTTP ou HTTPS et convertit le contenu extractible en Markdown, un format texte brut qui préserve les titres et les liens. Cette sortie est plus facile à transmettre à un modèle de langage qu’un document HTML non traité.

Les deux services utilisent l’authentification bearer et des requêtes JSON ordinaires. Ils ne sont pas limités à un kit de développement logiciel propriétaire. Une application peut les appeler depuis un outil de fonction, un moteur de workflow, un agent en ligne de commande ou un backend personnalisé.

Cette séparation est importante, car la recherche et l’extraction échouent de façons différentes. La recherche peut ne renvoyer aucun résultat pertinent, tandis que Fetch peut rencontrer un domaine bloqué, un format non pris en charge ou une page sans contenu exploitable. Garder les opérations distinctes permet aux développeurs de réessayer, remplacer ou mettre en cache l’une ou l’autre étape.

DeepSeek répertorie des codes d’erreur explicites pour les entrées non valides, un solde de compte insuffisant, un rejet de sécurité, un contenu indisponible, les limites de débit et les délais d’attente en aval. L’entreprise recommande de réessayer en cas de délai d’attente, de limite de débit ou d’erreur serveur, mais pas pour les autres erreurs client sans modifier la requête.

Le service est en lecture seule. Il peut découvrir et récupérer du contenu, mais il ne clique pas sur des boutons, ne soumet pas de formulaires et n’exploite pas de session de navigateur. Les équipes ont toujours besoin d’une couche d’automatisation de navigateur pour les sites web interactifs, les ressources authentifiées ou les applications qui affichent des informations importantes après des actions de l’utilisateur.

Les requêtes Search sont limitées à 100 requêtes par seconde au niveau du compte. Fetch a une limite distincte de 25 requêtes par seconde ainsi qu’une restriction supplémentaire par domaine. Des quotas séparés empêchent une pointe de travail d’extraction de consommer toute la capacité de recherche.

Ces détails font de cette sortie davantage qu’une fonctionnalité de modèle. DeepSeek propose une infrastructure de récupération qui peut se placer à côté de ses modèles ou au sein d’un système d’agents plus large. La question suivante est de savoir comment la règle de facturation modifie la conception des applications.

Le tarif de 0,75 $ récompense les récupérations réussies

DeepSeek facture les réponses exploitables plutôt que chaque tentative, ce qui transfère une partie du risque d’échec de la récupération au fournisseur.

Search coûte 0,75 $ par tranche de 1 000 requêtes réussies. Fetch applique le même tarif. DeepSeek définit une requête Search réussie comme une réponse HTTP 200 contenant un tableau de résultats non vide. Un appel Fetch devient facturable seulement lorsqu’il renvoie le contenu d’une page.

Les appels échoués, les délais d’attente et les recherches sans résultat ne sont pas facturés. Le nombre de résultats ne modifie pas le prix de la requête : demander 50 résultats entraîne donc le même coût de recherche que d’en demander un seul. Le traitement par modèle et les autres usages de l’API restent des dépenses distinctes.

Un workflow qui effectue une recherche et récupère cinq pages générerait donc six appels de récupération potentiellement facturables. Aux tarifs publiés, 1 000 workflows de ce type produiraient 6 000 appels réussis et 4,50 $ de frais de récupération. Le traitement des tokens ajouterait un autre coût.

Cette distinction évite une interprétation trompeuse du chiffre mis en avant. Le tarif annoncé ne signifie pas qu’une tâche de recherche entière coûte 0,00075 $. Un agent peut reformuler des requêtes, examiner plusieurs sources, suivre des citations et récupérer plusieurs pages avant de rédiger une réponse.

Un workflow de recherche approfondie peut produire des dizaines d’appels. Un agent autonome peut aussi répéter des recherches lorsque les sources se contredisent ou lorsqu’une requête initiale manque de résultats utiles. Le faible prix unitaire compte, mais l’orchestration détermine la facture finale.

La règle de DeepSeek offre néanmoins aux développeurs un degré utile de prévisibilité. Les frais de recherche ne changent pas selon le nombre de résultats, et les récupérations infructueuses ne consomment pas d’unités payantes. Les équipes peuvent estimer les coûts à partir des appels d’outils réussis plutôt que de modéliser un flux supplémentaire de tokens de récupération.

La sortie affecte également les intégrations de programmation et d’agents de DeepSeek. Sa documentation indique que les appels d’outils côté serveur provenant de DeepSeek Harness, Claude Code et Codex utilisent déjà les services Search et Fetch. Ces appels restent gratuits jusqu’au début de la facturation à minuit, heure de Pékin, le 1er novembre 2026.

Cette date est importante sur le plan opérationnel. Un développeur peut ne pas émettre directement une requête vers un endpoint, mais un agent peut déclencher des recherches en résolvant une tâche. Les tableaux de bord d’utilisation et les budgets doivent donc compter les appels d’outils autonomes, et non uniquement les actions explicitement initiées par une personne.

Le guide de l’API Responses de DeepSeek montre comment la recherche côté serveur peut participer à une réponse de modèle. Dans cette configuration, la plateforme exécute la récupération, ajoute les résultats au contexte du modèle et poursuit la génération. Cette commodité rend aussi la consommation de recherche moins visible au sein d’une longue session d’agent.

À titre de comparaison, la tarification actuelle de l’API OpenAI affiche la recherche web à 10 $ par tranche de 1 000 appels, les tokens de contenu de recherche étant facturés aux tarifs du modèle sélectionné. Les services ne sont pas identiques, de sorte que l’écart numérique n’établit pas une valeur équivalente.

La recherche intégrée peut inclure le classement, la gestion des sources, les citations, les contrôles de sécurité, des fonctionnalités régionales ou des optimisations propres au modèle. Les API indépendantes peuvent offrir davantage de contrôle sur la boucle de récupération. Les acheteurs doivent comparer des tâches complètes plutôt qu’une seule ligne d’une page de tarification.

L’offre de DeepSeek crée néanmoins une pression sur le bas de gamme du marché. Un développeur qui expérimente des milliers d’appels peut désormais considérer la récupération hébergée comme une faible dépense variable. Cela affaiblit l’idée que chaque équipe d’agents doit exploiter sa propre pile de scraping et de recherche pour maîtriser les coûts.

Cette évolution favorise également les architectures modulaires. Search peut servir un modèle, tandis que Fetch peut fournir du contenu à un autre. Une équipe peut conserver son choix de modèle et tester DeepSeek comme composant de récupération, même si les conditions de compte et le traitement des données exigent toujours un examen.

La recherche IA bon marché exerce une pression sur les fournisseurs intégrés et spécialisés

DeepSeek teste si la recherche doit rester une fonctionnalité d’IA haut de gamme ou devenir une infrastructure peu coûteuse.

Les applications d’IA utilisent la récupération web pour plusieurs tâches différentes. Un agent de support vérifie une documentation à jour. Un assistant de recherche trouve des éléments étayant une affirmation. Un agent de programmation lit des notes de version, des suivis de problèmes et des références de bibliothèques apparus après sa date limite d’entraînement.

Ces tâches exigent davantage qu’une page de résultats de recherche familière. L’application a besoin d’une sortie lisible par machine, de champs de réponse stables, d’une latence prévisible et d’un texte pouvant entrer dans le contexte d’un modèle. Elle a aussi besoin d’un système de facturation qui ne pénalise pas les comportements raisonnables de nouvelle tentative.

Les fournisseurs spécialisés se distinguent par la couverture de leur index, la qualité du classement, le succès de l’extraction, la fraîcheur des données et les fonctionnalités de workflow. Certains proposent le texte intégral des pages, la synthèse de réponses, des filtres de domaine ou des endpoints de recherche. D’autres mettent l’accent sur la résidence des données et les contrôles contractuels.

Les fournisseurs de modèles empruntent une voie différente. Ils peuvent intégrer la recherche dans une réponse et laisser le modèle décider du moment où l’utiliser. Cela réduit le travail d’intégration, mais peut rendre le comportement de récupération plus difficile à observer ou à transférer entre plateformes.

DeepSeek combine une partie des deux approches. Ses endpoints bruts ressemblent à une infrastructure spécialisée, tandis que ses outils côté serveur relient la récupération aux modèles DeepSeek et aux clients d’agents compatibles. Cela offre à l’entreprise deux voies d’accès à la pile d’un développeur.

Le faible tarif est le plus convaincant pour les tâches fréquentes à valeur modeste. Prenons un système interne de surveillance qui vérifie chaque heure la documentation des fournisseurs. La qualité de la recherche doit être acceptable, mais chaque requête individuelle ne justifie pas un processus de recherche coûteux.

Le calcul change pour les travaux à forts enjeux. Un workflow juridique, médical, financier ou de sécurité peut accorder une valeur bien plus élevée à une couverture fiable des sources qu’au prix de la requête. Manquer un document faisant autorité peut coûter plus cher que des milliers de recherches.

La latence compte également. Un assistant conversationnel ne peut pas s’interrompre pour une lente chaîne de recherches et de récupérations après chaque courte question. Une tâche de recherche peut tolérer davantage de temps, mais elle a toujours besoin d’une extraction réussie sur de nombreux domaines.

Les développeurs qui ont discuté de cette sortie dans le fil Hacker News ont souligné les deux aspects de ce compromis. Certains estimaient que la récupération hébergée était plus simple et plus fiable que la maintenance de scrapers. D’autres ont remis en question la couverture, la confidentialité, les limites de débit et la qualité de l’extraction.

Ces commentaires sont anecdotiques plutôt que des résultats de benchmark. Ils montrent les questions que se posent les acheteurs, mais n’établissent pas qu’un fournisseur est plus performant. Le service est trop récent pour que de nombreuses données de production puissent trancher la comparaison.

La recherche auto-hébergée reste un autre concurrent. Les systèmes de métarecherche open source peuvent agréger des moteurs publics sans frais de fournisseur par requête. Des outils d’extraction directs peuvent également convertir de nombreuses pages ordinaires en texte propre.

Cependant, l’auto-hébergement « gratuit » implique tout de même des serveurs, des proxys, des mises à jour, de l’observabilité et une réponse aux blocages. Les équipes doivent déterminer si ce travail opérationnel justifie d’éviter des frais de service hébergé. La réponse varie selon l’échelle, les effectifs et les exigences de fiabilité.

Le prix de DeepSeek réduit l’argument économique en faveur du maintien de cette infrastructure. Il n’élimine pas l’argument du contrôle. Un système exploité localement peut conserver les requêtes au sein d’une organisation et appliquer un classement personnalisé ou des listes d’autorisation.

La réponse pratique consiste à mesurer. Les équipes devraient constituer un ensemble d’évaluation fixe représentant leurs domaines et questions réels. Elles peuvent ensuite comparer la pertinence, la diversité des sources, l’exhaustivité de l’extraction, la latence et le nombre total d’appels par tâche achevée.

Une collection consultable de documents techniques internes peut compléter la récupération en direct. Les équipes ont souvent besoin à la fois de sources publiques actuelles et de contexte privé. Une base de connaissances d’ingénierie structurée peut rendre les preuves internes accessibles sans envoyer chaque question sur le web public.

Cette architecture combinée réduit également les recherches inutiles. L’agent peut d’abord consulter les documents locaux, identifier ce qui manque et réserver la récupération externe aux informations nécessitant une vérification récente.

La qualité de l’API Search de DeepSeek reste le chiffre manquant

La tarification est vérifiée, mais les éléments nécessaires pour juger la qualité de la recherche restent incomplets.

DeepSeek indique que Search fonctionne sur son moteur interne. Son schéma de réponse expose des résumés, des scores de classement, des niveaux d’autorité et, en option, le contenu des pages. Ces champs sont utiles, mais un schéma ne peut pas prouver que les résultats sous-jacents sont pertinents ou complets.

La qualité de la recherche varie selon la langue, la zone géographique, le sujet et le type de requête. Un moteur peut bien fonctionner sur des sources techniques chinoises tout en passant à côté de reportages locaux nord-américains. Il peut trouver de manière fiable la documentation officielle, mais peiner avec des forums spécialisés ou des pages récemment mises à jour.

La qualité de la récupération présente ses propres modes de défaillance. Les sites modernes peuvent nécessiter JavaScript, rejeter les clients automatisés, placer du contenu derrière une authentification ou intégrer des informations importantes dans des documents. DeepSeek précise que la récupération reste soumise à la disponibilité des sites et aux politiques d’accès.

Une réponse HTTP réussie ne garantit pas non plus des preuves utiles. Le Markdown extrait peut omettre un tableau, confondre la navigation avec le texte de l’article ou perdre les relations entre légendes et images. Les agents peuvent alors produire des réponses assurées à partir d’éléments incomplets.

La définition de la facturation d’une « requête réussie » est plus étroite que celle d’une tâche accomplie avec succès. Search devient facturable dès qu’il renvoie au moins un résultat, même si ce résultat n’est pas pertinent. Fetch devient facturable dès qu’il renvoie du contenu, même si ce contenu ne contient pas le fait recherché.

Les équipes devraient donc suivre séparément la réussite sémantique et la réussite facturable. Parmi les mesures utiles figurent la présence de la bonne source, la présence du passage ciblé dans l’extraction et la capacité de la réponse finale à citer des éléments étayant ses affirmations.

La diversité des sources constitue un autre test. Un moteur qui renvoie à répétition des copies d’un même reportage peut créer une apparence de corroboration. Une déduplication fondée uniquement sur l’URL ne détectera pas les contenus syndiqués ou réécrits.

Les développeurs doivent aussi examiner le score d’autorité. DeepSeek définit l’échelle, mais son guide public n’explique pas la méthode complète de notation. Un score élevé devrait orienter le classement, et non remplacer un jugement indépendant sur la source.

La couverture politique et régionale mérite des tests attentifs. Les moteurs de recherche font des choix concernant l’indexation, le classement, la sécurité et la conformité légale. Ces choix peuvent influencer ce qu’un agent voit avant même qu’un modèle de langage commence à raisonner.

La confidentialité pose une préoccupation distincte. Les requêtes peuvent révéler des plans de produits, des problèmes de sécurité, des noms de clients, des cibles d’acquisition ou des recherches non publiées. Les URL récupérées peuvent révéler quels documents et systèmes une organisation étudie.

La politique de confidentialité publique de DeepSeek devrait être examinée avec l’accord API avant tout déploiement sensible. Le guide Search et Fetch explique les fonctionnalités et la facturation, mais ne fournit pas d’engagement spécifique de conservation zéro des données pour ces endpoints.

Un examen des achats devrait établir quelles données de requête sont enregistrées, où elles sont traitées, combien de temps elles sont conservées et si elles peuvent servir à améliorer le service. Les engagements contractuels comptent davantage que les hypothèses tirées du faible prix.

Les équipes de sécurité devraient également examiner l’injection indirecte de prompts. Une page récupérée peut contenir du texte conçu pour manipuler un agent, demander des secrets ou rediriger son comportement. Convertir une page en Markdown ne rend pas ses instructions fiables.

Les applications doivent traiter le contenu récupéré comme des données non fiables. Les autorisations des outils doivent rester distinctes du texte des pages, et l’agent ne doit pas exécuter des instructions simplement parce qu’elles apparaissent dans une source. Les actions sensibles nécessitent des contrôles de politique explicites en dehors du plan généré par le modèle.

La mise en cache peut réduire à la fois les dépenses et l’exposition. Les pages publiques fréquemment demandées n’ont pas besoin d’être récupérées à répétition lorsque les exigences de fraîcheur permettent leur réutilisation. Un cache fournit également un enregistrement du contenu exact ayant informé une réponse antérieure.

Toutefois, la mise en cache soulève des questions de version. Les équipes doivent enregistrer l’heure de récupération, l’URL source et le hachage du contenu si elles ont besoin de résultats reproductibles. Sinon, une récupération ultérieure peut renvoyer une page modifiée qui ne soutient plus l’affirmation d’origine.

DeepSeek a rendu le coût facile à comprendre. Il n’a pas supprimé le travail d’ingénierie nécessaire pour rendre la récupération précise, sûre et vérifiable.

Comment DeepSeek Search et Fetch transforment la conception des agents

Cette sortie rend la récupération suffisamment bon marché pour être utilisée plus souvent, mais les bons agents devraient rechercher plus délibérément, et non sans discernement.

Un flux de travail solide commence par déterminer si des informations en direct sont nécessaires. Des définitions stables et des procédures internes peuvent déjà exister dans une base de connaissances fiable. Les prix actuels, les sorties, les politiques et les actualités exigent généralement une vérification externe.

L’agent peut ensuite transformer la question de l’utilisateur en un petit plan de recherche. Une requête devrait cibler la source primaire. Une autre peut rechercher des reportages indépendants ou des critiques. Les recherches supplémentaires devraient combler des lacunes précises plutôt que répéter une formulation générale.

Les opérateurs de DeepSeek prennent en charge ce modèle. Une requête peut cibler des domaines officiels, définir une fenêtre de publication ou limiter les langues. Ces contrôles aident un agent à rechercher dans un but probatoire plutôt qu’à collecter un vaste ensemble de résultats non ciblés.

Le nombre de résultats crée également une opportunité d’optimisation. Comme le tarif publié par requête ne change pas entre un et 50 résultats, un système peut demander suffisamment de candidats pour un nouveau classement. Il devrait néanmoins éviter de remplir le contexte du modèle avec chaque élément renvoyé.

Une étape de classement distincte peut sélectionner les sources selon la pertinence, l’autorité, la récence et la diversité. Fetch ne devrait ensuite récupérer que les pages susceptibles d’influencer la réponse. Cela réduit les appels d’extraction et limite le texte non fiable entrant dans le modèle.

Le flux de travail devrait préserver les citations tout au long du traitement. Les résumés sont pratiques, mais une réponse finale a besoin d’URL et de passages étayant chaque affirmation importante. Lorsque les éléments divergent, le système devrait signaler le désaccord plutôt que le fondre dans une conclusion non étayée.

Les échecs de Fetch nécessitent des nouvelles tentatives limitées. Réessayer une requête limitée en débit ou expirée a du sens après un délai. Répéter un rejet de sécurité ou une erreur de contenu non pris en charge sans modifier la requête fait perdre du temps et peut créer une boucle.

Les systèmes de production ont également besoin de budgets à plusieurs niveaux. Une limite par session empêche une requête utilisateur de déclencher des centaines de recherches. Une limite quotidienne par compte contient le trafic inattendu. Des contrôles par domaine réduisent la pression sur les sites individuels.

Les nouvelles conditions économiques pourraient encourager une récupération excessive parce que chaque appel semble presque gratuit. Ce serait une erreur. Davantage de résultats de recherche peuvent accroître la latence, les preuves dupliquées, la taille du contexte et les occasions d’injection de prompts.

Les concepteurs d’agents devraient mesurer le coût par réponse acceptée, et non le coût par appel API. Cette mesure inclut la récupération, les tokens du modèle, les nouvelles tentatives, la validation et la revue humaine. Elle reflète également si la réponse a réellement résolu le problème de l’utilisateur.

Un ensemble d’évaluation utile peut comporter quatre catégories. Les questions de fraîcheur testent les mises à jour récentes. Les questions à élément connu testent la capacité du moteur à trouver une page d’autorité spécifique. Les questions comparatives testent la diversité des sources. Les pages difficiles testent le comportement d’extraction.

Chaque test devrait enregistrer le rang de la source attendue, l’exhaustivité de l’extraction, la latence et le nombre de requêtes payantes. Les évaluateurs peuvent noter le soutien apporté par les citations et indiquer lorsqu’une réponse nécessite un autre fournisseur ou une revue manuelle.

Les endpoints bruts rendent également pratique le routage de secours. Une application peut essayer DeepSeek pour les recherches ordinaires, puis utiliser une autre source lorsque la couverture ou l’extraction échoue. Cela protège la qualité tout en préservant un coût moyen inférieur.

Cette stratégie exige une normalisation. Les fournisseurs renvoient des champs, scores, résumés et formats de date différents. Un schéma interne commun peut empêcher le reste de l’application de dépendre de la forme de réponse d’un seul fournisseur.

L’API de DeepSeek est donc facile à tester, mais pas automatiquement facile à remplacer. Les développeurs devraient isoler l’authentification, la gestion des erreurs et les champs de classement propres au fournisseur au sein d’un adaptateur. L’agent peut alors demander une « recherche » sans savoir quel service l’exécute.

Cette architecture transforme la concurrence sur les prix en avantage pour les acheteurs. Les fournisseurs doivent gagner le trafic par des performances mesurables, tandis que les équipes conservent la capacité de déplacer les charges de travail lorsque les politiques ou la qualité changent.

Trois signaux détermineront si le faible prix compte

Le prochain test consiste à savoir si DeepSeek peut convertir la curiosité des développeurs en une utilisation durable en production sans affaiblir la qualité ni la confiance.

Le premier signal est l’évaluation comparative indépendante de la récupération. Des tests utiles doivent couvrir les langues, les événements récents, la documentation technique, les informations locales et les pages adversariales. Ils devraient publier les ensembles de requêtes et les méthodes de notation, pas seulement une moyenne unique.

Si DeepSeek trouve systématiquement des sources faisant autorité et extrait un contenu complet, le faible tarif prend un poids stratégique. Si les résultats nécessitent des recherches répétées ou des fournisseurs de secours fréquents, l’avantage affiché diminuera au niveau de la tâche.

Le deuxième signal concerne la gestion des données d’entreprise. Les acheteurs ont besoin de réponses claires sur la conservation des requêtes, les lieux de traitement, l’utilisation pour l’entraînement, les contrôles de sécurité et la suppression contractuelle. Une option de conservation zéro documentée renforcerait la position de DeepSeek auprès des charges de travail sensibles.

Le silence ou l’ambiguïté auraient l’effet inverse. De nombreuses organisations paieront davantage pour des contrôles applicables, car les termes de recherche peuvent révéler des intentions confidentielles. Une récupération bon marché ne peut compenser un parcours de données inacceptable.

Le troisième signal est la réponse des concurrents. Les spécialistes de la recherche et les plateformes de modèles peuvent réduire les prix, intégrer la récupération, améliorer les quotas gratuits ou mettre l’accent sur une recherche de meilleure qualité. Ils peuvent également se différencier grâce au traitement régional, aux citations, à l’exécution dans le navigateur ou aux accords d’entreprise.

Une réponse tarifaire généralisée confirmerait que DeepSeek a redéfini les attentes en matière de récupération de base. Une réponse limitée suggérerait que les concurrents estiment que les acheteurs accordent plus de valeur à la qualité, à l’intégration et à la gouvernance qu’aux frais par requête.

Les développeurs devraient également surveiller l’utilisation après le début de la facturation le 1er novembre. Une adoption continue montrerait que les utilisateurs accordent de la valeur au service au-delà de sa période gratuite initiale. Un déclin marqué indiquerait que la curiosité, plutôt que la demande de production, a motivé l’attention initiale.

Le tarif publié donne à DeepSeek un point d’entrée concret. Search et Fetch sont assez simples à tester en quelques heures, et les requêtes infructueuses n’entraînent pas de frais de récupération. Cela réduit le coût d’une évaluation en conditions réelles.

Cela ne tranche pas la décision d’achat. Les équipes devraient comparer des tâches représentatives, examiner les accords pertinents et suivre l’ensemble du parcours, de la requête à la réponse sourcée. Elles devraient également tester les conditions d’échec avant de faire transiter des données clients ou d’entreprise par le service.

DeepSeek Search and Fetch rend une affirmation difficile à ignorer : l’accès au web en temps réel n’a plus besoin d’être une fonctionnalité premium coûteuse ajoutée à un modèle. La question restante est de savoir si DeepSeek peut fournir une récupération fiable et gouvernable à ce prix.

Exécutez le même jeu d’évaluation chez votre fournisseur actuel et chez DeepSeek. Mesurez les sources pertinentes, les extractions complètes, la latence, les appels facturables et l’exactitude des citations. Répétez ensuite le test en retirant les requêtes sensibles jusqu’à ce que les conditions relatives aux données répondent à vos exigences. Si DeepSeek l’emporte sur des tâches complètes plutôt que sur des appels isolés, son tarif de 0,75 $ aura son importance. S’il ne l’emporte que sur la grille tarifaire, la requête de recherche la moins chère pourrait tout de même produire la réponse la plus coûteuse.