Thèmes enfants dans PrestaShop : pourquoi ne jamais modifier le thème parent

Dernière mise à jour : juin 2026, couvre les thèmes enfants avec Hummingbird (PrestaShop 9, pipeline SCSS) comme avec Classic (PrestaShop 8). Le mécanisme de surcharge est identique avec les deux parents.

Voici le moment qui transforme un marchand PrestaShop satisfait en marchand frustré : vous avez acheté un thème premium, vous vouliez modifier trois petites choses, une police de titre différente, la couleur de votre marque sur les boutons, un ajustement de la mise en page produit, alors vous avez ouvert /themes/your-theme/templates/catalog/product.tpl et vous l’avez modifié. Le résultat était parfait. Puis, six semaines plus tard, l’auteur du thème a publié la version 2.1 avec un correctif de sécurité et une galerie produit plus rapide. Vous avez lancé la mise à jour. Toutes vos modifications ont disparu, écrasées, irrécupérables sauf si vous avez la chance de disposer d’une sauvegarde à comparer.

C’est l’erreur que l’on s’inflige le plus souvent dans la personnalisation PrestaShop, alors qu’elle dispose depuis des années d’une vraie solution : le thème enfant. Ce guide porte précisément sur cela, ce qu’est réellement un thème enfant PrestaShop au niveau du système de fichiers, comment l’ordre de résolution des surcharges décide quel fichier l’emporte, comment en créer un avec Hummingbird ou Classic, et où se situe exactement la limite entre « utiliser un thème enfant » et « il faut plutôt un module ». Si ce que vous voulez réellement, c’est ajouter un extrait de CSS ou un script de suivi sans rien dupliquer, c’est un besoin plus ciblé qui a sa propre réponse, consultez CSS et JavaScript personnalisés sans casser les mises à jour, et nous vous y renverrons au bon moment plus bas.

Ce qu’est réellement un thème enfant (au niveau des fichiers)

Un thème enfant est un répertoire de thème distinct qui déclare un parent dans son config/theme.yml et hérite de tout ce parent, chaque template, chaque ressource, chaque valeur de configuration, tout en vous permettant de surcharger des fichiers précis. Ce n’est pas une copie du parent. C’est une couche légère posée par-dessus. Tout fichier que vous ne placez pas dans l’enfant est servi depuis le parent ; tout fichier que vous placez dans l’enfant l’emporte.

L’intérêt pratique est toute la raison d’être de la technique : comme l’enfant vit dans son propre répertoire, une mise à jour du parent touche le parent et laisse votre travail intact. Le parent passe en v2.1, vos surcharges continuent de fonctionner au-dessus de la v2.1, et vous passez votre soirée à faire autre chose que reconstruire vos personnalisations de mémoire. Vous bénéficiez des corrections de bugs et des améliorations de vitesse de l’auteur du thème et de votre identité visuelle, au lieu d’avoir à choisir entre les deux.

L’ordre de résolution des surcharges. Le mécanisme qui fait fonctionner l’ensemble

Pour faire confiance aux thèmes enfants, vous devez savoir précisément comment PrestaShop décide quel template afficher. Lorsqu’un contrôleur demande un template, la couche de rendu du thème cherche dans un ordre fixe et s’arrête au premier résultat trouvé :

C’est pourquoi « copier le seul fichier nécessaire, puis modifier la copie » fonctionne sans casser le reste : PrestaShop résout chaque template indépendamment. Surchargez product.tpl et le reste de la boutique continue d’être rendu depuis le parent. Il n’y a pas d’interrupteur tout-ou-rien, l’enfant intercepte uniquement les chemins exacts que vous renseignez, puis laisse tout le reste se replier vers le parent. Ce repli est une fonctionnalité, pas une limite : moins vous interceptez de fichiers, plus les mises à jour du parent arrivent directement dans votre boutique.

config/theme.yml, le fichier qui déclare la relation

Toute l’hérédité repose sur un seul fichier dans le répertoire config/ de votre thème enfant, config/theme.yml. La clé parent indique à PrestaShop « utilise tout depuis ce thème sauf si je le surcharge ». Un enfant minimal basé sur Hummingbird ressemble à ceci :

parent: hummingbird
name: my-store-child
display_name: My Store Child
version: 1.0.0
assets:
  use_parent_assets: true

La valeur de parent doit correspondre au nom du répertoire du thème parent (et le parent doit réellement être installé. Un enfant ne peut pas hériter d’un thème absent du serveur). Le name doit être unique et correspondre au nom du propre répertoire de l’enfant. Si l’un des deux est incorrect, PrestaShop revient silencieusement au parent ou refuse d’activer le thème, deux cas plus faciles à diagnostiquer quand on sait qu’il s’agit presque toujours d’une incohérence de nom dans ce fichier.

