Vous avez lancé chkdsk parce que Windows ne démarrait plus, ou parce qu'il vous l'a proposé tout seul. L'écran s'est rempli de lignes, et deux d'entre elles vous ont arrêté :
Puis chkdsk a terminé, a annoncé avoir « corrigé le système de fichiers », et Windows a peut-être même redémarré. Affaire réglée ? Non. Ces deux messages ne parlent pas d'un Windows abîmé : ils disent que le disque n'arrive plus à relire une partie de ce qu'on lui a confié. C'est une panne matérielle qui commence, et la suite se joue sur l'ordre dans lequel vous faites les choses.

Cet article s'appuie sur un cas traité à l'atelier en septembre 2026 : un tout-en-un Acer de 2019 bloqué sur la réparation automatique. Nous allons lire ensemble le compte rendu de chkdsk, ligne par ligne.

À retenir en trente secondes

1. Le cas de l'atelier : un tout-en-un qui tourne en boucle

La machine : un Acer Aspire C27 de 2019, avec un petit SSD de 128 Go pour Windows et un disque dur de 1 To pour les données. Symptôme : à chaque allumage, « Préparation de la réparation automatique », puis la console de dépannage, en boucle. Windows ne tentait même plus de se lancer.

Ce symptôme a plusieurs causes possibles, que nous détaillons dans l'article PC bloqué sur « Préparation de la réparation automatique ». Ici, nous les avons écartées une à une :

• la chaîne de démarrage était intacte (le fichier bcdinfo.txt que la réparation automatique dépose dans C:\Windows\System32\LogFiles\Srt montrait un démarrage parfaitement configuré) ;

• le Registre était sain, et aucune mise à jour n'était restée coincée ;

• le journal de la réparation automatique, lui, concluait : « Fichiers du système d'exploitation introuvables sur le disque ».

Introuvables ? Pourtant le dossier Windows était bien là. Le déclic est venu d'un test tout simple : copier un fichier système vers une clé USB. La copie de C:\Windows\System32\winload.efi (le fichier qui charge Windows) échouait, alors que son double rangé dans System32\Boot se copiait sans problème. Un fichier qu'on voit mais qu'on ne peut pas lire : c'est la signature d'un support qui lâche.

Le chkdsk C: /f lancé ensuite a tout confirmé. Voici comment le lire.

2. Lire le compte rendu de chkdsk, étape par étape

Avec l'option /f, chkdsk travaille en trois étapes (cinq avec /r, qui ajoute l'analyse de toute la surface du disque).

Étape 1 : les enregistrements de fichier (la MFT)

Sur un disque Windows (format NTFS), chaque fichier et chaque dossier possède une fiche d'identité de 1 Ko dans une grande table, la MFT. Cette fiche dit : comment le fichier s'appelle, dans quel dossier il est rangé, où se trouvent ses données. L'étape 1 relit toutes ces fiches.

Chez notre client :
Deux mots à bien distinguer :

• illisible : chkdsk a demandé la fiche au disque, et le disque n'a pas pu la fournir. Le problème est dans le matériel.

• incorrect : le disque a fourni la fiche, mais son contenu ne tient pas debout. Le problème est dans les données, typiquement après une coupure de courant pendant une écriture.

Le détail qui ne trompe pas : quatre numéros qui se suivent. Quatre fiches de 1 Ko côte à côte, cela fait exactement 4 Ko, c'est-à-dire un seul bloc du disque. Ce n'est pas Windows qui a « mal écrit » quatre fiches par hasard : c'est un bloc physique que le SSD ne rend plus.

Étape 2 : les index (le contenu des dossiers)

Un dossier, sous NTFS, est un index : la liste alphabétique de ce qu'il contient. L'étape 2 vérifie que chaque fichier est bien listé dans son dossier, et que chaque ligne d'un dossier correspond à un fichier qui existe.
Ce message est revenu quatre fois, sur quatre dossiers différents. Le code c0000185 est un code d'état de Windows, STATUS_IO_DEVICE_ERROR : « le périphérique a signalé une erreur d'entrée/sortie ». Traduction : Windows a posé une question au disque, et le disque a répondu « je n'y arrive pas ». Selon la version de Windows, la ligne peut aussi s'écrire « Échec de lecture avec l'état 0xc0000185 au décalage… ». Le sens est le même.

