BYOK — pourquoi c'est non-négociable dans le régulé

Mis à jour le 18 octobre 2026.

Les éditeurs d'IA proposent souvent deux modes de facturation : un pool partagé où vous payez une enveloppe forfaitaire qui couvre les tokens, ou un mode BYOK où vous renseignez votre propre clé API et payez votre provider en direct.

Dans le SaaS standard, le pool partagé est confortable. Dans le régulé, c'est intenable.

Le problème du pool partagé

Quand votre éditeur met votre clé OpenAI / Anthropic / Mistral à disposition de tous ses clients via une seule clé maître :

1. Vous perdez le détail comptable. Impossible de prouver à votre auditeur quel volume vous avez réellement consommé chez le provider — il vous facture une somme agrégée.
2. Vous perdez la trace contractuelle. Vos données passent par le compte de l'éditeur. La data processing agreement (DPA) avec OpenAI ne vous couvre plus directement.
3. Vous perdez la maîtrise du modèle. L'éditeur peut décider de basculer du modèle A vers le modèle B silencieusement, pour des raisons de coût. Vos benchmarks régressent et vous ne savez pas pourquoi.
4. Vous perdez la révocation immédiate. En cas d'incident, vous ne pouvez pas révoquer la clé sans demander à l'éditeur.

Ce que BYOK garantit

Avec BYOK :

• Vos prompts et complétions passent directement entre votre compte provider et betool — pas par un compte tiers mutualisé.
• Votre DPA avec le provider reste l'unique chaîne contractuelle. Pas de sous-traitance opaque.
• Votre facturation est lisible : OpenAI vous facture, vous voyez chaque ligne. betool vous facture seulement l'orchestration.
• Votre révocation est instantanée : vous régénérez la clé chez le provider, le modèle est inaccessible dans la seconde.

La version privée (modèles auto-hébergés)

Pour les organisations vraiment exigeantes (banque, défense, santé), même BYOK n'est pas suffisant : envoyer vos prompts vers OpenAI ou Anthropic reste un transfert vers les États-Unis.

La solution est un modèle privé :

• Ollama ou LM Studio sur votre GPU, pour les modèles open-weight (Llama, Qwen, Mistral, DeepSeek…).
• vLLM, ou tout serveur exposant l'API OpenAI, sur cluster GPU pour la production à haut débit.

Vos prompts ne quittent jamais votre périmètre. La latence est sous votre contrôle. La conformité est totale.

Ce que ça coûte

Le mythe veut qu'auto-héberger un LLM coûte une fortune. En réalité, pour les modèles open-weight de la génération actuelle :

• Un serveur GPU bi-A100 80 GB peut servir un modèle d'environ 70 milliards de paramètres en production.
• À usage modéré (quelques milliers d'exchanges / jour), un seul GPU A6000 suffit pour servir un modèle 32B avec une latence sous la seconde.
• Coût mensuel d'amortissement : ~$2000 à $5000 selon la stratégie d'achat (location vs achat).

Comparé à un usage équivalent OpenAI sur 12 mois, l'investissement est rentabilisé en quelques mois pour les volumes sérieux — et le ROI s'inverse si vous avez des contraintes de souveraineté qui rendent OpenAI inacceptable.

Notre choix

betool est BYOK natif depuis le jour 1 : chaque organisation peut brancher ses propres clés (OpenAI, Anthropic, Google) ou ses modèles privés (Ollama, LM Studio, endpoint compatible OpenAI), et la résolution privilégie toujours ses comptes propres.

Pour démarrer vite, la plateforme propose aussi des modèles managés : vous les utilisez sans clé, et chaque token est débité en crédits, modèle par modèle, sur votre facture betool. C'est un choix explicite, jamais un basculement silencieux.

Dans le régulé, notre recommandation reste BYOK :

• Le pool partagé crée une dette de conformité que vos auditeurs vous demanderont de justifier.
• L'asymétrie entre « petits clients » et « grands clients » sur la souveraineté n'est pas acceptable.
• L'expérience que nous voulons construire — « je vois exactement ce que je consomme, où, et chez qui » — n'est complète qu'en BYOK.

C'est une étape de plus à l'onboarding (15 minutes pour récupérer une clé chez votre provider). C'est un investissement qui se paye sur la durée.