Un client arrive régulièrement avec un thème déjà acheté sur une place de marché, parfois avant même le premier rendez-vous avec l’agence. La question n’est alors plus « quel thème choisir » mais « peut-on travailler avec celui-ci sans mettre en péril la maintenance future du site ». Après plusieurs mauvaises surprises — un thème qui embarquait sa propre copie modifiée de WooCommerce, un autre qui stockait ses réglages dans des shortcodes impossibles à retrouver hors de son constructeur — l’équipe a fini par formaliser une grille de contrôle appliquée systématiquement avant d’accepter ce genre de commande.
Cette liste ne sert pas à comparer des thèmes entre eux ni à recommander une alternative : elle sert uniquement à décider, en connaissance de cause, si un thème imposé peut être accepté tel quel, accepté sous conditions, ou doit être refusé au client avec une explication argumentée.
Inventorier les plugins embarqués et leur provenance
La plupart des thèmes premium vendus en licence unique embarquent un lot de plugins tiers, parfois modifiés par rapport à la version publique. Le premier réflexe consiste à ouvrir le dossier plugins fourni avec le thème et à noter, pour chacun :
- Le nom réel du plugin et sa version, comparée à la dernière version disponible sur WordPress.org.
- S’il s’agit d’une version « nulled » ou modifiée sans en-tête d’origine — signe fréquent de code potentiellement compromis.
- S’il est installé via TGM Plugin Activation ou intégré directement dans le dossier du thème, ce qui complique sa mise à jour indépendante.
Un thème qui embarque une douzaine de plugins pour des fonctions aussi banales qu’un slider ou des onglets mérite une attention particulière : chaque plugin est une surface d’attaque supplémentaire et une ligne de plus dans le budget de maintenance annuel.
Tester la sortie des shortcodes propriétaires
Le point le plus critique à long terme concerne les shortcodes propres au thème, généralement générés par un constructeur de page intégré. La question à se poser n’est pas « est-ce que ça fonctionne aujourd’hui » mais « que reste-t-il si on désactive le thème demain ». Le test consiste à désactiver temporairement le thème sur une copie de développement et à observer le contenu affiché :
[vc_row][vc_column][theme_custom_hero title="Bienvenue"]
Texte de présentation ici.
[/theme_custom_hero][/vc_column][/vc_row]
Si ce code brut s’affiche tel quel à l’écran une fois le thème désactivé, c’est que le contenu est verrouillé dans une syntaxe propriétaire, sans échappatoire simple. C’est un signal fort : la migration future vers un autre thème demandera une réécriture complète du contenu, pas un simple changement d’habillage visuel.
Mesurer le nombre de requêtes SQL générées par page
Avec Query Monitor activé sur un environnement de test, on relève systématiquement le nombre de requêtes SQL sur trois types de pages : l’accueil, une page classique et un article de blog. Un thème classique bien construit reste en général sous la barre des 30 à 40 requêtes par page. Certains thèmes à constructeur intégré, en cumulant les appels de leurs propres modules, dépassent régulièrement les 150 requêtes sur une simple page d’accueil.
| Élément vérifié | Seuil d’alerte |
|---|---|
| Requêtes SQL sur la page d’accueil | Plus de 80 |
| Plugins embarqués non issus de WordPress.org | Plus de 5 |
| Poids du fichier CSS principal non minifié | Plus de 500 Ko |
Vérifier la fréquence des mises à jour
Sur la page produit ThemeForest elle-même, l’onglet des changelogs indique la date de la dernière mise à jour publiée. Un thème dont la dernière mise à jour remonte à plus d’un an, alors que WordPress a publié plusieurs versions majeures entre-temps, annonce une compatibilité future incertaine — d’autant plus si l’auteur ne répond plus dans les commentaires de support.
Le verrouillage du contenu, critère décisif
Au-delà des aspects techniques mesurables, la question la plus importante reste celle du verrouillage : si le client change un jour de prestataire ou de thème, combien de temps faudra-t-il pour récupérer un contenu exploitable ? Un thème classique, même premium, qui stocke son contenu dans des champs personnalisés lisibles reste raisonnable. Un thème qui encode chaque page en JSON propriétaire dans un unique champ meta est, de fait, une dépendance à vie tant que ce thème reste actif.
Un thème premium n’est jamais gratuit à long terme : son vrai coût se mesure le jour où il faut s’en séparer, pas le jour de l’achat.
Ce qu’il faut retenir
Cette grille — inventaire des plugins, test de sortie des shortcodes, mesure des requêtes SQL, fréquence des mises à jour et niveau de verrouillage du contenu — se remplit en moins d’une heure sur un environnement de test et évite bien des déconvenues six mois après la mise en ligne. Quand le résultat est mauvais sur plusieurs points à la fois, mieux vaut le documenter clairement pour le client plutôt que de livrer un site qu’on sait fragile dès le départ.