Quatre dossiers éloignés les uns des autres, plus le bloc de MFT de l'étape 1 : plusieurs zones illisibles dispersées. Ce n'est plus un accident isolé, c'est un SSD en fin de vie.

C'est aussi l'étape 2 qui a expliqué toute la panne :
Le dossier B85C8, c'était System32. Un bloc de son index était illisible : tous les fichiers d'une tranche alphabétique (de « vulkan… » à « win… ») existaient toujours sur le disque, mais n'étaient plus listés dans le dossier. Et winload.efi est dans cette tranche. Voilà pourquoi la réparation automatique ne « trouvait » plus Windows.

Les fichiers orphelins

Un orphelin est un fichier dont la fiche MFT est intacte mais qu'aucun dossier ne liste plus. chkdsk lit dans la fiche le nom du dossier parent et raccroche le fichier à sa place. Bilan du cas : 92 orphelins, dont 90 remis dans leur dossier d'origine, avec leur nom.

La preuve par l'exemple : après chkdsk, winload.efi est réapparu dans System32, même taille et même date que son double. Le fichier n'avait jamais été abîmé, c'est le dossier qui ne le listait plus.

Le dossier found.000

Les 2 orphelins restants, chkdsk n'a pas su où les ranger : il les a déposés dans found.000, un dossier caché créé à la racine du disque (found.001 s'il existe déjà, et ainsi de suite). On y trouve deux sortes de choses :

• des sous-dossiers dir0000.chk, dir0001.chk… qui contiennent des fichiers retrouvés, souvent avec leur vrai nom ;

• des fichiers file0000.chk, file0001.chk… : des fragments de données sans nom. Un .chk peut être une photo, un document, ou un bout de fichier système sans intérêt. On l'identifie en l'ouvrant avec un éditeur, ou en testant l'extension probable (.jpg, .docx, .pdf) sur une copie.

Pour le voir : dans l'Explorateur, Afficher puis Éléments masqués, et décocher « Masquer les fichiers protégés du système d'exploitation » dans les options des dossiers.

Ne supprimez pas found.000 par réflexe pour « faire propre ». Si des fichiers personnels manquent après un chkdsk, c'est le premier endroit où regarder.

Le résumé final

Sur un disque sain, cette ligne affiche 0 Ko. Attention à ne pas vous rassurer avec un petit chiffre : chkdsk /f ne parcourt pas la surface du disque. Il ne compte que les blocs abîmés qu'il a croisés en vérifiant la structure. Notre SSD avait au moins cinq zones illisibles ; le résumé n'en montrait qu'une.

3. Pourquoi Windows redémarre, et pourquoi le disque est quand même à remplacer

C'est le point qui piège le plus de monde. Après ce chkdsk, l'index de System32 était reconstruit, winload.efi de nouveau visible : Windows avait toutes les chances de redémarrer normalement. Et pourtant nous avons remplacé le SSD. Pourquoi ?

Parce que chkdsk répare le classement, pas le support. Il a reconstruit les listes, raccroché les orphelins, et marqué les blocs morts comme inutilisables. Il n'a rien changé au fait que ce SSD de 2019 perd la capacité de relire ses propres cellules. Les blocs touchés hier étaient dans un index ; ceux de demain seront peut-être dans vos photos, votre comptabilité ou la MFT elle-même.

Sur un SSD, c'est encore plus net que sur un disque dur : un SSD en bonne santé corrige en silence ses erreurs de lecture et remplace ses cellules usées sans que Windows ne voie rien. Quand une erreur de lecture remonte jusqu'à chkdsk, c'est que ces mécanismes internes sont dépassés. Et un SSD prévient rarement : il peut passer de « quelques erreurs » à « plus reconnu du tout » du jour au lendemain.

Pour confirmer, sans rien écrire sur le disque :

• l'état SMART (avec CrystalDiskInfo, gratuit) : regardez l'état de santé général, les « secteurs réalloués », les « erreurs non corrigibles » et, sur un SSD, le pourcentage de durée de vie. Attention, un SMART « correct » n'innocente pas un disque qui vient de produire des c0000185 : le compte rendu de chkdsk fait foi ;

• l'Observateur d'événements : dans Journaux Windows puis Système, les événements de source disk (« le périphérique comporte un bloc défectueux ») et Ntfs n° 55.

4. Le bon ordre : l'image d'abord, la réparation ensuite

chkdsk écrit sur le disque. Il reconstruit des index, efface des entrées qu'il juge irrécupérables, déplace des données. Sur un disque sain, c'est sans risque. Sur un disque qui lâche, chaque passe :

