Transformez votre PC en machine auto‑réparatrice : SFC/DISM hors ligne planifiés

Ce que signifie réellement « SFC/DISM hors ligne » (et pourquoi ça marche)

SFC (System File Checker) vérifie les fichiers système protégés et remplace les versions incorrectes par des copies connues bonnes. DISM (Deployment Image Servicing and Management) répare le magasin de composants (WinSxS) dont dépend SFC. Lorsque le magasin de composants est malade, SFC ne peut pas toujours guérir parce qu’il ne trouve pas de pièces propres à greffer.

Les réparations en ligne s’exécutent pendant que Windows est démarré. C’est pratique, mais c’est aussi une chirurgie à vif où le patient se lève pour aller boire un café. Les fichiers sont en cours d’utilisation. Les composants de la pile de maintenance sont actifs. Les pilotes sont chargés. Un pilote de filtrage de votre suite de sécurité est « aidant ». Les réparations en ligne peuvent réussir, mais quand elles échouent, vous restez coincé dans une boucle de corrections partielles et de corruptions récurrentes.

Réparation hors ligne signifie que vous démarrez dans l’environnement de récupération Windows (WinRE) ou dans un OS de maintenance séparé, puis vous pointez SFC et DISM vers l’installation Windows sur le disque (l’« image hors ligne »). Le système ciblé n’est pas en cours d’exécution, donc les fichiers ne sont pas verrouillés et la pile de maintenance ne se marche pas sur les pieds.

C’est la même idée opérationnelle que nous utilisons en ingénierie du stockage : réparer le jeu de données quand il est au repos. Scrubber ZFS quand le système peut le supporter. Reconstruire un RAID quand vous ne faites pas en même temps un test de charge. Windows ne fait pas exception ; il fait juste semblant.

Un bref avertissement : la réparation hors ligne ne remplace pas la vérification matérielle. Si le disque ment ou si la RAM est instable, SFC/DISM devient une façon coûteuse de réarranger des bits déjà corrompus.

Blague n°1 : Les réparations Windows ressemblent au fil dentaire : tout le monde reconnaît que c’est bon, et presque personne ne le fait tant que ça n’a pas mal.

Faits et petite histoire : comment on en est arrivé là

• SFC existe depuis l’époque Windows 98/2000, évoluant de System File Protection vers Windows Resource Protection (WRP) pour les versions modernes.
• DISM a remplacé des outils d’image plus anciens (comme ImageX et certaines utilités de maintenance précédentes) à mesure que Windows a évolué vers un modèle de maintenance basé sur des composants.
• WinSxS n’est pas un cache « que vous pouvez simplement supprimer » ; c’est le magasin de composants qui soutient les fonctionnalités, les mises à jour et les réparations de Windows.
• Le logging CBS (Component-Based Servicing) est devenu l’enregistrement de référence pour de nombreuses opérations de maintenance ; SFC écrit dans CBS.log.
• WinRE est devenu courant à mesure que les partitions de récupération OEM et les flux de réparation automatique se sont standardisés depuis Windows 8.
• Les Servicing Stack Updates (SSU) existent parce que le mécanisme qui installe les mises à jour a lui‑même besoin de mises à jour — le bootstrap est difficile.
• La maintenance hors ligne est la façon dont fonctionne l’imagerie en entreprise : les équipes informatiques appliquent des paquets sur des images WIM bien avant qu’elles ne démarrent sur les postes.
• Les échecs de Windows Update pointent souvent vers le magasin de composants ; vous pouvez parfois « réparer les mises à jour » en réparant le magasin, pas l’updater.
• Les fonctions Reset/Refresh sont en gros l’admission par Windows que parfois « réparer » coûte trop cher, donc réinstaller sur place l’emporte.

Votre modèle mental : WRP, WinSxS, et pourquoi les réparations échouent en ligne

WRP : le videur du club des fichiers système

Windows Resource Protection contrôle certains fichiers, dossiers et clés de registre. L’idée principale : les composants critiques du système d’exploitation ne doivent pas être remplacés silencieusement par des installateurs aléatoires. Quand SFC détecte une discordance de fichier protégé, il tente de le remplacer à partir d’une source connue bonne.

WinSxS : le magasin de composants (pas un tiroir à bazar)

WinSxS contient des assemblies côte à côte : plusieurs versions de composants, des manifests et des métadonnées qui permettent à Windows de se maintenir. Les mises à jour n’« écrasent » pas simplement les fichiers ; elles installent des composants et orchestrent des changements. Voilà pourquoi le dossier est volumineux et pourquoi le « nettoyage » a des règles.

