Récupérer des fichiers supprimés sur NTFS sans logiciels frauduleux

février 24, 2026 • février 24, 2026 • Lecture : 29 min • Views: 0

Cet article vous a aidé ?

Quelqu’un a supprimé un fichier. Ça comptait. Peut-être que c’était la seule copie, peut-être que c’était la présentation trimestrielle qui « avait bien été enregistrée », ou peut-être que c’était le dossier que la tâche de sauvegarde a ignoré pendant six mois. Quoi qu’il en soit, vous regardez maintenant un volume NTFS et vous ressentez l’envie familière : le chercher sur Google, télécharger le premier outil de récupération qui promet des miracles, cliquer sur « Start Scan » et espérer.

N’y allez pas. La façon la plus rapide de transformer « récupérable » en « perdu » est de continuer à écrire sur le disque—surtout en installant au hasard un logiciel de récupération dessus. Cet article explique comment récupérer des fichiers supprimés sur NTFS avec sang-froid, des capacités intégrées et quelques utilitaires réputés et non frauduleux—tout en comprenant ce qui se passe réellement sous le capot.

Règles de base : arrêter l’hémorragie d’abord

Si vous ne retenez qu’une chose : la récupération est une course contre les écritures. NTFS n’est pas magique. Les données supprimées ont tendance à rester tant que l’espace n’a pas été réutilisé. Chaque écriture—cache du navigateur, mises à jour Windows, téléchargements, « juste installer un outil »—est un coup de dés contre votre fichier manquant.

Les cinq premières minutes

Arrêtez d’utiliser le disque affecté. Ne le parcourez pas, n’y installez pas d’outils, ne « vérifiez qu’une chose ».
Si c’est le disque système, éteignez-le. Un OS en fonctionnement écrit constamment (logs, fichier d’échange, index de recherche, télémétrie, etc.).
Décidez où ira la sortie de la récupération. Pas sur le même volume. Pas « un autre dossier sur C: ». Utilisez un disque physique différent.

Petite plaisanterie courte : vos fichiers supprimés sont comme des chaussettes dans un sèche-linge—techniquement toujours dans la maison, mais ne continuez pas à les faire tourner si vous voulez les retrouver.

Quand abandonner et appeler un labo

Il y a une ligne entre « récupération de fichiers supprimés » et « récupération de matériel défaillant ». Si le disque clique, se déconnecte, affiche des erreurs de lecture ou que SMART semble mauvais, arrêtez de jouer au héros. Les laboratoires professionnels ont du matériel en chambre blanche et des outils firmware que vous n’avez pas. Votre travail est d’éviter d’empirer la situation et de préserver les preuves (oui, même si c’est juste un PDF fiscal).

Comment la « suppression » fonctionne réellement sur NTFS (et quand elle ne fonctionne pas)

NTFS a quelques structures centrales qui importent pour la récupération :

MFT (Master File Table) : la base de données des fichiers. Chaque fichier a un enregistrement avec des métadonnées et des pointeurs vers l’emplacement du contenu.
$Bitmap : suit quels clusters sont libres/occupés.
Répertoires : essentiellement des index qui mappent les noms aux enregistrements MFT.
Journal / journalisation : NTFS journalise les changements de métadonnées pour la cohérence.

Lorsque vous « supprimez » un fichier, NTFS fait typiquement :

Supprime l’entrée de nom de fichier de l’index de répertoire (ou la marque comme supprimée).
Marque l’enregistrement MFT comme disponible pour réutilisation.
Marque les clusters comme libres dans $Bitmap.

Les clusters de contenu ne sont pas nécessairement effacés. Ils deviennent simplement utilisables pour réécriture. C’est pourquoi « undelete » peut fonctionner—jusqu’à ce que ça ne fonctionne plus.

Le succès de la récupération dépend de la disposition du fichier

Deux résultats courants :

Meilleur cas : données contiguës, enregistrement MFT intact. La récupération peut être propre et rapide.
Mode difficile : données fragmentées, enregistrement MFT réutilisé. Vous pouvez obtenir des données partielles, des fichiers corrompus, ou aucun résultat exploitable.

Les SSD changent les règles (TRIM)

Si le fichier supprimé résidait sur un SSD et que TRIM est activé, l’OS peut informer le disque que certains blocs ne sont plus nécessaires. Le SSD peut alors les effacer en interne. Cela peut rendre la récupération beaucoup moins réussie que sur des disques rotatifs.

Volumes chiffrés : BitLocker et consorts

Si le disque est chiffré avec BitLocker, vous pouvez toujours récupérer des fichiers—tant que vous pouvez accéder au volume (clé disponible) et que vous imagez/récupérez au niveau logique. Si vous n’avez que des blocs bruts du disque sans clé, la récupération est une autre discussion.