• fait travailler un support fragile, parfois pendant des heures (surtout avec /r, qui relit toute la surface : c'est l'option qui achève les disques malades) ;

• prend des décisions irréversibles à partir de lectures partielles. Une entrée d'index « supprimée » parce que son bloc était illisible ce jour-là, c'est une information qu'une récupération professionnelle aurait peut-être pu relire.

L'ordre à retenir est donc :

1. On arrête tout dès les premiers messages « illisible » ou « c0000185 ». Exception : si chkdsk est en train de tourner, on le laisse finir. L'interrompre en pleine écriture est pire que tout.

2. On fait une image du disque (une copie intégrale, bloc par bloc, avec un outil qui sait insister sur les zones difficiles et passer les zones mortes). On travaille ensuite sur l'image, jamais sur l'original.

3. On remplace le disque et on réinstalle Windows sur un support neuf.

4. On restaure les données depuis l'image.

Soyons transparents : dans notre cas, le chkdsk a été lancé avant l'image, parce que tout désignait d'abord un problème de démarrage et non de disque. Il s'est terminé sans dégât, mais ce n'est pas l'ordre à reproduire. Dès la lecture du compte rendu, nous avons stoppé toute réparation (ni sfc, ni second chkdsk) et sorti le SSD.

Ce qu'il ne faut pas faire à ce stade :

• relancer chkdsk « pour voir si c'est mieux », ou le relancer avec /r ;

• lancer « Réinitialiser ce PC » : l'opération réécrit des dizaines de Go, échoue souvent à mi-parcours sur un disque fatigué, et laisse la machine dans un état pire pour la récupération ;

• copier ses fichiers à la main depuis Windows pendant des heures : chaque blocage sur un fichier illisible fait insister le disque sur ses zones les plus faibles.

5. Et si chkdsk n'affiche que des « incorrect » et des orphelins ?

C'est le cas favorable. Des enregistrements incorrects, des entrées d'index corrigées, quelques orphelins, 0 Ko de secteurs défectueux et aucun message « illisible » ni « c0000185 » : c'est une corruption logique. L'origine est presque toujours une extinction brutale (coupure de courant, batterie vide, appui long sur le bouton) pendant que Windows écrivait. Nous décrivons ce scénario dans Écran bleu au démarrage après une coupure de courant.

Dans ce cas chkdsk a fait son travail, et le disque peut rester en service. Deux précautions tout de même : vérifiez le SMART une fois, et si chkdsk retrouve des erreurs à chaque passage sans qu'il y ait eu de coupure, considérez le disque comme suspect. Un système de fichiers ne se corrompt pas tout seul.

Questions fréquentes

« Segment d'enregistrement de fichier illisible » : mes fichiers sont-ils perdus ?
Pas forcément. Le message dit qu'une fiche de la table des fichiers n'a pas pu être lue, pas que les données du fichier ont disparu. Dans notre cas, les fiches perdues concernaient des fichiers de cache sans importance. Mais vous ne le saurez qu'après coup, et le disque va continuer à se dégrader : sauvegardez avant toute autre manipulation.

Que signifie le code c0000185 ?
C'est le code Windows STATUS_IO_DEVICE_ERROR : le disque a signalé une erreur d'entrée/sortie lors d'une lecture. On le retrouve dans chkdsk, mais aussi sur un écran bleu de démarrage (« erreur 0xc0000185 : un périphérique requis n'est pas connecté ou inaccessible »). Dans les deux cas, il pointe vers le disque, son câble ou son connecteur, pas vers Windows.

Peut-on avoir une erreur c0000185 avec un disque en bon état ?
Oui, quand la liaison est en cause : câble SATA abîmé, SSD M.2 mal enfoncé, boîtier USB défaillant. Sur un PC fixe, on remplace le câble et on change de port avant de condamner le disque. Sur un SSD M.2 d'origine qui n'a jamais été démonté, c'est beaucoup moins probable.

Faut-il lancer chkdsk sur un SSD ?
chkdsk /f sur un SSD sain ne pose aucun problème. Ce qui est inutile et déconseillé, c'est chkdsk /r : l'analyse de surface n'a pas grand sens sur un SSD, qui gère lui-même le remplacement de ses cellules. Et sur un SSD suspect, aucun chkdsk avant d'avoir fait une image.

