{"id":40976,"date":"2026-04-29T08:00:00","date_gmt":"2026-04-29T06:00:00","guid":{"rendered":"https:\/\/leocare.eu\/fr\/?post_type=leocare_lab&p=40976"},"modified":"2026-04-01T23:17:59","modified_gmt":"2026-04-01T21:17:59","slug":"comment-resorber-sa-dette-technique-partie-2","status":"publish","type":"leocare_lab","link":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-2\/","title":{"rendered":"Comment r\u00e9sorber sa dette technique : op\u00e9rer sans tout casser (partie 2)"},"content":{"rendered":"\n

Une fois qu’on conna\u00eet mieux un projet, on peut commencer \u00e0 se projeter. Pour nous, \u00e7a a \u00e9t\u00e9 au bout d’un an et demi. On a commenc\u00e9 \u00e0 penser \u00e0 comment adapter l’architecture c\u0153ur<\/strong> vers quelque chose qui nous faciliterait la vie dans le contexte de notre application. Ce deuxi\u00e8me volet passe de la d\u00e9couverte \u00e0 la compr\u00e9hension : apr\u00e8s la dette de surface (partie 1), on s’attaque ici \u00e0 la dette profonde et structurante, avant de conclure sur la dette cach\u00e9e dans la partie 3.<\/strong><\/p>\n\n\n\n

C’est quoi, la dette profonde ?<\/h2>\n\n\n\n

La dette profonde, c’est celle qui est ancr\u00e9e dans l’architecture du projet<\/strong>. C’est le choix technologique qu’on a fait pour aller vite, mais qui revient nous hanter. Un service monolithique qui n’\u00e9volue plus, des d\u00e9pendances non ma\u00eetris\u00e9es, une API centrale qui devient un goulot d’\u00e9tranglement<\/strong>.<\/p>\n\n\n\n

\"dette<\/figure>\n\n\n\n

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

D\u00e9tecter la dette profonde exige une compr\u00e9hension globale du projet<\/strong>. Contrairement \u00e0 la dette de surface qui saute aux yeux, celle-ci se r\u00e9v\u00e8le avec le temps<\/strong>, quand vous commencez \u00e0 vraiment comprendre comment les pi\u00e8ces s’assemblent.<\/p>\n\n\n\n

Les signaux<\/h3>\n\n\n\n

Voici les indicateurs qui doivent vous mettre la puce \u00e0 l’oreille. Si vous en reconnaissez plusieurs, c’est probablement que la dette profonde est d\u00e9j\u00e0 bien install\u00e9e :<\/p>\n\n\n\n

    \n
  • Cartographiez votre architecture<\/strong> : quelles sont les d\u00e9pendances critiques ? Quels modules cr\u00e9ent des goulots d’\u00e9tranglement ? Si vous n’arrivez pas \u00e0 dessiner un sch\u00e9ma clair<\/strong> de votre architecture, c’est d\u00e9j\u00e0 un signal.<\/li>\n\n\n\n
  • Couplage fort entre modules<\/strong> : quand toucher un module oblige \u00e0 en modifier trois autres. Les d\u00e9pendances sont tellement imbriqu\u00e9es qu’on ne sait plus o\u00f9 commence une feature et o\u00f9 elle finit<\/strong>.<\/li>\n\n\n\n
  • Absence de couches d’abstraction<\/strong> : le code UI qui appelle directement la base de donn\u00e9es. Les appels r\u00e9seau \u00e9parpill\u00e9s partout. Pas de s\u00e9paration claire<\/strong> entre la logique m\u00e9tier et le reste.<\/li>\n\n\n\n
  • God classes et monolithes internes<\/strong> : ce manager de 5000 lignes qui fait tout. Ce singleton appel\u00e9 depuis 200 fichiers. Ces classes deviennent impossibles \u00e0 faire \u00e9voluer sans tout casser<\/strong>.<\/li>\n\n\n\n
  • \u00c9coutez les plaintes r\u00e9currentes<\/strong> : si chaque nouvelle fonctionnalit\u00e9 casse trois autres modules, il y a un probl\u00e8me structurel<\/strong>. Si l’\u00e9quipe dit souvent \u00ab\u00a0on ne peut pas faire \u00e7a \u00e0 cause de X\u00a0\u00bb, notez ces X.<\/li>\n\n\n\n
  • Temps de d\u00e9veloppement qui explose<\/strong> : une feature simple qui prend des semaines. Des estimations toujours d\u00e9pass\u00e9es. Ce n’est pas forc\u00e9ment un probl\u00e8me de comp\u00e9tence, c’est souvent la dette qui freine<\/strong>.<\/li>\n\n\n\n
  • Peur de toucher certaines parties<\/strong> : ces zones du code que tout le monde \u00e9vite. \u00ab\u00a0On ne touche pas \u00e0 \u00e7a, \u00e7a marche.\u00a0\u00bb C’est un signe que la dette est devenue trop co\u00fbteuse \u00e0 adresser<\/strong>.<\/li>\n\n\n\n
  • Bugs r\u00e9currents au m\u00eame endroit<\/strong> : vous corrigez un bug, il revient sous une autre forme. Le probl\u00e8me n’est pas le bug, c’est la structure qui le permet.<\/strong><\/li>\n\n\n\n
  • D\u00e9pendances circulaires<\/strong> : A d\u00e9pend de B qui d\u00e9pend de C qui d\u00e9pend de A. Ces cycles rendent le code impossible \u00e0 tester et \u00e0 faire \u00e9voluer proprement<\/strong>.<\/li>\n<\/ul>\n\n\n\n

    Notre exp\u00e9rience : repenser l’architecture<\/h2>\n\n\n\n

    Quand on parle d’architecture, on peut vite tomber dans un pi\u00e8ge : choisir une approche parce qu’elle est tendance, parce que c’est \u00ab\u00a0ce qui se fait\u00a0\u00bb, ou parce qu’on l’a vue dans une conf\u00e9rence. C’est une erreur.<\/strong> L’objectif n’est pas d’adopter la derni\u00e8re architecture \u00e0 la mode, mais de trouver celle qui r\u00e9pond aux besoins de votre projet, votre \u00e9quipe, et votre contexte<\/strong>.<\/p>\n\n\n\n

    \"strategie<\/figure>\n\n\n\n

    Nous avons discut\u00e9 de plusieurs architectures : VIPER, MVI, MVVM<\/strong>. Notre pr\u00e9requis \u00e9tait clair : pas question d’appliquer une architecture \u00ab\u00a0cl\u00e9 en main\u00a0\u00bb parce qu’elle \u00e9tait populaire. On voulait quelque chose qui puisse s’adapter \u00e0 nos r\u00e9alit\u00e9s<\/strong> : ne pas nous obliger \u00e0 utiliser toute la m\u00e9canique pour un simple \u00e9cran statique, mais conserver une ligne directrice coh\u00e9rente<\/strong> sur l’ensemble du projet.<\/p>\n\n\n\n

    On a exp\u00e9riment\u00e9 et trouv\u00e9 un m\u00e9lange de MVVM\/MVI avec des Coordinators et de la Clean Archi<\/strong> (DomainLayer, UseCase, DataLayer, Repository, etc.). L’id\u00e9e \u00e9tait de fournir des objets cl\u00e9s utilisables selon les besoins. Le r\u00e9sultat :<\/p>\n\n\n\n

      \n
    • Des features isol\u00e9es et scalables<\/strong> en termes d’architecture<\/li>\n\n\n\n
    • Certains parcours avec une architecture un peu plus \u00e9volu\u00e9e<\/strong> selon les besoins<\/li>\n\n\n\n
    • Un socle autour des Coordinators<\/strong> pour g\u00e9rer les workflows et pouvoir les lancer de fa\u00e7on standalone<\/li>\n<\/ul>\n\n\n\n

      Int\u00e9grer la nouvelle architecture dans le legacy<\/h2>\n\n\n\n

      Le plus dur n’est pas de trouver l’architecture, mais de l’int\u00e9grer dans le projet existant avec du code legacy.<\/strong><\/p>\n\n\n\n

      On a install\u00e9 le socle de base de la navigation de niveau 0<\/strong> dans un premier temps, en laissant toutes les features actuelles utiliser l’ancien syst\u00e8me. On avait une TabBar au niveau 0, on s’est concentr\u00e9s l\u00e0-dessus. Ensuite, on a prioris\u00e9 selon les enjeux business<\/strong> pour revoir les architectures de chaque partie. C’est une phase qui n’est pas facile, car il faut d’un c\u00f4t\u00e9 op\u00e9rer ce changement, et de l’autre garder en t\u00eate une strat\u00e9gie pour les parties qui n’ont pas encore \u00e9t\u00e9 trait\u00e9es<\/strong>.<\/p>\n\n\n\n

      Bien noter ce qui ferait sens en fonction des enjeux business pour glisser des \u00e9volutions petit \u00e0 petit<\/strong>, c’est essentiel. Essayez autant que possible de finir un chantier avant d’en entamer un nouveau<\/strong>. Sinon, avec une charge mentale importante, vous risquez de perdre le recul n\u00e9cessaire pour adapter votre strat\u00e9gie au fur et \u00e0 mesure.<\/p>\n\n\n\n

      Adapter l’architecture selon les besoins<\/h2>\n\n\n\n

      Parfois, certaines parties de votre application ont besoin d’une architecture un peu diff\u00e9rente<\/strong> pour fonctionner correctement. Et c’est OK.<\/p>\n\n\n\n

      \u00c7a a \u00e9t\u00e9 notre cas pour les parcours avec des formulaires complexes<\/strong> : collecte d’informations utilisateur, validations venant du backend, structure pouvant \u00e9voluer avec les enjeux l\u00e9gaux. On a d\u00fb concevoir une architecture sp\u00e9cifique<\/strong> en s’inspirant de patterns existants, tout en veillant \u00e0 ce qu’elle se branche proprement au reste de notre socle.<\/p>\n\n\n\n

      On peut tr\u00e8s bien avoir diff\u00e9rentes architectures dans un m\u00eame projet<\/strong>, si c’est justifi\u00e9. Les architectures que vous connaissez (MVC, MVVM, VIPER, etc.) ont toutes \u00e9t\u00e9 cr\u00e9\u00e9es pour r\u00e9pondre \u00e0 un besoin pr\u00e9cis. L’important, c’est d’avoir une ligne directrice commune<\/strong> et de documenter pourquoi certaines parties divergent<\/strong>.<\/p>\n\n\n\n

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

      Dans cette phase de compr\u00e9hension, on a ajout\u00e9 des outils qui permettent de prendre du recul et de mesurer l’\u00e9tat r\u00e9el du projet :<\/p>\n\n\n\n

      \"outils<\/figure>\n\n\n\n
      Outil<\/th>But \/ Mission<\/th><\/tr><\/thead>
      Tracking<\/strong><\/td>Comprendre les comportements utilisateurs et voir les parcours probl\u00e9matiques. Essentiel pour comprendre les enjeux business<\/strong> et prioriser les am\u00e9liorations techniques en les alignant avec les priorit\u00e9s de l’entreprise.<\/td><\/tr>
      SonarQube<\/strong><\/td>Analyser la qualit\u00e9 globale du code et suivre les indicateurs de dette technique<\/strong> dans le temps.<\/td><\/tr>
      Visualisateur de librairies<\/strong><\/td>V\u00e9rifier les librairies utilis\u00e9es, faire un \u00e9tat des lieux, et voir si certaines peuvent \u00eatre remplac\u00e9es ou ont un impact fort sur le code core<\/strong>.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

      Le Tracking : comprendre les enjeux business<\/h3>\n\n\n\n

      On a mis en place le Tracking<\/strong>. Certes, c’est souvent vu comme un outil marketing, mais on a voulu en profiter pour comprendre les usages de nos utilisateurs<\/strong>. Comme dans la phase pr\u00e9c\u00e9dente avec les crashs, ici on affine les recherches pour identifier plus pr\u00e9cis\u00e9ment les probl\u00e8mes<\/strong> de l’application.<\/p>\n\n\n\n

      On a coupl\u00e9 le Tracking avec les Crash et NonFatal dans Firebase Crashlytics<\/strong>. R\u00e9sultat : on peut savoir ce que l’utilisateur a fait dans les instants pr\u00e9c\u00e9dant un probl\u00e8me. C’est pr\u00e9cieux pour le debug.<\/strong> On a aussi con\u00e7u notre Tracker pour \u00eatre modulaire<\/strong> : il peut partager les donn\u00e9es de tagging \u00e0 plusieurs outils en m\u00eame temps, que ce soit pour l’analyse marketing ou pour le debug technique.<\/p>\n\n\n\n

      Je recommande d’y aller par \u00e9tapes :<\/strong> mettre en place des outils d\u00e9taill\u00e9s alors que votre application pr\u00e9sente d\u00e9j\u00e0 des probl\u00e8mes majeurs visibles ne vaut peut-\u00eatre pas le coup. Cela peut m\u00eame vous surcharger de travail sur la dette, plut\u00f4t que de vous aider.<\/strong><\/p>\n\n\n\n

      SonarQube : centraliser les m\u00e9triques<\/h3>\n\n\n\n

      On a int\u00e9gr\u00e9 SonarQube<\/strong>, qui s’inscrit dans la continuit\u00e9 du Linter, mais avec des r\u00e8gles suppl\u00e9mentaires et une centralisation<\/strong> pour les v\u00e9rifications lors des PRs. L’avantage de la centralisation, c’est qu’on peut observer l’\u00e9volution \u00e0 travers le temps<\/strong>.<\/p>\n\n\n\n

      Attention aux indicateurs de fa\u00e7ade<\/strong> : prenez le temps de voir avec l’\u00e9quipe quels indicateurs permettront de comprendre que l’application s’am\u00e9liore r\u00e9ellement<\/strong>. Il n’y a rien de pire que de voir des indicateurs qui ne correspondent pas \u00e0 ce que l’on fait au quotidien.<\/p>\n\n\n\n

      Visualisateur de librairies : anticiper les blocages<\/h3>\n\n\n\n

      C’est un sujet qu’on n\u00e9glige souvent, et pourtant il peut devenir critique<\/strong>. Une librairie d\u00e9pr\u00e9ci\u00e9e, une d\u00e9pendance qui bloque une mont\u00e9e de version d’OS, une lib qui n’est plus maintenue\u2026 et soudain, vous \u00eates bloqu\u00e9s<\/strong>. Le business attend une feature, mais vous ne pouvez pas avancer sans d’abord r\u00e9gler ce probl\u00e8me technique.<\/p>\n\n\n\n

      L’id\u00e9e, c’est d’anticiper<\/strong>. Faites r\u00e9guli\u00e8rement un \u00e9tat des lieux de vos d\u00e9pendances :<\/p>\n\n\n\n

        \n
      • Librairies d\u00e9pr\u00e9ci\u00e9es<\/strong> : est-ce qu’une lib que vous utilisez n’est plus maintenue ? Plus vous attendez, plus la migration sera douloureuse<\/strong>.<\/li>\n\n\n\n
      • Blocages de mont\u00e9e de version<\/strong> : certaines libs peuvent vous emp\u00eacher de passer \u00e0 une nouvelle version d’iOS ou Android. Si vous ne les identifiez pas \u00e0 l’avance, vous d\u00e9couvrirez le probl\u00e8me au pire moment<\/strong>.<\/li>\n\n\n\n
      • Libs structurantes vs libs rempla\u00e7ables<\/strong> : une lib d’UI, \u00e7a se remplace. Une lib de navigation utilis\u00e9e partout, c’est un chantier de plusieurs mois<\/strong>. Identifiez lesquelles sont critiques.<\/li>\n\n\n\n
      • Licences et s\u00e9curit\u00e9<\/strong> : des libs avec des failles de s\u00e9curit\u00e9 connues ou des licences incompatibles peuvent devenir des bombes \u00e0 retardement<\/strong>.<\/li>\n<\/ul>\n\n\n\n

        Un point important : un choix de lib pertinent \u00e0 un instant T peut devenir obsol\u00e8te avec le temps<\/strong>. C’est exactement ce qu’on a v\u00e9cu avec l’arriv\u00e9e de Compose<\/strong> et SwiftUI<\/strong> c\u00f4t\u00e9 mobile. Des solutions qu’on avait choisies sont devenues legacy. On ne peut pas tout faire d’un coup. On note tout, on partage avec l’\u00e9quipe, et on se coordonne pour prioriser ensemble.<\/strong> Le pire sc\u00e9nario, c’est de d\u00e9couvrir qu’une lib bloque tout le jour o\u00f9 vous devez livrer une feature importante. Anticipez.<\/strong><\/p>\n\n\n\n

        Conseils pour cette phase<\/h2>\n\n\n\n

        Dans cette phase de compr\u00e9hension globale, vous aurez peut-\u00eatre l’impression d’\u00eatre sur tous les fronts<\/strong>. Prenez bien le temps de corriger un maximum de remont\u00e9es \u00e0 chaque outil ajout\u00e9, afin de garder un rythme de fond<\/strong>.<\/p>\n\n\n\n

        Laissez-vous la possibilit\u00e9 d’\u00e9voluer<\/strong> dans la fa\u00e7on dont vous g\u00e9rez les outils dans votre quotidien. Un outil et une fa\u00e7on d’interagir avec lui ne seront pas les m\u00eames dans cette phase que dans la pr\u00e9c\u00e9dente<\/strong>, ni dans la suivante. Votre compr\u00e9hension et vos besoins vont \u00e9voluer.<\/p>\n\n\n\n

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

        Cette phase demande de la patience<\/strong> et de la rigueur<\/strong>. Les choix architecturaux que vous faites ici auront un impact durable sur la maintenabilit\u00e9<\/strong> de votre projet. Prenez le temps de bien les r\u00e9fl\u00e9chir et de les aligner avec les enjeux business<\/strong> de votre entreprise.<\/p>\n\n\n\n

        Ce deuxi\u00e8me volet pr\u00e9pare le terrain pour le final de la s\u00e9rie. Si ces chantiers d’architecture r\u00e9sonnent avec votre contexte, la prochaine \u00e9tape consiste \u00e0 rendre visible la dette cach\u00e9e et \u00e0 la piloter sereinement.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

        Une fois qu’on conna\u00eet mieux un projet, on peut commencer \u00e0 se projeter. Pour nous, \u00e7a a \u00e9t\u00e9 au bout d’un an et demi. On a commenc\u00e9 \u00e0 penser \u00e0 comment adapter l’architecture c\u0153ur vers quelque chose qui nous faciliterait la vie dans le contexte de notre application. Ce deuxi\u00e8me volet passe de la d\u00e9couverte […]<\/p>\n","protected":false},"author":49,"featured_media":40977,"comment_status":"closed","ping_status":"closed","template":"","categorie_leocare_lab":[37],"class_list":["post-40976","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-2\/\" \/>\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=\"Une fois qu’on conna\u00eet mieux un projet, on peut commencer \u00e0 se projeter. Pour nous, \u00e7a a \u00e9t\u00e9 au bout d’un an et demi. On a commenc\u00e9 \u00e0 penser \u00e0 comment adapter l’architecture c\u0153ur vers quelque chose qui nous faciliterait la vie dans le contexte de notre application. Ce deuxi\u00e8me volet passe de la d\u00e9couverte […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-2\/\" \/>\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\/carton-fragile.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=\"Dur\u00e9e de lecture estim\u00e9e\" \/>\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-2\/","og_locale":"fr_FR","og_type":"article","og_title":"LeoLab","og_description":"Une fois qu’on conna\u00eet mieux un projet, on peut commencer \u00e0 se projeter. Pour nous, \u00e7a a \u00e9t\u00e9 au bout d’un an et demi. On a commenc\u00e9 \u00e0 penser \u00e0 comment adapter l’architecture c\u0153ur vers quelque chose qui nous faciliterait la vie dans le contexte de notre application. Ce deuxi\u00e8me volet passe de la d\u00e9couverte […]","og_url":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-2\/","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\/carton-fragile.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_misc":{"Dur\u00e9e de lecture estim\u00e9e":"9 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-2\/","url":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-2\/","name":"LeoLab","isPartOf":{"@id":"https:\/\/leocare.eu\/fr\/#website"},"primaryImageOfPage":{"@id":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-2\/#primaryimage"},"image":{"@id":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-2\/#primaryimage"},"thumbnailUrl":"https:\/\/leocare.eu\/fr\/wp-content\/uploads\/2026\/04\/carton-fragile.jpg","datePublished":"2026-04-29T06:00:00+00:00","breadcrumb":{"@id":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-2\/#breadcrumb"},"inLanguage":"fr-FR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-2\/"]}]},{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-2\/#primaryimage","url":"https:\/\/leocare.eu\/fr\/wp-content\/uploads\/2026\/04\/carton-fragile.jpg","contentUrl":"https:\/\/leocare.eu\/fr\/wp-content\/uploads\/2026\/04\/carton-fragile.jpg","width":800,"height":505,"caption":"carton fragile"},{"@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\/40976","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=40976"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/leocare.eu\/fr\/wp-json\/wp\/v2\/media\/40977"}],"wp:attachment":[{"href":"https:\/\/leocare.eu\/fr\/wp-json\/wp\/v2\/media?parent=40976"}],"wp:term":[{"taxonomy":"categorie_leocare_lab","embeddable":true,"href":"https:\/\/leocare.eu\/fr\/wp-json\/wp\/v2\/categorie_leocare_lab?post=40976"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}