Les modes d’échec en ligne sur lesquels vous butez souvent

• Fichiers verrouillés : une DLL est utilisée ; le remplacement est différé ; le remplacement différé échoue ; vous répétez indéfiniment.
• Pilotes de filtrage : AV/EDR, agents de sauvegarde, couches de chiffrement et filtres de système de fichiers peuvent gêner les transactions de maintenance.
• Corruption du magasin de composants : SFC ne peut pas réparer parce que sa source est cassée ; DISM doit d’abord réparer le magasin.
• Incompatibilité de la pile de maintenance : le composant qui installe/répare les paquets est obsolète ou partiellement cassé.
• Problèmes de disque : la « corruption » est en réalité des erreurs d’E/S, des secteurs défectueux ou un contrôleur en difficulté.

Il y a une idée paraphrasée de Gene Kim, auteur fiabilité/ops : idée paraphrasée : la fiabilité vient de pratiques petites et répétables, pas de sauvetages héroïques à une heure tardive. C’est l’ambiance ici : de petites réparations planifiées battent la panique occasionnelle.

Méthode de diagnostic rapide : trouver le goulot d’étranglement vite

Vous n’avez pas le temps de « tenter des choses ». Vous avez besoin d’un chemin rapide vers la cause probable. Voici l’ordre que j’utilise quand une machine Windows sent la corruption.

Première étape : est-ce vraiment le disque/la RAM qui se fait passer pour un problème logiciel ?

1. Vérifiez les journaux d’événements pour les erreurs disque et NTFS (Disk, StorAHCI, stornvme, Ntfs). Si vous voyez des erreurs d’E/S, arrêtez de jouer à la roulette SFC et traitez d’abord le stockage.
2. Contrôlez l’état SMART / NVMe. Si le disque se réalloue, se bride ou signale des erreurs média, vous ne « réparez pas Windows » ; vous remplacez le disque et vous restaurez.
3. Confirmez l’espace libre. La maintenance a besoin d’espace pour travailler. Un faible espace disque fait échouer DISM de façons étranges.

Deuxième étape : état du magasin de composants (DISM) avant l’état des fichiers (SFC)

1. Lancez DISM ScanHealth (en ligne si vous pouvez démarrer, hors ligne sinon). Cela vous indique si le magasin est marqué comme réparable.
2. Exécutez DISM RestoreHealth avec une source contrôlée si Windows Update est peu fiable ou bloqué.

Troisième étape : exécutez SFC contre l’image hors ligne

1. Utilisez SFC hors ligne en pointant vers le bon répertoire Windows. Si vous devinez le mauvais lecteur, vous « réparerez » la mauvaise chose et vous vous sentirez productif.
2. Interprétez le résultat : « réparé », « impossible de réparer » ou « aucune violation d’intégrité ». Chacun mène à une décision différente.

Quatrième étape : si ça revient, cessez de traiter les symptômes

Si la corruption revient après des réparations propres, supposez une cause systémique : stockage défectueux, overclock instable, RAM qui faiblit, pilote de filtrage buggy, ou problèmes d’alimentation. Votre travail est de rendre la récurrence coûteuse en supprimant la cause racine, pas en planifiant des marteaux plus gros.

Tâches pratiques : commandes, sorties attendues et décisions (12+)

Toutes les commandes ci‑dessous supposent que vous êtes dans l’invite de commandes WinRE ou un shell administrateur Windows. Les blocs de code montrent des sorties réalistes ; les vôtres varieront. L’important est de savoir ce que signifie la sortie et quelle décision prendre ensuite.

Task 1: Identify the offline Windows drive letter (WinRE lies politely)

cr0x@server:~$ wmic logicaldisk get deviceid, volumename, description
DeviceID  Description       VolumeName
C:        Local Fixed Disk
D:        Local Fixed Disk  Windows
E:        CD-ROM Disk       UDFS

Ce que cela signifie : Dans WinRE, le volume Windows n’est souvent pas C:. Ici c’est D: parce que WinRE a monté les volumes différemment.

Décision : Utilisez D:\Windows pour SFC/DISM hors ligne. Ne devinez pas.

Task 2: Confirm the Windows directory exists where you think it does

cr0x@server:~$ dir D:\Windows
 Volume in drive D has no label.
 Directory of D:\Windows

02/04/2026  10:02 AM    <DIR>          .
02/04/2026  10:02 AM    <DIR>          ..
02/04/2026  10:02 AM    <DIR>          System32
02/04/2026  10:02 AM    <DIR>          WinSxS
               0 File(s)              0 bytes

