---
title: "Identifier les utilisateurs dans le SDK Kotlin Multiplatform"
description: "Identifiez les utilisateurs dans Adapty pour améliorer les expériences d'abonnement personnalisées."
---

> **AI agents**: to search Adapty docs faster and with fewer tokens, install the Adapty skill. Claude Code (self-updating via plugin): `claude plugin marketplace add adaptyteam/adapty-sdk-integration-skill && claude plugin install adapty-sdk-integration@adapty` — other tools: `npx skills add adaptyteam/adapty-sdk-integration-skill --all`

Adapty crée un identifiant de profil interne pour chaque utilisateur. Cependant, si vous disposez de votre propre système d'authentification, vous devez définir votre propre Customer User ID. Vous pouvez retrouver les utilisateurs par leur Customer User ID dans la section [Profiles](profiles-crm) et l'utiliser dans l'[API côté serveur](getting-started-with-server-side-api), qui sera envoyé à toutes les intégrations.

### Définir le Customer User ID lors de la configuration \{#setting-customer-user-id-on-configuration\}

Si vous disposez d'un identifiant utilisateur au moment de la configuration, passez-le simplement comme paramètre `customerUserId` à la méthode `.activate()` :

```kotlin showLineNumbers

Adapty.activate(
    AdaptyConfig.Builder("PUBLIC_SDK_KEY")
        .withCustomerUserId("YOUR_USER_ID")
        .build()
).onSuccess {
    // successful activation
}.onError { error ->
    // handle the error
    }
}
```

:::tip

Vous souhaitez voir un exemple concret d'intégration du SDK Adapty dans une application mobile ? Consultez nos [exemples d'applications](sample-apps), qui illustrent la configuration complète, notamment l'affichage des paywalls, les achats et d'autres fonctionnalités de base.

:::

### Définir le Customer User ID après la configuration \{#setting-customer-user-id-after-configuration\}

Si vous n'avez pas d'identifiant utilisateur lors de la configuration du SDK, vous pouvez le définir ultérieurement à tout moment avec la méthode `.identify()`. Les cas d'usage les plus courants sont après l'inscription ou la connexion, lorsque l'utilisateur passe du statut d'utilisateur anonyme à celui d'utilisateur authentifié.

```kotlin showLineNumbers

Adapty.identify("YOUR_USER_ID").onSuccess {
    // successful identify
}.onError { error ->
    // handle the error
}
```

Paramètres de la requête :

- **Customer User ID** (obligatoire) : un identifiant utilisateur sous forme de chaîne de caractères.

:::warning
Nouvelle soumission des données utilisateur importantes

Dans certains cas, par exemple lorsqu'un utilisateur se reconnecte à son compte, les serveurs d'Adapty disposent déjà d'informations sur cet utilisateur. Dans ces situations, le SDK Adapty bascule automatiquement vers le nouvel utilisateur. Si vous avez transmis des données à l'utilisateur anonyme, comme des attributs personnalisés ou des attributions provenant de réseaux tiers, vous devez soumettre à nouveau ces données pour l'utilisateur identifié.

Il est également important de noter que vous devez redemander tous les paywalls et produits après avoir identifié l'utilisateur, car les données du nouvel utilisateur peuvent être différentes.
:::

### Déconnexion et reconnexion \{#logging-out-and-logging-in\}

Vous pouvez déconnecter l'utilisateur à tout moment en appelant la méthode `.logout()` :

```kotlin showLineNumbers

Adapty.logout().onSuccess {
    // successful logout
}.onError { error ->
    // handle the error
}
```

Vous pouvez ensuite reconnecter l'utilisateur avec la méthode `.identify()`.

## Associer un `appAccountToken` (iOS) \{#assign-appaccounttoken-ios\}

