Récupération de données pour développeurs et administrateurs

Les pannes typiques sur un poste de dev ou un serveur

Le disque des projets ne monte plus

Un disque externe USB 3 qui héberge votre arborescence de travail reste invisible dans le gestionnaire de disques, ou claque à l'insertion. Windows le voit comme « non initialisé », Linux renvoie une erreur I/O sur /dev/sdb. La table de partition ou le circuit d'alimentation du boîtier est souvent en cause ; le contenu, lui, peut encore être lisible.

Le SSD du portable ne démarre plus

Après un arrêt brutal, le SSD NVMe n'est plus détecté dans le BIOS. Les contrôleurs de SSD gèrent une table de correspondance entre blocs logiques et cellules physiques ; quand cette table est corrompue ou le micrologiciel planté, le disque devient muet alors que les cellules contiennent toujours vos fichiers. Le chiffrement matériel complique ensuite la lecture.

Dépôt Git ou dossier de code effacé

Un rm -rf mal placé, un git clean -fdx trop large, un formatage rapide lors d'une réinstallation. Tant que le système de fichiers n'a pas réécrit sur les blocs libérés, les objets Git (y compris le dossier caché .git et ses packfiles) restent récupérables. Un git reset --hard non commité, en revanche, ne laisse rien sur le disque.

Base SQLite, MySQL ou PostgreSQL corrompue

Une coupure de courant pendant un checkpoint, un disque hôte qui renvoie des erreurs d'écriture, et voilà un fichier .ibd, un InnoDB ou un SQLite qui refuse de s'ouvrir. Nous récupérons le fichier de base lui-même ; sa réparation logique (cohérence des pages, journal de transactions) relève ensuite de votre DBA ou d'un outil dédié.

Image de machine virtuelle endommagée

Un fichier VMDK, VDI ou VHDX qui ne se monte plus dans VMware Workstation, VirtualBox ou Hyper-V, ou qui a disparu avec le disque hôte. Ces fichiers sont volumineux et souvent en mode provisionnement dynamique : leur entête décrit la carte des blocs. Un entête abîmé rend l'image illisible sans que les données internes soient perdues.

NAS, baie RAID ou serveur muet

Un volume RAID 5 ou 6 qui passe en « dégradé » puis disparaît après le remplacement d'un disque, un NAS Synology ou QNAP qui ne sort plus de son démarrage, une baie qui affiche un statut inconnu. L'ordre des disques, le niveau RAID et la taille des blocs conditionnent la reconstitution du volume.

Les bons gestes avant l'envoi

• Coupez l'alimentation du support dès la première alerte et ne le remontez plus en lecture : sur un disque qui claque, chaque tentative d'accès use les têtes de lecture et peut rayer la surface.
• Clonez en lecture seule avec ddrescue si vous avez un disque de destination plus grand, puis travaillez uniquement sur le clone : vous préservez l'original et gardez une image exploitable pour nos outils.
• Ne lancez ni fsck, ni chkdsk /f, ni l'utilitaire de disque sur l'original : ces outils réécrivent la table d'allocation et peuvent effacer les entrées des fichiers supprimés que nous cherchons.
• Sur un NAS ou une baie, ne reconstruisez pas le volume et ne remplacez aucun disque : notez la baie, le numéro de chaque emplacement et l'ordre de retrait avant toute manipulation.
• Conservez la clé BitLocker, LUKS ou FileVault, et le mot de passe du volume chiffré : sans elle, la lecture des blocs reste impossible, même sur un disque intact.

Ce que nous vérifions dans vos fichiers récupérés

Une fois la copie intégrale du support réalisée et l'analyse terminée, vous recevez une liste de fichiers. Pour un profil technique, nous la construisons en respectant l'arborescence d'origine : un dossier de projet reste un dossier de projet, avec ses sous-répertoires, son fichier .git et ses fichiers de configuration. Nous vérifions d'abord la présence des types de fichiers attendus — sources .c, .py, .java, .ts, scripts shell, fichiers de build Makefile, pom.xml, package.json — et leur taille cohérente. Les dumps SQL, fichiers .sql, .bak, .ibd, .sqlite, .db sont listés séparément, avec leur date de dernière modification, pour que vous puissiez juger de leur fraîcheur. Les images de machines virtuelles (VMDK, VDI, VHDX) et les archives .zip, .tar.gz apparaissent avec leur taille, ce qui permet de repérer celles qui sont tronquées. Enfin, les métadonnées — dates de création, de modification, chemins — sont conservées quand le système de fichiers d'origine les avait encore ; elles vous aident à distinguer la version qui vous intéresse.

Comment ça se passe et ce que ça coûte

1. Vous décrivez la panne en ligne : bilan sous une heure.

2. Le prix de la récupération vous est annoncé avant l'envoi : 300, 500, 580, 720, 850 ou 1 000 € TTC selon la panne.

3. Vous réglez des frais d'investigation de 90 € ou 150 € TTC avant l'envoi. Ils couvrent l'examen et les premières tentatives de réparation et, en cas d'échec, un diagnostic complet avec bilan final. Ils restent dus même si rien n'est retrouvé ; en cas de succès, ils sont déduits du prix.

4. Le bon de transport Chronopost aller est offert. Nous réalisons une copie intégrale avant toute manipulation.
5. Le solde n'est dû que si vos fichiers sont récupérés, après consultation de leur liste. Aucun résultat n'est garanti.

SOS Disque est un service indépendant, non affilié aux fabricants de supports ni aux éditeurs de logiciels cités sur cette page.

Questions fréquentes

Parlons de votre cas

Décrivez-nous votre panne en quelques lignes : support, système de fichiers, dernier état connu et fichiers prioritaires (code, dump SQL, image VM). Nous vous répondons avec un bilan et la marche à suivre avant tout envoi. Décrivez la panne en ligne ou appelez le 07 69 27 29 87.