Ouvre n’importe quel tuto Packer sur Windows et tu tomberas sur la même promesse : « une image parfaite en une commande, sans effort ». Tu copies le template, tu lances packer build, et tu déploies ta machine idéale.

Sauf que c’est faux. Enfin, pas tout à fait. La commande existe, le résultat est réel, mais entre les deux il y a une dizaine de pièges que personne ne te montre. Contrôleur disque invisible, balise obsolète qui fait tout planter, VM qui s’endort en plein build. J’ai tout traversé, en direct, sur ma machine. Cet article, c’est le tuto que j’aurais aimé lire avant de commencer.

L’objectif est simple : produire une golden image Windows 11 automatisée. Windows s’installe seul, le système passe en français, les VMware Tools et cinq applis se posent tout seuls, et à la fin tu récupères une image prête à cloner. Le tout sur VMware Workstation, en local, sans toucher la souris une seule fois une fois le build lancé.

Je te préviens tout de suite : ce n’est pas plug and play. Mais une fois les pièges désamorcés, ça tourne d’un bout à l’autre en 24 minutes. Et je te donne les vrais chiffres, y compris ceux qui font mal.

Packer, Chocolatey, Boxstarter : qui fait quoi

Avant de coder, il faut comprendre les trois briques, parce qu’elles n’ont rien à voir entre elles. On les empile, chacune a un rôle précis.

Packer, c’est l’orchestrateur du build. C’est lui qui crée la VM, monte l’ISO, la démarre, attend que Windows soit debout, se connecte, pousse les scripts, gère les reboots, puis exporte l’image. Il ne fait rien d’autre. Il fabrique le moule, une fois, et s’arrête.

Chocolatey, c’est le gestionnaire de paquets Windows. L’équivalent d’apt sur Debian ou de dnf sur Fedora, mais pour Windows. Une ligne, choco install firefox, et le soft est là, sans installeur à cliquer, sans « suivant, suivant, terminer ». C’est lui qui remplit le moule.

Boxstarter, c’est une surcouche de Chocolatey. Son intérêt unique : la résilience aux reboots. Il pose un autologon et reprend le script exactement là où il s’était arrêté après un redémarrage. Utile quand tu enchaînes des installs qui rebootent. On y reviendra, parce que dans un build Packer, il fait doublon, et c’est une nuance importante.

Packer contre Terraform : la confusion classique

Petite mise au point, parce que les deux sont des outils HashiCorp, écrits en HCL, et qu’on les confond tout le temps. Ce ne sont pas des concurrents. Ils font deux choses différentes, à deux moments différents.

Packer fabrique des images. Il produit un artefact figé, immuable : une image de VM, un template, une AMI sur AWS. Il construit, il exporte, il s’arrête. Il ne sait pas ce que devient l’image après, et il s’en moque.

Terraform déploie et gère l’infrastructure. Il est déclaratif, il tient un état (le fameux state), il crée, modifie et détruit des ressources vivantes : des VM, des réseaux, des ressources cloud. Il gère tout le cycle de vie.

En clair : Packer fabrique le moule, Terraform coule le béton dedans et gère les bâtiments. Le combo classique en prod, c’est Packer qui produit la golden image, puis Terraform qui déploie cinquante instances de cette image. L’un ne remplace pas l’autre, ils se passent le relais.

Pour cette démo, on reste sur Packer seul. On fabrique le moule.

I. Installer Packer sur l’hôte, pas dans la VM

Première confusion à évacuer : Packer s’installe sur la machine hôte, celle qui fait tourner VMware Workstation. Pas dans la VM. La VM n’existe même pas encore quand tu lances le build, c’est Packer qui la crée.

Sur mon poste, winget fait le job en trente secondes.

[CODE : install-packer.ps1]

powershell

winget install HashiCorp.Packer

Attention au piège le plus bête du monde : après l’install, le PATH n’est pas rechargé dans ta session en cours. Soit tu fermes et rouvres ton terminal, soit tu recharges à la volée.

