Peut-on auto-héberger Claude ? La réponse honnête

Pouvez-vous auto-héberger Claude ? Non, et voici pourquoi

Vous ne pouvez pas auto-héberger Claude. Anthropic ne publie pas les poids du modèle. Il n’existe donc aucun fichier à télécharger, aucun conteneur à exécuter et aucune licence permettant de le servir depuis votre propre matériel. Chaque requête adressée à Claude passe par l’API d’Anthropic ou par un partenaire hébergé tel qu’Amazon Bedrock, Google Vertex AI ou Microsoft Foundry. L’exécuter sur une machine que vous possédez n’est pas un problème de configuration. L’artefact n’existe tout simplement pas en dehors d’Anthropic.

C’est la réponse courte. En réalité, la plupart des personnes qui posent cette question ne veulent pas vraiment les poids du modèle. Elles veulent l’une des trois choses suivantes, qui sont toutes réalisables sur un serveur que vous contrôlez : un modèle performant exécuté localement, une passerelle qui conserve leurs clés d’API et plafonne leurs dépenses, ou un agent de programmation installé sur leur propre serveur plutôt que sur leur ordinateur portable. Ce guide couvre ces trois possibilités, avec les commandes.

Ce que signifie généralement « self-hosted Claude »

Les recherches sur « self-hosted Claude » correspondent à plusieurs besoins différents, qui appellent des réponses distinctes.

Certains utilisateurs veulent de la confidentialité. Ils ne veulent pas que leurs prompts quittent leur réseau. Seul un modèle local à poids ouverts répond à ce besoin, car toute requête Claude est, par définition, envoyée à Anthropic.

D’autres veulent maîtriser les coûts. Ils craignent qu’un agent incontrôlé consomme tous leurs crédits. Une gateway répond à ce besoin et fonctionne avec Claude : vous conservez donc la qualité du modèle.

D’autres encore veulent ne plus dépendre d’un laptop. Ils veulent qu’un agent continue à fonctionner même lorsque le capot est fermé. Un VPS répond à ce besoin, et Claude Code y fonctionne sans problème.

Certains recherchent l’équivalent de « self-hosted OpenRouter ». Il s’agit également d’une gateway, et la réponse habituelle est LiteLLM.

Déterminez lequel de ces besoins est le vôtre, car l’architecture adaptée diffère dans chaque cas.

Héberger un modèle ouvert avec Ollama

Si aucun prompt ne doit quitter votre serveur, utilisez un modèle à poids ouverts. Les familles réellement utilisables aujourd’hui sur un serveur loué sont Llama, Qwen, Mistral, Gemma et DeepSeek. Elles publient toutes des poids que vous pouvez télécharger et exécuter.

Ollama est le moyen le plus rapide de commencer. Le script d’installation tient sur une ligne et configure un service systemd sur Ubuntu.

curl -fsSL https://ollama.com/install.sh | sh
systemctl status ollama

systemctl status ollama doit afficher active (running). Téléchargez ensuite un modèle et utilisez-le.

ollama pull qwen3:8b
ollama run qwen3:8b "Summarise what a reverse proxy does in two sentences."

Le premier pull télécharge plusieurs gigaoctets. Le modèle doit donc tenir en mémoire vive ou dans la mémoire du GPU avant de pouvoir répondre. Pour les modèles quantifiés, comptez environ 6 GB libres pour un modèle de 8 milliards de paramètres, environ 10 GB pour un modèle de 14 milliards de paramètres, et davantage de mémoire que la plupart des offres VPS généralistes pour un modèle de 70 milliards de paramètres. Si le serveur manque de mémoire, le processus est tué par le kernel et vous voyez Error: llama runner process has terminated, avec une ligne indiquant l’épuisement de la mémoire dans dmesg. Vérifiez free -h avant d’incriminer le modèle. Ce même budget mémoire détermine aussi la longueur du prompt effectivement lue par le modèle, car Ollama tronque discrètement tout ce qui dépasse une fenêtre par défaut assez limitée. Augmenter num_ctx et dimensionner le cache KV est donc le premier point à vérifier lorsque de longs documents sont résumés partiellement.

