Appeler Claude, GPT et Gemini via des points d’entrée compatibles avec OpenAI

Anthropic et Google proposent désormais des points d’entrée compatibles avec OpenAI, de sorte que pour faire fonctionner du code SDK d’OpenAI existant avec Claude ou Gemini, il suffit de modifier quelques lignes au lieu de réécrire toute l’intégration. La partie difficile n’est pas la première requête ; il s’agit plutôt de savoir quels fonctionnalités chaque couche de compatibilité ignore discrètement, et quel est le coût lié au maintien de plusieurs d’entre elles en même temps. Ci-dessous, vous trouverez la configuration exacte du client pour chaque fournisseur, les lacunes documentées importantes pour les agents en production, ainsi que les compromis liés à la fusion des trois services derrière une seule URL de base et un seul mot de passe.

Que promet réellement l’expression « compatible avec OpenAI »

messages, les mêmes flags de streaming et le même schéma d’appel d’outil. Comme ce format est devenu la norme de facto il y a des années, la plupart des fournisseurs de modèles le proposent désormais sous une forme ou une autre, permettant ainsi aux équipes d’essayer un modèle différent sans devoir modifier leur code client.

Cependant, compatible ne signifie pas identique. La structure de la requête est similaire, mais la sémantique derrière chaque paramètre peut varier, et les options non prises en charge sont souvent acceptées puis ignorées plutôt que rejetées. C’est ce second comportement qui rend ces couches risquées : rien ne échoue de manière visible, si bien qu’un manque de fonctionnalité se manifeste par une sortie dégradée plutôt que par une erreur.

La documentation sur la compatibilité du SDK OpenAI d’Anthropic présente cette couche comme un moyen de tester et de comparer les capacités des modèles, et non comme la solution recommandée pour le déploiement en production. Elle énumère également des limitations concrètes :

• Le paramètre strict pour les appels de fonction est ignoré, ce qui signifie que le JSON des appels d’outil n’est pas garanti conforme au schéma fourni.
• Le mémorisation des prompts n’est pas disponible via cette couche de compatibilité, bien que l’API native d’Anthropic la prenne en charge.
• Tous les messages système et ceux destinés aux développeurs sont fusionnés en un seul message système au début de la conversation, car Claude ne accepte qu’un seul prompt système initial.

Aucun de ces éléments ne posera de problème pour une expérience rapide. Chacun d’eux peut cependant compromettre un agent de production qui dépend de l’accord des arguments d’outil avec un schéma, du stockage en cache pour maintenir la latence et les coûts sous contrôle, ou d’instructions système injectées au cours de la conversation.

La couche de compatibilité de Google

Le côté Google est plus complet dès le départ. Selon sa documentation Gemini sur la compatibilité avec OpenAI, les complétions de chat standard, le streaming et l’appel de fonctions fonctionnent tous. Google précise cependant que toutes les options spécifiques aux fournisseurs ne sont pas transférables entre les deux API, et il recommande de passer à l’API Gemini native dès que vous avez besoin d’une fonctionnalité spécifique à Gemini.

Le coût de leur utilisation

Chaque couche, prise isolément, constitue une solution temporaire viable pour évaluer un modèle. En intégrant les trois fournisseurs dans une seule application, la complexité augmente : trois adresses URL de base, trois clés API, trois tableaux de bord de facturation, trois ensembles de limites de débit et trois listes différentes de paramètres qui sont ignorés automatiquement, tout cela afin de faire fonctionner du code identique pour chaque fournisseur.

Diriger le SDK OpenAI vers Claude

Pour passer d’une intégration avec le SDK OpenAI à Claude, il suffit de faire trois modifications : l’adresse URL de base, une clé API d’Anthropic à la place d’une clé OpenAI, ainsi que le nom du modèle Claude. C’est ainsi la manière la plus rapide d’évaluer Claude avant de s’engager avec le SDK natif d’Anthropic. Les importations restent inchangées :

import os
from openai import OpenAI

response = ; séparez-les en deux instructions lors de sa copie :

client = OpenAI(
    api_key=os.environ.get("ANTHROPIC_API_KEY"),
    base_url="https://api.anthropic.com/v1/",
)response = client.chat.completions.create(
    model="claude-opus-5",
    messages=[{"role": "user", "content": "Explain how AI works"}],
)