Ce que cela signifie : Vous avez le bon volume ; WinSxS existe ; vous pouvez continuer.

Décision : Passez à DISM/SFC hors ligne. Si le dossier Windows n’est pas là, revérifiez les volumes.

Task 3: Quick disk sanity check (NTFS metadata) with CHKDSK read-only

cr0x@server:~$ chkdsk D: /scan
The type of the file system is NTFS.
Volume label is Windows.

Stage 1: Examining basic file system structure ...
  512000 file records processed.
File verification completed.
Stage 2: Examining file name linkage ...
  620000 index entries processed.
Index verification completed.
Windows has scanned the file system and found no problems.
No further action is required.

Ce que cela signifie : Aucune anomalie structurelle NTFS évidente trouvée dans un scan en lecture seule.

Décision : Procédez. S’il signale des erreurs, réparez d’abord le disque (/f hors ligne), puis réparez Windows.

Task 4: Look for disk I/O errors in event logs (online boot scenario)

cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=7 or EventID=51 or EventID=55)]]" /c:5 /f:text
Event[0]:
  Log Name: System
  Source: Disk
  Event ID: 7
  Level: Error
  Description:
  The device, \Device\Harddisk0\DR0, has a bad block.

Ce que cela signifie : Ce n’est pas une « corruption Windows ». C’est un stockage en train d’échouer.

Décision : Arrêtez. Sauvegardez maintenant. Remplacez le disque. N’exécutez les réparations qu’une fois le matériel stable.

Task 5: Check component store corruption flags (online)

cr0x@server:~$ DISM /Online /Cleanup-Image /CheckHealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

No component store corruption detected.
The operation completed successfully.

Ce que cela signifie : DISM ne pense pas que le magasin soit corrompu. C’est un contrôle rapide, pas exhaustif.

Décision : Si les symptômes persistent, lancez /ScanHealth ensuite ; puis SFC.

Task 6: Deep scan the component store (offline)

cr0x@server:~$ DISM /Image:D:\ /Cleanup-Image /ScanHealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

[==========================100.0%==========================]
The component store is repairable.
The operation completed successfully.

Ce que cela signifie : DISM a trouvé des problèmes et pense pouvoir les réparer.

Décision : Lancez /RestoreHealth. Préférez une source connue bonne plutôt que de faire confiance à Windows Update.

Task 7: Repair the offline component store using a mounted ISO as a source

cr0x@server:~$ DISM /Image:D:\ /Cleanup-Image /RestoreHealth /Source:WIM:F:\sources\install.wim:6 /LimitAccess
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.

Ce que cela signifie : DISM a réparé le magasin en utilisant l’index 6 du WIM. L’index doit correspondre à votre édition (Pro/Home/Enterprise) ou être compatible.

Décision : Exécutez maintenant SFC hors ligne. Si DISM échoue avec « source files could not be found », corrigez le chemin/index source.

Task 8: Discover the correct WIM index (don’t guess)

cr0x@server:~$ DISM /Get-WimInfo /WimFile:F:\sources\install.wim
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Index : 1
Name : Windows 11 Home
Index : 6
Name : Windows 11 Pro
The operation completed successfully.

Ce que cela signifie : Vous savez maintenant quel index utiliser.

Décision : Utilisez l’index correspondant à votre édition installée. Si vous n’êtes pas sûr, vérifiez l’édition installée depuis le registre hors ligne (tâche suivante).

Task 9: Identify installed edition from the offline registry (surgical, reliable)

cr0x@server:~$ reg load HKLM\OFFLINE D:\Windows\System32\Config\SOFTWARE
The operation completed successfully.

cr0x@server:~$ reg query "HKLM\OFFLINE\Microsoft\Windows NT\CurrentVersion" /v EditionID
HKEY_LOCAL_MACHINE\OFFLINE\Microsoft\Windows NT\CurrentVersion
    EditionID    REG_SZ    Professional

cr0x@server:~$ reg unload HKLM\OFFLINE
The operation completed successfully.

Ce que cela signifie : L’installation hors ligne est Pro, donc l’index WIM « Windows 11 Pro » est approprié.

Décision : Choisissez l’index WIM correspondant pour /Source de DISM.

Task 10: Run SFC against the offline Windows (the main event)

cr0x@server:~$ sfc /scannow /offbootdir=D:\ /offwindir=D:\Windows
Beginning system scan. This process will take some time.

Beginning verification phase of system scan.
Verification 100% complete.

Windows Resource Protection found corrupt files and successfully repaired them.
For online repairs, details are included in the CBS log file located at
windir\Logs\CBS\CBS.log

