Verrouiller un poste professionnel en mode kiosque — Choisir entre Assigned Access et Shell Launcher, et concevoir l'exploitation

« Sur un PC censé être une borne d’accueil, un visiteur avait ouvert Excel depuis la barre des tâches. » « Derrière l’écran de commande d’un équipement, YouTube tournait en arrière-plan, et c’était la cause de la plainte concernant la mauvaise réactivité de l’écran tactile. » « Sur la machine de démonstration d’un salon professionnel, en arrivant le matin, le bureau était entièrement visible, affichant l’écran de paramétrage de l’économiseur d’écran. » — Un poste Windows censé être dédié à une seule application finit toujours, si on le laisse faire, par être utilisé comme « un simple PC ».

La contre-mesure classique consiste à « activer la connexion automatique et inscrire l’application métier dans le démarrage », mais cela ne protège absolument rien. Le shell Explorer reste entièrement actif, si bien qu’Alt+Tab ou la touche Windows permettent de revenir instantanément au bureau. Cela dit, Windows dispose de plusieurs mécanismes pour le mode kiosque — Assigned Access, Shell Launcher, kiosque multi-application — et lequel est disponible dépend de l’édition et de la version de Windows, ce qui provoque fréquemment des retours en arrière du type « en essayant de le mettre en place sur un poste Pro, on s’est aperçu que Shell Launcher n’était pas disponible ».

Cet article s’adresse aux développeurs et aux responsables informatiques qui veulent configurer un « PC qui ne fait tourner qu’une seule application » — bornes d’accueil, postes de commande en usine, écrans de commande d’équipements d’inspection, machines de démonstration, etc. Il fait le point, avec le soutien de la documentation officielle, sur la vue d’ensemble des méthodes et leurs exigences d’édition, des exemples de configuration en PowerShell/XML, ainsi que sur la conception de l’exploitation : connexion automatique, reprise après un arrêt anormal, Windows Update et voies de maintenance.

1. La conclusion, d’abord

• « Connexion automatique + démarrage au lancement » n’est pas un kiosque. Tant que le shell Explorer est actif, l’utilisateur peut tout faire. Si vous voulez réellement protéger le poste, utilisez un mécanisme dédié.
• Le kiosque à application unique d’Assigned Access exécute en plein écran, par-dessus l’écran de verrouillage, une application UWP ou Microsoft Edge, et redémarre automatiquement l’application dès qu’elle est fermée. Il est disponible à partir de l’édition Pro.¹
• Sous Windows 11, Assigned Access permet aussi de transformer une application Win32 (de bureau) en kiosque. On indique le chemin de l’EXE dans v4:ClassicAppPath, ajouté au schéma à partir de Windows 11 (21H2). Le kiosque de Windows 10 est limité à UWP/Edge.²
• Shell Launcher est un mécanisme qui remplace Explorer.exe lui-même par l’application métier (Win32/UWP), réservé aux gammes d’édition Enterprise / Education / IoT Enterprise. Il n’est pas disponible sur Pro. Le comportement à la fermeture du shell (redémarrage, redémarrage de l’appareil, etc.) peut être configuré de façon déclarative.³⁴
• Le kiosque multi-application (expérience utilisateur restreinte) est une méthode qui crée, via une liste d’applications autorisées et un menu Démarrer dédié, un « poste partagé où seules quelques applications sont utilisables ». Des règles AppLocker sont générées automatiquement, et les applications non autorisées ne peuvent pas être lancées.²
• Les méthodes de configuration sont de plus en plus unifiées. Que ce soit pour l’application unique, le multi-application ou Shell Launcher, la procédure standard actuelle consiste à passer par le CSP AssignedAccess (via un MDM comme Intune), ou par le même CSP appelé localement via le pont WMI et PowerShell.⁵⁶
• La sortie de l’expérience kiosque se fait par défaut avec Ctrl+Alt+Suppr. Sous Windows 11, BreakoutSequence permet de la modifier. Prévoyez toujours, dans votre conception, un chemin permettant au personnel de maintenance de se connecter.²
• Même en verrouillant le poste, si la conception de l’application métier elle-même n’est pas au point (interface plein écran, absence de bouton de fermeture, récupération autonome en cas d’exception), une brèche subsiste. Le mécanisme de l’OS et la conception de l’application vont de pair.

2. Vue d’ensemble des options — les quatre méthodes diffèrent par « ce qu’elles protègent »

