Quand Windows exige-t-il réellement des privilèges administrateur - UAC, zones protégées et comment le déterminer par conception

Dans les consultations liées à Windows, certains sujets reviennent souvent mélangés.

• Dans quels cas « Exécuter en tant qu’administrateur » devient-il réellement nécessaire ?
• Je suis un compte administrateur : pourquoi l’UAC continue-t-il d’apparaître ?
• L’installation exige-t-elle toujours un administrateur ?
• On veut placer l’application dans Program Files : cela signifie-t-il une élévation même à l’exécution ?
• En pratique, sur quoi joue vraiment la différence entre HKCU et HKLM ?
• Comment concevoir une application où seules « certaines opérations » ont besoin de privilèges administrateur ?

Cette question ne se résume pas simplement à « savoir si la personne est administrateur ». En réalité, elle dépend largement de l’endroit où l’on écrit, de qui est affecté par le changement, et de quelle zone protégée de l’OS on touche.

Dans cet article, nous passons en revue les situations où Windows exige des privilèges administrateur, en partant des bases de l’UAC, pour établir, à l’usage des praticiens, jusqu’où les droits d’un utilisateur standard suffisent et à partir de quand il est question d’élévation. Le contenu se fonde sur les informations officielles de Microsoft vérifiables à la date de mars 2026.¹²³⁴⁵

1. La conclusion, d’abord

Pour commencer, voici directement les conclusions pratiques.

• Sur Windows, le besoin de privilèges administrateur se décide moins par « l’opération est-elle impressionnante » que par « affecte-t-elle l’OS ou la machine entière ».¹⁴
• Un traitement confiné à votre seul profil — par exemple l’usage de %AppData%, %LocalAppData%, HKCU ou Documents — se passe généralement de privilèges administrateur.⁶⁷
• À l’inverse, un traitement qui touche la machine entière, tous les utilisateurs ou les zones protégées — par exemple Program Files, Windows, System32, les paramètres machine-wide de HKLM ou HKCR, les services Windows, les pilotes en mode noyau, le pare-feu, ou les tâches à privilège le plus élevé — a tendance à exiger des privilèges administrateur.⁴⁶⁸⁹¹⁰
• Ce qui compte ici, c’est que l’appartenance de l’utilisateur au groupe Administrators et le fait que l’application tourne actuellement avec un jeton d’accès administrateur sont deux choses distinctes. Quand l’UAC est activé, même pour un utilisateur administrateur, les processus ordinaires s’exécutent avec des droits équivalents à ceux d’un utilisateur standard, et ne s’élèvent qu’en cas de besoin.²⁶
• Installation ne signifie pas forcément administrateur. Comme pour une installation per-user qui suppose de s’installer sous %LocalAppData%, il existe des conceptions qui permettent de distribuer et de mettre à jour sans privilèges administrateur.¹¹¹²
• Une « application qui, on ne sait pourquoi, demande à chaque fois des droits administrateur » est en réalité, la plupart du temps, soit une application qui écrit des données d’exécution dans une zone protégée, soit une application dont le manifeste déclare requireAdministrator / highestAvailable.⁴¹³
• Quant à la direction future, Windows tend vers une élévation explicite uniquement au moment où elle est nécessaire. La fonctionnalité Administrator protection (preview) de Windows 11 illustre assez clairement cette tendance.⁵

En résumé, le plus pratique est de retenir que savoir si des privilèges administrateur sont nécessaires ne dépend pas du statut de l’utilisateur, mais de la limite que l’application touche.

2. Que signifie réellement « nécessiter des privilèges administrateur » ?

Le premier point à clarifier ici, c’est de penser séparément l’utilisateur et le processus.

L’UAC de Windows est une fonctionnalité de sécurité destinée à empêcher les modifications non autorisées de l’OS. Microsoft Learn explique d’ailleurs que l’UAC notifie l’utilisateur lorsqu’un changement nécessitant des autorisations de niveau administrateur est sur le point d’être effectué.¹