Mode d’urgence : diagnostic rapide (quoi vérifier 1er/2e/3e)

Quand vous êtes sous pression, vous avez besoin d’une boucle de triage serrée. Voici la mienne pour les suppressions NTFS.

Premier : s’agit-il d’un « supprimé », « déplacé » ou « jamais écrit » ?

Vérifiez la Corbeille (locale, pas les partages réseau par défaut).
Vérifiez si le fichier a été déplacé dans un autre dossier ou renommé (recherchez par contenu/type si possible).
Vérifiez la synchronisation cloud (OneDrive/SharePoint historique des versions) et les sauvegardes.

Second : le support de stockage est-il encore stable ?

Si le disque est en panne (erreurs E/S, lectures lentes, avertissements SMART), imagez immédiatement et arrêtez d’analyser le disque en direct.
Si c’est un SSD avec TRIM, agissez vite et réduisez vos attentes.

Troisième : choisissez la voie de récupération la moins invasive

Clichés VSS / Versions précédentes → restauration rapide et propre (lorsque activé).
Windows File Recovery (winfr) → bon pour les scénarios courants, mais nécessite des paramètres prudents.
Imagerie hors ligne + ntfsundelete/photorec-style carving → meilleur quand les outils OS échouent ou que le disque est instable.

Comment les logiciels de récupération frauduleux vous piègent

La plupart des arnaques ne sont pas subtiles. Elles sont simplement optimisées pour la panique :

Elles promettent « 100 % de récupération » ou « récupérer n’importe quoi instantanément ». En réalité : la récupération est probabiliste.
Elles montrent un scan spectaculaire avec des milliers de « fichiers récupérables », puis placent la restauration derrière un paywall.
Elles installent des barres d’outils de navigateur, des « optimiseurs système » ou des pilotes non demandés.
Elles vous encouragent à installer l’outil sur le disque affecté (ce qui écrase ce que vous essayez de récupérer).

Conseil opinionné : si un outil ne vous dit pas techniquement ce qu’il fait, ne le lancez pas sur des données de production. En récupération, vous voulez un comportement ennuyeux, prévisible et des sorties claires—pas du marketing.

Récupération Windows : Corbeille, Versions précédentes et winfr

Corbeille : le gain le plus simple

Si le fichier a été supprimé via l’Explorateur depuis un disque NTFS local, il va généralement dans la Corbeille. Shift+Delete l’évite. Certaines applications l’évitent. Beaucoup de partages réseau l’évitent. Mais vérifiez quand même—parce que c’est gratuit, instantané et ne mutile rien.

Versions précédentes / Clichés shadow (VSS)

« Versions précédentes » est l’interface utilisateur du Volume Shadow Copy Service (VSS). Si la Protection du système est activée pour le volume ou si des sauvegardes intègrent VSS, vous pouvez restaurer :

le fichier lui-même,
ou le dossier tel qu’il existait à un instant antérieur.

C’est la récupération la plus propre parce qu’elle ne devine pas ; elle restaure à partir d’un instantané réel.

Windows File Recovery (winfr)

Le logiciel de Microsoft Windows File Recovery (la commande winfr) est le bon choix par défaut quand vous êtes sur Windows moderne et que vous voulez un outil légitime sans le côté louche. Ce n’est pas esthétique, mais c’est réel.

Détails opérationnels importants :

La sortie va sur un autre disque. Toujours.
Le mode compte. Régulier vs Extensive, et le comportement de scan segment/signature.
Le filtrage par chemin compte. Sinon vous récupérerez la moitié des restes de Windows et vous serez noyé.

Faites comme un SRE : imager d’abord, récupérer ensuite

Sur des disques stables, vous pouvez parfois récupérer directement. Sur tout support même légèrement douteux—ou si le fichier a une vraie valeur—imagez d’abord. L’imagerie vous donne :

Un artefact stable que vous pouvez scanner plusieurs fois sans usure supplémentaire.
Un point de restauration si un outil se comporte mal.
La préservation des preuves si cela devient un événement d’audit/juridique (oui, ça arrive).

Deuxième plaisanterie courte : la récupération de données sans imagerie, c’est comme opérer sur un bus en marche—exaltant, mais pas pour de « bons résultats ».

Bloqueurs d’écriture et montages en lecture seule

En criminalistique idéale, on utilise un bloqueur d’écriture matériel. Dans la vraie vie, au moins montez le disque en lecture seule quand vous scannez depuis Linux, et évitez de démarrer Windows à partir de ce disque.

Outils Linux pour la récupération NTFS (en sécurité)

