OAuth, abonnements et le chemin cloud le plus simple
Après la douche froide du CPU local, il fallait un chemin cloud pour l'interactif. Deux tentatives, un échec net et un succès immédiat : la question qui compte n'est pas quel cloud est le meilleur, mais lequel se branche simplement sans faire exploser la facture. Sixième article de la série.
Par Nicolas Cousin — Publié le 20 octobre 2026
OAuth, abonnements et le chemin cloud le plus simple
TL;DR
Après avoir mesuré à quel point le CPU local est lent pour l'interactif
(~4 min 44 pour une question simple, contre ~3 s dans le cloud), j'avais
besoin d'un chemin cloud fiable pour les tâches qui ne peuvent pas
attendre. Deux tentatives : Claude via OAuth dans Hermes, qui a échoué
malgré un abonnement Claude Code actif (401 invalid x-api-key), et
ChatGPT/Codex via abonnement, qui a fonctionné du premier essai. Ce n'est
pas un comparatif de providers, juste le constat de ce qui s'est branché
simplement et ce qui ne s'est pas branché du tout.
Sommaire
- Pourquoi il fallait un chemin cloud simple
- Claude via OAuth dans Hermes : la fausse bonne idée
- ChatGPT / Codex : ça a marché du premier coup
- Ce que je retiens
Pourquoi il fallait un chemin cloud simple
Le mode background d'Hermes absorbe une partie du problème de lenteur du CPU local, mais pas tout : certaines tâches restent interactives par nature, et attendre plusieurs minutes une réponse à une question de routine n'est pas tenable au quotidien. Je voulais un chemin cloud pour ces cas-là, mais avec une contrainte précise : je paie déjà un abonnement Claude Code et un abonnement OpenAI, je ne voulais pas ajouter une troisième facturation, séparée et à l'usage, juste pour brancher un provider dans Hermes.
Deux options évidentes, donc : faire passer Hermes par mon abonnement Claude Code, ou par mon abonnement ChatGPT/Codex. Dans les deux cas, l'objectif était le même : réutiliser un abonnement déjà payé plutôt que d'ouvrir une clé API facturée au token. Si l'un des deux chemins refuse de fonctionner en réutilisant l'abonnement, l'alternative qui reste est justement celle que je voulais éviter : payer l'accès API séparément.
Claude via OAuth dans Hermes : la fausse bonne idée
Sur le papier, ça semblait direct : provider Anthropic, authentification
OAuth via Claude Code, génération d'un jeton avec claude setup-token.
ANTHROPIC_TOKEN et ANTHROPIC_API_KEY présents dans l'environnement,
l'ancienne clé API nettoyée pour ne pas créer de conflit. Résultat, malgré
ça : 401 invalid x-api-key, systématiquement.
Je n'ai pas creusé plus loin côté implémentation d'Hermes pour confirmer
la cause exacte, mais une hypothèse plausible, non vérifiée : le jeton
généré par claude setup-token est probablement pensé pour l'usage de
l'outil officiel, pas pour être envoyé tel quel comme une clé API générique
par un client tiers. La leçon que je retiens, elle, ne dépend pas de cette
hypothèse : pouvoir utiliser Claude Code avec son abonnement ne signifie
pas automatiquement qu'un orchestrateur tiers peut réutiliser ce même
abonnement comme backend. Concrètement, la seule alternative pour faire
passer Claude par Hermes aurait été de payer un accès API Anthropic
séparé, exactement la dépense supplémentaire que je cherchais à éviter en
partant de l'abonnement plutôt que de l'API.
ChatGPT / Codex : ça a marché du premier coup
Deuxième tentative, provider Hermes configuré en OpenAI → ChatGPT/Codex subscription. Aucune complication comparable à l'échec côté Claude :
gpt-5.6-sol a fonctionné correctement dès la première requête, avec une
bonne veille .NET/F# sur les questions testées, et sans facturation
supplémentaire à surveiller.
C'est précisément la différence qui compte pour ce chemin cloud : pas « quel modèle est le meilleur », mais lequel des deux abonnements déjà payés a effectivement pu remplacer une clé API séparée sans coût additionnel.
Ce que je retiens
Je ne tire pas de ça un classement de providers : deux tentatives, un échec et un succès, ce n'est pas un panorama exhaustif, et l'échec côté Claude tient peut-être à un détail de configuration que je n'ai pas identifié plutôt qu'à une limite de fond. Ce que je retiens, c'est plus étroit : des deux abonnements que je payais déjà, un seul a pu servir de backend à Hermes sans facturation additionnelle, et c'est celui-là que j'ai gardé, pas par préférence de principe mais parce que c'est celui qui a marché du premier coup, sans détour par une facturation séparée. La suite de la série s'appuie sur ce choix par défaut.