Pour les équipes chinoises qui intègrent l'API Claude, le problème ne vient généralement pas du SDK, mais de la chaîne d'accès : d'où partent les requêtes, comment payer, comment obtenir une facture, comment le service recule en cas de limitation de débit et qui intervient en cas d'incident. En séparant ces questions, le choix devient clair.

Cet article compare trois approches courantes — connexion directe officielle, relais auto-hébergé et passerelle IA locale — et propose une configuration concrète pour les délais d'attente, les nouvelles tentatives, la dégradation et la supervision. Les modèles et les prix applicables sont ceux de la page Tarifs des modèles ; cet article ne constitue pas un avis juridique ou de conformité.

Remarque : Anthropic, Claude et OpenAI sont des marques de leurs détenteurs respectifs. Cet article décrit les formes de produits courantes en octobre 2026 ; les réseaux transfrontaliers, le transfert de données et les paiements doivent respecter la législation locale et les conditions de service de chaque plateforme. Consultez les équipes juridique et conformité avant toute mise en œuvre.

1. Les trois approches en un coup d'œil

La connexion directe consiste à appeler l'API fournie par Anthropic. La chaîne est la plus courte, les fonctions et la documentation sont synchronisées le plus vite ; elle convient aux équipes disposant déjà d'une entité, d'un moyen de paiement et d'une solution réseau transfrontalière matures. En contrepartie, la qualité réseau, le paiement en dollars, le taux de change et les justificatifs de remboursement restent à leur charge.

Le relais auto-hébergé consiste à déployer un reverse proxy ou une passerelle sur un serveur étranger conforme, afin de centraliser l'authentification, les journaux, la limitation de débit et la facturation. Le contrôle est maximal, mais l'exploitation, les certificats, les mises à jour et le durcissement de la sécurité incombent à l'équipe ; un mauvais choix d'emplacement ou un traitement inadapté des données peut au contraire aggraver le risque de conformité.

La passerelle IA locale, fournie par un prestataire chinois, expose un point d'entrée compatible OpenAI, facturé en yuans, généralement avec console, statistiques d'usage et facture. L'intégration est peu coûteuse et le changement de modèle simple ; il faut toutefois vérifier les qualifications du prestataire, les clauses de données, le niveau de service et la réaction aux incidents.

Dimension Connexion directe Relais auto-hébergé Passerelle IA locale
Réseau et accès Dépend de la liaison transfrontalière, à optimiser soi-même Choix de la ligne possible, exploitation à sa charge Point d'entrée local, généralement prêt à l'emploi
Paiement et facture Règlement en dollars, circuit de remboursement long Dépend du serveur et du titulaire du compte Règlement en yuans, facture possible
Conformité et données Évaluation du transfert et des clauses à faire soi-même Emplacement et conservation des données sous sa responsabilité Vérifier les clauses et les qualifications du prestataire
Coût d'exploitation Moyen, surtout réseau et compte Élevé : serveurs, certificats, mises à jour Faible, gestion centralisée dans la console
Limites et incidents Nouvelles tentatives et dégradation à concevoir Limitation et sondes à concevoir Le prestataire en traite une partie, à tester soi-même
Couverture des modèles Principalement Claude Extensible librement Généralement plusieurs fournisseurs

2. Réseau et liaison : tester avant de choisir

Ne vous contentez pas de vérifier « si ça passe ». En production, mesurez quatre éléments : le temps jusqu'au premier octet, la stabilité des réponses longues, la perte de paquets aux heures de pointe et la reconnexion après coupure. La sortie en flux est plus sensible à la liaison : testez avec des prompts de longueur réelle, pas seulement avec un « bonjour ».

Pour un relais auto-hébergé, distinguez « proxy » et « passerelle ». Un proxy se contente de transmettre les requêtes ; une passerelle assure aussi l'authentification, la limitation de débit, les journaux et le routage des modèles. Exposer un proxy directement sur Internet avec une seule clé fixe est très risqué : ajoutez au minimum un contrôle d'accès, une limite de taille des requêtes et des alertes d'anomalie.

