Une passerelle API compatible Anthropic est une passerelle qui accepte les requêtes de forme Anthropic et renvoie des réponses de forme Anthropic, en particulier pour les Claude messages API. Pour un développeur ou un constructeur individuel, l'attrait est simple : pointez les clients de style Claude, les SDK, les outils internes ou le Claude code sur une seule passerelle au lieu de câbler chaque application directement à Anthropic ou à plusieurs fournisseurs de modèles.

Le plus difficile est que la compatibilité n'est pas une étiquette oui ou non. Une passerelle peut prendre en charge une simple requête sans streaming vers /v1/messages et échouer quand même lorsqu'un client réel utilise le streaming, des outils, des blocs de contenu d'image, la mise en cache des invites, le comptage de jetons, les en-têtes bêta ou la configuration de code Claude. La question pratique n'est pas simplement « accepte-t-il une requête Claude ? » Il s'agit de "quelles parties du contrat Anthropic Messages préserve-t-il, et quelles parties traduit-il, ignore-t-il ou rapproche-t-il ?"

Ce guide explique ce qu'une passerelle Anthropiccompatible API doit faire, en quoi elle diffère d'un proxy LLM générique, ce qu'il faut tester avant de lui faire confiance en production et où la facturation, le routage du modèle, l'analyse de l'utilisation et la gestion des clés s'intègrent dans la conception.

Qu'est-ce qu'une passerelle Anthropic compatible API

Une passerelle Anthropic compatible API se situe entre votre application et un ou plusieurs fournisseurs de modèles en amont. Côté client, il expose les points de terminaison, les en-têtes, les champs de requête, les objets de réponse et les événements de streaming de style Anthropic. Du côté du fournisseur, il peut transmettre les requêtes à Anthropic, les acheminer vers un autre fournisseur ou les mapper dans un modèle différent API.

Dans le cas le plus simple, votre application envoie une requête qui ressemble à une Claude requête Messages :

  • POST /v1/messages
  • Authentification de style Anthropic, généralement x-api-key ou un équivalent de jeton de porteur en fonction de la passerelle
  • Un anthropic-version en-tête ou une version de compatibilité documentée
  • Une invite model, max_tokens, une invite system facultative et un messages tableau
  • Blocs de contenu tels que le texte, l'utilisation d'outils, les résultats d'outils, les images ou d'autres types de blocs pris en charge

La passerelle applique ensuite ses propres responsabilités : authentification, résolution de modèle, routage, journalisation, suivi de l'utilisation, contrôles des dépenses, tentatives en cas de sécurité et normalisation des réponses. Si la passerelle fait partie d'une plate-forme multi-fournisseurs plus large, elle peut également fournir un LLM unifié API pour les développeurs qui souhaitent un accès de style Anthropic aux côtés d'interfaces de modèle OpenAIcompatibles ou autres.

Pourquoi les développeurs utilisent une Claude API passerelle

Une passerelle Claude API est utile lorsque vous souhaitez des clients compatibles Claude sans disperser les informations d'identification du fournisseur, la logique de facturation et les règles de routage spécifiques au modèle dans chaque projet. Ceci est courant pour les créateurs solo exécutant plusieurs applications, les agences gérant les charges de travail des clients, les équipes d'outils internes et les produits qui doivent changer de modèle sans modifier le code de l'application.

Les principales raisons sont opérationnelles :

  • Authentification centralisée : les clients utilisent des clés émises par la passerelle au lieu des clés brutes du fournisseur en amont.
  • Contrôle de la facturation : l'utilisation peut être attribuée à une clé API, un utilisateur, un client, un projet ou une équipe.
  • Flexibilité du routage : les alias de modèle peuvent être résolus en arrière-plan en ID de modèle spécifiques au fournisseur.
  • Compatibilité client : les SDK, les HTTP clients de style Claude et le Claude code peuvent conserver la forme de requête attendue.
  • Observabilité : la passerelle peut enregistrer la latence, l'état, le modèle sélectionné, le modèle résolu, les catégories de jetons, les événements de cache et le coût.
  • Application des règles : les limites, les modèles autorisés et les restrictions de fonctionnalités peuvent être appliqués au niveau de la couche de passerelle.

