# Vérificateur de reporting (/fr/docs/platform/tools/reporting-api-checker)



Le vérificateur de reporting récupère une page en production, lit ses headers de reporting, et montre où chaque politique navigateur envoie ses violations. Il nomme les points de collecte (endpoints) que la réponse déclare, marque ceux vers lesquels rien ne pointe, et liste chaque politique présente qui ne reporte nulle part.

La collecte échoue en silence. Une politique avec une faute de frappe dans le nom de son point de collecte s'applique quand même, bloque quand même, et n'envoie quand même rien. Cet outil est le moyen de s'en apercevoir sans attendre des reports qui n'arriveront jamais.

## Vérifier un site [#vérifier-un-site]

1. Ouvrez **Outils** > **Vérificateur de reporting**.
2. Saisissez l'adresse, par exemple `example.com`.
3. Laissez **Suivre les redirections** activé, sauf si vous voulez la réponse à cette URL exacte.
4. Sélectionnez **Vérifier le reporting**.

## Lire l'onglet Collecte [#lire-longlet-collecte]

Le score et les constats fonctionnent comme dans les autres scanners, tels que décrits dans la [vue d'ensemble des outils](/fr/docs/platform/tools). Ce qui est propre à cet outil, c'est l'onglet **Collecte**, qui contient deux tableaux.

### Points de collecte [#points-de-collecte]

Une ligne par point de collecte que la réponse déclare.

| Colonne               | Signification                                                              |
| --------------------- | -------------------------------------------------------------------------- |
| **Point de collecte** | Le nom sous lequel le point de collecte est déclaré, par exemple `default` |
| **URL**               | Où sont envoyés les reports pour ce nom                                    |
| **Statut**            | `Utilisé` si au moins une politique pointe dessus, `Inutilisé` sinon       |
| **Déclaré dans**      | Quel header l'a déclaré, `reporting-endpoints` ou `report-to`              |

Un point de collecte `Inutilisé` est du poids mort, et en général le signe qu'une politique nomme un point de collecte différent de celui que vous avez configuré.

La colonne **Déclaré dans** est l'endroit où une configuration héritée se voit. [`Reporting-Endpoints`](/fr/docs/web-security/reporting-api/headers/reporting-endpoints) est le header actuel. [`Report-To`](/fr/docs/web-security/reporting-api/headers/report-to) est le header déprécié, et il reste le seul header depuis lequel [Network Error Logging](/fr/docs/web-security/policies/network-error-logging) lit son point de collecte, un site qui utilise NEL garde donc les deux.

### Fonctionnalités reportées [#fonctionnalités-reportées]

Une ligne par politique que la réponse porte.

| Colonne            | Signification                                                                                            |
| ------------------ | -------------------------------------------------------------------------------------------------------- |
| **Fonctionnalité** | La politique, par exemple Content-Security-Policy ou le reporting des hashes de scripts CSP              |
| **Présent**        | Si la réponse envoie la politique                                                                        |
| **Envoie vers**    | L'URL du point de collecte vers lequel ses violations aboutissent, ou vide si elle ne reporte nulle part |
| **Mode**           | `Bloqué` si la politique bloque, `Signalé` si elle ne fait que reporter                                  |

Le vérificateur couvre Content-Security-Policy, le reporting des hashes de scripts CSP, Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, Permissions-Policy, Document-Policy, Integrity-Policy, Connection-Allowlist et Network Error Logging.

## Ce que les trois états vous disent [#ce-que-les-trois-états-vous-disent]

Lire les deux tableaux ensemble donne une réponse parmi trois pour chaque politique.

* **Présente et pointant vers un point de collecte utilisé.** Les reports sont bien livrés. Regardez ensuite la colonne **Mode**, parce qu'une politique Report-Only remonte sans bloquer.
* **Présente avec un Envoie vers vide.** La politique est active et ses violations ne vont nulle part. Ajoutez une directive [`report-to`](/fr/docs/web-security/policies/content-security-policy/directives/report-to) qui nomme un point de collecte que vous avez déclaré.
* **Manquant.** La politique n'est pas envoyée du tout, il n'y a donc rien à reporter.

Une ligne `Signalé` sur plusieurs politiques est un état courant et délibéré pendant un déploiement progressif. Cela devient un constat parce que signalé n'est pas bloqué, et un déploiement laissé à moitié fini ressemble exactement à la même chose vu de l'extérieur.

## Vérifier votre propre point de collecte [#vérifier-votre-propre-point-de-collecte]

Quand vous pointez un site vers CentralCSP, la même vérification tourne derrière [Connecter votre site](/fr/docs/platform/websites/connect-your-site) pour confirmer que vos headers nous parviennent. Lancer l'outil à la main est le moyen de revérifier plus tard, après qu'un changement de CDN ou une montée de version de framework a réécrit vos headers.

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

* [Connecter votre site](/fr/docs/platform/websites/connect-your-site) pour commencer à collecter les reports
* [Référence Reporting API](/fr/docs/web-security/reporting-api)
* [Scanner d'en-têtes](/fr/docs/platform/tools/security-header-scanner), qui inclut le même onglet Collecte
* [Vue d'ensemble des outils](/fr/docs/platform/tools) pour le partage, l'export et les limites