Guide Claude AI : astuces et bonnes pratiques

Projects dans Claude Code a été reconstruit. Jusqu'ici, un projet était un dossier contenant des conversations et de la matière de référence ; les nouveaux Projects sont une conversation unique. Vous écrivez ce dont vous avez besoin, Claude découpe la demande en threads, les threads tournent en parallèle dans le cloud, et chacun ouvre une pull request et rend compte une fois terminé. Fermer votre ordinateur portable ne les arrête pas. Trois points méritent toutefois d'être vérifiés avant de se lancer : les comptes qui peuvent s'en servir restent limités (bêta publique Pro et Max, servie d'abord aux comptes sans projets existants), github.com et la Claude GitHub App sont en pratique indispensables, et la vitesse à laquelle la fonctionnalité dévore votre limite d'usage n'a rien à voir avec celle d'une session unique. Cet article explique comment savoir si le déploiement vous est parvenu, ce qu'un thread possède au démarrage, y compris le piège qui fait cesser d'appliquer les règles de permission et les hooks dès qu'un projet contient plus d'un dépôt, d'où vient le coût en tokens, réglage Opus en high par défaut compris, et comment choisir entre les cinq façons de travailler en parallèle : sous-agents, agent view, équipes d'agents, workflows dynamiques et Projects, le tout à partir de la documentation et du blog officiels.

Vous voulez confier uniquement la planification à un modèle intelligent, et l'implémentation à un modèle plus rapide et moins cher. Le réglage opusplan de Claude Code fait cela automatiquement. Il tourne sur Opus pendant le mode planification et sur Sonnet le reste du temps, et s'utilise avec /model opusplan ou avec le champ model de settings.json. En revanche, il n'apparaît pas dans la liste de /model, et comme le modèle change chaque fois que vous entrez en mode planification ou en sortez, chaque bascule relit toute la conversation sans le cache. En s'appuyant sur la documentation officielle, le CHANGELOG et les issues GitHub au 15 septembre 2026, cet article présente la configuration (y compris le choix des versions et le contexte de 1M), le passage du mode planification à l'implémentation après approbation, son retrait de l'écran de sélection dans la v2.0.0 et l'explication d'un membre de l'équipe d'Anthropic, une estimation du coût de cache qu'entraîne une bascule et les moyens de le limiter, les différences avec l'outil advisor et les sous-agents, ainsi que les usages qui s'y prêtent et ceux qui ne s'y prêtent pas.

Peut-on garder la session principale de Claude Code sur Opus 5 et ne confier que des tâches comme la traduction ou les vérifications en grand nombre à des sous-agents Sonnet ou Haiku ? Oui. Le modèle d'un sous-agent est choisi dans cet ordre : le modèle indiqué à l'appel, le champ model du fichier de définition, la variable d'environnement CLAUDE_CODE_SUBAGENT_MODEL, puis le modèle de la session principale, et l'effort peut lui aussi être réglé pour chaque sous-agent. En s'appuyant sur la documentation officielle au 15 septembre 2026, cet article fait le point sur les différences de cet ordre selon la version, sur CLAUDE_CODE_SUBAGENT_MODEL_FORCE pour aligner tous les sous-agents sur un seul modèle, sur la cible des alias qui change selon le fournisseur, et sur le fait que, depuis la v2.1.198, l'Explore intégré reprend le modèle de la session principale. Il présente ensuite ce que j'ai constaté en lançant réellement des sous-agents sur d'autres modèles et en vérifiant les journaux de conversation : ils ont tourné sur les modèles indiqués, chacun a lu des dizaines de milliers de tokens rien que pour démarrer, le cache des sous-agents expire au bout de 5 minutes même avec un abonnement, et la même traduction confiée deux fois à Opus 5, Sonnet 5 et Haiku 4.5 a donné des différences de temps, de coût et de qualité. Enfin, il résume l'effet sur le coût et sur les limites d'utilisation, et les éléments pour décider quelles tâches confier à un modèle moins cher.