Ce que cela signifie : SFC a réparé quelque chose. C’est bien, mais vous devez confirmer que la machine reste stable et que les mises à jour réussissent.

Décision : Redémarrez, puis lancez un SFC en ligne rapide plus tard. Si la corruption revient, recherchez la cause (pilotes, disque, RAM).

Task 11: When SFC can’t repair files, extract the actionable bits from CBS.log

cr0x@server:~$ findstr /c:"[SR]" D:\Windows\Logs\CBS\CBS.log | more
2026-02-04 10:41:12, Info                  CSI    000000f1 [SR] Cannot repair member file [l:24{12}]"somefile.dll" of somecomponent, Version = 10.0.22631.1
2026-02-04 10:41:12, Info                  CSI    000000f2 [SR] Repairing corrupted file \??\D:\Windows\System32\otherfile.dll from store

Ce que cela signifie : Les lignes « Cannot repair » vous indiquent ce qui est encore cassé. Souvent, le magasin est encore malsain ou la source est incorrecte.

Décision : Relancez DISM RestoreHealth avec la source correcte. Si ça échoue encore, envisagez une réparation sur place (in-place upgrade).

Task 12: Check DISM logs for source and servicing errors

cr0x@server:~$ type D:\Windows\Logs\DISM\dism.log | findstr /i "error 0x800f081f 0x800f0906 source"
DISM   DISM Package Manager: PID=1124 TID=1420 Failed to resolve package source. - CDISMPackageManager::Internal_Finalize(hr:0x800f081f)
DISM   DISM Package Manager: PID=1124 TID=1420 The source files could not be found; use the "Source" option to specify the location of the files. - GetCbsErrorMsg

Ce que cela signifie : Classique « source manquante ». Windows Update ne peut pas la fournir (ou vous l’avez bloqué), et vous n’avez pas fourni un WIM/ESD correspondant.

Décision : Fournissez un ISO/WIM correct et relancez RestoreHealth. N’essayez pas en boucle la même commande qui échoue.

Task 13: Verify WinRE status (so you can actually boot into maintenance mode)

cr0x@server:~$ reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration
Information:

    Windows RE status:         Enabled
    Windows RE location:       \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
    Boot Configuration Data (BCD) identifier: 12345678-1234-1234-1234-123456789abc
    Recovery image location:
    Recovery image index:      0
    Custom image location:
    Custom image index:        0

Ce que cela signifie : WinRE est activé. C’est bon ; c’est votre plate-forme de lancement pour la maintenance hors ligne.

Décision : Si désactivé, activez-le avant de dépendre des workflows de réparation hors ligne planifiée.

Task 14: Enable WinRE if it’s disabled

cr0x@server:~$ reagentc /enable
REAGENTC.EXE: Operation successful.

Ce que cela signifie : WinRE est maintenant activé.

Décision : Confirmez avec reagentc /info. Sans WinRE, votre plan de « réparation hors ligne planifiée » devient un plan « espérons que quelqu’un soit au clavier ».

Task 15: Check whether the component store cleanup is safe (avoid overzealous trimming)

cr0x@server:~$ DISM /Online /Cleanup-Image /AnalyzeComponentStore
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

Component Store (WinSxS) information:

Windows Explorer Reported Size of Component Store : 9.12 GB
Actual Size of Component Store : 8.95 GB
Shared with Windows : 6.40 GB
Backups and Disabled Features : 1.55 GB
Cache and Temporary Data : 1.00 GB

Component Store Cleanup Recommended : Yes

Ce que cela signifie : Le nettoyage pourrait récupérer de l’espace. Cela ne veut pas dire que vous devez le faire en pleine crise.

Décision : Si la machine est stable, planifiez le nettoyage pendant une période à faible risque. Si vous êtes en mode incident, concentrez-vous d’abord sur les réparations.

Task 16: Configure a one-time boot into WinRE (manual trigger)

cr0x@server:~$ reagentc /boottore
REAGENTC.EXE: Operation successful.

Ce que cela signifie : Le prochain redémarrage ira automatiquement dans WinRE.

Décision : Utilisez ceci quand vous voulez effectuer une session de réparation hors ligne sans jouer à la roulette des touches au démarrage.

Planification des réparations hors ligne : approches possibles (et celle que je préfère)

Abordons la partie gênante : le Planificateur de tâches Windows s’exécute à l’intérieur de Windows. La maintenance hors ligne s’exécute quand Windows n’est pas démarré. C’est un décalage. Donc « SFC/DISM hors ligne planifié » consiste en réalité à planifier l’entrée dans un environnement hors ligne plus des actions de réparation automatisées une fois arrivé là.

