Le choix d'un relais ou d'un proxy pour l'API DeepSeek est souvent perçu comme une simple question de « changer d'adresse ». En réalité, le choix doit répondre à quatre questions : comment le coût est calculé, si le réseau est stable, qui est responsable en cas d'incident, et si les clés et le traitement des données sont conformes.

Cet article compare les solutions courantes et fournit une checklist de migration et de vérification. Les prix exacts, les noms de modèles et la disponibilité sont ceux de la page Tarifs des modèles et de la documentation des fournisseurs.

Remarque : DeepSeek est une marque de son détenteur ; cet article n'a aucun lien d'affiliation avec DeepSeek. Le marché du relais évolue rapidement ; cet article décrit les formes courantes d'octobre 2026 et ne constitue pas une recommandation d'un fournisseur particulier.

1. Définitions : relais, proxy et passerelle ne sont pas synonymes

  • Relais API (relay) : transmet les requêtes au service de modèle amont et peut fournir facturation, limites et journaux. Certains « relais » du marché ne font que partager ou revendre des clés ; leur stabilité et leur conformité dépendent de l'exploitant.
  • Proxy réseau : HTTP, SOCKS ou reverse proxy, qui ne règle que l'accessibilité réseau sans modifier la sémantique de l'API ; la clé reste la vôtre.
  • Proxy auto-hébergé : vous déployez vous-même un reverse proxy ou une passerelle open source sur un serveur, en contrôlant les clés, les journaux et le routage, mais en assumant le compte amont, la bande passante et l'exploitation.
  • Passerelle IA unifiée : entrée compatible OpenAI qui agrège plusieurs modèles avec une clé, une facture et une console communes. Les passerelles commerciales comme les déploiements open source auto-hébergés peuvent entrer dans cette catégorie.

Mélanger ces quatre notions conduit facilement à prendre un problème réseau pour un problème de modèle. Avant de signer, demandez clairement quelle couche de service le fournisseur assure et à qui appartient la clé.

2. Les quatre solutions dans un tableau

Critère Accès direct Proxy auto-hébergé Relais commercial Passerelle IA unifiée
Transparence tarifaire Facturation du fournisseur, méthode claire Facturation amont plus vos coûts Dépend de l'exploitant, rapprochement nécessaire Facture unifiée dans la console, selon les règles de prix
Stabilité réseau Dépend de la sortie locale Dépend du serveur et de la ligne Dépend de la ligne du relais Dépend de la ligne de la passerelle et de l'amont
Limites et concurrence Limites au niveau du compte fournisseur Contrôle local, mais limites amont subsistent Pool possiblement partagé, à vérifier Selon les règles et l'offre de la passerelle
Couverture des modèles DeepSeek uniquement Dépend des services amont intégrés Souvent plus large, à vérifier Multi-modèles, selon la page Tarifs
Risque lié à la clé Clé entre vos mains Clé entre vos mains Clé partagée ou revendue possible Clé dédiée généralement émise
Exploitation et support Documentation du fournisseur Entièrement à votre charge Dépend des capacités du fournisseur Console, tickets et documentation

Aucune solution ne convient à toutes les équipes. Si vous n'utilisez que DeepSeek et que le réseau et le paiement fonctionnent, l'accès direct est le plus simple ; pour une sortie fixe et un audit, choisissez un proxy auto-hébergé ; sans personnel d'exploitation, évaluez un relais commercial ; pour une facture multi-modèles unifiée, regardez la passerelle.

3. Prix : ne regardez pas seulement le « multiplicateur »

Les relais annoncent souvent un prix « prix du fournisseur × multiplicateur » ou des forfaits de tokens. Un multiplicateur bas ne signifie pas un coût total bas. Posez au moins huit questions :

  1. Les entrées et sorties sont-elles facturées séparément, et au même multiplicateur ?
  2. Les entrées servies par le cache bénéficient-elles d'une remise, et comment est-elle calculée ?
  3. Les tokens de raisonnement produits par thinking sont-ils comptés dans la sortie ?
  4. Les requêtes échouées ou réessayées sont-elles facturées ?
  5. L'usage des requêtes en streaming est-il renvoyé intégralement ?
  6. La recharge a-t-elle un montant minimum, une durée de validité et des règles de remboursement ?
  7. Les factures sont-elles disponibles, et quels sont le taux de change et la devise de règlement ?
  8. La consommation et la facture peuvent-elles être ventilées par projet, par clé et par modèle ?

Inscrivez ces règles dans un tableau comparatif, puis testez avec un même lot de requêtes pour calculer le coût réel. Les prix et modes de facturation exacts sont ceux de la page Tarifs des modèles et de la facture du fournisseur.

