Pour une équipe basée en Chine, l'accès à l'API OpenAI se résume à trois voies : l'accès direct au fournisseur, un proxy auto-hébergé ou une passerelle IA locale. Ce ne sont pas simplement de « bonnes » et de « mauvaises » options : elles déplacent les coûts à des endroits différents. L'accès direct place le coût sur le réseau et le paiement ; le proxy sur l'exploitation ; la passerelle sur la dépendance au service et la vérification des conditions.

Cet article compare la stabilité réseau, le paiement et la facturation, la conformité, la maintenance, la couverture des modèles et la gestion des incidents. Il fournit aussi une configuration concrète de timeout, de nouvelle tentative et de repli, ainsi qu'une checklist de mise en production. Il s'agit uniquement d'une comparaison technique, sans valeur juridique ; la disponibilité et les exigences de conformité dépendent du droit local, de la réglementation et des conditions des fournisseurs.

Remarque : OpenAI, ChatGPT et GPT sont des marques d'OpenAI. Cet article décrit la situation courante en octobre 2026 ; les prix et la liste des modèles sont ceux de la page Tarifs et de la documentation des fournisseurs, et peuvent évoluer.

1. Les trois voies en bref

Accès direct au fournisseur : utiliser un compte et l'interface d'OpenAI. Le réseau, le paiement et la facturation restent dans le système du fournisseur. Cela suppose que l'équipe remplit les conditions d'inscription et de paiement, et que le droit local ainsi que les conditions de la plateforme l'autorisent.

Proxy auto-hébergé : l'équipe loue un serveur à l'étranger, y déploie un reverse proxy ou un programme de transfert, et les requêtes passent par son serveur avant d'atteindre l'amont. Le proxy règle le chemin réseau et la sortie unifiée, mais le compte, la clé et le paiement restent à régler séparément.

Passerelle IA locale : un fournisseur propose une adresse compatible OpenAI ; l'équipe recharge en yuans et gère ses clés dans la console. La passerelle prend en charge l'accès amont, le transfert et une partie de la gestion des incidents ; côté équipe, il suffit souvent de changer l'URL de base. ZSQH AI Gateway appartient à cette catégorie ; l'inscription se fait sur la page d'inscription.

2. Les différences en un tableau

Critère Accès direct Proxy auto-hébergé Passerelle IA locale
Stabilité réseau Dépend de la liaison transfrontalière ; diagnostic à votre charge Dépend de la ligne du serveur et de la qualité du proxy Maintenue par le fournisseur ; généralement accessible depuis la Chine
Conditions d'ouverture Compte fournisseur et moyen de paiement accepté Serveur, nom de domaine, certificats et exploitation Inscription suffisante, seuil le plus bas
Paiement et factures Selon les devises et moyens acceptés par le fournisseur Frais de serveur et frais amont payés séparément Recharge en yuans, facture selon les règles du fournisseur
Conformité et conditions Soumis directement aux conditions du fournisseur Doit respecter à la fois le droit local et les conditions amont Vérifier les qualifications du fournisseur et les exigences sur les données
Coût d'exploitation Faible, mais les problèmes réseau restent à votre charge Élevé : certificats, supervision, mises à jour Faible ; le diagnostic des incidents dépend du fournisseur
Couverture des modèles Modèles propres à OpenAI Dépend du compte amont, souvent un seul fournisseur Souvent plusieurs fournisseurs ; voir la page Tarifs
Gestion des incidents Canaux de support du fournisseur Diagnostic et rétablissement à votre charge Le fournisseur traite l'amont ; conservez l'identifiant de requête
Équipes concernées Paiement et réseau disponibles, OpenAI uniquement Équipe capable d'exploiter une infrastructure, sortie unifiée PME locales, multi-modèles, facturation en yuans

Ce tableau ne sert qu'à un premier tri. Ce qui détermine réellement l'expérience, ce sont la latence, le taux d'échec et la réactivité en cas d'incident aux heures de pointe. Testez avec vos vraies requêtes métier pendant une à deux semaines avant de décider.

3. Stabilité réseau : regarder la gigue, pas seulement la connectivité

« La page s'ouvre » ne signifie pas « les appels sont stables ». Surveillez le temps jusqu'au premier octet, la durée totale, le taux de timeout et le taux d'interruption du streaming. Aux heures de pointe, les liaisons transfrontalières subissent souvent une hausse de latence et des pertes de paquets, qui se traduisent par des timeouts occasionnels, des réinitialisations de connexion ou des coupures de streaming, plutôt que par un échec systématique.

