# Network Error Logging (/fr/docs/web-security/policies/network-error-logging)



Network Error Logging (NEL) demande au navigateur de collecter le résultat des
requêtes réseau (échecs DNS, erreurs TLS et de connexion, resets et erreurs HTTP) et
de les signaler à un endpoint serveur. Il donne aux opérateurs une visibilité sur les
échecs qui n'atteignent jamais leurs propres logs, parce que la requête a échoué
avant d'arriver. NEL est de l'observabilité, pas de l'application de règles.

<Callout type="warn" title="Expérimental, et repose sur le header hérité">
  NEL est limité à Chromium : Mozilla a pris une position de standardisation négative pour des raisons de vie privée et Safari ne l'a jamais implémenté. C'est aussi le seul mécanisme qui exige encore le header déprécié [`Report-To`](/fr/docs/web-security/reporting-api/headers/report-to) ; `Reporting-Endpoints` ne transporte pas NEL. Chrome a annoncé un mécanisme successeur, mais rien n'a été publié et aucune date de retrait n'existe, donc NEL est expérimental, pas déprécié.
</Callout>

Son activation exige les deux headers ensemble : la définition du groupe et la politique.

```http
Report-To: {"group":"nel-group","max_age":31536000,"endpoints":[{"url":"https://<Endpoint-ID>.report.centralcsp.com"}]}
```

```http
NEL: {"report_to":"nel-group","max_age":31536000,"include_subdomains":true,"success_fraction":0.0,"failure_fraction":1.0}
```

## Comment fonctionne NEL [#comment-fonctionne-nel]

Le header `NEL` est un objet JSON qui nomme un groupe `Report-To` et règle
l'échantillonnage. Le navigateur signale ensuite le résultat des requêtes vers votre
origine à l'endpoint de ce groupe, aux taux que vous configurez. Il faut deux headers
qui travaillent ensemble : `NEL` active la journalisation et pointe vers un groupe,
et [`Report-To`](/fr/docs/web-security/reporting-api/headers/report-to) définit où ce groupe
envoie ses rapports.

## Comment configurer NEL [#comment-configurer-nel]

| Champ                | Statut          | Signification                                                                                                              |
| -------------------- | --------------- | -------------------------------------------------------------------------------------------------------------------------- |
| `report_to`          | ✅ Bon           | Requis. Le nom du groupe `Report-To` qui reçoit les rapports.                                                              |
| `max_age`            | ✅ Bon           | Durée en secondes pendant laquelle le navigateur retient la politique ; `0` l'efface. Par exemple `2592000` fait 30 jours. |
| `include_subdomains` | ✅ Bon           | Applique aussi la politique aux sous-domaines. Défaut `false`.                                                             |
| `success_fraction`   | 🧪 Expérimental | Fraction des succès à signaler (0.0 à 1.0, défaut 0.0). Gardez-la petite, par exemple `0.01` sur un site à fort trafic.    |
| `failure_fraction`   | ✅ Bon           | Fraction des échecs à signaler (0.0 à 1.0, défaut 1.0).                                                                    |

## Mode Report-Only [#mode-report-only]

NEL n'a pas de header Report-Only ; c'est un mécanisme de reporting par nature,
puisqu'il ne bloque jamais rien. Vous réglez plutôt le volume avec les deux
fractions : signalez les échecs à `1.0` et les succès à `0` ou à un petit échantillon.

## Ce contre quoi il protège [#ce-contre-quoi-il-protège]

NEL relève de l'observabilité plutôt que d'un contrôle applicatif, mais il fait
remonter des problèmes que votre propre monitoring ne peut pas voir : interception
TLS ou échecs de certificat, problèmes DNS chez un résolveur donné, et échecs de
connectivité, autant de signaux de disponibilité ou d'intégrité.

## Configurations non sûres à éviter [#configurations-non-sûres-à-éviter]

<Callout type="warn">
  Les endpoints doivent être en HTTPS. Une `success_fraction` élevée peut générer de gros volumes de rapports ; échantillonnez prudemment.
</Callout>

