> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Browser error tracking

<Note>
  Browser monitoring est une fonctionnalité en beta d'[AppSignal Labs](/labs). Le
  package `@appsignal/browser` est publié sous le tag `beta` sur npm, et sa
  configuration ainsi que son API peuvent encore changer d'une release beta à
  l'autre. Partagez vos retours dans notre
  [communauté Discord](https://discord.gg/EjF6ykYx63).
</Note>

Une fois `init()` exécuté, AppSignal pour Browser rapporte les erreurs non interceptées de lui-même. Il n'y a rien à envelopper ni de gestionnaire à enregistrer.

Il écoute deux choses sur le `window` principal de la page :

* Les erreurs que votre code lève et n'intercepte jamais, via l'événement `error`.
* Les promesses qui échouent sans que rien ne traite l'échec, via l'événement `unhandledrejection`.

Le SDK commence à envoyer chaque erreur dès qu'elle est capturée, sans attendre un lot de web vitals. La livraison dépend toujours du navigateur et du réseau.

<h2 id="what-is-reported">
  Ce qui est rapporté
</h2>

* **Nom et message de l'erreur.** Le type d'erreur, par exemple `TypeError`, et le message qui l'accompagnait.
* **Backtrace.** La stack trace, une ligne par frame. Vide si le navigateur n'en fournit aucune.
* **Action.** La route sur laquelle l'erreur s'est produite. Les erreurs sont regroupées par cette valeur.
* **Révision.** L'`appVersion` que vous avez définie. Utilisée pour filtrer par version et pour trouver les bons sourcemaps.
* **Tags.** Tout ce que vous avez défini avec `setTags()`.
* **Nom de service.** Le `serviceName` que vous avez défini, ou `Browser`. Il identifie le front-end parmi les services d'une trace.
* **Breadcrumbs.** Jusqu'à 25 [breadcrumbs](/browser/breadcrumbs) récents qui aident à expliquer l'erreur.
* **URL et user agent.** La page où l'erreur s'est produite, avec les paramètres de requête retirés selon votre [allowlist](/browser/privacy#urls-and-query-parameters), et le user agent du navigateur.

Une promesse rejetée peut contenir une valeur autre qu'une `Error`. Le SDK transforme cette valeur en message d'erreur quand il le peut.

Les erreurs sont rapportées dans le namespace `browser` (voir les [namespaces](/guides/namespaces)), ce qui les garde distinctes de vos erreurs back-end et de leurs réglages de notification.

<h2 id="how-errors-are-grouped">
  Comment les erreurs sont regroupées
</h2>

Les erreurs se regroupent par action. C'est le template défini avec `setRouteTemplate()`, ou le chemin brut de la page si aucun n'a été défini.

Déclarer un template est ce qui empêche une route riche en identifiants de se fragmenter en un groupe d'erreurs par identifiant :

<CodeGroup>
  ```js JavaScript theme={null}
  import { setRouteTemplate } from "@appsignal/browser";

  // Every error on this route now groups under "/orders/:id"
  setRouteTemplate("/orders/:id");
  ```
</CodeGroup>

Appelez-le à chaque navigation de votre routeur. C'est la même valeur à laquelle [les web vitals sont attribuées](/browser/web-vitals#how-values-are-attributed-to-routes) : un seul appel couvre donc les deux.

<h2 id="reporting-errors-manually">
  Rapporter des erreurs manuellement
</h2>

Utilisez `captureError()` pour les erreurs que vous interceptez vous-même. Elle passe par le même pipeline qu'une erreur non interceptée, breadcrumbs, tags, échantillonnage et `beforeError` compris :

<CodeGroup>
  ```js JavaScript theme={null}
  import { captureError } from "@appsignal/browser";

  try {
    await submitOrder(order);
  } catch (error) {
    captureError(error);
  }
  ```
</CodeGroup>

Le SDK actuel accepte un second argument de contexte, mais ne l'inclut pas dans les rapports d'erreur ordinaires. Utilisez [`setTags()`](#tags) pour les valeurs qui doivent apparaître sur les erreurs suivantes.

Les applications React peuvent intercepter les erreurs de rendu avec l'[error boundary](/browser/react) au lieu d'envelopper les composants à la main.

<h2 id="failed-requests">
  Requêtes échouées
</h2>

Avec [`tracePropagationTargets`](/browser/configuration#tracepropagationtargets) défini, une requête vers votre API qui répond par un code 5xx ou expire est rapportée séparément. Elle arrive sous forme de `HTTPError` ou de `TimeoutError`, portant l'ID de trace envoyé par la requête au back-end. Si le back-end a poursuivi la trace, ses spans apparaissent sous l'erreur du navigateur dans la chronologie de la trace. Pour en savoir plus, consultez [le tracing distribué pour Browser](/browser/distributed-tracing).

<h2 id="tags">
  Tags
</h2>

Les tags sont des paires clé-valeur de chaînes attachées à chaque erreur rapportée à partir de ce moment. Ce sont eux qui vous servent à filtrer et à rechercher des erreurs dans AppSignal :

<CodeGroup>
  ```js JavaScript theme={null}
  import { setTags, clearTags } from "@appsignal/browser";

  // After authentication, once the values are known
  setTags({ plan: user.plan, org_id: user.orgId });

  // On sign-out. Tags survive a reload, so clear them explicitly
  clearTags();
  ```
</CodeGroup>

Chaque appel s'ajoute aux tags déjà définis plutôt que de les remplacer. Les valeurs deviennent du texte. Une valeur vide supprime son tag. Vous pouvez garder jusqu'à 32 tags ; le plus ancien est écarté en cas de besoin. Les valeurs longues sont réduites à 256 octets à leur arrivée. Pour en savoir plus, consultez notre [guide du tagging](/application/tagging).

Quelques noms de tags font plus que filtrer. Les tags `country_code`, `country` et `browser` produisent des [distributions d'attributs](/guides/tagging/attribute-distributions). N'importe quel tag peut être transformé en lien avec les [templates de liens](/application/link-templates).

<h2 id="rate-limits">
  Limites de débit
</h2>

Une page coincée dans une boucle peut lever des milliers d'erreurs par seconde. Deux limites empêchent le SDK de devenir le problème qu'il est censé rapporter :

* **La même erreur, encore et encore.** Le message et la première ligne de stack trace déterminent si deux erreurs sont des répétitions. AppSignal la rapporte au maximum cinq fois toutes les 10 secondes.
* **Trop d'erreurs à la fois.** Pas plus de 100 erreurs rapportées toutes les 10 secondes au total. Cela attrape une page qui lève de nombreuses erreurs *différentes*, ce que la première limite laisserait passer.

Si des erreurs disparaissent pendant qu'une page se comporte mal, l'une de ces deux limites en est la raison. Pour envoyer volontairement moins d'erreurs, définissez plutôt [`errors.sampleRate`](/browser/configuration#errors-samplerate).

<h2 id="sourcemaps">
  Sourcemaps
</h2>

Un bundle minifié produit des stack traces pleines de noms d'une lettre et de numéros de ligne énormes. Les [sourcemaps](/front-end/sourcemaps) les retransforment en noms de fichiers, fonctions et numéros de ligne que vous avez écrits. Chaque erreur envoie `appVersion` comme révision. AppSignal l'utilise pour trouver les sourcemaps de ce build. Sans elle, les stack traces restent minifiées.

Si vos sourcemaps sont publics, à côté de vos fichiers JavaScript, il n'y a rien de plus à faire. Si vous préférez ne pas les publier, envoyez-les à l'[endpoint API des sourcemaps](/api/sourcemaps) en utilisant la même révision.

<h2 id="errors-that-are-not-reported">
  Les erreurs qui ne sont pas rapportées
</h2>

<Warning>
  Certaines erreurs n'atteignent jamais le SDK. La plupart sont des restrictions
  du navigateur plutôt que des limites d'AppSignal, et chacune a une solution de
  contournement.
</Warning>

**Les erreurs de scripts sur un autre domaine.** Quand un script chargé depuis ailleurs lève une erreur, le navigateur refuse de partager les détails. Tout ce que votre page voit est le message `Script error.`, sans stack trace ni numéro de ligne. Le SDK écarte ces erreurs opaques car elles ne contiennent aucun détail utile. Pour capturer les erreurs de scripts servis par un CDN, envoyez un en-tête `Access-Control-Allow-Origin` depuis le CDN. Ajoutez `crossorigin="anonymous"` aux balises de script.

**Les erreurs à l'intérieur d'iframes.** Le SDK n'écoute que le `window` où il s'exécute. Pour surveiller un iframe que vous contrôlez, initialisez aussi le SDK à l'intérieur de ce frame. La page parente ne peut pas capturer les erreurs d'un iframe cross-origin.

**Les erreurs avant `init()`.** Tout ce qui est levé avant l'exécution d'`init()` est manqué. Importez votre configuration AppSignal en premier, avant les autres bibliothèques et votre propre code.

<h2 id="filtering-out-browser-noise">
  Filtrer le bruit du navigateur
</h2>

Certaines erreurs proviennent du navigateur ou de ses extensions, pas de votre code, et vous ne pouvez pas les corriger. L'option **Error filtering** du parcours d'installation les écarte avec `beforeError` :

<CodeGroup>
  ```js appsignal.js theme={null}
  import { init } from "@appsignal/browser";

  const IGNORED = [
    /ResizeObserver loop/,
    /^Script error\.?$/,
    /-extension:\/\//,
    /webkit-masked-url/,
  ];

  init({
    key: "<YOUR_FRONTEND_API_KEY>",
    beforeError: (error) => {
      const text = [error.message, error.stack, error.filename].join(" ");
      return IGNORED.some((pattern) => pattern.test(text)) ? null : error;
    },
  });
  ```
</CodeGroup>

Chaque motif est comparé au message, à la stack trace et au nom de fichier de l'erreur :

* `ResizeObserver loop` : un avertissement du navigateur indiquant que les notifications de redimensionnement ont été reportées à la prochaine frame. Généralement sans gravité.
* `Script error.` : une erreur provenant d'un script sur un autre domaine, sans détail pour déboguer. Le SDK écarte déjà celles qui arrivent sans stack trace.
* `-extension://` : une erreur provenant d'une extension de navigateur, comme un script `chrome-extension://` ou `moz-extension://`.
* `webkit-masked-url` : l'adresse que Safari affiche à la place du script d'une extension.

Ajoutez un motif à `IGNORED` pour toute autre erreur que vous avez décidé d'ignorer. Une erreur écartée ne laisse aucun breadcrumb et ne compte pas comme une répétition. Elle compte en revanche dans la [limite](#rate-limits) de 100 erreurs toutes les 10 secondes. Pour en savoir plus, consultez [filtrer les erreurs et les breadcrumbs](/browser/privacy#filtering-errors-and-breadcrumbs).

<h2 id="reviewing-errors-in-appsignal">
  Examiner les erreurs dans AppSignal
</h2>

La vue Errors les regroupe en issues que vous pouvez filtrer par version et par période, assigner, et pour lesquelles vous pouvez être notifié. Pour en savoir plus, consultez [les erreurs front-end dans AppSignal](/browser-monitoring/errors).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.