> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-feat-init-gt-translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Découvrez comment identifier, examiner et migrer les profils utilisateur Auth0 surdimensionnés avant l'application de la limite de taille de 10 Ko.

# Migrer les profils utilisateur surdimensionnés

Auth0 a instauré une limite de 10 Ko pour la représentation sérialisée des données de [profil utilisateur](/docs/fr-ca/manage-users/user-accounts/user-profiles). Auparavant, les données de profil utilisateur étaient limitées uniquement par la taille des documents du moteur de base de données sous-jacent.

Afin de réduire au minimum l'incidence fonctionnelle de cette nouvelle limite, Auth0 applique une marge de taille étendue en plus de celle-ci. Les opérations sur des profils utilisateur qui dépassent la limite de 10 Ko, mais restent dans cette marge étendue, continuent de réussir, mais génèrent des avertissements dans les journaux du tenant. Pour l'instant, cette marge est considérable, soit environ 10 fois la limite, afin de laisser suffisamment de temps pour assurer la conformité lorsqu'un profil utilisateur dépasse 10 Ko.

Les tenants existants comportant un ou plusieurs profils utilisateur qui approchaient ou dépassaient déjà la limite de 10 Ko ont bénéficié d'une période de migration pendant laquelle le comportement d'origine, sans limites explicites, demeure disponible. La période de migration prend fin le **4 mars 2027**. Après cette date, ces tenants commenceront à appliquer la limite de 10 Ko, en plus de la marge de taille étendue.

Pour en savoir plus sur les échéanciers de migration, consultez l'entrée [Dépréciations et migrations](/docs/fr-ca/troubleshoot/product-lifecycle/deprecations-and-migrations).

Suivez les étapes ci-dessous pour déterminer si vos tenants ont été signalés en raison de profils utilisateur dépassant la limite de 10 Ko, examiner les profils utilisateur non conformes et renoncer au comportement obsolète.