Signalez les échecs en totalité et les succès avec parcimonie ; un site à fort trafic
qui échantillonne les succès à un taux élevé inonde l'endpoint de trafic de
routine.

## Contournements et limites connus [#contournements-et-limites-connus]

Limité à Chromium, lié au header hérité `Report-To` (pas `Reporting-Endpoints`), et
HTTPS uniquement. Firefox et Safari ne l'implémentent pas, et Mozilla a pris une
position de standardisation négative en invoquant la vie privée.

## Risques [#risques]

Échantillonner les succès à une fraction élevée est coûteux et bruyant, et un
`max_age` long fait persister la politique longtemps chez les clients, choisissez
donc les deux délibérément.

## Recommandation [#recommandation]

```http
Report-To: {"group":"nel-group","max_age":2592000,"endpoints":[{"url":"https://<Endpoint-ID>.report.centralcsp.com"}]}
```

```http
NEL: {"report_to":"nel-group","max_age":2592000,"success_fraction":0.01,"failure_fraction":1.0}
```

Signalez chaque échec (`failure_fraction` 1.0, le défaut) et un petit échantillon de
succès comme référence, avec un `max_age` de 30 jours, le tout acheminé par le header
hérité `Report-To` puisque rien d'autre ne transporte NEL. Traitez le résultat comme de la
télémétrie Chromium uniquement : il couvre les utilisateurs de Chrome, Edge et Opera,
pas toute votre audience.

## Reporting [#reporting]

La valeur `report_to` nomme un groupe dans le header `Report-To`, et le navigateur
émet le [rapport network-error](/fr/docs/web-security/reporting-api/reports/network-error) vers
l'endpoint de ce groupe. CentralCSP collecte le
[flux NEL](/fr/docs/platform/monitoring/nel) aux côtés de vos autres rapports.

## Prise en charge par les navigateurs [#prise-en-charge-par-les-navigateurs]

Navigateurs basés sur Chromium uniquement (Chrome, Edge, Opera). Mozilla a pris une
position de standardisation négative pour des raisons de vie privée et Safari ne l'a
jamais implémenté. Chrome a annoncé un mécanisme successeur, mais rien n'a été publié
et aucune date de retrait n'existe, traitez donc NEL comme expérimental et limité à
Chromium plutôt que déprécié.

## FAQ [#faq]

### Qu'est-ce que Network Error Logging ? [#quest-ce-que-network-error-logging-]

Network Error Logging (NEL) demande au navigateur de collecter le résultat des
requêtes réseau (échecs DNS, erreurs TLS et de connexion, resets et erreurs HTTP) et
de les signaler à un endpoint que vous contrôlez. Il donne aux
opérateurs une visibilité sur les échecs qui n'atteignent jamais leurs propres logs,
parce que la requête a échoué avant d'arriver. NEL est de l'observabilité, pas de
l'application de règles.

### NEL présente-t-il un risque pour la vie privée ? [#nel-présente-t-il-un-risque-pour-la-vie-privée-]

Il signale les échecs réseau à l'origine, et Mozilla a pris une position de
standardisation négative pour des raisons de vie privée, ce qui explique en partie
pourquoi Firefox et Safari ne l'ont jamais implémenté. Gardez un échantillonnage prudent :
signalez les échecs en totalité et les succès à une petite fraction ou à zéro, et
réglez `max_age` délibérément puisque la politique persiste chez les clients.

## Voir aussi [#voir-aussi]

* [rapport network-error](/fr/docs/web-security/reporting-api/reports/network-error)
* [Header Report-To](/fr/docs/web-security/reporting-api/headers/report-to)
* [Report-To vs Reporting-Endpoints](/fr/docs/web-security/reporting-api/concepts/report-to-vs-reporting-endpoints)
* [Surveillance NEL dans CentralCSP](/fr/docs/platform/monitoring/nel)

## Sources [#sources]

* [MDN, NEL header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/NEL)
* [W3C, Network Error Logging](https://www.w3.org/TR/network-error-logging/)
* [web.dev, Network Error Logging](https://web.dev/articles/network-error-logging)
* [Position de standardisation de Mozilla sur NEL](https://github.com/mozilla/standards-positions/issues/99)