Styles de sortie Claude Code : fonctionnement et réglages

Ce qu’est un style de sortie dans Claude Code

Un style de sortie dans Claude Code est un bloc d’instructions que Claude Code ajoute à son prompt système. Il modifie la manière dont Claude vous répond : le rôle qu’il adopte et la forme de ce qu’il affiche. Il n’enseigne rien à Claude sur votre codebase et ne peut pas lui accorder l’autorisation d’exécuter des commandes.

Claude Code fournit cinq styles intégrés. Votre choix est enregistré dans une seule clé de configuration, outputStyle, qui est lue une fois au démarrage de la session. Cela explique la plupart des confusions liées à cette fonctionnalité : un style que vous changez au milieu d’une session est enregistré, puis ignoré jusqu’à ce que vous effaciez ce choix.

Sur un VPS, ce n’est pas seulement une préférence esthétique. Le transcript est ce que vous consultez via une connexion SSH (secure shell), généralement dans une fenêtre tmux. Chaque ligne que Claude affiche est donc une ligne que vous devez attendre et une ligne ajoutée à un buffer de scrollback de taille fixe.

Emplacement du paramètre outputStyle

Choisissez un style dans le menu /config, sous Output style. Claude Code enregistre votre choix dans .claude/settings.local.json du projet sur lequel vous travaillez.

La commande autonome /output-style n’existe plus. Elle a été dépréciée dans v2.1.73, puis supprimée dans v2.1.91. Dans une version actuelle, elle ne fait donc absolument rien. Vérifiez la version utilisée avant de suivre un ancien guide. Les versions indiquées sur cette page ont été vérifiées en août 2026.

claude --version

Vous pouvez également définir la clé manuellement. Quatre fichiers de configuration peuvent la contenir. Le fichier le plus spécifique prend le pas sur les fichiers plus généraux.

• ~/.claude/settings.json est votre fichier utilisateur. Il s’applique à tous les projets de cette machine.
• .claude/settings.json est le fichier du projet. Il est validé dans git et s’applique donc à toutes les personnes qui clonent le dépôt.
• .claude/settings.local.json est le fichier local du projet. Il n’est pas validé dans git et prend le pas sur les deux fichiers précédents. C’est ce fichier que le menu /config modifie.
• Les paramètres gérés, déployés par une équipe informatique depuis un chemin système tel que /etc/claude-code/ sous Linux, prennent le pas sur tous les autres.

La valeur de la clé est le nom du style :

{
  "outputStyle": "Concise"
}

Pour une seule session, transmettez la même clé sur la ligne de commande. L’option --settings accepte un chemin ou une chaîne JSON inline. Ses valeurs prennent le pas sur les mêmes clés des fichiers de configuration pour cette exécution :

claude --settings '{"outputStyle": "Concise"}'

Les libellés des menus et les slash commands ont changé au moins une fois au cours de l’évolution de cette fonctionnalité. La clé outputStyle, elle, n’a pas changé. Lorsqu’une capture d’écran d’un guide ne correspond plus à ce que vous voyez, définissez directement la clé, puis vérifiez-la avec /status, qui liste les sources de configuration actives.

Pourquoi votre nouveau style de sortie ne produit aucun effet avant l’effacement

Claude Code construit le system prompt une seule fois, au démarrage de la session, et le style de sortie en fait partie. Si vous modifiez le paramètre pendant une session, la nouvelle valeur est enregistrée, mais rien ne change à l’écran, car la session en cours continue d’envoyer le prompt construit au démarrage. Le nouveau style est chargé à la prochaine /clear ou au prochain lancement.

/clear
/context

/context affiche ce qui occupe actuellement la context window, réparti par catégorie, notamment le system prompt. Exécutez-le dans une nouvelle session avec chaque style : la ligne du system prompt constitue la base de votre comparaison. C’est également le moyen le plus rapide de vérifier qu’un style personnalisé a bien été chargé. Pour comprendre plus largement ce qui remplit cette fenêtre, consultez comment le contexte se remplit dans une longue session Claude Code.

Ce délai est nécessaire, car l’API réutilise les requêtes répétées à partir d’un prompt cache qui correspond au début de chaque requête, et le system prompt se trouve tout au début. Le réécrire au milieu d’une conversation invaliderait tout ce qui suit. Le tour suivant devrait alors retraiter tout votre historique comme une nouvelle entrée. Fixer le style au démarrage de la session évite ce coût. Changer de style est rapide. Il faut simplement effacer.