Comparons d’abord les méthodes côte à côte. Ce qui compte, ce n’est pas l’apparence, mais l’état du shell Explorer et qui bloque les opérations non autorisées.

Voici comment ces méthodes se répartissent en pratique.

• Pour un poste manipulé par des visiteurs ou des personnes non identifiées (accueil, salon professionnel, navigation publique), le kiosque à application unique. La surface d’attaque est réduite au minimum.
• Pour un poste partagé utilisant un nombre fixe d’applications (poste de ligne sur le terrain, usage pédagogique), le kiosque multi-application.
• Pour un usage industriel où une seule application métier Win32 sert d’écran de commande d’un équipement, Shell Launcher. Sa force est que l’interface issue d’Explorer (notifications, barre des tâches, interface révélée par un balayage depuis le bord de l’écran) n’existe tout simplement pas ; la possibilité de configurer un comportement de reprise selon le code de sortie le rend également adapté aux équipements.⁴
• La connexion automatique + démarrage au lancement peut servir de composant (l’automatisation de la connexion) dans l’une des méthodes ci-dessus, mais prise seule, ce n’est pas un kiosque.

Notez que sur un même poste, il n’est pas possible de configurer simultanément KioskModeApp (kiosque à application unique) et Shell Launcher.² Il faut choisir l’un ou l’autre.

3. Les exigences d’édition — ce que Pro permet, ce qu’Enterprise exige

Avant de choisir une méthode, vérifiez l’édition du poste dont vous disposez. Reporter cette vérification à plus tard signifie devoir tout reconcevoir.

• Assigned Access (application unique/multi-application) : Pro / Enterprise / Education / IoT Enterprise (y compris leurs versions LTSC respectives).¹
• Shell Launcher : Enterprise / Enterprise LTSC / Education / IoT Enterprise / IoT Enterprise LTSC. Pro n’est pas éligible.³
• Keyboard Filter (blocage des touches) : gammes Enterprise / Education / IoT Enterprise uniquement. Pro n’est pas éligible.⁸

Autrement dit, la demande classique « faire tourner une seule application Win32 sur un poste Pro » se traite ainsi :

• Sous Windows 11, cela se réalise directement avec v4:ClassicAppPath d’Assigned Access.²
• Sous Windows 10 Pro, il n’y a pas d’option directe : il faut soit passer en UWP, soit s’en approcher avec un kiosque multi-application + lancement automatique (rs5:AutoLaunch), soit monter en édition.²

Si vous pouvez choisir librement le poste pour une intégration matérielle ou un PC industriel, IoT Enterprise LTSC est le candidat naturel : il donne accès à Shell Launcher et Keyboard Filter, sans mise à jour de fonctionnalités imposée. La logique de choix d’édition est détaillée dans l’article compagnon publié le même jour, « Quel Windows installer sur un PC industriel ? — Guide pratique de Windows IoT Enterprise / LTSC ».

Autre prérequis important : l’expérience kiosque exige que l’UAC soit activé et une connexion depuis la console. L’expérience kiosque ne fonctionne pas via une connexion Bureau à distance.¹ Le piège classique du premier essai consiste à se connecter en RDP pour vérifier le fonctionnement, sans que rien ne se passe. Pour la relation entre session console et session RDP, voir « Comment comprendre la séparation des sessions sous Windows ».

4. Créer un kiosque à application unique avec Assigned Access

Il existe trois voies de configuration. Nous les voyons dans l’ordre de simplicité aux sections 4.1 à 4.3, puis, pour le XML de configuration qui est la méthode de référence, nous poursuivons avec la procédure d’application concrète sur un poste (4.4) et la façon de vérifier que la configuration a bien été appliquée (4.5).

4.1 Créer via l’application Paramètres (un seul poste, la voie la plus rapide pour Edge/UWP)

Un assistant permet de créer le compte local dédié au kiosque et de choisir l’application cible. Voici la procédure.⁵

1. Ouvrez Paramètres > Comptes > Autres utilisateurs
2. Appuyez sur « Commencer » (Get Started) dans « Configurer un kiosque » (Set up a kiosk)
3. Dans la boîte de dialogue « Créer un compte », saisissez le nom du compte et appuyez sur « Suivant » (si un utilisateur standard local existe déjà, vous pouvez aussi choisir « Sélectionner un compte existant »)
4. Choisissez l’application à exécuter à la connexion du compte kiosque. Si vous choisissez Microsoft Edge, configurez ensuite :
   • un affichage plein écran (affichage dynamique) ou la conservation de certaines commandes du navigateur (navigateur public)
   • l’URL ouverte à la connexion
   • si vous choisissez le navigateur public, le délai avant redémarrage d’Edge en cas d’inactivité prolongée
