# Activation du contenu adaptatif

Pour commencer à personnaliser l’expérience de votre documentation pour vos lecteurs, vous devrez activer le contenu adaptatif et décider comment les données de vos visiteurs sont transmises à GitBook. Cela permet au contenu de votre site de s’adapter dynamiquement en fonction de la personne qui le consulte.

### Activer le contenu adaptatif

Avant de pouvoir transmettre des données utilisateur à GitBook, vous devrez configurer votre site pour utiliser le contenu adaptatif.

Accédez à votre [paramètres de votre site](https://gitbook-open-v2-preview.gitbook.workers.dev/url/gitbook.com/docs/documentation/fr/publishing-documentation/site-settings), et activez **Contenu adaptatif** depuis les paramètres d’audience de votre site. Une fois activé, vous obtiendrez une « Visitor token signing key » générée, dont vous aurez besoin pour poursuivre la configuration du contenu adaptatif.

<figure><img src="https://3903131528-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FNkEGS7hzeqa35sMXQZ4X%2Fuploads%2F5EeWAo5Ij6CKrp69uMl5%2F26_01_06_enable_adaptive_content%402x.png?alt=media&#x26;token=4a1e8558-4b91-4f8b-8581-63d570a2c330" alt="A GitBook screenshot showing the enable adaptive content toggle"><figcaption><p>Activez le contenu adaptatif dans les paramètres de votre site</p></figcaption></figure>

### Définissez votre schéma de visiteur

Après avoir activé le contenu adaptatif, vous devrez définir un schéma pour les types de revendications que vous attendez de GitBook lorsqu’un utilisateur visite votre site.

Le schéma de visiteur doit refléter la manière dont ces revendications sont structurées lorsqu’elles sont envoyées à GitBook.

Par exemple, si vous vous attendez à ce qu’un visiteur puisse être un utilisateur bêta dans votre produit, vous définiriez un schéma de visiteur similaire à :

```json
{
  "type": "object",
  "properties": {
    "isBetaUser": {
      "type": "boolean",
      "description": "Indique si le visiteur est un utilisateur bêta."
    }
  },
  "additionalProperties": false
}
```

Cela vous aidera également à utiliser l’autocomplétion lorsque vous configurez vos revendications dans le [éditeur de conditions](https://gitbook-open-v2-preview.gitbook.workers.dev/url/gitbook.com/docs/documentation/fr/publishing-documentation/adapting-your-content#working-with-the-condition-editor). Les schémas de visiteur ne prennent en charge que les types suivants :

{% tabs %}
{% tab title="Chaînes" %}
Lire les revendications transmises sous forme de chaînes.

GitBook accepte les chaînes dynamiques, ce qui signifie que vous pouvez transmettre dynamiquement des données textuelles — comme le nom d’un utilisateur, des jetons développeur, et bien plus encore.

Les chaînes peuvent également contenir une **clé enum optionnelle** , qui vous permet de restreindre les données reçues par GitBook à l’une des valeurs définies.

```json
{
  "type": "object",
  "properties": {
    "language": {
          "type": "string",
          "description": "La langue du visiteur",
          // Propriété enum optionnelle
          "enum": [
            "en",
            "fr",
            "it"
          ]
  },
  "additionalProperties": false
}
```

{% hint style="warning" %}
Les chaînes dynamiques (chaînes définies sans clé enum) ne sont acceptées que pour [les expressions en ligne](https://gitbook-open-v2-preview.gitbook.workers.dev/url/gitbook.com/docs/documentation/fr/creating-content/variables-and-expressions#use-variables-in-your-content). Les expressions conditionnelles pour la visibilité des éléments (pages, sections, blocs) ne fonctionnent qu’avec des chaînes définies avec des clés enum.
{% endhint %}
{% endtab %}

{% tab title="Booléens" %}
Lire les revendications transmises sous forme de booléens.

```json
{
  "type": "object",
  "properties": {
    "isBetaUser": {
      "type": "boolean",
      "description": "Indique si le visiteur est un utilisateur bêta."
    },
  },
  "additionalProperties": false
}
```

{% endtab %}

{% tab title="Objets" %}
Imbriquez des revendications dans un objet pour regrouper des valeurs similaires.

```json
{
  // Revendications de premier niveau
  "type": "object",
  "properties": {
    // Revendications imbriquées
    "access": {
      "type": "object",
      "description": "Accès de l’utilisateur à la fonctionnalité du produit",
      "properties": {
        "isAlphaUser": {
          "type": "boolean",
          "description": "Indique si le visiteur est un utilisateur alpha."
        },
        "isBetaUser": {
          "type": "boolean",
          "description": "Indique si le visiteur est un utilisateur bêta."
        },
      },
      "additionalProperties": false
    }
  },
  "additionalProperties": false
}
```

{% endtab %}
{% endtabs %}

### Définir une revendication non signée

Les revendications non signées sont un type spécifique de revendication qui identifie les revendications entrantes qui peuvent ne pas être signées par une application cliente. Il est obligatoire de définir les revendications dans votre schéma de visiteur comme `non signé` si vous transmettez des revendications via des paramètres d’URL, des cookies non signés et des indicateurs de fonctionnalité.

Si vous comptez travailler avec des revendications non signées, vous devrez déclarer les revendications que vous attendez dans le schéma sous une propriété « unsigned », en plus de vos revendications signées.

```json
{
  "type": "object",
  "properties": {
    "isBetaUser": {
      "type": "boolean",
      "description": "Indique si le visiteur est un utilisateur bêta."
    },
    // Ajouter des revendications non signées
    "unsigned": {
      "type": "object",
      "description": "Revendications non signées du visiteur du site.",
      "properties": {
        "language": {
          "type": "string",
          "description": "La langue du visiteur",
          // Propriété enum optionnelle
          "enum": [
            "en",
            "fr",
            "it"
          ]
        }
      },
      "additionalProperties": false
    }
  },
  "additionalProperties": false
}
```

### Transmettre les données des visiteurs à GitBook

GitBook propose différentes façons de transmettre les données des visiteurs afin d’adapter le contenu de votre site. Après avoir défini votre schéma, vous devrez décider comment vous souhaitez transmettre les données de vos visiteurs à GitBook.

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><i class="fa-cookie">:cookie:</i></td><td><strong>Cookies</strong></td><td>Transmettez les données des visiteurs à votre documentation via un cookie public ou signé.</td><td><a href="enabling-adaptive-content/cookies">cookies</a></td></tr><tr><td><i class="fa-link">:link:</i></td><td><strong>URL</strong></td><td>Transmettez les données des visiteurs à votre documentation via des paramètres de requête URL.</td><td><a href="enabling-adaptive-content/url">url</a></td></tr><tr><td><i class="fa-flag">:flag:</i></td><td><strong>Indicateurs de fonctionnalité</strong></td><td>Transmettez les données des visiteurs à votre documentation via un fournisseur d’indicateurs de fonctionnalité.</td><td><a href="enabling-adaptive-content/feature-flags">feature-flags</a></td></tr><tr><td><i class="fa-lock">:lock:</i></td><td><strong>Accès authentifié</strong></td><td>Transmettez les données des visiteurs à votre documentation via un fournisseur d’authentification.</td><td><a href="enabling-adaptive-content/authenticated-access">authenticated-access</a></td></tr></tbody></table>