API DeepSeek en Chine : accès direct, passerelle et stabilité (2026)

Quand une équipe chinoise parle de l'API DeepSeek, la question se résume souvent à « est-ce que ça se connecte ». En production, quatre éléments comptent réellement : la stabilité du réseau, la possibilité de payer et d'obtenir une facture, l'acceptabilité des limitations aux heures de pointe, et l'existence d'un canal de secours en cas d'incident. Si un seul de ces points manque, le simple fait de « pouvoir se connecter » ne veut pas dire grand-chose.

Cet article compare trois approches courantes : l'accès direct au fournisseur, le proxy auto-hébergé et la passerelle IA nationale, avec des méthodes de gestion des timeouts, des nouvelles tentatives, du repli et de la validation. Les modèles, les tarifs et les modalités d'accès sont ceux de la page Tarifs des modèles et des documents du site.

Remarque : DeepSeek est une marque de son détenteur. Cet article décrit les situations courantes d'octobre 2026 ; l'environnement réseau et les conditions de service peuvent évoluer. La documentation du fournisseur et la réglementation locale font foi.

1. Les trois approches dans un seul tableau

Critère	Accès direct	Proxy auto-hébergé	Passerelle IA nationale
Point d'entrée	Adresse du fournisseur DeepSeek	Serveur auto-hébergé qui relaie	Point d'entrée unifié compatible OpenAI
Paiement	Selon les canaux acceptés par le fournisseur	Payer d'abord le serveur et la bande passante	Recharge sur le site, règles selon la page
Catalogue de modèles	DeepSeek uniquement	Selon la configuration du proxy	Plusieurs fournisseurs, selon les accès ouverts
Responsabilité de la stabilité	Fournisseur et réseau local	Entièrement à votre charge	Partagée entre le prestataire et vous
Coût d'exploitation	Faible	Élevé	Moyen
Équipe concernée	Un seul modèle, faible volume, réseau stable	Équipe capable d'exploiter le réseau	Multi-modèles, facture, facturation unifiée

Aucune approche ne convient à tout le monde. L'ordre de décision est le suivant : d'abord vérifier si l'activité tolère une interruption, ensuite si plusieurs modèles et des factures sont nécessaires, enfin si l'équipe dispose de personnel d'exploitation.

2. Accès direct : quand il suffit

L'accès direct convient lorsque vous n'appelez que DeepSeek, que le volume est régulier, que le réseau local fonctionne normalement, que la recharge auprès du fournisseur aboutit et que l'activité accepte un ralentissement aux heures de pointe. Les étapes d'intégration restent simples :

Créez une clé API sur la plateforme ouverte DeepSeek, avec un nom par projet.
Placez la clé dans une variable d'environnement côté serveur, jamais dans le front-end ni dans le dépôt.
Validez une requête minimale avec curl et vérifiez l'URL de base ainsi que le nom du modèle.
Configurez dans le SDK le timeout de connexion, le timeout de lecture et le nombre maximal de tentatives.
Journalisez pour chaque appel le modèle, les tokens, la durée et le type d'erreur.

export DEEPSEEK_API_KEY="sk-votre-clé"

curl "https://api.deepseek.com/chat/completions" \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-chat",
    "messages": [{"role": "user", "content": "Réponds seulement OK"}],
    "max_tokens": 16
  }'

Si cette commande échoue parfois par timeout mais fonctionne sur un autre réseau, le problème vient probablement de la sortie locale ou du DNS, pas de la clé. Conservez l'heure de la requête et le message d'erreur avant de décider s'il faut changer de liaison.

3. Proxy auto-hébergé : règle la sortie, pas la capacité

La pratique courante consiste à installer un reverse proxy sur un serveur capable de joindre l'interface du fournisseur et à y relayer les requêtes vers DeepSeek. Cela règle une partie des problèmes de stabilité du réseau local, mais crée de nouveaux travaux :

Le serveur proxy est lui-même un point unique de défaillance : s'il tombe, toutes les requêtes échouent ensemble.
Il faut gérer TLS, l'authentification et le contrôle d'accès pour éviter les abus.
Il faut des journaux, une limitation de débit et de la supervision, sinon impossible de localiser un incident.
Un relais supplémentaire ajoute de la latence ; le délai du premier token en streaming peut augmenter.
La responsabilité réseau et conformité reste à l'équipe.

Sans personnel pour maintenir le proxy en continu, la solution provisoire devient vite une dette de long terme. Elle peut servir de transition, mais il n'est pas recommandé d'en faire l'unique point d'entrée.

4. Passerelle IA : regrouper plusieurs modèles et l'instabilité derrière une seule entrée

L'intérêt d'une passerelle IA nationale ne se limite pas au « relais » : elle regroupe la gestion des clés, la recharge, la facturation, le changement de modèle et le traitement des incidents. Pour une équipe qui utilise plusieurs modèles, le changement le plus direct est que le code métier ne connaît qu'un point d'entrée compatible OpenAI ; changer de modèle revient à modifier la configuration, pas le code.

export ZSQH_API_KEY="sk-votre-clé"