Model Gate est pertinent dans cette catégorie car il fournit un accès multimodèle compatible OpenAI, une facturation unifiée, une gestion des clés API, des analyses d'utilisation, des contrôles d'équipe, des intégrations Telegram et un partenaire API pour créer des services au-dessus de la passerelle. Pour un hub compatible Anthropic, le point clé est plus large que n'importe quel produit : la passerelle ne crée de la valeur que si ses revendications de compatibilité correspondent aux clients et fonctionnalités réels que vous prévoyez d'utiliser.

La compatibilité va plus loin que l'acceptation /v1/messages

Les Anthropic messages API ne sont pas simplement un point de terminaison de génération de texte brut. Les clients Claude modernes peuvent s'appuyer sur des événements de streaming, des blocs de contenu structuré, des appels d'outils, des champs d'utilisation, des diagnostics de cache d'invite, des en-têtes bêta, un comptage de jetons et des indicateurs de fonctionnalités spécifiques au modèle. Une passerelle qui aplatit chaque requête en une invite générique de fin de discussion peut fonctionner pour une démo tout en interrompant les applications réelles.

Point de terminaison, en-têtes et comportement d'authentification

Un message compatible Anthropic API doit documenter les chemins de point de terminaison qu'il prend en charge, les en-têtes qu'il requiert ou accepte, et comment l'authentification de passerelle est mappée à l'authentification en amont. Anthropic exemples utilisent couramment x-api-key et anthropic-version. Claude Le code et certaines SDK configurations peuvent utiliser des remplacements d'URL de base et des variables d'environnement. Une passerelle doit donc indiquer explicitement si elle accepte x-api-key, Authorization: Bearer ou les deux.

Ne traitez pas l'authentification comme un emballage cosmétique. Les clés de passerelle nécessitent généralement une rotation indépendante, une propriété, des limites de dépenses et des pistes d'audit. Si une passerelle prend en charge la clé Bring-your-own-provider-key, elle doit également expliquer quelles facturations et analyses sont disponibles lorsque l'utilisation est facturée directement par le fournisseur en amont.

Schéma de requête et de réponse

Le contrat Messages comprend plus de messages: [{ role, content }]. Les applications peuvent utiliser des invites système, des tableaux de contenu structuré, des définitions d'outils, tool_choice, des métadonnées, des séquences d'arrêt, des blocs d'images, des paramètres de réflexion étendus, des contrôles de cache et des fonctionnalités bêta. Du côté des réponses, les clients peuvent s'attendre à des tableaux de blocs de contenu, des motifs d'arrêt, des champs d'utilisation, des blocs d'utilisation d'outils et des formes d'erreur cohérentes.

Si une passerelle annonce la compatibilité des messages Anthropic, elle doit indiquer quels types de blocs et quels champs sont conservés, lesquels sont rejetés avec une erreur claire et lesquels sont approximés. La dégradation silencieuse est l'option la plus dangereuse car elle donne l'impression que le débogage est un problème de qualité du modèle alors que le véritable problème est la perte de compatibilité.

Comportement de streaming

Le streaming est souvent le point où la compatibilité superficielle échoue. Un client peut s'attendre à des événements incrémentiels de style Anthropic, des limites de blocs de contenu, des événements delta, des événements de démarrage et d'arrêt de message, des informations d'utilisation finale et des erreurs de flux bien formées. Si la passerelle traduit à partir d'un autre fournisseur, elle doit mapper la sémantique de flux de ce fournisseur dans le modèle d'événement Anthropic sans divulguer de fragments en forme de OpenAI ou spécifiques au fournisseur.

Le streaming affecte également la comptabilité. La passerelle doit gérer les déconnexions des clients, les sorties partielles, les tentatives, les annulations et le règlement final de l'utilisation. Une passerelle de streaming Anthropic robuste enregistre suffisamment d'état pour répondre : quel modèle a été demandé, quel modèle a été réellement utilisé, combien de jetons ont été produits avant la résiliation, si l'utilisation finale a été reçue et quel coût doit être facturé.

Pass-through versus traduction

Il existe deux grands modèles de mise en œuvre pour une passerelle Anthropic Messages API : l'intercommunication et la traduction.

Une passerelle pass-through transmet les requêtes en forme de Anthropic à Anthropic ou à un serveur en amont qui parle déjà le même protocole. Cela préserve mieux la sémantique. Il s'agit du chemin le plus sûr lorsque vous dépendez du comportement Claude exact, des règles de mise en cache des invites, de la sémantique des outils, des fonctionnalités bêta ou du code Claude. Le compromis est que vous restez lié à la disponibilité du modèle, aux tarifs, au comportement régional et aux limites de compte du fournisseur en amont.