5. Appuyez sur « Fermer »

Une fois le poste redémarré après la configuration, le compte local créé se connecte automatiquement et l’application indiquée démarre.⁵ Pour un seul poste avec Edge ou une application UWP simple, cela suffit largement.

4.2 Créer via une applet de commande PowerShell (UWP uniquement)

Set-AssignedAccess permet de créer en une seule ligne une configuration minimale du type « cet utilisateur standard local n’a accès qu’à cette application UWP » (limité à UWP, à un utilisateur standard local, un compte administrateur n’étant pas accepté).⁹

# Restreindre l'utilisateur standard local KioskUser à une seule application UWP
Set-AssignedAccess -UserName 'KioskUser' -AppUserModelId 'Contoso.KenkiPanel_abc123!App'

# Réinitialiser
Clear-AssignedAccess

L’AUMID (AppUserModelID) à passer en argument se trouve avec Get-StartApps. Cette applet de commande liste le nom et l’AppID des applications installées, et renvoie deux colonnes, Name et AppID.¹⁰

# Parcourir visuellement la liste complète
Get-StartApps

# Filtrer par une partie du nom (les caractères génériques sont acceptés). La valeur de la colonne AppID est directement l'AUMID
Get-StartApps -Name '*KenkiPanel*' | Format-Table Name, AppID -AutoSize

La sortie se présente sous cette forme (les valeurs varient selon l’environnement).¹⁰

Name              AppID
----              -----
KenkiPanel        Contoso.KenkiPanel_abc123!App

Attention, point important : Get-StartApps renvoie les applications installées de « l’utilisateur en cours d’exécution ». Si vous voulez examiner une application provisionnée pour le compte kiosque, connectez-vous avec ce compte avant de l’exécuter. Un piège classique consiste à l’exécuter avec un compte administrateur et à ne rien voir apparaître. Notez aussi que l’AUMID peut changer lors d’une mise à jour d’une application UWP (auquel cas la configuration doit être refaite).⁷

4.3 XML de configuration + CSP AssignedAccess (la méthode de référence)

C’est la méthode de référence, qui couvre la spécification d’une application Win32, la connexion automatique et le changement de la touche d’échappement. Depuis un MDM comme Intune, on l’applique sur ./Vendor/MSFT/AssignedAccess/Configuration ; sur un poste autonome, on injecte le même XML via le pont WMI, depuis un PowerShell disposant des privilèges SYSTEM.⁵ Voici les points clés du XML.

<AssignedAccessConfiguration
    xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config"
    xmlns:rs5="http://schemas.microsoft.com/AssignedAccess/201810/config"
    xmlns:v4="http://schemas.microsoft.com/AssignedAccess/2021/config">
  <Profiles>
    <Profile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}">
      <!-- Windows 11 : transformer une application Win32 en kiosque (des arguments peuvent aussi être passés) -->
      <KioskModeApp v4:ClassicAppPath="%ProgramFiles%\Contoso\KenkiPanel.exe"
                    v4:ClassicAppArguments="--line 3" />
      <!-- Changer la touche d'échappement, par défaut Ctrl+Alt+Suppr -->
      <v4:BreakoutSequence Key="Ctrl+Alt+K" />
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <!-- Windows crée et gère lui-même un utilisateur standard local dédié pour la connexion automatique -->
      <AutoLogonAccount rs5:DisplayName="Terminal d'accueil" />
      <DefaultProfile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}" />
    </Config>
  </Configs>
</AssignedAccessConfiguration>

Pour une application UWP, spécifiez AppUserModelId (AUMID) dans KioskModeApp. Attention, l’AUMID peut changer lors d’une mise à jour de l’application UWP, auquel cas la configuration doit être mise à jour.⁷ Notez également que les profils kiosque ne peuvent être assignés qu’à des utilisateurs, pas à des groupes.²

4.4 Appliquer réellement la configuration via le pont WMI

