Styles de sortie (Output Styles) : changer d'émission sans changer d'animateur

📚 Navigation dans la série : L'article précédent 31 settings.json : configuration au niveau utilisateur / projet a clarifié la question de savoir « dans quel fichier écrire la configuration et qui l'emporte ». Cet article se penche sur une option spécifique qui réside dans ces paramètres — les styles de sortie (output styles). Il ne gère pas « ce que Claude sait », mais « comment Claude vous répond ». Une simple ligne de configuration lui permet de passer de son rôle par défaut d'« ingénieur concentré sur sa tâche » à celui d'un tuteur expliquant ses actions en temps réel, ou même à une tout autre facette ne produisant aucun code.

On dit souvent que « pour faire obéir Claude, il suffit de tout accumuler dans CLAUDE.md » — conventions, règles et tout ce qu'il doit mémoriser.

Pour être honnête, ce n'est vrai qu'à moitié. Le fichier CLAUDE.md est certes l'endroit idéal pour y déposer le « contexte du projet » (voir l'article 18), mais y insérer un certain type de besoins revient à se tromper de tiroir.

Quel type de besoins ? « Je souhaite que le ton, le rôle ou le format de ses réponses changent à chaque fois ». Par exemple : je veux qu'il commence systématiquement par dessiner un schéma avant d'expliquer, qu'il m'explique pourquoi il écrit le code de cette façon en même temps qu'il le produit, ou même que je puisse l'utiliser comme assistant de rédaction et non comme programmeur. Si vous écrivez ces exigences dans CLAUDE.md, leur application sera aléatoire — car CLAUDE.md est « un message utilisateur ajouté après le prompt système », c'est une « requête » adressée à Claude, pas un interrupteur modifiant sa « nature profonde ». L'interrupteur qui modifie réellement « la façon dont Claude s'exprime » s'appelle les output styles.

Disons-le ainsi : CLAUDE.md est la documentation de projet remise à une nouvelle recrue, tandis que les output styles réécrivent directement sa fiche de poste — « pour ce rôle, es-tu un ingénieur concentré sur son code ou un tuteur qui explique ses actions ? ». Cet article explique comment actionner cet interrupteur.

Prenons un scénario parlant pour illustrer immédiatement l'utilité : permettre à une personne n'ayant aucune notion de code d'utiliser Claude Code pour réécrire son CV. Avec sa personnalité d'ingénieur par défaut, il aura tendance à vouloir « diviser ce bloc en fonctions » ou demander « s'il faut ajouter des tests » — sa pensée axée sur l'ingénierie logicielle est totalement déconnectée de la relecture de CV. Ce n'est pas un problème que CLAUDE.md peut résoudre, et c'est précisément la raison d'être des output styles.

À la fin de cet article, vous obtiendrez :

• L'explication en une phrase de ce que modifient réellement les output styles (rappel : « comment il répond », pas « ce qu'il sait »)
• Les styles intégrés de Claude Code (Default, Proactive, Explanatory, Learning) : leurs rôles et quand les utiliser
• Comment changer de style — avec une alerte sur un changement de version : l'ancienne commande /output-style ayant été supprimée, comment procéder aujourd'hui
• Comment créer votre propre style de sortie : la structure du fichier Markdown, le rôle de chaque champ du frontmatter, et l'erreur à éviter avec le paramètre keep-coding-instructions
• Un tableau comparatif pour distinguer les output styles de CLAUDE.md, de --append-system-prompt, des Subagents et des skills

---

01 Le principe clé : modifier la « réponse », pas le « savoir »

Commençons par poser la phrase la plus importante de cet article, sur laquelle repose tout le reste :

Les styles de sortie modifient la façon dont Claude répond, et non ce que Claude sait.

C'est la formulation de la documentation officielle. Cela signifie que les output styles n'apportent pas de nouvelles connaissances sur votre projet à Claude. Ils agissent sur le prompt système (system prompt, la directive de base chargée au début de chaque session qui définit « qui est Claude et comment il travaille ») pour lui attribuer un rôle, un ton et un format de sortie.

Analogie : Un même animateur qui adapte sa posture selon l'émission. C'est la même personne, avec les mêmes compétences de base (son élocution, ses connaissances) ; mais elle adoptera un ton posé pour présenter le journal télévisé, un ton dynamique pour une émission jeunesse, et ralentira le rythme pour expliquer et poser des questions dans un programme éducatif. C'est le format de l'émission qui dicte sa façon de s'exprimer, sans pour autant le remplacer par quelqu'un d'autre. Les output styles changent « l'émission » de Claude — le modèle reste le même, ses capacités sont inchangées, mais son rôle, son ton et son format d'échange varient.

Quand est-ce utile ? La documentation officielle donne ce critère :