4. Stabilité : vérifier par les données, pas par la publicité

La stabilité se mesure au minimum avec six indicateurs : taux de succès, latence P50/P95, délai du premier token, taux de timeout, proportion de 429 et vitesse de sortie. Les tests doivent utiliser des invites de longueur réelle et couvrir le streaming, le contexte long et la concurrence.

import os
import statistics
import time
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["RELAY_API_KEY"],
    base_url=os.environ["RELAY_BASE_URL"],
    max_retries=0,
    timeout=60,
)

prompt = "Explique en 200 mots les principales étapes du traitement d'une commande e-commerce transfrontalière."
latencies, errors, usage = [], 0, []

for i in range(20):
    start = time.perf_counter()
    try:
        resp = client.chat.completions.create(
            model=os.environ["RELAY_MODEL"],
            messages=[{"role": "user", "content": prompt}],
            max_tokens=512,
        )
        latencies.append((time.perf_counter() - start) * 1000)
        usage.append(resp.usage.total_tokens if resp.usage else 0)
        print(i, resp.model, resp.usage)
    except Exception as exc:
        errors += 1
        print(i, type(exc).__name__, exc)

if latencies:
    print("Succès", len(latencies), "Échecs", errors)
    print("P50", statistics.median(latencies), "ms")
    print("Maximum", max(latencies), "ms")
    print("Tokens moyens", sum(usage) / len(usage))

Il ne s'agit que d'une sonde minimale, pas d'un test de charge. Avant la production, observez pendant 7 jours consécutifs, en lançant une série aux heures de pointe et une aux heures creuses, et comparez avec l'accès direct. Pour un relais commercial, surveillez surtout les heures de pointe et les requêtes longues ; pour un proxy auto-hébergé, la sortie du serveur et les limites amont.

5. Risque lié aux clés et conformité : plus important que le prix

Le point le plus souvent négligé avec un relais est l'appartenance de la clé. Une clé partagée, revendue ou un quota d'origine inconnue peut entraîner quatre problèmes :

  • Si l'amont bloque ou ajuste le quota, l'activité s'interrompt et aucun recours direct n'est possible.
  • Plusieurs locataires partagent une clé : limites et incidents s'influencent mutuellement, et le diagnostic devient difficile.
  • Les requêtes traversent un tiers, dont les politiques de journalisation, de cache et de conservation des données ne sont pas transparentes.
  • Les conditions de service peuvent interdire la revente ou le partage, ce qui laisse peu de base contractuelle en cas de litige.

Avant de choisir un fournisseur, vérifiez au minimum l'entité juridique, les conditions de service, la politique de confidentialité, la capacité à émettre des factures et un contact en cas d'incident. N'envoyez pas de requêtes contenant des données personnelles, des secrets ou des contrats à un relais incapable d'expliquer où vont les données. Dans les secteurs fortement régulés comme la finance ou la santé, évaluez en priorité l'accès direct, un déploiement privé ou un service capable de signer un accord de traitement des données.

6. Checklist de migration : de l'accès direct au relais ou à la passerelle

  1. Enregistrez l'état actuel : taux de succès, latence P50/P95, consommation de tokens pour mille requêtes et facture.
  2. Recensez les noms de modèles et les paramètres : thinking, max_tokens, tools, sortie JSON, streaming.
  3. Créez des clés de test et de production distinctes, avec budget et alertes séparés.
  4. Modifiez uniquement base_url et api_key, et validez la requête minimale en préproduction.
  5. Rejouez de vraies invites et comparez la qualité de sortie, la durée et la méthode de calcul de usage.
  6. Vérifiez la correspondance des 401, 402, 429, 5xx et timeouts, et assurez-vous que les tentatives n'aggravent pas la panne.
  7. Déployez progressivement sur 5 % à 10 % du trafic, observez 3 à 7 jours et conservez l'accès direct comme solution de repli.
  8. Après la bascule complète, poursuivez le rapprochement pendant une semaine pour confirmer la cohérence entre facture et statistiques d'usage.

Lors d'une migration, ne changez pas en même temps le modèle, les invites et la passerelle, sinon vous ne pourrez pas attribuer les causes. Ne modifiez qu'une variable à la fois.

7. Comment vérifier la fiabilité d'un relais

Regardez d'abord le champ model de la réponse, mais ne vous y fiez pas seul : il peut être réécrit. Une vérification combinée est plus fiable :

