# Vue d’ensemble (/fr/docs/platform/features/builders/permissions-policy) Le générateur Permissions-Policy écrit un header [Permissions-Policy](/fr/docs/web-security/policies/permissions-policy) à partir de vos propres reports. Ce header indique au navigateur quelles fonctionnalités, comme la caméra, la géolocalisation ou la fenêtre de paiement, vos pages et les iframes qu'elles embarquent peuvent utiliser. Vous choisissez les reports à analyser, partez d'un préréglage ou de votre propre politique, accordez chaque fonctionnalité aux pages et iframes qui l'utilisent, puis copiez les headers. Le générateur se trouve sous chaque site, dans la barre latérale, sous **Générateurs** > **Permissions-Policy**, à côté du [générateur CSP](/fr/docs/platform/features/builders/csp) et du [générateur Connection-Allowlist](/fr/docs/platform/features/builders/connection-allowlist). Il fonctionne sur tous les plans, et tous les rôles d'un site peuvent l'utiliser. Pour ce que les trois générateurs ont en commun, consultez [Générateurs](/fr/docs/platform/features/builders). 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, une fonctionnalité accordée ne prouve donc pas que vos pages l'utilisent. Revoyez les autorisations avant de déployer, en commençant par les fonctionnalités accordées à une autre origine. Une politique issue de l'API ou de l'outil MCP applique les mêmes réglages par défaut, sans revue, alors vérifiez-la de la même façon. 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é. ## Ce que produit le générateur Permissions-Policy [#ce-que-produit-le-générateur-permissions-policy] Le générateur aboutit à deux headers de réponse, prêts à coller dans la configuration de votre serveur ou de votre réseau de diffusion de contenu (CDN). Un header [`Reporting-Endpoints`](/fr/docs/web-security/reporting-api/headers/reporting-endpoints) envoie les reports vers l'endpoint CentralCSP de votre site. Un header `Permissions-Policy-Report-Only` porte la politique, ou `Permissions-Policy` une fois que vous passez en mode bloquant. Chaque fonctionnalité de la politique se lit de l'une de trois façons. `()` la refuse partout, `self` l'accorde à vos propres pages, et une origine entre guillemets l'accorde à une iframe de cette origine : ```http Permissions-Policy-Report-Only: camera=(), geolocation=(self), payment=(self "https://pay.example.com") ``` Le générateur n'écrit aucun paramètre `report-to` dans la politique. Ses reports partent vers l'endpoint nommé `default`, que le header `Reporting-Endpoints` déclare à côté de `centralcsp`. Consultez [L'endpoint par défaut](/fr/docs/web-security/reporting-api/concepts/default-endpoint). Le générateur n'enregistre ni ne déploie rien, et contrairement au générateur CSP, il ne note pas la politique. Il vous fournit les headers, et vous les ajoutez à votre site. Chaque export, les headers en TXT ou le tableau de revue en CSV, est consigné dans le [journal d'audit](/fr/docs/platform/security/audit-log#exports). ## Fonctionnement [#fonctionnement] Le générateur fonctionne en quatre étapes. Chaque étape reprend la réponse de la précédente. 1. **Période** : choisissez les jours de reports à analyser, jusqu'aux 30 derniers. 2. **Politique de départ** : partez d'un préréglage, par défaut celui qui refuse toutes les fonctionnalités listées, ou collez la politique que vous envoyez aujourd'hui. 3. **Revoir les fonctionnalités** : accordez ou rejetez chaque fonctionnalité, pour vos propres pages et pour chaque origine d'iframe. Chaque ligne arrive déjà tranchée : ce que vos pages et iframes ont utilisé est accordé, et le bruit ainsi que les fonctionnalités appelées uniquement par un script tiers arrivent rejetés. 4. **Déployer** : choisissez le mode report-only ou bloquant, et copiez les headers. Les réglages par défaut conservent ce que vos pages et iframes ont utilisé sur la période, et refusent le reste du catalogue. 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 ## D'où viennent les données [#doù-viennent-les-données] Le générateur lit deux types de report que votre site collecte déjà : * Un report de [violation Permissions-Policy](/fr/docs/web-security/reporting-api/reports/permissions-policy-violation), envoyé quand l'une de vos pages utilise une fonctionnalité que la politique bloque. Il devient une autorisation pour `self`. * Un report `potential-permissions-policy-violation`, envoyé quand l'attribut `allow` d'une iframe demande une fonctionnalité. Il devient une autorisation pour l'origine de cette iframe. La page [Reports Permissions Policy](/fr/docs/platform/monitoring/permissions-policy) montre les mêmes données, dans ses vues **Violations** et **Potentielles**. Pour comprendre pourquoi la vue **Potentielles** compte avant de passer en mode bloquant, consultez [Vérifiez Potentiel avant de faire appliquer](/fr/docs/platform/monitoring/permissions-policy#vérifiez-potentiel-avant-de-faire-appliquer). ### Pourquoi il n'y a pas de politique détectée [#pourquoi-il-ny-a-pas-de-politique-détectée] Un report CSP contient la politique qui l'a produit, le générateur CSP peut donc détecter la politique que vous servez. Un report Permissions-Policy ne contient jamais la politique servie. Le générateur ne peut pas voir ce que vous envoyez aujourd'hui, il part donc d'un préréglage, ou de la politique que vous collez. La revue ajoute ensuite ce que votre site a utilisé d'après les reports. Pour savoir comment le générateur transforme les reports en autorisations, repère le bruit et écrit le header, consultez [Règles de décision du générateur](/fr/docs/platform/features/builders/permissions-policy/how-it-decides). ## Utilisation depuis l'API et le serveur MCP [#utilisation-depuis-lapi-et-le-serveur-mcp] L'API REST construit la même politique sans l'assistant. L'endpoint **Build a recommended Permissions-Policy** accepte une période et une politique de départ, toutes deux facultatives, et renvoie deux valeurs de header : `policy` pour le header Permissions-Policy et `reportingEndpoints` pour le header `Reporting-Endpoints`. Sans politique de départ, il refuse toutes les fonctionnalités listées, puis rend ce que vos pages et iframes ont utilisé, en laissant de côté le bruit et les fonctionnalités appelées uniquement par des scripts tiers. Consultez la [référence de l'API](/fr/docs/api-mcp/api). Le [serveur Model Context Protocol (MCP)](/fr/docs/api-mcp/mcp) expose cet endpoint sous la forme de l'outil `build_recommended_permissions_policy`. ## Étapes suivantes [#étapes-suivantes] * [Démarrer](/fr/docs/platform/features/builders/permissions-policy/get-started) * [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) * [Reports Permissions Policy](/fr/docs/platform/monitoring/permissions-policy) * [Référence Permissions-Policy](/fr/docs/web-security/policies/permissions-policy) * [Verrouiller les fonctionnalités du navigateur avec Permissions-Policy](/fr/blog/permissions-policy-explained)