Utilisez-en un lorsque vous répétez continuellement la même consigne de ton ou de format à chaque interaction, ou lorsque vous souhaitez que Claude adopte un rôle autre que celui d'ingénieur logiciel.

En clair, cela correspond à deux situations :

• « Une instruction que je dois retaper à chaque interaction » — par exemple, si vous devez rappeler à chaque fois « commence ton explication par un schéma Mermaid », vous devriez après quelques répétitions vous dire qu'il est temps de figer cette consigne dans un style de sortie.
• « La tâche demandée ne concerne pas du tout l'écriture de code » — par exemple, utiliser Claude comme assistant d'écriture ou analyste de données. Le prompt système par défaut de Claude Code est optimisé pour « réaliser efficacement des tâches de développement logiciel ». Si vous lui demandez de rédiger un texte, les directives d'ingénierie telles que « limiter la portée des modifications, ajouter des commentaires, valider le travail » deviennent des contraintes inutiles.

Revenons au cas de la réécriture de CV de l'introduction — c'est le parfait exemple de cette seconde situation : la personnalité par défaut de Claude Code est entièrement configurée pour l'ingénierie logicielle. Lui demander de relire un CV alors qu'il a ces directives en tête génère des interférences. Ce type de besoin visant à « sortir du rôle d'ingénieur » ne se résout pas en écrivant « oublie que tu es programmeur » dans CLAUDE.md — car CLAUDE.md est une requête ajoutée en fin de contexte, alors que l'output style est l'outil approprié pour modifier sa fiche de poste.

💡 En résumé : les output styles modifient le prompt système de Claude — en changeant son rôle, son ton et son format de réponse. Ils modifient « comment il répond », pas « ce qu'il sait ». Pensez-y dans deux cas : une instruction répétée à chaque échange, ou pour effectuer des tâches autres que de la programmation.

---

02 Quatre styles intégrés : trois options prêtes à l'emploi en plus du style par défaut

Pas besoin d'écrire vos propres styles immédiatement, Claude Code en propose plusieurs intégrés d'office. Passons-les en revue.

Le style Default (Par défaut) est celui que vous utilisez depuis le début de cette série — son prompt système est spécifiquement calibré pour « mener à bien des tâches d'ingénierie logicielle ». Travailler efficacement, limiter les modifications au strict nécessaire et valider le travail constituent le « cœur de métier » de Claude Code. Sans besoin particulier, conservez ce style.

En plus du style par défaut, la documentation officielle propose trois styles supplémentaires :

Proactive (Proactif) — Plus autonome dans ses choix, privilégie l'action à la planification. La documentation indique : « il s'exécute immédiatement, formule des hypothèses raisonnables plutôt que de s'interrompre pour des prises de décision de routine, et privilégie l'action à la planification ». En clair, il réduit les validations incessantes et avance de lui-même sur les choix courants.

Un point de confusion fréquent est souligné officiellement : Proactive propose des « consignes » d'exécution plus autonomes que le mode automatique, mais sans modifier votre mode de gestion des autorisations — vous verrez toujours apparaître les invites de validation avant l'exécution des outils. Le mode d'autorisation (vu à l'article 20, qui détermine si l'agent doit demander l'autorisation de l'utilisateur) et le style Proactive (qui définit le degré d'initiative de l'agent dans ses propositions de modification) sont deux concepts distincts.

Explanatory (Explicatif) — Fournit des explications pédagogiques au fil de l'eau. Tout en réalisant vos tâches de développement, il insère des remarques explicatives (« Insights ») pour vous aider à comprendre « pourquoi cette solution est choisie, ou quel est le modèle de conception appliqué dans cette base de code ». Idéal si vous souhaitez monter en compétences sur le code produit plutôt que de simplement obtenir un résultat.

Learning (Apprentissage) — Travail collaboratif avec exercices pratiques. C'est le style le plus interactif. En plus de partager des explications comme le style Explanatory, il insère des balises TODO(human) dans le code pour vous demander d'écrire vous-même de courtes sections de code stratégiques. Claude configure ainsi la structure générale et vous confie l'écriture des lignes clés — pour vous forcer à pratiquer plutôt que de le regarder faire.

Illustrons ces différences sur une tâche concrète telle que « ajouter une pagination à cette liste » :

• Avec Proactive, il modifiera directement le code sans vous demander au préalable « s'il faut valider un plan d'action » ;
• Avec Explanatory, il effectuera la modification tout en expliquant « pourquoi utiliser une pagination par curseur plutôt qu'avec offset, et comment le reste du projet gère ce cas » ;
• Avec Learning, il posera la structure générale et insérera un commentaire // TODO(human): implémenter ici l'analyse du curseur dans la fonction principale, vous tendant ainsi le clavier.

Comparons les quatre options disponibles :

