Choisir une passerelle d’API IA n’est plus le même problème qu’il y a deux ans. En 2024, la plupart des développeurs appelaient directement OpenAI ou lançaient LiteLLM en local. Désormais, il existe des options hébergées avec des tableaux de bord de tarification, des plafonds de crédit par clé et des catalogues de modèles couvrant des dizaines de fournisseurs. La catégorie s’est suffisamment élargie pour que faire le mauvais choix signifie devoir défaire un vrai travail d’intégration plus tard.
Cet article compare quatre passerelles qui reviennent souvent dans les discussions entre développeurs : CometAPI, Portkey, LiteLLM et Cloudflare AI Gateway. L’objectif n’est pas de désigner un vainqueur — chacune a du sens selon la situation — mais d’exposer clairement ce que fait chaque solution afin que vous puissiez l’associer à votre cas d’usage.
Remarque sur les noms de modèles : Les identifiants de modèles utilisés dans cet article (tels que
gpt-5.4,claude-opus-4-7) sont des identifiants de plateforme CometAPI. Ce ne sont pas des noms officiels d’OpenAI ou d’Anthropic, dont les conventions de nommage diffèrent.
Ce que font réellement ces outils
Avant de comparer les fonctionnalités, il est utile de préciser ce qu’est une passerelle d’API IA. Au minimum : elle s’intercale entre votre application et un ou plusieurs fournisseurs d’IA, en transmettant les requêtes et en renvoyant les réponses. Au-delà de ce minimum, les passerelles divergent fortement.
Certaines passerelles — Cloudflare AI Gateway, par exemple — sont essentiellement une couche de transit qui ajoute de la journalisation et de la mise en cache sans toucher à votre clé API ni à votre tarification. D’autres, comme CometAPI, agissent en tant que revendeur : vous les payez, ils paient le fournisseur sous-jacent, et l’écart de tarification fait partie de la proposition de valeur. LiteLLM est encore différent — c’est un logiciel que vous exécutez vous-même, pas un service hébergé.
Comprendre cette distinction est important avant d’évaluer une fonctionnalité spécifique.
Comparaison des fonctionnalités
Le tableau ci-dessous utilise des informations provenant de la documentation officielle de chaque produit ou de leur tableau de bord public au mois de mai 2026. Les fonctionnalités marquées d’un tiret (—) n’étaient pas confirmées dans les sources officielles au moment de la rédaction.
| Fonctionnalité | CometAPI | Portkey | LiteLLM | Cloudflare AI Gateway |
|---|---|---|---|---|
| Déploiement | Hébergé (SaaS) | Hébergé + auto‑hébergé | Auto‑hébergé (open source) | Hébergé (edge Cloudflare) |
| Catalogue de modèles | 500+ modèles multi‑fournisseurs | 1,600+ LLMs via API unifiée | Dépend de votre config | OpenAI, Anthropic, Workers AI |
| Modèle de tarification | Revendeur (paiement à CometAPI) | Transit + frais de plateforme | Coût d’infrastructure seul | Transit (palier gratuit disponible) |
| API compatible OpenAI | Oui (api.cometapi.com/v1) | Oui (api.portkey.ai/v1) | Oui (local ou distant) | Oui (via l’URL de la passerelle) |
| Plafonds de crédit par clé | Oui (tableau de bord) | Oui | Oui (via config) | — |
| Ratios de prix par groupe | Oui (0.8x par défaut, 0.1x interne) | — | — | — |
| Journalisation des requêtes | Oui (4 types de logs) | Oui | Oui | Oui |
| Suivi du taux de réussite | Oui (vue de disponibilité sur 30 jours) | Oui | Oui | Oui |
| Palier gratuit | Oui (nouveaux comptes) | Oui | Open source (coût infra) | Oui |
| Option d’auto‑hébergement | Non (entreprise : serveur dédié) | Oui | Oui (cas d’usage principal) | Non |
Sources : Tableau de bord CometAPI, Page d’accueil Portkey, GitHub LiteLLM, Documentation Cloudflare AI Gateway
Connexion à chaque passerelle
Les quatre passerelles exposent un endpoint compatible OpenAI, ce qui signifie que la même structure de client fonctionne pour toutes — vous changez le base_url, les identifiants, et dans le cas de Portkey, la façon de spécifier le modèle.
Python
import osfrom openai import OpenAIdef require_env(name: str) -> str: """Raise a clear error if a required environment variable is missing.""" val = os.environ.get(name) if not val: raise ValueError(f"Missing required environment variable: {name}") return val# ── CometAPI ────────────────────────────────────────────────────────────────# Hosted reseller with 500+ models. Use CometAPI model identifiers (e.g. "gpt-5.4").cometapi_client = OpenAI( base_url="https://api.cometapi.com/v1", api_key=require_env("COMETAPI_KEY"),)# ── Portkey ─────────────────────────────────────────────────────────────────# Hosted gateway with observability and 1,600+ LLMs.# Route to a provider by prefixing the model name: "@openai/gpt-4o", "@anthropic/claude-3-5-sonnet", etc.# x-portkey-api-key is required; it authenticates requests to Portkey's gateway.portkey_client = OpenAI( base_url="https://api.portkey.ai/v1", api_key=require_env("PORTKEY_API_KEY"), default_headers={ "x-portkey-api-key": require_env("PORTKEY_API_KEY"), },)# ── LiteLLM ──────────────────────────────────────────────────────────────────# Self-hosted proxy. Provider credentials (OPENAI_API_KEY etc.) are set server-side.# By default the proxy does not validate the client API key — "anything" works.# If you have enabled virtual keys on your LiteLLM instance, pass a virtual key instead.litellm_client = OpenAI( base_url=os.environ.get("LITELLM_BASE_URL", "http://localhost:4000"), api_key=os.environ.get("LITELLM_API_KEY", "anything"),)# ── Cloudflare AI Gateway ───────────────────────────────────────────────────# URL-based pass-through. Keep your real provider API key — Cloudflare does not replace it.cf_account_id = require_env("CF_ACCOUNT_ID")cf_gateway_id = require_env("CF_GATEWAY_ID")cloudflare_client = OpenAI( base_url=( f"https://gateway.ai.cloudflare.com/v1" f"/{cf_account_id}/{cf_gateway_id}/openai" ), api_key=require_env("OPENAI_API_KEY"),)def ask(client: OpenAI, model: str, question: str) -> str: """ Minimal wrapper showing the common call pattern across all four gateways. Model format varies by gateway: CometAPI: "gpt-5.4", "claude-opus-4-7", etc. (CometAPI identifiers) Portkey: "@openai/gpt-4o", "@anthropic/claude-3-5-sonnet", etc. LiteLLM: whatever model names you configured in your proxy Cloudflare: standard OpenAI model names, e.g. "gpt-4o" This function does not handle finish_reason, tool_calls, or provider errors. For production error handling, see: How to Debug Failed AI API Generations. """ response = client.chat.completions.create( model=model, messages=[{"role": "user", "content": question}], ) return response.choices[0].message.content or ""
Node.js
import OpenAI from "openai";function requireEnv(name) { const val = process.env[name]; if (!val) throw new Error(`Missing required environment variable: ${name}`); return val;}// ── CometAPI ────────────────────────────────────────────────────────────────const cometClient = new OpenAI({ baseURL: "https://api.cometapi.com/v1", apiKey: requireEnv("COMETAPI_KEY"),});// ── Portkey ─────────────────────────────────────────────────────────────────// Route to a provider by prefixing the model: "@openai/gpt-4o", "@anthropic/claude-3-5-sonnet"const portkeyClient = new OpenAI({ baseURL: "https://api.portkey.ai/v1", apiKey: requireEnv("PORTKEY_API_KEY"), defaultHeaders: { "x-portkey-api-key": requireEnv("PORTKEY_API_KEY"), },});// ── LiteLLM ──────────────────────────────────────────────────────────────────// Self-hosted. Default mode accepts any API key value.// Set LITELLM_BASE_URL if your server runs on a different host or port.const litellmClient = new OpenAI({ baseURL: process.env.LITELLM_BASE_URL ?? "http://localhost:4000", apiKey: process.env.LITELLM_API_KEY ?? "anything",});// ── Cloudflare AI Gateway ───────────────────────────────────────────────────const cfClient = new OpenAI({ baseURL: `https://gateway.ai.cloudflare.com/v1/${requireEnv("CF_ACCOUNT_ID")}/${requireEnv("CF_GATEWAY_ID")}/openai`, apiKey: requireEnv("OPENAI_API_KEY"),});/** * Minimal wrapper showing the common call pattern. * Model format varies by gateway — see Python example above for details. * Does not handle finish_reason or error recovery; add those for production use. */async function ask(client, model, question) { const response = await client.chat.completions.create({ model, messages: [{ role: "user", content: question }], }); return response.choices[0].message.content ?? "";}
Le schéma de connexion est identique pour les quatre. Les différences significatives apparaissent ailleurs : ce que vous pouvez observer, ce que vous pouvez contrôler, et ce qui se passe quand quelque chose casse.
Ce à quoi chaque outil est réellement adapté
CometAPI
L’offre principale de CometAPI est un catalogue hébergé avec plus de 500 endpoints de modèles, incluant des modèles de génération d’images et de vidéos en plus des modèles texte. La tarification repose sur un système de ratios par groupe — le groupe par défaut applique un multiplicateur de 0.8x sur les tarifs de base de CometAPI. Vous pouvez configurer différents groupes de ratios pour l’usage interne (0.1x) versus les clients payants, ce qui rend pratique la création d’un produit à paliers sans gérer des comptes séparés.
Le tableau de bord propose quatre types de logs (appels API standard, génération d’images, génération de vidéos, Midjourney), une vue de disponibilité sur 30 jours et des plafonds de crédit par clé. Les plafonds de crédit vous permettent de fournir des clés API à des clients ou des prestataires avec un plafond de dépenses strict, ce qui résout un vrai problème lorsque vous distribuez l’accès à un compte partagé.
Ce que CometAPI n’offre pas : l’auto‑hébergement (les clients entreprise peuvent demander un serveur dédié, mais ce n’est pas une option auto‑hébergée standard), la limitation de débit au niveau de la passerelle, ou le SSO.
Idéal pour : Les développeurs indépendants et petites équipes qui veulent router entre de nombreux modèles — y compris image et vidéo — avec une seule clé API et une seule relation de facturation, et qui ont besoin de contrôles de budget par clé.
Portkey
Portkey est une passerelle hébergée centrée sur l’observabilité. Elle donne accès à 1,600+ LLMs via une API unifiée, avec un routage géré en préfixant le nom du modèle par le fournisseur (@openai/gpt-4o, @anthropic/claude-3-5-sonnet). Cela signifie que vous n’avez pas besoin de configurations client séparées pour chaque fournisseur — un seul client Portkey les gère tous, et vous changez la chaîne du modèle.
Au-delà du routage, Portkey fournit le traçage des requêtes, la gestion de versions de prompts et le routage de repli que vous configurez dans le tableau de bord plutôt que dans le code. L’option d’auto‑hébergement permet d’exécuter Portkey sur votre propre infrastructure si la conformité l’exige.
Le dépôt GitHub de la passerelle open source de Portkey est activement maintenu — consultez directement le nombre d’étoiles actuel plutôt que de vous fier à un chiffre cité ici, car il change fréquemment.
Idéal pour : Les équipes qui ont besoin de pistes d’audit, de routage multi‑fournisseurs avec une seule configuration client, ou qui veulent gérer l’exposition des clés API entre développeurs.
LiteLLM
LiteLLM est un package Python et un serveur proxy, pas un service hébergé. Vous l’exécutez vous‑même. C’est une distinction importante : aucun tiers ne traite vos requêtes ni ne détient vos clés API. Les identifiants des fournisseurs (votre vraie clé OpenAI, clé Anthropic, etc.) sont définis en variables d’environnement côté serveur ; le client pointe simplement vers le proxy local.
Par défaut, LiteLLM ne valide pas la clé API envoyée par les clients — n’importe quelle valeur fonctionne. Si vous activez la gestion des clés virtuelles, les clients envoient des clés virtuelles que LiteLLM valide dans sa propre base de données. Dans tous les cas, le proxy convertit les requêtes au format OpenAI vers le format attendu par le fournisseur amont, de sorte que votre code applicatif ne change pas quand vous ajoutez un nouveau fournisseur.
La contrepartie est la charge opérationnelle : vous êtes responsable de l’exécution, de la mise à l’échelle et des mises à jour du serveur.
Idéal pour : Les équipes avec des capacités devops, les organisations avec des contraintes de conformité interdisant les proxys d’API tiers, ou toute personne souhaitant un routage multi‑fournisseurs sans confier le contenu des requêtes à un éditeur SaaS.
Cloudflare AI Gateway
Cloudflare AI Gateway est structurellement différent des trois autres. Vous ne changez pas votre clé API ni ne payez Cloudflare pour l’accès aux modèles. À la place, vous remplacez l’URL de base du fournisseur par une URL gérée par Cloudflare qui ajoute la journalisation, la mise en cache et la limitation de débit à l’edge.
Parce que Cloudflare s’intercale entre votre application et le fournisseur, il peut mettre en cache des requêtes identiques — utile si votre application envoie plusieurs fois les mêmes prompts. Le palier gratuit couvre la plupart des cas d’usage des développeurs indépendants. La limite est le périmètre : Cloudflare n’agrège pas des modèles de plusieurs fournisseurs. Vous avez toujours besoin de comptes et de clés séparés pour chaque fournisseur que vous utilisez.
Idéal pour : Les développeurs déjà sur l’infrastructure Cloudflare, ou quiconque souhaite la mise en cache et la journalisation au‑dessus de comptes fournisseurs existants sans introduire une nouvelle relation de facturation ni changer de clés API.
Correspondance des scénarios
| Scénario | Outil recommandé | Raison |
|---|---|---|
| Application indépendante, essayer 10+ modèles avec une seule clé API | CometAPI | Catalogue large, configuration simple, plafonds par clé |
| Besoin de génération image + vidéo dans la même intégration | CometAPI | Endpoint unifié pour modèles texte, image et vidéo |
| Équipe de 5, besoin de suivre qui utilise quel modèle | Portkey | Traçage des requêtes, gestion d’équipe |
| Acheminer vers 1,600+ LLMs avec une seule configuration client | Portkey | Routage @provider/model, pas de configuration par fournisseur |
| Routage de repli entre fournisseurs sans changer le code | Portkey | Configuration déclarative du repli dans le tableau de bord |
| Entreprise avec exigences de résidence des données | LiteLLM (auto‑hébergé) | Aucun tiers ne traite le trafic |
| Budget nul, à l’aise avec l’auto‑gestion | LiteLLM | Open source, sans coût de plateforme |
| Utilise déjà OpenAI directement, souhaite la mise en cache | Cloudflare AI Gateway | Changement d’URL uniquement, pas de nouvelle facturation |
| Besoin de RBAC pour plusieurs équipes | Portkey ou LiteLLM | Tous deux gèrent équipes/rôles ; CometAPI et Cloudflare non |
Ce que ces quatre outils ne couvrent pas
Cette comparaison couvre les passerelles qui apparaissent le plus souvent dans les discussions de développeurs indépendants. Le marché inclut d’autres options à connaître : Helicone se concentre sur l’observabilité sans agir comme proxy, OpenRouter se spécialise dans le routage vers des modèles open‑weight et de recherche, et AWS Bedrock est le service IA managé d’Amazon destiné aux charges de travail d’entreprise. Si vos besoins ne correspondent à aucun des quatre ci‑dessus, ce sont les prochaines pistes à explorer.
Passer à une passerelle
Si vous appelez actuellement un fournisseur directement et envisagez une passerelle, le changement de code est minime. Pour CometAPI, vous ajoutez une variable d’environnement et changez le base_url. Pour Portkey, vous ajoutez un en‑tête et changez la manière de spécifier le modèle (@openai/gpt-4o au lieu de gpt-4o). Pour Cloudflare, vous changez l’URL sans toucher à votre clé API fournisseur. Pour LiteLLM, vous exécutez d’abord un serveur local, puis vous y pointez votre client.
La vraie question n’est pas comment effectuer la transition, mais si vous en avez besoin. Si vous n’appelez qu’un seul fournisseur, n’avez pas de problèmes de visibilité des coûts et n’avez pas besoin de routage multi‑modèles, une passerelle ajoute de la complexité sans bénéfice. Si vous utilisez plusieurs fournisseurs, distribuez des clés à des prestataires ou constatez des factures imprévues de manière récurrente, la surcharge d’intégration en vaut la peine.
FAQ
Puis-je utiliser ces passerelles ensemble ?
Oui. Certaines équipes exécutent LiteLLM en auto‑hébergement pour les charges sensibles et CometAPI pour le reste. Cloudflare AI Gateway peut se placer devant des requêtes CometAPI si vous souhaitez la couche de cache de Cloudflare par‑dessus — bien que cela ajoute un saut réseau.
Ces passerelles stockent-elles mes prompts ?
Ça dépend de l’outil et de votre configuration. Portkey et CometAPI journalisent les requêtes par défaut ; les deux proposent des réglages de rétention. LiteLLM ne stocke que ce que vous configurez, sur votre propre infrastructure. Le comportement de journalisation de Cloudflare est décrit dans leur documentation AI Gateway. Lisez les conditions de confidentialité de tout service hébergé avant d’y envoyer du contenu sensible.
Que se passe-t-il si la passerelle tombe en panne ?
Pour les passerelles hébergées (CometAPI, Portkey, Cloudflare), une panne de passerelle signifie que votre application ne peut pas atteindre le fournisseur d’IA via ce chemin. LiteLLM exécuté en local a les mêmes caractéristiques de disponibilité que votre propre serveur. Avant d’adopter une passerelle hébergée en production, vérifiez son SLA et si elle propose un repli direct vers le fournisseur si la passerelle elle‑même est indisponible.
Existe-t-il un moyen gratuit d’évaluer chacune avant de s’engager ?
Oui. CometAPI et Portkey disposent de paliers gratuits. LiteLLM est open source et ne coûte que l’infrastructure sur laquelle vous l’exécutez. Cloudflare AI Gateway est gratuit dans des limites généreuses. Vous pouvez tester les quatre sur les mêmes prompts avant de décider.
Comment choisir les bons noms de modèles pour chaque passerelle ?
Chaque passerelle a sa propre convention. CometAPI utilise ses propres identifiants (gpt-5.4, claude-opus-4-7). Portkey utilise le format @provider/nom-du-modèle (@openai/gpt-4o, @anthropic/claude-3-5-sonnet). LiteLLM utilise les noms de modèles que vous définissez dans la configuration de votre proxy. Cloudflare laisse passer les noms de modèles standards du fournisseur inchangés. Consultez la documentation de chaque passerelle pour sa liste de modèles actuelle avant d’écrire du code.
Le changement de passerelle affecte-t-il mes limites de débit actuelles ?
Oui. Si vous passez d’appels OpenAI directs à une passerelle qui gère la relation fournisseur (comme CometAPI), vos limites de débit effectives sont déterminées par le compte de la passerelle auprès d’OpenAI, et non par votre compte personnel. Vérifiez le comportement des limites de débit avec la passerelle avant de migrer du trafic de production.