Créer un thème enfant étape par étape

Un thème enfant ne fait rien tant qu’il n’est pas sélectionné comme thème actif.

• Créez le répertoire, par exemple /themes/my-store-child/, avec un répertoire config/ à l’intérieur. Ne copiez pas les fichiers du parent dedans. Un thème enfant minimal peut être très petit, mais il doit inclure un config/theme.yml valide déclarant le parent, le nom, display_name et la version, une fois ce fichier en place, il s’affiche exactement comme le parent.
• Ajoutez config/theme.yml dans /themes/my-store-child/config/theme.yml avec la référence au parent montrée ci-dessus.
• Copiez uniquement les fichiers que vous modifiez réellement, en conservant le chemin relatif. Pour personnaliser la page produit, copiez /themes/hummingbird/templates/catalog/product.tpl vers /themes/my-store-child/templates/catalog/product.tpl et ne modifiez que la copie de l’enfant.
• Activez-le dans le back-office sous Apparence → Thème & logo. Créer le répertoire ne fait rien à lui seul, tant que vous ne sélectionnez pas et n’utilisez pas le thème enfant ici, la boutique continue de servir le parent. C’est la question de support numéro un du type « pourquoi mon changement ne s’affiche pas », et la réponse est presque toujours : l’enfant n’a jamais été activé.

L’arborescence du thème enfant reflète exactement celle du parent. Le rôle d’un template est de vivre au même chemin relatif dans l’enfant que dans le parent. C’est cette correspondance de chemin qui permet au résolveur de les associer.

Ce qui a sa place dans un thème enfant, et ce qui n’y a pas sa place

Templates (.tpl), oui, c’est le bon outil

Les changements structurels de balisage, réorganiser les blocs de la page produit, ajouter une section d’information personnalisée, modifier le rendu de l’en-tête. Sont exactement le rôle des surcharges de template. Copiez le template parent dans le chemin enfant correspondant et modifiez-le. Surcharger le template front d’un module (un fichier sous /themes/[theme]/modules/[module]/views/templates/front/[template].tpl) est aussi une technique documentée, mais sachez que c’est un point faible connu avec les thèmes enfants en particulier : la documentation PrestaShop sur les thèmes enfants ne couvre pas les surcharges de templates de module, et des rapports ouverts signalent qu’elles se résolvent de manière incohérente depuis un enfant (le cache de template peut servir la copie du parent à la place). Si vous devez adapter l’affichage d’un module et que vous utilisez un thème enfant, testez-le soigneusement sur votre version, ou placez la surcharge directement sur le thème actif plutôt que de vous appuyer sur le repli parent/enfant.

CSS et JavaScript, généralement la mauvaise couche pour le faire

Si votre modification est purement visuelle, couleurs, polices, espacements, masquage d’un élément, surcharger un template entier est une méthode lourde, et elle vous oblige à réintégrer les changements de ce template à chaque mise à jour du parent. L’approche plus légère et plus sûre pour les mises à jour consiste à charger une feuille de style ou un script après les ressources du parent, sans dupliquer la moindre logique de template. C’est un besoin suffisamment distinct pour avoir son propre guide : CSS et JavaScript personnalisés dans PrestaShop sans casser les mises à jour. La règle pratique : n’utilisez une surcharge de template que lorsque vous devez réellement changer le balisage ; pour tout ce que CSS peut faire, faites-le en CSS.

Logique métier, ni l’un ni l’autre ; c’est un module

La limite stricte : si votre modification touche au comportement. Comment les prix sont calculés, comment la livraison est choisie, ce qui se passe au paiement, un thème enfant n’est absolument pas le bon endroit. Les templates affichent des données ; ils ne doivent pas les traiter. Dès que vous vous surprenez à écrire une vraie logique PHP dans un fichier .tpl, vous avez placé du code métier dans la couche de présentation, où il ne peut pas être testé, réutilisé ni mis à jour proprement. Ce travail appartient à un module (ou à une classe de surcharge), pas au thème. Un thème décide de l’apparence du panier ; un module décide du comportement du panier.

Pourquoi « léger » est une règle ferme, pas une coquetterie

Chaque fichier que vous surchargez est un fichier qui cesse de recevoir les corrections de l’auteur du parent. Si le parent publie un product.tpl corrigé et plus accessible en v2.1 et que vous avez votre propre copie, vous ne recevrez pas cette correction. Votre copie reste figée sur le balisage de la v2.0 jusqu’à ce que vous fusionniez manuellement la différence. Chaque surcharge entraîne donc un coût de maintenance continu, et la facture arrive à chaque mise à jour du parent.

