# Démarrer (/fr/docs/platform/features/builders/permissions-policy/get-started)











Cette page vous mène des reports que votre site collecte déjà à une [Permissions-Policy](/fr/docs/web-security/policies/permissions-policy) déployée en [mode report-only](/fr/docs/web-security/policies/permissions-policy#mode-report-only), puis appliquée.

<Callout type="warn" title="Revoyez chaque autorisation et déployez d'abord en report-only">
  Le générateur accorde chaque fonctionnalité aux pages et iframes dont les navigateurs ont reporté l'usage. Toute personne qui connaît votre endpoint de reporting peut lui envoyer des reports, alors revoyez les autorisations avant de déployer, en commençant par les fonctionnalités accordées à une autre origine.

  Déployez toujours une nouvelle politique d'abord avec le header `Permissions-Policy-Report-Only`. Passez à `Permissions-Policy` seulement quand au moins une semaine de reports montre que rien de ce dont vos pages ont besoin ne serait bloqué.
</Callout>

## Avant de commencer [#avant-de-commencer]

Vérifiez que vous disposez de :

* Un site qui envoie ses reports à CentralCSP. La page [Reports Permissions Policy](/fr/docs/platform/monitoring/permissions-policy) montre ce dont le générateur apprend. Si elle n'affiche aucune donnée, le générateur fonctionne quand même : partez d'un préréglage et accordez les fonctionnalités à la main. Consultez [Connecter votre site](/fr/docs/platform/websites/connect-your-site).
* Un accès à la configuration du serveur, du framework ou du réseau de diffusion de contenu (CDN) qui définit vos headers de réponse.
* La liste des iframes que vos pages embarquent volontairement, comme un formulaire de paiement, un lecteur vidéo ou une carte.

Choisissez la durée de la période à analyser avant de commencer. Une période plus longue capte les pages que peu de visiteurs ouvrent, comme le paiement ou les paramètres du compte.

<Callout type="warn" title="Gardez l'onglet ouvert jusqu'à l'export">
  Le générateur n'enregistre rien. L'étape, la période et le préréglage choisi restent dans l'adresse de la page, mais vos décisions d'autorisation et de rejet, ainsi qu'une politique que vous collez, n'existent que dans la page ouverte. Recharger ou fermer l'onglet les efface.
</Callout>

## 1. Choisir les reports à analyser [#1-choisir-les-reports-à-analyser]

Pour choisir la période :

1. Dans la barre latérale du site, allez dans **Générateurs** > **Permissions-Policy**.
2. À l'étape **Période**, sélectionnez **Aujourd'hui**, **7 jours**, **14 jours** ou **30 jours**. Pour toute autre plage dans les 30 derniers jours, faites plutôt glisser la souris sur le graphique des reports.
3. Vérifiez les trois compteurs : **Rapports**, **Fonctionnalités utilisées** et **Semblent être du bruit**.
4. Sélectionnez **Continuer**.

La période par défaut est de 7 jours. **Aujourd'hui** correspond au jour calendaire en cours dans votre fuseau horaire, pas aux dernières 24 heures. Un site qui envoie un très gros volume de reports est limité à 7 jours à la fois. Sur un tel site, les options **14 jours** et **30 jours** sont masquées. Si une période contient trop de reports pour être lue à temps, la page vous demande de choisir une période plus courte.

Si la période ne contient aucun report, la page affiche **Aucun rapport Permissions-Policy n'a été envoyé sur cette période. Choisissez une période plus longue, ou continuez avec un modèle.**

<img alt="Le générateur Permissions-Policy à l’étape Période, avec 7 jours sélectionnés, le graphique des reports et les compteurs Rapports, Fonctionnalités utilisées et Semblent être du bruit" src="__img0" width="1544" height="737" />

## 2. Choisir une politique de départ [#2-choisir-une-politique-de-départ]

Les navigateurs ne reportent jamais la Permissions-Policy avec laquelle une page a été servie, le générateur ne peut donc pas détecter la vôtre. Vous partez d'un préréglage, ou de la politique que vous collez.

Pour choisir la politique de départ :

1. À l'étape **Politique de départ**, sélectionnez une option :
   * **Refuser toutes les fonctionnalités listées** : l'option par défaut. Refuse les 25 fonctionnalités du catalogue, y compris dans les iframes embarquées.
   * **Base pour une page de paiement** : refuse tout sauf la demande de paiement et la connexion par passkey sur votre propre origine.
   * **Autoriser la caméra et le microphone** : refuse tout sauf la caméra, le microphone et le plein écran sur votre propre origine, pour les pages d'appel vidéo ou de capture.
   * **Votre propre politique** : collez la valeur Permissions-Policy que vous envoyez aujourd'hui, sans le nom du header, ou écrivez la vôtre.
2. Vérifiez la valeur du header sous **La politique de départ**.
3. Sélectionnez **Continuer**.

<img alt="L’étape Politique de départ, avec Refuser toutes les fonctionnalités listées sélectionné et la politique qui en découle, chaque fonctionnalité listée avec une allowlist vide" src="__img1" width="1544" height="838" />

Si le générateur ne peut lire aucune fonctionnalité dans une valeur collée, le panneau le signale. Pour la valeur exacte de chaque préréglage, consultez [Préréglages de départ](/fr/docs/platform/features/builders/permissions-policy/how-it-decides#préréglages-de-départ).

## 3. Revoir les fonctionnalités [#3-revoir-les-fonctionnalités]

Le tableau liste chaque fonctionnalité de la politique que vous construisez, avec une ligne pour vos propres pages (`self`) et une par origine d'iframe. Chaque ligne est déjà tranchée : ce que vos pages et iframes ont utilisé est accordé, le bruit et les fonctionnalités appelées uniquement par des scripts tiers sont rejetés.

Pour revoir le tableau :

1. À l'étape **Revoir les fonctionnalités**, réglez le filtre des signalements sur **Depuis un cadre**.
2. Vérifiez chaque origine d'iframe. Gardez celles que vous embarquez volontairement, comme votre prestataire de paiement, et sélectionnez **Rejeter** sur toute origine que vous ne reconnaissez pas.
3. Réglez le filtre des signalements sur **Bruit**. Si une ligne de bruit correspond à une fonctionnalité que votre site utilise réellement, sélectionnez **Ajouter**.
4. Réglez le filtre des signalements sur **Script tiers**. Ces lignes arrivent rejetées. Pour voir quels scripts ont appelé la fonctionnalité, sélectionnez la ligne, puis n'accordez la fonctionnalité que si vous faites confiance à ce script.
5. (Facultatif) Sélectionnez **Rejeter** sur les fonctionnalités dont vous êtes sûr que vos pages n'ont plus besoin.
6. Sélectionnez **Continuer**.

<img alt="Le tableau Revoir les fonctionnalités, qui regroupe les autorisations de chaque fonctionnalité, avec des origines d’iframe signalées Depuis un cadre, une ligne de bruit et une ligne de script tiers rejetées, et browsing-topics marquée Refusée" src="__img2" width="1544" height="880" />

Une fonctionnalité marquée **Refusée** n'est accordée à personne, le header l'écrit donc `()`. Pour remettre chaque décision sur la recommandation du générateur, sélectionnez **Auto**. Pour chaque colonne, signalement et filtre, consultez [Tableau de revue](/fr/docs/platform/features/builders/permissions-policy/review-features).

## 4. Déployer en mode report-only [#4-déployer-en-mode-report-only]

Pour déployer la politique :

1. À l'étape **Déployer**, laissez le mode sur **Signalé** (report-only).
2. Dans le bloc de code, copiez les deux headers, ou sélectionnez **Exporter en TXT** pour télécharger les deux headers dans un fichier texte. L'export est consigné dans le [journal d'audit](/fr/docs/platform/security/audit-log#exports).
3. Si la page affiche **Les iframes ont aussi besoin de leur attribut allow**, vous avez accordé une fonctionnalité à l'origine d'une iframe. Conservez l'attribut `allow` sur cette iframe, tel qu'il est aujourd'hui.
4. Ajoutez les deux headers à chaque réponse HTML que renvoie votre site.

Les headers ressemblent à cet exemple. Le premier déclare l'endpoint :

```http
Reporting-Endpoints: centralcsp="https://MyEndpoint.report.centralcsp.com", default="https://MyEndpoint.report.centralcsp.com"
```

Le second porte la politique. Le générateur l'écrit sur une seule ligne ; elle est découpée ici pour la lecture :

```http
Permissions-Policy-Report-Only:
    accelerometer=(),
    autoplay=(),
    browsing-topics=(),
    camera=(self),
    clipboard-read=(),
    clipboard-write=(self),
    display-capture=(),
    encrypted-media=(),
    fullscreen=(self "https://video.example.com"),
    gamepad=(),
    geolocation=(self),
    gyroscope=(),
    idle-detection=(),
    local-fonts=(),
    magnetometer=(),
    microphone=(),
    midi=(),
    payment=(self "https://pay.example.com"),
    picture-in-picture=(),
    publickey-credentials-get=(),
    screen-wake-lock=(),
    serial=(),
    storage-access=(),
    usb=(),
    xr-spatial-tracking=()
```

La politique n'a pas de paramètre `report-to`. Ses reports partent vers l'endpoint `default` que déclare le header [`Reporting-Endpoints`](/fr/docs/web-security/reporting-api/headers/reporting-endpoints).

Accorder `payment` à `https://pay.example.com` dans le header ne fait que la moitié de la délégation. L'iframe doit toujours nommer la fonctionnalité dans son attribut `allow` (consultez [le lien entre le header et l'attribut allow des iframes](/fr/blog/permissions-policy-explained#comment-il-se-rapporte-à-lattribut-allow-des-iframes)) :

```html title="checkout.html"
<iframe src="https://pay.example.com/checkout" allow="payment"></iframe>
```

<img alt="L’étape Déployer en mode Signalé, avec les headers Reporting-Endpoints et Permissions-Policy-Report-Only et le rappel que les iframes ont aussi besoin de leur attribut allow" src="__img3" width="1544" height="642" />

Les navigateurs reportent désormais les fonctionnalités que la politique bloquerait, sans les bloquer.

## 5. Passer en mode bloquant [#5-passer-en-mode-bloquant]

Pour appliquer la politique :

1. Surveillez la page [Reports Permissions Policy](/fr/docs/platform/monitoring/permissions-policy) pendant au moins une semaine. Chaque violation signifie désormais que la politique bloquerait une fonctionnalité utilisée par vos pages, et chaque violation potentielle qu'une iframe a demandé une fonctionnalité que la politique refuserait.
2. Quand plus rien de ce dont vos pages ont besoin n'apparaît dans les reports, relancez le générateur sur cette semaine. Le générateur ne peut pas détecter la politique que vous avez déployée, sélectionnez donc **Votre propre politique** et collez-la.
3. À l'étape **Déployer**, sélectionnez **Appliquer**.
4. Remplacez le header report-only par le header `Permissions-Policy`.

Les navigateurs bloquent désormais les fonctionnalités que la politique n'accorde pas.

## Étapes suivantes [#étapes-suivantes]

* [Vue d’ensemble du générateur Permissions-Policy](/fr/docs/platform/features/builders/permissions-policy)
* [Tableau de revue](/fr/docs/platform/features/builders/permissions-policy/review-features)
* [Règles de décision du générateur](/fr/docs/platform/features/builders/permissions-policy/how-it-decides)
* [Report de violation Permissions-Policy](/fr/docs/web-security/reporting-api/reports/permissions-policy-violation)
