Accélérer la validation des applications avec Windows Sandbox

Dans le développement d’applications Windows, les raisons pour lesquelles la validation ralentit sont à peu près toujours les mêmes.

• La machine de développement locale est « sale », si bien que les problèmes de première installation ne se reproduisent pas
• Le problème survient chez le client mais pas sur votre propre PC
• « Ça marche si on l’exécute en administrateur », mais la frontière de privilèges réellement nécessaire reste invisible
• On veut tester le comportement en cas de privilèges ou de dépendances manquants, mais on ne veut pas casser son environnement de tous les jours
• L’application plante en faible mémoire ou sans GPU, mais ce n’est pas grand-chose au point de justifier de monter une VM complète à chaque fois

Dans ce genre de situations, Windows Sandbox est un outil remarquablement pratique.

Il est plus léger qu’une VM complète, démarre rapidement, et repart de zéro à chaque fermeture — ce qui correspond bien à l’exigence : « je veux pouvoir recréer en quelques minutes un environnement de validation propre, sur la même build Windows ».

Cela dit, si on se contente d’ouvrir un Sandbox vierge à chaque fois sans aucune organisation, le gain d’efficacité reste limité. Ce qui paie vraiment en pratique, c’est le fonctionnement suivant : fixer un fichier .wsb par scénario de validation, séparer un dossier d’entrée en lecture seule d’un dossier de collecte en écriture seule, et alterner entre profils administrateur, utilisateur standard et environnement restreint.

Cet article organise cette approche du point de vue du développement d’applications Windows. Le contenu se fonde sur les informations officielles de Microsoft vérifiables en avril 2026.

D’abord la conclusion

Voici les conclusions, posées d’emblée.

• Windows Sandbox est adapté pour reproduire un environnement propre, vérifier une première installation, isoler les problèmes de privilèges administrateur et mettre en évidence des dépendances manquantes.
• Plutôt que de tout refaire manuellement dans l’interface graphique à chaque fois, séparer les fichiers .wsb par cas d’usage est plus rapide.
• Pour le partage avec l’hôte, séparer les entrées en read-only et ne mettre en read-write que les sorties réduit les incidents.
• La session Sandbox par défaut est difficile à utiliser telle quelle pour une validation en utilisateur standard. Si l’on veut une validation en utilisateur standard, il faut créer un autre utilisateur dans le Sandbox et démarrer avec cet utilisateur.
• Pour reproduire un manque de mémoire ou l’absence de GPU, les paramètres .wsb MemoryInMB et la désactivation de VGpu / du vGPU sont efficaces.
• En revanche, si l’on veut aussi aller jusqu’aux quotas CPU, à la saturation disque, à plusieurs instances simultanées ou à la reproduction d’une autre version d’OS, une VM complète est plus adaptée que Windows Sandbox.

En résumé, Windows Sandbox est un environnement de validation « léger mais jetable », « rapide mais limité à la même famille d’OS », « restreint mais suffisamment efficace en pratique ». Comprendre ce positionnement dès le départ évite de se tromper d’usage.

Pourquoi Windows Sandbox se marie bien avec la validation en développement

Il y a quatre raisons pour lesquelles Windows Sandbox se marie bien avec le développement d’applications Windows.

Fermer le Sandbox réinitialise tout, à chaque fois

C’est le point le plus important.

Essayer un installeur à répétition, casser des réglages, toucher au registre, ajouter et retirer des prérequis : faire cela sur sa propre machine de développement finit par produire « un environnement dont on ne sait plus ce qu’il contient ».

Avec le Sandbox, tout disparaît à la fermeture. Cela permet de repérer plus facilement les problèmes qui n’apparaissent qu’à la première installation et les problèmes masqués parce qu’un prérequis se trouvait par hasard déjà présent sur la machine.

On peut créer instantanément un environnement propre de la même famille Windows

Windows Sandbox part du principe qu’il utilise la même famille de build Windows que l’hôte. C’est une contrainte, mais vu autrement, cela signifie aussi qu’on peut créer instantanément un environnement propre de la même famille que son Windows 11 local.

Dans une situation du type « le client est sur Windows 11 24H2, et nous aussi », c’est très facile à exploiter.