Linux est utile parce qu’il est facile de traiter le disque comme un objet, de le monter en lecture seule et d’imager avec des outils matures. Un flux de travail typique :

Démarrer depuis un environnement live.
Identifier le disque et les partitions.
Vérifier les problèmes matériels (SMART, dmesg).
Imager la partition (ou le disque complet) vers un autre disque.
Exécuter des outils de récupération contre l’image.

Deux outils réputés et courants dans cet espace :

ntfs-3g / ntfsprogs utilitaires (y compris ntfsundelete dans certaines distributions) pour des tentatives d’undelete basées sur la MFT.
testdisk/photorec pour la récupération et le carving quand les métadonnées ont disparu (le carving peut récupérer le contenu mais souvent perd les noms de fichiers et la structure des dossiers).

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

Voici des tâches réelles que vous pouvez lancer. Les commandes sont présentées dans un format shell cohérent. Lisez la partie « décision » ; c’est là que la plupart des récupérations se gagnent.

Task 1 — Confirm which disk is the target (Linux)

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS
NAME   SIZE MODEL            SERIAL        FSTYPE MOUNTPOINTS
sda  931.5G Samsung_SSD_860  S3Z9NB0K12345
├─sda1 100M                                vfat   /boot/efi
├─sda2  16M
└─sda3 931.4G                              ntfs
sdb    3.6T WDC_WD40EFRX    WD-WCC4E123456
└─sdb1  3.6T                              ext4   /mnt/recovery

Ce que cela signifie : sda3 est une partition NTFS—probablement celle que vous voulez. sdb1 est votre disque de destination monté sur /mnt/recovery.

Décision : Si vous n’avez pas de disque de destination séparé monté, arrêtez ici et procurez-vous-en un. N’imaginez pas sur le même disque physique.

Task 2 — Check if the NTFS partition is mounted read-write (Linux)

cr0x@server:~$ mount | grep sda3
/dev/sda3 on /mnt/ntfs type ntfs3 (rw,relatime,uid=0,gid=0,iocharset=utf8)

Ce que cela signifie : Elle est montée rw (lecture-écriture). C’est dangereux pour la récupération.

Décision : Démontez et remontez en lecture seule avant de scanner.

Task 3 — Remount NTFS read-only (Linux)

cr0x@server:~$ sudo umount /mnt/ntfs
cr0x@server:~$ sudo mount -t ntfs3 -o ro /dev/sda3 /mnt/ntfs
cr0x@server:~$ mount | grep sda3
/dev/sda3 on /mnt/ntfs type ntfs3 (ro,relatime)

Ce que cela signifie : La partition est maintenant en lecture seule.

Décision : Continuez avec le diagnostic/l’imagerie. Si vous ne pouvez pas monter en lecture seule, ne forcez pas—imaginez le périphérique brut à la place.

Task 4 — Check kernel logs for I/O errors (Linux)

cr0x@server:~$ dmesg | tail -n 12
[  842.112233] sd 0:0:0:0: [sda] tag#23 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[  842.112240] sd 0:0:0:0: [sda] Sense Key : Medium Error [current]
[  842.112245] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error
[  842.112260] blk_update_request: I/O error, dev sda, sector 1953525168

Ce que cela signifie : Le disque retourne des erreurs de lecture.

Décision : Arrêtez les scans par fichiers. Passez à l’imagerie avec un outil conçu pour les médias défaillants (ou à un labo). Les scans répétés amplifient les dommages et les timeouts.

Task 5 — Quick SMART health check (Linux)

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i "model|realloc|pending|uncorrect|power_on|smart overall"
Device Model:     Samsung SSD 860
SMART overall-health self-assessment test result: PASSED
Power_On_Hours:   18432
Reallocated_Sector_Ct: 0
Current_Pending_Sector: 0
Offline_Uncorrectable: 0

Ce que cela signifie : Cet exemple semble sain. SMART n’est pas parfait, mais c’est un bon indice.

Décision : Si SMART montre des reallocations/pending/uncorrectables en hausse, traitez-le comme défaillant. Si ça semble correct, vous pouvez continuer—toujours en priorisant l’imagerie si les données comptent.

Task 6 — Check TRIM status on Windows (for SSD realism)

cr0x@server:~$ fsutil behavior query DisableDeleteNotify
NTFS DisableDeleteNotify = 0  (Disabled = 1, Enabled = 0)

Ce que cela signifie : Les notifications de suppression (TRIM) sont activées pour NTFS.

Décision : Si le fichier supprimé était sur un SSD et que TRIM est activé, priorisez la récupération basée sur snapshots (VSS, sauvegardes, versions cloud). Les chances d’undelete peuvent être faibles.

Task 7 — Check BitLocker status (Windows)

