Un SaaS en production sans observabilité, c'est une voiture sans tableau de bord. On avance, jusqu'au moment où quelque chose se grippe, et on n'a aucun moyen de savoir depuis combien de temps le problème existait, ni ce qui l'a causé. Sur une plateforme multi-tenant où une dégradation de service touche potentiellement plusieurs organisations clientes simultanément, cette situation est inacceptable.

L'observabilité, c'est la capacité à comprendre l'état interne d'un système à partir de ses sorties : métriques, logs, traces. CloudWatch est notre couche principale sur AWS. Pas parce que c'est l'outil le plus sophistiqué du marché, mais parce qu'il est profondément intégré à chaque service AWS qu'on utilise, sans configuration supplémentaire pour commencer.

Les métriques : savoir ce qui se passe en temps réel

CloudWatch collecte automatiquement les métriques des services AWS : utilisation CPU des instances EC2, connexions actives et latence sur les bases RDS, requêtes et codes de réponse sur le load balancer, latence et taux d'erreur sur les distributions CloudFront. Ce sont les signaux vitaux de l'infrastructure.

Notre architecture rend ces métriques directement lisibles client par client. Chaque organisation dispose de son propre environnement Elastic Beanstalk et de sa propre instance RDS : une dégradation qui touche un client apparaît sur ses propres ressources, nettement séparée de celles des autres. C'est la différence entre "tout va bien en moyenne" et "la base de ce client sature depuis dix minutes".

Les logs : comprendre ce qui s'est passé

Les journaux des bases RDS et ceux du WAF sont centralisés dans CloudWatch Logs, chacun dans son Log Group, avec une politique de rétention définie par catégorie.

CloudWatch Logs Insights permet d'interroger ces logs avec un langage de requête proche de SQL. Retrouver toutes les erreurs d'une base pendant une plage horaire, identifier les requêtes lentes, repérer les règles WAF déclenchées sur un endpoint : des investigations qui prenaient des heures en parcourant des fichiers manuellement deviennent des requêtes de quelques secondes.

fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 50

La rétention des logs a aussi une dimension RGPD. On définit des durées de conservation différenciées selon la sensibilité des données : plus courte pour les logs qui contiennent des informations sur le comportement des utilisateurs, plus longue pour les logs d'audit de sécurité qui peuvent être nécessaires en cas d'incident.

Les erreurs applicatives : Rollbar

Côté application, les erreurs PHP sont remontées dans Rollbar. Chaque exception arrive regroupée avec ses occurrences, sa trace et l'environnement concerné, ce qui permet de savoir immédiatement quel client est touché et depuis quand. Rollbar est configuré pour laisser de côté l'adresse IP des utilisateurs : on garde le contexte technique utile au diagnostic, et lui seul.

Les alarmes : être alerté avant les utilisateurs

Une métrique sans alarme est une métrique qu'on ne regarde que quand quelque chose est déjà cassé. Les alarmes CloudWatch surveillent les métriques en continu et déclenchent des notifications via SNS dès qu'un seuil est franchi.

Les health checks du load balancer complètent ce dispositif : Elastic Beanstalk suit en permanence l'état de santé de chaque environnement client et le signale dès qu'il se dégrade.

CloudWatch et Wazuh : deux couches complémentaires

CloudWatch couvre l'observabilité opérationnelle : performances, disponibilité, comportement applicatif. Wazuh couvre la couche sécurité : intégrité des fichiers, détection de comportements suspects sur les serveurs, corrélation d'événements de sécurité, avec un agent dans chaque environnement.

Les deux s'alimentent de sources différentes et répondent à des questions différentes. CloudWatch répond à "est-ce que la plateforme fonctionne correctement ?". Wazuh répond à "est-ce que quelqu'un ou quelque chose tente de compromettre l'infrastructure ?". La combinaison couvre l'essentiel des situations qu'une équipe SaaS doit détecter et traiter rapidement.

Ce que ça a changé en pratique

Avant d'avoir cette stack en place, on découvrait les incidents en même temps que les utilisateurs, parfois après. Le post-mortem se faisait avec des logs épars et une reconstitution approximative de la chronologie.

Aujourd'hui, les incidents sont détectés avant qu'ils impactent les utilisateurs dans la majorité des cas, la chronologie d'un incident est reconstituable à la seconde près, et les investigations de performance ont une base factuelle plutôt qu'intuitive. Ce n'est pas une garantie zéro incident. C'est la capacité à répondre vite et à apprendre de chaque situation.