Observabilité d’une application web : mesurer avant l’incident
Construisez l’observabilité d’une application web autour des parcours critiques : signaux, seuils, alertes, journaux, traces et reprise.
L’observabilité d’une application web ne consiste pas à accumuler des graphiques. Elle doit permettre de répondre, pendant un incident, à trois questions simples : quel parcours est dégradé, pourquoi et quelle action sûre faut-il engager maintenant ?
Commencez donc par les actions métier qui ne doivent pas échouer — envoyer une demande, payer, enregistrer un dossier, synchroniser un stock ou produire un document — puis reliez chaque symptôme à un signal, un seuil, une alerte, un responsable et une procédure de reprise. Les métriques montrent qu’un comportement change ; les journaux donnent le contexte d’un événement ; les traces suivent une requête entre plusieurs composants. Aucun de ces signaux ne remplace la preuve que le service attendu a réellement été rendu.
La matrice Anakyos parcours → symptôme → signal → seuil → alerte → responsable → action → preuve aide à construire ce système avant l’incident, sans choisir un outil trop tôt.
Qu’est-ce que l’observabilité d’une application web ?
L’observabilité est la capacité à comprendre l’état interne d’un système à partir des informations qu’il émet. Elle sert surtout à interroger un comportement inattendu sans devoir ajouter une nouvelle mesure à chaque question. L’introduction officielle d’OpenTelemetry distingue notamment trois signaux : métriques, journaux et traces.
Le monitoring, ou supervision, vérifie plutôt des conditions connues : le service répond-il, le taux d’erreur dépasse-t-il le seuil, une file grandit-elle trop vite ? L’observabilité complète cette surveillance lorsque le symptôme traverse plusieurs composants ou lorsque la cause n’était pas prévue.
La différence reste pratique :
| Besoin | Question | Signal utile |
|---|---|---|
| disponibilité | le parcours répond-il maintenant ? | contrôle synthétique ou test de bout en bout |
| niveau de service | le résultat reste-t-il dans la limite acceptée ? | indicateur agrégé et objectif explicite |
| diagnostic | où la requête ralentit-elle ou échoue-t-elle ? | trace corrélée aux journaux |
| enquête | quel événement, changement ou compte a précédé l’écart ? | journal structuré et historique de déploiement |
| reprise | la correction a-t-elle restauré le résultat métier ? | scénario rejoué et état final comparé |
Une page d’accueil qui répond en 200 ne prouve pas qu’un devis arrive dans le CRM. Un serveur avec peu de CPU ne prouve pas qu’une commande est préparée. La santé technique n’a de valeur que lorsqu’elle rejoint l’action que la personne voulait accomplir.
Commencer par les parcours critiques, pas par la plateforme
Une application produit potentiellement des milliers de mesures. Leur volume ne dit pas lesquelles méritent une alerte. La sélection commence par l’impact d’une défaillance.
Inventoriez cinq à dix parcours représentatifs : authentification, recherche, création d’un objet métier, paiement, export, synchronisation ou notification. Pour chacun, précisez le déclencheur, le résultat attendu, le délai acceptable, la source de vérité et la conséquence d’un échec.
Cette étape évite trois pièges :
- surveiller uniquement l’infrastructure parce que ses métriques sont faciles à obtenir ;
- alerter sur chaque erreur technique sans savoir si une personne ou une opération est touchée ;
- découvrir pendant l’incident que personne ne sait quelle donnée fait foi.
Le guide du logiciel métier sur mesure recommande déjà de traiter un parcours complet avant de multiplier les modules. L’observabilité suit la même logique : instrumenter moins de parcours, mais les suivre jusqu’au résultat final.
La matrice Anakyos des huit preuves
Créez une ligne par parcours critique ou par rupture qui change réellement la décision. La matrice doit rester lisible par le métier, le produit et la technique.
| Preuve | Question à trancher | Élément à conserver | Signal d’arrêt |
|---|---|---|---|
| Parcours | quelle action importante doit aboutir ? | déclencheur, résultat, source de vérité et délai | personne ne sait définir le succès |
| Symptôme | que voit la personne ou l’opération ? | erreur, lenteur, absence, doublon ou résultat faux | seule une cause technique est décrite |
| Signal | quelle observation révèle ce symptôme ? | test synthétique, événement métier, métrique, journal ou trace | le signal reste vert pendant un échec réel |
| Seuil | quand l’écart exige-t-il une décision ? | valeur, fenêtre, volume minimal et exception autorisée | seuil copié d’un outil sans lien avec le risque |
| Alerte | qui doit être interrompu, et avec quel contexte ? | gravité, canal, destinataire et délai | notification sans action possible |
| Responsable | qui qualifie, décide et communique ? | rôle principal, relais et fournisseur concerné | plusieurs équipes supposent que l’autre agit |
| Action | quel geste sûr limite puis corrige l’impact ? | arrêt, bascule, réconciliation, rejeu ou restauration | action irréversible ou non testée |
| Preuve | comment confirmer le retour à la normale ? | scénario rejoué, données comparées et décision horodatée | disparition de l’alerte prise pour une guérison |
Cette chaîne place les outils au bon endroit. Une plateforme peut collecter et corréler les signaux. Elle ne connaît ni le résultat métier attendu, ni le niveau de risque acceptable, ni la personne autorisée à relancer un traitement.
Quels signaux faut-il vraiment collecter ?
Un système utile superpose plusieurs points de vue sans les confondre.
Le contrôle extérieur vérifie le service rendu
Un test synthétique appelle l’application comme le ferait une personne ou un système tiers. Il peut charger une page, se connecter avec un compte de test, soumettre un formulaire ou vérifier une API. C’est une observation dite « boîte noire » : elle montre le symptôme sans connaître immédiatement sa cause.
Choisissez des contrôles courts, stables et sans effet commercial réel. Un test de paiement ne doit pas créer des commandes invisibles dans la comptabilité. Prévoyez des données dédiées, une annulation ou un environnement de vérification représentatif.
Les événements métier prouvent l’issue
Mesurez l’état qui compte : demande reçue, paiement confirmé, dossier créé, document disponible, synchronisation terminée. Un événement métier n’est pas un KPI marketing décoratif. Il répond à une question opérationnelle et peut déclencher une réconciliation.
Si le formulaire répond « merci » mais que le message n’arrive jamais, la page a réussi techniquement et le parcours a échoué. Cette frontière justifie un signal après l’envoi, pas seulement autour du bouton.
Les métriques montrent une évolution
Les métriques agrègent des valeurs sur une période : volume de requêtes, taux d’erreur, latence, longueur d’une file, saturation d’une ressource ou nombre de résultats métier terminés. Le chapitre de référence du Google SRE Book sur le monitoring propose quatre signaux généraux : latence, trafic, erreurs et saturation.
Ces quatre familles constituent une base, pas un tableau de bord universel. Ajoutez le minimum nécessaire pour distinguer une hausse normale de charge d’une perte de capacité ou d’un défaut fonctionnel.
Les journaux expliquent un événement
Un journal utile décrit ce qui s’est passé avec un horodatage, un niveau, un composant, une opération et un identifiant de corrélation. Préférez des champs structurés aux phrases impossibles à regrouper. Conservez la décision et le statut, pas une copie complète de chaque donnée traitée.
La CNIL recommande de tracer les opérations nécessaires à la détection des anomalies, dysfonctionnements et incidents. Elle demande aussi de limiter les données personnelles dupliquées, de protéger les traces, de leur attribuer une durée et de ne pas les détourner vers une autre finalité.
Les traces relient les composants
Une trace suit une requête entre le navigateur, l’API, une file, une base et un service externe. Chaque étape devient un span avec sa durée, son statut et des attributs choisis. La corrélation permet de passer d’un symptôme global à la portion réellement lente ou défaillante.
N’ajoutez pas automatiquement un identifiant client ou une donnée métier sensible dans tous les attributs. La documentation OpenTelemetry sur le contexte propagé rappelle que ces informations peuvent traverser des services et atteindre des destinataires inattendus. Utilisez des identifiants techniques opaques et une liste d’attributs autorisés.
Fixer un seuil à partir d’un service attendu
Une alerte doit conduire à une action. Un seuil pertinent traduit donc une promesse ou une capacité, pas seulement une variation statistique.
Pour chaque parcours, définissez un indicateur de niveau de service — un SLI — puis l’objectif associé, ou SLO. Par exemple : « 99 % des dossiers complets sont enregistrés en moins de trente secondes sur une fenêtre de vingt-huit jours ». Le chiffre n’est pas universel ; il doit venir de l’usage, du risque et de la capacité d’exploitation.
Séparez :
- la limite qui exige une action immédiate ;
- la dégradation qui mérite un ticket planifié ;
- la tendance à suivre sans interrompre une personne ;
- le journal conservé uniquement pour le diagnostic.
Le Google SRE Book distingue justement alertes, tickets et journaux. Alerter une personne sur tout ce qui paraît inhabituel crée du bruit, puis une habitude d’ignorer les notifications. Une alerte doit nommer le symptôme, le périmètre, la gravité, le lien vers les preuves et la première action sûre.
Corréler sans tout stocker
L’observabilité possède un coût de collecte, d’ingestion, de stockage et d’analyse. Elle possède aussi un risque de confidentialité. La bonne stratégie ne consiste donc pas à conserver chaque requête dans son intégralité.
Décidez signal par signal :
| Décision | Question utile |
|---|---|
| cardinalité | combien de valeurs différentes cet attribut peut-il créer ? |
| échantillonnage | quels événements doivent rester complets, et lesquels peuvent être réduits ? |
| rétention | combien de temps faut-il pour détecter, comparer et enquêter ? |
| accès | qui peut lire les traces, journaux et exports ? |
| export | peut-on changer d’outil sans perdre le protocole ni les définitions ? |
| coût | quelle décision supplémentaire cette donnée permet-elle réellement ? |
Conservez davantage de détails pour les erreurs rares et les opérations critiques ; échantillonnez prudemment les succès très fréquents lorsque cela ne détruit pas la capacité de comparer. Vérifiez cependant qu’une politique d’échantillonnage ne supprime pas les parcours minoritaires qui portent le plus de risque.
Le 2 octobre 2026, Cloudflare a annoncé une plateforme d’observabilité unifiée pour rapprocher journaux, traces, analyses, alertes, tableaux de bord et export. L’annonce confirme une tendance utile : les signaux gagnent en valeur lorsqu’ils sont corrélés. Elle rappelle aussi que le prix d’ingestion et de stockage fait partie de l’architecture ; le nouveau modèle tarifaire annoncé doit entrer en vigueur le 1er décembre 2026.
La décision Anakyos reste indépendante de cet éditeur. Définissez d’abord les parcours, les conventions et les preuves. Un outil devient alors remplaçable.
Huit scénarios de recette avant la production
La collecte peut sembler correcte alors qu’elle échoue précisément au moment utile. Testez le système d’observation comme une fonctionnalité du produit.
| Scénario | Variation introduite | Résultat à vérifier |
|---|---|---|
| parcours nominal | action complète avec données de test | résultat métier, trace et journaux corrélés sans donnée excessive |
| erreur visible | dépendance renvoie une réponse en échec | symptôme, gravité et composant fautif identifiables |
| erreur silencieuse | réponse technique réussie, écriture métier absente | contrôle d’issue ou réconciliation détecte l’écart |
| ralentissement | latence ajoutée sur un service tiers | seuil fondé sur le parcours, pas seulement sur le serveur |
| rupture de corrélation | identifiant perdu entre deux composants | diagnostic signale la frontière aveugle |
| alerte répétée | même incident persiste plusieurs fenêtres | regroupement, escalade et absence de tempête de notifications |
| outil de collecte indisponible | export ou plateforme d’observation coupé | application continue, perte connue et signal de repli disponible |
| reprise | correction appliquée puis scénario rejoué | issue métier restaurée et données affectées rapprochées |
Ajoutez un test de déploiement. Une nouvelle version doit porter son identifiant dans les signaux afin de comparer avant et après, sans conclure qu’une corrélation temporelle prouve automatiquement la cause.
Exemple fictif : un dossier validé mais jamais transmis
L’exemple suivant est fictif. Une application de gestion permet à un conseiller de valider un dossier. Le navigateur affiche la confirmation, l’API répond en 200 et la base enregistre le statut. Une tâche asynchrone doit ensuite transmettre le dossier à un service partenaire.
Pendant deux heures, le partenaire ralentit puis rejette certaines requêtes. Les métriques HTTP générales restent presque normales, car l’API principale répond vite. Le premier signal utile est métier : le nombre de dossiers « validés » augmente alors que les dossiers « transmis » stagnent au-delà du délai accepté.
L’alerte contient le parcours, la fenêtre touchée, le volume, la dernière transmission réussie et la procédure. L’équipe suspend les nouveaux rejets automatiques, vérifie les identifiants de corrélation, isole les réponses du partenaire et rapproche la file avec la source de vérité. Après correction, elle rejoue uniquement les dossiers absents avec une clé idempotente, puis compare l’état final des deux systèmes.
La preuve n’est pas la disparition de l’erreur. C’est l’absence de dossier manquant ou dupliqué dans la fenêtre concernée.
Un plan d’observabilité en dix jours ouvrés
Un premier lot peut rester modeste et complet.
- Choisir trois parcours critiques. Nommer le résultat, le délai et la source de vérité.
- Écrire les symptômes. Décrire ce qu’une personne ou une opération verrait réellement.
- Inventorier les signaux existants. Tests, événements, métriques, journaux, traces et historique de déploiement.
- Combler une frontière aveugle. Ajouter un identifiant de corrélation ou un événement d’issue avant un nouveau tableau de bord.
- Définir les seuils. Séparer interruption, ticket et simple observation.
- Attribuer les responsabilités. Nommer qui qualifie, décide, communique et restaure.
- Écrire une procédure courte. Première action, garde-fous, repli et preuve de fin.
- Recetter huit scénarios. Inclure erreur silencieuse, perte de corrélation et panne de collecte.
- Mesurer le coût. Revoir cardinalité, rétention, accès, export et budget.
- Faire un exercice. Simuler une rupture bornée et corriger ce qui dépend encore d’une mémoire individuelle.
Le résultat attendu n’est pas une plateforme « complète ». C’est une équipe capable de détecter un échec important, de le localiser assez vite et de confirmer une reprise sans improviser.
Ce que l’observabilité ne remplace pas
Les signaux ne corrigent pas une architecture sans source de vérité, une sauvegarde jamais restaurée, un fournisseur sans procédure de sortie ou un parcours dont personne ne possède la décision. Ils ne remplacent ni la sécurité, ni la recette, ni la continuité d’activité.
Le prix et le périmètre d’une maintenance web restent propriétaires des responsabilités contractuelles. Le protocole de supervision d’une application Shopify traite les webhooks, API et réconciliations propres à cette plateforme. Le guide des Core Web Vitals dans une SPA reste centré sur la performance perçue entre chargements complets et navigations douces.
Ici, la décision est plus générale : construire le plus petit système de preuves capable de relier une action importante à sa détection, son diagnostic, son responsable et sa reprise.
Mesurer avant que l’incident choisisse la question
Une application observable ne sait pas tout. Elle sait répondre aux questions qui protègent ses parcours essentiels, puis conserver assez de contexte pour enquêter sur l’inattendu. Le meilleur point de départ n’est ni un agent installé partout, ni un tableau de bord rempli. C’est un parcours dont l’échec coûte quelque chose et une preuve de reprise que l’équipe peut réellement produire.
Anakyos conçoit des logiciels métier sur mesure en reliant usage, données, architecture et exploitation. Une relecture ciblée peut transformer trois parcours critiques en matrice de signaux, seuils, alertes et procédures, puis déterminer si l’outillage actuel suffit ou si une instrumentation supplémentaire mérite son coût.
Sources principales
- OpenTelemetry — Observability primer, consulté le 13 octobre 2026 : définition, instrumentation, métriques, journaux et traces.
- Google SRE Book — Monitoring Distributed Systems, consulté le 13 octobre 2026 : symptômes et causes, monitoring boîte noire et boîte blanche, latence, trafic, erreurs et saturation.
- CNIL — Sécurité : tracer les opérations, publié le 14 mars 2024 : finalité, protection, analyse active, durée et minimisation des journaux.
- ANSSI — Recommandations de sécurité pour l’architecture d’un système de journalisation, publié le 28 janvier 2022 : architecture, intégrité et exploitation d’un système de journalisation.
- Cloudflare — 8 major updates to Cloudflare Observability, publié le 2 octobre 2026 : rapprochement des journaux, traces, alertes, tableaux de bord, export et tarification annoncée.
