Brevo PrestaShop : intégration, limites et QA du module

Le module Brevo pour PrestaShop s'installe en quelques minutes. C'est précisément ce qui pose problème : la vitesse d'installation donne l'illusion que la donnée est là, alors que la synchronisation initiale laisse volontairement une grande partie de la base client de côté. En agence, la moitié des dossiers PrestaShop qu'on récupère tournent avec une base amputée et un panier abandonné qui ne se déclenche jamais, sans que personne ait vu passer une erreur.

Cet article couvre le setup dans l'ordre où il doit être fait, les limites documentées par Brevo (avec les liens vers la doc pour chacune), et la recette à passer avant d'activer le premier scénario. Si vous cherchez plutôt le paramétrage général du compte, la checklist de mise en place Brevo traite la partie amont.

Ce que fait réellement le module

Le module Brevo pour PrestaShop couvre quatre briques distinctes, et il est utile de les séparer mentalement dès le départ parce qu'elles n'ont ni les mêmes prérequis ni les mêmes limites :

• La synchronisation des contacts : remontée des inscrits vers une liste Brevo, avec les attributs standards.
• La synchronisation e-commerce : commandes, attributs d'achat, données de comportement.
• Le tracker : le script déposé sur le site, qui alimente les apps Automations, Segments et Conversations. Brevo précise que le tracker connecte ces apps à votre site, et que PrestaShop fait partie des plateformes pour lesquelles un plugin l'installe pour vous (doc Brevo).
• L'envoi via SMTP Brevo : les emails transactionnels de la boutique routés par Brevo au lieu du serveur mail par défaut.

Vous pouvez activer les quatre, ou seulement les deux premières. Beaucoup de marques activent tout d'un coup le premier jour, puis passent trois semaines à débugger sans savoir quelle brique casse. Activez dans cet ordre, en validant chaque étape.

Prérequis techniques à vérifier avant l'installation

Deux points sont chiffrés dans la documentation officielle, et ce sont les seuls qui méritent une vérification en amont.

Ces deux exigences figurent sur la page d'aide du module Brevo pour PrestaShop, qui indique "compatible with PrestaShop 1.7.1 or higher (tested up to 9.0)" et "Check that your server uses PHP 7.3 or higher."

Attention à la nuance sur PrestaShop 9 : "testé jusqu'à 9.0" n'est pas la même chose qu'un support officiel garanti sur cette branche. Si vous êtes sur une 9.x, prévoyez une recette plus longue et un environnement de préproduction avant de basculer la boutique de production.

Le numéro de version exact du module bouge à chaque release. Vérifiez-le sur la page d'aide au moment de votre installation plutôt que de vous fier à un article de blog, y compris celui-ci.

Limite numéro 1 : la synchronisation initiale ne remonte pas toute votre base

C'est le point qui coûte le plus cher en pratique, et celui qui passe le plus inaperçu.

Lors de la première synchronisation, Brevo n'importe que deux populations : les contacts inscrits à la newsletter via le footer par défaut de PrestaShop, et les contacts ayant créé un compte PrestaShop en acceptant de recevoir vos newsletters (source).

Traduction opérationnelle : si votre collecte d'emails passe par un pop-up tiers, un formulaire custom en page produit, un module d'inscription remplacé par le thème, ou une case à cocher maison au checkout, ces contacts ne sont pas dans le périmètre de la synchronisation initiale. Ils existent dans votre base PrestaShop. Ils n'arrivent pas dans Brevo.

Ce qu'il faut faire avant l'installation :

1. Inventorier les points de collecte. Listez tous les endroits où un email peut entrer dans la base. Footer natif, création de compte, pop-up, landing, checkout, import manuel, jeu concours.
2. Qualifier le statut de consentement de chacun. Vous aurez besoin de savoir, pour chaque source, si l'opt-in marketing est tracé et daté. Notre article sur la checklist RGPD email marketing détaille ce que vous devez pouvoir prouver.
3. Prévoir un import complémentaire. Les populations hors périmètre devront être exportées de PrestaShop puis importées manuellement dans Brevo, avec leur statut de consentement. Ne mélangez pas cet import avec la liste de synchronisation automatique : gardez-les séparés, vous devrez pouvoir isoler une source si un problème de délivrabilité apparaît.

