La scène est presque toujours la même à l'atelier. Un client veut sauvegarder son PC avant une réinstallation, ou simplement mettre ses données à l'abri sur le NAS qu'il vient d'acheter. Il ouvre l'Explorateur, sélectionne C:\Users\Prénom, fait un glisser-déposer vers \\NAS\Sauvegardes, et laisse tourner. Deux heures plus tard, Windows affiche une fenêtre : « Le nom du fichier serait trop long pour le dossier de destination », avec trois boutons — Réessayer, Ignorer, Annuler. Il clique sur Ignorer, parfois même sur « Faire ceci pour tous les éléments en conflit », la copie se termine, et tout le monde est content.

Sauf que la sauvegarde est trouée. Pas de quelques fichiers : sur un cas mesuré à l'atelier — un dossier de 364 Go et 198 183 fichiers — l'Explorateur avait silencieusement laissé de côté 1 556 fichiers et 81 dossiers, soit environ 1,54 Go. Rien dans l'interface ne le dit une fois la fenêtre fermée. Aucun rapport, aucun récapitulatif. Le dossier de destination a l'air complet.

Le réflexe, à ce stade, est d'aller chercher sur le web « chemin trop long Windows 11 ». On tombe en trois clics sur le fameux réglage LongPathsEnabled, présenté partout comme la solution. On l'active, on redémarre, on relance la copie… et exactement les mêmes fichiers sont encore ignorés. C'est le moment où l'on se dit que Windows est cassé.

Windows n'est pas cassé. Ce réglage ne pouvait tout simplement pas fonctionner ici, pour une raison précise que nous allons voir. Et surtout, dans une copie de profil utilisateur vers un NAS, la longueur des noms de fichiers n'est même pas le vrai coupable : elle est le symptôme de quatre autres problèmes, tous invisibles depuis l'Explorateur.

Cet article explique ce qui se passe réellement, pourquoi LongPathsEnabled ne suffira jamais, quels sont les quatre pièges spécifiques au couple profil utilisateur → partage réseau, et donne la commande complète que nous utilisons en atelier, avec le contrôle de vérification qui prouve que la copie est intègre.

À retenir en trente secondes

Ce que vous constatez	Ce qui se passe réellement
« Windows dit que des noms sont trop longs et propose Ignorer »	La limite historique MAX_PATH (260 caractères). Si vous cliquez Ignorer, la copie se termine « normalement » mais elle est incomplète, sans aucun rapport.
« J'ai activé LongPathsEnabled et rien n'a changé »	Ce réglage n'agit que sur les applications déclarées compatibles. L'Explorateur ne l'est pas, même sous Windows 11.
« Ce sont des noms de fichiers monstrueux dans mon profil »	Presque jamais. Ce sont les jonctions de compatibilité de C:\Users qui bouclent sur elles-mêmes et fabriquent des chemins de 500 caractères.
« J'ai des milliers d'erreurs de sécurité / d'autorisations »	Vous copiez les ACL NTFS vers un partage SMB, qui ne sait pas les stocker. Il ne faut pas les copier.
« La copie a téléchargé 400 Go de OneDrive que je n'avais pas sur le disque »	Les fichiers à la demande ont été hydratés par la copie. Il faut les exclure.
« Le NAS refuse carrément la connexion »	Autre sujet : durcissement SMB de Windows 11 24H2/25H2. Voir le chapitre 10.

La commande, en une ligne (invite de commandes en administrateur, Z: étant le lecteur réseau du NAS) :

Chaque option a une raison d'être précise, et retirer la mauvaise suffit à retrouver le problème d'origine. Le détail est au chapitre 7, le contrôle final au chapitre 8.

1. Ce que fait vraiment l'Explorateur quand il « ignore » un fichier

