Configuration de développement : optimiser l'« environnement de travail » de Claude

📚 Navigation de la série : L'article précédent 45 Agent SDK vous a appris à extraire les fonctionnalités de Claude Code pour les intégrer à vos propres programmes. Cette étape revient au terminal dans lequel vous tapez vos commandes quotidiennement — où s'exécute Claude, à quoi peut-il accéder, utilise-t-il un proxy, à quoi ressemble son interface et quel modèle utilise-t-il ; il est temps d'ajuster ces cinq aspects de l'« environnement de travail » selon vos besoins. Cet article détaille les configurations de développement les plus courantes.

Commençons par aborder un scénario auquel beaucoup d'utilisateurs sont confrontés.

De nombreux développeurs utilisent Claude Code pendant les premiers mois dans son état d'origine par défaut, sans rien modifier. Jusqu'au jour où ils doivent intervenir sur un dépôt privé appartenant à un client, ce qui peut susciter des inquiétudes — ce code n'a jamais été audité, et si une commande malveillante venait à s'exécuter, elle s'exécuterait directement sur leur propre Mac personnel, accédant à leurs clés SSH, leurs jetons npm et l'ensemble de leurs fichiers professionnels confidentiels. Quelle est alors la « mesure de protection » habituelle ? Garder les yeux grand ouverts pour surveiller chaque commande, le doigt posé sur Ctrl+C. Passer l'après-midi ainsi est épuisant, et s'avère peu productif.

Pourtant, la documentation officielle propose une solution depuis le début — exécuter Claude dans un environnement isolé, qu'il s'agisse d'un bac à sable, d'un conteneur ou d'une machine virtuelle, afin que ses actions ne puissent pas affecter la machine hôte. Cette surveillance manuelle fastidieuse est simplement le résultat d'un manque de lecture de la documentation.

Cet exemple montre l'intérêt de maîtriser les configurations de développement. Ces options discrètes s'avèrent cruciales pour la sécurité, la maîtrise des coûts et le confort d'utilisation. Nous allons détailler les cinq aspects les plus courants : leur utilité, quand et comment les configurer.

Après avoir lu cet article, vous obtiendrez :

• Une description simple du rôle et du cas d'usage de chacune des cinq configurations de développement (bac à sable, devcontainer, réseau, terminal, modèle)
• Comment activer un bac à sable (sandbox) en une seule commande /sandbox pour réduire les invites de permission tout en sécurisant l'exécution
• Le rôle d'un devcontainer, sa différence avec le bac à sable et son intérêt pour les équipes
• Comment configurer Claude Code derrière un proxy ou un pare-feu d'entreprise (indispensable pour les environnements réseau contraints)
• Les trois réglages essentiels du terminal (retour à la ligne, notifications, thème) et comment choisir et optimiser le coût des modèles selon la tâche
• Une mise en pratique pas à pas : activer le bac à sable et configurer le modèle, avec les résultats attendus

---

01 Structurer l'approche : les cinq aspects de l'« environnement de travail » de Claude

Avant de modifier les paramètres, organisons ces concepts. La « configuration de développement » n'est pas une simple liste d'interrupteurs indépendants, elle régit les cinq facettes d'un même sujet : l'« environnement de travail » dans lequel s'exécute Claude.