cr0x@server:~$ manage-bde -status C:
Volume C: [OS]
    Conversion Status:    Fully Encrypted
    Percentage Encrypted: 100.0%
    Protection Status:   Protection On
    Lock Status:         Unlocked

Ce que cela signifie : Le volume est chiffré mais actuellement déverrouillé.

Décision : Vous pouvez exécuter une récupération logique (winfr, restauration VSS) normalement tant que le volume est déverrouillé. S’il est verrouillé et que vous n’avez pas les clés, arrêtez et résolvez d’abord l’accès.

Task 8 — Check for Shadow Copies via PowerShell (Windows)

cr0x@server:~$ vssadmin list shadows
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
Contents of shadow copy set ID: {d3a2c6f0-1d0a-4c0b-9a9a-9c2d6a0cbe12}
   Contained 1 shadow copies at creation time: 1/20/2026 9:14:22 AM
      Shadow Copy ID: {a31f45e3-1d57-4e2b-a5f5-9c4df0e0b4ce}
      Original Volume: (C:)\\?\Volume{11111111-2222-3333-4444-555555555555}\
      Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8\
      Provider: 'Microsoft Software Shadow Copy provider 1.0'
      Type: ClientAccessibleWriters
      Attributes: Persistent, Client-accessible, No auto release, Differential

Ce que cela signifie : Il y a au moins un cliché shadow disponible.

Décision : Essayez de restaurer à partir des clichés shadow en priorité. C’est peu risqué et conserve les noms et la structure des fichiers.

Task 9 — Restore a file from “Previous Versions” via GUI? No—mount the shadow copy (Windows)

cr0x@server:~$ mklink /d C:\Shadow8 \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8\
symbolic link created for C:\Shadow8 <<<===>>> \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8\

Ce que cela signifie : Vous avez créé un lien de répertoire pour parcourir le snapshot comme un dossier.

Décision : Copiez le fichier manquant depuis C:\Shadow8\Users\... vers un emplacement sûr. Ne « restaurez pas en place » si vous n’êtes pas sûr ; copiez d’abord, vérifiez, puis décidez.

Task 10 — Use Windows File Recovery (winfr) for a specific folder (Windows)

cr0x@server:~$ winfr C: E: /regular /n \Users\alice\Documents\Q4\*
Windows File Recovery 1.0.0.0
Scanning disk: C:
Scanning completed.
Recovered files: 14
Recovery completed. View your recovered files in E:\Recovery_2026_02_04\

Ce que cela signifie : winfr a trouvé et récupéré 14 fichiers correspondant au filtre de chemin.

Décision : Validez les fichiers récupérés (ouvrez-les, vérifiez les tailles/hashes si nécessaire). Si des fichiers clés manquent, relancez avec /extensive ou d’autres filtres, mais gardez la sortie sur E:.

Task 11 — Use winfr in Extensive mode with signature types (Windows)

cr0x@server:~$ winfr C: E: /extensive /y:pdf,docx,xlsx /n \Users\alice\Documents\
Windows File Recovery 1.0.0.0
Scanning disk: C:
Scanning completed.
Recovered files: 63
Recovery completed. View your recovered files in E:\Recovery_2026_02_04\

Ce que cela signifie : Le mode Extensive plus signatures a récupéré plus de fichiers, possiblement sans chemins originaux.

Décision : Si vous voyez beaucoup de fichiers sans noms, cela suggère que les métadonnées ont été partiellement perdues. Utilisez des hash et des timestamps pour identifier les bons ; évitez d’écraser les originaux.

Task 12 — Check whether the file was actually removed or just hidden/attributed weirdly (Windows)

cr0x@server:~$ attrib "C:\Users\alice\Documents\Q4\budget.xlsx"
A    C:\Users\alice\Documents\Q4\budget.xlsx

Ce que cela signifie : Le fichier existe et n’est pas caché/système (vous verriez H ou S).

Décision : Si le fichier existe, arrêtez la récupération. Votre problème est probablement au niveau applicatif (mauvais emplacement d’enregistrement) ou de synchronisation/versioning, pas une suppression.

Task 13 — Image the NTFS partition with ntfsclone (Linux)

cr0x@server:~$ sudo ntfsclone --save-image --output /mnt/recovery/sda3.ntfsclone.img /dev/sda3
ntfsclone v2022.10.3 (libntfs-3g)
Cluster size           : 4096 bytes
Current volume size    : 931.4 GB (227153920 clusters)
Saving NTFS to image ...
100.00 percent completed
Syncing ...
NTFS image successfully saved to '/mnt/recovery/sda3.ntfsclone.img'

Ce que cela signifie : Vous avez capturé une image du système de fichiers NTFS (souvent de manière efficace, pas forcément secteur par secteur brut).