Depuis les origines de Windows, l'interface de programmation Win32 impose une limite de 260 caractères pour un chemin complet — lettre de lecteur comprise, et en réalité 256 utilisables. Cette limite s'appelle MAX_PATH. Elle n'a rien à voir avec le système de fichiers : NTFS, lui, sait parfaitement stocker des chemins de plus de 32 000 caractères. C'est la couche d'application qui bloque.

Quand l'Explorateur rencontre un fichier dont le chemin de destination dépasserait cette limite, il ne sait pas quoi faire. Il vous propose Réessayer, Ignorer, Annuler. Et voici le point important : la copie qui se « termine » après un Ignorer est considérée par Windows comme réussie. Aucun journal n'est écrit, aucune liste des éléments abandonnés n'est conservée, aucune alerte ne subsiste. Si vous formatez ensuite le disque source — ce qui est exactement le scénario d'une réinstallation — les fichiers ignorés sont définitivement perdus, et vous ne saurez même pas lesquels.

C'est ce qui rend ce problème sournois : ce n'est pas une panne bruyante, c'est une perte silencieuse. Le client découvre le trou trois mois plus tard, quand il cherche un dossier précis.

Le cas mesuré cité en introduction est instructif sur un autre point : les 1 556 fichiers manquants n'étaient pas répartis au hasard. Ils étaient concentrés dans quelques arborescences très profondes — un dossier OneDrive professionnel avec des segments de chemin répétés, typiquement Documents\Projets 2024\Client X\Pièces jointes\Mails\.... Un seul dossier mal nommé haut dans l'arbre suffit à faire passer des centaines de fichiers au-delà de la limite.

2. LongPathsEnabled : le réglage que tout le monde conseille, et pourquoi il ne réglera pas votre copie

Depuis Windows 10 (version 1607), Microsoft permet de lever la limite MAX_PATH via un réglage système, souvent présenté comme la solution universelle :

L'équivalent en stratégie de groupe se trouve dans gpedit.msc → Configuration ordinateur → Modèles d'administration → Système → Système de fichiers → « Activer les chemins d'accès longs Win32 ». Dans les deux cas, un redémarrage est nécessaire.

Ce réglage fonctionne. Simplement, il ne fait pas ce que l'on croit. Il n'agit que sur les applications qui se déclarent elles-mêmes compatibles, via une mention longPathAware dans leur manifeste. Une application qui ne l'a pas déclaré continue de se heurter au mur des 260 caractères, que le réglage soit activé ou non.

Outil	Tire parti de LongPathsEnabled ?
Explorateur Windows	Non — y compris sous Windows 11 à jour. C'est la raison n°1 de « j'ai fait la manip et ça ne marche pas ».
PowerShell 5.1 (celui livré avec Windows)	Non
PowerShell 7 (installé séparément)	Oui
Invite de commandes (copy, xcopy)	Non
robocopy	Sans objet : il gère les chemins longs nativement, même si le réglage n'est pas activé

Ce tableau contient toute l'histoire. L'outil avec lequel vous faites la copie — l'Explorateur — est précisément celui qui ignore le réglage. Et l'outil qui règle le problème — robocopy, livré d'origine avec Windows — n'a jamais eu besoin de ce réglage : il ajoute en interne le préfixe \\?\ devant les chemins, ce qui court-circuite complètement MAX_PATH.

Faut-il quand même l'activer ? Oui, mais pour l'après, pas pour la copie. Une fois vos fichiers sur le NAS, vous voudrez les parcourir, ouvrir, dézipper, restaurer — et là, l'outil utilisé sera peut-être compatible. Activez-le donc, mais ne comptez jamais dessus pour rendre une copie de profil possible.

3. Piège n°1 : les jonctions de profil, vrai coupable des « chemins trop longs »

C'est le point que presque aucun tutoriel n'explique, et c'est pourtant la cause réelle de la majorité des erreurs lorsqu'on copie un profil utilisateur.

C:\Users\<utilisateur> n'est pas un dossier ordinaire. Il contient des jonctions de compatibilité — des sortes de raccourcis de bas niveau, invisibles par défaut — héritées de l'époque de Windows XP, pour que de vieux logiciels cherchant Documents and Settings ou My Documents trouvent quand même leur chemin. En voici les principales :