Sur un poste sans MDM, on appelle le même CSP via le fournisseur WMI du pont MDM. C’est le point où l’on bloque le plus souvent dans la procédure, voici donc les étapes détaillées.⁵

Étape 1 : lancer PowerShell en tant que SYSTEM. Le pont WMI des paramètres d’appareil doit s’exécuter sous le compte SYSTEM (LocalSystem). Un PowerShell avec des privilèges administrateur ne suffit pas.⁵ Utiliser PsExec de Sysinternals est la méthode indiquée officiellement.

:: Ouvrir l'invite de commandes en tant qu'administrateur, puis lancer un PowerShell interactif avec les privilèges SYSTEM
psexec.exe -i -s powershell.exe

Étape 2 : vérifier que le PowerShell lancé est bien SYSTEM. Avancer sans faire cette vérification et se retrouver avec « pas d’erreur mais ça ne fonctionne pas » est un scénario classique.

# Si NT AUTHORITY\SYSTEM s'affiche, c'est bon
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name

Étape 3 : encoder le XML en HTML et l’injecter. Exécutez ceci dans cette même session PowerShell avec les privilèges SYSTEM.

$assignedAccessConfiguration = @"
<?xml version="1.0" encoding="utf-8"?>
<AssignedAccessConfiguration xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config" xmlns:rs5="http://schemas.microsoft.com/AssignedAccess/201810/config" xmlns:v4="http://schemas.microsoft.com/AssignedAccess/2021/config">
  <Profiles>
    <Profile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}">
      <KioskModeApp v4:ClassicAppPath="%ProgramFiles%\Contoso\KenkiPanel.exe" v4:ClassicAppArguments="--line 3" />
      <v4:BreakoutSequence Key="Ctrl+Alt+K" />
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <AutoLogonAccount rs5:DisplayName="Terminal d'accueil" />
      <DefaultProfile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}" />
    </Config>
  </Configs>
</AssignedAccessConfiguration>
"@

$namespaceName = "root\cimv2\mdm\dmmap"
$className     = "MDM_AssignedAccess"

$obj = Get-CimInstance -Namespace $namespaceName -ClassName $className
# Ne pas transmettre le XML tel quel : l'encoder en HTML avant de le transmettre
$obj.Configuration = [System.Net.WebUtility]::HtmlEncode($assignedAccessConfiguration)
Set-CimInstance -CimInstance $obj

Étape 4 : redémarrer le poste. La configuration prend effet à la connexion suivant le redémarrage. Après le redémarrage, le compte local créé par AutoLogonAccount se connecte automatiquement et l’application indiquée démarre.⁵

Pour annuler la configuration, définissez Configuration à $null depuis un PowerShell disposant toujours des privilèges SYSTEM, puis redémarrez.⁵

$obj = Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" -ClassName "MDM_AssignedAccess"
$obj.Configuration = $null
Set-CimInstance -CimInstance $obj

4.5 Comment vérifier que la configuration a bien été appliquée

Pour diagnostiquer le cas « pas d’erreur, mais ça ne fonctionne pas », voici trois moyens de vérification à préparer.

(a) Activer et consulter le journal des événements. C’est le canal indiqué officiellement pour la vérification.⁷ Les erreurs de validation du XML de configuration et les échecs à l’exécution y apparaissent.

Observateur d'événements
  > Journaux des applications et des services
    > Microsoft
      > Windows
        > AssignedAccess
          > Operational

Le canal peut être désactivé par défaut : sélectionnez-le puis appuyez sur « Activer le journal » dans le volet de droite avant de reproduire le problème.

(b) Vérifier la configuration écrite dans le registre. La configuration d’Assigned Access est enregistrée dans les clés suivantes.⁷

(c) Relire la valeur depuis le CSP. Juste après l’injection, une relecture depuis le même PowerShell avec privilèges SYSTEM permet de savoir immédiatement si la valeur a bien été enregistrée.

$obj = Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" -ClassName "MDM_AssignedAccess"
$obj.Configuration

# Si la valeur renvoyée reste encodée et difficile à lire, la décoder pour l'inspecter visuellement
[System.Net.WebUtility]::HtmlDecode($obj.Configuration)

Si le résultat est vide, l’application elle-même a échoué ; s’il contient une valeur mais que rien ne fonctionne, il faut suspecter le contenu du XML (chemin de l’application, incohérence de GUID entre Profile et Config, exigences d’édition). Si une erreur survient à l’étape 3, retournez d’abord à la vérification SYSTEM de l’étape 2.

