Windows 11 Dev Drive : l’accélération des builds (parlons franchement)

Ce qu’est réellement Dev Drive (et ce que ce n’est pas)

Dev Drive est une fonctionnalité de Windows qui crée un volume ciblé pour développeurs, généralement formaté en ReFS (Resilient File System), et optimisé pour réduire la « mort par mille opérations de fichiers » dans les arbres de build. Il est associé à des comportements de Microsoft Defender visant à rendre le scanning moins perturbateur pour les répertoires dev à fort turnover.

Ce n’est pas de la magie. Ça n’« accélère pas votre CPU ». Ça ne résout pas un projet avec un graphe de build pathologique. Ça ne transforme pas un disque dur en SSD. L’objectif principal est d’attaquer une douleur spécifique : beaucoup de petites E/S de fichiers où l’antivirus et le surcoût des métadonnées deviennent le coût dominant.

Dev Drive s’accompagne de garde-fous et de compromis. ReFS se comporte différemment de NTFS. Certains outils supposent des particularités de NTFS. Certaines politiques d’entreprise partent du principe que tout est sur « C:\ ». Et les sauvegardes peuvent devenir étranges si votre organisation pense que « les machines développeur n’en ont pas besoin » (ce qui est une stratégie audacieuse).

Si vous construisez principalement des conteneurs sur WSL2 avec des bind mounts vers des chemins Windows, Dev Drive peut quand même avoir de l’importance — car la douleur se situe souvent à la frontière du système de fichiers Windows, pas à l’intérieur de Linux. Mais si votre goulot est une compilation liée au CPU ou des caches distants manquants, Dev Drive restera poliment inactif.

Pourquoi les builds sont lents sous Windows : les vrais goulots

Les problèmes de performance de build se présentent typiquement en trois catégories :

1) CPU-bound : vous compilez réellement

Quand vous compilez de grosses unités de traduction, exécutez un JIT, ou faites des optimisations lourdes, le disque n’est qu’un acteur secondaire. Dev Drive n’aidera pas beaucoup. Vos gains viennent du parallélisme, des PCH, des builds incrémentiels, de la compilation distribuée, et de ne pas tout reconstruire pour un changement de commentaire.

2) E/S-bound sur petits fichiers : la taxe « node_modules »

C’est le classique. Restauration de paquets, checkouts Git, indexation par des language servers, et systèmes de build qui parcourent d’immenses arbres. Le disque n’est pas « lent » en débit ; il est lent en latence et travail sur les métadonnées : ouvrir, fermer, statuer, et scanner une montagne de petits fichiers.

L’antivirus aggrave cela car chaque création/ouverture peut déclencher des hooks de scan et des drivers de filtre. Ce surcoût n’est pas constant ; il pique quand votre build génère des binaires neufs et des artefacts intermédiaires. Donc vos builds paraissent « aléatoirement lents », ce qui est le pire type de lenteur.

3) Comportement pathologique des outils : le tueur silencieux

Certaines outils rescannent l’arbre en boucle. D’autres génèrent un grand nombre de fichiers intermédiaires. Certains écrivent des logs de manière synchrone. D’autres utilisent des watchers qui retombent sur du polling et punissent votre stockage. Vous pouvez lancer ReFS contre tout cela et encore perdre.

Dev Drive vise directement la catégorie 2 : les arbres de dev qui sont effectivement un benchmark de métadonnées. Si c’est votre cas, c’est à considérer sérieusement.

Une citation à retenir (idée paraphrasée) : Gene Kim souligne souvent que des boucles de feedback rapides sont la base d’une livraison et d’une fiabilité efficaces. Votre temps de build est un enjeu de fiabilité.

Blague n°1 : Si votre build a besoin d’une pause café, ce n’est pas « par souci du détail », il attend probablement l’antivirus.

Faits intéressants et contexte historique (parce que ça n’est pas sorti de nulle part)

1. ReFS a fait ses débuts dans Windows Server 2012 comme un système de fichiers de nouvelle génération axé sur la résilience et l’intégrité plutôt que sur la compatibilité héritée.
2. NTFS remonte au début des années 1990. Il est éprouvé au combat, mais il porte des comportements de compatibilité de décennies qui ne sont pas optimisés pour les charges dev modernes.
3. Windows Defender utilise des drivers de filtre de système de fichiers pour inspecter l’activité. C’est puissant — et aussi une source majeure de surcoût par fichier pendant les builds.
4. Les charges dev ont changé : « un repo » signifie souvent des centaines de milliers de fichiers une fois dépendances et artefacts générés inclus.
5. Les workflows basés sur VHD/VHDX sont vieux dans l’ops ; nous isolons des charges via des disques virtuels depuis des années car ils sont faciles à déplacer, snapshotter et supprimer.
6. ReFS a historiquement été une affaire serveur, mais Dev Drive le porte sur les postes clients de façon ciblée, pas comme remplacement universel.
7. Accélérer un build signifiait avant tout des disques plus rapides ; maintenant cela signifie souvent réduire le « travail par fichier » via cache, scans intelligents, et éviter les touches inutiles au système de fichiers.
8. Les fonctionnalités d’intégrité des fichiers ont un coût. Les checksums et vérifications améliorent la fiabilité, mais ajoutent CPU et E/S sauf si elles sont ajustées pour la charge.
9. Le durcissement de la sécurité Windows a augmenté avec le temps, et c’est une bonne chose — jusqu’à ce que votre répertoire de build ressemble à un comportement de malware (créations rapides de fichiers, compilation, exécution).