Approche A : réparations planifiées en ligne (plus simple, moins fiable)

C’est la base : planifier sfc /scannow et dism /online /cleanup-image /restorehealth pendant une fenêtre de maintenance. Ce n’est pas hors ligne, mais c’est néanmoins utile — surtout sur du matériel stable avec peu de pilotes de filtrage tiers.

Quand l’utiliser : gestion de flotte, ordinateurs portables qu’on ne peut pas retirer du service, ou si l’accès à WinRE est verrouillé.

À éviter : lancer des réparations en ligne pendant de lourdes E/S, installations de patchs, ou pendant que le chiffrement/la sauvegarde est en cours.

Approche B : « planifier » en forçant le prochain démarrage dans WinRE, puis exécuter une réparation hors ligne scriptée (pratique, mon choix)

Vous pouvez planifier une tâche qui déclenche reagentc /boottore puis redémarre à une heure fixée. Le démarrage suivant arrive dans WinRE. À partir de là, il faut de l’automatisation.

WinRE n’est pas conçu comme une plateforme d’automatisation complète, mais vous pouvez le rendre pratique de deux manières :

• Automatisation assistée par un technicien : WinRE démarre, vous exécutez un script pré-écrit depuis une clé USB ou une partition locale fiable. C’est bien pour les power users et les petits environnements.
• Personnalisation OEM/IT : certains environnements customisent WinRE ou fournissent un OS de maintenance pré‑démarrage (WinPE) qui exécute automatiquement des scripts. C’est courant dans l’imagerie d’entreprise, moins sur les PC grand public.

Si vous êtes une personne normale avec un PC normal, la version « semi-automatique » est généralement le meilleur compromis : planifiez le redémarrage dans WinRE, et gardez un script prêt. Cela réduit le temps de réparation de « parcourir des guides à 2h du matin » à « exécuter le script, lire le résumé, retourner dormir ».

Approche C : double amorçage vers une partition Windows/WinPE de maintenance (la plus fiable, la plus coûteuse)

Vous pouvez maintenir une installation Windows minimale secondaire ou un environnement basé sur WinPE qui démarre selon un planning. Depuis cet environnement, la réparation hors ligne est triviale parce que le volume principal est hors ligne. C’est ainsi que fonctionnent certaines équipes d’ingénierie d’endpoint pour des kiosques, des systèmes de laboratoire et des postes à haute disponibilité.

Coût : espace disque, complexité et discipline. Si vous ne le testez pas trimestriellement, il va pourrir.

Comment penser le calendrier

Ne lancez pas DISM RestoreHealth chaque nuit. C’est comme reconstruire vos index de base de données toutes les heures parce qu’une requête a expiré. À la place :

• Hebdomadaire : vérifications légères (journaux d’événements, espace libre, peut‑être SFC si l’historique montre que ça aide).
• Mensuel ou après cycles de patch : DISM ScanHealth, et RestoreHealth seulement si marqué réparable.
• Après incidents : DISM+SFC hors ligne plus vérifications matérielles.

Blague n°2 : Planifier des réparations, c’est la version adulte de « je m’en occuperai demain », sauf que là le lendemain arrive vraiment.

Trois mini-récits d’entreprise depuis le terrain

1) L’incident causé par une mauvaise hypothèse : « C: est toujours Windows »

Une entreprise de taille moyenne avait un ensemble de stations de travail d’ingénierie qui échouaient parfois les mises à jour Windows. Quelqu’un a écrit une SOP « rapide » : démarrer sur un média de récupération, exécuter sfc /scannow et dism /image:c:\, redémarrer, fini.

Ça a marché sur la première machine. Même deux fois. L’équipe a pris confiance et a commencé à l’utiliser largement, y compris sur des systèmes avec BitLocker, plusieurs disques et un mélange de dispositions de partition OEM. Sur une sous-partie, WinRE attribuait les lettres de lecteur différemment. Sur quelques‑unes, le volume OS était D: et C: était une petite partition de récupération ou de données.

Le résultat n’a pas été une catastrophe immédiate. C’était pire : un succès trompeur. Les commandes retournaient « completed successfully » parce qu’elles trouvaient un répertoire Windows — simplement pas le bon. Pendant ce temps, le véritable OS continuait d’échouer aux mises à jour. Une semaine plus tard, le support était noyé de tickets répétés et l’équipe avait une demi‑douzaine de machines dans un état « ça marche jusqu’à ce que ça ne marche plus ».

