Le mois dernier, j'ai repris un projet de service client intelligent. Le métier exigeait l'intégration simultanée de trois grands modèles — DeepSeek, Tongyi Qianwen et Doubao — avec comme argument : « on utilise le moins cher, et si l'un est limité en débit, on bascule sur un autre ». Sur le papier, c'est raisonnable. En pratique, on découvre vite que les trois SDK reposent sur trois logiques complètement différentes en matière d'authentification, de facturation et de stratégie de timeout/retry. DeepSeek utilise un Bearer Token, Tongyi passe par DashScope avec une API-KEY plus signature, et les champs d'authentification de Doubao sont encore différents. Côté facturation, certains facturent séparément les tokens d'entrée et de sortie, d'autres appliquent un tarif combiné, et d'autres encore offrent une réduction sur les cache hits. Les timeouts sont encore plus pénibles : l'un est à 30 secondes par défaut, l'autre à 60 secondes, et les nombre de retries et stratégies de backoff doivent être écrits séparément.
À la fin, en comptant les lignes de code, la couche d'adaptation encapsulant les trois clients dépassait les 800 lignes, sans compter le mapping des codes d'erreur. C'est précisément pourquoi le concept de model gateway est revenu en boucle dans le milieu de l'ingénierie IA en Chine depuis l'année dernière. En une phrase : un model gateway est une couche intermédiaire qui masque les différences entre les API de plusieurs grands modèles et expose une interface unifiée à la couche métier supérieure.
Connexion directe, gateway auto-hébergée, plateforme d'agrégation : le coût d'ingénierie des trois approches
Commençons par la connexion directe aux SDK officiels. Trois modèles, cela signifie trois ensembles d'authentification, trois ensembles de gestion d'erreurs, trois ensembles de logiques de retry. Le code métier est truffé de if-else pour déterminer quel fournisseur appeler. Ajouter un nouveau modèle oblige à retoucher toute la couche d'adaptation. Nous avons estimé que maintenir le code d'adaptation pour trois connexions directes représente environ 15 % de la charge de travail backend totale du projet. Si le nombre de modèles dépasse cinq, cette proportion devient ingérable.
L'auto-hébergement d'un gateway est la deuxième option. L'idée centrale est d'écrire soi-même une couche proxy qui relaie les requêtes vers les API de chaque fournisseur. L'avantage, c'est le contrôle ; l'inconvénient, c'est qu'il faut gérer soi-même la conversion de protocole, la rotation des clés, les files de rate limiting et les statistiques d'usage. En interne, nous avons évalué qu'un gateway auto-hébergé prêt pour la production nécessite au minimum deux ingénieurs pendant six à huit semaines, sans compter la maintenance continue des changements de version des API de chaque fournisseur. Pour les équipes de taille petite ou moyenne, le calcul n'est pas vraiment rentable.
La troisième option est une plateforme d'agrégation d'API IA. Ces plateformes encapsulent les API de plusieurs grands modèles et exposent une interface unique. Le coût d'ingénierie est le plus faible, et le délai d'intégration se compte généralement en jours. Dans notre projet, nous utilisons SiCore TokenWorks, compatible avec le SDK OpenAI : il suffit de modifier une ligne de base_url pour basculer. Attention à un piège : les plateformes d'agrégation n'ont pas toutes les mêmes stratégies par défaut pour les timeouts et les retries. Avant d'intégrer, vérifiez impérativement si la plateforme permet de personnaliser le timeout, sinon les requêtes à réponse longue qui surviennent occasionnellement en production seront coupées prématurément par la couche plateforme, et le message d'erreur ne permettra même pas de distinguer un timeout du gateway d'un timeout du modèle.
Les quatre capacités fondamentales d'un model gateway
La normalisation des protocoles est la base. Il s'agit d'unifier les formats de requête, de réponse et les codes d'erreur de chaque fournisseur en un seul standard. Dans l'idéal, la couche métier supérieure ne connaît qu'un seul format d'interface, et changer de modèle ne demande qu'une modification de configuration, pas de code. C'est aussi la raison pour laquelle l'interface compatible OpenAI est si populaire en Chine : l'écosystème d'outils la supporte quasiment partout.
La stratégie de routage est la vraie valeur ajoutée d'un gateway. On peut router par type de tâche — par exemple, les questions-réponses simples vers Doubao, les raisonnements complexes vers DeepSeek ; on peut aussi router par coût — vers le fournisseur le moins cher du moment ; ou encore router par disponibilité — basculer automatiquement vers un secours quand un fournisseur est limité en débit. En testant le routage multi-modèles de SiCore TokenWorks, nous avons constaté qu'une stratégie de répartition selon la complexité de la tâche permettait de réduire sensiblement le coût global des appels dans un scénario de service client, car un grand nombre de questions simples ne nécessitent pas le modèle au raisonnement le plus puissant.
Le rate limiting avec dégradation et l'agrégation d'usage sont des indispensables en production. Le rate limiting doit pouvoir identifier les erreurs 429 et gérer automatiquement la file d'attente et les retries ; la dégradation doit basculer vers un modèle de secours quand un service est indisponible. Quant à l'agrégation d'usage, elle consiste à consolider les volumes d'appels, la consommation de tokens et les coûts dispersés chez plusieurs fournisseurs, pour faciliter le calcul des coûts et le contrôle budgétaire. Ces deux briques représentent un travail considérable si on les développe soi-même, en particulier l'agrégation d'usage : les règles de facturation de chaque fournisseur étant différentes, la logique de rapprochement doit être écrite séparément.
Un déploiement par étapes selon la maturité du projet
Si le projet démarre tout juste et n'intègre qu'un seul modèle, la connexion directe au SDK officiel suffit. Pas besoin de gateway : ajouter une couche, c'est ajouter un point de défaillance. Attendez que le projet soit stable et qu'un deuxième modèle soit nécessaire pour envisager une couche gateway — à ce moment-là, le coût de bascule reste faible.
Si le projet intègre déjà trois fournisseurs ou plus et que la disponibilité est un critère, je recommande directement une plateforme d'agrégation d'API IA, en externalisant les coûts d'adaptation et d'exploitation. Trois points clés lors du choix : compatibilité avec le SDK OpenAI, support des timeouts et retries personnalisés, et clarté des statistiques d'usage. Quant au gateway auto-hébergé, sauf exigence de conformité particulière ou équipe disposant de suffisamment de ressources d'exploitation, je ne le recommande pas en phase de démarrage.
Un model gateway résout la complexité d'ingénierie liée à l'intégration de plusieurs modèles, pas les questions de capacité des modèles eux-mêmes. Bien choisir sa solution permet à l'équipe de se recentrer sur la logique métier.