Sous le capot : ReFS, filtres et pourquoi Defender compte

ReFS vs NTFS pour les arbres de développement

ReFS (Resilient File System) est conçu avec des hypothèses de stockage modernes : gros volumes, fonctionnalités d’intégrité, et gestion des métadonnées qui peut être plus amicale sous une activité parallèle intense sur les fichiers. Pour les builds, l’implication pratique est souvent : moins de « blocages étranges » lorsque de nombreux processus créent et interrogent beaucoup de fichiers.

Mais ReFS n’est pas un remplacement transparent pour chaque fonctionnalité NTFS que vous avez intégrée. Certaines fonctionnalités spécifiques à NTFS ne sont pas présentes ou se comportent différemment. Si votre toolchain a des hypothèses anciennes (ou dépend de la compression NTFS, EFS, ou de certains cas limites de reparse-point), vous devez tester. Ne déployez pas cela comme une note de politique.

Defender : pas le méchant, mais il est dans le chemin chaud

Franchement : Defender fait son travail. Les builds ont l’air suspects. Ils créent des exécutables, écrivent dans des répertoires temporaires, téléchargent des paquets, et exécutent des scripts. Un produit de sécurité qui ignorerait cela serait… créativement négligent.

Le pitch de Dev Drive n’est pas « désactiver la sécurité ». C’est « appliquer une posture de scan orientée performance pour des emplacements dev de confiance », en réduisant la taxe constante de scanner chaque ouverture de fichier. C’est la différence entre une configuration pragmatique et un incident de sécurité qui attend de se produire.

Le motif d’E/S que cible Dev Drive

• création/ouverture/fermeture de fichiers à haute fréquence
• nombreuses lectures concurrentes sur beaucoup de petits fichiers
• turnover rapide dans les répertoires intermédiaires (obj/bin, bazel-out, target, dist, build, .gradle, etc.)
• chemins locaux répétables et « code connu » où scanner chaque accès est moins utile que scanner aux frontières

Si votre build effectue des lectures/écritures séquentielles soutenues et volumineuses (par exemple, assets vidéo, archives monolithiques géantes), Dev Drive peut être neutre. Votre limite de performance est probablement le SSD, le contrôleur ou la régulation thermique — pas le chemin des métadonnées du système de fichiers.

Options d’installation : partition, VHDX, ou « s’il vous plaît ne faites pas ça »

Option A : Partition dédiée (idéal pour un usage quotidien sérieux)

Quand vous pouvez libérer l’espace, un volume dédié est simple. Lettre de lecteur prévisible, performance stable, moins de couches. Si vous avez un NVMe rapide et que vous buildez constamment, c’est généralement l’option la plus simple.

Utilisez ceci quand : vous êtes stable sur une machine, avez des droits admin, et voulez le comportement le moins surprenant.

Option B : Dev Drive en VHDX (idéal pour isolation et portabilité)

Un Dev Drive basé sur VHDX est un compromis solide : vous pouvez l’allouer dynamiquement, le placer sur un disque rapide, et le supprimer s’il est corrompu ou gonflé. Il facilite aussi les « environnements dev séparés » : un VHDX par client ou par branche majeure.

Utilisez ceci quand : vous voulez garder votre OS propre, vous réinstallez souvent des machines, ou vous supportez plusieurs toolchains incompatibles.

Option C : Mettre toute votre vie sur Dev Drive (ne le faites pas)

Dev Drive est pour le source, les dépendances et les artefacts de build. Pas pour les photos de famille. Pas pour votre coffre-fort de mots de passe. Pas pour votre dossier « Téléchargements » où atterrissent des exécutables aléatoires. Gardez votre rayon d’explosion petit. La posture de sécurité repose sur des frontières de confiance, et votre arbre dev doit être traité comme une zone spéciale, pas comme toute la ville.

Blague n°2 : Si vous stockez votre répertoire personnel entier sur Dev Drive, félicitations — vous avez inventé « production » à nouveau, mais avec moins de sauvegardes.