La correction a été ennuyeuse : ils ont ajouté une étape pour identifier le volume Windows en vérifiant \Windows, en interrogeant le registre hors ligne pour EditionID, et en consignant la lettre de lecteur choisie. Ils ont aussi arrêté d’écrire des SOP qui traitent les lettres de lecteur comme des lois physiques.

2) L’optimisation qui s’est retournée contre eux : nettoyage agressif du magasin de composants

Une autre organisation avait des SSD peu profonds sur des portables terrain. La pression de stockage était constante, alors quelqu’un a décidé d’être proactif : après chaque Patch Tuesday, exécuter le nettoyage du magasin de composants avec des options agressives pour récupérer de l’espace. Ça semblait intelligent. Les portables restaient sous le seuil de « faible espace disque ».

Des mois plus tard, un lot de machines a commencé à échouer lors des mises à niveau de fonctionnalités et des mises à jour cumulatives. Le dépannage a pointé des payloads manquants et des erreurs de la pile de maintenance. L’équipe avait « optimisé » justement la sûreté qui rend la maintenance Windows résiliente dans le temps. Sur certains modèles, la connectivité était restreinte et Windows Update ne pouvait pas récupérer les composants manquants à la demande.

Le postmortem : le nettoyage n’est pas gratuit. Un magasin de composants n’est pas un cache de navigateur. Si vous nettoyez trop agressivement dans un environnement avec des sources de mise à jour restreintes, vous pouvez créer une famine de réparation auto‑infligée.

Ils ont ajusté la politique : dimensionner les disques pour garder assez d’espace, contrôler raisonnablement les applications, exécuter /AnalyzeComponentStore d’abord, et ne nettoyer que quand c’est recommandé — et pas sur les machines qui dépendent de sources de maintenance hors ligne.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : sources de réparation connues et journaux

Une organisation financière avait une posture de sécurité d’endpoint stricte : Windows Update était fortement géré, et beaucoup de machines avaient un accès Internet limité. Ils étaient aussi disciplinés — presque de façon agaçante — à conserver pour chaque build pris en charge une ISO Windows correspondante sur un partage interne.

Quand une vague d’échecs de mises à jour est survenue après un changement de servicing stack, ils n’ont pas paniqué. Leur playbook était simple : DISM ScanHealth, puis RestoreHealth avec une /Source:WIM contrôlée, puis SFC hors ligne pour les pires cas. Chaque exécution capturait les journaux DISM et CBS dans un dossier de cas central.

Ce qui les a sauvés n’était pas du génie. C’était de la cohérence. La source contrôlée a retiré le comportement aléatoire de Windows Update de l’équation. Les journaux ont rendu évident quelles machines échouaient à cause de restrictions d’accès versus une vraie corruption.

Ils avaient encore du travail, mais c’était du travail prévisible. En opérations, la prévisibilité est pratiquement un langage d’amour.

Erreurs courantes : symptôme → cause racine → correctif

1) « SFC a réparé des fichiers, mais la corruption revient en une semaine »

Symptôme : violations d’intégrité récurrentes ; mises à jour qui échouent parfois ; plantages d’apps aléatoires.

Cause racine : instabilité matérielle sous-jacente (erreurs média disque, mauvaise RAM, overclock instable) ou un pilote de filtrage tiers qui corrompt les écritures.

Correctif : Vérifiez les événements disque et l’état SMART/NVMe ; lancez des diagnostics mémoire ; retirez ou mettez à jour les pilotes suspects ; arrêtez l’overclocking. Puis relancez DISM+SFC hors ligne une fois la plateforme stable.

2) « DISM dit que les fichiers source sont introuvables (0x800f081f) »

Symptôme : RestoreHealth échoue ; ScanHealth signale réparable ; SFC ne peut pas réparer.

Cause racine : ISO de build incorrecte, mauvais index WIM, fonctionnalités à la demande manquantes, ou Windows Update bloqué sans source alternative.

Correctif : Utilisez DISM /Get-WimInfo pour trouver l’index correct ; confirmez l’édition via le registre hors ligne ; fournissez le /Source:WIM correct et utilisez /LimitAccess si nécessaire.

3) « SFC ne peut pas réparer les fichiers même après DISM »

Symptôme : SFC se termine par « could not repair some files ».

Cause racine : Le magasin de composants est toujours corrompu, ou le fichier système n’est pas couvert par WRP et est modifié par un logiciel.

Correctif : Relancez DISM avec la source correcte ; parsez CBS pour le fichier/composant exact ; si c’est un fichier tiers, réinstallez cette application/ce pilote. Si c’est un composant OS central et persistant, faites une réparation sur place (in-place upgrade).