Ce que chaque style de sortie intégré change dans la transcription

• Default est l’invite système normale de Claude Code, conçue pour les tâches de développement logiciel.
• Concise commence par le résultat. Il supprime le préambule et la narration détaillée des étapes, et conserve des réponses courtes jusqu’à ce que vous demandiez plus de détails. Le travail d’ingénierie effectué reste inchangé. Ce style ne raccourcit jamais un rapport d’erreur ni un avertissement de sécurité, et demande toujours une confirmation complète avant une action destructive. Ce style nécessite Claude Code v2.1.237 ou une version ultérieure.
• Explanatory ajoute des « Insights » pédagogiques entre les étapes d’une tâche. Ils expliquent pourquoi un choix d’implémentation a été effectué et quel modèle votre base de code utilise déjà. La transcription est volontairement plus longue.
• Learning va plus loin. Claude partage ces explications, puis vous demande d’écrire vous-même de petits morceaux de code, en indiquant chaque emplacement par un commentaire TODO(human) dans le fichier.
• Proactive fait agir Claude au lieu de le faire demander. Pour les décisions courantes, il part d’hypothèses raisonnables au lieu de s’arrêter pour demander une confirmation.

Lisez attentivement le dernier point, car c’est celui qui est le plus souvent mal compris. Proactive est une directive de l’invite système. Il modifie ce que Claude tente d’effectuer. Votre mode d’autorisation détermine toujours ce qui est réellement exécuté sans vous demander confirmation. C’est le paramètre important sur un serveur que vous laissez fonctionner sans supervision. Ce point est expliqué dans le mode automatique et les modes d’autorisation de Claude Code.

En quoi un style de sortie diffère de CLAUDE.md, d’un hook et d’un sous-agent

Ces mécanismes servent tous à indiquer à Claude comment se comporter, mais ils interviennent à des niveaux différents.

• Un style de sortie est ajouté à l’invite système. Il s’applique à chaque réponse de la conversation principale.
• CLAUDE.md est ajouté comme message utilisateur après l’invite système. C’est là que doivent figurer les conventions du projet et les informations sur le code.
• --append-system-prompt ajoute du texte à l’invite système pour une seule invocation, sans rien supprimer. C’est la version ponctuelle d’un style de sortie.
• Un hook est une commande shell que Claude Code exécute lorsqu’un événement se produit. Il est appliqué par le harness : il s’exécute donc même si Claude n’aurait pas choisi de le faire. Voir ce qu’un hook Claude Code peut et ne peut pas faire.
• Un sous-agent s’exécute avec sa propre invite système et son propre jeu d’outils.

Un test simple permet de choisir entre les deux premiers mécanismes. Les informations sur votre projet vont dans CLAUDE.md, car Claude doit les connaître. La formulation va dans un style de sortie, car elle concerne la manière dont la réponse est rédigée. Tout ce qui doit se produire à chaque fois, quelle que soit la décision du modèle, doit être un hook.

Les styles de sortie s’appliquent uniquement à la conversation principale. Un sous-agent n’hérite pas de votre style, car il démarre sa propre conversation avec sa propre invite système. Un fork de la conversation en cours constitue une exception, car il hérite exactement de l’invite système du parent. Si la rédaction d’un sous-agent ne vous convient pas, modifiez le fichier de cet agent plutôt que votre style.

Comment écrire votre propre style de sortie

Un style de sortie personnalisé est un fichier Markdown avec un frontmatter. Enregistrez-le dans votre répertoire personnel pour l’utiliser dans tous vos projets, ou dans le dépôt pour le conserver avec le code. Le répertoire utilisateur est ~/.claude/output-styles/ et le répertoire du projet est .claude/output-styles/.

mkdir -p ~/.claude/output-styles
cat > ~/.claude/output-styles/terse-ops.md <<'EOF'
---
name: Terse ops
description: Command first, explanation after, for SSH sessions
keep-coding-instructions: true
---

Lead with the command or the file change. Put the explanation after it, in two sentences or fewer.

Do not narrate what you are about to do. Report what you did.

When a command can fail, print the one check that proves it worked and say what a healthy result looks like.
EOF