[`iosAppAccountToken`](https://developer.apple.com/documentation/storekit/product/purchaseoption/appaccounttoken(_:)) est un **UUID** qui vous permet de relier les transactions App Store à l'identité interne de vos utilisateurs.
StoreKit associe ce token à chaque transaction, ce qui permet à votre backend de faire correspondre les données App Store à vos utilisateurs.

Utilisez un UUID stable généré par utilisateur et réutilisez-le pour le même compte sur tous les appareils.
Cela garantit que les achats et les notifications App Store restent correctement associés.

Vous pouvez définir le token de deux façons : lors de l'activation du SDK ou lors de l'identification de l'utilisateur.

:::important
Vous devez toujours passer `iosAppAccountToken` avec `customerUserId`.
Si vous ne passez que le token, il ne sera pas inclus dans la transaction.
:::

```kotlin showLineNumbers

// During configuration:
Adapty.activate(
    AdaptyConfig.Builder("PUBLIC_SDK_KEY")
        .withCustomerUserId(
            id = "YOUR_USER_ID",
            iosAppAccountToken = "YOUR_IOS_APP_ACCOUNT_TOKEN"
        )
        .build()
).onSuccess {
    // successful activation
}.onError { error ->
    // handle the error
}

// Or when identifying users
Adapty.identify(
    customerUserId = "YOUR_USER_ID",
    iosAppAccountToken = "YOUR_IOS_APP_ACCOUNT_TOKEN"
).onSuccess {
    // successful identify
}.onError { error ->
    // handle the error
}
```

## Définir des identifiants de compte obscurcis (Android) \{#set-obfuscated-account-ids-android\}

Google Play exige des identifiants de compte obscurcis dans certains cas d'usage pour renforcer la confidentialité et la sécurité des utilisateurs. Ces identifiants aident Google Play à identifier les achats tout en préservant l'anonymat des informations utilisateur, ce qui est particulièrement important pour la prévention des fraudes et l'analyse.

Vous aurez peut-être besoin de définir ces identifiants si votre application traite des données utilisateur sensibles ou si vous devez vous conformer à des réglementations spécifiques en matière de confidentialité. Les identifiants obscurcis permettent à Google Play de suivre les achats sans exposer les identifiants réels des utilisateurs.

:::important
Vous devez toujours passer `androidObfuscatedAccountId` avec `customerUserId`.
Si vous ne passez que l'identifiant de compte obscurcis, il ne sera pas inclus dans la transaction.
:::

```kotlin showLineNumbers

// During configuration:
Adapty.activate(
    AdaptyConfig.Builder("PUBLIC_SDK_KEY")
        .withCustomerUserId(
            id = "YOUR_USER_ID",
            androidObfuscatedAccountId = "YOUR_OBFUSCATED_ACCOUNT_ID"
        )
        .build()
).onSuccess {
    // successful activation
}.onError { error ->
    // handle the error
}

// Or when identifying users
Adapty.identify(
    customerUserId = "YOUR_USER_ID",
    androidObfuscatedAccountId = "YOUR_OBFUSCATED_ACCOUNT_ID"
).onSuccess {
    // successful identify
}.onError { error ->
    // handle the error
}
```

## Détecter les utilisateurs sur plusieurs appareils \{#detect-users-across-devices\}

Lors de l'activation du SDK, il lit automatiquement les droits existants de l'utilisateur depuis StoreKit (iOS) ou Google Play Billing (Android) et les synchronise avec le backend Adapty. Un abonnement actif apparaît sur le profil Adapty sans que l'application n'appelle `restorePurchases`.

Ce qui **ne** se produit **pas** automatiquement, c'est la reconnaissance qu'un profil sur un nouvel appareil appartient au même utilisateur que le profil sur l'appareil d'origine. Adapty fait correspondre les profils par Customer User ID, donc la continuité d'identité dépend de ce que vous utilisez comme CUID.

**Ce qu'Adapty peut détecter entre les appareils**

| Votre configuration | Ce qu'Adapty détecte | Ce que vous devez faire |
| --- | --- | --- |
| Customer User ID = `device_id` (sans connexion à l'application) | Le nouvel appareil reçoit un CUID différent et donc un profil différent. L'abonnement se synchronise avec le nouveau profil via un événement **Access level updated**, mais `subscription_started` ne se déclenche pas — le nouveau profil est traité comme un héritier de l'achat d'origine. Les analyses basées sur `subscription_started` sous-compteront les utilisateurs de retour. | Utilisez un identifiant de compte stable comme Customer User ID pour qu'un utilisateur de retour corresponde au profil existant sur tous les appareils. |
| Customer User ID = identifiant de compte stable (connexion sur chaque appareil) | Le SDK synchronise automatiquement l'abonnement lors de l'appel `activate()`, et `identify()` fait correspondre le profil existant par CUID. | Aucune configuration supplémentaire n'est nécessaire — l'identité et l'abonnement se résolvent automatiquement. |
| Héritier du partage familial Apple | Le membre de la famille reçoit l'abonnement uniquement via un événement **Access level updated** — `subscription_started` ne se déclenche pas. | Écoutez **Access level updated**. Consultez [Apple Family Sharing](apple-family-sharing) pour la matrice complète des événements. |
| Même compte Apple/Google, utilisateurs in-app différents | Le premier profil à enregistrer l'achat devient le parent. Les profils suivants voient l'abonnement via une chaîne d'héritiers, avec un seul événement **Access level updated**. | Exigez une connexion, puis choisissez un [mode de partage](sharing-paid-access-between-user-accounts) adapté à votre modèle. |

**Restaurer les achats sur un nouvel appareil**

Proposez un bouton « Restaurer les achats » initié par l'utilisateur sur votre paywall. Les directives App Review d'Apple (règle 3.1.1) l'exigent, et il sert de solution de secours quand la synchronisation automatique rate un cas limite. Ce bouton doit appeler `restorePurchases` dans votre SDK.

Un appel programmatique à `restorePurchases` au premier lancement n'est pas nécessaire pour une utilisation normale — le SDK effectue déjà l'équivalent lors de l'appel `activate()`. Réservez les appels programmatiques pour forcer une vérification fraîche du reçu, par exemple lors du débogage d'un accès manquant après la fin de `activate()`.