Douze mille erreurs fatales remontées en un mois sur un parc de sites clients : c’est le volume qui a poussé une agence à abandonner son fichier de log maison au profit d’un service de suivi d’erreurs dédié. Le choix s’est vite réduit à deux candidats sérieux pour du PHP : Sentry et Bugsnag. Les deux savent capturer une exception PHP, l’associer à une version de code et alerter une équipe. Les différences se jouent ailleurs.
Cet article compare l’intégration technique dans une extension WordPress, la qualité du regroupement des erreurs et le modèle de coût des deux services, sur la base d’un même code instrumenté avec chacun. Il ne traite pas la solution de journalisation fichier interne, déjà couverte dans un article distinct : ici, l’hypothèse de départ est qu’on envoie les erreurs vers un service tiers.
Installer le SDK sans polluer l’extension
Les deux services distribuent un SDK PHP installable via Composer : sentry/sdk pour Sentry, bugsnag/bugsnag pour Bugsnag. Dans une extension WordPress destinée à être distribuée, charger ces dépendances brutalement expose au conflit si un autre plugin embarque une version différente du même SDK. La pratique recommandée reste de préfixer les espaces de noms avec un outil comme Strauss avant de livrer, pour les deux SDK de façon identique — ce point ne départage donc pas les deux services.
La différence apparaît à l’initialisation. Sentry attend une configuration par DSN unique :
\Sentry\init([
'dsn' => 'https://exemplecle@o000000.ingest.sentry.io/000000',
'environment' => wp_get_environment_type(),
'release' => 'mon-extension@2.4.0',
]);
Bugsnag demande une clé de notifieur et une liste de types d’environnement à exclure explicitement, ce qui oblige à écrire quelques lignes de plus pour ne pas remonter les erreurs d’un environnement de développement local :
$bugsnag = Bugsnag\Client::make('cle-notifieur-ici');
$bugsnag->setReleaseStage(wp_get_environment_type());
$bugsnag->setNotifyReleaseStages(['production', 'staging']);
Bugsnag\Handler::register($bugsnag);
Regroupement des erreurs : le vrai critère
Sur un parc de sites exécutant la même extension, la même faute de frappe dans un appel à une fonction dépréciée peut générer des centaines d’occurrences par jour. Ce qui distingue vraiment les deux outils, c’est leur capacité à regrouper ces occurrences en un seul incident exploitable plutôt qu’en une liste ingérable.
| Critère | Sentry | Bugsnag |
|---|---|---|
| Regroupement par empreinte de pile | Très fin, tolère les variations de ligne mineures | Correct, plus sensible aux petites variations de trace |
| Suivi de version (release) | Intégré nativement, corrélation avec les commits Git possible | Disponible, moins poussé sur la corrélation code |
| Alerting | Règles fines par seuil et par taux de nouveauté | Règles simples par seuil de volume |
| Modèle tarifaire | Par utilisateur actif et volume d’événements | Principalement par volume d’événements |
| Support WordPress spécifique | Communauté active, plugin officiel léger | Aucun plugin officiel dédié WordPress |
Le coût à l’échelle d’un parc de sites
C’est souvent là que la décision bascule. Bugsnag facture principalement au volume d’événements envoyés, ce qui convient bien à un parc de sites nombreux mais peu bavards en erreurs. Sentry facture aussi au volume, mais ajoute une dimension par nombre d’utilisateurs de l’équipe qui accède au tableau de bord — un critère qui pèse peu pour une petite agence, davantage pour un éditeur qui ouvre l’accès à plusieurs clients finaux.
Dans les deux cas, il est indispensable de filtrer les erreurs avant envoi pour ne pas payer pour du bruit : exclure les erreurs de bots connus, dédupliquer les erreurs liées à des thèmes tiers hors du périmètre de l’extension, et échantillonner si le volume dépasse le forfait souscrit.
Ce qu’aucun des deux ne fait à la place de l’extension
Ni Sentry ni Bugsnag ne remplacent une stratégie de gestion des exceptions dans le code lui-même. Un bloc try/catch qui avale silencieusement une erreur sans la relancer ni l’enrichir de contexte produira le même résultat pauvre dans les deux outils : un message générique sans indication de ce que faisait l’utilisateur au moment du plantage. Enrichir le contexte avant l’envoi, avec l’identifiant de la commande ou du formulaire en cours de traitement, reste un travail à faire manuellement dans le code, quel que soit le service choisi.
Le service de suivi d’erreurs ne rend pas un code mal instrumenté meilleur : il rend visible à quel point il l’est, ou ne l’est pas.
Notre verdict
Pour une extension déployée sur un grand nombre de sites peu verbeux en erreurs, Bugsnag reste économiquement plus prévisible. Pour une équipe qui veut corréler les incidents avec les versions de code et affiner l’alerting par taux de nouveauté plutôt que par volume brut, Sentry justifie son coût par utilisateur. Aucun des deux ne dispense d’écrire du code qui documente ses propres échecs.