Une passerelle de traduction accepte les requêtes de forme Anthropic mais les mappe dans le API d'un autre fournisseur. Cela peut élargir le choix de modèles, améliorer la disponibilité ou réduire les coûts. Cela crée également plus de risques de compatibilité. Les outils peuvent ne pas mapper proprement. Les blocs d'images peuvent avoir des contraintes différentes. Les champs de réflexion peuvent ne pas être pris en charge. Les raisons de l'arrêt peuvent différer. Les écritures et les accès au cache peuvent ne pas exister sous la même forme. Les événements diffusés en continu peuvent nécessiter une reconstruction.

La traduction n'est pas fausse en soi. Il faut juste des limites honnêtes. Une bonne passerelle achemine uniquement vers les modèles qui prennent en charge les fonctionnalités demandées et renvoie des erreurs claires lorsqu'une demande ne peut pas être honorée. Une passerelle faible accepte tout, supprime les champs non pris en charge et espère que le résultat semble suffisamment proche.

Alias de modèle et décisions de routage

Les alias de modèle sont l'une des principales raisons d'utiliser une passerelle. Au lieu de coder en dur les noms de modèles de fournisseurs dans les applications, le client peut demander un alias appartenant à la passerelle, tel qu'un profil stable compatible Claude. La passerelle résout cet alias en un fournisseur, un ID de modèle, une région, un profil de tarification ou une politique de secours.

Les alias sont utiles lorsqu'ils sont spécifiques. Ils vous permettent d'épingler une charge de travail, de la migrer ultérieurement, d'annuler une modification de modèle ou de séparer les tâches en arrière-plan bon marché des requêtes interactives de haute qualité. Ils deviennent risqués lorsqu’ils sont vagues. Des noms comme best, latest ou smart peuvent masquer les changements de coûts, les changements de comportement et les changements de fonctionnalités de l'application.

Le routage doit tenir compte des capacités. Si une demande inclut des outils, la passerelle doit être acheminée uniquement vers les modèles et les fournisseurs qui prennent en charge l'utilisation des outils de la manière annoncée. S'il comprend des blocs de vision, l'itinéraire sélectionné doit prendre en charge la vision. Si cela dépend d’une mise en cache rapide, d’une réflexion approfondie, d’un contexte long ou de lots, ces fonctionnalités doivent faire partie de la décision de routage. Le coût à lui seul ne constitue pas un critère de routage sûr.

Comptage de jetons, mise en cache des invites et comptabilité analytique

Anthropic documente le comptage des jetons comme une surface API distincte, POST /v1/messages/count_tokens étant utilisé pour estimer ou calculer les jetons de requête avant la génération. Pour une passerelle, le comptage des jetons est important car il prend en charge les contrôles de coûts en amont, les décisions de quota, les avertissements destinés aux utilisateurs et les rejets avant que les dépenses n'aient lieu.

Lorsque le comptage des jetons est natif du fournisseur, la passerelle peut renvoyer un résultat faisant davantage autorité. Lorsqu'elle est estimée, la passerelle doit le dire. Les estimations sont toujours utiles, mais elles ne doivent pas être présentées comme des chiffres de facturation exacts si le fournisseur en amont peut compter les jetons différemment.

La mise en cache des invites crée une autre dimension de facturation et de fiabilité. Une passerelle doit traiter les écritures du cache, les accès au cache, la durée de vie du cache et la portée du cache comme des préoccupations de première classe. Anthropic la tarification et la documentation distinguent les jetons d'entrée, les jetons de sortie, les écritures de cache, les accès et actualisations du cache, le trafic par lots et parfois l'inférence régionale. Cela signifie qu'une facturation précise ne peut pas tout regrouper en un seul nombre de jetons génériques.

Un registre de facturation de passerelle pratique :

  • Clé de passerelle, attribution d'utilisateur, de projet ou de client
  • Alias de modèle demandé et modèle en amont résolu
  • Chemin de point de terminaison et de fonctionnalité, tel que les messages, le streaming, le comptage de jetons ou les lots
  • État, latence, tentatives et état d'erreur final
  • Entrée, sortie, écriture dans le cache, accès au cache, réflexion et utilisation liée aux outils, le cas échéant
  • Coût indiqué, coût réglé, devise et source de facturation