[CODE : reload-path.ps1]

powershell

$env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path","User")
packer version

Chez moi, Packer v1.15.4. Note bien la version, parce que le plugin qui va avec est devenu beaucoup plus strict que les anciens, et ça va nous jouer des tours.

II. L’ISO Windows 11 : LTSC ou pas, la nuance qui compte

Pour la source, on part d’une ISO d’évaluation, gratuite et sans clé, depuis l’Evaluation Center Microsoft. Attention, le paysage a changé. La Windows 10 Enterprise classique a été retirée depuis la fin de support d’octobre 2025. Sur Windows 11, tu as le choix entre la Enterprise LTSC 2024 (build 26100) et la version standard.

Petite parenthèse vécue : j’ai cru télécharger la LTSC, et une fois la VM montée, j’ai vu le Microsoft Store et Outlook dans le menu Démarrer. Or la LTSC n’a ni l’un ni l’autre. J’avais en fait la Enterprise Evaluation standard, pas la LTSC. Pour le pipeline ça ne change rien, choco et Packer s’en fichent, mais c’est le genre de détail à vérifier avant de croire qu’on a la bonne édition.

L’eval demande un formulaire, donc pas de téléchargement direct. Packer ne peut pas la récupérer seul, on pointe un fichier local. Et on calcule son empreinte pour la vérification d’intégrité.

[CODE : hash-iso.ps1]

powershell

Get-FileHash "C:\demo\ISO\win11ent.iso" -Algorithm SHA256

III. Le template Packer, et le plugin qui ne pardonne rien

Le coeur du build, c’est le fichier .pkr.hcl. Il déclare la source (la VM à créer) et le build (les étapes de provisioning). Je te donne la version finale, celle qui marche, après avoir mangé toutes les erreurs.

Premier piège, et il est de taille. Le plugin github.com/vmware/vmware en version 2.1.3 est beaucoup plus strict que les versions d’avant. Il ne devine plus rien. Deux paramètres que les anciens plugins déduisaient tout seuls sont désormais obligatoires : network_adapter_type et disk_adapter_type. Il y en a un troisième, tools_mode, mais celui-là ne devient obligatoire que si tu touches à la config d’upload des VMware Tools, ce qu’on évite ici en les installant par choco (j’y reviens en partie VI). Si tu copies un template d’un vieux tuto, il casse à la validation. Tu vas te manger des X is required en série. On met donc les deux paramètres requis d’entrée.

[CODE : windows11.pkr.hcl (extrait source)]

hcl

source "vmware-iso" "win11" {
  vm_name       = "win11-ltsc-demo"
  guest_os_type = "windows11-64"

  iso_url      = var.iso_path
  iso_checksum = var.iso_checksum

  cpus      = 4
  memory    = 8192
  disk_size = 40960

  disk_adapter_type    = "sata"
  cdrom_adapter_type   = "sata"
  network_adapter_type = "e1000e"

  vmx_data = {
    "firmware"                = "efi"
    "uefi.secureBoot.enabled" = "FALSE"
    "vtpm.present"            = "FALSE"
  }

  cd_files = ["./autounattend.xml"]
  cd_label = "PROVISION"

  boot_wait    = "3s"
  boot_command = ["<enter>"]

  communicator   = "winrm"
  winrm_username = "packer"
  winrm_password = "packer"
  winrm_timeout  = "2h"
}

Deux choix à expliquer, parce qu’ils m’ont coûté du temps.

disk_adapter_type = "sata". C’est le piège numéro un. Sans cette ligne, la VM démarre, l’install Windows se lance, et tu arrives sur l’écran de sélection du disque avec une liste vide. Aucun disque. Le disque existe, Packer l’a créé, mais il est branché sur le contrôleur par défaut du builder, du LSI Logic, dont l’ISO Windows 11 n’a pas le pilote natif. Windows ne le voit pas. En SATA (AHCI), il est reconnu out of the box, sans charger de driver.