Lancez plusieurs sessions en parallèle et vous finissez par vous demander laquelle dévore votre limite hebdomadaire. Pourtant, le /usage de Claude Code n'affiche que les chiffres de la session en cours et la consommation de l'ensemble du forfait répartie par Skill, sous-agent, plugin et serveur MCP, et la part consommée par chaque session n'apparaît ni dans l'anneau de consommation de l'application desktop ni sur la page des paramètres de claude.ai (en septembre 2026). La réponse se trouve dans les journaux de conversation stockés sur votre machine (les fichiers JSONL de ~/.claude/projects), mais les additionner tels quels donne un résultat faux, car une même réponse s'écrit sur plusieurs lignes, une par bloc de contenu, et les enregistrements des sous-agents se trouvent dans des fichiers séparés. Mesuré sur ma propre machine, le total naïf atteignait environ deux fois la valeur correcte, et comme l'ampleur de l'erreur variait d'une session à l'autre, même le classement changeait. Cet article couvre ce que les écrans officiels montrent et ne montrent pas, la bonne façon de compter les journaux avec un script d'agrégation d'une cinquantaine de lignes, le résultat mesuré où une seule session a pris près d'un tiers de toute la consommation, les limites de ce que les chiffres peuvent vous dire, et la mise en place d'OpenTelemetry si vous voulez surveiller dans la durée.

Plus besoin de demander à chaque fois « commencez par la conclusion » ou « répondez en français » : il suffit de l'écrire une fois dans le champ d'instructions qui s'applique automatiquement à toutes les conversations. Ce champ s'appelle « Instructions personnalisées » dans ChatGPT, « Instructions pour Claude » dans Claude et « Instructions pour Gemini » dans Gemini, mais son nom à l'écran, son emplacement et le nombre de caractères qu'il accepte diffèrent. ChatGPT accepte 1 500 caractères avec Free et Go, et 5 000 avec Plus et au-delà (limite relevée en juillet 2026), tandis que Claude et Gemini ne publient pas de limite. Cet article vérifie l'emplacement et la limite de chacun dans l'aide officielle des trois entreprises, puis s'appuie sur le guide officiel de rédaction de prompts d'Anthropic pour montrer comment rédiger des instructions qui marchent, exemple à l'appui. Il réunit aussi dans une liste de vérification les situations où, d'après les aides officielles, les instructions ne s'appliquent pas : dans un projet, dans un Gem, dans une discussion temporaire ou avec un compte d'entreprise.

Vous écrivez en français, et Claude vous répond en anglais. Le dépôt officiel de Claude Code reçoit régulièrement le même signalement, et la recherche a montré que, lorsque la demande et la réponse passent d'une langue à l'autre, même les modèles les plus puissants ne parviennent pas à répondre de façon constante dans la langue demandée. Mais la cause n'est pas unique. On distingue quatre types : l'anglais qui s'installe peu à peu pendant que Claude lit du code et des sorties d'outils, le retour à l'anglais juste après la compaction qui résume la conversation, la réponse qui bascule dans une autre langue que celle demandée, et, depuis fin septembre 2026 avec Opus 5.5, « seuls les courts messages entre deux outils passent en anglais », chacun appelant une parade différente. Cet article explique comment reconnaître chaque type, pourquoi le paramètre language de Claude Code, qui inscrit la consigne dans le prompt système, continue de s'appliquer après la compaction, présente le hook signalé comme efficace contre le type 4, que ce paramètre n'arrête pas toujours, et la mesure faite dans les journaux de l'auteur, où la part des courts messages en anglais est passée d'environ 11 % à environ 50 %, puis fait le point sur le problème signalé depuis septembre 2026 des longues sessions où la sortie elle-même se dérègle, en séparant ce qui est confirmé de ce qui ne l'est pas.

« Trop de Skills installés et le contexte est saturé » : c'est à moitié vrai et à moitié faux. D'après la documentation officielle de Claude Code, la liste des Skills puise dans un budget fixe de 1 % de la fenêtre de contexte du modèle, et vous aurez beau ajouter des Skills, elle s'arrête là. Au lieu de gonfler, la liste se met à supprimer des descriptions, en commençant par les Skills les moins souvent invoqués, et ne garde que leur nom. Un Skill privé de sa description ne se raccroche plus à ce que vous demandez, et pourtant aucune erreur n'apparaît et rien ne ralentit. Cet article passe en revue les rôles distincts des trois outils de mesure (/context, /usage et /skill-doctor), la définition d'un défaut de cache à 5 % et 2 000 tokens, la façon dont la durée de vie du cache tombe d'une heure à cinq minutes selon la formule souscrite, la raison pour laquelle un CLI reste plus léger que MCP maintenant que les définitions d'outils sont chargées à la demande par défaut, le raisonnement derrière l'objectif de 200 lignes pour CLAUDE.md, et enfin par quoi couper en premier une fois la mesure faite — le tout limité à ce qui a pu être confirmé dans la documentation officielle.

