40 projets WordPress actifs, chacun avec ses propres extensions, ses propres thèmes et ses propres particularités de code : c’est le volume que nous suivons actuellement sur notre compte de monitoring d’erreurs. À cette échelle, la question n’est plus « quel outil détecte le mieux une exception PHP », les deux le font correctement, mais « quel outil reste utilisable quand quarante flux d’erreurs différents arrivent dans le même tableau de bord ».
Nous avons fait tourner Sentry et Bugsnag en parallèle sur un sous-ensemble de dix projets pendant six semaines, avec le même SDK PHP configuré à l’identique côté seuils de sévérité, pour comparer honnêtement le regroupement d’erreurs, la lisibilité des tableaux de bord et le coût réel à cette échelle.
Le regroupement d’erreurs : la vraie différence à l’usage
Sentry regroupe les événements par une empreinte calculée à partir de la stack trace, du message et du fichier d’origine. Sur du code WordPress, où les mêmes fonctions du cœur apparaissent dans des centaines de stack traces différentes selon l’extension appelante, ce regroupement produit parfois des doublons artificiels : une même erreur PHP levée depuis deux extensions différentes crée deux groupes distincts. Bugsnag applique un algorithme de regroupement plus agressif qui a tendance, à l’inverse, à fusionner des erreurs distinctes partageant une même ligne du cœur WordPress.
La lisibilité à quarante projets
Sentry organise les projets par organisation avec un système de teams et d’alertes par projet assez fin, ce qui permet d’assigner un développeur précis à un sous-ensemble de projets sans qu’il voie le bruit des trente-neuf autres. Bugsnag propose une organisation par projet également, mais son tableau de bord global agrège moins bien les tendances inter-projets : repérer qu’une même erreur PHP 8.1 touche douze sites après une montée de version commune demande plus de clics sur Bugsnag que sur Sentry, où une vue de recherche transverse permet de filtrer par message d’erreur sur l’ensemble des projets d’un coup.
La facturation par événement, un point de bascule
Les deux outils facturent au volume d’événements ingérés, et non par projet. Sur un parc hétérogène, un seul projet mal configuré (un plugin qui logge une notice PHP à chaque requête) peut consommer le quota mensuel de tout le compte en quelques heures. Nous avons vécu ce scénario sur les deux outils. La différence tient au comportement une fois le quota dépassé : Sentry propose un système de rate limiting par projet, configurable indépendamment, qui permet de plafonner un projet bruyant sans affecter les autres. Bugsnag, sur l’offre que nous utilisions, appliquait un plafond global au compte, ce qui a coupé la remontée d’erreurs sur l’ensemble du parc pendant plusieurs heures.
Coûts observés sur notre échantillon
| Critère | Sentry | Bugsnag |
|---|---|---|
| Coût mensuel pour 40 projets | 89 € | 124 € |
| Rate limiting par projet | Oui | Non (sur notre offre) |
| Intégration WordPress officielle | Plugin communautaire mature | SDK PHP générique |
| Recherche transverse multi-projets | Bonne | Limitée |
L’intégration WordPress, un détail qui pèse
Sentry bénéficie d’un plugin WordPress communautaire actif qui capture automatiquement le contexte : thème actif, liste des extensions, version de WordPress, requête SQL en cours au moment de l’erreur. Ce contexte enrichi évite d’avoir à reproduire l’erreur pour comprendre son origine, un gain de temps réel quand on gère quarante projets et qu’on ne peut pas se permettre d’ouvrir chaque environnement pour diagnostiquer. Bugsnag demande une configuration manuelle plus poussée pour obtenir un niveau de contexte comparable.
- Sentry capture automatiquement la liste des extensions actives dans le contexte de chaque erreur.
- Bugsnag nécessite un middleware personnalisé pour obtenir la même information.
- Les deux supportent le source map côté JavaScript, utile pour les projets avec un thème block-first.
À cette échelle, le critère qui compte le plus n’est pas la détection d’erreur elle-même, mais la capacité à isoler un projet bruyant sans perdre la visibilité sur les trente-neuf autres.
Notre verdict
Pour un parc de plus de trente projets WordPress, Sentry l’emporte sur notre usage grâce à son rate limiting par projet et son intégration WordPress plus mature, malgré un regroupement d’erreurs parfois trop fin qui multiplie les faux doublons. Bugsnag reste un choix défendable sur un parc plus restreint, où le risque qu’un projet consomme tout le quota du compte est moins probable.