network_adapter_type = "e1000e". Même logique. L’ISO Windows 11 n’embarque pas le driver VMXNET3. Si tu prends vmxnet3, la carte réseau n’est pas reconnue pendant l’install, et sans réseau, pas de WinRM. Le e1000e est reconnu nativement.

Une fois le template en place, on initialise le plugin.

[CODE : packer-init.ps1]

powershell

packer init windows11.pkr.hcl

IV. L’autounattend, et la balise qui tue tout le fichier

L’autounattend.xml, c’est le fichier de réponses qui rend l’install de Windows silencieuse. Il partitionne le disque, crée le compte, contourne les vérifications matérielles de Windows 11 et active WinRM. Packer le monte dans un petit CD que Windows détecte tout seul.

Le contournement TPM et Secure Boot se fait en dur, via des clés de registre LabConfig écrites pendant la phase WinPE. C’est ce qui évite d’avoir à configurer un vTPM chiffré dans VMware, une vraie galère.

[CODE : autounattend.xml (extrait bypass)]

xml

<RunSynchronous>
  <RunSynchronousCommand wcm:action="add">
    <Order>1</Order>
    <Path>reg add "HKLM\System\Setup\LabConfig" /v BypassTPMCheck /t REG_DWORD /d 1 /f</Path>
  </RunSynchronousCommand>
  <!-- idem pour BypassSecureBootCheck, BypassRAMCheck, BypassCPUCheck, BypassStorageCheck -->
</RunSynchronous>

Et voilà le piège numéro deux, un des plus vicieux. Sur mon premier build correct, l’install s’est déroulée, puis au premier reboot, écran bleu d’erreur : « The computer restarted unexpectedly ». Plantage en phase specialize.

La cause était planquée dans C:\Windows\Panther\setuperr.log, qu’on lit avec un Shift+F10 dans la VM. Une ligne : The provided unattend file is not valid sur le composant CEIPEnabled. Cette balise a été supprimée de Windows 11 24H2. Elle n’existe plus. Et le setup, au lieu de l’ignorer, rejette tout le fichier autounattend à cause de cette seule ligne obsolète.

Le truc à retenir : une seule balise obsolète invalide l’autounattend entier. Si ton install plante en specialize, lis setuperr.log, il te donne le nom exact du composant fautif. On retire la ligne, et ça repart.

V. Valider puis lancer le build

Avant de lancer un build qui va tourner vingt minutes, on valide. packer validate attrape les erreurs de syntaxe et les paramètres manquants en deux secondes, ça évite de découvrir un X is required après dix minutes d’install Windows.

[CODE : packer-validate.ps1]

powershell

packer validate .\windows11.pkr.hcl

Tu veux lire The configuration is valid.. Si le plugin râle sur un champ obligatoire, tu corriges et tu revalides jusqu’à ce que ce soit propre.

Ensuite seulement, le build.

[CODE : packer-build.ps1]

powershell

packer build .\windows11.pkr.hcl

À partir de là, une fenêtre VMware Workstation s’ouvre, la VM boote sur l’ISO, et tout s’enchaîne sans que tu touches à rien. Surveille juste les premières secondes, le prompt « Press any key to boot from CD » où Packer envoie le <enter>. Si la VM le rate et part dans un shell EFI, augmente boot_wait et relance. C’est le réglage le plus capricieux du pipeline.

VI. Le DHCP absent, le décrochage WinRM et l’APIPA

Une fois Windows installé, Packer attend WinRM pour se connecter. Sur un de mes runs, il est resté bloqué sur Waiting for WinRM to become available sans fin, sans message d’erreur. Le genre de blocage silencieux qui te fait perdre une heure.

WinRM tournait pourtant dans la VM, le port 5985 répondait en local. Mais depuis l’hôte, rien. La cause : la VM avait une adresse en 169.254.x.x. Du APIPA. Autrement dit, elle n’avait pas reçu de bail DHCP, parce que le service DHCP de VMware était désactivé sur mon poste. Sans IP routable, Packer ne peut pas la joindre.