C'est ici que l'accès compatible Anthropic croise la IA unifiée API facturation. Une passerelle ne peut pas offrir une visibilité fiable sur les dépenses si elle ne préserve pas les catégories de coûts réellement facturées par le fournisseur en amont.

Claude Compatibilité de la passerelle de code

Claude Le code est un test de compatibilité plus strict qu'une requête curl écrite à la main. Anthropic documente la configuration de la passerelle pour Claude Code à l'aide de l'URL de base et des variables d'environnement d'authentification, et présente les passerelles comme étant utiles pour l'authentification centralisée, le suivi de l'utilisation, la gestion du budget et le routage. En pratique, Claude La compatibilité du code dépend de la collaboration de plusieurs détails.

Une passerelle Claude Code API doit documenter :

  • Quelle URL de base définir pour le Anthropictrafic compatible
  • Utiliser un jeton d'authentification, une clé API ou un flux d'informations d'identification basé sur une assistance
  • Quels alias de modèle correspondent à Claude Modèles compatibles avec le code
  • Si le streaming est entièrement pris en charge
  • Comment les outils, le contexte de fichier et les fonctionnalités spécifiques au fournisseur sont gérés
  • Limites connues lors du routage vers des non-Anthropic amont

De nombreuses passerelles peuvent prendre en charge les SDK appels ordinaires avant de prendre en charge le Claude Code de manière fiable. C'est normal, mais cela devrait être étiqueté. Claude Le code peut révéler des cas extrêmes concernant le streaming, la sémantique des outils, la priorité d'authentification et la dénomination du modèle qu'un test minimal de messages ne pourra pas détecter.

SDK compatibilité et remplacements d'URL de base

Anthropic SDK les utilisateurs se soucient généralement d'une question simple : le client officiel peut-il pointer vers une URL de base différente tout en préservant Anthropic les formes de requête et de réponse ? Si tel est le cas, une passerelle peut souvent être introduite avec des modifications minimes du code d’application. Si ce n'est pas le cas, les utilisateurs peuvent avoir besoin de HTTP clients personnalisés ou de SDK branches spécifiques à la passerelle.

Pour SDK compatibilité, évaluez les détails ennuyeux :

  • Le SDK autorise-t-il une URL de base personnalisée ?
  • L'authentification peut-elle être fournie sous la forme attendue par la passerelle ?
  • Les en-têtes tels que les indicateurs de version et bêta sont-ils transmis ?
  • Les événements en streaming apparaissent-ils sous la même forme ?
  • Les erreurs se désérialisent-elles correctement ?
  • La passerelle renvoie-t-elle les champs attendus par le système de type SDK ?
La compatibilité

SDK est fragile lorsqu'une passerelle renvoie un objet "proche" mais qui n'a pas réellement la forme Anthropic. Les clients typés peuvent rejeter les champs manquants, les champs renommés, les noms d'événements inattendus ou les erreurs de style OpenAI. Plus le client est fortement typé, moins il a de tolérance à la compatibilité informelle.

Lots de messages et charges de travail asynchrones

Les lots de messages

Anthropic API sont conçus pour les charges de travail de type Messages traitées par lots. La prise en charge par lots n'est pas seulement une version groupée de la génération synchrone. Il nécessite la création d'emplois, la récupération, le référencement, l'annulation, la récupération des résultats, la gestion des échecs partiels, l'état durable et le règlement de la facturation.

Une passerelle ne doit pas annoncer la compatibilité des lots de messages tant qu'elle n'est pas en mesure de modéliser honnêtement le cycle de vie. Certaines fonctionnalités prises en charge par Messages peuvent ne pas être prises en charge dans les requêtes par lots, et les charges de travail par lots peuvent avoir un comportement de cache d'invite, des limites de débit, des formats de résultat et des modes d'échec différents. Si une passerelle met uniquement les requêtes en file d'attente en interne et renvoie un ID de tâche personnalisé, cela peut être utile, mais ce n'est pas automatiquement Anthropic une prise en charge par lots compatible.

Analyse d'utilisation et contrôle des dépenses

