{"id":34149,"date":"2026-06-12T00:20:12","date_gmt":"2026-06-12T00:20:12","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/what-is-application-performance-monitoring\/"},"modified":"2026-06-12T00:36:08","modified_gmt":"2026-06-12T00:36:08","slug":"qu-est-ce-que-la-surveillance-des-performances-des-applications","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/qu-est-ce-que-la-surveillance-des-performances-des-applications\/","title":{"rendered":"Qu&#8217;est-ce que la surveillance des performances des applications (APM) ?"},"content":{"rendered":"<p><img fetchpriority=\"high\" decoding=\"async\" class=\"alignnone size-full wp-image-34098\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/06\/application-performance-monitoring-explained-hero.jpg\" alt=\"Illustration holographique de la surveillance des performances applicatives : m\u00e9triques, traces et logs transitant d'une application instrument\u00e9e vers un tableau de bord APM unifi\u00e9 sur un fond bleu marine profond.\" width=\"1344\" height=\"768\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/06\/application-performance-monitoring-explained-hero.jpg 1344w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/06\/application-performance-monitoring-explained-hero-300x171.jpg 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/06\/application-performance-monitoring-explained-hero-1024x585.jpg 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/06\/application-performance-monitoring-explained-hero-768x439.jpg 768w\" sizes=\"(max-width: 1344px) 100vw, 1344px\" \/><\/p>\n<p><strong>La surveillance des performances applicatives (APM) est la pratique consistant \u00e0 collecter, corr\u00e9ler et analyser des donn\u00e9es t\u00e9l\u00e9m\u00e9triques (m\u00e9triques, traces, logs et \u00e9v\u00e9nements) provenant de logiciels en fonctionnement pour d\u00e9tecter des r\u00e9gressions de performance, localiser les causes profondes et v\u00e9rifier les objectifs de niveau de service.<\/strong> Un <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/solutions\/surveillance-des-performances-des-applications-dotcom-monitor\/\">outil APM<\/a> instrumente les applications soit via des agents sp\u00e9cifiques \u00e0 un langage, des SDK, ou des standards ouverts comme OpenTelemetry, puis envoie ces donn\u00e9es vers un backend qui les rend accessibles via des tableaux de bord, des alertes et des diagnostics au niveau des traces.<\/p>\n<h2 id='apm-gestion-des-performances-applicatives-et-gestion-de-portefeuille-applicatif-ne-sont-pas-identiques'  id=\"boomdevs_1\" id=\"apm-application-performance-management-and-application-portfolio-management-are-not-the-same\">APM, gestion des performances applicatives et gestion de portefeuille applicatif ne sont pas identiques<\/h2>\n<p>Trois disciplines diff\u00e9rentes partagent l\u2019acronyme APM. Les distinguer d\u00e8s le d\u00e9part \u00e9vite la confusion lors de la lecture de la documentation des fournisseurs.<\/p>\n<p><strong>La surveillance des performances applicatives<\/strong> est la couche de mesure : collecte de la t\u00e9l\u00e9m\u00e9trie d\u2019une application en fonctionnement et affichage sous forme de m\u00e9triques, traces et logs. Elle r\u00e9pond \u00e0 <em>l\u2019application est-elle saine en ce moment, et si ce n\u2019est pas le cas, o\u00f9 se situe le probl\u00e8me ?<\/em><\/p>\n<p><strong>La gestion des performances applicatives<\/strong> est une discipline plus large : d\u00e9finition des SLO, \u00e9laboration de budgets de performance, ex\u00e9cution de tests de charge, instrumentation du code, exploitation de la pile de surveillance, et action sur les informations obtenues. La surveillance est une composante de la gestion.<\/p>\n<p><strong>La gestion de portefeuille applicatif<\/strong> se situe au niveau de l\u2019architecture d\u2019entreprise. Elle suit l\u2019int\u00e9gralit\u00e9 du parc applicatif d\u2019une organisation et d\u00e9cide des investissements, de la modernisation, de la consolidation ou du retrait. Elle utilise les donn\u00e9es de surveillance en entr\u00e9e mais n\u2019est pas une discipline de performance en soi.<\/p>\n<p>Lorsque cet article utilise \u201cAPM\u201d sans pr\u00e9cision, il se r\u00e9f\u00e8re \u00e0 la surveillance des performances applicatives.<\/p>\n<h2 id='surveillance-des-performances-applicatives-vs-observabilit\u00e9'  id=\"boomdevs_2\" id=\"application-performance-monitoring-vs-observability\">Surveillance des performances applicatives vs Observabilit\u00e9<\/h2>\n<p><strong>APM est un sous-ensemble de l\u2019observabilit\u00e9.<\/strong> APM se concentre sur la performance au niveau applicatif : temps de r\u00e9ponse, d\u00e9bit, taux d\u2019erreur, flux de transactions. L\u2019observabilit\u00e9 est la pratique plus large qui permet de poser des questions arbitraires sur l\u2019\u00e9tat interne d\u2019un syst\u00e8me \u00e0 partir de la t\u00e9l\u00e9m\u00e9trie \u00e9mise, incluant les donn\u00e9es d\u2019infrastructure, r\u00e9seau et \u00e9v\u00e9nements m\u00e9tier.<\/p>\n<p>En termes pratiques :<\/p>\n<ul>\n<li>Les outils APM vous indiquent que la latence p95 de l\u2019endpoint \/checkout est pass\u00e9e de 180 ms \u00e0 1,4 s apr\u00e8s le d\u00e9ploiement de 14:02.<\/li>\n<li>Une pile d\u2019observabilit\u00e9 vous permet de corr\u00e9ler cela avec un \u00e9v\u00e9nement de pression m\u00e9moire sur un n\u0153ud Kubernetes, une mont\u00e9e en attente de verrou Postgres, et un d\u00e9ploiement de feature flag survenus dans la m\u00eame fen\u00eatre.<\/li>\n<\/ul>\n<p>Les plateformes APM modernes (Datadog APM, New Relic, Dynatrace, Elastic Observability, Grafana Cloud, Splunk Observability Cloud) ont int\u00e9gr\u00e9 suffisamment la surface plus large de l\u2019observabilit\u00e9 pour que la fronti\u00e8re soit floue. Le mod\u00e8le mental le plus clair : l\u2019observabilit\u00e9 est l\u2019objectif, l\u2019APM est la tranche centr\u00e9e sur l\u2019application des donn\u00e9es n\u00e9cessaires pour l\u2019atteindre.<\/p>\n<h2 id='comment-fonctionne-la-surveillance-des-performances-applicatives'  id=\"boomdevs_3\" id=\"how-application-performance-monitoring-works\">Comment fonctionne la surveillance des performances applicatives<\/h2>\n<p>L\u2019APM fonctionne en quatre \u00e9tapes : instrumentation, collecte, transmission et corr\u00e9lation.<\/p>\n<h3 id='1-instrumentation'  id=\"boomdevs_4\" id=\"1-instrumentation\">1. Instrumentation<\/h3>\n<p>L\u2019instrumentation ajoute des points de mesure au code applicatif afin qu\u2019il \u00e9mette de la t\u00e9l\u00e9m\u00e9trie. Trois approches courantes existent :<\/p>\n<ul>\n<li><strong>Agents d\u2019auto-instrumentation. <\/strong>Des agents d\u2019ex\u00e9cution sp\u00e9cifiques au langage (instrumentation du bytecode Java, profileurs .NET, biblioth\u00e8ques Python ou Node.js OpenTelemetry d\u2019auto-instrumentation) s\u2019int\u00e8grent aux points d\u2019entr\u00e9e du framework (gestionnaires HTTP, pilotes de bases de donn\u00e9es, clients de files de messages) sans n\u00e9cessiter de modification du code.<\/li>\n<li><strong>Instrumentation manuelle via SDK. <\/strong>Les d\u00e9veloppeurs appellent directement les SDK APM ou OpenTelemetry pour d\u00e9marrer et arr\u00eater des spans, attacher des attributs, et \u00e9mettre des m\u00e9triques personnalis\u00e9es. Requis pour les transactions m\u00e9tier sp\u00e9cifiques que l\u2019agent ne reconna\u00eet pas.<\/li>\n<li><strong>eBPF et collecte sans agent. <\/strong>Des sondes au niveau du noyau capturent les appels syst\u00e8me, donn\u00e9es r\u00e9seau et processus sans modifier l\u2019application. Utile dans des environnements o\u00f9 l\u2019installation d\u2019agents est restreinte (charges de travail soumises \u00e0 conformit\u00e9, services tiers).<\/li>\n<\/ul>\n<p>OpenTelemetry (OTel) est le standard ouvert de facto pour l\u2019instrumentation toutes approches confondues. Il d\u00e9finit le protocole filaire (OTLP), les conventions s\u00e9mantiques pour la d\u00e9nomination des spans et m\u00e9triques, ainsi que les SDKs dans Java, Go, Python, Node.js, .NET, Ruby, PHP et autres. Erlang et Elixir sont couverts par la biblioth\u00e8que officielle opentelemetry-erlang. Les traces Rust sont stables ; les logs et m\u00e9triques sont en progression. Swift est disponible sous la forme d\u2019un SDK maintenu par la communaut\u00e9.<\/p>\n<h3 id='2-collecte'  id=\"boomdevs_5\" id=\"2-collection\">2. Collecte<\/h3>\n<p>L\u2019application instrument\u00e9e \u00e9met trois types principaux de signaux :<\/p>\n<ul>\n<li><strong>M\u00e9triques<\/strong> : mesures num\u00e9riques \u00e0 un instant donn\u00e9 (nombre de requ\u00eates, histogramme de latence, utilisation CPU).<\/li>\n<li><strong>Traces<\/strong> : ensembles ordonn\u00e9s de spans repr\u00e9sentant le parcours d\u2019une requ\u00eate unique \u00e0 travers les services.<\/li>\n<li><strong>Logs<\/strong> : enregistrements textuels horodat\u00e9s, id\u00e9alement structur\u00e9s en JSON, avec ID de trace et de span pour corr\u00e9lation.<\/li>\n<\/ul>\n<p>Les types de signaux plus r\u00e9cents incluent les <strong>profils continus<\/strong> (profil CPU, m\u00e9moire et verrous \u00e9chantillonn\u00e9s en production) et les \u00e9v\u00e9nements <strong>Real User Monitoring (RUM)<\/strong> \u00e9mis par des SDK JavaScript ou mobiles s\u2019ex\u00e9cutant dans le navigateur ou l\u2019appareil de l\u2019utilisateur. Le signal OpenTelemetry Profiles a \u00e9t\u00e9 accept\u00e9 comme OTEP en 2024 et est encore en maturation ; le support backend est partiel \u00e0 l\u2019horizon 2025\u20132026.<\/p>\n<h3 id='3-transmission'  id=\"boomdevs_6\" id=\"3-transmission\">3. Transmission<\/h3>\n<p>La t\u00e9l\u00e9m\u00e9trie circule de l\u2019application vers un backend via deux voies possibles :<\/p>\n<ul>\n<li><strong>Export direct <\/strong>de l\u2019agent ou SDK vers le point d\u2019ingestion du fournisseur APM via OTLP, HTTP ou un protocole propri\u00e9taire.<\/li>\n<li><strong>Via un collecteur <\/strong>(OpenTelemetry Collector, ou une distribution sp\u00e9cifique comme Datadog Agent ou Splunk Distribution of OpenTelemetry Collector) qui regroupe, filtre, \u00e9chantillonne et route les donn\u00e9es. Des relais orient\u00e9s logs tels que Fluent Bit et Vector peuvent g\u00e9rer logs et m\u00e9triques en parall\u00e8le du collecteur OTel pour les traces. Les collecteurs d\u00e9couplent l\u2019instrumentation du backend, rendant possible un changement de fournisseur sans r\u00e9instrumentation du code.<\/li>\n<\/ul>\n<h3 id='4-corr\u00e9lation'  id=\"boomdevs_7\" id=\"4-correlation\">4. Corr\u00e9lation<\/h3>\n<p>Le backend relie les signaux via des identifiants (ID de trace, ID de span, nom de service, h\u00f4te, ID de conteneur, ID utilisateur) afin qu\u2019une investigation d\u00e9but\u00e9e sur un signal puisse basculer sur les autres. Un flux de travail typique : une alerte d\u00e9clenche une hausse du taux d\u2019erreur \u2192 clic vers les traces du service affect\u00e9 \u2192 analyse d\u2019une trace repr\u00e9sentative en \u00e9chec \u2192 bascule du span lent vers ses logs \u2192 confirmation de la requ\u00eate base de donn\u00e9es fautive \u2192 v\u00e9rification des m\u00e9triques de l\u2019h\u00f4te base de donn\u00e9es. Ce chemin de bascule distingue une plateforme APM d\u2019une collection d\u2019outils isol\u00e9s.<\/p>\n<h2 id='composants-principaux-d-une-pile-apm'  id=\"boomdevs_8\" id=\"core-components-of-an-apm-stack\">Composants principaux d\u2019une pile APM<\/h2>\n<p>Un d\u00e9ploiement APM complet comprend :<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Composant<\/th>\n<th>Utilit\u00e9<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Agents \/ SDK \/ biblioth\u00e8ques OTel<\/td>\n<td>Instrumenter l\u2019application et \u00e9mettre la t\u00e9l\u00e9m\u00e9trie<\/td>\n<\/tr>\n<tr>\n<td>Collecteur<\/td>\n<td>Regrouper, filtrer, \u00e9chantillonner et router la t\u00e9l\u00e9m\u00e9trie<\/td>\n<\/tr>\n<tr>\n<td>Backend des m\u00e9triques<\/td>\n<td>Stockage en s\u00e9ries temporelles, alertes, tableaux de bord<\/td>\n<\/tr>\n<tr>\n<td>Backend des traces<\/td>\n<td>Stockage des spans, cartographie des d\u00e9pendances, analyse de latence<\/td>\n<\/tr>\n<tr>\n<td>Backend des logs<\/td>\n<td>Stockage index\u00e9 des logs avec corr\u00e9lation des traces<\/td>\n<\/tr>\n<tr>\n<td>RUM et surveillance synth\u00e9tique<\/td>\n<td>Mesurer la performance du point de vue utilisateur<\/td>\n<\/tr>\n<tr>\n<td>Alerting et int\u00e9gration de r\u00e9ponse aux incidents<\/td>\n<td>Acheminer les signaux vers les astreintes (PagerDuty, Opsgenie, Slack)<\/td>\n<\/tr>\n<tr>\n<td>Profileur<\/td>\n<td>Profilage continu CPU et m\u00e9moire en production<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p><strong>Comment couvrir la surveillance synth\u00e9tique avec Dotcom-Monitor.<\/strong> Dotcom-Monitor offre quatre produits de surveillance synth\u00e9tique partageant un workflow unique d\u2019alerte et de rapport. Utilisez <a href=\"https:\/\/www.dotcom-monitor.com\/wiki\/knowledge-base\/browserview-platform\/\">BrowserView<\/a> pour le timing de chargement des pages uniques sur plus de 40 combinaisons de navigateurs et appareils. Utilisez <a href=\"https:\/\/www.dotcom-monitor.com\/wiki\/knowledge-base\/userview-platform\/\">UserView<\/a> pour les flux transactionnels multi-\u00e9tapes (connexion, recherche, paiement). Utilisez <a href=\"https:\/\/www.dotcom-monitor.com\/wiki\/knowledge-base\/webview-platform\/\">WebView<\/a> pour la surveillance API REST, SOAP et GraphQL. Utilisez <a href=\"https:\/\/www.dotcom-monitor.com\/wiki\/knowledge-base\/serverview-platform\/\">ServerView<\/a> pour les contr\u00f4les TCP, DNS, SMTP, FTP, ICMP et autres protocoles r\u00e9seau. Pour les applications internes derri\u00e8re un pare-feu, installez le Private Agent sur un serveur dans le r\u00e9seau. C\u2019est un binaire unique initiant des connexions sortantes vers la plateforme, donc aucune r\u00e8gle de pare-feu entrante n\u2019est requise et les endpoints internes restent priv\u00e9s.<\/p>\n<h2 id='m\u00e9triques-apm-importantes'  id=\"boomdevs_9\" id=\"apm-metrics-that-matter\">M\u00e9triques APM importantes<\/h2>\n<p>Voici les m\u00e9triques que la plupart des \u00e9quipes instrumentent et surveillent. Les d\u00e9finitions sont align\u00e9es avec les conventions s\u00e9mantiques OpenTelemetry quand c\u2019est applicable.<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>M\u00e9trique<\/th>\n<th>D\u00e9finition<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Temps de r\u00e9ponse \/ latence<\/td>\n<td>Temps chronom\u00e9tr\u00e9 entre la r\u00e9ception d\u2019une requ\u00eate et l\u2019envoi de la r\u00e9ponse. Surveillez p50, p95, p99 et p99.9 s\u00e9par\u00e9ment ; les moyennes masquent la latence en queue de distribution.<\/td>\n<\/tr>\n<tr>\n<td>D\u00e9bit<\/td>\n<td>Requ\u00eates trait\u00e9es par unit\u00e9 de temps, typiquement requ\u00eates par seconde (RPS) ou par minute (RPM).<\/td>\n<\/tr>\n<tr>\n<td>Taux d\u2019erreur<\/td>\n<td>Fraction des requ\u00eates retournant un 5xx, g\u00e9n\u00e9rant une exception, ou violant une r\u00e8gle m\u00e9tier. Exprim\u00e9 en pourcentage.<\/td>\n<\/tr>\n<tr>\n<td>Score Apdex<\/td>\n<td>Indice de satisfaction utilisateur entre 0 et 1 d\u00e9riv\u00e9 d\u2019un seuil de latence configurable T. Apdex = (satisfaits + tol\u00e9rants\/2) \/ total. Consid\u00e9r\u00e9 comme obsol\u00e8te par la plupart des \u00e9quipes SRE aujourd\u2019hui, pr\u00e9f\u00e9rant des cibles SLI\/SLO explicites de latence (par ex., p99 &lt; 500 ms sur 28 jours) ; encore utilis\u00e9 par AppDynamics, New Relic et quelques autres.<\/td>\n<\/tr>\n<tr>\n<td>Saturation<\/td>\n<td>Niveau d\u2019occupation d\u2019une ressource (CPU, m\u00e9moire, pool de connexions, profondeur de file d\u2019attente). Un des quatre signaux dor\u00e9s de Google.<\/td>\n<\/tr>\n<tr>\n<td>Utilisation CPU et m\u00e9moire<\/td>\n<td>Consommation de ressources par processus et par conteneur.<\/td>\n<\/tr>\n<tr>\n<td>M\u00e9triques de collecte des ordures<\/td>\n<td>Dur\u00e9e, fr\u00e9quence des pauses GC, taille du heap pour JVM, .NET, Go et Node.js.<\/td>\n<\/tr>\n<tr>\n<td>M\u00e9triques de requ\u00eates base de donn\u00e9es<\/td>\n<td>Latence des requ\u00eates, lignes examin\u00e9es, temps d\u2019attente de verrou, nombre de requ\u00eates lentes.<\/td>\n<\/tr>\n<tr>\n<td>Profondeur de file et retard consommateur<\/td>\n<td>Pour Kafka, RabbitMQ, SQS et syst\u00e8mes similaires. Le retard est un indicateur avanc\u00e9 de lenteur en cascade.<\/td>\n<\/tr>\n<tr>\n<td>Dur\u00e9e de d\u00e9marrage \u00e0 froid<\/td>\n<td>Sp\u00e9cifique au serverless (AWS Lambda, Azure Functions, Google Cloud Run).<\/td>\n<\/tr>\n<tr>\n<td>MTTD, MTTR, MTBF<\/td>\n<td>Mean Time To Detect (temps moyen de d\u00e9tection), Mean Time To Recovery (temps moyen de r\u00e9cup\u00e9ration), Mean Time Between Failures (temps moyen entre pannes). M\u00e9triques de sant\u00e9 op\u00e9rationnelle, suivies avec les m\u00e9triques applicatives.<\/td>\n<\/tr>\n<tr>\n<td>SLI \/ SLO \/ budget d\u2019erreur<\/td>\n<td>Indicateurs de niveau de service, objectifs fix\u00e9s, et budget consomm\u00e9 quand le SLI d\u00e9passe la cible.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p><strong>Comment capter ces m\u00e9triques sans instrumenter le code.<\/strong> Plusieurs m\u00e9triques cit\u00e9es ci-dessus peuvent \u00eatre mesur\u00e9es de l\u2019ext\u00e9rieur de l\u2019application sans agent ni SDK. Un contr\u00f4le synth\u00e9tique Dotcom-Monitor renvoie le temps de r\u00e9ponse avec des d\u00e9coupages p50, p95 et p99, le taux d\u2019erreur par code HTTP, le Time to First Byte (TTFB), le temps de r\u00e9solution DNS, la dur\u00e9e de la n\u00e9gociation TLS et la chronologie compl\u00e8te par requ\u00eate. Les donn\u00e9es sont conserv\u00e9es jusqu\u2019\u00e0 trois ans avec le plan Enterprise, suffisamment pour calculer des bases SLI annuelles sans exporter vers une base de s\u00e9ries temporelles distincte.<\/p>\n<p>Le livre Google SRE d\u00e9finit les quatre <strong>signaux dor\u00e9s<\/strong> comme la latence, le trafic, les erreurs et la saturation. La <strong>m\u00e9thode RED<\/strong> (Rate, Errors, Duration) et la <strong>m\u00e9thode USE<\/strong> (Utilization, Saturation, Errors) sont des cadres largement adopt\u00e9s regroupant ces m\u00e9triques dans des tableaux de bord exploitables.<\/p>\n<h2 id='avantages-de-l-apm'  id=\"boomdevs_10\" id=\"benefits-of-apm\">Avantages de l\u2019APM<\/h2>\n<h3 id='avantages-techniques-ing\u00e9nierie'  id=\"boomdevs_11\" id=\"technical-benefits-engineering\">Avantages techniques (ing\u00e9nierie)<\/h3>\n<ul>\n<li><strong>Analyse des causes racines plus rapide.<\/strong> Les traces distribu\u00e9es r\u00e9duisent les enqu\u00eates multiservices de plusieurs heures \u00e0 quelques minutes en exposant le span exact \u00e0 l\u2019origine d\u2019une latence ou erreur.<\/li>\n<li><strong>D\u00e9bogage s\u00fbr en production.<\/strong> Les profileurs continus et logs structur\u00e9s permettent de diagnostiquer les probl\u00e8mes en production sans attacher de d\u00e9bogueur.<\/li>\n<li><strong>D\u00e9tection de r\u00e9gression.<\/strong> Les baselines par d\u00e9ploiement signalent les r\u00e9gressions de performance avant leur propagation.<\/li>\n<li><strong>Entr\u00e9es pour la capacit\u00e9.<\/strong> Les m\u00e9triques de saturation et de d\u00e9bit alimentent les seuils de scaling automatique r\u00e9alistes et les d\u00e9cisions de dimensionnement.<\/li>\n<\/ul>\n<h3 id='avantages-op\u00e9rationnels-devops-sre-noc'  id=\"boomdevs_12\" id=\"operational-benefits-devops-sre-noc\">Avantages op\u00e9rationnels (DevOps, SRE, NOC)<\/h3>\n<ul>\n<li><strong>Application des SLO.<\/strong> Les donn\u00e9es APM alimentent les calculs de budget d\u2019erreur et bloquent les d\u00e9ploiements risqu\u00e9s.<\/li>\n<li><strong>R\u00e9duction de la fatigue li\u00e9e aux alertes.<\/strong> Une alerte symptomatique sur les signaux dor\u00e9s remplace les alertes bruit\u00e9es par seuil sur des h\u00f4tes individuels.<\/li>\n<li><strong>R\u00e9f\u00e9rence commune inter-\u00e9quipes.<\/strong> Une vue partag\u00e9e des traces met fin au d\u00e9bat \u201cest-ce le r\u00e9seau ou l\u2019application ?\u201d.<\/li>\n<li><strong>Chronologies d\u2019incident document\u00e9es.<\/strong> La r\u00e9tention des traces et logs fournit des preuves post-mortem sans rejouer les incidents.<\/li>\n<\/ul>\n<h3 id='avantages-m\u00e9tier'  id=\"boomdevs_13\" id=\"business-benefits\">Avantages m\u00e9tier<\/h3>\n<ul>\n<li><a href=\"https:\/\/www.dotcom-monitor.com\/blog\/fr\/quel-est-le-cout-des-temps-darret\/\">R\u00e9duction des pertes de revenus li\u00e9es aux interruptions<\/a><strong> et \u00e0 la latence.<\/strong> Le taux de conversion, l\u2019ach\u00e8vement du panier et la dur\u00e9e des sessions d\u00e9pendent directement de la latence p95.<\/li>\n<li><strong>D\u00e9penses cloud r\u00e9duites.<\/strong> L\u2019infrastructure bien dimensionn\u00e9e et les requ\u00eates inefficaces identifi\u00e9es r\u00e9duisent le gaspillage.<\/li>\n<li><strong>Preuves d\u2019audit et de conformit\u00e9.<\/strong> Les rapports SLA et les chronologies d\u2019incident soutiennent les exigences contractuelles et r\u00e9glementaires.<\/li>\n<\/ul>\n<h2 id='qui-utilise-l-apm-et-ce-qu-ils-recherchent'  id=\"boomdevs_14\" id=\"who-uses-apm-and-what-they-look-for\">Qui utilise l\u2019APM et ce qu\u2019ils recherchent<\/h2>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>R\u00f4le<\/th>\n<th>Utilisation principale de l\u2019APM<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Ing\u00e9nieurs DevOps<\/td>\n<td>Valider les d\u00e9ploiements, surveiller les releases pilot\u00e9es par pipeline CI\/CD, bloquer les promotions selon des crit\u00e8res de performance.<\/td>\n<\/tr>\n<tr>\n<td>Ing\u00e9nieurs fiabilit\u00e9 site (SRE)<\/td>\n<td>D\u00e9finir et appliquer les SLO, g\u00e9rer les budgets d\u2019erreur, g\u00e9rer la r\u00e9ponse aux incidents, construire des runbooks \u00e0 partir de motifs de traces.<\/td>\n<\/tr>\n<tr>\n<td>D\u00e9veloppeurs logiciels<\/td>\n<td>D\u00e9boguer latences et erreurs dans leur service, profiler les chemins chauds, valider les corrections en staging et en production.<\/td>\n<\/tr>\n<tr>\n<td>Ing\u00e9nieurs QA<\/td>\n<td>Comparer les bases de performance entre candidats \u00e0 la release, piloter les tests de charge et synth\u00e9tiques \u00e0 partir des donn\u00e9es APM, d\u00e9tecter les r\u00e9gressions avant mise en production.<\/td>\n<\/tr>\n<tr>\n<td>Administrateurs r\u00e9seau<\/td>\n<td>Distinguer les probl\u00e8mes r\u00e9seau des probl\u00e8mes applicatifs, surveiller le trafic service \u00e0 service, valider le comportement des pare-feux et load balancers.<\/td>\n<\/tr>\n<tr>\n<td>Ing\u00e9nieurs s\u00e9curit\u00e9<\/td>\n<td>D\u00e9tecter des anomalies pouvant indiquer un abus (volume d\u2019attaques par force brute, motifs d\u2019erreur inhabituels aux endpoints d\u2019authentification).<\/td>\n<\/tr>\n<tr>\n<td>Direction technique et produit<\/td>\n<td>Suivre les KPIs de fiabilit\u00e9, latence c\u00f4t\u00e9 utilisateur, et impact du travail sur la performance sur les m\u00e9triques m\u00e9tier.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h2 id='apm-et-s\u00e9curit\u00e9-d\u00e9tection-pas-pr\u00e9vention'  id=\"boomdevs_15\" id=\"apm-and-security-detection-not-prevention\">APM et s\u00e9curit\u00e9 : d\u00e9tection, pas pr\u00e9vention<\/h2>\n<p>L\u2019APM n\u2019est pas un outil de s\u00e9curit\u00e9, mais sa t\u00e9l\u00e9m\u00e9trie constitue un signal de s\u00e9curit\u00e9 utile. Les motifs qu\u2019APM peut r\u00e9v\u00e9ler :<\/p>\n<ul>\n<li>Pic soudain de trafic vers un endpoint sp\u00e9cifique (credential stuffing, scraping).<\/li>\n<li>Motifs d\u2019erreur inhabituels sur les endpoints d\u2019authentification ou de paiement.<\/li>\n<li>Appels sortants vers des destinations inattendues depuis des services compromis.<\/li>\n<li>Nouvelles d\u00e9pendances apparaissant dans les donn\u00e9es de trace apr\u00e8s un d\u00e9ploiement.<\/li>\n<\/ul>\n<p>L\u2019APM moderne s\u2019int\u00e8gre aux plateformes SIEM et SOAR (Splunk Enterprise Security, Microsoft Sentinel, Elastic Security, Datadog Cloud SIEM) en transmettant logs et traces annot\u00e9s. Certaines plateformes proposent aussi d\u00e9sormais des add-ons IAST (Interactive Application Security Testing) et RASP (runtime application self-protection) qui s\u2019appuient sur l\u2019agent APM (Contrast Security, Datadog Application and API Protection \u2014 anciennement Datadog ASM \u2014 et la capacit\u00e9 IAST de New Relic dans le cadre de la gestion des vuln\u00e9rabilit\u00e9s).<\/p>\n<p>L\u2019APM est une couche de d\u00e9tection. Il compl\u00e8te mais ne remplace pas un WAF, un scanner de vuln\u00e9rabilit\u00e9s ou un EDR.<\/p>\n<h2 id='apm-pour-charges-cloud-native-et-microservices'  id=\"boomdevs_16\" id=\"apm-for-cloud-native-and-microservices-workloads\">APM pour charges cloud-native et microservices<\/h2>\n<p>Les architectures cloud-native modifient quatre aspects de l\u2019APM :<\/p>\n<p><strong>Volume de donn\u00e9es.<\/strong> Un monolithe \u00e9met un ensemble de m\u00e9triques ; un d\u00e9ploiement microservices de cinquante services \u00e9met cinquante ensembles, multipli\u00e9s par les r\u00e9plicas, multipli\u00e9s par chaque span dans chaque trace. L\u2019\u00e9chantillonnage adaptatif (bas\u00e9 sur la t\u00eate, la queue ou probabiliste) est indispensable. Le processeur d\u2019\u00e9chantillonnage en queue de l\u2019OpenTelemetry Collector est la solution standard.<\/p>\n<p><strong>\u00c9ph\u00e9m\u00e9rit\u00e9.<\/strong> Les conteneurs et fonctions serverless vivent de quelques secondes \u00e0 quelques minutes. La surveillance traditionnelle bas\u00e9e sur l\u2019h\u00f4te perd le contexte au red\u00e9marrage d\u2019un pod. Les identifiants de niveau service (nom de service, namespace, d\u00e9ploiement) remplacent l\u2019identit\u00e9 h\u00f4te comme cl\u00e9 principale d\u2019agr\u00e9gation.<\/p>\n<p><a href=\"https:\/\/www.dotcom-monitor.com\/blog\/fr\/surveillance-des-systemes-distribues\/\">Complexit\u00e9 service \u00e0 service<\/a><strong>.<\/strong> Identifier la cause racine d\u2019un pic de latence n\u00e9cessite de parcourir un graphe de d\u00e9pendance impossible \u00e0 m\u00e9moriser humainement. Les cartes de service g\u00e9n\u00e9r\u00e9es \u00e0 partir des donn\u00e9es de trace (vue d\u00e9pendances dans Jaeger, graphe de service Grafana Tempo, Service Map Datadog) sont la r\u00e9ponse pratique.<\/p>\n<p><strong>Environnements d\u2019ex\u00e9cution h\u00e9t\u00e9rog\u00e8nes.<\/strong> Une requ\u00eate unique peut traverser un BFF Node.js, un service Go, un backend legacy Java, et une fonction serverless. La propagation du contexte de trace cross-langage d\u2019OpenTelemetry (en-t\u00eates W3C Trace Context) rend une seule trace possible \u00e0 travers ce chemin.<\/p>\n<p><strong>Comment valider chaque r\u00e9gion en dehors du datacenter.<\/strong> Les syst\u00e8mes distribu\u00e9s \u00e9chouent souvent r\u00e9gion par r\u00e9gion. Un mauvais routage d\u2019un n\u0153ud CDN, un retard de propagation DNS, ou un \u00e9chec de renouvellement de certificat r\u00e9gional peuvent laisser l\u2019application saine en datacenter mais inaccessible depuis S\u00e3o Paulo ou Singapour. Pour le d\u00e9tecter, ex\u00e9cutez le m\u00eame contr\u00f4le synth\u00e9tique depuis chaque r\u00e9gion d\u2019int\u00e9r\u00eat sur une liste de cibles distincte. Dans Dotcom-Monitor, affectez les emplacements de monitoring par liste dans la configuration, et le tableau de bord isole automatiquement les diff\u00e9rences r\u00e9gionales de latence et disponibilit\u00e9. Ce dispositif d\u00e9tecte les pannes r\u00e9gionales AWS, incidents Cloudflare et basculements de routes BGP avant que les outils internes ne les signalent.<\/p>\n<p>Les pr\u00e9occupations sp\u00e9cifiques \u00e0 Kubernetes m\u00e9ritent leur propre traitement : compte de red\u00e9marrages de pods comme indicateur avanc\u00e9, kube-state-metrics pour signaux au niveau cluster, r\u00e9activit\u00e9 de l\u2019Horizontal Pod Autoscaler, signaux de pression au niveau des n\u0153uds, tous ces \u00e9l\u00e9ments doivent figurer dans un tableau de bord APM cloud-native.<\/p>\n<h2 id='apm-pour-charges-ia-et-llm'  id=\"boomdevs_17\" id=\"apm-for-ai-and-llm-workloads\">APM pour charges IA et LLM<\/h2>\n<p>Les fonctionnalit\u00e9s bas\u00e9es sur LLM ont des modes de d\u00e9faillance nouveaux que les m\u00e9triques classiques ne capturent pas :<\/p>\n<ul>\n<li><strong>Time-to-first-token (TTFT)<\/strong> et <strong>latence inter-token<\/strong> comptent plus que la dur\u00e9e totale de la requ\u00eate pour les r\u00e9ponses en streaming.<\/li>\n<li><strong>Co\u00fbt en tokens par requ\u00eate<\/strong> est \u00e0 la fois m\u00e9trique m\u00e9tier et m\u00e9trique de capacit\u00e9.<\/li>\n<li><strong>Contenu prompt et compl\u00e9tion<\/strong> (\u00e9chantillonn\u00e9, censur\u00e9) est n\u00e9cessaire pour diagnostiquer hallucinions, tentatives d\u2019injection de prompt, et d\u00e9gradation de la qualit\u00e9 de sortie.<\/li>\n<li><strong>D\u00e9rive de mod\u00e8le<\/strong> (variation mesurable dans la distribution de sortie dans le temps) n\u00e9cessite une \u00e9valuation de sortie parall\u00e8lement \u00e0 la latence.<\/li>\n<li><strong>Traces d\u2019appels d\u2019outils et de r\u00e9cup\u00e9ration<\/strong> dans les workflows agentiques : spans pour requ\u00eates de magasins vectoriels, appels de fonctions et requ\u00eates API en aval.<\/li>\n<\/ul>\n<p>Les conventions s\u00e9mantiques GenAI d\u2019OpenTelemetry (introduites en 2024, toujours en statut D\u00e9veloppement en 2026) d\u00e9finissent des attributs standard pour les appels LLM (gen_ai.provider.name, gen_ai.request.model, gen_ai.usage.input_tokens, gen_ai.usage.output_tokens). Les outils d\u2019observabilit\u00e9 LLM sp\u00e9cifiques (Langfuse, Arize Phoenix, Helicone, LangSmith) coexistent avec les APM g\u00e9n\u00e9ralistes ayant ajout\u00e9 le support GenAI (Datadog LLM Observability, New Relic AI Monitoring, Dynatrace AI Observability).<\/p>\n<p><strong>Comment surveiller un endpoint LLM avec Dotcom-Monitor.<\/strong> Cr\u00e9ez un monitor WebView pointant vers l\u2019endpoint LLM, par ex. POST \/v1\/chat\/completions. Placez un prompt de test fixe dans le corps de la requ\u00eate et la cl\u00e9 API ou token bearer dans les en-t\u00eates. D\u00e9finissez trois assertions JSONPath : choices[0].message.content doit \u00eatre non vide, usage.total_tokens doit \u00eatre dans une plage raisonnable (pour d\u00e9tecter les bugs de tokens hors contr\u00f4le), et le temps de r\u00e9ponse doit rester sous votre budget TTFT. Cette configuration d\u00e9tecte \u00e9puisement de quota, r\u00e9ponses de mod\u00e8le d\u00e9pr\u00e9ci\u00e9 telles que \u201cmodel not found\u201d, pannes c\u00f4t\u00e9 fournisseur et limitations r\u00e9gionales de d\u00e9bit. Les outils internes d\u2019observabilit\u00e9 LLM comme Langfuse, Helicone et LangSmith ne voient pas ces pannes car ils observent uniquement ce que l\u2019application re\u00e7oit.<\/p>\n<h2 id='bonnes-pratiques-de-surveillance-des-performances-applicatives'  id=\"boomdevs_18\" id=\"application-performance-monitoring-best-practices\">Bonnes pratiques de surveillance des performances applicatives<\/h2>\n<ul>\n<li><strong>Instrumentez par d\u00e9faut avec OpenTelemetry.<\/strong> \u00c9vitez le verrouillage propri\u00e9taire. Si un agent fournisseur offre une fonctionnalit\u00e9 absente d\u2019OTel, superposez-la plut\u00f4t que de remplacer OTel.<\/li>\n<li><strong>D\u00e9finissez les SLO avant les tableaux de bord.<\/strong> D\u00e9cidez de ce que signifie \u201csain\u201d en termes visibles par l\u2019utilisateur, puis construisez tableaux et alertes pour le mesurer.<\/li>\n<li><strong>Alertez sur les sympt\u00f4mes, appelez sur consommation du budget d\u2019erreur.<\/strong> Les alertes seuil h\u00f4te g\u00e9n\u00e8rent du bruit. Les alertes qui se d\u00e9clenchent quand le budget d\u2019erreur d\u2019un SLO br\u00fble trop vite respectent la s\u00e9r\u00e9nit\u00e9 des astreintes.<\/li>\n<li><strong>Associez surveillance synth\u00e9tique et utilisateur r\u00e9el.<\/strong> Les contr\u00f4les synth\u00e9tiques d\u00e9tectent les pannes depuis des emplacements contr\u00f4l\u00e9s selon un calendrier connu. Le RUM mesure l\u2019exp\u00e9rience utilisateur r\u00e9elle, incluant r\u00e9seau en derni\u00e8re mile et variabilit\u00e9 des appareils. Aucun des deux ne remplace l\u2019autre.<\/li>\n<li><strong>Standardisez les noms de spans et m\u00e9triques.<\/strong> Utilisez les conventions s\u00e9mantiques OpenTelemetry. R\u00e9sistez \u00e0 la personnalisation par \u00e9quipe.<\/li>\n<li><strong>Corr\u00e9lez par ID de trace de bout en bout.<\/strong> Injectez le contexte de trace dans logs, messages de file et requ\u00eates base (par ex., sous forme de commentaires SQL via sqlcommenter). Un ID de trace dans chaque ligne de log est l\u2019investissement le plus rentable en observabilit\u00e9.<\/li>\n<li><strong>\u00c9chantillonnez intelligemment.<\/strong> \u00c9chantillonnage en t\u00eate \u00e0 1\u201310 % pour services \u00e0 haut volume ; \u00e9chantillonnage en queue pour conservation des traces lentes et en erreur. Conservez 100 % des traces en erreur.<\/li>\n<li><strong>Consid\u00e9rez le collecteur comme une infrastructure de production.<\/strong> Ex\u00e9cutez l\u2019OpenTelemetry Collector avec redondance, surveillance et marge de capacit\u00e9.<\/li>\n<li><strong>R\u00e9visez et ajustez trimestriellement.<\/strong> La cardinalit\u00e9 des m\u00e9triques, le volume de logs et la r\u00e9tention des traces augmentent sans \u00e9lagage actif. Pr\u00e9voyez du temps pour supprimer ce qui ne justifie plus son stockage.<\/li>\n<li><strong>Organisez des exercices gameday.<\/strong> Injectez p\u00e9riodiquement des pannes (Chaos Mesh, Gremlin, AWS Fault Injection Service) et v\u00e9rifiez que la pile APM les d\u00e9tecte. Une observabilit\u00e9 non test\u00e9e est une observabilit\u00e9 non valid\u00e9e.<\/li>\n<\/ul>\n<h2 id='glossaire-apm'  id=\"boomdevs_19\" id=\"apm-glossary\">Glossaire APM<\/h2>\n<p><strong>Agent.<\/strong> Logiciel install\u00e9 \u00e0 c\u00f4t\u00e9 de l\u2019application qui auto-instrumente les appels d\u2019ex\u00e9cution et envoie la t\u00e9l\u00e9m\u00e9trie.<\/p>\n<p><strong>Apdex.<\/strong> Indice de performance applicative. Score de satisfaction de 0 \u00e0 1 d\u00e9riv\u00e9 d\u2019un seuil de latence.<\/p>\n<p><strong>Cardinalit\u00e9.<\/strong> Nombre de combinaisons uniques d\u2019\u00e9tiquettes ou attributs sur une m\u00e9trique. Une cardinalit\u00e9 \u00e9lev\u00e9e est co\u00fbteuse \u00e0 stocker et interroger.<\/p>\n<p><strong>Traces distribu\u00e9es.<\/strong> Pratique consistant \u00e0 suivre une requ\u00eate unique \u00e0 travers plusieurs services via la propagation d\u2019un ID de trace.<\/p>\n<p><strong>Budget d\u2019erreur.<\/strong> Quantit\u00e9 d\u2019indisponibilit\u00e9 tol\u00e9r\u00e9e par un SLO sur une fen\u00eatre, consomm\u00e9e par les incidents.<\/p>\n<p><strong>Exemplar.<\/strong> Un ID de trace sp\u00e9cifique attach\u00e9 \u00e0 un point de donn\u00e9es m\u00e9trique, utilis\u00e9 pour passer d\u2019une anomalie m\u00e9trique \u00e0 une trace repr\u00e9sentative.<\/p>\n<p><strong>Signaux dor\u00e9s.<\/strong> Latence, trafic, erreurs, saturation. Les quatre m\u00e9triques essentielles \u00e0 exposer pour tout service.<\/p>\n<p><strong>Instrumentation.<\/strong> Code ou configuration produisant de la t\u00e9l\u00e9m\u00e9trie \u00e0 partir d\u2019une application en fonctionnement.<\/p>\n<p><strong>OpenTelemetry (OTel).<\/strong> Cadre d\u2019observabilit\u00e9 CNCF. D\u00e9finit APIs, SDK, protocole OTLP et conventions s\u00e9mantiques.<\/p>\n<p><strong>OTLP.<\/strong> OpenTelemetry Protocol. Format filaire pour l\u2019envoi des traces, m\u00e9triques et logs.<\/p>\n<p><strong>M\u00e9thode RED.<\/strong> Rate, Errors, Duration. Cadre m\u00e9trique au niveau service.<\/p>\n<p><strong>Real User Monitoring (RUM).<\/strong> Donn\u00e9es de performance captur\u00e9es dans le navigateur ou l\u2019appareil de l\u2019utilisateur.<\/p>\n<p><strong>SLI \/ SLO \/ SLA.<\/strong> Indicateur de niveau de service (mesure), Objectif de niveau de service (cible interne), Accord de niveau de service (engagement contractuel).<\/p>\n<p><strong>Span.<\/strong> Une op\u00e9ration unique dans une trace, avec heure de d\u00e9but, dur\u00e9e et attributs.<\/p>\n<p><a href=\"https:\/\/www.dotcom-monitor.com\/blog\/fr\/what-is-synthetic-monitoring\/\">Surveillance synth\u00e9tique<\/a><strong>.<\/strong> Contr\u00f4les p\u00e9riodiques script\u00e9s simulant le comportement utilisateur depuis des emplacements contr\u00f4l\u00e9s.<\/p>\n<p><strong>\u00c9chantillonnage en queue.<\/strong> \u00c9chantillonnage des traces apr\u00e8s leur fin en fonction de propri\u00e9t\u00e9s comme le statut d\u2019erreur ou dur\u00e9e.<\/p>\n<p><strong>T\u00e9l\u00e9m\u00e9trie.<\/strong> Donn\u00e9es \u00e9mises par un syst\u00e8me \u00e0 propos de lui-m\u00eame. En APM, cela signifie m\u00e9triques, traces, logs, profils et \u00e9v\u00e9nements.<\/p>\n<p><strong>Contexte de trace.<\/strong> M\u00e9tadonn\u00e9es transmises entre services pour lier des spans en une unique trace. Normalis\u00e9 par W3C Trace Context.<\/p>\n<p><strong>M\u00e9thode USE.<\/strong> Utilisation, Saturation, Erreurs. Cadre m\u00e9trique au niveau ressource.<\/p>\n<section class=\"final-cta\">\n<h2 id='o\u00f9-aller-\u00e0-partir-d-ici'  id=\"boomdevs_20\" id=\"where-to-go-from-here\">O\u00f9 aller \u00e0 partir d\u2019ici<\/h2>\n<p>Pour une vue externe des performances et de la disponibilit\u00e9 c\u00f4t\u00e9 utilisateur, ex\u00e9cutez des contr\u00f4les synth\u00e9tiques et navigateurs r\u00e9els contre vos endpoints de production depuis plusieurs g\u00e9ographies. <a href=\"https:\/\/www.dotcom-monitor.com\/\">Dotcom-Monitor<\/a> fournit cette couche : transactions navigateurs script\u00e9es, <a href=\"https:\/\/www.dotcom-monitor.com\/fr\/produits-de-surveillance\/surveillance-api\/\">surveillance API<\/a> et rapports SLA depuis un r\u00e9seau global de monitoring, con\u00e7us pour compl\u00e9ter une pile APM interne plut\u00f4t que la remplacer. Pour l\u2019APM interne, commencez par l\u2019instrumentation OpenTelemetry dans un service critique, envoyez les traces \u00e0 un backend (Jaeger, Tempo ou une plateforme commerciale), d\u00e9finissez un unique SLO, puis \u00e9tendez progressivement.<\/p>\n<div class=\"cta-row\" style=\"justify-content: center\"><a class=\"tool-cta\" href=\"https:\/\/userauth.dotcom-monitor.com\/Account\/FreeTrialSignUp?SolutionType=Monitoring\">Commencez votre essai gratuit \u2192<\/a><\/div>\n<\/section>\n","protected":false},"excerpt":{"rendered":"<p>Ce qu&#8217;est la surveillance des performances des applications (APM), comment fonctionnent l&#8217;instrumentation, la collecte et la corr\u00e9lation, quelles m\u00e9triques sont importantes, et les meilleures pratiques qui rendent l&#8217;APM utile en production<\/p>\n","protected":false},"author":39,"featured_media":34100,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-34149","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/34149","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/users\/39"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/comments?post=34149"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/34149\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/media\/34100"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/media?parent=34149"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/categories?post=34149"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/tags?post=34149"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}