5. Transformer une application Win32 en shell avec Shell Launcher

Si une édition Enterprise est disponible, Shell Launcher est la solution la plus solide pour un poste où « l’existence même d’Explorer est gênante », comme un écran de commande d’équipement. Shell Launcher v2 (Windows 10 1809 et versions ultérieures) remplace Explorer.exe par CustomShellHost.exe, qui lance et surveille l’application métier, et permet de transformer en shell aussi bien une application Win32 qu’une application UWP.³

La configuration se fait via un XML dédié, dont la caractéristique principale est de permettre de déclarer, par code de sortie, le comportement de reprise lorsque l’application se termine.⁴

<ShellLauncherConfiguration
    xmlns="http://schemas.microsoft.com/ShellLauncher/2018/Configuration"
    xmlns:V2="http://schemas.microsoft.com/ShellLauncher/2019/Configuration">
  <Profiles>
    <DefaultProfile>
      <!-- Le personnel de maintenance et les autres utilisateurs sans profil assigné gardent l'Explorer normal -->
      <Shell Shell="%SystemRoot%\explorer.exe" />
    </DefaultProfile>
    <Profile Id="{GUID que vous générez vous-même}">
      <Shell Shell="%ProgramFiles%\Contoso\KensaPanel.exe" V2:AppType="Desktop"
             V2:AllAppsFullScreen="true">
        <ReturnCodeActions>
          <ReturnCodeAction ReturnCode="0"  Action="RestartShell"/>   <!-- Fin normale -> redémarrage -->
          <ReturnCodeAction ReturnCode="10" Action="RestartDevice"/>  <!-- Demande un redémarrage de l'appareil -->
        </ReturnCodeActions>
        <DefaultAction Action="RestartShell"/>
      </Shell>
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <AutoLogonAccount/>  <!-- Crée et connecte automatiquement l'utilisateur standard local « Kiosk » -->
      <Profile Id="{GUID que vous générez vous-même}"/>
    </Config>
  </Configs>
</ShellLauncherConfiguration>

Le GUID de Profile Id n’est pas quelque chose que l’on demande et qui vous serait délivré. C’est une valeur que vous choisissez vous-même, du moment qu’elle est unique dans le XML, et vous pouvez la générer avec New-Guid en PowerShell.⁴

# Générer une valeur avec ses accolades. Collez cette chaîne dans le XML
"{$((New-Guid).Guid.ToUpper())}"

Inscrivez la valeur générée sous la même forme (accolades comprises), à la fois côté Profiles et côté Configs. Si vous copiez l’exemple ci-dessus tel quel, cela ne fonctionnera pas : ce remplacement est nécessaire. Les valeurs Profile Id / DefaultProfile Id du XML de configuration Assigned Access du chapitre 4 sont de la même nature.

Les actions possibles sont au nombre de quatre : RestartShell / RestartDevice / ShutdownDevice / DoNothing. Si le code de sortie n’est associé à aucune action et qu’aucun DefaultAction n’est défini, « rien ne se passe », c’est-à-dire que l’écran reste bloqué, noir. Définissez toujours un DefaultAction.⁴ L’application se fait, pour un MDM, sur ./Vendor/MSFT/AssignedAccess/ShellLauncher ; en local, via le même pont WMI qu’Assigned Access, en définissant le XML dans la propriété ShellLauncher de MDM_AssignedAccess.⁶ Selon l’environnement, il peut être nécessaire d’activer au préalable, via « Activer ou désactiver des fonctionnalités Windows », la fonctionnalité Shell Launcher (Client-EmbeddedShellLauncher) sous le verrouillage de l’appareil.

Voici trois pièges propres à Shell Launcher.³

• Une application qui lance un autre processus puis se termine elle-même ne peut pas servir de shell. Shell Launcher surveille la fin du processus indiqué : si vous indiquez un exécutable de type lanceur (l’exemple de la documentation officielle est write.exe), il sera immédiatement considéré comme « terminé ».
• Le shell s’exécute avec les privilèges de l’utilisateur connecté. Si vous assignez le shell à un compte administrateur, tout devient possible avec ces privilèges ; et si l’application shell elle-même exige une élévation administrateur, il faudra désactiver l’UAC pour qu’elle démarre. Il vaut mieux concevoir l’application pour qu’elle n’ait pas besoin d’élévation, avant d’en arriver là.
• Shell Launcher n’empêche pas le lancement d’autres applications. Comme il ne fait que remplacer le shell, des chemins comme le lancement d’un EXE via une boîte de dialogue de fichier au sein de l’application métier restent possibles. Sur un poste où l’on ne peut pas faire confiance à la personne qui l’utilise, combinez-le avec AppLocker ou Keyboard Filter.

