Quatorze mois. C’est le temps qui sépare la dernière mise à jour publiée par l’auteur du thème et le jour où l’agence de voyage qui l’utilise m’a contacté, inquiète de ne plus voir aucune réponse sur le forum de support. Le thème gère encore les fiches destinations, les formulaires de devis et une bonne partie de la mise en page des circuits sur mesure. Il tourne, il rend bien, mais plus personne ne le maintient.
La tentation naturelle est de tout jeter et de repartir sur un thème actif. Sauf que le site génère un chiffre d’affaires réel, que la migration coûterait plusieurs semaines et que rien ne garantit qu’un nouveau thème rendra aussi bien les grilles de circuits construites au fil des ans. L’option retenue a été différente : auditer le thème existant, en sécuriser le cœur, et ne remplacer que ce qui pose un vrai risque.
Cartographier avant de couper quoi que ce soit
Premier réflexe : lister ce que le thème fait réellement. J’ai ouvert le dossier du thème et grep les appels à wp_enqueue_script, wp_enqueue_style et les hooks personnalisés dans functions.php. Sur ce projet, le thème embarquait trois bibliothèques JavaScript tierces chargées en dur, deux widgets Customizer maison et un système de champs personnalisés fait main, sans dépendance à un plugin de champs connu.
Cette cartographie sert de base à toute décision ultérieure. Un thème abandonné qui s’appuie uniquement sur les API du cœur WordPress (add_theme_support, register_nav_menu, get_template_part) vieillit mieux qu’un thème qui embarque son propre framework CSS ou son propre système de mise à jour.
Isoler le risque réel dans un thème enfant
Plutôt que de modifier le thème parent directement, j’ai créé un thème enfant minimal avec un style.css déclarant Template: nom-du-theme-parent et un functions.php qui charge la feuille de style parente via wp_enqueue_style accrochée à wp_enqueue_scripts. Toute correction de sécurité ou d’affichage passe désormais par ce thème enfant, jamais par le parent, ce qui garde une trace claire de ce qui a été modifié et facilite un futur remplacement partiel.
Deux points nécessitaient une intervention immédiate : un formulaire de contact qui n’échappait pas correctement les entrées avant de les afficher dans l’e-mail de confirmation, et un appel à une fonction de version PHP dépréciée qui produisait des avertissements silencieux dans les journaux. Les deux ont été corrigés dans le thème enfant, sans toucher au parent.
Ce qu’on ne touche pas tout de suite
- Le système de champs personnalisés maison, tant qu’il ne casse rien avec les futures versions de PHP
- La structure des templates de circuits, qui reste fonctionnelle et connue de l’équipe
- Les styles Customizer existants, réutilisés tels quels pour ne pas perturber les habitudes de l’équipe marketing
Documenter ce qui remplace le support du vendeur
Sans auteur pour répondre aux questions, la documentation interne devient le seul filet de sécurité. J’ai rédigé un fichier MAINTENANCE.md à la racine du thème enfant listant chaque correctif appliqué, sa date et sa justification. Ce document sert aussi de base pour la décision suivante : à partir de quel seuil de dette technique bascule-t-on vers un remplacement complet ?
Un thème abandonné n’est pas dangereux en soi. Ce qui l’est, c’est de ne plus savoir ce qu’il contient. La documentation compte autant que le correctif.
Surveiller sans dépendre du vendeur
Un audit ponctuel ne suffit pas si le thème continue d’accumuler des avertissements à chaque montée de version PHP. J’ai mis en place une surveillance des journaux d’erreurs via le service d’hébergement, avec une alerte dès qu’une nouvelle notice ou un warning apparaît dans les fichiers du thème. Cette veille remplace, autant que possible, les mises à jour que l’auteur ne publiera plus.
Sur ce projet, la fréquence des alertes est restée faible : deux notices mineures en six mois, corrigées en moins d’une heure chacune. Le thème n’était donc pas si fragile qu’il y paraissait ; il était surtout mal documenté.
Notre verdict
Reprendre un thème premium abandonné n’exige pas systématiquement une reconstruction. Ce qui compte, c’est de distinguer le cœur stable — souvent basé sur des API WordPress classiques — du superflu fragile, et de mettre cette frontière noir sur blanc dans un thème enfant documenté. Pour l’agence de voyage, cette approche a permis de gagner un an de tranquillité sans dépense de refonte, le temps de préparer sereinement une migration vers un thème activement maintenu.
