[{"data":1,"prerenderedAt":1587},["ShallowReactive",2],{"search-api":-1,"listing-tag-Refactoring-page-1":3},[4,869],{"_path":5,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":9,"description":10,"id":11,"date":12,"listed":13,"nocomments":7,"hidden":7,"categories":14,"tags":15,"--cover":19,"readingTime":20,"body":25,"_type":863,"_id":864,"_source":865,"_file":866,"_stem":867,"_extension":868},"/fr/dette-technique/programme-refactoring-approuve-business","dette-technique",false,"","Comment créer un programme de refactoring approuvé par le business","Le refactoring refusé par le business n'est pas un problème technique : c'est un problème de présentation. Construire le business case qui obtient le feu vert.",16,"2026-02-09",true,[6],[16,17,18],"Refactoring","Business Case","Management","covers/articles/refactoring-business-case.jpg",{"text":21,"minutes":22,"time":23,"words":24},"7 min read",6.88,412800,1376,{"type":26,"children":27,"toc":852},"root",[28,36,42,51,56,60,67,94,97,103,120,125,130,153,163,194,199,209,212,218,233,238,256,266,275,404,414,423,426,439,442,448,453,462,471,489,498,516,525,543,553,562,565,571,576,638,648,651,657,666,669,675,774,777,783,798,811,824,837,840],{"type":29,"tag":30,"props":31,"children":33},"element","h1",{"id":32},"comment-créer-un-programme-de-refactoring-approuvé-par-le-business",[34],{"type":35,"value":9},"text",{"type":29,"tag":37,"props":38,"children":39},"p",{},[40],{"type":35,"value":41},"Il y a quelques années, j'accompagnais le CTO d'une société de gestion d'épargne, avec une équipe de 20 développeurs. Il venait de se faire refuser pour la troisième fois un programme de refactoring sur leur module de calcul de rendement. Sa présentation était techniquement parfaite : complexité cyclomatique, taux de duplication, nombre de hotspots SonarQube. Le CPO l'avait écouté poliment puis avait dit : \"Je comprends que c'est important pour toi, mais on a la roadmap à tenir.\" Ce n'était pas un refus du business face à la technique. C'était un professionnel qui ne voyait pas son problème dans ce que l'autre lui présentait.",{"type":29,"tag":37,"props":43,"children":44},{},[45],{"type":29,"tag":46,"props":47,"children":48},"strong",{},[49],{"type":35,"value":50},"\"On a besoin de 3 mois pour refactoriser le core.\" Réponse du CPO : \"Pas maintenant, on a la roadmap feature à tenir.\" Cette conversation se joue dans 80% des entreprises tech. Et dans 80% des cas, c'est l'équipe technique qui présente mal, pas le business qui refuse mal.",{"type":29,"tag":37,"props":52,"children":53},{},[54],{"type":35,"value":55},"Le business ne comprend pas \"refactoring\". Il comprend \"coût\", \"risque\", \"délai\", et \"avantage concurrentiel\". Tant que vous présentez un projet technique dans un langage technique, vous demandez au business de vous faire confiance sur un sujet qu'il ne maîtrise pas. Ce n'est pas raisonnable, et ce n'est pas sa faute.",{"type":29,"tag":57,"props":58,"children":59},"hr",{},[],{"type":29,"tag":61,"props":62,"children":64},"h2",{"id":63},"avant-de-commencer-les-prérequis",[65],{"type":35,"value":66},"Avant de commencer : les prérequis",{"type":29,"tag":68,"props":69,"children":70},"ul",{},[71,84,89],{"type":29,"tag":72,"props":73,"children":74},"li",{},[75,77],{"type":35,"value":76},"Vous avez identifié le périmètre du refactoring (module, couche, ou composant spécifique, si ce n'est pas encore fait, commencez par ",{"type":29,"tag":78,"props":79,"children":81},"a",{"href":80},"/fr/dette-technique/legacy-code-evaluer-risque",[82],{"type":35,"value":83},"évaluer le risque du code legacy",{"type":29,"tag":72,"props":85,"children":86},{},[87],{"type":35,"value":88},"Vous avez une estimation grossière de l'effort technique (order of magnitude : semaines, pas jours)",{"type":29,"tag":72,"props":90,"children":91},{},[92],{"type":35,"value":93},"Vous avez accès aux métriques de base : lead time, taux de bugs, temps passé en maintenance",{"type":29,"tag":57,"props":95,"children":96},{},[],{"type":29,"tag":61,"props":98,"children":100},{"id":99},"étape-1-quantifier-le-coût-actuel-pas-leffort-de-refactoring",[101],{"type":35,"value":102},"Étape 1 : Quantifier le coût actuel, pas l'effort de refactoring",{"type":29,"tag":37,"props":104,"children":105},{},[106,111,113,118],{"type":29,"tag":46,"props":107,"children":108},{},[109],{"type":35,"value":110},"Durée estimée",{"type":35,"value":112}," : 4 heures\n",{"type":29,"tag":46,"props":114,"children":115},{},[116],{"type":35,"value":117},"Qui",{"type":35,"value":119}," : Tech Lead + 1 développeur senior",{"type":29,"tag":37,"props":121,"children":122},{},[123],{"type":35,"value":124},"C'est l'étape que la plupart des équipes sautent. Elles présentent l'effort du refactoring sans jamais quantifier le coût de l'inaction.",{"type":29,"tag":37,"props":126,"children":127},{},[128],{"type":35,"value":129},"Questions à chiffrer :",{"type":29,"tag":68,"props":131,"children":132},{},[133,138,143,148],{"type":29,"tag":72,"props":134,"children":135},{},[136],{"type":35,"value":137},"Quel pourcentage du temps de l'équipe est consacré à la maintenance de ce module ?",{"type":29,"tag":72,"props":139,"children":140},{},[141],{"type":35,"value":142},"Combien d'incidents de prod ce module a-t-il causés les 6 derniers mois ?",{"type":29,"tag":72,"props":144,"children":145},{},[146],{"type":35,"value":147},"Quel est le lead time pour une modification simple dans ce module vs un module sain ?",{"type":29,"tag":72,"props":149,"children":150},{},[151],{"type":35,"value":152},"Combien de développeurs ont quitté l'équipe en citant \"la dette technique\" dans leur entretien de sortie ?",{"type":29,"tag":37,"props":154,"children":155},{},[156,161],{"type":29,"tag":46,"props":157,"children":158},{},[159],{"type":35,"value":160},"Calcul type",{"type":35,"value":162}," :",{"type":29,"tag":68,"props":164,"children":165},{},[166,176,186],{"type":29,"tag":72,"props":167,"children":168},{},[169,171],{"type":35,"value":170},"Équipe de 20 développeurs × 40% d'absorption sur ce module × 450€/jour × 220 jours = ",{"type":29,"tag":46,"props":172,"children":173},{},[174],{"type":35,"value":175},"792 000€/an",{"type":29,"tag":72,"props":177,"children":178},{},[179,181],{"type":35,"value":180},"3 incidents P1 × 80 000€ d'impact moyen = ",{"type":29,"tag":46,"props":182,"children":183},{},[184],{"type":35,"value":185},"240 000€/an",{"type":29,"tag":72,"props":187,"children":188},{},[189],{"type":29,"tag":46,"props":190,"children":191},{},[192],{"type":35,"value":193},"Coût total de l'inaction : ~1 000 000€/an",{"type":29,"tag":37,"props":195,"children":196},{},[197],{"type":35,"value":198},"Ce chiffre est le fondement du business case. Sans lui, vous demandez un investissement sans montrer le retour. Avec lui, vous parlez la même langue que votre interlocuteur.",{"type":29,"tag":37,"props":200,"children":201},{},[202,207],{"type":29,"tag":46,"props":203,"children":204},{},[205],{"type":35,"value":206},"Résultat attendu",{"type":35,"value":208}," : un tableur avec les coûts actuels quantifiés, prêt à être présenté.",{"type":29,"tag":57,"props":210,"children":211},{},[],{"type":29,"tag":61,"props":213,"children":215},{"id":214},"étape-2-construire-le-roi-en-langage-business",[216],{"type":35,"value":217},"Étape 2 : Construire le ROI en langage business",{"type":29,"tag":37,"props":219,"children":220},{},[221,225,227,231],{"type":29,"tag":46,"props":222,"children":223},{},[224],{"type":35,"value":110},{"type":35,"value":226}," : 3 heures\n",{"type":29,"tag":46,"props":228,"children":229},{},[230],{"type":35,"value":117},{"type":35,"value":232}," : CTO + Tech Lead",{"type":29,"tag":37,"props":234,"children":235},{},[236],{"type":35,"value":237},"Le ROI d'un programme de refactoring a deux composantes :",{"type":29,"tag":37,"props":239,"children":240},{},[241,246,248,254],{"type":29,"tag":46,"props":242,"children":243},{},[244],{"type":35,"value":245},"Composante 1 : Réduction des coûts",{"type":35,"value":247}," : si le refactoring réduit l'",{"type":29,"tag":78,"props":249,"children":251},{"href":250},"/fr/dette-technique/introduction-maturite-engineering-5-niveaux",[252],{"type":35,"value":253},"absorption de 40% à 20%",{"type":35,"value":255},", vous récupérez 50% du coût de l'inaction. Sur l'exemple précédent : 500 000€/an récupérés.",{"type":29,"tag":37,"props":257,"children":258},{},[259,264],{"type":29,"tag":46,"props":260,"children":261},{},[262],{"type":35,"value":263},"Composante 2 : Accélération business",{"type":35,"value":265}," : le lead time divisé par 2 ou 3 signifie que les features arrivent plus vite sur le marché. Chiffrez-le en termes de features livrées par trimestre ou de time-to-market sur vos initiatives stratégiques.",{"type":29,"tag":37,"props":267,"children":268},{},[269,274],{"type":29,"tag":46,"props":270,"children":271},{},[272],{"type":35,"value":273},"Format de présentation pour le board",{"type":35,"value":162},{"type":29,"tag":276,"props":277,"children":278},"table",{},[279,301],{"type":29,"tag":280,"props":281,"children":282},"thead",{},[283],{"type":29,"tag":284,"props":285,"children":286},"tr",{},[287,291,296],{"type":29,"tag":288,"props":289,"children":290},"th",{},[],{"type":29,"tag":288,"props":292,"children":293},{},[294],{"type":35,"value":295},"Scénario actuel",{"type":29,"tag":288,"props":297,"children":298},{},[299],{"type":35,"value":300},"Après refactoring",{"type":29,"tag":302,"props":303,"children":304},"tbody",{},[305,324,346,364,382],{"type":29,"tag":284,"props":306,"children":307},{},[308,314,319],{"type":29,"tag":309,"props":310,"children":311},"td",{},[312],{"type":35,"value":313},"Absorption maintenance",{"type":29,"tag":309,"props":315,"children":316},{},[317],{"type":35,"value":318},"40%",{"type":29,"tag":309,"props":320,"children":321},{},[322],{"type":35,"value":323},"20%",{"type":29,"tag":284,"props":325,"children":326},{},[327,336,341],{"type":29,"tag":309,"props":328,"children":329},{},[330],{"type":29,"tag":78,"props":331,"children":333},{"href":332},"/fr/pratiques-agiles/reduire-work-in-progress-velocite",[334],{"type":35,"value":335},"Lead time moyen",{"type":29,"tag":309,"props":337,"children":338},{},[339],{"type":35,"value":340},"4 semaines",{"type":29,"tag":309,"props":342,"children":343},{},[344],{"type":35,"value":345},"2 semaines",{"type":29,"tag":284,"props":347,"children":348},{},[349,354,359],{"type":29,"tag":309,"props":350,"children":351},{},[352],{"type":35,"value":353},"Incidents P1/an",{"type":29,"tag":309,"props":355,"children":356},{},[357],{"type":35,"value":358},"6",{"type":29,"tag":309,"props":360,"children":361},{},[362],{"type":35,"value":363},"1-2",{"type":29,"tag":284,"props":365,"children":366},{},[367,372,377],{"type":29,"tag":309,"props":368,"children":369},{},[370],{"type":35,"value":371},"Coût annuel estimé",{"type":29,"tag":309,"props":373,"children":374},{},[375],{"type":35,"value":376},"1 000 000€",{"type":29,"tag":309,"props":378,"children":379},{},[380],{"type":35,"value":381},"400 000€",{"type":29,"tag":284,"props":383,"children":384},{},[385,393,396],{"type":29,"tag":309,"props":386,"children":387},{},[388],{"type":29,"tag":46,"props":389,"children":390},{},[391],{"type":35,"value":392},"Économie annuelle",{"type":29,"tag":309,"props":394,"children":395},{},[],{"type":29,"tag":309,"props":397,"children":398},{},[399],{"type":29,"tag":46,"props":400,"children":401},{},[402],{"type":35,"value":403},"600 000€",{"type":29,"tag":37,"props":405,"children":406},{},[407,409],{"type":35,"value":408},"Investissement programme : 200 000€ (3 mois, 4 développeurs). ",{"type":29,"tag":46,"props":410,"children":411},{},[412],{"type":35,"value":413},"ROI : 3 mois.",{"type":29,"tag":37,"props":415,"children":416},{},[417,421],{"type":29,"tag":46,"props":418,"children":419},{},[420],{"type":35,"value":206},{"type":35,"value":422}," : un slide ou un tableau de 1 page qui montre le ROI clairement.",{"type":29,"tag":57,"props":424,"children":425},{},[],{"type":29,"tag":427,"props":428,"children":433},"cta",{"cta":429,"href":430,"title":431,"type":432},"Réserver mon diagnostic gratuit →","https://app.kamanga.fr/forms/discovery-call","Votre programme de refactoring est bloqué faute de budget approuvé ?","call",[434],{"type":29,"tag":37,"props":435,"children":436},{},[437],{"type":35,"value":438},"Vous avez la conviction technique, vous voyez le coût s'accumuler chaque mois, mais vous n'arrivez pas à obtenir le feu vert. Ce n'est pas un problème de légitimité, c'est un problème de présentation. En 30 minutes, je vous aide à construire les chiffres clés et la structure de présentation qui débloque le budget dans votre contexte.",{"type":29,"tag":57,"props":440,"children":441},{},[],{"type":29,"tag":61,"props":443,"children":445},{"id":444},"étape-3-proposer-un-plan-en-3-phases-avec-quick-wins",[446],{"type":35,"value":447},"Étape 3 : Proposer un plan en 3 phases avec quick wins",{"type":29,"tag":37,"props":449,"children":450},{},[451],{"type":35,"value":452},"Le business est rassuré par les quick wins. Un programme de 6 mois qui ne livre rien de visible pendant 6 mois est un programme à haut risque perçu.",{"type":29,"tag":37,"props":454,"children":455},{},[456,461],{"type":29,"tag":46,"props":457,"children":458},{},[459],{"type":35,"value":460},"Structure recommandée en 3 phases",{"type":35,"value":162},{"type":29,"tag":37,"props":463,"children":464},{},[465,470],{"type":29,"tag":46,"props":466,"children":467},{},[468],{"type":35,"value":469},"Phase 1 (4-6 semaines) : Stabilisation et quick wins",{"type":35,"value":162},{"type":29,"tag":68,"props":472,"children":473},{},[474,479,484],{"type":29,"tag":72,"props":475,"children":476},{},[477],{"type":35,"value":478},"Objectif : réduire les incidents de prod immédiats",{"type":29,"tag":72,"props":480,"children":481},{},[482],{"type":35,"value":483},"Livrable visible : réduction du taux d'incidents de 50%",{"type":29,"tag":72,"props":485,"children":486},{},[487],{"type":35,"value":488},"Investissement : 20% de la capacité de l'équipe",{"type":29,"tag":37,"props":490,"children":491},{},[492,497],{"type":29,"tag":46,"props":493,"children":494},{},[495],{"type":35,"value":496},"Phase 2 (6-8 semaines) : Refactoring structurel",{"type":35,"value":162},{"type":29,"tag":68,"props":499,"children":500},{},[501,506,511],{"type":29,"tag":72,"props":502,"children":503},{},[504],{"type":35,"value":505},"Objectif : réduire l'absorption de la dette",{"type":29,"tag":72,"props":507,"children":508},{},[509],{"type":35,"value":510},"Livrable visible : le lead time sur le module cible commence à baisser",{"type":29,"tag":72,"props":512,"children":513},{},[514],{"type":35,"value":515},"Investissement : 30-40% de la capacité",{"type":29,"tag":37,"props":517,"children":518},{},[519,524],{"type":29,"tag":46,"props":520,"children":521},{},[522],{"type":35,"value":523},"Phase 3 (4-6 semaines) : Consolidation et transfert",{"type":35,"value":162},{"type":29,"tag":68,"props":526,"children":527},{},[528,533,538],{"type":29,"tag":72,"props":529,"children":530},{},[531],{"type":35,"value":532},"Objectif : documenter, tester, former l'équipe sur les nouveaux patterns",{"type":29,"tag":72,"props":534,"children":535},{},[536],{"type":35,"value":537},"Livrable visible : les autres équipes peuvent modifier le module sans accompagnement",{"type":29,"tag":72,"props":539,"children":540},{},[541],{"type":35,"value":542},"Investissement : 20% de la capacité",{"type":29,"tag":37,"props":544,"children":545},{},[546,551],{"type":29,"tag":46,"props":547,"children":548},{},[549],{"type":35,"value":550},"L'argument clé",{"type":35,"value":552}," : les features continuent de sortir pendant tout le programme. Ce n'est pas un arrêt, c'est une réallocation partielle et temporaire. C'est précisément ce que la théorie des contraintes de Goldratt préconise : traiter le goulot d'étranglement en maintenant le flux global.",{"type":29,"tag":37,"props":554,"children":555},{},[556,560],{"type":29,"tag":46,"props":557,"children":558},{},[559],{"type":35,"value":206},{"type":35,"value":561}," : un plan de 3 phases avec les livrables visibles à chaque étape.",{"type":29,"tag":57,"props":563,"children":564},{},[],{"type":29,"tag":61,"props":566,"children":568},{"id":567},"étape-4-le-pitch-de-10-minutes-qui-obtient-le-budget",[569],{"type":35,"value":570},"Étape 4 : Le pitch de 10 minutes qui obtient le budget",{"type":29,"tag":37,"props":572,"children":573},{},[574],{"type":35,"value":575},"Structure du pitch :",{"type":29,"tag":577,"props":578,"children":579},"ol",{},[580,590,600,610,620],{"type":29,"tag":72,"props":581,"children":582},{},[583,588],{"type":29,"tag":46,"props":584,"children":585},{},[586],{"type":35,"value":587},"L'enjeu",{"type":35,"value":589}," (2 min) : \"Notre module X nous coûte 1M€/an. Voici les chiffres.\"",{"type":29,"tag":72,"props":591,"children":592},{},[593,598],{"type":29,"tag":46,"props":594,"children":595},{},[596],{"type":35,"value":597},"Le diagnostic",{"type":35,"value":599}," (2 min) : \"Voici pourquoi il coûte autant et pourquoi ça va empirer.\"",{"type":29,"tag":72,"props":601,"children":602},{},[603,608],{"type":29,"tag":46,"props":604,"children":605},{},[606],{"type":35,"value":607},"La solution",{"type":35,"value":609}," (2 min) : \"Un programme de 3 mois, 3 phases, qui continue à livrer des features.\"",{"type":29,"tag":72,"props":611,"children":612},{},[613,618],{"type":29,"tag":46,"props":614,"children":615},{},[616],{"type":35,"value":617},"Le ROI",{"type":35,"value":619}," (2 min) : \"Investissement : 200K€. Économie annuelle : 600K€. Retour en 3 mois.\"",{"type":29,"tag":72,"props":621,"children":622},{},[623,628,630,636],{"type":29,"tag":46,"props":624,"children":625},{},[626],{"type":35,"value":627},"La décision demandée",{"type":35,"value":629}," (2 min) : \"On a besoin de votre feu vert pour allouer 30% de la capacité de l'équipe pendant 3 mois, à partir du ",{"type":29,"tag":631,"props":632,"children":633},"span",{},[634],{"type":35,"value":635},"date",{"type":35,"value":637},".\"",{"type":29,"tag":37,"props":639,"children":640},{},[641,646],{"type":29,"tag":46,"props":642,"children":643},{},[644],{"type":35,"value":645},"Ce qu'il ne faut surtout pas dire",{"type":35,"value":647}," : \"On a besoin de payer la dette technique.\" C'est une phrase technique sans signification financière. Remplacez-la par : \"On a besoin de réduire notre coût opérationnel de 600K€/an.\" Ce n'est pas du spin, c'est la même réalité exprimée dans la langue de votre interlocuteur.",{"type":29,"tag":57,"props":649,"children":650},{},[],{"type":29,"tag":61,"props":652,"children":654},{"id":653},"le-piège-à-éviter",[655],{"type":35,"value":656},"Le piège à éviter",{"type":29,"tag":658,"props":659,"children":660},"blockquote",{},[661],{"type":29,"tag":37,"props":662,"children":663},{},[664],{"type":35,"value":665},"Ne promettre jamais une réduction de 100% de la dette. Je promets des améliorations mesurables sur des métriques spécifiques. Un programme qui promet \"tout refactoriser\" ne sera jamais terminé et perdra la confiance du business. Un programme qui promet \"réduire les incidents P1 de 6 à 2 par an sur le module X en 3 mois\" est vérifiable et crédible.",{"type":29,"tag":57,"props":667,"children":668},{},[],{"type":29,"tag":61,"props":670,"children":672},{"id":671},"en-résumé",[673],{"type":35,"value":674},"En résumé",{"type":29,"tag":276,"props":676,"children":677},{},[678,699],{"type":29,"tag":280,"props":679,"children":680},{},[681],{"type":29,"tag":284,"props":682,"children":683},{},[684,689,694],{"type":29,"tag":288,"props":685,"children":686},{},[687],{"type":35,"value":688},"Étape",{"type":29,"tag":288,"props":690,"children":691},{},[692],{"type":35,"value":693},"Action",{"type":29,"tag":288,"props":695,"children":696},{},[697],{"type":35,"value":698},"Résultat",{"type":29,"tag":302,"props":700,"children":701},{},[702,720,738,756],{"type":29,"tag":284,"props":703,"children":704},{},[705,710,715],{"type":29,"tag":309,"props":706,"children":707},{},[708],{"type":35,"value":709},"1",{"type":29,"tag":309,"props":711,"children":712},{},[713],{"type":35,"value":714},"Quantifier le coût actuel de l'inaction",{"type":29,"tag":309,"props":716,"children":717},{},[718],{"type":35,"value":719},"Chiffres prêts pour le business case",{"type":29,"tag":284,"props":721,"children":722},{},[723,728,733],{"type":29,"tag":309,"props":724,"children":725},{},[726],{"type":35,"value":727},"2",{"type":29,"tag":309,"props":729,"children":730},{},[731],{"type":35,"value":732},"Construire le ROI en langage financier",{"type":29,"tag":309,"props":734,"children":735},{},[736],{"type":35,"value":737},"Slide de ROI en 1 page",{"type":29,"tag":284,"props":739,"children":740},{},[741,746,751],{"type":29,"tag":309,"props":742,"children":743},{},[744],{"type":35,"value":745},"3",{"type":29,"tag":309,"props":747,"children":748},{},[749],{"type":35,"value":750},"Plan en 3 phases avec quick wins visibles",{"type":29,"tag":309,"props":752,"children":753},{},[754],{"type":35,"value":755},"Programme crédible sans arrêt des features",{"type":29,"tag":284,"props":757,"children":758},{},[759,764,769],{"type":29,"tag":309,"props":760,"children":761},{},[762],{"type":35,"value":763},"4",{"type":29,"tag":309,"props":765,"children":766},{},[767],{"type":35,"value":768},"Pitch de 10 minutes structuré",{"type":29,"tag":309,"props":770,"children":771},{},[772],{"type":35,"value":773},"Feu vert et budget alloué",{"type":29,"tag":57,"props":775,"children":776},{},[],{"type":29,"tag":61,"props":778,"children":780},{"id":779},"faq-sur-le-business-case-du-refactoring",[781],{"type":35,"value":782},"FAQ sur le business case du refactoring",{"type":29,"tag":784,"props":785,"children":786},"details",{},[787,793],{"type":29,"tag":788,"props":789,"children":790},"summary",{},[791],{"type":35,"value":792},"1. Que faire si le business accepte mais réduit le budget de moitié ?",{"type":29,"tag":37,"props":794,"children":795},{},[796],{"type":35,"value":797},"Ne pas accepter un programme sous-dimensionné qui ne peut pas atteindre ses objectifs. C'est pire qu'un refus : il consomme de la capacité sans produire de résultats, et détruit la crédibilité pour les prochaines demandes. Il vaut mieux replanifier sur un périmètre plus restreint (un module au lieu de trois) avec le budget disponible, et livrer des résultats mesurables avant de demander la suite.",{"type":29,"tag":784,"props":799,"children":800},{},[801,806],{"type":29,"tag":788,"props":802,"children":803},{},[804],{"type":35,"value":805},"2. Comment mesurer l'impact du programme une fois démarré ?",{"type":29,"tag":37,"props":807,"children":808},{},[809],{"type":35,"value":810},"Je définis les métriques de succès avant de commencer : lead time cible, taux d'incidents cible, absorption de maintenance cible. Je mesure ces métriques à J0, J30, J60, J90. Un tableau de bord visible par le business tous les 15 jours. La transparence sur les progrès maintient le soutien et prévient les remises en question en cours de route.",{"type":29,"tag":784,"props":812,"children":813},{},[814,819],{"type":29,"tag":788,"props":815,"children":816},{},[817],{"type":35,"value":818},"3. Le business peut-il comprendre les concepts techniques comme la \"dette technique\" ?",{"type":29,"tag":37,"props":820,"children":821},{},[822],{"type":35,"value":823},"Oui, mais pas dans le vocabulaire technique. L'analogie financière fonctionne très bien : \"La dette technique est exactement comme une dette financière. Elle a un principal (le travail à faire pour la rembourser) et des intérêts (le surcoût de travail que vous payez chaque jour parce qu'elle existe). Nous payons actuellement 1M€/an d'intérêts. Ce programme rembourse une partie du principal et réduit les intérêts de 60%.\"",{"type":29,"tag":784,"props":825,"children":826},{},[827,832],{"type":29,"tag":788,"props":828,"children":829},{},[830],{"type":35,"value":831},"4. Comment gérer la pression de maintenir la roadmap feature pendant le programme ?",{"type":29,"tag":37,"props":833,"children":834},{},[835],{"type":35,"value":836},"Je négocie explicitement le \"budget technique\" avant de commencer : X% de la capacité de l'équipe est allouée au programme pendant Y semaines. Ce n'est pas du temps volé aux features, c'est un investissement planifié. Je présente chaque sprint les features livrées ET l'avancement du programme. La co-existence est possible à condition que les règles soient claires dès le départ.",{"type":29,"tag":57,"props":838,"children":839},{},[],{"type":29,"tag":427,"props":841,"children":846},{"cta":842,"href":843,"title":844,"type":845},"Accéder à l'assessment gratuit →","/mes-ressources","Ressource gratuite : Engineering Maturity Self-Assessment","resource",[847],{"type":29,"tag":37,"props":848,"children":849},{},[850],{"type":35,"value":851},"L'assessment inclut une section dédiée à la gestion de la dette technique et vous aide à quantifier votre niveau d'absorption actuel : le premier chiffre dont vous avez besoin pour votre business case.",{"title":8,"searchDepth":853,"depth":853,"links":854},2,[855,856,857,858,859,860,861,862],{"id":63,"depth":853,"text":66},{"id":99,"depth":853,"text":102},{"id":214,"depth":853,"text":217},{"id":444,"depth":853,"text":447},{"id":567,"depth":853,"text":570},{"id":653,"depth":853,"text":656},{"id":671,"depth":853,"text":674},{"id":779,"depth":853,"text":782},"markdown","content:fr:dette-technique:programme-refactoring-approuve-business.md","content","fr/dette-technique/programme-refactoring-approuve-business.md","fr/dette-technique/programme-refactoring-approuve-business","md",{"_path":80,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":870,"description":871,"id":872,"date":873,"listed":13,"nocomments":7,"hidden":7,"categories":874,"tags":875,"--cover":878,"readingTime":879,"body":884,"_type":863,"_id":1584,"_source":865,"_file":1585,"_stem":1586,"_extension":868},"Legacy code : comment évaluer le risque avant d'intervenir","Modifier du code legacy sans évaluation préalable est la cause #1 des régressions. Les 4 dimensions de risque à évaluer avant de toucher à la moindre ligne.",6,"2026-01-16",[6],[876,16,877],"Legacy Code","Risque","covers/articles/legacy-code-risque.jpg",{"text":880,"minutes":881,"time":882,"words":883},"8 min read",7.93,475800,1586,{"type":26,"children":885,"toc":1575},[886,891,896,904,909,912,918,923,935,947,952,955,961,966,975,993,1002,1020,1041,1044,1050,1055,1063,1081,1090,1108,1121,1124,1133,1136,1142,1147,1155,1182,1191,1209,1219,1222,1228,1233,1241,1259,1268,1301,1314,1317,1323,1328,1450,1459,1477,1482,1485,1491,1504,1517,1530,1543,1564,1567],{"type":29,"tag":30,"props":887,"children":889},{"id":888},"legacy-code-comment-évaluer-le-risque-avant-dintervenir",[890],{"type":35,"value":870},{"type":29,"tag":37,"props":892,"children":893},{},[894],{"type":35,"value":895},"J'étais dans une grande banque de réseau, avec une équipe de 35 développeurs. Un tech lead expérimenté m'annonce qu'il va \"faire un petit refactoring de 2 jours\" sur un module de calcul de frais. Deux semaines plus tard, la release était bloquée. Le module contenait une règle fiscale codée dans une condition sans commentaire, que personne ne connaissait plus. La personne qui l'avait écrite avait quitté l'entreprise trois ans plus tôt. Ce refactoring \"anodin\" avait cassé silencieusement un calcul utilisé sur 40 000 comptes clients.",{"type":29,"tag":37,"props":897,"children":898},{},[899],{"type":29,"tag":46,"props":900,"children":901},{},[902],{"type":35,"value":903},"Modifier du code legacy sans évaluation préalable est la cause numéro un des régressions inattendues. Non pas parce que les développeurs sont imprudents, mais parce que le code legacy contient des comportements implicites que personne ne connaît plus.",{"type":29,"tag":37,"props":905,"children":906},{},[907],{"type":35,"value":908},"J'ai vu des équipes bloquer des releases entières pour des \"petits refactorings de 2 jours\". J'en ai vu d'autres refuser de toucher à des modules critiques pendant des années, laissant la dette s'accumuler jusqu'à ce que la maintenance devienne insoutenable. Entre la témérité et la paralysie, il existe une voie structurée : l'évaluation de risque en 4 dimensions.",{"type":29,"tag":57,"props":910,"children":911},{},[],{"type":29,"tag":61,"props":913,"children":915},{"id":914},"pourquoi-le-code-legacy-est-un-terrain-miné",[916],{"type":35,"value":917},"Pourquoi le code legacy est un terrain miné",{"type":29,"tag":37,"props":919,"children":920},{},[921],{"type":35,"value":922},"Le danger du code legacy n'est pas sa complexité syntaxique. C'est l'accumulation de comportements implicites : des règles métier encodées dans des conditions sans commentaire, des effets de bord non documentés, des dépendances cachées entre modules qui semblent indépendants.",{"type":29,"tag":37,"props":924,"children":925},{},[926,928,933],{"type":35,"value":927},"Une étude de Cambridge University a estimé que les développeurs passent ",{"type":29,"tag":46,"props":929,"children":930},{},[931],{"type":35,"value":932},"50% de leur temps",{"type":35,"value":934}," à comprendre du code existant avant de le modifier. Sur du code legacy, ce chiffre peut atteindre 70-80%.",{"type":29,"tag":37,"props":936,"children":937},{},[938,940,945],{"type":35,"value":939},"Le coût d'une régression sur un module critique va bien au-delà du temps de correction : il inclut le rollback, la communication de crise, le test de non-régression élargi, et la perte de confiance en l'équipe. Dans le secteur financier, une régression sur un moteur de calcul peut déclencher un incident réglementaire aux conséquences disproportionnées. J'ai accompagné une équipe Crédit Agricole où un incident de ce type avait mobilisé 12 personnes pendant 4 jours (voir comment ",{"type":29,"tag":78,"props":941,"children":942},{"href":5},[943],{"type":35,"value":944},"obtenir le budget pour traiter ces risques",{"type":35,"value":946},"), soit 48 jours-homme pour corriger ce qu'une évaluation de risque préalable aurait évité.",{"type":29,"tag":37,"props":948,"children":949},{},[950],{"type":35,"value":951},"La bonne nouvelle : le risque d'intervention sur le legacy est évaluable. Il repose sur 4 dimensions.",{"type":29,"tag":57,"props":953,"children":954},{},[],{"type":29,"tag":61,"props":956,"children":958},{"id":957},"dimension-1-couverture-de-tests-ou-son-absence",[959],{"type":35,"value":960},"Dimension 1 : Couverture de tests (ou son absence)",{"type":29,"tag":37,"props":962,"children":963},{},[964],{"type":35,"value":965},"C'est la dimension la plus visible et la plus impactante. Un module bien couvert en tests est un module sur lequel on peut intervenir avec confiance : si on casse quelque chose, les tests le disent immédiatement.",{"type":29,"tag":37,"props":967,"children":968},{},[969,974],{"type":29,"tag":46,"props":970,"children":971},{},[972],{"type":35,"value":973},"Comment évaluer",{"type":35,"value":162},{"type":29,"tag":68,"props":976,"children":977},{},[978,983,988],{"type":29,"tag":72,"props":979,"children":980},{},[981],{"type":35,"value":982},"Calculer la couverture de tests du module cible (outils : JaCoCo, Istanbul, Coverage.py)",{"type":29,"tag":72,"props":984,"children":985},{},[986],{"type":35,"value":987},"Distinguer couverture de lignes (insuffisante) et couverture de branches (significative)",{"type":29,"tag":72,"props":989,"children":990},{},[991],{"type":35,"value":992},"Identifier les tests d'intégration qui couvrent le comportement end-to-end, pas seulement les tests unitaires",{"type":29,"tag":37,"props":994,"children":995},{},[996,1001],{"type":29,"tag":46,"props":997,"children":998},{},[999],{"type":35,"value":1000},"Seuils de risque",{"type":35,"value":162},{"type":29,"tag":68,"props":1003,"children":1004},{},[1005,1010,1015],{"type":29,"tag":72,"props":1006,"children":1007},{},[1008],{"type":35,"value":1009},"Couverture > 70% avec tests d'intégration → risque faible",{"type":29,"tag":72,"props":1011,"children":1012},{},[1013],{"type":35,"value":1014},"Couverture 30-70% → risque modéré, ajouter des tests de caractérisation avant d'intervenir",{"type":29,"tag":72,"props":1016,"children":1017},{},[1018],{"type":35,"value":1019},"Couverture \u003C 30% → risque élevé, écrire des characterization tests avant tout refactoring",{"type":29,"tag":658,"props":1021,"children":1022},{},[1023],{"type":29,"tag":37,"props":1024,"children":1025},{},[1026,1031,1033,1039],{"type":29,"tag":46,"props":1027,"children":1028},{},[1029],{"type":35,"value":1030},"La règle de Michael Feathers",{"type":35,"value":1032}," dans \"Working Effectively with Legacy Code\" : avant de modifier du legacy sans tests, écrire un \"",{"type":29,"tag":78,"props":1034,"children":1036},{"href":1035},"/fr/dette-technique/tests-integration-legacy-pieges",[1037],{"type":35,"value":1038},"characterization test",{"type":35,"value":1040},"\" : un test qui documente le comportement actuel, même s'il semble bizarre. Ce test devient votre filet de sécurité. Ce livre reste la référence absolue sur le sujet, 20 ans après sa publication.",{"type":29,"tag":57,"props":1042,"children":1043},{},[],{"type":29,"tag":61,"props":1045,"children":1047},{"id":1046},"dimension-2-compréhension-métier-du-code",[1048],{"type":35,"value":1049},"Dimension 2 : Compréhension métier du code",{"type":29,"tag":37,"props":1051,"children":1052},{},[1053],{"type":35,"value":1054},"Un module peut avoir une couverture de tests à 80% et rester dangereux si personne dans l'équipe ne comprend ce qu'il fait sur le plan métier.",{"type":29,"tag":37,"props":1056,"children":1057},{},[1058,1062],{"type":29,"tag":46,"props":1059,"children":1060},{},[1061],{"type":35,"value":973},{"type":35,"value":162},{"type":29,"tag":68,"props":1064,"children":1065},{},[1066,1071,1076],{"type":29,"tag":72,"props":1067,"children":1068},{},[1069],{"type":35,"value":1070},"Identifier la ou les personnes capables d'expliquer la règle métier implémentée",{"type":29,"tag":72,"props":1072,"children":1073},{},[1074],{"type":35,"value":1075},"Vérifier si la documentation métier (spécifications, tickets d'origine) existe et est accessible",{"type":29,"tag":72,"props":1077,"children":1078},{},[1079],{"type":35,"value":1080},"Estimer le \"bus factor\" : si cette personne part, le module devient-il opaque ?",{"type":29,"tag":37,"props":1082,"children":1083},{},[1084,1089],{"type":29,"tag":46,"props":1085,"children":1086},{},[1087],{"type":35,"value":1088},"Questions concrètes à poser",{"type":35,"value":162},{"type":29,"tag":68,"props":1091,"children":1092},{},[1093,1098,1103],{"type":29,"tag":72,"props":1094,"children":1095},{},[1096],{"type":35,"value":1097},"\"Pouvez-vous m'expliquer ce que ce module fait en 3 phrases, sans regarder le code ?\"",{"type":29,"tag":72,"props":1099,"children":1100},{},[1101],{"type":35,"value":1102},"\"Existe-t-il des cas limites non évidents dans cette règle métier ?\"",{"type":29,"tag":72,"props":1104,"children":1105},{},[1106],{"type":35,"value":1107},"\"Y a-t-il eu des incidents passés sur ce module dont la cause était une incompréhension métier ?\"",{"type":29,"tag":658,"props":1109,"children":1110},{},[1111],{"type":29,"tag":37,"props":1112,"children":1113},{},[1114,1119],{"type":29,"tag":46,"props":1115,"children":1116},{},[1117],{"type":35,"value":1118},"Ce que j'ai vécu dans une société d'assurance vie",{"type":35,"value":1120}," : un module de calcul de prime avait une couverture de tests à 65%. L'équipe estimait le risque modéré. Mais lors de l'entretien, il s'est avéré que l'unique développeur qui comprenait les règles fiscales avait quitté l'entreprise 18 mois plus tôt. Le risque réel était élevé. Nous avons passé 3 jours à documenter le comportement avant d'intervenir. Ce délai a semblé coûteux sur le moment, mais il nous a évité une régression sur 80 000 contrats.",{"type":29,"tag":57,"props":1122,"children":1123},{},[],{"type":29,"tag":427,"props":1125,"children":1127},{"cta":429,"href":430,"title":1126,"type":432},"Vous avez un module legacy critique à refactoriser mais vous ne savez pas par où commencer ?",[1128],{"type":29,"tag":37,"props":1129,"children":1130},{},[1131],{"type":35,"value":1132},"Vous voyez la dette s'accumuler, vous savez qu'il faut intervenir, mais chaque fois que vous vous approchez du code, quelque chose vous retient. C'est normal : le legacy non évalué est objectivement risqué. En 30 minutes, je vous aide à définir la séquence d'intervention qui minimise les régressions et libère de la capacité sans bloquer votre roadmap.",{"type":29,"tag":57,"props":1134,"children":1135},{},[],{"type":29,"tag":61,"props":1137,"children":1139},{"id":1138},"dimension-3-couplage-et-surface-dimpact",[1140],{"type":35,"value":1141},"Dimension 3 : Couplage et surface d'impact",{"type":29,"tag":37,"props":1143,"children":1144},{},[1145],{"type":35,"value":1146},"Un module peut être simple à comprendre et bien testé, et quand même risqué à modifier s'il est fortement couplé à d'autres modules. Chaque modification peut déclencher des effets en cascade.",{"type":29,"tag":37,"props":1148,"children":1149},{},[1150,1154],{"type":29,"tag":46,"props":1151,"children":1152},{},[1153],{"type":35,"value":973},{"type":35,"value":162},{"type":29,"tag":68,"props":1156,"children":1157},{},[1158,1172,1177],{"type":29,"tag":72,"props":1159,"children":1160},{},[1161,1163,1170],{"type":35,"value":1162},"Identifier les dépendances entrantes et sortantes du module (outils : Structure101, Sonargraph, ",{"type":29,"tag":1164,"props":1165,"children":1167},"code",{"className":1166},[],[1168],{"type":35,"value":1169},"git log --follow",{"type":35,"value":1171},")",{"type":29,"tag":72,"props":1173,"children":1174},{},[1175],{"type":35,"value":1176},"Cartographier les modules qui appellent le module cible",{"type":29,"tag":72,"props":1178,"children":1179},{},[1180],{"type":35,"value":1181},"Évaluer le couplage de données : le module partage-t-il des structures de données ou une base avec d'autres modules ?",{"type":29,"tag":37,"props":1183,"children":1184},{},[1185,1190],{"type":29,"tag":46,"props":1186,"children":1187},{},[1188],{"type":35,"value":1189},"Indicateurs de couplage à risque",{"type":35,"value":162},{"type":29,"tag":68,"props":1192,"children":1193},{},[1194,1199,1204],{"type":29,"tag":72,"props":1195,"children":1196},{},[1197],{"type":35,"value":1198},"Plus de 5 modules différents qui appellent directement le module cible",{"type":29,"tag":72,"props":1200,"children":1201},{},[1202],{"type":35,"value":1203},"Modification de schéma de base de données partagée",{"type":29,"tag":72,"props":1205,"children":1206},{},[1207],{"type":35,"value":1208},"Présence de \"shotgun surgery\" : un changement logique qui nécessite de modifier 8+ fichiers",{"type":29,"tag":37,"props":1210,"children":1211},{},[1212,1217],{"type":29,"tag":46,"props":1213,"children":1214},{},[1215],{"type":35,"value":1216},"La règle empirique",{"type":35,"value":1218}," : pour chaque module entrant dans le scope de refactoring, je vérifie les 3 niveaux de dépendances (direct, indirect, transitif). La surface d'impact réelle est souvent 3 à 5 fois plus large que l'estimation initiale.",{"type":29,"tag":57,"props":1220,"children":1221},{},[],{"type":29,"tag":61,"props":1223,"children":1225},{"id":1224},"dimension-4-criticité-business-du-module",[1226],{"type":35,"value":1227},"Dimension 4 : Criticité business du module",{"type":29,"tag":37,"props":1229,"children":1230},{},[1231],{"type":35,"value":1232},"Deux modules à risque technique équivalent n'ont pas le même risque réel si l'un gère les notifications email et l'autre les virements bancaires.",{"type":29,"tag":37,"props":1234,"children":1235},{},[1236,1240],{"type":29,"tag":46,"props":1237,"children":1238},{},[1239],{"type":35,"value":973},{"type":35,"value":162},{"type":29,"tag":68,"props":1242,"children":1243},{},[1244,1249,1254],{"type":29,"tag":72,"props":1245,"children":1246},{},[1247],{"type":35,"value":1248},"Identifier la criticité business : quel processus métier ce module supporte-t-il ?",{"type":29,"tag":72,"props":1250,"children":1251},{},[1252],{"type":35,"value":1253},"Évaluer l'impact d'une régression : financier, réglementaire, réputationnel",{"type":29,"tag":72,"props":1255,"children":1256},{},[1257],{"type":35,"value":1258},"Vérifier le SLA : ce module a-t-il un SLA de disponibilité ou de performance ?",{"type":29,"tag":37,"props":1260,"children":1261},{},[1262,1267],{"type":29,"tag":46,"props":1263,"children":1264},{},[1265],{"type":35,"value":1266},"Niveaux de criticité",{"type":35,"value":162},{"type":29,"tag":68,"props":1269,"children":1270},{},[1271,1281,1291],{"type":29,"tag":72,"props":1272,"children":1273},{},[1274,1279],{"type":29,"tag":46,"props":1275,"children":1276},{},[1277],{"type":35,"value":1278},"Critique",{"type":35,"value":1280}," : module dans le chemin de traitement principal, impact direct sur le revenu ou la conformité réglementaire",{"type":29,"tag":72,"props":1282,"children":1283},{},[1284,1289],{"type":29,"tag":46,"props":1285,"children":1286},{},[1287],{"type":35,"value":1288},"Important",{"type":35,"value":1290}," : module utilisé quotidiennement, régression visible par les utilisateurs mais non-bloquante",{"type":29,"tag":72,"props":1292,"children":1293},{},[1294,1299],{"type":29,"tag":46,"props":1295,"children":1296},{},[1297],{"type":35,"value":1298},"Standard",{"type":35,"value":1300}," : module d'administration, batch non-temps-réel, fonctionnalité non-critique",{"type":29,"tag":658,"props":1302,"children":1303},{},[1304],{"type":29,"tag":37,"props":1305,"children":1306},{},[1307,1312],{"type":29,"tag":46,"props":1308,"children":1309},{},[1310],{"type":35,"value":1311},"Règle",{"type":35,"value":1313}," : la criticité business multiplie le risque technique. Un module à risque technique modéré + criticité haute = risque réel élevé. Je refuse de commencer un refactoring sans avoir établi ce mapping clairement.",{"type":29,"tag":57,"props":1315,"children":1316},{},[],{"type":29,"tag":61,"props":1318,"children":1320},{"id":1319},"la-matrice-de-risque-et-comment-lutiliser",[1321],{"type":35,"value":1322},"La matrice de risque et comment l'utiliser",{"type":29,"tag":37,"props":1324,"children":1325},{},[1326],{"type":35,"value":1327},"Je combine les 4 dimensions dans une matrice simple :",{"type":29,"tag":276,"props":1329,"children":1330},{},[1331,1357],{"type":29,"tag":280,"props":1332,"children":1333},{},[1334],{"type":29,"tag":284,"props":1335,"children":1336},{},[1337,1342,1347,1352],{"type":29,"tag":288,"props":1338,"children":1339},{},[1340],{"type":35,"value":1341},"Dimension",{"type":29,"tag":288,"props":1343,"children":1344},{},[1345],{"type":35,"value":1346},"Score 1 (faible)",{"type":29,"tag":288,"props":1348,"children":1349},{},[1350],{"type":35,"value":1351},"Score 2 (modéré)",{"type":29,"tag":288,"props":1353,"children":1354},{},[1355],{"type":35,"value":1356},"Score 3 (élevé)",{"type":29,"tag":302,"props":1358,"children":1359},{},[1360,1383,1406,1429],{"type":29,"tag":284,"props":1361,"children":1362},{},[1363,1368,1373,1378],{"type":29,"tag":309,"props":1364,"children":1365},{},[1366],{"type":35,"value":1367},"Couverture tests",{"type":29,"tag":309,"props":1369,"children":1370},{},[1371],{"type":35,"value":1372},"> 70%",{"type":29,"tag":309,"props":1374,"children":1375},{},[1376],{"type":35,"value":1377},"30-70%",{"type":29,"tag":309,"props":1379,"children":1380},{},[1381],{"type":35,"value":1382},"\u003C 30%",{"type":29,"tag":284,"props":1384,"children":1385},{},[1386,1391,1396,1401],{"type":29,"tag":309,"props":1387,"children":1388},{},[1389],{"type":35,"value":1390},"Compréhension métier",{"type":29,"tag":309,"props":1392,"children":1393},{},[1394],{"type":35,"value":1395},"Bien documenté",{"type":29,"tag":309,"props":1397,"children":1398},{},[1399],{"type":35,"value":1400},"Documenté partiellement",{"type":29,"tag":309,"props":1402,"children":1403},{},[1404],{"type":35,"value":1405},"Non documenté",{"type":29,"tag":284,"props":1407,"children":1408},{},[1409,1414,1419,1424],{"type":29,"tag":309,"props":1410,"children":1411},{},[1412],{"type":35,"value":1413},"Couplage",{"type":29,"tag":309,"props":1415,"children":1416},{},[1417],{"type":35,"value":1418},"\u003C 3 dépendances",{"type":29,"tag":309,"props":1420,"children":1421},{},[1422],{"type":35,"value":1423},"3-7 dépendances",{"type":29,"tag":309,"props":1425,"children":1426},{},[1427],{"type":35,"value":1428},"> 7 dépendances",{"type":29,"tag":284,"props":1430,"children":1431},{},[1432,1437,1441,1446],{"type":29,"tag":309,"props":1433,"children":1434},{},[1435],{"type":35,"value":1436},"Criticité business",{"type":29,"tag":309,"props":1438,"children":1439},{},[1440],{"type":35,"value":1298},{"type":29,"tag":309,"props":1442,"children":1443},{},[1444],{"type":35,"value":1445},"Importante",{"type":29,"tag":309,"props":1447,"children":1448},{},[1449],{"type":35,"value":1278},{"type":29,"tag":37,"props":1451,"children":1452},{},[1453,1458],{"type":29,"tag":46,"props":1454,"children":1455},{},[1456],{"type":35,"value":1457},"Score total",{"type":35,"value":162},{"type":29,"tag":68,"props":1460,"children":1461},{},[1462,1467,1472],{"type":29,"tag":72,"props":1463,"children":1464},{},[1465],{"type":35,"value":1466},"4-6 points → Intervention directe possible",{"type":29,"tag":72,"props":1468,"children":1469},{},[1470],{"type":35,"value":1471},"7-9 points → Sécuriser avant d'intervenir (tests de caractérisation, documentation)",{"type":29,"tag":72,"props":1473,"children":1474},{},[1475],{"type":35,"value":1476},"10-12 points → Planifier une phase de préparation de 2-4 semaines avant toute modification",{"type":29,"tag":37,"props":1478,"children":1479},{},[1480],{"type":35,"value":1481},"Ce n'est pas un outil de blocage, c'est un outil de planification. Un module à 10-12 points peut et doit être refactorisé. Mais la séquence d'intervention change radicalement.",{"type":29,"tag":57,"props":1483,"children":1484},{},[],{"type":29,"tag":61,"props":1486,"children":1488},{"id":1487},"faq-sur-lévaluation-du-risque-legacy",[1489],{"type":35,"value":1490},"FAQ sur l'évaluation du risque legacy",{"type":29,"tag":784,"props":1492,"children":1493},{},[1494,1499],{"type":29,"tag":788,"props":1495,"children":1496},{},[1497],{"type":35,"value":1498},"1. Combien de temps faut-il pour évaluer le risque d'un module legacy ?",{"type":29,"tag":37,"props":1500,"children":1501},{},[1502],{"type":35,"value":1503},"Pour un module de taille moyenne (5 000 à 20 000 lignes de code), l'évaluation des 4 dimensions prend 2 à 4 heures en impliquant un tech lead et un développeur qui connaît le contexte métier. Pour un module critique avec des dépendances complexes, comptez une demi-journée. C'est un investissement rentable : une régression sur un module critique peut coûter 10 à 100 fois ce temps en incident management.",{"type":29,"tag":784,"props":1505,"children":1506},{},[1507,1512],{"type":29,"tag":788,"props":1508,"children":1509},{},[1510],{"type":35,"value":1511},"2. Qu'est-ce qu'un characterization test et comment l'écrire ?",{"type":29,"tag":37,"props":1513,"children":1514},{},[1515],{"type":35,"value":1516},"Un characterization test documente le comportement actuel d'un module, qu'il soit correct ou non. On appelle la fonction avec des inputs réels, on observe l'output, et on l'encode comme valeur attendue dans le test. L'objectif n'est pas de vérifier que le comportement est juste, c'est de détecter si une modification le change. C'est le filet de sécurité minimal avant toute intervention sur du legacy non testé, tel que Michael Feathers l'a formalisé.",{"type":29,"tag":784,"props":1518,"children":1519},{},[1520,1525],{"type":29,"tag":788,"props":1521,"children":1522},{},[1523],{"type":35,"value":1524},"3. Comment gérer un module legacy sans aucun test et sans documentation ?",{"type":29,"tag":37,"props":1526,"children":1527},{},[1528],{"type":35,"value":1529},"La séquence que je recommande : (1) Identifier un expert métier capable d'expliquer ce que le module est censé faire. (2) Écrire des characterization tests basés sur des exemples de données réelles de production. (3) Organiser une session de \"live coding\" où un développeur senior lit le code à voix haute pendant qu'un autre prend des notes sur les règles implicites découvertes. (4) Documenter les règles dans des commentaires proches du code avant toute modification. Ce processus prend 1 à 3 jours mais réduit le risque de 70-80%.",{"type":29,"tag":784,"props":1531,"children":1532},{},[1533,1538],{"type":29,"tag":788,"props":1534,"children":1535},{},[1536],{"type":35,"value":1537},"4. Quand est-ce qu'il vaut mieux réécrire que refactoriser ?",{"type":29,"tag":37,"props":1539,"children":1540},{},[1541],{"type":35,"value":1542},"La réécriture est justifiée quand : (1) le couplage est si fort qu'il est impossible de modifier une partie sans toucher à l'ensemble, (2) la technologie sous-jacente est en fin de vie et ne peut pas être migrée progressivement, (3) la logique métier est si obscure qu'elle ne peut pas être testée avant d'être comprise. Mais la réécriture from scratch a un taux d'échec élevé : je préfère la migration progressive par le pattern \"strangler fig\" de Martin Fowler : remplacer le legacy morceau par morceau tout en maintenant le système en production.",{"type":29,"tag":784,"props":1544,"children":1545},{},[1546,1551],{"type":29,"tag":788,"props":1547,"children":1548},{},[1549],{"type":35,"value":1550},"5. Comment convaincre l'équipe de faire une évaluation de risque systématique ?",{"type":29,"tag":37,"props":1552,"children":1553},{},[1554,1556,1562],{"type":35,"value":1555},"La meilleure approche est de partager un post-mortem d'une régression passée en montrant qu'une évaluation préalable l'aurait évitée. Ensuite, intégrer l'évaluation dans la ",{"type":29,"tag":78,"props":1557,"children":1559},{"href":1558},"/fr/pratiques-agiles/definition-of-ready-bugs-sprint",[1560],{"type":35,"value":1561},"Definition of Ready",{"type":35,"value":1563}," des stories de refactoring : \"une story de refactoring legacy est prête quand la matrice de risque a été remplie\". Une fois que l'équipe a utilisé l'outil 2-3 fois et évité des régressions, le réflexe s'installe naturellement.",{"type":29,"tag":57,"props":1565,"children":1566},{},[],{"type":29,"tag":427,"props":1568,"children":1569},{"cta":842,"href":843,"title":844,"type":845},[1570],{"type":29,"tag":37,"props":1571,"children":1572},{},[1573],{"type":35,"value":1574},"30 questions sur 5 dimensions de maturité engineering, incluant une section dédiée aux pratiques sur le code legacy et la gestion de la dette technique. Score automatique + 3 priorités d'action pour les 90 prochains jours.",{"title":8,"searchDepth":853,"depth":853,"links":1576},[1577,1578,1579,1580,1581,1582,1583],{"id":914,"depth":853,"text":917},{"id":957,"depth":853,"text":960},{"id":1046,"depth":853,"text":1049},{"id":1138,"depth":853,"text":1141},{"id":1224,"depth":853,"text":1227},{"id":1319,"depth":853,"text":1322},{"id":1487,"depth":853,"text":1490},"content:fr:dette-technique:legacy-code-evaluer-risque.md","fr/dette-technique/legacy-code-evaluer-risque.md","fr/dette-technique/legacy-code-evaluer-risque",1775679743552]