Analogie : organiser le poste de travail d'un nouvel ouvrier. Lorsqu'un ouvrier (Claude) arrive pour travailler, vous devez configurer son poste de travail : dans quel espace travaille-t-il (directement sur votre machine ou dans un atelier fermé isolé), où mènent les accès de cet espace (à quels réseaux peut-il se connecter, peut-il franchir le pare-feu de l'entreprise), les outils de travail sont-ils ergonomiques (comportement du retour à la ligne, notifications et thème du terminal) et quel est le niveau de compétence de la personne affectée (quel modèle utiliser). Une fois ces aspects réglés, le travail peut être effectué efficacement et en toute sécurité. La configuration de développement correspond à cette « organisation du poste de travail ».

Dans Claude Code, ces cinq dimensions sont :

• Isolation (où s'exécute le travail) — le bac à sable / devcontainer, qui détermine à quels éléments de votre machine physique Claude peut accéder lors de l'exécution des commandes.
• Réseau (où mènent les accès) — la configuration du proxy et des certificats, qui détermine si l'outil peut se connecter derrière un pare-feu d'entreprise.
• Terminal (ergonomie du poste) — le retour à la ligne, les notifications, les thèmes et le mode Vim, pour un confort d'utilisation optimal.
• Modèle (qui effectue le travail) — l'utilisation d'Opus, de Sonnet ou de Haiku, pour arbitrer entre performance et coût.

Voici un tableau synthétique pour comparer le rôle de chaque configuration :

Domaine	Problème résolu	Cas d'usage typique
Bac à sable (sandbox)	Réduire les invites de permission tout en sécurisant l'exécution	Limiter les demandes d'autorisation ou manipuler du code externe non audité
devcontainer	Fournir un environnement de travail identique et isolé pour toute l'équipe	Collaboration, tâches automatisées sans surveillance, uniformisation de l'environnement
Configuration réseau	Permettre la connexion derrière un proxy ou un pare-feu	Échecs de connexion à api.anthropic.com, inspection TLS active en entreprise
Configuration du terminal	Améliorer le confort d'utilisation (retour à la ligne, notifications, thèmes)	Comportement indésirable de Shift+Enter, absence de signal sonore de fin de tâche
Configuration du modèle	Choisir le modèle adapté et optimiser le budget	Consommation excessive de crédits, besoin d'affecter un modèle spécifique selon la tâche

Vous n'avez pas besoin d'apprendre ce tableau par cœur, mais vous devez savoir identifier la catégorie d'un problème rencontré — un échec de connexion relève du réseau et non du bac à sable, tandis qu'une demande incessante d'autorisation relève du bac à sable et non du modèle. Identifier la bonne catégorie vous permettra de vous reporter directement à la section correspondante.

Notez que parmi ces cinq dimensions, le bac à sable, le réseau et les modèles sont les aspects que vous configurerez le plus souvent ; le devcontainer concerne plutôt le travail en équipe, et les options du terminal relèvent des préférences personnelles. Si le temps vous est compté, concentrez-vous sur les sections bac à sable, réseau et modèles.

💡 Résumé en une phrase : La configuration de développement régit les cinq dimensions de l'environnement de travail de Claude — l'isolation (bac à sable / devcontainer), les accès (réseau), l'ergonomie (terminal) et la compétence (modèle) ; identifiez d'abord la nature du problème pour appliquer le bon réglage.

---

02 Bac à sable : réduire les invites tout en sécurisant l'exécution

Commençons par l'option la plus pratique et souvent méconnue — l'outil Bash sécurisé dans un bac à sable (sandboxed Bash tool). Cette fonctionnalité est intégrée à Claude Code et s'active par une simple commande.

Résoudre le dilemme de la sécurité et de la fluidité

Depuis le début de votre utilisation, vous faites probablement face à ce dilemme : vouloir que Claude travaille de manière autonome tout en évitant qu'il n'endommage le système. Les modes de permission (détaillés à l'article 20) sont binaires : soit chaque commande s'interrompt pour demander votre accord (fastidieux), soit l'exécution est entièrement libre (risqué). Le bac à sable offre une solution intermédiaire.

Analogie : tester un véhicule sur un circuit fermé. Vous ne laisseriez pas un véhicule de test rouler librement en ville au risque de provoquer un accident. Sur un circuit fermé, la situation est différente : les limites physiques du circuit empêchent le véhicule de sortir de la zone de test, ce qui évite d'avoir à garder le pied sur le frein en permanence. Le bac à sable est ce circuit fermé pour Claude — le système d'exploitation applique des restrictions strictes à chaque commande Bash : accès en écriture limité et connexions réseau contrôlées. Claude peut exécuter ses tâches de manière autonome dans ces limites sans vous solliciter, et ne demandera votre accord que s'il doit interagir avec l'extérieur (comme accéder à un nouveau domaine réseau).

L'explication officielle résume parfaitement ce fonctionnement :

Le bac à sable Bash permet à Claude d'exécuter la plupart des commandes shell sans s'interrompre pour demander des autorisations. Au lieu d'approuver chaque commande individuellement, vous définissez les fichiers et domaines réseau accessibles, et le système d'exploitation applique ces limites pour chaque commande Bash et ses processus enfants.

Notez l'expression « le système d'exploitation applique ces limites » — il ne s'agit pas d'une promesse de Claude de respecter les consignes, mais d'une barrière technique imposée par le système d'exploitation. C'est une différence fondamentale par rapport à une consigne écrite dans un fichier CLAUDE.md.

Activation : la commande /sandbox

Le bac à sable est intégré à Claude Code. Il est disponible sous macOS, Linux et WSL2, mais n'est pas pris en charge nativement sous Windows (les utilisateurs Windows doivent utiliser WSL2). Pour l'activer, saisissez dans votre session :

/sandbox

Cette commande ouvre un panneau présentant trois onglets :

• Mode : permet de choisir entre « Autorisation automatique » (Auto-allow) et « Permissions standard ». Le mode autorisation automatique permet d'exécuter les commandes sécurisées sans invite de validation (le principal intérêt du bac à sable) ; le mode permissions standard conserve les demandes d'autorisation.
• Overrides : permet de configurer si les commandes incompatibles avec le bac à sable peuvent être exécutées sans isolation (option allowUnsandboxedCommands).
• Config : affiche les limites actuelles du bac à sable.

Spécificités selon les plateformes :

• macOS : aucune installation requise. Le bac à sable s'appuie sur le framework Seatbelt natif du système.
• Linux / WSL2 : nécessite l'installation des paquets bubblewrap (pour l'isolation des fichiers) et socat (pour le relais réseau). Si ces dépendances sont absentes, l'onglet Dependencies du panneau /sandbox indiquera les éléments manquants à installer (sous Ubuntu / Debian : sudo apt-get install bubblewrap socat), puis redémarrez Claude Code.

Par défaut, les limites sont strictes — les commandes du bac à sable ne peuvent écrire que dans le répertoire de travail actuel, et Claude s'interrompt pour demander l'autorisation lors de la première tentative d'accès à un nouveau domaine réseau. Les choix effectués dans ce panneau sont enregistrés dans le fichier .claude/settings.local.json du projet (non soumis à git). Pour activer le bac à sable par défaut sur tous vos projets, définissez l'option sandbox.enabled sur true dans votre fichier de configuration utilisateur ~/.claude/settings.json (les règles de priorité de settings.json sont détaillées à l'article 31).

Attention à un piège courant : si le bac à sable ne peut pas démarrer en raison de dépendances manquantes ou d'une incompatibilité de plateforme, Claude Code affiche un avertissement et poursuit son exécution en mode non isolé par défaut afin de ne pas bloquer votre travail. Cela signifie que vous pouvez penser exécuter vos tâches de manière sécurisée alors que l'isolation est inactive. En cas de besoin de sécurité stricte, vérifiez l'activation effective à l'aide de la méthode décrite à la section 07. Pour bloquer l'exécution si le bac à sable est indisponible, définissez l'option sandbox.failIfUnavailable sur true.

Une restriction importante : le bac à sable ne concerne que Bash

Retenez bien cette limite pour éviter un faux sentiment de sécurité absolue. Le bac à sable intégré ne sécurise que les commandes exécutées via Bash. Les autres actions de Claude — la lecture/écriture de fichiers (outils Read / Edit), la récupération de pages web (WebFetch), ainsi que les serveurs MCP et hooks configurés — s'exécutent directement sur votre machine hôte en dehors du bac à sable.

La documentation officielle le précise clairement :

Les outils de fichiers intégrés, les serveurs MCP et les hooks s'exécutent toujours directement sur votre machine hôte.

Par conséquent, le bac à sable intégré est adapté pour sécuriser vos tâches de développement quotidiennes sur votre machine physique tout en limitant les invites de validation. Pour isoler l'intégralité du processus Claude Code (y compris les outils de fichiers, MCP et hooks), vous devez utiliser un conteneur comme détaillé à la section suivante, ou l'environnement d'exécution de bac à sable officiel (sandbox runtime, actuellement en phase expérimentale et sujet à modifications) qui permet d'isoler l'ensemble du processus. De manière générale, activez le bac à sable intégré pour un usage quotidien, et passez à un conteneur pour manipuler du code externe non audité.

💡 Résumé en une phrase : Le bac à sable, activé via /sandbox, isole chaque commande Bash au niveau du système d'exploitation en limitant l'accès aux fichiers et réseaux de manière autonome ; retenez cependant qu'il ne concerne que Bash et que les outils de fichiers, MCP et hooks s'exécutent sur la machine hôte.

---

03 devcontainer : fournir un environnement de travail identique et isolé pour toute l'équipe

Le bac à sable de la section précédente isole un espace sur votre machine physique. Le devcontainer (conteneur de développement) va plus loin en déplaçant l'intégralité du processus de Claude dans un environnement virtuel isolé.

Résoudre les problèmes d'écarts d'environnement et de tâches sans surveillance

Deux besoins majeurs justifient l'usage d'un devcontainer :

Premièrement, les écarts d'environnement au sein d'une équipe. Des versions différentes de Node.js (par exemple version 18 chez l'un, version 20 chez l'autre) peuvent conduire à des divergences de comportement lors des exécutions de Claude. Deuxièmement, le besoin d'exécuter des tâches de manière autonome sans surveillance — par exemple lancer un traitement long et s'absenter. Laisser un agent exécuter des tâches en autonomie directe sur sa machine physique présente des risques de sécurité.

Analogie : un box de recherche individuel en bibliothèque. Lorsque vous travaillez dans l'espace commun (machine hôte), vos affaires personnelles sont visibles et accessibles, ce qui vous empêche de vous absenter sereinement. En réservant un box individuel, la situation change : l'espace contient le mobilier standard fourni par la bibliothèque (identique pour tous), la porte est fermée et isolée de l'extérieur, et vos affaires personnelles restent en dehors. Le devcontainer correspond à ce box individuel : un environnement standardisé défini par fichier de configuration, dans lequel s'exécute Claude sans pouvoir accéder aux secrets et fichiers confidentiels de la machine hôte.

La définition officielle est la suivante :

Un conteneur de développement (ou dev container) vous permet de définir un environnement identique et isolé pour tous les ingénieurs de l'équipe. Une fois Claude Code installé dans ce conteneur, les commandes de Claude s'exécutent à l'intérieur de celui-ci et non sur la machine hôte, tandis que les modifications apportées aux fichiers du projet sont répercutées dans votre dépôt local à mesure que vous travaillez.

Notez un point clé de cette définition : les commandes s'exécutent dans le conteneur isolé, mais les modifications de code sont appliquées directement sur votre dépôt local. Cela concilie sécurité de l'exécution et persistance du travail produit.

Configuration : intégrer la fonctionnalité et reconstruire le conteneur

L'utilisation d'un devcontainer nécessite Docker ainsi qu'un éditeur compatible avec la spécification Dev Containers (VS Code, Codespaces, les IDE JetBrains, Cursor, etc. ; les éditeurs de type Vim ne sont pas concernés). Pour installer Claude Code dans le conteneur, ajoutez la déclaration suivante dans le fichier .devcontainer/devcontainer.json de votre projet :

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  }
}

Le bloc features désigne la fonctionnalité officielle Claude Code Dev Container Feature, qui prend en charge l'installation de l'outil dans le conteneur. Adaptez la ligne image avec l'image de base de votre projet. Une fois le fichier enregistré, utilisez la palette de commandes (Cmd+Shift+P sous macOS, ou Ctrl+Shift+P sous Windows/Linux) pour exécuter Dev Containers: Rebuild Container, puis lancez la commande claude dans le terminal du conteneur pour vous authentifier.

Attention à un point de fonctionnement important signalé dans la documentation officielle : le répertoire personnel du conteneur est généralement recréé lors des reconstructions, ce qui nécessite de se réauthentifier à chaque reconstruction. Pour conserver l'état de connexion, configurez un volume nommé (named volume) pour monter le dossier ~/.claude de manière persistante. Reportez-vous à la documentation des Dev Containers pour la configuration détaillée des volumes.

Veillez également à respecter cette consigne de sécurité majeure mise en évidence dans la documentation officielle :

N'utilisez les conteneurs de développement que pour travailler sur des dépôts de confiance, et surveillez l'activité de Claude. Évitez de monter des clés sensibles de l'hôte (telles que ~/.ssh ou des fichiers de secrets cloud) dans le conteneur.

En clair : le conteneur isole l'environnement, mais ne constitue pas un système de sécurité absolu. Si vous autorisez l'exécution autonome sans invite de validation, un code malveillant peut altérer les ressources accessibles au sein du conteneur. N'y montez pas les clés SSH de votre machine physique, privilégiez des jetons d'accès limités et temporaires associés au dépôt.

devcontainer vs bac à sable : distinguer les usages

Bien que tous deux qualifiés de systèmes d'« isolation », leurs périmètres diffèrent. Voici un comparatif des différentes options d'isolation incluant le bac à sable, le devcontainer et les autres approches documentées :

Type d'isolation	Périmètre isolé	Docker requis	Usage recommandé
Bac à sable intégré (/sandbox)	Commandes Bash uniquement	Non	Développement quotidien sur machine physique avec réduction des invites
devcontainer	Environnement de développement complet	Oui	Uniformisation d'équipe, exécution sans surveillance
Conteneur / VM personnalisés	Environnement ou système d'exploitation complet	Selon conteneur / VM	Manipulation de code non audité nécessitant une isolation au niveau du noyau
Claude Code sur le web (voir article 11)	Système d'exploitation complet hébergé	Non	Absence d'environnement local, aucune configuration d'infrastructure

Ces options peuvent être classées selon leur niveau de sécurité et de complexité de configuration, du plus simple au plus sécurisé :

Ce schéma montre que le niveau d'isolation augmente en allant vers la droite, nécessitant en contrepartie une configuration plus avancée — du bac à sable intégré limitant uniquement les commandes Bash, au devcontainer isolant tout l'environnement de développement, jusqu'à la machine virtuelle isolant au niveau du noyau, et enfin l'environnement cloud géré par Anthropic. Choisissez le niveau d'isolation en fonction du degré de confiance accordé au code supprimé.

La règle de choix peut être résumée ainsi :

• Usage quotidien sur machine physique avec réduction des invites → Bac à sable intégré, activé via /sandbox.
• Uniformisation d'équipe ou exécution autonome sans surveillance → devcontainer, configuré dans le dépôt de code.
• Code non audité ou suspect → Machine virtuelle dédiée ou version web, pour une isolation stricte au niveau du noyau.

En pratique, utilisez le bac à sable pour vos projets personnels, et recourez au devcontainer ou à Claude Code sur le web pour manipuler des dépôts externes dont vous n'avez pas audité le contenu, afin d'éviter d'avoir à surveiller manuellement chaque commande.

💡 Résumé en une phrase : Le devcontainer fournit un environnement virtuel complet et uniforme défini par le fichier .devcontainer/devcontainer.json où les commandes s'exécutent de manière isolée sans accès aux secrets de l'hôte, tandis que les modifications de fichiers sont appliquées directement dans le dépôt local.

---

04 Configuration réseau : connexion derrière un proxy ou un pare-feu d'entreprise

Cette section s'adresse aux développeurs évoluant dans un réseau d'entreprise restreint avec proxy obligatoire ou rencontrant des difficultés de connexion réseau directes. Si votre connexion fonctionne normalement, vous pouvez passer rapidement à la section suivante.

Résoudre les échecs de connexion réseau

Pour fonctionner, Claude Code doit pouvoir communiquer avec les serveurs d'Anthropic (ou de votre fournisseur de modèles tiers). Les réseaux d'entreprise imposent souvent des contraintes : passage obligatoire par un proxy, inspection active des flux TLS (avec certificats d'autorité internes) et filtrage des domaines autorisés par le pare-feu. Si ces éléments ne sont pas configurés, l'outil échouera à se connecter lors de la phase d'authentification ou lors des requêtes.

Analogie : téléphoner depuis un bureau sécurisé. Pour passer un appel vers l'extérieur (Claude Code vers le serveur), vous devez composer un préfixe pour passer par le standard (le serveur proxy), la ligne directe étant coupée. De plus, le service de sécurité inspecte le contenu des courriers (inspection TLS), et vous devez authentifier les agents de sécurité à l'aide de leur badge officiel (le certificat de l'entreprise) pour qu'ils autorisent l'expédition. La configuration réseau consiste à fournir ces paramètres à l'outil.

Toutes ces options peuvent être définies à l'aide de variables d'environnement ou déclarées dans le fichier de configuration settings.json. Pour des raisons de clarté, nous détaillons ci-dessous la configuration par variables d'environnement.

Configuration du proxy : variables d'environnement standards

Claude Code prend en charge les variables d'environnement de proxy standards. Déclarez-les dans votre terminal :

# Proxy HTTPS (recommandé)
export HTTPS_PROXY=https://proxy.exemple.com:8080

# Proxy HTTP (si HTTPS non disponible)
export HTTP_PROXY=http://proxy.exemple.com:8080

# Adresses à contacter en direct sans passer par le proxy
export NO_PROXY="localhost,127.0.0.1,.interne.entreprise.com"

Deux points importants : premièrement, Claude Code ne prend pas en charge les proxys SOCKS, seuls les protocoles HTTP et HTTPS sont reconnus. Si votre entreprise utilise SOCKS, vous devez mettre en œuvre une passerelle de conversion intermédiaire. Deuxièmement, si le proxy requiert une authentification, intégrez les identifiants dans l'URL (http://user:pass@proxy...), en veillant à ne pas exposer ces informations dans des scripts publics en utilisant des variables d'environnement sécurisées.

Certificats personnalisés : déclarer votre autorité de certification

Si votre entreprise utilise un proxy avec inspection de flux TLS (comme Zscaler ou CrowdStrike), Claude Code s'appuie par défaut sur le trousseau de certificats Mozilla intégré ainsi que sur le magasin de certificats du système d'exploitation — si le certificat racine de l'entreprise est correctement installé dans le système, aucune configuration supplémentaire n'est généralement requise. Si des erreurs de certificat persistent, déclarez manuellement le chemin vers le certificat de l'autorité de certification (CA) :

export NODE_EXTRA_CA_CERTS=/chemin/vers/certificat-ca-entreprise.pem

Règles de pare-feu : domaines à autoriser

Si vous devez configurer les accès ou soumettre une demande d'ouverture de flux à votre équipe réseau, voici les domaines principaux requis pour le fonctionnement de Claude Code (dans le cadre d'un accès direct à Anthropic) :

Domaine	Usage
api.anthropic.com	Requêtes d'API vers les modèles (indispensable)
claude.ai	Authentification et connexion au compte utilisateur
platform.claude.com	Authentification sur la console d'administration
downloads.claude.ai	Téléchargement des outils, installeurs et mises à jour
storage.googleapis.com	Hébergement des versions antérieures à la v2.1.116 (historique)
bridge.claudeusercontent.com	WebSocket pour la liaison avec l'extension Chrome
raw.githubusercontent.com	Notes de version et comptage d'installation des plug-ins

Si vous utilisez des services tiers comme Amazon Bedrock ou Google Vertex, les flux réseau transitent par les passerelles respectives de ces fournisseurs. L'autorisation des domaines Anthropic listés ci-dessus n'est alors pas requise pour l'utilisation des modèles.

Dans un environnement réseau avec proxy sécurisé, un échec d'authentification initial peut être confondu avec un problème de compte. Si le certificat racine de l'entreprise est déployé dans le magasin de certificats du système, l'authentification s'effectue généralement sans configuration de variable d'environnement après redémarrage du terminal. Vérifiez ce point avant de définir manuellement les variables.

💡 Résumé en une phrase : Pour fonctionner derrière un pare-feu d'entreprise, définissez le proxy avec la variable HTTPS_PROXY (les proxys SOCKS ne sont pas supportés), configurez le certificat avec NODE_EXTRA_CA_CERTS si nécessaire, et assurez-vous de l'autorisation d'accès aux domaines requis comme api.anthropic.com.

---

05 Configuration du terminal : retour à la ligne, notifications et thèmes

Les paramètres suivants concernent l'ergonomie et le confort d'utilisation au quotidien dans le terminal. Claude Code fonctionne sans modification par défaut, mais ces options permettent de régler des comportements inattendus. Voici les trois réglages les plus utiles.

1. Comportement du raccourci Shift+Enter pour le retour à la ligne

Il s'agit d'une difficulté courante pour les nouveaux utilisateurs : appuyer sur Shift+Enter pour insérer un retour à la ligne provoque la soumission de la saisie au lieu de passer à la ligne suivante.

Solution universelle : utilisez le raccourci Ctrl+J ou saisissez un caractère antislash \ suivi de Enter pour insérer un retour à la ligne dans n'importe quel terminal sans configuration supplémentaire.

La prise en charge du raccourci Shift+Enter dépend du terminal utilisé :

Terminal	Support natif de Shift+Enter
iTerm2, Ghostty, Kitty, Apple Terminal, Windows Terminal, WezTerm, Warp	Supporté par défaut, aucune configuration requise
VS Code, Cursor, Devin Desktop, Alacritty, Zed	Exécutez la commande /terminal-setup
gnome-terminal, les IDE JetBrains (PyCharm, etc.)	Non supporté ; utilisez Ctrl+J ou \ suivi de Enter

Pour les terminaux de la deuxième catégorie (VS Code, Cursor, etc.), saisissez dans votre session :

/terminal-setup

Cette commande configure les raccourcis clavier de votre terminal sans altérer vos liaisons existantes. Redémarrez ensuite l'éditeur pour appliquer les modifications. Exécutez cette commande directement dans le terminal principal, en dehors de tout multiplexeur comme tmux ou screen, pour qu'elle puisse configurer l'application hôte.

2. Notifications de fin de tâche

Lors de l'exécution de tâches longues, s'absenter ou travailler sur une autre fenêtre peut faire oublier de vérifier l'avancement, retardant la validation d'une invite de permission. Il est possible de configurer un signal sonore ou une notification à la fin d'un traitement.

Par défaut, seuls les terminaux Ghostty, Kitty et iTerm2 émettent des notifications de bureau natives. Pour les autres terminaux, configurez l'option preferredNotifChannel sur "terminal_bell" dans votre fichier ~/.claude/settings.json pour utiliser le signal sonore du terminal :

{
  "preferredNotifChannel": "terminal_bell"
}

Ce réglage permet de s'absenter de son poste pendant un traitement long en étant averti dès que Claude requiert une validation ou termine son exécution, évitant de bloquer le flux de travail. Pour des configurations plus avancées (comme le déclenchement d'un script personnalisé), reportez-vous aux hooks détaillés à l'article 33.

3. Thème de couleur

Les couleurs de l'interface de Claude Code peuvent être synchronisées avec le thème clair ou sombre de votre terminal. Saisissez dans votre session :

/theme

Sélectionnez l'option « auto » pour que l'interface s'adapte automatiquement à l'apparence du système d'exploitation (passage en mode sombre ou clair). Notez que Claude Code n'ajuste que ses propres couleurs d'affichage et ne modifie pas le thème de votre terminal, qui se règle dans les paramètres de l'application hôte. D'autres réglages fins de couleurs sont disponibles, mais le mode automatique répond à la majorité des besoins.

Pour les utilisateurs de macOS, notez que certains raccourcis basés sur la touche Option (comme Option+P pour changer de modèle) requièrent de configurer la touche Option comme touche Meta dans les paramètres de votre terminal (dans iTerm2 : Préférences → Profils → Clavier → définir l'option Left/Right Option sur Esc+). Ce point est détaillé à l'article 35. Pour utiliser les raccourcis de navigation Vim dans le champ de saisie, définissez le mode d'édition sur vim à l'aide de la commande /config.

💡 Résumé en une phrase : Optimisez votre terminal avec trois commandes — utilisez /terminal-setup pour le retour à la ligne via Shift+Enter (avec Ctrl+J en solution de secours), définissez preferredNotifChannel sur "terminal_bell" pour les alertes de fin de tâche, et ajustez les couleurs avec /theme.

---

06 Configuration du modèle : optimiser la performance et le coût

Dernier aspect de la configuration : le choix et le paramétrage du modèle, qui influent directement sur la qualité des réponses et la consommation de crédits. Les concepts d'API et de tarification ayant été abordés aux articles 04 et 06, cette section détaille la sélection et l'optimisation des modèles selon la tâche.

Adapter le modèle à la complexité de la tâche

Claude Code propose différents modèles présentant des niveaux de performance et des coûts distincts. Le modèle par défaut n'est pas nécessairement le plus économique pour les tâches simples — utiliser le modèle le plus performant pour corriger une simple faute d'orthographe représente un coût disproportionné.

Analogie : l'organisation des rôles en cuisine. Un chef cuisinier (Opus) prépare les plats complexes mais sa rémunération est élevée ; un cuisinier (Sonnet) prépare les plats courants et assure le service quotidien ; un commis (Haiku) se charge des tâches de préparation simples rapidement et à faible coût. Un responsable de restaurant n'affecte pas le chef cuisinier à la découpe des légumes — adapter la compétence à la tâche permet d'optimiser les coûts de fonctionnement. La configuration du modèle correspond à cette affectation des rôles.

Des alias de modèles facilitent la sélection sans avoir à saisir les numéros de version complets :

Alias	Modèle associé	Type de tâche recommandé
opus	Opus (dernière version)	Raisonnements complexes, choix d'architecture ou refactorisations lourdes
sonnet	Sonnet (dernière version)	Tâches de programmation quotidiennes (modèle principal recommandé)
haiku	Haiku (dernière version)	Tâches simples, traitements rapides à faible coût
opusplan	Combinaison Opus / Sonnet	Planification avec Opus pour concevoir la solution, puis exécution automatique avec Sonnet pour limiter les coûts
default	Modèle par défaut du compte	Réinitialise la configuration pour utiliser le modèle par défaut recommandé

L'alias opusplan est particulièrement recommandé pour optimiser le budget sur les tâches complexes : la phase de conception (Plan Mode) utilise Opus pour concevoir une solution solide, puis la phase de codage bascule sur Sonnet pour appliquer les modifications. Les étapes intellectuelles s'appuient sur Opus, tandis que l'application du code bénéficie du tarif de Sonnet. C'est le choix recommandé pour les réorganisations de code moyennes à complexes.

Ces alias pointent vers la version recommandée par le fournisseur et sont mis à jour automatiquement. Pour garantir la reproductibilité au sein d'une équipe en figeant une version spécifique, indiquez le nom de modèle complet (par exemple claude-opus-4-8) au lieu de l'alias.

Méthodes de changement de modèle par ordre de priorité

Quatre méthodes permettent de définir le modèle, de la plus temporaire à la plus permanente :

# 1. Dans la session active (changement immédiat)
/model sonnet

# 2. Au lancement de l'outil (uniquement pour la session ouverte)
claude --model opus

# 3. Via variable d'environnement (pour le terminal actif)
export ANTHROPIC_MODEL=sonnet

// 4. Dans le fichier settings.json (configuration persistante)
{
  "model": "opusplan"
}

Pour un changement ponctuel, privilégiez la commande /model. Pour définir une préférence par projet ou par utilisateur, renseignez le champ model dans le fichier settings.json (voir article 31 pour les règles de priorité). Notez que les configurations au niveau du projet ou imposées par l'entreprise prévalent sur vos choix personnels. Si le modèle sélectionné n'est pas appliqué, vérifiez les fichiers de configuration du projet.

Ajuster l'effort de réflexion du modèle

Une fois le modèle choisi, vous pouvez ajuster son effort de réflexion (effort level) pour contrôler la profondeur de son analyse. Pour un même modèle, ce paramètre influe sur le temps de calcul et le nombre de tokens consommés.

Analogie : l'attention accordée par un professionnel à une tâche. Un artisan peut réaliser une tâche courante rapidement ou y consacrer plus de temps pour soigner les détails. L'effort de réflexion correspond à ce niveau d'attention. La documentation officielle définit cinq niveaux : low (rapide et économique), medium (compromis léger), high (valeur par défaut équilibrée pour Sonnet et Opus), xhigh (analyse approfondie, par défaut pour Opus) et max (analyse maximale sans contrainte de coût).

Deux manières de l'utiliser en pratique :

• Analyse approfondie ponctuelle : insérez le mot-clé ultrathink dans votre prompt pour que Claude consacre plus d'effort à cette requête spécifique, sans modifier vos paramètres globaux. Seul le terme exact ultrathink est reconnu par le système.
• Paramétrage global : ajustez le niveau dans la session à l'aide de la commande /effort, ou définissez le champ effortLevel dans le fichier settings.json.

Pour un usage courant, conservez le niveau par défaut. Utilisez le mot-clé ultrathink uniquement pour résoudre des bugs de logique complexes ou des réorganisations de code imbriquées — cela permet de cibler la consommation de tokens sur les étapes à forte valeur ajoutée.

Limiter les modèles disponibles au sein d'une équipe

Pour maîtriser les coûts dans un cadre professionnel, utilisez l'option availableModels pour restreindre la liste des modèles sélectionnables par les collaborateurs — par exemple en excluant Opus pour limiter les coûts :

{
  "availableModels": ["sonnet", "haiku"]
}

Cette restriction empêche l'utilisation de modèles hors liste via /model, --model ou par variable d'environnement. C'est une méthode efficace de contrôle budgétaire pour un projet sensible aux coûts de tokens. Les administrateurs peuvent temporairement réintégrer un modèle dans la liste si une tâche complexe le requiert.

💡 Résumé en une phrase : Adaptez le modèle à la tâche — opus pour la complexité, sonnet pour le quotidien, haiku pour l'économie, ou opusplan pour allier conception et exécution ; utilisez /model pour basculer, configurez availableModels pour encadrer les budgets d'équipe, et utilisez ultrathink pour approfondir ponctuellement la réflexion.

---

07 Mise en pratique : activer le bac à sable et configurer le modèle

Appliquons ces concepts. Cette section vous guide pour configurer et vérifier le fonctionnement du bac à sable et de la sélection de modèle dans un cas simple. Ce test s'effectue sous macOS, Linux ou WSL2 et ne nécessite aucun projet complexe préalable.

Étape 1 : Activer le bac à sable (dans votre session claude active)

/sandbox

Résultat attendu : Le panneau de configuration du bac à sable s'affiche. Dans l'onglet Mode, sélectionnez « Autorisation automatique » (Auto-allow). L'affichage du panneau confirme la compatibilité du système. Si seul l'onglet Dependencies s'affiche (cas fréquent sous Linux/WSL2), installez les paquets requis (sudo apt-get install bubblewrap socat), puis redémarrez Claude Code.

Étape 2 : Exécuter une commande dans le bac à sable

Saisissez dans la session :

Créez un fichier sandbox-test.txt dans le dossier actuel contenant le texte hello sandbox

Résultat attendu : Claude exécute la commande de création du fichier dans le bac à sable sans afficher de demande de validation de permission, cette action d'écriture restant dans les limites autorisées du répertoire courant. Le fichier sandbox-test.txt est créé dans le dossier. La création directe confirme le bon fonctionnement du mode autorisation automatique. Vous pouvez ensuite supprimer ce fichier de test.

Étape 3 : Identifier le modèle actif

Saisissez :

/status

Résultat attendu : Le panneau d'état affiche le compte d'utilisation et le nom du modèle actuellement sélectionné. Notez ce nom (par exemple Sonnet ou Opus).

Étape 4 : Changer de modèle et vérifier le changement

Saisissez :

/model haiku

Résultat attendu : L'outil confirme le passage au modèle Haiku. Saisissez à nouveau /status : la ligne du modèle doit désormais indiquer Haiku. Cette différence confirme la prise en compte du changement de modèle. Rétablissez ensuite votre modèle habituel à l'aide de la commande /model sonnet ou /model default.

Étape 5 (facultative) : Enregistrer le modèle par défaut

Pour figer ce choix de modèle pour vos futures sessions dans ce projet, ajoutez la déclaration suivante dans le fichier .claude/settings.json à la racine de votre projet :

{
  "model": "sonnet"
}

Résultat attendu : Lors des prochains lancements de claude dans ce projet, la commande /status confirmera l'utilisation par défaut du modèle Sonnet.

Ce test simple valide l'ensemble du cycle de configuration : « activation de l'isolation → test d'exécution → identification du modèle → modification et vérification de la configuration ». La même démarche s'applique pour valider toute modification de vos paramètres de développement.

💡 Résumé en une phrase : Testez votre configuration en deux étapes — activez le mode automatique avec /sandbox pour valider l'exécution sans invite, puis basculez de modèle avec /model et vérifiez le changement avec /status.

---

08 Synthèse

Dans cet article, nous avons détaillé les cinq dimensions de la configuration de votre environnement de travail avec Claude Code.

Récapitulatif des options de configuration :

Domaine	Commande / Configuration	Point clé
Bac à sable	/sandbox (mode Auto-allow)	Isole uniquement Bash ; les outils de fichiers, MCP et hooks s'exécutent sur l'hôte
devcontainer	Déclaration features dans devcontainer.json	Requiert Docker ; isole tout l'environnement de développement, persistance dans le dépôt
Réseau	HTTPS_PROXY et NODE_EXTRA_CA_CERTS	Pas de support SOCKS ; déclarer le proxy et les certificats d'entreprise
Terminal	Commandes /terminal-setup, /theme	Solution de secours pour le retour à la ligne : Ctrl+J
Modèle	Commandes /model, option availableModels	Choisir selon la complexité ; utiliser opusplan pour optimiser le budget et ultrathink pour approfondir

Vous savez désormais : sécuriser l'exécution de Bash avec le bac à sable, utiliser un conteneur devcontainer pour uniformiser l'environnement d'une équipe, configurer les accès derrière un proxy ou pare-feu d'entreprise, corriger le retour à la ligne dans votre terminal, et sélectionner le modèle le plus économique selon la complexité de la tâche. Ces ajustements permettent d'utiliser Claude Code de manière sécurisée, confortable et économique.

Le recours à ces configurations vous évite d'avoir à surveiller manuellement chaque commande exécutée en vous reposant sur les mécanismes d'isolation du système ou de virtualisation.

---

L'article suivant 47 « Mode vocal » aborde une fonctionnalité expérimentale d'interaction avec l'outil : l'utilisation de la voix. Ce mode permet de formuler vos instructions à l'oral pendant que vos mains restent sur le clavier pour coder, par exemple pour demander une refactorisation simple. Nous ferons le point sur les possibilités offertes par cette interface.

---

Lectures recommandées

• MCP : connecter Claude au monde extérieur
• Configuration des modèles tiers et locaux
• Pratiques déconseillées et anti-patterns