Tâches pratiques : commandes, sorties et décisions

Ci‑dessous des tâches réelles que j’exécuterais sur une machine Windows 11 quand quelqu’un dit « Dev Drive n’a rien changé » ou « Dev Drive a tout réparé ». Nous traiterons les deux affirmations avec la même suspicion.

Important : Les commandes sont montrées en PowerShell. Les extraits de sortie sont représentatifs. Vos valeurs exactes différeront. L’important est ce que vous apprenez et la décision que vous prenez.

Tâche 1 : Confirmer que la build Windows supporte les fonctionnalités Dev Drive

cr0x@server:~$ powershell -NoProfile -Command "Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber"
WindowsProductName WindowsVersion OsBuildNumber
----------------- -------------- -------------
Windows 11 Pro     23H2          22631

Ce que ça signifie : Vous avez besoin d’une version moderne de Windows 11 où Dev Drive est disponible et stable. Si vous êtes sur une build plus ancienne, le comportement et les options UI peuvent différer.

Décision : Si l’OS est obsolète, mettez-le à jour d’abord. Ne benchmarkez pas une fonctionnalité que vous ne pouvez pas utiliser pleinement.

Tâche 2 : Lister les volumes et types de système de fichiers (trouver ReFS vs NTFS)

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume | Sort-Object DriveLetter | Format-Table DriveLetter, FileSystem, FileSystemLabel, SizeRemaining, Size -Auto"
DriveLetter FileSystem FileSystemLabel SizeRemaining      Size
----------- ---------- -------------- -------------      ----
C           NTFS       Windows        122.4 GB       476.8 GB
D           ReFS       DevDrive       311.2 GB       476.8 GB

Ce que ça signifie : Vous avez un volume ReFS nommé DevDrive. Bien. Si c’est NTFS, vous ne testez pas l’angle principal de Dev Drive.

Décision : Si votre « Dev Drive » est en réalité NTFS, arrêtez. Corrigez ça avant de blâmer la fonctionnalité.

Tâche 3 : Vérifier si le disque est réellement SSD/NVMe

cr0x@server:~$ powershell -NoProfile -Command "Get-PhysicalDisk | Format-Table FriendlyName, MediaType, BusType, Size -Auto"
FriendlyName          MediaType BusType Size
------------          --------- ------- ----
NVMe Samsung SSD 980  SSD       NVMe    1 TB

Ce que ça signifie : Si MediaType est HDD ou BusType est USB, vous optimisez la mauvaise couche. Dev Drive ne corrige pas la latence rotationnelle ni les enceintes externes lentes.

Décision : Si ce n’est pas NVMe/SSD, corrigez le placement matériel avant d’ajuster le système de fichiers.

Tâche 4 : Vérifier l’alignement de partition (le mauvais alignement peut nuire aux E/S aléatoires)

cr0x@server:~$ powershell -NoProfile -Command "Get-Partition -DriveLetter D | Select-Object DriveLetter, Offset, Size"
DriveLetter Offset   Size
----------- ------   ----
D           1048576  476.8 GB

Ce que ça signifie : Un offset de 1 048 576 octets (1 MiB) est l’alignement moderne « correct ». Des offsets bizarres peuvent provoquer des lectures/écritures supplémentaires.

Décision : Si l’alignement est étrange (pas environ 1 MiB), recréez la partition. Ne combattez pas la physique.

Tâche 5 : Voir si Defender est dans le chemin chaud pour votre arbre de build

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object -ExpandProperty ExclusionPath"
C:\Windows\Temp

Ce que ça signifie : Exclusions minimales. C’est normal en environnements verrouillés. Mais si votre arbre dev n’est pas traité spécialement, Defender peut scanner agressivement.

Décision : Si la politique d’entreprise le permet, configurez Dev Drive correctement plutôt que de parsemer des exclusions larges partout.

Tâche 6 : Confirmer l’état de la protection temps réel de Defender (ne présumez pas)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object RealTimeProtectionEnabled, BehaviorMonitorEnabled, AntivirusEnabled"
RealTimeProtectionEnabled BehaviorMonitorEnabled AntivirusEnabled
------------------------ ---------------------- ---------------
True                     True                   True

Ce que ça signifie : Defender est actif. Bien. Vous devez maintenant considérer le tuning de performance comme « rendre le scan plus intelligent », pas « l’éteindre ».

Décision : Si vous pensiez que Defender était désactivé alors qu’il est actif, vos hypothèses de benchmark sont déjà faussées.

Tâche 7 : Mesurer l’impact de Defender avec un test contrôlé de parcours de fichiers

cr0x@server:~$ powershell -NoProfile -Command "Measure-Command { Get-ChildItem -Recurse -File D:\repo | Out-Null } | Select-Object TotalSeconds"
TotalSeconds
------------
7.814