• Documents and Settings (à la racine de C:) ;

• AppData\Local\Application Data ;

• AppData\Local\Historique ;

• AppData\Local\Temporary Internet Files ;

• Mes documents / My Documents ;

• Local Settings ;

• Cookies, Menu Démarrer, Modèles, Voisinage réseau.

Le problème est que plusieurs d'entre elles pointent vers un dossier parent d'elles-mêmes. AppData\Local\Application Data pointe sur AppData\Local. Autrement dit : une boucle.

Un outil de copie qui suit aveuglément ces jonctions descend donc dans AppData\Local\Application Data\Application Data\Application Data\… jusqu'à ce que le chemin devienne trop long. Ce n'est pas votre fichier Rapport annuel définitif v3 corrigé.docx qui pose problème : c'est une arborescence fantôme fabriquée pendant la copie elle-même.

La conséquence pratique est décisive : les messages « chemin trop long » d'une copie de profil viennent presque toujours de là. C'est pourquoi activer LongPathsEnabled ne change rien — même sans limite, la boucle est infinie. Et c'est pourquoi l'option /XJ (exclure les jonctions) est obligatoire, et non facultative, dès qu'on copie un dossier utilisateur.

4. Piège n°2 : le budget de longueur se consomme côté destination

La limite des 260 caractères s'applique au chemin final, celui de la destination. Or une arborescence de sauvegarde bien rangée sur un NAS ressemble souvent à ceci :

Ce préfixe consomme à lui seul une soixantaine de caractères avant même d'atteindre le premier fichier. Vous avez donc déjà « brûlé » un quart du budget, et des fichiers qui tenaient parfaitement sur C: deviennent hors limites une fois sur le NAS. C'est la raison pour laquelle une copie peut échouer vers un partage réseau alors qu'elle passait sans problème vers un disque externe.

Le remède est trivial et fait gagner beaucoup : monter une lettre de lecteur au plus près du dossier cible, ce qui remplace tout le préfixe par deux caractères.

\\NAS-BSC\Sauvegardes\Clients\DUPONT\2026-08-14\... devient Z:\2026-08-14\.... Une fois la copie terminée, net use Z: /delete referme la connexion.

Deux précisions utiles :

• Faites-le dans la même session de privilèges que la copie. Un lecteur réseau monté dans une session utilisateur normale n'est pas visible dans une invite de commandes ouverte en administrateur — c'est un classique du « le lecteur Z: n'existe pas » alors qu'il est bien là dans l'Explorateur.

• Si le NAS demande des identifiants : net use Z: \\NAS-BSC\Sauvegardes /user:NOM_UTILISATEUR * vous les demandera de façon masquée.

5. Piège n°3 : les autorisations NTFS ne passent pas sur un partage réseau

Le second conseil que l'on trouve partout est d'utiliser /COPYALL — « pour tout copier, on ne sait jamais ». C'est une très mauvaise idée vers un NAS.

/COPYALL demande de copier, en plus des données, les ACL NTFS : la liste détaillée des autorisations, les propriétaires, les informations d'audit. Ces objets sont propres à NTFS et dépendent d'identifiants de sécurité (SID) valables sur votre machine uniquement.

Or votre NAS n'utilise pas NTFS. Un Synology, un QNAP ou un TrueNAS travaille en ext4, Btrfs ou ZFS, et présente ses dossiers via le protocole SMB, avec son propre modèle de permissions. Il ne sait donc pas stocker ce que vous lui envoyez. Résultat : des milliers d'échecs de copie de sécurité dans le journal, une copie qui rame, et un compte rendu final noyé sous les erreurs — au point de ne plus voir les vraies.