<Warning>
  Les administrateurs de tenant Private Cloud peuvent suivre ces instructions si leur [déploiement Private Cloud](/docs/fr-ca/deploy-monitor/deploy-private-cloud) est à la version `202635` ou ultérieure, car c'est à partir de cette version que la bascule de migration correspondante et les journaux du tenant deviennent disponibles dans les tenants concernés. Pour en savoir plus sur les versions de déploiement Private Cloud, consultez [How to Check the Auth0 Private Cloud's Release Number and Deployment Date](https://support.auth0.com/center/s/article/How-to-check-the-Auth0-private-cloud-s-release-number-and-deployment-date).
</Warning>

<h2 id="verify-affected-tenants">
  Vérifier les tenants touchés
</h2>

Utilisez le Auth0 Dashboard pour déterminer si un tenant a été signalé comme ayant des profils utilisateur non conformes et nécessitant une migration.

1. Accédez à [Auth0 Dashboard > Paramètres du tenant > Avancé](https://manage.auth0.com/dashboard/#/tenant/advanced).
2. Faites défiler jusqu'à la section **Migrations**.
3. Repérez la bascule **Uncapped User Profile Data** :
   * La bascule est **activée** : votre tenant n'est pas migré et a accès à des profils utilisateur sans limite de taille explicite. Vous devez terminer la migration avant l'échéance du **4 mars 2027**.
   * La bascule est absente ou **désactivée** : votre tenant n'applique plus le comportement deprecated; aucune autre action n'est requise.

<h3 id="functional-differences-in-unmigrated-tenants">
  Différences fonctionnelles dans les tenants non migrés
</h3>

Dans un tenant où la bascule de migration **Uncapped User Profile Data** est activée, le service ne génère **pas** d'erreur lors des opérations qui dépendent de la création ou de la mise à jour d'utilisateurs, même si le profil utilisateur dépasse à la fois la limite de 10 ko et la marge de taille étendue. Cette marge de taille étendue demeure applicable même après la migration d'un tenant vers le nouveau comportement.

<h2 id="identify-oversized-user-profiles">
  Repérer les profils utilisateur surdimensionnés
</h2>

Consultez les logs de tenant `depnote` associés afin de repérer les tentatives de création ou de mise à jour de profils utilisateur dépassant la nouvelle limite de taille de profil. Ces logs de tenant se déclenchent uniquement lorsqu'une activité de l'utilisateur exige une mise à jour du profil, comme une nouvelle tentative de login. Par conséquent, ils ne permettent pas de repérer les profils utilisateur existants qui dépassent déjà la limite si les utilisateurs concernés demeurent inactifs.

<h3 id="query-uncapped-user-profile-data-deprecation-logs">
  Interroger les logs de deprecation liés aux données de user profile non plafonnées
</h3>

Utilisez la query suivante pour rechercher les tenant logs propres à cette deprecation. Pour en savoir plus sur l'interrogation des tenant logs, consultez [Log Search Query Syntax](/docs/fr-ca/deploy-monitor/logs/log-search-query-syntax).

```bash lines theme={null}
type:depnote AND description:Uncapped\ User\ Profile\ Data*
```

Une fois les résultats de la requête obtenus, examinez les champs `user_id` et `projected_size_bytes` de l'objet `details` afin de repérer les profils utilisateur surdimensionnés et leur taille. La structure de l'objet `details`, tout comme les informations contextuelles supplémentaires, peut varier légèrement selon l'opération sous-jacente ayant déclenché le journal du locataire.

Voici un exemple d'entrée de journal déclenchée par un utilisateur final dont le profil est surdimensionné et qui s'est connecté au moyen de Universal Login. Certains champs par défaut du journal du locataire ont été omis de l'exemple par souci de concision.

```json lines theme={null}
{
  "date": "2026-08-12T10:41:05.694Z",
  "type": "depnote",
  "description": "Uncapped User Profile Data: This feature is being deprecated. Please see details.feature of this log for more information.",
  "connection_id": "",
  "client_id": "Bd5rq9AlKTuOIUCc1JWB5WfmsTmN6iCf",
  "client_name": "example-app",
  "ip": "165.85.168.10",
  "user_agent": "Chrome 153.0.0 / Mac OS X 10.15.7",
  "details": {
    "feature": {
      "projected_size_bytes": "37581",
      "operation": "users.save",
      "user_id": "auth0|6a7c4da311eb043fbeed60f3",
      "id": "allow_oversize_profile",
      "name": "Uncapped User Profile Data",
      "description": "User profile data will be limited to 10KB. User profiles above that limit are deprecated."
    },
    "path": "/u/login",
    "method": "POST"
  },
  "log_id": "90020260812104105751616000000000000001223372045702376794"
}
```

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Dès qu'un tenant adopte le nouveau comportement, les tenant logs propres à la deprecation ne s'appliquent plus. Vous pouvez toutefois continuer à surveiller les nouveaux cas de profils utilisateur qui dépassent la limite grâce au type de tenant log `user_profile_size_exceeded`.
</Callout>

<h3 id="ad-hoc-calculation-of-user-profile-size">
  Calcul ponctuel de la taille d'un profil utilisateur
</h3>

Les vérifications de limites effectuées par le service reposent sur la représentation interne des données sérialisées associées à un profil utilisateur. Comme ce processus de sérialisation inclut des champs opérationnels qui ne sont pas exposés à l'externe, les calculs ponctuels fondés uniquement sur les données de profil utilisateur visibles à l'externe peuvent différer des vérifications effectuées par le service.

Cela dit, les calculs ponctuels fondés sur la représentation JSON du profil utilisateur retournée par le endpoint [Get a User](https://auth0.com/docs/api/management/v2/users/get-users-by-id) demeurent utiles pour obtenir une valeur approximative et pour comparer des profils utilisateur dont les ensembles d'attributs diffèrent. Cela fonctionne parce que les profils surdimensionnés déjà présents dans le système continuent d'être retournés sans restriction par les endpoints de récupération (`GET`) et par les jobs d'exportation d'utilisateurs en bloc, qu'ils dépassent ou non la limite.

<h2 id="address-the-root-cause-of-oversized-user-profiles">
  Traiter la cause fondamentale des profils utilisateur trop volumineux
</h2>

Les étapes exactes pour réduire la taille d'un profil utilisateur signalé peuvent varier considérablement, mais elles se rattachent généralement à l'un des scénarios suivants :

* Retirer des profils utilisateur les données qui ne servent pas à l'authentification et à l'autorisation.
* Déplacer du profil utilisateur vers d'autres stockages de données les données nécessaires à l'authentification et à l'autorisation.

Des exemples concrets d'actions pour chaque scénario sont présentés ci-dessous.

<h3 id="prevent-storage-of-unneeded-attributes-from-external-identity-providers">
  Empêcher le stockage d'attributs inutiles provenant d'identity providers externes
</h3>

Pour éviter le stockage d'attributs utilisateur inutiles provenant d'identity providers externes, utilisez la [liste de rejet des attributs utilisateur Auth0](https://auth0.com/docs/secure/security-guidance/data-security/denylist). Cette fonctionnalité vous permet de bloquer explicitement l'enregistrement de certains attributs dans le profil utilisateur, ce qui garde les profils allégés et évite un gonflement inutile des données.

Les attributs ajoutés à la liste de rejet demeurent accessibles dans l'extensibilité post-login : vous pouvez donc utiliser cette information, ou la conserver dans un stockage de données externe, sans influer sur la taille du profil utilisateur.

<h3 id="use-extensibility-to-query-additional-business-data-dynamically">
  Utiliser l’extensibilité pour interroger dynamiquement des données métier supplémentaires
</h3>

Pour les structures de données non bornées, comme les tableaux dynamiques, ou les autres données volumineuses, évitez de stocker ces valeurs directement dans `user_metadata` ou `app_metadata`. Conservez plutôt ces données dans vos propres stockages de données externes et récupérez-les dynamiquement pendant l’authentification à l’aide d’une Action post-connexion :

1. Utilisez une Action post-connexion pour exécuter du code personnalisé immédiatement après l’authentification d’un utilisateur.
2. Dans votre Action, effectuez une requête réseau sécurisée (par exemple, à l’aide de `axios` ou de la fonction `fetch` native) vers votre propre API backend ou base de données afin de récupérer les attributs requis.
3. Utilisez les données récupérées pour définir des revendications personnalisées dans les jetons émis ou alimenter la logique d’autorisation, sans enregistrer les données brutes dans le profil utilisateur.

Ce modèle permet de maintenir vos profils utilisateur sous la limite de 10 Ko, tout en permettant à votre application de continuer à recevoir les données contextuelles nécessaires. Pour en savoir plus, consultez [Auth0 Actions](https://auth0.com/docs/customize/actions/write-your-first-action).

<h3 id="use-enterprise-groups-to-sync-group-information">
  Utiliser les Enterprise Groups pour synchroniser l'information de groupe
</h3>

Plutôt que de stocker directement dans le profil utilisateur l'information sur les groupes d'utilisateurs provenant d'identity providers externes, servez-vous des [Enterprise Groups](https://auth0.com/docs/authenticate/protocols/scim), accessibles par des endpoints SCIM, pour gérer cette information comme une entité distincte. Vous pouvez ensuite utiliser les groups ainsi provisionnés [de plusieurs façons](https://auth0.com/docs/authenticate/protocols/scim/configure-inbound-scim#group-provisioning-options) : en complément des Auth0 Organizations ou de manière indépendante, dans des post-login Actions, pour vos décisions personnalisées d'access control et d'autorisation.

Par exemple, cette approche vous permet de cesser de stocker l'information sur les groupes d'utilisateurs Entra ID (Azure AD) directement dans les profils utilisateur dans le cadre des [connections Azure AD existantes](https://auth0.com/docs/authenticate/protocols/scim/inbound-scim-for-older-azure-ad-connections).

<h2 id="opt-out-to-complete-migration">
  Désactiver pour terminer la migration
</h2>

Une fois que vous avez corrigé la cause des profils utilisateurs surdimensionnés et que vous ne dépendez plus de ce comportement obsolète, désactivez-le dès que possible. Vous pourrez ainsi choisir précisément quand votre tenant adoptera le nouveau comportement et garder davantage de contrôle sur votre migration.

1. Accédez à [Auth0 Dashboard > Paramètres du tenant > Avancé](https://manage.auth0.com/dashboard/#/tenant/advanced).
2. Sous **Migrations**, désactivez **Uncapped User Profile Data**.

Si vous rencontrez des problèmes, vous pouvez temporairement réactiver la bascule afin de rétablir le comportement précédent pendant que vous les corrigez. Les opérations les plus susceptibles d’être soumises à la vérification de la limite, et qui peuvent échouer si un profil utilisateur dépasse la taille maximale étendue autorisée, comprennent :

* **Opérations administratives via la Management API**
  * Création d’utilisateurs (`POST /api/v2/users`).
  * Mise à jour d’utilisateurs (`PATCH /api/v2/users/{id}`).
  * Importation en bloc d’utilisateurs (`POST /api/v2/jobs/users-imports`).
* **Opérations liées à l’authentification**
  * Connexions d’utilisateurs par l’intermédiaire de connexions à une base de données personnalisée, lorsque les scripts de base de données personnalisée renvoient trop d’attributs.
  * Connexions d’utilisateurs par l’intermédiaire de fournisseurs d’identité externes, comme des connexions sociales ou d’entreprise, lorsque le fournisseur d’identité renvoie trop d’attributs.
  * Connexions d’utilisateurs par tout type de connexion, si le profil est déjà surdimensionné, en raison de la nécessité de mettre à jour des attributs opérationnels lors d’une connexion standard.
  * Mise à jour des facteurs d’authentification multifacteur (MFA) via Universal Login, la MFA API ou la My Account API.
  * Mises à jour des métadonnées via l’objet `api` d’extensibilité, par exemple dans une Action post-login.
* **Opérations d’approvisionnement des utilisateurs**
  * Requêtes de modification de ressources utilisateur via SCIM.
  * Directory Sync pour les connexions Google Workspace.