Un proxy auto-hébergé ne résout pas automatiquement les problèmes de ligne : la région du serveur, la route retour et les éventuelles limitations de débit influencent la stabilité. L'intérêt d'une passerelle locale est que l'entrée se trouve dans le pays et que la liaison est maintenue par le fournisseur ; la latence doit toutefois être mesurée.

Ne vous contentez pas d'un ping. Envoyez de vraies requêtes pendant une période continue et enregistrez le taux de succès, la latence P95 et le nombre de timeouts. La commande suivante montre le temps de chaque étape :

curl -o /dev/null -sS \
  -w "dns=%{time_namelookup}s tcp=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s code=%{http_code}\n" \
  "$OPENAI_BASE_URL/models" \
  -H "Authorization: Bearer $OPENAI_API_KEY"

Un DNS lent indique un problème de résolution, un TCP lent un problème de ligne, un TLS lent une poignée de main ou un certificat, et un premier octet lent une file d'attente en amont. Faites une série de mesures le matin, à midi et le soir : elles seront plus parlantes qu'une mesure unique.

4. Paiement, factures et budget

L'accès direct exige un moyen de paiement accepté par le fournisseur ; la devise, l'échéance et les règles de facturation relèvent de son système. Un proxy auto-hébergé ne contourne pas le paiement : le serveur doit être payé, tout comme le compte amont ; la dépense est simplement divisée en deux postes. Une passerelle locale propose généralement une recharge en yuans et une facturation dans la console, adaptée aux équipes qui doivent justifier leurs dépenses localement.

Quelle que soit la voie choisie, fixez un plafond budgétaire et des alertes de consommation. Les prix évoluent ; cet article ne donne pas de tarif unitaire et renvoie à la page Tarifs. Côté finance, vérifiez trois points : la recharge permet-elle d'obtenir une pièce justificative conforme, le solde est-il remboursable, et le service est-il dégradé ou coupé en cas d'impayé.

5. Conformité et conditions : poser les limites d'abord

Cette section ne donne que des méthodes d'évaluation, pas de moyens de contournement. Vérifiez au minimum quatre points :

  1. L'usage respecte-t-il le droit et les exigences réglementaires locaux ?
  2. Les conditions d'OpenAI et des fournisseurs amont sont-elles respectées ?
  3. Le transfert de données a-t-il été évalué, et inclut-il des données personnelles ou sensibles ?
  4. Le fournisseur exige-t-il une vérification d'identité, propose-t-il un accord de traitement des données et un canal de réclamation ?

La conformité n'est pas une ligne dans un tableau de sélection, c'est un seuil d'entrée. Si une seule condition n'est pas remplie, ne mettez pas le service en production, même à bas prix. En cas de doute, consultez le service juridique ou un cabinet spécialisé ; ne remplacez pas ce jugement par des moyens techniques.

6. Coût de maintenance : un proxy ne s'arrête pas à l'installation

La mise en ligne d'un proxy auto-hébergé n'est que le début. Il faut ensuite gérer le renouvellement des certificats, les mises à jour logicielles, les journaux et le disque, le contrôle d'accès, les changements d'IP, la limitation de débit et les alertes de supervision. Si la clé est stockée sur le proxy, il faut aussi la protéger contre les fuites et les scans. Sans astreinte organisée, les incidents surviennent souvent au milieu de la nuit.

La passerelle confie cette couche au fournisseur, mais l'équipe doit conserver trois capacités : consulter sa consommation, conserver les identifiants de requête et basculer vers une ligne de secours en cas d'incident. Dépendre entièrement d'un point d'entrée unique revient à confier la disponibilité à un tiers ; tout auto-héberger revient à la confier à ses propres équipes. Le choix dépend du type de risque que l'équipe préfère assumer.

7. Couverture des modèles et gestion des incidents

Pour une équipe qui n'utilise qu'OpenAI, la couverture des modèles n'est pas un problème. Pour une équipe qui utilise plusieurs fournisseurs, la passerelle offre un avantage net : une URL de base, un jeu de clés, une facture. Mais « compatible » désigne généralement la compatibilité du format de requête ; les différents modèles ne prennent pas en charge de la même manière les paramètres, les appels d'outils et le format de streaming. Vérifiez chaque point avant de basculer.

En cas d'incident, l'accès direct et le proxy sont diagnostiqués par l'équipe, tandis que la passerelle fait appel au fournisseur pour localiser l'amont. Dans tous les cas, conservez côté client le code de statut, le corps de réponse et l'identifiant de requête. Face à une erreur 5xx, ne réessayez pas indéfiniment : fixez un nombre maximal de tentatives et un timeout global. En cas de coupure de streaming, déterminez d'abord si une sortie partielle a été produite et facturée.

8. Configuration des timeouts, des nouvelles tentatives et du repli

