Environnement de développement et infrastructure IA

Ouvrir ses sessions une à une pour changer le modèle et l'effort à chaque nouveau modèle, c'est une corvée. Quand j'ai essayé dans mon propre environnement le 24 septembre 2026, demander à l'assistant de « tout passer sur tel réglage » a fonctionné dans Claude Code Desktop comme dans Codex, sans que je touche à chaque session. Dans Claude Code Desktop, les outils que l'application fournit à l'assistant ont modifié les sessions sans envoyer de message, et les changements ont survécu à un redémarrage de l'application. En revanche, il ne voit que les sessions locales de l'application de bureau, se limite par défaut aux 20 plus récentes et ne peut pas modifier la session d'où vient la demande. Dans Codex, la valeur par défaut des nouveaux chats a été changée dans config.toml, et l'assistant a utilisé un mécanisme interne pour modifier un par un les 115 chats existants de mon environnement. Les chats ouverts dans l'application ont chacun reçu un message de confirmation. Cet article présente les différences entre les deux, ce qu'ils peuvent atteindre ou non, des exemples de demandes et 4 vérifications : garder les anciennes valeurs, définir le périmètre, tout relire et en vérifier une de ses propres yeux.

Les sessions cloud de Claude Code sont sorties de l'aperçu de recherche et sont devenues disponibles pour tous le 23 septembre 2026. Votre dépôt GitHub est cloné dans une machine virtuelle du cloud d'Anthropic, où Claude corrige le code et pousse une branche : le travail ne s'arrête pas quand vous fermez votre ordinateur portable. L'usage est décompté des mêmes limites que votre forfait habituel, sans facturation séparée pour la VM. En plus, les abonnés Pro existants reçoivent un crédit unique de 100 $ et les abonnés Max de 250 $ : réclamé au plus tard le 7 octobre, il est consommé en premier jusqu'au 5 novembre, 7 h 59 UTC (Projects et Routines sont exclus). À partir de la documentation officielle et des publications du compte officiel, cet article explique en quoi les sessions cloud diffèrent de Claude Code en local et de Remote Control (quels paramètres suivent et lesquels ne suivent pas, modes de permission, les quatre niveaux d'accès réseau et où ranger les secrets), comment démarrer depuis le navigateur et le terminal, comment réclamer le crédit et les réserves du texte intégral des conditions de l'offre, et pour quels travaux elles conviennent ou non.

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.

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.

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.

Faire écrire du code par un modèle qui tourne sur votre propre PC était déjà possible il y a quelques années, mais cela se limitait à la complétion, et l'usage agentique où l'on lit le dépôt, corrige plusieurs fichiers et lance les tests restait trop lourd pour une machine locale. Cela a changé entre la fin 2025 et 2026 : Qwen cite nommément CLINE dans ses fiches de modèle officielles, et Mistral AI a publié Devstral Small 2 (24B) sous licence Apache 2.0 en revendiquant explicitement le codage agentique. Cet article fait le point uniquement à partir de sources primaires, en écartant les articles de synthèse dont plusieurs attribuaient à un modèle le score d'un modèle d'une autre taille. Le passage obligé est la longueur de contexte par défaut d'Ollama, qui n'est pas une valeur fixe mais dépend de la VRAM : moins de 24 GiB donne 4k, ce qui suffit à faire dérailler un agent sans qu'aucune erreur ne s'affiche, puisque le dépassement est traité comme une troncature et non comme une erreur. La recommandation officielle est d'au moins 64000 jetons pour les outils de codage, mais augmenter la valeur augmente aussi la mémoire nécessaire, d'où la vérification par ollama ps pour confirmer que tout tient sur le GPU. Sont également couverts la différence de fond entre Continue, qui assigne un modèle par rôle, et Cline, agent autonome bien plus exigeant, le choix du modèle par tranche de VRAM avec les scores publiés par les éditeurs (Qwen3.6-35B-A3B à 73.4, Devstral Small 2 à 68.0%), et le fait que la comparaison avec le cloud est devenue difficile à établir puisque les modèles de frontière s'éloignent peu à peu de SWE-bench Verified. Enfin, le local n'est pas gratuit : le coût change simplement de forme, et la réponse s'inverse selon que le matériel est déjà là ou non.

Claude Desktop se fige en plein travail et toutes les sessions Claude Code que vous aviez ouvertes s'arrêtent au même instant ; vous forcez l'arrêt, et parfois l'application refuse ensuite de démarrer. La dernière ligne de %APPDATA%\Claude\logs\main.log est presque toujours la même : GPU process gone, avec exitCode 101457950 (0x060C201E). Cet article expose ce qu'est ce code, pourquoi des sessions qui n'ont rien à voir entre elles tombent ensemble, et quels remèdes tiennent. D'abord une séparation : ce n'est pas Claude Code (la CLI) qui a planté, mais le processus GPU de l'application de bureau Electron qui l'héberge. Vient ensuite l'étendue des dégâts. Chromium concentre le rendu dans un unique processus GPU, un seul par application, partagé par toutes les fenêtres, tous les onglets et toutes les sessions ; une seule page lourde ouverte dans le navigateur intégré peut donc emporter huit sessions sans rapport au même instant, et aucun réglage utilisateur ne les sépare. Le navigateur intégré domine les tickets publics : le #80444 consigne le processus mourant 15 à 36 secondes après qu'une page a lancé la détection WebGL/WebGPU, quatre fois avec le même code ; le #82967 attribue le déclenchement à la capture d'écran d'aperçu de l'outil navigateur ; le #83478 le reproduit en laissant ouvert un aperçu qui se rafraîchit en continu. Mais le navigateur n'est pas le seul déclencheur : le #68049 signale le même code au démarrage sur ARM64, sans interaction avec le navigateur, et le #83028 le reproduit sur un GPU intégré Intel. Le diagnostic repose sur trois fichiers — main.log, unknown-window.log (un CONTEXT_LOST_WEBGL au même horodatage) et le dossier Crashpad — plus un tableau qui distingue 101457950 des codes de fermeture propre, et un avertissement : la ligne requestAdapter / powerPreference du même journal est un message Chromium normal, pas le signe d'un plantage. La récupération couvre Réparer, quand Windows marque le paquet Modified et refuse de le lancer, et le signalement où l'état a atteint Modified, NeedsRemediation, où seules une suppression complète et une réinstallation ont ramené l'application ; les transcriptions enregistrées survivent, mais pas le travail en cours (le #81698 a perdu des résultats de sous-agents lancés en parallèle). Restent ce qui aide et ce qui n'aide pas, l'astuce du GPU hybride — sans aucun signalement indiquant qu'elle ait aidé pour ce symptôme —, et la manière de distinguer un arrêt forcé par une mise à jour du Store d'un vrai plantage.