Diriger le SDK d’OpenAI vers Gemini

La version Gemini de ce même mécanisme vise l’endpoint de Google. Vous avez besoin d’une clé API Gemini, que vous pouvez créer dans Google AI Studio. Une fois de plus, seule l’importation standard d’OpenAI est requise :

from openai import OpenAI

Le client utilise la clé Gemini ainsi que l’URL de base compatible OpenAI de Google ; le corps de la requête reste inchangé. La même absence de saut de ligne apparaît ici, et le placeholder pour la clé codée en dur devrait être remplacé par une variable d’environnement, comme dans l’exemple Claude :

client = OpenAI(
    api_key="YOUR_GEMINI_API_KEY",
    base_url="https://generativelanguage.googleapis.com/v1beta/openai/",
)response = client.chat.completions.create(
    model="gemini-3.7-flash",
    messages=[{"role": "user", "content": "Explain how AI works"}],
)

Le streaming et les appels de fonction fonctionnent tous deux via cet endpoint. Les contrôles de raisonnement de Gemini sont exposés à travers le paramètre reasoning_effort d’OpenAI, mais la correspondance n’est pas toujours exacte et dépend du modèle Gemini que vous utilisez. Si vous souhaitez disposer d’une nouvelle fonctionnalité exclusive à Gemini dès sa sortie, l’SDK natif reste la solution la plus rapide.

Et GPT lui-même ?

L’API d’OpenAI ne nécessite pas de couche de compatibilité, car elle définit le format que tous les autres imitent. Cela ne résout pas le problème des multiples fournisseurs, il se déplace simplement ailleurs. Un code écrit selon le format d’OpenAI facilite l’ajout ultérieur des couches d’Anthropic et de Google, mais vous devez encore gérer des clés distinctes, des limites de vitesse différentes et des particularités propres à chaque fournisseur.

Routage de tous les modèles via un seul point d’accès

Aucune des couches propres aux fournisseurs ne traite le cas de plusieurs fournisseurs, car chacune ne route que vers ses propres modèles. Un point d’accès pour les LLM comble cette lacune : une seule interface compatible avec OpenAI qui redirige les requêtes vers Claude, GPT ou Gemini en fonction du model indiqué, de sorte que votre code n’a plus besoin de savoir quelles particularités appartiennent à quel fournisseur.

La migration ressemble exactement aux deux précédentes. L’exemple ci-dessous utilise l’endpoint d’un gateway commercial ; le même schéma s’applique à tout gateway compatible avec OpenAI. L’importation reste inchangée :

from openai import OpenAI

Le client fait désormais référence à l’URL de base du gateway via une clé de gateway, et le nom du modèle sélectionne le fournisseur en amont. Comme avant, ajoutez un saut de ligne avant response = :

client = OpenAI(
    api_key="YOUR_SAYGM_API_KEY",
    base_url="https://api.saygm.com/v1",
)response = client.chat.completions.create(
    model="claude-opus-5",
    messages=[{"role": "user", "content": "Explain how AI works"}],
)

Changer model en gpt-5.6-luna ou gemini-3.7-flash est la seule modification nécessaire pour changer de fournisseur ; tout le reste reste inchangé. Considérez ces noms de modèles comme des exemples valables au moment de la rédaction, et consultez le catalogue de modèles du gateway pour obtenir les identifiants actuels. La même configuration unique fonctionne dans les outils de développement qui lisent déjà des paramètres compatibles avec OpenAI, tels que Cursor, Cline, Claude Code et le Vercel AI SDK : une seule URL de base et une seule clé permettent d’accéder à tous les modèles proposés par le gateway, plutôt qu’à la gamme d’un seul fournisseur. Chaque outil possède ses propres noms de champs pour l’URL de base et la clé, il convient donc de consulter les documents d’intégration du gateway pour connaître les paramètres exacts.

Ce que le gateway ne change pas

Le routage via un gateway ne supprime pas les limites liées au comportement de compatibilité du fournisseur sous-jacent. L’envoi de requêtes Claude au format OpenAI par l’intermédiaire d’un gateway ne vous offre ni mise en cache des prompts ni schémas strictement imposés ; toutes les limitations mentionnées ci-dessus restent en vigueur.

