Développement IA et programmation : créez des apps

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.

« 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 quatre messages de coupure en cours de réponse (Server error, Connection lost, computer went to sleep, The response stopped arriving), 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 la documentation officielle écrit noir sur blanc que pour la plupart des usages il faut 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 abandonnent 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.

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 réfléchit toujours (impossible à désactiver), 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 hérités comme Sonnet 4.5 / Haiku 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), 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/4.8 uniquement, bascule /fast dans Claude Code). Tout s'appuie sur la documentation officielle d'Anthropic : Thinking, Extended thinking et Fast mode.

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.

Une affirmation générale ne peut pas répondre à la question « si une IA peut modifier les choses directement, avons-nous encore besoin d'une interface d'administration ? », parce que la seule expression « interface d'administration » recouvre un empilement de fonctionnalités de natures complètement différentes. Cet article, ancré dans l'expérience de la suppression pure et simple de l'interface d'administration de ce site, remplace cette question par une autre, plus tranchante : cet écran fournit-il quelque chose que la CLI et l'IA ne fournissent pas déjà ? Ce que la suppression de l'ensemble a révélé, c'est que la plupart des fonctionnalités retirées n'étaient pas « inutilisées » mais « structurellement cassées ». Le CRUD des articles ne pouvait pas fonctionner, parce que la source de vérité des articles vit dans le code et que chaque déploiement écrase la base de données : tout ce qui était modifié dans l'écran disparaissait au déploiement suivant. La file de modération des commentaires était toujours vide parce que les messages étaient marqués comme approuvés dès leur envoi, si bien qu'un commentaire non approuvé ne pouvait jamais exister. Une fonctionnalité que personne n'utilise est une fonctionnalité dont personne ne peut voir qu'elle est cassée. La seule capacité qui ne pouvait pas disparaître était la suppression des commentaires, et même celle-là n'avait aucune raison intrinsèque de vivre dans une interface d'administration : un bouton de suppression sur la page de l'article s'est révélé meilleur, parce que le commentaire fautif peut être retiré là où on est en train de le lire. La décision se ramène à six questions. Qui l'utilise (des personnes non techniques ou un poste qui change de titulaire plaident pour une UI ; des développeurs qui vivent dans un terminal, non). Est-ce réversible (les actions irréversibles ont besoin d'une barrière). Faut-il un jugement humain (existe-t-il une transition d'état du type approuver ou rejeter). Faut-il séparer les droits. L'opérateur sait-il ce qui est possible (la liste fait office de documentation). Existe-t-il une piste d'audit. Les droits et la piste d'audit, en particulier, paraissent inutiles sur un projet solo et deviennent les premières exigences à la seconde où une deuxième personne arrive. Les changements passés par le code atterrissent dans git, mais laisser une IA écrire directement dans la base de données n'enregistre rien par défaut, et un historique de conversation conserve ce qui a été demandé plutôt que ce qui s'est produit. Parmi les six axes, seule la réversibilité pèse d'un poids différent. Le 18 juillet 2025, un agent d'IA de Replit a supprimé la base de données de production de SaaStr pendant un gel du code en cours, a fabriqué 4 000 utilisateurs et a affirmé à tort qu'un retour arrière était impossible, retardant la reprise (AI Incident Database #1152) — un cas qui montre moins la dangerosité de l'IA qu'un problème de conception où une action irréversible pouvait être atteinte sans passer par une barrière humaine. L'article traite aussi des trois choses à mettre en place avant de déplacer le poids vers l'IA et la CLI (les changements laissent une trace durable, une marche se tient devant les actions irréversibles, la procédure est écrite quelque part, puisque supprimer l'UI supprime aussi la liste de ce qui est possible), d'une liste de contrôle à passer avant de construire quoi que ce soit, et de la troisième option que constituent les produits d'outillage interne comme Retool ou Forest Admin plutôt qu'une interface écrite à la main.