Style intégré	Différence clé par rapport au style par défaut	Quand l'activer	Réponses plus longues ?
Default (Par défaut)	——	Développement classique, dans la majorité des cas	Référence
Proactive	Plus d'initiative, moins de confirmations, priorité à l'action	Pour éviter les validations répétitives sur des tâches courantes	Pas nécessairement
Explanatory	Ajoute des explications et des « Insights »	Pour comprendre la logique d'implémentation et la structure	Oui (par conception)
Learning	Explications + balises TODO(human) pour vous faire coder	Pour apprendre et pratiquer sur un sujet donné	Oui (par conception)

La dernière colonne « Réponses plus longues ? » mérite votre attention : la documentation indique que les styles Explanatory et Learning produisent par conception des réponses plus longues en raison de l'ajout d'explications et d'exercices. Des réponses plus longues se traduisent par une consommation accrue de tokens de sortie (voir les détails de facturation à l'article 06). Évitez donc de les laisser activés par défaut : utilisez-les dans vos phases d'apprentissage, et revenez au style Default pour vos tâches courantes afin d'optimiser votre consommation et la lisibilité des réponses.

Un schéma d'utilisation typique : conservez Default au quotidien ; si vous découvrez un dépôt open-source inconnu et souhaitez comprendre sa structure tout en faisant des modifications, passez sur Explanatory ; enfin, si vous apprenez un nouveau framework et souhaitez coder activement avec un guide, choisissez Learning. L'usage de Proactive dépend de votre goût personnel — si vous préférez que l'agent avance rapidement plutôt que de s'arrêter à chaque étape, activez-le.

💡 En résumé : quatre styles intégrés sont disponibles — Default effectue la tâche, Proactive prend des initiatives en limitant les confirmations, Explanatory explique ses choix, et Learning vous propose de coder les parties clés. Les deux derniers styles consomment plus de tokens ; utilisez-les de manière ciblée et revenez au style par défaut ensuite.

---

03 Comment changer de style : l'ancienne commande /output-style a disparu

Un point d'attention important concernant une évolution récente du produit : certaines documentations ou vidéos obsolètes font référence à une commande qui n'existe plus.

Il est souvent indiqué d'utiliser la commande /output-style. Cette commande dédiée a été supprimée. La documentation officielle le précise :

La commande autonome /output-style a été dépréciée dans la version 2.1.73 et supprimée dans la version 2.1.91. Utilisez /config ou éditez directement le paramètre outputStyle.

Deux méthodes sont aujourd'hui disponibles pour changer de style :

Méthode 1 : Via le menu /config (recommandé et visuel)

Saisissez /config dans votre session Claude et sélectionnez l'option Output Styles (Styles de sortie) pour choisir le style souhaité. La documentation indique :

Lancez /config et choisissez Output Styles pour sélectionner un style dans le menu. Votre choix sera enregistré dans le fichier de configuration locale du projet nommé .claude/settings.local.json.

Notez la destination de cet enregistrement — le style choisi dans le menu est écrit dans le fichier .claude/settings.local.json de votre projet. Comme vu à l'article 31, ce fichier settings.local.json est spécifique au projet, propre à votre machine et n'est pas suivi par le système de contrôle de version. Autrement dit, ce changement n'affecte que vos sessions sur ce projet et n'est pas partagé avec vos collaborateurs.

Méthode 2 : En modifiant directement le paramètre outputStyle

Vous pouvez également ajouter le paramètre outputStyle dans votre fichier de configuration settings :

{
  "outputStyle": "Explanatory"
}

Indiquez le nom du style comme valeur (les valeurs intégrées Explanatory, Learning, Proactive, ou le nom de votre style personnalisé). Le fichier dans lequel vous insérez ce paramètre détermine sa portée — ajoutez-le dans ~/.claude/settings.json pour un comportement global par défaut, ou dans le fichier settings du projet pour un comportement ciblé. Les règles de priorité de ces fichiers de configuration sont identiques à celles décrites à l'article 31.

La règle d'application à retenir

Quel que soit le moyen utilisé, le moment où la modification prend effet suit une règle précise :

Les styles de sortie font partie du prompt système, lu une seule fois par Claude Code à l'ouverture de la session. Les changements prennent effet après un /clear ou à l'ouverture d'une nouvelle session.

Analogie : Le conducteur d'un train reçoit sa feuille de route au départ de la gare. Si vous modifiez la feuille de route pendant le trajet, le conducteur ne la consultera pas — il faut attendre le prochain trajet pour que la modification soit prise en compte. Le principe est le même pour les output styles : ils sont intégrés au prompt système de base, chargé par Claude une seule fois en début de session. Modifier le style en cours de route ne changera pas son comportement immédiatement ; vous devez utiliser la commande /clear (qui réinitialise la session comme vu à l'article 19) ou ouvrir une nouvelle session pour charger le nouveau style.

