Il existe trois façons d’hériter d’une base de code : votre entreprise en a acquis une, vous prenez la direction technique, ou l’agence qui l’a développée n’est plus là. Dans tous les cas, on vous confie un système, des attentes, et environ un mois avant qu’un responsable demande un état des lieux.
La tentation est de commencer par lire le code. Ne le faites pas. La qualité du code est l’un des éléments les moins prédictifs que vous puissiez évaluer la première semaine, et c’est aussi celui sur lequel il est le plus facile de se faire une idée faussée. Voici l’ordre que nous suivons.
Une règle avant de commencer : ne changez rien la première semaine. Ni une dépendance, ni une valeur de configuration, ni même un composer update. Vous ne savez pas encore ce qui est essentiel au fonctionnement, et une indisponibilité causée par vos soins ruinerait votre crédibilité pour signaler celles dont vous n’êtes pas responsable.
Semaine 1 : Peut-on seulement l’exécuter ?
Tout le reste n’est qu’hypothèse tant que le système ne tourne pas sur une machine que vous contrôlez.
- Faites fonctionner un environnement local à partir d’un clone propre, et mesurez le temps nécessaire. Ce chiffre est le meilleur indicateur du coût de chaque modification future. Deux heures, c’est sain ; deux semaines, cela vous dit l’essentiel.
- Recensez les environnements. Production, préproduction, et les deux serveurs dont personne n’a parlé. Identifiez-les en lisant le DNS et le compte cloud, pas en posant la question.
- Déterminez ce qui tourne où : serveurs web, workers, cron, files d’attente, rapports planifiés, récepteurs de webhook. Le cron non documenté est le piège classique.
- Vérifiez que vous avez les accès. Bureau d’enregistrement du domaine, DNS, hébergement, cloud, dépôts, CI, suivi des erreurs, passerelles de paiement, envoi d’e-mails. Un accès manquant est un problème commercial à faire remonter dès le deuxième jour, pas à la quatrième semaine.
- Vérifiez l’existence des sauvegardes et restaurez-en une. Une sauvegarde non testée n’est qu’une rumeur. Restaurez-en une dans un environnement isolé et examinez-la.
- Identifiez qui détient l’information. Souvent une seule personne, parfois dans une société qui ne l’emploie plus. C’est votre ressource la plus fragile : prenez rendez-vous immédiatement.
Semaine 2 : Risque, pas qualité
Évaluez maintenant l’exposition. Ce sont ces constats qui orientent les décisions et débloquent les budgets.
- Version de PHP, par environnement, comparée au calendrier de support officiel. Une version non supportée est le constat qui prime sur tous les autres de cette liste.
- Âge des dépendances et statut de sécurité. Lancez un audit sur le fichier lock. Comptez le nombre de versions majeures de retard sur le framework : c’est ce chiffre, et non le style du code, qui détermine le coût d’une mise à niveau.
- Dépendances abandonnées. Paquets sans publication depuis des années, ou forks pointant vers un dépôt personnel. Chacun est un projet dont vous héritez sans le savoir.
- Secrets dans le dépôt. Parcourez tout l’historique, pas seulement l’état actuel. Considérez tout secret trouvé comme compromis.
- Protection des données. Où résident les données personnelles, qui y a accès, ce qui est chiffré, et quelles sont vos obligations à ce sujet.
- Déploiement reproductible ou non. Un système déployé par modification manuelle sur le serveur n’offre aucun retour arrière fiable, ce qui influence toutes les analyses de risque ultérieures.
Rédigez vos constats sous forme de risques, avec une probabilité, un impact et un coût de correction — jamais comme des reproches à l’équipe précédente. Ce document s’adresse à des décideurs, et ce code est mauvais n’est pas exploitable, alors que nous serons sans correctif dans 14 mois l’est.
Semaine 3 : Lire le code
Une fois le contexte posé, l’analyse du code devient utile, non jugeante. Cherchez la structure et la testabilité, pas le style.
- Lancez une analyse statique de base et notez l’état initial. Il ne s’agit pas de corriger, mais de mesurer. Ce qui compte, c’est l’évolution sur l’année à venir.
- Vérifiez la couverture de tests là où c’est critique : tunnel d’achat, paiement, tarification, tout ce qui touche à l’argent. Le pourcentage global est un indicateur faible ; la couverture des parcours à risque est la vraie mesure.
- Localisez la logique métier. Dans une base saine, elle est regroupée. Dans une base dégradée, elle est disséminée dans les contrôleurs, les templates et une procédure stockée oubliée.
- Repérez les god objects : la classe que toutes les fonctionnalités manipulent. C’est là que les changements coûtent le plus cher et que surviendra le prochain incident.
- Lisez l’historique git pour repérer l’instabilité. Les fichiers les plus modifiés sont ceux où l’activité réelle se concentre, et où l’investissement est le plus rentable.
- Identifiez l’intouchable. Tout système hérité a un module que personne n’ose modifier. Déterminez lequel et pourquoi.
Le bus factor mérite une mention à part. Si une seule personne peut expliquer le tunnel de commande et que personne d’autre ne le peut, le risque est supérieur à n’importe quel défaut de code, et la solution — binômage, documentation, une deuxième personne réellement compétente — doit être engagée immédiatement, pas après l’audit.
Semaine 4 : Évaluer et recommander
Notez chaque dimension de 1 (sain) à 5 (critique), et laissez la somme guider la recommandation plutôt que votre intuition.
- Sécurité et actualité des versions : la seule dimension pouvant imposer une décision à elle seule
- Santé des dépendances : retard accumulé, dépendances abandonnées
- Opérabilité : pouvez-vous déployer, revenir en arrière, observer et restaurer ?
- Testabilité : pourriez-vous modifier la logique de tarification et savoir si vous l’avez cassée ?
- Compréhensibilité : combien de temps avant qu’un nouvel ingénieur soit productif ?
- Adequation métier : le système répond-il toujours aux besoins, ou freine-t-il la feuille de route ?
Ensuite, positionnez le système :
- Majorité de 1–2 : maintenir et améliorer. Le système est sain. Corrigez les points identifiés et poursuivez la feuille de route.
- Majorité de 2–3 : investir de façon ciblée. Un plan de remédiation financé — mise à niveau des versions, gouvernance des dépendances, tests sur les parcours critiques — mené en parallèle de la livraison courante.
- Majorité de 3–4 : remplacement progressif. Approche « strangler fig », remplacement du système route par route tout en maintenant l’activité. Nous détaillons ce modèle dans migration d’un monolithe PHP hérité vers Laravel.
- Majorité de 4–5, ou adéquation métier à 5 : reconstruire. Rare, et cela doit sembler inévitable, non séduisant. Une reconstruction justifiée uniquement par la qualité du code est souvent une décision regrettée.
Méfiez-vous de votre propre envie de tout reconstruire. Presque tous les ingénieurs qui héritent d’une base inconnue en ont envie. Presque aucun projet issu de cette impulsion ne tient ses promesses. Exigez que la note globale le justifie.
Éléments à transmettre
Le livrable est un document lisible par un public non technique, qui comprend :
- Un résumé d'une page présentant la recommandation et trois raisons concrètes qui la justifient
- Un registre des risques — chaque point avec sa probabilité, son impact et le coût de correction, classés par ordre d'urgence
- La version et la situation des dépendances, avec les dates de fin de support
- Un plan sur 90 jours pour les actions à ne pas différer, chiffré
- Les lacunes d'accès et de propriété, qui relèvent le plus souvent de l'organisation ou du contrat, non de la technique
- Ce que nous n'avons pas pu évaluer et ce qu'il faudrait pour le faire
Ce dernier point distingue une évaluation professionnelle d'une évaluation simplement assurée. Un mois ne suffit pas pour tout savoir, et le reconnaître est plus crédible que de prétendre le contraire.
Nous réalisons cette évaluation pour nos clients via notre pôle PHP sur mesure et notre équipe de développement PHP — souvent avant une acquisition, parfois après la rupture avec une agence. La question connexe de savoir si le langage lui-même pose problème est traitée dans is PHP still the right choice for eCommerce.
Questions fréquentes
Combien de temps doit durer une analyse d’un code hérité ?
Quatre semaines à temps partiel suffisent pour formuler une recommandation solide sur la plupart des systèmes de taille moyenne. Moins de deux semaines donnent un avis, pas une analyse ; au-delà de six, c’est souvent qu’on cherche à corriger plutôt qu’à évaluer.
Quel est le premier point à vérifier ?
Vérifiez si vous pouvez l’exécuter localement à partir d’un dépôt propre, et combien de temps cela prend. Ce seul chiffre prédit mieux que tout indicateur de qualité de code le coût de chaque évolution future, et il est disponible dès le premier jour.
Faut-il reconstruire ou refactoriser un système PHP hérité ?
Dans presque tous les cas, refactorez ou remplacez progressivement. Ne reconstruisez que si l’outil ne répond plus aux besoins métiers, et non parce que le code est difficile à maintenir. Un projet de reconstruction motivé uniquement par la qualité du code est généralement regretté.
Quel est le principal risque d’un code hérité ?
Ce n’est généralement pas le code lui-même. Les vrais risques sont : une version PHP non maintenue, l’absence d’accès à un domaine ou à un compte cloud, des sauvegardes non testées, ou une seule personne qui maîtrise un sous-système critique. Ce sont ces constats qui modifient les décisions.
Comment présenter les constats aux parties prenantes non techniques ?
Sous forme de registre des risques : chaque point avec sa probabilité, son impact métier et le coût de correction, classés par urgence. Jamais comme une critique de l’équipe précédente — cela serait perçu comme une prise de position et rendrait le document plus facile à écarter.
Demandez un second avis
Si vous avez repris un existant et souhaitez un avis indépendant avant d'engager un budget, nous réalisons l'évaluation et vous remettons le document. Contactez notre équipe ; réponse sous un jour ouvré.