CRM PrestaShop : connecter votre boutique à votre CRM et à votre ERP

Le scénario est connu des équipes e-commerce. Un client commande un article affiché « en stock » sur la boutique, il paie, et le lendemain l’entrepôt découvre que la dernière pièce est partie la veille sur un autre canal. Le commercial ne voit rien passer dans le CRM, et la comptabilité ressaisit la commande dans l’ERP à partir d’un export. Trois outils, trois versions de la même vente.

La réponse réflexe consiste à chercher un module qui « synchronise tout ». C’est rarement le bon point de départ. Une connexion ne fait que recopier ce qu’on lui donne : si personne n’a décidé quel outil a raison quand deux se contredisent, elle recopie les erreurs plus vite. Ce guide part donc des données, puis du trajet d’une commande, et seulement ensuite du choix technique.

CRM PrestaShop : ce qui doit circuler

PrestaShop est d’abord une boutique : un catalogue, un panier, un paiement, des comptes clients et un historique de commandes. Elle suit aussi des stocks et édite des factures, mais ce n’est ni un CRM, qui suit la relation commerciale, ni un ERP, qui tient les achats, les stocks de tous les canaux et la facturation de l’entreprise. La fiche PrestaShop de notre répertoire d’outils présente la solution elle-même ; la question ici est ce qui doit passer entre elle et le reste de votre système d’information.

Les cinq données qui passent entre la boutique, le CRM et l’ERP

• Le client. Nom, e-mail, adresses de livraison et de facturation, consentements, et pour un professionnel la raison sociale et le SIREN.
• Le produit et son prix. Références, déclinaisons, prix public, et prix négociés pour certains comptes.
• Le stock. Quantité disponible à la vente, quantité réservée par les commandes en cours, quantité réellement en entrepôt.
• La commande. Lignes, montants, mode de paiement, transporteur, et surtout son statut, qui change plusieurs fois après le paiement.
• La facture et ses suites. Facture, avoir, remboursement, statut de livraison.

Ce que coûte une connexion absente

Sans connexion, chaque donnée voyage à la main. Quelqu’un exporte les commandes du jour en CSV, les reprend dans l’ERP, corrige les fautes de frappe, puis met à jour le stock de la boutique quand il en a le temps. Les effets sont toujours les mêmes : des articles vendus alors qu’ils ne sont plus disponibles, des factures émises avec un jour ou deux de décalage, des clients créés en double parce que l’e-mail saisi sur la boutique n’est pas celui que connaît le commercial. Additionnés, ces incidents occupent l’équipe à réconcilier des outils au lieu de servir des clients.

Qui fait foi pour chaque donnée

Avant tout choix technique, tracez une carte simple : pour chaque donnée, quel système est maître, c’est-à-dire le seul autorisé à la créer et à la modifier, et quels systèmes la lisent. Personne ne la prend spontanément : elle touche à la fois l’e-commerce, le commerce et la finance.

Le client : la boutique le crée, le CRM le reconnaît

Un client particulier naît le plus souvent sur la boutique, au moment où il crée son compte ou passe sa première commande. Le CRM ne doit pas le recréer à l’aveugle : il doit d’abord chercher s’il le connaît déjà, par l’e-mail ou, pour une entreprise, par le SIREN. Pour un client professionnel suivi par un commercial, c’est souvent l’inverse : le compte est ouvert dans le CRM ou l’ERP, puis transmis à la boutique avec ses conditions.

Le produit, le prix et le stock : l’ERP décide le plus souvent

Dès qu’une entreprise gère des achats, plusieurs entrepôts ou d’autres canaux de vente, l’ERP tient les références, les prix de base et les quantités. La boutique les affiche ; elle ne les invente pas. Exception fréquente : descriptions et photos, enrichies directement dans PrestaShop. Le maître peut donc changer selon le champ, pas seulement selon l’objet, et c’est précisément ce qu’il faut écrire noir sur blanc.

La commande et la facture : un aller dans un sens, des statuts dans l’autre

La commande naît sur la boutique et part vers l’ERP, qui la prépare et la facture. Les statuts font le chemin inverse : expédiée, livrée, retournée, remboursée. Le CRM, lui, lit l’ensemble pour donner au commercial et au service client l’historique complet. La relation entre l’ERP et le CRM obéit aux mêmes principes : un sens de circulation par donnée, et un seul système qui écrit.

Le trajet d’une commande, de la boutique à la facture

Pour vérifier que la carte tient, suivez une commande réelle de bout en bout. Prenons la commande n° 10482 d’ACME France, exemple fictif : un panier validé un vendredi soir, un article en rupture le lundi matin, un retour partiel dix jours plus tard. Chaque étape peut perdre la donnée.

Rapprocher le client avant de créer une fiche

Le premier point de rupture arrive dès la réception de la commande. Si la connexion crée systématiquement un nouveau contact dans le CRM, chaque client qui commande avec une autre adresse e-mail devient un doublon. La règle doit prévoir l’ordre de recherche — e-mail, puis SIREN ou nom de société — et le traitement des cas ambigus, mis de côté pour une personne plutôt que créés d’office. Si vos bases en contiennent déjà, l’article sur les doublons entre CRM et ERP explique comment les corriger sans tout recréer.

Statuts, retours et avoirs : les flux qu’on oublie

Les projets décrivent volontiers la création de la commande et oublient la suite. Une commande annulée après paiement, un retour partiel, un avoir émis par la comptabilité : si ces événements ne circulent pas, la boutique affiche un stock faux, le CRM attribue au client un chiffre d’affaires qu’il n’a pas fait, et le service client répond sans savoir que le remboursement est parti. Listez les statuts PrestaShop que vous utilisez réellement, et faites correspondre chacun à un état de l’ERP.

