{"id":31024,"date":"2025-11-08T21:38:07","date_gmt":"2025-11-08T21:38:07","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/salesforce-api-monitoring-synthetic\/"},"modified":"2026-05-22T05:18:33","modified_gmt":"2026-05-22T05:18:33","slug":"salesforce-api-monitoring-synthetic","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/salesforce-api-monitoring-synthetic\/","title":{"rendered":"Surveillance des API Salesforce : tests synth\u00e9tiques qui d\u00e9tectent les d\u00e9faillances"},"content":{"rendered":"

\"SalesforceLes API de Salesforce op\u00e8rent discr\u00e8tement derri\u00e8re d’innombrables interactions clients. Elles relient les CRM \u00e0 la facturation, synchronisent les leads avec le marketing et alimentent les tableaux de bord dont les dirigeants d\u00e9pendent au quotidien. Pourtant, lorsqu’une de ces API ralentit ou tombe en panne, cela se produit souvent sans alerte. Les tableaux de bord continuent de s’afficher, les int\u00e9grations continuent d’essayer de renvoyer les op\u00e9rations, et quelque part les donn\u00e9es cessent de circuler en silence. C’est le danger d’une d\u00e9faillance d’API invisible \u2014 quand quelqu’un s’en aper\u00e7oit, les d\u00e9g\u00e2ts sont d\u00e9j\u00e0 faits.<\/p>\n

La surveillance synth\u00e9tique comble cette lacune. En ex\u00e9cutant des appels d’API script\u00e9s qui se comportent comme de v\u00e9ritables int\u00e9grations, elle d\u00e9tecte la latence, les d\u00e9rives d’authentification et les erreurs de donn\u00e9es avant que les utilisateurs ou partenaires n’en subissent les cons\u00e9quences. Pour les organisations qui s’appuient sur l’\u00e9cosyst\u00e8me connect\u00e9 de Salesforce, la surveillance synth\u00e9tique n’est pas seulement une pr\u00e9caution \u2014 c’est de la visibilit\u00e9 op\u00e9rationnelle.<\/p>\n

Pourquoi les API Salesforce \u00e9chouent sans bruit<\/h2>\n

Les int\u00e9grations Salesforce sont construites en couches : applications connect\u00e9es, tokens d’authentification, middleware et automatisations en arri\u00e8re-plan. Chacune de ces couches peut flancher sans pour autant mettre l’ensemble du syst\u00e8me hors service. Une synchronisation nocturne qui indique \u00ab succ\u00e8s \u00bb peut avoir saut\u00e9 la moiti\u00e9 des enregistrements parce qu’un token d’acc\u00e8s a expir\u00e9 en cours d’ex\u00e9cution. Un webhook peut poster des r\u00e9ponses avec des payloads vides. Des limites de taux peuvent bride certains utilisateurs tandis que d’autres semblent fonctionner correctement.<\/p>\n

Ces d\u00e9faillances sont subtiles par conception. Salesforce est une plateforme distribu\u00e9e et multi-tenant optimis\u00e9e pour la stabilit\u00e9, pas pour exposer la sant\u00e9 des int\u00e9grations dans votre environnement. C’est pourquoi des probl\u00e8mes peuvent persister pendant des heures ou des jours avant d’\u00eatre remarqu\u00e9s. La surveillance synth\u00e9tique force ces probl\u00e8mes \u00e0 \u00e9merger t\u00f4t en ex\u00e9cutant les m\u00eames op\u00e9rations d’API que vos syst\u00e8mes effectuent \u2014 mais selon un calendrier pr\u00e9visible et continu.<\/p>\n

Pourquoi le monitoring traditionnel manque les probl\u00e8mes d’API<\/h2>\n

La plupart des \u00e9quipes surveillent d\u00e9j\u00e0 certaines m\u00e9triques. Elles suivent l’utilisation CPU, la m\u00e9moire et la disponibilit\u00e9 via des tableaux d’infrastructure. Mais rien de tout cela ne s’applique aux API Salesforce \u2014 vous ne contr\u00f4lez pas les serveurs, et la page de statut \u00ab tout vert \u00bb de Salesforce refl\u00e8te rarement le comportement de votre org ou de vos apps connect\u00e9es.<\/p>\n

Les v\u00e9rifications d’uptime qui se contentent de pinguer un endpoint sont \u00e9galement insuffisantes. Elles confirmeront que api.salesforce.com renvoie une r\u00e9ponse, mais pas que votre flux de travail fonctionne r\u00e9ellement. Un 200 OK n’indique pas un payload valide, des valeurs de champs correctes ou une ex\u00e9cution dans les d\u00e9lais. La v\u00e9ritable visibilit\u00e9 provient d’exercer la logique qui compte \u2014 authentifier, interroger, \u00e9crire, supprimer et valider les r\u00e9sultats. C’est l\u00e0 que la surveillance synth\u00e9tique change la donne.<\/p>\n

Comprendre l’\u00e9cosyst\u00e8me des API Salesforce<\/h2>\n

Avant de concevoir des tests, il vaut la peine de comprendre l’\u00e9cosyst\u00e8me que vous testez. Salesforce propose plusieurs API : REST pour les op\u00e9rations CRUD standard, SOAP pour les int\u00e9grations h\u00e9rit\u00e9es, Bulk pour les gros jobs de donn\u00e9es, Composite pour les op\u00e9rations group\u00e9es et Streaming pour les mises \u00e0 jour orient\u00e9es \u00e9v\u00e9nement. Chacune se comporte diff\u00e9remment sous charge, et chacune a ses propres particularit\u00e9s d’authentification.<\/p>\n

La plupart des int\u00e9grations actuelles reposent sur OAuth 2.0, g\u00e9n\u00e9ralement via une application connect\u00e9e qui \u00e9met des tokens d’acc\u00e8s de courte dur\u00e9e et des tokens de rafra\u00eechissement de longue dur\u00e9e. Ces flux compliquent la surveillance synth\u00e9tique car ils expirent et tournent. Un script simple qui stocke des identifiants \u00e9chouera d\u00e8s qu’un token expirera. La surveillance synth\u00e9tique doit donc imiter une int\u00e9gration r\u00e9elle, en g\u00e9rant les rafra\u00eechissements de fa\u00e7on gracieuse et en stockant les secrets en toute s\u00e9curit\u00e9.<\/p>\n

Concevoir des tests de surveillance synth\u00e9tique pour les API Salesforce<\/h2>\n

Un monitoring synth\u00e9tique efficace ne se contente pas de pinguer des endpoints \u2014 il ex\u00e9cute un travail r\u00e9el de mani\u00e8re contr\u00f4l\u00e9e. Chaque test doit refl\u00e9ter une transaction m\u00e9tier r\u00e9elle, en validant que le processus de bout en bout fonctionne toujours. La structure suit g\u00e9n\u00e9ralement quatre \u00e9tapes.<\/p>\n

    \n
  1. Authentifier en toute s\u00e9curit\u00e9<\/strong>
    \nLa base de toute appel \u00e0 l’API Salesforce est l’authentification. Les tests synth\u00e9tiques doivent utiliser le flux JWT ou le flux de refresh-token via une application connect\u00e9e d\u00e9di\u00e9e. N’int\u00e9grez jamais de credentials statiques dans des scripts. Stockez plut\u00f4t les tokens dans un coffre s\u00e9curis\u00e9 ou une configuration chiffr\u00e9e et renouvelez-les de fa\u00e7on programmatique. Cela garantit une surveillance continue sans intervention humaine ni risque de s\u00e9curit\u00e9.<\/li>\n
  2. Simuler des appels r\u00e9els<\/strong>
    \nUne fois authentifi\u00e9, les tests synth\u00e9tiques doivent effectuer des op\u00e9rations significatives. Cr\u00e9ez un enregistrement de test, interrogez-le, puis supprimez-le. Utilisez des objets d\u00e9di\u00e9s ou des sandboxes pour isoler les donn\u00e9es de monitoring de la production. L’objectif est de prouver que la logique m\u00e9tier s’ex\u00e9cute correctement, pas de mesurer une disponibilit\u00e9 abstraite.<\/li>\n
  3. Mesurer performance et int\u00e9grit\u00e9<\/strong>
    \nLe temps de r\u00e9ponse n’est qu’une partie de l’histoire. Les tests doivent v\u00e9rifier l’int\u00e9grit\u00e9 des donn\u00e9es \u2014 comptage des enregistrements, valeurs des champs, horodatages \u2014 pour confirmer que la r\u00e9ponse correspond aux attentes. La latence et la taille des payloads dans le temps r\u00e9v\u00e8lent des tendances bien avant qu’une panne n’arrive.<\/li>\n
  4. Contr\u00f4ler fr\u00e9quence et p\u00e9rim\u00e8tre<\/strong>
    \nSalesforce applique des limites strictes d’appels d’API par utilisateur et par org. Surveiller de fa\u00e7on trop agressive peut provoquer des probl\u00e8mes en soi. Ex\u00e9cutez des v\u00e9rifications synth\u00e9tiques assez fr\u00e9quemment pour d\u00e9tecter les probl\u00e8mes, mais pas au point de consommer les quotas. Des intervalles horaires trouvent souvent le bon compromis, avec des ex\u00e9cutions s\u00e9par\u00e9es et moins fr\u00e9quentes pour les jobs bulk importants.<\/li>\n<\/ol>\n

    Quand ils sont con\u00e7us ainsi, les tests synth\u00e9tiques deviennent la preuve vivante que vos int\u00e9grations Salesforce sont saines. Ils ne se contentent pas de dire \u00ab l’endpoint est actif \u00bb \u2014 ils montrent que le syst\u00e8me continue de se comporter comme pr\u00e9vu.<\/p>\n

    G\u00e9rer l’authentification et les tokens dans le monitoring<\/h2>\n

    Le mod\u00e8le OAuth de Salesforce ajoute \u00e0 la fois de la s\u00e9curit\u00e9 et de la complexit\u00e9. Les tokens d’acc\u00e8s expirent g\u00e9n\u00e9ralement en minutes ou heures, for\u00e7ant les int\u00e9grations \u00e0 les rafra\u00eechir. Pour le monitoring synth\u00e9tique, ce cycle de rafra\u00eechissement doit \u00eatre automatis\u00e9 et s\u00e9curis\u00e9.<\/p>\n

    Une approche pratique consiste \u00e0 utiliser le flux bearer JWT, o\u00f9 l’agent de monitoring signe une requ\u00eate avec une cl\u00e9 priv\u00e9e pour recevoir un token d’acc\u00e8s de courte dur\u00e9e. Aucun mot de passe ou refresh token n’a besoin d’\u00eatre stock\u00e9, ce qui le rend id\u00e9al pour les agents automatis\u00e9s. Les tokens doivent \u00eatre mis en cache temporairement, chiffr\u00e9s au repos et rotat\u00e9s fr\u00e9quemment.<\/p>\n

    Des outils de monitoring synth\u00e9tique comme Dotcom-Monitor peuvent g\u00e9rer ces tokens de fa\u00e7on centralis\u00e9e, garantissant que chaque test s’ex\u00e9cute avec des identifiants valides. Cela \u00e9vite le pi\u00e8ge courant o\u00f9 un script de monitoring \u00e9choue simplement parce que son authentification a expir\u00e9. Avec une gestion appropri\u00e9e des tokens, les tests synth\u00e9tiques restent stables, s\u00e9curis\u00e9s et non intrusifs.<\/p>\n

    Tester les limites d’API et le throttling de Salesforce<\/h2>\n

    Salesforce applique des limites de taux pour emp\u00eacher les abus et maintenir l’isolation entre tenants. Chaque org et utilisateur dispose d’un nombre fini d’appels d’API par p\u00e9riode de 24 heures. Les tests synth\u00e9tiques doivent v\u00e9rifier que ces limites se comportent de mani\u00e8re pr\u00e9visible sans contribuer \u00e0 l’\u00e9puisement.<\/p>\n

    Une approche consiste \u00e0 inclure des rafales contr\u00f4l\u00e9es dans votre planning de tests. Ex\u00e9cutez des s\u00e9quences d’appels d’API pour observer comment Salesforce g\u00e8re la charge, et surveillez les r\u00e9ponses HTTP 403 \u00ab Request Limit Exceeded \u00bb. Celles-ci indiquent soit un probl\u00e8me r\u00e9el soit un manque de capacit\u00e9 planifi\u00e9e. Suivre la consommation des limites d’API dans le temps aide \u00e0 pr\u00e9voir les besoins en mont\u00e9e en charge, surtout lorsque les int\u00e9grations s’\u00e9tendent.<\/p>\n

    En exer\u00e7ant proactivement les limites (plut\u00f4t que r\u00e9activement), le monitoring synth\u00e9tique veille \u00e0 ce que votre org Salesforce reste r\u00e9silient sous trafic l\u00e9gitime, pas seulement dans des conditions id\u00e9ales.<\/p>\n

    Interpr\u00e9ter les r\u00e9sultats : au-del\u00e0 du statut 200<\/h2>\n

    Un retour HTTP 200 de l’API Salesforce ne signifie pas le succ\u00e8s. De nombreuses op\u00e9rations peuvent \u00e9chouer logiquement tout en paraissant correctes. Par exemple, une requ\u00eate peut s’ex\u00e9cuter correctement mais retourner z\u00e9ro r\u00e9sultat parce que la synchronisation en amont a \u00e9chou\u00e9. Une requ\u00eate composite peut r\u00e9ussir globalement tandis qu’une sous-requ\u00eate \u00e9choue silencieusement.<\/p>\n

    Les tests synth\u00e9tiques doivent donc valider la logique, pas seulement le protocole. Ils doivent parser les payloads, confirmer la pr\u00e9sence des champs attendus et v\u00e9rifier les horodatages ou num\u00e9ros de version. Lorsqu’ils sont ex\u00e9cut\u00e9s en continu, ces contr\u00f4les \u00e9tablissent une ligne de base \u2014 \u00e0 quoi ressemble la normalit\u00e9 \u2014 afin que les d\u00e9viations deviennent \u00e9videntes. Une latence qui augmente ou des r\u00e9ponses qui diminuent en taille signalent souvent des probl\u00e8mes naissants.<\/p>\n

    Le monitoring synth\u00e9tique transforme ces indications en alertes. Au lieu de r\u00e9agir aux plaintes des utilisateurs, les \u00e9quipes re\u00e7oivent des avertissements pr\u00e9coces bas\u00e9s sur des comportements transactionnels r\u00e9els.<\/p>\n

    Surveillance synth\u00e9tique pour API composites et d\u00e9pendantes<\/h2>\n

    Les architectures Salesforce modernes appellent rarement une unique API de mani\u00e8re isol\u00e9e. Les endpoints composite regroupent souvent plusieurs op\u00e9rations en une seule transaction, tandis que des middlewares comme MuleSoft ou Workato encha\u00eenent des appels Salesforce avec des syst\u00e8mes externes. Cette complexit\u00e9 en couches est pr\u00e9cis\u00e9ment l’endroit o\u00f9 la surveillance synth\u00e9tique apporte le plus de valeur \u2014 en rejouant les m\u00eames \u00e9tapes interd\u00e9pendantes dont d\u00e9pend votre automatisation.<\/p>\n

    Les tests synth\u00e9tiques peuvent simuler des workflows m\u00e9tiers de bout en bout tels que :<\/p>\n

      \n
    • Cr\u00e9ation de lead et lien avec opportunit\u00e9<\/strong> \u2014 cr\u00e9er un lead qui d\u00e9clenche automatiquement une mise \u00e0 jour d’opportunit\u00e9 via une requ\u00eate composite.<\/li>\n
    • Synchronisations de campagnes inter-syst\u00e8mes<\/strong> \u2014 poster des donn\u00e9es dans Salesforce et valider que les plateformes marketing ou d’analytics en aval re\u00e7oivent les mises \u00e0 jour attendues.<\/li>\n
    • Jobs batch ou planifi\u00e9s<\/strong> \u2014 v\u00e9rifier les int\u00e9grations nocturnes qui ins\u00e8rent ou mettent \u00e0 jour des enregistrements en masse, assurant la consistance des donn\u00e9es et des timings.<\/li>\n
    • Workflows d’objets personnalis\u00e9s<\/strong> \u2014 tester la logique m\u00e9tier propre \u00e0 votre org, o\u00f9 une mise \u00e0 jour d’enregistrement d\u00e9clenche des flows Apex ou des webhooks externes.<\/li>\n
    • Cha\u00eenes d’API d\u00e9pendantes<\/strong> \u2014 exercer des processus multi-\u00e9tapes couvrant Salesforce et des API tierces, confirmant l’authentification, le s\u00e9quencement et l’int\u00e9grit\u00e9 des payloads \u00e0 chaque \u00e9tape.<\/li>\n<\/ul>\n

      En traitant ces processus comme des transactions coh\u00e9sives plut\u00f4t que des appels isol\u00e9s, la surveillance synth\u00e9tique expose les points faibles que les tests traditionnels manquent. Un timeout peut avoir pour origine Salesforce, ou peut se propager depuis une d\u00e9pendance externe. Des workflows script\u00e9s en continu rendent ces fronti\u00e8res visibles \u2014 ainsi, lorsque des d\u00e9faillances surviennent, vous saurez non seulement qu’elles<\/em> ont eu lieu, mais o\u00f9<\/em> et pourquoi<\/em>.<\/p>\n

      Int\u00e9grer les r\u00e9sultats synth\u00e9tiques \u00e0 une observabilit\u00e9 plus large<\/h2>\n

      La surveillance synth\u00e9tique n’existe pas isol\u00e9ment. Ses r\u00e9sultats prennent tout leur sens lorsqu’ils sont corr\u00e9l\u00e9s \u00e0 d’autres donn\u00e9es d’observabilit\u00e9. Les tendances de latence des API peuvent s’aligner sur des ralentissements r\u00e9seau ou des d\u00e9ploiements de code. Une mont\u00e9e brutale des \u00e9checs d’authentification peut se tracer jusqu’\u00e0 un certificat d’application connect\u00e9e r\u00e9voqu\u00e9.<\/p>\n

      Envoyer les m\u00e9triques synth\u00e9tiques vers les tableaux de bord existants donne aux \u00e9quipes une vue unifi\u00e9e. Les int\u00e9grations avec les plateformes d’alerte font en sorte que les anomalies d\u00e9clenchent des actions, pas seulement des rapports.<\/p>\n

      Les outils APIView et UserView de Dotcom-Monitor facilitent cette corr\u00e9lation \u2014 en combinant les r\u00e9sultats de transactions synth\u00e9tiques avec la disponibilit\u00e9, les performances et l’analyse d’erreurs. Le r\u00e9sultat est plus qu’un simple signal pass\u00e9\/\u00e9chou\u00e9 : c’est un insight contextuel sur la sant\u00e9 du syst\u00e8me.<\/p>\n

      Consid\u00e9rations de s\u00e9curit\u00e9 et de conformit\u00e9<\/h2>\n

      La surveillance synth\u00e9tique interagit avec des syst\u00e8mes de production en direct, elle doit donc \u00eatre gouvern\u00e9e comme toute int\u00e9gration. Salesforce permet le whitelist d’adresses IP pour les applications connect\u00e9es, et les agents de monitoring doivent utiliser des plages IP fixes et approuv\u00e9es. Les identifiants doivent appartenir \u00e0 des comptes de monitoring isol\u00e9s, pas \u00e0 des utilisateurs humains, et ces comptes doivent avoir un acc\u00e8s minimal \u2014 juste ce qu’il faut pour ex\u00e9cuter les tests.<\/p>\n

      Les journaux et les pistes d’audit sont essentiels. Chaque transaction synth\u00e9tique doit \u00eatre tra\u00e7able par compte, horaire et origine. Cela assure la conformit\u00e9 avec des cadres de s\u00e9curit\u00e9 comme SOC 2 ou ISO 27001 tout en gardant le p\u00e9rim\u00e8tre d’audit propre.<\/p>\n

      Fait correctement, le monitoring synth\u00e9tique renforce la conformit\u00e9 plut\u00f4t que de la compliquer \u2014 en fournissant des preuves auditables que les syst\u00e8mes critiques sont test\u00e9s continuellement et de mani\u00e8re s\u00e9curis\u00e9e.<\/p>\n

      Avenir du monitoring des API Salesforce<\/h2>\n

      La surface d’API de Salesforce continue d’\u00e9voluer. La plateforme pilote des endpoints de type GraphQL pour un acc\u00e8s aux donn\u00e9es plus efficace, et ses API Event Monitoring et Pub\/Sub \u00e9tendent la visibilit\u00e9 vers des op\u00e9rations quasi-temps r\u00e9el. Ces \u00e9volutions remodeleront la fa\u00e7on dont fonctionne la surveillance synth\u00e9tique.<\/p>\n

      Les tests synth\u00e9tiques de demain n’enverront pas seulement des requ\u00eates et mesureront la latence \u2014 ils s’abonneront \u00e0 des \u00e9v\u00e9nements, valideront la coh\u00e9rence des streams et testeront la performance des webhooks. Le principe, cependant, reste le m\u00eame : simuler la logique r\u00e9elle de l’utilisateur, mesurer les r\u00e9sultats et alerter lorsque la r\u00e9alit\u00e9 diverge des attentes.<\/p>\n

      Conclusion<\/h2>\n

      Les API Salesforce sont critiques pour le m\u00e9tier, mais trompeusement silencieuses lorsque quelque chose se d\u00e9r\u00e8gle. La surveillance synth\u00e9tique r\u00e9tablit cette visibilit\u00e9 manquante en simulant les m\u00eames appels que vos syst\u00e8mes effectuent chaque jour. Elle valide l’authentification, les performances et l’int\u00e9grit\u00e9 des donn\u00e9es \u2014 pas seulement les codes d’\u00e9tat.<\/p>\n

      En combinant une gestion s\u00e9curis\u00e9e des tokens, des transactions r\u00e9alistes et des alertes contextuelles, les \u00e9quipes peuvent d\u00e9tecter les d\u00e9faillances bien avant qu’elles ne se propagent dans les int\u00e9grations ou n’affectent les utilisateurs.<\/p>\n

      La plateforme de surveillance synth\u00e9tique de Dotcom-Monitor simplifie ce processus. Avec le support des APIs OAuth s\u00e9curis\u00e9es, des scripts personnalisables et la validation continue des transactions, elle donne aux \u00e9quipes d’exploitation la confiance que leurs int\u00e9grations Salesforce fonctionnent comme pr\u00e9vu.<\/p>\n

      Quand les int\u00e9grations \u00e9chouent silencieusement, la surveillance synth\u00e9tique fait le bruit dont vous avez besoin.<\/p>\n","protected":false},"excerpt":{"rendered":"

      Les API de Salesforce op\u00e8rent discr\u00e8tement derri\u00e8re d’innombrables interactions clients. Elles relient les CRM \u00e0 la facturation, synchronisent les leads avec le marketing et alimentent les tableaux de bord dont les dirigeants d\u00e9pendent au quotidien. Pourtant, lorsqu’une de ces API ralentit ou tombe en panne, cela se produit souvent sans alerte. Les tableaux de bord […]<\/p>\n","protected":false},"author":39,"featured_media":31018,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-31024","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\/31024","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=31024"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/31024\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/media\/31018"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/media?parent=31024"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/categories?post=31024"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/wp-json\/wp\/v2\/tags?post=31024"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}