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

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.

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.

Beaucoup de gens appuient sur le /compact de Claude Code selon une règle du type « toutes les 30 minutes » ou « dès que le contexte dépasse 70 % », mais ce que recommande la documentation officielle n'est ni une horloge ni un pourcentage : c'est une rupture dans le travail. Lancez /compact à une frontière naturelle, par exemple entre deux tâches, plutôt que d'attendre que la compaction automatique se déclenche au milieu d'une tâche. Cet article prend pour source primaire la documentation de Claude Code au 4 octobre 2026 (dernière version publiée : v2.1.289) et traite la question de la compaction manuelle à partir des spécifications. Il commence par la mécanique : la compaction se joue en trois étages, à savoir l'abandon des anciennes sorties d'outils, la compaction automatique, puis le /compact manuel que vous déclenchez. Les deuxième et troisième sont exactement le même traitement, si bien qu'appuyer soi-même n'achète que deux choses, choisir le moment et préciser ce qu'il faut garder. Appuyer plus souvent n'économise pas de contexte supplémentaire. Vient ensuite un tableau de ce qui survit. Le CLAUDE.md à la racine du projet et votre mémoire automatique sont réinjectés depuis le disque, tandis que les règles portant paths: et les CLAUDE.md imbriqués dans des sous-répertoires sont perdus jusqu'à ce qu'un fichier correspondant soit relu ; le corps des skills que vous avez invoqués est réinjecté sous un plafond de 5 000 tokens par skill et de 25 000 au total, les plus anciens étant abandonnés en premier. Côté coût, le prix d'une compaction est fixé non par la taille du contexte mais par la chaleur du cache de prompt. Appuyez en pleine session et le préfixe est lu depuis le cache, ce qui revient bon marché ; appuyez après une pause plus longue que la durée de vie du cache (une heure sur un abonnement, cinq minutes par défaut avec une clé d'API) et l'historique entier est retraité sans cache, ce qui est le maximum que cette commande puisse coûter. L'article couvre ensuite comment choisir entre /compact, /clear, /rewind, /recap et /context, comment /autocompact depuis la v2.1.221 déplace le point de déclenchement automatique de 100K à 1M tokens et l'ordre de priorité des quatre endroits d'où le réglage peut venir, le piège de la variable d'environnement qui n'accepte qu'un entier brut, ainsi que le sens et la marche à suivre pour les deux messages « Not enough messages to compact. » et « Autocompact is thrashing: the context refilled to the limit... ».

Vous essayez d'ouvrir Claude Desktop sous Windows et ce qui apparaît est une boîte de dialogue intitulée « Impossible d'ouvrir cette application », qui vous demande d'aller dans les options avancées de Claude et de choisir Réparer — et faire exactement ce qu'elle dit fonctionne. Sans désinstaller quoi que ce soit, et sans passer par Réinitialiser, qui, lui, jette vos données. Il y a toutefois une marche au milieu du chemin, et c'est le cœur de cet article. Un clic sur Réparer peut vous renvoyer un message vous disant que l'application est encore en cours d'exécution, alors qu'aucune fenêtre Claude n'est ouverte nulle part. La cause est que Claude Desktop continue de tourner dans la zone de notification après la fermeture de sa fenêtre : tant que ce processus résident tient ouverts les fichiers du paquet, la réparation ne peut pas aboutir. La solution est simple : fermez explicitement les processus, puis cliquez sur Réparer. Et ce fait désigne la cause même de la panne, le même processus ayant cassé la mise à jour avant de bloquer la réparation. L'article répond aussi à la question que tout le monde pose en premier : vos sessions sont-elles effacées ? La réponse se divise en trois. Votre historique de conversations claude.ai est sur les serveurs d'Anthropic et reste intact. Les sessions Claude Code vivent dans %USERPROFILE%\.claude\projects\, hors du paquet de l'application : elles survivent à une réparation, à une réinitialisation et même à une désinstallation (une machine réelle en contenait 2 977 fichiers, environ 3,0 Go, répartis sur 52 projets). La seule chose exposée, ce sont les réglages côté application dans %APPDATA%\Claude, et Réparer les conserve même — Windows écrit la différence sur l'écran lui-même, en indiquant à côté de Réparer que les données de l'application ne seront pas affectées, et à côté de Réinitialiser qu'elles seront supprimées. Suivent la vérification d'état en PowerShell en lecture seule, une routine de sauvegarde, une escalade par paliers quand l'application refuse toujours de s'ouvrir (contrôle de vmcompute et hns, suppression du paquet puis réinstallation, car -PreserveApplicationData ne fonctionne pas sur une installation normale), la cause déduite d'un MSIX à moitié enregistré appuyée sur les tickets GitHub (#55465, où l'installation a réussi sans qu'aucun point d'entrée soit créé, plus #50285 et #48437 — tous clos en closed as not planned, sans correctif officiel), les moyens de réduire les risques de récidive, et une comparaison avec l'ancienne version installeur, où la dernière version MSIX et une machine en ancien format affichaient toutes deux 1.24012.9.

