cas-prestashop

Cas d’étude — relance d’avis produits PrestaShop

Imaginé par Yohann le 21/09/2026 comme premier service concret, pour des amis ayant une boutique PrestaShop. Réflexion uniquement, rien à mettre en œuvre tant qu’il ne le demande pas.

Le scénario proposé

Chaque jour à 13 h → commandes expédiées il y a 5 jours → mail de demande d’avis → si avis déposé, mail de remerciement ; sinon relance à +5 jours puis à +10 jours.

Pourquoi c’est un bon premier service

• Problème nommé et universel en e-commerce : « je n’ai pas assez d’avis ».
• Gain mesurable : nombre d’avis collectés, et effet direct sur le taux de conversion.
• Client pilote réel et bienveillant, donc retour honnête et droit de citer.
• PrestaShop est une niche homogène : le même workflow se réinstalle presque tel quel sur la boutique suivante. C’est le critère de rentabilité identifié dans projet-freelance-agents-ia §9.

Les trois pièges techniques

1. « Expédiée il y a 5 jours » ne se lit pas sur la commande. date_upd change à chaque modification et ne dit rien de l’expédition. Il faut interroger order_histories et récupérer la date de passage à l’état « Expédié ». Sans ça, le déclencheur est faux dès le premier jour.

2. Savoir si l’avis a été déposé — le vrai point dur. PrestaShop n’a pas d’avis natif. Tout dépend du module installé :

• Product Comments (module officiel) stocke dans la table product_comment, non exposée par le webservice. Il faut donc un accès MySQL direct, ou un petit module qui expose l’information.
• Solution de secours : un lien tracké unique par client. On sait alors qu’il a cliqué, pas qu’il a publié — approximation acceptable pour arrêter les relances.
• Modules tiers (Avis Vérifiés, Trustpilot…) : vérifier s’ils exposent un webhook ou une API, c’est alors la voie la plus propre. → À vérifier en premier sur la boutique concernée : quel module d’avis est installé. Toute la branche conditionnelle en dépend.

3. L’idempotence. Un cron quotidien sans mémoire d’état renvoie les mêmes mails en boucle. Il faut stocker, par commande : quels messages ont été envoyés et quand. Tableur, table dédiée ou base n8n — mais ça ne peut pas être implicite.

Les points juridiques

• Ne jamais trier les clients à relancer. Ne solliciter que ceux qu’on suppose satisfaits est une pratique commerciale trompeuse. On relance tout le monde, ou personne.
• Un mail de demande d’avis après commande relève de la relation client, pas de la prospection : pas de consentement préalable requis, mais lien de désabonnement obligatoire.
• Depuis la directive Omnibus, un marchand qui affiche des avis doit indiquer comment il en vérifie l’authenticité. À signaler au client.

Les réglages à discuter avec le client

• 3 mails pour un avis, c’est beaucoup. Deux suffisent généralement ; au-delà, les plaintes pour spam abîment la délivrabilité de toute la boutique.
• J+5 après expédition ≠ produit reçu. Selon le transporteur, le client peut être relancé avant d’avoir ouvert le colis. J+7 est plus sûr.
• Exclure : commandes remboursées, annulées, en litige ou avec retour en cours. Demander un avis à quelqu’un qui vient de renvoyer son colis est le meilleur moyen d’obtenir une étoile.

Technique d’accès

Webservice PrestaShop activé dans le back-office, clé API avec permissions en lecture sur orders, order_histories, customers, order_details, products. Pas de nœud n8n natif : nœud HTTP Request, authentification basique avec la clé en identifiant et un mot de passe vide.

---

Cas 2 — Liste de préparation des commandes (21/09/2026)

Scénario proposé par Yohann : deux envois par jour, 9 h et 15 h, un mail détaillant les produits à préparer pour les commandes à expédier.

Pourquoi c’est le meilleur candidat pour un premier client

• Lecture seule, zéro risque externe. Aucun mail envoyé à un client final, aucune écriture dans la boutique. Si le workflow se trompe, seul le préparateur le voit. C’est exactement ce qu’il faut pour une première mise en production.
• Visible deux fois par jour. Le client constate le service en permanence — précieux quand on n’a pas encore de réputation.
• Gain mesurable : allers-retours évités dans le stock, erreurs de préparation en moins.

Le point de conception qui fait toute la valeur

Deux formats existent, et le réflexe est de n’en produire qu’un :

1. Agrégé par produit (liste de prélèvement) : « Référence A → 7 unités ». On ramasse tout en un seul passage dans le stock.
2. Détaillé par commande (liste de colisage) : « Commande 1234 → 2× A, 1× B ». On répartit et on emballe.

Le mail doit contenir les deux, dans cet ordre. C’est ainsi que travaillent les vrais entrepôts : une passe de ramassage groupé, puis un tri par commande. Fournir uniquement le détail par commande fait refaire dix fois le tour du stock — c’est le conseil qui justifie la prestation.

