{"id":13460,"date":"2021-04-01T15:10:28","date_gmt":"2021-04-01T15:10:28","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/2021\/04\/01\/surveillance-des-traces-de-pile-lacunes-dans-la-mesure-de-lexperience-utilisateur\/"},"modified":"2026-08-22T14:44:26","modified_gmt":"2026-08-22T14:44:26","slug":"surveillance-des-traces-de-pile-lacunes-dans-la-mesure-de-lexperience-utilisateur","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/surveillance-des-traces-de-pile-lacunes-dans-la-mesure-de-lexperience-utilisateur\/","title":{"rendered":"Surveillance des traces d’empilement : lacunes dans l’exp\u00e9rience utilisateur"},"content":{"rendered":"
\"D\u00e9veloppeur
Un tableau de bord APM vert et une exp\u00e9rience utilisateur d\u00e9faillante peuvent \u00eatre vrais en m\u00eame temps.<\/figcaption><\/figure>\n

Un acheteur \u00e0 Francfort clique sur Payer et regarde un spinner pendant dix secondes avant d’abandonner. Votre tableau de bord APM reste vert tout ce temps. Aucune exception d\u00e9clench\u00e9e, aucune trace de pile captur\u00e9e, car rien dans votre code n’a \u00e9chou\u00e9. Le script du fournisseur de paiement a bloqu\u00e9, la page n’a jamais termin\u00e9 de se charger, et la commande a \u00e9t\u00e9 abandonn\u00e9e. Votre backend n’a m\u00eame jamais vu la requ\u00eate finale de paiement, il n’y a donc aucune transaction \u00e9chou\u00e9e \u00e0 inspecter : du point de vue de l’application, rien ne s’est pass\u00e9. Du point de vue de l’utilisateur, la seule \u00e9tape qui comptait a \u00e9chou\u00e9.<\/p>\n

C\u2019est le point aveugle dont parle cet article. La surveillance des traces de pile est vraiment efficace dans ce qu\u2019elle fait : quand votre code lance une exception, elle fournit aux d\u00e9veloppeurs le fichier, la ligne, et la cha\u00eene d’appels qui y a conduit. Le probl\u00e8me est ce qu\u2019elle ne peut structurellement pas voir. Toute une cat\u00e9gorie de d\u00e9faillances c\u00f4t\u00e9 utilisateur se produit avant qu\u2019une requ\u00eate n\u2019atteigne votre code, apr\u00e8s que votre r\u00e9ponse en est partie, ou sans qu\u2019aucune erreur ne se d\u00e9clenche.<\/p>\n

Voici ce que la surveillance des traces de pile capture bien, les cinq lacunes qu\u2019elle laisse dans la mesure de l\u2019exp\u00e9rience utilisateur, et comment la surveillance synth\u00e9tique en navigateur r\u00e9el couvre le territoire qu\u2019elle ne peut pas.<\/p>\n

Qu\u2019est-ce que la surveillance des traces de pile ?<\/h2>\n

Une trace de pile est un instantan\u00e9 de la pile d\u2019appels au moment o\u00f9 une erreur se produit : quelles fonctions s\u2019ex\u00e9cutaient, dans quels fichiers, \u00e0 quelles lignes, et dans quel ordre elles ont \u00e9t\u00e9 appel\u00e9es. Si vous avez d\u00e9j\u00e0 vu une erreur console listant une cascade de m\u00e9thodes et de chemins de fichiers, vous en avez lu une.<\/p>\n

La surveillance des traces de pile, telle que pratiqu\u00e9e par les outils de surveillance de la performance applicative (APM)<\/a>, capture automatiquement ces traces, les regroupe, et suit la fr\u00e9quence de r\u00e9currence de chaque exception. Quand une NullPointerException commence \u00e0 se produire dans le service de paiement, la plateforme APM indique aux d\u00e9veloppeurs pr\u00e9cis\u00e9ment o\u00f9 chercher et l\u2019\u00e9tendue du probl\u00e8me. Les exceptions qui autrement dispara\u00eetraient dans un fichier journal deviennent des t\u00e2ches class\u00e9es, tendance et assignables.<\/p>\n

Notez la condition de d\u00e9clenchement, car tout le reste de cet article en d\u00e9coule : une trace de pile existe seulement lorsque le code s\u2019ex\u00e9cute et lance une erreur. Les deux moiti\u00e9s de cette condition comptent. Si votre code ne s\u2019ex\u00e9cute jamais, ou s\u2019ex\u00e9cute sans lancer d\u2019erreur, il n\u2019y a pas de trace, peu importe ce que l\u2019utilisateur vient d\u2019exp\u00e9rimenter.<\/p>\n

Une fa\u00e7on pratique de retenir cela : le code s\u2019est ex\u00e9cut\u00e9 et a lanc\u00e9 une erreur, vous obtenez une trace. Le code s\u2019est ex\u00e9cut\u00e9 lentement sans erreur, pas de trace. Le navigateur a \u00e9chou\u00e9 avant d\u2019atteindre votre code, pas de trace. Quelque chose hors de votre code a bloqu\u00e9 le parcours apr\u00e8s le d\u00e9part de votre r\u00e9ponse, pas de trace. Un \u00e9tat sur quatre produit une preuve, et les utilisateurs vivent dans les quatre.<\/p>\n

Ce que la surveillance des traces de pile capture bien<\/h2>\n

Rien de ce qui suit n\u2019est un argument contre l\u2019APM. Pour les d\u00e9faillances qui prennent naissance dans votre code, les traces de pile sont le chemin le plus rapide du sympt\u00f4me \u00e0 la correction :<\/p>\n