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 - Commande 789 : Stripe ne répond pas
[2026-02-18 09:03:15] WARN - Base lente : 4200 ms (seuil 1000 ms)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é.
Dans une architecture découpée en plusieurs services, une seule commande client traverse cinq ou six briques, chacune écrivant ses propres journaux. Pour reconstituer son parcours, on glisse dès le premier appel un identifiant unique que chaque brique recopie dans ses logs. C'est ce qu'on appelle l'identifiant de corrélation, et sans lui les microservices sont impossibles à déboguer.
Un journal est un fichier comme un autre, et il contient très vite des données personnelles, une adresse email, une adresse postale, parfois bien pire quand un développeur a journalisé une requête entière avec le mot de passe dedans. Ce qu'on n'écrit jamais dans un log, et combien de temps on le conserve, relève du RGPD autant que de la technique. Conserver et indexer ces journaux coûte d'ailleurs cher, parfois plus que les serveurs eux-mêmes, ce qui explique les arbitrages sur la durée de rétention et le niveau de détail.
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.
La surveillance métier
Le meilleur détecteur de panne n'est pas la mémoire du serveur. C'est le nombre de commandes par heure qui
s'effondre un mardi à 15h alors que tous les voyants techniques sont au vert, parce que le bouton de paiement
ne s'affiche plus sur Safari, ou que le prestataire de paiement répond des erreurs polies.
Les équipes matures surveillent donc aussi des indicateurs métier, commandes, inscriptions, paniers validés,
et comparent chaque heure à la même heure de la semaine précédente. C'est le point où tu as un rôle à jouer,
puisque tu es le mieux placé pour dire quels chiffres doivent déclencher l'alerte, et à partir de quel
écart.
On complète souvent le dispositif par un robot qui rejoue toutes les cinq minutes un vrai parcours, depuis l'extérieur, ajouter un produit, aller jusqu'au paiement. Il voit ce que les métriques internes ne voient pas, le certificat expiré, le DNS qui ne répond plus, le prestataire externe en panne. C'est le pendant côté disponibilité des mesures de terrain du chapitre sur la performance web.
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.
La même logique s'applique aux traitements planifiés du chapitre sur
cron, avec une subtilité. Un traitement de nuit qui ne tourne pas ne
produit aucune erreur, il ne produit rien du tout. On le surveille donc à l'envers, c'est le traitement qui
signale qu'il a bien fini, et c'est l'absence de ce signal à l'heure prévue qui déclenche l'alerte.
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 taux de disponibilité cache un second chiffre, plus utile au quotidien, le temps mis à remettre le service
debout une fois qu'il est tombé. Les pannes sont inévitables, ce qui distingue les équipes, c'est qu'elles
durent dix minutes ou une demi-journée. C'est l'un des quatre indicateurs que le chapitre sur le
DevOps propose de suivre.
Communiquer pendant l'incident
Pendant que l'équipe technique cherche la cause, quelqu'un doit parler aux clients, au support et à la direction, et ce quelqu'un, c'est très souvent toi. Une page de statut publique, mise à jour toutes les trente minutes même quand il n'y a rien de neuf, un message aux clients qui dit ce qu'on sait et quand on reviendra vers eux, et une consigne claire au support. Un incident bien communiqué coûte moins cher en confiance qu'un incident deux fois plus court passé sous silence.
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.