Vous butez sur un mur en utilisant Claude, vous cherchez le message exact qui s'est affiché, et il ne revient presque rien. Cinq chaînes se comportent ainsi : The model returned no content because the response was blocked by content filtering, The response was blocked by the provider's content filter, Streaming response ended before any complete data was received, Could not locate the Claude CLI on PATH et Connection to Claude's response was lost. Claude may still be working. Ce qu'elles ont en commun, c'est qu'elles sont apparues pendant que vous utilisiez Claude et que chercher dans la documentation de Claude semble pourtant ne rien donner ; la raison est simple : le programme qui a écrit le message à l'écran n'est pas forcément celui que vous croyez. Cet article n'explique pas chaque cause depuis le début. C'est un hall d'entrée qui identifie qui a écrit le message et vous renvoie vers le bon article. Il commence par répartir les auteurs possibles en quatre couches : le backend qui sert le modèle, Claude Code lui-même, l'extension d'IDE ou le wrapper qui le lance, et les clients tiers ; puis il confronte les chaînes au catalogue. Deux des cinq se révèlent être des entrées de la référence des erreurs officielle de Claude Code. La définition officielle du message de streaming est que les en-têtes sont revenus mais que le corps ne portait aucun message de l'API Claude, ce qui n'est pas du tout une coupure à mi-chemin, et le lire comme une connexion perdue vous envoie sur la mauvaise piste. Could not locate the Claude CLI on PATH se trouve dans un chapitre distinct, Wrapper and IDE errors, décrit comme imprimé par le programme lanceur plutôt que par Claude Code, et l'affichage réel peut faire quatre phrases là où l'intitulé officiel n'en fait qu'une, d'où l'absence de résultats en recherche. Les deux messages de filtre de contenu, eux, relèvent du vocabulaire tiers, et le ticket #35736 d'OpenCode rapporte que trois échecs complètement distincts — un 404 Vertex, une coupure de socket et un vrai refus — remontent tous sous la même phrase blocked by content filter. La formulation n'est juste que pour un seul des trois : la croire et adoucir votre demande ne corrigera jamais un identifiant de modèle mal configuré. La documentation officielle de GitHub indique par ailleurs que les invites d'entrée et les complétions de sortie passent par les filtres de contenu de GitHub Copilot quand Claude est utilisé, si bien qu'utiliser Claude ne signifie pas que c'est un filtrage d'Anthropic qui vous a arrêté. La chaîne restante ne figure ni dans la référence des erreurs officielle ni dans la documentation de Remote Control : son origine n'a pas pu être identifiée, aucun outil n'est nommé pour elle, et quatre gestes pour la retrouver dans votre propre environnement sont donnés à la place. Ce qui est établi et ce qui ne l'est pas est signalé tout du long.