La réactivation du service DHCP côté hôte règle le problème.

[CODE : fix-dhcp.ps1]

powershell

Start-Service VMnetDHCP
Set-Service VMnetDHCP -StartupType Automatic

Note bien ce piège : un Waiting for WinRM qui ne finit jamais, ce n’est presque jamais WinRM. C’est le réseau. Vérifie l’IP de la VM en premier. Et méfie-toi du ping : le pare-feu Windows bloque l’ICMP par défaut, donc un ping qui échoue ne prouve rien. Le vrai test, c’est le port, avec Test-NetConnection -Port 5985.

VII. Les provisioners : Tools, langue, applis, et les reboots

On arrive au coeur du build. Le bloc build enchaîne les scripts PowerShell, avec des reboots entre les étapes sensibles. Et non, ces reboots ne sont pas gérés par Boxstarter, mais par le provisioner natif windows-restart de Packer. J’y reviens juste après, c’est important.

[CODE : windows11.pkr.hcl (extrait build)]

hcl

build {
  sources = ["source.vmware-iso.win11"]

  provisioner "powershell" {
    scripts          = ["./scripts/install-vmware-tools.ps1"]
    valid_exit_codes = [0, 3010]
  }
  provisioner "windows-restart" {}

  provisioner "powershell" {
    scripts = ["./scripts/setup-language-french.ps1"]
  }
  provisioner "windows-restart" {}

  provisioner "powershell" {
    scripts = ["./scripts/install-choco-packages.ps1"]
  }
}

Les VMware Tools : oublie l’upload WinRM, passe par choco

Première approche, j’ai voulu faire uploader l’ISO des Tools par Packer, via l’option tools_upload. Mauvaise idée. L’upload de fichiers par WinRM est lent et fragile. Sur une ISO de 130 Mo, il a bloqué complètement, rien n’atterrissait dans la VM, dix minutes pour zéro octet écrit.

La parade est plus simple et plus reproductible : installer les Tools par Chocolatey. Le package existe, il télécharge depuis le dépôt Broadcom, pas de gros transfert WinRM, pas de dépendance au chemin de ton install Workstation.

[CODE : install-vmware-tools.ps1 (extrait)]

powershell

choco install vmware-tools -y --no-progress

Le truc à retenir : pour tout artefact un peu lourd, le gestionnaire de paquets bat l’upload WinRM. C’est plus robuste, point.

Le code 3010 : un succès pris pour une erreur

Piège suivant, et c’est un classique Windows. Les VMware Tools s’installent nickel, mais choco retourne le code de sortie 3010. Ce code veut dire « succès, reboot nécessaire ». Or Packer considère par défaut que seul le code 0 est acceptable. Il prend donc ce 3010 pour un échec et coupe le build.

D’où le valid_exit_codes = [0, 3010] sur ce provisioner. On dit à Packer que 3010 est un succès valide. Ce code sort tout le temps avec les MSI et les features Windows, à connaître par coeur.

La bascule en français, et la leçon la plus chère

Mon idée de départ : installer trois packs de langue, allemand, espagnol et français, puis passer le système en français. Bien pour le spectacle. Sauf que le spectacle m’a coûté des heures.

Install-Language tire chaque pack depuis Windows Update, plusieurs centaines de Mo, plus les Features on Demand (reconnaissance vocale, écriture manuscrite, OCR). Et ces FODs déclenchent en cascade une maintenance des composants Windows via TrustedInstaller qui ne finit jamais dans un délai raisonnable. Sur une image eval fraîche, j’ai vu TrustedInstaller à plus de 13000 secondes de CPU, bloqué sur le deuxième pack après 30 minutes.

La correction, et c’est aussi la bonne pratique pour une vraie golden image : une seule langue, le français, et sans les FODs lourds.

[CODE : setup-language-french.ps1 (extrait)]