La discipline qui maintient ce coût faible : surchargez la plus petite unité qui fait le travail. Besoin d’ajouter une classe à un seul élément ? Surchargez ce template précis, pas son layout parent, pas tout le dossier catalogue. Besoin d’un changement de couleur ? C’est du CSS, pas un template. Un thème enfant avec quatre fichiers surchargés se met à jour en cinq minutes ; un thème enfant avec quarante fichiers devient un projet à chaque évolution du parent.

Survivre à une mise à jour du thème parent

Lorsque l’auteur du parent publie une nouvelle version, la routine est courte parce que l’architecture fait le gros du travail :

• Mettez le parent à jour. Votre enfant est un répertoire séparé, donc rien de ce que vous avez écrit n’est écrasé.
• Comparez vos surcharges avec les nouvelles versions du parent. Pour chaque fichier que vous avez copié, comparez votre copie enfant figée avec la nouvelle copie du parent à l’aide de n’importe quel outil de diff. C’est le seul endroit où le coût de maintenance se paie, et il n’est jamais plus grand que votre nombre de surcharges.
• Fusionnez ce qui mérite d’être conservé, une correction de bug, un nouveau champ, une amélioration d’accessibilité ajoutée par l’auteur à un template que vous surchargez, dans votre copie enfant.
• Testez les pages concernées, en particulier celles dont vous surchargez les templates, avant et après.

Les fichiers que vous n’avez pas surchargés ne demandent rien de tout cela. Ils ont été mis à jour automatiquement dès que vous avez mis le parent à jour. Cette asymétrie est tout le rendement de la technique : vous ne faites le travail de comparaison et de fusion qu’à hauteur de ce que vous avez personnalisé, et vous obtenez tout le reste gratuitement.

Hummingbird ou Classic, quel parent choisir en 2026

Hummingbird est l’orientation moderne du thème officiel PrestaShop pour l’ère PS 9, tandis que Classic reste courant et disponible, surtout sur PS 8 et les boutiques plus anciennes. Le mécanisme de thème enfant est identique quel que soit le parent, même config/theme.yml, même ordre de résolution, mais le parent choisi change votre construction des assets :

Si vous migrez depuis PrestaShop 8 avec un thème enfant basé sur Classic, vous n’êtes pas obligé de passer à Hummingbird dès le premier jour. Classic reste disponible en téléchargement séparé, mais une nouvelle création devrait commencer sur Hummingbird. Comme le pipeline de feuilles de style de Hummingbird repose sur SCSS, la façon de compiler votre CSS personnalisé diffère de Classic ; le choix du parent affecte donc surtout votre flux de travail de style, pas la logique de surcharge. Choisir le bon thème de base dès le départ est une décision à prendre délibérément, nous l’abordons dans comment choisir le bon thème PrestaShop pour votre entreprise.

Les erreurs courantes qui persistent

• L’enfant n’a jamais été activé. Le répertoire et config/theme.yml existent, mais la boutique sert toujours le parent parce que personne n’a sélectionné l’enfant sous Apparence → Thème & logo. C’est toujours la première chose à vérifier.
• Incohérence de nom dans config/theme.yml. Le name ne correspond pas au répertoire, ou parent pointe vers un thème qui n’est pas installé. L’enfant retombe silencieusement sur le parent ou ne s’active pas.
• Prolifération des surcharges. Quarante templates copiés parce que « c’était plus simple de copier tout le dossier ». Chacun est désormais une fusion manuelle à chaque mise à jour du parent. Gardez l’ensemble léger dès la conception.
• Aucun contrôle de version. Un thème enfant est du code personnalisé. Il doit être dans Git avec de vrais messages de commit, afin qu’une mauvaise fusion après une mise à jour du parent puisse être annulée en un revert, pas devenir un jeu de devinettes.
• « Juste cette fois » sur le parent. Il n’y a pas de juste cette fois. Une modification directe du parent devient vingt modifications, puis la mise à jour que vous ne pouvez plus appliquer est celle de sécurité dont vous aviez le plus besoin. Chaque changement, aussi petit soit-il, va dans l’enfant.

Conclusion

Un thème enfant se met en place en une dizaine de minutes, un répertoire, un config/theme.yml, le nom du parent correctement orthographié, une activation dans le back-office, et il transforme chaque future mise à jour du parent, non plus en effacement de personnalisations, mais en non-événement. Ce n’est ni une technique avancée ni une bonne pratique optionnelle ; sur PrestaShop, c’est simplement la bonne manière de personnaliser tout thème que vous n’avez pas écrit vous-même. Si vous modifiez actuellement directement les fichiers du thème parent, la marche à suivre est la même, quelle que soit la taille apparente de vos changements : créez un thème enfant aujourd’hui et déplacez-y vos surcharges avant que la prochaine mise à jour ne les écrase. Puis gardez-le léger, placez le style pur dans du CSS et du JS qui survivent aux mises à jour, placez le comportement dans des modules, et réservez les surcharges de template aux changements de balisage qui en ont réellement besoin.

