"7 conseils Claude Code + Opus 4.7 de Boris Cherny"

"## 7 conseils Claude Code + Opus 4.7 de Boris Cherny\n\nJ'étais en plein milieu d'un clone de Linear quand la nouvelle vidéo de sept conseils de Boris Cherny est apparue dans mon fil d'actualité, et j'ai failli l'ignorer.\n\nMon excuse semblait raisonnable. J'utilise Claude Code au quotidien depuis plus d'un an. J'ai publié plus de quatre-vingts articles à ce sujet sur ce blog. J'ai testé chaque niveau d'effort, chaque changement de modèle, chaque plugin qui a traversé mon terminal. Qu'est-ce que le créateur de Claude Code pouvait bien m'apprendre que je n'avais pas déjà découvert par moi-même ?\n\nPuis il a dit une phrase qui m'a stoppé net : « Sur Opus 4.7, je ne touche plus au toggle d'extended thinking. Il a disparu. » J'ai mis la vidéo sur pause, ouvert ma console API, et j'ai vérifié. Il avait raison. Le paramètre thinking: {type: \"enabled\", budget_tokens: N} que je peaufinais depuis des mois renvoie désormais une erreur 400 sur Opus 4.7. Anthropic l'a discrètement supprimé. L'adaptive thinking est désormais le seul mode de réflexion activé, et on le pilote par la formulation des prompts — pas par un toggle.\n\nC'était une seule phrase. La vidéo en contenait sept conseils. Si je me trompais déjà sur l'un d'eux, je devais clairement donner une chance équitable aux six autres.\n\nJ'ai donc passé les quatre jours suivants à reconstruire mon clone de Linear de zéro, en appliquant chacune des techniques de Boris sur de vrais projets — pas des prompts jouets, pas des scripts de démo. Des projets, des tâches, des statuts, des priorités, des assignataires, une UI Next.js. Le même spec qu'il avait démontré. Et j'ai suivi ce qui changeait, ce qui ne changeait pas, et quels conseils je garde définitivement par rapport à ceux que je vais discrètement abandonner.\n\nVoici ce que j'ai appris. Les sept conseils. Les erreurs que je commettais. Et la formulation exacte qui fait que Opus 4.7 se comporte correctement.\n\n## Petite note sur la source : c'est bien Boris Cherny\n\nAvant d'aller plus loin — les transcriptions de cette conférence qui circulent l'appellent « Churnney », « Cherny » et quelques orthographes intermédiaires. La personne qui a créé Claude Code s'appelle Boris Cherny, ancien ingénieur chez Meta, aujourd'hui Head of Claude Code chez Anthropic. Il a rejoint Anthropic en 2024, a livré Claude Code comme projet annexe durant son premier mois, et le produit a dépassé 1 milliard de dollars de revenus annualisés début 2026. Quand il parle de la façon d'utiliser cet outil, ça vaut la peine de ralentir pour l'écouter, car c'est aussi lui qui décide de ce qui sera livré ensuite.\n\nUne autre correction de source pendant qu'on y est : le deuxième outil qu'il compare à Claude Code dans la conférence est OpenCode — pas « OpenClaw », comme je l'avais entendu la première fois dans la transcription. OpenCode est l'agent terminal open source qui s'interface avec plus de 75 fournisseurs de LLM. Retenez bien ce nom ; on y reviendra.\n\nMaintenant — les sept conseils, retestés.\n\n## Conseil 1 : Auto Mode est le nouveau défaut. Arrêtez de lutter contre le cycle de permissions.\n\nJe l'admets — j'ai été un adepte du « plan mode → acceptEdits → approuver manuellement » pendant la majeure partie de 2025. L'idée de laisser Claude Code exécuter des commandes bash sans surveiller chacune d'elles me semblait imprudente. Comme remettre les clés du serveur de production à quelqu'un avec le moteur en marche.\n\nAuto mode a tué cette hésitation.\n\nVoici la mécanique concrète. Claude Code dispose de quatre modes de permission que l'on fait défiler avec Shift+Tab : default → acceptEdits → plan → auto. Le slot auto mode n'apparaît dans le cycle que si votre compte est éligible et que vous l'avez activé. Sur un plan Max ou Team, claude --enable-auto-mode l'active, et ensuite un troisième appui sur Shift+Tab vous amène en auto.\n\nCe qui différencie auto mode de acceptEdits, ce n'est pas l'interface — c'est le classifieur. Avant chaque appel d'outil, un modèle de sécurité distinct basé sur Sonnet 4.6 examine l'action. Si elle ressemble à une suppression massive de fichiers, à une exfiltration de données ou à une escalade pilotée par injection de prompt, elle est bloquée. Tout le reste s'exécute. Anthropic a lancé ce mode le 24 mars 2026, spécifiquement pour gérer la fatigue des permissions que la plupart des utilisateurs avancés contournaient avec des listes d'autorisation personnalisées.\n\nQuand j'ai retesté le clone de Linear de Boris en auto mode, la différence n'était pas dans la qualité du code — elle était dans mon attention. Je ne regardais plus le terminal. J'étais dans l'application Claude desktop en train de rédiger les textes de l'UI pour la page des tâches pendant que Claude Code câblait le schéma Prisma, exécutait les migrations, peuplait les données de test et démarrait le serveur de développement. Vingt-trois appels d'outils se sont produits sans une seule demande de permission. Aucun d'eux n'avait besoin de moi.\n\nUn point sur lequel je m'écarterais de la formulation de Boris : auto mode n'est pas le bon défaut pour chaque projet. Si je touche au dépôt de production d'un client, ou à quoi que ce soit où un rm -rf accidentel coûterait de l'argent, je reste en acceptEdits. Le classifieur est bon, mais « bon » à cette échelle signifie encore des erreurs occasionnelles. Pour les nouvelles constructions, pour mes propres projets personnels, pour tout ce où un git reset est peu coûteux — auto mode est là où je vis désormais.\n\nSi vous avez alterné entre default et plan avec Shift+Tab pendant les six derniers mois, c'est l'habitude à briser. Une pression de plus et vous êtes dans un mode conçu pour le flow.\n\n## Conseil 2 : Fournissez le spec complet dès le départ. Opus 4.7 vous en récompense.\n\nC'est le conseil qui a le plus amélioré la qualité de mes résultats, et celui contre lequel j'ai le plus résisté.\n\nMon habitude — et probablement la vôtre — était de prompter de façon incrémentale. Construire le schéma de base de données. Puis les routes API. Puis l'UI. Puis tout assembler. À chaque étape, je vérifiait la sortie, j'ajustais, et je donnais l'instruction suivante. Ça ressemblait à du contrôle. Ça semblait responsable.\n\nCe n'était ni l'un ni l'autre. C'était une habitude héritée des modèles de l'ère GPT-4 qui ne pouvaient pas garder un grand spec en tête.\n\nLa démo de Boris était un désaveu direct. Il a ouvert Claude Code et a donné à Opus 4.7 ceci, en gros, comme un seul prompt :\n\n> Construis un clone de Linear. Les projets contiennent des tâches. Chaque tâche a un statut (todo, in-progress, done), une priorité (low, medium, high, urgent), un assignataire (depuis une table users), et le support des tags. Utilise Next.js App Router, Prisma avec SQLite pour le développement local, Tailwind pour le style, et les composants shadcn/ui. L'UI doit avoir une barre latérale de projet, une vue tableau des tâches, et une modale de détail de tâche. Ne me pose pas de questions — fais des choix sensés et livre.\n\nSix minutes plus tard, il avait un clone de Linear fonctionnel. Pas un squelette. Une application fonctionnelle, tournant sur localhost, avec des données de test, un tableau Kanban opérationnel, et une modale de détail de tâche qui s'ouvrait proprement.\n\nQuand j'ai essayé lors de mon retest, j'étais sceptique. Mon premier essai a pris environ sept minutes et demie. Mon deuxième essai, avec un spec plus précis, a pris moins de six minutes. Les deux fois, le résultat était genuinement utilisable. Pas parfait — j'ai dû corriger un chemin d'import shadcn et une classe Tailwind qui référençait un jeton de couleur indéfini — mais à 85-90% du niveau prêt pour la production dès le premier coup.\n\nLa leçon que Boris cherche à transmettre ici est subtile. La fenêtre de contexte d'Opus 4.7, couplée à son adaptive thinking, lui permet de garder en tête l'architecture entière pendant qu'il construit chaque pièce individuelle. Quand vous promptez de façon incrémentale, vous lui cachez des informations. Vous le forcez à reconstruire le contexte à chaque message. Pire, vous signalez que les pièces sont indépendantes — ce qui l'amène à les construire comme si c'était le cas, et la phase d'intégration devient son propre cauchemar.\n\nFrontloader signifie : écrire le spec complet avant d'appuyer sur entrée. Inclure le framework UI. Inclure le modèle de données. Inclure ce qu'il ne devrait pas faire. Inclure la direction esthétique. Chaque élément de contexte que vous fournissez en amont est un élément que Claude n'a pas à deviner.\n\nMa règle pratique maintenant : si mon premier prompt fait moins de 150 mots, c'est que je n'ai pas suffisamment réfléchi à ce que je demande.\n\n## Conseil 3 : Claude Code vs OpenCode — Choisissez le bon outil pour la tâche\n\nC'est le conseil où Boris est étonnamment honnête pour quelqu'un dont le travail consiste à vendre Claude Code.\n\nIl ne dit pas « utilisez Claude Code pour tout ». Il trace une ligne. Claude Code, dans sa formulation, est pour un travail profond, complexe et de qualité production — le type de construction où vous tenez à ce que le résultat soit de niveau production, où les décisions architecturales comptent, où vous voudriez qu'un ingénieur senior ait pris les décisions. OpenCode est pour les prototypes rapides et les outils d'agents légers où la vitesse d'itération importe plus que la qualité du résultat.\n\nJ'utilise les deux depuis quelques mois, et sa formulation se vérifie.\n\nOpenCode — l'agent terminal open source, pas Codex, pas le truc d'OpenAI — a un vrai avantage pour le prototypage. Il s'interface avec plus de 75 fournisseurs de LLM, donc je peux lancer un agent jetable sur un modèle bon marché pour une itération rapide et payer au token plutôt que de m'engager dans un abonnement. Quand je construis un outil CLI à usage unique que j'utiliserai une semaine puis que je jetterai, OpenCode arrive plus vite à un état fonctionnel parce que je ne me soucie pas de la qualité du code de quelque chose que je ne maintiendrai jamais.\n\nClaude Code est le compromis inverse. Il est exigeant sur la qualité. Il est optimisé pour les modèles d'Anthropic, ce qui signifie qu'il obtient le meilleur résultat d'Opus 4.7 par défaut. Il dispose de l'écosystème de plugins plus riche, du système de hooks mature, du framework de skills sur lequel je m'appuie quotidiennement. Quand je construis quelque chose que je maintiendrai pendant six mois, cette exigence est une fonctionnalité.\n\nLe conseil dans le conseil : arrêtez d'essayer de trouver l'Agent Universel. Vous en voulez deux. Un pour « j'ai besoin que ça fonctionne avant ce soir et je m'en fiche si le code est moche ». Un pour « je déboguerai cette application à 2h du matin dans six mois, et les choix architecturaux que je fais aujourd'hui me hanteront ». Associez l'outil à la tâche.\n\n## Conseil 4 : /recap — La commande dont vous ignoriez avoir besoin\n\nCelui-là, je l'avais genuinement manqué. D'une façon ou d'une autre. Il est disponible depuis avril 2026, il est dans la documentation, et je ne l'avais jamais tapé une seule fois.\n\n/recap est une slash command qui imprime un résumé ligne par ligne de tout ce qui s'est passé dans votre session Claude Code courante. Quels fichiers ont été touchés. Quelles commandes ont été exécutées. Quels tests ont réussi ou échoué. C'est configurable dans /config, et il y a une variable d'environnement CLAUDE_CODE_ENABLE_AWAY_SUMMARY qui contrôle si elle se déclenche automatiquement quand vous revenez à une session en attente.\n\nLa raison pour laquelle c'est important n'est pas la fonctionnalité elle-même — c'est le flux de travail qu'elle débloque.\n\nJ'ai une habitude que je soupçonne beaucoup d'entre vous de partager. Je lance une longue session Claude Code, je m'éloigne, je reviens quarante minutes plus tard avec un café froid, et je dois passer trois ou quatre minutes à lire le défilement pour comprendre où on en était. Qu'est-ce que Claude avait terminé ? Qu'est-ce qui était encore cassé ? Cette migration avait-elle vraiment été exécutée ? Quel fichier de test était celui qui échouait ?\n\n/recap répond à tout ça en environ deux secondes. Une ligne par action. Je le parcours, je sais où on en est, je formule la prochaine action.\n\nL'autre endroit où ça m'a sauvé cette semaine : je jonglais avec trois sessions Claude Code en parallèle (une habitude que Boris lui-même pratique avec 5 à 10 instances en parallèle un jour normal). Passer d'une session à l'autre tuait mon flow. /recap dans chaque fenêtre est devenu mon équivalent de me lever pour regarder un tableau blanc pour me réorienter. Moins de dix secondes pour savoir ce qu'une session avait accompli.\n\nSi vous ne l'avez pas encore tapé, essayez-le la prochaine fois que vous revenez à une session en cours. La première fois, vous aurez l'impression de découvrir une fonctionnalité qui n'aurait pas dû exister.\n\n## Conseil 5 : Niveaux d'effort — Extra High et Max sont réels, et ce sont des outils différents\n\nC'est là que je dois corriger une erreur que je m'étais faite dans la tête avant ce retest.\n\nJ'avais supposé que « max effort » et « extra high effort » étaient des distinctions marketing. Ce n'est pas le cas. Ce sont genuinement des modes différents avec des compromis différents, et la formulation de Boris m'a éclairé.\n\nClaude Code dispose de cinq niveaux d'effort : low, medium, high, xhigh (extra high), et max. Sur Opus 4.7, le défaut est xhigh pour tous les plans et fournisseurs — bien qu'Anthropic ait discrètement abaissé le défaut de high à medium sur les abonnements Pro et Max en mars 2026, ce qui vaut la peine de savoir si vos résultats ont semblé un peu moins riches ce printemps qu'avant.\n\nLa différence entre xhigh et max est importante. xhigh persiste entre les sessions. C'est le niveau que vous pouvez définir de façon permanente et oublier. max ne persiste pas — c'est un mode uniquement pour la session courante, sauf si vous le fixez avec la variable d'environnement CLAUDE_CODE_EFFORT_LEVEL. Max supprime toutes les contraintes de tokens sur la réflexion. Il n'y a pas de plafond. Claude dépensera autant que la tâche semble en nécessiter.\n\nLa règle de Boris, qui correspond presque exactement à mon retest :\n\n- Low / Medium : travail trivial. Modifications d'un seul fichier. Petits refactorings. Plans dont vous êtes confiant qu'ils sont corrects.\n- High : travail de fonctionnalité standard où vous voulez un raisonnement solide sans exploser le budget.\n- Extra High (xhigh) : travail de fonctionnalité où l'architecture est importante, ou où le premier instinct de Claude est souvent subtilement erroné.\n- Max : prompts larges et frontloadés. Mon clone de Linear. Migrations complètes de système. Le type de tâche où vous remettez à Opus 4.7 un spec en attendant un résultat quasi-complet.\n\nPour le retest du clone de Linear, j'ai effectué trois versions. Une à high, une à xhigh, une à max. High a produit une application fonctionnelle avec trois bugs évidents. Xhigh a produit une application fonctionnelle avec un problème cosmétique. Max a produit une application fonctionnelle sans aucun problème au premier essai, mais a pris environ 40% plus de temps et a dépensé environ 3x les tokens.\n\nLa courbe des coûts est réelle. N'utilisez pas max pour tout. Mais n'ayez pas peur de l'utiliser pour les tâches qui le justifient — un prompt de construction frontloadé est exactement ce type de tâche.\n\nSi vous préférez que quelqu'un réalise ce type de construction architecture-first pour vous — que ce soit un outil interne de style Linear, un prototype SaaS, ou un produit intégrant l'AI — je prends des commandes personnalisées via fiverr.com/s/EgxYmWD. Mais vous pouvez absolument y arriver vous-même avec le flux de travail de cet article.\n\n## Conseil 6 : Notifications — Arrêtez de surveiller le terminal\n\nCe conseil est d'une simplicité déconcertante et a amélioré mon flux de travail plus qu'il n'aurait dû.\n\nBoris configure des notifications de fin de tâche pour pouvoir laisser de longues tâches Claude Code tourner sans regarder le terminal. Ensuite il travaille sur autre chose — brainstorming dans l'application Claude desktop, rédaction de specs, pause café — jusqu'à ce que son Mac lui signale que Claude a soit terminé soit besoin d'une intervention.\n\nLe mécanisme est un Stop hook dans le système de hooks de Claude Code. Les Stop hooks se déclenchent quand Claude termine sa tâche courante. Vous pouvez y attacher n'importe quelle commande shell — y compris osascript pour déclencher une notification macOS, un webhook Slack, ou un appel à terminal-notifier. Il y a aussi un Notification hook qui se déclenche sur les demandes de permission, les invites d'inactivité ou les dialogues d'élicitation, ce qui est utile si vous êtes dans un mode qui demande encore des approbations.\n\nVoici le snippet minimal de ~/.claude/settings.json que j'utilise :\n\njson\n{\n \"hooks\": {\n \"Stop\": [\n {\n \"matcher\": \"\",\n \"hooks\": [\n {\n \"type\": \"command\",\n \"command\": \"osascript -e 'display notification \\\"Claude finished\\\" with title \\\"Claude Code\\\" sound name \\\"Glass\\\"'\"\n }\n ]\n }\n ],\n \"Notification\": [\n {\n \"matcher\": \"permission_prompt\",\n \"hooks\": [\n {\n \"type\": \"command\",\n \"command\": \"osascript -e 'display notification \\\"Needs your input\\\" with title \\\"Claude Code\\\" sound name \\\"Ping\\\"'\"\n }\n ]\n }\n ]\n }\n}\n\n\nDeux sons différents. Deux états différents. Je sais lequel est lequel sans regarder l'écran.\n\nLes hooks asynchrones qu'Anthropic a livrés en janvier 2026 sont également importants ici — ils permettent aux commandes de notification de s'exécuter en arrière-plan sans bloquer l'exécution de Claude, ce qui signifie pas de pause bizarre quand une notification se déclenche en plein milieu d'une tâche.\n\nLe méta-point que Boris soulève avec ce conseil ne concerne pas la notification elle-même. Il s'agit du changement de modèle mental. Si vous regardez Claude Code travailler en temps réel, vous êtes le goulot d'étranglement. Vous ne faites pas autre chose. Vous ne pensez pas à l'avance. Vous êtes spectateur de votre propre travail. Les notifications vous permettent de passer de spectateur à chef d'orchestre — et un chef d'orchestre qui fait tourner deux ou trois sessions Claude en parallèle est genuinement un développeur d'un autre type que celui qui pioche dans un seul terminal en temps réel.\n\n### Le multiplicateur de flux : brainstormez dans l'application Claude desktop pendant que Claude Code tourne\n\nBoris mentionne ceci comme une remarque en passant dans la vidéo, mais c'est l'un des éléments à plus fort levier de toute la présentation.\n\nPendant que Claude Code exécute une longue tâche, il ouvre l'application Claude desktop — un produit totalement séparé, pas Claude Code — et l'utilise comme surface de brainstorming. Pas d'appels d'outils. Pas d'éditions de fichiers. Juste un contexte de chat où il réfléchit à la prochaine fonctionnalité, rédige le langage du spec, vérifie les choix architecturaux.\n\nQuand son Mac lui signale que Claude Code a terminé, il a un prompt suivant entièrement formé prêt à lancer. Pas de temps mort « laissez-moi réfléchir à ce que je vais demander ensuite ».\n\nJ'ai copié ce schéma pour le retest. Mon clone de Linear avait trois pauses naturelles. Dans chacune, au lieu de regarder le terminal, j'ai ouvert l'application desktop et rédigé le prochain spec. Le temps total de construction est passé de ce qui aurait été un projet d'une demi-journée à environ une heure quarante de travail réel.\n\n## Conseil 7 : Adaptive Thinking — Le toggle est mort. Vive le prompt.\n\nC'est celui sur lequel je me suis trompé. Laissez-moi expliquer ce qui a réellement changé.\n\nSur Opus 4.6 et les versions antérieures, vous contrôliez l'extended thinking avec un paramètre explicite : thinking: {\"type\": \"enabled\", \"budget_tokens\": N}. Vous définissiez un budget de tokens. Claude réfléchissait jusqu'à ce budget. Simple.\n\nSur Opus 4.7, ce paramètre renvoie une erreur 400. Les budgets d'extended thinking ont disparu. Remplacés par l'adaptive thinking — un mode où Claude décide lui-même quand réfléchir plus intensément et combien dépenser, en fonction de la complexité de chaque requête.\n\nL'adaptive thinking est désactivé par défaut sur Opus 4.7. Vous l'activez avec thinking: {type: \"adaptive\"} dans l'API, ou — et c'est la clé pour les utilisateurs de Claude Code — vous le pilotez par la formulation du prompt.\n\nDeux phrases qui font vraiment bouger les choses :\n\n- « Think carefully step by step » — signale à Claude que c'est une tâche qui mérite de brûler des tokens de réflexion. Il dépensera plus en raisonnement à chaque étape.\n- « Prioritize responding quickly » — signale le contraire. Claude raccourcit son raisonnement et livre plus vite, au détriment d'une certaine profondeur.\n\nVoici la nuance qui m'a pris une journée à pleinement intérioriser : l'effort et la réflexion sont désormais des curseurs séparés. Le niveau d'effort est le budget total de ressources pour une tâche — combien de travail Claude est prêt à investir globalement, entre les appels d'outils, les lectures de fichiers et les nouvelles tentatives. La réflexion est la profondeur de raisonnement par étape — combien Claude réfléchit intensément avant de prendre chaque décision individuelle.\n\nVous pouvez avoir un effort élevé avec une réflexion faible (beaucoup d'actions, chacune décidée rapidement) ou un effort faible avec une réflexion élevée (peu d'actions, chacune soigneusement considérée). Pour mon retest du clone de Linear, max effort + la formulation « think carefully step by step » a produit le résultat le plus propre. Pour un correctif rapide dans une route API, xhigh effort + « prioritize responding quickly » a terminé en environ un tiers du temps sans sacrifier la correction.\n\nL'autre changement à connaître : à partir d'Opus 4.7, le contenu de réflexion est omis de la réponse par défaut. Les blocs de réflexion apparaissent toujours dans le flux de réponse, mais leur contenu est vide sauf si vous optez explicitement pour les inclure. C'est un changement silencieux — pas d'erreur, pas d'avertissement — et il améliore légèrement la latence des réponses. Si vous aviez des outils qui analysaient la sortie de réflexion, vérifiez s'ils fonctionnent encore.\n\n## Ce que je garde, ce que j'abandonne\n\nQuatre jours de retests. Voici mon bilan honnête.\n\nJe garde définitivement :\n- Auto mode pour les nouvelles constructions et les projets personnels. Le classifieur est suffisamment bon. Le flow en vaut la peine.\n- Les specs frontloadés pour toute construction qui n'est pas une modification triviale d'un seul fichier. C'est là que la plus grande amélioration de qualité s'est produite.\n- /recap comme réflexe à chaque reprise de session. Un gain sans coût.\n- Notifications via Stop hooks, toujours. Je suis gêné de ne pas avoir configuré ça il y a un an.\n- L'adaptive thinking par formulation de prompt parce que je n'ai pas le choix — le toggle a disparu.\n\nJe garde avec des réserves :\n- Max effort level, mais uniquement pour les bonnes tâches. Ce n'est pas un réglage « plus c'est mieux ». Utilisez-le quand la tâche le justifie.\n- La distinction Claude Code vs OpenCode — je suis d'accord avec le partage, mais je continue à utiliser Claude Code en premier la plupart des jours, parce que l'écosystème s'accumule.\n\nJ'abandonne :\n- Rien, honnêtement. Chaque conseil a tenu la route sur du vrai travail. C'est pourquoi je publie cet article plutôt que le pamphlet « voilà où Boris a tort » que je m'attendais à moitié à écrire quand j'ai commencé le retest.\n\nSi vous avez lu mon précédent article de fond sur le flux de travail quotidien de Boris Cherny ou mon analyse de l'impact pratique d'Opus 4.7, vous remarquerez que ces sept conseils recoupent les principes que Boris partage publiquement depuis des mois. Ce qui est nouveau, c'est le comportement spécifique d'Opus 4.7 — adaptive thinking, suppression du toggle d'extended thinking, max effort comme niveau réel — et la façon dont auto mode est passé d'un flag expérimental à quelque chose que je recommande désormais comme défaut pour les nouvelles constructions.\n\n## Le test du clone de Linear — Ce qui a vraiment été livré\n\nRevenons à la construction avec laquelle j'ai commencé.\n\nQuatre jours, trois retests, sept techniques appliquées proprement. Le clone de Linear avec lequel je me suis retrouvé possède des projets avec des tâches imbriquées, un tableau Kanban glisser-déposer, des champs de statut et de priorité, des assignataires tirés d'une base de données de test, le support des tags, une barre latérale de projet, et une modale de détail de tâche — exactement le spec que Boris a démontré. Next.js App Router, Prisma avec SQLite, Tailwind, composants shadcn/ui.\n\nTemps de modification humaine total : environ quarante minutes, réparties sur les trois constructions. Temps Claude Code total : environ trois heures et demie sur les trois exécutions. Tokens totaux sur la meilleure exécution : environ 450K en entrée et 180K en sortie. La meilleure exécution était celle avec max effort, spec frontloadé, auto mode, formulation de prompt tenant compte de l'adaptive thinking, et notifications via Stop hooks.\n\nChacun des sept conseils de Boris a contribué quelque chose. Supprimez-en un seul et la construction se dégrade, ralentit ou est plus interrompue.\n\n## Questions fréquemment posées\n\n### /recap est-elle une vraie commande Claude Code ?\nOui. /recap a été livré dans Claude Code en avril 2026 et imprime un résumé ligne par ligne des actions de votre session courante. C'est configurable via /config, et vous pouvez forcer l'activation du déclenchement automatique avec la variable d'environnement CLAUDE_CODE_ENABLE_AWAY_SUMMARY. Voir le détail complet des niveaux d'effort et des sessions ci-dessus.\n\n### Quelle est la différence entre les niveaux d'effort « high » et « max » de Claude Code ?\nHigh plafonne la profondeur de réflexion et des appels d'outils à un niveau raisonnable ; max supprime entièrement le plafond et s'applique uniquement à la session courante (sauf si vous le fixez avec CLAUDE_CODE_EFFORT_LEVEL). Utilisez max pour les constructions frontloadées et architecturalement complexes. Utilisez high pour le travail de fonctionnalité standard. Le cadre de décision complet est dans le Conseil 5.\n\n### Comment activer auto mode dans Claude Code ?\nExécutez claude --enable-auto-mode pour le débloquer pour votre compte, puis appuyez trois fois sur Shift+Tab pour faire défiler default → acceptEdits → plan → auto. Auto mode nécessite un plan Team, Enterprise ou API et utilise un classifieur basé sur Sonnet 4.6 pour bloquer les appels d'outils risqués avant leur exécution.\n\n### Anthropic a-t-il vraiment supprimé l'extended thinking dans Opus 4.7 ?\nOui. Définir thinking: {\"type\": \"enabled\", \"budget_tokens\": N} sur Opus 4.7 renvoie une erreur 400. L'adaptive thinking (thinking: {type: \"adaptive\"}) est désormais le seul mode de réflexion activé, et Claude décide de la profondeur de réflexion de façon dynamique. Vous le pilotez avec des formulations comme « think carefully step by step » ou « prioritize responding quickly ». Détails dans le Conseil 7.\n\n### Devrais-je utiliser Claude Code ou OpenCode ?\nLes deux. Utilisez Claude Code pour les constructions profondes et de qualité production où l'architecture et la qualité du code comptent. Utilisez OpenCode pour les prototypes rapides, les outils jetables, ou quand vous devez vous interfacer avec des modèles non-Anthropic. La formulation de Boris dans le Conseil 3 correspond à ma propre expérience avec les deux outils.\n\n## Pour conclure\n\nLa raison pour laquelle les sept conseils de Boris fonctionnent n'est pas qu'ils sont ingénieux. La plupart d'entre eux, individuellement, sont petits. /recap est une seule slash command. Un Stop hook, c'est dix lignes de JSON. Auto mode, c'est un seul flag.\n\nLa raison pour laquelle ils fonctionnent, c'est qu'ensemble, ils vous font passer du rôle de la personne qui tape dans Claude Code à celui de la personne qui le dirige — et qui en dirige deux ou trois instances à la fois, pendant qu'elle réfléchit au problème suivant. Chaque conseil de la liste supprime soit une tâche de surveillance, soit élève la qualité du résultat, soit vous aide à spécifier la bonne chose avant d'appuyer sur entrée.\n\nJ'ai passé quatre jours à reconstruire le même clone de Linear de trois façons différentes, et le conseil auquel je reviens sans cesse n'est aucun des sept. C'est le méta-conseil sous-jacent à tous : les développeurs qui gagnent avec Claude Code en ce moment ne sont pas ceux qui ont appris plus de prompts. Ce sont ceux qui ont arrêté d'agir comme s'ils étaient en conversation avec une AI et ont commencé à agir comme s'ils dirigeaient une petite équipe d'ingénierie d'un seul homme.\n\nShift+Tab trois fois. Frontloadez le spec. Laissez-le tourner. Allez rédiger le prochain prompt dans l'application desktop pendant que les notifications gèrent les mises à jour.\n\nC'est tout le jeu.\n\n## Travaillons ensemble\n\nVous cherchez à construire des systèmes AI, automatiser des flux de travail ou faire évoluer votre infrastructure technologique ? Je serais ravi de vous aider.\n\n* Fiverr (constructions et intégrations personnalisées) : fiverr.com/s/EgxYmWD\n* Portfolio : mejba.me\n* Ramlit Limited (solutions entreprise) : ramlit.com\n* ColorPark (design & branding) : colorpark.io\n* xCyberSecurity (services de sécurité) : xcybersecurity.io"