De plus, la documentation officielle de l’UAC précise que les applications nécessitant un jeton d’accès administrateur demandent le consentement de l’utilisateur final, et que les processus enfants héritent du jeton d’accès du processus parent, parent et enfant s’exécutant au même niveau d’intégrité.²

Deux points en découlent.

2.1 Même un « utilisateur administrateur » ne reste pas administrateur en permanence

Microsoft Learn explique que, lorsque l’UAC est activé, même les processus lancés par un membre du groupe Administrators s’exécutent avec des droits d’utilisateur standard, sauf élévation spécifique.⁶

Autrement dit :

• Votre compte Windows est administrateur
• Mais l’application que vous venez de lancer d’un double-clic n’est pas élevée
• Donc l’UAC n’apparaît qu’au moment précis d’une opération nécessitant des privilèges administrateur

est une situation tout à fait normale.

« Je suis administrateur, alors pourquoi manque-t-il encore de droits ? » est un comportement parfaitement naturel sous Windows.

2.2 Impossible de rendre « seulement ce traitement » administrateur au sein d’un même processus

L’UAC n’est pas une magie qui s’applique fonction par fonction : c’est une question de savoir sous quel jeton s’exécute le processus. Les processus enfants héritant du jeton de leur parent, il est impossible de concevoir un système où, dans un processus d’interface non élevé, certaines méthodes du même processus deviendraient administrateur au seul instant où l’on appuie sur un bouton.²

Si c’est nécessaire, il faut recourir à une unité d’exécution distincte, telle que :

• extraire un EXE séparé
• utiliser un service
• utiliser une tâche à privilège le plus élevé
• utiliser un COM élevé

¹⁴

Concevoir sans connaître ce principe de base mène presque toujours à la demande un peu délicate : « on voudrait que seul ce bouton s’exécute en administrateur ».

3. Ce qui détermine la réponse - comment le repérer, d’abord

La façon la plus simple de le déterminer repose sur ces trois questions.

1. Où écrivez-vous ?
2. Qui est affecté par ce changement ?
3. Touchez-vous quelque chose que l’OS protège ?

Sous forme de tableau de décision simplifié, cela donne :

Pour résumer de façon très schématique :

• Un changement pour soi-même se contente facilement d’un utilisateur standard
• Un changement pour tout le monde implique facilement un administrateur
• Toucher une limite de sécurité de l’OS exige un administrateur

Le simple fait de vérifier ces trois points en premier rend déjà beaucoup plus facile d’expliquer « pourquoi l’UAC apparaît ».

4. Cas typiques où les privilèges administrateur sont probablement nécessaires

4.1 Installation, mise à jour et désinstallation pour tous les utilisateurs

La documentation de Microsoft Learn sur l’architecture de l’UAC explique que de nombreux installateurs écrivent dans des répertoires système ou des clés de registre, que l’utilisateur standard n’a pas d’accès suffisant pour cela, et que Windows détecte les programmes d’installation pour demander une élévation.³

Le point important ici, c’est que ce n’est pas parce que l’installateur « a un statut particulier » que l’élévation est nécessaire, mais parce que la destination d’écriture est une zone protégée.

Typiquement, il s’agit de :

• se déployer dans Program Files
• écrire des informations machine-wide dans HKLM
• effectuer un enregistrement ou une intégration COM pour tous les utilisateurs
• installer des services ou des pilotes
• disposer d’un chemin de mise à jour à l’échelle de la machine

Ces cas ont tendance à exiger des privilèges administrateur.³⁸

4.2 Écrire des données d’exécution dans Program Files ou HKLM

Ce cas est également très fréquent. Le guide de conception de l’UAC de Microsoft explique qu’il faut éliminer les élévations inutiles, et que beaucoup de logiciels anciens nécessitent inutilement des privilèges administrateur parce qu’ils écrivent dans HKLM / HKCR ou dans les dossiers Program Files / Windows System.⁴

De plus, la documentation relative aux utilisateurs standard précise explicitement qu’ils ne peuvent pas écrire dans le dossier Program Files ni dans HKEY_LOCAL_MACHINE, ni effectuer de traitements modifiant le système.⁶

Autrement dit, si des données qui changent à l’exécution, telles que :