powershell

# -ExcludeFeatures evite les FODs (Speech, OCR, Handwriting)
# qui saturent TrustedInstaller pendant des heures.
Install-Language fr-FR -CopyToSettings -ExcludeFeatures

Set-WinUserLanguageList -LanguageList fr-FR -Force
Set-WinUILanguageOverride -Language fr-FR
Set-WinSystemLocale fr-FR
Set-SystemPreferredUILanguage fr-FR
Copy-UserInternationalSettingsToSystem -WelcomeScreen $true -NewUser $true

Le truc à retenir : ajouter des langues avec tous les FODs, c’est le meilleur moyen de rendre ton build ininstallable. Une langue, -ExcludeFeatures, sauf besoin explicite d’OCR ou de reconnaissance vocale.

Le piège dans le piège : la VM qui s’endort

Et le plus vicieux pour la fin, celui que personne ne documente. Même avec -ExcludeFeatures, mon build a décroché à 43 minutes, en plein Install-Language, avec une erreur réseau brute : wsarecv: the connected host has failed to respond. WinRM coupé net.

J’ai cru à un problème de pile réseau. Faux. La vraie cause : la VM se mettait en veille. Pendant qu’Install-Language mouline en silence, sans activité clavier ni souris, Windows applique son plan d’alimentation et met la machine en veille. Le réseau tombe, Packer perd WinRM, le build meurt.

La parade, à mettre en tout premier dans le pipeline : désactiver la veille via powercfg.

[CODE : disable-sleep.ps1]

powershell

powercfg /change standby-timeout-ac 0
powercfg /change standby-timeout-dc 0
powercfg /change monitor-timeout-ac 0
powercfg /change hibernate-timeout-ac 0
powercfg /setactive SCHEME_MIN

C’est une ligne à mettre dans n’importe quel pipeline de golden image Windows. Un provisioner long sur une VM qui s’endort, ça décroche WinRM sans jamais te dire pourquoi. Note-le bien.

Les applis, et le checksum qui casse tout seul

Dernier provisioner, les cinq applis via choco. Au départ, ma liste incluait Google Chrome. Erreur. Le package Chrome sur Chocolatey embarque un checksum figé du MSI, mais Google écrase le même fichier à chaque nouvelle version. Résultat, dès que le package est en retard d’une release, le checksum ne correspond plus et l’install échoue : hashes do not match.

Pour un build reproductible, un paquet qui casse au gré des sorties de Google, c’est exactement ce qu’on ne veut pas. Je l’ai remplacé par Firefox, qui n’a pas ce souci. Et j’ai rendu le script tolérant : un paquet qui échoue est loggé, mais ne fait plus planter tout le build.

[CODE : install-choco-packages.ps1 (extrait)]

powershell

$packages = @("7zip","notepadplusplus","firefox","git","vscode")
$failed = @()
foreach ($pkg in $packages) {
    choco install $pkg -y --no-progress
    if ($LASTEXITCODE -ne 0 -and $LASTEXITCODE -ne 3010) {
        Write-Warning "Echec de $pkg (code $LASTEXITCODE)"
        $failed += $pkg
    }
}

VIII. Et Boxstarter dans tout ça ?

J’ai gardé Boxstarter pour la fin, parce que c’est la nuance la plus honnête de cet article. Mon idée initiale était d’utiliser Boxstarter pour gérer les reboots entre les étapes. Bonne intuition sur le papier, mais mauvaise dans un contexte Packer.

Boxstarter gère les reboots via un autologon et une reprise du script en session interactive. Packer, lui, pilote la VM en WinRM, session non interactive. Quand Boxstarter reboote, la connexion WinRM de Packer tombe, et Packer ne voit pas la reprise Boxstarter qui se joue dans la session autologon. Les deux ne se coordonnent pas.