Élément Méthode Signal anormal
Latence Requêtes successives avec la même invite, comparaison P50/P95 Variations extrêmes ou lenteur persistante par rapport à l'accès direct
Taux d'erreur Proportion de 429, 5xx et timeouts Échecs concentrés aux heures de pointe
Usage Comparer usage de la réponse avec la facture de la console Incohérence, usage absent en streaming
Identité du modèle Jeu de test fixe comparant les limites de capacité et le style Capacité nettement dégradée, contexte raccourci
Isolation des clés Vérifier si la clé est dédiée et peut être renouvelée Refus d'expliquer l'origine de la clé
Contrat et support Vérifier l'entité, les conditions, la facturation, le délai de réponse aux tickets Contact personnel uniquement, absence de conditions de service

Les signaux d'alerte incluent : un prix durablement très inférieur à celui du fournisseur, une promesse de « zéro panne », un refus de fournir le détail de consommation, une demande de fournir votre clé du fournisseur, ou l'incapacité à indiquer où sont conservées les données. Dans ces cas, testez d'abord avec un faible volume et ne migrez pas la production d'un coup.

8. Quand un proxy auto-hébergé est-il préférable ?

Le proxy auto-hébergé convient aux équipes disposant de compétences d'ingénierie : besoin d'une IP de sortie fixe, d'un audit unifié, d'un routage multi-amont, ou volonté de garder les clés en interne. La pratique courante consiste à ajouter au reverse proxy la gestion des clés, la limitation de débit, les journaux et les alertes, tout en continuant d'utiliser un compte fournisseur ou un fournisseur conforme en amont.

Le coût doit aussi être calculé : serveur, bande passante, certificats, mises à jour, correctifs de sécurité et astreinte. Pour un usage occasionnel sans personnel d'exploitation, l'auto-hébergement revient souvent plus cher qu'une solution commerciale. Il ne permet pas non plus de contourner les limites amont ni les conditions de service.

9. Conseils de choix : classer selon les contraintes

  1. Regardez d'abord le réseau et le paiement : l'entrée du fournisseur est-elle accessible de manière stable et la recharge fonctionne-t-elle ? Si oui, privilégiez l'accès direct.
  2. Regardez ensuite le niveau de contrôle : avez-vous besoin d'une sortie fixe, de journaux d'audit, de clés privées ? Si oui, évaluez un proxy auto-hébergé.
  3. Puis la couverture des modèles : voulez-vous appeler plusieurs modèles depuis un seul point d'entrée ? Si oui, regardez la passerelle unifiée.
  4. Enfin la capacité de service : entité, conditions, facturation, tickets et politique de données sont-ils clairement définis ?

Si vous avez besoin d'un point d'entrée multi-modèles unifié, vous pouvez créer une clé de test sur ZSQH AI Gateway, valider avant de migrer ; les prix et modèles disponibles figurent sur la page Tarifs des modèles. Ne faites pas du « bon marché » le seul critère : intégrez aussi le coût de migration et d'incident.

Questions fréquentes

Quelle différence entre un relais et un proxy ?

Un proxy désigne généralement un transfert au niveau réseau, qui ne règle que l'accessibilité ; un relais inclut aussi le compte, la facturation ou la distribution des clés. Les deux termes sont souvent confondus : avant de signer, clarifiez le périmètre de service.

Un relais moins cher que le fournisseur est-il crédible ?

Cela peut venir d'achats en volume, d'une subvention de ligne ou d'une revente de quota, mais aussi s'accompagner de clés partagées, de limites de débit ou d'une instabilité de service. Vérifiez d'abord la méthode de facturation, le détail de consommation et les clauses du contrat, puis testez à faible volume.

Comment savoir si un relais a changé de modèle ?

Le champ model de la réponse ne suffit pas. Utilisez un jeu de test fixe pour comparer les limites de capacité, la longueur de contexte, le style de sortie et la structure de usage, en gardant l'accès direct comme référence. En cas de dégradation manifeste, suspendez le trafic avant d'analyser.

Combien de code faut-il modifier pour migrer vers une passerelle ?

La plupart des projets utilisant le SDK OpenAI ne changent que base_url et api_key, puis ajustent les noms de modèles selon la page Tarifs. Si vous utilisez thinking, tools ou des champs de réponse spécifiques, prévoyez des tests de compatibilité supplémentaires.

Que doivent surveiller en priorité les entreprises ?

L'appartenance des clés, l'accord de traitement des données, l'entité contractante et la facturation, la réactivité en cas d'incident et les modalités de sortie. Le prix compte, mais la continuité d'activité et la responsabilité en matière de conformité comptent davantage.

À lire également :