curl "https://ai.zhongshangqihang.com/v1/chat/completions" \
  -H "Authorization: Bearer $ZSQH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-chat",
    "messages": [{"role": "user", "content": "Explique en une phrase le rôle d'une passerelle"}],
    "max_tokens": 128
  }'

Cinq points sont à vérifier avant de choisir une passerelle : les modèles dont vous avez besoin sont-ils pris en charge, les règles de facturation et de recharge sont-elles explicites, des détails d'usage sont-ils fournis, comment les incidents sont-ils notifiés, et les clauses de données satisfont-elles vos exigences de conformité. Ne vous contentez pas de « l'appel passe ».

5. La stabilité se construit côté client : timeouts, nouvelles tentatives, repli

Quelle que soit l'approche, le client doit se protéger. Configurez dans cet ordre :

Séparez le timeout de connexion et le timeout de lecture : connexion courte, lecture plus longue, et un réglage distinct pour les textes longs et les tâches de raisonnement.
Espacez les nouvelles tentatives : ne réessayez que sur 429, 5xx et timeout, avec un backoff exponentiel et une gigue aléatoire, et fixez un maximum.
Contrôlez la concurrence : lissez les tâches par lot avec une file d'attente, sans saturer à l'heure pile.
Prévoyez un modèle de repli : l'activité critique peut basculer vers un modèle ou un canal de secours, en acceptant des sorties différentes.
Ajoutez un disjoncteur : au-delà d'un seuil d'échecs consécutifs, suspendez les appels pour éviter une tempête de tentatives.
Assurez l'idempotence : pour les opérations ayant des effets de bord, vérifiez l'état avant de renvoyer, sans réessayer à l'aveugle.

import httpx
from openai import OpenAI

client = OpenAI(
    api_key="sk-votre-clé",
    base_url="https://ai.zhongshangqihang.com/v1",
    timeout=httpx.Timeout(connect=5.0, read=120.0, write=30.0, pool=10.0),
    max_retries=2,
)

Il n'existe pas de valeur universelle : ajustez selon la tolérance de l'activité et la longueur des tâches. L'essentiel est de ne pas laisser une requête attendre indéfiniment et de ne pas relancer immédiatement en parallèle après un échec.

6. Valider une liaison pendant une semaine

Indicateur	Comment l'enregistrer	Point d'attention
Taux de réussite	Part des réponses non 200	Se concentre-t-il aux heures de pointe
Latence	Relever p50, p95 et délai du premier token	La queue de latence dégrade-t-elle l'expérience
Limitation	Nombre de 429 et heures de déclenchement	Quota ou pic de trafic
Erreurs réseau	DNS, TLS, timeouts de connexion	Problème de sortie locale
Qualité	Échantillonnage humain sur un jeu fixe	Sorties cohérentes après changement de liaison

Couvrez au moins un pic de jour ouvré et une période creuse nocturne. Envoyer le même lot de requêtes à heure fixe pendant sept jours apporte plus d'informations qu'un seul test de charge.

7. Paiement, facturation et conformité

Les équipes qui ont besoin de paiement interentreprise et de factures doivent vérifier à l'avance les règles de facturation et les délais d'encaissement du prestataire.
En cas de données clients, lisez d'abord les clauses : les entrées sont-elles conservées ou utilisées pour améliorer le service.
Séparez les clés par environnement ; une clé de production ne doit jamais entrer dans le front-end ni dans un dépôt public.
Conservez les journaux d'appels et les factures pour le rapprochement comptable et l'audit de sécurité.
Les transferts transfrontaliers et les exigences sectorielles relèvent de la réglementation locale et des procédures de conformité de l'entreprise.

Questions fréquentes

L'accès direct à DeepSeek depuis la Chine est-il stable ?

Cela dépend du réseau local, de l'heure et de la charge du fournisseur ; il n'y a pas de réponse unique. En production, ne dépendez pas d'une seule liaison : prévoyez au minimum timeouts, nouvelles tentatives et canal de secours.

Une passerelle est-elle plus lente ?

Un relais supplémentaire peut ajouter un peu de latence, mais la passerelle offre généralement une entrée plus stable et un basculement en cas d'incident. Testez les mêmes requêtes en direct et via la passerelle, en comparant p95 et taux de réussite, pas un seul appel.

Le proxy auto-hébergé convient-il à toutes les équipes ?

Non. Il exige une exploitation réseau continue, une configuration de sécurité et de la supervision. Sans personne dédiée, le proxy devient lui-même une nouvelle source de panne.

Une clé peut-elle appeler plusieurs modèles ?

En mode passerelle, généralement oui : le modèle est indiqué dans la requête, le périmètre exact dépendant de la page tarifs et de la console. Une clé en accès direct ne peut appeler que les modèles ouverts par le fournisseur.

Comment savoir si le problème est local ou en amont ?

Testez d'abord une requête minimale, puis changez successivement de réseau, de clé et de point d'entrée. Conservez l'heure et le message d'erreur : vous distinguerez rapidement DNS, TLS, authentification, limitation et panne amont.

Pour aller plus loin

Créez d'abord une clé de test sur ZSQH AI Gateway, comparez le taux de réussite et la latence du direct et de la passerelle sur le même lot de requêtes, puis choisissez la liaison de production. Les modèles et les tarifs font foi sur la page Tarifs des modèles.