• fichiers de configuration
• journaux
• cache
• état propre à chaque utilisateur
• historique récent

sont placées dans le dossier d’installation ou dans HKLM, cela suffit souvent à faire de l’application une application qui « ne fonctionne pas sans être lancée en administrateur ».

Et ce n’est pas rare : ce n’est pas parce que l’application est réellement destinée à un usage administrateur, mais simplement parce que le choix de l’emplacement de stockage est mauvais.

4.3 Enregistrement ou reconfiguration de services Windows

Les services étant gérés par l’OS, il est naturel qu’on ne puisse pas les toucher à la légère.

La documentation officielle sur les droits d’accès du gestionnaire de contrôle des services explique que l’appel de CreateService nécessite SC_MANAGER_CREATE_SERVICE, et que seul un processus disposant de privilèges Administrator peut ouvrir un handle utilisable avec CreateService.⁸

Il est également précisé que SERVICE_CHANGE_CONFIG, nécessaire pour ChangeServiceConfig / ChangeServiceConfig2, ne devrait être accordé qu’aux administrateurs, car il permet de modifier l’EXE que le système exécute.⁸

Ainsi, des opérations comme :

• enregistrer un service
• modifier le fichier exécutable ou le type de démarrage d’un service
• supprimer un service
• modifier le descripteur de sécurité d’un service

supposent des privilèges administrateur.

4.4 Installer un pilote en mode noyau

Microsoft Learn explique qu’un utilisateur standard ne peut pas exécuter de tâches modifiant le système, comme l’installation d’un pilote en mode noyau.⁶

C’est une limite assez claire. Les pilotes s’exécutant côté noyau, on ne peut pas les traiter au même niveau qu’une simple « sauvegarde des paramètres d’une application utilisateur ».

• Installer un pilote de périphérique
• Installer un pilote virtuel ou un pilote de filtre
• Modifier des composants liés au démarrage ou aux E/S

On peut considérer que ce type d’opérations nécessite des privilèges administrateur.

4.5 Configuration du pare-feu ou des tâches à privilège élevé

Le pare-feu fait lui aussi partie des limites de sécurité de l’OS. La procédure de configuration du pare-feu de Microsoft Learn précise explicitement que l’utilisation de Windows Firewall with Advanced Security sur un seul appareil nécessite des droits administrateur sur cet appareil.⁹

Par ailleurs, pour le Planificateur de tâches, TASK_RUNLEVEL_LUA est défini comme le privilège minimal et TASK_RUNLEVEL_HIGHEST comme une exécution au privilège le plus élevé, et la documentation de schtasks précise également qu’il faut être membre du groupe Administrators pour planifier, consulter ou modifier toutes les tâches sur l’ordinateur local.¹⁰

En résumé, des configurations telles que :

• ajouter ou modifier une règle Windows Firewall
• enregistrer un traitement spécifique comme tâche à privilège le plus élevé
• exécuter un job sous un autre utilisateur ou sous SYSTEM

se situent du côté qui exige des privilèges administrateur.

5. Cas typiques où l’on peut souvent se passer de privilèges administrateur

On a tendance à voir Windows comme « exigeant tout de suite l’administrateur », mais en réalité, il existe bien plus de parties que l’on peut concevoir sans besoin de privilèges administrateur qu’on ne le pense.

5.1 Ses propres paramètres, cache et journaux

Microsoft Learn explique que, plutôt que de s’appuyer sur la virtualisation à des fins de compatibilité, les applications devraient enregistrer leurs données dans un emplacement per-user, ou dans un emplacement machine situé dans %alluserprofile% avec des ACL correctement configurées.⁷

En pratique, la répartition suivante permet d’y voir clair :

• Propre à l’utilisateur : %AppData%, %LocalAppData%, HKCU
• Partagé mais mis à jour à l’exécution : %ProgramData% + conception des ACL
• L’exécutable lui-même : zones protégées comme Program Files

Avec cette séparation en place, on peut avoir une installation de l’application en administrateur, mais un usage quotidien sans administrateur.

5.2 Installation et mise à jour per-user

