# Qu'est-ce que NEL, le network error logging du navigateur (/fr/blog/what-is-nel-network-error-logging) Vos logs serveur ont un angle mort : ils ne peuvent enregistrer que les requêtes qui ont atteint votre serveur. Les requêtes qui ont échoué à la résolution DNS, pendant le handshake TLS, ou parce que la connexion a été réinitialisée n'arrivent jamais, donc vous ne les enregistrez jamais, même si l'utilisateur a subi une erreur. Network Error Logging (NEL) comble ce manque. Il demande au navigateur de rapporter ces échecs côté client à un endpoint que vous contrôlez, depuis le seul endroit qui peut les voir : le navigateur de l'utilisateur. ## Ce que NEL vous apporte [#ce-que-nel-vous-apporte] NEL collecte le résultat des requêtes réseau, les échecs DNS, les erreurs TLS et de connexion, les réinitialisations, et les réponses HTTP en erreur, et les rapporte à votre endpoint. C'est de l'observabilité, pas de l'application : il ne bloque ni ne modifie jamais une requête, il vous dit seulement ce qui s'est passé. Cela en fait le compagnon, au niveau réseau, des rapports de politique comme la CSP, et la référence complète est la [page de la politique NEL](/fr/docs/web-security/policies/network-error-logging). Le hic, c'est que les données vivent sur le client, donc vous n'apprenez les échecs que depuis les navigateurs qui prennent en charge NEL et seulement au taux d'échantillonnage que vous configurez. Considérez-le comme un large signal d'alerte précoce, pas comme un décompte complet de chaque requête échouée. ## Comment l'activer [#comment-lactiver] NEL est la seule fonctionnalité de reporting qui utilise encore le header [`Report-To`](/fr/docs/web-security/reporting-api/headers/report-to) historique plutôt que `Reporting-Endpoints`, donc il faut deux headers qui fonctionnent ensemble. `Report-To` définit un groupe nommé et l'endroit où il envoie ; le header `NEL` active le logging, pointe vers ce groupe, et définit les taux d'échantillonnage. ```http Report-To: {"group":"nel-group","max_age":31536000,"endpoints":[{"url":"https://.report.centralcsp.com"}]} ``` ```http NEL: {"report_to":"nel-group","max_age":31536000,"include_subdomains":true,"failure_fraction":1.0} ``` Les deux fractions contrôlent le volume. Mettez `failure_fraction` à `1.0` pour rapporter chaque échec, puisque les échecs sont ce qui vous intéresse et restent relativement rares. Gardez `success_fraction` à `0` ou très bas : un site fréquenté a bien plus de succès que d'échecs, et les échantillonner à un taux significatif inonde votre endpoint. `max_age` définit combien de temps le navigateur mémorise la politique, et `include_subdomains` l'étend à vos sous-domaines. ## À quoi ressemble un rapport [#à-quoi-ressemble-un-rapport] Le navigateur envoie un [rapport `network-error`](/fr/docs/web-security/reporting-api/reports/network-error) qui nomme la phase de la requête qui a échoué (`dns`, `connection`, ou `application`) et un type d'erreur précis, ainsi que des détails de timing et de protocole. ```json { "type": "network-error", "body": { "phase": "application", "type": "http.error", "status_code": 400, "protocol": "http/1.1", "server_ip": "192.0.2.172", "elapsed_time": 338 } } ``` Le champ `phase` est le tri le plus rapide : un échec `dns` pointe vers la résolution de nom, `connection` vers le TCP ou le TLS, et `application` vers une erreur de niveau HTTP renvoyée par votre serveur (ou un CDN devant lui). ## Quand cela en vaut la peine [#quand-cela-en-vaut-la-peine] NEL gagne sa place en faisant remonter des problèmes que votre propre supervision ne peut pas voir : une mauvaise configuration TLS qui n'affecte que l'edge CDN d'une région, un souci DNS sur un résolveur particulier, ou des réinitialisations de connexion depuis un réseau précis. Comme les rapports viennent d'utilisateurs réels, vous découvrez un edge cassé avant qu'il n'apparaisse sous forme de ticket de support. Un pic soudain d'échecs TLS ou de connexion depuis une même zone peut aussi être le signe d'une interception ou d'un portail captif qui altère le trafic. NEL est expérimental et ne fonctionne actuellement que dans les navigateurs basés sur Chromium, Firefox et Safari ne l'implémentent pas. Considérez-le comme un signal utile sur une partie de votre trafic, pas comme une image complète. ## Le collecter sans backend [#le-collecter-sans-backend] Les rapports NEL utilisent le même mécanisme de livraison que vos autres rapports navigateur, donc ils arrivent dans un seul flux. Pointez l'endpoint `Report-To` vers CentralCSP pour [collecter et visualiser les erreurs réseau](/fr/docs/platform/monitoring/nel) à côté de vos rapports CSP et autres, au lieu de monter un pipeline distinct rien que pour NEL. Les requêtes en échec groupées par type d'erreur et par phase, avec des lignes dns, connection et application et leur nombre de rapports ## Étapes suivantes [#étapes-suivantes] * Comprenez les deux headers de reporting dans [Report-To vs Reporting-Endpoints](/fr/blog/report-to-vs-reporting-endpoints). * Voyez le [rapport network-error](/fr/docs/web-security/reporting-api/reports/network-error) complet. * Mettez le reporting en place de bout en bout : [comment configurer la Reporting API](/fr/blog/how-to-set-up-the-reporting-api). [Surveillez les échecs réseau côté client](/register). ## Sources [#sources] * [W3C, Network Error Logging](https://www.w3.org/TR/network-error-logging/) * [W3C, Reporting API](https://www.w3.org/TR/reporting-1/) * [MDN, NEL header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/NEL)