Plus léger qu’une VM complète, avec un coût de gestion moindre

Les VM complètes sous Hyper-V ou VMware sont puissantes, mais si l’usage se limite à

• vérifier la procédure d’installation
• vérifier le comportement des invites UAC
• vérifier les erreurs en cas de privilèges manquants
• vérifier les journaux en cas de dépendances manquantes
• effectuer un smoke test dans un environnement propre

elles sont souvent un peu lourdes pour ça.

Windows Sandbox n’impose pas de gestion d’image OS ni de suivi de snapshots poussé, ce qui fait que sa force est de permettre de faire avancer une validation « je veux juste reproduire rapidement ».

Les scénarios peuvent être figés avec .wsb et la CLI

La vraie valeur du Sandbox n’est pas simplement de « pouvoir essayer en sécurité », mais de pouvoir recommencer autant de fois que nécessaire dans les mêmes conditions.

• Réseau activé / désactivé
• Dossiers partagés en read-only / read-write
• Faible mémoire
• Pas de partage GPU
• Pas de partage du presse-papiers
• Exécution d’un script spécifique au démarrage

En fixant ces réglages dans un fichier .wsb, ou via la CLI sur Windows 11 24H2 et ultérieur, la validation passe du statut de « bricolage ponctuel » à celui de « procédure reproductible ».

Les contraintes à connaître d’abord

C’est pratique, mais certains usages ne conviennent pas. Mieux vaut le savoir dès le départ.

Des restrictions d’édition s’appliquent

Windows Sandbox fonctionne sous Windows Pro / Enterprise / Education. Il n’est pas disponible sous l’édition Home.

Les machines de développement internes sont souvent en Pro, mais les postes commerciaux ou les PC personnels sont parfois en Home, ce qui peut coincer à ce niveau.

Il y a des prérequis de virtualisation

Son utilisation suppose que la fonctionnalité de virtualisation soit activée, et qu’une quantité minimale de RAM, d’espace disque et de cœurs CPU soit disponible. Léger, certes, mais pas totalement gratuit.

Le Sandbox utilise la même famille d’OS que l’hôte

C’est un point très important en pratique.

Windows Sandbox ne convient pas pour valider une autre version d’OS.

• Si l’hôte est sous Windows 11, il ne deviendra pas un environnement de reproduction de Windows 10
• Si le client utilise une build ancienne, cet écart ne peut pas être comblé

Donc, pour la validation de compatibilité entre versions d’OS ou les problèmes liés à une build ancienne, mieux vaut choisir une VM complète dès le départ.

On ne peut pas lancer plusieurs instances en même temps

À l’heure actuelle, Windows Sandbox ne convient pas à un usage nécessitant plusieurs instances simultanées.

Pour exécuter une matrice de tests en parallèle, Hyper-V ou équivalent est plus naturel.

Le réseau et le presse-papiers sont activés par défaut

C’est un point facile à négliger.

Windows Sandbox a la connexion réseau activée par défaut. Le partage du presse-papiers est également activé par défaut.

Autrement dit, si on le démarre sans y réfléchir, ce n’est pas un « monde totalement fermé ». Pour examiner un fichier suspect ou reproduire un manque de dépendances, il est plus sûr de contrôler ces réglages explicitement via .wsb dès le départ.

Sur Windows 11 24H2 et ultérieur, certaines applications inbox sont indisponibles

Dans le Sandbox sous Windows 11 24H2 et ultérieur, certaines applications Store inbox comme le Bloc-notes, le Terminal, la Calculatrice ou Photos sont indisponibles.

C’est pourquoi il est prudent de construire l’automatisation au démarrage et les opérations auxiliaires en s’appuyant sur cmd.exe, powershell.exe et explorer.exe.

Une arborescence de dossiers à préparer d’avance pour gagner du temps

Plutôt que de décider des dossiers partagés à chaque fois dans l’instant, préparer dès le départ un seul emplacement dédié à la validation simplifie beaucoup les choses.

Par exemple, une arborescence comme celle-ci.

