Que faire tout de suite
- Vérifiez la corbeille, puis clonez à nouveau le dépôt s’il avait été poussé vers un serveur distant.
- Si le dossier .git a survécu, utilisez git restore, git reflog et git stash pour ramener fichiers et commits.
- Pour le travail non commité, consultez la Chronologie de VS Code ou Local History de JetBrains avant d’analyser le disque depuis une clé USB.
Étape par étape
Arrêtez les builds et regardez la corbeille
N’exécutez ni installation de paquets, ni build, ni tests sur ce disque, car ils écrivent des milliers de fichiers. Regardez d’abord la corbeille : ce qui est supprimé depuis l’Explorateur ou de nombreux IDE y va en général, alors que des commandes comme rm -rf, del, Remove-Item ou git clean la contournent.
Clonez à nouveau depuis le dépôt distant
Si le projet avait été poussé vers GitHub, GitLab ou un autre serveur, clonez-le dans un nouveau dossier. Tout ce qui avait été commité et poussé revient à l’identique. Seul le travail local jamais poussé manque encore.
Servez-vous de git si .git a survécu
Si seuls quelques fichiers ont disparu, git status les liste et git restore suivi du chemin ramène en général leur dernière version commitée. Après un git reset --hard malencontreux, git reflog affiche les commits antérieurs auxquels revenir. Consultez git stash list pour le travail mis de côté. Les fichiers indexés avec git add mais jamais commités se retrouvent parfois avec git fsck --lost-found.
Consultez l’historique local de l’éditeur
Dans VS Code, ouvrez la vue Chronologie d’un fichier ; l’historique local est conservé à part du projet. Pour un fichier supprimé, créer un fichier vide au même chemin fait souvent apparaître ses anciennes entrées. Dans les IDE JetBrains, faites un clic droit sur le dossier du projet, ouvrez Local History puis Show History : les fichiers supprimés y figurent et peuvent être restaurés.
Analysez le disque pour retrouver le dossier
Lancez la version portable de FileFix Ultimate depuis une clé USB, ouvrez Récupération de fichiers supprimés, choisissez le disque et démarrez l’Analyse équilibrée. Parcourez l’arborescence jusqu’au chemin du projet ou filtrez sur des extensions comme cs, py, js, ts ou java. Ignorez les dossiers de dépendances et de build, qui se régénèrent.
Enregistrez ailleurs et vérifiez le code
Enregistrez le dossier récupéré sur un autre disque physique. Ouvrez-le à son nouvel emplacement, lancez le build et les tests, et comparez avec le dépôt distant via git diff, car un fichier revenu en partie écrasé peut sembler correct au premier coup d’œil.
Pourquoi git l’emporte souvent sur une analyse du disque
Le dossier .git conserve, sous forme compressée, toutes les versions commitées de chaque fichier suivi. Tant qu’il existe, en local ou sur un serveur distant, le code commité n’est pas vraiment perdu : le récupérer est une question de bonne commande. C’est aussi pourquoi supprimer un dossier de projet contenant .git fait plus mal que supprimer quelques fichiers, puisque l’historique part avec lui s’il n’avait pas été poussé.
Les modifications non commitées sont une autre histoire. Git ne les a jamais vues : les sources réalistes sont l’historique local de l’éditeur, ses sauvegardes d’onglets non enregistrés et le disque lui-même. La recherche de fichiers non enregistrés de FileFix Ultimate cherche aussi les copies de secours de VS Code et Notepad++, qui peuvent contenir le code d’onglets ouverts à la fermeture de l’éditeur.
Ce qu’une analyse peut faire, ou non, avec le code source
Les photos et les documents commencent par un en-tête reconnaissable, si bien qu’une recherche par signature les retrouve même quand le système de fichiers les a oubliés. Le code source est du texte brut sans en-tête de ce genre. Pour le code, tout dépend des enregistrements du système de fichiers : si les entrées NTFS du dossier supprimé subsistent, noms, chemins et arborescence reviennent ensemble ; si elles ont été réutilisées, les fichiers texte deviennent pratiquement introuvables.
Sous NTFS, les très petits fichiers sont souvent stockés dans leur propre enregistrement, ce qui explique que de courts fichiers de configuration ou de code survivent parfois quand les gros ont disparu. Les ressources binaires du projet, comme images, archives ou bases SQLite, restent trouvables par signature, mais sans leur nom.
Projets dans WSL ou dans des machines virtuelles
Le code conservé dans WSL 2 se trouve dans un fichier de disque virtuel, généralement nommé ext4.vhdx, qui contient un système de fichiers ext4. Exécutez wsl --shutdown, copiez ce fichier sur un autre disque et ouvrez la copie ; FileFix Ultimate sait ouvrir les images VHDX et lire ext4 en lecture seule. Les fichiers supprimés dans ext4 sont plus difficiles à récupérer avec leur nom que sous NTFS : voyez-y une chance plutôt qu’une voie sûre. Les disques VMDK, VHDX et QCOW2 de machines virtuelles s’ouvrent de la même manière.
Quand cela ne fonctionnera pas
- La plupart des machines de développement utilisent un SSD avec TRIM, qui peut effacer les fichiers supprimés presque aussitôt ; le code non commité peut alors être définitivement perdu.
- Si une installation de paquets ou un build a tourné sur le même disque après la suppression, l’espace libre a probablement été réutilisé.
- Sans enregistrements du système de fichiers, les fichiers source en texte brut ne peuvent pas être retrouvés par signature.
- Un travail jamais commité, poussé ni capturé par l’historique de l’éditeur n’a plus de copie une fois l’espace écrasé.
Comment FileFix Ultimate vous aide
- Gratuit pour un usage personnel et sans limite (licence annuelle par PC pour un usage professionnel), avec une version portable qui s’exécute depuis une clé USB pour ne rien écrire de nouveau sur le disque de développement.
- Reconstruit les arborescences supprimées à partir des enregistrements NTFS, FAT32 et exFAT, en conservant noms et chemins quand ces enregistrements existent.
- Retrouve, avec la recherche de fichiers non enregistrés, les sauvegardes VS Code et Notepad++ d’onglets jamais enregistrés.
- Ouvre les images VHDX, VMDK et QCOW2 et lit ext4 en lecture seule pour le code conservé dans WSL ou des machines virtuelles.
FileFix Ultimate est gratuit pour un usage personnel, fonctionne hors ligne et n’écrit jamais sur le lecteur à partir duquel vous récupérez les données. L’usage professionnel nécessite une licence d’un an par PC. Vérifiez la signature avant de l’exécuter.
Questions fréquentes
J’ai lancé git reset --hard. Puis-je récupérer mes commits ?
En général, oui. Lancez git reflog, repérez le commit d’avant le reset et créez une branche dessus ou revenez-y. Les modifications jamais commitées ne figurent pas dans le reflog ; seules celles qui étaient indexées peuvent réapparaître avec git fsck.
git clean envoie-t-il les fichiers à la corbeille ?
Non. git clean supprime directement les fichiers non suivis, qui n’apparaissent donc pas dans la corbeille. Restent l’historique local de l’éditeur ou une analyse du disque.
Faut-il aussi récupérer node_modules et les dossiers de build ?
Non. Ils se régénèrent à partir des fichiers du projet et du fichier de verrouillage : il est plus rapide et plus sûr de les réinstaller une fois le code revenu. Les laisser de côté rend aussi la récupération plus légère et plus rapide à vérifier.
Les fichiers récupérés garderont-ils leurs noms et leurs dossiers ?
S’ils sont retrouvés via les enregistrements du système de fichiers, oui. Les fichiers source ne peuvent pas être retrouvés autrement : un fichier qui apparaît dans l’arborescence apparaît donc en général avec son nom.