Claude Code s'arrête au milieu d'une réponse sur « API Error: Connection closed mid-response. The response above may be incomplete. » Ce n'est pas un problème de prompt : la connexion qui transportait la réponse en streaming s'est fermée alors que la réponse arrivait encore. Cet article s'appuie uniquement sur la référence des erreurs officielle, le changelog officiel et des tickets étayés par des captures réseau. Il part des définitions officielles — Connection closed signifie que le lien a été coupé, Response stalled qu'il est devenu silencieux, Server error qu'une 5xx est survenue en cours de flux — et explique pourquoi la sortie partielle est délibérément conservée (renvoyer risquerait d'exécuter deux fois les mêmes appels d'outils) et que l'étape de reprise documentée est de répondre continue. Il sépare ensuite les trois couches d'où la fermeture peut provenir (votre machine et la veille, une coupure d'inactivité dans un proxy ou un VPN, ou une fermeture initiée par le serveur) et présente les mesures publiées par l'auteur du ticket #67766 : les dix incidents étaient des fermetures propres côté serveur, l'erreur apparaissait 3 à 105 ms après le FIN, 7 à 20 Ko de réponse avaient déjà été reçus, le corps de requête pesait 1 à 2,5 Mo, une nouvelle connexion aboutissait en 20 ms environ, et 200 erreurs réparties sur 171 incidents figuraient dans 23 jours de transcriptions, dont 87 moins de cinq secondes après l'appel précédent. Le cœur pratique est une chronologie d'entrées réelles du changelog — 2.1.179 conserve le partiel, 2.1.185 fait passer l'indication de blocage de 10 à 20 secondes, 2.1.198 relance les coupures transitoires avec backoff, 2.1.199 conserve le partiel sur erreur serveur en cours de flux, 2.1.214 désactive le pool keep-alive après une erreur de connexion périmée — confrontée aux versions des signalements (2.1.173, 2.1.181, 2.1.183), toutes antérieures à la 2.1.198. Il se termine par les conditions aggravantes, une check-list en huit points, six repères pour les développeurs, la distinction avec Unable to connect et Prompt is too long, et un partage net entre ce qui est confirmé officiellement et ce qui ne l'est pas.

Vous ouvrez Hugging Face pour faire tourner un LLM en local et le même modèle affiche un mur de fichiers (Q4_K_M, Q5_K_S, GPTQ, AWQ, IQ3_M) et vous voilà bloqué. Cet article répond concrètement : quel fichier quantifié télécharger pour que ça marche, en laissant le concept de ce qu'est la quantification à un autre article et en se concentrant sur le choix du format. Le choix tient en deux étapes : quel format (= quel moteur pour l'exécuter), puis quelle profondeur de bits. Le fait le plus important : un fichier quantifié ne tourne que sur les moteurs qui prennent en charge son format. GGUF est le format local tout-terrain de référence qui tourne sur CPU, Mac et GPU partiel (llama.cpp/Ollama) ; GPTQ/AWQ/EXL2 sont orientés GPU d'abord (vLLM) ; bitsandbytes quantifie au chargement dans Transformers sans calibration. Le nommage GGUF Q4_K_M a trois parties : Q4 (nominal 4 bits, plus élevé = meilleur et plus gros), K (K-quant sur des super-blocs ; simple/_0/_1 sont anciens), M (S/M/L = mesure du rehaussement de certains tenseurs importants ; les bits effectifs dépassent l'étiquette, Q4_K environ 4,5 bpw). La famille IQ (I-quants) va encore plus petit à bits égaux mais est plus lourde à l'inférence et exige un imatrix (une matrice d'importance issue d'une calibration qui protège les poids qui comptent). GPTQ minimise l'erreur couche par couche ; AWQ protège les poids saillants via les activations (aucun n'est universellement meilleur). Pour la profondeur de bits, en cas de doute prenez Q4_K_M (défaut Ollama pour beaucoup de modèles), montez à Q5_K_M/Q6_K avec de la VRAM en réserve, Q8_0 est quasi sans perte mais déconseillé, et IQ2/IQ3 uniquement pour caser un gros modèle. Environ 4,5 à 5 bpw est la bonne bande (une heuristique). Trouvez les fichiers via library=gguf, bartowski/mradermacher (activité variable), ou les tags Ollama model:size-variant-quant. Les chiffres sont approximatifs et varient selon le modèle et le build.

Juste après avoir mis à jour Claude Desktop (Windows), lancer l'application fait apparaître « Un autre programme utilise actuellement ce fichier » et elle refuse de démarrer — et reste bloquée jusqu'au redémarrage du PC. C'est un bug connu de la version Microsoft Store (MSIX) (GitHub #53247 et d'autres). Le point clé : un redémarrage complet du PC n'est pas forcément nécessaire — dans bien des cas, il suffit de se déconnecter de Windows puis de se reconnecter pour récupérer (pas un redémarrage du PC, ni une déconnexion de Claude), car le handle orphelin sous-jacent persiste par session utilisateur Windows. Arrêter CoworkVMService ou réenregistrer le package est rapporté comme inefficace. Malgré le libellé de la boîte de dialogue, il est vérifié qu'il n'y a aucun verrou de fichier en espace utilisateur (handle.exe / Process Explorer) : le vrai échec se situe dans la couche conteneur AppX/Desktop Bridge, à la conversion Job Object → Silo (0x80070020 = ERROR_SHARING_VIOLATION, événements 215/208). Le déclencheur a deux explications non tranchées — le service retenant le Job Object (#57221) vs. un plantage au démarrage laissant le nettoyage inachevé (#53247) — et aucun correctif officiel n'a été publié. La solution de contournement permanente est de passer à la version Squirrel (installeur). D'après une seule machine (Windows 11 Home 10.0.26200) recoupée avec des issues GitHub ; avec labels de confiance tout du long.

