AI Gateway : providers natifs vs endpoints compatibles OpenAI

Un AI Gateway centralise les appels vers des fournisseurs LLM externes derrière une seule interface, au lieu de coder chaque intégration SDK côté application. Les clés API restent côté serveur, jamais exposées au client. Le gateway ajoute une couche commune de retry, de bascule et de comptage de coûts par-dessus des fournisseurs dont les formats de réponse diffèrent.

Sur un backend Postgres comme Aurabase, ce choix a une conséquence directe : le même gateway alimente le chat applicatif, le NL2SQL (traduction langage naturel vers SQL) et le RAG (recherche vectorielle pgvector). Un fournisseur mal intégré dégrade les trois fonctionnalités à la fois, pas une seule. C’est ce qui rend la distinction natif/compatible plus qu’un détail d’implémentation.

Un client natif code la forme réelle de l’API du fournisseur : structure de la requête, format de réponse, champs d’usage propres à ce fournisseur. C’est le cas d’Anthropic, dont l’API « Messages » ne ressemble pas à celle d’OpenAI, ou de Gemini, dont le comptage des tokens de raisonnement (thoughtsTokenCount) s’ajoute au compteur de sortie au lieu d’y être déjà inclus.

Un endpoint compatible OpenAI, lui, réutilise le client OpenAI existant et change seulement l’URL de base. Cela fonctionne parce que le fournisseur tiers (Mistral, Scaleway AI, Ollama) a choisi d’imiter le contrat d’API d’OpenAI, souvent avec des écarts : pas de champ de tokens de raisonnement séparé, pas de garantie sur la forme exacte des erreurs. La compatibilité s’arrête là où l’imitation s’arrête.

Le fichier qui organise les providers dans aura-ai ne laisse pas de place à l’ambiguïté. Trois modules, un par fournisseur natif, rien d’autre déclaré.

pub mod anthropic;
pub mod gemini;
pub mod openai;

Chaque module implémente le trait ChatProvider (complétion, streaming, nom de modèle). Deux d’entre eux, OpenAI et Gemini, implémentent en plus EmbeddingProvider. Anthropic n’en a pas besoin : Claude n’expose pas d’API d’embeddings côté fournisseur, un fait produit d’Anthropic lui-même, pas une lacune du code Aurabase.

Configurer Mistral, Scaleway AI ou Ollama ne demande pas de nouveau module : la même variable OPENAI_BASE_URL redirige le client openai.rs vers un autre point de terminaison compatible. C’est une bascule de configuration, pas un développement.

# Provider par défaut : OpenAI natif
OPENAI_API_KEY=sk-...

# Basculer sur un fournisseur compatible OpenAI (Mistral, Scaleway AI, Ollama...)
OPENAI_API_KEY=<clé du fournisseur choisi>
OPENAI_BASE_URL=<URL de base compatible OpenAI du fournisseur>
# ex. Mistral : https://api.mistral.ai/v1

Le comportement change en conséquence. Les erreurs HTTP restent classifiées par le même mécanisme (429 → limite de débit, 5xx → transitoire et retryable, 404 → modèle inconnu), parce que la classification vit au niveau du transport HTTP, pas du parsing spécifique au fournisseur. Ce qui ne suit pas : le comptage précis des tokens de raisonnement, propre au client dédié Gemini.

Le gateway d’Aurabase ajoute trois mécanismes de résilience au-dessus des trois clients natifs. Un circuit breaker par couple (projet, fournisseur) coupe les appels vers un fournisseur en échec répété, avec un jeton de sonde en état semi-ouvert avant de le rouvrir. Un retry à backoff exponentiel avec jitter relance les erreurs transitoires (timeout, 5xx, 429), sans dépendance à une bibliothèque externe de nombres aléatoires.

Chaque fournisseur nomme aussi différemment le motif d’arrêt d’une réponse : length chez OpenAI, MAX_TOKENS chez Gemini, max_tokens chez Anthropic, pour la même réalité (troncature). Le code normalise ces trois vocabulaires vers un jeu commun (stop, length, content_filter, tool_use, other). Sans cette normalisation, un client multi-fournisseur devrait connaître les trois vocabulaires pour détecter une réponse tronquée.

La facturation illustre le même risque. Chez OpenAI et Anthropic, le raisonnement du modèle est déjà compris dans le compteur de tokens de sortie facturés. Chez Gemini, thoughtsTokenCount s’ajoute séparément à candidatesTokenCount : l’ignorer sous-estime le coût réel d’une requête. Un adaptateur générique compatible OpenAI n’a aucune raison de connaître cette particularité, propre au format de réponse natif de Gemini.

Le marché confirme qu’un AI Gateway est devenu une brique attendue, pas un argument marketing isolé. Neon publie deux pages produit dédiées, « AI Gateway » et « Backend for AI agents », toutes deux orientées développeur Postgres. LiteLLM s’est imposé comme projet open source de référence pour unifier les appels vers un grand nombre de fournisseurs derrière un format proche d’OpenAI. Braintrust publie de son côté ses propres comparatifs sur le sujet, signe que la catégorie pèse assez pour justifier du contenu éditorial dédié.

Ces acteurs répondent à un besoin réel : réduire le couplage entre le code applicatif et un fournisseur LLM donné. La différence avec Aurabase tient à l’intégration. Le gateway ne vit pas à côté du backend : il partage le même service que le NL2SQL et le RAG, sur la même base Postgres. Le compromis inverse existe aussi : un proxy dédié comme LiteLLM couvre en général davantage de fournisseurs qu’un gateway intégré à un backend applicatif.

Un gateway natif comme celui d’Aurabase a un avantage réel quand le backend et l’IA doivent rester dans le même système : NL2SQL, RAG et chat applicatif partagent alors la même politique de résilience et la même facturation, sans service supplémentaire à opérer.

Le compromis inverse existe. Si votre priorité est de couvrir un très grand nombre de fournisseurs, ou si le gateway doit servir plusieurs backends indépendants et pas seulement un projet Postgres, un proxy généraliste comme LiteLLM reste souvent le bon choix. Aurabase ne cherche pas à concurrencer cette largeur de couverture : le pari est la profondeur sur 3 fournisseurs majeurs, intégrée au reste du backend.

Pour comprendre comment cette intégration change concrètement l’usage du NL2SQL par rapport à une approche par connecteurs externes, l’approche choisie par Supabase, voir Supabase mise sur des connecteurs, pas sur du NL2SQL natif.

Synthèse des critères qui distinguent réellement les deux approches, sans jugement de valeur : chacune répond à un besoin différent.

Pour voir ce gateway à l’œuvre sur un cas concret, voir le tutoriel NL2SQL sur Postgres. Pour le détail des capacités IA natives d’Aurabase, voir la page IA native.