Démarrez une session et ouvrez /config. Votre style apparaît dans la liste Output style, avec la description que vous avez écrite. S’il n’apparaît pas, le fichier n’est pas lu : vérifiez le chemin et assurez-vous que le bloc de frontmatter --- est le premier élément du fichier. Le nom du fichier devient le nom du style, sauf si le frontmatter définit name. Celui-ci s’appelle donc Terse ops, et non terse-ops.

Sélectionnez-le, ou définissez la clé sur ce nom exact et effacez :

{
  "outputStyle": "Terse ops"
}

Un champ détermine si votre fichier complète les instructions existantes ou les remplace. keep-coding-instructions vaut par défaut false, ce qui signifie qu’un style personnalisé supprime les instructions intégrées de Claude Code pour le software engineering et s’exécute uniquement avec votre texte. Ces instructions intégrées indiquent à Claude comment définir la portée d’une modification et comment vérifier son travail. Laissez ce champ absent pour un assistant de rédaction ou un analyste de données, car ces instructions ne s’appliquent pas dans ces cas. Définissez-le sur true pour tout ce qui touche encore au code. Sinon, vous vous demanderez pourquoi un ingénieur rigoureux a soudainement cessé de vérifier son propre travail.

description est la ligne que le sélecteur /config affiche à côté du nom. Rédigez-la en pensant au moment où vous devrez choisir entre deux de vos propres styles, six mois plus tard.

Pourquoi un style concis est différent via SSH

Sur un VPS, vous lisez la sortie à travers plusieurs couches qu’un terminal local n’a pas. Chacune vous fait payer la verbosité.

Le scrollback est le premier facteur. Dans tmux, chaque panneau conserve un nombre fixe de lignes défini par history-limit, qui vaut 2000 par défaut. Une sortie commentée remplit ce buffer plus rapidement. Les premières lignes de votre session sont donc supprimées plus tôt, et la sortie à laquelle vous vouliez revenir disparaît. Augmentez cette valeur si vous avez besoin de plus de place :

echo 'set -g history-limit 20000' >> ~/.tmux.conf
tmux source-file ~/.tmux.conf

Les panneaux créés ensuite conservent chacun 20000 lignes, au prix d’une consommation mémoire plus élevée par panneau. Les panneaux déjà ouverts conservent l’ancienne limite, car la taille du buffer est fixée lors de la création du panneau. Si vous construisez encore la disposition de la session, exécuter Claude Code dans tmux sur un VPS explique la procédure.

La latence est le deuxième facteur. La réponse est envoyée vers votre terminal au fur et à mesure de sa génération. Sur une liaison présentant un temps aller-retour élevé, un long préambule vous oblige à attendre l’arrivée du texte avant de voir apparaître la réponse.

Les tokens de sortie sont le troisième facteur. Chaque ligne commentée est facturée comme de la sortie. Les styles Explanatory et Learning sont volontairement plus longs. Concise est volontairement plus court, car il indique à Claude de limiter par défaut la longueur de ses réponses.

Ne faites confiance à aucun pourcentage, y compris à ceux de cette page. L’écart dépend de vos prompts, de votre modèle et du travail demandé. Mesurez donc votre propre différence avant et après. Exécutez la même tâche réelle dans deux nouvelles sessions, l’une avec Default et l’autre avec Concise, puis comparez les résultats. Une statusline est l’indicateur le plus simple, car Claude Code transmet à votre script un objet JSON sur stdin qui contient déjà le nom du style et les compteurs de tokens :

cat > ~/.claude/statusline.sh <<'EOF'
#!/bin/bash
input=$(cat)
style=$(echo "$input" | jq -r '.output_style.name // "default"')
out=$(echo "$input" | jq -r '.context_window.total_output_tokens // 0')
cost=$(echo "$input" | jq -r '.cost.total_cost_usd // 0')
echo "style=$style out=$out cost=$cost"
EOF
chmod +x ~/.claude/statusline.sh

Indiquez ce script dans le paramètre statusLine :

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh"
  }
}

La barre en bas de la session affiche maintenant le style actif à côté du nombre de tokens produits. C’est exactement la comparaison avant-après dont vous avez besoin. Le script nécessite jq, l’analyseur JSON en ligne de commande. Installez-le d’abord avec sudo apt install -y jq. Si la barre reste vide, exécutez le script manuellement et envoyez-lui du JSON via un pipe. Une statusline qui se termine avec un code différent de zéro n’affiche ni ne signale rien. Une statusline personnalisée pour Claude Code répertorie les autres champs de cet objet. Pour le volet facturation plutôt que celui de la session, consultez où vont réellement les tokens de Claude Code et les outils qui suivent les dépenses liées à Claude Code.