Ce que ça signifie : C’est un instrument grossier, mais utile. La traversée de répertoires est une grande partie de nombreux builds (globbing, scanning de dépendances, indexation).

Décision : Exécutez le même test sur un emplacement NTFS avec le même repo. Si ReFS + Dev Drive est sensiblement plus rapide, vous êtes dans la zone cible.

Tâche 8 : Vérifier l’indexation Windows sur le volume dev

cr0x@server:~$ powershell -NoProfile -Command "Get-Service WSearch | Select-Object Status, StartType, Name"
Status StartType Name
------ --------- ----
Running Automatic WSearch

Ce que ça signifie : L’indexation peut ajouter des E/S en arrière-plan et des ouvertures de fichiers. Pas toujours terrible, mais parfois elle se dispute votre charge de travail.

Décision : Si les builds sont erratiques pendant l’indexation, réduisez les emplacements indexés ou excluez le volume dev de l’indexation (si la politique le permet).

Tâche 9 : Vérifier le queueing disque et la latence pendant un build réel

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Read','\PhysicalDisk(_Total)\Avg. Disk sec/Write','\PhysicalDisk(_Total)\Current Disk Queue Length' -SampleInterval 1 -MaxSamples 3"
Timestamp                 CounterSamples
---------                 --------------
2/5/2026 10:14:01 AM      \\...\Avg. Disk sec/Read : 0.004
                           \\...\Avg. Disk sec/Write: 0.012
                           \\...\Current Disk Queue Length: 1
2/5/2026 10:14:02 AM      \\...\Avg. Disk sec/Read : 0.021
                           \\...\Avg. Disk sec/Write: 0.034
                           \\...\Current Disk Queue Length: 9
2/5/2026 10:14:03 AM      \\...\Avg. Disk sec/Read : 0.018
                           \\...\Avg. Disk sec/Write: 0.028
                           \\...\Current Disk Queue Length: 7

Ce que ça signifie : Des millisecondes à un chiffre sont acceptables. Quand vous voyez des dizaines de millisecondes et de longues files d’attente, vous êtes lié au stockage (ou vous êtes throttlé).

Décision : Si la latence pique pendant la restauration de dépendances et la génération de fichiers, Dev Drive est pertinent. Si la latence est stable mais le CPU est saturé, cherchez ailleurs.

Tâche 10 : Identifier les processus qui touchent le disque intensément

cr0x@server:~$ powershell -NoProfile -Command "Get-Process | Sort-Object IOReadBytes -Descending | Select-Object -First 5 Name, Id, IOReadBytes, IOWriteBytes"
Name           Id IOReadBytes IOWriteBytes
----           -- ----------- ------------
MsMpEng      4212  987654321    123456789
node         15840  654321098     98765432
cl           17400  612345678    212345678
dotnet       18888  512345678    112345678
git          19544  212345678     12345678

Ce que ça signifie : Si MsMpEng (Defender) est en haut pendant les builds, vous avez trouvé un suspect majeur. Si ce sont votre compilateur et linker, vous êtes peut-être simplement en train de beaucoup compiler.

Décision : Un I/O élevé de MsMpEng suggère que vous devez configurer correctement Dev Drive et/ou des frontières de scan plus intelligentes.

Tâche 11 : Valider que votre repo est sur le volume prévu

cr0x@server:~$ powershell -NoProfile -Command "Resolve-Path D:\repo | Select-Object Path"
Path
----
D:\repo

Ce que ça signifie : Vous seriez surpris de voir à quelle fréquence des gens benchmarquent « Dev Drive » alors que leur repo réel est sur C:\ à cause d’un symlink, d’une configuration d’IDE erronée, ou de la mémoire musculaire.

Décision : Si le repo n’est pas sur le Dev Drive, déplacez-le. Puis retestez.

Tâche 12 : Détecter les reparse points et bizarreries de symlink dans le repo

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem D:\repo -Force -Attributes ReparsePoint -Recurse -ErrorAction SilentlyContinue | Select-Object -First 5 FullName, LinkType"
FullName                               LinkType
--------                               --------
D:\repo\node_modules\.bin\eslint.cmd   Junction
D:\repo\packages\shared\dist           SymbolicLink

Ce que ça signifie : Certains outils de build et scanners se comportent mal autour des jonctions/symlinks, provoquant des rescans ou même des cycles.

Décision : Si vous voyez beaucoup de reparse points, assurez-vous que vos outils et règles de scan gèrent correctement ces cas. Envisagez d’aplanir la disposition si elle est pathologique.

