Testeur de compatibilité des API IA

Pourquoi une requête au format OpenAI fait un bon point de pivot

Un contrôle de compatibilité des API IA part d'un fait très concret : quelque part vers 2024, le schéma Chat Completions d'OpenAI est devenu, sans bruit, la forme que tout le monde a copiée (messages avec les rôles system, user, assistant, plus tools, temperature, max_tokens, stream, et parfois response_format). Anthropic, Mistral, Groq, Together, Fireworks, chaque serveur local que j'ai touché (Ollama, LM Studio, le serveur de llama.cpp). Tous exposent une variante d'endpoint OpenAI-compatible sur /v1/chat/completions. Gemini et Cohere ont gardé leurs propres schémas natifs. Même eux livrent un adaptateur OpenAI, ceci dit. Voici donc ma règle perso. Écris au format OpenAI, traduis vers l'extérieur, et tu t'es offert la sortie la moins douloureuse le jour où tu voudras partir.

Voilà le truc que personne ne te prévient, par contre. OpenAI-compatible, c'est un spectre, pas une case à cocher. Le chat de base (messages en entrée, complétion en sortie) se porte proprement et tu ne verras quasi rien. Les tools marchent la plupart du temps. C'est la façon dont les arguments se parsent et dont les appels parallèles reviennent qui varie juste assez pour te mordre. La vision existe sur OpenAI, Anthropic, Gemini, sauf que chacun veut l'image emballée à sa sauce. Le mode JSON ? Un beau bazar partout, franchement. Le streaming tourne partout, puis le format des chunks dérive sur les bords et ton parser s'étouffe. Cet outil étale chaque feature face à chaque provider pour que tu puisses chiffrer la migration avant de t'engager.

Ce que couvre la matrice de features en 2026

J'ai retenu les dix features qui décident vraiment si un portage prend un après-midi ou une semaine. Messages de chat de base. Message system comme champ à part entière, par opposition à un truc qu'on bourre dans le premier tour user. Temperature et max_tokens qui se comportent pareil par défaut. Tools / function calling, en simple et en parallèle. Entrées vision (image_url et base64). Mode JSON / structured outputs avec validation de schéma. Streaming via Server-Sent Events. response_format avec un schéma explicite. seed pour un sampling reproductible. Et logprobs, quand tu veux de la confiance au niveau des tokens. Chaque cellule est une coche verte, une croix rouge, ou un drapeau partiel portant une mise en garde oui, mais en une ligne.

Chaque fois qu'un provider sort un nouveau flagship, je rafraîchis la matrice. La base 2026 contre laquelle je teste : GPT-5 turbo et GPT-5 mini chez OpenAI, Claude Opus 4.7 et Sonnet 4.6 chez Anthropic, Gemini 3.0 Pro chez Google, Mistral Large 3 et Codestral 2 chez Mistral, Command R+ 2026 chez Cohere, Llama 4 405B et Mixtral 8x22B servis via Groq, et n'importe quel GGUF que tu as envie de faire tourner avec Ollama ou llama.cpp.

Comment fonctionne la traduction de requête

Pour chaque provider, tu obtiens un snippet réellement exécutable, écrit dans le SDK maison du provider. Sous le capot, ça fait cinq conversions barbantes, le genre qu'on rate facilement. Normalisation des rôles (Anthropic sort system dans son propre champ, Gemini le replie dans le premier tour user). Mapping du schéma des tools (OpenAI emballe tout dans type: function avec un objet function imbriqué, Anthropic veut un tableau tools à plat, Gemini veut function_declarations). Remodelage de la vision (OpenAI prend un tableau content avec image_url, Anthropic utilise type: image avec source, Gemini veut des données inline plus un type mime). Renommage des paramètres, où Mistral garde max_tokens mais Gemini insiste sur maxOutputTokens. Puis l'alignement de l'enveloppe de réponse, parce que chaque provider emballe la sortie du modèle un peu différemment.

Copie-le comme point de départ, pas comme produit fini. La traduction naïve tape dans les 80 pour cent des cas, d'après mon expérience. Les 20 pour cent restants ? Ça réclame du réglage spécifique au provider. Et c'est exactement à ça que servent les avertissements sous chaque snippet (Anthropic préfère le prompt caching sur les 1024 premiers tokens, pense à ajouter cache_control), pour que tu saches quels suivis méritent ton temps et lesquels tu peux ignorer.

Les pièges classiques par provider que l'outil signale

