La commande sfc /scannow lance le vérificateur des fichiers système de Windows : elle compare chaque fichier protégé du système à une copie de référence conservée par Windows lui-même, puis remplace ceux qui ont été modifiés, tronqués ou corrompus.
En bref
- La commande sfc s'exécute depuis une invite de commandes ouverte en administrateur, et dure de l'ordre d'un quart d'heure.
- Le détail fichier par fichier est écrit dans le journal CBS.log, que l'on filtre pour ne garder que les lignes utiles.
- Quand la réparation échoue, c'est la réserve de fichiers de référence qui est atteinte : DISM la remet en état, puis on relance sfc.
Ce que vérifie réellement la commande sfc
Windows tient une liste de fichiers dits protégés : bibliothèques du système, pilotes livrés avec l'installation, exécutables de base. Le mécanisme qui les surveille porte le nom de protection des ressources Windows, et l'utilitaire de Microsoft qui l'interroge s'appelle System File Checker, abrégé en trois lettres dans son nom de commande. Pour chaque fichier de cette liste, l'outil sfc calcule une empreinte et la confronte à celle de la copie saine mise en cache dans le magasin de composants, le dossier WinSxS. En cas d'écart, la copie de référence écrase le fichier en place.
Deux conséquences en découlent, et elles expliquent l'essentiel des déceptions. La première : System File Checker ne répare que ce qui figure dans sa liste, donc les composants de Windows et rien d'autre. La seconde : son fonctionnement suppose une source de référence intacte, faute de quoi il constate le problème sans pouvoir le résoudre. Une erreur de bibliothèque manquante peut donc relever de cette commande comme lui échapper complètement, selon le type de fichier qu'elle nomme.
Lancer l'analyse en mode administrateur
Ouvrir une invite de commandes avec les droits nécessaires
L'écriture dans les dossiers du système exige des droits élevés : sans eux, sfc refuse de démarrer et affiche un message demandant une console en mode administrateur. Le chemin le plus court consiste à appuyer sur la touche Windows du clavier, à taper cmd dans la barre de recherche, puis à faire un clic du bouton droit de la souris sur le résultat pour choisir l'exécution en tant qu'administrateur. Un clic du bouton gauche ouvrirait la même fenêtre sans les droits nécessaires, et c'est l'erreur la plus fréquente.
Dans la fenêtre qui s'ouvre, tapez la commande sfc puis appuyez sur la touche Entrée :
sfc /scannow
La vérification commence et affiche une progression en pourcentage. Elle demande quelques minutes sur un disque récent, davantage sur un disque dur mécanique bien rempli. Laissez la fenêtre ouverte jusqu'au message final : interrompre le processus en cours de remplacement laisse le système dans un état intermédiaire. Prévoyez aussi un peu d'espace libre sur le disque, la réparation travaillant sur des copies temporaires.
Les autres options de la commande sfc
L'option /verifyonly permet d'analyser sans rien réparer, ce qui établit un constat avant d'agir. Les options /scanfile et /verifyfile ciblent un fichier unique dont on connaît le chemin complet, utilisation commode quand un seul composant est en cause. Par exemple, sfc /scanfile=C:\Windows\System32\kernel32.dll ne contrôle que cette bibliothèque et rend la main en quelques secondes.
Lire le message final
Le vérificateur se termine toujours par l'une de quatre phrases, et chacune appelle une suite différente.
| Message affiché | Ce qu'il faut en faire |
|---|---|
| Aucune violation d'intégrité n'a été trouvée | Les fichiers protégés sont sains : la panne vient d'ailleurs, souvent d'un composant tiers. |
| Des fichiers corrompus ont été trouvés et réparés | Redémarrez, puis vérifiez que l'erreur d'origine a disparu. |
| Des fichiers corrompus ont été trouvés mais certains n'ont pas pu être réparés | La source de référence est elle-même atteinte : enchaînez sur DISM, puis relancez sfc. |
| L'opération demandée n'a pas pu être exécutée | L'outil n'a pas pu travailler : voyez le mode sans échec et l'environnement de récupération. |
Ce message est un résumé, pas un rapport. Il ne nomme aucun fichier, ne dit pas combien il y en avait, et ne précise pas lesquels résistent. Ces informations existent, mais dans le journal.
Ouvrir le journal pour connaître le détail
Chaque opération est consignée dans le fichier CBS.log, sous le dossier des journaux de Windows, à l'emplacement %WinDir%\Logs\CBS\CBS.log. Ce journal mêle le travail du vérificateur à celui du service de maintenance des composants, et il atteint couramment plusieurs dizaines de mégaoctets : l'ouvrir tel quel n'apprend pas grand-chose.
Les lignes produites par la vérification portent toutes le même préfixe. La commande suivante les extrait dans un fichier texte déposé sur le bureau de l'utilisateur en cours :
findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log >"%userprofile%\Desktop\sfcdetails.txt"
Le fichier obtenu se lit dans n'importe quel éditeur. On y trouve le nom complet de chaque fichier examiné, la nature du problème constaté et la mention de la réparation lorsqu'elle a réussi. Cette liste détaillée est la seule façon de savoir quel composant résiste, information nécessaire pour la suite.
Passer par DISM quand la réparation échoue
Le vérificateur puise ses copies saines dans le magasin de composants. Si ce magasin est lui-même corrompu, sfc n'a plus rien à recopier : il détecte les écarts, les signale, et s'arrête là. C'est la situation décrite par le troisième message du tableau, et aucune répétition de la même commande n'en viendra à bout.
C'est le rôle de l'autre utilitaire livré avec Windows, DISM, l'outil de gestion et de maintenance des images de déploiement. Il travaille un cran plus bas, sur l'image du système, et sait restaurer la réserve à partir d'une source externe.
Les trois commandes, de la plus rapide à la plus complète
- DISM /Online /Cleanup-Image /CheckHealth : consulte un indicateur déjà enregistré. La réponse est immédiate, mais elle ne vaut que si un examen a eu lieu auparavant.
- DISM /Online /Cleanup-Image /ScanHealth : analyse réellement le magasin de composants et rend un verdict. Comptez plusieurs minutes.
- DISM /Online /Cleanup-Image /RestoreHealth : applique le correctif, en téléchargeant les fichiers manquants par le service de mise à jour de Windows. C'est l'opération la plus longue, souvent une demi-heure selon la connexion.
Une fois la restauration terminée, relancez sfc : la réserve étant redevenue saine, la seconde passe répare généralement ce que la première n'avait pu que constater. L'ordre compte. Sur Windows 7, l'option de restauration en ligne n'existe pas ; la solution de remplacement est l'utilitaire de préparation aux mises à jour, à télécharger séparément sur le site de Microsoft.
Réparer sans passer par la mise à jour de Windows
La restauration échoue parfois avec un code d'erreur en 0x800f0906 ou 0x800f081f. Les deux disent la même chose : DISM n'a pas trouvé de source saine. Le cas se rencontre sur un poste sans connexion, derrière un serveur de mises à jour interne, ou lorsque la stratégie de sécurité de l'entreprise interdit l'accès direct au service de Microsoft.
La parade consiste à désigner soi-même la source, en montant une image d'installation de la même version de Windows et en indiquant le fichier qu'elle contient :
DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:X:\sources\install.wim:1 /LimitAccess
La lettre de lecteur est celle du support monté, et l'option finale empêche l'outil de retourner interroger le service en ligne. La version de l'image doit correspondre à celle de la machine : une source plus ancienne que le système installé sera refusée. DISM tient par ailleurs son propre journal, dans le sous-dossier DISM du dossier Logs de Windows, où figure le motif exact d'un échec.
Quand la commande sfc refuse de s'exécuter
Le message annonçant que l'opération demandée n'a pas pu être exécutée est le plus déroutant, parce qu'il ne dit rien du motif. Trois causes couvrent la grande majorité des cas où sfc ne fonctionne pas.
La première est l'absence de droits : une invite ouverte sans élévation ne peut ni lire ni remplacer les fichiers concernés. La deuxième tient aux dossiers de travail du magasin de composants, qui doivent exister pour que la réparation puisse préparer ses remplacements ; démarrer en mode sans échec suffit souvent à débloquer la situation, un logiciel de sécurité trop zélé pouvant aussi bloquer l'accès. La troisième est matérielle : un disque dur qui commence à rendre des secteurs illisibles fait échouer l'opération de façon aléatoire, et il vaut mieux contrôler son état avant d'insister.
Reste le cas d'un système qui ne démarre plus. L'analyse s'exécute alors depuis l'environnement de récupération, en désignant explicitement le disque et le dossier à examiner :
sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows
Attention à la lettre du lecteur : dans l'environnement de récupération, la partition système ne porte pas toujours la lettre C. Vérifiez-la avant de lancer la commande, sinon l'outil analysera le mauvais volume sans le signaler.
Vérifier que le problème est bien résolu
Un message annonçant une réparation réussie ne prouve pas que la panne d'origine a disparu, et c'est l'étape que l'on saute le plus souvent. Après le redémarrage, reproduisez d'abord le geste qui déclenchait l'erreur : lancer l'application concernée, ouvrir le document, brancher le périphérique. C'est le seul test qui compte.
Relancez ensuite sfc /verifyonly. L'opération est plus rapide qu'une réparation et confirme que plus aucune violation d'intégrité ne subsiste. Si le rapport reste propre alors que le symptôme est persistant, le problème n'était pas dans les fichiers du système, et continuer à répéter ces commandes ne servira à rien : c'est le moment de chercher du côté des programmes installés, des pilotes ou du matériel.
Les questions qui reviennent
Combien de temps dure une analyse complète ?
De l'ordre de cinq à vingt minutes selon le disque et le nombre de fichiers protégés. Une progression qui stagne longtemps sur un même pourcentage est normale et ne justifie pas d'interrompre l'opération.
Faut-il redémarrer après la réparation ?
Oui dès que des fichiers ont été remplacés, car certains composants ne sont rechargés qu'au démarrage. Après une analyse sans anomalie, le redémarrage n'apporte rien.
Peut-on lancer la commande depuis PowerShell ?
Oui, à condition d'ouvrir la fenêtre en administrateur. La syntaxe est identique et le résultat aussi : c'est bien le même utilitaire qui s'exécute.
La commande peut-elle abîmer le système ?
Elle ne fait que remplacer des fichiers de Windows par les copies officielles de la même version. Le seul effet indésirable connu concerne les personnalisations qui modifient des fichiers protégés, thèmes non officiels compris : elles sont annulées.
Que faire si les deux outils ne changent rien ?
Il reste la mise à niveau sur place, qui réinstalle Windows en conservant les programmes et les documents. Elle remplace l'intégralité des composants du système et règle les corruptions que la réparation ciblée ne sait pas traiter.
Ce que ces deux outils ne réparent pas
Un point mérite d'être clair, car il est la source de la plupart des recherches infructueuses : une bibliothèque qui n'appartient pas à Windows n'est pas dans la liste des fichiers protégés. Les noms commençant par msvcp, vcruntime ou msvcr relèvent des redistribuables Visual C++ ; ceux commençant par d3dx ou xinput relèvent du runtime graphique. Pour ces fichiers, l'analyse se terminera sur un rapport parfaitement propre pendant que l'erreur persistera, et ce résultat n'est pas une contradiction.
La bonne solution consiste alors à réinstaller le paquet auquel le fichier appartient, jamais à récupérer le fichier seul : c'est la raison pour laquelle il ne faut jamais télécharger une bibliothèque isolée. Un composant partagé peut par ailleurs être présent et simplement mal déclaré dans la base de registre, cas qui se traite avec l'utilitaire regsvr32 et non avec une vérification du système.
À l'inverse, une erreur portant sur un fichier de Windows lui-même, tel que kernel32.dll, est exactement le terrain de ces deux commandes. Nos guides pratiques sur les fichiers DLL détaillent les autres cas de figure, de la confusion entre les dossiers 32 et 64 bits aux erreurs de point d'entrée.
