# Report-To vs Reporting-Endpoints (/fr/docs/web-security/reporting-api/concepts/report-to-vs-reporting-endpoints)



Il existe deux générations du header qui déclare les endpoints de reporting.
`Report-To` est arrivé en premier (souvent appelé Reporting API v0) et
`Reporting-Endpoints` l'a remplacé (v1). Pour presque tout, vous devriez utiliser
`Reporting-Endpoints`. La seule exception est le [Network Error Logging](/fr/docs/web-security/policies/network-error-logging), qui exige toujours `Report-To`.

## Les deux générations [#les-deux-générations]

`Report-To` (v0) déclare des groupes d'endpoints sous forme de JSON. Un groupe a un
nom, un `max_age` qui met la configuration en cache, un tableau `endpoints` qui peut
contenir plusieurs URL avec priorité et poids pour le failover, et un
`include_subdomains` optionnel. Le modèle en cache et ambiant signifiait qu'une
configuration envoyée sur une réponse pouvait s'appliquer à d'autres pages de
l'origine.

<CodeBlockTabs defaultValue="Report-To (v0)">
  <CodeBlockTabsList>
    <CodeBlockTabsTrigger value="Report-To (v0)">
      Report-To (v0)
    </CodeBlockTabsTrigger>
  </CodeBlockTabsList>

  <CodeBlockTab value="Report-To (v0)">
    ```http
    Report-To: { "group": "csp-endpoint", "max_age": 10886400,
                 "endpoints": [ { "url": "https://<Endpoint-ID>.report.centralcsp.com" } ] }
    ```
  </CodeBlockTab>
</CodeBlockTabs>

`Reporting-Endpoints` (v1) abandonne tout cela au profit d'un dictionnaire de champs
structurés de paires `name="url"` : une URL par nom, pas de groupes, pas de failover,
pas de cache. Il est porté par la réponse sur laquelle il est servi, il doit donc être
présent sur chaque réponse pouvant générer un report.

<CodeBlockTabs defaultValue="Reporting-Endpoints (v1)">
  <CodeBlockTabsList>
    <CodeBlockTabsTrigger value="Reporting-Endpoints (v1)">
      Reporting-Endpoints (v1)
    </CodeBlockTabsTrigger>
  </CodeBlockTabsList>

  <CodeBlockTab value="Reporting-Endpoints (v1)">
    ```http
    Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"
    ```
  </CodeBlockTab>
</CodeBlockTabs>

La spécification W3C Reporting ne définit que `Reporting-Endpoints` ; `Report-To`
était un mécanisme de l'ère Chromium qui n'est jamais devenu un standard, ce qui
explique qu'il soit marqué déprécié et non standard et n'ait jamais été diffusé que
dans Chromium.

## Ce qui a changé et pourquoi [#ce-qui-a-changé-et-pourquoi]

| Aspect          | `Report-To` (v0)                   | `Reporting-Endpoints` (v1)           |
| --------------- | ---------------------------------- | ------------------------------------ |
| Syntaxe         | Groupes JSON                       | Paires `name="url"`                  |
| URL par nom     | Plusieurs, avec priorité et poids  | Une                                  |
| Cache           | `max_age`, ambiant entre les pages | Aucun, par réponse                   |
| Sous-domaines   | `include_subdomains`               | Non applicable                       |
| Portée          | En cache pour l'origine            | La réponse sur laquelle il est servi |
| Standard        | Non standard, déprécié             | W3C Reporting API                    |
| Prise en charge | Chromium uniquement                | Largement pris en charge             |

Le groupement et le cache qui faisaient la souplesse de la v0 sont précisément ce que
les autres moteurs de navigateur n'étaient pas prêts à standardiser. La v1 échange
cette souplesse contre un header simple, par réponse, et ce modèle plus simple est
désormais largement pris en charge dans les navigateurs actuels.

## La confusion à quatre voies autour de report-to [#la-confusion-à-quatre-voies-autour-de-report-to]