« De combien l'IA réduit-elle l'effort de développement logiciel ? » Avec l'arrivée du codage agentique en 2025-2026, l'unité de mesure elle-même a changé. Autrefois c'était « de combien de pour cent une tâche est-elle plus rapide » ; c'est désormais une histoire d'ordre de grandeur : « un cycle de dev qui prenait des semaines se comprime en heures ou en jours » (TechTarget). Claude Fable 5 a terminé la migration de 50 millions de lignes de Stripe en une journée ; TELUS a économisé 500 000 heures-développeur ; le temps de cycle est passé de 9,6 à 2,4 jours. Les chiffres de l'ère de l'autocomplétion — ECR Copilot 55,8 % plus rapide, McKinsey 20–50 % selon la tâche — sont désormais le plancher. Mais ce n'est pas un ×10 uniforme : selon le 2026 Agentic Coding Trends Report d'Anthropic, les développeurs utilisent l'IA sur ~60 % de leur travail, mais seuls 0–20 % des tâches peuvent être totalement déléguées (le déficit de délégation), la revue humaine reste donc nécessaire, et environ 27 % du travail IA est un travail nouveau qui n'existait pas auparavant (réduire l'effort = produire davantage). Avec un bon contexte, 40 % d'erreurs en moins et 55 % plus rapide. Même le résultat 2025 de METR « les experts sont 19 % plus lents » s'inverse en 2026, les auteurs admettant que la mesure sous-estime la réalité. Cet article distingue cette polarisation avec des sources nommées (GitHub, McKinsey, Anthropic, METR, DORA) et expose comment capter concrètement les gains d'effort.

Après un long travail dans Claude Code, la réponse se met parfois à répéter « court court court… » des dizaines à des centaines de fois avant de s'arrêter sur « Response stalled mid-stream ». Ce n'est pas une erreur de votre prompt : deux dysfonctionnements connus s'enchaînent — une boucle de répétition (dégénérescence) côté modèle et un arrêt du flux côté transfert. Cet article explique la nature de chaque couche, les conditions déclenchantes, comment l'arrêter tout de suite (Esc → nouvelle session, /clear), comment le prévenir côté développeur (timeout de lecture, détection de répétition, max_tokens) et comment le distinguer du bug de fuite de balise court/invoke, en s'appuyant sur la documentation officielle et les issues réelles.

L'erreur « API Error: 400 Output blocked by content filtering policy » qui surgit soudain dans Claude Code ou l'API n'est ni une limite d'usage ni un dépassement de contexte : c'est le filtre de sécurité qui a interrompu la « sortie » que Claude s'apprêtait à renvoyer. Son objet principal est d'empêcher la reproduction mot à mot d'œuvres existantes, et il produit souvent des faux positifs (false positive) sans mauvaise intention lors de la génération du texte intégral d'une licence standard comme MIT/Apache, d'un travail de « mise en correspondance » avec une source existante, ou de la duplication de documents longs. Cet article fait le point sur l'explication officielle (le filtre de sortie détecte la reproduction d'une œuvre et bloque avec un 400), les cas de faux positifs relevés dans les Issues réelles de Claude Code (mise en place d'un dépôt OSS, rapprochement de listes, diagnostic erroné en « limite de tokens » au terme d'une longue exécution d'agent), les solutions immédiates (récupérer via un outil plutôt que faire recopier, reformuler le prompt vers la génération/le résumé, arrêter la boucle de nouvelles tentatives avec Esc, découper la tâche, signaler les faux positifs au support), et la distinction avec Prompt is too long, usage limit, 529 Overloaded et max_tokens.