{"id":13331,"date":"2021-04-01T15:00:51","date_gmt":"2021-04-01T15:00:51","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/2021\/04\/01\/applications-internes-surveillance-derriere-votre-pare-feu\/"},"modified":"2026-08-26T22:26:34","modified_gmt":"2026-08-26T22:26:34","slug":"applications-internes-surveillance-derriere-votre-pare-feu","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/applications-internes-surveillance-derriere-votre-pare-feu\/","title":{"rendered":"Comment surveiller les applications internes derri\u00e8re votre pare-feu"},"content":{"rendered":"
\"\u00c9quipe
Les applications internes vivent sur des adresses priv\u00e9es que l’internet public ne peut pas atteindre\u2014la surveillance doit donc s\u2019effectuer depuis l\u2019int\u00e9rieur.<\/figcaption><\/figure>\n

Votre tableau de bord de surveillance affiche tout en vert, et pourtant la moiti\u00e9 de l’entreprise ne peut toujours pas ouvrir le syst\u00e8me ERP. C\u2019est le point aveugle de la surveillance externe : les v\u00e9rifications s\u2019ex\u00e9cutent depuis l\u2019internet public, tandis que votre CRM, portail RH, intranet et help desk sont h\u00e9berg\u00e9s sur des adresses priv\u00e9es inaccessibles depuis Internet. Lorsqu\u2019un de ces services tombe en panne, le tableau de bord reste muet. La file d\u2019attente du help desk en dit long.<\/p>\n

La solution n\u2019est pas d\u2019utiliser un second outil ni de cr\u00e9er une batterie de scripts maison. C\u2019est d\u2019ex\u00e9cuter la m\u00eame surveillance synth\u00e9tique<\/a> que vous utilisez d\u00e9j\u00e0 pour vos sites publics, mais depuis l\u2019int\u00e9rieur de votre r\u00e9seau, via un agent priv\u00e9 situ\u00e9 derri\u00e8re le pare-feu qui remonte les r\u00e9sultats. L\u2019agent est la partie facile ; la d\u00e9cision la plus difficile est de choisir l\u2019exp\u00e9rience utilisateur qu\u2019il doit repr\u00e9senter\u2014le si\u00e8ge, une succursale, les utilisateurs VPN\u2014car la surveillance interne \u00e9choue d\u00e8s que vous consid\u00e9rez l\u2019int\u00e9rieur du pare-feu comme un seul endroit. Ce guide explique comment cette architecture fonctionne, puis d\u00e9taille six \u00e9tapes num\u00e9rot\u00e9es pour surveiller les applications internes de bout en bout : inventaire, d\u00e9ploiement de l’agent, contr\u00f4les synth\u00e9tiques, contr\u00f4les r\u00e9seau, contr\u00f4les de d\u00e9pendances et alertes.<\/p>\n

Pourquoi la surveillance externe ne peut pas atteindre les applications internes<\/h2>\n

Les n\u0153uds de surveillance publics peuvent tester tout ce qui poss\u00e8de une adresse publique. Les applications internes n\u2019en ont pas. Elles se r\u00e9solvent via un DNS interne, r\u00e9sident dans un espace d\u2019adresses priv\u00e9es, et sont souvent accessibles uniquement via un VPN. Pointer un contr\u00f4le externe vers votre intranet renverra au mieux un d\u00e9lai de connexion d\u00e9pass\u00e9 ; l\u2019\u00e9chec n\u2019est pas d\u00fb \u00e0 une panne de l\u2019application mais \u00e0 un mauvais point de vue.<\/p>\n

Ainsi, la plupart des \u00e9quipes retombent sur les deux pires strat\u00e9gies de surveillance : attendre les plaintes ou demander \u00e0 un administrateur syst\u00e8me de pinger depuis un poste de travail quand quelque chose semble anormal. Aucune de ces m\u00e9thodes ne fournit de bases de r\u00e9f\u00e9rence, d\u2019alertes, d\u2019historique de temps de r\u00e9ponse ni de preuves. Or les syst\u00e8mes internes impliquent de r\u00e9elles obligations\u2014les \u00e9quipes IT signent des SLA internes et des accords op\u00e9rationnels pour ces applications, et un SLA que vous ne pouvez pas mesurer est un SLA que vous ne pouvez pas prouver<\/a>.<\/p>\n

Les enjeux sont les m\u00eames que pour n\u2019importe quel site destin\u00e9 au client, juste tourn\u00e9s vers l\u2019int\u00e9rieur. Une panne ERP bloque le traitement des commandes. Un portail help desk en panne coupe l\u2019\u00e9quipe qui r\u00e9pare tout le reste. Un portail paie qui \u00e9choue le jour de la deadline est un \u00e9v\u00e9nement d’entreprise. Ces syst\u00e8mes m\u00e9ritent les m\u00eames contr\u00f4les continus qu\u2019une page de revenus.<\/p>\n

Comment fonctionne un agent de surveillance priv\u00e9<\/h2>\n

Un agent priv\u00e9 est un logiciel de surveillance que vous installez sur un h\u00f4te \u00e0 l\u2019int\u00e9rieur de votre r\u00e9seau. Il ex\u00e9cute les m\u00eames types de contr\u00f4les qu\u2019un n\u0153ud de surveillance public\u2014requ\u00eates HTTP(S), flux de navigateur script\u00e9s, appels API, sondes r\u00e9seau\u2014mais depuis l\u2019endroit o\u00f9 vos employ\u00e9s travaillent r\u00e9ellement, contre des adresses visibles seulement sur votre r\u00e9seau.<\/p>\n

\"Diagramme
L\u2019agent contr\u00f4le les applications internes localement et pousse les r\u00e9sultats vers l\u2019ext\u00e9rieur\u2014aucun trou entrant dans le pare-feu requis.<\/figcaption><\/figure>\n

Cette architecture est importante car elle \u00e9vite certaines exigences. Les agents priv\u00e9s suivent un mod\u00e8le de connexion uniquement sortant : l\u2019agent initie des connexions chiffr\u00e9es sortantes vers la plateforme de surveillance pour r\u00e9cup\u00e9rer sa liste de t\u00e2ches et envoyer les r\u00e9sultats\u2014c\u2019est le m\u00eame sens de trafic que celui autoris\u00e9 par votre pare-feu pour toute station de travail naviguant sur le web. Pour le pare-feu, il s\u2019agit g\u00e9n\u00e9ralement de permettre uniquement le trafic sortant vers les points de terminaison de la plateforme. Vous n\u2019ouvrez pas de ports entrants, vous ne publiez pas un h\u00f4te interne sur Internet, et vous ne percez pas de trous dans le p\u00e9rim\u00e8tre. Dans les environnements tr\u00e8s s\u00e9curis\u00e9s, trois aspects ennuyeux posent plus souvent probl\u00e8me que l\u2019architecture elle-m\u00eame : l\u2019authentification proxy, l\u2019inspection TLS et la confiance des certificats, et la fa\u00e7on dont l\u2019agent r\u00e9sout le DNS interne par rapport aux employ\u00e9s. V\u00e9rifiez ces trois points avant d\u2019incriminer autre chose. Vos applications, vos identifiants et vos cibles de test restent \u00e0 l\u2019int\u00e9rieur ; seules les donn\u00e9es de surveillance sortent.<\/p>\n

Les agents priv\u00e9s Dotcom-Monitor<\/a> appliquent ce mod\u00e8le \u00e0 toute la plateforme : les m\u00eames contr\u00f4les synth\u00e9tiques, flux utilisateurs script\u00e9s, et alertes que vous ex\u00e9cuteriez depuis son r\u00e9seau global, r\u00e9alis\u00e9s depuis l\u2019int\u00e9rieur de votre pare-feu, avec des r\u00e9sultats dans le m\u00eame tableau de bord que votre surveillance publique. Une seule interface couvre les deux c\u00f4t\u00e9s du p\u00e9rim\u00e8tre.<\/p>\n

Comment surveiller les applications internes en six \u00e9tapes<\/h2>\n

Avec l\u2019architecture claire, voici le processus. Chaque \u00e9tape s\u2019appuie sur la pr\u00e9c\u00e9dente, et vous pouvez vous arr\u00eater au niveau de d\u00e9tail justifi\u00e9 par votre environnement.<\/p>\n

\u00c9tape 1 : Inventorier et prioriser vos applications internes<\/h3>\n

Dressez la liste de ce qui est r\u00e9ellement utilis\u00e9 : ERP, CRM, portails comptabilit\u00e9 et paie, syst\u00e8mes RH, help desk, outils de collaboration et messagerie, partages de fichiers, et API internes qui les connectent. Ne vous arr\u00eatez pas \u00e0 la CMDB : recoupez avec l\u2019historique des tickets, les journaux de lancement d\u2019application SSO et les fils de discussion r\u00e9currents \u00ab est-ce que c\u2019est en panne \u00bb, car ceux-ci r\u00e9v\u00e8lent les d\u00e9pendances r\u00e9elles plut\u00f4t que ce qui a \u00e9t\u00e9 document\u00e9. Un raccourci fonctionne tout le temps : demandez aux ing\u00e9nieurs seniors quelles pannes leur feraient annuler leurs vacances. Classez ensuite la liste selon le rayon d\u2019impact. Qu\u2019est-ce qui paralyse toute l\u2019entreprise en cas de panne ? Qu\u2019est-ce qui immobilise un d\u00e9partement ? Qu\u2019est-ce qui peut attendre jusqu\u2019au matin ?<\/p>\n

Tout ne n\u00e9cessite pas une surveillance continue. Le help desk IT par lequel passent toutes les autres pannes m\u00e9rite une surveillance 24\/7 ; un portail de reporting utilis\u00e9 uniquement en fin de trimestre non. Affectez \u00e0 chaque niveau une fr\u00e9quence de contr\u00f4le et un objectif de disponibilit\u00e9, et consignez ces objectifs \u2014 ils deviendront les SLA internes que votre surveillance confirmera ou infirmera par la suite.<\/p>\n

\u00c9tape 2 : D\u00e9ployez un agent priv\u00e9 l\u00e0 o\u00f9 vos utilisateurs se trouvent<\/h3>\n

Installez l\u2019agent sur un h\u00f4te d\u00e9di\u00e9 et s\u00e9curis\u00e9 \u00e0 l\u2019int\u00e9rieur de votre r\u00e9seau\u2014une VM stable ou un conteneur \u00e0 longue dur\u00e9e, pas une machine mutualis\u00e9e qui red\u00e9marre sans pr\u00e9avis\u2014confirmez son chemin sortant vers la plateforme de surveillance, et dirigez vos premiers contr\u00f4les vers la liste de niveau un. Cela couvre le si\u00e8ge. Pas tout le monde.<\/p>\n

Placez les agents selon le domaine de panne, pas l\u2019organigramme : un proche des utilisateurs mesure l\u2019exp\u00e9rience employ\u00e9s, un proche de la couche applicative mesure la sant\u00e9 de l\u2019application, un derri\u00e8re le VPN mesure l\u2019acc\u00e8s distant, et quand les trois divergent, cette divergence est le diagnostic. Si vous avez des succursales ou des sites r\u00e9gionaux, d\u00e9ployez un agent dans chacun. Une application qui r\u00e9pond instantan\u00e9ment au si\u00e8ge peut \u00eatre tr\u00e8s lente pour une succursale situ\u00e9e \u00e0 l\u2019autre bout d\u2019un lien WAN ou VPN satur\u00e9, et aucun point de vue unique ne r\u00e9v\u00e9lera cela. Un agent par site transforme le \u00ab c\u2019est toujours lent dans le bureau de Denver \u00bb d\u2019une simple anecdote en un graphique par emplacement que vous pouvez exploiter. Traitez les h\u00f4tes des agents comme une infrastructure de production : maintenez-les \u00e0 jour, aliment\u00e9s et exclus des politiques agressives de nettoyage de bureau.<\/p>\n

\u00c9tape 3 : Lancez des contr\u00f4les synth\u00e9tiques sur les flux utilisateurs critiques<\/h3>\n

Un ping indiquant que la page de connexion se charge ne vous dit presque rien sur la capacit\u00e9 d\u2019un employ\u00e9 \u00e0 faire son travail. Les contr\u00f4les synth\u00e9tiques doivent simuler les flux que les utilisateurs ex\u00e9cutent r\u00e9ellement : connexion, ouverture d\u2019un enregistrement, recherche, soumission d\u2019une transaction, confirmation du r\u00e9sultat. Script\u00e9 avec un outil comme EveryStep<\/a>, le flux se rejoue selon un calendrier depuis votre agent priv\u00e9, chaque \u00e9tape ayant son propre temps de r\u00e9ponse. Concevez ces scripts pour qu\u2019ils fonctionnent en continu : une identit\u00e9 de test d\u00e9di\u00e9e, une MFA g\u00e9r\u00e9e explicitement au lieu d\u2019\u00eatre laiss\u00e9e \u00e0 la d\u00e9rive, des enregistrements de test sem\u00e9s, et aucune transaction g\u00e9n\u00e9rant une charge de nettoyage pour quelqu\u2019un d\u2019autre.<\/p>\n

Le timing par \u00e9tape cache toute la valeur. Quand le flux se d\u00e9grade, vous n\u2019apprenez pas seulement que l\u2019application est lente\u2014vous voyez que l\u2019\u00e9tape recherche est pass\u00e9e de deux secondes \u00e0 douze tandis que la connexion reste stable, ce qui pointe vers la base de donn\u00e9es avant m\u00eame qu\u2019un ticket ne soit ouvert. \u00c9tablissez des bases de r\u00e9f\u00e9rence lorsque tout fonctionne bien, et alertez sur les \u00e9carts, pas uniquement sur les \u00e9checs. Cette m\u00eame m\u00e9thode couvre les plateformes internes lourdes\u2014les d\u00e9ploiements SharePoint<\/a> et SAP ERP<\/a> en sont des candidats classiques. La fr\u00e9quence d\u2019ex\u00e9cution de chaque flux est une d\u00e9cision qui lui est propre ; les compromis sont couverts dans ce guide sur la fr\u00e9quence et les lieux de surveillance synth\u00e9tique<\/a>.<\/p>\n

\u00c9tape 4 : Ajoutez des contr\u00f4les r\u00e9seau et d\u2019infrastructure<\/h3>\n

Les applications internes ne tombent que rarement seules en panne\u2014souvent c\u2019est le r\u00e9seau qui les sous-tend. Un DNS interne lent fait ressentir toutes les applications comme en panne simultan\u00e9ment. Un lien satur\u00e9 entre segments ajoute une latence qui ressemble \u00e0 un souci applicatif. Une perte de paquets sur un tunnel VPN transforme la journ\u00e9e d\u2019un bureau distant en diaporama.<\/p>\n

Depuis le m\u00eame agent priv\u00e9, ex\u00e9cutez des contr\u00f4les d\u2019infrastructure<\/a> en dessous de la couche applicative : sondes ICMP et TCP contre des h\u00f4tes cl\u00e9s, contr\u00f4les DNS sur vos serveurs r\u00e9solveurs internes, et mesures de latence entre segments r\u00e9seau et bureaux. Surveillez la bande passante disponible autour des pics connus. Un contr\u00f4le discret apporte une vraie valeur : le temps de r\u00e9ponse des requ\u00eates sur vos contr\u00f4leurs de domaine, car quand Active Directory ou LDAP ralentit, toutes les applications int\u00e9gr\u00e9es paraissent en panne tandis que leurs propres m\u00e9triques restent vertes. Lorsqu\u2019un contr\u00f4le applicatif et un contr\u00f4le r\u00e9seau \u00e9chouent simultan\u00e9ment, c\u2019est le diagnostic lui-m\u00eame\u2014vous savez en un cycle s\u2019il faut alerter l\u2019\u00e9quipe applicative ou l\u2019\u00e9quipe r\u00e9seau.<\/p>\n

\u00c9tape 5 : V\u00e9rifiez les d\u00e9pendances tierces depuis l\u2019int\u00e9rieur du pare-feu<\/h3>\n

Les applications internes d\u00e9pendent silencieusement de services externes : fournisseur d\u2019identit\u00e9 derri\u00e8re le single sign-on, processeurs de paiements, serveurs de licences, API fournisseurs. Les pages de statut fournisseurs mentent par omission : elles confirment que le c\u00f4t\u00e9 fournisseur est op\u00e9rationnel. Elles ne disent rien sur la capacit\u00e9 de votre<\/em> r\u00e9seau \u00e0 les atteindre\u2014via votre proxy, vos r\u00e8gles de pare-feu, votre DNS. Une r\u00e8gle de sortie p\u00e9rim\u00e9e peut faire tomber une int\u00e9gration tandis que toutes les pages de statut sur Internet restent au vert. Pour les d\u00e9pendances importantes, lancez des contr\u00f4les jumeaux depuis l\u2019internet public et depuis votre chemin normal de sortie : lorsqu\u2019il y a succ\u00e8s public mais \u00e9chec priv\u00e9, c\u2019est un probl\u00e8me de sortie ou DNS, et lorsqu\u2019ils \u00e9chouent tous deux, c\u2019est un probl\u00e8me c\u00f4t\u00e9 fournisseur.<\/p>\n

Ainsi, ex\u00e9cutez des contr\u00f4les d\u2019API<\/a> sur ces d\u00e9pendances depuis l\u2019int\u00e9rieur du pare-feu, en parall\u00e8le de contr\u00f4les de sant\u00e9 sur vos propres fonctions principales. Pour un syst\u00e8me de facturation interne, cela signifie tester planifi\u00e9 la connexion, la r\u00e9cup\u00e9ration de donn\u00e9es et le traitement des transactions\u2014les fonctions dont la panne sera signal\u00e9e dans l\u2019heure, mais d\u00e9tect\u00e9e en quelques minutes.<\/p>\n

\u00c9tape 6 : Automatisez les alertes et les r\u00e9ponses<\/h3>\n

La d\u00e9tection ne sert \u00e0 rien si la bonne personne n\u2019en est pas inform\u00e9e. Routez les alertes<\/a> de chaque application vers l\u2019\u00e9quipe qui la g\u00e8re, pas vers une bo\u00eete mail partag\u00e9e. Alertez autant sur des seuils de d\u00e9gradation que sur des pannes nettes, afin que la recherche \u00e0 douze secondes attire l\u2019attention avant de devenir une panne. Soyez r\u00e9aliste aussi sur la gravit\u00e9 : un portail de reporting interne qui \u00e9choue \u00e0 3h du matin n\u2019est pas une urgence r\u00e9veil, car l’enjeu est de prot\u00e9ger la productivit\u00e9 en heures ouvrables, pas de viser du cinq-neuf. Ajustez les politiques hors heures pour pr\u00e9server le sommeil de vos \u00e9quipes. Ajoutez une escalade pour les incidents non reconnus, et poussez les alertes dans les canaux d\u00e9j\u00e0 consult\u00e9s par vos \u00e9quipes\u2014chat, ticketing, outils d\u2019astreinte.<\/p>\n

Puis automatisez les r\u00e9solutions de routine. Si un service connu pour \u00eatre instable peut \u00eatre red\u00e9marr\u00e9 en toute s\u00e9curit\u00e9 quand l\u2019usage ressources d\u00e9passe un seuil, script ez cela et laissez l\u2019alerte d\u00e9clencher la r\u00e9paration ; gardez les humains pour les pannes n\u00e9cessitant du jugement. Et prot\u00e9gez-vous contre les faux positifs\u2014un \u00e9chec isol\u00e9 d\u2019un contr\u00f4le par un agent est une donn\u00e9e qui m\u00e9rite confirmation avant de r\u00e9veiller quelqu\u2019un. Les bonnes pratiques d\u2019ajustement d\u2019alertes sont trait\u00e9es dans notre guide sur les alertes de surveillance de site web<\/a>.<\/p>\n

Surveillance externe vs surveillance par agent priv\u00e9<\/h2>\n

Les deux approches ne sont pas rivales ; elles couvrent les c\u00f4t\u00e9s oppos\u00e9s du pare-feu, et la plupart des organisations ont besoin des deux.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n
Facteur<\/th>\nSurveillance externe<\/th>\nSurveillance par agent priv\u00e9<\/th>\n<\/tr>\n<\/thead>\n
Point de vue<\/td>\nInternet public, sites globaux<\/td>\n\u00c0 l\u2019int\u00e9rieur de votre r\u00e9seau, l\u00e0 o\u00f9 sont les employ\u00e9s<\/td>\n<\/tr>\n
Peut atteindre des adresses priv\u00e9es<\/td>\nNon<\/td>\nOui<\/td>\n<\/tr>\n
Modifications pare-feu<\/td>\nAucune (cibles publiques)<\/td>\nAutorisation sortante uniquement ; pas de ports entrants<\/td>\n<\/tr>\n
Ce que \u00e7a valide<\/td>\nDisponibilit\u00e9 et performance cot\u00e9 client<\/td>\nExp\u00e9rience employ\u00e9s des syst\u00e8mes internes<\/td>\n<\/tr>\n
O\u00f9 se trouvent les cibles sensibles<\/td>\nExpos\u00e9es aux contr\u00f4les publics par conception<\/td>\nRestent \u00e0 l\u2019int\u00e9rieur ; seuls les r\u00e9sultats sortent du r\u00e9seau<\/td>\n<\/tr>\n
Id\u00e9al pour<\/td>\nSites web, API publiques, frontaux SaaS<\/td>\nERP, CRM, intranets, API internes, connectivit\u00e9 succursale<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

La question d\u00e9cisive est le point de vue : mesurez les syst\u00e8mes orient\u00e9s client depuis le lieu o\u00f9 se trouvent les clients, et les syst\u00e8mes internes depuis l\u00e0 o\u00f9 se trouvent les employ\u00e9s. Une plateforme qui fait les deux garde les deux vues dans un m\u00eame tableau de bord au lieu de deux outils.<\/p><\/blockquote>\n

En conclusion<\/h2>\n

Les applications internes tombent en panne comme les applications publiques, mais elles \u00e9chouent dans l’ombre : les contr\u00f4les externes ne peuvent pas les atteindre, donc la premi\u00e8re alerte est g\u00e9n\u00e9ralement humaine. Un agent priv\u00e9 comble ce foss\u00e9 avec une architecture seulement sortante ne n\u00e9cessitant aucun changement entrant au pare-feu, et les six \u00e9tapes ci-dessus en font une pratique op\u00e9rationnelle\u2014inventoriez et classez vos apps, d\u00e9ployez les agents l\u00e0 o\u00f9 sont les utilisateurs, script ez les flux qui comptent, surveillez le r\u00e9seau en dessous, v\u00e9rifiez les d\u00e9pendances tierces depuis l\u2019int\u00e9rieur, et orientez les alertes vers les responsables avec automatisation des corrections de routine.<\/p>\n

Commencez avec un agent et vos cinq syst\u00e8mes internes les plus critiques. En une semaine, vous aurez des bases de r\u00e9f\u00e9rence que personne dans votre organisation n\u2019a jamais vues, et le prochain incident ERP sera un ticket ouvert par votre \u00e9quipe\u2014pas par vos utilisateurs.<\/p>\n

\n

Surveillez ce que l\u2019Internet ne peut pas voir<\/h2>\n

Effectuez une surveillance synth\u00e9tique en vrai navigateur<\/a> sur vos applications internes avec Dotcom-Monitor Private Agents<\/a>\u2014m\u00eame plateforme, m\u00eame tableau de bord, \u00e0 l\u2019int\u00e9rieur de votre pare-feu. Commencez un essai gratuit<\/a>.<\/p>\n<\/section>\n","protected":false},"excerpt":{"rendered":"

Surveillez les applications internes derri\u00e8re votre pare-feu : architecture d’agent priv\u00e9, contr\u00f4les synth\u00e9tiques et r\u00e9seau, v\u00e9rifications de sant\u00e9 et configuration des alertes.<\/p>\n","protected":false},"author":21,"featured_media":34446,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3446],"tags":[],"class_list":["post-13331","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-non-classifiee"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/13331","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\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/comments?post=13331"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/13331\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/media\/34446"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/media?parent=13331"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/categories?post=13331"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/tags?post=13331"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}