6. Conception de l’exploitation — connexion automatique, reprise, Update et voies de maintenance

Choisir une méthode et la configurer ne suffit pas. Le cœur du mode kiosque réside dans la conception qui permet un fonctionnement continu et sans surveillance.

La connexion automatique doit privilégier en premier lieu AutoLogonAccount dans le XML de configuration. Windows créant et gérant lui-même un utilisateur standard local dédié, il n’est pas nécessaire de conserver un mot de passe.²⁴ La méthode traditionnelle par registre Winlogon (AutoAdminLogon/DefaultUserName/DefaultPassword) reste utilisable, mais le mot de passe y reste en clair. Par ailleurs, la connexion automatique ne fonctionne pas, par conception, sur un poste où une restriction de mot de passe EAS est appliquée : vérifiez qu’elle n’entre pas en conflit avec une stratégie MDM.⁷

Lorsque l’application plante, laissez la première reprise à l’OS. Le kiosque Assigned Access redémarre automatiquement l’application dès qu’elle se ferme.¹ Shell Launcher configure le comportement de reprise via DefaultAction/ReturnCodeActions.⁴ Au-delà, pour parer au cas où « le redémarrage ne fait que reproduire la même exception en boucle », prévoir une tâche de redémarrage périodique nocturne améliore la capacité de reprise (pour la conception de cette tâche, voir « Conception fiable de l’exploitation du planificateur de tâches »).

Windows Update ne se bloque pas, il se contrôle dans le temps. La configuration recommandée officiellement consiste à aligner les heures actives sur les horaires d’ouverture, à combiner téléchargement automatique et installation planifiée de nuit, et à désactiver les notifications, y compris les avertissements de redémarrage.⁷ Vérifiez sur le poste réel qu’après un redémarrage, l’enchaînement « connexion automatique → retour au kiosque » se fait bien automatiquement. Les paramètres d’alimentation suivent la même logique : mettez à 0 (désactivé) les délais de mise en veille et d’extinction de l’écran, et désactivez le bouton d’alimentation.⁷ Les postes réutilisant un ordinateur portable ou équipés de Modern Standby ont des comportements particulièrement capricieux : consultez aussi « Veille, mise en veille prolongée, Modern Standby et applications longue durée ».

Les failles côté clavier et tactile diffèrent selon la méthode. Dans le kiosque multi-application (expérience utilisateur restreinte), Alt+F4, Alt+Tab et Ctrl+Alt+Suppr ne sont pas bloqués par défaut.⁷ Keyboard Filter permet de les bloquer, en supprimant les combinaisons de touches aussi bien sur un clavier physique que sur un clavier à l’écran (activation via Dism /online /Enable-Feature /FeatureName:Client-KeyboardFilter, réservé aux gammes Enterprise).⁸ Sur un poste de type tablette, désactivez (0) la stratégie LockDown/AllowEdgeSwipe pour empêcher un balayage depuis le bord de l’écran de faire apparaître l’interface système.

La préservation d’une voie de maintenance est aussi importante que le blocage lui-même. La sortie du kiosque Assigned Access se fait par défaut avec Ctrl+Alt+Suppr (modifiable sous Windows 11 via BreakoutSequence), à partir de laquelle on se connecte avec un compte administrateur.² Si Keyboard Filter bloque également Ctrl+Alt+Suppr, la touche d’échappement propre à Keyboard Filter (par défaut, cinq appuis successifs sur la touche Windows gauche) devient le dernier chemin vers l’écran d’accueil.⁸ Notez que Keyboard Filter est désactivé en mode sans échec, et peut être exclu pour les comptes administrateurs.⁸ L’expérience kiosque elle-même est réservée à la console, mais la maintenance en RDP par un administrateur peut être utilisée en parallèle ; conserver aussi un accès distant réduit le nombre d’interventions sur site. En cas de problème, le canal « AssignedAccess > Operational » du journal des événements constitue la première source d’information sur une erreur de configuration.⁷