• Message system d'Anthropic : c'est une chaîne system au niveau racine, pas un message avec le rôle system. Ton tableau messages doit commencer par user. Saute ça et tu te prends un 400.
• Format des messages chez Gemini : les rôles sont user et model, pas assistant. Ça piège tout le monde la première fois. Et le contenu vit dans un tableau parts, en plus.
• Appels de tools chez Mistral : le parallel tool calling ne marche que sur Large 3, aux dernières nouvelles. Les modèles plus petits te rendent les tools un par un.
• preamble vs system chez Cohere : Cohere appelle ça preamble, pas system, sur l'endpoint v2/chat. La v2 plus récente, style messages, accepte les deux. La vieille v1, non, donc vérifie sur laquelle tu es.
• Streaming chez Groq : pour économiser des octets, les chunks SSE lâchent delta.role après le premier. Suppose qu'il est sur chaque chunk et ton client casse. Demande-moi comment je le sais.
• Mode JSON chez Ollama : c'est format: json tout en haut de la requête, pas response_format à la façon OpenAI.
• Limites de taille de la vision en base64 : OpenAI prend jusqu'à 20 Mo par image, Gemini 20 Mo. Anthropic plafonne à 5 Mo, par contre, et c'est celle-là qui va te surprendre. L'outil signale toute image embarquée trop lourde pour sa destination.

Quand garder le client OpenAI et quand changer de SDK

Honnêtement ? La couche de compatibilité est assez bonne pour que la plupart des équipes gardent simplement le client officiel openai Node ou Python et le re-pointent vers une nouvelle base URL et une nouvelle clé. Rien que ça couvre OpenAI, Groq, Together, Fireworks, Ollama. Mistral aussi, une fois que tu surcharges deux ou trois headers. Anthropic et Gemini, c'est là que je passerais vraiment au SDK natif. Ils exposent le prompt caching, le tool use côté serveur, les réponses grounded que le client OpenAI ne peut tout simplement pas atteindre. Donc ma règle. Ne change de SDK que quand la feature voulue est native au provider (le caching d'Anthropic, le grounding de Gemini avec la recherche). Sinon, reste où tu es. Le diff n'en vaut pas la peine, je crois, sauf si tu cours après l'un de ces trucs-là.

Questions fréquentes

Est-ce que l'outil fait de vrais appels API ?

Non. Chaque traduction tourne directement dans ton navigateur. Aucune clé à saisir. Rien n'est envoyé à un quelconque provider, et le request body que tu colles ne quitte jamais la page. Vois ça comme un traducteur déterministe posé par-dessus le schéma OpenAI. Il réécrit ta requête. Il ne l'exécute pas.

Pourquoi certaines traductions affichent des avertissements ?

Un avertissement apparaît quand la traduction directe tournerait très bien, mais que le provider a un moyen moins cher ou meilleur d'y arriver. Quelques-uns que je signale : le prompt caching d'Anthropic quand tu réutilises le même message system, le grounding de Gemini pour les requêtes factuelles, des longueurs de preamble raisonnables chez Cohere. La sortie brute est déjà correcte. L'avertissement pointe juste l'optimisation que tu voudras probablement de toute façon.

Quel modèle utilise chaque provider dans l'exemple de code ?

Par défaut, ça va chercher le flagship 2026 : GPT-5 turbo chez OpenAI, Claude Sonnet 4.6 chez Anthropic, Gemini 3.0 Pro chez Google, Mistral Large 3 chez Mistral, Command R+ 2026 chez Cohere, Llama 4 405B via Groq, et llama3.3:70b pour Ollama. Des valeurs par défaut sensées. Pas une parole d'évangile. Remplace la chaîne du modèle par celui que tu fais réellement tourner avant de mettre en prod.

Est-ce que ça gère la nouvelle API responses d'OpenAI ?

En partie. Cette version est construite autour du schéma classique Chat Completions. L'API Responses débarquée fin 2025 est à moitié supportée dans l'onglet OpenAI. Mais traduis vers les autres providers, et ça retombe sur le chemin Chat Completions. Pourquoi ? Franchement, personne d'autre n'a encore implémenté la forme Responses.

Je peux utiliser cette sortie en production ?

S'il te plaît, ne la colle pas direct en prod en t'en allant. Les snippets sont une longueur d'avance, pas un build fini. Tu voudras encore une gestion d'erreurs spécifique au provider. Des retries avec backoff exponentiel quand tu te prends du rate limiting. Du suivi des coûts, un peu d'observabilité. Je te donne la forme de la requête. Toute la plomberie de prod autour, ça reste ton boulot.