Blocs HTML : ajouter du contenu personnalisé n’importe où dans votre boutique PrestaShop

Mis à jour en juin 2026, les noms de hooks et le tableau des modules natifs ci-dessous s’appliquent à PrestaShop 1.7, 8 et 9. Dans les back-offices modernes, les positions se gèrent dans Apparence → Positions.

Tôt ou tard, toute boutique PrestaShop se heurte au même problème : vous avez besoin d’un contenu que le thème n’a jamais été conçu pour accueillir. Une barre de livraison gratuite au-dessus de la grille produits. Un message du type "expédition avant Noël si vous commandez avant le 19 décembre" dans l’en-tête. Deux badges de confiance juste sous le bouton d’ajout au panier. Rien de tout cela n’a sa place dans une description produit, une page CMS ou une catégorie. Ce contenu doit apparaître à un emplacement précis, sur des pages précises, et rester en place malgré les mises à jour du thème. C’est exactement le rôle d’un bloc HTML personnalisé : il insère le balisage de votre choix dans une position nommée de votre boutique, sans vous obliger à ouvrir le moindre fichier de template.

Ce guide traite de cette tâche précise : placer du HTML personnalisé au bon endroit dans PrestaShop et contrôler où il s’affiche. Il ne parle pas de mise en forme (c’est un sujet à part entière ; voir CSS et JavaScript personnalisés dans PrestaShop sans casser les mises à jour) et il ne concerne pas le renommage des pages statiques dans votre menu (les noms d’affichage des pages CMS couvrent ce point). Ici, nous restons sur la mécanique du placement.

Pourquoi utiliser des blocs HTML au lieu de modifier le thème

Vous pourriez ouvrir themes/your-theme/templates/catalog/product.tpl et coder ce badge en dur. Deux raisons de ne pas le faire. D’abord, la prochaine mise à jour du thème, ou une resynchronisation d’un thème enfant, peut écraser votre modification et faire disparaître le badge sans bruit. Ensuite, une modification de template est invisible pour toute personne qui n’est pas développeur : impossible de la désactiver pour une vente du week-end ou de changer le texte depuis le back-office. Lorsqu’il est créé via un module comme ps_customtext ou un module dédié aux blocs HTML, le contenu est stocké en base de données et rendu par le système de hooks de PrestaShop ; il survit donc aux mises à jour et se gère depuis Modules ou Apparence, sans toucher à un fichier. Concrètement ? Vous modifiez vous-même un message promotionnel à 9 h avant une vente flash, puis vous le retirez à minuit, sans aucun risque pour le thème.

Les modules natifs qui le font déjà

Avant d’acheter quoi que ce soit, sachez que PrestaShop fournit trois modules gratuits qui couvrent les cas les plus courants. Ils sont généralement disponibles dans les installations standard basées sur Classic et peuvent être installés ou activés depuis le Gestionnaire de modules s’ils manquent :

Pour la plupart des besoins du type "j’ai juste besoin d’un paragraphe de HTML quelque part", ps_customtext est la bonne réponse. Allez dans Modules → Gestionnaire de modules, recherchez "texte personnalisé", cliquez sur Configurer, collez votre HTML dans l’éditeur (passez l’éditeur en vue source/code avec le bouton <> si vous voulez un balisage propre), puis enregistrez. Par défaut, il s’affiche dans displayHome. La limite, et la raison pour laquelle les marchands finissent par le dépasser, est que ps_customtext vous donne un seul bloc modifiable lié à un seul hook, sans ciblage par page ni planification.

Comprendre les positions : les hooks qui décident du "n’importe où"

Dans PrestaShop, "n’importe où" ne signifie pas littéralement n’importe quel pixel, cela signifie n’importe quel hook enregistré. Un hook est un point d’insertion nommé que le thème appelle pendant le rendu d’une page ; le module attaché à ce hook y dépose sa sortie. Vous pouvez voir toutes les positions dans Apparence → Positions (anciennes versions : Modules → Positions), avec la liste de chaque hook et des modules qui y sont actuellement greffés, dans leur ordre d’affichage. Voici les positions importantes pour du contenu personnalisé :

