Introduction aux profils utilisateur Windows - AppData et NTUSER.DAT

Cet article est rédigé comme un panorama général à l’intention des équipes informatiques qui administrent Windows, des responsables du déploiement de postes, et des développeurs d’applications Windows. Les schémas sont conceptuels. Dans les environnements Markdown compatibles Mermaid, ils s’affichent sous forme de diagrammes.

Le contenu s’appuie sur la documentation officielle de Microsoft telle que nous avons pu la vérifier en avril 2026. [1][4][7][10][13][14]

Dans les échanges autour de Windows, le mot « profil » est employé dans un sens très large.

• Que contient réellement C:\Users\<nom d'utilisateur> ?
• Comment bien répartir l’usage de %AppData% et %LocalAppData% ?
• Qu’est-ce qu’un profil itinérant dans un environnement de domaine ?
• Quelle est la différence entre un profil Mandatory et un profil Temporary ?
• Que choisir pour un PC partagé, RDS, VDI ou Azure Virtual Desktop ?
• Quand un profil est cassé, par où commencer à regarder ?

Sur ce terrain, le compte, les dossiers, le registre, le mode de synchronisation et la politique d’exploitation se mélangent tous à la fois, si bien que la discussion part vite dans tous les sens.

Dans cet article, nous posons d’abord une vision du profil utilisateur Windows comme un unique schéma de conception, puis nous parcourons dans l’ordre l’usage d’AppData, l’itinérance, Mandatory, Temporary, FSLogix, et la façon d’aborder les incidents.

1. La conclusion d’abord

Avant d’entrer dans le détail, voici d’abord les conclusions pratiques.

• Un profil utilisateur Windows n’est pas simplement le dossier C:\Users\<nom d'utilisateur>. C’est un ensemble composé de fichiers + une ruche de registre utilisateur (NTUSER.DAT). [1]
• Sur un PC local ordinaire, un profil local est créé par défaut. Lors de la première connexion, un nouveau profil est créé à partir de C:\Users\Default comme base. [11][12]
• Il vaut mieux ne pas choisir l’emplacement de stockage d’une application au hasard : la règle de base est que les paramètres que l’on veut faire suivre par utilisateur vont dans %APPDATA%, et le cache ou l’état temporaire propres à ce PC vont dans %LOCALAPPDATA%. [2][3]
• Le profil itinérant est un mécanisme qui « déplace le profil entier vers un partage », tandis que Folder Redirection est un mécanisme qui « déplace uniquement des dossiers connus comme Documents vers un autre emplacement » - ce n’est pas la même chose. [4][5]
• Le profil Mandatory est un profil en lecture seule destiné à « laisser l’utilisateur travailler sans enregistrer ses modifications ». Le profil Temporary est une solution de secours en cas d’erreur, conçue pour disparaître à chaque fois. [7][8][9]
• Les profils itinérants qui traversent plusieurs générations d’OS demandent de la prudence. Windows 10 / Server 2016 et versions ultérieures sont incompatibles avec les versions antérieures, et il faut envisager de séparer les versions de profil en conséquence. [6]
• Pour RDS / VDI / Azure Virtual Desktop, plutôt que de s’en tenir uniquement aux profils itinérants traditionnels, il y a de nombreux cas où il vaut mieux envisager en premier lieu les conteneurs de profil FSLogix. Microsoft recommande d’ailleurs FSLogix pour Azure Virtual Desktop. [13][14]
• En cas d’incident, plutôt que de toucher immédiatement à C:\Users, il est plus judicieux de regarder d’abord le journal Application, les journaux Operational / Diagnostic de User Profile Service, le chemin de partage, ainsi que les attributs et les droits de NTUSER.DAT / USRCLASS.DAT. [10][11][16]

En somme, la question du profil Windows se résume à « où placer quoi, jusqu’où le faire suivre, et comment revenir en arrière en cas d’échec ».

2. Qu’est-ce qu’un « profil utilisateur » Windows, au juste ?

Pour commencer, les choses deviennent plus simples si l’on distingue le compte et le profil.

flowchart LR
    A[Compte utilisateur<br/>qui se connecte] --> B[Profil utilisateur<br/>les paramètres et données de cette personne]
    C[Appareil / OS] --> B
    B --> D[Paramètres du bureau]
    B --> E[AppData]
    B --> F[Documents / Desktop, etc.]
    B --> G[Paramètres visibles sous HKCU]

• Le compte identifie qui est la personne
• Le profil est la réalité concrète de l’environnement de travail de cette personne
• L’appareil est l’endroit où ce profil est chargé et utilisé