Les pièges techniques

1. Les déclinaisons. order_details renvoie un product_attribute_id. S’il n’est pas résolu, la liste affichera « T-shirt » sans la taille ni la couleur — inutilisable en préparation. Piège numéro un, et il est éliminatoire.
2. Quel état déclenche la sélection ? À définir précisément : paiement accepté, pas encore expédié. Attention aux virements et chèques en attente.
3. Éviter le doublon entre 9 h et 15 h. La question à poser au client : « Vos préparateurs passent-ils les commandes en “en cours de préparation” ? »
   • Si oui : on filtre sur l’état, tout reste simple et sans mémoire externe.
   • Si non : on filtre sur la date et l’heure de commande, ou on assume que l’envoi de 15 h ne liste que les nouvelles.
4. Signaler les ruptures dans la liste. Sans ça, le préparateur découvre le problème devant le rayon vide.
5. Format du mail : tableau lisible sur téléphone et imprimable — les listes de préparation s’impriment encore beaucoup.

À inclure dans le mail

Par produit : référence, nom, déclinaison, quantité totale, emplacement si géré. Par commande : numéro, client, transporteur, contenu. En en-tête : nombre de commandes, nombre d’articles, alertes de rupture.

Évolution proposée par Yohann — le workflow bascule lui-même l’état

Après envoi du mail, passer la commande en « en cours de préparation ». L’état PrestaShop devient la mémoire du workflow : pas de doublon à 15 h, et une commande basculée manuellement le matin ne ressort pas l’après-midi.

Bonne intuition architecturale : on s’appuie sur l’état du système source au lieu de tenir un stockage parallèle. Mais trois conséquences à connaître.

1. ⚠️ Le piège majeur : PrestaShop envoie un mail au client à chaque changement d’état. Chaque état a une option « envoyer un e-mail au client », activée par défaut sur plusieurs statuts. Basculer 30 commandes déclenche donc 30 mails vers les clients finaux. Invisible tant qu’on n’a pas testé, et catastrophique en démonstration. → Vérifier send_email sur l’état visé avant toute écriture, et en discuter avec le client : veut-il vraiment prévenir l’acheteur à ce moment-là ? → Le changement d’état crée aussi une ligne dans l’historique, visible par le client dans son suivi de commande.

2. On quitte la lecture seule. L’argument « zéro risque » du cas 2 ne tient plus : le workflow écrit désormais dans la boutique. C’est un arbitrage assumé, pas un détail.

3. L’ordre des opérations devient critique. Basculer l’état uniquement après confirmation d’envoi du mail. Si le mail échoue alors que l’état a déjà changé, la commande est marquée préparée sans que personne n’ait la liste — et elle ne réapparaîtra plus jamais. → Prévoir un garde-fou : signaler les commandes « en cours de préparation » depuis plus de 24 h.

4. Ça impose un processus au client. Si ses préparateurs utilisaient déjà cet état autrement, on casse leur organisation. À valider avant, pas après.

Blueprint livré le 21/09/2026

Fichier : outputs/prestashop-liste-preparation.blueprint.json (généré par outputs/build_blueprint_preparation.py, modifiable et régénérable).

10 nœuds : déclencheur cron 0 9,15 * * 1-5 → Configuration → GET /api/orders → Code d’agrégation → test « des commandes ? » → envoi du mail → test « marquer en préparation ? » → une ligne par commande → POST /api/order_histories. Plus une note explicative dans le canvas, signée, qui sert aussi de carte de visite si le blueprint circule.

Non installé sur le n8n de Yohann : aucune clé d’API n8n n’existe sur le serveur, et les credentials PrestaShop et SMTP doivent de toute façon être saisis à la main. Import manuel = 10 secondes.

Choix de conception

• Le changement d’état est désactivé par défaut (marquer_en_preparation = false) : le premier lancement ne peut pas déclencher d’e-mails vers les clients finaux.
• Il intervient après l’envoi du mail, jamais avant.
• Débit limité à un appel toutes les 400 ms pour ne pas saturer le webservice.
• Le mail contient les deux listes : prélèvement agrégé puis colisage par commande, avec des cases à cocher.
• L’agrégation s’appuie sur product_name des order_rows, qui contient déjà la déclinaison telle que commandée — ce qui règle le piège des tailles et couleurs.

Testé le 21/09/2026 sur données simulées : deux commandes contenant 2 puis 3 unités de la même déclinaison → cumul correct à 5, déclinaison conservée dans la liste.

Reste à vérifier sur la vraie boutique : les identifiants d’état (ils varient d’une boutique à l’autre, voir Commandes > Statuts) et l’option d’envoi d’e-mail du statut « En cours de préparation ».

Voir aussi

• Catalogue n8n TPE
• Plan 90 jours