Ollama expose également une API HTTP sur 127.0.0.1:11434. C’est ce qui le rend utile à d’autres logiciels, et pas seulement pour discuter avec un modèle.

curl http://127.0.0.1:11434/api/generate -d '{"model":"qwen3:8b","prompt":"ping","stream":false}'

Si la première requête après une période d’inactivité prend trente secondes, puis que la suivante revient instantanément, rien n’est cassé : Ollama décharge le modèle après cinq minutes d’inactivité, et le conserver en mémoire avec keep_alive supprime ce délai de rechargement.

Laissez ce port lié à localhost. Un port Ollama ouvert sur une adresse IP publique fournit gratuitement un GPU à quiconque le découvre. La configuration complète, avec l’unité systemd, la détection du GPU et la mise en place d’un reverse proxy, est décrite dans le guide pour exécuter Ollama sur un VPS. Si plusieurs utilisateurs doivent l’utiliser simultanément, consultez d’abord la comparaison entre Ollama et vLLM, car la conception à flux unique d’Ollama devient le goulot d’étranglement bien avant le matériel.

Soyez honnête sur les limites. Un bon modèle ouvert sur un VPS de taille moyenne est réellement utile pour résumer, classer, rédiger et effectuer des extractions simples. Pour le raisonnement long en plusieurs étapes, les grandes bases de code et l’utilisation d’outils par un agent, il reste loin derrière un modèle hébergé de pointe. Aucun réglage de prompt ne comble cet écart. Choisissez le modèle local pour les tâches qu’il réalise bien et payez un modèle hébergé lorsque la difficulté le justifie.

Exécuter votre propre gateway avec LiteLLM

C’est le « OpenRouter auto-hébergé » que beaucoup recherchent. Une gateway se place entre vos applications et chaque fournisseur de modèles. Vos applications utilisent une seule clé, qui pointe vers votre serveur. Les véritables clés des fournisseurs restent uniquement sur ce serveur. Vous pouvez plafonner les dépenses par clé, router différentes applications vers différents modèles et journaliser chaque requête au même endroit.

LiteLLM est un choix courant, car il fournit une API compatible avec OpenAI et fait office de proxy vers Anthropic, Ollama et la plupart des autres fournisseurs depuis le même endpoint. Exécutez-le dans Docker avec un fichier de configuration.

model_list:
  - model_name: claude
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: local
    litellm_params:
      model: ollama/qwen3:8b
      api_base: http://127.0.0.1:11434

Enregistrez ce contenu dans litellm_config.yaml, puis démarrez le proxy. Il écoute sur le port 4000.

docker run -v $(pwd)/litellm_config.yaml:/app/config.yaml \
  -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
  -e LITELLM_MASTER_KEY=sk-1234 \
  -p 4000:4000 docker.litellm.ai/berriai/litellm:latest \
  --config /app/config.yaml

LITELLM_MASTER_KEY est l’identifiant d’administration. Traitez-le comme un mot de passe root et ne déployez pas la valeur d’exemple. Appelez le proxy exactement comme vous appelleriez une API hébergée.

curl http://localhost:4000/v1/chat/completions \
  -H 'Authorization: Bearer sk-1234' \
  -H 'Content-Type: application/json' \
  -d '{"model": "claude","messages": [{"role": "user","content": "Say hello in five words."}]}'

Une réponse saine est un JSON normal contenant un tableau choices. Un 401 indique un échec d’authentification. Avec cette configuration, la cause habituelle est un en-tête Authorization qui ne correspond pas à votre clé principale. LiteLLM renvoie également cette erreur pour une clé virtuelle invalide. Une clé de fournisseur rejetée par le fournisseur (un ANTHROPIC_API_KEY incorrect, par exemple) échoue aussi lors de l’authentification, avec le nom du fournisseur dans l’erreur sous la forme <Provider>Exception. Un 400 qui mentionne le modèle indique souvent que le model de votre requête ne correspond à aucun model_name du fichier de configuration. LiteLLM renvoie également 400 lorsqu’une requête est trop longue pour la fenêtre de contexte du modèle. Lisez donc le message d’erreur avant de modifier la configuration.

