---
title: "Comment fonctionnent les profils"
description: "Comprenez comment Adapty crée, suit et associe les profils utilisateurs — notamment les profils anonymes, les utilisateurs identifiés et les relations parent/héritier."
---

Chaque utilisateur de votre application dispose d'un profil Adapty qui suit ses achats, événements et état d'abonnement. Comprendre comment les profils sont créés et liés vous aide à éviter les bugs d'intégration, la fragmentation des données et à interpréter les informations dans la section [Profils](profiles-crm).

## Création de profil \{#profile-creation\}

Adapty crée automatiquement un profil la première fois qu'un utilisateur ouvre votre application.

**Sans Customer User ID**, le profil est anonyme. Un nouveau profil anonyme est créé à chaque fois que :
- Un utilisateur réinstalle l'application
- Un utilisateur se déconnecte de votre application (lorsque votre application appelle `Adapty.logout()`)

Les achats sont liés à l'installation de l'application, et non à une identité utilisateur persistante.

**Avec un Customer User ID**, le profil persiste entre les réinstallations et sur plusieurs appareils. Utiliser un Customer User ID vous permet de :

1. Suivre un utilisateur entre les réinstallations de l'application et sur plusieurs appareils.
2. Retrouver des utilisateurs via leur Customer User ID dans la section [**Profiles**](profiles-crm).
3. Utiliser le Customer User ID dans l'[API côté serveur](getting-started-with-server-side-api).
4. Adapty envoie le Customer User ID à toutes les intégrations.

Le comportement du profil avec un Customer User ID dépend du moment où vous le définissez :

- **Lors de l'activation du SDK** : Adapty utilise le profil existant associé à ce Customer User ID (pour les utilisateurs de retour) ou crée un nouveau profil (pour les nouveaux utilisateurs).
- **Après l'activation du SDK** : Adapty crée un profil anonyme lors de l'activation. Lorsque vous identifiez l'utilisateur par la suite, Adapty associe le Customer User ID au profil anonyme (pour les nouveaux utilisateurs) ou bascule vers le profil existant avec cet ID (pour les utilisateurs de retour).

**Quelle approche utiliser :**