Les gateways font également partie de votre zone de confiance, car chaque prompt et réponse passe par eux. Certains fournisseurs annoncent des mesures de confidentialité, comme le traitement des requêtes à l’intérieur d’environnements d’exécution fiables certifiés par du matériel, afin que l’opérateur du gateway ne puisse pas lire le trafic. De telles garanties concernent uniquement le gateway ; le fournisseur du modèle reçoit et traite toujours votre requête selon ses propres conditions. Évaluez ces deux niveaux séparément et vérifiez toutes les affirmations relatives aux certifications en vous référant à la documentation technique du fournisseur et non à sa publicité.

Questions fréquentes sur la migration

Les fonctionnalités spécifiques à Claude ou Gemini survivent-elles à un niveau compatible OpenAI ?

Seules les fonctionnalités que ce niveau permet de mapper restent accessibles. Que vous appeliez directement l’endpoint de compatibilité du fournisseur ou que vous passiez par un gateway, tout ce qui n’est pas traduit disparaît. Sur Claude, cela inclut le cache des prompts, le traitement des PDF ainsi que l’ensemble des résultats de réflexion étendue ; sur Gemini, cela concerne les paramètres de raisonnement propres au modèle. Si vous dépendez de ces fonctionnalités, utilisez l’API native correspondante pour ces chemins de code.

Quel est le coût du passage à un autre service ?

Avec un gateway, vous payez généralement par token, à peu près comme lorsque vous appelez directement un fournisseur, mais les tarifs varient en fonction du modèle et du vendeur, et certains gateways ajoutent une marge. Vérifiez les prix actuellement publiés pour le modèle spécifique avant de transférer votre trafic en production.

Que se passe-t-il en cas de panne du fournisseur ?

C’est le argument le plus convaincant en faveur d’un seul point de terminaison. Un gateway conçu pour le basculement peut rediriger vers un modèle de secours sans aucun changement dans le code de l’application, tandis que trois intégrations directes nécessitent chacune leur propre logique de tentative et de secours. Gardez à l’esprit qu’un modèle de secours est un modèle différent : les prompts optimisés pour Claude peuvent se comporter différemment sur Gemini, et la fiabilité des appels aux outils varie. Testez vos prompts critiques sur chaque modèle de la chaîne de secours avant de compter sur un basculement automatique.

Choisir une voie de migration

• Évaluer un fournisseur supplémentaire : utilisez le point de terminaison compatible OpenAI fourni par ce fournisseur. C’est précisément à cela qu’il est conçu, et la configuration ne nécessite que trois modifications.

Utilisation de deux ou trois fournisseurs en production : envisagez l’utilisation d’un gateway, car il élimine les clés redondantes, les tableaux de bord ainsi que la gestion des limites de vitesse, et centralise le basculement en cas de panne.

En fonction des fonctionnalités propres à chaque fournisseur : conservez les appels SDK natifs pour ces cas, quel que soit l’option choisie pour le reste.

Quelle que soit la solution retenue, conservez l’URL de base, les clés et le nom du modèle dans la configuration plutôt que dans le code, et ajoutez des tests d’intégration pour les comportements sur lesquels votre application repose, comme le respect du schéma des appels aux outils. Ainsi, une absence de paramètre non détectée se traduira par un échec du test plutôt que par un incident en production.

Points clés

• Les points d’entrée compatibles avec OpenAI correspondent à la forme de la requête, et non à tous ses comportements ; les paramètres non pris en charge sont souvent ignorés sans générer d’erreur.
• La couche d’Anthropic ignore les schémas d’outil strict, ne dispose pas de mémoire de cache pour les prompts et fusionne les messages système ; elle est décrite comme une voie de test.
• La couche de Gemini gère bien les conversations, la diffusion en continu et les appels de fonctions, mais les options spécifiques aux fournisseurs nécessitent encore l’API native.
• Un seul passage unique simplifie la gestion des clés, de la facturation et du basculement entre fournisseurs, mais il hérite de toutes les limites de compatibilité et ajoute une entité à votre cadre de confiance.