C:\SandboxFixtures\
├─ AppUnderTest\
│  ├─ MyAppInstaller.msi
│  ├─ MyApp.exe
│  └─ sample-data\
├─ Scripts\
│  └─ Prep-StandardUser.ps1
├─ Outbox\
├─ 00-clean-smoke.wsb
├─ 10-standard-user.wsb
├─ 20-restricted-runtime.wsb
└─ 30-low-resource.wsb

Les rôles se répartissent ainsi.

• AppUnderTest : la cible de la validation. Partage read-only
• Scripts : les scripts de démarrage. Partage read-only
• Outbox : journaux, dumps, résultats exportés. Partage read-write

Avec cette répartition, le seul endroit où le Sandbox peut écrire vers l’hôte est Outbox, ce qui est plutôt sûr.

De plus, les fichiers .wsb sont également fixés par scénario.

Cela suffit déjà à réduire considérablement le coût de démarrage d’une validation.

Faire du smoke test en environnement propre un simple double-clic

La première chose à préparer est un Sandbox dédié au smoke test en environnement propre.

Exemple : 00-clean-smoke.wsb

<Configuration>
  <Networking>Disable</Networking>

  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>explorer.exe C:\Work\AppUnderTest</Command>
  </LogonCommand>
</Configuration>

Pour ce cas d’usage, il y a quatre points à retenir :

• Placer le livrable dans AppUnderTest
• Exposer ce dossier en read-only
• N’écrire que les journaux et résultats dans Outbox
• Si l’on ne veut pas voir de dépendances réseau, couper le réseau dès le départ

Ainsi, il suffit de remplacer le livrable et de double-cliquer sur le .wsb pour obtenir, à chaque fois, une validation de première installation dans un environnement propre.

Les problèmes que cela permet de repérer facilement

À ce stade, on trouve souvent des problèmes de ce genre.

• Une DLL ou un runtime prérequis présent sur la machine de développement mais absent en production
• Un prérequis WebView2 ou du package redistribuable VC++ implicite
• Un mauvais emplacement pour un répertoire ou un fichier de configuration créé seulement au premier lancement
• Un plantage à l’écriture de données d’exécution sous Program Files
• Des certificats, polices ou réglages « qui se trouvaient par hasard chez le développeur » et traités comme des prérequis

Le point essentiel est de toujours faire sortir vers Outbox ce qui se passe côté Sandbox. Tout disparaît au moment de la fermeture, donc les journaux et les dumps ne doivent jamais rester à l’intérieur.

Garder aussi une version avec réseau, dans un fichier séparé

Si la cible est un installeur web ou une application avec authentification en ligne, garder le réseau coupé ne fera apparaître qu’une autre catégorie de problèmes.

Dans ce cas, il vaut mieux créer un fichier séparé, du type 01-clean-online.wsb, avec la même structure, et ne pas mélanger « reproduction en mode hors ligne » et « reproduction en mode en ligne », pour rester clair.

Une procédure pour isoler les problèmes de privilèges administrateur

Dans le développement d’applications Windows, les questions de privilèges administrateur sont souvent mêlées les unes aux autres.

• Est-ce nécessaire uniquement à l’installation ?
• Est-ce nécessaire aussi à l’exécution ?
• Est-ce nécessaire seulement pour certains changements de réglages ?
• Ou bien est-ce simplement que l’emplacement de sauvegarde est mal choisi ?

Ce sujet lui-même a déjà été organisé dans les articles suivants.

• Quand Windows exige-t-il réellement des privilèges administrateur - UAC, zones protégées et comment le déterminer par conception
• Comment isoler concrètement, dans une application Windows, « uniquement les opérations nécessitant des privilèges administrateur »

Ici, on se concentre sur la façon d’utiliser le Sandbox pour accélérer la validation.

Les points à vérifier en premier

Ce qu’on veut d’abord vérifier dans le Sandbox, ce sont des frontières comme celles-ci.

• L’installeur écrit-il dans Program Files ou dans HKLM ?
• Y a-t-il un enregistrement de service, une installation de pilote, ou une modification des règles du pare-feu ?
• L’outil de mise à jour essaie-t-il de remplacer des éléments à l’échelle de la machine ?
• L’application essaie-t-elle d’écrire des réglages d’exécution, des journaux ou du cache dans des zones protégées ?
• Y a-t-il une intégration OS comme des extensions Shell ou un enregistrement COM ?

