> ## 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.

# Les erreurs front-end dans AppSignal

> Comment les erreurs front-end sont regroupées en issues, et ce que la vue Errors vous montre.

<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>

La vue Errors répertorie les erreurs que votre front end a rapportées, regroupées en issues. C'est le même modèle d'issues que celui de vos erreurs back-end : tout ce que vous faites déjà avec une exception venue de Ruby ou de Node.js fonctionne aussi ici.

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

Les occurrences d'un même type d'erreur sur une même route forment une seule issue. Un bug qui se déclenche dix mille fois est une seule chose à trier, au lieu de dix mille notifications.

La route est celle que le SDK a rapportée via [`setRouteTemplate()`](/browser/installation#report-the-current-route), ou le chemin de la page si rien n'a été déclaré. C'est pourquoi déclarer des templates compte : sans eux, `/orders/1` et `/orders/2` sont des routes différentes, et un bug se fragmente en une issue par commande.

<h2 id="reading-the-issue-list">
  Lire la liste des issues
</h2>

Chaque issue de la liste porte :

* La classe d'erreur et le message, avec la route sur laquelle l'erreur s'est produite.
* La version dans laquelle elle a été **introduite**, souvent le moyen le plus rapide de repérer une régression : une nouvelle issue sur votre release la plus récente est une release à regarder de près.
* Une **tendance** sur la période sélectionnée, pour qu'un pic se lise différemment d'un filet continu.
* Le nombre **total** d'occurrences sur la période.
* La date de la **dernière** occurrence.
* La personne à qui elle est **assignée**.

Vous pouvez trier par occurrence la plus récente ou par volume, selon que vous triez ce qui vient de casser ou ce qui casse le plus souvent.

<h2 id="filtering-by-time-and-version">
  Filtrer par période et par version
</h2>

* **Période.** Des préréglages d'une heure à 30 jours, ou une plage personnalisée.
* **Version.** Restreignez la liste aux erreurs rapportées par une seule release. Combiné à la colonne d'introduction, c'est ainsi que vous confirmez si un deploy est responsable.

<h2 id="investigating-an-issue">
  Enquêter sur une issue
</h2>

Ouvrir une issue affiche un sample de l'erreur : quand elle s'est produite, la page concernée et le deploy dans lequel elle est apparue en premier, ainsi que quatre éléments à partir desquels déboguer.

* **Le message d'erreur**, en entier. C'est là que se trouve le sens. `TypeError` ne dit presque rien à lui seul, tandis que `Failed to fetch dynamically imported module` vous apprend qu'un chunk chargé paresseusement n'est jamais arrivé.
* **Les tags** que vous avez définis avec [`setTags()`](/browser/error-tracking#tags), affichés à côté du user agent et de la révision, si vous avez défini [`appVersion`](/browser/configuration#appversion). Quelques noms de tags font plus que filtrer. Taguez avec `country_code` ou `browser` et vous obtenez des [distributions d'attributs](/guides/tagging/attribute-distributions), qui montrent quels pays ou quels navigateurs voient le plus d'erreurs. Les [templates de liens](/application/link-templates) transforment un tag en lien, si bien qu'un tag `user_id` peut ouvrir cet utilisateur dans votre propre back-office.
* **La backtrace**, que vous pouvez lire en entier ou restreinte à votre propre application. Les stacks front-end sont souvent presque entièrement composées de frames de framework. Un échec de `removeChild` venu de React arrive comme un mur de frames `react-dom` sans rien de chez vous en vue, et la vue application est ce qui permet d'y voir clair.
* **La [chronologie des breadcrumbs](/browser/breadcrumbs)** qui a mené à l'erreur, et c'est généralement la partie qui vous sauve.

Chaque breadcrumb porte son propre détail. Une entrée réseau montre la méthode, l'URL, le statut de la réponse et la durée de la requête. Une entrée de sélection montre quel élément l'utilisateur a sélectionné. Une entrée de long task nomme le script qui a bloqué le thread principal, et pendant combien de temps. Une piste qui va d'une sélection à l'erreur en passant par une requête GraphQL de près de trois secondes constitue souvent l'explication complète, sans rien reproduire.

Les backtraces issues d'un bundle minifié sont résolues grâce aux [sourcemaps](/browser/error-tracking#sourcemaps), mises en correspondance sur la version de l'application. Sans version définie, les backtraces restent minifiées.

Un sample peut être exporté en JSON ou en Markdown, ce qui est le moyen le plus rapide de l'attacher à un ticket ou de le transmettre à un assistant. Chaque issue possède aussi un journal, où vous et votre équipe consignez en Markdown ce que vous avez trouvé.

<h2 id="triage-and-notifications">
  Tri et notifications
</h2>

Les issues peuvent être assignées, dotées d'un état, mises en sourdine et configurées avec leurs propres réglages de notification, et le reste de l'outillage d'incidents d'AppSignal fonctionne également sur elles. Pour en savoir plus, consultez [Errors](/errors). Comme les erreurs front-end vivent dans le namespace `browser` (voir les [namespaces](/guides/namespaces)), ces réglages sont distincts de ceux de votre back end. Si vous migrez depuis `@appsignal/javascript`, notez que ses erreurs étaient rapportées dans `frontend` : les réglages de notification que vous y avez configurés ne sont donc pas repris. Pour en savoir plus, consultez le [guide de migration](/browser/migration).

<h2 id="errors-you-will-not-find-here">
  Les erreurs que vous ne trouverez pas ici
</h2>

Certaines erreurs n'atteignent jamais le SDK, notamment celles levées avant son initialisation, celles venues de scripts cross-origin servis sans en-têtes CORS, et celles à l'intérieur d'iframes. Chacune a une solution de contournement, répertoriée dans [les erreurs qui ne sont pas rapportées](/browser/error-tracking#errors-that-are-not-reported). S'il manque une erreur que vous attendiez, parcourez le [dépannage](/browser/troubleshooting#an-error-is-missing).