7. Conception côté application métier et bonnes pratiques (tableau de décision)

Quelle que soit la rigueur du verrouillage côté OS, une brèche subsiste tant que l’application reste « une application de bureau ordinaire ». Voici les exigences de conception pour une application destinée à un kiosque.

• Maintenir soi-même le plein écran sans bordure. Shell Launcher propose bien V2:AllAppsFullScreen, mais fondamentalement, l’application doit elle-même maintenir son état maximisé, au premier plan, sans barre de titre, et se ramener au premier plan en cas de perte de focus.
• Ne pas afficher de bouton de fermeture. Au lieu de placer un moyen de fermer à l’écran, faites apparaître un menu de maintenance via une opération cachée que seul le personnel de maintenance connaît (par exemple : toucher les quatre coins de l’écran dans l’ordre, puis saisir un mot de passe). En distinguant les codes de sortie, ReturnCodeActions de Shell Launcher permet des enchaînements comme « sortie depuis le menu de maintenance → ne rien faire pour revenir à Explorer » ou « sortie après une mise à jour → redémarrer l’appareil ».⁴
• Récupérer automatiquement en cas d’exception. Le pire scénario est d’avaler silencieusement une exception non gérée et de laisser l’écran figé, inutilisable. Écrivez un journal, terminez rapidement votre propre processus, et laissez le mécanisme de redémarrage de l’OS (redémarrage automatique du kiosque, RestartShell de Shell Launcher) prendre le relais.
• Empêcher les lancements multiples. Quand un mécanisme de redémarrage automatique se superpose à votre propre logique de redémarrage, un double lancement survient facilement. Mettez en place une prévention par mutex (« Empêcher le lancement multiple d’une application Windows »).
• Ne pas exiger d’élévation. Le compte kiosque doit en principe être un utilisateur standard ; avec Shell Launcher, un shell nécessitant une élévation force à désactiver l’UAC.³ Séparez les traitements qui nécessitent des privilèges administrateur (« Comment isoler concrètement, dans une application Windows, « uniquement les traitements nécessitant des privilèges administrateur » »).

Voici pour finir un tableau de décision.

8. Conclusion

• « Connexion automatique + démarrage au lancement » n’est pas un kiosque. Tant qu’Explorer reste actif, rien n’est protégé : utilisez Assigned Access ou Shell Launcher.
• Assigned Access est disponible à partir de Pro et permet de configurer un kiosque à application unique (UWP/Edge, et Win32 sous Windows 11) ainsi qu’une expérience utilisateur restreinte multi-application.
• Shell Launcher est un mécanisme, réservé aux gammes Enterprise / Education / IoT Enterprise, qui remplace Explorer.exe par l’application métier, et permet de déclarer un comportement de reprise (RestartShell, etc.) selon le code de sortie.
• La configuration est unifiée autour du CSP AssignedAccess : même sans MDM, le même XML peut être appliqué via le pont WMI et PowerShell (avec les privilèges SYSTEM).
• L’ossature de la conception d’exploitation repose sur la connexion automatique via AutoLogonAccount, la reprise par le mécanisme de redémarrage de l’OS combiné à un redémarrage périodique, le contrôle temporel de Windows Update, et la préservation de voies de sortie via BreakoutSequence, la touche d’échappement et la maintenance à distance.
• Le dernier rempart reste la conception de l’application métier. Ce n’est qu’en réunissant le maintien du plein écran, l’absence de bouton de fermeture, la récupération autonome en cas d’exception, la prévention des lancements multiples et l’absence de besoin d’élévation que le « PC qui ne fait tourner qu’une seule application » est réellement abouti.

Articles connexes

• Quel Windows installer sur un PC industriel ? — Guide pratique de Windows IoT Enterprise / LTSC
• Empêcher le lancement multiple d’une application Windows
• Comment comprendre la séparation des sessions sous Windows
• Veille, mise en veille prolongée, Modern Standby et applications longue durée
• Conception fiable de l’exploitation du planificateur de tâches
• Comment isoler concrètement, dans une application Windows, « uniquement les traitements nécessitant des privilèges administrateur »

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) prend en charge le choix et la configuration de la méthode pour des postes en mode kiosque — bornes d’accueil, postes de commande en usine, écrans de commande d’équipements d’inspection —, la conception et le développement d’applications métier résistantes au mode kiosque (interface plein écran, récupération autonome, séparation des privilèges), ainsi que le « reverrouillage » de postes existants.