Voici une configuration Python concrète : en cas d'échec de la ligne principale, les tentatives reprennent selon certaines conditions, puis basculent vers l'adresse de secours. Le nom du modèle est lu dans une variable d'environnement pour éviter de le coder en dur.

import os
import random
import time
from openai import OpenAI

PRIMARY = OpenAI(
    api_key=os.environ["PRIMARY_API_KEY"],
    base_url=os.environ["PRIMARY_BASE_URL"],
    timeout=45.0,
    max_retries=0,
)
FALLBACK = OpenAI(
    api_key=os.environ["FALLBACK_API_KEY"],
    base_url=os.environ["FALLBACK_BASE_URL"],
    timeout=45.0,
    max_retries=0,
)
RETRYABLE = {408, 409, 429, 500, 502, 503, 504}

def call(prompt: str) -> str:
    clients = [PRIMARY, FALLBACK]
    last_error = None
    for client in clients:
        for attempt in range(3):
            try:
                resp = client.responses.create(
                    model=os.environ["OPENAI_MODEL"],
                    input=prompt,
                )
                return resp.output_text
            except Exception as exc:
                last_error = exc
                status = getattr(exc, "status_code", None)
                if status not in RETRYABLE:
                    break
                wait = min(2 ** attempt, 8) + random.random()
                time.sleep(wait)
    raise RuntimeError("Les lignes principale et de secours ont échoué") from last_error

Points clés : le timeout doit être inférieur au délai d'attente maximal toléré par le métier ; n'appliquez un backoff qu'aux erreurs réessayables ; configurez la ligne de secours à l'avance et testez-la régulièrement ; ne multipliez pas les tentatives, car en cas de panne elles transformeraient les requêtes en avalanche.

9. Checklist de mise en production

À vérifier dans l'ordre ; ne montez en charge que lorsque tout est coché :

  1. La ligne a été testée et les taux de succès ainsi que les latences P95 du matin, de midi et du soir sont consignés.
  2. Le moyen de paiement fonctionne, les alertes de budget et de solde sont configurées.
  3. Les clés sont séparées par environnement et stockées dans un gestionnaire de secrets côté serveur.
  4. L'URL de base ne contient qu'un seul /v1 et les noms de modèles sont copiés depuis la page Tarifs.
  5. Les timeouts, les tentatives et le repli sont configurés, et un exercice de panne a été réalisé.
  6. Les journaux contiennent l'identifiant de requête, le modèle, la durée et le code de statut, mais jamais la clé complète.
  7. Les exigences de conformité et de traitement des données ont été vérifiées, avec validation interne si nécessaire.
  8. La ligne de secours est opérationnelle, la procédure de bascule est documentée et un responsable est désigné.

10. Questions fréquentes

L'accès direct est-il forcément instable depuis la Chine ?

Non. La qualité de la liaison varie fortement selon la région, l'opérateur et l'heure. Il faut la mesurer avec ses propres requêtes métier. La stabilité est une question de probabilité.

Un proxy auto-hébergé dispense-t-il de gérer le compte amont ?

Non. Le proxy ne fait que transférer les requêtes et unifier la sortie ; le compte amont, la clé, le paiement et le respect des conditions restent à traiter séparément. Il n'apporte pas automatiquement de quota disponible.

Passerelle ou proxy : quelle solution demande le moins d'efforts ?

En général, la passerelle demande moins d'efforts : le serveur, les certificats, les mises à jour et une partie des incidents amont sont pris en charge par le fournisseur. En contrepartie, vous dépendez de ce fournisseur et devez conserver une ligne de secours ainsi que la possibilité d'exporter votre consommation.

Faut-il modifier beaucoup de code pour passer à une passerelle ?

La plupart des passerelles compatibles ne demandent que de changer l'URL de base et la clé, puis de remplacer les noms de modèles selon la page Tarifs. Les paramètres non standard ou les interfaces propriétaires doivent faire l'objet de tests de régression spécifiques.

Que regarder en premier en cas d'incident ?

Le code de statut et le corps de la réponse, puis l'identifiant de requête, et enfin la distinction entre réseau local, service d'entrée et amont. Sans identifiant de requête, la communication et le diagnostic ralentissent sensiblement.

Pour aller plus loin

Les trois voies n'ont pas de supériorité absolue : clarifiez d'abord le paiement, la conformité et la gestion des incidents, puis validez avec du trafic réel. Si vous avez besoin d'une recharge en yuans et d'un point d'entrée multi-modèles, vous pouvez commencer par créer un compte ZSQH AI Gateway ; les prix et les modèles sont indiqués sur la page Tarifs.

À lire également :