Vous cliquez sur l’icône. Rien. Ou la fenêtre clignote une demi-seconde comme si elle était timide, puis disparaît. Vous réessayez. Toujours rien. Maintenant vous négociez avec la barre des tâches.
C’est le moment où un mauvais conseil fait perdre du temps : « réinstallez juste » est parfois juste, souvent faux, et parfois catastrophique. Réparer, réinitialiser et réinstaller sont trois outils différents avec trois rayons d’impact différents. Si vous les traitez comme interchangeables, vous perdrez des données ou vous « réparerez » l’application alors que le vrai problème continue de couver en dessous.
Réparer vs réinitialiser vs réinstaller : le modèle mental
Quand les gens disent « l’application ne s’ouvre pas », ils décrivent un symptôme, pas un diagnostic. Votre travail est de choisir la plus petite action qui supprime la cause. Dans les systèmes de production, on appelle cela « minimiser le rayon d’impact ». Même principe sur un portable.
Réparer : corriger l’installation sans supprimer l’état utilisateur
Réparer signifie : vérifier les fichiers installés de l’application, les permissions et les composants enregistrés ; remplacer les éléments manquants/corrompus ; laisser les données utilisateur et la plupart des configurations intactes.
- Idéal pour : binaires corrompus, dépendances manquantes, enregistrement cassé, mises à jour partielles.
- Risque : faible. La « maison » de l’application est reconstruite ; vos « meubles » restent généralement.
- Quand ça échoue : lorsque le problème se situe dans l’état utilisateur (mauvaise config, cache corrompu, migration bloquée) ou à l’extérieur de l’application (disque plein, politique OS, malware, magasin de certificats, pilote GPU).
Réinitialiser : supprimer l’état local pour qu’il soit reconstruit
Réinitialiser signifie : effacer l’état local de l’application (paramètres, cache, base de données locale, jetons), puis repartir comme si l’application était lancée pour la première fois pour ce profil utilisateur.
- Idéal pour : crash au démarrage causé par une config corrompue, un cache défectueux, une base locale cassée, un état de connexion bloqué.
- Risque : moyen. Si l’application stockait des données localement (notes, téléchargements, mail hors ligne, coffre local), la réinitialisation peut les détruire.
- Quand ça échoue : lorsque l’installation est cassée, ou que la défaillance est externe (OS, pilotes, permissions, politique réseau).
Réinstaller : supprimer puis réinstaller (parfois en laissant l’état)
Réinstaller devrait vouloir dire : désinstaller l’application, supprimer les composants liés, puis installer proprement. En pratique, la « désinstallation » peut laisser de l’état (par conception ou bug), et l’« installation » peut réutiliser des paquets mis en cache.
- Idéal pour : installations irrécupérables, mises à jour cassées, versions incompatibles, problèmes d’empaquetage, ou quand vous devez changer de canal de distribution (store vs standalone).
- Risque : variable. Certains désinstalleurs sont polis ; d’autres sont destructeurs.
- Quand ça échoue : lorsque la cause racine est extérieure à l’application ou quand la réinstallation réutilise le même état corrompu.
Voici la dure vérité : une réinstallation n’est pas un diagnostic. C’est un pari à latence élevée. Parfois ça marche parce qu’elle réinitialise l’état par accident, ou parce qu’elle installe une build plus récente qui évite un crash connu. Ce n’est pas une stratégie ; c’est la roulette avec plus de barres de progression.
Idée paraphrasée (attribuée) : l’état d’esprit de l’ère Apollo de Gene Kranz se résume souvent par « dur et compétent ». C’est une posture utile ici : calme, méthodique, sans gesticulations.
Procédure de diagnostic rapide (vérifier d’abord/puis/ensuite)
Voici la séquence que j’utilise quand une application « ne s’ouvre pas » et que je veux des réponses en moins de dix minutes. Elle est optimisée pour la vitesse et le signal.
Première étape : confirmer ce que signifie « ne s’ouvre pas »
- Le processus démarre-t-il du tout ? S’il ne démarre jamais, pensez : exécution bloquée, dépendance manquante, politique, installation cassée.
- Il démarre puis se termine immédiatement ? Pensez : crash à l’initialisation, config corrompue, plugin incompatible, bibliothèque manquante, GPU/driver.
- Il se bloque ? Pensez : interblocage, attente réseau, mise à jour/migration bloquée, base locale verrouillée, latence du système de fichiers.
Deuxième étape : trouver la première erreur réelle
- Vérifiez les logs (logs de l’app, logs OS, rapports de crash). Vous voulez la première exception, pas la dernière plainte.
- Vérifiez l’espace disque et les erreurs de système de fichiers. Un nombre surprenant de problèmes « l’application ne s’ouvre pas » sont en réalité des problèmes « impossible d’écrire la config ».
- Vérifiez les permissions sur les répertoires de configuration de l’app. La corruption du profil utilisateur est ennuyeuse et courante.
Troisième étape : choisir le plus petit marteau
- Si les fichiers d’installation sont manquants/corrompus → Réparer.
- Si l’état utilisateur est corrompu/bloqué → Réinitialiser (mais sauvegardez d’abord).
- Si l’empaquetage/la mise à jour est cassé ou vous avez besoin d’un canal propre → Réinstaller (proprement, y compris l’état résiduel si besoin).
Une règle opérationnelle : ne faites pas deux actions destructrices en même temps. Si vous réinitialisez et réinstallez dans une frénésie, vous ne saurez jamais laquelle a réellement réparé—et vous n’aurez aucune histoire de retour en arrière.
Ce qui tombe réellement en panne quand une application ne s’ouvre pas
Les applications échouent à se lancer pour quelques raisons répétables. Si vous pouvez classer le mode de défaillance, vous choisirez plus vite la bonne réparation.
1) L’exécutable ne peut pas s’exécuter
Causes fréquentes : bibliothèques runtime manquantes, blocage par politique, vérifications de signature échouées, quarantaine antivirus, ou architecture incorrecte (essayer d’exécuter x86 sur un environnement ARM sans traduction).
2) L’application démarre, puis plante pendant l’initialisation
Causes fréquentes : fichier de configuration corrompu, plugin défectueux, GPU/driver incompatible, instruction CPU non supportée, mauvaise mise à jour qui a changé un schéma et dont la migration échoue.
3) L’application démarre, puis attend indéfiniment
Causes fréquentes : attente réseau (proxy, portail captif, interception TLS), tâches de démarrage en interblocage, base locale verrouillée, mise à jour automatique bloquée, latence du système de fichiers, ou mauvais comportement DNS.
4) L’application « s’ouvre » mais l’interface n’apparaît jamais
Causes fréquentes : problèmes du gestionnaire de fenêtres, fenêtres fantômes sur multi-écrans, coordonnées de fenêtre sauvegardées incorrectes, ou échecs du backend de rendu.
5) Tout va bien, sauf votre profil utilisateur
Répertoires de profil corrompus, mauvaise propriété, ou synchronisation de profil itinérante cassée peuvent faire paraître une installation saine comme cassée. C’est là que la réinitialisation aide—mais ce n’est pas toujours la faute de l’application.
Blague #1 : Réinstaller une application sans regarder les logs, c’est comme redémarrer un routeur pour réparer votre mariage—parfois quelque chose change, mais vous n’avez rien appris.
Tâches pratiques (commandes, sorties, décisions)
Ci-dessous des tâches réelles que vous pouvez exécuter. Chaque tâche inclut : une commande, ce que la sortie signifie généralement, et la décision à prendre. J’utilise des exemples Linux parce que l’outillage est cohérent et scriptable—mais la logique diagnostique s’applique partout. Si vous êtes sur Windows ou macOS, l’équivalent est « vérifier le processus, vérifier les logs, vérifier les permissions, vérifier le disque. » Même film, acteurs différents.
Task 1: Confirm the process exists (or dies immediately)
cr0x@server:~$ ps aux | grep -i 'myapp' | grep -v grep
cr0x 24891 0.1 0.4 1245672 69012 ? Sl 10:14 0:00 /opt/myapp/myapp --foreground
Ce que cela signifie : Le processus est vivant. Si les utilisateurs disent « ne s’ouvre pas », vous avez probablement affaire à l’UI/l’affichage, à un blocage, ou à une instance qui tourne en arrière-plan uniquement.
Décision : S’il fonctionne, ne réinstallez pas encore. Passez aux logs et à l’analyse du blocage.
cr0x@server:~$ ps aux | grep -i 'myapp' | grep -v grep
Ce que cela signifie : Rien ne tourne. Soit il n’a jamais démarré, soit il a démarré et s’est terminé rapidement.
Décision : Lancez-le depuis un terminal pour capturer stderr (Task 2) et inspectez les logs (Task 3).
Task 2: Launch from terminal to catch immediate errors
cr0x@server:~$ /opt/myapp/myapp
error while loading shared libraries: libXss.so.1: cannot open shared object file: No such file or directory
Ce que cela signifie : Dépendance de bibliothèque partagée manquante. C’est un problème d’installation/dépendance, pas « mauvaises options ».
Décision : Réparer via le gestionnaire de paquets ou installer la bibliothèque manquante. La réinitialisation n’aidera pas.
Task 3: Read recent system logs for crash signatures
cr0x@server:~$ journalctl --user -u myapp.service -n 100 --no-pager
Feb 05 10:16:03 host myapp[25010]: FATAL: config parse error at line 14: unexpected token
Feb 05 10:16:03 host systemd[1560]: myapp.service: Main process exited, code=exited, status=1/FAILURE
Ce que cela signifie : L’application se termine parce qu’elle ne peut pas analyser la configuration. C’est un mode de défaillance lié à l’état utilisateur.
Décision : Sauvegardez la configuration, puis réinitialisez ou corrigez la configuration de manière chirurgicale (ne réinstallez pas).
Task 4: Identify missing libraries and their source
cr0x@server:~$ ldd /opt/myapp/myapp | grep -i 'not found'
libXss.so.1 => not found
libnss3.so => /lib/x86_64-linux-gnu/libnss3.so (0x00007f2c2c000000)
Ce que cela signifie : Une dépendance est manquante. Cela arrive souvent après des mises à jour partielles, des conteneurs minimaux, ou après avoir retiré des libs de bureau sur des serveurs.
Décision : Installez le paquet fournissant cette bibliothèque ; préférez réparer plutôt que réinstaller.
Task 5: Confirm disk space (the silent assassin)
cr0x@server:~$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p2 100G 99G 200M 100% /
Ce que cela signifie : Le disque est plein. Les applications échouent à se lancer car elles ne peuvent pas écrire de logs, caches, fichiers temporaires, journaux SQLite, ou fichiers de verrouillage.
Décision : Libérez d’abord de l’espace. Réparer/réinitialiser/réinstaller avant d’avoir libéré de l’espace ne fait que remuer et peut aggraver la corruption.
Task 6: Check inode exhaustion (yes, that’s a thing)
cr0x@server:~$ df -i /home
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda2 6553600 6553500 100 100% /home
Ce que cela signifie : Vous êtes à court d’inodes—trop de petits fichiers. Certaines applications créent des montagnes de petits fichiers de cache.
Décision : Nettoyez les répertoires de cache et temporaires. La réinitialisation peut aider si le cache de l’application est le consommateur d’inodes.
Task 7: Check ownership/permissions on config directories
cr0x@server:~$ ls -ld ~/.config/myapp ~/.cache/myapp
drwx------ 2 root root 4096 Feb 5 10:00 /home/cr0x/.config/myapp
drwx------ 2 root root 4096 Feb 5 10:01 /home/cr0x/.cache/myapp
Ce que cela signifie : Ces répertoires sont possédés par root. L’application s’exécutant en utilisateur ne peut pas y écrire, donc elle échoue ou a un comportement étrange.
Décision : Corrigez la propriété (Task 8). Ne réinitialisez pas tant que les permissions ne sont pas correctes, ou vous créerez davantage d’état cassé.
Task 8: Fix ownership cleanly
cr0x@server:~$ sudo chown -R cr0x:cr0x /home/cr0x/.config/myapp /home/cr0x/.cache/myapp
Ce que cela signifie : Propriété corrigée.
Décision : Retentez le lancement. Si ça échoue encore, inspectez le contenu de la config ; maintenant les réinitialisations sont relativement sûres.
Task 9: Find and quarantine a corrupt config (surgical reset)
cr0x@server:~$ mv ~/.config/myapp/config.json ~/.config/myapp/config.json.bak
Ce que cela signifie : Vous avez préservé le fichier mais l’avez retiré du chemin attendu par l’application.
Décision : Lancez l’application. Si elle démarre, vous avez trouvé le coupable. Comparez la nouvelle config avec la sauvegarde et migrez les paramètres avec précaution.
Task 10: Catch hangs with a quick syscall trace
cr0x@server:~$ strace -f -tt -o /tmp/myapp.strace /opt/myapp/myapp
Ce que cela signifie : Vous avez capturé les appels système dans un fichier. C’est ainsi que vous découvrez ce que l’application attend : DNS, verrous de fichiers, connect(), fichiers manquants.
Décision : Si elle se bloque, arrêtez-la et inspectez la fin du log (Task 11).
Task 11: Read the last syscalls to see what it’s stuck doing
cr0x@server:~$ tail -n 30 /tmp/myapp.strace
10:20:14.012345 connect(12, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("10.0.0.10")}, 16) = -1 ETIMEDOUT (Connection timed out)
10:20:19.013210 connect(12, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("10.0.0.10")}, 16) = -1 ETIMEDOUT (Connection timed out)
Ce que cela signifie : Il essaie de se connecter à un point interne et subit des timeouts. L’application n’est pas « cassée » ; elle attend la disponibilité réseau ou la bonne configuration du proxy.
Décision : Corrigez le réseau/proxy/DNS. Réinitialiser/réinstaller ne changera pas un timeout.
Task 12: Validate DNS quickly (because DNS is never boring)
cr0x@server:~$ getent hosts api.mycorp.internal
10.0.0.10 api.mycorp.internal
Ce que cela signifie : La résolution de nom fonctionne et renvoie une IP. Si cela échoue ou renvoie la mauvaise IP, votre application peut se bloquer au démarrage en essayant d’atteindre des services.
Décision : Si c’est faux/manquant, corrigez resolv.conf/systemd-resolved/VPN split DNS avant de toucher à l’app.
Task 13: Check for library/API mismatch in packaged apps
cr0x@server:~$ /opt/myapp/myapp --version
myapp 3.4.2 (glibc 2.35)
Ce que cela signifie : Le binaire attend un certain environnement runtime. Si vous avez déplacé l’installation d’une autre machine ou mis à jour partiellement l’OS, vous pouvez obtenir des incompatibilités subtiles.
Décision : Préférez réinstaller depuis le canal correct pour votre version d’OS ; la « réparation » peut ne pas résoudre un mismatch d’ABI.
Task 14: Confirm package integrity with the package manager
cr0x@server:~$ sudo dpkg -V myapp
??5?????? c /etc/myapp/myapp.conf
Ce que cela signifie : Le fichier de config diffère de la version empaquetée (le « c » l’indique). Ce n’est pas automatiquement mauvais, mais c’est un indice—surtout si l’app plante maintenant en analysant la config.
Décision : Examinez le diff de config ; si elle est corrompue, réinitialisez la config ou restaurez une version connue saine. N’effacez pas toute l’application sauf si les binaires échouent aussi à la vérification.
Task 15: Detect plugin poisoning (a common startup killer)
cr0x@server:~$ ls -1 ~/.local/share/myapp/plugins
spellcheck.so
theme-dark.so
thirdparty-exporter.so
Ce que cela signifie : Des plugins existent. Un plugin défectueux peut faire planter l’app au chargement.
Décision : Déplacez le répertoire de plugins à part et retentez.
cr0x@server:~$ mv ~/.local/share/myapp/plugins ~/.local/share/myapp/plugins.disabled
Ce que cela signifie : Vous avez effectué une réinitialisation non destructive de l’état des plugins.
Décision : Si l’app démarre, réactivez les plugins un par un pour trouver le coupable. Réinstaller l’app ne réparera pas un plugin utilisateur qui se recharge à chaque lancement.
Task 16: Verify filesystem health signals (when “won’t open” is corruption)
cr0x@server:~$ dmesg | tail -n 20
[ 9123.456789] EXT4-fs error (device nvme0n1p2): ext4_journal_check_start:83: Detected aborted journal
[ 9123.456800] Buffer I/O error on dev nvme0n1p2, logical block 1234567, lost async page write
Ce que cela signifie : Erreurs du système de fichiers. Les applications peuvent échouer aléatoirement, les configs devenir illisibles, SQLite se fâcher, et la « réparation » devient du tape-à-l’œil.
Décision : Stoppez et adressez le stockage : vérifiez SMART, exécutez fsck hors-ligne, vérifiez le disque sous-jacent. Réinitialiser/réinstaller, c’est du vernis sur un disque défaillant.
Task 17: Check disk health quickly (SMART)
cr0x@server:~$ sudo smartctl -H /dev/nvme0
SMART overall-health self-assessment test result: PASSED
Ce que cela signifie : Le statut de santé basique semble OK. Ce n’est pas une garantie, mais ça réduit les soupçons.
Décision : Si SMART échoue ou montre des secteurs réalloués/en attente (sur SATA), corrigez le matériel d’abord. Si ça passe, poursuivez le diagnostic au niveau de l’application.
Task 18: Capture a core dump/backtrace when the app crashes
cr0x@server:~$ coredumpctl list myapp | tail -n 3
TIME PID UID GID SIG COREFILE EXE
Wed 2026-02-05 10:16:03 UTC 25010 1000 1000 11 present /opt/myapp/myapp
Ce que cela signifie : Vous avez un crash avec un fichier core. C’est une preuve exploitable.
Décision : Si c’est une application gérée par l’entreprise, fournissez les détails de crash au fournisseur/équipe. Si c’est votre application, déboguez. Réinstaller ne corrigera pas un plantage déterministe sur le même chemin de code.
Erreurs fréquentes : symptôme → cause racine → correctif
Cette section est la liste « sauvez-vous le futur de vous-même ». Ce sont les schémas qui reviennent sans cesse.
1) Symptom: icône de l’app qui rebondit/tourne, puis rien
Cause racine : crash au démarrage dû à une config corrompue, un plugin défectueux, ou une bibliothèque runtime manquante.
Correctif : lancez depuis un terminal pour capturer la première erreur ; déplacez la config ou les plugins de côté ; installez la bibliothèque manquante ; puis réparez si l’intégrité du paquet est suspecte.
2) Symptom: l’app se lance mais reste bloquée sur « Chargement… »
Cause racine : attente réseau (proxy, interception TLS, DNS), ou verrou sur la base locale.
Correctif : vérifiez la résolution DNS et la connectivité ; inspectez strace pour des timeouts de connect() ; vérifiez l’absence de fichiers de verrou obsolètes ; ne réinitialisez que si la base est corrompue ou verrouillée.
3) Symptom: la réinstallation « a marché » hier, de nouveau cassée aujourd’hui
Cause racine : la désinstallation a laissé l’état utilisateur, et l’app réimporte la même config/cache cassé au premier lancement ; ou le vrai problème est l’environnement (disque plein, permissions, politique).
Correctif : corrigez d’abord l’environnement ; si nécessaire, effectuez une vraie réinitialisation de l’état de l’application (après sauvegarde), pas des réinstallations répétées.
4) Symptom: l’app s’ouvre pour l’admin/root mais pas pour l’utilisateur
Cause racine : permissions/propriété du profil utilisateur cassées, ou corruption de la config par utilisateur.
Correctif : auditez la propriété des répertoires config/cache ; créez un nouveau profil utilisateur pour confirmer ; réinitialisez l’état utilisateur une fois les permissions corrigées.
5) Symptom: l’app n’ouvre que hors ligne ou VPN déconnecté
Cause racine : problèmes de split DNS, proxy d’entreprise mal configuré, ou interception TLS qui casse le pinning de certificat.
Correctif : vérifiez les résultats DNS avec et sans VPN ; contrôlez les paramètres proxy d’entreprise ; si le pinning est en cause, il vous faut la chaîne de confiance correcte—réinitialiser l’app ne corrigera pas un homme-du-milieu que vous avez installé volontairement.
6) Symptom: l’app démarre mais annonce immédiatement « impossible d’écrire »
Cause racine : disque plein, système de fichiers monté en lecture seule, erreurs de permission, ou stockage défaillant.
Correctif : vérifiez df/df -i ; vérifiez dmesg ; corrigez le stockage et les permissions ; puis réparez si des fichiers ont été corrompus par des écritures échouées.
7) Symptom: après une mise à jour de l’OS, l’app ne s’ouvre plus du tout
Cause racine : mismatch ABI/bibliothèques, dépendances obsolètes, pile GPU incompatible.
Correctif : réinstallez en utilisant la build correcte pour le nouvel OS ; vérifiez les dépendances ; envisagez de désactiver l’accélération matérielle si c’est un crash de rendu.
8) Symptom: « Réparer » se termine mais l’app ne s’ouvre toujours pas
Cause racine : la réparation a touché les fichiers d’installation, mais la défaillance se situe dans l’état utilisateur ou l’environnement externe.
Correctif : passez à la réinitialisation (après sauvegarde de l’état) ou corrigez les causes externes (proxy, DNS, permissions, disque).
Listes de contrôle / plan étape par étape
Voici les plans que je remettrais à un ingénieur astreint ou à une équipe d’assistance qui veut des résultats répétables, pas de la sagesse populaire.
Checklist A: « Il me faut ça en 15 minutes » (chemin à risque minimal)
- Vérifiez l’espace disque (Task 5) et les inodes (Task 6). Si l’un ou l’autre est à 100%, arrêtez-vous et corrigez ça en premier.
- Vérifiez si le processus tourne (Task 1). S’il tourne, ce n’est pas « ne s’ouvre pas », c’est « ne s’affiche pas ». Cherchez les problèmes d’UI/fenêtres ou un processus d’arrière-plan bloqué.
- Lancez depuis un terminal (Task 2). Si vous obtenez « bibliothèque manquante », installez-la ; ne touchez pas à l’état utilisateur.
- Inspectez les logs pour la première erreur (Task 3). Les erreurs d’analyse de config et la corruption de DB sont des problèmes d’état utilisateur.
- Quarantinez config/plugins (Task 9, Task 15). C’est une mini-réinitialisation réversible.
- Ce n’est qu’ensuite que vous envisagez la réparation si les binaires/dépendances semblent incorrects ; envisagez la réinitialisation si l’état utilisateur est clairement corrompu.
Checklist B: « Je ne peux pas perdre de données » (sécuritaire d’abord, plus lent)
- Identifiez où l’app stocke son état : répertoire de config, répertoire cache, DB locale, téléchargements, contenu hors ligne.
- Sauvegardez-le avant toute réinitialisation/désinstallation. Copiez l’arborescence entière dans un dossier daté.
- Essayez la réparation d’abord si vous suspectez des binaires/dépendances manquants ou corrompus.
- Si la réinitialisation est nécessaire, faites-la chirurgicalement : déplacez un fichier/répertoire à la fois (config, puis cache, puis DB), retentez entre chaque étape.
- Réinstallez en dernier recours, et si vous réinstallez, vérifiez que la désinstallation n’a pas laissé d’état cassé que vous allez simplement réutiliser.
Checklist C: « Ça arrive à plusieurs utilisateurs » (réalité entreprise)
- Standardisez le symptôme : plante-t-il, se bloque-t-il, ou ne démarre-t-il pas ? N’acceptez pas « ça ne marche pas ».
- Corrélez le timing : mises à jour OS, mises à jour app, changements de politique, changements de proxy, changements de certificats, modifications de sync de profil.
- Choisissez une machine et capturez les logs + artefacts de crash (Task 3, Task 18).
- Vérifiez les baselines d’environnement : espace disque, permissions, quarantaines antivirus, règles de protection endpoint.
- Restaurez le changement si possible. Réparer/réinitialiser/réinstaller à grande échelle est un pansement ; corrigez la cause systémique.
Trois mini-histoires d’entreprise tirées du terrain
Mini-histoire 1 : L’incident causé par une mauvaise hypothèse
La marée de tickets a commencé à 09:07 : « L’application ne s’ouvre pas. » L’équipe desktop a supposé que c’était une mauvaise mise à jour du fournisseur poussée la nuit précédente. Hypothèse raisonnable. Mais fausse.
Un ingénieur a fait ce que font les ingénieurs sous pression : il a réinstallé l’app sur un portable test. Toujours rien. Ils l’ont réparée. Pareil. Puis ils ont essayé sur un réseau différent, et elle s’est lancée immédiatement. Là, l’ambiance est passée de « bug d’app » à « il y a un incendie dans notre environnement ».
La cause racine était un changement de configuration de proxy auto (PAC) ce matin-là. Le fichier PAC a commencé à renvoyer un proxy pour un domaine interne qui aurait dû être direct. L’app faisait du pinning de certificat vers son endpoint d’auth. Avec le proxy au milieu, le TLS échouait silencieusement dans un thread d’initialisation. Pas d’UI, pas de dialogue utile, juste un processus qui démarrait et se terminait comme s’il avait mieux à faire.
L’hypothèse erronée était que « ne s’ouvre pas » équivaut à « installation cassée ». La correction n’était ni réparation ni réinitialisation ni réinstallation. C’était une ligne à changer dans la logique PAC et la purge des caches proxy sur les machines affectées.
La leçon post-incident a été nette : la première question dans toute défaillance de démarrage est « quelle dépendance externe est touchée avant que l’UI ne s’affiche ? » Réseau et auth reviennent souvent. Réinstaller l’app ne supprime pas votre proxy.
Mini-histoire 2 : L’optimisation qui a mal tourné
Une équipe voulait accélérer les temps de connexion. Ils ont activé un nettoyage agressif des profils : effacer les caches au délogement et limiter la taille de la sync de profil itinérante. Sur le papier, c’était propre. En pratique, ça a transformé une app stable en roulette quotidienne.
L’app stockait une petite base locale dans le profil utilisateur et attendait une fermeture propre pour checkpoint l’état. Le job de nettoyage tournait au délogement et supprimait parfois les fichiers journaux de la DB alors que l’app quittait encore. Au prochain logon, l’app essayait de récupérer, échouait la vérification de consistance, et plantait à l’initialisation. Les utilisateurs décrivaient ça comme « ne s’ouvre pas ». Le support trouvait que « les utilisateurs sont dramatiques ». Les deux avaient tort d’une manière intéressante.
L’équipe a d’abord répondu par des réinstallations. Ça « réparait » pour le reste de la journée parce que l’app reconstruit la DB. Puis venait le délogement, le nettoyage tournait, et le cycle reprenait. Finalement, quelqu’un a regardé les horodatages : le job de nettoyage touchait le répertoire de profil de l’app quelques secondes après la dernière sortie du processus de l’app.
La correction a été ennuyeuse : ajouter une période de grâce et une liste blanche pour que le répertoire d’état de l’app ne soit pas supprimé. L’objectif d’optimisation était valide ; l’implémentation a brisé une hypothèse sur le cycle de vie des fichiers. L’app n’était pas fragile ; elle était normale. Les systèmes de fichiers ne sont pas transactionnels simplement parce qu’on le voudrait.
Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une autre organisation avait un script standard de « bundle de défaillance de démarrage » pour les postes gérés. Rien de sophistiqué : collecter stats disque, logs pertinents, présence de dumps de crash, paramètres proxy, et permissions sur les répertoires d’état connus. Il s’exécutait localement et produisait un petit rapport texte.
Un matin, une application interne très utilisée a commencé à ne plus s’ouvrir pour un sous-ensemble d’utilisateurs. L’équipe n’a pas fait de supputations. Ils ont demandé les sorties du bundle pour trois machines affectées et trois non affectées. En quelques minutes, le schéma était évident : les machines affectées avaient le volume système plein, mais pas le volume de données. L’app écrivait ses fichiers temporaires sur le volume système.
Parce que le rapport incluait à la fois la sortie df et le chemin exact utilisé par l’app pour les temporaires, l’équipe n’a pas perdu une demi-journée à débattre si réparer ou réinstaller était « bonne pratique ». Ils ont poussé une politique de nettoyage pour les répertoires temporaires et ajusté l’app pour utiliser un autre emplacement quand disponible.
L’app a recommencé à s’ouvrir sans une seule réinstallation. Voilà la valeur de la pratique ennuyeuse : vous avez raison rapidement, en public, pendant que les autres téléchargent encore des installateurs.
Faits intéressants & contexte historique
- « Réparer » est devenu courant avec les technologies d’installateur comme Windows Installer (MSI), qui peut valider les composants installés par rapport à une base de données de paquet et remplacer les fichiers manquants.
- « Réinitialiser » est essentiellement une purge d’état utilisateur qui reflète une réalité moderne : beaucoup d’apps sont des clients étatful avec caches, jetons et bases locales, pas seulement des binaires.
- Les désinstalleurs laissent souvent des données par conception pour éviter de supprimer des fichiers utilisateur. C’est poli—et c’est aussi pourquoi la « réinstallation » ne supprime parfois pas le problème.
- Le démarrage d’app s’est fragilisé en devenant plus ambitieux : initialisation de télémétrie, vérifs de mise à jour auto, négociation d’auth, et chargement de plugins se produisent maintenant avant la première peinture de fenêtre.
- SQLite est partout dans les applications de bureau. Quand une app « ne s’ouvre pas », c’est fréquemment une DB SQLite verrouillée ou corrompue qui bloque l’initialisation.
- L’accélération GPU est un récidiviste pour « s’ouvre puis se ferme ». Un bug de pilote peut planter le renderer avant l’affichage de l’UI, surtout après des mises à jour OS.
- Les fichiers PAC de proxy auto-configuration sont un mécanisme d’entreprise ancien ; de petits changements peuvent casser le démarrage d’app si l’app touche le réseau tôt.
- Les pannes liées au disque plein sont historiquement sous-déclarées car beaucoup d’apps ne remontent pas proprement « ENOSPC » ; elles échouent plus loin de façon étrange.
- Les formats de packaging modernes (comme MSIX, Flatpak, Snap) ont amélioré l’isolation mais introduit de nouveaux emplacements d’état et des modèles de permission—excellents pour la sécurité, déroutants pour le dépannage.
Blague #2 : Si votre application ne s’ouvre pas parce que le disque est plein, félicitations—vous avez inventé un nouveau type de stockage en écriture seule.
FAQ
1) Quelle est la chose la plus rapide et sûre à essayer quand une application ne s’ouvre pas ?
Vérifiez d’abord l’espace disque et les logs. Si le disque est plein, corrigez cela. Si les logs montrent une corruption de config, mettez la config en quarantaine (renommez-la) avant de faire une réinitialisation complète.
2) Quand devrais-je choisir Réparer plutôt que Réinitialiser ?
Choisissez Réparer lorsque les fichiers installés de l’app ou les dépendances sont cassés : bibliothèques manquantes, binaires corrompus, mises à jour ratées. Choisissez Réinitialiser lorsque l’app plante/se bloque à cause de l’état utilisateur : config fautive, cache corrompu, DB locale bloquée, plugins empoisonnés.
3) La réinstallation supprimera-t-elle mes documents/données dans l’app ?
Peut-être. Certaines apps stockent des documents dans des emplacements évidents (comme le dossier Documents). D’autres stockent des données dans le répertoire d’état de l’app. Les désinstalleurs peuvent laisser de l’état ou le supprimer. Sauvegardez les répertoires d’état de l’app avant de réinstaller si vous tenez aux données.
4) Pourquoi l’app s’ouvre pour un nouveau compte utilisateur mais pas pour mon compte ?
Cela indique fortement une corruption d’état utilisateur ou des problèmes de permissions dans votre profil. La réinitialisation (ou une réinitialisation chirurgicale) est généralement efficace, mais corrigez d’abord la propriété/les permissions.
5) Pourquoi une réinitialisation corrige-t-elle si souvent ?
Parce qu’une grande partie des échecs « l’app ne s’ouvre pas » surviennent avant que l’UI n’apparaisse : pendant l’analyse de config, le préchauffage du cache, le chargement de plugins, ou les migrations de DB locale. La réinitialisation supprime les entrées cassées pour ces étapes.
6) Pourquoi la réparation ne fait-elle parfois rien ?
La réparation est excellente pour restaurer les artefacts d’installation. Elle ne touche généralement pas votre profil utilisateur, qui est l’endroit où résident beaucoup de défaillances de démarrage. Si les logs incriminent la config/cache utilisateur, la réparation ne changera rien.
7) L’app se bloque au démarrage—comment savoir si c’est lié au réseau ?
Utilisez le traçage d’appels système ou les logs pour voir si l’app est bloquée sur des appels connect(). Si vous observez des timeouts répétés vers un hôte, corrigez DNS/proxy/firewall/VPN plutôt que de toucher à l’installation.
8) Comment éviter que cela se reproduise ?
Gardez de la marge sur le disque système, évitez les outils de nettoyage qui suppriment l’état actif des apps, et standardisez un petit bundle de diagnostic : statut des processus, stats disque, logs, et permissions sur les répertoires d’état. Prévenez la classe de panne, pas l’instance unique.
9) Est-il jamais correct d’aller directement à la réinstallation ?
Oui—lorsque vous avez une preuve claire d’un dommage d’empaquetage ou d’un mismatch ABI (après une mise à jour d’OS), ou lorsque les mécanismes de réparation ne sont pas disponibles. Mais faites-le proprement et intentionnellement, pas par réflexe.
10) Si une application ne s’ouvre pas après une mise à jour d’OS, quel est le coupable le plus probable ?
Les dépendances et pilotes : bibliothèques runtime modifiées, pile GPU changée, politiques de sécurité renforcées, ou incompatibilité de l’app. Vérifiez d’abord les logs ; puis réinstallez la build correcte pour le nouvel OS.
Prochaines étapes actionnables aujourd’hui
Si vous ne retenez qu’une chose : réparer corrige l’installation, réinitialiser corrige l’état utilisateur, réinstaller est le dernier recours et n’est pas un diagnostic. Vos victoires les plus rapides viennent de la vérification du disque, des logs, et de l’identification si le processus plante, se bloque, ou ne démarre pas.
Faites ceci, dans l’ordre :
- Vérifiez l’espace disque/les inodes. Corrigez cela d’abord si c’est serré.
- Lancez l’app depuis un terminal et lisez la première erreur.
- Inspectez les logs/rapports de crash pour des échecs de config ou de dépendances.
- Quarantinez config/plugins (réinitialisation réversible) avant une réinitialisation complète.
- Réparez lorsque les binaires/dépendances sont en cause ; réinstallez uniquement quand vous avez besoin d’un canal propre ou que la réparation ne restaure pas une installation saine.
C’est tout le jeu : réduisez les conjectures, choisissez le plus petit marteau, et préservez vos données. L’application s’ouvrira—ou vous aurez des preuves suffisantes pour que quelqu’un d’autre doive corriger le problème.