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

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, réinstallation avec -PreserveApplicationData), 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 seul format local tout-terrain qui tourne sur CPU, Mac et GPU partiel (llama.cpp/Ollama) ; GPTQ/AWQ/EXL2 sont orientés GPU d'abord (vLLM/TGI) ; 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.

Beaucoup de développeurs solo se bloquent à « je sais construire, mais comment gagner de l'argent et à quel prix vendre ». Cet article réunit, du point de vue du développeur solo : le choix du modèle de monétisation (gratuit / paiement unique / abonnement / freemium / publicité / dons), la tarification à la valeur — qui part non des coûts ou des concurrents mais de « la valeur que le client obtient » —, l'offre à 3 paliers Gratuit → Pro → Business avec la règle d'or de la remise annuelle, la façon de décrocher son premier client payant, et enfin la rentabilité qui intègre le coût de l'IA (tokens d'API, etc.). Un article qui approfondit la phase « faire grandir » du hub « Feuille de route du développement solo avec l'IA ».

La plus grande cause d'échec du développement solo, c'est « trop peaufiner ». À force d'empiler les fonctions, ça se complexifie, et le projet disparaît sans jamais être publié. Le seul moyen d'y échapper : se limiter à une seule fonction et publier au plus vite le produit minimal qui transmet sa valeur — le MVP. Cet article explique, du point de vue du développeur solo qui prend l'IA pour coéquipière : la juste conception du MVP, le jugement de périmètre pour couper des fonctions, les deux voies pour construire au plus vite avec l'IA (vibe coding sans écrire de code / pratique en éditeur IA), la reconnaissance du « terminé », et le chemin jusqu'à publier et faire utiliser par une personne.

Maintenant que l'IA dispose de « mains pour écrire du code », une seule personne peut créer un produit et le lancer. Mais l'information est éparpillée étape par étape et l'on ne sait pas par où commencer. Cet article est la carte d'ensemble (feuille de route) qui va de l'idée → conception → implémentation → mise en ligne → monétisation : un article vaisseau amiral (hub) qui organise le développement solo en 5 phases (décider → préparer → construire → publier → faire grandir), indique pour chaque étape quoi faire et quels outils utiliser, et renvoie vers un guide dédié là où un approfondissement est nécessaire. De plus, il guide sur deux voies — la 🌱 voie débutant qui n'écrit presque pas de code, et la 🔧 voie pratique qui écrit du code dans un éditeur IA — pour qu'en suivant celle qui vous correspond, vous atteigniez une chose qui fonctionne sans détour. Spec-driven, générateurs d'applications IA, Claude Code / Cursor, intégration de fonctions IA (API / RAG / passerelle), déploiement, acquisition SEO/AEO, monétisation, gestion des coûts et les 5 pièges du développement solo avec l'IA : tout est réuni sur une seule page, avec des liens vers les guides pratiques existants.

Vous atteignez la limite hebdomadaire de tokens de Claude Code, et pourtant votre quota s'est entièrement reconstitué avant sept jours — plus d'une fois. En ligne, il existe même des articles sur un « mécanisme caché » affirmant que la limite hebdomadaire se réinitialise toutes les 72 heures. Est-ce vrai ? Cet article remonte le phénomène jusqu'à ses sources primaires. Mais Anthropic n'a pas documenté le mécanisme interne de réinitialisation, et les limites ne cessent d'évoluer ; nous étiquetons donc clairement trois types d'information : les faits vérifiables à partir de sources officielles, les événements que plusieurs utilisateurs observent de façon reproductible mais qu'Anthropic n'a jamais commentés, et les spéculations non confirmées reposant sur une source unique. L'essentiel : la récupération anticipée complète est, dans la plupart des cas, due aux réinitialisations globales irrégulières d'Anthropic (annoncées à plusieurs reprises par @ClaudeDevs) ; l'heure de réinitialisation affichée est aussi manifestement instable ; et la « cadence de 72 heures » qui circule repose sur un observateur unique, n'a pas été reproduite, et est contredite par une autre observation (24 h), elle ne peut donc pas être considérée comme un fait. Lorsqu'une chose ne peut pas être affirmée, nous le disons — une enquête de juillet 2026.

Vous avez construit sur OpenAI, puis voulu essayer Claude et comparer Gemini — et perdu des heures à cause des SDK, formats et gestions d'erreurs différents par fournisseur. Une passerelle LLM (passerelle IA / proxy LLM) est un relais que vous glissez entre votre application et les fournisseurs : elle expose une seule API compatible OpenAI pour atteindre tous les modèles et prend en charge les tâches transversales — bascule, suivi des coûts, clés virtuelles, mise en cache, limitation de débit et observabilité. Ce guide couvre pourquoi vous en avez besoin, ce qu'une passerelle est vraiment, les trois types (proxy auto-hébergé = LiteLLM / hébergé = OpenRouter / SDK = Vercel AI SDK), comment choisir parmi LiteLLM, OpenRouter et le Vercel AI SDK, le code de configuration minimal qui ne remplace que le point de terminaison, et les limites — un saut de latence, la passerelle comme nouveau point de défaillance, les frais (OpenRouter facture 5,5 % sur les achats), la perte de fonctionnalités et la confidentialité.