• displayBanner, bande pleine largeur tout en haut, au-dessus de l’en-tête. L’emplacement idéal pour les barres d’annonce globales et les messages de seuil de livraison gratuite. Visible avant tout défilement, sur toutes les pages.
• displayNav1 / displayNav2 / displayTop, dans la zone d’en-tête (à gauche ou à droite de la navigation, ligne utilitaire supérieure). Pratique pour un numéro de téléphone court, une note pays/livraison ou une ligne d’argument commercial discrète.
• displayHome, le corps de la page d’accueil, entre les carrousels produits et les tuiles de catégories. Pour les propositions de valeur et les sections promotionnelles mises en avant.
• displayProductAdditionalInfo, sur la page produit, directement sous la zone d’ajout au panier. C’est là que les promesses de livraison, badges de garantie et icônes de moyens de paiement prennent toute leur valeur, car l’acheteur les lit précisément au moment où il hésite.
• displayFooterBefore / displayFooter, au-dessus et à l’intérieur du pied de page, sur toutes les pages. Badges de confiance, invitations à la newsletter, liens secondaires.
• displayLeftColumn / displayRightColumn, colonnes latérales (là où votre thème en prévoit). Aides aux filtres, promotions de catégories, encarts d’assistance.

La bonne méthode quand vous ne connaissez pas le nom d’une position : ouvrez la page que vous voulez modifier, puis dans Apparence → Positions, utilisez Greffer un module (le bouton "Greffer un module"), la liste déroulante affiche toutes les positions disponibles pour les hooks, et le texte d’aide indique où chacune est rendue. Vous pouvez aussi faire glisser un module vers le haut ou le bas dans un hook pour décider si votre bloc apparaît au-dessus ou au-dessous, par exemple, de la bannière de catégorie.

Ce que les blocs natifs ne savent pas faire, et pourquoi les marchands passent à un module dédié

Le module natif ps_customtext convient très bien jusqu’au moment où vous avez besoin de ce que les vraies boutiques demandent réellement :

• Ciblage par page / par contrôleur. "Afficher ce guide des tailles uniquement dans la catégorie Chaussures, et uniquement sur les pages produit." Les blocs natifs s’affichent sur leur hook partout où celui-ci est appelé ; ils n’ont pas de filtre par page.
• Plusieurs emplacements et contrôle d’activation. Une barre "Dernier jour pour la livraison avant Noël" doit être un bloc nommé que vous pouvez activer, désactiver et déplacer sans modifier un template. La planification par plage de dates est une fonctionnalité distincte ; ne supposez pas qu’un module de blocs la propose si vous ne voyez pas de champs de date dans son back-office.
• Plusieurs blocs indépendants dans le même hook. Une instance de ps_customtext correspond à un bloc ; jongler avec cinq messages différents répartis sur cinq positions devient vite ingérable.
• Contenu compatible multiboutique. Afficher un contenu de bloc différent selon la boutique ou la langue, lorsque le module stocke des lignes par langue et par boutique. Le ciblage par groupe de clients est une couche de règles séparée, pas une fonctionnalité exposée par le bloc de texte natif.
• Blocs compatibles avec le consentement. Si le bloc contient du suivi ou un média intégré, un verrou par catégorie de cookies permet de ne l’afficher que lorsque le visiteur n’a pas refusé cette catégorie.

C’est précisément le vide que comble un module dédié aux blocs HTML : une bibliothèque de blocs nommés, chacun assigné à un ou plusieurs hooks, avec placement par type de page, choix de mise en page, contenu multilingue/boutique, contrôle par catégorie de cookies et, dans des modules comme MPR HTML Blocks, injection dans les templates pour les emplacements où le thème a oublié d’exposer un hook utile. Qu’est-ce que cela vous apporte concrètement ? Vous arrêtez de modifier des templates et d’installer un nouveau module chaque fois que le marketing veut une bannière ; vous créez un bloc une fois, puis vous le dirigez vers le hook ou la zone de page appropriée. Si vous cherchez du contenu sensible à la page et un placement plus propre, c’est l’étape qu’offre un module dédié au-delà du bloc natif, le même principe, mais avec plusieurs blocs, des enregistrements de placement et une injection de template gérés depuis le back-office.