Les liaisons transfrontalières doivent respecter la loi locale et les conditions des plateformes. N'utilisez pas de proxy partagé d'origine inconnue et ne confiez pas les identifiants de compte à un tiers non fiable. Pour les données personnelles et les données importantes, réalisez d'abord une classification et une évaluation du transfert.

3. Paiement, contrat et facture

Le point de blocage habituel des équipes chinoises est le titulaire du paiement. Rechargement par carte personnelle, paiement pour compte d'autrui et justificatifs incohérents empêchent souvent la comptabilité d'enregistrer la dépense. Avant de choisir, demandez clairement : avec qui le contrat est-il signé, dans quelle devise, quelle facture est émise et quelles sont les règles de remboursement.

Les passerelles locales acceptent généralement le virement d'entreprise en yuans et émettent des factures de TVA ; les relevés peuvent être regroupés par projet ou par clé, ce qui convient aux équipes devant unifier les dépenses multi-modèles. La connexion directe convient aux équipes disposant déjà d'une capacité de paiement à l'étranger. Quelle que soit l'approche, inscrivez prix, taux de change, taxes et conditions de remboursement dans le bon de commande ; les coûts exacts sont ceux de la page Tarifs des modèles et du contrat.

4. Conformité et périmètre des données

Les points à vérifier comprennent au minimum : les entrées et sorties servent-elles à l'entraînement, combien de temps les données sont-elles conservées, où sont-elles stockées, un accord de traitement des données peut-il être signé, quels sont les sous-traitants ultérieurs et comment les incidents de sécurité sont-ils notifiés. Pour un service destiné aux utilisateurs chinois, évaluez aussi les exigences de protection des données personnelles et de transfert transfrontalier.

L'approche pragmatique est de classifier les données : les informations publiques peuvent passer par un canal général ; le code, les contrats et les informations clients doivent d'abord être anonymisés ; les scénarios impliquant des données personnelles sensibles ou des données importantes font l'objet d'une évaluation distincte et de documents écrits. Ne remplacez pas l'analyse de conformité par un « on verra à l'usage ».

5. Limitation de débit, délais et dégradation

Les limites de l'API Claude sont généralement calculées selon plusieurs dimensions : nombre de requêtes, tokens d'entrée et tokens de sortie. Un pic de trafic, un contexte long et des nouvelles tentatives concurrentes déclenchent des 429 ; un 529 peut aussi apparaître lorsque le service est surchargé. La bonne pratique consiste à définir des délais raisonnables, un retrait exponentiel avec gigue aléatoire, un nombre maximal de tentatives et des écritures idempotentes.

import os, random, time
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["ZSQH_API_KEY"],
    base_url="https://api.zhongshangqihang.com/v1",
    timeout=60.0,
    max_retries=0,
)

def chat(messages, model, fallback):
    for name in [model, fallback]:
        for attempt in range(4):
            try:
                return client.chat.completions.create(
                    model=name,
                    messages=messages,
                    max_tokens=1024,
                    timeout=60,
                )
            except Exception as exc:
                status = getattr(exc, "status_code", None)
                if status not in (429, 500, 502, 503, 504, 529):
                    raise
                if attempt == 3:
                    break
                time.sleep(min(2 ** attempt + random.random(), 8))
    raise RuntimeError("primary and fallback both failed")

Les délais doivent être adaptés à la tâche : plus courts pour une question simple, plus longs pour la génération de documents. Un délai trop long n'est pas meilleur : une requête suspendue occupe une connexion du pool. Les nouvelles tentatives ne concernent que les erreurs récupérables ; 401, 400 et le dépassement de contexte ne doivent pas être réessayés.

Ordre de dégradation recommandé : modèle léger du même éditeur, modèle équivalent d'un autre éditeur, puis règles ou résultats en cache. Placez l'interrupteur de dégradation dans un centre de configuration, sans redéployer le code ; journalisez à chaque fois le modèle et la raison.