Des exemples de déploiement per-user apparaissent couramment dans la documentation officielle de Microsoft.

Par exemple, la documentation du client Remote Desktop explique que l’installation per-user s’effectue sous le LocalAppData de chaque profil utilisateur, et que l’utilisateur peut la mettre à jour sans privilèges administrateur.¹¹

La documentation OneDrive indique quant à elle qu’il s’agit par défaut d’une installation per-user, et que l’installation per-machine s’effectue en exécutant la commande avec /allusers, ce qui déclenche une invite UAC. De plus, l’installation per-user se place sous %localappdata%, tandis que l’installation per-machine se place sous Program Files.¹²

Ce qui en ressort, c’est que le seul mot « installation » ne détermine pas si des privilèges administrateur sont nécessaires.

• Si chaque utilisateur s’installe dans son propre espace, on peut parfois se passer d’administrateur
• Si l’on s’installe dans un espace commun à tous les utilisateurs, un administrateur est plus souvent nécessaire

Ce qui compte, c’est de décider d’abord s’il s’agit de per-user ou de per-machine.

5.3 Opérations d’interface ordinaires et logique métier

À l’inverse, les traitements suivants ne nécessitent pas en eux-mêmes de privilèges administrateur.

• Ouvrir des documents ou des images
• Modifier des fichiers situés sous son propre profil
• Effectuer des communications HTTP ou avec une base de données
• Exécuter la logique métier
• Afficher des résultats à l’écran
• Lire et écrire ses propres paramètres

Si, malgré cela, il faut « exécuter toute l’application en administrateur », la cause n’est généralement pas la fonctionnalité principale de l’application, mais le fait qu’un traitement périphérique touche une zone protégée.

6. Pourquoi l’application dit-elle « exécutez-moi en administrateur » ?

6.1 Le manifeste déclare requireAdministrator

Dans le manifeste de l’application, requestedExecutionLevel permet de déclarer le niveau de privilège requis. Microsoft Learn définit les trois valeurs suivantes.¹³

• asInvoker : s’exécute avec les mêmes privilèges que le processus qui l’a lancé
• highestAvailable : s’exécute avec le privilège le plus élevé disponible
• requireAdministrator : s’exécute avec des privilèges administrateur

Si une application est configurée en requireAdministrator, l’élévation est supposée à chaque lancement. Même avec highestAvailable, l’élévation peut entrer en jeu selon l’environnement.¹³

La réponse la plus directe à « pourquoi l’UAC apparaît-il à chaque fois » est donc : parce que l’application le déclare ainsi.

6.2 L’application est repérée par la détection d’installateur de Windows

La documentation sur l’architecture de l’UAC explique que Windows dispose d’une technologie de détection d’installateur (installer detection technology), et que de nombreux programmes d’installation écrivent dans des emplacements système protégés, ce qui rend l’élévation nécessaire.³

Et ce n’est pas simplement parce qu’il s’appelle setup.exe : Windows procède dans une certaine mesure à un jugement heuristique du type « ceci ressemble à un installateur ». La documentation officielle cite les conditions suivantes.³

• exécutable 32 bits
• absence de l’attribut requestedExecutionLevel
• processus interactif lancé par un utilisateur standard avec l’UAC activé
• nom de fichier contenant des mots comme install, setup, update, etc.

Il n’est donc pas étonnant, du point de vue de la conception de Windows, que SetupLauncher.exe ou Updater.exe demandent soudainement une élévation.

6.3 Une application ancienne qui « fonctionnait par hasard » grâce à la virtualisation

C’est un point qui prête facilement à confusion.

Microsoft Learn explique que l’UAC fournit une virtualisation des fichiers et du registre pour les applications non conformes qui tentent d’écrire dans une zone protégée. D’un autre côté, il est également précisé explicitement qu’il s’agit d’une mesure de compatibilité à court terme, et non d’une solution à long terme.³⁷

De plus, la virtualisation comporte des limites.

• Elle ne s’applique pas aux applications élevées
• Elle ne s’applique qu’aux applications 32 bits
• Elle est désactivée en présence d’un manifeste contenant requestedExecutionLevel
• Les applications devraient normalement être corrigées pour écrire au bon endroit