Pour les particuliers et les petites équipes, l'une des principales raisons d'utiliser une passerelle est de comprendre les dépenses avant l'arrivée de la facture du fournisseur. L'analyse de l'utilisation doit être construite autour de la clé émise par la passerelle et de la route en amont résolue. Cela vous permet de répondre à des questions pratiques : quelle application est chère, quel alias de modèle génère les jetons de sortie, quel client déclenche de longs contextes et quelles requêtes ne disposent pas d'accès au cache ?

Les contrôles des dépenses doivent être proches de la clé. Les budgets par clé, les quotas et les listes autorisées de modèles vous aident à isoler les projets et à empêcher une expérience de consommer l'intégralité du compte. Lorsque le cas d'utilisation passe d'un seul développeur à une équipe, le même modèle s'étend aux LLM API limites de dépenses par clé, limites au niveau du client ou budgets au niveau de l'équipe.

De bons contrôles sont appliqués avant les dépenses lorsque cela est possible. Le comptage de jetons peut prendre en charge les contrôles en amont. Les listes autorisées de modèles peuvent rejeter immédiatement les itinéraires non pris en charge ou coûteux. Les requêtes de streaming nécessitent une comptabilité d'exécution car elles peuvent s'exécuter plus longtemps que prévu. Les tâches par lots nécessitent une logique de réservation, de règlement ou de rapprochement afin que les charges de travail retardées ne contournent pas le modèle budgétaire.

Que mettre dans une matrice de compatibilité

Toute passerelle revendiquant la compatibilité Anthropic doit publier une matrice de compatibilité. Un seul badge ou titre est trop vague. La matrice doit séparer les fonctionnalités qui sont souvent confondues :

  • Point de terminaison des messages
  • Demandes de SMS sans streaming
  • Événements en streaming
  • Outils et choix d'outils
  • Blocs de vision et de contenu non textuel
  • Domaines étendus liés à la réflexion ou au raisonnement
  • Mise en cache des invites et diagnostics du cache
  • Comptage de jetons
  • Lots de messages
  • Point de terminaison des modèles
  • Forme d'erreur et codes d'état
  • En-têtes bêta
  • Claude Prise en charge du code
  • SDK Prise en charge des URL de base

Chaque ligne doit indiquer si la fonctionnalité est transmise, traduite, estimée, partiellement prise en charge ou non prise en charge. Il ne s’agit pas seulement d’hygiène de la documentation. Il évite les incidents de production en faisant de la compatibilité un ensemble de promesses testables.

Tests de conformité avant production

Avant de vous fier à une passerelle Anthropic compatible API, exécutez des tests de conformité qui correspondent à votre charge de travail réelle. Au minimum, testez une requête simple, une requête multi-tours, le streaming, un appel d'outil, une réponse d'erreur et votre chemin d'authentification. Si vous utilisez la mise en cache des invites, le comptage de jetons, Claude le code, les images ou les lots, testez-les directement au lieu de supposer qu'ils découlent de la prise en charge de base des messages.

Un ensemble de tests de fumée pratiques comprend :

  • Requête minimale /v1/messages avec sortie de texte
  • Invite système et conversation à plusieurs tours
  • Réponse en streaming avec gestion de l'utilisation finale
  • Définition de l'outil, appel d'outil et aller-retour du résultat de l'outil
  • Erreur de paramètre non pris en charge avec une réponse en forme de Anthropic
  • Vérification en amont du comptage des jetons
  • Comportement d'écriture d'invite dans le cache et d'accès au cache si annoncé
  • Claude Démarrage du code et véritable tâche de codage si Claude Le code est dans la portée
  • Routage d'alias de modèle vers un modèle demandé et résolu
  • Rejet du budget avant dépense

Le but est de détecter rapidement les inadéquations sémantiques. Si la passerelle renvoie un HTTP 200 valide mais supprime un champ d'outil, modifie un motif d'arrêt ou perd l'utilisation finale sur un flux, votre application peut échouer plus tard de manière plus coûteuse et moins évidente.

Erreurs courantes

L'erreur la plus courante consiste à utiliser "Anthropic-compatible" comme expression marketing au lieu d'un contrat de compatibilité. Une passerelle qui ne prend en charge qu’un seul appel texte sans streaming devrait le dire. Une compatibilité minimale est acceptable pour les charges de travail simples, mais elle ne doit pas être vendue comme une compatibilité totale Claude avec les messages.

