AxonHub : une passerelle Go pour appeler Claude avec le SDK OpenAI

Le problème concret : un SDK, dix fournisseurs, dix formats

Le README énonce le problème en quatre points : verrouillage fournisseur, complexité d'intégration, absence d'observabilité, contrôle des coûts. Le deuxième point est le plus tangible. Chaque fournisseur expose sa propre forme de requête et de réponse ; écrire du code qui parle à OpenAI, Anthropic et Gemini demande soit trois clients, soit une couche d'abstraction maison à maintenir. AxonHub propose de déplacer cette couche hors de l'application, dans un service séparé. La cible est donc l'équipe qui a déjà du code écrit contre un SDK précis et qui ne veut pas le réécrire pour changer de modèle. Le README résume la promesse par une phrase : utiliser le SDK OpenAI pour appeler Claude, ou le SDK Anthropic pour appeler GPT, avec, selon ses termes, zéro modification de code. C'est un problème d'ingénierie réel, pas un problème de confort : la couche de traduction est exactement l'endroit où se logent les écarts de comportement entre fournisseurs, et la déporter dans un composant distinct rend ces écarts visibles et testables à un seul endroit.

Traduction de protocole, traçage et RBAC : ce que le dépôt expose

Le dépôt contient une image d'architecture, docs/axonhub-architecture-light.svg, mais le README n'en détaille pas le contenu. Ce qui est décrit, c'est le rôle du composant : recevoir une requête dans le format d'un SDK, la convertir vers le format du fournisseur choisi, puis renvoyer la réponse dans le format d'origine. Autour de cette fonction centrale, le tableau des fonctionnalités liste quatre mécanismes : le traçage au niveau du fil d'exécution, un RBAC avec quotas d'usage et isolation des données, un équilibrage de charge avec bascule automatique annoncée sous 100 ms, et un suivi des coûts par requête incluant les jetons d'entrée, de sortie et de cache. Ces éléments sont documentés dans des fichiers distincts, par exemple docs/zh/guides/tracing.md, docs/zh/guides/permissions.md, docs/zh/guides/load-balance.md et docs/zh/guides/cost-tracking.md. La documentation principale est en chinois, avec des versions anglaise et japonaise du README. La valeur du chiffre de 100 ms n'est pas étayée dans le matériel fourni : c'est une affirmation du README, pas un résultat reproduit ici.

Installation et configuration : ce que le README donne

Le README affiche un badge Docker et une section quick start, mais le texte nettoyé fourni ne contient pas les commandes exactes de lancement. Je ne peux donc pas les reproduire sans les inventer. Ce qui est confirmé : le projet est écrit en Go, il publie une image Docker, et il existe une instance de démonstration hébergée sur axonhub.onrender.com. Le point d'entrée pratique est la section quick start du README et l'index de documentation docs/zh/index.md, qui référence les guides par fonction. Le réglage qui compte le plus est celui des identifiants fournisseurs : sans clé valide pour au moins un fournisseur, la passerelle n'a rien vers quoi router. Les clés de configuration exactes et les variables d'environnement ne figurent pas dans le matériel dont je dispose, donc le lecteur doit les chercher dans le quick start et non dans cet article.

La bascule automatique a un coût de conception

Le failover et l'équilibrage de charge sont présentés comme des arguments. Ils impliquent une conséquence que le README ne discute pas : si une requête part vers un fournisseur, échoue, puis repart vers un autre, le second fournisseur reçoit un contexte qu'il n'a pas produit. Sur des modèles ayant des formats de tool calling ou de cache de prompt différents, la bascule n'est pas neutre. Le suivi des coûts par requête, décrit comme incluant les jetons de cache, suggère que le projet traite ces différences, mais le matériel ne détaille pas la politique appliquée. Autre limite visible : la branche par défaut s'appelle unstable. Ce n'est pas un détail cosmétique. Un dépôt dont la branche par défaut porte ce nom indique que le travail actif s'y trouve, et que la stabilité n'est pas la propriété visée par cette branche. Pour un composant placé sur le chemin critique de toutes les requêtes d'une application, c'est un point à peser avant de choisir la branche à déployer.

Licence non identifiée et rythme de publication

Le champ licence renvoie NOASSERTION. Concrètement, GitHub n'a pas réussi à classer le fichier de licence du dépôt dans une licence reconnue. Cela ne veut pas dire qu'il n'y a pas de licence, ni qu'il y en a une. Cela veut dire qu'un lecteur ne peut pas savoir depuis les métadonnées quels droits il obtient. Pour un composant qui voit passer toutes les clés d'API et tous les prompts d'une organisation, cette incertitude est matérielle : elle touche la redistribution, la modification et l'usage interne en entreprise. Le fichier LICENSE à la racine est le seul endroit qui tranche, et je ne peux pas le citer ici puisqu'il n'est pas dans le matériel fourni. Sur le rythme, les trois versions publiées avant le 9 septembre 2026 sont v1.0.0-beta8, beta9 et beta10, espacées de quelques jours. Une cadence de bêta serrée signifie deux choses opposées selon le point de vue : le projet bouge, et les interfaces de configuration peuvent bouger avec lui. Un déploiement en production sur une bêta suppose de relire les notes de version à chaque montée.

L'alternative sans service intermédiaire

La comparaison utile n'est pas un autre produit, c'est l'absence de produit. Une équipe peut écrire sa propre couche d'abstraction dans son application : une interface interne avec une méthode par opération, et une implémentation par fournisseur. La différence d'approche est nette. Dans ce cas, la traduction vit dans le même processus que l'appelant, elle est testée avec le reste du code, et il n'y a pas de saut réseau supplémentaire ni de service à superviser. En échange, chaque nouveau fournisseur demande du code, et le suivi des coûts, le RBAC et le traçage doivent être construits séparément. AxonHub déplace ce travail dans un service partagé, ce qui devient avantageux dès que plusieurs applications doivent parler aux mêmes fournisseurs avec les mêmes quotas et la même journalisation. En dessous de ce seuil, la couche maison reste plus simple à raisonner.

Ce qu'il faut vérifier avant d'adopter

Trois vérifications, dans cet ordre. D'abord le fichier LICENSE à la racine du dépôt, parce que NOASSERTION ne permet aucune conclusion. Ensuite la branche à déployer : unstable est la branche par défaut, ce qui n'en fait pas un choix de production évident, et les tags de version publiés sont tous en bêta. Enfin la documentation des guides, en particulier docs/zh/guides/load-balance.md, pour comprendre ce qui se passe quand une requête est rejouée vers un second fournisseur. Si ces trois points sont acceptables pour votre contexte, la promesse de garder le SDK existant et de changer de fournisseur par configuration est celle qui justifie l'essai. Si le premier point ne peut pas être tranché, il n'y a pas de raison d'aller plus loin.

Conclusion éditoriale

AxonHub s'adresse aux équipes qui veulent garder leur code SDK actuel tout en changeant de fournisseur par configuration. Il ne convient pas à qui a besoin d'une licence claire dès aujourd'hui : GitHub renvoie NOASSERTION et la branche par défaut est unstable. Avant tout déploiement, vérifiez le fichier LICENSE à la racine du dépôt, puis la configuration des clés dans la section quick start du README.

Sources officielles

1. Issues
2. looplj/axonhub on GitHub
3. Project website
4. README
5. Releases