{"id":40969,"date":"2026-04-15T08:00:00","date_gmt":"2026-04-15T06:00:00","guid":{"rendered":"https:\/\/leocare.eu\/fr\/?post_type=leocare_lab&p=40969"},"modified":"2026-04-01T23:10:36","modified_gmt":"2026-04-01T21:10:36","slug":"comment-resorber-sa-dette-technique-partie-1","status":"publish","type":"leocare_lab","link":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-1\/","title":{"rendered":"Comment r\u00e9sorber sa dette technique : poser le diagnostic (partie 1)"},"content":{"rendered":"\n

La d\u00e9couverte d’un projet est toujours une phase d\u00e9licate. On tombe sur des probl\u00e8mes qu’on ne comprend pas encore, on ne ma\u00eetrise rien, et \u00e7a fait peur. Pour les d\u00e9veloppeurs, la dette technique, c’est cet emprunt rapide<\/strong> qu’on contracte pour livrer un MVP ou tenir une deadline. Mais comme tout emprunt, elle vient avec des int\u00e9r\u00eats<\/strong> : du code difficile \u00e0 maintenir, une architecture qui s’essouffle, des d\u00e9cisions qu’on regrette dans le calme apr\u00e8s la temp\u00eate.<\/p>\n\n\n\n

Cet article ouvre une s\u00e9rie en trois volets sur la dette technique. On d\u00e9marre par la dette de surface<\/strong>, avant de plonger dans la dette profonde<\/strong> (partie 2), puis de mettre en lumi\u00e8re la dette cach\u00e9e<\/strong> (partie 3).<\/p>\n\n\n\n

Un disclaimer avant de commencer<\/strong> : chaque \u00e9quipe est diff\u00e9rente. Ne prenez pas ce qu’on a fait pour l’appliquer tel quel chez vous. L’important, c’est de comprendre les concepts derri\u00e8re : la gestion de la charge mentale, la priorisation, l’adaptation au contexte<\/strong>.<\/p>\n\n\n\n

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

C’est le genre de dette technique qui saute aux yeux<\/strong> quand on commence un nouveau projet ou qu’on int\u00e8gre un legacy. Vous voyez le tableau : des fonctions spaghetti de 500 lignes, une doc d\u00e9su\u00e8te ou manquante, des tests unitaires inexistants. Bref, c’est la poussi\u00e8re qu’on pousse sous le tapis pour shipper plus vite<\/strong>.<\/p>\n\n\n\n

\"code<\/figure>\n\n\n\n

Comment la rep\u00e9rer ?<\/h2>\n\n\n\n

D\u00e8s la prise en main d’un projet, le r\u00e9flexe devrait \u00eatre d’identifier ces dettes visibles<\/strong>, souvent caus\u00e9es par le rush initial ou l’absence de pratiques solides. La dette de surface, c’est un ensemble de signaux. Certains sont des classiques qu’on retrouve partout, d’autres sont plus subtils.<\/p>\n\n\n\n

Les classiques<\/h3>\n\n\n\n

On commence par les plus \u00e9vidents, ceux que vous rep\u00e9rerez d\u00e8s les premi\u00e8res heures pass\u00e9es dans le code :<\/p>\n\n\n\n

    \n
  • Code dupliqu\u00e9<\/strong> : \u00e7a sent le copier-coller \u00e0 plein nez, souvent pour acc\u00e9l\u00e9rer, mais au prix de la maintenabilit\u00e9.<\/li>\n\n\n\n
  • Manque de tests<\/strong> : d\u00e9velopper sans tests, c’est d\u00e9velopper dans le noir. Quand vous corrigez un bug, comment savez-vous que vous n’en cr\u00e9ez pas un autre ?<\/li>\n\n\n\n
  • Fonctions fourre-tout<\/strong> : ce n’est pas une fonctionnalit\u00e9, c’est un roman. Des fonctions de 500 lignes qui font tout et n’importe quoi.<\/li>\n<\/ul>\n\n\n\n

    Les signaux qu’on oublie souvent<\/h3>\n\n\n\n

    Ensuite, il y a des indicateurs plus discrets, mais tout aussi r\u00e9v\u00e9lateurs. Ce sont souvent eux qui trahissent un projet o\u00f9 la dette s’est install\u00e9e dans la dur\u00e9e :<\/p>\n\n\n\n

      \n
    • Nommage incoh\u00e9rent ou cryptique<\/strong> : des variables temp<\/code>, data<\/code>, x<\/code>, des fonctions handleStuff()<\/code> qui ne disent rien sur ce qu’elles font. Pire : des nommages qui mentent, comme une fonction getUser()<\/code> qui en fait modifie l’utilisateur. Le nommage, c’est la premi\u00e8re documentation du code.<\/strong><\/li>\n\n\n\n
    • Commentaires obsol\u00e8tes ou TODOs abandonn\u00e9s<\/strong> : un \/\/ TODO: fix this later<\/code> dat\u00e9 de 2019, un commentaire qui d\u00e9crit un comportement qui n’existe plus. Les commentaires fant\u00f4mes sont un signe que le code a \u00e9volu\u00e9 sans que personne ne prenne le temps de nettoyer<\/strong>.<\/li>\n\n\n\n
    • Gestion d’erreurs silencieuse<\/strong> : des try\/catch<\/code> vides, des erreurs aval\u00e9es sans log, des print(\"error\")<\/code> perdus dans le code. Quand quelque chose plante en prod, vous ne saurez jamais pourquoi<\/strong>. C’est une dette invisible jusqu’au jour o\u00f9 elle explose.<\/li>\n\n\n\n
    • Magic numbers et valeurs hardcod\u00e9es<\/strong> : des if (status == 3)<\/code> ou des timeout = 5000<\/code> sans explication. Qu’est-ce que 3<\/code> ? Pourquoi 5000<\/code> ? Ce genre de dette rend le code illisible et dangereux \u00e0 modifier<\/strong>.<\/li>\n\n\n\n
    • Inconsistance de style<\/strong> : un fichier en camelCase, l’autre en snake_case. Des tabs ici, des espaces l\u00e0. \u00c7a para\u00eet cosm\u00e9tique, mais \u00e7a r\u00e9v\u00e8le souvent un projet o\u00f9 chacun a cod\u00e9 dans son coin<\/strong> sans conventions communes.<\/li>\n<\/ul>\n\n\n\n

      Les signaux d’alerte organisationnels<\/h3>\n\n\n\n

      Au-del\u00e0 du code lui-m\u00eame, certains signaux rel\u00e8vent plus de l’organisation du projet. Ils sont souvent le sympt\u00f4me d’une dette qui s’est accumul\u00e9e faute de conventions partag\u00e9es :<\/p>\n\n\n\n

        \n
      • Fichiers ou classes gigantesques<\/strong> : un ViewController de 3000 lignes, un Utils.swift<\/code> fourre-tout o\u00f9 tout le monde ajoute ses fonctions. Ces fichiers deviennent des zones de conflit en \u00e9quipe et des nids \u00e0 bugs<\/strong>.<\/li>\n\n\n\n
      • D\u00e9pendances obsol\u00e8tes<\/strong> : des librairies qui n’ont pas \u00e9t\u00e9 mises \u00e0 jour depuis des ann\u00e9es, des warnings de d\u00e9pr\u00e9ciation ignor\u00e9s. Chaque mise \u00e0 jour repouss\u00e9e accumule de la dette.<\/strong> Et un jour, la migration devient un projet en soi.<\/li>\n\n\n\n
      • Documentation inexistante ou mensong\u00e8re<\/strong> : un README qui d\u00e9crit une architecture qui n’existe plus, des diagrammes datant de la v1. Une doc obsol\u00e8te est parfois pire que pas de doc<\/strong> : elle induit en erreur.<\/li>\n\n\n\n
      • Configuration \u00e9parpill\u00e9e<\/strong> : des constantes d\u00e9finies \u00e0 trois endroits diff\u00e9rents, des URLs d’API hardcod\u00e9es dans le code, des feature flags g\u00e9r\u00e9s n’importe comment. Quand vous devez changer un param\u00e8tre et que vous ne savez pas o\u00f9 chercher<\/strong>, c’est de la dette.<\/li>\n<\/ul>\n\n\n\n

        Le pi\u00e8ge : vouloir tout corriger<\/h2>\n\n\n\n

        Vous venez de lire tout \u00e7a et vous avez coch\u00e9 mentalement la moiti\u00e9 des points ? C’est normal. Tous les projets ont de la dette de surface.<\/strong> Le pi\u00e8ge, c’est de vouloir tout attaquer en m\u00eame temps.<\/p>\n\n\n\n

        Le plus dur quand on arrive sur un projet, c’est de r\u00e9sister \u00e0 l’envie de tout refaire<\/strong>. On rep\u00e8re des probl\u00e8mes partout et on veut les corriger imm\u00e9diatement. Prenez le temps de d\u00e9couvrir. Un fichier n’est pas test\u00e9 ? Un nommage est bizarre ? Ne vous dites pas automatiquement \u00ab\u00a0il faut corriger \u00e7a\u00a0\u00bb. Demandez-vous plut\u00f4t : est-ce que c’est la priorit\u00e9 dans le scope actuel ? Est-ce que \u00e7a bloque quelque chose ?<\/strong><\/p>\n\n\n\n

        L’id\u00e9e n’est pas de mettre ces probl\u00e8mes de c\u00f4t\u00e9, mais de les noter et les prioriser<\/strong>. Cr\u00e9ez-vous une liste, un board, peu importe. Mais ne gardez pas tout en t\u00eate. Une fois que vous avez s\u00e9curis\u00e9 les \u00e9l\u00e9ments critiques, le reste devient un fil rouge \u00e0 d\u00e9rouler au fur et \u00e0 mesure<\/strong>.<\/p>\n\n\n\n

        Spoiler : vous trouverez toujours de la dette. L’objectif n’est pas de l’\u00e9liminer, c’est de la g\u00e9rer.<\/strong><\/p>\n\n\n\n

        Notre exp\u00e9rience<\/h2>\n\n\n\n

        Dans cette premi\u00e8re phase, il ne faut pas penser trop vite que parce que les bugs sont durs \u00e0 corriger, il faut revoir toute l’application. De notre c\u00f4t\u00e9, au bout de 6 mois, on aurait pu se dire qu’il fallait tout refaire, parce que certains bugs prenaient plusieurs jours \u00e0 \u00eatre compris et corrig\u00e9s. Mais avec le recul, prendre le temps de comprendre un bug vous fait visualiser plus largement comment l’\u00e9viter par la suite<\/strong>.<\/p>\n\n\n\n

        Cela permet aussi de cr\u00e9er un maillage de probl\u00e8mes<\/strong> qui ram\u00e8nent souvent \u00e0 des groupements ciblant des parties sp\u00e9cifiques de l’application. On a refait des \u00e9crans en fonction de ce constat et commenc\u00e9 \u00e0 comprendre ce qui posait probl\u00e8me. On a d\u00e9cortiqu\u00e9 les probl\u00e8mes et surtout on les a document\u00e9s<\/strong>, ce qui a permis de classifier les bugs par th\u00e9matiques et parties de l’application, pour ensuite isoler les parties legacy des nouvelles.<\/p>\n\n\n\n

        Pour regrouper ces probl\u00e8mes, vous pouvez utiliser diff\u00e9rents angles de vue :<\/p>\n\n\n\n

          \n
        • L’angle business<\/strong> : quelles parties de l’application sont critiques pour l’entreprise ? O\u00f9 sont les parcours les plus utilis\u00e9s ?<\/li>\n\n\n\n
        • L’angle technique<\/strong> : qu’est-ce qui vous semble le plus bancal et dangereux dans le temps ? Quelles parties sont des bombes \u00e0 retardement ?<\/li>\n\n\n\n
        • L’angle temporel<\/strong> : qu’est-ce qui doit \u00eatre corrig\u00e9 \u00e0 court terme (bloquant), moyen terme (fragilit\u00e9), long terme (\u00e9volution) ?<\/li>\n<\/ul>\n\n\n\n

          Mixez ces angles selon vos besoins.<\/strong> Il n’y a pas de formule magique. C’est votre compr\u00e9hension du projet qui fera la diff\u00e9rence.<\/p>\n\n\n\n

          Ne jamais refaire l’application de z\u00e9ro<\/h2>\n\n\n\n

          Dans notre strat\u00e9gie en \u00e9quipe, nous avions d\u00e9cid\u00e9 de ne jamais refaire l’application de z\u00e9ro<\/strong>. Un challenge pas facile, mais qui nous a fait grandir dans la compr\u00e9hension des diff\u00e9rentes parties. Certaines applications ne pourraient pas appliquer cette strat\u00e9gie, mais c’est une approche qui m’a fait \u00e9voluer dans ma m\u00e9thodologie<\/strong> pour comprendre du code rapidement et refactoriser en isolant les parties legacy.<\/p>\n\n\n\n

          \"angles<\/figure>\n\n\n\n

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

          Voici les outils qu’on a mis en place pendant cette premi\u00e8re phase, chacun avec un r\u00f4le pr\u00e9cis dans notre strat\u00e9gie de r\u00e9duction de la dette :<\/p>\n\n\n\n

          Outil<\/th>But \/ Mission<\/th><\/tr><\/thead>
          Audit (slides avec screenshots)<\/strong><\/td>Parcourir l’application et faire des retours sur le comportement, que ce soit fonctionnel ou visuel.<\/td><\/tr>
          SwiftLint (linter)<\/strong><\/td>Mettre en place un formalisme de code commun. Mis en place en it\u00e9ration : d’abord quelques r\u00e8gles, puis activation progressive apr\u00e8s avoir fix\u00e9 les pr\u00e9c\u00e9dentes.<\/td><\/tr>
          Logs syst\u00e8me<\/strong><\/td>Permettre de mieux debug les erreurs de l’application et mieux remonter ce qui pose probl\u00e8me.<\/td><\/tr>
          Documentation des bugs<\/strong><\/td>Comprendre l’application et r\u00e9ussir \u00e0 grouper les bugs et les parties qui posent le plus de probl\u00e8mes pour prioriser les refacts.<\/td><\/tr>
          Firebase Crashlytics<\/strong><\/td>Suivre les crashs en production et prioriser les corrections.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

          Le Linter : une mise en place progressive<\/h3>\n\n\n\n

          La premi\u00e8re chose qu’on a mise en place \u00e0 la reprise du projet, c’est SwiftLint pour iOS<\/strong>. On a \u00e9labor\u00e9 une strat\u00e9gie qui nous a permis d’activer les r\u00e8gles de code petit \u00e0 petit<\/strong>. Pas tout d’un coup, car le projet \u00e9tait enti\u00e8rement en rouge. D’abord une ou deux r\u00e8gles prioritaires qui passaient sans trop de modifications. Ensuite, des points r\u00e9guliers, souvent post-release, pour activer de nouvelles r\u00e8gles au fur et \u00e0 mesure qu’on corrigeait les pr\u00e9c\u00e9dentes. Cela a permis une am\u00e9lioration constante et satisfaisante.<\/strong><\/p>\n\n\n\n

          C’est l\u00e0 qu’intervient le concept de fil rouge<\/strong>. Une fois qu’un outil est en place, on peut faire du suivi et corriger au fur et \u00e0 mesure. On se retrouve \u00e0 faire des petites am\u00e9liorations constantes plut\u00f4t que des gros chantiers intimidants<\/strong>. C’est plus digeste pour l’\u00e9quipe, et \u00e7a cr\u00e9e une dynamique d’am\u00e9lioration continue<\/strong>.<\/p>\n\n\n\n

          Firebase Crashlytics : prioriser gr\u00e2ce aux donn\u00e9es<\/h3>\n\n\n\n

          On a branch\u00e9 le syst\u00e8me de d\u00e9tection de crash dans Firebase Crashlytics<\/strong> pour avoir des remont\u00e9es des crashs utilisateurs et pouvoir les flaguer une fois corrig\u00e9s. \u00c7a montre les endroits posant le plus de probl\u00e8mes<\/strong> et \u00e7a aide \u00e0 prioriser une roadmap en voyant les probl\u00e8mes et leur fr\u00e9quence.<\/p>\n\n\n\n

          Un point important : la dette technique, pour la plupart des gens, ce n’est pas tangible<\/strong>. Il y a une forme de p\u00e9dagogie \u00e0 avoir avec les autres \u00e9quipes pour faire comprendre le niveau de dette d’une plateforme. Si vous proposez des refontes r\u00e9currentes sans trop de vision de ce qui ne va pas, il y aura une perte de confiance<\/strong>, et \u00e7a peut \u00eatre dur d’amener d’autres changements ensuite.<\/p>\n\n\n\n

          Les logs : ne pas n\u00e9gliger le debugging<\/h3>\n\n\n\n

          Pour bien d\u00e9bugger, vous avez besoin de mettre des logs pertinents<\/strong> dans votre application. \u00c7a a \u00e9t\u00e9 de pair avec Crashlytics, car on a travaill\u00e9 \u00e0 faire des remont\u00e9es Non Fatal<\/strong> des erreurs via Crashlytics. Prenez le temps de mettre ces logs dans les nouvelles parties comme dans les parties legacy.<\/p>\n\n\n\n

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

          Chaque projet est diff\u00e9rent. Prenez le temps d’analyser les choses<\/strong> et ne foncez pas trop vite dans les choix de refaire telle ou telle partie. C’est une question de vision d’entreprise et de discussions avec l’\u00e9quipe. Trouvez comment aligner tout le monde sur les probl\u00e8mes<\/strong>.<\/p>\n\n\n\n

          On a tous envie de mettre en place ce qu’on a vu dans une entreprise pr\u00e9c\u00e9dente, mais se poser et comprendre le code et ses probl\u00e8mes<\/strong> vous fera adapter vos solutions \u00e0 la situation plut\u00f4t que d’appliquer quelque chose de g\u00e9n\u00e9rique. Chaque entreprise est diff\u00e9rente, chaque projet est diff\u00e9rent, et surtout l’humain est important.<\/strong><\/p>\n\n\n\n

          Ne vous battez pas pour une solution. Exposez les probl\u00e9matiques<\/strong>, les diff\u00e9rents choix qui s’offrent \u00e0 vous, notez les avantages et inconv\u00e9nients. Vous verrez, le choix collectif sera plus facile<\/strong>. Et si vous vous retrouvez seul face \u00e0 l’\u00e9quipe sur un choix de refactoring, ne vous d\u00e9couragez pas. Proposez plut\u00f4t de poser les choses \u00e0 plat : est-ce que tout le monde a bien compris le probl\u00e8me remont\u00e9 ? Son impact ?<\/p>\n\n\n\n

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

          La d\u00e9couverte d’un projet, que l’on soit junior ou exp\u00e9riment\u00e9, commence toujours par apprendre<\/strong>. Apprendre comment fonctionne l’application, mais pas que. Apprenez aussi \u00e0 conna\u00eetre les personnes avec qui vous travaillez : qui conna\u00eet quelle partie du code ? Qui a l’historique des d\u00e9cisions pass\u00e9es ?<\/p>\n\n\n\n

          \"process<\/figure>\n\n\n\n

          Cette phase est cruciale pour poser les bases d’une gestion saine de la dette technique<\/strong>. Le code, c’est une chose. Les humains qui le maintiennent, c’en est une autre. Et les deux comptent autant.<\/strong><\/p>\n\n\n\n

          Pour poursuivre la s\u00e9rie, rendez-vous sur le prochain volet qui explore la dette profonde et structurante, et comment adapter l’architecture sans tout casser.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

          La d\u00e9couverte d’un projet est toujours une phase d\u00e9licate. On tombe sur des probl\u00e8mes qu’on ne comprend pas encore, on ne ma\u00eetrise rien, et \u00e7a fait peur. Pour les d\u00e9veloppeurs, la dette technique, c’est cet emprunt rapide qu’on contracte pour livrer un MVP ou tenir une deadline. Mais comme tout emprunt, elle vient avec des […]<\/p>\n","protected":false},"author":49,"featured_media":40970,"comment_status":"closed","ping_status":"closed","template":"","categorie_leocare_lab":[37],"class_list":["post-40969","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-1\/\" \/>\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=\"La d\u00e9couverte d’un projet est toujours une phase d\u00e9licate. On tombe sur des probl\u00e8mes qu’on ne comprend pas encore, on ne ma\u00eetrise rien, et \u00e7a fait peur. Pour les d\u00e9veloppeurs, la dette technique, c’est cet emprunt rapide qu’on contracte pour livrer un MVP ou tenir une deadline. Mais comme tout emprunt, elle vient avec des […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-1\/\" \/>\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\/computer-code.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=\"10 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-1\/","og_locale":"fr_FR","og_type":"article","og_title":"LeoLab","og_description":"La d\u00e9couverte d’un projet est toujours une phase d\u00e9licate. On tombe sur des probl\u00e8mes qu’on ne comprend pas encore, on ne ma\u00eetrise rien, et \u00e7a fait peur. Pour les d\u00e9veloppeurs, la dette technique, c’est cet emprunt rapide qu’on contracte pour livrer un MVP ou tenir une deadline. Mais comme tout emprunt, elle vient avec des […]","og_url":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-1\/","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\/computer-code.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_misc":{"Dur\u00e9e de lecture estim\u00e9e":"10 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-1\/","url":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-1\/","name":"LeoLab","isPartOf":{"@id":"https:\/\/leocare.eu\/fr\/#website"},"primaryImageOfPage":{"@id":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-1\/#primaryimage"},"image":{"@id":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-1\/#primaryimage"},"thumbnailUrl":"https:\/\/leocare.eu\/fr\/wp-content\/uploads\/2026\/04\/computer-code.jpg","datePublished":"2026-04-15T06:00:00+00:00","breadcrumb":{"@id":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-1\/#breadcrumb"},"inLanguage":"fr-FR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-1\/"]}]},{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/leocare.eu\/fr\/leocare-lab\/comment-resorber-sa-dette-technique-partie-1\/#primaryimage","url":"https:\/\/leocare.eu\/fr\/wp-content\/uploads\/2026\/04\/computer-code.jpg","contentUrl":"https:\/\/leocare.eu\/fr\/wp-content\/uploads\/2026\/04\/computer-code.jpg","width":800,"height":505,"caption":"computer code"},{"@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\/40969","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=40969"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/leocare.eu\/fr\/wp-json\/wp\/v2\/media\/40970"}],"wp:attachment":[{"href":"https:\/\/leocare.eu\/fr\/wp-json\/wp\/v2\/media?parent=40969"}],"wp:term":[{"taxonomy":"categorie_leocare_lab","embeddable":true,"href":"https:\/\/leocare.eu\/fr\/wp-json\/wp\/v2\/categorie_leocare_lab?post=40969"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}