La bonne option est /COPY:DAT : Données, Attributs, Timestamps. C'est exactement ce dont on a besoin pour une sauvegarde de données personnelles. On y ajoute /DCOPY:DAT pour que les dossiers conservent aussi leurs dates.

Il y a un corollaire à connaître, et il faut le dire au client : une sauvegarde vers un NAS perd les autorisations d'origine. Ce n'est pas gênant pour restaurer des documents personnels — c'est en revanche à savoir si vous archivez un dossier partagé d'entreprise avec des droits finement réglés. Dans ce cas, l'archivage doit se faire dans un conteneur qui préserve les ACL (VHDX, image de sauvegarde), pas dans une arborescence SMB à plat.

6. Piège n°4 : OneDrive et les fichiers à la demande

Celui-là ne provoque pas d'erreur — il fait pire, il fait trop.

Avec les fichiers à la demande, OneDrive n'affiche sur votre disque que des espaces réservés : le nom, la taille, l'icône sont là (petit nuage bleu dans la colonne État), mais le contenu est resté dans le cloud. Le fichier ne pèse quasiment rien sur le disque.

Quand un outil de copie ouvre l'un de ces espaces réservés, Windows fait ce pour quoi le système est conçu : il télécharge le fichier à la volée. À l'échelle d'un profil entier, cela signifie rapatrier la totalité du OneDrive du client — parfois plusieurs centaines de gigaoctets — via sa connexion internet, avant de le renvoyer vers le NAS. Une copie prévue pour deux heures en prend vingt, sature la ligne, et remplit le disque système au passage. Et si le compte OneDrive est saturé, la synchronisation en pause, ou le client OneDrive arrêté, l'hydratation échoue et robocopy renvoie l'erreur 362 (code de sortie 9).

L'option /XA:O exclut les fichiers portant l'attribut offline — c'est-à-dire précisément les espaces réservés en ligne uniquement. Ils ne seront pas copiés, ce qui est le comportement souhaitable : ces fichiers sont déjà dans le cloud, ils reviendront seuls dès que le compte OneDrive sera reconnecté après la réinstallation.

Une nuance importante à ne pas manquer : /XA:O protège la copie, il ne dit rien de la stratégie de sauvegarde. Si le client veut aussi un exemplaire hors ligne de son OneDrive (ce qui est légitime), deux méthodes fiables :

1. Dans l'Explorateur, clic droit sur le dossier OneDrive → « Toujours conserver sur cet appareil », et attendre que plus aucun nuage bleu n'apparaisse dans la colonne État — ce qui suppose que le client OneDrive tourne et que la synchronisation n'est pas en pause.

2. Plus fiable en atelier : se connecter sur onedrive.com et utiliser Télécharger, qui produit une archive ZIP indépendante du poste.

Vérification qui ne trompe pas, une fois la copie faite : ouvrez trois ou quatre fichiers au hasard depuis le NAS. Un espace réservé copié par erreur fait 0 Ko et ne s'ouvre pas.

Sujet voisin : Icônes du bureau devenues blanches sous Windows 11, un autre effet de bord des fichiers à la demande.

7. La commande complète, expliquée option par option

Voici la commande utilisée en atelier. Elle s'exécute dans une invite de commandes en administrateur (le symbole ^ sert uniquement à couper la ligne pour la lisibilité — vous pouvez tout écrire d'un trait).