Décision : Effectuez la récupération contre l’image. Conservez l’état du disque original au cas où vous auriez besoin d’un autre outil plus tard.

Task 14 — Create a raw image with dd (only on healthy media) (Linux)

cr0x@server:~$ sudo dd if=/dev/sda of=/mnt/recovery/sda.raw.img bs=16M status=progress conv=noerror,sync
1207959552 bytes (1.2 GB, 1.1 GiB) copied, 3 s, 403 MB/s
...
1000204886016 bytes (1.0 TB, 932 GiB) copied, 2514 s, 398 MB/s

Ce que cela signifie : Vous copiez tout le disque. noerror,sync tente de continuer en cas d’erreurs (mais c’est rudimentaire).

Décision : Si vous voyez de nombreux ralentissements ou erreurs, arrêtez et passez à un imager dédié pour disques défaillants. dd brut peut gaspiller du temps et stresser le matériel.

Task 15 — Attempt undelete via ntfsundelete (Linux, if available)

cr0x@server:~$ sudo ntfsundelete /dev/sda3 --scan | head -n 12
Inode    Flags  %age  Date        Time     Size  Filename
----------------------------------------------------------------
102934   FN..  100%  2026-02-03  16:22  248832  budget.xlsx
102941   FN..   92%  2026-02-03  16:20  1048576 Q4-forecast.xlsx

Ce que cela signifie : Il a trouvé des entrées supprimées et estime la récupérabilité (%age). 100 % suggère que les clusters n’ont pas été réutilisés.

Décision : Si votre fichier cible montre une forte récupérabilité, tentez une récupération ciblée vers un disque différent. S’il est faible, privilégiez VSS/sauvegardes ou le carving par signature.

Task 16 — Recover a specific inode with ntfsundelete (Linux)

cr0x@server:~$ sudo ntfsundelete /dev/sda3 --undelete --inode 102934 --output /mnt/recovery/recovered
Undeleting inode 102934 ... OK
Writing recovered file to: /mnt/recovery/recovered/budget.xlsx

Ce que cela signifie : Il a restauré le contenu qu’il pouvait mapper depuis les métadonnées NTFS.

Décision : Validez le fichier (ouvrez-le, vérifiez la taille). S’il s’ouvre mais présente des parties corrompues, vos clusters ont été partiellement écrasés—essayez d’autres sources de récupération plutôt que de frapper à nouveau le disque.

Task 17 — Quick integrity check with hashes (Linux)

cr0x@server:~$ sha256sum /mnt/recovery/recovered/budget.xlsx
7b5f7ff3a7f7f06a9f9b5de3d2996e22b7b9d9a2d2b1a87ddc1d3b9a1f4c2a10  /mnt/recovery/recovered/budget.xlsx

Ce que cela signifie : Vous avez une empreinte stable du fichier récupéré.

Décision : Si vous récupérez plusieurs versions candidates, hachez-les et comparez tailles/timestamps. Choisissez celle qui correspond au contenu attendu, pas celle qui a le plus joli nom de fichier.

Trois mini-récits d’entreprise tirés du terrain

Mini-récit n°1 : L’incident causé par une mauvaise hypothèse

Une équipe finance a perdu un dossier de feuilles de calcul depuis un poste de travail Windows partagé. Le premier intervenant—un généraliste IT par ailleurs compétent—supposa que c’était « juste supprimé » et lança un scan de récupération directement sur le lecteur C:. Ils installèrent aussi une suite de récupération sur C: parce que l’installateur y mettait par défaut et personne ne voulait discuter des paramètres pendant une panne.

Le scan trouva « des milliers de fichiers récupérables », ce qui rassurait. L’outil commença alors à écrire les sorties récupérées dans un dossier sur C: parce que, encore une fois, paramètres par défaut. Entre-temps Windows Update estima qu’il avait assez attendu et commença à télécharger des patchs. Le système fit ce que font les systèmes : il écrivit constamment sur le disque.

Au moment de l’escalade, les feuilles de calcul manquantes figuraient toujours « trouvées » par nom mais s’ouvraient comme des conteneurs zip corrompus (les fichiers Office modernes sont essentiellement des archives zip). Nous imagions quand même le disque et avons tenté une récupération basée sur les métadonnées. Les entrées MFT étaient encore là, mais des clusters critiques avaient été réutilisés par l’installateur, les fichiers de sortie et l’activité OS habituelle.

La récupération finale vint d’un endroit profondément peu glamour : OneDrive avait discrètement synchronisé un sous-ensemble du dossier quelques jours plus tôt. Pas tout. Suffisamment pour reconstruire. La grande leçon n’était pas « utilisez OneDrive ». C’était « les hypothèses écrivent des données ». L’hypothèse que scanner in situ est sans danger est la façon dont on perd la dernière bonne copie.