En clair : dans un build Packer, l’outil pour les reboots, c’est windows-restart. Pas Boxstarter. Boxstarter brille quand tu provisionnes une machine en direct, hors Packer, par exemple un poste physique où tu veux enchaîner des installs qui rebootent et reprendre toutes seules.

C’est ça, la vraie leçon : deux outils qui semblent faire la même chose, mais chacun a son terrain. Je détaillerai le vrai cas d’usage de Boxstarter, packs de langue et reboots en cascade sur une machine directe, dans un article séparé. Il mérite sa propre démo.

Ce que je retiens

Le build final tourne d’un bout à l’autre sans intervention. Windows installé, VMware Tools, système en français, cinq applis, arrêt propre, image compactée. Voilà les chiffres, sans enjoliver.

Et la liste des pièges, parce que c’est ça le vrai contenu de ce tuto, pas le template :

• Le contrôleur disque en SATA, sinon Windows ne voit aucun disque.
• La balise CEIPEnabled obsolète en 24H2, qui invalide tout l’autounattend.
• Le DHCP VMware désactivé, qui envoie la VM en APIPA et bloque WinRM sans erreur claire.
• Le code 3010 à whitelister, un succès pris pour un échec.
• L’upload WinRM d’ISO qui bloque, à remplacer par choco.
• Les FODs de langue qui saturent TrustedInstaller pendant des heures.
• La veille de la VM qui décroche WinRM en plein provisioner long.
• Le checksum Chrome volatil, à remplacer par Firefox.
• oscdimg de l’ADK à mettre dans le PATH de façon permanente, sinon chaque console casse le build sur la création du CD.

Alors, est-ce que Packer vaut le coup pour une golden image Windows ? Oui, sans hésiter. Une fois le template stabilisé, tu reconstruis ton image parfaite en une commande, à l’identique, autant de fois que tu veux. C’est reproductible, c’est versionnable, c’est du vrai infrastructure as code.

Mais le template propre que tu copies en trois minutes, il cache une journée de pièges que personne ne documente. La reproductibilité se paie une fois, à la mise au point. Après, elle est gratuite. Comme souvent, la vraie valeur n’est pas dans la commande magique, elle est dans tout ce qu’on ne te montre pas.

A bientôt Louis 🐇 🤜 🤛 🐰

Introduction

Noël est passé, le papier cadeau est à la poubelle, et pour les plus chanceux d’entre vous, une boîte verte et noire trône désormais dans le PC. Peut-être que le Père Noël a été d’une générosité indécente avec une RTX 4090 ou la mythique RTX 5090 :OOO. D’autres, plus raisonnables (ou comme moi, avec un budget d’ingénieur réaliste), ont déballé une 5070 Ti 16 Go.

C’est une belle pièce de silicium, mais j’ai une mauvaise nouvelle si vous êtes sous Windows : vous l’utilisez mal.

En plus, soyons honnêtes un instant : Windows 11, c’est un peu le Windows Millennium des années 2025 (les « vieux cons » comme moi comprendront la douleur de cette référence).

Dans le monde de l’infrastructure IA locale, avoir du hardware, c’est bien. Savoir l’optimiser, c’est mieux. La majorité des utilisateurs « gâchent » une quantité astronomique de VRAM (Video RAM) simplement pour afficher leur fond d’écran. Dans cette série d’articles, dont voici la Partie 1, nous allons voir comment récupérer cette mémoire précieuse pour ce qui compte vraiment : l’entraînement et l’inférence de vos modèles, et non l’affichage de l’interface de cet OS capricieux.

1. Analyse Technique : La « Taxe d’Affichage » Windows

Pourquoi cette optimisation est-elle critique ? Parce que la VRAM est une ressource finie et non extensible. Contrairement à la RAM système où l’on peut rajouter une barrette (de toute façon vu le prix c’est mort :D), votre RTX 5070 Ti restera bloquée à 16 Go.

Dès que vous branchez un câble HDMI sur votre GPU dédié (dGPU), le sous-système graphique de Windows (WDDM – Windows Display Driver Model) s’approprie une partie de la mémoire pour gérer le DWM (Desktop Window Manager).