L’intérêt de construire cette gateway plutôt que d’appeler directement Anthropic est de pouvoir plafonner les dépenses. Créez une clé virtuelle distincte pour chaque application, avec son propre budget.

curl 'http://0.0.0.0:4000/key/generate' \
--header 'Authorization: Bearer sk-1234' \
--header 'Content-Type: application/json' \
--data-raw '{"models": ["claude"], "max_budget": 100}'

Les clés virtuelles et les budgets nécessitent une base de données Postgres derrière le proxy. Le docker run ci-dessus n’en utilise aucune. Ajoutez-y d’abord -e DATABASE_URL=postgresql://user:password@host:5432/litellm. Sans base de données, cet appel échoue avec No connected db.

Cette clé peut dépenser cent dollars et accéder à un seul modèle, et à rien d’autre. Lorsqu’un agent se comporte mal à trois heures du matin, l’impact se limite à une clé au lieu de concerner tout votre compte. Ce modèle, ainsi que la supervision associée, est présenté dans la maîtrise des coûts des agents sur un VPS. Si vous hésitez encore à payer à l’unité, la comparaison des coûts entre API et abonnement détaille le calcul.

Notez ce que la gateway ne fait pas. Elle ne rend pas Claude local et ne masque pas vos prompts à Anthropic. Les requêtes quittent toujours votre serveur vers le fournisseur. Vous gagnez en revanche le contrôle des clés, des dépenses, du routage et des journaux.

Exécuter Claude Code sur votre propre VPS

Le troisième souhait est le plus facile à exaucer. Claude Code est un client. Il s’installe sous la forme d’un binaire natif unique et communique avec l’API via HTTPS. L’installer sur un serveur dont vous avez la maîtrise permet à l’agent de continuer à fonctionner après l’arrêt de votre ordinateur portable. Son périmètre d’impact se limite ainsi à une machine que vous pouvez reconstruire, plutôt qu’à votre machine principale.

npm install -g @anthropic-ai/claude-code
claude --version

Le package npm nécessite Node.js 22 ou une version ultérieure. Avec une version plus ancienne de Node.js, l’installation affiche uniquement un avertissement EBADENGINE et se termine quand même. L’installeur natif recommandé par Anthropic, curl -fsSL https://claude.ai/install.sh | bash, ne nécessite pas Node.js. Dans les deux cas, le binaire claude installé ne s’exécute pas avec Node. Anthropic indique 4 GB de RAM comme minimum. Dimensionnez donc le VPS en conséquence.

Exécutez-le dans tmux afin qu’une déconnexion SSH ne mette pas fin à une tâche longue. Cette configuration, y compris la gestion des sessions, est présentée dans exécuter Claude Code sur un VPS avec tmux. Attribuez à l’agent son propre utilisateur sans privilèges. Consultez également les règles de sécurité pour exécuter Claude Code sur un serveur avant de lui accorder un accès en écriture à des données importantes.

Il s’agit d’auto-héberger l’agent, pas le modèle. Il est important de le préciser, car ces deux aspects sont souvent confondus. Vous contrôlez le processus, le système de fichiers, les connexions réseau sortantes et les journaux. Anthropic contrôle toujours l’inférence.

Ce que chaque option vous coûte réellement