Option	Rôle	Pourquoi elle est là
/E	Copie les sous-dossiers, y compris vides	Préserve la structure exacte
/ZB	Mode redémarrable, avec repli en mode sauvegarde	Passe outre certains fichiers verrouillés ou dont vous n'êtes pas propriétaire. Exige une invite en administrateur (privilège de sauvegarde)
/XJ	Exclut les jonctions	Chapitre 3 — sans elle, boucles infinies et faux « chemins trop longs »
/COPY:DAT	Données, attributs, horodatages — pas les ACL	Chapitre 5 — évite des milliers d'échecs de sécurité sur SMB
/DCOPY:DAT	Même chose pour les dossiers	Conserve les dates des dossiers
/XA:O	Exclut les fichiers en ligne uniquement	Chapitre 6 — évite d'hydrater tout le OneDrive
/R:1 /W:1	1 nouvelle tentative, 1 seconde d'attente	Indispensable : par défaut robocopy réessaie un million de fois avec 30 s d'attente, soit une copie qui semble figée sur un seul fichier verrouillé
/MT:16	16 fils de copie en parallèle	Gain considérable sur SMB, où le coût est dans le nombre d'allers-retours réseau, pas dans le débit. Incompatible avec /IPG et /EFSRAW
/NP	Pas de pourcentage de progression	Sans elle, le journal se remplit de milliers de lignes de progression illisibles
/TEE	Affiche et journalise	On voit défiler la copie tout en gardant la trace
/LOG:	Fichier journal	La pièce maîtresse : c'est lui qui listera les échecs. À écrire ailleurs que sur la source et la destination
/XD	Dossiers exclus	Caches, fichiers temporaires et conteneurs d'applications du Store : volumineux, inutiles, et souvent verrouillés

Quelques précisions de terrain :

• Donnez des chemins source complets à /XD. La correspondance sur un nom relatif est moins fiable et peut exclure des dossiers homonymes ailleurs dans l'arborescence.

• NTUSER.DAT restera probablement en échec. C'est le fichier de registre du profil, ouvert en permanence par la session en cours. Trois options : copier depuis une autre session Windows, copier depuis un environnement de démarrage (WinPE, ou disque branché sur un autre PC), ou simplement l'accepter — pour une sauvegarde de données personnelles, ce fichier n'a aucune utilité de restauration.

• Le journal peut être écrit sur un disque externe. Évitez le NAS : si le réseau tombe, vous perdez la trace au moment précis où elle devient utile.

8. Le contrôle qui prouve que la copie est complète

C'est l'étape que personne ne fait, et c'est pourtant la seule qui transforme une copie en sauvegarde vérifiée. Robocopy sait fonctionner en simulation : avec /L, il compare source et destination et vous dit ce qu'il aurait copié, sans rien écrire.

Le récapitulatif final doit afficher, sur la ligne Fichiers : 0 Copié, 0 Discordance, 0 ÉCHEC. Si un nombre non nul apparaît en Copié, c'est qu'il reste des fichiers à transférer — relancez la commande du chapitre 7, elle ne recopiera que ce qui manque.

Lire les codes de retour sans se tromper

C'est un piège classique, y compris pour des informaticiens : robocopy ne renvoie pas 0 en cas de succès, contrairement à la quasi-totalité des programmes en ligne de commande.

Code	Signification
0	Rien à faire — les deux dossiers étaient déjà identiques
1	Des fichiers ont été copiés — c'est le succès normal
2	Des éléments supplémentaires existent dans la destination
3	Combinaison de 1 et 2 (copie réussie + éléments en plus)
≥ 8	Échec réel — des fichiers n'ont pas pu être copiés

Autrement dit : un script qui teste if errorlevel 1 → erreur déclarera en échec toutes vos copies réussies. Le seuil correct est 8.

La règle absolue : jamais /MIR pour compléter

/MIR met la destination en miroir exact de la source. C'est très pratique pour une sauvegarde récurrente… et catastrophique pour compléter une copie partielle : tout ce qui existe dans la destination mais plus dans la source est supprimé. Si le client a déjà rangé, trié ou ajouté des choses sur le NAS, /MIR les efface. Pour compléter, /E suffit : il n'ajoute que ce qui manque et ne supprime jamais rien.

9. Ce qui reste en échec malgré tout (et comment le régler)

Même avec la bonne commande, quelques fichiers peuvent résister. Le journal les liste — c'est précisément à cela qu'il sert. Voici les trois cas rencontrés en atelier.