Questions fréquentes

Dois-je copier tout le thème parent dans mon enfant ?

Non, et vous ne devriez pas. Un thème enfant hérite par défaut de tout le parent ; vous ne copiez que les fichiers précis que vous modifiez, en conservant leur chemin relatif. Un enfant minimal peut n’être qu’un répertoire avec un config/theme.yml valide, et il s’affichera exactement comme le parent. Moins vous copiez de fichiers, plus les mises à jour du parent arrivent directement dans votre boutique.

Mon thème enfant ressemble exactement au parent et aucune de mes modifications ne s’affiche. Pourquoi ?

Presque toujours pour l’une de deux raisons : l’enfant n’a jamais été activé sous Apparence → Thème & logo (créer le répertoire ne fait rien à lui seul), ou il y a une incohérence de nom dans config/theme.yml, le name ne correspond pas au répertoire de l’enfant, ou parent pointe vers un thème qui n’est pas installé. Vérifiez d’abord l’activation, puis le YAML.

Puis-je mettre mon CSS et mon JavaScript personnalisés dans le thème enfant ?

Vous le pouvez, mais pour des changements purement visuels, couleurs, polices, espacements, masquage d’un élément, surcharger un template entier est lourd et impose de réintégrer les changements à chaque mise à jour du parent. Une feuille de style ou un script chargé après les ressources du parent est plus léger et ne duplique aucune logique de template. Réservez les surcharges de template aux vrais changements de balisage ; pour tout ce que CSS peut faire, faites-le en CSS. Voir CSS et JavaScript personnalisés sans casser les mises à jour.

Mes surcharges survivront-elles aux mises à jour du thème parent ?

Oui, l’enfant vit dans son propre répertoire, donc une mise à jour du parent ne le touche jamais. La seule tâche que vous devez assumer est de comparer chaque fichier surchargé avec la nouvelle version du parent et d’y fusionner tout changement utile (une correction de bug, une amélioration d’accessibilité). Ce travail est proportionnel uniquement au nombre de fichiers que vous avez copiés, ce qui explique exactement pourquoi il est rentable de garder un nombre de surcharges réduit.

Un thème enfant peut-il surcharger le template front-end d’un module ?

C’est une technique documentée, mais c’est un point faible connu avec les thèmes enfants en particulier, des rapports ouverts signalent que les surcharges de templates de module se résolvent de manière incohérente depuis un enfant, car le cache de template peut servir la copie du parent à la place. Si vous devez adapter l’affichage d’un module et que vous utilisez un thème enfant, testez-le soigneusement sur votre version exacte, ou placez la surcharge directement sur le thème actif plutôt que de vous appuyer sur le repli parent/enfant.

Le changement que je veux concerne le comportement, pas l’apparence. Va-t-il dans le thème enfant ?

Non. Si vous changez la façon dont les prix sont calculés, dont la livraison est choisie ou ce qui se passe au paiement, c’est de la logique métier et cela appartient à un module ou à une classe de surcharge, jamais à un fichier .tpl. Les templates affichent des données ; ils ne doivent pas les traiter. Un thème décide de l’apparence du panier ; un module décide du comportement du panier.

Un thème enfant doit-il être placé sous contrôle de version ?

Oui. Un thème enfant est du code personnalisé, et il doit être dans Git avec de vrais messages de commit. Le bénéfice apparaît après une mise à jour du parent : si une fusion se passe mal, vous êtes à un revert d’un état connu et fonctionnel au lieu de devoir deviner ce que vous aviez changé. Cela permet aussi de voir immédiatement quels fichiers du parent vous avez dérivés et devrez donc comparer à la prochaine mise à jour.

Hummingbird et Classic nécessitent-ils des configurations de thème enfant différentes ?

Le mécanisme de surcharge est identique, même config/theme.yml, même ordre de résolution, donc le choix du parent ne change pas la logique. Ce qu’il change, c’est votre flux de travail de style : le pipeline de feuilles de style de Hummingbird repose sur SCSS, tandis que celui de Classic est plus simple, donc la compilation du CSS personnalisé diffère. Choisissez Hummingbird pour les nouvelles créations et Classic lorsque vous maintenez un enfant existant basé sur Classic.

Guides associés

• CSS et JavaScript personnalisés dans PrestaShop sans casser les mises à jour
• Comment choisir le bon thème PrestaShop pour votre entreprise
• Blocs HTML : ajouter du contenu personnalisé partout dans votre boutique PrestaShop