Six alertes Sentry en dix minutes, toutes avec la même trace d’appel PHP, la même ligne de code fautive, le même message d’erreur au caractère près. Une seule différence entre elles : l’URL de la page où l’erreur s’est produite, chacune préfixée par un code de langue différent — /fr/, /en/, /de/, /es/, /it/, /nl/.
C’est le symptôme classique de Sentry configuré par défaut sur un site multilingue à six langues : il regroupe ses alertes selon un « fingerprint » qui inclut par défaut l’URL complète de la requête, préfixe de langue compris. Le résultat, une seule vraie panne côté code, produit un mur d’alertes qui donne l’illusion d’un incident généralisé à toute l’infrastructure.
Pourquoi le fingerprint par défaut de Sentry inclut l’URL
Sentry regroupe automatiquement les événements d’erreur similaires dans un même « issue » en se basant sur plusieurs signaux : le type d’exception, la trace de la pile d’appel, et par défaut sur certains transports, des éléments contextuels de la requête HTTP dont l’URL. Sur un site à une seule langue, ce comportement est presque toujours souhaitable : deux erreurs sur deux URL différentes sont souvent deux problèmes distincts.
Sur un site multilingue où chaque page existe en plusieurs versions linguistiques structurellement identiques, cette logique se retourne contre l’équipe technique : l’URL diffère uniquement par son préfixe de langue, alors que le code exécuté et l’erreur produite sont rigoureusement identiques.
Corriger avec un fingerprint personnalisé qui neutralise le préfixe de langue
Le SDK PHP de Sentry permet de définir un fingerprint personnalisé avant l’envoi de l’événement, en y injectant une valeur normalisée qui retire le préfixe de langue de l’URL avant comparaison :
<?php
add_action( 'init', function() {
\Sentry\configureScope( function ( \Sentry\State\Scope $scope ): void {
$uri = $_SERVER['REQUEST_URI'] ?? '';
// Retire le préfixe de langue type /fr/, /en/, /de/...
$uri_normalisee = preg_replace(
'#^/(fr|en|de|es|it|nl)/#',
'/',
$uri
);
$scope->setFingerprint( [ '{{ default }}', $uri_normalisee ] );
} );
} );Le jeton {{ default }} conserve le comportement de regroupement habituel de Sentry (type d’exception, trace de pile), tout en y ajoutant l’URL normalisée plutôt que l’URL brute. Après ce réglage, les six alertes redeviennent une seule et même issue, avec un compteur d’occurrences qui reflète la réalité : une panne survenue six fois, pas six pannes distinctes.
Garder une trace de la langue, sans casser le regroupement
Regrouper les alertes ne signifie pas perdre l’information de langue : elle reste précieuse pour comprendre si une erreur touche toutes les langues ou seulement certaines (un problème d’encodage spécifique à l’arabe ou au russe, par exemple). Sentry permet d’ajouter cette donnée comme tag contextuel, séparé du fingerprint utilisé pour le regroupement :
$scope->setTag('langue', pll_current_language());conserve la langue comme filtre disponible dans l’interface Sentry- Le fingerprint, lui, ignore ce tag pour le regroupement
- Résultat : une seule issue, mais un histogramme consultable des langues où elle s’est produite
Le cas particulier des erreurs 404 multilingues
Les erreurs 404 posent un problème inverse : elles doivent souvent rester séparées par URL, y compris entre langues, car une page manquante en allemand n’est pas la même information qu’une page manquante en italien. Le fingerprint personnalisé ne doit donc s’appliquer qu’aux erreurs applicatives (exceptions PHP, erreurs fatales), jamais aux erreurs 404 volontairement laissées avec leur granularité par URL complète.
En résumé
Sur un site multilingue, le comportement de regroupement par défaut de Sentry transforme une seule panne en autant d’alertes que de langues actives, ce qui noie le signal réel dans du bruit. Un fingerprint personnalisé qui normalise l’URL avant comparaison restaure un tableau d’alertes exploitable, tout en gardant la langue disponible comme filtre plutôt que comme critère de séparation.
