Un thème enfant pour Divi sert à personnaliser un site sans toucher au cœur du thème parent, ce qui change tout dès qu’un projet commence à évoluer. Je vais vous montrer la logique à suivre, les cas où il faut vraiment en créer un, la structure minimale à prévoir et la manière de garder une interface propre sans transformer le site en patchwork de réglages dispersés.
Les points essentiels à retenir avant de modifier Divi
- Un thème enfant protège vos modifications de code et de modèles lors des mises à jour du thème parent.
- Pour de petites retouches visuelles, Divi propose déjà plusieurs emplacements adaptés avant même de créer un child theme.
- La base minimale tient en 2 fichiers : `style.css` et `functions.php`.
- Le thème enfant devient vraiment utile dès qu’on touche au PHP, aux templates ou à une personnalisation répétitive.
- La bonne méthode consiste à séparer design, structure et fonctionnalité au lieu de tout entasser au même endroit.
Ce qu’un thème enfant change vraiment dans Divi
Dans WordPress, un thème enfant hérite du thème parent tout en vous laissant modifier ce qui doit l’être. Avec Divi, l’intérêt est très concret : vous gardez le confort du constructeur visuel, mais vous ajoutez une couche propre pour les ajustements qui doivent survivre aux mises à jour. C’est cette séparation qui évite les bricolages fragiles.
Je le résume souvent ainsi : Divi gère bien l’interface, le thème enfant gère bien la structure durable. Si vous ne faites que changer quelques couleurs, marges ou blocs de contenu, les outils natifs de Divi suffisent souvent. Si vous commencez à toucher à des fonctions PHP, à des gabarits de page, à des hooks ou à du code réutilisable, le child theme devient la bonne base de travail.
Cette distinction paraît simple, mais elle évite beaucoup d’erreurs. Le lecteur qui cherche une solution autour d’un thème enfant pour Divi ne veut pas seulement “savoir ce que c’est” : il veut surtout savoir à quel moment cela devient réellement utile. C’est justement le point suivant.
Quand l’utiliser et quand s’en passer
Je ne crée pas un thème enfant par réflexe. Je le crée quand il apporte un gain réel en maintenance, en clarté ou en sécurité. À l’inverse, si la personnalisation peut rester dans l’interface de Divi sans alourdir le projet, je préfère garder une configuration plus simple.
| Besoin | Meilleur choix | Pourquoi |
|---|---|---|
| Ajuster une page d’accueil, une section ou un header | Divi Builder ou Theme Builder | Rapide, visuel, facile à reprendre plus tard |
| Ajouter quelques règles CSS ciblées | CSS de Divi ou CSS du module | Le style reste proche de l’élément concerné |
| Modifier un template PHP ou une fonction du thème | Thème enfant | Les changements résistent aux mises à jour du parent |
| Construire une interface cohérente sur plusieurs sites | Thème enfant + base de styles réutilisable | On standardise le travail et on réduit les écarts entre projets |
| Ajouter une logique métier indépendante du design | Plugin dédié | Une fonctionnalité ne devrait pas dépendre du thème si elle doit rester active ailleurs |
La règle pratique est simple : si la modification concerne surtout l’apparence, restez dans Divi ; si elle concerne la structure ou le comportement global, passez par le thème enfant. Je trouve aussi utile de penser en couches : l’interface dans le builder, le code dans le child theme, et la fonctionnalité dans un plugin quand elle doit rester indépendante. Cette logique rend l’ensemble beaucoup plus propre à maintenir.
Une fois ce tri fait, on peut construire la base technique sans perdre de temps dans des fichiers inutiles.
La structure minimale d’un thème enfant Divi
Pour démarrer, il suffit en pratique de deux fichiers dans un dossier dédié au thème enfant. Le premier décrit le thème, le second permet de charger correctement les styles et d’ajouter vos fonctions personnalisées.
Le fichier style.css contient l’en-tête du thème. Le point important est le champ Template : il doit correspondre au nom du dossier du thème parent, ici Divi. Sans cela, WordPress ne fait pas le lien entre les deux.
/*
Theme Name: Divi Child
Template: Divi
Version: 1.0
*/Le fichier functions.php sert à charger les styles du parent puis vos propres ajouts. Je préfère une structure lisible plutôt qu’un bloc de code difficile à relire six mois plus tard.
get( 'Version' )
);
}Selon le niveau de personnalisation, vous pouvez aussi ajouter un screenshot.png pour rendre le thème plus identifiable dans l’admin WordPress. Ce n’est pas obligatoire, mais c’est utile si plusieurs thèmes sont présents dans le back-office. Le point clé reste ailleurs : la base doit être légère, lisible et prête à recevoir du CSS ou du PHP sans désordre.
Une fois cette structure en place, il reste à l’activer et à vérifier que tout fonctionne sans casser le rendu.
Créer et activer le thème enfant sans friction
J’aime garder la procédure courte. Plus elle est simple, moins on introduit d’erreurs au moment de la mise en ligne ou d’une reprise de projet par un autre intervenant.
- Créer un dossier dédié, par exemple
divi-child, dans/wp-content/themes/. - Ajouter le fichier
style.cssavec l’en-tête du thème et le bonTemplate: Divi. - Ajouter
functions.phppour charger proprement le style parent et vos ajouts. - Compresser le dossier en
.zipou l’envoyer en FTP selon votre méthode de déploiement. - Activer le thème dans Apparence > Thèmes.
- Vérifier immédiatement l’en-tête, le pied de page, les gabarits principaux et l’affichage mobile.
Je conseille toujours un contrôle en 3 points après activation : les pages clés, les modules personnalisés et la version responsive. Si quelque chose déraille, le problème vient souvent d’un style mal chargé, d’un cache persistant ou d’une règle CSS qui écrase un élément plus large que prévu. Sur un site déjà en production, la préproduction reste la meilleure assurance contre les mauvaises surprises.
Ce contrôle rapide prépare la vraie question suivante : où doit vivre chaque type de personnalisation dans Divi ?
Où placer chaque type de personnalisation dans Divi
Le plus gros piège sur Divi n’est pas technique, il est organisationnel. Beaucoup de sites finissent avec du CSS dans quatre endroits différents, du code ajouté à la volée et des exceptions impossibles à retrouver. J’essaie au contraire de garder une carte mentale simple, parce qu’une interface propre se maintient mieux qu’une interface “moulinée” à la main.
| Type de modification | Emplacement conseillé | Lecture pratique |
|---|---|---|
| Typographies, couleurs, espacements globaux | Options de Divi ou Theme Builder | Rapide à ajuster et visible immédiatement |
| Style d’un module précis | CSS du module, de la section ou de la page | Le changement reste localisé au composant concerné |
| En-tête, pied de page, modèles d’articles | Theme Builder | On contrôle les gabarits sans écrire tout le thème à la main |
| Fonctions PHP, filtres, templates personnalisés | Thème enfant | Le code reste centralisé et durable |
| Fonctionnalité métier indépendante du design | Plugin | On évite de coupler une fonctionnalité à un choix graphique |
La documentation de Divi montre bien que le thème accepte plusieurs zones de CSS et de code, mais cela ne veut pas dire qu’il faut tout disperser. Mon approche est plus stricte : le builder pour composer, le child theme pour sécuriser, le plugin pour isoler ce qui doit vivre indépendamment. C’est ce découpage qui garde un site lisible quand il grandit.
Cette discipline évite ensuite les erreurs classiques que je vois revenir sur les projets mal structurés.
Les erreurs qui cassent la maintenance
Il y a quelques erreurs que je repère très vite sur un site Divi. Elles ne font pas toujours planter le site, mais elles compliquent la vie de la personne qui devra le maintenir ensuite. Et dans la plupart des cas, ce sera vous quelques mois plus tard.
- Modifier directement le thème parent : tout peut disparaître à la prochaine mise à jour.
- Mettre tout le CSS au même endroit : on perd la logique de priorité et la lecture devient pénible.
- Dupliquer la même règle dans plusieurs emplacements : le dernier style chargé gagne, ce qui crée des effets difficiles à diagnostiquer.
- Oublier le responsive : une belle maquette desktop peut se dégrader très vite sur mobile si les espacements ne sont pas testés.
- Confondre personnalisation et fonctionnalité : un code métier placé dans le thème finit souvent au mauvais endroit.
- Ne pas documenter les choix : sans repère, la reprise du projet devient un travail d’enquête.
Je recommande aussi de garder une copie claire des changements majeurs, même simple, avec les dates de modification et l’endroit où le code a été placé. Ce n’est pas du formalisme inutile : sur un site en production, c’est ce qui fait gagner du temps au prochain audit ou au prochain refonte partielle. Et sur Divi, où plusieurs couches de personnalisation coexistent, cette traçabilité devient vite précieuse.
À ce stade, la meilleure méthode n’est plus théorique : elle tient en une règle de travail très simple.
La règle simple que j’applique sur un site Divi qui évolue
Sur un projet réel, je garde toujours trois niveaux bien séparés. Le constructeur visuel sert à construire la page, le thème enfant sert à protéger le code, et les plugins servent à porter les fonctionnalités durables. Cette règle évite l’encombrement et facilite les mises à jour sans arbitrage permanent.
Si votre site est une vitrine légère, un child theme peut rester très sobre. Si votre site s’enrichit de modèles spécifiques, de scripts, de fonctions personnalisées ou d’une identité graphique très structurée, je vous conseille de le créer tôt plutôt que tard. On travaille alors avec une base propre, au lieu de rattraper des ajustements dispersés.
Au fond, la bonne décision n’est pas de créer un thème enfant “par principe”, mais de le créer dès qu’une modification doit rester stable, lisible et récupérable par quelqu’un d’autre. C’est ce seuil-là qui fait la différence entre une personnalisation confortable et un site difficile à faire évoluer.
