L'utilisation de ce site, notamment notre base de connaissances, est soumise à l'acceptation de nos « conditions générales d'utilisation ». BSC DataRecovery ne pourra être tenu responsable de l'usage qui est fait des informations publiées.
La copie semblait terminée, vous avez tiré la clé. Ou le câble a bougé, ou le portable s'est mis en veille. Au branchement suivant, Windows annonce « Vous devez formater le disque avant de l'utiliser », ou la clé s'ouvre sur une poignée de fichiers aux noms illisibles, ou elle n'est tout simplement plus reconnue. Et tout ce qui était dessus semble avoir disparu d'un coup.
Ce que nous constatons à l'atelier, sur ce type de dossier, est presque toujours le même : la quasi-totalité des fichiers est encore écrite sur la clé. Ce qui a été abîmé au moment du retrait, c'est une zone de quelques kilooctets au début du support, qui sert de sommaire à tout le reste. Cet article explique pourquoi c'est précisément cette zone qui saute, ce qui se récupère avec ses noms et ses dossiers, ce qui revient moins bien, et les trois gestes qui transforment un cas très favorable en perte définitive. C'est le pendant, côté clé USB, de notre article sur la carte SD retirée pendant l'écriture.
1. Retirer une clé pendant une écriture n'efface pas vos fichiers. Il interrompt la mise à jour du sommaire de la clé, qui se trouve tout au début du support. Les fichiers eux-mêmes sont ailleurs, et ils n'ont pas bougé.
2. Ce sommaire est réécrit à chaque copie, à chaque suppression, à chaque enregistrement. C'est pour cela que le retrait tombe presque toujours dessus, et rarement sur vos données.
3. Photos, documents, sous-dossiers reviennent en général intacts, avec leurs noms. Ce qui revient moins bien : les gros fichiers découpés en morceaux, et les noms des dossiers du premier niveau.
4. Ne formatez pas, ne laissez pas Windows « réparer », ne réutilisez pas la clé. Chaque branchement sur un PC écrit un peu dessus, dans la zone déjà abîmée.
5. Récupération logique sur clé USB : 90 € TTC, diagnostic gratuit, pas de données, pas de frais.
Quand vous glissez un dossier sur une clé USB, la barre de progression de Windows suit ce que l'ordinateur a envoyé, pas ce que la clé a fini d'écrire. Entre les deux, il y a trois étages de mémoire tampon :
l'ordinateur garde une partie des écritures en attente, pour les regrouper (c'est moins vrai sur Windows 10 et 11, qui privilégient par défaut le « retrait rapide » pour les clés, mais les applications ont leurs propres tampons) ;
la clé elle-même a son petit processeur, le contrôleur, et sa propre mémoire de travail ; elle continue à écrire quelques instants après la dernière donnée reçue, le temps de ranger ce qu'elle a en attente et de mettre ses propres tables à jour ;
le sommaire du support n'est mis à jour qu'après les données : le système écrit d'abord le contenu du fichier, puis la table qui dit où sont ses morceaux, puis la fiche du fichier dans son dossier.
La fonction « Éjecter » sert exactement à vider ces trois étages, dans l'ordre, et à refermer proprement le sommaire. Retirer la clé à la main court-circuite cette séquence, et la coupure tombe au hasard dans la dernière étape en cours.
Le voyant de la clé, quand elle en a un, est un meilleur indicateur que la fenêtre de copie : tant qu'il clignote, elle écrit.
Une clé USB est presque toujours formatée en FAT32 (ou en exFAT au-delà de 32 Go). Ce format range tout ce qui décrit le contenu de la clé au début du support, dans cet ordre :
la zone de démarrage, qui dit comment la clé est organisée (taille des blocs, taille des tables) ;
la table d'allocation, en deux exemplaires l'un derrière l'autre, qui indique pour chaque bloc de la clé s'il est libre, et sinon quel est le bloc suivant du même fichier ;
le dossier racine, la liste des fichiers et dossiers du premier niveau, avec pour chacun son nom, sa taille, sa date et son premier bloc.
Vos fichiers et vos sous-dossiers viennent ensuite, répartis sur tout le reste du support.
Or chaque opération sur la clé passe par ces trois zones. Copier une photo : ses données sont écrites quelque part sur la clé, puis la table d'allocation est mise à jour deux fois (une par exemplaire), puis le dossier qui la contient reçoit sa fiche. Supprimer un fichier : sa fiche est marquée effacée et sa chaîne de blocs remise à zéro dans les deux tables. Renommer, déplacer, sauvegarder un document ouvert : encore le dossier et la table. La zone de données de vos fichiers est écrite une fois ; le sommaire l'est des dizaines de fois par minute pendant une copie.
À cela s'ajoute une particularité de la mémoire flash : elle ne réécrit jamais un octet, elle réécrit une page entière, de 4 à 16 kilooctets selon la clé. Pour modifier la fiche d'un seul fichier dans le dossier racine, le contrôleur relit la page complète, la modifie en mémoire et la réécrit en entier. Si la clé perd son alimentation pendant cette réécriture, la page peut se retrouver avec un contenu quelconque : ce qu'il y avait dans le tampon à cet instant, des zéros, ou un mélange. Sur un cas récent à l'atelier, un support externe formaté en FAT32 de 1 To (un disque, mais la mécanique est exactement celle d'une clé), les 4 premiers kilooctets du dossier racine contenaient du code de programme, copié là depuis la mémoire de l'ordinateur au moment de la coupure. Les 28 kilooctets suivants du même dossier étaient intacts, les deux tables d'allocation identiques, les sous-dossiers et les données à leur place.
C'est ce qui rend ce type de panne à la fois spectaculaire et favorable : quelques kilooctets abîmés à un endroit stratégique, et tout le reste en bon état.
Selon la zone exacte touchée, le symptôme change. Il n'annonce pas la même chose, et surtout il ne dit rien de l'état de vos fichiers.
Le deuxième cas mérite qu'on s'y arrête, parce qu'il trompe tout le monde, les logiciels de récupération compris. Windows lit le dossier racine depuis le début. Il prend les octets abîmés pour de vraies fiches de fichiers, d'où les noms en caractères aléatoires, les dates impossibles et les tailles rondes. Puis il tombe sur un octet qui, dans ce format, signifie « fin de la liste », et il s'arrête là. Les fiches intactes, quelques kilooctets plus loin dans le même dossier, ne sont jamais lues. Sur le cas cité plus haut, l'Explorateur affichait une quinzaine d'entrées absurdes, et les outils de laboratoire retrouvaient l'arborescence complète en parcourant le dossier jusqu'au bout, en écartant les fiches invalides une par une. Nous avons consacré un article à ce symptôme précis : noms de fichiers en caractères bizarres, dossiers devenus fichiers, dates en 1980.
Le dernier cas, la clé plus reconnue du tout, est le plus rare après un simple retrait. Une clé USB est faite pour être branchée et débranchée sous tension, et un retrait isolé abîme le sommaire bien plus souvent que le contrôleur. Il devient probable sur une clé déjà fatiguée, bas de gamme ou contrefaite, dont le contrôleur réécrivait ses propres tables au moment de la coupure. Le traitement n'est plus logique mais matériel, et il est décrit dans clé USB détectée mais vide, 0 octet ou « insérez un disque » et clé USB non reconnue. Si la clé chauffe ou si son connecteur a bougé au retrait, ce n'est plus le même sujet : voir clé USB qui chauffe très fort.
Voici ce que donne, dossier après dossier, la récupération d'une clé dont le début du volume a été abîmé par un retrait pendant l'écriture. Ce n'est pas une promesse générale, c'est ce que nous observons quand rien n'a été écrit sur la clé après l'incident.
Les sous-dossiers et tout leur contenu : intacts, avec leurs noms. Un sous-dossier est lui-même un petit fichier rangé dans la zone de données, loin du début de la clé. Sa liste de fichiers, avec les noms d'origine, les dates et les tailles, n'a pas été touchée. Le dossier « Photos vacances 2024 » revient donc avec toutes ses photos et tous ses noms.
Les photos et les documents : intacts. Une photo, un PDF, un document de bureautique sont des fichiers de quelques centaines de kilooctets à quelques mégaoctets, en général écrits d'un seul tenant. Même quand leur chaîne dans la table d'allocation est abîmée, leur premier bloc et leur taille, notés dans leur fiche, suffisent à les relire en entier.
Les noms des dossiers du premier niveau : parfois perdus. Ce sont eux qui vivaient dans la zone détruite du dossier racine. Le dossier existe toujours, son contenu est complet, mais sa fiche, celle qui portait son nom, a disparu. Au laboratoire, ces dossiers orphelins sont retrouvés par balayage, et livrés sous un nom neutre. Ils se renomment en quelques minutes à partir de ce qu'ils contiennent : un dossier plein de fichiers « Facture 2023-… » ne pose pas de problème d'identification. Sur le cas cité, cette recherche a fait passer la part du support non atteinte de 23 Go à moins d'un demi-gigaoctet, sans que rien ne manque à l'arrivée.
Les fichiers posés directement à la racine : contenu intact, nom parfois perdu. Même logique : le fichier est là, sa fiche ne l'est plus. Il revient sous un nom générique, avec son extension reconnue à son contenu, et une date à zéro. À vous de lui redonner son nom.
Les gros fichiers écrits en plusieurs morceaux : c'est ici que ça se complique. Une vidéo, une archive, une image disque, un gros fichier de sauvegarde, sur une clé qui a vécu, sont découpés en fragments dispersés. Leur ordre n'est connu que de la table d'allocation. Si le retrait a interrompu la mise à jour de cette table pour ce fichier, sa chaîne s'arrête avant la fin : le fichier revient tronqué, plus court que sa taille déclarée. Le début s'ouvre, la fin manque. La suite peut parfois être reconstituée par recherche de signature autour de l'endroit où la chaîne s'arrête, mais sans garantie, et ce n'est pas la règle. C'est pour cela que nous vous demandons de désigner vos fichiers prioritaires dès le dépôt.
Le fichier qui était en cours de copie : incomplet, par nature. Les données qui n'avaient pas encore quitté l'ordinateur n'existent nulle part sur la clé. Cette partie-là ne se récupère pas, par personne. En revanche, l'original est toujours sur l'ordinateur d'où vous copiiez, sauf si vous aviez fait un « couper-coller » : dans ce cas, le fichier source a été supprimé après la copie, et il se retrouve le plus souvent dans la corbeille ou par récupération sur le disque de l'ordinateur.
Enfin, une pièce peu connue joue en votre faveur : les deux exemplaires de la table d'allocation. Ils sont écrits l'un après l'autre. Un retrait qui tombe entre les deux laisse un exemplaire à jour et l'autre en retard, et la différence entre les deux dit exactement quel fichier était en cours d'écriture. C'est une des premières choses que nous comparons.
Dans cet ordre de fréquence à l'atelier.
1. Accepter le formatage ou la réparation proposés par Windows. Le formatage rapide réécrit la zone de démarrage, remet les deux tables à zéro et vide le dossier racine : il détruit ce qui restait de sommaire, et transforme une récupération avec noms et dossiers en reconstruction par signature (nous détaillons ce que fait vraiment un formatage dans formatage rapide ou fichier supprimé sur une clé USB). La « réparation » (chkdsk) est pire pour ce cas précis : elle prend les fiches absurdes du début du dossier racine pour de vrais fichiers, tente de les rendre cohérentes, coupe les chaînes qu'elle juge invalides, et range les morceaux dans un dossier FOUND.000 sous des noms FILE0001.CHK. Ce qu'elle fait est expliqué dans chkdsk peut détruire vos données et dossier FOUND.000 et fichiers .CHK.
2. Continuer à brancher la clé, ou la réutiliser. Ce point est contre-intuitif : vous n'écrivez rien, vous « regardez juste ». Mais Windows, lui, écrit. À chaque montage d'une clé dont il ne retrouve plus le dossier système caché, il en crée un nouveau, et il le place au premier emplacement libre du dossier racine, c'est-à-dire dans la zone abîmée, par-dessus ce qui pourrait encore y être lu. Sur le cas cité, nous avons pu dater le dégât grâce à ces dossiers système successifs : un créé avant l'incident, dans la partie intacte, un autre après, dans la partie détruite. Chaque branchement en ajoute une couche. Et copier ne serait-ce qu'un fichier sur la clé « pour tester » va l'écrire au premier bloc libre, qui peut être un bloc de vos anciens dossiers devenus orphelins. Une clé dans cet état se branche une seule fois, pour en prendre une image en lecture seule.
3. Supprimer les fichiers bizarres, ou lancer l'outil du fabricant. Supprimer les entrées aux noms illisibles paraît anodin : ce sont de fausses fiches. Mais elles pointent, par hasard, vers de vrais blocs de la clé, et leur suppression remet ces blocs « libres » dans les deux tables. L'outil de « réparation » ou de « restauration » du fabricant, lui, remet la clé en état d'usine : c'est l'opération la plus définitive qui soit, elle ne se rattrape plus.
À proscrire aussi : enchaîner plusieurs logiciels gratuits de récupération sur la clé. Le premier scan ne l'abîme pas s'il est en lecture seule, mais beaucoup proposent de « réparer » ou d'écrire les fichiers récupérés sur le même support.
La procédure est courte pour un cas purement logique, et c'est ce qui explique le tarif.
1. Une seule lecture, intégrale, en mode bloqué en écriture. La clé est branchée sur un matériel qui ne peut physiquement rien y écrire, et copiée bloc par bloc dans une image. Tout le reste se fait sur cette image ; la clé n'est plus sollicitée.
2. Comparaison des deux tables d'allocation et lecture de la copie de secours de la zone de démarrage (le format FAT32 en garde une). Les deux tables identiques et la copie du démarrage saine sont le scénario le plus fréquent : le dégât est alors localisé dans le dossier racine.
3. Parcours complet du dossier racine, sans s'arrêter au premier marqueur de fin, puis recherche des dossiers orphelins dans la zone de données, et mesure : le nombre de blocs alloués dans la table, contre le nombre de blocs atteints par l'arborescence reconstruite. Quand les deux chiffres se rejoignent, rien ne manque.
4. Liste complète des fichiers récupérés, envoyée avant paiement. Vous vérifiez que vos fichiers prioritaires y sont, et ceux qui reviennent tronqués sont signalés comme tels. Si l'essentiel manque, vous refusez sans frais de récupération.
5. Restitution sur un support neuf, fourni sur devis ou apporté par vous (vierge). Jamais sur la clé d'origine.
Pour une clé USB, cette récupération logique est facturée 90 € TTC, et le diagnostic est gratuit. Si le contrôleur a décroché (clé non reconnue, 0 octet), on passe à une lecture directe de la mémoire : 390 € TTC pour une clé classique, 690 € TTC pour une clé monolithique, dont la puce et le contrôleur sont fondus dans un même bloc de résine (pour savoir ce que vous avez en main : clé USB monolithique ou classique). Le détail par situation est sur prix de la récupération d'une carte SD, microSD ou clé USB, et la règle « pas de données, pas de frais » s'applique sans exception sur ce type de support. Les frais d'envoi restent à votre charge, et le support de restitution s'ajoute au devis.
Un retrait à chaud n'use pas une clé, et on pourrait être tenté de la reformater et de continuer. Deux raisons de ne pas le faire. La première : si c'est le contrôleur qui a décroché, il recommencera, et la deuxième fois ce sera avec vos fichiers récupérés. La seconde, plus prosaïque : une clé USB à 10 € n'est pas un support de stockage, c'est un support de transport. Ce qui n'existe qu'à un seul exemplaire, sur une clé, est déjà en danger avant tout incident.
Et pour la prochaine fois : cliquez sur « Éjecter », attendez le message « Le matériel peut être retiré en toute sécurité », et si la clé a un voyant, attendez qu'il s'éteigne. C'est la seule manipulation de cet article qui ne coûte rien.
Pour votre clé USB : estimation gratuite en ligne, diagnostic guidé en 5 questions, ou appelez le laboratoire au 09 71 32 65 95.
Le détail de notre service et des tarifs : récupération de données sur clé USB.
La copie semblait terminée, vous avez tiré la clé. Ou le câble a bougé, ou le portable s'est mis en veille. Au branchement suivant, Windows annonce « Vous devez formater le disque avant de l'utiliser », ou la clé s'ouvre sur une poignée de fichiers aux noms illisibles, ou elle n'est tout simplement plus reconnue. Et tout ce qui était dessus semble avoir disparu d'un coup.
Ce que nous constatons à l'atelier, sur ce type de dossier, est presque toujours le même : la quasi-totalité des fichiers est encore écrite sur la clé. Ce qui a été abîmé au moment du retrait, c'est une zone de quelques kilooctets au début du support, qui sert de sommaire à tout le reste. Cet article explique pourquoi c'est précisément cette zone qui saute, ce qui se récupère avec ses noms et ses dossiers, ce qui revient moins bien, et les trois gestes qui transforment un cas très favorable en perte définitive. C'est le pendant, côté clé USB, de notre article sur la carte SD retirée pendant l'écriture.
🔴 Clé USB retirée pendant une copie, plus reconnue ou demandant un formatage ? BSC DataRecovery - 09 71 32 65 95.
Diagnostic gratuit et sans engagement.
Estimation pour ma clé USB →
Diagnostic gratuit et sans engagement.
Estimation pour ma clé USB →
L'essentiel en 30 secondes
1. Retirer une clé pendant une écriture n'efface pas vos fichiers. Il interrompt la mise à jour du sommaire de la clé, qui se trouve tout au début du support. Les fichiers eux-mêmes sont ailleurs, et ils n'ont pas bougé.
2. Ce sommaire est réécrit à chaque copie, à chaque suppression, à chaque enregistrement. C'est pour cela que le retrait tombe presque toujours dessus, et rarement sur vos données.
3. Photos, documents, sous-dossiers reviennent en général intacts, avec leurs noms. Ce qui revient moins bien : les gros fichiers découpés en morceaux, et les noms des dossiers du premier niveau.
4. Ne formatez pas, ne laissez pas Windows « réparer », ne réutilisez pas la clé. Chaque branchement sur un PC écrit un peu dessus, dans la zone déjà abîmée.
5. Récupération logique sur clé USB : 90 € TTC, diagnostic gratuit, pas de données, pas de frais.
Pourquoi « la copie est finie » ne veut pas dire « la clé a fini d'écrire »
Quand vous glissez un dossier sur une clé USB, la barre de progression de Windows suit ce que l'ordinateur a envoyé, pas ce que la clé a fini d'écrire. Entre les deux, il y a trois étages de mémoire tampon :
l'ordinateur garde une partie des écritures en attente, pour les regrouper (c'est moins vrai sur Windows 10 et 11, qui privilégient par défaut le « retrait rapide » pour les clés, mais les applications ont leurs propres tampons) ; la clé elle-même a son petit processeur, le contrôleur, et sa propre mémoire de travail ; elle continue à écrire quelques instants après la dernière donnée reçue, le temps de ranger ce qu'elle a en attente et de mettre ses propres tables à jour ; le sommaire du support n'est mis à jour qu'après les données : le système écrit d'abord le contenu du fichier, puis la table qui dit où sont ses morceaux, puis la fiche du fichier dans son dossier.La fonction « Éjecter » sert exactement à vider ces trois étages, dans l'ordre, et à refermer proprement le sommaire. Retirer la clé à la main court-circuite cette séquence, et la coupure tombe au hasard dans la dernière étape en cours.
Le voyant de la clé, quand elle en a un, est un meilleur indicateur que la fenêtre de copie : tant qu'il clignote, elle écrit.
Pourquoi c'est le début de la clé qui saute
Une clé USB est presque toujours formatée en FAT32 (ou en exFAT au-delà de 32 Go). Ce format range tout ce qui décrit le contenu de la clé au début du support, dans cet ordre :
la zone de démarrage, qui dit comment la clé est organisée (taille des blocs, taille des tables) ; la table d'allocation, en deux exemplaires l'un derrière l'autre, qui indique pour chaque bloc de la clé s'il est libre, et sinon quel est le bloc suivant du même fichier ; le dossier racine, la liste des fichiers et dossiers du premier niveau, avec pour chacun son nom, sa taille, sa date et son premier bloc.Vos fichiers et vos sous-dossiers viennent ensuite, répartis sur tout le reste du support.
Or chaque opération sur la clé passe par ces trois zones. Copier une photo : ses données sont écrites quelque part sur la clé, puis la table d'allocation est mise à jour deux fois (une par exemplaire), puis le dossier qui la contient reçoit sa fiche. Supprimer un fichier : sa fiche est marquée effacée et sa chaîne de blocs remise à zéro dans les deux tables. Renommer, déplacer, sauvegarder un document ouvert : encore le dossier et la table. La zone de données de vos fichiers est écrite une fois ; le sommaire l'est des dizaines de fois par minute pendant une copie.
À cela s'ajoute une particularité de la mémoire flash : elle ne réécrit jamais un octet, elle réécrit une page entière, de 4 à 16 kilooctets selon la clé. Pour modifier la fiche d'un seul fichier dans le dossier racine, le contrôleur relit la page complète, la modifie en mémoire et la réécrit en entier. Si la clé perd son alimentation pendant cette réécriture, la page peut se retrouver avec un contenu quelconque : ce qu'il y avait dans le tampon à cet instant, des zéros, ou un mélange. Sur un cas récent à l'atelier, un support externe formaté en FAT32 de 1 To (un disque, mais la mécanique est exactement celle d'une clé), les 4 premiers kilooctets du dossier racine contenaient du code de programme, copié là depuis la mémoire de l'ordinateur au moment de la coupure. Les 28 kilooctets suivants du même dossier étaient intacts, les deux tables d'allocation identiques, les sous-dossiers et les données à leur place.
C'est ce qui rend ce type de panne à la fois spectaculaire et favorable : quelques kilooctets abîmés à un endroit stratégique, et tout le reste en bon état.
Ce que vous voyez au branchement suivant, et ce que ça veut dire
Selon la zone exacte touchée, le symptôme change. Il n'annonce pas la même chose, et surtout il ne dit rien de l'état de vos fichiers.
| Ce que Windows affiche | Ce qui a été abîmé | Vos fichiers |
|---|---|---|
| « Vous devez formater le disque », clé en RAW, ou « Le paramètre est incorrect » | la zone de démarrage, ou le début de la première table | intacts |
| La clé s'ouvre, mais montre quelques fichiers aux noms illisibles, datés de 2045 ou de 1980, de 4 Go, et plus rien d'autre | le début du dossier racine | intacts, mais Windows ne les atteint plus |
| La clé s'ouvre normalement, un dossier est vide ou un fichier ne s'ouvre plus | un sous-dossier, ou la chaîne d'un fichier dans la table | tout le reste intact |
| « Analyser et réparer ce lecteur ? » | rien de plus qu'un drapeau « pas refermé proprement » laissé levé | intacts, à condition de répondre non |
| Clé non reconnue, 0 octet, ou capacité absurde (2 Go, 32 Mo) | les tables internes du contrôleur, pas le sommaire | intacts dans la mémoire, mais inaccessibles par logiciel |
Le deuxième cas mérite qu'on s'y arrête, parce qu'il trompe tout le monde, les logiciels de récupération compris. Windows lit le dossier racine depuis le début. Il prend les octets abîmés pour de vraies fiches de fichiers, d'où les noms en caractères aléatoires, les dates impossibles et les tailles rondes. Puis il tombe sur un octet qui, dans ce format, signifie « fin de la liste », et il s'arrête là. Les fiches intactes, quelques kilooctets plus loin dans le même dossier, ne sont jamais lues. Sur le cas cité plus haut, l'Explorateur affichait une quinzaine d'entrées absurdes, et les outils de laboratoire retrouvaient l'arborescence complète en parcourant le dossier jusqu'au bout, en écartant les fiches invalides une par une. Nous avons consacré un article à ce symptôme précis : noms de fichiers en caractères bizarres, dossiers devenus fichiers, dates en 1980.
Le dernier cas, la clé plus reconnue du tout, est le plus rare après un simple retrait. Une clé USB est faite pour être branchée et débranchée sous tension, et un retrait isolé abîme le sommaire bien plus souvent que le contrôleur. Il devient probable sur une clé déjà fatiguée, bas de gamme ou contrefaite, dont le contrôleur réécrivait ses propres tables au moment de la coupure. Le traitement n'est plus logique mais matériel, et il est décrit dans clé USB détectée mais vide, 0 octet ou « insérez un disque » et clé USB non reconnue. Si la clé chauffe ou si son connecteur a bougé au retrait, ce n'est plus le même sujet : voir clé USB qui chauffe très fort.
Ce qui se récupère, et dans quel état
Voici ce que donne, dossier après dossier, la récupération d'une clé dont le début du volume a été abîmé par un retrait pendant l'écriture. Ce n'est pas une promesse générale, c'est ce que nous observons quand rien n'a été écrit sur la clé après l'incident.
Les sous-dossiers et tout leur contenu : intacts, avec leurs noms. Un sous-dossier est lui-même un petit fichier rangé dans la zone de données, loin du début de la clé. Sa liste de fichiers, avec les noms d'origine, les dates et les tailles, n'a pas été touchée. Le dossier « Photos vacances 2024 » revient donc avec toutes ses photos et tous ses noms. Les photos et les documents : intacts. Une photo, un PDF, un document de bureautique sont des fichiers de quelques centaines de kilooctets à quelques mégaoctets, en général écrits d'un seul tenant. Même quand leur chaîne dans la table d'allocation est abîmée, leur premier bloc et leur taille, notés dans leur fiche, suffisent à les relire en entier. Les noms des dossiers du premier niveau : parfois perdus. Ce sont eux qui vivaient dans la zone détruite du dossier racine. Le dossier existe toujours, son contenu est complet, mais sa fiche, celle qui portait son nom, a disparu. Au laboratoire, ces dossiers orphelins sont retrouvés par balayage, et livrés sous un nom neutre. Ils se renomment en quelques minutes à partir de ce qu'ils contiennent : un dossier plein de fichiers « Facture 2023-… » ne pose pas de problème d'identification. Sur le cas cité, cette recherche a fait passer la part du support non atteinte de 23 Go à moins d'un demi-gigaoctet, sans que rien ne manque à l'arrivée. Les fichiers posés directement à la racine : contenu intact, nom parfois perdu. Même logique : le fichier est là, sa fiche ne l'est plus. Il revient sous un nom générique, avec son extension reconnue à son contenu, et une date à zéro. À vous de lui redonner son nom. Les gros fichiers écrits en plusieurs morceaux : c'est ici que ça se complique. Une vidéo, une archive, une image disque, un gros fichier de sauvegarde, sur une clé qui a vécu, sont découpés en fragments dispersés. Leur ordre n'est connu que de la table d'allocation. Si le retrait a interrompu la mise à jour de cette table pour ce fichier, sa chaîne s'arrête avant la fin : le fichier revient tronqué, plus court que sa taille déclarée. Le début s'ouvre, la fin manque. La suite peut parfois être reconstituée par recherche de signature autour de l'endroit où la chaîne s'arrête, mais sans garantie, et ce n'est pas la règle. C'est pour cela que nous vous demandons de désigner vos fichiers prioritaires dès le dépôt. Le fichier qui était en cours de copie : incomplet, par nature. Les données qui n'avaient pas encore quitté l'ordinateur n'existent nulle part sur la clé. Cette partie-là ne se récupère pas, par personne. En revanche, l'original est toujours sur l'ordinateur d'où vous copiiez, sauf si vous aviez fait un « couper-coller » : dans ce cas, le fichier source a été supprimé après la copie, et il se retrouve le plus souvent dans la corbeille ou par récupération sur le disque de l'ordinateur.Enfin, une pièce peu connue joue en votre faveur : les deux exemplaires de la table d'allocation. Ils sont écrits l'un après l'autre. Un retrait qui tombe entre les deux laisse un exemplaire à jour et l'autre en retard, et la différence entre les deux dit exactement quel fichier était en cours d'écriture. C'est une des premières choses que nous comparons.
Les trois gestes qui aggravent le cas
Dans cet ordre de fréquence à l'atelier.
1. Accepter le formatage ou la réparation proposés par Windows. Le formatage rapide réécrit la zone de démarrage, remet les deux tables à zéro et vide le dossier racine : il détruit ce qui restait de sommaire, et transforme une récupération avec noms et dossiers en reconstruction par signature (nous détaillons ce que fait vraiment un formatage dans formatage rapide ou fichier supprimé sur une clé USB). La « réparation » (chkdsk) est pire pour ce cas précis : elle prend les fiches absurdes du début du dossier racine pour de vrais fichiers, tente de les rendre cohérentes, coupe les chaînes qu'elle juge invalides, et range les morceaux dans un dossier FOUND.000 sous des noms FILE0001.CHK. Ce qu'elle fait est expliqué dans chkdsk peut détruire vos données et dossier FOUND.000 et fichiers .CHK.
2. Continuer à brancher la clé, ou la réutiliser. Ce point est contre-intuitif : vous n'écrivez rien, vous « regardez juste ». Mais Windows, lui, écrit. À chaque montage d'une clé dont il ne retrouve plus le dossier système caché, il en crée un nouveau, et il le place au premier emplacement libre du dossier racine, c'est-à-dire dans la zone abîmée, par-dessus ce qui pourrait encore y être lu. Sur le cas cité, nous avons pu dater le dégât grâce à ces dossiers système successifs : un créé avant l'incident, dans la partie intacte, un autre après, dans la partie détruite. Chaque branchement en ajoute une couche. Et copier ne serait-ce qu'un fichier sur la clé « pour tester » va l'écrire au premier bloc libre, qui peut être un bloc de vos anciens dossiers devenus orphelins. Une clé dans cet état se branche une seule fois, pour en prendre une image en lecture seule.
3. Supprimer les fichiers bizarres, ou lancer l'outil du fabricant. Supprimer les entrées aux noms illisibles paraît anodin : ce sont de fausses fiches. Mais elles pointent, par hasard, vers de vrais blocs de la clé, et leur suppression remet ces blocs « libres » dans les deux tables. L'outil de « réparation » ou de « restauration » du fabricant, lui, remet la clé en état d'usine : c'est l'opération la plus définitive qui soit, elle ne se rattrape plus.
À proscrire aussi : enchaîner plusieurs logiciels gratuits de récupération sur la clé. Le premier scan ne l'abîme pas s'il est en lecture seule, mais beaucoup proposent de « réparer » ou d'écrire les fichiers récupérés sur le même support.
Ce que nous faisons au laboratoire
La procédure est courte pour un cas purement logique, et c'est ce qui explique le tarif.
1. Une seule lecture, intégrale, en mode bloqué en écriture. La clé est branchée sur un matériel qui ne peut physiquement rien y écrire, et copiée bloc par bloc dans une image. Tout le reste se fait sur cette image ; la clé n'est plus sollicitée.
2. Comparaison des deux tables d'allocation et lecture de la copie de secours de la zone de démarrage (le format FAT32 en garde une). Les deux tables identiques et la copie du démarrage saine sont le scénario le plus fréquent : le dégât est alors localisé dans le dossier racine.
3. Parcours complet du dossier racine, sans s'arrêter au premier marqueur de fin, puis recherche des dossiers orphelins dans la zone de données, et mesure : le nombre de blocs alloués dans la table, contre le nombre de blocs atteints par l'arborescence reconstruite. Quand les deux chiffres se rejoignent, rien ne manque.
4. Liste complète des fichiers récupérés, envoyée avant paiement. Vous vérifiez que vos fichiers prioritaires y sont, et ceux qui reviennent tronqués sont signalés comme tels. Si l'essentiel manque, vous refusez sans frais de récupération.
5. Restitution sur un support neuf, fourni sur devis ou apporté par vous (vierge). Jamais sur la clé d'origine.
Pour une clé USB, cette récupération logique est facturée 90 € TTC, et le diagnostic est gratuit. Si le contrôleur a décroché (clé non reconnue, 0 octet), on passe à une lecture directe de la mémoire : 390 € TTC pour une clé classique, 690 € TTC pour une clé monolithique, dont la puce et le contrôleur sont fondus dans un même bloc de résine (pour savoir ce que vous avez en main : clé USB monolithique ou classique). Le détail par situation est sur prix de la récupération d'une carte SD, microSD ou clé USB, et la règle « pas de données, pas de frais » s'applique sans exception sur ce type de support. Les frais d'envoi restent à votre charge, et le support de restitution s'ajoute au devis.
Après la récupération : ne remettez pas cette clé en service
Un retrait à chaud n'use pas une clé, et on pourrait être tenté de la reformater et de continuer. Deux raisons de ne pas le faire. La première : si c'est le contrôleur qui a décroché, il recommencera, et la deuxième fois ce sera avec vos fichiers récupérés. La seconde, plus prosaïque : une clé USB à 10 € n'est pas un support de stockage, c'est un support de transport. Ce qui n'existe qu'à un seul exemplaire, sur une clé, est déjà en danger avant tout incident.
Et pour la prochaine fois : cliquez sur « Éjecter », attendez le message « Le matériel peut être retiré en toute sécurité », et si la clé a un voyant, attendez qu'il s'éteigne. C'est la seule manipulation de cet article qui ne coûte rien.
Pour votre clé USB : estimation gratuite en ligne, diagnostic guidé en 5 questions, ou appelez le laboratoire au 09 71 32 65 95.
Le détail de notre service et des tarifs : récupération de données sur clé USB.
Dans le groupe BSC, selon votre situation.
🛠️ Remplacer la clé et choisir un support adapté à ce que vous stockez : l'atelier BSC Informatique fournit et conseille sur place.
🏠 Mettre en place chez vous une copie automatique de vos documents et de vos photos, pour que la prochaine clé perdue ne soit qu'une clé perdue : BSC Assistance intervient à domicile chez les particuliers, avec l'agrément service à la personne.
Sources : Microsoft, spécification du système de fichiers FAT32 (organisation du volume, table d'allocation en deux exemplaires, entrées de répertoire du dossier racine, marquage des entrées effacées) ; documentation Microsoft sur l'éjection sécurisée et la politique de retrait des périphériques amovibles ; fonctionnement des mémoires flash NAND (écriture par page, effacement par bloc) ; cas traités et documentés à l'atelier BSC DataRecovery.🛠️ Remplacer la clé et choisir un support adapté à ce que vous stockez : l'atelier BSC Informatique fournit et conseille sur place.
🏠 Mettre en place chez vous une copie automatique de vos documents et de vos photos, pour que la prochaine clé perdue ne soit qu'une clé perdue : BSC Assistance intervient à domicile chez les particuliers, avec l'agrément service à la personne.