Autrement dit, l’objectif est de séparer « les opérations qui nécessitent réellement des privilèges administrateur » des « opérations dont seul l’emplacement d’exécution est mal choisi ».

L’état par défaut du Sandbox ne suffit pas à valider un comportement en utilisateur standard

C’est un point important.

La commande de connexion de Windows Sandbox s’exécute avec le compte utilisateur du conteneur. Microsoft Learn indique lui-même que cet utilisateur du conteneur est censé être un compte administrateur.

Autrement dit, la session Sandbox par défaut est difficile à utiliser telle quelle pour une « reproduction en utilisateur standard ».

Pour bien isoler les problèmes de privilèges administrateur, il est plus simple de créer un autre utilisateur standard dans le Sandbox et de lancer l’application en tant que cet utilisateur.

Exemple : 10-standard-user.wsb

<Configuration>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Scripts</HostFolder>
      <SandboxFolder>C:\Work\Scripts</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>powershell.exe -NoExit -ExecutionPolicy Bypass -File C:\Work\Scripts\Prep-StandardUser.ps1</Command>
  </LogonCommand>
</Configuration>

Exemple : Prep-StandardUser.ps1

$UserName = 'wsbuser'
$Password = 'P@ssw0rd-For-Test-Only!'

$existing = Get-LocalUser -Name $UserName -ErrorAction SilentlyContinue
if (-not $existing) {
    $secure = ConvertTo-SecureString $Password -AsPlainText -Force
    New-LocalUser -Name $UserName -Password $secure -AccountNeverExpires | Out-Null
}

try {
    Remove-LocalGroupMember -Group 'Administrators' -Member $UserName -ErrorAction Stop
}
catch {
}

try {
    Add-LocalGroupMember -Group 'Users' -Member $UserName -ErrorAction Stop
}
catch {
}

Write-Host ''
Write-Host 'Standard user has been prepared.'
Write-Host "User     : $UserName"
Write-Host "Password : $Password"
Write-Host ''
Write-Host 'Run your app as the standard user with:'
Write-Host 'runas /user:wsbuser "C:\Work\AppUnderTest\MyApp.exe"'
Write-Host ''

Start-Process explorer.exe 'C:\Work\AppUnderTest'

Avec cette configuration, un utilisateur standard est déjà prêt dès le démarrage du Sandbox, ce qui permet d’essayer directement :

runas /user:wsbuser "C:\Work\AppUnderTest\MyApp.exe"

Ce que cela permet de voir

Avec cette méthode, des problèmes comme ceux-ci deviennent plus faciles à repérer.

• Les réglages d’exécution sont sauvegardés à côté de l’EXE et l’opération échoue
• Une écriture dans HKLM échoue
• L’outil de mise à jour part du principe d’un fonctionnement à l’échelle de la machine
• L’emplacement des journaux se trouve sous Program Files
• Un seul bouton nécessite les droits administrateur, mais toute l’application part du principe d’une élévation

Les problèmes de privilèges administrateur peuvent parfois se voir dès la revue de code. Mais observer concrètement où ça coince quand on exécute vraiment en utilisateur standard rend la frontière de conception beaucoup plus nette.

Créer volontairement un état où les privilèges ou les dépendances manquent

Au-delà du simple fait de « ne pas être administrateur », retirer volontairement une partie du confort offert par l’environnement met en évidence des dépendances cachées.

Exemple : 20-restricted-runtime.wsb

<Configuration>
  <Networking>Disable</Networking>
  <ClipboardRedirection>Disable</ClipboardRedirection>
  <PrinterRedirection>Disable</PrinterRedirection>
  <ProtectedClient>Enable</ProtectedClient>

  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>explorer.exe C:\Work\AppUnderTest</Command>
  </LogonCommand>
</Configuration>

Ce que ce profil permet de vérifier

Ce profil restreint convient bien à des vérifications comme celles-ci.