Tâche 13 : Vérifier l’espace libre et le risque de fragmentation (oui, même sur SSD)

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume -DriveLetter D | Select-Object DriveLetter, SizeRemaining, Size, HealthStatus"
DriveLetter SizeRemaining      Size HealthStatus
----------- -------------      ---- ------------
D           311.2 GB       476.8 GB Healthy

Ce que ça signifie : Les charges dev gonflent rapidement. Un faible espace libre augmente l’amplification d’écriture et peut déclencher des comportements SSD désagréables.

Décision : Si vous êtes sous ~15–20% d’espace libre, agrandissez le volume ou nettoyez les caches de build. Ne « optimisez » pas un disque quasi plein.

Tâche 14 : Chercher la régulation thermique et les problèmes de plan d’alimentation

cr0x@server:~$ powershell -NoProfile -Command "powercfg /getactivescheme"
Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e  (Balanced)

Ce que ça signifie : Le mode Balanced est généralement acceptable, mais les portables sous charge de build peuvent réduire la fréquence CPU ou brider le stockage par chaleur.

Décision : Si vous observez une baisse de performance après quelques minutes, testez en « Meilleures performances » et surveillez les températures. Dev Drive ne résoudra pas un portable en surchauffe.

Tâche 15 : Vérifier que votre build est réellement incrémentiel

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem D:\repo\build -Recurse -File | Measure-Object | Select-Object Count"
Count
-----
182344

Ce que ça signifie : De grands répertoires de build peuvent être normaux, mais s’ils grossissent sans contrôle vous payez des scans et parcours de fichiers supplémentaires à chaque fois.

Décision : Si le nombre d’artefacts explose, ajoutez des politiques de nettoyage et assurez-vous que votre outil de build n’est pas mal configuré au point de désactiver l’incrémentalité.

Feuille de diagnostic rapide (trouver le goulot en 15 minutes)

Voici la séquence « arrêtez de débattre et mesurez ». Faites-la dans l’ordre. Chaque étape confirme soit que Dev Drive est le levier approprié — soit qu’il faut arrêter de perdre du temps.

Première étape : Décidez si vous êtes lié par l’E/S ou par le CPU

• Vérifiez la saturation CPU : si tous les cœurs sont saturés et que la latence disque reste basse, Dev Drive ne sera pas le héros.
• Vérifiez la latence disque et la longueur de file pendant l’étape lente : si la latence augmente et la file s’allonge, vous êtes lié par l’E/S.

Deuxième étape : Identifiez si le scan de sécurité est la taxe

• Si MsMpEng fait partie des processus I/O en tête pendant les builds, Defender est matériellement impliqué.
• Si l’I/O de Defender est faible, concentrez-vous sur les outils (résolveur de dépendances, linker, file watcher) ou sur le matériel de stockage.

Troisième étape : Prouvez que la couche de stockage est bien celle que vous pensez

• Confirmez que le repo est sur le volume Dev Drive.
• Confirmez que ce volume est sur un SSD/NVMe (pas un « disque externe rapide » qui est en réalité un goulot).
• Confirmez l’espace libre et l’absence de problèmes de configuration évidents (indexation, agents de sauvegarde, outils de synchronisation).

Quatrième étape : Faites un test A/B, pas des impressions

Choisissez une opération représentative : checkout propre + restauration de paquets + build. Exécutez-la sur NTFS et sur Dev Drive, même machine, même commit, même réseau, même mode d’alimentation. Si le delta est dans le bruit, Dev Drive n’est pas votre facteur limitant.

Erreurs courantes (symptôme → cause racine → correction)

1) « Dev Drive n’a rien fait. »

Symptôme : Temps de build inchangés après avoir déplacé le repo.

Cause racine : La phase lente est CPU-bound (compilation/link) ou réseau-bound (téléchargements de paquets).

Correction : Profilez les phases de build. Si c’est CPU-bound, améliorez l’incrémentalité, le parallélisme et le caching. Si c’est réseau-bound, utilisez des caches locaux, des mirrors ou des lockfiles. Dev Drive n’accélère pas le réseau.

2) « Dev Drive est plus lent que C:\. »

Symptôme : Les opérations fichier semblent lentes ; l’indexation de l’IDE est plus lente.

Cause racine : Dev Drive placé sur un stockage plus lent (SSD secondaire, boîtier externe) ou dans un VHDX contraint sur un disque occupé.

Correction : Placez le Dev Drive sur le NVMe local le plus rapide. Si vous utilisez VHDX, assurez-vous que le disque hôte a de la marge et ne partage pas des charges lourdes (clients de sync, images VM, jeux — oui, les jeux génèrent des E/S).

3) « Ma toolchain a cassé après le passage sur Dev Drive. »

Symptôme : Hooks Git échouent, étapes de build errent, problèmes étranges de permissions.

Cause racine : L’outil dépend de comportements spécifiques à NTFS, d’hypothèses de chemin, ou d’une politique d’entreprise codée en dur sur C:\.