Mini-récit n°2 : L’optimisation qui a mal tourné

Une équipe dev voulait des laptops plus rapides. Quelqu’un proposa de réduire l’empreinte disque locale en désactivant la Protection du système (pas de points de restauration) et en supprimant des « services inutiles ». C’était présenté comme de l’hygiène performance. Ils l’ont déployé via une stratégie, et cela réduisit le travail en arrière-plan.

Trois mois plus tard, un ingénieur supprima un répertoire d’artefacts de test locaux qui contenait aussi des logs fournis par un client. Les logs n’étaient pas censés rester à long terme sur le laptop, mais la réalité ne lit pas les politiques. L’ingénieur utilisa Shift+Delete par habitude.

Sans clichés VSS, « Versions précédentes » était vide. Avec des SSD et TRIM activé, les chances d’undelete étaient déjà faibles. L’équipe essaya winfr ; il récupéra quelques PDFs mais pas les logs clés. Photorec a ensuite produit des fichiers texte partiels sans en-têtes et hors contexte ; les noms de fichiers étaient perdus, et les apparier aux dossiers clients devint un incident en soi.

L’optimisation a économisé un peu d’espace disque et un peu de CPU. Elle coûte des jours de temps d’ingénierie et une conversation client difficile. Le suivi n’a pas été « tout activer pour toujours ». Il fut ciblé : garder la Protection du système activée pour les endpoints manipulant des données clients, forcer la redirection vers des emplacements sauvegardés et former les gens que Shift+Delete est un engagement, pas un raccourci.

Mini-récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise de taille moyenne gérait un serveur de fichiers Windows avec des volumes NTFS. Rien de sophistiqué. L’équipe SRE (oui, SRE sur Windows) avait une règle impopulaire : les partages critiques exigeaient des clichés VSS nocturnes et des tests de restauration hebdomadaires. Aucune exception. C’était le genre de politique qui fait soupirer en réunion.

Un matin, un répertoire de projet était « manquant ». Pas un fichier—un sous-arbre entier. Quelqu’un avait lancé un script de nettoyage avec un bug de chemin. La suppression se propagea rapidement, et comme c’était un serveur, la panique arriva avant l’analyse de la cause racine.

L’intervenant n’a pas ouvert Google. Il n’a rien téléchargé. Il vérifia la disponibilité des snapshots, monta le cliché shadow pertinent et copia le répertoire vers un emplacement de quarantaine. Il valida quelques gros fichiers, puis restaura l’arbre complet. Le temps d’arrêt se compta en minutes, pas en jours.

Plus tard, nous fîmes quand même le travail sérieux : post-mortem, sécurités sur les scripts, principe du moindre privilège. Mais la récupération elle-même fut ennuyeuse et rapide. C’est la norme d’or. La fiabilité est surtout un empilement de pratiques ennuyeuses qui ne semblent impressionnantes que quand tout casse.

Erreurs courantes : symptômes → cause racine → correction

Symptôme : L’outil de récupération « trouve » des fichiers mais les fichiers récupérés ne s’ouvrent pas.: Cause racine : Des clusters ont été partiellement écrasés ; les noms de fichiers ont persisté plus longtemps que le contenu. Courant après utilisation continue ou installation d’outils sur le même disque.; Correction : Arrêtez les écritures, imagez le disque, essayez snapshots/sauvegardes. Pour les documents, essayez des versions alternes (historique cloud). Évitez les scans répétés qui stressent le disque.
Symptôme : La Corbeille est vide, et l’utilisateur jure qu’il a supprimé « normalement ».: Cause racine : Shift+Delete, suppression au niveau applicatif, ou fichier sur un partage réseau/périphérique amovible avec une sémantique différente.; Correction : Vérifiez la corbeille spécifique à l’application (certaines apps en ont une), vérifiez les snapshots côté serveur, puis passez à winfr/ntfsundelete.
Symptôme : winfr récupère des tas de fichiers avec des noms aléatoires.: Cause racine : Récupération basée sur signature (carving) lorsque les métadonnées sont manquantes. Utile, mais perd les noms et la structure.; Correction : Réduisez la recherche par types de fichiers et fenêtre temporelle probable. Utilisez des hash, tailles et contenus internes pour identifier les candidats. Préférez VSS/sauvegardes si possible.
Symptôme : La récupération est extrêmement lente ; le système gèle ; le disque disparaît.: Cause racine : Disque défaillant, bridge USB instable, ou problèmes d’alimentation. Le scan de récupération provoque des lectures répétées de régions défectueuses.; Correction : Arrêtez. Stabilisez le matériel (SATA direct si possible), imagez avec des outils tolérants aux erreurs, ou envoyez en labo si le disque se dégrade.
Symptôme : « Versions précédentes » n’affiche rien.: Cause racine : VSS non activé, pas de points de restauration, ou volume exclu de la protection ; parfois des politiques le désactivent.; Correction : Ne l’activez pas après coup en espérant des clichés rétroactifs. Passez aux sauvegardes/versions cloud ou aux tentatives d’undelete.
Symptôme : Vous avez récupéré sur le même disque et maintenant les résultats sont pires.: Cause racine : Les fichiers de sortie de récupération ont écrasé l’espace libre qui contenait le contenu supprimé.; Correction : Arrêtez immédiatement. Imagez ce qui reste. À l’avenir : récupérez toujours sur un disque physique séparé.
Symptôme : Données supprimées sur SSD introuvables.: Cause racine : TRIM et le garbage collection en arrière-plan ont effacé les blocs.; Correction : Utilisez snapshots/sauvegardes/historique cloud. Pour les incidents SSD de grande valeur : agissez vite, évitez les cycles d’alimentation, et envisagez une récupération professionnelle—mais attendez-vous à des limites.