Les prix évoluent. Considérez donc ces montants comme un ordre de grandeur et non comme un devis. Au 17 octobre 2026, Claude Sonnet 5.5 est facturé 2 $ par million de tokens en entrée et 10 $ par million de tokens en sortie. Claude Opus 5.5 est facturé respectivement 4 $ et 20 $. Sonnet 5, le modèle utilisé dans la configuration de la gateway ci-dessus, a été remplacé par Sonnet 5.5, mais n’est pas obsolète : la page des dépréciations de modèles d’Anthropic l’indique comme Active, avec un retrait prévu au plus tôt le 30 juin 2027. Il coûte toujours 2 $ et 10 $, tandis qu’Opus 5 reste facturé 5 $ et 25 $. Un modèle local ne coûte rien par token. Il coûte à la place le prix mensuel du serveur, que vous l’utilisiez ou non.

Le seuil de rentabilité est plus bas qu’on ne le pense. Un VPS doté de suffisamment de mémoire pour exécuter un modèle open source utile coûte réellement de l’argent chaque mois, et reste la plupart du temps inactif. Si votre utilisation est irrégulière, l’API hébergée est généralement moins chère. Si votre utilisation est constante, ou si vos données ne peuvent pas quitter votre réseau, le modèle local est avantageux sur les deux plans.

La réponse mixte et réaliste est celle que retiennent la plupart des équipes. Exécutez localement un modèle open source pour les tâches volumineuses et peu complexes. Acheminez les requêtes difficiles vers un modèle frontier hébergé. Placez une gateway devant les deux afin que les applications n’aient pas besoin de savoir lequel est utilisé et que vous puissiez déplacer la frontière entre eux sans modifier le code applicatif. Cette architecture est la version concrète de « Claude auto-hébergé ». Contrairement à la version littérale, elle existe. Si vous souhaitez également exécuter vous-même toute la stack de l’agent, le récapitulatif des agents IA auto-hébergés présente les solutions disponibles.

FAQ

Puis-je télécharger les poids du modèle de Claude et l’exécuter localement ?

Non. Anthropic n’a jamais publié les poids d’un modèle Claude et aucune licence n’autorise l’auto-hébergement. Tout ce qui est présenté en ligne comme un « modèle Claude » téléchargeable est soit un autre modèle auquel on a donné un nom trompeur, soit un wrapper qui appelle l’API. S’il nécessite une clé d’API, il ne s’exécute pas localement.

Quel est le modèle open source le plus proche de Claude ?

Il n’existe pas d’équivalent exact et les modèles leaders changent tous les quelques mois. Les familles à poids ouverts qui méritent d’être testées sont Llama, Qwen, Mistral, Gemma et DeepSeek. Pour la synthèse, la classification et les modifications simples de code, un bon modèle ouvert de 8 à 14 milliards de paramètres est réellement utile. Pour le raisonnement en plusieurs étapes sur de longs contextes et l’utilisation agentique d’outils, l’écart avec un modèle de pointe hébergé reste important. Testez-les avec vos propres prompts au lieu de vous fier à un classement.

LiteLLM est-il un OpenRouter auto-hébergé ?

Fonctionnellement, oui, pour le routage et la gestion des clés. LiteLLM s’exécute sur votre serveur, expose un endpoint compatible avec l’API OpenAI et sert de proxy vers Anthropic, Ollama et la plupart des autres fournisseurs. Une fois une base de données Postgres configurée, vous bénéficiez de plafonds de dépense par clé, ainsi que du routage des modèles et d’un emplacement unique pour consulter les journaux. En revanche, LiteLLM ne fournit pas d’inférence locale : les requêtes vers Claude transitent toujours par Anthropic.

L’exécution de Claude Code sur mon propre serveur protège-t-elle la confidentialité de mon code ?

Non. Claude Code envoie à l’API Anthropic le contenu des fichiers qu’il lit, quel que soit l’endroit où le processus s’exécute. Un VPS vous apporte l’isolation de l’agent, pas la confidentialité du contenu. Attribuez-lui un utilisateur dédié sans privilèges, empêchez-le d’accéder aux identifiants et aux dépôts sans rapport, et considérez tout ce qu’il peut lire comme du contenu qui quitte le serveur.