Suivi des exceptions

Le suivi des exceptions est le cœur de Quiet Guard : chaque erreur levée par votre application est capturée, regroupée et suivie tout au long de son cycle de vie. Vous y accédez en ouvrant un projet dans le panel /app, onglet Anomalies.

Comment fonctionne l'ingestion

Votre client envoie (POST) un payload d'exception à /api/v1/ingest, authentifié par la clé de projet. Le serveur le valide, applique le quota mensuel de votre équipe, puis le transmet à l'ingesteur. Un appel réussi renvoie 202 Accepted avec l'identifiant public de l'issue. La forme complète du payload est documentée dans la référence de l'API d'ingestion.

Chaque exception acceptée devient une occurrence. Les occurrences sont regroupées en issues.

Regroupement par empreinte en issues

Plutôt que de stocker des milliers d'erreurs identiques en lignes distinctes, Quiet Guard les regroupe. Une empreinte (fingerprint) déterministe est calculée à partir de :

• le projet,
• la classe de l'exception,
• le fichier (chemin normalisé), et
• la ligne.

Toutes les occurrences partageant une empreinte sont regroupées dans une seule issue, avec un compteur d'occurrences qu'aucun envoi simultané ne fait perdre, la date de première apparition et celle de la dernière.

Pourquoi normaliser le chemin ? Les outils de déploiement servent souvent l'application depuis un répertoire horodaté (par ex. /releases/20260628/...). L'empreinte élimine ce bruit, en conservant le chemin à partir du premier marqueur /app/, /src/ ou /vendor/, pour que la même erreur se regroupe d'un déploiement à l'autre au lieu de se fragmenter à chaque release.

Occurrences

Ouvrez une issue pour voir sa page de détail : la classe et le message regroupés, l'endroit où elle se produit, le nombre de fois où elle a été vue, et la liste des occurrences individuelles. Chaque occurrence porte sa propre trace, son contexte de requête, son environnement et sa release, capturés au moment où elle s'est produite.

La page de détail ajoute six éléments en plus de la trace. Une nouvelle section, La requête, affiche l'adresse, la méthode HTTP, l'utilisateur connecté et l'environnement d'exécution PHP/Laravel capturés avec la dernière occurrence ; pour une équipe avec le stockage chiffré activé, elle affiche à la place un espace réservé verrouillé, jamais l'adresse ni l'utilisateur, tant que vous n'avez pas déverrouillé le chiffrement dans votre navigateur depuis la page Chiffrement. Deux compteurs, Dernières 24 h et 7 derniers jours, ainsi que les listes des Environnements et des Versions touchés au cours des 7 derniers jours, accompagnent le nombre total d'occurrences. Un graphique Quatorze jours d'occurrences répartit chaque occurrence par jour, pour faire coïncider un pic avec un déploiement. Une ligne Dans votre code nomme la première ligne de la trace qui n'appartient pas à une dépendance, pour ne pas avoir à faire défiler les lignes du framework avant de trouver où votre code a cassé. Quand le projet est connecté à GitHub et que votre offre le permet, une action Historique du fichier liste les cinq commits les plus récents ayant touché ce fichier, du plus récent au plus ancien. Enfin, si le projet suit les issues de son dépôt, deux actions Ouvrir une issue GitHub et Lier une issue GitHub rattachent l'anomalie à un rapport du dépôt, et la vue d'ensemble affiche ensuite l'issue liée avec son état.

La trace d'appel

À partir de la version 0.3 des clients, la section Dernière trace d'appel se lit comme la page d'erreur de Laravel :

• les trames sont listées d'un côté, le site de levée en premier (Levée ici) : la ligne qui a levé l'exception voyage désormais comme trame zéro, alors que la trace de PHP commence à l'appelant et ne l'a jamais contenue ;
• les suites de trames de dépendances sont repliées en une seule ligne nommée d'après le paquet (« 7 trames de laravel/framework »), qui se déplie d'un clic ;
• à côté de la liste, le détail de la trame sélectionnée : l'appel, le chemin complet et l'extrait de code autour de la ligne fautive, celle-ci marquée ;
• quand le projet est connecté à GitHub, un lien Ouvrir ce fichier sur GitHub pointe sur le fichier au commit déployé : celui que la release de l'occurrence résout, sinon la branche par défaut du dépôt.