Microsoft Learn explique également qu’un profil utilisateur comprend les dossiers de profil sur le système de fichiers et la ruche de registre NTUSER.DAT, et que cette ruche est chargée à la connexion pour être utilisée comme HKEY_CURRENT_USER. [1]

2.1 Pas « seulement des dossiers » - le registre en fait partie aussi

C’est le point important.

flowchart TD
    A[Connexion] --> B[Identifier le dossier de profil]
    B --> C[Charger NTUSER.DAT]
    C --> D[Utiliser comme HKCU]
    B --> E[Préparer Desktop / Documents / AppData]
    D --> F[Les paramètres utilisateur prennent effet]
    E --> F

Autrement dit, si l’on ne regarde que C:\Users\<nom d'utilisateur>, on n’en voit encore que la moitié.

Un profil Windows comporte globalement deux couches.

1. La couche fichiers Desktop, Documents, Downloads, AppData, etc.
2. La couche registre HKCU, alimenté par le NTUSER.DAT chargé

Ce qui rend les discussions sur la corruption de profil compliquées, c’est qu’il existe des cas où seul le côté dossier est cassé et des cas où le problème se situe du côté de la ruche de registre. [1][11]

2.2 À la première connexion, Default sert de base

Lorsqu’un nouvel utilisateur se connecte pour la première fois à ce PC, Windows crée un profil local à partir de C:\Users\Default. [11]

