Aucun dépôt de code, aucun ticket de suivi, aucun contact qui réponde encore à l’adresse indiquée sur la facture d’origine : c’est dans ces conditions qu’a commencé la reprise d’un thème classique construit trois ans plus tôt pour une structure associative locale, désormais livrée à elle-même après la disparition de son prestataire d’origine.
Le premier constat : l’absence totale de versionnement
Le thème existait uniquement sous forme de fichiers sur le serveur de production, sans historique, sans branche, sans le moindre commentaire indiquant qui avait modifié quoi et pourquoi. Le premier réflexe a consisté à établir immédiatement un dépôt Git local à partir de l’état actuel des fichiers, avant toute modification, pour disposer au minimum d’un point de repère fiable pour la suite.
cd wp-content/themes/theme-association
git init
git add -A
git commit -m "État initial constaté à la reprise, aucune source antérieure disponible"
Ce commit initial, même dépourvu de sens historique réel, sert de ligne de base pour mesurer chaque modification future et pour distinguer clairement ce qui relève de la reprise de ce qui existait déjà.
Un functions.php monolithique de plus de deux mille lignes
Le fichier functions.php concentrait absolument tout : l’enregistrement des styles, la déclaration des zones de widgets, plusieurs types de contenu personnalisés, une intégration de formulaire codée en dur, et des morceaux de code visiblement copiés depuis des tutoriels en ligne sans adaptation au contexte réel du projet, reconnaissables à leurs noms de fonction restés génériques.
- Aucune organisation en fichiers séparés, tout dans un seul bloc de code difficile à parcourir.
- Des fonctions dupliquées à plusieurs endroits, sans qu’aucune ne soit visiblement la version définitive.
- Des appels directs à la base de données via
$wpdbpour des besoins que les fonctions natives de WordPress auraient couverts sans risque.
Des identifiants d’extensions désactivées encore référencés
Plusieurs fonctions du thème appelaient des fonctions d’extensions visiblement désinstallées depuis longtemps, protégées par des vérifications function_exists() qui masquaient l’erreur sans jamais la signaler clairement. Un audit systématique de chaque appel conditionnel de ce type a permis d’identifier trois fonctionnalités mortes, jamais nettoyées.
if ( function_exists( 'ancienne_extension_afficher_widget' ) ) {
ancienne_extension_afficher_widget();
}
// L'extension correspondante n'existe plus depuis au moins deux ans.
La méthode retenue pour la remise à niveau
Plutôt que de tout réécrire d’un bloc, ce qui aurait multiplié le risque de régression sur un site en production sans environnement de test disponible, la reprise s’est faite par étapes : d’abord la mise en place d’un environnement local reproduisant fidèlement la production, ensuite un découpage progressif de functions.php en fichiers thématiques, puis la suppression une à une des fonctionnalités mortes confirmées.
Une règle suivie tout au long de cette reprise : ne jamais supprimer un morceau de code sans avoir d’abord confirmé, par la recherche de son point d’appel, qu’il n’était réellement plus utilisé nulle part dans le thème.
Ce que cette reprise a changé pour la suite
Le projet s’est terminé par la rédaction d’un document de passation détaillé, remis à la structure associative, listant l’architecture du thème, les identifiants techniques importants, et un rappel explicite de l’obligation de versionner tout futur développement sur ce site, quel que soit le prestataire retenu ensuite.
En résumé
Reprendre un thème sans documentation ni contact avec son auteur d’origine impose une méthode rigoureuse avant toute intervention : versionner l’état constaté, cartographier les dépendances mortes, et avancer par étapes mesurables plutôt que par une réécriture globale risquée. Le temps investi dans cet audit initial se rembourse largement sur la suite du projet.
