Ce que c'est et pourquoi ça compte
Si vous construisez votre app avec Claude sans comprendre le code, le jour où elle casse, vous êtes bloqué. Vous ne savez pas où regarder, et vous demandez de réparer quelque chose que vous ne savez même pas décrire. Plus l'app grandit, plus ça pèse.
Claude Code a déjà une réponse intégrée : les styles de sortie. Un style est un ensemble d'instructions qui change la façon dont Claude vous répond pendant toute la session. En plus du style de base, appelé Default, il en inclut quatre : Proactive, Concise, Explanatory et Learning. Learning est celui pensé pour apprendre.
Avec Learning, Claude fait toujours le travail de routine. Mais quand il arrive à un morceau avec un vrai choix, il vous laisse quelques lignes à écrire et vous explique ses propres choix au passage. Vous finissez l'app quand même, mais certaines lignes clés, c'est vous qui les avez écrites. C'est pour ceux qui construisent seuls avec Claude et veulent comprendre leur code assez bien pour le réparer.
1. Comment l'activer
Il y a une voie pour chaque endroit où vous utilisez Claude Code. La commande et les deux menus enregistrent votre choix dans le fichier .claude/settings.local.json du projet : il ne vaut que dans ce projet, et que pour vous.
- Dans le terminal : tapez /output-style learning. La commande ignore les majuscules et les minuscules. Si vous tapez seulement /output-style, elle liste les styles et marque celui qui est actif.
- Toujours dans le terminal, avec le menu : tapez /config et choisissez Output style.
- Dans l'extension VS Code : tapez / dans la zone de saisie et choisissez Output styles.
- Dans l'app de bureau : ici /config ouvre les réglages de l'app, pas le menu. Écrivez vous-même le champ outputStyle dans le fichier .claude/settings.local.json du projet, comme ci-dessous, puis ouvrez une nouvelle session.
{
"outputStyle": "Learning"
}Dans le fichier, la majuscule compte : écrivez Learning, pas learning. Un nom mal écrit ne donne aucune erreur : il vous laisse dans le style Default sans vous prévenir. Si le fichier contient déjà d'autres réglages, ajoutez seulement la ligne outputStyle à l'intérieur des accolades existantes.
Si vous voulez Learning dans tous vos projets, mettez le même champ dans le fichier de votre utilisateur, ~/.claude/settings.json. Mais les réglages d'un projet l'emportent sur ceux de l'utilisateur : si un projet a son propre outputStyle, c'est celui-là qui s'applique.
Si vous changez de style en cours de session, dans la dernière version de Claude Code le nouveau style s'applique dès votre message suivant : pas besoin de recommencer.
2. Ce qui se passe pendant qu'il travaille
Vous lui donnez une tâche comme d'habitude. À partir de là, ça se passe comme ça :
- Il fait le travail de routine : les fichiers à créer, les branchements, les parties qui ne s'écrivent que d'une seule façon.
- Quand il arrive à un morceau avec un vrai choix, il s'arrête. La documentation donne trois exemples : comment gérer une erreur, comment organiser les données, une règle de votre app qui peut s'écrire de plusieurs façons correctes.
- Dans le fichier, à l'endroit exact, il laisse un commentaire repère : le mot anglais pour « à faire » suivi de (human), c'est-à-dire « humain ». Pour le trouver, cherchez (human) dans le fichier.
- Il vous envoie une demande Learn by Doing en trois parties : Context, ce qui est déjà en place ; Your Task, ce qu'il faut écrire et où ; Guidance, ce qu'il faut peser pendant que vous écrivez.
- Puis il s'arrête et attend. Vous écrivez ces quelques lignes à la place du repère et vous lui dites que vous avez fini.
- Il lit votre code, répond avec un encadré Insight sur ce que vous avez écrit et reprend la tâche.
En parallèle, avant ou après le code qu'il écrit, il ajoute des encadrés Insight : deux ou trois points sur le pourquoi de ses choix, liés à votre projet. Ils restent dans la conversation : ils ne finissent pas dans vos fichiers sous forme de commentaires.
Une chose à savoir tout de suite : un style est une instruction, pas une garantie. Claude décide lui-même quels morceaux vous laisser, et dans une tâche sans vrai choix, il peut ne rien vous laisser. Si vous voulez un morceau précis, demandez-le : c'est la section suivante.
3. Utilisez-le sur une vraie fonctionnalité
Ça rapporte plus sur une fonctionnalité dont vous avez vraiment besoin que sur un exercice. Les lignes à garder pour vous, ce sont les règles de votre app : ce sont celles que vous changerez quand l'idée changera, et les premières que vous regarderez quand quelque chose cloche. Écrivez-lui comme ça :
J'ajoute [la fonctionnalité, par exemple : 3 projets maximum pour la version gratuite]. Écris toi-même la partie de routine : fichiers, branchements, interface. Les règles de mon app, c'est-à-dire ce qui se passe dans chaque cas et comment gérer les erreurs, laisse-les-moi avec le repère (human), une à la fois. Pour chacune, dis-moi dans quel fichier elle est, ce que je reçois et ce que je dois renvoyer.
Quand vous avez écrit vos lignes :
J'ai fini le repère (human) dans [nom du fichier]. Lis mon code et dis-moi s'il y a un cas que je ne gère pas, sans le réécrire toi-même. Ensuite, continue.
4. Quand vous bloquez, demandez un indice
Il arrive de regarder le repère sans savoir par où commencer. Ne demandez pas tout de suite la solution : si vous la lisez toute faite, la prochaine fois vous en serez au même point. Demandez un indice :
Je bloque sur le repère (human) dans [nom du fichier]. N'écris pas le code. Donne-moi un seul indice : la première chose à vérifier ou la question que je dois me poser. Si je bloque encore après deux indices, montre-moi un exemple semblable, mais pas identique.
Si ce n'est vraiment pas le moment, vous pouvez toujours lui dire d'écrire ce morceau lui-même. Mais essayez d'abord les indices : c'est là que le code devient le vôtre.
5. Quand vous êtes pressé, revenez à Default
Learning vous ralentit, et c'est voulu. Ses réponses sont plus longues que dans Default par conception, donc vous consommez plus de tokens en sortie. Quand vous devez juste boucler quelque chose, revenez au style de base :
/output-style default
Default figure dans la liste avec les autres styles, vous le trouvez donc aussi dans /config et dans le menu de VS Code. Dans l'app de bureau, retirez la ligne outputStyle du fichier. Quand vous avez de nouveau du temps, remettez Learning.
6. Si vous voulez seulement les explications : Explanatory
Si vous n'avez pas envie d'écrire du code mais voulez comprendre ce qui se passe, il y a Explanatory. Il fait le travail comme Default et ajoute les mêmes encadrés Insight, avec le pourquoi de ses choix. Il ne vous laisse rien à écrire et ne s'arrête pas pour vous attendre.
Il s'active de la même façon : /output-style explanatory dans le terminal, ou Explanatory dans le fichier, avec un E majuscule. Là aussi, les réponses sont plus longues que dans Default, donc plus de tokens. Explanatory convient quand vous découvrez du code que vous ne connaissez pas ; Learning, quand vous écrivez une fonctionnalité que vous devrez maintenir vous-même.
Les erreurs les plus courantes
- Écrire learning en minuscules dans le fichier. Le fichier attend Learning : avec un mauvais nom, vous restez dans Default et rien ne vous le signale.
- S'attendre à un repère (human) dans chaque réponse. Claude décide quels morceaux vous laisser : si vous en voulez un, demandez-le.
- Le laisser activé quand vous êtes pressé. Les réponses longues consomment plus de tokens : revenez à Default et réactivez-le plus tard.
- Mettre Learning dans ~/.claude/settings.json et ne pas comprendre pourquoi il ne s'active pas dans un projet. Les réglages du projet l'emportent : vérifiez s'il y a un autre outputStyle dans ce projet.
- Créer .claude/settings.local.json à la main et finir par le committer dans git. Quand Claude Code le crée, il le garde hors de git tout seul ; si vous le créez vous-même, ajoutez-le au .gitignore.
Check-list
- Learning est activé dans le projet sur lequel je travaille
- Si je l'ai mis dans le fichier, c'est écrit Learning avec un L majuscule
- Je lui ai demandé de me laisser les règles de mon app avec le repère (human)
- J'ai écrit mes lignes et je lui ai dit que j'avais fini
- J'ai lu l'Insight sur mon code
- Je sais comment revenir à Default quand je suis pressé
Questions fréquentes
Avec Learning, est-ce que je mets plus de temps à finir l'app ?
Un peu, oui : de temps en temps vous vous arrêtez pour écrire, et les réponses sont plus longues. Mais le travail de routine, c'est toujours lui qui le fait, et vous écrivez quelques lignes là où il y a un vrai choix. Quand vous êtes pressé, vous revenez à Default avec une commande.
Le style s'applique-t-il aussi aux sous-agents ?
Non. Les sous-agents sont les assistants séparés que Claude lance pour une tâche précise. Le style s'applique à la conversation principale et à un fork, qui hérite de toute la conversation. Les autres sous-agents ont leurs propres instructions, donc le style ne change pas leur façon de répondre.
Puis-je créer un style avec mes propres règles ?
Oui. Un style à vous est un fichier Markdown dans le dossier .claude/output-styles du projet, ou dans ~/.claude/output-styles pour tous vos projets. En haut, mettez name et description, et keep-coding-instructions: true si vous voulez que Claude continue à coder comme d'habitude ; en dessous, vos instructions. Dans le terminal, si vous créez ou modifiez le fichier pendant une session, redémarrez Claude Code.