Telles sont les conditions.³⁷

Autrement dit, une ancienne application 32 bits peut sembler « avoir pu écrire dans Program Files sans administrateur », mais il est possible que ce ne soit pas qu’elle écrivait correctement, mais simplement qu’elle était redirigée vers le VirtualStore.

C’est pourquoi, à des moments comme :

• le passage en 64 bits
• l’ajout d’un manifeste
• un changement de méthode de build
• une mise en conformité avec l’UAC

une « erreur de conception de l’emplacement de stockage » qui n’était jamais apparue auparavant peut soudainement devenir visible.

6.4 L’emplacement touché à l’exécution est tout simplement mal choisi

En pratique, c’est finalement le cas le plus fréquent.

• Enregistrer les paramètres à côté de l’EXE
• Écrire les journaux dans le dossier d’installation
• Créer des fichiers temporaires sous Program Files
• Écrire l’état propre à chaque utilisateur dans HKLM

Une telle configuration aboutit à une forme assez difficile à gérer : une application dont le corps est une interface ordinaire, mais dont le lancement exige des privilèges administrateur.⁴⁶

Les cas où c’est « administrateur parce que l’emplacement de stockage est mauvais », plutôt que « administrateur parce que l’opération est avancée », sont vraiment très nombreux.

7. Comment concevoir pour réduire les élévations inutiles

7.1 La base : asInvoker

Sauf si l’application entière est vraiment un outil d’administration système, la ligne de base consiste à faire tourner une application d’interface ordinaire sans élévation. Dans le manifeste, asInvoker est justement la déclaration « s’exécute avec les mêmes privilèges que celui qui l’a lancée ».¹³

Faire tourner en administrateur les opérations d’écran habituelles, la logique métier et jusqu’à l’enregistrement des paramètres par utilisateur multiplie les problèmes :

• la surface d’attaque s’élargit
• l’exploitation devient plus difficile à expliquer
• l’UAC apparaît à chaque fois
• on ne voit plus « quel traitement a réellement besoin d’un administrateur »

Le guide de conception de l’UAC de Microsoft explique également qu’il faut éliminer les élévations inutiles et réserver les privilèges administrateur aux seules tâches qui en ont vraiment besoin.⁴

7.2 Ne séparer que les traitements nécessitant l’administrateur dans une unité d’exécution distincte

Microsoft Learn présente explicitement des modèles permettant à une application comportant des traitements nécessitant des privilèges administrateur de continuer à tourner comme une application utilisateur standard, en ne séparant que la partie nécessaire.¹⁴

On en distingue quatre principaux.

• Administrator Broker Model Application d’interface en utilisateur standard + EXE d’aide administrateur
• Operating System Service Model Interface en utilisateur standard + service résident
• Elevated Task Model Interface en utilisateur standard + tâche planifiée au privilège le plus élevé
• Administrator COM Object Model Interface en utilisateur standard + COM élevé

La répartition sommaire est la suivante.

• Opérations administrateur occasionnelles seulement : EXE d’aide
• Constant, sans surveillance, fréquent : service
• Job de routine court : tâche highest
• COM existant supposé : COM élevé

La mise en œuvre concrète de cette conception pour les applications Windows est traitée en détail dans un autre article, Comment isoler concrètement, dans une application Windows, « uniquement les opérations nécessitant des privilèges administrateur ».

7.3 Corriger l’emplacement des données d’exécution

Le principe pour l’emplacement de stockage est plutôt simple.

• Les données propres à l’utilisateur : HKCU ou %AppData%
• Le cache strictement local : %LocalAppData%
• Les données partagées mais changeant à l’exécution : %ProgramData% + ACL
• L’exécutable lui-même : Program Files

Microsoft Learn explique également que les applications devraient enregistrer leurs données dans un emplacement per-user, ou dans %alluserprofile% (qui correspond en réalité à ProgramData) avec des ACL correctement configurées.⁷

Avec cette organisation, il devient plus facile de faire en sorte que seul l’installateur soit élevé, tandis que l’application en cours d’exécution reste non élevée.

