« L’ancien développeur ne répond plus, on n’a que le dossier FTP » : cette phrase ouvre à peu près un projet de reprise sur trois dans notre agence. Pas de dépôt Git, pas de changelog, parfois même pas de nom de thème enfant cohérent avec le site. Il faut reconstruire une compréhension du projet à partir du code seul, sans pouvoir demander au précédent auteur ce qu’il a fait et pourquoi.
Ce travail n’est pas glamour, mais il conditionne toute la suite : livrer un devis de maintenance sans cet audit préalable, c’est s’exposer à découvrir en cours de route des dépendances cachées ou des correctifs fragiles qui auraient dû faire monter le prix.
Étape 1 : isoler le thème parent de l’enfant
La première chose à vérifier est la nature exacte du thème actif : thème enfant d’un thème du répertoire officiel, thème premium modifié directement, ou thème entièrement sur mesure. Le fichier style.css du thème actif contient l’en-tête avec, potentiellement, un champ Template: indiquant le thème parent. En son absence, on regarde le contenu du dossier : un thème enfant minimal ne contient généralement que style.css et functions.php, le reste étant hérité.
Nous avons établi une checklist systématique pour cette première étape :
- Lire l’en-tête complet de
style.css(nom, version, thème parent déclaré). - Télécharger la version officielle du thème parent correspondant à la version installée et la comparer fichier par fichier avec
diffaux fichiers présents dans l’enfant, quand des fichiers du parent y sont dupliqués. - Lister tous les plugins actifs et leur dernière mise à jour, pour évaluer le niveau d’abandon global du projet.
- Vérifier la version de WordPress et de PHP en place face aux exigences minimales du thème et des plugins.
Étape 2 : reconstituer un historique approximatif
Sans Git, on n’a pas d’historique de commits, mais on a souvent des indices indirects : dates de modification des fichiers sur le serveur, commentaires ponctuels dans le code (rarement horodatés, malheureusement), et surtout le journal des révisions de contenu dans la base WordPress, qui donne une idée de l’activité du site dans le temps. Nous créons systématiquement un dépôt Git local dès la reprise, même a posteriori, pour au moins figer un point de départ avant toute intervention.
cd wp-content/themes/theme-client-enfant
git init
git add -A
git commit -m "Etat initial constaté a la reprise du projet"Ce commit initial n’a aucune valeur historique réelle, mais il devient la référence zéro à partir de laquelle toute modification future sera traçable pour l’équipe qui reprend le projet.
Étape 3 : identifier les hacks par leur odeur
Sans commentaire ni changelog, on repère les correctifs bricolés à leurs symptômes typiques : du CSS avec !important en excès, des fonctions collées directement dans functions.php sans namespace ni préfixe cohérent avec le reste du thème, des hooks désactivés puis réactivés à coups de commentaires, ou des appels directs à la base de données via $wpdb là où une fonction native de l’API WordPress aurait suffi.
Chacun de ces signaux indique un correctif posé dans l’urgence, potentiellement fragile, qu’il faut documenter avant de le toucher : il répond peut-être à un besoin réel du client, même si sa forme est discutable.
Étape 4 : prioriser par risque, pas par esthétique du code
Le réflexe naturel d’un développeur qui reprend un projet mal fichu est de vouloir tout réécrire proprement. C’est rarement ce que le client demande, ni ce qu’il peut financer. Notre grille de priorisation retient trois critères : le risque de sécurité (plugin abandonné avec vulnérabilité connue), le risque de rupture (fonction dépréciée qui cassera à la prochaine montée de version majeure de PHP), et l’inconfort pur (code moche mais fonctionnel). Seuls les deux premiers justifient une intervention immédiate.
Un code moche qui fonctionne et ne présente aucun risque identifié n’est pas une urgence. C’est un choix d’agence à assumer, pas un réflexe automatique de développeur perfectionniste.
En résumé
Reprendre un projet sans historique demande une discipline d’audit avant toute chose, pour ne pas confondre découverte progressive et instabilité du projet. La création d’un dépôt Git dès le premier jour, même tardif, et une checklist stricte de vérification du thème parent et des plugins actifs évitent la majorité des mauvaises surprises que nous avons rencontrées sur ce type de mission.
