Child Theme : ce qui a changé depuis 2017 et ce qui reste essentiel
Cet article propose une lecture actualisée des pratiques autour des child themes, en s’appuyant sur l’expérience acquise depuis nos précédents textes consacrés au sujet. Il ne réexplique pas les bases déjà présentées ailleurs et ne cherche pas à remplacer les guides classiques, mais à clarifier ce qui demeure essentiel, en renvoyant vers nos articles Aller plus loin avec un Child-Thème, Créer un thème enfant pour WordPress et Child-Thème, gérer les dépendances, ainsi que vers les ressources externes de référence comme Child Themes chez developer.wordpress.org et Créer un thème WordPress enfant : est-ce vraiment nécessaire en 2025 ? chez WPMarmite.
Nous revenons notamment sur les besoins concrets rencontrés dans les projets actuels, les limites souvent méconnues, les situations où un child theme est utile et celles où il ne l’est pas, ainsi que les points sensibles observés lors des reprises de sites ou dans les environnements complexes. Le contenu a été mis à jour afin de refléter les pratiques d’aujourd’hui et compléter l’article initial publié en 2017.
Erreurs récurrentes dans les projets hérités
Lorsque l’on reprend un site existant, le child theme raconte souvent l’histoire des années passées : ajustements rapides, dépannages urgents, changements d’intervenants, ajout de fonctionnalités sans réelle coordination. Ces situations ne sont pas propres à WordPress ; elles sont typiques des projets qui ont évolué au fil du temps. Ce chapitre ne revient pas sur les aspects techniques détaillés dans nos autres articles, mais sur les dérives rencontrées en situation réelle et sur la manière de les remettre en ordre.
Surcharges CSS dispersées
Voici un cas fréquemment rencontré :
/* style.css – thème enfant */
.header-title { color: red; }
/* style-override.css – ajouté plus tard */
.header-title { color: blue; }
/* Customizer */
.header-title { color: green; }
/* Dans ce type de situation, trois sources modifient la même règle. La bonne approche consiste à consolider : */
/* style-enfant-global.css – version consolidée */
.header-title {
color: green; /* valeur effectivement souhaitée */
}On charge alors uniquement le fichier consolidé. Dans de nombreux projets, les styles se retrouvent éclatés entre plusieurs fichiers : un override ponctuel ajouté dans style-override.css, un correctif dans le Customizer, une adaptation dans style.css, puis une feuille supplémentaire chargée « juste pour régler un cas particulier ». Chaque intervention avait un sens au moment où elle a été faite, mais l’accumulation génère une cascade difficile à maintenir.
Que fait-on dans ce cas ? La première étape consiste à regrouper les règles réellement utiles dans un fichier unique, chargé après celui du parent. On identifie ce qui est encore utilisé, ce qui ne l’est plus, et ce qui se contredit. Cette consolidation rend le thème enfant plus lisible et facilite toute évolution ultérieure.
Dépendances scripts/styles en désordre
Exemple réel trouvé dans certains projets :
// functions.php du thème enfant
wp_enqueue_style('parent-style', get_template_directory_uri().'/style.css');
wp_enqueue_style('child-style', get_stylesheet_directory_uri().'/style.css');
wp_enqueue_style('child-style', get_stylesheet_directory_uri().'/style.css'); // doublon
wp_dequeue_style('parent-style'); // retrait contradictoire
// Après reprise, on revient à une structure propre :
function charge_styles_proprement() {
wp_enqueue_style('parent-style', get_template_directory_uri().'/style.css');
wp_enqueue_style('child-style', get_stylesheet_directory_uri().'/style.css', ['parent-style']);
}
add_action('wp_enqueue_scripts','charge_styles_proprement');Cette version garantit un chargement cohérent. Dans certains projets hérités, les dépendances sont chargées de manière incohérente : des scripts ajoutés deux fois, d’autres retirés sans raison claire, des priorités modifiées à la volée, des feuilles de style du parent et de l’enfant qui se croisent dans un ordre inattendu. Ces situations proviennent souvent de corrections rapides, sans vision d’ensemble.
Que fait-on dans ce cas ? On commence par repérer les fichiers effectivement nécessaires, puis on vérifie quels scripts et styles le parent charge déjà. Une fois cet état des lieux réalisé, on réorganise calmement les appels en conservant uniquement ce qui est utile. Les détails techniques sur la gestion propre des dépendances sont déjà couverts dans notre article Child-Thème, gérer les dépendances.
Templates copiés en masse
Exemple courant : tout un dossier copié pour une seule modification.
wp-content/themes/parent/
single.php
footer.php
header.php
page.php
wp-content/themes/enfant/
single.php
footer.php
header.php
page.php ← souvent inutile
#La correction consiste à n’extraire que le fichier réellement modifié :
wp-content/themes/enfant/
footer.php ← seul fichier nécessaireIl arrive qu’un intervenant, par prudence, copie tout un dossier du thème parent dans le thème enfant pour modifier une seule ligne. À court terme, cela peut fonctionner. À long terme, la divergence entre les templates du parent et ceux du child devient problématique, surtout lors de mises à jour.
Que fait-on dans ce cas ? On identifie la modification initiale, puis on repart du fichier original du thème parent. On ne recopie dans le child theme que le fichier concerné, et l’on documente clairement l’emplacement et la raison de l’override. Cela permet de suivre les évolutions du thème parent sans perdre le fil.
Fonctions redéclarées dans le child theme
Voici ce que l’on retrouve parfois :
// functions.php enfant
function affiche_message() {
return 'Version enfant';
}
// functions.php parent
function affiche_message() {
return 'Version parent';
}
// La version propre consiste à auditer, puis à orienter vers un hook :
add_filter('affiche_message_filter', function() {
return 'Version enfant';
});La mécanique complète des fonctions pluggables est décrite dans l’article dédié. Il arrive qu’une fonction du thème parent soit redéclarée dans le thème enfant, souvent après un dépannage rapide ou une recherche trouvée en ligne. Ce type de modification peut fonctionner tant que le parent reste stable, mais crée des collisions dès qu’une mise à jour introduit la même fonction.
Que fait-on dans ce cas ? On réalise un audit des redéfinitions présentes dans le child theme : lesquelles sont utiles ? Lesquelles doublonnent une fonction déjà correctement prévue par le parent ? Lesquelles devraient être transformées en hook ? Les aspects techniques pour implémenter proprement une fonction pluggable étant déjà présentés dans notre article Aller plus loin avec un Child-Thème, nous nous concentrons ici sur la logique de reprise et d’assainissement.
Quand plusieurs intervenants se sont succédé
Sur les projets ayant connu plusieurs développeurs, on observe parfois des choix hétérogènes : surcharge CSS d’un côté, surcharge de templates de l’autre, scripts ajoutés en doublon, priorités modifiées pour contourner un comportement inattendu. Le résultat n’est pas “fautif” ; il reflète simplement l’absence de ligne directrice.
Que fait-on dans ce cas ? On établit d’abord un diagnostic : quelles sont les surcharges réellement utiles ? Où se trouvent les duplications ? Quelles dépendances doivent être maintenues ? À partir de cette vue d’ensemble, on reconstruit une structure propre, cohérente et stable.
Pourquoi ces situations nécessitent une analyse dédiée
Les dérives rencontrées dans les child themes hérités ne viennent pas d’erreurs fondamentales : elles proviennent du cycle normal de tout projet vivant. Reprendre un thème enfant, ce n’est pas corriger un manque de compétence, mais remettre de l’ordre après des années d’adaptations successives. Comprendre ces mécanismes permet de restaurer un environnement stable avant de poursuivre l’évolution du site.
Thèmes complexes et child themes
Les thèmes modernes basés sur des builders, qu’il s’agisse d’Avada, Divi, Elementor ou d’outils similaires, suivent une logique très différente des thèmes classiques. Ils génèrent leurs propres styles, leurs propres scripts, leurs mises en forme dynamiques et leurs mécanismes internes d’optimisation. Lorsqu’on hérite d’un projet bâti sur l’un de ces environnements, le child theme reflète souvent un assemblage d’ajustements réalisés au fil des années, parfois indispensables, parfois redondants.
Quand le builder prend déjà la main
Dans de nombreux cas, le builder génère automatiquement les feuilles de styles nécessaires, les scripts spécifiques aux modules utilisés et toute une série d’optimisations internes. Modifier ces éléments via un child theme revient alors à contourner le fonctionnement natif, ce qui entraîne des conflits ou des comportements imprévisibles après mise à jour.
Pour éviter cela, il est utile d’observer ce que le builder produit réellement : quelles feuilles sont chargées, quels scripts sont injectés, et dans quel ordre. Cela permet de déterminer si la surcharge est encore légitime ou si elle peut être remplacée par un réglage interne du builder.
/* Avant – surcharge manuelle dans le child theme */
.fusion-button {
background-color: #ff0000;
border-radius: 4px;
}
/* Après – réglage appliqué directement dans le builder */
/* Aucun CSS dans le child theme, le builder génère automatiquement : */
.fusion-button {
background-color: #1e90ff;
border-radius: 6px;
}Pour appliquer correctement ce type de modification, il est recommandé d’utiliser en priorité les options internes du builder, qu’il s’agisse des réglages du module, des options globales du thème ou, si nécessaire, du panneau de CSS personnalisé du builder. Ces emplacements sont conçus pour être stables lors des mises à jour, contrairement aux feuilles internes générées automatiquement, qui ne doivent jamais être modifiées directement.
Ajustements ponctuels ou stratégie durable
Dans un projet vivant, on retrouve parfois un fichier CSS ajouté pour corriger un composant précis, puis un second pour ajuster une mise en page, puis un script inséré pour compenser un comportement inattendu. Pris isolément, chacun de ces ajouts avait un sens. Ensemble, ils finissent par créer une surcouche difficile à maintenir, d’autant plus si le thème parent évolue régulièrement.
La bonne approche consiste alors à distinguer les corrections réellement nécessaires de celles qui répondaient à des limites anciennes du builder. Une fois cette distinction faite, on peut réduire le volume de code surchargé et recentrer le child theme sur des besoins ciblés.
/* Avant – correctifs accumulés au fil du temps */
/* Fichier : fix-layout.css */
.section-title { margin-top: 40px; }
/* Fichier : adjust-buttons.css */
.button-primary { padding: 18px 26px; }// Script ajouté ponctuellement
add_action('wp_footer', function() {
echo "<script>document.body.classList.add('patched');</script>";
});
// 'patched' était souvent utilisé pour appliquer temporairement un correctif via CSS, par ex. .patched .header { margin-top: 32px; }/* Après – consolidation et nettoyage */
/* Un seul fichier, contrôlé et documenté */
.section-title {
margin-top: 32px; /* valeur réellement souhaitée */
}
.button-primary {
padding: 16px 24px;
}// Après – plus de script injecté inutile
// Le builder gère désormais le comportement correctementQuand l’override n’est pas la solution
Certains projets montrent un child theme contenant des templates copiés depuis le builder ou des scripts détournés pour contourner une fonctionnalité interne. Ces interventions fonctionnent parfois à court terme, mais elles fragilisent le site à long terme. Les builders offrent souvent des points d’extension, des hooks, ou des options d’ajustement qui évitent de devoir surcharger le cœur de leur fonctionnement.
Autrement dit, avant de recopier un fichier ou de modifier un script, il est utile de vérifier si le builder ne propose pas déjà un mécanisme plus propre, stable et durable.
// Avant — surcharge risquée : template du builder recopié
require get_stylesheet_directory() . '/builder-templates/single-post.php';
// Après — ajustement ciblé via un point d’extension du builder
add_filter('builder_single_post_title', function ($titre) {
return $titre . ' · mise à jour';
});Quand un child theme n’est pas nécessaire
Après avoir passé en revue quelques erreurs récurrentes dans les projets hérités et les cas où les thèmes complexes imposent presque un child theme, il reste une situation importante à clarifier. Il existe des projets où créer un thème enfant ne change rien, voire complique la vie sans apporter de bénéfice réel.
Dans certains sites hérités, le thème parent est stable, simple, et le besoin porte surtout sur le contenu. On corrige des textes, on remplace des images, on réorganise quelques pages, mais on ne touche ni à la structure ni aux gabarits. Dans ce contexte, ajouter un child theme ne protège rien de plus, puisqu’aucune surcharge de modèle ou de style n’est prévue.
De nombreux thèmes proposent aujourd’hui un panneau d’options suffisamment riche pour couvrir les besoins courants. Logo, couleurs, typographies, tailles, marges, gabarits de pages, tout se règle dans l’interface sans modifier une seule ligne de code. Tant que le projet reste dans ce cadre, le thème parent suffit, et construire un child theme reviendrait à dupliquer une couche qui ne sera jamais utilisée.
Les thèmes orientés blocs ou édition complète du site suivent la même logique. Les ajustements passent par l’agencement des blocs, la configuration des modèles globaux ou l’éditeur de styles, sans modifier les fichiers. Avec le Customizer, on agit surtout sur les réglages visuels stockés en base. Quant aux builders intégrés, ils permettent de composer des mises en page complètes sans intervention dans le thème. Dans ces approches, tant qu’on reste dans l’usage prévu, un thème enfant n’apporte rien de plus.
Enfin, il faut tenir compte de la capacité de l’équipe à maintenir le site. Dans certains contextes, les personnes qui reprendront le projet ne travaillent que via l’interface d’administration. Si l’on sait que personne ne modifiera les fichiers de modèles ou de styles, créer un child theme ne ferait qu’ajouter une couche technique de plus à expliquer et à documenter.
Que faire lorsqu’un child theme est déjà présent ?
Quand un site possède déjà un child theme alors qu’il n’en a pas réellement besoin, la première étape consiste à vérifier s’il surcharge des fichiers. S’il est vide ou ne contient que quelques lignes inutilisées, il peut être conservé tel quel sans impact. Lorsqu’un child theme ne sert qu’à héberger du CSS, il peut être remplacé par la feuille de styles personnalisée du thème ou par l’outil d’ajustement visuel prévu, ce qui simplifie la maintenance.
Si des modifications plus anciennes ont été placées dedans, il faut les examiner, identifier ce qui est encore utile et transférer ce qui relève du contenu ou des options dans les emplacements prévus. L’objectif n’est pas de supprimer systématiquement le thème enfant, mais de clarifier son rôle pour éviter d’entretenir une couche technique qui ne joue plus aucun rôle concret.
Comment reconstruire un child theme propre après des années d’évolutions
Reprendre un child theme ancien commence par un diagnostic clair. Les fichiers accumulés au fil des années ne reflètent pas toujours les besoins actuels du site, et certaines surcharges autrefois utiles ne correspondent plus au thème parent d’aujourd’hui. L’objectif est de retrouver une base lisible, stable et facile à maintenir.
La première étape consiste à établir une carte précise de ce qui est réellement utilisé. On examine les templates surchargés, on vérifie les CSS effectivement chargés, on identifie les fonctions encore appelées et on repère les scripts laissés en place après un correctif ponctuel. Cette vision d’ensemble permet de distinguer l’essentiel de l’historique.
Une fois cet état des lieux posé, on peut reconstruire un child theme allégé. Les modèles réellement modifiés sont isolés, les fichiers obsolètes sont retirés et les règles de style sont regroupées dans une feuille consolidée. Cette réduction élimine les doublons et clarifie ce qui doit être maintenu dans le temps.
Enfin, un functions.php remis à plat fournit des bases saines. Pour y parvenir, on commence par lister chaque fonction présente et vérifier si elle est encore utilisée. Les ajouts redondants ou liés à d’anciennes versions du thème parent sont retirés. On regroupe ensuite les fonctions utiles dans une structure claire, en évitant les déclarations dispersées ou les hooks ajoutés à la hâte. On conserve uniquement ce qui relève du thème enfant, en laissant au thème parent ce qu’il gère déjà. Ce nettoyage rend le child theme plus cohérent, plus léger et plus simple à maintenir dans la durée.
Pour vérifier si une fonction du child theme est encore utile, plusieurs approches simples s’appliquent. Chercher son nom dans l’ensemble du projet révèle rapidement si elle est encore appelée. Repérer les hooks associés permet de savoir si elle s’attache à une action ou un filtre toujours actif dans le thème parent ou un plugin. Désactiver temporairement une fonction en la commentant montre aussi si son impact est réel ou devenu inutile. Enfin, comparer son rôle avec la version actuelle du thème parent permet d’identifier les ajouts obsolètes, souvent liés à de vieux correctifs désormais intégrés nativement.
Alors, child theme, plugin ou options ? Clarifier les rôles
Dans de nombreux projets WordPress, les difficultés viennent moins du code que d’une mauvaise répartition des modifications. Ce chapitre vise à clarifier les rôles des différents espaces d’intervention, afin de choisir systématiquement l’emplacement le plus stable et le plus durable pour chaque besoin.
- La logique métier relève toujours d’un plugin. Tout ce qui touche aux règles internes, aux traitements, aux formulaires, aux données ou aux comportements spécifiques doit être isolé dans une extension. Cela garantit la pérennité du site même en changeant de thème.
- La mise en page appartient au thème. Structure, gabarits, affichage des contenus, organisation des blocs et logique visuelle se situent dans le parent ou le child. C’est ici que l’HTML et les modèles dictent l’apparence du site.
- Les variations du thème relèvent du child theme. Ajuster un template, modifier un comportement visuel particulier ou personnaliser un bloc spécifique sont des usages naturels du thème enfant, sans affecter le cœur du parent.
- Les réglages globaux doivent passer par le Customizer ou les options du builder. Couleurs, polices, tailles, espacements et mises en page standardisées sont gérés par l’interface prévue, afin d’éviter des surcharges inutiles dans le child.
- Les hooks et filtres peuvent appartenir soit au child, soit au plugin. Les ajustements visuels ou comportementaux qui ne relèvent pas directement du thème peuvent être placés dans une extension légère, surtout lorsqu’ils doivent être réutilisés ou rester fonctionnels en cas de changement de thème.
Un exemple typique :
// Cas métier → plugin
add_action('save_post', function($id) {
// Traitement métier spécifique
});
// Variation visuelle → child theme
override_single_template();
// Réglage global → Customizer
/* Couleur des liens modifiée dans l’interface */
// Hook partagé → selon le besoin
add_filter('excerpt_length', function() { return 24; });Cette grille permet de stabiliser durablement un projet WordPress en répartissant chaque intervention au bon endroit, sans multiplier les contournements ni fragmenter la logique du site.
Gestion de la performance et des mises à jour dans un child theme
Les performances d’un site WordPress reposent autant sur la qualité du thème parent que sur le soin apporté au child theme. Avec le temps, les surcharges successives peuvent alourdir les pages, ralentir l’affichage ou introduire des comportements imprévisibles lors des mises à jour. Ce chapitre propose une lecture simple et opérationnelle des points qui influencent réellement les performances et la stabilité.
- Certaines surcharges ralentissent directement le site. Les feuilles de styles dispersées, les règles qui se contredisent ou les fichiers chargés sans ordre logique augmentent le poids total et la complexité du rendu. Regrouper les CSS utiles dans un fichier unique permet de réduire les doublons et d’améliorer la lisibilité.
- Les scripts mal priorisés sont une autre source fréquente de lenteur. Lorsqu’un script du child theme se charge avant celui du parent, ou qu’il est injecté trop tard dans la page, le navigateur doit recalculer des éléments visuels, ce qui dégrade l’expérience utilisateur. Veiller à la bonne hiérarchie des dépendances améliore la fluidité.
- Les mises à jour du thème parent peuvent provoquer des conflits si le child theme surcharge des fichiers devenus obsolètes. Lorsqu’un modèle évolue, toute copie ancienne dans le child devient une divergence potentielle. Vérifier les différences entre les versions et retirer les surcharges inutiles permet de conserver une base saine.
Avant de déployer un child theme, il est utile de le tester en conditions réelles. Charger le site sans les surcharges, activer progressivement les fonctions du child et observer l’impact sur l’affichage permet d’identifier d’éventuels effets de bord. Ce test par étape limite les risques lors de la mise en production.
Enfin, éviter les effets de bord repose sur une règle simple : intervenir le moins possible dans les couches sensibles. Plutôt que de surcharger un modèle complet, il est souvent plus fiable d’utiliser un hook ou un filtre. Plutôt que de multiplier les feuilles de styles, il est préférable de consolider. Cette approche rend le child theme plus léger, plus stable et plus durable.
Conclusion : Personnaliser un thème, avec ou sans child theme
Personnaliser un thème WordPress ne signifie plus systématiquement créer un child theme. Les outils modernes offrent plusieurs chemins complémentaires, chacun adapté à une intention précise. L’essentiel est de choisir l’espace d’intervention le plus cohérent : les options du thème ou du builder pour les réglages globaux, les blocs et modèles pour l’organisation visuelle, les hooks pour les ajustements ciblés, et le child theme uniquement lorsque la structure ou le comportement doit réellement être modifié.
Cette approche souple permet d’adapter un site sans l’alourdir, en s’appuyant sur les forces du thème parent tout en conservant une marge de personnalisation maîtrisée.
