[{"data":1,"prerenderedAt":761},["ShallowReactive",2],{"/fr/dette-technique/legacy-code-evaluer-risque":3,"search-api":-1},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":8,"description":9,"id":10,"date":11,"listed":12,"nocomments":6,"hidden":6,"categories":13,"tags":14,"--cover":18,"readingTime":19,"body":24,"_type":755,"_id":756,"_source":757,"_file":758,"_stem":759,"_extension":760},"/fr/dette-technique/legacy-code-evaluer-risque","dette-technique",false,"","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",true,[5],[15,16,17],"Legacy Code","Refactoring","Risque","covers/articles/legacy-code-risque.jpg",{"text":20,"minutes":21,"time":22,"words":23},"8 min read",7.93,475800,1586,{"type":25,"children":26,"toc":745},"root",[27,35,41,50,55,59,66,71,83,97,102,105,111,116,126,146,155,173,195,198,204,209,217,235,244,262,275,278,291,294,300,305,313,340,349,367,377,380,386,391,399,417,426,459,472,475,481,486,614,623,641,646,649,655,670,683,696,709,730,733],{"type":28,"tag":29,"props":30,"children":32},"element","h1",{"id":31},"legacy-code-comment-évaluer-le-risque-avant-dintervenir",[33],{"type":34,"value":8},"text",{"type":28,"tag":36,"props":37,"children":38},"p",{},[39],{"type":34,"value":40},"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":28,"tag":36,"props":42,"children":43},{},[44],{"type":28,"tag":45,"props":46,"children":47},"strong",{},[48],{"type":34,"value":49},"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":28,"tag":36,"props":51,"children":52},{},[53],{"type":34,"value":54},"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":28,"tag":56,"props":57,"children":58},"hr",{},[],{"type":28,"tag":60,"props":61,"children":63},"h2",{"id":62},"pourquoi-le-code-legacy-est-un-terrain-miné",[64],{"type":34,"value":65},"Pourquoi le code legacy est un terrain miné",{"type":28,"tag":36,"props":67,"children":68},{},[69],{"type":34,"value":70},"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":28,"tag":36,"props":72,"children":73},{},[74,76,81],{"type":34,"value":75},"Une étude de Cambridge University a estimé que les développeurs passent ",{"type":28,"tag":45,"props":77,"children":78},{},[79],{"type":34,"value":80},"50% de leur temps",{"type":34,"value":82}," à comprendre du code existant avant de le modifier. Sur du code legacy, ce chiffre peut atteindre 70-80%.",{"type":28,"tag":36,"props":84,"children":85},{},[86,88,95],{"type":34,"value":87},"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":28,"tag":89,"props":90,"children":92},"a",{"href":91},"/fr/dette-technique/programme-refactoring-approuve-business",[93],{"type":34,"value":94},"obtenir le budget pour traiter ces risques",{"type":34,"value":96},"), soit 48 jours-homme pour corriger ce qu'une évaluation de risque préalable aurait évité.",{"type":28,"tag":36,"props":98,"children":99},{},[100],{"type":34,"value":101},"La bonne nouvelle : le risque d'intervention sur le legacy est évaluable. Il repose sur 4 dimensions.",{"type":28,"tag":56,"props":103,"children":104},{},[],{"type":28,"tag":60,"props":106,"children":108},{"id":107},"dimension-1-couverture-de-tests-ou-son-absence",[109],{"type":34,"value":110},"Dimension 1 : Couverture de tests (ou son absence)",{"type":28,"tag":36,"props":112,"children":113},{},[114],{"type":34,"value":115},"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":28,"tag":36,"props":117,"children":118},{},[119,124],{"type":28,"tag":45,"props":120,"children":121},{},[122],{"type":34,"value":123},"Comment évaluer",{"type":34,"value":125}," :",{"type":28,"tag":127,"props":128,"children":129},"ul",{},[130,136,141],{"type":28,"tag":131,"props":132,"children":133},"li",{},[134],{"type":34,"value":135},"Calculer la couverture de tests du module cible (outils : JaCoCo, Istanbul, Coverage.py)",{"type":28,"tag":131,"props":137,"children":138},{},[139],{"type":34,"value":140},"Distinguer couverture de lignes (insuffisante) et couverture de branches (significative)",{"type":28,"tag":131,"props":142,"children":143},{},[144],{"type":34,"value":145},"Identifier les tests d'intégration qui couvrent le comportement end-to-end, pas seulement les tests unitaires",{"type":28,"tag":36,"props":147,"children":148},{},[149,154],{"type":28,"tag":45,"props":150,"children":151},{},[152],{"type":34,"value":153},"Seuils de risque",{"type":34,"value":125},{"type":28,"tag":127,"props":156,"children":157},{},[158,163,168],{"type":28,"tag":131,"props":159,"children":160},{},[161],{"type":34,"value":162},"Couverture > 70% avec tests d'intégration → risque faible",{"type":28,"tag":131,"props":164,"children":165},{},[166],{"type":34,"value":167},"Couverture 30-70% → risque modéré, ajouter des tests de caractérisation avant d'intervenir",{"type":28,"tag":131,"props":169,"children":170},{},[171],{"type":34,"value":172},"Couverture \u003C 30% → risque élevé, écrire des characterization tests avant tout refactoring",{"type":28,"tag":174,"props":175,"children":176},"blockquote",{},[177],{"type":28,"tag":36,"props":178,"children":179},{},[180,185,187,193],{"type":28,"tag":45,"props":181,"children":182},{},[183],{"type":34,"value":184},"La règle de Michael Feathers",{"type":34,"value":186}," dans \"Working Effectively with Legacy Code\" : avant de modifier du legacy sans tests, écrire un \"",{"type":28,"tag":89,"props":188,"children":190},{"href":189},"/fr/dette-technique/tests-integration-legacy-pieges",[191],{"type":34,"value":192},"characterization test",{"type":34,"value":194},"\" : 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":28,"tag":56,"props":196,"children":197},{},[],{"type":28,"tag":60,"props":199,"children":201},{"id":200},"dimension-2-compréhension-métier-du-code",[202],{"type":34,"value":203},"Dimension 2 : Compréhension métier du code",{"type":28,"tag":36,"props":205,"children":206},{},[207],{"type":34,"value":208},"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":28,"tag":36,"props":210,"children":211},{},[212,216],{"type":28,"tag":45,"props":213,"children":214},{},[215],{"type":34,"value":123},{"type":34,"value":125},{"type":28,"tag":127,"props":218,"children":219},{},[220,225,230],{"type":28,"tag":131,"props":221,"children":222},{},[223],{"type":34,"value":224},"Identifier la ou les personnes capables d'expliquer la règle métier implémentée",{"type":28,"tag":131,"props":226,"children":227},{},[228],{"type":34,"value":229},"Vérifier si la documentation métier (spécifications, tickets d'origine) existe et est accessible",{"type":28,"tag":131,"props":231,"children":232},{},[233],{"type":34,"value":234},"Estimer le \"bus factor\" : si cette personne part, le module devient-il opaque ?",{"type":28,"tag":36,"props":236,"children":237},{},[238,243],{"type":28,"tag":45,"props":239,"children":240},{},[241],{"type":34,"value":242},"Questions concrètes à poser",{"type":34,"value":125},{"type":28,"tag":127,"props":245,"children":246},{},[247,252,257],{"type":28,"tag":131,"props":248,"children":249},{},[250],{"type":34,"value":251},"\"Pouvez-vous m'expliquer ce que ce module fait en 3 phrases, sans regarder le code ?\"",{"type":28,"tag":131,"props":253,"children":254},{},[255],{"type":34,"value":256},"\"Existe-t-il des cas limites non évidents dans cette règle métier ?\"",{"type":28,"tag":131,"props":258,"children":259},{},[260],{"type":34,"value":261},"\"Y a-t-il eu des incidents passés sur ce module dont la cause était une incompréhension métier ?\"",{"type":28,"tag":174,"props":263,"children":264},{},[265],{"type":28,"tag":36,"props":266,"children":267},{},[268,273],{"type":28,"tag":45,"props":269,"children":270},{},[271],{"type":34,"value":272},"Ce que j'ai vécu dans une société d'assurance vie",{"type":34,"value":274}," : 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":28,"tag":56,"props":276,"children":277},{},[],{"type":28,"tag":279,"props":280,"children":285},"cta",{"cta":281,"href":282,"title":283,"type":284},"Réserver mon diagnostic gratuit →","https://app.kamanga.fr/forms/discovery-call","Vous avez un module legacy critique à refactoriser mais vous ne savez pas par où commencer ?","call",[286],{"type":28,"tag":36,"props":287,"children":288},{},[289],{"type":34,"value":290},"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":28,"tag":56,"props":292,"children":293},{},[],{"type":28,"tag":60,"props":295,"children":297},{"id":296},"dimension-3-couplage-et-surface-dimpact",[298],{"type":34,"value":299},"Dimension 3 : Couplage et surface d'impact",{"type":28,"tag":36,"props":301,"children":302},{},[303],{"type":34,"value":304},"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":28,"tag":36,"props":306,"children":307},{},[308,312],{"type":28,"tag":45,"props":309,"children":310},{},[311],{"type":34,"value":123},{"type":34,"value":125},{"type":28,"tag":127,"props":314,"children":315},{},[316,330,335],{"type":28,"tag":131,"props":317,"children":318},{},[319,321,328],{"type":34,"value":320},"Identifier les dépendances entrantes et sortantes du module (outils : Structure101, Sonargraph, ",{"type":28,"tag":322,"props":323,"children":325},"code",{"className":324},[],[326],{"type":34,"value":327},"git log --follow",{"type":34,"value":329},")",{"type":28,"tag":131,"props":331,"children":332},{},[333],{"type":34,"value":334},"Cartographier les modules qui appellent le module cible",{"type":28,"tag":131,"props":336,"children":337},{},[338],{"type":34,"value":339},"Évaluer le couplage de données : le module partage-t-il des structures de données ou une base avec d'autres modules ?",{"type":28,"tag":36,"props":341,"children":342},{},[343,348],{"type":28,"tag":45,"props":344,"children":345},{},[346],{"type":34,"value":347},"Indicateurs de couplage à risque",{"type":34,"value":125},{"type":28,"tag":127,"props":350,"children":351},{},[352,357,362],{"type":28,"tag":131,"props":353,"children":354},{},[355],{"type":34,"value":356},"Plus de 5 modules différents qui appellent directement le module cible",{"type":28,"tag":131,"props":358,"children":359},{},[360],{"type":34,"value":361},"Modification de schéma de base de données partagée",{"type":28,"tag":131,"props":363,"children":364},{},[365],{"type":34,"value":366},"Présence de \"shotgun surgery\" : un changement logique qui nécessite de modifier 8+ fichiers",{"type":28,"tag":36,"props":368,"children":369},{},[370,375],{"type":28,"tag":45,"props":371,"children":372},{},[373],{"type":34,"value":374},"La règle empirique",{"type":34,"value":376}," : 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":28,"tag":56,"props":378,"children":379},{},[],{"type":28,"tag":60,"props":381,"children":383},{"id":382},"dimension-4-criticité-business-du-module",[384],{"type":34,"value":385},"Dimension 4 : Criticité business du module",{"type":28,"tag":36,"props":387,"children":388},{},[389],{"type":34,"value":390},"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":28,"tag":36,"props":392,"children":393},{},[394,398],{"type":28,"tag":45,"props":395,"children":396},{},[397],{"type":34,"value":123},{"type":34,"value":125},{"type":28,"tag":127,"props":400,"children":401},{},[402,407,412],{"type":28,"tag":131,"props":403,"children":404},{},[405],{"type":34,"value":406},"Identifier la criticité business : quel processus métier ce module supporte-t-il ?",{"type":28,"tag":131,"props":408,"children":409},{},[410],{"type":34,"value":411},"Évaluer l'impact d'une régression : financier, réglementaire, réputationnel",{"type":28,"tag":131,"props":413,"children":414},{},[415],{"type":34,"value":416},"Vérifier le SLA : ce module a-t-il un SLA de disponibilité ou de performance ?",{"type":28,"tag":36,"props":418,"children":419},{},[420,425],{"type":28,"tag":45,"props":421,"children":422},{},[423],{"type":34,"value":424},"Niveaux de criticité",{"type":34,"value":125},{"type":28,"tag":127,"props":427,"children":428},{},[429,439,449],{"type":28,"tag":131,"props":430,"children":431},{},[432,437],{"type":28,"tag":45,"props":433,"children":434},{},[435],{"type":34,"value":436},"Critique",{"type":34,"value":438}," : module dans le chemin de traitement principal, impact direct sur le revenu ou la conformité réglementaire",{"type":28,"tag":131,"props":440,"children":441},{},[442,447],{"type":28,"tag":45,"props":443,"children":444},{},[445],{"type":34,"value":446},"Important",{"type":34,"value":448}," : module utilisé quotidiennement, régression visible par les utilisateurs mais non-bloquante",{"type":28,"tag":131,"props":450,"children":451},{},[452,457],{"type":28,"tag":45,"props":453,"children":454},{},[455],{"type":34,"value":456},"Standard",{"type":34,"value":458}," : module d'administration, batch non-temps-réel, fonctionnalité non-critique",{"type":28,"tag":174,"props":460,"children":461},{},[462],{"type":28,"tag":36,"props":463,"children":464},{},[465,470],{"type":28,"tag":45,"props":466,"children":467},{},[468],{"type":34,"value":469},"Règle",{"type":34,"value":471}," : 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":28,"tag":56,"props":473,"children":474},{},[],{"type":28,"tag":60,"props":476,"children":478},{"id":477},"la-matrice-de-risque-et-comment-lutiliser",[479],{"type":34,"value":480},"La matrice de risque et comment l'utiliser",{"type":28,"tag":36,"props":482,"children":483},{},[484],{"type":34,"value":485},"Je combine les 4 dimensions dans une matrice simple :",{"type":28,"tag":487,"props":488,"children":489},"table",{},[490,519],{"type":28,"tag":491,"props":492,"children":493},"thead",{},[494],{"type":28,"tag":495,"props":496,"children":497},"tr",{},[498,504,509,514],{"type":28,"tag":499,"props":500,"children":501},"th",{},[502],{"type":34,"value":503},"Dimension",{"type":28,"tag":499,"props":505,"children":506},{},[507],{"type":34,"value":508},"Score 1 (faible)",{"type":28,"tag":499,"props":510,"children":511},{},[512],{"type":34,"value":513},"Score 2 (modéré)",{"type":28,"tag":499,"props":515,"children":516},{},[517],{"type":34,"value":518},"Score 3 (élevé)",{"type":28,"tag":520,"props":521,"children":522},"tbody",{},[523,547,570,593],{"type":28,"tag":495,"props":524,"children":525},{},[526,532,537,542],{"type":28,"tag":527,"props":528,"children":529},"td",{},[530],{"type":34,"value":531},"Couverture tests",{"type":28,"tag":527,"props":533,"children":534},{},[535],{"type":34,"value":536},"> 70%",{"type":28,"tag":527,"props":538,"children":539},{},[540],{"type":34,"value":541},"30-70%",{"type":28,"tag":527,"props":543,"children":544},{},[545],{"type":34,"value":546},"\u003C 30%",{"type":28,"tag":495,"props":548,"children":549},{},[550,555,560,565],{"type":28,"tag":527,"props":551,"children":552},{},[553],{"type":34,"value":554},"Compréhension métier",{"type":28,"tag":527,"props":556,"children":557},{},[558],{"type":34,"value":559},"Bien documenté",{"type":28,"tag":527,"props":561,"children":562},{},[563],{"type":34,"value":564},"Documenté partiellement",{"type":28,"tag":527,"props":566,"children":567},{},[568],{"type":34,"value":569},"Non documenté",{"type":28,"tag":495,"props":571,"children":572},{},[573,578,583,588],{"type":28,"tag":527,"props":574,"children":575},{},[576],{"type":34,"value":577},"Couplage",{"type":28,"tag":527,"props":579,"children":580},{},[581],{"type":34,"value":582},"\u003C 3 dépendances",{"type":28,"tag":527,"props":584,"children":585},{},[586],{"type":34,"value":587},"3-7 dépendances",{"type":28,"tag":527,"props":589,"children":590},{},[591],{"type":34,"value":592},"> 7 dépendances",{"type":28,"tag":495,"props":594,"children":595},{},[596,601,605,610],{"type":28,"tag":527,"props":597,"children":598},{},[599],{"type":34,"value":600},"Criticité business",{"type":28,"tag":527,"props":602,"children":603},{},[604],{"type":34,"value":456},{"type":28,"tag":527,"props":606,"children":607},{},[608],{"type":34,"value":609},"Importante",{"type":28,"tag":527,"props":611,"children":612},{},[613],{"type":34,"value":436},{"type":28,"tag":36,"props":615,"children":616},{},[617,622],{"type":28,"tag":45,"props":618,"children":619},{},[620],{"type":34,"value":621},"Score total",{"type":34,"value":125},{"type":28,"tag":127,"props":624,"children":625},{},[626,631,636],{"type":28,"tag":131,"props":627,"children":628},{},[629],{"type":34,"value":630},"4-6 points → Intervention directe possible",{"type":28,"tag":131,"props":632,"children":633},{},[634],{"type":34,"value":635},"7-9 points → Sécuriser avant d'intervenir (tests de caractérisation, documentation)",{"type":28,"tag":131,"props":637,"children":638},{},[639],{"type":34,"value":640},"10-12 points → Planifier une phase de préparation de 2-4 semaines avant toute modification",{"type":28,"tag":36,"props":642,"children":643},{},[644],{"type":34,"value":645},"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":28,"tag":56,"props":647,"children":648},{},[],{"type":28,"tag":60,"props":650,"children":652},{"id":651},"faq-sur-lévaluation-du-risque-legacy",[653],{"type":34,"value":654},"FAQ sur l'évaluation du risque legacy",{"type":28,"tag":656,"props":657,"children":658},"details",{},[659,665],{"type":28,"tag":660,"props":661,"children":662},"summary",{},[663],{"type":34,"value":664},"1. Combien de temps faut-il pour évaluer le risque d'un module legacy ?",{"type":28,"tag":36,"props":666,"children":667},{},[668],{"type":34,"value":669},"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":28,"tag":656,"props":671,"children":672},{},[673,678],{"type":28,"tag":660,"props":674,"children":675},{},[676],{"type":34,"value":677},"2. Qu'est-ce qu'un characterization test et comment l'écrire ?",{"type":28,"tag":36,"props":679,"children":680},{},[681],{"type":34,"value":682},"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":28,"tag":656,"props":684,"children":685},{},[686,691],{"type":28,"tag":660,"props":687,"children":688},{},[689],{"type":34,"value":690},"3. Comment gérer un module legacy sans aucun test et sans documentation ?",{"type":28,"tag":36,"props":692,"children":693},{},[694],{"type":34,"value":695},"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":28,"tag":656,"props":697,"children":698},{},[699,704],{"type":28,"tag":660,"props":700,"children":701},{},[702],{"type":34,"value":703},"4. Quand est-ce qu'il vaut mieux réécrire que refactoriser ?",{"type":28,"tag":36,"props":705,"children":706},{},[707],{"type":34,"value":708},"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":28,"tag":656,"props":710,"children":711},{},[712,717],{"type":28,"tag":660,"props":713,"children":714},{},[715],{"type":34,"value":716},"5. Comment convaincre l'équipe de faire une évaluation de risque systématique ?",{"type":28,"tag":36,"props":718,"children":719},{},[720,722,728],{"type":34,"value":721},"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":28,"tag":89,"props":723,"children":725},{"href":724},"/fr/pratiques-agiles/definition-of-ready-bugs-sprint",[726],{"type":34,"value":727},"Definition of Ready",{"type":34,"value":729}," 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":28,"tag":56,"props":731,"children":732},{},[],{"type":28,"tag":279,"props":734,"children":739},{"cta":735,"href":736,"title":737,"type":738},"Accéder à l'assessment gratuit →","/mes-ressources","Ressource gratuite : Engineering Maturity Self-Assessment","resource",[740],{"type":28,"tag":36,"props":741,"children":742},{},[743],{"type":34,"value":744},"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":7,"searchDepth":746,"depth":746,"links":747},2,[748,749,750,751,752,753,754],{"id":62,"depth":746,"text":65},{"id":107,"depth":746,"text":110},{"id":200,"depth":746,"text":203},{"id":296,"depth":746,"text":299},{"id":382,"depth":746,"text":385},{"id":477,"depth":746,"text":480},{"id":651,"depth":746,"text":654},"markdown","content:fr:dette-technique:legacy-code-evaluer-risque.md","content","fr/dette-technique/legacy-code-evaluer-risque.md","fr/dette-technique/legacy-code-evaluer-risque","md",1775679743581]