Correction : Validez la compatibilité de l’outil avec ReFS. Au besoin, gardez des répertoires spécifiques sur NTFS (par ex. outils legacy) et placez les artefacts bruyants sur Dev Drive. Scindez la charge plutôt que d’imposer la pureté.

4) « La restauration de paquets est toujours lente. »

Symptôme : npm/pnpm/yarn, NuGet, Maven/Gradle prennent une éternité.

Cause racine : Latence réseau, inspection TLS, ou proxy corporate faisant un scan approfondi. Le système de fichiers local n’est pas le goulot.

Correction : Mesurez séparément le temps de téléchargement et le temps d’extraction. Utilisez des caches locaux quand c’est permis. Si l’inspection TLS est le goulot, escaladez avec des preuves ; ne vous contentez pas de vous plaindre.

5) « Mon disque est rapide mais les builds sont variables. »

Symptôme : Certaines exécutions sont rapides, d’autres lentes, sans changements de code.

Cause racine : Tâches en arrière-plan : indexation, clients de sync, agents de sauvegarde, scans complets Defender, ou Windows Update.

Correction : Vérifiez les processus I/O responsables pendant les runs lents. Planifiez le travail intensif en dehors des heures dev ou excluez le Dev Drive de l’indexation si la politique le permet.

6) « Les builds WSL sont lents même si Linux est rapide. »

Symptôme : Build dans WSL2 lent quand le repo est sous /mnt/c ou un autre chemin monté depuis Windows.

Cause racine : Surcharge à la frontière des systèmes de fichiers cross-OS. Beaucoup d’appels de métadonnées traversent cette frontière.

Correction : Gardez le repo dans le système de fichiers natif WSL pour les builds Linux, ou utilisez Dev Drive et testez si la pénalité frontière diminue suffisamment. Ne présumez pas ; mesurez.

7) « Dev Drive s’est rempli instantanément. »

Symptôme : Vous perdez des dizaines de Go en une semaine.

Cause racine : Les caches de build et répertoires d’artefacts grossissent sans nettoyage ; couches de conteneurs et caches d’outils s’accumulent.

Correction : Définissez des politiques de rétention des caches. Ajoutez des scripts de nettoyage planifiés pour les sorties de build. Agrandissez le volume si vous générez légitimement de gros outputs.

Trois mini-récits d’entreprise depuis le terrain

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

Une organisation d’ingénierie de taille moyenne a déployé « Dev Drive pour tout le monde » après qu’une équipe ait constaté des builds .NET plus rapides. L’IT a créé une image standard et un script qui déplaçaient les espaces de travail vers D:\ (ReFS) par défaut. Ça paraissait propre. Ça a aussi cassé quelques semaines plus tard d’une façon qui semblait surnaturelle.

Le symptôme n’était pas « build plus lent ». C’était « builds qui échouent aléatoirement sur de nouvelles machines ». Les erreurs étaient inconsistantes : certains devs voyaient des fichiers manquants, d’autres des échecs ressemblant à des permissions dans des outils qui n’avaient jamais tenu compte des permissions. Le fil commun était les opérations Git et un générateur de code legacy qui stockait son état dans un chemin dérivé du profil utilisateur.

L’hypothèse erronée : « Si ça marche sur ma machine, ça marche pour la flotte. » La machine pilote avait des paramètres de politique différents et une version de toolchain différente. Le générateur supposait pouvoir créer un certain type de lien et s’appuyait sur un comportement NTFS utilisé en catimini pendant des années. Sur ReFS, il ne plantait pas systématiquement. Il plantait quand il rencontrait une forme de chemin spécifique et un ensemble particulier d’opérations concurrentes.

La correction fut ennuyeuse : ils ont scindé la charge. Le code source et les intermédiaires sont allés sur Dev Drive, mais le répertoire d’état du générateur est resté sur un petit emplacement NTFS, et un test de compatibilité a été ajouté à l’onboarding. Ils ont aussi appris à versionner le déploiement : « Dev Drive activé » est devenu un feature flag avec plan de rollback, pas une voie sans retour.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre équipe d’entreprise est devenue ambitieuse. Ils ont lu que le scanning antivirus peut martyriser les builds, alors ils ont poussé une politique : exclure tout le Dev Drive du scan. Pas « mode performance ». Exclusion totale. Ils se sont justifiés en disant que le disque ne contenait que du « code de confiance ».

Deux mois plus tard, un dev a tiré une dépendance qui a été ensuite signalée comme malveillante en amont. Ce n’était pas un chamboulement cinématographique. Pas de rançon. Juste un payload méchant qui a tenté de persister et d’exfiltrer des tokens des outils dev locaux. La seule raison pour laquelle ça n’a pas empiré, c’est que des contrôles réseau sortants ont détecté un domaine suspect et l’ont bloqué.