Noms se terminant par un espace ou un point. NTFS les accepte lorsqu'ils sont créés via le préfixe \\?\ (certains logiciels le font, ou ils arrivent d'un partage d'un autre système). La couche SMB d'un NAS sous Linux les refuse. Le fichier est lu sans problème, mais impossible à créer côté destination. Solution : les renommer à la source (là encore avec \\?\ si l'Explorateur refuse), puis relancer la copie.

Composants de nom dépassant 255 octets. Piège subtil : NTFS compte en caractères, tandis qu'ext4 et Btrfs comptent en octets. En UTF-8, un accent pèse 2 octets, un caractère chinois 3, un emoji souvent 4. Un nom de 200 caractères bourré d'accents et d'emojis peut donc passer sous NTFS et être rejeté par le NAS. Même remède : raccourcir le nom à la source.

Fichiers verrouillés par le système ou l'antivirus. NTUSER.DAT (voir chapitre 7), mais aussi les bases de données ouvertes par un logiciel métier, et surtout les fichiers protégés par un antivirus. Ce dernier cas mérite une vigilance particulière : certaines suites de sécurité laissent le fichier se copier puis le re-suppriment à la destination, ce qui creuse un trou dans la sauvegarde sans qu'aucune erreur n'apparaisse. Mettez l'antivirus en pause le temps de la copie (clic droit sur son icône), et revérifiez ensuite avec le /L du chapitre 8.

10. Cas voisin : le NAS refuse carrément la connexion

Il arrive qu'on ne parvienne même pas à l'étape de la copie. Le partage réseau ne s'ouvre pas, et Windows affiche l'un de ces messages :

• « Vous ne pouvez pas accéder à ce dossier partagé, car les stratégies de sécurité de votre organisation bloquent l'accès des invités non authentifiés » ;

• l'erreur 0x80070035, « Le chemin d'accès réseau n'a pas été trouvé » ;

• une fenêtre d'identifiants qui revient en boucle alors que le partage n'a pas de mot de passe.

Ce n'est pas un problème de copie mais de durcissement du protocole SMB : depuis Windows 11 24H2, la signature SMB est obligatoire et l'accès invité est refusé par défaut ; en 25H2, SMB1 a disparu. Les tutoriels antérieurs à 2024, qui ne mentionnent qu'un seul réglage, ne suffisent plus.

La bonne pratique, dans ce cas, n'est pas d'affaiblir le PC mais de créer un compte utilisateur sur le NAS (Synology DSM, QNAP QTS, TrueNAS), de lui donner les droits sur le dossier de sauvegarde et de cocher « Mémoriser mes identifiants » côté Windows. C'est aussi rapide, et on ne dégrade la sécurité de rien. Le contournement par accès invité ne se justifie que pour du matériel incapable de gérer un compte : très vieux NAS, disque partagé par une box internet, imprimante multifonction, lecteur multimédia.

Le détail complet de ce cas — les deux réglages nécessaires depuis 24H2, la méthode par stratégie de groupe, les événements SMBClient qui permettent de vérifier — est traité dans notre article dédié : Activer l'accès invité SMB sous Windows 11 pour accéder à un NAS.

11. En résumé

1. L'Explorateur abandonne silencieusement les fichiers dont le chemin dépasse 260 caractères. Après un clic sur Ignorer, la copie paraît réussie et rien ne signale le trou.

2. LongPathsEnabled ne règle pas ce cas : l'Explorateur n'est pas compatible chemins longs, même sous Windows 11. Activez-le pour l'exploitation ultérieure de la copie, pas pour la copie.

3. robocopy gère les chemins longs nativement, sans réglage préalable, et il est déjà installé sur votre PC.

4. Sur un profil utilisateur, /XJ est obligatoire : les jonctions de compatibilité de C:\Users bouclent et fabriquent elles-mêmes les chemins interminables.

5. Vers un NAS, /COPY:DAT et surtout pas /COPYALL : les ACL NTFS ne se stockent pas sur un partage SMB.

6. /XA:O évite de rapatrier tout le OneDrive du client par la ligne internet.

7. Mappez une lettre de lecteur au plus près du dossier cible : le budget de 260 caractères se consomme côté destination.

8. Vérifiez avec /L : le récapitulatif doit afficher 0 Copié / 0 Discordance / 0 ÉCHEC. Code de retour 1 = succès, ≥ 8 = échec.

9. Jamais /MIR pour compléter une copie : il supprime dans la destination.

10. Et la meilleure sauvegarde avant réinstallation reste celle qu'on ne fait pas : installer Windows sur un SSD neuf et garder le disque d'origine intact quelques semaines. Sur une machine de cinq ans et plus, c'est souvent le meilleur rapport sécurité/prix.

À lire aussi avant de formater quoi que ce soit : Réinstaller Windows sans perdre ses données : les pièges OneDrive, antivirus et mots de passe navigateur, et Supprimer un fichier au nom trop long sous Windows, l'autre face du même problème de chemins.

Besoin d'un coup de main ?

Une sauvegarde de profil vers un NAS, c'est une demi-journée de tâtonnements quand on découvre ces pièges un par un — et une opération de routine quand on connaît la commande et le contrôle qui va avec. Si vous préférez ne pas vous lancer, ou si la sauvegarde doit précéder une réinstallation que vous ne voulez pas rater, nous nous en chargeons.

• Sauvegarde, réinstallation, mise en place et paramétrage de NAS, particuliers comme professionnels — en atelier ou sur site : BSC Informatique, 18 Av Olbius Riquier, 83400 Hyères, 04 94 27 65 95, www.bsc-informatique.fr. Nous vendons et installons également le matériel : NAS, disques, SSD.

• Vous êtes un particulier et vous préférez qu'on vienne le faire chez vous — installation du NAS, sauvegarde de vos données, explications sans jargon : BSC Assistance, assistance informatique à domicile, agréée service à la personne.

• Le disque source fait du bruit, ralentit, ou des fichiers reviennent illisibles : n'insistez pas, chaque lecture supplémentaire coûte des chances. BSC DataRecovery — récupération de données sur disques durs, SSD, cartes mémoire, clés USB et systèmes RAID.

• Le PC ne s'allume plus, ne charge plus, ou un port USB est hors service — c'est de la réparation de carte mère : BSC Électronique (PC portables et Chromebooks, hors Apple).

• Il vous faut une machine pendant l'immobilisation de la vôtre : BSC Location loue des ordinateurs fixes et portables, en courte comme en longue durée.

• Votre PC est envahi d'alertes, de notifications publicitaires ou de faux messages de support : BSC Sécurité, suppression de virus et nettoyage de navigateurs.

Sources : synthèse des interventions de l'atelier BSC Informatique (copies de profils vers NAS Synology et QNAP, cas mesuré du 24 juillet 2026 — 364 Go / 198 183 fichiers, 1 556 fichiers et 81 dossiers manquants après copie Explorateur, puis copie complète et vérifiée par robocopy), recoupée avec la documentation Microsoft Learn sur la limitation MAX_PATH et le réglage LongPathsEnabled (applications longPathAware uniquement), la référence des commutateurs robocopy (/XJ, /COPY:DAT, /XA:O, /MT, codes de sortie), la documentation OneDrive sur les fichiers à la demande et l'attribut hors connexion, et les notes Microsoft sur le durcissement SMB de Windows 11 24H2 et 25H2. Les manipulations décrites engagent vos données : vérifiez toujours une sauvegarde avant de formater une source. BSC Informatique — EURL BSC INFORMATIQUE — 18 Avenue Olbius Riquier, 83400 Hyères — 04 94 27 65 95.

Sauvegarde, NAS et réinstallation à Hyères

Sauvegarde vérifiée avant réinstallation, mise en place et paramétrage de NAS,
transfert de profil utilisateur — particuliers et professionnels, en atelier ou sur site.

Tél. 04 94 27 65 95