D'autres échecs fréquents incluent l'ignorance des en-têtes de version et bêta, le renvoi d'erreurs de forme OpenAI à partir d'un point de terminaison Anthropic, l'aplatissement des blocs de contenu structuré en chaînes simples, la perte d'appels d'outils pendant la traduction et le traitement de tous les jetons comme une seule catégorie de prix. Ces problèmes n'apparaissent généralement qu'après qu'un client commence à utiliser plus qu'un flux de réponse rapide de base.

La logique de repli est une autre source de casse subtile. Réessayer une requête ayant échoué sur un autre modèle peut être sûr pour une simple génération en lecture seule. C'est beaucoup plus risqué lors de l'utilisation d'un outil, du streaming ou de tout flux de travail ayant des effets secondaires. Un modèle de remplacement peut ne pas prendre en charge les mêmes fonctionnalités, produire des arguments d'outil différents ou modifier le comportement de facturation. La solution de repli doit respecter les filtres de capacité et les limites d'idempotence.

Enfin, ne cachez pas les causes profondes derrière les erreurs 500 génériques. Les clients ont besoin d'erreurs de forme Anthropic qui sont utiles, et les opérateurs ont besoin de journaux indiquant le fournisseur, l'itinéraire, l'état des nouvelles tentatives, le modèle résolu, l'ID de la demande et l'état de facturation. Une bonne normalisation des erreurs préserve la compatibilité client sans effacer les faits nécessaires au débogage.

Comment choisir une passerelle compatible Anthropic

Commencez par votre client, pas par la liste des fonctionnalités de la passerelle. Un script qui envoie des requêtes de messages simples a des besoins différents de ceux du Claude Code, d'un framework d'agent avec des outils, d'un workflow de vision ou d'un produit avec une facturation stricte par client. Notez les fonctionnalités exactes utilisées par votre charge de travail, puis comparez les passerelles à ces fonctionnalités.

Pour une évaluation au stade de la sensibilisation, posez ces questions :

  • Conserve-t-il Anthropic les formes de requêtes et de réponses des messages ?
  • Est-il compatible avec le streaming dans le format attendu par votre client ?
  • Les outils, la vision, la mise en cache, la réflexion, le comptage de jetons et les lots sont-ils documentés séparément ?
  • Les Claude SDK ou Claude Code peuvent-ils pointer vers la passerelle sans branches client personnalisées ?
  • Le routage utilise-t-il les capacités du modèle, pas seulement le prix ou la disponibilité ?
  • La passerelle enregistre-t-elle à la fois l'alias de modèle demandé et le modèle en amont résolu ?
  • L'utilisation et le coût sont-ils séparés par catégorie de jeton où le fournisseur expose ces détails ?
  • Pouvez-vous définir des limites de dépenses par clé, utilisateur, projet ou client ?
  • Les paramètres non pris en charge sont-ils clairement rejetés au lieu d'être ignorés ?
  • Existe-t-il une suite de tests de conformité ou au moins des tests de fumée documentés ?

La bonne réponse peut être une passerelle d'intercommunication stricte, une passerelle de traduction avec des fonctionnalités prises en charge limitées ou un plan de contrôle plus large offrant un accès compatible avec Anthropic aux côtés d'autres API. Ce qui compte, c'est que les promesses de la passerelle correspondent au comportement du client dont vous dépendez.

Conclusion : traiter la compatibilité comme un contrat opérationnel

Une passerelle API compatible Anthropic est plus utile lorsqu'elle permet aux clients de style Claude de continuer à travailler tout en centralisant l'authentification, le routage, la facturation, les analyses et les contrôles de politique. Mais la compatibilité doit être spécifique. Les messages, le streaming, les outils, le comptage de jetons, la mise en cache des invites, les lots, le comportement SDK et le Claude code créent chacun leurs propres exigences.

Avant d'adopter une passerelle, définissez les fonctionnalités dont votre charge de travail a besoin, inspectez la matrice de compatibilité, exécutez des tests de conformité et vérifiez que la comptabilité d'utilisation correspond aux dimensions de facturation réelles du fournisseur. Une passerelle honnête en matière de transfert, de traduction, d'estimation et de fonctionnalités non prises en charge sera plus facile à exploiter qu'une passerelle qui revendique une compatibilité universelle et laisse les cas extrêmes à la production.