Faire tourner un agent IA en autonomie sur un VPS — et pourquoi je passe par Bedrock en production

Mettre un agent IA sur un VPS, c'est vingt minutes de travail. Un apt install, une clé API dans un fichier .env, un cron, et vous avez une machine qui trie vos logs toutes les nuits. Ça marche vraiment, et c'est assez satisfaisant.

Le problème arrive plus tard : le jour où ce montage ne tourne plus sur votre serveur perso mais chez un client, avec ses données, sa facture et son DSI qui pose des questions. À ce moment-là, la clé API dans le .env devient un vrai sujet, et il n'y a pas de rustine élégante.

Cet article fait les deux : le montage qui fonctionne, puis la version que je déploie réellement en production, basée sur Amazon Bedrock. Le basculement de l'une à l'autre tient dans une variable d'environnement — c'est tout ce qui sépare un side-project d'une infrastructure auditable.

Le montage de base : claude -p sur un VPS

Claude Code n'est pas seulement une interface interactive dans un terminal. Le drapeau -p (ou --print) le fait basculer en mode non interactif : il lit son entrée standard, écrit sur la sortie standard et rend la main avec un code de sortie. Autrement dit, il se comporte comme grep ou jq, et se pilote depuis n'importe quel script shell.

C'est ce qui rend l'agent déployable : plus besoin de session, de TTY ou de tmux qui traîne. Un VPS d'entrée de gamme suffit — l'inférence tourne côté API, la machine ne fait qu'orchestrer.

curl -fsSL https://claude.ai/install.sh | bash

export ANTHROPIC_API_KEY="sk-ant-..."

claude -p "Résume les erreurs de ce log" < /var/log/app/error.log

Les quatre drapeaux qui comptent

• --bare — désactive la découverte automatique des hooks, skills, plugins, serveurs MCP et fichiers CLAUDE.md. Sans lui, votre agent charge tout ce qui traîne dans le répertoire de travail et dans ~/.claude. En production, c'est le drapeau qui garantit que la commande fait la même chose sur toutes les machines.
• --output-format json — renvoie un objet structuré au lieu de texte libre : le résultat, l'identifiant de session, l'usage en tokens et le coût de l'exécution. C'est ce qui rend le pilotage possible : vous parsez avec jq et vous branchez sur la sortie.
• --allowedTools — la liste blanche des outils autorisés sans confirmation. La syntaxe accepte le préfixe : Bash(git diff *) autorise toutes les commandes qui commencent par git diff. L'espace avant l'astérisque est significatif.
• --append-system-prompt — ajoute des instructions au prompt système sans écraser le comportement par défaut. C'est là que vous définissez le rôle de l'agent : relecteur sécurité, trieur d'incidents, rédacteur de rapport.

#!/usr/bin/env bash
set -euo pipefail

cd /srv/projet

git diff origin/main | claude --bare -p \
  --append-system-prompt "Tu es ingénieur sécurité. Signale uniquement
  les vulnérabilités exploitables, avec fichier et ligne." \
  --output-format json \
  --allowedTools "Read" \
  | jq -r '.result' > /var/reports/revue-$(date +%F).md

Un timer systemd, une entrée de cron, et vous avez un agent qui produit un rapport de revue tous les matins. C'est réellement utile, et ça coûte quelques centimes par exécution.

Ce qui casse dès que ce n'est plus votre side-project

Le montage ci-dessus est parfaitement viable sur votre serveur personnel. Il devient difficile à défendre le jour où il tourne chez un client. Quatre points bloquent, et aucun ne se règle avec une meilleure organisation de fichiers.

La version production : le même agent, via Amazon Bedrock

Amazon Bedrock sert les modèles Claude depuis l'intérieur d'un compte AWS. Pour l'agent, rien ne change : mêmes commandes, mêmes outils, même prompt. Ce qui change, c'est tout ce qu'il y a autour de l'appel.

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=eu-west-3

# Épinglage du modèle (fortement recommandé)
export ANTHROPIC_MODEL='eu.anthropic.claude-sonnet-4-5-20250929-v1:0'

claude --bare -p "Résume les erreurs de ce log" < /var/log/app/error.log

Il n'y a plus de ANTHROPIC_API_KEY dans l'environnement. Claude Code utilise la chaîne de credentials standard du SDK AWS : sur une instance EC2, il récupère les credentials temporaires du rôle IAM attaché à la machine. Aucun secret n'est écrit sur disque, et la rotation est gérée par AWS.

La politique IAM minimale

C'est le cœur du sujet : les permissions de l'agent deviennent une ressource déclarative, versionnée dans votre Terraform, revue en pull request.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "bedrock:InvokeModel",
      "bedrock:InvokeModelWithResponseStream",
      "bedrock:ListInferenceProfiles",
      "bedrock:GetInferenceProfile"
    ],
    "Resource": [
      "arn:aws:bedrock:*:*:inference-profile/*",
      "arn:aws:bedrock:*:*:foundation-model/*"
    ]
  }]
}