• Y a-t-il une dépendance cachée qui empêche le démarrage sans réseau ?
• Y a-t-il une hypothèse selon laquelle des fichiers arrivent via le presse-papiers ?
• L’interface ou le traitement des rapports est-il écrit en supposant qu’une imprimante par défaut est visible ?
• Y a-t-il des dépendances superflues derrière des opérations qui « marchaient à peu près » même via une session RDP ?
• Y a-t-il du code peu rigoureux qui suppose un accès en écriture libre à un dossier partagé ?

C’est particulièrement vrai pour les applications métier : « ça marchait normalement chez moi » se transforme souvent, sur le poste du terrain, en

• restrictions réseau
• restrictions du presse-papiers
• absence d’imprimante
• restrictions d’écriture sur les dossiers partagés

Se rapprocher de ce monde-là d’abord dans le Sandbox évite de rester bloqué plus tard face à des tickets de support.

Ne pas exposer les dossiers partagés trop largement

C’est aussi un point très important.

Les dossiers mappés du Sandbox sont pratiques, mais les modifications apportées à un dossier partagé en écriture persistent côté hôte, même après la fermeture du Sandbox.

Il vaut donc mieux éviter des partages comme ceux-ci.

• Partager la totalité de C:\Users
• Exposer l’intégralité d’un dépôt en écriture
• Partager Downloads ou Documents en écriture sans précaution

La base consiste à adopter deux niveaux :

• Les entrées dans un dossier restreint, en read-only
• Uniquement les sorties dans un Outbox dédié, en read-write

Créer un environnement à ressources limitées

Windows Sandbox n’offre pas une grande liberté en matière de contrôle des ressources. Il reste néanmoins utilisable pour une « validation avec ressources légèrement limitées ».

Exemple : 30-low-resource.wsb

<Configuration>
  <VGpu>Disable</VGpu>
  <MemoryInMB>2048</MemoryInMB>
  <Networking>Disable</Networking>

  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>explorer.exe C:\Work\AppUnderTest</Command>
  </LogonCommand>
</Configuration>

Les problèmes que cela rend plus visibles

Avec ce profil, des problèmes comme ceux-ci ressortent plus facilement.

• Une consommation excessive de mémoire au démarrage
• L’absence de vérification de marge mémoire lors de la lecture de gros fichiers
• Un rendu qui devient extrêmement lourd sans partage GPU
• Un mauvais comportement de repli en WPF / WebView2 / traitement d’image / traitement vidéo
• Des problèmes d’interface « invisibles chez moi parce que j’ai un GPU performant »

Selon la spécification de configuration de Microsoft, si MemoryInMB est inférieur à 2048 Mo, la valeur est automatiquement relevée jusqu’au minimum nécessaire au démarrage. Autrement dit, il est réaliste de considérer environ 2 Go comme plancher pour une validation en faible mémoire sous Windows Sandbox.

Les cas où le Sandbox seul ne suffit pas

À l’inverse, Windows Sandbox seul est un peu insuffisant pour ceci.

• Limiter fortement l’utilisation du CPU
• Créer précisément une saturation de l’espace disque
• Injecter une latence d’E/S
• Faire tourner une matrice sur plusieurs tailles de mémoire
• Faire tourner de manière persistante un soak test de longue durée

Pour cela, il est plus simple de passer d’emblée à une VM complète sous Hyper-V ou équivalent.

Le Sandbox est efficace pour un « environnement légèrement restreint », mais ce n’est pas une « plateforme de test de charge de précision ».

Sur Windows 11 24H2 et ultérieur, la CLI facilite aussi le pilotage

Le nouveau Windows Sandbox sous Windows 11 24H2 et ultérieur propose également une CLI.

Les commandes disponibles sont à peu près celles-ci.

• wsb start
• wsb list
• wsb connect
• wsb exec
• wsb share
• wsb stop

Par exemple, dans sa forme la plus minimale, le déroulement est le suivant.

wsb start --config "<Configuration><Networking>Disabled</Networking></Configuration>"
wsb list

