Une boutique PrestaShop reçoit les mêmes questions toute la journée. Le colis est parti ? Ce produit convient-il à mon installation ? Quelle différence entre ces deux références ? Brancher un chatbot dessus paraît trivial. En pratique, l’intégration échoue souvent sur trois détails que personne ne documente : le mode d’injection, la politique de sécurité de contenu, et le cache.
Ce guide traite l’intégration, pas le choix de l’outil. Il s’adresse à quelqu’un qui a déjà décidé d’installer un assistant et qui veut que ça tienne en production.
Module ou script : la question n’est pas cosmétique
Beaucoup d’outils proposent un bout de code à coller avant </body>. Sur PrestaShop, c’est un mauvais calcul.
Un script placé dans themes/votre-theme/templates/layouts/layout-both-columns.tpl disparaît à la prochaine mise à jour du thème. Il n’apparaît nulle part dans le back-office, donc personne dans l’équipe ne sait qu’il existe. Le jour où le widget dysfonctionne, il faut un accès FTP pour le couper.
Un module fait l’inverse. Il s’installe depuis le gestionnaire de modules, expose sa configuration dans une interface, et se désactive sans toucher au code. Sa désinstallation retire proprement ses clés de configuration au lieu de laisser des résidus en base.
| Script dans le thème | Module | |
|---|---|---|
| Survit à une mise à jour de thème | Non | Oui |
| Coupure d’urgence | Accès FTP | Un clic |
| Visible par l’équipe | Non | Gestionnaire de modules |
| Configuration | En dur dans le template | Interface dédiée |
| Désinstallation propre | Manuelle | Automatique |
La seule situation où le script se défend, c’est une boutique très fortement personnalisée dont le thème n’est plus mis à jour. Autrement dit, un cas de dette technique, pas un choix d’architecture.
Le bon hook, et pourquoi
PrestaShop expose des dizaines de points d’accroche. Pour un widget de conversation, un seul convient vraiment : displayBeforeBodyClosingTag.
Il place le script juste avant la fermeture du body, donc après que le contenu de la page a été rendu. Le widget ne retarde ni le premier affichage ni le LCP. Les hooks d’en-tête comme displayHeader fonctionnent techniquement, mais ils font charger un script d’interface avant le contenu que le client est venu voir. Sur mobile, la différence se mesure.
Le module doit rester un injecteur, et rien d’autre. Concrètement, il ne devrait contenir :
- aucune information d’identification vers votre catalogue,
- aucune connaissance métier,
- aucun client de conversation,
- aucune requête SQL exécutée pendant le rendu d’une page produit.
Cette discipline a une conséquence pratique agréable : un module aussi mince se relit en dix minutes, ce qui compte le jour où votre prestataire ou votre DSI demande à l’auditer.
Ce que la configuration doit exposer
Un module de widget correctement conçu demande peu de choses, et chacune doit être explicite.
- Un identifiant d’installation, qui relie la boutique à sa configuration côté plateforme.
- Une locale, au format BCP 47 (
fr-FR), pour que l’assistant parle la bonne langue. - Une origine HTTPS explicite pour les assets, sans paramètre ni fragment.
- Un identifiant de version figé, du type
1.0.0.
Le quatrième point est celui qu’on oublie. Épingler la version signifie qu’une mise à jour côté fournisseur ne change pas le comportement de votre boutique sans que vous l’ayez décidé. Si vous devez revenir en arrière, vous modifiez un champ, sans migration ni intervention en base.
La CSP : la panne que personne ne diagnostique
Voici le scénario le plus fréquent. Le module est installé, activé, configuré. Le back-office affiche un état vert. Sur la boutique, rien.
La cause est presque toujours la Content Security Policy. Si l’en-tête Content-Security-Policy de la boutique ne liste pas l’origine du widget dans script-src, le navigateur refuse de charger le fichier et n’affiche aucun avertissement visible pour un non-développeur.
Le diagnostic prend trente secondes. Ouvrez la console du navigateur sur une page produit et cherchez une ligne du type Refused to load the script. Si elle est là, ajoutez l’origine à votre directive script-src et videz les caches.
Un point de prudence pendant que vous y êtes : n’élargissez pas connect-src par précaution. Ouvrez uniquement ce dont le widget a réellement besoin, au moment où il en a besoin. Une directive large « au cas où » est exactement le genre de décision qui ressort mal dans un audit six mois plus tard.
Le cache, deuxième suspect
PrestaShop met en cache les templates Smarty et compile ses assets. Après une installation ou un changement de configuration, la boutique peut continuer à servir l’ancienne version pendant un moment.
Le réflexe : videz le cache depuis Paramètres avancés → Performances, puis rechargez avec le cache navigateur désactivé. Si vous avez un cache HTTP en amont, un Varnish ou un CDN, purgez-le aussi. Beaucoup de « le module ne marche pas » se terminent ici.
Multiboutique : configurez par boutique
Si vous exploitez plusieurs boutiques dans une même installation, ne présumez pas qu’une activation globale suffit. Chaque boutique a son catalogue, souvent sa langue, parfois son thème. L’identifiant d’installation doit donc différer.
Activer un même identifiant partout produit un résultat désagréable : l’assistant répond à un client de la boutique B avec le contexte de la boutique A. Le problème ne se voit pas en recette, où l’on ne teste en général qu’une seule boutique.
Ce qu’il faut mesurer après la mise en ligne
L’installation n’est pas la fin. Trois indicateurs valent le coup d’œil dès la première semaine.
- Le taux de réponse hors périmètre. Un assistant qui répond à tout est un assistant qui invente. Une part de questions déclinées ou escaladées est un bon signe, pas un défaut.
- Les questions sans réponse. Elles pointent les trous de votre catalogue et de vos fiches, souvent bien avant vos outils d’analyse.
- Le poids réel du widget. Mesurez-le sur une page produit, pas sur la page d’accueil. C’est là que vos clients décident.
Ce que ce guide ne couvre pas
L’injection du widget est la partie facile. Ce qui détermine la qualité des réponses, c’est la manière dont l’assistant accède à votre catalogue et ce qu’il a le droit d’en déduire. Un widget parfaitement intégré posé sur un assistant qui ne connaît que vos pages web reste un assistant qui récite.
C’est un sujet à part entière, et nous l’avons traité dans notre article sur le RAG e-commerce.
Chez Selvren, le module PrestaShop suit exactement les principes décrits ici : un injecteur mince, un hook officiel, une version épinglée, aucune information d’identification embarquée. Il est actuellement en pilote accompagné, ce qui veut dire que nous le posons avec vous plutôt que de vous laisser une documentation et un lien de téléchargement.
Questions fréquentes
Faut-il un module ou un simple script pour installer un chatbot sur PrestaShop ?
Un module, dans la quasi-totalité des cas. Le script collé dans un template survit rarement à une mise à jour de thème, et il n’est pas désactivable depuis le back-office. Le module s’accroche à un hook officiel, se coupe en un clic et nettoie sa configuration à la désinstallation.
Quel hook PrestaShop utiliser pour injecter un widget de chat ?
displayBeforeBodyClosingTag. Il place le script juste avant la fermeture du body, donc après le rendu du contenu, ce qui évite de retarder le premier affichage. Les hooks d’en-tête comme displayHeader conviennent mal à un chargement asynchrone.
Pourquoi mon chatbot ne s’affiche pas alors que le module est activé ?
Neuf fois sur dix, la Content Security Policy de la boutique n’autorise pas l’origine du script dans script-src. Le navigateur bloque le chargement sans rien afficher. Le second suspect est le cache Smarty, qui sert encore l’ancien template.
Un chatbot ralentit-il une boutique PrestaShop ?
Pas s’il est chargé en defer depuis une origine distincte, et si le module n’ajoute aucune requête SQL au rendu de page. Le point à surveiller est le poids du bundle du widget lui-même, pas le module qui l’injecte.