Comment vérifier le style de sortie réellement chargé

Utilisez ces vérifications plutôt que de vous fier aux suppositions.

• /status répertorie les sources de configuration actives pour cette session, notamment si des paramètres gérés par une organisation sont appliqués.
• /context affiche le prompt système chargé sous forme de catégorie dans la vue de répartition de la fenêtre de contexte.
• claude doctor, exécuté depuis le shell sans démarrer de session, affiche les diagnostics d’installation et de configuration, et signale les fichiers de configuration invalides.

Lorsqu’un style ne s’applique pas, la cause relève presque toujours de l’un de ces deux cas. Le premier est que vous l’avez modifié en cours de session : exécutez donc /clear. Le second est la priorité : .claude/settings.local.json prend le pas sur .claude/settings.json, et tous deux prennent le pas sur ~/.claude/settings.json. Comme le sélecteur /config écrit dans le fichier local, un style validé par votre équipe dans .claude/settings.json est silencieusement remplacé sur toute machine où quelqu’un a déjà utilisé le menu. /status indique quelle source a été retenue.

Une erreur de syntaxe JSON produit le même symptôme, mais sa correction est différente. claude doctor indique le fichier qu’il n’a pas pu analyser. Il est donc utile de l’exécuter avant de rechercher une cause plus complexe.

FAQ

Pourquoi la commande /output-style a-t-elle cessé de fonctionner ?

Elle a été dépréciée dans v2.1.73, puis supprimée dans v2.1.91. Avec une build de mi-2026, la commande n’existe donc plus. Exécutez claude --version pour vérifier votre version. Sélectionnez le style dans /config, sous Output style, ou définissez la clé outputStyle dans un fichier de configuration. La clé a survécu à la commande. Il est donc utile de noter dans vos propres notes comment la définir directement.

J’ai modifié mon style de sortie, mais rien ne s’est produit. Pourquoi ?

Le style de sortie fait partie du system prompt. Claude Code construit ce system prompt une seule fois, au démarrage de la session. Une modification effectuée en cours de session est enregistrée, mais pas appliquée, car la session en cours continue d’envoyer le prompt construit au démarrage. Exécutez /clear ou démarrez une nouvelle session. Si le changement ne s’applique toujours pas, exécutez /status pour voir quelle source de configuration a priorité, car .claude/settings.local.json remplace .claude/settings.json et les deux remplacent ~/.claude/settings.json.

Le style de sortie Concise permet-il de réduire les coûts ?

Il réduit les output tokens comme prévu, car il demande à Claude de produire par défaut des réponses courtes. La réduction dépend de vos prompts et de votre modèle. Considérez donc tout pourcentage publié comme une mesure effectuée sur le travail de quelqu’un d’autre. Mesurez vos propres résultats : exécutez /context dans une nouvelle session avec chaque style pour la partie input, puis exécutez la même tâche avec chaque style et comparez le nombre d’output tokens. Concise ne raccourcit jamais un rapport d’erreur ni un avertissement de sécurité. Les éléments que vous devez surtout lire restent donc complets.

Un changement de style de sortie modifie-t-il la façon dont mes subagents écrivent ?

Non. Les styles de sortie s’appliquent uniquement à la conversation principale. Un subagent démarre sa propre conversation avec son propre system prompt et son propre ensemble d’outils. Un fork de la conversation actuelle fait exception, car il hérite exactement du system prompt parent. Pour modifier les réponses d’un subagent, éditez le fichier propre à cet agent.

Un style de sortie peut-il permettre à Claude d’exécuter des commandes sans demander confirmation ?

Non. Un style de sortie est du texte dans le system prompt. Il peut donc uniquement influencer ce que Claude essaie de faire. Le style Proactive demande à Claude de prendre des décisions et d’agir plutôt que de s’arrêter pour les décisions courantes. Il ne peut toujours pas approuver une commande. Votre permission mode détermine ce qui s’exécute sans confirmation. C’est ce paramètre que vous devez vérifier avant de laisser une session s’exécuter sur un serveur.