Votre monitoring ment : comment savoir si votre SaaS va vraiment bien

Votre dashboard est vert. Les serveurs répondent. La mémoire est sous contrôle. Aucun voyant rouge.

Et pourtant, un client vous écrit que le paiement tourne dans le vide depuis dix minutes.

C'est le moment où l'on découvre la différence entre surveiller une infrastructure et comprendre un produit en production.

Beaucoup de startups ont un monitoring qui mesure la santé technique de leurs machines. Peu savent répondre rapidement à une question plus importante : est-ce que l'utilisateur réussit réellement à faire ce qu'il est venu faire ?

Ce n'est pas un problème d'outil. C'est un problème de signal, de priorité et de lien avec le métier.

Un dashboard vert ne veut pas dire que le produit va bien

Un serveur peut être disponible alors que le parcours de paiement échoue. Une API peut renvoyer un statut HTTP 200 tout en retournant une réponse inutilisable. Une file peut continuer à recevoir des messages alors que son traitement a pris deux heures de retard.

Les métriques d'infrastructure sont utiles. Elles répondent à des questions comme :

• Combien de CPU et de mémoire consomme le service ?
• Combien de requêtes arrive-t-il à traiter ?
• Le processus est-il encore démarré ?
• Le réseau ou la base de données montrent-ils un signe de saturation ?

Elles ne répondent pas toujours à la question qui intéresse le client : mon action a-t-elle abouti ?

C'est le piège classique d'un monitoring construit depuis les composants techniques vers l'utilisateur. On collecte ce que les outils savent facilement mesurer, puis on espère que ces indicateurs décriront l'expérience réelle. Ils ne le font pas forcément.

Le premier changement consiste donc à partir des parcours critiques : se connecter, rechercher, payer, envoyer un document, recevoir une notification. Pour chacun, il faut savoir ce que signifie "ça marche", ce que signifie "c'est dégradé" et ce que l'équipe doit faire quand la réponse est non.

Monitoring et observabilité ne désignent pas la même chose

Le monitoring vérifie des conditions connues à l'avance. Par exemple : la latence dépasse un seuil, le taux d'erreur augmente, un disque approche de sa capacité maximale.

L'observabilité cherche à rendre un système suffisamment explicite pour permettre d'en comprendre le comportement, y compris lorsqu'un problème n'avait pas été anticipé. Elle s'appuie généralement sur des métriques, des logs et des traces corrélés par un contexte commun.

OpenTelemetry décrit cette approche comme un framework open source et indépendant des fournisseurs pour instrumenter, générer, collecter et exporter des données de télémétrie, notamment les traces, les métriques et les logs. OpenTelemetry n'est pas le backend qui stocke ou affiche ces données : il standardise surtout la manière de les produire et de les transporter. Documentation OpenTelemetry

La distinction est importante pour une équipe réduite. Installer un nouvel outil ne crée pas automatiquement de l'observabilité. Si les signaux ne permettent pas de relier une erreur à une version, un parcours utilisateur et une action technique, vous avez peut-être plus de graphiques, mais pas plus de compréhension.

Les quatre signaux qui méritent votre attention

Vous n'avez pas besoin de tout instrumenter le premier jour. Commencez par les signaux qui répondent à quatre questions différentes.

1. Le résultat métier

Combien de tentatives de paiement aboutissent ? Combien de fichiers sont réellement traités ? Combien d'emails importants sont livrés ?

Cette métrique doit être calculée à partir d'un événement métier, pas déduite uniquement d'un code HTTP. Elle doit distinguer une action réussie d'une action techniquement acceptée mais fonctionnellement incomplète.

C'est souvent le signal le plus difficile à mettre en place, parce qu'il demande de choisir ce que "réussi" signifie. C'est aussi celui qui permet de sortir d'une discussion purement technique : une baisse du taux de paiement réussi est un problème produit et business, même si tous les serveurs semblent en bonne santé.

2. La latence vécue par l'utilisateur

La moyenne est rarement suffisante. Une moyenne peut rester correcte alors qu'une minorité d'utilisateurs attend beaucoup trop longtemps. Suivez au minimum des percentiles, par exemple la latence sous laquelle se trouvent 95 % des requêtes, et regardez-les par parcours critique.

