Si votre application tombe un samedi soir, qui le sait en premier ? Dans beaucoup de PME, la réponse honnête est : un client, par mail, le lundi matin. Le monitoring d'une application web en PME sert exactement à inverser cet ordre : être prévenu avant vos clients, avec assez d'informations pour agir vite.
La bonne nouvelle, c'est que le minimum utile tient en trois surveillances simples. L'application répond-elle ? Produit-elle des erreurs ? Ses ressources (disque, certificat, sauvegardes) tiennent-elles le coup ? Le reste est surtout une question d'organisation : qui reçoit l'alerte, et que fait-il ensuite.
Cet article vous donne ce minimum, sans jargon, pour que vous puissiez vérifier ce qui existe déjà chez vous et ce qui manque.
Pourquoi vos clients découvrent les pannes avant vous
Une application ne tombe presque jamais en panne de façon spectaculaire. Le plus souvent, c'est discret : un formulaire qui ne s'envoie plus, un paiement qui échoue pour une partie des utilisateurs, un mail de confirmation qui ne part plus. Rien ne clignote. Personne en interne ne s'en rend compte, parce que personne en interne n'utilise l'application comme vos clients.
Il y a aussi les pannes « à retardement » :
- le disque du serveur qui se remplit lentement de journaux, jusqu'au jour où plus rien ne peut s'écrire ;
- le certificat HTTPS qui expire, et le navigateur qui affiche un avertissement de sécurité à vos visiteurs ;
- la sauvegarde qui échoue en silence depuis des semaines.
Dans tous ces cas, l'information existait. Elle n'était simplement envoyée à personne. Le monitoring, ce n'est pas un outil sophistiqué : c'est décider quelles informations doivent remonter, et à qui.
Monitoring d'une application web en PME : les trois choses à surveiller
Dans le chapitre consacré à la surveillance de leur livre Site Reliability Engineering, les ingénieurs de Google distinguent les symptômes (ce qui est cassé, vu de l'utilisateur) et les causes (pourquoi c'est cassé) : « Monitoring Distributed Systems ». Pour une PME, ce découpage suffit à construire un socle solide.
1. L'application répond-elle ? (le symptôme vu de l'extérieur)
Un service externe interroge votre application à intervalle régulier, depuis Internet, comme le ferait un client. Si la page ne répond pas, ou renvoie une erreur, vous recevez une alerte. C'est ce qu'on appelle une surveillance de disponibilité (uptime).
Point d'attention : vérifier que la page d'accueil s'affiche ne suffit pas toujours. Une page d'accueil peut s'afficher alors que la base de données est inaccessible. Depuis Laravel 11, les nouvelles applications Laravel incluent par exemple une adresse de contrôle de santé, /up par défaut (Laravel News). Elle confirme que l'application démarre, mais ne vérifie pas d'elle-même la base de données ni les services tiers. C'est à votre développeur de la compléter pour qu'elle contrôle ce qui compte vraiment chez vous.
2. L'application produit-elle des erreurs ? (le symptôme vu de l'intérieur)
Un site peut répondre tout en plantant sur une action précise. Un outil de suivi d'erreurs capte chaque erreur au moment où elle se produit, la regroupe avec les erreurs identiques et indique à quel endroit du code et sur quelle page elle est survenue. Sentry est l'outil le plus connu. GlitchTip en est une alternative open source : il est compatible avec les bibliothèques de Sentry et surveille aussi la disponibilité (glitchtip.com).
Ce qui compte pour vous, dirigeant, ce n'est pas l'outil choisi. C'est la réponse à cette question : « Si une erreur se produit des dizaines de fois cette nuit, est-ce que quelqu'un le saura demain matin ? »
3. Les ressources tiennent-elles ? (les causes prévisibles)
Certaines pannes s'annoncent. Il suffit de surveiller :
- l'espace disque du serveur et de la base de données ;
- la date d'expiration du certificat HTTPS et du nom de domaine ;
- le résultat de la dernière sauvegarde : a-t-elle réussi, et quand ?
- les tâches planifiées (envoi de mails, factures, imports) : se sont-elles exécutées ?
Pour les sauvegardes, la règle est simple : si personne ne la surveille, vous ne savez rien de votre sauvegarde. Nous avons détaillé le sujet dans Sauvegarde d'une application web en PME : le minimum à mettre en place.
Qui reçoit l'alerte, et que fait-il ensuite
C'est l'étape la plus souvent oubliée. Un outil qui envoie des alertes dans une boîte mail que personne ne lit ne sert à rien. Un outil qui envoie des dizaines d'alertes par jour non plus : au bout d'une semaine, plus personne ne les regarde. Le livre de Google le dit à sa manière : une alerte doit signaler un problème réel et compréhensible, qui demande l'intervention de quelqu'un.
Concrètement, posez par écrit trois choses :
- Qui reçoit quoi. Une panne complète du site mérite un SMS ou une notification immédiate. Une erreur isolée peut attendre un récapitulatif quotidien.
- Qui agit, et dans quel délai. Si c'est un prestataire, vérifiez que son contrat prévoit une intervention, et à quels horaires. Si c'est vous, sachez au moins qui appeler.
- Ce qu'on fait en premier. Une courte fiche suffit : où sont les accès, comment redémarrer, comment revenir à la version précédente, comment prévenir les clients.
Ce dernier point paraît évident tant que tout va bien. Il l'est beaucoup moins à 22 h, quand le développeur qui connaissait l'application n'est plus joignable.
Le cas particulier des applications codées avec l'IA
Si votre application a été construite avec Lovable, Bolt, Cursor ou Claude Code, la surveillance compte encore davantage, pour trois raisons.
D'abord, ces outils produisent du code qui fonctionne sur le scénario prévu, mais ils couvrent moins bien les cas limites : une donnée manquante, un utilisateur qui fait les choses dans un ordre inattendu, un service tiers qui répond lentement. Un suivi d'erreurs fait remonter précisément ce genre de problème, que vous ne verriez pas autrement.
Ensuite, ces outils ne s'occupent généralement pas de l'exploitation : supervision, mises à jour de sécurité, sauvegardes. Ils livrent une application, pas un service qui tourne. Le rapport 2026 de Veracode sur le code généré par IA relève d'ailleurs que les modèles produisent désormais du code qui compile presque toujours, mais que sa sécurité progresse peu d'une année sur l'autre (Veracode, 2026 GenAI Code Security Report). Autrement dit, « ça marche » ne veut dire ni « c'est surveillé », ni « c'est sûr ».
Enfin, quand chaque correction demandée à l'IA risque d'en casser une autre, le suivi d'erreurs vous sert de filet : il vous montre ce qui a cassé juste après une mise en ligne. Nous en parlons dans Application vibe coding : quand chaque correction casse autre chose.
Ce que vous pouvez mettre en place cette semaine
Vous n'avez pas besoin d'un chantier de plusieurs mois. Voici une liste à dérouler avec votre développeur ou votre prestataire, dans cet ordre :
- Demandez l'état actuel. « Qu'est-ce qui est surveillé aujourd'hui, et qui reçoit les alertes ? » Si la réponse est floue, c'est déjà une information.
- Mettez en place une surveillance de disponibilité sur la page d'accueil et sur une adresse de contrôle qui vérifie aussi la base de données.
- Branchez un suivi d'erreurs sur l'application, et décidez qui lit le récapitulatif.
- Ajoutez les alertes sur les ressources : disque, certificat, nom de domaine, dernière sauvegarde réussie.
- Rédigez la fiche « que faire si… » : une page, rangée là où vous la retrouverez.
- Testez. Arrêtez volontairement l'application sur un créneau calme et vérifiez que l'alerte arrive bien à la bonne personne.
C'est le dernier test qui apprend le plus : on découvre souvent qu'une alerte part vers une adresse qui n'existe plus, ou vers un ancien prestataire.
Questions fréquentes
Mon hébergeur ne surveille-t-il pas déjà mon application ?
En général, l'hébergeur surveille son infrastructure : il vérifie que le serveur est allumé et joignable. Il ne sait pas si votre formulaire de commande fonctionne ni si votre application renvoie des erreurs. Vérifiez ce que prévoit votre contrat, mais ne supposez pas que c'est couvert.
Faut-il une astreinte 24 h/24 ?
Pas forcément. Tout dépend de ce que vous coûte une panne. Pour beaucoup de PME, être prévenu immédiatement et intervenir dans la matinée suffit. L'essentiel est que ce délai soit décidé à l'avance, et non subi.
Puis-je installer ça moi-même ?
La surveillance de disponibilité, oui : plusieurs services en ligne s'activent en quelques minutes. Le suivi d'erreurs et l'adresse de contrôle demandent une intervention dans le code, donc un développeur.
C'est précisément ce que couvre l'offre Autopilote : hébergement, sauvegardes, monitoring, déploiement et contrôle qualité, pour que votre application soit surveillée sans que vous ayez à y penser. Si vous voulez simplement savoir ce qui est surveillé chez vous aujourd'hui et ce qui ne l'est pas, parlons-en : un échange de trente minutes suffit souvent à faire le point.