Le constat est technique et douloureux : Regardez cette capture d’une RTX 5070 Ti au repos, simplement connectée à un écran sous Windows.

• Idle Consumption : Comme vous le voyez ci-dessus, Windows vampirise ici 1,6 Go juste pour exister.
• Impact IA : Sur un LLM, ces 1,6 Go sont la différence entre charger un modèle 13B ou crasher avec une erreur CUDA out of memory.
• Spillover : Quand la VRAM est pleine, le système déborde sur la RAM classique. On passe d’une bande passante de ~1000 Go/s à ~60 Go/s. C’est la mort des performances.

2. Impacts sur l’Infrastructure Physique (Layer 1)

L’optimisation commence par le câblage. L’objectif est de séparer les rôles : le Control Plane (Affichage OS) et le Data Plane (Calcul IA).

La stratégie du « Headless Hybride »

C’est quelque chose qui paraît logique, mais que peu de monde fait : débrancher la carte vidéo du moniteur. L’idée est d’utiliser l’iGPU (la puce graphique intégrée à votre processeur Intel ou AMD Ryzen) pour gérer l’affichage de Windows. Ainsi, votre monstre de puissance (la RTX) reste « Headless » (sans tête), 100% disponible pour PyTorch ou TensorFlow.

La gestion du flux vidéo

On ne va pas passer notre vie à quatre pattes sous le bureau pour débrancher le HDMI. La solution infra pragmatique, c’est le Switch HDMI ou le KVM.

ce type de modèle se trouve souvent dans les 20 euros

Le piège du simple débranchement

Une fois l’écran basculé sur la carte mère (iGPU) et la RTX physiquement « débranchée » (via le switch), on s’attend à récupérer 100% de la VRAM. Erreur.

Regardez ce qu’il se passe quand on coupe juste l’affichage :

On voit bien qu’il reste 0,5 Go de mémoire fantôme utilisée. Windows garde la carte « prête à dégainer » et certains processus d’arrière-plan (Nvidia Container, etc.) squattent toujours la mémoire. C’est là que l’automatisation logicielle devient indispensable pour aller chercher les derniers méga-octets.

3. Recommandations : Automatisation et Scripting

Une fois le câble géré, il faut nettoyer la couche logicielle. Même sans écran, certains processus continuent d’allouer de la mémoire. Pour éviter de modifier le BIOS à chaque fois, j’ai développé une solution d’automatisation.

Le Script PowerShell de Bascule (Switch)

Voici le code pour votre boîte à outils SysAdmin. Il modifie le registre pour le Hardware Scheduling et désactive/active le périphérique via pnputil.

Fichier : GPU_Switch.ps1

Clear-Host
Write-Host "=== RTX 30/40/50XX Headless Switch (IA/Gaming) ===" -ForegroundColor Green
Write-Host "1: Headless ON (AI optimized - iGPU)" -ForegroundColor Cyan
Write-Host "2: Headless OFF (Gaming RTX)" -ForegroundColor Yellow
$choice = Read-Host "Choix (1/2)"

if ($choice -eq "1") {
    Write-Host "→ Headless IA ON..." -ForegroundColor Green
    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" -Name "HwSchMode" -Value 2
    pnputil /disable-device "PCI\VEN_10DE*DEV_*" | Out-Null
    Write-Host "Reboot en 5s... (VRAM 100% IA après)" -ForegroundColor Green
    Start-Sleep 5; Restart-Computer -Force
}
elseif ($choice -eq "2") {
    Write-Host "→ Gaming RTX ON..." -ForegroundColor Yellow
    pnputil /enable-device "PCI\VEN_10DE*DEV_*" | Out-Null
    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" -Name "HwSchMode" -Value 1
    Write-Host "Reboot en 5s... (RTX display after)" -ForegroundColor Yellow
    Start-Sleep 5; Restart-Computer -Force
} else {
    Write-Host "Invalid choice!" -ForegroundColor Red; Start-Sleep 2; & $MyInvocation.MyCommand.Path
}