Restreignez la ressource aux ARN des profils d'inférence que l'agent a réellement le droit d'appeler et vous obtenez un périmètre net : cet agent-là, sur ces modèles-là, dans ce compte-là.

Ce que ça change concrètement

aws bedrock list-inference-profiles --region eu-west-3

Épinglez vos modèles

Sans épinglage explicite, les alias sonnet et opus se résolvent vers les valeurs par défaut de Claude Code, qui évoluent avec les versions et peuvent ne pas être activées dans le compte du client. Sur un parc de machines, c'est la garantie d'un comportement qui change tout seul un matin — et d'une facture qui change avec, un modèle Opus coûtant sensiblement plus cher qu'un Sonnet.

export ANTHROPIC_DEFAULT_SONNET_MODEL='eu.anthropic.claude-sonnet-4-5-20250929-v1:0'
export ANTHROPIC_DEFAULT_HAIKU_MODEL='eu.anthropic.claude-haiku-4-5-20251001-v1:0'

En environnement d'entreprise, on va plus loin : les profils d'inférence applicatifs permettent de router chaque version de modèle vers un ARN géré par l'organisation, avec ses propres quotas et son propre suivi de coût.

Et si le client n'est pas sur AWS ?

L'argument de cet article n'est pas « utilisez Bedrock ». Il est qu'un agent en production ne doit pas porter de secret statique, doit être traçable, plafonné, et maîtrisé quant à la localisation de ses données. Bedrock est une façon d'obtenir ces quatre propriétés quand le client est déjà sur AWS. Ce n'est pas la seule.

Sur GCP, Azure ou une infrastructure mixte, la réponse habituelle est une passerelle LLM — LiteLLM en étant l'implémentation open source la plus répandue. Elle s'intercale entre l'agent et le fournisseur et rend exactement le même service : la clé du fournisseur reste côté serveur, chaque service ou chaque développeur reçoit son propre identifiant, la consommation est attribuée, budgets et limites s'appliquent en un point unique, et chaque requête est journalisée.

Côté agent, la bascule tient là encore en une variable :

export ANTHROPIC_BASE_URL=https://passerelle.interne.example.com

La passerelle apporte même une propriété que Bedrock n'a pas : changer de fournisseur se fait dans sa configuration, sans toucher aux machines qui exécutent les agents.

La contrepartie est réelle, et il faut la poser avant de s'engager : la passerelle devient une brique d'infrastructure que vous exploitez. Elle doit suivre les évolutions du client — une passerelle qui ne relaie pas une nouvelle capacité casse la fonctionnalité correspondante. Et Anthropic ne maintient ni n'audite les produits de passerelle tiers.

Avant de laisser tourner : ce qu'il faut verrouiller

Un agent autonome sur une machine exposée, c'est un processus qui exécute des commandes shell décidées par un modèle, à partir de contenus qu'il lit. Ces contenus — un log, une issue GitHub, un fichier déposé par un tiers — ne sont pas de confiance. Cinq règles, dans l'ordre d'importance :

• Pas de --dangerously-skip-permissions sur une machine exposée. Le bon réglage est une liste blanche via --allowedTools, éventuellement combinée au mode dontAsk qui refuse tout ce qui ne figure pas dans vos règles d'autorisation ou dans l'ensemble des commandes en lecture seule. Un agent qui plante parce qu'il lui manque une permission est un bon signal ; un agent qui a tous les droits n'en émet aucun.
• Un utilisateur système dédié, non privilégié. Pas de root, pas de compte de déploiement partagé. L'agent n'a accès qu'aux répertoires sur lesquels il doit travailler, et un rôle IAM qui ne porte que les actions Bedrock nécessaires — surtout pas les credentials d'administration du compte.
• Un egress réseau restreint. Groupe de sécurité en sortie limité à ce dont l'agent a besoin. C'est le filet qui limite les dégâts si un contenu malveillant réussit à influencer une commande.
• Un plafond de temps d'exécution. Un TimeoutStartSec côté systemd, ou un timeout autour de l'appel. À la réception d'un SIGTERM, Claude Code interrompt le tour en cours, termine l'arborescence de processus des commandes lancées et sort avec le code 143 — l'arrêt est propre, encore faut-il le déclencher.
• Des journaux conservés. Redirigez la sortie JSON vers un fichier ou CloudWatch. Le jour où l'agent fait quelque chose d'inattendu, la trace complète de la session est la seule chose qui permet de comprendre.

Clé API ou Bedrock : le tableau

Le verdict est assez simple. Pour prototyper, explorer, automatiser vos propres tâches : la clé API, sans hésiter, c'est plus rapide et le surcoût de gouvernance ne se justifie pas. Dès qu'il y a un client, des données qui ne vous appartiennent pas ou un budget à défendre : une architecture gouvernée — Bedrock si le client est déjà sur AWS, une passerelle LLM sinon. Dans les deux cas, le passage se fait sans réécrire une ligne de l'agent.

Questions fréquentes