Un SSD peut-il avoir des « secteurs défectueux » ?
Oui. Le terme vient des disques durs, mais la réalité est la même : des blocs que le contrôleur n'arrive plus à relire malgré sa correction d'erreurs. La différence, c'est qu'un SSD masque ces défauts très longtemps. Quand ils deviennent visibles depuis Windows, l'usure est déjà avancée.

chkdsk a terminé et Windows redémarre. Puis-je continuer à utiliser mon PC ?
S'il n'a affiché que des erreurs logiques (« incorrect », orphelins, 0 Ko défectueux) : oui. S'il a affiché « illisible », « c0000185 » ou des secteurs défectueux : utilisez ce sursis pour sauvegarder, pas pour reprendre vos habitudes. Le disque est à remplacer.

Que faire des fichiers .chk du dossier found.000 ?
Copiez le dossier ailleurs, puis examinez les copies. Les sous-dossiers dir0000.chk contiennent souvent des fichiers avec leur nom d'origine. Les file0000.chk sont des fragments à identifier. Ne supprimez found.000 qu'après avoir vérifié qu'il ne vous manque aucun document.

chkdsk reste bloqué à 10 % ou tourne depuis des heures. Je coupe ?
Tant que le disque travaille (voyant d'activité, bruit), non : couper pendant une écriture peut aggraver la corruption. Un chkdsk interminable est lui-même un signe de disque malade, qui insiste sur des zones difficiles. S'il n'y a plus aucune activité depuis plus de deux heures, il est bloqué : éteignez, et ne le relancez pas.

6. Ce que nous pouvons faire pour vous

Dans le cas de l'atelier, la conclusion a été simple : SSD d'origine en fin de vie, données à mettre à l'abri, puis machine remise à neuf. Chaque étape a sa structure :

• Récupérer les données d'un disque ou d'un SSD qui lâche : BSC DataRecovery, notre laboratoire de récupération de données. L'image du disque est réalisée sur un équipement professionnel qui contrôle le disque au plus bas niveau, contourne les zones mortes et ne force jamais un support fragile. C'est la bonne porte dès que chkdsk affiche « illisible » ou « c0000185 » et que vos fichiers comptent. Vous n'êtes pas dans le Var ? Le disque s'envoie par colis suivi, l'estimation se demande en ligne sur bsc-datarecovery.fr.

• Remplacer le disque et réinstaller Windows : BSC Informatique, atelier au 18 avenue Olbius Riquier, 83400 Hyères, 04 94 27 65 95. Nous fournissons et posons le SSD adapté à votre machine (sur ce tout-en-un, un 500 Go à la place des 128 Go d'origine, devenus trop justes pour Windows 11), réinstallons un Windows à jour et remettons vos données en place. Avant une réinstallation, lisez aussi Réinstaller Windows sans perdre ses données. Et si la machine est ancienne, notre guide réparer ou remplacer son ordinateur vous aide à décider.

• Besoin d'un ordinateur pendant l'intervention : BSC Location vous loue un PC fixe ou portable à la journée, à la semaine ou au mois.

• Vous êtes un particulier et préférez une remise en route chez vous (messagerie, imprimante, box, comptes) une fois le PC réparé : BSC Assistance, assistance informatique à domicile, agréée service à la personne.

Sources : documentation Microsoft Learn (commande chkdsk, étapes et options /f et /r ; codes d'état NTSTATUS, 0xC0000185 STATUS_IO_DEVICE_ERROR ; environnement de récupération Windows et journaux LogFiles\Srt). Complété par la pratique de l'atelier BSC Informatique, en particulier un cas traité en septembre 2026 : tout-en-un Acer Aspire C27 de 2019, SSD M.2 SATA 128 Go d'origine, boucle de réparation automatique, chkdsk /f de 13 minutes relevant 4 segments de MFT consécutifs illisibles, 4 erreurs de lecture c0000185 sur des index de dossiers, 92 fichiers orphelins dont 90 reconnectés, 2 dans found.000, 4 Ko de secteurs défectueux. Les manipulations décrites engagent la responsabilité de celui qui les réalise. BSC Informatique, EURL BSC INFORMATIQUE, 18 Avenue Olbius Riquier, 83400 Hyères, 04 94 27 65 95.

Disque qui montre des signes de faiblesse, à Hyères

chkdsk affiche « illisible » ou « c0000185 » : diagnostic,
image du disque, remplacement, particuliers et professionnels.

Tél. 04 94 27 65 95