À noter que les exemples officiels de la CLI Windows Sandbox utilisent Disabled, alors que la documentation du schéma du fichier de configuration .wsb mentionne Disable / Enable / Default. Si vous intégrez --config en ligne dans votre flux de travail, vérifiez quelle orthographe est acceptée sur votre machine réelle sous Windows 11 24H2 ou ultérieur.

Une fois connu l’ID du Sandbox en cours d’exécution, on peut s’y connecter avec :

wsb connect --id <sandbox-id>

Les situations où la CLI est utile

La CLI est efficace dans des situations comme celles-ci.

• On veut intégrer le démarrage du Sandbox dans un script de reproduction local
• On veut invoquer des configurations fréquemment utilisées depuis un fichier batch ou PowerShell
• On veut ajouter un partage de dossier à un Sandbox en cours d’exécution
• On veut automatiser légèrement ses procédures de validation locales

Pourquoi il vaut mieux garder aussi les fichiers .wsb

Cela dit, mieux vaut ne pas abandonner les fichiers .wsb pour l’instant.

La raison est simple : ils se lisent comme des noms de scénario.

• 00-clean-smoke.wsb
• 10-standard-user.wsb
• 20-restricted-runtime.wsb
• 30-low-resource.wsb

Nommés ainsi, n’importe qui peut comprendre à quoi ils servent.

La CLI est pratique, mais en pratique, la répartition des rôles la plus facile à gérer est à peu près « les conditions sont définies dans .wsb, le démarrage est encapsulé par la CLI ».

Points de vigilance concernant la CLI

wsb exec présente actuellement des contraintes sur la capture des E/S de processus, et l’exécution dans le contexte d’un utilisateur déjà connecté nécessite également une session utilisateur active.

Autrement dit, mieux vaut ne pas trop en attendre comme plateforme de test automatisé entièrement headless. C’est pratique pour automatiser une reproduction locale, mais ce n’est pas le genre d’outil qu’on met en place à la place d’une CI.

Points de vigilance à ne pas manquer en exploitation

Pour finir, un récapitulatif des points où l’on se fait piéger en pratique.

Garder les dossiers partagés au minimum

Le Sandbox est isolé, mais les dossiers mappés restent connectés à l’hôte. Un dossier partagé en écriture a un impact sur l’hôte.

Ne pas partager largement, et concentrer les partages inscriptibles sur le seul Outbox. C’est la base.

Récupérer les journaux et les dumps avant de fermer

Une évidence, mais : une fois fermé, tout disparaît. C’est précisément pour cela qu’il vaut mieux fixer dès le départ la destination de sortie sur Outbox.

Ne pas se contenter de « la session Sandbox par défaut » pour la validation en utilisateur standard

Pour bien isoler les problèmes de privilèges administrateur, démarrer avec un autre utilisateur permet de rester plus clair. Rester flou sur ce point laisse subsister le risque : « ça marchait dans le Sandbox mais ça plante chez l’utilisateur standard du client ».

Ne pas trop compter dessus pour la validation des écarts entre versions d’OS

Le Sandbox convient à la validation propre sur la même famille d’OS, mais ce n’est pas un simulateur d’anciennes versions de Windows. Pour examiner un autre OS, il faut passer d’emblée par une VM complète.

Des contraintes de stratégie de groupe peuvent s’appliquer sur les postes administrés en entreprise

Les réglages contrôlés par la stratégie de groupe (Group Policy) peuvent ne pas être modifiables depuis un fichier .wsb. Sur un poste d’entreprise verrouillé, quand « le réglage ne prend pas effet », mieux vaut d’abord soupçonner un contrôle par stratégie.

Résumé

L’utilisation de Windows Sandbox accélère considérablement ce type de validation dans le développement d’applications Windows.

• L’isolation des problèmes de privilèges administrateur
• La vérification de la première installation dans un environnement propre
• La mise en évidence des dépendances réseau et aux dossiers partagés
• La reproduction de privilèges ou de dépendances manquants
• La validation restreinte légère en faible mémoire / sans GPU

Ramené à ce qui fonctionne concrètement en pratique, cela tient à peu près en cinq points.