L'extrait est lu par le client dans le fichier qui a tourné : les cinq lignes de part et d'autre de la ligne de la trame, au plus dix trames par rapport, et jamais pour une dépendance (tout chemin contenant /vendor/). Une ligne qui nomme une clé de la liste de masquage (password, secret, token, passphrase...) ou l'un des mots key, auth, credential, salt, private, dsn, bearer, sk_, pk_, et lui donne une valeur, est remplacée entière par [scrubbed], parce que le code source est l'endroit où vit un secret codé en dur : une affectation ($secret = ..., 'api_key' => ...), à partir de la version 0.3.1 un indice nommé entre guillemets ($headers['Authorization'] = ...), un appel dont le premier argument est un littéral (setApiKey('...')), ou une comparaison par == ou === dont le nom est à gauche ($token === '...'), dont l'autre membre peut être le secret lui-même ; !== et un littéral à gauche ('...' === $token) ne comptent pas. Une ligne qui ne fait qu'utiliser le nom reste (Hash::check($password, $hash), et à partir de la version 0.3.1 Auth::user()), et un littéral qui n'en nomme aucun voyage tel quel ; la règle complète est dans le masquage du cœur. Pour ne plus l'envoyer : MONITOR_CODE_SNIPPETS=false avec le SDK Laravel, code_snippets: false dans le bundle Symfony, ou la clé d'option code_snippets du plugin WordPress. Une trame sans extrait le dit, qu'elle vienne d'un client plus ancien ou d'une dépendance. Avec le stockage chiffré, les extraits sont scellés au repos avec le reste de la trace.

Résoudre, ignorer, rouvrir

Chaque issue a un statut :

• Ouverte: active, nécessite une attention (par défaut pour une nouvelle issue).
• Résolue: vous l'avez corrigée ; elle sort de la liste active.
• Ignorée: du bruit que vous ne voulez pas traiter ; conservée mais mise en sourdine.

Vous passez d'un état à l'autre via les actions de la liste des issues et de la page de détail. Des filtres permettent de se concentrer, par exemple, sur les seules issues ouvertes.

Réouverture sur régression

Si une issue est résolue et que la même erreur survient à nouveau, Quiet Guard la traite comme une régression : l'issue est automatiquement repassée en ouverte à l'occurrence suivante, et une alerte issue.reopened est déclenchée vers les canaux de notification abonnés. Inutile de surveiller les issues résolues : si elles reviennent, vous serez prévenu.

Corrélation release → commit

C'est là que les données GitHub paient. Lorsqu'une occurrence porte une release (un SHA de commit, envoyé dans context.release) et que le projet est connecté à GitHub, Quiet Guard associe cette release au commit synchronisé exact. Depuis l'issue, vous pouvez sauter directement au commit qui a livré le code défectueux, bouclant la boucle de l'erreur vue en production à la modification qui l'a causée.

À noter : la corrélation de release ne se résout que lorsque la valeur de release est un SHA de commit hexadécimal et que le commit correspondant a été synchronisé depuis GitHub.

Flux de triage

L'onglet Anomalies d'un projet s'ouvre en vue de triage : le filtre de statut est préréglé sur Ouverte, ce que rappelle la ligne des filtres actifs au-dessus des lignes ; les autres filtres sont derrière le bouton entonnoir et s'appliquent dès qu'ils sont choisis. La colonne 24 h compte les occurrences de chaque anomalie sur la dernière journée, repérez la rafale en cours, pas l'anomalie bruyante de la semaine passée. Sélectionnez plusieurs anomalies pour les résoudre ou les ignorer en une action.

Le triage sur tous les projets

Une agence répond d'un portefeuille, pas d'une seule application. L'entrée Anomalies de la barre latérale rassemble toutes les anomalies de tous les projets de l'équipe, avec une colonne Projet et un filtre Projet, et elle s'ouvre triée sur les dernières 24 heures plutôt que sur la récence : la question à laquelle elle répond est « qu'est-ce qui brûle maintenant », pas « qu'est-ce qui vient d'arriver ». Les filtres, l'assignation et la résolution ou l'ignorance groupées y fonctionnent exactement comme dans un projet, mais à travers les projets.

L'onglet d'un projet ne change pas et reste le bon endroit dès que vous savez quel projet vous voulez. L'entrée de la barre latérale porte une pastille avec le nombre d'anomalies ouvertes de l'équipe.

Assigner des anomalies

Assignez une anomalie à un membre de l'équipe depuis la liste ou depuis sa page. Le filtre Assignées à moi transforme la liste en pile de travail personnelle, idéal pour les agences qui répartissent les projets entre développeurs.

Journaux autour d'un événement

Si votre offre inclut les journaux applicatifs, la page d'une anomalie affiche les journaux enregistrés sur le même projet et environnement à ±5 minutes de la dernière occurrence, le « pourquoi » s'y cache souvent. Chaque ligne mène à l'entrée complète.

Recherche globale

Appuyez sur ⌘K / Ctrl+K n'importe où dans le panneau pour retrouver une anomalie par classe d'exception, message ou fichier, et un projet par nom. Avec le stockage chiffré, les messages scellés ne sont pas cherchables (par design) : la recherche s'appuie sur les métadonnées en clair.

Et ensuite

• Configurez les alertes pour que l'équipe soit prévenue des issues nouvelles et rouvertes.
• Ajoutez les logs applicatifs pour le contexte autour de chaque erreur.
• Activez le stockage chiffré si le contenu des exceptions doit rester privé au repos.