Dans Claude Code, la réponse s'arrête au milieu sur « API Error: Connection lost mid-response. The response above may be incomplete. » — et chercher ce libellé tel quel ne donne presque rien, parce que c'est un nom récent. La référence des erreurs officielle écrit noir sur blanc qu'avant la v2.1.227, Connection lost mid-response s'affichait sous la forme Connection closed mid-response ; au même moment, Response stalled mid-stream est devenu The response stopped arriving, et Connection closed while thinking, before producing a response est devenu Connection lost before a response was produced. Le phénomène existait donc déjà, seuls les mots ont changé. Cet article part de ce renommage et s'appuie uniquement sur la documentation officielle et sur des tickets publics. D'abord la définition officielle des six messages de coupure en cours de réponse (Server error, Connection lost, computer went to sleep, The response stopped arriving, Part of the response never arrived, The response stream was malformed), puis la raison pour laquelle la sortie déjà transmise est conservée à dessein — un renvoi risquerait d'exécuter deux fois le même appel d'outil — et le fait que la procédure de reprise consiste à répondre continue. Ensuite, pourquoi il n'y a pas de nouvelle tentative automatique, expliqué par l'arbre des Automatic retries officiels : une rupture avant tout achèvement est renvoyée jusqu'à dix fois avec recul exponentiel ; après la réflexion mais avant la sortie, deux renvois au maximum puis Connection lost before a response was produced ; après l'achèvement d'un bloc, aucun renvoi, seulement la mention. Viennent ensuite les trois couches où la connexion peut se rompre (le poste et sa liaison, le trajet avec proxy et passerelle, le côté serveur et la réutilisation des connexions), la relecture des fichiers lors d'une rotation de certificats mTLS (depuis la v2.1.232), une check-list de diagnostic en neuf gestes, les valeurs par défaut des quatre minuteurs de surveillance du flux (first-byte 180 s, event 300 s, byte 180 s, body idle 5 minutes) et les variables CLAUDE_CODE_MAX_RETRIES, CLAUDE_CODE_RETRY_WATCHDOG et API_TIMEOUT_MS, un tableau de correspondance avec huit messages voisins, et enfin deux signalements réels où le HTTPS brut est sain et où seule la CLI tombe sur ECONNRESET (#86473 et #85979). La conclusion sépare les niveaux de fiabilité : le symptôme, le sens et la procédure de reprise sont documentés officiellement, l'explication de la cause ne l'est pas, et le CHANGELOG ne porte aucune trace du renommage.

Migrer vers Claude Fable 5.1 ne s'arrête pas au remplacement de l'ID du modèle. La documentation officielle écrit noir sur blanc que trois des changements sont cassants et, pour deux d'entre eux, l'endroit où l'erreur surgit est loin de sa cause. 1) L'appel d'outil forcé renvoie 400 : les valeurs any et tool de tool_choice répondent par invalid_request_error. Sur un modèle qui réfléchit en permanence, forcer l'appel fait sauter cette réflexion et la qualité des arguments baisse. 2) Le bloc de réflexion est lié au modèle : une conversation qui passe d'une génération précédente à Fable 5.1 conserve son raisonnement, mais dans l'autre sens il est perdu. Et par défaut, les blocs illisibles sont jetés avant d'atteindre le modèle, ils ne sont pas comptés dans input_tokens et n'apparaissent pas non plus sur la facture. Dans les montages qui changent de modèle par routeur ou par bascule de secours, tout a l'air de fonctionner et seul le raisonnement disparaît. Pour s'en apercevoir, il faut l'en-tête bêta thinking-binding-controls-2026-08-01. 3) Modifier un tour passé invalide tous les blocs de réflexion qui suivent : cela vaut pour la reconstruction du prompt system ou du tableau tools, et pour l'habitude d'insérer un rappel puis de l'effacer. Ce contrôle est imposé sur les comptes créés à partir du 31 août 2026, d'où la contradiction possible entre un environnement de test tout juste monté qui échoue et une production qui passe. Il faut aussi éviter le malentendu sur le positionnement : Fable 5.1 n'est pas une relève du modèle phare, et, au moment de sa publication, la documentation officielle écrivait noir sur blanc que pour la plupart des usages il fallait commencer par Opus 5. Aucune hausse de prix ; la seule chose qui a changé, c'est la lecture de cache, qui passe de 0.1 à 0.025 fois l'entrée de base. L'effet dépend du nombre de relectures du même préambule, et la documentation officielle parle d'environ 25% de moins sur les charges typiques et jusqu'à environ 45% de moins sur le travail nettement agentique. Sept comportements changent en outre sans qu'on touche au code (moins d'appels d'outils en parallèle, moins de commentaires sur l'avancement, tendance à répondre de mémoire à effort low, prose plus dense, moins de mise en forme, citations non signalées dans les résumés, réécriture de tout le texte pour la moindre correction). Les cinq fonctionnalités ajoutées (dont la baisse du prix de la lecture de cache, traitée à part au chapitre 5) et les cinq étapes de migration sont également reprises, le tout à partir de la documentation officielle d'Anthropic.

Remote Control connecte l'application mobile Claude ou claude.ai/code à une session Claude Code déjà lancée sur votre propre machine, et le point que la plupart des explications manquent est que rien ne part dans le cloud : l'exécution du code et l'accès aux fichiers restent locaux du début à la fin, et le téléphone n'est qu'une fenêtre ouverte sur cette session. Cet article détaille ce que ce choix de conception apporte et ce qu'il coûte. Votre système de fichiers local, vos serveurs MCP, vos outils et la configuration du projet restent tous disponibles (taper @ complète les chemins du projet local), la conversation et l'avancement des sous-agents restent synchronisés entre terminal, navigateur et téléphone, et un portable en veille ou une connexion coupée se surmontent parce que Claude Code se reconnecte et livre les mises à jour mises en file dès qu'il récupère. Les prérequis sont plus stricts qu'il n'y paraît : Pro, Max, Team ou Enterprise (les clés API ne sont pas prises en charge), une connexion claude.ai plutôt qu'un setup-token, une liaison directe à api.anthropic.com, et aucune des quatre variables d'environnement qui désactivent la télémétrie, ce qui explique pourquoi les utilisateurs soucieux de confidentialité ayant défini DO_NOT_TRACK s'entendent dire que la fonctionnalité n'est pas activée sur leur compte. Trois points d'entrée sont couverts (/remote-control pour emporter la conversation en cours, claude --remote-control, et le mode serveur avec ses options --spawn, --capacity 32 et --continue), ainsi que le partage entre les commandes slash utilisables à distance et celles réservées au local comme /resume, l'expiration de cinq minutes des boîtes de dialogue qui ne s'applique pas aux demandes d'autorisation, et les deux interrupteurs de notifications push. Sur la sécurité, l'article est délibéré : aucun port entrant n'est jamais ouvert, si bien que la surface d'attaque réseau disparaît presque entièrement et que le risque se déplace vers le compte, le QR code est un raccourci et non une authentification, et la porte par défaut est exactement un compte connecté, ce qui fait de la passkey l'étape la plus rentable. La conservation des transcriptions (5 ans ou 30 jours), la marche à suivre en cas de perte du téléphone, Trusted Devices et sa fenêtre de connexion de 18 heures, le délai de dix minutes du mode serveur, la fenêtre de reprise de quatre heures, l'obligation d'utiliser tmux sur les machines distantes, un tableau de dépannage indexé sur les vrais messages d'erreur et une comparaison avec Dispatch complètent l'ensemble.

La façon dont Claude réfléchit a connu un changement de génération. L'ancienne réflexion étendue (extended thinking) vous faisait préciser un budget de tokens à chaque requête — thinking: {"type": "enabled", "budget_tokens": N} — mais le bon budget diffère selon la tâche, ne peut pas être deviné à l'avance, et le modifier invalide le cache de prompt. L'actuelle réflexion adaptative (adaptive thinking) tient en une ligne, type: "adaptive" : réfléchir ou non, et à quelle profondeur, est la décision du modèle lui-même selon la difficulté apparente de la requête. La migration s'est faite par étapes : budget_tokens a été déprécié sur Opus 4.6 / Sonnet 4.6 et est rejeté avec une erreur 400 à partir d'Opus 4.7. Cet article condense les règles par modèle en un seul tableau — Fable 5.1 et Opus 5.5 réfléchissent toujours (impossible à désactiver), Sonnet 5.5 a la réflexion activée par défaut et rejette disabled avec une 400, mais between_tools coupe seulement la réflexion initiale (effort high ou moins), les modèles Legacy Opus 5 et Sonnet 5 ont la réflexion activée par défaut (sur Opus 5, la désactivation n'est permise qu'à effort high ou moins), Opus 4.8 / 4.7 exigent un réglage adaptive explicite, et les modèles qui ne prennent en charge que la réflexion étendue, comme Haiku 4.5 / Sonnet 4.5, gardent budget_tokens comme seul mode. Le contrôle de la profondeur est passé à output_config: {"effort": ...} avec cinq niveaux (défaut high sur la plupart des modèles, medium sur Opus 5.5 et Haiku 5.5), et changer l'effort casse le cache exactement comme changer le budget autrefois. La visibilité est régie par display : le défaut de la nouvelle génération est "omitted" (blocs de réflexion vides), et vous payez de toute façon l'intégralité des tokens de réflexion — mesurez avec usage.output_tokens_details.thinking_tokens ; aucun réglage ne renvoie jamais la chaîne de pensée brute. Désactiver la réflexion sur Opus 5 comporte des effets secondaires documentés (appels d'outils écrits en texte brut, fuite de balises internes), donc abaisser l'effort est le levier de coût le plus sûr. La réflexion entrelacée — raisonner entre les appels d'outils — est automatique en mode adaptatif, l'ancien en-tête bêta n'étant plus nécessaire. Et quand la vitesse compte, le fast mode exécute le même Opus environ 2,5x plus vite pour un prix doublé (Opus 5.5/5/4.8 uniquement, bascule /fast dans Claude Code). Tout s'appuie sur la documentation officielle d'Anthropic : Thinking, Extended thinking et Fast mode.