Écrire le HTML pour qu’il survive à l’éditeur

Un problème facile à éviter : TinyMCE et le filtrage HTML de PrestaShop peuvent réécrire ou supprimer le balisage non pris en charge selon la configuration. L’éditeur de texte enrichi va "nettoyer" le balisage qu’il ne reconnaît pas, et le filtrage de sécurité peut retirer les styles inline ou reformater les balises à l’enregistrement. Si votre bloc disparaît ou perd sa mise en forme après un enregistrement, c’est généralement la cause. Les solutions, par ordre de préférence :

Gardez un balisage de bloc simple et basé sur des classes. Voici le type de contenu en vue source qui résiste au nettoyage de l’éditeur et laisse toute la mise en forme à la feuille de style du thème.

<section class="promo-bar promo-bar--shipping">
  <p><strong>Free delivery this weekend.</strong> Orders over 75 EUR ship free until Monday.</p>
  <p><a href="/delivery">See delivery conditions</a></p>
</section>

Une page produit de la boutique avec du contenu dans l'onglet Description.

• Activez la vue code source de l’éditeur (le bouton <> / "Outils → Code source") et collez le balisage à cet endroit, pas dans le panneau WYSIWYG.
• Gardez la mise en forme dans une classe, pas en inline. Placez une classe comme promo-bar sur votre bloc et définissez .promo-bar dans la feuille de style personnalisée de votre thème, l’éditeur laisse les attributs de classe tranquilles, et vous bénéficiez de la mise en forme qui survit aux mises à jour, comme expliqué dans CSS et JavaScript personnalisés sans casser les mises à jour.
• Si un bloc doit exécuter du JavaScript, attachez-le via le hook d’assets approprié plutôt que de coller une balise <script> dans l’éditeur. Les scripts inline dans les blocs de contenu sont fragiles et faciles à casser à l’enregistrement. Ce mécanisme est un sujet à part, traité dans le même guide CSS/JS.

Gardez vos blocs rapides et cohérents avec votre marque

Deux disciplines de conception déterminent si un bloc aide ou nuit. D’abord, respectez le thème. Reprenez la même pile de polices, la même couleur d’accent et le même rythme d’espacement que votre thème utilise déjà, afin que le bloc fasse partie de la boutique au lieu de ressembler à un ajout plaqué après coup. Ensuite, restez concis. Une bannière, c’est une phrase plus un appel à l’action ; une bande de confiance, ce sont des icônes reconnaissables, pas un paragraphe. La valeur d’un bloc tient à ce qu’il ajoute au bon moment, pas à la quantité de contenu que vous y entassez.

Côté performance : chaque bloc ajoute du balisage, et les blocs chargés en images sont généralement les plus lourds. Servez des images aux bonnes dimensions et correctement compressées, utilisez le CSS pour la mise en page et les effets plutôt que de charger une bibliothèque, et si plusieurs blocs sont actifs en même temps, vérifiez leur impact cumulé dans le panneau réseau de votre navigateur. La vitesse de page fait partie des signaux pris en compte par Google ; une pile de bannières trop lourdes peut donc discrètement nuire au reste de votre travail on-page. Gardez un balisage léger et le gain reste un gain.

Guide de décision rapide

Si les blocs HTML méritent d’être maîtrisés, c’est pour la raison même qui les rend utiles au départ : ils permettent à un propriétaire de boutique, pas à un développeur, de placer le bon message au bon endroit, au bon moment, puis de le retirer tout aussi facilement, sans jamais mettre le thème en danger. Apprenez les noms des positions, utilisez les blocs natifs gratuits pour les besoins simples, passez à un module dédié dès que vous avez besoin de plusieurs blocs, d’un placement sensible à la page ou d’une injection sûre pour le thème, et gardez chaque bloc léger et cohérent avec votre marque. Faites cela, et une installation PrestaShop standard commence à parler avec la voix propre de votre boutique exactement aux moments qui déclenchent une vente.

Questions fréquentes

"N’importe où" signifie-t-il vraiment n’importe quel emplacement sur la page ?