Un import massif de contacts jamais sollicités depuis longtemps est le meilleur moyen de dégrader vos taux dès la première campagne. Si votre base a du volume dormant, passez par une séquence de nettoyage avant. La méthode est dans Réduire le taux de désabonnement email et dans nos articles sur les flows de winback.

Limite numéro 2 : l'historique de commandes ne remonte pas

Deuxième piège structurel. La documentation est explicite : seules les commandes des contacts ajoutés après la connexion du module sont synchronisées, et l'historique d'achat passé des clients existants n'est pas importé (source).

Ça a trois conséquences directes sur votre plan CRM :

• Pas de segmentation RFM immédiate. Récence, fréquence et montant se construisent sur l'historique. Sans historique, vos segments sont vides le jour J. La méthode RFM reste valable, mais son application dans Brevo démarre à partir de la date de connexion du module.
• Pas de segment VIP au lancement. Vos meilleurs clients ne sont pas identifiables côté Brevo tant qu'ils n'ont pas recommandé.
• Pas de calcul de valeur client exploitable. Le calcul de LTV par abonné demande une profondeur d'historique que le module ne vous donnera pas.

La parade : exporter l'historique de commandes depuis PrestaShop et l'injecter comme attributs de contact au moment de l'import complémentaire. Vous perdez la granularité commande par commande, mais vous récupérez de quoi construire des segments de base (nombre de commandes passées, date de dernière commande, montant cumulé). C'est un travail de préparation de fichier, pas une manipulation dans l'interface.

Point à ne pas rater : ce chantier doit être fait avant d'écrire vos scénarios. Sinon vous concevez des automatisations qui reposent sur une donnée absente.

Limite numéro 3 : champs personnalisés, sens de synchronisation, multiboutique

Trois contraintes plus discrètes, toutes documentées sur la même page d'aide, toutes capables de faire échouer un scénario en silence.