<Callout type="info">
  « report-to » signifie des choses différentes selon le contexte. Gardez-les distincts : le header `Report-To` (v0), le header `Reporting-Endpoints` (v1, le remplaçant moderne), la directive CSP `report-to` (nomme un endpoint depuis une politique), et le paramètre `report-to=` sur les headers COOP/COEP/Permissions-Policy.
</Callout>

En pratique, la directive et le paramètre ne font que *référencer* un nom ; l'un des
deux headers doit le *déclarer* :

* `Reporting-Endpoints: csp-endpoint="https://..."` déclare l'endpoint (v1).
* `Report-To: { "group": "csp-endpoint", ... }` le déclare à l'ancienne (v0).
* `Content-Security-Policy: ...; report-to csp-endpoint` le référence depuis CSP.
* `Cross-Origin-Opener-Policy: same-origin; report-to="csp-endpoint"` le référence depuis COOP.

## Lequel utiliser [#lequel-utiliser]

Par défaut, utilisez `Reporting-Endpoints` pour tout : CSP, COOP, COEP,
Permissions-Policy, Document-Policy, Integrity-Policy, et les reports implicites de
dépréciation, d'intervention et de crash. Ne gardez `Report-To` que sur les réponses
qui envoient aussi le header `NEL`, car le Network Error Logging n'est pas pris en
charge par la v1. Pour CSP en particulier, la directive `report-to` a atteint le
statut Baseline en 2026, vous n'avez donc besoin de conserver la directive dépréciée
`report-uri` que comme repli pour les navigateurs très anciens,
voir [report-uri vs report-to](/fr/blog/report-uri-vs-report-to).

## FAQ [#faq]

### Report-To est-il déprécié ? [#report-to-est-il-déprécié-]

Oui. `Report-To` (Reporting API v0) était un mécanisme de l'ère Chromium qui n'est
jamais devenu un standard, il est donc marqué déprécié et non standard.
`Reporting-Endpoints` (v1) est le remplaçant moderne, défini par la spécification
W3C Reporting et Baseline dans les navigateurs actuels. `Report-To` ne subsiste que
pour le Network Error Logging, que la v1 ne prend pas en charge.

### Faut-il à la fois Report-To et Reporting-Endpoints ? [#faut-il-à-la-fois-report-to-et-reporting-endpoints-]

Seulement si vous utilisez le Network Error Logging, qui exige encore le header
hérité `Report-To`. Pour tout le reste, CSP, COOP, COEP, Permissions-Policy,
Document-Policy, Integrity-Policy, et les reports implicites de dépréciation,
d'intervention et de crash, `Reporting-Endpoints` seul suffit. Ne gardez `Report-To`
que sur les réponses qui envoient aussi le header `NEL`.

### report-to vs report-uri dans CSP ? [#report-to-vs-report-uri-dans-csp-]

Ce sont des générations différentes de la directive de reporting de CSP.
`report-to` nomme un endpoint déclaré par un header `Reporting-Endpoints` (ou
`Report-To`) et délivre des reports structurés de la Reporting API. `report-uri` est
la directive plus ancienne qui prend une URL directement. `report-to` a atteint le
statut Baseline en 2026 ; ne gardez `report-uri` que comme repli pour les
navigateurs très anciens.

## Voir aussi [#voir-aussi]

* [Reporting-Endpoints header](/fr/docs/web-security/reporting-api/headers/reporting-endpoints)
* [Report-To header](/fr/docs/web-security/reporting-api/headers/report-to)
* [Network Error Logging (NEL)](/fr/docs/web-security/policies/network-error-logging)
* [Report-To vs Reporting-Endpoints, lequel utiliser](/fr/blog/report-to-vs-reporting-endpoints)

## Sources [#sources]

* [Chrome, migrate to Reporting API v1](https://developer.chrome.com/blog/reporting-api-migration)
* [MDN, Reporting-Endpoints header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Reporting-Endpoints)
* [MDN, Report-To header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Report-To)