# 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 livré. 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 livre pas NEL. Chrome a annoncé un mécanisme successeur, mais rien n'est livré et aucune date de retrait n'existe, donc NEL est expérimental, pas déprécié.
</Callout>

L'activer demande 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.

## 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 le volume avec les deux fractions à la
place : 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 chargé qui
échantillonne les succès à un taux significatif 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, livrés via 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 livré. Chrome a annoncé un mécanisme successeur, mais rien n'est livré 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, donc les échecs DNS, les erreurs TLS et de connexion, les resets et
les 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 livré. 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)