Les clients professionnels : tarifs, comptes et conditions de paiement

Une boutique qui vend aussi à des professionnels ajoute une couche de règles : tarifs par groupe de clients, remises négociées, paiement à terme, encours autorisé, adresses de livraison multiples pour un même compte. Ces règles vivent en général dans l’ERP ou dans le CRM. La connexion doit les transmettre à la boutique, et vérifier au passage qu’un compte bloqué pour impayé ne peut plus commander à terme.

Une connexion ne corrige pas une règle absente : elle l’applique plus vite, y compris quand elle est fausse.

Module, Make ou connecteur dédié

Une fois la carte des données écrite, le choix devient plus simple. Trois familles coexistent, aucune n’est meilleure dans l’absolu, et elles se comparent sur les mêmes critères : les règles métier qu’elles savent porter, le volume qu’elles absorbent, la visibilité qu’elles donnent sur les erreurs, et l’effort de maintenance à chaque mise à jour.

Quand un module du marché suffit

Des modules et des connecteurs du marché relient PrestaShop à de nombreux CRM et ERP, par exemple HubSpot ou Odoo. Ils conviennent quand vos règles sont proches de celles prévues par l’éditeur du module : un seul catalogue, peu de statuts, pas de tarifs négociés. Avant d’en installer un, vérifiez trois choses : ce qu’il fait quand un envoi échoue, s’il sait rapprocher un client existant au lieu d’en créer un nouveau, et qui le maintient lors des mises à jour de PrestaShop.

Quand une plateforme d’automatisation est le bon choix

Une plateforme comme Make permet de décrire les flux scénario par scénario : à chaque nouvelle commande, chercher le client, le créer s’il n’existe pas, créer la commande dans l’ERP, renvoyer le statut. Elle convient quand les règles dépassent ce qu’un module propose, sans justifier un développement. Son avantage principal est la lisibilité : chaque exécution apparaît dans l’historique du scénario avec son statut, et une exécution en erreur peut être conservée puis relancée, à condition d’activer cette option dans les réglages du scénario. Le comparatif Zapier et Make détaille les différences entre les deux outils.

Quand il faut un connecteur dédié

Quand les volumes sont élevés, que les règles métier sont nombreuses ou que plusieurs systèmes s’ajoutent à la boutique — logistique, places de marché —, un connecteur écrit pour votre cas devient plus sûr qu’un empilement de scénarios. Il s’appuie sur les interfaces de programmation de chaque outil, dont le webservice de PrestaShop. Il demande en contrepartie une documentation et un responsable identifié, faute de quoi il devient une boîte noire que plus personne n’ose modifier. La checklist technique d’intégration CRM recense les points à cadrer avant de lancer ce type de chantier.

Le cas des boutiques PrestaShop 1.6 et des modules spécifiques

PrestaShop 1.6 n’est plus maintenue depuis juin 2019 et ne reçoit plus de mises à jour de sécurité, rappelle le projet PrestaShop. Certaines boutiques restées sur cette version ont été fortement modifiées pour coller à leur fonctionnement, ce qui rend leur migration difficile. La compatibilité d’un connecteur dépend de la version : certains existent en éditions distinctes pour PrestaShop 1.6 et 1.7, et chaque module spécifique peut modifier la façon dont une commande ou un client est enregistré. Connecter une boutique 1.6 à un ERP reste possible, mais la recette doit être plus large : tester les commandes passées par chaque module, et décider si la connexion se construit avant ou après une montée de version.

Ce qu’a fait Café Joyeux

Chez Café Joyeux, Salesforce et la boutique PrestaShop ne communiquaient pas efficacement, et une partie des données était gérée dans des fichiers Excel. Le projet a consisté à passer de Salesforce à HubSpot en reprenant les données, à connecter le CRM à PrestaShop et à mettre en place avec Make une transmission bidirectionnelle des flux. Le processus de commande a été automatisé depuis le CRM, et des tableaux de bord permettent désormais de piloter l’activité.

On y retrouve les éléments décrits plus haut : des données reprises, des flux qui circulent dans les deux sens, puis des indicateurs pour piloter.

Faire durer la connexion

Une connexion qui fonctionne le jour de sa mise en service n’est pas terminée. La boutique évolue, le CRM aussi, les modules se mettent à jour, et un flux peut s’arrêter sans que personne ne s’en aperçoive pendant des jours.

Un journal des erreurs que quelqu’un lit

Chaque envoi raté doit laisser une trace lisible : quelle commande, quel client, quel message d’erreur. Ce journal n’a de valeur que s’il a un destinataire nommé, qui le consulte à un rythme défini et sait rejouer un envoi une fois la cause corrigée.

Une recette à chaque mise à jour de la boutique ou du CRM

Gardez une courte liste de commandes de test qui couvrent vos cas réels : un nouveau client, un client existant sous un autre e-mail, un client professionnel avec ses conditions, une annulation, un retour partiel. Rejouez-la à chaque mise à jour de PrestaShop, de ses modules ou du CRM. C’est la façon la plus économique de détecter une rupture avant vos clients.

Par où commencer : un état des lieux court de vos données clients, produits et commandes, et de la façon dont elles passent aujourd’hui d’un outil à l’autre. Le diagnostic en tête d’article vous en donne une première carte ; nos offres CRM et ERP détaillent la suite.