Les champs personnalisés PrestaShop ne remontent pas. Seuls les attributs de contact standards sont synchronisés de PrestaShop vers Brevo ; les champs custom ne peuvent pas être transmis. Si votre segmentation repose sur un champ maison (type de licence, taille d'animal, catégorie professionnelle), il faudra le pousser autrement : import de fichier, ou intégration API dédiée.

La synchronisation des contacts est unidirectionnelle. Les attributs et données de contact vont de PrestaShop vers Brevo uniquement ; les modifications faites dans Brevo ne sont pas renvoyées vers PrestaShop. Conséquence pratique : votre boutique et votre outil CRM peuvent diverger. Décidez dès le départ quel système fait autorité sur quelle donnée, et écrivez-le. Un désabonnement enregistré dans Brevo ne se reflète pas mécaniquement côté boutique.

En multiboutique, le bloc produits ne tire que la première boutique connectée. Quand plusieurs boutiques sont connectées, le bloc produits dans les emails ne remonte que les produits de la première boutique ajoutée. Si vous opérez trois boutiques PrestaShop sur une même instance, vos emails afficheront les produits d'une seule. Testez ce point spécifiquement avant de lancer une campagne multiboutique.

Toutes ces limites viennent de la page d'aide du module.

Transactionnel et SMS : ce que le module ne fera pas

Le périmètre transactionnel est plus étroit que ce que beaucoup imaginent.

Les emails de confirmation de commande natifs de PrestaShop ne peuvent pas être remplacés par un scénario d'automatisation Brevo. La doc le dit directement : les emails de confirmation de commande ne peuvent pas être déclenchés via les workflows d'automatisation Brevo en remplacement des emails natifs de PrestaShop. Vous pouvez router les emails transactionnels de la boutique via le SMTP Brevo, ce qui suppose que votre compte SMTP Brevo soit activé, mais le déclenchement reste géré par PrestaShop.

Le module ne couvre que le SMS marketing. Les campagnes SMS marketing sont supportées ; les SMS transactionnels, comme une confirmation de commande, ne peuvent pas être envoyés via le module. Si votre projet inclut du SMS d'expédition ou de livraison, il passera par une autre voie. La distinction entre les deux régimes, y compris côté conformité, est traitée dans SMS transactionnel vs SMS marketing.

Ces deux limites orientent l'architecture : PrestaShop reste le moteur du transactionnel de commande, Brevo prend le marketing et le lifecycle. Ne cherchez pas à tout centraliser côté Brevo, la doc ferme la porte.

Le tracker et les événements : la condition du panier abandonné

Le scénario panier abandonné est la première automatisation que tout le monde veut lancer. Il a des prérequis précis.

Brevo indique que le scénario repose sur le déclencheur nommé "Cart updated", et qu'il faut avoir installé le tracker Brevo sur le site plus avoir configuré les trois événements d'achat : cart_updated, cart_deleted, order_completed (doc panier abandonné).

Sur PrestaShop, le plugin installe le tracker pour vous. Reste à vérifier que les trois événements remontent réellement, et c'est là que la recette compte : un scénario configuré sur un événement qui n'arrive jamais ne produit aucune erreur visible. Il ne se déclenche simplement pas.

Un point à connaître sur l'activation : si la fonctionnalité Ecommerce Attribute Synchronization est déjà activée, le Behavior tracking est activé automatiquement (source). Utile à savoir quand vous cherchez pourquoi un réglage semble déjà coché.

Sur le timing de la séquence de relance, méfiez-vous des chiffres qui circulent. Les délais recommandés relèvent du conseil éditorial, pas d'une contrainte produit : à vous de les tester sur votre base. La logique de construction d'une séquence d'abandon multi-scénarios est détaillée dans Flow abandon Klaviyo, et le raisonnement se transpose sans difficulté.

Retour en stock : PrestaShop est dans le périmètre supporté

Bonne nouvelle pour les boutiques à catalogue tendu. Brevo précise que les alertes de retour en stock sont actuellement supportées pour Shopify, WooCommerce, Shopware 6, PrestaShop et les intégrations API (doc back in stock).

C'est un des scénarios avec le meilleur rapport effort/revenu sur une marque qui subit des ruptures régulières : l'intention d'achat est déjà exprimée, le message est purement informatif, et la pression commerciale est nulle. Mettez-le dans votre premier lot de scénarios, juste après le panier abandonné et le welcome.

La checklist de recette avant de lancer

Voilà la QA qu'on passe systématiquement avant de valider une intégration PrestaShop. Elle se fait avec un compte de test et une vraie commande à un euro.

Bloc contacts

• Une inscription via le footer natif crée bien un contact dans la liste Brevo attendue.
• Une création de compte avec case newsletter cochée crée bien un contact.
• Une création de compte sans case cochée ne crée pas de contact marketing.
• Les attributs standards attendus sont bien remplis sur le contact de test (pas de champ vide inexpliqué).
• Les contacts hors périmètre (pop-up, formulaire custom) sont identifiés et un plan d'import existe.

Bloc commandes et e-commerce

• Une commande test passée par un contact synchronisé remonte dans Brevo.
• Le contact de test porte bien les attributs d'achat après la commande.
• Vous avez acté par écrit que l'historique antérieur n'est pas là, et vous savez comment vous le comblez.

Bloc tracker et événements

• Le tracker est présent sur les pages du site (vérification dans le code source ou l'inspecteur réseau).
• cart_updated remonte quand vous ajoutez un produit au panier.
• cart_deleted remonte quand vous videz le panier.
• order_completed remonte à la validation de commande.
• Le scénario panier abandonné se déclenche sur le contact de test, et pas sur un contact qui a finalisé.

Bloc emails et rendu

• Le SMTP Brevo est activé si vous routez les transactionnels de la boutique par Brevo.
• Les emails de confirmation natifs PrestaShop partent toujours et arrivent.
• En multiboutique, vous avez vérifié quelle boutique alimente le bloc produits.
• Le rendu est contrôlé sur les principaux clients mail, dark mode inclus (guide dark mode).

Bloc délivrabilité

• L'authentification du domaine est en place avant le premier envoi de volume. Les réglages spécifiques à Brevo sont dans Délivrabilité Brevo : 7 réglages essentiels.
• La montée en volume est progressive, pas un envoi global le premier jour.

Cette recette prend une demi-journée. C'est moins cher qu'un mois de flows qui ne tournent pas.

Ordre de déploiement recommandé

Pour une boutique PrestaShop qui démarre sur Brevo, l'ordre qui limite le nombre d'allers-retours :

1. Vérification des prérequis techniques (versions PrestaShop et PHP).
2. Installation et connexion du module sur un environnement de test.
3. Recette contacts, avec inventaire des points de collecte hors périmètre.
4. Import complémentaire des populations manquantes, avec statut de consentement, dans une liste séparée.
5. Activation de la synchronisation e-commerce et vérification du tracker et des trois événements.
6. Authentification du domaine et réglages de délivrabilité.
7. Premier lot de scénarios : welcome, panier abandonné, retour en stock.
8. Deuxième lot une fois que l'historique de commandes s'est reconstitué : post-achat, réactivation, segmentation par valeur.

Si vous voulez comparer l'ergonomie du moteur d'automatisation avant de vous engager sur la roadmap de scénarios, Brevo Automation détaille le nouvel éditeur. Et si vous hésitez encore entre plateformes pour une marque DTC en croissance, Brevo vs Klaviyo pose les critères de décision.

Sur les prix, les quotas et les unités de facturation : ces informations ne sont pas exploitables depuis la documentation que nous avons ouverte pour cet article. Consultez la page tarifaire officielle de Brevo avant de valider un budget, et rapprochez-la de votre volume d'envoi réel plutôt que de votre nombre de contacts.

Besoin d'un audit ou d'un déploiement encadré sur cette stack ? C'est le quotidien de notre agence Brevo.

FAQ

Le module Brevo est-il compatible avec PrestaShop 9 ?

La documentation Brevo indique une compatibilité à partir de PrestaShop 1.7.1, testée jusqu'à la 9.0. "Testé jusqu'à" n'équivaut pas à un support officiel garanti : sur une branche 9.x, installez d'abord sur un environnement de préproduction et passez une recette complète avant la production.

Est-ce que toute ma base client PrestaShop va remonter dans Brevo ?

Non. La synchronisation initiale ne prend que les contacts inscrits via le footer par défaut de PrestaShop et ceux ayant créé un compte en acceptant les newsletters. Toute autre source de collecte devra faire l'objet d'un import manuel, avec son statut de consentement.

Puis-je remplacer les emails de confirmation de commande PrestaShop par un scénario Brevo ?

Non. La documentation précise que les emails de confirmation de commande ne peuvent pas être déclenchés via les workflows Brevo en remplacement des emails natifs PrestaShop. Vous pouvez en revanche router les emails transactionnels de la boutique via le SMTP Brevo, à condition que votre compte SMTP soit activé.

Pourquoi mon scénario panier abandonné ne se déclenche pas ?

Le scénario repose sur le déclencheur "Cart updated" et exige le tracker Brevo installé plus les trois événements d'achat : cart_updated, cart_deleted, order_completed. Si un seul de ces événements ne remonte pas, le scénario reste silencieux sans message d'erreur. Vérifiez les trois un par un avec une commande de test.

Mes champs personnalisés PrestaShop seront-ils utilisables pour segmenter dans Brevo ?

Pas via le module. Seuls les attributs de contact standards sont synchronisés ; les champs personnalisés ne sont pas transmis. Il faut passer par un import de fichier ou une intégration API pour les rendre disponibles à la segmentation.