Clear-Host
Write-Host "=== RTX 30/40/50XX Headless Switch (IA/Gaming) ===" -ForegroundColor Green
Write-Host "1: Headless ON (AI optimized - iGPU)" -ForegroundColor Cyan
Write-Host "2: Headless OFF (Gaming RTX)" -ForegroundColor Yellow
$choice = Read-Host "Choix (1/2)"

if ($choice -eq "1") {
    Write-Host "→ Headless IA ON..." -ForegroundColor Green
    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" -Name "HwSchMode" -Value 2
    pnputil /disable-device "PCI\VEN_10DE*DEV_*" | Out-Null
    Write-Host "Reboot en 5s... (VRAM 100% IA après)" -ForegroundColor Green
    Start-Sleep 5; Restart-Computer -Force
}
elseif ($choice -eq "2") {
    Write-Host "→ Gaming RTX ON..." -ForegroundColor Yellow
    pnputil /enable-device "PCI\VEN_10DE*DEV_*" | Out-Null
    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" -Name "HwSchMode" -Value 1
    Write-Host "Reboot en 5s... (RTX display after)" -ForegroundColor Yellow
    Start-Sleep 5; Restart-Computer -Force
} else {
    Write-Host "Invalid choice!" -ForegroundColor Red; Start-Sleep 2; & $MyInvocation.MyCommand.Path
}

Et j’exécute le script powershell avec un batch ou j’ai mis le raccourci sur le bureau à exécuter en administrateur :

Fichier : GPU_Switch.bat

@echo off
powershell -ExecutionPolicy Bypass -WindowStyle Maximized -File "%~dp0GPU_Switch.ps1"
pause

@echo off
powershell -ExecutionPolicy Bypass -WindowStyle Maximized -File "%~dp0GPU_Switch.ps1"
pause

Le Résultat Final

Une fois le mode « Headless » activé via le script et le câble basculé sur l’iGPU, voici l’état de la même carte RTX 5070 Ti :

Conclusion

Conclusion et Résultats : L’Efficacité au Service de la Performance

Après avoir mis en place ces optimisations et configuré l’environnement en mode « headless » avec les scripts appropriés, les résultats sont sans appel. Cette approche ne se contente pas de libérer de la ressource brute, elle transforme radicalement le workflow d’entraînement.

1. Un Gain de Temps Majeur

L’optimisation de la gestion des ressources a un impact direct sur la rapidité d’exécution. Sur un cycle d’entraînement lourd qui nécessitait auparavant 8 heures, le temps de traitement est descendu à 5 heures. Cette réduction de près de 40 % permet d’accélérer les itérations de recherche et de développement de manière significative.

2. Libération Totale de la VRAM

L’un des plus grands défis en scripting IA est de s’assurer que les ressources sont correctement restituées au système une fois la tâche terminée. Grâce au déchargement dynamique et à la suppression des processus graphiques inutiles, l’utilisation de la VRAM retombe pratiquement à 0 % (seulement 222 Mo utilisés sur 16 Go, soit 1,4 %) dès que l’entraînement s’arrête. Cela garantit que la carte est immédiatement prête pour une nouvelle tâche sans nécessiter de redémarrage ou de nettoyage manuel des processus « zombies ».

3. Sobriété Énergétique

Enfin, la gestion thermique et électrique est optimisée. En mode veille (idle), une fois les scripts terminés, la consommation de la carte tombe sous la barre des 24W. Pour une carte de cette puissance (capable de monter jusqu’à 300W), ce niveau de consommation est extrêmement raisonnable, permettant de laisser le serveur tourner H24 sans impact écologique ou financier démesuré.

En maîtrisant ainsi votre VRAM et vos scripts de déchargement, vous ne maximisez pas seulement la puissance de votre GPU : vous optimisez sa durée de vie et votre propre productivité.