Le bon indicateur n'est pas forcément la latence de chaque endpoint. C'est le temps nécessaire pour terminer l'action qui compte pour l'utilisateur. Une page rapide avec une API lente appelée ensuite reste une expérience lente.

3. Les erreurs réellement actionnables

Une alerte doit signaler une situation qui demande une décision humaine. Elle doit dire ce qui est dégradé, depuis quand, avec quelle portée, et où commencer l'investigation.

Une alerte sur chaque exception n'est pas une politique d'alerte. C'est une boîte mail transformée en bruit de fond. À terme, l'équipe apprend à l'ignorer, y compris lorsque l'incident est sérieux.

Séparez les erreurs qui bloquent un parcours critique, les erreurs récupérées automatiquement et les événements utiles pour le diagnostic mais qui ne nécessitent pas de réveiller quelqu'un. Le journal peut tout conserver. La page d'astreinte, elle, doit rester courte.

4. Le chemin complet d'une requête

Une erreur visible dans le frontend peut venir de l'API, d'un appel à un fournisseur externe, d'une requête SQL ou d'un worker asynchrone. Sans identifiant de corrélation, chaque équipe cherche dans son propre outil et reconstitue l'histoire à la main.

Une trace distribuée permet de suivre une opération à travers ses différents composants. Les logs et les métriques associés au même contexte rendent ensuite la recherche beaucoup plus rapide. Ce n'est pas réservé aux architectures en microservices : un monolithe qui appelle une base, un service de paiement et un worker peut déjà bénéficier de ce modèle.

Les SLO rendent la fiabilité arbitrable

Dire "il faut que ce soit fiable" ne permet pas de prendre une décision. Il faut définir ce que l'on promet implicitement à l'utilisateur et quel niveau de dégradation est acceptable.

Un SLI est l'indicateur observé, par exemple le taux de paiements réussis ou la proportion de requêtes servies sous un certain délai. Un SLO est l'objectif fixé sur cet indicateur pendant une période donnée. Un SLA est un engagement contractuel qui peut prévoir des conséquences s'il n'est pas tenu.

Le SLO n'est donc pas une promesse vague de perfection. C'est un outil de décision. Si l'objectif de fiabilité est respecté, l'équipe peut continuer à livrer. Si la marge d'erreur acceptable est consommée, la priorité peut basculer vers la réduction du risque plutôt que vers une nouvelle fonctionnalité.

Google SRE formalise cette marge sous le nom d'error budget, le budget d'erreur. L'idée n'est pas de maximiser la disponibilité à n'importe quel prix, mais d'équilibrer fiabilité, vitesse d'innovation et coût opérationnel. Service Level Objectives et Embracing Risk

Pour une petite équipe, un SLO utile peut tenir sur une page :

1. Le parcours concerné.
2. La définition précise d'une réussite.
3. La fenêtre d'observation.
4. Le seuil qui déclenche une action.
5. La personne qui décide quoi faire lorsque le budget est consommé.

Ne commencez pas par fixer un objectif spectaculaire. Commencez par un objectif que vous pouvez mesurer, expliquer et utiliser pour arbitrer la roadmap.

Les erreurs de conception que je retrouve le plus souvent

Mesurer les composants au lieu des parcours

Un serveur, une base et une file peuvent tous être "up" pendant qu'un workflow client est bloqué. La supervision technique doit être reliée à quelques transactions représentatives du produit.

Alerter sur des seuils sans contexte

"CPU à 80 %" n'est pas une décision. Est-ce nouveau ? Est-ce corrélé à une hausse du trafic ? Le service répond-il plus lentement ? Le seuil indique-t-il un risque imminent ou seulement une activité normale ? Une alerte sans contexte transfère le travail de diagnostic à la personne qui la reçoit.

Confondre logs et stratégie de diagnostic

Écrire davantage de logs ne suffit pas. Un log doit donner un événement compréhensible, un niveau de gravité, un identifiant de corrélation, une version et les informations nécessaires pour agir, sans exposer de données sensibles. Les messages doivent rester exploitables lorsqu'ils sont agrégés et filtrés, pas seulement lisibles dans un terminal.

Copier la complexité des grandes organisations