C'est une erreur classique lors de la première utilisation : configurer le style Explanatory via /config et constater que l'agent continue à produire du code sans aucune explication. Ce n'est pas un dysfonctionnement — c'est simplement que le prompt système de la session en cours n'a pas été réinitialisé avec /clear. Exécutez /clear pour voir les explications apparaître. Gardez cela en tête pour éviter des recherches inutiles.

💡 En résumé : la commande /output-style a été supprimée. Pour changer de style, utilisez le menu /config (les paramètres s'enregistrent dans settings.local.json) ou déclarez directement le paramètre outputStyle dans vos fichiers de configuration. Exécutez /clear ou ouvrez une nouvelle session pour appliquer la modification.

---

04 Créer un style de sortie personnalisé : un simple fichier Markdown

Si les styles intégrés ne répondent pas à vos besoins, vous pouvez concevoir le vôtre. La mise en œuvre est simple — un simple fichier Markdown suffit.

La documentation officielle décrit sa structure de la manière suivante :

Un style de sortie personnalisé est un fichier Markdown : le frontmatter contient les métadonnées, suivies des instructions à ajouter au prompt système.

Le fichier comporte deux parties : le frontmatter en en-tête (les métadonnées entourées par ---) + les instructions du corps (les directives à ajouter au prompt système). Créons un style personnalisé en trois étapes.

Étape 1 : Enregistrer le fichier au bon emplacement

Comme pour les autres extensions (skills, Subagents), les styles de sortie proposent trois niveaux de stockage qui déterminent leur visibilité :

Niveau	Répertoire de stockage	Portée d'utilisation
Utilisateur	~/.claude/output-styles	Disponible pour tous vos projets
Projet	.claude/output-styles (à la racine du projet)	Spécifique au projet en cours, partagé via Git avec vos collaborateurs
Politique d'entreprise (Managed)	Sous .claude/output-styles du répertoire des configurations d'entreprise	Déployé et géré de manière centralisée par l'organisation

Cette organisation (projet vs utilisateur) suit la même logique que celle des settings (article 31) ou de la mémoire (article 25) : ce qui relève de vos préférences personnelles transversales va dans le dossier utilisateur (~/.claude/output-styles) ; ce qui relève des spécificités du projet et doit être partagé avec vos collaborateurs va dans le dossier projet (.claude/output-styles) pour être suivi par Git.

Une règle de nommage s'applique :

Le nom du fichier définit par défaut le nom du style, sauf si un champ name est spécifié dans le frontmatter.

Si vous créez un fichier code-reviewer.md, le style s'appellera par défaut code-reviewer ; si vous déclarez un champ name différent dans le frontmatter, c'est cette valeur qui sera retenue.

Étape 2 : Rédiger le frontmatter et les instructions

Prenons l'exemple proposé par la documentation officielle — un style qui demande à Claude d'accompagner systématiquement ses explications d'un schéma. Analysons sa structure :

---
name: Diagrams first
description: Lead every explanation with a diagram
keep-coding-instructions: true
---

When explaining code, architecture, or data flow, start with a Mermaid diagram showing the structure, then explain in prose.

## Diagram conventions

Use `flowchart TD` for control flow and `sequenceDiagram` for request paths. Keep diagrams under 15 nodes.

La section supérieure délimitée par --- correspond au frontmatter, tandis que la section inférieure contient les instructions (ici rédigées en anglais : « pour expliquer le code, l'architecture ou les flux de données, commencez par présenter un schéma Mermaid décrivant la structure, puis détaillez le fonctionnement sous forme textuelle... »). Ces instructions seront ajoutées au prompt système de Claude — il commencera alors par dessiner un schéma à chaque fois qu'il devra expliquer un concept.

Le frontmatter accepte quatre paramètres :

Paramètre du frontmatter	Rôle	Valeur par défaut
name	Nom du style (si omis, utilise le nom du fichier)	Nom du fichier sans extension
description	Description du style, affichée dans le menu /config	Aucun
keep-coding-instructions	Conserve les instructions d'ingénierie logicielle par défaut de Claude Code	false
force-for-plugin	Réservé aux plug-ins : applique automatiquement ce style lorsque le plug-in est actif	false

Les deux premiers paramètres sont évidents — name définit le nom et description fournit l'explication textuelle affichée dans les menus. Les deux suivants méritent des précisions. Le paramètre keep-coding-instructions est le plus important à configurer correctement, son rôle étant détaillé à la section suivante. force-for-plugin concerne le développement de plug-ins (vu à l'article 24, un plug-in pouvant embarquer et diffuser ses propres styles de sortie) et n'est pas nécessaire pour vos styles personnels d'usage courant.

Étape 3 : Activer votre nouveau style

Une fois le fichier enregistré et configuré, ouvrez le menu /config et sélectionnez votre nouveau style dans la liste Output Styles (qui affichera également sa description). N'oubliez pas — exécutez /clear ou relancez la session pour appliquer le changement.

💡 En résumé : un style personnalisé est un fichier Markdown comportant un en-tête frontmatter pour les métadonnées et un corps pour les instructions à ajouter au prompt système. Enregistrez-le dans le dossier utilisateur pour un usage global ou dans le projet pour un partage d'équipe. Sélectionnez-le dans /config et réinitialisez la session avec /clear.

---

05 Le paramètre clé : keep-coding-instructions

Le paramètre keep-coding-instructions du frontmatter mérite une attention particulière : une mauvaise valeur pour ce champ modifiera radicalement le comportement de votre style personnalisé.

Détaillons son rôle. Par défaut, le prompt système de Claude Code contient de nombreuses « instructions d'ingénierie logicielle » — gestion des modifications, commentaires, étapes de validation. Par défaut, la création d'un style personnalisé désactive ces instructions intégrées. La documentation officielle précise :

Les styles de sortie personnalisés excluent les instructions d'ingénierie logicielle par défaut de Claude Code... sauf si keep-coding-instructions est défini sur true.

Ce paramètre est à false par défaut. Cela signifie que votre style personnalisé va remplacer l'intégralité des directives d'ingénierie logicielle intégrées pour ne conserver que les vôtres. Conserver ou supprimer ces directives dépend de la tâche à accomplir : Claude doit-il continuer à écrire du code avec ce style ?

Posez-vous cette question : « Dans le cadre de ce style, Claude va-t-il continuer à programmer ? »

• Oui, il doit programmer mais avec une forme de réponse différente (par exemple : « code comme d'habitude, mais ajoute systématiquement un schéma ») → Définissez keep-coding-instructions: true pour conserver les directives d'ingénierie. C'est le cas de l'exemple « Diagrams first » de la section précédente qui modifie la forme de l'explication mais conserve la programmation, d'où la valeur true configurée par défaut.
• Non, il n'écrira pas de code (par exemple : utilisation comme assistant de rédaction, analyste de données, traducteur) → Omettez ce paramètre (valeur par défaut false) pour supprimer les directives de développement. S'il ne doit pas programmer, les consignes d'ingénierie telles que « limiter les modifications ou lancer des tests » sont inutiles et perturbent son action.

La documentation officielle résume ce choix de manière très claire :

Conservez-les lorsque vous modifiez la façon de s'exprimer de Claude tout en continuant à programmer (par exemple, pour répondre systématiquement avec des diagrammes). Omettez-les lorsque Claude ne fait plus de développement logiciel (par exemple, pour un assistant d'écriture ou un analyste de données).

Comparons les deux scénarios et l'impact d'une erreur de configuration :

Objectif du style	Valeur recommandée	Conséquence d'une erreur
Programmation classique avec adaptation des réponses (schémas, formats spécifiques...)	true (conserver les consignes d'ingénierie)	❌ Défini à false : l'agent perd ses consignes de rigueur (validation, tests) et réalise des modifications de code de manière moins structurée
Aide à la rédaction ou analyse sans code (CV, articles, traduction...)	Omettre (par défaut false : supprimer les consignes d'ingénierie)	❌ Défini à true : l'agent garde ses réflexes de développeur (fonctions, tests) inadaptés pour un assistant de rédaction

C'était précisément l'origine du problème pour la relecture de CV évoquée à la section 01. Nous avions besoin d'une personnalité d'« assistant d'écriture », débarrassée des consignes d'ingénierie. En concevant un style personnalisé et en omettant le paramètre keep-coding-instructions (pour désactiver les consignes d'ingénierie), l'agent n'aurait plus cherché à « diviser le texte du CV en fonctions ». Ce paramètre définit en quelque sorte si la nouvelle personnalité de l'agent conserve ses responsabilités de développeur.

💡 En résumé : keep-coding-instructions vaut false par défaut et supprime les directives d'ingénierie logicielle. Posez-vous une seule question : « L'agent va-t-il coder avec ce style ? » — Si oui, définissez-le à true ; si non, omettez-le pour libérer l'agent des consignes de développement.

---

06 Fonctionnement interne : l'assemblage du prompt système

Nous avons évoqué l'ajout d'instructions au prompt système et la nécessité de réinitialiser la session avec /clear. Regardons comment ce mécanisme fonctionne en coulisses. Comprendre ce fonctionnement clarifie l'ensemble des comportements observés : la nécessité de réinitialiser la session, l'impact sur chaque réponse et le rôle du paramètre keep-coding-instructions.

La documentation officielle résume le fonctionnement interne en trois règles :

• Tous les styles de sortie ajoutent leurs instructions personnalisées à la fin du prompt système.
• Tous les styles de sortie déclenchent des rappels pendant la conversation pour s'assurer que Claude respecte les consignes du style.
• Les styles de sortie personnalisés excluent les instructions d'ingénierie logicielle par défaut de Claude Code... sauf si keep-coding-instructions est défini sur true.

Première règle : les instructions de votre style sont ajoutées à la toute fin du prompt système. Ce prompt système définit la base du comportement de Claude pour la session, et votre style y est greffé en terminaison — il s'applique donc à chacune des réponses produites au cours de la session.

Deuxième règle : des rappels réguliers sont envoyés à Claude pendant l'échange. Au cours d'une longue conversation, un modèle d'IA peut perdre le fil de ses directives initiales. Ce mécanisme de rappel régulier lui renvoie ses consignes de style pour s'assurer qu'il ne s'en écarte pas.

Troisième règle : les styles personnalisés retirent par défaut les directives d'ingénierie logicielle intégrées du prompt système ; définir keep-coding-instructions: true indique explicitement à l'agent de les conserver. C'est ce qui permet d'orienter le rôle de l'agent (développement ou autre tâche) en gérant la présence de ces directives dans le prompt système assemblé.

Voici comment le prompt système de Claude est assemblé :

Ce schéma montre qu'à l'ouverture de la session, Claude Code assemble son prompt système selon le style choisi : les styles intégrés et les styles personnalisés configurés avec keep=true incluent les directives d'ingénierie logicielle, tandis que les styles personnalisés configurés avec keep=false (ou par omission) les suppriment pour ne conserver que vos instructions spécifiques. Une fois ce prompt système assemblé, il s'applique à chaque réponse de la session. Si vous changez de style en cours de route, vous devez exécuter /clear ou ouvrir une nouvelle session pour réassembler le prompt système avec la nouvelle configuration (c'est la raison d'être de la remarque de la section 03).

Un mot sur la consommation de tokens (voir les détails de facturation à l'article 06). La documentation précise :

La consommation de tokens dépend du style choisi. L'ajout d'instructions au prompt système augmente les tokens d'entrée, bien que le mécanisme de prompt caching (mise en cache des invites) en réduise le coût lors des requêtes suivantes au sein d'une même session.

En clair : les instructions du style intègrent le prompt système et représentent une consommation de tokens d'entrée. Heureusement, grâce au prompt caching de Claude Code (qui met en cache le prompt système inchangé pour le réutiliser), ce coût est optimisé après la première requête de la session. La consommation réelle provient plutôt de l'utilisation de styles tels que Explanatory ou Learning qui produisent par conception des réponses plus denses (impactant les tokens de sortie). Il en va de même pour les styles personnalisés que vous concevez — plus vos instructions incitent l'agent à détailler ses réponses, plus la consommation de tokens augmente.

💡 En résumé : les instructions d'un style sont greffées en fin de prompt système, s'appliquent à toute la session et font l'objet de rappels réguliers. Les styles personnalisés suppriment par défaut les directives d'ingénierie (sauf si keep=true). Un changement de style nécessite un /clear pour régénérer le prompt système. La configuration consomme quelques tokens optimisés par le prompt caching, la longueur des réponses produites restant le facteur principal de facturation.

---

07 output styles vs CLAUDE.md / Skill / Subagent : les différences

Une question se pose naturellement : quelle est la différence entre les output styles et les outils vus précédemment comme CLAUDE.md, les skills ou les Subagents, qui permettent tous de personnaliser le comportement de Claude ? Clarifions ces rôles. L'article 30 proposait un tableau d'aide à la décision selon les besoins, concentrons-nous ici sur la distinction avec les output styles.

La spécificité des output styles est d'agir directement sur le prompt système et de s'appliquer à chaque réponse de la session. Les autres outils agissent soit en fin de prompt, soit uniquement lors de conditions spécifiques. Le tableau comparatif officiel résume ces rôles :

Outil	Fonctionnement	Quand l'utiliser (plutôt qu'un style de sortie)
Output Style	Modifie directement le prompt système, s'applique à chaque réponse	Pour changer de rôle, de ton ou de format de manière globale pour toute la session
CLAUDE.md (article 18)	Ajoute un message utilisateur après le prompt système	Pour fournir les conventions du projet et le contexte du code, pas le style d'expression
--append-system-prompt	Ajoute des instructions en fin de prompt système	Pour ajouter temporairement des directives lors d'une unique exécution
Subagent (article 23)	Exécute un sous-agent avec son propre prompt système, modèle et outils	Pour déléguer une tâche spécifique dans un contexte isolé et récupérer le résultat
Skill (article 26)	Charge des instructions uniquement lors de l'appel ou si le contexte le demande	Pour figer un processus ou flux de travail réutilisable à la demande

Il convient de bien distinguer les deux premiers éléments — les output styles et CLAUDE.md — qui sont les plus proches dans leur objectif de personnalisation. Leurs rôles sont pourtant bien distincts :

CLAUDE.md contient le « fond / contexte », l'output style définit la « forme / posture ». L'un explique « quel est ce projet et quelles sont ses conventions », l'autre définit « avec quel ton et quel format tu dois interagir ». Pour reprendre notre analogie : CLAUDE.md est le dossier projet fourni au développeur, l'output style est sa fiche de poste. Vous ne devez pas indiquer « nous utilisons pnpm et non npm » dans un output style (c'est une convention de projet, à placer dans CLAUDE.md), ni imposer « commence toujours tes réponses par un schéma » dans CLAUDE.md (c'est une consigne de forme, à placer dans un output style). La documentation officielle le rappelle explicitement :

Pour les instructions concernant votre projet, vos conventions ou votre base de code, utilisez plutôt CLAUDE.md.

Concernant --append-system-prompt, il agit également sur le prompt système mais de manière temporaire, contrairement à la configuration durable d'un output style : --append-system-prompt est une directive ajoutée en ligne de commande pour la session en cours, qui disparaît ensuite. C'est l'outil adapté pour tester un style de manière ponctuelle :

claude --append-system-prompt "这次回答都用中文、尽量简短"

La configuration disparaît à la fermeture de la session. Si ce style d'échange doit être réutilisé au quotidien, il convient de l'enregistrer sous forme d'output style. Utilisez l'option en ligne de commande pour un test ponctuel, et l'output style pour un usage régulier.

Faisons également la distinction avec les Skills (article 26) : un Skill est un flux de travail réutilisable chargé à la demande, qui ne charge pas le prompt système par défaut et s'active uniquement lors d'un appel direct /<nom> ou si Claude le juge nécessaire. L'output style est une configuration de posture permanente appliquée à chaque réponse. Le Skill est une recette de cuisine que l'on sort du placard au besoin, l'output style est le ton de l'animateur tout au long de l'émission.

Une erreur courante consiste à vouloir « demander à Claude d'être concis dans ses réponses » en ajoutant cette consigne dans CLAUDE.md. Le résultat est irrégulier — car les consignes de style doivent être configurées dans le prompt système (via un output style) et non dans les messages de contexte de CLAUDE.md. C'est le même type d'erreur qui consiste à insérer une documentation d'API de trois cents lignes dans CLAUDE.md : chaque information doit être rangée dans le bon tiroir.

💡 En résumé : la spécificité des output styles est de modifier le prompt système pour toute la session. Ne les confondez pas avec CLAUDE.md : CLAUDE.md gère le contexte du projet (le fond), l'output style gère la posture de l'agent (la forme). Utilisez --append-system-prompt pour un test ponctuel et les Subagents pour isoler une tâche.

---

08 Pratique : créer le style « Diagrams first » et valider son fonctionnement

Passons à la pratique. Nous allons créer un style personnalisé, l'activer et vérifier son fonctionnement. Nous allons implémenter l'exemple classique « Diagrams first » (Les schémas d'abord). Cet exercice peut être réalisé dans n'importe quel répertoire, sans projet complexe préalable.

Étape 1 : Créer le fichier de style

Nous allons l'enregistrer dans le dossier utilisateur (~/.claude/output-styles) pour qu'il soit disponible pour tous vos projets. Créez le dossier, puis le fichier :

mkdir -p ~/.claude/output-styles

Utilisez votre éditeur pour créer le fichier diagrams-first.md sous ~/.claude/output-styles/ et collez-y les instructions suivantes :

---
name: Diagrams first
description: 每次解释都先画一张图，再用文字说明
keep-coding-instructions: true
---

解释代码、架构 or 数据流时，先给一张展示结构的 Mermaid 图，再用文字解释。

## 画图约定

控制流用 `flowchart TD`，请求路径用 `sequenceDiagram`。每张图节点控制在 15 个以内。

Notez la présence du paramètre keep-coding-instructions: true — car dans ce style, Claude doit continuer à programmer normalement tout en adoptant le réflexe de dessiner des schémas. Nous devons donc conserver les instructions d'ingénierie logicielle par défaut (comme vu à la section 05).

Étape 2 : Sélectionner le style

Ouvrez une session Claude Code, saisissez /config et accédez au menu Output Styles pour sélectionner Diagrams first.

claude

Une fois dans la session, tapez /config, utilisez les flèches pour sélectionner « Output Styles », appuyez sur Entrée, puis choisissez Diagrams first.

Résultat attendu : L'option Diagrams first doit apparaître dans la liste avec la description que vous avez configurée. Sa présence confirme que le fichier a été correctement détecté. Si l'option n'apparaît pas, verifiez que le fichier est enregistré dans le bon dossier et que la structure du frontmatter --- est correcte.

Étape 3 : Réinitialiser avec /clear

Avant d'envoyer votre question — exécutez la commande /clear (comme vu à la section 03, le prompt système n'est chargé qu'à l'initialisation) :

/clear

Étape 4 : Tester et valider le comportement

Posez une question nécessitant une explication pour observer la mise en œuvre du style :

解释一下用户登录的请求是怎么从前端走到数据库的

Résultat attendu : Claude doit commencer sa réponse par un schéma Mermaid (probablement un sequenceDiagram décrivant les échanges entre le Front-end, le Back-end et la Base de données), puis détailler le fonctionnement par écrit. Si le schéma apparaît avant les explications textuelles, votre style personnalisé est opérationnel.

Pour comparer, retournez dans /config, sélectionnez le style Default, exécutez /clear et posez la même question — Claude répondra uniquement par du texte, sans schéma. Cette différence de comportement confirme l'impact direct de l'output style sur la forme des réponses de l'agent.

Étape 5 : Nettoyer (optionnel)

Si vous souhaitez supprimer ce style personnalisé, supprimez simplement le fichier correspondant :

rm ~/.claude/output-styles/diagrams-first.md

Le style disparaît du menu /config. (Si le style était actif, pensez à sélectionner Default dans /config au préalable.)

En déroulant ces cinq étapes, vous avez validé le flux complet : créer le fichier .md → sélectionner le style → appliquer avec /clear → tester et valider → supprimer. La création de tout autre style personnalisé suivra cette méthode en adaptant les instructions et le paramètre keep-coding-instructions.

💡 En résumé : le test pratique se déroule en cinq étapes — créer le fichier .md, le sélectionner dans /config, appliquer avec /clear, valider la présence du schéma en début de réponse, puis supprimer le fichier pour nettoyer. La comparaison avec le style par défaut met en évidence la modification du comportement de l'agent.

---

09 Résumé

Cet article a détaillé le rôle et le fonctionnement des output styles — cet outil qui configure comment Claude répond plutôt que ce que Claude sait.

Synthétisons les points clés :

Objectif	Action	Point clé
Comprendre l'outil	Modifier la posture (rôle, ton, format) du prompt système	Modifie « comment il répond », pas « ce qu'il sait »
Utiliser les styles intégrés	Default / Proactive / Explanatory / Learning	Les deux derniers styles sont plus denses et consomment plus de tokens
Changer de style	Sélectionner dans le menu /config ou éditer outputStyle	L'ancienne commande /output-style a été supprimée ; exécuter /clear pour appliquer
Créer un style personnalisé	Rédiger un fichier Markdown (frontmatter + instructions)	Le nom du fichier définit le nom du style ; stocker dans le dossier utilisateur ou projet
Gérer les consignes d'ingénierie	Configurer keep-coding-instructions	Définir à true si l'agent doit programmer, omettre (par défaut false) s'il effectue d'autres tâches
Différencier de CLAUDE.md	Distinguer le fond de la forme	Les conventions et le code vont dans CLAUDE.md ; le ton et le format de réponse dans l'output style

Vous devriez maintenant être capable de : expliquer le rôle des output styles, choisir parmi les quatre styles intégrés selon la tâche, changer de style via /config et appliquer la modification avec /clear, concevoir un style personnalisé dans un fichier Markdown en configurant correctement le paramètre keep-coding-instructions, et le distinguer de CLAUDE.md, des skills ou des Subagents. Vous disposez ainsi des clés pour adapter la posture de Claude Code à vos différents besoins, en le transformant selon le cas en développeur rigoureux, en tuteur pédagogue ou en assistant de rédaction.

Pour les consignes de style, de ton ou de format, utilisez les output styles ; pour le contexte et les règles de votre base de code, utilisez CLAUDE.md. En rangeant chaque consigne dans le bon outil, vous tirerez le meilleur parti de vos sessions.

---

Le prochain article 33 Les hooks vous présentera les actions automatisées. Les output styles modifient la posture de Claude Code, mais son exécution dépend de sa volonté de suivre les consignes. Existe-t-il un moyen de s'assurer qu'une action soit exécutée de manière systématique, sans dépendre de l'initiative de l'agent ? Par exemple : « exécuter un outil de formatage après chaque modification de fichier » ou « bloquer l'exécution d'une commande jugée à risque ». C'est le rôle des Hooks — des points de passage automatisés déclenchés par des événements. Nous avons amorcé ce sujet à l'article 30, nous le détaillerons dans l'article suivant. Quelles sont les vérifications ou actions répétitives que vous aimeriez automatiser après chaque intervention de Claude ?

---

Lectures recommandées

• Commandes slash (Slash Commands) : appeler les raccourcis de Claude d'un simple /
• Gestion du contexte : éviter les pertes de mémoire et optimiser la consommation de tokens
• Guide de référence du CLI : options et drapeaux de commande