Quel type de site web choisir pour votre entreprise ?
Site vitrine, e-commerce, web app ou landing page ? Un guide clair pour choisir le bon format selon votre objectif, votre budget et votre planning.
Julien
Fondateur, Ateia Digital
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.
Avant de modifier quoi que ce soit, on prend le temps de comprendre l'existant. C'est la règle numéro un.
Un refactoring raté commence toujours par un développeur qui a voulu aller trop vite.
Concrètement, voici ce qu'on fait :
madge (JS) ou deptrac (PHP) pour visualiser le couplage.git log --oneline --all | wc -l sur chaque dossier donne déjà une bonne idée.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 :
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 :
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.
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.
Sans tests, chaque modification est un pari. On a vu des projets où un "simple renommage" a cassé toute une chaîne de paiement.
Un refactoring massif en une seule branche, c'est un merge conflict garanti et des semaines de régression.
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".
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.
| 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 |
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 :
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
Recevez nos derniers articles et analyses directement dans votre boîte mail. Pas de spam, que du contenu utile.