Listes de contrôle / plan pas à pas

Plan pas à pas : poste standard (PC portable/bureau Windows)

Arrêtez d’utiliser la machine (ou au moins arrêtez d’utiliser le disque affecté). Si c’est le disque OS et que le fichier est critique : éteignez.
Vérifiez la Corbeille. Restaurez à l’emplacement d’origine ou copiez ailleurs.
Vérifiez la synchronisation cloud et l’historique des versions (OneDrive/SharePoint/Dropbox, etc.). Vous voulez des versions serveur quand c’est possible.
Vérifiez les Versions précédentes si activées. Préférez copier depuis un snapshot plutôt que la restauration en place.
Lancez winfr avec un filtre de chemin serré et une sortie sur un disque différent.
Si winfr échoue et que les données ont une forte valeur : imagez le disque, puis tentez la récupération depuis l’image avec des outils réputés.
Validez les fichiers récupérés (ouvrez-les, vérifiez tailles, hashes si pertinent).
Après action : corrigez la cause racine—activez snapshots/sauvegardes, ajustez les workflows utilisateurs et documentez la procédure pour la prochaine fois.

Plan pas à pas : serveur de fichiers / volume NTFS partagé

Arrêtez l’activité : mettez en pause les jobs qui écrivent sur le partage (indexeurs, ETL, processus batch).
Identifiez l’étendue : quels chemins, quelle fenêtre temporelle, qui a supprimé.
Restaurez à partir des snapshots VSS si disponibles ; copiez d’abord en quarantaine.
Si pas de snapshots : restaurez depuis les sauvegardes ; si les sauvegardes sont lentes, faites une restauration ciblée par chemin.
Si pas de sauvegardes : envisagez de mettre le volume hors ligne et d’imager avant d’exécuter des opérations de récupération lourdes.
Postmortem : contrôles d’accès, automatisation plus sûre et procédure de restauration testée.

Checklist : ce qu’il faut éviter (imprimez et affichez)

Installer un logiciel de récupération sur le volume affecté.
Récupérer des fichiers sur le même volume NTFS dont vous récupérez.
Exécuter des scans profonds répétés sur un disque défaillant.
Défragmenter, « optimiser » ou « nettoyer » le disque après une suppression.
Laisser Windows tourner sur le disque OS pendant que vous « réfléchissez ».

Faits et contexte historique (les éléments qu’on oublie)

NTFS a remplacé FAT pour Windows grand public dans les années 1990, apportant journalisation et métadonnées riches—ce qui influence la récupérabilité.
La MFT est centrale : NTFS stocke les enregistrements de fichiers dans la Master File Table ; récupérer les métadonnées signifie souvent récupérer des entrées MFT.
NTFS a un miroir partiel de la MFT pour aider à récupérer de certaines corruptions.
La suppression change généralement les métadonnées, pas les blocs de données ; le contenu reste souvent jusqu’à écrasement, d’où le fait que l’« undelete » ait déjà fonctionné.
Les SSD ont introduit TRIM, qui peut effacer de manière proactive les blocs « supprimés »—excellent pour les performances, terrible pour la récupération post-suppression.
Volume Shadow Copy Service (VSS) existe depuis les années 2000 ; c’est un mécanisme de snapshot largement utilisé par les outils de sauvegarde.
Les fichiers Office modernes sont des conteneurs ZIP (docx/xlsx/pptx), donc un écrasement partiel produit souvent des erreurs « fichier corrompu » même si une partie du contenu subsiste.
chkdsk n’est pas un outil d’« undelete » ; il répare la cohérence du système de fichiers et peut aussi orpheliner ou renommer des fichiers lors des réparations.
Le file carving est antérieur à NTFS comme technique forensique : il trouve des fichiers par signatures, pas par métadonnées du système de fichiers, d’où la perte des noms.