4) « SFC hors ligne indique aucune violation, mais Windows est quand même cassé »

Symptôme : Applications qui plantent, menu Démarrer problématique, échecs de mise à jour, mais SFC est propre.

Cause racine : Toutes les cassures ne sont pas des fichiers système protégés. Profils, packages d’apps, services et métadonnées de mise à jour peuvent échouer indépendamment.

Correctif : Concentrez-vous sur les logs de mise à jour et l’état AppX/package ; envisagez de réinitialiser les composants Windows Update ; validez les services ; vérifiez l’intégrité des profils par utilisateur.

5) « J’ai exécuté SFC hors ligne mais il a ciblé la mauvaise partition »

Symptôme : Les commandes « réussissent », mais rien ne s’améliore ; le journal CBS manque d’entrées attendues.

Cause racine : Mauvaise lettre de lecteur dans WinRE, ou offbootdir/offwindir incorrects.

Correctif : Identifiez explicitement le volume Windows avec wmic logicaldisk et dir X:\Windows ; puis relancez avec les chemins corrects.

6) « DISM marche en ligne, mais échoue hors ligne (ou vice versa) »

Symptôme : Résultats incohérents selon l’environnement.

Cause racine : BitLocker verrouille le volume hors ligne, pilotes manquants dans WinRE, ou différences d’accès réseau/source.

Correctif : Déverrouillez le volume BitLocker dans WinRE ; assurez-vous que les pilotes de stockage sont disponibles ; utilisez des sources ISO locales plutôt que des dépendances réseau.

Checklists / plan pas à pas

Plan A : Vous pouvez démarrer Windows (mais il se comporte comme maudit)

1. Collectez d’abord des preuves : vérifiez les journaux d’événements pour erreurs disque/NTFS ; confirmez l’espace libre.
2. Exécutez DISM CheckHealth puis ScanHealth : décidez si une réparation est nécessaire.
3. Si réparable, lancez DISM RestoreHealth : préférez une ISO connue bonne si votre environnement bloque Windows Update.
4. Exécutez SFC en ligne : si des fichiers sont réparés, redémarrez et retestez mises à jour/apps.
5. Si les symptômes persistent : planifiez une session hors ligne (Plan B) plutôt que de répéter indéfiniment les réparations en ligne.

Plan B : Vous ne pouvez pas démarrer Windows de façon fiable (ou vous voulez la réparation la plus sûre)

1. Démarrez dans WinRE : soit manuellement soit en utilisant reagentc /boottore avant le redémarrage.
2. Identifiez le volume Windows : ne supposez pas les lettres de lecteur.
3. Exécutez chkdsk /scan : si des erreurs apparaissent, corrigez d’abord le système de fichiers.
4. Exécutez DISM ScanHealth hors ligne : si réparable, procédez à RestoreHealth.
5. Exécutez DISM RestoreHealth hors ligne avec source ISO : utilisez l’index WIM correct.
6. Exécutez SFC hors ligne : vérifiez l’intégrité et réparez les fichiers protégés.
7. Redémarrez normalement : testez Windows Update et vos applications clés.
8. Extraites et archivez les journaux : CBS.log et dism.log sont vos reçus.

Plan C : Rendre ça « planifié » sans transformer votre vie en foire scientifique

1. Décidez ce que vous planifiez : vérifications hebdomadaires vs réparations mensuelles vs réparation hors ligne seulement après incident.
2. Planifiez une fenêtre de redémarrage contrôlée : hors des heures de travail, avec alimentation branchée pour les portables.
3. Déclenchez un boot WinRE unique : reagentc /boottore, puis redémarrez.
4. Exécutez votre script ou checklist hors ligne : n’improvisez pas à 3h du matin.
5. Après redémarrage, validez : installation des mises à jour, journaux d’événements, et si la corruption revient.

Garde-fous opérationnels (ce que font les adultes)

• Garder une ISO correspondante pour votre build/major version installée. « Assez proche » est la façon d’obtenir 0x800f081f.
• Ne traitez pas une corruption récurrente comme purement logicielle. Le stockage et la RAM ont leur mot à dire.
• Capturer les journaux à chaque fois. Si vous ne pouvez pas expliquer pourquoi ça a cassé, vous ne l’avez pas réparé — vous avez eu de la chance.
• Changer une variable à la fois. Réparation + mises à jour de pilotes + tweaks de registre n’est pas du dépannage, c’est du jeu de hasard.

FAQ