Le post-mortem fut direct : ils avaient optimisé au détriment d’un contrôle de sécurité critique parce qu’ils voyaient Defender comme « une lenteur de build », pas comme une partie du modèle de menace. Le problème plus profond était culturel : performance et sécurité ne négociaient pas ; elles se battaient.

L’approche corrigée a utilisé le modèle prévu par Dev Drive : garder le scan activé, mais ajusté pour les répertoires développeur, et s’appuyer sur des contrôles aux frontières (téléchargements, exécutions, réputation, scans périodiques) plutôt que scanner chaque ouverture de fichier dans un arbre hot. Ils ont aussi commencé à pinner et vérifier les dépendances plus rigoureusement. La performance est revenue, et l’équipe sécurité a arrêté de brandir ses couteaux.

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

Une petite équipe plateforme supportait un monorepo utilisé par plusieurs groupes produits. Les builds étaient lents, et chacun avait une théorie : « c’est l’IDE », « c’est le réseau », « c’est le nouveau compilateur », « c’est Windows qui fait Windows ». Plutôt que de choisir un coupable, l’équipe a créé un script de benchmark standard et l’a rendu obligatoire pour toute réclamation de performance.

Ils ont mesuré trois phases séparément : checkout, restauration de dépendances, et build. Ils ont capturé les compteurs de latence disque, les processus I/O en tête, et l’utilisation CPU. Puis ils ont répété la même exécution sur NTFS et sur Dev Drive, après un reboot, avec le même commit, et avec les tâches en arrière-plan mises en pause quand possible.

Les résultats n’étaient pas spectaculaires partout. Certains langages voyaient peu de changement. Mais deux workflows — projets TypeScript avec d’énormes node_modules et un système de build C++ générant des océans d’intermédiaires minuscules — se sont améliorés de façon constante. Pas une vitesse infinie, mais des minutes réelles gagnées par itération.

Parce qu’ils disposaient de données de base, le déploiement fut chirurgical : seules les équipes dont le profil I/O correspondait furent recommandées d’adopter Dev Drive. Ils ont évité un mandat « tout le monde doit » à l’échelle de la flotte, et avaient des preuves quand la direction a demandé pourquoi les travaux de performance n’étaient pas uniformes. La pratique ennuyeuse fut la discipline de mesure, et elle a évité du temps perdu et des toolchains cassés.

Checklists / plan pas à pas

Plan pas à pas : adopter Dev Drive sans créer un désordre

1. Classifiez votre charge : La douleur est-elle dans le checkout/restore/indexation (E/S) ou compilation/link/test (CPU) ? Mesurez une exécution représentative.
2. Choisissez le placement : Mettez Dev Drive sur le NVMe local le plus rapide. Si vous n’avez qu’un disque, c’est toujours acceptable — allouez de manière responsable.
3. Choisissez un format :
   • Utilisez une partition dédiée si c’est votre espace de travail quotidien principal.
   • Utilisez un VHDX si vous voulez la portabilité et la facilité de « wipe and recreate ».
4. Déplacez uniquement ce qui en bénéficie : repos, caches de paquets (parfois), outputs de build. Gardez les téléchargements aléatoires et données personnelles ailleurs.
5. Validez la compatibilité des outils : exécutez la chaîne complète : build, test, packaging, signature, debug et exécution.
6. Surveillez le comportement de Defender : confirmez que vous n’avez pas désactivé des protections que la sécurité n’acceptera pas.
7. Benchmark A/B : même commit, mêmes étapes, mêmes conditions, exécutions multiples. Conservez les données.
8. Standardisez : documentez où vont les repos, où vont les caches, et comment nettoyer.
9. Opérationnalisez le nettoyage : suppression périodique des intermédiaires et caches obsolètes, particulièrement pour les monorepos et environnements multi-SDK.
10. Créez un plan de rollback : si une équipe rencontre un problème de compatibilité, elle doit avoir une méthode documentée pour revenir sur NTFS sans perdre une semaine.

Liste Do / Don’t (parce que vous serez tenté)

• Do : mettez les répertoires à fort turnover sur Dev Drive (outputs de build, arbres de dépendances qui explosent en nombreux petits fichiers).
• Do : conservez au moins 15–20% d’espace libre sur le volume Dev Drive.
• Do : capturez les compteurs et l’I/O des processus pendant les runs lents.
• Don’t : excluez intégralement le Dev Drive du scan de sécurité sans modèle de menace et approbations.
• Don’t : supposez que VHDX signifie « performance gratuite ». C’est une couche supplémentaire et peut amplifier la contention si le disque hôte est occupé.
• Don’t : déployez à l’échelle de la flotte sans un pilote de compatibilité qui reflète de vrais toolchains, pas seulement celui d’une équipe.