7.4 Décider d’abord entre per-user et per-machine

C’est un point que l’on néglige étonnamment souvent.

• Chaque utilisateur devrait-il pouvoir installer l’application lui-même ?
• Doit-elle s’installer dans un emplacement unique commun à tous les utilisateurs ?
• Qui est responsable des mises à jour ?
• Est-il acceptable d’exécuter l’exécutable depuis un profil utilisateur ?

Si cette décision reste floue, la situation risque plus tard de devenir confuse, par exemple :

• administrateur seulement pour l’installation
• administrateur aussi pour l’exécution
• administrateur aussi pour les mises à jour
• seule une partie en contexte utilisateur

La différence entre per-user et per-machine n’est pas simplement une question de méthode de distribution : c’est la conception des privilèges elle-même.

8. Vers où Windows se dirige-t-il à l’avenir ?

À la date de mars 2026, Windows 11 dispose d’une fonctionnalité appelée Administrator protection (preview). Microsoft Learn la décrit comme maintenant un état déprivilégié (deprivileged state) en temps normal, et n’accordant des droits admin que just-in-time, en cas de besoin.⁵

Microsoft précise en outre qu’une authentification explicite est requise avant les opérations nécessitant des privilèges administrateur, telles que l’installation de logiciels, la modification de paramètres système comme l’heure ou le registre, ou l’accès à des données sensibles.⁵

Cette fonctionnalité est encore en preview, et son déploiement général se fait progressivement.⁵ La direction est toutefois assez claire.

• Ne pas conserver en permanence un jeton administrateur
• N’élever qu’au moment précis où c’est nécessaire
• Isoler les sessions élevées
• Rendre plus explicite « quand, quelle application, et pourquoi elle est devenue administrateur »

Autrement dit, on peut considérer que la conception consistant à « faire tourner provisoirement tout en administrateur » sera de moins en moins compatible avec Windows à l’avenir.

9. Idées reçues courantes

9.1 « Je suis un utilisateur administrateur, donc l’UAC ne devrait pas apparaître »

Il apparaît quand même. Lorsque l’UAC est activé, même un membre du groupe Administrators voit ses processus ordinaires s’exécuter sans élévation, celle-ci n’intervenant qu’en cas de besoin.⁶²

9.2 « Une installation exige forcément un administrateur »

Pas forcément. Il existe des conceptions permettant de distribuer sans privilèges administrateur, comme une installation per-user dans %LocalAppData%.¹¹¹²

9.3 « Puisqu’on la place dans Program Files, autant y enregistrer les paramètres aussi »

Non. Il faut séparer l’emplacement de l’exécutable de celui des données qui changent à l’exécution. Microsoft cite lui-même l’écriture à l’exécution dans Program Files ou HKLM comme l’exemple classique d’élévation inutile.⁴⁷

9.4 « Il suffit d’exécuter en administrateur pour que tous les problèmes de conception disparaissent »

Cela ne les résout pas. L’application peut fonctionner temporairement, mais la surface d’attaque, l’exploitabilité, la distribution et la facilité de support ont tendance à se dégrader. De plus, il est impossible d’élever commodément une seule partie d’un même processus.²¹⁴

9.5 « Ça fonctionnait avant, donc c’est encore correct aujourd’hui »

Pas nécessairement. Si une ancienne application 32 bits « fonctionnait par hasard » grâce à la virtualisation, le problème refait surface lors du passage en 64 bits ou de l’ajout d’un manifeste. La virtualisation est une mesure provisoire pour la compatibilité, pas une solution à long terme.³⁷

10. Résumé

En un mot, le besoin de privilèges administrateur sous Windows se décide selon « où l’on va changer quoi ».

• Un changement pour soi-même : un utilisateur standard suffit généralement
• Un changement pour tous les utilisateurs / la machine entière : un administrateur est probablement nécessaire
• Toucher une zone protégée ou une limite de sécurité de l’OS : des privilèges administrateur sont requis

Et ce qui compte vraiment en pratique, c’est de distinguer les traitements qui ont réellement besoin de privilèges administrateur des traitements qui n’en ont besoin que par la faute d’un mauvais choix d’emplacement de stockage.

