# 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. Comme ce modèle reposait sur un cache valable pour
toute l'origine, une configuration envoyée sur une seule 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. Sa portée se limite à la réponse qui le transporte : il doit donc figurer
sur chaque réponse susceptible de 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 : il est
marqué déprécié et non standard, et n'a jamais été implémenté ailleurs 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 troque
cette souplesse contre un header minimal, valable pour une seule réponse, et c'est ce
modèle-là qui est aujourd'hui 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. Ne les confondez pas : 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 la v1 ne prend pas en charge le Network Error
Logging. 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 achemine 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)