6. Isolation des clés et supervision

  1. Utilisez des clés différentes pour la production et les tests, puis séparez encore par projet.
  2. Ne placez les clés que dans des variables d'environnement côté serveur ou dans un service de gestion des secrets, jamais dans le front-end, le dépôt ou les journaux.
  3. Fixez un plafond ou un seuil d'alerte par clé et faites-les tourner régulièrement.
  4. Enregistrez le volume de requêtes, le taux d'erreur, la latence P95, la consommation de tokens et le nombre de dégradations.
  5. Alertez séparément sur les 401, les 429 et les 5xx, pour qu'un « taux d'erreur » global ne masque pas un problème précis.
  6. Conservez l'identifiant de requête et le nom du modèle, pour faciliter le rapprochement avec le prestataire et le diagnostic.

La supervision doit couvrir le résultat métier, pas seulement le code HTTP 200. Le taux d'échec d'analyse JSON, le taux de réussite des appels d'outils et la proportion de réponses vides révèlent souvent plus tôt qu'un code de statut un problème de modèle ou de prompt.

7. Checklist de mise en production

  1. Définir la voie d'accès et le titulaire du contrat, puis faire valider par le juridique et la finance.
  2. Réaliser un test de charge avec du trafic réel dans l'environnement réseau cible.
  3. Configurer les délais, les nouvelles tentatives, le retrait et le nombre maximal de tentatives.
  4. Préparer au moins un modèle de dégradation utilisable et répéter la bascule.
  5. Mettre en place la hiérarchie des clés, les plafonds et le plan de rotation.
  6. Brancher la supervision de l'usage, du taux d'erreur, de la latence et des dégradations.
  7. Archiver les clauses de données, les factures, les reçus de paiement et les procès-verbaux de recette.
  8. Déployer d'abord sur un faible volume et observer une semaine avant d'augmenter.

Questions fréquentes

Peut-on se connecter directement à l'API Claude depuis la Chine ?

La disponibilité dépend de l'environnement réseau local, de l'éligibilité du compte et des conditions de la plateforme. Cet article ne fournit pas de méthode pour contourner des restrictions ; les équipes doivent choisir un mode d'accès conforme à la loi et aux conditions de service, et privilégier une passerelle locale avec contrat et facture.

Quelle différence entre une passerelle et un proxy ?

Un proxy transmet généralement les requêtes ; une passerelle assure en plus l'authentification, la limitation de débit, les journaux, la facturation et le routage des modèles. En production, il est conseillé de centraliser via une passerelle et de ne pas exposer un proxy brut sur Internet.

Que faut-il vérifier pour un relais auto-hébergé ?

L'emplacement du serveur, la conservation des données, le contrôle d'accès, le renouvellement des certificats et la réponse aux incidents restent à votre charge. Réalisez une évaluation de conformité avant tout déploiement transfrontalier et évitez de faire transiter des données sensibles sur une liaison non maîtrisée.

Faut-il réessayer indéfiniment en cas de 429 ?

Non. Utilisez un retrait exponentiel avec gigue aléatoire et limitez le nombre de tentatives ; un 429 persistant indique un quota ou une concurrence insuffisants. Il faut alors dégrader, mettre en file ou ajuster le quota, plutôt que d'empiler les tentatives.

Une passerelle multi-modèles réduit-elle la stabilité ?

Un maillon supplémentaire ajoute un point de panne, mais aussi des capacités de bascule et de dégradation. L'essentiel est de vérifier le niveau de service, la supervision, la notification d'incident et les règles de remboursement du prestataire, et de réaliser soi-même des sondes de bout en bout.

Pour aller plus loin

Créez d'abord une clé de test sur ZSQH AI Gateway avec un lot de tâches réelles, vérifiez la liaison, la latence et la dégradation, puis séparez les clés de production par environnement. La couverture des modèles et les coûts sont ceux de la page Tarifs des modèles.

Lectures associées :