{"id":40982,"date":"2026-05-13T08:00:00","date_gmt":"2026-05-13T06:00:00","guid":{"rendered":"https:\/\/leocare.eu\/fr\/?post_type=leocare_lab&p=40982"},"modified":"2026-04-01T23:26:03","modified_gmt":"2026-04-01T21:26:03","slug":"comment-resorber-sa-dette-technique-partie-3","status":"publish","type":"leocare_lab","link":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-3\/","title":{"rendered":"Comment r\u00e9sorber sa dette technique : anticiper ce qui ne se voit pas encore (partie 3)"},"content":{"rendered":"\n

Arriv\u00e9 ici, vous avez une application qui tourne bien, avec de bons outils et une bonne vision, en phase avec votre s\u00e9niorit\u00e9. Ce troisi\u00e8me volet cl\u00f4t la s\u00e9rie. Si vous d\u00e9barquez directement, le pr\u00e9c\u00e9dent volet sur la dette profonde et structurante est \u00e0 lire en amont pour bien suivre le fil.<\/p>\n\n\n\n

La dette cach\u00e9e, c’est quoi ?<\/h2>\n\n\n\n

Il y a toujours une dette cach\u00e9e<\/strong>, m\u00eame quand tout semble parfait. Elle se loge dans des endroits qu’on ne remarque pas tout de suite : des d\u00e9pendances implicites<\/strong>, des modules sous-test\u00e9s<\/strong>, ou des hypoth\u00e8ses obsol\u00e8tes<\/strong>. Elle ne se manifeste pas par des bugs ou des crashs. Elle attend son heure.<\/strong><\/p>\n\n\n\n

Comment on la d\u00e9busque ?<\/h2>\n\n\n\n

Pour mettre en lumi\u00e8re la dette cach\u00e9e, il faut s’appuyer sur une compr\u00e9hension totale du projet<\/strong>. C’est souvent un travail d’enqu\u00eate, car cette dette ne se manifeste pas de fa\u00e7on \u00e9vidente. Voici les leviers qui nous ont permis de la d\u00e9busquer :<\/p>\n\n\n\n

    \n
  • Outils d’audit avanc\u00e9s<\/strong> : l’analyse statique, les tests de performance ou les scanners de s\u00e9curit\u00e9 peuvent r\u00e9v\u00e9ler des zones probl\u00e9matiques que vous n’aviez pas identifi\u00e9es<\/strong>. Dans cette phase, vous avez le recul pour interpr\u00e9ter ces r\u00e9sultats correctement.<\/li>\n\n\n\n
  • Feedback de l’\u00e9quipe<\/strong> : vos coll\u00e8gues connaissent souvent des zones qu’ils \u00e9vitent de toucher. “On ne touche pas \u00e0 \u00e7a, c’est fragile.” Ces zones sont de la dette cach\u00e9e.<\/strong> Prenez le temps de les lister.<\/li>\n\n\n\n
  • Les workarounds accumul\u00e9s<\/strong> : ces petits hacks mis en place “en attendant” qui sont toujours l\u00e0. Ces conditions sp\u00e9ciales pour g\u00e9rer des cas edge. \u00c0 force, ils forment une couche de complexit\u00e9 invisible<\/strong>.<\/li>\n\n\n\n
  • Les hypoth\u00e8ses obsol\u00e8tes<\/strong> : des d\u00e9cisions prises il y a 2 ans qui ne correspondent plus \u00e0 la r\u00e9alit\u00e9<\/strong>. L’API qui devait \u00e9voluer mais qui est rest\u00e9e fig\u00e9e. Le volume de donn\u00e9es qui a explos\u00e9 alors que l’archi \u00e9tait pr\u00e9vue pour moins.<\/li>\n\n\n\n
  • Les connaissances tribales<\/strong> : ce que seule une personne de l’\u00e9quipe sait. “Demande \u00e0 Pierre, c’est lui qui conna\u00eet cette partie.” Si Pierre part, cette connaissance part avec lui. C’est une dette, m\u00eame si elle n’est pas dans le code.<\/strong><\/li>\n<\/ul>\n\n\n\n
    \"detecter<\/figure>\n\n\n\n

    Les outils de cette phase<\/h2>\n\n\n\n

    \u00c0 ce stade, les outils servent moins \u00e0 d\u00e9couvrir qu’\u00e0 piloter, communiquer et optimiser. Voici ceux qu’on a mobilis\u00e9s :<\/p>\n\n\n\n

    Outil<\/th>But \/ Mission<\/th><\/tr><\/thead>
    Rituels<\/strong><\/td>S’organiser autour des diff\u00e9rents outils mis en place pour suivre de fa\u00e7on r\u00e9guli\u00e8re<\/strong> les remont\u00e9es.<\/td><\/tr>
    Heatmaps fonctionnelles<\/strong><\/td>Visualiser les zones critiques de l’application et leur \u00e9tat (vert, jaune, rouge<\/strong>).<\/td><\/tr>
    Grafana \u00d7 OpenTelemetry<\/strong><\/td>Donner de l’autonomie aux autres \u00e9quipes pour comprendre un bug. Connect\u00e9 aux logs backend avec Grafana Tempo, on voit toute la cha\u00eene d’encha\u00eenement des services<\/strong> avec des infos compl\u00e9mentaires (OS, version de l’app, etc.).<\/td><\/tr>
    Firebase Performance<\/strong><\/td>Visualiser la performance de l’application. Suivre les calls r\u00e9seaux<\/strong> et autres metrics pour identifier les optimisations possibles.<\/td><\/tr>
    Outil de d\u00e9tection du code inutilis\u00e9<\/strong><\/td>Nettoyer le code inutilis\u00e9<\/strong> pour ne pas garder les choses qui ne servent pas. Tout reste dans Git, rien n’est perdu.<\/td><\/tr>
    Firebase Remote Config<\/strong><\/td>G\u00e9rer l’activation ou la d\u00e9sactivation d’un bout de code. Permet de faire des migrations progressives<\/strong> en production.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Les rituels : structurer le suivi<\/h3>\n\n\n\n

    De notre c\u00f4t\u00e9, on a mis en place des remont\u00e9es p\u00e9riodiques<\/strong> et des points r\u00e9guliers<\/strong> pour faire le bilan sur chaque outil, voir comment il \u00e9volue, et s’affecter des t\u00e2ches.<\/p>\n\n\n\n

    Essayez de r\u00e9partir dans le temps<\/strong> ces points pour les outils. Si vous organisez une grosse r\u00e9union avec les remont\u00e9es de tous vos outils de suivi, \u00e7a peut devenir tr\u00e8s frustrant face \u00e0 l’ampleur de la charge de travail. Il vaut mieux \u00e9valuer la charge que cela g\u00e9n\u00e8re et adapter avec votre \u00e9quipe<\/strong>. Trouvez un juste milieu. Avec la mont\u00e9e en comp\u00e9tence de chacun, vous verrez \u00e9voluer votre fa\u00e7on de corriger les probl\u00e8mes.<\/p>\n\n\n\n

    Un conseil : si vous avez de l’exp\u00e9rience, prenez sur vous la charge de r\u00e9duire le niveau des remont\u00e9es<\/strong>. Par exemple, n’afficher que les remont\u00e9es critiques tant qu’il y en a, puis ouvrir progressivement. Cela permet de se concentrer sur les priorit\u00e9s plus rapidement<\/strong>.<\/p>\n\n\n\n

    Les Heat Maps fonctionnelles : communiquer sur la dette<\/h3>\n\n\n\n

    On a eu des probl\u00e9matiques de communication avec l’\u00e9quipe produit<\/strong> au fur et \u00e0 mesure que notre dette technique diminuait. De l’ext\u00e9rieur, tout semblait bien se passer : l’application fonctionnait bien, peu de crashs, peu d’erreurs, un aspect visuel correct. Mais on avait toujours en t\u00eate des parties qu’il fallait revoir<\/strong> pour \u00e9viter que l’application ne tombe du jour au lendemain.<\/p>\n\n\n\n

    \"heat<\/figure>\n\n\n\n

    Pour cela, on a analys\u00e9 feature par feature<\/strong> l’application (d’abord de fa\u00e7on macro, puis avec plus de pr\u00e9cision au fil du temps) pour \u00e9valuer l’\u00e9tat de chacune. On a tout mis \u00e0 plat dans un document, et pour rendre cela visuel, on a cr\u00e9\u00e9 une sorte de Heat Map \u00e0 la main, avec un code couleur simple :<\/p>\n\n\n\n

      \n
    • Vert<\/strong> : la feature est saine, elle fonctionne correctement<\/li>\n\n\n\n
    • Orange<\/strong> : la feature n\u00e9cessite une attention particuli\u00e8re, \u00e0 surveiller<\/li>\n\n\n\n
    • Rouge<\/strong> : la feature est difficile \u00e0 faire \u00e9voluer, elle freine le d\u00e9veloppement business<\/li>\n\n\n\n
    • Noir<\/strong> : zone morte, la feature n\u00e9cessite une refonte compl\u00e8te<\/li>\n<\/ul>\n\n\n\n
      \"niveaux<\/figure>\n\n\n\n

      Gr\u00e2ce \u00e0 cette Heat Map, on a pu montrer factuellement l’\u00e9tat de l’application<\/strong>. Pas mal de parties \u00e9taient OK, mais certaines \u00e9taient complexes \u00e0 maintenir. Cela a permis aux diff\u00e9rentes \u00e9quipes de prendre en main leur p\u00e9rim\u00e8tre<\/strong> et de voir, c\u00f4t\u00e9 produit, comment int\u00e9grer ces travaux dans la roadmap. L’id\u00e9e \u00e9tait aussi de formaliser sur un document ce qu’on avait en t\u00eate<\/strong>.<\/p>\n\n\n\n

      Des librairies d\u00e9pr\u00e9ci\u00e9es laiss\u00e9es de c\u00f4t\u00e9 car trop structurantes<\/h3>\n\n\n\n

      On a renforc\u00e9 la communication et fait des pr\u00e9sentations pour expliquer ce que cela impliquait<\/strong>, tout en rassurant l’entreprise sur notre capacit\u00e9 \u00e0 g\u00e9rer un sujet aussi structurant. On a aussi utilis\u00e9 la Heat Map pour visualiser cette partie, m\u00eame si c’est quelque chose de plus technique.<\/p>\n\n\n\n

      Notre plus gros enjeu structurant depuis un an est de pr\u00e9parer la transition de notre navigation c\u00f4t\u00e9 Android<\/strong>, qui repose sur une librairie d\u00e9pr\u00e9ci\u00e9e utilisant les FragmentManager.<\/p>\n\n\n\n

      Optimiser les performances : Firebase Performance et Grafana<\/h3>\n\n\n\n

      C’est dans cette phase que l’optimisation des performances prend tout son sens<\/strong>. Avant, on mettait en place des outils pour observer. Maintenant, on a assez de recul et de donn\u00e9es pour agir<\/strong>.<\/p>\n\n\n\n

      Avec Firebase Performance<\/strong>, on a pu analyser l’utilisation des requ\u00eates webservices et identifier les appels r\u00e9seau \u00e0 optimiser<\/strong>. On ne l’a pas fait tout de suite. On a d’abord mis l’outil en place de fa\u00e7on l\u00e9g\u00e8re, observ\u00e9 les donn\u00e9es, compris les patterns. Et quand on a eu une vision claire des probl\u00e8mes, on a pu prioriser les optimisations qui avaient vraiment un impact<\/strong>.<\/p>\n\n\n\n

      Grafana coupl\u00e9 \u00e0 OpenTelemetry<\/strong> nous a permis d’aller encore plus loin. On voit maintenant toute la cha\u00eene d’ex\u00e9cution d’une requ\u00eate<\/strong> : du mobile jusqu’au backend, en passant par tous les services interm\u00e9diaires. Quand un utilisateur remonte un probl\u00e8me de lenteur, on peut tracer exactement ce qui s’est pass\u00e9<\/strong>. \u00c7a donne aussi de l’autonomie aux autres \u00e9quipes : elles peuvent investiguer sans forc\u00e9ment solliciter les devs mobile.<\/p>\n\n\n\n

      L’id\u00e9e, c’est que les outils de performance deviennent vraiment utiles quand vous ma\u00eetrisez votre application<\/strong>. Avant \u00e7a, vous risquez de vous noyer dans des m\u00e9triques sans savoir quoi en faire.<\/p>\n\n\n\n

      Firebase Remote Config : migrer en douceur<\/h3>\n\n\n\n

      Quand vous devez remplacer un composant structurant de votre application, vous ne pouvez pas tout basculer d’un coup<\/strong>. C’est l\u00e0 que Firebase Remote Config<\/strong> devient pr\u00e9cieux.<\/p>\n\n\n\n

      \"firebase<\/figure>\n\n\n\n

      L’id\u00e9e est simple : vous gardez l’ancien code et le nouveau c\u00f4te \u00e0 c\u00f4te, et vous contr\u00f4lez lequel est actif via un flag distant. \u00c7a vous permet de :<\/p>\n\n\n\n

        \n
      • Tester en conditions r\u00e9elles<\/strong> : activer la nouvelle impl\u00e9mentation pour un petit pourcentage d’utilisateurs et observer le comportement.<\/li>\n\n\n\n
      • Rollback instantan\u00e9<\/strong> : si quelque chose ne va pas, vous d\u00e9sactivez le flag sans avoir \u00e0 red\u00e9ployer<\/strong>.<\/li>\n\n\n\n
      • Migration progressive<\/strong> : vous augmentez progressivement le pourcentage d’utilisateurs sur la nouvelle version jusqu’\u00e0 100 %.<\/li>\n<\/ul>\n\n\n\n

        De notre c\u00f4t\u00e9, on l’a utilis\u00e9 pour plusieurs migrations, business comme techniques. C\u00f4t\u00e9 technique, deux cas majeurs :<\/p>\n\n\n\n

          \n
        • Le changement complet de notre backend<\/strong> : on a maintenu les deux backends en parall\u00e8le pendant la transition, et le switch en production s’est fait de fa\u00e7on transparente pour les utilisateurs<\/strong>. C’\u00e9tait un chantier \u00e9norme, mais Remote Config nous a permis de ma\u00eetriser les impacts \u00e0 chaque \u00e9tape<\/strong>.<\/li>\n\n\n\n
        • La migration de notre feature de chat<\/strong> : on a fait cohabiter l’ancienne et la nouvelle impl\u00e9mentation. Le switch en production s’est fait progressivement. Aucune coupure, aucun stress.<\/strong><\/li>\n<\/ul>\n\n\n\n

          \u00c7a rassure tout le monde : l’\u00e9quipe technique, le produit, et les parties prenantes. On avance sereinement sur des sujets qui auraient pu \u00eatre tr\u00e8s risqu\u00e9s.<\/strong> Une fois la migration termin\u00e9e et valid\u00e9e, on supprime l’ancien code et le flag. C’est important de ne pas laisser tra\u00eener ces feature flags ind\u00e9finiment<\/strong>, sinon vous cr\u00e9ez une nouvelle forme de dette.<\/p>\n\n\n\n

          Nouveaut\u00e9s des plateformes<\/h3>\n\n\n\n

          Les nouveaut\u00e9s comme Compose<\/strong> ou SwiftUI<\/strong> sont int\u00e9ressantes \u00e0 mettre en place pour l’avenir de l’application et des personnes qui vont travailler dessus<\/strong>.<\/p>\n\n\n\n

          Comment en parler sans tout casser ?<\/h2>\n\n\n\n

          Une fois la dette d\u00e9tect\u00e9e, il faut la communiquer<\/strong>. Et pour \u00e7a, pas question de parler en jargon incompr\u00e9hensible aux non-d\u00e9veloppeurs :<\/p>\n\n\n\n

            \n
          • Adaptez votre discours<\/strong> : parlez des cons\u00e9quences r\u00e9elles de la dette (retards, instabilit\u00e9), pas de d\u00e9tails techniques abscons.<\/li>\n\n\n\n
          • Proposez des solutions progressives<\/strong> : on ne la r\u00e9sout pas tout d’un coup. Il s’agit de la r\u00e9duire petit \u00e0 petit<\/strong>, tout en gardant les objectifs business en t\u00eate.<\/li>\n<\/ul>\n\n\n\n

            Conclusion<\/h2>\n\n\n\n

            La dette technique n’est jamais totalement \u00e9limin\u00e9e.<\/strong> L’important, c’est de l’int\u00e9grer dans la routine de l’\u00e9quipe : des revues de code r\u00e9guli\u00e8res<\/strong>, des audits p\u00e9riodiques<\/strong>, et surtout une culture de responsabilit\u00e9 partag\u00e9e<\/strong>.<\/p>\n\n\n\n

            Cette s\u00e9rie a parcouru trois \u00e9tapes : la d\u00e9couverte de la dette de surface<\/strong>, la compr\u00e9hension de la dette profonde structurante<\/strong>, puis la mise en lumi\u00e8re de la dette cach\u00e9e<\/strong>. Pas de solution miracle : la gestion de la dette technique reste du cas par cas<\/strong>, selon votre \u00e9quipe, votre contexte et vos contraintes. Avec des efforts structur\u00e9s, de la communication et du pragmatisme, on r\u00e9duit son impact et on rend le travail plus agr\u00e9able<\/strong>.<\/p>\n\n\n\n

            Merci d’avoir suivi ces trois volets. J’esp\u00e8re que ce partage d’exp\u00e9rience vous aidera \u00e0 aborder vos propres chantiers avec plus de s\u00e9r\u00e9nit\u00e9 et de clart\u00e9<\/strong>.<\/p>\n\n\n\n

            \u00c0 retenir<\/h2>\n\n\n\n

            Cette phase finale est celle o\u00f9 vous passez de la gestion technique pure \u00e0 une vraie collaboration avec les autres \u00e9quipes<\/strong>. La capacit\u00e9 \u00e0 visualiser et communiquer<\/strong> l’\u00e9tat de la dette technique devient aussi importante que la capacit\u00e9 \u00e0 la corriger.<\/p>\n","protected":false},"excerpt":{"rendered":"

            Arriv\u00e9 ici, vous avez une application qui tourne bien, avec de bons outils et une bonne vision, en phase avec votre s\u00e9niorit\u00e9. Ce troisi\u00e8me volet cl\u00f4t la s\u00e9rie. Si vous d\u00e9barquez directement, le pr\u00e9c\u00e9dent volet sur la dette profonde et structurante est \u00e0 lire en amont pour bien suivre le fil. La dette cach\u00e9e, c’est […]<\/p>\n","protected":false},"author":49,"featured_media":40987,"comment_status":"closed","ping_status":"closed","template":"","categorie_leocare_lab":[37],"class_list":["post-40982","leocare_lab","type-leocare_lab","status-publish","has-post-thumbnail","hentry","categorie_leocare_lab-developers"],"acf":[],"yoast_head":"\nLeoLab<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-3\/\" \/>\n<meta property=\"og:locale\" content=\"fr_FR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"LeoLab\" \/>\n<meta property=\"og:description\" content=\"Arriv\u00e9 ici, vous avez une application qui tourne bien, avec de bons outils et une bonne vision, en phase avec votre s\u00e9niorit\u00e9. Ce troisi\u00e8me volet cl\u00f4t la s\u00e9rie. Si vous d\u00e9barquez directement, le pr\u00e9c\u00e9dent volet sur la dette profonde et structurante est \u00e0 lire en amont pour bien suivre le fil. La dette cach\u00e9e, c’est […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-3\/\" \/>\n<meta property=\"og:site_name\" content=\"Leocare, assurance en ligne automobile et habitation\" \/>\n<meta property=\"og:image\" content=\"https:\/\/leocare.eu\/fr\/wp-content\/uploads\/2026\/04\/iceberg.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"800\" \/>\n\t<meta property=\"og:image:height\" content=\"505\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data1\" content=\"9 minutes\" \/>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"LeoLab","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-3\/","og_locale":"fr_FR","og_type":"article","og_title":"LeoLab","og_description":"Arriv\u00e9 ici, vous avez une application qui tourne bien, avec de bons outils et une bonne vision, en phase avec votre s\u00e9niorit\u00e9. Ce troisi\u00e8me volet cl\u00f4t la s\u00e9rie. Si vous d\u00e9barquez directement, le pr\u00e9c\u00e9dent volet sur la dette profonde et structurante est \u00e0 lire en amont pour bien suivre le fil. La dette cach\u00e9e, c’est […]","og_url":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-3\/","og_site_name":"Leocare, assurance en ligne automobile et habitation","og_image":[{"width":800,"height":505,"url":"https:\/\/leocare.eu\/fr\/wp-content\/uploads\/2026\/04\/iceberg.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_misc":{"Est. reading time":"9 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-3\/","url":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-3\/","name":"LeoLab","isPartOf":{"@id":"https:\/\/leocare.eu\/fr\/#website"},"primaryImageOfPage":{"@id":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-3\/#primaryimage"},"image":{"@id":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-3\/#primaryimage"},"thumbnailUrl":"https:\/\/leocare.eu\/fr\/wp-content\/uploads\/2026\/04\/iceberg.jpg","datePublished":"2026-05-13T06:00:00+00:00","breadcrumb":{"@id":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-3\/#breadcrumb"},"inLanguage":"fr-FR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-3\/"]}]},{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-3\/#primaryimage","url":"https:\/\/leocare.eu\/fr\/wp-content\/uploads\/2026\/04\/iceberg.jpg","contentUrl":"https:\/\/leocare.eu\/fr\/wp-content\/uploads\/2026\/04\/iceberg.jpg","width":800,"height":505,"caption":"iceberg"},{"@type":"WebSite","@id":"https:\/\/leocare.eu\/fr\/#website","url":"https:\/\/leocare.eu\/fr\/","name":"Leocare, assurance en ligne automobile et habitation","description":"enfin (r)assur\u00e9.e","publisher":{"@id":"https:\/\/leocare.eu\/fr\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/leocare.eu\/fr\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"fr-FR"},{"@type":"Organization","@id":"https:\/\/leocare.eu\/fr\/#organization","name":"Leocare, assurance en ligne automobile et habitation","url":"https:\/\/leocare.eu\/fr\/","logo":{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/leocare.eu\/fr\/#\/schema\/logo\/image\/","url":"https:\/\/leocare.eu\/fr\/wp-content\/uploads\/2020\/03\/logo-leocare.svg","contentUrl":"https:\/\/leocare.eu\/fr\/wp-content\/uploads\/2020\/03\/logo-leocare.svg","caption":"Leocare, assurance en ligne automobile et habitation"},"image":{"@id":"https:\/\/leocare.eu\/fr\/#\/schema\/logo\/image\/"}}]}},"_links":{"self":[{"href":"https:\/\/leocare.eu\/fr\/wp-json\/wp\/v2\/leocare_lab\/40982","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/leocare.eu\/fr\/wp-json\/wp\/v2\/leocare_lab"}],"about":[{"href":"https:\/\/leocare.eu\/fr\/wp-json\/wp\/v2\/types\/leocare_lab"}],"author":[{"embeddable":true,"href":"https:\/\/leocare.eu\/fr\/wp-json\/wp\/v2\/users\/49"}],"replies":[{"embeddable":true,"href":"https:\/\/leocare.eu\/fr\/wp-json\/wp\/v2\/comments?post=40982"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/leocare.eu\/fr\/wp-json\/wp\/v2\/media\/40987"}],"wp:attachment":[{"href":"https:\/\/leocare.eu\/fr\/wp-json\/wp\/v2\/media?parent=40982"}],"wp:term":[{"taxonomy":"categorie_leocare_lab","embeddable":true,"href":"https:\/\/leocare.eu\/fr\/wp-json\/wp\/v2\/categorie_leocare_lab?post=40982"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}