Développement

Refactoriser un projet legacy : méthode et pièges à éviter

J

Fondateur, Ateia Digital

Illustration de l'article : Refactoriser un projet legacy : méthode et pièges à éviter

Pourquoi refactoriser un projet legacy ?

Chaque développeur a déjà ouvert un projet existant en se demandant : "Qui a écrit ça… et pourquoi ?". Un projet legacy, ce n'est pas forcément du mauvais code. C'est du code qui a survécu, qui a été modifié par plusieurs mains, souvent sans documentation, et qui aujourd'hui freine l'évolution du produit.

Chez Ateia Digital, on intervient régulièrement sur des bases de code existantes. Refactoriser, ce n'est pas tout réécrire. C'est améliorer sans casser, progressivement, avec méthode.


Étape 1 — Auditer avant de toucher une ligne

Avant de modifier quoi que ce soit, on prend le temps de comprendre l'existant. C'est la règle numéro un.

lightbulb

Un refactoring raté commence toujours par un développeur qui a voulu aller trop vite.

Concrètement, voici ce qu'on fait :

  • Cartographier les dépendances : quels modules parlent à quels autres ? On utilise des outils comme madge (JS) ou deptrac (PHP) pour visualiser le couplage.
  • Identifier les zones critiques : quelles parties du code sont modifiées le plus souvent ? Un git log --oneline --all | wc -l sur chaque dossier donne déjà une bonne idée.
  • Lister les tests existants : s'il y en a. S'il n'y en a pas, c'est la première chose à poser.

Étape 2 — Sécuriser avec des tests avant de refactoriser

On ne refactore jamais sans filet. Si le projet n'a aucun test, on commence par écrire des tests de caractérisation : des tests qui documentent le comportement actuel du code, même s'il est buggé.

L'objectif n'est pas de valider que le code est correct, mais de détecter tout changement de comportement introduit par le refactoring.

Outils qu'on utilise selon le contexte :

  • Jest ou Vitest pour le JS/TS
  • PHPUnit pour le PHP
  • Cypress ou Playwright pour les tests E2E en dernier recours

Étape 3 — Refactoriser par petits incréments

La tentation est toujours la même : tout réécrire d'un coup. C'est la pire idée possible.

Notre approche chez Ateia Digital :

  1. Isoler un module ou une fonctionnalité
  2. Extraire le code dans une structure plus claire (pattern, service, composant)
  3. Tester que le comportement est identique
  4. Merger et passer au suivant

Chaque PR doit être petite, lisible et réversible. Si un refactoring prend plus de 2 jours sans merge, c'est un signal d'alerte.


Les 5 pièges classiques du refactoring legacy

Piège 1 — Réécrire au lieu de refactoriser

Réécrire de zéro est rarement justifié. Le code legacy contient des décisions métier implicites que personne ne documente. En réécrivant, on les perd.

Piège 2 — Refactoriser sans tests

Sans tests, chaque modification est un pari. On a vu des projets où un "simple renommage" a cassé toute une chaîne de paiement.

Piège 3 — Vouloir tout faire d'un coup

Un refactoring massif en une seule branche, c'est un merge conflict garanti et des semaines de régression.

Piège 4 — Ignorer la dette technique "sociale"

Le code legacy, c'est aussi des habitudes d'équipe. Si personne ne comprend pourquoi on refactore, l'équipe va résister. Communiquer le "pourquoi" est aussi important que le "comment".

Piège 5 — Ne pas mesurer l'impact

Avant/après : temps de build, couverture de tests, nombre de bugs en production, vélocité de l'équipe. Si on ne mesure pas, on ne peut pas prouver que le refactoring a apporté de la valeur.


Notre stack et nos outils pour un refactoring efficace

| Besoin | Outil | |---|---| | Analyse de dépendances | madge, deptrac, dependency-cruiser | | Tests | Vitest, Jest, PHPUnit, Playwright | | Qualité de code | ESLint, SonarQube, PHPStan | | Monitoring post-deploy | Sentry, Datadog | | Versioning | Feature flags avec Unleash ou LaunchDarkly |


Ce qu'on retient

Refactoriser un projet legacy, c'est un travail de chirurgien, pas de bulldozer. Chez Ateia Digital, on aborde chaque projet avec la même méthode :

  1. Comprendre avant d'agir
  2. Sécuriser avec des tests
  3. Avancer par petits pas mesurables
  4. Communiquer avec l'équipe

Si vous avez un projet legacy qui vous freine, ou si vous êtes développeur et que cette approche vous parle — on recrute des profils qui pensent comme ça.


Écrit par Julien · Ateia Digital · Mars 2025

Restez informé

Recevez nos derniers articles et analyses directement dans votre boîte mail. Pas de spam, que du contenu utile.

Lectures suivantes

Voir tout le blog →