Workflow de design BYOK : faites tourner Claude, Codex ou Qwen sur votre propre clé
La plupart des outils de design IA ajoutent discrètement une marge sur chaque token que vous dépensez. Open Design adopte la position inverse — apportez la clé de votre propre modèle, payez directement le fournisseur et gardez le contrôle total de l'endroit où s'exécute l'inférence. Voici comment fonctionne réellement la couche BYOK.
Si vous avez utilisé un produit de design IA hébergé en 2026, vous avez probablement remarqué la facture qui grimpe. Un abonnement par-dessus une facturation par siège, le tout superposé à une majoration d'inférence que personne ne publie. Le calcul est opaque, et c'est voulu.
Open Design n'exécute pas d'inférence. Nous n'avons aucune marge sur les tokens. L'ensemble du workflow est construit autour du bring-your-own-key (BYOK) — vous pointez le daemon vers n'importe quel endpoint compatible OpenAI, vous collez votre propre clé API, et c'est terminé.
Cet article explique pourquoi nous avons fait ce choix, comment cela fonctionne en coulisses, et ce que cela change réellement dans votre workflow au quotidien. Si vous voulez l'argument philosophique plus large derrière tout ça, pourquoi nous avons conçu Open Design comme une couche de skills en est le pendant — celui-ci est la version pratique.
Ce que « BYOK » signifie vraiment ici
Il y a deux définitions de BYOK qui circulent dans l'univers de l'outillage IA, et ce ne sont pas la même chose :
- BYOK de surface — l'outil vous laisse coller une clé, mais achemine quand même l'inférence via ses serveurs, journalise vos prompts et peut appliquer des limites de débit.
- BYOK réel — l'outil appelle directement le fournisseur du modèle depuis votre machine (ou votre infrastructure). Vos prompts ne touchent jamais les serveurs du fournisseur. Le fournisseur ne prend aucune marge.
Open Design est du second type. Le daemon effectue des appels HTTP vers l'endpoint que vous configurez, avec votre clé, depuis votre machine. Nous ne faisons pas de proxy. Nous ne journalisons pas. Nous ne voyons pas vos prompts.
Où part réellement l'appel
Lorsque le daemon prend en charge une tâche, il compose le prompt — en récupérant les fichiers SKILL.md et DESIGN.md pertinents pour la tâche — puis effectue une unique requête HTTP vers la base URL que vous avez définie. La réponse est renvoyée en streaming vers votre machine, l'agent écrit l'artefact sur le disque, et voilà toute la boucle. Il n'y a aucun serveur Open Design sur le chemin. Le même daemon qui découvre vos skills possède aussi l'appel réseau, c'est pourquoi « où cela s'exécute-t-il ? » est un paramètre et non une conversation commerciale.
L'adaptateur compatible OpenAI
La plupart des endpoints d'inférence IA en 2026 parlent l'API OpenAI Chat Completions. Nous l'utilisons comme protocole plus petit dénominateur commun. Si votre fournisseur la parle (et presque tous le font), vous êtes pris en charge par défaut — aucun plugin, aucune intégration par fournisseur à attendre.
Fournisseurs vers lesquels vous pouvez le pointer
| Fournisseur | Forme typique de la base URL | Idéal pour |
|---|---|---|
| OpenAI | https://api.openai.com/v1 | gpt-image-2, gpt-5.x, les passes générales les plus solides |
| Anthropic | shim de compatibilité OpenAI, ou l'adaptateur Claude dédié | raffinement axé sur le goût, briefs longs |
| DeepSeek | https://api.deepseek.com/v1 | rédaction long-contexte économique |
| Groq | base URL du fournisseur | cycles de brouillon à faible latence |
| OpenRouter | https://openrouter.ai/api/v1 | n'importe quel modèle de pointe, une seule relation de facturation |
| vLLM / TGI / Ollama auto-hébergés | votre propre hôte, p. ex. http://localhost:11434/v1 | travail entièrement local, confidentiel pour le client |
| Qwen / Kimi / Hermes | base URL du fournisseur | modèles régionaux avec endpoints compatibles OAI |
La liste n'est pas une liste d'autorisation codée en dur — c'est simplement là où les gens atterrissent couramment. Tout ce qui répond à la forme Chat Completions fonctionne.
Deux champs, puis redémarrage
La configuration tient en deux champs :
OPENAI_BASE_URL=https://api.deepseek.com/v1
OPENAI_API_KEY=sk-…Placez-les dans .env.local, redémarrez le daemon, et vous êtes sur un autre modèle. Basculer vers une instance Ollama locale pour un projet sensible tient aux deux mêmes lignes :
OPENAI_BASE_URL=http://localhost:11434/v1
OPENAI_API_KEY=ollamaIl n'y a aucun registre de modèles à mettre à jour, aucun compte à relier, aucune migration. La clé et l'endpoint constituent toute la surface.
Pourquoi cela compte pour le travail de design
Les workflows de design ont une structure de coût particulière que les produits à inférence hébergée gèrent mal :
- L'itération est l'unité de travail. Une vraie passe de design signifie 30 à 50 cycles de prompts, pas trois. Les forfaits hébergés brident durement autour des 50 cycles.
- Le long contexte est la norme. Un brief sérieux implique des documents de marque, des travaux antérieurs, des spécifications de système et de l'imagerie de référence. Ce contexte dépasse largement les budgets de tokens des interfaces hébergées.
- Le choix du modèle devrait être ad hoc. Certaines passes veulent un modèle rapide et bon marché. D'autres veulent le plus puissant disponible. D'autres veulent un modèle local pour du contenu sensible. Un produit hébergé en choisit un pour vous.
Le BYOK règle les trois. Vous payez au token, vous choisissez le modèle, vous n'êtes pas bridé.
L'itération cesse d'être rationnée
C'est ce qui change discrètement votre façon de travailler. Quand chaque cycle supplémentaire est décompté sur un forfait, vous commencez à vous auto-censurer — vous prenez le troisième brouillon parce que le quatrième semble coûteux. En BYOK, le coût marginal d'une passe de plus représente quelques centimes chez le fournisseur du modèle, donc la décision redevient une question de travail, pas de compteur. Le troisième brouillon est généralement là où le design devient bon ; un outil qui taxe l'itération taxe précisément l'étape qui compte.
Et le coût ?
Une inquiétude fréquente : « Si je paie directement, est-ce que ça ne sera pas plus cher ? »
En pratique, non. Voici une journée type de travail de design dans notre usage interne :
| Tâche | Tokens | Fournisseur | Coût |
|---|---|---|---|
| Réception du brief (3 docs) | 30K en entrée | Claude Sonnet | 0,09 $ |
| Première passe de brouillon | 80K en entrée + 20K en sortie | Claude Sonnet | 0,54 $ |
| 5 cycles d'itération | 250K en entrée + 80K en sortie | Claude Sonnet | 1,95 $ |
| Peaufinage final | 50K en entrée + 30K en sortie | Claude Opus (une passe) | 1,35 $ |
| Total de la journée | ~3,93 $ |
Cela représente un deck, deux variantes de landing et une exploration de marque. L'équivalent hébergé — en supposant un forfait « créateur » à 30 $/mois avec frais de dépassement — coûterait environ 50 $ pour le même travail, vous donnerait moins d'itérations et vous enfermerait dans un seul modèle.
Si vous voulez réduire les coûts, remplacez Claude Sonnet par DeepSeek V3.2 et la journée tombe sous le dollar. L'enjeu n'est pas qu'un modèle soit le bon — c'est que le curseur prix/qualité est entre vos mains plutôt que figé dans un palier d'abonnement.
Confidentialité et conformité
Il y a une seconde raison pour laquelle le BYOK compte : les prompts contiennent la marque de votre client.
L'inférence hébergée signifie faire transiter des documents de marque, des noms de produits non annoncés, des tarifs internes et de la création avant lancement par les serveurs d'un tiers. La plupart des entreprises ont un avis là-dessus. Certaines ont un contrat à ce sujet.
Avec le BYOK, l'aller-retour du prompt se fait entre votre ordinateur portable et le fournisseur du modèle que vous avez déjà validé (ou auto-hébergé). Open Design n'est pas dans la boucle. Nous n'avons aucun journal à assigner, aucune surface de fuite à exposer, aucun trou d'audit à expliquer.
Ce que « pas de journal » vous apporte en pratique
Pour le travail d'agence, les secteurs réglementés ou tout ce qui précède un lancement, c'est la seule position qui tienne. Si une revue de sécurité demande « où vont nos actifs de marque ? », la réponse est « vers le fournisseur du modèle prévu dans notre contrat, et nulle part ailleurs » — pas « vers le tableau de bord d'un fournisseur que nous ne contrôlons pas ». Auto-héberger un endpoint Ollama ou vLLM resserre encore les choses : les octets ne quittent jamais votre réseau. C'est le même arbitrage exploré dans le bilan de réalité du BYOK, qui est honnête sur les aspérités qui subsistent — les modèles locaux et les modèles de pointe ne sont pas interchangeables sur le goût, et vous êtes propriétaire de la surface d'injection de prompts.
Comment changer de fournisseur en cours de projet
L'un des avantages sous-estimés du BYOK est l'arbitrage de fournisseur pendant un projet :
- Brouillon — utilisez un modèle bon marché (DeepSeek V3.2, Qwen 3) pour le formulaire de questions et la première itération
- Raffinement — passez à Claude Sonnet ou GPT-5 pour les passes intermédiaires où le goût compte
- Contenu sensible — basculez vers un modèle Ollama local pour les prompts confidentiels du client
- Peaufinage final — consacrez une passe au modèle le plus puissant disponible (Opus, GPT-5 Pro)
Dans Open Design, changer revient à modifier deux lignes dans .env.local. Aucune migration, aucun ré-onboarding, aucune montée en gamme de forfait.
Un routage détaillé pour un brief
Concrètement, un seul brief de landing-page pourrait se dérouler ainsi :
# draft + first iterations — cheap and fast
OPENAI_BASE_URL=https://api.deepseek.com/v1
OPENAI_API_KEY=sk-…
# then, for the passes where taste decides the outcome:
OPENAI_BASE_URL=https://api.anthropic.com/v1 # via the compat shim
OPENAI_API_KEY=sk-ant-…Mêmes skills, même design system sur le disque, mêmes artefacts — seul le moteur derrière le workflow a changé. Parce que les skills et les systems ne sont que des fichiers (SKILL.md et DESIGN.md), rien dans votre configuration n'est lié à un modèle particulier. C'est ce que signifie réellement posséder le workflow : l'outil s'efface, et le modèle est un paramètre que vous changez selon les exigences du brief.
Essayez-le
Clonez le dépôt, définissez OPENAI_BASE_URL et OPENAI_API_KEY dans .env.local, lancez pnpm tools-dev. Le daemon utilisera l'endpoint que vous lui indiquez, avec le modèle que vous payez, selon le rythme que vous voulez.
Voilà toute l'histoire du BYOK. Aucun palier spécial, aucun parcours de mise à niveau, aucune relation de facturation avec nous. Vous payez le fournisseur du modèle, vous gardez vos clés, vous gardez vos prompts. Nous fournissons la couche.
Lectures associées
- Pourquoi nous avons conçu Open Design comme une couche de skills, pas un produit — le pari derrière le fait de livrer une couche fine plutôt qu'une application hébergée
- Le bilan de réalité du BYOK : 5 choses qui cassent — les compromis honnêtes et les aspérités du fait d'apporter sa propre clé
- 31 skills, 72 systems : comment fonctionne la bibliothèque Open Design — les fichiers
SKILL.md/DESIGN.mdqui restent constants quel que soit le modèle que vous exécutez