Lundi matin, 9h. Le support client croule sous les messages :
"Je n'arrive plus à me connecter", "la page de paiement affiche une erreur".
L'équipe technique se mobilise. Mais où est le problème ?
Le serveur web ? La base de données ? Un partenaire externe ?
Sans monitoring et sans logs, trouver la cause d'un problème en
production
revient à chercher une aiguille dans une botte de foin. Avec, c'est comme avoir
des caméras de surveillance et un journal de bord qui enregistrent tout.
Les logs : le journal de bord
Un log (journal), c'est une ligne de texte que l'application écrit à chaque événement
important : une connexion réussie, un paiement validé, une erreur rencontrée...
Chaque log contient au minimum la date, le niveau de gravité et un message :
[2026-02-18 09:03:12] INFO - Utilisateur n°42 connecté
[2026-02-18 09:03:15] ERROR - Échec paiement commande n°789 : timeout partenaire Stripe
[2026-02-18 09:03:15] WARN - Temps de réponse base de données : 4200ms (seuil : 1000ms)Les niveaux de gravité classiques sont :
- DEBUG : détails techniques pour les développeurs. Très verbeux.
- INFO : événements normaux du système. "Un utilisateur s'est connecté."
- WARN : quelque chose d'anormal mais pas critique. "La base de données est lente."
- ERROR : un problème empêche une fonctionnalité de marcher. "Le paiement a échoué."
- CRITICAL : le système est en danger. "Le serveur n'a plus de mémoire."
En production, les logs sont centralisés dans des outils comme Elasticsearch ou Datadog qui permettent de les rechercher, filtrer et analyser. Quand un bug est signalé, le développeur consulte les logs de la période concernée pour reconstituer ce qu'il s'est passé. C'est là qu'il retrouve les messages d'erreur et les stack traces dont nous avons parlé.
Le monitoring : la surveillance en temps réel
Les logs racontent le passé. Le monitoring surveille le présent.
Le monitoring collecte en permanence des métriques sur la santé du système :
utilisation du processeur, mémoire disponible, nombre de requêtes par seconde,
temps de réponse moyen, taux d'erreur...
Ces métriques sont affichées sur des dashboards (tableaux de bord)
avec des graphiques en temps réel, dans des outils comme Grafana.
D'un coup d'oeil, l'équipe peut voir si le système se comporte normalement
ou si quelque chose déraille.
Les alertes
Personne ne passe sa journée à regarder des dashboards.
Le monitoring est configuré pour envoyer des alertes quand une métrique
dépasse un seuil critique.
Exemples :
- Le taux d'erreur dépasse 5% → alerte Slack.
- Le temps de réponse moyen dépasse 3 secondes → alerte email.
- Un serveur ne répond plus → appel téléphonique au développeur d'astreinte.
Les équipes organisent des astreintes : à tour de rôle, un développeur
est joignable en dehors des heures de bureau pour réagir aux alertes critiques.
C'est le côté moins glamour du métier.
Le piège classique, c'est d'en mettre trop. Si le système crie au loup en permanence
pour des raisons non critiques, l'équipe finit par ignorer les notifications.
Et le jour où une vraie alerte arrive, personne ne réagit.
L'uptime et les engagements
Toutes ces mesures finissent par se résumer à un chiffre que le commerce comprend, le taux de disponibilité.
Un service disponible 99,9% du temps a le droit de tomber environ 43 minutes par mois. À 99,99%, la marge
tombe à 4 minutes. Chaque neuf supplémentaire coûte beaucoup plus cher que le précédent, parce qu'il oblige à
dupliquer des serveurs, des bases et des équipes d'astreinte.
C'est ce qu'on retrouve dans les contrats sous le nom de SLA (Service Level Agreement), l'engagement pris
auprès du client, souvent assorti de pénalités. Quand une équipe technique discute du nombre de neuf, elle
parle en réalité d'un arbitrage entre budget et promesse commerciale.
Le post-mortem
Quand un incident majeur survient (le site tombe, des données sont corrompues,
un paiement est débité deux fois), les équipes matures rédigent un post-mortem :
un document qui analyse ce qu'il s'est passé, pourquoi, et comment éviter
que ça se reproduise.
Un bon post-mortem ne cherche pas un coupable. Il identifie les failles du système
(monitoring insuffisant, absence de test, procédure manquante) et propose des actions concrètes.
C'est un exercice d'amélioration continue, pas un tribunal.