Un projet web qui tourne, mais qui ralentit. Un code que plus personne ne comprend tout à fait. Une application qui fonctionne mais que personne n’ose toucher. Ces situations sont fréquentes, et elles posent une question concrète : est-ce qu’on reprend, ou est-ce qu’on refait ?
La réponse honnête est que ça dépend — mais pas de ce qu’on croit en général. Elle dépend moins de l’âge du code que de sa lisibilité, de sa testabilité et de la clarté du besoin actuel. Cet article présente comment aborder cette évaluation sans se précipiter dans une refonte totale qui n’en valait peut-être pas la peine.
Ce qu’on entend par “dette technique”
La dette technique n’est pas un défaut moral. C’est le résultat de compromis acceptés au fil du temps : une fonctionnalité développée vite parce que la date de livraison était fixée, une dépendance non mise à jour parce que la migration était complexe, une architecture qui n’a pas suivi la croissance du produit.
Tout projet accumule de la dette. Le problème n’est pas son existence, mais son invisibilité. Une dette technique connue et documentée est gérable. Une dette invisible, c’est ce qui transforme un correctif anodin en journées de débogage.
Les formes les plus courantes :
- dépendances obsolètes ou non maintenues ;
- absence de tests automatisés sur les parties critiques ;
- logique métier dispersée dans les contrôleurs, les templates ou les scripts d’import ;
- configuration dupliquée entre environnements ;
- absence de documentation sur les choix structurants ;
- couplage fort entre des modules qui devraient être indépendants.
Aucune de ces situations n’impose une refonte complète. Mais chacune impose une évaluation sérieuse avant de reprendre le développement.
Pourquoi reprendre un projet est différent de le créer
Démarrer un projet nouveau, c’est poser des fondations. Reprendre un projet existant, c’est comprendre ce qui tient debout, ce qui menace de s’effondrer et ce qui peut être conservé tel quel.
La différence est souvent sous-estimée. On arrive sur un projet avec des hypothèses sur ce qu’il fait, et on découvre assez vite que ces hypothèses sont partiellement fausses. Le code réel reflète des décisions passées dont les raisons ne sont plus visibles. Certaines règles métier existent uniquement dans le code, sans documentation. Certains comportements sont des effets de bord devenus des fonctionnalités.
Reprendre un projet sans phase d’audit, c’est avancer à vue. Les premières modifications peuvent déstabiliser des parties du système apparemment sans lien. Les délais s’allongent. Les bugs réapparaissent.
Un audit préalable — même court — réduit significativement ce risque. Il ne doit pas durer des semaines. Il doit produire une carte des zones à risque.
Ce qu’un audit technique doit couvrir
Un audit de reprise n’est pas une revue de code exhaustive. C’est une lecture orientée risques et priorités.
L’état des dépendances
Quelles versions de frameworks, bibliothèques et outils sont utilisées ? Y a-t-il des dépendances non maintenues, avec des failles connues, ou incompatibles avec les versions actuelles du langage ? Un projet Symfony 4.4 sans migration vers 5 ou 6 représente une surface d’exposition différente d’un projet sur une version LTS à jour.
La couverture de tests
Y a-t-il des tests ? Sur quelles parties ? Des tests unitaires sur la logique métier changent la nature du travail de reprise. Leur absence ne bloque pas la reprise, mais elle modifie le niveau de confiance lors des modifications.
La lisibilité du code
Pas au sens esthétique. Au sens opérationnel : est-ce qu’une personne qui n’a pas participé au développement peut comprendre ce que fait un contrôleur, une entité, un service, en le lisant ? L’absence de lisibilité ralentit tout : la correction de bugs, l’ajout de fonctionnalités, la revue de code, l’intégration d’un nouveau développeur.
La séparation des responsabilités
Est-ce que la logique métier est isolée de la couche de présentation et de la couche de données ? Un projet où les règles de calcul sont dans les templates, ou où les requêtes SQL sont directement dans les contrôleurs, est plus difficile à faire évoluer et à tester.
La documentation des choix structurants
Pourquoi cette architecture ? Pourquoi cette dépendance ? Pourquoi cette règle métier encodée de cette façon ? L’absence de documentation ne rend pas un code inexploitable, mais elle transforme chaque reprise en archéologie.
L’infrastructure et les environnements
Comment le projet se déploie-t-il ? Existe-t-il un environnement de staging ? Les configurations sont-elles versionnées ? Un projet sans environnement de test fiable est plus risqué à modifier, même sur des fonctionnalités a priori simples.
Reprendre ou refaire : comment trancher
La refonte complète est souvent présentée comme la solution propre. En pratique, elle est rarement la plus rapide ni la plus sûre.
Refaire entièrement, c’est :
- recréer un contexte de développement de zéro ;
- réencode une connaissance métier souvent mal documentée ;
- maintenir deux systèmes en parallèle pendant la transition ;
- prendre le risque d’oublier des cas limites que le code existant gérait silencieusement.
Reprendre avec une phase de stabilisation préalable est souvent plus raisonnable, à condition que les fondations soient saines.
Une grille simple pour décider :
| Critère | Signal pour reprendre | Signal pour refaire |
|---|---|---|
| Dépendances | Obsolètes mais migrables | Abandonnées, incompatibles |
| Tests | Partiels mais présents | Absents sur les parties critiques |
| Lisibilité | Dégradée mais compréhensible | Opaque, sans documentation |
| Logique métier | Structurée, identifiable | Dispersée, impossible à isoler |
| Infrastructure | Déployable, adaptable | Inexistante ou bloquante |
| Coût de migration | Inférieur au coût de refonte | Supérieur à une réécriture ciblée |
Cette grille n’est pas une règle absolue. Un projet peut cumuler plusieurs signaux dans les deux colonnes. L’objectif est de poser le diagnostic avant de prendre une décision coûteuse.
Prioriser les interventions après un audit
Un audit produit une liste de points à traiter. Pas de la même urgence ni du même ordre de grandeur. Les prioriser évite de traiter le cosmétique avant le structurel.
Priorité 1 : sécurité et disponibilité. Les failles connues, les dépendances non maintenues avec des CVE publiées, les configurations exposées, les points de défaillance uniques. Ce sont les risques qui peuvent se matérialiser sans action de développement.
Priorité 2 : fiabilité de la logique métier. Les règles métier qui produisent des résultats incorrects, les cas limites non gérés, les données incohérentes dans la base. Un outil qui fonctionne mais produit des résultats faux est souvent plus dangereux qu’un outil lent.
Priorité 3 : observabilité. Logs, alertes, monitoring. Savoir quand quelque chose échoue et pourquoi. Avant d’engager des modifications significatives, il faut pouvoir observer l’impact.
Priorité 4 : testabilité. Ajouter des tests sur les parties critiques avant de les modifier. Pas pour atteindre une couverture cible, mais pour créer un filet de sécurité sur ce qui ne doit pas casser.
Priorité 5 : dette de lisibilité. Renommages, extraction de services, documentation des décisions. Ces interventions sont utiles mais peuvent attendre que les priorités précédentes soient traitées.
Le cas particulier des applications métier internes
Les applications métier internes — suivi de demandes, gestion de plannings, portail de saisie, outil de facturation sur mesure — ont une dynamique particulière en matière de reprise.
Leur logique métier est souvent plus complexe que leur interface ne le laisse penser. Elle s’est construite par couches successives, en réponse à des situations réelles qui n’étaient pas prévisibles au départ. Les règles de calcul reflètent des arbitrages organisationnels qui ne sont plus forcément connus de ceux qui utilisent l’outil aujourd’hui.
Sur ce type de projet, la phase d’audit doit aller au-delà du code. Elle doit comprendre les usages réels : qui utilise quoi, dans quel ordre, avec quelles exceptions. Sinon, on risque de simplifier une règle qui semblait complexe et qui gérait en réalité un cas fréquent passé inaperçu.
C’est le lien avec le cadrage d’une nouvelle version : cadrer une application métier avant de développer reste valable même quand on reprend un outil existant. On repart du terrain, pas seulement du code.
Ce qu’un prestataire doit vous dire avant de commencer
Si vous faites appel à un développeur ou une structure externe pour reprendre votre projet, certaines questions doivent trouver des réponses claires avant que le développement commence.
- Ont-ils accès au code source, à la base de données de développement, aux environnements ?
- Font-ils un audit préalable, ou ils démarrent directement dans le code ?
- Comment documentent-ils ce qu’ils comprennent et ce qu’ils modifient ?
- Quelle est leur stratégie de test avant de déployer des modifications ?
- Comment gèrent-ils la transition si le projet est en production ?
Un prestataire qui promet de reprendre un projet en quelques jours sans phase d’exploration prend un risque — souvent à votre charge. Une reprise sérieuse commence par une phase de lecture, même courte.
FAQ
Peut-on reprendre un projet sans documentation ?
Oui, mais c’est plus lent. L’absence de documentation oblige à reconstituer le contexte à partir du code, des échanges passés, des utilisateurs actuels et des données en base. Ce travail a de la valeur — il documente ce qui était implicite — mais il doit être budgété.
Combien de temps dure un audit de reprise ?
Cela dépend de la taille et de la complexité du projet. Un audit rapide sur un outil de taille modeste peut se faire en quelques jours. Un projet avec de nombreux modules, des intégrations tierces et une logique métier dense peut nécessiter plusieurs semaines de lecture avant qu’on puisse proposer une feuille de route crédible.
Vaut-il mieux reprendre en interne ou confier à un prestataire externe ?
Les deux ont du sens selon les ressources disponibles. Une reprise en interne permet de capitaliser sur la connaissance existante, mais elle demande du temps disponible et des compétences techniques à jour. Un prestataire externe apporte un regard neuf et des méthodes rodées, mais il a besoin d’une phase d’intégration au contexte. Dans certains cas, une combinaison des deux est la plus efficace : audit externe, exécution en interne.
Que faire si le projet est bloquant mais que la refonte est trop coûteuse ?
C’est la situation la plus fréquente. La réponse passe par la priorisation : identifier les trois ou quatre points qui posent le plus de risques ou qui ralentissent le plus l’usage, et les traiter en premier. Une stabilisation partielle vaut mieux qu’une refonte repoussée indéfiniment.
Peut-on migrer vers une stack différente en reprenant ?
Oui, mais c’est un projet dans le projet. Si le code existant est en PHP sans framework et que la migration vers Symfony est envisagée, il vaut mieux traiter ça comme une refonte ciblée avec une stratégie de bascule progressive, pas comme une reprise à l’identique.
Conclusion
Reprendre un projet web existant n’est pas la même chose que démarrer un développement neuf. Cela demande une phase de lecture, un audit orienté risques, une priorisation honnête des interventions et une décision éclairée entre stabilisation et refonte.
La tentation de tout réécrire est compréhensible. Elle sous-estime souvent le coût de la reconstitution de la connaissance métier et le risque de régression sur des cas limites que le code existant gérait silencieusement.
Le bon point de départ est l’audit. Ce qu’il révèle détermine la feuille de route, le budget réaliste et la nature des premières interventions.
Si vous êtes dans cette situation — un projet qui tourne mais que vous n’osez plus toucher, ou une application interne à moderniser — c’est le genre de problème sur lequel on peut travailler ensemble. L’approche commence par comprendre ce qui existe avant de proposer quoi que ce soit.