Pourquoi je lance mon assistant IA dans un container Docker (et pourquoi vous devriez faire pareil)

Parlons vrai. Avec les agents de coding IA, on a deux options lamentables. Soit tu vires toutes les protections et tu laisses ton agent galoper librement sur ta machine. Soit tu restes planté devant ton écran à cliquer « Approuver » toutes les trente secondes comme un démineur en pleine crise.

Pendant longtemps, j'étais le type qui cliquait. Et ouais, c'était le comportement responsable. Mais concrètement ? Un vrai massacre pour ma productivité. Chaque fois que Claude Code voulait exécuter une commande, installer un package, ou modifier un fichier, je sortais de mon flow pour jouer les baby-sitters.

Ensuite, j'ai regardé des potes partir dans l'autre extrême : mode YOLO total, zéro garde-fou, que du vibes et de la prière. Franchement, ça m'inquiétait encore plus. Ces agents sont puissants, mais suffisamment autonomes pour causer de vrais dégâts si quelque chose se passe mal.

Le terrain d'entente qui a tout changé pour moi : conteneuriser l'agent de coding.

L'idée de base

Au lieu de lancer ton assistant IA directement sur ta machine hôte, tu le démarrer dans un container Docker avec le répertoire de travail montés dedans. L'agent fait son job dans le container, où ses capacités destructrices sont contenues. S'il décide de tout supprimer ? Nickel, il supprime le filesystem du container, pas ta vraie machine.

Concrètement, ça veut dire que tu peux utiliser les fonctionnalités YOLO comme --dangerously-skip-permissions sans la terreur de voir ton home directory disparaître.

Voici comment ça fonctionne.

Configurer Claude Code dans Docker

Le setup le plus simple commence avec un Dockerfile :

FROM node:20-bookworm-slim

RUN apt-get update && apt-get install -y --no-install-recommends git curl ca-certificates && rm -rf /var/lib/apt/lists/*

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

ENV PATH="/root/.local/bin:${PATH}"

WORKDIR /workspace

ENTRYPOINT ["claude", "--dangerously-skip-permissions"]

Build une fois :

docker build -t claude-code .

Puis lance avec ton répertoire courant mounté :

docker run -it -v "$PWD:/workspace" claude-code

Et voilà, tu as Claude Code qui tourne avec accès à tes fichiers projet. Le container peut lire, écrire et exécuter librement dans le workspace, mais il est sandboxé du système réel.

Le problème d'authentification

Voilà où ça devient intéressant. Sur Mac, Claude Code stocke les credentials dans Keychain. Les containers Linux ne parlent pas Keychain. Donc il faut gérer l'authentification autrement.

La solution : passer un token API en variable d'environnement. D'abord, récupère ton setup token :

claude setup-token

Ensuite, crée un petit script d'entrée qui lit ce token et configure le fichier credentials du container :

#!/bin/bash
echo "${ANTHROPIC_TOKEN}" > /root/.claude/credentials.json
exec claude --dangerously-skip-permissions

Maintenant, quand tu lances le container, tu passes juste le token :

docker run -it -v "$PWD:/workspace" -e ANTHROPIC_TOKEN="$(claude setup-token)" claude-code

Rendre ça vraiment pratique

Soyons honnêtes : tu n'as pas envie de taper tout ça à chaque fois. Crée un alias ou une fonction shell :

cc() {
    docker run -it \
        -v "$PWD:/workspace" \
        -v "$HOME/.claude:/root/.claude" \
        -v "$HOME/.claude/skills:/root/.claude/skills" \
        -v "$HOME/.claude/settings.json:/root/.claude/settings.json:ro" \
        -e ANTHROPIC_TOKEN="$(claude setup-token 2>/dev/null)" \
        --env-file ~/.claude/env \
        claude-code "$@"
}

Ce setup :

• Monte ton répertoire courant comme /workspace
• Passe ta config Claude et tes skills
• Charge les variables d'environnement (pratique pour les clés API dont l'agent pourrait avoir besoin)
• Te permet d'appeler cc de n'importe où et avoir immédiatement un agent de coding opérationnel

Ce que ça ne protège PAS

Je veux être clair sur le modèle de menace. La conteneurisation protège ta machine hôte des actions de l'agent. Ça ne te protège PAS de :

• Les attaques par prompt injection : si un attaquant peut influencer ce que voit l'agent, il pourrait le piéger pour exfiltrer ton code ou tes secrets
• L'exposition des clés API : l'agent a toujours accès aux clés qu'il peut lire dans le workspace ou l'environnement
• Les attaques réseau : le container a toujours accès réseau
• Les problèmes de supply chain : les packages malveillants que l'agent installe dans le container restent malveillants

Ce que tu gagnes, c'est la protection contre « oups, l'agent a supprimé mon home directory » ou « il a lancé rm -rf / et maintenant je suis mort. » Pour moi, ça a valu le coup de setup bien des fois.

C'est overkill ?

Honnêtement ? Ça dépend de ce que tu fais. Pour les scripts rapides et les tasks ponctuelles, je lance encore Claude Code directement avec les prompts de permission normaux. Mais pour du feature development sérieux, du refactoring, ou quand je bosse sur un repo qui compte ? Le setup en container m'a fait gagner des heures de clics d'approbation cumulés et m'a offert une vraie tranquillité d'esprit.

Le mieux, c'est qu'une fois que tu comprends le concept, tu peux l'adapter. Différents agents de coding auront différents gotchas — emplacements de stockage des credentials, formats de config, besoins d entrypoint — mais le principe reste le même : isoler l'agent, lui donner un accès contrôlé à ton travail, et le laisser tourner sans que tu surveilles ses moindres faits et gestes.

En conclusion

On est dans une période de transition intéressante avec les outils de coding IA. Les safety defaults sont conservatrices pour de bonnes raisons — ces agents sont puissants et autonomes. Mais les defaults conservatrices signifient souvent « conçu pour des gens qui découvrent l'outil » plutôt que « conçu pour un usage professionnel quotidien. »

La conteneurisation est une façon de combler ce fossé. C'est pas de la sécurité parfaite, mais c'est une protection pratique qui te permet de vraiment capturer les gains de productivité de ces outils sans jouer au whack-a-mole des permissions.

Essaie. Une fois que t'as l'alias de configuré et que tu appelles cc depuis ton terminal pour avoir un agent de coding full equipped en quelques secondes, tu reviendras pas en arrière.

Ton setup pour lancer des agents de coding IA ? Tu cliques encore sur approuver ? Mode YOLO total ? Tu as une astuce de conteneurisation que j'ai ratée ? J'aimerais savoir comment les autres gèrent cet équilibre.