Guides · Exploitation

Quand votre application casse la nuit, qui le sait ?

Un paiement qui échoue, un e-mail qui ne part plus, une page blanche pour un client sur dix : dans la plupart des applications, personne ne le sait avant qu'un client écrive, quand il écrit. Voici comment être prévenu le premier, avec des outils simples, souvent gratuits pour une petite application.

30 minutesToute application en production, en particulier sans équipe technique dédiéePublié le 4 octobre 2026

Le silence n'est pas une bonne nouvelle

Dans beaucoup d'applications, quand une erreur se produit, elle s'affiche dans le navigateur du client (dans une console qu'il n'ouvrira jamais) et nulle part ailleurs. Résultat : vous apprenez les pannes par vos clients, au mieux. Au pire, ils partent sans rien dire. C'est le constat I de notre diagnostic de Studio Kerelune : plus de cent endroits du code qui signalent une erreur, tous dans le navigateur du client, et personne pour les lire.

Être prévenu demande quatre choses, toutes accessibles gratuitement pour une petite application.

1. Savoir si l'application répond

Un service de surveillance de disponibilité (par exemple Better Stack, qui a une offre gratuite, ou UptimeRobot dans son offre payante : sa formule gratuite est réservée à un usage non commercial) ouvre votre application toutes les quelques minutes et vous prévient par e-mail ou par notification sur votre téléphone si elle ne répond plus.

Surveillez au moins la page d'accueil et, si possible, une adresse qui touche la base de données : une page d'accueil peut s'afficher alors que tout le reste est en panne.

2. Savoir quand une erreur se produit chez un client

Un outil de remontée d'erreurs (Sentry est le plus connu, avec une offre gratuite) s'installe en quelques lignes dans votre application. Chaque erreur qui se produit chez un client vous est remontée, avec la page, le navigateur et le détail technique, et vous recevez une alerte quand une nouvelle erreur apparaît ou qu'une erreur se répète.

Pour savoir si c'est déjà en place, cherchez dans votre code le nom de ces outils, ou une variable comme SENTRY_DSN. Une variable lue mais jamais utilisée, c'est un outil prévu puis oublié.

3. Écouter ce que vos prestataires vous disent déjà

Vos services vous envoient déjà des alertes, encore faut-il qu'elles arrivent à la bonne personne :

  • Stripe prévient quand votre webhook échoue à répétition, et quand des paiements sont contestés ;
  • votre base de données (Supabase, par exemple) envoie des alertes d'usage et d'incident ;
  • votre service d'e-mails signale les rebonds et les plaintes ;
  • votre registraire prévient avant l'expiration du nom de domaine (vérifiez que le renouvellement automatique est actif et que la carte de paiement est valide) ; pour le certificat, renouvelé automatiquement en général, la plupart des services de surveillance savent alerter avant son expiration.

Vérifiez, pour chacun, à quelle adresse partent ces alertes. Une adresse personnelle d'un ancien prestataire, ou une boîte que personne ne lit, et vous ne saurez rien.

4. Les tâches qui tournent sans personne

Relances automatiques, fins d'essai gratuit, purges, sauvegardes : ces tâches planifiées tournent la nuit. Quand l'une d'elles échoue, rien ne se voit pendant des jours. Pour chacune, demandez-vous : si elle ne tourne plus, qui le remarque, et quand ? Un service de surveillance des tâches planifiées (on parle de « battement de cœur », heartbeat : une adresse que la tâche appelle à chaque exécution réussie) vous prévient si l'appel n'arrive pas.

Le test qui compte : déclencher une fausse alerte

Une alerte qu'on n'a jamais vue arriver n'existe pas. Une fois les outils en place, provoquez volontairement une erreur dans un environnement d'essai, ou ajoutez un moniteur sur une adresse qui n'existe pas (une page qui renvoie une erreur 404), et vérifiez que l'alerte arrive bien, à la bonne personne, sur un téléphone, et en combien de temps.

Décidez aussi, à l'avance, qui réagit : à 3 h du matin, un e-mail dans une boîte partagée ne réveille personne.

Ce que cette vérification ne couvre pas

Ce que les journaux contiennent (ils ne doivent pas contenir de mots de passe ni de données personnelles en clair), la capacité à revenir en arrière après une mise à jour ratée, et la restauration d'une sauvegarde. C'est ce que couvre l'axe « exploitation » de notre diagnostic, et ce que nous installons dans le cadre de la garde, notre maintenance au mois : les alertes arrivent chez nous, et quelqu'un répond.

Dans notre grille : Surveillance et alertes, et qui les reçoit ; journaux et ce qu'on y voit ; tâches planifiées ; ce qui se passe à 3 h du matin.
Voir les soixante questions
Vingt minutes

Vous préférez qu'on regarde avec vous ?

Le diagnostic couvre ce guide et toute la grille, soixante questions sur sept axes, pour 2 900 € HT : premiers constats sous 48 heures, rapport sous cinq jours ouvrés.