[{"content":" \u0026ldquo;Pas besoin de faire du bon code, le projet est déjà très legacy…\u0026rdquo; # Vous l’avez déjà entendue, n’est-ce pas ?\nBien que cela ne me fasse pas plaisir, cette réflexion est assez répandue dans l\u0026rsquo;IT.\nQue ce soit de manière consciente ou inavouée, on a tous eu au moins une fois cette pensée dans notre carrière en voyant un projet en piteux état.\nEn soi, le raisonnement peut se comprendre :\nLe code est ignoble. La solution est truffée de bugs. La logique est par endroits, voire en totalité tirée par les cheveux.\n\u0026ldquo;Pourquoi s\u0026rsquo;embêter à essayer de faire quelque chose de bien dans ce contexte ? Tu n\u0026rsquo;y es pour rien à l\u0026rsquo;état actuel des choses.\u0026rdquo; dira la petite voix.\nLa réflexion peut se comprendre, mais c\u0026rsquo;est ici que s\u0026rsquo;arrête l\u0026rsquo;avocat du diable.\nLe problème n\u0026rsquo;est vraiment pas à prendre à la légère. Il implique les devs, mais également le management, et par effet domino, l’ensemble de l’entreprise.\nMais pourquoi ? # En quelques mots, la théorie de la vitre brisée.\nLe principe est le suivant : si une fenêtre cassée d\u0026rsquo;une maison n’est pas rapidement réparée, les autres suivront. L’endroit sera perçu comme délabré, menant à plus de casse, et le cercle vicieux s’installera.\nLa théorie s\u0026rsquo;applique parfaitement à nos projets IT.\nLaisser passer l’ajout de code bancal, sous prétexte que le code existant est déjà médiocre, c’est valider sciemment que la qualité du projet ne fera que se dégrader, et que la situation va empirer.\nLa suite devient prévisible :\n→ Le backlog va continuer de grossir, et les utilisateurs vont devenir de plus en plus mécontents (à juste titre.).\n→ Le moindre correctif va prendre des allures de champ de bataille avec des devs faisant du stress post-traumatique rien qu’à l\u0026rsquo;énonciation du nom du projet (des souvenirs vous reviennent ?).\n→ Le temps et les coûts de maintenance vont exploser, au point où certains en viennent à rêver de tout refaire from scratch (à supposer qu\u0026rsquo;il y ait du budget).\n\u0026ldquo;Les développeurs n\u0026rsquo;ont qu\u0026rsquo;à se responsabiliser et le problème est réglé.\u0026rdquo; # Non. Je maintiens. Le problème implique l\u0026rsquo;ensemble de l\u0026rsquo;entreprise.\nSi un développeur seul peut penser et agir ainsi, c\u0026rsquo;est déjà qu\u0026rsquo;à la base, la culture d\u0026rsquo;entreprise et d\u0026rsquo;équipe en place ne sont pas assez fortes pour guider le groupe.\nLe code n\u0026rsquo;étant pas la propriété d\u0026rsquo;un développeur, ni même d\u0026rsquo;une équipe, mais de toute l\u0026rsquo;entreprise, c\u0026rsquo;est tout le collectif qui en paiera le prix le moment venu.\nOn fait quoi alors ? # Côté développeur, individuellement, on applique le principe bien connu \u0026ldquo;Boy Scout Rule\u0026rdquo; popularisé dans l\u0026rsquo;IT par Robert C. Martin dans son livre \u0026ldquo;Clean Code\u0026rdquo; : toujours laisser le code plus propre qu\u0026rsquo;on ne l\u0026rsquo;a trouvé à chaque intervention dans la codebase du projet.\nCela ne résoudra pas tout (par exemple l\u0026rsquo;introduction involontaire de bugs), mais ça limitera au moins les problèmes.\nCôté équipe IT, on met en place des standards d\u0026rsquo;équipe ainsi que du monitoring et du suivi de métriques définies ensemble pour suivre la progression de la qualité du code et des services. Faites attention cependant à ne pas imposer des standards qui ne sont ni compris ni acceptés par le groupe. Cela ne ferait que créer des tensions et une difficulté à faire évoluer les pratiques dans le temps. Le groupe doit rester uni avant tout pour pouvoir avancer dans la même direction.\nCôté management, on joue le rôle de médiateur et d\u0026rsquo;arbitre à la perfection : ni du côté du métier, ni des développeurs. Balancer plus d\u0026rsquo;un côté que de l\u0026rsquo;autre ne fera que causer des problèmes à terme.\nÀ ce titre, la qualité doit être un facteur d\u0026rsquo;arbitrage dans l\u0026rsquo;équation au même titre que les deadlines et le budget. Si une concession sur ce point vient à être faite pour X ou Y raison(s), il faudra très sérieusement planifier les corrections pour y remédier dans le futur. Pas juste \u0026ldquo;il faudra\u0026rdquo; (on le connait tous, le fameux \u0026ldquo;on verra plus tard\u0026rdquo; (jamais\u0026hellip;)). Planifier.\nRestez attentif aux alertes remontées par les développeurs à ce sujet.\nCes principes couvrent l\u0026rsquo;essentiel concernant la problématique initiale exposée. Cette liste reste cependant non exhaustive. Bien d\u0026rsquo;autres pratiques peuvent être mises en place pour le bien de l\u0026rsquo;équipe IT et de l\u0026rsquo;entreprise, surtout dans le cadre d\u0026rsquo;une reprise en main d\u0026rsquo;un legacy. Vous en trouverez d\u0026rsquo;autres dans les chapitres et articles de ce site.\nConclusion Les actions du passé ne doivent pas guider les actions futures. Chacun à son rôle à jouer concernant le risque de laisser-aller vis-à-vis d\u0026rsquo;une situation existante catastrophique sur un projet legacy. Cela peut être tentant, mais il faut agir collectivement pour stopper et remplacer ces mauvaises pensées et actions.\nNewsletter Reprendre le contrôle du legacy, une idée à la fois. Des réflexions sur le legacy, pour en comprendre les mécanismes et sa reprise en main. Votre adresse email S\u0026#39;inscrire Pas de spam. Désinscription en un clic. ","date":"12 juin 2025","externalUrl":null,"permalink":"/chapitres/resignation/","section":"Chapitres","summary":"","title":"\"Pas besoin de faire du bon code, le projet est déjà très legacy…\"","type":"chapitres"},{"content":" Pourquoi votre solution legacy est-elle legacy ? # Question \u0026ldquo;simple\u0026rdquo;.\nEt pourtant pas anodine\u0026hellip;\nLe premier réflexe serait probablement d\u0026rsquo;essayer d\u0026rsquo;y répondre en questionnant le passé :\nÀ partir de quand cela a commencé ? C\u0026rsquo;était quoi l\u0026rsquo;élément déclencheur ?\nEt au final de mon côté, si on se limite à ceci\u0026hellip; Je ne sais pas.\nEt probablement plus personne ne le sait.\nJe ne sais pas quand cette solution est devenue legacy.\nJe ne sais pas pourquoi cette solution est devenue legacy.\nLes personnes originelles qui ont travaillé sur ce projet ont probablement quitté la boîte depuis longtemps.\nL\u0026rsquo;équipe a dû se renouveler potentiellement plusieurs fois depuis les débuts.\nOn est à ce stade littéralement sur de l\u0026rsquo;archéologie, à essayer de déchiffrer et comprendre des choses en se basant sur ce qu\u0026rsquo;ont légué (consciemment ou non) les prédécesseurs.\nEt en toute franchise, même si par une magie incroyable, on pouvait tous les rassembler dans la même pièce et les laisser débattre, il y a des chances qu\u0026rsquo;ils ne sachent pas non plus eux-mêmes l\u0026rsquo;expliquer de manière précise\u0026hellip;\nIls donneront des faits marquants. Pourront expliquer des choix techniques et fonctionnels qui ont été pris pour X ou Y raisons liées au contexte.\nMais à la question fatidique \u0026ldquo;pourquoi la solution est legacy\u0026rdquo;, ça sera jamais une réponse décisive sans aucune contestation possible\u0026hellip;\nCependant ! # Si on reprend cette question, et qu\u0026rsquo;on réalise un tout petit pivot dans l\u0026rsquo;interprétation pour en faire \u0026ldquo;pourquoi la solution est toujours legacy\u0026hellip;\u0026rdquo;\nLà. Là on peut y arriver.\nÀ la base, fondamentalement, avoir de la dette technique n\u0026rsquo;est pas un problème.\nTous les projets finiront par en avoir pour X raisons recevables.\nTous sans exception.\nLa dette technique n\u0026rsquo;est pas en elle-même le souci. Le projet ne va pas subitement arrêter de fonctionner à son introduction.\nLes problèmes ne vont pas arriver d\u0026rsquo;un seul coup et tout mettre à mal.\nIls vont plutôt commencer d\u0026rsquo;abord petits et ponctuellement, puis s\u0026rsquo;accumuler, de plus en plus vite, devenir de plus gros en plus gros, créer des effets en chaîne\u0026hellip; jusqu\u0026rsquo;à la perte de contrôle totale de la situation.\nPour éviter ce scénario, les actions sont de prime abord \u0026ldquo;simples\u0026rdquo; (avec de très gros guillemets !) :\nMettre en place un backlog dédié à la dette technique et le maintenir à jour. Faire des points d\u0026rsquo;équipes réguliers pour quantifier la dette technique et la prioriser. Mettre en place des métriques de contrôle de la qualité des solutions, monitorer, et garder ceci en visu. Y allouer du temps Chacun de ces points mériterait de faire l’objet d’un chapitre à part entière, mais vous avez l’idée générale.\nLe problème n\u0026rsquo;a jamais été la dette technique, mais plutôt la manière dont elle a été gérée.\nDonc au final, l\u0026rsquo;interrogation intéressante n\u0026rsquo;est pas \u0026ldquo;pourquoi cette solution est devenue legacy ?\u0026rdquo; (passé).\nMais plutôt \u0026ldquo;Qu\u0026rsquo;est-ce qui est fait pour stopper la progression du legacy ?\u0026rdquo; (présent).\nEn se basant sur les éléments cités précédemment, si la réponse est rien, lancer un vaste projet de modernisation via une refonte from scratch de la solution ne réglera pas les soucis\u0026hellip;\nC\u0026rsquo;est un peu comme balayer la poussière sous le tapis, se mettre des oeillères sur les yeux, et ne pas vouloir reconnaitre le problème.\nLa dure réalité : L\u0026rsquo;équipe IT risque simplement de reproduire les mêmes erreurs avec des technologies plus modernes.\nConclusion Dans le cas d\u0026rsquo;une solution legacy, le problème n\u0026rsquo;est jamais la présence de la dette technique. Le problème est l\u0026rsquo;absence de mécanisme pour la maîtriser. Tout commence ici.\nNewsletter Reprendre le contrôle du legacy, une idée à la fois. Des réflexions sur le legacy, pour en comprendre les mécanismes et sa reprise en main. Votre adresse email S\u0026#39;inscrire Pas de spam. Désinscription en un clic. ","date":"22 juillet 2026","externalUrl":null,"permalink":"/chapitres/cause/","section":"Chapitres","summary":"","title":"Pourquoi votre solution legacy est-elle legacy ?","type":"chapitres"},{"content":" La documentation et la thématique du legacy : une grande histoire d\u0026rsquo;amour (faux). # Tout le monde dans la tech a déjà été confronté au classique :\n\u0026ldquo;Elle est où la documentation ? Ah. Y en a pas…\u0026rdquo;\nCe genre de phrase est tellement connu que c\u0026rsquo;en est devenu un running gag dans l\u0026rsquo;IT.\nElle nous évoque à tous au moins une anecdote de notre parcours, probablement douloureuse à l\u0026rsquo;époque, aujourd\u0026rsquo;hui amusante, par l\u0026rsquo;innocence du junior que nous étions.\nÀ la simple énonciation de cette phrase, le problème semble évident : l’absence de documentation.\nJ\u0026rsquo;en suis pour ma part pas convaincu…\nSi vous pensez que je délire, réfléchissez au point commun entre toutes les documentations. Elles vieillissent…\nÇa partait pourtant si bien\u0026hellip; # Une documentation, pour être pertinente, se doit d\u0026rsquo;être maintenue à jour. Or, si l\u0026rsquo;effort de créer de la documentation peut survenir, celui de la maintenir est (très) souvent négligé.\nIncroyable, pour la toute première fois, vous avez enfin accès à une documentation sur un projet. Une vraie !!!\nVotre joie sera de courte durée\u0026hellip;\nIl s\u0026rsquo;avère que le code ne fait pas ce que la documentation indique. Qui croire du coup ? La doc ou le code ? Vous êtes maintenant parti pour une longue séance d\u0026rsquo;archéologie pour comprendre l\u0026rsquo;historique, suivie d\u0026rsquo;échanges questions réponses avec le métier pour essayer de démêler le vrai du faux\u0026hellip;\nSur un projet récent, le problème est encore facilement corrigeable. Le développeur toujours présent dans l\u0026rsquo;équipe peut mettre à jour la documentation via sa mémoire à la demande.\nMais concernant un projet legacy ayant connu plusieurs vagues de développeurs depuis la dernière mise à jour de cette documentation ?\nOn pleure\u0026hellip;\nUne documentation est un mauvais support de vérité. # Malheureusement comme vous l\u0026rsquo;aurez compris, une documentation n\u0026rsquo;est pas une source fiable d\u0026rsquo;information.\nSur le principe, ça semble être une bonne idée, en pratique, c\u0026rsquo;est bien plus nuancé\u0026hellip;\nLe vrai effort de documentation d\u0026rsquo;un projet, il doit s\u0026rsquo;effectuer dans le code, et plus spécifiquement dans ses tests.\nLes tests décrivent et valident les règles métiers. C\u0026rsquo;est un contrat écrit. La règle n\u0026rsquo;est pas respectée ? Le test va casser et vous signaler qu\u0026rsquo;il va falloir soit modifier le contrat car la règle a changé, soit réparer le code pour maintenir le contrat existant.\nLa documentation classique ne vous dira jamais quand elle n\u0026rsquo;est plus à jour…\nC’est d\u0026rsquo;ailleurs le même problème avec les commentaires dans le code. Si un commentaire se contente de décrire ce que le code fait, il finira lui aussi à son tour par vieillir et ne plus être à jour… Il faut au maximum limiter son usage uniquement au strict nécessaire pour exprimer ce que le code ne peut pas décrire.\nEst-ce qu\u0026rsquo;on doit alors abandonner l\u0026rsquo;effort d\u0026rsquo;écriture d\u0026rsquo;une documentation classique ? # Non. Bien sûr que non.\nIl reste des choses que le code et les tests ne peuvent expliquer.\nPar exemple :\nÀ quoi sert le projet, l\u0026rsquo;objectif La première prise en main Les choix d\u0026rsquo;architecture importants Les raisons d\u0026rsquo;un choix de prime abord contestable Etc. Autrement dit, le contexte.\nDans une solution legacy, bien souvent le code et les tests (trop peu nombreux ou manquants) n\u0026rsquo;arrivent plus à jouer ce rôle. Et c\u0026rsquo;est ainsi qu\u0026rsquo;on se met à empiler de la documentation écrite en long et en large pour tout afin de compenser.\nPourtant, le principe reste toujours le même. Si la solution n\u0026rsquo;est pas explicite, c’est qu\u0026rsquo;il faut la modifier progressivement pour qu\u0026rsquo;elle le devienne.\nÀ chaque changement dans le projet, on clarifie le code et on ajoute des tests qui décrivent le comportement métier attendu.\nDe cette manière, on fiabilise l\u0026rsquo;information en la rendant incontestable.\nAu final, la meilleure documentation, c\u0026rsquo;est celle qu\u0026rsquo;on n\u0026rsquo;a pas besoin d’écrire.\nConclusion Le code décrit ce que le système fait. Les tests formalisent et vérifient ce qui est attendu. La documentation explique pourquoi c\u0026rsquo;est fait ainsi.\nNewsletter Reprendre le contrôle du legacy, une idée à la fois. Des réflexions sur le legacy, pour en comprendre les mécanismes et sa reprise en main. Votre adresse email S\u0026#39;inscrire Pas de spam. Désinscription en un clic. ","date":"27 juillet 2026","externalUrl":null,"permalink":"/chapitres/information/","section":"Chapitres","summary":"","title":"La documentation et la thématique du legacy : une grande histoire d'amour (faux).","type":"chapitres"},{"content":" Le problème avec le legacy n\u0026rsquo;est bien souvent pas dans le code. C\u0026rsquo;est un leurre. # À première vue, cette affirmation peut sembler surprenante.\nQuand une solution devient difficile à maintenir, truffé de bugs, avec des régressions à chaque modification, et dont plus personne n\u0026rsquo;en comprend le fonctionnement, on peut assez facilement affirmer :\nLe code est mauvais.\nEt en soit, c\u0026rsquo;est probablement le cas.\nCependant, allons jusqu\u0026rsquo;au bout du raisonnement.\nQui a produit ce code ? Les développeurs.\nQuestion :\n\u0026ldquo;Est-ce que pour chaque solution legacy, il y avait des mauvais développeurs ?\u0026rdquo;\nÉvidemment que non.\nMême la meilleure des équipes, constituée exclusivement de développeurs seniors, peut produire une solution legacy.\nJ\u0026rsquo;ai déjà vu ce scénario se produire. Probablement vous aussi.\nSi la compétence de l\u0026rsquo;équipe n\u0026rsquo;explique pas à elle seule l\u0026rsquo;apparition du legacy, alors qu\u0026rsquo;est-ce qui l\u0026rsquo;explique ?\nContinuons sur ce scénario.\nNous avons maintenant une équipe très compétente, qui a produit une solution legacy via du mauvais code.\nBien\u0026hellip; Pourquoi ils ont fait ça ???\nAjout d\u0026rsquo;une variable à l\u0026rsquo;équation. # Depuis le début, on parle de legacy, mais au final, c\u0026rsquo;est quoi une solution legacy ? Les définitions varient, cependant il y a consensus sur un point : la présence d\u0026rsquo;une dette technique conséquente. Une \u0026ldquo;dette\u0026rdquo;.\nNos développeurs seniors ont généré, volontairement ou non, de la dette.\nPourquoi ?\nC\u0026rsquo;est ici que nous devons introduire une nouvelle variable à notre équation :\nLe business.\nQuand un développeur modifie ou introduit une fonctionnalité via du code, il le fait généralement pour répondre à une demande du business.\nUn développeur pour y arriver doit faire avec les exigences et contraintes qu\u0026rsquo;on lui impose pour diverses raisons : les deadlines, le budget, les urgences à résoudre, etc.\nQuand ces contraintes deviennent trop importantes, face à la nécessité de devoir avancer et vite, des compromis peuvent être pris pour réduire le temps de développement au détriment de la qualité du code.\nDe la dette technique est alors introduite dans le projet. Dette qui, comme son nom l\u0026rsquo;indique, devra être remboursée dans le futur.\nMalheureusement, si vous constatez aujourd\u0026rsquo;hui cette dette, vous l\u0026rsquo;aurez compris : elle n\u0026rsquo;a pas été remboursée.\nPire. Elle a grossi.\nD\u0026rsquo;abord, probablement car d\u0026rsquo;autres dettes ont été contractées entre-temps.\nEnsuite, tout comme pour un prêt bancaire, une dette engendre des intérêts.\nPlus la dette est remboursée tardivement, plus l\u0026rsquo;effort à fournir pour y arriver sera important.\nCette dernière ayant entre-temps probablement créé d\u0026rsquo;autres problèmes et contraintes via son existence.\nPourquoi la dette technique n\u0026rsquo;est pas remboursée ? # Car il n\u0026rsquo;y a pas eu d\u0026rsquo;arbitrage pour la rembourser. Tant que le \u0026ldquo;GO\u0026rdquo; n\u0026rsquo;est pas donné, avec un plan d\u0026rsquo;action et du temps alloué, le problème reste reporté à plus tard.\nProblème, le temps et le budget sont limités. Du temps alloué au remboursement de la dette, c\u0026rsquo;est du temps qui ne sera pas alloué à des demandes du business.\nÀ la différence du métier, qui réclamera si sa demande n\u0026rsquo;est pas prise en compte assez vite, personne, mis à part peut-être les développeurs, ne viendra réclamer des actions vis à vis de la dette technique.\nEt vu que de part nature, dans l\u0026rsquo;IT, nous sommes très souvent à flux tendu en continu, à recevoir constamment des nouvelles demandes, des urgences, des imprévus, etc. On reportera toujours ceci à plus tard.\nLe \u0026ldquo;plus tard\u0026rdquo; n\u0026rsquo;arrivera jamais. On repoussera ainsi le problème jusqu\u0026rsquo;à ce que la situation devienne incontrôlable.\nC\u0026rsquo;est bien souvent ici que le piège finit par se refermer.\nCela finit souvent par se traduire par une refonte from scratch dite big-bang du projet initial, quand le budget le permet (avec son lot de nouveaux problèmes, voir mon article dédié à ce sujet).\nVoilà, nous avons maintenant vu ensemble les deux faces de l\u0026rsquo;iceberg.\nLa présence de la dette technique sur la partie \u0026ldquo;visible\u0026rdquo; (via les problèmes qu\u0026rsquo;elle génère). Et les arbitrages organisationnels qui ont repoussé son remboursement jusqu\u0026rsquo;à ce qu\u0026rsquo;elle soit incontrôlable dans la partie immergée. Donc pour conclure, bien souvent le problème avec le legacy, c\u0026rsquo;est avant tout un problème organisationnel.\nHeureusement, un arbitrage, ça peut toujours être réévalué.\nConclusion Le problème avec le legacy n\u0026rsquo;est bien souvent pas dans le code. C\u0026rsquo;est un leurre. L\u0026rsquo;origine du problème vient de l\u0026rsquo;absence d\u0026rsquo;arbitrage pour rembourser la dette technique qui a été contractée.\nNewsletter Reprendre le contrôle du legacy, une idée à la fois. Des réflexions sur le legacy, pour en comprendre les mécanismes et sa reprise en main. Votre adresse email S\u0026#39;inscrire Pas de spam. Désinscription en un clic. ","date":"3 août 2026","externalUrl":null,"permalink":"/chapitres/coupable/","section":"Chapitres","summary":"","title":"Le problème avec le legacy n'est bien souvent pas dans le code. C'est un leurre.","type":"chapitres"},{"content":" Une solution legacy est un joyau à polir.\nOui, vous avez bien lu.\nIl est vrai que nous autres développeurs adorons nous en plaindre en y rajoutant à chaque fois une couche (sport national !).\nPourtant, d\u0026rsquo;une certaine manière, vous avez devant vous un petit miracle.\nQuand on pense legacy, on a tout de suite en tête cette application avec du code spaghetti alambiqué, des bugs mystiques, un filet de sécurité via des tests faible, voire inexistant.\nOn pourrait débattre durant des jours et des jours sur comment cela aurait dû être fait, comment on referait le projet via une page blanche, etc. etc. …\nMais ce serait oublier ce qui a déjà été accompli.\nSi cette solution legacy existe aujourd\u0026rsquo;hui, c\u0026rsquo;est que par le passé, suite à un long processus d\u0026rsquo;échanges et d\u0026rsquo;itérations avec le métier et l\u0026rsquo;équipe IT, probablement au terme d\u0026rsquo;un véritable parcours du combattant, cela a fini par donner naissance à ce projet, qui, globalement, répond au besoin métier.\nDans la majorité des cas, la difficulté principale pour un projet informatique n\u0026rsquo;est pas sur l\u0026rsquo;aspect technique, mais le facteur humain : comprendre le besoin, le traduire en des usages, débattre, faire des compromis, des adaptations…\nVous avez devant vous une base de connaissances. Tout ceci est désormais acquis.\nLa suite reste à écrire. Polir cette pierre brute pour en faire un joyau demandera du temps, de la méthode et beaucoup d\u0026rsquo;efforts. Mais à partir de maintenant, en prenant le bon cap et en y mettant l\u0026rsquo;énergie nécessaire, atteindre une solution qui répondra aux exigences de l\u0026rsquo;IT et du métier est à portée de main.\nConclusion Le legacy n’est pas un poids à traîner, mais un acquis à valoriser. Le potentiel est là.\nNewsletter Reprendre le contrôle du legacy, une idée à la fois. Des réflexions sur le legacy, pour en comprendre les mécanismes et sa reprise en main. Votre adresse email S\u0026#39;inscrire Pas de spam. Désinscription en un clic. ","date":"20 juillet 2026","externalUrl":null,"permalink":"/chapitres/valeur/","section":"Chapitres","summary":"","title":"Une solution legacy est un joyau à polir.","type":"chapitres"},{"content":" \u0026ldquo;Sur un projet tech existant, refactoriser sans tests, c\u0026rsquo;est okay ?\u0026rdquo;\nLa réponse évidente serait de répondre un \u0026ldquo;non\u0026rdquo; catégorique.\nLe raisonnement se base sur l\u0026rsquo;une des raisons d\u0026rsquo;être des tests : sécuriser la solution face aux régressions.\nAgir sur un code sans tests, c\u0026rsquo;est littéralement marcher dans un champ de mines.\nTout changement, aussi minime soit-il, peut introduire des bugs et des régressions sur l\u0026rsquo;existant sans prévenir.\nL\u0026rsquo;image est facile à comprendre. Pas besoin d\u0026rsquo;en dire beaucoup plus.\nDans n\u0026rsquo;importe quel contexte normal, le sujet s\u0026rsquo;arrêterait ici. Tout serait parfait. Super !\nSauf que\u0026hellip; # Sauf qu\u0026rsquo;on traite ici de legacy. Et malheureusement, legacy n\u0026rsquo;est pas synonyme de belle prairie avec un champ de fleurs à perte de vue, mais bien de ce champ de mines mentionné précédemment, avec en prime les barbelés pour la déco.\nLa situation n\u0026rsquo;est clairement pas aussi simple et limpide que le contexte idéal qu\u0026rsquo;on aimerait avoir.\nDans notre contexte, si on s\u0026rsquo;arrête au concept de base \u0026ldquo;on ne modifie jamais du code sans tests\u0026rdquo;, à moins d\u0026rsquo;avoir les moyens financiers et opérationnels à la hauteur de ces exigences et ambitions, cela va devenir extrêmement difficile d\u0026rsquo;espérer pouvoir avancer et débloquer la situation.\nJe veux que ce soit sans risques, pas cher, et rapide.\n— La désillusion\nPour mieux le comprendre, voici une mise en situation :\nMise en situation # Dans ce scénario, nous avons une solution legacy massive avec une couverture de tests faible à la limite de l\u0026rsquo;inexistant, comportant un nombre conséquent de tests obsolètes ou inefficaces.\nL\u0026rsquo;équipe est constituée de quelques développeurs et d\u0026rsquo;un budget limité.\nLe métier reste disponible, mais avec un temps limité à nous consacrer.\nDonc tout d\u0026rsquo;abord, les méthodes traditionnelles :\nOption 1 : Partir dans l\u0026rsquo;optique qu\u0026rsquo;il faut réaliser des tests classiques avant d\u0026rsquo;agir. Malheureusement, en l\u0026rsquo;état le code n\u0026rsquo;est pas testable. Il n\u0026rsquo;a pas été conçu avec cela à l\u0026rsquo;esprit.\nOption 2 : Faire un strangler fig pattern (faire cohabiter une nouvelle solution avec l\u0026rsquo;ancienne et remplacer progressivement le legacy). Sauf que cela est en soi un nouveau projet à part entière, nécessitant du budget dédié et un engagement sur la durée.\nOption 3 : Faire des tests de caractérisation (réaliser des tests via des captures du comportement existant). Cela aurait probablement été la meilleure solution ici. Malheureusement cette approche est, elle aussi, un investissement important à faire pour pouvoir identifier les comportements que l\u0026rsquo;on souhaite capturer avec l\u0026rsquo;aide du métier et ainsi construire un jeu de données représentatif.\n3 options, mais aucune qui ne convienne vraiment avec notre scénario initial\u0026hellip;\nC\u0026rsquo;est foutu ? # Si on reste sur cette idée de ne vouloir prendre aucun risque et d\u0026rsquo;attendre un alignement parfait des astres, voire peut-être d\u0026rsquo;un miracle, alors oui, c\u0026rsquo;est probablement foutu. Le projet est condamné.\nCependant\u0026hellip;\nSi on commence à réfléchir en termes de compromis\u0026hellip; Il nous reste des cartes à jouer.\nOn pourrait très bien avancer par mini-itération ciblée avec un commit à chaque avancée (commit atomique), en commençant toujours par le plus facile et moins risqué (renommage automatique via IDE, découpage du code, supprimer le code mort, etc.) et en compilant / testant manuellement régulièrement pour s\u0026rsquo;assurer que cela fonctionne toujours.\nUne fois le code modifié, en le rendant au passage cette fois testable, on pourrait maintenant faire des tests pour verrouiller la progression face au legacy.\nEn réalisant ceci, nous passons d\u0026rsquo;une situation où la dette technique avait la mainmise sur le projet et dont aucune action n\u0026rsquo;était envisageable, à une situation où nous pouvons maintenant progressivement améliorer le code en acceptant un risque maîtrisé et proportionné.\nC\u0026rsquo;est quand même un peu plus encourageant non ?\nLa gestion du risque # Le risque est une variable, au même titre que le coût, le temps, et la qualité. Tout est une question de compromis.\nDans cette situation de compromis à faire, il reste bien évidemment important de prendre en considération la criticité des sections qui constituent le legacy. On ne va pas appliquer le même niveau de risque entre le service de paiement et un autre module très secondaire.\nLa stratégie s\u0026rsquo;adapte selon le contexte et n\u0026rsquo;a aucunement besoin d\u0026rsquo;être appliquée uniformément sur l\u0026rsquo;ensemble du projet.\nEt oui, comme vous l\u0026rsquo;aurez compris, même en prenant toutes les garanties du monde, il est possible que nous introduisions quand même un bug.\nMais prenez cependant également en considération le scénario où nous aurions décidé de ne rien faire : nous aurions simplement choisi de ne pas prendre de risque aujourd\u0026rsquo;hui, au prix d\u0026rsquo;un risque futur plus grand.\nNe pas prendre de décision, en legacy, c\u0026rsquo;est tout de même prendre une décision, celle de laisser la dette technique grossir.\nConclusion L\u0026rsquo;inaction et l\u0026rsquo;immobilisme ont un coût réel qui se paiera le moment venu. Prendre conscience qu\u0026rsquo;on peut agir en gérant le risque, c\u0026rsquo;est déjà faire un grand pas vers la reprise en main de la situation.\nNewsletter Reprendre le contrôle du legacy, une idée à la fois. Des réflexions sur le legacy, pour en comprendre les mécanismes et sa reprise en main. Votre adresse email S\u0026#39;inscrire Pas de spam. Désinscription en un clic. ","date":"29 juillet 2026","externalUrl":null,"permalink":"/chapitres/risque/","section":"Chapitres","summary":"","title":"Sur un projet tech existant, refactoriser sans tests, c'est okay ?","type":"chapitres"},{"content":" Vous venez d\u0026rsquo;arriver sur un projet. Surprise. Vous découvrez une solution ayant des problèmes cumulés avec le temps : documentation absente, tests cassés ou inexistants, des soucis de CI/CD, \u0026hellip;\nAgissez. Prenez l\u0026rsquo;initiative de commencer à résoudre des manquements. Toute amélioration commence par une initiative et une première pierre établie.\nÇa paraît niais n\u0026rsquo;est-ce pas ? C\u0026rsquo;est assumé.\nJe n\u0026rsquo;ai encore jamais vu de collègues dans une équipe s\u0026rsquo;être consternés après que moi ou un autre collègue arrivant aient entamé de petites améliorations pour le collectif. Elles sont pratiquement toujours les bienvenues.\nL\u0026rsquo;essentiel étant de commencer petit, et de prévenir rapidement pour être sûr que cela ne causera pas de soucis.\nLe pire qui puisse arriver ?\nOn vous dira que cela n\u0026rsquo;est pas nécessaire et que vous pouvez arrêter. Et c\u0026rsquo;est tout.\nLe mieux qui puisse arriver ?\nVotre initiative a commencé à prendre de l\u0026rsquo;ampleur à mesure que vous y avez passé un peu de temps par ici et par là. D\u0026rsquo;autres collègues ont commencé à vous prêter main-forte en voyant vos efforts, et à vous tous, vous avez réalisé quelque chose ayant un réel impact pour tout le monde de manière durable.\nEn appliquant ceci, j\u0026rsquo;ai déjà vu des améliorations significatives se faire, comme une structuration du ticketing, de la gestion de la documentation, la mise en place de pratiques DevOps en partant de rien, la réduction de dettes techniques, \u0026hellip;\nL\u0026rsquo;effet boule de neige peut vraiment avoir un impact significatif.\nGardez cependant à l\u0026rsquo;esprit que vous n\u0026rsquo;avez probablement pas encore la compréhension globale de la situation. Par conséquent, prenez le temps pour observer la situation, posez des questions et essayez sincèrement de comprendre pourquoi les choses sont ainsi. Votre action n\u0026rsquo;en sera que plus juste.\nPour finir, je rajouterai que bien souvent les personnes en place ont fini par s\u0026rsquo;habituer aux problèmes de fond, et s\u0026rsquo;y sont accommodées. Cela ne veut pas dire qu\u0026rsquo;elles apprécient la situation.\nEn tant que personne arrivante, c\u0026rsquo;est aussi votre job d\u0026rsquo;essayer d\u0026rsquo;apporter un regard nouveau.\nConclusion Les problèmes latents ne disparaîtront pas d’eux-mêmes. Soyez celui qui pose la première pierre.\nNewsletter Reprendre le contrôle du legacy, une idée à la fois. Des réflexions sur le legacy, pour en comprendre les mécanismes et sa reprise en main. Votre adresse email S\u0026#39;inscrire Pas de spam. Désinscription en un clic. ","date":"13 août 2026","externalUrl":null,"permalink":"/chapitres/initiative/","section":"Chapitres","summary":"","title":"Problèmes latents ? Prenez l'initiative !","type":"chapitres"},{"content":"Article en cours de rédaction.\nLa publication de cet article sera annoncée sur LinkedIn et sur la newsletter.\nNewsletter Reprendre le contrôle du legacy, une idée à la fois. Des réflexions sur le legacy, pour en comprendre les mécanismes et sa reprise en main. Votre adresse email S\u0026#39;inscrire Pas de spam. Désinscription en un clic. ","date":"27 septembre 2026","externalUrl":null,"permalink":"/articles/cest-quoi-le-probleme-avec-la-refonte-big-bang-dun-legacy/","section":"Articles","summary":"","title":"[En cours d'écriture] - C'est quoi le problème avec la refonte big-bang d'un legacy ?","type":"articles"},{"content":" Un article, un sujet de fond. Pour prendre le temps d\u0026rsquo;explorer ensemble une problématique. ","date":"27 septembre 2026","externalUrl":null,"permalink":"/articles/","section":"Articles","summary":"","title":"Articles","type":"articles"},{"content":"","date":"27 septembre 2026","externalUrl":null,"permalink":"/categories/articles/","section":"Categories","summary":"","title":"Articles","type":"categories"},{"content":"","date":"27 septembre 2026","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"27 septembre 2026","externalUrl":null,"permalink":"/tags/dette-technique/","section":"Tags","summary":"","title":"Dette technique","type":"tags"},{"content":"","date":"27 septembre 2026","externalUrl":null,"permalink":"/tags/legacy/","section":"Tags","summary":"","title":"Legacy","type":"tags"},{"content":" Articles et chapitres que je recommande en particulier de lire. Un aperçu du contenu de ce site. Il y en a bien d\u0026rsquo;autres à découvrir. ","date":"27 septembre 2026","externalUrl":null,"permalink":"/tags/ma-selection/","section":"Tags","summary":"","title":"Ma sélection","type":"tags"},{"content":" Voir ma sélection Un projet legacy n\u0026rsquo;est pas une fatalité, encore moins une solution condamnée à être jetée et remplacée. ","date":"27 septembre 2026","externalUrl":null,"permalink":"/","section":"Reprenez en main votre legacy.","summary":"","title":"Reprenez en main votre legacy.","type":"page"},{"content":"","date":"27 septembre 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":" Vianney DOLEANS\nDéveloppeur freelance C# .NET, spécialisé dans la reprise en main de projets legacy.\nMon expertise # J’aide les équipes IT à reprendre le contrôle de leur solution à forte dette technique pour retrouver la confiance des équipes métiers.\nQuand l’équipe IT perd cette confiance en raison de bugs récurrents, de régressions, de l’instabilité des plateformes, d’incapacités à quantifier les deadlines, d’incidents en production à répétition, c’est qu’il est grand temps d’agir.\nMa conviction : la refonte big bang n’est presque jamais la solution # Dans la majorité des cas, une refonte from scratch dite big bang est une erreur qui finira par coûter cher à l’entreprise. Une solution ne devient jamais legacy par hasard.\nLes problèmes de fond qui ont conduit à l’apparition de la situation existante finiront par ressurgir, causant à nouveau les mêmes problèmes.\nVia mon intervention, j’assure une reprise en main progressive et méthodique de l’existant avec l’équipe IT, afin d’assurer une réelle reprise de contrôle durable des systèmes.\nMa méthode # Faire avec les moyens du bord, assurément, mais pas dans la panique !\nLe code et l’architecture ne sont qu’une partie du problème.\nLa priorité avant toute chose est de s\u0026rsquo;assurer qu\u0026rsquo;il soit possible de livrer et répondre rapidement aux problèmes qui pourraient survenir.\nEn conséquence, plusieurs indispensables sont à revoir en parallèle du code :\nPermettre aux équipes de livrer et d’intervenir rapidement, idéalement plusieurs fois par semaine (et cela de manière sereine !!!). Mettre en place ou améliorer le monitoring existant. Revoir la gestion du ticketing lorsqu’elle est insuffisante. Fiabiliser les livraisons et réduire drastiquement les risques de régressions. Au global, il est nécessaire d\u0026rsquo;introduire une méthodologie et une culture de travail permettant d\u0026rsquo;envisager la suite serreinement.\n⚡ Ma particularité : je suis du genre tenace et je n’en démords pas.\n⚡ La finalité : Tout est mis en oeuvre pour que le métier puisse être satisfait du service rendu par l’IT, tout en capitalisant sur la combativité et l’envie d’agir de l’équipe IT.\nMa stack # C# .NET 4.8 / .NET 10 ASP.NET React WPF / MVVM DDD CQRS Clean architecture Testing CI/CD \u0026amp; DevOps Azure Elastic Stack (ELK) SonarQube Me contacter # Vous pouvez me joindre par LinkedIn pour une première prise de contact.\nMon parcours # Développeur fullstack .NET / React 2025 - aujourd\u0026#39;hui Groupe IRCEM · Freelance Mission en cours chez l\u0026rsquo;IRCEM.\nC# · .NET (4.8 \u0026amp; 10) · React · DDD · Clean architecture\nDéveloppeur fullstack .NET / .NET Core / DevOps 2022 - 2025 ABILWAYS (SKOLAE Formation) · Freelance Intégration d’une équipe (DSI, 6 développeurs seniors) dans le cadre d’une transformation du SI de l’entreprise (centre de formation), majoritairement legacy, sans CI/CD, et avec pour unique environnement la production.\nReprise en main et modernisation d’applications legacy en .NET 4.8 : clean code, refactoring, testing, monitoring, évolutions. Passage à .NET 8 pour la majorité d’entre elles. Réalisation de nouveaux projets dans le cadre de la structuration du SI : API de mailing avancé globale aux solutions de la société, API de gestion des réunions (Teams, Webex), intégration d’API tierces (Pipedrive, Edusign…). Couverture de tests avoisinant les 80 % dans la majorité des cas. Lead sur la mise en place des pratiques DevOps : création et standardisation avancée des pipelines CI/CD pour l’ensemble des applications, réduction du temps des cycles de livraison, mise en place de SonarQube, création des environnements (DEV, UAT, PRE-PROD), automatisations sur des composants tels que les bases de données et les instances Elasticsearch. Le travail réalisé en 3 ans a permis le retour à un système d’information stable, une réduction significative des incidents et de leurs criticités, ainsi qu’une amélioration nette de la satisfaction des équipes métiers.\nC# · .NET (4.8 \u0026amp; 8) · DevOps · DDD · CQRS · Clean architecture · Testing · JavaScript · Elasticsearch · Microservices · Monolithe · Azure AD · Elastic Stack (ELK) · Kibana · SQL Server · Redis\nDéveloppeur backend .NET / .NET Core 2021 Meritis · Freelance Intervention dans le cadre d’une évolution du SI de l’entreprise Meritis (ESN) afin de répondre à son besoin de faire évoluer ses process de recrutement.\nDéveloppement d’une API .NET 6 pour assurer la communication des différentes plateformes utilisées pour le recrutement (Salesforce, SmartRecruiters, Talentsoft…). Le projet a une couverture de tests de 75 %, est documenté et respecte les bonnes pratiques de développement.\nL’API était à l’origine en .NET Framework 4.8 avant mon arrivée (projet commencé depuis ≈ 2 mois) ; j’ai réalisé plus tard sa migration vers .NET Core. Les enjeux étaient nombreux : performance, historisation des transactions, gestion du suivi des candidats, besoins et règles métiers, sécurité, temps.\nC# · .NET / .NET Core · Testing · Clean code · Azure · SQL Server\nDéveloppeur fullstack C# / .NET 2020 Stereograph · Freelance Développement avec l’équipe des développeurs sur la solution web Teia (BIM d’exploitation pour les métiers du smart building).\nDéveloppements sur la solution monolithe en ASP.NET MVC. Participation à la réalisation des premiers tests de la solution. Démarrage de la rédaction d’une documentation technique interne et force de proposition concernant les outils à mettre en place (wiki, documentations, formatage des tickets support). Étude sur les solutions concurrentes (fonctionnalités, avantages) et benchmarks. C# · .NET · ASP.NET MVC · Testing · JavaScript · jQuery · SQL Server\nDéveloppeur C# / .NET \u0026amp; .NET Core 2020 Isogeo · Freelance Réalisation en prestation de service d’un plugin pour intégrer les services de l’entreprise Isogeo au logiciel Esri ArcGIS Pro (cartographie et analyse 3D, géomatique) à destination de ses clients finaux. En production depuis 2020.\nRéalisation d’un plugin optimisé et performant avec une architecture moderne (MVVM, clean code, design patterns, modularité et indépendance des composants). Cadrage du projet et de la roadmap. Challenge du métier concernant les besoins et affinage des spécifications. Produit délivré avec une documentation wiki étoffée et un transfert de connaissances. Depuis sa mise en service en 2020, le plugin a connu moins de 10 bugs confirmés et corrigés. Il a parallèlement reçu des évolutions de ma part, dont une montée de version de .NET Framework 4.8 vers .NET 6, ainsi qu’une restructuration d’une partie du système permettant notamment de diviser par 3 les temps de chargement.\nD’autres missions ont été réalisées en parallèle :\nAudit pour étude de migration vers .NET Core de l’API .NET 4.8 de l’entreprise. Intervention lors d’une situation de crise impactant la production (investigation, résolution, préconisations à l’équipe du client pour le futur). Formation avec plan détaillé donnée au nouveau développeur back-end arrivant chez le client. C# · .NET / .NET Core · Clean code · WPF · MVVM · SQL Server · Azure\nDéveloppeur backend C# .NET / DevOps 2019 - 2020 Isogeo · temps partiel Intervention dans le cadre du démarrage de la volonté de l’entreprise de reprise en main de son API .NET legacy.\nDéveloppements pour assurer la maintenance corrective. Réalisation from scratch du CI/CD (Azure DevOps). Migration de l’API vers le cloud (Azure App Service). Démarrage d’un travail de documentation technique de l’API ainsi que rédaction de tutoriels et documentations pour faciliter la prise en main de celle-ci. Assistance au lead dev pour encadrer et former la nouvelle recrue front-end. C# · .NET · ASP.NET · CI/CD · Azure · Azure DevOps · SQL Server\nDéveloppeur C# / .NET - Stage 2018 SEMERU · Fayat Énergie Services Développements réalisés sur un logiciel de gestion dans le cadre de l’installation des portillons sur le métro lillois, ainsi que divers projets liés à la société Transpole (Ilévia).\nDéveloppements sur l’automatisation des portillons du métro de Lille. Développements sur des technologies propriétaires (API, SDK) ainsi que sur un protocole open source (ONVIF) pour le contrôle de caméras de surveillance. Développements concernant le logiciel de gestion des infrastructures du métro lillois (Ilévia). C# · .NET · WPF · WinForms · SQL Server\n","date":"18 août 2026","externalUrl":null,"permalink":"/about/","section":"Reprenez en main votre legacy.","summary":"","title":"À propos de moi","type":"page"},{"content":"","date":"13 août 2026","externalUrl":null,"permalink":"/categories/chapitres/","section":"Categories","summary":"","title":"Chapitres","type":"categories"},{"content":" Un chapitre, une idée, une conclusion. Des textes courts, indépendants, qui explorent chacun une facette du legacy. Les chapitres sont complémentaires et permettent d\u0026rsquo;assembler une vision globale du legacy. ","date":"13 août 2026","externalUrl":null,"permalink":"/chapitres/","section":"Chapitres","summary":"","title":"Chapitres","type":"chapitres"},{"content":"","date":"13 août 2026","externalUrl":null,"permalink":"/tags/etat-desprit/","section":"Tags","summary":"","title":"État d'esprit","type":"tags"},{"content":"","date":"13 août 2026","externalUrl":null,"permalink":"/tags/organisation/","section":"Tags","summary":"","title":"Organisation","type":"tags"},{"content":"","date":"13 août 2026","externalUrl":null,"permalink":"/tags/qualite-logicielle/","section":"Tags","summary":"","title":"Qualité logicielle","type":"tags"},{"content":"","date":"3 août 2026","externalUrl":null,"permalink":"/tags/management/","section":"Tags","summary":"","title":"Management","type":"tags"},{"content":"","date":"29 juillet 2026","externalUrl":null,"permalink":"/tags/tests/","section":"Tags","summary":"","title":"Tests","type":"tags"},{"content":"","date":"27 juillet 2026","externalUrl":null,"permalink":"/tags/documentation/","section":"Tags","summary":"","title":"Documentation","type":"tags"},{"content":"","date":"20 juillet 2026","externalUrl":null,"permalink":"/tags/evolution/","section":"Tags","summary":"","title":"Évolution","type":"tags"},{"content":" Newsletter Inscription confirmée Votre inscription est officiellement confirmée. Vous figurez désormais sur la liste. Vous recevrez bientôt de superbes mails pour rester informé des dernières publications. ","externalUrl":null,"permalink":"/newsletter-confirmation-inscription/","section":"","summary":"","title":"","type":"newsletter-confirmation-inscription"},{"content":" Newsletter Demande bien reçue. Vérifiez votre boîte e-mail et cliquez sur le lien de confirmation pour finaliser votre inscription. ","externalUrl":null,"permalink":"/newsletter-mail-confirmation/","section":"","summary":"","title":"","type":"newsletter-mail-confirmation"},{"content":" Le contenu # J\u0026rsquo;écris personnellement l\u0026rsquo;ensemble du contenu présent sur ce site en m\u0026rsquo;appuyant sur mon expérience et mon vécu.\nToutes les informations sont vérifiées en multipliant les sources.\nL\u0026rsquo;IA n\u0026rsquo;a ici qu\u0026rsquo;une place minime. Je peux m\u0026rsquo;appuyer sur celle-ci pour améliorer des tournures de phrases ou prendre du recul sur la qualité du contenu produit, mais les textes sont bien de moi et reflètent ma pensée.\nJe fais sincèrement de mon mieux pour créer une ligne éditoriale cohérente et intéressante, qui soit en accord avec mes valeurs et les messages que je veux transmettre.\nDans cette optique, les articles et chapitres sont mis à jour quand je le juge nécessaire pour assurer la mission du site.\nJ\u0026rsquo;espère vraiment que ce site pourra vous être utile.\nBonne lecture !\nSi jamais vous voulez discuter avec moi sur le sujet, n\u0026rsquo;hésitez pas, ce serait avec grand plaisir. Vous pouvez me contacter via LinkedIn.\nLe site # Site réalisé avec Hugo et Blowfish\n","externalUrl":null,"permalink":"/siteinformation/","section":"Reprenez en main votre legacy.","summary":"","title":"Informations du site","type":"page"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"}]