1) Dois‑je exécuter DISM avant SFC ?

Oui, quand vous suspectez une vraie corruption. DISM répare le magasin de composants que SFC utilise comme source. Si le magasin est cassé, SFC peut échouer ou « réparer » de manière incohérente.

2) Que signifie « The component store is repairable » ?

DISM a détecté une corruption et pense pouvoir la corriger si vous fournissez une source valide (Windows Update ou un WIM/ESD local). C’est le feu vert pour exécuter RestoreHealth.

3) Pourquoi SFC hors ligne réussit parfois alors que SFC en ligne échoue ?

Hors ligne évite les verrous de fichiers, les services en cours d’exécution et les pilotes de filtrage qui influencent les opérations sur les fichiers. C’est la même opération de réparation avec moins de pièces en mouvement.

4) Puis‑je vraiment automatiser SFC/DISM hors ligne avec le Planificateur de tâches ?

Pas directement, parce que le Planificateur s’exécute dans Windows. Vous pouvez planifier un redémarrage dans WinRE (reagentc /boottore) puis exécuter les réparations avec un script pré‑démarrage (personnalisation WinPE/WinRE) ou une intervention technique. L’automatisation totalement sans personne nécessite généralement un environnement pré‑démarrage d’entreprise.

5) Que faire si DISM RestoreHealth échoue même avec une source ?

Vérifiez que le build et l’index de la source correspondent, confirmez que le chemin est accessible dans votre environnement, et lisez dism.log pour l’erreur exacte. Si ça échoue toujours, vous aurez peut‑être besoin d’une réparation sur place ou de corriger d’abord des problèmes disques.

6) Est‑ce sûr d’exécuter ces réparations régulièrement ?

Des contrôles occasionnels sont acceptables. Lancer RestoreHealth constamment est excessif. La cadence sûre : vérifier d’abord, réparer uniquement quand c’est signalé. Si vous réparez chaque semaine, vous avez probablement une cause racine récurrente.

7) SFC/DISM résoudra‑t‑il les échecs de Windows Update ?

Parfois. Si les mises à jour échouent parce que le magasin de composants est corrompu, DISM peut le réparer et les mises à jour recommenceront à fonctionner. Si les mises à jour échouent à cause de politiques, réseau ou SSU, vous devez traiter ces problèmes directement.

8) Où trouver les journaux importants ?

Les détails SFC se trouvent dans C:\Windows\Logs\CBS\CBS.log (ou l’équivalent hors ligne). Les détails DISM sont dans C:\Windows\Logs\DISM\dism.log. Dans WinRE, ajustez la lettre de lecteur en conséquence.

9) Quelle est la différence entre install.wim et install.esd ?

Les deux peuvent contenir des images Windows ; ESD est généralement plus compressé. DISM peut utiliser l’un ou l’autre comme source, mais la syntaxe diffère (/Source:WIM: vs /Source:ESD:) et votre ISO peut n’en contenir qu’un seul.

10) Quand dois‑je abandonner et faire une réparation sur place (in‑place repair upgrade) ?

Si DISM ne peut pas réparer le magasin avec une source correcte, SFC échoue sur des composants centraux, ou la corruption revient immédiatement sur un matériel stable. À ce stade, le temps c’est de l’argent — la réparation par réinstallation souvent gagne.

Prochaines étapes qui réduisent vraiment la douleur

Si vous voulez un Windows « auto‑réparateur », il ne faut pas de mysticisme. Il faut une boucle de maintenance répétable et la volonté d’accuser le matériel quand le matériel est coupable.

1. Constituez votre trousse de base : gardez une ISO Windows correspondante à portée de main ; sachez comment trouver l’index WIM ; confirmez que WinRE est activé.
2. Adoptez l’ordre des opérations : sanity du disque → DISM (magasin) → SFC (fichiers) → journaux → puis seulement les actions plus lourdes.
3. Facilitez le déclenchement hors ligne : utilisez reagentc /boottore pour la maintenance planifiée, et gardez un petit script ou une checklist prête pour WinRE.
4. Surveillez la récurrence : si la corruption revient, traitez‑la comme un problème de plateforme, pas comme un mauvais caractère de Windows.
5. Consignez ce qui s’est passé : sauvegardez CBS.log et dism.log pour chaque incident. La prochaine panne semblera « nouvelle » jusqu’à ce que vous la compariez à l’ancienne.

Faites cela, et vous passerez moins de temps à réparer Windows et plus de temps à l’utiliser. Ce qui est le but quand on possède un ordinateur au lieu d’adopter un animal de compagnie exigeant.