flowchart LR
    A[C:\Users\Default] --> B[Première connexion]
    B --> C[Génère C:\Users\nom d'utilisateur]
    C --> D[Charge NTUSER.DAT]
    D --> E[Devient l'environnement propre à cet utilisateur]

Si l’on traite ce point à la légère dans un contexte de déploiement d’image ou de préparation de postes, cela devient ensuite assez pénible.

Microsoft explique que, pour la personnalisation du profil par défaut, la méthode prise en charge consiste à utiliser CopyProfile. Une copie manuelle ou une duplication grossière à l’ancienne peut introduire des informations superflues et provoquer des problèmes de stabilité pour les applications ou le système. [12]

3. Comment lire C:\Users\<nom d'utilisateur>

Vu du côté des dossiers, un profil utilisateur présente à peu près cette structure.

flowchart TD
    A["C:\Users\nom d'utilisateur"] --> B[Desktop]
    A --> C[Documents]
    A --> D[Downloads]
    A --> E[Pictures]
    A --> F[AppData]
    A --> G[NTUSER.DAT]
    F --> H[Roaming]
    F --> I[Local]
    F --> J[LocalLow]

En pratique, voici à peu près les premiers endroits que l’on regarde.

3.1 Considérer AppData comme trois zones distinctes

C’est ici que la confusion survient le plus facilement, en développement d’applications Windows comme en investigation d’incidents.

Le guide de Microsoft recommande d’utiliser FOLDERID_RoamingAppData (Roaming AppData) pour les données propres à l’application, et FOLDERID_LocalAppData pour les fichiers temporaires et les données non utilisées sur d’autres ordinateurs. [2]

Par ailleurs, dans les définitions des Known Folders, les chemins par défaut sont organisés comme suit. [3]

• %APPDATA% = %USERPROFILE%\AppData\Roaming
• %LOCALAPPDATA% = %USERPROFILE%\AppData\Local
• LocalLow = %USERPROFILE%\AppData\LocalLow

flowchart LR
    A[AppData] --> B[Roaming]
    A --> C[Local]
    A --> D[LocalLow]

    B --> B1[Paramètres à faire suivre]
    B --> B2[État utilisateur de petite taille]

    C --> C1[Cache]
    C --> C2[Données régénérables]
    C --> C3[État propre à ce PC]

    D --> D1[Usages particuliers]

Comment trancher en pratique

ProgramData est également défini, dans les définitions des dossiers connus de Microsoft, comme des données d’application destinées à tous les utilisateurs, prévues pour des données partagées qui ne sont pas mises en itinérance. [3]

Ce qu’il faut surtout éviter ici, c’est de placer des données d’exécution propres à un utilisateur dans Program Files. Cela a tendance à faire s’effondrer d’un coup à la fois l’organisation du profil et la conception des droits d’accès.

3.2 Public et Default ont des rôles différents

C’est un autre point où la confusion est facile.

flowchart LR
    A["C:\Users"] --> B[Default]
    A --> C[Public]
    A --> D[Chaque utilisateur]

    B --> B1[Modèle de création des nouveaux profils]
    C --> C1[Éléments partagés visibles par tous les utilisateurs]
    D --> D1[Données propres à chaque utilisateur]

• Default est le modèle utilisé pour créer les nouveaux profils
• Public est la zone partagée visible par tous les utilisateurs
• Le dossier de chaque utilisateur contient les données propres à cette personne

Ces trois éléments se ressemblent en apparence, mais leurs rôles sont totalement différents.

4. Les différents types de profils

Même si l’on parle d’un seul mot, « profil », il existe en exploitation au moins les types suivants.

flowchart TD
    A[Profils Windows] --> B[Profil local]
    A --> C[Profil itinérant]
    A --> D[Profil Mandatory]
    A --> E[Profil Temporary]
    A --> F[Conteneur de profil FSLogix]

4.1 Profil local

Sur un PC ordinaire, c’est le type par défaut.

• Créé sur le disque local de ce PC
• Ne voyage pas automatiquement vers d’autres PC
• La solution la plus simple pour un PC autonome

Microsoft explique également que, par défaut, Windows crée un profil utilisateur local. [14]

4.2 Profil itinérant

Microsoft Learn décrit le profil utilisateur itinérant comme un mécanisme stocké sur un partage serveur, qui permet de recevoir les mêmes paramètres d’OS / d’application sur plusieurs ordinateurs. [4][5]

flowchart LR
    A[Profil sur un serveur partagé] <--> B[PC-A]
    A <--> C[PC-B]
    A <--> D[PC-C]

Toutefois, en pratique, il faut prêter attention aux points suivants.

• La copie et la synchronisation à la connexion / déconnexion ont tendance à devenir lourdes
• C’est pénible si AppData\Local contient de grandes quantités de données
• Sensible aux problèmes liés aux différences de version d’OS
• Fortement affecté par le chemin de partage et la qualité du réseau

4.3 Profil Mandatory

Un profil Mandatory est un « profil itinérant qui n’enregistre pas les modifications », créé par un administrateur. [7][8]

Selon Microsoft, avec un profil Mandatory, même si l’utilisateur effectue des modifications pendant la session, celles-ci ne sont pas enregistrées comme elles le seraient avec un profil itinérant classique. [7]

De plus, la documentation Win32 explique que :

• renommer NTUSER.DAT en NTUSER.MAN rend le profil Mandatory
• ajouter .man à la fin du nom du dossier du chemin de profil le rend Super-mandatory

[8]

flowchart LR
    A[Profil préparé par l'administrateur] --> B[L'utilisateur se connecte]
    B --> C[Les modifications sont possibles pendant l'utilisation]
    C --> D[Déconnexion]
    D --> E[Les modifications ne sont pas enregistrées]

Cela convient par exemple aux usages suivants.

• Postes éducatifs
• Postes d’accueil
• Kiosques
• Postes partagés que l’on veut remettre à l’état propre à chaque fois

4.4 Profil Temporary

Un profil Temporary n’est pas un choix de conception ; c’est la solution de repli qui apparaît lorsque le profil réel ne peut pas être chargé à cause d’une erreur. [9]

Microsoft Learn explique qu’un profil Temporary est émis lorsqu’une condition d’erreur empêche le chargement du profil réel, qu’il est supprimé à la fin de la session, et que les modifications sont perdues. [9]

flowchart TD
    A[Début du chargement du profil normal] --> B{Le chargement réussit-il}
    B -->|Oui| C[Connexion normale]
    B -->|Non| D[Connexion avec un profil Temporary]
    D --> E[Le travail est possible]
    E --> F[Modifications perdues à la déconnexion]

Autrement dit, fonctionner avec un profil Temporary est en soi le signe d’une anomalie.

4.5 Conteneur de profil FSLogix

FSLogix est décrit par Microsoft Learn comme un mécanisme qui rend cohérente l’expérience du profil utilisateur Windows dans les environnements de bureau virtuel. [13]

Le conteneur de profil FSLogix est une approche où le profil utilisateur entier est conservé sous forme de VHD / VHDX, attaché à la connexion, et présenté comme s’il s’agissait d’un profil natif. [13][14]

flowchart LR
    A[Profil sur VHD / VHDX] --> B[Attaché à la connexion]
    B --> C[Apparaît comme C:\Users\utilisateur sur l'hôte de session]
    C --> D[Détaché à la déconnexion]

Pour Azure Virtual Desktop, Microsoft recommande l’utilisation des FSLogix profile containers. [14]

5. Quelle est la différence entre profil itinérant, Folder Redirection et FSLogix ?

Ces trois éléments sont souvent évoqués comme s’il s’agissait de la même chose, mais leurs rôles diffèrent.

flowchart TD
    A[Faire suivre l'état utilisateur] --> B[Profil itinérant]
    A --> C[Folder Redirection]
    A --> D[FSLogix]

    B --> B1[Le profil entier vers un partage]
    C --> C1[Seuls les dossiers connus vers un autre emplacement]
    D --> D1[Attacher un VHD/VHDX]

En s’appuyant sur la manière dont Microsoft Learn les présente, il est plus simple de voir les différences ainsi. [4][5][14]

5.1 Folder Redirection ne déplace que « les dossiers connus »

Selon Microsoft Learn, Folder Redirection est un mécanisme qui fait pointer le chemin d’un known folder vers un autre emplacement. [4]

Par exemple, si l’on redirige Documents vers un partage de fichiers, l’utilisateur le voit comme s’il était local, alors que les données réelles se trouvent ailleurs. [4]

flowchart LR
    A[Documents] --> B[Les données réelles sont sur un partage de fichiers]
    C[Desktop] --> D[Configuration séparée si nécessaire]
    E[AppData] --> F[Inchangé ou approche différente]

Autrement dit, Folder Redirection n’est pas un substitut au profil entier, mais un repositionnement dossier par dossier.

5.2 Ne pas mélanger à la légère les profils itinérants entre générations d’OS

Microsoft explique que les profils itinérants de Windows 10 / Server 2016 et versions ultérieures sont incompatibles avec les versions antérieures de Windows. [6]

flowchart LR
    A[Génération Windows 7 / 8.1] -.attention au mélange.-> B[Même partage]
    C[Windows 10 / Server 2016 et versions ultérieures] -.attention au mélange.-> B
    B --> D[Cause d'incohérences / menu Démarrer défaillant / barre des tâches défaillante]

Ce qui compte ici, c’est :

• Séparer les versions de profil par génération d’OS
• Ne pas se dire « c’est le même utilisateur, donc le même dossier convient »
• Pour un déploiement ou un renouvellement de postes, intégrer la compatibilité des profils au plan de migration

[6]

6. Les emplacements de stockage que développeurs et responsables d’exploitation doivent décider en premier

La question du profil revient toujours au même point : quoi placer où.

flowchart TD
    A[Données à stocker] --> B{Est-ce un livrable créé par l'utilisateur}
    B -->|Oui| C[Documents, etc.]
    B -->|Non| D{Est-ce propre à ce PC}
    D -->|Oui| E[%LOCALAPPDATA%]
    D -->|Non| F{Est-ce un paramètre par utilisateur}
    F -->|Oui| G[%APPDATA%]
    F -->|Non| H{Est-ce une donnée modifiable partagée par tous les utilisateurs}
    H -->|Oui| I[ProgramData + ACL]
    H -->|Non| J[Reconsidérer l'emplacement]

6.1 Séparer les fichiers créés par l’utilisateur de l’état interne de l’application

Si l’on mélange ces deux catégories, les sauvegardes comme les migrations deviennent fragiles.

• Les livrables que l’utilisateur manipule consciemment Documents, Pictures, dossiers de sauvegarde métier
• L’état interne de l’application Paramètres, cache, miniatures, informations de session, fichiers de travail

Le premier est une donnée métier, le second existe pour la commodité de l’application. Même si les deux sont des « fichiers », mieux vaut les traiter séparément.

6.2 Ce que l’on place dans %APPDATA%

On y place généralement ce qui suit.

• Des paramètres de petite taille
• Des préférences par utilisateur
• Un état que l’on veut voir identique sur plusieurs postes
• Ce qui peut voyager avec le profil sans problème

La documentation Fast User Switching indique elle aussi FOLDERID_RoamingAppData comme emplacement pour les données propres à l’application. [2]

6.3 Ce que l’on place dans %LOCALAPPDATA%

Ce que l’on veut placer ici est ce qui doit rester local, du point de vue de la régénération et de la portabilité.

• Cache régénérable
• État qui n’a de sens que localement
• Gros fichiers de travail
• Ce que l’on ne veut pas faire voyager pour des raisons de performance

Dans les définitions des Known Folders également, LocalAppData correspond à %USERPROFILE%\AppData\Local. [3]

6.4 Ce que l’on place dans ProgramData

Les données communes à tous les utilisateurs mais qui changent pendant l’exécution sont candidates pour ProgramData. [3]

Par exemple :

• Dictionnaires partagés
• Fichiers de définition communs à tous les utilisateurs
• Données modifiables partagées entre un service et plusieurs utilisateurs

Cependant, il faut ici réfléchir en incluant la conception des ACL. Plutôt que de se dire « c’est partagé, donc autant mettre ça dans ProgramData », l’important est de décider qui lit et qui écrit.

6.5 Quand on veut personnaliser le profil par défaut

Dans un déploiement d’image, il est courant de vouloir « appliquer les mêmes paramètres initiaux à tous les nouveaux utilisateurs ». Dans ce cas, il est plus sûr de construire cela avec la méthode basée sur CopyProfile prise en charge par Microsoft, plutôt que de toucher Default à la légère. [12]

flowchart LR
    A[Configuration initiale avec un compte administrateur] --> B[Sysprep + CopyProfile]
    B --> C[Appliqué au profil Default]
    C --> D[Appliqué aux nouveaux utilisateurs suivants]

Une méthode telle que « copier manuellement C:\Users\A d’un PC vers Default sur un autre PC » peut sembler rapide, mais elle finit souvent par tout casser plus tard. [12]

7. Comment aborder un profil cassé, devenu temporaire, ou qui ne se synchronise pas

C’est le point le plus délicat sur le terrain. De plus, les symptômes se ressemblent, si bien qu’un tri approximatif conduit facilement à s’enfoncer dans une mauvaise piste.

7.1 Commencer par répartir les symptômes en trois catégories

flowchart TD
    A[Semble être un problème de profil] --> B{La connexion est-elle possible}
    B -->|Oui| C{Tout semble-t-il réinitialisé}
    B -->|Non| D[Catégorie échec de chargement]
    C -->|Oui| E[Temporary / corrompu / profil différent]
    C -->|Non| F{Seuls certains paramètres reviennent-ils en arrière}
    F -->|Oui| G[Catégorie itinérance / redirection / synchronisation]
    F -->|Non| H[Possible problème propre à une application]

Globalement, il existe trois grandes catégories.

1. Échec à la connexion
2. La connexion réussit, mais tout semble réinitialisé
3. Seule une partie ne se synchronise pas

7.2 Les journaux à consulter en premier

Microsoft Learn recommande, pour investiguer les problèmes de profil, de regarder dans l’ordre suivant. [10]

1. Le journal Application
2. Le journal Operational de User Profile Service
3. Si nécessaire, le journal Diagnostic
4. Si besoin d’aller plus loin, les traces ETL

Les chemins concrets sont les suivants. [10]

• Event Viewer Applications and Services Logs > Microsoft > Windows > User Profile Service > Operational
• Pour voir plus de détails ... > User Profile Service > Diagnostic

flowchart LR
    A[Journal Application] --> B[Journal Operational]
    B --> C[Journal Diagnostic]
    C --> D[Trace ETL]

Sur le terrain, plutôt que de se lancer d’emblée dans la réparation du registre ou la suppression de dossiers, il est plus sûr de d’abord se faire une idée de la direction à partir des journaux : « échec de chargement », « échec de copie », « accès refusé », « chemin trop long », « impossible d’écrire sur le partage », etc.

7.3 Causes fréquentes

Attributs et droits de NTUSER.DAT / USRCLASS.DAT

Microsoft explique que si NTUSER.DAT ou USRCLASS.DAT est marqué Read-only, ou si les droits d’accès requis manquent, le chargement du profil peut échouer. [11]

C’est discret, mais si on le néglige, cela peut faire traîner l’investigation en longueur.

flowchart LR
    A[Chargement du profil] --> B{L'accès aux fichiers DAT est-il possible}
    B -->|Non| C[Échec de connexion / bureau initial / Temporary]
    B -->|Oui| D[Chargement normal]

Chemins trop longs lors de la copie en itinérance

Un article de la base de connaissances Microsoft décrit un cas où le nom du serveur ou du partage côté chemin de partage est long, ce qui rend le chemin de destination global trop long et fait basculer vers un profil temporaire, avec l’Event ID 1509. [16]

Cela ressemble à une simple contrainte de longueur de chemin, mais en réalité, la cause peut résider dans la conception même de la destination d’itinérance.

Informations de registre / dossier restantes après une suppression incomplète

Microsoft propose un article avec des scripts d’exemple pour nettoyer les informations orphelines restées dans le registre et dans C:\Users, afin d’éviter les profils TEMP. [15]

Cela montre bien que supprimer uniquement le dossier ne suffit pas.

flowchart LR
    A[Suppression grossière d'un ancien profil] --> B[Les informations de registre subsistent]
    B --> C[Incohérence à la prochaine connexion]
    C --> D[Cause de profils TEMP ou de dossiers supplémentaires]

7.4 Que vérifier en premier

8. Quelle approche choisir ?

Il n’y a pas ici « une seule bonne réponse ». Cela dépend du mode d’utilisation.

flowchart TD
    A[Mode d'utilisation] --> B[PC à usage personnel]
    A --> C[PC professionnel joint à un domaine]
    A --> D[PC partagé / poste éducatif]
    A --> E[RDS / VDI / AVD]

    B --> B1[Principalement local]
    C --> C1[Folder Redirection / itinérance selon les besoins]
    D --> D1[Mandatory / Shared PC / nettoyage]
    E --> E1[FSLogix comme premier choix]

8.1 PC à usage personnel

En principe, un profil local suffit.

• Les paramètres utilisateur dans AppData
• Les livrables dans Documents
• Si nécessaire, synchronisation des documents via une couche séparée telle que OneDrive

Cette configuration est la plus simple.

8.2 PC professionnel joint à un domaine

Selon les exigences, on combine les éléments suivants.

• Vous voulez gérer les documents de façon centralisée → Folder Redirection
• Vous voulez avoir les mêmes paramètres sur plusieurs PC → Profil itinérant
• Mélange d’OS ou profils volumineux → conception prudente, ou remise en question de l’approche

Microsoft Learn indique également que Folder Redirection et Roaming User Profiles sont utiles pour la centralisation, l’utilisation hors ligne et la facilitation des sauvegardes. [4]

8.3 PC partagés / postes éducatifs / kiosques

Pour cet usage, revenir à un état propre à chaque fois compte davantage que « conserver la personnalisation individuelle ».

Il y a trois candidats.

• Profil Mandatory
• Mode Shared PC
• Politique de suppression automatique des anciens profils

Microsoft dispose d’une politique nommée Delete user profiles older than a specified number of days on system restart, qui permet de supprimer au redémarrage les profils inutilisés depuis un nombre de jours donné. [17]

Le guide Shared PC présente également une approche combinant la gestion et la suppression automatiques des comptes / profils sur les postes partagés. [18]

8.4 RDS / VDI / Azure Virtual Desktop

Dans ce contexte, les profils itinérants traditionnels seuls sont souvent insuffisants.

Microsoft recommande les FSLogix profile containers pour Azure Virtual Desktop, et explique qu’un VHDX / VHD est attaché à la connexion et traité comme un profil utilisateur natif. [14]

flowchart LR
    A[Plusieurs hôtes de session] --> B[Stockage partagé]
    B --> C[Profil utilisateur sur VHDX]
    C --> D[Attaché à l'hôte connecté]

Dans les conditions suivantes en particulier, il vaut vraiment la peine d’envisager FSLogix en premier.

• L’hôte de session change à chaque fois
• Utilisation d’Outlook / OneDrive / Microsoft 365
• VDI non persistant où le transport du profil est indispensable
• Les délais de connexion des profils itinérants posent problème

9. Idées reçues courantes

9.1 « Si l’on crée un compte, le même profil est utilisé partout »

Ce n’est pas le cas. Le compte est un identifiant, et le profil est la réalité concrète du côté de l’appareil. Jusqu’où il voyage dépend de l’approche choisie : local, itinérant, Folder Redirection, FSLogix, etc. [4][14]

9.2 « Copier C:\Users\<nom d'utilisateur> suffit pour migrer »

Une copie grossière est dangereuse.

• Compatibilité de version d’OS
• NTUSER.DAT
• Droits d’accès
• État propre à l’application
• Mélange avec le profil par défaut

en sont la cause. En particulier pour l’itinérance entre générations d’OS différentes, Microsoft lui-même part du principe d’une séparation des versions de profil. [6]

9.3 « Mandatory et Temporary, c’est à peu près pareil »

Ce sont deux choses distinctes. Mandatory est un profil en lecture seule créé intentionnellement par un administrateur, tandis que Temporary est la solution de repli utilisée lorsqu’une erreur empêche de lire le profil réel. [8][9]

9.4 « Si l’on veut synchroniser, il suffit de tout mettre dans Roaming »

C’est risqué. Si l’on met les paramètres et un cache volumineux dans la même boîte, la connexion / déconnexion et la gestion en cas d’incident deviennent lourdes. Il est plus facile à exploiter de séparer ce que l’on veut mettre en Roaming de ce qui doit rester confiné en Local. [2][3]

9.5 « Même en profil temporaire, autant continuer à l’utiliser »

Mieux vaut éviter cela. Un profil Temporary est conçu pour disparaître à la déconnexion, donc si l’on continue de travailler dans cet état, on risque de placer des données importantes dans un endroit qui va ensuite disparaître. [9]

10. Résumé

Un profil utilisateur Windows n’est pas simplement un mot désignant les dossiers sous C:\Users.

• Les fichiers
• Le registre utilisateur, centré sur NTUSER.DAT
• L’approche d’exploitation : où se trouve ce profil, comment il se synchronise, et comment il est supprimé

En considérant tout cela comme une seule et même conception, la vision d’ensemble devient plus claire.

Voici les six points à retenir en priorité en pratique.

• Pour un PC autonome, prendre d’abord le profil local comme référence
• Séparer l’emplacement de stockage des applications entre Roaming / Local / ProgramData
• Dans un environnement de domaine, ne pas confondre le profil itinérant et Folder Redirection
• Pour les postes partagés, envisager Mandatory / le nettoyage / Shared PC
• Pour RDS / VDI / AVD, placer FSLogix en tête des candidats
• En cas de panne, regarder d’abord les journaux de User Profile Service

En fin de compte, la conception d’un profil ne consiste pas à décider « où enregistrer », mais « ce qui appartient à qui, et jusqu’où cela doit voyager ». Une fois ce point posé, le déploiement des postes, la conception des applications Windows et l’investigation des incidents deviennent tous nettement plus faciles.

11. 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
• Accélérer la validation des applications avec Windows Sandbox

12. Services liés à cette thématique

Développement d’applications Windows

La manière de répartir les emplacements de stockage pour les paramètres utilisateur, les journaux, le cache et les données partagées a un impact majeur sur l’exploitabilité et la maintenabilité d’une application Windows. Si vous souhaitez couvrir tout le parcours, de la clarification des exigences jusqu’à la conception, l’implémentation et l’exploitation à long terme, ce sujet s’inscrit naturellement dans le cadre du développement d’applications Windows.

Voir le service / Nous contacter

Conseil technique et revue de conception

Le choix entre local / itinérant / FSLogix, la manière de faire évoluer l’exploitation des postes existants, et la façon de découper les emplacements de stockage font une réelle différence lorsqu’ils sont clarifiés avant l’implémentation. Si vous souhaitez repartir de la sélection de l’approche et de la conception des frontières, ce sujet se prête bien à être traité comme un conseil technique et une revue de conception.

Voir le service / Nous contacter

Investigation de bugs et analyse des causes

Le basculement en profil Temporary, les échecs de connexion, les échecs d’enregistrement à la déconnexion et le tri des problèmes liés au chemin de partage se prêtent très bien à une investigation de bugs. C’est un point d’entrée pour une consultation lorsque vous voulez cerner, à partir des journaux, des événements, des droits d’accès et de la configuration de partage, des problèmes de profil difficiles à reproduire.

Voir le service / Nous contacter

13. Références

1. Microsoft Learn, About User Profiles (Windows) Les éléments constitutifs d’un profil utilisateur, NTUSER.DAT, et les bases du profil Temporary.

2. Microsoft Learn, Fast User Switching La répartition entre FOLDERID_RoamingAppData pour les données propres à l’application et FOLDERID_LocalAppData pour les données non utilisées sur d’autres ordinateurs.

3. Microsoft Learn, KNOWNFOLDERID, CSIDL Les définitions des dossiers connus tels que %APPDATA%, %LOCALAPPDATA%, LocalLow et ProgramData.

4. Microsoft Learn, Folder Redirection and Roaming User Profiles in Windows and Windows Server La différence entre Folder Redirection et Roaming User Profiles, et la logique de gestion centralisée.

5. Microsoft Learn, Deploy roaming user profiles Les étapes pratiques de déploiement des profils itinérants : droits de partage, GPO et gestion des versions.

6. Microsoft Learn, Roaming user profiles of earlier versions of Windows are incompatible with Windows 10, Windows Server 2016, and later versions L’incompatibilité entre générations d’OS et la gestion des versions de profil.

7. Microsoft Learn, Create mandatory user profiles L’usage et la méthode de création d’un Mandatory user profile.

8. Microsoft Learn, Mandatory User Profiles Les définitions de NTUSER.MAN et du Super-mandatory profile.

9. Microsoft Learn, Temporary User Profiles La définition et les caractéristiques du Temporary profile.

10. Microsoft Learn, Troubleshoot user profiles with events Le tri à l’aide des journaux Application / Operational / Diagnostic.

11. Microsoft Learn, Error occurs during desktop setup and desktop location is unavailable when you log on to Windows for the first time La création d’un nouveau profil à partir de C:\Users\Default, et les problèmes d’attributs / de droits d’accès de NTUSER.DAT / USRCLASS.DAT.

12. Microsoft Learn, Customize the default local user profile when you prepare an image of Windows La méthode prise en charge pour personnaliser le profil par défaut à l’aide de CopyProfile.

13. Microsoft Learn, What is FSLogix, Types of Containers Les bases de FSLogix et la logique du Profile Container.

14. Microsoft Learn, User profile management for Azure Virtual Desktop with FSLogix profile containers, Configure profile containers using FSLogix La recommandation pour Azure Virtual Desktop, et l’approche de conteneur de profil à l’aide de VHD / VHDX.

15. Microsoft Learn, Scripts: Clean up profile folder information and prevent TEMP user profiles from being created Le lien entre les informations de profil orphelines et les profils TEMP.

16. Microsoft Learn, User profile cannot be loaded with Event ID 1509: DETAIL - The filename or extension is too long Le problème de chemin trop long lors de l’enregistrement d’un profil itinérant.

17. Microsoft Learn, ADMX_UserProfiles Policy CSP Les définitions de politiques telles que Delete user profiles older than a specified number of days on system restart.

18. Microsoft Learn, Configure a shared or guest Windows device Le mode Shared PC et la gestion des comptes / profils sur les postes partagés.

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.

Qu'est-ce qu'un profil utilisateur Windows - est-ce juste le dossier C:\Users ?

Non, un profil utilisateur est plus que ce dossier. Il se compose de deux couches : la couche fichiers (Desktop, Documents, Downloads, AppData, etc.) et la couche registre - la ruche NTUSER.DAT, chargée à la connexion et utilisée comme HKEY_CURRENT_USER. C'est pourquoi les cas de profil corrompu peuvent être déroutants : parfois seul le côté dossier est cassé, parfois le problème se situe dans la ruche de registre. Lorsqu'un nouvel utilisateur se connecte pour la première fois, Windows crée le profil en utilisant C:\Users\Default comme modèle.

Quelle est la différence entre %APPDATA% et %LOCALAPPDATA% ?

%APPDATA% correspond à AppData\Roaming et sert aux paramètres par utilisateur que l'on souhaite faire suivre - des préférences et un état de taille réduite qui doivent avoir le même aspect sur tous les appareils. %LOCALAPPDATA% correspond à AppData\Local et sert aux données propres à la machine : les caches régénérables, les gros fichiers de travail et l'état qui n'a de sens que sur ce PC, que l'on ne veut pas faire itinérer pour des raisons de performance. Les données partagées par tous les utilisateurs relèvent de ProgramData, avec une conception d'ACL appropriée, et ce qu'il faut surtout éviter est de placer des données d'exécution propres à un utilisateur dans Program Files.

Quelle est la différence entre un profil obligatoire (Mandatory) et un profil temporaire (Temporary) ?

Ce sont deux choses complètement différentes. Un profil obligatoire est un profil en lecture seule qu'un administrateur crée délibérément - renommer NTUSER.DAT en NTUSER.MAN rend le profil obligatoire - de sorte que les utilisateurs peuvent travailler pendant la session, mais leurs modifications ne sont jamais enregistrées, ce qui convient aux kiosques, aux postes éducatifs et aux PC partagés. Un profil temporaire n'est pas un choix de conception : c'est une solution de secours émise lorsque le profil réel ne peut pas être chargé à cause d'une erreur, et il est supprimé à la déconnexion avec perte de toutes les modifications ; fonctionner avec un tel profil est donc en soi un signe que quelque chose ne va pas.

Par où commencer le diagnostic d'un profil Windows cassé ou temporaire ?

Plutôt que de toucher immédiatement à C:\Users, commencez par regarder les journaux : le journal Application, puis le journal Operational de User Profile Service sous Applications and Services Logs, puis le journal Diagnostic si nécessaire. Les causes fréquentes incluent NTUSER.DAT ou USRCLASS.DAT marqués en lecture seule ou sans les droits d'accès requis, des chemins de destination d'itinérance trop longs (Event ID 1509), et des informations de registre orphelines laissées par une suppression incomplète du profil - supprimer uniquement le dossier ne suffit pas et provoque des profils TEMP à la connexion suivante.

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.