Pas littéralement, cela signifie n’importe quel hook enregistré. Un hook est un point d’insertion nommé que le thème appelle pendant le rendu d’une page, et la sortie de votre bloc se place là où ce hook est exécuté. Vous pouvez voir toutes les positions disponibles dans Apparence → Positions. Si l’emplacement exact que vous voulez n’a pas de hook, c’est là que la fonction d’injection dans les templates d’un module dédié prend tout son intérêt, puisqu’elle peut cibler des positions que le thème n’a jamais exposées sous forme de hook.

Quel module natif utiliser pour un simple bloc HTML ?

Pour un paragraphe de HTML, utilisez ps_customtext, recherchez "texte personnalisé" dans le Gestionnaire de modules, cliquez sur Configurer, puis collez votre balisage (utilisez la vue source <> pour obtenir un code propre). Pour une image de bannière avec un lien en haut de chaque page, utilisez ps_banner ; pour les listes de liens en pied de page, ps_linklist. Tous trois sont fournis gratuitement avec les installations basées sur Classic et stockent le contenu en base de données, ce qui lui permet de survivre aux mises à jour du thème.

Où placer un badge de confiance ou une promesse de livraison sur la page produit ?

Dans le hook displayProductAdditionalInfo, qui s’affiche directement sous la zone d’ajout au panier. C’est là que les badges de garantie, promesses de livraison et icônes de moyens de paiement prennent toute leur valeur, car l’acheteur les lit précisément au moment où il hésite. Greffez votre bloc à cet endroit via Apparence → Positions → Greffer un module plutôt que de modifier product.tpl.

Mon bloc a perdu sa mise en forme ou a disparu après l’enregistrement. Pourquoi ?

Presque toujours à cause de TinyMCE ou du filtrage HTML de PrestaShop qui "nettoie" le balisage à l’enregistrement, l’éditeur réécrit les balises qu’il ne reconnaît pas, et le filtrage de sécurité peut supprimer les styles inline. La solution : collez le contenu dans la vue code source de l’éditeur, pas dans le panneau WYSIWYG, et gardez la mise en forme dans une classe CSS (définissez .promo-bar dans la feuille de style de votre thème) plutôt qu’en inline. L’éditeur laisse les attributs de classe intacts.

Quand ps_customtext ne suffit-il plus et faut-il passer à un module dédié ?

Dès que vous avez besoin de l’un des éléments suivants : ciblage par page ou par contrôleur (par exemple un guide des tailles uniquement dans la catégorie Chaussures), plusieurs blocs indépendants gérés au même endroit, contenu de bloc multiboutique ou multilingue, contrôle du consentement aux cookies pour les blocs contenant du suivi, ou placement à un endroit que le thème n’expose via aucun hook. ps_customtext vous donne un bloc lié à un hook, sans filtre par page, très bien jusqu’à l’apparition de ces besoins.

Puis-je exécuter du JavaScript dans un bloc HTML ?

Ne collez pas une balise <script> brute dans l’éditeur. Les scripts inline dans les blocs de contenu sont fragiles, faciles à casser à l’enregistrement, et contournent la gestion des assets de PrestaShop. Attachez plutôt le comportement sous forme de fichier .js externe via le hook d’assets approprié, exactement comme expliqué dans CSS et JavaScript personnalisés sans casser les mises à jour. Limitez le bloc au balisage et à une classe CSS.

Trop de blocs peuvent-ils ralentir la boutique ?

Oui, chaque bloc ajoute du balisage, et les blocs riches en images sont généralement les plus lourds. Servez des images aux bonnes dimensions et compressées, utilisez le CSS pour la mise en page plutôt que de charger une bibliothèque, et si plusieurs blocs sont actifs à la fois, vérifiez leur coût cumulé dans le panneau réseau de votre navigateur. La vitesse de page est l’un des signaux pris en compte par Google ; une pile de bannières trop lourdes peut donc affaiblir discrètement le reste de votre travail on-page.

Guides associés

• CSS et JavaScript personnalisés dans PrestaShop sans casser les mises à jour
• Noms d’affichage des pages CMS : une meilleure navigation pour vos pages statiques
• Thèmes enfants dans PrestaShop : pourquoi vous ne devez jamais modifier le thème parent