FAQ

1) Dev Drive est-il réservé à Visual Studio ?

Non. Il s’agit du comportement du système de fichiers et de la sécurité sous des E/S de type dev. Visual Studio en bénéficie, mais aussi les opérations Git, les écosystèmes Node/Java, CMake/Ninja, et autres workflows « beaucoup de petits fichiers ».

2) Dois-je utiliser Dev Drive pour des projets WSL2 ?

Ça dépend d’où résident les fichiers. Si vous buildz dans WSL sur des systèmes de fichiers natifs Linux, Dev Drive est irrélevant. Si vous buildz contre des chemins montés depuis Windows, Dev Drive peut aider, mais la pénalité de frontière peut toujours dominer.

3) Dev Drive va-t-il user mon SSD plus rapidement ?

Les builds écrivent déjà beaucoup. Dev Drive en soi n’est pas un « multiplicateur d’usure », mais des builds plus rapides peuvent vous inciter à en lancer davantage, ce qui augmente les écritures. Le contrôle pratique est le nettoyage et la limitation des rebuilds inutiles.

4) Puis-je stocker des caches de paquets sur Dev Drive ?

Souvent oui, et cela peut aider. Mais les caches sont aussi une frontière de sécurité. Si votre organisation audite les caches ou s’appuie sur leur scan, coordonnez-vous avec la sécurité avant de les déplacer.

5) Pourquoi ne pas simplement ajouter des exclusions Defender et garder NTFS ?

Parce que les « exclusions » sont un outil grossier et fréquemment surutilisé. Dev Drive vise une posture de performance plus sûre et structurée. De plus, ReFS peut améliorer le comportement sur les métadonnées même quand le scan n’est pas le seul coût.

6) ReFS est-il fiable pour des machines développeur ?

Il est largement utilisé en contexte serveur, et Dev Drive est une fonctionnalité client ciblée. Mais « fiable » signifie aussi « compatible avec vos outils et workflows de sauvegarde ». Testez la restauration et la récupération, pas seulement la performance.

7) Quel est le signe le plus clair que Dev Drive m’aidera ?

Vos étapes lentes sont dominées par l’énumération de fichiers et de nombreuses lectures/écritures de petits fichiers, et vous voyez Defender (ou d’autres drivers de filtre) effectuer beaucoup d’I/O pendant ces étapes.

8) Et si ma politique d’entreprise bloque Dev Drive ou ReFS ?

Traitez cela comme tout autre changement d’ingénierie : constituez un petit dossier étayé par des preuves. Montrez les timings A/B, montrez quelle phase s’améliore, et proposez un déploiement contraint avec des garde-fous.

9) Dois-je mettre tout mon monorepo sur Dev Drive ?

Généralement oui, si le monorepo est la source de l’explosion du nombre de fichiers. Mais séparez les composants legacy qui cassent sur ReFS. Le placement mixte est autorisé ; le dogme est optionnel.

10) Comment savoir si j’ai choisi la mauvaise approche (partition vs VHDX) ?

Si vous avez besoin de portabilité, d’environnements isolés multiples ou d’un reset rapide, VHDX est votre ami. Si vous visez la prévisibilité absolue et la simplicité, une partition dédiée l’emporte. Choisissez selon l’opérationnel, pas l’esthétique.

Prochaines étapes (pratiques, pas aspirationnelles)

Voici ce que je ferais ensuite si je gérais la performance de build sur une équipe Windows-intensive :

1. Choisissez un repo représentatif qui fait le plus mal et définissez un benchmark répétable : checkout, restore, build, test.
2. Exécutez la feuille de diagnostic rapide et classez le goulot. Si vous n’êtes pas lié par l’E/S, arrêtez de chasser les réglages de stockage.
3. Montez un Dev Drive sur le NVMe local le plus rapide (partition ou VHDX), déplacez le repo, et relancez le benchmark en conditions contrôlées.
4. Surveillez l’I/O du processus Defender pendant l’exécution. S’il est en tête, Dev Drive a probablement un effet ; sinon, creusez plus loin.
5. Documentez une disposition standard pour repos et outputs de build, plus un plan de nettoyage. La plupart des tickets « ma machine est lente » sont en réalité « mon disque est plein des artefacts d’hier ».
6. Déployez sélectivement aux charges qui correspondent au profil I/O. L’objectif est de réduire les heures développeur perdues, pas de mener une croisade filesystem.

Dev Drive est un bon outil. Ce n’est pas un miracle. Traitez‑le comme tout changement en production : mesurez, contraignez, validez, et gardez un plan de rollback. C’est ainsi que vous obtenez de la vitesse sans surprises — sur les postes développeur comme ailleurs.