La plupart des sites de petites entreprises ne découvrent qu’un bris est survenu que lorsqu’un client le signale. Un bouton de paiement lance une erreur JavaScript dans un navigateur, un formulaire de contact arrête discrètement d’envoyer les soumissions après une mise à jour de plugin, l’image d’un produit se met à renvoyer une erreur 404 après un changement de CDN — et rien de tout ça n’apparaît là où vous regardez déjà. Google Analytics compte les visites, pas les requêtes échouées — pas par défaut, en tout cas. Le moniteur de disponibilité de votre hébergeur vérifie si le serveur répond, pas si la page qu’il renvoie fonctionne réellement.
Le suivi des erreurs comble cet écart, et ça n’a pas besoin de devenir un projet de tableau de bord ou une embauche. Pour la plupart des sites, ce sont deux outils — un qui surveille le code, un qui surveille ce que Google voit — installés en un après-midi, puis laissés tranquilles jusqu’à ce que quelque chose cloche vraiment.
Ce qui vaut la peine d’être suivi, et ce qui n’est que du bruit
Toutes les alertes ne méritent pas la même attention, et c’est en les traitant toutes pareil que les équipes finissent par abandonner le suivi des erreurs à peine un mois après l’avoir activé.
Ce qui vaut la peine d’être capté :
- Les erreurs serveur (réponses 5xx) — le site échoue activement à répondre.
- Les erreurs JavaScript sur le paiement, l’inscription ou tout formulaire qui recueille des paiements ou des coordonnées.
- Les soumissions de formulaire échouées — le formulaire s’est chargé correctement, mais les données ne sont arrivées nulle part.
- Les 404 sur des pages qui génèrent du trafic ou reçoivent des dépenses publicitaires — une page de destination brisée brûle du budget à chaque heure où elle reste brisée.
Ce qu’on peut ignorer sans risque :
- Les avertissements CSS sur des propriétés désuètes.
- Les erreurs générées par les extensions de navigateur du visiteur, et non par votre code.
- Les 404 générés par des robots qui cherchent des pages de connexion ou des chemins d’administration qui n’existent pas sur votre site.
Si une alerte ne correspond pas à une page qu’un vrai client utilise, elle n’a pas besoin de déranger qui que ce soit dans sa journée.
Deux outils suffisent pour la plupart des petits sites
Pas besoin d’une plateforme d’entreprise pour commencer.
Sentry surveille votre code — les erreurs JavaScript côté client et les erreurs côté serveur — et signale ce qui a cassé, sur quelle page, pour combien d’utilisateurs. Son plan gratuit couvre 5 000 erreurs par mois, un utilisateur et un historique de 30 jours, ce qui suffit pour la plupart des sites qui n’ont pas encore atteint une vraie échelle.
Google Search Console surveille ce que Google lui-même rencontre : les erreurs serveur quand Googlebot essaie d’explorer une page, et les 404 souples — des pages qui semblent vides ou brisées mais qui renvoient quand même un « 200 OK » au lieu d’une vraie 404. Le rapport d’indexation des pages liste les deux, et si vous avez déjà fait du référencement, le compte traîne probablement là, inutilisé.
Avec les deux, vous couvrez ce qui casse pour un visiteur et ce qui casse pour le moteur de recherche qui décide s’il continue ou non à vous envoyer des visiteurs.
L’installation elle-même est la partie rapide, et ça vaut la peine de le dire clairement, parce que les guides la sautent souvent : Sentry vous donne une clé de projet — un DSN — qu’on insère une fois dans le site, soit par le plugin de la plateforme, soit par quelques lignes dans le gabarit de page, et Search Console demande une vérification de propriété unique, par DNS ou par un fichier sur le serveur. Aucun des deux ne prend un après-midi. Ce qui suit — décider ce qui mérite une alerte — c’est la partie qui demande vraiment du jugement. Et gardez le moniteur de disponibilité que votre hébergeur vous donne déjà : il répond à une autre question, celle de savoir si le serveur fonctionne du tout, et ça ne coûte rien de le laisser tourner.
Des alertes qu’on n’ignore pas
L’échec habituel, ce n’est pas de sauter le suivi des erreurs — c’est de l’activer, de se faire inonder de notifications dès la première semaine, et de couper le canal dès la deuxième.
Fixez des seuils plutôt que des alertes à chaque événement. Sentry offre des alertes métriques qui se déclenchent seulement quand le nombre d’erreurs dépasse un seuil que vous fixez, plutôt qu’à chaque occurrence — voir sa documentation sur les alertes. Configuré ainsi, l’outil reste silencieux jusqu’à ce qu’une vraie tendance se dessine.
Envoyez ces alertes là où votre équipe regarde déjà — un canal Slack ou Teams, pas une boîte de réception partagée que personne n’ouvre la fin de semaine. Et associez un nom à chaque parcours critique : paiement, inscription, formulaire de contact principal. Une alerte sans responsable désigné se fait lire — et ignorer — également par tout le monde.
Testez le montage avant de lui faire confiance
Ne présumez pas que ça fonctionne — prouvez-le, la même semaine où vous l’activez :
- Chargez une page qui n’existe pas et confirmez que la 404 apparaît là où elle devrait.
- Soumettez un formulaire avec un champ obligatoire laissé vide et confirmez que l’échec est bien consigné, pas seulement rejeté discrètement par le navigateur.
- Si vous pouvez déclencher une erreur serveur en toute sécurité dans un environnement de test, faites-le et vérifiez que l’alerte arrive.
Si rien n’apparaît après ça, vous n’avez pas de suivi des erreurs — vous avez un outil installé, mais qui n’est connecté à rien.
Quand une alerte devrait devenir un flux de travail
Une fois que les alertes arrivent quelque part de réel, le prochain point de rupture, c’est ce qui se passe après que quelqu’un en lise une. Si une soumission de formulaire échouée signifie encore qu’une personne vérifie le journal manuellement, retrouve le courriel du client dans une source de sauvegarde et fait un suivi à la main, vous avez automatisé le fait de le remarquer — pas de le régler.
C’est le même test « quand A se produit, faites B » qu’on utilise pour tout processus qui mérite d’être automatisé : une soumission échouée peut ouvrir un ticket toute seule, une 5xx répétée sur le même point de terminaison peut publier dans Slack avec les dernières occurrences en pièce jointe, une 404 souple sur une page de destination payante peut signaler le groupe d’annonces avant que plus de budget ne brûle sur une page morte. Rien de tout ça n’exige de reconstruire votre suivi des erreurs — ça exige de brancher l’alerte à l’étape suivante, au lieu de la laisser à quelqu’un qui la remarquera un jour, à son propre rythme.
Que ça vaille la peine de le construire dépend de la fréquence réelle de l’erreur — la même question qui revient chaque fois que quelqu’un évalue le coût de l’automatisation d’un flux de travail pour n’importe quelle tâche répétitive, pas seulement la gestion des erreurs. Une erreur qui survient deux fois par année peut très bien rester entre les mains d’une personne qui consulte un tableau de bord. Une qui survient chaque semaine coûte discrètement du temps réel à quelqu’un.
Pour donner un ordre de grandeur : on chiffre un seul flux de travail connecté à 800 $ fixes, ou 1 500 $ pour un ensemble d’au plus trois, un prix unique plutôt qu’un abonnement mensuel de plateforme. Si vous ne savez pas dans quelle catégorie tombent vos erreurs, ou si vous voulez qu’on construise toute la chaîne alerte-à-correction plutôt que juste l’alerte, c’est le genre de travail d’automatisation qu’on construit pour les sites de petites entreprises — contactez-nous et on regardera ce qui revient vraiment chez vous.