• Développement d’applications Windows professionnelles
• Développement d’applications d’intégration d’équipements et de contrôle temps réel souple
• Conseil technique et revue de conception
• Contact

Références

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.

Questions fréquentes

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

Assigned Access est-il utilisable même sur Windows Pro ?

Oui. Assigned Access (le kiosque à application unique et l'expérience utilisateur restreinte multi-application) est pris en charge sur Pro / Enterprise / Education / IoT Enterprise (y compris leurs versions LTSC respectives). En revanche, Shell Launcher, qui remplace Explorer.exe lui-même par l'application métier, est réservé aux gammes Enterprise / Education / IoT Enterprise et n'est pas disponible sur Pro. Par ailleurs, l'expérience kiosque nécessite que l'UAC soit activé et une connexion depuis la console : l'expérience kiosque via une connexion Bureau à distance n'est pas prise en charge.

Shell Launcher est-il indispensable pour transformer une application Win32 (de bureau) en kiosque ?

Sous Windows 11, ce n'est plus indispensable. Avec le schéma Windows 11 (21H2 et versions ultérieures), Assigned Access permet de spécifier le chemin de l'exécutable d'une application de bureau via l'attribut v4:ClassicAppPath de l'élément KioskModeApp, et de configurer un kiosque à application unique pour une application Win32 même sur un poste Pro. Le kiosque Assigned Access de Windows 10 étant limité aux applications UWP et à Microsoft Edge, si vous ne voulez faire tourner qu'une seule application Win32, Shell Launcher (réservé à la gamme Enterprise) ou une configuration multi-application utilisant AutoLaunch deviennent les solutions réalistes. Vérifiez d'abord la correspondance entre l'édition et la méthode avant de concevoir votre solution.

L'application kiosque redémarre-t-elle automatiquement en cas d'arrêt anormal ?

Le comportement dépend de la méthode. Le kiosque à application unique d'Assigned Access est conçu pour redémarrer automatiquement l'application dès qu'elle est fermée. Avec Shell Launcher, le comportement à la fermeture de l'application transformée en shell se configure de façon déclarative via DefaultAction et ReturnCodeActions, avec le choix entre RestartShell (redémarrage du shell), RestartDevice (redémarrage de l'appareil), ShutdownDevice et DoNothing. Si aucune action n'est définie pour un code de sortie donné et qu'aucun DefaultAction n'existe non plus, rien ne se passe et l'écran reste bloqué, noir : définissez donc toujours un DefaultAction. L'application elle-même doit aussi être conçue pour se terminer d'elle-même en cas d'exception non gérée, afin d'enclencher le mécanisme de reprise.

Comment le personnel de maintenance doit-il se connecter en tant qu'administrateur ?

Par défaut, l'expérience kiosque d'Assigned Access permet de sortir vers l'écran de connexion avec Ctrl+Alt+Suppr, et sous Windows 11, l'élément BreakoutSequence permet de modifier cette combinaison de touches. Dans une configuration où Keyboard Filter bloque également Ctrl+Alt+Suppr, la touche d'échappement propre à Keyboard Filter (par défaut, appuyer cinq fois de suite sur la touche Windows gauche) conserve un chemin de retour vers l'écran d'accueil. L'expérience kiosque elle-même est réservée à la console, mais une maintenance en Bureau à distance avec un compte administrateur peut être utilisée en parallèle, dans une session distincte. Il est important de ne pas bloquer toutes les issues, au risque d'obtenir un poste qui ne peut être récupéré que par une intervention sur place.

Est-il sûr d'écrire le mot de passe de la connexion automatique dans le registre ?

Ce n'est pas recommandé. Avec la méthode AutoAdminLogon de Winlogon, le mot de passe DefaultPassword reste en clair dans le registre. Le XML de configuration d'Assigned Access et de Shell Launcher comporte un élément AutoLogonAccount : en l'utilisant, Windows crée et gère lui-même un utilisateur standard local dédié pour la connexion automatique, ce qui évite d'avoir à conserver soi-même le mot de passe. Le principe est que le compte kiosque doit être un utilisateur standard local à privilèges minimaux, en évitant de réutiliser un compte de domaine. Notez également que la connexion automatique ne fonctionne pas sur un poste où une stratégie de restriction de mot de passe Exchange ActiveSync est appliquée.

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.