Une startup n'a pas besoin de reproduire toute la plateforme d'une entreprise internationale. Elle a besoin de savoir quels parcours sont critiques, qui reçoit les alertes, comment revenir à la dernière version saine et comment apprendre après un incident.

Les métriques DORA peuvent aider à regarder la performance de livraison sous l'angle du débit et de la stabilité, mais elles ne remplacent pas les indicateurs de réussite du produit. Guide des métriques DORA

Une progression réaliste en quatre étapes

Étape 1 : choisir trois parcours critiques

Listez les actions sans lesquelles le produit perd une partie essentielle de sa valeur. Pour chacune, écrivez une définition observable de la réussite et de l'échec. Si l'équipe ne sait pas formuler cette définition, le problème est probablement produit avant d'être technique.

Étape 2 : instrumenter la chaîne minimale

Ajoutez les métriques de résultat, la latence par parcours, les erreurs actionnables et un contexte de corrélation. Vérifiez que les données ne contiennent pas de secrets, de mots de passe ou de données personnelles inutiles.

Étape 3 : écrire les alertes comme des procédures

Chaque alerte importante doit avoir un propriétaire, un niveau d'urgence, un lien vers un dashboard utile et quelques premières vérifications. Si la seule instruction est "regarder les logs", l'alerte n'est pas terminée.

Étape 4 : utiliser les incidents pour améliorer le système

Après un incident, demandez quels signaux auraient permis de le détecter plus tôt, quelle information a manqué pour le diagnostiquer, et quelle action empêchera sa répétition. Le but n'est pas de remplir un rapport. Le but est de transformer une surprise en capacité de détection et de récupération.

Cette démarche complète naturellement un audit technique ou une mission de CTO à temps partiel, mais elle peut aussi démarrer avec une équipe interne et un tableau blanc. L'outil vient après les décisions.

FAQ : monitoring et observabilité d'un SaaS

Quelle est la différence entre monitoring et observabilité ?

Le monitoring vérifie des conditions et des seuils connus. L'observabilité fournit les signaux et le contexte nécessaires pour comprendre un comportement inattendu. Le monitoring est une partie de l'observabilité, pas son équivalent.

Faut-il mettre en place OpenTelemetry pour un monolithe ?

Pas nécessairement dès le départ, mais un monolithe peut lui aussi produire des métriques, des logs structurés et des traces utiles. La décision dépend de la complexité du parcours, du nombre de dépendances et du niveau de diagnostic nécessaire, pas du simple fait d'utiliser ou non des microservices.

Combien d'alertes faut-il créer ?

Il n'existe pas de nombre universel. Créez en priorité les alertes qui correspondent à une dégradation réelle d'un parcours critique et qui appellent une action claire. Une alerte ignorée parce qu'elle se répète est un défaut de conception, pas une fatalité opérationnelle.

Quelle métrique suivre en premier pour une startup ?

Commencez par le taux de réussite d'un parcours qui crée directement de la valeur, par exemple une activation, une commande ou un paiement. Complétez-le par la latence et les erreurs de ce même parcours. Une métrique métier reliée à des signaux techniques est plus utile qu'un grand catalogue de métriques isolées.

Les SLO sont-ils réservés aux grandes équipes SRE ?

Non. Un SLO est simplement un objectif mesurable qui aide à arbitrer entre fiabilité et livraison. Une petite équipe peut en définir un ou deux sur ses parcours les plus importants, sans créer une organisation SRE complète.

Ce que je recommande en tant que CTO hands-on

Ne commencez pas par choisir un outil d'observabilité. Commencez par écrire les trois parcours que vous ne pouvez pas vous permettre de ne pas comprendre.

Ensuite, reliez chaque parcours à un résultat métier, une latence, des erreurs et un chemin de diagnostic. Définissez un SLO assez simple pour être discuté en réunion produit et technique. Enfin, utilisez chaque incident pour réduire l'inconnu, pas seulement pour ajouter une alerte.

Un dashboard peut être vert et votre produit en panne. La vraie maturité opérationnelle commence lorsque vos signaux décrivent l'expérience de vos utilisateurs et permettent à votre équipe de décider quoi faire ensuite.

Sources

• OpenTelemetry, What is OpenTelemetry?
• Google SRE, Service Level Objectives
• Google SRE, Embracing Risk
• DORA, Software delivery performance metrics