1. Créer de manière fixe AppUnderTest, Scripts et Outbox
2. Séparer les fichiers .wsb par scénario
3. Mettre les entrées en read-only et seules les sorties en read-write
4. Effectuer la validation en utilisateur standard avec un utilisateur séparé
5. Passer à une VM complète si l’on a besoin du CPU, du disque ou d’un ancien OS

La qualité du Sandbox ne tient pas au fait qu’il soit universel, mais au fait qu’il permet de réduire la préparation avant validation tout en pouvant remettre l’environnement à zéro à chaque fois.

En fixant les scénarios en fonction de cette caractéristique, on peut faire tourner la validation non plus comme « une reproduction ponctuelle » mais comme une procédure de validation reproductible.

Articles connexes

• Quand Windows exige-t-il réellement des privilèges administrateur - UAC, zones protégées et comment le déterminer par conception
• Comment isoler concrètement, dans une application Windows, « uniquement les opérations nécessitant des privilèges administrateur »
• Comment choisir une méthode de distribution pour une application Windows - Tableau de décision MSI / MSIX / ClickOnce / xcopy / updater personnalisé
• Introduction à la collecte de dumps de plantage pour les applications Windows - Comment choisir entre WER / ProcDump / WinDbg

Sujets connexes

• Sujets techniques Windows

Services liés à cette thématique

• Développement d’applications Windows
• Conseil technique et revue de conception
• Nous contacter

Références

1. Microsoft Learn, Windows Sandbox
2. Microsoft Learn, Install Windows Sandbox
3. Microsoft Learn, Use and configure Windows Sandbox
4. Microsoft Learn, Windows Sandbox sample configuration files
5. Microsoft Learn, Windows Sandbox frequently asked questions (FAQ)
6. Microsoft Learn, Windows Sandbox versions
7. Microsoft Learn, Windows Sandbox command line interface

</content>

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Pour quels types de validation Windows Sandbox est-il adapté ?

Il excelle pour reproduire un environnement propre lors d'une première installation, isoler les problèmes de privilèges administrateur, mettre en évidence les dépendances réseau ou aux dossiers partagés, reproduire des privilèges ou des dépendances manquants, et effectuer des vérifications légères en conditions de faible mémoire ou sans GPU. Il est plus léger qu'une VM complète, démarre rapidement et repart de zéro à chaque fermeture. En revanche, pour reproduire une autre version d'OS, exécuter plusieurs instances simultanément, ou reproduire précisément des quotas CPU ou une saturation disque, une VM complète est plus adaptée.

Y a-t-il des conditions pour utiliser Windows Sandbox ?

Il fonctionne sous Windows Pro / Enterprise / Education. Il n'est pas disponible sous l'édition Home. Il faut également que la fonctionnalité de virtualisation soit activée, ainsi qu'une quantité minimale de RAM, d'espace disque et de cœurs CPU. Comme il utilise la même famille de build Windows que l'hôte, un hôte sous Windows 11 ne permettra pas de reproduire un environnement Windows 10.

Que peut-on configurer dans un fichier .wsb ?

On peut y fixer l'activation ou la désactivation du réseau, le mode read-only / read-write des dossiers partagés, la limite de mémoire (MemoryInMB), la désactivation du vGPU, la désactivation du partage du presse-papiers, ou encore la commande exécutée au démarrage (LogonCommand). En séparant les fichiers .wsb par cas d'usage, on peut recréer autant de fois que nécessaire un environnement de validation dans les mêmes conditions, d'un simple double-clic. À noter que si MemoryInMB est inférieur à 2048 Mo, la valeur est automatiquement relevée jusqu'au minimum requis pour démarrer ; il est donc réaliste de considérer 2 Go comme le plancher pour une validation en faible mémoire.

Peut-on valider le comportement d'un utilisateur standard avec Windows Sandbox ?

La session Sandbox par défaut est difficile à utiliser telle quelle pour une validation en utilisateur standard, car la commande de connexion du Sandbox s'exécute avec le compte utilisateur du conteneur, et cet utilisateur est censé être un compte administrateur. Pour reproduire un manque de privilèges en utilisateur standard, il est plus simple de créer un utilisateur standard dans le Sandbox via un script de démarrage, puis de lancer l'application en tant que cet utilisateur avec la commande runas.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.