Claude ne s'ouvre pas sous Windows : 110 584 caractères de diagnostic, 19 caractères de réponse
Écran blanc, application disparue du menu Démarrer, bouton « Réparer » qui se saborde tout seul. La machine derrière un bug ouvert depuis quatre mois, et le protocole qui marche vraiment.
En bref. L’application de bureau Claude sous Windows casse toute seule depuis avril 2026. Écran blanc chez les uns, application qui refuse de s’ouvrir chez les autres, parfois disparue du menu Démarrer. Des dizaines d’utilisateurs ont produit un diagnostic de qualité professionnelle sur le dépôt public d’Anthropic : journaux alignés à la milliseconde, empreintes numériques de 2 817 fichiers, captures Procmon. Le 25 août 2026, le fil principal a été fermé avec trois mots, en doublon d’un ticket ouvert depuis quatre mois où personne ne répond non plus. Le lendemain, le bug était reproduit sur la dernière version.
Ce qui suit raconte la machine sous le capot, donne le protocole de dépannage dans l’ordre, et pose un chiffre : 110 584 caractères écrits par les utilisateurs, 19 par l’éditeur.
Un abonnement Pro, un rectangle blanc, et dix tentatives dans le vide
Une proche achète un abonnement Claude Pro. Elle installe l’application de bureau sur son Asus Zenbook, sous Windows 11. L’application s’ouvre : cadre de fenêtre normal, boutons réduire, agrandir, fermer à leur place, et un rectangle blanc à la place de tout le reste.
Dans le gestionnaire des tâches, une dizaine de processus Claude tournent. L’application est vivante. Elle n’affiche rien.
Ce qui a été tenté, dans l’ordre, sur une soirée, à deux :
| # | Tentative | Résultat |
|---|---|---|
| 1 | Désinstallation puis réinstallation | Écran blanc |
| 2 | Deuxième désinstallation, deuxième réinstallation | Écran blanc |
| 3 | Script de nettoyage des dossiers de configuration | Écran blanc |
| 4 | Désactivation du HDR dans les réglages d'affichage | Aucun effet |
| 5 | Relance avec l'accélération graphique désactivée | Le script n'aboutit pas |
| 6 | Ajout de Claude dans les préférences GPU de Windows | Impossible, dossier protégé |
| 7 | Script de désinstallation du paquet | Erreur 0x80073CF1 |
| 8 | Troisième cycle complet avec le programme d'installation officiel | Écran blanc |
| 9 | Nouvelle tentative dans les préférences GPU | C'est « Microsoft Store » qui a été ajouté, pas Claude |
| 10 | Utilitaire de résolution des problèmes Windows, puis wsreset | L'installation plante |
Dix tentatives. Aucune amélioration. Le verdict, tombé vers minuit : « Elle va résilier son forfait. »
Et l’aveu qui va avec : je n’ai pas trouvé, ce soir-là. Deux personnes, dont une qui répare des machines depuis vingt-huit ans, mises en échec par une application qui affiche du blanc.
Ce qui suit, c’est ce que j’ai compris après, en creusant le dépôt public où les utilisateurs de Windows documentent cette panne depuis quatre mois.
Windows ne fait plus tourner les applications dans la maison, il leur monte un appartement
Il faut une image pour la suite, et elle tient tout l’article.
Depuis quelques années, Windows n’installe plus les applications modernes « dans la maison », mélangées au reste du système. Il leur monte un appartement à part dans l’immeuble : murs à elle, compteurs à elle, boîte aux lettres à elle. C’est plus propre sur le papier. L’application ne peut plus salir le reste du logement, et quand elle s’en va, elle ne laisse rien derrière.
Cet appartement porte un nom technique, MSIX, mais peu importe le nom. Ce qui compte, c’est le principe : l’application ne détient pas les clés de son propre appartement. Seul le gardien de l’immeuble les a. Chaque fois qu’il faut refaire la peinture, autrement dit à chaque mise à jour, c’est le gardien qui ouvre. Et il exige que le logement soit vide.
Le bug de Claude sous Windows, c’est ça et rien d’autre : des travaux lancés pendant que quelqu’un dort encore dans l’appartement. Le gardien refuse d’ouvrir, laisse un mot sur la porte, et personne ne lit le mot.
À partir de là tout s’enchaîne. Et chaque étage de l’immeuble ajoute son mensonge.
Quatre mensonges empilés
1. Le message d'erreur désigne un coupable qui n'existe pas
L’utilisateur voit une boîte de dialogue Windows, « Un autre programme utilise ce fichier actuellement ». Réflexe immédiat, chez tout le monde, moi compris : ouvrir le gestionnaire des tâches et chercher le coupable à tuer.
Il n’y a pas de coupable. Ce texte est la phrase générique que Windows affiche pour un code d’erreur donné, 0x80070020, et elle tombe à côté. Le vrai blocage est dans les compteurs de l’appartement. Quand l’application tourne, Windows monte pour elle un petit registre privé, un fichier de configuration invisible. Après un plantage, ce registre reste monté : le compteur tourne encore alors que le logement est vide. Pour rouvrir, Windows doit le remonter. Il est déjà monté. Il abandonne.
Ce registre n’apparaît ni dans le gestionnaire des tâches, ni dans les outils d’inspection habituels. Il est tenu par le noyau du système, pas par un programme. Tuer des processus ne peut rien y faire, par construction.
La preuve a été apportée deux fois, par deux utilisateurs qui ne se connaissent pas, les 8 et 19 août. Tous les deux ont lancé Procmon, l’outil gratuit de Microsoft qui trace chaque accès fichier, au moment exact de la panne. Résultat : aucun processus ne tient le fichier. L’opération qui échoue est le montage du registre privé du conteneur.
Le message envoie tout le monde chasser un processus, et il n’y en a pas.
C’est le cœur du métier de dépannage, et ça dépasse largement Claude : quand le message d’erreur ment, tout ce que vous faites ensuite est perdu. Nous avons passé une soirée sur le pilote graphique parce qu’un symptôme nous avait envoyés du mauvais côté.
2. Windows déclare le paquet modifié. 2 817 fichiers disent le contraire
Windows tient une fiche d’état pour chaque appartement. Si les travaux se passent mal, il coche une case : « modifié, nécessite une remise en état ». L’appartement existe toujours, l’adresse est valide, la porte a l’air normale. Mais la case est cochée, et le gardien refuse d’ouvrir tant qu’elle l’est. L’utilisateur, lui, voit « Cette application ne peut pas s’ouvrir », ou une invitation à réinstaller.
Le problème, c’est que rien n’a été modifié.
Le 24 août, un utilisateur a instrumenté sa machine pour capturer l’état exact au moment de la panne, avant toute réparation. Il a calculé l’empreinte SHA256, la signature numérique unique, de chacun des 2 817 fichiers de l’application, et l’a comparée à une référence saine.
Personne n’a touché à l’application. Le verdict du système est faux, et il suffit à la rendre inutilisable.
3. Le garde-fou codé par Anthropic ne peut pas s'exécuter
Celui-là est le plus gênant, et c’est un utilisateur qui l’a trouvé, pas l’éditeur.
Claude installe un service en arrière-plan, CoworkVMService. Les développeurs ont manifestement anticipé le problème : au démarrage, ce service essaie de configurer ses propres règles de reprise, pour éviter de se relancer au mauvais moment pendant des travaux. L’intention est bonne.
La tentative échoue à chaque fois. Message : accès refusé. Deux avertissements écrits dans l’observateur d’événements de Windows à chaque démarrage, sur toutes les machines, depuis des mois. Personne ne les voit, parce que personne n’ouvre l’observateur d’événements.
La raison est structurelle. Un service installé dans un appartement de ce type ne s’appartient pas : sa configuration est décidée par le bail, pas par le locataire. Quand on inspecte ses permissions, on trouve exactement deux entrées, les utilisateurs authentifiés et le service de déploiement de Windows. Ni l’administrateur de la machine, ni le compte système ne figurent dans la liste. Le droit de modifier cette configuration n’appartient qu’à Windows lui-même.
Donc le code écrit pour se protéger de ce bug ne peut pas tourner. Pas « échoue parfois » : ne peut pas, jamais, chez personne.
Le même utilisateur a poussé le raisonnement jusqu’au bout : il a vérifié que le service peut être arrêté sans être administrateur. Le programme de mise à jour a donc déjà, aujourd’hui, tout ce qu’il faut pour arrêter proprement le service avant de lancer les travaux. Il faut juste attendre réellement l’arrêt, au lieu de le demander et de partir. Quelques lignes de code. C’est publié, avec la preuve à côté, depuis le 19 août.
4. Le bouton Réparer démarre le service qui fait échouer la réparation
Windows propose un bouton « Réparer » dans les réglages de l’application. Il marche une fois sur deux, sans raison apparente. Certains le cliquent cinq fois d’affilée avant que ça passe, et en concluent que l’informatique est une affaire de chance.
La réparation se fait en deux temps : reposer le contenu de l’appartement, puis le réenregistrer auprès du gardien. Or la première étape rallume le service, qui est déclaré en démarrage automatique. Quand la seconde étape arrive, il y a de nouveau quelqu’un dans l’appartement. Le gardien refuse. La réparation échoue.
Un utilisateur a aligné les journaux à la milliseconde, sur une machine ARM :
22:59:13.515 conteneur cree, le service y est ajoute 22:59:13.539 le service ecrit dans son journal « demarrage » 22:59:13.572 etape 2 : reenregistrement 22:59:13.934 « deploiement abandonne : une application est encore active »
419 millisecondes entre l’étape qui allume et l’étape qui échoue à cause d’elle. À la seconde près, on ne voit rien et on croit à un hasard. À la milliseconde, il n’y a plus de doute sur qui cause quoi.
Ce constat a fait l’objet d’un ticket dédié, #88962, ouvert le 23 août. Fermé le 25.
Pourquoi personne ne fait le lien entre la casse et la panne
Il reste une pièce, et c’est celle qui explique la phrase qu’on retrouve dans tous les tickets : « je n’ai rien fait ». Elle est exacte.
Claude se met à jour tout seul, en silence, après un délai d’inactivité. Dans son propre journal, la ligne est explicite : déclenchement de la mise à jour furtive après expiration du délai d’inactivité, puis arrêt en cours pour mise à jour. L’application se ferme d’elle-même pour laisser passer les travaux. Et parfois, le nouvel appartement est posé alors que l’ancien n’est pas encore vide : le gardien marque l’enregistrement « à faire plus tard » et s’en va. Personne ne revient jamais le faire.
Deux détails rendent la panne insaisissable.
Le premier, c’est le décalage. Les travaux ratés cochent la case, mais l’application déjà ouverte continue de tourner normalement. Elle ne repasse pas devant le gardien, elle peut tenir des heures. C’est au redémarrage suivant que le refus tombe. Sur ma machine, chronologie publiée le 27 juillet : les travaux échouent à 11h21 un jour, l’application fonctionne sans anomalie jusqu’au lendemain, la panne apparaît après le redémarrage. Entre-temps, trois opérations de réenregistrement enregistrées comme réussies, et 35 secondes après la dernière, la case était toujours cochée.
Le second, c’est le déclencheur. On a longtemps cru, moi le premier, que le danger était la mise à jour nocturne. C’est plus retors : dans plusieurs cas, ce qui casse tout, c’est le double-clic du matin sur une application dont le conteneur est déjà mort. Windows tente alors une auto-réparation, qui démolit ce qui restait debout. Le geste fatal, c’est d’essayer d’ouvrir.
Sur ma machine, la panne prend une forme encore plus déroutante : la mise à jour ratée désenregistre l’application pour l’utilisateur courant. Claude disparaît du menu Démarrer et de la liste des programmes installés, comme s’il avait été désinstallé, alors que tous les fichiers sont là. Quatre fois en cinq jours, avec un téléchargement de 246 Mo à chaque fois avant que je comprenne ce qui se passait.
Récapitulons ce qu’un clic sur l’icône de Claude traverse.
AGRANDIR
110 584 caractères d'un côté, 19 de l'autre
Tout ce que vous venez de lire vient d’utilisateurs. Pas d’un article de blog, pas d’une note technique d’éditeur : de gens qui ont installé Procmon un dimanche pour comprendre pourquoi leur logiciel ne démarrait plus.
Le fil principal, #76357, ouvert le 10 juillet 2026 :
| Mesure | Valeur au 26/08/2026 |
|---|---|
| Durée de vie | 46 jours |
| Commentaires | 31 |
| Contributeurs distincts | 26 |
| Caractères écrits par les utilisateurs | 110 584 |
| Caractères écrits par Anthropic | 19 |
| Ratio | 5 820 pour 1 |
| Réponse technique de l'éditeur | aucune |
Les 19 caractères, dans leur intégralité : duplicate of #53247.
Pour donner l’échelle, 110 584 caractères représentent environ 18 000 mots, une soixantaine de pages. Des journaux horodatés, des captures Procmon, des tableaux d’hypothèses éliminées une par une, les empreintes de 2 817 fichiers.
Le ticket désigné comme l’original, #53247, est ouvert depuis le 25 avril 2026. Il compte 25 commentaires, 98 190 caractères écrits par des utilisateurs, et zéro réponse d’Anthropic. Il était encore actif le matin du 26 août.
Fermer #76357 en doublon de #53247 n’a donc corrigé aucun bug et n’a répondu à personne. Ça a déplacé 26 personnes d’une file d’attente sans réponse vers une autre file d’attente sans réponse, plus ancienne de trois mois.
Pour situer le décor : au 26 août 2026, le dépôt compte 410 tickets ouverts portant à la fois les étiquettes platform:windows et area:desktop, sur 1 419 au total depuis l’origine. Je ne prétends pas qu’ils soient tous graves. Je constate un ordre de grandeur, et un seul compte qui passe en triage.
Le cercle vicieux, étape par étape
Le plus instructif n’est pas le silence. C’est le mécanisme qui le produit, et il est documenté dans les tickets eux-mêmes.
Un bot menace. Trois heures après l’ouverture de #51143, le ticket qui décrit exactement l’écran blanc de mon dépannage, un robot commente : trois doublons possibles trouvés, fermeture automatique dans trois jours. Charge à l’utilisateur de prouver, sous 72 heures, que son bug est original.
Les anciens tickets sont verrouillés. L’auteur du ticket #65341 explique dans son propre rapport que le problème a déjà été signalé cinq fois, dans cinq tickets tous verrouillés ou fermés, et que ces tickets lui demandaient d’en ouvrir un nouveau. Ce qu’il a fait.
Le nouveau ticket est classé invalide. #65341 contenait pourtant un diagnostic à trois causes, un contournement complet écrit en PowerShell et résistant aux mises à jour, un tableau de six approches testées et écartées, et une demande raisonnable : ajouter un bouton « désactiver l’accélération matérielle » dans les réglages, comme le font Discord, VS Code et Slack. Fermé en trois jours, étiquette invalid.
Les tickets restants meurent de vieillesse. Deux d’entre eux portent l’étiquette stale. L’un n’a jamais reçu un seul commentaire.
Le fil vivant est fermé en doublon vers un fil mort. C’est le 25 août, à 14h23 UTC. Une minute plus tard, le même compte ferme #88962 avec la même phrase.
Au bout du compte, des gens qui produisent un travail de forensique digne d’un rapport d’incident professionnel n’ont, à ce jour, obtenu aucune réponse technique. Pas un merci, pas un « on regarde », pas un numéro de ticket interne.
Ma part, et mes erreurs dedans
J’ai écrit trois commentaires sur ce fil, et je ne vais pas me donner le beau rôle.
Le 26 juillet, j’ai décrit la variante du symptôme sur ma machine : l’application désenregistrée pour l’utilisateur courant, disparue du menu Démarrer, avec la cause capturée en direct par une tâche déclenchée sur événement.
Le 27 juillet, j’ai posé la chronologie qui explique le décalage de 24 heures, celle qui montre trois Register enregistrés comme réussis et un drapeau qui n’a pas bougé. Deux pannes distinctes se cachaient derrière un seul titre, et le fil les confondait.
Le 24 août, j’ai signalé le piège que le fil était en train de creuser lui-même. Tout le monde conseillait de désactiver le service (Start=4). Or Start=4 casse l’activation de l’application encore plus sûrement que le bug d’origine, tout en affichant un paquet en parfait état. J’ai perdu un après-midi entier le 30 juillet à diagnostiquer un verrou système qui était en réalité mon propre sabotage : cinq réenregistrements réussis d’affilée, application toujours non lançable. La valeur correcte est Start=3, démarrage manuel.
Et une correction publique, aussi. Mes deux premiers commentaires décrivaient l’erreur 0x80070020 comme un verrou de fichier tenu par le service. Le fil a prouvé que c’était faux : au Procmon, aucun handle ne tient le fichier. Mon remède marchait, mon explication était fausse. J’ai corrigé en public le 24 août.
C’est ce qui sépare un fil technique d’un fil de récriminations : les gens s’y corrigent. Et c’est ce qui donne le droit de reprocher un silence à quelqu’un d’autre.
Vingt et une heures après ce troisième commentaire, le fil était fermé.
Ce qui rend cette fermeture indéfendable
Trois faits, à poser côte à côte.
Le bug n’est pas corrigé. Il a été reproduit le 26 août sur la version 1.37937.1, la plus récente, par un utilisateur qui le documentait pour la troisième fois en cinq jours.
Le ticket « original » ne mène nulle part : quatre mois, zéro réponse de l’éditeur, et son dernier commentaire en date est un utilisateur qui publie son propre script de dépannage, écrit avec une IA, parce que personne d’autre ne le fera.
Et le travail fourni était exploitable tel quel : le correctif de quelques lignes est décrit, argumenté et posé sur la table depuis le 19 août.
Je ne dis pas qu’Anthropic ne fait rien en interne. Je n’en sais rien, et personne à l’extérieur n’en sait rien. Ce que je peux écrire, c’est que rien n’a été dit publiquement aux gens qui ont fourni le diagnostic, et que le bug est toujours là quatre mois après.
Je le dis aussi dans l’autre sens, parce que ça compte : Claude fonctionne, Claude Code fonctionne, claude.ai fonctionne. J’utilise ces outils tous les jours, ils sont dans mon atelier de freelance et je ne compte pas m’en passer. Ce qui casse, c’est la chaîne d’empaquetage Windows de l’application de bureau. Rien d’autre.
Écran blanc sur Claude Desktop sous Windows : le protocole qui marche
Passons à la partie utile. Ce protocole est reconstruit à partir des remèdes publiés par des utilisateurs sur les tickets publics et de ce que j’ai vérifié le 26 août 2026 sur une machine Windows à jour. Suivez l’ordre, il est classé par probabilité, pas par difficulté. Et ne désinstallez rien avant l’étape 5.
Étape 0 : lisez le journal, toujours en premier
L’application écrit un fichier main.log qui nomme la cause. Dans les cas de blocage réseau, on y lit littéralement :
[info] Failed to load URL: https://claude.ai/
{ errorCode: -356, errorDescription: 'ERR_QUIC_PROTOCOL_ERROR' }
[warn] [buddy-ble] mainView not ready: Timed out waiting for mainView to become readyTrois lignes, et le diagnostic est fait. Ce fichier se cache à trois endroits différents selon la version installée, d’où cette commande à coller dans PowerShell (touche Windows, taper powershell, Entrée) :
Get-ChildItem "$env:LOCALAPPDATA\Claude\Logs\main.log", `
"$env:APPDATA\Claude\logs\main.log", `
"$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\main.log" `
-ErrorAction SilentlyContinue | Select-Object FullName, LastWriteTime, Length
# puis, sur le fichier trouve :
Get-Content "<le chemin>" -Tail 60Ce que vous y cherchez :
| Si le journal contient | La cause est | Aller à |
|---|---|---|
ERR_QUIC_PROTOCOL_ERROR ou ERR_CONNECTION_* | le réseau | étape 2 |
ERR_CERT_DATE_INVALID ou une erreur de certificat | l'horloge | étape 1 |
mainView not ready seul, sans erreur réseau | l'affichage ou le cache | étape 3 |
| rien du tout, journal vide ou absent | l'application meurt avant d'écrire | étape 5 |
Étape 1 : l'horloge, 30 secondes
Réglages, puis Heure et langue, puis Date et heure. Vérifiez que « Régler l’heure automatiquement » et « Définir le fuseau horaire automatiquement » sont activés, et cliquez sur « Synchroniser maintenant ».
Un décalage de quelques minutes suffit à faire refuser les certificats de sécurité, donc à empêcher la page de se charger, donc à produire un écran blanc. Un utilisateur de #51143 a résolu son cas exactement comme ça.
Étape 2 : le réseau, 5 minutes
L’application de bureau est un navigateur déguisé : elle affiche le site de Claude dans une fenêtre sans barre d’adresse. Si la page ne charge pas, il n’y a rien à dessiner, et le cadre reste blanc. La différence avec votre navigateur habituel, c’est qu’un vrai navigateur sait retomber sur l’ancien protocole réseau quand le moderne est bloqué. L’application, non : elle attend, sans rien dire.
Dans l’ordre, en relançant Claude après chaque test :
- Antivirus tiers. Kaspersky, ESET, Norton, Avast et consorts filtrent souvent le protocole QUIC. Désactivez-le temporairement. Si ça règle le problème, le remède permanent est d’ajouter Claude en exception, pas de laisser l’antivirus éteint.
- VPN. Coupez-le.
- DNS personnalisé. Repassez en automatique. Un utilisateur de #51143 a débloqué son écran blanc, sur l’application et dans son navigateur, uniquement en retirant son DNS.
- Partage de connexion depuis un téléphone. Si l’application marche en 4G et pas sur la box, le problème est la box, pas le PC. Test rapide et très parlant.
- Forcer l’abandon de QUIC. Si le journal montre
ERR_QUIC_PROTOCOL_ERROR, bloquez l’UDP sortant sur le port 443 pour Claude dans le pare-feu Windows. Pas dans l’application : la version empaquetée ignore les fichiers d’options habituels.
Étape 3 : les caches, aux deux emplacements
Fermez Claude complètement d’abord, et vérifiez dans le gestionnaire des tâches qu’aucun processus Claude ne survit.
$cibles = @(
"$env:APPDATA\Claude\GPUCache",
"$env:APPDATA\Claude\Local Storage",
"$env:APPDATA\Claude\DawnCache",
"$env:APPDATA\Claude\DawnWebGPUCache",
"$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\GPUCache",
"$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\Local Storage"
)
foreach ($c in $cibles) {
if (Test-Path $c) { Remove-Item $c -Recurse -Force -ErrorAction SilentlyContinue; "supprime : $c" }
else { "absent : $c" }
}Les deux emplacements, c’est le piège de cette étape. Selon la version, les données sont dans %APPDATA%\Claude ou redirigées dans un chemin enfoui sous %LOCALAPPDATA%\Packages\. Plusieurs utilisateurs n’ont débloqué leur écran blanc qu’en vidant le second, après avoir vidé le premier sans résultat.
Et regardez ce que le script affiche. Il dit ce qu’il a réellement supprimé, ligne par ligne. Un script de nettoyage qui ne dit pas ce qu’il a trouvé ne prouve rien.
Étape 4 : l'affichage, en dernier
- HDR : Réglages, Système, Affichage, désactiver le HDR. Relancer.
- Pilote graphique : sur un portable de marque, prenez le pilote du constructeur correspondant au modèle, pas le pilote générique Intel ou NVIDIA.
- Préférence GPU : pour une application empaquetée, le sélecteur classique « Parcourir » ne peut pas atteindre le dossier, qui est protégé par le système. Il faut passer par « Ajouter une application », puis « Application Microsoft Store », et chercher Claude dans la liste déroulante. Si Claude n’y apparaît pas, n’ajoutez surtout pas « Microsoft Store » à la place : ça ne règle rien et ça ajoute une entrée sans effet. C’est l’erreur numéro 9 de mon tableau.
Étape 5 : la désinstallation propre, si tout le reste a échoué
Séquence publiée par un utilisateur de #76357, à respecter exactement. L’ordre compte : si vous réinstallez avant de supprimer le dossier de données, le paquet se réenregistre et le problème revient identique.
# 1. Retirer le paquet Get-AppxPackage *Claude* | Remove-AppxPackage # 2. Verifier qu'il n'en reste rien (ne doit rien afficher) Get-AppxPackage *Claude* # 3. Verifier que le service a disparu (doit dire qu'il n'existe pas) sc.exe query CoworkVMService
Redémarrez le PC. Puis, avant de lancer ou d’installer quoi que ce soit :
Remove-Item "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force -ErrorAction SilentlyContinue Remove-Item "$env:APPDATA\Claude" -Recurse -Force -ErrorAction SilentlyContinue Remove-Item "$env:LOCALAPPDATA\Claude" -Recurse -Force -ErrorAction SilentlyContinue
Ensuite seulement, relancez le programme d’installation officiel.
Cette étape supprime les conversations stockées localement. Sur un compte en ligne, l’historique est côté serveur et revient après reconnexion, mais autant le savoir avant.
Deux pièges à connaître ici. L’erreur 0x80073CF1, celle qui m’est tombée dessus, signifie « paquet introuvable » : Windows ne retrouve plus le paquet qu’il est censé désinstaller, sa base d’état est désynchronisée. Le remède est la séquence ci-dessus, avec le redémarrage obligatoire entre le retrait et le nettoyage, parce que c’est le redémarrage qui libère ce que les commandes ne peuvent pas atteindre. Second piège, signalé par un utilisateur de #76357 : lancer le programme d’installation sur un paquet déjà enregistré ne réinstalle pas, ça met à jour sur place, c’est-à-dire exactement l’opération qui échoue. On croit avoir réinstallé trois fois. On n’a peut-être jamais réinstallé. L’indice qui tranche : si le nom complet du paquet est inchangé après coup, il n’y a pas eu de réinstallation.
Étape 6 : si rien ne marche
L’abonnement Pro fonctionne parfaitement sur claude.ai dans un navigateur. Aucune installation, aucun paquet, aucun service en arrière-plan, et donc aucun de ces bugs. Même IA, même compte, mêmes conversations.
Ce qu’on perd en restant dans le navigateur : l’accès aux fichiers locaux et les fonctions qui dépendent de l’application de bureau. Pour la grande majorité des usages, ça ne change rien au quotidien.
personne ne devrait résilier un abonnement à cause d'un empaqueteur Windows défaillant.
Trois leçons qui valent bien au-delà de Claude
Sortons du cas. Ce dépannage raté résume ce que j’essaie de transmettre en formation depuis des années.
Le message d’erreur est une piste, pas un diagnostic. « Un autre programme utilise ce fichier » a envoyé des centaines de personnes chasser un processus qui n’existe pas. Chez nous, l’écran blanc a envoyé deux personnes sur le pilote graphique pendant une soirée. Le message décrit ce que le système croit, pas ce qui se passe.
« Réussi » ne veut pas dire « ça a marché ». Trois réenregistrements enregistrés comme réussis, et l’état de la machine n’avait pas bougé d’un pouce. Mon script de nettoyage affichait « terminé » en ayant vidé un dossier qui n’existe pas sur les installations modernes, celui de l’ancien programme d’installation. Il tournait, il annonçait le succès, il ne supprimait rien. C’est la même famille d’erreur, et c’est pour ça que le script de l’étape 3 imprime ligne par ligne ce qu’il a trouvé. Un outil qui ne montre pas son travail ne prouve rien. C’est la même exigence que celle qui structure mon agent de diagnostic Windows : mesurer avant, mesurer après, afficher l’écart. Et c’est la même que dans mon guide d’entretien de Windows, où chaque geste se vérifie.
Le support fait partie du produit. On peut acheter le meilleur modèle d’IA du marché et se retrouver sans logiciel, sans réponse, avec un lien vers un ticket de quatre mois. Quand vous choisissez un outil pour votre entreprise, la question n’est pas seulement « est-ce qu’il est bon », mais « qu’est-ce qui se passe le jour où il casse ». C’est valable pour l’IA, pour votre hébergeur, pour votre logiciel de caisse.
Je répare des machines depuis 1995, quand mon premier disque dur est mort à Noël et m’a valu le surnom de Norton. La partie du travail qui n’a pas changé depuis, c’est celle-là : ouvrir le journal avant de cliquer.
Pendant que je publiais, ça m'est retombé dessus
Cinquième fois en un mois. Le lendemain de la fermeture du ticket principal, sur la version qu'un autre utilisateur signalait le matin même. Et avec un mécanisme que je n'avais pas vu venir.
À 10h46, la version 1.37937.1.0 s'installe proprement en 34 secondes. Elle fonctionne. À 12h11, sans que personne ne demande quoi que ce soit, Windows lance de lui-même une réparation d'enregistrement sur 1.37937.0.0 : la version précédente, celle qui n'est plus là. Une seconde plus tard, échec, et le paquet sain d'à côté se retrouve marqué « modifié, nécessite une remise en état ».
Windows réparait l'enregistrement d'une version qui n'existait plus, et c'est cette réparation inutile qui a cassé l'installation qui marchait. Ce n'est ni le cas « désenregistré » ni le verrou noyau décrits plus haut. C'est un troisième chemin de panne : l'auto-réparation qui vise une cible périmée.
Deux détails qui valent d'être notés. Seuls deux processus Claude tournaient à cet instant, ce qui achève d'écarter la thèse du « fermez tout et ça ira ». Et la récupération a pris 13 secondes : arrêt du service, trois processus résiduels terminés, réenregistrement de la version courante, test de lancement réel. Aucun redémarrage, aucune réinstallation, et pas un octet retéléchargé là où les quatre fois précédentes m'avaient coûté 246 Mo chacune.
Ça confirme deux choses que le fil disait et que je rapportais au conditionnel. Le déclencheur n'est pas la mise à jour nocturne : à midi, c'est Windows qui a lancé l'opération tout seul. Et l'événement 573 relevé à 12h11, « nom de la famille de packages Claude_pzs8sxrjxfjjc, activé false », est la trace exacte que réclame le ticket #82277, dont le titre dit que la maintenance du paquet désactive le paquet pendant qu'il tourne. Ce ticket-là est ouvert. C'est la seule bonne raison d'y retourner : pour y déposer une preuve que personne n'a encore, pas pour se plaindre une fois de plus.
Questions fréquentes
- Claude affiche un écran blanc sous Windows, que faire en premier ?
- Ouvrez le journal
main.logavant toute autre chose (étape 0 ci-dessus). Il nomme la cause dans la plupart des cas. Ensuite seulement : l'horloge, le réseau, les caches. L'affichage et la réinstallation viennent en dernier, dans cet ordre, parce que ce sont les causes les plus rares et les plus destructrices à tester. - L'application a disparu de mon menu Démarrer sans que je la désinstalle. C'est normal ?
- Non, mais c'est documenté. Une mise à jour ratée peut désenregistrer l'application pour votre compte utilisateur, alors que les fichiers sont toujours sur le disque. Ça donne l'illusion d'une désinstallation. Un redémarrage la ramène parfois. Sinon, la séquence de l'étape 5 remet tout d'aplomb.
- Le bouton « Réparer » de Windows ne marche pas. Pourquoi ?
- Parce que sa première phase rallume le service en arrière-plan de l'application, et que sa seconde phase échoue à cause de ce service. 419 millisecondes séparent les deux, journaux à l'appui. Cliquer plusieurs fois finit parfois par passer, par pure chance de synchronisation.
- Est-ce que je dois résilier mon abonnement Claude ?
- Non. Le service web sur claude.ai n'est pas concerné du tout : même compte, même IA, mêmes conversations, sans installation ni paquet Windows. Ce qui casse ici, c'est l'application de bureau et sa chaîne d'empaquetage.
- Ce bug touche-t-il aussi Claude Code ?
- Le fil de discussion contient des rapports d'agents tués sans trace de plantage sous Windows, sur un ticket distinct qui reste ouvert. Mais le nœud décrit plus haut concerne l'application de bureau et son conteneur. L'outil en ligne de commande n'est pas empaqueté de la même façon.
- Pourquoi ne pas simplement désactiver le service en arrière-plan ?
- Parce que ça se retourne contre vous. Mettre le service en désactivé (
Start=4) casse l'activation de l'application encore plus sûrement, tout en affichant un paquet en parfait état. J'ai perdu un après-midi sur ce piège. La valeur correcte estStart=3, démarrage manuel. Et même là, le service porte un déclencheur qui le rallume dès que l'application le sollicite.
Un outil, ce n'est pas qu'un abonnement
Je forme des dirigeants et des équipes à l'IA, et cette histoire est devenue mon exemple préféré. On compare les modèles, les prix, les fonctions. On ne regarde presque jamais ce qui se passe le jour où ça casse : qui répond, en combien de temps, et avec quels mots. Le support fait partie du produit.
06 61 75 64 98 Mettre l'IA au travail Assistance et dépannage La veille IA du moisanthropics/claude-code. Ils bougeront. Les tickets cités sont publics et consultables sans compte. Je ne nomme personne : le compte qui a fermé les fils fait du triage sur un dépôt qui compte 410 tickets Windows ouverts, et le problème est d'organisation, pas de personne. Une question, une correction, un cas voisin ? écrivez-moi.