Une citation opérationnelle (idée paraphrasée)

Gene Kranz (idée paraphrasée) : « Tough and competent » est la norme—restez calme, suivez la procédure et n’improvisez pas au risque d’aggraver la situation.

FAQ

1) Puis-je récupérer des fichiers supprimés de NTFS gratuitement ?

Souvent, oui. La Corbeille et les Versions précédentes sont gratuites. Windows File Recovery (winfr) est une option légitime. Les outils Linux sont généralement open-source. Le coût est le temps et la discipline.

2) CHKDSK aide-t-il à récupérer des fichiers supprimés ?

Pas de manière fiable. chkdsk répare les incohérences du système de fichiers. Il peut récupérer des fragments orphelins en fichiers FOUND.000, mais il peut aussi modifier les métadonnées. Exécutez-le uniquement lorsque vous réparez une corruption, pas comme première tentative d’undelete.

3) Quel est le facteur principal qui détermine si la récupération fonctionne ?

Si les clusters ont été écrasés. Si vous continuez à utiliser le disque, vous augmentez la probabilité d’écrasement. Sur les SSD avec TRIM, la suppression peut être suivie d’un effacement effectif.

4) J’ai supprimé un fichier sur un SSD. Suis-je condamné ?

Pas toujours, mais les chances sont plus mauvaises. Si TRIM est activé et que du temps s’est écoulé (ou que le système est resté actif), l’undelete basée sur les métadonnées peut échouer parce que le disque a effacé les blocs. Votre meilleur espoir : snapshots, sauvegardes ou historique des versions cloud.

5) Pourquoi un logiciel de récupération trouve mon nom de fichier mais est-ce corrompu ?

Parce que les entrées de répertoire et les enregistrements MFT peuvent persister plus longtemps que le contenu qu’ils pointent. Le nom est une étiquette ; les clusters de données sont le vrai prix, et ils sont réutilisés.

6) Dois-je imager le disque même s’il semble sain ?

Si les données sont importantes : oui. L’imagerie est une assurance contre les erreurs d’outil et des problèmes disque inattendus. Si c’est peu critique et que le disque est sain, un winfr ciblé peut être acceptable.

7) Puis-je récupérer des fichiers après avoir vidé la Corbeille ?

Parfois. Vider la Corbeille supprime typiquement les références, pas nécessairement le contenu sous-jacent immédiatement. Vos chances dépendent des écritures ultérieures et si vous êtes sur SSD avec TRIM.

8) La défragmentation aide-t-elle la récupération ?

Non. La défragmentation écrit beaucoup de données et réarrange les blocs—exactement ce qu’il ne faut pas faire. Elle peut détruire du contenu supprimé récupérable.

9) Pourquoi certains fichiers récupérés perdent leur structure de dossiers ?

C’est typique du carving basé sur signature. Quand les métadonnées du système de fichiers (chemins, noms) sont perdues ou peu fiables, les outils récupèrent le contenu brut par motifs. Pratique pour les photos et PDFs ; problématique pour des projets Office.

10) Quand dois-je arrêter le bricolage et appeler une récupération professionnelle ?

Quand il y a des erreurs de lecture, que le disque disparaît, que le lecteur fait des bruits inhabituels, ou que la valeur des données est telle que des erreurs coûteraient cher. Aussi quand vous ne pouvez pas justifier pourquoi vous avez continué à « tester des choses » sur la seule copie.

Conclusion : que faire ensuite, aujourd’hui

Si vous gérez actuellement une suppression sur NTFS, effectuez ces étapes suivantes dans l’ordre :

Arrêtez d’écrire sur le disque affecté. Si c’est le disque OS et que le fichier est critique, éteignez.
Essayez les récupérations propres d’abord : Corbeille, historique des versions cloud, Versions précédentes/VSS.
Utilisez winfr avec des filtres serrés et récupérez vers un autre disque.
Si les enjeux sont élevés ou que le disque semble instable : imagez d’abord, puis récupérez depuis l’image avec des outils réputés.
Après coup : corrigez le système pour que la prochaine fois ce soit une simple nuisance—snapshots, sauvegardes, tests de restauration et des workflows utilisateurs sensés.

La récupération ne dépend pas de l’outil le plus chic. Elle dépend de ne pas empirer la situation pendant que vous cherchez la dernière bonne copie. NTFS vous rendra service—si vous arrêtez de piétiner les preuves.