- **Customer User ID disponible au lancement de l'application** (par exemple, stocké depuis une session précédente) — transmettez-le à `activate()` lors de l'initialisation du SDK.
- **Les utilisateurs se connectent après le lancement de l'application** — appelez `identify()` après l'authentification. Adapty associe l'ID au profil actuel (si l'ID est nouveau) ou bascule vers le profil existant (si l'ID existe déjà).
- **Les utilisateurs peuvent acheter avant de se connecter** — appelez `identify()` après la connexion. Si le Customer User ID existe déjà dans Adapty, récupérez le profil ensuite pour synchroniser le niveau d'accès actuel.

Pour les détails d'implémentation, consultez le guide SDK [identification des utilisateurs](identifying-users).

:::note
Si un utilisateur de retour a précédemment utilisé votre application sans Customer User ID, ces profils anonymes ne sont pas automatiquement fusionnés lorsque vous commencez à identifier lors de l'activation du SDK. Pour conserver l'historique complet de ces utilisateurs, utilisez `identify()` après la connexion à la place.
:::

## Profils parent et héritier \{#parent-and-inheritor-profiles\}

Lorsqu'un même abonnement côté store est associé à plusieurs profils Adapty, Adapty traite ces profils comme une chaîne : un profil **parent** et un ou plusieurs profils **héritiers** qui partagent l'accès issu du même achat.

Cela se produit lorsque :

- Le [partage d'accès payant entre comptes utilisateurs](sharing-paid-access-between-user-accounts) est activé et qu'un utilisateur se connecte sur un appareil où un profil différent avait précédemment effectué l'achat.
- Un utilisateur réinstalle l'application sans `customer_user_id`, et le nouveau profil récupère l'achat de l'installation précédente.
- Des utilisateurs identifiés différents restaurent des achats sur le même appareil.
- Une application est transférée entre des Team IDs Apple et la nouvelle application récupère les achats effectués sous l'ancien Team ID.

**Comment le parent est sélectionné.**

Le parent est le **premier profil à enregistrer l'achat** — déterminé par l'ordre des reçus d'achat dans Adapty, et non par l'ordre de création des profils. Par exemple : vous installez l'application sans effectuer d'achat, puis vous réinstallez et achetez un abonnement. Le second profil devient le parent car c'est lui qui a effectué l'achat. Le premier profil devient l'héritier et obtient l'accès via le partage.

**Comment les événements sont distribués :**

- **Événements transactionnels** (achats, renouvellements, annulations, problèmes de facturation, délais de grâce, remboursements) : Apparaissent uniquement sur le profil **parent** qui a effectué l'achat. Tous les renouvellements et mises à jour d'abonnements continuent d'apparaître sur ce profil.
- **Événements `access_level_updated`** : Apparaissent sur les profils **parent et héritier** à chaque changement d'état du niveau d'accès. Cela permet de maintenir tous les profils connectés informés de leur statut d'accès actuel.

Le profil parent affiche l'historique complet des transactions. Les profils héritiers affichent uniquement leurs mises à jour de niveau d'accès et un lien vers le profil parent dans la section **Access level**.

  <img src="/assets/shared/img/98d0dad-non-original_profile.webp"
  style={{
    border: '1px solid #727272',
    width: '700px',
    display: 'block',
    margin: '0 auto'
  }}
/>

**Suivi du même abonnement sur plusieurs profils.**

Chaque profil héritier possède son propre `profile_id`, donc `profile_id` n'est pas stable au sein d'une chaîne. Pour identifier le même abonnement sur plusieurs profils — par exemple lors du rapprochement d'événements webhook ou de la correspondance entre profils du tableau de bord et un utilisateur sous-jacent — utilisez plutôt l'identifiant côté store.

| Champ | Utilisation |
| --- | --- |
| `store_original_transaction_id` | Identifier une chaîne d'abonnement sur plusieurs profils. Unique par abonnement Apple. |
| `profiles_sharing_access_level` (champ webhook) | Tous les profils actuellement autorisés par l'abonnement, lorsque le partage est activé. |
| `profile_id` | **Non** adapté au suivi cross-profil — chaque héritier possède le sien. |

## Transactions sans profil \{#transactions-without-profiles\}

Certaines transactions dans Adapty ne sont rattachées à aucun profil — elles apparaissent dans les analyses et les exports mais pas dans la liste des Profils. Cela se produit pour les **notifications store serveur à serveur (S2S)** envoyées pour des utilisateurs dont les comptes ne se sont jamais connectés à votre application via le SDK Adapty. Les sources connues sont :

- Notifications S2S de l'App Store (y compris les événements de remboursement)
- Notifications S2S de Google Play
- Événements webhook Stripe et Paddle

Ces transactions :

- **Apparaissent dans les graphiques analytiques** (elles sont comptabilisées dans les métriques globales)
- **Apparaissent dans les exports** (S3, GCS, BigQuery) avec `profile_id` défini à `null`
- **N'apparaissent pas dans la liste des Profils** — il n'y a aucun profil auquel les rattacher

Si vous constatez plus d'événements dans les analyses ou les exports que vous n'en trouvez dans l'interface Profils, la différence correspond probablement à ces transactions sans profil. Pour les trouver dans un export, filtrez les lignes où `profile_id IS NULL`.

## Partage de l'accès payant entre comptes utilisateurs \{#sharing-paid-access-between-user-accounts\}

:::link
Article principal : [Partage de l'accès payant entre comptes utilisateurs](sharing-paid-access-between-user-accounts)
:::

Pour définir votre politique de partage de niveau d'accès, sur la page des paramètres [**General**](general), sélectionnez une option de partage. Vous pouvez définir une politique distincte pour l'[environnement sandbox](test-purchases-in-sandbox).

**Activé (par défaut)**

Les utilisateurs identifiés (ceux qui ont un [Customer User ID](identifying-users#set-customer-user-id-on-configuration)) peuvent partager le même [niveau d'accès](access-level) fourni par Adapty si leur appareil est connecté au même identifiant Apple/Google. C'est utile quand un utilisateur réinstalle l'application et se connecte avec un autre e-mail — il conserve tout de même l'accès à son achat précédent. Avec cette option, plusieurs utilisateurs identifiés peuvent partager le même niveau d'accès.

Même si le niveau d'accès est partagé, toutes les transactions passées et futures sont enregistrées comme événements dans le Customer User ID d'origine afin de maintenir des analyses cohérentes et conserver un historique de transactions complet — y compris les périodes d'essai, les achats d'abonnement, les renouvellements, etc., liés au même profil.

**Transférer l'accès au nouvel utilisateur**

Les utilisateurs identifiés peuvent continuer à accéder au [niveau d'accès](access-level) fourni par Adapty, même s'ils se connectent avec un [Customer User ID](identifying-users#set-customer-user-id-on-configuration) différent ou réinstallent l'application, tant que l'appareil est connecté au même identifiant Apple/Google.

Contrairement à l'option précédente, Adapty transfère l'achat entre les utilisateurs identifiés. Cela garantit que le contenu acheté est disponible, mais un seul utilisateur peut y avoir accès à la fois. Par exemple, si UserA achète un abonnement et que UserB se connecte sur le même appareil et restaure les transactions, UserB obtient l'accès à l'abonnement, et celui-ci est révoqué pour UserA.

Si l'un des utilisateurs (le nouveau ou l'ancien) n'est pas identifié, le niveau d'accès sera tout de même partagé entre ces profils dans Adapty.

Bien que le niveau d'accès soit transféré, toutes les transactions passées et futures sont enregistrées comme événements dans le Customer User ID d'origine afin de maintenir des analyses cohérentes et conserver un historique de transactions complet — y compris les périodes d'essai, les achats d'abonnement, les renouvellements, etc., liés au même profil.

Après être passé à **Transférer l'accès au nouvel utilisateur**, les niveaux d'accès ne seront pas transférés entre les profils immédiatement. Le processus de transfert pour chaque niveau d'accès spécifique est déclenché uniquement lorsqu'Adapty reçoit un événement du store, comme un renouvellement d'abonnement, une restauration ou lors de la validation d'une transaction.

**Désactivé**

Le premier profil d'utilisateur identifié à obtenir un niveau d'accès le conservera indéfiniment. C'est la meilleure option si votre logique métier exige que les achats soient liés à un seul Customer User ID.

Notez que les niveaux d'accès sont tout de même partagés entre les utilisateurs anonymes.

Vous pouvez « délier » un achat en [supprimant le profil de l'utilisateur propriétaire](https://adapty.io/docs/fr/api-adapty/operations/deleteProfile). Après la suppression, le niveau d'accès devient disponible pour le premier profil utilisateur qui le réclame, qu'il soit anonyme ou identifié.

La désactivation du partage ne concerne que les nouveaux utilisateurs. Les abonnements déjà partagés entre utilisateurs continueront de l'être même après la désactivation de cette option.

:::warning

Apple et Google exigent que les achats intégrés soient partagés ou transférés entre utilisateurs car ils s'appuient sur l'identifiant Apple/Google pour y associer l'achat. Sans partage, la restauration des achats risque de ne pas fonctionner lors des réinstallations ultérieures.

La désactivation du partage peut empêcher les utilisateurs de retrouver l'accès après connexion.

Nous recommandons de désactiver le partage uniquement si vos utilisateurs **sont tenus de se connecter** avant d'effectuer un achat. Dans le cas contraire, un utilisateur identifié pourrait acheter un abonnement, se connecter à un autre compte et perdre définitivement l'accès.
:::

### Quel paramètre choisir ? \{#which-setting-should-i-choose\}

| Mon application...                                           | Option à choisir                                             |
| ------------------------------------------------------------ | ------------------------------------------------------------ |
| N'a pas de système de connexion et utilise uniquement les identifiants de profil anonymes d'Adapty. | Utilisez l'option par défaut, car les niveaux d'accès sont toujours partagés entre les identifiants de profil anonymes pour les trois options. |
| Dispose d'un système de connexion optionnel et permet aux clients d'effectuer des achats avant de créer un compte. | Choisissez **Transférer l'accès au nouvel utilisateur** pour garantir que les clients qui achètent sans compte pourront toujours restaurer leurs transactions ultérieurement. |
| Exige que les clients créent un compte avant d'acheter, mais permet de lier les achats à plusieurs Customer User ID. | Choisissez **Transférer l'accès au nouvel utilisateur** pour garantir qu'un seul Customer User ID a accès à la fois, tout en permettant aux utilisateurs de se connecter avec un autre Customer User ID sans perdre leur accès payant. |
| Exige que les clients créent un compte avant d'acheter, avec des règles strictes liant les achats à un seul Customer User ID. | Choisissez **Désactivé** pour garantir que les transactions ne sont jamais transférées entre comptes. |

## Horodatages d'événements avec des dates futures (Apple/iOS) \{#event-timestamps-with-future-dates-appleios\}

Ce comportement est spécifique à l'App Store d'Apple. Le système de notifications de Google Play n'envoie pas d'événements à l'avance.

Les horodatages d'événements dans les profils et les intégrations peuvent afficher des dates futures car Apple envoie les événements de renouvellement à l'avance.

- **Pourquoi cela se produit** : Apple fait cela pour s'assurer que les abonnements se renouvellent automatiquement avant leur expiration, évitant ainsi toute interruption de service pour les utilisateurs. Pour plus de détails, consultez le Forum des développeurs Apple : [Server Notifications for Subscriptions](https://developer.apple.com/forums/tags/app-store-server-notifications).
- **Types d'événements concernés** : En général, cela s'applique aux renouvellements d'abonnements et aux conversions d'essai vers payant. Ces événements peuvent avoir des horodatages futurs car Apple en notifie les systèmes à l'avance.
- **Autres types d'événements** : Les achats intégrés supplémentaires et les changements de plan d'abonnement sont enregistrés avec leurs horodatages réels car ces événements ne peuvent pas être prédits à l'avance.
- **Impact sur les analyses et le flux d'événements** : Ces événements n'apparaîtront dans **Analytics** et dans le **Event Feed** qu'une fois leurs horodatages dépassés. Les événements avec des horodatages futurs ne sont affichés dans aucune de ces sections.
- **Impact sur les intégrations** : Adapty envoie les événements aux intégrations dès leur réception. Si un événement a un horodatage futur, Adapty l'envoie à votre intégration avec l'horodatage futur inchangé.

## Étapes suivantes \{#next-steps\}

- Pour utiliser le tableau de bord Profils afin de trouver et gérer les utilisateurs, consultez [Profils](profiles-crm).
- Pour configurer l'identification des utilisateurs dans votre application, consultez le guide SDK [identification des utilisateurs](identifying-users).
- Pour configurer la politique de partage d'accès, consultez [Partage de l'accès payant entre comptes utilisateurs](sharing-paid-access-between-user-accounts).