---
title: "Corriger l’erreur de script qui cache son message, son fichier et sa ligne"
description: "Script error. avec la ligne 0 et sans stack trace signifie que le navigateur a caché l’erreur d’un script d’une autre origine. Ajoutez crossorigin et un en-tête CORS pour retrouver le message."
canonical: "https://logbrew.co/fr/errors/script-error"
last_updated: "2026-11-10"
---

# Corriger l’erreur de script qui cache son message, son fichier et sa ligne

`Script error.` avec la ligne 0 et sans stack trace signifie que le navigateur a caché l’erreur d’un script d’une autre origine. Ajoutez `crossorigin` et un en-tête CORS pour retrouver le message.

Testé le 10 novembre 2026 avec Chromium 152, @logbrew/browser 0.1.21 et @logbrew/sdk 0.1.44

Par [Furkan Erday](https://github.com/furkanerday). Furkan Erday est le fondateur de LogBrew. Il développe LogBrew avec Claude Code et Codex tous les jours.

Canonical: https://logbrew.co/fr/errors/script-error

## Ce que la page apprend d’un script qui lève une erreur

| Comment le script se charge | Script exécuté | Détails de l’erreur |
| --- | --- | --- |
| Depuis l’origine de la page | Exécuté | Complets |
| Depuis une autre origine | Exécuté | `Script error.` |
| Autre origine, `crossorigin` et l’en-tête CORS | Exécuté | Complets |
| Autre origine, `crossorigin` et aucun en-tête | Bloqué | Aucun |

1 script, chargé de 4 façons. Complets signifie le message, le fichier, la ligne 1, la colonne 7 et la stack trace, lus depuis l’événement `error` sur `window`.

## Retrouver l’erreur complète

### Chargez le script avec l’attribut crossorigin

L’attribut demande au navigateur de récupérer le fichier avec CORS. Quand le serveur l’autorise, le navigateur transmet le vrai message, le fichier, la ligne et la stack trace aux écouteurs d’erreur de la page.

```bash
<script src="https://cdn.example.com/app.js" crossorigin="anonymous"></script>
```

### Envoyez l’en-tête CORS depuis le serveur du fichier

Le serveur qui héberge le script doit répondre avec `Access-Control-Allow-Origin` réglé sur l’origine de votre page, ou `*` pour un fichier public. Dans notre test, cet en-tête seul a transformé `Script error.` en message complet.

```bash
Access-Control-Allow-Origin: *
```

### Vérifiez que le fichier se charge toujours

Avec `crossorigin` et sans en-tête, le navigateur bloque le fichier et le script ne s’exécute jamais. La console affiche alors `blocked by CORS policy` et `net::ERR_FAILED`, et l’élément `script` déclenche son événement `error`.

Sortie

```text
Access to script at 'http://127.0.0.1:4874/plain/throws.js?scenario=script-cross-origin-attr-no-header' from origin 'http://127.0.0.1:4873' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Failed to load resource: net::ERR_FAILED
```

### Ou servez le script depuis votre propre origine

Un script servi depuis l’origine de la page ne met jamais ses erreurs en sourdine. Regroupez le fichier dans le bundle de votre application, ou servez-le via un proxy sur votre domaine, et aucun en-tête n’est nécessaire.

## Gérer les erreurs en sourdine qui arrivent encore

### Comptez-les, puis trouvez le script

`Script error.` ne contient rien à corriger. Chacune signifie qu’un script d’une autre origine a levé une erreur. Cherchez les balises sans `crossorigin` et commencez par celles qui se chargent sur chaque page.

### Lisez le vrai message dans la console

Le navigateur affiche l’erreur complète dans la console même quand il la met en sourdine pour vos écouteurs. Dans notre test, la console a affiché `Uncaught Error: Keg is empty` pendant que `window.onerror` recevait `Script error.`.

### Décidez quoi faire des balises tierces

Un widget de chat ou une balise de mesure d’audience sans en-tête CORS vous laisse 2 choix. Gardez-la telle quelle et acceptez des erreurs en sourdine, ou ajoutez `crossorigin` pour qu’un en-tête manquant bloque la balise et apparaisse comme un chargement en échec.

## Ce que nous avons vu en testant

Nous avons placé 1 script qui lève une erreur, `throw new Error("Keg is empty: no beer left for order 42");`, sur 2 serveurs locaux. La page tournait sur `http://127.0.0.1:4873` dans Chromium 152 avec `@logbrew/browser` 0.1.21 installé, et un second serveur sur `http://127.0.0.1:4874` jouait le rôle du CDN. Nous avons chargé le script de 4 façons et lu l’événement `error` sur `window` à chaque fois.

Depuis l’origine de la page, l’événement contenait `Uncaught Error: Keg is empty: no beer left for order 42`, le fichier `/throws.js`, la ligne 1, la colonne 7 et un objet `Error` avec une stack trace. Depuis l’autre origine sans `crossorigin`, l’événement contenait `Script error.`, un nom de fichier vide, la ligne 0, la colonne 0 et aucun objet `Error`. La console affichait quand même le message complet.

Avec `crossorigin="anonymous"` et `Access-Control-Allow-Origin: *` sur le CDN, l’événement contenait de nouveau tous les détails. Avec l’attribut et sans en-tête, le navigateur a bloqué le fichier, le script ne s’est jamais exécuté et l’élément `script` a déclenché son événement `error`.

## Pourquoi le navigateur cache le message

Le standard HTML met en sourdine les erreurs des scripts que la page a récupérés depuis une autre origine sans CORS. Son algorithme marque les erreurs comme mises en sourdine quand la réponse était CORS-cross-origin, puis signale l’erreur comme `Script error.` sans URL, avec la ligne 0, la colonne 0 et aucun objet d’erreur.

Le navigateur traite le texte d’erreur d’un script cross-origin comme une donnée de ce script, donc la page n’en reçoit rien. La page MDN sur `crossorigin` dit la même chose en 1 ligne. L’accès à la journalisation des erreurs via `window.onerror` est limité pour ces scripts.

whatwg/html#2440 demandait un moyen d’obtenir les détails sans CORS. Il a été fermé en juillet 2024, le jour où whatwg/html#10514 a été ouvert pour signaler que les navigateurs ne mettent pas les mêmes cas en sourdine de la même façon. Ce ticket est toujours ouvert.

## Ce que LogBrew enregistre

Avec les détails complets, le SDK navigateur a envoyé 1 problème nommé `Browser error: Error`, avec un frame de stack trace pour `/throws.js` à la ligne 1, colonne 7, le chemin source et la clé de regroupement `browser.error:Error:/throws.js`. Chaque script qui lève une erreur reçoit son propre problème.

Avec l’erreur en sourdine, le problème portait le même nom, sans frame de stack trace, avec la ligne 0, la colonne 0 et la clé de regroupement `browser.error:Error`. Les erreurs en sourdine partagent ce 1 problème, donc son compteur vous dit combien d’erreurs vous ne voyez pas encore.

Les 2 événements contenaient le chemin de la page, le runtime `Chromium 152` sur `macOS` et un breadcrumb `page_view`. Aucun ne contenait le texte du message. Le SDK l’a marqué `redacted`.

## Questions fréquentes

### Que signifie l’erreur de script en JavaScript ?

Un script d’une autre origine a levé une erreur, et le navigateur a caché les détails à la page parce que le fichier n’a pas été chargé avec CORS. Le script lui-même s’est exécuté.

### Pourquoi l’erreur de script a-t-elle la ligne 0 et aucune stack trace ?

Le standard HTML remplace le message, le fichier, la ligne, la colonne et l’objet d’erreur quand il met une erreur en sourdine. Il ne reste que la chaîne `Script error.`.

### L’erreur de script signifie-t-elle que le script n’a pas pu se charger ?

Non. Un script qui ne se charge pas déclenche l’événement `error` sur son élément `script` et ne s’exécute jamais. `Script error.` signifie que le script s’est exécuté et a levé une erreur.

### Puis-je voir le message sans modifier le serveur ?

Dans la console du navigateur, oui. Dans votre suivi des erreurs, non. La page a besoin de `crossorigin` sur la balise et de l’en-tête CORS du serveur, ou du script sur votre propre origine.

### Dois-je exclure l’erreur de script de mon suivi des erreurs ?

Comptez-la plutôt. Le nombre vous dit combien d’erreurs vous ne voyez pas, et il tombe à 0 dès que chaque script cross-origin se charge avec CORS.

## Comptez les erreurs que vous ne voyez pas encore

Le SDK navigateur de LogBrew garde chaque erreur en sourdine dans 1 problème et donne à chaque vraie erreur son fichier, sa ligne et sa stack trace. Commencez avec le généreux forfait Free, sans carte bancaire.

[Commencer gratuitement](https://logbrew.co/fr)

## Sources

- [MDN, Window: error event](https://developer.mozilla.org/en-US/docs/Web/API/Window/error_event)
- [MDN, crossorigin attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/crossorigin)
- [HTML Standard, Runtime script errors](https://html.spec.whatwg.org/multipage/webappapis.html#runtime-script-errors)
- [whatwg/html#2440](https://github.com/whatwg/html/issues/2440)
- [whatwg/html#10514](https://github.com/whatwg/html/issues/10514)

## D’autres correctifs d’erreurs JavaScript

- [Corriger l’erreur Failed to fetch et distinguer ses 3 causes](https://logbrew.co/fr/errors/failed-to-fetch)
- [Les erreurs JavaScript que nous avons reproduites, et comment corriger chacune](https://logbrew.co/fr/errors)