En particulier dans le développement d’applications Windows, les principes suivants sont très efficaces.

• Garder l’interface non élevée par défaut
• Séparer les traitements administrateur dans un EXE / service / tâche distinct
• Rapprocher les données d’exécution du côté AppData / HKCU / ProgramData
• Décider per-user / per-machine dès le départ

« A-t-on besoin de privilèges administrateur » n’est pas une question de prestige de l’application. C’est une question de quelle limite de l’OS l’on touche.

Adopter ce point de vue dès le départ rend nettement plus lisibles le comportement de l’UAC, le choix de la méthode d’installation et la conception de l’application.

11. Articles liés

• Comment isoler concrètement, dans une application Windows, « uniquement les opérations nécessitant des privilèges administrateur »
• Liste de contrôle minimale de sécurité pour le développement d’applications Windows
• Comment choisir une méthode de distribution pour une application Windows - Tableau de décision MSI / MSIX / ClickOnce / xcopy / updater personnalisé

12. 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.

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.

Pourquoi l'UAC apparaît-il alors que je suis connecté en tant qu'administrateur ?

Parce qu'appartenir au groupe Administrators et faire tourner une application avec un jeton d'accès administrateur sont deux choses différentes. Lorsque l'UAC est activé, même les processus lancés par un membre du groupe Administrators s'exécutent avec des droits équivalents à ceux d'un utilisateur standard, à moins d'être explicitement élevés ; l'invite n'apparaît donc qu'au moment précis d'une opération nécessitant des privilèges administrateur. C'est un comportement normal, voulu par la conception de Windows, et non le signe d'une mauvaise configuration.

Quelles opérations exigent réellement des privilèges administrateur sous Windows ?

Ce qui compte, c'est de savoir si le changement affecte l'OS ou la machine entière, pas à quel point l'opération semble impressionnante. Écrire dans des zones protégées comme Program Files, Windows, System32, HKLM ou HKCR, installer pour tous les utilisateurs, enregistrer ou reconfigurer des services Windows, installer des pilotes en mode noyau, modifier des règles du pare-feu Windows, ou exécuter des tâches planifiées au niveau de privilège le plus élevé : tout cela relève du côté administrateur. Un traitement confiné à votre propre profil — AppData, LocalAppData, HKCU, Documents — ne nécessite normalement aucun privilège administrateur, et une installation per-user dans LocalAppData peut éviter toute élévation.

Pourquoi mon application réclame-t-elle « Exécuter en tant qu'administrateur » à chaque démarrage ?

En général, l'une de trois causes. Le manifeste déclare peut-être requireAdministrator ou highestAvailable dans requestedExecutionLevel, ce qui suppose une élévation dès le lancement. La détection d'installateur de Windows peut aussi repérer l'exécutable de façon heuristique — par exemple un EXE 32 bits interactif sans requestedExecutionLevel, dont le nom contient des mots comme install, setup ou update. Le plus souvent, l'application écrit simplement des données d'exécution — paramètres, journaux, cache — dans une zone protégée comme le dossier d'installation ou HKLM, ce qui signifie que c'est l'emplacement de stockage qui est mal choisi, et non que l'application soit véritablement un outil d'administration.

Comment concevoir une application où seules certaines opérations nécessitent des droits administrateur ?

Il est impossible d'élever une seule méthode à l'intérieur d'un même processus, car l'UAC fonctionne au niveau du jeton du processus, et les processus enfants héritent du jeton du parent. Les modèles documentés par Microsoft séparent la partie privilégiée dans sa propre unité d'exécution : un EXE d'aide de type « courtier administrateur » (administrator broker) pour des opérations occasionnelles, un service résident pour un travail constant ou sans surveillance, une tâche planifiée au niveau de privilège le plus élevé pour de courts travaux de routine, ou un COM élevé lorsqu'un COM existant est déjà en place. Gardez l'interface utilisateur en asInvoker et stockez les données d'exécution dans AppData, HKCU ou ProgramData, afin que l'usage quotidien reste non élevé.

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.