# DataFirefly
> Modules e-commerce premium pour PrestaShop, WooCommerce et Shopware — performance, conversion, AEO.
DataFirefly développe et publie des modules e-commerce premium pour PrestaShop 8 / 9, WooCommerce et Shopware 6.7+. Notre catalogue couvre les briques essentielles d'un site marchand professionnel : checkout & paiement, abonnements, retours produits, marketing & SEO, productivité administrative, et expérience client.
Chaque module est conçu pour être multishop et multilingue, compatible avec les versions LTS de la plateforme cible, livré avec une documentation complète et un changelog public. Le code est maintenu activement, sans dépendance Composer cachée ni framework propriétaire — uniquement les conventions natives de chaque plateforme (Symfony pour PrestaShop, hooks WordPress pour WooCommerce, plugin manifest pour Shopware).
Nous proposons également des prestations de développement sur mesure, d'audit performance et SEO/AEO, ainsi que des hubs d'expertise dédiés (Développeur PrestaShop, Développeur de modules WordPress, Consultant Shopware, Agence e-commerce).
Édité par DataFirefly Limited (Irlande). Support technique en français, anglais et espagnol.
## Stack & expertise technique
**Plateformes maîtrisées** : PrestaShop 1.7 → 9.0, WooCommerce 8 → 10, Shopware 6.6 → 6.7, WordPress 6.6+.
**Stack backend** : PHP 8.1+ (8.3 recommandé), Symfony 6/7, Doctrine ORM, MySQL 8 / MariaDB 11.4 LTS, OpenSearch 2.19+ pour les catalogues volumineux.
**Stack frontend** : Twig, Vue.js 3, React (Shopware admin), Tailwind, Smarty (PrestaShop legacy).
**Conventions de développement** : multishop natif, multilingue Polylang Pro / Symfony Translator, conformité RGPD, hooks Symfony grid (PrestaShop 8+), plugin manifest avec services.xml explicite (Shopware), PSR-4 autoloading, tests unitaires PHPUnit.
**Infrastructure & CI/CD** : Docker Compose, FrankenPHP, Traefik, GitHub Actions avec builds sélectifs par dossier modifié, déploiements via SSH/Git, Hetzner VPS pour la production, o2switch pour les sites WordPress.
**Outils LLM/AEO** : génération automatique de fichiers llms.txt et llms-full.txt (ce plugin), Schema.org JSON-LD, optimisation pour ChatGPT, Claude, Perplexity, Google AI Overviews et Apple Intelligence.
## FAQ
### Sur quelles plateformes les modules DataFirefly fonctionnent-ils ?
Notre catalogue couvre PrestaShop (versions 1.7 à 9.0), WooCommerce (versions 8 à 10) et Shopware 6 (versions 6.6 et 6.7+). Chaque fiche produit indique précisément la matrice de compatibilité, la version PHP minimale requise, et les éventuelles dépendances avec d'autres modules. Tous nos modules sont multishop et multilingue compatibles dès lors que la plateforme cible le permet nativement.
### Quelles versions de PHP sont requises ?
Notre catalogue couvre PrestaShop (versions 1.7 à 9.0), WooCommerce (versions 8 à 10) et Shopware 6 (versions 6.6 et 6.7+). Chaque fiche produit indique précisément la matrice de compatibilité, la version PHP minimale requise, et les éventuelles dépendances avec d'autres modules. Tous nos modules sont multishop et multilingue compatibles dès lors que la plateforme cible le permet nativement.
### Vos modules sont-ils compatibles multishop et multilingue ?
Oui. Sur PrestaShop, tous nos modules respectent la couche multishop native (configuration par boutique, stockage en table _shop). Sur WordPress/WooCommerce, ils sont compatibles Polylang Pro et WPML pour les chaînes traduisibles. Sur Shopware, ils utilisent le système de Sales Channels et les translation snippets natifs.
### Comment se passent les mises à jour des modules ?
Chaque module bénéficie d'un an de mises à jour gratuites incluses dans l'achat. Les nouvelles versions sont publiées sur votre espace client datafirefly.com et installables via le ZIP standard de la plateforme cible. Le changelog est public et accessible directement depuis la fiche produit. Au-delà de la première année, l'extension de mise à jour est proposée à tarif préférentiel.
### Comment obtenir un support technique ?
Le support technique est inclus pendant un an avec chaque module. Vous pouvez ouvrir un ticket depuis votre espace client, ou nous écrire directement par email. Notre équipe répond en français, anglais et espagnol, du lundi au vendredi en jours ouvrés. Le SLA habituel est de 24 à 48 heures ouvrées pour une première réponse.
### Proposez-vous du développement sur mesure ?
Oui. Au-delà du catalogue de modules, DataFirefly propose des prestations de développement sur mesure : modules spécifiques, intégrations ERP/CRM (Fastmag, Sage, HubSpot, Apollo, Brevo), refonte de checkout, optimisations Core Web Vitals, audits SEO/AEO, et migrations entre plateformes (PS → Shopware, WC → PS, etc.). Voir nos hubs d'expertise pour le détail des services et grilles tarifaires indicatives.
### Vos modules sont-ils conformes RGPD ?
Oui. Aucun de nos modules ne transmet de données personnelles à des serveurs tiers sans consentement explicite. Les modules qui s'intègrent à des services externes (Stripe, Brevo, Google Tag Manager, etc.) le font uniquement via les SDK officiels de ces services et respectent leurs propres mécanismes de consentement. Une notice de confidentialité dédiée est fournie pour chaque module concerné.
## Pages clés
### A propos
_Source :_
---
### Blog — Conseils e-commerce PrestaShop, WordPress, Shopware
_Source :_
> Tutoriels, guides et retours terrain pour optimiser vos boutiques PrestaShop, WordPress et Shopware 6. Conversion, SEO, Core Web Vitals, IA — une publication par semaine.
---
### Boutique — Modules PrestaShop, WordPress, Shopware
_Source :_
---
### Comparatif des plateformes ecommerce 2026
_Source :_
---
### Conditions Générales du Programme d'Affiliation
_Source :_
> Conditions du programme d'affiliation Datafirefly : commission de 25 % HT, cookie 30 jours, facturation mensuelle, paiement le 20, droit irlandais.
**Datafirefly Limited****Version 1.0 · Effective : 2026-09-01**
Datafirefly Limited, société de droit irlandais (private company limited by shares), immatriculée au Companies Registration Office sous le numéro **810100**, dont le siège social est situé 15A Main Street, Blackrock, Dublin, A94 T8P8, Irlande, ci-après « **Datafirefly** ».
Et toute personne physique ou morale dont la candidature au programme d’affiliation a été acceptée par Datafirefly, ci-après « **l’Affilié** ».
L’acceptation des présentes conditions lors de la candidature forme le contrat entre les parties. Aucune autre stipulation, aucun document commercial et aucune page du site ne prévaut sur le présent texte.
---
## 1. Objet
Le programme d’affiliation permet à l’Affilié de promouvoir les produits et services de Datafirefly au moyen d’un lien de suivi personnel, et de percevoir une commission sur les commandes qui lui sont attribuées selon les règles de l’article 4.
Le programme est ouvert sur le site www.datafirefly.com. Il ne couvre aucun autre canal de vente de Datafirefly, ni les prestations sur devis, ni les abonnements négociés de gré à gré, sauf accord écrit.
## 2. Nature de la relation entre les parties
L’Affilié agit en toute indépendance. Il n’est ni salarié, ni mandataire, ni agent commercial, ni associé, ni distributeur, ni représentant de Datafirefly. Il ne dispose d’aucun pouvoir de négocier, de conclure ou d’engager Datafirefly, de quelque manière que ce soit.
Les parties conviennent expressément que la présente relation ne relève pas du statut d’agent commercial et n’ouvre droit à aucune indemnité de cessation, de clientèle, de rupture ou de préavis, quels que soient le volume d’affaires apporté et la durée de la relation.
L’Affilié supporte seul l’ensemble de ses obligations fiscales, sociales et déclaratives dans son pays d’établissement. Il garantit Datafirefly contre toute réclamation d’une administration, d’un organisme social ou d’un tiers fondée sur la qualification de la présente relation.
## 3. Candidature, admission et compte
L’inscription est gratuite et sans engagement de volume. Toute candidature est examinée par Datafirefly, qui l’accepte ou la refuse à sa discrétion, sans obligation de motivation.
L’Affilié communique des informations exactes, complètes et à jour, et notifie toute modification dans un délai de 30 jours, notamment tout changement de statut fiscal, d’adresse, de coordonnées bancaires ou de canal de promotion déclaré.
Le compte est personnel. Il ne peut être cédé, partagé ni exploité pour le compte d’un tiers.
L’accès au versement des commissions est subordonné à un dossier complet au sens de l’article 9.
## 4. Suivi et attribution des commandes
L’attribution repose sur un cookie signé déposé sur le navigateur du visiteur lors du clic sur un lien d’affiliation valide. Sa durée est de **30 jours** à compter du clic.
Le modèle d’attribution est celui du **dernier clic** : lorsqu’un visiteur emprunte successivement les liens de plusieurs affiliés, la commission revient au dernier lien emprunté dans la fenêtre de suivi.
Ne donnent lieu à aucune commission :
1. les commandes passées par l’Affilié lui-même, sous son adresse email ou depuis son compte client, ou par une personne agissant pour son compte ;
2. les commandes pour lesquelles aucun cookie valide n’est présent au moment du paiement, notamment en cas de suppression, de blocage ou d’expiration du cookie, de navigation privée, ou de changement de navigateur ou d’appareil entre le clic et l’achat ;
3. les commandes attribuées à un autre affilié en application de la règle du dernier clic ;
4. les commandes générées en violation de l’article 11 ;
5. les commandes annulées, remboursées, contestées ou impayées, dans les conditions de l’article 8.
L’Affilié reconnaît qu’aucune technologie de suivi n’est exhaustive et renonce à toute réclamation fondée sur une attribution manquante en l’absence de cookie valide enregistré.
## 5. Commission
Le taux de commission est de **25 %** du montant **hors taxes effectivement encaissé** par Datafirefly au titre de la commande.
La taxe sur la valeur ajoutée et toute autre taxe supportée par le client sont exclues de la base de calcul. Les remises, codes promotionnels et avoirs appliqués à la commande en sont déduits. Les produits de Datafirefly étant des logiciels livrés par voie électronique, aucun frais de port n’entre dans le calcul.
Le taux applicable à une commission est celui en vigueur à la date de la commande. Datafirefly peut modifier le taux pour l’avenir, moyennant un préavis de 30 jours notifié par email, sans effet sur les commissions déjà générées.
Les commissions sont exprimées et versées en **euros**.
Une commission est créée au paiement de la commande, au statut « en attente ». Elle passe au statut « approuvée » **45 jours** après la commande, sous réserve que celle-ci demeure finalisée, non annulée et non remboursée. Ce délai couvre la garantie de remboursement de 30 jours accordée aux clients de Datafirefly, ainsi que le temps de traitement d’une demande formée le dernier jour de cette garantie. Il est fixé de manière à ce qu’une commission portée sur un relevé mensuel soit définitivement acquise, et n’ait donc pas à être reprise après paiement.
## 6. Le client est celui de Datafirefly
Datafirefly est seul vendeur et seul cocontractant du client final. Elle conclut la vente, encaisse le prix, exécute la prestation, assure le support et traite les réclamations. L’Affilié n’intervient à aucun de ces stades.
Le client acquis par l’intermédiaire d’un lien d’affiliation **est et demeure le client de Datafirefly**. L’Affilié n’acquiert sur ce client aucun droit, aucune exclusivité, aucun droit de suite, aucune protection territoriale ou sectorielle, et aucun droit de préférence.
L’Affilié n’a accès à aucune donnée personnelle des clients. Son tableau de bord ne présente que des volumes, des montants et des numéros de commande.
La commission est due au titre de la commande attribuée dans la fenêtre de suivi. Les commandes ultérieures du même client ne donnent lieu à aucune commission, sauf nouvelle attribution valide au sens de l’article 4. Aucune commission récurrente n’est due au titre des renouvellements, reconductions ou abonnements souscrits par ce client.
L’Affilié s’interdit de se prévaloir de la clientèle de Datafirefly auprès de tiers, de la démarcher en son nom propre au motif de l’apport initial, de la présenter comme sienne, et de faire état d’une relation autre que celle décrite à l’article 2.
## 7. Cycle mensuel de facturation et de paiement
Le programme fonctionne selon un **cycle mensuel unique**. Aucun paiement n’intervient en dehors de ce cycle.
**7.1 Clôture du mois.** Le premier jour de chaque mois, Datafirefly arrête le compte de l’Affilié. Sont retenues les commissions au statut « approuvée » à cette date et non encore rattachées à un relevé.
**7.2 Seuil de déclenchement.** Si le total arrêté est inférieur à **50 EUR**, aucun relevé n’est émis : le montant est automatiquement reporté sur le mois suivant et se cumule, sans démarche de l’Affilié.
**7.3 Relevé et appel à facturation.** Si le total atteint 50 EUR, Datafirefly émet un **relevé mensuel numéroté** détaillant les commandes retenues, la base de calcul, le taux, le montant total et le régime de TVA applicable. Ce relevé est adressé à l’Affilié par email et mis à disposition dans son tableau de bord, accompagné d’un **appel à facturation** indiquant le montant exact à facturer, les mentions obligatoires à reprendre et les coordonnées de facturation de Datafirefly.
**7.4 Dépôt de la facture.** L’Affilié dépose sa facture au format PDF dans son tableau de bord, au plus tard le **10 du mois**. La facture doit porter le numéro du relevé, être émise à l’ordre de Datafirefly Limited, et présenter un montant strictement identique à celui du relevé. Toute facture non conforme est rejetée avec indication du motif, et peut être redéposée.
**7.5 Paiement.** Datafirefly règle le **20 de chaque mois**, en un virement unique, l’ensemble des factures déposées et validées au 10 du même mois.
Une facture n’est validée que si le dossier de l’Affilié est complet au sens de l’article 9.1 et si son numéro de TVA intracommunautaire a été vérifié, ou sa non-assujettissement déclaré, au sens de l’article 9.2. À défaut, aucun paiement n’est initié : le montant demeure acquis à l’Affilié et est reporté au cycle suivant jusqu’à régularisation.
**7.6 Facture tardive.** Une facture déposée après le 10 est traitée au cycle suivant et payée le 20 du mois suivant. Aucun paiement anticipé, partiel ou hors cycle n’est effectué, pour quelque motif que ce soit.
**7.7 Absence de facture.** À défaut de dépôt, le montant du relevé demeure acquis à l’Affilié et est reporté au relevé du mois suivant, où il se cumule. Datafirefly adresse deux rappels automatiques, puis n’effectue aucune relance ultérieure. Il appartient à l’Affilié de déposer sa facture pour être payé.
**7.8 Comptes dormants.** Au-delà de **douze mois** consécutifs sans dépôt de facture malgré les rappels, le compte est considéré comme dormant. Le solde reste dû, mais son versement suppose la régularisation préalable et complète du dossier au sens de l’article 9.
**7.9 Moyens et frais de paiement.** Les paiements sont effectués par virement SEPA, PayPal ou Wise, en euros, sur un compte dont **le titulaire est l’Affilié lui-même**. Aucun paiement n’est effectué à un tiers. Les frais d’un virement SEPA en euros sont à la charge de Datafirefly. Les frais et écarts de change des autres moyens de paiement sont à la charge de l’Affilié.
**7.10 Suspension du paiement.** Datafirefly peut suspendre un paiement, en informant l’Affilié du motif, en cas de dossier incomplet, de soupçon sérieux de fraude, de manquement aux articles 11 ou 12, ou de litige en cours sur les commandes concernées. Les sommes non contestées sont versées au cycle suivant la levée de la suspension.
## 8. Annulations, remboursements et reprises
Toute commande annulée, remboursée en totalité, contestée par le porteur de carte ou demeurée impayée annule la commission correspondante, que celle-ci soit en attente ou approuvée.
En cas de remboursement partiel, la commission est réduite au prorata du montant effectivement conservé par Datafirefly.
Lorsque l’annulation intervient après le paiement de la commission, Datafirefly impute le montant correspondant sur les commissions à venir. À défaut de commissions suffisantes dans un délai de douze mois, la somme est remboursée par l’Affilié dans les 30 jours d’une demande écrite.
## 9. Dossier de l’Affilié, facturation et TVA
**9.1 Pièces exigées.** Dès l’approbation de sa candidature, l’Affilié reçoit une demande de pièces lui permettant d’ouvrir son dossier de paiement. Avant tout paiement, il fournit et maintient à jour dans son tableau de bord :
1. son identité légale complète, nom et prénom ou raison sociale exacte ;
2. son adresse et son pays d’établissement ;
3. son statut : société, indépendant, ou particulier sans activité professionnelle ;
4. son numéro d’immatriculation au registre compétent, le cas échéant, avec la pièce justificative correspondante ;
5. son numéro de TVA intracommunautaire, ou une déclaration expresse de non-assujettissement ;
6. ses coordonnées bancaires complètes, au nom du titulaire déclaré.
**9.2 Vérification.** Datafirefly vérifie tout numéro de TVA auprès du système VIES de la Commission européenne. Un numéro invalide ou non vérifiable fait obstacle au traitement en autoliquidation et peut suspendre le paiement au sens de l’article 7.10.
**9.3 Mentions de la facture.** La facture de l’Affilié reprend les mentions obligatoires de son pays d’établissement, ainsi que le numéro du relevé mensuel. Selon sa situation :
- Affilié assujetti établi dans un État membre de l’Union européenne autre que l’Irlande : facture sans TVA, portant la mention « **Autoliquidation — article 44 de la directive 2006/112/CE** » ;
- Affilié assujetti établi en Irlande : facture soumise à la TVA irlandaise au taux en vigueur ;
- Affilié établi hors de l’Union européenne : facture sans TVA, prestation hors du champ ;
- Affilié bénéficiant d’un régime de franchise : facture sans TVA, portant la mention correspondante de son pays, par exemple « TVA non applicable, article 293 B du CGI » pour la France.
**9.4 Auto-facturation.** L’Affilié qui ne dispose d’aucun statut professionnel lui permettant d’émettre une facture autorise Datafirefly à établir en son nom et pour son compte le relevé mensuel valant facture. Ce relevé lui est adressé et est réputé accepté à défaut de contestation écrite dans un délai de 15 jours. Dans ce cas, l’Affilié s’engage à ne pas émettre lui-même de facture pour les mêmes sommes.
**9.5 Statut professionnel.** L’Affilié dépourvu de statut professionnel s’engage à en acquérir un dans son pays d’établissement dès lors que le cumul des commissions perçues dépasse **600 EUR sur douze mois glissants**, et à en justifier. À défaut, Datafirefly suspend les paiements jusqu’à régularisation.
## 10. Tableau de bord et contestation
L’Affilié dispose d’un tableau de bord dans son compte client, présentant en continu ses clics, son taux de conversion, ses commissions en attente, approuvées et payées, ses relevés mensuels et l’historique de ses paiements.
Les données du tableau de bord et des relevés de Datafirefly font foi entre les parties. Toute contestation d’un relevé est formulée par écrit à contact@datafirefly.com dans un délai de **30 jours** à compter de sa mise à disposition. Passé ce délai, le relevé est réputé accepté.
## 11. Pratiques interdites
Sont interdits et entraînent l’annulation des commissions concernées, sans préjudice de la résiliation prévue à l’article 15 :
1. les enchères payantes sur la marque « Datafirefly », ses variantes, déclinaisons et fautes de frappe, sur tout moteur de recherche ou régie publicitaire ;
2. l’usage d’un nom de domaine, d’un sous-domaine, d’un profil ou d’une page reprenant la marque de Datafirefly d’une manière laissant croire à un canal officiel ;
3. la diffusion de codes de réduction non émis par Datafirefly, et la publication sur les sites de bons de réduction ou de cashback sans accord écrit préalable ;
4. la prospection non sollicitée, sous toute forme, y compris l’emailing de masse, les messages privés automatisés et les commentaires publiés en série ;
5. le cookie stuffing, la superposition de cookies, les cadres invisibles, les redirections automatiques, les extensions de navigateur et toute technique de dépôt de cookie sans clic délibéré de l’internaute ;
6. l’auto-parrainage, direct ou par personne interposée, et toute attribution artificielle ;
7. la promotion sur des contenus illicites, haineux, trompeurs, pornographiques ou contrefaisants ;
8. toute affirmation inexacte sur les produits, les prix, les fonctionnalités, les performances ou la qualité de partenaire de l’Affilié.
## 12. Transparence publicitaire
L’Affilié indique de manière claire, visible et immédiatement perceptible la nature commerciale de sa recommandation, dans la langue de son audience et conformément aux règles applicables dans son pays.
Une mention équivalente à « lien affilié » ou « contenu rémunéré » figure sur chaque support portant un lien d’affiliation.
Sur un site web, les liens d’affiliation portent l’attribut `rel="sponsored"`, conformément aux règles des moteurs de recherche relatives aux liens rémunérés. L’Affilié qui ne respecte pas cette obligation répond des conséquences subies par Datafirefly, notamment en cas de sanction algorithmique ou manuelle affectant son référencement.
## 13. Marque et supports
Datafirefly concède à l’Affilié, pour la durée du programme, un droit non exclusif, non cessible et révocable d’utiliser sa dénomination, ses marques et ses visuels officiels aux seules fins de promouvoir ses produits et services, dans le respect de sa charte graphique.
Toute modification des visuels, toute association avec une autre marque et tout usage en dehors de cet objet sont soumis à accord écrit préalable. Ce droit cesse de plein droit à la fin de la relation, et l’Affilié retire alors les supports concernés dans un délai de 15 jours.
## 14. Données personnelles
Chaque partie est responsable de traitement pour les traitements qu’elle met en œuvre.
Datafirefly traite les données de l’Affilié aux fins de gestion du programme, de suivi des attributions, de paiement des commissions et de respect de ses obligations comptables et fiscales. Ces données sont conservées pendant la durée de la relation, puis pendant la durée légale de conservation applicable en Irlande.
Aucune donnée personnelle de client final n’est transmise à l’Affilié.
L’Affilié exerce ses droits d’accès, de rectification, d’effacement, de limitation et de portabilité auprès de privacy@datafirefly.com. La politique de confidentialité publiée sur www.datafirefly.com complète le présent article.
## 15. Durée, suspension et résiliation
Le programme est conclu pour une durée indéterminée.
Chacune des parties peut y mettre fin à tout moment, sans préavis, sans indemnité et sans motif, par simple notification écrite adressée à l’autre partie.
Datafirefly peut suspendre immédiatement un compte, le temps des vérifications nécessaires, en cas de soupçon sérieux de fraude ou de manquement aux articles 11 et 12.
À la fin de la relation :
- les commissions approuvées et non contestées restent dues et sont versées selon le cycle de l’article 7, sous réserve du dépôt de la facture correspondante ;
- les commissions en attente suivent leur cours normal et sont approuvées ou annulées selon les règles des articles 5 et 8 ;
- les commissions issues d’une fraude avérée ou d’un manquement à l’article 11 sont annulées ;
- les droits d’usage de marque cessent immédiatement.
## 16. Responsabilité
Datafirefly n’est tenue à aucune garantie de volume, de trafic, de disponibilité du programme ou de niveau de revenu. Elle peut à tout moment modifier son catalogue, ses prix, son site et ses tunnels de commande.
La responsabilité de Datafirefly au titre du programme est limitée au montant des commissions dues et non versées à l’Affilié. Sont exclus les dommages indirects, la perte de chance, le manque à gagner et le préjudice d’image.
## 17. Modification des présentes conditions
Datafirefly peut modifier les présentes conditions. Toute nouvelle version est notifiée par email et publiée avec son numéro de version et sa date d’entrée en vigueur, **30 jours** avant application.
La poursuite de l’activité de promotion après l’entrée en vigueur vaut acceptation. L’Affilié qui refuse la nouvelle version peut mettre fin à sa participation selon l’article 15, ses commissions déjà acquises demeurant dues.
## 18. Stipulations diverses
La nullité d’une stipulation n’affecte pas la validité des autres, qui demeurent applicables.
La tolérance d’un manquement ne vaut pas renonciation à s’en prévaloir ultérieurement.
L’Affilié ne peut céder le présent contrat sans accord écrit de Datafirefly. Datafirefly peut le céder librement dans le cadre d’une réorganisation ou d’une cession de son activité.
## 19. Droit applicable et juridiction
Les présentes conditions sont régies par le **droit irlandais**.
Tout différend relatif à leur validité, leur interprétation ou leur exécution relève de la compétence exclusive des **tribunaux de Dublin**, sous réserve des règles impératives de protection applicables à un Affilié ayant la qualité de consommateur.
**Langue.** Les présentes conditions sont publiées en français et en anglais. En cas de divergence entre les deux versions, **la version anglaise fait foi**.
---
**Datafirefly Limited** · CRO 810100 · 15A Main Street, Blackrock, Dublin, A94 T8P8, Irlande contact@datafirefly.com
---
### Devis site PrestaShop
_Source :_
> Faites chiffrer la création de votre boutique PrestaShop en 30 secondes. L'estimateur ci-dessous construit une fourchette en direct selon votre projet ; le devis détaillé, ferme et poste par poste,…
Faites chiffrer la création de votre boutique PrestaShop en 30 secondes. L'estimateur ci-dessous construit une fourchette en direct selon votre projet ; le devis détaillé, ferme et poste par poste, suit sous 24 h ouvrées. Sans engagement.
Transparence
## Ce que contient un devis de site PrestaShop
Un devis sérieux ne se résume pas à un prix global. Le nôtre détaille chaque poste pour que vous compariez ce qui est comparable :
01**Périmètre fonctionnel**Arborescence catalogue, fiches produit, tunnel de commande, moyens de paiement et de livraison.02**Design**Thème adapté à votre charte ou maquettes sur mesure des écrans clés.03**Développements spécifiques**Modules métier (B2B, RGPD, SEO), connecteurs ERP, configurateur produit.04**Multilingue et multi-devise**Hreflang, taxes par pays, traduction du catalogue.05**Reprise de données**Migration du catalogue, des clients et des commandes depuis votre ancienne plateforme.06**Planning, livrables et maintenance**Délais fermes, 12 mois de mises à jour de compatibilité, propriété complète des sources.Grille de prix du marché
## Combien coûte un site PrestaShop ?
Un site PrestaShop coûte entre **800 € et 15 000 €** en investissement initial, et entre **50 € et 400 € par mois** en coûts récurrents (hébergement, modules, maintenance). L'écart s'explique par trois variables : le prestataire (freelance débutant vs agence), le niveau de personnalisation, et le nombre de modules premium installés. Avant de lancer un **devis site PrestaShop**, mieux vaut connaître ces fourchettes pour ne pas se faire surprendre en cours de projet — c'est justement ce que détaille cette section, poste par poste.
PrestaShop lui-même est un logiciel open source gratuit. Le **prestashop prix** réel se joue donc ailleurs : hébergement, thème, modules, développement et marketing. Voici le détail de chaque poste.
**800 € – 15 000 €**investissement initial**50 € – 400 €/mois**coûts récurrents**5 à 8 modules**minimum pour une boutique fonctionnelle**3 sem. – 6 mois**délai selon la complexité
### Hébergement & nom de domaine
L'hébergement est le seul poste incompressible : sans lui, pas de boutique en ligne. Le **tarif site PrestaShop** varie selon le volume de trafic et de catalogue :
**Mutualisé orienté performance**_Lancement, moins de 500 produits — suffisant pour tester un projet_5 – 15 € HT/mois**VPS configuré**_Boutique établie, trafic régulier — recommandé au-delà de 500 références_20 – 60 € HT/mois**Dédié / cloud managé**_Fort volume, multi-boutique, infogérance comprise_80 – 300 € HT/mois**Nom de domaine**_Souvent offert la première année, puis facturé au renouvellement (.fr, .com, .shop)_10 – 15 € TTC/an**Point de vigilance**
Un hébergement mutualisé bas de gamme (moins de 5 €/mois) tient rarement la charge dès que le trafic dépasse quelques centaines de visiteurs/jour sous PrestaShop, qui reste gourmand en ressources serveur.
### Thème / template
Le thème conditionne à la fois le design et une partie des performances (temps de chargement, compatibilité mobile).
**Thème par défaut PrestaShop**_Gratuit, mais générique et peu différenciant_0 €**Thème premium**_PrestaShop Addons, ThemeForest — licence à vie dans la majorité des cas_84 – 280 €**Installation et configuration du thème**_Prestation ponctuelle par un développeur_50 – 150 €**Thème sur-mesure**_Design unique, maquette Figma dédiée, intégré dans un budget de personnalisation plus large_dès 1 500 €
### Modules : fourchettes de prix
Les modules sont souvent le poste le plus sous-estimé dans un **devis site PrestaShop**. Une boutique fonctionnelle en installe rarement moins de 5 à 8.
**Modules SEO / référencement**30 – 90 €**Modules de paiement**_Hors passerelle bancaire_0 – 150 €**Modules de traduction / multi-langue**40 – 120 €**Modules de logistique et transporteurs**80 – 250 €**Connecteurs ERP / comptabilité**300 – 1 500 €**Modules API avancés**_Marketplace, PIM, synchronisation stock_1 500 – 4 000 €**Budget annuel réaliste**
Comptez 300 € à 2 000 € la première année, puis un budget de renouvellement/maintenance de licences pouvant grimper jusqu'à 7 000 €/an pour une boutique avec des besoins avancés (multi-entrepôts, B2B, abonnements).
### Développement agence / freelance
Le développement est le poste le plus variable, car il dépend directement du profil du prestataire et de son taux journalier moyen (TJM).
ProfilTJM indicatifCoût site completFreelance débutant84 – 140 €800 – 3 000 €Freelance confirmé140 – 210 €3 000 – 8 000 €Agence digitale250 – 450 €/jour équivalent8 000 – 20 000 €Agence e-commerce premium400 €+ /jour équivalent20 000 – 50 000 €+
Quelques repères de prestations ponctuelles observées sur des plateformes comme Codeur.com :
**Audit de boutique existante**≈ 150 €**Migration ou installation SSL**≈ 250 €**Installation complète de PrestaShop**≈ 450 €**Boutique clé en main**_Thème + configuration de base_≈ 900 €**Le bon calcul**
Ne comparez jamais deux devis uniquement sur leur montant total. Comparez le TJM affiché et le nombre de jours estimés — un devis à 3 000 € en 10 jours (300 €/j) n'a pas la même valeur qu'un devis à 3 000 € en 25 jours (120 €/j).
### Personnalisation
La personnalisation regroupe tout ce qui sort du thème et des modules standards : développement spécifique, UX sur-mesure, intégrations tierces.
**Fonctionnalités sur-mesure**_Filtres avancés, configurateur produit, espace B2B_1 500 – 6 000 €**Refonte UX/UI complète avec maquettage**3 000 – 10 000 €**Intégration ERP / CRM sur-mesure**4 000 – 15 000 €
Une boutique avec une expérience utilisateur réellement différenciante mobilise en général un budget de **6 000 € à 15 000 €**, hors hébergement et licences.
### Marketing, SEO, publicité
Un site PrestaShop sans budget marketing reste invisible. Voici les ordres de grandeur les plus courants :
**Audit SEO + optimisation on-page**_Prestation one-shot_500 – 2 000 €**Accompagnement SEO mensuel**400 – 1 500 €/mois**Publicité Google Ads / Meta Ads**_Budget média, hors frais de gestion_dès 300 €/mois**Email marketing / automation**_Klaviyo, Mailchimp — selon la volumétrie_30 – 150 €/mois
Ce poste n'est pas optionnel dans un **prestashop tarif** global réaliste : sans acquisition de trafic, même la meilleure boutique reste sans commande.
### Coûts cachés & délais
C'est ici que la plupart des devis dérapent. Quatre postes sont systématiquement sous-estimés :
**Maintenance et mises à jour de sécurité**_Selon la complexité de la boutique_80 – 400 €/mois**Sauvegardes externalisées et supervision**_En supplément de l'hébergement_4 – 20 €/mois**Licences de modules à renouveler**_Abonnement annuel support + mises à jour_20 – 30 %/an du prix d'achat**Temps de formation à l'administration**_Rarement chiffré, mais à prévoir si l'équipe interne prend la main sur le back-office_à planifier**Délais moyens constatés**
Un planning réaliste dépend directement du niveau de personnalisation :
Boutique simple sur thème premium__**3 – 6 semaines**Projet standard, personnalisation modérée__**6 – 12 semaines**Projet avancé (ERP, multi-langue)__**3 – 6 mois**
En résumé, un **tarif site PrestaShop** ne se résume jamais à la ligne « développement » du devis. Additionnez hébergement, thème, modules, développement, personnalisation et marketing pour obtenir le coût réel du projet — et gardez toujours 10 à 15 % de marge pour les imprévus techniques.
### Et chez DataFirefly ?
Nous ne faisons que du sur-mesure, avec un chiffrage ferme poste par poste. À titre indicatif, selon la taille du catalogue et le niveau de personnalisation :
**Boutique vitrine ou petit catalogue**_Moins de 100 produits, thème adapté_dès 8 000 €**Boutique standard**_Catalogue moyen, design sur mesure_12 000 – 18 000 €**Projet B2B ou multilingue**_Comptes pro, ERP, plusieurs langues_20 000 – 35 000 €**Plateforme complexe**_Marketplace, configurateur, gros volumes_35 000 €+
L'estimateur en haut de page affine cette fourchette selon vos réponses. Pour la méthode et le périmètre complet, voyez notre page [création de site PrestaShop](https://www.datafirefly.com/expertise/creation-site-prestashop/) ; pour un projet entre professionnels, la page [PrestaShop B2B](https://www.datafirefly.com/expertise/prestashop-b2b/).
Méthode
## Comment se déroule la création
1. **Cadrage**Un appel de 20 min pour comprendre le projet, le catalogue et les contraintes métier.
2. **Maquettes et devis fixe**Conception des écrans clés, périmètre clair, prix ferme, délai engageant.
3. **Intégration et développement**Thème, catalogue, modules, tests en environnement de recette.
4. **Mise en production et maintenance**Mise en ligne, formation à l'admin, 12 mois de mises à jour incluses.
## Devis gratuit, sans engagement
L'estimation et le devis détaillé sont gratuits. Vous recevez le chiffrage ferme sous 24 h ouvrées, accompagné d'une proposition de créneau pour l'appel cadrage. Aucun engagement, aucune licence cachée, aucune commission sur vos ventes — vous restez propriétaire de la boutique et de son code.
[Réserver un appel cadrage — 20 min, sans pitch](https://www.datafirefly.com/contact/)FAQ
## Questions fréquentes
### Combien coûte la création d'un site PrestaShop ?
Sur le marché, un site PrestaShop coûte entre 800 € (freelance débutant, thème premium) et 15 000 € et plus (agence, sur-mesure). Chez DataFirefly, une boutique PrestaShop sur mesure démarre à 8 000 €. Le budget final dépend de la taille du catalogue, du design, du multilingue et des fonctionnalités métier (B2B, ERP, configurateur). L'estimateur en haut de page donne une fourchette en direct ; le devis détaillé chiffre chaque poste.
### Le devis est-il gratuit et sans engagement ?
Oui. L'estimation et le devis détaillé sont gratuits et sans engagement. On y ajoute un appel cadrage de 20 minutes pour valider le périmètre avant toute décision.
### Que contient un devis de site PrestaShop ?
Le chiffrage poste par poste (catalogue, thème, paiement, livraison, modules, multilingue), le planning, les livrables, les conditions de maintenance et la propriété complète des sources.
### Sous combien de temps reçoit-on le devis détaillé ?
Sous 24 heures ouvrées après l'envoi du formulaire, accompagné d'une proposition de créneau pour l'appel cadrage.
### Quel délai pour créer la boutique PrestaShop ?
Comptez 6 à 14 semaines selon la taille du catalogue et le volume de développement sur mesure. Un planning ferme est livré avec le devis après le cadrage.
---
### Expertise
_Source :_
---
### IA - Intelligence Artificielle et Automatisation pour e-commerce
_Source :_
> L'IA et l'automatisation ne sont plus des sujets émergents en 2026 — elles font partie du paysage e-commerce standard. La question n'est plus « faut-il s'y mettre ? » mais…
L'IA et l'automatisation ne sont plus des sujets émergents en 2026 — elles font partie du paysage e-commerce standard. La question n'est plus _« faut-il s'y mettre ? »_ mais _« où concentrer l'investissement pour avoir le meilleur retour rapidement ? »_.
Cette page rassemble, plateforme par plateforme, les modules de notre catalogue qui mettent l'IA au travail concrètement — pas en théorie, pas en buzzword, mais dans des cas d'usage qui font gagner du temps ou de l'argent dès la première semaine.
## Trois familles de modules IA & Automatisation
Notre catalogue IA & Automatisation se répartit en trois grands axes fonctionnels :
### Génération et enrichissement de contenu
Modules qui s'appuient sur les API OpenAI, Anthropic ou Mistral pour rédiger automatiquement les descriptions produit, les balises meta SEO, les emails marketing, les réponses aux avis clients. Le gain typique est de **80 % du temps de rédaction** sur un catalogue de plus de 200 références.
### Marketing prédictif et personnalisation
Modules de scoring client, recommandation produit personnalisée, prédiction du churn, pricing dynamique. Ces modules apprennent sur l'historique de votre boutique et tournent en autonomie. Sur une boutique mature, le gain en taux de conversion se mesure typiquement entre 1 et 4 points selon le secteur.
### Automatisation back-office
Modules qui éliminent les tâches répétitives : synchronisation marketplaces, traitement automatique des retours, classification des emails support, génération de rapports. La promesse est moins du chiffre d'affaires que **de la santé mentale d'équipe** — un argument souvent sous-estimé en 2026.
## Spécificités par plateforme
### PrestaShop
L'écosystème IA PrestaShop est en pleine effervescence depuis la sortie de PS 9. Les modules récents s'intègrent nativement dans le BackOffice grâce aux nouveaux hooks Symfony et profitent du moteur d'inférence côté serveur pour offrir des suggestions en temps réel pendant l'édition produit. C'est la plateforme où l'IA pèse le plus lourd dans le catalogue DataFirefly.
### WordPress / WooCommerce
WooCommerce bénéficie de la maturité de l'écosystème WordPress autour des plugins IA — des dizaines d'options matures pour la rédaction, le SEO et la recherche intelligente. Notre catalogue se concentre sur les modules **spécifiquement WooCommerce** (descriptions produit, scoring panier, automation commande) plutôt que sur les généralistes WordPress.
### Shopware 6
Shopware Copilot, intégré nativement depuis 6.7, change la donne. Notre catalogue propose des modules qui **étendent** les capacités natives plutôt que de les remplacer — typiquement de l'IA spécialisée B2B (négociation prix automatique, scoring leads, génération de devis pro forma).
## Combien ça coûte vraiment ?
Au-delà du prix du module (entre 39 € et 299 € selon les cas), il faut compter les **coûts d'inférence API** côté fournisseur IA. Pour une boutique de 500 produits qui génère des descriptions une fois, comptez 5 à 15 € de tokens OpenAI ou Anthropic. Pour de l'automatisation continue (réponse aux avis, support, scoring), le coût récurrent est en général de 20 à 80 € / mois — souvent dérisoire face au temps économisé.
## IA générative vs. agentic commerce
Les modules listés ci-dessous couvrent surtout l'**IA générative** (création de contenu) et le **machine learning classique** (scoring, recommandations). Le sujet émergent en 2026 est l'**agentic commerce** — la possibilité pour un agent IA tiers (ChatGPT, Copilot, agent Shopware) d'acheter sur votre boutique au nom de l'utilisateur. Les premiers modules supportant ce protocole arrivent dans nos [Nouveautés](/nouveautes/) et finiront à terme dans une famille dédiée.
Notre équipe peut auditer votre boutique et identifier les trois automatisations à **impact maximum / effort minimum** pour votre stack — [décrivez-nous votre cas](/contact/) et nous répondons en général sous 24 h.
---
### Les indispensables
_Source :_
> Cette page n'est pas un classement de ventes. C'est notre sélection éditoriale : les modules que nous installerions sur n'importe quel projet neuf sur PrestaShop, WordPress / WooCommerce ou Shopware…
Cette page n'est pas un classement de ventes. C'est notre **sélection éditoriale** : les modules que nous installerions sur n'importe quel projet neuf sur PrestaShop, WordPress / WooCommerce ou Shopware 6, avant même de savoir précisément ce que le client veut faire.
Notre critère pour entrer dans ces listes est simple : _l'absence du module crée une dette technique ou commerciale dans les six mois_. Ce ne sont pas des modules sexy — ce sont des modules qui évitent de devoir tout refaire plus tard.
## La différence avec les best-sellers
Nos [meilleures ventes](/meilleures-ventes/) reflètent ce que les marchands achètent. Les indispensables reflètent ce que nous, intégrateurs, mettons systématiquement dans un setup propre. Il y a beaucoup de chevauchements, mais aussi des écarts intéressants :
- Certains modules à très forte adoption ne sont **pas** dans les indispensables — parce qu'ils résolvent un problème spécifique qui ne se pose pas chez tout le monde.
- Certains modules peu vendus **sont** dans les indispensables — typiquement les modules d'infrastructure (logs, monitoring, backups, gestion des erreurs) que personne n'achète spontanément mais qui sauvent la mise quand ça casse.
## Notre logique de sélection par plateforme
### PrestaShop
Nos indispensables PrestaShop couvrent quatre axes : **performance Core Web Vitals** (le moteur PS 9 est puissant mais nécessite un coup de main), **SEO technique multilingue**, **sécurité catalogue** et **gestion des retours / SAV**. Quatre piliers que toute boutique sérieuse doit avoir avant le lancement.
### WordPress / WooCommerce
Sur WooCommerce, les indispensables tournent autour de trois axes : **performance** (cache + base de données HPOS), **sécurité** (hardening WP + WooCommerce) et **conformité RGPD / EAA**. La force de WooCommerce, c'est la flexibilité — mais cette flexibilité crée des angles morts qu'il faut combler dès le départ.
### Shopware 6
Côté Shopware, l'écosystème étant plus jeune et plus B2B, nos indispensables sont moins marketing et plus opérationnels : **intégrations ERP**, **gestion fine des prix B2B**, **tableaux de bord administrateurs**, **modules de devis pro forma**. La cible Shopware est l'entreprise qui a besoin de structurer son back-office, pas la TPE qui démarre.
## À combien estimer son budget modules de démarrage ?
Pour un site sérieux, comptez entre 800 € et 1 800 € de modules indispensables à l'installation, selon la plateforme et le niveau de personnalisation. C'est beaucoup moins que ce que coûte le développement custom équivalent et c'est immédiatement disponible.
## Comment cette sélection évolue
La liste est revue chaque trimestre par l'équipe DataFirefly. Quand un module entre en obsolescence (version plateforme dépassée, mainteneur disparu, alternative supérieure), il sort. Quand une nouveauté change la donne (typiquement à chaque release majeure PrestaShop, WooCommerce ou Shopware), elle entre rapidement. Pour suivre les évolutions du catalogue en temps réel, voyez la page [Nouveautés](/nouveautes/).
Si vous voulez une recommandation chiffrée pour votre cas particulier, [décrivez-nous votre projet](/contact/) — nous répondons en général sous 24 h avec une shortlist motivée et un budget indicatif.
---
### Meilleures Ventes
_Source :_
> Sur DataFirefly, plus d'une centaine de modules sont disponibles pour les trois principales plateformes e-commerce open source — PrestaShop, WordPress / WooCommerce et Shopware 6. Plutôt que de tous les…
Sur DataFirefly, plus d'une centaine de modules sont disponibles pour les trois principales plateformes e-commerce open source — PrestaShop, WordPress / WooCommerce et Shopware 6. Plutôt que de tous les survoler, cette page met en avant ceux que **nos clients achètent réellement le plus**, plateforme par plateforme.
Les classements ci-dessous sont calculés directement depuis les ventes WooCommerce, mis à jour en continu, et reflètent donc ce qui sort vraiment du catalogue — pas une sélection éditoriale.
## Pourquoi consulter les meilleures ventes
Un module qui se vend bien est rarement un module qui sort de nulle part. C'est souvent un signal fort de trois choses :
- **Le problème qu'il résout est récurrent** — beaucoup de marchands rencontrent la même friction.
- **La qualité de mise en œuvre est validée** — un module mal codé ne franchit pas les 50 ventes.
- **Le support tient la route** — DataFirefly maintient activement ce qui se vend.
Si vous démarrez un nouveau projet et que vous hésitez entre plusieurs solutions, partir d'un best-seller est souvent un raccourci raisonnable.
## Meilleures ventes par plateforme
### PrestaShop
Les modules les plus vendus pour PrestaShop sont historiquement ceux qui touchent à la gestion catalogue, au SEO technique et à l'optimisation des performances (Core Web Vitals). La plateforme conserve une part de marché solide en Europe et nos best-sellers PrestaShop reflètent les besoins des marchands EU : multilingue natif, conformité RGPD, intégrations marketplaces.
### WordPress / WooCommerce
Côté WooCommerce, les meilleures ventes penchent vers le marketing (newsletter, SEO on-page, abonnements) et la productivité (gestion stocks, retours, retours conditionnels). C'est cohérent avec le profil typique des boutiques WooCommerce : catalogue plus modeste, focus sur l'acquisition et la rétention.
### Shopware 6
Sur Shopware, les bestsellers sont plus B2B et plus orientés architecture (extensions CMS, intégrations ERP, theming). La base d'utilisateurs Shopware étant majoritairement DACH et mid-market B2B, les modules qui décollent répondent à des besoins entreprise : pricing par groupe client, devis pro forma, comptes clients multiples.
## Comment ce classement est calculé
Les données viennent du compteur `total_sales` WooCommerce, mis à jour à chaque commande validée. Le classement se rafraîchit toutes les 30 minutes et tient compte de la totalité de l'historique du catalogue — pas seulement du mois en cours. C'est donc une lecture _« ce qui marche durablement »_ plutôt que _« ce qui décolle en ce moment »_. Pour les sorties récentes, voyez plutôt notre page [Nouveautés](/nouveautes/).
## Et si je ne sais pas par où commencer ?
Deux pistes complémentaires :
- Notre [sélection des modules indispensables](/les-indispensables/) — sélection éditoriale par plateforme, ceux que nous installerions personnellement dès le premier jour d'un projet.
- Si votre besoin est plus pointu (IA, automatisation, orchestration), la page [IA & Automatisation](/ia-intelligence-artificielle-et-automatisation-pour-e-commerce/) filtre directement le catalogue sur ces deux familles.
- La [prise de contact directe](/contact/) — décrivez votre stack et vos trois principaux pain points, nous répondons avec une shortlist motivée.
---
### Module personnalisé
_Source :_
---
### Modules PrestaShop, WordPress, Shopware sur mesure — DataFirefly
_Source :_
---
### Nous Contacter
_Source :_
---
### Nouveautés
_Source :_
> Le catalogue DataFirefly s'enrichit en continu, soit par nos propres développements, soit par l'intégration de modules développés par nos partenaires. Cette page rassemble les dernières sorties du catalogue, plateforme par…
Le catalogue DataFirefly s'enrichit en continu, soit par nos propres développements, soit par l'intégration de modules développés par nos partenaires. Cette page rassemble les **dernières sorties du catalogue**, plateforme par plateforme.
L'ordre est strictement chronologique : les modules les plus récemment publiés apparaissent en premier dans chaque carrousel. Ce qui sort cette semaine est en tête ; ce qui est sorti il y a un mois descend tranquillement.
## Pourquoi suivre les nouveautés
Trois raisons d'y jeter un œil régulièrement :
- **Anticiper les évolutions plateforme** — quand PrestaShop 9.2 ou Shopware 6.8 sort, les modules associés arrivent dans les semaines qui suivent.
- **Capter les opportunités** — un nouveau module SEO ou un nouvel intégrateur marketplace peut changer la donne sur un projet en cours.
- **Voir l'écosystème évoluer** — les tendances 2026 (IA, automatisation, conformité EAA, agentic commerce) se reflètent directement dans ce qui sort du catalogue.
## Ce qui sort en ce moment, par plateforme
### PrestaShop
Les nouveautés PrestaShop 2026 sont fortement orientées **compatibilité PS 9** et conformité **EAA** (European Accessibility Act, obligatoire depuis juin 2025). Les nouveaux modules intègrent par défaut les standards d'accessibilité et tirent parti des nouveautés du moteur Hummingbird 2.0 introduit avec PrestaShop 9.
### WordPress / WooCommerce
Côté WooCommerce, les nouveautés tournent autour de **HPOS** (High-Performance Order Storage, stabilisé depuis WC 9.0) et de l'éditeur de blocs qui se généralise sur les pages produit. Les plugins récents adoptent ces deux directions et abandonnent progressivement les hooks legacy `add_to_cart` au profit des nouveaux APIs.
### Shopware 6
Sur Shopware, les nouveautés visent **Shopware 6.7** et préparent l'arrivée de 6.8. Beaucoup de modules récents exploitent les nouvelles APIs Symfony 7.4 et le système d'événements amélioré. L'angle B2B reste très présent, et les modules Shopware Copilot (extension de l'IA native) sont une tendance lourde.
## Comment être notifié des nouveautés
Trois options :
- Cette page — mise à jour automatique à chaque nouveau module publié, sans intervention manuelle.
- Notre newsletter — un email court à chaque sortie majeure, pas plus.
- Le [flux RSS du blog](/feed/) qui couvre les annonces de modules importantes et les analyses techniques.
## Aller plus loin
Une nouveauté qui se vend bien finit en général dans nos [meilleures ventes](/meilleures-ventes/) sous 90 jours. Une nouveauté que nous trouvons réellement essentielle entre dans nos [indispensables](/les-indispensables/) au trimestre suivant. Cette page Nouveautés est donc le pipeline d'entrée du catalogue — ce qui apparaît ici aujourd'hui a de bonnes chances d'être un classique demain.
Vous avez une idée de module qui vous manque ? [Proposez-la](/contact/) — nous évaluons les suggestions en début de chaque mois et la moitié finit développée.
---
### Programme d'affiliation
_Source :_
---
### Support
_Source :_
---
## Catalogue produits — fiches détaillées
### Module TVA Packs PrestaShop 8/9 : Un Taux et un Prix par Produit
_Page produit :_
_PrestaShop · SKU DF-PACKVAT-EN · 89,00 €_
**Les packs natifs de PrestaShop n'ont qu'un seul prix et un seul taux de TVA pour tout le lot. Ce module donne à chaque composant son prix HT ou TTC, sa remise en montant ou en pourcentage et son vrai taux de TVA, puis produit des factures conformes : lignes composants éclatées ou ligne pack unique avec ventilation TVA multi-taux, exacte au centime.**
Un pack qui mélange de l'alimentaire à 5,5 % et de l'accessoire à 20 % est illégal à facturer avec les packs natifs de PrestaShop : le produit pack ne porte qu'un seul groupe de taxes et un seul prix, et la facture affiche un taux unique sur tout le lot. Ce module corrige le problème à la racine. Sur la fiche du pack, vous saisissez un prix par composant (en HT ou en TTC, l'autre se calcule tout seul), une remise optionnelle en montant ou en pourcentage, et le taux de TVA appliqué est celui du produit lui-même. Le prix du pack affiché en boutique devient la somme exacte des composants : panier, commande et facture concordent toujours.
À la validation de la commande, le module réécrit la facturation selon le mode choisi. En mode lignes éclatées, la facture remplace le pack par une ligne par composant, chacune avec son prix de base, sa remise et son taux. En mode ligne unique, le pack reste une seule ligne mais le détail des taxes de la facture est ventilé par taux, exact au centime quel que soit le mode d'arrondi de la boutique. Les remises apparaissent en clair sur la facture PDF, sur la page de confirmation et dans l'historique client. Les packs que vous ne configurez pas gardent le comportement natif : aucun risque de régression.
---
### Module Slider Page d'Accueil PrestaShop 8/9 : Bannières Rapides WebP
_Page produit :_
_PrestaShop · SKU DF-HOMEBANNERS-EN · 79,00 €_
**Composez un hero d'accueil complet : slider principal, deux bannières latérales et deux bannières promotionnelles larges, gérés depuis le back-office. Conversion WebP automatique à l'upload, préchargement de l'image LCP, lazy loading, zéro CLS et slider en JavaScript vanilla de 3 Ko : votre page d'accueil reste rapide, même chargée de visuels.**
La page d'accueil d'une boutique vit au rythme des opérations commerciales : nouveau catalogue, offre de livraison, promotion du mois. Ce module vous donne une grille de hero complète, du même type que celles des grands sites e-commerce : un slider principal, deux bannières empilées à droite et deux bannières larges en dessous. Chaque visuel se gère depuis un onglet dédié du back-office : image par langue, lien, texte alternatif, position, et une plage de dates de début et de fin pour planifier vos campagnes à l'avance. Une bannière expirée disparaît toute seule, sans intervention ni vidage de cache.
Là où la plupart des sliders plombent le score PageSpeed, celui-ci a été construit pour l'inverse. Les images sont redimensionnées et converties en WebP dès l'upload, la première slide est préchargée avec fetchpriority high pour un LCP immédiat, tout le reste est en lazy loading, et les attributs width et height éliminent le CLS. Le slider tourne avec 3 Ko de JavaScript vanilla chargé en defer, sans jQuery ni librairie externe. Le rendu est mis en cache Smarty avec une seule requête SQL, et une image mobile dédiée peut remplacer chaque slide sous 768 px. Vous pouvez même désactiver des zones entières sur mobile : les images masquées ne sont alors jamais téléchargées.
---
### Module Carrousel Produits PrestaShop 8/9 — Sliders Illimités
_Page produit :_
_PrestaShop · SKU DF-PRODUCTCAROUSEL-FR · 69,00 €_
**Créez des carrousels produits illimités partout dans votre boutique : meilleures ventes, nouveautés, promotions, sélection manuelle ou par catégorie, sur n'importe quel hook y compris vos hooks personnalisés. Colonnes desktop, tablette et mobile indépendantes, autoplay, boucle infinie, 5 skins, et des cartes produits 100 % natives de votre thème.**
Les modules de carrousel classiques imposent leur propre gabarit de carte produit : prix mal formatés, flags absents, quick view cassé, et un design qui jure avec le reste de la boutique. Product Carousel Pro prend le problème à l'envers : chaque produit est rendu par le template de miniature de votre thème actif, via les mécanismes natifs de PrestaShop (ProductAssembler et ProductPresenter). Prix, promotions, badges, ajout au panier, aperçu rapide : tout fonctionne exactement comme sur vos pages catégories, quel que soit votre thème.
Côté back-office, un onglet dédié permet de créer autant de carrousels que nécessaire : source de produits (meilleures ventes, nouveautés, promotions, catégorie, catégorie d'accueil ou sélection manuelle avec recherche autocomplete et tri par glisser-déposer), hook d'affichage parmi six emplacements standards ou n'importe quel hook personnalisé créé à la volée, colonnes desktop, tablette et mobile réglées séparément, défilement produit par produit ou rangée par rangée, autoplay, boucle infinie sans à-coup, 5 skins et couleur d'accent. Le tout sans Composer, sans jQuery, en JavaScript vanilla, compatible PrestaShop 8 et 9 et multiboutique.
---
### Module Packs de Produits & Bundles PrestaShop 8 & 9 : Lots, Coffrets & Prix Pack
_Page produit :_
_PrestaShop · SKU DF-PACKPRO-FR · 89,00 €_
**Créez des packs de produits à prix réduit sur PrestaShop 8 et 9 : lots, coffrets, bundles avec déclinaisons, produits optionnels et 4 modes de prix. Chaque composant reste une vraie ligne de commande : factures, stock et exports ERP fonctionnent nativement. Le pack s'affiche sur les fiches de ses produits.**
Un pack bien construit augmente le panier moyen sans toucher aux marges unitaires : le client voit l'économie, vous vendez trois produits au lieu d'un. Le problème des modules de bundle classiques, c'est qu'ils créent un produit fantôme : stock dédoublé, factures sur une seule ligne, exports comptables faux.
Ce module prend l'approche inverse. Le pack est une entité virtuelle composée de vrais produits du catalogue. À l'ajout au panier, chaque composant devient une vraie ligne de commande à son prix pack : le stock se décrémente produit par produit, la facture détaille chaque article, vos exports ERP et comptables restent justes. Quatre modes de prix, page pack dédiée avec URL propre, et un bloc croisé sur la fiche de chaque composant qui annonce le pack là où le client hésite.
Compatible PrestaShop 8.0 à 9.x, multi-boutique, back-office et front en cinq langues. Aucun override de classe ni de contrôleur.
---
### Prix le Plus Bas 30 Jours Shopware 6 : Conformité Directive Omnibus (Prix Barré UE)
_Page produit :_
_Shopware · SKU DF-OMNIBUS-SW-FR · 139,00 €_
**Mettez votre boutique Shopware 6 en conformité avec la directive Omnibus (UE 2019/2161). Le prix le plus bas des 30 jours précédant chaque promotion est calculé sur une fenêtre ancrée au début de la réduction, les séries de promotions restent gelées sur le prix d'avant la première remise, et aucune mention n'est affichée sans historique pour la prouver.**
---
### Module Google Calendar PrestaShop 8 & 9 : Commandes Ajoutées Automatiquement à votre Agenda
_Page produit :_
_PrestaShop · SKU DF-ORDERCALENDAR-FR · 79,00 €_
**À chaque commande validée, un événement complet est créé dans votre Google Calendar : référence, client, total, produits, adresse de livraison. Connexion OAuth 2.0 directe avec vos propres identifiants Google, sans serveur intermédiaire. Journal des échecs et relance en un clic. PrestaShop 8 et 9, 6 langues, sans dépendance.**
---
### Barre Admin Front Office PrestaShop 8 & 9 - Modifier un Produit depuis la Boutique
_Page produit :_
_PrestaShop · SKU DF-ADMINBAR-FR · 49,00 €_
**La barre d'administration WordPress pour PrestaShop 8 et 9 : modifiez le produit, la catégorie ou la page CMS affichée en un clic depuis le front office, et videz le cache sans ouvrir le back-office. Visible uniquement par vos employés connectés.**
---
### Générateur de FAQ Schema.org — Rich results et position zéro pour Shopware 6
_Page produit :_
_Shopware · SKU DF-DFFAQSCHEMA-FR · 79,00 €_
**Ajoutez des blocs FAQ éditables sur vos fiches produits, catégories et pages CMS Shopware 6, avec balisage JSON-LD FAQPage automatique pour viser les rich results Google et la position zéro. Traduit en 6 langues, sans modification du thème.**
---
### Compteur de Paniers Shopware 6 : preuve sociale « Dans + de 20 paniers » sur la fiche produit
_Page produit :_
_Shopware · SKU DF-CARTPOP-SW-FR · 69,00 €_
**Shopware stocke chaque panier sous forme de payload sérialisé : compter les paniers contenant un produit est impossible en SQL direct. Ce plugin maintient un index dédié alimenté par les événements panier, puis affiche « Dans + de 20 paniers » sous le bloc d'achat. Seuil, fenêtre temporelle, mode palier ou exact, cache intégré. Compatible Shopware 6.5, 6.6 et 6.7.**
---
### Compteur de Ventes Shopware 6 : nombre de ventes affiché sur la fiche produit
_Page produit :_
_Shopware · SKU DF-SALESCOUNT-SW-FR · 69,00 €_
**Affichez « Déjà vendu 142 fois » sur vos fiches produit Shopware 6, à partir de vos vraies commandes. Le compteur lit les lignes de commande réelles, se limite aux commandes valides ou payées, cumule les ventes de toutes les déclinaisons et n'apparaît qu'au-dessus du seuil que vous fixez. Rendu côté serveur, aucun JavaScript externe, compatible Shopware 6.5, 6.6 et 6.7.**
---
### Prix le Plus Bas 30 Jours WooCommerce (Conformité Directive Omnibus)
_Page produit :_
_WordPress / WooCommerce · SKU DFWOM-PRO · 79,00 €_
**Mettez votre boutique WooCommerce en conformité avec la directive Omnibus (UE 2019/2161). Le prix le plus bas des 30 jours précédant chaque promotion est calculé sur une fenêtre ancrée au début de la réduction, les séries de promotions restent gelées sur le prix d'avant la première remise, et aucune mention n'est affichée sans historique pour la prouver.**
---
### Dynamic Product Groups Sous-catégories Shopware 6 — DfStreamCategoryTree : filtre catégorie récursif incluant les catégories enfants
_Page produit :_
_Shopware · SKU DF-CATTREE-SW-FR · 79,00 €_
**Dans les groupes de produits dynamiques Shopware 6, le filtre Categories natif ne remonte que les produits affectés directement à la catégorie choisie. DfStreamCategoryTree ajoute un champ Category (including subcategories) basé sur product.categoryTree : vous sélectionnez la catégorie parente, tous les produits de l'arborescence descendante sont inclus automatiquement.**
---
### Séparer les Déclinaisons en Produits Distincts : Éclater un Produit à Combinaisons PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-PRODUCTSPLITTER-PL · 89,00 €_
**Transformez un produit à déclinaisons PrestaShop en plusieurs produits distincts : un produit par déclinaison, ou un produit par couleur avec les tailles conservées en combinaisons. Images, stocks, catégories, prix spécifiques et caractéristiques sont repris, avec redirection 301 du produit source et annulation en un clic.**
Un produit à quinze déclinaisons de couleur n'occupe qu'une seule URL, remonte sur une seule requête et n'affiche qu'une seule image en page catégorie. Chaque couleur qui aurait pu capter sa propre recherche reste enfermée dans un menu déroulant.
Ce module découpe ce produit en produits réellement distincts, selon deux stratégies. Un produit par déclinaison, ou un produit par valeur d'un groupe d'attributs : une fiche par couleur, les tailles restant des combinaisons du nouveau produit. Les impacts de prix et de poids sont absorbés dans le prix de base et les impacts restants recalculés, ce qui laisse les prix finaux inchangés.
Images, stocks, catégories, caractéristiques, prix spécifiques, transporteurs, fournisseurs et champs de personnalisation suivent. Le produit source peut être conservé, désactivé, redirigé en 301 vers le premier produit créé ou supprimé. Chaque découpage est journalisé et annulable en un clic.
Compatible PrestaShop 8.0 à 9.x, multi-boutique, sans dépendance Composer et sans aucun override.
---
### Augmentation des Prix en Masse WooCommerce (Inflation & Arrondi Psychologique)
_Page produit :_
_WordPress / WooCommerce · SKU DF-INFLPRICING · 59,00 €_
**Augmentez tous vos prix WooCommerce d'un pourcentage pour couvrir l'inflation, en conservant des prix lisibles type 59, 89 ou 569. Aperçu complet avant écriture, traitement par lots et annulation en un clic.**
Plugin WooCommerce premium pour répercuter l'inflation sur tout ou partie de votre catalogue sans casser vos prix psychologiques. Vous saisissez un pourcentage, le plugin applique l'augmentation puis recale chaque résultat sur une échelle de prix que vous définissez : 59, 89, 569 pour des entiers finissant par 9, ou 9,90 et 60,90 pour des décimales. L'arrondi travaille sur le prix TTC vu par le client puis reconvertit en HT selon la classe de taxe du produit. Rien n'est écrit avant validation de l'aperçu, chaque ancien prix est enregistré et l'annulation se fait en un clic. Compatible HPOS, déclinaisons et WP-CLI.
---
### Obfuscation de Liens SEO : masquer les liens à facettes et optimiser le crawl budget
_Page produit :_
_PrestaShop · SKU DF-OBFUSCATOR-FR · 79,00 €_
**Réécrivez les liens à facettes, de tri et de pagination en éléments non explorables, directement dans le HTML servi. Le crawler ne voit plus ces liens, le visiteur ne voit aucune différence : clic, clic molette, ctrl+clic et navigation clavier restent identiques.**
## La navigation à facettes fabrique des milliers d'URLs
Un jeu de six filtres à quatre valeurs produit plusieurs milliers de combinaisons d'URL sur une seule catégorie. Googlebot les découvre, les met en file d'attente et les explore. Pendant ce temps, vos nouvelles fiches produits attendent. Le budget d'exploration part dans des pages de filtres, et le maillage interne dilue son jus sur des URLs que vous ne cherchez pas à positionner.
Les réponses classiques ont chacune leur limite. Le noindex laisse le crawler consommer sa file d'attente avant de comprendre. Le disallow dans le robots.txt bloque l'exploration mais laisse les liens transmettre du PageRank vers un mur. Le canonical demande à Google d'explorer la page pour lire l'instruction. Dans les trois cas, le crawler a d'abord vu le lien.
## Une réécriture côté serveur, pas un correctif JavaScript
Ce module intervient sur le HTML final, avant qu'il ne parte vers le navigateur, via le hook actionOutputHTMLBefore. Les liens qui correspondent à vos sélecteurs sont transformés en éléments span portant l'URL encodée dans un attribut data. Aucune balise de lien ne subsiste dans le code source pour ces éléments.
La différence avec les solutions purement JavaScript est nette : un crawler qui n'exécute pas le JavaScript, ou qui analyse le HTML brut avant rendu, ne trouve rien à explorer. Avec une obfuscation appliquée après le chargement de la page, le lien est présent dans la source et reste exploitable.
## Ce que voit un visiteur
Rien de différent. Le clic gauche ouvre la page, le clic molette et le ctrl+clic ouvrent un nouvel onglet, la touche Entrée fonctionne au clavier. Les éléments obfusqués reçoivent tabindex 0, role link et un contour de focus visible, donc la navigation au clavier et les lecteurs d'écran continuent de les traiter comme des liens.
Le rafraîchissement AJAX des filtres et le scroll infini réinjectent des liens dans la page après le rendu initial. Un MutationObserver leur applique les mêmes sélecteurs, ce qui évite les comportements incohérents entre le premier affichage et les suivants.
## Ce que ce module n'est pas
Ce n'est pas du cloaking. Le contenu servi est strictement identique pour un visiteur et pour un crawler : aucune détection de user-agent, aucun HTML alternatif. La seule chose qui change, c'est que certains liens ne sont plus des liens pour personne, et que le navigateur les reconstitue au moment de l'interaction.
Ce n'est pas non plus un remplaçant du robots.txt ou du noindex. Ces outils restent pertinents pour les URLs déjà indexées. L'obfuscation empêche la découverte de nouvelles, elle ne désindexe pas l'existant.
---
### Vérificateur de Liens Morts PrestaShop 8 & 9 - Liens Cassés & Images Manquantes
_Page produit :_
_PrestaShop · SKU DF-BROKENLINKS · 59,00 €_
**Analysez tout votre catalogue à la recherche des liens qui ne répondent plus et des images qui ne s'affichent plus. Le module vérifie le code HTTP de chaque lien et de chaque image, contrôle la présence des fichiers images sur le disque, et vous emmène directement sur la fiche à corriger.**
---
### Nettoyage HTML des Descriptions Produits & Catégories : Supprimer le Code Word, les Styles Inline et les Balises Vides (PrestaShop 8 & 9)
_Page produit :_
_PrestaShop · SKU DF-HTMLCLEANER-FR · 79,00 €_
**Supprimez le code Word, les styles inline et les balises vides de vos descriptions produits et catégories PrestaShop. Simulation avant écriture, traitement par lots AJAX et restauration d'une exécution en un clic.**
---
### Module Promotions par Quantité PrestaShop 8 & 9 - X Achetés Y Offerts & Badges Promo
_Page produit :_
_PrestaShop · SKU DF-QUANTITYDEAL-FR · 79,00 €_
**Créez des promotions par quantité sur PrestaShop 8 et 9 : 4+2 offerts, 3+1, le 2e à -25 %, le 3e à -50 %, prix de lot. Le badge s'affiche sur la vignette produit et la remise se calcule dans le panier, sans code promo à saisir.**
Vos clients prennent une unité là où votre marge tient sur trois. Les promotions par quantité règlent ce problème sans toucher au prix unitaire : acheter plus devient visiblement intéressant, et l'offre se voit dès la page catégorie.
Ce module ajoute cinq mécaniques de promotion à la quantité (X achetés Y offerts, le Nième article à -X %, à -X €, à prix imposé, ou prix de lot) et pose le badge correspondant sur la vignette produit, comme en grande distribution. La remise est recalculée à chaque modification du panier via une règle de panier privée. Le client n'a aucun code à saisir.
Compatible PrestaShop 8.0 à 9.x, multi-boutique, back-office et front en cinq langues. Aucun override de classe ni de contrôleur.
---
### Commandes Récurrentes & Programmées — Réassort Automatique PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-RECURRINGORDER-FR · 109,00 €_
**Commandes récurrentes pour PrestaShop 8 & 9 : le client programme la répétition, reçoit avant chaque échéance un e-mail avec un lien panier prêt à régler. Sans prélèvement automatique.**
---
### Module Espace Membre & Abonnement PrestaShop 8 & 9 — Contenu Payant, Paywall & Stripe
_Page produit :_
_PrestaShop · SKU DF-MEMBERSHIP-FR · 129,00 €_
**Vendez des abonnements qui ouvrent un espace membre et du contenu réservé : articles, vidéos, fichiers, prix de groupe et pages CMS privées. Deux modes de facturation au choix par formule — accès à durée limitée expiré par cron, ou abonnement récurrent réel via Stripe Billing. PrestaShop 8 et 9, multiboutique, 5 langues, sans dépendance.**
---
### Module Coffret Personnalisé PrestaShop 8 & 9 — Box Builder Mix & Match
_Page produit :_
_PrestaShop · SKU DF-BOXBUILDER-FR · 129,00 €_
**Laissez vos clients composer leur propre coffret à partir de la sélection que vous choisissez : grille interactive, prix calculé en direct, 4 modèles de tarification, emplacements catégoriels, coffrets pré-composés, surprise et lien de partage. PrestaShop 8 et 9, multiboutique, 5 langues, sans dépendance.**
---
### Récupération de Panier Abandonné Shopware 6 — Relances Email & Codes Promo Uniques
_Page produit :_
_Shopware · SKU DF-CARTRECOVERY-SW · 129,00 €_
**Récupérez automatiquement vos paniers abandonnés sur Shopware 6 : jusqu'à 3 relances email planifiées, code promo unique par client, lien de restauration du panier en 1 clic et tracking complet des commandes récupérées. Fonctionne sur Shopware CE 6.5, 6.6 et 6.7 — sans plan Commercial ni service externe.**
Shopware Community Edition n'a aucune fonctionnalité native pour les paniers abandonnés : la récupération est réservée au plan Commercial via le Flow Builder étendu. Résultat, 70 % des paniers partent en fumée sans la moindre relance. DfCartRecovery comble ce vide avec un moteur de relance complet : détection des paniers abandonnés (clients connectés et invités identifiés), jusqu'à trois emails de relance aux délais configurables, code promo unique généré par client et rattaché à une promotion de votre choix, lien de restauration qui reconstruit le panier en un clic, et tracking de récupération avec l'identifiant de commande. Le template email est éditable dans l'admin Shopware et pré-installé en cinq langues. Purge RGPD automatique, aucun service externe, aucun build d'administration requis. Compatible Shopware 6.5, 6.6 et 6.7, multi-canaux de vente.
---
### Programme de Fidélité Shopware 6 — Points, Paliers & Bons d'achat
_Page produit :_
_Shopware · SKU DFLOYALTY-SW · 129,00 €_
**Programme de fidélité complet pour Shopware 6 : vos clients gagnent des points à chaque commande, progressent dans des paliers avec multiplicateurs et convertissent leurs points en bons d'achat via les promotions natives. Compatible 6.5, 6.6 et 6.7, sans compilation.**
---
### Gestion DLC & DLUO — Lots, FEFO et dates de péremption
_Page produit :_
_PrestaShop · SKU DF-DLC-FR · 99,00 €_
**Gérez vos dates limites de consommation (DLC) et dates de durabilité minimale (DLUO/DDM) par lot sur PrestaShop 8 et 9 : déstockage FEFO automatique, affichage de la date sur la fiche produit, promotions automatiques sur les dates courtes, désactivation des lots périmés et alertes e-mail.**
---
### Formulaire de Livraison Objets Lourds & Volumineux — Meubles, Électroménager, TV (PrestaShop 8 & 9)
_Page produit :_
_PrestaShop · SKU DF-DELIVERYFORM · 89,00 €_
**Collectez les conditions d'accès (étage, ascenseur, escaliers, obstacles) directement au checkout pour vos produits lourds ou volumineux : meubles, lave-linge, TV, mobilier médical. Champs 100 % configurables en back-office, notification email et récap dans la fiche commande.**
---
### Filtres à Facettes AJAX PrestaShop
_Page produit :_
_PrestaShop · SKU dffacetedfilter · 99,00 €_
**Navigation à facettes nouvelle génération pour PrestaShop 8 & 9 : slider de prix avec histogramme, filtres couleur visuels, multi-sélection à compteurs dynamiques et contrôle total de l'indexation SEO des pages filtrées. Intégration native, sans surcharge.**
---
### Relances d'Impayés B2B & Pénalités de Retard – Module PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-DUNNING-FR · 89,00 €_
**Automatisez la relance des commandes B2B payées par virement et restées impayées : scénarios de relance en 3 niveaux, calcul des pénalités légales de retard et de l'indemnité forfaitaire de 40 €, lettres et mises en demeure PDF, tableau de bord des créances. PrestaShop 8 et 9, cron sécurisé, sans Composer.**
Les commandes B2B réglées par virement traînent souvent en impayé, et relancer chaque client à la main coûte du temps — quand ce n'est pas oublié. Ce module suit automatiquement vos créances dès la validation de la commande, déclenche des relances graduées selon un calendrier que vous définissez, et chiffre les pénalités de retard ainsi que l'indemnité forfaitaire de recouvrement de 40 € prévues par le Code de commerce.
Trois niveaux de relance sont prêts à l'emploi : une relance courtoise, une relance ferme avec pénalités et lettre PDF, puis une mise en demeure formelle. Un tableau de bord dédié affiche l'encours, la balance âgée de vos créances et le suivi des relances envoyées. Compatible PrestaShop 8 et 9, multiboutique, cron sécurisé par token, sans Composer.
---
### Validation TVA Intracommunautaire VIES & Autoliquidation B2B
_Page produit :_
_PrestaShop · SKU dfviesb2b · 79,00 €_
**Vérifiez les numéros de TVA intracommunautaire via VIES en temps réel au checkout, appliquez l'autoliquidation (TVA 0 %, art. 138) automatiquement pour vos clients B2B européens, et conservez un journal de preuves horodaté avec numéro de consultation officiel — indispensable en cas de contrôle fiscal.**
---
### TVA OSS / IOSS — Déclarations UE & seuil 10 000 €
_Page produit :_
_PrestaShop · SKU dfvatoss · 89,00 €_
**Automatisez votre conformité TVA e-commerce dans l'UE : rapport de TVA par pays de consommation, surveillance du seuil de 10 000 €, export OSS trimestriel et gestion IOSS pour les envois jusqu'à 150 €. Compatible PrestaShop 8 et 9, multiboutique et multilingue.**
---
### Module Facturation Récapitulative B2B PrestaShop 8 & 9 — Facture Mensuelle Consolidée par Client
_Page produit :_
_PrestaShop · SKU DF-DEFERREDINVOICING-FR · 89,00 €_
**Une seule facture mensuelle consolidée par client professionnel, au lieu d'une facture par commande. Le module regroupe toutes les commandes de la période, numérote la facture récapitulative en séquence, calcule la ventilation TVA par taux, l'envoie par email en PDF et retire la facture individuelle des emails de commande. Cron automatique, anti-doublon garanti, PrestaShop 8 et 9, multiboutique, 5 langues, sans dépendance.**
---
### Lookbook Shoppable — Shop the Look & Hotspots Cliquables
_Page produit :_
_PrestaShop · SKU dfshopthelook · 79,00 €_
**Transformez vos photos d'ambiance en vitrines cliquables. Placez des hotspots sur vos produits, affichez un carrousel de looks sur la page d'accueil et en fiche produit, et laissez vos clients ajouter tout le look au panier en un seul clic.**
---
### Vue Produit 360° PrestaShop — Visionneuse Spin par Séquence d'Images
_Page produit :_
_PrestaShop · SKU df360spin · 79,00 €_
**Ajoutez une vue produit 360° interactive à vos fiches PrestaShop à partir d'une séquence d'images spin : rotation au drag souris et tactile avec inertie, lecture automatique, plein écran, navigation clavier et lazy loading. Gestion des frames en glisser-déposer, redimensionnement automatique, aucun override. Compatible PrestaShop 8 & 9, sans jQuery.**
La fiche produit PrestaShop montre une photo figée là où vos clients aimeraient tourner l'article dans tous les sens avant d'acheter. **Vue Produit 360°** ajoute une visionneuse interactive qui reconstitue une rotation complète à partir d'une simple séquence d'images prises sur tourne-disque, sans toucher aux templates de votre thème.
Le visiteur fait glisser l'objet à la souris ou au doigt pour le faire pivoter, avec une inertie naturelle en fin de geste. Lecture automatique, plein écran, compteur d'images et navigation au clavier sont inclus. Les images se chargent uniquement quand la visionneuse entre dans l'écran, pour préserver la vitesse de la page.
Côté back-office, vous rattachez une séquence à un produit, glissez-déposez vos images, les réordonnez à la souris et prévisualisez la rotation avant publication. Les frames trop larges sont redimensionnées automatiquement à l'import. Une séquence par produit, gérée par boutique en multiboutique.
---
### Décoration Saisonnière Planifiée – Noël, Black Friday & Soldes
_Page produit :_
_PrestaShop · SKU dfthemescheduler · 99,00 €_
**Programmez l'habillage de votre boutique à l'avance : bandeau promo avec compte à rebours, bannière, palette de couleurs, neige ou feux d'artifice. Chaque campagne démarre et s'arrête toute seule aux dates choisies, avec récurrence annuelle et prévisualisation sécurisée.**
Décoration Saisonnière Planifiée transforme votre boutique PrestaShop pour chaque temps fort commercial, sans intervention manuelle le jour J. Créez vos campagnes de Noël, Black Friday, soldes ou Saint-Valentin des semaines à l'avance : le module applique et retire automatiquement bandeaux, bannières, couleurs et effets visuels aux dates programmées.
---
### Barre d'annonce & Compte à rebours — Bandeau promo PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-ANNOUNCEBAR · 59,00 €_
**Affichez le bon message au bon visiteur : barre d'annonce avec rotation de messages, compte à rebours en direct, ciblage par langue, pays et groupe client, planification et bouton de fermeture mémorisé. Trois emplacements, zéro jQuery.**
---
### Fil d'Ariane Pro
_Page produit :_
_PrestaShop · SKU dfbreadcrumbpro · 89,00 €_
**Fil d'Ariane avancé pour PrestaShop 8 & 9 : menus déroulants donnant accès aux catégories sœurs sur chaque niveau, données structurées JSON-LD BreadcrumbList conformes aux guidelines Google, et chemin intelligent pour les produits appartenant à plusieurs catégories.**
Fil d'Ariane Pro remplace le fil d'Ariane basique de votre thème PrestaShop par une navigation enrichie qui sert à la fois vos visiteurs et votre référencement. Chaque niveau du fil devient un point d'entrée vers les catégories sœurs grâce à des menus déroulants accessibles au survol ou au tap, le balisage JSON-LD BreadcrumbList rend vos pages éligibles aux résultats enrichis Google, et trois stratégies configurables garantissent que vos produits multi-catégories affichent toujours le chemin le plus pertinent — y compris un mode contextuel basé sur le parcours réel du visiteur.
---
### Galerie Produit PrestaShop — Zoom HD, Plein Écran & Filtre Variantes
_Page produit :_
_PrestaShop · SKU dfgallerypro · 69,00 €_
**Remplacez la galerie native de PrestaShop : zoom HD au survol basé sur l'image originale, vignettes verticales, visionneuse plein écran avec pincement sur mobile, filtrage des images par déclinaison sélectionnée et lazy loading optimisé LCP. Sans override, compatible PrestaShop 8 & 9.**
La galerie produit native de PrestaShop est un point faible connu : zoom limité, vignettes rigides, aucune expérience plein écran digne de ce nom sur mobile, et toutes les images affichées quelle que soit la déclinaison choisie. **Galerie Produit PrestaShop** la remplace intégralement, sans toucher aux templates de votre thème.
Le module injecte une galerie moderne directement sur la fiche produit : zoom interne haute résolution au survol qui bascule automatiquement vers l'image source originale, colonne de vignettes verticales, visionneuse plein écran immersive avec pincement à deux doigts et navigation par balayage sur mobile.
Surtout, la galerie **filtre les images selon la déclinaison sélectionnée** en s'appuyant sur les associations natives images / combinaisons, et se resynchronise à chaque changement de variante. Le tout avec une stratégie de chargement pensée pour le Largest Contentful Paint : cover préchargée en priorité haute, le reste en différé.
---
### Page Catégorie Visuelle : Sous-catégories en Tuiles Images (Category Wall)
_Page produit :_
_PrestaShop · SKU dfcategorywall · 89,00 €_
**Remplacez la liste de sous-catégories native, datée et sans image, par un mur visuel de tuiles imagées avec compteurs de produits et trois mises en page au choix : grille, mosaïque ou carrousel.**
---
### Search Landing Pages — Landing pages SEO depuis la recherche interne
_Page produit :_
_PrestaShop · SKU DF-SEARCHLANDING-PL · 89,00 €_
**Transformez vos recherches internes les plus fréquentes en vraies pages d'atterrissage indexables : contenu éditorial, listing produits natif, URL propre, sitemap XML dédié et redirection 301 intelligente. « chaussure running homme » devient une landing SEO qui se positionne sur Google.**
## Vos clients vous disent déjà quoi référencer
Chaque jour, des visiteurs tapent des requêtes précises dans le moteur de recherche de votre boutique : « chaussure running homme », « sac à dos randonnée », « veste imperméable femme ». Ces requêtes sont de l'or SEO — elles révèlent exactement l'intention de recherche de votre marché. Mais les pages de résultats de recherche PrestaShop ne sont pas indexables, pas éditorialisées, pas optimisées.
Search Landing Pages capte ces requêtes, vous montre les plus fréquentes, et les transforme en un clic en véritables pages d'atterrissage : une URL propre, un H1, du contenu éditorial au-dessus et en dessous d'un listing produits rendu nativement par votre thème, des balises meta dédiées, un canonical propre et un sitemap XML prêt pour la Search Console.
## Un pipeline complet, de la donnée à la position Google
Le module journalise chaque recherche du front-office avec son volume, sa langue et son nombre de résultats. Le rapport back-office classe les requêtes par popularité et signale celles qui n'ont pas encore de landing. Un bouton « Créer la landing » pré-remplit tout : requête, titre, URL simplifiée. Il ne vous reste que le contenu éditorial — la partie où vous apportez la valeur.
Deux modes de listing au choix : les résultats live du moteur de recherche (toujours synchronisés avec votre catalogue) ou une sélection manuelle ordonnée via un sélecteur de produits avec autocomplétion. Et pour boucler la boucle, une redirection 301 optionnelle envoie les visiteurs qui tapent la requête directement vers votre landing éditorialisée.
## Des garde-fous SEO intégrés
Indexable ou noindex par page, passage automatique en noindex quand une page ne renvoie plus aucun produit (anti thin-content), canonical auto-référent avec gestion de la pagination, fil d'Ariane intégré. Le rendu des produits passe par le présentateur natif de PrestaShop : vos miniatures s'affichent exactement comme dans une catégorie.
---
### Module Souvent achetés ensemble PrestaShop 8/9
_Page produit :_
_PrestaShop · SKU DF-BUNDLEVISUAL-PL · 69,00 €_
**Bloc « Souvent achetés ensemble » façon Amazon sur la fiche produit : produits cochables, prix total dynamique et remise de lot appliquée automatiquement. Suggestions issues de vos vraies commandes.**
Le module Souvent achetés ensemble reproduit sur PrestaShop le bloc de vente croisée le plus efficace du e-commerce : plusieurs produits complémentaires présentés côte à côte, cochables individuellement, avec un prix total qui se recalcule en direct et un bouton unique pour ajouter toute la sélection au panier.
Vous composez vos lots manuellement depuis un onglet dédié du back-office et leur associez une remise en pourcentage ou en montant fixe, appliquée uniquement lorsque le lot complet est au panier. Et si aucun lot manuel n'existe pour un produit, le module suggère automatiquement les articles réellement achetés ensemble d'après votre historique de commandes — sans IA, sans service externe, uniquement vos données.
---
### Product Story — Blocs Storytelling Fiche Produit
_Page produit :_
_PrestaShop · SKU dfproductstory · 79,00 €_
**Ajoutez des sections storytelling riches sur vos fiches produit PrestaShop 8 et 9 : blocs image + texte alterné, vidéo lazy, tableau comparatif et icônes bénéfices, assemblés en drag & drop et ciblés par produit ou catégorie. L'alternative légère aux page builders lourds.**
---
### Swipe Shopping Mobile — Découverte Produits Style Tinder
_Page produit :_
_PrestaShop · SKU DF-SWIPEGALLERY · 69,00 €_
**Transformez vos pages catégorie en expérience de découverte ludique sur mobile : vos visiteurs parcourent les produits carte par carte façon Tinder, ajoutent en wishlist d'un swipe à droite et au panier d'un geste vers le haut. Analytics intégrés en back-office.**
---
### Configurateur de Produit par Étapes — Options visuelles, aperçu live & impact prix (PrestaShop 8 & 9)
_Page produit :_
_PrestaShop · SKU dfproductconfigurator · 129,00 €_
**Transformez votre fiche produit en configurateur par étapes : options visuelles avec vignettes ou pastilles de couleur, gravure de texte, aperçu composé en temps réel et supplément de prix calculé côté serveur. Compatible PrestaShop 8 et 9, multi-devise.**
---
### Module Google Fonts Local PrestaShop 8/9 — Polices Auto-hébergées RGPD
_Page produit :_
_PrestaShop · SKU DF-FONTMANAGER-FR · 59,00 €_
**Hébergez vos Google Fonts en local en un clic : plus aucune requête vers les serveurs de Google (RGPD), subsetting automatique pour ne télécharger que les alphabets utiles, préchargement du fichier critique et remplacement des polices de votre thème par simples règles CSS — sans modifier un seul fichier du thème.**
Chaque page de votre boutique qui charge une police depuis fonts.googleapis.com transmet l'adresse IP de vos visiteurs à Google — sans consentement. Depuis la décision du tribunal de Munich en 2022, cette pratique expose juridiquement les e-commerçants européens, et les mises en demeure se multiplient. Le module Google Fonts Local règle le problème à la racine : recherchez une police dans le catalogue Google Fonts intégré, choisissez vos graisses et vos alphabets, cliquez sur Importer. Les fichiers woff2 sont téléchargés une seule fois sur votre serveur, et vos visiteurs ne contactent plus jamais Google. Une option supprime même les appels externes que votre thème ou d'autres modules injectent dans le HTML.
Le module ne se contente pas de la conformité : il optimise. Le subsetting automatique ne télécharge que les alphabets cochés (latin, latin-ext, cyrillique…) et conserve les unicode-range pour que le navigateur ne charge que les plages réellement affichées. Le fichier critique de chaque famille peut être préchargé, et la stratégie font-display (swap par défaut) élimine le texte invisible au chargement. Enfin, des règles de remplacement — sélecteur CSS vers police — appliquent vos nouvelles typographies par-dessus le thème, sans toucher au moindre fichier : body, titres, boutons, tout se pilote depuis le back-office. Compatible PrestaShop 8 et 9, sans Composer ni framework, JS vanilla.
---
### Accessibilité EAA — Widget & Corrections WCAG Automatiques
_Page produit :_
_PrestaShop · SKU dfaccessibility · 79,00 €_
**Mettez votre boutique PrestaShop en conformité avec la directive européenne sur l'accessibilité (EAA) : widget d'accessibilité complet, corrections WCAG automatiques (alt, labels, ARIA, focus, contraste) et déclaration d'accessibilité générée en 5 langues. Sans toucher à votre thème.**
---
### Video Background — Bannière vidéo accueil & catégories
_Page produit :_
_PrestaShop · SKU dfvideobackground · 79,00 €_
**Ajoutez des sections hero vidéo plein écran sur votre page d'accueil et vos pages catégories PrestaShop 8 & 9. Vidéo auto-hébergée MP4/WebM sans YouTube ni cookie tiers, lazy loading intelligent, image de repli sur mobile et overlay titre + bouton multilingues.**
---
### Blocs de Réassurance & Badges de Confiance
_Page produit :_
_PrestaShop · SKU dftrustbuilder · 59,00 €_
**Créez vos blocs de réassurance en quelques minutes : 18 icônes SVG intégrées (paiement sécurisé, livraison, retours, made in EU), positionnement en glisser-déposer sur 6 zones du front-office et variantes par langue. Compatible PrestaShop 8 et 9.**
Les blocs de réassurance sont l'un des leviers de conversion les plus rentables d'une boutique en ligne : paiement sécurisé, délais de livraison, politique de retours, origine des produits. Ce module vous permet de les créer, traduire et positionner sans toucher au thème ni écrire une ligne de code.
Choisissez une icône dans la bibliothèque intégrée, rédigez le titre et le sous-titre dans chaque langue, sélectionnez la zone d'affichage et réordonnez le tout en glisser-déposer depuis le back-office.
---
### Mode Maintenance & Coming Soon
_Page produit :_
_PrestaShop · SKU dfmaintenancepro · 79,00 €_
**Page maintenance & coming soon designée pour PrestaShop 8 & 9 : compte à rebours, capture d'e-mails, accès testeurs par IP ou token, et soft launch pays par pays — sans jamais toucher au mode maintenance natif.**
---
### Galerie Photos Clients Shoppable — UGC & Instagram
_Page produit :_
_PrestaShop · SKU dfugcgallery · 79,00 €_
**Transformez les photos de vos clients en vitrine qui vend : galerie shoppable sur la page d'accueil et les fiches produits, upload après commande, import Instagram et hotspots produits cliquables. Modération complète, consentement RGPD, zéro dépendance jQuery.**
---
### Pages Marques SEO — Mur de Marques A–Z
_Page produit :_
_PrestaShop · SKU dfbrandhub · 79,00 €_
**Transformez vos pages fabricant PrestaShop en vraies pages marques : mur de logos A–Z avec recherche instantanée, bannière, H1 et métas SEO par marque, description enrichie, listing produits natif avec facettes et données structurées Brand.**
---
### E-reporting Facturation Électronique 2026 (PDP)
_Page produit :_
_PrestaShop · SKU dfereporting · 89,00 €_
**Réforme de la facturation électronique : transmettez vos données de transactions B2C et vos statuts de facture à votre Plateforme Agréée (PDP) ou au PPF. Flux 10 DGFiP au format XML/JSON, périodicité automatique selon votre régime TVA, cycle de vie des factures et cron sécurisé. Prêt pour septembre 2026.**
---
### Preuve Sociale — Notifications d'achat & Visiteurs en direct
_Page produit :_
_PrestaShop · SKU DF-SOCIALPROOF · 59,00 €_
**Affichez des notifications d'achats réels anonymisées et un compteur de visiteurs en direct sur vos fiches produit. Une preuve sociale 100 % éthique : données réelles uniquement, anonymisation côté serveur, zéro cookie.**
---
### Maillage Interne Automatique Shopware 6
_Page produit :_
_Shopware · SKU DfInternalLinking · 89,00 €_
**Injectez automatiquement des liens internes contextuels dans vos fiches produits et catégories Shopware, structurez vos silos SEO et détectez vos pages orphelines. Compatible Shopware 6.5, 6.6 et 6.7.**
---
### Gestionnaire de Redirections 301 & Capture 404 – Shopware 6
_Page produit :_
_Shopware · SKU DF-REDIRECTS-SW · 89,00 €_
**Gérez toutes vos redirections 301/302/410 et capturez automatiquement les erreurs 404 de votre boutique Shopware. Matching exact, wildcard ou regex, suggestions de cible par similarité d'URL, import CSV en masse et compteur de hits. Compatible Shopware 6.5, 6.6 et 6.7, multi-canaux.**
Shopware gère mal les URLs orphelines : dès qu'un produit ou une catégorie est supprimé, ses anciennes adresses renvoient une 404 — perte de trafic, de position Google et de clients. DfRedirects comble ce manque avec un vrai gestionnaire de redirections (301, 302, 307, 308 et 410) doté de trois modes de correspondance (exact, wildcard, regex), d'une capture automatique des 404 depuis le trafic réel, de suggestions de cible par similarité d'URL, et d'un import CSV pour migrer des centaines de règles en une fois. Chaque redirection compte ses hits, chaque 404 est dédupliquée et priorisée. Compatible Shopware 6.5, 6.6 et 6.7, multi-canaux de vente.
---
### Avis Vérifiés WooCommerce — Résumé IA et Réponse Automatique
_Page produit :_
_WordPress / WooCommerce · SKU dfreviews · 89,00 €_
**Collectez des avis vérifiés après chaque commande, affichez un résumé IA (forces, faiblesses, synthèse) sur vos fiches produit et répondez automatiquement à chaque avis grâce à l'IA — avec votre propre clé OpenAI, sans abonnement SaaS.**
---
### Onglets Fiche Produit PrestaShop — Gestionnaire Drag & Drop
_Page produit :_
_PrestaShop · SKU dftabsbuilder · 79,00 €_
**Ajoutez des onglets personnalisés à vos fiches produit PrestaShop et réorganisez-les en glisser-déposer. Onglets globaux, par catégorie ou par produit, contenu HTML ou page CMS, transformés en accordéon sur mobile.**
---
### Image au Survol & Badges Automatiques PrestaShop
_Page produit :_
_PrestaShop · SKU dfimagehover · 69,00 €_
**Rendez vos listings PrestaShop plus vivants : la deuxième image du produit s'affiche au survol et des badges Nouveau, Promo et Stock faible se déclenchent automatiquement selon vos règles. Sans toucher à votre thème.**
---
### Scroll Infini PrestaShop — Pagination SEO & Retour Position
_Page produit :_
_PrestaShop · SKU dfinfinitescroll · 69,00 €_
**Scroll infini en catégorie avec pagination SEO préservée : URL et canonical synchronisés via History API, bouton « Charger plus » hybride, et retour à la position exacte sur le produit visité au retour d'une fiche. Compatible navigation à facettes, PrestaShop 8 & 9.**
Le scroll infini classique règle un problème d'UX mais en crée deux autres : il casse le référencement de la pagination, et il renvoie le visiteur tout en haut de la liste quand il revient d'une fiche produit. **Scroll Infini PrestaShop** traite les deux de front.
Le module ne crée aucun endpoint AJAX : il récupère les URLs paginées natives de votre thème (page 2, page 3, etc.) et injecte les produits au fil du scroll. Sans JavaScript, la pagination serveur reste intacte et parfaitement crawlable par les robots. Avec JavaScript, la barre d'adresse, la balise canonical et les liens rel prev/next sont synchronisés en continu via l'History API, dans les deux sens de défilement.
Surtout, quand un visiteur clique sur un produit puis revient en arrière, les pages déjà chargées sont réinjectées instantanément et la vue se recale **exactement sur le produit qu'il avait cliqué** — le point de douleur que la plupart des modules de scroll infini ne gèrent pas correctement.
---
### Prix par Pays, Boutique & Devise
_Page produit :_
_PrestaShop · SKU dfmultiprice · 89,00 €_
**Fixez vos prix par boutique, pays et devise : coefficient de marge, arrondi psychologique (x,90 / x,95 / x,99) calculé sur le prix TTC, recalcul en masse par lots et cron. Compatible PrestaShop 8 et 9, multi-boutique.**
---
### Synchronisation Multi-Boutiques - Module Prestashop 8 & 9
_Page produit :_
_PrestaShop · SKU dfmultisync · 99,00 €_
**Synchronisez catalogue, stock et prix entre plusieurs boutiques PrestaShop distinctes, via le webservice natif. Push ou pull, mapping d'IDs persistant, gestion des conflits et automatisation par cron.**
## Gardez plusieurs boutiques PrestaShop parfaitement synchronisées
Vous gérez deux boutiques PrestaShop ou plus — une boutique de gros et une boutique grand public, un site par pays, une boutique de test et une boutique de production ? **Synchronisation Multi-Boutiques** réplique automatiquement vos catégories, produits, stocks et prix spécifiques d'une installation à l'autre, en s'appuyant uniquement sur le webservice natif de PrestaShop. Aucun service tiers, aucun intermédiaire, aucune donnée qui transite ailleurs que chez vous.
## Push ou pull : c'est vous qui décidez de la source
Chaque profil de synchronisation définit un sens : en mode _push_, la boutique courante est la source et pousse ses données vers la boutique distante ; en mode _pull_, c'est l'inverse, la boutique distante fait autorité. Vous pouvez cumuler plusieurs profils vers plusieurs sites distants, chacun avec ses propres entités et ses propres règles.
## Un mapping d'IDs qui ne se perd jamais
Le module apparie une fois pour toutes chaque entité locale à son équivalent distant et conserve cette correspondance de façon permanente. Les langues sont appariées par code ISO, les catégories par leur hiérarchie, les déclinaisons par référence. Résultat : une catégorie ou un produit n'est jamais dupliqué, même après des dizaines de synchronisations.
## Détection des changements par empreinte
À chaque passage, seules les entités réellement modifiées sont transférées. Le module calcule une empreinte de chaque produit et la compare à la dernière synchronisation : ce qui n'a pas bougé est ignoré, ce qui rend les exécutions rapides même sur de gros catalogues.
## La gestion des conflits pensée pour le terrain
Quand les deux boutiques ont modifié la même fiche, le module applique la stratégie de votre choix : la source gagne, la cible gagne, le plus récent gagne, ou arbitrage manuel. Dans ce dernier cas, les conflits sont mis en file d'attente et vous les résolvez en un clic depuis le back-office (« garder local » ou « garder distant »).
## Conçu pour les gros catalogues et l'hébergement mutualisé
La synchronisation s'exécute par lots avec un budget de temps configurable et une reprise automatique : si une exécution est interrompue, la suivante repart exactement là où elle s'était arrêtée. Vous pouvez lancer une synchro à la demande depuis le tableau de bord, ou l'automatiser via une URL de cron sécurisée par jeton.
## Ce qui est synchronisé
- Catégories (avec hiérarchie et contenus multilingues)
- Produits simples et à déclinaisons, appariés par référence
- Quantités de stock
- Prix spécifiques (mode push)
- Images produits (envoi incrémental en push, téléchargement à la création en pull)
Compatible PrestaShop 8 et 9, multiboutique, avec code source complet inclus. Support et mises à jour de compatibilité assurés par DataFirefly.
---
### Duplication Multiboutique d'une Catégorie Complète — PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU dfshopduplicator · 109,00 €_
**Dupliquez une catégorie entière — produits, déclinaisons, images, prix spécifiques et stock — d'une boutique vers une ou plusieurs autres, en un clic. Assistant en 3 étapes, mapping visuel des catégories cibles et exécution par lots AJAX sans timeout.**
---
### Module Recherche Sans Résultat PrestaShop 8/9 — Page de Rattrapage & Alertes Produit
_Page produit :_
_PrestaShop · SKU DF-ZEROSEARCH-FR · 79,00 €_
**Au lieu d'un « aucun résultat », affichez une page de rattrapage : correction orthographique, produits proches, top ventes de la catégorie devinée, best-sellers et formulaire « prévenez-moi ». Plus un dashboard des requêtes perdues avec mapping requête → produit, catégorie ou URL.**
Chaque recherche qui renvoie « aucun résultat » est une vente qui s'échappe : le visiteur a exprimé une intention d'achat précise, et votre boutique lui répond par un cul-de-sac. Le module Recherche Sans Résultat transforme cette page vide en page de rattrapage. Dès qu'une recherche ne renvoie rien, le module propose une correction orthographique « vouliez-vous dire… », des produits proches, les meilleures ventes de la catégorie qu'il devine à partir des mots de la requête, et, en dernier recours, vos best-sellers. Le visiteur repart avec des pistes au lieu d'une impasse.
Côté back-office, vous disposez enfin d'un tableau de bord des requêtes perdues : chaque recherche à zéro résultat est agrégée, comptée et classée par volume. D'un clic, vous rattachez une requête à un produit, une catégorie ou une URL — en simple suggestion affichée sur la page, ou en redirection automatique. Et parce qu'un visiteur peut chercher un produit que vous n'avez pas encore, un formulaire « prévenez-moi » en opt-in RGPD capture son email : le jour où vous mappez sa requête, vous le prévenez d'un clic. Architecture sans Composer ni framework, JS vanilla, compatible PrestaShop 8 et 9, multiboutique et sur les cinq langues du catalogue.
---
### Module Recherches Sauvegardées & Alertes Nouveaux Produits PrestaShop 8/9
_Page produit :_
_PrestaShop · SKU DF-SAVEDSEARCH-FR · 99,00 €_
**Vos clients enregistrent leurs recherches et reçoivent une alerte email dès qu'un nouveau produit correspond. Anti-doublon, opt-in RGPD, désinscription en un clic, digest cron auto-hébergé. Un canal de réengagement sans effort.**
Le module Recherches Sauvegardées & Alertes transforme chaque recherche de votre boutique PrestaShop en canal de réengagement. Vos clients enregistrent une combinaison de critères — mots-clés, catégorie, fabricant, fourchette de prix, disponibilité — et reçoivent automatiquement un email dès qu'un nouveau produit correspondant est mis en ligne.
Conçu pour être respectueux de l'attention de vos clients et de leurs données : l'alerte email est en opt-in explicite (décoché par défaut), la désinscription se fait en un clic sans connexion, et un journal anti-doublon garantit qu'un client n'est notifié que des produits publiés _après_ la sauvegarde de sa recherche, jamais deux fois pour le même produit. Le digest quotidien ou hebdomadaire est envoyé par une tâche cron auto-hébergée, sans aucun service externe.
---
### Recherche Sémantique IA — Module PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU dfvectorsearch · 149,00 €_
**Vos clients trouvent le bon produit par le sens, pas seulement par mot-clé. Autocomplete, page de résultats et bloc Vous aimerez aussi partagent le même classement sémantique par embeddings IA. Moins de « aucun résultat », plus de conversions.**
---
### Assistant de Choix Produit — Guide d'Achat Interactif Module Prestashop 8 & 9
_Page produit :_
_PrestaShop · SKU dffinder · 99,00 €_
**Questionnaire de choix guidé pour PrestaShop : le visiteur répond à quelques questions et arrive sur une sélection de produits filtrée. Builder drag-and-drop, résultats natifs, multiboutique et multilingue.**
---
### Produit en avant par catégorie Module Prestashop 8 & 9
_Page produit :_
_PrestaShop · SKU dfcategoryhighlight · 59,00 €_
**Mettez en valeur un produit de votre choix dans chaque catégorie : bordure de couleur configurable, flag « Bon plan ! » personnalisable et épinglage automatique en première position. Compatible PrestaShop 8 et 9, sans surcharge de template.**
---
### Page 404 Intelligente PrestaShop 8 & 9 — Suggestions Produits & Redirections 301
_Page produit :_
_PrestaShop · SKU DF-404SMART · 59,00 €_
**Transformez vos pages 404 en pages de conversion. Le module analyse l'URL cassée, suggère les produits les plus proches, préremplit la recherche et vous permet de créer une redirection 301 en un clic depuis le journal des 404.**
---
### Module Lecture Audio Produit Text-to-Speech PrestaShop 8/9
_Page produit :_
_PrestaShop · SKU DF-AUDIOPRODUCT-PL · 79,00 €_
**Ajoutez un bouton « Écouter la description » sur vos fiches produit : synthèse vocale gratuite dans le navigateur ou voix premium OpenAI, Google et ElevenLabs, vitesse réglable de 0,75× à 2× et cache MP3 invalidé automatiquement. Un vrai plus accessibilité (EAA) et confort mobile.**
## Vos fiches produit prennent la parole
Une part croissante de vos visiteurs préfère écouter plutôt que lire : sur mobile, en déplacement, ou parce qu'une déficience visuelle, une dyslexie ou une fatigue oculaire rend la lecture difficile. Ce module ajoute un lecteur audio élégant sur chaque fiche produit : un clic sur « Écouter la description » et le nom, la description courte et la description longue sont lus à voix haute.
## Quatre moteurs de synthèse vocale, dont un 100 % gratuit
Par défaut, le module utilise la Web Speech API du navigateur : aucune clé API, aucun coût, la voix est générée directement sur l'appareil du visiteur. Pour une qualité studio, basculez en un clic vers OpenAI TTS (tts-1, tts-1-hd, gpt-4o-mini-tts), Google Cloud Text-to-Speech (voix Neural2) ou ElevenLabs (modèle multilingue). Un bouton de test intégré valide votre clé API avant la mise en production.
## Cache intelligent : un seul MP3 par produit et par langue
Avec les moteurs premium, l'audio est généré une seule fois, au premier clic, puis mis en cache sur votre serveur et servi avec les en-têtes HTTP appropriés (ETag, 304). Le réglage de vitesse s'applique côté navigateur : un même fichier couvre toutes les vitesses de lecture. Le cache est invalidé automatiquement dès qu'un produit est modifié, avec durée de vie optionnelle et purge manuelle. Votre coût API est donc borné et prévisible : au maximum un fichier par produit et par langue.
## Pensé accessibilité et confort mobile
Le lecteur respecte les bonnes pratiques d'accessibilité attendues à l'ère de l'European Accessibility Act : bouton avec états ARIA, annonces via aria-live pour les lecteurs d'écran, navigation clavier complète, respect de prefers-reduced-motion et interface adaptée au tactile. Il complète parfaitement une démarche de mise en conformité EAA de votre boutique.
## Administration complète
Depuis le back-office : choix du moteur et de la voix, vitesse par défaut, position d'affichage (sous le bloc d'achat ou dans les actions produit), contenu lu (description courte et/ou longue), limite de caractères pour maîtriser les coûts, durée de vie du cache. Un onglet dédié liste tous les audios générés avec produit, langue, taille, nombre de lectures, suppression unitaire, en masse ou purge totale, et un panneau de statistiques (fichiers, espace disque, lectures totales).
---
### DataFirefly Glossaire SEO — Lexique de termes métier, infobulles automatiques dans vos descriptions et maillage interne vers vos produits pour PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-DFGLOSSARY · 69,00 €_
**Créez un glossaire de vos termes métier : chaque occurrence dans vos descriptions produits, catégories et pages CMS devient un lien avec infobulle vers une page de définition indexable, qui renvoie elle-même vers vos produits. Maillage interne sémantique bidirectionnel, sans IA, sans abonnement.**
---
### Module Documents & Téléchargements PrestaShop 8 & 9 — Notices, Fiches Techniques, Certificats CE en Fiche Produit + Page Centrale Indexable
_Page produit :_
_PrestaShop · SKU DF-DOWNLOADCENTER-FR · 89,00 €_
**Rattachez notices, manuels, fiches techniques et certificats CE à vos produits. Onglet dédié en fiche produit, page centrale indexable avec recherche et filtres, compteur de téléchargements. PrestaShop 8 et 9, multiboutique, 5 langues, sans dépendance.**
---
### Module Questions/Réponses Produit PrestaShop 8/9 — Q&R avec Rich Snippets QAPage
_Page produit :_
_PrestaShop · SKU DF-PRODUCTQA-FR · 79,00 €_
**Un bloc Questions/Réponses complet sur vos fiches produit : formulaire public, modération en back-office, réponse officielle du marchand, réponses de la communauté, votes d'utilité et données structurées QAPage pour décrocher les rich snippets Google.**
---
### Module Produits Tendances & Recherches Populaires PrestaShop 8/9
_Page produit :_
_PrestaShop · SKU DF-TRENDING-FR · 59,00 €_
**Widget tendances pour PrestaShop 8 et 9 : recherches populaires du moment, produits en accélération de ventes et section « en ce moment » auto-générée, avec tableau de bord back-office.**
---
### Commande d'Échantillons Produit — Relance & Suivi de Conversion (PrestaShop 8 & 9)
_Page produit :_
_PrestaShop · SKU DF-SAMPLES-FR · 129,00 €_
**Ajoutez un bouton « Commander un échantillon » (gratuit ou payant) sur vos fiches produit, limitez les demandes par client, suivez la conversion échantillon → achat et relancez automatiquement par email avec un bon de réduction.**
---
### Module Recherche par Véhicule PrestaShop 8 & 9 — Compatibilité Pièces Auto, Sélecteur Année/Marque/Modèle & Mon Garage
_Page produit :_
_PrestaShop · SKU DF-FITMENTFINDER-FR · 129,00 €_
**Vos clients trouvent les produits compatibles avec leur véhicule ou leur appareil : sélecteur Marque / Modèle / Année / Motorisation en cascade, « Mon garage » mémorisé, vérification de compatibilité en fiche produit et tableau de correspondances. Pièces auto, cartouches, coques, pièces détachées. PrestaShop 8 et 9, import CSV, 5 langues.**
---
### Module Produits Récemment Consultés PrestaShop 8/9
_Page produit :_
_PrestaShop · SKU DF-RECENTLYVIEWED-FR · 59,00 €_
**Historique de navigation serveur, fusion invité vers client à la connexion, badges de baisse de prix et tableau de bord analytique. Le bloc « récemment consultés » qui convertit vraiment, compatible full page cache et RGPD.**
---
### Module Dark Mode PrestaShop 8/9 — Mode sombre automatique
_Page produit :_
_PrestaShop · SKU DF-DARKMODE-FR · 59,00 €_
**Mode sombre automatique pour PrestaShop 8 et 9 : détection de la préférence système, mémorisation du choix visiteur, génération automatique de palette sombre et toggle plaçable où vous voulez. Sans modification de thème.**
---
### Module Quick View PrestaShop 8/9 — Aperçu Rapide Produit
_Page produit :_
_PrestaShop · SKU DF-QUICKVIEW-FR · 79,00 €_
**Une modale d'aperçu rapide moderne sur vos pages de catégorie : galerie d'images, sélection des déclinaisons, ajout au panier en AJAX et préchargement au survol. Vos clients achètent sans jamais quitter la liste.**
---
### Module Barre de Navigation Mobile PrestaShop 8/9
_Page produit :_
_PrestaShop · SKU DF-MOBILENAV-FR · 79,00 €_
**Barre d'onglets fixe en bas de l'écran type application native pour PrestaShop 8 et 9 : accueil, recherche, panier, favoris et compte, avec badges de compteur en temps réel.**
---
### Règle de taxe par défaut automatique à la création produit — PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-AUTOTAX-PL · 49,00 €_
**Appliquez automatiquement votre groupe de taxes à chaque nouveau produit PrestaShop, au lieu de « Aucune taxe ». Compatible page produit v2, multiboutique, avec mode « ne remplacer que si vide ».**
---
### Essayage virtuel IA pour WooCommerce
_Page produit :_
_WordPress / WooCommerce · SKU DF-GTO-WP · 129,00 €_
**Vos clientes chargent une photo ou utilisent leur webcam et se voient porter le vêtement, grâce au modèle Google Vertex AI Virtual Try-On. Moins de retours, plus de conversions.**
---
### Essayage Virtuel IA pour Shopware 6
_Page produit :_
_Shopware · SKU DF-SWVTO-FR · 189,00 €_
**Un widget d'essayage virtuel IA sur vos fiches produit Shopware. Le client se voit porter l'article grâce à Google Vertex AI, sans studio ni mannequin.**
---
### Module Essayage Virtuel IA (Try-On) pour PrestaShop
_Page produit :_
_PrestaShop · SKU DF-DFGOOGLETRYON · 189,00 €_
**Widget d'essayage virtuel IA sur vos fiches produit, propulsé par Google Vertex AI Try-On. Upload photo ou caméra, 100% server-side, consentement RGPD, watermark SynthID, plafonds anti-coûts. PrestaShop 8 et 9.**
dfgoogletryon ajoute un widget d'essayage virtuel directement sur vos fiches produit PrestaShop 8 et 9. Le client téléverse une photo (ou utilise sa caméra) et se voit porter le vêtement, grâce au modèle génératif Google Vertex AI Virtual Try-On. Tous les appels à Google sont proxifiés côté serveur : la clé du compte de service n'atteint jamais le navigateur. Consentement RGPD obligatoire, photos non stockées, watermark SynthID, garde-fous anti-coûts par session — le tout sans toucher au code de votre thème.
---
### Connecteur Axonaut pour WooCommerce
_Page produit :_
_WordPress / WooCommerce · SKU DF-AXONAUT-WC · 89,00 €_
**Synchronisez automatiquement vos commandes WooCommerce avec Axonaut : factures ou devis, sociétés et contacts, avoirs sur remboursement, import de l'historique. Compatible HPOS, sans Composer.**
Le **Connecteur Axonaut pour WooCommerce** relie votre boutique à l'ERP/CRM français Axonaut et supprime la ressaisie : chaque commande devient une facture ou un devis, chaque client une société avec son contact, et chaque remboursement un avoir.
Le traitement s'effectue en arrière-plan via Action Scheduler, sans impact sur le checkout, et reste idempotent : une commande n'est jamais synchronisée deux fois. Compatible HPOS, sans dépendance Composer sur votre serveur.
---
### DF Translate Pro — Traduction multilingue à l'échelle pour WordPress & WooCommerce
_Page produit :_
_WordPress / WooCommerce · SKU DF-TRANSLATE-PRO-FR · 99,00 €_
**L'add-on Pro de DF Translate : langues illimitées, traduction en masse avec estimation du coût, autopilote à diff intelligent, mémoire de traduction, glossaire, produits variables WooCommerce, e-mails de commande dans la langue du client, export/import XLIFF et WP-CLI. Toujours avec votre propre clé IA.**
---
### DF Translate — Traduction multilingue IA pour WordPress & WooCommerce (gratuit)
_Page produit :_
_WordPress / WooCommerce · SKU DF-TRANSLATE-FR_
**Rendez votre site WordPress et votre boutique WooCommerce réellement multilingues : contenu réel dupliqué par langue, traduction par IA avec votre propre clé (Claude, DeepL, OpenAI, LibreTranslate), hreflang, éditeur côte à côte et migration Polylang en 1 clic. 100 % gratuit, 2 langues.**
---
### Carrousel d'Avis Google pour Shopware 6
_Page produit :_
_Shopware · SKU DF-REVIEWS-CAROUSEL-SW-FR · 89,00 €_
**Affichez vos avis Google en carrousel élégant dans votre storefront Shopware 6. Schema.org JSON-LD automatique, cache intelligent, thèmes Light & Dark, responsive, swipe — zéro dépendance frontend, aucun build administration.**
---
### Mise à jour de prix en masse - Module Prestashop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-PRICEUP-PL · 99,00 €_
**Modifiez tous vos prix en un clic : règles par marge, catégorie, marque ou fournisseur, arrondis psychologiques X,90 €, planification automatique, prévisualisation avant application et rollback complet.**
## Changez tous vos prix sans passer des heures dans le back-office
Une hausse fournisseur, une nouvelle politique de marge, une opération saisonnière : modifier les prix produit par produit est long et risqué. **Mise à jour de prix en masse** applique vos changements de tarifs à tout ou partie du catalogue en une seule opération, avec une prévisualisation complète avant validation et un rollback en un clic si le résultat ne convient pas.
## Des règles de prix précises
Ciblez le catalogue entier, une catégorie (avec ou sans ses sous-catégories), une marque ou un fournisseur. Choisissez ensuite l'opération : augmentation ou baisse en pourcentage, en montant fixe, calcul du prix à partir d'une marge sur le prix d'achat, ou fixation d'un prix précis.
## Arrondis psychologiques automatiques
Terminez systématiquement vos prix en X,90 €, X,95 €, X,99 € ou X,50 €. L'arrondi peut s'appliquer sur le prix TTC affiché en boutique (le module recalcule alors le prix HT correspondant selon le taux de TVA du produit) pour un affichage vitrine parfaitement maîtrisé.
## Planification
Programmez une règle pour qu'elle s'exécute chaque jour, chaque lundi ou le 1er de chaque mois via une simple tâche cron. Idéale pour appliquer automatiquement une revalorisation mensuelle sans y penser.
## Prévisualisation et rollback
Avant toute application, une fenêtre de prévisualisation affiche le nombre de produits concernés et le détail ancien prix / nouveau prix. Chaque application (manuelle ou planifiée) crée un point de restauration : un clic suffit pour revenir aux prix précédents, y compris les impacts de déclinaisons et les prix spécifiques.
---
### Connecteur Axonaut PrestaShop — Synchronisation CRM/ERP (clients, factures, devis)
_Page produit :_
_PrestaShop · SKU DF-AXONAUT · 129,00 €_
**Synchronisez automatiquement vos clients, commandes et produits PrestaShop avec Axonaut, le logiciel de gestion français. Factures ou devis générés à la validation de commande, contacts et sociétés à jour, file de synchronisation avec relance automatique. Compatible PrestaShop 8 et 9.**
---
### Connecteur Sellsy PrestaShop – Synchronisation CRM/ERP (clients, commandes, factures)
_Page produit :_
_PrestaShop · SKU DF-SELLSY · 129,00 €_
**Synchronisez automatiquement vos clients, produits, commandes, factures et avoirs PrestaShop vers Sellsy, le CRM/ERP SaaS français, via l'API Sellsy v2. Compatible PrestaShop 8 et 9.**
---
### Sync Etsy PrestaShop — Synchronisation Produits, Stocks & Commandes
_Page produit :_
_PrestaShop · SKU DF-ETSY · 129,00 €_
**Reliez votre boutique PrestaShop à votre shop Etsy : export de vos produits en listings, mise à jour automatique des stocks, et import des commandes Etsy directement dans PrestaShop. Pensé pour les créateurs et artisans qui vendent sur les deux canaux.**
---
### Module Prix « À partir de » — Remises sur la quantité en liste produit (PrestaShop 8 & 9)
_Page produit :_
_PrestaShop · SKU DF-FROMPRICE-PL · 49,00 €_
**Affichez « À partir de {prix} » et le prix par quantité le moins cher dans vos listes produit dès qu'une remise sur la quantité existe. Le levier de vente en gros rendu visible avant le clic.**
---
### Export Commandes PrestaShop vers Logisticien / 3PL — CSV, EDI, API + Import Tracking
_Page produit :_
_PrestaShop · SKU dforderdispatch · 99,00 €_
**Envoyez automatiquement vos commandes PrestaShop à votre logisticien ou préparateur (3PL) au format CSV, EDI ou API, sur planning, puis réimportez les numéros de suivi en un clic. Compatible PrestaShop 8 et 9.**
Vous confiez la préparation et l'expédition de vos commandes à un prestataire logistique externe (3PL), un transporteur ou un WMS ? **Order Dispatch** automatise tout le flux : il exporte vos commandes PrestaShop au format attendu par votre partenaire, les lui transmet automatiquement sur un planning défini, puis réimporte les numéros de suivi dès que les colis partent — sans aucune saisie manuelle.
Le module gère les trois formats les plus demandés par les logisticiens (**CSV**, **fichier plat EDI** et **API JSON**) et les modes de transfert standards du secteur (**FTP, SFTP, API HTTP** ou téléchargement manuel). Un cron sécurisé par jeton déclenche l'export à intervalle régulier, et le réimport des trackings s'effectue par upload CSV, récupération FTP/URL ou webhook poussé par votre prestataire.
---
### Import Export CSV & XML PrestaShop 8 & 9 — Mapping Visuel, Imports Planifiés FTP/SFTP
_Page produit :_
_PrestaShop · SKU DF-CSVPRO-FR · 129,00 €_
**Importez et exportez tout votre catalogue PrestaShop en CSV ou XML, avec un mapping visuel des colonnes, des profils réutilisables et des imports planifiés depuis FTP, SFTP ou une URL.**
---
### Module Export ERP PrestaShop 8/9 — Sage 100, EBP, Cegid, Codial
_Page produit :_
_PrestaShop · SKU DF-ERPBRIDGE-FR · 129,00 €_
**Export planifié des commandes, clients et stock PrestaShop vers Sage 100, EBP, Cegid, Codial ou un format générique CSV / XML / JSON — livré par FTP ou e-mail, piloté par cron. Fini la ressaisie manuelle dans votre logiciel de gestion.**
---
### Import Fournisseurs & Dropshipping PrestaShop 8 & 9 — Flux CSV, XML, JSON
_Page produit :_
_PrestaShop · SKU DF-SUPPLIERFEED-FR · 99,00 €_
**Importez et synchronisez plusieurs catalogues fournisseurs (CSV, XML, JSON), appliquez vos marges par fournisseur et catégorie, gardez le stock à jour toutes les heures et laissez la priorité fournisseur trancher les doublons EAN.**
---
### Synchronisation Google Sheets Bidirectionnelle — Éditez prix, stock & titres dans un Sheet, sync auto vers PrestaShop (PrestaShop 8 & 9)
_Page produit :_
_PrestaShop · SKU DF-SHEETSYNC-FR · 89,00 €_
**Éditez prix, quantités et titres produits directement dans un Google Sheet : le module synchronise automatiquement les changements vers PrestaShop, et renvoie vers le Sheet toute modification faite en back-office. Détection intelligente des conflits, cron sécurisé, zéro dépendance. Compatible PrestaShop 8 & 9.**
---
### Module Swatches Variantes Photo & Stock PrestaShop 8/9
_Page produit :_
_PrestaShop · SKU DF-VARIANTSWATCH-FR · 89,00 €_
**Remplacez les listes déroulantes de déclinaisons par des vignettes photo cliquables, avec aperçu galerie au survol et stock visible par variante. Le levier de conversion des boutiques mode, déco et cosmétique.**
Le module Swatches Variantes Photo transforme la sélection de déclinaisons de vos fiches produit PrestaShop : fini les listes déroulantes textuelles, vos clients choisissent leur couleur, taille ou matière en cliquant sur des vignettes visuelles. Au survol d'une vignette, l'image principale de la galerie affiche instantanément la photo de la variante correspondante, et chaque vignette indique sa disponibilité en stock.
Zéro configuration obligatoire : le module dérive automatiquement les vignettes depuis les photos de vos combinaisons existantes. Vous pouvez ensuite affiner en uploadant des vignettes dédiées ou des codes couleur par attribut. Conçu pour PrestaShop 8 et 9, compatible avec les thèmes Classic, Hummingbird et la plupart des thèmes premium, entièrement navigable au clavier.
---
### Migration WooCommerce vers PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-MIGRATEWOO · 129,00 €_
**Migrez votre boutique WooCommerce vers PrestaShop 8 ou 9 : catégories, tags, attributs globaux, produits simples et variables avec combinaisons, images, clients et commandes (HPOS inclus). Moteur par lots sans timeout, relançable, avec mode simulation.**
---
### Auto-complétion d'Adresse Shopware 6 — Multi-Provider BAN & Google Places
_Page produit :_
_Shopware · SKU DF-ADDRAC-SW-FR · 69,00 €_
**Auto-complétion d'adresse pour Shopware 6.6/6.7 : vos clients tapent trois lettres, le plugin remplit rue, code postal, ville et pays. BAN (gratuit, France) et Google Places (mondial) inclus, architecture extensible, clé API protégée côté serveur.**
---
### DataFirefly Server-Side — Tracking de conversions Shopware (gratuit)
_Page produit :_
_Shopware · SKU DF-SERVERSIDE-SW_
**Le plugin Shopware gratuit du service DataFirefly Server-Side Tracking : votre conversion d'achat envoyée de serveur à serveur, signée HMAC, respectueuse du consentement, et compatible avec notre plugin DataFirefly Cookie Consent (Google Consent Mode v2).**
---
### Passeport Numérique Produit (DPP) — Conformité ESPR pour PrestaShop
_Page produit :_
_PrestaShop · SKU DF-DFDPP-PS · 59,00 €_
**Le passeport numérique produit exigé par le règlement européen ESPR, directement dans PrestaShop 8 et 9 : QR code par produit, registre des composants, traçabilité du cycle de vie et score de conformité automatique.**
---
### DataFirefly Server-Side — Tracking de conversions PrestaShop (gratuit)
_Page produit :_
_PrestaShop · SKU DF-SERVERSIDE-PS_
**Le module PrestaShop gratuit du service DataFirefly Server-Side Tracking : votre conversion d'achat envoyée de serveur à serveur, signée HMAC, respectueuse du consentement, et compatible nativement avec notre module DataFirefly Cookie Manager (Google Consent Mode v2).**
---
### DataFirefly Server-Side — Tracking WooCommerce client + serveur (gratuit)
_Page produit :_
_WordPress / WooCommerce · SKU DF-SERVERSIDE_
**Le connecteur WooCommerce gratuit du service DataFirefly Server-Side Tracking : tout votre tunnel envoyé client + serveur, dédupliqué, respectueux du consentement, et compatible nativement avec notre module DataFirefly Cookie Consent v2.**
---
### AI Act Ready — Conformité EU AI Act pour PrestaShop 8 / 9
_Page produit :_
_PrestaShop · SKU DF-AIACT-FR · 229,00 €_
**Structurez votre mise en conformité EU AI Act depuis PrestaShop : inventaire des systèmes IA, registre guidé, obligations sourcées, documents PDF en 6 langues et export auditeur. Un outil qui vous fait gagner des semaines de structuration — il ne garantit pas votre conformité.**
Le règlement européen sur l'intelligence artificielle (Règlement UE 2024/1689) s'applique progressivement, avec les obligations de transparence de l'Art. 50 à compter du 2 août 2026. Si votre boutique PrestaShop utilise un chatbot, un moteur de recommandation, un outil de génération de contenu ou de scoring, vous avez des obligations. AI Act Ready vous aide à les inventorier, les documenter et les structurer directement dans votre back-office, et à générer vos documents de conformité en 6 langues (FR, EN, ES, DE, IT, PT).
Le module structure votre démarche et vous fait gagner des semaines de travail. Il ne remplace pas un avocat et ne garantit pas votre conformité : la classification de risque est une indication opérationnelle, pas un avis juridique opposable. Vos données restent 100% sur votre serveur. Compatible PrestaShop 8, multiboutique, validé PrestaShop Addons (0 finding sur 10 catégories).
_AI Act Ready est un outil de structuration, pas un certificat de conformité. La conformité dépend de vos pratiques réelles. Conformément à l'Art. 26 du Règlement (UE) 2024/1689, le déployeur (le marchand) reste responsable de l'usage de ses systèmes IA. Pour un système à risque élevé, l'avis d'un juriste qualifié est nécessaire._
---
### DataFirefly Social Connect — Connexion sociale & statistiques pour WooCommerce
_Page produit :_
_WordPress / WooCommerce · SKU DF-SOCIALCONNECT-WC-FR · 49,00 €_
**Six fournisseurs sociaux (Google, Apple, Facebook, Microsoft, LinkedIn, X) avec tableau de bord statistique complet, attribution des commandes, test A/B et anti-fraude — pour WooCommerce.**
---
### DataFirefly Live Counters
_Page produit :_
_WordPress / WooCommerce · SKU DF-DFLC-WP-ES · 49,00 €_
**Compteurs animés WooCommerce — clients, expéditions, abonnés, KPIs — qui restent à jour même derrière LiteSpeed ou WP Rocket. Bloc Gutenberg, widget, shortcode.**
---
### Return Portal + Auto-Label pour WooCommerce
_Page produit :_
_WordPress / WooCommerce · SKU DFRETURNPORTAL-FR · 79,00 €_
**Portail de retour client self-service avec génération automatique d'étiquettes multi-transporteur (Colissimo, Mondial Relay, Chronopost, UPS, DPD), workflow d'inspection admin et moteur de résolution (remboursement, avoir bonifié ou remplacement) pour WooCommerce 8.0+.**
---
### Se connecter en tant que client Pro — Module PrestaShop 8 / 9
_Page produit :_
_PrestaShop · SKU DF-LOGINAS · 49,00 €_
**Connectez-vous au compte de n'importe quel client en un clic depuis le back-office PrestaShop 8 / 9. Liens signés et expirables, bannière de sortie, magic link sans mot de passe, journal d'audit RGPD et restrictions par profil. L'outil indispensable du SAV et du débogage de commandes.**
---
### Module Commande Rapide B2B PrestaShop 8 & 9 — Saisie SKU, Import CSV & Réachat
_Page produit :_
_PrestaShop · SKU DF-QUICKORDER-FR · 89,00 €_
**Une page de commande rapide pour vos clients pros : saisie par référence avec autocomplétion, collage Excel, import CSV, listes de réachat et recommande de commande en un clic. Tout est ajouté au panier d'un coup. PrestaShop 8 et 9, multiboutique, 5 langues, sans dépendance.**
---
### DataFirefly Précommande & Liste d'attente — Shopware 6
_Page produit :_
_Shopware · SKU DF-PREORDER-SW-FR · 69,00 €_
**Alerte e-mail de retour en stock (liste d'attente) avec double opt-in optionnel, plus badge de précommande et date d'expédition prévue sur les fiches produit. Détection du restock en temps réel et filet de sécurité planifié. Shopware 6.5, 6.6 et 6.7.**
Shopware n'a pas de fonction native « Prévenez-moi quand c'est de nouveau en stock » : DfPreorder comble ce manque et ajoute un mode précommande léger. Sur chaque fiche produit en rupture (closeout, stock disponible épuisé), un formulaire d'inscription apparaît automatiquement. Le client laisse son e-mail et reçoit une alerte dans sa propre langue dès que le produit revient. Le retour en stock est détecté de deux façons complémentaires : en temps réel à chaque écriture produit, et via un balayage planifié toutes les 15 minutes qui rattrape les mises à jour de stock faites en SQL direct (passage de commande, imports ERP). Les deux chemins convergent vers un traitement idempotent, donc aucun e-mail en double. Le double opt-in optionnel et la suppression automatique des données après notification rendent la liste d'attente conforme au RGPD. Le mode précommande affiche un badge et la date d'expédition prévue via des champs personnalisés produit. Compatible Shopware 6.5, 6.6 et 6.7, multilingue (EN, DE, FR, ES, IT) et multi-canaux de vente.
---
### Suivi DHL Automatique & Multi-Transporteurs — Polling API temps réel et statuts auto (PrestaShop 8 & 9)
_Page produit :_
_PrestaShop · SKU DF-DHLTRACK-FR · 59,00 €_
**Suivi DHL eCommerce & Express en temps réel via l'API DHL, synchronisation automatique des statuts de commande, et page de suivi brandée pour 19 transporteurs (Colissimo, Chronopost, Mondial Relay, DPD, UPS, Poste Italiane, Correos, bpost…).**
---
### Compteur de Ventes — Nombre de ventes affiché sur la fiche produit (PrestaShop 8 & 9)
_Page produit :_
_PrestaShop · SKU DF-SALESCOUNT · 29,00 €_
**Affichez « Déjà vendu 142 fois » sur vos fiches produit et rassurez l'acheteur avec une preuve sociale basée sur vos vraies ventes.**
---
### Popularité Panier — Compteur de paniers sur la fiche produit (PrestaShop 8 & 9)
_Page produit :_
_PrestaShop · SKU DF-CARTPOP · 29,00 €_
**Affichez sur chaque fiche produit le nombre de paniers contenant l'article (ex : « Dans + de 20 paniers »). Un levier de preuve sociale et d'urgence, avec seuil paramétrable, fenêtre temporelle et cache intégré. Compatible PrestaShop 8 et 9, multilingue, sans dépendance.**
Le module **Popularité Panier** ajoute un badge de preuve sociale sur la fiche produit : il compte le nombre de paniers contenant le produit et affiche un message du type « Dans + de 20 paniers » dès que le seuil que vous fixez est atteint. Un déclencheur d'urgence simple, honnête et basé sur vos vraies données de paniers.
Le comptage s'appuie directement sur les paniers de la boutique, dédoublonnés par panier et limités à la boutique courante en multiboutique. Vous choisissez le seuil d'affichage, la fenêtre temporelle prise en compte, le mode d'affichage (palier arrondi ou nombre exact) et l'emplacement du badge sur la fiche. Un cache intégré évite tout recalcul à chaque vue produit.
Développé selon les standards DataFirefly : aucune dépendance Composer, rendu serveur sans JavaScript externe, compatible PrestaShop 8 et 9, et entièrement traduisible (textes fournis en français, anglais, espagnol, allemand et italien).
---
### Traffic Radar — Trafic temps réel & crawlers IA pour PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-TRAFFICRADAR · 49,00 €_
**Transformez votre back-office en tour de contrôle du trafic : visiteurs en direct, séparation nette humains / robots / crawlers IA, graphiques, heatmap et contrôle des crawlers IA. Sans cron, conforme RGPD.**
Traffic Radar affiche en temps réel qui visite votre boutique PrestaShop et sépare les vrais visiteurs des robots et des crawlers IA. Compteur en ligne instantané, graphiques humains contre bots, heatmap d'affluence, top crawlers IA, flux d'activité live, contrôle des crawlers IA via robots.txt et export CSV. Aucune dépendance externe, aucun cron requis, IP toujours hachées.
---
### Garantie Légale de Conformité 2 ans – Module PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-GLC-PT · 59,00 €_
**Affichez automatiquement les mentions légales obligatoires de garantie (conformité 2 ans, vices cachés, extension après réparation) sur vos fiches produits PrestaShop 8 et 9. Textes pré-rédigés et éditables en 5 langues.**
Mettez vos fiches produits en conformité avec les obligations d'information sur la garantie légale en France. Le module affiche, là où vous le souhaitez sur la fiche produit, la garantie légale de conformité (2 ans), la garantie des vices cachés et l'extension de garantie de 6 mois après réparation — avec des textes pré-rédigés et entièrement personnalisables en français, anglais, espagnol, allemand et italien. Compatible PrestaShop 8 et 9, multiboutique, sans Composer.
---
### Disponibilité Pièces Détachées PrestaShop 8/9 – Module Obligation Légale (L111-4)
_Page produit :_
_PrestaShop · SKU DF-SPAREPARTS-FR · 89,00 €_
**Affichez la durée de disponibilité des pièces détachées sur la fiche produit, la confirmation de commande et la facture PDF. Mise en conformité avec l'article L111-4 du Code de la consommation, pour PrestaShop 8 et 9, en mono et multiboutique.**
## Conformité à l'obligation d'information sur les pièces détachées
L'article L111-4 du Code de la consommation impose d'informer le consommateur, avant l'achat et par écrit lors de l'achat, de la période pendant laquelle ou de la date jusqu'à laquelle les pièces détachées indispensables sont disponibles sur le marché. Ce module gère cette obligation de bout en bout pour PrestaShop 8 et 9.
## Affichée au bon endroit, au bon moment
- Encart lisible sur la fiche produit (information précontractuelle).
- Reprise sur la page de confirmation de commande et sur la facture PDF (confirmation écrite lors de l'achat).
## Simple à gérer
Un onglet dédié sur chaque fiche produit, avec aperçu en direct, et une fonction d'affectation en masse par catégories ou sur tout le catalogue. Multiboutique, sans Composer ni framework.
---
### Sécurité Jouets & Conformité CE (Avertissements d'Âge) PrestaShop
_Page produit :_
_PrestaShop · SKU DF-DFTOYSAFETY · 89,00 €_
**Affichez les mentions CE, les avertissements de sécurité et les restrictions d'âge obligatoires sur vos fiches jouets, conformément à la directive européenne 2009/48/CE relative à la sécurité des jouets.**
---
### Origine France & Made in UE — Badges + Filtres PrestaShop
_Page produit :_
_PrestaShop · SKU DF-MADEIN-PL · 59,00 €_
**Affichez des badges « Fabriqué en France / UE », des labels certifiés vérifiables (Origine France Garantie) et laissez vos clients filtrer par origine et certification. PrestaShop 8 & 9, multiboutique, FR/EN/ES/DE/IT.**
Mettez en avant la provenance de vos produits avec des badges d'origine clairs sur la fiche produit et dans les listes, des labels certifiés que vos clients peuvent vérifier, et des filtres boutique par origine et certification. Compatible PrestaShop 8 et 9, multiboutique, sans aucune dépendance.
---
### Multi-Entrepôt PrestaShop 8 & 9 — Routage Automatique des Commandes par Stock et Zone Géographique
_Page produit :_
_PrestaShop · SKU DF-WHR-FR · 189,00 €_
**Affectez chaque commande à l'entrepôt optimal, automatiquement, selon le stock réel et la zone de livraison. Trois stratégies de routage, stock par entrepôt, zéro dépendance externe.**
Multi-Entrepôt & Routage Stock affecte automatiquement chaque commande validée à l'entrepôt le plus pertinent, en croisant le stock réellement disponible et la zone géographique du client. Trois stratégies d'arbitrage, un stock indépendant par entrepôt et un pilotage complet depuis la fiche commande, sans aucune dépendance à une API externe.
---
### Assurance Colis PrestaShop 1.7, 8 & 9 — Upsell Assurance Transport au Checkout
_Page produit :_
_PrestaShop · SKU DF-PARCELINS-FR · 89,00 €_
**Un upsell d'assurance transport optionnelle affiché au moment du paiement. Le client coche, le montant s'ajoute au panier — montant fixe ou pourcentage. Compatible PrestaShop 1.7.6+, 8 et 9, multi-boutique et multilingue.**
---
### Expédition Partielle & Reliquats Automatiques (Backorder)
_Page produit :_
_PrestaShop · SKU DF-AVSPLIT-FR · 109,00 €_
**Expédiez immédiatement les articles en stock et placez automatiquement le reste en reliquat (backorder). Deux commandes reliées par la même référence, totaux recalculés au centime, port offert sur le reliquat. PrestaShop 8 et 9.**
---
### Liste de Naissance, Mariage & Cadeaux — PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-GIFTREG-IT · 129,00 €_
**Offrez à vos clients de vraies listes de naissance, mariage et cadeaux partagées : création depuis le compte client, lien public, réservation des cadeaux ajoutée au panier, suivi des cadeaux reçus et email au propriétaire. Compatible PrestaShop 8 & 9, multi-boutique et multi-langues.**
Vos clients vous réclament une liste de naissance ou une liste de mariage, mais PrestaShop n'en propose aucune nativement. Résultat : ils créent leur liste sur une plateforme tierce, et les cadeaux sont achetés… chez un concurrent.
Ce module ajoute à votre boutique un véritable système de **listes de cadeaux partagées** : naissance, mariage, anniversaire, crémaillère. Le client crée sa liste depuis son compte, y ajoute les produits de votre catalogue, définit les quantités souhaitées, puis partage un **lien public** avec ses proches.
Les invités consultent la liste, choisissent un cadeau et l'offrent en un clic : le produit est **réservé puis ajouté au panier**. À la validation de la commande, la réservation devient un cadeau confirmé et le propriétaire de la liste reçoit un email. Chaque produit affiche une barre de progression réservé / restant, pour éviter les doublons.
Côté technique, le module s'appuie sur des _ObjectModel_ et des contrôleurs front legacy pour une compatibilité PrestaShop 8 et 9 sans dépendance Symfony. Hooks utilisés : displayCustomerAccount, displayProductAdditionalInfo, actionFrontControllerSetMedia et actionValidateOrder. **Aucun override du cœur**, installation et désinstallation propres.
📖 **Documentation :**[Guide complet d'installation et d'utilisation](https://www.datafirefly.com/documentation/dfgiftregistry/).
---
### Module Cagnotte & Paiement Partagé PrestaShop — Cadeau Commun (PS 8/9)
_Page produit :_
_PrestaShop · SKU DF-GIFTPOT-FR · 129,00 €_
**Permettez à vos clients de financer un cadeau commun à plusieurs : cagnotte partageable par lien, paiement réel de chaque part, et bon de réduction automatique à la clôture. 100% natif PrestaShop 8 et 9.**
---
### Module Pourboire / Tip au Checkout PrestaShop 8 & 9 — Don Optionnel (% ou Montant Fixe)
_Page produit :_
_PrestaShop · SKU DF-TIP-FR · 79,00 €_
**Pourboire optionnel au panier et au checkout : pourcentage, montant fixe ou montant libre, intégré nativement à la commande (total, TVA, facture). Idéal artisans, créateurs et restauration. Sans dépendance.**
---
### Module Emballage Cadeau & Message Personnalisé PrestaShop 8/9
_Page produit :_
_PrestaShop · SKU DF-GIFTWRAP-FR · 59,00 €_
**Proposez l'emballage cadeau et une carte message personnalisée directement dans le tunnel de commande PrestaShop. Options d'emballage illustrées et payantes, message libre gravé sur la commande, frais intégrés proprement jusqu'à la facture. Compatible PrestaShop 8 et 9, multiboutique.**
---
### Module Demande de Devis B2B PrestaShop 8 & 9 — Panier en Devis PDF en 1 clic
_Page produit :_
_PrestaShop · SKU DF-EXPRESSQUOTE-FR · 69,00 €_
**Un bouton « Demander un devis » en pied de panier : le client B2B reçoit son devis PDF en un clic, sans créer de compte. PDF généré à la volée, emails automatiques client et boutique, suivi des devis dans le back-office. PrestaShop 8 et 9, multiboutique, 5 langues, sans dépendance.**
---
### Module Comparateur de Produits PrestaShop 8/9
_Page produit :_
_PrestaShop · SKU DF-COMPARATOR-FR · 59,00 €_
**Comparateur de produits côte à côte pour PrestaShop 8 et 9 : boutons automatiques, barre flottante, colonnes figées, surbrillance du meilleur prix et différences en un clic. Autonome, sans dépendance, multiboutique et 5 langues.**
Le module Comparateur de Produits ajoute à votre boutique PrestaShop un comparateur côte à côte complet et professionnel. Des boutons « Comparer » apparaissent automatiquement sur la page produit et dans les listes, et une page dédiée aligne les produits sélectionnés en colonnes pour une décision d'achat éclairée.
La page de comparaison fige l'en-tête et la première colonne, met en avant le meilleur prix avec un badge dédié et propose une bascule « afficher seulement les différences » qui masque les lignes identiques. Une barre flottante suit le client sur toute la boutique, et chaque comparaison génère une URL partageable. 100 % autonome, en JavaScript vanilla, sans aucune dépendance.
---
### Module Panier Sticky & Cross-sell IA PrestaShop 8/9
_Page produit :_
_PrestaShop · SKU DF-STICKYCART-FR · 89,00 €_
**Tiroir panier sticky en Ajax avec recommandations cross-sell issues de vos vraies commandes et re-classement IA optionnel. Plus de ventes additionnelles, zéro dépendance.**
Le module Panier Sticky & Cross-sell IA ajoute à votre boutique PrestaShop un tiroir panier latéral qui s'ouvre en Ajax, sans jamais recharger la page. Chaque ajout au panier devient une occasion de proposer des produits complémentaires pertinents et d'augmenter le panier moyen.
Les recommandations sont calculées à partir de vos commandes réelles — co-achat (market-basket) et affinité de catégorie — puis peuvent être affinées par une couche d'IA optionnelle qui réordonne les suggestions et rédige une courte raison personnalisée pour chaque produit. Le module reste pleinement fonctionnel sans aucune clé API : l'intelligence artificielle n'est qu'un renfort, jamais une dépendance.
---
### Plugin PWA & Notifications Push Shopware 6 — DfPwaPush : Web Push VAPID Auto-Hébergé, Manifest + Service Worker, Campagnes, Sans Dépendance
_Page produit :_
_Shopware · SKU DF-PWAPUSH-SW-FR · 99,00 €_
**Transformez votre boutique Shopware 6.5, 6.6 et 6.7 en PWA installable (manifest et service worker dynamiques, page hors-ligne, bannière d'installation) et envoyez des notifications Web Push entièrement auto-hébergées (VAPID, chiffrement RFC 8291) depuis un gestionnaire de campagnes intégré. Aucun service tiers, aucune dépendance Composer, aucun build : un seul codebase compatible 6.5 à 6.7.**
---
### Module ChatGPT Checkout PrestaShop 8 & 9 – Agentic Commerce Protocol (ACP)
_Page produit :_
_PrestaShop · SKU DF-ACP-PL · 99,00 €_
**Exposez votre catalogue et votre tunnel de commande aux agents IA (ChatGPT, Claude, Perplexity) via l'Agentic Commerce Protocol. 5 endpoints REST conformes, commande PrestaShop réelle, paiement délégué Stripe, webhooks. Compatible PrestaShop 8 & 9, multiboutique.**
Vos clients découvrent et achètent de plus en plus à l'intérieur des assistants IA. Ce module transforme votre boutique PrestaShop en backend de commerce agentique conforme à l'**Agentic Commerce Protocol (ACP)**, le standard ouvert porté par OpenAI et Stripe sur lequel s'appuie ChatGPT Instant Checkout.
L'agent parcourt votre catalogue via un flux authentifié, crée une session de paiement, sélectionne livraison et adresse, puis finalise l'achat — et une commande PrestaShop réelle est créée dans votre boutique.
---
### Recherche Visuelle par Image & Shop the Look IA
_Page produit :_
_PrestaShop · SKU DF-VISUALSEARCH-FR · 79,00 €_
**Vos clients cherchent par photo : ils glissent une image, le module retrouve instantanément les produits de votre catalogue les plus proches visuellement. Avec Shop the Look IA et un moteur agnostique (Voyage, Cohere, OpenAI, Mistral).**
---
### AI Returns Predictor
_Page produit :_
_PrestaShop · SKU DF-AIRP-FR · 79,00 €_
**AI Returns Predictor note chaque commande dès sa validation, calcule un score de risque de retour de 0 à 100 et alerte votre logistique avant l'expédition. Moteur heuristique transparent, couche IA Mistral optionnelle.**
## Anticipez les retours avant que le colis ne parte
AI Returns Predictor analyse chaque commande PrestaShop dès sa validation et lui attribue un score de risque de retour de 0 à 100. Le résultat s'affiche directement sur la fiche commande, et votre logistique est alertée par email lorsqu'une commande franchit le seuil de risque élevé.
- Score 0–100 et niveau Faible / Moyen / Élevé sur chaque commande
- Six facteurs explicables, sans boîte noire
- Tableau de bord logistique trié par risque
- Couche IA Mistral optionnelle avec repli automatique
---
### AI Size & Fit Advisor
_Page produit :_
_PrestaShop · SKU DF-SIZEFIT-FR · 79,00 €_
**Recommandez la bonne taille à partir des mensurations et de la morphologie de chaque client — là où le guide des tailles reste statique.**
AI Size & Fit Advisor transforme votre guide des tailles statique en un véritable conseiller. Le client saisit ses mensurations sur la fiche produit et reçoit instantanément la taille recommandée, avec un indice de confiance, une alternative et le détail mensuration par mensuration. À la clé : plus de conversions et moins de retours liés à une mauvaise taille.
---
### Synthèse IA des avis – Avantages / Inconvénients
_Page produit :_
_PrestaShop · SKU DF-RSYNTH-FR · 49,00 €_
**Le module lit des centaines d'avis et affiche automatiquement les Avantages et Inconvénients clés, dans la langue de chaque fiche.**
---
### Vérification des Emails Clients — Anti-faux comptes et nettoyage de base (PrestaShop 8 & 9)
_Page produit :_
_PrestaShop · SKU dfemailcheck · 49,00 €_
**Contrôlez la validité réelle des emails à l'inscription et supprimez en masse les clients dont l'adresse n'existe pas — sans jamais effacer un vrai client par erreur.**
Vérification des Emails Clients contrôle la délivrabilité réelle de chaque adresse email de votre boutique PrestaShop, repère les comptes dont l'email n'existe pas et vous permet de purger votre base en toute sécurité. Compatible PrestaShop 8 et 9.
---
### DataFirefly Frais de Paiement — Surcharge par moyen de paiement (PrestaShop 8 & 9)
_Page produit :_
_PrestaShop · SKU dfpaymentfees · 49,00 €_
**Ajoutez des frais (montant fixe et/ou pourcentage) à chaque moyen de paiement PrestaShop 8 et 9. Moteur de règles avec conditions par groupe client, pays, devise et montant de panier, gestion de la TVA, plafonds et seuil de gratuité. Frais affichés au checkout et ajoutés automatiquement à la commande.**
DataFirefly Frais de Paiement permet d'appliquer des frais supplémentaires à chaque moyen de paiement de votre boutique PrestaShop 8 ou 9. Facturez le surcoût réel d'un mode de règlement (paiement à la livraison, chèque, virement, carte…) ou incitez vos clients vers le moyen de paiement le moins coûteux pour vous.
Le module repose sur un **moteur de règles** complet : frais en **montant fixe et/ou en pourcentage**, base de calcul HT ou TTC avec ou sans les frais de port, **plafonds minimum et maximum** et **seuil de gratuité**. Chaque règle se cible finement par **groupe de clients**, **pays** de facturation, **devise** et **fourchette de montant de panier**, avec un système de priorités (la première règle correspondante s'applique).
Les frais sont **affichés au client pendant le tunnel de commande**, à côté de chaque moyen de paiement, puis **ajoutés automatiquement à la commande** à sa validation : totaux, facture et e-mail de confirmation sont mis à jour, et le détail HT/TTC est conservé pour votre comptabilité. Gestion de la **TVA** par règle de taxe configurable, prise en charge **multiboutique** et **multilingue**.
---
### DataFirefly Express Checkout — Apple Pay, Google Pay & Amazon Pay via Stripe (PrestaShop 8 & 9)
_Page produit :_
_PrestaShop · SKU dfexpresscheckout · 49,00 €_
**Affichez les boutons Apple Pay, Google Pay et Amazon Pay via Stripe sur la fiche produit, dans le panier et au checkout. Un seul Express Checkout Element, paiement en un geste, commande créée via webhook sécurisé. Compatible PrestaShop 8 et 9.**
DataFirefly Express Checkout ajoute le paiement par portefeuille (Apple Pay, Google Pay et Amazon Pay) à votre boutique PrestaShop 8 ou 9, propulsé par Stripe. Le client paie en un geste — sans saisir d'adresse ni de carte — directement depuis la fiche produit, le panier ou la page de paiement.
Le module s'appuie sur l'**Express Checkout Element** de Stripe : un seul composant qui détecte automatiquement les portefeuilles disponibles sur l'appareil du client et affiche les bons boutons. Le paiement est capturé immédiatement (ou en autorisation puis capture manuelle, au choix) et la commande est créée puis validée via un **webhook signé**, avec une logique **idempotente** qui évite toute double commande.
Aucune dépendance externe : client Stripe interne, clés gérées dans le back-office, mode Test et Live, et fichiers de traduction fournis en français, anglais, espagnol, allemand et italien.
---
### Facebook Dynamic Ads + Pixel PRO — Flux produits, Pixel & API Conversions (PrestaShop 8 & 9)
_Page produit :_
_PrestaShop · SKU dffbadspixel · 89,00 €_
**Exportez votre catalogue vers Facebook & Instagram (flux XML & CSV), suivez vos conversions avec le pixel et l'API Conversions, et reciblez vos visiteurs. Multi pays / langue / devise, règles d'exclusion, libellés personnalisés.**
Le module le plus complet pour diffuser et vendre vos produits sur Facebook et Instagram depuis votre boutique PrestaShop. Générez un flux catalogue de haute qualité (XML et CSV), installez le pixel Facebook et activez l'API Conversions pour un suivi fiable, et reciblez automatiquement vos visiteurs grâce au remarketing dynamique.
Conçu pour les gros catalogues (jusqu'à 200 000 produits) grâce à la génération par lots et à la mise en cache CRON, il offre un contrôle fin des données exportées : règles d'exclusion avancées, libellés personnalisés, mapping des catégories Google, frais de port réels et flux localisés par pays / langue / devise.
---
### Nutri-Score & valeurs nutritionnelles INCO — Logo officiel et tableau schema.org (PrestaShop 8 & 9)
_Page produit :_
_PrestaShop · SKU dfnutriscore · 49,00 €_
**Affichez le logo officiel Nutri-Score et un tableau nutritionnel INCO structuré sur vos fiches produit. Score calculé automatiquement selon l'algorithme 2023 (arrêté du 15 mars 2025), avec forçage manuel, badge sur les listings et données schema.org.**
---
### Préparation de commandes & Picking — Scan code-barres et bons de colisage (PrestaShop 8 & 9)
_Page produit :_
_PrestaShop · SKU dfpicking · 79,00 €_
**Préparez plusieurs commandes en une seule tournée : liste de picking agrégée par produit avec emplacements de stock, scan code-barres (douchette), passage automatique en « Préparation en cours », PDF de picking et bons de colisage sans prix.**
---
### Personnalisation produit — Gravure, texte & image avec aperçu live (PrestaShop 8 & 9)
_Page produit :_
_PrestaShop · SKU dfcustomizer · 69,00 €_
**Gravure, texte personnalisé et upload d'image avec aperçu en direct sur la photo produit. Chaque option ajoute son supplément au prix — montant fixe ou pourcentage — appliqué automatiquement au panier.**
---
### Page de suivi de commande multi-transporteurs — Timeline brandée (PrestaShop 8 & 9)
_Page produit :_
_PrestaShop · SKU dftracking · 49,00 €_
**Offrez à vos clients une page de suivi de commande à vos couleurs : statuts Colissimo, Mondial Relay, Chronopost et DHL agrégés en temps réel sur une timeline claire, sans quitter votre boutique.**
Vos clients n'ont plus à jongler entre les sites des transporteurs : ce module ajoute à votre boutique PrestaShop une page de suivi brandée qui interroge directement les APIs Colissimo (La Poste), Mondial Relay, Chronopost et DHL, normalise les statuts et les affiche sur une timeline en 4 étapes — de la confirmation de commande à la livraison. Accessible depuis l'espace client comme en invité (référence + email), mise en cache en base avec rafraîchissement par cron, et personnalisable à vos couleurs depuis le back-office.
---
### Retrait en Magasin — Click & Collect avec carte (PrestaShop 8 & 9)
_Page produit :_
_PrestaShop · SKU datafireflystorepickup · 39,00 €_
**Proposez le Click & Collect sur votre boutique PrestaShop 8 ou 9 : un transporteur « Retrait en magasin » avec liste des magasins et carte interactive au checkout. Le client choisit son point de retrait en un clic — sans clé API, sans abonnement.**
Le module Retrait en Magasin ajoute un transporteur Click & Collect complet à votre boutique PrestaShop 8 ou 9. À l'étape livraison du checkout, vos clients voient la liste de vos magasins et une carte interactive (Leaflet + OpenStreetMap) et sélectionnent leur point de retrait en un clic. Le choix est obligatoire et enregistré avec la commande : il s'affiche sur la confirmation de commande, dans l'espace client et dans la fiche commande du back-office.
La gestion des magasins se fait directement depuis la configuration du module : nom, adresse, téléphone, horaires, position GPS définie par simple clic sur la carte ou géocodage automatique de l'adresse. Les frais de retrait sont configurables (gratuit par défaut). Aucune clé API n'est requise : la cartographie repose sur OpenStreetMap.
---
### Page Builder pour Shopware 6.7 – Éditeur visuel de pages
_Page produit :_
_Shopware · SKU DF-PAGEBUILDER-SW · 99,00 €_
**Créez des landing pages et pages de contenu sans développeur : éditeur drag & drop avec 15 blocs (produits, formulaires, vidéos RGPD), brouillons, versions, publication planifiée et SEO intégré. 100 % autonome, indépendant du CMS natif.**
Le Page Builder DataFirefly est un éditeur visuel de pages autonome pour Shopware 6.7. Vos équipes marketing créent et publient des landing pages complètes — blocs produits avec ajout panier, formulaires anti-spam, galeries, vidéos à consentement RGPD — sans toucher au code ni dépendre des Shopping Experiences. Brouillons séparés de la version publiée, historique de versions, publication planifiée multilingue, slugs uniques avec redirections 301 automatiques : tout est pensé pour un usage e-commerce sérieux.
---
### Staging & Clonage de Boutique PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-STAGINGPRO · 79,00 €_
**Créez un site de staging complet de votre boutique PrestaShop 8 ou 9 en un clic : fichiers et base de données clonés par lots sans timeout, staging protégé automatiquement, push sélectif vers la production avec backup et rollback.**
---
### Prix Dégressifs par Palier (Quantité) PrestaShop
_Page produit :_
_PrestaShop · SKU DF-QTIERS-FR · 69,00 €_
**Transformez les remises quantité natives de PrestaShop en bloc de vente design : cartes de paliers avec badge meilleure offre, ajout direct au panier par quantité, relance automatique sur la page panier et statistiques de clics par palier.**
---
### Plugin Sauvegarde Shopware 6 — DfBackup SW : BDD + Fichiers, Chiffrement AES-256, S3/FTP/Dropbox, Restauration 1-Clic
_Page produit :_
_Shopware · SKU DF-BACKUP-SW-FR · 149,00 €_
**Sauvegarde planifiée BDD et fichiers pour Shopware 6.5, 6.6 et 6.7 : stockage Local / S3 / FTP / Dropbox, chiffrement AES-256 authentifié, vérification SHA-256, restauration 1-clic avec snapshot automatique, exécution en arrière-plan via Symfony Messenger, et réplication push vers un Shopware staging pour la synchronisation nightly.**
---
### Traduction IA PrestaShop — Produits, Catégories, SEO & Pages CMS (ChatGPT, Claude, Gemini, Mistral)
_Page produit :_
_PrestaShop · SKU DF-AICONTENT-FR · 59,00 €_
**Traduisez et améliorez produits, catégories, pages CMS et marques — contenu et SEO complet — avec ChatGPT, Claude, Gemini ou Mistral, dans toutes les langues de votre boutique PrestaShop 8 ou 9. Aperçu avant/après, rollback en un clic, compatible Creative Elements.**
---
### Frais de Douane DDP / DAP PrestaShop — Taxes d'Importation Hors UE pour Boutiques Européennes
_Page produit :_
_PrestaShop · SKU DF-CUSTOMSDUTY-DE · 89,00 €_
**Conçu pour les boutiques européennes expédiant hors UE : vos clients choisissent au checkout de régler les droits de douane et taxes d'importation directement sur la boutique (DDP) ou à la livraison (DAP). Calcul automatique, taux par pays, seuils de franchise, multidevise, mention Incoterm sur la facture.**
---
### DataFirefly Vente Flash & Compte à rebours — Shopware 6
_Page produit :_
_Shopware · SKU DF-FLASHSALE-SW-FR · 89,00 €_
**Bannière promo sticky, compte à rebours synchronisé sur le serveur et remises planifiées automatiquement — sans CRON, sans build et sans toucher à votre thème. Shopware 6.5, 6.6 et 6.7.**
Le plugin DataFirefly Vente Flash transforme vos promotions Shopware en véritables ventes flash. Programmez une campagne avec une date de début et de fin : la remise est appliquée à la volée par un processeur de panier natif, activée et coupée à la seconde près, sans aucun CRON et sans modifier les données de vos produits. Le prix barré s'affiche nativement sur les fiches produit et les listings. Une bannière à compte à rebours synchronisée sur l'heure du serveur crée un sentiment d'urgence crédible et insensible à la manipulation de l'horloge du visiteur. Compatible Shopware 6.5, 6.6 et 6.7, multilingue et multi-canaux de vente.
---
### DataFirefly WhatsApp Commerce Suite — Shopware 6
_Page produit :_
_Shopware · SKU DF-WACOMM-SW6-PT · 129,00 €_
**Allez bien au-delà des simples notifications WhatsApp sur Shopware 6 : synchronisation du catalogue Meta Commerce, prise de commande conversationnelle complète, relance de panier abandonné par WhatsApp avec templates HSM, et lien de paiement signé HMAC qui ramène le client sur votre checkout Shopware. Codebase unique compatible 6.5, 6.6 et 6.7.**
## 4 modules pour faire de WhatsApp un véritable canal de vente sur Shopware 6
La plupart des extensions WhatsApp pour Shopware s'arrêtent à l'envoi d'une notification de commande. **DataFirefly WhatsApp Commerce Suite** va beaucoup plus loin et transforme WhatsApp en un canal de vente complet, en s'appuyant sur l'API Meta Cloud officielle.
### 📦 Synchronisation du catalogue WhatsApp Business
Vos produits Shopware sont poussés automatiquement vers le catalogue Meta Commerce, en temps réel à chaque modification, ou par lots horaires si vous préférez. Les variantes sont envoyées individuellement, le mapping `retailer_id` est cohérent (`sw_{numéro d'article}`), les catégories exclues sont configurables, et un bouton de resynchronisation complète permet de tout repousser en batch de 100.
### 💬 Prise de commande conversationnelle
Une machine à états complète gère le parcours du client dans WhatsApp : navigation dans le catalogue, recherche libre, sélection de quantités avec contrôle de stock, revue du panier, paiement, transfert à un conseiller humain. Vos clients peuvent commander sans jamais quitter le chat — et le checkout final reste votre checkout Shopware, panier déjà construit.
### ⏰ Relance de panier abandonné en 3 étapes
Trois séquences configurables (60 min, 24 h, 72 h par défaut) avec templates HSM Meta. La troisième relance peut joindre un code promo dynamique pour maximiser la conversion. Le taux de récupération est suivi en temps réel dans le tableau de bord.
### 💳 Lien de paiement signé HMAC
Quand le client clique sur « Payer » dans WhatsApp, il reçoit un lien sécurisé signé HMAC SHA-256 avec expiration configurable, qui restaure son panier côté serveur et le ramène directement sur votre checkout Shopware existant. Aucune dépendance à un nouveau prestataire de paiement, vous gardez votre stack actuelle.
## Architecture technique
- Plugin natif Shopware 6, codebase unique compatible 6.5, 6.6 et 6.7
- PSR-4 sous le namespace `DfWhatsAppCommerce`, contrôleurs en attributs PHP 8
- 5 entités DAL dédiées sur tables préfixées `df_wac_` (conversations, messages, paniers, catalogue, journaux)
- 2 scheduled tasks natives Shopware : relance panier toutes les 15 min, batch catalogue horaire
- Webhook storefront `/df-wac/webhook` avec validation X-Hub-Signature-256 et handshake Meta
- Module d'administration complet : dashboard KPI, conversations style WhatsApp Web avec réponse directe, paniers abandonnés, log catalogue, journaux filtrables
- Configuration par canal de vente via le système de plugin config standard
- 3 langues fournies : FR, EN, DE (admin, storefront et messages clients avec détection de langue)
## Inclus à l'achat
- Plugin `.zip` téléchargeable depuis votre compte client, code source complet inclus
- Documentation complète (configuration Meta Cloud API, webhook, templates HSM)
- Mises à jour gratuites pendant 12 mois
- Support technique par e-mail
- Installations dev et pré-production illimitées
---
### Centre de Notifications Shopware
_Page produit :_
_Shopware · SKU DF-NTCSW-FR · 79,00 €_
**Une cloche de notifications à côté du panier : nouveautés ajoutées automatiquement, codes promo en un clic, badge rouge sur les non-lues. Pour Shopware 6.5, 6.6 et 6.7.**
---
### DfGpsr SW – Conformité RGPS pour Shopware 6
_Page produit :_
_Shopware · SKU DFGPSR-SW-FR · 69,00 €_
**Le RGPS (règlement UE 2023/988) est obligatoire depuis décembre 2024 et Shopware n'a rien de natif. DfGpsr SW affiche fabricant, personne responsable UE, avertissements et documents de sécurité sur chaque fiche produit. Un seul ZIP pour Shopware 6.5, 6.6 et 6.7.**
---
### DataFirefly Factur-X SW — Facture électronique Shopware 6 : ZUGFeRD & XRechnung 3.0
_Page produit :_
_Shopware · SKU DF-FACTURX-SW-PL · 89,00 €_
**Factures électroniques EN 16931 pour Shopware 6 : Factur-X / ZUGFeRD embarqué dans le PDF de facture, XRechnung 3.0 avec Leitweg-ID pour le B2G, génération automatique, pièce jointe e-mail et catégories TVA intelligentes. Compatible Shopware 6.5 à 6.7, zéro dépendance Composer.**
---
### Popup Pro Newsletter — Shopware 6
_Page produit :_
_Shopware · SKU DF-SW-POPUPNEWS-FR · 49,00 €_
**Popup newsletter haute conversion pour Shopware 6 : vos visiteurs s'abonnent et reçoivent instantanément un code promo valable sur leur première commande — code unique par abonné ou code fixe, remise en pourcentage ou en montant.**
---
### Codes promo & réductions dans la liste des commandes — PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-OVCH · 29,00 €_
**Ajoutez deux colonnes à la liste des commandes du back-office : le ou les codes promo utilisés et le montant total de la réduction, formaté dans la devise de la commande. Basé sur la grille Symfony officielle, sans aucun override du cœur ni table ajoutée.**
La liste des commandes de PrestaShop affiche le total payé, mais jamais **quel code promo a été utilisé** ni **combien il a coûté**. Pour le savoir, il faut ouvrir chaque commande, une par une. Dès que vous lancez une campagne de codes promo, suivre leur usage devient vite fastidieux.
Ce module ajoute directement dans la liste des commandes deux colonnes : **les codes promo utilisés** et **le montant total de la réduction** (formaté dans la devise de la commande). Vous repérez d'un coup d'œil quelles commandes ont bénéficié d'une promotion, et pour quel montant, sans ouvrir une seule fiche.
À partir de PrestaShop 1.7.7, la liste des commandes repose sur la _grille Symfony_. Le module s'y branche via les hooks officiels _actionOrderGridDefinitionModifier_ (ajout des colonnes) et _actionOrderGridQueryBuilderModifier_ (récupération des données). **Aucun contrôleur surchargé, aucun fichier du cœur modifié.**
Les codes et montants sont lus par sous-requêtes corrélées sur les tables order_cart_rule et cart_rule. Cette approche évite toute duplication de lignes et tout conflit avec le regroupement interne de la grille. Le module ne crée aucune table et n'écrit rien en base : il se contente de lire et d'afficher. Installation et désinstallation parfaitement propres.
---
### DataFirefly Social Connect — Shopware 6 : Google, Apple & Facebook
_Page produit :_
_Shopware · SKU DF-SCT-SW-FR · 89,00 €_
**Connexion sociale Google, Apple et Facebook pour Shopware 6, avec dashboard analytique intégré. Inscription en un clic, liaison automatique par email vérifié, et statistiques par canal de vente. Compatible Shopware 6.6 et 6.7.**
---
### Bouton Vider le Panier — PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-CLEARCART-FR_
**Un bouton « Vider le panier » sur la page panier : vos clients suppriment tous les articles et bons de réduction en un seul clic.**
---
### DataFirefly BOM — Nomenclatures & Assemblage de produits
_Page produit :_
_PrestaShop · SKU DF-BOM · 109,00 €_
**Vendez des kits et fabriquez des produits assemblés dans PrestaShop 8 & 9 : nomenclatures (BOM), stock calculé automatiquement, décrément des composants à la vente, ordres d'assemblage et prix calculé à partir des composants.**
---
### DataFirefly Achat Groupé & Prix Dégressif Collectif
_Page produit :_
_PrestaShop · SKU DF-GROUPBUY-FR · 89,00 €_
**Plus il y a d'acheteurs, plus le prix baisse pour tout le monde. Paliers dégressifs collectifs en temps réel, remboursement rétroactif optionnel et compte à rebours, le tout via les prix spécifiques natifs de PrestaShop.**
---
### Live Shopping & Vente en Direct PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-DFLIVE-FR · 149,00 €_
**Transformez votre boutique PrestaShop 8 ou 9 en plateforme de live shopping autonome : streaming vidéo natif (HLS, MP4 ou embed), produits épinglés en direct, offres flash, chat et ajout au panier natif — sans SaaS tiers.**
---
### DataFirefly MCP Commerce — Serveur MCP / Commerce agentique PrestaShop
_Page produit :_
_PrestaShop · SKU DF-MCPCOMMERCE-FR · 89,00 €_
**Exposez votre boutique PrestaShop aux agents IA (ChatGPT, Claude) via un serveur MCP. Catalogue, panier et commande pilotables par l'IA, avec OAuth 2.1 et jetons Bearer.**
---
### Connecteur Odoo pour PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-ODOO-FR · 149,00 €_
**Synchronisez produits, stock, commandes et clients entre PrestaShop et Odoo en temps réel et dans les deux sens, sans jamais bloquer votre tunnel de commande.**
Le Connecteur Odoo relie votre boutique PrestaShop à votre ERP Odoo en temps réel. Produits, stock, commandes et clients sont synchronisés automatiquement, dans les deux sens, grâce à une file d'attente résiliente qui rejoue toute synchronisation en cas d'indisponibilité d'Odoo. Compatible PrestaShop 8 et 9, Odoo 14 à 18, via JSON-RPC.
---
### DataFirefly PWA — Boutique installable, Push & Hors-ligne
_Page produit :_
_PrestaShop · SKU DF-PWA-FR · 129,00 €_
**Transformez votre boutique PrestaShop en Progressive Web App : icône sur l'écran d'accueil, notifications push web et navigation hors-ligne. Compatible PrestaShop 8 et 9, multiboutique et multilingue.**
---
### Comptes Multi-utilisateurs B2B — Équipes & Rôles PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-B2BTEAM-FR · 109,00 €_
**Comptes B2B multi-utilisateurs pour PrestaShop 8 & 9 : sociétés, rôles, validation hiérarchique, budgets et paiement sur compte.**
---
### DataFirefly Auction — Ventes aux enchères en temps réel
_Page produit :_
_PrestaShop · SKU DF-AUCTION-FR · 129,00 €_
**Transformez n'importe quel produit en vente aux enchères en ligne : enchères automatiques façon eBay, anti-sniping, prix de réserve masqué, achat immédiat, clôture automatique par cron et génération d'un bon pour le gagnant.**
---
### Webhooks DataFirefly — Connecteur Zapier, Make & n8n
_Page produit :_
_PrestaShop · SKU DF-WEBHOOKS-FR · 109,00 €_
**Connecteur webhooks bidirectionnel no-code : reliez PrestaShop à Zapier, Make, n8n et 5000+ applications, avec file asynchrone, relances automatiques et signature HMAC.**
Webhooks DataFirefly relie votre boutique PrestaShop 8 et 9 à plus de 5000 applications, dans les deux sens, sans écrire une seule ligne de code. Émettez vos événements boutique vers Zapier, Make ou n8n, et laissez vos automatisations pousser des données en retour via une API entrante sécurisée. File asynchrone, relances à backoff exponentiel, signature HMAC, anonymisation RGPD et journal de livraison complet avec rejeu.
---
### Smart Content – Personnalisation par segment & IA
_Page produit :_
_PrestaShop · SKU DF-SMARTCONTENT-PL · 129,00 €_
**Affichez le bon contenu au bon visiteur. Segmentez selon le profil, le comportement, le panier et le contexte, puis diffusez des blocs sur-mesure dans n'importe quelle zone du thème — avec A/B testing, statistiques et IA intégrée.**
## Le bon message, pour la bonne audience, au bon endroit
Smart Content transforme votre boutique PrestaShop en vitrine personnalisée. Au lieu d'afficher le même contenu à tout le monde, le module évalue chaque visiteur en temps réel — son profil, son historique d'achat, le contenu de son panier et son contexte — puis sélectionne automatiquement le bloc de contenu le plus pertinent à afficher.
Nouveaux clients, acheteurs VIP, paniers abandonnés, visiteurs venus d'une campagne précise : chacun voit un message taillé pour lui, dans la zone de votre choix.
### Une segmentation puissante, sans toucher au code
Construisez des segments à partir de règles combinées en ET ou en OU : groupe client, statut connecté, nouveau ou récurrent, pays, langue, devise, appareil, nombre de commandes, total dépensé, jours depuis la dernière commande, total du panier, catégorie ou produit présent dans le panier, abonnement newsletter, source de trafic UTM, site référent, plage horaire et jour de la semaine. Le tout se construit visuellement, règle par règle.
### Des campagnes pilotées, mesurées et optimisées
Associez vos segments à un contenu HTML diffusé dans l'une des 11 zones d'affichage du thème. Ajoutez une planification, une priorité, un plafond de fréquence par visiteur, et activez l'A/B testing pour comparer plusieurs variantes. Le tableau de bord suit les impressions, le taux de clic, les conversions et le chiffre d'affaires attribué — par campagne et par variante.
### L'intelligence artificielle intégrée, sans surcoût
Smart Content embarque deux assistants IA. Le premier rédige pour vous un bloc de contenu orienté conversion à partir d'un segment, d'un objectif et d'un ton, dans la langue de votre choix. Le second analyse les statistiques réelles de votre boutique et vous propose les segments à plus forte valeur, prêts à créer. L'IA est incluse : il vous suffit de connecter votre clé API (compatible OpenAI et Mistral).
---
### Suivi de Positions SERP (Rank Tracker Google) PrestaShop
_Page produit :_
_PrestaShop · SKU DF-SERPTRACKER · 49,00 €_
**Suivez vos positions Google sur PrestaShop : mots-clés par pays et appareil, historique et graphiques, distance au top, indice de visibilité, concurrents, fonctionnalités SERP et alertes de chute. Multi-fournisseurs (Serper, ValueSERP, SerpApi, DataForSEO).**
---
### Réservation & Prise de rendez-vous
_Page produit :_
_PrestaShop · SKU DF-BOOKING-NL · 149,00 €_
**Transformez votre boutique PrestaShop en plateforme de réservation : calendrier interactif, créneaux en temps réel, gestion des intervenants et acompte payé en ligne.**
---
### FAQ Produit — Accordéon Statique
_Page produit :_
_PrestaShop · SKU DF-STATICFAQ-PL_
**Affichez une FAQ en accordéon sous vos fiches produit. Saisie manuelle, balisage schema.org FAQPage, zéro JavaScript. Compatible PrestaShop 8 & 9, multiboutique et multilingue. Gratuit.**
## Une FAQ claire sous chaque produit
Répondez aux questions récurrentes de vos clients directement sur la fiche produit, dans un accordéon pliable, léger et accessible. Vous rédigez chaque question et chaque réponse depuis le back-office, en gardant un contrôle total sur le contenu.
## Optimisé pour le SEO et l'AEO
Le module injecte automatiquement le balisage schema.org FAQPage en JSON-LD. Vos questions deviennent éligibles aux résultats enrichis de Google et exploitables par les moteurs de réponse et les assistants IA.
## Zéro JavaScript, zéro dépendance
L'accordéon repose sur les éléments details et summary natifs du HTML : rien à charger, aucun conflit de thème, navigation clavier native et respect des préférences de mouvement réduit.
---
### Injecteur de code Header/Footer (CSS/JS)
_Page produit :_
_PrestaShop · SKU DF-CODEINJECTOR-PL_
**Injectez CSS, JS et HTML dans le header et le footer de PrestaShop sans modifier le thème. Snippets illimités, ciblage par page, multiboutique. Module gratuit.**
---
### Vider le Cache PrestaShop — Purge auto (PS 8 & 9)
_Page produit :_
_PrestaShop · SKU DF-CACHECLEAR-PL_
**Ajoutez un bouton « Vider le cache » à la barre du back-office. Un clic purge Smarty, XML, Media et Symfony. Compatible PrestaShop 8 et 9, multiboutique. Gratuit.**
Pendant le développement et la maintenance d'une boutique PrestaShop, on vide le cache des dizaines de fois par jour. **DataFirefly Cache Clear** ajoute un bouton « Vider le cache » directement dans la barre d'outils du back-office : un seul clic purge l'ensemble des caches, sans passer par Paramètres avancés puis Performances, et sans recharger la page.
Le module nettoie le cache template Smarty, le cache XML, le cache des médias (CSS/JS) ainsi que le conteneur Symfony de PrestaShop 8/9. Si le conteneur n'est pas joignable, un repli automatique supprime le contenu du dossier de cache de l'environnement courant. Aucune configuration n'est requise : installez, activez, le bouton apparaît immédiatement.
---
### Éditeur robots.txt
_Page produit :_
_PrestaShop · SKU DF-ROBOTS-PL_
**Éditez, validez et régénérez votre robots.txt en un clic depuis le back-office PrestaShop. Validateur intégré, sauvegarde automatique et blocage des robots d'IA. Compatible PrestaShop 8 et 9.**
Le fichier robots.txt pilote la manière dont les moteurs de recherche et les robots explorent votre boutique. Le modifier impose habituellement un accès FTP ou SSH. Ce module gratuit DataFirefly vous permet de l'éditer, de le valider et de le régénérer en un clic, directement depuis le back-office PrestaShop, avec une sauvegarde automatique à chaque enregistrement et des modèles prêts à l'emploi (dont le blocage des robots d'IA). Compatible PrestaShop 8 et 9, multiboutique.
---
### Boutons +/- de Quantité sur la Fiche Produit — PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-QTYBUTTONS_
**Remplacez l'input quantité natif de PrestaShop par de vrais boutons + et − tactiles sur la fiche produit. Sans override de template, compatible thème Classic et thèmes custom, couleurs et style personnalisables. Gratuit.**
## Un sélecteur de quantité enfin agréable à utiliser
Sur la fiche produit, le champ quantité natif de PrestaShop est minuscule et peu pratique : il faut viser de toutes petites flèches, ou taper la valeur au clavier. Sur mobile, c'est encore pire. **Boutons +/- de Quantité** ajoute de vrais boutons **+** et **−** de chaque côté du champ, avec de larges zones de clic, pensés pour le tactile.
## Aucun override de template
Le module n'écrase aucun fichier de thème. Il enregistre une feuille de style et un script léger, uniquement sur la fiche produit, qui encapsulent le champ quantité existant et lui ajoutent les boutons. Résultat : il fonctionne avec le thème Classic comme avec la plupart des thèmes personnalisés, et survit aux mises à jour de PrestaShop sans rien casser.
## Compatible avec le thème Classic
Le thème Classic ajoute déjà ses propres flèches verticales via bootstrap-touchspin. Le module les neutralise proprement à l'intérieur de son groupe de boutons, pour ne laisser que les vrais + et −, sans doublon visuel.
## Synchronisation correcte avec le panier
À chaque clic, la nouvelle valeur est appliquée et PrestaShop est notifié comme si l'utilisateur avait saisi la quantité lui-même (événements natifs et jQuery). Le prix, les déclinaisons et le bouton d'ajout au panier réagissent exactement comme attendu. Après un changement de déclinaison, qui re-génère le bloc quantité, les boutons sont automatiquement réinjectés.
## Respecte le stock et les contraintes
Les boutons lisent la quantité minimale, la quantité maximale et le pas définis sur le champ : impossible de descendre sous le minimum (souvent 1) ni de dépasser le stock disponible lorsqu'il est borné.
## Personnalisable depuis le back-office
Choisissez le style des boutons (carré ou arrondi), la couleur de fond et la couleur des icônes +/−, et masquez ou non les flèches natives du champ nombre. Aucune ligne de code à écrire.
---
### DataFirefly Billetterie & Événements
_Page produit :_
_PrestaShop · SKU DF-EVENTTICKETS-PL · 149,00 €_
**Vendez vos billets d'événement directement dans PrestaShop : sélection de siège visuelle, billets QR, PDF et contrôle d'entrée par scan. Compatible PrestaShop 8 & 9, multiboutique et multilingue.**
DataFirefly Billetterie & Événements transforme n'importe quel produit PrestaShop en billet d'événement, avec plan de salle visuel, billets QR et contrôle d'entrée par scan. Aucune passerelle tierce, aucune dépendance externe : la génération des QR et des PDF est embarquée dans le module.
---
### DataFirefly Publication Réseaux Sociaux
_Page produit :_
_PrestaShop · SKU DF-SOCIALAUTOPOST · 149,00 €_
**Publiez automatiquement chaque nouveau produit PrestaShop 8 ou 9 sur Facebook, Telegram, X, LinkedIn et Pinterest : file d'attente, cron sécurisé, messages personnalisables par réseau et garde anti-rétroactive contre la publication en masse du catalogue existant.**
---
### Bouton Retour en Haut (Scroll to Top) PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-BTT-FR_
**Un bouton « Retour en haut » fluide, léger et entièrement personnalisable pour PrestaShop 8 et 9.**
Le module DataFirefly Retour en haut ajoute un bouton flottant qui ramène vos visiteurs en haut de page d'un seul clic, en douceur. Léger, accessible et entièrement personnalisable depuis le back-office, il s'installe en quelques secondes sur PrestaShop 8 et 9.
---
### DataFirefly - Tunnel de conversion & Heatmap
_Page produit :_
_PrestaShop · SKU DF-FHM-PL · 79,00 €_
**Voyez exactement où vos visiteurs décrochent et sur quoi ils cliquent. Tunnel de conversion en 9 étapes et heatmap (clics, scroll, éléments), 100% first-party.**
---
### DataFirefly Corbeille Produits
_Page produit :_
_PrestaShop · SKU DF-PRODTRASH · 59,00 €_
**Chaque produit supprimé dans PrestaShop est automatiquement sauvegardé (données + fichiers images) dans une corbeille. Restaurez-le à l'identique en un clic, avec son ID d'origine. Le filet de sécurité indispensable contre les suppressions accidentelles, les imports ratés et les fausses manipulations.**
---
### Journal d'audit BO — Traçabilité et conformité pour PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-ALOG · 49,00 €_
**Tracez chaque création, modification et suppression en back-office PrestaShop avec le détail champ par champ avant/après, l'employé, l'adresse IP et l'horodatage. Liste filtrable, vue détaillée, export CSV et purge automatique. Sécurité et conformité RGPD, sans aucun override du cœur.**
Dès qu'une boutique implique plusieurs employés, prestataires ou agences, une question revient sans cesse : **qui a modifié ce prix, supprimé cette commande ou changé cette configuration ?** Sans traçabilité, une erreur ou une action malveillante reste invisible.
Ce module enregistre chaque intervention en back-office : créations, modifications et suppressions, avec le **détail champ par champ** (ancienne valeur → nouvelle valeur), l'employé, son profil, l'adresse IP, le contrôleur, la méthode HTTP, l'URL et l'horodatage. Il trace également le _début de session_ de chaque employé, et — sur PrestaShop 8 — les tentatives échouées et les déconnexions.
Le module s'appuie exclusivement sur les **hooks natifs d'ObjectModel** présents dans PrestaShop 8 et 9 : il capte ainsi toutes les entités (produits, catégories, commandes, clients, employés, transporteurs, taxes, CMS, configuration…) **sans aucun override ni modification du cœur**. Les champs sensibles (mots de passe, clés, tokens) sont automatiquement masqués, et toutes les écritures se font en SQL direct — l'audit ne peut jamais interrompre une opération métier.
Côté exploitation : une liste filtrable et triable, une vue détaillée avec diff coloré, un export CSV compatible Excel et une purge automatique selon la durée de rétention que vous définissez. Conçu pour la sécurité et la conformité RGPD.
---
### DataFirefly Helpdesk & Ticketing
_Page produit :_
_PrestaShop · SKU DF-HELPDESK · 89,00 €_
**Un système de support complet intégré à PrestaShop 8 et 9 : file d'attente back-office, tickets liés aux commandes, statuts et priorités, notes internes privées et notifications automatiques.**
---
### Forum Communautaire — PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-FORUM · 129,00 €_
**Un forum communautaire complet, intégré au compte client : catégories et sous-forums multilingues, sujets, réponses, modération, signalements, recherche plein texte et URLs propres. Compatible PrestaShop 8 et 9.**
---
### Arrondi Solidaire & Don au Checkout
_Page produit :_
_PrestaShop · SKU DF-SOLIDROUND · 49,00 €_
**Arrondi à l'euro supérieur et microdon caritatif au panier, au profit de l'association de votre choix. Trois modes, don sans TVA, suivi des dons en back-office. Compatible PrestaShop 8 et 9.**
---
### Filigrane Automatique des Images Produit — PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-WATERMARK · 49,00 €_
**Apposez automatiquement votre logo ou votre nom sur les images produit PrestaShop, dès l'upload ou la régénération des miniatures. Logo PNG ou texte, opacité, 9 positions + mosaïque, WebP & AVIF. Les fichiers originaux restent intacts.**
## Protégez et signez vos visuels produit, automatiquement
Vos images produit sont votre vitrine — et elles se recopient en deux clics. **Filigrane Automatique** appose votre logo ou votre nom sur chaque miniature produit, dès l'upload d'une image ou lors de la régénération des vignettes. Vos fichiers originaux ne sont jamais modifiés : seules les déclinaisons affichées en boutique sont tamponnées, ce qui garantit qu'une nouvelle régénération repart toujours d'une image propre.
## Deux modes au choix : logo PNG ou texte
- **Mode logo** — téléversez un PNG transparent. La transparence est parfaitement préservée grâce à une fusion alpha sur mesure : aucun cadre ni fond noir disgracieux, contrairement à beaucoup de modules de filigrane.
- **Mode texte** — affichez le nom de votre boutique, un copyright ou une mention personnalisée. La police DejaVuSans est embarquée dans le module : aucune dépendance serveur, le rendu est identique sur tous les hébergements.
## Un placement au pixel près
Choisissez parmi **9 positions d'ancrage** (coins, bords, centre) ou le **mode mosaïque** qui répète le filigrane sur toute l'image — idéal contre la revente de visuels. Réglez l'opacité de 1 à 100 %, les marges horizontale et verticale en pixels, l'angle du texte, et sa couleur.
## Une taille qui s'adapte à chaque format d'image
La taille du logo et du texte s'exprime en **pourcentage de la largeur de l'image**. Résultat : le filigrane garde des proportions cohérentes sur la fiche produit en grand format comme sur la vignette de la page catégorie, sans réglage par type d'image. Une largeur minimale configurable évite de tamponner les micro-vignettes (panier, recherche).
## Compatible WebP et AVIF
PrestaShop 8 et 9 génèrent désormais des images en WebP et AVIF en plus du format principal. Le module traite **tous les formats générés** (JPG, PNG, WebP, AVIF) ainsi que les variantes haute densité `@2x`, et reprend automatiquement les niveaux de qualité définis dans les paramètres d'images de votre boutique.
## Léger, sans dépendance, sans risque
Aucune bibliothèque externe : le module s'appuie uniquement sur l'extension GD présente sur la quasi-totalité des hébergements PHP. Il se branche sur le hook natif `actionWatermark` de PrestaShop, et résout ses chemins de façon défensive pour fonctionner aussi bien à l'upload qu'en régénération back-office ou en ligne de commande (`bin/console prestashop:thumbnails:regenerate products`).
## Mise en route en 3 étapes
1. Installez le module et choisissez votre mode (logo ou texte).
2. Réglez opacité, position, taille et formats à traiter.
3. Régénérez les miniatures depuis _Design > Paramètres d'images_ pour appliquer le filigrane à tout le catalogue existant. Les nouvelles images sont filigranées automatiquement à l'upload.
---
### Roue de la fortune & Pop-up Exit-Intent
_Page produit :_
_PrestaShop · SKU DF-EXITWHEEL · 49,00 €_
**Transformez les visiteurs sur le point de partir en abonnés et en clients. Une pop-up exit-intent avec roue de la fortune gamifiée : capture d'emails, tirage pondéré côté serveur et coupons uniques générés automatiquement.**
---
### DataFirefly Location de Produits
_Page produit :_
_PrestaShop · SKU DF-RENTAL · 99,00 €_
**Louez vos produits PrestaShop 8 et 9 : calendrier de disponibilité, sélection des dates en plage ou en deux champs avec heures, dates globales au panier, tarif dégressif ou coefficients de durée avec exceptions week-end, caution par produit ou globale automatique, demande de réservation sans paiement, packs synchronisés et API JSON. Option catalogue complet pour les boutiques 100 % location.**
---
### DataFirefly Factur-X — Facturation électronique PDF/A-3 + XML
_Page produit :_
_PrestaShop · SKU DF-DFFACTURX · 89,00 €_
**Transformez chaque commande PrestaShop en facture électronique hybride Factur-X : un PDF/A-3b imprimable contenant les données structurées XML CII (norme EN 16931). Prêt pour la réforme française 2026-2027.**
Module PrestaShop de génération de factures électroniques au format Factur-X (PDF/A-3b avec XML CII embarqué), conforme à la norme EN 16931 et prêt pour la réforme française de la facturation électronique 2026-2027.
---
### DataFirefly Mega Menu & Burger
_Page produit :_
_PrestaShop · SKU DF-MEGAMENU-FR · 129,00 €_
**Méga-menu, menu walker et menu burger pour PrestaShop 8 & 9 : colonnes, images, blocs CMS, arborescence automatique. 100% multilingue et multiboutique, configurable au glisser-déposer.**
DataFirefly Mega Menu & Burger transforme la navigation de votre boutique PrestaShop : méga-menu à colonnes, menu déroulant walker et menu burger mobile, le tout configurable visuellement au glisser-déposer, sans aucune ligne de code.
---
### DataFirefly Vente Flash & Compte à rebours
_Page produit :_
_PrestaShop · SKU DF-FLASHSALE-FR · 79,00 €_
**Bannière promo, compte à rebours synchronisé sur le serveur et planification automatique des remises — sans CRON et sans toucher à votre thème.**
Le module DataFirefly Vente Flash transforme vos promotions en véritables ventes flash. Programmez une campagne avec une date de début et de fin : la remise est appliquée nativement via les prix spécifiques de PrestaShop, activée et coupée à la seconde près, sans aucun CRON. Une bannière à compte à rebours synchronisée sur l'heure du serveur crée un sentiment d'urgence crédible et insensible à la manipulation de l'horloge du visiteur. Compatible PrestaShop 8.x et 9.x, multilingue et multiboutique.
---
### Cache Page & Optimisation Vitesse PrestaShop 8 & 9
_Page produit :_
_PrestaShop · SKU DF-SPEEDPACK-FR · 149,00 €_
**Full Page Cache, Critical CSS, Delay JS, lazy load natif et nettoyage de la base. Des pages servies en cache et des Core Web Vitals au vert, sur PrestaShop 8 et 9.**
DataFirefly Speed Pack regroupe en un seul module tout ce qu'il faut pour accélérer une boutique PrestaShop : cache page complet servi dès le dispatcher, Critical CSS par type de page, minification et combinaison des actifs, Delay JS jusqu'à la première interaction, lazy loading natif, resource hints, réécriture CDN, directives serveur et nettoyage de la base de données. Compatible PrestaShop 8 et 9, multiboutique et multilingue, architecture PSR-4 sans Composer.
---
### DataFirefly GPSR
_Page produit :_
_PrestaShop · SKU DF-GPSR-PL · 69,00 €_
**Conformité GPSR clé en main pour PrestaShop : affichez le fabricant, le responsable établi dans l'UE, les avertissements et les pictogrammes de sécurité sur chaque fiche produit.**
---
### DataFirefly Marketplace — Multi-vendeurs PrestaShop
_Page produit :_
_PrestaShop · SKU DF-MARKETPLACE-PL · 129,00 €_
**Place de marché multi-vendeurs complète pour PrestaShop 8 et 9 : split de commande réel, commissions, paiement éclaté Mangopay et Stripe Connect, conformité DSA et P2B, en 5 langues.**
## Transformez votre boutique PrestaShop en place de marché
DataFirefly Marketplace permet à des vendeurs tiers de s'inscrire, de publier leurs produits et de gérer leurs commandes, pendant que vous orchestrez commissions, paiements et conformité depuis le back-office.
### Un découpage de commande réel
Chaque commande multi-vendeurs est découpée en véritables commandes filles, chacune avec ses frais de port, sa commission figée, sa facture et son crédit de portefeuille. Le cloisonnement entre vendeurs est strict.
### Paiement éclaté et escrow régulés
Les adaptateurs Mangopay et Stripe Connect encaissent les fonds de façon éclatée, les conservent en escrow, puis les libèrent vers les portefeuilles vendeurs au jalon de votre choix, avec reversements SEPA déclenchés en un clic.
### Pensé pour le cadre européen
Identité vendeur DSA affichée en vitrine, factures de commission générées automatiquement, page de transparence P2B et indicateur TVA « plateforme réputée fournisseur ».
### Complet de bout en bout
Espace vendeur, fiche produit riche, livraison par vendeur, avis, messagerie, plans, vitrines personnalisées, répertoire, litiges et retours, analytics opérateur et vendeur — le tout en français, anglais, espagnol, allemand et italien.
---
### DataFirefly Demande de Devis B2B
_Page produit :_
_PrestaShop · SKU DF-B2BQUOTE · 79,00 €_
**Transformez votre boutique PrestaShop 8 ou 9 en outil de vente B2B : bouton « Devis » à la place de l'achat, panier de devis dédié, négociation des prix au back-office, PDF natif et conversion en commande réelle en un clic.**
---
### Optimiseur d'images WebP & AVIF PrestaShop
_Page produit :_
_PrestaShop · SKU DF-IMGOPT-PS · 29,00 €_
**Conversion WebP/AVIF 100% locale, sans abonnement ni quota. Livraison transparente via .htaccess, lazy-load natif et compression des originaux pour des Core Web Vitals au vert.**
L'Optimiseur d'images WebP & AVIF convertit et compresse les images de votre boutique PrestaShop directement sur votre serveur, puis sert automatiquement à chaque visiteur le format le plus léger que son navigateur sait afficher. Pas d'abonnement, pas de crédits, aucune image envoyée vers un service tiers : vos fichiers restent chez vous.
Deux modes de livraison au choix : négociation de contenu Apache via .htaccess (totalement transparent, aucune modification de votre thème) ou réécriture des balises en pour Nginx. Les originaux ne sont jamais écrasés : les versions WebP et AVIF sont générées à côté et servies uniquement aux navigateurs compatibles. Lazy-load natif, conversion automatique à l'upload, traitement en lot par AJAX, tâche CRON et commande CLI pour les gros catalogues. Compatible PrestaShop 1.7, 8 et 9.
---
### Relance Panier Abandonné Multi-étapes
_Page produit :_
_PrestaShop · SKU DF-CARTRECOVERY-PL · 49,00 €_
**Récupérez automatiquement vos paniers abandonnés grâce à des séquences d'emails programmés, des bons de réduction escaladés et la restauration du panier en un clic. Compatible PrestaShop 8 & 9.**
En moyenne, 7 paniers sur 10 sont abandonnés avant le paiement. **Relance Panier Abandonné Multi-étapes** transforme ces paniers perdus en chiffre d'affaires grâce à une séquence d'emails automatiques, personnalisés et escaladés.
Le module détecte les paniers abandonnés, planifie vos relances, génère des bons de réduction nominatifs et permet à vos clients de retrouver leur panier en un seul clic — le tout mesuré dans un tableau de bord clair.
- Séquence d'emails illimitée, chaque étape avec son délai, son contenu et son bon de réduction.
- Restauration du panier en un clic avec reconnexion automatique optionnelle.
- Suivi du chiffre d'affaires récupéré, des ouvertures et des clics.
- Conforme RGPD : désinscription en un clic et liste de suppression.
---
### Centre de Notifications WooCommerce
_Page produit :_
_WordPress / WooCommerce · SKU DF-NOTIFCENTER-FR · 29,00 €_
**Une cloche de notifications pour votre boutique WooCommerce : nouveaux produits annoncés automatiquement, codes promo et articles en un clic, pastille de non-lus, multilingue et compatible cache.**
Notification Center ajoute une cloche de notifications dans l'en-tête de votre boutique WooCommerce, à côté du panier et de l'espace client. Une pastille rouge signale les nouveautés non lues : nouveaux produits, codes promo et articles de blog. Léger, multilingue et compatible avec le cache de page.
---
### Centre de Notifications
_Page produit :_
_PrestaShop · SKU DF-NTC-FR · 45,00 €_
**Une cloche de notifications à côté du panier : nouveautés ajoutées automatiquement, codes promo en un clic, badge rouge sur les non-lues.**
---
### DataFirefly Google Tag Manager Pro — GTM & Server-side pour WooCommerce
_Page produit :_
_WordPress / WooCommerce · SKU DF-GTMPRO · 49,00 €_
**Le module Google Tag Manager premium pour WooCommerce. Connectez GA4, Google Ads, Meta, TikTok, Pinterest, Snapchat, LinkedIn, Microsoft, X, Hotjar et Clarity, puis générez en un clic un conteneur GTM complet déjà câblé sur votre dataLayer. Suivi server-side natif (Meta Conversions API, GA4 Measurement Protocol) avec déduplication automatique, Consent Mode v2, Enhanced Conversions et mode pixel direct pour les boutiques sans GTM.**
---
### Tri & Ordre des Produits WooCommerce (Glisser-Déposer)
_Page produit :_
_WordPress / WooCommerce · SKU DF-PRODUCTORDER · 19,00 €_
**Réorganisez l'ordre d'affichage de vos produits WooCommerce par glisser-déposer, pour toute la boutique ou catégorie par catégorie.**
DataFirefly Product Order ajoute une page d'administration dédiée où vous définissez l'ordre d'affichage de vos produits WooCommerce par simple glisser-déposer : ordre global de la boutique ou ordre spécifique et indépendant pour chaque catégorie. L'ordre personnalisé s'applique au front uniquement lorsque le client utilise le tri par défaut, sans jamais brider les tris par prix, popularité ou note.
---
### Double Authentification 2FA WordPress & WooCommerce
_Page produit :_
_WordPress / WooCommerce · SKU DF-TWOFACTOR · 29,00 €_
**Authentification à deux facteurs professionnelle pour WordPress et WooCommerce : back-office et comptes clients, TOTP, e-mail, codes de secours, application par rôle avec période de grâce.**
DataFirefly 2FA Fortress ajoute une authentification à deux facteurs complète et configurable à votre site WordPress / WooCommerce, aussi bien pour les administrateurs et l'équipe que pour les clients de la boutique.
Choisissez pour chaque rôle si la 2FA est désactivée, optionnelle ou obligatoire, et laissez une période de grâce paramétrable aux utilisateurs concernés avant tout blocage. Trois méthodes sont disponibles : application d'authentification (TOTP), code par e-mail et codes de secours à usage unique.
Les clients peuvent activer eux-mêmes la double authentification depuis « Mon compte ». Le module intègre la protection anti-bruteforce, un journal de sécurité, la réinitialisation par un administrateur et le chiffrement des secrets en AES-256-GCM.
---
## Articles de blog — contenu intégral
### Comment séparer les déclinaisons PrestaShop en produits distincts ?
_Source :_ — _publié_ 2026-09-06
> Une taille de vêtement se choisit après la décision d'achat, une couleur de canapé se cherche nommément sur Google. Les cinq critères qui justifient l'éclatement, ce qu'on y perd, et la procédure en sept étapes avec les redirections.
Un produit à déclinaisons regroupe plusieurs variantes sous une seule fiche et une seule adresse. C'est le bon modèle pour une taille de vêtement, et un très mauvais modèle pour une couleur de canapé que les clients cherchent nommément sur Google.
Éclater un produit à combinaisons en produits distincts se décide au cas par cas, et se fait dans un ordre précis.
## Quand la déclinaison reste le bon modèle
Trois situations où il ne faut surtout pas éclater.
Le choix est **fait après la décision d'achat**. Personne ne cherche « t-shirt bleu taille M », on cherche le t-shirt puis on choisit sa taille en fin de parcours.
Les variantes sont **nombreuses et combinatoires**. Cinq tailles et six couleurs donnent trente produits distincts, dont vingt-neuf seront des doublons de contenu.
Le **prix est identique** et les images se ressemblent. L'éclatement n'apporte alors ni contenu unique ni argument commercial.
## Les cinq critères qui justifient l'éclatement
À l'inverse, éclatez quand au moins deux de ces critères sont réunis.
1. **La variante fait l'objet de recherches propres.** Vérifiez-le dans vos logs de recherche interne et dans la Search Console : si « canapé velours vert » génère des requêtes, la couleur mérite sa page.
2. **Le prix diffère significativement** entre les variantes. Un écart de plus de 20 % rend l'affichage d'un prix unique trompeur en listing et fausse les filtres de prix.
3. **Les images sont entièrement différentes.** Une fiche unique impose de charger toutes les images de toutes les variantes, ou de n'en montrer qu'une partie.
4. **Le contenu descriptif diffère.** Matières, entretien, usages : quand le texte change réellement d'une variante à l'autre, la fiche unique devient un compromis illisible.
5. **Les places de marché ou comparateurs exigent des références distinctes**, ce qui est le cas de la plupart des flux produits sérieux.
## Ce que vous gagnez
Le gain principal est le référencement : une page par variante, avec son titre, son contenu et ses images, capte des requêtes que la fiche unique ne pouvait pas viser.
Trois gains secondaires, souvent plus immédiats. La grille de catégorie affiche chaque variante avec son visuel propre, ce qui augmente le taux de clic. Les filtres à facettes deviennent exacts, alors qu'une fiche à déclinaisons apparaît dans tous les filtres de couleur simultanément. Et le stock se lit directement, sans avoir à ouvrir le sélecteur.
## Ce que vous perdez
Il faut l'assumer, ce n'est pas neutre.
Le client perd le sélecteur qui lui permettait de basculer d'une couleur à l'autre sans quitter la page. Ce point se compense par un bloc de liens entre variantes, sur lequel nous revenons plus bas.
Vous multipliez les fiches à maintenir. Une modification de description doit être répercutée sur chaque variante, ce qui suppose un outil de modification en masse.
Et vous créez du risque de contenu dupliqué si les descriptions restent identiques. C'est la contrepartie directe du gain SEO : éclater sans différencier le contenu produit l'effet inverse de celui recherché.
## La procédure, dans l'ordre
L'ordre des opérations compte, parce qu'une étape ratée est difficile à rattraper.
**1. Relever les URL existantes** de la fiche à éclater, y compris les variantes accessibles par paramètre. Vous en aurez besoin pour les redirections.
**2. Créer les nouveaux produits** avec leurs références propres, leur stock, leurs images et leur prix. Le stock de la déclinaison devient le stock du produit.
**3. Différencier les contenus.** C'est l'étape qui prend du temps et qui décide de la réussite. Au minimum, le titre, le premier paragraphe et les métadonnées doivent être propres à chaque variante.
**4. Rattacher aux catégories** et vérifier les positions, qui repartent en fin de grille.
**5. Rediriger l'ancienne fiche** vers la variante la plus vendue, en 301. C'est elle qui hérite de l'historique de la page d'origine.
**6. Mettre à jour les liens internes** qui pointaient vers l'ancienne fiche : blocs d'accessoires, articles de blog, pages CMS.
**7. Régénérer les flux** vers Google et les places de marché, avec les nouvelles références.
## Le lien entre les variantes
Point à ne pas négliger, sous peine de dégrader l'expérience. Chaque fiche issue de l'éclatement doit afficher un bloc « autres coloris » ou « autres versions », avec les vignettes et les liens vers ses sœurs.
Ce bloc remplit deux fonctions : il rend au client la navigation entre variantes qu'il a perdue, et il crée un maillage interne entre des pages qui traitent du même produit, ce qui aide les moteurs à comprendre leur relation.
## Le cas des redirections multiples
Si vos variantes étaient accessibles par des URL distinctes avec paramètres, chacune doit être redirigée vers sa nouvelle fiche, pas vers la fiche principale. C'est le seul moyen de conserver le positionnement acquis par chaque variante.
Vérifiez ces redirections une par une après la bascule : une redirection vers une page qui redirige elle-même perd de la valeur et ralentit l'exploration.
Le automatise cette procédure sur PrestaShop 8 et 9 : création des produits à partir des combinaisons avec reprise du stock, des images et des prix, rattachement aux catégories et génération des redirections des anciennes URL.
---
### Comment réorganiser les produits d'une catégorie PrestaShop en drag & drop ?
_Source :_ — _publié_ 2026-09-06
> Remonter un produit de la position 40 à la position 2 demande trente-huit clics dans le back-office natif. Comment PrestaShop stocke les positions, ce qui les écrase sans prévenir, et sur quels critères ordonner une grille.
L'ordre d'affichage d'une catégorie est un levier commercial direct : les trois premiers produits d'une grille concentrent l'essentiel des clics. PrestaShop permet de le contrôler, mais l'outil natif rend l'exercice pénible dès qu'une catégorie dépasse une trentaine de références.
## Comment PrestaShop stocke la position
Chaque produit possède une position par catégorie, et non une position globale. Un même produit peut donc être premier dans une catégorie et vingtième dans une autre, ce qui est exactement le comportement souhaité.
Cette position n'est utilisée que si le tri par défaut de la boutique est réglé sur « position ». Dans les paramètres du catalogue, si le tri par défaut est « prix croissant » ou « nom », tout votre travail de positionnement est ignoré côté visiteur.
C'est la première vérification à faire, et elle explique la plupart des cas où le classement manuel « ne fonctionne pas ».
## Les limites du back-office natif
L'interface existe : dans une catégorie, la liste des produits affiche des flèches de déplacement. Trois limites la rendent inutilisable à l'échelle.
**Un déplacement d'une position à la fois.** Remonter un produit de la position 40 à la position 2 demande trente-huit clics, chacun avec un rechargement.
**Aucune vue d'ensemble.** Vous voyez une liste texte, pas la grille telle que le client la verra. Or l'ordre se juge visuellement, en particulier quand les images se répondent.
**Aucune information de décision.** La liste n'affiche ni le stock, ni la marge, ni les ventes récentes. Vous ordonnez à l'aveugle.
## Ce qui écrase vos positions
Quatre opérations réinitialisent tout ou partie du travail, et elles sont fréquentes.
1. **L'import CSV.** Selon les options choisies, un import peut réattribuer les positions dans l'ordre du fichier. C'est la cause la plus fréquente de perte, et elle passe inaperçue jusqu'à ce que quelqu'un regarde la catégorie.
2. **L'ajout d'un produit à la catégorie.** Le nouveau produit se place en fin de liste, ce qui est logique, mais un ajout en masse renvoie toutes vos nouveautés en dernière page.
3. **La suppression ou la désactivation.** Elle laisse un trou dans la numérotation, sans conséquence directe, mais qui complique les traitements automatisés.
4. **Le changement de catégorie par défaut d'un produit**, qui peut modifier son rattachement et donc sa position.
La parade tient en une règle : après tout import, vérifiez une catégorie témoin. Trente secondes qui évitent de découvrir le problème trois semaines plus tard.
## Quelle stratégie de tri
Ordonner manuellement suppose de savoir sur quoi. Quatre approches, à combiner.
**Par marge.** Placer en tête les produits qui rapportent le plus par vente. Efficace, mais à surveiller : si ce sont aussi les plus chers, vous dégradez le taux de conversion de la catégorie.
**Par rotation.** Les meilleures ventes en tête. C'est le réflexe naturel, et il s'auto-renforce : un produit bien placé se vend, donc reste bien placé, ce qui enferme votre catalogue.
**Par nouveauté.** Utile sur les univers saisonniers ou de mode, contre-productif sur un catalogue technique où le client cherche une référence établie.
**Par disponibilité.** Règle transversale à appliquer dans tous les cas : les produits en rupture descendent en fin de grille. Un produit épuisé en première position gâche l'emplacement le plus précieux de la page.
Une approche mixte fonctionne bien : trois à six emplacements ordonnés manuellement selon votre stratégie du moment, puis un tri automatique pour le reste.
## Le cas des produits en rupture
Il mérite une décision explicite, et deux options se défendent.
Les **reléguer en fin de grille** tout en les laissant visibles conserve leur référencement et permet de collecter des inscriptions à l'alerte de retour en stock.
Les **retirer de la catégorie** améliore l'expérience immédiate mais fait disparaître des pages qui reçoivent du trafic, et casse les liens externes.
La première option est presque toujours préférable, à condition que la rupture soit annoncée clairement sur la vignette et pas seulement sur la fiche.
## Mesurer
Deux indicateurs suffisent pour savoir si votre travail de positionnement produit un effet.
Le **taux de clic par position** dans la grille, qui vous donne la valeur réelle de chaque emplacement sur votre boutique. Elle décroît fortement après les premières lignes, et la pente varie selon les catégories.
Le **chiffre d'affaires par emplacement**, qui permet de comparer deux stratégies de tri sur la même catégorie à deux périodes comparables.
Le traite cette gestion sur PrestaShop 8 et 9 : réorganisation par glisser-déposer dans une vue en grille, affichage du stock et des ventes pour décider, et conservation des positions après les imports.
---
### Recherche sémantique sur PrestaShop : principe et mise en place
_Source :_ — _publié_ 2026-09-05
> Rapprocher « chargeur voiture » et « adaptateur allume-cigare » sans déclarer de synonyme : le principe, ce qu'il faut vectoriser, et surtout pourquoi il ne faut pas remplacer la recherche existante mais la combiner.
La recherche interne classique compare des chaînes de caractères. Elle trouve les produits dont le texte contient les mots saisis, et rien d'autre. La recherche sémantique compare des sens : elle rapproche « chargeur voiture » et « adaptateur allume-cigare » sans qu'aucun synonyme n'ait été déclaré.
Voici comment cela fonctionne réellement, ce que cela coûte, et où cela reste moins bon que le classique.
## Le principe, sans jargon
Chaque produit de votre catalogue est transformé en une suite de nombres, appelée vecteur, qui représente son sens. Deux produits proches par le sens produisent des vecteurs proches dans cet espace.
Quand un visiteur cherche quelque chose, sa requête est transformée de la même façon, puis le moteur cherche les vecteurs les plus proches. Aucune correspondance de mots n'est nécessaire : c'est la proximité de sens qui décide.
Cette transformation est produite par un modèle de langue, entraîné sur d'énormes volumes de texte, qui a appris que certains termes apparaissent dans les mêmes contextes. C'est ce qui lui permet de savoir qu'un allume-cigare et un chargeur voiture relèvent du même usage.
## Ce que cela résout
Trois situations où le moteur classique échoue systématiquement.
**Le vocabulaire différent.** Le client emploie ses mots, votre catalogue emploie ceux du fournisseur. Sans synonymes déclarés, aucun résultat. C'est le cas le plus fréquent et le plus coûteux.
**La requête descriptive.** « Quelque chose pour ranger des outils dans un garage » ne contient aucun mot de votre catalogue, mais décrit précisément un besoin. Le moteur lexical renvoie du bruit ou rien.
**La faute de frappe et la variation.** Pluriels, conjugaisons, orthographes approximatives sont absorbés par la représentation vectorielle sans réglage particulier.
## Ce qu'il faut vectoriser
Question qui détermine la qualité des résultats bien plus que le choix du modèle.
Le minimum utile : le nom du produit, sa description courte, sa catégorie et ses attributs principaux. La description longue apporte du contexte mais aussi du bruit, en particulier quand elle contient des conditions de livraison ou des mentions légales identiques sur toutes les fiches.
Un principe simple : ne vectorisez que ce qui distingue le produit. Tout texte présent à l'identique sur cent fiches rapproche artificiellement ces cent fiches les unes des autres et dégrade la pertinence.
Les caractéristiques techniques méritent un traitement particulier. Un modèle de langue comprend mal les nombres et les unités : « 120 cm » et « 140 cm » lui paraissent très proches. C'est une limite structurelle, pas un défaut de configuration.
## Le point le plus important : ne pas remplacer, combiner
C'est l'erreur de conception classique. La recherche sémantique n'est pas meilleure que la recherche lexicale, elle est différente, et elle est nettement moins bonne sur certains cas.
Sur une **référence exacte**, un code produit, un numéro de pièce, un code-barres, le lexical gagne toujours. Le vectoriel ne comprend pas qu'une suite de caractères doit correspondre exactement.
Sur les **valeurs numériques**, taille, poids, dimension, puissance, le lexical associé à des filtres reste supérieur.
Sur un **nom de marque**, le lexical est plus fiable, le vectoriel ayant tendance à ramener des marques concurrentes du même univers.
L'architecture qui fonctionne combine les deux : une recherche lexicale d'abord, complétée par la couche vectorielle quand elle renvoie peu ou pas de résultats, ou fusionnée avec une pondération. Une boutique qui bascule entièrement en sémantique voit ses recherches par référence se dégrader, et ce sont souvent celles de ses meilleurs clients.
## Le coût, en clair
Trois postes, d'ampleurs très différentes.
**L'indexation initiale.** Chaque produit doit être vectorisé une fois. Sur un catalogue de dix mille références, l'opération représente un coût unitaire faible mais réel, et un temps de traitement de quelques heures.
**La mise à jour.** Seuls les produits modifiés doivent être revectorisés. Une réindexation complète à chaque import est une erreur coûteuse : détectez les changements réels sur les champs vectorisés.
**Les requêtes.** Chaque recherche visiteur suppose de vectoriser la requête. C'est le poste qui monte avec le trafic, et celui qu'il faut regarder avant de se lancer. Un cache des requêtes fréquentes le réduit fortement, une part importante des recherches d'une boutique étant répétitive.
## Mesurer avant et après
Trois indicateurs, relevés sur les trente jours qui précèdent la mise en place.
Le **taux de recherches sans résultat**, qui doit baisser nettement. C'est le gain le plus visible et le plus immédiat.
Le **taux de clic sur le premier résultat**, qui mesure la pertinence perçue. S'il baisse alors que le taux de résultats monte, votre moteur renvoie des produits proches mais pas pertinents.
Le **taux de conversion des sessions avec recherche**, seul chiffre qui justifie l'investissement.
Un quatrième contrôle, qualitatif : constituez une liste de trente requêtes réelles issues de vos logs, avec le résultat attendu, et rejouez-la après chaque modification. C'est le seul moyen de constater une régression avant vos clients.
Le met en place cette couche sur PrestaShop 8 et 9 : indexation vectorielle du catalogue avec sélection des champs, combinaison avec la recherche lexicale existante, produits similaires calculés sur le sens, et tableau de bord des requêtes avec leur taux de résultat.
---
### Migrer de PrestaShop 8 vers PrestaShop 9 : l'audit des modules
_Source :_ — _publié_ 2026-09-05
> Une migration majeure ne se joue pas sur le cœur de PrestaShop mais sur vos modules. L'inventaire à produire avant tout devis, les quatre catégories de traitement, les ruptures techniques fréquentes et le plan de test par parcours.
Une migration de version majeure ne se joue pas sur le cœur de PrestaShop, qui se met à jour correctement dans la plupart des cas. Elle se joue sur vos modules. Sur une boutique qui en compte quarante, il suffit qu'un seul touche au tunnel de commande et ne soit plus compatible pour que la migration soit bloquée.
L'audit des modules doit donc précéder tout le reste, y compris le devis.
## Ce qui change réellement
PrestaShop 9 s'appuie sur des versions plus récentes de PHP et de Symfony, ce qui entraîne trois familles de ruptures.
**Les ruptures liées à PHP.** Typage plus strict, propriétés dynamiques dépréciées, fonctions retirées. Un module écrit il y a cinq ans et jamais repris produit des erreurs fatales, pas des avertissements.
**Les ruptures liées au framework.** Les modules qui étendent des contrôleurs Symfony ou qui déclarent des services doivent suivre la nouvelle version. C'est le cas des modules récents et bien construits, paradoxalement plus exposés que les modules purement legacy.
**Les ruptures propres à PrestaShop.** Méthodes supprimées des classes historiques, hooks retirés ou renommés, changements dans les templates du thème par défaut.
## L'inventaire, premier livrable
Avant toute manipulation, produisez un tableau avec une ligne par module et six colonnes.
1. **Nom technique et version installée.**
2. **Éditeur**, et son existence actuelle. Un éditeur disparu est un module condamné.
3. **Date de la dernière mise à jour** disponible. Au-delà de dix-huit mois sans publication, considérez le module comme abandonné jusqu'à preuve du contraire.
4. **Compatibilité annoncée** avec la version cible, en distinguant ce qui est écrit sur la fiche produit de ce qui est réellement testé.
5. **Criticité** : le module touche-t-il au paiement, au tunnel, au catalogue, ou seulement à un affichage secondaire ?
6. **Présence d'overrides**, visible dans le dossier des surcharges. C'est le meilleur indicateur de fragilité.
Ce tableau se remplit en une demi-journée et il détermine tout le reste du projet.
## Les quatre catégories
Chaque module tombe dans l'une d'elles, et le traitement diffère.
**Compatible et maintenu.** Vous mettez à jour et vous testez. C'est le cas le plus simple, et il représente rarement la majorité.
**Compatible annoncé mais non vérifié.** La mention sur la fiche produit ne vaut pas recette. Ces modules doivent être testés en priorité, parce qu'une incompatibilité découverte tard coûte un report.
**Abandonné.** Deux issues : trouver un remplaçant, ou faire reprendre le code. La reprise n'a de sens que si la fonctionnalité est spécifique à votre activité.
**Remplaçable par du natif.** Catégorie systématiquement sous-estimée. Chaque version majeure intègre des fonctions qui existaient auparavant sous forme de modules. Une migration est le bon moment pour désinstaller ce qui ne sert plus.
Sur les audits réels, ce dernier tri retire souvent entre cinq et dix modules de la liste, ce qui allège d'autant le projet.
## Les pièges techniques les plus fréquents
Pour les développeurs et les agences, quatre ruptures reviennent constamment sur les modules à reprendre.
La méthode de traduction disponible directement sur les contrôleurs a disparu : il faut passer par l'instance du module. Les surcharges de méthodes dont la signature a changé produisent des erreurs de compatibilité, notamment sur les méthodes de rendu utilisées pour les réponses asynchrones. Les appels asynchrones aux contrôleurs d'administration historiques ont changé de forme et exigent que les paramètres soient passés différemment. Et les modules qui écrivaient directement dans des tables du cœur se heurtent aux évolutions de schéma.
Aucune de ces corrections n'est complexe prise isolément. Le coût vient du nombre.
## L'environnement de recette
Non négociable, et pourtant régulièrement sauté.
Il doit reposer sur une copie récente de la base de production, pas sur un jeu de démonstration. La plupart des incompatibilités apparaissent sur des données réelles : produits avec cent déclinaisons, clients avec des adresses incomplètes, commandes dans des statuts oubliés.
Deux précautions : anonymisez les données clients avant de copier, et désactivez tout envoi d'email depuis cet environnement. Un test de migration qui envoie deux mille emails de changement de statut à de vrais clients est une histoire vraie et fréquente.
## Le plan de test
Testez des parcours, pas des pages. Six parcours couvrent l'essentiel.
Une commande complète en tant que visiteur non connecté, avec paiement réel en environnement de test. Une commande avec un compte existant et une adresse enregistrée. Un ajout au panier depuis une page catégorie avec filtres actifs. Une recherche interne suivie d'un achat. Un retour ou une demande de service après-vente. Et côté administration, la création d'un produit avec déclinaisons et la validation d'une commande.
Chaque parcours doit être joué sur desktop et sur mobile. Comptez une journée pour l'ensemble, à refaire après chaque correction significative.
## La bascule et l'après
Prévoyez la migration en dehors des périodes commerciales, avec une fenêtre de retour arrière définie et testée. Une sauvegarde qui n'a jamais été restaurée ne compte pas.
Les jours suivants, trois contrôles s'imposent. Les journaux d'erreur du serveur, qui révèlent les incompatibilités que la recette n'a pas rencontrées. Les liens et images cassés, car un changement de version peut affecter les chemins d'images et les URL réécrites. Et le suivi des commandes, à comparer au niveau habituel : une chute brutale signale un blocage dans le tunnel que personne n'a signalé.
Sur ce dernier point, le est utile en phase de recette comme après la bascule : il détecte les liens internes cassés et les images manquantes que la migration a pu produire, sur PrestaShop 8 comme sur PrestaShop 9.
---
### GA4 e-commerce sur PrestaShop : les 7 événements à câbler
_Source :_ — _publié_ 2026-09-04
> Une boutique qui n'envoie que l'achat dispose d'un chiffre d'affaires et de rien d'autre. Les sept événements qui reconstituent la chaîne, la structure des articles à tenir partout, les erreurs classiques et l'écart normal avec le back-office.
Une boutique qui n'envoie que l'événement d'achat à GA4 dispose d'un chiffre d'affaires et de rien d'autre. Aucun taux d'abandon par étape, aucun produit vu sans être ajouté, aucune analyse de la performance des listes. La valeur de GA4 sur une boutique vient de la chaîne complète, pas du dernier maillon.
Sept événements suffisent à la reconstituer.
## Les sept événements
1. **view_item_list** : affichage d'une liste de produits, catégorie, résultats de recherche, bloc de recommandations. Il permet de comparer la performance des emplacements entre eux.
2. **select_item** : clic sur un produit depuis une liste. Couplé au précédent, il donne le taux de clic par liste.
3. **view_item** : consultation d'une fiche produit. La base de tout le reste.
4. **add_to_cart** : ajout au panier. Rapporté à view_item, il donne le taux d'ajout, indicateur le plus utile au niveau produit.
5. **begin_checkout** : entrée dans le tunnel. C'est la borne qui sépare la navigation de l'achat.
6. **add_payment_info** : choix du moyen de paiement. Le dernier point de mesure avant la validation, et celui qui isole les abandons liés au paiement.
7. **purchase** : commande validée, avec le détail des articles.
Un huitième mérite d'être ajouté quand il est simple à câbler : **remove_from_cart**, qui signale les produits retirés au moment de découvrir les frais de port.
## La structure des articles
Tous ces événements partagent la même structure de description des articles, et la cohérence entre eux est ce qui fait la différence entre des données exploitables et un rapport illisible.
Cinq paramètres comptent par article : l'identifiant, le nom, la catégorie, le prix unitaire et la quantité. Deux autres sont utiles : la marque et la variante.
**L'identifiant est le point critique.** Il doit être strictement le même dans tous les événements, et surtout identique à celui utilisé dans votre flux produit vers Google. Une boutique qui envoie la référence dans un événement et l'identifiant interne dans un autre obtient deux fiches produit distinctes dans ses rapports, pour le même article.
**La déclinaison doit être traitée explicitement.** Décidez si l'identifiant porte sur le produit ou sur la déclinaison, et tenez cette règle partout. Les deux choix se défendent, le mélange non.
## Prix hors taxes ou toutes taxes comprises
Question qui n'a pas de réponse universelle et qui doit être tranchée avant le câblage.
La convention la plus courante en Europe consiste à envoyer les prix toutes taxes comprises, parce que c'est ce que le client paie et ce qui figure sur la commande. L'alternative, hors taxes, facilite le rapprochement avec la comptabilité.
Ce qui compte davantage que le choix : que la valeur de la commande soit calculée de la même façon, et que vous sachiez laquelle vous avez retenue quand vous comparerez GA4 à votre back-office six mois plus tard.
Deux éléments à exclure de la valeur de la transaction : les frais de port et les taxes se déclarent dans des paramètres dédiés, pas dans le montant total. Les inclure gonfle artificiellement le chiffre d'affaires produit.
## Les erreurs classiques
**L'achat compté deux fois.** La page de confirmation rechargée ou remise en cache renvoie l'événement. C'est de loin l'anomalie la plus fréquente, et elle fausse le chiffre d'affaires à la hausse. La protection consiste à marquer la commande comme déjà envoyée, côté serveur ou en stockage local, et à ne jamais déclencher l'événement deux fois pour un même identifiant de transaction.
**L'identifiant de transaction absent ou non unique.** Sans lui, GA4 ne peut pas dédoublonner. Utilisez la référence de commande, jamais un horodatage.
**Les frais de port dans la valeur.** Voir plus haut.
**L'événement d'achat déclenché avant la validation du paiement.** Sur un paiement redirigé, la commande peut échouer après l'envoi de l'événement. Le déclenchement doit se faire sur la page de confirmation réelle, après retour du prestataire.
**Les listes non nommées.** Si toutes vos listes portent le même nom, vous ne saurez jamais si vos blocs de recommandation fonctionnent.
## Le consentement
Sans consentement, aucun de ces événements ne doit partir avec des identifiants. Le mode de consentement permet de conserver une mesure agrégée en l'absence de consentement, à condition qu'il soit correctement câblé et que les signaux soient transmis avant le chargement des balises.
Un point pratique souvent découvert trop tard : si votre bandeau bloque les scripts jusqu'au consentement, les événements déclenchés pendant ce délai sont perdus. Prévoyez une file d'attente qui les rejoue après acceptation, plutôt que de les laisser tomber.
## Vérifier
Trois niveaux de contrôle, à faire dans cet ordre.
**La couche de données.** Dans la console du navigateur, inspectez son contenu à chaque étape et vérifiez la présence et la forme des paramètres. C'est là que se voient les identifiants incohérents et les prix mal formatés.
**Le mode de débogage de GA4.** Il affiche les événements en temps réel avec leurs paramètres, et signale ceux qui sont rejetés. Passez une commande complète en observant cet écran.
**Le rapprochement chiffré.** Après deux semaines, comparez le nombre de commandes et le chiffre d'affaires de GA4 avec votre back-office.
## L'écart normal avec le back-office
Ne cherchez pas l'égalité parfaite, elle n'existe pas. Un écart de 5 à 15 % en moins dans GA4 est attendu, et il s'explique : refus de consentement, bloqueurs de publicité, navigations privées, commandes prises par téléphone, et clients quittant la page avant l'envoi de l'événement.
Ce qui doit vous alerter, c'est un écart supérieur à 25 %, ou un écart _positif_, GA4 comptant plus de commandes que votre back-office. Le second signale presque toujours un double comptage.
Le câble cette chaîne sur PrestaShop 8 et 9 : les événements e-commerce avec une structure d'articles cohérente, la protection contre le double envoi de l'achat, et l'articulation avec le consentement.
---
### Accessibilité PrestaShop et EAA : que doit vérifier une boutique e-commerce ?
_Source :_ — _publié_ 2026-09-04
> L'EAA est applicable depuis juin 2025 et couvre explicitement le commerce électronique. Qui est réellement concerné, les douze blocages qui reviennent sur toutes les boutiques, une méthode d'audit en une journée et ce qu'un widget ne peut pas faire.
L'European Accessibility Act est applicable depuis le 28 juin 2025. Il couvre explicitement les services de commerce électronique, ce qui inclut une boutique en ligne, son tunnel de commande et ses documents contractuels. Ce n'est pas une recommandation : c'est une obligation avec un régime de sanctions.
La plupart des marchands concernés ne le savent pas, ou pensent l'être sans l'être. Commençons par là.
## Qui est concerné
Le texte vise les entreprises qui fournissent des services de commerce électronique aux consommateurs. Une exemption existe pour les **microentreprises** fournissant des services, définies comme employant moins de dix personnes et réalisant un chiffre d'affaires annuel ou un total de bilan n'excédant pas deux millions d'euros.
Deux précisions qui font la différence. L'exemption s'apprécie sur l'entreprise entière, pas sur l'activité en ligne. Et elle porte sur les services : les obligations applicables aux produits relèvent d'un régime distinct.
Un point de méthode : si vous êtes proche des seuils, ne construisez pas votre planning sur l'exemption. Une croissance vous fait basculer, et une mise en conformité ne s'improvise pas en trois semaines.
## Le référentiel applicable
La norme européenne de référence renvoie, pour le web, aux critères des règles internationales d'accessibilité au niveau AA. En France, le référentiel général d'amélioration de l'accessibilité en constitue la déclinaison opérationnelle, avec une grille de critères testables.
Ce point est utile en pratique : plutôt que de partir des principes, partez de la grille. Elle transforme un sujet abstrait en une liste de vérifications.
## Les douze blocages les plus fréquents sur une boutique
Sur les audits de boutiques, les mêmes points reviennent. Les voici, par ordre de fréquence décroissante.
1. **Contrastes insuffisants** sur les textes secondaires, les prix barrés et les mentions légales.
2. **Images de produits sans texte alternatif**, ou avec un texte alternatif reprenant le nom du fichier.
3. **Champs de formulaire sans étiquette associée**, notamment dans le tunnel de commande où seul un texte de substitution fait office de libellé.
4. **Focus clavier invisible**, souvent supprimé par le thème pour des raisons esthétiques.
5. **Navigation impossible au clavier** sur les menus déroulants et les sélecteurs de déclinaisons.
6. **Messages d'erreur non annoncés** aux technologies d'assistance : le champ devient rouge, rien n'est vocalisé.
7. **Carrousels sans contrôle**, qui défilent automatiquement sans possibilité d'arrêt.
8. **Hiérarchie de titres incohérente**, avec des niveaux sautés ou utilisés pour la mise en forme.
9. **Liens non explicites** hors contexte, du type « en savoir plus » répété vingt fois sur une page catégorie.
10. **Information portée par la couleur seule** : disponibilité en vert, rupture en rouge, sans texte.
11. **Vidéos sans sous-titres** ni transcription.
12. **Zoom bloqué** sur mobile par une balise de configuration d'affichage.
Les quatre premiers représentent l'essentiel du volume d'anomalies, et ils sont tous corrigeables sans refonte.
## Une méthode d'audit en une journée
Un audit complet est un projet. Un premier état des lieux tient dans une journée et suffit à savoir où vous en êtes.
**Matin : les tests automatiques.** Passez un outil d'analyse sur cinq pages types, accueil, catégorie, fiche produit, panier, tunnel de commande. Les outils automatiques détectent environ un tiers des critères, essentiellement les contrastes, les alternatives manquantes et les étiquettes de formulaire. C'est peu, mais c'est le tiers le plus volumineux.
**Début d'après-midi : le test clavier.** Débranchez la souris et passez une commande complète en n'utilisant que la tabulation et la touche d'entrée. Cet exercice, qui prend vingt minutes, révèle davantage de problèmes bloquants que n'importe quel outil.
**Fin d'après-midi : le test au lecteur d'écran.** Activez le lecteur d'écran de votre système et parcourez une fiche produit. L'objectif n'est pas de tout corriger mais de constater : si le prix, la disponibilité et le bouton d'achat ne sont pas annoncés correctement, vous savez par quoi commencer.
À l'issue de cette journée, vous disposez d'une liste priorisée et d'une idée réaliste de l'effort restant.
## Ce qu'un widget peut faire, et ce qu'il ne peut pas
Point d'honnêteté nécessaire, parce que le marché entretient une confusion.
Une surcouche d'accessibilité traite efficacement un sous-ensemble de critères : correction de contrastes, ajout d'étiquettes manquantes, restauration du focus visible, options de confort comme l'agrandissement du texte ou l'espacement des lignes. Sur les douze blocages listés plus haut, elle en couvre correctement quatre à six.
Elle ne peut pas réparer une structure de titres incohérente, rendre navigable au clavier un composant qui ne l'est pas, rédiger des textes alternatifs pertinents, ni sous-titrer une vidéo. Aucun outil automatique ne rend un site conforme, et présenter une surcouche comme une mise en conformité complète est un argument à écarter.
Ce qu'elle apporte réellement : un gain immédiat sur les anomalies les plus nombreuses, pendant que la remédiation de fond se planifie sur le thème.
## La déclaration d'accessibilité
Obligation souvent ignorée : les entités concernées doivent publier une déclaration décrivant l'état de conformité du service, les contenus non accessibles avec leur justification, et un moyen de contact pour signaler un problème.
Une déclaration honnête mentionnant une conformité partielle vaut mieux qu'une absence de déclaration, et mieux qu'une déclaration de conformité totale démentie par le premier test.
## Par quoi commencer
Dans l'ordre : les contrastes, qui sont massifs et faciles ; les étiquettes de formulaire du tunnel de commande, parce qu'un tunnel inutilisable rend le service inaccessible au sens strict ; le focus clavier ; puis les textes alternatifs des images produits, chantier long mais fractionnable.
Le intervient sur PrestaShop 8 et 9 : corrections automatiques des contrastes, étiquettes et focus, options de confort utilisateur, et rapport des anomalies détectées pour cadrer la remédiation qui reste à faire sur le thème.
---
### Maillage interne e-commerce : des catégories vers les fiches produit
_Source :_ — _publié_ 2026-09-03
> Le flux descendant de la catégorie vers les produits se fait tout seul. Le flux remontant, celui qui fait exister vos pages catégories, est presque toujours absent. Les quatre flux à construire, les règles d'ancre et ce qui s'automatise vraiment.
Le maillage interne est le seul levier SEO entièrement sous votre contrôle. Il ne dépend d'aucun tiers, il ne s'achète pas, et il agit sur deux choses à la fois : la façon dont les moteurs répartissent l'importance entre vos pages, et la profondeur à laquelle un visiteur trouve ce qu'il cherche.
Sur une boutique, il se construit rarement, et presque jamais dans les deux sens.
## Le principe du silo
Une boutique a une structure naturelle à trois niveaux : accueil, catégories, fiches produits. Le maillage consiste à faire circuler la valeur dans cette structure plutôt qu'à la laisser stagner.
Deux flux existent, et le second est presque toujours absent.
**Le flux descendant**, de la catégorie vers les produits, se fait tout seul : la grille de produits est un maillage. Il est massif mais non hiérarchisé, chaque produit recevant le même traitement.
**Le flux remontant**, du produit vers la catégorie, est celui qui manque. Un fil d'Ariane le crée faiblement. Un lien contextuel dans la description, un bloc « voir toute la gamme », une mention de la catégorie parente dans le contenu font bien davantage.
Sans flux remontant, vos pages catégories dépendent uniquement du menu pour exister, alors qu'elles portent les requêtes à plus fort volume.
## Les quatre flux à construire
1. **Catégorie vers produits** : existant, à hiérarchiser. Les produits mis en avant en tête de grille reçoivent plus de valeur que ceux de la page 4. Ce choix devrait suivre votre stratégie, pas l'ordre par défaut.
2. **Produit vers catégorie** : à construire. C'est celui qui a le meilleur rapport effort sur résultat, parce qu'il se génère automatiquement à partir de la catégorie principale du produit.
3. **Produit vers produit** : accessoires, produits similaires, souvent achetés ensemble. Il fait circuler la valeur latéralement et améliore la découverte.
4. **Contenu vers produit** : depuis les articles de blog, les guides, les pages d'aide. C'est le flux le plus qualitatif, parce que le lien est contextuel et entouré de texte pertinent.
## Les ancres
Trois règles, dont la première est la plus enfreinte.
**Variez les formulations.** Trois cents fiches produits qui pointent toutes vers la même catégorie avec exactement la même ancre constituent un signal artificiel. Alternez entre le nom exact de la catégorie, une formulation descriptive, et une variante.
**L'ancre décrit la destination.** « Cliquez ici » et « en savoir plus » n'apportent rien, ni au moteur ni au lecteur. « Toute notre gamme de perceuses sans fil » indique où l'on va.
**Restez naturel.** Une ancre sur-optimisée, qui empile les mots-clés, se repère immédiatement et dégrade la lecture. Si la phrase sonne mal lue à voix haute, l'ancre est mauvaise.
## Combien de liens par page
La question revient toujours, et il n'existe pas de chiffre magique. Deux principes utilisables à la place.
**La valeur transmise se divise.** Une page qui émet deux cents liens en transmet peu à chacun. Sur une fiche produit, une dizaine de liens contextuels bien choisis valent mieux qu'un pied de page à cent entrées.
**Le pied de page compte.** Un méga pied de page répété sur toutes les pages génère un maillage uniforme qui ne hiérarchise rien. Il n'est pas nocif en soi, mais il ne remplace pas des liens contextuels et il dilue le reste.
Un repère pratique : sur une fiche produit, comptez les liens hors navigation et pied de page. S'il y en a moins de cinq, votre maillage contextuel est inexistant.
## Ce qui s'automatise et ce qui ne s'automatise pas
**S'automatise bien** : le lien du produit vers sa catégorie principale, le lien vers la marque, les blocs de produits similaires calculés sur des données réelles, le fil d'Ariane enrichi.
**Demande une intervention** : les liens contextuels dans les descriptions, les liens depuis les articles de blog, et les liens transversaux entre univers qui n'ont pas de relation dans votre base.
Un dispositif intermédiaire fonctionne bien : un lexique de termes métier, où chaque terme défini une fois est automatiquement lié depuis toutes les descriptions qui l'emploient. Vous obtenez un maillage contextuel à grande échelle sans réécrire les fiches.
## Les pièges
**Les liens en JavaScript.** Un bloc de produits similaires chargé au clic ou au défilement peut ne pas être vu. Le lien doit exister dans le HTML initial.
**Les liens vers des pages non indexables.** Pointer massivement vers des pages en noindex ou bloquées gaspille la valeur transmise.
**Les chaînes de redirection.** Un lien interne qui passe par une redirection perd de la valeur et ralentit l'exploration. Après une refonte, les liens internes doivent pointer vers les nouvelles adresses, pas vers les anciennes.
**Les pages orphelines.** Des pages qui n'ont aucun lien entrant existent sur presque toutes les boutiques : anciennes catégories, pages CMS, produits sortis du menu. Elles ne sont accessibles que par le sitemap, ce qui ne suffit pas.
## Mesurer
Trois indicateurs, obtenus avec un crawler.
**La profondeur de clic** depuis l'accueil. Toute page importante devrait être atteignable en trois clics. Au-delà de cinq, elle est traitée comme secondaire.
**Le nombre de liens internes entrants par page**, comparé à son importance commerciale. Un décalage entre les deux est votre plan de travail : vos meilleures pages devraient être les mieux liées.
**Le nombre de pages orphelines**, à ramener à zéro ou à assumer explicitement.
Le automatise une partie de ce maillage sur PrestaShop 8 et 9 : lexique de termes métier avec infobulles dans les descriptions et liens automatiques vers les produits et catégories concernés. Sur l'axe des marques, le construit le flux des fiches vers leur page de marque.
---
### Comment gérer les DLC, DDM/DLUO et numéros de lot dans PrestaShop ?
_Source :_ — _publié_ 2026-09-03
> La date n'appartient pas au produit, elle appartient au lot : c'est ce qui fait échouer les implémentations naïves. Distinguer DLC, DDM et numéro de lot, la règle FEFO en préparation, et ce qui rend un rappel produit ciblé possible.
Vendre de l'alimentaire, du cosmétique ou du produit chimique en ligne suppose de gérer une donnée que PrestaShop ignore : la date. Pas la date de commande, celle du produit lui-même, qui varie d'un lot à l'autre et qui détermine ce que vous pouvez expédier.
## Trois notions à ne pas confondre
**La DLC**, date limite de consommation, s'exprime par « à consommer jusqu'au ». Elle concerne les denrées très périssables. Au-delà de cette date, la denrée est réputée dangereuse : sa vente est interdite, et sa remise à titre gratuit également.
**La DDM**, date de durabilité minimale, anciennement DLUO, s'exprime par « à consommer de préférence avant ». Elle concerne les produits stables. Son dépassement n'interdit pas la vente : le produit reste consommable, il peut simplement avoir perdu des qualités gustatives ou nutritionnelles. La vente après DDM est licite à condition que le consommateur en soit informé, et elle est courante en déstockage anti-gaspillage.
**Le numéro de lot** n'est pas une date. C'est un identifiant qui permet de retrouver l'ensemble des unités produites dans les mêmes conditions. Il est obligatoire sur la plupart des denrées préemballées et il constitue la base de toute traçabilité.
Cette distinction n'est pas académique : elle détermine trois comportements différents dans votre boutique. Un produit à DLC dépassée doit être bloqué à la vente. Un produit à DDM dépassée peut être vendu avec information. Un lot rappelé doit être retiré indépendamment de toute date.
## Le modèle de données
C'est le point qui bloque une implémentation naïve : la date n'appartient pas au produit, elle appartient au lot.
Un même produit peut avoir en stock trois lots avec trois dates différentes. La quantité affichée sur la fiche est la somme des lots, mais la date affichée doit être celle du lot qui partira, c'est-à-dire le plus proche de la péremption.
Le modèle minimal comporte donc trois niveaux : le produit, le lot avec son numéro et sa date, et la quantité par lot. Toute tentative de stocker une date unique sur la fiche produit échoue dès le deuxième réassort.
## Ce qu'il faut afficher au client
En vente à distance, le client ne peut pas retourner l'emballage pour lire la date. Trois éléments méritent d'apparaître.
**Une durée minimale garantie à réception.** « Date de durabilité minimale garantie : au moins 3 mois à réception » est plus utile qu'une date précise, qui changera au prochain lot et qui vous obligerait à modifier la fiche en permanence.
**La mention explicite en cas de vente après DDM.** Sur un lot proche ou dépassé vendu à prix réduit, l'information doit être visible avant l'achat, pas découverte à la réception. C'est la condition de licéité de cette vente.
**Le numéro de lot sur le bon de livraison**, ou à défaut dans le suivi de commande. Il permet au client de vous contacter précisément en cas de problème.
## La préparation de commande
La règle d'affectation est le FEFO, pour premier périmé premier sorti. Elle diffère du FIFO classique : ce n'est pas le lot reçu en premier qui part, c'est celui dont la date est la plus proche.
Les deux règles coïncident souvent, mais pas toujours. Un réassort en urgence chez un autre fournisseur peut arriver avec des dates plus courtes que le stock existant, et c'est lui qui doit partir en premier.
Concrètement, le bon de préparation doit indiquer, pour chaque ligne, le lot à prélever et son emplacement. Sans cette indication, le préparateur prend ce qui est devant, et vous découvrez trois mois plus tard un fond de palette périmé.
## La traçabilité et le rappel
C'est la fonction qui justifie à elle seule la gestion par lot.
En cas de rappel produit, vous devez pouvoir répondre à deux questions en quelques minutes. Quelles commandes contenaient ce lot ? Et quels clients contacter ?
Cela suppose que le numéro de lot soit enregistré sur la ligne de commande au moment de la préparation, pas seulement dans votre stock. Une gestion de lots qui s'arrête à l'entrepôt ne permet aucun rappel ciblé : vous devez alors contacter tous les acheteurs du produit, ce qui coûte beaucoup plus cher en image qu'un rappel précis.
Conservez également la trace des lots sortis pendant la durée légale applicable à votre secteur, qui dépasse souvent la durée de vie du produit.
## Les alertes
Trois seuils méritent une alerte automatique, à calibrer selon votre rotation.
Un premier signal à J-60, qui laisse le temps d'accélérer l'écoulement par une mise en avant ou une promotion. Un second à J-30, où le déstockage devient prioritaire. Et un blocage automatique à la date, qui retire le lot de la vente sans intervention.
Ce dernier point est le plus important : sur une DLC, le blocage doit être automatique et non dépendre d'une vérification humaine. Une expédition après DLC engage votre responsabilité même si l'erreur est involontaire.
## Le cas des lots et coffrets
Un assortiment contenant six produits différents porte six dates. La date à retenir est la plus courte, et c'est elle qui détermine la vente du coffret entier.
Cette règle a une conséquence de gestion : un coffret bien vendu peut être bloqué par un seul de ses composants. Prévoyez la substitution du composant concerné plutôt que le blocage de l'assortiment.
Le traite cette chaîne sur PrestaShop 8 et 9 : gestion par lot avec date et quantité, distinction DLC et DDM avec comportements différenciés, sortie FEFO sur le bon de préparation, enregistrement du lot sur la ligne de commande et alertes de péremption.
---
### Comment vérifier automatiquement un numéro de TVA VIES au checkout PrestaShop ?
_Source :_ — _publié_ 2026-09-02
> Un appel, une réponse valide ou invalide : en production, il faut compter trois états, pas deux. Formats de numéros par pays, latence variable selon l'État interrogé, comportement quand le service est indisponible et conservation de la preuve.
La vérification d'un numéro de TVA intracommunautaire auprès du service européen VIES est simple sur le papier : un appel, une réponse valide ou invalide. En production, elle se heurte à un service dont la disponibilité varie selon les États membres, à des formats de numéros hétérogènes, et à un client qui attend une réponse pendant que la page tourne.
Cet article traite l'implémentation. Les conditions fiscales de l'exonération relèvent d'un autre sujet, et la vérification n'en est qu'une des quatre.
## Où placer le champ
Deux emplacements possibles, avec des conséquences différentes.
**À l'inscription**, dans le formulaire de création de compte professionnel. La vérification se fait une fois, le résultat est stocké sur le client, et le checkout reste fluide. C'est l'approche recommandée dès que vous validez les comptes professionnels.
**Au checkout**, dans le formulaire d'adresse de facturation. Plus souple pour les clients qui commandent sans compte, mais la vérification intervient au pire moment : une lenteur ou une erreur à cette étape coûte une commande.
Dans les deux cas, le champ se rattache à l'adresse de facturation, jamais à l'adresse de livraison. Le numéro appartient à l'entité qui achète, pas au lieu où le colis arrive.
## Les formats, première source d'échec
Un numéro de TVA intracommunautaire commence par un code pays à deux lettres, suivi d'une chaîne dont la longueur et la composition varient d'un État à l'autre. La France utilise deux caractères de clé puis neuf chiffres, l'Allemagne neuf chiffres, l'Espagne une combinaison de lettres et de chiffres, l'Irlande admet plusieurs formats historiques.
Trois traitements à faire avant tout appel.
1. **Normaliser la saisie.** Retirer les espaces, points, tirets et passer en majuscules. Un client sur trois saisit son numéro avec des séparateurs.
2. **Séparer le code pays du reste.** Le service attend les deux séparément, et le client saisit souvent tout d'un bloc.
3. **Valider la forme avant d'appeler.** Un contrôle de format par pays évite d'interroger le service pour une saisie manifestement erronée, et permet un message immédiat.
Attention au cas de la Grèce, dont le code pays TVA diffère de son code pays ISO, et à celui de l'Irlande du Nord, qui dispose d'un préfixe distinct depuis le retrait du Royaume-Uni.
## L'appel au service
Le service européen interroge, pour chaque requête, la base nationale de l'État concerné. Deux conséquences directes.
**La latence varie fortement** selon le pays interrogé. Une vérification allemande répond en général rapidement, d'autres administrations sont nettement plus lentes.
**La disponibilité est indépendante d'un État à l'autre.** Le service peut fonctionner pour la Belgique et être indisponible pour l'Italie au même moment. Un test réussi ne garantit donc pas que toutes les vérifications aboutiront.
Fixez un délai maximal d'attente, cinq à dix secondes, au-delà duquel vous considérez le service comme indisponible. Un appel sans limite de temps bloque la page.
## Le comportement dégradé
C'est le point qui distingue une implémentation utilisable d'une implémentation fragile. Trois états à distinguer, et non deux.
**Numéro valide.** Vous enregistrez le résultat, l'horodatage, et vous appliquez vos règles fiscales.
**Numéro invalide.** Message clair au client, avec la possibilité de corriger. Ne bloquez pas la commande : le client peut acheter avec la TVA et régulariser ensuite.
**Service indisponible.** Le cas le plus mal traité. La commande doit passer, avec TVA appliquée, et la vérification doit être mise en file pour une nouvelle tentative. Traiter l'indisponibilité comme une invalidité fait perdre des commandes ; la traiter comme une validité vous expose fiscalement.
Une file de revérification qui repasse automatiquement les numéros non vérifiés quelques heures plus tard règle ce cas sans intervention.
## Les messages au client
Ils comptent autant que la mécanique. Trois formulations à préparer.
Sur un numéro invalide, expliquez ce qui peut expliquer le refus : numéro récent pas encore enregistré dans la base européenne, entreprise non assujettie, ou erreur de saisie. Un simple « numéro invalide » laisse le client sans issue.
Sur une indisponibilité, dites la vérité : la vérification n'a pas pu aboutir, la commande peut être passée avec TVA, et vous reviendrez vers lui. C'est plus rassurant qu'un message d'erreur technique.
Sur un succès, confirmez visuellement, avec le nom de l'entreprise retourné par le service quand il est disponible. Cette confirmation réduit les erreurs de saisie sur un numéro appartenant à une autre société.
## Conserver la preuve
Le service européen fournit un numéro de consultation pour chaque requête. Enregistrez-le, avec la date, l'heure, le numéro testé et la réponse complète.
C'est cette trace qui vous permet de démontrer, deux ans plus tard, que le numéro était valide au moment de la vente. Sans elle, vous ne pouvez pas justifier une exonération, même si la vérification a bien eu lieu.
Rattachez cette preuve à la commande, pas seulement au client : un client peut changer de numéro, et c'est l'état au moment de la transaction qui compte.
## Cache et revérification
Deux réglages complémentaires.
**Ne rappelez pas le service à chaque page.** Une vérification réussie peut être conservée quelques jours sans risque, ce qui évite d'interroger le service à chaque rechargement du panier.
**Revérifiez périodiquement** les clients récurrents. Un numéro retiré en cours d'année reste valide dans votre base si personne ne repasse. Une revérification mensuelle des comptes actifs suffit.
Le gère cette chaîne sur PrestaShop 8 et 9 : normalisation et contrôle de format par pays, appel au service avec délai maximal, comportement dégradé avec file de revérification, conservation du numéro de consultation et revérification périodique des comptes.
---
### Comment afficher des avis clients PrestaShop avec étoiles dans Google ?
_Source :_ — _publié_ 2026-09-02
> Les avis qu'une entreprise affiche sur elle-même ne donnent plus d'étoiles : seuls les avis produit restent éligibles. Les deux balisages à articuler, les cinq règles de Google, les erreurs qui font disparaître les extraits et pourquoi l'attente est normale.
Les étoiles affichées sous un résultat de recherche augmentent nettement le taux de clic, à position égale. Elles ne s'obtiennent pas en cochant une case : elles supposent un balisage correct, des avis réels, et le respect de règles que Google a resserrées ces dernières années.
## Ce que Google affiche, et pour quoi
Une précision qui évite des mois de travail inutile. Google a restreint les extraits enrichis d'avis sur certains types d'entités. Les avis qu'une entreprise affiche sur elle-même, rattachés à une entité de type organisation ou commerce local, ne donnent plus d'étoiles.
En revanche, les avis portant sur un **produit** restent éligibles. C'est la seule voie sur une boutique : baliser les avis au niveau de chaque fiche produit, pas au niveau du site.
Conséquence pratique : les avis marchands, ceux qui portent sur la qualité du service et de la livraison, ne produiront pas d'étoiles sur vos pages, quel que soit leur volume. Ils ont leur utilité, ce n'est pas celle-là.
## Les deux balisages, et leur articulation
Deux structures coexistent à l'intérieur du balisage produit, et elles ne servent pas la même chose.
**La note agrégée** porte la moyenne et le nombre d'avis. C'est elle qui produit les étoiles. Elle exige au minimum la valeur de la note, l'échelle utilisée, et le nombre d'avis ou de notes.
**L'avis unitaire** décrit un avis individuel avec son auteur, sa date et son contenu. Il n'est pas obligatoire pour obtenir les étoiles, mais il renforce la compréhension de la page et permet à Google d'afficher un extrait d'avis.
Une erreur fréquente consiste à déclarer une note agrégée sans aucun avis unitaire, sur une page qui n'affiche pourtant que trois avis. La cohérence entre ce qui est balisé et ce qui est visible est le point de contrôle principal.
## Les propriétés à ne pas oublier
Au-delà de la note, le produit lui-même doit être correctement identifié. Trois éléments comptent.
**Un identifiant produit** : code-barres, référence fabricant, ou référence interne. Sans identifiant, Google ne peut pas rattacher votre page au produit et les extraits enrichis sont moins fiables.
**Le nom exact du produit**, identique à celui affiché sur la page.
**L'offre**, avec le prix, la devise et la disponibilité. Un balisage d'avis sur un produit sans offre déclarée est incomplet.
Si vous alimentez également un flux produit vers Google, les identifiants doivent être strictement les mêmes des deux côtés. Une incohérence entre le flux et le balisage de la page produit des rapprochements erronés.
## Les cinq règles à respecter
1. **Les avis doivent être visibles sur la page.** Baliser une note que le visiteur ne peut pas lire est le motif d'action manuelle le plus courant sur ce sujet.
2. **Ils doivent être rédigés par des utilisateurs**, pas par vous. Un avis rédigé en interne, même sincère, ne relève pas de ce balisage.
3. **Pas d'agrégation d'avis d'autres sites** sans en avoir le droit et sans le déclarer.
4. **Pas de note sans avis correspondants.** Une note de 4,8 sur une fiche sans aucun avis affiché est une déclaration invérifiable.
5. **Le balisage porte sur l'élément principal de la page.** Sur une page catégorie, baliser les notes des vingt produits affichés n'est pas conforme : la page ne porte pas sur un produit unique.
## Les erreurs qui font perdre les étoiles
Quatre situations rencontrées régulièrement.
**Les avis chargés en JavaScript après le rendu initial.** Si le balisage arrive avec les avis dans un second temps, il peut ne pas être vu. Un balisage inséré côté serveur reste la solution la plus sûre.
**La note arrondie dans le balisage mais pas à l'affichage**, ou l'inverse. Les deux valeurs doivent correspondre.
**Le compteur d'avis qui inclut les avis en attente de modération.** Le nombre balisé doit correspondre aux avis effectivement publiés.
**Le balisage dupliqué.** Un thème qui déclare déjà un balisage produit, plus un module d'avis qui en ajoute un second, produit deux déclarations concurrentes sur la même page. C'est une cause fréquente d'extraits qui disparaissent après l'installation d'un module.
## Contrôler
Deux outils, dans cet ordre.
Le **test des résultats enrichis** de Google, sur une URL de fiche produit. Il vous dit si le balisage est détecté, valide, et éligible. Testez plusieurs fiches, dont une sans avis, pour vérifier que le balisage ne déclare pas une note vide.
Le **rapport des extraits enrichis** dans la Search Console, qui remonte les erreurs à l'échelle du site et permet de voir combien de pages sont réellement éligibles.
## Quand les étoiles n'apparaissent pas malgré un balisage valide
C'est la situation la plus frustrante, et elle est normale. Un balisage valide rend la page éligible, il ne garantit pas l'affichage.
Trois facteurs jouent. Le volume d'avis, un seul avis à cinq étoiles n'inspirant pas confiance à l'algorithme. La confiance accordée au domaine, qui met du temps à se construire. Et le type de requête, Google n'affichant pas les mêmes enrichissements selon l'intention détectée.
Comptez plusieurs semaines entre la mise en place et l'apparition, et ne modifiez pas le balisage entre-temps sous prétexte que rien ne bouge.
Le produit ce balisage sur PrestaShop 8 et 9 : note agrégée et avis unitaires déclarés côté serveur, cohérence avec les avis réellement publiés, identifiants produits complets et détection des balisages en doublon avec le thème.
---
### Louer du matériel avec PrestaShop : calendrier et gestion des disponibilités
_Source :_ — _publié_ 2026-09-01
> Un produit loué n'est pas indisponible, il est indisponible du 12 au 18. Le modèle de disponibilité par intervalle, les quatre durées à distinguer dont celle qu'on oublie toujours, et les règles d'ergonomie du calendrier client.
Vendre un produit, c'est gérer une quantité. Le louer, c'est gérer un calendrier. La différence paraît mineure, elle change entièrement le modèle de données : un produit loué n'est pas indisponible, il est indisponible _du 12 au 18_.
PrestaShop ne connaît pas cette notion. Voici ce que la location suppose réellement, et les pièges qui se révèlent en production.
## Le modèle de disponibilité
Le stock natif répond à une question unique : combien en reste-t-il. La location en pose une autre : combien en reste-t-il _sur cette période_.
Concrètement, chaque unité de matériel possède un calendrier propre, et une demande de réservation doit vérifier qu'au moins une unité est libre sur l'intégralité de l'intervalle demandé, bornes comprises.
Cette vérification est plus subtile qu'elle n'en a l'air. Une réservation du 12 au 15 et une du 16 au 18 sont compatibles. Une du 12 au 15 et une du 15 au 18 ne le sont pas, sauf si vous considérez que le retour du matin libère l'après-midi. Cette règle doit être décidée explicitement, pas subie.
## Les quatre durées à distinguer
C'est l'erreur de conception la plus fréquente : ne modéliser que la période louée.
1. **La période de location**, celle que le client choisit et qu'il paie.
2. **Le délai d'acheminement aller**, si vous expédiez. Le matériel part deux jours avant le début de la location et n'est donc pas disponible pour un autre client sur ces deux jours.
3. **Le délai de retour**, symétrique.
4. **Le temps de remise en état** : nettoyage, contrôle, recharge, remplacement de consommables. C'est le plus oublié, et celui qui produit les conflits les plus pénibles, parce qu'un matériel réservé le lendemain de son retour part sale ou incomplet.
La durée d'immobilisation réelle d'une unité peut ainsi atteindre le double de la durée facturée. Sur un parc restreint, cette différence détermine votre chiffre d'affaires maximal.
Ces marges doivent se paramétrer par catégorie de matériel : un vidéoprojecteur demande une heure de contrôle, une tente demande deux jours de séchage.
## Le calendrier côté client
Quatre règles d'ergonomie qui font la différence entre un calendrier utilisable et un formulaire abandonné.
**Les dates indisponibles sont désactivées, pas signalées après coup.** Un client qui choisit deux dates puis reçoit un message d'erreur recommence, ou part.
**La durée minimale est visible avant la sélection.** Si vous ne louez pas en dessous de trois jours, indiquez-le au-dessus du calendrier.
**Le prix se calcule pendant la sélection**, pas après validation. Sur un tarif dégressif, c'est ce qui pousse le client à allonger sa période.
**Les jours de fermeture apparaissent.** Si vous ne remettez ni ne récupérez le dimanche, le calendrier doit le montrer, sinon le client construit une réservation impossible.
## Le tarif
Trois structures coexistent et se combinent.
Le **tarif dégressif** par palier, jour, semaine, mois. C'est la structure la plus lisible et celle qui augmente la durée moyenne de location.
La **durée minimale facturée**, qui protège votre rentabilité sur les courtes locations : deux jours de manutention pour une demi-journée de location ne sont pas rentables.
Les **périodes particulières** : week-end, haute saison, jours fériés. Sur du matériel événementiel ou saisonnier, c'est là que se fait la marge.
Un point de méthode : affichez toujours le prix total de la période, pas seulement le prix journalier. Un client qui découvre le total au panier après avoir raisonné en prix par jour abandonne souvent.
## La caution
Deux approches, avec des conséquences très différentes.
La **préautorisation bancaire** bloque un montant sans le débiter, et le libère au retour. C'est la plus élégante, mais elle a des contraintes : durée de validité limitée selon les réseaux, montant plafonné, et disponibilité variable selon votre prestataire de paiement.
L'**encaissement avec remboursement** est plus simple techniquement et plus lourd pour le client, dont la trésorerie est mobilisée. Il impose aussi un remboursement rapide au retour, faute de quoi les réclamations arrivent.
Dans les deux cas, le montant et les conditions de retenue doivent figurer sur la page produit, pas seulement dans les conditions générales.
## Les documents
Trois pièces à prévoir dès le départ.
Le **contrat de location**, avec les dates, le matériel, la caution et les responsabilités. Il doit être généré automatiquement à la commande, pas rédigé à la main.
L'**état des lieux de départ**, idéalement avec des photos. C'est votre seule protection en cas de litige sur une dégradation.
L'**état des lieux de retour**, qui conditionne la libération de la caution.
Un conseil issu de la pratique : conservez ces documents rattachés à la commande, avec leur horodatage. Un litige sur une location intervient souvent plusieurs semaines après le retour.
## Le cas du retard
Le point qui casse le calendrier. Un client qui rend avec trois jours de retard rend indisponible un matériel déjà réservé par un autre.
Trois protections, à mettre en place dès l'ouverture. Un rappel automatique la veille de la date de retour. Une pénalité de retard annoncée à la réservation, qui doit être dissuasive sans être disproportionnée. Et une marge de sécurité dans le calendrier sur les matériels à forte demande, qui absorbe un retard sans annuler la réservation suivante.
Le couvre cette chaîne sur PrestaShop 8 et 9 : calendrier de disponibilité par unité, marges de préparation et de remise en état paramétrables, tarif dégressif par palier, gestion de la caution et documents de location rattachés à la commande.
---
### Quels blocs de réassurance ajouter sur une fiche produit PrestaShop ?
_Source :_ — _publié_ 2026-09-01
> Une rangée de six pictogrammes en pied de page que personne ne lit : le problème n'est pas le principe mais l'application. Les trois questions réelles du visiteur, ce qui rassure selon le panier moyen, et les formulations qui ne servent à rien.
Les blocs de réassurance sont partout, et la plupart ne servent à rien. Une rangée de six pictogrammes en pied de page, identiques sur toutes les boutiques, que personne ne lit. Le problème n'est pas le principe, c'est l'application : ces blocs répondent à des questions que le visiteur ne se pose pas, au moment où il ne se les pose plus.
## Les trois questions réelles
Un visiteur hésitant devant un bouton d'achat se pose trois questions, dans cet ordre.
**Vais-je le recevoir, et quand ?** C'est la première inquiétude, et elle porte sur le délai autant que sur la fiabilité.
**Et si ça ne va pas ?** Retour, échange, garantie. Cette question monte avec le prix et avec l'incertitude sur le produit.
**Mon paiement est-il sûr ?** Contrairement à ce qu'on croit, c'est la moins fréquente sur une boutique d'apparence professionnelle. Elle devient centrale sur un site inconnu ou mal fini.
Un bloc de réassurance qui ne répond à aucune de ces trois questions est un élément décoratif.
## Ce qui rassure change avec le panier moyen
C'est le point que les listes génériques ignorent.
**En dessous de 50 euros**, la préoccupation dominante est le coût et le délai de livraison. Les frais de port et la date de réception estimée valent tous les badges de sécurité du monde. Le risque financier est faible, le client ne s'inquiète pas de la garantie.
**Entre 50 et 300 euros**, le retour devient central. Le client se demande ce qui se passe si le produit ne convient pas, combien cela lui coûtera, et combien de temps il a pour décider. C'est la tranche où une politique de retour claire produit le plus d'effet.
**Au-dessus de 300 euros**, l'inquiétude se déplace vers l'après-vente et l'humain. Existe-t-il un service client joignable ? Que se passe-t-il si le produit tombe en panne dans huit mois ? Le paiement en plusieurs fois entre également dans le champ de la réassurance à ce niveau de prix.
Une boutique dont le panier moyen est de 35 euros n'a aucun intérêt à afficher un bloc « garantie 2 ans » en évidence, et une boutique à 800 euros de panier moyen perd son temps avec « livraison en 48 h ».
## La position
Sous le bouton d'achat, dans le champ visuel du prix. Pas en pied de page, où les blocs sont vus par une minorité de visiteurs, et jamais au moment de la décision.
Trois à quatre éléments, pas six. Chaque élément supplémentaire dilue l'attention portée aux autres, et une rangée dense finit par ressembler à un bandeau décoratif que l'œil saute.
Sur mobile, le bloc doit rester visible sans défilement supplémentaire après le bouton. Si le thème l'envoie plus bas, mieux vaut deux éléments bien placés que quatre hors champ.
## Les formulations qui ne marchent pas
**« Paiement 100 % sécurisé ».** Formule vide, présente sur tous les sites, y compris frauduleux. Elle n'apporte aucune information. Nommer les moyens de paiement acceptés, avec les logos réels, fait davantage.
**« Satisfait ou remboursé ».** Trop vague pour rassurer. « Retour gratuit sous 30 jours » donne les deux informations qui manquent : le coût et le délai.
**« Livraison rapide ».** Rapide ne veut rien dire. « Expédié aujourd'hui si commandé avant 15 h » est vérifiable et actionnable.
**« Service client à votre écoute ».** Remplacez par les horaires et le canal. « Par téléphone du lundi au vendredi, 9 h à 18 h » vaut mieux qu'une promesse d'écoute.
La règle commune : une réassurance efficace contient un chiffre ou une modalité précise. Si votre concurrent peut écrire exactement la même phrase, elle ne vous distingue pas.
## Ce qu'il ne faut pas mettre
Les logos de cartes bancaires en guise de preuve de sécurité. Ils indiquent les moyens acceptés, pas un niveau de protection, et leur accumulation fait bricolé.
Les certifications que vous n'avez pas obtenues. Un badge de confiance imité ou générique se repère, et il produit l'effet inverse de celui recherché.
Les mentions redondantes avec le reste de la page. Si le délai de livraison est déjà affiché sous le prix, ne le répétez pas dans le bloc.
## La cohérence avec la réalité
Une réassurance ne tient que si elle est vraie. Annoncer un retour gratuit sous 30 jours puis facturer les frais de renvoi produit un litige, un avis négatif, et une perte de confiance qui dépasse largement le gain de conversion initial.
Avant d'écrire un bloc, vérifiez que vos conditions générales disent la même chose, et que votre service client applique effectivement la règle. Les trois doivent concorder.
## Mesurer
Le taux de conversion global bougera peu et ne vous dira rien. Deux mesures plus utiles.
Le **taux de clic sur les blocs**, quand ils renvoient vers une page détaillée. Un bloc jamais cliqué n'est pas forcément inutile, mais un bloc beaucoup cliqué signale une question importante mal traitée ailleurs sur la fiche.
Le **volume de questions au service client** sur les sujets couverts. Si les demandes sur les délais de livraison baissent après l'ajout d'un bloc, il travaille, même si la conversion n'a pas visiblement bougé.
Le gère ces éléments sur PrestaShop 8 et 9 : blocs paramétrables par produit ou par catégorie, positionnement sous le bouton d'achat, affichage mobile adapté et personnalisation des textes sans modification du thème.
---
### Comment offrir un cadeau à partir d'un montant de panier sur PrestaShop ?
_Source :_ — _publié_ 2026-08-31
> Un seuil trop bas et vous offrez à des gens qui dépassaient déjà. Comment le calculer à partir de la distribution des paniers et non de la moyenne, quel cadeau choisir, et les cinq cas de gestion à trancher avant le lancement.
Le cadeau à partir d'un montant de panier est la mécanique de montée en panier la plus simple à comprendre pour le client et la plus facile à mal calibrer pour le marchand. Un seuil trop bas et vous offrez à des gens qui dépassaient déjà. Trop haut et personne ne le vise.
## Calculer le seuil, à partir de la distribution
Le réflexe consiste à prendre le panier moyen et à ajouter 20 %. C'est un mauvais calcul, parce que la moyenne est tirée vers le haut par quelques grosses commandes.
Regardez plutôt la distribution de vos paniers par tranche de dix euros sur les six derniers mois. Deux informations en sortent.
**Le mode**, c'est-à-dire la tranche la plus fréquente. C'est le montant que vos clients atteignent naturellement.
**La densité juste au-dessus.** Combien de commandes se situent entre le mode et le mode plus vingt euros ? C'est la population que vous pouvez faire basculer.
Le bon seuil se place légèrement au-dessus du mode, à une distance qu'un article supplémentaire permet de franchir. Si vos paniers se concentrent autour de 45 euros et que votre article moyen vaut 18 euros, un seuil à 60 euros est atteignable. Un seuil à 90 exigerait deux articles de plus et ne sera pas visé.
## Choisir le cadeau
Trois critères, dans cet ordre.
**Son coût réel doit rester inférieur à la marge additionnelle attendue.** Si le franchissement du seuil rapporte quinze euros de chiffre supplémentaire à 40 % de marge, votre cadeau ne doit pas coûter plus de trois à quatre euros en prix de revient.
**Il doit avoir un lien avec l'achat.** Un accessoire, un consommable, un échantillon de gamme. Un objet publicitaire sans rapport est perçu comme un déstockage et ne motive personne.
**Sa valeur perçue doit dépasser son coût.** C'est tout l'intérêt de la mécanique. Un échantillon d'un produit vendu 30 euros a une valeur perçue élevée pour un coût de revient faible.
Évitez le cadeau que vous n'arrivez pas à vendre. Les clients le repèrent, et cela dévalorise l'offre au lieu de la renforcer.
## La barre de progression, vrai moteur
C'est l'élément qui fait fonctionner le dispositif, davantage que le cadeau lui-même.
Une barre affichant « Plus que 12 euros pour recevoir votre cadeau » agit sur un mécanisme simple : le client a déjà investi dans son panier, et l'écart restant paraît petit par rapport à ce qu'il a déjà mis.
Quatre points d'implémentation.
- **Visible dès le premier ajout au panier**, pas seulement sur la page panier. Un bandeau ou un affichage dans le tiroir latéral.
- **Le montant restant, pas le pourcentage.** « Plus que 12 euros » est actionnable, « 80 % atteints » ne l'est pas.
- **Une suggestion de produits** dans la tranche de prix manquante. C'est ce qui transforme l'intention en ajout.
- **Un état franchi explicite.** Quand le seuil est atteint, le message change et le cadeau apparaît dans le panier, sinon le client doute.
## Les cas de gestion à trancher
Cinq situations qui se produiront toutes, et qu'il vaut mieux avoir décidées.
1. **Le client retire un article et repasse sous le seuil.** Le cadeau doit disparaître automatiquement, avec un message explicite. Le laisser produit une commande non conforme à vos règles.
2. **Le cadeau est épuisé.** Prévoyez un cadeau de remplacement, ou le retrait propre de l'offre. Un panier qui affiche un cadeau indisponible bloque la commande.
3. **Le cumul avec un code promo.** Le seuil se calcule-t-il avant ou après remise ? La règle prudente est après remise, sinon une remise de 20 % vous fait offrir un cadeau sur un panier qui n'atteint plus le seuil.
4. **Les frais de port.** Ils ne devraient pas entrer dans le calcul du seuil, sinon le montant à atteindre varie selon le mode de livraison choisi, ce qui est incompréhensible pour le client.
5. **Le retour partiel.** Si le client renvoie un article et repasse sous le seuil, réclamez-vous le cadeau ? En pratique, non, mais la règle doit figurer dans vos conditions.
## Sur la facture
Le cadeau doit apparaître comme une ligne à zéro euro, avec sa désignation. Deux raisons : la traçabilité de vos sorties de stock, et la clarté en cas de retour ou de litige.
Son coût de revient reste une charge pour vous, et l'article sort de votre stock comme n'importe quelle vente. Si vous gérez des quantités, prévoyez le décrément.
## Mesurer
Trois chiffres, relevés avant et après le lancement.
**Le panier moyen**, évidemment, mais surtout sa distribution : vous devez voir apparaître un pic juste au-dessus du seuil. Si ce pic n'apparaît pas, la mécanique n'a rien changé et vous offrez sans contrepartie.
**La part de commandes ayant déclenché le cadeau.** Trop élevée, votre seuil est trop bas. Trop faible, il est inatteignable. Une fourchette de 20 à 35 % est un bon repère.
**La marge par commande**, coût du cadeau déduit. C'est le seul chiffre qui dit si l'opération est rentable, et il est souvent oublié au profit du panier moyen, qui monte forcément.
Le gère cette mécanique sur PrestaShop 8 et 9 : seuil paramétrable, barre de progression avec montant restant, retrait automatique sous le seuil, gestion du stock du cadeau et règles de cumul avec les autres promotions.
---
### Directive Omnibus : afficher le prix le plus bas des 30 derniers jours sur PrestaShop
_Source :_ — _publié_ 2026-08-31
> Pas le prix catalogue, pas le prix conseillé : le plus bas effectivement appliqué sur trente jours. Ce que constitue une annonce de réduction, comment calculer la référence, les trois exceptions et pourquoi l'historisation doit commencer maintenant.
Depuis la transposition de la directive Omnibus, toute annonce de réduction de prix doit indiquer le prix antérieur le plus bas pratiqué au cours des trente derniers jours. Pas le prix catalogue, pas le prix conseillé, pas le prix d'avant la promotion : le plus bas effectivement appliqué sur cette période.
La règle paraît simple. Sa mise en œuvre suppose une donnée que la plupart des boutiques ne conservent pas.
## Ce que dit le texte
La directive européenne 2019/2161 a été transposée en droit français, avec des dispositions codifiées dans le code de la consommation et précisées par arrêté. Le principe est le suivant : lorsqu'un professionnel annonce une réduction de prix, il indique le prix antérieur, défini comme le prix le plus bas qu'il a pratiqué à l'égard de tous les consommateurs au cours des trente derniers jours précédant l'application de la réduction.
Deux précisions comptent. Le prix de référence est propre à votre boutique, il ne s'agit pas d'un prix de marché ni d'un prix conseillé. Et il se calcule à l'égard de tous les consommateurs, ce qui exclut les prix réservés à un groupe restreint.
## Ce qui constitue une annonce de réduction
Le champ d'application est plus large qu'on ne le pense, et c'est là que se trouvent la plupart des manquements.
**Sont concernés** : un prix barré à côté du prix courant, un pourcentage de remise affiché, un montant d'économie, une mention du type prix cassé, promotion, offre spéciale, dès lors qu'elle suggère une baisse par rapport à un prix antérieur.
**Ne sont pas concernés** : un prix bas permanent sans référence à un prix antérieur, une comparaison avec un prix conseillé par le fabricant à condition qu'il soit clairement identifié comme tel et non présenté comme votre prix habituel, et les offres de fidélité personnalisées non généralisées.
Le cas ambigu le plus fréquent est celui des badges. Afficher « bon plan » ou « offre » sur une fiche, sans prix barré, suggère malgré tout une réduction. La prudence commande de traiter ces mentions comme des annonces de réduction.
## Calculer le prix de référence
Quatre questions se posent en pratique, et elles n'ont pas toutes une réponse évidente.
**Sur quelle granularité ?** Par produit vendable, donc par déclinaison quand les déclinaisons ont des prix différents. Une taille XL vendue plus cher a son propre historique.
**Quels prix compter ?** Tous les prix appliqués à l'ensemble des consommateurs, y compris les précédentes promotions, les ventes flash et les prix issus de règles panier appliquées automatiquement. Un code promo saisi manuellement par le client relève d'un cas plus discutable, mais un code diffusé publiquement à tous entre bien dans le calcul.
**Et les prix par groupe ?** Un tarif réservé aux membres d'un programme de fidélité restreint n'abaisse pas le prix de référence général. Un tarif appliqué automatiquement à tous les visiteurs, oui.
**Sur quelle période exactement ?** Les trente jours qui précèdent l'application de la réduction, pas les trente jours glissants pendant l'opération.
## Les exceptions
Trois situations sortent du régime général.
**Les denrées périssables.** Les produits susceptibles de se détériorer ou de se périmer rapidement échappent à l'obligation, ce qui vise typiquement le frais et l'ultra-frais.
**Les produits mis en vente depuis moins de trente jours.** Vous ne pouvez pas afficher un historique qui n'existe pas. L'usage consiste à indiquer le prix de référence sur la période effectivement écoulée depuis la mise en vente, en le mentionnant.
**Les réductions progressives.** Lorsqu'une réduction augmente de façon continue et sans interruption, comme pendant les soldes, le prix de référence peut rester celui pratiqué avant la première baisse. C'est ce qui permet d'afficher une remise croissante pendant toute la période de soldes sans que la première démarque ne devienne la nouvelle référence.
Cette dernière exception est précieuse et souvent ignorée. Elle suppose que les baisses s'enchaînent sans retour au prix plein entre deux démarques.
## L'historisation, la vraie difficulté
PrestaShop ne conserve pas l'historique des prix. Quand vous modifiez un prix spécifique, l'ancien disparaît. Sans historique, vous ne pouvez ni calculer le prix de référence ni le justifier lors d'un contrôle.
Ce que l'historisation doit enregistrer : la date et l'heure du changement, le produit et la déclinaison concernés, le prix appliqué, et son origine, prix de base, prix spécifique ou règle panier.
Point important : commencez maintenant. Un historique construit aujourd'hui vous donne un prix de référence exploitable dans trente jours. Un historique que vous commencerez la veille des soldes ne vous servira à rien.
## L'affichage
La mention doit être lisible et proche du prix promotionnel. Une formulation courante : « Prix le plus bas pratiqué au cours des 30 derniers jours : 49,90 euros. »
Trois précautions. Le prix de référence affiché doit être celui calculé, pas le prix barré habituel : les deux diffèrent dès qu'une promotion a eu lieu récemment. La mention doit apparaître partout où la réduction est annoncée, y compris dans les listings de catégorie et les blocs de mise en avant, pas seulement sur la fiche. Et le pourcentage affiché doit être calculé à partir du prix de référence, sinon il est faux.
## Contrôles et sanctions
Le manquement relève des pratiques commerciales trompeuses. Les contrôles de la répression des fraudes sur ce point sont réguliers, et particulièrement soutenus pendant les périodes de soldes et le Black Friday.
Le contrôle est simple à mener : l'agent relève les prix affichés à plusieurs dates, et compare avec ce que la boutique annonce comme prix de référence. Une boutique sans historisation ne peut pas se défendre, même de bonne foi.
Le traite ce point sur PrestaShop 8 et 9 : historisation automatique des prix par produit et par déclinaison, calcul du prix le plus bas sur trente jours, affichage de la mention sur la fiche et dans les listings, et gestion des réductions progressives pendant les soldes.
---
### Comment créer un « Shop the Look » cliquable sur PrestaShop ?
_Source :_ — _publié_ 2026-08-30
> Une photo sur fond blanc montre un produit, une scène montre un résultat. La mécanique est simple, sa réussite tient à des détails d'exécution : composition de l'image, nombre de points chauds, comportement mobile et liste de repli.
Un client qui regarde une photo de canapé sur fond blanc voit un canapé. Le même canapé dans un salon, avec le tapis, la lampe et les coussins, lui montre un résultat. Le Shop the Look transforme cette mise en scène en parcours d'achat : chaque objet visible devient cliquable.
La mécanique est simple. Sa réussite tient à des détails d'exécution qui ne se voient qu'une fois en production.
## Où cela fonctionne
Trois familles s'y prêtent réellement.
**La mode et l'accessoire**, cas d'origine. La tenue complète répond à une question que la fiche produit ne traite pas : avec quoi porter cette pièce.
**La décoration et l'ameublement.** L'achat se fait par ambiance, presque jamais par produit isolé. C'est le secteur où le panier moyen bouge le plus.
**Le bricolage et le jardin en situation.** Une terrasse aménagée, un atelier équipé, un coin bureau. Le visiteur découvre des produits complémentaires qu'il n'aurait pas cherchés.
Le dispositif est en revanche inutile sur un catalogue technique où l'achat est unitaire et spécifié à l'avance : pièces détachées, consommables, produits professionnels sur référence.
## La photo, première contrainte
Le résultat dépend davantage de l'image que du module.
**Chaque produit doit être identifiable.** Un objet à moitié caché derrière un autre produira un point chaud incompréhensible. Composez la scène en pensant aux zones cliquables, pas seulement à l'esthétique.
**La résolution doit permettre le zoom**, en particulier sur mobile où le visiteur agrandit pour distinguer un détail avant de cliquer.
**Le cadrage doit laisser de l'espace.** Un produit collé au bord de l'image ne peut pas recevoir un point chaud sans que l'infobulle sorte du cadre.
Prévoyez également le format : une image très large fonctionne mal sur mobile, une image carrée gâche l'espace sur desktop. Deux versions de la même scène est la solution la plus propre.
## Placer les points chauds
Quatre règles issues de l'usage réel.
1. **Cinq à sept maximum par image.** Au-delà, la scène devient un semis de pastilles et le visiteur n'en ouvre aucune.
2. **Une taille tactile suffisante.** Le point doit rester atteignable au doigt, ce qui suppose une zone d'environ quarante pixels de côté sur mobile, quelle que soit la taille visuelle de la pastille.
3. **Un point par produit, sur la partie la plus reconnaissable.** Sur une chaise, l'assise plutôt qu'un pied.
4. **Une indication visuelle de cliquabilité.** Une pastille statique passe inaperçue. Une légère animation à l'arrivée sur l'image, puis un état de repos discret, résout ce point.
## Le contenu du point chaud
Ce qui s'ouvre au clic détermine la conversion. Quatre éléments, pas plus.
Le nom du produit, son prix, sa disponibilité, et une action. Cette action doit être l'ajout direct au panier quand le produit n'a pas de déclinaison, et un lien vers la fiche quand un choix de taille ou de couleur reste nécessaire.
Forcer un passage par la fiche pour un produit sans option ajoute une étape inutile. Proposer un ajout direct sur un produit qui exige une taille produit des commandes erronées et des retours.
## Le comportement mobile
C'est ici que la plupart des implémentations échouent. Sur mobile, l'infobulle qui s'ouvre à côté du point chaud recouvre l'image et sort souvent de l'écran.
Le comportement qui fonctionne : au clic sur un point chaud, une carte produit apparaît en bas de l'écran, sur toute la largeur, sans masquer la zone touchée. Le visiteur garde le contexte visuel et peut enchaîner sur un autre point sans refermer.
Prévoyez également un affichage de repli. Sous l'image, une liste classique des produits présents dans la scène, toujours visible. Elle sert aux visiteurs qui ne comprennent pas la mécanique, et elle règle deux autres problèmes.
## Accessibilité et référencement
Les deux se traitent par la même liste.
Une image avec des points chauds en superposition n'est pas exploitable par un lecteur d'écran, et les produits ne sont pas des liens indexables si le module les charge en JavaScript au clic. La liste HTML sous l'image, avec un lien vers chaque fiche, rend la scène accessible et fait exister le maillage.
Ajoutez un texte alternatif descriptif sur l'image, qui décrit la scène et non le nom du fichier.
## Où placer les looks
Trois emplacements, complémentaires.
Une **page dédiée** regroupant toutes les scènes, structurée par univers ou par saison. Elle se partage bien et se positionne sur des requêtes d'inspiration.
En **tête de catégorie**, une ou deux scènes de l'univers concerné. C'est l'emplacement qui convertit le mieux, parce que le visiteur y arrive déjà en phase de recherche.
Sur la **fiche produit**, un bloc « vu dans ces ambiances » qui renvoie vers les scènes contenant ce produit. Ce maillage inverse est celui qui fait monter le panier moyen.
## Mesurer
Trois indicateurs. Le taux d'interaction, part des visiteurs qui ouvrent au moins un point chaud, qui vous dit si la mécanique est comprise. Le taux d'ajout depuis les points chauds. Et le panier moyen des sessions ayant vu une scène, comparé aux autres : c'est là que le dispositif se justifie ou non, parce qu'il coûte du temps de production photo.
Le gère cette mécanique sur PrestaShop 8 et 9 : placement des points chauds sur l'image, carte produit avec ajout direct au panier, comportement mobile adapté, liste HTML des produits pour l'accessibilité et bloc inverse sur les fiches concernées.
---
### Comment transformer les recherches internes PrestaShop en landing pages SEO ?
_Source :_ — _publié_ 2026-08-30
> Le journal des recherches internes contient la façon dont vos clients formulent leur besoin, dans leurs mots. Quelles requêtes méritent une page indexable, les quatre critères de sélection, et pourquoi la génération massive transforme cette idée en pénalité.
Le journal des recherches internes contient quelque chose qu'aucun outil de mots-clés ne vous donnera : la façon dont vos clients formulent leur besoin, dans leurs mots, sur votre catalogue. Certaines de ces formulations reviennent des centaines de fois par mois et ne correspondent à aucune page de votre site.
Les transformer en pages indexables est une des rares opportunités SEO qui ne demande pas de recherche de mots-clés. Elle demande en revanche beaucoup de discipline, sous peine de produire des milliers de pages nuisibles.
## Les trois types de requêtes qui méritent une page
**La requête transversale.** « Cadeau moins de 50 euros », « idée cadeau fête des pères », « produits fabriqués en France ». Elle traverse plusieurs catégories et ne correspond à aucune d'entre elles. C'est le type le plus rentable, parce qu'aucune page existante ne peut le couvrir.
**La requête par attribut non catégorisé.** « Bureau blanc 120 cm », « chaussures de sécurité pointure 47 », « peinture extérieure gris anthracite ». Le filtre existe peut-être, mais la page filtrée n'est pas indexable ni optimisée.
**La requête par usage.** « Matériel pour randonnée bivouac », « équipement pour salon de coiffure », « outillage pour rénovation salle de bain ». Le client raisonne en projet, votre catalogue raisonne en famille de produits. La page comble cet écart.
## Les critères de sélection
C'est ici que se joue la réussite ou l'échec de la démarche. Quatre conditions cumulatives avant de créer une page.
1. **Un volume interne significatif.** Fixez un seuil, par exemple trente recherches sur trois mois. En dessous, la requête relève de l'anecdote.
2. **Un nombre de résultats suffisant.** Une page qui affiche trois produits n'a aucune valeur. Comptez huit à dix produits minimum, et vérifiez que ce nombre reste stable dans le temps.
3. **Aucune page existante équivalente.** Si une catégorie couvre déjà la requête, améliorez-la plutôt que de créer une page concurrente. Deux pages sur la même intention se cannibalisent.
4. **Une intention marchande.** Les recherches de suivi de commande, de contact ou de conditions de retour ne relèvent pas de ce dispositif.
## Le danger de la génération massive
C'est l'erreur qui transforme une bonne idée en pénalité. Générer automatiquement une page pour chaque requête produit rapidement plusieurs milliers de pages, dont la majorité affiche zéro ou deux produits, sans contenu propre, avec un titre construit mécaniquement.
Google traite ce type de production comme du contenu de faible qualité créé à l'échelle, et l'effet ne se limite pas aux pages concernées : il peut dégrader l'évaluation de l'ensemble du site.
La règle est simple. La génération peut être automatisée, la publication doit être décidée. Une file de propositions que vous validez une par une, avec un seuil minimal de produits, reste gérable : sur un catalogue moyen, vous aurez entre vingt et cinquante pages légitimes, pas deux mille.
## Ce que doit contenir la page
Une grille de produits ne suffit pas. Quatre éléments s'y ajoutent.
**Un titre et une adresse propres**, construits à partir de la requête mais rédigés, pas concaténés. « Bureau blanc 120 cm : notre sélection » plutôt que « Résultats de recherche : bureau blanc 120 cm ».
**Une introduction rédigée**, de 100 à 200 mots, unique à la page. Elle explique ce que la sélection regroupe et sur quels critères. C'est le seul contenu qui distingue la page d'une page de résultats.
**Des liens vers les catégories** dont sont issus les produits. Ils font le maillage et évitent que la page soit un cul-de-sac.
**Une aide au choix**, quelques lignes ou trois questions fréquentes. Sur une requête d'usage, c'est ce que le visiteur cherche vraiment.
## Le paramétrage d'indexation
Trois règles techniques.
La page porte une balise canonique vers elle-même, et pas vers la catégorie la plus proche. Sinon vous demandez à Google de l'ignorer, ce qui annule l'intérêt.
Elle figure dans le sitemap, idéalement dans un fichier distinct, pour suivre son indexation séparément du reste du catalogue.
Et elle bascule automatiquement en noindex si le nombre de produits passe sous le seuil. C'est le mécanisme de sécurité indispensable : une page créée avec quinze produits peut n'en compter que deux six mois plus tard, après des ruptures et des retraits de catalogue.
## L'entretien
Une page de sélection vieillit plus vite qu'une catégorie, parce qu'elle repose sur un filtre qui ne suit pas les évolutions du catalogue.
Prévoyez un contrôle trimestriel sur trois points : le nombre de produits affichés, le trafic reçu, et la pertinence de la sélection. Une page sans trafic après six mois doit être supprimée avec une redirection, pas laissée en place au cas où.
## Mesurer
Deux indicateurs suffisent, mesurés page par page. Le trafic de recherche organique reçu, à comparer au volume de recherche interne qui a motivé la création. Et le taux de conversion de la page, à comparer à celui de vos catégories : une page de sélection bien construite convertit souvent mieux, parce que l'intention y est plus précise.
Le traite ce dispositif sur PrestaShop 8 et 9 : détection des requêtes internes récurrentes, proposition avec seuil de volume et de résultats, création de pages éditorialisées avec introduction et métadonnées propres, et bascule automatique en noindex sous le seuil de produits.
---
### Comment synchroniser le stock entre deux boutiques PrestaShop distinctes ?
_Source :_ — _publié_ 2026-08-29
> Tant que le stock n'est pas partagé, chaque boutique croit disposer de la totalité. Trois architectures possibles, pourquoi la synchronisation bidirectionnelle naïve diverge, comment calculer la fenêtre de survente et ce qu'il ne faut surtout pas aligner.
Deux installations PrestaShop distinctes qui vendent les mêmes produits depuis le même stock physique : le cas est courant. Un site grand public et un site professionnel, une boutique française et une boutique allemande sous domaines séparés, ou une marque principale et un déstockage.
Tant que le stock n'est pas partagé, chaque boutique croit disposer de la totalité. La première survente arrive dans la semaine.
## Trois architectures possibles
**Le multiboutique natif.** Une seule installation, plusieurs boutiques logiques. Le stock est partagé nativement, la question ne se pose pas. C'est la solution la plus simple, et elle est souvent écartée à tort : beaucoup de projets partent sur deux installations séparées alors que le multiboutique aurait suffi.
**Deux installations synchronisées.** Chacune a sa base, son thème, ses modules, et un mécanisme maintient la cohérence du stock. Plus lourd, mais nécessaire dès que les deux sites doivent évoluer indépendamment ou appartenir à des entités juridiques différentes.
**Un système tiers maître.** Un ERP ou un logiciel de gestion détient le stock, et les deux boutiques le consomment. C'est l'architecture la plus saine dès qu'un troisième canal existe, magasin physique ou place de marché.
Avant de construire une synchronisation, vérifiez que la première option ne convient pas. Elle supprime le problème au lieu de le gérer.
## Un maître, un seul
C'est la décision fondatrice, et la synchronisation bidirectionnelle naïve est le piège classique.
Si les deux boutiques peuvent modifier le stock et se le renvoyer, vous obtenez des boucles : la boutique A décrémente, envoie à B, B applique et renvoie à A, qui décrémente à nouveau. Les stocks divergent en quelques heures, dans le mauvais sens.
Deux modèles corrects existent.
Le **modèle maître-esclave** : une boutique détient la vérité, l'autre reçoit. Simple, mais les ventes de l'esclave doivent remonter, ce qui suppose un canal distinct pour les décréments.
Le **modèle à stock centralisé** : ni l'une ni l'autre ne détient le stock, un référentiel externe le fait. Chaque vente déclenche un décrément sur ce référentiel, qui redistribue. C'est plus robuste, et cela suppose une brique supplémentaire.
## La fréquence, et la fenêtre de survente
Toute synchronisation périodique laisse une fenêtre pendant laquelle les deux boutiques ont une vision différente. Cette fenêtre se calcule.
Si vous synchronisez toutes les quinze minutes et que vous vendez trois unités par heure d'une référence, la fenêtre représente en moyenne moins d'une unité : le risque est faible. Sur une vente flash à cinquante unités l'heure, la même fenêtre laisse passer une douzaine de commandes en trop.
Trois réglages en découlent. Une fréquence élevée, cinq à quinze minutes, sur les références à rotation rapide. Une synchronisation événementielle plutôt que périodique sur les produits critiques : chaque vente déclenche immédiatement la propagation. Et une marge de sécurité, en réservant une ou deux unités par boutique, qui absorbe la fenêtre sans complexité supplémentaire.
## La correspondance des références
Point technique qui décide de la faisabilité. Les identifiants produits ne sont jamais les mêmes entre deux installations : le produit 421 sur la boutique A n'est pas le produit 421 sur la boutique B.
La correspondance doit donc s'appuyer sur une clé métier stable, présente des deux côtés et jamais modifiée. La référence produit convient, à condition qu'elle soit renseignée partout et unique. Le code-barres est une alternative solide.
Deux pièges. Les déclinaisons doivent avoir leur propre référence, sinon la synchronisation se fait au niveau du produit et le stock par taille reste faux. Et les produits présents d'un seul côté doivent être explicitement ignorés, pas traités comme des erreurs à chaque cycle.
## Ce qu'on ne synchronise pas
La tentation est de tout aligner. C'est une erreur, et elle rend le système fragile.
Ne synchronisez pas les prix si vos deux boutiques ont des positionnements différents, ce qui est presque toujours la raison de leur existence séparée. Ne synchronisez pas les descriptions traduites ni les métadonnées SEO, sous peine de créer du contenu dupliqué entre deux domaines. Ne synchronisez pas les commandes ni les clients, sauf besoin explicite : ce sont des données à forte charge réglementaire.
Le périmètre minimal qui fonctionne : le stock, la disponibilité, et éventuellement le statut actif ou inactif du produit.
## Les conflits, et la reprise après incident
Deux situations à prévoir dès la conception.
**Le conflit.** Les deux côtés ont changé entre deux synchronisations. La règle doit être écrite : soit le maître gagne toujours, soit la valeur la plus basse l'emporte, ce qui est prudent sur du stock. Une règle non écrite devient une règle aléatoire.
**La panne.** Que se passe-t-il si la synchronisation s'arrête pendant six heures sans que personne ne le remarque ? Trois protections : un journal consultable des synchronisations avec leur résultat, une alerte en cas d'échec répété, et une resynchronisation complète déclenchable manuellement.
Cette dernière est celle qu'on oublie systématiquement, et celle dont on a besoin en urgence un samedi matin.
## Contrôler
Un écart de stock ne se voit pas, il se constate au moment de la survente. Un contrôle hebdomadaire comparant les quantités des deux côtés, référence par référence, prend quelques minutes et révèle les dérives avant qu'elles ne coûtent une commande annulée.
Le traite cette chaîne sur PrestaShop 8 et 9 : correspondance par référence ou code-barres au niveau des déclinaisons, synchronisation du stock avec sens et fréquence paramétrables, journal des opérations et resynchronisation complète à la demande.
---
### Gift with purchase sur PrestaShop : la science du seuil pour booster l'AOV en 2026
_Source :_ — _publié_ 2026-08-29
> Le cadeau panier est plus rentable qu'une remise pourcentage : coût pour le marchand 5× à 10× inférieur en valeur perçue équivalente, effet psychologique du « gratuit » plus fort. Sur les boutiques PrestaShop bien calibrées : +12 à +22 % d'AOV, +6 à +14 % de marge par commande. La science du seuil, le choix du bon cadeau, et les pièges qui ruinent la marge.
## Le cadeau panier : un levier d'AOV plus puissant qu'une remise, et beaucoup moins coûteux
Proposer un cadeau quand le panier atteint un certain seuil est une mécanique vieille comme le commerce — la « prime » des magazines des années 1980, le bouquet offert chez le fleuriste, le sachet personnalisé Sephora. En e-commerce, c'est l'un des leviers d'AOV (panier moyen) les plus mal exploités, généralement remplacé par une remise pourcentage qui coûte mécaniquement plus à la marge.
L'arithmétique est implacable. Sur une commande à 80 € avec une marge brute de 35 % :
- **−10 % de remise** : 8 € de remise, soit 28,5 % de la marge brute (8 / 28). Coût pour le marchand : 8 € secs.
- **Cadeau valeur perçue 15 €, coût d'achat 3,50 €** : 3,50 € de coût pour le marchand, valeur perçue 5× supérieure. Coût pour le marchand : 3,50 €.
Et l'effet sur la conversion ? Les A/B tests publiés (Shopify Labs 2024, Klaviyo 2025) convergent : le cadeau panier convertit légèrement mieux qu'une remise équivalente en valeur perçue. L'effet psychologique du « gratuit » bat l'effet « pourcentage » dans la majorité des contextes.
## La science du seuil : à quel montant déclencher le cadeau ?
Le seuil idéal n'est pas un chiffre rond. Il se calcule en fonction de trois données mesurables sur votre boutique :
- **AOV actuel** — panier moyen sur les 90 derniers jours.
- **Distribution des paniers** — histogramme des montants payés (par tranche de 10 €).
- **Marge brute moyenne** par produit.
### La règle empirique : seuil = AOV × 1,3 à 1,5
Si l'AOV est 65 €, fixer le seuil entre 85 € et 95 €. Trop bas (seuil = AOV) : les clients qui auraient acheté à 65 € obtiennent le cadeau « gratuit » sans rien changer à leur comportement. Trop haut (seuil = AOV × 2) : très peu de clients y arrivent et la mécanique ne s'exprime pas.
Le sweet spot incite la marge des paniers initialement à 50-70 € à pousser jusqu'à 85-95 €. Soit +20 à +30 € de CA par commande concernée, sur un coût marginal cadeau de 3 à 5 €.
### L'ajustement par segment
Un seuil unique pour tout le catalogue n'est pas optimal sur les catalogues à AOV très dispersé (boutique généraliste). Trois patterns plus avancés :
- **Seuil par catégorie** — 90 € sur la mode, 150 € sur la beauté premium, 60 € sur les accessoires. Reflète la structure de panier différente par segment.
- **Seuil progressif** — cadeau A à 80 €, cadeau B (plus désirable) à 130 €, cadeau premium à 200 €. Crée plusieurs paliers d'incitation.
- **Seuil dégressif** sur les nouveaux clients — premier achat avec un seuil bas (50 €), seuils habituels après. Acquisition vs rétention.
## Choisir le bon cadeau : valeur perçue ≫ coût d'achat
Le cadeau idéal a quatre propriétés :
1. **Valeur perçue élevée** — quelque chose que le client aurait pu acheter, ressenti comme un vrai bonus.
2. **Coût d'achat faible** — généralement 5 à 15 % du seuil déclencheur.
3. **Petit volume / poids** — pour ne pas alourdir le shipping (et ne pas tuer la marge sur le port).
4. **Cohérent avec l'univers de marque** — un cadeau hors-univers est perçu comme du dumping de stock.
### Exemples par secteur
SecteurCadeau typeCoût d'achat indicatifValeur perçueBeauté / soinPochette, échantillon premium, mini-format2-5 €15-25 €ModeTrousse, foulard saison passée, marque-page3-8 €20-40 €Alimentaire finMignonnette, tablette dégustation, bocal mini2-4 €8-15 €DécorationCarte postale série, sac coton imprimé1-3 €8-12 €MaroquineriePorte-clés, miroir poche, sachet protecteur3-7 €15-30 €E-book / digitalPDF guide premium, accès vidéo bonus0 € marginal15-40 €
Le cas du digital est particulier : coût marginal nul, valeur perçue élevée si le contenu est exclusif. C'est souvent le combo le plus rentable.
## L'implémentation propre sur PrestaShop
L'erreur classique : créer une remise commerciale (« 15 € de remise si panier ≥ 90 € ») et ajouter un produit gratuit en post-traitement manuel. Trois problèmes :
- Le client ne voit pas le cadeau avant la confirmation — pas de levier d'incitation.
- La compta enregistre une remise, pas un cadeau (impact négatif sur le FEC).
- Le stock du cadeau n'est pas géré (rupture = client mécontent).
### Le pattern propre : un module dédié
Le [module DfFreeGift pour PrestaShop](https://www.datafirefly.com/product/dffreegift-cadeau-panier-prestashop/) implémente la mécanique correctement :
- Configuration du seuil (par boutique, par devise, par catégorie de panier).
- Sélection du produit cadeau (avec gestion stock, désactivation auto si rupture).
- Affichage du cadeau dans le panier en temps réel (« il vous manque 12 € pour obtenir [nom du cadeau] »).
- Ajout automatique du produit cadeau au panier à 0 € quand le seuil est atteint.
- Comptabilisation comme cadeau commercial (compte 6234 ou similaire selon le plan comptable), pas comme remise.
- Multilingue (FR/EN/ES/DE) sur les messages d'incitation.
### L'affichage qui maximise l'impact
Trois emplacements clés où afficher le seuil et le cadeau :
- **Sticky cart bar** sur le récap panier mobile : « 12 € pour obtenir [cadeau] ».
- **Page panier** : barre de progression visuelle (« 78 € / 90 € pour votre cadeau »).
- **Page checkout** : rappel du cadeau acquis (renforce la satisfaction d'achat) ou du seuil non atteint (dernière chance d'ajouter un produit).
Le combo avec le [sticky cart mobile](https://www.datafirefly.com/2026/08/27/conversion-mobile-prestashop-sticky-cart-autocompletion-adresse-indicatif-e164-2026/) est particulièrement puissant : la progression vers le seuil est visible en permanence pendant que le client navigue le catalogue.
## L'effet sur l'AOV mesuré
Sur les boutiques PrestaShop qui ont déployé un système de cadeau panier bien calibré :
- **AOV en moyenne** : +12 à +22 % sur les visiteurs qui voient le bandeau d'incitation.
- **Conversion globale** : neutre à légèrement positive (+1 à +3 points), le cadeau n'affecte pas la décision d'achat initiale mais influence le montant.
- **Marge nette** : +6 à +14 % par commande concernée, malgré le coût du cadeau (parce que les produits additionnels dans le panier compensent largement).
Sur une boutique faisant 1 000 commandes/mois à AOV 65 €, l'augmentation à 75 € moyens représente +10 000 €/mois de CA, sur un coût total cadeau d'environ 800-1 500 €/mois. ROI net : facteur 8 à 12.
## Les pièges à éviter
### 1. Cadeau perçu comme « cheap »
Un cadeau de mauvaise qualité ou hors-univers dégrade l'image de marque. Symptôme : taux de retour client en baisse, avis négatifs mentionnant le cadeau (« déçue par la pochette en plastique »). Mieux vaut un cadeau plus rare et qualitatif qu'un cadeau systématique mais ressenti comme du dumping de stock.
### 2. Stock cadeau insuffisant
La rupture sur le cadeau pendant qu'il est promis dans le panier crée une frustration disproportionnée. Le module doit désactiver automatiquement la mécanique si le stock cadeau passe sous un seuil de sécurité (typiquement 50 unités). Communiquer un cadeau de remplacement plutôt que cacher la rupture.
### 3. Cumul avec d'autres promotions
Si le client a déjà une remise active (code promo, vente flash), faut-il maintenir le cadeau ? Deux écoles : _autoriser_ (vision client) ou _exclure_ (vision marge). En pratique, autoriser sur les premières commandes (acquisition) et exclure sur les promotions agressives soldes/Black Friday. Le module doit gérer ces règles de cumul finement.
### 4. Cadeau qui devient une attente permanente
Si le cadeau est en place toute l'année, les clients l'intègrent dans leur référentiel et il perd son effet d'incitation. Le cadeau panier marche par variation : changement saisonnier, durée limitée, opérations spéciales. Le but est de créer de la nouveauté répétée, pas une norme.
### 5. Comptabilisation incorrecte
Un cadeau commercial gratuit n'est pas une remise sur ventes (compte 709). C'est une charge commerciale (compte 6234 — cadeaux à la clientèle, plafond fiscalement déductible 73 € TTC/an/bénéficiaire en 2026 pour la France). Une comptabilisation incorrecte fausse le FEC et le rapprochement marge. Voir [notre article sur le FEC](https://www.datafirefly.com/2026/05/25/fec-export-comptable-ecommerce-woocommerce-prestashop-conformite-fiscale-2026/).
## Combiner avec d'autres leviers AOV
Le cadeau panier n'est pas le seul levier d'AOV. Il s'insère dans un mix qui couvre toute la phase de pre-checkout :
- **Barre de livraison gratuite** — souvent combinée avec le cadeau (« livraison gratuite à 60 €, cadeau à 90 € »). Crée deux paliers d'incitation. Voir [notre article sur la barre de livraison gratuite](https://www.datafirefly.com/2026/05/29/barre-livraison-gratuite-calcul-seuil-optimal-marge-prestashop-2026/).
- **Bundles et packs produits** — vendre un trio à prix consolidé incite à monter en panier. Voir [notre guide bundles](https://www.datafirefly.com/2026/08/20/bundles-packs-produits-prestashop-conversion-aov-2026/).
- **Cross-sell intelligent** — proposer des accessoires complémentaires en fin de fiche, dans le panier, et en checkout.
- **Up-sell sur la page produit** — proposer la version premium ou la taille supérieure à un delta prix faible.
Le combo qui fonctionne le mieux en 2026 sur les boutiques mid-market : livraison gratuite (palier bas) + cadeau (palier haut) + cross-sell contextuel = +25 à +40 % d'AOV cumulé.
## FAQ
### Quelle fréquence de changement du cadeau ?
Optimum : 4 à 6 changements par an, alignés sur les saisons commerciales (printemps, été, rentrée, fêtes, Saint-Valentin, soldes). Plus fréquent : difficulté logistique. Moins fréquent : effet d'usure sur les clients réguliers.
### Le cadeau panier fonctionne-t-il en B2B ?
Avec des nuances. En B2B, le cadeau commercial est plafonné fiscalement (73 € TTC/an/bénéficiaire en France pour la déductibilité) et doit être tracé. Un cadeau au-delà de 73 € sur un panier B2B est tout de même autorisé, mais non déductible — affecte la marge nette. Pour les boutiques [B2B PrestaShop](https://www.datafirefly.com/2026/05/25/b2b-prestashop-comptes-pros-devis-paiement-differe-kyb-2026/), le cadeau panier marche bien sur les comptes pros TPE/PME, moins sur les grands comptes.
### Le cadeau s'applique-t-il en cas de retour partiel ?
Si le client retourne une partie du panier qui fait passer le total sous le seuil, deux options : facturer le cadeau (selon CGV qui doivent le prévoir) ou le laisser. La pratique commerciale habituelle : laisser le cadeau si le retour est < 30 % du panier, débiter sinon. À documenter dans les CGV pour éviter les litiges.
### Que faire si le client est livré avant que le cadeau soit en stock ?
Trois options : (1) livraison séparée du cadeau plus tard (coût port supplémentaire, frustration), (2) substitution par un cadeau équivalent (à automatiser), (3) bon d'achat de remplacement (mauvaise UX). La meilleure pratique : le module doit refuser d'attacher le cadeau si le stock effectif (et pas seulement déclaré) ne suffit pas.
### Combien de temps faut-il pour déployer un système de cadeau panier ?
Avec un module clé en main comme [DfFreeGift](https://www.datafirefly.com/product/dffreegift-cadeau-panier-prestashop/), l'installation prend 30 minutes. Le travail réel est la sélection du cadeau (validation marketing/branding), le calibrage du seuil (analyse AOV historique), et la création des visuels d'incitation (barre de progression, bandeau panier). Comptez 1 à 2 semaines en parallèle des autres opérations.
## En synthèse
Le cadeau panier reste l'un des leviers d'AOV les plus rentables — coût pour le marchand 5 à 10× inférieur à une remise pourcentage équivalente en valeur perçue, effet psychologique du « gratuit » plus puissant. La rigueur est dans le calibrage : seuil = AOV × 1,3 à 1,5, cadeau avec valeur perçue 3 à 5× le coût d'achat, gestion stock et comptabilisation propres.
Le [module DfFreeGift pour PrestaShop](https://www.datafirefly.com/product/dffreegift-cadeau-panier-prestashop/) implémente la mécanique avec affichage de la barre de progression, gestion automatique du stock cadeau, comptabilisation correcte (cadeau commercial vs remise), multilingue et multishop. Il s'intègre naturellement avec [la barre de livraison gratuite](https://www.datafirefly.com/2026/05/29/barre-livraison-gratuite-calcul-seuil-optimal-marge-prestashop-2026/) pour créer plusieurs paliers d'incitation et avec [les bundles produits](https://www.datafirefly.com/2026/08/20/bundles-packs-produits-prestashop-conversion-aov-2026/) pour amplifier l'AOV.
Le ROI typique sur une boutique mid-market : +12 à +22 % d'AOV, +6 à +14 % de marge par commande concernée, payback du module sous 30 jours. Pour optimiser la mécanique sur la durée, [notre audit conversion PrestaShop](https://www.datafirefly.com/expertise/audit-prestashop/) mesure le delta réel par cohorte et ajuste seuils et cadeaux selon les segments client.
---
### Nutri-Score sur une boutique alimentaire PrestaShop
_Source :_ — _publié_ 2026-08-29
> Les valeurs nutritionnelles sont obligatoires, le Nutri-Score est volontaire, mais dès que vous l'affichez ses règles d'usage s'imposent. La plus contraignante : l'exhaustivité sur toute la gamme, pas seulement sur les produits bien notés.
Vendre de l'alimentaire en ligne impose deux obligations distinctes qu'on confond souvent. Les valeurs nutritionnelles relèvent du règlement européen INCO et sont obligatoires. Le Nutri-Score relève d'un dispositif volontaire, mais dès que vous l'affichez, ses règles d'usage deviennent contraignantes.
## Ce qui est obligatoire, et ce qui ne l'est pas
Le règlement INCO impose, pour la vente à distance de denrées préemballées, que les mentions obligatoires soient disponibles **avant la conclusion de l'achat**. Cela couvre la dénomination, la liste des ingrédients, les allergènes mis en évidence, la quantité nette, la déclaration nutritionnelle et les conditions de conservation.
Le point souvent raté : ces informations doivent figurer sur la fiche produit, pas seulement dans une photo de l'emballage. Une image de l'étiquette n'est pas exploitable par un lecteur d'écran, et n'est pas considérée comme une mise à disposition suffisante.
Le Nutri-Score, lui, n'est pas obligatoire. Son usage suppose un engagement auprès de Santé publique France, qui ouvre le droit d'utiliser le logo selon un règlement d'usage précis.
## Les règles d'usage du logo
Elles sont strictes et leur non-respect fait perdre le bénéfice de l'engagement.
- **Le logo officiel uniquement.** Pas de version redessinée, recolorée ou simplifiée. Les fichiers sont fournis avec le règlement d'usage.
- **Une taille minimale** garantissant la lisibilité, et des proportions non modifiables.
- **L'exhaustivité.** Si vous vous engagez, vous devez afficher le Nutri-Score sur l'ensemble des produits concernés de votre gamme, pas seulement sur ceux bien notés. C'est la règle la plus importante, et celle qui fait hésiter certaines boutiques.
- **Un délai de mise en conformité** après l'engagement, au-delà duquel l'affichage doit être complet.
Afficher un A sur trois produits et rien sur les vingt autres n'est pas une application partielle : c'est un usage non conforme du logo, et une pratique trompeuse au regard du consommateur.
## Le calcul, et sa révision
Le score se calcule à partir de la composition pour 100 grammes ou 100 millilitres. Des points défavorables sont attribués pour l'énergie, les acides gras saturés, les sucres et le sel. Des points favorables viennent des fibres, des protéines et de la part de fruits, légumes et légumineuses. La différence donne une note traduite en lettre de A à E.
L'algorithme a été révisé, avec une application progressive, et cette révision modifie le classement de certaines familles : les boissons sucrées, les produits salés et sucrés, ou encore les huiles et les produits laitiers ne sont plus notés selon les mêmes seuils.
Conséquence pratique : ne recopiez pas une note trouvée sur une base de données ancienne. La note affichée doit être celle communiquée par le fabricant selon la version en vigueur, et elle doit être mise à jour quand il la révise.
## Où l'afficher dans PrestaShop
Trois emplacements, par ordre de priorité.
Sur la **fiche produit**, à proximité des informations produit et non enfoui dans un onglet secondaire. La déclaration nutritionnelle complète peut se trouver dans un onglet, le logo doit rester visible.
Dans le **listing de catégorie**, en option. Ce n'est pas exigé, et c'est un avantage commercial réel sur une gamme bien notée. Sur une gamme majoritairement notée D et E, l'affichage en listing est cohérent mais commercialement discutable, à vous de trancher.
Dans les **résultats de recherche interne** et les blocs de recommandation, pour rester cohérent. Un score visible en catégorie mais absent du bloc « produits similaires » donne une impression d'affichage sélectif.
## Le cas des lots et coffrets
Question fréquente et sans réponse simple. Un coffret contenant six produits différents n'a pas de Nutri-Score propre : le score porte sur une denrée, pas sur un assortiment.
La pratique la plus défendable consiste à afficher le score de chaque composant dans le détail du coffret, sans en calculer un pour l'ensemble. Un score moyen serait inventé, et donc trompeur.
Même logique pour les produits vendus au poids ou préparés sur commande : si la composition varie, aucun score fixe ne peut être affiché.
## Stocker la donnée correctement
Comme pour l'indice de réparabilité, le score et les valeurs nutritionnelles doivent être des champs structurés, pas du texte dans la description.
Trois raisons concrètes. Vous devez pouvoir lister les produits alimentaires dont les valeurs sont manquantes, ce qui est un contrôle de conformité. Vous devez pouvoir exporter ces données vers vos flux, les places de marché alimentaires les exigeant de plus en plus. Et un balisage en données structurées, qui améliore la compréhension de vos fiches par les moteurs, suppose des champs identifiés.
Le traite ce besoin sur PrestaShop 8 et 9 : logo officiel aux proportions réglementaires, tableau des valeurs nutritionnelles conforme, champs structurés par produit, affichage sur la fiche et en option dans les listings, et balisage en données structurées.
---
### Comment optimiser les pages marques PrestaShop pour le SEO ?
_Source :_ — _publié_ 2026-08-28
> Les pages marques existent, sont accessibles, et ne reçoivent aucun trafic. Quatre causes structurelles, le contenu minimum qui change la donne, le maillage depuis les fiches et le traitement des marques à deux produits.
Sur beaucoup de boutiques, les pages marques existent, sont accessibles depuis un menu, et ne reçoivent aucun trafic de recherche. Elles constituent pourtant l'un des rares gisements de requêtes à forte intention encore accessibles : quelqu'un qui tape le nom d'une marque suivi d'un mot générique sait déjà ce qu'il veut.
La raison de cet échec est structurelle, et elle se corrige.
## Pourquoi la page marque native ne se positionne pas
Quatre causes se cumulent, chacune suffisante à elle seule.
**Aucun contenu.** La page native affiche un logo, une description souvent vide, et une grille de produits. Face à des pages concurrentes qui présentent la marque, son histoire et sa gamme, elle n'a rien à opposer.
**Un titre générique.** Le titre de page se réduit fréquemment au nom de la marque, sans complément. Or personne ne tape uniquement un nom de marque pour acheter : les requêtes réelles sont du type nom plus catégorie, ou nom plus qualificatif.
**Aucun maillage entrant.** Les fiches produits mentionnent la marque sans lier vers sa page. La page existe mais rien ne pointe vers elle, ce qui la place en périphérie du site.
**Une profondeur excessive.** Sur beaucoup de thèmes, la liste des marques est reléguée en pied de page, à trois ou quatre clics de l'accueil.
## Le contenu minimum d'une page qui se positionne
Comptez 400 à 700 mots, structurés. En dessous, la page reste une grille de produits avec un paragraphe d'introduction, ce qui ne suffit pas.
Quatre blocs constituent une base solide.
1. **Le positionnement de la marque.** Ce qu'elle fabrique, depuis quand, ce qui la distingue. Trois à quatre phrases factuelles, pas un communiqué de presse recopié.
2. **Les gammes.** Une présentation des familles de produits, avec un lien vers la catégorie correspondante filtrée sur la marque. Ce bloc fait le maillage descendant.
3. **Un guide de choix.** Le bloc qui apporte le plus. Quel modèle pour quel usage, comment se repèrent les références, ce que signifient les suffixes. C'est ce que cherche réellement le visiteur qui tape un nom de marque.
4. **Une FAQ courte.** Garantie, disponibilité des pièces, compatibilités, service après-vente. Trois à cinq questions suffisent.
Point important : ce contenu doit être unique. Recopier la présentation fournie par le fabricant place votre page en concurrence avec des dizaines de revendeurs qui ont fait la même chose, et avec le site officiel de la marque.
## Le titre et l'URL
Le titre doit contenir la marque et un qualificatif qui correspond à la requête réelle. « Marque X » seul est trop court ; « Marque X : toute la gamme outillage, prix et disponibilité » cible ce que les gens tapent.
Pour l'URL, une structure courte et stable, en évitant les paramètres. Une page marque atteignable uniquement via un filtre appliqué à une catégorie n'est pas une page marque, c'est une vue filtrée, et elle ne se positionnera pas.
## Le maillage, dans les deux sens
C'est le levier le plus rentable et le plus simple à mettre en place.
**Depuis les fiches produits.** Chaque fiche mentionnant une marque doit lier vers sa page. Sur un catalogue de trois mille produits répartis sur quarante marques, cela représente une moyenne de soixante-quinze liens entrants par page marque, obtenus sans effort éditorial.
**Depuis un annuaire de marques.** Une page listant toutes les marques par ordre alphabétique, accessible depuis le menu principal, réduit la profondeur à deux clics. Elle capte au passage les recherches internes portant sur des noms de marques.
**Depuis les catégories.** Un bloc « marques présentes dans cette catégorie » crée un maillage transversal utile au visiteur comme au robot.
## Le cas des marques à faible catalogue
Une page marque avec deux produits est un problème : peu de contenu, peu de valeur pour le visiteur, et un risque de page jugée de faible qualité.
Trois traitements possibles selon le cas. Si la marque a un potentiel de recherche réel, développez le contenu même avec peu de produits : le guide de choix et la FAQ n'exigent pas un catalogue étoffé. Si la marque n'a aucune notoriété, excluez la page de l'indexation plutôt que de la laisser flotter. Et si vous avez trente marques à un ou deux produits, regroupez-les dans une page thématique commune plutôt que de créer trente pages faibles.
## Le risque de cannibalisation
Point à surveiller quand une marque correspond presque à une catégorie. Si vous avez une catégorie « Perceuses » et une page « Marque X » dont le catalogue est composé à 90 % de perceuses, les deux pages visent des requêtes proches et se concurrencent.
La règle de départage : la catégorie cible la requête générique, la page marque cible la requête avec le nom. Leurs titres, leurs premiers paragraphes et leurs guides de choix doivent refléter cette différence. Si vous constatez que Google alterne entre les deux pages sur une même requête, l'une des deux doit être réorientée.
## Mesurer
Suivez trois choses dans la Search Console, filtrées sur les URL de pages marques. Le nombre de requêtes distinctes générant des impressions, qui indique si la page est comprise comme une page de marque ou comme une simple liste. La position moyenne sur les requêtes contenant le nom de la marque. Et le taux de clic, qui révèle si votre titre correspond à ce que les gens cherchent.
Le traite cette structure sur PrestaShop 8 et 9 : pages marques enrichies avec contenu structuré et métadonnées propres, annuaire A à Z avec recherche instantanée, et maillage automatique depuis les fiches produits vers la page de leur marque.
---
### People Also Ask + FAQ IA en 2026 : capter le triple territoire SERP (Featured Snippets, PAA, AI Overviews) sur PrestaShop et WooCommerce
_Source :_ — _publié_ 2026-08-28
> Le SERP 2026 n'est plus une liste de dix liens — c'est trois territoires : Featured Snippets, People Also Ask, AI Overviews. Ensemble, ils captent 60 à 75 % du trafic search. Chacun appelle un format de contenu spécifique, mais ils se rejoignent autour d'un socle commun : du Q/R structuré, du Schema FAQPage propre, et un llms.txt à jour. La méthode pour les conquérir simultanément.
## Le SERP de 2026 n'est plus une liste de dix liens bleus — c'est trois territoires distincts à conquérir
Quand un internaute tape une question sur Google en 2026, il ne reçoit plus une SERP. Il reçoit un patchwork : une **AI Overview** en haut (présente sur 47 % des requêtes informationnelles selon les mesures Semrush mai 2026), un bloc **People Also Ask** qui s'étend dynamiquement (jusqu'à 8-12 questions empilées sur les requêtes longues), un **Featured Snippet** classique (toujours là, toujours stratégique), puis seulement la liste organique. Sur Bing, c'est Copilot qui occupe la moitié de l'écran. Sur ChatGPT et Perplexity, il n'y a même plus de SERP — il y a une réponse synthétisée avec quelques citations cliquables.
Pour une boutique e-commerce, l'enjeu est double. Premièrement, ces trois territoires (Featured Snippets, PAA, AI Overviews) concentrent 60 à 75 % du trafic search en 2026. Deuxièmement, ils ne se gagnent pas tous avec le même contenu : un Featured Snippet aime une définition courte, une PAA aime une réponse de 40-60 mots, une AI Overview aime du contenu structuré avec entités nommées et données factuelles. Le contenu qui truste les trois est un contenu écrit pour les trois — et ça ne se fait pas tout seul.
Cet article détaille la mécanique de chaque territoire, le format de contenu qui gagne sur chacun, et comment automatiser cette production par IA sur PrestaShop et WooCommerce.
## Territoire 1 — Featured Snippets : le snippet position 0
Le Featured Snippet existe depuis 2014. Il occupe le haut de la SERP avec une réponse extraite d'une page web. Trois formats principaux :
- **Paragraphe** : 40-58 mots qui répondent à une question (« qu'est-ce que »).
- **Liste** : ordonnée ou non, 4 à 8 items (« étapes pour », « comment faire »).
- **Tableau** : comparaison structurée (« différence entre A et B », « prix moyen »).
### Ce qui fait gagner un Featured Snippet en 2026
- **Question explicitement posée comme titre H2 ou H3**, suivie immédiatement de la réponse en moins de 60 mots.
- **Réponse au-dessus du fold** de la page (Google scanne la première moitié plus en détail).
- **Données structurées** Schema.org FAQPage ou HowTo qui aident à l'extraction.
- **Autorité topique** du site — Google ne donne pas de Featured Snippet à un site qui n'est pas déjà bien classé sur le terme.
### Pour une fiche produit e-commerce
Le Featured Snippet sur une requête commerciale (« meilleur matelas latex », « différence entre PrestaShop et WooCommerce ») est très convoité. La stratégie qui fonctionne :
- Identifier les requêtes longue traîne où la concurrence est faible.
- Écrire un article ou enrichir une fiche produit avec un H2 = la question exacte de la requête, suivi d'une réponse courte et précise.
- Ajouter le balisage `FAQPage` Schema.org sur la question/réponse.
L'effet : un Featured Snippet bien capturé multiplie par 4 à 8 le CTR de la position 1 classique, et il survit même partiellement au-dessus d'une AI Overview (Google laisse coexister Featured Snippets et AI Overviews depuis 2024).
## Territoire 2 — People Also Ask : le bloc qui s'étend
Le bloc PAA présente 3 à 5 questions « apparentées » sous la SERP. Chaque clic sur une question affiche la réponse extraite d'une page, et ajoute 2 à 3 nouvelles questions au bloc — qui peut s'étendre à 12-20 questions sur une session utilisateur engagée.
### L'opportunité PAA est massive et sous-exploitée
Trois caractéristiques rendent le PAA stratégique :
- **Le PAA est plus accessible que le Featured Snippet** : il accueille plusieurs pages différentes (3 à 5+), pas une seule. La concurrence est mécaniquement moins violente.
- **Une question apparaît dans 50 à 200 requêtes parentes différentes**. Capturer une question PAA donne un trafic sur l'ensemble de l'arborescence de questions associées.
- **La citation PAA donne une visibilité de marque** même quand l'utilisateur ne clique pas — l'extrait avec la source en référence renforce la notoriété.
### Le format de contenu qui capture les PAA
Une question PAA aime une réponse de **40 à 60 mots**, placée juste après la question. Pas un paragraphe contextualisant longuement avant. Le crawler Google extrait la réponse linéairement après le H3 qui correspond à la question.
Structure type qui gagne :
```
Combien coûte un module PrestaShop ?
Un module PrestaShop coûte entre 30 € et 500 € en licence
perpétuelle, selon la complexité. Les modules SEO et marketing
sont généralement à 50-150 €, les modules ERP/B2B à 200-500 €.
Les modules gratuits existent mais ont un support limité.
```
53 mots. Question directe en H3. Réponse autonome (lisible hors contexte). Données chiffrées concrètes. C'est le profil qui maximise la probabilité de capture PAA.
### Générer les bonnes questions par IA
L'identification manuelle des questions PAA passe par AlsoAsked.com ou Semrush — outils excellents mais qui demandent du tri humain. L'alternative en 2026 : générer les questions par IA depuis le contenu produit, puis valider qu'elles correspondent à des PAA réels.
Le [module DfAiPAA pour PrestaShop](https://www.datafirefly.com/product/dfaipaa-prestashop-people-also-ask-ia/) implémente ce workflow : pour chaque fiche produit ou catégorie, il génère par GPT-4o-mini une liste de 8 à 15 questions probables, les croise avec une API SERP (DataForSEO ou similaire) pour vérifier qu'elles apparaissent en PAA Google, et propose le contenu de réponse. Coût IA : 0,03 à 0,08 € par fiche enrichie. Le module gère aussi le balisage Schema.org FAQPage automatique sur chaque Q/R injectée.
## Territoire 3 — AI Overviews et les agents IA
Les AI Overviews de Google (lancés en mai 2024 sous le nom Search Generative Experience puis renommés en 2024) génèrent une réponse synthétique en haut de SERP sur les requêtes complexes ou informationnelles. Cette réponse cite typiquement 3 à 8 sources. Être cité dans une AI Overview est l'équivalent moderne du Featured Snippet — sauf qu'au lieu de récupérer le clic, on récupère une visibilité de marque ET (dans 35 à 45 % des cas) un clic vers la source.
En parallèle, ChatGPT Search, Perplexity, Claude (via mode shopping), et Bing Copilot construisent leurs propres réponses avec leurs propres règles d'attribution.
### Ce que les agents IA cherchent dans une page
Trois signaux dominent en 2026 :
1. **Entités nommées explicites** — Schema.org Product, Organization, FAQPage, HowTo avec leurs propriétés complètes.
2. **Données factuelles chiffrées** — prix, dimensions, dates, statistiques, comparatifs.
3. **Structure sémantique propre** — H1 unique, H2 par section, H3 pour les questions, paragraphes auto-portants.
Le fichier [`llms.txt`](https://www.datafirefly.com/product/llms-txt-prestashop-seo-ia-chatgpt/) est devenu un standard de fait pour indexer un site auprès des LLM. Il fournit à un agent IA une carte du contenu indexable, équivalent du `robots.txt` mais pour les modèles de langage. Sur PrestaShop, le générer automatiquement à partir du catalogue est un gain de visibilité IA immédiat.
### Le rôle décisif des FAQ produit
Une FAQ produit bien structurée — 5 à 10 questions/réponses sur chaque fiche — est le contenu qui sert simultanément les trois territoires :
- Pour les Featured Snippets : chaque Q/R est candidate à un snippet sur sa question.
- Pour les PAA : les questions matchent souvent des PAA Google.
- Pour les AI Overviews : la structure FAQPage Schema.org est extrêmement lisible par les LLM.
L'observation empirique : sur les boutiques avec une FAQ IA bien remplie (10+ questions par fiche), la part de trafic IA-attribué (depuis ChatGPT, Perplexity, Claude) atteint 4 à 7 % en 2026 — vs 0,2 à 0,8 % sur les boutiques sans FAQ. C'est un canal qui n'existait pas en 2023 et qui pèse aujourd'hui autant que Bing organique.
## Automatiser la production : trois modules complémentaires
### 1. Génération de FAQ produit par IA
Sur PrestaShop, le [module DataFirefly FAQ IA Produit](https://www.datafirefly.com/product/datafirefly-faq-ia-produit-prestashop-8/) génère pour chaque fiche 5 à 10 questions/réponses contextualisées (à partir du titre, description, attributs, marque). Multi-langue (FR, EN, ES, DE), balisage Schema.org FAQPage automatique, génération par batch. Coût IA : 0,02 à 0,05 € par fiche.
Sur WooCommerce, l'équivalent est [DataFirefly FAQ IA Produit WooCommerce](https://www.datafirefly.com/product/datafirefly-faq-ia-produit-woocommerce/), avec les mêmes fonctionnalités adaptées au modèle de données WC (custom fields, taxonomies, variations).
### 2. Génération de PAA contextualisées
Le [module DfAiPAA pour PrestaShop](https://www.datafirefly.com/product/dfaipaa-prestashop-people-also-ask-ia/) va plus loin : il génère des questions _spécifiquement_ alignées sur les PAA Google détectés par crawl SERP. Différence avec la FAQ classique : la FAQ vise les questions _probables_, le PAA vise les questions _vérifiées dans la SERP_. Les deux sont complémentaires.
### 3. Fichier llms.txt
Le [module llms.txt pour PrestaShop](https://www.datafirefly.com/product/llms-txt-prestashop-seo-ia-chatgpt/) génère et maintient à jour le fichier `/llms.txt` à la racine du site, avec la liste des catégories, fiches produits, articles de blog, et leurs URL canoniques. C'est devenu un signal lu par ChatGPT, Perplexity, Claude, et progressivement par les crawlers Google. Coût zéro en API (le fichier est statique).
Le [pendant WooCommerce](https://www.datafirefly.com/product/llms-txt-aeo-woocommerce-schema-ia/) implémente la même logique avec la structure WP/WC.
## Le pipeline complet 2026
Pour une boutique qui veut occuper les trois territoires, le pipeline recommandé en 2026 :
1. **Audit initial** — Identifier les 50 à 100 requêtes prioritaires (top catégories + top fiches + requêtes longue traîne identifiées en Search Console). Pour chacune : présence Featured Snippet/PAA/AI Overview ? Concurrents qui les occupent ?
2. **Génération FAQ produit** — Module IA déployé sur tout le catalogue. 5 à 10 Q/R par fiche, balisage Schema.
3. **Génération PAA enrichie** — Pour les top 20 % de fiches qui font 80 % du trafic, enrichir avec des PAA spécifiques crawlés depuis Google.
4. **Articles éditoriaux ciblés** — Pour les requêtes top-funnel (« comment choisir », « différence entre ») : articles de blog dédiés avec structure Q/R, balisage FAQPage, et maillage interne vers les fiches.
5. **Fichier llms.txt déployé** — Mise à jour quotidienne, listé dans `robots.txt` via `Sitemap:`.
6. **Mesure** — Search Console pour PAA/Featured Snippets, paramètre UTM ou referrer pour le trafic IA (ChatGPT envoie son referrer depuis 2024).
Le ROI typique sur une boutique mid-market PrestaShop ou WooCommerce : +18 à +35 % de trafic search organique en 6 à 9 mois, dont 4 à 8 points spécifiquement attribuables au trafic IA.
## Lien avec le maillage interne et le AEO global
La production de FAQ et PAA n'a de sens que si le contenu est correctement maillé. Une FAQ orpheline reçoit peu d'autorité ; une FAQ liée depuis 8 à 15 entités du catalogue se positionne en quelques semaines. C'est l'articulation avec [le maillage interne sémantique IA](https://www.datafirefly.com/2026/08/22/maillage-interne-semantique-ia-prestashop-graphe-pertinence-2026/) qui transforme la production de contenu en performance SEO réelle.
De même, le travail PAA/FAQ s'inscrit dans une [démarche AEO globale 2026](https://www.datafirefly.com/2026/05/21/aeo-2026-optimiser-prestashop-8-chatgpt-perplexity-google-ai-overviews/) qui couvre aussi les [données structurées Schema.org Product 2026](https://www.datafirefly.com/2026/07/20/schema-org-product-2026-hasmerchantreturnpolicy-shippingdetails-prestashop-woocommerce/) et la fluidité de consommation par [les agents shopping IA](https://www.datafirefly.com/2026/08/09/ai-shopping-agents-operator-claude-perplexity-prestashop-2026/).
## Les pièges qui tuent le ROI
### 1. Génération de masse sans contrôle qualité
Générer 10 000 Q/R par IA en une nuit, c'est techniquement possible. C'est aussi le meilleur moyen d'inonder son site de contenu médiocre que Google identifie comme « bulk AI-generated » et qui déclenche une pénalité Helpful Content Update. La règle : valider échantillonnage 10-15 % des Q/R générées, ajuster le prompt système si nécessaire, et purger les Q/R qui n'ajoutent pas d'information.
### 2. Schema FAQPage incohérent
Le balisage `FAQPage` Schema.org doit décrire les Q/R **réellement visibles** sur la page. Si le balisage liste 10 questions mais le contenu visible n'en affiche que 5, Google considère cela comme du _structured data spam_ et désindexe le balisage. Toujours synchroniser le visible et le balisé.
### 3. Cannibalisation entre fiches et articles
Si la même question apparaît avec la même réponse sur 200 fiches du catalogue, Google ne sait laquelle classer. La déduplication est cruciale : une question générique va dans un article de blog ; les questions spécifiques (produit, taille, couleur) restent sur la fiche.
### 4. PAA inventées
Générer par IA des questions « plausibles » qui ne correspondent à aucune PAA Google réelle est du contenu mort. Toujours croiser avec une API SERP (DataForSEO, Serper, ValueSerp) pour valider que la question a une recherche derrière elle.
## FAQ
### Combien de questions par fiche produit est l'optimum ?
Le sweet spot en 2026 est 7 à 12 questions par fiche. Moins de 5 : sous-exploite le territoire. Plus de 15 : Google considère que la page est « FAQ-loaded » et dévalue. Les fiches très techniques (électronique, informatique) peuvent monter à 15-20 si la qualité est là.
### Faut-il les afficher tout déroulé ou en accordéon ?
L'accordéon est OK pour l'UX mais le contenu doit rester dans le HTML (pas chargé en JavaScript). Google et les LLM lisent le HTML rendu, pas l'état UI. Si le contenu n'est révélé qu'au clic via fetch JavaScript, il n'est pas indexé. La règle : contenu en HTML statique, JS pour le toggle visuel uniquement.
### L'IA générée pour les FAQ pose-t-elle un problème Google ?
Pas en soi. Google précise depuis 2023 que la qualité prime sur l'origine. Une FAQ générée par IA, factuelle, utile, sans hallucinations, contextualisée à la fiche → OK. Une FAQ générée en masse, générique, qui se répète d'une fiche à l'autre → Helpful Content Update.
### Le trafic IA (ChatGPT, Perplexity) est-il mesurable ?
Oui depuis 2024. ChatGPT envoie le referrer `chatgpt.com`, Perplexity `perplexity.ai`, Claude `claude.ai`. Dans GA4, créer un segment Custom basé sur ces referrers donne une lecture précise. Les boutiques en pointe mesurent aujourd'hui 3 à 8 % de leur trafic search depuis ces sources.
### Comment optimiser pour Bing Copilot spécifiquement ?
Bing Copilot consomme largement les mêmes signaux que Google (Schema, structure, autorité). Une optimisation Google bien faite couvre 80 % de Bing. Le 20 % spécifique : soumettre le sitemap dans Bing Webmaster Tools, vérifier l'indexation, et privilégier les contenus avec citations explicites (Bing valorise les pages qui citent leurs sources de manière nette).
## En synthèse
Le SERP 2026 se découpe en trois territoires distincts — Featured Snippets, People Also Ask, AI Overviews et agents IA — qui appellent des formats de contenu spécifiques mais qui se rejoignent autour d'un même socle : du Q/R structuré, du Schema.org FAQPage propre, et un fichier `llms.txt` à jour. La production manuelle de ce contenu ne passe pas l'échelle ; la génération IA bien encadrée la passe en grande partie.
Sur PrestaShop, la pile recommandée combine trois modules complémentaires : [FAQ IA Produit](https://www.datafirefly.com/product/datafirefly-faq-ia-produit-prestashop-8/) pour la couverture catalogue, [DfAiPAA](https://www.datafirefly.com/product/dfaipaa-prestashop-people-also-ask-ia/) pour le ciblage PAA Google réel, et [le module llms.txt](https://www.datafirefly.com/product/llms-txt-prestashop-seo-ia-chatgpt/) pour l'indexation par les LLM. Sur WooCommerce, le [module FAQ IA](https://www.datafirefly.com/product/datafirefly-faq-ia-produit-woocommerce/) couvre le même périmètre adapté à l'écosystème WordPress.
Le ROI typique en 2026 sur une boutique mid-market : +18 à +35 % de trafic search organique en 6 à 9 mois, dont 4 à 8 points spécifiquement attribuables au trafic depuis les agents IA. Le payback du setup IA (modules + coût d'inférence) tourne autour de 60 à 90 jours. [Notre audit AEO](https://www.datafirefly.com/expertise/audit-prestashop/) identifie le ciblage prioritaire et calibre la production pour éviter les pièges de la génération de masse.
---
### Autoliquidation TVA sur PrestaShop : appliquer 0 % aux clients B2B européens éligibles
_Source :_ — _publié_ 2026-08-28
> Quatre conditions cumulatives, et si une seule manque, la TVA française reste due à votre charge. Le piège de la livraison en France, la valeur de preuve de la vérification VIES, les deux éléments exigés pour justifier le transport et la mention obligatoire.
Un client professionnel allemand commande sur votre boutique française. S'il est assujetti à la TVA dans son pays et que la marchandise part vers l'Allemagne, la vente s'effectue hors taxes : c'est lui qui déclarera la TVA chez lui. Ce mécanisme, l'autoliquidation, est standard en B2B intracommunautaire.
Il repose sur des conditions cumulatives. Si une seule manque, la TVA française reste due, et c'est vous qui la payez, majorée des pénalités, plusieurs années après.
## Les quatre conditions cumulatives
1. **L'acheteur est assujetti à la TVA** dans un autre État membre, et il agit en tant que tel. Un particulier allemand ne relève pas de ce régime, même s'il achète beaucoup.
2. **Son numéro de TVA intracommunautaire est valide** au moment de l'opération, vérifié auprès de la base européenne VIES.
3. **Le bien quitte physiquement la France** vers un autre État membre.
4. **Vous détenez la preuve de ce transport.**
Les deux dernières sont celles qui se perdent en pratique, et ce sont celles que l'administration vérifie.
## Le piège de la livraison en France
Point mal compris et fréquent : c'est la destination de la marchandise qui compte, pas la nationalité du client.
Une entreprise belge disposant d'un numéro de TVA valide qui commande sur votre site avec une livraison à Lille reste soumise à la TVA française. Le bien ne quitte pas le territoire, donc l'exonération ne s'applique pas.
Techniquement, la conséquence est claire : le calcul ne doit jamais se fonder sur le pays de facturation seul. Une boutique qui exonère dès qu'un numéro de TVA étranger est saisi commet une erreur systématique sur toutes les livraisons en France.
## La vérification du numéro
Depuis les mesures européennes entrées en application en 2020, la validité du numéro de l'acquéreur n'est plus une formalité mais une condition de fond de l'exonération.
La vérification passe par la base VIES, qui interroge les administrations nationales. Trois précautions.
**Conservez la preuve.** Enregistrez la date de vérification, le numéro testé et le résultat retourné. Sans cette trace, vous ne pouvez pas démontrer que le numéro était valide au moment de la vente, même s'il l'était.
**Prévoyez l'indisponibilité.** Le service VIES tombe régulièrement, ou renvoie une réponse partielle selon les États. Votre parcours doit prévoir ce cas : ne pas bloquer la commande, mais ne pas exonérer non plus. La commande passe avec TVA, quitte à régulariser.
**Revérifiez.** Un numéro valide en janvier peut avoir été retiré en juin. Sur un client récurrent, une revérification périodique évite de découvrir le problème lors d'un contrôle.
## La preuve du transport
C'est la condition la plus souvent négligée, et celle qui coûte le plus cher en cas de redressement.
Les règles européennes prévoient une présomption de transport lorsque vous détenez au moins deux éléments de preuve non contradictoires, émis par deux parties indépendantes l'une de l'autre et de vous-même.
Ces éléments se répartissent en deux groupes. Le premier comprend les documents de transport proprement dits : lettre de voiture signée, connaissement, facture du transporteur. Le second regroupe des preuves complémentaires : police d'assurance du transport, document bancaire prouvant le paiement du transport, accusé de réception par l'acquéreur, attestation d'un entrepositaire dans l'État d'arrivée.
En pratique, sur des envois par transporteur classique, la facture du transporteur et la preuve de livraison signée constituent le couple le plus simple à réunir. Elles doivent être conservées et rattachées à la commande, pas dispersées dans une boîte email.
## La mention obligatoire sur la facture
Une facture exonérée doit porter une mention explicite renvoyant au fondement de l'exonération. Une formulation courante en France : « Exonération de TVA, article 262 ter I du CGI, autoliquidation par le preneur ».
Doivent également figurer votre numéro de TVA intracommunautaire et celui de l'acquéreur. Une facture sans le numéro du client ne permet pas de justifier l'exonération.
Vérifiez le modèle de facture PrestaShop avant d'ouvrir ce régime : le modèle natif ne prévoit ni la mention d'exonération ni l'affichage du numéro de TVA client.
## Le paramétrage dans PrestaShop
Trois éléments s'articulent.
Un **groupe de clients** distinct pour les professionnels européens validés, qui détermine l'affichage hors taxes. Une **règle de taxe** paramétrée pour appliquer un taux nul aux zones concernées, et non une suppression de la ligne de TVA, qui empêcherait ensuite tout suivi comptable. Et une **condition sur l'adresse de livraison**, distincte de l'adresse de facturation, pour traiter correctement le cas de la livraison en France.
Le point de vigilance porte sur l'ordre d'évaluation : la décision d'exonérer doit intervenir après la saisie de l'adresse de livraison, jamais avant.
## Les obligations déclaratives
Une vente exonérée n'est pas une vente invisible. Deux déclarations en découlent.
L'**état récapitulatif TVA**, qui liste par client et par montant les livraisons intracommunautaires du mois. Il est obligatoire dès la première opération.
L'**enquête statistique sur les échanges de biens**, qui a remplacé la partie statistique de la déclaration d'échanges de biens, et qui ne concerne que les entreprises dépassant certains seuils ou expressément sollicitées.
Ces déclarations supposent d'extraire les données par client, par pays et par période. Prévoyez cet export dès la mise en place, plutôt que de le reconstituer à la main chaque mois.
Le couvre cette chaîne sur PrestaShop 8 et 9 : vérification du numéro auprès de VIES avec conservation de la preuve, exonération conditionnée à l'adresse de livraison, mention réglementaire sur la facture et export des opérations intracommunautaires.
---
### Collecter des avis produits sans tomber dans le faux avis
_Source :_ — _publié_ 2026-08-27
> Un faux avis ne se limite pas à un avis inventé : le filtrage des négatifs et la mention « avis vérifiés » sans vérification en relèvent aussi. Les quatre formes retenues par les contrôles, les trois informations obligatoires et ce qu'apporte la norme NF Z74-501.
Collecter des avis est un problème d'organisation. Collecter des avis dont l'authenticité tient devant un contrôle est un problème juridique. Les deux se traitent séparément, et le second est celui qui expose réellement une boutique.
La répression des fraudes a mené plusieurs campagnes de contrôle sur les avis en ligne, avec des taux d'anomalie élevés. Les manquements relevés ne sont pas exotiques : ce sont des pratiques que beaucoup de marchands considèrent comme normales.
## Ce qu'est un faux avis au sens de la loi
La définition est plus large que « un avis inventé ». Le code de la consommation vise les pratiques commerciales trompeuses, et la jurisprudence comme les contrôles retiennent quatre formes distinctes.
1. **L'avis fabriqué.** Rédigé par le marchand, par un proche, ou acheté à un prestataire. La forme la plus évidente et la plus lourdement sanctionnée.
2. **Le filtrage des avis négatifs.** Publier les avis favorables et écarter les autres. C'est un faux avis par omission : la note affichée ne reflète pas les retours réels.
3. **La contrepartie non déclarée.** Offrir un bon d'achat contre un avis n'est pas interdit, mais ne pas l'annoncer publiquement l'est.
4. **L'affirmation non vérifiée.** Écrire « avis vérifiés » ou « avis de clients ayant acheté » sans mécanisme de vérification. L'allégation elle-même devient trompeuse.
Les sanctions relèvent des pratiques commerciales trompeuses : amende administrative, et dans les cas graves une peine pouvant atteindre deux ans d'emprisonnement et 300 000 euros d'amende, montant pouvant être porté à un pourcentage du chiffre d'affaires.
Le règlement européen sur les services numériques a par ailleurs renforcé les obligations de transparence sur la modération des contenus, ce qui inclut les avis.
## Les trois informations obligatoires
Le point le plus souvent manquant, et le plus simple à corriger. Toute boutique publiant des avis doit indiquer trois choses, accessibles depuis les pages qui les affichent.
- **Si les avis font l'objet d'un contrôle**, et si oui, lequel. Une boutique qui ne vérifie rien doit l'écrire, ce qui est parfaitement licite.
- **La date de publication** de chaque avis, et celle de l'expérience si elle diffère.
- **Les critères de classement** des avis. Si vous affichez les mieux notés en premier, dites-le.
Une page dédiée de quinze lignes règle ces trois obligations. Son absence est le manquement le plus fréquemment relevé, et le plus facile à constater.
## La norme NF Z74-501, et ce qu'elle apporte
Cette norme française, dont une version internationale existe sous la référence ISO 20488, encadre le traitement des avis de consommateurs. Elle est volontaire : ne pas la suivre n'est pas une infraction.
Elle impose une méthode sur trois volets. La collecte doit être traçable, avec une identification de l'auteur et une preuve de l'expérience de consommation. La modération doit reposer sur des critères objectifs, écrits et appliqués uniformément, avec conservation de la trace des rejets. Et la restitution doit publier tous les avis retenus, sans sélection sur la note, dans un ordre annoncé.
Son intérêt réel n'est pas le label mais la discipline qu'elle impose. Une boutique qui applique ces trois principes est en conformité avec la loi presque automatiquement, parce que les obligations légales en sont un sous-ensemble.
## Une modération défendable
Vous avez le droit de rejeter des avis. Vous devez pouvoir expliquer pourquoi.
Écrivez vos critères avant de commencer, et tenez-vous-y. Une liste utilisable tient en cinq points : propos injurieux ou discriminatoires, contenu hors sujet ou portant sur un autre produit, données personnelles de tiers, contenu manifestement faux ou vérifiablement erroné, soupçon de concurrence déloyale.
Ce qui ne figure pas sur cette liste ne justifie pas un rejet. En particulier, ni la note basse, ni la critique du délai de livraison, ni le mécontentement mal formulé.
Conservez pour chaque rejet la date, le motif et l'identité du modérateur. Sans cette trace, votre modération est indéfendable, quelle qu'ait été son honnêteté.
## Le lien avec la commande, meilleure preuve
Techniquement, le dispositif le plus solide consiste à ne permettre le dépôt d'un avis qu'à partir d'un lien nominatif à usage unique, envoyé après livraison, et rattaché à la ligne de commande concernée.
Trois conséquences. La mention « avis vérifié » devient exacte et démontrable. Les avis portent sur des produits réellement reçus, ce qui améliore leur contenu. Et le volume baisse par rapport à un formulaire ouvert, ce qui est le prix de la crédibilité.
Conservez le lien entre l'avis et la commande, sans l'afficher publiquement. C'est ce lien qui répond à un contrôle, pas la mention affichée.
## Le cas des avis sollicités contre avantage
Si vous offrez un bon d'achat, des points de fidélité ou une participation à un tirage, trois règles s'appliquent.
L'avantage doit être annoncé publiquement, sur la page qui présente les avis. Il ne peut être conditionné à une note minimale ni à un contenu favorable. Et il doit être accordé quel que soit le contenu de l'avis déposé, y compris s'il est très négatif.
Une formulation acceptable : « Chaque avis publié donne droit à 2 euros de remise sur votre prochaine commande, quelle que soit la note attribuée. »
## Ce que Google attend en plus
Pour l'affichage des étoiles dans les résultats de recherche, deux règles s'ajoutent aux obligations légales. Les avis doivent porter sur le produit spécifique et non sur la boutique. Et ils doivent être visibles sur la page qui porte le balisage : baliser une note agrégée qu'aucun visiteur ne peut lire expose à une action manuelle.
Le fournit ce cadre sur PrestaShop 8 et 9 : dépôt par lien nominatif rattaché à la commande, file de modération avec motif et traçabilité des rejets, publication sans filtrage sur la note et balisage des données structurées.
---
### Conversion mobile 2026 sur PrestaShop : sticky cart, autocomplétion d'adresse et indicatif E.164 — la trilogie qui débloque le checkout mobile
_Source :_ — _publié_ 2026-08-27
> Le mobile fait 70 % du trafic et seulement 45 % des ventes : l'écart est entièrement dans le checkout. Trois frictions précises tuent la conversion mobile — l'ajout au panier qui force un scroll vers le haut, la saisie d'adresse à 45 secondes, le numéro de téléphone international mal formaté. Les trois leviers qui débloquent le checkout mobile en 2026.
## Le mobile fait 70 % du trafic et 45 % des ventes — l'écart est entièrement dans le checkout
Sur les boutiques PrestaShop mid-market que nous instrumentons en 2026, le mobile représente en moyenne 71 % du trafic et 44 % du chiffre d'affaires. L'écart de 27 points est presque entièrement explicable par le taux de conversion mobile inférieur de moitié au desktop (1,2 % vs 2,6 % en moyenne). Et ce différentiel ne s'explique pas par l'intention d'achat — on observe des taux d'ajout au panier équivalents — mais par la friction du checkout.
Trois frictions précises tuent la conversion mobile :
1. **L'ajout au panier qui force un scroll vers le haut** sur les pages produits longues — l'utilisateur a fini de lire les caractéristiques en bas de page, mais le bouton d'ajout est tout en haut, hors du viewport.
2. **La saisie d'adresse au checkout** — taper « 47 rue de la République 75011 Paris » sur un clavier mobile prend 45 secondes et génère 2 à 3 erreurs en moyenne.
3. **La saisie du numéro de téléphone international** — pour les marchands multi-pays, demander « tapez +33 6 12 34 56 78 » à un client espagnol qui hésite entre « 0034 » et « +34 » fait basculer 8 à 12 % des paniers dans l'abandon.
Ces trois frictions sont indépendantes mais cumulatives. Les corriger en même temps double l'effet : ce n'est plus une optimisation à 2 ou 3 points, c'est typiquement un gain de 6 à 11 points de conversion mobile. Cet article détaille la mécanique de chaque levier et les pièges d'implémentation.
## Levier 1 — Le bouton d'ajout au panier sticky mobile
### Pourquoi le sticky cart fonctionne
Une fiche produit mobile bien faite mesure 2 500 à 4 000 pixels de hauteur (titre, prix, image principale, sélecteur de déclinaison, description, FAQ, avis, produits similaires). Le bouton d'ajout au panier est dans la partie haute, autour de 600-800 px. Quand l'utilisateur scrolle pour lire les détails, le bouton disparaît du viewport. Pour acheter, il doit scroller en arrière — un geste qui interrompt la lecture et signale physiquement « tu n'es pas censé être là ».
Le sticky cart résout ce problème en affichant en permanence un bouton d'ajout au panier (ou de paiement express) dans la zone basse de l'écran mobile, à portée du pouce. C'est la barre que vous voyez sur Amazon, ASOS, Sephora, et toute boutique mobile-first sérieuse.
### Anatomie d'un sticky cart bien conçu
Un sticky cart efficace contient :
- Une miniature du produit (40×40 px) — rappelle ce qu'on est en train d'acheter.
- Le prix unitaire (et le prix barré si en promotion).
- Le sélecteur de quantité (avec contrôles + / − accessibles au pouce).
- Un bouton d'ajout au panier au moins 48 px de hauteur (cible tactile recommandée Android/iOS).
- Optionnel mais puissant : un bouton paiement express (Apple Pay / Google Pay) directement dans la barre, qui bypass le panier intermédiaire.
Le bouton paiement express dans le sticky est le levier qui fait basculer la conversion : il transforme un parcours en 4 écrans (fiche → panier → checkout → confirmation) en 2 écrans (fiche → confirmation). Voir notre article sur [le paiement express en 2026](https://www.datafirefly.com/2026/08/05/paiement-express-apple-pay-google-pay-bancontact-prestashop-2026/).
### Les trois pièges du sticky cart
**1. Apparition trop précoce.** Le sticky qui apparaît dès le chargement de la page mobile cache la photo principale et perçoit comme intrusif. La règle : apparition après 200-400 px de scroll, quand le bouton d'ajout natif sort du viewport. Animation de slide-up de 200 ms pour la douceur visuelle.
**2. Cumul avec le menu hamburger fixe.** Si la boutique a déjà un header fixe en haut, le sticky cart en bas mange du viewport. Sur les écrans iPhone SE/Mini (320×568 effectif), il reste 400 px de contenu visible — c'est insuffisant pour lire confortablement. La solution : header non-sticky sur mobile (le hamburger reste accessible via geste swipe), sticky cart en bas uniquement.
**3. Conflit avec le clavier virtuel.** Au moment où l'utilisateur tape la quantité dans un champ texte du sticky cart, le clavier iOS/Android remonte et masque le bouton. La solution : utiliser des sélecteurs + / − au lieu de champs texte, ou détecter `visualViewport.height` et adapter le sticky.
### Implémentation sur PrestaShop
Le [module sticky add-to-cart pour PrestaShop](https://www.datafirefly.com/product/bouton-ajouter-panier-sticky-prestashop/) injecte la barre via le hook `displayFooterProduct`, avec CSS `position: fixed; bottom: 0` et un trigger de visibilité au scroll. La barre est nativement responsive (caché sur desktop ≥ 768 px), compatible avec les déclinaisons (mise à jour du prix au changement de variante), et désactivable par catégorie de produit (utile pour les produits config-heavy comme cuisine sur-mesure).
L'impact mesuré : +12 à +18 % de conversion mobile sur les fiches produits longues (catalogue mode, électronique, beauté), neutre à légèrement négatif sur les fiches courtes (livres, accessoires simples). À configurer par catégorie selon le profil produit.
## Levier 2 — L'autocomplétion d'adresse au checkout
### Le coût caché de la saisie manuelle
Sur PrestaShop, le formulaire d'adresse standard demande 5 à 7 champs : numéro, rue (3 lignes en option), code postal, ville, pays, complément. Sur mobile, ces champs déclenchent chacun une animation du clavier, des erreurs de saisie (autocorrect français qui transforme « rue » en « ruse »), et un risque élevé de typo dans le code postal ou la ville.
Le résultat mesurable : 14 à 22 % d'abandon spécifiquement sur le formulaire d'adresse, soit le premier point de chute du tunnel après la création de compte. Et 4 à 8 % des commandes terminées ont une adresse erronée qui génère un échec de livraison, un retour, ou un avoir.
### Comment fonctionne l'autocomplétion Google Places
L'utilisateur commence à taper son adresse. À partir de 3 caractères, une requête est envoyée à l'API Google Places Autocomplete qui retourne une liste de propositions structurées. L'utilisateur sélectionne la bonne, et l'API renvoie l'adresse complète en composants normalisés : numéro de rue, voie, code postal, ville, pays. Ces composants sont automatiquement mappés sur les champs du formulaire.
Trois bénéfices immédiats :
- Saisie en 5 à 8 secondes au lieu de 45 à 60 secondes.
- Aucune typo possible (l'adresse est validée par Google).
- Standardisation : « Rue de la République » est toujours écrit pareil, ce qui facilite la logistique (clusters de tournées) et le reporting BI.
### L'arithmétique du coût Google Places API
Google Places facture en pay-per-use depuis 2018 :
- **Autocomplete (per session)** : 0,017 $ par session, soit ~0,015 €.
- **Place Details (per request)** : 0,017 $ par lookup.
- **Quota gratuit** : 200 $/mois de crédit Google Maps Platform (depuis 2024, attention il évolue).
Sur une boutique avec 5 000 commandes/mois, c'est environ 100 € de coût API. Le ROI est immédiat : récupérer 1 % de conversion sur 5 000 commandes à 80 € de panier moyen = +4 000 €/mois de CA. Ratio : 1:40.
Pour les boutiques très volumineuses, des alternatives existent : _Mapbox Search_, _HERE Maps_, _OpenStreetMap Photon_ (gratuit mais qualité variable selon la zone). La règle pratique : Google Places en France et UE pour la qualité, Mapbox aux US, Photon pour les boutiques à très faible budget qui acceptent une moindre couverture.
### Les pièges d'implémentation
**1. Le piège du champ « complément d'adresse ».** Google Places ne retourne pas le complément (étage, bât. B, code interphone). Il faut garder un champ texte libre _après_ la sélection, mais sans le rendre obligatoire (la majorité des adresses n'en ont pas).
**2. Les zones rurales mal indexées.** Google Places couvre bien les adresses urbaines, moins bien les zones rurales (lieu-dit, route départementale). Toujours offrir une option « entrer manuellement » en fallback, avec un lien discret.
**3. Le périmètre par pays.** Restreindre l'autocomplétion au pays sélectionné via `componentRestrictions: { country: 'fr' }` améliore drastiquement la pertinence. Ne pas oublier de changer le périmètre quand l'utilisateur change le pays de livraison.
**4. La gestion des sessions.** Google facture par session, pas par requête. Une session démarre au premier appel Autocomplete et se termine à un appel Place Details, dans un délai max de quelques minutes. Bien gérer le _session token_ divise le coût par 10.
Le [module Address Lookup pour PrestaShop](https://www.datafirefly.com/product/address-lookup-autocompletion-checkout-prestashop/) gère ces quatre pièges nativement, avec configuration par pays, fallback manuel, et un session token correctement géré pour minimiser le coût API.
## Levier 3 — L'indicatif téléphone international (E.164)
### Pourquoi le numéro de téléphone fait fuir les visiteurs internationaux
Sur une boutique française, le champ téléphone par défaut accepte « 06 12 34 56 78 ». C'est lisible pour un Français. C'est incompréhensible pour un client espagnol qui ne sait pas s'il doit taper son numéro local (612 345 678), avec préfixe Espagne (+34 612 345 678), ou tenter « 0034 612 345 678 ». La règle implicite est culturelle : un boutique française attend du français.
Conséquence mesurée sur les boutiques PrestaShop multi-pays : 8 à 14 % d'abandon spécifique au champ téléphone pour les visiteurs étrangers, et 3 à 5 % de numéros saisis incorrects (sans préfixe, mal préfixés). Ces numéros incorrects font dérailler les SMS de notification livraison (Chronopost, DPD, Mondial Relay envoient des SMS sur le numéro saisi — un numéro espagnol mal préfixé est inutilisable).
### La solution : le standard E.164
E.164 est le standard ITU-T qui définit le format universel des numéros de téléphone internationaux : `+{indicatif pays}{numéro local}`, sans espaces, max 15 chiffres. Pour la France : `+33612345678`. Pour l'Espagne : `+34612345678`. Pour les États-Unis : `+12025550123`.
Un sélecteur d'indicatif international affiche un drapeau cliquable + l'indicatif, et l'utilisateur saisit uniquement son numéro local. Le format E.164 est construit automatiquement. C'est l'expérience qu'on voit sur WhatsApp, Telegram, et la plupart des applications mobiles modernes.
### Les quatre exigences d'un sélecteur E.164 professionnel
**1. Auto-détection par défaut.** Le drapeau initial est déduit du pays de livraison sélectionné, ou de l'IP géolocalisée si pas de pays choisi. L'utilisateur n'a pas à scroller dans une liste de 240 pays.
**2. Validation en temps réel par règles nationales.** Un numéro français mobile commence par 06, 07. Fixe par 01-05. Un numéro espagnol mobile commence par 6, 7. La validation par regex stricte par pays bloque les erreurs de saisie immédiatement. La librairie de référence est [libphonenumber de Google](https://github.com/google/libphonenumber), qui couvre tous les pays avec leurs règles.
**3. Stockage normalisé en base.** Le numéro stocké dans `ps_address.phone` ou `ps_address.phone_mobile` est toujours au format E.164 `+33612345678`. L'affichage peut le reformater à la lecture (« +33 6 12 34 56 78 ») mais le stockage est normalisé. Cela facilite les exports CSV, les intégrations CRM, les envois SMS.
**4. Compatible RGPD.** Le numéro de téléphone est une donnée personnelle. Le sélecteur doit respecter les droits d'accès, modification et suppression au même titre que les autres champs.
### Bénéfice secondaire : la fiabilité des SMS
Pour les boutiques qui envoient des SMS (notifications livraison, codes 2FA, alertes promo), le E.164 garantit la délivrabilité. Sans cela, le numéro `06 12 34 56 78` stocké tel quel doit être normalisé à l'envoi — opération qui échoue dans 3 à 8 % des cas selon le pays. Avec E.164 en base, le SMS part toujours au bon numéro.
### Implémentation sur PrestaShop
Le [module indicatif téléphone international PrestaShop E.164](https://www.datafirefly.com/product/indicatif-telephone-international-prestashop-e164/) remplace les champs `phone` et `phone_mobile` du formulaire d'adresse par un composant avec drapeau + indicatif + numéro local, basé sur libphonenumber.js. Il s'intègre via hook sur les formulaires d'adresse front (création, modification) et back-office (saisie commande). Multilingue, multishop, validation côté serveur en plus du côté client.
## L'effet cumulé des trois leviers
Sur une boutique PrestaShop avec 70 % de trafic mobile et 12 000 sessions/mois :
OptimisationGain conversion mobileGain CA mensuel (panier 80 €)Baseline1,2 %—+ Sticky add-to-cart1,4 %+ 1 920 €+ Autocomplétion d'adresse1,55 %+ 3 360 €+ Indicatif E.164 (multi-pays)1,65 %+ 4 320 €Total cumulé1,65 %+ 4 320 €/mois
Le gain est cumulatif mais non-linéaire : chaque levier corrige un point de friction différent, et le bénéfice marginal du troisième dépend du profil de trafic (boutique 100 % France : E.164 a un impact faible ; boutique 30 % UE : E.164 est aussi rentable que les deux autres réunis).
## Compatibilité avec le reste de la stack mobile
### Avec le paiement express
Sticky cart + paiement express = combo gagnant. Le bouton Apple Pay/Google Pay dans le sticky permet un parcours en 2 clics : tap sur Apple Pay → biométrie Face ID → confirmation. L'autocomplétion d'adresse n'intervient même pas, puisque l'adresse vient du Wallet. Voir [notre article sur le paiement express en 2026](https://www.datafirefly.com/2026/08/05/paiement-express-apple-pay-google-pay-bancontact-prestashop-2026/).
### Avec le magic link
Pour les clients identifiés, le [magic link](https://www.datafirefly.com/2026/08/25/connexion-passwordless-magic-link-prestashop-conversion-checkout-2026/) élimine le login. L'adresse de livraison est déjà en base, donc l'autocomplete est en bonus. Le combo magic link + paiement express + sticky cart représente le checkout mobile le plus court possible en 2026.
### Avec la barre de livraison gratuite
La [barre de livraison gratuite](https://www.datafirefly.com/2026/05/29/barre-livraison-gratuite-calcul-seuil-optimal-marge-prestashop-2026/) peut s'intégrer dans le sticky cart : « Encore 22 € pour la livraison gratuite ». Double bénéfice : visibilité permanente du seuil + incitation à l'ajout au panier directement depuis le sticky.
## FAQ
### Le sticky add-to-cart pollue-t-il l'expérience desktop ?
Non, à condition qu'il soit caché sur les viewports ≥ 768 px (tablette landscape et desktop). Sur desktop, le bouton d'ajout au panier est généralement visible dans le viewport initial sans scroll, le sticky n'a pas d'utilité.
### L'autocomplétion d'adresse est-elle compatible avec le DOM par PrestaShop checkout en une page ?
Oui. Le module s'attache aux champs du formulaire après leur création (event `DOMContentLoaded` ou MutationObserver pour les formulaires injectés dynamiquement). Compatible avec le checkout natif PrestaShop 8/9 et avec la plupart des modules de checkout custom.
### Que faire si Google Places refuse une adresse pourtant valide ?
Cela arrive sur 2 à 4 % des adresses (nouvelles constructions, adresses récentes non encore indexées). Toujours offrir un lien « Entrer manuellement » qui débloque les champs natifs PrestaShop. L'expérience standard est : 95 % des utilisateurs passent par l'autocomplete, 5 % par le manuel — c'est largement suffisant pour récupérer le gain de conversion.
### Le sélecteur E.164 fonctionne-t-il pour les téléphones fixes ?
Oui. libphonenumber distingue les numéros mobiles et fixes par pays, et valide les deux. Sur PrestaShop, le champ `phone` de l'adresse accepte les deux ; le champ `phone_mobile` peut être restreint aux numéros mobiles via la configuration.
### Quel est le ROI de l'autocomplétion sur une boutique 100 % France ?
Sur une boutique mono-pays France, l'autocomplete d'adresse rapporte typiquement +2 à +4 points de conversion checkout (vs +3 à +6 sur du multi-pays). Le ROI est positif dès quelques centaines de commandes/mois, car le coût API (100 € pour 5 000 commandes) reste très inférieur au gain.
## En synthèse
La conversion mobile en 2026 ne se gagne pas avec un seul levier — elle se gagne en supprimant les frictions une par une, là où elles font perdre des clients. Sticky add-to-cart, autocomplétion d'adresse, indicatif téléphone E.164 sont les trois plus mesurables, avec un effet cumulé typique de +35 à +50 % sur la conversion mobile et un payback de 30 à 60 jours sur l'investissement modules.
La pile mobile recommandée 2026 sur PrestaShop combine trois modules complémentaires : [le sticky add-to-cart](https://www.datafirefly.com/product/bouton-ajouter-panier-sticky-prestashop/), [l'autocomplétion d'adresse](https://www.datafirefly.com/product/address-lookup-autocompletion-checkout-prestashop/), et [le sélecteur E.164](https://www.datafirefly.com/product/indicatif-telephone-international-prestashop-e164/). Tous trois sont nativement responsive, multishop, multilingue, et compatibles PrestaShop 8 et 9.
Pour aller plus loin, [l'optimisation Core Web Vitals](https://www.datafirefly.com/expertise/optimisation-core-web-vitals-prestashop/) reste la couche fondamentale du mobile (LCP, INP, CLS), et le [server-side tracking GA4](https://www.datafirefly.com/2026/08/13/server-side-tracking-ga4-prestashop-ios-17-consent-mode-2026/) permet de mesurer le delta de conversion avec fiabilité, là où les cookies tiers et iOS 17 effacent une partie des signaux côté navigateur.
---
### Comment créer un espace membre payant sur PrestaShop ?
_Source :_ — _publié_ 2026-08-27
> Accès réservé, contenu payant ou adhésion à avantages : trois modèles sur un même socle. Ce que les groupes clients de PrestaShop savent faire, ce qui leur manque, et le mécanisme d'expiration qui décide de la viabilité du modèle.
Un espace membre payant sur une boutique répond à trois besoins très différents : réserver le catalogue à des professionnels validés, vendre l'accès à un contenu, ou accorder des conditions tarifaires en échange d'une cotisation. Les trois se construisent sur le même socle, mais ils n'ont ni les mêmes contraintes ni le même modèle économique.
## Trois modèles à ne pas confondre
**L'accès réservé.** Le catalogue, ou une partie, n'est visible que des membres. Modèle courant en B2B, en vente de matériel professionnel ou de produits réglementés. Le paiement peut être symbolique, l'enjeu est le contrôle d'accès.
**Le contenu payant.** Vous vendez l'accès à des fichiers, des vidéos, des formations, des plans, des bases documentaires. Le produit n'est pas physique, le renouvellement fait le chiffre d'affaires.
**L'adhésion à avantages.** Une cotisation annuelle donne accès à des prix réduits, à la livraison offerte, à des ventes privées. Le modèle des clubs. Il est le plus rentable et le plus exigeant : la valeur perçue doit rester supérieure à la cotisation, chaque année.
## Ce que PrestaShop fait nativement
Les groupes de clients permettent déjà beaucoup. Vous pouvez restreindre l'accès à une catégorie à certains groupes, appliquer une remise permanente par groupe, et afficher des prix différents.
Trois choses manquent, et ce sont exactement celles qui font l'espace membre.
- **La notion de durée.** Un client rattaché à un groupe y reste indéfiniment. Rien ne gère l'échéance ni le retrait automatique à l'expiration.
- **Le paiement de l'adhésion.** Il faut vendre l'adhésion comme un produit, puis rattacher manuellement le client au groupe. Impraticable au-delà de quelques dizaines de membres.
- **Le contenu protégé.** PrestaShop sait vendre un fichier téléchargeable attaché à une commande, pas donner accès à une bibliothèque tant que l'abonnement court.
## Combien de niveaux
Deux ou trois, rarement plus. Chaque niveau supplémentaire multiplie les règles à maintenir et complique la décision du client.
La structure qui fonctionne le mieux : un niveau gratuit qui donne accès au catalogue standard, un niveau payant qui apporte l'avantage principal, et éventuellement un niveau supérieur pour les gros volumes ou les professionnels.
Chaque niveau doit se justifier par un avantage que le niveau inférieur n'a pas, et cet avantage doit être immédiatement compréhensible. « Accès prioritaire aux nouveautés » ne vend pas. « Livraison offerte sans minimum et 10 % sur tout le catalogue » se calcule en trois secondes par le client.
## L'expiration, et ce qui la précède
C'est le mécanisme qui décide de la viabilité du modèle. Une adhésion qui expire sans prévenir produit un client mécontent et un désabonnement définitif.
La séquence qui fonctionne comporte quatre moments. Un rappel à quinze jours de l'échéance, informatif, avec le récapitulatif de ce dont le membre a bénéficié pendant l'année. Un second à trois jours. Une notification le jour de l'expiration. Et une relance à quinze jours après, souvent la plus efficace, parce que le membre a alors constaté ce qu'il a perdu.
Prévoyez une période de grâce de quelques jours après l'échéance, pendant laquelle les avantages restent actifs. Elle coûte peu et évite la mauvaise expérience du client dont la carte a expiré un week-end.
## Protéger réellement le contenu
Point technique souvent bâclé. Masquer un lien de téléchargement dans l'interface ne protège rien : le fichier reste accessible à qui connaît son adresse, et cette adresse circule.
Les fichiers doivent être stockés hors du dossier public et servis par un script qui vérifie l'adhésion à chaque requête. Pour les vidéos, l'adresse doit être signée et à durée limitée, faute de quoi un lien partagé sur un forum reste valable des mois.
Prévoyez aussi une limite de téléchargements par période. Elle ne gêne aucun usage normal et bloque le partage de compte à grande échelle.
## Le cadre légal de l'adhésion
Une adhésion payante à reconduction automatique relève des règles sur les contrats à tacite reconduction. Trois obligations en découlent.
L'information sur la reconduction doit être transmise avant l'échéance, dans un délai qui laisse au client le temps de refuser. La résiliation doit être possible par voie électronique, aussi simplement que la souscription. Et les conditions doivent être accessibles avant le paiement, pas seulement dans les conditions générales.
Ces obligations sont contrôlées, et le manquement le plus fréquent est le troisième : une adhésion vendue comme un produit ordinaire, sans que la durée et le mode de renouvellement soient annoncés sur la page d'achat.
## Mesurer la rétention
Le taux de renouvellement global ne dit pas grand-chose. Ce qui compte est le taux par cohorte : sur les membres inscrits en janvier, combien ont renouvelé douze mois plus tard ? En suivant plusieurs cohortes, vous voyez si vos améliorations produisent un effet ou si vous compensez simplement par de nouvelles inscriptions.
Second indicateur utile : le taux d'usage des avantages. Un membre qui n'utilise jamais son avantage principal ne renouvellera pas, et il est repérable des mois à l'avance.
Le couvre cette chaîne sur PrestaShop 8 et 9 : niveaux d'adhésion avec restriction de catalogue et de contenus, paiement récurrent, expiration automatique avec période de grâce, séquence de relance et protection des fichiers réservés.
---
### Checkout en une page sur PrestaShop : quels gains de conversion mesurer
_Source :_ — _publié_ 2026-08-26
> Les gains publiés vont de 5 à 40 %, ce qui suffit à les disqualifier tous. Pourquoi le test A/B est difficile sur un tunnel, comment faire une mesure avant et après valable, et les cinq indicateurs qui expliquent ce qui bouge.
Les chiffres circulant sur le checkout en une page vont de 5 à 40 % de gain de conversion. Cette dispersion suffit à disqualifier l'ensemble : ces mesures viennent de boutiques dont le point de départ, le catalogue et le panier moyen n'ont rien à voir avec les vôtres. Une boutique dont le tunnel natif est déjà bien tenu ne gagnera pas ce qu'une boutique au checkout en cinq étapes gagnera.
La seule mesure qui vous concerne est la vôtre. Voici comment l'établir sans se tromper.
## Pourquoi le test A/B est difficile ici
Sur une page de destination, le test A/B est simple. Sur un tunnel de commande, trois obstacles se cumulent.
**Le volume.** Pour détecter un écart de 10 % sur un taux de conversion de 2 %, il faut plusieurs milliers de sessions par variante. Une boutique à cent commandes par mois n'atteindra jamais la significativité en un temps raisonnable.
**La cohérence de session.** Un client qui voit la version A puis revient trois jours plus tard doit revoir la version A, sinon vous mesurez du bruit. Cela suppose un marquage persistant.
**Le risque.** Un bug sur la variante B pendant une semaine coûte directement du chiffre d'affaires, contrairement à un test sur une page secondaire.
Pour la plupart des boutiques, la mesure avant et après reste la seule approche praticable. Elle est moins rigoureuse, mais elle devient acceptable si vous contrôlez trois choses.
## La mesure avant et après, faite correctement
**Des périodes comparables.** Quatre semaines avant, quatre semaines après, en évitant les périodes promotionnelles, les vacances scolaires et les jours fériés. Comparer novembre à septembre n'a aucun sens.
**Un mix de trafic stable.** Si vous lancez une campagne publicitaire la semaine du changement, vous mesurez la campagne, pas le checkout. Vérifiez la répartition par source avant et après, elle doit être proche.
**Un seul changement à la fois.** C'est la règle la plus enfreinte. Modifier le checkout et ajouter un moyen de paiement la même semaine rend toute conclusion impossible.
## Les cinq indicateurs à relever
Le taux de conversion global est le résultat, pas le diagnostic. Cinq mesures intermédiaires expliquent ce qui bouge.
1. **Le taux de complétion du checkout** : commandes finalisées rapportées aux entrées dans le tunnel. C'est l'indicateur principal, et il isole le tunnel du reste du site.
2. **Le taux de passage par étape.** Sur un tunnel en plusieurs étapes, il révèle laquelle fait fuir. Sur un tunnel en une page, il est remplacé par le taux de complétion de chaque bloc.
3. **Le temps médian de complétion.** Le médian, pas la moyenne, qu'un seul client parti déjeuner suffit à fausser.
4. **Le taux d'erreur de formulaire.** Combien de validations échouent, et sur quels champs. C'est souvent là que se cache le vrai problème : un format de téléphone trop strict coûte plus qu'une étape supplémentaire.
5. **Le taux d'abandon après affichage des frais de port.** Il mérite sa propre mesure, parce que c'est la cause d'abandon la plus citée et qu'elle ne relève pas de l'ergonomie du tunnel.
## Segmenter par appareil, toujours
Le taux de conversion mobile est structurellement inférieur au taux desktop, dans un rapport qui va souvent du simple au double. Une moyenne globale masque donc tout : un gain de 15 % sur mobile et une perte de 3 % sur desktop peuvent produire une moyenne plate.
Comme les gains d'un checkout simplifié se concentrent presque toujours sur mobile, ne pas segmenter revient à conclure que le changement n'a rien apporté.
Segmentez également par statut client. Un client déjà inscrit, avec ses adresses enregistrées, ne rencontre pas les mêmes frictions qu'un nouveau visiteur. Le gain se mesure surtout sur les seconds.
## Les pièges d'interprétation
**La saisonnalité.** Le taux de conversion varie naturellement au fil de l'année. Comparez également à la même période de l'année précédente pour distinguer votre effet du mouvement de fond.
**L'effet nouveauté.** Les premiers jours après un changement montrent parfois des chiffres flatteurs qui se normalisent ensuite. Attendez au moins deux semaines avant de conclure.
**Le panier moyen.** Un checkout qui convertit mieux mais fait baisser le panier moyen peut être une mauvaise affaire. Regardez le chiffre d'affaires par session, pas seulement le taux de conversion.
## Ce qui bouge réellement
D'après ce qu'on observe en pratique, le gain d'un checkout simplifié se répartit rarement comme on l'imagine. Il vient surtout de trois sources : la réduction du nombre de champs, la suppression de l'obligation de créer un compte, et l'affichage des frais de port plus tôt dans le parcours.
Le passage de plusieurs étapes à une seule page compte moins que ces trois éléments pris ensemble. C'est une raison de plus pour mesurer par étape plutôt que de conclure globalement : vous saurez alors lequel de ces leviers a produit l'effet, et lequel reste à actionner.
Le regroupe le tunnel sur PrestaShop 8 et 9 : saisie sur une seule page, formulaire d'adresse allégé, commande sans création de compte obligatoire et affichage des frais de port avant la dernière étape.
---
### Comment ajouter un bloc « Souvent achetés ensemble » sur PrestaShop ?
_Source :_ — _publié_ 2026-08-26
> Un bloc alimenté au jugé propose la housse d'un autre modèle, et le visiteur cesse de le regarder. Comment construire les associations depuis l'historique de commandes, éviter le piège du best-seller et choisir le bon format d'affichage.
Le bloc « souvent achetés ensemble » est l'un des rares emplacements de recommandation qui fonctionne encore, à une condition : que les associations proposées soient réelles. Un bloc alimenté au jugé propose la housse d'un autre modèle, et le visiteur cesse de le regarder au bout de deux fiches.
## Trois sources d'association, une seule fiable
**La sélection manuelle.** Vous désignez les accessoires de chaque produit. Précis, et impraticable au-delà de deux cents références. Surtout, elle reflète ce que vous pensez que les clients associent, pas ce qu'ils associent réellement.
**La proximité de catégorie.** Proposer les produits de la même catégorie revient à proposer des concurrents du produit consulté, ce qui est de la substitution et non de la complémentarité. Cette approche fait baisser le panier au lieu de le faire monter.
**L'historique des commandes.** Vous regardez ce qui a été acheté ensemble, réellement, dans les mêmes commandes. C'est la seule source qui produit des associations que vous n'auriez pas devinées, et ce sont souvent les meilleures.
## Le calcul, sans mathématiques compliquées
Trois notions suffisent, et elles se calculent en SQL sur vos propres commandes.
**La co-occurrence** est le nombre de commandes contenant à la fois le produit A et le produit B. C'est le point de départ, et pris seul il induit en erreur.
**La confiance** est la part des acheteurs de A qui ont aussi acheté B. Si 200 personnes ont acheté A et que 60 d'entre elles ont pris B, la confiance est de 30 %. C'est déjà bien plus utile qu'un simple compte.
**Le lift** compare cette confiance au taux d'achat de B dans l'ensemble des commandes. Si B est acheté dans 25 % de toutes les commandes, une confiance de 30 % ne signifie presque rien : B se vend simplement beaucoup. Si B n'apparaît que dans 3 % des commandes, une confiance de 30 % révèle une vraie association.
C'est cette troisième notion qui évite le piège principal.
## Le piège du best-seller
Sans correction, votre produit le plus vendu apparaît comme associé à tout le catalogue. Il est présent dans un quart des commandes, donc il co-occurre avec tout.
Le bloc devient alors un emplacement publicitaire pour un seul produit, répété sur toutes les fiches. Les visiteurs l'ignorent en quelques jours, et vous perdez l'emplacement.
Le filtrage par lift règle ce cas : le best-seller n'est proposé que là où l'association est réellement plus forte que sa fréquence naturelle.
## Le seuil de fiabilité
Une association observée sur trois commandes n'est pas une association, c'est du bruit. Fixez un minimum, dix à quinze commandes contenant la paire, et n'affichez rien en dessous.
Un bloc vide vaut mieux qu'un bloc faux. Sur les produits récents ou peu vendus, prévoyez un repli : les accessoires désignés manuellement, ou rien du tout.
Point de méthode : recalculez les associations chaque semaine, pas chaque nuit. Les habitudes d'achat évoluent lentement, et un recalcul quotidien sur un gros historique coûte cher pour un résultat identique.
## Où placer le bloc, et sous quelle forme
Deux emplacements, deux usages.
**Juste sous le bouton d'achat**, sous forme d'un ensemble de deux ou trois produits avec une case à cocher par article et un bouton « ajouter la sélection au panier ». C'est le format le plus performant, parce qu'il transforme trois décisions en une seule.
**En bas de fiche**, sous forme de carrousel. Moins performant, mais utile pour les visiteurs qui lisent toute la fiche avant de décider.
Sur le premier format, affichez le total de l'ensemble et le prix de chaque élément. Cacher le détail donne l'impression d'un lot imposé et fait chuter le taux d'ajout.
## Faut-il remiser l'ensemble ?
Question à trancher avec précaution. Une remise de 5 % sur l'ensemble augmente le taux d'ajout, mais elle s'applique aussi à tous les clients qui auraient pris les deux produits de toute façon.
Le test utile consiste à mesurer d'abord sans remise. Si le taux d'ajout est déjà satisfaisant, la remise ne fait que réduire votre marge sur des ventes acquises. Elle n'a de sens que si elle déclenche des ajouts qui n'auraient pas eu lieu.
## Mesurer
Trois indicateurs. Le taux d'affichage utile, c'est-à-dire la part des fiches où le bloc a effectivement quelque chose à proposer au-dessus du seuil. Le taux d'ajout depuis le bloc. Et l'écart de panier moyen entre les commandes ayant utilisé le bloc et les autres, qui donne la valeur réelle de l'emplacement.
Le calcule ces associations sur PrestaShop 8 et 9 : analyse de l'historique de commandes avec seuil de fiabilité, filtrage des faux positifs, affichage en ensemble avec cases à cocher et ajout groupé au panier.
---
### Comment préparer le Black Friday sur PrestaShop plusieurs semaines à l'avance ?
_Source :_ — _publié_ 2026-08-25
> La contrainte la plus structurante du Black Friday n'est pas commerciale mais réglementaire, et elle se déclenche trente jours avant. Un rétroplanning à six semaines, du gel des prix de référence à la sortie d'opération.
Le Black Friday ne se prépare pas la semaine précédente. La contrainte la plus structurante n'est pas commerciale mais réglementaire, et elle se déclenche trente jours avant l'opération. Une boutique qui découvre ce point mi-novembre a déjà perdu la possibilité d'afficher les remises qu'elle avait prévues.
Voici un rétroplanning à six semaines, en partant de la contrainte la plus contraignante.
## S-6 : verrouiller le prix de référence
La règle issue de la directive Omnibus impose d'afficher, à côté du prix promotionnel, le prix le plus bas pratiqué au cours des trente derniers jours. Ce n'est pas votre prix catalogue habituel, c'est le plus bas effectivement appliqué.
La conséquence pratique est simple et souvent découverte trop tard : toute promotion, vente flash ou code de réduction appliqué dans les trente jours qui précèdent le Black Friday abaisse mécaniquement votre prix de référence, et donc réduit la remise que vous pourrez annoncer.
À six semaines, deux actions. Établir la liste des références qui seront en promotion, et geler leur prix sur les trente jours précédents. Puis extraire l'historique des prix pratiqués sur ces références, pour connaître le prix de référence réel que vous devrez afficher.
Si votre boutique enchaîne les opérations promotionnelles, cet audit révèle souvent que la remise annonçable est bien inférieure à celle envisagée.
## S-5 : construire le plan de promotion
Trois décisions, dans cet ordre.
**La sélection.** Ni tout le catalogue, ni trois références. Une sélection de 10 à 20 % du catalogue, choisie sur deux critères : la marge disponible et la capacité d'entraînement, c'est-à-dire les produits qui font entrer un panier auquel s'ajoutent des articles non remisés.
**La mécanique.** Remise en pourcentage, lot, cadeau, ou palier de panier. La remise en pourcentage est la plus lisible et la plus coûteuse. Les mécaniques de lot préservent mieux la marge à perception équivalente.
**La profondeur.** Calculez la marge après remise, frais de port inclus, et vérifiez qu'elle reste positive sur le panier moyen attendu, pas sur le panier idéal.
## S-4 : stock et logistique
Deux questions qui décident du reste.
Le stock disponible sur les références en promotion couvre-t-il la demande attendue, en général deux à quatre fois un volume normal sur les produits mis en avant ? Une rupture le jour J transforme une opération réussie en vague de réclamations.
Votre chaîne de préparation absorbe-t-elle le pic ? Les commandes du week-end du Black Friday partent la semaine suivante. Prévoyez les renforts, prévenez le transporteur, et surtout annoncez des délais réalistes plutôt qu'optimistes. Un délai annoncé à trois jours et tenu à huit coûte plus cher en service client que la marge gagnée.
## S-3 : l'habillage
La partie visible, et celle qui doit être préparée à l'avance plutôt que bricolée la veille.
Bandeau d'annonce, visuels de catégories, page dédiée à l'opération, badges sur les fiches. Le point important est la planification : ces éléments doivent s'activer et se désactiver automatiquement à date, sans intervention manuelle un dimanche soir.
Prévoyez aussi la fin. Un site encore habillé aux couleurs du Black Friday le 15 décembre donne l'impression d'une boutique abandonnée.
## S-2 : la technique
Quatre vérifications, à faire avant que le trafic n'arrive.
1. **Le test de charge.** Simulez cinq à dix fois votre trafic normal et observez où ça casse. C'est presque toujours la base de données, sur les requêtes de filtres et de recherche.
2. **Le cache.** Vérifiez que les pages produit et catégorie sont bien servies depuis le cache, et prévoyez la purge au moment du changement de prix.
3. **Le plan de repli.** Que faites-vous si le site tombe le vendredi à 10 h ? Une page d'attente avec collecte d'email vaut mieux qu'une erreur serveur.
4. **Les sauvegardes.** Une sauvegarde complète juste avant l'opération, et vérifiée. Une sauvegarde jamais restaurée n'est pas une sauvegarde.
## S-1 : les emails
Trois envois suffisent : une annonce à J-3, un lancement le jour J, un rappel de fin. Le rappel de fin génère habituellement plus de commandes que l'annonce.
Ouvrez également une liste d'attente sur les produits qui seront en promotion, pour les visiteurs qui arrivent avant le lancement. C'est la meilleure base d'envoi possible : elle contient des gens qui ont déjà manifesté un intérêt précis.
## J-1 : la checklist
Les prix promotionnels sont programmés avec une date de début et une date de fin. Le prix de référence affiché est le bon. Le stock est à jour. Les emails sont programmés. Le bandeau est planifié. Une commande de test a été passée de bout en bout, paiement compris. Le plan de repli est accessible.
## Le lendemain
La sortie d'opération est aussi importante que l'entrée. Les prix reviennent automatiquement, les badges disparaissent, l'habillage se retire. Et vous relevez trois chiffres pendant qu'ils sont frais : le chiffre d'affaires par mécanique, la marge réelle après remise et frais de port, et le taux de retour des produits achetés en promotion, qui est en général supérieur à la normale.
Le traite la partie habillage sur PrestaShop 8 et 9 : bandeaux, visuels et éléments décoratifs programmés à date de début et de fin, avec retour automatique à l'état normal. Pour la mécanique de remise elle-même, le gère les périodes et la fin automatique.
---
### Connexion sans mot de passe (magic link) sur PrestaShop en 2026 : conversion checkout et fin du captcha
_Source :_ — _publié_ 2026-08-25
> 14 % des clients identifiés abandonnent au moment du login, 28 % passent par « mot de passe oublié ». Sur une boutique mid-market, c'est 8 à 18 % de revenu perdu sur la friction d'authentification. Le magic link et le passkey changent l'équation : +21 points de login successful rate, +4 à +8 points de conversion checkout, −68 % de tickets support compte.
## Le mot de passe est devenu un boulet de la conversion e-commerce
Sur les boutiques PrestaShop que nous instrumentons, environ 14 % des visiteurs identifiés (déjà clients) abandonnent au moment du login. Pas avant — au moment précis où ils doivent saisir leur mot de passe. Et sur les 86 % qui parviennent à se connecter, 28 % passent par « mot de passe oublié », ce qui ajoute un détour de 2 à 4 minutes au parcours d'achat. Cumulé sur une boutique mid-market, c'est 8 à 18 % de revenu qui passe à la trappe sur la friction d'authentification.
Le mot de passe traîne aussi un coût caché : 30 à 50 % des tickets support e-commerce concernent un compte (réinitialisation, blocage après tentatives, compte introuvable). À 5 à 8 € le ticket support traité, sur 2 000 tickets par mois, c'est 35 à 80 K€/an de coût opérationnel. Sans compter le coût psychologique : un client qui se fait éjecter du checkout par un mot de passe oublié devient plus difficile à reconquérir.
L'alternative existe depuis longtemps et atteint sa maturité en 2026 : la connexion sans mot de passe par lien magique (_magic link_) ou passkey (WebAuthn). Le principe est identique à celui qui a permis à Slack, Notion, Linear de remplacer le mot de passe par défaut : on envoie un lien unique par email, le clic authentifie. Plus de mot de passe à mémoriser, plus de captcha, plus de blocage.
## Comment fonctionne un magic link, techniquement
Le flux complet en cinq étapes :
1. **L'utilisateur saisit son email** sur le formulaire de connexion.
2. **Le serveur génère un token cryptographique** (typiquement 32 octets aléatoires, encodés en base64url) avec une durée de vie limitée (15 minutes par défaut).
3. **Le token est stocké en base**, lié à l'email, avec un hash (jamais en clair) et une date d'expiration.
4. **Un email est envoyé** avec un lien de la forme `https://boutique.fr/login/magic?token=abc...`
5. **Au clic, le serveur valide le token**, ouvre la session, et invalide le token (usage unique).
Quatre propriétés cryptographiques essentielles à respecter :
- **Token aléatoire cryptographique** : généré avec `random_bytes()` en PHP, jamais avec `mt_rand()` ou un UUID prévisible.
- **Hash en base** : on ne stocke pas le token en clair, on stocke son SHA-256 (comme pour un mot de passe haché). Cela protège la base en cas de fuite.
- **Single-use** : un token validé est immédiatement invalidé. Pas de double activation possible.
- **Time-bound** : 15 minutes d'expiration par défaut. Au-delà, le token est mort, l'utilisateur redemande un lien.
Le [module DfMagicLink pour PrestaShop](https://www.datafirefly.com/product/dfmagiclink-connexion-sans-mot-de-passe-prestashop/) implémente ces quatre garanties par défaut, avec en plus une protection anti-énumération (réponse identique que l'email existe ou non, pour éviter de révéler la base clients à un attaquant) et un rate limiting par IP.
## Magic link vs Passkey (WebAuthn) : deux technologies complémentaires
Magic link et passkey ne sont pas concurrents mais complémentaires, chacun avec son cas d'usage :
### Magic link — email-based, universel, faible friction
- Compatible avec tous les terminaux et tous les navigateurs.
- Ne nécessite aucune préinscription : un email suffit.
- Dépend de la délivrabilité email (cf. [email transactionnel et DMARC/BIMI](https://www.datafirefly.com/2026/07/24/email-transactionnel-delivrabilite-dmarc-bimi-prestashop-2026/)).
- Friction résiduelle : ouvrir sa boîte email, cliquer.
### Passkey — biométrie, instantané, lié à l'appareil
- L'utilisateur s'authentifie par biométrie (Touch ID, Face ID, empreinte Android) ou code PIN appareil.
- Aucun aller-retour email, instantané.
- Exige une inscription préalable du passkey sur chaque appareil.
- Standardisé W3C WebAuthn, supporté par tous les navigateurs modernes depuis 2023.
### Le pattern hybride 2026
Le pattern qui marche aujourd'hui en e-commerce :
- **Première connexion ou nouveau terminal** : magic link (universel, pas d'enregistrement préalable).
- **Après la première connexion réussie**, propose d'enregistrer un passkey sur l'appareil pour les connexions suivantes (« connectez-vous en un clic la prochaine fois »).
- **Mot de passe classique en option** pour les utilisateurs qui le souhaitent, ou pour le compte admin du back-office (où le 2FA reste roi).
Ce pattern combine l'universalité du magic link et l'instantanéité du passkey, sans imposer un changement brutal d'habitude.
## Impact mesuré sur la conversion
Sur les boutiques PrestaShop qui ont basculé du mot de passe classique vers un système magic link en première ligne :
- **Login successful rate** : de 73 % à 94 % (gain : +21 points). Les 6 % d'échecs résiduels sont des fautes de frappe d'email ou des problèmes de délivrabilité.
- **Temps moyen de connexion** : de 47 s à 22 s (clic email inclus).
- **Tickets support liés au compte** : −68 % en moyenne sur 3 mois.
- **Conversion checkout des clients identifiés** : +4 à +8 points.
Sur une boutique faisant 200 commandes/mois à un panier moyen de 80 €, +6 points de conversion checkout sur 35 % de clients identifiés = +0,6 commandes/jour × 80 € = +1 460 €/mois de CA. Plus les tickets support économisés. Plus le coût psychologique d'une expérience fluide.
## Implémentation sur PrestaShop : les choix d'architecture
### Architecture de la base de données
Une table dédiée `ps_df_magic_token` avec les champs :
- `id_token` (PK auto-increment)
- `id_customer` (FK `ps_customer`, nullable pour création de compte au vol)
- `email` (indexé)
- `token_hash` (SHA-256, indexé pour validation rapide)
- `expires_at` (datetime)
- `consumed_at` (datetime nullable, marqueur d'utilisation)
- `ip_request`, `ip_consume` (audit forensique)
- `user_agent` (audit forensique)
Un index composite `(token_hash, expires_at, consumed_at)` pour valider rapidement un token entrant.
### Le contrôleur PrestaShop
Deux contrôleurs modernes (Symfony) pour PS 8/9 :
- `MagicLinkRequestController` — reçoit l'email, génère le token, envoie l'email. POST avec rate limiting.
- `MagicLinkConsumeController` — reçoit le token via GET, valide, ouvre la session via `$context->customer->logged = true` et `$context->cookie`.
Attention au piège classique : ne **jamais** ouvrir la session sur un GET sans vérification CSRF si le lien est cliqué depuis un email — un preview lien (Outlook, Gmail link preview) pourrait consommer le token. La solution : exiger un clic explicite sur une page intermédiaire qui POST le token, ou détecter les _preview agents_ (User-Agent contenant _"GoogleImageProxy"_, _"Mail-Preview"_) et ne pas consommer le token sur leur passage.
### Le template email
L'email magic link est un email transactionnel à haute priorité. Quatre règles :
- **Délai d'envoi sous 5 secondes** — au-delà, l'utilisateur recommence à saisir son email.
- **Délivrabilité maximale** — SPF, DKIM, DMARC alignés ; pas d'images traçantes qui dégradent le score spam ; sujet court (« Connexion à votre boutique »).
- **Bouton bien visible** — pas un lien hypertexte planqué dans un paragraphe. Un CTA dédié de 200×50 px en couleur de marque.
- **Mention de sécurité** — « si vous n'êtes pas à l'origine de cette demande, ignorez ce message » (atténue le risque de social engineering).
L'[implémentation propre de la délivrabilité email transactionnel](https://www.datafirefly.com/2026/07/24/email-transactionnel-delivrabilite-dmarc-bimi-prestashop-2026/) est un prérequis : un magic link qui finit en spam, c'est un client qui abandonne.
## Sécurité : les attaques à anticiper
### 1. Énumération de comptes
Si la réponse diffère selon que l'email existe ou non en base (« nous vous avons envoyé un lien » vs « cet email n'existe pas »), un attaquant peut énumérer la base clients par bruteforce. La règle : réponse identique dans les deux cas, et envoi d'email _uniquement_ si le compte existe.
### 2. Phishing par lien usurpé
Un attaquant envoie un email imitant votre marque avec un faux magic link qui redirige vers une page de phishing. La protection : sensibiliser les clients (mention dans l'email réel : « vérifiez que l'URL commence bien par boutique.fr »), et publier BIMI pour afficher le logo de marque dans Gmail/Yahoo. C'est le levier de confiance le plus efficace en 2026.
### 3. Bruteforce de tokens
Avec 32 octets aléatoires, l'espace de recherche est 2256, soit pratiquement infranchissable. Mais un attaquant pourrait tenter du bruteforce sur l'endpoint de validation. La protection : rate limiting par IP (10 tentatives/minute max), et logging des tentatives invalides.
### 4. Vol de session via interception email
Si la boîte email du client est compromise, l'attaquant reçoit les magic links. C'est le risque résiduel principal du magic link : il déporte la sécurité du compte boutique vers la sécurité de l'email. La protection : durée de vie courte (15 min), invalidation au login, et 2FA optionnel pour les comptes à enjeu (paniers récurrents, comptes B2B).
### 5. Replay attack
Un attaquant intercepte un magic link et le rejoue. Protection : single-use enforcé en base (`consumed_at` non NULL bloque la validation).
## Cas particuliers à traiter
### Création de compte au premier login
Si le visiteur saisit un email inconnu en base, deux options : refus (« cet email n'a pas de compte ») ou création au vol. La création au vol est UX-friendly (zéro formulaire d'inscription) mais demande un complément ultérieur (nom, adresse pour la livraison) au premier checkout. Le pattern recommandé pour PrestaShop : créer le compte au vol avec un statut _« incomplete »_, et le compléter au moment du checkout (qui demande de toute façon adresse, téléphone, etc.).
### Magic link + récupération de panier abandonné
Combinaison puissante : on envoie au client un email de panier abandonné qui contient à la fois le récap du panier ET un magic link pour reprendre l'achat sans login. Conversion sur panier abandonné mesurée : ×1,6 vs un email classique avec login standard. C'est ce que combinent les modules [DfSaveCart](https://www.datafirefly.com/product/dfsavecart-sauvegarde-panier-lien-magique-prestashop/) et DfMagicLink quand on les déploie ensemble.
### Compte B2B avec multi-utilisateurs
Pour les boutiques [B2B avec comptes pro multi-utilisateurs](https://www.datafirefly.com/2026/05/25/b2b-prestashop-comptes-pros-devis-paiement-differe-kyb-2026/), le magic link reste valable : chaque collaborateur reçoit le lien sur son email pro. Mais on ajoute un audit log : qui s'est connecté quand, depuis quelle IP. Cela facilite les contrôles internes (qui a passé telle commande, etc.).
### Comptes admin / back-office
Pour le back-office PrestaShop, le magic link reste tentant mais le 2FA TOTP (Google Authenticator, Authy) ou le passkey direct sont à préférer. Une boîte email compromise donnant accès à l'admin de votre boutique, c'est game over. La règle : magic link en front-office, 2FA fort en back-office.
## Compatibilité PrestaShop 8 et 9
Sur PrestaShop 8 (Symfony 4) et 9 (Symfony 6), l'implémentation utilise :
- Routes Symfony modernes via `config/routes.yml` ou attributs PHP 8.
- Sessions PrestaShop natives via `$context->cookie` + `Customer::login()`.
- Hooks pour s'intégrer aux formulaires de login natifs (`displayCustomerLoginFormAfter`).
- Multilingue via XLIFF (FR, EN, ES, DE) pour les emails et messages d'erreur.
- Multishop : tokens scopés par `id_shop` pour ne pas permettre la connexion cross-shop avec un seul lien.
Le [module DfMagicLink](https://www.datafirefly.com/product/dfmagiclink-connexion-sans-mot-de-passe-prestashop/) couvre ces compatibilités nativement et s'intègre avec la session natif PrestaShop sans forker le système d'auth.
## FAQ
### Le mot de passe doit-il disparaître complètement ?
Non, et c'est même contre-productif. Certains utilisateurs préfèrent le mot de passe par habitude. Le pattern recommandé : magic link en première proposition (95 % des cas), mot de passe en option (« utiliser un mot de passe à la place »). Pas de pression, pas de friction d'apprentissage.
### Le RGPD impose-t-il des contraintes sur les magic links ?
Pas directement, mais les traces d'audit (IP, user-agent, dates) sont des données personnelles soumises au RGPD. Durée de conservation recommandée : 1 an pour les tokens consommés (suffisant pour audit forensique), purge automatique des tokens expirés non consommés. Le [droit à l'oubli](https://www.datafirefly.com/2026/05/23/droit-oubli-rgpd-article-17-suppression-compte-trace-fiscale-prestashop-2026/) doit aussi supprimer ces traces, sauf si elles sont nécessaires à une enquête en cours.
### Que se passe-t-il si l'email du client est désactivé ?
Le magic link est inenvoyable, le client est bloqué. Pour ce cas, on garde une procédure de récupération assistée : formulaire de contact, vérification d'identité par autres canaux (numéro de téléphone, dernier achat), puis changement d'email manuel par le support. C'est rare (1 % des cas) mais doit être documenté.
### Le magic link fonctionne-t-il en application mobile ?
Oui, avec des _deep links_ ou _universal links_ (iOS) / _app links_ (Android). Le lien email ouvre directement l'app si elle est installée, avec une session automatique. PrestaShop n'a pas d'app native, mais pour les boutiques avec PWA ou app hybride, cette intégration est techniquement standard.
### Combien de temps faut-il pour intégrer un système magic link ?
Avec un module clé en main comme [DfMagicLink](https://www.datafirefly.com/product/dfmagiclink-connexion-sans-mot-de-passe-prestashop/), c'est typiquement 30 minutes d'installation + 1 à 2 heures de personnalisation (template email aux couleurs de la marque, mention de sécurité, traduction des labels). En développement custom, comptez 3 à 5 jours pour atteindre la qualité de production (sécurité, délivrabilité, tests).
## En synthèse
Le magic link n'est pas un gadget UX — c'est le retrait du frein le plus mesurable du checkout en 2026, avec un impact direct de +4 à +8 points de conversion sur les clients identifiés et −60 % de tickets support compte. Combiné aux passkeys pour les utilisateurs réguliers, il offre une expérience de connexion qui rivalise enfin avec Amazon, Google Pay et les leaders du marché.
Pour l'implémenter proprement sur PrestaShop, le [module DfMagicLink](https://www.datafirefly.com/product/dfmagiclink-connexion-sans-mot-de-passe-prestashop/) couvre les cinq propriétés cryptographiques essentielles (token aléatoire, hash en base, single-use, time-bound, anti-énumération) et s'intègre avec le système de session natif PrestaShop. Pour maximiser le ROI, on le combine avec la [sauvegarde de panier par lien magique](https://www.datafirefly.com/product/dfsavecart-sauvegarde-panier-lien-magique-prestashop/) qui exploite la même infrastructure pour la récupération de paniers abandonnés.
Le prérequis non négociable : une délivrabilité email transactionnelle au niveau professionnel (DMARC strict, DKIM aligné, BIMI). Sans ça, le magic link finit en spam et la boutique perd plus de clients qu'elle n'en sauve. [Notre audit PrestaShop](https://www.datafirefly.com/expertise/audit-prestashop/) inclut systématiquement la vérification de cette couche email avant de recommander un déploiement magic link.
---
### Comment créer un configurateur produit par étapes sur PrestaShop ?
_Source :_ — _publié_ 2026-08-25
> Cinq attributs à quatre valeurs donnent 1 024 déclinaisons pour un seul produit. Au-delà de cent, le modèle cède et il faut configurer plutôt que décliner. Découpage en étapes, règles de dépendance, prix en direct et récupération des abandons.
Un client qui commande une cuisine, un vélo personnalisé, une fenêtre sur mesure ou un ordinateur configuré ne choisit pas une référence : il construit un produit. Le sélecteur de déclinaisons de PrestaShop, conçu pour une taille et une couleur, ne tient pas ce parcours.
Voici quand un configurateur devient nécessaire, et comment le structurer pour qu'il termine des ventes au lieu de les faire abandonner.
## Pourquoi les déclinaisons ne suffisent pas
La raison est arithmétique. PrestaShop matérialise chaque combinaison d'attributs comme une déclinaison enregistrée en base, avec sa référence, son stock, son prix et ses images.
Cinq attributs à quatre valeurs chacun donnent 1 024 déclinaisons pour un seul produit. Sept attributs à cinq valeurs en donnent plus de 78 000. Le back-office devient inutilisable, les temps de chargement de la fiche s'effondrent, et la gestion du stock n'a plus aucun sens puisque vous ne stockez pas des combinaisons mais des composants.
Le seuil pratique se situe autour de cent déclinaisons par produit. Au-delà, le modèle par déclinaisons cesse d'être tenable et il faut passer à une logique de configuration : des options évaluées à la volée, sans qu'aucune combinaison ne soit stockée à l'avance.
## Découper en étapes
Un formulaire présentant vingt options simultanément produit deux réactions : la paralysie, ou le départ. Le découpage en étapes règle ce problème, à trois conditions.
**Trois à cinq étapes, pas davantage.** Au-delà, la barre de progression devient décourageante. Si vous avez plus de matière, regroupez plutôt que d'ajouter des étapes.
**Une décision par étape.** L'étape porte une question, pas une liste. « Quelle dimension ? » puis « Quel matériau ? », et non un écran mêlant dimensions, matériaux et finitions.
**Du structurant vers le cosmétique.** Les choix qui conditionnent les autres passent en premier : dimension, modèle, motorisation. Les choix décoratifs, couleur, finition, gravure, viennent en dernier. Cet ordre a un effet secondaire utile : le client s'engage sur les décisions difficiles pendant que sa motivation est intacte.
## Les dépendances entre options
C'est la partie qui distingue un vrai configurateur d'un formulaire à étapes, et celle qui coûte le plus cher à mal traiter.
Trois types de règles doivent exister.
- **L'exclusion.** Le choix A à l'étape 1 rend le choix B impossible à l'étape 3. La règle doit masquer ou griser l'option, pas afficher une erreur après validation.
- **La contrainte de valeur.** Une largeur supérieure à 120 centimètres impose un renfort. L'option devient obligatoire et présélectionnée, avec une explication.
- **La valeur par défaut conditionnelle.** Selon le modèle choisi, la finition la plus courante diffère. Présélectionner correctement réduit le nombre de décisions réelles.
Le comportement à éviter absolument : laisser le client construire une configuration invalide pendant quatre étapes, puis l'invalider au moment de l'ajout au panier. Chaque règle doit s'appliquer au moment du choix, pas à la fin.
## Le prix en temps réel
Le prix doit être visible en permanence et se mettre à jour à chaque choix. Un client qui découvre le total à la dernière étape abandonne, ou commande puis annule.
Trois précisions techniques. Le prix affiché doit être calculé côté serveur, pas dans le navigateur, sinon un utilisateur averti peut le manipuler. L'affichage doit distinguer le prix de base des suppléments, afin que le client comprenne ce qui fait monter le total. Et la mise à jour doit être visible : un montant qui change sans animation passe inaperçu.
Sur les configurations où le prix peut varier fortement, afficher une fourchette dès l'entrée dans le configurateur évite de faire perdre son temps à un visiteur hors budget.
## Récupérer les abandons
Un configurateur produit mécaniquement des abandons en cours de parcours : le client compare, réfléchit, demande un avis. Ces abandons sont récupérables, contrairement à un abandon de panier classique, parce que la configuration représente un travail que le client ne veut pas refaire.
Trois mécanismes, par ordre d'efficacité.
1. **La sauvegarde automatique** de la configuration en cours, restaurée au retour sur le site, même sans compte.
2. **Le lien de reprise** envoyé par email, qui rouvre le configurateur exactement à l'endroit quitté. C'est aussi un lien partageable, utile quand la décision se prend à deux.
3. **La demande de devis** depuis le configurateur, pour les configurations complexes où le client préfère un échange humain avant de payer.
## Ce qui part en production
Point négligé et coûteux. Une commande configurée doit être lisible par la personne qui prépare ou fabrique. Un bon de préparation affichant « Produit configuré, réf. CFG-4471 » sans le détail des options est une source d'erreurs garantie.
La configuration doit apparaître intégralement sur le bon de préparation, sur la facture et dans le détail de commande en back-office, sous une forme lisible par un humain et non sous forme d'identifiants techniques.
Prévoyez également le cas de la modification après commande : un client qui appelle pour changer une finition avant lancement en production doit pouvoir être servi sans qu'on recrée la commande entière.
## Mettre en place le configurateur
Le couvre cette chaîne sur PrestaShop 8 et 9 : découpage en étapes avec options visuelles, règles de dépendance entre choix, calcul du prix en direct côté serveur, sauvegarde et reprise de configuration, et report du détail sur les documents de commande.
---
### Comment améliorer la recherche interne de PrestaShop 8 sans changer de thème ?
_Source :_ — _publié_ 2026-08-24
> Thème acheté, personnalisé, modifié par un prestataire absent : y toucher est disproportionné. L'essentiel des gains se fait ailleurs, en quatre étapes dont aucune n'exige de modifier un template.
La contrainte est fréquente : vous avez un thème acheté, personnalisé, éventuellement modifié par un prestataire qui n'est plus là. Y toucher pour améliorer la recherche revient à ouvrir un chantier disproportionné, avec un risque de régression sur des pages qui fonctionnent.
Bonne nouvelle, l'essentiel des gains se fait ailleurs. Voici les quatre étapes, de la plus rentable à la plus lourde, sans qu'aucune n'exige de modifier un template.
## Étape 1 : les réglages natifs, trente minutes
Tout se passe dans **Configurer > Paramètres de la boutique > Recherche**, et cette page est rarement ouverte.
**La pondération des champs.** PrestaShop attribue un poids à chaque source : nom du produit, référence, description courte, description longue, marque, attributs, caractéristiques. Les valeurs par défaut sont rarement adaptées. Sur un catalogue technique où les clients cherchent par référence, monter le poids de la référence change immédiatement la pertinence. Sur un catalogue de mode, c'est le nom et les attributs qui priment.
**La longueur minimale des mots.** Fixée à trois caractères par défaut, elle exclut les recherches sur des tailles, des références courtes ou des sigles. La descendre à deux améliore la couverture, au prix d'un index plus volumineux.
**La recherche floue.** L'option existe et n'est pas toujours activée. Elle autorise une correspondance sur le début des mots, ce qui rattrape les singuliers, les pluriels et les troncatures. Elle ne rattrape pas une faute au milieu d'un mot, mais elle coûte zéro.
**La reconstruction de l'index.** Le bouton se trouve en bas de la même page. Si vous avez fait un import ces derniers mois, une partie de votre catalogue n'est probablement pas indexée. Lancez la reconstruction complète, puis programmez une tâche récurrente pour l'indexation incrémentale.
## Étape 2 : nettoyer le vocabulaire du catalogue
Deuxième meilleur rapport effort sur résultat, et il ne demande aucune intervention technique.
La méthode : extraire les recherches sans résultat des trois derniers mois, les trier par fréquence, et regarder les cinquante premières. Vous y trouverez surtout des termes que vos clients emploient et que votre catalogue n'emploie pas.
Ces termes se placent dans un champ indexé mais discret. Les caractéristiques produit conviennent bien : elles sont indexées, pondérables, et n'apparaissent pas nécessairement dans la description commerciale. Une caractéristique « Autres appellations » remplie avec trois ou quatre synonymes règle des dizaines de recherches perdues.
Comptez une demi-journée pour traiter les cinquante premiers termes. C'est le meilleur investissement de la liste.
## Étape 3 : l'autocomplétion, sans toucher au thème
C'est ici que la contrainte de départ trouve sa réponse. Une couche de suggestions instantanées n'a pas besoin de remplacer votre champ de recherche : elle s'y accroche.
Le principe technique est simple. Un module se déclare sur le hook d'en-tête, injecte son script, détecte le champ de recherche existant du thème par son sélecteur, et attache son propre comportement. Le template du thème n'est pas modifié. Une mise à jour du thème n'écrase rien, et une désinstallation du module rend le champ à son comportement d'origine.
La seule condition est que le champ de recherche soit identifiable, ce qui est le cas de la quasi-totalité des thèmes, y compris fortement personnalisés. Sur un thème exotique, un sélecteur configurable suffit à régler le cas.
## Ce que doit contenir une suggestion
Une liste de noms de produits en texte brut n'apporte presque rien. Une suggestion utile contient quatre éléments.
- **La miniature du produit.** Le visiteur reconnaît visuellement avant de lire.
- **Le prix.** Il permet d'écarter immédiatement ce qui est hors budget, sans ouvrir la fiche.
- **La disponibilité.** Proposer un produit épuisé en tête de suggestion crée une frustration inutile.
- **Les catégories correspondantes**, à côté des produits. Un client qui tape un terme générique veut souvent parcourir, pas atterrir sur une référence précise.
Un cinquième élément mérite d'être testé : les recherches populaires affichées avant même la première frappe, dans le champ vide. Sur un catalogue saisonnier, elles orientent efficacement.
## Le comportement mobile
Sur mobile, l'autocomplétion doit occuper l'écran entier plutôt que se glisser sous le champ. Le clavier virtuel occupe déjà la moitié basse, et une liste déroulante de quatre suggestions dans les cent pixels restants est inutilisable.
Autre point : déclencher la recherche à partir de deux caractères, pas de trois, et attendre environ 250 millisecondes après la dernière frappe avant d'interroger le serveur. En dessous, vous multipliez les requêtes inutiles.
## Étape 4 : mesurer
Trois indicateurs, à relever avant toute modification pour disposer d'un point de comparaison.
Le taux de recherches sans résultat, qui doit baisser après les étapes 1 et 2. Le taux de clic sur les suggestions, qui indique si elles sont pertinentes. Et le taux de conversion des sessions avec recherche, à comparer à celui des sessions sans, ce qui donne la valeur économique du chantier.
## Quand il faut quand même toucher au thème
Deux situations. Si votre thème n'a pas de champ de recherche visible sur mobile, aucune couche logicielle ne remplacera son absence. Et si vous voulez une page de résultats entièrement repensée, avec filtres latéraux et tri personnalisé, le template de résultats devra être repris.
Ces deux cas mis à part, les quatre étapes ci-dessus couvrent l'essentiel du gain accessible.
Le traite les étapes 3 et 4 sur PrestaShop 8 et 9 : suggestions instantanées avec image, prix et disponibilité, accrochage au champ existant sans modification de template, et journal des requêtes avec taux de clic et conversion.
---
### Module PrestaShop du commerce ou développement sur mesure : comment arbitrer
_Source :_ — _publié_ 2026-08-24
> Le prix d'achat n'est qu'une fraction du coût réel, dans les deux cas. Les quatre postes oubliés du développement sur mesure, une comparaison chiffrée sur trois ans, et les cinq situations où le sur-mesure reste la bonne réponse.
La question revient à chaque besoin non couvert : acheter un module à 90 euros ou faire développer une fonctionnalité sur mesure. Posée ainsi, elle semble tranchée d'avance. Elle ne l'est pas, parce que le prix d'achat n'est qu'une fraction du coût réel, dans les deux cas.
## Les quatre postes de coût qu'on oublie
Un développement sur mesure ne se limite pas aux jours de code. Quatre postes s'ajoutent systématiquement, et ils représentent souvent autant que le développement lui-même.
1. **La spécification.** Décrire précisément le comportement attendu, y compris les cas limites, prend une à trois journées. Les sauter revient à les payer plus tard en allers-retours.
2. **La recette.** Tester la fonctionnalité sur un environnement de préproduction, remonter les écarts, valider les corrections. Comptez 20 à 30 % du temps de développement.
3. **La maintenance corrective.** Les bugs qui apparaissent en conditions réelles, six semaines après la mise en ligne, quand personne n'a plus le contexte en tête.
4. **La montée de version.** Le poste le plus sous-estimé. Un développement fait pour PrestaShop 8 devra être repris pour PrestaShop 9. Cette reprise n'est jamais budgétée au moment de la décision initiale.
Un module du commerce a ses propres coûts cachés, plus légers mais réels : le temps de configuration, l'adaptation au thème, et le risque d'abandon par l'éditeur.
## Le coût total sur trois ans
Prenons un besoin concret, une recherche interne performante, et comparons sur trois ans.
**Voie module.** Achat autour de 150 euros. Configuration et adaptation au thème, une demi-journée. Mises à jour incluses, généralement pendant douze mois puis renouvelables. Montée vers PrestaShop 9 assurée par l'éditeur. Coût total sur trois ans : de l'ordre de 600 à 900 euros, temps interne compris.
**Voie sur mesure.** Spécification, deux jours. Développement, dix à quinze jours pour une recherche avec tolérance aux fautes et suggestions. Recette, trois jours. Soit quinze à vingt jours à 500 euros, entre 7 500 et 10 000 euros. Ajoutez la maintenance et la reprise pour la version majeure suivante, et vous dépassez 12 000 euros sur trois ans.
L'écart est d'un facteur quinze. Il ne se justifie que si le sur-mesure apporte quelque chose que le module n'apporte pas.
## Les cinq cas où le sur-mesure s'impose
- **Un processus métier qui vous est propre.** Une logique de tarification, de production ou d'expédition qui n'existe nulle part ailleurs parce qu'elle vient de votre organisation.
- **Une intégration à un système existant.** Un ERP maison, un logiciel de gestion sectoriel, un outil de production. Aucun module ne connaît votre schéma de données.
- **Un avantage concurrentiel.** Si la fonctionnalité est ce qui vous différencie, l'acheter revient à la partager avec vos concurrents.
- **Une contrainte réglementaire sectorielle.** Pharmacie, produits phytosanitaires, armurerie, alcools : des obligations que le marché des modules généralistes ne couvre pas.
- **Une volumétrie hors norme.** Cent mille références ou dix mille commandes par jour changent les contraintes techniques au point que les solutions génériques cèdent.
## Les quatre cas où le module gagne
Un besoin standard, partagé par des milliers de boutiques : recherche, avis, promotions, retours, conformité réglementaire nationale. Un budget contraint, où l'écart de coût est décisif. Un délai court, un module se déploie dans la journée. Et une équipe sans compétence technique interne, pour qui un développement sur mesure crée une dépendance permanente à un prestataire.
## La voie médiane
Elle est souvent la bonne et rarement envisagée : partir d'un module et le surcharger pour la partie spécifique. Vous récupérez 80 % du besoin immédiatement et vous ne développez que l'écart.
Cette approche suppose une condition, à vérifier avant l'achat : que le module expose des points d'extension propres, hooks ou services, plutôt que d'imposer une modification directe de son code. Un module modifié dans ses fichiers perd ses mises à jour, ce qui vous ramène au sur-mesure sans en avoir les avantages.
## Les questions à poser avant d'acheter
1. Le module est-il compatible avec PrestaShop 9, ou seulement annoncé comme tel ?
2. À quelle fréquence a-t-il été mis à jour ces douze derniers mois ?
3. Le support répond-il en français, et sous quel délai ?
4. Le module utilise-t-il des surcharges de classes, qui entrent en conflit avec d'autres modules, ou uniquement des hooks ?
5. Existe-t-il une démonstration en back-office, et pas seulement des captures d'écran ?
Les deux dernières questions sont les plus discriminantes et les moins souvent posées.
## Un repère de décision
Si le besoin est décrit par une phrase que d'autres marchands prononceraient à l'identique, un module existe et il sera moins cher. S'il faut trois paragraphes et un schéma pour l'expliquer, le sur-mesure devient défendable.
Le est un exemple de cet arbitrage : une fonctionnalité dont le développement interne représenterait plusieurs semaines, disponible en configuration à la journée sur PrestaShop 8 et 9.
---
### Indice de réparabilité et durabilité : afficher la note sur PrestaShop
_Source :_ — _publié_ 2026-08-23
> Une note sur 10 avec une décimale, un pictogramme coloré, à proximité du prix : le format est imposé et le manquement se constate en une seconde. Les catégories concernées, où afficher, comment stocker la donnée et ce que change l'indice de durabilité.
L'indice de réparabilité est entré en vigueur au 1er janvier 2021 pour cinq catégories de produits, avant d'être étendu à quatre autres en novembre 2022. Depuis, un indice de durabilité prend progressivement le relais sur certaines familles. Pour un marchand PrestaShop, ces textes se traduisent par une obligation concrète : afficher une note, dans un format imposé, à un endroit précis.
Le manquement se constate en une seconde sur une fiche produit, ce qui en fait un point de contrôle facile pour l'administration.
## Qui est concerné
L'obligation porte sur des catégories définies par décret, pas sur des univers commerciaux. Elle vise notamment les smartphones, les ordinateurs portables, les téléviseurs, les lave-linge, les tondeuses à gazon électriques, les lave-vaisselle, les nettoyeurs haute pression et les aspirateurs.
Trois précisions comptent. L'obligation s'applique à tout vendeur, y compris un revendeur qui n'a pas fabriqué le produit. Elle s'applique en ligne comme en magasin. Et la note n'est pas à calculer par vos soins : elle est établie par le fabricant selon une grille réglementaire, et elle doit vous être transmise avec le détail des critères.
Si un fournisseur ne vous fournit pas cette note, c'est un problème à régler avec lui avant la mise en vente, pas un motif d'exonération.
## Le format d'affichage
C'est là que les implémentations dérapent. La note ne se résume pas à un chiffre écrit dans la description.
- **Une note sur 10, avec une décimale.** « 7,8 » et non « 7,8/10 arrondi à 8 ».
- **Un pictogramme réglementaire**, dont la couleur varie selon la tranche de note, du rouge au vert.
- **Une présentation à proximité du prix**, dans le même champ visuel, lisible sans avoir à dérouler la page ni à ouvrir un onglet.
- **Le détail des sous-critères** accessible au consommateur : documentation, démontabilité, disponibilité des pièces, prix des pièces, et un critère spécifique à la catégorie.
Le détail peut se trouver derrière un lien ou un onglet, mais la note et le pictogramme doivent être visibles immédiatement.
## Où l'afficher dans PrestaShop
La fiche produit est l'emplacement obligatoire. Concrètement, cela suppose d'accrocher l'affichage à proximité du bloc de prix, ce qui dépend de votre thème.
Sur les pages de catégorie, l'affichage n'est pas exigé de la même façon, mais il est recommandé : un client qui compare deux références dans une liste apprécie de voir l'écart sans ouvrir les deux fiches. C'est aussi un argument commercial quand vos produits sont bien notés.
Deux points techniques à ne pas manquer. La note doit suivre la déclinaison quand elle varie d'une version à l'autre, ce qui est rare mais existe. Et elle doit apparaître sur le récapitulatif de commande ainsi que sur la facture pour les catégories où c'est requis, ce qui suppose que la donnée soit portée par la ligne de commande et pas seulement par la fiche.
## Stocker la donnée proprement
Le réflexe consistant à écrire la note dans la description du produit est une fausse bonne idée. Trois raisons.
Vous ne pouvez pas lister les produits dont la note est manquante, donc pas contrôler votre conformité. Vous ne pouvez pas modifier le format d'affichage sans reprendre chaque fiche. Et la donnée n'est pas exportable vers vos flux, alors que les comparateurs et places de marché la demandent de plus en plus.
La note doit être une caractéristique structurée du produit, au même titre que le poids, avec un champ par sous-critère.
## Sanctions et contrôles
Le défaut d'affichage relève des pratiques commerciales, avec une amende administrative pouvant atteindre 3 000 euros pour une personne physique et 15 000 euros pour une personne morale. Les contrôles de la répression des fraudes portent régulièrement sur ce point, et ils sont simples à mener : il suffit d'ouvrir quelques fiches.
L'affichage d'une note erronée est traité plus sévèrement que l'absence d'affichage, puisqu'il s'agit alors d'une information trompeuse. En cas de doute sur une note transmise par un fournisseur, mieux vaut la vérifier que la publier.
## L'indice de durabilité
Un second indice, plus large, prend le relais sur certaines catégories. Il intègre la réparabilité mais y ajoute la fiabilité, la robustesse et l'évolutivité du produit. Les téléviseurs et les lave-linge sont concernés en premier, d'autres familles suivront.
Pour un marchand, la conséquence pratique est qu'un même catalogue peut porter les deux indices selon les produits, avec des pictogrammes différents. Votre implémentation doit donc gérer les deux formats en parallèle plutôt que de supposer un affichage unique.
## Mettre en place l'affichage
Le traite ce besoin sur PrestaShop 8 et 9 : champs structurés par produit et par sous-critère, pictogramme réglementaire coloré selon la note, affichage à proximité du prix sur la fiche et en option dans les listings, et détection des produits concernés dont la note est manquante.
---
### Google Shopping et Merchant Center 2026 sur PrestaShop : flux produit, GTIN, Performance Max
_Source :_ — _publié_ 2026-08-23
> Google Shopping en 2026 : 18 % du CA quand le flux est bien fait, 3 % par défaut. L'écart se joue sur trois niveaux : qualité du flux (attributs requis, GTIN, identifiants), stratégie de campagne (Performance Max vs Standard), conformité Merchant Center (Omnibus, retour, livraison). Le guide complet d'un canal d'acquisition mal exploité sur PrestaShop.
## Google Shopping en 2026 : la couche d'acquisition la plus mal exploitée par les boutiques PrestaShop
Sur les boutiques PrestaShop mid-market que nous auditons, Google Shopping représente en moyenne 18 % du chiffre d'affaires acquis. Quand le flux est bien fait. Quand il ne l'est pas — et c'est la situation par défaut — c'est 3 % ou moins, avec un coût d'acquisition qui s'envole et des produits désapprouvés par Merchant Center sans qu'on s'en aperçoive.
L'écart se joue à trois niveaux : la qualité du flux (attributs requis, GTIN, identifiants uniques), la stratégie de campagne (Performance Max vs Standard Shopping), et la conformité Merchant Center (politiques 2024-2026, Comparison Shopping Services, prix de référence). Les trois sont des sujets distincts et techniques. Cet article les couvre dans l'ordre où ils apparaissent dans le pipeline d'un marchand qui démarre ou refond son canal Shopping en 2026.
## Ce qui a changé chez Merchant Center en 2024-2026
Trois évolutions majeures redéfinissent le terrain de jeu :
### Merchant Center Next remplace l'ancienne interface
Depuis 2024, Google a migré tous les comptes vers _Merchant Center Next_ — une refonte qui aplatit la hiérarchie, simplifie la création de flux et impose plus strictement les politiques. Conséquence pratique : des flux qui passaient en silence il y a 18 mois sont aujourd'hui désapprouvés en bloc, notamment sur l'absence de `shipping` et de `tax` pour les marchands non-EU.
### La fin du repérage des Comparison Shopping Services côté UE
Suite à la décision européenne et à ses ajustements 2023-2024, les marchands UE peuvent passer par Google directement ou via un CSS partenaire avec un rabais effectif de 20 % sur le CPC. Sur des budgets Shopping supérieurs à 5 000 €/mois, le passage par un CSS partenaire (Adwise, KelKoo Group, Productsup, etc.) est rentable. C'est une optimisation qui ne coûte rien à mettre en place mais que 80 % des marchands PrestaShop n'activent pas.
### Les attributs de retour et livraison sont devenus quasi-obligatoires
Depuis fin 2024, Google exige `shipping` et `return_policy` explicites sur la grande majorité des fiches Shopping. Sans cela, les annonces tournent mais avec une visibilité dégradée et un Quality Score en baisse. C'est aligné avec [les propriétés Schema.org Product 2026 (`hasMerchantReturnPolicy`, `shippingDetails`)](https://www.datafirefly.com/2026/07/20/schema-org-product-2026-hasmerchantreturnpolicy-shippingdetails-prestashop-woocommerce/) que Google a déjà imposées sur les rich results.
## Anatomie d'un flux produit conforme en 2026
Le flux Google Shopping est un fichier (XML, CSV, ou via Content API) qui décrit chaque produit pour Google. Vingt-cinq attributs sont possibles, dix sont obligatoires, et leur traitement correct fait la différence entre un compte Merchant Center sain et un compte sous warning permanent.
### Les dix attributs obligatoires — et les pièges sur PrestaShop
AttributSource PrestaShopPiège classique`id``id_product` + déclinaisonsRéutilisation d'ID après suppression : Google bloque pour duplication`title``name` + attributsLimite 150 caractères, mais l'idéal est 70-90 ; format : _Marque + Nom + Variante + Taille_`description``description_short` ou `description`HTML toléré mais nettoyé ; 5000 caractères max ; pas d'emoji ni de tout en majuscules`link`URL canonique de la ficheDoit pointer sur la déclinaison exacte, pas sur le produit parent`image_link`Image principale800×800 px minimum, fond uni recommandé, pas de filigrane`availability`Stock`in_stock` / `out_of_stock` / `preorder` / `backorder` — pas de valeurs custom`price`Prix TTCDoit matcher exactement le prix affiché sur la fiche, avec devise (ex. `49.00 EUR`)`brand`MarqueObligatoire si la marque existe ; `generic` si vraiment sans marque`gtin`EAN/UPC/ISBNValidation par check digit ; 8/12/13/14 chiffres ; ISBN-10 pas accepté, convertir en EAN-13`mpn`Référence fabricantObligatoire si pas de GTIN ; sinon optionnel mais améliore le matching
### Les attributs « optionnels mais critiques »
Quatre attributs ne sont pas marqués obligatoires mais leur absence dégrade fortement la performance :
- `shipping` : tableau de tarifs livraison par pays/région. Sans cela, Google applique des règles par défaut souvent fausses. À renseigner finement, surtout pour les boutiques multi-pays.
- `tax` : taxe applicable. Obligatoire pour les marchands US. Pour l'UE, le prix TTC est dans `price` et la TVA est implicite mais peut être déclarée.
- `google_product_category` : catégorie Google (3 à 5 niveaux). Sans elle, Google devine — souvent mal. À mapper depuis la taxonomie officielle Google (5 600 catégories).
- `product_type` : votre propre taxonomie, utile pour la segmentation des campagnes.
### Variantes et déclinaisons : la complexité PrestaShop
Sur PrestaShop, une fiche produit avec déclinaisons (taille × couleur) est un produit avec plusieurs `id_product_attribute`. Sur Google Shopping, chaque déclinaison doit être une ligne distincte du flux, avec :
- `id` unique par déclinaison (typiquement `{id_product}-{id_product_attribute}`).
- `item_group_id` commun à toutes les déclinaisons du même produit parent (typiquement `id_product`). C'est ce qui permet à Google de grouper les variantes dans l'interface acheteur.
- Attributs de variation : `color`, `size`, `material`, `pattern`, `gender`, `age_group` — selon la catégorie.
- GTIN par déclinaison (souvent un EAN différent par taille ou couleur).
- Stock par déclinaison.
L'erreur la plus fréquente : envoyer une seule ligne par produit parent avec un prix moyen et un stock agrégé. Google bloque immédiatement. Le [module Google Shopping PrestaShop](https://www.datafirefly.com/product/module-google-shopping-prestashop/) gère cette explosion par déclinaison nativement, avec mapping des attributs PrestaShop vers les attributs Google.
## GTIN : la friction n°1 et la solution
Le GTIN (Global Trade Item Number) est l'identifiant universel d'un produit. EAN-13 en Europe, UPC-A aux US, ISBN pour les livres. Google demande le GTIN pour tous les produits qui en ont un nativement (marques connues, produits manufacturés). Pour les produits sans GTIN (création artisanale, marque propre exclusive, services), il faut explicitement marquer `identifier_exists: false`.
Deux pièges fréquents :
### 1. Les EAN-13 invalides
Le treizième chiffre est un check digit, calculé sur les douze premiers selon l'algorithme Modulo 10. Beaucoup de boutiques importent des références fabricant avec des EAN tronqués ou inventés. Google les rejette en masse. La validation devrait être faite au moment de l'import, pas découverte trois semaines plus tard quand Merchant Center désapprouve 800 fiches.
### 2. Le GTIN partagé entre déclinaisons
Erreur classique sur PrestaShop : l'EAN est stocké sur le produit parent (`ps_product.ean13`) au lieu de la déclinaison (`ps_product_attribute.ean13`). Résultat : toutes les variantes ont le même GTIN, Google détecte la duplication et désapprouve.
Le bon pattern : stocker l'EAN au niveau de la déclinaison quand elle a sa propre référence (cas typique : tailles différentes du même modèle), et au niveau du produit parent uniquement pour les fiches mono-déclinaison.
## Performance Max vs Standard Shopping en 2026
Depuis 2022, Google pousse Performance Max (PMax) comme campagne par défaut. C'est une campagne automatisée qui combine Shopping, Display, YouTube, Discover et Search dans une seule logique d'optimisation. L'algorithme décide où placer les annonces et à qui. L'annonceur fournit les _asset groups_ (textes, images, signaux d'audience) et le budget.
### Quand PMax est rentable
- Catalogue large (1 000+ références) avec une couverture catégorielle variée.
- Données de conversion solides (50+ conversions / 30 jours par campagne, idéalement 100+).
- Marges qui supportent un CPA optimisé par l'algorithme (entre +15 et +30 % de CPA vs Standard, mais volume × 2 à × 5).
- Capacité à analyser les segments via les rapports d'_asset groups_ et de signaux d'audience (rapports limités mais en amélioration depuis 2024).
### Quand Standard Shopping reste préférable
- Catalogue spécialisé (moins de 200 références) où le contrôle granulaire par groupe de produits est critique.
- Marges serrées qui exigent un CPA strict et un ROAS stable.
- Catégories régulées (CBD, vape, certains compléments) où PMax peut élargir le ciblage de façon non conforme.
- Phase d'apprentissage : il vaut mieux structurer en Standard Shopping pendant 3 mois pour mesurer la performance par segment, avant de passer en PMax avec ces apprentissages.
### La stack hybride 2026
Le pattern qui marche aujourd'hui : Standard Shopping sur le top 20 % du catalogue qui fait 80 % du CA, PMax sur la longue traîne. Cela combine le contrôle (top produits stratégiques) et l'automatisation à l'échelle (longue traîne où le coût d'optimisation manuel n'est pas rentable).
## L'export du flux PrestaShop : trois architectures
### Architecture 1 — Flux statique XML/CSV régénéré
Un cron PHP (toutes les heures, ou toutes les nuits selon le rythme du catalogue) régénère un fichier XML ou CSV exposé à une URL fixe. Merchant Center pull ce fichier à fréquence configurée. Simple, robuste, mais latence de plusieurs heures entre un changement et son reflet dans Shopping.
### Architecture 2 — Content API push
Le module pousse les changements en temps réel via la Google Content API. Idéal pour les boutiques où les prix bougent fréquemment (flash sales, dynamic pricing) ou pour les inventaires limités. Plus complexe à implémenter, exige un quota Content API et une gestion fine des erreurs.
### Architecture 3 — Feed temps réel via Merchant Center Next
Depuis 2024, Merchant Center Next supporte les _real-time inventory updates_ pour les attributs critiques (prix, stock, disponibilité). C'est un endpoint dédié, indépendant du flux principal. Le pattern recommandé en 2026 est de combiner : un flux statique pour les données stables (titre, image, description) et un push temps réel pour prix et stock.
Le [module DataFirefly](https://www.datafirefly.com/product/module-google-shopping-prestashop/) implémente l'architecture statique avec une option de push prix/stock — couvrant 95 % des cas marchands sans complexité d'API gateway.
## Conformité Merchant Center : les politiques 2024-2026 qui désapprouvent
Quatre politiques sont à l'origine de 80 % des désapprobations en 2026 :
### 1. Prix de référence — directive Omnibus et politique Google alignée
Si vous affichez un prix barré (« 99 € au lieu de 149 € »), le prix de référence doit être conforme à la [directive Omnibus](https://www.datafirefly.com/2026/06/22/directive-omnibus-prix-reference-promotions-prestashop-2026/) : prix le plus bas pratiqué les 30 derniers jours. Google a aligné sa politique : un prix de référence non conforme = désapprobation, et c'est tracé sur tout le compte.
### 2. Produits restreints et interdits
Tabac, armes, contenus pour adultes, médicaments sur ordonnance : interdits. Compléments alimentaires, vape (sans nicotine), CBD : restreints, avec règles par pays. La désapprobation d'un seul produit restreint peut entraîner une suspension de compte si répétée — toujours filtrer côté flux PrestaShop pour exclure ces catégories de l'export.
### 3. Disponibilité incohérente
Le flux dit `in_stock`, la fiche affiche « Rupture de stock » ou un bouton désactivé. Google compare et désapprouve. La solution : synchroniser le flux avec le stock réel par déclinaison, avec un seuil (par exemple `availability = out_of_stock` si `quantity ≤ 0` et `allow_oosp = false`).
### 4. Politique de retour et livraison non déclarée
Depuis 2025, Google demande explicitement les politiques de retour et de livraison. Soit via les paramètres compte Merchant Center (politiques globales par pays), soit via les attributs `shipping` et `return_policy` dans le flux. Sans cela : warning permanent et dégradation du Quality Score.
## Mesurer la performance — au-delà du ROAS Merchant Center
Le ROAS affiché par Google Ads est la métrique de surface. Pour piloter correctement, trois autres lectures :
- **ROAS net** = (CA brut × taux de marge) / coût pub. Le ROAS Google ne tient pas compte de la marge produit. Un ROAS de 8 sur des produits à 15 % de marge est moins rentable qu'un ROAS de 4 sur des produits à 45 % de marge.
- **Incrementality** : combien de ces ventes auraient eu lieu sans Shopping (via SEO organique, retour de marque, autre canal) ? Test : pauser PMax pendant 14 jours sur un segment et mesurer le delta CA. Difficile à faire proprement, mais critique pour les budgets supérieurs à 20 K€/mois.
- **Coût d'acquisition new vs returning**. Shopping convertit massivement sur new (acquisition). Pour mesurer le LTV, croiser avec le CRM/back-office PrestaShop sur 6 à 12 mois.
L'[implémentation du server-side tracking GA4](https://www.datafirefly.com/2026/08/13/server-side-tracking-ga4-prestashop-ios-17-consent-mode-2026/) est devenue indispensable en 2026 pour fiabiliser ces mesures, avec l'érosion des cookies tiers et le Consent Mode v2.
## Maillage avec les autres signaux SEO/AEO
Google Shopping ne vit pas isolé. Les agents IA — Google AI Overviews, ChatGPT Shopping, Perplexity — lisent à la fois le flux Shopping (via Merchant Center API), les données structurées Schema.org de la fiche, et le contenu sémantique du site. Trois optimisations qui se renforcent mutuellement :
- [Le fichier llms.txt](https://www.datafirefly.com/product/llms-txt-prestashop-seo-ia-chatgpt/) qui sert d'index pour les LLM.
- Schema.org Product complet (avec `hasMerchantReturnPolicy`, `shippingDetails`, `aggregateRating`) pour le matching organique.
- Flux Shopping conforme avec attributs riches (GTIN, brand, gender, material, age_group).
Sur les boutiques qui investissent les trois, on observe une corrélation forte entre la qualité du flux Shopping et les citations IA dans les [agents de shopping IA](https://www.datafirefly.com/2026/08/09/ai-shopping-agents-operator-claude-perplexity-prestashop-2026/).
## Budget réaliste pour démarrer en 2026
Pour une boutique PrestaShop mid-market qui lance Google Shopping :
- **Module de flux** : [149 € licence perpétuelle](https://www.datafirefly.com/product/module-google-shopping-prestashop/), ou 30 à 80 €/mois pour les alternatives en SaaS.
- **Setup initial** : 1 à 3 jours de travail (mapping taxonomie Google, validation GTIN, paramétrage shipping/tax). Le module DataFirefly automatise 80 % de ce setup.
- **Budget Ads** : commencer à 30-50 €/jour, monter à 200-500 €/jour à mesure que le ROAS se stabilise. Le sweet spot d'apprentissage PMax est autour de 50 conversions / 30 jours.
- **CSS partenaire** : −20 % sur CPC effectif, gratuit à activer après ouverture du compte. Rentable dès 5 000 €/mois de budget.
Avec ce setup, le ROAS cible 12 mois est de 4 à 8 sur des marges 30-40 %, avec un payback de la mise en place sur les deux premiers mois.
## FAQ
### Faut-il un compte Google Ads pour utiliser Merchant Center ?
Pour faire des annonces Shopping payantes, oui. Mais Merchant Center seul permet aussi les _free listings_ (annonces gratuites dans l'onglet Shopping et sur Search). Ces listings ne convertissent pas autant que les payants mais c'est un trafic gratuit qu'aucune boutique ne devrait laisser sur la table.
### Peut-on faire des annonces Shopping en B2B ?
Officiellement, Shopping est destiné au B2C. Mais des boutiques [B2B sur PrestaShop](https://www.datafirefly.com/2026/05/25/b2b-prestashop-comptes-pros-devis-paiement-differe-kyb-2026/) exposent leur catalogue public en Shopping pour générer des leads — ça fonctionne tant que la fiche permet l'achat direct. Les prix doivent être TTC affichés (ou avec mention « hors taxes ») ; les boutiques 100 % HT avec validation pro ne sont pas éligibles.
### Qu'est-ce qui cause la suspension d'un compte Merchant Center ?
Trois causes principales : multiplication des désapprobations sans correction (Google considère que vous ne respectez pas la politique), création répétée de comptes pour contourner une suspension précédente (la suspension est tracée par domaine, IBAN, identité fiscale), ou présence d'un produit interdit (armes, médicaments sur ordonnance). En cas de suspension, la procédure d'appel demande un correctif documenté, pas une excuse.
### Comment gérer les promotions et soldes via Shopping ?
Google Merchant Promotions permet d'attacher des codes promo aux annonces. Le code doit être valide, applicable au panier minimum, et conforme à la directive Omnibus pour le prix barré. Pour les soldes calendaires (Black Friday, soldes d'été), on prépare les annonces 7 à 14 jours en amont via le flux, et on planifie la campagne PMax avec un budget × 2 ou × 3 sur la période. Voir aussi [notre check-list Black Friday](https://www.datafirefly.com/2026/08/16/black-friday-2026-prestashop-infrastructure-calendrier-checklist-j30/).
### Le flux doit-il être bilingue/multi-pays ?
Oui, mais avec un flux distinct par pays/langue ciblé. Un même produit en France et en Espagne se déclare via deux entrées dans Merchant Center : une avec `language=fr`, `feed_country=FR`, prix en EUR, livraison FR ; une avec `language=es`, `feed_country=ES`, prix en EUR (ou différent si la stratégie le justifie), livraison ES. Ne jamais déclarer un produit en plusieurs pays avec un même flux : ça casse le matching et désapprouve.
## En synthèse
Google Shopping en 2026 n'est pas un canal qu'on active en 30 minutes. C'est une infrastructure produit-data qui exige rigueur sur les GTIN, propreté sur le mapping de taxonomie, conformité réglementaire (Omnibus, retour, livraison) et alignement avec les signaux SEO/AEO du reste du site. Pour les boutiques PrestaShop qui font cet investissement, c'est typiquement 15 à 25 % du CA acquis avec un ROAS de 4 à 8 et un payback de la mise en place sur 60 jours.
Le [module Google Shopping PrestaShop de DataFirefly](https://www.datafirefly.com/product/module-google-shopping-prestashop/) automatise les éléments les plus chronophages : extraction par déclinaison, validation GTIN, mapping taxonomie Google, export XML/CSV, intégration Content API. Pour les boutiques qui souhaitent aller plus loin, [l'audit complet du canal Shopping](https://www.datafirefly.com/expertise/audit-prestashop/) identifie les fuites de conformité et les gains rapides.
À ne pas oublier en parallèle : [l'intégration Google Search Console](https://www.datafirefly.com/product/dfsearchconsole-google-search-console-prestashop/) pour suivre les performances organiques en parallèle du payant, et [le maillage interne sémantique](https://www.datafirefly.com/product/datafirefly-maillage-interne-semantique-ia-prestashop/) pour renforcer l'autorité topique du catalogue indépendamment du budget Ads.
---
### Comment ajouter automatiquement les balises hreflang sur PrestaShop 8 et 9 ?
_Source :_ — _publié_ 2026-08-23
> Hreflang ne fait pas monter une page, il évite que vos versions se concurrencent et sert la bonne au bon visiteur. Les trois règles absolues, le choix entre langue et langue plus pays, et les cinq erreurs qui annulent tout le dispositif.
Sur une boutique multilingue, la même fiche produit existe en cinq versions. Sans indication, un moteur de recherche voit cinq pages proches, en choisit une par requête, et peut très bien servir la version espagnole à un visiteur allemand. Les balises hreflang existent pour éviter cela.
Elles sont mal comprises, souvent mal posées, et PrestaShop ne les génère pas nativement de façon complète.
## Ce que hreflang fait, et ne fait pas
Une précision utile avant tout paramétrage. Hreflang ne fait pas monter une page dans les résultats. C'est un signal de correspondance, pas de qualité.
Ce qu'il apporte concrètement : il indique quelle version servir selon la langue et la région du visiteur, et il regroupe les versions entre elles pour qu'elles ne se concurrencent pas. Une page allemande bien positionnée en Allemagne conserve son classement, et le visiteur français reçoit la version française plutôt que la même page en allemand.
Sur un site où toutes les versions sont dans la même langue, français de France et français de Belgique par exemple, hreflang est le seul moyen de faire comprendre à quel public chacune s'adresse.
## Les trois règles absolues
Une implémentation hreflang est valide ou ne l'est pas. Il n'y a pas de demi-mesure, et trois règles conditionnent tout.
1. **La réciprocité.** Si la page française pointe vers la page allemande, la page allemande doit pointer vers la page française. Un lien non réciproque est ignoré. C'est la première cause d'échec.
2. **L'auto-référence.** Chaque page doit se déclarer elle-même dans la liste. Une page française qui ne liste que l'allemand et l'espagnol est incomplète.
3. **La cohérence avec la balise canonique.** Chaque page doit avoir une canonique pointant vers elle-même. Une canonique qui pointe vers une autre version annule tout le dispositif, puisqu'elle dit au moteur que cette page n'est pas la bonne.
Ajoutons une contrainte de format : le code langue suit la norme ISO 639-1, le code pays facultatif la norme ISO 3166-1. « fr » est valide, « fr-FR » aussi, « fr-fr » est toléré, mais « fr-EU » ne l'est pas, l'Union européenne n'étant pas un pays.
## Langue ou langue plus pays
Choix structurant qui dépend de votre modèle.
Si vous vendez le même catalogue aux mêmes conditions à tous les francophones, un simple « fr » suffit. Si vous avez une boutique française et une boutique belge avec des prix et des frais de port différents, il faut « fr-FR » et « fr-BE ».
Le second cas est plus puissant et plus fragile : il multiplie le nombre de relations à maintenir. Trois langues et quatre pays donnent douze versions, donc cent trente-deux relations réciproques à tenir correctes.
## Où poser les balises
Trois emplacements possibles, un seul suffit et il ne faut pas les mélanger.
**Dans l'en-tête HTML de la page.** Le plus courant, le plus simple à contrôler, et le plus lourd si vous avez douze versions : douze lignes supplémentaires sur chaque page.
**Dans le sitemap XML.** Plus léger côté page, et pratique sur un grand nombre de versions. En contrepartie, une erreur est moins visible et le fichier devient volumineux.
**Dans les en-têtes HTTP.** Réservé aux fichiers non HTML, typiquement des PDF multilingues.
## La balise x-default
Elle désigne la page à servir quand aucune version ne correspond à la langue du visiteur. Un visiteur japonais sur un site français, anglais et allemand doit atterrir quelque part.
Deux usages corrects : pointer vers la version anglaise, ou vers une page de sélection de pays. Un usage incorrect et fréquent : pointer vers la version française en la déclarant aussi comme « fr ». La page peut cumuler les deux rôles, mais la déclaration doit être explicite.
## Les erreurs les plus fréquentes
- **Hreflang vers une page non traduite.** Une fiche existe dans le sélecteur de langue mais son contenu est resté en français. Le moteur constate que les deux pages sont identiques et cesse de faire confiance à l'ensemble des déclarations.
- **Hreflang vers une redirection.** L'URL déclarée renvoie un code 301. Le lien est ignoré.
- **Hreflang vers une page bloquée.** L'URL est interdite dans le fichier robots, ou porte une balise noindex. Contradiction directe.
- **Déclaration partielle.** Seules les pages d'accueil sont couvertes, et pas les fiches ni les catégories. C'est le cas le plus répandu, et il ne sert à peu près à rien.
- **Produits désactivés dans une langue.** Une référence vendue en France mais pas en Espagne casse la réciprocité si la déclaration continue de pointer vers une page inexistante.
## Le cas PrestaShop
Deux architectures coexistent et n'appellent pas le même traitement.
En **multilingue simple**, une boutique, plusieurs langues, les URL se distinguent par un préfixe de langue. Les relations sont faciles à établir puisque chaque produit possède un identifiant unique commun à toutes ses traductions.
En **multiboutique**, une boutique par pays avec des domaines distincts, la correspondance n'est plus automatique. Un produit peut porter des identifiants différents selon les boutiques, ou exister dans l'une et pas dans l'autre. C'est là que la génération manuelle devient impraticable.
## Contrôler
Trois vérifications, dans cet ordre. Le code source d'une fiche produit, pour voir les balises réellement présentes. Le rapport de ciblage international de la Search Console, qui remonte les erreurs de réciprocité et les codes invalides. Et un contrôle par échantillon sur une vingtaine de pages tirées au hasard, parce que les erreurs se concentrent rarement sur la page d'accueil.
Le génère ces balises automatiquement sur PrestaShop 8 et 9 : couverture de toutes les pages et pas seulement de l'accueil, gestion du multiboutique et des correspondances entre domaines, x-default paramétrable et exclusion des produits non disponibles dans une version.
---
### Ajouter une demande de devis sur PrestaShop sans basculer en mode B2B complet
_Source :_ — _publié_ 2026-08-22
> Activer le mode B2B de PrestaShop transforme la boutique pour tout le monde afin de servir une minorité. L'approche ciblée : garder le B2C et ajouter un canal devis conditionnel, avec les quatre bons déclencheurs et un workflow interne qui tient.
Une boutique qui vend en B2C reçoit régulièrement des demandes professionnelles : une collectivité qui veut trente unités, un revendeur qui demande un tarif, une entreprise qui a besoin d'un devis pour son service achats. Le réflexe consiste à activer le mode B2B de PrestaShop. C'est presque toujours une erreur.
## Ce que « passer en B2B » fait réellement
L'option se trouve dans **Paramètres de la boutique > Clients**, et elle transforme la boutique bien plus profondément que son intitulé ne le suggère.
- Les prix s'affichent hors taxes par défaut, ce qui déroute immédiatement un particulier.
- Le formulaire d'inscription se charge de champs professionnels : raison sociale, numéro SIRET, numéro de TVA, effectif.
- Les nouveaux comptes peuvent nécessiter une validation manuelle avant de pouvoir commander.
- Des notions de remise permanente et d'encours autorisé apparaissent au niveau du client.
Sur une boutique dont 95 % du chiffre d'affaires est B2C, ce basculement dégrade le parcours de la quasi-totalité des visiteurs pour servir une minorité. Le remède est plus coûteux que le mal.
## L'approche ciblée
La boutique reste en B2C. Vous ajoutez un canal parallèle : un bouton de demande de devis, visible uniquement dans les situations où il a du sens, et qui déclenche un traitement humain.
Rien ne change pour le particulier qui achète une unité. Le professionnel qui a un besoin spécifique trouve un chemin adapté sans que vous ayez transformé votre tunnel.
## Où placer le bouton
Quatre déclencheurs, à combiner selon votre catalogue.
1. **Au-delà d'un seuil de quantité.** Le sélecteur atteint dix unités, un message propose une demande de devis pour un tarif adapté. C'est le déclencheur le plus naturel : il apparaît au moment exact où le client formule un besoin de volume.
2. **Sur une sélection de produits.** Les références vendues au professionnel, les gros équipements, les produits sur commande. Le bouton coexiste avec l'ajout au panier.
3. **Sur les produits sans prix affiché.** Pour du sur-mesure ou des équipements dont le prix dépend de l'installation, le bouton remplace l'achat direct.
4. **Depuis le panier.** Un lien discret « Vous êtes un professionnel ? Demandez un devis pour ce panier » transforme une sélection existante en demande, sans que le client ait à tout ressaisir.
Le quatrième est le plus productif et le moins souvent implémenté.
## Ce qu'il ne faut pas faire
Remplacer le bouton d'achat par un bouton de devis sur l'ensemble du catalogue. Vous perdez alors toutes les ventes directes, y compris celles de professionnels pressés qui auraient payé le prix affiché sans négocier.
La règle : le devis s'ajoute, il ne remplace pas. Les deux boutons coexistent, avec une hiérarchie visuelle claire en faveur de l'achat immédiat.
## Le formulaire
Trois champs suffisent pour ouvrir la discussion : le nom de la société, un email et un téléphone. Ajoutez un champ libre pour le besoin, et éventuellement un champ de quantité prérempli.
Le SIRET et le numéro de TVA intracommunautaire ne servent qu'au moment de la facturation. Les demander à l'étape de la demande fait chuter le taux de soumission sans rien apporter : vous les collecterez à la conversion, quand le client sera engagé.
Une pièce jointe est utile sur les marchés publics et les appels d'offres, où le client transmet un cahier des charges. Limitez les formats et la taille, et scannez ce qui arrive.
## Le workflow interne
Une demande de devis qui atterrit dans une boîte email partagée se perd. Quatre éléments minimum doivent exister.
**Une file de demandes** visible dans le back-office, avec un statut par demande. **Un responsable désigné** par demande, même si vous êtes seul : cela force à savoir qui doit agir. **Un délai cible** de première réponse, vingt-quatre heures ouvrées est un repère raisonnable, car le client a souvent sollicité trois fournisseurs le même jour. **Un historique** conservé par client, qui permet de retrouver le tarif accordé la fois précédente.
## La relance
Une demande de devis sans réponse du client n'est pas un refus. Deux relances suffisent : une à cinq jours, une à quinze. La première rappelle simplement le devis et propose de répondre aux questions. La seconde mentionne l'échéance de validité, ce qui donne une raison objective de reprendre contact.
Au-delà, classez la demande sans la supprimer. Une demande de l'an dernier est un contact qualifié pour la campagne suivante.
## Une fois le devis accepté
La suite du parcours, états du devis, durée de validité, acompte et conversion en commande, se traite avec la même rigueur. C'est là que se perdent les affaires déjà gagnées, faute d'un lien maintenu entre le devis et la commande finale.
Le met en place ce canal parallèle sur PrestaShop 8 et 9, sans activer le mode B2B natif : bouton conditionnel par produit, catégorie ou quantité, demande depuis le panier, file de traitement dans le back-office et conversion en commande une fois le devis accepté.
---
### Maillage interne sémantique par IA sur PrestaShop : transformer un catalogue en graphe de pertinence en 2026
_Source :_ — _publié_ 2026-08-22
> Un catalogue PrestaShop sans maillage interne, c'est une bibliothèque sans index. Google et les agents IA voient des îles, pas un graphe. Le maillage manuel ne tient pas à l'échelle au-delà de 200 fiches. L'IA, elle, calcule la similarité sémantique entre 5 000 entités en quelques minutes et propose les liens qui maximisent la pertinence. Méthode, coût réel, et les trois erreurs qui font perdre 30 % du trafic organique.
## Le maillage interne reste l'optimisation SEO la plus sous-investie en 2026
Sur 100 boutiques PrestaShop auditées en 2025, 78 ont moins de trois liens internes sortants par fiche produit. La moitié n'a aucun lien entre fiches produits de la même famille. Et pourtant, la documentation Google sur la _Search Quality_ est claire depuis 2019 : la structure du maillage interne est l'un des trois signaux les plus forts pour qu'un crawler comprenne l'autorité topique d'une page.
Pourquoi cet écart entre l'évidence théorique et la pratique ? Parce que le maillage manuel ne passe pas l'échelle. À 200 fiches produits, identifier les meilleurs liens prend déjà une journée. À 2 000 fiches en trois langues, c'est impossible à maintenir : chaque nouvelle référence devrait être croisée avec 5 999 autres entités pour décider où poser un lien.
L'IA change l'équation. Avec des embeddings sémantiques (OpenAI, Voyage AI, Cohere) et un calcul de similarité cosinus, on peut construire en quelques minutes la matrice complète de proximité entre toutes les entités d'un catalogue — produits, catégories, articles de blog, pages CMS — puis en déduire les liens les plus pertinents à poser. C'est ce que fait [le module de maillage interne sémantique IA pour PrestaShop](https://www.datafirefly.com/product/datafirefly-maillage-interne-semantique-ia-prestashop/) : 5 000 entités traitées en moins de dix minutes, 30 à 80 € de coût IA selon le fournisseur d'embeddings choisi.
## Ce qu'un crawler voit quand le maillage est absent
Trois pathologies typiques sur les boutiques PrestaShop sans maillage interne stratégique :
### 1. Les fiches produits orphelines
Une fiche n'est accessible que depuis la pagination de la catégorie ou le moteur de recherche interne. Google la trouve via le sitemap XML, mais elle reçoit zéro link juice. Sur une boutique mode de 1 200 références, on mesure régulièrement que 30 à 40 % des fiches ne sont pas indexées du tout — l'orphelinat tue la découverte autant que l'autorité.
### 2. Les silos étanches
Les catégories sont liées au menu et entre elles via le fil d'Ariane, mais aucun lien horizontal n'existe entre fiches de catégories différentes pourtant complémentaires. Un blouson en cuir n'est jamais lié au t-shirt blanc qu'on porte dessous, ni à la pochette qui complète la tenue. Le client navigue mais le crawler n'a pas d'arête pour propager la pertinence.
### 3. L'absence de pont blog ↔ catalogue
Le blog parle de tendances, conseils, comparatifs. Le catalogue vend les produits qui matérialisent ces contenus. Sans lien interne entre les deux, l'autorité éditoriale construite côté blog ne se transmet jamais aux fiches qui en bénéficieraient — et l'inverse, où une fiche populaire devrait remonter vers son article guide, ne se produit jamais.
## Le maillage sémantique : calculer la pertinence, pas la deviner
La méthode tient en cinq étapes que tout module sérieux automatise :
### Étape 1 — Extraction du corpus
On extrait pour chaque entité (produit, catégorie, article, page CMS) un bloc texte représentatif : titre, description courte, description longue, attributs, caractéristiques. Sur PrestaShop, c'est une jointure SQL sur `ps_product_lang`, `ps_category_lang`, `ps_cms_lang` et la table de blog si présente. Filtre langue par langue : pas de croisement français/anglais, le maillage est par défaut intra-langue.
### Étape 2 — Génération des embeddings
Chaque bloc texte est envoyé à un modèle d'embeddings : `text-embedding-3-small` chez OpenAI (1 536 dimensions, 0,02 $ par million de tokens), `voyage-3-lite` chez Voyage AI (512 dimensions, 0,02 $ par million de tokens, optimisé multilingue), ou `embed-multilingual-v3` chez Cohere. Un embedding est un vecteur numérique qui capture le sens du texte — deux textes proches en signification produisent des vecteurs proches dans l'espace vectoriel.
Sur 5 000 entités avec en moyenne 400 tokens chacune, on parle de 2 millions de tokens, soit environ 40 $ chez OpenAI ou Voyage. Coût unique : les embeddings sont stockés en base et ne sont régénérés que pour les nouvelles entités ou celles modifiées.
### Étape 3 — Calcul de similarité cosinus
Pour chaque paire d'entités, on calcule le cosinus de l'angle entre leurs deux vecteurs. Score entre 0 (orthogonal) et 1 (identique). Sur un catalogue de 5 000 entités, c'est une matrice 5 000 × 5 000, soit 25 millions de paires — calculées en moins d'une minute en mémoire avec NumPy ou directement en MySQL avec une fonction stockée.
### Étape 4 — Sélection des candidats avec seuils et règles
On garde les paires dont la similarité dépasse un seuil (typiquement 0,72 pour text-embedding-3-small), puis on applique des règles métier :
- Pas plus de 5 liens internes générés par entité source.
- Préférence pour les liens vers des entités de catégories différentes (sortir des silos).
- Préférence pour les liens article → produit et produit → article (faire le pont).
- Exclusion des entités déjà liées manuellement (on ne dédouble pas).
- Exclusion des produits hors stock, des articles en brouillon, des pages non publiées.
### Étape 5 — Génération des anchors et injection
Pour chaque lien retenu, l'IA génère un anchor text contextuel à partir du titre de la cible et de quelques mots-clés extraits. Pas de « cliquez ici », pas de « en savoir plus » : un anchor descriptif comme « guide complet du choix de matelas latex naturel » qui correspond au sémantique de la cible. L'injection se fait dans la description longue ou dans un bloc _« Articles connexes »_ en bas de fiche, selon l'option choisie.
## L'arithmétique du PageRank interne
Google ne publie plus le PageRank depuis 2016, mais le concept reste opérationnel dans l'algorithme. La règle simplifiée : chaque page distribue son autorité à ses liens sortants, divisée par leur nombre. Une page d'accueil avec 80 liens sortants distribue 1/80 de son autorité par lien. Une fiche produit avec 5 liens sortants distribue 1/5.
Conséquence pratique : **moins une page a de liens sortants, plus chaque lien est puissant**. C'est pourquoi le menu mega-menu surchargé est un anti-pattern SEO. C'est aussi pourquoi un maillage interne ciblé et limité (3 à 5 liens contextuels par page) bat un footer chargé de 80 liens.
Sur une boutique PrestaShop typique de 500 fiches produits, un maillage sémantique bien fait propage 12 à 18 % d'autorité supplémentaire vers les fiches longue traîne, ce qui se traduit empiriquement par +20 à +35 % de trafic organique sur ces fiches en 4 à 6 mois.
## Topic clusters et siloing : la couche au-dessus de la similarité
La similarité cosinus est un excellent point de départ, mais elle ne distingue pas un lien « pilier → satellite » d'un lien « satellite ↔ satellite ». Or pour le SEO, ces deux liens n'ont pas la même valeur :
- Lien **pilier → satellite** : la page pilier (ex. _« guide complet du sommeil »_) lie vers ses pages satellites (matelas mémoire, matelas latex, surmatelas). Distribue de l'autorité vers la longue traîne. À privilégier.
- Lien **satellite → pilier** : chaque satellite remonte vers le pilier. Concentre l'autorité sur le pilier, qui devient la page de référence sur le sujet. À systématiser.
- Lien **satellite ↔ satellite** : deux pages de longue traîne se lient mutuellement. Utile pour le crawl, faible pour l'autorité. À limiter.
Un module de maillage IA propose typiquement une option « priorité aux liens vers piliers », qui force un quota minimum de liens vers les pages identifiées comme piliers thématiques (souvent les catégories principales et les guides éditoriaux). C'est la couche métier qui transforme un calcul de similarité en stratégie de siloing.
## Coût IA réel et ROI
Sur une boutique mid-market de 2 000 produits en français :
- **Initialisation** : 800 000 tokens embeddings ≈ 16 $ (OpenAI _text-embedding-3-small_) ou 20 $ (Voyage AI). Plus génération des anchors : 200 000 tokens GPT-4o-mini ≈ 0,03 $ par lien × 6 000 liens ≈ 5 $. Total : ~25 $.
- **Maintenance mensuelle** : nouveaux produits + produits modifiés (typiquement 5 à 10 % du catalogue) ≈ 2 à 4 $ par mois.
- **Multilingue** : multiplier par le nombre de langues actives. Trois langues = ~75 $ initial + 9 $/mois.
Sur la même boutique, le ROI mesuré sur 6 mois (post-implémentation, vs baseline) tourne autour de +18 % de pages organiques actives en Search Console et +24 % de revenu organique sur les fiches longue traîne. Le payback du coût IA est inférieur à 30 jours.
## Les trois erreurs qui font perdre 30 % du trafic organique
### Erreur 1 — Le sur-maillage
Mettre 30 liens internes par fiche produit. Symptôme : Google diminue la valeur de chaque lien, le visiteur ne sait plus où cliquer, le taux de rebond monte. La règle empirique : 3 à 5 liens contextuels dans le corps + 4 à 6 liens dans un bloc dédié _« Vous aimerez aussi »_, séparés graphiquement et balisés différemment (un `nofollow` sur le bloc dédié peut même se justifier sur les très gros catalogues).
### Erreur 2 — Les anchors génériques ou suroptimisés
« Cliquez ici » ne dit rien à Google. « Meilleur matelas latex naturel pas cher livraison gratuite » est suroptimisé et déclenche une pénalité algorithmique. Le bon anchor est descriptif et naturel : « notre matelas latex naturel 160×200 » suffit. Une IA bien promptée génère ce type d'anchor par défaut.
### Erreur 3 — L'injection en footer ou sidebar globale
Les liens internes qui apparaissent sur toutes les pages (footer, sidebar) sont massivement dévalués par Google depuis 2022. Un lien dans le corps du contenu, contextuel à la page, vaut 5 à 10 fois plus qu'un lien sitewide. Le maillage IA doit s'injecter **dans** le contenu, pas _autour_.
## Intégration sur PrestaShop : les bons hooks
Sur PrestaShop 8 et 9, l'injection se fait via deux hooks :
- `displayProductAdditionalInfo` ou `displayFooterProduct` pour les fiches produits.
- `displayHome` ou un bloc CMS pour les pages éditoriales.
L'injection directe dans `description` via SQL est tentante mais déconseillée : elle pollue la donnée source et complique les migrations. Le pattern propre est un hook qui lit une table dédiée (par exemple `df_semantic_links`) et injecte les liens au render. Cela permet de regénérer le maillage sans toucher aux fiches.
Pour les multishops PrestaShop, attention à scoper la table par `id_shop` : un même produit peut avoir des liens internes différents selon la boutique (catalogue partiel, langue dominante, stratégie SEO par marché).
## Maillage IA et AEO : le bonus 2026
Les agents IA — ChatGPT Shopping, Perplexity, Claude, Google AI Overviews — consomment de plus en plus la structure du maillage interne pour reconstituer l'arbre de catégories et la relation entre entités. Un catalogue bien maillé est mieux compris par ces agents, ce qui se traduit par des citations plus fréquentes dans les réponses synthétiques.
C'est complémentaire d'autres signaux structurés : [l'optimisation AEO globale](https://www.datafirefly.com/2026/05/21/aeo-2026-optimiser-prestashop-8-chatgpt-perplexity-google-ai-overviews/), le fichier [llms.txt](https://www.datafirefly.com/product/llms-txt-prestashop-seo-ia-chatgpt/) qui sert d'index pour les LLM, et les [données structurées Schema.org Product 2026](https://www.datafirefly.com/2026/07/20/schema-org-product-2026-hasmerchantreturnpolicy-shippingdetails-prestashop-woocommerce/). Le maillage sémantique est le ciment qui relie tous ces signaux entre eux.
## Quand un module IA est pertinent — et quand il ne l'est pas
Le maillage manuel reste valable pour les très petits catalogues (moins de 100 fiches) et pour les boutiques mono-thématique très spécialisées où le contenu éditorial est limité. Pour tout le reste — catalogues mid-market 500-10 000 fiches, plusieurs langues, blog actif, mises à jour fréquentes — un module IA est le seul moyen de maintenir un maillage à jour sans y consacrer un mi-temps SEO.
Le calcul est simple : un mi-temps SEO interne, c'est 25 à 35 K€/an. Un module IA + coûts d'embeddings, c'est moins de 200 €/an. Le module ne remplace pas la stratégie SEO globale, mais il automatise la couche d'exécution la plus chronophage.
## FAQ : les questions qu'on me pose après chaque audit
### Faut-il regénérer tout le maillage à chaque modification de catalogue ?
Non. Seules les entités nouvelles ou modifiées doivent être ré-embeddées. La matrice de similarité est mise à jour de manière incrémentale (le coût d'embedding d'une nouvelle fiche est de quelques cents). Un cron hebdomadaire ou journalier suffit pour la plupart des boutiques.
### Peut-on faire du maillage sémantique multilingue (cross-language) ?
Techniquement oui, avec un modèle d'embeddings multilingue (Voyage `voyage-3`, Cohere `embed-multilingual-v3`). Mais c'est rarement souhaitable : l'expérience utilisateur d'un client français qui clique sur un lien et atterrit sur une page en allemand est mauvaise. Le maillage est par défaut intra-langue ; le pont multilingue est géré par `hreflang`.
### Les liens internes générés par IA sont-ils considérés comme du contenu généré par IA par Google ?
Non. Google s'intéresse au contenu généré par IA (paragraphes, descriptions), pas aux liens internes — qui sont du HTML, pas du texte sémantique nouveau. L'anchor généré peut être considéré comme du contenu, mais à raison de quelques mots descriptifs par lien, c'est en deçà du seuil de scrutiny.
### Quel impact sur le crawl budget ?
Positif. Un maillage bien fait réduit le nombre de niveaux de profondeur (depth) du site, ce qui permet à Googlebot de crawler plus de pages avec le même budget. Sur les sites où Search Console rapporte des pages « découvertes mais non indexées », un meilleur maillage est souvent la solution.
### Est-ce que ça remplace les backlinks externes ?
Non. Le maillage interne distribue l'autorité existante. Les backlinks externes apportent l'autorité initiale. Les deux travaillent ensemble : un site avec d'excellents backlinks mais un maillage interne pauvre gaspille son autorité ; un site avec un excellent maillage mais zéro backlink amplifie un signal très faible.
## En synthèse
Le maillage interne sémantique par IA n'est pas une nouveauté gadget — c'est la mise à l'échelle d'une bonne pratique SEO connue depuis quinze ans, désormais accessible à tout catalogue qui dépasse les 200 entités. Pour 25 $ d'initialisation et 3 $/mois, on récupère typiquement +20 à +35 % de trafic organique sur la longue traîne, avec un payback inférieur à 30 jours.
Les prérequis sont raisonnables : un module qui automatise les cinq étapes (extraction, embeddings, similarité, sélection, injection), une intégration via hooks propres (pas d'écrasement des descriptions sources), et un suivi mensuel dans Search Console pour mesurer le ROI réel.
Pour aller plus loin, le [module DataFirefly Maillage Interne Sémantique IA](https://www.datafirefly.com/product/datafirefly-maillage-interne-semantique-ia-prestashop/) implémente cette méthode sur PrestaShop 8 et 9 avec le choix du fournisseur d'embeddings (OpenAI, Voyage, Cohere), la configuration des règles métier, et le suivi des liens générés. Il s'intègre naturellement avec [une démarche d'audit SEO complet](https://www.datafirefly.com/expertise/audit-prestashop/) et avec [l'intégration Google Search Console](https://www.datafirefly.com/product/dfsearchconsole-google-search-console-prestashop/) pour mesurer l'impact dans la durée.
Pour les équipes qui souhaitent un accompagnement plus large, [notre expertise développeur PrestaShop](https://www.datafirefly.com/expertise/developpeur-prestashop/) couvre l'intégration sur-mesure, l'analyse de la matrice de pertinence et les stratégies de siloing avancées.
---
### Comment afficher les photos de vos clients sur les fiches produit PrestaShop ?
_Source :_ — _publié_ 2026-08-22
> Une photo client règle la question de la teinte réelle et de l'échelle mieux que n'importe quel descriptif. Comment collecter ces images, quelles autorisations obtenir, comment modérer et rattacher chaque photo au bon produit.
Une photo studio montre le produit. Une photo client montre le produit dans un salon éclairé au néon, porté par quelqu'un qui n'est pas mannequin, à côté d'objets du quotidien. La seconde répond à une question que la première élude : à quoi cela ressemble-t-il vraiment chez moi ?
C'est la raison pour laquelle une galerie de photos clients agit sur deux indicateurs à la fois, la conversion et le taux de retour.
## Pourquoi cela fonctionne
Trois mécanismes se cumulent, et ils sont différents de ceux d'un avis écrit.
**La réduction de l'incertitude.** Sur un vêtement, une couleur, un meuble, l'écart entre la photo catalogue et la réalité est la première cause d'abandon et de retour. Une photo prise en lumière naturelle par un client règle la question de la teinte réelle mieux que n'importe quel descriptif.
**L'échelle.** Un objet photographié sur fond blanc n'a pas de taille. Le même objet posé sur une table, tenu en main ou porté devient immédiatement dimensionnable.
**La preuve d'usage.** Une photo prouve que quelqu'un a acheté, reçu et utilisé le produit. C'est une garantie implicite que le texte d'un avis n'apporte pas au même degré.
## Collecter les photos
Trois sources, avec des rendements très différents.
1. **La demande post-achat**, couplée à la sollicitation d'avis. C'est la source la plus productive et la plus propre juridiquement, parce que le consentement se recueille au même moment. Ajoutez simplement un bouton d'ajout de photo au formulaire d'avis.
2. **Le mot-clé sur les réseaux sociaux.** Vous proposez un mot-clé de marque, les clients publient, vous importez. Volume élevé sur des produits visuels, mais la question des droits se complique.
3. **L'envoi direct** depuis une page dédiée, souvent associé à un jeu-concours. Efficace ponctuellement, peu productif en régime permanent.
Un incitatif modeste, un bon d'achat de quelques euros ou une participation à un tirage, multiplie le volume. Il doit être annoncé publiquement et ne pas être conditionné à une photo flatteuse.
## Le droit à l'image, en pratique
C'est le point où beaucoup de galeries se construisent sur du sable. Publier une photo prise par un client suppose deux autorisations distinctes.
**Les droits d'auteur sur la photo.** Le client est l'auteur de son cliché. Il doit vous céder le droit de le reproduire sur votre site, et vous devez préciser pour quelle durée et sur quels supports. Une case cochée au moment de l'envoi, renvoyant à des conditions lisibles, suffit, à condition qu'elle soit explicite.
**Le droit à l'image des personnes.** Si une personne est identifiable sur la photo, son autorisation est nécessaire. Celle du client si c'est lui, celle des tiers présents sinon. Sur une photo montrant un enfant, l'autorisation des deux parents est requise, ce qui rend ces images difficiles à exploiter en pratique.
Deux règles simples évitent la majorité des problèmes : privilégier les photos de produit sans personne identifiable, et conserver la trace horodatée du consentement, pas seulement la photo.
## La modération
Aucune publication automatique. Une file de validation est indispensable, avec des critères écrits.
- La photo montre-t-elle bien le produit concerné ?
- Une personne tierce est-elle identifiable sans autorisation ?
- Des données personnelles apparaissent-elles en arrière-plan : plaque d'immatriculation, courrier, écran ?
- Une marque concurrente est-elle visible ?
- La qualité permet-elle de distinguer quelque chose ?
Comptez moins d'une minute par photo une fois les critères posés. Ce n'est pas la modération qui coûte, c'est l'absence de critères.
## Le point technique : rattacher au bon produit
C'est la difficulté d'implémentation principale, et elle est sous-estimée. Une photo issue d'une commande contenant quatre articles doit être associée au bon, sinon la galerie devient un fourre-tout inutilisable.
Deux approches. Demander au client de choisir le produit concerné au moment de l'envoi, ce qui ajoute une étape mais garantit l'exactitude. Ou proposer l'envoi depuis la fiche produit elle-même, le rattachement étant alors implicite. La seconde donne de meilleurs résultats.
Sur les photos importées depuis les réseaux sociaux, le rattachement reste manuel, ce qui limite le volume traitable.
## Où placer la galerie
Sur la fiche produit, sous la description et au-dessus des avis, la galerie fonctionne comme une extension visuelle des avis. Une page dédiée regroupant toutes les photos sert de vitrine sociale et se partage bien, mais elle convertit moins.
Sur mobile, un défilement horizontal avec ouverture en plein écran fonctionne mieux qu'une grille compressée.
## Mesurer
Comparez le taux de conversion des fiches disposant d'au moins trois photos clients à celui des fiches n'en ayant aucune, sur des produits comparables. Suivez également le taux de retour de ces mêmes fiches : c'est souvent là que le gain est le plus net, et le moins attendu.
Le gère cette chaîne sur PrestaShop 8 et 9 : collecte depuis la fiche produit ou l'email post-achat, recueil du consentement, file de modération, rattachement au produit et affichage en galerie sur la fiche comme sur une page dédiée.
---
### Comment proposer des commandes récurrentes de réassort sur PrestaShop ?
_Source :_ — _publié_ 2026-08-21
> Sur les consommables, le client revient commander quand le produit est fini, donc trop tard. Comment identifier les produits à rythme stable, où proposer la récurrence, et les quatre actions que le client doit pouvoir faire seul.
Sur un catalogue de consommables, une part importante du chiffre d'affaires provient de clients qui reviennent commander la même chose. Ils y pensent quand le produit est terminé, c'est-à-dire souvent trop tard, et parfois ils ne reviennent pas parce qu'un concurrent est apparu entre-temps.
La commande récurrente supprime ce moment de bascule. Le client décide une fois, et la commande repart d'elle-même à intervalle choisi.
## Identifier les produits candidats
Tout ne se prête pas à la récurrence. Le critère est simple : l'intervalle entre deux commandes du même produit par le même client doit être stable.
Vous pouvez l'établir à partir de votre historique. Pour chaque référence achetée au moins deux fois par un même client, calculez l'écart entre les commandes successives, puis prenez la médiane par produit. Un écart médian resserré indique un rythme de consommation prévisible, donc un bon candidat. Un écart très dispersé indique un achat d'opportunité, où la récurrence n'a pas de sens.
Trois familles ressortent presque toujours : les consommables d'entretien, les compléments et produits de santé, les recharges et cartouches. Le point commun n'est pas la catégorie mais la régularité de l'usage.
## Récurrence n'est pas abonnement
La distinction compte, commercialement et juridiquement.
Un **abonnement** établit un engagement de durée, avec un prélèvement automatique sur un moyen de paiement enregistré. Il relève des règles sur la reconduction tacite et la résiliation, et il demande au client une confiance importante.
Une **commande récurrente** reproduit une commande à intervalle régulier, sans engagement de durée. Selon l'implémentation, elle peut se déclencher automatiquement avec un paiement enregistré, ou envoyer un rappel que le client valide en un clic.
La seconde forme est nettement moins engageante, donc plus facile à faire adopter. Elle produit un taux de reconduction inférieur, mais sur une base d'adhérents beaucoup plus large. Sur un premier déploiement, c'est le format à privilégier.
## Le bon moment pour proposer
Trois emplacements fonctionnent, dans cet ordre d'efficacité.
1. **Sur la fiche produit**, à côté du bouton d'achat, sous forme de choix entre commande unique et livraison régulière avec un intervalle présélectionné. Le client décide au moment où il est déjà convaincu.
2. **Dans l'email post-achat**, quelques jours après la livraison. Le produit a été reçu, l'usage a commencé, la proposition arrive sans pression.
3. **Après la deuxième commande du même produit**. C'est le moment le plus qualifié : le client a démontré la répétition. Une proposition personnalisée à ce moment obtient un taux d'adhésion élevé.
Un point de méthode : proposez un intervalle par défaut calculé à partir de la consommation réelle, et non un menu de six options. « Tous les 2 mois » avec possibilité de modifier convertit mieux que six cases à choisir.
## Ce que le client doit pouvoir faire seul
C'est le facteur qui détermine si le dispositif tient dans la durée ou génère des annulations. Quatre actions doivent être accessibles depuis l'espace client, sans passer par le service client.
- **Reporter la prochaine livraison.** L'action la plus demandée, et celle qui évite le plus d'annulations. Un client qui part en vacances veut décaler, pas arrêter.
- **Modifier la quantité ou l'intervalle.** La consommation réelle diffère toujours de l'estimation initiale.
- **Sauter une occurrence.** Variante du report, utile quand le stock du client est excédentaire.
- **Arrêter, sans friction.** Rendre l'arrêt difficile ne conserve personne, cela produit des rejets de paiement et des avis négatifs.
Un rappel envoyé quelques jours avant chaque échéance, avec les liens vers ces quatre actions, réduit fortement les annulations et supprime la sensation de prélèvement subi.
## Prix, stock et rupture
Trois questions à trancher avant l'ouverture.
**Le prix appliqué** est celui du jour de la commande, pas celui du jour de la souscription. Toute autre règle vous engage sur des tarifs futurs. Annoncez-le clairement, et prévenez le client en cas de hausse avant l'échéance suivante.
**La rupture de stock** doit décaler la commande, pas l'annuler. Une annulation silencieuse est perçue comme une résiliation unilatérale et se solde par un abandon.
**La remise éventuelle** accordée à la récurrence doit être calibrée. Cinq à dix pour cent suffisent à faire pencher la décision. Au-delà, vous financez un engagement que le client aurait pris de toute façon.
## Les trois chiffres à suivre
Le taux d'adhésion, part des commandes du produit qui passent en récurrent. Le nombre moyen d'occurrences avant arrêt, qui donne la valeur réelle d'un adhérent. Et le taux de report, qui signale un intervalle par défaut mal calibré s'il est élevé.
Le couvre cette chaîne sur PrestaShop 8 et 9 : proposition sur la fiche produit avec intervalle paramétrable, espace client pour reporter, modifier ou arrêter, rappel avant échéance et gestion du report en cas de rupture.
---
### Notifications push web 2026 : levier de réengagement ou nuisance qui tue la confiance ?
_Source :_ — _publié_ 2026-08-21
> Le push web a traversé trois cycles depuis 2015 : engouement, fatigue, maturation réglementaire. En 2026, c'est un levier de réengagement de niche qui délivre 2 à 5 % du CA additionnel sur cart abandonment, back in stock et price drop — ou une nuisance qui détruit la confiance si mal déployé. Web Push API, support iOS PWA, opt-in conforme RGPD, comparatif OneSignal / PushOwl / Wonderpush et arithmétique du ROI.
Les notifications push web ont traversé trois cycles depuis 2015 : engouement initial (« le nouveau email »), saturation et fatigue utilisateur (popups intrusifs, opt-in trompeur), maturation réglementaire (RGPD, ePrivacy). En 2026, le push web est à nouveau un levier intéressant — à condition de comprendre ce qu'il a changé et ce qu'il n'a pas.
Le push web n'est pas un canal de masse à la manière de l'email. C'est un canal de réengagement de niche, avec un taux d'opt-in faible (5-10 % de la base visiteurs), des contraintes techniques spécifiques, et une exigence de qualité élevée — trop d'envois, et l'utilisateur désabonne. Cet article fait le point sur ce qui marche en 2026, les protocoles, les outils, et le test de pertinence à conduire avant d'investir.
## Ce qu'est le push web techniquement
Le push web repose sur le protocole Web Push API standardisé par le W3C. Mécanique :
1. Le visiteur arrive sur le site. Au bout d'un certain temps ou après une action, une demande de permission s'affiche (la modale native du navigateur).
2. Si l'utilisateur accepte, le navigateur génère un endpoint unique (URL des serveurs push de Mozilla, Google ou Apple) et le partage avec le site.
3. Le site stocke cet endpoint, associé à un identifiant utilisateur si connu.
4. Pour envoyer une notification, le site (ou son outil push) envoie une requête signée VAPID au endpoint, qui pousse la notification au navigateur.
5. L'utilisateur voit la notification même si le site n'est pas ouvert, tant que le navigateur tourne (ou en arrière-plan sur mobile).
### Support navigateur en 2026
- **Chrome, Edge, Firefox, Opera** sur desktop et Android : support complet depuis longtemps.
- **Safari macOS et iPadOS** : support natif depuis macOS 13.
- **Safari iOS (iPhone)** : support partiel depuis iOS 16.4 (mars 2023), à condition que le site soit installé en PWA sur l'écran d'accueil. C'est la grande limitation : sur iPhone, le push web nécessite l'installation PWA préalable.
Conséquence en 2026 : le push web est puissant sur Android et desktop, marginal sur iPhone tant que la PWA n'est pas installée. Pour une audience majoritairement iOS sans PWA, le push web ne couvre que 20-30 % de la base.
## Le cadre RGPD et ePrivacy
Le push web relève de la directive ePrivacy et du RGPD :
- **Consentement explicite** : la modale push native du navigateur fait office de recueil de consentement, mais elle ne se déclenche que si on l'appelle proprement (en réponse à une action utilisateur claire, pas au chargement de la page).
- **Information préalable** : l'utilisateur doit savoir ce qu'il va recevoir avant d'accepter. Bonne pratique : afficher un pré-prompt sur-mesure (« Recevoir nos alertes promo ? ») avant la modale native.
- **Désabonnement facile** : un bouton de désabonnement doit être accessible à tout moment, idealement directement dans la notification.
- **Données personnelles** : l'endpoint push n'est pas en soi une donnée personnelle, mais l'association avec un identifiant client en fait une donnée personnelle. À documenter dans le registre RGPD.
Les opt-in trompeurs (« Cliquez OK pour accéder au site ») sont sanctionnés par la CNIL et restent l'erreur la plus fréquente. À partir de 2024-2025, la jurisprudence est ferme : un opt-in ambigu vaut absence de consentement.
## Les cas d'usage qui justifient le canal
Le push web n'est rentable que sur des cas d'usage à haut signal. Mauvais usage : newsletter quotidienne. Bons usages :
### 1. Cart abandonment
Notification push 1h-4h après abandon de panier : « Votre panier vous attend, finalisez avant la fin de la promo. » Taux de clic typique 4-12 %, taux de conversion clic-vente 8-15 %. ROI généralement positif dès 50 paniers abandonnés / jour.
### 2. Back in stock
L'acheteur s'était inscrit sur la liste d'attente d'un produit en rupture. « Le produit X est de retour. » Push déclenché dès la réassort. Taux de clic 25-45 %, taux de conversion 15-30 %. C'est le cas d'usage roi.
### 3. Price drop
L'acheteur avait ajouté à favoris ou consulté un produit. « Le prix du produit X vient de baisser de 20 %. » Push déclenché sur changement de prix significatif. Taux de clic 10-20 %, taux de conversion 5-12 %.
### 4. Confirmation d'événement majeur
« Votre commande est expédiée », « Code de retrait disponible ». Mais en concurrence avec SMS et email transactionnels — souvent moins pertinent pour ces événements.
### 5. Lancements d'offres limitées
« Vente flash 2h » sur produits surveillés. À utiliser avec parcimonie pour ne pas épuiser la base.
## Outils en 2026
### OneSignal
- Leader mondial, plan free généreux (jusqu'à 10 K abonnés).
- Module PrestaShop officiel et SDK riche.
- Segmentation, tag dynamiques, A/B testing inclus.
- Tarif payant à partir de 9 $/mois, scaling jusqu'à plusieurs centaines.
### PushOwl
- Spécialiste e-commerce, focalisé sur Shopify mais intégrable PrestaShop via API.
- Templates e-commerce natifs (cart abandonment, back in stock, etc.).
- Tarif à partir de 19 $/mois.
### Wonderpush
- Solution européenne, hébergement UE, plus stricte sur la conformité RGPD.
- Module PrestaShop spécifique.
- Tarif à partir de 1 €/1000 push, plans entreprise négociables.
### DIY via Web Push API
- Développement custom utilisant la Web Push API native.
- Coût initial 5-15 K€ de dev.
- Pertinent uniquement si on a un besoin spécifique non couvert par les solutions SaaS, ou un argument de souveraineté des données.
## L'arithmétique du ROI
Sur une boutique PrestaShop à 100 K visiteurs uniques par mois :
- Taux d'opt-in réaliste en 2026 : 5-10 % après 30 jours d'optimisation = 5 000 à 10 000 abonnés.
- Désabonnement / churn : 2-4 % par mois — il faut renouveler la base.
- Push transactionnels (back in stock, cart abandon, price drop) : 100-500 envois / jour selon taille catalogue.
- CTR typique : 6-15 %.
- Conversion clic-vente : 5-12 %.
Sur cette base, le push web génère typiquement 2 à 5 % du CA total de la boutique. Sur une boutique à 500 K€/mois, c'est 10-25 K€/mois de CA additionnel pour un coût outil de 20-150 €/mois. ROI nettement positif tant que la base est entretenue avec qualité.
## Quand le push web est une nuisance qui tue la confiance
Le même canal peut faire perdre 2-5 % du CA s'il est mal utilisé. Signaux de mauvaise utilisation :
- **Envois quotidiens promotionnels génériques** : le visiteur désabonne et associe la marque à du spam.
- **Opt-in dès l'arrivée** : la modale s'affiche en même temps que la page se charge. Résultat : 95 % de « Refus » et opt-in définitivement bloqué par le navigateur (sur Chrome, après 2-3 refus, le bouton disparait).
- **Contenu trompeur** : titre qui promet une promo, clic qui mène sur une fiche produit standard. Résultat : taux de plainte navigateur monte, distribution future dégradée par les serveurs push.
- **Confusion canal** : pousser des notifications qui auraient dû être des emails. Le push est court (< 200 caractères), éphémère, et sans contenu riche. Mauvais canal pour une newsletter.
## La mécanique d'opt-in qui marche
1. **Pas d'opt-in en page d'arrivée**. Déclenchement après 30 à 60 secondes de session, ou après un signal d'engagement (consultation de 3 pages, ajout au favoris, abandon de panier).
2. **Pré-prompt sur-mesure** : un encart « Recevoir vos alertes promo, retour stock et nouveautés ? » avec bouton « Oui » / « Plus tard ». Si « Oui », on déclenche la modale native.
3. **Valeur claire** : indiquer ce que l'utilisateur va recevoir (« maximum 2 push par semaine », « uniquement les retours en stock que vous suivez »).
4. **Pas plus de 1 demande par session**, et mémorisation : si refus, ne pas redemander avant 30 jours.
## Les pièges à éviter
### 1. Sur-solliciter et brûler la base
Plus de 2 push promotionnels par semaine et le désabonnement explose. Règle empirique : 1 push transactionnel par jour maximum, 1 push promotionnel par semaine maximum.
### 2. Confondre opt-in et inscription newsletter
Le RGPD requiert un consentement distinct pour chaque canal. Inscription newsletter ne donne pas le droit de pusher. Et l'inverse.
### 3. Ne pas mesurer la délivrabilité
Les serveurs push de Google et Mozilla dégradent la délivrabilité des envois en cas de taux de plainte élevé ou de contenu suspect. Monitorer le taux de délivrance via le dashboard de l'outil push, et corriger dès qu'il chute sous 90 %.
### 4. Oublier le re-engagement de la base inactive
Un abonné qui n'a pas cliqué depuis 90 jours est un coup probable de désabonnement bientôt. Mieux vaut le sortir proactivement de la base que de continuer à polluer ses notifications.
### 5. Négliger le iOS PWA
Sur audience majoritairement iPhone, le push web sans PWA installable couvre une fraction de la base. Si la PWA est mise en place et activement promue (« Installer notre app »), le push web devient pertinent. Sans PWA, autres canaux à privilégier.
## Conclusion : un levier de niche, pas un canal de masse
En 2026, le push web n'est ni la solution miracle vendue en 2018 ni le canal mort prédit en 2022. C'est un levier de réengagement de niche, qui délivre 2 à 5 % de CA additionnel sur des cas d'usage bien ciblés (cart abandonment, back in stock, price drop). À condition de respecter trois règles : opt-in honnête sans piégeage, contenu transactionnel à forte valeur, parcimonie sur le promotionnel.
Pour une boutique PrestaShop mid-market, OneSignal en plan free ou payant entrée couvre la majorité des besoins, avec un déploiement en 2-5 jours. Le test de pertinence prend 60-90 jours : si après ce délai, l'opt-in stagne sous 3 % ou les push génèrent moins de 1 % du CA, le canal n'est pas une priorité pour cette audience. S'il dépasse 4 %, c'est un levier désormais structurel à entretenir sur la durée.
---
### Comment afficher un prix différent selon le pays dans PrestaShop ?
_Source :_ — _publié_ 2026-08-21
> PrestaShop raisonne en prix unique décliné par devise et corrigé par la TVA, pas en prix par pays. Les quatre leviers de différenciation, le piège du prix TTC rond, et ce que le règlement européen sur le blocage géographique autorise vraiment.
Vendre 49 euros en France et 54 euros en Allemagne n'est pas une fantaisie : c'est la conséquence de coûts logistiques différents, d'un paysage concurrentiel différent et de taux de TVA différents. Le problème est que PrestaShop ne raisonne pas en prix par pays. Il raisonne en prix unique, décliné par devise et corrigé par la TVA.
Voici ce que le natif permet réellement, où il s'arrête, et le point réglementaire que la plupart des boutiques ignorent.
## Ce que fait le natif
Trois mécanismes existent et se combinent.
**La devise.** Chaque devise possède un taux de conversion appliqué au prix de base. Vous ne fixez pas un prix en livres sterling : vous fixez un taux, et PrestaShop calcule. Le résultat donne des prix comme 43,17 livres, que personne n'affiche volontairement.
**La TVA par pays.** Les règles de taxes s'appliquent selon le pays de livraison. Le prix hors taxes reste identique, seul le prix TTC varie. Un produit à 40 euros hors taxes devient 48 euros en France et 47,60 en Allemagne.
**Le multiboutique.** Une boutique par pays, chacune avec son catalogue, ses prix et son domaine. C'est la seule voie native pour fixer des prix réellement différents, et elle a un coût de gestion réel.
## Le piège du prix TTC rond
C'est le point qui surprend le plus. Vous voulez afficher 49,90 euros dans toute l'Europe, prix psychologique classique. Avec un prix hors taxes unique, c'est impossible : les taux de TVA diffèrent, donc les prix TTC diffèrent.
Pour afficher le même prix TTC partout, il faut faire varier le prix hors taxes en sens inverse du taux de TVA. Votre marge devient alors différente d'un pays à l'autre, ce qui est une décision commerciale à prendre en conscience, pas un effet de bord à découvrir dans le compte de résultat.
Le raisonnement inverse est tout aussi valable : conserver la marge et accepter des prix TTC non ronds. Il n'y a pas de bonne réponse universelle, mais il y a une mauvaise pratique, celle qui consiste à ne pas trancher.
## Les quatre leviers de différenciation
1. **Le prix spécifique par pays.** PrestaShop permet de rattacher un prix spécifique à un pays donné. C'est le levier le plus direct, mais il se paramètre produit par produit, ce qui le rend impraticable au-delà de quelques dizaines de références.
2. **Le groupe de clients.** Un groupe par zone, avec une remise ou une majoration globale. Simple, mais il suppose que le client soit rattaché au bon groupe, donc identifié, ce qui exclut les visiteurs non connectés.
3. **Le coefficient par devise.** Plutôt qu'un taux de change strict, appliquer un coefficient commercial. Cela règle le problème des prix non ronds mais ne différencie que par devise, pas par pays : la France, l'Allemagne et l'Espagne restent au même tarif.
4. **Le multiboutique.** Contrôle total, coût de gestion maximal. Chaque modification de catalogue doit être répercutée, ou héritée avec les précautions que cela suppose.
## Le point réglementaire à connaître
Le règlement européen sur le blocage géographique injustifié encadre cette pratique depuis 2018, et il est régulièrement mal compris.
Ce qu'il n'interdit pas : proposer des prix différents selon les versions nationales de votre site. Vous restez libre de votre politique tarifaire par marché.
Ce qu'il interdit : empêcher un client d'accéder à une autre version de votre site en raison de sa nationalité, de son lieu de résidence ou du pays d'émission de sa carte bancaire, et le rediriger automatiquement sans son accord. Concrètement, un client français doit pouvoir consulter et commander sur votre boutique allemande, aux conditions allemandes, s'il le souhaite, y compris avec une carte française.
La redirection automatique par géolocalisation est donc à manier avec précaution : proposer, oui, imposer, non. Une bannière suggérant la version locale avec un lien pour rester sur la version courante remplit la condition. Une redirection silencieuse ne la remplit pas.
## Détection du pays et cache
Deux difficultés techniques se cumulent dès que le prix dépend du pays.
**La détection.** Avant qu'un client soit connecté ou ait renseigné une adresse, son pays ne peut être déduit que de son adresse IP, avec une fiabilité imparfaite et une exactitude nulle derrière un VPN. Le prix affiché en navigation anonyme relève donc toujours d'une hypothèse. Elle doit être corrigeable par un sélecteur visible, et le prix définitif ne se fixe qu'à la saisie de l'adresse de livraison.
**Le cache.** Une page produit mise en cache contient un prix. Si ce prix dépend du pays, il faut soit segmenter le cache par pays, ce qui multiplie son volume, soit sortir le bloc prix du cache et le charger séparément. La première option est plus simple, la seconde plus économe.
Un symptôme classique révèle un cache mal segmenté : le premier visiteur d'une page depuis un pays donné voit le bon prix, les suivants voient le sien.
## La cohérence avec les canaux externes
Un point souvent découvert trop tard. Si vos prix varient par pays, vos flux produits doivent varier de la même façon. Un flux Merchant Center annonçant 49 euros pour une page qui en affiche 54 déclenche un refus, et des refus répétés peuvent suspendre le compte.
La règle est de générer un flux par pays cible, alimenté par la même source que l'affichage, jamais par un export figé.
## Mettre en place la différenciation
Le traite ce besoin sur PrestaShop 8 et 9 : règles de prix par pays et par devise appliquées en masse plutôt que produit par produit, coefficient de marge, arrondi psychologique par devise et cohérence de l'affichage entre catalogue, fiche et panier.
---
### Générer un catalogue PDF téléchargeable depuis PrestaShop
_Source :_ — _publié_ 2026-08-20
> Le catalogue PDF reste indispensable en B2B et sur salon. Trois usages qui appellent trois documents différents, comment traiter le problème des prix figés, et pourquoi un simple lien de téléchargement ne suffit pas à le rendre consultable.
Le catalogue PDF a disparu du B2C, et il reste indispensable ailleurs. Un commercial en rendez-vous, un acheteur professionnel qui doit faire valider une sélection en interne, un exposant sur un salon sans réseau fiable : dans ces trois situations, un document autonome fait ce qu'aucune page web ne fait.
Le sujet se sépare en deux problèmes distincts, qu'on confond souvent : produire le PDF, et le rendre utilisable depuis la boutique.
## Trois usages, trois documents différents
**Le catalogue commercial complet.** Toutes les références d'une gamme, avec visuels et caractéristiques. Volumineux, mis à jour une à deux fois par an. C'est le document de référence, celui qu'on envoie à un nouveau distributeur.
**La sélection personnalisée.** Vingt à cinquante références choisies pour un client donné, avec ses conditions tarifaires. Produit à la demande, durée de vie de quelques semaines. C'est celui qui fait avancer une affaire.
**La fiche technique produit.** Une ou deux pages sur une référence unique, téléchargeable depuis la fiche. Le document le plus consulté des trois, et le plus souvent absent.
Vouloir traiter les trois avec le même outil conduit généralement à mal traiter les trois.
## Produire le document
Trois approches, avec des coûts très différents.
1. **La mise en page manuelle.** Export du catalogue, mise en forme dans un logiciel de PAO. Résultat impeccable, coût élevé, et obsolescence immédiate dès qu'un prix change.
2. **La génération automatique depuis le catalogue.** Un gabarit, des données à jour, un document produit à la demande. Moins beau, toujours exact.
3. **L'approche mixte.** Pages de couverture et d'univers travaillées en PAO, pages produits générées. C'est ce qui tient le mieux dans la durée.
## Le problème du prix
Un PDF fige les prix au moment de sa génération. Trois façons de traiter le problème, à choisir selon l'usage.
- **Aucun prix dans le document**, avec renvoi vers la boutique ou vers un tarif joint séparément. C'est la solution la plus sûre pour un catalogue annuel.
- **Prix avec date de validité** imprimée en pied de page. Indispensable si vous affichez des prix : sans cette mention, le document vous engage.
- **Génération à la demande**, le PDF étant produit au moment du téléchargement avec les prix du jour et les conditions du client connecté.
La troisième option est la seule qui résout réellement le problème, et c'est aussi la seule qui suppose que le document soit produit par la boutique plutôt que déposé sur le serveur.
## Publier le document sur la boutique
C'est la partie négligée. Un PDF déposé derrière un simple lien de téléchargement obtient très peu de consultations : le visiteur ne sait pas ce qu'il va télécharger, hésite devant un fichier de plusieurs dizaines de méga-octets, et abandonne.
Une visionneuse intégrée change ce comportement. Le document se feuillette dans la page, en double page comme un vrai catalogue, avec les miniatures pour naviguer et un mode plein écran. Le téléchargement reste possible, mais il devient un choix plutôt qu'un préalable.
Trois emplacements méritent d'accueillir cette visionneuse : une page dédiée au catalogue, la page de chaque univers produit avec le catalogue de la gamme concernée, et l'espace client pour les documents réservés aux professionnels.
## Le point SEO
Un PDF est indexable par les moteurs, et il se positionne parfois mieux qu'on ne l'imagine sur des requêtes de référence technique. Trois précautions.
Renseignez les métadonnées du document, titre et auteur, qui servent de titre dans les résultats de recherche. Donnez au fichier un nom explicite plutôt qu'une suite de chiffres. Et vérifiez que le texte est bien du texte : un PDF composé d'images scannées n'est lisible ni par les moteurs ni par les lecteurs d'écran.
Point de vigilance inverse : un catalogue PDF qui reprend l'intégralité de votre contenu produit peut se positionner à la place de vos fiches. Si ce risque existe, la page de la visionneuse doit être indexable et le fichier PDF lui-même exclu de l'indexation.
## Mesurer
Deux chiffres suffisent : le nombre de consultations dans la visionneuse, et le nombre de téléchargements. Leur écart vous dit si le document sert à la consultation rapide ou à l'archivage, et donc s'il faut investir dans la mise en page ou dans l'exhaustivité.
Sur un usage B2B, un troisième indicateur mérite le suivi : la part des téléchargements suivis d'une demande de devis dans les sept jours.
## Publier proprement
Le traite la partie publication sur PrestaShop 8 et 9 : visionneuse double page avec miniatures et mode plein écran, intégration dans une page dédiée ou une catégorie, téléchargement optionnel et page indexable autour du document.
---
### Bundles et packs produits PrestaShop : conversion, AOV et la mécanique technique
_Source :_ — _publié_ 2026-08-20
> Pendant que toute l'attention se porte sur le taux de conversion, le levier le plus rentable du e-commerce reste largement sous-utilisé : faire grossir le panier moyen au moment de l'achat. Les bundles et packs produits déplacent l'aiguille de +18 à +35 % d'AOV sur les boutiques qui les déploient proprement. Les trois familles (pack fixe, mix & match, FBT), la mécanique technique sur PrestaShop, les enjeux TVA et retours, les pièges qui font échouer 80 % des déploiements.
Le panier moyen est l'indicateur de marge le plus négligé du e-commerce mid-market. Pendant que toute l'attention se porte sur le taux de conversion et le coût d'acquisition, le levier le plus rentable reste souvent invisible : faire grossir le panier au moment de l'achat. Et de tous les outils à disposition (cross-sell, up-sell, livraison gratuite à partir de X), les bundles et packs produits sont ceux qui déplacent le plus l'aiguille — entre +18 % et +35 % d'AOV sur les boutiques qui les déploient proprement.
Sur PrestaShop, les bundles sont mal compris et mal utilisés. Le « Pack » natif est limité, la TVA pose des questions, la gestion des retours est complexe, et beaucoup de marchands renoncent. Cet article fait le point sur les trois familles de bundles, la mécanique technique sur PrestaShop, le ROI mesuré et les pièges qui font échouer 80 % des déploiements.
## Les trois familles de bundles en 2026
### Famille 1 : le pack fixe
Un pack fixe est un produit virtuel composé de plusieurs références à quantités déterminées, vendu à un prix unique inférieur à la somme des composants. Exemple : « Pack découverte café » avec 3 paquets différents à 19,90 € (au lieu de 24 €).
- Cas d'usage : produits complémentaires évidents (kit, set, coffret, panier découverte).
- Avantage : simple à modéliser, panier moyen prévisible, marges contrôlées.
- Limite : pas de personnalisation, l'acheteur prend tout ou rien.
### Famille 2 : le bundle composable (mix & match)
L'acheteur choisit lui-même N produits parmi un ensemble, avec un prix dégressif. Exemple : « 3 t-shirts pour 39 € », l'acheteur choisit ses 3 t-shirts parmi 50 références.
- Cas d'usage : mode, cosmétique, livres, vins.
- Avantage : taux de conversion élevé (sentiment de personnalisation, perception de bonne affaire).
- Limite : complexité technique élevée (gestion du stock, fiche produit dynamique, panier).
### Famille 3 : Frequently Bought Together (FBT)
Suggérer sur la fiche produit « les clients qui ont acheté ce produit ont aussi acheté » avec ajout en un clic. Bundle dynamique, proposé mais pas imposé.
- Cas d'usage : universel mais particulièrement efficace sur électronique, accessoires, matière première.
- Avantage : zero effort merchandiser si bien automatisé sur algorithme.
- Limite : moins puissant que les packs fixes (le client peut refuser), nécessite un volume de données de commandes pour être pertinent.
## Le ROI mesuré : +18 à +35 % d'AOV
Sur des audits de boutiques PrestaShop 2025-2026 ayant déployé des bundles de manière structurée :
- **Pack fixe correctement merchandisé** : +12 à +22 % d'AOV sur les visiteurs qui voient un pack en page d'accueil ou catégorie dédiée.
- **Bundle composable** : +20 à +35 % d'AOV, +5 à +12 points de conversion sur la page bundle dédiée par rapport aux fiches produit individuelles.
- **FBT bien algorithmé** : +8 à +18 % d'AOV sur la portion des visiteurs qui acceptent la suggestion (typiquement 5-15 % des acheteurs).
Effet combiné : sur une boutique avec un AOV de 75 €, l'introduction de bundles structurés remonte typiquement l'AOV à 90-105 € sur 6-9 mois. Pour une boutique à 1 M€/an, c'est 200-400 K€ de CA additionnel sans coût d'acquisition supplémentaire.
## L'implémentation sur PrestaShop 8 et 9
### Pack fixe : utiliser la fonctionnalité native
PrestaShop propose une fonctionnalité « Pack » dans le back-office produit. Paramétrage :
- Type produit : Pack.
- Ajouter les produits composants avec quantité.
- Définir si le stock du pack est calculé à partir des composants (option recommandée) ou géré indépendamment.
- Configurer la décrémentation des stocks composants à la vente.
Limite native : la fiche produit pack affiche les composants en lecture seule, sans personnalisation. Pour des packs marketing élaborés, il faut customiser le thème ou utiliser un module.
### Bundle composable : module nécessaire
Le natif PrestaShop ne couvre pas le mix & match. Modules pertinents en 2026 :
- Module dédié mix & match (plusieurs sur l'Addons, 80-250 €).
- Développement custom sur Symfony pour une boutique à volumes élevés ou logique spécifique (4-8 K€ de dev).
Logique technique :
- Page bundle dédiée (« Composez votre pack ») avec liste filtrable des produits éligibles.
- Ajout au panier : ligne unique « Bundle X » avec sous-lignes composants, ou plusieurs lignes groupées par bundle_id.
- Prix : calcul au moment de l'ajout (le prix bundle remplace la somme des composants).
- Stock : vérifier que chaque composant est en stock au moment de l'ajout, et décrémenter à la validation.
### Frequently Bought Together : modules + data
Modules dispos sur l'Addons (DataFirefly dfcartcrosssell, autres). Algorithme par défaut : co-occurrence dans les commandes passées. Variantes plus avancées : similarité attributs, recommandations IA basées sur navigation.
Clé du succès : avoir suffisamment de données de commandes (au moins 1 000 commandes / mois) pour que la co-occurrence soit statistiquement fiable. Sinon, recommandations éditeur (FBT manuels) plus pertinentes.
## Les enjeux TVA et marge
### TVA
Si le bundle est composé de produits à taux de TVA différents (par exemple livre à 5,5 % + DVD à 20 %), la règle fiscale française impose de ventiler la TVA proportionnellement aux composants, pas d'appliquer un taux unique. Sur la facture, chaque ligne composant doit montrer son taux. PrestaShop pack natif gère la répartition correctement ; un bundle custom doit être vérifié par l'expert-comptable.
### Calcul de marge
Erreur fréquente : appliquer une remise sur un bundle qui mange toute la marge sur les composants haut de gamme. À surveiller au cas par cas :
- Marge brute composant par composant.
- Marge sur le bundle complet (selon discount appliqué).
- Vérifier que la marge globale par produit pack reste positive et cohérente avec la cible de marge.
### Retours partiels
Si le client retourne 1 produit d'un pack de 3, comment rembourser ? Trois options pratiques :
- Refus du retour partiel (politique explicite, mention en page produit).
- Remboursement au prix unitaire hors pack (le client perd la remise pack).
- Remboursement au prorata de la valeur dans le pack (le client garde la remise au prorata).
Le modèle doit être clair, documenté dans les CGV et implémenté dans le workflow de retour. Sans clarté, conflit client et risque RGPD sur le traitement non documenté.
## SEO et merchandising : le bundle comme page de destination
Un bundle bien fait n'est pas seulement un produit catalogue, c'est une page SEO à part entière :
- URL dédiée avec slug optimisé (`/coffret-decouverte-cafe-3-paquets`).
- Title et meta description spécifiques, optimisés sur la requête cible (« coffret découverte café »).
- Description riche : compositions, suggestions d'usage, comparaison avec achat individuel.
- Schema.org Product avec offre et ProductCollection référençant les composants.
- FAQPage Schema sur les questions récurrentes (peut-on substituer un élément ? livraison ? offre cadeau ?).
Les bundles bien référencés captent un trafic organique distinct des fiches produit individuelles — et généralement à plus forte intention d'achat (« coffret », « kit », « pack » sont des requêtes de fin de funnel).
## Les pièges à éviter
### 1. Cannibaliser les ventes unitaires
Si la remise bundle est trop forte, les acheteurs qui auraient acheté un produit unitaire passent au bundle. La marge brute baisse au lieu d'augmenter. Calculer le mix bundle / unitaire avant et après déploiement, ajuster la remise pour maximiser la marge totale et non l'AOV brut.
### 2. Créer des bundles sans cohérence merchandising
« On va faire des packs pour augmenter l'AOV » sans logique d'usage produit. Résultat : 50 packs créés, aucun ne vend. Les bundles efficaces ont une narrative : « kit démarrage », « essentiels de la saison », « offre cadeau ». Sans narrative, le bundle est invisible.
### 3. Sous-estimer la complexité stock
Sur un bundle composable où chaque composant peut tomber en rupture, le système doit gérer en temps réel les composants disponibles. Une page bundle qui affiche des composants out-of-stock saigne la conversion. Sync stock obligatoire.
### 4. Ne pas tracker les bundles séparément
Sans tracking spécifique (item_id distinct dans GA4, catégorie « Bundle » dans le data layer), impossible de mesurer le ROI réel du levier. Tagger les bundles est l'étape la plus souvent oubliée.
### 5. Confondre bundle et cross-sell
Un cross-sell suggère d'ajouter un produit au panier en cours. Un bundle est un produit en lui-même, avec une page dédiée et un prix bundle. Les deux peuvent coexister, mais leur logique merchandising et SEO est différente.
## Conclusion : le levier AOV le plus rentable, sous-utilisé
En 2026, les bundles et packs produits restent l'un des leviers de croissance les plus rentables sur PrestaShop, et l'un des moins exploités par rapport à leur potentiel. Le retour sur investissement est mesurable dès 30 jours sur les boutiques qui déploient proprement, avec un effet durable au-delà.
La clé du succès n'est pas technique — PrestaShop gère le pack natif honnêtement, les modules tiers couvrent le mix & match — mais merchandising et data : choisir les bundles avec une narrative claire, calibrer la remise pour maximiser la marge, tracker pour mesurer, itérer chaque trimestre. Une boutique qui déploie 5-10 bundles bien conçus, avec leur page SEO dédiée et leur narrative cohérente, capte un levier d'AOV qui surpasse souvent les efforts d'acquisition payante.
---
### Recherche interne PrestaShop : pourquoi elle ne trouve pas les fautes de frappe
_Source :_ — _publié_ 2026-08-20
> Une lettre manquante suffit à rendre un produit invisible. Comment PrestaShop construit son index de recherche, pourquoi la correspondance reste exacte, les trois autres angles morts et les quatre niveaux de correction possibles.
Un visiteur tape « chausure » au lieu de « chaussure » et obtient une page vide. Le produit est en stock, bien renseigné, correctement catégorisé, mais une lettre manquante suffit à le rendre invisible. Ce comportement n'est pas un bug : il découle directement de la façon dont PrestaShop indexe et interroge son catalogue.
## Comment fonctionne la recherche native
PrestaShop construit son propre index de recherche, indépendant du catalogue. Deux tables le portent : l'une stocke les mots rencontrés, l'autre associe chaque mot aux produits qui le contiennent, avec un poids.
L'indexation applique une série de traitements au moment où le produit est enregistré. Le texte est découpé en mots, les accents sont normalisés, les mots trop courts sont écartés, et une liste de mots vides est retirée. Les champs pris en compte et leur poids respectif se règlent dans **Configurer > Paramètres de la boutique > Recherche** : nom du produit, référence, description courte, description longue, marque, attributs, caractéristiques.
À la requête, PrestaShop applique le même découpage aux mots saisis, puis cherche des correspondances dans l'index. C'est là que tout se joue : la correspondance est exacte, ou par début de mot selon le réglage, mais jamais approximative.
### Pourquoi aucune tolérance
Le moteur compare des chaînes de caractères. « Chausure » et « chaussure » sont deux chaînes différentes, sans relation, et rien dans le mécanisme ne mesure la distance entre elles. Un moteur tolérant aux fautes doit calculer un écart entre les mots, ce qui suppose une structure d'index et un coût de calcul que le mécanisme natif ne prévoit pas.
La recherche par début de mot, activable dans les réglages, crée l'illusion d'une tolérance. Elle trouve « chaussures » à partir de « chaussu », mais reste impuissante dès que l'erreur porte sur une lettre au milieu du mot.
## Les autres angles morts
La faute de frappe n'est que le cas le plus visible. Trois autres situations produisent le même résultat.
- **Le vocabulaire différent.** Le client cherche « chargeur voiture », votre fiche dit « adaptateur allume-cigare ». Aucun mot commun, aucun résultat, alors que le produit correspond parfaitement.
- **Le mot trop court.** Les mots en dessous de la longueur minimale, souvent trois caractères, sont ignorés. Une recherche portant sur une référence courte ou une taille échoue silencieusement.
- **L'index périmé.** L'indexation se déclenche à l'enregistrement du produit, mais un import massif ou une modification directe en base ne la déclenchent pas. Le catalogue est à jour, l'index non.
Ce dernier point mérite un contrôle immédiat : si votre dernier import date d'hier et que vous n'avez pas reconstruit l'index, une partie de votre catalogue est actuellement introuvable.
## Quatre niveaux de correction
Par ordre croissant d'effort et d'efficacité.
**1. Régler ce qui existe.** Reconstruire l'index, abaisser la longueur minimale des mots, activer la recherche par début de mot, revoir la pondération des champs. Une demi-heure, aucun coût, un gain réel mais limité.
**2. Enrichir le vocabulaire.** Ajouter dans un champ dédié, souvent les caractéristiques ou la description courte, les termes que vos clients emploient réellement. La liste s'obtient dans le journal des recherches sans résultat, pas par intuition. C'est l'action au meilleur rapport effort sur résultat.
**3. Passer à un moteur dédié.** Un moteur externe apporte la tolérance aux fautes, les synonymes, la pondération fine et l'autocomplétion. Il impose en contrepartie une synchronisation du catalogue et une dépendance supplémentaire.
**4. Ajouter une couche sémantique.** Plutôt que de comparer des chaînes, la recherche sémantique compare des représentations vectorielles du sens. « Chargeur voiture » et « adaptateur allume-cigare » se rapprochent alors sans qu'aucun synonyme n'ait été déclaré, parce que les deux expressions occupent des positions voisines dans l'espace vectoriel.
## Mesurer avant d'investir
Avant de choisir un niveau, trois chiffres à établir sur trente jours.
1. **La part des sessions** qui utilisent la recherche. En dessous de 5 %, le sujet n'est pas prioritaire. Au-dessus de 20 %, la recherche est un composant central de votre parcours.
2. **Le taux de recherches sans résultat.** Entre 10 et 20 % sur une boutique moyenne. Au-delà, le problème est structurel.
3. **L'écart de conversion** entre les visiteurs qui cherchent et les autres. Il est en général très favorable aux premiers, ce qui donne la valeur de chaque point de recherche récupéré.
Ces trois chiffres transforment une intuition en arbitrage chiffré, et ils déterminent lequel des quatre niveaux mérite votre budget.
## Aller vers la recherche sémantique
Le ajoute cette couche sur PrestaShop 8 et 9 : indexation vectorielle du catalogue, tolérance aux fautes et aux formulations différentes, produits similaires calculés sur le sens, et tableau de bord des requêtes avec leur taux de résultat.
---
### Comment héberger Google Fonts en local sur PrestaShop pour le RGPD ?
_Source :_ — _publié_ 2026-08-19
> Une police chargée depuis les serveurs de Google transmet l'IP du visiteur à un tiers hors UE, sans base légale. Pourquoi le consentement ne règle pas le cas, où se cachent les appels dans PrestaShop, et la procédure de rapatriement en quatre étapes.
Charger une police depuis les serveurs de Google déclenche une requête sortante depuis le navigateur du visiteur, avant tout consentement. Cette requête transmet son adresse IP, l'adresse de la page consultée et son agent utilisateur à un tiers situé hors de l'Union européenne. C'est un traitement de données personnelles qui n'a pas de base légale, et il est trivialement constatable par n'importe qui ouvrant l'inspecteur du navigateur.
Une décision du tribunal régional de Munich en 2022 a condamné un exploitant de site sur ce fondement précis, et l'affaire a servi de base à une vague de mises en demeure en Allemagne. La CNIL a repris le sujet dans ses recommandations. Le risque n'est pas théorique.
## Pourquoi le consentement ne règle pas le problème
On pourrait imaginer bloquer les polices jusqu'au consentement, comme un script de mesure d'audience. En pratique cette approche ne tient pas : une page qui attend le consentement pour charger ses polices s'affiche d'abord en police système puis bascule, ce qui produit un décalage visuel important et dégrade l'expérience pour tout le monde.
L'auto-hébergement est la seule réponse qui règle à la fois la conformité et la performance. Vous téléchargez les fichiers une fois, vous les servez depuis votre propre domaine, et aucune requête ne part chez un tiers.
## Où se cachent les appels dans PrestaShop
C'est la partie que la plupart des rapatriements manquent. Un appel supprimé du thème ne signifie pas que le site est propre.
1. **Le thème.** Une balise de lien vers fonts.googleapis.com dans le fichier d'en-tête, parfois accompagnée d'une directive de préconnexion.
2. **Les feuilles de style.** Une règle d'import en tête d'un fichier CSS, souvent oubliée parce qu'elle n'apparaît pas dans le code des templates.
3. **Les modules.** Un module de carrousel, de compte à rebours ou de pop-up qui charge sa propre police. Chaque module ajoute potentiellement un appel.
4. **Les icônes.** Les bibliothèques d'icônes hébergées chez le même fournisseur relèvent exactement du même problème.
5. **Le contenu.** Une page CMS ou une description produit collée depuis un éditeur externe peut contenir une balise de style important une police distante.
## La procédure
Quatre étapes, dans cet ordre.
**1. Inventorier.** Ouvrez l'onglet Réseau de votre navigateur, filtrez sur les domaines de polices, et rechargez plusieurs pages types : accueil, catégorie, fiche produit, panier, page CMS. Notez chaque famille et chaque graisse réellement appelée.
**2. Télécharger.** Récupérez les fichiers au format WOFF2, qui couvre tous les navigateurs actuels. Ne conservez que les graisses que vous utilisez vraiment : une famille chargée en six graisses alors que le thème n'en emploie que deux représente plusieurs centaines de kilo-octets inutiles.
**3. Déclarer.** Placez les fichiers dans votre thème et déclarez chaque famille avec une règle de police personnalisée, en précisant un comportement d'affichage de type échange pour éviter le texte invisible pendant le chargement.
**4. Nettoyer.** Supprimez toutes les références distantes trouvées à l'étape 1, y compris les directives de préconnexion, qui déclenchent une connexion même sans téléchargement de fichier.
## Le contrôle final
Le test se fait dans l'onglet Réseau, navigation privée, cache vidé. Filtrez sur les domaines de polices distants : zéro requête attendue, sur toutes les pages types, connecté comme déconnecté.
Deux vérifications complémentaires méritent d'être faites. Le back-office charge parfois ses propres polices distantes, ce qui ne concerne pas vos visiteurs mais mérite d'être traité pour vos équipes. Et les emails transactionnels au format HTML peuvent également contenir des appels de polices, ce qui transmet des données à chaque ouverture d'un message.
## Le bénéfice de performance
L'auto-hébergement supprime une résolution DNS, une négociation TLS et une connexion vers un domaine tiers, sur le chemin critique du rendu. Sur une connexion mobile moyenne, cela représente couramment plusieurs centaines de millisecondes gagnées sur l'affichage du texte.
Deux réglages complètent le gain. Le préchargement de la police principale, à déclarer dans l'en-tête, la fait démarrer avant l'analyse du CSS. Et la réduction du jeu de caractères aux alphabets réellement utilisés allège chaque fichier, souvent de moitié quand on retire les caractères cyrilliques et grecs d'une police universelle.
## Le point de vigilance sur la licence
La quasi-totalité des polices distribuées par Google sont sous licence libre, ce qui autorise l'auto-hébergement sans démarche. Vérifiez tout de même la licence des familles que vous rapatriez, en particulier si vous les avez obtenues ailleurs, et conservez le fichier de licence à côté des fichiers de police.
## Automatiser le rapatriement
Le traite cette chaîne sur PrestaShop 8 et 9 : détection des appels distants dans le thème et les modules, téléchargement et hébergement local des familles utilisées, réécriture des références et contrôle qu'aucune requête ne subsiste.
---
### PIM pour e-commerce mid-market : quand Akeneo devient rentable (vs CSV et back-office natif)
_Source :_ — _publié_ 2026-08-19
> À partir de 1 000 SKUs ou 200 SKUs en 3+ langues, la gestion par CSV devient le frein numéro 1 à la croissance d'une boutique PrestaShop. Akeneo domine le marché PIM européen avec trois éditions (Community open source, Growth, Enterprise). Les quatre indicateurs de bascule, le coût réel (50-80 K€ sur 12 mois), les alternatives Quable, Ergonode, Pimcore, et les pièges à éviter.
À quel moment la gestion de catalogue par CSV cesse-t-elle d'être viable ? La réponse standard est « à partir de 1 000 SKUs », mais la réalité est plus nuancée en 2026. Une boutique avec 500 SKUs en 4 langues, des déclinaisons riches (taille, couleur, packaging) et des spécifications techniques complexes peut très bien justifier un PIM. Une boutique avec 5 000 SKUs simples mono-langue peut tenir au CSV. Le bon indicateur n'est pas le volume brut, mais le coût d'opportunité de la gestion de catalogue actuelle.
Akeneo est le PIM (Product Information Management) le plus installé sur l'écosystème PrestaShop / Magento / Shopware en Europe. Cet article fait le point sur ce que change un PIM, le seuil de bascule, les alternatives à Akeneo et le coût réel de la mise en place en 2026.
## Le problème qu'un PIM résout
Sans PIM, la donnée produit vit éclatée :
- Description marketing : Word ou Google Docs envoyé par le service marketing.
- Spécifications techniques : tableur Excel maintenu par le service produit.
- Photos : Drive partagé du service création.
- Stock et prix : ERP ou PrestaShop directement.
- Traductions : Google Sheets envoyé à l'agence de traduction.
- Données Google Shopping : feed XML généré à part.
Chaque fois qu'un produit évolue (nouvelle photo, ajustement de la description, traduction à mettre à jour), le travail est dupliqué dans 4-6 endroits, avec un risque d'incohérence à chaque étape. Sur 50 produits évolutifs par mois, l'équipe perd 40-80 heures de travail répétitif. Sur 200 produits par mois, l'équipe est saturée.
Un PIM centralise la donnée produit dans une source de vérité unique. Toutes les destinations (PrestaShop, Google Shopping, marketplaces Amazon/ManoMano, catalogue PDF print) consomment depuis le PIM. Une mise à jour, une fois, propagée automatiquement partout.
## Le seuil de bascule en 2026
Quatre indicateurs convergents qui déclenchent l'investissement PIM :
1. **Catalogue ≥ 1 000 SKUs actifs** ou **200 SKUs en 3+ langues**. La complexité multilingue compte autant que le volume brut.
2. **2+ canaux de distribution** : PrestaShop + marketplace (Amazon, ManoMano, Cdiscount), ou PrestaShop + catalogue print. Chaque canal a ses contraintes (longueur de titre, formats d'images, attributs requis), donc multiplie le travail.
3. **Workflow d'enrichissement structuré** : un produit passe par plusieurs personnes (acheteur, marketing, traducteur, création photo, valideur). Sans PIM, la coordination par email est chronophage.
4. **Données structurées riches** : spécifications techniques détaillées, attributs requis pour les marketplaces (GTIN, taxonomie GS1, schéma .org product augmenté). PrestaShop natif est trop limité sur la modélisation.
Si trois de ces indicateurs sont cochés, un PIM est rentabilisé en 12-24 mois. Si seulement un est coché, le CSV peut suffire encore quelques années.
## Akeneo : les trois éditions en 2026
### Akeneo Community Edition (open source)
- Gratuit, open source, hostable en self-hosting.
- Fonctionnalités de base : modélisation produit, attributs personnalisés, multilingue, channels, import/export.
- Sans workflow avancé, sans DAM intégré, sans connecteurs natifs.
- Coût total : 5-15 K€ de déploiement initial + serveur dédié (50-150 €/mois) + maintenance dev.
### Akeneo Growth Edition (SaaS débridable)
- SaaS, partir de 25-30 K€/an.
- Inclut workflow, DAM, connecteurs marketplace.
- Limite : 50 K SKUs, 5 users.
- Cible : PME e-commerce 2-15 M€ de CA.
### Akeneo Serenity / Enterprise
- SaaS premium, à partir de 60-100 K€/an.
- SLA, SSO, audit log, gestion multi-marques.
- Cible : ETI / grands comptes à partir de 15 M€ de CA.
## Le connecteur Akeneo ↔ PrestaShop
Le connecteur Akeneo ↔ PrestaShop existe en deux versions :
- **Connecteur officiel Akeneo** : maintenu par l'éditeur, mais limité dans son mapping. Souvent insuffisant pour des catalogues complexes ou des modules tiers PrestaShop.
- **Connecteurs partenaires** : agences spécialisées (StudioForty9, Wakeo, Idanto en France) proposent des connecteurs sur mesure, souvent plus robustes pour des contextes B2B ou multi-shop.
Plan d'intégration typique :
1. Modéliser le catalogue dans Akeneo : familles, attributs, channels, locales.
2. Migrer les produits existants (un-shot, via API ou import CSV).
3. Mapper Akeneo → PrestaShop : quels attributs vers quelles tables (`product_lang`, `product_attribute`, `feature_value_lang`).
4. Définir la fréquence de synchronisation : temps réel via webhook, batch quotidien via cron, batch à la demande.
5. Tester sur un sous-ensemble (50 produits) avant bascule complète.
Budget réaliste : 15-40 K€ de développement connecteur + 5-15 K€ de migration / formation. Durée : 2 à 4 mois.
## Les alternatives à Akeneo en 2026
### Quable
PIM français SaaS pur, fort en mode et FMCG. Tarif à partir de 18 K€/an. Interface souvent jugée plus moderne qu'Akeneo Growth. Connecteur PrestaShop existant mais moins mature que celui d'Akeneo.
### Ergonode
PIM open source polonais en croissance. Architecture moderne (Vue.js, Symfony), bon modèle de données. Communauté plus restreinte qu'Akeneo. Pertinent pour les équipes tech qui veulent un open source maintenable.
### Pimcore
Plus qu'un PIM : DAM + CMS + e-commerce platform. Open source allemand, écosystème solide. Plus complexe à déployer mais plus complet. Pertinent quand le PIM s'accompagne d'un besoin DAM ou CMS fort.
### Sales Layer, inRiver
PIM SaaS internationaux. Tarif similaire à Akeneo Growth/Enterprise. À évaluer pour des contextes multi-pays multi-régions complexes.
## Le ROI d'un PIM mesuré en pratique
Sur des déploiements PIM terminés ces 18 derniers mois sur PrestaShop, les gains observés :
- **Temps de mise en ligne nouveaux produits** : passe typiquement de 2-4h par produit (avec déclinaisons, traductions, photos) à 30-60 minutes. Sur 100 nouveautés/mois, gain de 150-300h/mois soit 1-2 ETP.
- **Réduction des erreurs catalogue** : descriptions divergentes entre canaux, traductions oubliées, prix incohérents. Diminution de 70-90 %.
- **Lancement sur nouveau canal** : ouverture d'une marketplace (Amazon, ManoMano) passe de 6-12 semaines de préparation à 2-4 semaines (mapping channel uniquement).
- **SEO produit** : richesse des attributs structurés permet un Schema.org plus complet, gain CTR mesurable en SERP.
Pour une boutique à 3 M€/an de CA avec 5 000 SKUs et 3 langues, l'investissement PIM (50-80 K€ sur 12 mois) se rentabilise typiquement en 18-30 mois.
## Les pièges du déploiement PIM
### 1. Vouloir modéliser parfait avant de commencer
Erreur classique. L'équipe désigne 4 mois à définir un modèle « idéal ». Le projet meurt avant la migration. Approche correcte : modèle minimal viable, migration en 6 semaines, amélioration itérative ensuite.
### 2. Sous-estimer la gouvernance
Un PIM sans gouvernance devient un dépôt en vrac. Il faut : un Product Owner dédié, des règles de saisie documentées, un workflow de validation, des rapports de qualité de la donnée. Sans ça, on a remplacé le chaos Excel par du chaos PIM.
### 3. Faire l'impasse sur le DAM
Un PIM gère la donnée produit mais pas les fichiers média (photos, vidéos, schémas) de manière optimale. Sur des catalogues riches, ajouter un DAM (Akeneo Asset Manager, Bynder, Cloudinary) évite que le PIM serve de stockage photo douteux.
### 4. Ne pas former l'équipe
2-3 jours de formation par utilisateur, plus une certification interne pour les Power Users. Sans formation, le PIM est utilisé à 30 % de son potentiel et l'équipe retombe sur Excel.
### 5. Mal calibrer la sync vers PrestaShop
Une sync temps réel sur tout le catalogue à chaque modification saturera l'API PrestaShop et pénalisera les performances. Approche correcte : sync delta (uniquement les produits modifiés), avec batch nocturne pour la résynchronisation complète.
## Conclusion : un projet structurel, pas une optimisation
Un PIM est un projet d'infrastructure data, pas une optimisation tactique. Il ne se justifie qu'après avoir dépassé un seuil d'échelle (catalogue, langues, canaux). En dessous, le CSV bien organisé ou un import / export PrestaShop maîtrisé restent suffisants.
Au-dessus du seuil, l'absence de PIM devient un frein à la croissance : impossible d'ouvrir un nouveau canal sans projet de 3 mois, impossible de tenir la qualité catalogue sur 5 000+ SKUs, équipe saturée en tâches répétitives. Le bon moment pour investir, c'est juste avant que ce frein ne soit visible — typiquement quand la boutique passe de 1 M€ à 3 M€ de CA avec multiplication des canaux. Après, c'est rattraper du retard ; avant, c'est se préparer à grandir sans frottement.
---
### Comment trouver les liens cassés et images manquantes sur PrestaShop ?
_Source :_ — _publié_ 2026-08-19
> Sur un catalogue qui vit, les liens morts sont une conséquence normale de l'exploitation. Les six sources propres à PrestaShop, ce qu'un crawler externe ne voit pas, comment prioriser par valeur et les trois décisions possibles pour chaque URL.
Sur un catalogue de plusieurs milliers de références qui vit depuis quelques années, les liens morts ne sont pas un accident : ils sont la conséquence normale de l'exploitation. Produits retirés, catégories réorganisées, images remplacées, changement de thème. Chacune de ces opérations laisse des références vers des ressources qui n'existent plus.
Le problème n'est pas esthétique. Un visiteur qui tombe sur une page d'erreur repart, et un moteur qui rencontre trop de liens morts réduit progressivement la fréquence à laquelle il explore le site.
## Les sources de 404 propres à PrestaShop
Six causes couvrent la quasi-totalité des cas, et elles sont toutes prévisibles.
1. **Le produit désactivé.** Décocher « Activé » retire le produit du front sans rien rediriger. Les liens externes, les partages sur les réseaux et les résultats Google continuent de pointer dessus.
2. **Le produit supprimé.** Même effet, sans possibilité de retour en arrière. C'est le cas le plus coûteux quand la fiche avait acquis un positionnement.
3. **Le changement d'URL simplifiée.** Modifier le champ URL simplifiée d'un produit ou d'une catégorie casse instantanément toutes les URL existantes, sans redirection automatique.
4. **La catégorie déplacée ou fusionnée.** Le chemin change, et avec lui l'URL complète si votre structure d'URL inclut l'arborescence.
5. **Les liens en dur dans les descriptions.** Une description produit ou une page CMS qui référence un autre produit par une URL écrite à la main survit rarement à deux ans d'exploitation.
6. **Les images absentes du disque.** La base référence une image dont le fichier a disparu, ou dont la déclinaison de taille n'a jamais été régénérée.
## Le cas particulier des images
Une image manquante ne renvoie pas toujours une erreur visible. Selon la configuration, PrestaShop affiche une image de remplacement, ce qui masque le problème côté visiteur tout en le laissant intact côté données.
Deux situations à distinguer. Le fichier source a disparu du dossier des images : l'ensemble des déclinaisons est perdu. Ou le fichier source existe mais les miniatures n'ont pas été régénérées après un changement de thème : le produit s'affiche correctement en fiche mais pas en listing, ou l'inverse.
La régénération des miniatures depuis **Design > Paramètres des images** traite le second cas. Elle est longue sur un gros catalogue, et elle échoue silencieusement en cas de limite mémoire atteinte, ce qui explique les régénérations partielles.
## Scanner : ce qu'un outil externe ne voit pas
Un crawler externe explore ce qui est accessible depuis la page d'accueil en suivant les liens. Il trouve donc les liens cassés dans la navigation et les descriptions.
Il ne voit pas trois choses. Les produits désactivés qui recevaient du trafic, puisqu'ils ne sont plus liés nulle part. Les images référencées en base mais absentes du disque, si l'affichage est masqué par une image de remplacement. Et les URL orphelines qui reçoivent encore des visites depuis l'extérieur, information qui se trouve dans vos logs serveur ou dans la Search Console, pas dans un crawl.
Un scan interne, qui interroge la base plutôt que le front, complète donc le crawl externe plutôt qu'il ne le remplace.
## Prioriser : par valeur, pas par volume
Un catalogue mal tenu peut afficher plusieurs milliers d'erreurs. Les traiter dans l'ordre de la liste est une perte de temps. Trois critères de tri, par ordre d'importance.
- **Le trafic entrant réel** sur l'URL cassée, mesuré sur les trente derniers jours. Une 404 que personne ne visite ne coûte rien.
- **Les liens externes** pointant vers elle. Une page référencée par un site tiers représente une valeur acquise que vous perdez à chaque visite non redirigée.
- **Le positionnement passé** de la page dans les résultats de recherche, visible dans la Search Console.
Dans la pratique, une vingtaine d'URL concentrent souvent l'essentiel de la valeur perdue.
## Trois décisions possibles
Pour chaque URL cassée à traiter, une seule des trois options s'applique.
**Rediriger en 301** vers la page la plus proche : le produit remplaçant, la déclinaison équivalente, ou à défaut la catégorie parente. Éviter la redirection systématique vers l'accueil, qui est traitée comme une erreur douce et n'apporte rien au visiteur.
**Restaurer** la page quand le produit est simplement épuisé mais reviendra. Une fiche en rupture avec une alerte de retour en stock vaut infiniment mieux qu'une 404.
**Retourner un 410** quand la ressource a définitivement disparu et n'a pas d'équivalent. Ce code indique explicitement une suppression volontaire et accélère le retrait de l'index.
## En faire un contrôle récurrent
Le nettoyage ponctuel ne tient pas. Un mois d'exploitation normale suffit à recréer des dizaines de liens morts. Le contrôle doit être périodique, mensuel sur un catalogue actif, et son résultat comparé au précédent pour repérer les opérations qui en génèrent le plus.
Le effectue ce scan depuis le back-office sur PrestaShop 8 et 9 : liens internes cassés, images manquantes en base et sur disque, rapport priorisé et suivi entre deux analyses.
---
### Transformer un devis en commande sur PrestaShop : le workflow complet
_Source :_ — _publié_ 2026-08-18
> Entre le devis accepté et la commande créée, il se passe des choses : le prix bouge, le stock part, personne ne sait quelle version le client a validée. Les six états d'un devis, la durée de validité, l'acompte et la question de la réservation de stock.
Sur une boutique B2B, le devis n'est pas un document décoratif : c'est l'objet autour duquel tourne la relation commerciale. Sa transformation en commande est le moment où tout peut se perdre, parce que le prix a bougé, parce que le stock n'était pas réservé, ou parce que personne ne sait quelle version du devis le client a acceptée.
PrestaShop ne connaît que la commande. Voici le workflow à construire autour.
## Les six états d'un devis
Un devis n'est pas un objet à deux positions. Six états couvrent la totalité des situations réelles.
1. **Brouillon** : construit côté marchand, non visible du client. C'est là que le commercial ajuste les remises.
2. **Envoyé** : transmis au client, il devient une offre ferme et engage vos prix pour la durée de validité.
3. **Accepté** : le client a validé. Le document se fige, plus aucune modification n'est possible.
4. **Refusé** : à conserver, avec le motif quand vous l'avez. C'est votre meilleure source d'information sur votre positionnement tarifaire.
5. **Expiré** : la date de validité est dépassée sans réponse. L'état doit basculer automatiquement.
6. **Converti** : une commande a été créée à partir du devis, avec un lien permanent entre les deux.
L'erreur classique consiste à fusionner « accepté » et « converti ». Entre les deux, il peut s'écouler plusieurs jours, le temps d'un bon de commande client ou d'un virement d'acompte, et vous devez savoir combien de devis sont dans cet intervalle.
## La durée de validité n'est pas une formalité
Un devis sans date limite est une offre à durée indéterminée. Trois risques concrets suivent.
Vos prix d'achat évoluent, mais vous restez engagé sur le prix affiché. Le stock que vous aviez au moment du devis a été vendu à d'autres clients. Et sur des produits importés, le taux de change a bougé.
Trente jours est la durée usuelle. Ce qui compte davantage que le chiffre, c'est que l'échéance apparaisse sur le document, que le passage à l'état expiré soit automatique, et qu'une relance parte quelques jours avant. Un devis relancé à J-3 de son expiration se transforme nettement plus souvent qu'un devis oublié.
## L'acompte
Sur des montants significatifs ou des produits sur mesure, l'acompte protège votre trésorerie et engage le client. Trois points à cadrer.
- **Le montant** : pourcentage ou forfait, à définir par gamme plutôt qu'au cas par cas.
- **La facturation** : un acompte encaissé donne lieu à une facture d'acompte, qui sera déduite de la facture finale. Ce n'est pas une simple ligne de paiement.
- **Le sort en cas d'annulation** : à écrire dans les conditions du devis, pas à improviser au moment du litige.
## La conversion, et la question du stock
Au moment de la conversion, un arbitrage doit être tranché : réservez-vous le stock dès l'acceptation du devis, ou seulement à la création de la commande ?
Réserver dès l'acceptation évite d'annoncer une disponibilité que vous ne pouvez pas tenir. Cela immobilise en revanche du stock sur des affaires qui peuvent ne jamais se conclure. Le compromis courant consiste à réserver après encaissement de l'acompte, ce qui filtre les intentions molles.
Sur le plan documentaire, la commande doit conserver le numéro du devis d'origine. C'est ce lien qui permet de retrouver, six mois plus tard, sur quelle base tarifaire une remise a été accordée.
## Ce que le devis ne doit pas être
Deux raccourcis répandus posent problème.
**Le devis n'est pas une commande à l'état d'attente.** Créer une commande PrestaShop avec un statut « devis » semble pratique, mais cela pollue vos statistiques, vos exports comptables et vos relances. Une commande non validée reste une commande dans les compteurs.
**Le devis n'utilise pas la numérotation des factures.** Il lui faut sa propre séquence, avec un préfixe distinct. Mélanger les deux crée une rupture dans la numérotation comptable, exactement le point que le fisc vérifie.
## Ce qui déclenche le passage à un outil
Un devis par semaine se traite très bien dans un tableur et un PDF envoyé à la main. Trois signaux indiquent que le seuil est franchi : vous ne savez plus combien de devis sont en attente de réponse, vous découvrez des devis expirés que personne n'a relancés, et la ressaisie des lignes au moment de la commande génère des erreurs de prix.
À ce stade, le coût du traitement manuel se compte en affaires perdues, pas en heures.
## Mettre en place le workflow
Le couvre cette chaîne sur PrestaShop 8 et 9 : demande depuis la fiche produit ou le panier, gestion des états et de la durée de validité, relance avant expiration, et conversion en commande sans ressaisie avec conservation du lien entre les deux documents.
---
### Fraude au paiement et chargebacks : 3DS2, score de risque et la mécanique anti-fraude PrestaShop
_Source :_ — _publié_ 2026-08-18
> Un chargeback à 80 € coûte en réalité 120 à 200 € quand on compte les frais processeur, pénalités réseau et coût RH. Pour les secteurs à risque (vape, électronique, contenus numériques), le seuil critique Visa de 0,9 % est franchi en un trimestre sans mécanique anti-fraude. 3DS2, scoring de fraude, friendly fraud et la défense en profondeur à mettre en place sur PrestaShop.
Le coût d'un chargeback en 2026 ne se limite pas à la perte du montant de la commande. Pour une transaction à 80 € contestée, le marchand encaisse typiquement : remboursement intégral de la transaction, frais de chargeback du processeur (15 à 50 €), pénalité du réseau si taux de chargeback dépassé (Visa Dispute Monitoring, Mastercard Excessive Chargeback), perte de la marchandise, et coût interne de gestion du litige. Le coût complet : 120 à 180 € pour une transaction de 80 €. Au-delà d'un certain seuil, le processeur menace de clôturer le compte marchand.
En 2026, le taux de chargeback typique d'une boutique PrestaShop B2C est de 0,3 à 0,8 % du nombre de transactions. Dans certains secteurs à risque (vape, électronique, contenus numériques, cosmétique) il monte facilement à 1,5-3 %. Le seuil critique du réseau Visa est 0,9 % à partir duquel des pénalités sont activées. La mise en place d'une mécanique anti-fraude propre n'est pas un confort — c'est une condition de survie pour ces secteurs.
## 3DS2 et SCA : le cadre obligatoire depuis 2021
Depuis l'entrée en vigueur complète de la PSD2 en 2021, l'authentification forte (SCA, Strong Customer Authentication) est obligatoire sur la majorité des transactions e-commerce en UE. Concrètement, le 3D Secure version 2 :
- Déclenche une vérification supplémentaire (biométrie sur l'app bancaire, code SMS) au moment du paiement.
- Transfère la responsabilité du chargeback au porteur de carte (et donc à sa banque émettrice) pour les fraudes « carte volée ».
- Augmente le taux d'échec de paiement de 5 à 15 % par friction utilisateur additionnelle.
Le 3DS2 n'élimine pas tous les chargebacks. Il reste responsable d'environ 60 % de la fraude tiers (carte volée), mais ne couvre pas la **friendly fraud** (l'acheteur légitime conteste ensuite la transaction) qui représente 15 à 35 % des chargebacks selon le secteur.
### Exemptions SCA à connaître
- **Low Value Transaction (LVT)** : transactions inférieures à 30 € peuvent être exemptées (avec limite cumulée par carte).
- **Transaction Risk Analysis (TRA)** : si le processeur a un score de fraude bas (TRA Acquirer Reference Rate sous 0,01 %), il peut demander l'exemption.
- **Whitelisting marchand** : le porteur peut autoriser un marchand spécifique à transiger sans SCA.
- **Merchant Initiated Transactions (MIT)** : paiements récurrents après initialisation valide.
Bien configurer ces exemptions réduit la friction sans dégrader la sécurité. C'est un sujet à piloter avec le payment gateway.
## Le scoring de fraude : la couche au-dessus du 3DS2
3DS2 protège contre les fraudes « carte volée », mais ne détecte ni les fraudeurs sophistiqués (utilisant des cartes légitimes avec SCA réussie) ni la friendly fraud. La couche complémentaire est le scoring de fraude : analyse de signaux pour calculer une probabilité de fraude avant la capture.
### Signaux scorés
- **Cohérence géographique** : adresse de facturation France, IP Roumanie, livraison Belgique. Score augmente.
- **Vélocité** : nombre de transactions tentées sur la même carte ou IP dans les dernières 24h.
- **BIN check** : la banque émettrice de la carte est-elle cohérente avec l'adresse de facturation ?
- **Comportement de navigation** : temps passé sur le site, parcours, copier-coller du numéro de carte (signal de bot).
- **Device fingerprinting** : empreinte du navigateur, partagée avec d'autres comptes ?
- **Email pattern** : adresse jetable, créée récemment, format suspect.
- **Adresse de livraison** : reshipping (hôtels, points relais peu utilisés, services de transitaire illégitimes).
- **Historique acheteur** : nouveau compte vs récurrent, premier paiement vs commandes répétées.
### Trois familles de solutions en 2026
**Pure-players spécialisés** : Signifyd, Riskified, Forter, NoFraud. Garantie sur les chargebacks frauduleux (le fournisseur paie le chargeback s'il a approuvé la transaction). Tarif : 0,5 à 1,5 % du CA transactionnel. ROI principal pour des CA dépassant 2 M€/an et des secteurs à risque.
**Outils intégrés aux payment gateways** : Adyen RevenueProtect, Stripe Radar, Mollie Fraud Detection. Tarif : 0,1 à 0,3 % du CA. Moins puissant qu'un pure-player mais quasi sans intégration supplémentaire. Suffisant pour 80 % des boutiques mid-market.
**Règles maison** : un module PrestaShop avec quelques règles simples (refus des emails jetables, blocage des IPs anonymisantes, plafond sur première commande). Coût : 0 à 5 K€ de dev. Capte 30 à 50 % de la fraude basique, manque la fraude sophistiquée.
## Le coût complet d'un chargeback en détail
Sur une transaction à 80 € contestée et perdue par le marchand :
- Remboursement de la transaction au porteur : **-80 €**
- Frais de chargeback du processeur (Stripe, Adyen, Mollie) : **-15 à -50 €**
- Coût du produit perdu (le marchandise est livrée) : **-marge brute du produit**
- Coût logistique : **-3 à -8 €**
- Coût interne de gestion du litige (1 à 3h de back-office) : **-30 à -90 €**
Total : 120-200 € pour une transaction de 80 €. Sur des boutiques où le taux de chargeback grimpe à 2 %, le coût total est 2,5-4 % du CA — souvent plus que la marge nette.
### Le triple effet d'un taux élevé
- Pénalité Visa Dispute Monitoring à partir de 0,9 % : 25-50 $ par chargeback en pénalité réseau.
- Mastercard Excessive Chargeback Program au-dessus de 1,5 % : 100 $ par chargeback.
- Clôture du compte marchand par le processeur si taux soutenu au-dessus de 1 %.
## La friendly fraud : 15 à 35 % des chargebacks
La friendly fraud est commise par l'acheteur légitime, pas par un fraudeur tiers. Scénarios courants :
- « Je n'ai pas reçu le produit » alors qu'il a été livré (même avec preuve).
- « Je n'ai pas autorisé cette transaction » après une commande sous emprise ou par un enfant.
- « Le produit ne correspond pas à la description » sur des produits parfaitement conformes.
- « La transaction est récurrente non autorisée » sur des abonnements pourtant explicitement consentis.
Le 3DS2 ne protège pas contre la friendly fraud. La défense passe par :
- Preuve de livraison signée (Mondial Relay, Chronopost expert).
- Trace de consentement claire pour les abonnements (double opt-in archivé).
- Descriptions et photos produit documentées et archivées.
- Réponse rapide au litige (sous 7 jours) avec dossier complet.
- Pour les récidivistes (même email, même device), blacklist progressive.
## Implémentation sur PrestaShop 2026
### Couche 1 : payment gateway bien configuré
- Activer le 3DS2 avec exemptions LVT et TRA correctement configurées.
- Activer le scoring intégré du processeur (Stripe Radar, Adyen RevenueProtect, Mollie Fraud).
- Configurer des seuils : refus auto au-dessus d'un score, review manuelle entre deux seuils, accept en dessous.
- Surveiller les KPIs via le dashboard du processeur.
### Couche 2 : pre-screening PrestaShop
- Module ou code custom vérifiant : email jetable (via API Kickbox ou Emailable), IP VPN/Tor (via MaxMind, IPQualityScore), adresse cohérente (BIN check).
- Blocage en pre-checkout, avant même la tentative de paiement. Évite les frais de tentative et les patterns détectés par le réseau.
- Plafond sur première commande (par exemple 200 € max pour un nouveau compte) qui décourage les fraudeurs en volume.
### Couche 3 : monitoring continu
- Dashboard hebdo : taux de chargeback par produit, par moyen de paiement, par source de trafic.
- Alerte automatique dès que le taux mensuel dépasse 0,5 %.
- Réunion mensuelle pour passer en revue les chargebacks et identifier les patterns.
## Quand investir dans un pure-player anti-fraude
Riskified, Signifyd, Forter coûtent 0,5 à 1,5 % du CA. La question est : leur garantie de chargeback (ils paient si la transaction qu'ils ont approuvée est contestée pour fraude) compense-t-elle le coût ?
Règle simple : si le taux de chargeback actuel dépasse 0,8 % et que le CA dépasse 2 M€/an, le ROI est presque toujours positif. En dessous, l'outil intégré au payment gateway suffit pour la majorité des cas.
## Les pièges à éviter
### 1. Refuser trop large pour éviter la fraude
Un scoring trop strict refuse de vraies transactions (false positives). Sur 100 transactions refusées à tort, c'est 100 paniers perdus et autant de clients qui n'essaieront plus. L'arbitrage est économique : taux de fraude actuel vs taux de false positive accepté. À piloter avec les KPIs.
### 2. Ne pas répondre aux litiges
Un chargeback non contesté est perdu par défaut. Sur les friendly frauds avec preuve de livraison et trace de consentement, le marchand gagne 40 à 60 % des litiges quand il répond proprement. À ne pas négliger — c'est 1-3 % du CA en jeu.
### 3. Confondre tentative et capture
Une tentative de paiement refusée par 3DS2 n'est pas un chargeback. Distinction importante pour le monitoring : ne pas confondre taux d'échec authentification, taux d'échec paiement, taux de fraude détectée, taux de chargeback.
### 4. Configurer 3DS2 sans tester
Sandbox du processeur indispensable. Sur une cartouche FR, AT, DE, ES, le comportement de SCA peut différer (banque émettrice, mode d'authentification). Tester sur plusieurs cartes test fournies par Stripe / Adyen / Mollie avant mise en production.
### 5. Sous-estimer le coût en RH
Gérer 50 chargebacks par mois sans outil = 2 jours/semaine d'un back-officer. C'est un coût caché. À partir d'un certain volume, externaliser via Chargeback911, Chargebacks Gurus ou un pure-player intégré devient rentable.
## Conclusion : la défense en profondeur, pas une seule couche
La fraude au paiement en 2026 ne se traite pas avec un seul outil mais avec une défense en profondeur : 3DS2 correctement configuré, scoring du payment gateway, pre-screening PrestaShop, monitoring hebdomadaire, réponse systématique aux litiges. Pour les secteurs à risque, une couche pure-player anti-fraude.
Le bon arbitrage coût / bénéfice dépend du taux de chargeback actuel et du secteur. Pour une boutique standard B2C à 0,3 % de chargeback, l'outil intégré au gateway suffit. Pour une boutique vape ou électronique à 1,5 %, un pure-player se justifie. Dans tous les cas, mesurer le coût complet du chargeback (pas seulement le montant transactionnel) reste l'étape qui débloque les bons arbitrages — et la plus souvent oubliée.
---
### Automatiser les demandes d'avis après commande sur PrestaShop : méthode complète
_Source :_ — _publié_ 2026-08-18
> Les clients satisfaits n'écrivent pas spontanément, les mécontents si. Automatiser la demande d'avis rétablit la représentativité : délai calé sur l'usage réel, séquence en deux emails, notation en un clic et cadre légal à respecter.
La grande majorité des clients satisfaits ne laissent jamais d'avis spontanément. Ceux qui écrivent sans y être invités sont majoritairement des mécontents, ce qui explique la note moyenne étrangement basse des boutiques qui ne sollicitent pas. Automatiser la demande ne sert pas à gonfler la note, mais à rétablir la représentativité.
## Le délai : après l'usage, pas après la livraison
C'est le paramètre qui détermine à la fois le taux de réponse et la qualité des avis. Solliciter à la livraison produit des avis sur l'emballage et le transporteur. Solliciter trop tard produit un taux de réponse en chute libre.
La règle utile : envoyer la demande une fois que le client a réellement utilisé le produit. Le délai varie donc selon ce que vous vendez.
- **Consommable ou produit d'usage immédiat** : 3 à 5 jours après livraison.
- **Textile, chaussure** : 7 à 10 jours, le temps de l'essayage et d'un premier lavage.
- **Équipement, outillage, électroménager** : 15 à 30 jours, le temps d'un usage significatif.
- **Produit saisonnier ou d'occasion rare** : le délai calendaire ne veut rien dire, préférez une sollicitation à date fixe après la saison.
Si votre catalogue mélange ces cas, un délai unique appliqué à tout le catalogue est un compromis médiocre. Le délai devrait se paramétrer par catégorie.
## La séquence en deux emails
Un envoi unique capte une partie des réponses. Une relance sept jours plus tard, adressée uniquement aux non-répondants, ajoute typiquement entre un tiers et la moitié du volume du premier envoi. Au-delà de deux messages, le rendement s'effondre et le risque de plainte augmente.
La relance ne doit pas être une copie du premier message. Elle est plus courte, elle mentionne le produit concerné, et elle donne une raison : aider les prochains acheteurs à choisir.
## Le contenu de l'email
Trois éléments comptent, le reste est du décor.
**Le rappel visuel du produit.** Un client qui a commandé trois articles ne sait plus lequel vous lui demandez de noter. L'image et le nom du produit dans le message évitent la confusion et la réponse générique.
**La notation directement dans l'email.** Cinq étoiles cliquables, chacune menant à un formulaire déjà prérempli avec la note choisie. Cette seule mécanique change le taux de réponse davantage que tout le reste, parce qu'elle transforme un formulaire en un clic.
**Un formulaire court.** Note, titre facultatif, commentaire libre. Chaque champ supplémentaire coûte des soumissions. Les critères multiples, prix, qualité, livraison, ne servent que si vous les exploitez réellement.
## Le cadre légal, en clair
Trois obligations à respecter, régulièrement contrôlées.
1. **Informer sur le traitement des avis.** Vous devez indiquer si les avis font l'objet d'un contrôle, et si oui lequel, ainsi que la date de publication et les critères de classement. Cette information doit être accessible depuis les pages affichant des avis.
2. **Ne pas filtrer les avis négatifs.** Supprimer un avis parce qu'il est défavorable est une pratique commerciale trompeuse. La modération ne peut porter que sur des motifs objectifs : propos injurieux, hors sujet, données personnelles, contenu manifestement faux.
3. **Déclarer toute contrepartie.** Un bon de réduction contre un avis n'est pas interdit en soi, mais il doit être annoncé publiquement, et il ne peut être conditionné à une note favorable.
Le point le plus souvent raté est le premier. Une page « Comment nous traitons les avis » de dix lignes règle la question, et elle rassure au passage.
## L'avis vérifié, et ce que le terme recouvre
Un avis est vérifié quand vous pouvez démontrer que son auteur a réellement acheté le produit. Techniquement, cela veut dire lier chaque avis à une commande, et n'ouvrir la possibilité de noter qu'aux clients ayant reçu leur colis.
Cette contrainte réduit le volume d'avis et augmente leur valeur. Elle rend aussi la mention « avis vérifiés » utilisable sans risque, ce qui n'est pas le cas d'un formulaire ouvert à tous.
## Répondre, y compris aux bons avis
La réponse du marchand est lue par les futurs acheteurs bien plus que par l'auteur de l'avis. Sur un avis négatif, une réponse factuelle et non défensive neutralise l'effet du commentaire. Sur un avis positif, une réponse courte montre qu'un humain suit la boutique.
Fixez un délai de réponse, quarante-huit heures ouvrées est un bon repère, et tenez-le. Un avis négatif sans réponse pendant trois mois fait plus de dégâts que l'avis lui-même.
## Le volume nécessaire pour les étoiles Google
Les avis produits balisés en données structurées peuvent faire apparaître des étoiles dans les résultats de recherche. Deux conditions pratiques : un balisage correct au niveau de chaque fiche, et un volume suffisant pour que la note soit crédible. Une fiche avec un seul avis à cinq étoiles n'obtient généralement rien.
C'est un argument supplémentaire pour automatiser la collecte plutôt que d'attendre. Le volume met des mois à se constituer, et il ne se rattrape pas.
## Mettre en place la collecte
Le gère cette chaîne sur PrestaShop 8 et 9 : sollicitation automatique avec délai paramétrable, relance des non-répondants, notation en un clic depuis l'email, rattachement à la commande et balisage des données structurées.
---
### Vente flash avec compte à rebours sur PrestaShop
_Source :_ — _publié_ 2026-08-17
> Un compte à rebours figé par le cache ou décalé de deux heures détruit la contrainte de temps sur laquelle repose la vente flash. Les trois pièges techniques, la règle de calcul côté client, et le point de conformité qui limite la répétition des opérations.
Une vente flash repose sur une contrainte de temps crédible. Si le compte à rebours affiche une heure fausse, se fige, ou repart à zéro à chaque rechargement, la contrainte disparaît et l'opération devient une simple promotion. Les trois pièges qui produisent ce résultat sont techniques, connus, et pourtant rencontrés à chaque saison commerciale.
## Piège 1 : le fuseau horaire
Trois horloges interviennent dans une vente flash, et elles ne sont presque jamais alignées.
- **Le serveur**, souvent réglé en UTC chez les hébergeurs mutualisés comme sur les conteneurs.
- **PrestaShop**, qui possède son propre réglage dans les paramètres de la boutique et qui l'utilise pour interpréter les dates de début et de fin.
- **Le navigateur du client**, réglé sur le fuseau de sa machine.
Une promotion saisie pour 20 h dans le back-office démarre à 22 h si le serveur est en UTC et la boutique en heure d'été française, ou l'inverse selon la façon dont la date est enregistrée. Le contrôle est simple : programmez une vente de test à cinq minutes et vérifiez qu'elle démarre à l'heure attendue. Faites ce test avant chaque grande opération, pas seulement à l'installation, parce qu'un changement d'hébergement ou un passage à l'heure d'hiver suffit à décaler l'ensemble.
Décidez aussi de la référence annoncée au client. Sur une boutique multilingue vendant en Europe, la mention « fin à 23 h 59 heure de Paris » évite les réclamations des clients d'autres fuseaux.
## Piège 2 : le cache
C'est le piège le plus coûteux. Une page mise en cache conserve le compte à rebours tel qu'il était au moment de la génération. Le premier visiteur voit deux heures restantes, et tous les suivants voient la même chose pendant toute la durée de vie du cache.
La règle est de ne jamais calculer le temps restant côté serveur. Le serveur transmet uniquement le _timestamp de fin_, et le compte à rebours se calcule dans le navigateur à partir de l'horloge du client. Le HTML mis en cache reste alors valide.
Un détail complète le dispositif : l'horloge du visiteur peut être fausse. Si l'écart avec le serveur dépasse quelques minutes, le compte à rebours affiche un temps différent de la réalité, et le client peut voir « 3 minutes restantes » alors que la promotion est déjà close. Transmettre également l'heure serveur au chargement, et travailler sur l'écart entre les deux, règle ce cas.
Reste la purge. Au démarrage comme à la fin de l'opération, le cache des pages produit et catégorie doit être vidé, sinon les prix affichés restent ceux d'avant. Programmez cette purge plutôt que de compter sur une intervention manuelle à minuit.
## Piège 3 : la fin de l'opération
Une vente flash mal terminée coûte plus cher qu'une vente flash mal lancée. Trois vérifications à prévoir dès la configuration.
1. **Le prix revient** au tarif normal automatiquement, sans action manuelle. Une date de fin sur le prix spécifique, pas une suppression prévue le lendemain matin.
2. **Le badge et le compte à rebours disparaissent.** Un bandeau « Vente flash » figé sur une fiche vendue au prix plein est le symptôme le plus visible d'une boutique mal tenue.
3. **Les paniers en cours.** Un client qui a ajouté le produit à 23 h 58 et valide à 00 h 02 paie le prix plein sans en être averti. Décidez de la règle et affichez-la : soit le prix du panier est recalculé avec un message clair, soit vous accordez une tolérance de quelques minutes.
## Le stock, et l'honnêteté de l'affichage
Une vente flash combine deux raretés : le temps et la quantité. Afficher les unités restantes augmente le taux de conversion, à une condition : que le chiffre soit réel. Un compteur décoratif qui redescend tout seul est une pratique commerciale trompeuse, et elle se repère en quelques rechargements.
Si vous limitez la quantité vendue en promotion sans limiter le stock du produit, prévoyez le comportement de bascule : à l'épuisement du quota, le produit reste vendable au prix normal, et l'affichage doit le refléter immédiatement.
## La relance email
Deux envois suffisent et fonctionnent mieux qu'une campagne étalée : un au lancement, un à quelques heures de la fin. Le second génère habituellement plus de commandes que le premier, parce qu'il s'adresse à des personnes déjà informées et qu'il ajoute la seule chose qui manquait, l'échéance.
Ciblez le second envoi sur les non-acheteurs de la période, sinon vous relancez des clients qui viennent de commander.
## Le point Omnibus
Une vente flash affiche un prix barré, donc une annonce de réduction. Le prix de référence à afficher est le prix le plus bas pratiqué au cours des trente derniers jours, pas le prix catalogue habituel. Sur des opérations flash répétées, ce point se retourne rapidement contre vous : la troisième vente flash du mois ne peut plus se référer au prix plein, puisque celui-ci n'a pas été le plus bas pratiqué.
C'est un argument concret en faveur d'opérations espacées plutôt que d'un rythme hebdomadaire.
## Mettre en place l'opération
Le gère ces points sur PrestaShop 8 et 9 : compte à rebours calculé côté client et compatible avec le cache, gestion du fuseau, quota de stock dédié, retour automatique au prix normal et nettoyage des badges à l'échéance.
---
### Avis produits vérifiés en 2026 : NF ISO 20488, fin du fake review et workflow conforme sur PrestaShop
_Source :_ — _publié_ 2026-08-17
> Depuis le Digital Services Act et le décret de janvier 2025, héberger des avis non vérifiés coûte cher : amendes DGCCRF jusqu'à 6 % du CA mondial pour pratique commerciale trompeuse. La conformité passe par la norme NF ISO 20488 et un workflow auditable. Comparatif des solutions Avis Vérifiés, Trustpilot, eKomi, Trusted Shops sur PrestaShop, plus l'option DIY avec son vrai coût caché.
Pendant dix ans, la collecte d'avis produits sur PrestaShop a été le terrain de toutes les approximations : avis modérés à discrétion, avis fictifs achetés en lot, modules tiers sans traçabilité de l'acheteur. En 2026, c'est terminé. Le Digital Services Act, le décret français de janvier 2025 et la norme NF ISO 20488 (qui remplace l'ancienne NF Z74-501) ont structuré le cadre. Les premières amendes DGCCRF sont tombées en 2025 sur des boutiques mid-market : jusqu'à 6 % du chiffre d'affaires mondial pour pratique commerciale trompeuse.
Pour autant, les avis produits restent un levier SEO et conversion incontournable : +12 à +35 % de conversion sur fiches produit avec avis bien affichés, jusqu'à +18 % de CTR en SERP avec les étoiles Schema.org. Cet article fait le point sur le cadre 2026, la certification NF ISO 20488, le comparatif des solutions disponibles sur PrestaShop, et le workflow qui permet de capter le levier sans tomber sous la sanction.
## Le cadre légal en 2026
### NF ISO 20488 : la norme de référence
La norme NF ISO 20488, publiée par l'AFNOR et reconnue au niveau international, définit les exigences pour la collecte, modération et publication d'avis consommateurs en ligne. Les exigences principales :
- **Identification de l'auteur** : impossible de publier un avis anonyme. L'auteur doit être identifiable (au moins par email vérifié et idéalement par lien à une commande effective).
- **Traçabilité achat** : chaque avis doit pouvoir être rattaché à une commande, ou clairement signalé comme « non vérifié ».
- **Modération transparente** : critères publics, droit de réponse de l'auteur en cas de rejet, conservation des avis négatifs (pas de suppression sélective).
- **Conservation de la preuve** : pendant 13 mois minimum, l'historique doit permettre d'auditer toute publication ou modération.
- **Affichage clair** : note moyenne accompagnée du nombre d'avis, distinction visible entre avis vérifiés et non vérifiés s'il y en a.
### Digital Services Act et décret français 2025
Le DSA, applicable à toutes les plateformes en UE depuis 2024, qualifie comme « pratique commerciale déloyale » l'affichage d'avis sans contrôle de vérification. Le décret français de janvier 2025 a précisé les sanctions : avertissement DGCCRF, amende administrative jusqu'à 75 000 € en première instance, ouverture d'une procédure pénale pour pratique commerciale trompeuse en cas de récidive, avec amende jusqu'à 6 % du CA mondial du groupe.
Les premières condamnations 2025 ont visé des boutiques mid-market entre 5 et 50 M€ de CA. Le ticket d'entrée est désormais clairement franchi.
## Quatre solutions tierces certifiées en 2026
Sur PrestaShop, quatre solutions dominent le marché avec une certification NF ISO 20488 active.
### Avis Vérifiés (NetReviews / Skeepers)
- Leader historique en France, intégré sur 50 000+ boutiques.
- Module officiel PrestaShop 8/9, intégration plug-and-play.
- Tarif : 65-250 €/mois selon volume, avec engagement annuel.
- Atouts : certification AFNOR depuis 2014, base d'avis cross-shop (Skeepers), Google Seller Ratings.
- Limites : prix élevé sur petits volumes, interface modération vieillissante.
### Trustpilot
- Leader européen, fort en UK / DACH, présence FR croissante.
- Intégration via module officiel + widget JS.
- Tarif : 0 € en free (limité), 200-2000 €/mois en plans payants.
- Atouts : notoriété marque, écosystème mature, API riche.
- Limites : modération limitée en free, droit de réponse complexe, conflits réguliers sur des avis suspects difficiles à supprimer.
### eKomi
- Très présent en DACH, croissance France.
- Module PrestaShop officiel.
- Tarif : 89-499 €/mois.
- Atouts : double validation auteur (call et email), proche du référentiel NF ISO 20488.
- Limites : interface en anglais, support FR limité.
### Trusted Shops
- Très implanté DACH, en croissance France.
- Module officiel, intégration buy-protection en complément.
- Tarif : 99-490 €/mois selon volume commande.
- Atouts : label de confiance reconnu en Allemagne, écosystème complet (avis + garantie acheteur + médiation).
- Limites : moins reconnu en France pour le SEO local.
## L'option DIY : moins chère, plus risquée
Plusieurs modules PrestaShop tiers proposent une collecte d'avis maison, sans certification AFNOR : DataFirefly dfreviews, ProductComments natif PrestaShop, modules de l'Addons Marketplace. Avantages : coût récurrent zéro ou très faible, contrôle total de l'interface et de la donnée.
Inconvénients réels en 2026 :
- Pas de certification AFNOR : en cas de contrôle DGCCRF, charge de la preuve sur le marchand. Doit pouvoir démontrer le respect de la norme par audit interne.
- Google Seller Ratings non accessible : les étoiles boutique en SERP nécessitent un fournisseur certifié partenaire Google.
- Effort de conformité interne : modération documentée, archivage 13 mois, workflow rejet avec droit de réponse, distinction vérifiés / non vérifiés.
Le DIY est donc défendable si :
- Le marchand met en place un workflow conforme NF ISO 20488 documenté (modèle interne d'audit, conservation des données, modération transparente).
- Le volume d'avis est faible (sous 500/an) et le risque DGCCRF perçu comme limité.
- Les étoiles SERP Google ne sont pas une priorité SEO.
## Le ROI mesuré : pourquoi le levier vaut le coût
Sur des audits e-commerce 2025-2026, l'effet mesuré des avis bien affichés sur fiche produit :
- +12 à +35 % de conversion sur fiches produit avec ≥10 avis et note ≥ 4/5.
- +8 à +18 % de CTR en SERP avec les étoiles Schema.org Review activées sur fiches produit individuelles.
- +4 à +12 % de CTR en SERP avec les étoiles boutique Google Seller Ratings (visibles en ads et organic).
- Réduction du taux de retour de 3 à 8 % grâce aux retours d'usage partagés par les acheteurs (taille, qualité réelle, livraison).
Sur une boutique à 1 M€/an, l'investissement dans une solution certifiée (1 200 à 4 800 €/an) est amorti par le gain conversion en 1 à 3 mois.
## Workflow conforme à mettre en place sur PrestaShop
### 1. Sollicitation post-livraison
Email transactionnel automatique 7 à 14 jours après livraison (donc après réception confirmée par le transporteur, pas après expédition). Lien unique signé par token, expirant à 30 jours. Pas d'incentive monétaire pour l'avis (interdit par le DSA si lié à une note positive).
### 2. Collecte et vérification
L'avis est rattaché à un numéro de commande. La note (1 à 5) est obligatoire, le commentaire texte facultatif. Vérification anti-spam (Akismet ou équivalent), détection automatique d'insultes ou de contenu illégal.
### 3. Modération
Toute modération doit suivre des critères publics et auditables. Motifs valides de rejet : insulte, contenu illégal, hors-sujet (ex. avis sur le transporteur posté sur la fiche produit), conflit d'intérêt manifeste. Motif invalide : avis simplement négatif. En cas de rejet, droit de réponse de l'auteur sous 14 jours.
### 4. Publication et affichage
Avis publié sous 72h après collecte. Affichage : note, texte, date, prénom et initiale, mention « avis vérifié ». Note moyenne accompagnée explicitement du nombre d'avis (« 4,3 / 5 sur 247 avis »). Distinction visuelle si avis non-vérifiés cohabitent.
### 5. Conservation et audit
Historique 13 mois minimum, accessible en cas de contrôle. Journal de modération : qui a modéré, quand, pourquoi, communication avec l'auteur. Ce journal est l'élément central d'un audit DGCCRF.
## Les pièges qui font perdre le bénéfice du levier
### 1. Modérer pour supprimer les avis négatifs
Tentation classique et risque maximal en 2026. Un audit DGCCRF qui compare le ratio avis négatifs publiés vs avis négatifs collectés détecte immédiatement la modération abusive. Plus efficace : _répondre_ publiquement aux avis négatifs avec une vraie solution proposée. Effet conversion supérieur à une suppression, et conforme à la norme.
### 2. Mélanger avis vérifiés et non vérifiés sans distinction visible
Particulièrement risqué si les avis non vérifiés sont importés depuis une ancienne base ou ajoutés manuellement. La distinction doit être claire, et le lecteur ne doit pas pouvoir confondre.
### 3. Inciter à un avis positif
« Donnez 5 étoiles et recevez un bon de 10 € » est désormais une pratique commerciale déloyale claire. Incentive autorisé : un bon générique offert pour publier un avis (quelle que soit la note), explicitement déconnecté de la nature de l'avis.
### 4. Sous-estimer la portée Schema.org
Le Schema.org Review et AggregateRating doivent porter sur la fiche produit individuelle, pas sur la boutique globale. Erreur fréquente : afficher la note moyenne boutique sur chaque fiche produit via JSON-LD. Google détecte et déclasse, voire ne montre plus aucune étoile en SERP.
### 5. Oublier la portée multilingue
Sur une boutique FR/EN/ES/DE en Polylang, les avis FR ne sont pas pertinents pour les visiteurs EN. Soit les avis sont affichés selon la langue, soit ils sont traduits (avec mention claire de la traduction automatique), soit ils sont mutualisés explicitement.
## Conclusion : la conformité est devenue le coût d'entrée
En 2026, les avis produits restent un des leviers de conversion les plus rentables sur PrestaShop. Mais l'époque des avis collectés à la légère est terminée. Le coût d'une solution certifiée NF ISO 20488 (1 200 à 4 800 €/an pour la majorité des cas) est dérisoire face au risque DGCCRF (jusqu'à 6 % du CA mondial) et au gain de conversion (12 à 35 %).
Pour une boutique sérieuse, le choix par défaut est désormais Avis Vérifiés ou Trustpilot. Le DIY reste défendable mais seulement avec un workflow de conformité documenté et audité, et en acceptant la perte du levier Google Seller Ratings. Dans tous les cas, la sollicitation post-livraison, la modération transparente et le droit de réponse sont devenus des éléments non négociables.
---
### Comment faire du storytelling sur une fiche produit PrestaShop sans page builder ?
_Source :_ — _publié_ 2026-08-17
> Le storytelling produit est une question d'ordre, pas de style. Pourquoi un constructeur de pages est le mauvais outil sur un catalogue, la structure en six blocs qui convertit, et comment l'appliquer à trois cents fiches sans y passer l'année.
Sur une fiche produit, le storytelling n'est pas une question de style d'écriture. C'est une question d'ordre : dans quel ordre présenter les informations pour qu'un visiteur qui ne connaît ni la marque ni le produit décide d'acheter. La plupart des fiches PrestaShop échouent parce qu'elles commencent par les caractéristiques techniques, c'est-à-dire par la réponse à une question que le visiteur ne s'est pas encore posée.
Le réflexe habituel consiste à installer un constructeur de pages. Voici pourquoi c'est le mauvais outil, et ce qui marche à la place.
## Le problème du constructeur de pages
Un page builder résout un problème de mise en page pour une fiche. Il en crée quatre autres dès qu'on raisonne catalogue.
- **Il ne se réplique pas.** Composer trois cents fiches à la main est un projet, pas une tâche. Et la trois centième ne ressemblera pas à la première.
- **Il alourdit la page.** Les constructeurs chargent leur propre CSS et JavaScript sur chaque fiche, y compris pour les fiches qui n'utilisent aucun bloc. Le coût se lit directement dans les Core Web Vitals.
- **Il enferme le contenu.** La mise en page est stockée dans le HTML de la description. Un changement de thème ou de constructeur casse l'ensemble, et une migration devient un chantier de reprise manuelle.
- **Il produit du contenu non structuré.** Vous ne pouvez pas interroger « toutes les fiches dont le bloc preuve est vide », parce que la notion de bloc n'existe nulle part dans vos données.
## La structure en six blocs
Une fiche qui convertit suit presque toujours la même progression. Le contenu change, l'ordre non.
1. **La promesse.** Une phrase qui dit ce que le produit permet de faire, pas ce qu'il est. Elle se place juste sous le titre, avant le prix si votre thème le permet.
2. **Le problème.** Deux ou trois lignes qui décrivent la situation du client avant l'achat. Ce bloc crée la reconnaissance : le visiteur doit se dire « c'est exactement mon cas ».
3. **La preuve.** Un chiffre, une photo d'usage réelle, un avis client précis, un résultat de test. Un seul élément, mais solide.
4. **Le détail.** Les caractéristiques techniques, la composition, les dimensions. C'est ici, et pas plus haut.
5. **L'objection.** Ce qui bloque l'achat : la taille, la compatibilité, le délai, l'entretien. Le traiter dans la fiche évite un abandon et un ticket au service client.
6. **L'action.** Un rappel de la promesse au niveau du bouton d'achat, avec l'élément de réassurance qui compte pour ce produit.
## Bénéfice avant caractéristique, concrètement
La règle est connue et mal appliquée. Trois exemples de réécriture.
- « Batterie 5000 mAh » devient « Deux recharges complètes de téléphone avant de devoir la recharger elle-même ».
- « Traitement déperlant » devient « La pluie fine glisse dessus, vous restez sec pendant une averse de vingt minutes ».
- « Livré avec 3 embouts » devient « Les trois embouts couvrent les vis de meuble en kit les plus courantes ».
Notez que la caractéristique ne disparaît pas. Elle reste, au bloc 4, pour le visiteur qui compare. Elle cesse simplement d'être le premier contact.
## La preuve, et ce qui n'en est pas
« Qualité premium » n'est pas une preuve. « Testé sur 200 cycles de lavage sans perte de couleur » en est une. Le critère est simple : une preuve est vérifiable ou réfutable. Si votre concurrent peut écrire exactement la même phrase sur son propre produit, ce n'est pas une preuve, c'est du remplissage.
Les quatre sources qui fonctionnent, par ordre d'efficacité décroissante : le chiffre mesuré, la photo d'usage prise par un client, l'avis client cité avec son contexte, la certification ou le test tiers.
## Industrialiser sans uniformiser
Le point qui rend la démarche tenable sur un catalogue entier : les blocs 2, 5 et 6 sont largement communs à l'intérieur d'une même gamme. Le problème que résout une perceuse est le même pour toutes vos perceuses. Les objections aussi.
Vous pouvez donc écrire ces blocs une fois par catégorie et ne personnaliser que la promesse, la preuve et le détail. Le temps de rédaction par fiche tombe de trente minutes à cinq, et la cohérence de la gamme s'améliore au passage.
## L'effet SEO, en second
Une fiche structurée en blocs produit mécaniquement du contenu unique, plus long, et hiérarchisé par des titres. Ces trois éléments servent le référencement, mais c'est une conséquence, pas l'objectif. Une fiche écrite pour le moteur et non pour le lecteur se reconnaît immédiatement et convertit mal, quel que soit son classement.
Un point technique tout de même : si vos blocs sont repliés dans des onglets ou des accordéons, vérifiez que le contenu est bien présent dans le HTML initial et non chargé au clic. Dans le second cas, il n'est pas indexé.
## Passer à la pratique
Le apporte cette structure en blocs sans constructeur de pages : champs dédiés par bloc dans la fiche produit, modèles réutilisables par catégorie, rendu géré par le thème, et contenu stocké de façon structurée plutôt que noyé dans le HTML de la description.
---
### Page « Aucun résultat » PrestaShop : comment la transformer en page qui vend ?
_Source :_ — _publié_ 2026-08-16
> Entre 10 et 20 % des recherches internes ne renvoient rien, et ces sessions portaient la meilleure intention du site. Les quatre causes d'une recherche vide, les cinq blocs qui rattrapent le visiteur, et comment exploiter le journal des requêtes.
Un visiteur qui utilise la barre de recherche a une intention précise. S'il obtient une page vide, il ne reformule pas dans la majorité des cas : il quitte. Sur une boutique moyenne, entre 10 et 20 % des recherches internes ne renvoient rien, et ces sessions convertissent à un taux proche de zéro alors qu'elles portaient la meilleure intention du site.
PrestaShop affiche pour ces cas un message court, sans alternative. C'est une impasse alors que la page devrait être un point de rattrapage.
## Pourquoi une recherche ne renvoie rien
Quatre causes, très inégales en fréquence.
1. **Le vocabulaire ne correspond pas.** Le client cherche « chargeur voiture », votre fiche s'intitule « adaptateur allume-cigare ». Le produit existe, la requête échoue. C'est de loin le cas le plus fréquent.
2. **La faute de frappe.** La recherche native s'appuie sur un index fulltext MySQL sans tolérance à l'erreur. Une lettre en trop suffit.
3. **Le produit n'existe pas au catalogue.** Cas minoritaire, mais le plus intéressant commercialement.
4. **Le produit existe mais est désactivé ou hors stock avec vente interdite.** Le client cherche une référence que vous avez retirée sans redirection.
Ces quatre cas appellent des réponses différentes, ce qui interdit une page zéro résultat générique.
## Les cinq blocs d'une page utile
**La correction suggérée.** « Vouliez-vous dire… » avec relance automatique sur le terme corrigé. C'est le bloc qui récupère le plus de sessions, parce qu'il traite les cas 1 et 2 sans effort de la part du visiteur.
**Les catégories proches.** À partir des mots de la requête, proposez deux ou trois catégories plutôt que des produits isolés. Un client qui cherche un terme générique veut souvent parcourir, pas atterrir sur une fiche.
**Une sélection commerciale.** Meilleures ventes ou nouveautés de la catégorie déduite. Ce bloc convertit peu mais retient : il évite la page blanche et donne au visiteur une raison de rester une page de plus.
**Le formulaire de demande.** « Nous n'avons pas trouvé, dites-nous ce que vous cherchez. » Email et texte libre, deux champs. C'est le bloc que presque personne n'installe et qui a le meilleur rapport valeur sur effort.
**Le contact direct.** Sur un catalogue technique, un numéro ou un chat sur cette page précise a du sens : le visiteur qui ne trouve pas est souvent celui qui a le panier le plus élevé.
## Le formulaire de demande, en détail
Ce que vous récoltez ne se limite pas à une adresse email. Chaque soumission est une demande qualifiée, datée, formulée dans les mots du client. Trois usages concrets :
- **Réponse individuelle.** Si le produit existe sous un autre nom, vous répondez avec le lien et vous récupérez une vente qui était perdue.
- **Décision de sourcing.** Dix demandes sur la même référence absente valent un test d'achat chez le fournisseur.
- **Correction du catalogue.** Les demandes portant sur un produit existant mais introuvable vous donnent la liste exacte des synonymes à ajouter à vos fiches.
Prévoyez le consentement pour la réponse, et distinguez-le de toute inscription commerciale.
## Mesurer le rattrapage
Trois indicateurs suffisent, et ils doivent être suivis dans le temps plutôt qu'observés une fois.
- **Le taux de sortie** de la page zéro résultat. C'est le juge de paix. Avant intervention, il dépasse souvent 70 %.
- **Le taux de clic** sur chaque bloc, pour savoir lequel travaille réellement et lequel occupe de la place.
- **Le taux de conversion des sessions rattrapées**, c'est-à-dire des visiteurs passés par une page vide puis revenus dans le parcours d'achat.
## Le journal des requêtes vides est un plan de travail
Au-delà de la page elle-même, la liste des recherches sans résultat est l'un des rares gisements de données parfaitement gratuits d'une boutique. Trié par fréquence, le top 50 vous donne trois chantiers immédiats.
Les termes correspondant à des produits existants deviennent des synonymes à intégrer aux fiches ou à l'index de recherche. Les termes récurrents sans produit correspondant alimentent la liste de sourcing. Et les requêtes à volume significatif méritent parfois une page dédiée, indexable, qui capte la même demande depuis Google.
Un point de vigilance sur ce dernier usage : générer automatiquement une page pour chaque requête produit des milliers de pages vides et nuit à l'ensemble du site. La sélection doit rester manuelle, ou reposer sur un seuil de volume et un contrôle du nombre de résultats.
## Mettre en place la page de rattrapage
Le construit cette page sur PrestaShop 8 et 9 : suggestions corrigées, catégories déduites, sélection commerciale, formulaire de demande produit, et journal des requêtes vides avec suivi du taux de rattrapage.
---
### Black Friday 2026 sur PrestaShop : infrastructure, calendrier promo et la check-list J-30
_Source :_ — _publié_ 2026-08-16
> Le 27 novembre 2026, des boutiques PrestaShop tomberont à 18h pour cause de PHP-FPM saturé, d'autres seront sanctionnées par la DGCCRF pour prix de référence non conforme, d'autres encore récolteront un pic de trafic non monétisé faute de logistique préparée. La check-list complète J-30 à J+15, par poste : infrastructure, catalogue, marketing, conformité, monitoring jour J.
Le 27 novembre 2026, Black Friday tombera un vendredi. Cyber Monday le 30 novembre. Pour les boutiques e-commerce françaises, c'est typiquement 8 à 25 % du CA annuel concentré sur 5 jours. Et chaque année, les mêmes incidents se répètent : boutiques en rade à 18h le vendredi, prix barrés non conformes à la directive Omnibus, stocks fantômes vendus puis annulés, conversions GA4 effondrées par saturation server-side.
Les boutiques qui passent Black Friday sans incident ne le font pas par chance. Elles suivent un playbook qui démarre à J-30 et couvre cinq postes : infrastructure, catalogue, marketing, conformité, monitoring. Cet article rassemble la check-list complète, calibrée pour PrestaShop 8 et 9 en 2026.
## J-30 à J-21 : infrastructure et capacité
### Audit de capacité serveur
- Mesurer le trafic actuel (visiteurs uniques / heure, requêtes / minute, pic horaire constaté).
- Estimer le pic Black Friday : +300 à +800 % du trafic moyen en heure de pointe (18h-22h vendredi soir, 11h-14h samedi). Référence : statistiques Adobe Digital Insights et données internes secteur.
- Vérifier que l'hébergement actuel soutient ce pic. Un mutualisé o2switch ou OVH Performance ne tient généralement pas un pic ×8 — passage VPS dédié ou cluster nécessaire.
### Load testing réaliste
Outil de référence : **k6** (ou Locust). Scénario à scripter : 70 % de visiteurs anonymes sur catalogue, 20 % en ajout panier, 10 % en checkout complet. Cible : tenir 3× le pic estimé sans dégradation du TTFB au-delà de 800 ms. Tester depuis l'extérieur (pas depuis le même datacenter que le serveur).
### Cache pré-chauffé
Configurer un cron qui crawl les 500 URLs les plus visitées la veille de Black Friday pour pré-chauffer le cache (Varnish, edge CDN, Redis objet). Page froide au moment du pic = boutique en rade.
### Plan de scaling
- Sur VPS Hetzner / Scaleway / OVH : passer la veille à un plan supérieur (CPU + RAM doublés). Coût marginal 30-100 € pour 7 jours, prolongation jusqu'au 2-3 décembre.
- Sur AWS / GCP : Auto Scaling Group correctement dimensionné, health check validé.
- CDN : passer en plan Pro/Business si nécessaire pour bande passante non plafonnée.
## J-21 à J-14 : catalogue et préparation produit
### Audit prix et directive Omnibus
C'est la conformité la plus contrôlée par la DGCCRF en 2026. Pour chaque produit en promo, le prix barré doit être le prix de référence le plus bas pratiqué dans les 30 derniers jours. Concrètement :
- Audit table `ps_specific_price` : repérer les promos déjà actives.
- Documenter le prix de référence (le plus bas des 30 derniers jours) pour chaque produit qui sera en promo Black Friday.
- Configurer le prix barré explicitement avec ce prix de référence, pas avec le prix tarif catalogue artificiellement gonflé.
Pour mémoire, l'article de fond sur la directive Omnibus est programmé sur le blog au 22 juin : la conformité prix de référence est devenue la cible n°1 des contrôles e-commerce et reste sanctionnée jusqu'à 300 K€ pour personne morale.
### Préparation des règles de prix et codes promo
- Créer toutes les `specific_price` et `cart_rule` dans un environnement de staging, tester, puis exporter / importer en production.
- Coder les dates de début / fin précises (du 27 novembre 0h au 30 novembre 23h59 par exemple).
- Vérifier que les règles ne se cumulent pas de manière non voulue (priorité, exclusivité).
### Audit stock et logistique
- Identifier les produits à risque de rupture pendant Black Friday : top 100 catalogue.
- Vérifier la mise à jour du stock en temps réel (sync ERP, désactivation en cas de rupture, gestion des back-orders).
- Alerter le partenaire logistique : préparation aux volumes ×5 du quotidien sur 4 jours.
## J-14 à J-7 : marketing et email warming
### Warming de la délivrabilité email
Si la newsletter n'a pas envoyé depuis plus de 30 jours, les filtres anti-spam Gmail et Outlook traiteront un gros envoi Black Friday comme suspect. Stratégie de warming :
- Envois progressifs sur la base la plus engagée à J-14, J-10, J-7.
- Volume croissant : 10 %, 25 %, 50 % de la base, puis 100 % le jour J.
- Surveiller le taux de bounce et le placement (Inbox Placement via Mailgun ou Postmark).
### Préparation campagnes Ads
- Briefer Meta Ads et Google Ads sur l'augmentation de budget des 27-30 novembre.
- Vérifier que les conversions sont bien remontées via Conversion API server-side (sinon ROAS apparent faussé).
- Activer les audiences personnalisées (panier abandonné, visiteurs 30 jours, top-spenders) en J-7.
### Activation des leviers de capture
- Popup newsletter avec offre « Accès anticipé Black Friday » — capture en J-21 à J-7.
- Notifications push web : campagne dédiée le 26 novembre soir (J-1).
- SMS pour la base opt-in : envoi 27 novembre matin.
## J-7 à J-1 : derniers contrôles
### Gel des déploiements
Aucun déploiement de module, thème ou code custom à partir de J-5. Toute modification doit être validée en staging et déployée avant. Exception : hotfix de sécurité critique.
### Plan de bascule
- Documenter le numéro de l'astreinte technique pour le 27-30 novembre.
- Préparer un plan de communication client en cas d'incident (bandeau « ralentissement temporaire », email rassurant si retard envoi).
- Backup complet à J-2 (BDD + fichiers), stocké en off-site, restauration testée.
### Vérification finale conformité
- Audit visuel d'une dizaine de fiches produit en promo : prix barré, prix de référence, économies affichées cohérentes.
- CGV à jour, mentions Black Friday spécifiques (durée de l'offre, exclusions).
- Politique de retour bien visible — les retours post-Black Friday sont massifs.
## Jour J : monitoring temps réel
### Dashboard à surveiller
- TTFB et taux d'erreur 5xx via UptimeRobot, BetterUptime ou Grafana.
- Charge CPU / RAM serveur (htop, Netdata, Datadog).
- File d'attente PHP-FPM (`pm.status_path` exposé).
- Cache hit ratio Redis / CDN.
- Conversions GA4 en temps réel, comparées au volume back-office.
- Taux de remplissage stock sur les top 50 produits.
### Astreinte humaine
Au minimum un dev en astreinte vendredi 18h-23h et samedi 10h-14h (pics confirmés sur 5 ans de données). Avec accès SSH, sudo, et accès au back-office. Sans astreinte, un incident à 19h le vendredi peut tuer 30 % du CA Black Friday.
## J+1 à J+15 : la phase post-Black Friday
### Gestion des retours
Le taux de retour Black Friday est typiquement 1,5× à 2× la moyenne annuelle (achat impulsif, cadeau qui ne convient pas). Préparer :
- Capacité service client : +50 à +100 % de tickets sur 2-3 semaines.
- Workflow retour automatisé (étiquette pré-payée, remboursement rapide).
- Communication proactive J+7 : « comment retourner si nécessaire ».
### Pic de fraude post-Black Friday
Les fraudeurs profitent du volume pour passer inaperçus. Le taux de chargeback monte typiquement de 50 à 100 % en décembre par rapport à l'année. Surveiller particulièrement les commandes à livraison expresse vers des adresses inhabituelles.
### Analyse post-mortem
À J+15, produire un rapport :
- CA total Black Friday, comparé à 2025 et au CA quotidien moyen.
- Taux de conversion par canal (email, ads, organique, direct).
- AOV par segment (nouveaux vs récurrents).
- Performance technique (uptime, TTFB moyen, incidents).
- Marges réelles après promos et coût d'acquisition.
- Top 5 enseignements pour Black Friday 2027.
## Le résumé en un coup d'œil
Black Friday n'est pas un événement marketing — c'est une opération technique, juridique et logistique qui demande 30 jours de préparation sérieuse. Les boutiques qui s'en sortent en 2026 ont toutes en commun :
1. Une infrastructure load-testée à 3× le pic estimé.
2. Un cache propre, pré-chauffé, qui absorbe les pages anonymes.
3. Une conformité Omnibus auditée et documentée pour chaque promo.
4. Un warming email progressif pour ne pas tomber en spam le jour J.
5. Une astreinte humaine pendant le pic, avec un plan de bascule documenté.
6. Une logistique briefée et une gestion des retours anticipée.
Sans ce playbook, Black Friday devient une roulette : parfois ça passe, parfois la boutique perd une partie du CA et l'image en prime. Avec ce playbook, Black Friday devient un levier sûr de croissance annuelle. La différence : 30 jours de préparation à partir du 27 octobre.
---
### Comment regrouper toutes les commandes d'un client B2B dans une facture mensuelle PrestaShop ?
_Source :_ — _publié_ 2026-08-16
> Une facture par mois plutôt qu'une facture par commande : ce que la consolidation change côté trésorerie, les quatre cas de gestion à trancher, et pourquoi on ne peut pas se contenter de regrouper des PDF déjà numérotés.
Un client professionnel qui commande deux fois par semaine reçoit une centaine de factures par an. Son comptable en traite une centaine, votre comptable en émet une centaine, et chacune génère potentiellement un virement à rapprocher. La facturation récapitulative règle ce problème en émettant une facture unique par client et par période, généralement le mois.
PrestaShop n'a pas cette notion. Une commande égale une facture, générée automatiquement au changement de statut. Voici ce que suppose réellement le passage à la facturation mensuelle.
## Ce que la consolidation change concrètement
Pour le client, un seul document à valider et un seul règlement à programmer. Sur des commandes de faible montant passées à haute fréquence, c'est souvent la condition posée par le service achat pour travailler avec vous.
Pour vous, trois effets se cumulent : moins de documents à émettre et à archiver, moins de virements à rapprocher, et un encours plus lisible parce qu'il se raisonne par client et non par commande. Le contrepoids est réel : vous encaissez plus tard. Une commande du 2 du mois facturée le 30, payable à 30 jours, est réglée fin du mois suivant, soit près de soixante jours de décalage. Cette décision est financière avant d'être technique.
## Les quatre cas de gestion à trancher
### La date qui déclenche le rattachement
Une commande passée le 30 janvier et expédiée le 2 février appartient à quelle facture ? La règle la plus sûre rattache la commande à la période de sa livraison, parce que c'est la livraison qui rend la créance exigible en vente de marchandises. Choisissez une règle unique et documentez-la, l'incohérence sur ce point est ce qui déclenche les contestations client.
### Les retours et les avoirs
Un retour intervenu avant la clôture doit être déduit de la facture récapitulative en cours. Un retour intervenu après émission impose un avoir séparé, avec sa propre numérotation. Ne rectifiez jamais une facture déjà transmise, même si elle n'est pas encore payée.
### La TVA
Les taux applicables sont ceux en vigueur à la date de chaque livraison, pas à la date d'émission de la facture récapitulative. Sur une période à cheval sur un changement de taux, la facture porte donc deux taux distincts. Le document doit détailler les bases par taux, ce qu'une simple somme de commandes ne fait pas.
### Le détail exigé
Une facture récapitulative n'est pas un relevé. Elle doit reprendre le détail des livraisons : date, référence de la commande ou du bon de livraison, désignation des articles, quantités, prix unitaires. Un document qui se contenterait de lister des montants ne remplit pas les conditions d'une facture et sera refusé par le service comptable du client.
## La numérotation
C'est le point où une implémentation maison échoue le plus souvent. La numérotation des factures doit être continue, chronologique et sans rupture. Si vous continuez à générer des factures par commande pour vos clients B2C tout en émettant des récapitulatives pour vos clients B2B, les deux flux doivent partager la même séquence, ou utiliser deux séries distinctes clairement identifiées par un préfixe.
Ce que vous ne pouvez pas faire : générer les factures unitaires puis les « remplacer » par une récapitulative. Les numéros déjà attribués resteraient dans la séquence sans document correspondant, ce qui constitue une rupture. La consolidation doit intervenir en amont, en n'émettant pas de facture au niveau de la commande.
## Ce que PrestaShop fait, et pourquoi cela bloque
Dans PrestaShop, la facture est générée par le passage à un statut de commande dont l'option « facture » est cochée, typiquement « Paiement accepté » ou « Expédié ». Le numéro est attribué à ce moment, à partir du compteur global de la boutique.
Deux conséquences suivent. Il faut d'abord neutraliser la génération automatique pour les clients concernés, sans la désactiver pour les autres, ce qui suppose de raisonner par groupe de clients. Il faut ensuite disposer d'un état intermédiaire pour les commandes livrées mais pas encore facturées, sinon vous perdez la trace de ce qui reste à consolider en fin de mois.
## Le contexte de la facturation électronique
La généralisation de la facture électronique entre entreprises rend ce sujet plus sensible qu'auparavant. Une facture récapitulative reste parfaitement admise, mais elle devra être émise dans un format structuré et transiter par une plateforme agréée, avec son détail de lignes exploitable par machine. Une consolidation bricolée par assemblage de PDF ne passera pas cette étape.
C'est un bon argument pour traiter le sujet maintenant plutôt que dans l'urgence : la structure de données que vous mettez en place aujourd'hui pour consolider proprement est exactement celle qui sera exigée demain.
## Mettre en place la consolidation
Le traite cette chaîne dans PrestaShop 8 et 9 : suspension de la facturation unitaire par groupe de clients, regroupement par période, détail des livraisons par ligne, gestion des avoirs et numérotation continue.
---
### Alerte retour en stock sur PrestaShop : convertir la rupture
_Source :_ — _publié_ 2026-08-15
> Une fiche en rupture reçoit un visiteur avec une intention d'achat claire et le laisse repartir. Voici ce que fait le module natif Alertes mail, ses trois limites, et les quatre chiffres qui transforment l'alerte en outil de décision de réassort.
Une rupture de stock est le seul cas où un visiteur arrive sur une fiche produit avec une intention d'achat claire et repart sans rien. Le trafic a été payé, la demande est qualifiée, et le seul obstacle est temporaire. C'est le meilleur rapport effort sur revenu de toute la boutique, et c'est aussi ce que la plupart des PrestaShop laissent filer.
## Ce que fait le module natif
PrestaShop embarque le module **Alertes mail** (ps_emailalerts), qui propose deux fonctions distinctes : des notifications côté marchand, et une alerte client « Prévenez-moi quand ce produit sera disponible ». La seconde s'active dans la configuration du module et ajoute un lien sur les fiches en rupture.
Cela fonctionne, au sens strict. Le client laisse son email, et quand la quantité repasse au-dessus de zéro, un message part. Trois limites apparaissent dès qu'on veut en faire un levier commercial.
### Aucune visibilité sur la demande
Le back-office n'expose pas la liste des attentes. Vous ne savez pas quels produits concentrent le plus d'inscriptions, ni depuis combien de temps les gens attendent. Cette information vaut pourtant plus que l'alerte elle-même : c'est un signal de réassort gratuit, remonté par vos clients.
### Aucune mesure
Une fois l'email parti, la piste s'arrête. Impossible de savoir combien de destinataires ont cliqué, combien ont commandé, quel chiffre d'affaires l'alerte a généré. Sans ce chiffre, vous ne pouvez pas arbitrer entre réapprovisionner une référence ou la sortir du catalogue.
### Un envoi brut
Tous les inscrits reçoivent le message en même temps, sans échelonnement. Sur un réassort de dix unités pour trois cents inscrits, vous générez deux cent quatre-vingt-dix déceptions et un pic de trafic inutile. Le message ne réserve rien et n'indique pas la quantité disponible.
## Le formulaire : trois règles
**La place.** Le formulaire remplace le bouton d'ajout au panier, au même endroit et avec le même poids visuel. Un lien discret sous la description est vu par une fraction des visiteurs.
**Les champs.** L'email seul. Chaque champ supplémentaire coûte des inscriptions, et vous n'avez besoin de rien d'autre pour envoyer l'alerte. Si le client est connecté, préremplissez.
**Le consentement.** L'inscription à une alerte est un traitement à finalité déterminée : elle autorise l'envoi du message de disponibilité, pas l'ajout à votre newsletter. Deux cases distinctes, ou une seule case et pas de newsletter. Le raccourci inverse est une non-conformité classique et facilement constatable.
## L'email : le délai et le contenu
Le délai d'envoi est le paramètre le plus déterminant. Une alerte envoyée dans l'heure suivant la remise en stock capte l'intention encore chaude. Envoyée le lendemain par un traitement nocturne, elle arrive après que le client a acheté ailleurs.
Le contenu tient en peu de choses : le visuel du produit, son prix actuel, un lien qui ajoute directement au panier plutôt qu'un lien vers la fiche, et une indication de la quantité disponible quand elle est faible. Cette dernière mention change le taux de clic : « 6 unités disponibles » déclenche davantage que « de nouveau disponible ».
## Les quatre chiffres à suivre
1. **Taux d'inscription** : inscriptions rapportées aux visites de fiches en rupture. En dessous de 5 %, le formulaire est mal placé ou peu visible.
2. **Taux de clic** sur l'email d'alerte. Il est structurellement élevé, souvent au-dessus de 30 %, parce que le message répond à une demande explicite.
3. **Taux de conversion** des cliqueurs. C'est le chiffre qui compte, et le seul qui justifie un réassort.
4. **Chiffre d'affaires attribué** aux alertes sur la période, à comparer au coût du réassort.
Ces quatre chiffres transforment une fonctionnalité de confort en outil de décision d'achat.
## Le cas des déclinaisons
Point technique souvent négligé : l'alerte doit porter sur la déclinaison, pas sur le produit. Un client qui attend une chemise en taille L n'a rien à faire d'un message annonçant le retour de la taille XS. Vérifiez ce comportement avant toute chose, c'est la première source de désabonnement et de plaintes.
## Exploiter la demande en amont
Le vrai gain se situe avant même l'alerte. Une liste d'attente qui grossit sur une référence vous dit trois choses : la demande existe, elle est mesurable, et elle est datée. Sur un produit saisonnier, la courbe des inscriptions vous indique le moment de la commande fournisseur bien mieux que l'historique de ventes, puisqu'elle capte une demande que vous n'avez pas servie.
Le couvre cette chaîne complète sur PrestaShop 8 et 9 : formulaire par déclinaison, envoi automatique à la remise en stock, tableau des attentes par référence et suivi du chiffre d'affaires généré par chaque alerte.
---
### Headless PrestaShop 2026 : faut-il vraiment passer au front découplé ?
_Source :_ — _publié_ 2026-08-15
> Le headless commerce est vendu comme la solution miracle aux Core Web Vitals et à la modernité front. Sur PrestaShop, la réalité 2026 est plus nuancée : 6 à 12 mois de dev, 30 à 150 K€ de coût, perte de l'écosystème thème et modules front. Pour quelles boutiques le découplé est rentable, et l'alternative hybride qui couvre 80 % du gain pour 10 % du coût.
Depuis 2022, le « headless commerce » est devenu un argument marketing récurrent dans l'écosystème e-commerce : front découplé en React ou Vue, back-end PrestaShop / WooCommerce / Shopware exposé via API, performance Core Web Vitals parfaite, expérience PWA mobile-native. La promesse est séduisante. En 2026, après quatre ans de retours d'expérience sur des projets réels, le bilan est plus nuancé.
Sur PrestaShop spécifiquement, le passage au headless est un projet à 30-150 K€ de budget initial, 6 à 12 mois de mise en œuvre, et une rupture avec une grosse partie de l'écosystème de modules. Cet article fait le point sur ce que change vraiment le headless, pour quel profil de boutique il est rentable, et l'alternative hybride qui couvre l'essentiel du gain sans le coût.
## Headless, vraiment : la définition technique
Une boutique PrestaShop classique est un monolithe : Smarty génère le HTML côté serveur à partir de templates .tpl, qui sont peuplés par les controllers Symfony et les hooks de modules. Front et back partagent le même processus PHP.
Une boutique headless découple les deux. Le front est une application autonome (souvent Next.js, Nuxt, Vue Storefront, ou un PWA custom) qui appelle l'API PrestaShop pour récupérer produits, catégories, panier, commande. Le rendu HTML est généré côté client (CSR) ou côté serveur Node (SSR), pas par PHP.
Trois variantes existent en 2026 :
- **Full headless** : front Next.js complet, back PrestaShop pur API. Aucun template Smarty utilisé.
- **Composable commerce** : plusieurs sources de données (PrestaShop pour catalogue, Algolia pour search, Stripe pour checkout, Contentful pour CMS) agrégées par le front.
- **Hybride PWA** : front PWA qui reste connecté au back PrestaShop traditionnel, avec service worker pour les ressources statiques et appels API pour la dynamique. Pas du vrai headless, mais souvent suffisant.
## Les promesses du headless et ce qu'elles valent en 2026
### Promesse 1 : performance Core Web Vitals
C'est l'argument central. Un front Next.js bien fait obtient effectivement de meilleurs scores CWV qu'un PrestaShop classique non optimisé. Mais comparer un front Next.js optimisé à un PrestaShop non optimisé est trompeur — c'est comparer un projet récent et soigné à un projet legacy. Sur un PrestaShop 8 avec stack de cache propre (Redis + edge CDN + OPcache), les écarts de CWV avec un Next.js sont marginaux : 0,2 s sur le LCP, parfois moins.
### Promesse 2 : expérience mobile PWA
Vrai. Un front PWA peut être installé comme une app, fonctionne offline partiellement, et offre une navigation plus fluide que le web mobile classique. Mais l'adoption PWA réelle reste faible (3-8 % des visiteurs installent la PWA), et le bénéfice business est rarement à la hauteur de l'investissement.
### Promesse 3 : multi-canal et omnichannel
L'idée : le même back-end PrestaShop sert un front web, un front mobile natif, des bornes en magasin, un chatbot. C'est techniquement vrai, mais la majorité des boutiques mid-market n'ont qu'un canal (web) et n'auront jamais de besoin omnichannel. Argument marketing surtout pertinent pour les chaînes retail à plus de 50 M€ de CA.
### Promesse 4 : modernité du stack et talents dev
Recruter sur React et Next.js est plus facile que sur Smarty et Twig PrestaShop. Vrai. Mais une fois recruté, le dev doit apprendre les spécificités du modèle de données PrestaShop, des hooks, du multishop, des combinaisons. Le gain en talents nets est moindre qu'annoncé.
## Le coût réel d'un projet headless PrestaShop
### Développement initial
- **Front complet (Next.js ou Nuxt)** : pages catalogue, fiches produit, recherche, panier, checkout, compte client, blog. 3 à 6 mois de dev front à plein temps.
- **Intégration API PrestaShop** : la webservice REST de PrestaShop couvre 80 % des besoins, mais reste limitée sur des cas spécifiques (cart rules complexes, multishop, modules tiers). Souvent 1 à 2 mois de dev sur des endpoints custom.
- **Checkout repensé** : c'est le module le plus complexe. Calcul de port, taxes, codes promo, paiement, gestion des erreurs. 1 à 2 mois.
- **SEO et redirections** : sitemap, hreflang, meta, schema.org, gestion URL legacy. Si non préparé, perte SEO violente. 2-3 semaines.
Budget total typique : **30 à 80 K€ pour une boutique simple, 80 à 150 K€ pour une boutique B2B ou multilingue / multi-pays**.
### Infrastructure
- Hébergement Vercel ou Netlify : 50-300 $/mois selon volume.
- Auto-hébergement Node SSR : VPS dédié 30-100 €/mois.
- Search externalisé (Algolia, Meilisearch) : 50-500 $/mois.
- CDN images (Cloudinary, Imagekit) : 30-200 $/mois.
### Maintenance courante
- Deux codebases à maintenir au lieu d'une.
- Compatibilité à valider à chaque mise à jour PrestaShop (la webservice change parfois).
- Modules PrestaShop achetés deviennent largement inutiles : ils interviennent sur les hooks de thème Smarty, qui n'existent plus.
## Ce qu'on perd en passant headless
### 1. L'écosystème de modules PrestaShop
C'est la perte la plus sous-estimée. PrestaShop 8 a un écosystème de plus de 3 500 modules sur l'Addons Marketplace. La grande majorité interviennent côté front via des hooks de thème (`displayProductButtons`, `displayLeftColumnProduct`, etc.). En headless, ces hooks ne sont plus appelés. Chaque module front doit être réimplémenté en React/Vue : avis produits, cross-sell, configurateur, sticker promotionnel, badge nouveauté.
Sur une boutique qui utilise 15 modules front, il faut prévoir 2 à 4 semaines de dev pour réimplémenter le strict nécessaire.
### 2. L'admin et l'UX merchandiser
Le back-office PrestaShop reste, mais certaines fonctionnalités perdent leur sens. Le module CMS PrestaShop génère du HTML que le front headless doit interpréter — ce qui marche si on reste sur des structures simples, mais pas si le merchandiser veut placer des composants riches. Les CMS headless modernes (Builder.io, Storyblok) sont en général ajoutés en complément, ce qui ajoute une troisième stack à orchestrer.
### 3. La capacité d'itération rapide
Modifier un thème Smarty est rapide (FTP, refresh). Modifier un front Next.js implique un cycle build / deploy / test. Pour des équipes habituées à itérer vite côté boutique, le passage au headless ralentit le rythme.
## Pour quelles boutiques le headless est-il rentable ?
Trois profils où l'investissement se justifie réellement en 2026 :
### 1. Boutique avec ambition omnichannel sérieuse
Plusieurs canaux à servir (web, app mobile native, bornes magasin, marketplaces) avec une source de vérité unique. PrestaShop devient le back-office produit, le front est dédupliqué par canal. Justification : à partir de 5-10 M€ de CA et 2+ canaux.
### 2. Boutique avec exigence d'expérience front extrême
Catalogue mode de luxe avec animations sophistiquées, configurateur 3D, boutique éditoriale avec contenu très riche. Le templating Smarty montre vite ses limites face à un front React bien fait. Profil minoritaire (haut de gamme, secteurs très visuels).
### 3. Boutique avec stack composable mature
L'équipe tech a déjà fait le choix d'agréger plusieurs sources : Algolia pour search, Stripe pour checkout, un PIM externe, un CMS dédié. PrestaShop n'est plus que le moteur de catalogue parmi d'autres. Le front est l'agrégateur naturel.
## L'alternative hybride : 80 % du gain pour 10 % du coût
Pour 80 % des boutiques PrestaShop mid-market, le bon compromis en 2026 n'est pas le headless mais une optimisation hybride :
1. **Conserver le monolithe PrestaShop** avec sa stack de cache propre (Redis + edge CDN, voir l'article dédié sur la stratégie de cache).
2. **Optimiser le thème Smarty** : CSS critique inliné, JS différé, lazy loading natif, images WebP/AVIF, polices preloadées.
3. **Ajouter des îlots interactifs** en Vue ou React sur les zones à forte interactivité (configurateur, recherche, panier sticky). C'est la philosophie « islands architecture » qui combine SSR rapide et interactivité ciblée.
4. **Externaliser uniquement ce qui a un ROI clair** : Algolia pour la search si la recherche est un levier, Cloudinary pour les images si le volume le justifie.
Cette approche coûte 5 à 15 K€ d'implémentation, se déploie en 2 à 6 semaines, et obtient des scores Core Web Vitals proches d'un headless bien fait — sans casser l'écosystème modules ni doubler la maintenance.
## Conclusion : un projet à ne pas confondre avec une optimisation
Le headless PrestaShop est un choix d'architecture stratégique, pas une optimisation Core Web Vitals. Justifiable pour les boutiques avec une vraie ambition omnichannel, une exigence d'expérience front exceptionnelle, ou une stack tech déjà composable. Difficilement rentable pour une boutique mid-market dont l'objectif est d'améliorer la conversion mobile et la performance.
En 2026, la majorité des projets headless PrestaShop sur lesquels DataFirefly a été consultée auraient obtenu un meilleur ROI avec une stack de cache propre + un thème optimisé + des îlots interactifs ciblés. Le headless reste pertinent — mais seulement pour les boutiques dont les contraintes le justifient réellement, pas comme solution par défaut à un problème de performance.
---
### PrestaShop : comment faire « le 2e à -50 % » sans code promo ?
_Source :_ — _publié_ 2026-08-15
> Le 2e à -50 % est une remise de 25 % sur le lot, pas de 50 %. Voici pourquoi le code promo est un mauvais véhicule, ce que le prix spécifique par quantité fait à la place, et les cas de gestion à trancher avant de lancer l'offre.
« Le 2e à -50 % » est une mécanique de lot déguisée en remise. Elle fonctionne bien sur les produits que l'on achète naturellement par paire ou par lot : chaussettes, cartouches, filtres, cosmétiques, accessoires. Sa mise en place sur PrestaShop se heurte à deux obstacles : le moteur de prix ne sait pas appliquer une remise à une unité seulement, et le réflexe du code promo coûte plus cher qu'il ne rapporte.
## Pourquoi ne pas passer par un code promo
Un code promo suppose que le client le connaisse, le saisisse, et ne se trompe pas. Trois effets négatifs suivent mécaniquement.
- Le champ « code promo » au panier envoie une partie des visiteurs chercher un code ailleurs. Une proportion non négligeable ne revient pas, ou revient via un site de bons de réduction auquel vous versez une commission sur une vente qui était déjà acquise.
- Les clients qui n'ont pas vu le code paient plein tarif et découvrent l'offre après coup, ce qui génère des demandes de geste commercial au service client.
- Vous ne pouvez pas annoncer l'offre sur la fiche produit de manière crédible, puisque son application dépend d'une action manuelle en fin de parcours.
Une mécanique de lot doit s'appliquer d'elle-même, dès l'ajout de la deuxième unité au panier.
## Le calcul réel, et pourquoi il compte
Sur un produit à 40 euros, « le 2e à -50 % » donne 40 + 20, soit 60 euros pour deux unités. Le prix unitaire moyen tombe à 30 euros, ce qui représente une remise de 25 % sur le lot, pas de 50 %.
Cette différence explique pourquoi la mécanique est plus rentable qu'elle n'en a l'air. Vous annoncez un chiffre à deux chiffres frappant, vous consentez la moitié. C'est aussi ce qui la rend difficile à reproduire avec les outils natifs.
### Le prix spécifique par quantité ne fait pas la même chose
Dans l'onglet **Prix** d'un produit, un prix spécifique déclenché à partir de 2 unités applique la remise à _toutes_ les unités du lot. Une remise de 25 % à partir de 2 donne bien 60 euros pour deux, le résultat est identique. Mais le prix unitaire affiché passe à 30 euros, et c'est ce prix-là que le client voit, pas la mécanique.
La conséquence est double. Vous perdez l'effet psychologique du « 2e à moitié prix ». Et vous créez un nouveau prix pratiqué qui entre dans votre historique tarifaire, avec les obligations d'affichage qui vont avec.
### La règle de panier n'est pas plus adaptée
Une règle de panier applique un pourcentage à une sélection de produits ou au panier entier, jamais à une unité désignée à l'intérieur d'une ligne. Sur un panier contenant trois unités du produit, la remise porterait sur les trois, ce qui n'est pas la mécanique.
## Les décisions à prendre avant de configurer
Quatre points déterminent le comportement de l'offre et doivent être tranchés en amont.
1. **La répétition.** Sur quatre unités, le client bénéficie-t-il de deux remises, ou d'une seule ? La logique de lot veut deux, une par paire. La logique promotionnelle simple veut une seule.
2. **Le nombre impair.** Trois unités donnent une paire remisée et une unité pleine. C'est la règle standard, mais elle doit être visible au panier, sinon elle passe pour une erreur de calcul.
3. **Le périmètre.** Deux unités du même produit, ou deux produits de la même catégorie ? Le second cas est plus attractif mais impose de désigner l'unité remisée, en général la moins chère.
4. **Le cumul.** L'offre s'applique-t-elle sur un produit déjà en promotion ? Le cumul donne des remises effectives de 40 % et plus, à vérifier produit par produit.
## L'affichage et le point de conformité
Une mécanique de lot ne modifie pas le prix unitaire de référence tant que la première unité reste vendue au tarif habituel. Vous n'avez donc pas à faire évoluer votre prix de référence au sens de la directive Omnibus, à la différence d'une remise classique en pourcentage.
Trois éléments doivent malgré tout figurer :
- sur la fiche produit, l'annonce de l'offre à hauteur du sélecteur de quantité, avec le prix du lot indiqué en clair ;
- au panier, une ligne distincte pour la remise appliquée, avec son libellé, et non une simple différence de total ;
- les conditions de l'offre, période et produits concernés, accessibles depuis la page.
Sur la facture, la remise doit apparaître comme une réduction sur le lot et non comme un prix unitaire modifié. Cette distinction évite les erreurs de rapprochement comptable et les litiges en cas de retour partiel : si le client renvoie une des deux unités, le remboursement porte sur le prix effectivement payé, pas sur le prix catalogue.
## Le point de retour
C'est le cas de gestion que la plupart des boutiques découvrent trop tard. Un client achète deux unités à 60 euros, en retourne une, et réclame 40 euros. Décidez à l'avance, et écrivez-le dans vos conditions : soit le remboursement se fait au prorata du montant réellement payé, soit le retour d'une unité annule l'offre et le client conserve la seconde au tarif plein. La première option est plus simple à défendre.
## Mettre l'offre en place
La mécanique demande un moteur capable de raisonner par paire à l'intérieur d'une ligne de panier, de répéter la remise autant de fois que nécessaire, et de l'annoncer avant le panier. Le couvre ces trois besoins sur PrestaShop 8 et 9, avec le badge sur la fiche et dans le listing, la gestion des quantités impaires et le paramétrage du cumul.
---
### Comment automatiser les relances d'impayés B2B sur PrestaShop ?
_Source :_ — _publié_ 2026-08-14
> Sur une boutique B2B qui accepte le virement, l'encours impayé se construit en silence. Voici une séquence de relance en quatre temps, les mentions à faire figurer, et le point où le suivi manuel cesse d'être tenable.
Une boutique B2B qui accepte le virement avec paiement à réception ou à 30 jours accumule un encours. Tant qu'il reste faible, un tableur suffit. Passé une trentaine de factures ouvertes en simultané, le suivi manuel décroche : on relance les gros clients, on oublie les petits, et ce sont souvent les petits qui finissent en perte.
PrestaShop ne gère pas ce sujet. La commande passe en « En attente de paiement par virement », et plus rien ne se produit. Aucun compteur d'échéance, aucune relance, aucun calcul de pénalité. Voici comment structurer le processus.
## La séquence en quatre temps
La donnée la plus contre-intuitive du recouvrement est celle-ci : le taux de récupération dépend davantage du délai de première relance que de la fermeté du ton. Une facture relancée le lendemain de l'échéance se solde dans la grande majorité des cas par un simple oubli corrigé. La même facture relancée à trente jours entre dans une négociation.
### J+1 : le rappel neutre
Ton informatif, pas comminatoire. L'objectif est de traiter le cas majoritaire, celui de la facture égarée dans une boîte comptable. Rappelez le numéro de facture, le montant, la date d'échéance dépassée, et joignez à nouveau le document. Proposez un contact direct en cas de litige sur la prestation, c'est le meilleur moyen de faire remonter tôt un problème de fond.
### J+8 : la relance ferme
Le ton change. Vous constatez l'absence de règlement et vous fixez une date limite explicite, en général sept jours. C'est aussi le moment d'annoncer, sans encore les appliquer, les conséquences prévues aux conditions générales de vente : pénalités de retard et suspension des livraisons en cours.
### J+15 : la relance avec pénalités chiffrées
Vous appliquez et vous chiffrez. Deux montants doivent apparaître distinctement :
- les pénalités de retard, calculées au taux prévu par vos CGV, avec pour plancher légal trois fois le taux d'intérêt légal en vigueur ;
- l'indemnité forfaitaire pour frais de recouvrement, fixée à 40 euros par facture.
Point souvent mal compris : ces deux montants sont dus de plein droit dès le jour suivant l'échéance, sans qu'un rappel préalable soit nécessaire. Vous choisissez de les réclamer ou non, mais vous n'avez pas à les avoir annoncés pour y avoir droit.
### J+30 : la mise en demeure
Courrier recommandé avec accusé de réception, reprenant l'historique des relances, le principal, les pénalités, l'indemnité forfaitaire, et un délai final. C'est la pièce qui rend une procédure ultérieure possible. Elle marque aussi la sortie du processus automatisé : au-delà, l'affaire relève d'un traitement individuel.
## Ce que le suivi doit exposer
Une séquence d'emails ne suffit pas. Il faut une vue par client, pas seulement par facture, avec quatre informations :
- l'encours total ouvert, toutes factures confondues ;
- l'ancienneté de la plus vieille facture non réglée ;
- le stade de relance atteint pour chacune ;
- le montant des pénalités courues à date.
Cette vue sert à deux décisions concrètes : bloquer ou non la prise de nouvelles commandes pour ce client, et arbitrer entre relance amiable et passage au contentieux. Sans elle, vous continuez à livrer un client qui ne paie plus depuis deux mois, ce qui arrive plus souvent qu'on ne l'admet.
## Les mentions à ne pas oublier sur la facture
Le processus de relance s'appuie sur des mentions qui doivent déjà figurer sur la facture initiale. Trois sont obligatoires en B2B :
1. la date d'échéance ou le délai de paiement convenu ;
2. le taux des pénalités de retard applicables ;
3. la mention de l'indemnité forfaitaire de 40 euros pour frais de recouvrement.
Leur absence n'annule pas votre droit à les percevoir, mais elle affaiblit votre position dans une discussion et vous expose à une sanction administrative distincte. Vérifiez le template de facture PrestaShop avant de lancer la moindre séquence de relance : le modèle natif ne les contient pas.
## Le point de bascule
Trois signes indiquent que le traitement manuel a atteint sa limite : vous ne savez plus dire de tête quel client vous doit combien, vous découvrez des factures en retard de plus de soixante jours au moment de la clôture, et vous relancez par vagues plutôt qu'au fil de l'eau. À ce stade, chaque semaine de retard de relance coûte mécaniquement du taux de recouvrement.
Le traite cette chaîne dans PrestaShop 8 et 9 : échéances par commande, séquence de relance paramétrable, calcul automatique des pénalités et de l'indemnité forfaitaire, et tableau de bord de l'encours par client.
---
### Stratégie de cache PrestaShop 2026 : Redis, Memcached, Varnish — quelle stack pour quelle boutique
_Source :_ — _publié_ 2026-08-14
> TTFB à 800 ms, LCP à 3,2 s, budget de crawl Google saturé : sur une boutique PrestaShop non optimisée, le cache est l'optimisation au plus fort ROI en 2026 — et la plus mal faite. Les quatre couches d'un stack propre, la règle de décision Redis / Memcached / Varnish, et la stack par défaut recommandée pour 80 % des boutiques mid-market.
Sur une boutique PrestaShop 8 ou 9 non optimisée, le TTFB (Time To First Byte) dépasse couramment 800 ms sur du mutualisé et reste autour de 400 ms sur un VPS milieu de gamme. Effet direct sur le LCP (mauvais score Core Web Vitals), sur le budget de crawl Googlebot et sur le taux de rebond. Le tout en 2026, alors que le bench Google est passé à 200 ms de TTFB et 2,5 s de LCP.
Le cache n'est ni un sujet de niche ni réservé aux gros volumes. C'est l'optimisation à plus fort ROI sur PrestaShop, et celle qui est la plus mal faite : confusion entre cache PHP, cache objet, cache HTTP et reverse proxy ; configurations par défaut peu efficaces ; piles de modules qui se marchent sur les pieds. Cet article fait le point sur les quatre couches d'un stack propre et donne la règle de décision Redis / Memcached / Varnish selon le profil de boutique.
## Les quatre couches de cache d'une boutique PrestaShop
Une boutique sert chaque page en empilant plusieurs couches de cache. Connaître les couches, c'est éviter d'en empiler plus qu'il n'en faut — chaque couche ajoute de la complexité et des points de purge à maîtriser.
### 1. Cache opcode PHP
OPcache met en cache le bytecode des fichiers .php interprétés. Indispensable : sans OPcache, chaque requête PrestaShop ré-interprète des milliers de fichiers. Gain typique : 30 à 50 % de TTFB. C'est gratuit, natif PHP, et c'est le premier réflexe à valider via `php -i | grep opcache` en production. À dimensionner : 256 Mo minimum pour PrestaShop 8/9, `opcache.validate_timestamps=0` en production avec recyclage manuel sur déploiement.
### 2. Cache objet (in-memory key-value)
PrestaShop met en cache certains résultats applicatifs : sessions utilisateurs, métadonnées Smarty (chemins de templates, configuration de hooks), résultats de requêtes répétitives. Par défaut, ces caches passent par le système de fichiers, lent. En production sérieuse, on les déplace vers une base in-memory : **Redis** ou **Memcached**.
### 3. Cache HTTP et reverse proxy
Au-dessus de PrestaShop, un reverse proxy (Varnish, NGINX cache, ou edge cache CDN) intercepte les requêtes HTTP et sert des réponses pré-rendues sans solliciter PHP. C'est l'optimisation au plus fort levier — gain typique de 90 % du temps serveur sur les pages anonymes en hit cache.
### 4. Cache navigateur et CDN
Les ressources statiques (images, CSS, JS, polices) doivent porter des en-têtes `Cache-Control: public, max-age=31536000, immutable` et être servies par un CDN. Évidence en 2026, mais mal faite sur 40 % des boutiques auditées : max-age trop court, ressources non versionnées, variations de cache mal configurées.
## Redis vs Memcached : la décision en pratique
Sur le cache objet, deux choix dominent : Redis et Memcached. Le débat « lequel est plus rapide » est dépassé — les deux saturent largement les besoins d'une boutique PrestaShop. La vraie différence est ailleurs.
### Memcached
- Plus simple, moins de fonctionnalités, moins de surface d'attaque et moins de pièges de configuration.
- Excellent pour du cache éphémère key-value pur.
- Pas de persistance disque : un redémarrage vide tout, ce qui produit un thundering herd transitoire sur PHP-FPM.
- Pas de structures avancées (listes, sorted sets, pub-sub) — usage limité au cache strict.
### Redis
- Plus riche : structures de données (lists, sets, sorted sets), pub-sub, scripting Lua.
- Persistance optionnelle (RDB ou AOF) : survit aux redémarrages.
- Utilisé bien au-delà du cache PrestaShop : sessions multi-serveurs, queue Symfony Messenger, rate limiting.
- Configuration mémoire à surveiller (maxmemory, eviction policy) — sinon il consomme plus que prévu.
**Règle pratique 2026** : Redis est le choix par défaut. Memcached reste pertinent si la boutique est volontairement minimaliste et que les seuls besoins sont du cache objet pur. Toute boutique qui envisage à terme une queue de jobs, du rate limiting API ou des sessions partagées multi-serveurs gagne à partir directement sur Redis.
## Quand Varnish a du sens (et quand il ne faut pas)
Varnish (ou NGINX cache full-page) est l'optimisation à plus fort levier sur PrestaShop : il sert les pages anonymes en quelques millisecondes au lieu de 400-800 ms. Mais Varnish n'est pas un game-changer dans toutes les configurations.
### Cas où Varnish change tout
- **Trafic majoritairement anonyme** : visiteurs non connectés, pas de prix personnalisés par client, pas d'A/B test à clé serveur. Catalogue B2C grand public.
- **Volume élevé concentré sur peu d'URLs** : une homepage, 50 catégories, 500 fiches produit représentent 80 % du trafic. Le cache fait l'essentiel du travail.
- **Pic saisonnier prévisible** : Black Friday, soldes. Varnish absorbe le trafic sans saturer PHP-FPM.
### Cas où Varnish est un piège
- **Boutique B2B avec connexion obligatoire** : chaque page est personnalisée (prix groupe client, multi-utilisateurs, devis en cours). Varnish ne sert que les pages publiques (rares) et la complexité dépasse le gain.
- **Personnalisation côté serveur** : recommandations IA par utilisateur, A/B testing serveur, prix dynamiques. Le cache full-page rend caduque toute la personnalisation.
- **Trafic anonyme dispersé sur des milliers de longue-traîne** : si chaque URL est visitée 1 fois par jour, le hit ratio reste faible et Varnish n'apporte rien.
### L'alternative edge cache CDN
En 2026, Cloudflare Cache Rules, BunnyCDN Permacache, Fastly et autres edge caches font le travail de Varnish au niveau du CDN, sans serveur supplémentaire. Avantage : pas de couche à maintenir, distribution géographique, intégration WAF native. Inconvénient : la purge fine est moins flexible que Varnish, et le coût peut grimper sur les gros volumes. Pour 80 % des boutiques mid-market, l'edge cache CDN est devenu une alternative supérieure à un Varnish auto-hébergé.
## Coût réel et ROI d'une stack de cache propre
### Coût
- **OPcache** : 0 €. Activer et bien dimensionner.
- **Redis** : 0 € en local (même serveur que PHP-FPM) à 15-30 €/mois sur un VPS dédié (Hetzner CX11) ou Redis managé (Upstash, Redis Cloud) à partir de 10 €/mois.
- **Varnish** : 0 € open source, mais 1 à 3 jours d'installation et tuning par un sysadmin compétent. À budgéter en temps, pas en licence.
- **Edge cache CDN** : Cloudflare Pro 25 $/mois, BunnyCDN environ 1 $/Go transféré, Fastly à partir de 50 $/mois usage-based.
- **Implémentation initiale** : 2 à 5 jours de dev pour une boutique standard (configuration, tests, purge automatique sur webhook PrestaShop).
### ROI mesuré
Sur des audits de boutiques PrestaShop 8 mid-market post-déploiement d'une stack de cache propre :
- TTFB passe de 600-800 ms à 80-150 ms en hit cache.
- LCP descend de 3,2 s à 1,4 s sur fiche produit anonyme.
- Taux de rebond mobile baisse de 12 à 18 % en moyenne.
- Conversion mobile augmente de 6 à 12 %.
- Budget de crawl Google double, ce qui se traduit en 4-8 semaines par +15 % d'URLs indexées.
Le coût d'opportunité de ne pas mettre en place de cache propre dépasse souvent 1 % de CA annuel. Une boutique à 1 M€/an perd typiquement 10 à 20 K€/an en performance dégradée.
## Les pièges à éviter
### 1. Empiler des modules de cache sans cohérence
Beaucoup de boutiques accumulent : module officiel PrestaShop cache, module Redis tiers, module Varnish séparé, plugin CDN. Sans hiérarchie claire, les caches s'invalident mal entre eux et certains hits annulent les autres. Il faut une et une seule politique de cache documentée, avec un schéma clair de purge en cascade.
### 2. Mal gérer la purge sur événement
Quand un prix change, qu'un stock se met à jour, qu'un attribut produit est modifié, la page concernée doit être purgée. PrestaShop n'a pas de hook unifié — il faut câbler `actionProductUpdate`, `actionObjectStockMvtAddAfter`, `actionObjectCategoryUpdateAfter` et déclencher la purge correcte (Varnish PURGE, Redis DEL, CDN API). Sans ça, le visiteur voit un prix obsolète, ce qui peut tomber sous la directive Omnibus.
### 3. Cacher des pages personnalisées
Le panier, le compte client, le checkout et toute page contenant des données utilisateur ne doivent jamais entrer en cache full-page. La règle Varnish ou CDN doit explicitement exclure ces routes (`/cart`, `/mon-compte`, `/commande`, `/identite`). Erreur fréquente : une boutique qui cache tout par défaut affiche le panier d'un autre client. Incident grave et difficile à diagnostiquer après coup.
### 4. Ne pas tester sous charge
Un cache propre se valide sous charge. Un outil comme k6 ou Locust permet de simuler 500-1000 visiteurs simultanés et de mesurer le hit ratio, le TTFB sous charge, la stabilité PHP-FPM. Sans ce test, on découvre les problèmes en production un jour de pic — le pire moment pour corriger.
### 5. Oublier le multishop et la multi-currency
Un cache trop agressif sur une boutique multishop peut servir la même page HTML à toutes les boutiques, ou servir le prix EUR à un visiteur en GBP. La clé de cache doit inclure `id_shop`, `id_lang`, `id_currency` au minimum. Vérifier explicitement la clé de cache générée — c'est l'erreur silencieuse la plus coûteuse en perte de conversion.
## La stack recommandée par défaut en 2026
Pour 80 % des boutiques PrestaShop 8 / 9 mid-market (CA 200 K€ à 5 M€/an) :
1. **OPcache** activé avec 256 Mo et `opcache.validate_timestamps=0` en production.
2. **Redis** comme backend de cache objet PrestaShop (sessions, Smarty, métadonnées). Une instance suffit dans la plupart des cas.
3. **Edge cache CDN** (Cloudflare ou BunnyCDN) sur les pages catalogue et CMS publiques, avec exclusion explicite des routes utilisateur.
4. **Cache navigateur** agressif sur les ressources statiques (1 an), versionnées par hash via le système d'asset PrestaShop.
5. **Pas de Varnish** sauf cas spécifique de gros trafic homogène où le tuning et la maintenance se justifient.
Cette stack se déploie en 2 à 5 jours, coûte 10 à 30 € par mois en frais récurrents, et apporte un gain de performance bien supérieur à ce qu'on peut obtenir en optimisant le code applicatif. Avant toute optimisation back-end (refonte de modules, requêtes SQL), passer ces cinq points en revue reste la première étape rentable.
---
### Comment créer une promotion 3 achetés + 1 offert sur PrestaShop ?
_Source :_ — _publié_ 2026-08-14
> Les règles de panier PrestaShop savent offrir un produit, mais pas répéter l'offre à chaque multiple de trois ni l'afficher sur la fiche. Voici ce que permet le natif, où il s'arrête, et comment construire une mécanique X achetés Y offerts qui tient en production.
La mécanique « 3 achetés, 1 offert » est l'une des plus efficaces pour faire monter le panier moyen sur des produits à faible prix unitaire et à réachat fréquent : consommables, cosmétiques, alimentaire, petites pièces détachées. Elle est aussi l'une des plus mal servies par PrestaShop en configuration native. Le moteur de règles de panier sait offrir un produit, mais il ne sait pas répéter l'offre à chaque tranche de trois, ni l'annoncer avant que le client ne soit arrivé au panier.
Voici précisément ce que fait le natif, où il s'arrête, et comment construire une offre qui tient sur un vrai catalogue.
## Ce que les règles de panier savent faire
Dans **Réductions > Règles de panier**, PrestaShop propose bien une action « Envoyer un cadeau ». Vous choisissez un produit, éventuellement une déclinaison, et il est ajouté au panier à prix nul quand les conditions sont réunies. Côté conditions, l'onglet _Conditions_ permet de restreindre la règle à une sélection de produits, à des groupes de clients, à une période, et de fixer un montant minimum ou une quantité minimale de produits dans le panier.
Sur le papier, cela ressemble à un 3+1. En pratique, quatre limites apparaissent dès la mise en production.
### La règle ne se répète pas
Un client qui met neuf articles dans son panier devrait recevoir trois cadeaux. La règle native s'applique une fois. Le champ « Total disponible pour chaque utilisateur » ne change rien à cela : il compte les commandes, pas les tranches à l'intérieur d'un même panier. Vous pouvez créer trois règles successives avec des seuils à 3, 6 et 9, mais cette approche ne passe pas l'échelle et devient ingérable au-delà de deux paliers.
### La quantité minimale porte sur le panier entier
La condition de quantité compte les produits du panier, pas les unités d'un produit donné. Un client qui achète un article de chaque référence de la sélection déclenche l'offre au même titre que celui qui prend trois fois le même. Selon votre catalogue, cette nuance suffit à rendre l'opération non rentable.
### Le cadeau est un produit fixe
L'action désigne une référence unique. Sur une offre du type « 3 t-shirts achetés, le 4e offert », le client reçoit systématiquement le même t-shirt, dans la même taille, quelles que soient ses trois premières unités. C'est acceptable pour un échantillon, pas pour une offre de gamme.
### Rien ne s'affiche avant le panier
C'est la limite la plus coûteuse. Une promotion que le client découvre après avoir constitué son panier ne modifie pas son comportement d'achat. Elle ne fait que réduire votre marge sur une commande qui aurait eu lieu de toute façon. L'offre doit être visible sur la fiche produit et dans le listing de catégorie pour produire un effet sur la quantité commandée.
## Le contournement par prix spécifique, et ce qu'il coûte
Beaucoup de boutiques passent par un prix spécifique par quantité : à partir de 4 unités, remise de 25 %. Mathématiquement, le client paie bien trois articles pour quatre. Trois différences importantes subsistent.
- La perception change. Une remise de 25 % est lue comme une baisse de prix, un article offert est lu comme un gain. Le second déclenche davantage l'ajout d'une unité supplémentaire.
- Le prix unitaire affiché baisse. Cela vous engage sur le terrain de la conformité tarifaire : ce nouveau prix entre dans l'historique des prix pratiqués et peut devenir votre prix de référence pour les 30 jours suivants au sens de la directive Omnibus.
- Le seuil est rigide. Un client qui prend 7 unités obtient 25 % sur les 7, pas sur 4 seulement, ce qui n'est pas la mécanique visée.
Ce contournement reste valable pour du B2B ou du semi-gros, où la lecture en pourcentage est naturelle. Il ne remplace pas une mécanique de cadeau sur du B2C.
## Paramétrer une offre 3+1 qui fonctionne
Une mise en place complète suppose quatre décisions, à prendre avant de toucher au back-office.
1. **Le périmètre.** Catégorie entière, sélection manuelle ou marque. Évitez de faire porter l'offre sur des produits dont la marge unitaire est inférieure à 30 %, la tranche offerte vous ferait passer sous le seuil de rentabilité.
2. **La répétition.** Offre unique par commande, ou répétée à chaque tranche de trois. Le second cas exige que la règle sache diviser la quantité et appliquer le résultat autant de fois que nécessaire.
3. **L'unité offerte.** Le produit le moins cher de la tranche est la convention la plus courante, et la plus sûre pour votre marge. L'alternative, un produit désigné, est plus lisible mais plus risquée si les prix de la sélection sont hétérogènes.
4. **Le cumul.** Décidez si l'offre s'applique à des produits déjà en promotion. Dans PrestaShop, cet arbitrage se règle produit par produit via les prix spécifiques, pas globalement, ce qui impose de vérifier la sélection avant chaque opération commerciale.
## Rendre l'offre visible
Une mécanique 3+1 rentable se voit à trois endroits :
- sur la vignette du listing de catégorie, sous forme de badge court, pour capter l'attention avant le clic ;
- sur la fiche produit, à hauteur du sélecteur de quantité, avec une indication du reste à parcourir du type « ajoutez 1 unité pour recevoir votre article offert » ;
- dans le panier, avec la ligne du cadeau clairement identifiée à 0 euro et non mélangée aux autres lignes.
Le troisième point est celui que le natif traite correctement. Les deux premiers demandent une intervention sur le thème ou un module qui expose ces informations aux templates.
## Le point conformité
Un article offert ne modifie pas le prix unitaire des articles payés. À ce titre, il ne crée pas de nouveau prix de référence et ne déclenche pas l'obligation d'affichage du prix le plus bas des 30 derniers jours. C'est un avantage réel du cadeau sur la remise en pourcentage, souvent sous-estimé lors du choix de la mécanique.
Deux précautions demeurent. La valeur du cadeau doit apparaître sur la facture, ne serait-ce qu'à 0 euro, pour la traçabilité comptable. Et les conditions de l'offre, période, quantité, produits concernés, doivent être accessibles depuis la page de l'opération.
## Aller plus vite
Si votre calendrier commercial comporte plusieurs opérations de ce type par an, reconstruire la mécanique à chaque fois coûte plus cher que de l'outiller une bonne fois. Le gère la répétition par tranche, le choix de l'unité offerte, l'affichage sur la fiche et dans le listing, et les règles de cumul, sur PrestaShop 8 comme sur PrestaShop 9.
---
### Server-side tracking GA4 sur PrestaShop : retrouver 20 à 35 % de conversions après iOS 17 et Consent Mode v2
_Source :_ — _publié_ 2026-08-13
> Entre commandes back-office PrestaShop et conversions GA4, l'écart est de 20 à 35 % en 2026. Effet combiné d'iOS 17, Consent Mode v2, blocage cookies tiers et extensions anti-pistage. Le server-side tracking restaure 70 à 90 % de ces conversions et fiabilise les ROAS Meta/Google. Architecture, coût et ROI réel.
Si vous comparez encore les chiffres GA4 de votre boutique avec les commandes du back-office, vous savez ce qui suit : entre 20 et 35 % de conversions « manquent ». Elles ont eu lieu, elles sont dans le back-office PrestaShop, mais GA4 ne les a pas attribuées. Effet combiné d'iOS 17 (Mail Privacy Protection, Link Tracking Protection), du Consent Mode v2, du blocage des cookies tiers généralisé, et des extensions anti-pistage installées par défaut chez la moitié de l'audience.
Le **server-side tracking** est la réponse technique standardisée à ce trou dans la mesure. Mis en place correctement, il restaure typiquement 70 à 90 % des conversions perdues, fiabilise les attributions multi-touch, et renforce la conformité RGPD. Cet article fait le point sur l'architecture en 2026, le coût réel d'un GTM server-side, et l'implémentation sur PrestaShop.
## Pourquoi la mesure côté client est cassée en 2026
Quatre forces convergentes ont dégradé la mesure GA4 classique côté client depuis 2023 :
- **iOS 17 Mail Privacy Protection et Link Tracking Protection** (2023-2024) : neutralisent les paramètres UTM dans Mail et Messages d'Apple, brisent l'attribution email-to-conversion pour l'écosystème iPhone.
- **Safari Intelligent Tracking Prevention** : limite la durée de vie des cookies first-party à 7 jours. Un visiteur Safari qui revient après 8 jours est un nouveau visiteur pour GA4.
- **Firefox Total Cookie Protection** et **uBlock Origin sur Chrome** : extensions et navigateurs qui bloquent les requêtes vers google-analytics.com et collect.googletagmanager.com.
- **Consent Mode v2** obligatoire en UE depuis mars 2024 : si l'utilisateur refuse les cookies analytics, GA4 ne reçoit que des pings consentless modélisés statistiquement. Très utile, mais bruité.
Résultat : selon des audits multi-boutiques 2025-2026, l'écart entre commandes back-office et commandes GA4 est aujourd'hui de :
- 10 à 20 % sur des audiences principalement Android Chrome.
- 25 à 40 % sur des audiences principalement iOS Safari.
- 30 à 50 % sur les paniers issus de campagnes Meta Ads et TikTok Ads (double effet : pixels bloqués et UTM neutralisés).
## Ce qu'est le server-side tracking — modèle conceptuel
Le tracking client classique fonctionne comme suit : le navigateur du visiteur charge le snippet GA4 ou GTM, envoie un hit à google-analytics.com directement, et celui-ci est bloqué par ITP, uBlock, etc. Quand le hit arrive, il porte un identifiant fragile (cookie _ga avec durée limitée).
Le server-side tracking renverse l'équation : le navigateur envoie un hit à un sous-domaine du marchand (par exemple metrics.boutique.com), qui héberge un container GTM Server-Side. Ce container, sur un serveur du marchand, transforme et enrichit l'événement, puis le transfère côté serveur vers GA4, vers Meta CAPI, vers Google Ads conversion API, vers TikTok Events API. Avantages :
- L'événement n'est plus bloqué par les extensions anti-pistage (la requête va vers le domaine du marchand, pas vers Google).
- Les cookies first-party persistent davantage (côté serveur, durée maîtrisée).
- Les données sont enrichies côté serveur (numéro de commande, marge, catégorie produit, source d'acquisition stockée en BDD) avant d'être transmises.
- Le consentement utilisateur est appliqué avant transmission, ce qui simplifie la conformité Consent Mode v2.
- On peut router le même événement vers plusieurs destinations (GA4 + Meta + Google Ads + TikTok) sans charger autant de pixels côté client.
## Architecture type pour une boutique PrestaShop en 2026
Le stack standardisé qui s'impose en 2026 :
1. **Côté boutique** : container GTM Web standard, avec dataLayer enrichi sur chaque événement critique (view_item, add_to_cart, begin_checkout, add_payment_info, purchase). C'est PrestaShop qui pousse ces événements via un module de tag manager.
2. **Sous-domaine de tracking** (metrics.boutique.com ou analytics.boutique.com) : pointant vers un serveur dédié qui héberge le container GTM Server-Side. Sur App Engine (Google Cloud), AWS, Hetzner ou serveur dédié.
3. **Container GTM Server-Side** : reçoit les hits, enrichit avec données serveur (commande réelle, marge, fidélité client), route vers GA4 Measurement Protocol, Meta CAPI, Google Ads Conversion API, TikTok Events API, et éventuellement vers un data warehouse interne (BigQuery, ClickHouse).
4. **Cookies first-party gérés côté serveur** : durée de vie maîtrisée, identifiant client réconcilié côté serveur avec l'ID PrestaShop quand le visiteur s'authentifie.
## Coût réel d'un GTM Server-Side en 2026
Trois postes de coût à anticiper :
### Hébergement
- **Google Cloud App Engine** (option Google par défaut) : autour de 100 à 200 $ par mois pour un trafic moyen d'une PME e-commerce (100-200 K visiteurs/mois). Auto-scaling automatique. Plus cher si volume élevé, mais zéro maintenance.
- **VPS Hetzner ou Scaleway** avec Docker et image GTM SS officielle : 15 à 40 € par mois pour un volume équivalent. Plus de maintenance, mais 5x à 10x moins cher.
- **AWS, Azure** : ordres de grandeur comparables à GCP, avec frais de bande passante un peu plus élevés.
### Implémentation initiale
Pour une boutique PrestaShop standard, comptez 8 à 20 jours de travail pour :
- Audit du tag actuel et cartographie des événements à tracker.
- Mise en place du sous-domaine tracking et déploiement du container SS.
- Migration du tag GA4 client vers serveur, validation des événements.
- Mise en place des destinations additionnelles (Meta CAPI, Google Ads Conversion API).
- Tests A/B side-by-side pour valider la conformité des données.
- Documentation et formation équipe marketing.
### Maintenance courante
1 à 2 jours par trimestre pour suivre les évolutions GTM SS, mettre à jour les templates de tags, gérer les nouvelles destinations. Faible mais non nul.
## Implémentation sur PrestaShop 8 et 9
Côté boutique, le travail consiste à pousser proprement les événements GA4 standard dans le dataLayer. PrestaShop n'a pas de module officiel pour cela, mais plusieurs solutions tierces couvrent le besoin.
Côté DataFirefly, le module dfgtagmanager (v1.1.0+) gère le dataLayer GA4 complet pour PrestaShop 8 : view_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, ainsi que les événements consent_update (Consent Mode v2) et user_data avec hash SHA-256 pour les Enhanced Conversions. Sortie compatible directement avec un container GTM Web qui transfère vers un container GTM Server-Side.
## Les pièges à anticiper
### 1. Le sous-domaine de tracking doit être cohérent
metrics.boutique.com doit être un sous-domaine du domaine principal, sinon les cookies first-party ne fonctionnent pas correctement et l'intérêt du SS chute. Ne pas utiliser un domaine séparé (genre boutique-metrics.com).
### 2. La conformité Consent Mode v2 doit être appliquée côté serveur
Recevoir l'événement côté serveur ne dispense pas du consentement. Si l'utilisateur a refusé les cookies marketing, le container GTM SS doit drop le hit avant de le transmettre à Meta CAPI ou Google Ads. Erreur classique de débutant qui crée une non-conformité plus grave que le tracking client classique.
### 3. La latence ajoutée doit rester sous contrôle
Un container GTM SS lent (hébergé loin, mal dimensionné) ajoute de la latence aux hits. Sur des événements asynchrones (purchase), c'est invisible. Sur des événements en chemin critique (rare en e-commerce), c'est à monitorer.
### 4. La déduplication des conversions est essentielle
Si le même événement purchase est envoyé deux fois (une fois côté client, une fois côté serveur), GA4 ou Meta CAPI vont compter en double. Il faut soit ne tracker que côté serveur, soit envoyer un event_id unique partagé entre les deux côtés pour permettre la déduplication côté Google et Meta.
### 5. Le routage multi-destinations doit être pensé
Tous les événements ne vont pas à toutes les destinations. Un add_to_cart va à GA4 et Meta CAPI. Un purchase va à GA4, Meta CAPI, Google Ads, TikTok, et idéalement à un data warehouse interne. Le mapping doit être documenté.
## ROI typique de la migration
Sur des projets terminés ces 12 derniers mois, les gains observés se répartissent comme suit :
- **Récupération de la mesure** : 70 à 90 % des conversions « perdues » par le tracking client sont récupérées côté serveur. Pour une boutique à 80 K€/mois de CA, ça représente entre 12 et 24 K€/mois de CA « visible » à nouveau dans GA4. Sans changement du CA réel, mais avec une vue fidèle qui change les arbitrages marketing.
- **Performance des campagnes Meta Ads** : +15 à +35 % de ROAS observé après déploiement de Meta CAPI server-side, par effet d'amélioration de l'algorithme Meta (qui apprend mieux avec des conversions plus complètes).
- **Performance des campagnes Google Ads** : +10 à +25 % de ROAS avec Enhanced Conversions et Google Ads Conversion API server-side. Effet similaire à Meta.
- **Conformité RGPD renforcée** : application du consentement avant transmission, audit de flux possible, traçabilité claire. Argument fort en cas de contrôle CNIL.
Sur une boutique mid-market PrestaShop, le coût total de déploiement (implémentation + hébergement annuel) est typiquement amorti en 2 à 6 mois par le seul gain ROAS sur les campagnes payantes — sans même compter l'amélioration de la qualité de décision côté marketing.
## Conclusion : la mesure n'est plus une option en 2026
Investir dans le contenu, l'UX, le SEO et l'AEO sans pouvoir mesurer correctement la conversion, c'est piloter à l'aveugle. En 2026, le tracking client classique sur GA4 est devenu insuffisant pour une boutique sérieuse — pas par paresse technique, mais parce que l'écosystème navigateur a fondamentalement changé.
Le server-side tracking n'est pas une mode. C'est l'architecture de référence à laquelle migrent toutes les boutiques qui dépassent un certain seuil de chiffre d'affaires et de complexité d'acquisition. C'est aussi, en 2026, un fondement nécessaire pour faire des arbitrages marketing pertinents et pour rester conforme RGPD dans la durée.
Si vous n'avez pas encore migré, le bon moment est maintenant — avant le prochain durcissement d'iOS, de Chrome ou de la jurisprudence CNIL qui rendra le tracking client encore plus partiel qu'aujourd'hui.
---
### AI shopping agents : préparer son catalogue PrestaShop pour Operator, Claude Computer Use et les agents de comparaison en 2026
_Source :_ — _publié_ 2026-08-09
> Operator, Claude Computer Use, ChatGPT Shopping, Perplexity Buy : les agents IA pèsent déjà 2 à 8 % du trafic référent sur les boutiques mid-market en 2026. Comment un agent lit réellement une fiche produit, et la checklist en 8 points pour rendre son catalogue PrestaShop découvrable par les agents et leurs utilisateurs.
2026 est l'année où les **agents de shopping IA** sortent de la démo. Operator d'OpenAI, Claude Computer Use d'Anthropic, ChatGPT Shopping, Perplexity Buy with Pro, Gemini Shopping — chacun, à sa manière, propose à un utilisateur d'_exécuter_ un achat à sa place : trouver un produit, comparer, ajouter au panier, voire valider le checkout. Pour le marchand e-commerce, c'est un changement de paradigme : **une part croissante du trafic devient des agents, pas des humains**, et un catalogue mal préparé devient invisible pour cette nouvelle audience.
Cet article répond à trois questions concrètes : qu'est-ce qui constitue déjà une part mesurable du trafic en 2026 ? Comment un agent IA « lit » réellement une fiche produit ? Et quelles actions techniques mener sur un catalogue PrestaShop pour rester découvrable ?
## Ce qui est réellement déployé en 2026
L'écosystème, à l'heure où ce papier est écrit, se compose grosso modo de :
- **ChatGPT Shopping** (depuis 2024-2025) : un visiteur pose une question d'intention d'achat (« meilleure trottinette électrique adulte pliable sous 800 € »), ChatGPT répond avec une short-list cliquable. Le clic emmène sur la boutique source. Inclusion conditionnée par la qualité des données structurées et de l'IndexNow/sitemap.
- **Perplexity Pro Shopping** : intégré au moteur de réponse Perplexity, propose des produits cliquables dans la marge des réponses « achat ». Très visuel, sourcing direct depuis les balisages Schema.org et Open Graph.
- **Google AI Overviews Shopping** : intégré directement aux SERP Google. Sélection basée sur le Shopping graph (qui dépend du Merchant Center et des balisages Product/Offer).
- **Operator** (OpenAI) et **Claude Computer Use** (Anthropic) : agents qui contrôlent un navigateur. Plus rares en 2026 mais en croissance. Ils _naviguent_ réellement le site, cliquent les boutons, remplissent les formulaires. C'est un visiteur synthétique, qui suit le DOM et le rendu visuel.
- **Agents intégrés à d'autres apps** : Microsoft Copilot Shopping, Amazon Rufus (côté Amazon), agents WhatsApp Business naissants.
Volume estimé sur boutiques mode/déco/tech B2C français mid-market en 2026 : 2 à 8 % du trafic référent provient déjà des agents IA, en croissance rapide. Pas encore majoritaire, mais plus marginal non plus.
## Comment un agent IA « lit » une fiche produit
Deux modes de lecture coexistent et coexisteront en 2026 :
### Mode 1 : data-first (la majorité)
L'agent ne charge pas la page rendue. Il interroge une API publique ou aspire le balisage Schema.org structuré. Sources prioritaires :
- JSON-LD Schema.org embarqué dans la page (Product, Offer, AggregateRating, hasMerchantReturnPolicy, shippingDetails).
- Open Graph meta (og:title, og:description, og:image, og:type=product).
- Flux Google Merchant Center (XML ou API Content).
- Fichier llms.txt s'il existe (qui peut pointer vers une version structurée du catalogue).
- Sitemap XML produit avec dates de modification et priorités.
Aucun JavaScript exécuté, aucun affichage rendu. Si l'information n'est pas dans le HTML statique ou dans les flux structurés, elle n'existe pas pour l'agent.
### Mode 2 : browser-first (Operator, Computer Use)
L'agent charge la page comme un humain le ferait — il exécute JS, voit le DOM rendu, prend des captures d'écran, identifie les boutons, clique. Sa lecture est plus proche d'un visiteur réel, mais avec quelques particularités :
- Il a besoin d'éléments interactifs **nommés et étiquetés** (boutons avec aria-label, formulaires avec labels associés). Le travail accessibilité fait pour WCAG 2.2 sert directement ici.
- Il est sensible aux **popups bloquants** et aux **modales sans bouton de fermeture clair**. Une bannière cookies impossible à fermer au clavier bloquera l'agent autant qu'un utilisateur handicapé.
- Il privilégie les **parcours linéaires** et les **checkouts en un seul écran**. Un funnel à six étapes est plus risqué qu'un one-page checkout.
## La checklist d'optimisation pour catalogue PrestaShop
### 1. JSON-LD Schema.org complet et à jour
C'est la fondation. Voir l'article dédié à Schema.org Product 2026 : hasMerchantReturnPolicy, shippingDetails, ProductGroup pour les déclinaisons, AggregateRating réelles, GTIN/MPN/brand renseignés. Sans cela, un agent IA ne peut pas matcher la fiche produit avec une intention d'achat.
### 2. Fichier llms.txt à la racine
Le standard llms.txt (porté par Anthropic depuis fin 2024) propose un fichier markdown à la racine du domaine qui décrit le site et pointe vers les ressources structurées les plus utiles aux modèles. Pour une boutique e-commerce, le llms.txt typique contient :
- Identité du marchand et secteurs couverts.
- URL du sitemap produit.
- URL d'un flux JSON catalogue (si disponible).
- Politique de retour et de livraison résumée.
- Information de contact pour les agents (email machine-friendly).
Côté DataFirefly, le module dfllmstxt génère ce fichier automatiquement pour les boutiques PrestaShop, avec mise à jour quotidienne et personnalisation par boutique du multi-shop.
### 3. Open Graph produit propre
Au-delà de Schema.org, les agents IA et les réseaux sociaux interrogent les balises Open Graph et Twitter Card. og:type=product, og:image au format 1200×630, og:title clair, og:price:amount et og:availability quand pertinent. Beaucoup de thèmes PrestaShop oublient og:price.
### 4. URLs canoniques stables
Un agent qui revient sur une fiche doit retrouver la même URL. Les URLs avec paramètres dynamiques (id_lang=1, controller=product, etc.) sont moins fiables que des URLs réécrites stables. Le SEO et l'AEO se rejoignent ici.
### 5. Disponibilité et prix fiables côté serveur
L'agent lit le HTML rendu côté serveur. Si le prix réel est calculé en JavaScript côté client (cas fréquent avec les modules de promotion dynamique), l'agent verra le prix par défaut. Vérifier que le prix affiché dans le HTML statique correspond au prix réel.
### 6. Robots.txt et politique de crawl explicite
Les principaux crawlers d'agents IA s'identifient désormais avec des user-agents reconnaissables : GPTBot, ClaudeBot, PerplexityBot, ChatGPT-User, Anthropic-Verifier, Google-Extended. Dans un robots.txt 2026, on autorise explicitement ceux qu'on veut accueillir et on bloque ceux qu'on refuse. Bloquer aveuglément tous les bots IA est tentant mais coupe la boutique de l'audience future.
### 7. Performance et stabilité du rendu serveur
Les agents browser-first abandonnent si la page met plus de quelques secondes à se charger ou si le DOM bouge constamment (CLS élevé). Le travail Core Web Vitals fait pour Google sert directement aux agents — c'est le même critère technique, simplement appliqué par un agent au lieu d'un robot d'indexation.
### 8. Checkout machine-friendly
Pour les agents qui vont jusqu'à acheter (Operator, Computer Use) : checkout one-page ou très court, pas de captcha bloquant, paiement express disponible (Apple Pay, Google Pay), récapitulatif clair avant validation. Un panier abandonné à cause d'un captcha imposé en checkout pour un agent IA, c'est une vente ratée — et en 2026 ça commence à compter.
## Mesurer la part agent dans son trafic
Les agents IA laissent généralement leur trace dans le user-agent et parfois dans le referrer. Les principaux à monitorer en 2026 dans les logs serveur ou GA4 :
- GPTBot, ChatGPT-User (OpenAI).
- ClaudeBot, Claude-User, Anthropic-Verifier (Anthropic).
- PerplexityBot, Perplexity-User (Perplexity).
- Google-Extended (Gemini / AI Overviews).
- CCBot (Common Crawl, alimente plusieurs modèles).
- Applebot-Extended (Apple Intelligence).
Ajouter une dimension custom dans GA4 ou un filtre dans son outil d'analytics côté serveur pour isoler ce trafic permet de mesurer la croissance et de calculer le ROI réel de l'investissement AEO.
## Les risques à anticiper
Trois écueils à garder en tête :
- **La fraude par agent** : un agent mal aligné ou détourné peut tenter des achats en masse, scraper des prix, ou pire. La protection passe par du rate-limiting intelligent (bloquer les patterns suspects sans bloquer les agents légitimes) et de l'authentification step-up pour les paniers atypiques.
- **La désintermédiation marque-client** : si l'agent boucle le tunnel de bout en bout sans que l'utilisateur passe sur le site marchand, la marque perd l'opportunité de communication (newsletter, retargeting, cross-sell). Tendance qui s'amplifiera et qu'il faut intégrer dans la stratégie de fidélisation.
- **Le contenu généré par IA dans les avis** : un travers déjà observé. Investir dans des avis vérifiés (verified reviews) garantit l'authenticité du signal et la conformité avec les exigences Google sur la qualité des reviews.
## Conclusion : préparer son catalogue n'est pas optionnel
L'AEO de 2025 était une option intéressante. L'AEO en 2026 est une condition d'accès au trafic. Les boutiques qui n'auront pas mis à jour leur balisage Schema.org, publié leur llms.txt, et configuré leur robots.txt pour les agents IA verront leur part de marché sur le trafic IA tendre vers zéro pendant que leurs concurrents capteront les premiers effets de réseau.
Bonne nouvelle : ces actions techniques sont parmi les moins coûteuses du marketing digital 2026. Quelques semaines de travail bien ciblé suffisent à passer dans la catégorie « catalogue lisible par agents ». La vraie compétition se joue désormais sur la qualité du produit, du prix, et du service — pas sur la friction technique d'accès à l'information.
---
### Paiement express en 2026 : Apple Pay, Google Pay, Bancontact — adoption France et impact conversion sur PrestaShop
_Source :_ — _publié_ 2026-08-05
> Apple Pay, Google Pay, PayPal Express, Bancontact : le paiement express est le levier de conversion le plus mesurable du checkout en 2026 (+8 à +18 points). Voici l'état réel de l'adoption en France, l'écart de conversion par moyen de paiement, et les trois placements à empiler sur PrestaShop.
Le paiement express — Apple Pay, Google Pay, PayPal Express, Bancontact, Shop Pay — n'est pas une commodité technique. C'est le levier de conversion le plus mesurable du checkout en 2026. Une boutique PrestaShop bien équipée sur ce front gagne typiquement entre 8 et 18 points de taux de conversion finale, le passage en checkout étant le moment de friction maximale.
Mais le sujet est plus subtil qu'il n'y paraît. Tous les moyens de paiement express n'ont pas la même adoption en France, ni le même coût marchand, ni le même impact UX. Cet article fait le point sur l'état réel de l'adoption en 2026, les écarts de conversion par moyen de paiement, et la stratégie d'intégration sur PrestaShop.
## État des lieux de l'adoption en France — données 2026
Quatre wallets dominent désormais le paiement express en France :
- **Apple Pay** : taux de pénétration côté population estimé entre 25 et 35 % en France (correspondant à la part d'iPhone, avec l'usage Wallet activé). Adoption croissante sur mobile, encore minoritaire sur desktop (Safari uniquement).
- **Google Pay** : pénétration plus faible côté population (15-20 %), mais utilisateurs Android plus enclins à payer en wallet quand l'option est disponible.
- **PayPal (express ou classique)** : très installé en France (taux de pénétration > 50 % chez les acheteurs en ligne), mais en perte de vitesse sur la mode et le luxe, où l'image PayPal vieillit.
- **Bancontact** : essentiel en Belgique, marginal en France. À installer obligatoirement pour toute boutique qui livre en Belgique (> 70 % de part de marché du paiement en ligne là-bas).
D'autres wallets régionaux ou sectoriels comptent selon le marché cible : iDEAL aux Pays-Bas, Klarna en DACH, SOFORT/Giropay en Allemagne, Multibanco au Portugal, Sumup pour les paiements en boutique physique multicanal.
## L'écart de conversion mesuré par moyen de paiement
Sur des analyses comparatives multi-boutiques en 2025-2026, on observe les ordres de grandeur suivants (taux de conversion checkout, c'est-à-dire visiteur arrivé à l'étape paiement qui valide effectivement) :
- **Carte bancaire classique** (saisie manuelle) : base de référence. Disons 70-80 % de complétion checkout.
- **Apple Pay** sur iPhone Safari : +15 à +25 % de complétion par rapport à la saisie CB. Authentification Face ID en 1-2 secondes.
- **Google Pay** sur Android Chrome : +10 à +18 % de complétion par rapport à la saisie CB.
- **PayPal Express** : +5 à +12 % par rapport à la saisie CB, surtout efficace sur les acheteurs hors UE ou les paniers > 100 €.
- **Bancontact** en Belgique : indispensable, on perd quasiment 100 % de la conversion belge si on ne le propose pas.
Effet le plus fort : sur mobile. Là où la saisie CB est pénible (clavier mobile, données carte à reproduire), le wallet supprime tout. C'est aussi pourquoi le paiement express est le premier levier mobile en 2026.
## Coût marchand : ce qu'on paie vraiment
Les écarts de commission sont nettement moins importants que ce qu'on imagine. Comparaison sur un panier moyen 70 € en France :
- **CB classique via Stripe ou Adyen** : 1,4 % + 0,25 € fixes. Soit 1,23 € sur 70 €.
- **Apple Pay / Google Pay** via le même PSP : même tarif que la CB. Apple ne facture rien au marchand, c'est transparent.
- **PayPal Express** : 2,9 % + 0,35 € fixes en standard. Soit 2,38 € sur 70 €. Possibilité de négocier à 1,9 % au-delà d'un volume mensuel.
- **Bancontact** via Mollie, Adyen : 1,2 % + 0,30 € en moyenne. Compétitif.
Le surcoût PayPal Express vs CB (environ 1 € sur un panier 70 €) est rentabilisé si PayPal gagne ne serait-ce que 2-3 % de complétion. La vraie question n'est pas le coût, c'est la conversion incrémentale.
## Intégration sur PrestaShop 8 et 9 — l'état du marché
L'écosystème PSP qui intègre proprement le paiement express sur PrestaShop en 2026 :
### Stripe
Module officiel Stripe pour PrestaShop, qui supporte Apple Pay, Google Pay, Link, Bancontact, iDEAL, SOFORT, Klarna, Affirm. Intégration via Payment Element (UI unifiée) ou via boutons express en haut du checkout. C'est la solution la plus complète et la plus simple à déployer en 2026.
### Adyen
Plus orienté grands volumes, mais le module PrestaShop Adyen supporte l'ensemble des wallets. Pertinent si le marchand a déjà un contrat Adyen pour son retail physique multicanal.
### Mollie
Très bon pour les marchands BeNeLux et France. Le module Mollie pour PrestaShop couvre Apple Pay, Bancontact, iDEAL, Klarna. Tarification compétitive.
### Worldline / Saferpay / Lyra
PSP historiques européens. Modules existent, qualité variable. Worldline a beaucoup investi sur PrestaShop 6.7+ ces derniers mois, notamment via le module officiel MoptWorldline.
### PayPlug
Filiale du groupe BPCE, bien implanté chez les marchands français. Module PrestaShop solide, Apple Pay et Google Pay supportés. Tarification française et support en français.
## L'erreur d'implémentation la plus fréquente
Beaucoup de boutiques placent les boutons Apple Pay et Google Pay _uniquement_ à l'étape paiement du checkout. Erreur. Le placement optimal en 2026 est **au panier**, voire **directement sur la fiche produit**, avec un bouton « Acheter maintenant » qui court-circuite le funnel classique.
Cette logique de « shortcut buy » (popularisée par Shop Pay puis Amazon One-Click) raccourcit le checkout à 2 clics : ajout panier → Apple Pay → confirmation. C'est ce qui explique en grande partie l'écart de conversion Shopify vs PrestaShop sur la mobile commerce — et c'est implémentable techniquement sur PrestaShop, simplement moins pré-câblé.
### Trois placements à empiler
1. Bouton wallet sur la fiche produit (court-circuit), pour les achats impulsifs et le « shopping rapide ».
2. Bouton wallet en haut de la page panier (pré-checkout), pour les paniers à plusieurs articles.
3. Boutons wallets à l'étape paiement du checkout (standard), pour les visiteurs qui suivent le tunnel complet.
Ces trois placements coexistent sans se concurrencer. Chacun capte une intention différente.
## Les pièges techniques à éviter
### Le bouton Apple Pay qui ne s'affiche pas
Apple Pay s'affiche uniquement sur Safari iOS, Safari macOS, et navigateurs qui supportent l'API Payment Request. Sur Chrome Android, c'est Google Pay qui apparaît. Beaucoup de marchands testent leur checkout sur Chrome desktop et concluent que « Apple Pay ne marche pas ». Vérifier sur iPhone réel.
### L'absence de domain verification Apple Pay
Apple Pay exige une vérification de domaine côté serveur (fichier .well-known/apple-developer-merchantid-domain-association). Sans elle, le bouton se charge mais le paiement échoue. Erreur classique au déploiement, à vérifier avant mise en production.
### Le checkout pas adapté au flow wallet
Apple Pay et Google Pay retournent les données client (adresse, email, téléphone) en une seule requête. Si le checkout PrestaShop attend une saisie manuelle d'adresse en plusieurs étapes, l'expérience se casse. Il faut court-circuiter les étapes d'adresse en pré-remplissant depuis la réponse du wallet.
### La gestion des produits à transport spécifique
Si le panier contient des articles avec frais de port variables selon la zone, le wallet doit interroger ces frais en temps réel via shipping callback. C'est implémentable mais ajoute de la complexité. Sur PrestaShop, certains modules le couvrent automatiquement, d'autres non.
## L'avenir proche : agents de paiement et identité décentralisée
En 2026, plusieurs signaux convergent vers une nouvelle vague :
- Les **agents de paiement IA** (Operator, Claude Computer Use, ChatGPT Shopping) qui complètent un checkout pour le compte d'un utilisateur authentifié. Cela suppose que la boutique expose un checkout machine-friendly — souvent justement via une API Payment Request bien implémentée.
- Le **wallet EUDI** (European Digital Identity Wallet) qui arrive en 2026-2027 dans une partie des pays UE, promettant un paiement authentifié via identité numérique étatique.
- Les **passkeys de paiement** en cours de standardisation, qui pourraient simplifier encore l'authentification.
Pour un marchand PrestaShop, la bonne stratégie 2026 n'est pas de courir après chacune de ces innovations dès leur sortie, mais d'avoir une intégration Stripe ou Adyen propre et à jour : ces PSP poussent les nouveautés au fil de l'eau, ce qui évite de refaire le checkout tous les ans.
## Conclusion : le checkout en 2026 est multi-modal par défaut
La saisie carte bancaire reste le moyen de paiement principal en France (60-70 % des paiements selon les boutiques), mais elle ne tient ce rang que parce qu'on continue à la proposer en premier par habitude. Reconfigurer le checkout pour **présenter d'abord les wallets express, puis la CB en repli**, déplace l'aiguille de plusieurs points de conversion sans aucun changement de paramétrage commercial.
C'est l'un des très rares leviers e-commerce 2026 où le ROI se mesure en semaines, le risque est nul (on n'enlève rien, on ajoute), et l'investissement est principalement du paramétrage. Probablement le premier chantier à mener avant n'importe quelle autre optimisation conversion.
Pour passer à l'action : [notre sélection de modules pour un checkout rapide sur PrestaShop](https://www.datafirefly.com/solutions/prestashop/checkout-rapide/).
---
### Politique de retour qui convertit : retour gratuit vs payant, le calcul ROI réel sur PrestaShop en 2026
_Source :_ — _publié_ 2026-08-01
> « Retour gratuit 30 jours » vs « Retour à vos frais sous 14 jours » : la différence n'est pas marketing. Une politique de retour est un levier de conversion mesurable, dont le ROI peut être calculé. Voici le calcul chiffré sur une boutique mode (+12 600 € HT/mois net) et les paramètres d'une politique qui convertit sans saigner les marges.
« Retour gratuit 30 jours » vs « Retour à vos frais sous 14 jours ». La différence semble marketing. Elle ne l'est pas. Une politique de retour est un levier de conversion mesurable, dont le ROI peut être calculé avec une précision raisonnable — et qui, mal pensé, peut coûter beaucoup plus cher que ce que sa générosité fait gagner.
L'enjeu en 2026 est plus aigu qu'avant pour deux raisons : Google a fait de la politique de retour un signal de classement dans le Shopping et les AI Overviews (via hasMerchantReturnPolicy), et la fraude au retour s'est professionnalisée (porte ouverte au « try-and-return », à la « wardrobing », au retour d'articles substitués). Cet article décompose le calcul ROI réel et donne les paramètres d'une politique qui convertit sans saigner les marges.
## Pourquoi la politique de retour est un levier de conversion mesurable
Trois mécanismes empilent leurs effets :
1. **Réduction du risque perçu.** Un visiteur hésitant convertit plus facilement s'il sait qu'il peut renvoyer sans frais. L'élasticité dépend du panier moyen et de la catégorie : forte sur la mode (+5 à +15 points de conversion), modérée sur la beauté (+2 à +5), faible sur les biens techniques où le retour gratuit est attendu mais peu utilisé.
2. **Effet de levier sur le ticket moyen.** Quand le retour est gratuit, le visiteur ajoute plus facilement la deuxième taille ou la deuxième couleur — surtout en mode. Ticket moyen typiquement +8 à +20 % sur les boutiques mode/chaussure.
3. **Signal SEO et AEO.** Depuis 2024, Google affiche un badge « Retour gratuit X jours » dans Shopping et les AI Overviews à partir du balisage hasMerchantReturnPolicy. Effet sur le CTR organique : +10 à +25 % observé sur les fiches produit comparables.
Côté coût, deux postes principaux :
- **Coût logistique du retour** : étiquette retour, transport, contrôle qualité, reconditionnement, réintégration au stock. En moyenne 7 à 18 € selon le volume et le partenaire transporteur, davantage pour les produits volumineux.
- **Coût « invendable »** : article reçu en retour mais qui ne peut plus être vendu au prix neuf — souillé, ouvert, démodé. Selon la catégorie, 5 à 30 % des retours mode et 1 à 10 % des retours électroménager.
## Le calcul ROI : exemple chiffré sur une boutique mode PrestaShop
Prenons une boutique mode PrestaShop à 80 000 € HT de CA mensuel, panier moyen 65 €, taux de conversion 2,2 %, taux de retour actuel 18 % avec retour payant.
**Hypothèse** : passage au retour gratuit 30 jours.
Effets attendus (fourchette prudente) :
- Conversion : +6 points relatifs (de 2,2 % à 2,33 %) → +4 800 € HT de CA mensuel.
- Ticket moyen : +12 % (de 65 € à 73 €) → effet multiplicateur, soit environ +10 600 € HT additionnels.
- CTR organique sur fiches produit : +15 %, qui se traduit en +1 200 € HT de CA via le SEO.
- **Gain brut total mensuel** : environ +16 600 € HT.
- Taux de retour : monte de 18 % à 28 % (effet de la gratuité). Volume de retours : 28 % × (80 K + 16,6 K) = 27 K€ de marchandises retournées.
- Coût logistique additionnel : 27 K€ × ~12 % de la valeur (étiquette + manutention + contrôle) = 3 200 €.
- Coût invendable additionnel : 27 K€ × ~10 % invendable au prix neuf, vendus avec décote 30 % = 800 € de perte.
- **Coût total mensuel** : environ 4 000 € HT.
**ROI net mensuel** : 16 600 − 4 000 = **+12 600 € HT**. Sur un an, 150 K€ de marge additionnelle pour une décision de politique.
Cet exemple est volontairement favorable (mode = catégorie sensible). Sur des biens techniques, le calcul est moins net : la conversion gagne peu, le retour devient un coût net. C'est pour cela qu'il faut calculer _par catégorie_, pas globalement.
## Les paramètres d'une politique qui convertit
### Durée
La psychologie compte plus que la durée elle-même. 30 jours est devenu la norme française, 60 jours est un argument différenciant, 100 jours (utilisé par certains pure players mode) est un argument fort. Au-delà, l'effet marginal s'amenuise.
Au plan légal en France, la durée minimale est de 14 jours (droit de rétractation) pour les achats à distance. Toute politique commerciale au-dessus est un choix marchand.
### Gratuité du retour
Trois variantes selon le contexte :
- **Retour gratuit total** : étiquette prépayée fournie. Le mieux pour la conversion, le pire pour les marges. À réserver aux catégories à forte conversion sensible (mode, chaussure, lunettes, sous-vêtement).
- **Retour à frais réduits** : « 4,90 € de frais de retour ». Réduit le frottement du « try-and-return » sans dégrader fortement la conversion. Compromis sain pour la majorité des marchands.
- **Retour à frais client** : par défaut. Acceptable sur les biens techniques où l'acheteur sait ce qu'il achète, mais à compenser par un argument fort (échange gratuit, par exemple).
### Modalités de retour
Point de collecte (Mondial Relay, Relais Colis) > retour en boutique > enlèvement à domicile > envoi par le client. Le point de collecte gratuit est le standard 2026 sur la mode. L'enlèvement à domicile est un service premium qui peut être payant ou réservé aux clients fidèles.
### Échange préféré au remboursement
Mécaniquement, un échange (changement de taille, de couleur, autre article) coûte beaucoup moins cher qu'un remboursement, parce que le CA n'est pas perdu. Mettre en avant « Échange gratuit » avant « Remboursement gratuit » sur la page de retour réoriente une partie significative des retours vers l'échange — gain moyen 15 à 25 % de marge sur le périmètre retour.
### Restrictions ciblées contre la fraude
Pour les boutiques mode/luxe, certaines règles limitent le « wardrobing » (achat-port-retour) :
- Étiquettes anti-retour visibles sur le vêtement (étiquette suspendue qui doit rester en place).
- Non-retour des articles soldés en-dessous d'un certain seuil (gris sur le plan légal, à vérifier avec un juriste).
- Blacklist des clients récidivistes (taux de retour > 70 %, plus de 3 retours consécutifs).
## Implémentation technique sur PrestaShop
Le module Returns natif de PrestaShop est minimaliste : il génère un numéro de retour mais ne gère ni étiquette automatique, ni workflow comptable, ni intégration transporteur, ni statistiques par motif de retour.
Un workflow retour complet sur PrestaShop 8 ou 9 implique :
1. Formulaire client de demande de retour avec choix de motif (taille, couleur, défaut, autre), photos optionnelles, choix entre échange et remboursement.
2. Génération automatique d'étiquette retour transporteur (API Colissimo, Mondial Relay, Chronopost, UPS).
3. Workflow back-office : réception colis, contrôle qualité, décision (acceptation, refus, décote), réintégration stock ou destruction.
4. Génération avoir comptable automatique avec ordre correct des opérations (TVA, port, frais bancaires).
5. Statistiques par motif, par catégorie, par client, pour identifier les produits à problème.
Côté DataFirefly, le module dfproductreturn couvre ce workflow complet sur PrestaShop 8 et 9, avec intégration Fastmag ERP pour les marchands qui ont un back-office multi-canal.
## Mesurer ce qui compte vraiment
Les bonnes métriques à suivre sur un horizon de 3 à 6 mois après mise en place d'une politique :
- **Taux de conversion par catégorie** avant/après. Doit augmenter sur les catégories sensibles.
- **Taux de retour par catégorie**. Va augmenter, normal. Surveiller que ça reste dans la fourchette prévue (le calcul ROI est sensible à cette variable).
- **Ratio échange / remboursement**. Idéalement > 30 % en échange.
- **Coût moyen retour** (logistique + invendable). À tracker au mois pour détecter une dérive (transporteur, fraude).
- **Top 20 produits avec taux de retour anormal**. Souvent un défaut produit caché, un mauvais guide des tailles, une photo trompeuse. Action ciblée plus efficace que « durcir la politique ».
## Le piège des politiques trop généreuses
Une boutique mode qui passe brutalement de retour payant à retour gratuit 100 jours sans préparation logistique se met en difficulté. Le pic de retours arrive 30-45 jours après le changement, et si le back-office n'est pas dimensionné, les remboursements traînent, les avis Google s'effondrent, et le gain marketing initial est annulé.
La bonne séquence : tester d'abord sur une catégorie en pilote pendant 2 mois, mesurer, dimensionner le back-office (ressources humaines, intégration transporteur, stock tampon), puis généraliser progressivement.
## Conclusion : une politique de retour est un produit, pas un texte juridique
Trop de marchands traitent la politique de retour comme une page CGV qu'on rédige une fois et qu'on oublie. C'est un produit : il a une cible (la catégorie sensible), un prix (le coût additionnel), un ROI à calculer, et une mesure de performance dans le temps. Bien conçu, c'est l'un des meilleurs investissements UX d'un marchand mode ou beauté en 2026 — et un signal qui fait basculer Google Shopping et les AI Overviews.
Mal conçu, c'est un cadeau aux fraudeurs et une charge récurrente. La différence est dans le calcul, pas dans l'intention.
Pour passer à l'action : [notre sélection de modules pour gérer les retours produits](https://www.datafirefly.com/solutions/prestashop/gestion-retours/).
---
### Email transactionnel délivrabilité 2026 : DMARC strict, BIMI et pourquoi vos confirmations finissent en spam
_Source :_ — _publié_ 2026-07-24
> « On a payé une commande, le client ne reçoit pas la confirmation. » Le ticket support le plus fréquent en 2026 est presque toujours un problème de délivrabilité, pas un bug. Depuis Gmail/Yahoo février 2024, DMARC strict et BIMI sont devenus la nouvelle norme. La feuille de route complète pour une boutique e-commerce.
« On a payé une commande, le client ne reçoit pas la confirmation. » C'est probablement le ticket support le plus fréquent sur les boutiques PrestaShop en 2026 — et c'est presque toujours un problème de délivrabilité, pas un bug applicatif. Depuis février 2024, Gmail et Yahoo ont durci leurs exigences pour les expéditeurs en masse, et l'écosystème suit. Hotmail, Outlook, Apple iCloud appliquent désormais des contrôles équivalents.
Pour une boutique e-commerce, l'enjeu n'est pas marginal : un email de confirmation qui finit en spam, c'est un client qui rappelle, un agent support qui gère, un risque de litige et un rétrogradage de la réputation domaine qui dégrade _tous_ les emails suivants. Voici la mise au point complète sur les règles 2026, les vérifications à faire sur sa propre boutique, et les corrections concrètes.
## Les règles applicables en 2026 — synthèse opérationnelle
Trois mécanismes d'authentification sont aujourd'hui exigés ou exigibles selon le volume :
- **SPF** (Sender Policy Framework) : enregistrement DNS qui liste les serveurs autorisés à envoyer du courrier pour le domaine. Soft fail (~all) toléré, hard fail (-all) recommandé une fois la migration validée.
- **DKIM** (DomainKeys Identified Mail) : signature cryptographique de chaque email avec une clé privée, vérifiable via une clé publique publiée en DNS. Indispensable.
- **DMARC** (Domain-based Message Authentication, Reporting & Conformance) : politique publiée en DNS qui dit aux serveurs destinataires ce qu'il faut faire des emails qui échouent SPF ou DKIM. p=none = monitoring, p=quarantine = spam, p=reject = rejet pur.
Depuis février 2024, Gmail et Yahoo exigent DMARC publié (au minimum p=none) pour tout expéditeur dépassant 5 000 emails par jour. Outlook et iCloud ont suivi en 2025. À partir d'avril 2025, Gmail a commencé à filtrer plus agressivement les expéditeurs en p=none qui ne progressent pas vers une politique stricte au bout de plusieurs mois.
En 2026, la trajectoire est claire : **DMARC p=quarantine ou p=reject est en train de devenir le standard de fait**, même pour les expéditeurs sous le seuil de 5 000 emails/jour. Les boutiques qui restent en p=none verront leur délivrabilité se dégrader progressivement.
## BIMI : le bonus visuel qui devient un signal de réputation
BIMI (Brand Indicators for Message Identification) permet d'afficher le logo de la marque dans la boîte de réception (rond bleu Gmail, vignette Apple Mail). Pour l'activer, il faut :
- Une politique DMARC en p=quarantine ou p=reject (pas p=none).
- Un logo SVG carré au format SVG Tiny Portable/Secure (.svg).
- Idéalement un certificat VMC (Verified Mark Certificate) émis par DigiCert ou Entrust — payant, autour de 1 200 € à 1 800 € HT par an — pour activer l'affichage chez Gmail et Apple Mail.
Au-delà de l'aspect cosmétique, BIMI envoie aux filtres anti-spam un signal de sérieux et de continuité d'identité. Les boutiques BIMI gagnent en moyenne 2 à 4 points de taux d'ouverture sur les newsletters, et marginalement sur le transactionnel (où le taux d'ouverture est déjà très haut).
## Pourquoi vos emails PrestaShop finissent en spam — les six causes principales
### 1. Envoi via le serveur web par défaut (PHP mail)
PHP mail() depuis un serveur partagé OVH, o2switch, Hetzner ou cPanel quelconque : IP partagée avec des centaines de domaines, pas de signature DKIM par défaut, pas de boucle de rétroaction. Cause numéro un de mise en quarantaine immédiate par Gmail.
La règle saine en 2026 : **tous les emails passent par un SMTP authentifié**, qu'il soit chez Brevo, Mailjet, Sendgrid, Postmark, AWS SES, Scaleway TEM, ou un SMTP self-hosted bien configuré. Cela impose à PrestaShop d'utiliser le module Symfony Mailer en mode SMTP.
### 2. SPF non aligné
SPF correct sur le domaine d'envoi, mais l'adresse Return-Path pointe sur un sous-domaine non couvert. Résultat : SPF passe mais ne s'aligne pas avec le From visible. DMARC échoue. Le diagnostic se fait avec un rapport DMARC aggregate (RUA) : on voit immédiatement le décalage.
### 3. DKIM expirée ou rotation oubliée
La clé DKIM publiée en DNS doit être en rotation périodique (semestrielle ou annuelle). Beaucoup de boutiques l'installent au lancement puis l'oublient. Au bout de quelques années, la clé est compromise statistiquement (longueurs 1024 bits historiquement) et Gmail commence à pénaliser. Il faut une rotation propre, généralement gérée par le fournisseur SMTP.
### 4. Contenu HTML mal conçu
Email avec trop de liens vers des domaines tiers, ratio texte/image inversé (image en bandeau qui couvre 80 % du contenu, peu de texte), URL raccourcies (bit.ly et autres), absence de version texte plain. Ces signaux sont individuellement faibles, cumulés ils déclenchent les filtres bayésiens.
### 5. Volume erratique et listes mal entretenues
Boutique qui envoie un email transactionnel par jour pendant trois mois, puis 50 000 newsletters d'un coup. Pic atypique → suspicion. Et si la liste contient des adresses inactives ou des hard bounces non purgés, le taux de plaintes monte. Au-dessus de 0,3 %, Gmail commence à filtrer.
### 6. Listes empoisonnées
Adresses spam-trap (anciennes adresses recyclées par les FAI pour piéger les spammeurs). Une seule adresse spam-trap touchée plombe la réputation domaine pour plusieurs semaines. La prévention : double opt-in obligatoire, nettoyage régulier, validation au moment de la saisie (vérifier que l'adresse répond avant inscription).
## La checklist de mise au propre en 2026 — séquence en 6 étapes
### Étape 1 — Audit de l'existant
Vérifier ses enregistrements DNS avec dmarcian, MXToolbox ou Postmark DNS checker : SPF correct, DKIM publié, DMARC publié et lisible. Tester un envoi vers une adresse Gmail personnelle et inspecter les en-têtes (Authentication-Results) pour vérifier le pass/fail.
### Étape 2 — Mise en place d'un SMTP transactionnel authentifié
Brevo, Mailjet, Postmark ou AWS SES selon le volume. Configurer PrestaShop via le module Symfony Mailer (PS 8.1+) ou via un module SMTP tiers. Valider l'envoi d'un email test de la boutique : confirmation de commande, reset mot de passe, alerte prix.
### Étape 3 — Activation de DMARC en p=none avec reporting
Publier l'enregistrement DMARC avec p=none et l'attribut rua qui pointe vers une adresse dédiée (dmarc-rua@domaine.com) ou un service de monitoring (dmarcian, Postmark DMARC, OnDMARC). Laisser tourner 2 à 4 semaines pour collecter les rapports aggregate.
### Étape 4 — Analyse des rapports DMARC et correction des fuites
Les rapports identifient tous les services tiers qui envoient pour le domaine : SMTP transactionnel, plateforme newsletter, outil de support (Zendesk, Crisp), CRM, paie. Chacun doit être autorisé en SPF et signer en DKIM aligné. C'est l'étape qui prend le plus de temps en pratique.
### Étape 5 — Passage à p=quarantine puis p=reject
Une fois les rapports DMARC propres (>95 % d'alignement), monter en p=quarantine pendant 4 à 8 semaines, puis p=reject. À chaque palier, surveiller les bounces et les tickets clients.
### Étape 6 — BIMI et certificat VMC (optionnel mais utile)
Une fois en p=quarantine ou p=reject stable, publier un enregistrement BIMI avec logo SVG. Acheter un VMC si la marque est protégée (marque déposée) et que le volume justifie l'investissement.
## Le filtrage anti-spam interne — un sujet souvent oublié
Côté entrant, une boutique reçoit beaucoup de spam (contact form, faux devis, faux ordre…) qui pollue les BAL des équipes commerciales et qui parfois s'égare dans la base CRM. Un filtre de qualité côté entrant améliore la productivité et la sécurité (phishing entrant).
Côté DataFirefly, le module dfemailfilter applique un filtrage anti-spam serveur sur les domaines hébergés, avec règles SPF/DKIM/DMARC entrantes, score bayésien et liste noire dynamique. Utile pour le formulaire de contact PrestaShop et les emails B2B.
## Conclusion : la délivrabilité comme métrique e-commerce de premier rang
Beaucoup de marchands traitent l'email comme un sujet « informatique » à déléguer. C'est une erreur en 2026. La délivrabilité conditionne désormais : la conversion (panier abandonné non récupéré si l'email n'arrive pas), le support (tickets « je n'ai pas reçu ma facture »), la rétention (newsletters qui finissent au spam = relation client cassée), et la conformité (RGPD : preuve de consentement par double opt-in seulement valide si l'email arrive).
Une mise à niveau SPF/DKIM/DMARC propre prend 4 à 8 semaines de travail concentré et apporte généralement 5 à 15 points de taux d'ouverture côté marketing, sans toucher au contenu. C'est l'un des meilleurs ROI techniques de l'année.
Pour passer à l'action : [notre sélection de modules pour réduire l'abandon de panier](https://www.datafirefly.com/solutions/prestashop/panier-abandonne/), dont les relances dépendent directement de votre délivrabilité.
---
### Schema.org Product en 2026 : ce qui est obligatoire, ce qui est recommandé, et où déclarer retours et livraison
_Source :_ — _publié_ 2026-07-20
> Cinq propriétés seulement sont requises pour être éligible aux résultats produit. hasMerchantReturnPolicy et shippingDetails sont des enrichissements, à déclarer de préférence au niveau Organization. Ce que dit la documentation Google, et comment l'appliquer sur PrestaShop 8/9 et WooCommerce.
La documentation Google sur les fiches produit distingue deux choses que beaucoup d’articles mélangent : les propriétés requises pour qu’une page soit éligible à un résultat enrichi, et les propriétés qui enrichissent ce résultat quand elles sont présentes. Les informations de retour et de livraison relèvent de la seconde catégorie. Search Central les range explicitement parmi les enrichissements de résultat, avec les notes, la disponibilité et les baisses de prix.
Cet article reprend le balisage `Product` tel qu’il est documenté, section par section : ce qui est obligatoire, ce qui ne l’est pas, et où placer chaque bloc sur PrestaShop 8/9 et WooCommerce.
## Le socle obligatoire tient en cinq propriétés
Sur `Product` :
- `name`
- `image`, une ou plusieurs URLs crawlables et indexables
- `offers`
Sur `Offer` :
- `price`, ou `priceSpecification.price`
- `priceCurrency`, ou `priceSpecification.priceCurrency`
Trois contraintes s’ajoutent. Les expériences Merchant listing exigent un `Offer` et non un `AggregateOffer`, puisque c’est vous qui vendez. Le prix doit être strictement supérieur à zéro. Et la page doit porter sur un produit unique ou ses déclinaisons, pas sur une liste ou une catégorie.
Google distingue par ailleurs deux familles de balisage. Le _product snippet_ vise les pages où l’on ne peut pas acheter directement, typiquement un test éditorial, avec des options supplémentaires côté avis. Le _merchant listing_ vise les pages où le visiteur achète chez vous, avec les tailles, la livraison et les retours. Remplir les propriétés requises du merchant listing rend en général la page éligible aussi au product snippet.
## Tout le reste est recommandé
Le tableau des propriétés recommandées de `Offer` contient `availability`, `itemCondition`, `url`, `priceValidUntil`, `validFrom`, `validThrough`, `hasMerchantReturnPolicy` et `shippingDetails`. Côté `Product` : `brand.name`, `sku`, `mpn`, les `gtin`, `description`, `category`, `color`, `size`, `material`, `pattern`, `audience`, `hasCertification`, `review`, `aggregateRating`, `inProductGroupWithID`, `isVariantOf` et `subjectOf`.
Ces propriétés servent à débloquer des affichages : note moyenne, coût de livraison et livraison gratuite, disponibilité, informations de retour, baisse de prix. Google précise que ces enrichissements sont montrés à la discrétion de chaque expérience et peuvent évoluer, et conseille donc de fournir autant d’information produit que possible sans chercher à viser un affichage précis.
Le point qui tranche : la procédure de mise en production demande de corriger les erreurs critiques remontées par le Rich Results Test, puis ajoute que les problèmes non critiques peuvent améliorer la qualité du balisage, mais que les corriger n’est pas nécessaire pour être éligible aux résultats enrichis. Or « Missing field hasMerchantReturnPolicy » et « Missing field shippingDetails » remontent précisément en non critique dans la Search Console.
## Retours et livraison : le bon niveau est Organization
Pour une politique de retour qui couvre tout ou presque tout le catalogue, Google demande de la déclarer une seule fois, sur la page qui décrit cette politique, dans un `MerchantReturnPolicy` imbriqué sous `Organization` (ou `OnlineStore`) via `hasMerchantReturnPolicy`. Inutile de la répéter sur chaque page du site.
À ce niveau, deux options de balisage minimal :
- **Option A** : `applicableCountry` et `returnPolicyCategory`. Si la catégorie vaut `MerchantReturnFiniteReturnWindow`, alors `merchantReturnDays` devient obligatoire.
- **Option B** : `merchantReturnLink`, l’URL de la page qui décrit la politique aux clients.
Le reste est recommandé et permet d’être précis : `returnFees`, `returnMethod`, `returnShippingFeesAmount`, `returnPolicyCountry`, `refundType`, `restockingFee`, `returnLabelSource`, `itemCondition`, les variantes `customerRemorse*` et `itemDefect*`, et `returnPolicySeasonalOverride` pour restreindre la fenêtre pendant les fêtes.
```
{
"@context": "https://schema.org",
"@type": "OnlineStore",
"name": "Ma boutique",
"url": "https://example.com",
"hasMerchantReturnPolicy": {
"@type": "MerchantReturnPolicy",
"@id": "https://example.com/retours#policy",
"applicableCountry": ["FR", "BE", "LU"],
"returnPolicyCountry": "FR",
"returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
"merchantReturnDays": 30,
"returnMethod": "https://schema.org/ReturnByMail",
"returnFees": "https://schema.org/FreeReturn",
"refundType": "https://schema.org/FullRefund"
}
}
```
Le niveau `Offer` ne sert qu’à deux cas : déroger à la politique standard pour un produit précis, ou n’avoir aucune politique standard. Les propriétés supportées y sont un sous-ensemble de celles disponibles au niveau boutique. Pour référencer sans ambiguïté la politique globale depuis une fiche, un simple `@id` suffit :
```
"hasMerchantReturnPolicy": { "@id": "https://example.com/retours#policy" }
```
La livraison suit la même logique. La politique standard se déclare sous `Organization`, avec un jeu de propriétés plus large que celui disponible au niveau produit, et une fiche peut y renvoyer via `hasShippingService` :
```
"shippingDetails": {
"@type": "OfferShippingDetails",
"hasShippingService": { "@id": "https://example.com/livraison#policy" }
}
```
Au niveau `Offer`, si vous décrivez la livraison en dur, quatre propriétés sont requises pour l’enrichissement : `deliveryTime` (avec `handlingTime` et `transitTime`), `shippingDestination` (avec `addressCountry` en ISO 3166-1 alpha-2), `shippingRate.currency` et `shippingRate.value` ou `shippingRate.maxValue`. Un tarif par bloc `OfferShippingDetails` : pour plusieurs tarifs, plusieurs blocs.
## Le balisage arrive en dernier dans l’ordre de priorité
Google documente un ordre de précédence pour les informations de retour, de la source la plus forte à la plus faible :
1. Content API for Shopping, réglages de retour
2. Réglages dans Merchant Center ou dans la Search Console
3. Balisage au niveau de la fiche produit
4. Balisage au niveau `Organization`
Deux conséquences pratiques. Si vos retours sont déjà configurés dans la Search Console ou dans Merchant Center, c’est cette configuration qui sera utilisée et le balisage devient redondant. Et l’absence de balisage sur une fiche ne se traduit pas par « pas de politique de retour » : Google descend simplement dans la chaîne pour trouver l’information. Pour un catalogue dont les frais de port bougent souvent, la documentation suggère d’ailleurs de passer par Merchant Center plutôt que par le balisage.
## priceValidUntil n’est pas une date à renouveler chaque année
Définition officielle : la date et l’heure après lesquelles le prix ne sera plus disponible, au format ISO 8601. La doc ajoute une seule mise en garde, et ce n’est pas celle qu’on lit partout : la fiche peut ne pas s’afficher si `priceValidUntil` indique une date _passée_. Le risque vient d’une date périmée, pas d’une propriété absente.
Depuis la refonte de la section consacrée à la durée des promotions, le rôle de cette propriété est précis : borner une remise. Le début se déclare avec `validFrom`, la fin avec `validThrough` ou `priceValidUntil`. Google recommande de fournir les deux bornes, de vérifier que le début précède la fin, et d’inclure l’heure et le fuseau horaire.
```
"offers": {
"@type": "Offer",
"price": 10.00,
"priceCurrency": "EUR",
"validFrom": "2026-11-20T08:00:00+01:00",
"priceValidUntil": "2026-11-30T23:59:59+01:00",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"priceType": "https://schema.org/StrikethroughPrice",
"price": 15.00,
"priceCurrency": "EUR"
}
}
```
Attention au placement. Sur le nœud `Offer`, `priceValidUntil` et `validThrough` sont interchangeables. Sur un nœud `PriceSpecification`, seul `validThrough` fonctionne : `priceValidUntil` n’y est pas applicable.
Si votre prix n’a pas de date de fin réelle, ne mettez pas de `priceValidUntil`. Une date glissante à un an, générée automatiquement, ne décrit rien et revient à annoncer une fin de promotion qui n’existe pas.
## Prix barré, prix membre, prix au litre
Trois types de prix sont reconnus, encodés dans `priceSpecification` sous `Offer` :
- Prix actif : ni `priceType` ni `validForMemberTier`. Il peut aussi rester au niveau de l’offre, dans `price`.
- Prix barré : `priceType` à `https://schema.org/StrikethroughPrice`. C’est lui qui déclenche l’affichage promotionnel, le prix actif devenant le prix soldé.
- Prix membre : `validForMemberTier` pointant vers un `MemberProgramTier` défini dans Merchant Center ou dans un `MemberProgram` sous `Organization`.
Les deux marqueurs ne se combinent pas : une spécification de prix portant à la fois `priceType` et `validForMemberTier` est ignorée. Si vous renseignez à la fois `offers.price` et `offers.priceSpecification` pour le prix actif, Google retient `offers.price`.
Pour les produits vendus au volume, au poids ou à la longueur, le prix unitaire passe par `referenceQuantity` dans un `UnitPriceSpecification`. La documentation signale que ce format compte particulièrement dans l’Union européenne, en Nouvelle-Zélande et en Australie.
## Déclinaisons : ProductGroup, deux structures possibles
Une seule propriété est requise sur `ProductGroup` : `name`. L’identifiant du groupe se déclare soit par `productGroupID` sur le `ProductGroup` (le SKU parent), soit par `inProductGroupWithID` sur chaque variante. Si vous renseignez les deux, ils doivent correspondre. `variesBy` liste les axes de variation, avec six valeurs supportées : `color`, `size`, `material`, `pattern`, `suggestedAge` et `suggestedGender`.
Deux structures sont documentées. Soit les variantes sont imbriquées dans le `ProductGroup` via `hasVariant`, soit elles sont déclarées à côté et renvoient au parent via `isVariantOf` et un `@id`. Google recommande la première, décrite comme la représentation la plus compacte et la plus naturelle. La seconde est souvent plus simple à générer depuis un CMS.
Les contraintes techniques comptent autant que le balisage. Chaque variante a besoin d’un identifiant unique (`sku` ou `gtin`) et d’une URL distincte permettant de la présélectionner, avec la bonne image, le bon prix, la bonne disponibilité et la possibilité de l’ajouter au panier. Sur un site où tout se joue sur une page, une seule URL canonique représente le groupe. Sur un site multi-pages, chaque page doit porter un balisage complet et autonome, avec la définition du `ProductGroup` répétée.
## Étiquetage énergétique : hasCertification
Pour l’électroménager, les ampoules ou les écrans vendus dans l’Union européenne, la propriété à utiliser est `hasCertification`, avec un objet `Certification` :
- `issuedBy.name` : `EC` ou `European_Commission` pour les étiquettes énergie UE, `ADEME` et `BMWK` pour les classes de CO2 des véhicules.
- `name` : `EPREL`, `Vehicle_CO2_Class` ou `Vehicle_CO2_Class_Discharged_Battery`.
- `certificationIdentification` : le code EPREL, requis pour les étiquettes énergie européennes.
- `certificationRating` : à utiliser quand le code EPREL n’existe pas (Norvège, Suisse, Royaume-Uni) ou pour les classes CO2. `ratingValue` est requis, et pour l’efficacité énergétique `bestRating` et `worstRating` le sont aussi.
Jusqu’à dix certifications par produit. L’ancienne propriété `hasEnergyConsumptionDetails` reste lue, mais la documentation recommande de basculer vers `hasCertification`.
## Et les AI Overviews ?
Aucune documentation publique de Google ne conditionne l’apparition dans les AI Overviews à `hasMerchantReturnPolicy`, `shippingDetails` ou une autre propriété de `Product`. Ces propriétés sont documentées pour les expériences Merchant listing : panneau de connaissances Shopping, Popular products, Google Images, Google Lens, product snippets.
Un balisage propre aide les systèmes de Google à comprendre la page, ce qui reste une bonne raison de le soigner. Mais tant qu’aucune documentation ni étude reproductible ne l’établit, mieux vaut ne pas construire d’arbitrage budgétaire sur un lien de cause à effet entre ces propriétés et les réponses génératives.
## Implémentation sur PrestaShop 8 et 9
Le thème Classic produit un JSON-LD `Product` avec `offers`, mais ni les politiques de retour et de livraison, ni la structure `ProductGroup` pour les déclinaisons. Deux chantiers distincts, à ne pas confondre.
**Côté catalogue.** Soit vous surchargez le template qui émet le JSON-LD dans votre thème enfant, avec la maintenance que cela implique à chaque montée de version, soit vous passez par un module. Dans les deux cas, vérifiez qu’un seul bloc `Product` est émis par page : deux modules SEO actifs en même temps produisent deux balisages concurrents.
**Côté boutique.** La politique de retour et la politique de livraison se déclarent une fois, sur les pages CMS correspondantes, dans un bloc `Organization`. Le plus simple reste un champ de code personnalisé injecté dans le head de ces deux pages.
Le module [DataFirefly All in One SEO](https://www.datafirefly.com/product/dfallinoneseo/) couvre le premier chantier : graphe JSON-LD avec Organization, WebSite, BreadcrumbList, `Product` incluant `offers`, `priceValidUntil` et l’`AggregateRating` issue de productcomments, plus FAQPage et LocalBusiness. Il fournit aussi les champs de code personnalisé head et fin de body, dans lesquels déclarer les politiques au niveau boutique.
## Implémentation sur WooCommerce
WooCommerce émet nativement un `Product` avec `offers`, modifiable via le filtre `woocommerce_structured_data_product`. Yoast SEO et Rank Math génèrent chacun leur propre graphe et exposent leur propre point d’extension. Choisissez une seule de ces trois sources : cumuler revient à publier plusieurs blocs `Product` sur la même URL.
Pour les politiques, la logique est identique à PrestaShop : un bloc `Organization` sur la page de retours et sur la page de livraison, référencé depuis les fiches par `@id` si vous voulez lever toute ambiguïté. Le plugin [llms.txt + AEO Schema WooCommerce](https://www.datafirefly.com/product/llms-txt-aeo-woocommerce-schema-ia/) gère cette partie graphe et FAQ pour les agents.
## Vérifier le résultat
1. **Rich Results Test.** Corrigez les erreurs critiques. Les avertissements non critiques restent à votre main : arbitrez selon les enrichissements que vous voulez obtenir.
2. **Validateur schema.org.** Syntaxe JSON-LD et cohérence des `@type`, indépendamment des règles Google.
3. **Search Console, rapport Merchant listings.** L’état réel en production, une fois les pages recrawlées. Comptez plusieurs jours après publication.
4. **Merchant Center ou Search Console, réglages de retour.** Vérifiez qu’une configuration existante ne prend pas déjà le pas sur votre balisage.
## Par où commencer
1. Vérifier que `name`, `image`, `offers`, `price` et `priceCurrency` sont présents et exacts sur 100 % des fiches. C’est le seul point réellement bloquant.
2. Ajouter `availability`, `itemCondition`, `sku`, `brand.name`, et le GTIN quand il existe.
3. Déclarer la politique de retour et la politique de livraison une fois, au niveau `Organization`, sur les pages dédiées.
4. Ne poser `priceValidUntil` que sur les prix qui ont une date de fin réelle, avec `validFrom` en face.
5. Traiter les déclinaisons avec `ProductGroup`, après s’être assuré que chaque déclinaison possède bien une URL propre.
Une règle chapeaute le tout : le balisage doit décrire ce que la page affiche. Un retour gratuit balisé doit être annoncé sur le site, un délai de 30 jours balisé doit être un délai de 30 jours effectif. C’est ce principe, et non le nombre de propriétés, qui explique la plupart des actions manuelles sur données structurées.
À lire aussi : [le guide complet du SEO e-commerce](https://www.datafirefly.com/2026/05/01/seo-ecommerce-guide-complet-2026/) et [le FAQ schema et les rich snippets](https://www.datafirefly.com/2026/05/09/prestashop-faq-schema-rich-snippets-google-guide-2026/).
Pour passer à l'action : [notre sélection de modules pour optimiser vos fiches produit](https://www.datafirefly.com/solutions/prestashop/fiche-produit/).
---
### Accessibilité WCAG 2.2 et European Accessibility Act : où en est la conformité PrestaShop un an après l'entrée en vigueur
_Source :_ — _publié_ 2026-07-16
> Le European Accessibility Act est entré en vigueur le 28 juin 2025. Un an plus tard, la majorité des boutiques PrestaShop sont toujours hors-clous. Voici le cadre exact, les sanctions appliquées et la checklist d'audit WCAG 2.2 pour mettre une boutique en conformité sans refondre le thème.
Le 28 juin 2025 a marqué l'entrée en vigueur du **European Accessibility Act** (directive UE 2019/882) pour la plupart des produits et services e-commerce vendus à des consommateurs européens. Un an plus tard, le constat de terrain est limpide : la majorité des boutiques PrestaShop opérant en France ne sont pas conformes — et la plupart des marchands l'ignorent encore.
Le sujet n'est pas qu'éthique. C'est désormais un risque juridique, commercial (perte de marchés publics, B2B sensibles) et de réputation. Cet article fait le point sur le cadre légal réel, les sanctions effectivement appliquées en France depuis un an, et la feuille de route technique pour mettre une boutique PrestaShop 8 ou 9 en conformité **sans refondre le thème**.
## Le cadre légal qui s'applique à une boutique PrestaShop en 2026
L'EAA est transposé en droit français par l'ordonnance du 6 septembre 2023, modifiant le Code de la consommation. Le périmètre est large : tout service e-commerce destiné à des consommateurs européens est concerné — site web, application mobile, processus d'achat, communication post-vente.
Deux exemptions structurantes :
- **Les micro-entreprises** au sens européen (moins de 10 salariés ET chiffre d'affaires ou bilan inférieur à 2 M€) sont exemptées pour leurs services. Attention : le seuil s'apprécie au niveau du groupe.
- **Les contenus tiers** non maîtrisés (commentaires utilisateurs bruts, par exemple) ne sont pas dans le périmètre, mais le marchand reste responsable de la structure d'accueil de ces contenus.
La norme technique de référence en France est le **RGAA 4.1** (qui s'aligne sur WCAG 2.1 niveau AA). En pratique, la norme internationale qui guide le travail au quotidien est **WCAG 2.2**, publiée en octobre 2023, qui ajoute neuf critères de succès — notamment le focus visible (2.4.11), les cibles de pointage suffisamment grandes (2.5.8) et la persistance des éléments d'aide (3.2.6). Une boutique conforme WCAG 2.2 AA est conforme RGAA 4.1.
## Les sanctions effectivement appliquées en France depuis un an
Le contrôle est réparti entre la DGCCRF (volet consommateur) et l'ARCOM (volet contenu numérique). En un an, le constat est le suivant :
- **Phase pédagogique majoritaire** : les premiers contrôles 2025 ont surtout débouché sur des mises en demeure et des engagements correctifs. Peu d'amendes fermes.
- **Durcissement à partir du T1 2026** : plusieurs amendes administratives ont été notifiées, échelonnées de 5 000 € à 75 000 € selon la taille de l'opérateur et la gravité (absence totale de déclaration d'accessibilité notamment).
- **Le plafond légal est élevé** : jusqu'à 250 000 € pour une personne morale en cas de récidive ou de manquement caractérisé.
- **Risque indirect probablement supérieur** : exclusion des marchés publics, refus de référencement par des centrales d'achat B2B, signalements clients sur les comparateurs.
L'obligation visible la plus systématiquement contrôlée est la **déclaration d'accessibilité**, qui doit être publiée sur le site, datée, et indiquer le niveau de conformité atteint (totalement / partiellement / non conforme) ainsi qu'un schéma pluriannuel de mise en conformité. Une boutique sans cette page est immédiatement repérée.
## L'audit terrain : ce qui pèche réellement sur PrestaShop
Sur la base des audits que nous menons sur des thèmes Classic, Hummingbird, Warehouse et thèmes sur mesure, les non-conformités récurrentes se concentrent sur six familles :
### 1. Contraste insuffisant (critère WCAG 1.4.3 / 1.4.11)
Le gris clair sur fond blanc utilisé pour les prix barrés, les mentions « TVA incluse », ou les pictos de réassurance échoue presque systématiquement le ratio 4.5:1 (texte normal) ou 3:1 (texte large et interfaces). Une passe d'audit avec Lighthouse ou axe-core sort en général 15 à 40 défauts de contraste sur une fiche produit standard.
### 2. Navigation clavier cassée
Le menu déroulant top, les filtres de la facette à gauche, le sélecteur de quantité custom, le popup newsletter — tous ces composants sont fréquemment inaccessibles au clavier seul (touche Tab + Entrée + Espace). Le focus visible disparaît dans la moitié des thèmes premium. C'est un critère bloquant.
### 3. Formulaire de checkout non étiqueté correctement
Champ sans attribut label associé, indication d'erreur en couleur seule (rouge), pas d'attribut aria-describedby pour les contraintes (« 8 caractères minimum »), récapitulatif inaccessible au lecteur d'écran. Le checkout one-page natif PrestaShop 8 a fait des progrès mais reste à compléter, surtout dès qu'un module de paiement ou un sélecteur d'adresse tiers est ajouté.
### 4. Images sans texte alternatif structuré
Le bon vieux problème : tous les visuels produit ont un attribut alt vide ou répété (nom du produit copié-collé). La logique correcte : alt vide pour les visuels purement décoratifs (alt=""), alt descriptif et différencié pour les vues secondaires (« vue de dos », « détail couture »). PrestaShop ne le fait pas automatiquement, c'est au marchand de le saisir à l'import catalogue.
### 5. Vidéos et carrousels automatiques
Carrousel home qui défile tout seul sans bouton pause, vidéo produit en autoplay : violation directe du critère 2.2.2 (Mise en pause, arrêt, masquage). Et techniquement, pour un visiteur avec un trouble vestibulaire, le défilement automatique peut déclencher un malaise.
### 6. Captcha bloquant et popups intrusifs
reCAPTCHA v2 « cochez la case » sans alternative pour utilisateurs de lecteurs d'écran, popup newsletter sans piège à focus, modale cookies impossible à fermer au clavier. Trois classiques que tout audit DGCCRF relève en quelques minutes.
## Feuille de route de mise en conformité — sans refondre le thème
Bonne nouvelle : la majorité des boutiques peuvent atteindre une conformité substantielle WCAG 2.2 AA en 4 à 8 semaines de travail ciblé, sans refonte complète. Voici la séquence qui fonctionne :
### Semaine 1 — Audit chiffré
Lancer un audit automatisé (axe DevTools, WAVE, Lighthouse) sur 10 pages représentatives : accueil, catégorie, fiche produit, panier, étape de livraison, étape de paiement, confirmation, blog, contact, déclaration légale. Doubler avec un test manuel clavier seul + un test lecteur d'écran (NVDA gratuit sur Windows, VoiceOver sur Mac). Sortir une matrice « critère / page / sévérité » avec scores.
### Semaines 2 à 3 — Corrections de surface à fort impact
- Reprise de la palette de couleurs pour atteindre les ratios de contraste — souvent une variable CSS à ajuster, voire deux ou trois.
- Ajout d'un focus visible global et lisible (outline 2 pixels avec une couleur contrastée).
- Reprise des libellés alt sur le catalogue : règle automatisable via un script SQL ou un [module de corrections WCAG automatiques](https://www.datafirefly.com/product/accessibilite-eaa-prestashop/).
- Suppression des autoplay et ajout d'un contrôle de pause sur le carrousel.
### Semaines 4 à 5 — Composants critiques
- Refonte du menu principal avec gestion clavier complète (Tab, Entrée, Échap, flèches).
- Étiquetage ARIA correct des filtres facette, du sélecteur de quantité, des notifications panier.
- Reprise des formulaires : labels associés, indications d'erreur en texte ET en couleur, focus sur le premier champ en erreur.
### Semaines 6 à 7 — Conformité éditoriale et déclaration
- Audit des pages CMS et articles de blog (structure de titres, images alt).
- Rédaction et publication de la déclaration d'accessibilité conforme au modèle officiel (état de conformité, dérogations justifiées, retour utilisateur, voie de recours).
- Schéma pluriannuel de mise en conformité publié sur la même page.
### Semaine 8 — Test utilisateur et documentation
Un test avec un utilisateur réel en situation de handicap (déficience visuelle ou motrice) reste le seul moyen de valider qu'on n'a pas raté un critère subtil. C'est aussi un argument en cas de contrôle : prouver une démarche d'amélioration continue.
## Le piège des modules tiers
L'angle mort majeur : les modules tiers ajoutent en permanence des éléments non audités. Une popup wishlist, un module de cross-sell avec carrousel, un widget d'avis tiers — chaque ajout peut casser la conformité acquise. La règle saine : auditer chaque nouveau module avec axe-core avant déploiement, et exiger du développeur une déclaration de compatibilité WCAG 2.2 AA.
Côté DataFirefly, l'ensemble des modules récents (panier latéral, alertes, recherche live, page builder) sont testés axe-core et lecteur d'écran avant publication, et la déclaration de conformité technique est fournie sur demande pour les marchands en contrôle DGCCRF.
## Conclusion : le risque n'est plus théorique
L'argument « personne ne contrôle » n'est plus tenable un an après l'entrée en vigueur de l'EAA. Les amendes commencent à tomber, la déclaration d'accessibilité est devenue le minimum visible, et la pression B2B s'intensifie (centrales d'achat, marchés publics, donneurs d'ordres grand compte exigent désormais des engagements WCAG dans leurs contrats).
Le bon angle stratégique pour un marchand PrestaShop n'est pas de faire le minimum cosmétique, mais d'utiliser la mise en conformité comme un audit UX général : la majorité des correctifs accessibilité améliorent _aussi_ la conversion (lisibilité, contraste, navigation clavier appréciée des power-users, structure sémantique meilleure pour le SEO et l'AEO). Un investissement de 4 à 8 semaines qui sert plusieurs objectifs. Pour couvrir les autres volets réglementaires de la fiche produit (Omnibus, GPSR, garantie légale, ESPR), notre [sélection de modules de conformité produit PrestaShop](https://www.datafirefly.com/solutions/prestashop/conformite-produits/) complète ce chantier.
À lire aussi : [la checklist GPSR](https://www.datafirefly.com/2026/06/04/gpsr-2026-checklist-conformite-produit-prestashop/) et [la directive Omnibus et le prix de référence](https://www.datafirefly.com/2026/06/22/directive-omnibus-prix-reference-promotions-prestashop-2026/).
Pour passer à l'action : [notre sélection de modules pour l'accessibilité et la conformité EAA](https://www.datafirefly.com/solutions/prestashop/accessibilite-eaa/).
---
### Recherche interne PrestaShop 8 en 2026 : pourquoi le moteur natif sabote vos ventes (et comment mesurer le coût)
_Source :_ — _publié_ 2026-07-12
> 15 à 30 % des visiteurs passent par la barre de recherche, avec une intention d'achat 2 à 5 fois supérieure à la moyenne. Et la recherche native PrestaShop ne les sert pas. Voici comment quantifier le coût et ce que change un live search bien fait.
Sur la plupart des boutiques PrestaShop, la barre de recherche est utilisée par 15 à 30 % des visiteurs. Et c'est exactement ce segment qu'il faut surveiller : un visiteur qui tape une requête dans la barre de recherche a une intention d'achat 2 à 5 fois plus forte qu'un visiteur en navigation passive. Les études Baymard et Forrester convergent depuis dix ans sur cette donnée — la recherche interne convertit mieux que le reste du trafic.
Le problème : la recherche native de PrestaShop est techniquement faible. Pas de suggestion temps réel, pas de tolérance aux fautes de frappe, pas de pondération du tri, pas d'analytics. Sur ce segment ultra-rentable, la boutique offre l'équivalent d'un fichier texte avec un `grep`. Et personne ne mesure le coût.
Cet article décortique pourquoi la recherche interne est un levier de conversion souvent ignoré, comment quantifier ce qu'elle vous coûte aujourd'hui, et ce que change un live search bien fait.
## Le profil du visiteur qui utilise la recherche
Comprendre l'enjeu commence par comprendre qui cherche. Les analyses comportementales montrent trois profils dominants :
### 1. Le visiteur transactionnel
Il sait ce qu'il veut. « Robe rouge taille 38 », « iPhone 17 Pro 256 Go », « Casque audio Bose ». Son intention d'achat est élevée, il accepte mal les frictions. Si la recherche ne lui donne pas ce qu'il cherche en 2-3 secondes, il quitte la boutique et tape sa requête dans Google.
### 2. Le visiteur exploratoire
Il a une idée vague. « Cadeau pour homme », « Chaussures été », « Pantalon confortable ». Son intention est moins immédiate mais il est ouvert. Une recherche qui propose des suggestions pertinentes oriente sa décision.
### 3. Le visiteur revenu
Il connaît la boutique, il a vu un produit dans une précédente visite, il le recherche par nom partiel ou approximatif. La tolérance aux fautes et la mémoire contextuelle font la différence.
Tous trois convertissent **2 à 5 fois plus que la moyenne du site** si la recherche les sert correctement. Et tous trois sortent perdants si elle échoue.
## Ce que la recherche native PrestaShop ne fait pas
Le moteur natif de PrestaShop 8 (et 9) repose sur un index plein-texte MySQL ou Elasticsearch optionnel. Il fonctionne, mais avec des lacunes structurelles :
### Pas de tolérance aux fautes
« Sambba » ne renvoie pas les Adidas Samba. « Iphon » ne renvoie pas les iPhone. Le visiteur voit « Aucun résultat » et part. Sur une boutique mode, 8 à 15 % des recherches contiennent au moins une faute de frappe. Tous ces visiteurs sont perdus.
### Pas de suggestion en temps réel
Le visiteur doit valider sa recherche (touche Entrée ou clic sur la loupe), puis attendre le chargement de la page de résultats. Pendant ce temps, l'attention chute. La concurrence (Amazon, marketplaces) propose des suggestions instantanées. La comparaison est cruelle.
### Pas de pondération produit
Une recherche « robe » renvoie tous les produits contenant le mot, sans tri intelligent : les bestsellers, les nouveautés, les produits en stock ne sont pas favorisés. Le visiteur tombe sur un produit en rupture, un produit obsolète, ou un produit hors-saison. Conversion ratée.
### Pas d'analytics
Combien de recherches par jour ? Quelles requêtes ne donnent aucun résultat ? Quelles requêtes ont un taux de clic faible ? Sans cette donnée, impossible d'optimiser le catalogue ou de détecter les opportunités produit.
### Performance limitée
Sur un catalogue de plus de 10 000 produits, la recherche plein-texte MySQL devient lente (200-500 ms). Avec un index Elasticsearch correctement configuré, on tombe sous les 50 ms — mais l'installation et la maintenance Elasticsearch sont rarement assumées.
## Le coût réel d'une recherche mal faite : comment le mesurer
La plupart des e-commerçants n'ont aucune idée du coût de leur recherche actuelle, parce qu'ils ne la mesurent pas. Voici les trois KPI minimum à instrumenter, même sans module dédié :
### Taux de recherche zéro résultat
Combien de requêtes renvoient zéro produit ? Si vous êtes au-dessus de 8-10 %, vous avez un problème de catalogue ou de tolérance aux fautes. Chaque zéro résultat est un visiteur frustré.
### Taux de clic sur résultats de recherche
Le visiteur a tapé sa requête, il a vu les résultats — combien cliquent sur un produit ? Si le CTR est sous les 40 %, le tri ou la pertinence sont en cause.
### Taux de conversion post-recherche
Sur les sessions qui passent par la recherche, quel est le taux de conversion ? Comparé au taux global, vous devriez observer x1,5 à x3. Si vous êtes en dessous, votre recherche dessert son segment le plus rentable.
Sur une boutique générant 100 k€ de CA mensuel avec 25 % de visiteurs passant par la recherche, une recherche qui sous-performe de 30 % par rapport à son potentiel représente **5 à 8 k€ de CA perdu par mois**. À l'année : 60 à 100 k€. Et c'est invisible parce que personne ne le mesure.
## Ce que change un live search bien fait
### Suggestions instantanées en cours de frappe
Dès le 2e ou 3e caractère, une popin sous la barre affiche les produits correspondants, avec photo, prix, et lien direct vers la fiche. Le visiteur clique directement, sans passer par la page de résultats. Réduction du nombre de pages vues par recherche : ÷ 2 à 3, gain de conversion important.
### Tolérance aux fautes
Algorithme de distance de Levenshtein ou équivalent : « Sambba » trouve « Samba », « Iphon » trouve « iPhone ». Sur une boutique mode, ce seul ajustement récupère 8 à 15 % de recherches précédemment perdues.
### Tri intelligent
Les résultats prennent en compte plusieurs critères : pertinence textuelle, popularité (best-sellers), disponibilité (en stock d'abord), nouveauté, prix. Configurable selon la stratégie commerciale (boutique premium vs déstockage).
### Suggestions complémentaires
« Vous cherchez "robe" ? » suivi de catégories suggérées (Robes longues, Robes courtes, Robes de soirée). Le visiteur exploratoire est redirigé vers les catégories pertinentes. Augmentation des pages vues qualifiées.
### Analytics intégrées
Tableau de bord avec : top 20 des recherches, requêtes zéro résultat (= opportunités produit à créer), CTR par requête, taux de conversion post-recherche, évolution dans le temps. Données actionables, pas du reporting cosmétique.
### Performance
Indexation optimisée, requêtes en moins de 50 ms même sur 100 000+ produits, lazy loading des résultats, cache intelligent. La fluidité de l'expérience est aussi importante que la pertinence des résultats.
## Notre module dflivesearch : recherche qui convertit
Implémenter cette stack à la main demande 15 à 25 jours de dev : index optimisé, algorithme de matching avec tolérance aux fautes, frontend interactif, analytics. [Notre module dflivesearch](https://www.datafirefly.com/product/live-search-prestashop-suggestions-analytics-conversions/) pour PrestaShop 8 et 9 packagé toute la stack :
- **Suggestions temps réel** à partir du 2e caractère, avec photo produit, prix et stock.
- **Tolérance aux fautes** configurable (1-2 caractères de différence acceptés).
- **Tri intelligent** par pertinence pondérée (texte + popularité + stock + prix).
- **Suggestions de catégories et de tags** en plus des produits.
- **Analytics complètes** : top requêtes, zéro résultat, CTR, conversion, évolution temporelle.
- **Performance optimisée** : requêtes < 50 ms jusqu'à 100 000 produits.
- **Multilingue FR/EN/ES/DE** avec gestion par boutique multi-shop.
- **Compatible RGPD** : pas de cookie de tracking sans consentement.
- **Sans Elasticsearch requis** : fonctionne avec MySQL standard pour les boutiques jusqu'à 50 000 produits.
Pour 89 €, vous transformez le segment le plus rentable de votre trafic en machine de conversion.
## Trois optimisations rapides à faire même sans module
Si vous n'êtes pas prêt à installer un module dédié, trois optimisations gratuites peuvent déjà récupérer une partie du gisement :
1. **Instrumenter les recherches zéro résultat.** Activer le log natif PrestaShop ou un script custom qui enregistre les requêtes sans match. Identifier les 20 requêtes les plus fréquentes en zéro résultat, et soit créer les produits correspondants, soit ajouter des synonymes/alias dans le module recherche.
2. **Configurer les tags et alias produits.** Le moteur natif PrestaShop accepte les tags. Bien renseigner les tags des produits (synonymes, variantes orthographiques, abréviations) améliore la pertinence sans changer de moteur.
3. **Promouvoir la barre de recherche.** Sur 30 % des thèmes, la barre est cachée ou peu visible. La rendre proéminente, surtout sur mobile, augmente son usage et donc le segment converti.
Ces trois actions sont rentables même sans module. Elles ne remplacent pas un live search complet, mais elles préparent le terrain.
## FAQ
### Faut-il un Elasticsearch pour avoir une bonne recherche ?
Non, pas systématiquement. Pour les boutiques de moins de 50 000 produits, un index MySQL bien configuré avec un module intelligent suffit largement et offre des performances sub-50 ms. Au-delà de 100 000 produits ou de besoins avancés (filtres dynamiques en temps réel), Elasticsearch devient pertinent. La complexité d'install et de maintenance reste un coût à prendre en compte.
### La recherche impacte-t-elle le SEO ?
Indirectement, oui. Une recherche qui convertit améliore l'engagement (temps sur site, pages vues), ce que Google interprète comme un signal de qualité. Et les requêtes internes captées sont une mine d'or pour identifier les requêtes Google qui méritent d'être travaillées — si vos visiteurs tapent souvent « chaussures cuir homme », c'est aussi probablement une requête à viser en SEO.
### Quelle différence entre live search et search bar améliorée ?
Le « live search » désigne spécifiquement l'affichage instantané de résultats pendant la frappe. Une « search bar améliorée » peut juste avoir l'auto-complétion sans afficher de résultats. Le gain de conversion vient principalement de l'affichage des résultats en temps réel, pas juste des suggestions textuelles.
### Comment gérer les recherches multi-mots ?
Le piège : « robe rouge soie » doit être traité avec une combinaison flexible. Un système strict (AND sur les trois mots) renvoie souvent zéro résultat. Un système lâche (OR) renvoie trop de bruit. La bonne pratique : matching AND prioritaire, fallback OR avec score réduit. dflivesearch gère cette logique par défaut.
### L'analytics du moteur de recherche pose-t-elle des problèmes RGPD ?
Pas si elle reste agrégée (combien de fois la requête X a été tapée, sans associer à un utilisateur identifiable). Si vous croisez la recherche avec l'identifiant utilisateur connecté, ça devient une donnée personnelle qui demande un traitement RGPD. dflivesearch reste sur de l'agrégé par défaut.
## Pour aller plus loin
La recherche interne est un des leviers les plus sous-exploités du funnel e-commerce. Voir aussi notre dossier sur l'[anatomie d'une fiche produit haute conversion](https://www.datafirefly.com/2026/05/13/anatomie-fiche-produit-haute-conversion-prestashop-8-2026/) (où la recherche est le point d'entrée principal du segment transactionnel), et le [guide des 12 leviers de conversion e-commerce](https://www.datafirefly.com/2026/05/01/taux-conversion-ecommerce-12-leviers-2026/). Trois angles complémentaires : capter (recherche), convaincre (fiche), conclure (panier-checkout).
Pour passer à l'action : [notre sélection de modules pour la recherche et la navigation](https://www.datafirefly.com/solutions/prestashop/recherche-navigation/).
---
### Alertes prix + retour en stock sur PrestaShop : récupérer le revenu différé que la majorité des boutiques laissent filer
_Source :_ — _publié_ 2026-07-08
> « Trop cher » et « En rupture » sont deux des principales causes d'abandon avant panier. Sans capture, le revenu est perdu. Avec deux modules d'alertes propres (prix + stock), les boutiques captent 3 à 8 % de CA additionnel net. Mécanique complète.
Deux moments tuent silencieusement la conversion sur une boutique PrestaShop : le visiteur qui considère un produit, le trouve trop cher et part — et le visiteur qui veut acheter un produit, le découvre en rupture de stock et part. Dans les deux cas, l'intention d'achat est réelle. Dans les deux cas, sans dispositif de capture, le revenu est perdu. Définitivement.
Pourtant, ces deux scénarios sont parmi les plus simples à monétiser : un système d'alertes propre capte l'email du visiteur, déclenche un message automatique quand la condition est réunie (baisse de prix ou retour en stock), et convertit. Le ROI sur les boutiques bien équipées est mesurable : 3 à 8 % de revenu additionnel net, avec un coût opérationnel proche de zéro.
Cet article décortique les deux mécaniques, leurs synergies, les patterns qui marchent, et les pièges qui rendent les modules d'alerte inefficaces.
## Pourquoi les alertes prix et stock sont une mine de revenu négligée
Sur une boutique standard, le funnel se concentre sur la conversion immédiate : optimiser la fiche produit, le panier, le checkout. Tout ce qui se passe APRÈS l'abandon est traité avec un seul outil — le panier abandonné, qui couvre uniquement les utilisateurs ayant déjà mis le produit au panier.
Mais avant le panier, 80 à 90 % des visiteurs partent. Beaucoup partent _parce qu'un signal les bloque_ :
- **« Trop cher »** — le produit est désirable, mais hors budget perçu. Le visiteur compare ailleurs, attend les soldes, ou abandonne.
- **« Rupture de stock »** — la taille ou la couleur désirée n'est pas disponible. Le visiteur cherche ailleurs et trouve un concurrent.
Ces deux signaux ne sont pas des objections sur le produit. Ce sont des freins circonstanciels. Si on capte l'intention et qu'on revient vers le visiteur quand la condition change, le taux de conversion sur ce segment dépasse souvent les 15 à 25 % — bien au-dessus du taux de conversion moyen d'une boutique (2 à 4 %).
## L'alerte baisse de prix : la mécanique qui marche
### Le déclencheur visuel
Sur la fiche produit, à côté du prix, un bouton ou un lien discret : « Recevoir une alerte en cas de baisse de prix ». La formulation est importante : pas « M'alerter », trop vague, mais l'engagement explicite — alerte conditionnelle, pas newsletter.
### La capture
Le visiteur saisit son email (RGPD-compliant, consentement explicite, finalité limitée à l'alerte produit). Le système enregistre : email, id_produit, id_attribute si déclinaison, prix au moment de l'inscription, date.
### Le déclenchement
Quand le prix du produit baisse (changement de specific_price, soldes, promo flash), le système compare le nouveau prix au prix d'inscription. Si la baisse dépasse un seuil configurable (1 %, 5 %, 10 % selon la stratégie), une notification email est envoyée immédiatement.
### L'email d'alerte
Court, direct, avec :
- La photo du produit et son nom.
- L'ancien prix barré et le nouveau prix en gros.
- Le pourcentage de réduction.
- Un bouton « Voir le produit » qui pointe directement vers la fiche.
- Optionnellement : un compte à rebours si la promotion est limitée dans le temps.
### Le tracking de conversion
Sans tracking, l'alerte est aveugle. Il faut mesurer combien d'emails déclenchent un clic, combien de clics aboutissent à un achat, et quel revenu net cela génère. Sans cette boucle, impossible d'optimiser.
## L'alerte retour en stock : même logique, autre cible
### Le déclencheur
Sur une fiche produit en rupture (stock = 0, ou rupture sur une déclinaison spécifique), un bouton remplace « Ajouter au panier » : « Prévenez-moi du retour en stock ». Encore une fois, formulation engagée et claire.
### La capture par déclinaison
Détail crucial : la capture doit être au niveau de la déclinaison, pas du produit parent. Si le client veut la taille M en rouge, il ne veut pas être alerté pour le retour de la taille XL en bleu. Sans gestion fine de l'attribute, le module envoie des alertes non pertinentes et perd la confiance.
### Le déclenchement
Quand le stock revient (par hook `actionUpdateQuantity` ou cron de vérification), le système identifie toutes les inscriptions correspondantes et envoie les emails. Pour éviter les déclenchements parasites (stock à 1 unité épuisé en 5 min), prévoir un seuil minimum (par exemple, déclencher uniquement si stock > 3).
### L'urgence implicite
L'alerte stock joue sur la peur de manquer (FOMO) : « Le produit que vous attendiez est de nouveau disponible. Stock limité. » Inclure le stock disponible (« Plus que 8 en stock ») renforce l'incitation à l'action immédiate.
## La synergie des deux mécaniques
Les deux alertes captent deux profils différents :
AlerteProfil capturéDélai moyen de conversionBaisse de prixVisiteur hésitant sur le prix, comparateur, attentiste3 à 60 joursRetour en stockVisiteur engagé bloqué par la rupture, déçu1 à 14 jours
Sur une boutique mode, le retour en stock convertit à 25-35 % (intention d'achat très forte). Sur une boutique tech ou high-tech, l'alerte prix convertit à 8-15 % (cycle de décision plus long). Les deux mécaniques sont complémentaires et leur valeur dépend du secteur.
Les boutiques qui les déploient simultanément observent souvent une montée en CRM significative : les visiteurs deviennent des contacts qualifiés, segmentables par produit et par comportement.
## Les pièges qui rendent les alertes inefficaces
1. **Email d'alerte qui arrive 3 jours après le déclenchement.** La promotion est terminée, le produit est de nouveau en rupture. L'alerte doit partir dans les minutes qui suivent l'événement.
2. **Pas de tracking de conversion.** Impossible de mesurer le ROI, donc d'optimiser.
3. **Désinscription compliquée.** RGPD exige une désinscription en un clic. Sinon, le module devient une source de plaintes.
4. **Capture sans validation double opt-in.** Risque d'inscriptions spammées par des emails inexistants. La validation par lien (one-click) protège la délivrabilité.
5. **Pas de gestion des doublons.** Un client qui s'inscrit deux fois pour le même produit reçoit deux emails. Mauvaise UX, désabonnements en chaîne.
6. **Email trop générique.** Un mail « Le prix a baissé sur un produit que vous suiviez » sans le nom ni la photo du produit ne convertit pas. Le mail doit être personnalisé au produit exact.
7. **Pas de gestion de l'inactivité.** Au bout de 12 mois sans déclenchement, supprimer ou pruner les inscriptions pour ne pas spammer.
## Nos modules dfpricealert et dfwaitlist : combo industriel
Implémenter les deux mécaniques proprement demande 8 à 15 jours de dev par module, plus la stack email (templates, double opt-in, désinscription, délivrabilité). Nos modules [dfpricealert](https://www.datafirefly.com/product/datafirefly-price-alert-prestashop/) et [dfwaitlist](https://www.datafirefly.com/product/dfwaitlist-prestashop-alerte-retour-stock/) pour PrestaShop 8 et 9 industrialisent les deux :
### dfpricealert (49 €)
- Bouton d'inscription configurable sur fiche produit.
- Capture par produit ou par déclinaison.
- Détection automatique de baisse de prix avec seuil configurable.
- Email d'alerte personnalisé, multilingue FR/EN/ES/DE.
- Tracking de conversion (clic, vue produit, ajout panier, commande).
- Tableau de bord ROI : nombre d'inscriptions, taux d'ouverture, taux de clic, CA généré.
- Double opt-in et désinscription one-click.
- Gestion des doublons et purge automatique des inscriptions inactives.
### dfwaitlist (49 €)
- Remplacement automatique du bouton « Ajouter au panier » sur fiches en rupture.
- Capture par déclinaison (taille + couleur, par exemple).
- Déclenchement instantané au retour en stock avec seuil minimum.
- Email d'alerte avec stock disponible et urgence.
- Tracking de conversion complet.
- Tableau de bord par produit, par déclinaison, par période.
- Compatible multi-shop, multi-langue.
- RGPD natif (double opt-in, désinscription, purge).
Combinés à 98 €, les deux modules adressent l'intégralité du « revenu différé » que la majorité des boutiques laissent filer.
## ROI mesuré sur le terrain
Sur une boutique mode de 800 k€ de CA annuel avec un taux de rupture moyen de 12 % et des promotions régulières :
- **dfwaitlist** : environ 1 200 inscriptions/an, taux de conversion 28 %, panier moyen 65 € → **22 k€ de CA additionnel/an**.
- **dfpricealert** : environ 3 500 inscriptions/an, taux de conversion 11 %, panier moyen 55 € → **21 k€ de CA additionnel/an**.
- Coût des modules : 98 € one-shot.
- ROI annuel : ratio sans équivalent dans le catalogue.
Et l'effet CRM secondaire : 4 700 emails qualifiés ajoutés à la base, segmentables par produit suivi. Une base de prospection qualifiée pour les futures campagnes saisonnières.
## FAQ
### Faut-il combiner les alertes avec une newsletter générale ?
Non. Le RGPD impose une finalité explicite : si le client s'inscrit pour une alerte produit spécifique, on ne peut pas l'utiliser pour pousser une newsletter générale sans consentement séparé. Garder les deux flux distincts protège juridiquement et préserve la confiance.
### Comment éviter que les alertes saturent la base d'envoi ?
Plafonner le nombre d'alertes envoyées par client et par période. Par exemple : maximum 3 emails d'alerte par client par semaine, fusion intelligente si plusieurs alertes se déclenchent simultanément. dfpricealert et dfwaitlist gèrent ce throttling automatiquement.
### L'alerte prix peut-elle déclencher des achats spéculatifs ?
Oui, et c'est généralement positif. Un client qui s'inscrit à une alerte sur 5 produits et achète 3 quand le prix baisse, c'est un cycle d'achat normalement perdu sans le mécanisme. Le « risque » de baisse de prix pour booster les ventes existe déjà avec les soldes — l'alerte ne fait que le rendre adressable individuellement.
### Quel impact sur la délivrabilité email ?
Les alertes ont des taux d'ouverture élevés (30-50 %) et des taux de plainte bas (le client a explicitement demandé l'alerte). Bien géré, le flux d'alertes améliore la réputation d'envoi globale. Mal géré (sans double opt-in, sans désinscription claire), il peut au contraire dégrader. D'où l'importance de la stack RGPD.
### Doit-on intégrer avec un outil CRM externe (Klaviyo, Mailchimp) ?
Optionnel selon la maturité. Pour une petite boutique, l'envoi direct depuis PrestaShop suffit. Pour une boutique avec stratégie CRM mature, intégrer les inscriptions et conversions dans Klaviyo ou Brevo permet de segmenter plus finement et de croiser avec d'autres flows. Nos modules exposent des webhooks pour ce type d'intégration.
## Pour aller plus loin
Les alertes prix et stock sont une partie de la stratégie de conversion différée. Voir aussi notre [dossier sur la wishlist comme levier de conversion](https://www.datafirefly.com/2026/05/09/wishlist-prestashop-levier-conversion-alertes-prix-2026/) (les alertes prix sont d'ailleurs une fonctionnalité avancée de la wishlist sur certaines stacks), et le [guide cross-sell pour augmenter le panier moyen](https://www.datafirefly.com/2026/05/09/panier-moyen-prestashop-8-7-strategies-cross-sell-2026/). Trois leviers de revenu complémentaires : différer (alertes), engager (wishlist), enrichir (cross-sell).
Pour passer à l'action : [notre sélection de modules pour créer une urgence crédible](https://www.datafirefly.com/solutions/prestashop/urgence-rarete/), alertes de retour en stock comprises.
---
### Redirections 301, monitoring 404 et changement de slug : la mécanique SEO oubliée après chaque migration PrestaShop
_Source :_ — _publié_ 2026-07-04
> Sans gestion 301 propre, une migration PrestaShop fait perdre 25 à 50 % du trafic SEO en un trimestre — sans incident visible. Voici la stack qui sécurise les redirections : changement de slug auto, monitoring 404, regex, aplatissement de chaînes.
Lors d'une migration PrestaShop 1.7 vers 8, d'un changement de thème, d'une réorganisation de l'arborescence, ou simplement d'une modification de slug produit, des centaines voire des milliers d'URLs changent silencieusement. Chacune de ces URLs accumule du jus SEO, des liens entrants, et figure peut-être dans les résultats Google avec un bon classement. Sans redirection 301 vers la nouvelle URL, ce capital disparaît.
Le pire : la perte n'est pas immédiate. Vous voyez le trafic chuter doucement sur 3 à 6 semaines, sans incident clair. Le temps de comprendre, vous avez perdu 30 à 50 % du trafic SEO et il faudra 6 à 12 mois pour le récupérer — si vous y arrivez.
Cet article décortique la mécanique des redirections 301 sur PrestaShop : ce que fait le natif, ce qu'il rate, comment mettre en place un monitoring 404 propre, et comment automatiser le réflexe « slug change → redirection 301 ».
## Pourquoi les redirections 301 sont critiques pour le SEO
Une redirection 301 (« Moved Permanently ») dit à Google et aux utilisateurs : cette URL a déménagé définitivement, voici la nouvelle adresse. Google transmet alors le PageRank, l'historique de l'URL, les backlinks accumulés. La nouvelle URL hérite du capital SEO.
Sans 301, l'URL initiale renvoie une 404 (« Not Found »). Google met la page en file d'attente de désindexation, les backlinks pointent dans le vide, le PageRank se dissipe. Au bout de 3-6 mois, l'URL est retirée de l'index. Le capital est perdu.
Quelques chiffres d'audit, sur une boutique post-migration sans gestion 301 propre :
- **40 à 60 % des URLs indexées Google répondent en 404** dans les 6 mois.
- **Le trafic SEO chute de 25 à 50 %** dans le trimestre suivant.
- **Les positions sur les requêtes longue-traîne** (souvent les plus rentables) s'effondrent en premier.
- **Les backlinks externes** (presse, blogs, annuaires) deviennent obsolètes et perdent leur jus.
## Ce que PrestaShop gère nativement (et ce qu'il rate)
### Le module SEO & URLs natif
PrestaShop 8 et 9 propose un onglet « Redirections » dans Préférences > Trafic > SEO & URLs. Il permet d'ajouter manuellement des redirections 301 / 302 / 410 par paire (URL source, URL cible).
Limites :
- **Pas de gestion par regex ou wildcard.** Pour rediriger toute une ancienne catégorie `/anciens-produits/*` vers `/promotions/`, il faut créer manuellement chaque URL.
- **Pas de redirection automatique au changement de slug.** Si vous modifiez le slug d'un produit, l'ancienne URL part en 404 sans redirection.
- **Pas de monitoring 404** sur les URLs effectivement visitées.
- **Performance limitée.** Au-delà de quelques milliers de redirections, le module ralentit le routage.
- **Pas d'import/export** en CSV pour gérer en masse.
### Le fichier .htaccess
Alternative manuelle : écrire des règles `RewriteRule` dans `.htaccess`. Performant (Apache traite les règles en amont), mais :
- Sensible aux erreurs de syntaxe (une virgule mal placée, et tout le site tombe en 500).
- Difficile à maintenir pour les non-techniques.
- Ne fonctionne pas sur Nginx (qui utilise sa propre syntaxe).
- Pas d'interface BO ni de traçabilité.
## La stack qu'on devrait avoir
### 1. Redirection automatique sur changement de slug
Quand un produit, une catégorie ou un CMS change de slug, l'ancienne URL doit automatiquement enregistrer une 301 vers la nouvelle. Pas de manipulation manuelle, pas de risque d'oubli. C'est le filet de sécurité numéro 1.
### 2. Monitoring des 404
Toutes les URLs qui partent en 404 doivent être loggées avec leur fréquence et leur référent. Une URL appelée 200 fois par mois en 404 est un bug à traiter en priorité. Une URL en 404 une fois par an peut attendre.
### 3. Redirections en masse par regex et wildcard
Pour les migrations, on a besoin de patterns. `/categorie-ancienne/(.*) → /categorie-nouvelle/$1` doit pouvoir être configuré en une règle, pas en 200 entrées.
### 4. Import/export CSV
Avant une migration, on prépare la table de correspondance en CSV depuis l'export du sitemap ancien et le sitemap nouveau. On importe en une fois plutôt que de saisir à la main.
### 5. Détection des chaînes de redirection
Une URL qui redirige vers une URL qui redirige vers une URL est un anti-pattern SEO. Google déprécie les chaînes de plus de 2 hops. Un bon outil détecte et signale les chaînes.
### 6. Traçabilité et audit
Qui a créé telle redirection, quand, pour quel motif ? En cas de problème (chute de trafic post-migration), pouvoir auditer les règles 301 est crucial.
## Le cas particulier du changement de slug produit
Sur une boutique active, les slugs changent constamment. Un produit dont le nom évolue (« Robe été 2025 » → « Robe lin été 2025 »), une optimisation SEO de titre, une correction de typo — chaque modification du `link_rewrite` dans `ps_product_lang` change l'URL canonique.
Si la 301 n'est pas créée automatiquement, l'ancienne URL part en 404. Sur 12 mois, sur un catalogue de 5 000 produits avec 10 % de slugs modifiés, cela représente 500 URLs « perdues ». Si chacune drainait en moyenne 50 visites/mois, on parle de 25 000 visites SEO perdues par an, sans incident visible.
Le réflexe correct : un hook sur `actionObjectProductUpdateAfter` qui détecte le changement de `link_rewrite` et crée la 301 automatiquement, par langue et par boutique multi-shop.
## Le piège des chaînes de redirection
Scénario classique : un produit A change de slug 3 fois en 6 mois. Sans gestion fine, on se retrouve avec :
- `/slug-1.html → /slug-2.html`
- `/slug-2.html → /slug-3.html`
- `/slug-3.html → /slug-4.html`
Une requête sur la première URL fait 3 hops avant d'arriver. Google déprécie les chaînes de plus de 2 redirections. Le crawl budget est consommé inutilement, et le PageRank se dissipe à chaque hop (perte de 5 à 10 % par hop selon les études Moz).
La règle : **aplatir les chaînes**. Quand une nouvelle redirection est créée, le système doit chercher si l'URL source était déjà la cible d'une autre 301, et réécrire l'ancienne pour pointer directement sur la nouvelle cible. Plus de chaîne, plus de hop.
## Notre module dfredirects : gestionnaire 301 complet
Implémenter cette stack à la main demande 7 à 12 jours de dev sur PrestaShop, plus la maintenance. [Notre module dfredirects](https://www.datafirefly.com/product/gestionnaire-redirections-301-prestashop/) pour PrestaShop 8 et 9 industrialise toute la mécanique :
- **Redirections 301, 302, 410** configurables depuis le BO, avec interface filtrable et paginée.
- **Patterns regex et wildcard** : une règle peut couvrir des centaines d'URLs (`/old-cat/(.*)$ → /new-cat/$1`).
- **Redirection automatique au changement de slug** produit, catégorie, fabricant, fournisseur, CMS — multilingue et multishop.
- **Monitoring 404** avec fréquence, dernière visite, référent. Tri par volume pour prioriser.
- **Aplatissement automatique des chaînes** : pas de redirection en cascade.
- **Import/export CSV** pour gérer en masse avant migration.
- **Traçabilité** : auteur, date, motif optionnel par règle.
- **Compatible PS 8 et 9**, sans dépendance Apache/.htaccess (fonctionne aussi sur Nginx).
- **Performance** : table optimisée avec index, jusqu'à 100 000 règles sans dégradation.
Pour 49 €, vous évitez la perte de trafic post-migration et vous installez un filet de sécurité durable contre la dérive 404.
## Procédure de migration SEO-safe
Étape par étape, la procédure qu'on applique sur les migrations PrestaShop 1.7 → 8 ou les refontes majeures :
1. **Avant migration : export du sitemap.xml ancien**. Il contient toutes les URLs indexées.
2. **Crawl complet du site ancien** avec Screaming Frog ou équivalent, pour récupérer toutes les URLs (y compris pages hors sitemap : filtres, paginations).
3. **Mapping ancien → nouveau** en CSV : chaque URL ancienne reçoit son URL nouvelle. Pour les URLs disparues, choisir une cible alternative pertinente (catégorie parent, page d'accueil en dernier recours).
4. **Import du CSV dans dfredirects** avant ou pendant la bascule.
5. **Test : 50 URLs random vérifiées en 301** directement, sans chaîne, vers la bonne cible.
6. **Soumission du nouveau sitemap.xml à Google Search Console**.
7. **Monitoring 404 quotidien pendant le premier mois** : toute 404 récurrente est convertie en 301.
8. **Audit à 30, 60, 90 jours** : couverture Search Console, requêtes perdues, vérification de la stabilité du trafic.
## FAQ
### Quelle différence entre 301 et 302 ?
La 301 est définitive et transmet le PageRank. La 302 est temporaire et ne transmet pas. Pour une migration ou un changement de slug, toujours utiliser 301. La 302 est réservée aux cas explicitement temporaires : maintenance, A/B test, redirection saisonnière.
### Et la 410 (Gone) ?
La 410 dit à Google : cette URL n'existe plus et ne reviendra pas, désindexe immédiatement. Plus rapide que la 404 pour le nettoyage de l'index. Utile pour les produits définitivement retirés sans équivalent. Mais à utiliser avec parcimonie : une fois la 410 retournée, le PageRank est perdu.
### Combien de temps Google met-il à prendre en compte une 301 ?
Le crawl Google de l'URL ancienne peut prendre quelques jours à plusieurs semaines selon la fréquence de crawl. La transmission complète du PageRank vers la nouvelle URL prend en pratique 1 à 3 mois. Soumettre le nouveau sitemap accélère le processus.
### Peut-on rediriger en HTTPS et changer de domaine en même temps ?
Oui, et c'est même fréquent. Une 301 peut combiner protocole (HTTP → HTTPS), domaine (ancien.com → nouveau.com) et chemin. La règle : **une seule 301 par URL, pas une chaîne**. Aplatir au maximum.
### Les redirections impactent-elles les performances ?
Une 301 simple ajoute environ 100-200 ms au temps de réponse pour la première requête. Avec mise en cache navigateur (Cache-Control sur la 301), les visites suivantes vont directement à la nouvelle URL sans le hop. Le coût est négligeable hors chaînes multiples. Une chaîne de 3 hops, en revanche, peut ajouter 500 ms — d'où l'aplatissement.
## Pour aller plus loin
La gestion des redirections est un des piliers de la migration SEO-safe. Voir aussi notre [checklist complète de migration PrestaShop 1.7 → 8](https://www.datafirefly.com/2026/06/10/migration-prestashop-1-7-vers-8-checklist-2026/) (planifiée le 10 juin) où les 301 sont l'étape 8 de la procédure, et notre [guide SEO e-commerce 2026](https://www.datafirefly.com/2026/05/01/seo-ecommerce-guide-complet-2026/) pour le tableau complet du SEO PrestaShop. Trois articles complémentaires sur la même thématique : préparer, exécuter, sécuriser.
À lire aussi : [le guide complet du SEO e-commerce](https://www.datafirefly.com/2026/05/01/seo-ecommerce-guide-complet-2026/) et [Indexing API, IndexNow et bots IA](https://www.datafirefly.com/2026/06/07/indexation-2026-google-indexing-api-indexnow-bots-ia-prestashop/).
Pour passer à l'action : [notre sélection de modules SEO technique pour PrestaShop](https://www.datafirefly.com/solutions/prestashop/seo-technique/).
---
### Guide des tailles e-commerce mode : réduire le taux de retour de 30 % sans casser la conversion
_Source :_ — _publié_ 2026-06-26
> 70 % des retours mode sont liés à la taille. Un guide PNG dans un onglet ne déplace pas l'aiguille. Un guide interactif avec calculateur, page SEO dédiée et mémorisation peut réduire le taux de retour de 8 à 15 points. Anatomie complète sur PrestaShop.
Sur une boutique mode standard, le taux de retour oscille entre 25 et 40 %. Selon les études Statista et Asos rendues publiques en 2024-2025, près de 70 % des retours sont dus à un problème de taille — produit trop grand, trop petit, ou ressenti comme tel après livraison. Sur une boutique qui réalise 1 M€ de CA, ramener le taux de retour de 35 % à 25 % représente 100 k€ de revenu conservé, sans compter les coûts logistiques évités (réception, contrôle, remise en stock, frais de port retour).
Le guide des tailles est l'outil n°1 pour attaquer ce problème, et c'est aussi celui que la plupart des boutiques traitent le plus mal. Cet article décortique l'anatomie d'un guide des tailles qui fonctionne, les pièges qui le neutralisent, et son rôle SEO insoupçonné en 2026.
## Pourquoi les guides des tailles standards échouent
Le guide des tailles « classique » — une image PNG avec un tableau EU/US/UK — coche la case juridique et UX minimale, mais ne change quasiment rien au taux de retour. Pourquoi ?
- **Le client ne sait pas se mesurer.** Une longueur de bras ou un tour de hanches sans repère anatomique reste un chiffre abstrait. Sans schéma, sans vidéo, sans aide contextuelle, le client renseigne au pif.
- **Le tableau ne tient pas compte des morphologies.** Une taille 40 française n'a pas la même coupe chez Sandro, Massimo Dutti et Levi's. Un guide générique sans personnalisation marque/coupe rate la conversion.
- **Le PNG n'est pas accessible.** Pas lisible mobile, pas indexable Google, pas exploitable par les screen readers. Et il coûte du LCP sur la fiche produit.
- **Il est caché derrière un onglet.** 60 à 80 % des visiteurs ne l'ouvrent pas. Pour qu'un guide impacte le taux de retour, il doit être ressenti comme une aide proactive, pas comme une annexe.
- **Pas de mémorisation entre visites.** Le client refait l'exercice à chaque achat. Au bout de la deuxième fois, il abandonne et achète au pif.
## L'anatomie d'un guide des tailles qui fait baisser le taux de retour
### 1. Schéma anatomique avec repères de mesure
Un dessin clair, mobile-friendly, qui montre exactement où mesurer : tour de poitrine sous les bras, tour de taille au plus fin, longueur d'entrejambe au pli inguinal. Sans cela, les mesures saisies sont au mieux approximatives, au pire incohérentes (tour de poitrine = 75 cm pour une taille 42, mathématiquement impossible).
### 2. Calculateur interactif
Le client saisit ses mesures, le calculateur propose la taille recommandée. C'est la fonction qui change tout. Conversion mesurée : +12 à +20 % vs guide statique, taux de retour : -8 à -15 points.
### 3. Recommandation personnalisée par produit
Le calculateur ne renvoie pas une taille générique mais la taille correspondant au modèle consulté, en tenant compte des spécificités de coupe (slim, regular, oversize). Cela demande un mapping par modèle, donc une vraie data structurée — pas un PNG.
### 4. Affichage des trois standards (EU/US/UK)
Une boutique qui vend à l'international ne peut pas se contenter du système métrique français. Le bon guide affiche les trois conversions côte à côte, avec la taille du client surlignée dans son système habituel.
### 5. Mémorisation des mesures côté client
Une fois saisies, les mesures sont stockées en local (cookie ou localStorage) ou dans le compte client. La prochaine visite, le guide pré-remplit. Frottement client réduit, taux de réutilisation du guide multiplié par 4.
### 6. Page dédiée SEO
Une page `/guide-des-tailles` indexable, avec contenu éditorial (« comment se mesurer », FAQ tailles), génère du trafic informationnel et capte les requêtes « guide taille [marque] ». L'investissement éditorial est rentabilisé par le SEO en plus du gain de conversion.
## Le rôle SEO oublié du guide des tailles
Les requêtes contenant « guide des tailles » génèrent des millions de recherches mensuelles. Un visiteur qui tape « guide des tailles pantalon homme » sur Google n'est pas en pleine session d'achat — il est en phase de recherche. Si votre page est bien rankée, vous le captez tôt dans le funnel.
De plus, depuis l'avènement des AI Overviews et des moteurs de réponse (ChatGPT, Perplexity), les pages de guide des tailles bien structurées sont souvent citées comme sources. Une page guide avec un FAQ Schema (« Comment se mesurer pour un pantalon ? », « Comment convertir une taille US en EU ? ») apparaît dans les réponses IA.
Concrètement, sur une boutique mode que nous avons accompagnée, la page guide des tailles dédiée draine aujourd'hui 8 à 12 % du trafic SEO total, avec un taux de conversion attribué de 1,5 à 2 % — supérieur à la moyenne de la boutique.
## Implémentation technique : trois approches
### Approche 1 — page statique avec image
Solution la plus simple, et la plus inefficace. Coche la case UX minimale, ne déplace pas l'aiguille sur le taux de retour ni sur le SEO.
### Approche 2 — popin avec tableau HTML
Mieux : tableau dans une popin Bootstrap, multi-onglets EU/US/UK. SEO faible (contenu en JS), mais accessibilité correcte. Bonne base pour démarrer.
### Approche 3 — guide interactif avec calculateur et page dédiée
Module ou développement spécifique : page dédiée indexable, popin sur fiche produit qui réutilise le contenu de la page, calculateur JS, mémorisation localStorage, contenu éditorial. La seule approche qui couvre les trois objectifs (conversion, retours, SEO).
## Notre module dfsizeguide : le guide des tailles intelligent
Implémenter l'approche 3 à la main demande 5 à 10 jours de dev front + back, plus la rédaction éditoriale. [Notre module dfsizeguide](https://www.datafirefly.com/product/guide-des-tailles-prestashop/) pour PrestaShop 8 et 9 industrialise toute la mécanique :
- **Tableaux multi-systèmes** EU / US / UK / personnalisé, par catégorie produit et par modèle.
- **Calculateur interactif** qui prend les mesures du client et recommande la taille appropriée.
- **Page SEO dédiée**`/guide-des-tailles` avec contenu éditorial et FAQ Schema.
- **Popin sur fiche produit** qui réutilise le contenu de la page, sans duplication.
- **Affichage des trois standards** côte à côte, configuration par boutique multi-shop.
- **Mémorisation des mesures client** via localStorage, optionnellement liée au compte client.
- **Mapping par catégorie ou par produit** : un même catalogue peut avoir des guides différents pour les hauts, bas, chaussures.
- **Multilingue FR/EN/ES/DE** avec traduction des intitulés et des unités.
- **Sans modification du thème** : 100 % via hook.
Pour 29 €, c'est un des meilleurs ROI conversion + retours du catalogue PrestaShop.
## Combien gagner concrètement
Sur une boutique mode de 1 M€ de CA annuel avec un taux de retour à 35 % :
- Avant guide intelligent : 350 k€ de marchandise retournée, soit 70 à 100 k€ de coût net après remise en stock et frais logistiques.
- Après guide intelligent (8 points de réduction du taux de retour, hypothèse conservatrice) : 270 k€ de marchandise retournée, soit 50 à 75 k€ de coût net. **Gain net : 20 à 25 k€/an**.
- Plus le gain conversion à l'achat (clients hésitants qui osent commander grâce au guide) : +1 à +2 % de taux de conversion, soit 10 à 20 k€ de CA additionnel.
- Plus le SEO : 5 à 15 % de trafic additionnel sur la page guide indexée.
ROI annuel : 30 à 60 k€ pour un module à 29 €. Le rapport coût/bénéfice est sans équivalent dans le catalogue PrestaShop.
## Les pièges à éviter
1. **Guide générique pour toute la boutique.** Si vous vendez hauts, bas, chaussures et accessoires, vous avez besoin de plusieurs guides — pas d'un mégaguide unique illisible.
2. **Mesures en pouces ET centimètres sans toggle.** Le tableau devient illisible. Toggle propre EU/US par défaut.
3. **Calculateur sans validation.** Si le client saisit un tour de poitrine de 250 cm, le calculateur doit le rejeter, pas recommander une 6XL absurde.
4. **Image PNG haute résolution non optimisée.** 800 ko de PNG flinguent le LCP de la fiche produit. WebP optimisé et lazy loading, toujours.
5. **Pas de version mobile.** 70 % du trafic mode est mobile en 2026. Un tableau qui scroll horizontalement sur mobile, c'est mort.
## FAQ
### Le guide des tailles est-il obligatoire en e-commerce ?
Pas obligatoire stricto sensu, mais l'absence de guide ou un guide trompeur peut être qualifié de « pratique commerciale trompeuse » au sens de l'article L121-2 du Code de la consommation, surtout sur l'habillement. Et au-delà de la conformité, c'est un outil commercial central.
### Comment gérer les marques avec des coupes très différentes ?
Le mapping doit se faire au niveau du produit ou du modèle, pas au niveau global. Un module sérieux permet de définir des tableaux par marque, par collection, voire par référence. Si votre boutique mélange du Levi's slim et du Carhartt regular, ne pas leur appliquer le même tableau.
### Faut-il proposer un service de mesure à distance ?
Les services IA de mesure par photo (Bold Metrics, Sizolution) sont pertinents au-delà de 5 M€ de CA. En dessous, le ROI ne couvre pas l'intégration et l'abonnement. Un calculateur classique propre couvre 90 % du besoin.
### Comment afficher le guide sur mobile sans casser la fiche produit ?
Sur mobile, le guide doit s'ouvrir en plein écran (bottom sheet ou modale full-page), pas en popin compressée. Et la fermeture doit être facile. Le pattern « bottom sheet swipe-to-close » est devenu la norme en 2026.
### Le guide doit-il être placé avant ou après le sélecteur de taille ?
Le lien « Guide des tailles » doit être visible juste à côté du sélecteur de taille, pas dans un onglet en bas de page. La position optimale : à droite de l'intitulé « Taille » avec une icône claire et un texte court. Toujours en deçà de la ligne d'add-to-cart pour ne pas distraire de l'action principale.
## Pour aller plus loin
Le guide des tailles est un des leviers d'amélioration du funnel post-achat. Voir aussi notre article sur l'[anatomie d'une fiche produit haute conversion](https://www.datafirefly.com/2026/05/13/anatomie-fiche-produit-haute-conversion-prestashop-8-2026/) où le guide des tailles est un des 12 éléments à orchestrer, et le dossier sur la [wishlist comme levier de conversion différée](https://www.datafirefly.com/2026/05/09/wishlist-prestashop-levier-conversion-alertes-prix-2026/). Trois leviers complémentaires : décision (guide), engagement (wishlist), action (fiche produit).
Pour passer à l'action : [nos modules pour vendre des vêtements et de la mode](https://www.datafirefly.com/solutions/prestashop/vendre-des-vetements/) et [notre sélection pour gérer les retours produits](https://www.datafirefly.com/solutions/prestashop/gestion-retours/).
---
### Claude Fable retour : c'est officiel, le modèle revient mondialement (1er juillet 2026)
_Source :_ — _publié_ 2026-06-24
> Claude Fable 5 est de retour : le 30 juin, les États-Unis ont levé les contrôles à l'export, et Anthropic a rétabli le modèle mondialement dès le 1er juillet (claude.ai, API, Claude Code, Claude Cowork). Retour mondial, France comprise — seul Mythos 5 reste restreint. Nouveau classificateur cyber, limites d'usage et rétention à 30 jours : ce qui change.
**En bref :** oui, **Claude Fable 5 est de retour** — et cette fois pour tout le monde. Le 30 juin 2026, le Département du Commerce américain a **levé les contrôles à l'export** qui pesaient sur Fable 5 et son jumeau Mythos 5 depuis le 12 juin. Anthropic a annoncé la remise en service du modèle **à l'échelle mondiale à partir du mercredi 1er juillet**, sur le Claude Platform (API), claude.ai, Claude Code et Claude Cowork. Point crucial pour les utilisateurs français : ce retour est **mondial**, pas réservé aux seuls comptes américains — c'est désormais Mythos 5 qui reste, lui, cantonné à une centaine d'organisations américaines « de confiance ».
Le redéploiement s'accompagne toutefois de nouvelles conditions : un **nouveau classificateur de cybersécurité** (certaines tâches, y compris du code et du débogage de routine, basculent sur Opus 4.8), des **limites d'usage** temporaires, et une **rétention de 30 jours** des données pour les modèles de classe Mythos. On détaille tout ci-dessous.
Si vous êtes arrivé ici en cherchant « Claude Fable retour », « Claude Fable disponible » ou « is Fable back », voici la réponse claire, la chronologie complète, les raisons de l'arrêt et ce qui change concrètement avec ce redéploiement.
## Claude Fable est-il de retour aujourd'hui ?
Oui. Depuis le **1er juillet 2026**, Claude Fable 5 est de nouveau accessible **aux utilisateurs du monde entier** sur les surfaces maison d'Anthropic : le Claude Platform (API), claude.ai, Claude Code et Claude Cowork. C'est l'aboutissement de deux semaines et demie de négociations entre Anthropic et l'administration américaine.
Deux réserves pratiques à connaître. D'abord, le déploiement peut être **progressif** : selon votre fuseau horaire, le modèle peut n'apparaître dans le sélecteur que dans le courant de la journée (en France, plutôt en fin de journée). Ensuite, l'accès via les **plateformes cloud partenaires — AWS (Bedrock), Google Cloud (Vertex) et Microsoft Foundry — n'est pas encore rétabli** : Anthropic indique le remettre en service « aussi vite que possible ». Si vous appelez Fable 5 depuis l'un de ces hyperscalers, patientez encore un peu.
## Ce qui change avec ce redéploiement
Fable 5 ne revient pas à l'identique. Anthropic a modifié plusieurs paramètres pour obtenir le feu vert du gouvernement.
### Un nouveau classificateur cyber (et des bascules vers Opus 4.8)
Le cœur du dispositif : un **classificateur de sécurité** entraîné spécifiquement pour détecter et bloquer la technique de contournement signalée par Amazon. Anthropic affirme intercepter cette technique dans **plus de 99 % des cas**. Concrètement, lorsqu'une requête est jugée sensible sur le plan cybersécurité, Fable 5 **ne répond pas lui-même** : la tâche est renvoyée vers Opus 4.8 et l'utilisateur en est informé. Anthropic reconnaît le revers de la médaille : **davantage de faux positifs** sur des tâches parfaitement légitimes de codage et de débogage, qui basculeront elles aussi sur Opus 4.8 à court terme. L'entreprise indique vouloir affiner ces classificateurs dans les semaines qui viennent pour mieux distinguer un usage malveillant d'une demande légitime.
### Des limites d'usage temporaires
Pour les offres **Pro, Max, Team et certains plans Enterprise**, Fable 5 est inclus à hauteur de **50 % des limites d'usage hebdomadaires jusqu'au 7 juillet** ; au-delà, l'accès se fait via un système de **crédits d'usage** (usage credits). Les sièges Enterprise standard n'ont, eux, pas d'allocation Fable 5 incluse — l'accès passe directement par les crédits d'usage.
### Rétention des données à 30 jours pour les modèles de classe Mythos
Anthropic impose désormais une **rétention de 30 jours** sur l'ensemble du trafic des modèles de classe Mythos (Fable 5, Mythos 5 et modèles futurs de capacité équivalente ou supérieure), y compris sur les surfaces tierces. Ces données **ne servent pas à entraîner** de nouveaux modèles ni à un usage non lié à la sécurité ; elles visent à détecter les attaques complexes et les nouveaux jailbreaks, et à réduire les faux positifs. L'entreprise dit avoir ajouté des garde-fous : journalisation des accès humains et suppression après 30 jours dans la quasi-totalité des cas.
### Un cadre de sévérité des jailbreaks et plus de collaboration gouvernementale
En parallèle, Anthropic a commencé à rédiger — avec **Amazon, Microsoft, Google et d'autres partenaires du programme Glasswing** — un **cadre de consensus** pour évaluer la gravité des jailbreaks d'IA et la réponse à y apporter, et invite les autres acteurs du secteur à s'y joindre. L'entreprise renforce aussi sa **collaboration avec le gouvernement américain** sur les tests et les garde-fous : accès pré-lancement aux modèles pour évaluation, partage d'informations sur les jailbreaks et les usages malveillants, et ressources dédiées à la recherche conjointe.
## Pourquoi Claude Fable avait été suspendu : les vraies raisons de l'arrêt
Rappel utile, car l'épisode est inédit : ce n'était ni une panne ni un bug, mais une décision réglementaire.
### La chronologie complète
- **9 juin 2026 :** Anthropic ouvre Claude Fable 5 au grand public — son modèle le plus puissant jamais rendu accessible largement. Son jumeau Mythos 5, identique sur le fond mais avec moins de garde-fous, reste réservé au programme fermé Project Glasswing.
- **12 juin 2026, 17 h 21 (heure de l'Est) :** le secrétaire au Commerce Howard Lutnick adresse à Anthropic une directive de contrôle des exportations, fondée sur la sécurité nationale.
- **Le soir même :** Anthropic désactive Fable 5 et Mythos 5 pour tous ses clients.
- **26 juin 2026 :** premier dégel — le gouvernement autorise le redéploiement de Mythos 5 à une centaine d'organisations américaines « de confiance » (agences fédérales et opérateurs d'infrastructures critiques). Fable 5 reste exclu de cette autorisation.
- **30 juin 2026 :** le Département du Commerce **lève les contrôles à l'export** sur Fable 5 _et_ Mythos 5. Anthropic annonce le rétablissement de l'accès dès le lendemain.
- **1er juillet 2026 :****Fable 5 est de nouveau disponible mondialement** sur claude.ai, le Claude Platform, Claude Code et Claude Cowork. Mythos 5 reste, lui, réservé aux organisations américaines approuvées.
### Le motif invoqué par le gouvernement
La directive du 12 juin ordonnait de bloquer l'accès à Fable 5 et Mythos 5 pour **tout ressortissant étranger** (foreign national), aux États-Unis comme ailleurs — y compris les propres employés étrangers d'Anthropic. Le motif technique : un rapport de chercheurs d'**Amazon** décrivant une méthode de « jailbreak » amenant Fable 5 à identifier des failles logicielles — et, dans un cas, à produire du code montrant comment exploiter l'une d'elles. Remonté aux autorités, ce rapport a déclenché des inquiétudes sur les capacités cyber offensives des LLM publics.
### La position d'Anthropic : un malentendu, désormais tranché par les tests
Anthropic a toujours contesté la gravité du problème — et ses tests, menés avec le gouvernement et Amazon pendant deux semaines, lui donnent largement raison. Selon l'entreprise, des modèles **moins capables** — dont Opus 4.8, GPT-5.5 ou Kimi K2.7 — identifiaient **les mêmes failles** que Fable 5 dans le rapport ; et pour la démonstration d'exploitation, **tous les modèles testés** produisaient le même résultat. Autrement dit, il s'agissait d'un travail de sécurité défensive de routine, sans capacité offensive propre à Fable 5. C'est ce constat, doublé du nouveau classificateur, qui a permis de débloquer la situation.
### Pourquoi tout le monde avait été coupé, et pas seulement les étrangers ?
Parce qu'il n'existe aucun moyen fiable de vérifier la nationalité à chaque requête API, à travers des dizaines de plateformes cloud. Pour se mettre en conformité, Anthropic avait préféré tout éteindre plutôt que de risquer une violation — transformant une mesure ciblant les ressortissants étrangers en un blocage mondial total.
## Et Mythos 5 ? Toujours sous cloche
Attention à ne pas confondre les deux modèles. Si Fable 5 revient pour tous, **Mythos 5 reste réservé** à une liste fermée d'environ **100 organisations américaines « de confiance »** (agences fédérales, opérateurs d'infrastructures critiques), autorisée depuis le 26 juin. Anthropic poursuit les discussions avec le gouvernement pour élargir cet accès aux autres partenaires — domestiques et internationaux — du programme Glasswing. Mythos 5, c'est le même modèle de base que Fable 5 mais **sans les garde-fous cyber** : il n'est ni ouvert au public, ni accessible aux utilisateurs étrangers.
## Claude Fable retour en France : que peuvent faire les utilisateurs français ?
C'est le point qui a le plus évolué — et l'occasion de corriger une prévision. Beaucoup redoutaient que la France, visée par la mesure au titre des « ressortissants étrangers », reste exclue d'un premier retour réservé aux comptes américains. Ce n'est pas le scénario retenu : la levée des contrôles à l'export est **totale**, et Fable 5 revient **mondialement**. Les utilisateurs français, britanniques ou canadiens y ont donc accès au même titre que les américains, sur claude.ai, l'API, Claude Code et Claude Cowork (sous réserve du déploiement progressif évoqué plus haut). Seul Mythos 5 demeure hors de portée.
Le dossier gardait une forte dimension franco-américaine. Le sommet du G7 s'était tenu à **Évian-les-Bains**, en France : Donald Trump y avait rencontré Dario Amodei, et la Maison-Blanche avait indiqué que le président avait « apaisé » ses inquiétudes de sécurité nationale à l'issue de cet échange. Emmanuel Macron, de son côté, avait qualifié les contrôles américains à l'export d'IA de « nationalistes ». La résolution rapide du dossier montre que la question se jouait autant sur le terrain diplomatique que technique.
## « Je vois Fable dans l'application mais ça ne marche pas »
Pendant la suspension, le nom de Fable 5 restait affiché dans le sélecteur de modèles sans être actif — un simple artefact d'interface. Depuis le 1er juillet, le modèle doit fonctionner ; si vous obtenez encore une erreur ou une bascule silencieuse vers Opus 4.8, deux explications probables : le **déploiement progressif** (patientez quelques heures, surtout hors des États-Unis) ou un appel via une **plateforme cloud** (AWS/GCP/Foundry) pas encore rétablie. À noter aussi : une bascule vers Opus 4.8 peut désormais être **volontaire**, déclenchée par le nouveau classificateur cyber sur une requête jugée sensible.
## Attention aux fausses méthodes de « déblocage »
Le blocage étant désormais levé, la question ne se pose plus. Pour mémoire, pendant la suspension, aucune « astuce » (fichier de configuration miracle, prompt secret, build alternatif, miroir non officiel) ne fonctionnait : le blocage était appliqué côté serveur, par décision gouvernementale. Les pseudo-miroirs et « versions débloquées » n'offraient pas le vrai Fable 5 et exposaient surtout à des risques de sécurité concrets — un réflexe de prudence à conserver pour la prochaine fois.
## La vraie leçon : rendre la couche modèle interchangeable
Même de retour, cet épisode laisse un enseignement qui dépasse Anthropic : un modèle de pointe peut disparaître du jour au lendemain pour une raison non technique — réglementaire ou géopolitique. Pour quiconque construit une boutique en ligne ou un module qui s'appuie sur une IA, la règle de conception est claire : **la couche modèle doit être interchangeable**. Si vous ne pouvez pas basculer votre trafic d'un modèle à l'autre par simple configuration, sans redéploiement, votre abstraction est à revoir. Le comportement même de Fable 5 l'illustre : quand son classificateur bloque une requête, il bascule tout seul sur Opus 4.8. C'est aussi ce qui explique l'intérêt persistant pour des alternatives multi-fournisseurs (modèles à poids ouverts comme GLM 5.2, ou modèles d'autres éditeurs). Bonne nouvelle : tous les autres modèles Claude — Opus 4.8, Sonnet 4.6, Haiku 4.5 — sont restés disponibles pendant toute la crise et le demeurent.
## FAQ — Claude Fable retour
### Claude Fable 5 est-il de retour ?
Oui. Depuis le 1er juillet 2026, à la suite de la levée des contrôles à l'export par le Département du Commerce américain le 30 juin. Le modèle est de nouveau disponible mondialement sur claude.ai, le Claude Platform, Claude Code et Claude Cowork.
### Le retour de Fable 5 concerne-t-il la France ?
Oui. Contrairement à ce que laissait craindre le dégel initial de Mythos 5, le retour de Fable 5 est mondial : les utilisateurs français y ont accès comme partout ailleurs. Seul le déploiement peut être progressif selon le fuseau horaire.
### Puis-je utiliser Fable 5 sur AWS, Google Cloud ou Microsoft Foundry ?
Pas encore. Le retour concerne d'abord les surfaces maison d'Anthropic (claude.ai, API, Claude Code, Claude Cowork). Anthropic indique rétablir l'accès sur AWS Bedrock, Google Vertex et Microsoft Foundry « aussi vite que possible ».
### Pourquoi certaines de mes requêtes basculent-elles sur Opus 4.8 ?
Fable 5 revient avec un nouveau classificateur cyber. Lorsqu'une requête est jugée sensible (ou, à court terme, pour certaines tâches de codage/débogage de routine par excès de prudence), la tâche est renvoyée vers Opus 4.8 et vous en êtes informé. Anthropic doit affiner ces classificateurs dans les semaines à venir pour réduire les faux positifs.
### Y a-t-il des limites d'usage ?
Oui, temporairement. Pour les offres Pro, Max, Team et certains plans Enterprise, Fable 5 est inclus jusqu'à 50 % des limites hebdomadaires jusqu'au 7 juillet, puis via des crédits d'usage.
### Quelle est la différence entre Fable 5 et Mythos 5 ?
C'est le même modèle de base. Fable 5 embarque des classificateurs de sécurité qui peuvent refuser certaines requêtes (cybersécurité, biologie, chimie…) et basculer vers Opus 4.8. Mythos 5 en a moins et reste réservé à des organisations américaines triées sur le volet (Project Glasswing puis la liste « de confiance » du 26 juin) — il n'est pas ouvert au public.
### Mes données sont-elles conservées ?
Pour les modèles de classe Mythos (dont Fable 5), Anthropic applique désormais une rétention de 30 jours de l'ensemble du trafic, à des fins de sécurité uniquement (détection d'attaques et de jailbreaks, réduction des faux positifs). Ces données ne servent pas à l'entraînement des modèles.
---
_Article mis à jour le 1er juillet 2026, après la levée des contrôles à l'export et l'annonce officielle d'Anthropic. Sources : blog et compte officiels d'Anthropic, CNBC, VentureBeat, The Hacker News._
---
### Directive Omnibus en 2026 : afficher le prix de référence sans saboter ses promos sur PrestaShop
_Source :_ — _publié_ 2026-06-22
> Quatre ans après son entrée en vigueur, la directive Omnibus est devenue la cible n°1 des contrôles DGCCRF e-commerce. Voici la règle exacte du prix de référence des 30 derniers jours, les pièges qui tuent les promos, et la mécanique correcte sur PrestaShop.
La directive européenne 2019/2161, dite « Omnibus », est applicable depuis le 28 mai 2022. En 2026, après quatre ans d'application et plusieurs vagues de contrôles DGCCRF, la conformité n'est plus optionnelle : les sanctions vont jusqu'à 4 % du chiffre d'affaires annuel pour les manquements graves, et la DGCCRF a publiquement annoncé une intensification des contrôles e-commerce en 2025-2026 sur les soldes, les Black Friday et les annonces de promotion permanente.
Le problème : la règle Omnibus est simple à énoncer, complexe à implémenter techniquement, et catastrophique sur les promotions si elle est mal appliquée. Cet article décortique la règle, les pièges qui tuent les promos, et la mécanique correcte sur PrestaShop.
## Ce que dit exactement la directive Omnibus
Article L121-4 du Code de la consommation, modifié par l'ordonnance 2021-1734 transposant Omnibus :
> « Toute annonce d'une réduction de prix indique le prix antérieur pratiqué par le professionnel avant l'application de la réduction. Le prix antérieur correspond au prix le plus bas pratiqué par le professionnel à l'égard de tous les consommateurs au cours des trente derniers jours précédant l'application de la réduction. »
Concrètement, quatre règles s'imposent :
1. **Toute promotion doit afficher le prix de référence** = prix le plus bas des 30 derniers jours.
2. **Ce prix de référence doit être visible** à côté du nouveau prix promotionnel.
3. **Le calcul est par produit** et par référence (combinaison déclinaison), pas par catégorie.
4. **Le pourcentage de réduction affiché doit être calculé sur ce prix de référence**, pas sur un prix gonflé.
## Les exceptions et cas particuliers
### Soldes officiels
La règle Omnibus s'applique aux soldes. Le « prix de référence » affiché en soldes doit être le prix le plus bas des 30 jours précédant l'ouverture des soldes — pas le prix barré arbitraire des fabricants.
### Promotion progressive
Si vous appliquez -20 % la première semaine, puis -30 % la deuxième, le prix de référence reste celui des 30 jours précédant la PREMIÈRE remise. Le -30 % se calcule par rapport au prix d'origine, pas par rapport au prix promo précédent.
### Nouveau produit (moins de 30 jours)
Si le produit est en vente depuis moins de 30 jours, on prend le prix le plus bas depuis sa mise en vente. La règle n'invente pas un prix antérieur — elle utilise l'historique disponible.
### Denrées périssables
Exception : produits frais à date de péremption courte. L'Omnibus s'applique avec souplesse, mais la traçabilité reste exigée.
### Produits non commercialisés au public auparavant
Une remise initiale (« prix de lancement ») n'a pas à afficher de prix de référence. Mais on ne peut pas indiquer un faux « prix barré ».
## Le piège qui tue les promos : le prix barré gonflé
Avant Omnibus, beaucoup d'e-commerçants alignaient leur PVC sur un prix « catalogue fabricant » fantaisiste et affichaient -50 % en permanence. Pratique morte en 2022 et activement sanctionnée en 2025-2026.
Exemple type d'un contrôle DGCCRF : une boutique affiche un produit à 39,90 € avec un prix barré à 79,90 € (-50 %). L'audit DGCCRF demande l'historique des prix. Le produit n'a jamais été vendu au-dessus de 49,90 €. Sanction : amende administrative, retrait de l'allégation promotionnelle, publication du contrôle.
L'erreur de fond : confondre **prix conseillé fabricant** (PVC, non opposable) et **prix de référence Omnibus** (prix réellement pratiqué).
## La mécanique technique sur PrestaShop
PrestaShop 8 et 9 ne gèrent pas nativement le prix de référence Omnibus. Le module catalogue gère les « réductions » et « specific prices », mais sans historique des 30 derniers jours ni calcul automatique du prix antérieur réel.
L'implémentation manuelle demande quatre couches :
### 1. Tracking de l'historique des prix
Une nouvelle table `ps_price_history` enregistre chaque changement de prix par `id_product` et `id_product_attribute`, avec timestamp. Soit déclenché par hook `actionObjectProductUpdateAfter`, soit par un cron quotidien qui snapshotte les prix.
```
CREATE TABLE ps_price_history (
id_history INT AUTO_INCREMENT PRIMARY KEY,
id_product INT NOT NULL,
id_product_attribute INT DEFAULT 0,
id_shop INT NOT NULL,
id_currency INT NOT NULL,
price DECIMAL(20,6) NOT NULL,
date_change DATETIME NOT NULL,
INDEX idx_product_date (id_product, date_change)
) ENGINE=InnoDB;
```
### 2. Calcul du prix de référence
Au moment d'afficher une promotion, le module calcule pour chaque produit le prix le plus bas des 30 derniers jours :
```
SELECT MIN(price) AS prix_reference
FROM ps_price_history
WHERE id_product = :product_id
AND id_product_attribute = :attribute_id
AND date_change >= DATE_SUB(NOW(), INTERVAL 30 DAY)
AND date_change < :promo_start_date;
```
### 3. Affichage conforme
Sur la fiche produit et dans les listings, le bloc prix affiche :
- Prix promotionnel actuel (en grand)
- Prix de référence des 30 derniers jours, barré (« Prix antérieur le plus bas (30j) : 39,90 € »)
- Pourcentage de réduction calculé sur le prix de référence
Optionnellement, un tooltip ou un lien « Voir l'historique des prix » améliore la transparence (et désamorce les contestations).
### 4. Traçabilité pour l'audit
En cas de contrôle DGCCRF, vous devez pouvoir produire l'historique sur demande. La table `ps_price_history` doit être conservée au moins 2 ans, idéalement 5 ans. Exportable en CSV depuis le BO.
## Les erreurs fréquentes en production
1. **Calculer le prix de référence sur le prix HT au lieu du prix TTC** ou inversement. La règle s'applique au prix payé par le consommateur — donc TTC pour le B2C.
2. **Ignorer les déclinaisons**. Le prix de référence est par référence physique, pas par produit parent.
3. **Ne pas gérer le multi-devise**. Si vous vendez en euros et en dollars, l'historique doit être par devise.
4. **Réinitialiser l'historique à chaque mise à jour catalogue**. Une migration ou un import en masse peut écraser l'historique. Le module doit préserver l'historique passé.
5. **Afficher le « prix conseillé fabricant » à la place du prix de référence**. C'est l'erreur juridique majeure.
6. **Ne pas couvrir les pages catégorie et les listings**. Si la fiche produit est conforme mais que la vignette en catégorie affiche un prix barré gonflé, vous êtes en infraction.
## Notre module dfomnibus : conformité automatique
Implémenter cette mécanique à la main est un projet de 5 à 8 jours de dev, avec tests sur multi-shop, multi-devise et déclinaisons. [Notre module dfomnibus](https://www.datafirefly.com/product/dfomnibus-conformite-directive-omnibus/) pour PrestaShop 8 et 9 industrialise toute la stack :
- **Tracking automatique de l'historique** via hook sur la modification de prix (sans cron, en temps réel).
- **Calcul du prix de référence Omnibus** par produit et par déclinaison, avec gestion multi-shop et multi-devise.
- **Affichage conforme** sur fiches produit, listings catégorie, blocs cross-sell, panier.
- **Traçabilité auditable** : export CSV de l'historique, prêt pour la DGCCRF.
- **Pourcentage de réduction recalculé** sur le prix de référence, jamais sur un prix arbitraire.
- **Compatible avec les soldes officiels** et les promotions programmées.
- **Multilingue FR/EN/ES/DE** pour les boutiques internationales (la directive Omnibus s'applique dans toute l'UE).
Pour 79 €, vous passez en conformité sans toucher au catalogue et sans risque sur les promotions à venir.
## Au-delà de la conformité : la conversion
Paradoxalement, une promotion conforme Omnibus convertit souvent mieux qu'une promotion gonflée. La raison : les consommateurs sont devenus méfiants face aux prix barrés artificiels. Afficher un prix de référence vérifié et un pourcentage honnête renforce la crédibilité. Sur les boutiques que nous avons converties à la conformité stricte, le taux de clic sur les vignettes promotionnelles s'est stabilisé ou a légèrement augmenté.
Et surtout, la conformité supprime un risque opérationnel majeur : un signalement DGCCRF (souvent fait par un concurrent) déclenche un audit qui peut paralyser la stratégie promotionnelle pendant des mois.
## FAQ
### La directive Omnibus s'applique-t-elle aux soldes ?
Oui, intégralement. Le prix de référence affiché en soldes doit être le prix le plus bas pratiqué au cours des 30 jours précédant l'ouverture des soldes — pas le « prix catalogue » ou le « PVC fabricant ». La DGCCRF a explicitement ciblé les soldes 2024 et 2025 dans ses contrôles e-commerce.
### Que faire pour les produits en promotion permanente ?
La promotion « permanente » est incompatible avec Omnibus. Si un produit est en remise -30 % depuis trois mois, le prix de référence est en réalité le prix de remise (puisque c'est le prix le plus bas des 30 derniers jours). Donc -30 % par rapport à... -30 % = 0 % de remise réelle affichable. Soit on supprime la communication promotionnelle, soit on alterne périodes promotionnelles et périodes au prix normal.
### Le module gère-t-il la rétroactivité ?
Si vous installez dfomnibus aujourd'hui, l'historique commence à la date d'installation. Pour les contrôles DGCCRF portant sur des promotions passées (avant installation), il faudra produire l'historique par d'autres moyens (sauvegardes BDD, exports CSV anciens). Nous recommandons d'installer le module en amont des soldes ou des opérations promotionnelles majeures, pas le jour J.
### Quelle sanction en cas de non-conformité ?
L'article L132-2 du Code de la consommation prévoit jusqu'à 300 000 € pour les personnes physiques et 4 % du chiffre d'affaires annuel pour les personnes morales pour les manquements graves. En pratique, les sanctions DGCCRF sur les e-commerçants en 2024-2025 oscillent entre 5 000 € et 80 000 € selon la gravité et la récidive.
### La directive Omnibus s'applique-t-elle hors UE ?
Non, c'est une directive européenne. Mais si votre boutique vend à des consommateurs européens depuis un pays tiers (UK, Suisse, US), vous êtes soumis à la règle pour les ventes B2C dans l'UE. Le critère est le ciblage du consommateur, pas le siège du marchand.
## Pour aller plus loin
La conformité réglementaire en e-commerce 2026 se structure autour de trois piliers : RGPD (Consent Mode v2), Omnibus (prix de référence), et sectoriel (age gate, INCO, sécurité produits). Voir aussi notre [guide RGPD Consent Mode v2 PrestaShop](https://www.datafirefly.com/2026/05/09/rgpd-consent-mode-v2-prestashop-2026-tracking-ga4/) et le récent [dossier sur la vérification d'âge e-commerce](https://www.datafirefly.com/2026/06/18/verification-age-ecommerce-cbd-vape-alcool-conformite-prestashop-2026/). Trois couches indépendantes, à empiler proprement.
À lire aussi : [la checklist GPSR](https://www.datafirefly.com/2026/06/04/gpsr-2026-checklist-conformite-produit-prestashop/) et [la vérification d'âge (CBD, vape, alcool)](https://www.datafirefly.com/2026/06/18/verification-age-ecommerce-cbd-vape-alcool-conformite-prestashop-2026/).
Pour passer à l'action : [notre sélection de modules de conformité produit](https://www.datafirefly.com/solutions/prestashop/conformite-produits/).
---
### Vérification d'âge e-commerce en 2026 : conformité CBD, vape, alcool — obligation légale vs taux d'entrée
_Source :_ — _publié_ 2026-06-18
> Vendre du CBD, de la vape ou de l'alcool sans age gate en 2026, c'est jouer avec les CGV des transporteurs et des processeurs de paiement. Mais une modale bricolée fait fuir 25 % des visiteurs. Voici la mécanique qui marche, secteur par secteur.
En 2026, vendre du CBD, de l'alcool, de la vape, des couteaux ou du tabac en ligne sans dispositif de vérification d'âge n'est plus un risque juridique théorique. Les contrôles DGCCRF se sont durcis depuis 2024, les CGV des transporteurs (Colissimo, DHL, UPS) exigent désormais une preuve documentée de majorité pour certaines catégories, et les sanctions vont jusqu'à 75 000 € pour la vente d'alcool à mineur (article L3353-3 du Code de la santé publique).
Le problème : un age gate mal conçu fait fuir 15 à 25 % des visiteurs. Bien conçu, l'impact tombe sous les 3 %. Cet article fait le point sur l'obligation légale par secteur, les patterns UX qui marchent en 2026, et la mécanique technique sur PrestaShop.
## Le cadre légal par secteur en 2026
### Alcool
Article L3342-1 du Code de la santé publique : la vente d'alcool aux mineurs est interdite, le commerçant doit exiger la preuve de la majorité. En ligne, cela se traduit par un mécanisme déclaratif au minimum, idéalement renforcé d'un contrôle à la livraison (signature adulte).
### Vape et e-liquides nicotinés
Décret 2016-1117 transposant la directive TPD : vente interdite aux mineurs, déclaratif d'âge obligatoire. Depuis 2024, les marketplaces (Amazon, Cdiscount) refusent les vendeurs sans dispositif visible.
### CBD
Cadre flou stricto sensu (le CBD n'est pas un stupéfiant depuis l'arrêt de la Cour de cassation 2023), mais l'autorégulation du secteur exige un age gate +18. Les transporteurs et les processeurs de paiement (Stripe, Mollie) l'imposent dans leurs CGV pour conserver le compte marchand.
### Tabac et accessoires
Loi Évin renforcée : interdiction stricte de la vente aux mineurs, mais en pratique la vente en ligne de tabac est interdite en France (article 568 ter CGI). Pour les accessoires (briquets, papiers, narguilés), l'age gate +18 est la norme professionnelle.
### Armes, couteaux, défense
Décret 2013-700 : certaines catégories (couteaux à lame fixe +6 cm, armes de catégorie D) imposent une vérification d'identité, pas seulement déclarative. Un simple age gate ne suffit pas — il faut KYC.
### Contenus adultes et jeux
Loi 2020-936 du 30 juillet 2020 et décret 2024-200 : les sites pornographiques doivent vérifier l'âge par dispositif robuste (carte bancaire, France Connect, tiers vérificateur). L'Arcom contrôle. Le déclaratif simple n'est plus accepté.
## Déclaratif vs vérification robuste : où placer le curseur
Tous les age gates ne se valent pas. On distingue trois niveaux :
NiveauMécanismeForce probanteSecteur recommandé1 — Déclaratif binaire« J'ai +18 ans » / « J'ai moins de 18 ans »FaibleCBD, vape, accessoires tabac, alcool soft2 — Déclaratif datéSaisie de la date de naissance complèteMoyenneAlcool fort, paris en ligne légers3 — Vérification documentairePièce d'identité, FranceConnect, tiers KYCForteContenus adultes, armes, jeux d'argent
Pour 95 % des boutiques PrestaShop concernées (CBD, vape, alcool, accessoires), le niveau 1 ou 2 est suffisant et conforme. Le niveau 3 réclame une intégration tiers payante et n'est obligatoire que pour des secteurs très précis.
## Le coût UX d'un age gate raté
L'age gate intervient à un moment critique : le visiteur arrive sur la boutique, n'est pas encore engagé, et on lui demande une action. Les patterns qui plombent la conversion :
- **Bloquer toutes les pages, y compris l'accueil et le blog.** Le visiteur ne peut même pas se faire une idée de la boutique. Taux d'abandon : 25-30 %.
- **Réafficher la modale à chaque visite** sans mémoriser le consentement par cookie. Frustration garantie.
- **Forcer la saisie de la date de naissance complète** sur une boutique de e-liquides à 9 €. Disproportion ressentie, fuite.
- **Modale visuellement bâclée** qui ressemble à une fenêtre de phishing. Perte de confiance immédiate.
- **Pas de version mobile correcte.** 70 % du trafic part par mobile en 2026, et un overlay buggé tue la session.
## L'architecture qui marche : modale bloquante propre, cookie 30 jours, version mobile native
Le pattern qu'on a éprouvé sur plusieurs boutiques CBD et vape PrestaShop :
1. **Modale bloquante affichée à l'arrivée sur le domaine**, sans dépendre du JavaScript de l'utilisateur (la modale est rendue côté serveur ou injectée par script qui ne bloque pas le rendu critique).
2. **Deux boutons clairs** : « J'ai 18 ans ou plus » / « J'ai moins de 18 ans ».
3. **Si refus**, redirection vers une page externe (généralement Google ou une page d'information sur la consommation responsable).
4. **Si acceptation**, cookie de 30 jours mémorise le consentement. Le visiteur ne revoit pas la modale pendant 30 jours.
5. **Multilingue** : la modale parle la langue de la boutique active (français, anglais, espagnol, allemand).
6. **Compatible RGPD et tracking** : la modale ne déclenche pas les scripts de tracking avant consentement Consent Mode v2.
7. **Mobile-first** : la modale est sized et stylisée pour mobile, sans bug de scroll ou de viewport.
## Implémentation technique sur PrestaShop 8 et 9
Trois approches techniques sont possibles :
### Hook frontController ou displayHeader
L'age gate est injecté en haut de page via un hook PrestaShop standard. Le module détecte l'absence du cookie de consentement et insère le HTML de la modale. Le pattern le plus propre, compatible avec tous les thèmes.
### Override du contrôleur front
À éviter. Les overrides cassent à la prochaine mise à jour de PrestaShop ou du thème.
### Module dédié
L'approche recommandée. Le module gère le hook, la modale, le cookie, le multilingue, et la configuration BO (catégories concernées, redirection, design).
## Notre module dfagegate : la solution packagée
[Notre module dfagegate](https://www.datafirefly.com/product/verification-age-prestashop-modal-cbd-alcool-vape-medical/) implémente directement le pattern décrit. Pour 29 €, vous obtenez :
- **Modale bloquante propre**, design configurable depuis le BO (couleurs, logo, textes).
- **Activation par catégorie ou globale** : vous pouvez réserver l'age gate aux fiches produits CBD/vape, ou l'imposer à toute la boutique.
- **Cookie de consentement** avec durée configurable (par défaut 30 jours).
- **Multilingue FR/EN/ES/DE** avec traductions natives.
- **Redirection paramétrable** si le visiteur se déclare mineur.
- **Compatible RGPD** : ne déclenche pas les trackers avant validation.
- **Mobile-first**, testé sur iOS Safari, Chrome Android, Firefox mobile.
- **Sans modification du thème** : 100 % via hook, déinstallation propre.
C'est la solution la plus directe pour passer en conformité sans une journée de dev.
## L'impact mesuré sur le funnel
Sur les boutiques où nous avons déployé un age gate propre (vs un age gate maison bricolé), nous mesurons en moyenne :
- Taux d'abandon à la modale : **3 à 5 %** (vs 15-25 % avec un age gate bricolé).
- Bounce rate global : **+1 à +2 points** (vs +8 à +12 points).
- Conversion : impact non significatif après réaffichage 30 jours plus tard (les revenants ne voient pas la modale).
L'idée que « l'age gate tue la conversion » vient des implémentations ratées. Une modale propre, sortie une seule fois par visiteur, n'a quasiment pas d'impact mesurable au-delà du premier filtrage.
## FAQ
### L'age gate est-il obligatoire pour le CBD en France en 2026 ?
Le cadre légal n'est pas explicite, mais l'autorégulation du secteur et les CGV des partenaires (transporteurs, paiement) l'exigent en pratique. Vendre du CBD sans age gate +18 est devenu impossible pour rester sur des marketplaces et conserver son compte Stripe/Mollie.
### Le déclaratif simple est-il juridiquement suffisant pour l'alcool ?
Pour la vente en ligne d'alcool à domicile, le déclaratif (binaire ou par date de naissance) est accepté par la DGCCRF tant qu'il est combiné à une signature adulte à la livraison. Pour Drive ou Click&Collect, la vérification physique se fait au retrait. Un age gate déclaratif seul ne suffit pas — il faut le chaînage logistique.
### Que faire si le visiteur clique « moins de 18 ans » ?
Pas de bonne pratique unique. Trois options : rediriger vers Google (radical, légalement sûr), rediriger vers une page d'information sur la consommation responsable (plus social), ou afficher un message bloquant interdisant l'accès (frustrant mais clair). Notre recommandation : page d'information dédiée, sobre, sans appel à revenir.
### L'age gate impacte-t-il le SEO ?
Si la modale bloque le rendu de la page pour les robots, oui — Google ne voit que la modale et ne peut pas indexer le contenu. Solution : autoriser le passage des user-agents Googlebot et Bingbot (en bypass de la modale), et s'assurer que le HTML produit ne masque pas le contenu via display:none AVANT consentement. Notre module gère ce cas par défaut.
### Peut-on combiner age gate et bandeau cookies RGPD ?
Oui, et c'est même recommandé. L'age gate s'affiche en premier (vérification de la majorité), puis le bandeau cookies après acceptation. Voir notre [guide RGPD Consent Mode v2 PrestaShop](https://www.datafirefly.com/2026/05/09/rgpd-consent-mode-v2-prestashop-2026-tracking-ga4/) pour le chaînage correct.
## Pour aller plus loin
La conformité sectorielle (CBD, vape, alcool) est devenue en 2026 un enjeu opérationnel autant que juridique : transporteurs, processeurs de paiement et marketplaces refusent désormais les boutiques non conformes. L'age gate est le premier maillon. Pour les secteurs alimentaires, voir aussi notre prochain dossier sur la conformité INCO 1169/2011 et la directive Omnibus pour l'affichage des prix promotionnels.
À lire aussi : [la checklist GPSR](https://www.datafirefly.com/2026/06/04/gpsr-2026-checklist-conformite-produit-prestashop/) et [la directive Omnibus et le prix de référence](https://www.datafirefly.com/2026/06/22/directive-omnibus-prix-reference-promotions-prestashop-2026/).
Pour passer à l'action : [notre sélection de modules de conformité produit](https://www.datafirefly.com/solutions/prestashop/conformite-produits/).
---
### Core Web Vitals 2026 : passer PrestaShop au vert (cache, Critical CSS, images next-gen)
_Source :_ — _publié_ 2026-06-15
> LCP, INP, CLS : les Core Web Vitals sont des facteurs de ranking directs. Voici la chaîne d'optimisation complète pour faire passer une boutique PrestaShop au vert en 2026 — cache full-page, Critical CSS, images WebP/AVIF et facettes performantes.
Les Core Web Vitals ne sont plus un sujet de niche pour développeurs. Depuis que Google en a fait un facteur de ranking direct, un LCP à 4 secondes ou un CLS qui saute coûte des positions sur les requêtes produit — et donc du chiffre d'affaires. En 2026, l'INP a remplacé le FID et durcit encore la donne sur mobile. La bonne nouvelle : une boutique PrestaShop peut passer au vert sans refonte, à condition d'attaquer les trois métriques dans le bon ordre.
Cet article détaille la chaîne d'optimisation complète : ce qui pèse vraiment sur LCP, INP et CLS, et les leviers techniques qui font basculer le statut Search Console de « À améliorer » à « Bon ».
## Comprendre ce que mesure chaque métrique
**LCP (Largest Contentful Paint)** mesure le temps d'affichage du plus gros élément visible — souvent l'image principale de la fiche produit ou le visuel hero de la home. **INP (Interaction to Next Paint)** mesure la réactivité : le délai entre un clic et la réponse visible de la page, plombé par le JavaScript. **CLS (Cumulative Layout Shift)** mesure la stabilité visuelle : tout élément qui « pousse » le contenu après coup (image sans dimensions, bannière injectée) dégrade le score.
## Étape 1 — Le cache full-page, le plus gros levier LCP
PrestaShop régénère le HTML à chaque visite si rien ne le met en cache. Sur un hébergement mutualisé, le TTFB (time to first byte) explose et tire le LCP vers le haut. Un cache full-page sert le HTML déjà construit en quelques millisecondes. C'est, de loin, le levier qui a le plus d'impact sur le LCP — avant même de toucher aux images. Couplé à la génération de **Critical CSS** (le CSS minimal nécessaire pour afficher le above-the-fold, injecté inline, le reste chargé en différé), on supprime le render-blocking qui retarde le premier rendu.
C'est exactement ce que regroupe : cache page, Critical CSS et optimisations avancées dans un seul module, sans bricolage serveur.
## Étape 2 — Les images next-gen (WebP / AVIF)
Sur une boutique, les images représentent souvent 70 % du poids des pages. Servir du JPEG/PNG en 2026, c'est laisser 30 à 60 % de poids inutile. Le WebP et surtout l'AVIF offrent la même qualité visuelle pour une fraction du poids — un gain direct sur le LCP mobile. La règle : conversion automatique à la volée, service en local (pas de dépendance à un CDN tiers payant), et fallback pour les vieux navigateurs.
Côté PrestaShop, fait cette conversion automatiquement et 100 % en local. Si votre boutique tourne sous WooCommerce, l'équivalent est — même logique, sans abonnement.
## Étape 3 — Maîtriser le CLS et l'INP
Le CLS se règle en réservant l'espace : dimensions explicites ou aspect-ratio sur chaque image et iframe, polices chargées avec font-display swap et fallback métrique. L'INP se gagne en allégeant le JavaScript : différer les scripts non critiques, éviter les sliders et popups lourds au chargement. Un cas classique qui plombe les deux : une galerie produit ou une vidéo mal intégrée — sujet que nous avons détaillé dans .
## Le cas particulier des pages à facettes
Les pages de catégorie filtrées (recherche à facettes) sont souvent les pires élèves : rechargements complets, URLs non indexables, JavaScript lourd. Un moteur de facettes pensé pour la performance et le SEO, comme , résout les filtres côté serveur avec des landing pages indexables et un rendu rapide — au lieu de dégrader l'INP à chaque clic de filtre.
## Conclusion : optimiser dans l'ordre, mesurer en continu
La séquence gagnante est claire : cache full-page et Critical CSS d'abord (impact LCP maximal), puis images next-gen, puis stabilité (CLS) et réactivité (INP). Mesurez avant/après dans la Search Console sur données terrain (CrUX), pas seulement en Lighthouse labo. Pour creuser la méthode avec du vrai code, notre va plus loin, et l'ensemble de nos guides est rassemblé dans la catégorie
À lire aussi : [le guide complet Core Web Vitals](https://www.datafirefly.com/2026/05/01/core-web-vitals-guide-prestashop-wordpress-2026/) et [la checklist technique LCP, INP, CLS](https://www.datafirefly.com/2026/05/09/performance-prestashop-8-checklist-core-web-vitals-2026-lcp-inp-cls/).
Pour passer à l'action : [notre sélection de modules pour accélérer votre boutique PrestaShop](https://www.datafirefly.com/solutions/prestashop/performance-vitesse/).
---
### Pourquoi votre base PrestaShop pèse 8 Go en 2026 : audit, nettoyage et stratégie de rétention des tables ballast
_Source :_ — _publié_ 2026-06-14
> Une boutique PrestaShop active 5 ans pèse 6 à 12 Go en BDD, dont 80 % de tables ballast jamais nettoyées. On audite, on cartographie, on définit une politique de rétention — et on automatise. Sans casser la boutique.
Une boutique PrestaShop en production depuis cinq ans pèse rarement moins de 6 Go en base de données. Beaucoup dépassent les 12 Go. Ce n'est pas le catalogue qui explose — un catalogue de 10 000 produits avec déclinaisons, images et SEO complet tient sous le gigaoctet. Ce qui gonfle, ce sont les **tables ballast** : des tables techniques que PrestaShop alimente en continu et qu'aucun process natif ne nettoie. Au bout de cinq ans, elles représentent souvent 70 à 90 % du poids total de la BDD.
Cet article cartographie les tables coupables, donne les requêtes SQL pour mesurer le gain potentiel, et explique comment mettre en place une politique de rétention durable sans casser la boutique. Pas une checklist de magazine — la version qu'on applique réellement en production.
## Pourquoi une base PrestaShop gonfle sans bruit
PrestaShop n'a pas de garbage collector. Toutes les tables qui enregistrent des événements — recherches internes, connexions, paniers abandonnés, logs, métadonnées orphelines — grossissent linéairement, parfois exponentiellement, sans qu'aucun mécanisme natif ne déclenche un nettoyage.
Concrètement, sur une boutique avec 2 000 visiteurs/jour :
- `ps_statssearch` reçoit 300 à 800 lignes par jour (chaque recherche interne, même vide).
- `ps_connections` et `ps_connections_page` enregistrent chaque visite et chaque page vue. Comptez 5 000 à 15 000 lignes par jour.
- `ps_guest` crée un enregistrement pour chaque visiteur non authentifié.
- `ps_cart` garde tous les paniers — abandonnés inclus — pour toujours. Sur certaines boutiques, on trouve 90 % de paniers vides datant de 2018.
- `ps_log` capture toutes les erreurs et événements admin.
Multipliez par 365 jours et 5 ans : on parle de dizaines de millions de lignes pour un volume métier nul. Le poids brut n'est pas le pire problème. Le vrai coût est ailleurs.
## Le coût caché des tables ballast
### 1. Performance des requêtes
InnoDB charge les index en mémoire (buffer pool). Quand des tables techniques de plusieurs Go monopolisent le buffer, vos requêtes catalogue, panier et commande deviennent plus lentes. Le LCP d'une fiche produit peut prendre 200 à 400 ms supplémentaires uniquement à cause de la pression mémoire MySQL.
### 2. Sauvegardes et restaurations
Un dump `mysqldump` de 12 Go prend 30 à 60 minutes selon le disque. La restauration peut prendre 2 à 4 heures. Si la sauvegarde automatique de votre hébergeur dépasse une fenêtre horaire, elle se met à échouer en silence. Beaucoup de boutiques découvrent qu'elles n'ont plus de sauvegarde valide le jour d'un incident.
### 3. Migrations bloquées
Migrer une boutique 12 Go en PHP 8.2 vers un nouveau serveur, ou en PrestaShop 9, demande de transférer le dump par `rsync`, de restaurer, de tester. Le poids démultiplie chaque opération. Les migrations « simples » deviennent des projets de plusieurs jours.
### 4. Modules tiers qui s'alourdissent
Certains modules de statistiques, de marketing, de connecteurs ERP créent leurs propres tables et les laissent grossir indéfiniment. `ps_netreviews_`, `ps_advancedstats_`, `ps_mailchimp_` sont des suspects fréquents. Un audit révèle souvent une table de 2 Go laissée par un module désinstallé il y a deux ans.
## Audit : combien pèse vraiment votre base
Avant tout nettoyage, on mesure. Cette requête liste les tables de votre base classées par taille décroissante :
```
SELECT
table_name AS 'Table',
ROUND(((data_length + index_length) / 1024 / 1024), 2) AS 'Size (MB)',
table_rows AS 'Rows'
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 30;
```
Vous obtenez en général un palmarès qui ressemble à :
1. `ps_statssearch` — 1,8 Go
2. `ps_connections_page` — 1,2 Go
3. `ps_pagenotfound` — 800 Mo
4. `ps_connections` — 600 Mo
5. `ps_log` — 400 Mo
6. `ps_cart` — 350 Mo
7. `ps_guest` — 300 Mo
8. `ps_cart_rule` + `ps_cart_cart_rule` — 250 Mo
Notez que `ps_product`, `ps_product_lang`, `ps_orders` apparaissent rarement dans le top 10. La donnée métier réelle est minoritaire dans une base PrestaShop ancienne.
## Cartographie des tables ballast et politique de rétention
### ps_statssearch — les recherches internes
Cette table enregistre chaque mot saisi dans la barre de recherche. Garder l'historique au-delà de 90 jours n'a aucun intérêt analytique : les tendances de recherche sur 2019 n'éclairent rien en 2026. **Politique recommandée : rétention 90 jours.**
```
-- Audit
SELECT COUNT(*) AS total, MIN(date_add) AS plus_ancien
FROM ps_statssearch;
-- Suppression au-delà de 90 jours
DELETE FROM ps_statssearch
WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY);
```
### ps_connections et ps_connections_page — l'historique de visite
Si vous utilisez GA4 ou Matomo, ces tables sont redondantes. PrestaShop les remplit pour son propre module de statistiques que personne ne consulte. **Politique : rétention 30 jours, ou 0 si vous avez un outil externe.**
### ps_pagenotfound — les 404
Utile pour identifier les liens cassés et programmer des redirections 301. Mais après traitement, l'historique ne sert plus. **Politique : rétention 60 jours, après extraction des 404 récurrentes.**
### ps_cart — les paniers abandonnés
Subtil. Les paniers récents servent au retargeting et aux relances. Au-delà de 90 jours, un panier abandonné est statistiquement perdu. **Politique : conserver 90 jours, mais ne pas toucher aux paniers liés à des commandes (table jointe ps_orders.id_cart).**
```
-- Suppression sûre : uniquement les paniers SANS commande associée
DELETE c FROM ps_cart c
LEFT JOIN ps_orders o ON o.id_cart = c.id_cart
WHERE o.id_cart IS NULL
AND c.date_add < DATE_SUB(NOW(), INTERVAL 90 DAY);
```
### ps_guest — les visiteurs non authentifiés
Liée à `ps_customer` et `ps_connections`. Nettoyage avec précaution : un guest converti en customer doit être préservé. **Politique : supprimer les guests sans customer et sans connexion récente.**
### ps_log — les logs admin
Utile pour le débogage récent, sans valeur passé un mois. **Politique : rétention 30 jours.**
### Métadonnées orphelines
Quand vous supprimez un produit, certaines tables liées gardent des lignes orphelines : `ps_image`, `ps_feature_product`, `ps_specific_price`, `ps_product_attachment`. Idem pour les catégories, les fabricants, les fournisseurs supprimés. Ces lignes ne servent à rien et faussent les jointures.
```
-- Exemple : ps_image orphelines
SELECT i.id_image FROM ps_image i
LEFT JOIN ps_product p ON p.id_product = i.id_product
WHERE p.id_product IS NULL;
```
## Le piège du DELETE en production
Supprimer un million de lignes en une seule requête sur une table InnoDB lockée par votre admin et votre front, c'est la garantie d'un crash. Le binary log explose, la réplication décroche, le serveur peut partir en swap.
La règle absolue : **supprimer par lots de 5 000 à 10 000 lignes maximum, avec une pause de 100 ms entre chaque lot**.
```
-- Boucle de suppression batchée (pseudo-code)
DO WHILE rows_affected > 0:
DELETE FROM ps_statssearch
WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY)
LIMIT 5000;
SLEEP 0.1;
END DO;
```
Et systématiquement : **dry-run avant execute**. Vous voulez savoir combien de lignes vont disparaître et combien d'espace vous récupérez avant de cliquer.
## Automatiser la rétention : la stratégie correcte
Faire le nettoyage à la main une fois et l'oublier ne sert à rien — la base regonflera. La rétention doit être **continue et automatique** :
1. **Cron quotidien** qui exécute la politique de rétention de chaque table.
2. **Token de sécurité** pour que le cron ne soit pas déclenchable depuis l'extérieur.
3. **Logs d'exécution** pour suivre ce qui a été supprimé.
4. **Notification** en cas d'échec ou d'anomalie (volume anormal de suppression).
5. **OPTIMIZE TABLE** hebdomadaire sur les tables nettoyées pour récupérer l'espace disque (sinon InnoDB conserve l'espace alloué).
## Notre module dfcleanup : la méthode packagée
Implémenter cette stratégie à la main demande deux à trois jours de dev et autant de tests. [Notre module dfcleanup](https://www.datafirefly.com/product/dfcleanup-nettoyage-base-prestashop/) pour PrestaShop 8 et 9 industrialise toute la méthode décrite ici :
- **Six nettoyeurs spécialisés** : recherches, paniers, logs, statistiques, métadonnées orphelines, images orphelines. Chacun avec sa propre rétention configurable.
- **Trois modes** : Audit (lecture seule), Dry-run (simulation tracée), Execute (suppression batchée par lots de 5 000 lignes).
- **Gain en MB calculé avant action**, par cleaner et au total.
- **Tâche cron sécurisée par token**, prête à l'emploi.
- **Logs détaillés** et compatibilité PrestaShop 8 et 9.
Pour 19 €, vous évitez les requêtes DELETE à la main et vous installez une politique de rétention durable. Comparé au temps de dev et au coût d'un incident DBA, c'est un des modules au meilleur ROI du catalogue.
## FAQ
### Faut-il faire un OPTIMIZE TABLE après chaque DELETE ?
Non, pas après chaque DELETE — c'est coûteux en I/O et lock la table. Une fois par semaine ou par mois, en heure creuse, sur les tables qui ont subi un nettoyage massif. `OPTIMIZE TABLE` récupère l'espace disque que InnoDB ne libère pas naturellement après suppression.
### Le nettoyage peut-il affecter le SEO ou les statistiques ?
Aucun impact SEO : les tables nettoyées sont techniques (recherches internes, connexions, logs), pas le catalogue ni l'URL. Côté stats, si vous utilisez GA4 ou Matomo, vos données sont stockées chez eux — la BDD PrestaShop est redondante. Si vous utilisez les statistiques natives PS, configurez une rétention plus longue (180 jours par exemple).
### Quelle rétention pour les paniers abandonnés ?
90 jours suffisent largement. Les outils de relance panier (mail, retargeting) déclenchent dans les 24 à 72 heures. Au-delà de 90 jours, la probabilité de récupération est statistiquement nulle. Et vous ne supprimez jamais un panier converti en commande — la jointure `ps_orders.id_cart` protège cette donnée.
### Combien de gain attendre concrètement ?
Sur une boutique 5 ans, 2 000 visiteurs/jour, nous mesurons en moyenne 60 à 80 % de réduction de la BDD au premier passage. Une boutique à 12 Go redescend à 3 ou 4 Go. Les passages suivants stabilisent la base à un palier proche du « poids métier réel ».
### Le module est-il compatible multi-boutique ?
Oui. Les nettoyeurs respectent le périmètre multi-shop quand c'est pertinent (paniers, recherches par boutique). Les tables globales (logs, connexions) sont nettoyées globalement.
## Pour aller plus loin
La dette de base est une des trois sources principales de dégradation perfomance long-terme d'une boutique PrestaShop, avec les modules tiers obsolètes et les images mal optimisées. Voir aussi notre [checklist Core Web Vitals 2026](https://www.datafirefly.com/2026/05/09/performance-prestashop-8-checklist-core-web-vitals-2026-lcp-inp-cls/) pour le reste du tableau, et le [guide PrestaShop 9 vs 8](https://www.datafirefly.com/2026/05/01/prestashop-9-vs-prestashop-8-changements/) si vous préparez une migration : alléger la BDD avant migration peut diviser par 5 le temps de bascule.
Pour passer à l'action : [notre sélection de modules pour la maintenance, la sauvegarde et la fiabilité](https://www.datafirefly.com/solutions/prestashop/maintenance-sauvegarde-fiabilite/) et [celle pour accélérer votre boutique](https://www.datafirefly.com/solutions/prestashop/performance-vitesse/).
---
### Le meilleur module de recherche PrestaShop en 2026 : pourquoi la recherche native ne suffit plus
_Source :_ — _publié_ 2026-06-13
> Sur une boutique PrestaShop, les visiteurs qui utilisent la recherche convertissent bien plus que les autres — à condition de trouver. La recherche native les laisse en plan. Voici ce qui fait le meilleur module de recherche PrestaShop, et pourquoi une recherche live avec analytics change la donne.
Sur une boutique en ligne, le visiteur qui tape dans la barre de recherche est le plus précieux de tous : il sait ce qu'il veut. Les études de CRO le confirment depuis des années — les internautes qui utilisent la recherche interne convertissent nettement plus que ceux qui se contentent de naviguer. Le problème, c'est que sur PrestaShop, la recherche native ne tient pas la promesse. Elle laisse partir précisément les clients les plus chauds.
Cet article fait le point sur ce qui distingue réellement le **meilleur module de recherche PrestaShop** d'une simple barre d'autocomplétion, et pourquoi une recherche live couplée à de l'analytics est devenue un standard en 2026 sur PrestaShop 8 et 9.
## La recherche native de PrestaShop : un angle mort qui coûte des ventes
Le moteur de recherche intégré de PrestaShop fonctionne, mais il appartient à une autre époque. À chaque validation, il recharge une page de résultats complète. Sur mobile, où se joue désormais la majorité du trafic, ce rechargement est lent et décourageant. Le client qui ne trouve pas en deux secondes ne reformule pas : il quitte.
Pire, la recherche native est une boîte noire. Vous ne savez pas ce que vos clients cherchent, combien de fois une requête ne retourne aucun résultat, ni si ces recherches débouchent sur une vente. Vous pilotez à l'aveugle un des leviers de conversion les plus puissants de votre boutique.
## Qu'est-ce qui fait le meilleur module de recherche PrestaShop ?
Avant de comparer des solutions, il faut savoir ce qu'on évalue. Un module de recherche réellement performant en 2026 réunit, selon nous, six critères :
- **L'instantanéité** : des résultats live en AJAX dès les premiers caractères, dans un dropdown, sans rechargement de page.
- **La suggestion proactive** : proposer des pistes avant même la frappe (recherches populaires, produits recommandés).
- **L'analytics** : savoir ce que les clients cherchent, ce qui retourne du vide, ce qui convertit.
- **Le tracking de conversion** : relier une recherche à une commande pour mesurer le ROI réel du champ.
- **La détection des lacunes** : repérer automatiquement les requêtes sans résultat, qui trahissent un manque catalogue ou une faute de frappe fréquente.
- **La compatibilité** : PrestaShop 8 et 9, multiboutique et multilingue, sans bricolage.
La plupart des modules du marché cochent un ou deux de ces critères — souvent l'autocomplétion seule. Rares sont ceux qui couvrent l'ensemble. C'est précisément ce qui distingue .
## DFLiveSearch : la recherche live qui convertit
remplace la recherche native par un moteur live complet. Dès deux caractères saisis (seuil configurable), un dropdown s'ouvre avec les produits correspondants : image, nom, prix et badge promotion. La navigation au clavier est incluse, et l'expérience reste fluide y compris sur mobile. Le client voit ce qu'il cherche apparaître sous ses yeux et clique directement dessus.
### Des suggestions avant même le premier caractère
Au moment où le client active le champ, deux carousels s'affichent : les recherches les plus populaires sur votre boutique et une sélection de produits recommandés. Ces données ne sont pas génériques : elles sont calculées à partir des logs réels de votre boutique. Avec l'option de personnalisation, les produits recommandés tiennent même compte de l'historique de navigation du client connecté. Le champ de recherche devient ainsi une vitrine, pas seulement un outil.
### Un dashboard analytics qui révèle vos angles morts
C'est là que le module change vraiment la donne. Chaque recherche est enregistrée — terme saisi, nombre de résultats, clic, conversion en commande. Le back-office affiche le taux de succès, le taux de clic et le taux de conversion, un graphique d'évolution sur 30 jours, le top 20 des recherches et, surtout, le top 20 des recherches _sans résultat_. Cette dernière liste est une mine d'or : elle vous dit noir sur blanc quels produits vos clients réclament et que vous n'avez pas, ou sous quelle orthographe ils vous cherchent. L'export CSV permet d'aller plus loin dans l'analyse.
### Des alertes pour combler les lacunes du catalogue
Plutôt que de consulter le dashboard manuellement, vous laissez le module surveiller pour vous. Dès qu'un terme dépasse un seuil configurable (cinq recherches sans résultat par défaut), une alerte email part automatiquement et une notification apparaît dans le header du back-office. Vous traitez le manque pendant qu'il est encore chaud, au lieu de le découvrir un mois plus tard.
### De la recherche à l'achat sans quitter la page
L'option d'ajout rapide au panier permet au client d'ajouter un produit directement depuis le dropdown, avec un sélecteur de quantité optionnel — sans jamais charger la fiche produit. Et le module boucle la mesure : si une commande suit un clic dans les résultats de recherche, elle est marquée comme convertie et comptabilisée. Vous savez enfin combien votre champ de recherche vous rapporte vraiment.
## Recherche native, module gratuit ou DFLiveSearch : que choisir ?
La recherche native a un mérite : elle est gratuite et déjà là. Mais elle reste muette et lente. Les modules d'autocomplétion gratuits améliorent l'affichage des suggestions, sans rien apporter côté pilotage : aucune statistique, aucun suivi de conversion, aucune alerte. Vous gagnez un peu de confort visuel, mais vous restez aveugle.
se place sur un autre terrain : celui de la recherche pilotée par la donnée. C'est un achat unique, sans abonnement mensuel — un argument qui pèse face aux solutions SaaS de search facturées au volume de requêtes, dont la facture grimpe avec votre trafic. Pour une boutique où la recherche représente une part sérieuse des ventes, l'investissement se rentabilise vite.
## Le verdict
Il n'existe pas de « meilleur module » dans l'absolu, mais un meilleur module _pour un objectif_. Si le vôtre est de transformer le trafic de recherche — le plus qualifié de votre boutique — en commandes, alors le bon outil est celui qui combine recherche live, suggestions proactives, analytics et tracking de conversion. Sur PrestaShop 8 et 9, coche les six critères qui comptent, là où la plupart se contentent d'un joli dropdown.
Pour aller plus loin sur l'optimisation du tunnel de conversion, parcourez la catégorie
Pour passer à l'action : [notre sélection de modules pour la recherche et la navigation](https://www.datafirefly.com/solutions/prestashop/recherche-navigation/).
---
### Web Push vs email : reconquérir ses visiteurs sans abonnement mensuel
_Source :_ — _publié_ 2026-06-12
> 98 % des visiteurs partent sans acheter. Email et Web Push sont les deux canaux pour les faire revenir — mais ils ne jouent pas le même rôle. Comparatif honnête et stack de reconquête sans abonnement mensuel, pour PrestaShop et WooCommerce.
En moyenne, 98 % des visiteurs d'une boutique repartent sans acheter, et près de 70 % des paniers sont abandonnés. La vraie bataille du e-commerce ne se joue pas sur l'acquisition mais sur la reconquête : faire revenir ces visiteurs. Deux canaux dominent — l'email et le Web Push — et la plupart des marchands les opposent à tort. Ils ne jouent pas le même rôle, et bien utilisés, ils se complètent.
Cet article compare honnêtement les deux canaux et propose un stack de reconquête sans abonnement mensuel, là où les SaaS du marché facturent au volume d'envois.
## Email : la profondeur, mais la friction de l'opt-in
L'email reste imbattable pour les messages riches : relances de panier détaillées avec visuels produit, séquences de nurturing, offres personnalisées, factures. Son défaut : il exige une adresse, donc un visiteur déjà au moins en partie engagé (compte créé, panier renseigné). Les taux d'ouverture plafonnent souvent à 15-25 %, et le délai de réaction est long. L'email est le canal de la _relation_.
## Web Push : l'immédiateté, sans demander d'adresse
Le Web Push ne demande qu'un clic « Autoriser » — pas d'email, pas de formulaire. Le message arrive directement sur l'écran, même quand le visiteur n'est plus sur le site. Les taux de clic sont structurellement plus élevés que l'email sur les messages courts et urgents (baisse de prix, retour en stock, fin de promo). Son défaut : le message est bref et l'opt-in se perd si on le déclenche au mauvais moment. Le Web Push est le canal du _déclencheur_.
Côté PrestaShop, permet de reconquérir sans SDK ni abonnement ; l'équivalent WooCommerce est , en push web natif sans tracking tiers.
## La règle de répartition : urgence au push, profondeur à l'email
Le bon arbitrage n'est pas « l'un ou l'autre » mais « le bon message sur le bon canal » :
- **Web Push** : retour en stock, baisse de prix sur un produit consulté, dernières heures d'une promo, nouveauté. Court, urgent, instantané.
- **Email** : séquence de relance panier en plusieurs étapes, récapitulatif détaillé, bon de réduction nominatif, réassurance.
La relance de panier abandonné mérite une mention à part : c'est le scénario au meilleur ROI du e-commerce. Une (rappel à H+1, incitation à J+1, dernière chance à J+3) récupère structurellement plus qu'un envoi unique.
## Ne pas négliger l'on-site : le centre de notifications
Entre l'email (hors site) et le push (hors site), il manque souvent une brique : la notification _sur_ le site. Une cloche avec pastille de non-lus qui annonce nouveautés et codes promo transforme un visiteur présent en acheteur, sans aucun opt-in. (ou ) joue ce rôle de relais on-site.
## Le vrai sujet : le coût
La plupart des solutions Web Push et de relance sont des SaaS qui facturent à l'abonné ou à l'envoi. À volume élevé, la facture mensuelle dépasse vite le prix d'un module acheté une fois. Pour un marchand qui maîtrise déjà sa donnée, des modules natifs sans abonnement éliminent ce coût récurrent et gardent les données en interne — un argument à la fois budgétaire et RGPD.
## Conclusion : un stack de reconquête, pas un canal unique
La reconquête efficace combine trois temps : la notification on-site quand le visiteur est là, le Web Push pour le rappeler sur un déclencheur précis, l'email pour la relance profonde. Aucun canal ne suffit seul. Pour aller plus loin sur l'optimisation du tunnel, parcourez la catégorie
Pour passer à l'action : [notre sélection de modules pour fidéliser vos clients](https://www.datafirefly.com/solutions/prestashop/fidelisation-clients/).
---
### Vendre autrement sur PrestaShop : marketplace multi-vendeurs et B2B
_Source :_ — _publié_ 2026-06-11
> Au-delà du B2C classique, PrestaShop sait porter des modèles plus ambitieux : marketplace multi-vendeurs et vente B2B. Voici quand chaque modèle a du sens, ce qu'il faut techniquement, et comment l'assembler sans passer à Adobe Commerce.
« PrestaShop, c'est pour le B2C mono-vendeur. » Ce récit a la vie dure, et il est faux en 2026. Avec les bonnes briques, PrestaShop porte deux modèles bien plus ambitieux : la **marketplace multi-vendeurs** (vous ouvrez votre boutique à des vendeurs tiers et prenez une commission) et la **vente B2B** (devis, prix négociés, comptes pros). Les deux peuvent même cohabiter. Encore faut-il savoir quand chaque modèle a du sens et ce qu'il exige techniquement.
## Le modèle marketplace : passer de revendeur à plateforme
Devenir marketplace, c'est changer de métier : vous ne vendez plus seulement vos produits, vous orchestrez les ventes d'autres vendeurs et prélevez une commission. Le modèle est puissant — catalogue élargi sans stock, revenu sur chaque transaction — mais il impose une mécanique précise :
- Espace vendeur autonome : inscription, gestion de catalogue, suivi des commandes.
- Répartition automatique des commandes et calcul des commissions par vendeur.
- Versements (payouts) et relevés vendeurs.
- Modération des produits et des vendeurs.
Construire cela à la main est un projet lourd. fournit cette mécanique clé en main sur PrestaShop, à une fraction du coût d'une plateforme dédiée.
## Le modèle B2B : le devis avant le panier
En B2B, l'acheteur professionnel ne clique pas « Ajouter au panier » sur un coup de tête. Il constitue une sélection, demande un devis, négocie, puis convertit en commande. PrestaShop ne gère pas ce flux nativement, mais l'ajoute : du devis à la commande sans quitter la boutique. Nous avons cartographié l'ensemble du stack B2B (validation SIRET/VIES, paiement différé, comptes pros) dans .
## Les offres groupées : le levier de panier qui sert les deux modèles
Que vous soyez en B2C, en B2B ou en marketplace, augmenter le panier moyen reste central. Les offres groupées intelligentes — packs, « achetez X recevez Y », cadeau automatique au-delà d'un seuil — sont un levier transversal. permet de les présenter proprement sur la fiche produit, avec ajout automatique des produits liés.
## Marketplace et B2B : faut-il choisir ?
Non, et c'est souvent là que PrestaShop brille. Une marketplace B2B (plateforme multi-vendeurs avec devis et tarification pro) est un modèle en forte croissance — distribution professionnelle, grossistes, secteurs de niche. La logique technique consiste à empiler les briques : socle marketplace pour la multi-vendeur, brique devis pour le B2B, groupes clients et prix par groupe pour la tarification. C'est l'assemblage cohérent, pas la plateforme, qui fait la différence.
## Le budget réel face aux alternatives
Un stack marketplace + B2B sur PrestaShop se chiffre en quelques centaines d'euros de modules plus le paramétrage — très loin des budgets Adobe Commerce ou Mirakl, pour un périmètre fonctionnel qui couvre la majorité des besoins PME/ETI. Le compromis se situe sur les cas extrêmes (catalogues à très grande échelle, workflows d'approbation multi-niveaux), où une plateforme entreprise reste justifiée.
## Conclusion : la plateforme n'est pas la limite, l'assemblage l'est
PrestaShop n'impose pas le modèle mono-vendeur B2C. Marketplace, B2B, ou les deux : tout dépend des briques que vous assemblez. Pour comparer les solutions par usage, parcourez nos
Pour passer à l'action : [notre sélection de modules pour vendre en B2B](https://www.datafirefly.com/solutions/prestashop/vente-b2b/).
---
### Migration PrestaShop 1.7 → 8 : la checklist complète 2026 (modules cassés, performance, SEO, données)
_Source :_ — _publié_ 2026-06-10
> PrestaShop 1.7 est en fin de support sécurité depuis fin 2025. La migration vers PS8 n'est plus une option en 2026. Voici la checklist complète : audit préalable, modules cassés à remplacer, gestion des données, redirections 301 SEO, et l'opportunité de moderniser le stack au passage.
En 2026, une part significative des boutiques PrestaShop tourne encore sous version 1.7 — sortie en 2016, déclarée en fin de support officiel par PrestaShop SA en 2024, et désormais sans correctifs de sécurité depuis fin 2025. Ces boutiques accumulent les risques : incompatibilités PHP récents, modules 1.7 abandonnés, vulnérabilités non patchées, performance plombée par des hooks legacy, et impossibilité d'utiliser le catalogue moderne PS8 (cross-sell intelligent, FAQ IA, AEO, multi-pays propre).
La migration vers PrestaShop 8 n'est plus une option en 2026 — c'est une obligation à terme. Mais c'est un projet à part entière, pas un clic dans le back-office. Cet article détaille la checklist complète de migration 1.7 → 8 : l'audit préalable, les modules à remplacer, la gestion des données, la critique du SEO et des redirections, et l'opportunité de moderniser le stack technique au passage.
## Pourquoi migrer en 2026 (et pourquoi attendre devient risqué)
Trois forces convergent en 2026 pour rendre la migration 1.7 → 8 inévitable.
**Fin du support sécurité.** PrestaShop SA n'émet plus de correctifs de sécurité pour la branche 1.7 depuis fin 2025. Toute faille découverte après cette date reste exploitable, et la quantité de boutiques 1.7 encore en ligne en fait une cible privilégiée pour les attaquants. Sur les audits récents, plusieurs boutiques 1.7 ont été compromises via des modules tiers vulnérables qui ne sont plus maintenus — admin défacé, tunnel de paiement détourné, données clients exfiltrées.
**Incompatibilité PHP.** PrestaShop 1.7 ne supporte officiellement que PHP 7.4 et certaines versions de PHP 8.0. Or PHP 7.4 est en fin de vie depuis novembre 2022, et la majorité des hébergeurs ont retiré ou retirent PHP 7.4 de leurs offres. Les boutiques 1.7 forcées de tourner en PHP 8.1 ou 8.2 expérimentent des bugs aléatoires (warnings, deprecated, casts implicites cassés) qui dégradent le fonctionnement.
**Catalogue moderne PS8 inaccessible.** Tous les modules e-commerce 2026 modernes (FAQ IA, AEO via llms.txt, cross-sell pondéré avec analytics, marquage Schema.org étendu, multi-pays propre avec hreflang automatique) sont développés pour PrestaShop 8. Les versions 1.7 de ces modules, quand elles existent, sont des portages dégradés — fonctions limitées, performance moindre, support arrêté.
L'arbitrage économique est simple : le coût d'une migration sérieuse en 2026 (typiquement 5 000 à 25 000 € selon la taille de la boutique et la complexité) est inférieur au coût cumulé de rester sur 1.7 — failles de sécurité, perte de modules modernes, dégradation de performance, perte de clients à cause de bugs PHP.
## L'audit préalable : ce qu'il faut savoir avant de migrer
Avant tout devis ou planning de migration, un audit complet de votre boutique 1.7 actuelle. Sans cet audit, vous découvrez les complications en cours de projet et le budget explose.
**Inventaire des modules installés.** Listez tous les modules activés sur la boutique. Pour chacun : la version, le statut (actif / désactivé / orphelin), l'auteur, la date de dernière mise à jour, et la disponibilité d'une version PrestaShop 8. Sur les boutiques 1.7 mature, on trouve typiquement 30 à 80 modules dont 20 à 40 % sont en réalité abandonnés ou orphelins — désactivés depuis longtemps, sans usage actif. Ceux-là disparaissent automatiquement à la migration.
**Inventaire des modifications custom.** Override de classes core dans `override/classes/`, override de controllers, modifications de templates Smarty, mods directs dans le code core (pratique anti-pattern fréquente sur les boutiques 1.7 anciennes). Toutes ces modifications sont à recenser et à documenter — elles ne survivront pas à la migration sans intervention manuelle.
**Audit du thème.** Si vous utilisez un thème custom (et non un thème classic-rocket ou Hummingbird natif), vérifiez sa compatibilité PS8. Beaucoup de thèmes 1.7 commerciaux ne sont jamais portés sur PS8 — votre choix est alors entre acheter une nouvelle licence PS8 du même thème (si disponible), choisir un nouveau thème PS8, ou faire porter le thème custom par un développeur (cher).
**Audit des données.** Volumétrie des produits, des commandes, des clients, des avis. Une migration de boutique avec 500 produits et 5 000 commandes prend quelques jours de travail. Une migration de boutique avec 50 000 produits et 500 000 commandes prend plusieurs semaines avec coordination logistique (gel de la prod, fenêtre de bascule).
**Audit SEO.** Top 100 des pages avec trafic organique, top 100 des pages avec backlinks, structure des URL actuelles. Cette donnée est critique pour planifier les redirections 301 (sujet d'une section dédiée plus bas).
## Les modules 1.7 cassés à remplacer
Sur les migrations que nous avons accompagnées, voici les catégories de modules qui posent systématiquement problème.
**Modules de cross-sell 1.7.** Les modules de produits associés en version 1.7 (pscrosssellsproducts, blockcategories enrichi, certains modules tiers) ne marchent pas en PS8 et leurs équivalents PS8 sont souvent rebrandés. Profitez de la migration pour passer à un cross-sell moderne avec analytics et stratégies pondérées — sujet traité dans notre article sur les [7 stratégies de cross-sell 2026](/2026/05/09/panier-moyen-prestashop-8-7-strategies-cross-sell-2026/). Module recommandé : [DataFirefly Cross-Sell](/product/datafirefly-cross-sell-prestashop-8/).
**Modules d'avis 1.7.** Les modules d'avis natifs PS 1.7 (productcomments) et les modules tiers anciens ne génèrent pas de marquage Schema.org AggregateRating + Review propre — donc pas d'étoiles dans la SERP, pas de citation dans les Answer Engines (sujet AEO traité dans notre article dédié). À remplacer par un module moderne comme [DataFirefly Avis Vérifiés](/product/datafirefly-avis-verifies-prestashop-8/) qui couvre le marquage complet.
**Modules de FAQ produit 1.7.** La majorité des modules FAQ 1.7 sont du Smarty hardcodé sans gestion IA ni Schema.org propre. Le passage à PS8 est l'occasion de basculer sur un module FAQ avec génération IA en masse comme [DataFirefly FAQ IA Produit](/product/datafirefly-faq-ia-produit-prestashop-8/) — gain de temps massif sur la rédaction et marquage Schema.org valide.
**Modules de wishlist 1.7.** Les wishlist 1.7 sont généralement basiques (ajouter / supprimer / lister) sans capture d'email anonyme, sans alerte prix, sans analytics. À remplacer par [DataFirefly Wishlist Avancée](/product/dfwishlist/) — sujet traité dans notre article sur la [wishlist comme levier de conversion](/2026/05/09/wishlist-prestashop-levier-conversion-alertes-prix-2026/).
**Modules de panier latéral / sidecart 1.7.** Souvent absents en 1.7 (le panier était une page dédiée, sans sidecart). À ajouter en PS8 avec [DataFirefly SideCart](/product/datafirefly-sidecart-prestashop-8/) qui modernise l'expérience post-add-to-cart.
**Modules SEO multi-pays 1.7.** Les modules hreflang 1.7 sont souvent partiels et ne gèrent pas la réciprocité ou les codes ISO correctement. À remplacer par [module Hreflang DataFirefly](/product/module-hreflang-prestashop-8-balises-alternate-seo-multilingue-datafirefly/) + [Sélecteur de Pays](/product/module-selecteur-de-pays-prestashop-8-drapeaux-cliquables-datafirefly/).
**Modules paiement 1.7.** Les anciens modules de paiement 1.7 sont souvent incompatibles avec les exigences SCA / 3DS2 modernes, ou non conformes PSD2. La majorité des banques et processeurs (Stripe, Mollie, Adyen, BNP, Société Générale, Crédit Mutuel via Mercanet) ont des modules PS8 modernes à activer en remplacement. À tester rigoureusement avant bascule en prod — un paiement cassé en prod, c'est du CA perdu.
**Modules de tracking analytics 1.7.** Les modules GA Universal ou GTM legacy 1.7 ne supportent pas le Consent Mode v2 (obligatoire en 2026 pour Google Ads / GA4). À remplacer par [Google Tag Pro](/product/google-tag-pro-plug-play/) ou similaire qui gère Consent Mode v2 nativement, plus [Cookie Manager Tarteaucitron](/product/cookie-manager-tarteaucitron-conformite-rgpd-cle-en-main-pour-prestashop/) pour la CMP.
## La gestion des données : import / export propre
La migration des données est techniquement la partie la plus risquée. PrestaShop ne fournit pas de migrateur natif 1.7 → 8 fiable — l'outil Module Migration Manager qui existe a des limitations connues sur les catalogues complexes.
L'approche éprouvée :
**Étape 1 — Export propre depuis 1.7.** Export CSV / XML des produits, catégories, clients, commandes, avis, descripteurs (caractéristiques, attributs). Conserver les ID originaux pour pouvoir mapper les redirections SEO ensuite.
**Étape 2 — Installation PS8 propre.** Sur un environnement dédié (staging), installer PS8 from scratch avec un thème compatible et les modules de base. Ne pas réinstaller les modules 1.7 — installer les versions PS8 modernes équivalentes.
**Étape 3 — Import structuré.** Import dans l'ordre : catégories → caractéristiques → produits → images produit → clients → adresses → commandes → avis. L'ordre compte parce que certaines tables référencent d'autres (un produit référence une catégorie qui doit déjà exister).
**Étape 4 — Vérification de cohérence.** Compter le nombre de lignes par table après import, comparer aux comptes de la 1.7 d'origine. Tester quelques fiches produit, quelques catégories, quelques commandes pour vérifier que tout est cohérent visuellement.
**Étape 5 — Tests fonctionnels.** Parcours complet sur staging : navigation, ajout panier, checkout, paiement (en mode test), confirmation. Tester aussi les fonctionnalités admin (gestion commandes, gestion produits, gestion clients).
## SEO et redirections 301 : la partie qu'on rate le plus souvent
Les URL changent entre PS 1.7 et PS 8, parfois subtilement (structure de slug, gestion des paramètres, ajout du multilingue). Sans plan de redirection 301 systématique, vous perdez toute votre autorité SEO accumulée.
Les types d'URL à mapper :
- **URL produit** : ancien format `/category/123-slug-produit.html` vs nouveau format `/category/produit-456` (ou inverse selon votre config). Mapper produit par produit.
- **URL catégorie** : peuvent changer si la hiérarchie ou les slugs ont été ajustés.
- **URL CMS / pages statiques** : à mapper individuellement.
- **URL fournisseurs / marques** : si vous les utilisiez en 1.7.
- **URL paramétrées avec filtres** : à mapper vers les nouvelles URL faceted search PS8.
Implémentation pratique : un fichier de redirections 301 dans `.htaccess` ou nginx config, ou un module de redirections PS8 (plusieurs existent au marketplace) qui les gère depuis la base de données. Pour les très gros catalogues (10 000+ produits), automatiser le mapping via script qui lit l'ancien sitemap et génère les redirections vers les nouvelles URL en se basant sur les slugs ou les SKUs.
Et critique : surveiller Search Console pendant 4-8 semaines après la bascule pour détecter les erreurs 404. Chaque 404 révèle une URL ancienne qui n'a pas été redirigée — à ajouter au fichier de redirections au fur et à mesure.
## La checklist de migration en 12 étapes
1. **Audit complet** de la boutique 1.7 actuelle (modules, thème, custom code, données, SEO).
2. **Choix du thème PS8** (réplique du thème actuel ou nouveau choix).
3. **Choix des modules PS8** de remplacement, avec audit des modules à abandonner.
4. **Provisioning environnement PS8** (hébergement, PHP 8.2+, MySQL 8 / MariaDB 11, certificats SSL).
5. **Installation PS8 propre** et configuration de base (langues, devises, multilingue, pays).
6. **Installation des modules PS8** sélectionnés et configuration.
7. **Import des données** depuis l'export 1.7 (catégories, produits, clients, commandes).
8. **Production des redirections 301** mappant ancien URL → nouveau URL.
9. **Tests fonctionnels exhaustifs** sur staging (navigation, checkout, admin).
10. **Bascule en production** (DNS, certificats, fichier `.htaccess` ou nginx config avec redirections).
11. **Surveillance post-bascule** Search Console, GA4, logs serveur, retours clients.
12. **Itération corrective** sur les bugs détectés en prod (compter 2-4 semaines de polish post-bascule).
Sur les migrations que nous avons accompagnées, le projet complet dure entre 4 et 12 semaines selon la taille de la boutique et la complexité des customisations.
## L'opportunité de moderniser le stack au passage
Une migration 1.7 → 8 n'est pas seulement un upgrade technique, c'est aussi l'opportunité de moderniser le stack e-commerce qu'on a accumulé pendant des années sans nettoyage.
**Sécurité admin.** Profitez de la migration pour activer la 2FA admin via [2FA Google Authenticator pour PrestaShop](/product/2fa-google-authentificator-pour-prestashop/). C'est une protection essentielle en 2026 que beaucoup de boutiques 1.7 négligent.
**Stack AEO.** Profitez de la migration pour aligner votre boutique sur les standards AEO 2026 (sujet traité dans notre [catégorie AEO](/category/aeo-answer-engines/)). Le combo [LLMs.txt PrestaShop](/product/llms-txt-prestashop-seo-ia-chatgpt/) + FAQ IA + Avis Vérifiés positionne votre boutique pour le trafic ChatGPT / Perplexity / Google AI Overviews.
**Recurring revenue via abonnements.** Si votre catalogue le permet (consommables, box, services digitaux), profitez de PS8 pour ajouter le module [DataFirefly Subscriptions](/product/datafirefly-subscriptions-prestashop-8/) avec Stripe — sujet traité dans notre [guide tunnel d'abonnement](/2026/05/09/tunnel-abonnement-prestashop-stripe-monetiser-recurrent-2026/). Le récurrent sur PrestaShop 1.7 était particulièrement bricolé ; sur PS8 c'est mature.
**Stack de conversion moderne.** Au-delà des remplacements modules cassés, profitez de la migration pour ajouter les leviers que vous n'aviez pas en 1.7 : barre de livraison gratuite avec barre de progression, sidecart, wishlist avec alertes, vidéos produit avec CWV propres. Une migration sans modernisation, c'est une refonte technique sans gain business.
## Erreurs fréquentes en migration 1.7 → 8
**Croire que la migration prend 2 jours.** Sur les devis low-cost qui promettent une migration en 2 jours, vous récupérez systématiquement une boutique cassée. Le minimum réaliste est 2-3 semaines pour une boutique simple, plus pour les complexes.
**Négliger les redirections 301.** La perte de trafic SEO post-migration est typiquement de 30-60 % sans plan de redirection complet. Avec plan, on récupère 90-100 % en 4-8 semaines.
**Garder tous les modules 1.7.** La migration est l'occasion d'élaguer. Les boutiques qui essaient de tout porter à l'identique se retrouvent avec un PS8 alourdi par 50 modules dont la moitié sont legacy.
**Faire la migration en prod direct.** Sans staging, sans tests, sans rollback plan. C'est la garantie d'un drama. Toute migration sérieuse passe par staging avec validation exhaustive.
**Sous-estimer la formation utilisateurs.** L'admin PS8 est différent de PS 1.7 — workflows changés, écrans réorganisés, certaines fonctions déplacées. Les équipes opérationnelles (gestion commandes, support client) doivent être formées avant la bascule, pas découvrir l'admin nouveau le matin du go-live.
## Conclusion : un projet structurant qui modernise votre business e-commerce
La migration PrestaShop 1.7 → 8 n'est pas une simple update technique — c'est un projet qui mérite un sponsoring direction, un budget calibré, et un planning rigoureux. Les boutiques qui prennent le sujet au sérieux sortent de la migration avec une boutique moderne, sécurisée, performante, et alignée sur les standards e-commerce 2026. Les boutiques qui le bâclent y perdent du trafic SEO, du chiffre d'affaires pendant des semaines, et accumulent une dette technique qu'il faudra payer plus tard.
L'investissement type pour une migration sérieuse est de 5 000 à 25 000 € selon la taille (PME : 8-15 K€, e-commerce mature : 15-25 K€), plus le coût des nouveaux modules de remplacement (généralement 500-2 000 € selon le stack choisi). Le retour sur investissement est mesurable en 6-12 mois post-migration via la modernisation des leviers de conversion et la libération du potentiel SEO bloqué par les limitations 1.7.
Pour creuser les sujets connexes, parcourez nos catégories [Performance & Core Web Vitals](/category/performance-core-web-vitals/) et [Tutoriels PrestaShop](/category/tutoriels-prestashop/). Et pour assembler le stack moderne PrestaShop 8 post-migration (cross-sell, avis vérifiés, FAQ IA, sidecart, wishlist, free shipping, multi-pays, AEO), l'ensemble du [catalogue DataFirefly](https://www.datafirefly.com/shop/) est aligné sur les patterns 2026 — performance-first, code propre, support francophone, mises à jour régulières.
À lire aussi : [PrestaShop 9 vs PrestaShop 8](https://www.datafirefly.com/2026/05/01/prestashop-9-vs-prestashop-8-changements/) et [la migration Shopware 6.6 vers 6.7](https://www.datafirefly.com/2026/06/06/migration-shopware-6-6-vers-6-7-checklist-pieges-2026/).
Pour passer à l'action : [notre sélection de modules pour migrer vers PrestaShop](https://www.datafirefly.com/solutions/prestashop/migration-prestashop/).
---
### Topic clusters et autorité thématique : structurer son catalogue pour le SEO sémantique
_Source :_ — _publié_ 2026-06-09
> Google ne classe plus des pages isolées mais des entités thématiques. Pages piliers, clusters, cannibalisation, contenu pauvre : voici la méthode pour structurer un catalogue e-commerce afin de construire une vraie autorité sémantique en 2026.
Le SEO de 2026 n'a plus grand-chose à voir avec le placement de mots-clés. Google — et les moteurs de réponse comme ChatGPT ou Perplexity — ne classent plus des pages isolées mais des **entités thématiques** : un site reconnu comme une autorité sur un sujet voit l'ensemble de ses pages mieux positionnées. La question n'est donc plus « cette page est-elle optimisée ? » mais « mon catalogue couvre-t-il un sujet de façon cohérente et structurée ? ».
La réponse tient en une méthode : les topic clusters. Voici comment structurer un catalogue e-commerce pour construire une vraie autorité sémantique.
## Le modèle pilier / cluster expliqué simplement
Un **topic cluster** est un ensemble de pages reliées autour d'un sujet : une _pillar page_ (page pilier) qui traite le sujet en largeur, et des pages satellites (catégories, sous-catégories, fiches, articles de blog) qui traitent chaque sous-thème en profondeur, toutes reliées par un maillage interne cohérent. Google lit cette structure comme un signal d'expertise. Une boutique de café avec une page pilier « guide du café en grains » reliée à ses catégories par origine, par intensité et à des articles sur la mouture sera vue comme plus experte qu'un catalogue à plat.
## Étape 1 — Cartographier ce que vous couvrez déjà
Avant d'ajouter du contenu, il faut voir la structure actuelle : quels clusters existent, lesquels sont incomplets, où manquent les pages piliers. Le faire à l'œil sur un gros catalogue est impossible. cartographie automatiquement la sémantique du catalogue et identifie les pages piliers manquantes.
## Étape 2 — Détecter ce qui dilue votre autorité
Deux problèmes silencieux sabotent l'autorité thématique :
- **La cannibalisation** : plusieurs pages visent le même mot-clé et se font concurrence dans la SERP, divisant le signal. croise les données Search Console pour les repérer et les résoudre (fusion, désindexation, repositionnement).
- **Le thin content** : des pages trop pauvres qui tirent vers le bas la qualité perçue du domaine. identifie ces pages faibles pour les enrichir ou les supprimer.
## Étape 3 — Mesurer la cohérence sémantique
Au-delà des pages individuelles, c'est la cohérence d'ensemble qui compte. mesure quels contenus se rapprochent ou s'éloignent thématiquement, et révèle les pages qui diluent votre autorité sur un sujet. C'est l'outil qui transforme l'intuition « notre SEO part dans tous les sens » en diagnostic actionnable.
## Étape 4 — Anticiper et industrialiser
Une fois la structure assainie, deux leviers prennent le relais : pour prioriser les clusters à fort potentiel saisonnier, et une suite SEO complète comme pour gérer balises, données structurées et signaux techniques à l'échelle du catalogue.
## Le lien avec l'AEO
Cette structuration sémantique ne sert pas que Google. Les moteurs de réponse citent en priorité les sources qu'ils identifient comme expertes d'un sujet — exactement ce que construit un bon topic cluster. C'est le prolongement naturel de : la même structure thématique nourrit à la fois le ranking classique et les citations IA.
## Conclusion : structurer avant de produire
Ajouter du contenu sans structure ne construit pas d'autorité — ça ajoute du bruit. La séquence gagnante : cartographier les clusters, supprimer la cannibalisation et le thin content, mesurer la cohérence, puis produire là où ça compte. Pour aller plus loin, explorez nos guides
À lire aussi : [le guide complet du SEO e-commerce](https://www.datafirefly.com/2026/05/01/seo-ecommerce-guide-complet-2026/), [comprendre l'AEO](https://www.datafirefly.com/2026/05/01/aeo-answer-engine-optimization-avenir-seo/) et [l'AEO appliqué à PrestaShop 8](https://www.datafirefly.com/2026/05/21/aeo-2026-optimiser-prestashop-8-chatgpt-perplexity-google-ai-overviews/).
Pour passer à l'action : [notre sélection de modules pour produire du contenu SEO à l'échelle](https://www.datafirefly.com/solutions/prestashop/contenu-seo-ia/).
---
### Psychologie de l'urgence : vente flash, compteurs et preuve sociale qui convertissent
_Source :_ — _publié_ 2026-06-08
> L'urgence et la preuve sociale sont les leviers de conversion les plus puissants — et les plus mal utilisés. Pourquoi ils marchent, quand ils se retournent contre vous, et comment les implémenter sans détruire la confiance.
L'urgence et la preuve sociale sont, données à l'appui, parmi les leviers de conversion les plus puissants du e-commerce. Ce sont aussi les plus mal utilisés : compteurs qui se réinitialisent à chaque visite, « plus que 2 en stock » permanents, fausses ventes flash. Mal employés, ils ne font pas qu'être inefficaces — ils détruisent la confiance et peuvent valoir des sanctions au titre des pratiques commerciales trompeuses.
Cet article explique pourquoi ces leviers fonctionnent psychologiquement, quand ils se retournent contre vous, et comment les implémenter honnêtement.
## Pourquoi l'urgence fonctionne : aversion à la perte
Le cerveau humain pèse plus lourdement une perte potentielle qu'un gain équivalent — c'est l'aversion à la perte, documentée par Kahneman et Tversky. « Cette offre se termine dans 3 heures » active la peur de rater (FOMO) plus fortement que « profitez de cette offre » n'active le désir. L'urgence transforme une intention vague (« j'achèterai peut-être ») en décision immédiate. C'est pourquoi une vraie vente flash avec surperforme une promo sans échéance : la date butoir crée la décision.
## Pourquoi la preuve sociale fonctionne : la validation par le nombre
Face à l'incertitude, on regarde ce que font les autres. « 47 personnes regardent ce produit », « 312 vendus ce mois-ci » : ces signaux réduisent le risque perçu et valident le choix. La preuve sociale est particulièrement efficace sur les produits où l'acheteur hésite sur la qualité ou la fiabilité. (vues en direct, ventes récentes, stock) restituent ces signaux sur la fiche produit.
## La ligne rouge : l'honnêteté
C'est là que la majorité des boutiques se trompent. Les règles non négociables en 2026 :
- Un compte à rebours doit correspondre à une **vraie** échéance. Un compteur qui se relance à chaque visite est trompeur — et la directive Omnibus sanctionne les fausses réductions et fausses urgences.
- Un « plus que X en stock » doit refléter le stock réel, pas un chiffre cosmétique fixe.
- Les compteurs de preuve sociale doivent s'appuyer sur des données réelles (vraies vues, vraies ventes), pas sur des nombres aléatoires.
La raison n'est pas que légale : un visiteur qui repère une fausse urgence perd confiance dans toute la boutique. Le gain de conversion à court terme se paie en taux de retour et en réputation.
## L'urgence couplée à l'offre
L'urgence est encore plus efficace adossée à une offre construite. Une vente flash sur un pack ou une offre groupée combine deux leviers : la valeur perçue de l'offre et la pression temporelle. C'est la logique des , qui gagnent à être animées par une échéance.
## Mesurer plutôt que croire
Comme tout levier de conversion, l'urgence et la preuve sociale se valident en A/B test, pas à l'intuition. Sur certains segments (achat réfléchi, B2B technique), l'urgence agressive peut même réduire la conversion en signalant une pression mal venue. La règle : tester par catégorie de produit et garder ce qui marche réellement.
## Conclusion : des leviers puissants à manier avec intégrité
L'urgence et la preuve sociale convertissent parce qu'elles parlent à des mécanismes cognitifs réels. Leur efficacité durable dépend entièrement de leur honnêteté : vraie échéance, vrai stock, vrais chiffres. Bien utilisés, ils augmentent la conversion sans entamer la confiance. Pour d'autres leviers de CRO, parcourez la catégorie
Pour passer à l'action : [notre sélection de modules pour créer une urgence crédible](https://www.datafirefly.com/solutions/prestashop/urgence-rarete/) et [celle pour la preuve sociale](https://www.datafirefly.com/solutions/prestashop/preuves-sociales/).
---
### Indexation 2026 : Google Indexing API, IndexNow et reprise de contrôle sur les bots IA
_Source :_ — _publié_ 2026-06-07
> Attendre que Googlebot passe est un luxe qu'on ne peut plus se permettre. Indexing API, IndexNow, gestion du crawl des bots IA : voici comment reprendre le contrôle de l'indexation et du crawl de votre boutique en 2026.
Pendant des années, l'indexation était passive : on publiait, on soumettait un sitemap, et on attendait que Googlebot finisse par passer. En 2026, attendre est un luxe. Les catalogues changent vite (prix, stock, nouveautés), la concurrence se réindexe en continu, et une nouvelle population de robots — les crawlers IA — consomme votre bande passante sans toujours vous apporter de trafic. Reprendre le contrôle de l'indexation et du crawl est devenu un chantier SEO technique à part entière.
## Pousser plutôt qu'attendre : les API d'indexation
Au lieu d'attendre le passage du crawler, on peut _notifier_ les moteurs dès qu'une page change. Deux protocoles le permettent :
- **Google Indexing API** : soumission directe à Google des URLs créées ou modifiées.
- **IndexNow** : un protocole ouvert qui notifie en une fois Bing, Yandex, Naver et les moteurs partenaires.
Pour une boutique, l'intérêt est direct : un produit remis en stock, un prix mis à jour ou une nouvelle fiche est connu des moteurs en minutes, pas en jours. automatise ces soumissions pour les produits, catégories et pages CMS de PrestaShop.
## Le nouveau venu : le crawl des bots IA
GPTBot, ClaudeBot, PerplexityBot, CCBot et consorts parcourent désormais le web pour entraîner ou alimenter des modèles. Le problème : ils peuvent représenter une part significative du crawl, consommer des ressources serveur, et scraper votre contenu sans contrepartie. Mais les bloquer aveuglément peut aussi vous priver de citations dans les moteurs de réponse — un canal de visibilité émergent. La bonne approche est le contrôle granulaire : autoriser ce qui vous apporte de la visibilité, limiter ce qui ne fait que consommer. permet ce pilotage fin sur PrestaShop.
## Mesurer ce qui se passe réellement : la Search Console
On ne pilote bien que ce qu'on mesure. Les rapports de couverture et de performance de la Search Console disent quelles pages sont indexées, lesquelles sont exclues et pourquoi. Y accéder sans quitter le back-office change la fréquence à laquelle on agit. ramène ces données directement dans PrestaShop, au plus près des fiches concernées.
## Le crawl budget : ne pas gaspiller le passage des robots
Indexer vite ne sert à rien si les robots gaspillent leur budget de crawl sur des URLs inutiles. Les pages à facettes mal gérées sont le coupable n°1 : des milliers d'URLs filtrées non canoniques qui diluent le crawl. Un moteur de facettes propre, traité dans et porté par des landing pages indexables, concentre le crawl sur ce qui compte.
## Et la mesure côté analytics
L'indexation alimente le trafic, mais encore faut-il l'attribuer correctement. Un suivi propre via Google Tag Manager — idéalement en server-side pour résister aux bloqueurs — referme la boucle entre indexation, trafic et conversion. C'est le rôle d' côté WooCommerce.
## Conclusion : l'indexation est devenue active
En 2026, l'indexation se pilote : on pousse les changements via Indexing API et IndexNow, on contrôle le crawl des bots IA, on mesure dans la Search Console, et on protège le crawl budget. C'est un avantage concurrentiel concret pour qui s'en empare. Pour approfondir, parcourez nos guides
À lire aussi : [le guide complet du SEO e-commerce](https://www.datafirefly.com/2026/05/01/seo-ecommerce-guide-complet-2026/) et [redirections 301 et monitoring 404](https://www.datafirefly.com/2026/07/04/redirections-301-monitoring-404-changement-slug-seo-prestashop-2026/).
Pour passer à l'action : [notre sélection de modules pour auditer et piloter votre SEO](https://www.datafirefly.com/solutions/prestashop/pilotage-seo/).
---
### Migration Shopware 6.6 → 6.7 : checklist complète et pièges de mise à jour en 2026
_Source :_ — _publié_ 2026-06-06
> Retour d'expérience sur la migration Shopware 6.6 → 6.7 : breaking changes API Payment, refonte admin Vue 3 + composants mt-*, Vite manifest, OpenSearch 2.19. Checklist en 8 étapes et les pièges silencieux qu'on a rencontrés en vrai sur plusieurs boutiques.
Shopware 6.7 est sortie fin 2024 avec ce que la documentation officielle qualifie de « major release with multiple breaking changes ». Pour les boutiques en 6.6, la migration est obligatoire à terme — Shopware ne maintient en parallèle que la dernière version stable et la version précédente, donc rester sur 6.5 ou 6.6 trop longtemps coupe l'accès aux correctifs de sécurité. Pour les plugins développés en 6.6, plusieurs API critiques ont changé de signature ou ont été supprimées entre 6.6 et 6.7.
Cet article est un retour d'expérience direct sur la migration 6.6 → 6.7 que nous avons menée sur plusieurs boutiques en 2025-2026, avec les vrais pièges techniques qu'on a rencontrés et les patches que nous avons dû produire pour adapter nos plugins propres et tiers. L'objectif : éviter à d'autres équipes le mois de debugging que nous avons passé sur certaines régressions silencieuses.
## Ce qui change vraiment dans Shopware 6.7
Au-delà du marketing release, voici les changements 6.7 qui ont un impact concret sur les plugins existants.
**Refonte de l'API Payment Handler.** L'interface `AsynchronousPaymentHandlerInterface` est supprimée en 6.7. Tout plugin de paiement qui implémentait cette interface en 6.6 doit migrer vers `AbstractPaymentHandler`. Les méthodes `pay()` et `finalize()` ont une signature différente : la struct `AsyncPaymentTransactionStruct` est remplacée par `PaymentTransactionStruct`, plus minimaliste et orientée DDD.
**Tags de service modifiés.** Le tag `shopware.payment.method.async` qui distinguait les payments synchrones et asynchrones est supprimé au profit d'un tag unifié `shopware.payment.method`. Si vos services.xml utilisaient l'ancien tag, le payment handler ne se déclare plus correctement et le mode de paiement disparaît du checkout sans erreur visible.
**Migration admin Vue 2 → Vue 3.** L'admin Shopware 6.7 est portée sur Vue 3 (alors que 6.6 était sur Vue 2 avec compat layer). Les composants `sw-*` (legacy) sont en cours de remplacement par les composants `mt-*` (Meteor design system). Beaucoup de composants `sw-*` sont marqués deprecated et seront supprimés dans une release 6.x ultérieure. Les plugins admin qui utilisaient les composants sw-* doivent migrer.
**Système de traduction admin modifié.** Les méthodes `$tc()` (translation choice, gestion du pluriel) ont été remplacées par `$t()` avec gestion native du pluriel. Vos templates admin qui faisaient `{{ $tc('mon.plugin.label') }}` doivent passer à `{{ $t('mon.plugin.label') }}`.
**Build admin via Vite.** L'admin compile désormais via Vite avec un `manifest.json` structuré différemment de la 6.6. Les plugins qui injectaient leur JS admin via le mécanisme historique doivent adapter leur build pipeline pour générer le bon manifest, sinon l'admin charge un JS vide au lieu de votre code.
**Storefront : Bootstrap 5.3 généralisé.** Le passage à Bootstrap 5.3 dans le storefront active le support natif de `data-bs-theme`, ce qui simplifie les implémentations de mode sombre — sujet de notre [plugin DataFirefly Dark Mode](/product/datafirefly-dark-mode-shopware-6/) qui exploite cette convention. Les thèmes custom basés sur Bootstrap 5.2 ou antérieur peuvent avoir des variables SCSS qui ne mappent plus.
**Compatibilité PHP et MySQL.** 6.7 demande PHP 8.2+ (PHP 8.1 sorti, PHP 8.3 recommandé) et MySQL 8.0+ ou MariaDB 11.4 LTS. Les hébergements encore en MySQL 5.7 ou MariaDB 10.x doivent migrer leur DB avant l'upgrade applicatif.
## Les breaking changes plugin par plugin que nous avons rencontrés
Sur les boutiques que nous avons migrées, voici les bugs concrets découverts à l'upgrade 6.6 → 6.7.
**MoptWorldline (paiement Worldline / SaferPay).** Le plugin de paiement Worldline en version 6.6 implémentait `AsynchronousPaymentHandlerInterface`. Au passage 6.7, le plugin ne charge plus correctement, et les méthodes de paiement Worldline disparaissent du checkout. Le patch demande de migrer vers `AbstractPaymentHandler` et de réécrire les méthodes `pay()` et `finalize()` avec la nouvelle signature `PaymentTransactionStruct`. Travail estimé : 2-4 jours pour un dev Shopware expérimenté.
**Plugins admin custom avec composants sw-*.** Sur nos plugins MySmartBook et autres, plusieurs composants admin custom utilisaient `sw-card`, `sw-button`, `sw-text-field`, etc. En 6.7, ces composants existent encore mais sont marqués deprecated. Les composants `mt-card`, `mt-button`, `mt-text-field` les remplacent. La migration est mécanique mais demande une revue exhaustive de tous les fichiers admin.
**Snippets et traductions.** Les fichiers de snippets en 6.6 utilisaient parfois la structure pluralisée que `$tc()` consommait. En 6.7 avec `$t()`, certaines structures de snippets ne marchent plus identiquement. À tester systématiquement, surtout sur les snippets avec compteurs (« 1 produit » / « N produits »).
**Custom field customer et synchronisation.** Notre [plugin Dark Mode pour Shopware](/product/datafirefly-dark-mode-shopware-6/) stocke la préférence utilisateur dans un custom field `df_dark_mode_preference` sur l'entité customer. La migration 6.7 a conservé la compatibilité custom fields, mais l'API de synchronisation a une signature légèrement différente. À tester systématiquement après upgrade.
**OpenSearch 2.19+ obligatoire.** Si votre boutique utilise la recherche fulltext avec OpenSearch (ex-Elasticsearch dans les versions Shopware antérieures), 6.7 demande OpenSearch 2.19 minimum. Les versions OpenSearch 1.x ne sont plus supportées. Migration cluster OpenSearch à prévoir avant l'upgrade applicatif.
## La checklist de migration en 8 étapes
Pour une migration 6.6 → 6.7 maîtrisée, voici l'ordre que nous suivons en interne.
**Étape 1 — Audit des plugins installés.** Listez tous les plugins activés sur votre boutique. Pour chacun, vérifiez sur le store ou sur GitHub si une version compatible 6.7 existe. Les plugins non-mis à jour sont des risques majeurs : à désactiver temporairement, ou à patcher en interne, ou à remplacer.
**Étape 2 — Audit du thème custom.** Si vous utilisez un thème custom (et non le thème Storefront natif), vérifiez la compatibilité avec Bootstrap 5.3, les changements de structure base layout, et le système Vite admin si votre thème injecte du JS admin custom.
**Étape 3 — Mise à jour environnement infrastructure.** PHP 8.2+, MySQL 8 ou MariaDB 11.4 LTS, OpenSearch 2.19+ si utilisé, Node.js récent (18+ ou 20 LTS). À faire avant l'upgrade applicatif Shopware.
**Étape 4 — Backup complet.** Base de données + dossier files + fichiers `config/`. C'est l'étape qu'on a tendance à négliger jusqu'au moment où l'upgrade casse irrémédiablement quelque chose. À faire systématiquement avant tout changement.
**Étape 5 — Migration sur environnement de staging.** Cloner la prod sur un staging identique, faire l'upgrade 6.7 sur le staging, valider exhaustivement avant de toucher la prod. Ce n'est pas une option — sur les boutiques que nous avons migrées, 30 % ont eu des bugs critiques découverts uniquement en staging.
**Étape 6 — Upgrade applicatif Shopware.** Via le SUM (Shopware Update Manager) en CLI : `bin/console system:update:prepare`, puis `bin/console system:update:finish`. Bien lire la documentation officielle pour les options (skip-asset-build, etc.). Compter 30 min à 2 h selon la taille de la base.
**Étape 7 — Recompilation thème et admin.** Après l'upgrade core, recompiler le thème (`bin/console theme:compile`) et rebuild l'admin (`bin/build-administration.sh`). Sur Shopware 6.7, l'admin se compile via Vite ; la commande historique theme:compile ne suffit plus pour l'admin.
**Étape 8 — Test exhaustif post-upgrade.** Parcours complet : navigation catalogue, fiche produit, ajout panier, checkout, paiement (chaque méthode de paiement testée individuellement), espace client, admin (chaque module installé). Sur les boutiques B2B, tester aussi devis, comptes hiérarchiques, prix par client.
## Les pièges silencieux qu'on a rencontrés en vrai
Au-delà des breaking changes documentés, voici les bugs subtils qui ne se voient pas immédiatement après l'upgrade.
**Le payment handler qui ne déclare plus.** Comme mentionné plus haut, un plugin de paiement avec ancien tag `shopware.payment.method.async` ne s'enregistre plus en 6.7. Le mode de paiement disparaît du checkout, mais aucune erreur n'est levée — le payment_method_id correspondant existe toujours en base, simplement le handler n'est plus instancié. Symptôme côté client : la méthode est affichée à l'admin (configuration / sales channels / payment methods) mais n'apparaît pas au checkout.
**Le composant admin custom qui rend vide.** Un composant qui utilisait `$tc()` sans aucune translation associée (cas des labels hardcodés) ne rend plus rien en 6.7. Pas d'erreur dans la console, simplement un placeholder vide. À détecter par revue manuelle des écrans admin custom après upgrade.
**Le manifest Vite qui ne se génère pas.** Si votre plugin admin custom était buildé avec un script personnalisé en 6.6 (webpack ou rollup direct), ce build peut ne pas générer le manifest.json attendu par Shopware 6.7. Symptôme : l'admin charge mais votre JS plugin n'est pas exécuté. Solution : adapter le build pour exporter un manifest compatible Vite.
**Les snippets pluralisés qui ne se traduisent plus.** Si vous aviez des snippets avec structure `{count} | une chose | {count} choses` consommés par `$tc()`, le passage à `$t()` demande une syntaxe différente. Les snippets non-migrés affichent la chaîne template brute au lieu de la traduction.
**Le custom field qui n'existe plus en API.** Quelques modifications de l'API DAL (Data Abstraction Layer) en 6.7 ont changé la sérialisation de certains custom fields complexes (multi-select, JSON). Les valeurs en base existent toujours, mais sont lues différemment. À tester sur les custom fields critiques.
## Conclusion : une migration nécessaire mais à anticiper
La migration Shopware 6.6 → 6.7 n'est pas une simple update mineure. Elle introduit des breaking changes significatifs qui demandent un travail réel sur les plugins (paiement notamment), l'admin custom, et l'infrastructure. Les boutiques qui font cette migration en 1 journée « parce qu'on a juste cliqué sur Update » découvrent les bugs en production des semaines plus tard, parfois avec impact direct sur le CA (paiement cassé, admin inutilisable).
L'investissement temps réaliste pour une boutique avec 5-10 plugins tiers et un thème custom est de 5 à 15 jours-homme pour un développeur Shopware expérimenté, plus quelques jours de recette. Anticiper le sujet, faire l'upgrade en staging, tester exhaustivement avant la prod, c'est ce qui distingue une migration maîtrisée d'une migration en crise.
Pour les sujets techniques connexes, parcourez nos catégories [Actualités e-commerce](/category/actualites-ecommerce/) et [Performance & Core Web Vitals](/category/performance-core-web-vitals/). Et si vous cherchez des plugins Shopware 6.7 français, performance-first et bien maintenus, notre [plugin Dark Mode](/product/datafirefly-dark-mode-shopware-6/) est compatible Shopware 6.7 dès la sortie et illustre les patterns techniques alignés sur la nouvelle architecture (anti-FOUC, custom field customer, événements JS pour synchronisation tierce).
À lire aussi : [la checklist migration PrestaShop 1.7 vers 8](https://www.datafirefly.com/2026/06/10/migration-prestashop-1-7-vers-8-checklist-2026/) et [PrestaShop 9 vs PrestaShop 8](https://www.datafirefly.com/2026/05/01/prestashop-9-vs-prestashop-8-changements/).
---
### Réduire les frictions au login : SSO social, 2FA et navigation qui retient
_Source :_ — _publié_ 2026-06-05
> Chaque friction entre le visiteur et son achat coûte des conversions. Connexion sociale, double authentification bien dosée et navigation claire : comment fluidifier le parcours sans sacrifier la sécurité ni la confiance.
Le tunnel de conversion se joue autant sur ce qu'on ajoute que sur ce qu'on retire. Chaque friction entre le visiteur et son achat — un compte à créer, un mot de passe à retrouver, un menu confus — coûte des conversions. Paradoxalement, certains marchands ajoutent de la friction au nom de la sécurité, et d'autres la suppriment au point de fragiliser les comptes. Le bon équilibre se construit sur trois leviers : la connexion, la sécurité dosée, et la navigation.
## La création de compte : le premier point d'abandon
Demander la création d'un compte avant l'achat est l'une des premières causes d'abandon. Deux réponses complémentaires : autoriser la commande invité, et proposer la connexion sociale. Le SSO social (Google, Apple, Facebook) supprime le formulaire : un clic, et le visiteur est identifié. ajoute ces boutons à PrestaShop, avec en prime un tableau de bord analytique pour voir quels fournisseurs sont réellement utilisés.
## La sécurité, mais au bon endroit
Réduire la friction ne veut pas dire baisser la garde. Les comptes clients contiennent des données personnelles et des moyens de paiement enregistrés ; un compte administrateur compromis, c'est toute la boutique en danger. La double authentification (2FA) est la protection la plus rentable — mais elle doit être **dosée** : indispensable côté back-office et pour les comptes sensibles, optionnelle et non intrusive côté client. permet ce réglage fin sur WordPress et WooCommerce. L'idée n'est pas de mettre de la friction partout, mais là où le risque le justifie.
## La navigation : la friction invisible
On pense rarement au menu comme à une source de friction, et c'est une erreur. Un visiteur qui ne trouve pas vite la bonne catégorie repart. Un méga-menu clair — colonnes, images, blocs mis en avant — guide le visiteur vers le produit en réduisant le nombre de clics et la charge cognitive. (avec versions burger mobile et menu déroulant) structure cette navigation sans toucher au code.
## L'ordre des produits : le merchandising silencieux
Une fois dans la bonne catégorie, l'ordre d'affichage des produits oriente l'achat. Laisser PrestaShop ou WooCommerce trier par défaut, c'est laisser le hasard décider de ce que le visiteur voit en premier. Pouvoir réordonner les produits par glisser-déposer — mettre en avant les best-sellers, les nouveautés, les produits à forte marge — est un levier de conversion sous-estimé. le permet côté WooCommerce, globalement ou par catégorie.
## Mesurer la friction
Chaque levier se valide sur la donnée : taux d'utilisation de la connexion sociale, taux d'abandon au login, profondeur de navigation, taux de clic sur le menu. Comme pour tout sujet de conversion, l'A/B test tranche mieux que l'intuition — un méga-menu trop riche peut noyer le visiteur, une 2FA mal placée peut faire fuir. Le but est un parcours fluide _et_ sûr, pas l'un au détriment de l'autre.
## Conclusion : fluidité et sécurité ne s'opposent pas
Réduire les frictions, ce n'est pas tout enlever : c'est retirer ce qui freine inutilement (compte obligatoire, navigation confuse) et renforcer ce qui protège vraiment (2FA ciblée). Connexion sociale, sécurité dosée, navigation claire et merchandising maîtrisé composent un parcours qui convertit sans trahir la confiance. Pour d'autres leviers, explorez la catégorie
Pour passer à l'action : [notre sélection de modules pour sécuriser votre boutique](https://www.datafirefly.com/solutions/prestashop/securite-protection/).
---
### GPSR 2026 : la checklist de conformité produit pour votre boutique PrestaShop
_Source :_ — _publié_ 2026-06-04
> Le GPSR s'applique à toute boutique vendant des produits physiques dans l'UE. En 2026, places de marché et autorités le vérifient activement. Voici la checklist concrète pour rendre vos fiches produit PrestaShop conformes sans y passer des semaines.
Depuis le 13 décembre 2024, le Règlement (UE) 2023/988 relatif à la sécurité générale des produits — le GPSR — s'applique à toute boutique qui vend des produits physiques à des consommateurs de l'Union européenne. En 2026, ce n'est plus une nouveauté qu'on peut repousser : c'est un point de contrôle que les places de marché, les transporteurs et les autorités de surveillance vérifient activement. Une fiche produit non conforme peut être déréférencée, et le marchand engage sa responsabilité.
Le piège, pour la plupart des marchands PrestaShop, c'est de croire que le GPSR se résume à une mention en pied de page. Il impose en réalité des informations précises sur _chaque_ fiche produit, un responsable établi dans l'UE et une traçabilité. Voici la checklist concrète pour être conforme sans y passer des semaines.
## Ce que le GPSR exige réellement sur une fiche produit
Le règlement impose que le consommateur puisse identifier, avant l'achat, qui fabrique le produit et qui en est responsable dans l'UE. Concrètement, chaque fiche doit afficher :
- L'identité et l'adresse postale du fabricant (raison sociale + adresse complète).
- Le nom et les coordonnées du responsable établi dans l'UE lorsque le fabricant est hors UE.
- Un élément d'identification du produit : référence, modèle, numéro de type ou de lot.
- Les avertissements de sécurité et instructions, dans la langue du pays de vente.
- Le cas échéant, les pictogrammes réglementaires (âge minimum, risque d'étouffement, etc.).
Le point clé : ces informations doivent être visibles **sur la fiche en ligne**, pas seulement sur l'emballage physique. Une boutique qui ne les affiche pas est non conforme, même si le produit lui-même est sûr.
## Le responsable UE : le point que tout le monde oublie
C'est l'angle mort le plus fréquent. Si vous revendez des produits fabriqués hors UE (Chine, UK post-Brexit, USA…), il doit exister une « personne responsable » établie dans l'UE — fabricant, importateur, mandataire ou fournisseur de services d'exécution des commandes. Son nom et ses coordonnées doivent figurer sur la fiche. Sans responsable UE identifié, le produit ne peut légalement pas être mis sur le marché. Pour un catalogue de plusieurs centaines de références importées, renseigner ce champ manuellement produit par produit est ingérable : il faut un système qui le gère par fabricant ou par fournisseur.
## Avertissements, pictogrammes et langue de vente
Les avertissements doivent être compréhensibles par le consommateur, donc traduits dans la langue de chaque marché. Sur une boutique multilingue (Polylang ou multiboutique PrestaShop), cela signifie gérer les mentions GPSR par langue, pas une seule version française recopiée partout. Les pictogrammes (jouets, produits chimiques, électroniques) doivent être associés aux bonnes catégories de produits, idéalement par règle automatique plutôt qu'à la main.
## GPSR, accessibilité et conformité : le même chantier réglementaire
Le GPSR ne tombe pas seul en 2026. Il s'inscrit dans une vague réglementaire qui touche aussi l'accessibilité (l'European Accessibility Act, que vous pouvez traiter avec ) et la protection des données. Le réflexe gagnant est de traiter ces obligations comme un seul chantier de conformité plutôt que comme des urgences séparées. Si le sujet RGPD vous concerne, notre dossier sur complète utilement cette checklist, tout comme notre guide sur .
## Automatiser la conformité GPSR sur PrestaShop
Renseigner manuellement fabricant, responsable UE, identifiants et avertissements sur chaque fiche d'un gros catalogue est à la fois chronophage et source d'oublis. C'est précisément le rôle d' : définir le fabricant et le responsable UE au niveau global ou par fabricant/fournisseur, propager les avertissements et pictogrammes par catégorie, et afficher automatiquement le bloc conforme sur chaque fiche, dans la bonne langue.
## Conclusion : la conformité GPSR est un acquis, pas un projet ponctuel
Le GPSR n'est pas une case à cocher une fois pour toutes : tout nouveau produit ajouté au catalogue doit naître conforme. L'enjeu n'est donc pas de « mettre à jour » une fois 300 fiches, mais d'industrialiser l'affichage des informations obligatoires pour que la conformité soit automatique et durable. Pour approfondir les autres sujets réglementaires et techniques côté PrestaShop, parcourez nos
À lire aussi : [l'accessibilité WCAG 2.2 et l'EAA](https://www.datafirefly.com/2026/07/16/accessibilite-wcag-2-2-european-accessibility-act-prestashop-2026/), [la directive Omnibus et le prix de référence](https://www.datafirefly.com/2026/06/22/directive-omnibus-prix-reference-promotions-prestashop-2026/) et [la vérification d'âge (CBD, vape, alcool)](https://www.datafirefly.com/2026/06/18/verification-age-ecommerce-cbd-vape-alcool-conformite-prestashop-2026/).
Pour passer à l'action : [notre sélection de modules de conformité produit](https://www.datafirefly.com/solutions/prestashop/conformite-produits/).
---
### Vidéos produit : quand elles convertissent vraiment et quand elles plombent les Core Web Vitals
_Source :_ — _publié_ 2026-06-02
> « La vidéo produit booste la conversion de 30 à 80 %. » Vrai sur certains produits, faux sur d'autres. Et techniquement, une vidéo mal implémentée plombe vos Core Web Vitals. Voici quand investir dans la vidéo produit et comment l'implémenter sans dégrader vos CWV.
« La vidéo produit booste la conversion de 30 à 80 %. » Cette statistique tourne en boucle depuis 2018 dans les contenus marketing e-commerce. Elle est vraie sur certains produits, sur certaines audiences, dans certains contextes — et elle est complètement fausse sur d'autres. Plus problématique encore : intégrer une vidéo produit mal implémentée techniquement peut _dégrader_ votre taux de conversion en plombant les Core Web Vitals, particulièrement le LCP et l'INP qui sont devenus des facteurs de ranking Google directs depuis 2024.
Cet article tranche : quand la vidéo produit convertit vraiment, quand elle ne sert à rien voire fait du mal, et comment l'implémenter techniquement sur PrestaShop 8 sans dégrader vos Core Web Vitals.
## Quand la vidéo produit convertit réellement
La vidéo produit n'est pas un levier universel. Elle a un impact mesurable et significatif dans des cas précis.
**Produits où l'usage est non-évident.** Un objet dont la fonction n'est pas immédiatement claire à partir d'une image (gadget innovant, accessoire technique, électroménager polyvalent). La vidéo de 15-30 secondes qui montre l'objet en action résout l'ambiguïté et déclenche la décision d'achat. Sans vidéo, l'acheteur abandonne ou cherche une démo ailleurs.
**Produits où l'échelle / le contexte sont critiques.** Un canapé, une étagère, une plante : l'image fixe ne donne pas la sensation de la taille réelle, de la profondeur, du volume. Une vidéo qui filme l'objet dans un salon donne instantanément le bon référentiel. Les boutiques mobilier / déco voient typiquement +20 à +50 % de conversion sur les fiches avec vidéo.
**Produits où la matière compte.** Vêtements (drapé du tissu en mouvement), bijoux (reflets, finition), cosmétiques (texture, glissant). L'image fixe perd l'information dynamique ; la vidéo la restitue.
**Produits techniques avec démo.** Outils, machines, électronique. Une vidéo de 30-60 secondes qui montre l'utilisation réelle, le déballage, ou le fonctionnement convainc plus qu'une description textuelle de 500 mots.
## Quand la vidéo ne sert à rien (voire dégrade)
Inversement, plusieurs catégories de produits ne tirent aucun bénéfice mesurable de la vidéo, et y intégrer en force est une perte de temps et de budget.
**Produits standards bien connus.** Une référence connue (un livre, un jeu vidéo, un médicament en vente libre, une marque de café standard) n'a pas besoin de vidéo. L'acheteur sait déjà ce qu'il achète. La vidéo n'apporte aucune information nouvelle et peut être perçue comme du remplissage.
**Produits où le prix est le facteur décisif.** Sur les produits commodity à faible marge où l'arbitrage se fait sur le prix (consommables industriels, fournitures de bureau standard), la vidéo n'influence pas la décision. L'acheteur compare les prix entre 5 boutiques et choisit. Le temps passé sur la vidéo retarde la conversion sans la déclencher.
**Audiences impatientes.** Sur le segment B2B technique, l'acheteur sait ce qu'il cherche et veut valider rapidement (référence, prix, délai). Une vidéo qui force le clic « play » et impose 30 secondes d'attention est une friction, pas un atout.
**Produits dont le côté visuel est déjà parfait sur photo.** Bijoux haut de gamme avec photographie macro studio, vêtements avec lookbook professionnel, art. La vidéo dégradée par compression ne fait pas mieux que la photo soignée — elle peut même donner une impression de qualité moindre.
Avant d'investir dans la production de vidéos produit (qui coûte facilement 100-500 € par produit en production professionnelle, plus le temps interne), classez votre catalogue dans ces catégories. Si vos produits ne sont pas dans les catégories « vidéo utile », ne forcez pas le levier — investissez ailleurs.
## Le piège technique : la vidéo qui plombe les Core Web Vitals
Même sur un produit où la vidéo apporte une valeur réelle, une mauvaise implémentation technique peut annuler le bénéfice de conversion en dégradant les Core Web Vitals — qui ont eux-mêmes un impact direct sur le ranking SEO et la conversion mobile.
Trois mécanismes plombent typiquement les CWV.
**1. La vidéo qui charge en eager au LCP.** Si la vidéo est intégrée comme premier élément de la galerie produit avec autoplay et sans optimisation, elle peut déclencher le LCP (Largest Contentful Paint) de la page. Un fichier MP4 de quelques mégaoctets met 2-5 secondes à se charger sur 4G dégradée — votre LCP saute à 4-5 secondes au lieu de 1,8 secondes que vous aviez avant la vidéo. Google détecte la dégradation, baisse votre ranking sur les requêtes produit. Net effet : moins de visiteurs, peut-être plus de conversion par visiteur, mais total négatif.
**2. La vidéo qui consomme du JS au INP.** Les players vidéo modernes (vidéo HTML5 native, ou wrappers comme video.js, Plyr) chargent du JavaScript qui s'exécute au montage et freine les interactions ultérieures. Si votre INP (Interaction to Next Paint) passe de 180 ms (bon) à 320 ms (mauvais) à cause du player vidéo, vous perdez sur les Core Web Vitals.
**3. La vidéo qui décale le contenu (CLS).** Si l'espace de la vidéo n'est pas réservé en CSS avant son chargement (avec aspect-ratio ou width/height explicites), la vidéo qui arrive en différé pousse le contenu sous elle, déclenchant un Cumulative Layout Shift. Le CLS mauvais est l'une des dégradations CWV les plus pénalisantes côté SEO.
Sur les boutiques que nous auditons, un module vidéo produit mal implémenté dégrade typiquement le score Lighthouse de 10-20 points. Sur certaines boutiques, c'est suffisant pour faire passer le statut Search Console de « Bon » à « À améliorer » sur les CWV — avec impact direct sur le ranking.
## L'implémentation technique correcte sur PrestaShop 8
Une vidéo produit qui ne dégrade pas les CWV respecte cinq règles techniques.
**1. Hébergement optimisé.** Hébergez les vidéos sur un CDN spécialisé (Cloudflare Stream, Bunny.net, Vimeo Pro), pas sur votre serveur de boutique. Les CDN spécialisés font la transcodage adaptatif (HLS, DASH) qui ajuste la qualité au débit du visiteur, et servent les segments depuis des points de présence proches. Stockage local ou Vimeo gratuit = vidéo lente partout.
**2. Lazy load systématique.** La vidéo doit être chargée seulement quand elle entre dans le viewport (intersection observer ou attribut `loading="lazy"` selon support navigateur). Avant, c'est une miniature/poster image qui s'affiche, infiniment plus légère qu'une vidéo.
**3. Poster image hautement optimisée.** L'image poster (la frame qui s'affiche avant que le visiteur clique play) doit être en WebP ou AVIF, dimensionnée précisément à la zone d'affichage, et chargée en priorité high si elle est above the fold. C'est cette image qui sera votre LCP, pas la vidéo.
**4. Pas d'autoplay sauf cas spécifique.** L'autoplay des vidéos produit est généralement déconseillé en 2026 — les navigateurs bloquent l'autoplay avec son par défaut, et les visiteurs perçoivent l'autoplay forcé comme intrusif. Préférez un poster image accrocheuse + bouton play visible.
**5. Réservation d'espace CSS.** Le conteneur vidéo doit avoir un `aspect-ratio: 16/9` (ou la valeur correspondant à votre vidéo) en CSS, pour que l'espace soit réservé avant le chargement et qu'il n'y ait pas de CLS quand la vidéo arrive.
Sur PrestaShop 8, le module [Vidéo dans la galerie produit DataFirefly](/product/video-dans-la-galerie-produit-prestashop/) implémente ces cinq règles : intégration native dans la galerie produit (vidéo en première position si configurée), poster image automatique générée depuis la première frame, lazy load par intersection observer, support des hébergements externes (YouTube, Vimeo, MP4 self-hosted ou CDN), et CSS qui réserve l'espace pour zéro CLS. C'est la version « performance-first » qui ne dégrade pas vos Core Web Vitals.
## Comment mesurer si votre vidéo convertit vraiment
Une fois la vidéo en place, deux métriques à suivre pour valider qu'elle apporte de la valeur.
**Taux de lecture de la vidéo.** Combien de visiteurs cliquent réellement sur play ? Sur les boutiques que nous accompagnons, ce taux varie de 5 à 30 % selon la pertinence de la vidéo et son design (bouton play visible, miniature attractive). Sous 5 %, la vidéo est ignorée — autant l'enlever.
**Taux de conversion comparé.** Comparez le taux de conversion des fiches avec vidéo vs sans vidéo, à audience comparable. La vraie mesure est en A/B test (50 % des visiteurs voient la fiche avec vidéo, 50 % sans). Si la vidéo apporte +5 % de conversion sur la cohorte « avec », c'est rentable. Si elle apporte 0 % ou -1 %, c'est neutre ou négatif — la production / hébergement vidéo ne sont pas rentabilisés.
Sans cette mesure, vous investissez à l'aveugle dans des vidéos. Et le sujet des CWV reste critique : si votre vidéo apporte +5 % de conversion mais dégrade votre ranking SEO de 10 % sur les requêtes produit, le bilan net est négatif. La mesure doit être globale, pas seulement sur le funnel post-arrivée.
## Conclusion : la vidéo produit est un levier ciblé, pas universel
La vidéo produit n'est pas un levier de conversion universel. Elle marche très bien sur les produits où l'usage, l'échelle, la matière, ou la démo apportent une vraie information. Elle ne sert à rien (voire dégrade les CWV) sur les produits standard, commodity, ou déjà parfaitement vendus par photo.
Sur les produits où elle marche, l'implémentation technique est critique : hébergement CDN spécialisé, lazy load, poster image optimisée, réservation d'espace CSS. Sans ces cinq règles, votre vidéo plombe vos Core Web Vitals — sujet traité en profondeur dans notre article sur la [checklist Core Web Vitals 2026 sur PrestaShop 8](/2026/05/09/performance-prestashop-8-checklist-core-web-vitals-2026-lcp-inp-cls/). La conversion gagnée sur la fiche peut être annulée par le ranking perdu sur la SERP.
Pour creuser, parcourez nos catégories [Conversion & UX](/category/conversion-ux/) et [Performance & Core Web Vitals](/category/performance-core-web-vitals/). Et pour intégrer la vidéo dans la galerie produit PrestaShop 8 sans dégrader les CWV, le module [Vidéo Galerie DataFirefly](/product/video-dans-la-galerie-produit-prestashop/) implémente les cinq règles techniques par défaut, avec configuration en quelques clics.
À lire aussi : [le guide complet Core Web Vitals](https://www.datafirefly.com/2026/05/01/core-web-vitals-guide-prestashop-wordpress-2026/) et [cache, Critical CSS et images next-gen](https://www.datafirefly.com/2026/06/15/core-web-vitals-2026-optimiser-prestashop-cache-critical-css-images/).
Pour passer à l'action : [notre sélection de modules pour optimiser vos fiches produit](https://www.datafirefly.com/solutions/prestashop/fiche-produit/).
---
### Free shipping bar : la science derrière le seuil de livraison gratuite (avec calcul de marge réelle)
_Source :_ — _publié_ 2026-05-29
> La barre de livraison gratuite est un levier mathématique, pas marketing. Voici comment calculer le seuil optimal selon votre panier moyen, votre marge et votre coût de livraison, et pourquoi la barre de progression visuelle double l'efficacité du levier.
La barre de livraison gratuite est l'un des leviers de panier moyen les plus mal exploités sur les boutiques PrestaShop. La majorité des marchands l'activent avec un seuil arrondi (« 50 € » ou « 79 € ») qu'ils ont copié sur un concurrent ou pris au feeling, sans calcul. Le résultat est invariablement sous-optimal : soit le seuil est trop bas et vous perdez de la marge sur des paniers qui auraient payé la livraison sans broncher, soit il est trop haut et les visiteurs abandonnent au lieu d'ajouter.
Cet article détaille la science derrière le seuil de livraison gratuite : comment le calculer en fonction de votre panier moyen, votre marge, et votre coût de livraison réel ; comment il varie selon les pays de livraison ; et pourquoi la barre de progression visuelle (barre qui se remplit au fur et à mesure que le visiteur approche du seuil) double l'efficacité du levier vs un simple seuil annoncé.
## Pourquoi le seuil de livraison gratuite est un sujet stratégique
La livraison gratuite est l'un des trois facteurs les plus cités par les acheteurs e-commerce comme déterminants de la décision d'achat — au même niveau que le prix et la rapidité de livraison. Sur les études comportementales, environ 50 % des acheteurs déclarent avoir abandonné un panier au moins une fois à cause des frais de livraison non gratuits.
Mais offrir la livraison à tous les paniers est financièrement insoutenable dans la majorité des cas. Sur un panier moyen de 45 € avec une marge brute de 35 %, vous gagnez 15,75 € de marge. Une livraison qui vous coûte 6 € absorbe 38 % de votre marge sur cette commande. Multiplié par toutes les commandes, c'est insoutenable.
Le seuil de livraison gratuite résout cette équation : _au-delà_ d'un certain montant de panier, vous offrez la livraison parce que la marge additionnelle compense le coût. _En-deçà_, vous facturez. Le visiteur conscient du seuil est incité à augmenter son panier pour passer en livraison gratuite — gain panier moyen + perception positive (« j'ai eu la livraison offerte »).
Le sujet n'est donc pas « est-ce que j'offre la livraison » mais « à quel seuil je l'offre ».
## Le calcul du seuil optimal : la formule fondamentale
Le seuil optimal dépend de trois variables : votre **panier moyen actuel** (P), votre **marge brute moyenne** (M, en pourcentage), et votre **coût de livraison moyen** (C, en euros HT).
La formule de base est :
`Seuil_optimal = P × (1 + (C / (P × M)))`
Cette formule donne le seuil minimum auquel vous pouvez offrir la livraison sans dégrader votre marge unitaire actuelle.
Exemple concret : panier moyen 45 €, marge brute 35 %, coût livraison 6 €.
`Seuil = 45 × (1 + (6 / (45 × 0,35))) = 45 × (1 + 0,381) = 62,15 €`
Le seuil minimum mathématique est 62 €. À ce seuil, la marge gagnée sur les 17 € additionnels (62 - 45 = 17 € × 35 % = 5,95 €) compense exactement le coût de livraison de 6 €.
**Mais.** Ce calcul donne seulement le minimum. Le seuil optimal en pratique est plus élevé, parce qu'il faut intégrer un coussin de marge pour que l'opération soit profitable, pas neutre. La règle empirique : prendre le seuil mathématique et l'arrondir à un multiple de 5 ou 10 légèrement supérieur. Dans notre exemple : 65 € ou 70 €.
Quel choix entre 65 et 70 ? La question est psychologique, pas mathématique. Un seuil de 70 € est perçu comme « facile à atteindre » par un visiteur avec déjà 45 € au panier (il manque 25 €, soit 56 % de plus). Un seuil de 65 € est perçu comme « presque atteint » (manque 20 €, soit 44 %). Plus le seuil est proche du panier, plus le visiteur est incité à ajouter.
## Pourquoi la barre de progression visuelle change tout
Annoncer un seuil sous forme de texte (« Livraison gratuite dès 70 € ») est largement moins efficace qu'afficher une barre de progression qui montre _en temps réel_ où le visiteur en est par rapport au seuil.
Le mécanisme cognitif : un seuil texte demande au visiteur un calcul mental (« j'ai 45 €, il me faut 70 €, donc 25 € de plus »). Une barre de progression rend ce calcul visuel instantané — le visiteur voit la barre à 64 %, comprend immédiatement qu'il est aux deux tiers, et ressent la pression cognitive de compléter la barre.
Sur les A/B tests que nous avons menés sur des boutiques accompagnées, le passage de seuil texte à barre de progression visuelle augmente le panier moyen de 8 à 18 % selon les boutiques. C'est l'un des leviers de UX e-commerce avec le meilleur ratio coût/impact.
La barre doit afficher trois informations en même temps :
- L'état courant (« 45 € sur 70 € »).
- Le manquant (« il vous manque 25 € pour la livraison gratuite »).
- L'incitation visuelle (la barre elle-même qui se remplit).
Et critique : le message doit changer quand le seuil est atteint. « Vous bénéficiez de la livraison gratuite ! » avec barre pleine 100 % est une récompense psychologique qui renforce la fidélité.
Sur PrestaShop 8, la [barre de livraison gratuite DataFirefly](/product/barre-de-livraison-gratuite-barre-de-progression-et-seuils-par-pays-prestashop/) implémente cette mécanique avec barre visuelle en temps réel, affichage en haut de boutique et au panier, et messages adaptatifs selon l'état (loin du seuil, proche, atteint).
## Le piège du seuil unique en multi-pays
Une boutique qui livre dans plusieurs pays doit calibrer un seuil _par pays_, pas un seuil unique. La raison : le coût de livraison varie significativement entre la France métropolitaine (typiquement 5-7 € via Colissimo ou Mondial Relay) et la Belgique ou l'Espagne (8-12 €), encore plus pour la Suisse, le UK post-Brexit, ou les destinations hors UE (15-25 €).
Si votre seuil est de 70 € pour la France et que vous l'appliquez aussi à la Belgique avec un coût livraison de 11 €, votre marge sur les paniers belges à 70 € est dégradée :
`Seuil_BE = 45 × (1 + (11 / (45 × 0,35))) = 45 × (1 + 0,698) = 76,40 €`
Le seuil minimum pour la Belgique devrait être 80 €, pas 70 €. À 70 €, vous perdez environ 5 € de marge sur chaque panier belge passé sans payer la livraison. Multiplié par 100 commandes belges/mois, c'est 500 € de marge perdue.
Le calcul devient encore plus tendu pour la Suisse (livraison 18 €, seuil minimum proche de 100 €) ou l'international (livraison 25 €+, seuil minimum souvent au-dessus de 120 €).
Implémentation pratique : un module de barre de livraison gratuite qui supporte les seuils par pays (lecture automatique du pays via geoip ou choix utilisateur du pays de livraison) résout ce problème. Sans cette fonctionnalité, vous appliquez un seuil moyen sub-optimal partout.
## Quand baisser le seuil et quand l'augmenter
Une fois votre seuil de base calculé, deux situations justifient de l'ajuster.
**Baisser temporairement.** Pendant les périodes de forte demande (Black Friday, soldes, fêtes), un seuil légèrement abaissé peut accélérer la conversion en jouant sur l'urgence (« profitez de la livraison gratuite à partir de 50 € au lieu de 70 € »). L'arbitrage : la marge unitaire baisse, mais le volume augmente. Sur les périodes où vous avez du stock à écouler, le calcul est généralement positif.
**Augmenter pour pousser le panier.** Sur les boutiques où le panier moyen est très bas (typiquement < 30 €), augmenter le seuil bien au-dessus du panier (par exemple seuil 60 € pour panier moyen 25 €) force les visiteurs à doubler leur panier pour passer en gratuit. C'est agressif et peut perdre certains visiteurs, mais sur les boutiques où la marge est forte (50 %+), le calcul est rentable parce que les paniers qui passent montent à 60 € au lieu de 25.
L'inverse est aussi vrai : si votre panier moyen est déjà élevé (> 100 €) et votre marge serrée (< 25 %), il peut être plus rentable de _ne pas faire_ de livraison gratuite et de facturer la livraison de manière transparente. Le client B2B avec panier de 500 € comprend que la livraison est facturée — il ne s'attend pas à de la gratuité de masse comme en B2C.
## L'effet sur le SEO et le merchandising
Au-delà du panier moyen brut, la barre de livraison gratuite a deux effets indirects souvent ignorés.
**L'effet sur le SEO via le taux de rebond.** Une boutique avec barre de livraison gratuite visible dès la home et les fiches produit a un taux de rebond plus bas (les visiteurs s'engagent dans la navigation au lieu de partir au premier prix). Google interprète positivement ce signal et améliore le ranking sur les requêtes commerciales.
**L'effet sur le merchandising.** Quand un visiteur cherche « le produit qui complète mon panier pour atteindre 70 € », il navigue dans votre catalogue avec une intention spécifique. C'est le moment idéal pour pousser des cross-sell pertinents (sujet traité dans notre article sur les [7 stratégies de cross-sell qui marchent en 2026](/2026/05/09/panier-moyen-prestashop-8-7-strategies-cross-sell-2026/)) ou afficher les bestsellers à prix attractif. La synergie barre de livraison gratuite + cross-sell est plus forte que la somme des deux pris séparément.
## Conclusion : un levier mathématique, pas marketing
La barre de livraison gratuite est l'un des rares leviers e-commerce où le calcul mathématique est plus important que l'intuition marketing. Le seuil n'est pas une valeur arbitraire à choisir au feeling — c'est une fonction de votre panier moyen, votre marge, et votre coût de livraison. Le calculer correctement, et le différencier par pays, peut représenter quelques milliers d'euros de marge additionnelle annuelle sur une boutique moyenne.
L'implémentation visuelle (barre de progression en temps réel) double l'efficacité du levier vs un simple seuil annoncé. Combinée à des cross-sell pertinents qui aident le visiteur à compléter son panier vers le seuil, c'est l'un des leviers de panier moyen avec le meilleur ratio effort/impact en 2026.
Pour creuser les sujets connexes, parcourez nos catégories [Conversion & UX](/category/conversion-ux/) et [Tutoriels PrestaShop](/category/tutoriels-prestashop/). Et pour une barre de livraison gratuite PrestaShop 8 avec barre de progression, seuils par pays, et messages adaptatifs prête à déployer, le module [DataFirefly](/product/barre-de-livraison-gratuite-barre-de-progression-et-seuils-par-pays-prestashop/) couvre l'ensemble en quelques minutes d'installation.
Pour passer à l'action : [notre sélection de modules pour augmenter votre panier moyen](https://www.datafirefly.com/solutions/prestashop/panier-moyen/).
---
### Sauvegarder une boutique PrestaShop en 2026 : règle 3‑2‑1, chiffrement AES‑256 et restauration testée
_Source :_ — _publié_ 2026-05-26
> 6 boutiques PrestaShop sur 10 n'ont pas de sauvegarde restaurable en moins de 4 heures. La règle 3-2-1, le chiffrement AES-256, la rotation GFS et — surtout — la restauration testée. La stratégie de sauvegarde qu'on devrait avoir en 2026.
La plupart des e-commerçants pensent être sauvegardés. La majorité ne l'est pas vraiment. Sur les audits que nous menons, 6 boutiques sur 10 n'ont pas de sauvegarde restaurable en moins de 4 heures, 3 sur 10 ont des sauvegardes corrompues ou incomplètes, et environ 1 sur 10 n'a aucune sauvegarde exploitable depuis plus d'un mois — souvent sans le savoir.
Le coût d'un incident sans sauvegarde fonctionnelle, c'est entre 24 h et plusieurs semaines d'arrêt, des données clients perdues, et parfois la cessation d'activité. Cet article décrit la stratégie de sauvegarde qu'on devrait avoir en 2026 sur une boutique PrestaShop : la règle 3-2-1, le chiffrement, la rotation, et surtout — la restauration testée.
## Pourquoi les sauvegardes par défaut ne suffisent pas
« Mon hébergeur fait des sauvegardes » est la phrase qui revient le plus souvent. C'est vrai en général, et insuffisant en pratique :
- **Les sauvegardes hébergeur sont sur le même datacenter.** Un incendie majeur (OVH Strasbourg 2021), une attaque ransomware, ou un compromis du panneau d'admin de l'hébergeur, et les sauvegardes brûlent avec les données.
- **La rétention est courte.** 7 à 14 jours pour les offres standard. Si vous découvrez un défacement ou une corruption 3 semaines après, la sauvegarde infectée a déjà remplacé la sauvegarde saine.
- **La sauvegarde inclut-elle vraiment tout ?** Beaucoup d'hébergeurs sauvegardent la base mais pas les fichiers, ou inversement. Et les uploads (images produits, factures PDF, exports) sont parfois oubliés.
- **La restauration n'est jamais testée.** Le jour J, on découvre que la procédure de restauration ne fonctionne pas, ou prend 36 heures, ou demande l'accès à un panneau qu'on a perdu.
- **Pas de chiffrement.** Une sauvegarde non chiffrée hébergée chez un tiers, c'est l'ensemble de votre base clients exposé en cas de fuite chez le prestataire.
## La règle 3-2-1 : référence industrielle depuis 30 ans
Formulée par le photographe Peter Krogh en 2005 pour les sauvegardes numériques, adoptée par l'ANSSI, le CISA américain et la quasi-totalité des frameworks de sécurité IT :
> **3 copies des données, sur 2 supports différents, dont 1 hors site.**
Concrètement pour une boutique PrestaShop :
1. **Copie 1** : la production (votre serveur de prod).
2. **Copie 2** : sauvegarde locale ou sur le même hébergeur (rapide à restaurer pour les incidents mineurs).
3. **Copie 3** : sauvegarde hors site, chez un fournisseur de stockage tiers (S3, Backblaze B2, Wasabi, Dropbox).
La copie hors site est la dernière ligne de défense contre les sinistres majeurs (incendie, ransomware, faillite hébergeur).
## Ce qu'il faut sauvegarder dans une boutique PrestaShop
### 1. La base de données complète
Toutes les tables, pas seulement les tables métier. Un dump `mysqldump` avec les options `--single-transaction --quick --routines --triggers` pour la cohérence et l'inclusion des procédures stockées et triggers.
### 2. Les fichiers uploadés
Le dossier `/img/` (images produits, catégories, fabricants), `/upload/` (fichiers attachés aux produits), `/download/` (produits virtuels et leurs livrables), et tous les répertoires de modules tiers stockant des fichiers (factures PDF, exports comptables, logs).
### 3. Le code et les modules
Même si vous avez Git, sauvegarder le code en production permet de capturer les modifications hotfix non versionnées et l'état exact des modules installés. Inclut `/modules/`, `/themes/`, `/override/`, et la racine PrestaShop hors `/var/cache/`.
### 4. La configuration système
Fichiers `app/config/parameters.php`, `.htaccess`, configurations Nginx/Apache, certificats SSL, crontabs. Souvent oubliés, ils sont critiques pour rejouer une installation depuis zéro.
### 5. Les emails sortants et logs récents
Pour les obligations légales (RGPD, comptabilité), conserver une copie des logs récents et des emails transactionnels. Pas systématique, mais utile.
## Le chiffrement n'est plus optionnel
Une sauvegarde non chiffrée stockée chez un fournisseur tiers est un risque RGPD majeur : si le prestataire est compromis, toute votre base clients fuit en clair. Article 32 du RGPD : obligation de mettre en œuvre des « mesures techniques appropriées », ce qui inclut le chiffrement au repos pour les sauvegardes contenant des données personnelles.
Le standard en 2026 : **AES-256 avec une clé stockée séparément des sauvegardes**. Ne jamais stocker la clé de chiffrement avec les sauvegardes — sinon le chiffrement ne sert à rien.
## La rotation : combien de versions conserver
Plus on conserve, mieux c'est — mais ça coûte. Stratégie GFS (Grandfather-Father-Son) éprouvée :
- **Sauvegardes quotidiennes** conservées 7 jours.
- **Sauvegardes hebdomadaires** conservées 4 semaines.
- **Sauvegardes mensuelles** conservées 12 mois.
- **Sauvegardes annuelles** conservées 5 à 7 ans (selon les obligations comptables locales).
Avec cette stratégie, vous pouvez restaurer à n'importe quel jour des 7 derniers jours, n'importe quelle semaine du dernier mois, n'importe quel mois de la dernière année. Couvre 99 % des scénarios de récupération.
## La restauration testée : la seule sauvegarde qui compte
Une sauvegarde non testée est une superstition, pas une sauvegarde. La règle absolue :
> **Testez la restauration sur un environnement de staging au moins une fois par trimestre.**
Ce test doit vérifier :
- La sauvegarde est-elle complète (toutes les tables, tous les fichiers) ?
- Le dump est-il restaurable sans erreur ?
- Le site fonctionne-t-il après restauration (pages catégorie, panier, checkout, BO) ?
- Combien de temps prend la restauration complète (RTO : Recovery Time Objective) ?
- Quelle est la perte de données maximale (RPO : Recovery Point Objective) ?
Sur les boutiques qui font ce test trimestriel, le temps de restauration tombe de 6-8 heures à 1-2 heures en quelques itérations. Et les écarts (table manquante, permission erronée, fichier corrompu) sont détectés avant l'incident, pas pendant.
## Notre module dfbackup : sauvegarde clé en main
Implémenter cette stratégie à la main demande la maintenance d'un script de dump, d'un système de chiffrement, d'une rotation et d'une montée vers du stockage S3. [Notre module dfbackup](https://www.datafirefly.com/product/module-sauvegarde-prestashop-8-9-dfbackup/) pour PrestaShop 8 et 9 packagé toute la stack :
- **Sauvegarde planifiée BDD + fichiers** par cron, intervalle configurable (quotidien, hebdomadaire).
- **Chiffrement AES-256** avec clé séparée, stockable hors du serveur.
- **Destinations multiples** : S3 (et compatibles : Wasabi, Backblaze B2, Scaleway), FTP/SFTP, Dropbox.
- **Rotation GFS automatisée** : conservation paramétrable par strate.
- **Restauration 1-clic** depuis le BO, avec staging optionnel.
- **Notifications** par email ou webhook en cas d'échec ou de succès.
- **Logs détaillés** de chaque sauvegarde (volume, durée, hash de vérification).
- **Compatible multi-shop**, multi-langue, et avec rétention différenciée selon le périmètre.
Pour 129 €, vous installez une stratégie de sauvegarde conforme RGPD et industrialisée, sans dépendre de votre hébergeur.
## Combien coûte ne pas être sauvegardé
Sur une boutique générant 100 k€ de CA mensuel, un arrêt de 48 h coûte directement 6 700 € en CA non réalisé. Ajoutez les coûts indirects : reconquête clients perdus, retours négatifs sur le SAV, impact SEO si l'arrêt dure (Google peut désindexer si le site reste 404 plus de quelques jours), perte de confiance partenaires. Total réaliste : 15 à 30 k€ pour un arrêt de 48 h. Pour un mois d'arrêt, on parle de la viabilité de l'entreprise.
Le coût d'une stratégie de sauvegarde robuste : 130 € de module + 5 à 20 €/mois de stockage S3. Le ratio coût/risque est sans débat.
## FAQ
### Les sauvegardes incrémentielles sont-elles suffisantes ?
Pas seules. Une sauvegarde incrémentielle dépend de la sauvegarde complète précédente. Si la sauvegarde complète est corrompue, toute la chaîne incrémentielle est inutilisable. La règle : **une sauvegarde complète hebdomadaire ou mensuelle**, complétée par des incrémentielles quotidiennes. Pas l'inverse.
### Combien de temps doit prendre une restauration ?
Le RTO acceptable dépend de la criticité. Pour une boutique e-commerce active : **moins de 4 heures pour une restauration complète** est l'objectif. En dessous de 2 heures avec une procédure rodée et un stockage à proximité. Au-delà de 8 heures, il y a un problème de stratégie ou d'outillage.
### Faut-il sauvegarder les fichiers et la base ensemble ou séparément ?
Ensemble, idéalement dans une fenêtre temporelle resserrée (10-15 minutes). Une base et des fichiers désynchronisés (par exemple, base sauvegardée le matin, fichiers le soir) créent des incohérences à la restauration : produits dans la base qui n'ont pas d'image, factures référencées qui n'existent pas en fichier.
### Le stockage cloud (S3) est-il conforme RGPD ?
Oui, si le fournisseur est dans l'UE ou propose les Clauses Contractuelles Types (CCT) pour les transferts hors UE. AWS, Scaleway, OVH Object Storage, Backblaze sont conformes avec config appropriée. Le chiffrement avant upload garantit que même un fournisseur compromis ne donne accès à rien d'utilisable.
### Quelle différence avec une réplication temps réel ?
La réplication (master-slave MySQL, par exemple) protège contre une panne matérielle, pas contre les erreurs humaines ou les corruptions logiques. Si un script supprime 10 000 produits par erreur, la réplique applique la suppression instantanément. La sauvegarde versionnée garde une version saine antérieure. Les deux sont complémentaires, pas substituables.
## Pour aller plus loin
La sauvegarde est un maillon d'une chaîne plus large : sécurité, monitoring, gestion des incidents. Un site bien sauvegardé mais mal monitoré perd quand même des données entre l'incident et sa détection. Voir aussi notre [guide d'installation des modules PrestaShop](https://www.datafirefly.com/2026/05/01/installer-module-prestashop-8-guide-complet/) pour comprendre où dfbackup s'insère dans la stack, et le [dossier sur le nettoyage de la base PrestaShop](https://www.datafirefly.com/2026/06/14/base-prestashop-tables-ballast-nettoyage-retention-2026/) : alléger la base avant sauvegarde divise par 5 le temps de sauvegarde et le coût de stockage.
Pour passer à l'action : [notre sélection de modules pour la maintenance, la sauvegarde et la fiabilité](https://www.datafirefly.com/solutions/prestashop/maintenance-sauvegarde-fiabilite/).
---
### FEC et export comptable e-commerce 2026 : la conformité fiscale française que 80 % des boutiques ratent
_Source :_ — _publié_ 2026-05-25
> Le FEC (Fichier des Écritures Comptables) est une obligation légale française depuis 2014. En 2026, sa non-production dans le délai d'un contrôle entraîne taxation d'office et pénalités. Sur les boutiques e-commerce, 7 sur 10 ne savent pas produire un FEC conforme sans plusieurs jours de retraitement manuel. Anatomie d'un export comptable propre sur WooCommerce et PrestaShop.
## Le FEC : la pièce qu'on ne demande qu'en cas de contrôle, mais qu'il faut produire le jour même
Le Fichier des Écritures Comptables (FEC) est une obligation légale française depuis 2014 pour toute entreprise tenant une comptabilité informatisée. En 2026, l'administration fiscale demande un FEC conforme à l'arrêté du 29 juillet 2013 lors de tout contrôle, et la non-production dans le délai (généralement 30 jours) entraîne un rejet de la comptabilité et une taxation d'office. C'est ce point précis — la production sous délai contraint, sans pouvoir refaire l'historique — qui rend l'export comptable depuis le e-commerce critique.
Sur les boutiques que nous auditons, 7 sur 10 ne savent pas produire leur FEC sans une intervention manuelle de plusieurs jours. Pourtant le calcul est simple : pas de FEC conforme = comptabilité rejetée = redressement basé sur des chiffres approximatifs, généralement défavorables à l'entreprise. Pour une boutique WooCommerce ou PrestaShop qui fait 500 K€ de CA, l'écart entre une compta propre et un redressement peut atteindre plusieurs dizaines de milliers d'euros — sans compter les pénalités.
## Ce qu'est exactement un FEC conforme
Le FEC est un fichier plat (CSV avec séparateur tabulation ou pipe, encodage UTF-8 ou ASCII) qui contient toutes les écritures comptables de l'exercice, dans un format normalisé de 18 colonnes obligatoires :
#ColonneDescription1`JournalCode`Code journal (ex. VE pour ventes, BQ pour banque)2`JournalLib`Libellé journal3`EcritureNum`Numéro d'écriture chronologique4`EcritureDate`Date de comptabilisation (YYYYMMDD)5`CompteNum`Numéro de compte (Plan Comptable Général)6`CompteLib`Libellé du compte7-8`CompAuxNum / CompAuxLib`Compte auxiliaire (client/fournisseur) si applicable9`PieceRef`Référence de la pièce justificative10`PieceDate`Date de la pièce11`EcritureLib`Libellé de l'écriture12-13`Debit / Credit`Montants (utiliser uniquement l'un OU l'autre, jamais les deux)14`EcritureLet`Lettrage (si applicable)15`DateLet`Date de lettrage16`ValidDate`Date de validation de l'écriture17-18`Montantdevise / Idevise`Montant en devise + code devise si pas EUR
Trois règles immuables :
- Une écriture validée ne peut plus être modifiée (chaîne d'irréversibilité). Une correction passe par une contre-écriture, jamais par modification de l'originale.
- Le total débit = total crédit sur chaque écriture (équilibre comptable).
- Les numéros d'écriture sont strictement séquentiels et continus dans le temps.
C'est ce dernier point qui fait défaut sur 80 % des boutiques e-commerce : les commandes sont créées dans un ordre, payées dans un autre, remboursées plus tard. Le mapping vers un FEC séquentiel exige une normalisation rigoureuse.
## Pourquoi e-commerce et comptabilité ne s'entendent pas naturellement
WooCommerce et PrestaShop tiennent une **base commerciale** : commandes, paiements, remboursements, avoirs, frais de port. Un expert-comptable a besoin d'une **base comptable** : écritures débitrices et créditrices équilibrées, codifiées par compte du PCG (Plan Comptable Général).
La translation des deux modèles passe par six concepts :
### 1. Les comptes du Plan Comptable Général
Une vente B2C en France typique mobilise :
- `411xxx` — Compte client (auxiliaire par client si volume faible, agrégé si volume élevé)
- `707000` — Ventes de marchandises (ou `706000` pour les services)
- `4457xx` — TVA collectée (par taux : 20 %, 10 %, 5,5 %, 2,1 %)
- `708500` — Ports facturés (avec sa propre TVA)
- `411090` ou similaire — Compte d'attente paiement (avant l'encaissement effectif)
- `512xxx` — Banque (lors de l'encaissement)
- `627xxx` — Frais bancaires processeur (Stripe, PayPal)
### 2. Les journaux comptables
Au minimum trois journaux distincts :
- **VE — Ventes** : enregistre la vente et la TVA collectée au moment de la facturation (commande payée)
- **BQ — Banque** : enregistre l'encaissement réel sur le compte bancaire
- **OD — Opérations diverses** : enregistre les avoirs, retours, frais de processeur, écarts de change
### 3. La date de comptabilisation vs la date de paiement
Une commande payée le 31 mars à 23 h 59 et encaissée par Stripe le 2 avril doit comptabiliser la vente sur mars (date du fait générateur fiscal : la livraison ou la vente définitive) et l'encaissement sur avril (date de crédit bancaire effectif). Ce décalage est la cause principale d'erreurs sur les exports e-commerce naïfs.
### 4. La gestion de la TVA
Trois cas pratiques :
- **Vente France** : TVA collectée au taux français applicable
- **Vente intracommunautaire B2B avec n° de TVA valide** : TVA à 0 % avec mention _« autoliquidation »_, déclaration sur la DEB et la DES
- **Vente intracommunautaire B2C (OSS-IOSS depuis 2021)** : TVA au taux du pays de destination si le seuil 10 000 €/an UE est dépassé, déclaration via le guichet unique OSS
L'OSS-IOSS est le piège qui fait basculer en non-conformité 60 % des boutiques multi-pays. Ce n'est pas un export FEC standard : il faut un journal séparé par pays de destination, ou des comptes 4457 distincts par taux applicable.
### 5. Les retours et avoirs
Un retour client génère un avoir (facture négative) ET une écriture de remboursement. Les deux doivent apparaître séparément dans le FEC, avec la traçabilité `PieceRef` qui pointe sur la commande d'origine. Comptabiliser un retour comme une « annulation » de l'écriture initiale est non-conforme : cela casse la chaîne d'irréversibilité.
### 6. Les frais de processeur
Une commande à 100 € payée par Stripe encaisse réellement environ 97,10 € sur le compte bancaire (frais Stripe : 1,4 % + 0,25 € pour une carte UE). Les 2,90 € de différence vont sur le compte `627` (services bancaires). Sans cette ventilation, le rapprochement bancaire est impossible.
## Pourquoi les exports e-commerce natifs ne suffisent pas
WooCommerce et PrestaShop disposent d'exports CSV natifs des commandes. Ces exports ne sont **pas** un FEC, pour cinq raisons :
1. **Aucune notion de journal comptable** — Une ligne = une commande, pas une écriture débit/crédit.
2. **Aucune ventilation par compte du PCG** — Les montants HT, TVA, port ne sont pas mappés sur les comptes 707, 4457, 708.
3. **Aucune gestion de la séquentialité d'écriture** — Pas de `EcritureNum` continu.
4. **Pas de séparation vente/encaissement** — La date de paiement et la date de validation sont confondues.
5. **Pas de traitement des retours, avoirs et frais processeur** — Ces opérations sont ignorées ou incohérentes.
Résultat pratique : l'expert-comptable reçoit un export Excel et passe 8 à 12 heures par exercice à reconstruire les écritures manuellement. Sur une boutique avec 2 000 commandes/an, c'est entre 1 200 et 1 800 € de prestation comptable supplémentaire. Sur une boutique avec 20 000 commandes/an, c'est l'expert-comptable qui refuse le dossier ou facture 4 000 à 6 000 € de réintégration.
## L'architecture d'un export FEC propre
Un module FEC sérieux pour [WooCommerce](https://www.datafirefly.com/product/dfwoo-fec/) ou [PrestaShop](https://www.datafirefly.com/product/dfaccountingexport-export-comptable-prestashop/) implémente cinq couches :
### Couche 1 — Mapping des comptes
L'admin configure le mapping entre les entités e-commerce et les comptes du PCG :
- Catégorie de produit → compte 707/706 (ventes marchandises vs services)
- Méthode de livraison → compte 708 (port) ou 706 (service)
- Taux de TVA → compte 4457 (4457100, 4457200, 4457550, etc.)
- Méthode de paiement → compte 411090 d'attente, puis 512 banque ou 512x sub-compte par processeur
- Frais de processeur → compte 627 (avec sous-comptes Stripe, PayPal, Mollie)
### Couche 2 — Génération des écritures
Pour chaque commande dans la période, le module génère 3 à 8 écritures distinctes :
- Vente HT (débit 411 client, crédit 707 ventes)
- TVA collectée (crédit 4457 par taux)
- Port (crédit 708 ou 706)
- Encaissement (débit 512 banque, crédit 411 client) avec décalage de date
- Frais processeur (débit 627, crédit 512) en écriture séparée
Pour un avoir, on génère les contre-écritures, jamais une modification des originales.
### Couche 3 — Numérotation séquentielle stable
Le `EcritureNum` est attribué à l'export selon un compteur global persistant, redémarré chaque exercice. Une fois exportée, une écriture conserve son numéro à vie. Le module doit stocker cet état pour ne jamais re-numéroter à la régénération.
### Couche 4 — Validation et contrôles
Avant export, le module vérifie :
- Équilibre débit/crédit par écriture (différence ≤ 0,01 €)
- Continuité du `EcritureNum` (pas de trou ni de doublon)
- Conformité du format (encodage, séparateur, dates YYYYMMDD)
- Présence de toutes les colonnes obligatoires
- Cohérence comptable (les comptes utilisés existent dans le PCG configuré)
### Couche 5 — Export et signature
Le fichier final est produit dans le format légal (TXT avec séparateur pipe ou tabulation, UTF-8 ou ASCII), avec un nom normalisé : `SIREN+FEC+date_fin_exercice.txt` (par exemple `123456789FEC20251231.txt`). Certains modules calculent en plus un hash SHA-256 pour traçabilité interne.
## Les pièges juridiques à ne pas négliger
### 1. Le délai de conservation
Le FEC et toutes les pièces justificatives (factures, avoirs, justificatifs bancaires) doivent être conservés pendant 10 ans à compter de la clôture de l'exercice (article L.123-22 du code de commerce). Pour une boutique e-commerce, cela inclut les exports SQL de la base, les factures PDF, et les logs de paiement processeur. La stratégie de sauvegarde doit couvrir cette rétention longue : voir notre article sur [la sauvegarde PrestaShop règle 3-2-1](https://www.datafirefly.com/2026/05/26/sauvegarder-boutique-prestashop-regle-3-2-1-chiffrement-restauration-2026/).
### 2. La tenue de la comptabilité doit être chronologique
Article 921-2 du PCG : « Le caractère définitif des enregistrements [...] est assuré par une procédure de validation qui interdit toute modification ou suppression de l'enregistrement ». Un module FEC qui permet de « re-générer » un exercice clos est non-conforme. Une fois l'exercice clos par l'expert-comptable, le FEC est figé.
### 3. La taxation d'office en cas de non-production
Si le FEC n'est pas produit dans le délai du contrôle (généralement 30 jours après la demande), l'administration peut rejeter la comptabilité et procéder à une taxation d'office sur des bases qu'elle estime. Les pénalités peuvent atteindre 5 000 € (article 1729 D du CGI) + 0,5 % du CA par mois de retard.
### 4. RGPD et données comptables — la tension avec le droit à l'oubli
Article 17 du RGPD permet à un client de demander la suppression de ses données. Mais l'obligation comptable impose 10 ans de conservation. La résolution juridique : on conserve les données nécessaires à l'obligation légale (nom, adresse de facturation, montants) et on supprime le reste (préférences, historique de navigation, marketing). C'est le sujet précis que nous traitons dans l'article de demain sur [le droit à l'oubli RGPD sans casser la trace fiscale](https://www.datafirefly.com/2026/05/23/droit-oubli-rgpd-article-17-suppression-compte-trace-fiscale-prestashop-2026/).
## WooCommerce et PrestaShop : deux logiques d'implémentation
### WooCommerce — la spécificité française
WooCommerce est conçu pour le marché US, où le FEC n'existe pas. L'export comptable français exige donc un plugin tiers qui sait lire les commandes WC, leurs items, leurs taxes (via le système `wc_tax_rate`), et qui sait mapper les _payment gateways_ sur les comptes bancaires. Le [module DfWoo-FEC](https://www.datafirefly.com/product/dfwoo-fec/) implémente cette logique avec un mapping configurable, la gestion HPOS (High-Performance Order Storage), et le support des refunds WC nativement.
### PrestaShop — l'avantage de la TVA native
PrestaShop, conçu en France à l'origine, gère nativement les taux de TVA, les comptes auxiliaires clients, les factures et avoirs séquentiels (`ps_order_invoice`, `ps_order_slip`). Le travail du module FEC est donc plus simple : transformer les _invoices_ et _slips_ en écritures comptables, sans avoir à recalculer les TVA. Le [module DataFirefly Accounting Export](https://www.datafirefly.com/product/dfaccountingexport-export-comptable-prestashop/) implémente cette logique avec le support multishop, multilingue, multidevise.
## Cas particuliers à traiter dans l'export
### Les commandes B2B avec TVA intracommunautaire
Quand un client allemand avec un numéro de TVA UE valide achète, la TVA française est à 0 %. L'écriture doit refléter cela explicitement, avec mention _« autoliquidation par le preneur »_, et le montant doit alimenter la DEB (déclaration d'échange de biens) et la DES (déclaration européenne de services). Un module qui traite ces ventes comme du B2C français est non-conforme.
### L'OSS-IOSS pour le B2C UE
Depuis juillet 2021, les ventes B2C UE au-delà de 10 000 €/an cumulés exigent la TVA du pays de destination. Le FEC doit faire apparaître un compte 4457 par pays/taux (ex. `4457DE19` pour TVA Allemagne 19 %, `4457IT22` pour Italie 22 %). Sans cette ventilation, la déclaration OSS trimestrielle est impossible.
### Les abonnements et la TVA temporelle
Pour une boutique en [abonnements](https://www.datafirefly.com/expertise/woocommerce-abonnements/), la TVA est due au prorata de la prestation. Un abonnement annuel à 120 € souscrit le 15 octobre génère : 24 € de CA et 4,80 € de TVA sur l'exercice en cours (oct-nov-dec), puis 96 € de CA et 19,20 € de TVA répartis sur l'exercice suivant. Le module FEC doit pouvoir générer ces écritures de produits constatés d'avance.
### Les bons cadeaux et gift cards
Vendre un bon cadeau de 50 € n'est pas une vente — c'est un engagement futur. L'écriture initiale est dette envers le client (compte 4419 ou similaire), pas vente (707). Au moment de l'utilisation du bon, on solde la dette et on enregistre la vente. C'est subtile et 90 % des exports automatiques se trompent.
## Workflow recommandé : la passation au cabinet d'expertise
La bonne pratique observée chez les boutiques qui ont passé sans souci leur dernier contrôle fiscal :
1. **Mapping initial avec le cabinet** — Une session de 2 h avec l'expert-comptable pour valider les comptes utilisés, les journaux, et le traitement des cas particuliers (avoirs, frais processeur, OSS).
2. **Export mensuel** — Génération du FEC partiel chaque mois, transmis au cabinet pour rapprochement bancaire et intégration dans la compta. Un mois oublié est un mois à reconstruire.
3. **Lettrage des comptes auxiliaires** — Lettrer client par client (ou en agrégé pour les très gros volumes) pour identifier les retours et avoirs non comptabilisés.
4. **Clôture annuelle** — Export du FEC complet de l'exercice, validation finale par l'expert-comptable, archivage chiffré pour 10 ans.
5. **Test de production** — Une fois par an, simuler une demande de FEC : générer le fichier, vérifier qu'il s'ouvre dans le logiciel de contrôle fiscal (Test Compta Demat), et qu'il passe les validations.
## Coût et ROI
Pour une boutique avec 2 000 commandes/an, l'équation économique :
- **Module FEC** : [49 € licence WooCommerce](https://www.datafirefly.com/product/dfwoo-fec/) ou [99 € licence PrestaShop](https://www.datafirefly.com/product/dfaccountingexport-export-comptable-prestashop/)
- **Setup avec cabinet** : 200 à 400 € (mapping initial, paramétrage des comptes)
- **Économie sur prestation comptable** : 800 à 1 500 €/an (réintégration manuelle évitée)
- **Économie sur risque fiscal** : non chiffrable mais critique en cas de contrôle
Payback de 3 à 6 mois sur la seule économie comptable, sans compter la couverture du risque.
## FAQ
### Mon expert-comptable utilise déjà un logiciel qui importe mes commandes WooCommerce. Ai-je besoin d'un FEC ?
Le logiciel comptable produit son propre FEC à partir des écritures qu'il a saisies. Mais l'export depuis votre boutique doit être propre _en amont_ pour que les écritures soient correctes. Un connecteur direct WooCommerce → logiciel comptable (type Sage, Cegid, Quadra) peut remplacer un module FEC, mais il a son propre coût (mensuel typiquement) et ses propres limites de mapping.
### Puis-je tenir ma compta en Excel et générer un FEC depuis Excel ?
Légalement oui, si Excel respecte les principes de la comptabilité (irréversibilité notamment). En pratique, c'est l'écueil principal : Excel permet de modifier des écritures passées, ce qui rend la comptabilité non-conforme. L'administration ne refuse pas Excel par principe mais demande des garanties (export PDF horodaté de chaque clôture mensuelle, par exemple). Au-delà de 100 commandes/mois, c'est ingérable.
### Quel est le bon journal pour les frais Stripe/PayPal ?
Le compte 627 (services bancaires) avec un sous-compte par processeur (`627100 Stripe`, `627200 PayPal`, `627300 Mollie`). L'écriture passe au journal OD (opérations diverses) au moment du versement net du processeur sur le compte bancaire. Certains experts préfèrent passer au journal BQ (banque) avec une ligne de frais — les deux sont acceptés tant que c'est cohérent dans l'exercice.
### Comment gérer les ventes Amazon ou eBay qui transitent par ma boutique ?
Si la commande est créée dans WooCommerce/PrestaShop (via un connecteur marketplace), l'export FEC la traite comme une vente normale, avec le compte 411 auxiliaire = Amazon/eBay (pas le client final). Les frais marketplace vont en 627 distinct. Si la commande n'est jamais dans WC/PS (Amazon FBA pur), elle relève de la compta Amazon en parallèle — votre cabinet doit alors gérer deux flux.
### L'export FEC inclut-il la TVA à l'IS et la TVA déductible sur achats ?
Non. Le FEC produit par un module e-commerce ne couvre que les écritures issues du e-commerce (ventes, encaissements clients, frais processeur). Les achats fournisseurs, salaires, charges sociales, IS — tout cela passe par le logiciel comptable du cabinet et fusionne avec le FEC e-commerce dans le FEC final annuel.
## En synthèse
Le FEC n'est pas un export de plus. C'est une obligation légale française dont la non-conformité ouvre directement la porte au redressement fiscal. Un module FEC sérieux remplace 10 à 30 heures de retraitement comptable manuel par exercice, sécurise les délais de production en cas de contrôle, et donne au cabinet d'expertise un fichier directement intégrable dans son logiciel.
Pour [WooCommerce](https://www.datafirefly.com/expertise/developpeur-woocommerce/), le module [DfWoo-FEC](https://www.datafirefly.com/product/dfwoo-fec/) gère le mapping, l'export, et les cas particuliers (HPOS, OSS, refunds). Pour [PrestaShop](https://www.datafirefly.com/expertise/developpeur-prestashop/), le module [DataFirefly Accounting Export](https://www.datafirefly.com/product/dfaccountingexport-export-comptable-prestashop/) couvre le multishop, le multilingue, le multidevise et les ventes B2B intracommunautaires.
Le bon réflexe en 2026 : valider avec son cabinet le mapping comptable dès l'installation du module, exporter mensuellement, et faire un test annuel de production de FEC dans le logiciel officiel de contrôle. Une heure de discipline mensuelle qui évite des semaines de stress en cas de contrôle.
Pour passer à l'action : nos sélections de modules pour une facturation conforme [sur PrestaShop](https://www.datafirefly.com/solutions/prestashop/facturation-conforme/) et [sur WooCommerce](https://www.datafirefly.com/solutions/wordpress/facturation-conforme/).
---
### Multi-pays sur PrestaShop : hreflang, country switcher et localisation prix sans casser le SEO en 2026
_Source :_ — _publié_ 2026-05-25
> Multi-pays sur PrestaShop 8 : hreflang, country switcher, localisation prix, conformité TVA. Le multi-pays mal fait dégrade le SEO France au lieu d'ouvrir des marchés. Voici la mécanique correcte en 2026.
Une boutique PrestaShop qui veut vendre dans plusieurs pays affronte trois problèmes simultanés : faire en sorte que Google montre la bonne version de la page au bon visiteur (selon sa langue et son pays), permettre au visiteur de basculer manuellement entre versions, et localiser les prix et devises sans casser la conformité TVA. Aucun des trois n'est trivial, et leurs interactions cachées génèrent la majorité des bugs SEO multi-pays qu'on rencontre en audit.
Cet article détaille la mécanique correcte pour PrestaShop 8 en 2026 : balises hreflang, sélecteur de pays, localisation prix, et les pièges qui dégradent silencieusement votre SEO international si la configuration n'est pas rigoureuse.
## Le piège du multi-pays mal fait
Sur les boutiques multi-pays que nous auditons, deux familles de problèmes reviennent en boucle.
**Le duplicate content non maîtrisé.** Si votre fiche produit est accessible en français pour la France (`/fr/produit-x`) ET pour la Belgique (`/be/produit-x`) ET pour le Canada (`/ca-fr/produit-x`) avec le même contenu textuel, Google détecte trois pages quasi-identiques et choisit lui-même laquelle indexer en priorité — souvent pas celle que vous voudriez. Sans hreflang explicite, vous laissez Google deviner.
**Le ciblage géographique défaillant.** Un acheteur belge cherche votre produit, Google lui montre la version française (`/fr/`) au lieu de la version belge (`/be/`). Le client clique, voit des prix en euros français, des frais de port France métropolitaine, et abandonne en pensant que vous ne livrez pas en Belgique. Vous avez l'offre, vous la livrez, mais le visiteur ne le sait pas parce que la mauvaise version lui a été servie.
Ces deux problèmes sont résolus par les balises hreflang — à condition qu'elles soient correctement implémentées. Sur les audits que nous menons, environ 60 % des boutiques multi-pays ont un hreflang techniquement cassé : balises absentes, balises non-réciproques, codes pays mal formés, conflit avec les balises canonical. Aucun de ces bugs n'est visible côté visiteur — vous découvrez le problème quand votre trafic Belgique reste à zéro pendant 18 mois alors que le marché est ouvert.
## Hreflang : le tag clé du SEO multi-pays
La balise hreflang dit à Google : « cette page existe aussi pour tel autre pays/langue, voici l'URL de cette autre version ». Elle se place dans le `head` de chaque page, ou dans le sitemap XML, ou dans les en-têtes HTTP — les trois sont valides, mais le head est le plus simple à debugger.
Format minimal pour une page produit qui existe en FR-FR, FR-BE, et FR-CA :
```
```
Quatre règles non négociables :
**1. Réciprocité.** Si la page A référence la page B en hreflang, la page B doit référencer la page A. Sans ça, Google ignore la déclaration unilatérale. C'est l'erreur la plus fréquente — 40 % des boutiques multi-pays ont au moins un hreflang non-réciproque quelque part dans leur arborescence.
**2. Codes pays/langue corrects.** Le format est `langue-pays` selon ISO 639-1 (langue) et ISO 3166-1 alpha-2 (pays). `fr-FR` est valide, `fr-FRA` ou `fre-FR` sont invalides et ignorés. Pour le UK c'est `en-GB`, pas `en-UK`.
**3. URL absolues.** Les balises hreflang doivent contenir des URL complètes (`https://...`), pas des chemins relatifs. Une URL relative casse la balise.
**4. Cohérence avec canonical.** Chaque page de la grille hreflang doit avoir sa propre balise canonical pointant vers elle-même (pas vers une autre version). Mettre la canonical de la page `fr-be` vers la page `fr-fr` annule l'effet du hreflang.
Sur PrestaShop 8 nativement, la gestion hreflang est partielle et souvent incomplète selon le thème. Le [module Hreflang DataFirefly](/product/module-hreflang-prestashop-8-balises-alternate-seo-multilingue-datafirefly/) automatise la génération des balises sur toutes les pages multilingues, gère la réciprocité, valide les codes ISO, et synchronise avec le multi-shop. C'est le moyen le plus rapide de ne pas avoir à debugger ces 4 règles à la main produit par produit.
## Le sélecteur de pays : UX et ergonomie
Le sélecteur de pays est l'élément qui permet au visiteur de basculer manuellement entre versions de votre boutique. Il est généralement placé en haut à droite du header (à côté du compte / panier) ou dans le footer.
Trois patterns UX dominants en 2026 :
**Le drapeau cliquable simple.** Un drapeau (icône) qui représente le pays courant, cliquable pour ouvrir un dropdown des autres pays disponibles. Compact, immédiatement compréhensible, fonctionne bien sur mobile. Limite : si vous gérez beaucoup de pays (> 10), le dropdown devient long et inutilisable.
**Le sélecteur drapeau + nom de pays.** Combinaison drapeau + texte (« 🇫🇷 France » / « 🇧🇪 Belgique »). Plus accessible (les drapeaux seuls sont parfois ambigus — le drapeau espagnol vs catalan vs colombien), supporte mieux les pays multiples avec même langue (FR-FR vs FR-BE vs FR-CA).
**La modale de sélection au premier visit.** Pour les boutiques fortement multi-pays, une modale qui s'affiche au premier chargement et propose explicitement de choisir son pays. Plus intrusive, mais évite les erreurs de ciblage initial. À utiliser avec parcimonie — beaucoup d'utilisateurs détestent les modales qui apparaissent immédiatement.
Erreur classique : auto-rediriger le visiteur vers la version de son pays détecté par IP, sans demander confirmation. Cette pratique est explicitement déconseillée par Google (mauvais signaux pour le SEO), elle frustre les voyageurs et VPN-users, et casse les liens partagés (un Belge qui partage une URL `/fr-be/...` à un Français se retrouve redirigé). La bonne pratique en 2026 : _suggérer_ le bon pays au visiteur via un bandeau discret (« Vous êtes en Belgique. Voir notre boutique belge ? »), pas le rediriger sans demander.
Sur PrestaShop 8, le [module Sélecteur de Pays DataFirefly](/product/module-selecteur-de-pays-prestashop-8-drapeaux-cliquables-datafirefly/) implémente le pattern drapeau + nom de pays avec dropdown, support multi-shop natif, et compatibilité avec le module Hreflang pour cohérence du stack multilingue. La configuration est centralisée et survit aux mises à jour PrestaShop.
## Localisation prix, devises, et conformité TVA
La localisation prix est le sujet le plus délicat techniquement parce qu'il croise SEO, UX, et conformité légale.
**Devises.** PrestaShop 8 gère le multi-devise nativement, avec taux de change configurables manuellement ou synchronisés via API (BCE, Open Exchange Rates). Sur les boutiques multi-pays, chaque version doit afficher la devise locale par défaut (€ pour la zone euro, CHF pour la Suisse, GBP pour le UK, etc.). Le sélecteur manuel reste possible mais est moins utilisé en 2026 — les visiteurs préfèrent voir directement la devise de leur pays.
**Prix HT vs TTC.** Pour les boutiques B2C, prix TTC partout (avec mention « TTC » ou « VAT included »). Pour les boutiques B2B, prix HT par défaut avec mention « HT » ou « ex VAT » et toggle pour basculer en TTC. Mélanger HT et TTC sur la même page sans hiérarchie claire est la cause de friction la plus fréquente sur les boutiques mixtes B2B/B2C.
**TVA par pays.** En zone euro, la TVA dépend du pays de livraison (et non du pays de la boutique) pour les ventes B2C au-dessus du seuil OSS (Operating Single System) de 10 000 € HT/an cumulés vers l'UE. Sous le seuil, vous appliquez la TVA française. Au-dessus, vous appliquez la TVA du pays de livraison et déclarez via OSS. PrestaShop 8 gère le système nativement, à condition d'avoir activé le module OSS et configuré les taux par pays.
**Localisation des prix marketing.** Au-delà de la simple conversion EUR → CHF, certaines boutiques différencient les prix par pays pour des raisons commerciales (un produit à 49 € en France peut être à 55 CHF en Suisse, pas le taux exact). C'est faisable avec multi-shop ou groupes de prix, mais demande un travail produit par produit. Au minimum, les arrondis doivent être cohérents (49,99 € → 49,99 CHF, pas 50,12 CHF qui apparaît grossier).
## Configuration PrestaShop 8 native vs modules tiers
PrestaShop 8 expose nativement plusieurs des briques multi-pays via le multi-shop. Voici ce qui marche en natif et ce qui demande des modules complémentaires.
**Natif : multi-shop avec un domaine par pays.** Vous pouvez créer plusieurs boutiques (au sens PrestaShop multi-shop), chacune avec sa propre URL (par exemple `monsite.fr` pour la France, `monsite.be` pour la Belgique), partageant le même catalogue produit ou avec catalogue différencié. La configuration est solide et bien documentée.
**Natif : multi-langue par boutique.** Chaque boutique du multi-shop peut avoir plusieurs langues. Une boutique belge peut afficher français + néerlandais + allemand, par exemple.
**Manquant en natif : hreflang automatique entre boutiques.** PrestaShop ne génère pas spontanément les bonnes balises hreflang quand vous avez plusieurs boutiques avec des contenus traduits. C'est précisément le rôle du module hreflang dédié.
**Manquant en natif : sélecteur de pays unifié.** PrestaShop a un sélecteur de langue dans le footer mais pas un vrai sélecteur de pays/boutique avec drapeaux. Module dédié nécessaire pour cela.
**Manquant en natif : suggestions intelligentes.** Le bandeau « Vous êtes en Belgique, voir notre boutique belge ? » n'existe pas nativement. À implémenter via un module ou du JS custom.
La combinaison la plus stable en 2026 : multi-shop PrestaShop natif (un domaine par pays principal, sous-répertoires pour les pays secondaires de la même langue) + module Hreflang DataFirefly pour les balises automatiques + module Sélecteur de Pays DataFirefly pour l'UI. Les trois forment un stack cohérent qui couvre 95 % des cas d'usage multi-pays sans bricolage.
## Mesurer le succès du multi-pays
Trois métriques à mettre en place pour évaluer si votre multi-pays fonctionne réellement.
**1. Indexation par pays dans Search Console.** Configurez chaque domaine ou sous-répertoire de votre multi-pays comme une propriété distincte dans Search Console. Chaque propriété montre le trafic, les requêtes, les clics, les positions pour le pays correspondant. Si votre boutique belge a 5 % du trafic de votre boutique française, vous savez où vous en êtes.
**2. Erreurs hreflang dans Search Console.** Search Console > Améliorations > International Targeting détaille les erreurs hreflang détectées par Google : balises non-réciproques, codes invalides, conflits canonical. Une boutique multi-pays sans erreur hreflang dans Search Console est rare — viser zéro erreur est l'objectif.
**3. Trafic et conversion par pays dans GA4.** Dans GA4, segmentez par pays (Country dimension). Comparez le ratio sessions/conversions par pays. Une distorsion (par exemple, 30 % de sessions Belgique mais 5 % de conversions) signale soit un problème de localisation prix/livraison, soit un problème de UX local.
## Conclusion : le multi-pays n'est pas une option, c'est un projet
Beaucoup de marchands abordent le multi-pays comme une simple option de configuration : « j'ajoute la Belgique en cliquant sur quelques cases ». La réalité est qu'un multi-pays bien fait est un projet à part entière, qui combine SEO (hreflang), UX (sélecteur de pays), localisation (prix, devise, TVA), et mesure (analytics par pays). Mal fait, le multi-pays dégrade le SEO France au lieu d'ouvrir des marchés additionnels.
L'investissement initial est de quelques jours de configuration sérieuse, plus quelques centaines d'euros de modules dédiés. Le retour, sur les boutiques que nous accompagnons, est généralement entre 15 et 40 % de CA additionnel sur 12-18 mois selon les marchés ouverts et la qualité de l'exécution.
Pour creuser, parcourez nos catégories [SEO E-commerce](/category/seo-ecommerce/) et [Tutoriels PrestaShop](/category/tutoriels-prestashop/). Et pour aligner votre PrestaShop 8 sur les standards multi-pays 2026, le combo [Module Hreflang](/product/module-hreflang-prestashop-8-balises-alternate-seo-multilingue-datafirefly/) + [Sélecteur de Pays](/product/module-selecteur-de-pays-prestashop-8-drapeaux-cliquables-datafirefly/) couvre les briques techniques manquantes du natif PrestaShop, avec configuration unifiée multi-shop.
Pour passer à l'action : [notre sélection de modules pour vendre à l'international](https://www.datafirefly.com/solutions/prestashop/vente-internationale/).
---
### B2B sur PrestaShop : comptes pros, devis, paiement différé, KYB — le stack complet 2026
_Source :_ — _publié_ 2026-05-25
> PrestaShop n'est pas Shopify Plus. Mais avec les bonnes briques assemblées (validation SIRET/VIES, groupes clients, pro forma, paiement différé, BNPL B2B, saisie rapide), il couvre la majorité des besoins B2B PME et ETI à un tiers du coût d'Adobe Commerce. Cartographie complète du stack B2B PrestaShop en 2026.
Le B2B sur PrestaShop est un sujet à la fois mature et mal compris. PrestaShop n'est pas Shopify Plus ni Adobe Commerce — il n'a pas de mode B2B natif explicitement positionné. Mais il dispose de toutes les briques nécessaires (groupes clients, prix par groupe, multi-utilisateurs, devis), à condition de les assembler correctement et de combler les trous fonctionnels avec quelques modules ciblés.
En 2026, la pression B2B s'intensifie : les acheteurs professionnels veulent désormais une expérience aussi fluide que le B2C qu'ils vivent ailleurs (Amazon, Manomano, Cdiscount Pro). Les boutiques PrestaShop qui répondent à cette attente captent des volumes significatifs sans investissement plateforme énorme. Voici la cartographie complète du stack B2B sur PrestaShop en 2026.
## Le périmètre fonctionnel d'un B2B e-commerce moderne
Au-delà des prix HT et de la facturation, un B2B complet implique aujourd'hui :
- Identification professionnelle (SIRET, TVA intracommunautaire, KYB de base).
- Tarification par groupe ou par client : prix nets, remises volume, conditions personnalisées.
- Comptes multi-utilisateurs : un compte société avec plusieurs acheteurs, des rôles (acheteur, valideur, comptable).
- Workflow de devis : demande de devis, négociation, conversion en commande, signature.
- Paiement différé (30, 45, 60 jours fin de mois), avec encours et limite de crédit.
- Catalogue restreint par client ou par groupe (un acheteur ne voit que ses produits).
- Commande rapide par référence, import CSV, panier sauvegardé.
- Facturation pro forma, bons de livraison, factures multilingues, exports comptables.
Aucune plateforme n'offre cela natif. Sur PrestaShop, on construit en combinant brique native + extensions ciblées.
## Brique 1 — Identification et création de compte pro
Le formulaire d'inscription natif PrestaShop pour les sociétés permet déjà de saisir la raison sociale, le SIRET et le numéro de TVA intracommunautaire. Ce qui manque en natif :
- La validation automatique du SIRET via l'API Insee (gratuite, robuste).
- La validation du numéro de TVA via VIES (gratuite, indispensable pour facturer HT intracommunautaire).
- Un workflow de validation manuelle du compte (« en attente de validation ») avant d'autoriser la commande.
Ces trois éléments font la différence entre une boutique qui laisse n'importe qui s'inscrire comme pro (et risque la fraude) et une qui contrôle réellement son canal B2B. Plusieurs modules tiers couvrent ce besoin, ou on peut le développer en surcharge.
### KYB léger sur PrestaShop : ce qui est faisable
Un KYB (Know Your Business) complet implique vérification d'identité du dirigeant, recoupement bénéficiaire effectif, vérification de sanctions internationales. C'est généralement disproportionné pour un e-commerce B2B de produits standard.
Le KYB léger pertinent pour la majorité des marchands : SIRET valide, TVA intracommunautaire valide, code NAF cohérent avec la cible, vérification que le compte n'est pas radié (Insee). C'est faisable en quelques heures de développement et couvre 95 % des cas de fraude.
## Brique 2 — Tarification par groupe et par client
PrestaShop natif gère les groupes clients et les règles de prix spécifiques par groupe. C'est solide. Trois affinements pertinents en B2B :
- **Prix net spécifique par client** (au-delà du groupe) : un grand compte négocie un tarif à part. Géré par les règles de prix spécifiques sur la fiche produit, mais lourd à maintenir si on multiplie les comptes. Un module de tarification client peut centraliser.
- **Remises volume par paliers** : à partir de 10 unités, 5 % ; à partir de 50, 10 %. Natif via les règles de prix mais peu visible côté client. Affichage explicite des paliers sur la fiche produit améliore la conversion.
- **Affichage HT par défaut pour groupe pro** : option native PrestaShop. À activer obligatoirement, sinon l'acheteur pro voit du TTC et se demande pourquoi.
## Brique 3 — Comptes multi-utilisateurs
C'est le point faible historique de PrestaShop pour le B2B. Un compte client = un email = un utilisateur. Aucune notion native de société avec plusieurs comptes rattachés.
Trois approches en 2026 :
1. **Module multi-utilisateurs tiers** (wkmultiuser et équivalents) : rattache plusieurs comptes à une entité société, avec rôles et droits. Mature, plusieurs solutions du marché.
2. **Convention simple « un compte par société »** : suffisant pour les TPE et PME. On contourne le problème en demandant au client d'utiliser une boîte partagée (commandes@société.fr) et un mot de passe partagé. Pas idéal, mais pragmatique.
3. **Approche SSO B2B** (plus rare) : compte rattaché à un annuaire client (LDAP, Google Workspace). Réservé aux gros comptes avec gros volumes.
## Brique 4 — Workflow de devis et pro forma
Le devis est central en B2B. Un visiteur pro ne commande pas en ligne sur un panier impulsif — il demande un devis, fait valider, puis convertit en commande. PrestaShop ne gère pas nativement ce flux, mais plusieurs modules le couvrent. Côté DataFirefly, le module dfproforma génère un PDF pro forma à partir d'un panier client, avec validité paramétrable, conversion en commande sans ressaisie, signature électronique optionnelle, et envoi par email avec relances automatiques.
Le workflow typique : visiteur pro inscrit, constitue son panier, clique « Demander un devis », reçoit le pro forma par email, valide la signature, le panier est converti en commande payable selon les conditions négociées.
## Brique 5 — Paiement différé et encours client
Le grand sujet 2026. Un B2B sérieux propose le paiement à 30, 45 ou 60 jours fin de mois. Deux approches :
### Mode interne : on porte le risque
Module de mode de paiement « facture à 30 jours » avec encours et limite de crédit. PrestaShop gère ça via un module de paiement custom (facile à développer) et un suivi manuel ou semi-automatisé des paiements. Risque porté par le marchand : impayés, recouvrement.
### Mode externalisé : BNPL B2B
Solutions type Pledg B2B, Hokodo, Defacto, Mondu, Resolve, Treezor for Business : assurance crédit, validation instantanée, paiement marchand immédiat, recouvrement délégué. Commission 1,5 % à 4 % du montant. Mature en 2026 : plusieurs solutions ont des connecteurs PrestaShop directs.
Pour un volume B2B significatif (> 100 K€ / mois en différé), le BNPL B2B est presque toujours rentable : il libère la trésorerie et supprime le risque d'impayé. En-dessous, le différé interne reste raisonnable.
## Brique 6 — Catalogue restreint et expérience pro
Cas fréquent : on a un catalogue partagé B2C + B2B, mais on veut que les pros voient des références qui leur sont propres (lots, conditionnements). Solutions :
- **Catégories réservées** aux groupes pro (option native PrestaShop). Suffisant pour la majorité des cas.
- **Catalogue dédié par groupe** avec produits visibles uniquement par certains groupes : géré via les onglets « accès » dans la fiche produit.
- **Multi-boutique** avec une boutique B2B distincte sous la même installation. Lourd à maintenir mais robuste si les deux mondes divergent fortement.
## Brique 7 — Commande rapide et import CSV
Un acheteur pro qui commande 80 références à chaque commande mensuelle n'a pas envie de naviguer le catalogue. Ce qu'il veut : un champ « tapez la référence ou collez votre liste », et hop, panier rempli. Deux fonctionnalités à ajouter via module :
- Saisie rapide par référence (autocomplete sur SKU ou EAN).
- Import CSV ou collage tableur : une ligne = SKU + quantité.
Ces deux fonctionnalités, isolément, gagnent 30 à 50 % de temps de commande aux acheteurs pros et augmentent significativement la fidélité (l'acheteur ne va pas changer de plateforme s'il a investi sa procédure de commande dans la vôtre).
## Brique 8 — Facturation, bons de livraison, comptabilité
Le natif PrestaShop génère facture et bon de livraison PDF, mais le rendu est parfois rustique et la conformité comptable française demande quelques ajustements (mentions obligatoires, gestion des avoirs, numérotation continue, archivage conforme loi anti-fraude TVA depuis 2018).
Pour la majorité des marchands B2B, l'approche pertinente est :
- Génération facture PDF via PrestaShop, avec template personnalisé pour respecter les mentions obligatoires françaises.
- Export comptable périodique vers le logiciel comptable du marchand ou de son expert-comptable (CSV au format FEC, ou connecteur direct vers Pennylane, Sage, Cegid, Quadra…).
- Archivage conforme : sauvegardes mensuelles, chiffrement, conservation 10 ans pour les factures.
## Stack B2B PrestaShop type — récapitulatif
Pour une PME française qui veut se lancer en B2B sur PrestaShop 8 en 2026, le stack minimal viable se compose de :
1. Formulaire d'inscription pro avec validation SIRET/VIES.
2. Groupes clients et règles de prix par groupe (natif).
3. Module multi-utilisateurs ou convention compte partagé.
4. Module pro forma type dfproforma pour le workflow devis.
5. Mode de paiement « facture à 30 jours » ou BNPL B2B selon le volume.
6. Module de saisie rapide par référence.
7. Template facture PDF conforme.
8. Export comptable périodique.
Budget réaliste pour assembler le tout : 3 000 à 8 000 € de modules + 5 à 15 jours de paramétrage et tests. Très loin des budgets Adobe Commerce ou Shopify Plus pour un périmètre fonctionnel équivalent.
## Conclusion : PrestaShop est une plateforme B2B sous-estimée
Le récit dominant dit que « PrestaShop, c'est pour le B2C ». C'est faux en 2026. À l'exception des cas très complexes (catalogues à plusieurs centaines de milliers de SKU, workflows d'approbation multi-niveaux, intégration ERP profonde), PrestaShop 8 et 9 couvrent confortablement la majorité des besoins B2B PME et ETI.
L'enjeu n'est pas la plateforme : c'est l'assemblage cohérent des briques. Une boutique PrestaShop bien équipée en B2B fait jeu égal avec une boutique BigCommerce ou Shopify B2B, à un tiers du coût total de possession, et avec une maîtrise complète des données et de la roadmap.
Pour passer à l'action : [notre sélection de modules pour vendre en B2B](https://www.datafirefly.com/solutions/prestashop/vente-b2b/) et [celle dédiée à la facturation et au recouvrement B2B](https://www.datafirefly.com/solutions/prestashop/facturation-recouvrement-b2b/).
---
### Droit à l'oubli RGPD article 17 sur PrestaShop : suppression de compte sans casser la trace fiscale en 2026
_Source :_ — _publié_ 2026-05-23
> L'article 17 RGPD impose le droit à l'oubli. Le code de commerce impose 10 ans de conservation des données comptables. Comment satisfaire les deux simultanément sur une boutique PrestaShop ou WooCommerce ? Pseudonymisation sélective, cartographie des données, pont avec le FEC, audit log conforme. Le workflow qui ne casse ni la conformité RGPD ni la trace fiscale.
## L'article 17 RGPD : une obligation simple à formuler, complexe à exécuter
« Le client peut demander la suppression de ses données ». La phrase est lapidaire dans l'article 17 du RGPD. Sa mise en œuvre sur une boutique PrestaShop ou WooCommerce qui a 5 ans d'existence est tout sauf simple. Parce qu'une « suppression de compte » bien faite doit naviguer entre quatre exigences contradictoires :
- Le droit à l'oubli du client (RGPD article 17).
- L'obligation de conservation comptable de 10 ans (code de commerce L.123-22).
- La traçabilité fiscale des ventes (CGI, FEC).
- Le droit de réponse à un litige éventuel (Code de la consommation, garanties légales jusqu'à 2 ans après l'achat).
L'enjeu pratique : un module qui supprime tout brutalement met l'entreprise en infraction comptable. Un module qui ne supprime rien met l'entreprise en infraction RGPD (sanction jusqu'à 4 % du CA mondial). La bonne pratique, c'est la **pseudonymisation sélective** — supprimer ce qui n'est pas nécessaire à une obligation légale, conserver le reste sous une forme non rattachable à une personne identifiée.
## Ce que l'article 17 RGPD dit exactement
L'article 17.1 énumère six motifs qui justifient la demande de suppression :
1. Les données ne sont plus nécessaires à la finalité pour laquelle elles ont été collectées.
2. La personne retire son consentement et il n'existe pas d'autre fondement juridique.
3. La personne s'oppose au traitement et il n'existe pas de motif légitime impérieux.
4. Les données ont fait l'objet d'un traitement illicite.
5. Les données doivent être effacées pour respecter une obligation légale.
6. Les données ont été collectées dans le cadre de l'offre de services à un enfant.
Mais l'article 17.3 prévoit cinq exceptions qui s'appliquent fréquemment au e-commerce :
1. Exercice de la liberté d'expression et d'information.
2. **Respect d'une obligation légale (par exemple : conservation comptable).**
3. Motif d'intérêt public dans le domaine de la santé publique.
4. Fins archivistiques, recherche scientifique ou historique, statistiques.
5. Constatation, exercice ou défense de droits en justice.
L'exception (b) — obligation légale — est celle qui s'applique aux données comptables. Mais elle ne couvre **pas** toutes les données d'un compte client : seulement celles strictement nécessaires à la tenue de la comptabilité et au respect de la durée de conservation (10 ans).
## Cartographier les données d'un compte client
Sur une boutique PrestaShop avec 5 ans d'historique, un compte client contient typiquement :
Catégorie de donnéeExemplesSuppression article 17Conservation légaleIdentificationnom, prénom, email, téléphonePseudonymiser10 ans (compta)Adresseslivraison, facturationConserver adresse de facturation, supprimer livraison ancienne10 ans pour facturationCommandesnuméro, date, montants, itemsConserver10 ans (compta) + 2 ans (garantie légale)Paiementstokens Stripe/PayPal, derniers chiffresSupprimer si plus utilisésPas obligation, mais utile pour litigeMots de passehash bcryptSupprimer immédiatementAucunePréférencesnewsletter, marketing, cookiesSupprimerAucune (sauf preuve de consentement utile 3 ans)Historique de navigationlogs visites, paniers abandonnésSupprimerAucuneAvis et commentairesavis produits, messages SAVAnonymiser (« Client anonyme »)Variable selon affichage publicProgramme fidélitépoints, statutsSupprimerAucuneWishlistproduits favorisSupprimerAucune
La règle de tri : **est-ce que cette donnée est nécessaire à la trace comptable ou à un éventuel litige ?** Si oui, on conserve sous forme pseudonymisée. Si non, on supprime.
## Pseudonymisation : le mécanisme central
Pseudonymiser, ce n'est pas anonymiser. La différence est juridique et technique :
- **Anonymisation** : suppression irréversible du lien entre la donnée et la personne. La donnée ne peut plus jamais être rattachée. **L'anonymisation sort la donnée du périmètre RGPD.**
- **Pseudonymisation** : remplacement des identifiants directs par un pseudonyme, mais le lien reste théoriquement reconstructible (par exemple via une table de correspondance chiffrée). La donnée **reste dans le périmètre RGPD**, mais le traitement est considéré comme moins risqué.
Pour le e-commerce, on vise généralement une **pseudonymisation forte** qui s'apparente à de l'anonymisation pratique :
- `customer.firstname` → `"Client"`
- `customer.lastname` → `"#" + id_customer` (ex. `"#42851"`)
- `customer.email` → `"deleted-" + id_customer + "@invalid"` (préfixe spécial, domaine invalide)
- `customer.phone` → NULL
- `customer.passwd` → bytes aléatoires (compte effectivement inutilisable)
- `customer.note` → NULL
- `address.firstname`, `address.lastname` sur adresses anciennes → pseudonyme
- `address.firstname`, `address.lastname` sur l'adresse de facturation des commandes existantes → **conserver** (nécessaire à la facture)
La clé est dans la nuance : on garde la facture telle qu'elle a été émise (obligation comptable), mais on supprime tout ce qui ne sert plus.
## Architecture d'un module de suppression conforme
Un module sérieux pour PrestaShop comme [DfAccountDelete](https://www.datafirefly.com/product/dfaccountdelete-suppression-compte-rgpd/) implémente cinq couches :
### Couche 1 — Identification de la demande
Trois canaux possibles :
- **Bouton dans l'espace client** — « Supprimer mon compte » accessible depuis « Mes informations ». UX du self-service.
- **Formulaire de demande** — pour les anciens clients qui ne peuvent plus se connecter. Vérification d'identité par email avec lien de confirmation.
- **Demande au DPO/contact RGPD** — par email ou courrier, traitée manuellement avec retranscription dans le système.
### Couche 2 — Vérification d'identité
Avant suppression, on vérifie que la personne est bien titulaire du compte. Pour les clients connectés : le fait d'être connecté + saisie du mot de passe ou validation par email (magic link bis). Pour les clients non connectés : envoi d'un email de confirmation avec un lien de validation single-use à durée limitée (1 heure typiquement). Pour les demandes par courrier : copie d'une pièce d'identité conservée 1 an puis détruite.
### Couche 3 — Délai de réflexion
Optionnel mais recommandé : un délai de 7 à 30 jours entre la demande et l'exécution effective. L'utilisateur reçoit un email « votre demande sera traitée le [date], cliquez ici pour annuler ». Cela évite les suppressions accidentelles et les regrets. C'est une bonne pratique CNIL.
### Couche 4 — Exécution de la pseudonymisation
Le module exécute en transaction MySQL atomique :
1. Pseudonymise `ps_customer` (nom, email, téléphone, etc.).
2. Pseudonymise les `ps_address` non rattachées à des commandes finalisées.
3. Supprime `ps_cart` abandonnés, `ps_compare`, `ps_wishlist`.
4. Supprime les entrées de programme fidélité, alertes prix, alertes stock.
5. Anonymise les avis publics (`« Client anonyme »`) ou les supprime selon la politique.
6. Supprime les logs de session, tokens magic link, paniers sauvegardés.
7. Supprime les abonnements newsletter (et propage à Mailchimp, Brevo via API si connecté).
8. Marque le compte comme supprimé (`active=0`, `deleted=1`, `deleted_at` = now).
9. Conserve **intactes** les commandes, factures, avoirs (`ps_orders`, `ps_order_invoice`, `ps_order_slip`).
### Couche 5 — Audit log et notification
Une entrée dans un journal d'audit RGPD :
- Date de la demande, date de l'exécution.
- Email d'origine (avant pseudonymisation).
- ID client.
- Méthode de vérification d'identité.
- Liste des tables touchées et nombre de lignes affectées.
Ce log est conservé 3 ans (durée recommandée par la CNIL pour démontrer la conformité). Il sert en cas d'inspection CNIL ou de demande de la personne (« avez-vous vraiment supprimé mes données ? »).
Un email de confirmation est envoyé à l'adresse d'origine, avec mention que les données ont été supprimées sauf celles nécessaires à la comptabilité (transparence article 12 RGPD).
## Le pont avec le FEC : ce qu'il faut absolument préserver
Comme expliqué dans [notre article sur le FEC et l'export comptable](https://www.datafirefly.com/2026/05/25/fec-export-comptable-ecommerce-woocommerce-prestashop-conformite-fiscale-2026/), certaines données sont nécessaires à la production d'un FEC conforme :
- **Identification du client** sur la facture émise (nom + adresse de facturation au moment de l'émission). Mais on n'a **pas besoin** que ce nom soit toujours retrouvable depuis la base clients vivante — il est dans la facture PDF archivée et dans `ps_orders`.
- **Montants HT, TVA, port, total TTC** — données comptables pures, à conserver intactes.
- **Date de la commande, de la facture, du paiement** — idem.
- **Méthode de paiement (Stripe, PayPal, virement)** — utile pour le rapprochement bancaire.
Le pattern pratique : on pseudonymise `ps_customer`, mais on laisse `ps_orders.firstname`, `ps_orders.lastname`, `ps_orders.email` tels qu'ils étaient au moment de la commande. C'est ce qui apparaît sur la facture émise. La facture est l'enregistrement comptable, immuable. Le compte client est un agrégat vivant, qu'on peut anonymiser.
Sur PrestaShop, cette logique est facilitée par le fait que la facture est gérée par `ps_order_invoice` avec ses propres champs (le nom n'est pas seulement référencé par `id_customer`, il est aussi figé dans la commande). Sur WooCommerce, c'est plus délicat : les _orders_ WC stockent l'_customer ID_ et reconstruisent les infos à l'affichage. Il faut donc figer le nom et l'adresse de facturation sur l'order au moment de la pseudonymisation, sinon la facture régénérée affiche « Client anonyme ».
## Les avis et commentaires : un cas à part
Un avis produit affiché publiquement avec le nom du client est une donnée personnelle (article 4 RGPD). Sa suppression à la demande pose deux problèmes :
- Le contenu de l'avis a une valeur pour les autres clients (information consommateur).
- L'historique des avis sert à la moyenne de notation.
La résolution juridique standard : anonymiser le nom (« Client anonyme » ou « C.A. »), conserver le contenu de l'avis et la note. C'est un traitement _statistique_ au sens de l'article 17.3.d. Si le client demande explicitement la suppression complète de l'avis (« je ne veux plus que ce texte existe »), alors on supprime entièrement, mais on peut ré-évaluer la moyenne sans la donnée perdue.
Cette nuance doit être présentée à l'utilisateur dans le formulaire : _« Voulez-vous supprimer vos avis ou les rendre anonymes ? »_.
## Cas particuliers difficiles
### Compte client avec un litige en cours
Si une commande est en litige (retour bloqué, contestation, action en garantie), la suppression des données du client compromet la défense de l'entreprise. Article 17.3.e couvre ce cas : on peut **refuser** la suppression jusqu'à résolution du litige, en informant le client de cette raison. La conservation se fait sous statut « en litige », avec accès restreint.
### Compte B2B avec multi-utilisateurs
Sur un compte [B2B avec plusieurs utilisateurs](https://www.datafirefly.com/2026/05/25/b2b-prestashop-comptes-pros-devis-paiement-differe-kyb-2026/), la suppression du compte d'un utilisateur ne doit pas supprimer la société. On supprime l'utilisateur (qui a un droit individuel), on conserve les commandes au nom de la société (qui n'a pas de droit à l'oubli, étant une personne morale).
### Newsletter sans compte (anonyme)
Un email inscrit à la newsletter sans compte client : la suppression est immédiate, sans pseudonymisation. Pas d'obligation comptable rattachée. Une exception : si le consentement marketing est tracé pour preuve, on peut conserver l'historique du consentement (date, IP, opt-in) pendant 3 ans après désinscription. Au-delà, suppression complète.
### Abonnés à un service récurrent (abonnement)
Pour les boutiques [en abonnement](https://www.datafirefly.com/expertise/woocommerce-abonnements/), la suppression du compte exige d'abord l'arrêt de l'abonnement (impossible de débiter une carte d'un compte qui n'existe plus). Le module doit séquencer : annulation des abonnements → attente d'un cycle pour confirmation → pseudonymisation. Skipper la séquence cause des débits orphelins et des contentieux clients.
## Le délai de réponse imposé par le RGPD
Article 12.3 RGPD : la réponse à une demande doit intervenir **sous 1 mois**, prolongeable à 2 ou 3 mois pour les demandes complexes (avec notification de la prolongation au demandeur). En pratique pour le e-commerce :
- Demande simple via le bouton « supprimer mon compte » : exécution immédiate (selon délai de réflexion optionnel) — bien en deçà du délai légal.
- Demande par email/courrier qui exige une vérification d'identité : 1 à 2 semaines de traitement, en deçà du mois.
- Demande dans un contexte complexe (litige, abonnement actif, multi-comptes) : 1 mois avec information du demandeur du statut.
Le non-respect du délai expose à des sanctions CNIL. Un module automatisé qui répond sous 24-48 h couvre largement le risque.
## Coût et ROI
Le ROI d'un module de suppression de compte conforme se mesure différemment d'un module de conversion :
- **Coût du module** : [39 € licence pour PrestaShop](https://www.datafirefly.com/product/dfaccountdelete-suppression-compte-rgpd/).
- **Coût évité d'une sanction CNIL** : variable, mais les sanctions e-commerce 2023-2025 vont de 5 000 € pour PME à plusieurs millions pour les grandes enseignes. Le ratio coût/risque est extrêmement favorable.
- **Coût évité de retraitement manuel** : sur une boutique de 50 000 clients, traiter 5 à 10 demandes/mois manuellement représente 2 à 4 h/mois de travail interne — environ 1 200 €/an.
- **Bénéfice de confiance** : afficher un bouton « supprimer mon compte » bien visible est devenu un signal de confiance fort en 2026, mesurable en taux de création de compte (+3 à 6 % observé).
## FAQ
### Faut-il vraiment garder les commandes 10 ans après suppression du compte ?
Oui, c'est l'obligation comptable (code de commerce L.123-22). Le RGPD ne dispense pas du droit fiscal. La résolution : les commandes restent en base sous forme pseudonymisée (le nom du client n'est plus rattaché à un compte vivant mais figure encore sur la facture émise, comme c'est nécessaire). À l'issue des 10 ans, suppression complète possible.
### Que faire si Mailchimp ou Brevo continue d'envoyer la newsletter ?
Le RGPD article 19 impose la propagation de la suppression aux destinataires des données. Si vous avez synchronisé votre base avec Mailchimp/Brevo/Klaviyo, le module doit appeler leur API pour supprimer le contact (et pas seulement le désabonner). C'est un point à valider à l'installation : tous les connecteurs marketing doivent recevoir le signal de suppression.
### Comment gérer la suppression chez les sous-traitants (Stripe, PayPal) ?
Stripe et PayPal conservent les tokens de paiement et l'historique des transactions selon **leur** politique (généralement 10 ans pour conformité fiscale + lutte anti-blanchiment). Vous ne pouvez pas forcer leur suppression — c'est leur obligation légale, distincte de la vôtre. La mention dans votre politique de confidentialité doit indiquer que les sous-traitants de paiement conservent les données selon leur propre durée légale.
### Peut-on supprimer un compte sans en informer le client ?
Si c'est _le client_ qui a demandé la suppression : on l'informe de l'exécution. Si c'est l'entreprise qui supprime à son initiative (inactivité prolongée, par exemple) : on doit avoir prévu cette politique dans les CGV/politique de confidentialité, et idéalement notifier 30 jours avant suppression pour permettre l'opposition. La suppression sans notification est risquée.
### Combien de temps après une demande d'oubli un client peut-il revenir vers nous ?
Le droit à l'oubli n'est pas un droit à l'inversion. Une fois les données supprimées (ou pseudonymisées), le client qui revient crée un nouveau compte ex nihilo. L'historique reste dans l'audit log RGPD (qui sert à prouver qu'on a exécuté la demande), mais ne peut pas être réutilisé pour reconstituer le compte initial.
## En synthèse
La suppression de compte conforme à l'article 17 RGPD est un exercice d'équilibrisme entre quatre obligations légales contradictoires. La résolution passe par la pseudonymisation sélective : on supprime ou anonymise tout ce qui n'est pas couvert par une obligation de conservation, on conserve intactement la trace comptable nécessaire au FEC et au contrôle fiscal.
Le [module DfAccountDelete pour PrestaShop](https://www.datafirefly.com/product/dfaccountdelete-suppression-compte-rgpd/) implémente cette logique avec les cinq couches d'un workflow conforme : identification, vérification d'identité, délai de réflexion optionnel, pseudonymisation atomique, audit log. Il s'intègre avec l'export FEC pour ne pas casser la chaîne comptable et avec les principaux outils marketing (Mailchimp, Brevo, Klaviyo) pour propager la suppression.
Le bon réflexe en 2026 : afficher un bouton « supprimer mon compte » bien visible dans l'espace client (signal de confiance, conformité explicite), documenter le workflow dans la politique de confidentialité (transparence article 12), conserver l'audit log 3 ans pour démontrer la conformité en cas d'inspection CNIL.
Pour les boutiques qui souhaitent un audit complet de leur conformité RGPD, [notre audit PrestaShop](https://www.datafirefly.com/expertise/audit-prestashop/) couvre les six points critiques : cookies et consentement, base de traitement des données clients, durées de conservation paramétrées, droit à l'accès et à la portabilité, droit à l'oubli, registre des traitements article 30.
Pour passer à l'action : [notre sélection de modules pour le RGPD et les cookies](https://www.datafirefly.com/solutions/prestashop/rgpd-cookies/).
---
### AEO pour e-commerce en 2026 : comment optimiser PrestaShop 8 pour ChatGPT, Perplexity et Google AI Overviews
_Source :_ — _publié_ 2026-05-21
> L'AEO est le successeur logique du SEO en 2026 : optimiser pour ChatGPT, Perplexity, Claude, et Google AI Overviews. Voici les techniques qui marchent vraiment sur PrestaShop 8 — llms.txt, FAQ Schema, marquage Review — et celles qui sont du marketing creux.
En 2026, une part significative et croissante des recherches commerciales ne passe plus par Google search classique. Les acheteurs interrogent ChatGPT (« quels sont les meilleurs modules d'avis pour PrestaShop »), Perplexity (« compare-moi tel et tel produit »), Claude, et consultent les Google AI Overviews qui s'affichent au-dessus des résultats classiques. Ce n'est plus un sujet émergent — c'est un canal de découverte commercial à part entière, qui rivalise avec la SERP traditionnelle.
Le problème pour les marchands e-commerce : ces Answer Engines ne fonctionnent pas comme Google search. Ils ne renvoient pas une liste de liens à cliquer ; ils synthétisent une réponse. Si votre boutique n'est pas _citable_ par ces moteurs, vous êtes invisible. Optimiser pour eux, c'est l'AEO (Answer Engine Optimization) — le successeur logique du SEO, ou plutôt sa nouvelle couche superposée. Cet article détaille comment optimiser une boutique PrestaShop 8 pour l'AEO en 2026, avec les techniques qui marchent réellement et celles qui sont du marketing creux.
## De SEO à AEO : ce qui change en 2026
Le SEO classique optimise pour le ranking dans une SERP de liens. Les leviers : mots-clés, backlinks, performance, structure, intent matching. L'utilisateur lit une liste de résultats, choisit un lien, atterrit sur une page.
L'AEO optimise pour la _citation_ dans une réponse synthétique générée par un Answer Engine. Les leviers sont en partie les mêmes (autorité, qualité de contenu, structure) mais avec une exigence supplémentaire : votre contenu doit être **extractible** et **citable** par un LLM qui synthétise une réponse en 200-500 mots. Les pages qui marchent en SEO ne marchent pas automatiquement en AEO, et inversement.
Trois différences fondamentales :
**L'unité d'extraction est plus petite.** En SEO, Google indexe et classe une page entière. En AEO, le LLM extrait des morceaux de contenu (paragraphes, listes, tableaux, FAQ) qu'il intègre à sa réponse synthétisée. Une page longue avec un paragraphe pertinent sur le sujet exact de la requête peut être citée même si le reste de la page est hors-sujet.
**La structure compte plus que jamais.** Les LLM sont entraînés à reconnaître des structures (FAQ, listes à puces, tableaux comparatifs, données structurées Schema.org). Un contenu non structuré, même de qualité, est moins facilement extractible. Cela explique pourquoi les FAQ marquées Schema.org performent bien sur AEO — elles sont littéralement des paires question-réponse prêtes à être réutilisées.
**L'autorité se mesure différemment.** En SEO, l'autorité passe par les backlinks et signaux externes. En AEO, l'autorité passe aussi par la cohérence du discours sur l'ensemble de votre site (les LLM remarquent quand vos pages se contredisent), et par la présence dans les corpus d'entraînement (Common Crawl, données licenciées).
## Comment les Answer Engines lisent réellement votre catalogue produit
Trois mécanismes coexistent pour qu'un Answer Engine connaisse votre catalogue.
**Le crawl direct.** Comme Googlebot, les bots des Answer Engines (GPTBot pour OpenAI, ClaudeBot pour Anthropic, PerplexityBot, etc.) visitent votre site régulièrement et indexent le contenu accessible. Vérifiez votre `robots.txt` — beaucoup de boutiques bloquent par défaut ces bots sans s'en rendre compte, ce qui les rend invisibles pour les Answer Engines.
**Le retrieval-augmented generation (RAG) en temps réel.** Quand un utilisateur pose une question à ChatGPT ou Perplexity, le moteur peut faire une recherche web en temps réel et lire les pages les plus pertinentes pour synthétiser sa réponse. Vos pages doivent donc être indexées par les moteurs de recherche classiques (Google, Bing) que ces Answer Engines utilisent en backend.
**Les corpus d'entraînement.** Les LLM sont entraînés sur des dumps massifs du web (Common Crawl, contenu licencié, sources éditoriales). Une fois entraînés, ils contiennent des connaissances figées à leur date de cutoff — votre boutique, si elle est suffisamment ancienne et indexée, est probablement déjà dans le savoir « par cœur » de ces modèles, même sans crawl en temps réel.
L'AEO efficace travaille les trois canaux en parallèle : autoriser les bots dans robots.txt, structurer le contenu pour le RAG, et publier régulièrement du contenu éditorial qui finira dans les futurs corpus d'entraînement.
## Le format LLMs.txt : le nouveau standard 2025-2026
En 2024, Jeremy Howard a proposé une convention : le fichier `/llms.txt` à la racine du site, qui décrit la structure du site dans un format optimisé pour la lecture par LLM (markdown structuré, liens vers les pages clés, contexte synthétique). Le format a été rapidement adopté par les Answer Engines majeurs comme un signal de structure et d'autorité.
Pour une boutique e-commerce, un `llms.txt` bien construit décrit :
- l'identité de la boutique (nom, secteur, USP) ;
- les principales catégories de produits (avec liens) ;
- les pages éditoriales clés (blog, guides, FAQ générale) ;
- les pages de support (contact, livraison, retour) ;
- optionnellement, un lien vers un `llms-full.txt` qui contient l'intégralité du contenu en format markdown synthétisé.
Les Answer Engines lisent ce fichier en priorité quand ils découvrent votre site, et l'utilisent pour structurer leur compréhension. Une boutique avec llms.txt bien construit est citée plus précisément qu'une boutique sans, sur les requêtes commerciales et informationnelles liées à son catalogue.
Sur PrestaShop 8, générer et maintenir le llms.txt manuellement est viable pour les petits catalogues (50 produits) mais devient ingérable au-delà. Notre [module LLMs.txt PrestaShop](/product/llms-txt-prestashop-seo-ia-chatgpt/) génère automatiquement le fichier à partir de votre catalogue, le met à jour en continu quand vos produits évoluent, et expose les options techniques (inclure/exclure certaines catégories, format synthétique vs détaillé). C'est aujourd'hui le moyen le plus rapide pour un marchand PrestaShop d'aligner sa boutique sur ce standard 2026.
**Un fichier llms.txt déjà en ligne ?** Avant de le publier — ou pour auditer celui que votre boutique expose déjà —, passez-le dans notre [testeur llms.txt gratuit](https://check-llms.datafirefly.com/) : il valide la structure (titre H1, blockquote de résumé, sections de liens), repère les liens morts et vous dit en quelques secondes ce qui empêche les Answer Engines de lire correctement votre site. Un réflexe à reprendre à chaque évolution majeure de votre catalogue.
## Schema.org étendu : la lingua franca des Answer Engines
Le marquage Schema.org reste central pour l'AEO. Les Answer Engines consomment massivement les données structurées pour comprendre vos pages. Sur une fiche produit e-commerce, le stack minimal est :
- **Product** : nom, marque, prix, devise, disponibilité, image, GTIN/EAN si possible.
- **Offer** : conditions commerciales, prix, devise, livraison, conditions de retour.
- **AggregateRating** : note moyenne, nombre d'avis (si vous en avez).
- **Review** : les avis individuels avec auteur, note, contenu.
- **FAQPage** : les questions/réponses contextuelles au produit.
- **BreadcrumbList** : la hiérarchie catégorielle.
L'erreur classique est d'avoir un Product Schema basique sans les autres marquages, ou d'avoir des marquages partiels incohérents (par exemple, prix dans Product différent du prix dans Offer). Les Answer Engines détectent ces incohérences et préfèrent ne pas citer une page suspect.
Sur PrestaShop 8, le Product Schema natif est minimal. Pour le compléter proprement, les modules [DataFirefly Avis Vérifiés](/product/datafirefly-avis-verifies-prestashop-8/) (qui ajoute AggregateRating + Review) et [DataFirefly FAQ IA Produit](/product/datafirefly-faq-ia-produit-prestashop-8/) (qui ajoute FAQPage) couvrent les trois marquages les plus impactants pour l'AEO. Combinés, ils transforment une fiche produit standard en page hautement citable par les Answer Engines.
## Les FAQ produit : le format favori des LLM
Sur les requêtes commerciales informationnelles (« est-ce que ce produit convient pour X »), les Answer Engines citent fréquemment les FAQ produit qu'ils trouvent sur les fiches. Plusieurs raisons :
D'abord, le format question-réponse correspond exactement à ce que le LLM doit produire. Une FAQ « est-ce que cette robe taille petit ou grand ? » avec sa réponse est directement réutilisable par le LLM dans sa synthèse, avec attribution à votre site.
Ensuite, les FAQ marquées Schema.org sont structurellement _extraites_ des pages — le LLM les voit comme des entités discrètes et indexables, pas comme des paragraphes noyés dans du texte continu.
Enfin, les FAQ produit reflètent les vraies questions des acheteurs. Ce sont les requêtes que les acheteurs futurs vont poser aux Answer Engines. La probabilité de match est mécaniquement plus élevée que sur du contenu marketing générique.
La condition pour que ce levier fonctionne est que les FAQ soient _spécifiques au produit_, pas génériques. Une FAQ « quels sont les délais de livraison ? » qui apparaît sur les 500 fiches de votre catalogue ne sert à rien — le LLM la voit comme un boilerplate sans valeur informationnelle. Une FAQ « cette chaise convient-elle à un usage extérieur ? » sur une fiche produit chaise, avec une réponse précise (matériaux, traitement, garantie outdoor), est exactement ce que le LLM cherche.
## Mesurer votre présence dans les Answer Engines
Mesurer l'AEO est plus difficile que mesurer le SEO classique. Il n'y a pas (encore) de Search Console pour Perplexity ou ChatGPT. Mais plusieurs signaux existent.
**Test manuel de citation.** Posez 10 questions commerciales typiques de votre secteur à ChatGPT, Perplexity, Claude, et Google AI Overviews. Notez si votre boutique apparaît dans les réponses, sous quelle forme (lien direct, mention de marque, citation de contenu précis). Refaites le test tous les 30 jours pour voir l'évolution. C'est qualitatif mais informatif.
**Trafic référent depuis les Answer Engines.** Dans GA4 ou votre outil analytics, surveillez les sources de trafic provenant de chat.openai.com, perplexity.ai, claude.ai, gemini.google.com. C'est encore marginal en volume sur la plupart des boutiques, mais la tendance 2024-2026 est clairement à la hausse. Une boutique qui a 0 % de trafic AEO en 2024 peut être à 5-10 % en 2026.
**Cohérence robots.txt et logs serveur.** Vérifiez que GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot apparaissent dans vos logs serveur (signes que les bots crawlent votre site) et qu'ils ne sont pas bloqués dans robots.txt. Si vous voulez explicitement autoriser ou bloquer certains bots, utilisez la syntaxe User-agent dans robots.txt.
**Outils dédiés émergents.** Des plateformes comme Profound, Otterly, ou des solutions custom commencent à proposer du « brand monitoring AEO » — surveiller automatiquement votre présence dans les réponses AI sur des centaines de prompts. Encore en phase précoce, mais ces outils vont se sophistiquer rapidement.
## Les pièges marketing de l'AEO en 2026
L'AEO étant un sujet hot, beaucoup d'acteurs vendent du conseil ou des outils sur la base de promesses qui ne tiennent pas la critique technique. Trois pièges typiques.
**« Optimisez votre contenu pour ChatGPT spécifiquement. »** Faux. Les techniques qui marchent (structure, FAQ, Schema.org, llms.txt) marchent pour tous les Answer Engines majeurs en parallèle. Optimiser « pour ChatGPT » ou « pour Perplexity » spécifiquement n'a pas de sens technique — vous optimisez pour les principes qu'ils partagent.
**« Achetez des backlinks dans des sites cités par les Answer Engines. »** Vente de service douteuse. Les Answer Engines sont moins sensibles aux backlinks que Google, et plus sensibles à la qualité intrinsèque du contenu. Acheter des backlinks pour l'AEO est de l'argent mal placé.
**« On va injecter du contenu caché spécifiquement pour les LLM. »** Pratique à risque. Les Answer Engines détectent (et pénalisent) le cloaking — afficher un contenu différent au LLM bot vs au visiteur humain. C'est l'équivalent moderne du keyword stuffing : ça marche brièvement, ça finit en dégradation à long terme.
L'AEO efficace est l'application disciplinée des techniques SEO modernes (structure, schema, performance, qualité éditoriale) avec quelques ajouts spécifiques (llms.txt, FAQ marquées, contenu extractible). Pas de magie ni de raccourci.
## Conclusion : l'AEO est une couche au-dessus du SEO, pas une révolution
L'AEO en 2026 n'invalide pas le SEO. Il en étend les principes pour une nouvelle classe de moteurs (Answer Engines) qui synthétisent au lieu de lister. Les boutiques qui font correctement leur SEO 2026 (structure, schema, performance, qualité) sont déjà bien positionnées sur l'AEO. Celles qui ajoutent les briques spécifiques (llms.txt, FAQ produit Schema, marquage Review étendu) prennent une avance de 6 à 18 mois sur leurs concurrents qui n'auront pas vu venir le sujet.
L'angle business : sur les requêtes commerciales, les Answer Engines remplaceront progressivement la SERP classique pour 20 à 40 % des recherches d'ici 2027-2028. Une boutique invisible aux Answer Engines en 2026 prend le risque structurel de perdre une part significative de son trafic découverte d'ici 2 ans. Investir dans l'AEO maintenant, c'est protéger sa visibilité future.
Pour creuser, parcourez nos catégories [AEO & Answer Engines](/category/aeo-answer-engines/) et [SEO E-commerce](/category/seo-ecommerce/). Et pour aligner votre boutique PrestaShop 8 sur les standards AEO 2026, le combo [LLMs.txt PrestaShop](/product/llms-txt-prestashop-seo-ia-chatgpt/) + [FAQ IA Produit](/product/datafirefly-faq-ia-produit-prestashop-8/) + [Avis Vérifiés](/product/datafirefly-avis-verifies-prestashop-8/) couvre les trois leviers les plus impactants — structure llms.txt, FAQ marquées par produit, et marquage Review étendu pour la citation.
À lire aussi : [le guide complet du SEO e-commerce](https://www.datafirefly.com/2026/05/01/seo-ecommerce-guide-complet-2026/), [comprendre l'AEO](https://www.datafirefly.com/2026/05/01/aeo-answer-engine-optimization-avenir-seo/) et [Schema.org Product en 2026](https://www.datafirefly.com/2026/07/20/schema-org-product-2026-hasmerchantreturnpolicy-shippingdetails-prestashop-woocommerce/).
Pour passer à l'action : [notre sélection de modules pour être visible dans ChatGPT sur PrestaShop](https://www.datafirefly.com/solutions/prestashop/referencement-ia-aeo/).
---
### PrestaShop 8 vs WooCommerce vs Shopware 6.7 : quel choix en 2026 selon votre profil de boutique
_Source :_ — _publié_ 2026-05-17
> Quelle plateforme e-commerce choisir en 2026 : PrestaShop 8, WooCommerce ou Shopware 6.7 ? Comparatif factuel sur 8 critères, écosystème de modules, et recommandations selon votre profil de boutique. Pas de gagnant universel — chacune a son terrain de pertinence.
« Quelle plateforme e-commerce choisir en 2026 ? » est probablement la question la plus tapée par les entrepreneurs qui démarrent une boutique, et la plus refoulée par ceux qui en ont déjà une. Le marché s'est restructuré : Shopify s'impose comme référence sur le SaaS, WooCommerce reste l'option pragmatique sur WordPress, PrestaShop résiste fort en Europe francophone et latine, et Shopware 6.7 s'est imposé en Allemagne et au-delà sur le segment professionnel exigeant. Magento (Adobe Commerce) reste pertinent uniquement sur les très gros catalogues B2B avec budget IT illimité.
Ce comparatif se concentre sur les trois plateformes qui posent un véritable choix pour la majorité des boutiques européennes en 2026 : **PrestaShop 8**, **WooCommerce**, et **Shopware 6.7**. Trois plateformes self-hosted (vous gérez votre code, vos données, vos modules), trois philosophies différentes, trois écosystèmes de modules qui ne se valent pas. L'angle est factuel et critique, sans mépris pour aucune des trois — chacune a son terrain de pertinence et ses pièges.
## Pourquoi la question se repose en 2026
Trois forces ont rebattu les cartes du choix de plateforme depuis 2023.
**La pression de Shopify.** Shopify a continué à grignoter des parts de marché en proposant un setup rapide pour les jeunes boutiques DTC. Beaucoup d'entrepreneurs démarrent sur Shopify et envisagent une migration vers du self-hosted seulement quand les coûts d'app récurrents deviennent dissuasifs (typiquement passé 50-100 K€ de CA mensuel). La question 2026 n'est plus « PrestaShop ou Shopify » mais « si je quitte Shopify, vers quoi je vais ? ».
**La maturité de Shopware 6.** Après les tâtonnements de la migration 6.0-6.4, Shopware 6.6 puis 6.7 (sortie 2024-2025) ont stabilisé une plateforme moderne en Symfony avec une admin Vue.js refondue, une architecture API-first, et un écosystème enterprise solide. Shopware est devenu une option crédible pour les boutiques qui auraient choisi Magento il y a 5 ans.
**L'évolution de PrestaShop.** PrestaShop 8 a apporté Symfony en back-office, modernisé l'API, et serré la conformité PHP 8.x. La compatibilité modules historiques (PrestaShop 1.7) reste un sujet, mais le catalogue moderne PS8 est riche, francophone, et bien maintenu. La plateforme garde son positionnement européen avec une particulière force en France, Espagne, Italie, Pologne.
Côté WooCommerce, l'évolution est plus lente. Le plugin reste solide sur sa promesse (e-commerce sur WordPress), mais l'expérience admin reste héritée de WordPress, et les performances sur gros catalogue (5000+ produits) sont un sujet récurrent. Le rachat par WPEngine en 2024 a inquiété une partie de la communauté ; depuis, l'engagement open source semble maintenu.
## PrestaShop 8 : le pragmatique européen
PrestaShop est né en France en 2007, et reste largement déployé en Europe latine et francophone. Avec PrestaShop 8 (sorti 2022, mis à jour régulièrement depuis), la plateforme offre un compromis solide entre richesse fonctionnelle native et flexibilité technique.
**Les forces.**
- Multi-boutique natif (plusieurs vitrines sur une seule instance, partage de catalogue) — différenciant fort vs WooCommerce.
- Multi-langue et multi-devise solides via le système natif, plus extension Polylang-like via certains modules tiers ([module hreflang](/product/module-hreflang-prestashop-8-balises-alternate-seo-multilingue-datafirefly/), [sélecteur de pays](/product/module-selecteur-de-pays-prestashop-8-drapeaux-cliquables-datafirefly/)).
- Catalogue de modules très riche, dont une part significative francophone — utile pour les boutiques qui veulent un support en français.
- Conformité TVA européenne (intracommunautaire, autoliquidation, OSS) intégrée avec moins de bricolage que sur Woo.
- Performance correcte sur catalogue moyen (1000-10 000 produits), avec cache Smarty + cache modules + cache HTTP serveur.
**Les faiblesses.**
- L'écosystème module est inégal : à côté de modules excellents, beaucoup d'anciens modules 1.7 mal portés sur PS8, parfois chiffrés (ioncube, source codée), rarement maintenus. La sélection demande un œil expert.
- L'admin reste hybride entre legacy Smarty et Symfony moderne — la transition est inachevée. Certaines pages admin sont rapides et modernes, d'autres restent lentes et datées.
- Les performances sur très gros catalogue (50 000+ produits) demandent une optimisation avancée (Elasticsearch, Varnish, archi multi-serveur). Ce n'est pas le sweet spot de la plateforme.
- L'API REST est fonctionnelle mais moins moderne que Shopware ou Shopify — moins adaptée aux usages headless/PWA.
**Pour qui c'est fait.** Les boutiques européennes (France et Europe latine surtout) avec un catalogue de 100 à 10 000 produits, qui veulent un compromis self-hosted maîtrisable sans budget illimité. Idéal pour les marchands qui veulent du multi-boutique sans usine à gaz et un support francophone.
## WooCommerce : le polyvalent WordPress-natif
WooCommerce est un plugin e-commerce sur WordPress, gratuit, open source, qui transforme un site WordPress en boutique. C'est la plateforme la plus déployée au monde en volume — plus de 30 % des sites e-commerce mondiaux selon W3Techs.
**Les forces.**
- Intégration native dans l'écosystème WordPress, qui reste le CMS le plus utilisé pour les sites de contenu. Idéal si votre boutique est aussi un blog, un média, ou un site éditorial.
- Catalogue d'extensions WordPress + WooCommerce considérable, dont beaucoup gratuits ou à coût faible. Couverture fonctionnelle excellente sur les sujets standards.
- Courbe d'apprentissage admin très douce pour les utilisateurs déjà familiers de WordPress.
- Coût initial très bas (le plugin est gratuit, hébergement WordPress souvent partagé suffisant pour démarrer).
- Excellent SEO natif via WordPress + extensions Yoast / Rank Math, particulièrement fort pour les boutiques avec stratégie content-marketing forte.
**Les faiblesses.**
- Performances qui décrochent au-delà de 10 000 produits sans architecture spécifique (custom DB queries, cache HTTP avancé, hosting WP managed). Le sweet spot reste les boutiques de petite à moyenne taille.
- Multi-boutique non natif — il faut WP Multisite + extensions WooCommerce dédiées, le tout fragile et peu adopté.
- Conformité TVA européenne fonctionnelle mais demande des extensions (gestion des taux par pays, OSS, factures intracommunautaires). Plus de bricolage que sur PrestaShop.
- Sécurité dépendante de la maintenance WordPress (et de tous les plugins installés). Une maintenance laxiste expose à des failles.
- Architecture héritée de WordPress (custom post types pour les produits, taxonomies pour les catégories) qui rend certaines optimisations e-commerce contre-intuitives.
**Pour qui c'est fait.** Les boutiques avec composante éditoriale forte (blog, média, contenu marketing premium), les jeunes boutiques au budget contraint qui veulent démarrer vite, et les marchands déjà à l'aise avec WordPress qui ne veulent pas apprendre une nouvelle plateforme. Moins adapté aux gros catalogues, au B2B avancé, et au multi-boutique réel.
## Shopware 6.7 : le challenger DACH
Shopware est née en Allemagne en 2003, et la version 6 (lancée en 2019, refondue depuis) marque la rupture avec l'ancienne v5 PHP procédural. Shopware 6.7 (mises à jour 2025-2026) est une plateforme Symfony moderne, API-first, avec une admin Vue.js soignée.
**Les forces.**
- Architecture moderne : Symfony côté back, Vue.js côté admin, Twig + Bootstrap 5 côté storefront. Code propre, conventions claires, bonne séparation des couches.
- API-first par design : tout le back est exposé via API, ce qui rend les intégrations headless / PWA / mobile beaucoup plus naturelles que sur PrestaShop ou WooCommerce.
- Performance native solide grâce à OpenSearch (ex-Elasticsearch) intégré pour le catalogue, cache HTTP Symfony, et architecture qui scale bien jusqu'aux gros catalogues (50 000-100 000 produits).
- Écosystème enterprise mature, particulièrement fort sur le marché DACH (Allemagne, Autriche, Suisse). De plus en plus présent en France, UK, Pays-Bas.
- B2B natif via l'extension B2B Suite (payante en édition Enterprise), qui couvre comptes clients hiérarchiques, devis, prix par client, workflows d'approbation.
**Les faiblesses.**
- Catalogue de plugins moins large que PrestaShop ou WooCommerce, particulièrement pour les besoins très spécifiques. La couverture fonctionnelle de base est excellente, mais les niches sont parfois découvertes.
- Communauté francophone plus restreinte — la documentation et la majorité des plugins sont d'abord en allemand et anglais. Notre [plugin DataFirefly Dark Mode pour Shopware 6.7](/product/datafirefly-dark-mode-shopware-6/) est l'un des rares disponibles en français à ce jour.
- Édition Community gratuite limitée vs édition Professional (payante, à partir de ~600 €/an) ou Enterprise. Certaines fonctionnalités avancées (B2B Suite, Rule Builder avancé, multi-shop sophistiqué) sont en payant uniquement.
- Courbe d'apprentissage plus raide pour les développeurs qui viennent de PrestaShop 1.7 ou de WordPress — Symfony, Vue.js, Twig, conventions Shopware spécifiques.
- Hosting plus exigeant : Shopware 6.7 demande PHP 8.2+, MySQL 8 ou MariaDB 11 LTS, OpenSearch 2.19+, Node.js récent. Pas un hébergement mutualisé bas de gamme.
**Pour qui c'est fait.** Les boutiques B2B exigeantes avec besoins d'API et d'intégrations (ERP, CRM, PIM), les marques DTC ambitieuses qui veulent une plateforme qui scale, et les projets headless / PWA. Particulièrement adapté aux acheteurs qui veulent une plateforme moderne sans aller chez Shopify, et aux entreprises qui privilégient un écosystème allemand/européen.
## Comparatif factuel sur 8 critères
Synthèse comparative sur les critères qui décident le plus souvent du choix.
**1. Coût de démarrage.** WooCommerce le plus bas (plugin gratuit, hosting WP partagé). PrestaShop intermédiaire (gratuit mais hosting plus exigeant + thème souvent payant). Shopware le plus haut (Community gratuite mais souvent insuffisante, Professional 600 €/an, hosting solide nécessaire).
**2. Coût d'exploitation à 5 ans.** Plus mitigé. WooCommerce peut être très bas si maintenance interne, mais grimpe vite avec extensions premium accumulées. PrestaShop intermédiaire avec coût modules récurrent. Shopware élevé en Pro/Enterprise mais inclus beaucoup en standard.
**3. Performance sur 10 000 produits.** Shopware en tête (OpenSearch natif, archi pensée pour). PrestaShop correct avec optimisation sérieuse. WooCommerce demande beaucoup d'effort pour rester rapide à ce volume.
**4. Multi-langue / multi-pays.** PrestaShop natif et bien fait. Shopware natif via Sales Channels (concept proche du multi-boutique). WooCommerce via plugins (WPML, Polylang) — fonctionnel mais plus de bricolage.
**5. Multi-boutique réel.** PrestaShop le meilleur (multi-shop natif sans bricolage). Shopware via Sales Channels (puissant, bien pensé). WooCommerce via WP Multisite (techniquement possible, mais lourd à opérer).
**6. Écosystème de modules / plugins.** WooCommerce le plus large (héritage WordPress). PrestaShop riche mais qualité variable. Shopware plus restreint mais qualité moyenne plus élevée.
**7. API et headless.** Shopware l'option par défaut pour le headless (API-first). PrestaShop API correcte mais moins moderne. WooCommerce API REST + GraphQL via plugins, fonctionnelle mais moins idiomatique.
**8. Conformité européenne (RGPD, TVA, mentions).** PrestaShop nativement très solide (origines françaises). Shopware excellent (origines allemandes). WooCommerce demande plugins additionnels mais y arrive.
## Le critère caché : la qualité de l'écosystème de modules
Un critère que personne n'évalue sérieusement avant de choisir, et qui détermine pourtant la moitié de la qualité de l'expérience à 18 mois : **la qualité moyenne des modules** que vous allez installer pour combler les fonctionnalités manquantes.
Sur PrestaShop, la qualité moyenne des modules a beaucoup amélioré depuis PS8, mais reste hétérogène. Les modules bien codés (performance-first, sans N+1 queries, sans dépendances cassées) coexistent avec des modules historiques mal portés depuis 1.7. Le tri demande de l'expérience.
Sur WooCommerce, l'écosystème est immense mais la qualité va du tout au tout. Les extensions du marketplace WooCommerce officielle sont solides ; le grand reste dépend des plugins WordPress tiers, dont beaucoup chargent des assets inutilement, ralentissent le site, ou exposent des failles de sécurité. La maintenance moyenne d'une boutique WooCommerce mature avec 30 plugins est plus exigeante que celle d'une PrestaShop équivalente.
Sur Shopware, le catalogue est plus restreint mais la qualité moyenne est plus élevée — les standards de code Shopware sont stricts, et les plugins doivent passer un processus de validation pour être marketplace-officiels. Le revers : pour les besoins très spécifiques, vous trouvez moins facilement un plugin tout fait, et finissez plus souvent par développer en interne ou commander une intégration.
Implication pratique : avant de choisir une plateforme, listez les 10 fonctionnalités spécifiques à votre boutique (paiement par 3-fois, gestion stock multi-entrepôt, B2B avec quotas, etc.) et vérifiez la qualité des modules disponibles sur chaque plateforme pour ces 10 sujets. La plateforme qui a le meilleur écosystème pour _vos_ besoins gagne — pas celle qui a le plus gros catalogue brut.
## Quelle plateforme pour quel profil de boutique
Plutôt qu'un « gagnant universel », voici les correspondances claires.
**Boutique mode / déco / lifestyle B2C, 200-2 000 produits, fort budget marketing :** WooCommerce ou Shopify. WooCommerce si vous voulez self-hosted et avez une équipe technique ; Shopify si vous privilégiez la vitesse de mise en place et acceptez les coûts d'app récurrents.
**Boutique européenne francophone avec catalogue technique, 500-5 000 produits, équipe dev interne ou agence partenaire :** PrestaShop 8 reste le meilleur compromis. Multi-langue natif, multi-boutique solide, écosystème module francophone, conformité européenne. C'est notre cas d'usage de référence et celui que nous accompagnons le plus.
**Boutique B2B avec processus complexes (devis, comptes hiérarchiques, prix par client), 1 000-50 000 produits, exigences API fortes :** Shopware 6.7 Pro ou Enterprise. La B2B Suite et l'architecture API-first justifient l'investissement. PrestaShop reste possible mais demande plus de modules tiers pour atteindre la même couverture.
**Boutique multi-pays avec >10 langues, catalogue 5 000-50 000 produits, projet international ambitieux :** Shopware (Sales Channels) ou PrestaShop (multi-shop) selon les expertises de l'équipe. WooCommerce dévissera à ce volume.
**Marque DTC qui veut un setup rapide avec content-marketing fort :** WooCommerce sur WordPress. La synergie blog + boutique sur la même plateforme est un atout sur lequel WooCommerce reste imbattable.
**Migration depuis Shopify pour des raisons de coût :** WooCommerce ou PrestaShop selon votre catalogue et vos contraintes. La migration depuis Shopify a un coût (réimport produits, redirections, refonte thème), c'est un projet à part entière.
## Conclusion : la bonne plateforme est celle qui correspond à votre profil, pas celle qui est « la meilleure »
Le débat « PrestaShop vs WooCommerce vs Shopware » n'a pas de réponse universelle. Les trois plateformes sont solides, maintenues, et capables de porter une boutique e-commerce sérieuse en 2026. Le bon choix dépend de votre catalogue, votre marché géographique, votre budget, vos exigences techniques, et — souvent négligé — l'expertise de votre équipe ou de vos partenaires.
Notre angle, comme cabinet qui développe des modules sur les trois plateformes : PrestaShop reste le sweet spot pour les boutiques européennes francophones de 500 à 10 000 produits, Shopware s'impose sur les besoins B2B et headless, WooCommerce reste pertinent pour les marques avec composante éditoriale forte. Migrer d'une plateforme à l'autre coûte typiquement 6 mois et plusieurs dizaines de milliers d'euros — ce qui rend le choix initial particulièrement structurant. Prenez le temps d'évaluer les 10 fonctionnalités critiques pour _votre_ boutique avant de décider.
Pour creuser les sujets connexes, parcourez nos catégories [Guides & comparatifs](/category/guides-comparatifs-modules/) et [Actualités e-commerce](/category/actualites-ecommerce/). Et si vous avez fait votre choix PrestaShop 8 et cherchez les modules qui font la différence, l'ensemble du [catalogue DataFirefly](https://www.datafirefly.com/shop/) est aligné sur les patterns de cet article — performance-first, code propre, support francophone.
Pour passer à l'action : si votre choix se porte sur PrestaShop, [notre sélection de modules pour migrer vers PrestaShop](https://www.datafirefly.com/solutions/prestashop/migration-prestashop/).
---
### Anatomie d'une fiche produit haute conversion en 2026 : les 12 éléments à orchestrer sur PrestaShop 8
_Source :_ — _publié_ 2026-05-13
> Une fiche produit qui convertit en 2026, ce n'est pas une page belle. C'est une page architecturée. Voici les 12 éléments à orchestrer dans le bon ordre pour faire passer un visiteur curieux à un acheteur qui valide, avec les modules PrestaShop 8 qui font le travail.
Une fiche produit qui convertit en 2026, ce n'est pas une page belle. C'est une page _architecturée_. Sur les boutiques PrestaShop 8 que nous auditons, on retrouve toujours les mêmes faiblesses : un hero produit sans hiérarchie visuelle claire, un bloc prix qu'on cherche, une preuve sociale rangée trop bas, un cross-sell décoratif, et — surtout — une absence d'orchestration entre les éléments. Le visiteur scrolle dans une accumulation d'éléments au lieu de suivre un parcours mental qui le mène à la décision d'achat.
Cet article détaille les 12 éléments qui composent une fiche produit haute conversion en 2026, dans l'ordre où le visiteur les consomme, avec leur rôle psychologique précis et les arbitrages techniques sur PrestaShop 8. À la fin, vous saurez exactement quels modules de votre stack actuel font le travail, lesquels sont absents, et lesquels font illusion sans contribuer.
## Le constat 2026 : la fiche produit reste le maillon faible
Sur les audits de boutiques PrestaShop que nous menons, le funnel d'achat se présente typiquement comme ceci : 100 visiteurs arrivent sur une fiche produit, 30 cliquent « ajouter au panier », 12 finalisent la commande. Le taux de conversion final autour de 3-4 % est dans la moyenne du marché, mais il cache une vérité gênante — la phase fiche produit est responsable de la moitié des abandons. Sur 100 visiteurs, 70 quittent sans même mettre l'article au panier.
Pourquoi cette phase est-elle si critique ? Parce que c'est à la fiche produit que le visiteur prend la décision d'acheter ou non. Le panier et le checkout, en aval, traitent les obstacles techniques (frais de port, mode de paiement, création de compte). Mais c'est la fiche qui répond à la question fondamentale : « est-ce que ce produit vaut le prix demandé pour moi maintenant ? ». Si la réponse n'est pas évidente, le visiteur quitte.
L'enjeu d'une fiche produit haute conversion, c'est donc de répondre à cette question avec la plus grande clarté possible — et de la répondre dans l'ordre qui correspond au cheminement mental d'un acheteur réel, pas dans l'ordre arbitraire qu'imposent les défauts de PrestaShop ou les habitudes héritées des thèmes 2018.
## L'architecture d'une fiche produit qui convertit
Une fiche produit haute conversion suit une structure stable autour de 12 éléments, organisés en trois zones : la zone héro (above the fold, immédiatement visible), la zone d'engagement (juste sous le pli, informationnelle), et la zone de profondeur (longue, scroll continu, achat différé ou hésitant). Voici le détail.
### 1. Le hero produit : image, galerie, vidéo
L'image principale est statistiquement le premier élément que le visiteur regarde — avant même le titre. Elle doit servir à deux objectifs simultanés : montrer le produit clairement et déclencher le désir. Sur les boutiques mode, beauté, déco, c'est l'image qui fait la moitié du travail de conversion ; sur les boutiques techniques, l'image situe le produit (taille, finition, contexte d'usage) et permet de valider visuellement qu'on a la bonne référence.
Une galerie de 4 à 8 images vues sous différents angles est devenue le standard 2026. Au-delà de 8, le visiteur ne regarde plus. En dessous de 4, il manque d'informations visuelles. Et critiquement : intégrer une [vidéo produit dans la galerie](/product/video-dans-la-galerie-produit-prestashop/) peut booster la conversion de 20 à 40 % sur certains produits — à condition que la vidéo soit courte (10-30 secondes), montre le produit en usage réel, et n'impacte pas les Core Web Vitals (lazy load obligatoire, pas de preload sauf sur la première frame).
### 2. Le titre produit
Le titre doit faire deux choses simultanément : confirmer au visiteur qu'il est sur la bonne page (cohérence avec la requête qui l'a amené), et résumer la promesse en une phrase. Les titres trop courts (« Robe noire ») sont insuffisants en 2026 ; les titres trop longs (« Robe noire élégante en coton bio fabriquée en France pour les soirées d'été ») sont fatigants. Le sweet spot est 5 à 10 mots, qui combinent nom du produit + 1-2 attributs différenciants.
Côté SEO, le titre H1 de la fiche est l'un des signaux les plus forts pour le ranking sur les requêtes long-tail produit. Une convention efficace : `{Marque} — {Nom produit} — {Attribut différenciant}`. Cette structure donne du contexte à Google et à l'acheteur en une lecture.
### 3. Le bloc prix
Le prix doit être immédiatement trouvable et décodable. Trois cas d'usage :
- **Prix simple** : un seul prix affiché, gros, en couleur de marque. C'est le cas par défaut.
- **Prix promotionnel** : prix barré (gris, plus petit) à côté du prix actuel (gros, en couleur), avec étiquette « -X % » ou « -X € ». L'écart visuel doit être net pour que la promo soit perçue.
- **Prix dégressif (à partir de)** : pour les produits avec déclinaisons de prix, afficher « À partir de 29 € » avec un lien vers le détail des variantes.
Erreur classique : afficher le prix avec et sans TVA en deux lignes égales, ce qui crée une hésitation cognitive. Un seul prix dominant (TVA incluse pour B2C, hors TVA pour B2B), l'autre en plus petit avec mention claire.
### 4. La preuve sociale immédiate
La note moyenne (étoiles + nombre d'avis) doit être visible **au-dessus du pli**, à proximité du titre. C'est l'un des trois éléments qui décident de la suite — avec l'image et le prix. Sans étoiles visibles, vous laissez le visiteur seul face à sa décision ; avec étoiles, vous lui donnez un signal social qui réduit la friction.
Pour activer ce levier, deux pré-requis : un module d'avis vérifiés qui collecte assez de retours pour avoir une note moyenne crédible (minimum 5 avis, idéalement 20+), et un marquage Schema.org AggregateRating qui fait apparaître les étoiles dans la SERP Google. Notre [module DataFirefly Avis Vérifiés](/product/datafirefly-avis-verifies-prestashop-8/) couvre les deux. Sur les fiches sans avis encore (nouveaux produits), un [badge « Meilleure vente »](/product/module-badge-meilleure-vente-prestashop-best-seller-flag/) ou « Tendance » peut remplir le rôle de preuve sociale temporaire.
### 5. Le bouton CTA primaire
Le bouton « Ajouter au panier » est l'élément le plus important de toute la fiche. Sa visibilité, sa couleur, son libellé décident du taux de conversion sur la mesure brute. Quelques règles éprouvées en 2026 :
- **Couleur contrastante** par rapport au reste de la page (souvent orange, rouge, ou vert si la marque le permet) — pas la couleur dominante du thème.
- **Libellé actionnable**, pas générique. « Ajouter au panier » est meilleur que « Acheter » ; « Commander maintenant » est meilleur que « Valider ». Le mot doit décrire l'action, pas le résultat.
- **Taille suffisante** pour être cliquable sans précision (44×44 px minimum sur mobile, idéalement plus).
- **Sticky sur mobile** : sur les fiches longues, le bouton doit rester visible quand le visiteur scrolle dans la description ou les avis. Sans sticky CTA, vous perdez les visiteurs qui s'éloignent du haut de page.
### 6. Les bénéfices clés (3-5 bullets)
Juste sous le titre/prix/CTA, un bloc de 3 à 5 bullets qui résument les bénéfices clés du produit. Pas les caractéristiques techniques (matériau, dimensions, poids — ça va ailleurs). Pas un descriptif long (idem). Des bénéfices concrets pour l'acheteur, formulés en mots qu'il utiliserait lui-même.
Exemple sur une chaussure de running : « Amorti spécifique pour terrain mou », « Tige respirante pour ne pas surchauffer », « Semelle anti-glisse en condition humide ». Pas : « EVA densité 35, mesh 70 g/m², semelle Vibram MegaGrip ». Le second est de la fiche technique ; le premier vend le produit.
Cette section est souvent négligée parce qu'elle demande un travail éditorial : il faut écrire les bénéfices, produit par produit. Mais elle a un impact disproportionné sur le taux de conversion parce qu'elle traduit les caractéristiques techniques en valeur perçue.
### 7. Les variantes sans rupture de flux
Si votre produit a des déclinaisons (couleur, taille, format), le sélecteur de variantes doit être **au-dessus** du bouton CTA, jamais en-dessous. Le visiteur configure d'abord, puis ajoute au panier. L'inverse crée une friction inutile.
Sur les variantes de couleur, des swatches visuels (carrés ou ronds colorés cliquables) sont systématiquement plus efficaces qu'un menu déroulant texte. Pour les tailles, un sélecteur en boutons (XS, S, M, L, XL alignés horizontalement) bat le menu déroulant. Et critiquement : indiquer la disponibilité par variante — si la taille M est en rupture, le bouton M doit apparaître barré ou grisé, pas masquer la rupture jusqu'au clic sur « ajouter au panier ».
### 8. La barre de livraison gratuite
Une barre de progression vers le seuil de livraison gratuite, affichée discrètement au-dessus du panier ou du CTA produit, augmente le panier moyen de 5 à 15 % sur les boutiques où elle est bien calibrée. Le mécanisme est simple : le visiteur voit qu'il lui manque 12 € pour passer en livraison gratuite, et ajoute un produit complémentaire pour franchir le seuil.
Le piège est de mal calibrer le seuil. Trop haut, le visiteur abandonne au lieu d'ajouter. Trop bas, vous offrez de la livraison à des paniers qui auraient payé sans broncher. Le sujet est traité en profondeur dans notre article dédié au calcul du seuil optimal. Côté technique, la [barre de livraison gratuite DataFirefly](/product/barre-de-livraison-gratuite-barre-de-progression-et-seuils-par-pays-prestashop/) gère les seuils par pays (utile pour les boutiques qui livrent en France et à l'international avec des tarifs différents).
### 9. Les FAQ produit (Schema-marquées)
Une section FAQ avec 4 à 8 questions courantes sur le produit traite trois objectifs en parallèle : elle réduit les frictions cognitives (le visiteur trouve les réponses sans contacter le SAV), elle envoie des signaux SEO via le marquage FAQ Schema (extensions de snippet en SERP), et elle alimente les Answer Engines (ChatGPT, Perplexity, AI Overviews) avec du contenu structuré qu'ils peuvent citer.
Les FAQ doivent être spécifiques au produit, pas génériques. « Quel est le délai de livraison ? » est une FAQ générique qui apparaît partout — Google ne lui accorde aucun signal. « Cette robe taille-t-elle grand ou petit ? » est une FAQ produit qui répond à une vraie hésitation d'achat. La rédaction manuelle scale jusqu'à 30-50 fiches ; au-delà, le module [DataFirefly FAQ IA Produit](/product/datafirefly-faq-ia-produit-prestashop-8/) génère ces FAQ contextuellement.
### 10. La description longue (avec storytelling)
Sous les bénéfices clés et les FAQ, une description plus longue (300-800 mots) qui développe le produit dans son contexte d'usage. Cette description a deux fonctions : convaincre le visiteur hésitant qui veut creuser, et nourrir le SEO long-tail (les requêtes spécifiques que cherchent les acheteurs avancés).
Le piège : la description longue est souvent un copier-coller du catalogue fournisseur, sans valeur ajoutée éditoriale. Quand 50 sites e-commerce vendent le même produit avec la même description fournisseur, Google ne peut pas distinguer la valeur de chacun. La description doit être **rédigée par votre équipe** avec votre angle, votre positionnement, votre vocabulaire. C'est un travail. Mais c'est ce qui différencie les fiches qui montent dans la SERP de celles qui restent enfouies.
### 11. Les avis clients étendus (avec photos)
Plus bas dans la fiche, une section avis clients complète : tous les avis collectés, avec photos clients quand disponibles, avec possibilité de filtrer (par note, par variante, par date). C'est ici que les visiteurs hésitants vont creuser pour valider ou invalider leur intention d'achat.
Trois leviers qui multiplient l'efficacité de cette section : (a) les **photos clients** qui montrent le produit en condition réelle d'usage — elles convertissent 2 à 3 fois mieux que les avis textuels seuls ; (b) les **réponses publiques du marchand** aux avis (surtout aux négatifs) — qui montrent que vous prenez le SAV au sérieux ; (c) la **vérification** des avis (badge « avis vérifié, achat confirmé »), qui distingue vos avis des faux qu'on trouve partout. Le module [DataFirefly Avis Vérifiés](/product/datafirefly-avis-verifies-prestashop-8/) couvre les trois.
### 12. Le cross-sell intelligent
En fin de fiche, le cross-sell propose des produits complémentaires. C'est l'élément qui boucle le parcours : le visiteur qui n'est pas convaincu par CE produit peut découvrir un produit voisin, le visiteur qui veut acheter peut compléter son panier avec des accessoires.
Le piège du cross-sell « 4 produits aléatoires de la même catégorie » est traité en profondeur dans notre article sur les [7 stratégies de cross-sell qui marchent en 2026](/2026/05/09/panier-moyen-prestashop-8-7-strategies-cross-sell-2026/). La synthèse : un cross-sell utile combine plusieurs logiques pondérées (accessoires, fréquemment achetés ensemble, même fabricant) avec analytics sur ce qui convertit. Notre [module DataFirefly Cross-Sell](/product/datafirefly-cross-sell-prestashop-8/) implémente cette mécanique.
## Les éléments qui ne sont pas sur la fiche (mais qui comptent)
Trois éléments adjacents complètent l'architecture de conversion sans être visibles sur la fiche elle-même.
**Le sidecart.** Quand le visiteur clique « Ajouter au panier », le sidecart glisse depuis la droite avec le produit ajouté + 2-3 cross-sell pertinents. Cette mécanique évite la rupture de flux que crée la redirection vers la page panier (qui sort le visiteur du contexte produit où il était). Notre [module DataFirefly SideCart](/product/datafirefly-sidecart-prestashop-8/) implémente cette interaction proprement.
**La wishlist.** Pour les visiteurs pas prêts à acheter immédiatement, le bouton wishlist (cœur, près du CTA) capture l'intention différée. Combiné à des alertes prix automatiques et à un email de relance à J+3 et J+7, la wishlist devient un deuxième tunnel de conversion en parallèle du panier — sujet traité dans notre article sur la [wishlist comme levier de conversion](/2026/05/09/wishlist-prestashop-levier-conversion-alertes-prix-2026/). Module : [DataFirefly Wishlist](/product/dfwishlist/).
**Les signaux d'urgence.** Stock limité (« il en reste 3 »), promotion à durée limitée (« offre valable jusqu'à minuit »), nombre de personnes qui regardent le produit en temps réel. À utiliser avec modération — l'urgence artificielle se détecte facilement et casse la confiance. Mais l'urgence réelle (vraie rupture imminente, vraie fin de promo) accélère la décision sans manipuler.
## Tester et mesurer ce qui convertit vraiment sur votre fiche
Tous ces éléments sont des heuristiques validées par des centaines de boutiques que nous avons accompagnées. Mais sur votre boutique spécifique, certaines combinaisons fonctionneront mieux que d'autres. La seule façon de savoir, c'est de mesurer.
**Heatmap et session recording.** Outils comme Hotjar, Microsoft Clarity (gratuit), ou Smartlook permettent de voir où les visiteurs cliquent, scrollent, hésitent. Un visiteur qui scrolle frénétiquement la fiche puis quitte sans rien faire vous dit qu'il cherchait quelque chose qu'il n'a pas trouvé — souvent une information précise (compatibilité, dimension, délai). C'est un signal pour enrichir une section spécifique.
**A/B testing par éléments.** Plutôt que de redesigner la fiche entière d'un coup, testez les éléments un par un. Couleur du CTA, position du bloc prix, ordre des bénéfices, longueur de la description. Un test par sprint, mesure sur 4-6 semaines pour avoir un signal statistique. Outils : Google Optimize n'existe plus depuis 2023, mais des alternatives comme VWO, Optimizely, Convert.com font le travail.
**Analytics de cross-sell par stratégie.** Si vous utilisez un module de cross-sell pondéré, mesurez le CTR par stratégie. La stratégie « accessoires » converti à 12 % et la stratégie « best-sellers » à 4 % sur votre boutique ? Augmentez le poids de la première, baissez la seconde. Sans cette donnée, vous pilotez à l'aveugle.
## Conclusion : la fiche produit est un système, pas une page
Une fiche produit haute conversion en 2026 n'est pas une page belle. C'est un système architecturé où 12 éléments principaux et 3 éléments adjacents travaillent ensemble pour conduire un visiteur curieux vers un achat validé. Chaque élément a un rôle psychologique précis ; chaque transition entre éléments doit fluide ; chaque module technique sous-jacent doit faire son travail sans dégrader les Core Web Vitals.
L'optimisation est continue : on installe la base, on mesure, on ajuste. Sur les boutiques que nous accompagnons, le passage d'une fiche produit standard à une fiche optimisée représente typiquement un gain de 15 à 35 % de taux de conversion sur les requêtes produit, plus 10 à 25 % de panier moyen via cross-sell et free shipping. C'est rarement un projet de quelques jours — c'est un travail de plusieurs mois, par itération.
Pour creuser les sujets connexes, parcourez nos catégories [Conversion & UX](/category/conversion-ux/) et [Tutoriels PrestaShop](/category/tutoriels-prestashop/). Et pour assembler le stack technique d'une fiche produit haute conversion sur PrestaShop 8, l'ensemble des modules cités dans cet article (Cross-Sell, Avis Vérifiés, FAQ IA, SideCart, Wishlist, Free Shipping Bar, Vidéo Galerie, Badge Meilleure Vente) est disponible dans notre catalogue, individuellement ou combinables selon vos priorités.
Pour passer à l'action : [notre sélection de modules pour optimiser vos fiches produit](https://www.datafirefly.com/solutions/prestashop/fiche-produit/).
---
### PrestaShop FAQ Schema : guide complet 2026 pour faire apparaître ses produits en rich snippets Google
_Source :_ — _publié_ 2026-05-09
> Le FAQ Schema reste l'un des leviers SEO les plus rentables sur les fiches produit en 2026 — et l'un des plus mal compris. Guide complet : implémentation sur PrestaShop 8, validation, et débogage quand le marquage est valide mais n'apparaît pas dans Google.
Régulièrement sur les forums SEO et les threads Reddit r/SEO, la même rumeur revient : « Google a tué le FAQ Schema en 2023 ». La réalité est plus nuancée. En août 2023, Google a effectivement réduit drastiquement l'affichage des rich snippets FAQ — uniquement les sites « gouvernementaux et de santé bien établis » ont conservé l'affichage standard. Mais sur les **fiches produit e-commerce**, le FAQ Schema continue de fonctionner et de produire des résultats visibles dans la SERP en 2026.
Sur les boutiques PrestaShop 8 que nous auditons, l'implémentation du FAQ Schema sur les fiches produit produit toujours :
- des extensions de snippet visibles dans la SERP (les questions apparaissent sous le titre du résultat) ;
- une meilleure compréhension du produit par les Answer Engines (ChatGPT, Perplexity, Google AI Overviews) qui consomment ces données structurées ;
- un signal de qualité éditoriale qui contribue à l'autorité globale de la fiche produit.
Le problème, c'est que le FAQ Schema est aussi l'un des marquages les plus mal compris : implémentations qui ne valident pas, JSON-LD qui valide mais que Google n'affiche jamais, FAQ écrites pour le marquage et pas pour les acheteurs. Ce guide couvre l'implémentation correcte sur PrestaShop 8, la validation, et surtout — la partie que tout le monde rate — le débogage quand votre FAQ Schema est valide mais n'apparaît pas dans les résultats Google.
## Pourquoi le FAQ Schema vaut encore le coup en 2026
La rumeur de la « mort du FAQ Schema » vient d'une mise à jour Google d'août 2023 qui a effectivement limité l'affichage des rich snippets FAQ. Mais la limitation porte sur les **pages éditoriales** (articles de blog, pages d'aide) — pas sur les **fiches produit e-commerce**.
Sur les fiches produit, le FAQ Schema reste actif pour trois raisons :
1. **Google considère les FAQ produit comme des données structurées commerciales** au même titre que le Product Schema ou le Review Schema. Ces données alimentent à la fois la SERP classique et les fonctionnalités enrichies (Shopping, Discover, AI Overviews).
2. **Les Answer Engines (ChatGPT, Perplexity, Claude, Google AI Overviews) consomment massivement ces données** depuis 2024. Quand un utilisateur demande à ChatGPT « quelle est la différence entre tel et tel produit », l'IA cite régulièrement les FAQ structurées trouvées sur les fiches produit — souvent avec un lien vers la source. C'est l'AEO (Answer Engine Optimization) appliqué au e-commerce.
3. **Le FAQ Schema reste un signal d'autorité éditoriale** que Google interprète comme « cette page a été pensée pour répondre aux questions des acheteurs », au-delà du simple rendering en SERP.
Sur les boutiques que nous monitorons, les fiches produit avec FAQ Schema bien implémenté affichent des CTR organiques 12 à 25 % supérieurs aux fiches sans (mesure sur des cohortes équivalentes en termes de positions et de mots-clés). Le rendement est plus modéré qu'en 2022 quand l'affichage était systématique, mais reste largement positif vs le coût d'implémentation.
Conclusion : le FAQ Schema produit n'est pas mort. Il est juste devenu un investissement modéré au lieu d'un levier hyper-rentable.
## Ce que Google attend exactement : la structure JSON-LD valide
Google reconnaît trois formats de données structurées : JSON-LD, Microdata, et RDFa. JSON-LD est officiellement recommandé par Google et est le seul format que vous devriez utiliser en 2026.
Le JSON-LD se place dans une balise script de type `application/ld+json` dans le head ou le body de la page (les deux sont valides ; placer dans le head est plus propre). Voici la structure minimale d'un FAQPage Schema valide pour une fiche produit :
```
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Quelle taille me conseillez-vous ?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Consultez notre guide des tailles dans la section dédiée. La plupart des clients prennent leur taille habituelle ; pour les modèles ajustés, prenez une taille au-dessus."
}
},
{
"@type": "Question",
"name": "Quel est le délai de livraison ?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Livraison sous 48h en France métropolitaine, 3-5 jours en Europe, 7-10 jours dans le reste du monde."
}
}
]
}
```
Quelques règles qui décident du succès ou de l'échec :
**Le contenu doit exister visiblement sur la page.** Google ne prend en compte le FAQ Schema que si les questions et réponses sont effectivement affichées au visiteur (en accordéon, en bloc déroulant, peu importe). Les FAQ « cachées » qui n'existent que dans le JSON-LD sont ignorées et peuvent même déclencher une pénalité manuelle pour cloaking.
**Pas de promotion, pas de marketing dans les réponses.** Google a explicitement banni les FAQ Schema qui contiennent du contenu publicitaire ou des liens externes. Les réponses doivent être informationnelles, neutres, et utiles à l'acheteur.
**Une seule FAQPage par URL.** Si vous avez plusieurs accordéons FAQ sur une page (par exemple, FAQ générale plus FAQ livraison), regroupez tout dans un seul tableau `mainEntity`. Ne créez pas plusieurs blocs JSON-LD `FAQPage` séparés.
**Au moins 2 questions par page.** Une seule question + réponse n'est pas un FAQPage, c'est un Q&A isolé. Visez 4 à 8 questions par fiche produit pour la sweet spot — assez pour être informatif, pas trop pour rester lisible.
**Encodage des caractères spéciaux.** Les apostrophes, guillemets, et caractères accentués doivent être correctement échappés. Une virgule mal placée dans le JSON casse le marquage et le valideur Google rejette tout.
## Implémentation sur PrestaShop 8 : 3 méthodes du plus simple au plus puissant
PrestaShop 8 ne fournit pas de FAQ Schema natif sur les fiches produit. Voici les trois approches possibles.
### Méthode 1 — Manuelle dans le template Twig
L'approche la plus rapide pour tester : éditer le template `themes/votre-theme/templates/catalog/product.tpl` et ajouter le JSON-LD à la fin du fichier.
Cette méthode marche pour les boutiques avec un petit catalogue (moins de 50 produits) où les FAQ peuvent être gérées via une feature personnalisée (`feature_value_lang.value` contenant le texte FAQ formaté). Le template lit la feature et génère le JSON-LD.
Limites évidentes : les FAQ ne sont pas éditables depuis le back-office produit-par-produit avec un éditeur dédié, c'est du copier-coller dans une feature texte qui devient vite ingérable. Pour 5 produits, c'est jouable. Pour 500 produits, c'est inhumain.
### Méthode 2 — Module avec FAQ par produit
L'approche standard : un module qui ajoute un onglet « FAQ » dans la fiche produit du back-office, où vous éditez les questions et réponses comme un mini-CMS. Le module se charge ensuite d'injecter le JSON-LD dans le head de la page (via le hook `displayHeader`) et d'afficher les FAQ visibles dans un accordéon en bas de fiche.
Cette méthode résout le problème éditorial mais introduit le suivant : il faut écrire les FAQ. Sur 500 produits, c'est plusieurs jours de rédaction manuelle. La plupart des marchands abandonnent après 30 produits, et le module devient un cimetière de FAQ vides.
### Méthode 3 — Génération IA automatisée
L'approche moderne : un module qui génère automatiquement les FAQ par produit en utilisant une IA (OpenAI ou Claude), à partir du nom du produit, de sa description, de ses caractéristiques, et de ses avis. Vous déclenchez la génération en bulk depuis la liste produits, vous relisez et ajustez les FAQ générées, et le module pousse le JSON-LD dans le head.
C'est ce que fait notre [module DataFirefly FAQ IA Produit](/product/datafirefly-faq-ia-produit-prestashop-8/) : génération en masse, validation manuelle, FAQ visibles en front avec JSON-LD valide en arrière-plan, le tout en multi-boutique et multi-langue.
Recommandation pratique : démarrez en méthode 1 sur 5 fiches pour valider que Google indexe bien votre marquage, puis basculez en méthode 3 dès que vous voulez scaler au-delà de 30 produits. La méthode 2 est rarement le bon compromis — soit vous voulez scaler (méthode 3), soit vous gérez à la main quelques fiches premium (méthode 1).
## Valider votre FAQ Schema avant et après mise en ligne
La validation se fait en deux étapes : validation syntaxique (le JSON-LD est-il bien formé ?) et validation Google (Google reconnaît-il la structure ?).
**Validation syntaxique.** Avant tout, copiez votre JSON-LD dans un validateur JSON classique (jsonlint.com par exemple). Si la structure est cassée syntaxiquement (virgule manquante, accolade orpheline), le validateur Google ignorera tout. Cette étape rate 90 % des problèmes en 30 secondes.
**Rich Results Test de Google.** L'outil officiel à `search.google.com/test/rich-results`. Vous collez l'URL de votre fiche produit (ou directement le code source HTML), et l'outil vous dit :
- si le FAQ Schema est détecté ;
- combien de questions sont reconnues ;
- s'il y a des erreurs ou des avertissements ;
- à quoi ressemblerait le rich snippet (preview).
Un FAQ Schema valide affiche « FAQPage » dans la liste des éléments détectés avec un compteur du nombre de questions.
**Validation côté Search Console.** Une fois la fiche produit indexée par Google, allez dans Search Console > Améliorations > FAQ. Si Google a accepté le marquage, la page apparaît dans le rapport « Pages valides ». S'il y a des problèmes, elle apparaît dans « Pages avec avertissements » ou « Pages avec erreurs ».
**Le délai d'indexation.** Le marquage que vous publiez aujourd'hui n'apparaîtra pas dans Search Console avant 2 à 7 jours sur une fiche produit existante. Sur une fiche neuve, comptez 1 à 3 semaines avant que Google ne crawle, indexe, et reconnaisse le marquage. Pendant ce délai, le Rich Results Test reste votre meilleur outil de validation.
**Erreurs typiques que le valideur signale.** Les trois plus fréquentes : « Question manquante » (vous avez un `Question` sans `name`), « Réponse manquante » (un `Question` sans `acceptedAnswer`), et « FAQ non visible sur la page » (le contenu du JSON-LD ne correspond pas au texte affiché). Cette dernière est la plus subtile : un copier-coller depuis un autre site, ou une modification du JSON-LD sans mise à jour du HTML visible, déclenche cette erreur.
## Le piège classique : votre FAQ Schema est valide mais n'apparaît pas dans Google
C'est la requête la plus tapée sur Google par les développeurs e-commerce frustrés : « prestashop faq schema not showing in google ». Le marquage valide, le Rich Results Test passe, Search Console ne signale rien — et pourtant aucun rich snippet n'apparaît dans la SERP. Voici les causes par ordre de fréquence.
**Cause 1 : Google n'affiche le rich snippet que pour certaines requêtes, pas systématiquement.** Depuis la mise à jour d'août 2023, Google ne déclenche le FAQ rich snippet que sur les requêtes où il considère que les FAQ apportent une valeur informationnelle au chercheur. Une recherche très transactionnelle (« acheter chaussures rouges 42 ») n'affichera probablement jamais le FAQ snippet, même si la fiche produit a un marquage parfait. Une recherche plus informationnelle (« comment choisir taille chaussures running ») peut déclencher l'affichage. Conclusion : le marquage existe et est valide, mais Google décide quand le montrer.
**Cause 2 : la fiche produit n'est pas suffisamment positionnée pour déclencher les rich features.** Google n'enrichit les SERP qu'à partir d'un certain seuil de qualité de la page. Si votre fiche est en page 2 sur la requête, le FAQ snippet ne s'affichera quasi jamais — Google réserve l'enrichissement aux résultats organiques en haut de page 1.
**Cause 3 : les FAQ sont dupliquées entre plusieurs fiches.** Si vos 50 fiches produit affichent toutes les mêmes 4 questions FAQ (par exemple, des FAQ génériques sur la livraison, le retour, le SAV), Google détecte la duplication et ignore le marquage sur les pages dupliquées. C'est une cause fréquente quand on ajoute des FAQ génériques sans personnaliser par produit.
**Cause 4 : le marquage n'est pas crawlé (robots.txt ou JS-only).** Vérifiez que le JSON-LD apparaît dans le HTML brut servi par votre serveur (curl ou Outils Développeur > Affichage du code source). Si le marquage est généré en JavaScript après chargement, Google peut ne pas l'exécuter sur certaines fiches. Le rendu côté serveur est obligatoire.
**Cause 5 : sanction manuelle ou pénalité algorithmique.** Très rare mais à vérifier dans Search Console > Sécurité et actions manuelles. Si Google a manuellement pénalisé votre site pour spam de données structurées (FAQ trop promotionnelles, réponses non pertinentes), tous vos rich snippets sont coupés.
**Cause 6 : les FAQ sont écrites pour le marquage, pas pour les acheteurs.** C'est le piège subtil. Si vos FAQ sont des questions-réponses artificielles destinées uniquement à remplir le JSON-LD, elles ne déclenchent pas les rich snippets parce que Google identifie qu'elles n'apportent pas de valeur informationnelle réelle. Symptôme : marquage valide, FAQ rich snippet jamais affiché, jamais d'augmentation de CTR malgré des semaines de patience.
Le test : montrez vos FAQ à quelqu'un qui ne connaît pas votre catalogue. Si les questions semblent évidemment artificielles (« pourquoi tel produit est-il génial ? »), c'est mort. Si elles ressemblent à des questions qu'un acheteur poserait sincèrement (« est-ce que tel modèle convient pour tel usage ? »), c'est bon.
**Diagnostic rapide.** Tapez votre fiche produit dans Google avec une requête ciblée que vous estimez devoir déclencher l'enrichissement. Si rien n'apparaît, attendez 2 à 4 semaines après mise en ligne du marquage avant de conclure à un problème. Le délai d'apparition des rich snippets est plus long que le simple délai d'indexation.
## Pourquoi un module IA bat le copier-coller manuel à grande échelle
La rédaction manuelle des FAQ produit reste viable jusqu'à 30-50 fiches. Au-delà, le coût en heures de rédaction devient déraisonnable, et la qualité chute parce que le rédacteur se lasse et écrit des FAQ génériques pour finir le batch.
L'IA bien utilisée résout les deux problèmes :
**Génération contextuelle.** Une bonne IA prend en input le nom du produit, sa description, ses caractéristiques, ses spécifications techniques, et ses avis clients. Elle produit des FAQ qui reflètent les vraies questions que les acheteurs posent (puisqu'elle a appris sur des millions de fiches produit et des milliards de requêtes utilisateur). C'est nettement plus pertinent que les FAQ génériques d'un template.
**Cohérence multilingue.** Sur une boutique multilingue, l'IA génère les FAQ dans toutes les langues actives en une passe, avec une qualité de traduction généralement supérieure à la traduction automatique appliquée sur des FAQ rédigées en français puis traduites.
**Vitesse.** Sur 500 fiches produit, une génération IA prend quelques minutes (en parallèle, par batchs). La validation manuelle des FAQ générées prend ensuite 10 à 20 secondes par fiche (lire et ajuster si nécessaire). Total : 2 à 4 heures pour traiter 500 produits, vs 20 à 40 heures de rédaction manuelle.
**Le risque à connaître.** Une IA mal pilotée peut produire des FAQ génériques (« quels sont les avantages de ce produit ? ») qui n'apportent rien. La qualité du résultat dépend du prompt et du modèle. Notre [module DataFirefly FAQ IA Produit](/product/datafirefly-faq-ia-produit-prestashop-8/) utilise GPT-4 ou Claude au choix, avec des prompts spécifiquement conçus pour produire des questions concrètes et utiles à l'acheteur — pas des questions tautologiques. La validation manuelle reste possible et recommandée pour les fiches stratégiques.
Le vrai gain n'est pas seulement le temps économisé : c'est la possibilité d'avoir un marquage FAQ Schema sur 100 % de votre catalogue, au lieu des 5 à 10 % typiques quand on rédige manuellement. Et 100 % du catalogue avec FAQ Schema, c'est un signal SEO global qui contribue à la perception de qualité éditoriale par Google.
## Au-delà du FAQ Schema : Product, Review, Breadcrumb pour cumuler les rich snippets
Le FAQ Schema seul produit un effet modéré. Le vrai gain SEO sur les fiches produit vient du **cumul** de plusieurs marquages structurés.
**Product Schema.** Le marquage de base : nom, prix, devise, disponibilité, image, marque, GTIN ou EAN si vous l'avez. Sans Product Schema, les rich snippets enrichis (prix dans la SERP, étiquette de stock, fil d'Ariane visible) n'apparaissent jamais. PrestaShop 8 génère un Product Schema basique nativement, mais incomplet — vérifiez qu'il inclut bien `priceCurrency`, `availability` à `schema.org/InStock` ou équivalent, et `image` avec un URL absolu.
**Review et AggregateRating Schema.** Si votre fiche produit a des avis clients vérifiés, l'`aggregateRating` (note moyenne sur 5, nombre d'avis) déclenche les étoiles dans la SERP — l'un des leviers de CTR les plus puissants en e-commerce. Notre [module DataFirefly Avis Vérifiés](/product/datafirefly-avis-verifies-prestashop-8/) génère ce marquage automatiquement à partir des avis collectés et l'injecte dans le Product Schema existant.
**BreadcrumbList Schema.** Pour faire apparaître le fil d'Ariane dans la SERP au lieu de l'URL brute. Effet visuel positif mais modeste sur le CTR. PrestaShop 8 génère ce marquage nativement sur les pages catégories et fiches produit ; vérifiez qu'il n'a pas été cassé par votre thème custom.
**Offer Schema.** Si vous avez des promotions ou des prix barrés, le marquage `Offer` permet d'afficher le prix réduit avec le prix d'origine dans la SERP. C'est encore plus puissant pendant les soldes et les Black Friday. Compatible avec le Product Schema en l'imbriquant dans `offers`.
**Cohérence entre marquages.** Tous les schemas sur une même page doivent être cohérents : si votre Product Schema dit « prix 49 € » et votre Offer Schema dit « prix 39 € », Google considère le marquage comme suspect et peut tout ignorer. Vérifiez que les valeurs propagent correctement.
**Stratégie globale.** L'objectif n'est pas d'avoir un type de schema parfait, mais d'avoir un **stack** cohérent : Product, Offer, AggregateRating, FAQPage, BreadcrumbList tous présents et tous valides sur chaque fiche produit. Sur les boutiques où ce stack complet est en place, les fiches produit affichent en SERP : titre, URL avec breadcrumb, prix, étoiles, et extension FAQ. Le CTR organique gagne typiquement 30 à 50 % vs un titre brut. C'est un investissement initial conséquent, mais une fois stable, l'effet est durable.
## Conclusion : un investissement modéré qui reste rentable en 2026
Le FAQ Schema sur fiches produit n'est plus le levier hyper-rentable de 2022. Mais il reste l'un des marquages structurés les plus rentables en 2026, particulièrement quand il est combiné aux autres schemas (Product, Review, Breadcrumb) pour former un stack cohérent.
L'implémentation manuelle est viable jusqu'à 30-50 fiches. Au-delà, basculez en génération IA — gain de temps de 90 % et qualité supérieure parce que vous couvrez 100 % du catalogue au lieu d'une poignée de fiches.
Pour les sujets SEO connexes, parcourez notre catégorie [SEO E-commerce](/category/seo-ecommerce/), ou nos [tutoriels PrestaShop](/category/tutoriels-prestashop/) pour les sujets techniques. Pour mesurer l'impact réel de votre stack de schemas sur le CTR, le module [Google Tag Pro](/product/google-tag-pro-plug-play/) configure le tracking nécessaire pour suivre les clics par type de SERP enrichie.
Et si vous voulez sauter la phase de rédaction manuelle pour passer directement au scale, le module [DataFirefly FAQ IA Produit](/product/datafirefly-faq-ia-produit-prestashop-8/) génère vos FAQ et leur marquage JSON-LD pour tout votre catalogue PrestaShop 8 en quelques minutes.
À lire aussi : [le guide complet du SEO e-commerce](https://www.datafirefly.com/2026/05/01/seo-ecommerce-guide-complet-2026/) et [Schema.org Product en 2026](https://www.datafirefly.com/2026/07/20/schema-org-product-2026-hasmerchantreturnpolicy-shippingdetails-prestashop-woocommerce/).
Pour passer à l'action : [notre sélection de modules pour optimiser vos fiches produit](https://www.datafirefly.com/solutions/prestashop/fiche-produit/).
---
### RGPD 2026 et Consent Mode v2 sur PrestaShop : configuration complète pour rester conforme et garder son tracking GA4
_Source :_ — _publié_ 2026-05-09
> Depuis mars 2024, Google impose le Consent Mode v2 pour conserver l'accès à GA4 et Google Ads. En 2026, beaucoup de boutiques PrestaShop tournent encore mal configurées. Guide complet : stack technique, GTM, debugging, erreurs typiques.
Depuis mars 2024, Google impose le Consent Mode v2 à tout site qui veut conserver l'accès aux données GA4 et Google Ads pour les utilisateurs européens. En 2026, beaucoup de boutiques PrestaShop tournent encore avec une configuration mal comprise — soit en Consent Mode v1 oublié dans un coin, soit en v2 mal câblé, soit pire, sans Consent Mode du tout. Le résultat est invariablement le même : des données GA4 partielles, des audiences Google Ads qui ne se remplissent plus, et un risque de conformité RGPD que la CNIL prend de moins en moins à la légère depuis ses sanctions de 2024-2025.
Ce guide couvre la configuration complète du Consent Mode v2 sur PrestaShop 8 : ce qui a changé par rapport à v1, le stack technique à mettre en place (CMP + Google Tag Manager + GA4), les erreurs typiques qu'on voit en audit, et comment vérifier que tout marche réellement avant de considérer le sujet comme bouclé.
## Ce que le Consent Mode v2 change concrètement par rapport à v1
Le Consent Mode v1 (lancé en 2020) gérait deux paramètres de consentement : `ad_storage` et `analytics_storage`. C'était suffisant pour différencier le tracking analytics du tracking publicitaire, et la CNIL acceptait l'approche.
Le Consent Mode v2 (mars 2024) ajoute deux paramètres supplémentaires :
- `ad_user_data` — autorisation d'envoyer des données utilisateur à Google pour de la publicité (par exemple, hash d'email pour les Customer Match). Sans cette autorisation, vos audiences personnalisées Google Ads ne se remplissent plus.
- `ad_personalization` — autorisation d'utiliser ces données pour de la publicité personnalisée (remarketing, audiences similaires, etc.). Sans cette autorisation, vos campagnes de remarketing tournent à vide.
Pour conserver l'accès aux fonctionnalités Google Ads complètes, ces deux paramètres doivent être positionnés explicitement, en plus des deux historiques. Si vous ne le faites pas, Google considère que vous n'avez pas migré et bloque progressivement les fonctionnalités les plus dépendantes des données utilisateur (Customer Match, audiences avancées, remarketing dynamique).
L'autre changement majeur, c'est la distinction entre **Consent Mode basique** et **Consent Mode avancé**. En basique, si l'utilisateur refuse les cookies, aucun tag Google ne se déclenche du tout — vous perdez 100 % de la donnée pour ce visiteur. En avancé, les tags Google se déclenchent quand même mais en mode « cookieless » (envoi de pings anonymes), et Google utilise ensuite la modélisation statistique pour combler les trous des utilisateurs qui ont refusé. C'est nettement plus puissant, mais c'est aussi plus délicat à implémenter — et c'est là que la majorité des configurations partent en vrille.
Dernier point : le Consent Mode v2 doit être déclaré **avant** tout autre tag Google sur la page (GA4, Google Ads, Floodlight, etc.). Si l'ordre n'est pas respecté, les premiers événements partent sans état de consentement et votre conformité RGPD est cassée. C'est l'erreur la plus fréquente qu'on voit en audit.
## Le stack à mettre en place sur PrestaShop 8
La configuration propre repose sur trois composants qui doivent travailler ensemble.
**Une CMP (Consent Management Platform).** C'est le bandeau cookies que voit le visiteur, qui collecte son choix et l'expose techniquement aux autres scripts de la page. Sur PrestaShop 8, plusieurs options existent : tarteaucitron (gratuit, français, IAB TCF non requis pour les sites non-publishers), Axeptio ou Didomi (CMP IAB TCF v2.2 si vous avez besoin du framework publicitaire), ou des solutions intégrées dans des modules dédiés.
**Google Tag Manager.** Le hub central qui orchestre vos tags. Sans GTM, gérer le Consent Mode v2 directement dans le code théorique de PrestaShop est faisable mais devient ingérable dès qu'on ajoute Google Ads, Meta Pixel, TikTok Pixel, et d'autres trackers. GTM centralise la logique et permet de conditionner chaque tag à l'état de consentement courant.
**GA4 et les destinations Google Ads.** En aval, ce sont les destinations qui consomment l'information de consentement. GA4 et Google Ads lisent automatiquement les paramètres Consent Mode quand ils sont correctement positionnés via GTM ou via les tags directs.
L'orchestration : la CMP signale à GTM le choix de l'utilisateur via un dataLayer push, GTM déclenche les tags Google avec les bons paramètres de consentement, GA4 et Google Ads enregistrent les données selon ce que le consentement permet. Si l'un de ces trois maillons est mal configuré, la chaîne se casse silencieusement.
Sur PrestaShop 8 spécifiquement, le défi est que ces composants viennent de modules différents qui ne se parlent pas par défaut. Sans coordination, vous avez votre CMP qui fait son travail, GTM qui fait le sien, et GA4 qui collecte tout ou rien selon les hasards de l'ordre de chargement. La configuration manuelle est possible mais pénible ; un module dédié qui gère la chaîne complète est généralement plus fiable.
## Configuration de la CMP : tarteaucitron, Axeptio, ou solution intégrée
Le choix de la CMP dépend de votre besoin réel.
**Tarteaucitron** est une CMP française open source largement utilisée sur PrestaShop. Avantages : gratuite, conforme RGPD strict, gestion granulaire des services tiers (Google Tag Manager, GA4, Hotjar, YouTube, etc.), et personnalisable visuellement. Limites : configuration technique parfois pénible, pas de framework IAB TCF v2.2 (donc inadaptée si vous publiez de la pub display via SSP). Pour 95 % des boutiques PrestaShop classiques (vente de produits, pas de monétisation publicitaire), tarteaucitron est suffisant.
Sur PrestaShop 8, le module [Cookie Manager Tarteaucitron](/product/cookie-manager-tarteaucitron-conformite-rgpd-cle-en-main-pour-prestashop/) intègre la librairie avec une configuration back-office propre, gère les services tiers courants en quelques clics, et expose les states de consentement vers GTM via des événements dataLayer standards. La connexion avec GTM est automatique, ce qui élimine la majorité des erreurs de timing.
**Axeptio et Didomi** sont des CMP commerciales (à partir de 30-100 € par mois selon le volume), avec support IAB TCF v2.2. À choisir si vous monétisez avec de la publicité programmatique, ou si vous opérez dans un secteur sensible (santé, finance) où le niveau de conformité doit être documenté. Pour la majorité des boutiques e-commerce classiques, c'est de la sur-ingénierie.
**Solutions tout-en-un.** Certains modules combinent CMP + tracking GA4/Ads + Consent Mode v2 dans un seul package, ce qui élimine les conflits de version et de timing. C'est ce que fait le module [Google Tag Pro](/product/google-tag-pro-plug-play/) sur PrestaShop : tracking GA4 et Google Ads enhanced ecommerce complet, Consent Mode v2 natif, et compatibilité avec les CMP courantes (tarteaucitron, Axeptio, Didomi) via détection automatique. Approche pragmatique pour les boutiques qui veulent un setup conforme sans bricolage.
Quel que soit le choix, le test à faire après installation : recharger la page en navigation privée, refuser les cookies dans le bandeau, et vérifier dans les Outils Développeur > Réseau que **aucun tag Google** ne charge avant que vous fassiez votre choix. Si un tag charge avant, votre CMP n'est pas configurée correctement et votre conformité RGPD est cassée.
## Configuration de GTM avec les triggers Consent State
Côté GTM, la configuration suit toujours la même séquence : initialiser le Consent Mode avec un état par défaut « tout refusé », puis envoyer un événement `consent update` dès que l'utilisateur a fait son choix dans la CMP.
**Tag de configuration Default (à déclencher en premier sur toutes les pages).** Ce tag pose les valeurs par défaut du Consent Mode avant tout autre tag :
```
gtag('consent', 'default', {
'ad_storage': 'denied',
'ad_user_data': 'denied',
'ad_personalization': 'denied',
'analytics_storage': 'denied',
'wait_for_update': 500
});
```
Le paramètre `wait_for_update` indique à Google d'attendre jusqu'à 500 ms avant d'envoyer les premiers pings — le temps que la CMP ait pu déterminer le choix de l'utilisateur (cookie persistant existant ou nouveau choix). Ce paramètre évite les pings dupliqués qui partent une fois en mode « tout refusé » puis une seconde fois après le consentement.
**Tag Update (à déclencher après le choix utilisateur).** Ce tag met à jour les valeurs en fonction du choix exprimé dans la CMP :
```
gtag('consent', 'update', {
'ad_storage': 'granted',
'ad_user_data': 'granted',
'ad_personalization': 'granted',
'analytics_storage': 'granted'
});
```
Sur GTM, ce tag se déclenche sur un événement custom (par exemple `consent_granted`) que la CMP pousse dans le dataLayer après le clic « Accepter » de l'utilisateur. Si l'utilisateur fait un choix granulaire (accepte analytics mais refuse pub), seuls les paramètres correspondants passent à `granted`.
**Configuration des tags GA4 et Google Ads.** Une fois le Consent Mode initialisé, les tags GA4 et Google Ads classiques fonctionnent normalement et lisent automatiquement les paramètres de consentement. Vous n'avez rien à modifier sur ces tags individuels — c'est tout l'intérêt de la centralisation Consent Mode.
**L'astuce mode avancé.** Pour activer le Consent Mode avancé (modélisation statistique des refus), il faut configurer dans GTM le paramètre « URL passthrough » et « Redact ads data » au niveau du conteneur. Ces options envoient des pings anonymisés même quand le consentement est refusé, ce qui permet à Google de modéliser le comportement de la cohorte refusante. Le détail : ces pings sont sans cookies, sans identifiants utilisateur, conformes RGPD.
## Vérifier que tout marche : debugging avec Google Tag Assistant
Une fois la configuration en place, la vérification se fait avec deux outils Google.
**Google Tag Assistant (https://tagassistant.google.com).** Vous saisissez l'URL de votre boutique, l'outil charge la page dans une session de debug et trace tous les événements qui partent. Pour chaque événement, vous voyez les paramètres envoyés, dont les states de Consent Mode courants. Le test critique : ouvrir Tag Assistant, faire le parcours d'achat complet (homepage → fiche produit → ajout au panier → checkout → paiement), et vérifier que tous les événements partent avec les bons states.
Avant le consentement utilisateur, tous les événements doivent partir avec `denied` sur les 4 paramètres. Après consentement « tout accepter », tous doivent passer à `granted`. Si vous voyez un événement qui part avec un mix incohérent, ou un événement qui part avec `granted` avant le consentement, votre configuration est cassée.
**L'extension Chrome Tag Assistant Companion.** Plus puissante que la version web, elle s'installe dans Chrome et trace en temps réel tous les hits Google envoyés depuis le site visité. Pratique pour debug en navigation normale (pas dans une session Tag Assistant artificielle). L'extension affiche en temps réel les Consent States de chaque hit, ce qui permet de repérer les incohérences entre pages ou entre actions.
**Le rapport « États de consentement » dans GA4.** Une fois la configuration stabilisée depuis quelques jours, allez dans GA4 > Administration > Diagnostics. Le rapport « États de consentement » indique le pourcentage d'événements reçus avec consentement granted vs denied. Sur une boutique européenne avec une CMP correctement configurée, vous devriez voir 30 à 60 % d'événements en granted (selon votre design de bandeau et l'intensité de votre dark pattern). Si vous voyez 100 % de granted, votre CMP ne demande pas vraiment le consentement. Si vous voyez 0 % de granted, votre Update tag ne se déclenche pas.
## Les erreurs typiques qu'on voit en audit
Sur les audits RGPD/Consent Mode des boutiques PrestaShop, les six erreurs suivantes reviennent en boucle.
**Erreur 1 : le Default tag est déclenché après le tag GA4.** Le Consent Mode doit être initialisé en tout premier dans le code de la page, avant que GA4 ou Google Ads ne se charge. Si l'ordre n'est pas respecté, GA4 envoie son premier ping (vue de page) sans état de consentement, donc en mode « consent inconnu », et la CNIL peut considérer que vous trackez avant consentement. Solution : dans GTM, mettre le Default tag avec le déclencheur « Initialization » (qui se déclenche avant tous les autres déclencheurs).
**Erreur 2 : le Update tag ne se déclenche jamais.** Symptôme classique : tous les pings restent en `denied` même après que l'utilisateur a cliqué « Tout accepter ». Cause : la CMP ne pousse pas l'événement attendu dans le dataLayer, ou GTM est configuré pour écouter le mauvais nom d'événement. À vérifier en console : taper `dataLayer` et chercher l'événement de consentement après avoir cliqué Accepter.
**Erreur 3 : GTM bloqué par la CMP elle-même (le paradoxe).** Certaines CMP mal configurées considèrent GTM comme un « tracker tiers » à bloquer avant consentement. Résultat : GTM ne charge pas, donc le Consent Mode n'est jamais initialisé, donc rien ne marche. La CMP doit autoriser GTM à charger avant le consentement (GTM lui-même est neutre, ce sont les tags qu'il déclenche qui dépendent du consentement).
**Erreur 4 : conflits multi-modules.** Sur les boutiques PrestaShop qui ont accumulé plusieurs modules de tracking au fil des années (un ancien module GA Universal, le natif PrestaShop GA4, un module GTM, un module Meta Pixel, etc.), les tags se court-circuitent entre eux. Le code GA4 part deux fois, le Consent Mode est posé puis écrasé par un autre module. Solution : auditer tous les modules de tracking actifs et n'en garder qu'un seul qui orchestre tout.
**Erreur 5 : pas de gestion du retour utilisateur.** Quand un utilisateur change d'avis et clique « Modifier mes préférences » dans le footer, la CMP doit déclencher un nouvel événement Update qui passe les paramètres au nouveau choix. Beaucoup de configurations gèrent l'événement Accept initial mais pas les changements ultérieurs, donc l'utilisateur qui retire son consentement continue d'être tracké comme s'il avait accepté.
**Erreur 6 : Consent Mode v1 oublié à côté.** Plusieurs boutiques migrées de v1 à v2 ont conservé l'ancien tag par erreur. Les deux Consent Modes coexistent et se disputent les paramètres, avec des résultats imprévisibles. Solution : supprimer toute trace du Consent Mode v1 (tags GTM, code dans le thème, modules anciens) avant de mettre en place v2.
## Et la « modélisation » Google : ce qu'on récupère malgré le refus
Le grand argument de vente du Consent Mode avancé, c'est la modélisation statistique. Quand un utilisateur refuse les cookies, Google envoie quand même des pings anonymisés (pas d'identifiant, pas de cookie), et ses algorithmes ML utilisent ces signaux pour estimer ce qui se serait passé si l'utilisateur avait accepté. Concrètement, votre rapport GA4 affiche des conversions modélisées en plus des conversions observées.
Dans la réalité 2026, voici ce qu'on observe :
**Conditions d'éligibilité.** La modélisation ne se déclenche que si votre propriété GA4 a un volume minimum (1000 événements par jour environ, selon Google) et au moins 1000 utilisateurs sans consentement par jour. En dessous, GA4 affiche les données « brutes » sans modélisation, et vous perdez réellement les utilisateurs qui ont refusé. Pour une boutique avec 200-500 visiteurs jour, la modélisation ne sera probablement pas active sur tout votre trafic.
**Côté Google Ads, c'est plus généreux.** Les campagnes Google Ads bénéficient de la modélisation à partir de seuils plus bas, et l'effet est immédiatement visible sur le ROAS rapporté. Si vous faites de l'achat média Google, le Consent Mode avancé bien configuré peut récupérer 20 à 40 % de conversions « manquées » dans les rapports.
**Réalité vs marketing.** Google présente la modélisation comme une compensation magique, mais ce sont des estimations statistiques avec une marge d'erreur réelle. Le vrai bénéfice n'est pas tant le chiffre récupéré que la possibilité pour les algorithmes de bidding Google Ads de continuer à apprendre — c'est ça qui maintient la performance de vos campagnes Smart Bidding malgré la baisse du consentement explicite.
**L'alternative serveur-à-serveur.** Pour les boutiques qui veulent maximiser la collecte sans dépendre uniquement de la modélisation, le tracking server-side via GTM Server est une option. Plus complexe à mettre en place, mais récupère une partie significative des données perdues côté client. Sujet d'un autre article.
## Conclusion : un investissement obligatoire qui demande de la rigueur
Le Consent Mode v2 sur PrestaShop n'est plus une option en 2026. C'est une obligation à la fois pour rester conforme RGPD et pour garder accès aux fonctionnalités complètes de Google Ads. La configuration n'est pas extraordinairement complexe, mais elle exige de la rigueur : ordre de déclenchement précis, coordination CMP/GTM/GA4, vérification systématique avec Tag Assistant.
L'erreur la plus coûteuse, c'est de penser que « ça doit marcher » parce qu'on a installé une CMP et que le bandeau cookie s'affiche. Sans vérification end-to-end avec Tag Assistant, vous découvrez les bugs de configuration des mois plus tard, en perdant des données et en risquant la conformité.
Pour aller plus loin sur les sujets connexes, parcourez nos [tutoriels PrestaShop](/category/tutoriels-prestashop/) ou nos [actualités e-commerce](/category/actualites-ecommerce/) où nous suivons les évolutions réglementaires et techniques au fil des annonces Google et CNIL.
Et si vous voulez un setup tracking GA4 et Google Ads complet avec Consent Mode v2 natif et compatibilité CMP automatique, le module [Google Tag Pro](/product/google-tag-pro-plug-play/) implémente la chaîne complète sur PrestaShop 8 — installation guidée, configuration en quelques clics, debugging intégré.
Pour passer à l'action : [notre sélection de modules pour le RGPD et les cookies](https://www.datafirefly.com/solutions/prestashop/rgpd-cookies/) et [celle pour mesurer vos conversions](https://www.datafirefly.com/solutions/prestashop/tracking-conversions/).
---
## Documentation
### 2FA Google Authentificator pour PrestaShop — Documentation
_Source :_
> Ce guide couvre l'installation, la configuration et l'utilisation quotidienne du module 2FA Google Authentificator pour PrestaShop 8 et 9. Le module ajoute une vérification par code à 6 chiffres (standard…
Ce guide couvre l'installation, la configuration et l'utilisation quotidienne du module **2FA Google Authentificator** pour PrestaShop 8 et 9. Le module ajoute une vérification par code à 6 chiffres (standard TOTP, RFC 6238) après la saisie du mot de passe sur le back-office.
## Prérequis
- PrestaShop 8.0 à 8.2 ou PrestaShop 9.x
- PHP 7.4 minimum (PHP 8.1+ requis par PrestaShop 9)
- Une application TOTP sur le téléphone de chaque employé : Google Authenticator, Microsoft Authenticator, Authy, 1Password, Bitwarden, FreeOTP ou toute app compatible RFC 6238
- Horloge serveur synchronisée via NTP (le cas sur tous les hébergements modernes)
## Installation
1. Dans le back-office, ouvrez **Modules → Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et sélectionnez le fichier `df2fa.zip` téléchargé depuis votre compte DataFirefly.
3. Cliquez sur **Installer**. Le module crée sa table en base et enregistre ses contrôleurs automatiquement.
L'installation n'active la 2FA pour personne : chaque employé doit effectuer son appairage (ou y être forcé via le mode obligatoire, voir ci-dessous). Vous ne risquez pas de vous retrouver bloqué hors du back-office en installant le module.
## Configuration du module
Ouvrez **Modules → Gestionnaire de modules → 2FA Google Authentificator → Configurer**. La page présente trois blocs :
### Mon compte 2FA
Un panneau d'état en haut de page indique si votre propre 2FA est active, avec un bouton direct vers l'appairage ou la gestion.
### Configuration 2FA
- **2FA obligatoire** — en mode forcé, tout employé sans 2FA configurée est automatiquement redirigé vers la page d'appairage dès sa connexion. En mode opt-in (par défaut), une bannière de rappel s'affiche dans le back-office et chaque employé active sa 2FA quand il le souhaite.
- **Nom de l'émetteur (Issuer)** — le nom affiché dans l'application TOTP de vos employés (par défaut, le nom de la boutique).
### Statut 2FA des employés
Un tableau liste tous les employés avec leur statut 2FA (actif/inactif), la date de configuration et un bouton **Réinitialiser** pour chaque employé ayant la 2FA active.
Déploiement progressif recommandé : commencez en mode opt-in, laissez la bannière de rappel faire son travail quelques jours, vérifiez l'adoption dans le tableau, puis basculez en mode obligatoire.
## Appairage côté employé
1. L'employé ouvre la page d'appairage : via le lien **Configurer ma 2FA** du menu utilisateur (en haut à droite du back-office), via la bannière de rappel, ou automatiquement à la connexion si le mode obligatoire est actif.
2. Il scanne le **QR code** affiché avec son application TOTP. Le QR code est généré localement dans le navigateur — aucune donnée n'est envoyée à un service externe. En cas d'impossibilité de scanner, le secret peut être saisi manuellement dans l'app (bouton Copier).
3. Il saisit le **code à 6 chiffres** affiché par l'application pour valider l'appairage.
4. Les **8 codes de récupération** à usage unique s'affichent alors — c'est la seule fois où ils sont visibles. L'employé les copie ou les imprime et les conserve en lieu sûr.
Les codes de récupération sont stockés hashés (SHA-256) : ils ne peuvent pas être réaffichés ultérieurement. S'ils sont perdus, il faudra désactiver puis réactiver la 2FA, ou passer par une réinitialisation Super Admin.
## Connexion avec 2FA
Après la saisie du mot de passe, l'employé est redirigé vers l'écran de vérification 2FA et saisit le code à 6 chiffres courant de son application. La vérification reste valable **12 heures** pour la session : il n'est pas nécessaire de ressaisir un code à chaque page.
Une tolérance de dérive de ±30 secondes est appliquée pour absorber les petits écarts d'horloge entre le serveur et le téléphone.
## Codes de récupération
Si l'employé n'a plus accès à son application TOTP (téléphone perdu, volé, réinitialisé) :
1. Sur l'écran de vérification, cliquez sur **Utiliser un code de récupération**.
2. Saisissez l'un des 8 codes de récupération (10 caractères).
3. Chaque code ne fonctionne **qu'une seule fois**. Une fois connecté, désactivez puis réactivez la 2FA pour générer un nouvel appairage et une nouvelle série de codes.
## Protection anti force brute
Après **5 codes invalides consécutifs**, la vérification 2FA du compte est verrouillée pendant **15 minutes**. L'écran de vérification affiche le temps restant. Le compteur est remis à zéro à chaque vérification réussie.
## Réinitialisation par un Super Admin
Si un employé a perdu à la fois son téléphone et ses codes de récupération :
1. Un Super Admin ouvre la page de configuration du module.
2. Dans le tableau **Statut 2FA des employés**, il clique sur **Réinitialiser** sur la ligne de l'employé concerné.
3. La 2FA de l'employé est supprimée : il peut se connecter avec son seul mot de passe et devra refaire l'appairage (immédiatement si le mode obligatoire est actif).
## Désactiver sa propre 2FA
Depuis **Gérer ma 2FA** (menu utilisateur ou panneau du module), cliquez sur **Désactiver la 2FA** et confirmez avec un code TOTP valide. La saisie d'un code est exigée pour empêcher une désactivation par une session laissée ouverte.
## Mise à jour depuis la version 1.0.x
La mise à jour vers la 1.1.0 est automatique et transparente :
- La structure de la table est migrée (colonnes de verrouillage, champ secret élargi).
- Les secrets TOTP existants restent valides et sont **chiffrés en AES-256** automatiquement lors de leur prochaine sauvegarde. Aucun ré-appairage nécessaire.
- Les codes de récupération existants restent utilisables : ils sont convertis en hash SHA-256 à leur première utilisation.
Migration PS8 → PS9 : le module est identique sur les deux versions. Vous pouvez migrer votre boutique sans mettre à jour le module ni ré-appairer les employés.
## Dépannage
### « Code invalide » alors que le code semble correct
Dans 95 % des cas il s'agit d'un écart d'horloge. Vérifiez que l'horloge du serveur est synchronisée par NTP (`timedatectl` sous Linux) et que l'heure du téléphone est en mode automatique. La tolérance du module est de ±30 secondes.
### Compte verrouillé après des essais infructueux
Attendez la fin du verrouillage de 15 minutes, ou demandez à un Super Admin de réinitialiser la 2FA du compte depuis la page de configuration.
### Tous les accès Super Admin sont bloqués
En dernier recours, désactivez le module en base de données : dans la table `ps_module`, passez la colonne `active` à 0 pour la ligne `df2fa`, ou renommez temporairement le dossier `modules/df2fa`. Reconnectez-vous, puis réactivez le module et refaites les appairages nécessaires.
### La bannière de rappel ne s'affiche pas
La bannière n'apparaît que pour les employés sans 2FA active. En mode opt-in, elle peut être masquée pour la session en cours via sa croix de fermeture ; elle réapparaît à la session suivante.
## Notes de version
### 1.1.0 — 2 juillet 2026
- Compatibilité PrestaShop 9 (contrôleurs, nouvelle page de connexion Symfony, Symfony 6.4)
- Chiffrement AES-256 du secret TOTP en base, avec migration automatique
- Codes de récupération hashés en SHA-256 (10 caractères)
- Verrouillage 15 minutes après 5 codes invalides
- QR code généré 100 % localement (dépendance CDN supprimée)
### 1.0.0 — 12 mars 2025
- Première version stable : TOTP RFC 6238, mode obligatoire ou opt-in, 8 codes de récupération, réinitialisation Super Admin, multi-boutique
---
### Accessibilité EAA — Widget & Corrections WCAG (dfaccessibility)
_Source :_
> DF Accessibility met votre boutique PrestaShop en conformité avec la directive européenne sur l'accessibilité (EAA — Directive (UE) 2019/882) en combinant trois briques : un widget d'accessibilité pour vos visiteurs,…
DF Accessibility met votre boutique PrestaShop en conformité avec la directive européenne sur l'accessibilité (EAA — Directive (UE) 2019/882) en combinant trois briques : un widget d'accessibilité pour vos visiteurs, un moteur de corrections WCAG automatiques appliquées au chargement de chaque page, et un générateur de déclaration d'accessibilité légale multilingue.
Cette documentation couvre la version **1.0.1** du module, compatible PrestaShop **8.0.0 à 9.x**. Aucun override de classe, aucune dépendance Composer, aucune requête externe.
## Installation
1. Dans votre back-office PrestaShop, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez le fichier `dfaccessibility.zip`.
3. Cliquez sur **Configurer** une fois l'installation terminée.
Le module s'enregistre sur trois hooks (`displayHeader`, `actionFrontControllerSetMedia`, `displayBeforeBodyClosingTag`) et crée une unique table de statistiques. Dès l'installation, le widget est actif en front-office avec les réglages par défaut et toutes les corrections automatiques sont activées, à l'exception de la correction de contraste.
## Configuration
### Widget d'accessibilité
- **Activer le widget** — affiche le bouton flottant sur toutes les pages du front-office.
- **Position du bouton** — en bas à droite ou en bas à gauche.
- **Couleur d'accent** — utilisée pour le bouton, les options actives du panneau et le contour de focus imposé. Choisissez une couleur suffisamment contrastée avec le blanc (le bleu par défaut `#2563EB` respecte le ratio AA).
- **Masquer le bouton sur mobile** — cache le bouton flottant sous 768px. Les préférences déjà enregistrées par le visiteur continuent de s'appliquer.
### Corrections automatiques
Chaque correction est activable individuellement. Elles s'exécutent dans le navigateur du visiteur au chargement de la page : vos fichiers de thème ne sont jamais modifiés et une désinstallation restaure l'état d'origine à l'identique.
- **Textes alternatifs manquants** — voir le détail des heuristiques plus bas.
- **Champs de formulaire sans étiquette** — ajoute un `aria-label` déduit du placeholder ou du nom du champ.
- **Liens ouvrant une nouvelle fenêtre** — ajoute `rel=noopener` et un avertissement audible pour les lecteurs d'écran.
- **Iframes sans titre** — ajoute un attribut `title` dérivé du domaine source.
- **Repères ARIA** — ajoute les rôles `banner`, `contentinfo` et un `aria-label` de navigation lorsqu'ils sont absents.
- **Lien d'évitement** — injecte un lien « Aller au contenu principal » révélé au premier appui sur Tab.
- **Contour de focus visible** — impose un contour au focus clavier (critère WCAG 2.4.7).
- **Correction automatique du contraste** — désactivée par défaut, voir la section dédiée.
### Statistiques
Lorsque la collecte est activée, le navigateur envoie après application des corrections un compteur anonyme par type de correction (via `sendBeacon`). Ces compteurs sont agrégés par jour et par boutique — aucun cookie, aucun identifiant, aucune donnée personnelle.
## Le widget côté visiteur
Le bouton flottant ouvre un panneau proposant :
- **Taille du texte** — 5 paliers de 100% à 135%.
- **Contraste élevé** — mode intelligent qui éclaircit les fonds unis en préservant les images (voir ci-dessous).
- **Police lisible** — bascule vers une pile Verdana/Arial.
- **Augmenter les espacements** — interlignage 1.8, espacement des lettres et des mots augmentés (critère WCAG 1.4.12).
- **Surligner les liens** — fond jaune et soulignement systématique.
- **Grand curseur** — curseur agrandi à fort contraste.
- **Guide de lecture** — barre horizontale suivant la souris.
- **Arrêter les animations** — neutralise animations et transitions CSS (critère WCAG 2.3.3).
- **Masquer les images** — masque images, vidéos et images de fond.
- **Réinitialiser tous les réglages** — retour à l'état d'origine.
Le panneau est entièrement utilisable au clavier : piège de focus, fermeture par Échap, états `aria-pressed` sur chaque option. Les préférences sont stockées uniquement dans le `localStorage` du navigateur et réappliquées **avant le premier rendu** des pages suivantes — aucun flash visuel, aucune donnée transmise à vos serveurs.
### Le contraste élevé intelligent
Contrairement aux widgets classiques qui forcent un fond blanc sur tous les éléments (et font disparaître sliders et bandeaux), le mode analyse le DOM à l'activation :
- les fonds de **couleur unie** opaques sont blanchis ;
- les éléments portant une **image de fond** sont préservés : leurs textes reçoivent une plaque blanche semi-opaque qui garantit la lisibilité par-dessus le visuel ;
- les textes passent en noir, les liens en bleu foncé souligné, les contrôles interactifs reçoivent une bordure noire de 2px.
La désactivation retire tous les styles appliqués et restaure le thème à l'identique.
## Les corrections automatiques en détail
### Textes alternatifs (WCAG 1.1.1)
Pour chaque image sans attribut `alt`, le module applique dans l'ordre :
1. si l'image est dans un lien déjà porteur de texte : `alt` vide (image décorative) ;
2. sinon, la légende `figcaption` ou l'attribut `title` ;
3. sinon, le titre du produit de la miniature environnante ;
4. en dernier recours, le nom de fichier nettoyé (tirets remplacés, suites de chiffres retirées) si le résultat est signifiant.
La correction automatique est un filet de sécurité. Pour vos images produits importantes, rédigez des textes alternatifs à la main dans votre catalogue : ils seront toujours prioritaires puisque le module ne touche jamais aux `alt` existants.
### Formulaires (WCAG 1.3.1, 4.1.2)
Les champs sans `label` associé, sans `aria-label` ni `title` reçoivent un `aria-label` déduit du placeholder, ou à défaut du nom du champ humanisé.
### Liens et iframes (WCAG 3.2.5, 4.1.2)
Les liens `target=_blank` reçoivent `rel=noopener` et un `aria-label` complété par la mention « s'ouvre dans une nouvelle fenêtre ». Les iframes sans titre reçoivent un `title` mentionnant le domaine embarqué.
### Structure et navigation (WCAG 1.3.1, 2.4.1, 2.4.7)
Rôles ARIA ajoutés lorsque le thème ne les déclare pas, lien d'évitement injecté en tout début de page, et contour de focus imposé sur tous les éléments interactifs via `:focus-visible`.
### Correction automatique du contraste (WCAG 1.4.3)
Le moteur parcourt les textes visibles, calcule la luminance relative du texte et de son fond effectif, puis assombrit ou éclaircit progressivement les couleurs dont le ratio est inférieur à 4,5. L'analyse est plafonnée à 1500 éléments et s'exécute via `requestIdleCallback` pendant les temps morts du navigateur.
Cette correction modifie les couleurs de texte définies par votre thème. Activez-la, vérifiez le rendu sur vos pages clés, puis conservez-la si le résultat vous convient. Elle est désactivée par défaut pour cette raison.
## Déclaration d'accessibilité EAA
La publication d'une déclaration d'accessibilité est une obligation formelle de la directive. Depuis la configuration du module, cliquez sur **Générer la page de déclaration** : une page CMS est créée dans chaque langue active de votre boutique (modèles FR, EN, ES, DE, IT inclus, repli anglais pour les autres langues), avec :
- l'état de conformité au regard de la Directive (UE) 2019/882 et de la norme EN 301 549 ;
- la liste des fonctionnalités d'accessibilité proposées ;
- le canal de signalement pointant vers votre formulaire de contact ;
- les voies de recours vers l'autorité nationale compétente.
Le lien vers la déclaration apparaît automatiquement en bas du panneau du widget. Après une mise à jour du module ou un changement de nom de boutique, cliquez sur **Mettre à jour la page de déclaration** pour actualiser la page existante sans changer son URL.
## Statistiques et preuve de diligence
Le tableau de la page de configuration affiche, sur les 30 derniers jours et par type, le nombre de corrections appliquées : textes alternatifs, étiquettes de formulaires, liens externes, titres d'iframes, repères ARIA, liens d'évitement et corrections de contraste. En cas de contrôle ou de signalement, ces compteurs documentent les mesures techniques mises en place. Le bouton **Réinitialiser les statistiques** purge les compteurs de la boutique courante.
En multiboutique, les statistiques et la déclaration sont gérées par contexte de boutique.
## Bonnes pratiques et limites
Le module corrige les défauts techniques les plus fréquents, mais certains critères WCAG restent de nature éditoriale et vous appartiennent :
- hiérarchie logique des titres h1-h6 dans vos contenus CMS et fiches produits ;
- qualité rédactionnelle des textes alternatifs de vos images clés ;
- sous-titrage de vos vidéos ;
- intelligibilité des libellés de vos boutons et liens.
Aucun outil automatique ne rend un site « 100% conforme ». Le module vous donne une base technique solide et documentée ; complétez-la par une relecture éditoriale de vos pages clés.
## Dépannage
- **Le bouton n'apparaît pas** — vérifiez que le widget est activé, que le hook `displayBeforeBodyClosingTag` n'est pas désactivé par votre thème, et videz le cache PrestaShop (Paramètres avancés > Performances).
- **Les préférences ne persistent pas** — le visiteur navigue probablement en mode privé ou son navigateur bloque le `localStorage` ; le widget reste utilisable, seule la persistance est perdue.
- **Le contraste élevé laisse une zone incohérente** — certains éléments injectés dynamiquement après le chargement (widgets tiers) échappent à la passe d'analyse. Désactivez puis réactivez le mode, ou signalez le cas au support avec l'URL concernée.
- **Aucune statistique ne remonte** — vérifiez que la collecte est activée et qu'aucun bloqueur côté serveur ne filtre les requêtes vers le contrôleur `track` du module.
## Désinstallation
La désinstallation supprime la table de statistiques et les clés de configuration. La page CMS de déclaration d'accessibilité est volontairement conservée (elle reste une obligation légale) : supprimez-la manuellement depuis **Apparence > Pages** si vous ne souhaitez pas la garder.
---
### Achat Groupé & Prix Dégressif Collectif — Guide complet
_Source :_
> Présentation et prérequis Achat Groupé instaure un prix dégressif collectif : plus il y a d'acheteurs sur un produit, plus le prix unitaire baisse pour tout le monde. Vous définissez…
## Présentation et prérequis
Achat Groupé instaure un prix dégressif collectif : plus il y a d'acheteurs sur un produit, plus le prix unitaire baisse pour tout le monde. Vous définissez des paliers (un seuil d'acheteurs débloque un prix), et le module applique automatiquement le prix du palier atteint via les prix spécifiques natifs de PrestaShop. Le tarif courant s'affiche donc partout sans la moindre modification de votre thème : fiche produit, listings, panier et e-mails.
- Compatible PrestaShop 8.0 à 9.x, thème Classic et thèmes dérivés.
- PHP 7.4 à 8.3.
- Multiboutique et multilingue (FR/EN/ES/DE/IT).
- Aucune tâche CRON requise : le recalcul est piloté par les évènements de commande.
- Architecture conforme PrestaShop (ModuleAdminController, ObjectModel), sans dépendance Composer.
Le prix courant est poussé dans un **prix spécifique** calé sur les dates de la campagne. Il s'applique donc nativement à tout l'affichage, sans surcharge de template.
## Installation
Installez le module comme n'importe quel module PrestaShop :
1. Téléchargez l'archive `dfgroupbuy-1.0.2.zip` depuis votre compte client.
2. Dans le back-office, allez dans **Modules > Gestionnaire de modules**.
3. Cliquez sur **Installer un module** et déposez l'archive.
4. Une fois installé, cliquez sur **Configurer**.
À l'installation, le module crée ses tables (campagnes, paliers, participants), enregistre ses hooks et ajoute l'onglet **Achat Groupé** sous Catalogue. Vous pouvez créer votre première campagne immédiatement.
## Réglages généraux du module
La page de configuration regroupe les réglages globaux, communs à toutes les campagnes :
- **Couleur principale** et **couleur d'accent** : appliquées au widget de la fiche produit (barre de progression, badges, prix courant).
- **Envoyer un e-mail lors d'un remboursement rétroactif** : notifie l'acheteur quand un bon lui est attribué.
- **Durée de validité des bons** : nombre de jours de validité des bons rétroactifs (30 par défaut).
- **Intervalle de rafraîchissement** : fréquence de mise à jour en direct du widget, en secondes (30 par défaut).
## Créer une campagne d'achat groupé
Depuis l'onglet **Catalogue > Achat Groupé**, cliquez sur **Ajouter une campagne**. Une campagne associe un produit à une grille de paliers, sur une fenêtre de dates.
- **Référence** : identifiant interne de la campagne (libre).
- **Produit** : recherchez et sélectionnez le produit concerné. Vous pouvez cibler une **déclinaison précise** ou laisser « toutes les déclinaisons ».
- **Nom et description** : textes traduisibles, affichés dans le widget.
- **Mode de comptage** : voir la section dédiée ci-dessous.
- **Commandes valides uniquement** : ne compte que les commandes confirmées (recommandé).
- **Prix de référence** : le prix de départ (barré) avant tout palier.
- **Date de début / fin** : fenêtre d'activité de la campagne.
- **Remboursement rétroactif** : voir la section dédiée.
- **Active** : active ou suspend la campagne.
### Définir les paliers
Chaque palier associe un **seuil** (nombre d'acheteurs, d'unités ou de clients selon le mode) à un **prix unitaire HT**. Ajoutez autant de paliers que nécessaire, par exemple :
```
10 acheteurs → 18,00 € HT
50 acheteurs → 15,00 € HT
100 acheteurs → 12,00 € HT
```
À chaque enregistrement, le module recalcule le palier courant et met à jour le prix spécifique. Les prix doivent être décroissants à mesure que le seuil augmente.
Le prix de référence et les prix de palier sont saisis **hors taxes**. La conversion en TTC pour l'affichage suit les règles de taxe du produit.
## Les modes de comptage
Le mode de comptage détermine ce qui fait progresser le compteur collectif :
- **Commandes** : nombre de commandes distinctes contenant le produit.
- **Unités vendues** : quantité totale d'unités du produit vendues.
- **Clients distincts** : nombre de clients différents ayant acheté le produit.
L'option **Commandes valides uniquement** restreint le comptage aux commandes considérées comme valides par PrestaShop (paiement accepté, etc.), ce qui évite de compter des commandes annulées ou en attente.
## Le prix collectif en temps réel
Dès qu'une commande est validée ou change de statut, le module recompte la campagne, détermine le palier atteint et met à jour le prix spécifique appliqué à tous les acheteurs. Le nouveau prix s'affiche immédiatement partout, sans intervention. Aucun CRON n'est nécessaire : tout est piloté par les évènements de commande.
Si une commande passe en statut annulé ou remboursé et que vous comptez les commandes valides, le compteur est recalculé à la baisse et le prix peut remonter si le palier n'est plus atteint.
## Prix par palier de quantité (achat en gros)
En mode **Unités vendues**, un client qui commande une grande quantité d'un coup franchit seul un palier : il obtient alors immédiatement le prix de ce palier sur sa propre commande, sans attendre que le collectif l'atteigne. Par exemple, avec un palier à 10 unités, un client qui met 10 exemplaires au panier paie tout de suite le prix du palier 10.
Cette logique reste « meilleur prix pour tous » : si le prix collectif courant est déjà plus bas que le prix du palier de quantité, c'est le prix collectif qui s'applique. Tout passe par les prix spécifiques natifs (par paliers de quantité), donc le bon tarif s'affiche dès le panier.
Cette mécanique ne s'active qu'en mode **Unités vendues**, où les seuils représentent des unités. En mode Commandes ou Clients, un achat en gros reste une seule commande ou un seul client.
## Remboursement rétroactif
Quand l'option est activée, le principe « tout le monde au meilleur prix » s'applique : dès qu'un palier inférieur se débloque, les acheteurs précédents reçoivent automatiquement un bon de réduction égal à la différence entre le prix qu'ils ont payé et le nouveau prix, multiplié par la quantité achetée. Un e-mail de notification est envoyé si l'option d'envoi est active.
- Le bon est un code de réduction (CartRule) nominatif, valable le nombre de jours configuré.
- Seuls les acheteurs ayant payé plus cher que le nouveau prix reçoivent un bon.
- Le prix effectif de chaque participant est mis à jour pour éviter tout double remboursement lors des baisses suivantes.
Le remboursement rétroactif crée de véritables bons de réduction. Vérifiez votre grille de paliers avant d'activer une campagne à fort volume afin de maîtriser le montant total des remboursements.
## Le widget sur la fiche produit
Sur la fiche produit, le module affiche un widget qui met en scène la dynamique collective :
- Un badge et le prix de référence barré face au prix courant.
- Le compteur collectif et une barre de progression vers le prochain palier.
- L'échelle complète des paliers, le palier courant étant mis en avant.
- Un compte à rebours jusqu'à la fin de la campagne.
- Une note sur le remboursement rétroactif quand l'option est active.
L'ensemble se rafraîchit en direct par AJAX, à l'intervalle défini dans les réglages, sans rechargement de page.
## FAQ et dépannage
### Le widget ne s'affiche pas sur le produit
Vérifiez qu'une campagne **active** cible bien ce produit, que la date du jour est comprise entre la date de début et la date de fin, et que la campagne appartient à la boutique courante. Si vous ciblez une déclinaison précise, le widget n'apparaît que pour cette déclinaison.
### Le prix ne baisse pas alors que le seuil est atteint
Le recalcul est déclenché par la validation des commandes et les changements de statut. Si vous comptez les commandes valides, assurez-vous que les commandes concernées sont bien dans un état valide. Une simple modification puis sauvegarde de la campagne force également un recalcul.
### Un gros acheteur n'obtient pas le prix de sa quantité
Le prix par palier de quantité ne fonctionne qu'en mode **Unités vendues**, et pour des seuils supérieurs ou égaux à 2. En mode Commandes ou Clients, la quantité d'une commande ne franchit pas de palier à elle seule.
### Fonctionne-t-il avec les déclinaisons ?
Oui. Une campagne peut cibler une déclinaison précise ou toutes les déclinaisons d'un produit. Une campagne ciblant une déclinaison précise prime sur une campagne « toutes déclinaisons ».
### Que se passe-t-il à la désinstallation ?
La désinstallation retire les prix spécifiques créés par le module, supprime ses hooks et son onglet, et nettoie ses tables. Les bons de réduction déjà émis restent valables côté clients.
---
### AEO Monitor & Optimizer — Guide complet
_Source :_
> Présentation AEO Monitor & Optimizer mesure la visibilité de votre marque dans les réponses de cinq assistants IA — ChatGPT (OpenAI), Claude (Anthropic), Perplexity, Gemini (Google) et Mistral — puis…
## Présentation
AEO Monitor & Optimizer mesure la visibilité de votre marque dans les réponses de cinq assistants IA — ChatGPT (OpenAI), Claude (Anthropic), Perplexity, Gemini (Google) et Mistral — puis génère des recommandations concrètes pour l'améliorer. Le plugin envoie vos prompts de surveillance à chaque LLM activé, analyse les réponses (mentions de marque, citations de domaine, URL exactes, concurrents), calcule un score de visibilité de 0 à 100 et sert un fichier llms.txt dynamique.
Le plugin fonctionne en modèle BYOK (Bring Your Own Key) : vous utilisez vos propres clés API et les appels partent directement de votre serveur vers les API officielles. Aucune donnée ne transite par DataFirefly.
## Prérequis
- WordPress 6.0 ou supérieur (testé jusqu'à 6.7)
- PHP 7.4 ou supérieur (8.1+ recommandé)
- WooCommerce 7.0+ uniquement pour le suivi automatique des produits et la génération de prompts par catégorie (optionnel)
- Au moins une clé API parmi : OpenAI, Anthropic, Perplexity, Google Gemini, Mistral
- WP-Cron fonctionnel (ou un cron système appelant wp-cron.php) pour les audits planifiés
## Installation
1. Téléchargez le fichier ZIP depuis votre compte client DataFirefly.
2. Dans l'admin WordPress, allez dans **Extensions → Ajouter → Téléverser une extension**, sélectionnez le fichier dfaeomonitor.zip puis cliquez sur **Installer maintenant**.
3. Cliquez sur **Activer**. Le plugin crée automatiquement ses 6 tables de base de données et planifie le cron d'audit hebdomadaire.
4. Rendez-vous dans **Réglages → Permaliens** et cliquez sur **Enregistrer** (sans rien modifier) afin de rafraîchir les règles de réécriture pour l'URL llms.txt.
Un menu **AEO Monitor** apparaît dans la barre latérale de l'admin avec six pages : Tableau de bord, Prompts, Résultats, Pages suivies, Recommandations et Réglages.
## Configuration initiale
### 1. Marque et site
Dans **AEO Monitor → Réglages**, renseignez :
- **Nom de marque** : le nom exact que les LLM devraient citer.
- **Alias / variantes** : autres orthographes ou noms commerciaux (un par ligne). Chaque alias compte comme une mention de marque.
- **Domaine principal** : votre domaine sans http ni www (exemple : maboutique.com). Toute citation d'URL de ce domaine compte comme citation de domaine.
- **Concurrents** : une marque par ligne. Le plugin détecte quand un LLM parle d'eux à votre place et applique une pénalité au score.
### 2. Fournisseurs LLM
Toujours dans les Réglages, activez les fournisseurs que vous voulez interroger et collez la clé API correspondante :
- **OpenAI** — clé depuis platform.openai.com. Modèle recommandé pour la veille : gpt-4o-mini. Le plugin utilise l'API Responses avec l'outil de recherche web.
- **Anthropic** — clé depuis console.anthropic.com. L'appel utilise l'API Messages avec l'outil de recherche web.
- **Perplexity** — clé depuis perplexity.ai. Modèle sonar-pro avec citations natives : le fournisseur le plus riche en sources.
- **Google Gemini** — clé depuis Google AI Studio. Le grounding Google Search est activé automatiquement.
- **Mistral** — clé depuis console.mistral.ai. Recherche web quand disponible, sinon repli sur les connaissances internes du modèle.
Une seule API suffit pour démarrer, mais trois fournisseurs ou plus donnent une vision représentative. Un audit hebdomadaire de 10 prompts sur 5 LLM (50 appels) coûte typiquement entre 0,30 et 1,20 euros avec les modèles économiques.
### 3. Planification
- **Cadence d'audit** : hebdomadaire (recommandé) ou quotidienne.
- **Prompts max par audit** : plafond de prompts envoyés à chaque exécution. Rappel : chaque prompt est envoyé à chaque LLM activé.
- **Timeout requête** : durée maximale d'un appel API (45 secondes par défaut).
- **Suivi automatique** : cochez pour suivre automatiquement chaque nouveau produit WooCommerce publié et, si vous le souhaitez, chaque nouvelle page.
- **llms.txt dynamique** : active la réponse du site sur l'URL llms.txt.
## Créer et gérer les prompts
Un prompt est une question posée telle quelle aux LLM, formulée comme un utilisateur réel la poserait. Exemples : « Quels sont les meilleurs modules SEO pour PrestaShop ? », « Quelle boutique recommandes-tu pour acheter des sneakers en cuir en France ? »
Dans **AEO Monitor → Prompts** vous pouvez :
- **Créer un prompt manuellement** avec un libellé interne, le texte de la question, une intention (marque, produit, catégorie, concurrent, informationnel), une langue, et optionnellement une URL cible dont vous voulez suivre la citation.
- **Générer des prompts par défaut** : le bouton dédié crée automatiquement des prompts de marque et un prompt par catégorie WooCommerce, dans la langue du site.
- **Activer / désactiver** un prompt sans le supprimer : seuls les prompts actifs sont envoyés lors des audits.
Associer une URL cible à un prompt permet de mesurer précisément si les LLM renvoient vers la bonne page — le score gagne 20 points quand l'URL exacte est citée.
## Lancer un audit
Trois façons de déclencher un audit :
1. **Bouton « Lancer un audit maintenant »** sur le tableau de bord — l'exécution démarre en tâche de fond dans les secondes qui suivent.
2. **Cron planifié** — automatique selon la cadence choisie dans les réglages.
3. **WP-CLI** — la commande wp dfaeo audit exécute l'audit de façon synchrone avec le détail dans le terminal.
Pendant l'audit, chaque prompt actif est envoyé à chaque fournisseur activé avec une temporisation de 300 ms entre les appels. Les réponses sont stockées, analysées puis les recommandations sont générées automatiquement en fin d'exécution.
## Comprendre le score de visibilité
Chaque réponse LLM reçoit un score de 0 à 100 calculé ainsi :
- +30 points si votre marque est mentionnée, plus un bonus jusqu'à +15 selon le nombre de répétitions
- +25 points si votre domaine est cité dans les sources
- +20 points si l'URL cible exacte du prompt est citée
- +5 points si la réponse contient des sources
- Pénalité jusqu'à -15 points selon le nombre de mentions de concurrents
Le tableau de bord agrège ces scores : moyenne globale, taux de mention de marque, taux de citation du domaine, évolution sur 7, 30 ou 90 jours et comparaison des cinq plateformes.
## Pages suivies et score de couverture
La page **Pages suivies** liste les URL dont vous surveillez l'indexation par les LLM. Le score de couverture d'une page augmente chaque fois qu'un LLM cite son URL exacte et décroît légèrement à chaque audit sans citation (facteur 0,98), ce qui reflète la fraîcheur réelle de votre présence.
- Les produits WooCommerce publiés sont ajoutés automatiquement si l'option est active.
- Vous pouvez ajouter manuellement n'importe quelle URL avec un type (page, produit, article, catégorie) et une priorité de 1 à 10.
- Les pages à priorité élevée mais score faible génèrent automatiquement des recommandations.
## Recommandations
Après chaque audit, le moteur de recommandations analyse les pages en difficulté et propose des actions classées par sévérité (haute, moyenne, basse) :
- **FAQ JSON-LD** — bloc de code prêt à coller dans l'en-tête de la page, avec questions-réponses générées à partir du contenu.
- **Schéma Product** — données structurées enrichies pour les fiches WooCommerce (prix, disponibilité, avis) hydratées depuis les vraies données produit.
- **Résumé TL;DR** — un paragraphe de 60 à 80 mots à placer en tête de contenu, format que les LLM extraient volontiers.
- **Schéma Organization** — identité de marque renforcée pour limiter les confusions et hallucinations sur votre entreprise.
- **robots.txt** — règles d'autorisation pour les crawlers IA : GPTBot, ClaudeBot, PerplexityBot, Google-Extended.
- **Priorité llms.txt** — promotion d'une page stratégique dans le fichier llms.txt dynamique.
Chaque recommandation peut être marquée En cours, Résolue ou Ignorée. Le code proposé s'affiche dans un bloc dépliable prêt à copier.
## Le fichier llms.txt dynamique
Quand l'option est active, votre site répond sur l'URL llms.txt avec un index Markdown généré en continu :
- **Top references** — les pages les mieux détectées par les LLM, classées par score de couverture.
- **Priority pages** — les pages à priorité 5 ou plus pas encore bien détectées.
- **Catalog** — vos catégories WooCommerce principales.
- **About** — nom de marque, URL du site et contact.
Si l'URL llms.txt renvoie une 404, ré-enregistrez les permaliens dans Réglages → Permaliens. Le filtre dfaeo_llmstxt_lines permet aux développeurs de modifier les lignes générées.
## WP-CLI
Trois commandes sont disponibles pour l'automatisation :
```
« wp dfaeo audit » lance un audit synchrone (option --prompts=5 pour limiter)
« wp dfaeo seed » génère les prompts par défaut depuis la marque et les catégories
« wp dfaeo report --days=30 » affiche le rapport agrégé (option --format=json ou csv)
```
La commande report est idéale pour alimenter un outil de BI ou un tableau de bord externe via une tâche cron système.
## Résolution des problèmes
- **« Aucun audit n'a pu démarrer »** — vérifiez qu'au moins un fournisseur est activé avec une clé API valide et qu'au moins un prompt est actif.
- **Erreurs 401 / 403 dans les résultats** — la clé API du fournisseur concerné est invalide ou expirée. Les erreurs sont visibles dans le détail de chaque résultat.
- **Erreurs 429** — quota API atteint chez le fournisseur. Réduisez le nombre de prompts par audit ou passez à la cadence hebdomadaire.
- **Le cron ne se déclenche pas** — sur les sites à faible trafic, WP-Cron ne s'exécute que lors des visites. Configurez un cron système appelant wp-cron.php toutes les 15 minutes.
- **llms.txt en 404** — ré-enregistrez les permaliens ou désactivez puis réactivez le plugin.
- **Graphiques vides sur le tableau de bord** — normal avant le premier audit terminé. Vérifiez aussi qu'aucun bloqueur de scripts n'empêche le chargement de Chart.js depuis le CDN jsdelivr.
## Désinstallation
La désactivation conserve toutes vos données. La suppression du plugin depuis la page Extensions déclenche le nettoyage complet : les 6 tables (prompts, runs, results, citations, pages, recommendations), les options et les tâches cron sont supprimées définitivement.
## Confidentialité et RGPD
Le plugin n'envoie aucune donnée à DataFirefly et n'embarque aucune télémétrie. Les seuls appels sortants vont vers les API des LLM que vous avez activés, avec vos clés. Les prompts que vous rédigez sont transmis à ces fournisseurs tiers : évitez d'y inclure des données personnelles de clients. Les clés API sont stockées dans la table d'options WordPress de votre base de données.
---
### Agent IA Service Client — Documentation complète
_Source :_
> Guide complet du plugin DataFirefly AI Customer Service Agent pour WooCommerce : installation, configuration Claude/OpenAI, personnalisation du widget, outils de l'agent, escalade Slack et email, multilingue, sécurité RGPD, hooks développeur.
Guide complet d'installation, de configuration et d'utilisation du plugin **DataFirefly AI Customer Service Agent** — un agent IA de support client pour WooCommerce qui comprend le contexte, appelle des outils en lecture seule sur votre boutique, et escalade intelligemment les cas complexes vers Slack et email.
**À qui s'adresse ce plugin ?** Aux boutiques WooCommerce qui reçoivent des dizaines à des centaines de tickets par semaine, dont la majorité concerne le statut de commande, la livraison, les retours et les tailles. L'agent traite automatiquement environ 70 % de ces demandes de niveau 1 en 5 langues, et transmet le reste à un humain avec le contexte complet.
## 1. Prérequis
- **WordPress** 6.4 ou supérieur
- **WooCommerce** 8.0 ou supérieur
- **PHP** 8.1, 8.2 ou 8.3
- Une **clé API** Anthropic (Claude) _ou_ OpenAI (recommandé : Claude Sonnet 4.5)
- Optionnel : un webhook Slack pour l'escalade en temps réel
- Optionnel : Polylang Pro ou WPML si votre boutique est multilingue
## 2. Installation
### Installation du ZIP
1. Depuis votre compte DataFirefly, téléchargez le fichier `df-ai-customer-service.zip`
2. Dans WordPress, allez dans **Extensions → Ajouter une extension → Téléverser une extension**
3. Sélectionnez le ZIP puis cliquez sur **Installer**
4. Cliquez sur **Activer** une fois l'installation terminée
### Que se passe-t-il à l'activation ?
Le plugin crée automatiquement 5 tables dans la base de données préfixées `wp_dfaics_` : conversations, messages, escalations, faq, analytics. Il déclare également la compatibilité HPOS et les blocs Gutenberg cart/checkout, puis planifie une tâche cron quotidienne pour nettoyer les conversations expirées.
Après activation, un nouveau menu **AI Support** apparaît dans la sidebar de l'admin WordPress avec 4 sous-pages : Dashboard, Conversations, FAQ, Réglages.
## 3. Configuration du provider IA
Le plugin supporte deux providers IA. Vous choisissez celui que vous préférez dans **AI Support → Réglages → IA**. Vous fournissez votre propre clé API — DataFirefly n'intercepte rien et ne prélève aucune commission sur votre consommation.
### Option A : Claude (recommandé)
1. Créez un compte sur [console.anthropic.com](https://console.anthropic.com)
2. Générez une clé API dans **Settings → API Keys**
3. Copiez la clé (commence par `sk-ant-...`)
4. Dans WordPress, allez dans **AI Support → Réglages → IA**
5. Sélectionnez le provider **Anthropic (Claude)**
6. Collez votre clé dans le champ _Clé API Anthropic_
7. Modèle par défaut : `claude-sonnet-4-5` (excellent rapport qualité / coût)
8. Cliquez sur **Tester la clé** pour valider
9. Enregistrez
### Option B : OpenAI
1. Créez un compte sur [platform.openai.com](https://platform.openai.com)
2. Générez une clé API dans **API Keys**
3. Copiez la clé (commence par `sk-...`)
4. Dans WordPress, sélectionnez le provider **OpenAI**
5. Modèle par défaut : `gpt-4o-mini` (le plus économique avec tool calling fiable)
**Sécurité.** Les clés API sont chiffrées au repos en AES-256-CBC avec une clé dérivée de `AUTH_KEY` et `AUTH_SALT` (constantes de votre `wp-config.php`). Elles ne sont plus jamais affichées en clair après la première saisie. Si vous changez `AUTH_KEY`, vous devrez ressaisir vos clés.
### Coût indicatif
Une conversation typique de 5 à 10 échanges avec tool calling coûte :
- Environ **0,01 à 0,05 USD** avec Claude Sonnet 4.5
- Environ **0,005 à 0,02 USD** avec GPT-4o mini
Le dashboard affiche le total des tokens input/output consommés sur la période.
## 4. Configuration du widget
Le widget de chat s'affiche par défaut en bas à droite sur toutes les pages du site frontend. Personnalisez-le dans **AI Support → Réglages → Widget**.
### Options d'apparence
- **Couleur principale** — Couleur du bouton flottant et du header (par défaut `#0073aa`)
- **Couleur du texte** — Couleur du texte dans le header (par défaut blanc)
- **Position** — Bas à droite ou bas à gauche
- **Titre du widget** — Ex. « Besoin d'aide ? »
- **Message de bienvenue** — Premier message affiché à l'ouverture
- **Placeholder** — Texte du champ de saisie
- **Afficher le badge DataFirefly** — Petite mention en bas du widget
### Affichage conditionnel
Dans l'onglet **Widget**, vous pouvez limiter l'affichage :
- **Toutes les pages** — Comportement par défaut
- **Pages produit uniquement** — Pour un support ciblé sur les fiches
- **Sauf panier et checkout** — Éviter la distraction pendant l'achat
- **Masquer sur ces IDs de contenu** — Liste d'IDs à exclure
### Shortcode
Vous pouvez également intégrer le chat dans une page ou un article avec le shortcode :
```
[dfaics_chat]
```
Cela affiche le widget en mode intégré (non flottant), pratique pour une page « Nous contacter » dédiée.
## 5. Les 6 outils de l'agent
L'agent dispose de 6 outils qu'il choisit d'appeler ou non en fonction de la question. Tous sont **strictement en lecture seule**. Vous les activez ou désactivez individuellement dans **Réglages → Comportement**.
### lookup_order
Récupère le statut d'une commande WooCommerce. **Nécessite une vérification email obligatoire** avant divulgation : l'agent demande l'email au client et le confronte à celui de la commande. Retourne le numéro, statut, montant, date, méthode de livraison, numéro de suivi si disponible.
### search_products
Recherche dans le catalogue par nom, catégorie, tag, disponibilité, gamme de prix. Retourne jusqu'à 5 résultats par défaut avec titre, SKU, prix, URL, stock. Utile pour répondre à « avez-vous ceci en bleu ? » ou « quel est le prix de X ? ».
### get_shipping_info
Retourne les zones et méthodes de livraison configurées dans WooCommerce, avec les frais et délais. L'agent peut ainsi répondre précisément à « livrez-vous en Belgique ? » ou « combien coûte l'express ? ».
### get_returns_policy
Retourne le contenu de votre politique de retour (que vous configurez dans les réglages). L'agent peut expliquer le délai, la procédure et les conditions.
### search_faq
Cherche dans vos FAQ personnalisées (gérées dans **AI Support → FAQ**). Résultats scopés par langue de la conversation. Chaque entrée trouvée incrémente un compteur d'usage pour vous aider à identifier les questions les plus fréquentes.
### escalate_to_human
L'agent appelle cet outil quand il détermine qu'un cas nécessite un humain (frustration client, cas complexe, plusieurs échecs d'outils). Déclenche les notifications Slack et / ou email configurées. Voir la section _Escalade_ plus bas.
**Sécurité par design.** Aucun outil n'écrit dans la base. Le plugin ne peut ni modifier une commande, ni rembourser, ni changer un mot de passe, ni envoyer d'email au client. Toute action de ce type doit passer par un opérateur humain via escalade.
## 6. Gestion de la FAQ
Créez des entrées de FAQ personnalisées que l'agent pourra rechercher pendant une conversation. Chaque entrée est **scopée par langue**.
### Créer une entrée
1. Allez dans **AI Support → FAQ**
2. Cliquez sur **Ajouter une entrée**
3. Choisissez la langue
4. Rédigez la question et la réponse en langage naturel
5. Ajoutez des mots-clés séparés par des virgules (facultatif, améliore la recherche)
6. Choisissez une catégorie (ex. livraison, tailles, garantie)
7. Enregistrez
### Bonnes pratiques FAQ
- Formulez les questions comme un client les poserait, pas comme un rédacteur SEO
- Réponses courtes et actionnables (2 à 4 phrases suffisent, l'agent reformule)
- Créez une entrée par langue majeure de votre clientèle
- Consultez régulièrement le compteur d'usage pour identifier les questions à enrichir
## 7. Escalade vers un humain
L'escalade se configure dans **Réglages → Escalade**. Deux canaux sont supportés en parallèle : Slack et email.
### Configuration Slack
1. Dans Slack, créez une nouvelle app sur [api.slack.com/apps](https://api.slack.com/apps)
2. Activez **Incoming Webhooks**
3. Créez un webhook vers le canal souhaité (ex. `#support-escalations`)
4. Copiez l'URL du webhook
5. Dans WordPress, collez-la dans _Webhook Slack_
6. Cliquez sur **Tester le webhook** pour envoyer un message de test
Chaque escalade envoie à Slack un message en blocs riches contenant : l'extrait des 3 derniers messages, le motif d'escalade, les métadonnées client (email vérifié, langue, page d'origine), et un bouton **Ouvrir dans l'admin** qui pointe directement vers le détail de la conversation.
### Configuration email
Dans _Email d'escalade_, indiquez une ou plusieurs adresses séparées par des virgules. Chaque escalade envoie un email HTML contenant la transcription complète, les données client et un lien vers l'admin.
### Déclencheurs d'escalade
L'agent escalade dans 3 situations :
1. **Mots-clés sensibles** — Liste configurable (par défaut : remboursement, avocat, cassé, réclamation, complaint, refund, lawyer, broken)
2. **Seuil de sentiment** — Détection de frustration ou de mécontentement (paramétrable de -1 à 0)
3. **Échec répété d'outils** — Après 6 tours sans résolution, escalade forcée
L'agent peut aussi escalader de sa propre initiative si le mot-clé n'est pas déclenché mais qu'il juge le cas hors de sa compétence. C'est le comportement natif du tool calling.
## 8. Dashboard et analytics
Le tableau de bord **AI Support → Dashboard** affiche 4 indicateurs clés :
- **Volume** — Nombre total de conversations sur les 7, 30 ou 90 derniers jours
- **Taux d'auto-résolution** — % de conversations qui se terminent sans escalade
- **Satisfaction moyenne** — Note en étoiles données par les clients après escalade
- **Tokens consommés** — Input + output cumulés pour l'estimation du coût IA
La page **Conversations** liste toutes les sessions avec filtres (langue, statut, escalade oui/non). Cliquez sur une ligne pour voir le transcript complet avec les tool calls détaillés en JSON.
## 9. Multilingue
Le plugin supporte nativement 5 langues : français, anglais, espagnol, allemand, italien. La langue de la conversation est résolue automatiquement dans cet ordre :
1. Langue Polylang de la page où le widget s'affiche (si Polylang installé)
2. Langue WPML de la page (si WPML installé)
3. Locale du navigateur du visiteur
4. Langue de repli configurée dans les réglages (par défaut : anglais)
Le system prompt de l'agent indique explicitement au modèle la langue de réponse attendue. Cela garantit qu'un visiteur français reçoit une réponse en français, même si votre boutique est majoritairement anglaise.
## 10. Sécurité et confidentialité
### Chiffrement des clés API
Les clés Anthropic, OpenAI et le webhook Slack sont chiffrés en AES-256-CBC au moment de leur enregistrement, avec une clé dérivée de `AUTH_KEY` + `AUTH_SALT`. Le champ input ne réaffiche jamais la valeur : en laissant le champ vide et en enregistrant, l'ancienne valeur est préservée.
### Vérification email pour les commandes
L'outil `lookup_order` exige obligatoirement une vérification : l'agent demande au client son email, et le confronte à celui associé à la commande. Sans correspondance, aucune donnée n'est divulguée. Ce comportement n'est pas désactivable — il protège contre le scraping de commandes via l'agent.
### Rate limiting
Un rate limit anti-spam de **5 messages par minute par session** est appliqué côté serveur. Le nombre maximum de messages par conversation est de 25 par défaut (configurable). Au-delà, l'agent propose une escalade humaine.
### Rétention et RGPD
Les conversations sont conservées 30 jours par défaut, puis supprimées automatiquement par une tâche cron quotidienne. Vous pouvez réduire cette durée dans **Réglages → Confidentialité**. L'IP du visiteur et l'user agent peuvent être journalisés ou non selon votre politique.
Le plugin propose également une option _Anonymiser les PII dans les logs_ qui masque emails et numéros de téléphone dans les journaux techniques (WooCommerce logger).
**Aucune donnée n'est envoyée à DataFirefly.** Toutes les requêtes IA transitent directement entre votre WordPress et le provider (Anthropic ou OpenAI) que vous avez choisi, avec votre propre clé API. DataFirefly n'a aucun accès aux conversations.
## 11. Compatibilité HPOS et blocs de checkout
Le plugin déclare officiellement la compatibilité avec :
- **HPOS** (High-Performance Order Storage) — Toutes les requêtes commandes passent par les CRUDs WooCommerce officiels (`wc_get_order`, `wc_get_orders`), donc fonctionnent aussi bien sur les tables anciennes que sur les tables HPOS
- **Blocs Gutenberg cart et checkout** — Aucune interférence avec les nouveaux blocs de paiement
- **Multisite WordPress** — Activation réseau supportée, options scopées par site
## 12. Hooks et filtres pour développeurs
Le plugin expose plusieurs hooks pour personnaliser son comportement sans modifier le code source.
### Filtres disponibles
```
// Modifier le system prompt avant envoi au modèle
apply_filters('dfaics_system_prompt', $prompt, $context);
// Ajouter ou retirer des outils dynamiquement
apply_filters('dfaics_tools_available', $tools, $conversation);
// Modifier le seuil de messages max avant escalade forcée
apply_filters('dfaics_max_messages', 25, $conversation);
// Personnaliser le contenu de l'email d'escalade
apply_filters('dfaics_escalation_email_body', $html, $conversation);
// Enrichir les métadonnées Slack
apply_filters('dfaics_slack_metadata', $metadata, $conversation);
```
### Actions disponibles
```
// Après création d'une conversation
do_action('dfaics_conversation_created', $conversation_id, $session);
// Après envoi d'un message par l'agent
do_action('dfaics_message_sent', $message_id, $conversation_id);
// Après une escalade
do_action('dfaics_escalated', $conversation_id, $reason, $channel);
// Après nettoyage cron des conversations expirées
do_action('dfaics_cleanup_done', $deleted_count);
```
### Ajouter un outil personnalisé
Créez une classe qui étend `ToolBase` et enregistrez-la via le filtre `dfaics_tools_available`. Le namespace est `DataFireflyAiCustomerServiceAgentTools`. Chaque outil déclare son schéma JSON, sa description, et implémente une méthode `execute()` qui retourne un tableau associatif sérialisable.
## 13. Dépannage
### Le widget ne s'affiche pas
- Vérifiez que le widget est activé dans **Réglages → Widget → Activer le widget**
- Vérifiez la règle d'affichage conditionnel (pages autorisées)
- Ouvrez la console navigateur (F12) et cherchez des erreurs JS
- Videz le cache si vous utilisez un plugin de cache (WP Rocket, W3 Total Cache…)
### L'agent ne répond pas
- Vérifiez que la clé API est valide via le bouton **Tester la clé**
- Vérifiez votre crédit / quota sur le compte Anthropic ou OpenAI
- Consultez les logs WooCommerce dans **WooCommerce → Statut → Logs**, source `df-ai-customer-service`
### L'escalade Slack n'arrive pas
- Vérifiez le webhook via le bouton **Tester le webhook**
- Regénérez le webhook côté Slack si nécessaire
- Vérifiez que le canal cible existe et que le bot y a accès
### Réinitialiser complètement le plugin
Dans **Réglages → Confidentialité**, cochez _Supprimer toutes les données à la désinstallation_. Ensuite désactivez puis désinstallez le plugin : les 5 tables et les options sont supprimées.
## 14. FAQ technique
### Puis-je changer de provider IA sans perdre les conversations ?
Oui, la bascule Claude ↔ OpenAI est instantanée et n'affecte pas l'historique. Les nouvelles conversations utiliseront le nouveau provider.
### Le plugin fonctionne-t-il en mode headless ?
L'API REST du plugin (`/wp-json/dfaics/v1/`) est utilisable depuis n'importe quel front (Next.js, Vue, mobile). Le widget natif est en vanilla JS et peut être remplacé par votre propre implémentation qui appelle la même API.
### Peut-on brancher le plugin sur Zendesk ou Freshdesk ?
Pas nativement en 1.0.0 : l'escalade est limitée à Slack et email. Vous pouvez cependant utiliser le hook `dfaics_escalated` pour déclencher votre propre intégration.
### Est-ce que l'agent apprend de mes conversations ?
Non. Aucun fine-tuning n'est effectué. L'agent utilise uniquement le prompt système + les outils + le contexte de la conversation en cours. Vos données ne sont pas utilisées pour améliorer les modèles Anthropic ou OpenAI (les deux providers offrent une option d'opt-out qui est active par défaut sur leurs APIs professionnelles).
## 15. Support
Pour toute question ou signalement de bug, écrivez à **support at datafirefly.com** en indiquant votre numéro de licence. Nous répondons sous 48 h ouvrées.
---
### AI Act Ready — Installation, configuration et utilisation
_Source :_
> AI Act Ready vous aide à structurer votre mise en conformité avec le Règlement (UE) 2024/1689 sur l'intelligence artificielle, directement depuis le back-office PrestaShop : inventaire de vos systèmes IA,…
AI Act Ready vous aide à structurer votre mise en conformité avec le Règlement (UE) 2024/1689 sur l'intelligence artificielle, directement depuis le back-office PrestaShop : inventaire de vos systèmes IA, registre guidé, suivi des obligations, génération de documents en 6 langues et export auditeur consolidé.
AI Act Ready est un **outil de structuration, pas un certificat de conformité**. La conformité dépend de vos pratiques réelles. La classification de risque produite par le module est une indication opérationnelle, non un avis juridique opposable. Pour un système à risque élevé, l'avis d'un juriste qualifié est nécessaire.
## Prérequis
- PrestaShop 8 et 9 (8.0.0 minimum)
- PHP 7.4 minimum (8.1 à 8.3 recommandé)
- MySQL 5.7+ ou MariaDB 10.3+ (colonnes JSON)
- Extensions PHP : **gd** ou **imagick** (rendu PDF), **mbstring**, **json**, **openssl**
- Accès administrateur au back-office
Le module embarque dompdf dans son dossier vendor. Aucune dépendance externe ni Composer n'est requis en production.
## Installation
1. Téléchargez `datafirefly_aiact-1.0.0.zip` depuis votre commande sur datafirefly.com.
2. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**, puis cliquez sur **Uploader un module**.
3. Sélectionnez le ZIP et lancez l'installation.
4. À l'installation, le module crée ses tables, enregistre ses hooks et ajoute le menu **AI Act** avec ses 6 onglets dans la barre latérale.
## Activation de la licence
1. Ouvrez **AI Act > Licence & Paramètres**.
2. Saisissez la clé reçue par email, au format `DFAIA-PRO-XXXX-XXXX-XXXX`.
3. Cliquez sur **Activer la licence**. Le module contacte `license.datafirefly.com` en HTTPS et met en cache le résultat localement.
Mode **fail-open** : si le serveur de licence est temporairement injoignable, le module reste pleinement fonctionnel pendant 7 jours à partir du dernier contrôle réussi. Aucune coupure de service.
## Vue d'ensemble du back-office
Le menu AI Act comporte six onglets : **Tableau de bord**, **Registre IA**, **Obligations**, **Documents**, **Journal** et **Licence & Paramètres**. Le parcours conseillé suit cet ordre : scanner et compléter le registre, puis traiter les obligations, puis générer les documents.
## 1. Tableau de bord
Le tableau de bord offre une vue d'ensemble : indicateur de complétude de la démarche, nombre de systèmes IA inventoriés, obligations restantes et raccourcis vers les actions principales. C'est votre point d'entrée pour suivre l'avancement.
## 2. Registre IA
Le registre est le cœur du module : un enregistrement par système IA inventorié, conservé dans votre base PrestaShop.
### Scanner automatique
Le scanner compare vos modules installés à une base de signatures maintenue par DataFirefly. Il détecte environ 90 % des modules IA PrestaShop populaires et 100 % des modules DataFirefly. Les modules dont le nom ou le dossier contiennent des termes IA (chatbot, gpt, openai, llm, neural...) sont surfacés en statut **« à cadrer »** pour revue manuelle — ils ne sont jamais classés automatiquement.
Le scanner ne détecte pas les IA développées en interne (PHP inline, thème) ni les appels API serverless depuis le front. Ajoutez ces systèmes manuellement via **Registre > Ajouter manuellement**. Le scan est une aide au démarrage, pas une condition de conformité.
### Questionnaire de classification guidé
Pour chaque système, vous renseignez la finalité, le rôle AI Act (fournisseur, déployeur, importateur, distributeur), la base légale RGPD, le responsable interne et la date de mise en service. À partir de vos réponses, le module propose un niveau de risque (minimal, limité, élevé, interdit, GPAI) accompagné de sa justification.
## 3. Obligations
À partir de la classification, le module liste les obligations applicables à chaque système, avec l'article précis du règlement (Art. 50, Art. 4...) et la date d'entrée en vigueur. Les obligations s'organisent en kanban : **À faire / En cours / Fait / Non applicable**. Pour chaque obligation, vous pouvez ajouter une preuve (référence screenshot, PDF, URL interne).
La classification de risque s'appuie sur la méthodologie FLI (Future of Life Institute) et des extensions DataFirefly adaptées à PrestaShop. Elle n'a aucune valeur juridique formelle et ne saurait être opposée à une autorité de contrôle. En cas de contrôle, seules vos pratiques réelles et votre documentation comptent.
## 4. Documents
Le module génère quatre documents PDF, chacun dans **6 langues (FR, EN, ES, DE, IT, PT)** :
- **Politique IA interne** — synthèse du registre, finalités et gouvernance (Art. 4, Art. 26).
- **Charte AI literacy** — charte de formation du personnel aux systèmes IA (Art. 4).
- **DPIA light** — analyse d'impact pour les systèmes à risque limité.
- **Clauses CGV IA** — clauses prêtes à intégrer à vos conditions générales de vente (Art. 50).
Un bouton **« Générer le dossier audit »** produit un PDF auditeur consolidé : couverture, registre complet, obligations avec preuves et horodatages, journal IA, version du Rules Pack appliqué et identifiant unique d'audit.
Les documents générés sont des modèles génériques pré-remplis. Ils doivent être relus et adaptés à votre contexte avant tout usage officiel. Pour les langues ES, DE, IT et PT, une relecture par un professionnel du droit local est recommandée avant tout usage opposable. Ils ne constituent pas un avis juridique.
## 5. Journal
Chaque action significative (scan, mise à jour d'obligation, génération de document) est horodatée dans un journal exportable en CSV. Le journal peut être alimenté par les modules DataFirefly compatibles via l'API `JournalCollector::record()`. Pour les modules IA tiers, l'intégration côté tiers reste de leur ressort ; vous pouvez documenter manuellement.
En v1.0, la complétude du journal dépend de l'adoption de l'API par les modules tiers. Le module fournit l'interface, pas l'intégration côté tiers. Si vous n'utilisez pas de modules DataFirefly, le journal sera essentiellement alimenté par vos actions dans le module et votre documentation manuelle.
## 6. Licence & Paramètres
Cet onglet gère l'activation de la licence, le jeton du cron de mise à jour du Rules Pack et les options d'affichage front-office (toujours désactivées par défaut) :
- **Notice Art. 50** — notice de transparence en front (opt-in).
- **Badge disclosure chatbot** — badge par page produit, activable par système.
## Données et confidentialité
Seuls le **hash SHA-256 de votre clé de licence** et l'**IP de votre serveur** sont transmis à `license.datafirefly.com`, à des fins de validation de licence et de limitation de débit. Le registre IA, les obligations, les preuves, le journal, les documents et toutes les données boutique (clients, commandes, produits) restent exclusivement dans votre base de données PrestaShop. La clé n'est jamais stockée en clair.
## Multiboutique
Le module est nativement multiboutique : chaque boutique dispose de son registre, de ses obligations et de son journal indépendants. Le scan, les obligations et les toggles d'affichage front sont gérés par boutique. Le jeton du cron est partagé au niveau global.
## Mises à jour réglementaires (Rules Pack) et renouvellement
Le module embarque un Rules Pack baseline couvrant l'Art. 50 et l'Art. 4, vérifié contre les sources officielles (AI Act Explorer FLI + Commission européenne). Le cron du module contacte le serveur pour récupérer les versions mises à jour, ce qui requiert une licence active.
Le renouvellement à 69 €/an maintient la licence active et le Rules Pack à jour (lignes directrices de la Commission, transpositions nationales, codes de conduite GPAI). Sans renouvellement, le module continue de fonctionner avec le dernier pack reçu, mais ne bénéficie plus des évolutions réglementaires.
## Désinstallation
Avant de désinstaller, exportez votre registre et votre journal en CSV/PDF depuis l'onglet Documents. La désinstallation supprime toutes les tables et clés de configuration du module.
À la désinstallation, les tables du module sont supprimées, les clés de configuration purgées, les hooks désenregistrés et les onglets BO retirés. Aucune donnée orpheline ne reste en base. Vos données exportées restent entièrement sous votre contrôle — aucun lock-in.
## FAQ
### Le scanner ne détecte pas mon chatbot ou mon module IA
Vérifiez que le module est bien installé (et non simplement téléchargé). S'il est custom ou récent, il n'est peut-être pas encore dans la base de signatures. Ajoutez-le manuellement via **Registre > Ajouter manuellement** ; cette option ne nécessite aucun scan préalable.
### La clé de licence est refusée
Copiez-collez la clé depuis l'email de livraison (format `DFAIA-PRO-XXXX-XXXX-XXXX`) plutôt que de la retranscrire. Vérifiez qu'elle n'est pas expirée et que votre hébergeur n'empêche pas les connexions HTTPS sortantes vers `license.datafirefly.com`.
### Les PDF ne se génèrent pas
Assurez-vous que l'extension PHP **gd** (ou **imagick**) est activée, nécessaire au rendu PDF de dompdf.
### Le module est-il compatible PrestaShop 9 ?
Oui. AI Act Ready est compatible PrestaShop 8 et 9. Il est en revanche spécifique à PrestaShop et ne couvre ni Shopify ni WooCommerce.
### Ce module me rend-il conforme à l'EU AI Act ?
Non. Il vous outille pour documenter et structurer votre démarche. La conformité dépend de vos pratiques réelles et, selon les cas, d'un avis juridique externe.
## Support
Support assuré par DataFirefly Limited (Dublin, Irlande), en français et en anglais, sous 48 h ouvrées : **support@datafirefly.com** ou le formulaire sur **datafirefly.com/support**. Pour une demande urgente, mentionnez « URGENT » dans l'objet.
---
### AI Competitor — Veille tarifaire concurrents
_Source :_
> Présentation AI Competitor surveille les prix de vos concurrents directement depuis votre back-office PrestaShop. Pour chaque produit de votre catalogue, vous déclarez une ou plusieurs URLs concurrentes ; le module…
## Présentation
AI Competitor surveille les prix de vos concurrents directement depuis votre back-office PrestaShop. Pour chaque produit de votre catalogue, vous déclarez une ou plusieurs URLs concurrentes ; le module les visite à intervalles réguliers, extrait le prix affiché (avec un fallback IA quand les méthodes classiques échouent), détecte les variations significatives, vous alerte par email, et vous propose un prix ajusté selon votre stratégie tarifaire.
Compatible PrestaShop 8.0 à 9.x, PHP 7.4 à 8.3, multiboutique natif. Aucune dépendance Composer.
## Installation
1. Dans votre back-office, ouvrez **Modules → Gestionnaire de modules → Installer un module**.
2. Uploadez le fichier `dfaicompetitor.zip`.
3. Le module s'installe et crée automatiquement ses trois tables (`dfaicompetitor_url`, `dfaicompetitor_price`, `dfaicompetitor_alert`) ainsi que le menu **Catalogue → AI Competitor**.
Après installation, un token cron unique est généré. Vous le retrouverez sur le tableau de bord du module.
## Configuration initiale
Ouvrez **Catalogue → AI Competitor**. Le tableau de bord regroupe les statistiques et quatre blocs de configuration.
### Provider IA
Le fallback IA est facultatif mais fortement recommandé : c'est lui qui prend le relais quand un site concurrent n'expose ni données structurées ni sélecteur exploitable. Trois providers sont supportés :
- **Mistral AI** (défaut) — le plus économique, modèle conseillé : `mistral-small-latest`
- **Anthropic Claude** — la meilleure précision sur les pages complexes, modèle conseillé : `claude-haiku-4-5-20251001`
- **OpenAI** — bon compromis, modèle conseillé : `gpt-4o-mini`
Renseignez la clé API du provider choisi. Elle est masquée à l'affichage ; laissez le champ vide lors d'un enregistrement ultérieur pour conserver la clé en place. Vous payez le provider directement, sans surcoût DataFirefly.
### Alertes
- **Email de notification** — destinataire des digests d'alertes et du rapport hebdomadaire.
- **Seuil de variation** — en pourcentage (3 % par défaut). En dessous, aucune alerte n'est créée.
- **Jour du rapport hebdomadaire** — lundi par défaut.
### Scraping
- **URLs par lot cron** — nombre d'URLs traitées à chaque exécution (20 par défaut).
- **Intervalle par défaut** — en heures, appliqué aux nouvelles URLs (24 h par défaut).
- **Timeout HTTP** et **User-Agent** — le User-Agent livré est identifiable (`DataFireflyBot`) ; vous pouvez le personnaliser.
### Stratégie d'ajustement
Trois stratégies déterminent le prix suggéré, toujours calculé à partir du concurrent le moins cher :
- **Aligner** — même prix que le plus bas concurrent.
- **Undercut de X %** — X % en dessous (défaut : 1 %).
- **Premium à X %** — X % au-dessus, pour un positionnement haut de gamme assumé.
## Ajouter des URLs concurrentes
Ouvrez **Catalogue → AI Competitor → Competitor URLs → Ajouter**. Chaque ligne associe un produit de votre catalogue à une page concurrente :
- **Produit** — sélectionné dans votre catalogue.
- **Nom du concurrent** — libellé libre (Amazon, Cdiscount, un site marchand…).
- **URL** — l'adresse complète de la fiche produit concurrente.
- **Sélecteur CSS** (optionnel) — voir ci-dessous.
- **Devise ISO** — EUR par défaut.
- **Forcer l'extraction IA** — court-circuite les méthodes classiques pour cette URL.
- **Intervalle** — en heures, spécifique à cette URL.
Le bouton **Scrape** de chaque ligne déclenche une extraction immédiate — pratique pour valider une URL dès sa création.
### Comment fonctionne l'extraction
Pour chaque URL, le module essaie quatre méthodes en cascade et s'arrête à la première qui aboutit :
1. **JSON-LD** — les données structurées Product/Offer, présentes sur la grande majorité des sites e-commerce. Le prix, la devise et la disponibilité sont lus directement, sans configuration.
2. **OpenGraph** — les balises meta product price amount.
3. **Sélecteur CSS** — si vous en avez fourni un. Le convertisseur intégré gère les classes, identifiants, sélecteurs d'attribut et combinateurs enfant. Exemples valides : `.current-price`, `.price-box > .amount`, `span[itemprop=price]`.
4. **IA** — un extrait HTML nettoyé est envoyé à votre provider, qui renvoie le prix, la devise et l'état de stock. Les formats de prix internationaux sont gérés (1 299,90 — 1.234,56 — $49.99).
Commencez toujours sans sélecteur CSS : le JSON-LD suffit dans la plupart des cas. N'ajoutez un sélecteur ou l'IA forcée que si la colonne Status affiche `no_price`.
## Configurer le cron
Le scraping périodique repose sur un endpoint sécurisé par token, affiché sur le tableau de bord. Programmez son appel toutes les 30 minutes :
```
*/30 * * * * curl -s "https://votre-boutique.com/index.php?fc=module&module=dfaicompetitor&controller=cron&token=VOTRE_TOKEN" > /dev/null
```
À chaque exécution, le cron : traite le lot d'URLs dont l'intervalle est écoulé, envoie les emails d'alertes en attente, expédie le rapport hebdomadaire si c'est le bon jour, et purge les données anciennes (snapshots > 180 jours, alertes > 365 jours). La réponse est un JSON récapitulatif.
Le token peut être régénéré à tout moment depuis le tableau de bord (les crons existants devront être mis à jour). Un déclenchement manuel est aussi disponible via le bouton **Run cron now**.
## Alertes
Cinq types d'alertes sont générés, chacun avec une sévérité :
- **price_drop / price_rise** — variation au-delà du seuil. Une variation ≥ 10 % passe en critical.
- **undercut** — un concurrent passe sous votre prix de vente TTC. Toujours critical.
- **out_of_stock / back_in_stock** — transitions de disponibilité détectées via les données structurées ou l'IA.
- **scrape_error** — uniquement après 3 échecs consécutifs, pour éliminer le bruit des indisponibilités passagères.
Les alertes sont regroupées en un seul email digest par exécution cron, et consultables dans **Reports & Alerts** avec accusé de lecture (« Acknowledge all »).
## Rapport hebdomadaire
Chaque semaine, le jour configuré, un email HTML récapitule : les produits les plus sous-côtés, les plus fortes baisses et hausses concurrentes, la santé du scraping, et une **synthèse exécutive rédigée par l'IA** qui hiérarchise les actions à mener. Un aperçu du rapport en cours est visible à tout moment dans **Reports & Alerts**, avec un bouton d'envoi immédiat.
## Suggestion de prix
Dans **Reports & Alerts**, sélectionnez un produit surveillé : le module affiche votre prix actuel, le min/moyenne/max concurrent, les sources, et le prix suggéré selon votre stratégie. Le bouton **Appliquer** écrit le prix sur le produit PrestaShop.
L'application n'est jamais automatique — c'est un choix délibéré pour éviter les boucles de baisse en miroir entre concurrents équipés du même type d'outil. La conversion TTC → HT est gérée automatiquement selon le taux de taxe du produit.
## Dépannage
### Status « no_price »
Aucune des méthodes n'a trouvé de prix. Vérifiez l'URL dans un navigateur, ajoutez un sélecteur CSS pointant l'élément prix, ou activez « Forcer l'extraction IA » pour cette URL.
### Status « error »
La page n'a pas répondu (HTTP ≥ 400 ou timeout). Certains sites bloquent les robots : personnalisez le User-Agent dans la configuration, augmentez le timeout, ou espacez l'intervalle. Une alerte n'est émise qu'au 3ᵉ échec consécutif.
### L'extraction IA ne fonctionne pas
Vérifiez que la clé API est valide et que le modèle existe chez votre provider. Les erreurs d'appel IA sont journalisées dans **Paramètres avancés → Logs** avec le préfixe `[dfaicompetitor]`.
### Les emails n'arrivent pas
Testez la configuration email de PrestaShop (**Paramètres avancés → E-mail**). Le module utilise le système de mails natif avec ses propres templates FR/EN.
## Bonnes pratiques et conformité
- Espacez les intervalles (6 à 24 h par URL suffisent pour de la veille tarifaire) afin de ne pas solliciter inutilement les serveurs concurrents.
- Conservez un User-Agent identifiable : c'est la pratique loyale attendue en veille concurrentielle.
- La lecture de prix publics est généralement licite en Europe, mais vous restez responsable de l'usage des données collectées.
---
### AI Crawler Manager — Documentation
_Source :_
> Présentation AI Crawler Manager (slug technique : dfaicrawlermanager) donne à votre boutique PrestaShop 8 ou 9 le contrôle fin du trafic généré par les bots IA : GPTBot d'OpenAI, ClaudeBot…
## Présentation
**AI Crawler Manager** (slug technique : `dfaicrawlermanager`) donne à votre boutique PrestaShop 8 ou 9 le contrôle fin du trafic généré par les bots IA : GPTBot d'OpenAI, ClaudeBot d'Anthropic, Google-Extended, Applebot-Extended, PerplexityBot, Bytespider de ByteDance, et 25+ autres crawlers à jour de mai 2026.
Trois mécanismes de protection complémentaires :
- **Robots.txt visual builder** — autorise/bloque chaque bot via un interrupteur, applique un préréglage en un clic, écrit le fichier sans casser vos directives manuelles.
- **Blocage HTTP 403** — pour les bots qui ignorent robots.txt (Bytespider, anthropic-ai legacy), retourne un code 403 dès la première requête, avant tout traitement PrestaShop.
- **Statistiques de crawl** — suivi temps réel via hook + import des logs Apache/Nginx pour mesurer rétroactivement le trafic IA.
**Note** — Le module ne touche jamais à votre robots.txt en dehors de sa propre section, délimitée par les marqueurs sentinelles `# BEGIN DataFirefly AI Crawler Manager` et `# END DataFirefly AI Crawler Manager`. Tout le reste du fichier est préservé tel quel et un fichier `.bak` est créé à chaque écriture.
## Pré-requis
- PrestaShop 8.0 → 9.x
- PHP 7.4 minimum (PHP 8.0 à 8.3 recommandé)
- MySQL 5.7 / MariaDB 10.3 ou supérieur
- Droits d'écriture sur `/robots.txt` (racine de la boutique)
- Pour l'import des logs : accès en lecture au log d'accès Apache/Nginx (généralement `/var/log/apache2/access.log`, ou `~/logs/` chez o2switch, `~/access-logs/` chez cPanel)
## Installation
1. Téléchargez le ZIP `dfaicrawlermanager-v1.0.0.zip` depuis votre compte DataFirefly.
2. Dans le back-office PrestaShop, allez dans **Modules › Module Manager › Téléverser un module**.
3. Glissez-déposez le ZIP, attendez la confirmation puis cliquez sur **Installer**.
4. Une fois installé, un nouvel onglet **AI Crawler Manager** apparaît dans le menu de gauche (sous _Configurer_).
L'installation crée 5 tables (préfixe `ps_dfaicm_`), seed automatiquement la liste des 30+ bots IA et insère 6 onglets d'administration.
**Astuce** — Aucun `composer install` n'est requis. L'autoloader PSR-4 est embarqué dans le module sous le namespace `DataFireflyAiCrawlerManager`.
## Premier démarrage — le tableau de bord
L'onglet **AI Crawler Manager** ouvre le tableau de bord. Sur une installation fraîche, vous voyez :
- **Bots IA suivis** : 30+ (compte des bots actifs dans la base)
- **Bots bloqués** : 0 (par défaut, tous les bots sont autorisés)
- **Visites (30j)** : 0 (le suivi temps réel ne démarre qu'après activation)
- **Règles par chemin** : 0
Trois actions recommandées à ce stade :
1. Ouvrir le **robots.txt visual builder** et appliquer un préréglage (voir section dédiée).
2. Activer le **suivi temps réel** dans Réglages pour commencer à collecter des statistiques.
3. Optionnel : importer vos logs d'accès historiques pour voir le crawl IA des semaines précédentes.
## Onglet Bots IA
La liste complète des 30+ bots suivis avec :
- **Display name** : nom marketing (ex. "ClaudeBot")
- **User-agent** : chaîne exacte recherchée dans l'en-tête HTTP
- **Éditeur** : entreprise (OpenAI, Anthropic, Google, ByteDance, Meta…)
- **Usage** : _training_ (entraînement LLM), _assistant_ (réponses temps réel), _search_ (moteur de recherche IA), _crawl_ (générique)
- **Respecte robots.txt** : oui / non (indique si le robots.txt est suffisant)
- **Statut** : autorisé / bloqué
Actions disponibles :
- **Modifier** un bot pour ajuster son statut ou ajouter des notes internes.
- **Bloquer / Débloquer en masse** via les actions groupées en bas de liste.
- Toute modification déclenche une régénération automatique de robots.txt si l'option correspondante est activée dans les Réglages.
## Robots.txt visual builder
L'onglet le plus utilisé : éditeur visuel du fichier robots.txt.
### Préréglages en un clic
Cinq stratégies prêtes à l'emploi :
- **Bloquer uniquement l'entraînement** — stoppe les bots _training_ (GPTBot, ClaudeBot, anthropic-ai, CCBot, Bytespider…) et garde les bots _assistant_ et _search_ autorisés (ChatGPT-User, Claude-User, OAI-SearchBot…). Recommandé pour la plupart des boutiques.
- **Strict** — bloque _training_ + _crawl_ générique, autorise _assistant_ + _search_.
- **Tout bloquer** — disallow sur l'ensemble des 30+ bots IA.
- **Tout autoriser** — réinitialise tous les bots en autorisé.
- **Bloquer Bytespider uniquement** — utile si vous voulez juste cibler le crawler le plus agressif sans toucher au reste.
**Important** — Un préréglage écrase le statut de tous les bots concernés. Une confirmation est demandée avant application. Vous pouvez ensuite affiner bot par bot.
### Toggle par bot
Chaque bot dispose d'un interrupteur :
- **Vert** = autorisé (aucune directive `Disallow` dans robots.txt)
- **Rouge** = bloqué (directive `User-agent: X / Disallow: /` écrite dans la section gérée)
Un badge _"ignore robots.txt"_ jaune indique les bots pour lesquels le robots.txt seul est insuffisant. Pour ceux-là, activez aussi le **blocage HTTP 403** dans les Réglages (voir section dédiée).
### Aperçu live
Le panneau de droite affiche en temps réel le contenu qui sera écrit dans robots.txt. Aspect type :
```
# BEGIN DataFirefly AI Crawler Manager
# Generated 2026-05-26 14:32 — do not edit manually
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Allow: /
User-agent: Bytespider
Disallow: /
# … autres bots …
Sitemap: https://example.com/sitemap.xml
# END DataFirefly AI Crawler Manager
```
Cliquez sur **Enregistrer dans robots.txt** pour écrire le fichier. Un fichier `robots.txt.bak` est créé à côté à chaque enregistrement.
## Règles par chemin
Pour un blocage à granularité fine : autoriser un bot sur une partie du site, le bloquer sur une autre.
Exemple typique : autoriser ClaudeBot sur les fiches produits (pour que Claude les recommande) mais le bloquer sur le blog (pour ne pas céder votre contenu éditorial).
Une règle se compose de :
- **Bot** — bot ciblé (ou "tous les bots" via wildcard)
- **Action** — `allow` ou `disallow`
- **Chemin** — pattern URL avec wildcard `*` et fin de chaîne `$`
- **Position** — ordre d'évaluation (les règles les plus spécifiques en premier)
Exemples de patterns :
- `/blog/*` — toute URL commençant par `/blog/`
- `/*.pdf$` — tous les fichiers PDF
- `/order*` — URLs de commande
- `/module/dfsavecart/*` — un module spécifique
**Note** — Les règles par chemin sont ajoutées dans robots.txt sous forme de directives `Allow:` / `Disallow:` classiques, mais elles servent aussi au blocage HTTP 403 si vous l'activez.
## Blocage HTTP 403
Certains bots ignorent volontairement robots.txt. Le plus connu est **Bytespider** (ByteDance), mais aussi quelques anciennes versions d'_anthropic-ai_. Pour ces bots, robots.txt ne suffit pas.
Activez l'option **"Activer le blocage HTTP 403 pour les bots bloqués"** dans Réglages. Le module installe alors un hook `actionDispatcherBefore` qui :
1. Détecte l'user-agent à chaque requête entrante (comparaison de chaînes en mémoire, ~0.1 ms).
2. Si le bot est dans la liste des bloqués et que la requête correspond à une règle de blocage : renvoie immédiatement un HTTP 403 avant toute initialisation PrestaShop.
3. Logge la tentative dans la table `ps_dfaicm_visit` avec le flag `blocked = 1`.
**Astuce** — Le blocage HTTP économise CPU et base de données pour les bots les plus volumineux. Bytespider peut représenter plusieurs milliers de hits par jour sur une boutique moyenne.
## Statistiques et import des logs
L'onglet **Statistiques** propose une vue à 7, 30 ou 90 jours avec :
- KPI globaux (visites totales, bots distincts, hits bloqués)
- Graphique de trafic quotidien
- Top bots par volume
- Top URLs visitées
- Journal des 50 visites les plus récentes (date, bot, URL, IP, statut)
### Suivi temps réel
Si activé dans Réglages, chaque requête est inspectée et les hits de bots IA identifiés sont enregistrés. Le surcoût est négligeable : moins de 1 % du trafic atteint la phase d'écriture.
### Import des logs Apache/Nginx
Permet de comptabiliser rétroactivement les visites IA, y compris celles d'avant l'installation du module.
1. Dans **Réglages**, renseignez le chemin du fichier de log. Le module propose une auto-détection (chemins courants Apache, Nginx, o2switch, cPanel).
2. Choisissez le format (_combined_ par défaut, ou _common_).
3. Dans l'onglet **Statistiques**, cliquez sur **Analyser le log maintenant**.
Le parsing est **incrémental** : un offset en octets est stocké en base. Relancer l'opération ne crée pas de doublons. Le module limite chaque exécution à 8 Mo pour éviter les timeouts ; pour les fichiers très volumineux, plusieurs passes successives suffisent.
Pour repartir de zéro (par exemple après une rotation de log), cochez **Réinitialiser l'offset** dans Réglages et relancez l'analyse.
## Réglages
Récapitulatif des options disponibles :
### robots.txt
- **Auto-régénération** : régénère robots.txt automatiquement quand un bot ou une règle change
- **Crawl-delay** : délai recommandé entre requêtes (0 = désactivé, 1-120 secondes)
- **URL du sitemap** : ajoutée en fin de section gérée
- **Section globale Disallow** : ajoute aussi une section `User-agent: *` bloquant les zones sensibles (admin, panier, login)
### Blocage HTTP
- **Activer le blocage HTTP 403** : retourne immédiatement un 403 pour les bots bloqués (voir section dédiée)
### Suivi temps réel
- **Activer le suivi** : enregistre chaque visite IA détectée
- **Rétention** : nombre de jours de conservation des visites individuelles (7 à 730, défaut 90). Les agrégats quotidiens sont conservés plus longtemps.
### Import des logs
- **Activer l'analyse des logs** : active le bouton d'import dans l'onglet Statistiques
- **Chemin du fichier** : chemin absolu, avec auto-détection proposée
- **Format** : combined (Apache/Nginx par défaut) ou common
- **Réinitialiser l'offset** : à cocher pour relire le fichier entier
## Stratégies de blocage recommandées
Le choix dépend de votre positionnement éditorial et commercial. Trois profils typiques :
### Boutique e-commerce classique (recommandation par défaut)
Appliquer le préréglage **"Bloquer uniquement l'entraînement"**. Les bots d'entraînement (GPTBot, ClaudeBot, anthropic-ai, CCBot, Bytespider) sont bloqués. Les bots d'assistance temps réel (ChatGPT-User, Claude-User) et de recherche IA (OAI-SearchBot, PerplexityBot, Google-Extended) restent autorisés : vos produits peuvent toujours être recommandés dans ChatGPT, Claude, Perplexity et Google AI Overviews.
### Marque premium / contenu éditorial fort
Préréglage **"Strict"** + règles par chemin pour autoriser certaines zones. Exemple : bloquer tous les bots IA partout, sauf `/produit/*` autorisé pour ChatGPT-User et Claude-User. Vos descriptions produits restent référencées dans les assistants, votre blog et vos guides sont protégés.
### Boutique en plein lancement / faible volume éditorial
Préréglage **"Tout autoriser"**. La visibilité dans les moteurs de réponse IA dépasse largement le risque de cession de contenu. Vous repasserez à un blocage plus strict quand votre catalogue et votre blog auront pris de la valeur.
## Maintenance
### Purge automatique
Les visites individuelles plus anciennes que la rétention configurée sont supprimées automatiquement lors de chaque parsing de logs. Vous pouvez aussi déclencher une purge manuelle depuis l'onglet Statistiques (bouton **"Purger les anciennes visites"**).
### Sauvegarde du robots.txt
Chaque écriture crée un `robots.txt.bak` à côté du fichier original. En cas d'erreur, vous pouvez le restaurer manuellement par FTP ou via votre cPanel.
### Mise à jour de la liste de bots
Les nouveaux bots IA sont ajoutés via les mises à jour du module. La table `ps_dfaicm_bot` est mise à jour en mode "merge" : un bot que vous avez personnalisé manuellement n'est jamais écrasé.
## Dépannage
### robots.txt n'est pas inscriptible
Le tableau de bord affiche un badge rouge "Not writable". Vérifiez :
- Permissions du fichier `/robots.txt` : doit être en 644 minimum, et le propriétaire doit être l'utilisateur PHP/Apache
- Si le fichier n'existe pas, vérifiez les permissions du dossier racine (755 + propriétaire correct)
- Sur certains hébergements mutualisés, le robots.txt est généré dynamiquement par PrestaShop : désactivez l'option correspondante dans Préférences › Trafic › SEO et URLs
### L'auto-détection du log d'accès ne trouve rien
Le module cherche les chemins suivants : `/var/log/apache2/access.log`, `/var/log/nginx/access.log`, `~/logs/`, `~/access-logs/`. Sur d'autres hébergements, renseignez manuellement le chemin. Si vous ne le connaissez pas, contactez votre support hébergeur ou cherchez dans la documentation de votre panneau de contrôle.
### Le parsing de logs prend trop de temps
Le module limite chaque exécution à 8 Mo pour éviter les timeouts PHP. Pour un fichier de 500 Mo, prévoyez 60 à 70 passes. Chaque clic sur **"Analyser le log maintenant"** reprend là où la précédente s'est arrêtée grâce à l'offset stocké.
### Un bot bloqué apparaît quand même dans les statistiques
Normal : le suivi temps réel enregistre TOUTES les visites IA détectées, y compris celles bloquées (avec le flag `was_blocked = 1`). Cela vous permet de mesurer combien de tentatives sont effectivement bloquées par votre configuration.
### Un bot ignore robots.txt malgré ma règle
Confirmez avec un import de logs : si vous voyez encore des hits avec statut 200, le bot ignore effectivement robots.txt. Activez le blocage HTTP 403 dans Réglages. À partir de ce moment, les hits du bot apparaîtront avec statut 403 et flag `was_blocked = 1`.
## Désinstallation
Depuis **Modules › Module Manager**, cliquez sur **Désinstaller** sur la fiche du module. L'opération :
- Supprime les 5 tables `ps_dfaicm_*`
- Supprime les 6 onglets d'administration
- Retire la section gérée du robots.txt (les marqueurs sentinelles et tout ce qu'ils délimitent)
- Préserve le reste du robots.txt et le fichier `robots.txt.bak`
## Référence technique
- **Slug technique** : `dfaicrawlermanager`
- **Namespace** : `DataFireflyAiCrawlerManager`
- **Tables créées** : `ps_dfaicm_bot`, `ps_dfaicm_rule`, `ps_dfaicm_category_rule`, `ps_dfaicm_visit`, `ps_dfaicm_visit_daily`
- **Hooks utilisés** : `actionDispatcherBefore`, `actionAdminControllerSetMedia`, `displayBackOfficeHeader`
- **Onglets back-office** : Dashboard, Bots, Path rules, Builder, Statistics, Settings (sous AdminParentConfigure)
- **Clés de configuration** : `DFAICM_AUTO_REGEN`, `DFAICM_VISIT_LOG`, `DFAICM_HTTP_BLOCK`, `DFAICM_LOG_PARSING`, `DFAICM_LOG_PATH`, `DFAICM_LOG_FORMAT`, `DFAICM_LAST_PARSE`, `DFAICM_LAST_OFFSET`, `DFAICM_RETENTION`, `DFAICM_CRAWL_DELAY`, `DFAICM_SITEMAP_URL`, `DFAICM_GLOBAL_DISALLOW`, `DFAICM_INSTALLED_AT`
## Support
Pour toute question technique, contactez l'équipe DataFirefly à **contact@datafirefly.com** ou consultez votre espace client sur [datafirefly.com](https://www.datafirefly.com/).
---
### AI People Also Ask — Documentation complète (dfaipaa)
_Source :_
> Présentation AI People Also Ask (slug technique : dfaipaa) capture les questions que vos clients posent réellement à Google — les blocs « People Also Ask » — génère les…
## Présentation
**AI People Also Ask** (slug technique : `dfaipaa`) capture les questions que vos clients posent réellement à Google — les blocs « People Also Ask » — génère les réponses avec une IA de votre choix, et publie une FAQ balisée schema.org sur vos fiches produit et pages catégorie.
Le module industrialise un pipeline complet en quatre étapes :
- **Scraping** — capture des questions PAA sur vos mots-clés cibles via SerpApi, DataForSEO ou saisie manuelle.
- **Génération IA** — rédaction des réponses via Mistral, OpenAI ou Anthropic, avec ton et voix de marque configurables.
- **Workflow éditorial** — révision, affectation aux produits et catégories, publication (manuelle ou automatique).
- **Publication** — accordéon FAQ accessible côté boutique + JSON-LD FAQPage pour Google et les moteurs génératifs.
**Note** — Aucun `composer install` n'est requis. Un autoloader PSR-4 minimal est embarqué dans le module sous le namespace DataFirefly Dfaipaa.
## Pré-requis
- PrestaShop 8.0.0 → 9.99.99
- PHP 8.1, 8.2 ou 8.3
- MySQL 5.7 / MariaDB 10.4 ou supérieur
- Une clé API pour au moins un fournisseur IA (Mistral, OpenAI ou Anthropic)
- Optionnel : une clé SerpApi ou un compte DataForSEO pour automatiser le scraping
- Autorisation des connexions HTTPS sortantes (cURL) depuis votre hébergement
**Astuce** — Le mode « saisie manuelle » permet d'utiliser le module sans aucun abonnement de scraping : vous entrez vous-même les questions, l'IA se charge des réponses.
## Installation
1. Téléchargez le ZIP `dfaipaa.zip` depuis votre compte DataFirefly.
2. Dans le back-office PrestaShop, allez dans **Modules › Gestionnaire de modules › Téléverser un module**.
3. Glissez-déposez le ZIP, attendez la confirmation puis cliquez sur **Installer**.
4. Un nouveau menu **AI People Also Ask** apparaît dans la colonne de gauche, avec trois onglets : Configuration, Mots-clés, Questions.
L'installation crée 4 tables (préfixe `ps_dfaipaa_`), pose les valeurs de configuration par défaut et installe 4 onglets d'administration (un parent + trois enfants) avec des libellés localisés en FR, EN, ES, DE, IT et NL.
**Important** — Si votre outil de décompression ignore les dossiers `vendor/`, l'autoloader ne sera pas présent et le module lèvera une erreur « Class not found ». Décompressez avec `unzip` ou téléversez le ZIP directement via le back-office, qui gère correctement l'arborescence.
## Configuration — Scraping
Onglet **AI People Also Ask › Configuration**, première section.
ChampDescriptionDéfautFournisseur`serpapi`, `dataforseo` ou `manual``serpapi`Clé APIClé SerpApi, ou identifiants DataForSEO au format `login:password`videLangueCode ISO 2 lettres utilisé dans la requête Google`fr`PaysCode ISO 2 lettres du marché ciblé`FR`Max questions par mot-cléLimite par opération de scraping`8`Intervalle de rafraîchissementEn jours, au-delà duquel un mot-clé est considéré comme périmé`30`
### Obtenir une clé SerpApi
Créez un compte sur **serpapi.com**. Le plan gratuit offre 100 requêtes par mois, ce qui correspond à environ 100 mots-clés scrapés. La clé se trouve dans votre tableau de bord, section « Your Account ». Le module interroge l'endpoint de recherche Google et exploite le bloc `related_questions` de la réponse.
### Obtenir un compte DataForSEO
Créez un compte sur **dataforseo.com**. Vous obtenez un couple identifiant / mot de passe à coller dans le champ Clé API sous la forme `login:password` (le module gère l'authentification HTTP Basic). DataForSEO facture à l'usage, ce qui convient mieux aux gros volumes. Le module utilise l'endpoint SERP Google organic live advanced et extrait les éléments `people_also_ask`.
Le mapping des codes de localisation est intégré pour les marchés suivants : FR, BE, CH, LU, CA, US, UK, IE, ES, PT, IT, DE, AT, NL, PL, BR et MX.
### Mode saisie manuelle
Sélectionnez `manual` pour désactiver tout appel externe. Vous ajoutez alors les questions vous-même depuis l'onglet Questions ; la génération IA reste pleinement fonctionnelle.
## Configuration — Intelligence artificielle
Deuxième section de l'onglet Configuration.
ChampDescriptionDéfautFournisseur`mistral`, `openai` ou `anthropic``mistral`ModèleIdentifiant du modèle chez le fournisseur`mistral-large-latest`Clé APIClé du fournisseur sélectionnévideTempérature0.0 à 1.0 — plus bas = plus factuel`0.3`Tokens maxLongueur maximale de la réponse générée`500`TonalitéTexte libre : expert, pédagogique, commercial, chaleureux…videVoix de marqueInstructions additionnelles pour aligner le style éditorialvideAuto-publicationPublie automatiquement chaque réponse généréedésactivé
### Modèles recommandés
- **Mistral** — `mistral-large-latest` pour la qualité, `mistral-small-latest` pour réduire les coûts sur de gros volumes.
- **OpenAI** — `gpt-4o-mini` offre un excellent rapport qualité / prix ; `gpt-4o` pour les catalogues techniques exigeants.
- **Anthropic** — `claude-sonnet-4-6` pour des réponses nuancées et bien structurées.
### Contrainte imposée au modèle
Le module construit un prompt système strict, indépendant du fournisseur : réponses de 60 à 120 mots, HTML simple uniquement (paragraphes, gras, italique, listes), interdiction du markdown, des balises de titre et de tout script. Le contexte de l'entité (nom et description du produit ou de la catégorie, tronqués à 1200 caractères) ainsi que le mot-clé d'origine sont injectés pour ancrer la réponse. Le snippet Google d'origine est fourni comme référence avec une consigne explicite de reformulation — jamais de copie.
**Astuce** — Si un modèle plus petit renvoie malgré tout du markdown, baissez la température à 0.2 et précisez « HTML uniquement, pas de markdown » dans le champ Voix de marque.
## Configuration — Affichage
Troisième section de l'onglet Configuration.
ChampDescriptionDéfautMode produit`tab` (onglet) ou `footer` (bloc en pied de fiche)`tab`Activer sur produitAffiche la FAQ sur les fiches produitactivéActiver sur catégorieAffiche la FAQ en pied de page catégorieactivéTitre ongletLibellé localisé de l'onglet produit« Questions fréquentes »Titre produitTitre du bloc en mode footerlocaliséTitre catégorieTitre du bloc catégorielocaliséÉmettre le JSON-LDInjecte le balisage FAQPageactivé
En mode `tab`, le module s'appuie sur le mécanisme natif `ProductExtraContent` de PrestaShop : la FAQ apparaît comme un onglet aux côtés de « Description » et « Détails du produit », sans surcharge de template.
## Workflow éditorial
### Étape 1 — Ajouter des mots-clés
Onglet **Mots-clés**. Collez votre liste dans la zone de texte, un mot-clé par ligne, puis validez. Les doublons sont ignorés automatiquement (l'ajout est idempotent par mot-clé, langue et boutique).
Choisissez des mots-clés qui correspondent à l'intention d'achat : « machine à café automatique », « meilleur café en grain », « entretien cafetière ». Évitez les requêtes de marque pure, qui déclenchent rarement des blocs PAA.
### Étape 2 — Scraper
Deux options :
- **Scraper** — bouton individuel sur chaque ligne de mot-clé, utile pour tester la configuration.
- **Scraper tous les périmés** — traite par lot de 20 les mots-clés dont la dernière capture dépasse l'intervalle de rafraîchissement.
Chaque question capturée est enregistrée avec un hash d'unicité (question + langue + boutique) : re-scraper un mot-clé ne crée jamais de doublon, il met simplement à jour la date de dernière capture.
### Étape 3 — Générer les réponses
Onglet **Questions**. Filtrez par statut `pending`, sélectionnez les questions via les cases à cocher, puis lancez l'action de masse **Générer**. Un bouton individuel est également disponible sur chaque ligne.
Le contexte d'entité est construit à partir de la première affectation de la question. Pour de meilleures réponses, affectez la question à un produit ou une catégorie _avant_ de générer : l'IA disposera alors du nom et de la description de l'entité.
### Étape 4 — Réviser et affecter
Cliquez sur une question pour ouvrir le formulaire d'édition. Vous pouvez :
- corriger la réponse HTML dans l'éditeur enrichi ;
- affecter la question à un ou plusieurs produits et catégories (relation N à N) ;
- réordonner les affectations pour contrôler l'ordre d'affichage de l'accordéon ;
- rejeter une question hors sujet (statut `rejected`, conservée en base mais jamais affichée).
### Étape 5 — Publier
Passez le statut à `published`. La FAQ apparaît immédiatement côté boutique, accompagnée de son JSON-LD.
Si l'option **Auto-publication** est activée dans la configuration, les étapes 4 et 5 sont fusionnées : la génération publie directement. Pratique pour un pipeline entièrement automatisé, à réserver aux catalogues où la relecture humaine n'est pas critique.
## Statuts des questions
StatutSignificationAffiché en boutique`pending`Question capturée, pas encore de réponse IANon`generated`Réponse générée, en attente de validationNon`published`Validée et publiéeOui`rejected`Écartée manuellementNon
## Affichage côté boutique
L'accordéon repose sur les éléments HTML natifs `details` et `summary`, ce qui garantit :
- une navigation au clavier fonctionnelle sans JavaScript ;
- un contenu indexable par les moteurs même replié ;
- une compatibilité avec tous les navigateurs modernes.
Le premier élément est ouvert par défaut. Un fichier CSS léger est chargé, entièrement surchargeable depuis votre thème enfant. Toutes les classes utilisent le préfixe `dfaipaa-faq` pour éviter les collisions.
### Événements JavaScript
Le script front émet deux événements personnalisés que vous pouvez brancher sur votre outil d'analytics :
```
document.addEventListener('dfaipaa:open', function (e) {
// e.detail.question, e.detail.index, e.detail.type, e.detail.entityId
gtag('event', 'faq_open', { question: e.detail.question });
});
document.addEventListener('dfaipaa:close', function (e) {
console.log('FAQ fermée :', e.detail.question);
});
```
Le fichier `views/js/front.js` contient également une constante `SINGLE_OPEN` (à `false` par défaut) : passez-la à `true` pour n'autoriser qu'un seul panneau ouvert à la fois.
### Deep-linking
Une ancre de la forme `#dfaipaa-q-123` ouvre automatiquement la question correspondante et fait défiler la page jusqu'à elle. Pratique pour partager une réponse précise depuis un email ou un ticket SAV.
## Balisage JSON-LD FAQPage
À chaque chargement de page produit ou catégorie comportant au moins une question publiée, le module injecte un bloc JSON-LD juste avant la fermeture du corps du document (hook `displayBeforeBodyClosingTag`).
Structure émise : un nœud `FAQPage`, un tableau `mainEntity`, et pour chaque entrée un nœud `Question` contenant un `acceptedAnswer` de type `Answer`. Le contenu HTML des réponses est nettoyé avant émission : les balises de script et de style ainsi que les attributs événementiels sont supprimés.
**Astuce** — Validez votre balisage avec l'outil de test des résultats enrichis de Google. Notez que Google a restreint l'affichage des rich snippets FAQ aux sites gouvernementaux et de santé, mais le balisage reste précieux pour les moteurs génératifs (ChatGPT, Perplexity, Gemini) qui l'exploitent activement.
## Automatisation par cron
Un script CLI est fourni pour exécuter le pipeline sans intervention manuelle.
```
# Scraper les mots-clés périmés (20 max par défaut)
php modules/dfaipaa/cli/cron.php scrape --limit=20
# Générer les réponses IA pour les questions en attente
php modules/dfaipaa/cli/cron.php generate --limit=10
# Enchaîner scraping puis génération
php modules/dfaipaa/cli/cron.php all --limit=20
```
Exemple de crontab, exécution nocturne à 3 h :
```
0 3 * * * cd /var/www/prestashop && php modules/dfaipaa/cli/cron.php all --limit=30 >> /var/log/dfaipaa.log 2>&1
```
**Important** — Dimensionnez le paramètre `--limit` en fonction de vos quotas API. Un lot de 30 mots-clés consomme 30 requêtes SerpApi ; avec le plan gratuit (100 par mois), une exécution hebdomadaire est plus adaptée qu'une exécution quotidienne.
## Multilingue et multiboutique
Les questions sont indexées par `id_lang` et `id_shop`. Concrètement :
- un même mot-clé scrapé en français et en anglais produit deux jeux de questions distincts ;
- les réponses sont générées dans la langue de la question, le prompt appliquant une directive linguistique explicite (fr, en, es, de, it, nl, pt, pl) ;
- en multiboutique, les questions et affectations d'une boutique n'apparaissent jamais sur une autre ;
- les titres d'affichage (onglet, produit, catégorie) sont stockés en configuration localisée.
## Dépannage
### Le scraping ne renvoie aucune question
- Vérifiez votre quota chez le fournisseur : SerpApi coupe silencieusement au-delà du plan gratuit.
- Contrôlez la cohérence langue / pays : « fr » avec « US » donne des résultats erratiques.
- Certains mots-clés ne déclenchent tout simplement pas de bloc PAA chez Google. Testez la requête manuellement dans un navigateur en navigation privée.
- Pour DataForSEO, vérifiez le format `login:password` du champ Clé API.
### L'IA renvoie du markdown au lieu du HTML
Baissez la température à 0.2, ou passez à un modèle plus capable. Le prompt impose déjà des règles HTML strictes, mais les modèles les plus légers peuvent les ignorer partiellement.
### La FAQ ne s'affiche pas en boutique
- Vérifiez qu'au moins une question est au statut `published`.
- Vérifiez qu'elle est bien affectée à l'entité consultée (produit ou catégorie).
- Contrôlez que l'affichage est activé pour ce type d'entité dans la configuration.
- Videz le cache Smarty depuis **Paramètres avancés › Performances**.
### Le JSON-LD n'apparaît pas dans le code source
Assurez-vous que l'option « Émettre le JSON-LD » est activée et que le thème appelle bien le hook `displayBeforeBodyClosingTag`. Certains thèmes tiers l'omettent : ajoutez alors `{hook h='displayBeforeBodyClosingTag'}` avant la fermeture du corps dans votre `layouts/layout-both-columns.tpl`.
### Erreur « Class not found » après installation
Le dossier `vendor/` n'a pas été extrait. Réinstallez le module en téléversant le ZIP via le back-office plutôt qu'en décompressant manuellement.
### Consulter les logs d'opération
Toutes les opérations (scraping, génération, publication) sont journalisées. Pour investiguer :
```
SELECT * FROM ps_dfaipaa_log ORDER BY date_add DESC LIMIT 50;
```
## Désinstallation
Depuis **Modules › Gestionnaire de modules**, cliquez sur **Désinstaller**. L'opération supprime les 4 tables `ps_dfaipaa_*`, les 4 onglets d'administration et toutes les clés de configuration `DFAIPAA_`. Le contenu généré est définitivement perdu : exportez vos questions au préalable si vous souhaitez les conserver.
## Référence technique
- **Slug technique** : `dfaipaa`
- **Namespace** : DataFirefly Dfaipaa (PSR-4, autoloader embarqué)
- **Tables créées** : `ps_dfaipaa_keyword`, `ps_dfaipaa_question`, `ps_dfaipaa_assignment`, `ps_dfaipaa_log`
- **Hooks utilisés** : `displayHeader`, `displayProductExtraContent`, `displayFooterProduct`, `displayCategoryFooter`, `displayBeforeBodyClosingTag`, `actionFrontControllerSetMedia`, `actionAdminControllerSetMedia`, `actionProductUpdate`, `actionProductSave`, `actionCategoryUpdate`, `actionObjectProductDeleteAfter`, `actionObjectCategoryDeleteAfter`
- **Onglets back-office** : AdminDfaipaa (parent), AdminDfaipaaConfig, AdminDfaipaaKeywords, AdminDfaipaaQuestions
- **Clés de configuration** : `DFAIPAA_SCRAPER_PROVIDER`, `DFAIPAA_SCRAPER_API_KEY`, `DFAIPAA_SCRAPER_LANG`, `DFAIPAA_SCRAPER_COUNTRY`, `DFAIPAA_SCRAPER_MAX_PER_KEYWORD`, `DFAIPAA_AI_PROVIDER`, `DFAIPAA_AI_MODEL`, `DFAIPAA_AI_API_KEY`, `DFAIPAA_AI_TEMPERATURE`, `DFAIPAA_AI_MAX_TOKENS`, `DFAIPAA_AI_TONE`, `DFAIPAA_AI_BRAND_VOICE`, `DFAIPAA_AUTO_PUBLISH`, `DFAIPAA_REFRESH_INTERVAL`, `DFAIPAA_PRODUCT_MODE`, `DFAIPAA_EMIT_JSONLD`, `DFAIPAA_TAB_TITLE`, `DFAIPAA_PRODUCT_TITLE`, `DFAIPAA_CATEGORY_TITLE`
- **CLI** : `modules/dfaipaa/cli/cron.php` (commandes `scrape`, `generate`, `all`)
- **Template front** : `views/templates/hook/faq.tpl`
## Conformité RGPD
Le module ne collecte ni ne stocke aucune donnée personnelle : seuls des mots-clés, des questions, des réponses générées et des journaux d'opérations techniques sont enregistrés. Aucun cookie n'est déposé côté boutique. Les appels aux API externes (scraping, IA) ne transmettent que le mot-clé, la question et le contexte produit — jamais de données client.
## Support
Pour toute question technique, contactez l'équipe DataFirefly à **contact@datafirefly.com** ou consultez votre espace client sur [datafirefly.com](https://www.datafirefly.com/).
---
### AI Product Photography Studio — Guide complet
_Source :_
> Présentation AI Product Photography Studio transforme une photo produit sur fond blanc en mises en scène professionnelles générées par IA (Flux Kontext Pro via fal.ai ou Replicate). Le produit reste…
## Présentation
AI Product Photography Studio transforme une photo produit sur fond blanc en mises en scène professionnelles générées par IA (Flux Kontext Pro via fal.ai ou Replicate). Le produit reste rigoureusement identique d'une scène à l'autre : seul l'environnement change. Le plugin s'intègre directement dans la fiche produit WooCommerce via une meta box dédiée, et les générations s'exécutent en arrière-plan grâce à Action Scheduler.
## Prérequis
- WordPress 6.4 ou supérieur
- WooCommerce 8.0 ou supérieur (Action Scheduler inclus)
- PHP 8.1 ou supérieur
- Un site accessible en HTTPS — les providers IA doivent pouvoir télécharger vos images sources via une URL publique
- Un compte fal.ai **ou** Replicate avec une clé API active
**Important :** les sites en local (localhost, .test, .local) ne fonctionneront pas : le provider IA ne peut pas atteindre l'URL de votre image source. Utilisez un environnement de staging accessible publiquement ou un tunnel (ngrok, Cloudflare Tunnel).
## Installation
1. Téléchargez le fichier `df-ai-product-photography.zip` depuis votre compte DataFirefly.
2. Dans WordPress, allez dans **Extensions → Ajouter → Téléverser une extension**.
3. Sélectionnez le ZIP puis cliquez sur **Installer maintenant**, puis **Activer**.
4. Un nouveau sous-menu **WooCommerce → AI Photo Studio** apparaît : c'est la page de réglages du plugin.
À l'activation, le plugin vérifie que PHP 8.1+ et WooCommerce sont présents. Si l'une des conditions n'est pas remplie, l'activation est refusée avec un message explicite.
## Obtenir une clé API
### Option A — fal.ai (recommandé en production)
1. Créez un compte sur [fal.ai](https://fal.ai).
2. Ouvrez le dashboard puis la section **Keys**.
3. Générez une nouvelle clé et copiez-la (format `xxxxxxxx-xxxx-...:yyyyyyyy`).
4. Ajoutez du crédit à votre compte (facturation à l'usage, environ 0,04 € par image).
### Option B — Replicate
1. Créez un compte sur [replicate.com](https://replicate.com).
2. Allez dans **Account → API tokens**.
3. Générez un token (format `r8_...`) et copiez-le.
4. Renseignez un moyen de paiement (environ 0,06 € par image).
## Configuration
Rendez-vous dans **WooCommerce → AI Photo Studio**. La page de réglages comporte quatre onglets.
### Onglet Provider IA
- **Choix du fournisseur** : sélectionnez fal.ai ou Replicate via les cartes radio. Les deux utilisent le même modèle Flux Kontext Pro.
- **Clé API fal.ai** / **Token API Replicate** : collez la clé correspondante. Seule la clé du provider sélectionné est requise.
- **Bouton Tester** : vérifie que la clé est bien renseignée pour le provider choisi.
### Onglet Paramètres de génération
- **Ratio d'image** : `Identique à la source` (défaut), 1:1, 4:3, 3:4, 16:9, 9:16, 3:2 ou 2:3.
- **Format de sortie** : JPEG (défaut) ou PNG.
- **Tolérance modération** : de 1 (très strict) à 6 (très permissif). La valeur 2 est recommandée pour le e-commerce.
- **Guidance** : force d'adhérence au prompt, de 1 à 10 (fal.ai uniquement). 3.5 par défaut.
- **Galerie automatique** : si coché, chaque image générée est immédiatement ajoutée à la galerie du produit sans intervention manuelle.
### Onglet Scènes personnalisées
En plus des 12 scènes intégrées, vous pouvez déclarer vos propres mises en scène au format JSON :
```
[
{
"key": "loft_industriel",
"label": "Loft industriel",
"category": "lifestyle",
"icon": "🏭",
"description": "Décor brut métal et béton",
"prompt": "Place this product in a modern industrial loft setting with exposed brick walls, concrete floor, large factory windows, dramatic natural light"
}
]
```
- `key` : identifiant unique en minuscules sans espaces (obligatoire)
- `label` : nom affiché dans le sélecteur
- `category` : `lifestyle`, `packshot`, `context` ou `seasonal`
- `prompt` : instruction en anglais commençant idéalement par « Place this product... » (obligatoire)
**Astuce :** rédigez vos prompts en anglais et décrivez l'environnement, la lumière et le style photographique. Le plugin ajoute automatiquement un garde-fou pour préserver le produit et éviter texte et watermarks.
### Onglet Avancé
- **Niveau de log** : Désactivé, Erreurs uniquement (défaut) ou Verbose. Les logs sont consultables dans **WooCommerce → État → Journaux**, source `df-ai-product-photography`.
- Un encart d'informations techniques affiche les versions PHP / WordPress / WooCommerce et la présence d'Action Scheduler.
## Générer des mises en scène
Ouvrez n'importe quel produit dans **Produits → Tous les produits**. La meta box **🎨 AI Product Photography Studio** apparaît sous l'éditeur. Le workflow se déroule en trois étapes :
### Étape 1 — Photo source
Choisissez l'image de départ : soit via **Choisir depuis la médiathèque**, soit via **Utiliser l'image principale** qui reprend l'image mise en avant du produit. Une photo nette sur fond blanc ou neutre donne les meilleurs résultats — un smartphone récent suffit.
### Étape 2 — Sélection des scènes
Cochez les mises en scène désirées parmi les cartes, organisées par catégorie (Lifestyle, Packshot, Contexte d'usage, Saisonnier). Les liens rapides **+ Tous Lifestyle**, **+ Tous Packshot**, **Tout sélectionner** et **Effacer** accélèrent la sélection. Un lot est limité à 20 scènes maximum.
### Étape 3 — Lancement
Ajoutez éventuellement des instructions additionnelles (ex. « éclairage chaud, couleurs automnales, style magazine ») qui seront appliquées à toutes les scènes du lot, puis cliquez sur **✨ Générer les mises en scène**.
La colonne de droite **🖼️ Générations** affiche l'état de chaque job en temps réel : _En file_ → _Envoi_ → _Génération_ → _Terminé_ ou _Échec_. Le statut se rafraîchit automatiquement toutes les 3,5 secondes. Comptez généralement 10 à 30 secondes par image.
## Utiliser les images générées
Chaque image terminée propose trois actions :
- **+ Galerie** : ajoute l'image à la galerie du produit WooCommerce (sans écraser les images existantes).
- **Voir** : ouvre l'image en pleine résolution dans un nouvel onglet.
- **×** : retire l'entrée de la liste (l'image reste dans la médiathèque).
Toutes les images générées sont importées dans la médiathèque WordPress avec des méta-données de traçabilité : `_df_aipp_generated`, `_df_aipp_scene` (nom de la scène) et `_df_aipp_origin_product` (produit d'origine). Vous pouvez donc les retrouver et les réutiliser librement.
## Fonctionnement technique
Les générations sont asynchrones : au clic sur Générer, le plugin crée un job par scène et le planifie via Action Scheduler (hook `df_aipp_submit_job`). Chaque job soumet la requête au provider, récupère un identifiant, puis un second hook (`df_aipp_poll_job`) interroge le statut toutes les 5 secondes, jusqu'à 60 tentatives (~5 minutes). En cas d'erreur réseau transitoire, le job est retenté jusqu'à 3 fois avant d'être marqué en échec.
Vous pouvez observer et relancer les actions dans **WooCommerce → État → Actions planifiées**, groupe `df-ai-product-photography`.
## Dépannage
### Le bouton Générer est grisé
Le provider sélectionné n'a pas de clé API renseignée. Allez dans **WooCommerce → AI Photo Studio → Provider IA** et collez votre clé.
### Les jobs restent bloqués en « En file »
Action Scheduler ne s'exécute pas. Vérifiez que WP-Cron fonctionne (visitez le site côté front, ou configurez un vrai cron serveur pointant sur `wp-cron.php`). Consultez **WooCommerce → État → Actions planifiées** pour voir les actions en attente.
### Erreur « Image source introuvable » ou échec immédiat
Le provider n'arrive pas à télécharger votre image. Causes fréquentes : site en local non accessible publiquement, protection par htpasswd, hotlink protection au niveau serveur ou CDN bloquant les requêtes externes. Testez l'URL de l'image dans une fenêtre de navigation privée.
### Erreur 401 / 403 renvoyée par le provider
Clé API invalide, expirée ou compte sans crédit. Régénérez la clé sur le dashboard du provider et vérifiez votre solde.
### La génération aboutit mais l'image est refusée (safety)
Le modèle a jugé le contenu sensible. Augmentez la **Tolérance modération** dans les réglages (essayez 3 ou 4), ou reformulez le prompt de votre scène personnalisée.
### Où trouver les logs détaillés ?
Passez le **Niveau de log** sur Verbose dans l'onglet Avancé, relancez une génération, puis consultez **WooCommerce → État → Journaux** et sélectionnez la source `df-ai-product-photography`.
## Désinstallation
La désactivation seule ne supprime rien. La suppression du plugin déclenche `uninstall.php` qui efface les réglages globaux, les méta de jobs sur les produits et les actions planifiées restantes. Les images générées déjà présentes dans la médiathèque sont conservées.
## FAQ
### Puis-je utiliser les deux providers en parallèle ?
Le provider actif est global (un seul à la fois), mais vous pouvez basculer à tout moment dans les réglages : les nouvelles générations utiliseront le provider nouvellement sélectionné.
### Les images générées sont-elles libres de droits ?
Selon les conditions de fal.ai et Replicate, les sorties générées avec votre compte vous appartiennent et sont utilisables commercialement. Vérifiez les CGU de votre provider pour votre cas d'usage.
### Le plugin fonctionne-t-il avec les produits variables ?
Oui. La meta box est disponible sur tous les types de produits WooCommerce. Les images sont attachées à la galerie du produit parent.
---
### AI Returns Predictor — Guide complet
_Source :_
> AI Returns Predictor analyse chaque commande dès sa validation et lui attribue un score de risque de retour de 0 à 100, classé en trois niveaux (Faible, Moyen, Élevé). Le…
AI Returns Predictor analyse chaque commande dès sa validation et lui attribue un score de risque de retour de 0 à 100, classé en trois niveaux (Faible, Moyen, Élevé). Le score s'affiche directement sur la fiche commande, avec le détail des facteurs, et votre logistique est alertée par email avant l'expédition lorsqu'une commande dépasse le seuil de risque élevé. Ce guide couvre l'installation, la configuration, le fonctionnement du moteur de scoring et la couche IA optionnelle.
## Installation
1. Téléchargez l'archive `dfreturnspredictor.zip` depuis votre compte DataFirefly.
2. Back-office PrestaShop → **Modules** → **Téléverser un module** → envoyez le ZIP.
3. À l'installation, le module crée sa table `df_return_risk`, enregistre ses hooks et ajoute l'onglet **Expédition → Returns Predictor**.
Compatible PrestaShop 8.0 à 9.x, en PHP 7.4 à 8.3. Aucun override de thème, aucune dépendance Composer. Compatible multiboutique et multilingue.
## Configuration générale
Rendez-vous dans **Modules → AI Returns Predictor → Configurer**.
### Seuils de risque
Deux seuils déterminent le niveau attribué à chaque commande à partir de son score :
- **Seuil Moyen** (par défaut 40) : score à partir duquel une commande passe en risque _Moyen_.
- **Seuil Élevé** (par défaut 70) : score à partir duquel une commande passe en risque _Élevé_ et déclenche l'alerte logistique.
En dessous du seuil Moyen, la commande est classée _Faible_. Les seuils doivent respecter la règle 1 ≤ Moyen < Élevé ≤ 100.
### Catégories à fort taux de retour
Renseignez la liste des identifiants de catégories réputées pour leurs retours fréquents (mode, textile, chaussures…), séparés par des virgules. Les produits appartenant à ces catégories augmentent le score de la commande.
### Alerte logistique
- **Email d'alerte logistique** : adresse notifiée lorsqu'une commande franchit le seuil de risque élevé. Laissez le champ vide pour désactiver les alertes email.
L'alerte n'est envoyée qu'une seule fois par commande, à la première détection d'un risque élevé. Les recalculs ultérieurs ne renvoient pas de nouvel email.
### Couche IA (optionnelle)
Le module fonctionne sans IA grâce à son moteur heuristique. Vous pouvez activer une couche IA optionnelle pour affiner le score et générer une explication courte.
- **Activer l'affinage IA** : si désactivé, aucun appel externe n'est effectué.
- **Clé API Mistral** : stockée côté serveur, jamais exposée au front-office.
- **Modèle Mistral** : par exemple `mistral-small-latest`.
En cas d'erreur réseau, d'API indisponible ou de dépassement du délai (8 s), le module repasse automatiquement sur le score heuristique. Le scoring ne bloque jamais la préparation des commandes.
## Comment le score est calculé
Le moteur heuristique combine six facteurs explicables, chacun apportant un nombre de points plafonné. Le total est borné entre 0 et 100.
- **Historique de retours du client** (0–30) : rapport entre le nombre de retours passés et le nombre de commandes valides du client.
- **Bracketing tailles / variantes** (0–25) : même produit commandé en plusieurs déclinaisons (tailles, couleurs), signe d'une intention d'essayage.
- **Valeur du panier** (0–15) : montant de la commande rapporté au panier moyen de la boutique.
- **Catégories à risque** (0–20) : présence de produits dans les catégories que vous avez déclarées.
- **Nouveau client** (0–8) : absence d'historique d'achat exploitable.
- **Taille du panier** (0–10) : nombre d'articles distincts dans la commande.
Chaque facteur affiche sa contribution en points sur la fiche commande, ce qui rend le score entièrement transparent — pas de boîte noire.
## Le panneau de risque sur la commande
Sur chaque fiche commande (hook `displayAdminOrderSide`), un panneau « Risque de retour » affiche :
- le score sur 100 et le niveau coloré (Faible / Moyen / Élevé) ;
- le détail des facteurs contributifs avec leurs points ;
- l'explication de l'IA, le cas échéant ;
- un bouton **Recalculer** qui relance le scoring en AJAX sans recharger la page.
Le score est calculé automatiquement à la validation de la commande (hook `actionValidateOrder`) et rafraîchi lors des changements de statut (hook `actionOrderStatusPostUpdate`).
## Le tableau de bord logistique
L'onglet **Expédition → Returns Predictor** liste toutes les commandes scorées, triées par score décroissant. Vous y retrouvez la référence, le client, le statut, le score, le niveau et l'indicateur d'alerte. Filtrez par niveau pour isoler les commandes à risque élevé avant la préparation des colis. L'action « Voir » ouvre directement la fiche commande concernée.
## L'alerte email
Lorsqu'une commande franchit le seuil de risque élevé à sa création, un email récapitulatif part vers l'adresse logistique configurée : référence de commande, score, niveau, client, facteurs contributifs et note IA éventuelle. Les modèles d'email sont fournis en français et en anglais, et l'envoi tient compte de la langue du client et de la boutique d'origine de la commande.
Le module informe et alerte, mais ne modifie jamais le statut de la commande et n'empêche pas l'expédition. La décision finale reste humaine.
## Compatibilité et notes techniques
- PrestaShop 8.0 à 9.x, multiboutique et multilingue.
- Contrôleur d'administration legacy (pas de contrôleur Symfony) pour la compatibilité PS8/PS9.
- Endpoint AJAX back-office via le 4ᵉ argument de `getAdminLink()` ; rendu JSON par une méthode dédiée.
- Table `df_return_risk` : un enregistrement par commande, avec score, niveau, facteurs (JSON) et indicateur d'alerte.
- Couche IA optionnelle : seules les données nécessaires au calcul sont transmises à Mistral ; repli automatique sur l'heuristique.
## FAQ et dépannage
**Le panneau de risque n'apparaît pas sur la fiche commande.** Vérifiez que le module est bien greffé sur le hook `displayAdminOrderSide` et que la commande a été créée après l'installation. Utilisez le bouton « Recalculer » pour forcer le scoring.
**Aucune alerte email n'est reçue.** Vérifiez que l'adresse d'alerte est renseignée et valide, et que la commande dépasse réellement le seuil Élevé. L'alerte n'est envoyée qu'une fois par commande.
**L'IA ne renvoie pas d'explication.** Vérifiez la clé API et le nom du modèle Mistral. Le module bascule de toute façon sur le score heuristique ; aucun score n'est perdu.
**Tous les nouveaux clients sont-ils considérés à risque ?** Non. L'absence d'historique ajoute seulement une légère majoration ; le score dépend surtout des autres facteurs (bracketing, catégories, valeur du panier).
---
### AI Review Pros/Cons Synthesizer – Guide complet
_Source :_
> Documentation d'installation et de configuration du module AI Review Pros/Cons Synthesizer : fournisseurs IA, sources d'avis, génération en masse, cron multilingue et affichage.
Le module **AI Review Pros/Cons Synthesizer** lit les avis clients d'un produit et en génère, par intelligence artificielle, une synthèse en badges **Avantages** et **Inconvénients** affichés directement sur la fiche produit. Les synthèses sont mises en cache par produit, langue et boutique, et rafraîchies automatiquement via un cron.
## Présentation
Quand une fiche cumule des centaines d'avis, peu de visiteurs les lisent. Le module condense ce signal en quelques badges clairs, accompagnés d'une phrase de résumé neutre et d'un compteur de mentions. Trois fournisseurs IA sont pris en charge : Mistral AI, OpenAI et Anthropic (Claude). Chaque synthèse est produite dans la langue de la fiche, ce qui convient aux catalogues multilingues.
## Prérequis
- PrestaShop 8.0 à 9.x (mono ou multiboutique).
- PHP 7.4 à 8.x avec l'extension cURL active.
- Une source d'avis : le module officiel _Product Comments_, ou _DataFirefly Reviews_.
- Une clé API auprès d'un fournisseur IA (Mistral, OpenAI ou Anthropic).
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules > Envoyer un module**.
2. Sélectionnez l'archive `dfreviewsynth.zip` puis installez.
3. Cliquez sur **Configurer** pour accéder aux réglages.
**Bon à savoir.** L'installation crée une table de cache dédiée et un onglet d'administration masqué servant uniquement aux appels de génération.
## Configuration
### Fournisseur IA et clé API
Choisissez le **fournisseur** (Mistral, OpenAI ou Anthropic), collez votre **clé API** et renseignez le **modèle** souhaité :
- Mistral : `mistral-small-latest`
- OpenAI : `gpt-4o-mini`
- Anthropic : `claude-haiku-4-5`
**Astuce.** Laissez le champ de clé vide lors d'un nouvel enregistrement pour conserver la clé déjà mémorisée : elle n'est jamais réaffichée pour des raisons de sécurité.
### Source des avis
Sélectionnez l'origine des avis. L'adaptateur _Product Comments_ lit les commentaires approuvés et non supprimés. L'adaptateur _DataFirefly Reviews_ lit les avis actifs ; ajustez au besoin le nom des colonnes dans la classe d'accès aux données si votre schéma diffère.
### Position d'affichage
Deux emplacements sont disponibles sur la fiche produit : **sous la description courte** (informations complémentaires) ou **en pied de fiche**.
### Seuils et cache
- **Nombre minimum d'avis** : en deçà, aucune synthèse n'est générée.
- **Badges maximum par côté** : limite le nombre d'Avantages et d'Inconvénients affichés.
- **Avis maximum envoyés à l'IA** : plafonne la consommation de jetons (les avis les plus récents sont prioritaires).
- **Durée de vie du cache (jours)** : utilisée par le cron pour rafraîchir les synthèses obsolètes.
## Générer les synthèses
### Console d'administration
Dans la page de configuration, la console permet de charger les produits éligibles (ceux qui atteignent le seuil minimum d'avis), puis de générer les synthèses à l'unité ou en masse, avec barre de progression. La génération s'effectue dans la langue courante du back-office.
### Cron multilingue
Pour maintenir automatiquement à jour toutes les langues, planifiez un appel régulier à l'URL de cron affichée dans la configuration :
```
/index.php?fc=module&module=dfreviewsynth&controller=cron&token=VOTRE_TOKEN&limit=20
```
Le paramètre `limit` plafonne le nombre de produits traités par exécution (défaut 20, maximum 100). Le cron parcourt chaque langue active et ne régénère que les synthèses manquantes, en erreur ou obsolètes.
**Attention.** Le jeton de cron est confidentiel. En cas de fuite, régénérez-le depuis la page de configuration : l'ancienne URL cessera immédiatement de fonctionner.
## Affichage côté client
Sur la fiche produit, le module affiche un bloc « Ce que disent les clients » avec deux colonnes (Avantages en vert, Inconvénients en orange), une phrase de résumé neutre optionnelle, le nombre d'avis pris en compte et un compteur de mentions par badge. Une mention « résumé généré par IA » peut être affichée pour la transparence vis-à-vis des clients.
## Catalogue multilingue
Chaque synthèse est stockée par produit, langue et boutique. Le contenu est généré dans la langue de la fiche, et le cron synchronise l'ensemble des langues actives. Une synthèse n'est régénérée que lorsque le contenu des avis change (détection par empreinte) ou lorsque le cache arrive à expiration.
## Dépannage
- **Aucun badge ne s'affiche.** Vérifiez que le produit atteint le nombre minimum d'avis et qu'une synthèse a bien été générée (console ou cron).
- **Statut « erreur » dans la console.** Contrôlez la clé API, le nom du modèle et la disponibilité de cURL ; le détail de la dernière erreur est conservé en cache.
- **Avis non détectés.** Confirmez la source sélectionnée et, pour DataFirefly Reviews, la correspondance des colonnes dans l'adaptateur.
## Journal des versions
- **1.0.0** — Première version publique : synthèse Avantages / Inconvénients par IA (Mistral, OpenAI, Anthropic), cache multilingue, console d'administration et cron de rafraîchissement.
---
### AI Size & Fit Advisor — Guide complet
_Source :_
> AI Size & Fit Advisor remplace votre guide des tailles statique par un véritable conseiller : le client saisit ses mensurations sur la fiche produit et reçoit la taille la…
AI Size & Fit Advisor remplace votre guide des tailles statique par un véritable conseiller : le client saisit ses mensurations sur la fiche produit et reçoit la taille la plus adaptée, avec un indice de confiance, une alternative et le détail mensuration par mensuration. Ce guide couvre l'installation, la configuration, la création des guides de tailles et le fonctionnement du moteur de recommandation.
## Installation
1. Téléchargez l'archive `dfsizefit.zip` depuis votre compte DataFirefly.
2. Back-office PrestaShop → **Modules** → **Téléverser un module** → envoyez le ZIP.
3. Le module crée ses tables, enregistre ses hooks et ajoute l'onglet **Catalogue → Size & Fit Charts**.
Compatible PrestaShop 8.0 à 9.x, en PHP 7.2.5+ (PS8) et 8.1+ (PS9). Aucun override, aucune dépendance externe.
## Configuration générale
Rendez-vous dans **Modules → AI Size & Fit Advisor → Configurer**.
### Couche IA
Le module fonctionne sans IA grâce à son moteur déterministe. Vous pouvez activer une couche IA optionnelle pour affiner la décision selon la morphologie et générer une explication dans la langue du client.
- **Activer la couche IA** : si désactivée, aucun appel externe n'est effectué.
- **Fournisseur** : Mistral, OpenAI ou Anthropic.
- **Clé API** : stockée côté serveur, jamais exposée au front-office.
- **Modèle** : par exemple `mistral-small-latest`, `gpt-4o-mini` ou `claude-haiku-4-5`.
En cas d'échec ou de dépassement du délai de l'API, le module repasse automatiquement sur le moteur déterministe. La recommandation reste donc toujours disponible.
### Préférence de coupe
Activez cette option pour proposer au client les choix _Ajustée / Classique / Ample_. Le module applique un biais de ±3 % sur les mensurations afin d'orienter la taille vers le haut ou le bas selon la coupe souhaitée.
### Fit-learning
Lorsqu'il est activé, le module journalise de façon anonymisée les profils et les recommandations dans la table dédiée, afin d'analyser la pertinence et de repérer les références qui taillent petit ou grand.
### Unité et hook d'affichage
- **Unité par défaut** : centimètres ou pouces.
- **Hook d'affichage** : `displayProductActions` (près du bouton d'ajout au panier) ou `displayProductAdditionalInfo` (sous les informations produit).
- **Libellé du bouton** : laissez vide pour utiliser la traduction par défaut « Trouver ma taille ».
## Créer un guide des tailles
Ouvrez **Catalogue → Size & Fit Charts → Ajouter**.
### Portée
Chaque guide possède une portée qui détermine les produits concernés :
- **Global** : s'applique à tous les produits (référence laissée à 0).
- **Catégorie** : renseignez l'ID de la catégorie.
- **Produit** : renseignez l'ID du produit.
La résolution se fait en cascade : le module cherche d'abord un guide au niveau du produit, puis de ses catégories, puis le guide global. Le premier trouvé est utilisé.
### L'éditeur de grille
L'éditeur visuel fonctionne comme un tableau : une ligne par taille, une colonne par mensuration.
- Ajoutez une colonne de mensuration (poitrine, taille, hanches, entrejambe, longueur de pied, etc.) via le sélecteur, puis le bouton « Ajouter une colonne ».
- Ajoutez une ligne de taille avec « Ajouter une taille » et nommez-la (S, M, L, 38, 40…).
- Pour chaque cellule, indiquez une plage **minimum / maximum** dans l'unité configurée.
- Choisissez le **genre** (femme, homme, unisexe, enfant) et activez le guide.
Renseignez des plages cohérentes et sans trou entre les tailles. Plus les mensurations couvertes sont nombreuses, plus la recommandation est fiable.
## Comment fonctionne la recommandation
La recommandation se déroule en plusieurs étapes :
1. **Matching déterministe** : le moteur score chaque taille en comparant les mensurations du client aux plages de la grille (distance au centre de chaque plage, pénalité si hors plage), puis applique le biais de coupe.
2. **Affinage IA (optionnel)** : si la couche IA est active, le fournisseur confirme ou ajuste la taille en tenant compte de la morphologie (taille, poids) et rédige une explication courte.
3. **Repli** : si l'IA échoue, le résultat déterministe est conservé.
Le client reçoit la taille recommandée, un indice de confiance, une taille alternative et le détail par mensuration (dans la fourchette, serré ou large).
## Affichage côté client
Sur la fiche produit, un bouton « Trouver ma taille » ouvre une modale. Le client saisit ses mensurations, éventuellement sa taille, son poids et sa préférence de coupe, puis valide. Le résultat s'affiche dans la même fenêtre, avec une barre de confiance et la décomposition par mensuration.
## Fit-learning et analyse des retours
Chaque recommandation peut être journalisée avec son profil anonymisé, le moteur utilisé et l'indice de confiance. Le statut de retour (gardé, retourné trop petit, retourné trop grand) permet, à terme, d'identifier les coupes problématiques et d'ajuster vos grilles.
## Compatibilité et notes techniques
- PrestaShop 8.x et 9.x, multiboutique et multilingue.
- Contrôleur d'administration legacy (pas de contrôleur Symfony) pour la compatibilité PS8/PS9.
- Endpoint AJAX front via le lien de module ; rendu JSON par une méthode dédiée.
- Données client stockées sur votre boutique ; seule la partie nécessaire au calcul est transmise au fournisseur IA choisi.
## FAQ et dépannage
**Le bouton n'apparaît pas sur la fiche produit.** Vérifiez qu'un guide actif s'applique au produit (portée produit, catégorie ou global) et que le hook d'affichage choisi est bien greffé sur votre thème.
**La recommandation indique un manque de données.** Le client n'a pas renseigné de mensuration correspondant aux colonnes de la grille. Ajoutez des colonnes communes (poitrine, taille, hanches) ou invitez le client à compléter davantage de champs.
**L'IA ne renvoie rien.** Vérifiez la clé API et le nom du modèle. Le module bascule de toute façon sur le moteur déterministe ; aucune recommandation n'est perdue.
---
### Arrondi Solidaire & Don au Checkout — Guide complet
_Source :_
> Présentation Le module Arrondi Solidaire & Don au Checkout (dfsolidarityround) permet à vos clients de soutenir une association en quelques secondes, directement dans le panier : en arrondissant leur commande…
## Présentation
Le module **Arrondi Solidaire & Don au Checkout** (`dfsolidarityround`) permet à vos clients de soutenir une association en quelques secondes, directement dans le panier : en **arrondissant leur commande à l'euro supérieur**, en choisissant un **montant de don prédéfini**, ou en saisissant un **montant libre**. Le don s'intègre proprement au total — TVA, devise et multiboutique étant gérés par le cœur de PrestaShop, jusqu'à la facture.
Le don n'est pas un simple affichage : il est porté par un produit virtuel dédié et un prix spécifique limité au panier du client. Le montant se retrouve donc naturellement dans les totaux, la commande et la facture.
## Compatibilité
- PrestaShop 8.0 à 9.x
- Mono-boutique et multiboutique
- PHP 7.4 à 8.3
- Thème Classic et thèmes personnalisés
- Interface livrée en français, anglais, espagnol, allemand et italien
- Aucune dépendance (ni Composer ni framework)
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** puis sélectionnez le fichier `dfsolidarityround.zip`.
3. Une fois installé, cliquez sur **Configurer**.
À l'installation, le module crée sa table d'historique, enregistre ses hooks (ressources front, bloc au panier et au checkout, validation de commande), ajoute l'onglet back-office **Dons solidaires** et génère un **produit virtuel caché « Don solidaire »** : non visible en boutique, sans TVA, sans frais de livraison. C'est lui qui porte le montant du don dans le panier. Ne le supprimez pas manuellement.
## Configuration
### Modes de don
Trois modes sont disponibles et s'activent indépendamment. Vous pouvez n'en proposer qu'un seul, ou les trois à la fois.
- **Arrondi à l'euro supérieur** : propose au client de porter sa commande au montant rond supérieur. Le **pas d'arrondi** est configurable (`1,00` pour l'euro supérieur, `0,50` pour le demi-euro, etc.).
- **Montants fixes** : affiche des boutons prêts à cliquer. La liste des montants est configurable (par exemple `1;2;5`).
- **Montant libre** : laisse le client saisir la somme de son choix, encadrée par un **don minimum** et un **don maximum**.
En mode arrondi, si le total du panier est déjà un montant rond, le module propose un don d'un pas complet pour que l'opt-in du client ait toujours du sens.
### Personnalisation de l'association
- **Titre du bloc** : intitulé affiché en tête du bloc (champ multilingue).
- **Nom de l'association** : nom de la cause soutenue (champ multilingue).
- **Description** : court texte d'accompagnement (champ multilingue).
- **Logo de l'association** : visuel affiché dans le bloc (PNG, JPG, GIF, WEBP ou SVG).
### Emplacements d'affichage
- **Afficher sur la page Panier** : affiche le bloc au bas de la page panier (emplacement principal et fiable).
- **Afficher dans le tunnel de commande** : affiche le bloc dans le récapitulatif de commande, si votre thème expose l'emplacement correspondant.
## Fonctionnement côté client
### Arrondi à l'euro supérieur
Le client voit un bouton du type « Arrondir et donner 0,73 € ». Le montant proposé correspond à la différence entre son total et le montant rond supérieur, selon le pas configuré.
### Montants fixes
Le client clique sur l'un des montants proposés (1 €, 2 €, 5 €…). Le don correspondant est ajouté immédiatement.
### Montant libre
Le client saisit le montant de son choix puis valide. La valeur est contrôlée par rapport au minimum et au maximum définis.
Une fois le don ajouté, le bloc affiche un remerciement et un lien « Retirer le don ». Le client garde la main : il peut changer de montant ou retirer son don à tout moment avant le paiement.
## Comment le don est ajouté au panier
À chaque choix, le module crée un **prix spécifique** (`SpecificPrice`) limité au panier courant (`id_cart`) et l'applique au produit virtuel « Don solidaire ». Ce produit est ajouté au panier lorsque le montant est supérieur à zéro, retiré sinon. PrestaShop applique alors la devise et le contexte multiboutique, et le don apparaît comme une ligne claire dans les totaux, la commande et la facture.
### Recalcul automatique de l'arrondi
En mode arrondi, le montant du don est **recalculé à chaque affichage du bloc**. Ainsi, si le client modifie son panier après avoir choisi l'arrondi, le don reste cohérent avec le nouveau total jusqu'au paiement.
### Don sans TVA
Le produit « Don solidaire » est créé **sans règle de taxe** : le montant affiché et collecté correspond exactement au geste du client, sans surprise de TVA.
## Suivi des dons en back-office
Un onglet **Dons solidaires** est ajouté sous **Commandes** (contrôleur `AdminDfDonations`). Il liste chaque don avec :
- le **montant** du don ;
- le **mode** utilisé (arrondi, montant fixe ou montant libre) ;
- le **client** et la **commande** associée ;
- la **date** du don.
Un bandeau de synthèse affiche le **total collecté** et le nombre de dons. Le don est figé dans l'historique à la **validation de la commande** (`actionValidateOrder`).
## Reversement à l'association
Le module **ne reverse pas automatiquement** les dons à l'association : c'est volontaire. Il collecte les dons au sein de vos commandes et vous fournit le total et l'historique. Vous gardez la main sur le moment et le canal de reversement à votre association partenaire, selon votre propre process.
## Compatibilité PrestaShop 9
Le module est conçu et testé de PrestaShop 8.0 à 9.x :
- le contrôleur back-office utilise `ModuleAdminController`, compatible 8 et 9 ;
- le code évite les méthodes supprimées en PrestaShop 9 (jeton AJAX et formatage de prix portables) ;
- le contrôleur AJAX renvoie directement du JSON, sans override de signature incompatible.
## FAQ et dépannage
### Le bloc ne s'affiche pas dans le tunnel de commande
Le bloc s'affiche de façon fiable au bas de la page panier. Dans le récapitulatif de commande, l'affichage dépend du thème, qui doit exposer l'emplacement correspondant. Le don choisi sur la page panier est de toute façon conservé jusqu'au paiement.
### Le total n'est pas mis à jour après le clic
Le bloc déclenche un rafraîchissement du panier après l'ajout ou le retrait du don. Videz le cache de PrestaShop, puis rechargez la page. Vérifiez aussi que le produit « Don solidaire » n'a pas été supprimé manuellement.
### La boutique devient blanche après installation
Assurez-vous d'utiliser la dernière version du module et videz le cache. Le produit de don est volontairement non visible en boutique ; ne le rendez pas visible et ne le supprimez pas manuellement.
### Le don d'arrondi me semble incorrect
Vérifiez le **pas d'arrondi** configuré. En mode arrondi, le don est recalculé à chaque affichage du bloc à partir du total hors don ; si le panier change, le montant est ajusté automatiquement.
### Comment traduire le bloc dans une autre langue ?
Le titre, le nom de l'association et la description sont des champs multilingues : sélectionnez chaque langue dans la configuration pour les traduire. Les libellés d'interface se traduisent via **Paramètres avancés > Traductions > Traductions des modules installés**, en choisissant `dfsolidarityround`.
### Est-ce compatible PrestaShop 9 ?
Oui. Le module est conçu et testé de PrestaShop 8.0 à 9.x, en mono-boutique comme en multiboutique.
## Désinstallation
La désinstallation supprime le produit « Don solidaire », l'onglet back-office et la table d'historique des dons. Si vous souhaitez conserver l'historique, désactivez le module sans le désinstaller.
---
### Assistant de Choix Produit — Documentation
_Source :_
> L'Assistant de Choix Produit (module dffinder) transforme un catalogue complexe en un parcours d'achat guidé. Vous construisez un arbre de questions dans le back-office ; le visiteur y répond étape…
L'**Assistant de Choix Produit** (module `dffinder`) transforme un catalogue complexe en un parcours d'achat guidé. Vous construisez un arbre de questions dans le back-office ; le visiteur y répond étape par étape et arrive sur une sélection de produits filtrée, exactement comme le ferait un vendeur-conseil en boutique.
## Présentation
Le module s'adresse aux catalogues où le client hésite : matelas, vélos, informatique, cosmétiques, pièces détachées. Chaque réponse du questionnaire est reliée à un ou plusieurs critères de votre catalogue (attributs, caractéristiques, catégories, fabricants, fourchettes de prix), et le module traduit les choix du visiteur en une recherche produit native.
- Builder d'arbre de questions en glisser-déposer, sans code.
- Questions à choix unique ou multiple, titres et libellés multilingues.
- Compteur de produits correspondants en temps réel à chaque étape.
- Page de résultats native (tri et pagination du thème) via `ProductSearchProviderInterface`.
- Affichage en widget page d'accueil, balise widget ou page dédiée.
- Compatible PrestaShop 8.0 à 9.x, multiboutique et multilingue.
## Installation
1. Rendez-vous dans _Modules > Gestionnaire de modules > Téléverser un module_.
2. Sélectionnez l'archive `dffinder-1.0.0.zip` et validez l'installation.
3. Le module crée ses tables, un onglet d'administration **DF Product Finder** et les routes réécrites `product-finder` et `product-finder/results`.
Après l'installation, si les URL `product-finder` ne répondent pas, régénérez les liens : _Paramètres avancés > Performances > Vider le cache_, puis vérifiez que les URL simplifiées sont activées dans _Trafic & SEO_.
## Créer un premier finder
Ouvrez _Modules > DF Product Finder_ et cliquez sur **Ajouter un finder**. Donnez-lui un nom interne et un texte d'introduction affiché en tête du questionnaire. Le builder s'organise en colonnes : les questions à gauche, les réponses de chaque question, et les mappings de chaque réponse.
### Ajouter des questions
Cliquez sur **Ajouter une question**. Pour chaque question, renseignez :
- le **titre** (ex. « Pour quel usage ? ») et un **texte d'aide** facultatif ;
- le **type d'affichage** : choix unique (une seule réponse, avec auto-avance) ou choix multiple (plusieurs réponses cochables) ;
- l'ordre, en faisant glisser la question à la position voulue.
### Ajouter des réponses
Sous chaque question, ajoutez les réponses proposées au visiteur (ex. « Sport », « Ville », « Enfant »). Chaque réponse possède un libellé multilingue et se réordonne par glisser-déposer au sein de sa question.
### Mapper les réponses au catalogue
C'est le cœur du module : chaque réponse pointe vers un ou plusieurs critères produit. Les types de mapping disponibles sont :
- **Attribut** — une valeur d'attribut de déclinaison (taille, couleur…), recherchée sur les combinaisons produit ;
- **Caractéristique** — une valeur de caractéristique produit ;
- **Catégorie** — l'appartenance à une catégorie ;
- **Fabricant** — la marque du produit ;
- **Prix** — une fourchette `min`/`max` sur le prix de base de la boutique.
Les champs attribut, caractéristique, catégorie et fabricant disposent d'une autocomplétion : saisissez quelques lettres pour retrouver la valeur. Une même réponse peut cumuler plusieurs mappings (par exemple une catégorie _et_ une fourchette de prix).
Les fourchettes de prix filtrent sur le **prix de base hors taxes** du produit pour la boutique courante (`product_shop.price`). Les taxes et les prix spécifiques (promotions, prix par groupe) ne sont pas appliqués dans ce filtre.
Quand votre arbre est prêt, cliquez sur **Enregistrer**. La sauvegarde est idempotente : l'arbre complet est reconstruit à chaque enregistrement, ce qui garantit un état cohérent.
## Comprendre le moteur de matching
Le module combine les choix du visiteur selon deux règles simples :
- **OU** entre les réponses d'une même question : cocher « Sport » et « Ville » élargit la sélection aux produits correspondant à l'une _ou_ l'autre.
- **ET** entre les questions : les critères de chaque question franchie se cumulent pour resserrer la sélection.
À chaque étape, le module recalcule en AJAX le nombre de produits correspondants et l'affiche au visiteur, ce qui évite d'aboutir à une sélection vide.
## Afficher le finder
### Widget page d'accueil
Activez l'affichage en page d'accueil depuis la configuration du module. Le widget présente une carte d'appel à l'action menant au questionnaire.
### Balise widget
Pour insérer le finder n'importe où dans un template de votre thème, utilisez la balise Smarty :
```
{widget name='dffinder' id_finder=1}
```
Remplacez `id_finder` par l'identifiant du finder souhaité (visible dans la liste du back-office).
### URL dédiées
Le questionnaire est également accessible directement via des URL propres, pratiques pour vos campagnes :
- `votre-boutique/product-finder` — le questionnaire ;
- `votre-boutique/product-finder/results?answers=1,4,9` — la page de résultats.
## La page de résultats
À la fin du questionnaire, le visiteur est dirigé vers une page de résultats qui étend le contrôleur de listing natif de PrestaShop. Concrètement, vous récupérez sans réglage supplémentaire :
- le gabarit de liste produit de votre thème ;
- le tri par date, prix ou nom ;
- la pagination standard.
Un lien **Recommencer** permet au visiteur de relancer le questionnaire depuis le début.
## Multiboutique et multilingue
Le module est associé au contexte boutique : chaque finder appartient à la ou aux boutiques de votre choix. Tous les textes (nom, introduction, titres de questions, libellés de réponses) sont saisissables par langue grâce au sélecteur de langue d'édition présent en haut du builder.
## Dépannage
**Le compteur affiche toujours zéro.** Vérifiez que les mappings pointent vers des valeurs réellement utilisées par vos produits (attribut/caractéristique bien affecté aux produits), et que les produits sont actifs et associés à la boutique courante.
**La fourchette de prix ne filtre pas comme attendu.** Rappelez-vous que le filtre s'applique au prix de base hors taxes, sans prix spécifiques. Un produit en promotion reste filtré sur son prix catalogue.
**Bonne pratique.** Commencez par une question générale (usage, profil) puis affinez (budget, taille). Limitez chaque question à quelques réponses claires pour garder un parcours fluide.
---
### Assurance Colis au Checkout — Installation et configuration
_Source :_
> Présentation Le module Assurance Colis au Checkout affiche une offre d'assurance transport facultative au moment du paiement. Le client l'active d'un clic, et le montant correspondant est ajouté à sa…
## Présentation
Le module Assurance Colis au Checkout affiche une offre d'assurance transport facultative au moment du paiement. Le client l'active d'un clic, et le montant correspondant est ajouté à sa commande sous la forme d'une ligne dédiée. L'assurance étant gérée comme une ligne de commande standard, elle apparaît automatiquement dans les totaux, sur la facture, dans le détail de commande au back-office et dans les e-mails.
Le tarif peut être un montant fixe ou un pourcentage du panier, avec des bornes optionnelles. Le module est compatible PrestaShop 1.7.6+, 8 et 9, en mono comme en multi-boutique, et multilingue.
## Installation
1. Depuis le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez l'archive ZIP du module.
3. Une fois l'installation terminée, cliquez sur **Configurer**.
À l'installation, le module crée un produit technique masqué « Assurance colis » qui sert de support à la ligne d'assurance. Ce produit n'est pas visible dans le catalogue et ne doit pas être supprimé manuellement.
## Configuration
### Activer l'assurance
L'interrupteur **Activer l'assurance** contrôle l'affichage global de l'offre au checkout. Désactivez-le pour masquer temporairement l'assurance sans désinstaller le module.
### Mode de calcul
Deux modes sont disponibles :
- **Montant fixe** : un tarif unique, saisi hors taxe, est proposé quel que soit le panier.
- **Pourcentage du panier** : le tarif correspond à un pourcentage du total produits hors taxe, hors assurance. Il est recalculé automatiquement si le panier change.
### Plancher et plafond
En mode pourcentage notamment, vous pouvez encadrer le tarif final avec un **plancher** (montant minimum facturé) et un **plafond** (montant maximum). Laissez ces champs à 0 pour ne pas appliquer de borne.
### Panier minimum
Définissez un **panier minimum** (hors taxe) en dessous duquel l'assurance n'est pas proposée. La valeur 0 propose l'assurance pour tous les paniers.
### Règle de taxe
Sélectionnez la **règle de taxe** applicable à la ligne d'assurance. Les montants saisis dans la configuration sont des montants hors taxe ; la taxe est ajoutée selon la règle choisie. Laissez « Aucune taxe » si l'assurance n'est pas taxée.
### Cochée par défaut
Activez l'option **Cochée par défaut** pour ajouter l'assurance automatiquement dès l'arrivée au tunnel de commande. Le client reste libre de la retirer ; son choix est mémorisé pour le reste du parcours.
### Titre et description
Le **titre affiché** et la **description** sont personnalisables et traduisibles par langue. Ils constituent l'argumentaire présenté au client sur la carte d'assurance.
## Côté client
À l'étape de paiement, une carte présente l'offre d'assurance avec son tarif. Le client coche ou décoche la case : le montant est ajouté ou retiré du panier sans qu'il ait à quitter le tunnel. Les totaux et les options de paiement sont mis à jour en conséquence.
## Commande, facture et e-mails
Comme l'assurance est une ligne de commande native, elle figure automatiquement dans le récapitulatif de commande, sur la facture, dans le détail de la commande au back-office et dans les e-mails de confirmation. Elle reste compatible avec la gestion des taxes et des avoirs.
## Désinstallation
La désinstallation du module supprime le produit technique « Assurance colis », ses tarifs spécifiques et l'ensemble de la configuration. Les commandes déjà passées conservent la ligne d'assurance qu'elles contenaient.
## FAQ
### Comment le montant de l'assurance est-il ajouté à la commande ?
Le module ajoute une ligne de commande standard dont le prix correspond au tarif calculé. Elle apparaît dans les totaux, la facture et les e-mails.
### Puis-je facturer un pourcentage du panier ?
Oui. En mode pourcentage, le tarif est calculé sur le total produits hors taxe (hors assurance), encadré par le plancher et le plafond éventuels.
### Le module est-il compatible PrestaShop 1.7, 8 et 9 ?
Oui, le module est compatible PrestaShop 1.7.6+, 8.x et 9.x, en mono comme en multi-boutique.
---
### Audit Sémantique — Documentation
_Source :_
> Installation Prérequis PrestaShop 8.0 à 9.x PHP 7.4 minimum (8.x recommandé) MySQL 5.7+ ou MariaDB 10.3+ Une clé API OpenAI ou Mistral (optionnel — un mode local sans API est…
## Installation
### Prérequis
- PrestaShop 8.0 à 9.x
- PHP 7.4 minimum (8.x recommandé)
- MySQL 5.7+ ou MariaDB 10.3+
- Une clé API OpenAI ou Mistral (optionnel — un mode local sans API est inclus)
### Installer le module
1. Décompressez le fichier `dfsemanticaudit.zip` téléchargé depuis votre compte client.
2. Uploadez le dossier `dfsemanticaudit/` dans `/modules/` de votre PrestaShop via FTP, ou utilisez l'installation par ZIP depuis **Modules → Module manager → Téléverser un module**.
3. Cliquez sur **Installer**.
### Activer le module
Le module crée automatiquement quatre tables SQL (`ps_dfsa_content`, `ps_dfsa_audit`, `ps_dfsa_cluster`, `ps_dfsa_assignment`) ainsi qu'un onglet d'administration accessible depuis le menu de gauche.
## Configuration
Avant le premier audit, rendez-vous dans **Modules → DataFirefly → Audit Sémantique → Configuration**.
### Choix du fournisseur d'embeddings
Trois fournisseurs sont disponibles. Le choix détermine la qualité des clusters obtenus.
### OpenAI (recommandé)
Le fournisseur par défaut. Utilise le modèle `text-embedding-3-small` (1 536 dimensions). Qualité maximale, coût marginal : environ 0,02 € pour 1 000 produits lors de la première indexation.
- **Clé API** : créez-la depuis [platform.openai.com/api-keys](https://platform.openai.com/api-keys)
- **Modèle** : laissez `text-embedding-3-small` par défaut. `text-embedding-3-large` (3 072 dim) donne une qualité légèrement supérieure mais coûte 6× plus cher.
### Mistral
Alternative européenne hébergée en France. Utilise `mistral-embed` (1 024 dimensions). Tarification comparable à OpenAI.
- **Clé API** : créez-la depuis [console.mistral.ai](https://console.mistral.ai/)
- **Modèle** : `mistral-embed`
### TF-IDF local
Fonctionne entièrement sur votre serveur, sans appel API, sans coût récurrent. Utilise les principes classiques du traitement statistique du langage (TF-IDF normalisé) avec une dimension de 384.
- Qualité suffisante pour les catalogues de moins de 500 produits.
- Supporte FR, EN, ES, DE, IT (stopwords intégrés).
- Aucune clé API requise.
**Astuce** — Vous pouvez changer de fournisseur à tout moment. Au prochain audit, tous les contenus seront ré-embarqués automatiquement.
### Paramètres d'audit
- **k (nombre de clusters)** : 8 par défaut. Plage 2–50.
- **Seuil hors-topic** : distance cosinus à partir de laquelle un contenu est signalé. 0,55 par défaut. Plage 0,1 à 1,5.
### Auto-reindex
Activé par défaut. Le module enregistre des hooks sur la création, modification et suppression des produits, catégories et pages CMS. À chaque changement, le contenu est marqué pour ré-embedding au prochain run, sans effort manuel.
## Lancer son premier audit
Trois étapes à effectuer dans l'ordre depuis le **tableau de bord**.
### Étape 1 — Réindexer le contenu
Cliquez sur **Réindexer le contenu**. Le module parcourt vos produits, catégories actives, pages CMS et fabricants, calcule un hash `SHA1` du titre + extrait, et ne marque pour traitement que les contenus nouveaux ou modifiés.
Pour 1 000 contenus, cette étape dure quelques secondes.
### Étape 2 — Générer les embeddings
Cliquez sur **Générer les embeddings**. Le module envoie les contenus marqués comme "dirty" au fournisseur sélectionné par lots de 50 (OpenAI/Mistral) ou en une passe locale (TF-IDF). Une barre de progression suit l'avancement.
Pour 1 000 contenus :
- OpenAI : ~30 secondes
- Mistral : ~40 secondes
- TF-IDF local :
### Étape 3 — Lancer l'audit
Cliquez sur **Lancer l'audit**. Le clustering k-means cosinus regroupe les contenus en `k` clusters (initialisation k-means++, 50 itérations maximum), étiquette chaque cluster avec ses top termes (TF×IDF), calcule la distance de chaque contenu à son centroïde, et identifie les outliers.
Cette étape prend moins d'une seconde, même pour 5 000 contenus.
## Comprendre le rapport
### Tableau de bord
Quatre KPIs clés en haut :
- **Contenus indexés** — total de produits, catégories, CMS et fabricants embarqués.
- **Pages hors-topic** — nombre absolu, taux en pourcentage et répartition par type.
- **Clusters thématiques** — nombre de groupes thématiques identifiés.
- **Distance médiane** — distance cosinus médiane au centroïde. En dessous de 0,40 = catalogue très cohérent. Au-dessus de 0,60 = catalogue dispersé.
### Clusters
Vue **Clusters** : liste détaillée triée par taille, avec étiquette automatique (top 5 termes TF×IDF), score de cohésion (0 = dispersé, 1 = identique), et taille (nombre de contenus).
Un cluster avec une **cohésion < 0,40** est trop hétérogène — c'est souvent le signe qu'il faudrait scinder le sujet en deux sous-thèmes, ou que `k` est trop bas.
### Carte sémantique 2D
Projection de tous les contenus sur un plan via la technique **Johnson-Lindenstrauss** (une projection aléatoire qui préserve approximativement les distances).
Chaque point est un contenu, chaque couleur un cluster. Les croix marquent les centroïdes. Les points avec un **contour rouge** sont les hors-topic. La légende à droite permet de masquer/afficher chaque cluster individuellement en cliquant dessus.
**Lecture rapide** — Si vous voyez des points d'une couleur perdus très loin de leur centroïde, ce sont des candidats prioritaires au déplacement.
### Pages hors-topic
Vue **Pages hors-topic** : tableau triable des contenus dont la distance cosinus au centroïde dépasse le seuil configuré. Pour chaque ligne :
- Type, titre, URL publique et lien direct vers la fiche d'édition
- Cluster actuel (avec sa couleur)
- Distance au centroïde (plus elle est élevée, plus le contenu est éloigné)
- Cluster suggéré (si pertinent)
- Δ Gain : réduction de distance si le contenu était déplacé
### Pages irrécupérables
En bas de la vue Hors-topic, une section spéciale liste les contenus éloignés **de tous les clusters**. Le module n'a pas trouvé de destination viable pour eux.
Trois actions à envisager :
1. **Supprimer** si la page n'a pas de trafic SEO ni de conversion.
2. **Noindex** pour préserver le budget de crawl sans perdre l'historique.
3. **Réécrire** pour aligner le contenu avec un cluster existant.
### Suggestions de restructuration
Vue **Suggestions** : équivalente à Pages hors-topic mais centrée sur l'action. Tous les déplacements proposés sont listés avec le gain de cohérence attendu. Triez par gain décroissant pour traiter les cas les plus impactants d'abord.
Le module ne modifie **jamais** votre arborescence automatiquement. Les changements restent sous votre contrôle via le back-office PrestaShop standard.
## Export CSV
Depuis chaque vue de rapport, un bouton **Exporter CSV** permet de télécharger les données brutes. Utile pour :
- Partager le rapport avec un consultant SEO externe
- Traiter les données dans Excel/Sheets
- Archiver l'état d'un audit avant de modifier l'arborescence
## Automatisation via cron
Le module expose une URL signée affichée dans la page de configuration. Elle déclenche en headless l'enchaînement complet **indexation → embeddings → audit**.
Exemple de tâche cron hebdomadaire (chaque lundi 3h) :
```
0 3 * * 1 wget -q -O /dev/null "https://votre-boutique.com/modules/dfsemanticaudit/cron.php?token=VOTRE_TOKEN"
```
Le token est dérivé de la `_COOKIE_KEY_` de votre PrestaShop et ne change qu'à la réinstallation. Notez-le précieusement.
## Coûts API
Estimation pour un catalogue moyen (1 000 produits) :
- **OpenAI text-embedding-3-small** : ~0,02 € la première fois, puis quasi nul (seuls les contenus modifiés sont retraités)
- **OpenAI text-embedding-3-large** : ~0,13 € la première fois
- **Mistral mistral-embed** : ~0,10 € la première fois
- **TF-IDF local** : 0 €
## Multi-langues et multi-boutique
Le module est nativement multi-langues et multi-boutique. Chaque audit s'exécute sur un couple **langue × boutique** donné, en utilisant la langue de contexte du back-office.
Pour auditer votre boutique en français puis en anglais, changez de langue dans la barre supérieure de PrestaShop, puis relancez un nouvel audit.
**Note** — Le module respecte la langue d'origine de chaque contenu, sans tentative de traduction automatique. Les clusters obtenus seront différents pour chaque langue, ce qui est normal.
## Dépannage
### L'étape "Générer les embeddings" échoue avec une erreur 401
Votre clé API est invalide ou expirée. Vérifiez-la dans la page de configuration et reconfigurez-la si nécessaire.
### L'étape "Générer les embeddings" échoue avec une erreur 429
Vous avez atteint la limite de débit de votre fournisseur. Attendez quelques minutes puis relancez — le module reprendra là où il s'était arrêté grâce à son traitement par lots.
### Aucun cluster ne semble pertinent
Trois pistes :
1. Augmentez le nombre de clusters (k). Si votre catalogue a 10 thématiques distinctes mais que k=4, le clustering ne pourra pas les séparer.
2. Passez du mode TF-IDF local à OpenAI ou Mistral. Sur les catalogues hétérogènes, la qualité sémantique fait toute la différence.
3. Vérifiez que les titres et descriptions de vos contenus sont suffisamment riches. Un produit avec un titre de 2 mots et aucune description ne donnera pas un bon embedding.
### Trop de pages signalées hors-topic
Augmentez le seuil hors-topic (par exemple de 0,55 à 0,70). C'est attendu si votre catalogue couvre légitimement plusieurs thématiques larges.
### Aucune page signalée hors-topic mais le catalogue semble incohérent
Baissez le seuil (par exemple de 0,55 à 0,40) pour resserrer la détection.
## FAQ
### Faut-il obligatoirement une clé API ?
Non. Le mode TF-IDF local fonctionne sans connexion externe. Il est légèrement moins précis que OpenAI/Mistral mais suffit pour démarrer ou pour un catalogue homogène.
### Le module modifie-t-il automatiquement mon arborescence ?
Non. Le module ne fait que **recommander**. Tous les déplacements de contenu restent à votre charge via le back-office standard de PrestaShop.
### Comment choisir le nombre de clusters (k) ?
Règle empirique : `k` ≈ nombre de catégories principales de premier niveau. Par défaut k=8 fonctionne bien entre 100 et 5 000 produits. Lancez 2 ou 3 audits avec différentes valeurs de k pour comparer si vous hésitez — les audits précédents restent en historique.
### Mes vecteurs sont-ils envoyés à un serveur tiers ?
Avec OpenAI ou Mistral : oui, les titres et extraits de vos contenus sont envoyés à leur API d'embeddings. Avec le mode TF-IDF local : non, aucune donnée ne quitte votre serveur.
### Combien de temps les audits sont-ils conservés ?
Indéfiniment, jusqu'à suppression manuelle depuis le tableau de bord. Vous pouvez consulter l'historique complet pour mesurer l'évolution de votre cohérence sémantique au fil du temps.
### Le module fonctionne-t-il en multi-boutique ?
Oui. Chaque boutique du multistore peut avoir ses propres audits indépendants.
---
### Avis Vérifiés WooCommerce — Documentation
_Source :_
> DataFirefly Reviews (dfreviews) transforme le système d'avis natif de WooCommerce en machine à preuve sociale : demandes d'avis automatiques après achat, badge Achat vérifié, photos client, votes utiles, résumé IA…
DataFirefly Reviews (dfreviews) transforme le système d'avis natif de WooCommerce en machine à preuve sociale : demandes d'avis automatiques après achat, badge Achat vérifié, photos client, votes utiles, résumé IA des avis sur la fiche produit, réponse automatique aux avis par IA, code promo récompense et rich snippets Schema.org. Cette documentation couvre l'installation, la configuration complète et le dépannage.
## Installation
1. Dans votre administration WordPress, ouvrez **Extensions → Ajouter → Téléverser une extension**.
2. Sélectionnez le fichier `dfreviews-1.0.0.zip` puis cliquez sur **Installer maintenant** et **Activer**.
3. Un nouveau sous-menu **WooCommerce → DF Reviews** apparaît : c'est le centre de contrôle du plugin.
Le plugin s'appuie sur les avis natifs WooCommerce : vos avis existants sont conservés et immédiatement exploitables. Aucune migration n'est nécessaire.
Prérequis : WooCommerce 8 ou 9, WordPress 6.0+, PHP 8.0 à 8.3. Le plugin est compatible HPOS (High-Performance Order Storage) et fonctionne sans jQuery ni Composer.
## Configuration de la clé OpenAI
Le résumé IA et la réponse automatique utilisent votre propre clé API OpenAI :
1. Créez une clé sur [platform.openai.com](https://platform.openai.com/api-keys).
2. Collez-la dans **WooCommerce → DF Reviews → Settings**, section **OpenAI**.
3. Le modèle par défaut est `gpt-4o-mini` — le plus économique, recommandé. Un résumé ou une réponse coûte typiquement bien moins d'un centime.
Sans clé OpenAI, toutes les autres fonctions (demandes d'avis, photos, votes, coupons, rich snippets) restent pleinement opérationnelles. L'onglet **AI tools** affiche l'état de la configuration IA.
## Demandes d'avis automatiques
Section **Review requests** des réglages :
- **Statut déclencheur** : la demande est mise en file quand une commande atteint ce statut (par défaut _Commande terminée_).
- **Délai d'envoi** : nombre de jours d'attente après le statut déclencheur (défaut : 3 jours).
- **Relance** : un unique email de rappel part si aucun avis n'a été déposé (défaut : 5 jours après le premier email).
Chaque email contient un lien d'avis personnel tokené : l'avis déposé via ce lien reçoit automatiquement le badge **Achat vérifié**. Les envois se font par lots de 50 à chaque passage du cron. L'onglet **Request queue** liste les 100 dernières demandes avec leur statut (pending, sent, reminded, completed, failed, unsubscribed) et permet de lancer un traitement manuel.
Chaque email comporte un lien de désinscription. Les adresses désinscrites sont stockées hashées en SHA-256 et ne reçoivent plus jamais de demande.
## Résumé IA des avis
Dès qu'un produit atteint le nombre minimum d'avis publiés (défaut : 3), le cron génère un bloc affiché en tête de l'onglet avis de la fiche produit : **points forts**, **points d'attention** et **synthèse**.
- Le résumé est mis en cache par produit **et par langue** : avec Polylang ou WPML, chaque version linguistique affiche un résumé dans sa langue.
- Il est régénéré automatiquement quand de nouveaux avis sont publiés (invalidation par empreinte des avis analysés).
- Le réglage **Max reviews analyzed** limite le nombre d'avis envoyés au modèle.
L'onglet **AI tools** liste les résumés générés avec leur langue et leur date.
## Réponse automatique aux avis par IA
Chaque avis publié peut recevoir une réponse marchande générée par IA, rédigée **dans la langue de l'avis**. Réglages clés :
- **Mode de publication** : _Brouillon_ (recommandé au départ — chaque réponse attend votre validation dans le menu Commentaires) ou _Publication immédiate_.
- **Ton** : chaleureux, professionnel ou concis.
- **Nom de signature** : affiché comme auteur de la réponse (vide = nom du site).
- **Répondre aux notes à partir de** : 1 pour répondre à tous les avis — recommandé, car les avis négatifs sont ceux qui bénéficient le plus d'une réponse.
Garde-fous intégrés : pour les notes de 3/5 ou moins, la réponse présente des excuses et oriente vers le support, sans jamais promettre de remboursement. La réponse est limitée à environ 70 mots et s'affiche avec le badge **Réponse officielle**, exclue des moyennes de notes et des rich snippets.
Pour les avis existants ou importés : action **Generate AI reply** dans la liste des commentaires WordPress, ou traitement de rattrapage par lots via le cron.
## Photos, votes et code promo récompense
- **Photos client** : les clients joignent jusqu'à 3 photos (configurable, max 10) à leur avis — formats jpg, png, webp, gif, 5 Mo max, affichage en lightbox.
- **Votes utiles** : boutons « Cet avis vous a-t-il été utile ? » avec protection anti-doublon par compte et par IP hashée. Jamais affichés sur les réponses marchandes.
- **Code promo** : à la publication de son avis, le client reçoit un coupon en pourcentage (défaut : 10 %, 30 jours), unique, à usage unique, restreint à son adresse email. Anti-farming : une seule récompense par email et par produit.
## Formulaire et affichage
- **Champ titre** de l'avis, optionnel ou obligatoire.
- **Longueur minimale** de l'avis en caractères (défaut : 10).
- **Bloc de répartition des notes** (barres 5★ à 1★) au-dessus de la liste des avis.
- **Couleur des étoiles** personnalisable (hexadécimal, défaut #e7a11a).
## Rich snippets Schema.org
Le plugin conserve le balisage AggregateRating et Review natif de WooCommerce en l'assainissant : les réponses marchandes sont exclues du balisage et des moyennes, pour des étoiles Google exactes. L'option peut être désactivée dans les réglages, ce qui retire alors tout balisage d'avis.
## Cron : fiabiliser les envois
Le traitement (demandes, relances, résumés IA, réponses de rattrapage) s'exécute toutes les heures via WP-Cron. WP-Cron ne se déclenchant qu'à la visite du site, configurez un vrai cron serveur pour un envoi fiable :
1. Copiez l'**URL de cron tokenée** affichée dans **Settings → Cron**.
2. Ajoutez-la dans le cron de votre hébergeur (ou crontab), toutes les 15 à 60 minutes, par exemple avec `curl -s "URL" > /dev/null`.
Un verrou anti-concurrence empêche deux traitements simultanés. Le bouton **Run processing now** de l'onglet Request queue lance un traitement manuel à tout moment.
## Import et export CSV
Onglet **Import / Export** :
- **Export** : tous les avis produits avec note, titre, indicateur vérifié et dates.
- **Import** : CSV avec ligne d'en-tête et colonnes `product_id` ou `sku`, `author`, `email`, `rating`, `title`, `content`, `date` (Y-m-d H:i:s, optionnel), `verified` (1/0, optionnel). Les statistiques de notes sont recalculées automatiquement après import.
## Espace client
Un onglet **Mes avis** est ajouté au compte client (Mon compte) : chaque client y retrouve ses avis avec statut de modération, étoiles et badge vérifié. Si l'onglet renvoie une erreur 404 après activation, réenregistrez les permaliens via **Réglages → Permaliens → Enregistrer**.
## RGPD et données
- Lien de désinscription dans chaque email de demande, adresses désinscrites stockées hashées en SHA-256, jamais en clair.
- Adresses IP des votants hashées avec le salt WordPress.
- Seul appel sortant : l'API OpenAI que vous contrôlez, uniquement si une clé est configurée.
- La désinstallation supprime les tables et réglages du plugin mais **conserve tous les avis** (avis WooCommerce natifs).
## Dépannage
- **Les demandes ne partent pas** : vérifiez que la fonction est activée, que des commandes atteignent le statut déclencheur, et que le cron tourne (dernier passage affiché dans AI tools). Configurez l'URL de cron serveur.
- **Pas de résumé IA** : clé OpenAI configurée ? Nombre minimum d'avis publiés atteint ? Le résumé est généré au passage du cron, pas instantanément.
- **Pas de réponse IA** : vérifiez le mode (en brouillon, la réponse attend dans Commentaires → En attente), la note minimale configurée, et la clé API.
- **Emails non reçus** : le plugin envoie via le mailer WooCommerce — testez votre configuration email globale (un plugin SMTP est recommandé).
---
### Barre Admin Front Office - Documentation
_Source :_
> Présentation Barre Admin Front Office ajoute une barre d'administration noire, façon WordPress, en haut de votre boutique PrestaShop 8 ou 9. Elle s'affiche uniquement pour les employés connectés au back-office…
## Présentation
Barre Admin Front Office ajoute une barre d'administration noire, façon WordPress, en haut de votre boutique PrestaShop 8 ou 9. Elle s'affiche uniquement pour les employés connectés au back-office et donne un accès direct à l'édition du produit, de la catégorie ou de la page CMS en cours de consultation, ainsi qu'un bouton de vidage de cache.
La barre est invisible pour vos visiteurs : aucun fichier CSS ou JavaScript du module n'est chargé pour eux.
## Installation
1. Dans le back-office, ouvrez Modules puis Module Manager.
2. Cliquez sur Installer un module et sélectionnez le fichier dfadminbar.zip.
3. Le module s'installe et enregistre automatiquement le nom de votre dossier admin.
La barre est active immédiatement : ouvrez votre boutique dans le même navigateur que votre session back-office et elle apparaît en haut de page.
## Configuration
Quatre réglages sont disponibles dans Modules, Module Manager, Barre Admin Front Office, Configurer :
- **Activer la barre d'administration** : interrupteur général du module.
- **Afficher le bouton de vidage du cache** : affiche ou masque le bouton Vider le cache dans la barre.
- **Restreindre au profil SuperAdmin** : lorsque cette option est active, seuls les employés du profil SuperAdmin voient la barre. Désactivée, tout employé connecté la voit.
- **Afficher les boutons Voir dans le back-office** : ajoute un bouton Voir le produit ou Voir la catégorie dans le header du back-office, sur les pages d'édition correspondantes.
## Utilisation
### La barre
La barre affiche en permanence trois liens vers le back-office : Tableau de bord, Catalogue et Commandes. Le prénom de l'employé connecté apparaît à droite. Les liens intègrent un jeton back-office valide : vous arrivez directement sur la page cible, sans page de connexion intermédiaire.
### Liens contextuels
Selon la page consultée, un lien d'édition s'ajoute à la barre :
- Fiche produit : Modifier ce produit ouvre la page d'édition du produit.
- Page catégorie : Modifier cette catégorie ouvre l'édition de la catégorie.
- Page CMS : Modifier cette page ouvre l'édition de la page CMS.
Sur PrestaShop 8 et 9, l'URL générée est convertie automatiquement vers la page d'édition moderne du back-office.
### Boutons Voir dans le back-office
Sur la page d'édition d'un produit ou d'une catégorie, un bouton Voir le produit ou Voir la catégorie s'ajoute dans le header noir du back-office, à côté de Voir ma boutique. Il ouvre la page correspondante du front office dans un nouvel onglet. Si le header ne contient pas ce lien (contexte multi-boutique avec sélecteur de boutiques), le bouton s'affiche en pastille flottante en bas à droite.
### Vidage de cache
Le bouton Vider le cache déclenche un appel AJAX qui vide les caches Smarty et XML, le cache Media (CCC) et régénère l'index de classes. Le libellé du bouton confirme l'opération (Cache vidé). Le cache Symfony n'est pas concerné : son vidage depuis le front provoquerait des temps de réponse trop longs.
## Fonctionnement technique
### Détection de l'employé
Le module lit le cookie employé psAdmin de PrestaShop, valide le hash du mot de passe avec Employee::checkPassword() et vérifie que le compte est actif. Aucune session supplémentaire n'est créée, aucun identifiant n'est stocké par le module.
### Liens back-office et jetons
Chaque lien est construit avec un jeton legacy calculé pour l'employé connecté (Tools::getAdminToken). PrestaShop convertit ensuite l'URL legacy vers la route moderne correspondante. L'appel AJAX de vidage de cache est protégé par un jeton dédié lié à l'identifiant de l'employé.
### Dossier admin
Le nom du dossier admin est enregistré à l'installation, puis rafraîchi à chaque ouverture de la page de configuration. Si vous renommez le dossier admin, rouvrez simplement la configuration du module.
## Dépannage
- **La barre ne s'affiche pas** : vérifiez que vous êtes connecté au back-office dans le même navigateur, que le module est activé dans sa configuration et que l'option SuperAdmin ne vous exclut pas.
- **La barre ne s'affiche plus après un renommage du dossier admin** : ouvrez la page de configuration du module pour réenregistrer le nouveau nom.
- **Back-office sur un autre domaine** : le cookie employé doit être partagé entre boutique et back-office, ce qui correspond à l'installation standard de PrestaShop. Un back-office hébergé sur un domaine différent n'est pas pris en charge.
- **Thème personnalisé sans le hook displayAfterBodyOpeningTag** : la barre est injectée par ce hook. S'il est absent de votre thème, ajoutez son appel dans le template principal.
## Changelog
- **1.1.0 (2026-08-22)** : bouton Voir le produit et Voir la catégorie dans le header du back-office, sur les pages d'édition correspondantes. Nouvelle option de configuration pour activer ou désactiver ces boutons.
- **1.0.0 (2026-08-12)** : première version publique. Barre d'administration front office, liens d'édition contextuels produit, catégorie et CMS, vidage de cache AJAX, restriction SuperAdmin, traductions FR, EN, ES, DE, IT, PL.
---
### Barre d'annonce & Compte à rebours (dfannouncebar)
_Source :_
> Présentation Le module dfannouncebar ajoute une barre d'annonce intelligente à votre boutique PrestaShop 8 ou 9 : plusieurs messages en rotation dans la même barre, un compte à rebours en…
## Présentation
Le module **dfannouncebar** ajoute une barre d'annonce intelligente à votre boutique PrestaShop 8 ou 9 : plusieurs messages en rotation dans la même barre, un compte à rebours en direct, un ciblage par langue, pays et groupe client, une planification par dates et un bouton de fermeture mémorisé par cookie. Trois emplacements sont disponibles : haut de page, haut fixe (sticky) et bas fixe.
## Installation
1. Dans le back-office, ouvrez **Modules → Gestionnaire de modules → Installer un module**.
2. Envoyez le fichier `dfannouncebar.zip` puis cliquez sur **Installer**.
3. Cliquez sur **Configurer** pour ouvrir la page du module.
À l'installation, le module crée une **barre d'exemple inactive** avec un message multilingue (code HELLO10 et compte à rebours à J+7) : activez-la pour voir immédiatement le rendu, puis adaptez-la ou supprimez-la.
Aucune dépendance : pas de Composer, pas de jQuery. Les fichiers JS et CSS du module ne sont chargés sur le front que si au moins une barre est active.
## Configuration générale
La page de configuration contient un réglage global : le **hook d'accroche** de l'emplacement « haut de page ».
- **displayBanner** (par défaut) : position standard au-dessus du header sur le thème Classic.
- **displayTop** : solution de secours si votre thème ne déclare pas displayBanner.
Une garde interne empêche tout double affichage si votre thème exécute les deux hooks. Les emplacements fixes (haut fixe et bas fixe) ne dépendent pas de ce réglage.
## Créer une barre
Depuis la page de configuration, cliquez sur **Gérer les barres**. Chaque barre possède :
- **Emplacement** : haut de page, haut fixe (suit le défilement) ou bas fixe. Le module compense automatiquement le padding de la page pour les positions fixes.
- **Priorité** : si plusieurs barres visent le même emplacement, seule celle avec la priorité la plus basse s'affiche.
- **Couleurs** : fond et texte, appliqués via des variables CSS.
- **Rotation** : intervalle en secondes entre deux messages. La rotation se met en pause au survol.
- **Fermeture** : bouton de fermeture optionnel ; la durée de vie du cookie (en heures) détermine quand la barre réapparaît.
- **Planification** : date de début et date de fin au format AAAA-MM-JJ, complétées automatiquement à 00:00:00 et 23:59:59.
- **Boutique** : en multiboutique, une barre peut être globale ou limitée à une boutique.
## Messages et compte à rebours
Depuis la liste des barres, l'action **Messages** ouvre les messages de la barre. Chaque message est **multilingue** et comprend :
- **Texte** : le contenu affiché. Insérez le placeholder `{countdown}` à l'endroit où le chronomètre doit apparaître.
- **Date d'échéance** : la cible du compte à rebours, affiché au format `Xj HH:MM:SS` et mis à jour chaque seconde (le libellé des jours est traduisible).
- **Masquer une fois expiré** : le message disparaît automatiquement à l'échéance, côté navigateur et côté serveur (aucun HTML mort n'est servi).
- **Bouton d'action** : libellé et URL optionnels, affiché en style pilule.
- **Ordre** : position du message dans la rotation.
Exemple : « Soldes d'été : -20 % avec le code HELLO10 — fin dans {countdown} ». Si tous les messages d'une barre expirent, la barre se retire d'elle-même.
## Ciblage
Chaque barre peut être restreinte par :
- **Langues** : la barre ne s'affiche que pour les langues sélectionnées.
- **Pays** : basé sur le pays du contexte PrestaShop ; la précision augmente si la géolocalisation IP est activée dans **Paramètres internationaux → Localisation**.
- **Groupes clients** : visiteurs, invités, clients ou tout groupe personnalisé (VIP, B2B…).
Un champ laissé vide signifie « tout le monde ». Les trois critères se cumulent.
## Dépannage
- **La barre ne s'affiche pas en haut de page** : votre thème ne déclare probablement pas displayBanner ; passez le hook d'accroche sur displayTop dans la configuration.
- **La barre ne s'affiche pas du tout** : vérifiez qu'elle est active, que la planification couvre la date du jour, que le ciblage correspond à votre profil de test, et qu'aucune barre de priorité inférieure n'occupe le même emplacement. Pensez aussi au cookie de fermeture : ouvrez une fenêtre de navigation privée.
- **Le compte à rebours n'apparaît pas** : assurez-vous que le message contient bien `{countdown}` et qu'une date d'échéance future est renseignée.
- **Deux barres apparaissent en haut** : le hook d'accroche a peut-être été modifié alors qu'un cache de page servait l'ancienne version ; videz le cache PrestaShop.
---
### Barre de livraison gratuite (dffreeshipbar) — Guide complet
_Source :_
> Guide complet du module dffreeshipbar pour PrestaShop 8 et 9 : installation, seuils par pays et par état, filtrage par transporteur, emplacements d'affichage, multi-boutique et dépannage. Toutes les règles de…
Guide complet du module **dffreeshipbar** pour PrestaShop 8 et 9 : installation, seuils par pays et par état, filtrage par transporteur, emplacements d'affichage, multi-boutique et dépannage. Toutes les règles de résolution sont détaillées avec les cas limites.
## Aperçu
dffreeshipbar affiche une barre de progression indiquant au client combien il lui reste à dépenser pour bénéficier de la livraison gratuite. Lorsque le seuil est atteint, le message bascule sur une confirmation.
Le module fonctionne avec **ses propres seuils**, stockés dans ses tables. Il n'interroge à aucun moment la variable native `PS_SHIPPING_FREE_PRICE` : vous pouvez la laisser à 0 et piloter votre franco de port par des tranches transporteur sans aucun conflit.
La particularité du module est sa **résolution territoriale à deux niveaux**. Un seuil peut être défini au niveau du pays, mais aussi au niveau de l'état PrestaShop — ce qui permet de traiter différemment des territoires rattachés administrativement à un même pays, comme les départements d'outre-mer rattachés à la France.
## Prérequis
- PrestaShop 8.0 à 9.x
- PHP 7.4 minimum (8.0 à 8.3 supportées)
- Thème Classic, Hummingbird ou thème personnalisé appelant les hooks standards
- Accès administrateur au back office
## Installation
1. Dans le back office, aller dans **Modules → Gestionnaire de modules → Envoyer un module**.
2. Uploader le fichier `dffreeshipbar-2.1.0.zip`.
3. Cliquer sur **Installer** puis **Configurer**.
À l'installation, le module crée deux tables et enregistre ses hooks :
- `PREFIX_dffreeshipbar_country` — seuils au niveau pays, avec une colonne `id_shop`.
- `PREFIX_dffreeshipbar_state` — seuils au niveau état, avec une colonne `id_shop`.
Hooks enregistrés : `displayHeader`, `displayBanner`, `displayNav2`, `displayNavFullWidth`, `displayShoppingCartFooter`, `displayCheckoutSummaryTop`, `actionCarrierUpdate`.
**Note.** Par défaut, le seuil global de repli est désactivé. Tant que vous n'avez configuré aucun territoire, la barre ne s'affiche nulle part. C'est volontaire : mieux vaut une barre absente qu'une barre qui promet un franco inexistant.
## Configuration générale
L'écran de configuration se trouve dans **Modules → DataFirefly - Barre de livraison gratuite → Configurer**. Il se compose de trois panneaux : paramètres généraux, règles transporteur, seuils par territoire.
### Seuil global de repli
Deux réglages liés :
- **Utiliser un seuil global par défaut** : quand ce switch est sur _Non_, la barre n'apparaît que dans les territoires configurés explicitement. Quand il est sur _Oui_, tout territoire non configuré reçoit le montant saisi ci-dessous.
- **Seuil global par défaut** : le montant appliqué en dernier recours.
Laissez le repli désactivé si votre franco ne couvre que quelques destinations. Activez-le si votre franco est universel et que les exceptions sont rares.
### Base de calcul
- **Comparer les totaux TTC** : détermine si le total du panier est évalué taxes comprises ou hors taxes. Ce réglage doit correspondre à la base utilisée par vos tranches transporteur, faute de quoi la barre et le tunnel de commande afficheront des résultats divergents.
- **Inclure les bons de réduction dans le total** : quand ce switch est actif, les remises panier sont déduites avant comparaison au seuil. Un panier de 70 € avec un bon de 10 € est alors évalué à 60 €.
Le total évalué correspond à un appel natif :
```
Cart::getOrderTotal(
$with_taxes = (bool) DFFREESHIPBAR_TAX_INCL,
$type = DFFREESHIPBAR_INCLUDE_DISCOUNTS
? Cart::BOTH_WITHOUT_SHIPPING
: Cart::ONLY_PRODUCTS
);
```
Les frais de port et l'emballage cadeau ne sont jamais comptés dans la progression.
### Exiger une adresse de livraison
Tant que le client n'a pas renseigné d'adresse, la destination n'est qu'une estimation et l'état reste inconnu. Trois modes :
- **Jamais** : la barre s'affiche dès la navigation catalogue, sur la base du pays estimé.
- **Pour les pays comportant des états** (recommandé) : la barre reste visible partout, sauf dans les pays dont les états peuvent porter des conditions différentes. Un visiteur estimé en Belgique voit la barre ; un visiteur estimé en France ne la voit qu'après saisie d'adresse, puisque son état déterminera le seuil réel.
- **Toujours** : rien tant qu'aucune adresse n'existe sur le panier.
**Astuce.** Le mode recommandé est le meilleur compromis : vous conservez l'effet incitatif sur la majorité de votre trafic, et vous ne prenez le risque d'une promesse erronée dans aucun pays à territoires.
### Emplacements et apparence
- **Afficher en haut de page** : bannière visible sur tout le site.
- **Afficher sur le panier et la commande** : bloc affiché au moment de la décision.
- **Activer l'animation** : rayures animées sur la barre en cours de progression. L'animation est automatiquement neutralisée pour les visiteurs ayant activé `prefers-reduced-motion`.
- **Quatre couleurs** : fond, barre, texte, message de réussite.
Pour un placement libre dans votre thème, le module implémente `WidgetInterface` :
```
{widget name='dffreeshipbar'}
{widget name='dffreeshipbar' position='cart'}
```
## Seuils par territoire
C'est le cœur du module. Le tableau liste tous les pays actifs de la boutique, et sous chaque pays comportant des états, ses états en retrait.
### Ordre de résolution
Pour une adresse de livraison donnée, le module cherche dans cet ordre et s'arrête au premier résultat :
1. **L'état** de l'adresse, si une règle existe pour lui.
2. **Le pays** de l'adresse, si une règle existe pour lui.
3. **Le seuil global de repli**, s'il est activé.
Si aucune de ces trois étapes ne produit de montant, la barre ne s'affiche pas.
### Case à cocher et champ montant : deux effets différents
C'est le point le plus important de la configuration, et le plus souvent mal compris :
- **Case décochée** → la barre est _masquée_ pour ce territoire. Il n'hérite ni du pays parent, ni du seuil global. La résolution s'arrête là.
- **Case cochée, montant vide** → la règle est supprimée, le territoire _hérite_ du niveau supérieur.
- **Case cochée, montant saisi** → ce montant s'applique.
**Attention.** Pour exclure un territoire de votre offre, décochez la case. Vider le montant produit l'effet inverse : le territoire héritera du seuil de son pays parent.
### Exemple : franco métropole uniquement
Cas courant d'une boutique française offrant le port à 65 € en métropole et en Corse, mais pas en outre-mer :
- **France** : case cochée, montant `65`.
- **Corse** : case cochée, montant vide — elle hérite des 65 € de la France.
- **Guadeloupe, Martinique, Guyane, Réunion, Mayotte** : cases _décochées_. Aucune barre sur ces destinations.
- **Seuil global de repli** : désactivé, pour qu'aucun autre pays ne reçoive de barre par accident.
Un client guadeloupéen ne verra donc jamais la promesse de franco, alors même que son adresse est rattachée au pays « France » dans PrestaShop.
### Filtre et recherche
Le champ de recherche filtre pays et états par nom. La case **Afficher uniquement les territoires configurés** réduit le tableau aux lignes ayant déjà une règle — utile sur une boutique ouverte à cent pays.
Les deux boutons d'enregistrement sont indépendants : **Enregistrer les pays** et **Enregistrer les états**.
## Règles transporteur
Si votre franco n'est accordé que par certains transporteurs, restreignez l'affichage en conséquence. Trois modes :
- **Tous les transporteurs** : aucun filtrage.
- **Afficher uniquement pour les transporteurs cochés** : liste blanche.
- **Masquer pour les transporteurs cochés** : liste noire.
**Note technique.** Les règles sont enregistrées sur l'`id_reference` du transporteur, pas sur son `id_carrier`. PrestaShop marque l'ancien transporteur comme supprimé et en crée un nouveau à chaque modification : une configuration basée sur l'ID serait perdue dès votre premier changement de tarif. La référence, elle, reste stable.
### Avant sélection du transporteur
Le transporteur n'est connu qu'à l'étape de livraison. Le réglage **Avant sélection du transporteur** décide de ce qui se passe avant ce moment :
- **Afficher** : la barre apparaît sur le catalogue et le panier, puis disparaît si le client choisit un transporteur exclu.
- **Masquer** : la barre n'apparaît qu'une fois un transporteur éligible sélectionné.
## Mise à jour en temps réel
La barre est recalculée côté serveur et rafraîchie sans rechargement de page à chaque événement panier : ajout, suppression, changement de quantité, modification d'adresse, changement d'étape du tunnel.
Le script écoute les événements PrestaShop `updatedCart`, `updateCart`, `updatedAddressForm`, `changedCheckoutStep` et `updateDeliveryForm`. Vous pouvez déclencher un rafraîchissement manuel depuis votre propre code :
```
document.dispatchEvent(new Event('dffreeshipbar:refresh'));
```
C'est le serveur qui décide de la visibilité : si le territoire ou le transporteur ne qualifie plus, la barre est retirée du DOM plutôt que laissée avec une valeur périmée.
## Multi-boutique
Les seuils sont stockés avec une colonne `id_shop`. Chaque boutique possède donc ses propres règles pays et états, indépendantes les unes des autres.
Pour configurer une boutique donnée, sélectionnez son contexte en haut du back office avant d'ouvrir l'écran de configuration. Le panneau des seuils affiche le nom de la boutique courante en rappel.
## Traductions
Le module est livré traduit en français, anglais, allemand, espagnol, italien et polonais.
Pour adapter les textes affichés côté client, aller dans **International → Traductions**, sélectionner « Traductions du module », choisir _dffreeshipbar_ et la langue, puis chercher le domaine `Modules.Dffreeshipbar.Shop`. Les chaînes disponibles :
- _« Plus que %amount% pour bénéficier de la livraison gratuite ! »_ — panier en cours.
- _« Livraison gratuite dès %amount%. »_ — panier vide.
- _« Félicitations ! Votre commande bénéficie de la livraison gratuite. »_ — seuil atteint.
Le jeton `%amount%` est remplacé par le montant formaté selon la devise et la locale actives. Conservez-le dans vos traductions.
## Mise à jour depuis la version 1.0
La mise à jour est automatique au remplacement du ZIP. Les scripts d'upgrade effectuent les opérations suivantes :
- Création de la table des états.
- Renommage de la colonne `active` en `enabled` sur la table des pays. Vos seuils existants sont conservés.
- Le seuil global de repli est activé si vous en aviez un en 1.0, pour ne pas modifier ce que voient vos clients.
- Le mode d'exigence d'adresse est positionné sur _Jamais_, qui correspond au comportement de la version 1.0. Passez-le sur le mode recommandé quand vous le décidez.
## Dépannage
### La barre ne s'affiche nulle part
1. Le module est-il activé ? (switch _Activer le module_).
2. Avez-vous configuré au moins un territoire, ou activé le seuil global de repli ? Sans l'un ou l'autre, la barre ne s'affiche jamais.
3. Le mode d'exigence d'adresse est-il sur _Toujours_ alors que vous testez sans adresse de livraison ?
4. Les emplacements sont-ils activés ? (bannière et/ou panier).
5. Votre thème appelle-t-il les hooks utilisés ? Vérifier dans **Modules → Positions**. En thème personnalisé, utiliser plutôt le widget.
### La barre s'affiche là où elle ne devrait pas
Le cas typique est un territoire qui hérite alors qu'il devrait être exclu. Vérifier que la case du territoire est bien _décochée_, et non simplement que son montant a été vidé — les deux actions ont des effets opposés.
### Le seuil affiché ne correspond pas au checkout
- Vérifier que le réglage _Comparer les totaux TTC_ correspond à la base de vos tranches transporteur.
- Vérifier le réglage des bons de réduction : un panier remisé peut passer sous le seuil.
- Le module ne lit pas vos tranches transporteur. Si vous avez modifié une tranche, reportez la nouvelle valeur dans le module.
### La barre ne se met pas à jour après un ajout au panier
Le rafraîchissement s'appuie sur les événements JavaScript de PrestaShop. Certains thèmes ou modules de panier tiers ne les émettent pas. Deux vérifications :
- La console navigateur signale-t-elle une erreur JavaScript sur une autre ressource ? Une erreur bloquante en amont empêche l'écoute de s'installer.
- Votre module de panier ajax émet-il bien `prestashop.emit('updatedCart')` ? Sinon, déclenchez `dffreeshipbar:refresh` depuis votre code.
### Les règles transporteur semblent ignorées
Vérifier que le transporteur sélectionné est bien celui que vous croyez : après une modification de tarif, PrestaShop crée un nouveau transporteur. Le module suit la référence, donc la règle devrait suivre — mais si le transporteur a été _recréé de zéro_ plutôt que modifié, sa référence est nouvelle et il faut le recocher.
## Désinstallation
Aller dans **Modules → Gestionnaire de modules → DataFirefly - Barre de livraison gratuite → Désinstaller**. La désinstallation supprime les deux tables de seuils et toutes les clés de configuration préfixées `DFFREESHIPBAR_`.
**Attention.** Vos seuils par pays et par état sont définitivement perdus. Si vous prévoyez de réinstaller, exportez les deux tables au préalable.
## FAQ rapide
- **Le module lit-il PS_SHIPPING_FREE_PRICE ?** Non, jamais. Vous pouvez la laisser à 0 et gérer votre franco par tranches transporteur.
- **Le module lit-il mes tranches transporteur pour en déduire le seuil ?** Non. Les seuils sont saisis manuellement. Une synchronisation automatique depuis les tranches est possible en développement spécifique.
- **Mon franco dépend aussi du poids. Est-ce géré ?** Non, le module ne mesure qu'un montant. Une condition de poids relève d'un développement spécifique.
- **Puis-je afficher la barre ailleurs que dans les emplacements proposés ?** Oui, via `{widget name='dffreeshipbar'}` dans n'importe quel template.
- **Le module fonctionne-t-il avec le thème Hummingbird ?** Oui. Les hooks `displayNavFullWidth` et `displayCheckoutSummaryTop` sont enregistrés pour lui, et le widget couvre les placements personnalisés.
- **Les seuils sont-ils indépendants par boutique ?** Oui, chaque ligne porte un `id_shop`.
## Support et mises à jour
Le module inclut **12 mois de mises à jour et de support** à partir de la date d'achat. Support par email en français ou en anglais, réponse sous 24 heures ouvrées.
Pour toute question ou anomalie, contacter [le support DataFirefly](https://www.datafirefly.com/contact/) en précisant :
- Version de PrestaShop et de PHP
- Version du module installée
- Thème utilisé
- Territoire et transporteur concernés par le comportement observé
- Description du comportement observé vs attendu
---
### Billetterie & Événements — Guide complet
_Source :_
> Présentation DataFirefly Billetterie & Événements transforme n'importe quel produit PrestaShop en billet d'événement. Le module gère deux types d'événements (placement libre ou places assises), un plan de salle visuel, la…
## Présentation
DataFirefly Billetterie & Événements transforme n'importe quel produit PrestaShop en billet d'événement. Le module gère deux types d'événements (placement libre ou places assises), un plan de salle visuel, la génération de billets QR téléchargeables en PDF et un écran de contrôle d'entrée par scan. La particularité de l'approche : chaque **catégorie de place est une déclinaison produit**, ce qui laisse PrestaShop gérer nativement les prix, les taxes et la facturation.
Aucune dépendance externe : la génération des QR et des PDF est embarquée dans le module. Aucun Composer n'est requis, et le module est compatible PrestaShop 8 comme 9, en multiboutique.
## Installation
1. Téléchargez l'archive `dfeventtickets.zip` depuis votre compte DataFirefly.
2. Dans le back-office, allez dans **Modules > Module Manager**, cliquez sur **Téléverser un module** et déposez le ZIP.
3. Le module s'installe automatiquement : il crée ses tables, ses onglets de menu (sous **Clients > DataFirefly Billetterie**) et enregistre ses hooks.
4. Videz le cache PrestaShop (**Paramètres avancés > Performances > Vider le cache**) après l'installation.
En cas de mise à jour, écrasez les fichiers puis videz le cache pour purger l'index de classes de PrestaShop.
## Concepts clés
### Produit = billet
Vous créez d'abord un produit PrestaShop standard (le « billet »), puis vous lui associez un _événement_. Tout ce qui touche au prix, à la TVA et à la facture reste géré par PrestaShop.
### Zone de prix = déclinaison
Chaque zone (Carré Or, Balcon, Fosse…) pointe vers une **combinaison** du produit (`id_product_attribute`) ou vers le prix de base. C'est ce qui garantit des totaux et des factures corrects, sans calcul parallèle.
### Deux types d'événement
- **Placement libre** (`general`) : le client choisit une catégorie et une quantité via le bloc d'achat natif.
- **Places assises** (`seated`) : le client choisit sa place sur un plan de salle interactif.
## Créer un événement
Rendez-vous dans **Clients > DataFirefly Billetterie > Événements** puis cliquez sur **Ajouter un événement**. Renseignez :
- le **produit** associé ;
- le **type** (placement libre ou places assises) ;
- les **dates** de début et de fin (format `AAAA-MM-JJ HH:MM:SS`) et le fuseau ;
- la **capacité** (pour le placement libre) ;
- la **durée de réservation** (minutes pendant lesquelles un siège sélectionné reste bloqué, 15 par défaut) ;
- le statut **actif**.
Vous pouvez aussi accéder à la création/édition d'événement directement depuis l'onglet **Billetterie & Événement** de la fiche produit.
## Définir les zones de prix
Une fois l'événement enregistré, le panneau **Zones de prix** apparaît sous le formulaire. Pour chaque zone, indiquez un nom, la déclinaison produit correspondante (ou le prix de base) et une couleur d'affichage. Le prix réel est lu depuis la déclinaison PrestaShop.
Créez au moins une zone avant de dessiner le plan de salle : chaque siège doit être rattaché à une zone.
## Dessiner le plan de salle
Pour les événements en places assises, ouvrez **Dessiner le plan de salle**. L'éditeur visuel permet de :
- **générer un bloc** de sièges (rangées × colonnes, première rangée et premier numéro paramétrables) rattaché à une zone ;
- **repositionner** un siège au glisser-déposer ;
- **activer/désactiver** un siège (clic) — un siège désactivé n'est pas vendu ;
- **supprimer** un siège (double-clic) ;
- **tout effacer** pour recommencer.
La barre « SCÈNE / ENTRÉE » sert de repère d'orientation pour vos clients.
## Côté boutique : acheter un billet
Sur la fiche produit, le module injecte automatiquement le bon widget :
- **Places assises** : un plan interactif où les zones sont colorées, les places occupées grisées et les places disponibles cliquables. Le client sélectionne une ou plusieurs places ; chaque sélection ajoute la déclinaison correspondante au panier et réserve le siège temporairement.
- **Placement libre** : un encart de disponibilité ; l'achat se fait via le bloc quantité natif.
Si une place vient d'être prise par un autre client, le plan se rafraîchit et invite à en choisir une autre — pas de double vente.
## Billets QR & PDF
Dès que la commande est validée et payée, le module génère un billet par place réellement payée, chacun portant un **jeton aléatoire unique** encodé en QR. Le client télécharge ses billets en PDF (un billet par page) depuis le détail de la commande ou son espace client. Si TCPDF n'est pas disponible, un repli HTML imprimable est proposé.
## Contrôle d'entrée (scan)
Le jour J, ouvrez **Clients > DataFirefly Billetterie > Scan**. Deux modes :
- **Caméra** : démarrez la caméra et présentez le QR du billet ;
- **Saisie manuelle** : collez ou saisissez le code du billet.
Le résultat s'affiche en couleur (valide, déjà utilisé, annulé, invalide) et un journal des derniers scans aide le personnel d'accueil. Un billet validé passe en **utilisé** et ne peut plus être réutilisé.
## Cycle de vie d'un billet
- **reserved** : siège sélectionné, bloqué jusqu'à expiration de la réservation ;
- **valid** : commande payée et réconciliée (seules les places réellement payées deviennent valides) ;
- **used** : billet scanné à l'entrée ;
- **cancelled** : commande annulée ou remboursée ;
- **expired** : réservation non confirmée arrivée à expiration.
## Gestion des billets en back-office
L'onglet **Billets** liste tous les billets avec leur événement, place, client, commande, statut et date d'émission. La liste est filtrable et permet l'**annulation groupée**. Un filtre par événement est disponible depuis le panneau zones.
## Compatibilité & aspects techniques
- PrestaShop 8.0 à 9.x, multiboutique, multilingue (FR, EN, ES, DE, IT) ;
- PHP 7.4 à 8.3 ;
- contrôleurs `ModuleAdminController` (compatibilité PS8/9, sans contrôleurs Symfony) ;
- QR (bibliothèque MIT) et PDF (TCPDF natif) embarqués, aucune dépendance Composer.
## Dépannage
### Le widget de sélection n'apparaît pas sur la fiche produit
Vérifiez que l'événement est **actif**, associé au bon produit, et que le module est bien greffé sur les hooks de la fiche produit. Videz le cache.
### Une page blanche apparaît après l'installation ou la mise à jour
Videz le cache PrestaShop pour reconstruire l'index de classes, puis rechargez l'écran.
### La caméra ne démarre pas sur l'écran de scan
Le scan caméra nécessite un contexte sécurisé (HTTPS) et l'autorisation d'accès à la caméra. À défaut, utilisez la saisie manuelle du code.
### Les prix ou taxes semblent incorrects
Assurez-vous que chaque zone pointe vers la bonne déclinaison produit : c'est PrestaShop qui calcule prix et TVA à partir de cette combinaison.
---
### Blocs de Réassurance & Badges de Confiance — Guide complet
_Source :_
> Présentation Le module Blocs de Réassurance & Badges de Confiance (dftrustbuilder) permet de créer des blocs de réassurance à partir d'une bibliothèque de 18 icônes SVG intégrées, de les positionner…
## Présentation
Le module Blocs de Réassurance & Badges de Confiance (`dftrustbuilder`) permet de créer des blocs de réassurance à partir d'une bibliothèque de 18 icônes SVG intégrées, de les positionner sur 6 zones du front-office par glisser-déposer, et de gérer des variantes par langue. Compatible PrestaShop 8.0 à 9.x, multiboutique et multilingue.
À l'installation, 4 blocs d'exemple (paiement sécurisé, livraison rapide, retours faciles, conçu en Europe) sont créés en 5 langues sur la zone de réassurance produit. Votre boutique est habillée immédiatement.
## Installation
1. Dans le back-office, allez dans **Modules > Gestionnaire de modules > Installer un module**.
2. Téléversez le fichier `dftrustbuilder-1.0.0.zip` puis cliquez sur **Installer**.
3. Cliquez sur **Configurer** pour accéder aux réglages d'affichage et à la gestion des blocs.
Aucune modification du thème n'est nécessaire : le module s'appuie sur les hooks standards du front-office.
## Réglages d'affichage
La page de configuration du module regroupe les réglages globaux appliqués à tous les blocs :
- **Style** : minimal (sans cadre), encadré (bordure fine), ou carte (fond blanc avec ombre portée).
- **Colonnes** : auto (adaptatif selon la largeur disponible), 2, 3, 4 ou 6.
- **Alignement** : icône à gauche du texte, ou centré avec l'icône au-dessus.
- **Taille des icônes** : de 12 à 128 pixels (32 px par défaut).
- **Couleur des icônes** : laissez vide pour hériter de la couleur de texte du thème.
- **Une colonne sur mobile** : force l'empilement vertical sur les écrans étroits.
## Gérer les blocs
Cliquez sur **Gérer les blocs de réassurance** depuis la page de configuration pour ouvrir la liste des blocs.
### Créer un bloc
1. Cliquez sur **Ajouter un bloc**.
2. Choisissez une icône dans la grille : paiement sécurisé, carte bancaire, camion de livraison, horloge 24 h, colis, retours, garantie, made in EU, made in France, support, téléphone, chat, cadeau, avis, éco-responsable, monde, satisfaction, promotions.
3. Sélectionnez le **hook d'affichage** (voir ci-dessous).
4. Renseignez le titre et le sous-titre dans chaque langue.
5. Optionnel : ajoutez une URL par langue pour rendre le bloc entièrement cliquable, par exemple vers votre page CMS de livraison.
6. Enregistrez. Le bloc est ajouté en dernière position.
### Zones d'affichage disponibles
- **Réassurance produit** (displayReassurance) : sous le bouton d'achat de la fiche produit — la zone recommandée.
- **Page d'accueil** (displayHome).
- **Sous le header, pleine largeur** (displayNavFullWidth).
- **Au-dessus du footer** (displayFooterBefore) : visible sur tout le site.
- **Infos complémentaires produit** (displayProductAdditionalInfo).
- **Bas du panier** (displayShoppingCartFooter).
### Réordonner par glisser-déposer
Dans la liste des blocs, saisissez les flèches de la colonne **Position** et faites glisser la ligne. L'ordre est enregistré automatiquement.
Utilisez le filtre **Hook** en haut de la colonne pour n'afficher que les blocs d'une zone et réordonner cet emplacement précisément.
## Variantes par langue
Chaque bloc porte un titre, un sous-titre et un lien **par langue**. Deux usages :
- **Traduction** : renseignez simplement les textes dans chaque onglet de langue.
- **Visibilité par langue** : laissez le titre **vide** dans une langue pour masquer le bloc uniquement pour cette langue. Exemple : un badge « Fabriqué en France » avec l'icône hexagone visible seulement en français, et un badge « Made in EU » pour les autres langues.
Le titre est obligatoire uniquement dans la langue par défaut de la boutique. Toutes les autres langues peuvent rester vides.
## Multiboutique
En contexte multiboutique, chaque bloc peut être associé à une ou plusieurs boutiques via l'encart **Association de boutique** du formulaire. Les réglages d'affichage (style, colonnes, couleurs) suivent le contexte de configuration de PrestaShop.
## Dépannage
- **Les blocs ne s'affichent pas** : vérifiez que le bloc est actif, que son hook correspond à une zone réellement rendue par votre thème, et que le titre est renseigné dans la langue consultée.
- **La zone Réassurance n'apparaît pas sur la fiche produit** : certains thèmes personnalisés n'appellent pas displayReassurance. Utilisez alors displayProductAdditionalInfo ou displayFooterBefore.
- **Les icônes sont invisibles ou de la mauvaise couleur** : par défaut elles héritent de la couleur du texte. Définissez une couleur explicite dans la configuration si votre thème utilise un texte très clair.
- **Le glisser-déposer ne fonctionne pas** : assurez-vous que la liste est triée par la colonne Position (tri par défaut).
---
### Bouton Vider le panier — Guide complet
_Source :_
> Présentation Le module Bouton Vider le panier (dfclearcart) ajoute sur la page panier de votre boutique un bouton « Vider le panier » qui supprime en un seul clic l'intégralité…
## Présentation
Le module **Bouton Vider le panier** (`dfclearcart`) ajoute sur la page panier de votre boutique un bouton **« Vider le panier »** qui supprime en un seul clic l'intégralité du panier : tous les produits, leurs déclinaisons et personnalisations, ainsi que les bons de réduction appliqués. Le module est entièrement autonome : aucune dépendance Composer, aucune table SQL ajoutée.
Le bouton est injecté en JavaScript via un hook toujours présent, puis placé dans le bloc panier. Il s'affiche donc même sur les thèmes personnalisés qui ne déclenchent pas les hooks d'affichage habituels de la page panier.
## Compatibilité
- PrestaShop 8.0 à 9.x
- Mono-boutique et multi-boutique
- 5 langues : FR, EN, ES, DE, IT
- Thème Classic et thèmes personnalisés
- Aucune dépendance (ni Composer ni framework)
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** puis sélectionnez le fichier `dfclearcart.zip`.
3. Une fois installé, cliquez sur **Configurer**.
À l'installation, le module enregistre ses hooks (chargement des ressources sur le front et bouton sur la page panier) et crée ses réglages par défaut : bouton activé, confirmation activée, libellés dans les cinq langues.
## Configuration
- **Activer le bouton** : affiche ou masque le bouton « Vider le panier » sur la page panier.
- **Demander confirmation** : affiche une fenêtre de confirmation avant le vidage, pour éviter les clics accidentels.
- **Libellé du bouton** : texte affiché sur le bouton, personnalisable et traduisible dans chaque langue.
- **Message de confirmation** : texte de la demande de confirmation, personnalisable et traduisible dans chaque langue.
Les libellés sont des champs multilingues : sélectionnez chaque langue dans le sélecteur du champ pour adapter le texte. Les valeurs par défaut sont fournies dans les cinq langues dès l'installation.
## Fonctionnement
### Ce qui est supprimé
Au clic (et après confirmation si elle est activée), le module supprime **tous les produits** du panier — y compris leurs déclinaisons et personnalisations — puis retire **tous les bons de réduction et règles panier** appliqués. Le panier revient à un état totalement vide.
### Rechargement automatique
Une fois le panier vidé, la page panier est rechargée automatiquement pour afficher l'état vide, sans intervention du client.
### Injection indépendante du thème
Les ressources (script et style) sont chargées via le hook `actionFrontControllerSetMedia`, toujours appelé. Le script repère ensuite le bloc panier et y insère le bouton. Cette approche garantit l'affichage du bouton même lorsque le thème ne déclenche pas les hooks d'affichage classiques de la page panier.
Si le thème déclenche le hook `displayShoppingCartFooter`, le bouton y est rendu directement et le script s'y rattache sans créer de doublon.
### Sécurité
Le vidage s'effectue via une requête AJAX protégée par un jeton lié au panier courant, et ne porte que sur le panier de la session en cours. Aucune autre session ni aucun autre panier n'est affecté.
## FAQ et dépannage
### Le bouton n'apparaît pas sur la page panier
Videz le cache de PrestaShop (Paramètres avancés > Performances) et, pendant vos tests, désactivez la combinaison/compression (CCC) et forcez la recompilation des templates. Rechargez ensuite la page panier en navigation privée. Le bouton ne s'affiche que lorsque le panier contient au moins un article.
### Mon thème personnalisé n'affiche toujours pas le bouton
Le bouton est inséré dans le premier conteneur panier reconnu. Si votre thème utilise une structure très spécifique, ouvrez la console du navigateur : si l'objet `dfClearCart` est défini, les ressources sont bien chargées et seul le sélecteur d'insertion doit être adapté à votre bloc panier.
### Le panier ne se vide qu'après un rafraîchissement manuel
Assurez-vous d'utiliser la dernière version du module : le rechargement de la page panier est déclenché automatiquement après le vidage.
### Est-ce compatible PrestaShop 9 ?
Oui. Le module est compatible PrestaShop 8 et 9, en multi-boutique et multilingue, sans méthode dépréciée.
---
### Boutons +/- de Quantité — Guide complet
_Source :_
> Présentation Le module Boutons +/- de Quantité ajoute de vrais boutons + et − de chaque côté du champ quantité, sur la fiche produit. Il remplace l'usage du petit champ…
## Présentation
Le module Boutons +/- de Quantité ajoute de vrais boutons **+** et **−** de chaque côté du champ quantité, sur la fiche produit. Il remplace l'usage du petit champ nombre natif de PrestaShop, peu pratique au clavier comme au doigt sur mobile, par deux larges boutons faciles à viser.
Le module ne modifie aucun fichier de thème : il ajoute une feuille de style et un script légers, uniquement sur la fiche produit, qui encapsulent le champ quantité existant. Il est compatible PrestaShop 1.7, 8 et 9, avec le thème Classic comme avec la plupart des thèmes personnalisés.
## Installation
1. Depuis le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez l'archive ZIP du module.
3. Une fois l'installation terminée, cliquez sur **Configurer** (facultatif : le module fonctionne avec ses réglages par défaut dès l'installation).
Aucune table SQL n'est créée et aucun fichier de thème n'est modifié. Le module enregistre simplement le hook qui charge ses ressources sur la fiche produit.
## Configuration
La page de configuration regroupe quatre réglages. Tous sont optionnels : par défaut, les boutons sont actifs, en style carré, avec masquage des flèches natives.
### Activer les boutons
L'interrupteur **Activer les boutons** contrôle l'affichage global. Désactivez-le pour masquer temporairement les boutons sans désinstaller le module : la fiche produit retrouve alors le champ quantité d'origine.
### Style des boutons
Choisissez l'apparence des boutons :
- **Carré** : les boutons + et − ont des coins légèrement arrondis aux extrémités du groupe (style par défaut).
- **Arrondi** : les boutons adoptent une forme en pilule, avec des extrémités complètement arrondies.
### Couleur de fond et couleur des icônes
Deux sélecteurs de couleur permettent d'ajuster :
- la **couleur de fond** des boutons (par défaut un gris clair) ;
- la **couleur des icônes** + et − (par défaut un gris foncé).
L'effet au survol est dérivé automatiquement de la couleur de fond : il n'y a donc pas de troisième réglage à gérer. Les couleurs sont appliquées au moyen de variables CSS, ce qui garantit une intégration propre dans la plupart des thèmes.
### Masquer les flèches natives du champ nombre
Lorsque cette option est activée (recommandé), les petites flèches verticales du champ nombre du navigateur sont masquées, pour ne conserver que les boutons + et − du module. Désactivez-la si vous préférez laisser les flèches natives visibles.
## Côté client
Sur la fiche produit, le client voit un bouton − à gauche du champ quantité et un bouton + à droite. Chaque clic incrémente ou décrémente la quantité d'un pas, puis met à jour le prix, les éventuelles déclinaisons et le bouton d'ajout au panier, exactement comme une saisie manuelle. La quantité reste bien sûr modifiable directement au clavier dans le champ.
## Fonctionnement et compatibilité
### Aucun override de template
Le module n'écrase aucun fichier de thème. Il repère le champ quantité standard de la fiche produit et l'encapsule par injection JavaScript pour y ajouter les boutons. Cette approche le rend compatible avec un large éventail de thèmes et le préserve des mises à jour de PrestaShop, puisqu'aucun template n'est surchargé.
### Thème Classic et bootstrap-touchspin
Le thème Classic enrichit déjà le champ quantité avec bootstrap-touchspin, qui ajoute deux petites flèches verticales. Le module neutralise proprement ces flèches à l'intérieur de son propre groupe de boutons, afin de ne laisser que les + et − bien lisibles, sans doublon ni décalage de mise en page.
### Synchronisation avec le panier
À chaque clic, le module applique la nouvelle valeur puis déclenche les événements attendus par PrestaShop, à la fois natifs et jQuery. Le prix total, les déclinaisons et le bouton d'ajout au panier réagissent normalement. Après un changement de déclinaison, qui reconstruit le bloc quantité, les boutons sont automatiquement réinjectés.
### Respect du stock et des contraintes
Les boutons lisent la quantité minimale, la quantité maximale et le pas définis sur le champ. Le client ne peut pas descendre sous le minimum requis (souvent 1) ni dépasser le stock disponible lorsque celui-ci est borné. Le comportement reste cohérent avec les règles de la boutique.
## Dépannage
### Les boutons n'apparaissent pas sur la fiche produit
Vérifiez que le module est activé et que l'option **Activer les boutons** est bien sur Oui. Videz ensuite le cache de PrestaShop (Paramètres avancés > Performances) et rechargez la fiche produit. Si votre thème utilise un champ quantité fortement personnalisé, le module peut ne pas le détecter ; contactez le support en précisant votre thème.
### Les flèches natives du thème Classic restent visibles
Assurez-vous d'utiliser la version 1.1.0 ou supérieure, qui neutralise les flèches bootstrap-touchspin, puis videz le cache. Vérifiez également qu'aucune surcharge CSS de votre thème ne réaffiche ces flèches.
### La quantité change mais le prix ne se met pas à jour
Ce comportement vient généralement d'un thème qui n'utilise pas les événements standard de PrestaShop. Le module déclenche les événements natifs et jQuery ; si le thème écoute un mécanisme différent, contactez le support en indiquant le thème utilisé.
## Désinstallation
La désinstallation du module retire ses ressources de la fiche produit et supprime sa configuration. Le champ quantité retrouve son apparence d'origine. Aucune donnée produit ni commande n'est affectée.
## FAQ
### Le module modifie-t-il mon thème ?
Non. Il n'écrase aucun fichier de thème : il ajoute une feuille de style et un script uniquement sur la fiche produit, qui encapsulent le champ quantité existant.
### Puis-je changer la couleur des boutons ?
Oui. La configuration permet de régler la couleur de fond et la couleur des icônes + et −, ainsi que le style carré ou arrondi. L'effet de survol est dérivé automatiquement de la couleur de fond.
### Le module est-il compatible PrestaShop 9 ?
Oui, le module est compatible PrestaShop 1.7, 8.x et 9.x, en mono comme en multi-boutique.
---
### Box Builder (Mix & Match) — Guide complet
_Source :_
> Présentation Le module Box Builder (Mix & Match) (dfboxbuilder) ajoute une page où vos clients composent leur propre coffret à partir d'une sélection de produits que vous avez choisie. Ils…
## Présentation
Le module **Box Builder (Mix & Match)** (`dfboxbuilder`) ajoute une page où vos clients **composent leur propre coffret** à partir d'une sélection de produits que vous avez choisie. Ils piochent les articles dans une grille, suivent une **barre de progression**, voient le **prix se mettre à jour en direct**, puis ajoutent le coffret complet au panier en un clic. Idéal pour les coffrets gourmands, box beauté, paniers garnis, packs « 3 produits achetés », abonnements découverte, etc.
Vous créez autant de coffrets que vous voulez, chacun avec ses propres produits, ses règles (minimum / maximum d'articles) et son **modèle de tarification**. Un même catalogue peut alimenter plusieurs coffrets très différents.
## Compatibilité
- PrestaShop 1.7.6 à 8.x et 9.x
- PHP 7.4 à 8.x
- Mono-boutique et multi-boutique
- 5 langues : FR, EN, ES, DE, IT (100 % traduit, sans repli)
- Thème Classic et thèmes personnalisés (compositeur en JavaScript natif, sans dépendance jQuery)
- Aucune dépendance (ni Composer ni framework)
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** puis sélectionnez le fichier `dfboxbuilder.zip`.
3. Une fois installé, ouvrez l'onglet **Box Builder** ajouté au menu pour créer votre premier coffret.
À l'installation, le module crée ses tables, enregistre ses hooks (`displayHeader`, `actionFrontControllerSetMedia`, `displayHome` et `actionValidateOrder`) et ajoute un onglet d'administration **Box Builder**. À la première sauvegarde d'un coffret, un **produit conteneur caché** est généré automatiquement : il porte la ligne du coffret dans le panier et n'est pas visible dans le catalogue.
## Configuration d'un coffret
Le formulaire d'édition d'un coffret est organisé en cinq onglets.
### Onglet Général
- **Nom, description, libellé du bouton** : traduisibles dans les 5 langues.
- **Articles min / max** : bornes de la composition. Le maximum pilote la cible de la barre de progression.
- **Autoriser les doublons** et **unités max par article** : permettent (ou non) d'ajouter plusieurs fois le même produit, avec un plafond par produit.
- **Masquer les produits en rupture** : retire de la grille les produits indisponibles (en tenant compte du réglage de rupture de chaque produit).
- **Activer « Surprenez-moi »** et **Activer l'enregistrement & partage** : affichent ou masquent ces actions côté client.
- **Actif** : publie ou non le coffret.
### Onglet Tarification
Quatre modèles de prix sont disponibles :
- **Prix fixe** : un prix unique pour le coffret, quel que soit son contenu.
- **Paliers de volume** : le prix change selon le nombre d'articles (ex. 3 articles = 25 €, 6 articles = 45 €). Vous définissez autant de paliers « à partir de X articles » que nécessaire.
- **Somme des produits avec remise** : le prix est la somme des produits composant le coffret, moins un pourcentage de remise.
- **Prix par emplacement** : chaque emplacement (slot) contribue un prix unitaire fixe ; le total dépend des emplacements remplis.
Cet onglet pilote aussi la **gamification** : **cadeau offert quand le coffret est complet** (choix du produit offert, ajouté gratuitement au panier) et **livraison offerte à la complétion**.
Le prix de base / fixe se saisit **hors taxe**. Le module applique ensuite la taxe du produit conteneur et affiche le prix toutes taxes comprises au client.
### Onglet Composition (sources & emplacements)
Vous définissez les **produits éligibles** qui apparaîtront dans la grille du compositeur, via deux types de sources :
- **Produits** : ajoutés un par un grâce à une **recherche avec autocomplétion**.
- **Catégories** : tous les produits actifs de la catégorie deviennent éligibles.
L'option **Utiliser des emplacements par catégorie** active une composition « par étapes ». Chaque emplacement possède son propre nom, ses bornes **min / max**, son éventuel **prix d'emplacement** et ses **propres sources**. Vous pouvez ainsi exiger par exemple « 2 plats + 3 accompagnements + 1 dessert ». Sans emplacements, le client puise librement dans la liste globale.
### Onglet Modèles (coffrets pré-composés)
Vous proposez des **coffrets « prêts à l'emploi »** que le client choisit d'un clic, puis ajuste à sa guise. Chaque modèle a un nom, une description et une liste de produits (ajoutés par recherche avec autocomplétion). Idéal pour guider le client indécis ou mettre en avant un assortiment best-seller.
### Onglet Contraintes
Vous déclarez des **paires de produits incompatibles** qui ne peuvent pas figurer ensemble dans le même coffret. Le compositeur empêche alors leur sélection conjointe et la validation serveur la refuse.
## Utilisation côté client
### Le compositeur interactif
La page de composition affiche la grille des produits (image, nom, alerte « stock faible » le cas échéant) et un **panneau récapitulatif collant** : barre de progression, liste des articles choisis, **prix calculé en direct** (appel AJAX optimisé) et messages de validation. Le bouton d'ajout au panier ne s'active que lorsque la composition respecte toutes les règles.
### Emplacements catégoriels
Quand les emplacements sont activés, des **onglets** guident le client d'un emplacement à l'autre, chacun affichant son compteur (par exemple « Plats 2/3 ») et sa propre sélection de produits.
### Surprenez-moi
Le bouton **Surprenez-moi** remplit automatiquement le coffret avec des produits éligibles, en respectant le maximum d'articles, les bornes de chaque emplacement et les incompatibilités. Le client peut ensuite ajuster la sélection proposée.
### Enregistrer & partager
Le client peut **enregistrer sa composition** et obtenir un **lien de partage**. Toute personne ouvrant ce lien retrouve le coffret pré-rempli, prêt à être ajusté et commandé.
### Ajout au panier et commande
À l'ajout au panier, la **composition est enregistrée comme personnalisation** de la ligne (et reste visible dans le panier puis sur la commande), et le **prix calculé du coffret** est appliqué. Si la gamification est activée, le **cadeau** est ajouté gratuitement. À la validation de la commande, le module **décrémente le stock de chaque produit composant** le coffret et enregistre la vente pour les statistiques.
## Statistiques (back-office)
L'onglet **Statistiques** agrège les coffrets commandés : chiffre d'affaires, nombre de commandes, nombre moyen d'articles par coffret, performance **par coffret** et **combinaisons les plus populaires**. De quoi identifier vos assortiments gagnants et affiner vos sources.
## Affichage en page d'accueil (optionnel)
Un bloc d'accueil facultatif liste vos coffrets actifs avec un lien direct vers leur compositeur. La page d'un coffret est également accessible directement via son adresse : `index.php?fc=module&module=dfboxbuilder&controller=builder&id_dfbox=ID`. Vous pouvez créer un lien depuis votre menu, une page CMS ou une bannière.
## Fonctionnement technique
Pour chaque coffret, un **produit conteneur caché** (visibilité « nulle part », non navigable) porte la ligne dans le panier. Le prix du coffret est appliqué via un **prix spécifique limité au panier** du client, de sorte que le prix catalogue du conteneur n'est jamais montré. La composition est stockée en personnalisation, et le stock des composants est décrémenté à la validation de la commande.
En modèle **Somme avec remise**, si un client ajoute deux coffrets du **même** coffret avec des compositions de prix différents, le dernier prix calculé s'applique aux deux lignes (le prix spécifique est porté par le produit conteneur). En prix **fixe**, **par paliers** ou **par emplacement** à nombre d'articles égal, il n'y a aucun impact.
La suppression d'un coffret ne supprime pas automatiquement son produit conteneur caché (v1). Si vous supprimez un coffret de test, vous pouvez retirer manuellement le produit conteneur associé depuis le catalogue.
## FAQ et dépannage
### Le compositeur ne s'affiche pas ou les boutons ne réagissent pas
Videz le cache de PrestaShop (Paramètres avancés > Performances) et, pendant vos tests, désactivez la combinaison/compression des fichiers (CCC). Assurez-vous que le coffret est **actif** et qu'il possède au moins une source de produits.
### La grille est vide
Vérifiez que les sources (produits ou catégories) contiennent des produits **actifs** pour la boutique courante. Si « Masquer les produits en rupture » est activé, les produits indisponibles n'apparaissent pas.
### Le prix affiché ne correspond pas à mes attentes
Contrôlez le modèle de tarification choisi : le prix fixe ignore le contenu, les paliers dépendent du nombre d'articles, la somme avec remise dépend du prix des produits, et le prix par emplacement dépend des emplacements remplis. Le prix de base se saisit hors taxe.
### Le stock des composants n'est pas décrémenté
Le décrément a lieu à la **validation de la commande** (hook `actionValidateOrder`), pas à l'ajout au panier. Vérifiez que la commande atteint bien un état valide.
### Puis-je exiger une structure précise (par catégories) ?
Oui : activez les **emplacements** et définissez pour chacun un minimum / maximum et ses sources. Vous obtenez une composition guidée du type « 2 + 3 + 1 ».
### Est-ce compatible PrestaShop 9 ?
Oui. Le module est compatible PrestaShop 8 et 9, en multi-boutique et multilingue (FR, EN, ES, DE, IT).
---
### Cagnotte & Paiement Partagé (dfgiftpot)
_Source :_
> Présentation Le module Cagnotte & Paiement Partagé permet à vos clients de financer un cadeau commun à plusieurs. Un client crée une cagnotte depuis une fiche produit ou son panier,…
## Présentation
Le module **Cagnotte & Paiement Partagé** permet à vos clients de financer un cadeau commun à plusieurs. Un client crée une cagnotte depuis une fiche produit ou son panier, partage un lien unique, et chaque participant règle réellement sa part via les moyens de paiement déjà actifs sur votre boutique. À la clôture, un bon de réduction correspondant au montant collecté est automatiquement émis pour l'organisateur.
Le module est compatible PrestaShop 8.0 à 9.x, multiboutique, sans Composer ni dépendance externe.
## Installation
1. Dans votre back-office, ouvrez **Modules** puis **Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez le fichier `dfgiftpot.zip`.
3. Une fois installé, cliquez sur **Configurer** pour régler le module.
À l'installation, le module crée automatiquement un produit virtuel caché nommé « Contribution cagnotte ». Il sert de support technique au paiement des parts et n'apparaît pas dans le catalogue.
## Réglages du module
La page de configuration regroupe les paramètres suivants :
- **Contribution minimum** : montant plancher d'une participation (par défaut 5).
- **Contribution maximum** : plafond d'une participation (0 = illimité).
- **Durée par défaut** : nombre de jours avant l'échéance d'une cagnotte.
- **Validité du bon** : durée de validité, en jours, du bon de réduction émis à la clôture.
- **Bouton sur la fiche produit** : affiche un bouton « Créer une cagnotte » sur les pages produit.
- **Bouton depuis le panier** : affiche un bouton « Créer une cagnotte » dans le panier.
- **Cagnottes libres** : autorise la création de cagnottes sans produit cible.
- **Clôture automatique** : clôt la cagnotte dès que l'objectif est atteint.
- **Conditions** : mentions affichées au participant avant sa contribution.
## Comment fonctionne une cagnotte
Le mécanisme repose sur une capture réelle de chaque participation :
1. Un client crée une cagnotte (ciblée sur un produit, ou libre) et fixe éventuellement un objectif.
2. Il partage le lien public de la cagnotte avec les participants.
3. Chaque participant saisit un montant. Le module crée pour lui un panier dédié contenant le produit « Contribution cagnotte » au prix exact de sa part, puis le dirige vers le tunnel de commande natif.
4. Une fois le paiement validé, la participation est marquée payée et ajoutée au total collecté.
5. À l'atteinte de l'objectif (clôture automatique) ou sur clôture manuelle, un bon de réduction du montant collecté est généré et envoyé à l'organisateur.
Le produit de contribution est créé sans taxe : le participant paie exactement le montant qu'il saisit. Vous pouvez ajuster ce comportement en lui affectant une règle de taxe si votre fiscalité l'exige.
## Côté client
### Créer une cagnotte
Depuis une fiche produit ou son panier, le client clique sur « Créer une cagnotte », renseigne un titre, un objectif facultatif et une échéance, puis valide. La création nécessite un compte client.
### Participer
Un participant ouvre le lien de la cagnotte, saisit son montant, son nom et son e-mail (un message et l'option anonyme sont possibles), puis paie sa part. Aucun compte n'est nécessaire pour participer.
### Partager
La page de la cagnotte propose un lien unique et un bouton « Copier » pour le diffuser facilement.
### Mes cagnottes
L'organisateur retrouve ses cagnottes dans son compte client, où il peut suivre la progression, clôturer ou annuler.
## Côté boutiquier (back-office)
Un onglet **Cagnottes** est ajouté dans le menu Client. Il liste toutes les cagnottes avec leur organisateur, objectif, montant collecté, statut et échéance. La vue détaillée affiche la liste des participations et permet de clôturer ou d'annuler une cagnotte manuellement.
## E-mails envoyés
- **Nouvelle contribution** : envoyé à l'organisateur à chaque participation payée.
- **Cagnotte clôturée** : envoyé à l'organisateur à la clôture, avec le code du bon de réduction.
Les modèles sont fournis en français et en anglais et sont personnalisables depuis la traduction des e-mails de PrestaShop.
## Bon de réduction émis
À la clôture, le module génère une règle panier à usage unique, restreinte au compte de l'organisateur, dont le code suit le format « POT- » suivi d'un jeton et de l'identifiant de la cagnotte. Le bon correspond au montant collecté et est utilisable selon les règles standard des bons de réduction PrestaShop.
## Questions fréquentes
### Peut-on créer une cagnotte sans produit ?
Oui, si l'option « Cagnottes libres » est activée dans les réglages.
### Que se passe-t-il si une participation dépasse l'objectif ?
Lorsqu'un objectif est défini, la dernière participation est automatiquement plafonnée au montant restant.
Ne supprimez pas le produit « Contribution cagnotte » créé par le module : il est indispensable au paiement des parts. En cas de suppression accidentelle, réinstallez le module pour le recréer.
## Désinstallation
La désinstallation depuis le Gestionnaire de modules supprime les tables des cagnottes et des participations ainsi que la configuration. Sauvegardez vos données au préalable si vous souhaitez les conserver.
---
### Carbon Footprint + Offset Checkout — Guide complet
_Source :_
> Installation Carbon Footprint + Offset Checkout est un plugin WooCommerce standard, installable comme n'importe quelle extension. Téléchargez le ZIP df-carbon-offset.zip depuis la fiche produit DataFirefly. Dans votre back-office WordPress, allez…
## Installation
Carbon Footprint + Offset Checkout est un plugin WooCommerce standard, installable comme n'importe quelle extension.
1. Téléchargez le ZIP `df-carbon-offset.zip` depuis la fiche produit DataFirefly.
2. Dans votre back-office WordPress, allez sur **Extensions → Ajouter → Téléverser une extension**.
3. Sélectionnez le fichier ZIP, cliquez sur **Installer maintenant**, puis sur **Activer**.
4. Une nouvelle entrée **Carbon Footprint** apparaît dans le menu latéral WooCommerce.
**Prérequis :** WordPress 6.0 ou plus, WooCommerce 7.0 ou plus, PHP 7.4 minimum (PHP 8.1+ recommandé). Le plugin déclare explicitement sa compatibilité HPOS et Cart/Checkout Blocks — aucun avertissement n'apparaît dans WooCommerce Status.
À l'activation, deux tables SQL sont créées automatiquement : `{prefix}dfcarbon_factors` (facteurs d'émission) et `{prefix}dfcarbon_log` (journal des compensations). La base ADEME est immédiatement seedée avec environ 25 facteurs pré-chargés.
## Configuration initiale
Le plugin fonctionne **zero-config** dès l'activation : les facteurs ADEME sont chargés, le badge s'affiche sur toutes les fiches produit, la compensation apparaît au checkout. Mais quelques ajustements initiaux vous donneront des chiffres bien plus pertinents.
### Réglages généraux
Allez sur **Carbon Footprint → Réglages**. Quatre blocs de paramètres :
- **API Climatiq** — optionnelle. Laissez vide pour un fonctionnement 100% local sur les facteurs ADEME.
- **Compensation** — activation du bloc au checkout, prix par tonne (défaut 25 €/t, marché typique 15–30 €/t), partenaire affiché (Gold Standard par défaut), description client.
- **Transport** — activation de la composante transport, distance moyenne en km (défaut 500 km), facteur d'émission transport (défaut : transport routier).
- **Affichage** — position du badge sur la fiche produit (5 hooks disponibles), style (carte, pastille, minimal), couleur, priorité du hook.
### Mapping catégories → facteurs
C'est l'étape la plus impactante. Allez sur **Carbon Footprint → Mapping**. Pour chaque catégorie de produits WooCommerce, sélectionnez le facteur d'émission le plus pertinent parmi ceux de la base ADEME.
Sans mapping, tous vos produits utiliseront le facteur `general` (4,50 kgCO₂e/kg), ce qui est très approximatif. Un mapping soigné passe de _« ordre de grandeur »_ à _« estimation crédible pour reporting »_.
### Activation de l'API Climatiq (optionnelle)
Climatiq est une base de plus de 80 000 facteurs d'émission, plus fine que la Base Empreinte ADEME sur certains secteurs (électronique détaillée, cosmétique par composant, agroalimentaire par filière). Si vous avez une clé :
1. Créez un compte sur `climatiq.io` (offre gratuite disponible pour un usage modéré).
2. Copiez la clé API dans **Carbon Footprint → Réglages → Climatiq API**.
3. Cliquez sur **Tester la connexion** pour valider.
Une fois activée, l'API Climatiq est utilisée en priorité 2 (après un éventuel override manuel produit) et devant le mapping ADEME. Chaque résultat est mis en cache une semaine — aucun surcoût d'appel au rendu des pages.
## Comment fonctionne le calcul d'empreinte
### Priorités du calcul
Pour chaque produit, le plugin détermine l'empreinte via quatre sources, dans cet ordre strict de priorité :
1. **Override manuel produit** — si vous avez saisi une valeur dans l'onglet « Carbon » de la fiche produit (meta `_dfcarbon_kgco2e`), c'est celle-ci qui est utilisée. Elle court-circuite toutes les autres sources.
2. **API Climatiq** — si une clé API est configurée et que le produit a un poids ou une catégorie interrogeable.
3. **Facteur ADEME via mapping** — le facteur assigné à la catégorie du produit, appliqué au poids.
4. **Fallback général** — le facteur `general` (4,50 kgCO₂e/kg) appliqué au poids, ou une valeur forfaitaire si le poids n'est pas renseigné.
Le calcul est mis en cache via l'API objet WordPress (groupe `dfcarbon_product`) et invalidé automatiquement à chaque modification de fiche produit ou de mapping.
### Composante transport
Si activée, la composante transport est ajoutée à l'empreinte matière :
```
empreinte_totale = empreinte_matière + (poids_kg × distance_km × facteur_transport_tkm)
```
Le facteur transport routier par défaut est de 0,105 kgCO₂e par tonne-kilomètre (source ADEME, poids lourd moyen). Vous pouvez changer le facteur transport dans les réglages, ou basculer sur un autre facteur (transport maritime, aérien, etc.) si vous en ajoutez à la base.
La composante transport ne concerne que le **transport aval** (de l'entrepôt vers le client). L'empreinte matière du facteur ADEME inclut déjà la production et le transport amont.
## Facteurs d'émission ADEME inclus
Le plugin est livré avec environ 25 facteurs pré-chargés, issus de la **Base Empreinte ADEME** (France). Les principaux secteurs couverts :
- **Textile** — vêtement standard, coton, laine, synthétique, chaussures
- **Électronique** — smartphone, ordinateur portable, petit électroménager, gros électroménager
- **Alimentaire** — bovin, porc, volaille, poisson, produits laitiers, épicerie sèche
- **Cosmétique** — soin corps, maquillage, parfumerie
- **Maison** — mobilier bois, mobilier métal, textile de maison
- **Papier** — livre, magazine, carton d'emballage
- **Sport** — équipement sportif, vêtement sport
- **Bijoux** — bijouterie fantaisie, argent, or
- **Transport** — transport routier, transport maritime
- **Fallback** — `general` (4,50 kgCO₂e/kg)
Vous pouvez consulter, éditer, supprimer ou ajouter vos propres facteurs depuis **Carbon Footprint → Facteurs**. Chaque facteur possède : un slug unique, un libellé, une valeur en kgCO₂e/unité, une unité (kg par défaut), une source (ADEME, Climatiq, personnalisé…) et une année.
Un bouton **Recharger les valeurs ADEME par défaut** permet de restaurer la base d'origine _sans écraser vos ajouts personnels_ : seuls les slugs ADEME manquants seront réinsérés.
## Le badge produit
### Styles disponibles
Trois rendus au choix (réglable dans **Réglages → Affichage → Style du badge**) :
- **Carte (détaillée)** — bloc complet avec l'empreinte, la source, deux équivalences pédagogiques (km voiture, années d'arbre) et le prix de compensation.
- **Pastille en ligne** — badge compact « 🌱 5,2 kg CO₂e » à côté du prix.
- **Texte minimal** — juste la valeur, sans encadré.
### Positions
Le badge s'accroche à l'un des hooks WooCommerce standards :
- `after_price` — juste après le prix (défaut)
- `before_add_to_cart` — avant le bouton d'ajout au panier
- `after_add_to_cart` — après le bouton d'ajout au panier
- `before_meta` — avant les métadonnées produit
- `after_summary` — après le résumé complet du produit
Si aucune position ne convient à votre thème, vous pouvez utiliser le shortcode `[dfcarbon_badge]` directement dans un template ou un builder visuel (Elementor, Divi, Gutenberg…).
### Masquer sur certains produits
Dans l'onglet **Carbon** de chaque fiche produit, cochez _« Masquer le badge »_. Le calcul d'empreinte reste actif (utile pour les rapports et le checkout), mais l'affichage public disparaît. Pratique pour les produits dématérialisés, les cartes cadeaux ou les services.
## Compensation au checkout
Au checkout, le plugin insère un bloc entre le récapitulatif de commande et le mode de paiement. Ce bloc contient :
- L'empreinte estimée du panier (somme des empreintes de tous les articles × leurs quantités)
- Le coût de compensation correspondant (empreinte × prix par tonne)
- Une case à cocher optionnelle « Oui, j'ajoute X € pour compenser l'impact de ma commande »
- Un texte descriptif configurable mentionnant le partenaire (Gold Standard, Verra…)
Quand le client coche la case, un **fee WooCommerce dynamique** est ajouté au total via le hook `woocommerce_cart_calculate_fees`. L'état est stocké dans la session WooCommerce (`dfcarbon_offset_active`), puis persisté sur la commande via les metas `_dfcarbon_cart_kgco2e`, `_dfcarbon_offset_active`, `_dfcarbon_offset_amount` et `_dfcarbon_offset_provider`.
**Important :** le plugin **collecte** la compensation auprès de vos clients — il **n'achète pas** les crédits carbone à votre place. C'est un choix délibéré, pour vous laisser maître du timing, du canal et du partenaire (Gold Standard, Verra, Ecologi, MyClimate…). Le tableau de bord vous indique le total à honorer à chaque cycle de paiement chez votre partenaire.
## Tableau de bord et rapports
Le menu **Carbon Footprint → Tableau de bord** affiche les indicateurs globaux :
- Nombre total de commandes compensées
- Empreinte CO₂ cumulée mesurée sur les commandes
- Empreinte CO₂ effectivement compensée
- Montant total investi en compensation
Le menu **Carbon Footprint → Rapports** détaille chaque commande compensée : date, numéro de commande, empreinte de la commande, kg compensés, montant, partenaire. Ce tableau alimente directement votre reporting extra-financier CSRD ou toute demande d'audit RSE.
Un snapshot d'empreinte est aussi conservé par ligne de commande (meta `_dfcarbon_line_kgco2e`) : les valeurs affichées ne changent pas rétrospectivement quand vous modifiez un facteur ADEME plus tard.
## Shortcodes disponibles
Trois shortcodes publics pour intégrer les éléments partout dans votre site :
```
[dfcarbon_badge id="123" style="card"]
```
Affiche le badge carbone d'un produit spécifique. `id` est obligatoire, `style` optionnel (`card` par défaut, `pill`, `minimal`).
```
[dfcarbon_cart_summary]
```
Affiche l'empreinte du panier en cours et le coût de compensation. Utile dans une page « Mon panier » personnalisée ou dans une side-cart.
```
[dfcarbon_stats]
```
Bloc public avec les statistiques agrégées : tonnes compensées, nombre de commandes, montant investi. Parfait pour une page « Notre engagement climat ».
## Hooks & filtres pour développeurs
Le plugin expose un filtre principal pour override complet du calcul d'empreinte :
```
add_filter( 'dfcarbon_product_footprint', function( $footprint, $product_id, $context ) {
// $footprint est un array : ['kg' => 5.2, 'source' => 'ademe', 'breakdown' => [...]]
// Retournez un array modifié pour surcharger
return $footprint;
}, 10, 3 );
```
Autres hooks utiles :
- `dfcarbon_daily_sync` — action WP-Cron quotidienne (purge des transients Climatiq)
- `dfcarbon_before_offset_fee` — action avant l'ajout du fee de compensation
- `dfcarbon_offset_purchased` — action déclenchée à la persistance sur commande
Le plugin utilise le namespace PHP `DataFirefly\CarbonOffset`. Pour ajouter un facteur programmatique depuis un mu-plugin ou un thème enfant, importez la classe `Database` :
```
use DataFirefly\CarbonOffset\Database;
Database::upsert_factor( [
'slug' => 'mon-facteur',
'label' => 'Mon secteur particulier',
'value' => 2.35,
'unit' => 'kg',
'source' => 'Personnalisé',
'year' => 2026,
] );
```
## Multilingue (Polylang / WPML)
Le plugin est compatible avec Polylang Pro et WPML. Les 5 langues fournies (FR, EN, ES, DE, IT) sont dans le dossier `languages/` avec les fichiers `.po` et `.mo` déjà compilés.
Pour ajuster une traduction :
1. Installez Loco Translate (plugin gratuit) ou utilisez Poedit en local.
2. Ouvrez le catalogue `df-carbon-offset-fr_FR.po`.
3. Éditez les entrées à traduire.
4. Recompilez en `.mo` — automatique dans Loco Translate.
Pour ajouter une nouvelle langue non fournie (portugais, néerlandais…), dupliquez un `.po` existant, renommez-le au bon locale (`df-carbon-offset-pt_PT.po`, `df-carbon-offset-nl_NL.po`…), traduisez et compilez.
## Désinstallation
Le plugin nettoie proprement à la désinstallation via `uninstall.php` :
- Suppression des tables `dfcarbon_factors` et `dfcarbon_log`
- Suppression des options `dfcarbon_settings` et `dfcarbon_db_version`
- Suppression des postmeta `_dfcarbon_*` sur tous les produits et commandes
- Désinscription du cron `dfcarbon_daily_sync`
- Purge des transients Climatiq
La désinstallation est **destructive** : le journal des compensations passées est supprimé. Si vous avez besoin de le conserver pour un audit CSRD, exportez le tableau `Rapports` avant la suppression.
## FAQ
### Puis-je forcer un facteur spécifique sur un produit sans changer sa catégorie ?
Oui. Dans l'onglet Carbon de la fiche produit, sélectionnez un facteur dans le menu déroulant « Facteur d'émission ». Il l'emporte sur le mapping de catégorie pour ce produit uniquement.
### Que se passe-t-il si mon produit n'a pas de poids ?
Le calcul utilise une valeur forfaitaire pour les produits sans poids (traités comme « unité »). Vous pouvez aussi utiliser l'override manuel pour saisir directement la valeur en kg CO₂e.
### Le plugin fonctionne-t-il avec les produits variables ?
Oui. L'empreinte est calculée au niveau du produit parent (via son poids et sa catégorie), ce qui reste cohérent pour la plupart des cas. Pour un contrôle par variation, utilisez le filtre `dfcarbon_product_footprint`.
### Comment gérer les produits téléchargeables (dématérialisés) ?
Pour un produit purement dématérialisé (ebook, formation en ligne, licence logicielle), cochez « Masquer le badge » et laissez le calcul retomber sur le fallback général (l'impact sera minimal si le produit n'a pas de poids). Alternative : utilisez l'override manuel avec une petite valeur (typiquement 0,01 à 0,1 kg CO₂e pour un ebook).
### Puis-je exclure un produit de la compensation au checkout ?
La compensation s'applique au panier dans son ensemble, pas produit par produit. Si un produit doit être totalement exclu du calcul, utilisez le filtre `dfcarbon_product_footprint` pour retourner un array avec `['kg' => 0]`.
### Le plugin fait-il des appels API à chaque page vue ?
Non. Chaque empreinte produit est mise en cache via l'API objet WordPress. Les appels Climatiq (si activés) sont eux-mêmes cachés en transient pendant une semaine. Une page produit ne déclenche aucun appel externe.
### Compatible avec les caches (WP Rocket, Litespeed, W3TC) ?
Oui, entièrement. Le rendu du badge est statique côté serveur. La partie dynamique (checkbox de compensation au checkout) est gérée en AJAX et n'affecte pas la mise en cache de la fiche produit.
---
### Carrousel d'Avis Google pour Shopware 6 — Installation, configuration et utilisation
_Source :_
> Le plugin Carrousel d'Avis Google affiche les avis Google de votre établissement sous forme de carrousel responsive dans le storefront Shopware 6. Il génère automatiquement le balisage Schema.org (LocalBusiness +…
Le plugin **Carrousel d'Avis Google** affiche les avis Google de votre établissement sous forme de carrousel responsive dans le storefront Shopware 6. Il génère automatiquement le balisage Schema.org (LocalBusiness + AggregateRating + Review), met les avis en cache et propose deux thèmes intégrés. Aucun build administration n'est requis : il s'installe sur n'importe quel hébergement, y compris mutualisé.
## Prérequis
- Shopware 6.5.x, 6.6.x ou 6.7.x
- PHP 8.1 ou supérieur
- Une clé API Google Cloud avec l'**API Places** activée (gratuite jusqu'à un large volume de requêtes)
- Le **Place ID** de votre établissement Google
## Installation
Déposez l'archive ZIP via _Extensions > Mes extensions > Charger l'extension_, ou copiez le dossier `DfGoogleReviews` dans `custom/plugins/`. Puis exécutez :
```
bin/console plugin:refresh
bin/console plugin:install --activate DfGoogleReviews
bin/console cache:clear
```
Le plugin apparaît ensuite dans _Extensions > Mes extensions_, prêt à être configuré.
## Obtenir votre clé API et votre Place ID
### Clé API Google
1. Rendez-vous sur `console.cloud.google.com` et créez (ou sélectionnez) un projet.
2. Dans _API et services_, activez l'**API Places**.
3. Dans _Identifiants_, créez une clé API et copiez-la.
4. Recommandé : restreignez la clé à l'API Places et à votre domaine.
### Place ID
Utilisez le _Place ID Finder_ de Google (documentation Google Maps Platform) pour récupérer l'identifiant de votre établissement. Il ressemble à `ChIJ...`.
## Configuration
Ouvrez _Extensions > Mes extensions > Carrousel d'avis Google > Configurer_. Tous les réglages sont gérés **par canal de vente** : sélectionnez le sales channel concerné en haut de la page avant de configurer.
### Connexion Google
- **Activer le carrousel** : interrupteur principal.
- **Clé API Google** : votre clé avec l'API Places activée.
- **Place ID** : l'identifiant de votre établissement.
- **Langue des avis** : code langue (ex. `fr`, `de`, `en`) transmis à l'API pour les textes et dates relatives. Laisser vide pour le défaut Google.
### Affichage
- **Position** : _Page d'accueil_ (au-dessus du footer), _Toutes les pages_, ou _Manuel_ (voir la section suivante).
- **Titre** : titre du carrousel (vide = titre traduit par défaut, fourni en 5 langues).
- **Thème** : Light ou Dark.
- **Défilement automatique** et **intervalle** (en millisecondes) : pause automatique au survol et au focus.
- **Nombre maximum d'avis** : jusqu'à 10 (l'API Google en renvoie 5 au maximum).
- **Note minimum** : n'affiche que les avis au-dessus du seuil (ex. 4 pour ne garder que les 4 et 5 étoiles).
### Cache
- **Durée de vie du cache** : de 1 heure à 7 jours (24 heures recommandé).
## Afficher le carrousel
### Mode automatique
Avec la position _Page d'accueil_ ou _Toutes les pages_, le carrousel s'insère automatiquement au-dessus du footer. Aucune modification de thème n'est nécessaire.
Le mode automatique passe par le bloc `base_footer`. Si un thème personnalisé écrase entièrement ce bloc sans appeler `parent()`, utilisez le mode manuel ci-dessous.
### Mode manuel (include Twig)
Choisissez la position _Manuel_, puis insérez le composant où vous le souhaitez dans votre thème storefront :
```
{% sw_include '@DfGoogleReviews/storefront/component/df-google-reviews.html.twig' %}
```
C'est idéal pour placer les avis sur une page CMS précise, dans une Shopping Experience ou à un endroit spécifique de votre mise en page.
## Commandes console
Deux commandes facilitent la maintenance :
```
# Tester la connexion API et prévisualiser les avis (cache ignoré)
bin/console df:google-reviews:test
# Vider le cache des avis
bin/console df:google-reviews:clear-cache
```
Les deux acceptent l'option `--sales-channel-id=...` pour cibler la configuration d'un canal de vente précis. La commande de test affiche le nom de l'établissement, la note globale et la liste des avis renvoyés — pratique pour valider la clé API et le Place ID avant publication.
## SEO et Schema.org
À chaque affichage, le plugin injecte un balisage JSON-LD complet : `LocalBusiness` (nom, note globale), `AggregateRating` (moyenne et nombre total d'avis) et un bloc `Review` par avis. Ce balisage peut faire apparaître les étoiles dans les résultats Google (rich snippets). Le contenu étant rendu côté serveur, les avis restent lisibles par les robots d'indexation et les utilisateurs sans JavaScript ; le carrousel n'est qu'une amélioration progressive.
## Performance
Le CSS (~2 KB) et le JavaScript (~2 KB, Vanilla JS) sont injectés uniquement sur les pages où le carrousel s'affiche. Aucune librairie tierce, aucun jQuery. Les appels à l'API Google Places sont mis en cache dans le cache objet Shopware selon la durée configurée.
**Dégradation gracieuse** : si l'API Google est momentanément indisponible, les derniers avis valides mis en cache continuent d'être affichés. Le storefront n'est jamais cassé par le widget.
## Dépannage
- **Le carrousel ne s'affiche pas** : vérifiez que le plugin est activé, que la case « Activer le carrousel » est cochée, et que la clé API et le Place ID sont renseignés. Lancez `bin/console df:google-reviews:test` pour diagnostiquer.
- **Erreur d'API** : assurez-vous que l'API Places est bien activée dans Google Cloud et que la clé n'est pas trop restreinte. Consultez `var/log` pour le détail.
- **Les avis ne se mettent pas à jour** : videz le cache avec `bin/console df:google-reviews:clear-cache` (l'API Google ne renvoie de toute façon que les 5 avis les plus récents).
- **Mode automatique invisible sur un thème custom** : basculez en mode manuel et ajoutez l'include Twig.
## Désinstallation
Désactivez puis désinstallez le plugin depuis _Extensions > Mes extensions_, ou via :
```
bin/console plugin:uninstall DfGoogleReviews
```
Si vous choisissez de supprimer les données lors de la désinstallation, toute la configuration (clés `DfGoogleReviews.config.*`) est automatiquement nettoyée.
---
### Catalogue PDF PrestaShop — Guide complet
_Source :_
> Présentation DFPDFCatalog publie vos catalogues PDF directement sur votre boutique PrestaShop 8 ou 9. Le module fonctionne de deux façons complémentaires. Il crée d'abord ses propres pages en front-office :…
## Présentation
DFPDFCatalog publie vos catalogues PDF directement sur votre boutique PrestaShop 8 ou 9. Le module fonctionne de deux façons complémentaires. Il crée d'abord ses propres pages en front-office : une page vitrine listant tous vos catalogues sous forme de bannières cliquables (`/catalogues-pdf`) et une page visionneuse par catalogue (`/catalogue-pdf/{id}-{slug}`). Il permet ensuite d'**intégrer n'importe quel catalogue dans n'importe quelle page** de votre boutique, via un shortcode, un widget Smarty ou une iframe.
Dans les deux cas, le PDF s'affiche dans un lecteur intégré de niveau professionnel : mode double page magazine, miniatures cliquables, plein écran, zoom, liens cliquables et texte sélectionnable.
## Installation
1. Téléchargez le fichier ZIP du module depuis votre compte DataFirefly.
2. Dans votre back-office PrestaShop, allez dans **Modules → Gestionnaire de modules → Installer un module**.
3. Sélectionnez le fichier `dfpdfcatalog.zip` et validez.
4. Le module s'installe automatiquement : tables de base de données, onglet admin et routes front sont créés sans aucune configuration manuelle.
Après installation, un nouvel onglet **Catalogues PDF** apparaît dans le menu **Catalogue** du back-office.
La même archive s'installe sur PrestaShop 8.0 à 8.2 et sur PrestaShop 9.x. Aucune version distincte n'est à télécharger selon votre génération.
### Mise à jour depuis une version antérieure
1. Uploadez la nouvelle version via **Modules → Gestionnaire de modules → Installer un module** (ou remplacez le dossier `/modules/dfpdfcatalog/` par FTP).
2. Videz le cache PrestaShop : **Paramètres avancés → Performances → Vider le cache**.
La mise à jour préserve vos catalogues existants : les tables de base de données et les fichiers uploadés (bannières et PDF) ne sont pas touchés. En passant en 1.2.0, le module enregistre automatiquement les hooks nécessaires à l'intégration dans les pages.
## Ajouter un catalogue
1. Allez dans **Catalogue → Catalogues PDF** puis cliquez sur **Ajouter un catalogue**.
2. Renseignez le **titre** (traduisible par langue) — il sert aussi à générer le slug de l'URL et le meta title de la page.
3. Renseignez la **description** (traduisible) — affichée sur la page visionneuse et utilisée comme meta description.
4. Uploadez l'**image de bannière** — elle apparaît dans la grille de la page vitrine et sert d'affiche d'ouverture lorsque le catalogue est intégré dans une page.
5. Uploadez le **fichier PDF**.
6. Définissez la **position** (ordre d'affichage dans la grille) et le statut **actif/inactif**.
7. En multiboutique, cochez les boutiques sur lesquelles le catalogue doit apparaître.
8. Sauvegardez : le catalogue est immédiatement visible sur `/catalogues-pdf`.
Une fois le catalogue enregistré, rouvrez-le : le formulaire affiche un bloc **Codes d'intégration** contenant les quatre codes prêts à copier pour l'afficher ailleurs sur votre boutique. Cliquez dans un champ pour le sélectionner.
## Intégrer un catalogue dans une page
La page vitrine ne convient pas à tous les usages. Pour une landing page métier, une page marché public ou une catégorie qui doit présenter son propre catalogue, vous pouvez placer la visionneuse exactement où vous le souhaitez.
### Méthode recommandée : le shortcode
Collez ce marqueur dans le contenu de votre page, à l'endroit exact où le catalogue doit apparaître :
```
[dfpdfcatalog id="3"]
```
Remplacez `3` par l'identifiant du catalogue, visible dans la colonne ID de la liste **Catalogue → Catalogues PDF**. Le shortcode fonctionne dans :
- le contenu des **pages CMS** ;
- les **descriptions de catégorie** ;
- les **descriptions de produit**.
Dans ces trois contextes, le module remplace le marqueur côté serveur, avant l'envoi de la page. Pour tous les autres contextes (blocs de thème, modules tiers, page builders), un repli JavaScript détecte le marqueur dans la page et monte la visionneuse au même endroit. Vous n'avez rien à configurer : le comportement est identique pour le visiteur.
### Options du shortcode
- `id` — identifiant du catalogue. Obligatoire.
- `mode` — `click` (par défaut) affiche d'abord une affiche reprenant la bannière du catalogue, et ne charge la visionneuse qu'au clic. `inline` affiche directement la visionneuse, chargée à l'approche du viewport.
- `height` — hauteur de la visionneuse en pixels. Par défaut la visionneuse occupe 80 % de la hauteur de l'écran.
- `title` — libellé affiché sur l'affiche d'ouverture. Par défaut, le titre du catalogue.
```
[dfpdfcatalog id="3" mode="inline" height="800"]
```
### Widget Smarty dans un template de thème
Pour intégrer un catalogue directement dans un fichier `.tpl` de votre thème :
```
{widget name='dfpdfcatalog' id_catalog=3 mode='inline'}
```
Cette syntaxe ne fonctionne que dans les templates. Le contenu des pages CMS n'étant pas interprété par Smarty, utilisez le shortcode dans ce cas.
### Iframe, y compris hors PrestaShop
Le module expose une page d'intégration sans en-tête ni pied de page de la boutique, à placer dans une iframe :
```
```
C'est la méthode à retenir pour afficher un catalogue sur un site externe. Ces pages d'intégration sont en `noindex` et ne concurrencent donc jamais vos vraies pages dans les résultats de recherche. Notez que la hauteur d'une iframe est fixe : sur votre propre boutique, préférez le shortcode, qui s'adapte au contenu.
### Plusieurs catalogues sur une même page
Vous pouvez placer autant de catalogues que nécessaire sur une même page. Chaque intégration crée une visionneuse indépendante, avec ses propres commandes de navigation, son zoom et son mode d'affichage. Les raccourcis clavier n'agissent que sur la visionneuse survolée, et non sur toutes en même temps.
Le chargement est optimisé pour ce cas de figure :
- en mode `click`, aucun PDF n'est téléchargé tant que le visiteur n'a pas ouvert un catalogue ;
- en mode `inline`, le chargement se déclenche à l'approche du viewport ;
- la bibliothèque de rendu et la feuille de style ne sont téléchargées qu'une seule fois pour toute la page, et uniquement si un catalogue y est réellement présent.
Une page présentant huit catalogues en mode `click` ne charge donc au départ que huit images de bannière.
## Pages front-office
### Page vitrine
La page `/catalogues-pdf` affiche tous les catalogues actifs de la boutique courante sous forme de grille de bannières, triées par position. Chaque bannière renvoie vers la visionneuse du catalogue. La page génère son propre meta title et sa meta description, et s'intègre au fil d'Ariane natif de PrestaShop.
### Page visionneuse
Chaque catalogue dispose de sa propre page `/catalogue-pdf/{id}-{slug}`. Le PDF y est affiché dans la visionneuse intégrée, avec un bouton de retour vers la vitrine et un bouton de téléchargement direct. Le PDF est servi via un contrôleur PHP en affichage inline, ce qui force l'affichage dans le navigateur. Les requêtes HTTP Range sont supportées, ce qui permet aux gros catalogues de se charger progressivement plutôt qu'en une seule fois.
## Utiliser la visionneuse
La visionneuse repose sur PDF.js (Mozilla) et offre les commandes suivantes dans sa barre d'outils :
- **Miniatures** — affiche ou masque la barre latérale des miniatures de pages. Les miniatures sont cliquables et se génèrent au fur et à mesure du défilement (rendu paresseux), même pour de très longs catalogues. La ou les pages actives sont surlignées.
- **Double page** — bascule entre affichage page par page et mode double page magazine : couverture seule, puis paires 2-3, 4-5, etc. Ce mode est activé par défaut sur les écrans d'au moins 1024 px de large.
- **Navigation** — boutons précédent/suivant, indicateur de page (par exemple « Page 4-5 / 24 » en mode double page). Les flèches gauche/droite du clavier fonctionnent aussi.
- **Zoom** — zoom avant/arrière par paliers de 25 % et bouton d'ajustement automatique à la largeur.
- **Plein écran** — bascule la visionneuse en plein écran via l'API native du navigateur. Sur iOS Safari, un mode plein écran simulé est utilisé automatiquement. La touche Échap permet de sortir.
Les hyperliens contenus dans le PDF restent cliquables : les liens externes s'ouvrent dans un nouvel onglet, et les liens internes (sommaire, renvois) naviguent directement dans la visionneuse. Si le PDF contient une couche texte, le texte est sélectionnable, copiable, et la recherche Ctrl+F du navigateur fonctionne sur le contenu.
Le rendu utilise la densité de pixels de l'écran (HiDPI) : les pages sont nettes sur écrans Retina et 4K.
## SEO et URLs
Le module déclare ses routes via le hook moduleRoutes de PrestaShop :
- `/catalogues-pdf` — page vitrine, avec meta title et meta description dédiés.
- `/catalogue-pdf/{id}-{slug}` — une URL propre par catalogue, où le slug est généré automatiquement à partir du titre. Le meta title reprend le titre du catalogue et la meta description reprend sa description.
- `/catalogue-pdf-embed/{id}` — page d'intégration destinée aux iframes, en `noindex`.
Aucune page CMS n'est à créer : les routes sont enregistrées automatiquement à l'installation.
## Multilingue et multiboutique
Les titres et descriptions se traduisent champ par champ dans le formulaire d'édition (sélecteur de langue standard PrestaShop). Chaque langue génère son propre slug et ses propres metas. En multiboutique, l'association catalogue/boutique se gère par cases à cocher : chaque boutique n'affiche que les catalogues qui lui sont assignés. Ce filtrage s'applique également à l'accès direct par URL et aux intégrations dans les pages : un catalogue non assigné à la boutique courante n'y est jamais servi.
## Dépannage
### Le shortcode s'affiche en texte brut sur la page
- Vérifiez que l'identifiant correspond bien à un catalogue existant, actif, et assigné à la boutique courante. Un identifiant introuvable laisse le marqueur intact plutôt que d'afficher une visionneuse vide.
- Vérifiez que le catalogue contient bien un fichier PDF.
- Videz le cache PrestaShop, puis rechargez la page en navigation privée.
- Si vous venez de mettre à jour le module, désinstallez puis réinstallez-le pour forcer l'enregistrement des hooks d'intégration.
### Le PDF ne s'affiche pas
- Vérifiez que le fichier PDF a bien été uploadé (rééditez le catalogue dans le back-office).
- Videz le cache PrestaShop puis rechargez la page en navigation privée.
- Si un message d'erreur apparaît dans la visionneuse, un lien de téléchargement direct du PDF est proposé en secours.
### Le texte n'est pas sélectionnable ou Ctrl+F ne trouve rien
La sélection de texte nécessite que le PDF contienne une couche texte. Les PDF scannés ou exportés en pur bitmap n'en contiennent pas : dans ce cas seul l'affichage graphique est possible. Passez le document par un outil d'OCR si vous avez besoin du texte.
### Les liens du PDF ne sont pas cliquables
Les liens doivent être de véritables annotations de lien dans le PDF (créées par l'outil d'export : InDesign, Word, LibreOffice…). Un texte qui ressemble à une URL mais sans annotation ne sera pas cliquable.
### Les pages apparaissent étirées ou floues
Ce problème des versions 1.0.0 est corrigé depuis la version 1.0.1 (rendu HiDPI et neutralisation des resets CSS des thèmes). Mettez le module à jour puis videz le cache PrestaShop.
## Historique des versions
- **1.2.0** (2026-08-10) — Intégration d'un catalogue dans n'importe quelle page via shortcode, widget Smarty ou iframe ; remplacement côté serveur dans les pages CMS, catégories et fiches produit, avec repli JavaScript ; visionneuse réécrite en instances indépendantes (plusieurs catalogues par page) ; chargement paresseux ; codes d'intégration prêts à copier en back-office ; support des requêtes HTTP Range.
- **1.1.0** (2026-08-10) — Compatibilité PrestaShop 9 ; correction de l'association boutique dans le formulaire d'édition ; filtrage par boutique appliqué à l'accès direct par URL ; contrôle du contenu réel des fichiers envoyés.
- **1.0.4** (2026-05-11) — Mode plein écran (API native + fallback iOS Safari) ; correction du fit-width de la couverture en mode double page ; surlignage des boutons actifs.
- **1.0.3** (2026-05-11) — Mode double page magazine (couverture seule, puis 2-3, 4-5…) ; auto-activation sur écrans larges ; annulation propre des rendus lors de navigations rapides.
- **1.0.2** (2026-05-11) — Barre latérale de miniatures cliquables à rendu paresseux ; couche texte (sélection + Ctrl+F) ; bouton d'affichage des miniatures.
- **1.0.1** (2026-05-11) — Rendu HiDPI net sur Retina/4K ; liens du PDF cliquables (couche annotations) ; correction de l'étirement vertical des pages.
- **1.0.0** (2026-05-08) — Version initiale : page vitrine, visionneuse intégrée, URLs SEO, multilingue, multiboutique.
---
### Category Wall — Page catégorie visuelle
_Source :_
> Category Wall remplace la liste de sous-catégories native de PrestaShop par un mur de tuiles imagées, avec compteurs de produits et trois mises en page au choix. Ce guide couvre…
Category Wall remplace la liste de sous-catégories native de PrestaShop par un mur de tuiles imagées, avec compteurs de produits et trois mises en page au choix. Ce guide couvre l'installation, la configuration et l'utilisation avancée du module.
## Installation
Le module s'installe comme n'importe quel module PrestaShop, sans dépendance externe ni Composer.
1. Depuis le back-office, ouvrez **Modules > Module Manager**, puis cliquez sur **Installer un module** (bouton en haut à droite).
2. Sélectionnez le fichier `dfcategorywall.zip` et lancez l'installation.
3. Une fois installé, cliquez sur **Configurer** pour accéder aux réglages.
Le module est compatible PrestaShop 8.0 à 9.x, multiboutique, et n'ajoute aucun override de template. Il peut donc être installé et désinstallé en toute sécurité.
## Comment fonctionne l'affichage
Sur chaque page catégorie, le module affiche automatiquement le mur de sous-catégories au-dessus du listing de produits. Il s'appuie sur le hook `displayContentWrapperTop`, présent dans le thème Classic et la plupart des thèmes qui en dérivent.
Si aucune sous-catégorie active n'existe pour la catégorie consultée, le mur ne s'affiche pas : le module reste totalement invisible sur les catégories « feuilles ».
## Options de configuration
Toutes les options se règlent depuis l'écran de configuration du module.
### Mise en page (layout)
Trois présentations sont disponibles :
- **Grille** — une grille régulière de tuiles de taille identique, idéale pour un rendu propre et structuré.
- **Mosaïque** — une disposition dynamique où la première sous-catégorie occupe une tuile agrandie, pour attirer l'œil sur un rayon phare.
- **Carrousel** — un défilement horizontal fluide, tactile sur mobile et équipé de flèches de navigation sur desktop.
### Colonnes
Réglez le nombre de colonnes affichées sur desktop, de 2 à 6. Cette valeur s'applique aux layouts grille et carrousel. L'affichage s'adapte automatiquement à 3 puis 2 colonnes sur tablette et mobile.
### Compteurs de produits
Activez **Afficher les compteurs de produits** pour faire apparaître, sur chaque tuile, le nombre de produits de la sous-catégorie sous forme de badge.
- **Compter les produits récursivement** — additionne les produits de toute l'arborescence enfant (sous-sous-catégories comprises), et non uniquement les produits rattachés directement.
- **Masquer les sous-catégories vides** — retire du mur les sous-catégories sans aucun produit visible, pour ne présenter que des rayons réellement fournis.
Seuls les produits actifs et visibles au catalogue sont comptés. Le calcul est effectué en une seule requête groupée mise en cache : activer les compteurs n'a pas d'impact notable sur le temps de chargement.
### Description et titre
- **Afficher la description des sous-catégories** — affiche un court extrait sous le nom de chaque tuile (tronqué à 120 caractères).
- **Afficher le titre de la section** et **Titre de la section** — un intitulé personnalisable et multilingue affiché au-dessus du mur (par exemple « Parcourir les sous-catégories »). Laissez le champ vide pour masquer le titre.
### Masquer la liste native
L'option **Masquer la liste native des sous-catégories** ajoute une règle CSS discrète qui masque le bloc de sous-catégories par défaut du thème, afin d'éviter tout doublon avec le mur. Cette option est sans effet si votre thème n'affiche pas ce bloc.
## Tuiles sans image
Quand une sous-catégorie ne dispose pas d'image de couverture, le module génère automatiquement une tuile de repli : un dégradé de couleur stable, dérivé de l'identifiant de la catégorie, portant l'initiale de son nom. La grille reste ainsi toujours homogène, sans case vide.
Pour un rendu optimal, ajoutez une image à chaque sous-catégorie depuis **Catalogue > Catégories**. Le module utilise le format d'image « category » défini dans les réglages d'images de votre boutique.
## Utilisation en widget
Au-delà de la page catégorie, le mur peut être inséré n'importe où dans un template grâce à l'interface widget de PrestaShop.
```
{widget name='dfcategorywall'}
```
Pour cibler une catégorie précise, passez son identifiant :
```
{widget name='dfcategorywall' id_category=12}
```
## Dépannage
### Le mur ne s'affiche pas
- Vérifiez que la catégorie consultée possède bien des sous-catégories **actives**.
- Assurez-vous que votre thème déclenche le hook `displayContentWrapperTop`. Sinon, utilisez l'insertion par widget décrite ci-dessus.
### Les sous-catégories apparaissent en double
Activez l'option **Masquer la liste native des sous-catégories** pour supprimer le bloc d'origine du thème.
### Les flèches du carrousel n'apparaissent pas
Les flèches ne s'affichent que lorsqu'il y a suffisamment de tuiles pour déborder de la largeur visible. Sur mobile, la navigation se fait uniquement au doigt (défilement tactile).
Besoin d'aide ? Contactez le support DataFirefly depuis votre compte client, en précisant votre version de PrestaShop et le thème utilisé.
---
### Centre de Notifications — Guide complet
_Source :_
> Présentation Le module Centre de Notifications (dfnotificationcenter) ajoute une cloche de notifications dans l'en-tête de votre boutique, juste à côté du panier et de « Mon compte ». Un badge…
## Présentation
Le module **Centre de Notifications** (`dfnotificationcenter`) ajoute une **cloche de notifications** dans l'en-tête de votre boutique, juste à côté du panier et de « Mon compte ». Un **badge rouge** signale les notifications non lues. Vos **nouveaux produits** y apparaissent automatiquement et vous pouvez y pousser vos **codes promo**, que le client copie en un clic. Le tout est multilingue, multiboutique et compatible PrestaShop 8 et 9.
La cloche reprend un réflexe que vos visiteurs ont déjà sur les réseaux sociaux : un point rouge attire l'œil et invite au clic, sans pop-up intrusif ni bannière qui gêne la navigation.
## Compatibilité
- PrestaShop 8.0 à 9.x
- Mono-boutique et multiboutique
- PHP 7.2 à 8.x
- Thème Classic et thèmes personnalisés
- Interface livrée en français, anglais, espagnol, allemand et italien
- Aucune dépendance (ni Composer ni framework)
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** puis sélectionnez le fichier `dfnotificationcenter.zip`.
3. Une fois installé, cliquez sur **Configurer**.
À l'installation, le module crée ses trois tables (notifications, traductions, état de lecture), enregistre ses hooks (cloche dans l'en-tête, ressources front, enregistrement produit, création de bon de réduction) et ajoute l'onglet back-office **Notification Center** pour gérer les notifications.
## Réglages globaux
Depuis la page **Configurer** du module, vous réglez le comportement général :
- **Nouveaux produits automatiques** : crée une notification à chaque enregistrement d'un produit.
- **Produits actifs uniquement** : ne génère la notification que pour les produits actifs et visibles.
- **Promo auto sur bon de réduction** : crée automatiquement une notification promo dès qu'un bon de réduction avec code est créé.
- **Durée de vie des notifications produit (jours)** : expiration automatique après N jours. `0` = jamais.
- **Intervalle de rafraîchissement (secondes)** : actualisation du badge en arrière-plan. `0` = désactivé.
- **Nombre maximum d'éléments dans le panneau** : nombre de notifications affichées dans la cloche.
- **Couleur du badge** et **Couleur de la cloche** (vide = couleur du thème).
- **Son** et **Animation** de la cloche à l'arrivée d'une nouvelle notification.
## Gérer les notifications
L'onglet **Notification Center** (accessible aussi via le bouton « Ouvrir le Notification Center » sur la page de configuration) liste vos notifications avec leur type, priorité, nombre de vues et de clics, et leur état actif. Cliquez sur **Ajouter une notification** pour en créer une.
### Champs d'une notification
- **Type** : Nouveau produit, Code promo, News ou Information. Chaque type a son icône et sa couleur côté client.
- **Titre** (multilingue, requis) et **Message** (multilingue, éditeur de texte).
- **Libellé du bouton** (multilingue) et **Lien** (URL de destination).
- **ID produit** : pour le type Nouveau produit. L'image et le lien sont alors résolus automatiquement.
- **Code promo** : pour le type Code promo. Affiché côté client avec un bouton **Copier**.
- **Image** : visuel optionnel (ignoré pour le type produit, qui utilise l'image de couverture).
- **Groupe cible** : « Tous les clients » ou un groupe précis.
- **Priorité** : plus la valeur est élevée, plus la notification remonte en haut.
- **Date de début** et **Date de fin** : laissez vide pour « visible immédiatement » et « n'expire jamais ».
- **Actif** : interrupteur d'activation.
La planification et le ciblage se combinent : vous pouvez par exemple programmer une notification promo visible uniquement par le groupe « Clients fidèles », du 1er au 15 du mois, avec une priorité élevée pour qu'elle apparaisse en tête.
## Nouveaux produits automatiques
Quand l'option est activée, le module écoute l'enregistrement des produits (hook `actionProductSave`) et crée une notification de type produit avec le nom, l'image de couverture et le lien de la fiche. Un même produit n'est notifié qu'une seule fois (dédoublonnage par identifiant produit).
L'image et le lien d'une notification produit sont **recalculés à l'affichage**. Même si vous modifiez le produit ou changez sa photo plus tard, la notification reste correcte. Si le produit devient inactif ou est supprimé, la notification cesse simplement d'apparaître.
## Codes promo
Créez une notification de type **Code promo**, saisissez le code de votre bon de réduction, et il s'affiche côté client dans une puce avec un bouton **Copier**. Un clic, le code est dans le presse-papiers, le client retourne au panier l'appliquer.
Si l'option **Promo auto sur bon de réduction** est activée, une notification promo est créée automatiquement à chaque création d'un bon de réduction comportant un code (hook `actionObjectCartRuleAddAfter`), en reprenant sa date de fin de validité.
## Fonctionnement côté client
La cloche s'affiche dans l'en-tête via le hook `displayNav2`, à côté du panier et de « Mon compte ». Un badge rouge indique le nombre de notifications non lues (au-delà de neuf, il affiche `9+`). Au clic, un panneau déroulant liste les notifications, les plus prioritaires et les plus récentes en premier.
- **Marquer comme lu** : un bouton « Tout marquer comme lu » et une lecture automatique au clic sur une notification.
- **Bouton Copier** sur les codes promo.
- **Horodatage relatif** (« il y a 2 h », « hier »…).
- **Responsive** : le panneau s'affiche en bas de l'écran (bottom-sheet) sur mobile.
- **Accessibilité** : attributs ARIA et fermeture au clavier (touche Échap).
### État lu / non-lu
Pour les **clients connectés**, l'état lu / non-lu est stocké côté serveur, et donc partagé entre leurs appareils. Pour les **visiteurs non connectés**, il est mémorisé dans le navigateur via `localStorage`.
## Statistiques (KPI)
Chaque notification cumule un compteur de **vues** et de **clics**, visibles dans la liste du back-office. Vous repérez ainsi en un coup d'œil les notifications qui génèrent le plus d'engagement.
## Compatibilité PrestaShop 9
Le module est conçu et testé de PrestaShop 8.0 à 9.x :
- le contrôleur back-office utilise `ModuleAdminController`, compatible 8 et 9 ;
- les contrôleurs évitent les méthodes supprimées en PrestaShop 9 ;
- le contrôleur AJAX front renvoie directement du JSON via des méthodes `ajaxProcess`, sans override de signature incompatible ;
- aucun override du cœur de PrestaShop.
## FAQ et dépannage
### La cloche ne s'affiche pas dans l'en-tête
La cloche est greffée sur le hook `displayNav2` du thème Classic, là où se trouvent le panier et le compte client. Sur un thème personnalisé qui n'expose pas cet emplacement, greffez le module sur le hook utilisé par votre en-tête depuis **Modules > Gestionnaire de modules**, ou contactez-nous.
### Les nouveaux produits n'apparaissent pas
Vérifiez que l'option **Nouveaux produits automatiques** est activée. Si **Produits actifs uniquement** est coché, le produit doit être actif et visible. Un produit déjà notifié ne l'est pas une seconde fois.
### Le badge ne se met pas à jour pour un visiteur
Pour les visiteurs non connectés, l'état lu est conservé dans le navigateur. Vider le cache ou les données du site réinitialise cet état. Pour un suivi partagé entre appareils, le client doit être connecté.
### Le bouton Copier ne fonctionne pas
La copie utilise l'API presse-papiers du navigateur, disponible en HTTPS. Assurez-vous que votre boutique est servie en HTTPS ; une copie de secours est prévue, mais l'HTTPS garantit le meilleur fonctionnement.
### Comment traduire les notifications ?
Le titre, le message et le libellé du bouton sont des champs multilingues : sélectionnez chaque langue dans le formulaire de la notification. Les libellés d'interface se traduisent via **Paramètres avancés > Traductions > Traductions des modules installés**, en choisissant `dfnotificationcenter`.
### Est-ce compatible PrestaShop 9 ?
Oui. Le module est conçu et testé de PrestaShop 8.0 à 9.x, en mono-boutique comme en multiboutique.
## Désinstallation
La désinstallation supprime l'onglet back-office, les réglages et les trois tables du module (notifications, traductions, état de lecture). Pour conserver vos notifications, désactivez le module sans le désinstaller.
---
### Centre de Notifications pour Shopware 6 — Installation, configuration et documentation technique
_Source :_
> Présentation Le Centre de Notifications DataFirefly ajoute une cloche de notifications dans l'en-tête du storefront Shopware 6, juste à côté du panier. Un badge rouge indique le nombre de messages…
## Présentation
Le Centre de Notifications DataFirefly ajoute une **cloche de notifications** dans l'en-tête du storefront Shopware 6, juste à côté du panier. Un badge rouge indique le nombre de messages non lus (affiché « 9+ » au-delà de neuf) et un panneau déroulant présente vos annonces, nouveaux produits et codes promo.
Le plugin gère trois types de notifications : les **annonces** rédigées manuellement, les **notifications produit** créées automatiquement à chaque nouveau produit (image et lien résolus en temps réel) et les **codes promo** dotés d'un bouton « Copier ». Chaque notification peut être planifiée, ciblée par groupe client et par canal de vente, priorisée, et suivie via des KPI de vues et de clics.
Un seul plugin, un seul ZIP, compatible **Shopware 6.5, 6.6 et 6.7** — y compris l'administration basée sur Vite de la 6.7, livrée pré-compilée sans étape de build.
## Prérequis
- Shopware 6.5, 6.6 ou 6.7 (`shopware/core` ~6.5 || ~6.6 || ~6.7)
- Accès à la ligne de commande pour vider le cache et installer les assets
- Aucune dépendance externe, aucun service tiers
## Installation
1. Dans l'administration, allez dans **Extensions → Mes extensions → Téléverser l'extension** et sélectionnez le ZIP.
2. Installez puis **activez** le plugin.
3. Videz le cache et installez les assets :
```
bin/console plugin:refresh
bin/console plugin:install --activate DffNotificationCenter
bin/console assets:install
bin/console cache:clear
```
Après installation ou mise à jour, videz aussi le cache de votre navigateur (Ctrl+F5) sur la page d'administration pour recharger le module.
### Shopware 6.7 (administration Vite)
Le module d'administration est livré **pré-compilé** avec un fichier `entrypoints.json` Vite. Il se charge tel quel sur 6.5, 6.6 et 6.7 sans étape de build. Il suffit de relancer, après chaque mise à jour :
```
bin/console assets:install
bin/console cache:clear
```
## Configuration
Rendez-vous dans **Extensions → Mes extensions → Centre de Notifications → Configuration**. Les réglages sont scopables par canal de vente.
### Cloche de notifications
- **Activer la cloche** (défaut : oui) : affiche ou masque la cloche dans le storefront.
- **Nombre maximum de notifications affichées** (défaut : 10) : borné entre 1 et 50 côté serveur.
- **Rafraîchissement en arrière-plan** (défaut : 60 s) : intervalle de sondage, `0` pour désactiver.
- **Son** (défaut : non) : joue un son à la réception d'une notification.
- **Animation** (défaut : oui) : anime la cloche en présence de notifications non lues.
### Notifications produits automatiques
- **Créer une notification pour chaque nouveau produit** (défaut : oui).
- **Uniquement pour les produits actifs** (défaut : oui).
- **Expiration automatique** (défaut : 30 jours, `0` = jamais) : au-delà, la notification produit n'est plus diffusée.
### Notifications promo automatiques
- **Créer une notification à la création d'une promotion avec code** (défaut : **non**, à activer explicitement).
La notification promo est créée dès qu'une promotion **active** possède un **code global**. Par conception, les codes individuels ne sont jamais diffusés.
## Gérer les notifications dans l'administration
Le module de gestion se trouve dans **Marketing → Centre de Notifications**. Vous y créez, planifiez, ciblez et priorisez vos annonces, et vous consultez les KPI vues/clics.
Trois types sont disponibles :
- **Annonce** (`manual`) : titre, message, libellé de bouton et lien libres.
- **Produit** (`product`) : liée à un produit ; l'image de couverture et le lien vers la fiche sont résolus en temps réel à chaque affichage — jamais de lien cassé.
- **Code promo** (`promo`) : affiche un code avec un bouton « Copier » côté client.
### Planification, ciblage et priorité
- **Planification** : dates `validFrom` / `validUntil` ; une notification en dehors de sa fenêtre n'est pas diffusée.
- **Ciblage groupe client** : limite la diffusion à un groupe client donné (vide = tous).
- **Ciblage canal de vente** : limite à un canal (vide = tous), utile en multi-boutique.
- **Priorité** : entier ; les priorités les plus élevées s'affichent en premier, puis tri par date de création décroissante.
## Fonctionnement côté client
La cloche s'insère dans l'en-tête via une extension Twig (`sw_extends`). Si votre thème personnalise fortement l'en-tête, un _fallback_ JavaScript insère automatiquement la cloche à côté du panier.
Le panneau récupère les notifications via un appel AJAX. Le badge affiche le nombre de non-lus, avec son et animation optionnels et un rafraîchissement en arrière-plan configurable. L'interface est accessible : attributs ARIA, navigation clavier, et affichage en _bottom-sheet_ sur mobile.
**État de lecture :** pour les clients connectés, il est enregistré côté serveur (table `dff_notification_read`) et donc synchronisé entre appareils. Pour les invités, il reste dans le `localStorage` du navigateur — aucune donnée personnelle n'est collectée.
## Architecture technique
Le plugin suit les conventions Shopware : entités déclarées via la Data Abstraction Layer (DAL), contrôleur storefront renvoyant du JSON, subscribers d'événements et migration SQL. Aucun override — les templates sont étendus via `sw_extends`, le code est 100 % natif.
### Entités et Data Abstraction Layer
L'entité principale `dff_notification` (`NotificationDefinition`) porte les champs : `type`, `active`, `priority`, `validFrom`, `validUntil`, `customerGroupId`, `salesChannelId`, `productId` (+ `productVersionId`), `promotionId`, `promoCode`, `views` et `clicks`. Les champs traduisibles `title`, `message`, `buttonLabel` et `linkUrl` sont portés par l'entité de traduction `dff_notification_translation`.
Associations : `ManyToOne` vers `customer_group`, `sales_channel`, `product` et `promotion` ; `OneToMany` vers `dff_notification_read` (état de lecture par client). Les définitions sont enregistrées avec le tag `shopware.entity.definition` et exposées à l'API (`ApiAware`).
### Schéma de base de données
La migration `Migration1781049600NotificationCenter` crée trois tables :
- `dff_notification` : la notification, avec index sur `active` et sur `(product_id, product_version_id)`. Clés étrangères vers `customer_group` et `sales_channel` (`ON DELETE SET NULL`) et vers `product` (`ON DELETE CASCADE`).
- `dff_notification_translation` : traductions par langue (`title`, `message`, `button_label`, `link_url`).
- `dff_notification_read` : couples notification/client, avec index unique sur `(dff_notification_id, customer_id)` pour éviter les doublons de lecture.
### Routes AJAX du storefront
Les routes sont déclarées en XML (`Resources/config/routes.xml`) pour rester compatibles de Shopware 6.5 à 6.7 (Symfony 6.x et 7.x). Le contrôleur étend `AbstractController` — et non `StorefrontController` — car il ne renvoie que du JSON et `setTwig()` a disparu en 6.7.
- `GET /dff-nc/list` → `list()` : renvoie les notifications diffusables et incrémente leurs vues.
- `POST /dff-nc/read` → `markRead()` : marque comme lu côté serveur (clients connectés) ; pour les invités, la réponse indique un stockage `client`.
- `POST /dff-nc/click/{id}` → `click()` : incrémente le compteur de clics.
### Logique de diffusion (contrôleur list)
La requête DAL filtre les notifications `active = true`, dans leur fenêtre de validité (`validFrom` ≤ maintenant ≤ `validUntil`, bornes nulles admises), correspondant au canal de vente courant (ou nul) et au groupe client courant (ou nul), triées par priorité puis date décroissantes. Les produits liés sont ensuite résolus dynamiquement (association `cover.media`) : une notification produit dont le produit est supprimé ou indisponible dans le canal est masquée silencieusement. Les vues des notifications réellement délivrées sont incrémentées en une seule requête.
### Notifications automatiques (subscribers)
**ProductSubscriber** écoute `product.written`. À chaque _insert_ de produit sur la version _live_ (les variantes avec `parentId` sont ignorées), et si l'option est activée, il crée une notification de type `product` — en respectant le filtre « produits actifs uniquement », la durée de vie configurée (`validUntil`) et un contrôle anti-doublon par produit.
**PromotionSubscriber** écoute `promotion.written`. Comme l'administration crée d'abord la promotion puis renseigne le code et l'activation par mises à jour successives, il réagit aux _inserts_ et aux _updates_. Une notification `promo` n'est créée que si la promotion est **active** et possède un **code global**, avec report des dates `validFrom`/`validUntil` de la promotion et contrôle anti-doublon par promotion.
### Internationalisation
Trois langues sont livrées pour le storefront et l'administration : français, anglais et allemand (snippets `fr-FR`, `en-GB`, `de-DE`). Les titres et messages par défaut des notifications produit et promo sont générés via le service de traduction (clés `dffNc.*`).
## Confidentialité (RGPD)
Le plugin ne collecte aucune donnée personnelle. L'état de lecture des invités reste dans leur navigateur (`localStorage`) ; celui des clients connectés est stocké côté serveur et rattaché à leur compte. Les compteurs de vues et de clics sont agrégés au niveau de la notification, sans profil individuel.
## Désinstallation
À la désinstallation, les tables `dff_notification_read`, `dff_notification_translation` et `dff_notification` sont supprimées — **sauf** si l'option « conserver les données de l'utilisateur » est cochée, auquel cas elles sont laissées intactes.
## Dépannage
- **La cloche n'apparaît pas** : vérifiez que la cloche est activée dans la configuration, relancez `assets:install` et `cache:clear`, puis videz le cache navigateur. Le fallback JS s'insère à côté du panier si le thème surcharge l'en-tête.
- **Aucune notification produit créée** : l'option doit être activée, le produit doit être un produit racine (pas une variante) et, si le filtre est actif, être marqué actif.
- **Aucune notification promo créée** : l'option est désactivée par défaut ; la promotion doit être active et disposer d'un code global (les codes individuels ne sont pas diffusés).
- **Module d'administration non chargé sur 6.7** : relancez `assets:install` puis `cache:clear` et forcez le rechargement navigateur (Ctrl+F5).
---
### Checkout Simple & Élégant (dfsimplecheckout) — Guide complet
_Source :_
> Présentation DataFirefly Simple Checkout remplace le checkout 5 étapes natif de PrestaShop par un tunnel d'achat one-page moderne, inspiré des checkouts Shopify et Stripe. Le module monte son contrôleur au…
## Présentation
DataFirefly Simple Checkout remplace le checkout 5 étapes natif de PrestaShop par un tunnel d'achat one-page moderne, inspiré des checkouts Shopify et Stripe. Le module monte son contrôleur au runtime via le hook `actionDispatcher` — aucun fichier override n'est écrit sur disque, et vos overrides tiers existants sur `OrderController` sont hérités proprement.
Fonctionnalités principales : layout deux colonnes avec récapitulatif permanent, connexion sociale Google et Facebook, auto-complétion d'adresse Google Places, formulaire d'adresse adaptatif par pays, code promo AJAX, trois couleurs personnalisables, mode distraction-free.
## Installation
1. Dans votre back-office PrestaShop, allez dans **Modules → Gestionnaire de modules → Installer un module**.
2. Sélectionnez le fichier `dfsimplecheckout.zip` téléchargé depuis votre compte DataFirefly.
3. Cliquez sur **Installer** puis sur **Configurer**.
4. Videz le cache PrestaShop (**Paramètres avancés → Performance → Vider le cache**).
5. Visitez la page `/order` de votre boutique avec un produit au panier : le nouveau checkout s'affiche immédiatement.
Le module est compatible PrestaShop 8.0 → 9.x. Aucune modification de thème n'est requise. La désinstallation restaure automatiquement le checkout natif.
## Configuration générale
### Couleurs
Trois couleurs sont configurables dans l'onglet réglages du module :
- **Couleur principale** — boutons, liens, états actifs, radios sélectionnées (défaut `#1a73e8`).
- **Couleur hover des boutons** — état survol des boutons primaires « Continuer », « Commander » (défaut `#1559b8`).
- **Couleur accent / succès** — indicateurs d'étape complétée, pill de code promo appliqué, label « Gratuit » du transporteur, messages de succès (défaut `#008060`).
Les trois valeurs sont injectées comme variables CSS (`--dfsc-primary`, `--dfsc-primary-hover`, `--dfsc-success`) et validées par regex hexadécimal strict.
### Logo
Renseignez l'URL d'un logo personnalisé pour l'en-tête du checkout ; à défaut, le logo de la boutique est utilisé. Dimensions rendues : 190×42 px maximum.
### Mode distraction-free
L'option **Masquer le header et le footer du thème** (activée par défaut) supprime l'en-tête complet du thème (menu, recherche, panier) et son pied de page sur la page `/order` uniquement. L'implémentation surcharge les blocs Smarty `header` et `footer` dans notre template : sur un thème qui n'utilise pas ces blocs standards, l'option est simplement sans effet — jamais de page blanche.
### Autres options
- Champ note vendeur (on/off)
- Champ code promo (on/off)
- Badges de confiance — HTML libre affiché sous le récapitulatif
- Liens légaux en pied de checkout (CGV, confidentialité, retours — détectés via les rôles CMS natifs)
## Connexion sociale Google
### Créer les identifiants
1. Rendez-vous sur [Google Cloud Console](https://console.cloud.google.com/) et créez (ou sélectionnez) un projet.
2. Dans **APIs & Services → Credentials**, créez un **OAuth client ID** de type **Web application**.
3. Dans **Authorized JavaScript origins**, ajoutez l'URL de votre boutique (ex. `https://www.maboutique.fr`) — sans chemin, avec le protocole https.
4. Copiez le **Client ID** généré (se termine par `.apps.googleusercontent.com`).
### Configurer le module
1. Dans les réglages du module, activez **Google Sign-In** et collez le Client ID.
2. Enregistrez puis videz le cache.
3. Sur `/order`, le bouton Google apparaît au-dessus des onglets « Je suis un nouveau client / J'ai déjà un compte ».
Le flux : le client clique, sélectionne son compte Google, le module reçoit un jeton JWT qu'il valide côté serveur via le endpoint officiel `tokeninfo` (vérification de l'audience, de l'émetteur, de l'expiration et de l'email vérifié). Si un compte client existe avec cet email, il est connecté ; sinon un compte est créé automatiquement avec le nom et prénom du profil Google.
## Connexion sociale Facebook
### Créer l'application
1. Sur [Meta for Developers](https://developers.facebook.com/), créez une application de type **Consumer**.
2. Ajoutez le produit **Facebook Login** et déclarez votre domaine dans les paramètres.
3. Récupérez l'**App ID** et l'**App Secret** dans **Settings → Basic**.
### Configurer le module
Activez **Facebook Login** dans les réglages, collez App ID et App Secret, enregistrez. La validation serveur est en deux étapes : `debug_token` (vérifie que le jeton appartient bien à votre application) puis récupération du profil avec signature `appsecret_proof` (HMAC-SHA256). L'App Secret ne quitte jamais votre serveur.
## Auto-complétion d'adresse Google Places
1. Dans Google Cloud Console, activez les APIs **Places API** et **Maps JavaScript API**.
2. Créez une clé API et restreignez-la à votre domaine (recommandé).
3. Dans le module, activez **Auto-complétion d'adresse** et collez la clé.
Le champ « Adresse » du formulaire propose alors des suggestions pendant la frappe. La sélection d'une suggestion pré-remplit rue, complément, ville, code postal, pays et région le cas échéant. Les suggestions sont limitées aux pays actifs de votre boutique (jusqu'à 5 pays — limite de l'API Google).
L'API Places est facturée par Google au-delà du quota gratuit mensuel. Pour une boutique française à volume modéré, le quota gratuit est généralement suffisant.
## Formulaire d'adresse adaptatif par pays
Le formulaire d'adresse s'adapte automatiquement au pays sélectionné :
- Le pays par défaut du dropdown est celui configuré dans **International → Localisation** de votre back-office (et non le premier pays alphabétique).
- Le champ **État/Région** n'apparaît que pour les pays qui en comportent (USA, Espagne, Italie…) et son dropdown liste uniquement les régions actives du pays sélectionné.
- Le champ **DNI** apparaît pour les pays qui l'exigent (Espagne).
- La validation du code postal utilise le format du pays.
- Au changement de pays, la page se recharge avec le formulaire restructuré pour le nouveau pays.
### Édition d'adresse
Chaque adresse enregistrée affiche une icône crayon. Le clic ouvre le formulaire inline pré-rempli avec toutes les valeurs de l'adresse (chargées côté serveur avec contrôle de propriété — un client ne peut jamais consulter l'adresse d'un autre). La sauvegarde met à jour l'adresse existante, sans créer de doublon.
## Code promo
Le champ code promo (activable) fonctionne en AJAX : application et suppression sans rechargement, mise à jour instantanée du récapitulatif. Les opérations sont déléguées au contrôleur natif `CartController` de PrestaShop, donc toutes les règles panier (dates, montant minimum, restrictions transporteur, cumul) sont respectées à l'identique. Les messages d'erreur natifs (« Ce code a expiré », « Montant minimum non atteint »…) sont restitués tels quels.
## Compatibilité transporteurs et Colissimo
Le contenu extra des transporteurs (carte de points relais Colissimo, widget Mondial Relay…) est rendu via `{$carrier.extraContent}` comme dans le template natif. Pour Colissimo Points Relais, le module injecte automatiquement les informations du point sélectionné (identifiant, téléphone mobile) dans les requêtes de validation, ce qui élimine le faux message « Veuillez sélectionner un point de retrait » que le module Colissimo pouvait afficher sur les checkouts one-page.
## Hooks développeur
- `displayDfsimplecheckoutExpress` — slot en haut du checkout pour les paiements express (Apple Pay, Google Pay, PayPal Express).
- `displayDfsimplecheckoutSidebarTop` / `displayDfsimplecheckoutSidebarBottom` — zones d'injection dans la colonne récapitulatif.
- `actionDfscSocialLogin` — déclenché après une connexion sociale réussie, avec les paramètres `customer` et `dfsc_social_provider` (`google` ou `facebook`). Utile pour du tagging CRM.
## Dépannage
### Le bouton Google ne s'affiche pas
- Vérifiez que le Client ID est bien renseigné et l'option activée.
- Vérifiez dans la console navigateur qu'il n'y a pas d'erreur « origin not allowed » — dans ce cas, ajoutez l'URL exacte de votre boutique (avec https, sans slash final) dans les Authorized JavaScript origins de Google Cloud Console.
### La connexion sociale ne persiste pas
Videz le cache PrestaShop et le cache navigateur. Si le problème persiste, vérifiez qu'aucun module de sécurité tiers n'invalide les cookies de session après login.
### Le champ État affiche les mauvaises régions
Assurez-vous d'utiliser la version 1.2.20 ou supérieure du module, qui résout la structure du formulaire côté serveur pour chaque pays.
### Page blanche sur /order
Activez le mode debug PrestaShop (`_PS_MODE_DEV_`) pour afficher l'erreur, ou consultez `var/logs`. Vérifiez qu'aucun autre module de checkout one-page n'est actif simultanément.
## Désinstallation
Désinstallez le module depuis le Gestionnaire de modules. L'environnement runtime est libéré immédiatement et le checkout natif 5 étapes est restauré. Aucun fichier résiduel, aucune donnée orpheline.
---
### Commande Rapide B2B (Quick Order) — Guide complet
_Source :_
> Présentation Le module Commande Rapide B2B (dfquickorder) ajoute une page de saisie rapide où vos clients professionnels composent une commande directement à partir de leurs références (SKU), sans parcourir le…
## Présentation
Le module **Commande Rapide B2B** (`dfquickorder`) ajoute une page de saisie rapide où vos clients professionnels composent une commande directement à partir de leurs **références (SKU)**, sans parcourir le catalogue. Ils peuvent saisir les références une à une avec autocomplétion, **coller deux colonnes depuis Excel**, **importer un fichier CSV**, recharger une **liste de réachat** enregistrée ou **recommander une commande passée**, puis tout ajouter au panier en un clic.
Conçu pour le réassort B2B et les acheteurs pressés : un grossiste qui connaît ses références gagne un temps considérable par rapport à la navigation produit par produit. La grille résout chaque SKU en temps réel (nom, prix selon le groupe, stock, quantité minimum, déclinaison).
## Compatibilité
- PrestaShop 8.0 à 9.x
- PHP 7.4 à 8.3
- Mono-boutique et multi-boutique
- 5 langues : FR, EN, ES, DE, IT
- Thème Classic et thèmes personnalisés (grille en JavaScript natif, sans dépendance jQuery)
- Aucune dépendance (ni Composer ni framework)
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** puis sélectionnez le fichier `dfquickorder.zip`.
3. Une fois installé, cliquez sur **Configurer**.
À l'installation, le module crée sa table de listes de réachat, enregistre ses hooks (`displayCustomerAccount`, `displayNav2` et le hook personnalisé `displayQuickOrderBlock`) et initialise ses réglages par défaut. Un lien **Commande rapide** apparaît alors dans l'espace client.
## Configuration
### Accès et restriction
- **Groupes de clients autorisés** : laissez vide pour ouvrir la commande rapide à tout le monde, ou sélectionnez un ou plusieurs groupes pour la réserver à vos clients B2B. Les visiteurs non autorisés sont redirigés vers leur compte.
### Saisie et import
- **Séparateur CSV** : point-virgule, virgule, tabulation ou barre verticale, selon le format exporté par vos clients.
- **Nombre de lignes par défaut** : nombre de lignes vides affichées à l'ouverture de la grille.
- **Lignes maximum par CSV / collage** : garde-fou contre les imports trop volumineux ; les lignes au-delà de la limite sont ignorées avec un avertissement.
### Affichage et fonctionnalités
- **Afficher le prix et le sous-total** : affiche le prix unitaire, le total par ligne et le total estimé, calculés selon la méthode fiscale du groupe (HT ou TTC).
- **Collage depuis Excel** : active l'onglet de collage de deux colonnes (référence et quantité).
- **Listes de réachat** : active l'enregistrement et le rechargement de listes nommées par client.
- **Recommande en un clic** : active le rechargement d'une commande passée dans la grille.
- **Bouton « Convertir en devis »** : affiché uniquement si le module `dfb2bquote` est installé et actif (pont avec la gamme devis B2B).
## Utilisation
### La grille de saisie SKU
Le client saisit une référence : un menu d'autocomplétion propose les produits et déclinaisons correspondants (par référence ou par nom). À la validation, la ligne est résolue en temps réel et affiche le nom du produit, le libellé de la déclinaison, le prix unitaire selon son groupe, le total de ligne et un badge de statut. Une nouvelle ligne vide est ajoutée automatiquement au fur et à mesure.
### Les statuts de ligne
- **Vert** : référence valide, stock suffisant.
- **Orange** : quantité ajustée (stock partiel disponible, ou quantité minimum de vente atteinte).
- **Rouge** : référence inconnue, produit indisponible ou rupture de stock.
La résolution gère les **déclinaisons** : une référence de déclinaison renvoie le bon `id_product_attribute` et son libellé d'attributs. La recherche se fait sur la référence puis, en repli, sur le code-barres EAN13, en respectant la boutique courante et les produits actifs.
### Coller depuis Excel
Dans l'onglet **Coller depuis Excel**, le client colle deux colonnes (référence et quantité) directement depuis son tableur. Chaque ligne est analysée et résolue, puis injectée dans la grille avec son statut. Une éventuelle ligne d'en-tête (« sku », « référence »…) est détectée et ignorée.
### Import CSV
Dans l'onglet **Import CSV**, le client charge un fichier à deux colonnes. Le fichier est lu côté navigateur puis envoyé pour résolution. Un **modèle CSV** téléchargeable est fourni pour guider le format attendu. Le séparateur configuré dans le back-office est appliqué, avec repli automatique sur les séparateurs courants.
### Listes de réachat
Un client connecté peut **enregistrer la grille en cours comme liste nommée** (par exemple « Réassort mensuel ») et la recharger à tout moment depuis l'onglet **Mes listes**. Chaque liste appartient au client et à la boutique ; elle peut être chargée dans la grille ou supprimée.
### Recommander une commande passée
L'onglet **Recommander** liste les dernières commandes valides du client. Un clic recharge l'intégralité des références et quantités de la commande dans la grille, prêtes à être ajustées puis ajoutées au panier.
### Ajouter au panier et convertir en devis
Le bouton **Tout ajouter au panier** ajoute en une fois toutes les lignes valides au panier, en respectant les quantités. Si le module `dfb2bquote` est actif, le bouton **Convertir en devis** ajoute les lignes au panier puis bascule vers le parcours devis.
### Accès à la commande rapide
Le lien **Commande rapide** est disponible dans l'espace client. Vous pouvez aussi l'afficher dans la navigation haute et, via le hook personnalisé `displayQuickOrderBlock`, insérer un bloc d'appel à l'action où vous le souhaitez sur votre boutique.
## FAQ et dépannage
### La grille affiche une erreur « JSON invalide » ou ne résout pas les références
Videz le cache de PrestaShop (Paramètres avancés > Performances) et, pendant vos tests, désactivez la combinaison/compression des fichiers (CCC). Les réponses de la grille sont du JSON strict : le module purge toute sortie parasite avant de répondre, ce qui évite qu'un message PHP ne corrompe la réponse.
### Comment réserver la commande rapide à mes clients professionnels ?
Dans la configuration, sélectionnez le ou les groupes autorisés dans **Groupes de clients autorisés**. Tous les autres visiteurs n'auront pas accès à la page.
### Les déclinaisons sont-elles gérées ?
Oui. Une référence de déclinaison est résolue vers la bonne combinaison, avec son libellé d'attributs, son prix et son stock propres. Le code-barres EAN13 est également accepté comme référence.
### Que se passe-t-il si une quantité dépasse le stock ?
Selon le réglage de gestion des ruptures du produit, la quantité est ajustée au stock disponible (statut orange) ou la ligne est marquée en rupture (statut rouge). Les références introuvables sont signalées sans bloquer le reste de la grille.
### Les listes et la recommande nécessitent-elles un compte ?
Oui : l'enregistrement de listes et la recommande de commandes passées requièrent que le client soit connecté. La saisie SKU, le collage et l'import CSV fonctionnent aussi pour les visiteurs autorisés.
### Est-ce compatible PrestaShop 9 ?
Oui. Le module est compatible PrestaShop 8 et 9, en multi-boutique et multilingue (FR, EN, ES, DE, IT).
---
### Commandes Google Calendar (dfordercalendar)
_Source :_
> Présentation Commandes Google Calendar (dfordercalendar) crée automatiquement un événement dans votre agenda Google à chaque commande validée sur votre boutique PrestaShop 8 ou 9. L'événement contient la référence, le client,…
## Présentation
Commandes Google Calendar (dfordercalendar) crée automatiquement un événement dans votre agenda Google à chaque commande validée sur votre boutique PrestaShop 8 ou 9. L'événement contient la référence, le client, le total, le moyen de paiement, le transporteur, la liste des produits et l'adresse de livraison. La connexion utilise OAuth 2.0 avec vos propres identifiants Google Cloud : aucune donnée ne transite par un serveur tiers.
## Installation
1. Dans le back-office, ouvrez Modules puis Gestionnaire de modules.
2. Cliquez sur Installer un module et sélectionnez le fichier dfordercalendar.zip.
3. Une fois le module installé, cliquez sur Configurer.
Prérequis : PrestaShop 8.0 à 9.x, PHP 7.4 à 8.3 avec l'extension cURL active (présente sur la quasi-totalité des hébergements).
## Créer les identifiants Google (Google Cloud Console)
Le module se connecte à l'API Google Calendar avec des identifiants OAuth 2.0 que vous créez une seule fois, en une dizaine de minutes.
### 1. Créer un projet et activer l'API
1. Ouvrez [console.cloud.google.com](https://console.cloud.google.com/) et connectez-vous avec le compte Google qui possède l'agenda cible.
2. Créez un projet (par exemple « Boutique PrestaShop »).
3. Dans le menu, ouvrez API et services puis Bibliothèque, recherchez « Google Calendar API » et cliquez sur Activer.
### 2. Configurer l'écran de consentement
1. Ouvrez API et services puis Écran de consentement OAuth.
2. Choisissez le type Externe (ou Interne si vous êtes sur Google Workspace), renseignez le nom de l'application et votre email, puis enregistrez.
Tant que l'application reste en statut « En test », Google fait expirer la connexion au bout de 7 jours. Deux solutions : publier l'application (bouton Publier l'application, aucune validation n'est requise pour ce type d'usage) ou ajouter votre propre compte dans la liste des utilisateurs test puis publier plus tard. Pour un usage en production, publiez l'application.
### 3. Créer l'identifiant OAuth 2.0
1. Ouvrez API et services puis Identifiants, cliquez sur Créer des identifiants puis ID client OAuth.
2. Type d'application : Application Web.
3. Dans « URI de redirection autorisés », collez exactement l'URL affichée dans le panneau Connexion Google de la configuration du module (elle se termine par controller=oauth).
4. Validez : Google affiche votre Client ID et votre Client Secret.
L'URI de redirection doit être copiée à l'identique, protocole https compris. C'est la cause numéro 1 de l'erreur redirect_uri_mismatch.
## Connexion du module
1. Dans la configuration du module, collez le Client ID et le Client Secret, puis enregistrez.
2. Cliquez sur Connecter le compte Google : Google demande l'autorisation d'accéder à vos agendas.
3. Validez : un message confirme la connexion, revenez dans la configuration.
4. Dans Calendrier cible, choisissez l'agenda qui recevra les commandes (tous vos agendas accessibles en écriture sont listés, agendas partagés inclus), puis enregistrez.
Le jeton d'accès est renouvelé automatiquement, la connexion n'est à faire qu'une fois. Le bouton Déconnecter supprime les jetons à tout moment.
## Configuration des événements
### Modèle de titre
Le titre de l'événement est composé librement avec les variables suivantes :
- `{reference}` : référence de la commande
- `{customer}` : prénom et nom du client
- `{total}` : total TTC formaté dans la devise de la commande
- `{payment}` : moyen de paiement
- `{carrier}` : transporteur
- `{shop}` : nom de la boutique
Exemple : `Commande {reference} - {customer} ({total})`
### Type et contenu de l'événement
- Type d'événement : horodaté à la date et l'heure de la commande (durée réglable en minutes, fuseau horaire de la boutique) ou journée entière.
- Inclure la liste des produits : ajoute chaque ligne avec sa quantité dans la description.
- Inclure l'adresse de livraison : ajoutée dans la description et dans le champ lieu de l'événement.
- Inclure l'email et le téléphone du client : coordonnées ajoutées dans la description.
- Mettre à jour l'événement au changement de statut : ajoute le statut courant au titre à chaque changement d'état de la commande.
## Fonctionnement au quotidien
Dès qu'une commande est validée, l'événement est créé dans l'agenda cible. Sur la fiche commande du back-office, un encart Google Calendar affiche le lien direct vers l'événement, ou le statut de synchronisation en cas de problème.
Le bouton « Créer un événement de test depuis la dernière commande » permet de vérifier toute la chaîne sans attendre une vraie commande.
## Échecs et relance
Un échec d'appel à l'API Google ne bloque jamais la validation de la commande. L'échec est enregistré avec le message d'erreur exact renvoyé par Google et apparaît dans le panneau Synchronisations échouées de la configuration. Le bouton Relancer les événements en échec recrée tous les événements manquants en un clic. Les erreurs sont aussi tracées dans les logs PrestaShop (Paramètres avancés puis Logs).
## Dépannage
### redirect_uri_mismatch
L'URI de redirection déclarée dans Google Cloud Console ne correspond pas exactement à celle affichée par le module. Copiez-la à nouveau depuis la configuration, sans espace ni caractère manquant, et vérifiez le https.
### access_denied ou connexion expirée après 7 jours
Votre application OAuth est en statut « En test ». Publiez-la depuis l'écran de consentement OAuth (voir plus haut), puis reconnectez le compte.
### Erreur 403 : Google Calendar API has not been used
L'API Google Calendar n'est pas activée sur le projet. Retournez dans Bibliothèque, activez-la, patientez une minute puis relancez les événements en échec.
### Un agenda n'apparaît pas dans la liste
Seuls les agendas sur lesquels le compte connecté dispose d'un droit d'écriture sont listés. Pour un agenda partagé, demandez au propriétaire le droit « Apporter des modifications aux événements ».
## Données et désinstallation
Les jetons OAuth et le journal de synchronisation sont stockés dans la base de données de votre boutique. Les données de commande transitent uniquement entre votre serveur et l'API Google, en HTTPS. La désinstallation du module supprime les jetons, la configuration et la table de journal ; les événements déjà créés restent dans votre agenda Google.
---
### Commandes Récurrentes & Programmées — Documentation PrestaShop 8 & 9
_Source :_
> Ce que fait le module Le module permet à vos clients de programmer la répétition d'une commande depuis leur compte : toutes les semaines, tous les mois, tous les trimestres,…
## Ce que fait le module
Le module permet à vos clients de programmer la répétition d'une commande depuis leur compte : toutes les semaines, tous les mois, tous les trimestres, tous les ans, ou selon un intervalle libre exprimé en jours.
Avant chaque échéance, un planificateur envoie au client un e-mail contenant un lien sécurisé. Quand le client clique sur ce lien, son panier est reconstruit à cet instant précis, puis il est redirigé vers le tunnel de commande habituel où il règle avec le moyen de paiement de son choix.
**Aucun prélèvement automatique.** Le module ne stocke aucun moyen de paiement et ne déclenche aucun débit. Il n'y a donc ni mandat récurrent à collecter, ni carte à tokeniser, ni authentification forte à rejouer. Le client valide et règle chaque commande lui-même.
## Installation
1. Depuis le back-office, ouvrez _Modules — Gestionnaire de modules_, puis _Installer un module_.
2. Déposez le fichier ZIP fourni, ou copiez le dossier `dfrecurringorder` dans le répertoire `modules/` de votre boutique.
3. Cliquez sur _Installer_. Les tables, les onglets d'administration et les valeurs par défaut sont créés automatiquement.
4. Configurez la tâche planifiée, décrite à la section suivante. Sans elle, aucun e-mail de rappel ne partira.
Le module ajoute un menu _Commandes — Commandes programmées_, composé de trois écrans : la liste des programmations, l'historique des envois et la configuration.
## Configurer le planificateur
Le module doit être appelé une fois par jour. Une seule exécution quotidienne suffit : le planificateur traite en un passage toutes les programmations arrivées à échéance.
### Par URL
La page de configuration du module affiche l'URL exacte, jeton inclus. Elle ressemble à ceci :
```
https://votre-boutique.tld/module/dfrecurringorder/cron?token=VOTRE_JETON
```
Cette URL est utilisable avec le module officiel _Tâches cron_ de PrestaShop, avec un service de cron externe, ou depuis une crontab serveur :
```
0 6 * * * wget -q -O - "https://votre-boutique.tld/module/dfrecurringorder/cron?token=VOTRE_JETON"
```
### En ligne de commande
C'est la méthode recommandée sur un serveur dédié : elle évite les délais d'exécution du serveur web.
```
0 6 * * * php /chemin/vers/boutique/modules/dfrecurringorder/cli/run.php --token=VOTRE_JETON
```
L'option `--id_shop=N` restreint l'exécution à une seule boutique en contexte multiboutique. Sans cette option, toutes les boutiques sont traitées.
### Vérifier que tout fonctionne
La page de configuration propose un bouton _Exécuter le planificateur maintenant_. Il déclenche un passage immédiat et affiche un compte rendu : nombre de programmations traitées, e-mails envoyés et échecs éventuels. L'appel par URL renvoie le même compte rendu au format JSON.
Le jeton peut être régénéré à tout moment depuis la page de configuration. Pensez alors à mettre à jour votre crontab, sinon les appels suivants seront rejetés.
## Configuration du module
### Expérience client
- **Autoriser les clients à créer leurs programmations** — affiche le bouton « Programmer cette commande » sur le détail de commande et la page de confirmation. Désactivez cette option si vous préférez créer les programmations vous-même depuis le back-office.
- **Nombre maximum de programmations par client** — 0 pour illimité. La valeur par défaut est 20.
- **Intervalle minimum en jours** — empêche la création de programmations trop rapprochées.
- **Jeu d'icônes du thème** — les icônes affichées dans l'espace client. Le thème Classic de PrestaShop utilise Material Icons, tandis que beaucoup de thèmes commerciaux chargent FontAwesome. Choisissez celui que votre thème charge réellement, ou aucune icône. Une icône manquante ou remplacée par un mot dans l'espace client signifie simplement que ce réglage ne correspond pas à votre thème.
- **Produits exclus des commandes programmées** — une liste d'identifiants produits séparés par des virgules. Ces produits ne sont jamais recopiés dans une programmation, ni ajoutés à un panier reconstruit. Voir la section sur les cadeaux et les règles panier.
### Fréquences disponibles
Chaque fréquence s'active ou se désactive indépendamment : quotidienne, hebdomadaire, bimensuelle, mensuelle, bimestrielle, trimestrielle, semestrielle, annuelle et personnalisée en jours. Seules les fréquences activées apparaissent dans le formulaire du client.
Par défaut, les fréquences hebdomadaire, bimensuelle, mensuelle, bimestrielle, trimestrielle, semestrielle et annuelle sont actives. La fréquence quotidienne et l'intervalle personnalisé sont désactivés, car ils conviennent surtout à des cas B2B spécifiques.
### E-mails et lien de paiement
- **Envoyer l'e-mail X jours avant l'échéance** — valeur par défaut appliquée aux nouvelles programmations. Le client peut ajuster ce délai pour la sienne. Trois jours est un bon point de départ : assez tôt pour laisser le temps de réagir, assez tard pour rester dans l'esprit du client.
- **Durée de validité du lien de paiement** — en jours, 14 par défaut. Passé ce délai, le lien affiche un message d'expiration et invite le client à en régénérer un depuis son compte.
- **Ignorer les produits indisponibles** — activé par défaut. Voir la section sur les cas particuliers.
- **Envoyer une copie au marchand** — utile pendant la phase de rodage pour vérifier le rendu réel des e-mails.
### Planificateur
- **Programmations traitées par exécution** — 50 par défaut. Augmentez cette valeur si votre volume dépasse cette limite quotidienne, ou lancez le cron plusieurs fois par jour.
- **Supprimer toutes les données à la désinstallation** — désactivé par défaut. Voir la section Désinstallation.
## Proposer la récurrence pendant la commande
Par défaut, le client programme sa commande après coup, depuis une commande déjà passée. Deux options facultatives permettent de lui proposer la récurrence plus tôt, au moment où il achète. Les deux sont désactivées à l'installation : les activer est une décision, pas un effet de bord d'une mise à jour.
### Option dans le tunnel de commande
Une case « Transformer cet achat en commande récurrente » s'affiche dans le panier et en haut de l'étape de paiement, suivie d'un sélecteur de fréquence qui ne propose que les fréquences que vous avez activées. Le client coche, choisit son rythme, et poursuit sa commande normalement.
Le choix est enregistré sur le panier, pas dans la session. C'est important avec les moyens de paiement qui redirigent le client vers une page externe : la commande y est souvent validée dans un retour de paiement où la session du client n'existe plus, et un choix conservé en session serait perdu sans la moindre alerte.
La programmation n'est créée qu'une fois la commande validée. Adresses, transporteur et devise proviennent donc d'une commande réelle, et une nouvelle tentative de paiement ne peut pas créer deux programmations. La première échéance est calculée à partir de la date de la commande, selon la fréquence choisie.
L'option n'apparaît que pour les clients connectés, puisqu'une programmation appartient à un compte client. Elle respecte également le quota de programmations par client et la liste des produits exclus.
### Encart sur la fiche produit
Un court encart signale au visiteur que le produit peut être commandé de façon récurrente et explique le principe en deux phrases, sans jargon. Les produits figurant dans la liste d'exclusion ne l'affichent jamais.
### Si rien ne s'affiche
Ces deux affichages reposent sur des points d'accroche standards de PrestaShop. Certains thèmes, et surtout les modules de commande en une page, ne les fournissent pas tous. La page de configuration du module liste ces points d'accroche avec leur état et propose un bouton pour les enregistrer à nouveau. Si l'un d'eux reste inactif après cette tentative, c'est que votre thème ou votre module de commande ne l'expose pas.
## Côté client : programmer une commande
Le parcours part toujours d'une commande déjà passée, ce qui garantit que les produits, l'adresse et le transporteur sont cohérents.
1. Le client ouvre l'une de ses commandes depuis son historique, ou reste sur la page de confirmation juste après un achat.
2. Il clique sur _Programmer cette commande_.
3. Il ajuste les quantités si besoin. Une quantité fixée à 0 retire le produit de la programmation.
4. Il choisit sa fréquence, la date de sa prochaine commande et, s'il le souhaite, une date de fin ou un nombre maximum de commandes.
5. Il enregistre. Un e-mail de confirmation récapitule la programmation.
La programmation apparaît ensuite dans _Mon compte — Mes commandes programmées_. Depuis cet écran, le client peut à tout moment :
- modifier la fréquence, la date ou les quantités ;
- mettre en pause puis réactiver, la prochaine échéance étant alors recalculée dans le futur ;
- supprimer définitivement la programmation ;
- cliquer sur _Commander maintenant_ pour déclencher immédiatement son panier sans attendre l'échéance.
## Côté marchand : suivre les programmations
### Liste des commandes programmées
Elle affiche pour chaque programmation le client, la fréquence, le nombre de produits, la prochaine échéance, le nombre d'e-mails déjà envoyés, le nombre de commandes réellement passées et le statut. La colonne des commandes est la mesure la plus utile : elle indique combien de programmations se transforment effectivement en chiffre d'affaires.
La fiche détaillée d'une programmation permet d'envoyer immédiatement le lien de paiement au client, ce qui est pratique en support quand un client signale ne pas avoir reçu son e-mail.
### Historique des envois
Chaque lien généré donne lieu à une ligne d'historique dont le statut évolue au fil du parcours :
- **Envoyé** — l'e-mail est parti, le lien n'a pas encore été ouvert.
- **Lien ouvert** — le client a cliqué, un panier a été construit.
- **Transformé en commande** — le panier est devenu une commande. La référence de commande est rattachée automatiquement.
- **Expiré** — la durée de validité est dépassée sans commande.
- **Erreur** — l'envoi de l'e-mail a échoué. Vérifiez la configuration e-mail de la boutique.
### Dans la fiche commande
Un panneau au bas de la fiche commande liste les programmations créées à partir de cette commande, avec un accès direct à leur détail.
## Comment fonctionne le lien de paiement
Comprendre ce mécanisme aide à répondre aux questions de vos clients.
1. À l'envoi de l'e-mail, le module ne crée aucun panier. Il génère uniquement un jeton aléatoire de 48 caractères, à usage unique et daté.
2. Quand le client clique, le module vérifie le jeton et sa date d'expiration.
3. Si le client n'est pas connecté, il est redirigé vers la page de connexion standard puis ramené automatiquement sur son lien. Le lien n'authentifie jamais le visiteur par lui-même.
4. Une fois le client identifié, le panier est construit à partir de la programmation, avec les prix, promotions, règles panier et stocks du moment.
5. Le client est redirigé vers le tunnel de commande. Un second clic sur le même lien réutilise le panier déjà créé tant qu'il n'a pas donné lieu à une commande.
C'est parce que le panier est construit au clic, et non à l'envoi, qu'il reste toujours juste. Un panier pré-généré au moment de l'e-mail deviendrait faux dès qu'un prix, une promotion ou un stock évolue entre l'envoi et le clic.
## Cas particuliers
### Produit indisponible à l'échéance
Avec l'option _Ignorer les produits indisponibles_ activée, le produit concerné est simplement écarté et les autres articles restent commandables. Le panier n'est refusé que si aucun produit n'est disponible : le client voit alors un message l'invitant à vous contacter ou à modifier sa programmation.
Si vous désactivez cette option, une rupture bloque la reconstitution du panier. Ce comportement convient aux boutiques dont les commandes doivent partir complètes ou pas du tout.
### Adresse supprimée entre deux échéances
Si l'adresse de livraison enregistrée dans la programmation a été supprimée par le client, le module bascule automatiquement sur sa première adresse disponible. L'adresse de facturation suit la même logique. Le client peut toujours changer d'adresse dans le tunnel de commande.
### Cadeaux et règles panier
Un produit offert par une règle panier n'est jamais recopié dans la programmation. C'est volontaire : le cadeau n'a pas été choisi par le client, et la règle panier l'ajoute d'elle-même à chaque reconstruction du panier dès que les conditions sont remplies. Le conserver dans la programmation le ferait apparaître deux fois.
Le cadeau continue donc à être offert normalement à chaque échéance, et il suit l'état courant de votre règle : si vous modifiez le seuil ou changez le produit offert, la commande programmée en tient compte immédiatement.
Si un cadeau est ajouté par un module tiers plutôt que par une règle panier native, la détection automatique ne peut pas le reconnaître. Ajoutez alors son identifiant produit dans le réglage _Produits exclus des commandes programmées_. Cette exclusion s'applique aussi aux programmations existantes, sans que vos clients aient à les recréer.
### Fins de mois
Une programmation mensuelle démarrée un 31 janvier ne dérive pas. Le module ramène la date au dernier jour du mois quand celui-ci est plus court : le 28 ou 29 février, puis le 31 mars. Le jour d'origine est mémorisé, il n'est donc jamais perdu.
### Multiboutique
Chaque programmation est rattachée à la boutique sur laquelle elle a été créée. Les e-mails partent avec l'identité de cette boutique, et le lien de paiement pointe vers son domaine.
### Fin d'une programmation
Une programmation se termine automatiquement lorsque la date de fin est dépassée ou lorsque le nombre maximum de commandes est atteint. Elle passe alors au statut _Terminée_ et cesse d'envoyer des e-mails, tout en restant consultable dans l'historique.
## Personnaliser les e-mails
Le module fournit deux modèles, déclinés en version HTML et texte, dans sept langues : français, anglais, espagnol, italien, portugais, allemand et polonais :
- `dfro_reminder` — le rappel envoyé avant chaque échéance, avec le lien de paiement.
- `dfro_created` — la confirmation envoyée à la création d'une programmation.
Ils sont modifiables depuis _Design — Thème et logo — E-mails_, ou directement dans le dossier `mails/` du module. Les variables disponibles dans le rappel sont : prénom et nom du client, libellé et fréquence de la programmation, date de la prochaine commande, tableau des produits, total estimé, lien de paiement, lien de gestion, durée de validité du lien et nom de la boutique.
Le total affiché dans l'e-mail est une estimation calculée à l'envoi, à titre indicatif. Le montant réellement facturé est celui du panier reconstruit au clic. Ne présentez donc jamais ce total comme un engagement de prix.
## Dépannage
### Aucun e-mail n'est envoyé
Vérifiez dans l'ordre : que la tâche planifiée s'exécute bien, que le jeton de la crontab correspond à celui affiché en configuration, qu'au moins une programmation est active avec une échéance atteinte, et que l'envoi d'e-mails de la boutique fonctionne. Le bouton _Exécuter le planificateur maintenant_ permet d'isoler rapidement le problème : s'il envoie les e-mails, c'est la tâche planifiée qui est en cause.
### Le lien affiche « Lien invalide »
Le jeton n'existe pas ou a été tronqué par le client de messagerie. Régénérez un lien depuis la fiche de la programmation en back-office.
### Le client tourne en boucle sur la page de connexion
Cela se produit quand le lien est ouvert avec un compte différent de celui du destinataire. Le client doit se déconnecter, puis rouvrir le lien.
### Le panier reconstruit est vide
Tous les produits de la programmation sont désactivés ou en rupture. Vérifiez leur état dans le catalogue, ou désactivez temporairement l'option d'exclusion des produits indisponibles pour rendre le diagnostic explicite.
## Désinstallation
Par défaut, la désinstallation conserve les tables et les programmations. Une réinstallation ultérieure retrouve donc l'intégralité des données. Pour tout supprimer, activez l'option _Supprimer toutes les données à la désinstallation_ avant de désinstaller le module.
Cette suppression est définitive et concerne les programmations, leurs lignes produits et l'historique complet des envois. Faites une sauvegarde de votre base avant de l'activer.
---
### Compteur de Paniers Shopware 6 : installation et configuration
_Source :_
> Le plugin DfCartPopularity affiche sur la fiche produit un badge indiquant le nombre de paniers contenant actuellement le produit, par exemple « Dans + de 20 paniers ». Le comptage…
Le plugin **DfCartPopularity** affiche sur la fiche produit un badge indiquant le nombre de paniers contenant actuellement le produit, par exemple « Dans + de 20 paniers ». Le comptage repose sur vos vraies données de panier.
## Prérequis
- Shopware 6.5, 6.6 ou 6.7 en installation auto-hébergée (le SaaS Shopware Cloud n'accepte pas les plugins serveur)
- PHP 8.1 ou supérieur
- Accès SSH pour les commandes console et la compilation du thème
## Installation
Déposez le ZIP via Extensions puis Mes extensions, ou copiez le dossier dans `custom/plugins/`, puis lancez :
```
bin/console plugin:refresh
bin/console plugin:install --activate DfCartPopularity
bin/console cache:clear
./bin/build-storefront.sh
```
La compilation du storefront est nécessaire une fois, pour intégrer la feuille de style du badge. Sur un environnement piloté par un pipeline de déploiement, cette étape fait généralement déjà partie du processus standard.
## Amorcer l'index
À l'installation, l'index est vide : les compteurs partent de zéro et se remplissent à mesure que les clients modifient leur panier. Pour afficher des chiffres crédibles dès le premier jour, lancez la reconstruction :
```
bin/console df:cart-popularity:rebuild
```
La commande lit les paniers déjà stockés dans la boutique et alimente l'index. Elle est idempotente et peut être relancée sans risque. L'option `--truncate` vide l'index avant reconstruction.
Les paniers déjà transformés en commande sont supprimés par Shopware de la table des paniers. La reconstruction ne voit donc que les paniers actifs, ce qui est exactement le périmètre attendu.
## Configuration
Paramètres, Système, Plugins, DataFirefly Cart Popularity, puis Configurer. Chaque option est surchargeable canal de vente par canal de vente.
### Affichage
- **Activer le badge** : le suivi des paniers continue même badge désactivé, les données sont donc prêtes le jour où vous l'activez.
- **Seuil minimum** (défaut 5) : en dessous de ce nombre de paniers, rien ne s'affiche.
- **Mode d'affichage** : palier arrondi ou nombre exact.
- **Pas du palier** (défaut 10) : un comptage de 23 s'affiche en « + de 20 ». Si le comptage est inférieur au pas, le plugin bascule automatiquement sur le nombre exact plutôt que d'annoncer un palier faux.
- **Emplacement** : au-dessus ou sous le bloc d'achat.
- **Style du badge** : fond léger, contour ou texte simple.
### Règles de comptage
- **Fenêtre temporelle** (défaut 7 jours) : seuls les paniers mis à jour dans cette fenêtre sont comptés. La valeur 0 désactive la fenêtre.
- **Paniers actifs uniquement** : exclut les paniers déjà transformés en commande.
- **Limiter au canal de vente** : évite qu'un pic sur une boutique gonfle le compteur d'une autre.
- **Agréger les déclinaisons** : toutes les variantes d'un produit partagent le compteur du parent. Désactivez cette option si chaque déclinaison doit avoir son propre compteur.
### Performance et rétention
- **Durée de vie du cache** (défaut 900 secondes) : la requête de comptage n'est exécutée qu'une fois par durée de vie et par produit. La valeur 0 désactive le cache. Le cache est vidé automatiquement à chaque enregistrement de la configuration.
- **Rétention** (défaut 60 jours) : les enregistrements plus anciens sont supprimés. Le nettoyage s'exécute automatiquement, au maximum une fois par heure, sans dépendre du message queue.
## Personnaliser le texte
Le libellé du badge vit dans les snippets Shopware. Paramètres, Snippets, puis recherchez `dfCartPopularity`. Trois clés sont disponibles :
- `dfCartPopularity.badge.textTier` : mode palier, contient le placeholder du nombre
- `dfCartPopularity.badge.textExact` : mode exact, contient le placeholder du nombre
- `dfCartPopularity.badge.textSingular` : mode exact avec un seul panier
Le placeholder s'écrit `%count%` et doit être conservé dans votre formulation. Les traductions anglaise, allemande, française, espagnole, italienne et polonaise sont fournies.
## Comment fonctionne le comptage
Shopware sérialise le panier complet dans une colonne payload de la table `cart`, souvent compressée. Aucune requête SQL ne peut donc savoir ce que contient un panier sans le désérialiser. Le plugin maintient sa propre table `df_cart_popularity` associant un jeton de panier, un produit, un canal de vente, une quantité et un indicateur de commande.
Cette table est synchronisée à chaque persistance de panier via `CartSavedEvent`, en deux requêtes indexées. L'événement `CartConvertedEvent` marque les lignes comme commandées au moment du passage en commande. L'affichage effectue alors un simple comptage distinct sur un index composite, mis en cache.
Aucune donnée personnelle n'est enregistrée : l'index ne contient que le jeton de panier, qui est un identifiant technique pseudonyme, la référence produit, le canal de vente et des horodatages.
## Commandes CLI
```
bin/console df:cart-popularity:rebuild
bin/console df:cart-popularity:rebuild --truncate
bin/console df:cart-popularity:cleanup
bin/console df:cart-popularity:cleanup --days=30
```
## Dépannage
### Le badge ne s'affiche pas
Vérifiez dans l'ordre : le badge est activé pour le canal de vente concerné, le nombre de paniers atteint le seuil, la fenêtre temporelle n'exclut pas tous les paniers, et le storefront a bien été recompilé après l'installation. Videz aussi le cache HTTP si la page est servie depuis le cache.
### Le badge s'affiche sans style
La feuille de style du plugin est intégrée à la compilation du thème. Relancez `./bin/build-storefront.sh` ou `bin/console theme:compile`.
### La commande de reconstruction indique des paniers ignorés
Ces paniers utilisent un format de payload que la commande ne sait pas lire, typiquement un stockage de panier externalisé. Ils seront indexés normalement dès la prochaine modification par le client, le suivi par événement fonctionnant indépendamment du mode de stockage.
## Désinstallation
La désinstallation avec suppression des données utilisateur supprime la table `df_cart_popularity` et la configuration du plugin. En conservant les données utilisateur, la table reste en place et les compteurs repartent tels quels en cas de réinstallation.
---
### Compteur de Ventes — Guide complet
_Source :_
> Présentation Le module Compteur de Ventes affiche, sur la fiche produit, le nombre de fois qu'un produit a déjà été vendu. Le message est généré automatiquement à partir des lignes…
## Présentation
Le module Compteur de Ventes affiche, sur la fiche produit, le nombre de fois qu'un produit a déjà été vendu. Le message est généré automatiquement à partir des lignes de commande réelles de votre boutique : aucune saisie manuelle, aucune donnée inventée. C'est un levier de réassurance simple et efficace, qui rassure l'acheteur hésitant en lui montrant qu'un article a déjà convaincu d'autres clients.
Le module est compatible PrestaShop 8 et 9, en mono comme en multiboutique, et multilingue. Le rendu est effectué côté serveur, sans dépendance Composer ni JavaScript externe.
## Installation
1. Depuis le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez l'archive ZIP du module.
3. Une fois l'installation terminée, cliquez sur **Configurer**.
À l'installation, le module enregistre ses réglages par défaut et s'accroche aux emplacements d'affichage de la fiche produit. Aucun produit technique ni table supplémentaire n'est créé : le compteur lit directement les commandes existantes.
## Configuration
### Activer l'affichage
L'interrupteur **Activer l'affichage** contrôle l'affichage global du badge sur les fiches produit. Désactivez-le pour masquer temporairement le compteur sans désinstaller le module.
### Méthode de comptage
Deux méthodes sont disponibles :
- **Quantité totale vendue** : le module additionne toutes les quantités commandées du produit (somme des quantités). Cette méthode met en avant le volume écoulé.
- **Nombre de commandes** : le module compte le nombre de commandes distinctes ayant inclus le produit. Cette méthode met en avant le nombre de clients différents convaincus.
### Commandes valides uniquement
Lorsque cette option est activée (recommandé), seules les commandes valides — c'est-à-dire payées — sont comptées. Désactivez-la pour comptabiliser toutes les commandes, quel que soit leur état de paiement.
### Seuil minimum d'affichage
Définissez un **seuil minimum** en dessous duquel aucun badge n'est affiché. Cela évite de montrer un chiffre trop faible et garantit un message toujours valorisant. La valeur 0 affiche le badge dès la première vente.
### Emplacement d'affichage
Choisissez où le badge apparaît sur la fiche produit :
- **Sous le bloc d'achat** (infos additionnelles produit).
- **Près des boutons d'achat**.
Les deux emplacements sont enregistrés à l'installation ; seul l'emplacement sélectionné effectue le rendu, il n'est donc pas nécessaire de réinstaller le module pour en changer.
### Texte affiché
Le **texte affiché** est personnalisable et traduisible par langue. Utilisez le marqueur `{sales}` pour insérer le nombre à l'endroit de votre choix dans la phrase. Par exemple : `Déjà vendu {sales} fois`. Si le marqueur est absent, le nombre est ajouté automatiquement à la fin du texte.
## Côté client
Sur la fiche produit, le badge s'affiche à l'emplacement choisi avec le texte configuré et le nombre de ventes calculé. Aucun script n'est chargé côté client : le contenu est généré côté serveur, ce qui le rend compatible avec la mise en cache des pages.
## Multiboutique
En contexte multiboutique, le comptage est automatiquement restreint à la boutique courante : chaque boutique affiche ses propres chiffres de ventes pour un même produit.
## Performance
Le compteur s'appuie sur une requête légère utilisant l'index existant sur l'identifiant produit des lignes de commande. Sur les boutiques à fort catalogue, l'affichage reste rapide. Si votre trafic est très élevé, l'activation d'un cache de pages au niveau de votre serveur ou de PrestaShop bénéficie directement au module, le rendu étant entièrement côté serveur.
## Désinstallation
La désinstallation du module supprime l'ensemble de ses réglages et retire le badge des fiches produit. Aucune donnée de commande n'est modifiée : le module ne fait que lire les ventes existantes.
## FAQ
### Sur quelles données repose le compteur ?
Sur les lignes de commande réelles contenant le produit. Vous pouvez limiter le comptage aux commandes valides, et il est automatiquement restreint à la boutique courante en multiboutique.
### Le module compte-t-il les quantités ou les commandes ?
Au choix. Le mode quantité additionne toutes les quantités vendues ; le mode commandes compte le nombre de commandes distinctes ayant inclus le produit. Le mode se règle dans la configuration.
### Comment éviter d'afficher un chiffre trop faible ?
Définissez un seuil minimum d'affichage : en dessous de ce nombre de ventes, aucun badge n'est affiché.
### Le texte est-il traduisible ?
Oui, intégralement, par langue, avec le marqueur `{sales}` pour positionner le nombre. Les traductions FR, EN, ES, DE et IT sont fournies.
### Le module est-il compatible PrestaShop 9 ?
Oui, le module est compatible PrestaShop 8.x et 9.x, en mono comme en multiboutique, sans dépendance Composer ni JavaScript externe.
---
### Compteur de Ventes Shopware 6 : guide d'installation et de configuration
_Source :_
> Ce guide couvre l'installation, la configuration et la personnalisation du plugin DfSalesCounter, qui affiche sur chaque fiche produit le nombre de fois qu'un produit a déjà été vendu, à partir…
Ce guide couvre l'installation, la configuration et la personnalisation du plugin **DfSalesCounter**, qui affiche sur chaque fiche produit le nombre de fois qu'un produit a déjà été vendu, à partir des commandes réelles de votre boutique Shopware 6.
## Prérequis
- Shopware 6.5.x, 6.6.x ou 6.7.x en installation auto-hébergée. Shopware Cloud (SaaS) n'accepte pas les plugins serveur.
- PHP 8.1 ou supérieur.
- Un thème storefront dérivé du thème Storefront de Shopware, ou un thème personnalisé qui conserve les blocs Twig standards du bloc d'achat.
- Un accès en ligne de commande est recommandé pour la compilation du thème, mais l'installation par l'administration fonctionne également.
## Installation
### Par upload ZIP depuis l'administration
1. Dans l'administration Shopware, ouvrez _Extensions_, puis _Mes extensions_.
2. Cliquez sur _Téléverser l'extension_ et sélectionnez le fichier `DfSalesCounter-1.0.0.zip`.
3. Une fois le plugin listé, cliquez sur _Installer_, puis activez-le avec l'interrupteur.
4. Recompilez le thème depuis _Contenus_, _Thèmes_, en sélectionnant votre thème puis _Recompiler le thème_. Cette étape est nécessaire une seule fois, car le plugin fournit une feuille de style storefront.
### Par ligne de commande
Déposez le dossier `DfSalesCounter` dans `custom/plugins/` de votre installation, puis lancez :
```
bin/console plugin:refresh
bin/console plugin:install --activate DfSalesCounter
bin/console theme:compile
bin/console cache:clear
```
Sur un environnement disposant d'un pipeline de déploiement, la compilation du thème fait généralement déjà partie des étapes standard.
## Configuration
La page de configuration se trouve dans _Extensions_, _Mes extensions_, bouton _..._ à droite de DataFirefly Sales Counter, puis _Configurer_. Le sélecteur en haut de page permet de choisir le canal de vente auquel s'applique la configuration : chaque canal peut avoir son propre seuil, son propre texte et son propre emplacement.
### Onglet Général
- **Activer le compteur de ventes** : interrupteur principal. Désactivé, aucune requête n'est exécutée et aucun badge n'est rendu.
- **Mode de comptage** : _Quantité vendue_ additionne toutes les quantités commandées du produit. _Nombre de commandes_ compte les commandes distinctes ayant inclus le produit. Le premier mode met en avant le volume, le second le nombre de clients différents convaincus.
- **Commandes prises en compte** : _Toutes les commandes_ donne le chiffre brut. _Exclure les commandes annulées_ écarte celles dont l'état machine est `cancelled`. _Commandes payées uniquement_ ne conserve que les commandes disposant d'une transaction en état `paid` ou `paid_partially`.
- **Seuil minimum avant affichage** : en dessous de cette valeur, aucun badge n'apparaît. La valeur par défaut est 5. Un seuil de 0 est traité comme 1, le badge n'est jamais rendu pour un produit sans vente.
- **Période en jours** : limite le comptage aux X derniers jours, sur la base de la date de commande. La valeur 0 signifie un cumul depuis toujours.
- **Cumuler les ventes de toutes les déclinaisons** : additionne les ventes du produit parent et de l'ensemble de ses variantes. Recommandé sur un catalogue mode ou taille, à désactiver si chaque variante correspond à un usage distinct.
- **Compter uniquement les commandes du canal de vente courant** : évite qu'une boutique B2B ou un canal export gonfle les chiffres affichés sur la boutique grand public.
### Onglet Affichage
- **Emplacement sur la fiche produit** : _Sous le nom du produit_, _Sous le prix_, ou _Sous le bloc d'achat_, c'est-à-dire en bas du bloc, sous le bouton d'ajout au panier.
- **Style visuel** : _Badge_ rend une pilule bordée, _Texte simple_ rend une ligne sans encadrement, _Bandeau_ rend un bloc pleine largeur avec une barre latérale colorée.
- **Icône** : flamme, panier, coche, ou aucune. Les icônes sont des SVG rendus en ligne, aucune police d'icônes n'est chargée.
- **Couleur d'accent** : laissée vide, la couleur primaire du thème est utilisée. Renseignée, elle alimente la variable CSS `--df-sales-counter-accent` sur l'élément du badge.
- **Séparateur de milliers** : espace fine, virgule, point ou aucun. Utile dès que les compteurs dépassent le millier.
- **Texte personnalisé** : voir la section suivante.
- **Durée de cache en secondes** : 900 par défaut. La valeur 0 désactive le cache et interroge la base à chaque affichage de fiche.
## Personnaliser le texte
### Texte global depuis la configuration
Le champ _Texte personnalisé_ accepte une phrase avec le marqueur `%count%` à l'endroit où le nombre doit apparaître. Exemple : `Ce modèle est parti %count% fois ce mois-ci`. Ce texte est commun à toutes les langues du canal de vente. Il est nettoyé avant rendu, ce qui autorise un balisage simple comme `` mais bloque tout script.
### Textes par langue via les snippets
Laissez le champ _Texte personnalisé_ vide pour piloter le texte langue par langue. Ouvrez _Paramètres_, _Boutique_, _Fragments de texte_, puis recherchez `dfSalesCounter`. Quatre clés sont disponibles :
- `dfSalesCounter.badge.quantitySingular` et `dfSalesCounter.badge.quantityPlural`, utilisées en mode quantité vendue.
- `dfSalesCounter.badge.ordersSingular` et `dfSalesCounter.badge.ordersPlural`, utilisées en mode nombre de commandes.
Chaque valeur accepte le marqueur `%count%`. Les traductions française, anglaise, espagnole, allemande et italienne sont livrées avec le plugin. Une valeur modifiée dans le gestionnaire de fragments prend le pas sur celle du plugin, y compris après une mise à jour.
## Comment le chiffre est calculé
Le plugin lit les lignes de commande de type produit, jointes à la commande et à son état. Le calcul se fait en une seule requête agrégée, sans traitement en arrière-plan et sans table dédiée.
- En mode quantité, la requête somme la colonne des quantités des lignes de commande.
- En mode commandes, elle compte les identifiants de commande distincts.
- Seule la version courante des commandes est prise en compte, les versions de travail créées lors d'un avoir ou d'une modification de commande sont ignorées.
- Avec le cumul des déclinaisons activé, le plugin résout d'abord la famille du produit affiché, produit parent et variantes, puis filtre sur l'ensemble des identifiants.
Si le résultat est inférieur au seuil configuré, aucune extension n'est ajoutée au produit et le template ne rend rien. Le badge n'existe donc pas dans le HTML, ce qui évite tout affichage résiduel via une règle CSS de thème.
## Cache et fraîcheur du chiffre
Le résultat est stocké dans le pool de cache applicatif de Symfony, sous une clé qui combine l'identifiant du produit, le canal de vente et une signature des options influençant le calcul. Une modification du mode de comptage, de la portée des commandes, de la période ou des options de cumul change cette signature et invalide donc mécaniquement les valeurs précédentes.
À chaque commande passée, le plugin purge le cache des produits contenus dans cette commande, ainsi que celui de leur produit parent. Le compteur reflète donc la vente sans attendre l'expiration de la durée configurée.
Sur un catalogue de taille modeste, la durée de cache peut être ramenée à 0 sans conséquence notable : la requête porte sur des colonnes indexées. Sur un gros catalogue à fort trafic, conservez une durée de plusieurs minutes.
## Personnalisation avancée du rendu
Le plugin surcharge le buy-widget de la page produit et ajoute son badge dans trois blocs Twig standards, selon l'emplacement choisi : le bloc du nom du produit, le bloc du conteneur de prix et le bloc du conteneur d'achat. Le badge lui-même est rendu par un template de composant dédié, `storefront/component/df-sales-counter/badge.html.twig`, qui expose deux blocs surchargeables pour l'icône et pour le texte.
Depuis un thème ou un plugin, l'extension est accessible dans Twig sur le produit de la page sous le nom `dfSalesCounter`. Elle expose le nombre brut, le nombre formaté, l'emplacement, le style, l'icône, la couleur d'accent, le texte personnalisé et le mode de comptage. Vous pouvez ainsi rendre le compteur ailleurs que dans le bloc d'achat, par exemple dans un onglet d'informations produit, en récupérant l'extension et en incluant le composant.
Les styles sont définis dans `Resources/app/storefront/src/scss/base.scss` autour des classes `df-sales-counter`, `df-sales-counter__icon` et `df-sales-counter__text`, avec un modificateur par style visuel. Toute règle de votre thème compilée après celle du plugin prend le dessus, sans qu'il soit nécessaire de modifier le plugin.
## Dépannage
### Aucun badge n'apparaît
Vérifiez dans l'ordre : le plugin est activé, l'interrupteur d'activation est sur oui pour le bon canal de vente, le produit a atteint le seuil configuré, et la portée des commandes retenue n'exclut pas toutes vos commandes. Un seuil à 5 avec une portée _Commandes payées uniquement_ sur une boutique de test dont les commandes ne sont jamais marquées payées ne produira jamais d'affichage.
### Le badge apparaît sans style
Le thème n'a pas été recompilé après l'activation. Lancez `bin/console theme:compile` ou utilisez le bouton de recompilation dans l'administration.
### Le chiffre semble figé
La durée de cache est encore en cours. Videz le cache applicatif avec `bin/console cache:pool:clear cache.app`, ou ramenez temporairement la durée à 0 pour valider le calcul.
### Le badge ne se place pas au bon endroit
Un thème très personnalisé peut avoir supprimé ou renommé les blocs Twig du bloc d'achat. Essayez un autre emplacement dans la configuration, ou incluez le composant manuellement dans votre template en récupérant l'extension du produit.
## Mise à jour et désinstallation
Une mise à jour s'effectue par téléversement du nouveau ZIP puis clic sur _Mettre à jour_, suivi d'une recompilation du thème si la version contient des changements de style. La configuration est conservée.
À la désinstallation, une case propose de conserver les données utilisateur. Décochée, l'ensemble des clés de configuration du plugin est supprimé. Le plugin ne crée aucune table et n'exécute aucune migration, la désinstallation ne laisse donc rien en base au-delà de sa configuration.
## Référence des clés de configuration
Toutes les clés sont préfixées par `DfSalesCounter.config.` et manipulables par l'API Admin ou par la commande `system:config:set` :
- `active`, booléen
- `countMode`, valeurs `quantity` ou `orders`
- `orderScope`, valeurs `all`, `notCancelled` ou `paid`
- `minThreshold`, entier
- `periodDays`, entier
- `aggregateVariants`, booléen
- `scopeToSalesChannel`, booléen
- `position`, valeurs `afterName`, `afterPrice` ou `afterBuy`
- `style`, valeurs `badge`, `inline` ou `banner`
- `icon`, valeurs `none`, `flame`, `cart` ou `check`
- `accentColor`, chaîne hexadécimale
- `thousandSeparator`, valeurs `space`, `comma`, `dot` ou `none`
- `customText`, chaîne
- `cacheTtl`, entier en secondes
---
### Configurateur de Produit par Étapes — Guide complet
_Source :_
> Présentation DF Product Configurator transforme une fiche produit PrestaShop en configurateur guidé par étapes : le client choisit une couleur, ajoute une gravure, sélectionne un accessoire, voit le résultat composé…
## Présentation
DF Product Configurator transforme une fiche produit PrestaShop en configurateur guidé par étapes : le client choisit une couleur, ajoute une gravure, sélectionne un accessoire, voit le résultat composé en temps réel sur la photo du produit, et le supplément de prix correspondant est appliqué au panier — côté serveur, de manière infalsifiable.
Le module repose sur deux notions simples :
- **Étape** : une question posée au client, rattachée à un produit. Deux types existent : _Choix visuel_ (le client clique sur une option) et _Texte / gravure_ (le client saisit un texte libre).
- **Option** : une réponse possible d'une étape de type choix visuel, avec son visuel (vignette photo ou pastille de couleur), son calque d'aperçu et son impact prix.
## Installation
1. Dans le back-office PrestaShop, ouvrez **Modules → Gestionnaire de modules → Installer un module**.
2. Téléversez le fichier `dfproductconfigurator.zip` puis cliquez sur **Installer**.
3. Deux nouveaux onglets apparaissent sous **Catalogue** : _Configurateur — Étapes_ et _Configurateur — Options_.
Compatibilité : PrestaShop 8.0.0 à 9.x, PHP 7.4 à 8.3. Le module n'utilise ni Composer ni jQuery et ne nécessite aucune modification du thème.
## Créer une étape
1. Ouvrez **Catalogue → Configurateur — Étapes** puis cliquez sur **Ajouter**.
2. Renseignez le **produit** : tapez au moins 3 caractères dans le champ de recherche et cliquez sur un résultat — l'ID produit se remplit automatiquement.
3. Choisissez le **type d'étape** : _Choix visuel_ ou _Texte / gravure_.
4. Saisissez le **libellé** dans chaque langue (par exemple « Couleur », « Gravure », « Accessoire »). C'est le texte affiché dans le stepper.
5. Cochez **Obligatoire** si le client doit répondre à cette étape avant de pouvoir ajouter au panier.
6. Réglez la **position** pour ordonner les étapes entre elles.
### Champs spécifiques aux étapes de gravure
Pour une étape de type _Texte / gravure_, des champs supplémentaires apparaissent :
- **Longueur maximale** : nombre de caractères autorisés (validé côté serveur également).
- **Impact prix** : supplément appliqué dès que le client saisit un texte (0 pour une gravure gratuite).
- **Position X / Y** : position du texte sur l'aperçu, en pourcentage de la largeur et de la hauteur de l'image (50 / 50 = centre).
- **Taille et couleur du texte** : taille en pixels et couleur hexadécimale de l'overlay.
- **Placeholder** : texte d'invite affiché dans le champ, traduisible.
## Créer les options d'une étape
1. Dans la liste des étapes, cliquez sur l'action **Options** de l'étape concernée (ou ouvrez **Catalogue → Configurateur — Options**).
2. Cliquez sur **Ajouter** et renseignez le **libellé** multilingue de l'option.
3. Définissez son **impact prix** hors taxes : positif (supplément), négatif (remise) ou nul (inclus).
4. Choisissez le visuel de la carte d'option : soit une **couleur** hexadécimale (affichée en pastille ronde), soit une **vignette** photo (redimensionnée automatiquement à 400 px).
5. Téléversez si besoin un **calque** PNG transparent (jusqu'à 1600 px) : il sera empilé sur la photo du produit dans l'aperçu composé.
6. Cochez **Par défaut** pour pré-sélectionner cette option — une seule option par défaut par étape, le module s'en charge.
Pour un aperçu parfait, exportez vos calques PNG avec exactement le même cadrage que la photo de couverture du produit (même ratio, produit à la même position). L'empilement se fait en mode contain : si les cadrages diffèrent, les éléments seront décalés.
## Fonctionnement du prix
Les impacts prix sont définis **hors taxes, dans la devise par défaut** de la boutique. Sur la fiche produit, le module les convertit dans la devise du visiteur et les affiche TTC ou HT selon le groupe client, avec un total recalculé en direct.
Ce total affiché est purement indicatif. Au moment du panier, la surcharge réelle est appliquée par le hook de calcul de prix natif de PrestaShop, côté serveur, à partir de la configuration enregistrée en base : conversion de devise au taux de change, application de la TVA du contexte client, arrondi aux décimales de la devise. Un client qui modifie le DOM ou les requêtes ne peut pas changer le prix facturé.
Les impacts négatifs sont autorisés : pratique pour une formule de base à prix réduit ou une option « sans accessoire » qui déduit un montant.
## Parcours client sur la fiche produit
Le bloc configurateur s'affiche automatiquement sur la fiche produit (hook d'informations additionnelles) dès qu'au moins une étape active existe pour le produit. Le client :
1. navigue entre les étapes via le stepper (les étapes complétées sont cochées) ;
2. clique sur ses options ou saisit sa gravure — l'aperçu composé et le total se mettent à jour instantanément ;
3. clique sur **Ajouter au panier** : le module valide les étapes obligatoires, enregistre la configuration côté serveur, puis laisse l'ajout au panier se poursuivre normalement.
Si une étape obligatoire est incomplète, le configurateur s'ouvre sur l'étape concernée avec un message explicite, et l'ajout au panier est bloqué.
## Panier, commande et facture
Chaque configuration validée crée une **personnalisation PrestaShop native** : deux configurations différentes du même produit donnent deux lignes de panier distinctes, chacune avec son prix. Le résumé lisible (par exemple _Couleur : Bleu océan · Gravure : Léa · Accessoire : Bouchon bambou_) apparaît sous le nom du produit dans le panier, la commande, la facture et le détail de commande du back-office — sans aucun réglage supplémentaire.
À la validation de la commande, la configuration est archivée dans une table dédiée. Les configurations de paniers abandonnés sont purgées automatiquement après 60 jours.
## Déclinaisons, invités et multi-devise
- **Déclinaisons** : le configurateur suit la déclinaison sélectionnée — l'aperçu se reconstruit et le prix de base affiché est celui de la déclinaison.
- **Clients invités** : un panier est créé automatiquement si nécessaire au moment de l'enregistrement de la configuration.
- **Multi-devise** : la conversion se fait au taux de change de la boutique, à l'affichage comme au calcul serveur.
## Désinstallation et nettoyage
Le module nettoie derrière lui :
- à la **suppression d'un produit**, ses étapes, options et images d'options sont supprimées ;
- à la **désinstallation**, les tables du module sont supprimées et les champs de personnalisation créés sont libérés (les compteurs produit sont décrémentés).
La désinstallation supprime définitivement les étapes et options configurées. Les commandes passées conservent leur résumé de personnalisation natif, mais le détail structuré des configurations archivées est supprimé avec les tables.
## Dépannage
### Le bloc configurateur ne s'affiche pas
- Vérifiez qu'au moins une étape **active** est rattachée au bon produit (ID produit correct).
- Videz le cache PrestaShop (**Paramètres avancés → Performances**).
- Vérifiez que votre thème appelle bien le hook `displayProductAdditionalInfo` (c'est le cas du thème Classic et de la quasi-totalité des thèmes).
### L'aperçu composé est décalé
Le calque PNG n'a pas le même cadrage que la photo de couverture. Ré-exportez le calque avec le même ratio et la même position du produit que l'image principale.
### Le supplément n'apparaît pas dans le panier
- Vérifiez que l'option sélectionnée porte bien un impact prix non nul.
- Le prix du panier est recalculé par PrestaShop : videz le cache et re-testez avec un panier neuf.
### Deux ajouts identiques créent deux lignes
C'est le comportement attendu si les configurations diffèrent. Si elles sont strictement identiques et ajoutées dans la même session, le module réutilise la même personnalisation et incrémente la quantité.
---
### Conformité GPSR (sécurité produit) — Guide complet
_Source :_
> Présentation Le module Conformité GPSR (datafireflygpsr) outille votre boutique pour le règlement (UE) 2023/988 relatif à la sécurité générale des produits, applicable depuis le 13 décembre 2024. Il affiche sur…
## Présentation
Le module **Conformité GPSR** (`datafireflygpsr`) outille votre boutique pour le **règlement (UE) 2023/988** relatif à la sécurité générale des produits, applicable depuis le 13 décembre 2024. Il affiche sur chaque fiche produit le **fabricant**, le **responsable établi dans l'Union européenne**, les **avertissements de sécurité** et les **pictogrammes réglementaires**, dans la langue du client.
Le module fournit l'outillage technique pour collecter et afficher les informations exigées. La conformité réglementaire dépend aussi de l'exactitude des informations que vous saisissez et de l'analyse de risque propre à chaque produit. Il ne se substitue pas à un conseil juridique.
## Compatibilité
- PrestaShop 8.0 à 9.x
- PHP 7.4 à 8.3
- MySQL 5.7+ ou MariaDB 10.3+
- Mono-boutique et multiboutique
- Thème Classic, Hummingbird et thèmes personnalisés
- Interface et données livrées en français, anglais, espagnol, allemand et italien
- Aucune dépendance (ni Composer ni framework), aucun CDN
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** puis sélectionnez le fichier `datafireflygpsr.zip`.
3. Une fois installé, cliquez sur **Configurer**.
À l'installation, le module crée ses tables, enregistre ses hooks (ressources back-office et front, onglet de la fiche produit, bloc d'affichage en boutique), ajoute le menu **Catalogue > GPSR** et amorce des données d'exemple : quatre pictogrammes (mise en garde, âge 0-3 ans, marquage CE, inflammable) et deux avertissements types (risque d'étouffement, surveillance d'un adulte), traduits dans les cinq langues.
## Prise en main rapide
1. Créez vos **opérateurs économiques** (au minimum un fabricant et, si besoin, un responsable UE) dans **Catalogue > GPSR > Opérateurs**.
2. Vérifiez ou complétez la bibliothèque de **pictogrammes** et d'**avertissements**.
3. Dans la configuration du module, définissez éventuellement un fabricant et un responsable UE **par défaut**.
4. Ouvrez une fiche produit, allez dans l'onglet **GPSR**, renseignez les informations, puis cliquez sur **Enregistrer GPSR**.
5. Vérifiez l'affichage côté boutique sur la fiche produit.
## Configuration du module
- **Activer l'affichage GPSR** : active ou désactive l'affichage des informations en boutique.
- **Mode d'affichage** : _Onglet dédié_ (un onglet « Sécurité du produit » sur la fiche) ou _Bloc en ligne_ (sous les informations produit).
- **Afficher les pictogrammes** : montre ou masque la grille de pictogrammes en boutique.
- **Afficher les avertissements** : montre ou masque la liste des avertissements en boutique.
- **Masquer si vide** : n'affiche aucun cadre lorsqu'un produit n'a aucune donnée GPSR renseignée.
- **Fabricant par défaut** et **Responsable UE par défaut** : opérateurs appliqués automatiquement aux produits sans valeur spécifique (voir « Valeurs par défaut »).
## Gérer les opérateurs économiques
Les opérateurs économiques sont gérés une seule fois et réutilisés sur tout le catalogue, depuis **Catalogue > GPSR > Opérateurs**. Quatre **types** sont disponibles :
- **Fabricant** : l'entité qui produit le bien ou le fait produire sous son nom.
- **Importateur** : l'entité qui met sur le marché de l'Union un produit provenant d'un pays tiers.
- **Mandataire** : la personne mandatée par le fabricant pour agir en son nom dans l'UE.
- **Responsable UE** : la personne responsable établie dans l'Union, requise lorsque le fabricant est hors UE.
Chaque opérateur porte sa raison sociale, son adresse complète, son pays, son email, son téléphone, son site et son numéro de TVA.
Corrigez une adresse une seule fois sur l'opérateur : la modification se répercute instantanément sur tous les produits qui l'utilisent, sans ressaisie produit par produit.
## Gérer les pictogrammes
Depuis **Catalogue > GPSR > Pictogrammes**, créez, modifiez ou supprimez les pictogrammes de sécurité. Chaque pictogramme possède un code, une image (SVG ou PNG, téléversée dans le module), une position d'affichage et, pour chaque langue, un nom et une légende.
- Quatre pictogrammes sont fournis d'origine : mise en garde générale, tranche d'âge 0-3 ans, marquage CE, produit inflammable.
- Vous pouvez en créer autant que nécessaire et téléverser vos propres visuels.
Vous restez responsable du choix des pictogrammes adaptés à chaque produit selon la réglementation applicable.
## Gérer les avertissements
Depuis **Catalogue > GPSR > Avertissements**, gérez la bibliothèque d'avertissements de sécurité. Chaque avertissement possède un code, une position et, pour chaque langue, son texte.
- Deux avertissements types sont fournis : risque d'étouffement (petites pièces) et usage sous la surveillance d'un adulte.
- Les textes sont traduits dans les cinq langues et personnalisables.
## Renseigner les données GPSR d'un produit
Ouvrez une fiche produit en back-office : un onglet **GPSR** est ajouté. Vous y trouvez :
- la sélection du **fabricant** et du **responsable UE** parmi vos opérateurs ;
- les champs **GTIN** et **numéro de lot** ;
- les **avertissements** applicables (cases à cocher) ;
- la grille de **pictogrammes** sélectionnables ;
- une zone d'**information de sécurité complémentaire** en texte libre, multilingue.
Cliquez sur **Enregistrer GPSR** pour sauvegarder.
L'enregistrement des données GPSR passe par un **contrôleur AJAX dédié**, indépendant du formulaire produit Symfony. C'est un choix d'architecture délibéré : il garantit un comportement identique et fiable sur PrestaShop 8 et 9, dont les pages produit diffèrent profondément. Le bouton « Enregistrer GPSR » est donc distinct du bouton « Enregistrer » de la fiche produit.
## Valeurs par défaut et repli automatique
Si la plupart de vos produits partagent le même fabricant ou le même responsable UE, définissez-les une fois dans la configuration du module comme **valeurs par défaut**. Tout produit sans fabricant ou responsable spécifique héritera automatiquement de ces valeurs à l'affichage en boutique. Vous ne renseignez manuellement que les exceptions.
## Affichage côté client
Selon le mode choisi, les informations GPSR s'affichent :
- en **onglet dédié** de la fiche produit, via le hook `displayProductExtraContent` ;
- ou en **bloc en ligne** sous les informations produit, via le hook `displayProductAdditionalInfo`.
Le bloc présente le fabricant, le responsable UE, les avertissements, les pictogrammes (avec leurs légendes), l'information complémentaire, et le cas échéant le GTIN et le numéro de lot. L'option **Masquer si vide** évite tout cadre vide sur les produits non renseignés.
## Tableau de bord de couverture
Le menu **Catalogue > GPSR** ouvre un tableau de bord qui indique la part du catalogue dont les données GPSR sont renseignées : nombre de produits couverts, nombre d'opérateurs, de pictogrammes et d'avertissements. Il vous aide à repérer les produits restant à compléter.
## Multilingue
Les avertissements, les légendes de pictogrammes et l'information complémentaire sont traduisibles en français, anglais, espagnol, allemand et italien. L'affichage suit automatiquement la langue active du client — ce qu'exige le règlement, qui impose des informations de sécurité dans la langue du pays de commercialisation. Les libellés d'interface se traduisent via **Paramètres avancés > Traductions > Traductions des modules installés**, en choisissant `datafireflygpsr`.
## Compatibilité PrestaShop 9
Le module est conçu et testé de PrestaShop 8.0 à 9.x :
- les contrôleurs back-office utilisent `ModuleAdminController`, compatible 8 et 9 ;
- l'enregistrement des données produit passe par un contrôleur AJAX dédié, plutôt que par le formulaire produit Symfony ;
- le contrôleur AJAX renvoie directement du JSON, sans override de signature incompatible.
## FAQ et dépannage
### L'onglet GPSR ne montre pas mes opérateurs
Vérifiez que vous avez bien créé au moins un opérateur dans **Catalogue > GPSR > Opérateurs** et qu'il est actif. Les listes déroulantes de la fiche produit ne proposent que les opérateurs actifs.
### Les informations ne s'affichent pas en boutique
Assurez-vous que l'affichage GPSR est activé dans la configuration, que le produit a des données renseignées (ou qu'un fabricant/responsable par défaut est défini), puis videz le cache de PrestaShop. Si l'option **Masquer si vide** est active, un produit sans donnée n'affiche rien volontairement.
### Le clic sur « Enregistrer GPSR » ne sauvegarde pas
Le bouton « Enregistrer GPSR » est distinct du bouton « Enregistrer » de la fiche produit et déclenche une requête AJAX dédiée. Videz le cache, rechargez la page produit, et vérifiez dans la console du navigateur qu'aucune extension ne bloque la requête.
### Comment ajouter mon propre pictogramme ?
Dans **Catalogue > GPSR > Pictogrammes**, créez un pictogramme, téléversez votre image (SVG ou PNG) et renseignez son nom et sa légende pour chaque langue.
### Est-ce compatible PrestaShop 9 ?
Oui. Le module est conçu et testé de PrestaShop 8.0 à 9.x, en mono-boutique comme en multiboutique.
## Désinstallation
La désinstallation supprime les tables du module, ses onglets d'administration et désenregistre les hooks. Les opérateurs, pictogrammes, avertissements et associations produit sont effacés. Si vous prévoyez de réinstaller, conservez au préalable une sauvegarde de votre base de données.
---
### Connecteur Axonaut pour WooCommerce — Documentation
_Source :_
> Le Connecteur Axonaut pour WooCommerce relie votre boutique WooCommerce à l'ERP/CRM français Axonaut. Il pousse automatiquement vos commandes dans Axonaut sous forme de factures ou de devis, crée les sociétés…
Le **Connecteur Axonaut pour WooCommerce** relie votre boutique WooCommerce à l'ERP/CRM français Axonaut. Il pousse automatiquement vos commandes dans Axonaut sous forme de factures ou de devis, crée les sociétés et contacts correspondants, génère des avoirs lors des remboursements et vous permet d'importer votre historique. Tout le traitement s'effectue en arrière-plan via Action Scheduler, sans impact sur le checkout, et reste idempotent : une commande n'est jamais synchronisée deux fois.
## Prérequis
- WordPress 6.0 ou supérieur
- WooCommerce 7.0 ou supérieur
- PHP 7.4 ou supérieur
- Un compte Axonaut actif et sa clé API
Le plugin ne requiert aucune dépendance Composer sur votre serveur et est compatible avec le stockage haute performance des commandes (HPOS) comme avec l'ancien stockage.
## Installation
1. Depuis l'administration WordPress, allez dans _Extensions > Ajouter > Téléverser une extension_.
2. Sélectionnez le fichier ZIP du plugin, puis cliquez sur _Installer maintenant_.
3. Activez l'extension.
4. Un nouveau menu _WooCommerce > Axonaut_ apparaît dans l'administration.
## Connexion à Axonaut
Rendez-vous dans _WooCommerce > Axonaut_, onglet _Réglages_.
### Récupérer votre clé API
Dans votre compte Axonaut, ouvrez la section _Paramètres_ puis _Développeurs_. Copiez votre clé API personnelle.
### Renseigner et tester la clé
Collez la clé dans le champ _Clé API Axonaut_, puis cliquez sur _Tester la connexion_. Un message vert confirme que la connexion est établie ; un message rouge indique une clé invalide ou un problème réseau.
La clé est stockée de façon sécurisée et n'est jamais affichée en clair une fois enregistrée. Le test de connexion utilise la clé saisie dans le champ, même avant l'enregistrement.
## Configuration
### Type de document
Choisissez le document créé dans Axonaut à partir d'une commande : **Facture** ou **Devis**. Ce choix s'applique à toutes les commandes synchronisées.
### Statuts déclencheurs
Cochez les statuts de commande qui déclenchent l'envoi vers Axonaut (par exemple _Terminée_). Dès qu'une commande atteint l'un de ces statuts, elle est mise en file d'attente pour synchronisation. Chaque commande n'est envoyée qu'une seule fois, même si elle change plusieurs fois de statut.
### Contacts
Activez cette option pour que l'acheteur soit créé comme contact (employee) rattaché à la société dans Axonaut. La société, elle, est toujours créée : Axonaut en a besoin pour rattacher factures et devis.
### Remboursements
Activez cette option pour qu'un remboursement WooCommerce génère automatiquement un avoir dans Axonaut. Cela ne s'applique qu'aux commandes déjà synchronisées en facture.
### Date de paiement
Lorsqu'elle est activée, la date de paiement est transmise à Axonaut pour les commandes déjà réglées.
### Produits
Option facultative : synchronise vos produits WooCommerce vers le catalogue Axonaut lors de leur création ou mise à jour.
### Maintenance
Définissez la durée de rétention du journal (en jours) et activez le mode debug pour journaliser l'intégralité des réponses de l'API en cas de diagnostic.
## Synchronisation des commandes
Quand une commande atteint un statut déclencheur, le connecteur :
1. résout ou crée la société Axonaut correspondante ;
2. construit le document ligne par ligne, avec le taux de TVA calculé pour chaque ligne ;
3. ajoute les frais de port et les frais éventuels comme lignes dédiées ;
4. transmet la date de paiement si la commande est déjà réglée ;
5. crée la facture ou le devis dans Axonaut et enregistre son identifiant sur la commande.
Le traitement est asynchrone (Action Scheduler) : il n'allonge pas le temps de passage en caisse. En cas d'erreur temporaire de l'API (429 ou 5xx), l'envoi est automatiquement re-tenté avec un délai croissant, jusqu'à cinq fois.
## Sociétés, contacts et TVA intracommunautaire
La société Axonaut est créée à partir des données de facturation. Le connecteur distingue automatiquement les clients professionnels (champ société renseigné) des particuliers, et reporte le numéro de TVA intracommunautaire détecté depuis les principaux plugins de TVA UE.
### Déduplication
Avant tout appel à l'API, le connecteur cherche une société déjà résolue : d'abord sur la commande elle-même, puis sur le compte client (le cas échéant), puis sur une commande précédente portant le même e-mail de facturation. Les acheteurs récurrents, même en commande invitée, sont ainsi reconnus sans créer de doublon.
## Avoirs et remboursements
Un remboursement WooCommerce, total ou partiel, sur une commande déjà synchronisée en facture, génère automatiquement un avoir dans Axonaut, lié à la facture d'origine.
- Les remboursements par ligne sont repris ligne par ligne, avec la TVA recalculée.
- Les remboursements par montant produisent une ligne d'avoir globale.
- Les frais de port remboursés sont ajoutés comme ligne dédiée.
Chaque avoir est idempotent : un même remboursement ne génère jamais deux avoirs.
## Import de l'historique
L'onglet _Import_ permet de pousser vos commandes existantes vers Axonaut.
1. Choisissez une plage de dates (facultative) et les statuts de commande à inclure.
2. Cliquez sur _Démarrer l'import_.
3. Les commandes sont parcourues par lots en arrière-plan via Action Scheduler ; les commandes déjà synchronisées sont automatiquement ignorées.
Suivez l'avancement dans l'onglet _Journal_.
## Action groupée sur la liste des commandes
Depuis la liste des commandes (écran HPOS ou ancien écran), sélectionnez une ou plusieurs commandes, puis choisissez l'action groupée _Synchroniser vers Axonaut_. Un message indique le nombre de commandes mises en file d'attente et celles ignorées car déjà synchronisées.
## Meta box et resynchronisation manuelle
Sur la fiche d'une commande, la boîte _Axonaut_ affiche l'état de synchronisation : type et numéro du document créé, société liée et date. Si la commande n'est pas encore synchronisée, un bouton _Synchroniser maintenant_ permet un envoi immédiat, avec affichage de la dernière erreur le cas échéant.
## Journal d'activité et mode debug
L'onglet _Journal_ affiche les dernières opérations (créations de sociétés, factures, avoirs, erreurs), avec un lien direct vers la commande concernée. La durée de rétention est configurable. Le mode debug ajoute au journal le détail complet des réponses de l'API, utile pour diagnostiquer un problème.
## Synchronisation des produits (optionnel)
Lorsque l'option est activée, chaque création ou mise à jour de produit WooCommerce est répercutée dans le catalogue Axonaut (nom, référence SKU, prix hors taxe, taux de TVA). La correspondance est mémorisée pour mettre à jour le bon produit Axonaut lors des modifications suivantes.
## Compatibilité HPOS
Le plugin déclare sa compatibilité avec le stockage haute performance des commandes (High-Performance Order Storage). Toutes les métadonnées de synchronisation sont enregistrées via l'API des commandes WooCommerce, ce qui garantit un fonctionnement identique avec l'ancien stockage et avec HPOS.
## Hooks pour développeurs
Le connecteur expose plusieurs points d'extension pour adapter les données envoyées à Axonaut :
- `df_axonaut_company_payload` — filtre les données de la société avant création.
- `df_axonaut_employee_payload` — filtre les données du contact avant création.
- `df_axonaut_document_payload` — filtre les données de la facture ou du devis.
- `df_axonaut_credit_note_payload` — filtre les données de l'avoir.
- `df_axonaut_product_payload` — filtre les données du produit synchronisé.
- `df_axonaut_vat_meta_keys` — personnalise les clés de méta où chercher le numéro de TVA.
- `df_axonaut_order_synced` — action déclenchée après synchronisation réussie d'une commande.
- `df_axonaut_refund_synced` — action déclenchée après création d'un avoir.
## Dépannage
### Le test de connexion échoue
Vérifiez que la clé API est correcte et active dans votre compte Axonaut, et que votre serveur peut joindre l'API Axonaut en sortie HTTPS.
### Une commande n'est pas synchronisée
Assurez-vous que son statut figure parmi les statuts déclencheurs et qu'elle n'a pas déjà été synchronisée. Consultez le journal ainsi que la boîte Axonaut de la commande pour la dernière erreur. Vérifiez également que la file Action Scheduler s'exécute (WooCommerce > État > Actions planifiées).
### Un avoir n'a pas été créé
Les avoirs ne sont générés que pour les commandes déjà synchronisées en _facture_ (pas en devis) et lorsque l'option des remboursements est activée.
Ne modifiez pas manuellement l'identifiant de document Axonaut enregistré sur une commande : c'est lui qui garantit qu'une commande n'est jamais envoyée deux fois.
---
### Connecteur Axonaut PrestaShop — Documentation
_Source :_
> Le module Connecteur Axonaut PrestaShop (dfaxonaut, éditeur DataFirefly) synchronise automatiquement vos clients, commandes et produits entre PrestaShop et Axonaut, le logiciel de gestion français (CRM, facturation, devis, trésorerie). Ce guide…
Le module **Connecteur Axonaut PrestaShop** (dfaxonaut, éditeur DataFirefly) synchronise automatiquement vos clients, commandes et produits entre PrestaShop et Axonaut, le logiciel de gestion français (CRM, facturation, devis, trésorerie). Ce guide couvre l'installation, la configuration, le fonctionnement des synchronisations et le dépannage.
## Prérequis
- PrestaShop 8.x ou 9.x, PHP 7.4 à 8.3.
- Un compte Axonaut actif avec accès à l'API v2.
- Votre clé API Axonaut (userApiKey), disponible dans Axonaut sous _Paramètres > Développeurs > Clé API_.
## Installation
1. Dans le back-office PrestaShop, ouvrez _Modules > Module Manager > Envoyer un module_ et déposez le fichier ZIP du module.
2. Une fois installé, cliquez sur _Configurer_.
3. Un nouvel onglet _Axonaut Connector_ apparaît également sous _Paramètres avancés_ : il donne accès au tableau de bord et aux journaux.
Le module n'installe aucune dépendance Composer au déploiement : l'autoloader PSR-4 est intégré. Rien d'autre n'est requis côté serveur.
## Configuration
### Clé API et test de connexion
Collez votre clé API Axonaut dans le champ _Clé API Axonaut_ puis enregistrez. Rendez-vous ensuite dans le tableau de bord (_Paramètres avancés > Axonaut Connector_) et cliquez sur _Tester la connexion_ : le module interroge l'endpoint /me d'Axonaut et affiche le compte associé si tout est correct.
### Synchronisation des clients
Activez _Synchroniser les clients_ pour que chaque création de compte, mise à jour du compte ou modification d'adresse crée ou mette à jour une société Axonaut accompagnée de son contact. Le module détecte automatiquement les professionnels (raison sociale ou TVA intracommunautaire renseignée) et les particuliers (B2C), et transmet l'adresse, la TVA intracommunautaire et le numéro d'entreprise lorsqu'ils sont disponibles.
### Synchronisation des commandes
Activez _Synchroniser les commandes_, puis choisissez :
- **Mode** : créer une _facture_ ou un _devis_ Axonaut.
- **Statuts déclencheurs** : la commande est envoyée la première fois qu'elle atteint l'un des statuts sélectionnés (par exemple « Paiement accepté »).
- **Prix TTC** : envoyer les prix unitaires taxes incluses plutôt que hors taxes.
Chaque commande transmise reprend les lignes produits (référence, taux de TVA, quantité) et ajoute les frais de port en ligne dédiée. Une commande déjà envoyée n'est jamais dupliquée.
### Synchronisation des produits (optionnelle)
Activez _Synchroniser les produits_ pour refléter votre catalogue (référence, nom, prix, TVA, description courte) dans les produits Axonaut. La synchronisation se déclenche à chaque mise à jour d'une fiche produit.
## Tâche cron
Les synchronisations sont mises en file d'attente et traitées en tâche de fond. Un traitement inline léger est tenté à la volée dans les hooks, mais pour un fonctionnement fiable, planifiez la tâche cron affichée dans la configuration :
```
curl -s "https://votre-boutique.tld/index.php?fc=module&module=dfaxonaut&controller=cron&token=VOTRE_TOKEN"
```
Fréquence recommandée : toutes les 5 à 15 minutes. Le cron traite la file, purge les éléments terminés (7 jours) et les journaux anciens (30 jours). Le token est régénérable depuis la page de configuration.
Si vous régénérez le token, pensez à mettre à jour l'URL dans votre planificateur de tâches (cron serveur, tâche PrestaShop ou service externe).
## Tableau de bord et journaux
L'onglet _Axonaut Connector_ affiche les compteurs (en attente / synchronisés / en échec) et le journal complet des opérations, filtrable et exportable. Deux actions sont disponibles :
- **Traiter la file maintenant** : force le traitement immédiat des éléments en attente.
- **Relancer les échecs** : remet en file les éléments passés en échec après 5 tentatives.
## Fonctionnement de la file et des relances
Chaque entité à synchroniser (client, commande, produit) est déposée dans une file. En cas d'erreur temporaire (réseau, quota API), le module réessaie automatiquement jusqu'à 5 fois, puis marque l'élément en échec. Les erreurs sont journalisées avec leur message, ce qui facilite le diagnostic. Le mode debug ajoute les payloads et réponses complets de l'API dans les journaux.
## Dépannage
- **« Clé API vide »** : renseignez la clé dans la configuration avant de tester la connexion.
- **Erreur HTTP 401/403** : la clé API est invalide ou révoquée. Régénérez-la dans Axonaut.
- **Commandes non envoyées** : vérifiez que le statut atteint fait partie des statuts déclencheurs et que la synchronisation des commandes est activée.
- **Éléments en échec** : ouvrez le journal pour lire le message d'erreur, corrigez la cause, puis cliquez sur _Relancer les échecs_.
- **Rien ne se synchronise en tâche de fond** : vérifiez que la tâche cron est bien planifiée et que le token de l'URL correspond à celui de la configuration.
## Notes techniques
- API utilisée : Axonaut REST API v2, authentification par en-tête userApiKey.
- Endpoints : /me, /companies, /companies/{id}/employees, /employees/{id}, /products, /invoices, /quotations.
- Tables créées : dfaxonaut_map (correspondances PrestaShop ↔ Axonaut), dfaxonaut_queue (file), dfaxonaut_log (journaux).
- Compatible multiboutique PrestaShop.
---
### Connecteur Odoo — Guide complet
_Source :_
> Installer, connecter et exploiter le Connecteur Odoo : connexion JSON-RPC, sens de synchronisation par entité, synchronisation initiale, cron, webhook entrant et file résiliente pour PrestaShop 8 et 9.
Le **Connecteur Odoo** synchronise en temps réel et dans les deux sens vos produits, votre stock, vos commandes et vos clients entre PrestaShop et Odoo. Ce guide couvre l'installation, la connexion à Odoo, le choix du sens de synchronisation, la synchronisation initiale, le cron, le webhook entrant et le dépannage.
## Prérequis
- PrestaShop 8.0 à 9.x.
- PHP 7.4 à 8.3 avec l'extension cURL active.
- Une instance Odoo 14 à 18 (en ligne ou auto-hébergée) accessible en HTTPS depuis votre serveur PrestaShop.
- Un utilisateur Odoo disposant d'une clé API et des droits sur les modèles Ventes, Inventaire et Contacts.
Le module communique avec Odoo via **JSON-RPC**. L'extension PHP `xmlrpc`, retirée de PHP 8, n'est pas nécessaire.
## Installation
1. Dans le back-office, ouvrez _Modules > Module Manager_ puis _Téléverser un module_ et déposez le fichier `dfodooconnect.zip`.
2. Une fois installé, ouvrez la page de configuration via le bouton _Configurer_ ou l'onglet _Odoo Connector_ dans le menu d'administration.
## Générer une clé API dans Odoo
1. Connectez-vous à Odoo avec le compte de service dédié à la synchronisation.
2. Ouvrez _Préférences > Sécurité du compte > Clés API_ et générez une nouvelle clé.
3. Copiez la clé : elle remplace le mot de passe dans la configuration du module.
Créez un utilisateur Odoo dédié (par exemple « PrestaShop Sync ») plutôt que d'utiliser un compte administrateur personnel. Vous gardez ainsi un journal d'audit clair côté Odoo.
## Connexion à Odoo
Dans la page de configuration, renseignez les quatre champs du bloc _Connexion Odoo_ :
- **URL Odoo** : l'adresse complète de votre instance, par exemple `https://mon-odoo.com`.
- **Base de données** : le nom exact de la base Odoo.
- **Utilisateur** : l'identifiant (login) du compte de service.
- **Clé API** : la clé générée à l'étape précédente.
Cliquez sur **Tester la connexion**. En cas de succès, le module affiche la version d'Odoo détectée et l'identifiant utilisateur (uid). Enregistrez, puis cochez **Activer la synchronisation**.
Tant que la case _Activer la synchronisation_ n'est pas cochée, aucune donnée n'est envoyée à Odoo, même si la connexion est valide.
## Choisir les entités et le sens de synchronisation
Quatre entités sont gérées. Pour chacune, vous activez ou désactivez la synchronisation ; pour les produits et le stock, vous choisissez en plus le sens.
- **Clients** : PrestaShop vers Odoo (contacts `res.partner`).
- **Produits** : PrestaShop vers Odoo, Odoo vers PrestaShop, ou bidirectionnel.
- **Stock** : PrestaShop vers Odoo, Odoo vers PrestaShop, ou bidirectionnel.
- **Commandes** : PrestaShop vers Odoo (bons de commande `sale.order`).
Deux options complètent le comportement des commandes : **Confirmer automatiquement la commande dans Odoo** (passe le devis en bon de commande confirmé) et **Générer la facture Odoo**.
## Synchronisation initiale
Avant d'activer le flux temps réel sur une boutique existante, peuplez Odoo avec vos données actuelles depuis le bloc _Synchronisation initiale_ :
1. **Exporter tous les clients** : place chaque client dans la file d'export.
2. **Exporter tous les produits** : nécessaire avant le stock et les commandes, car les lignes de commande et les ajustements de stock s'appuient sur la correspondance produit.
3. **Exporter toutes les commandes** : à lancer après les clients et les produits.
Respectez l'ordre clients → produits → commandes. Le module gère automatiquement les dépendances manquantes (il met un produit non mappé en file avant de réessayer la commande), mais l'ordre réduit le nombre de relances.
## Configuration du cron
Le cron vide la file d'attente (relances des envois en échec) et importe le stock depuis Odoo lorsque ce sens est activé. Planifiez l'URL fournie dans le bloc _Endpoints_, toutes les 1 à 5 minutes :
```
curl "https://votre-boutique.com/module/dfodooconnect/cron?token=VOTRE_TOKEN"
```
Le jeton est généré automatiquement à l'installation et affiché dans la configuration.
## Webhook entrant (Odoo vers PrestaShop)
Pour que les changements faits dans Odoo redescendent en temps réel, créez une **Action automatisée** dans Odoo (action serveur de type webhook) qui envoie une requête POST JSON vers l'URL de webhook du module.
Mise à jour de stock :
```
{ "token": "VOTRE_TOKEN", "entity": "stock", "odoo_id": 42, "qty": 17 }
```
Changement d'état de commande :
```
{ "token": "VOTRE_TOKEN", "entity": "order_state", "odoo_id": 99, "state": "cancel" }
```
Les états reconnus sont `cancel`, `sale` et `done`, mappés respectivement vers Annulée, En préparation et Livrée côté PrestaShop.
Le `token` du webhook doit être identique à celui affiché dans la configuration. Une requête sans jeton valide est rejetée avec un code 403.
## Tableau de bord et journal
Le tableau de bord affiche en permanence quatre indicateurs de file (_En attente_, _Synchronisés_, _En erreur_, _Abandonnés_), le nombre de correspondances par entité, ainsi qu'un journal d'activité horodaté. Deux actions de maintenance sont disponibles : **Traiter la file maintenant** et **Importer le stock depuis Odoo**.
## La file d'attente résiliente
Chaque changement dans PrestaShop est d'abord poussé dans une file, puis envoyé immédiatement à Odoo en « best effort ». Si Odoo est injoignable, le travail reste en file et le cron le rejoue automatiquement. Après le nombre de tentatives configuré (par défaut 5), un travail définitivement en échec passe en quarantaine (_Abandonné_) pour ne pas bloquer le reste de la file.
C'est ce mécanisme qui garantit qu'une indisponibilité d'Odoo ne bloque jamais le tunnel de commande de vos clients.
## Champs synchronisés
### Clients
Nom, email, société, référence, adresse par défaut (rue, ville, code postal, téléphone), numéro de TVA et pays. Le rapprochement anti-doublon se fait par email.
### Produits
Nom, référence interne, prix de vente, prix d'achat, poids, code-barres, description courte et état actif. Le rapprochement anti-doublon se fait par référence.
### Stock
Les quantités disponibles sont reportées via un ajustement d'inventaire sur l'emplacement Odoo configuré (ou le premier emplacement interne si aucun n'est précisé).
### Commandes
Partenaire, référence client, lignes de commande (produit, quantité, prix unitaire hors taxe) et frais de port. Le client est synchronisé à la volée s'il ne l'a pas encore été.
## Mode test (dry-run)
Activez **Mode test** pour valider le mappage sans rien écrire dans Odoo : chaque opération est enregistrée dans le journal avec la mention DRY-RUN mais aucune donnée n'est créée ni modifiée. Idéal pour une recette avant la mise en production.
## Dépannage
- **Le test de connexion échoue** : vérifiez l'URL (avec https), le nom exact de la base, le login et la clé API. Assurez-vous que le serveur PrestaShop peut joindre l'instance Odoo en sortie.
- **Une commande reste en attente** : un produit de la commande n'est probablement pas encore mappé. Le module met le produit en file ; relancez « Traiter la file maintenant » après quelques secondes.
- **Le stock ne remonte pas dans PrestaShop** : vérifiez que le sens du stock inclut Odoo vers PrestaShop et que le cron s'exécute.
- **Doublons côté Odoo** : assurez-vous que les références produits et les emails clients sont renseignés ; ce sont les clés de rapprochement.
## Désinstallation
La désinstallation supprime les tables de correspondance, de file et de journal du module. **Vos données dans Odoo ne sont pas affectées.** Pour une simple mise à jour, remplacer les fichiers suffit : le schéma et les correspondances sont préservés.
---
### Connecteur Sellsy PrestaShop – Documentation
_Source :_
> Guide complet du connecteur Sellsy pour PrestaShop 8 et 9 : installation, création de l'accès API Sellsy v2, configuration, synchronisation des clients, commandes, factures, paiements et avoirs, cron et dépannage.
## Présentation
Le connecteur Sellsy de DataFirefly relie votre boutique PrestaShop à **Sellsy**, la solution SaaS française de CRM, facturation et gestion. Il synchronise automatiquement vos clients, produits, commandes, factures, paiements et avoirs de PrestaShop vers Sellsy via l'**API Sellsy v2**. La synchronisation est unidirectionnelle : PrestaShop → Sellsy.
Compatible PrestaShop 8.0 à 9.x, multiboutique. Interface d'administration en français et anglais.
## Installation
1. Depuis le back-office PrestaShop, allez dans _Modules > Gestionnaire de modules_.
2. Cliquez sur _Installer un module_ et téléversez le fichier `dfsellsy.zip`.
3. Une fois installé, cliquez sur _Configurer_.
Le module crée deux tables (`dfsellsy_link` pour la correspondance PrestaShop ↔ Sellsy, `dfsellsy_log` pour le journal) et un onglet « Sellsy Connector » dans le menu Modules.
## Créer l'accès API dans Sellsy
Le connecteur utilise l'authentification OAuth2 (client credentials) de l'API v2.
1. Dans Sellsy, ouvrez _Menu > Réglages > Portail développeur_.
2. Dans l'onglet _API V2_, cliquez sur _Créer un accès API_.
3. Choisissez le collaborateur lié à l'accès (de préférence un administrateur, pour disposer de tous les droits) et cochez les scopes nécessaires (clients, documents, catalogue, paiements).
4. Enregistrez, puis copiez le **Client ID** et le **Client Secret**.
Le Client Secret n'est affiché qu'une seule fois. Conservez-le en lieu sûr avant de quitter la page Sellsy.
## Configuration du module
Sur la page de configuration du module, renseignez :
- **Client ID** et **Client Secret** : les identifiants OAuth2 créés dans Sellsy. Laissez le champ secret vide pour conserver la valeur déjà enregistrée.
- **Synchroniser les clients** : crée/met à jour un tiers Sellsy à l'inscription et à la mise à jour d'un client.
- **Synchroniser les commandes** : transforme les commandes en documents Sellsy.
- **Type de document Sellsy pour les commandes** : facture ou bon de commande.
- **Déclencheur de synchronisation des commandes** : à la confirmation du paiement ou à la validation de la commande.
- **Valider les documents Sellsy** : valide automatiquement factures et avoirs après création (sinon ils restent en brouillon dans Sellsy).
- **Enregistrer les paiements** : enregistre les règlements PrestaShop sur la facture Sellsy (uniquement en type facture).
- **Synchroniser les remboursements en avoirs** : crée un avoir Sellsy à chaque avoir PrestaShop et le lie à la facture d'origine.
- **Synchroniser les produits** : pousse le catalogue vers les items Sellsy.
Utilisez le bouton _Tester la connexion API_ pour vérifier vos identifiants avant d'activer les synchronisations.
## Synchronisation des clients
À l'inscription ou à la mise à jour d'un client, le module crée ou met à jour un tiers Sellsy. Les clients avec un champ « société » renseigné deviennent des **sociétés** Sellsy (avec le SIRET si disponible), les autres des **particuliers**. Une recherche par e-mail évite les doublons, et l'adresse de facturation principale est remontée à la création.
## Synchronisation des commandes
Selon le déclencheur choisi, une commande validée ou payée devient un document Sellsy comportant les lignes produits, les frais de port et les remises panier (en ligne négative). Les taux de TVA PrestaShop sont automatiquement mis en correspondance avec les taxes Sellsy. Chaque commande n'est synchronisée qu'une seule fois (idempotence).
## Factures, validation et paiements
Lorsque le type de document est « facture » :
- si l'option _Valider les documents_ est active, la facture est validée automatiquement après création ;
- si l'option _Enregistrer les paiements_ est active, chaque règlement PrestaShop est enregistré sur la facture, sans doublon, y compris les paiements partiels ou multiples ;
- si la commande a été créée à la validation et que le paiement arrive plus tard, le module enregistre uniquement les nouveaux règlements sur la facture existante.
## Avoirs sur remboursement
À la génération d'un avoir PrestaShop, le module crée un avoir Sellsy à partir des lignes remboursées (produits et port), le valide si l'option est active, puis le rattache à la facture d'origine lorsque celle-ci existe côté Sellsy.
## Synchronisation des produits
La synchronisation des produits est optionnelle. Une fois activée, les produits sont poussés vers le catalogue Sellsy à la création et à la mise à jour. Vous pouvez aussi lancer une synchronisation de masse depuis la page « Sellsy Connector » (traitement par lots de 20).
## Tâches planifiées (cron)
Un cron intégré permet de rattraper ce que les hooks temps réel auraient manqué. Planifiez les URL affichées sur la page de configuration :
- `.../module/dfsellsy/cron?token=VOTRE_TOKEN&job=orders`
- `...&job=customers`
- `...&job=products`
- `...&job=retry` (relance les entités en erreur non encore liées)
Le paramètre `limit` (par défaut 20, max 100) contrôle la taille du lot par exécution.
## Journal de synchronisation
La page « Sellsy Connector » affiche un journal filtrable (par entité et par statut) de chaque opération, avec le message renvoyé par Sellsy en cas d'erreur. Un bouton _Relancer les erreurs_ rejoue les échecs en un clic.
## Dépannage
- **« Connexion échouée »** : vérifiez le Client ID / Client Secret et que les scopes nécessaires sont bien cochés dans Sellsy.
- **Une erreur sur un champ de document (HTTP 422)** : certains comptes Sellsy ont des exigences spécifiques (mentions e-invoicing, champs obligatoires). Consultez le message du journal pour identifier le champ concerné.
- **Doublons de tiers** : le module recherche par e-mail avant création ; assurez-vous que l'e-mail client est bien renseigné.
- **Rien ne se synchronise** : vérifiez que les options concernées sont actives et testez la connexion API.
---
### Cookie Manager Tarteaucitron — Guide complet
_Source :_
> Présentation Cookie Manager Tarteaucitron est un module de gestion du consentement aux cookies pour PrestaShop 8.0+ et 9.x. Il combine le moteur open-source tarteaucitron.js — qui bloque effectivement les services…
## Présentation
Cookie Manager Tarteaucitron est un module de gestion du consentement aux cookies pour PrestaShop 8.0+ et 9.x. Il combine le moteur open-source tarteaucitron.js — qui bloque effectivement les services avant consentement — avec une interface moderne style Axeptio : carte flottante animée, toggles par catégorie et bulle de réouverture. Le module intègre Google Consent Mode v2, un scanner de trackers avec activation automatique et un journal RGPD des consentements.
## Installation
1. Dans votre back-office PrestaShop, allez dans **Modules → Gestionnaire de modules → Installer un module**.
2. Téléversez le fichier `datafirefly_tarteaucitron.zip`.
3. Cliquez sur **Installer** puis sur **Configurer**.
Le module crée automatiquement la table de journal des consentements à l'installation. Si vous mettez à jour depuis une version 1.0.x, la table est créée à la première visite de la page de configuration — aucune réinstallation nécessaire.
Après toute mise à jour du module, videz le cache PrestaShop : **Paramètres avancés → Performances → Vider le cache**.
## Configuration générale
L'onglet **Général** contient les réglages de base :
- **Activer le module** : interrupteur principal de la bannière sur le front-office.
- **Nom du cookie** : nom du cookie de consentement (par défaut `tarteaucitron`). Ne le changez que si un autre outil entre en conflit.
- **Durée de vie du cookie** : 365 jours par défaut. La CNIL recommande un maximum de 13 mois (395 jours).
- **Bulle de réouverture** : affiche une petite bulle « Cookies » après le consentement, permettant au visiteur de modifier ses choix à tout moment — une exigence RGPD.
- **Lien politique de confidentialité** : URL de votre page CMS, affichée sous les boutons de la bannière.
L'onglet **Textes** permet de personnaliser le titre, le message et les libellés des trois boutons. L'onglet **Design** contrôle la couleur principale, les couleurs de fond et de texte des boutons.
## Activer les services
L'onglet **Services** liste les 11 intégrations prêtes à l'emploi. Pour chaque service, activez l'interrupteur et renseignez l'identifiant demandé :
- **Google Analytics 4** : Measurement ID au format G-XXXXXXXX
- **Google Tag Manager** : Container ID au format GTM-XXXXXX
- **Google Ads** : Conversion ID
- **Meta Pixel** : Pixel ID numérique
- **Hotjar** : Site ID numérique
- **LinkedIn Insight** : Partner ID
- **TikTok Pixel** : Pixel ID
- **Microsoft Clarity** : Project ID
- **Intercom** : App ID
- **YouTube** : aucun identifiant requis — active le blocage des vidéos embarquées avant consentement
- **Stripe** : aucun identifiant requis — voir la section dédiée ci-dessous
Un service activé sans identifiant ne sera pas chargé sur le front (sauf YouTube et Stripe qui n'en demandent pas). Vérifiez vos identifiants après avoir utilisé l'activation automatique du scanner.
## Scanner et détection automatique
L'onglet **Détection automatique** configure le module à votre place :
1. Cliquez sur **Scanner le site maintenant**. Le module lit les cookies présents sur votre domaine et récupère le HTML de votre front-office pour analyser les balises de scripts tiers.
2. Deux tableaux s'affichent : les cookies détectés (avec service probable et catégorie suggérée, modifiable) et les scripts tiers identifiés (avec leur statut dans le module).
3. La barre verte indique le nombre de services reconnus. Cliquez sur **Appliquer au module et sauvegarder** : les services correspondants sont activés et la configuration est enregistrée immédiatement.
4. Passez ensuite dans l'onglet Services pour renseigner les identifiants des services nouvellement activés.
Le scanner reconnaît notamment : Google Analytics, Google Ads, Meta Pixel, Hotjar, LinkedIn, TikTok, Microsoft Clarity, Intercom, Brevo, Stripe, ainsi que les cookies fonctionnels PrestaShop.
Naviguez d'abord sur votre front-office dans le même navigateur, puis lancez le scan : les cookies déposés par vos trackers seront visibles et la détection sera plus complète.
## Google Consent Mode v2
Obligatoire depuis mars 2024 pour les annonceurs européens, Consent Mode v2 permet à Google de modéliser les conversions même en cas de refus. L'onglet **Consent Mode** du module :
- émet les 7 signaux requis (ad_storage, ad_user_data, ad_personalization, analytics_storage, functionality_storage, personalization_storage, security_storage) en _default_ avant tout tag ;
- permet de configurer chaque état par défaut individuellement — `denied` est recommandé pour l'EEE ;
- met à jour les signaux automatiquement selon les choix du visiteur.
Particularité du module : au chargement de chaque page, l'état par défaut lit le cookie de consentement existant. Un visiteur ayant déjà accepté obtient `granted` dès la première frame — aucune fenêtre `denied` transitoire qui amputerait vos conversions Google Ads au rechargement.
## Stripe et les cookies essentiels
Les cookies Stripe (`__stripe_mid`, `__stripe_sid`) sont strictement nécessaires à la prévention de la fraude au paiement. Ils relèvent de l'exemption de consentement prévue pour les traceurs essentiels : les bloquer casserait le tunnel de commande.
Le module les traite en conséquence : lorsque le service Stripe est activé, il se charge sans demande de consentement et apparaît dans le panneau de préférences sous la catégorie **Essentiels et paiement** avec le badge « Toujours actif ». Transparence totale pour le visiteur, zéro paiement bloqué.
## Services personnalisés
L'onglet **Services personnalisés** permet d'ajouter n'importe quel script tiers absent de la liste :
- **Clé** : identifiant technique unique en minuscules (ex. `monchat`)
- **Nom** : libellé affiché dans la bannière
- **Catégorie** : analytic, ads, social, support, api ou other
- **Code JavaScript** : le code de chargement du service, exécuté uniquement après consentement
- **Cookies** : liste des noms de cookies déposés, séparés par des virgules
- **URL de politique** : lien vers la politique de confidentialité du service
Les services personnalisés apparaissent dans la bannière sous une catégorie dédiée avec leur propre toggle.
## Journal RGPD des consentements
L'article 7 du RGPD impose de pouvoir démontrer que le consentement a été donné. L'onglet **Journal RGPD** affiche les 50 derniers enregistrements avec, pour chaque action :
- la date et l'heure ;
- l'identifiant visiteur anonyme (cookie technique dédié, aucune donnée personnelle) ;
- les catégories acceptées ;
- le détail des choix service par service.
Points clés du fonctionnement :
- L'adresse IP n'est **jamais stockée en clair** : elle est hashée en SHA-256 avec un salt serveur, conformément aux recommandations CNIL.
- Une déduplication serveur ignore les enregistrements identiques du même visiteur dans les 5 secondes (double-clic).
- Une purge automatique supprime les entrées de plus de 3 ans à chaque visite de la page de configuration.
- Le journal est **conservé en cas de désinstallation** du module afin de préserver votre piste d'audit.
## Dépannage
- **La bannière ne s'affiche pas** : vérifiez que le module est activé dans l'onglet Général, puis videz le cache PrestaShop. Vérifiez aussi qu'aucun autre module de consentement n'est actif en parallèle.
- **Les choix ne sont pas mémorisés** : assurez-vous d'utiliser la version 1.1.0 ou supérieure, qui écrit le cookie au format natif tarteaucitron. Videz le cache navigateur et supprimez l'ancien cookie de consentement avant de retester.
- **Un service ne se charge pas après acceptation** : vérifiez que son identifiant est renseigné dans l'onglet Services. Ouvrez la console navigateur pour repérer d'éventuelles erreurs.
- **Le scan ne détecte rien** : naviguez d'abord sur le front-office dans le même navigateur, puis relancez le scan. Si l'admin et le front sont sur des domaines différents, seule l'analyse des scripts fonctionne.
- **Aucun enregistrement dans le journal** : visitez la page de configuration du module (la table est créée automatiquement si absente), puis effectuez un nouveau consentement depuis le front en navigation privée.
Besoin d'aide ? Contactez le support DataFirefly depuis votre espace client — réponse sous 24 h ouvrées.
---
### Corbeille Produits — Guide complet
_Source :_
> Présentation Le module Corbeille Produits transforme chaque suppression de produit en sauvegarde réversible. Juste avant qu'un produit ne soit effacé — manuellement, en suppression groupée, par un import ou par…
## Présentation
Le module Corbeille Produits transforme chaque suppression de produit en sauvegarde réversible. Juste avant qu'un produit ne soit effacé — manuellement, en suppression groupée, par un import ou par un script — le module en réalise un instantané complet et le place dans une corbeille. Vous pouvez ensuite restaurer le produit à l'identique en un clic, avec son ID d'origine, ce qui préserve ses URLs et son référencement.
La capture couvre les données en base (fiche, traductions, déclinaisons, prix, stocks, catégories, caractéristiques, etc.) ainsi que les fichiers images sur le disque. Le module est compatible PrestaShop 8 et 9, en mono comme en multi-boutique, et multilingue.
## Installation
1. Depuis le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez l'archive ZIP du module.
3. Une fois l'installation terminée, cliquez sur **Configurer**.
À l'installation, le module crée une table de sauvegarde dédiée, un dossier de sauvegarde protégé pour les images, et un nouvel onglet **Corbeille produits** dans le menu **Catalogue**. La surveillance des suppressions est active immédiatement, sans configuration préalable.
## Accéder à la corbeille
La corbeille est accessible de deux façons : via le menu **Catalogue > Corbeille produits**, ou via le bouton **Ouvrir la corbeille** présent sur la page de configuration du module. La liste affiche les produits sauvegardés et non encore restaurés, avec leur ID produit d'origine, leur nom, leur référence, le nombre d'images sauvegardées, l'auteur de la suppression et la date.
## Comment fonctionne la sauvegarde
Le module s'accroche au hook `actionObjectProductDeleteBefore`, déclenché par PrestaShop juste avant l'effacement d'un produit, au moment où toutes ses données sont encore présentes en base. Ce hook est emprunté aussi bien par l'ancienne page produit que par la nouvelle page Symfony de PrestaShop 8 et 9, ainsi que par les suppressions groupées : chaque produit supprimé est donc sauvegardé individuellement.
L'instantané capturé comprend :
- la fiche produit, ses versions par boutique et ses traductions pour toutes les langues ;
- les déclinaisons, leurs attributs et leurs versions par boutique ;
- les prix spécifiques, les stocks et les associations catégories ;
- les caractéristiques, les tags, les fournisseurs et les transporteurs ;
- les pièces jointes, les produits associés, les packs et les produits virtuels téléchargeables ;
- les champs de personnalisation et leurs traductions ;
- les fichiers images, dans toutes les tailles générées, copiés dans un dossier de sauvegarde protégé.
La capture est silencieuse et ne bloque jamais la suppression. Si une étape de sauvegarde échoue pour une raison quelconque, PrestaShop poursuit la suppression normalement : le module ne perturbe pas le fonctionnement de la boutique.
## Restaurer un produit
1. Ouvrez **Catalogue > Corbeille produits**.
2. Repérez le produit à restaurer dans la liste (vous pouvez filtrer et trier les colonnes).
3. Cliquez sur le bouton vert **Restaurer** et confirmez.
Le module réinjecte alors toutes les tables liées dans une transaction unique, en conservant les identifiants d'origine, recopie les fichiers images à leur emplacement exact, puis relance l'indexation de la recherche. Le produit réapparaît dans votre catalogue tel qu'il était avant sa suppression, et son entrée disparaît de la corbeille. Le HTML des descriptions est préservé au caractère près.
**Anti-conflit.** La restauration vérifie d'abord que l'ID produit est libre. Si un autre produit porte déjà cet identifiant, la restauration est annulée et un message vous l'indique, afin de ne jamais écraser une fiche existante. En pratique, PrestaShop ne réutilise pas les identifiants supprimés, ce cas reste donc rare.
## Supprimer définitivement et vider la corbeille
Pour libérer de l'espace, vous pouvez supprimer définitivement une sauvegarde à l'unité avec le bouton rouge de la colonne **Actions**. Cette action supprime l'instantané et les fichiers images associés ; elle est irréversible.
Le bouton **Vider la corbeille**, en haut de la liste, supprime définitivement toutes les sauvegardes non restaurées en une seule opération.
## Configuration
### Sauvegarder les fichiers images
Lorsque cette option est activée (par défaut), le module copie les fichiers images de toutes les tailles à la suppression et les remet en place à la restauration. Désactivez-la si vous souhaitez ne sauvegarder que les données et économiser de l'espace disque ; dans ce cas, les lignes images restent dans l'instantané mais les fichiers ne sont pas restaurés.
### Rétention (jours)
Définissez le nombre de jours au-delà duquel les sauvegardes sont purgées automatiquement. La valeur **0** conserve les sauvegardes sans limite de durée. La purge s'exécute au fil des suppressions suivantes.
## Multiboutique et multilingue
L'instantané capture toutes les langues et toutes les boutiques associées au produit, et la restauration les rétablit intégralement. Le module fonctionne aussi bien sur une boutique unique que sur un multiboutique PrestaShop.
## Bonnes pratiques et cas particuliers
- **Gros catalogues :** chaque suppression crée une sauvegarde. Définissez une rétention adaptée pour éviter une accumulation inutile si vous supprimez fréquemment de nombreux produits (imports de remplacement, par exemple).
- **Dossier de sauvegarde :** il est protégé par un `.htaccess` et un `index.php`, et n'est donc pas accessible publiquement. Il doit rester accessible en écriture par le serveur.
- **Imports :** un import qui supprime puis recrée des produits remplit la corbeille des versions supprimées. C'est volontaire et utile en cas d'import raté ; pensez à vider la corbeille une fois l'import validé.
## Désinstallation
La désinstallation du module supprime la table de sauvegarde, l'onglet du menu et l'ensemble du dossier de sauvegarde (instantanés et fichiers images). Les produits déjà restaurés et présents dans le catalogue ne sont pas affectés.
## FAQ
### La corbeille fonctionne-t-elle avec la suppression groupée et la nouvelle page produit ?
Oui. La capture repose sur un hook emprunté par l'ancienne page produit, la nouvelle page Symfony de PrestaShop 8 et 9, et les suppressions groupées. Chaque produit supprimé est sauvegardé individuellement.
### La restauration garde-t-elle le même ID produit ?
Oui. Le produit est restauré avec son identifiant d'origine, ce qui préserve ses URLs, ses redirections et son référencement. Si l'identifiant est déjà occupé, la restauration est bloquée.
### Les images sont-elles restaurées, fichiers compris ?
Oui, lorsque l'option de sauvegarde des images est activée. Les fichiers de toutes les tailles sont copiés à la suppression et remis en place à la restauration, puis la recherche est réindexée.
### Le module est-il compatible PrestaShop 9 ?
Oui, le module est compatible PrestaShop 8.x et 9.x, en mono comme en multi-boutique.
---
### Core Web Vitals PrestaShop — Suivi CrUX par template (dfcoreweb)
_Source :_
> DataFirefly Core Web Vitals interroge l'API Chrome UX Report (CrUX) de Google et rapatrie dans votre back-office les métriques de performance réellement mesurées chez vos visiteurs, séparément pour chaque type…
DataFirefly Core Web Vitals interroge l'API Chrome UX Report (CrUX) de Google et rapatrie dans votre back-office les métriques de performance réellement mesurées chez vos visiteurs, séparément pour chaque type de page : accueil, catégorie, fiche produit, panier, page CMS et origine agrégée. Le module conserve l'historique complet, détecte les régressions et traduit chaque métrique dégradée en actions concrètes côté PrestaShop.
Cette documentation couvre la version **1.0.0** du module, compatible PrestaShop **8.0.0 à 9.x** et PHP **8.1+**. Module strictement back-office : aucun hook front, aucun JavaScript côté visiteur, aucune dépendance Composer.
## Prérequis : la clé API Chrome UX Report
Le module a besoin d'une clé API Google pour interroger CrUX. Elle est gratuite et s'obtient en quatre étapes :
1. Ouvrez la **Google Cloud Console** et créez un projet (ou sélectionnez un projet existant).
2. Dans **API et services > Bibliothèque**, recherchez **Chrome UX Report API** et cliquez sur **Activer**.
3. Dans **API et services > Identifiants**, cliquez sur **Créer des identifiants** puis **Clé API**.
4. Copiez la clé générée (elle commence par `AIzaSy`) et collez-la dans la configuration du module.
Le quota gratuit est de 150 requêtes par minute et 30 000 requêtes par jour. Une synchronisation complète du module consomme environ 12 appels : vous utilisez donc moins de 0,05 % du quota quotidien. Aucune carte bancaire n'est requise.
## Installation
1. Dans votre back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez le fichier `dfcoreweb.zip`.
3. Cliquez sur **Configurer** une fois l'installation terminée.
L'installation crée trois tables (URLs suivies, snapshots historiques, journal des recommandations masquées) et ajoute un menu **DataFirefly Core Web Vitals** sous **Améliorer**, avec quatre onglets : Dashboard, Configuration, Historique et Recommandations.
## Configuration
### Clé API
Collez votre clé Chrome UX Report dans le champ prévu et enregistrez. Tant que ce champ est vide, le tableau de bord affiche un avertissement et aucune synchronisation n'est possible.
### Form factors suivis
CrUX publie ses métriques séparément par type d'appareil. Trois cases à cocher permettent de choisir ceux que vous suivez :
- **Mobile** — activé par défaut, c'est le form factor utilisé par Google pour l'évaluation de l'expérience de page.
- **Bureau** — activé par défaut, utile si votre trafic desktop est significatif.
- **Tablette** — désactivé par défaut, CrUX dispose rarement de données suffisantes sur ce segment.
Chaque form factor supplémentaire multiplie le nombre d'appels quotidiens, sans risque de dépassement de quota compte tenu des volumes en jeu.
### URLs suivies
Par défaut, le module choisit lui-même une URL représentative par type de page : la page d'accueil, la catégorie contenant le plus de produits, le produit le plus vendu, la page panier et la première page CMS active. Il interroge également l'**origine**, c'est-à-dire l'agrégation de tout le domaine.
Trois champs permettent de reprendre la main en saisissant des identifiants séparés par des virgules :
- **IDs produits** — pour suivre une fiche précise plutôt que le best-seller courant.
- **IDs catégories** — pour suivre une catégorie stratégique.
- **IDs pages CMS** — pour suivre une landing page ou une page de contenu à fort trafic.
Privilégiez des URL à fort trafic. CrUX ne publie de données que lorsqu'un seuil minimal de visites Chrome est atteint : une fiche produit confidentielle remontera systématiquement en « données insuffisantes ».
### Rétention des données
Le champ **Durée de rétention** (365 jours par défaut) définit l'ancienneté au-delà de laquelle les snapshots sont purgés. La purge s'exécute à chaque synchronisation, et un bouton du tableau de bord permet de la déclencher manuellement.
### Alertes de régression
- **Notifier en cas de régression** — active l'envoi d'e-mails.
- **Adresse e-mail** — destinataire des alertes ; laissez vide pour utiliser l'adresse de la boutique.
- **Seuil de régression** — pourcentage de dégradation déclenchant l'alerte, 15 % par défaut.
Après chaque synchronisation, la nouvelle valeur de chaque métrique est comparée à la moyenne des sept derniers jours. Si l'écart dépasse le seuil, un e-mail HTML et texte est envoyé avec le détail du delta et un lien direct vers le tableau de bord.
## Synchronisation automatique
La page de configuration affiche une URL de synchronisation protégée par un jeton dérivé de la clé de sécurité de votre boutique. Appelez-la une fois par jour depuis votre planificateur de tâches :
```
0 6 * * * curl -s "https://votre-boutique.com/index.php?fc=module&module=dfcoreweb&controller=cron&token=VOTRE_JETON" > /dev/null
```
Sous Windows, utilisez le Planificateur de tâches ; sur un hébergement mutualisé, le module Crontab Manager de PrestaShop ou le planificateur de votre panneau d'administration font aussi l'affaire.
Inutile de synchroniser plus d'une fois par jour : CrUX agrège ses données sur une fenêtre glissante de 28 jours et ne les rafraîchit qu'une fois par 24 heures. Un appel plus fréquent renverra les mêmes valeurs.
Le bouton **Lancer une synchronisation** du tableau de bord permet de déclencher immédiatement une collecte, utile pour valider la configuration juste après l'installation.
## Lire le tableau de bord
Le tableau de bord affiche une tuile par type de page, avec la dernière valeur connue de chaque métrique et un code couleur reprenant les seuils officiels de Google :
- **LCP** (Largest Contentful Paint) — bon jusqu'à 2,5 s, à améliorer jusqu'à 4 s, mauvais au-delà.
- **INP** (Interaction to Next Paint) — bon jusqu'à 200 ms, à améliorer jusqu'à 500 ms, mauvais au-delà.
- **CLS** (Cumulative Layout Shift) — bon jusqu'à 0,1, à améliorer jusqu'à 0,25, mauvais au-delà.
- **FCP** (First Contentful Paint) — bon jusqu'à 1,8 s, à améliorer jusqu'à 3 s.
- **TTFB** (Time To First Byte) — bon jusqu'à 0,8 s, à améliorer jusqu'à 1,8 s.
Toutes les valeurs sont exprimées au **75e centile** : elles représentent l'expérience des 25 % de visiteurs les moins bien servis, conformément à la méthodologie de Google. Une boutique est considérée comme « réussissant » l'évaluation lorsque LCP, INP et CLS sont simultanément dans le vert.
## Historique
L'onglet Historique superpose l'évolution de chaque métrique sur 30, 90, 180 ou 365 jours, pour un type de page et un form factor donnés. Les graphiques affichent en pointillés les seuils de Google, ce qui rend immédiatement lisible le passage d'une zone à l'autre. Une courbe supplémentaire suit le pourcentage de visites classées « bonnes » sur les trois métriques principales.
C'est la vue à consulter après une mise en production, une migration de thème ou l'ajout d'un script tiers : une dégradation de LCP apparaît généralement dans les jours qui suivent, décalée par la fenêtre glissante de 28 jours.
## Recommandations
Chaque métrique hors seuil génère une ou plusieurs recommandations rattachées au type de page concerné, triées par sévérité :
- **Critique** — métrique dans la zone rouge, impact direct sur le référencement et la conversion.
- **Avertissement** — métrique dans la zone orange, marge de progression significative.
- **Information** — bonne pratique applicable même en zone verte.
Les conseils sont formulés en vocabulaire PrestaShop : format et préchargement de l'image de couverture sur une fiche produit, dimensions explicites des miniatures de la grille catégorie, nombre de modules greffés sur les hooks d'en-tête, compression et cache serveur pour le TTFB, différé des scripts tiers pour l'INP. Chaque recommandation porte une estimation d'impact business calibrée sur l'étude Deloitte « Milliseconds Make Millions ».
Le bouton **Masquer** retire une recommandation de la liste pendant 30 jours, le temps de traiter le sujet ou d'acter qu'il n'est pas prioritaire.
## Le statut « données insuffisantes »
CrUX ne publie une métrique que lorsque suffisamment de visiteurs Chrome ont chargé l'URL sur la période. En dessous de ce seuil, l'API répond que l'enregistrement n'existe pas : le module enregistre alors un statut « données insuffisantes » sans erreur ni interruption de la collecte.
Si c'est le cas de la plupart de vos pages, appuyez-vous sur la ligne **Origine** : l'agrégation de tout le domaine atteint le seuil bien plus facilement et reste représentative de l'expérience moyenne de votre boutique.
## Vie privée et hébergement des données
Aucune donnée client n'est transmise à Google. Seules les URL publiques que vous avez choisi de suivre sont envoyées à l'API CrUX, et les métriques renvoyées sont déjà anonymisées et agrégées par Google. Tous les relevés sont stockés dans votre propre base de données PrestaShop. La bibliothèque de graphiques est embarquée dans le module : aucun appel à un CDN externe, aucune télémétrie, aucun script d'analyse côté visiteur.
## Dépannage
- **Erreur d'authentification à la synchronisation** — la clé API est absente, mal recopiée, ou l'API Chrome UX Report n'a pas été activée sur le projet Google Cloud. Vérifiez également qu'aucune restriction d'adresse IP ou de référent HTTP n'est appliquée à la clé.
- **Toutes les lignes en « données insuffisantes »** — le trafic Chrome sur ces URL est trop faible. Suivez l'origine, et choisissez manuellement des pages à fort trafic.
- **L'appel cron renvoie une erreur d'autorisation** — le jeton de l'URL ne correspond plus. Il dépend du nom de la boutique et de la clé de sécurité de l'installation : recopiez l'URL affichée dans la configuration après tout changement de nom de boutique.
- **Le menu n'apparaît pas après l'installation** — videz le cache dans **Paramètres avancés > Performances**, puis vérifiez les permissions de votre profil employé sur les nouveaux onglets.
- **Les graphiques restent vides** — il faut au minimum deux synchronisations à des dates différentes pour tracer une courbe. Patientez 24 heures après la première collecte.
## Désinstallation
La désinstallation supprime les trois tables du module, l'ensemble des clés de configuration et les onglets du back-office. L'historique des mesures est définitivement perdu : exportez vos données auparavant si vous souhaitez les conserver. Une confirmation explicite est demandée avant l'opération.
---
### Database Manager Back Office — Adminer pour PrestaShop : installation, configuration, dépannage
_Source :_
> Le module Database Manager Back Office (référence interne dfdbmanager) intègre Adminer 5.4.2 directement dans le back office PrestaShop 8 et 9. Plus besoin de cPanel ni de phpMyAdmin externe :…
Le module **Database Manager Back Office** (référence interne `dfdbmanager`) intègre Adminer 5.4.2 directement dans le back office PrestaShop 8 et 9. Plus besoin de cPanel ni de phpMyAdmin externe : un clic dans le menu _Paramètres Avancés > Adminer_ et vous gérez votre base de données, déjà authentifié.
**En une phrase** — installez le ZIP, ouvrez le menu Adminer, gérez votre BDD. L'auto-login utilise les credentials de la boutique, l'accès est restreint au profil SuperAdmin.
## Pré-requis
- **PrestaShop** : 8.0.0 à 9.99.99 (testé sur 8.0, 8.1, 8.2, 9.0)
- **PHP** : 7.4 ou supérieur (compatible 8.0, 8.1, 8.2, 8.3)
- **Base de données** : MySQL 5.7+ ou MariaDB 10.3+
- **Compte employé** : profil SuperAdmin (id_profile = 1) pour ouvrir Adminer
- **Hébergement** : compatible mutualisé (o2switch, OVH, Infomaniak), VPS, dédié
Aucune connexion sortante n'est requise depuis votre serveur : Adminer 5.4.2 est bundlé dans le ZIP du module (508 KB, fichier unique).
## Installation
### 1. Uploader le ZIP
Dans votre back office PrestaShop :
1. Allez dans _Modules > Gestionnaire de modules_
2. Cliquez sur _Installer un module_ en haut à droite
3. Glissez-déposez le fichier `dfadminer-1.0.0.zip` ou cliquez pour le sélectionner
4. Attendez la fin de l'upload (quelques secondes — le ZIP fait moins de 400 KB)
5. Le module s'installe automatiquement
### 2. Vérifier l'onglet de menu
L'installation crée automatiquement un onglet de menu sous _Paramètres Avancés > Adminer_, avec une icône de stockage Material. L'onglet est créé en cinq langues (français, anglais, espagnol, allemand, italien) — la langue active s'affichera selon votre profil employé.
**Si l'onglet n'apparaît pas** — videz le cache PrestaShop (_Paramètres Avancés > Performances > Vider le cache_) puis rechargez le menu. Sur PrestaShop 9, déconnectez-vous et reconnectez-vous au back office.
## Premier accès à Adminer
### Ouvrir le menu
Naviguez vers _Paramètres Avancés > Adminer_. Vous arrivez directement sur la liste des tables de votre base PrestaShop, sans écran d'authentification, sans formulaire à remplir.
La page se compose de :
- Une bannière fixe en haut, en dark navy, avec le nom de votre base à gauche et un bouton bleu _Back to PrestaShop BO_ à droite
- L'interface Adminer en dessous : sidebar des tables à gauche, contenu principal à droite
### Auto-login : comment ça marche
Le module lit les credentials de votre base depuis la configuration PrestaShop (les constantes `_DB_SERVER_`, `_DB_USER_`, `_DB_PASSWD_`, `_DB_NAME_` définies dans `config/parameters.php` ou `config/settings.inc.php`) et démarre la session Adminer côté serveur avec ces credentials avant qu'Adminer ne se charge. Aucun nouveau mot de passe n'est créé, aucune permission MySQL n'est étendue — Adminer utilise exactement les mêmes droits que PrestaShop.
**Sessions Adminer par employé** — chaque employé SuperAdmin aura sa propre session Adminer (les sessions PHP sont par cookie navigateur), mais tous se connectent à la même base avec les mêmes credentials système. Pas de gestion de comptes Adminer à faire.
## Page de configuration du module
Depuis _Modules > Gestionnaire de modules_, cherchez _Database Manager Back Office_ et cliquez sur _Configurer_. La page propose trois sections.
### Statut
Affiche :
- Version d'Adminer installée localement (5.4.2 par défaut)
- Chemin du fichier `adminer.php` dans le module
- Variante installée (Adminer complet ou Adminer Editor)
- Taille du fichier
### Mettre à jour Adminer
Quand une nouvelle version stable d'Adminer sort sur `adminer.org`, vous pouvez la télécharger directement depuis cette page. Cliquez sur _Update to latest Adminer_ — le module récupère le fichier depuis `adminer.org/latest-en.php` via cURL (ou file_get_contents en fallback) et remplace le fichier local.
**Connexion sortante requise** — le téléchargement nécessite que votre serveur puisse joindre `adminer.org` en HTTPS. Sur certains hébergements mutualisés très restrictifs, les connexions sortantes sont bloquées. Dans ce cas, téléchargez manuellement le fichier depuis `adminer.org` et remplacez-le dans `modules/dfadminer/views/adminer/adminer.php` via FTP.
### Basculer vers Adminer Editor
Adminer publie aussi une variante _Editor_ — l'interface est identique mais le champ d'exécution SQL brut est retiré. Seule la navigation dans les tables et l'édition de lignes restent disponibles. Utile si vous voulez donner accès à un profil moins technique sans risquer qu'il exécute du SQL libre.
Cliquez sur _Switch to Adminer Editor_ pour télécharger et remplacer le fichier. Vous pouvez revenir à Adminer complet à tout moment avec _Switch back to full Adminer_.
## Modèle de sécurité
### Restriction SuperAdmin
Adminer est un outil puissant : qui a accès à votre base a accès à tout (commandes, clients, paiements, mots de passe hashés employés). Pour cette raison, le module restreint l'accès au profil **SuperAdmin uniquement** — c'est-à-dire `id_profile = 1` dans PrestaShop.
Les autres profils (Logisticien, Traducteur, Vendeur, profils personnalisés) reçoivent un message _Access Denied_ s'ils tentent d'ouvrir Adminer, même s'ils connaissent l'URL.
### Double vérification serveur
La restriction est appliquée deux fois côté serveur dans le contrôleur :
- Dans `postProcess()` — avant qu'Adminer ne tourne
- Dans `initContent()` — au rendu UI de fallback
Cette double vérification garantit qu'aucun chemin de code ne contourne le gate, même en cas de comportement inattendu du routeur PrestaShop.
### Blocage HTTP direct du fichier adminer.php
Le fichier `views/adminer/adminer.php` est bloqué à l'accès HTTP direct via un `.htaccess` avec la directive `Require all denied`. Tenter d'ouvrir directement l'URL `/modules/dfadminer/views/adminer/adminer.php` retourne un 403 Forbidden. La seule façon d'atteindre Adminer est de passer par le contrôleur PrestaShop, qui applique le gate SuperAdmin.
## Utilisation d'Adminer pour PrestaShop
### Tables courantes à connaître
Quelques tables fréquemment utiles pour le debug PrestaShop (préfixe `ps_` par défaut, peut varier selon votre installation) :
- **ps_configuration** — toutes les variables de configuration (clés/valeurs)
- **ps_orders** — commandes
- **ps_customer** — clients
- **ps_product** + **ps_product_lang** — produits et leurs traductions
- **ps_employee** — employés du BO
- **ps_log** — journal d'erreurs PrestaShop
- **ps_cart** + **ps_cart_product** — paniers
- **ps_specific_price** — promotions et règles de prix
### Exécuter une requête SQL
Dans la sidebar gauche, cliquez sur _SQL command_. Tapez votre requête, cliquez sur _Execute_. Adminer affiche le résultat en bas, avec pagination automatique pour les gros résultats.
**Conseil** — Adminer mémorise l'historique de vos requêtes SQL dans la session. Vous pouvez naviguer dans l'historique via le menu _History_ en bas de page, et réexécuter une requête en un clic.
### Exporter une table
Sur une table donnée, cliquez sur _Export_. Adminer propose plusieurs formats : SQL (avec ou sans données), CSV, TSV. Pour les très grosses tables, l'export se fait en streaming chunked — pas de problème de mémoire PHP.
### Éditer une ligne en place
Sur n'importe quelle table, cliquez sur _Select data_, puis sur le crayon à gauche d'une ligne. Vous éditez tous les champs dans un formulaire, vous sauvegardez d'un clic. Adminer génère automatiquement la requête UPDATE.
## Multi-employés SuperAdmin
Si vous avez plusieurs employés avec le profil SuperAdmin, chacun aura sa propre session Adminer indépendante. Concrètement :
- Employé A ouvre Adminer dans son navigateur — sa session adminer_sid est créée
- Employé B fait pareil dans le sien — sa propre session adminer_sid est créée
- Les deux peuvent naviguer dans Adminer en parallèle sans interférence
- Quand A se déconnecte du BO PrestaShop, sa session Adminer reste valide jusqu'à la fermeture du navigateur (puis expire)
Tous les employés se connectent à la même base avec les mêmes credentials système — il n'y a pas de comptes Adminer séparés à gérer.
## Mise à jour du module
Pour mettre à jour le module vers une version plus récente :
1. Téléchargez le nouveau ZIP depuis votre espace client DataFirefly
2. Dans le BO, _Modules > Gestionnaire de modules_
3. Cliquez sur _Installer un module_ et uploadez le nouveau ZIP
4. PrestaShop détecte qu'une version existe déjà et propose de la mettre à jour
5. Confirmez — le module est mis à jour sans perdre la configuration
Aucune table BDD n'étant créée, il n'y a pas de migration de schéma à gérer entre versions.
## Désinstallation
Pour désinstaller proprement le module :
1. Allez dans _Modules > Gestionnaire de modules_
2. Trouvez _Database Manager Back Office_
3. Cliquez sur _Désinstaller_ dans le menu déroulant
La désinstallation :
- Supprime l'onglet de menu _Paramètres Avancés > Adminer_
- Retire les fichiers du module (y compris le fichier `adminer.php` bundlé)
- Ne touche à aucune table — votre base PrestaShop reste intacte
- Ne modifie aucune configuration PrestaShop, aucun mot de passe, aucune permission
La désinstallation est totalement réversible : réinstallez le module pour retrouver Adminer dans le même état.
## Dépannage
### L'écran d'authentification Adminer s'affiche au lieu de la liste des tables
Symptôme : vous ouvrez le menu Adminer et voyez le formulaire _Authentification_ d'Adminer (champs _System_, _Server_, _Username_, _Password_, _Database_) au lieu de la liste des tables.
Cause probable : un ancien cookie Adminer (de l'installation précédente ou d'un autre site Adminer) interfère avec la session pré-populée.
**Solution** :
1. Ouvrez les DevTools de votre navigateur (F12)
2. Allez dans l'onglet _Application_ (Chrome) ou _Stockage_ (Firefox)
3. Section _Cookies_, sélectionnez votre domaine
4. Supprimez les cookies nommés `adminer_sid`, `adminer_permanent`, `adminer_key` et `adminer_version`
5. Rechargez la page Adminer avec Ctrl+Shift+R
### Erreur 403 Forbidden au chargement
Symptôme : la page Adminer retourne un statut HTTP 403, parfois avec le formulaire d'authentification visible en dessous.
Cause probable : Adminer ne reconnaît pas la session pré-populée et tombe dans son code-path `auth_error` qui ajoute explicitement `HTTP/1.1 403 Forbidden` quand `$_GET[username]` est défini mais que l'authentification échoue.
**Solution** : même procédure que ci-dessus — videz les cookies Adminer du navigateur. Si le problème persiste, vérifiez que les credentials PrestaShop dans `config/parameters.php` (PS9) ou `config/settings.inc.php` (PS8) sont corrects et que PrestaShop arrive bien à se connecter à MySQL (le BO PrestaShop fonctionne-t-il normalement ?).
### Les liens Adminer ramènent au dashboard PrestaShop
Symptôme : vous cliquez sur un nom de table dans la sidebar Adminer et vous arrivez sur le dashboard PrestaShop au lieu de la page de la table.
Cause probable : le post-processing des URLs (qui injecte `controller=AdminDfAdminer` dans les URLs internes d'Adminer) n'a pas fonctionné. Le plus souvent : un cache HTML ou un proxy intermédiaire qui sert une version stale de la page.
**Solution** :
1. Videz le cache PrestaShop (_Paramètres Avancés > Performances > Vider le cache_)
2. Videz le cache navigateur (Ctrl+Shift+R)
3. Si un CDN ou un cache HTTP est en amont (Cloudflare, Varnish), purgez son cache pour les URLs `/admin*/index.php`
### Mode sombre : la bannière ou Adminer ne s'adaptent pas
La bannière du module s'adapte automatiquement au mode sombre du système via la media query `@media (prefers-color-scheme: dark)`. Adminer 5 a aussi son propre mode sombre intégré qui suit la même préférence système.
Si le rendu ne suit pas votre mode système :
- Vérifiez que votre OS est bien en mode sombre (Windows : _Paramètres > Personnalisation > Couleurs > Mode sombre_ ; macOS : _Préférences Système > Général > Apparence : Sombre_)
- Le navigateur doit transmettre cette préférence — par défaut Chrome et Firefox le font, mais certaines extensions de gestion de thèmes peuvent overrider
- Vérifiez avec DevTools _Rendering > Emulate CSS media feature prefers-color-scheme_ que la préférence est bien _dark_
### Invalid Security Token sur une action Adminer
Symptôme : vous exécutez une requête SQL ou éditez une ligne, et PrestaShop affiche _Invalid Security Token_.
Cause probable : ce message n'apparaît normalement jamais avec le module — le contrôleur override `checkToken()` pour bypasser le CSRF PrestaShop sur les actions internes d'Adminer. Si vous le voyez, c'est que vous accédez à une URL qui ne passe pas par notre contrôleur.
**Solution** : vérifiez que l'URL dans la barre du navigateur commence bien par `index.php?controller=AdminDfAdminer&token=...`. Si elle commence par `index.php?select=...` sans le paramètre controller, le post-processing des URLs a été contourné — videz les caches PrestaShop et navigateur, et rouvrez Adminer depuis le menu.
## Architecture technique
Pour les développeurs ou les administrateurs curieux qui veulent comprendre comment fonctionne le module en interne.
### Auto-login : pré-population de session
Le loader `views/adminer/loader.php` démarre la session Adminer avant que `adminer.php` ne se charge :
1. Ferme toute session PHP en cours via `session_write_close()` (PS9 peut en avoir démarrée une via Symfony)
2. Démarre une nouvelle session avec `session_name('adminer_sid')`
3. Pré-populate `$_SESSION[pwds][server][host][user]` avec le vrai mot de passe de la base, lu depuis `_DB_PASSWD_`
4. Pré-populate `$_SESSION[db][server][host][user][dbname] = true`
5. Définit `$_GET[username]`, `$_GET[db]`, `$_GET[server]` aux valeurs PrestaShop
6. Charge `adminer.php`
Quand Adminer s'initialise, il voit que la constante `SID` est déjà définie et skip son propre `session_start()`. Il voit `$_SESSION[pwds]` non-vide et skip la restauration via cookie permanent. La vérification d'authentification passe directement, `Driver::connect()` utilise le vrai mot de passe via la méthode `credentials()` de notre classe, et `login()` retourne true.
### Bypass du CSRF PrestaShop
Les formulaires POST internes d'Adminer (exécution de requête SQL, édition de ligne, suppression de table) ne portent pas le token CSRF par contrôleur de PrestaShop. Sans intervention, PS rejette ces requêtes avec un écran _Invalid Security Token_.
Le contrôleur `AdminDfAdminerController` override la méthode `checkToken()` pour retourner true sans vérification. C'est sûr parce que le gate SuperAdmin (`id_profile === 1`) en amont est strictement plus fort qu'un token CSRF : un attaquant qui aurait déjà une session SuperAdmin volée a déjà accès à tout le back office de toute façon.
### Réécriture des URLs Adminer
Adminer construit ses liens internes comme `index.php?select=table_name&db=ps`. Sans réécriture, ces URLs ne portent pas `controller=AdminDfAdminer` et PrestaShop les routerait vers le dashboard.
Le contrôleur appelle `ob_start()` avec un callback qui post-process la sortie HTML d'Adminer : injection de la bannière de retour BO en début de body, et réécriture de tous les attributs `href`, `action` et `src` qui pointent vers `index.php?...` pour y injecter `controller=AdminDfAdminer&` juste après le `?`.
### Survie aux exit; d'Adminer
Adminer fait 19 appels à `exit;` à divers endroits (page_footer, file= serving pour les assets, fin d'erreur). Un simple `ob_get_clean()` à la fin du contrôleur ne serait jamais atteint dans ces cas.
La solution : passer le callback de post-processing directement à `ob_start()`. Le callback est appelé automatiquement par PHP au moment du flush final du buffer, même si `exit;` a été appelé. Toutes les sorties d'Adminer passent donc par le post-processing, sans exception.
## Compatibilité PrestaShop 9
Le module est testé sur PrestaShop 8.0, 8.1, 8.2 et 9.0. La compatibilité PS 9 est obtenue en utilisant exclusivement les patterns legacy supportés par les deux versions :
- `ModuleAdminController` au lieu de Symfony controllers — supporté en PS 8 et PS 9
- Smarty pour le template de configuration — supporté nativement
- Installation d'onglet via la classe `Tab` — API stable entre versions
- Pas de classes Symfony spécifiques, pas de bundle requis
- PSR-4 autoload sans Composer (chargé via `require_once` dans le main module)
Sur PS 9, le module fonctionne sans modification, sans recompilation, sans `composer install`.
## Licence et code source
Le module DataFirefly est sous licence commerciale (DataFirefly Limited, Ireland). Le code source est livré **non chiffré** dans le ZIP — vous pouvez l'auditer, étendre les hooks, ou adapter le comportement (par exemple ajouter d'autres profils autorisés à ouvrir Adminer).
Adminer lui-même est sous double licence **Apache 2.0 / GPL 2.0**, créé par Jakub Vrana. Le fichier `adminer.php` bundlé est la version stable 5.4.2 inchangée — vous pouvez le remplacer par n'importe quelle version d'Adminer compatible en respectant la licence d'origine.
## Support
Le support est inclus pendant 12 mois après l'achat (24h ouvrées, FR/EN). Pour toute question :
- Email : support à datafirefly.com
- Espace client : [datafirefly.com/my-account](https://www.datafirefly.com/my-account/)
Pour les bugs ou demandes d'évolution, précisez votre version PrestaShop, votre version PHP, votre hébergeur et la version du module installée.
---
### DataFirefly 2FA Fortress — Guide complet
_Source :_
> Guide complet d'installation, de configuration et d'utilisation de DataFirefly 2FA Fortress pour WordPress et WooCommerce.
DataFirefly 2FA Fortress ajoute une authentification à deux facteurs complète au back-office WordPress et aux comptes clients WooCommerce. Vous décidez, rôle par rôle, si la 2FA est désactivée, optionnelle ou obligatoire, avec une période de grâce avant blocage. Trois méthodes sont disponibles : application d'authentification (TOTP), code par e-mail et codes de secours à usage unique. Ce guide couvre l'installation, les réglages, l'activation côté utilisateur et client, la connexion, l'administration et le dépannage.
## Installation
1. Téléchargez l'archive `df-twofactor.zip` depuis votre compte DataFirefly.
2. Back-office WordPress → **Extensions** → **Ajouter** → **Téléverser une extension** → envoyez le ZIP, puis **Activer**.
3. À l'activation, l'extension crée sa table de journal de sécurité, génère une clé de chiffrement dédiée et ajoute le menu **DataFirefly 2FA**.
Compatible WordPress 6.0 à 7.x et PHP 8.1 à 8.3. Compatible WooCommerce HPOS (stockage haute performance des commandes) et Cart/Checkout Blocks, multisite et multilingue. Aucune dépendance Composer.
## Prise en main en trois minutes
1. Ouvrez **DataFirefly 2FA → Réglages** et choisissez le mode par rôle (au minimum _Obligatoire_ pour les administrateurs).
2. Définissez une période de grâce (par défaut 7 jours) pour laisser à chacun le temps de configurer sa 2FA.
3. Rendez-vous sur **votre profil** et activez l'application TOTP : scannez le QR code, saisissez le code à 6 chiffres, puis téléchargez vos codes de secours.
4. Déconnectez-vous puis reconnectez-vous : un code vous est désormais demandé après le mot de passe.
Activez toujours au moins une méthode de secours (codes de secours ou e-mail) avant de rendre la 2FA obligatoire : c'est ce qui évite de se retrouver bloqué en cas de perte du téléphone.
## Réglages généraux (back-office)
Tous les réglages se trouvent dans **DataFirefly 2FA → Réglages**.
### Application par rôle
Pour chaque rôle (administrateur, éditeur, boutiquier, client…), choisissez l'un des trois modes :
- **Désactivée** : la 2FA n'est ni proposée ni exigée pour ce rôle.
- **Optionnelle** : les utilisateurs peuvent l'activer s'ils le souhaitent.
- **Obligatoire** : l'utilisateur doit la configurer ; au-delà de la période de grâce, l'accès est bloqué tant qu'elle n'est pas active.
Lorsqu'un utilisateur possède plusieurs rôles, c'est le niveau le plus exigeant qui s'applique.
### Période de grâce
La période de grâce (en jours) s'applique aux utilisateurs soumis à une 2FA obligatoire qui ne l'ont pas encore configurée. Pendant ce délai, un rappel indique le nombre de jours restants. À 0 jour, la configuration est exigée dès la première connexion.
### Méthodes autorisées
Activez les méthodes proposées à vos utilisateurs : application TOTP, code par e-mail et codes de secours. TOTP est recommandé comme méthode principale ; les codes de secours servent de filet de sécurité. Le champ **Nom affiché (issuer)** détermine l'étiquette montrée dans l'application d'authentification (par défaut, le nom du site).
### Appareils de confiance
Le réglage **Mémoriser le navigateur** (en jours) permet à un utilisateur de ne plus être challengé sur un appareil validé pendant la durée choisie. La valeur 0 désactive complètement cette fonction.
### Protection anti-bruteforce
Définissez le nombre de tentatives autorisées avant verrouillage temporaire et la durée de ce verrouillage. La **tolérance TOTP** compense les horloges légèrement décalées : 1 accepte le code précédent et le suivant. L'augmenter réduit la sécurité.
### Code par e-mail
Réglez la durée de validité du code reçu par e-mail et le délai minimal entre deux envois (anti-spam). Le code est à usage unique et expire automatiquement.
### Clients et notifications
- **Opt-in client** : autorise les clients à activer la 2FA depuis « Mon compte » dans WooCommerce.
- **Nouvel appareil** : envoie un e-mail informatif lors d'une connexion validée depuis un appareil jamais vu.
## Activer sa 2FA (administrateurs et équipe)
Chaque utilisateur configure sa 2FA depuis son **profil** (menu _Comptes_ → _Profil_), dans la section « Authentification à deux facteurs ».
### Application d'authentification (TOTP)
1. Cliquez sur **Configurer** sous « Application d'authentification ».
2. Scannez le QR code affiché avec Google Authenticator, Authy, Microsoft Authenticator, 1Password, etc. Si le QR ne peut pas être scanné, saisissez manuellement la clé affichée sous le QR.
3. Saisissez le code à 6 chiffres généré par l'application, puis cliquez sur **Confirmer & activer**.
Le secret TOTP est chiffré côté serveur (AES-256-GCM) avant d'être stocké. Il n'est jamais affiché en clair une fois la configuration terminée.
### Code par e-mail
Cliquez sur **Activer** sous « Code par e-mail » : un code de vérification est envoyé à votre adresse. Saisissez-le pour confirmer. Si le code a expiré, utilisez **Renvoyer un nouveau code**.
### Codes de secours
Dès l'activation d'une méthode, dix codes de secours à usage unique sont générés et affichés une seule fois. Utilisez les boutons **Télécharger (.txt)** ou **Copier** pour les conserver en lieu sûr. Chaque code ne fonctionne qu'une fois ; vous pouvez les régénérer à tout moment (les anciens sont alors invalidés).
## Activer la 2FA côté client (WooCommerce)
Lorsque l'opt-in client est activé, vos clients disposent d'un onglet **Sécurité (2FA)** dans « Mon compte ». Ils y activent l'application TOTP ou le code par e-mail, exactement comme dans le back-office, et conservent leurs propres codes de secours. Vous pouvez aussi rendre la 2FA obligatoire pour le rôle _client_.
## Se connecter avec la double authentification
Une fois la 2FA active, la connexion se déroule en deux étapes : identifiant et mot de passe habituels, puis un écran de vérification qui demande le code de la méthode principale.
### Changer de méthode ou renvoyer un code
Sur l'écran de vérification, des liens permettent de basculer vers une autre méthode activée (par exemple passer du TOTP au code e-mail) ou d'utiliser un code de secours. Pour la méthode e-mail, un lien permet de renvoyer un code si nécessaire.
### Se souvenir de l'appareil
Si les appareils de confiance sont activés, une case « Se souvenir de cet appareil » évite de redemander un code sur ce navigateur pendant la durée configurée. À éviter sur un poste partagé.
### Configuration forcée (2FA obligatoire)
Si la 2FA est obligatoire pour le rôle et que la période de grâce est dépassée, l'utilisateur doit la configurer directement sur l'écran de connexion : il saisit son mot de passe, puis active l'application TOTP avant d'accéder au site. Ses codes de secours lui sont présentés juste après.
Avant de passer un rôle en « Obligatoire » avec une période de grâce courte, prévenez les utilisateurs concernés et assurez-vous qu'une méthode de récupération est disponible. En cas de blocage, un administrateur peut toujours réinitialiser la 2FA d'un compte.
## Codes de secours : usage, téléchargement, régénération
Les codes de secours permettent de se connecter quand l'appareil principal n'est pas disponible. Sur l'écran de vérification, choisissez « Utiliser un code de secours » et saisissez l'un de vos codes inutilisés. Depuis le profil, la carte « Codes de secours » indique le nombre de codes restants et permet de les régénérer. À leur génération, les codes peuvent être téléchargés dans un fichier `.txt` (en-tête avec le site, le compte et la date) ou copiés dans le presse-papiers.
## Gérer la 2FA des utilisateurs (administrateur)
### Colonne 2FA et réinitialisation
La liste des **Comptes** affiche une colonne **2FA** indiquant pour chaque utilisateur l'état de sa double authentification (Activée, En attente, Bloquée ou Inactive). Le lien **Gérer** ouvre le panneau 2FA de l'utilisateur, où un administrateur peut réinitialiser sa configuration (par exemple en cas de perte d'appareil).
### Journal de sécurité
Le menu **DataFirefly 2FA → Journal de sécurité** conserve les 200 derniers événements : connexions réussies et échouées, activations et désactivations, utilisation d'un code de secours, verrouillages anti-bruteforce et réinitialisations administrateur. Les entrées de plus de 180 jours sont purgées automatiquement.
## Sécurité et stockage des données
- Les secrets TOTP sont chiffrés en AES-256-GCM à l'aide d'une clé dédiée générée à l'activation, indépendante des clés de salage WordPress.
- Les codes de secours sont hachés (jamais stockés en clair) et invalidés après usage.
- La protection anti-bruteforce verrouille temporairement un compte après trop d'échecs.
- Les appareils de confiance reposent sur un jeton aléatoire, stocké haché côté serveur.
## Compatibilité et notes techniques
- WordPress 6.0 à 7.x, PHP 8.1 à 8.3, multisite.
- WooCommerce : compatibilité HPOS et Cart/Checkout Blocks déclarée.
- Multilingue : un modèle de traduction `.pot` est fourni (compatible Polylang, WPML, Loco Translate).
- Architecture extensible par fournisseurs de méthodes (voir la section développeurs), prête pour l'ajout ultérieur de WebAuthn / passkeys.
## Pour les développeurs (hooks et filtres)
- `df2fa_providers` (filtre) : ajoute ou retire des méthodes de vérification.
- `df2fa_ip_headers` (filtre) : personnalise les en-têtes utilisés pour déterminer l'adresse IP du client.
- `df2fa_email_code_message` (filtre) : personnalise le message de l'e-mail contenant le code.
- `df2fa_event_logged` (action) : déclenchée à chaque enregistrement dans le journal de sécurité.
- `df2fa_login_success` (action) : déclenchée après une connexion validée par 2FA.
## Désinstallation
La suppression de l'extension depuis l'écran des extensions exécute un nettoyage complet : la table du journal de sécurité est supprimée, les options et toutes les métadonnées 2FA des utilisateurs sont effacées, et les tâches planifiées sont retirées. La simple désactivation, elle, conserve les données.
## FAQ et dépannage
**Le QR code ne s'affiche pas.** Forcez le rechargement de la page (cache du navigateur). Vous pouvez aussi configurer l'application manuellement en saisissant la clé affichée sous le QR. Vérifiez qu'aucune extension de minification/blocage JavaScript n'empêche le chargement des scripts.
**Un utilisateur a perdu son téléphone.** Il peut utiliser un code de secours, ou la méthode e-mail si elle est activée. À défaut, un administrateur réinitialise sa 2FA depuis la liste des comptes.
**Le code reçu par e-mail est refusé.** Vérifiez qu'il n'a pas expiré et utilisez « Renvoyer un nouveau code ». Contrôlez aussi la configuration d'envoi des e-mails du site (SMTP).
**Je suis bloqué après avoir rendu la 2FA obligatoire.** Connectez-vous avec un autre compte administrateur pour réinitialiser le compte concerné, ou ajustez le mode du rôle dans les réglages.
**Les passkeys / WebAuthn sont-ils gérés ?** Pas dans la version 1.0.0. L'architecture par fournisseurs permettra de les ajouter ultérieurement sans refonte.
---
### DataFirefly Address Lookup — Documentation
_Source :_
> Présentation DataFirefly Address Lookup ajoute l'autocomplétion d'adresse aux formulaires de PrestaShop 8 et 9 : tunnel de commande, page « Mon adresse », page « Mes informations » et formulaire…
## Présentation
DataFirefly Address Lookup ajoute l'autocomplétion d'adresse aux formulaires de PrestaShop 8 et 9 : tunnel de commande, page « Mon adresse », page « Mes informations » et formulaire d'inscription. Le module s'appuie sur deux moteurs : l'API française BAN (data.geopf.fr/geocodage), gratuite et sans clé, activée par défaut pour la France, et Google Places en option pour les adresses internationales.
Le workflow côté client est simple : il saisit son code postal, la ville se remplit automatiquement (ou un sélecteur de communes s'affiche si plusieurs correspondent) ; il commence à taper sa rue, les suggestions apparaissent ; un clic remplit d'un coup la rue, le code postal et la ville avec une adresse normalisée.
**Aucune donnée ne transite par votre serveur ni par DataFirefly.** Les requêtes partent directement du navigateur du client vers l'API BAN ou Google Places. Le module ne crée aucune table SQL et ne surcharge aucun template Smarty.
## Prérequis
- PrestaShop 8.0 à 9.x (thème Classic, Hummingbird ou la plupart des thèmes tiers)
- PHP 7.4 ou supérieur
- Pour Google Places uniquement : une clé d'API Google Cloud avec les APIs _Places API (New)_ et _Maps JavaScript API_ activées
## Installation
1. Dans le back-office PrestaShop, ouvrez **Modules → Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez le fichier `dfaddresslookup.zip`.
3. PrestaShop installe le module et enregistre automatiquement les hooks `actionFrontControllerSetMedia` et `displayHeader`.
4. Cliquez sur **Configurer** pour ouvrir l'écran de réglages.
Dès l'installation, l'autocomplétion est active pour la France sans aucune configuration : l'API BAN est activée par défaut et ne nécessite pas de clé.
## Configuration
### API française BAN
**Activer l'API BAN française** — active ou désactive le moteur français. Activé par défaut. L'API data.geopf.fr/geocodage est un service public gratuit : pas de clé, pas d'abonnement, limite indicative de 50 requêtes par seconde et par IP, très au-delà des besoins d'un checkout.
**Pré-remplir la ville depuis le code postal** — quand le client saisit un code postal français à 5 chiffres, la ville se remplit automatiquement si une seule commune correspond ; sinon un sélecteur de communes s'affiche sous le champ. Le module ne remplace jamais une ville déjà saisie par le client.
### Google Places (optionnel)
**Activer Google Places** — active le moteur international. Nécessite une clé d'API valide, sans quoi l'enregistrement de la configuration est refusé.
**Clé d'API Google** — votre clé Google Cloud. Voir la section suivante pour la créer et la sécuriser.
**Pays autorisés** — liste de codes ISO 3166-1 alpha-2 séparés par des virgules (ex. `BE,CH,LU,DE`). Google Places ne se déclenche que pour ces pays ; champ vide = tous les pays. C'est le levier principal pour maîtriser votre facturation Google Cloud.
### Comportement
**Caractères minimum** — nombre de caractères avant le déclenchement des suggestions (2 à 10, défaut 3).
**Debounce (ms)** — délai entre la dernière frappe et l'appel API (80 à 2000 ms, défaut 250). Augmentez-le pour réduire le nombre de requêtes, diminuez-le pour des suggestions plus réactives.
**Surligner les correspondances** — met en gras le texte tapé par le client dans chaque suggestion.
## Obtenir une clé Google Places
1. Ouvrez la [Google Cloud Console](https://console.cloud.google.com/) et sélectionnez ou créez un projet.
2. Dans **APIs & Services → Bibliothèque**, activez **Places API (New)** et **Maps JavaScript API**.
3. Dans **APIs & Services → Identifiants**, créez une **clé d'API**.
4. Restreignez la clé : _Restrictions relatives aux applications_ → « Référents HTTP » → ajoutez votre domaine (ex. `*.maboutique.fr/*`) ; _Restrictions relatives aux API_ → limitez à Places API (New) et Maps JavaScript API.
5. Collez la clé dans la configuration du module et enregistrez.
Ne déployez jamais une clé Google sans restriction de référent HTTP : elle serait utilisable par n'importe quel site tiers et pourrait générer une facturation à votre charge.
## Fonctionnement technique
### Bascule automatique entre moteurs
Le module lit le pays sélectionné dans le champ `id_country` du formulaire. France → moteur BAN. Autre pays présent dans la liste des pays autorisés → Google Places. Pays hors liste ou aucun moteur applicable → l'autocomplétion se désactive silencieusement et le formulaire reste un formulaire de saisie classique. La bascule est immédiate à chaque changement de pays, sans rechargement de page.
### Compatibilité checkout one-page et re-rendus
Le checkout de PrestaShop ré-affiche le formulaire d'adresse à chaque changement d'étape. Le module surveille le DOM avec un `MutationObserver` et s'abonne aux événements natifs `updatedAddressForm`, `updatedAddress`, `updatedDeliveryForm` et `changedCheckoutStep` : l'autocomplétion se ré-attache automatiquement à chaque re-rendu. Chaque formulaire est marqué après liaison pour éviter tout double-attachement.
### Formulaires multiples
Si plusieurs formulaires d'adresse sont affichés simultanément (livraison + facturation), chacun reçoit son propre autocomplete indépendant, avec son propre dropdown et son propre état.
### Navigation clavier et accessibilité
Le dropdown de suggestions se pilote entièrement au clavier : flèches haut/bas pour naviguer, Entrée pour sélectionner, Échap pour fermer. Les suggestions portent les attributs ARIA `role="listbox"` et `role="option"`.
### Dégradation gracieuse
Si l'API est injoignable (panne, client hors ligne, blocage réseau), aucune erreur n'est affichée : le formulaire reste un formulaire de saisie manuelle classique. L'autocomplétion est une amélioration progressive, jamais un point de blocage du checkout.
## RGPD et confidentialité
- Les requêtes d'autocomplétion partent directement du navigateur du client vers l'API BAN (service public français) ou Google Places.
- Aucune donnée ne transite par votre serveur PrestaShop pendant la saisie.
- Aucune donnée ne transite par les serveurs DataFirefly, jamais.
- Le module ne dépose aucun cookie.
- Si vous activez Google Places, mentionnez Google dans votre politique de confidentialité comme destinataire des saisies d'adresse pour les pays concernés.
## Dépannage
### Les suggestions n'apparaissent pas
- Vérifiez que le moteur concerné est activé dans la configuration du module.
- Vérifiez le nombre de caractères minimum : les suggestions ne se déclenchent qu'à partir du seuil configuré.
- Videz le cache PrestaShop (**Paramètres avancés → Performances**) pour forcer le rechargement des assets JS/CSS.
- Ouvrez la console navigateur : une erreur CORS ou un blocage par une extension (adblock, protection vie privée) peut empêcher les appels à l'API.
### Google Places ne se déclenche pas
- Vérifiez que le pays sélectionné figure dans la liste des pays autorisés (ou que la liste est vide).
- Vérifiez dans la console navigateur que le script Google Maps se charge sans erreur : une clé invalide, une API non activée ou une restriction de référent trop stricte produisent une erreur explicite `Google Maps JavaScript API error`.
- Vérifiez que la facturation est activée sur votre projet Google Cloud : les APIs Places refusent les requêtes sans compte de facturation actif.
### La ville ne se remplit pas depuis le code postal
- Cette fonction ne concerne que le moteur BAN (France) et se désactive si le champ ville contient déjà une valeur saisie par le client.
- Certains codes postaux couvrent plusieurs communes : le module affiche alors un sélecteur au lieu de remplir automatiquement.
### Conflit avec un module de checkout tiers
Le module cible les champs par leurs attributs `name` standards (`address1`, `postcode`, `city`, `id_country`). Les checkouts one-page tiers qui conservent ces noms de champs fonctionnent sans configuration. Si un module tiers renomme les champs, l'autocomplétion se désactive silencieusement sans casser le checkout — contactez le support avec le nom du module concerné.
## FAQ
### Le module ralentit-il ma boutique ?
Non. Le JS et le CSS ne sont chargés que sur les 4 pages contenant un formulaire d'adresse, et toutes les requêtes d'autocomplétion sont exécutées par le navigateur du client, jamais par votre serveur.
### Puis-je utiliser uniquement l'API française sans Google ?
Oui, c'est le mode par défaut. Google Places est strictement optionnel et ne se charge pas tant qu'il n'est pas activé avec une clé valide.
### Le module fonctionne-t-il en multi-boutique ?
Oui. La configuration est gérée par la table de configuration native de PrestaShop et respecte le contexte multi-boutique standard.
### Que se passe-t-il à la désinstallation ?
Toutes les clés de configuration sont supprimées. Aucune table n'ayant été créée, la désinstallation ne laisse aucune trace.
## Changelog
### 1.1.0 — 23 août 2026
- Migration du moteur Google vers Places API (New) : API programmatique AutocompleteSuggestion avec session tokens et Place.fetchFields ; le widget legacy n'est plus disponible pour les nouveaux clients Google Cloud depuis mars 2025
- Les suggestions Google s'affichent dans le menu du module : UX unifiée, navigation clavier, surlignage, restriction au pays sélectionné
- La France peut être servie entièrement par Google Places en désactivant le moteur BAN
### 1.0.3 — 23 août 2026
- Correction : sur certains thèmes, un script tiers restaurait le texte saisi dans le champ rue après la sélection d'une suggestion, laissant l'adresse non remplie ; la rue est désormais écrite en dernier et sa valeur ré-assertée si elle est écrasée
- Protection anti-réouverture du menu de suggestions basée sur une fenêtre temporelle
### 1.0.2 — 23 août 2026
- Correction : le menu de suggestions restait ouvert après la sélection d'une adresse, la recherche étant relancée par les événements synthétiques émis lors du remplissage des champs
### 1.0.1 — 1 juillet 2026
- Migration du moteur français vers le service de géocodage Géoplateforme (data.geopf.fr/geocodage, IGN), l'ancien endpoint api-adresse.data.gouv.fr ayant été décommissionné fin janvier 2026
- API iso-fonctionnelle : mêmes paramètres, même réponse GeoJSON, même limite de 50 requêtes par seconde et par IP
- Libellés du back-office et attribution des suggestions mis à jour
### 1.0.0 — 15 mai 2026
- Première version publique
- API française BAN intégrée par défaut (gratuite, sans clé)
- Google Places en option avec clé d'API et liste de pays autorisés
- Pré-remplissage code postal → ville → rue
- Compatible PrestaShop 8.0 à 9.x, checkout one-page et multi-étapes
- Navigation clavier, surlignage des correspondances, debounce configurable
- Aucune surcharge de template, aucune table SQL
---
### DataFirefly All in One SEO — Documentation complète
_Source :_
> Documentation complète du module DataFirefly All in One SEO pour PrestaShop 8 et 9 : installation, templates de méta, schémas JSON-LD, sitemap XML, redirections, monitoring 404, robots.txt, tracking GA4/GTM, analyseur de contenu.
Suite SEO premium tout-en-un pour PrestaShop 8 et 9 : templates de méta dynamiques, schémas JSON-LD complets, sitemap XML multilingue, redirections, monitoring 404, Open Graph et Twitter Cards, GA4 et GTM, robots.txt intelligent avec blocage des crawlers IA et analyseur de contenu — tout dans un seul module.
## Prérequis
- **PrestaShop** : 8.0 à 9.x
- **PHP** : 8.1 ou supérieur (8.2 et 8.3 recommandés)
- **MySQL** : 5.7+ ou MariaDB 10.3+
- **Module productcomments** (officiel PrestaShop) : optionnel, requis uniquement pour AggregateRating sur les produits
- **mod_rewrite** activé sur le serveur Apache (ou équivalent Nginx) pour les URL réécrites
Le module est conscient du contexte multi-boutique nativement : toutes les tables sont scopées par `id_shop`. Vous pouvez avoir des configurations totalement différentes par boutique.
## Installation
1. Téléchargez le fichier `dfallinoneseo-vX.Y.Z.zip` depuis votre compte client DataFirefly.
2. Connectez-vous à votre back-office PrestaShop.
3. Allez dans **Modules → Module Manager**.
4. Cliquez sur **Installer un module** en haut à droite.
5. Glissez-déposez le fichier ZIP ou cliquez sur **Sélectionner un fichier**.
6. L'installation crée automatiquement les 11 tables SQL, enregistre les hooks et ajoute le menu **Améliorer → DataFirefly SEO**.
Après installation, ouvrez le **Dashboard** du module pour un aperçu du score SEO global et des points à corriger en priorité.
## Premier paramétrage en 10 minutes
Ce parcours rapide vous permet de configurer l'essentiel avant la première crawl Google.
1. **Réglages → Général** : activez le module, renseignez le nom du site et le libellé "Accueil" pour le fil d'Ariane.
2. **Méta & templates** : définissez au minimum un template _Produit_ et un template _Catégorie_ (voir section dédiée).
3. **Schema → Identité de l'organisation** : renseignez logo, téléphone, email, adresse et URLs des réseaux sociaux (`sameAs`).
4. **Sitemap** : activez le sitemap et cliquez sur **Régénérer maintenant**.
5. **Tracking** : ajoutez votre GA4 Measurement ID et/ou GTM ID.
6. **Tracking → Vérifications** : collez la valeur de vérification Google Search Console.
7. **Robots.txt** : cliquez sur **Charger les défauts (PS + blocage AI)** pour partir d'une base saine.
## Templates de méta
Le module remplace la saisie manuelle de `meta_title` et `meta_description` par des templates dynamiques par type d'entité. À l'enregistrement d'une fiche dont les méta sont vides, le template correspondant est appliqué automatiquement.
### Types d'entités supportés
- **Produit** : fiches produit (tous types confondus, y compris virtuels et pack)
- **Catégorie** : pages catégorie
- **Page CMS** : pages de contenu statique
- **Marque / Fabricant** : pages fabricant
- **Fournisseur** : pages fournisseur
- **Accueil** : page d'accueil de la boutique
- **Pages génériques** : `/contact`, `/sitemap`, etc.
### Tokens disponibles
Les tokens sont remplacés par les valeurs réelles au rendu de la page. Tous les tokens ne sont pas disponibles sur tous les types d'entité.
- `{shop_name}` — nom de la boutique
- `{sep}` — séparateur (par défaut `|`)
- `{product_name}` — nom du produit (langue courante)
- `{product_reference}` — référence interne
- `{product_sku}` — alias de référence
- `{product_ean13}` — code-barres EAN13
- `{product_brand}`, `{brand}` — marque/fabricant
- `{category}` — catégorie par défaut (produit) ou nom de la catégorie (page catégorie)
- `{category_parent}` — nom de la catégorie parente
- `{category_description}` — description courte (160 car. max)
- `{short_description}` — description courte du produit (160 car. max)
- `{price}` — prix TTC formaté avec devise
- `{price_tax_excl}` — prix HT formaté
- `{title}` — titre de la page CMS
- `{summary}` — extrait du contenu CMS (160 car. max)
### Blocs conditionnels
Pour ne pas afficher un token vide, utilisez la syntaxe conditionnelle :
```
{?product_brand}{product_brand} | {/?}{product_name} - {shop_name}
```
Si `product_brand` est vide (produit sans marque), tout le bloc entre `{?token}` et `{/?}` est supprimé. Sinon, son contenu est rendu et les tokens à l'intérieur sont remplacés normalement.
### Exemples de templates recommandés
**Produit** :
```
Title : {?product_brand}{product_brand} {/?}{product_name} - {category} | {shop_name}
Description : Découvrez {product_name}{?product_brand} signé {product_brand}{/?}. {short_description} Livraison rapide sur {shop_name}.
```
**Catégorie** :
```
Title : {category} - {?category_parent}{category_parent} - {/?}{shop_name}
Description : Tous les produits de la catégorie {category} sur {shop_name}. {category_description}
```
**Accueil** :
```
Title : {shop_name} - Boutique en ligne
Description : Bienvenue sur {shop_name}. Découvrez notre catalogue, livraison rapide, paiement sécurisé.
```
### Surcharge par entité
Pour surcharger une fiche spécifique (par exemple un produit phare), cliquez sur l'icône **Surcharge méta** dans le menu **Édition en masse** ou utilisez l'URL :
```
?controller=AdminDfSeoMeta&entity=product&entity_id=42
```
La page de surcharge permet de définir `meta_title`, `meta_description`, la directive robots (`noindex,follow` par exemple) et un canonical custom par langue.
La directive robots définie sur une entité spécifique a priorité sur les réglages globaux d'indexation. Utilisez-la avec parcimonie pour éviter de désindexer accidentellement vos meilleures pages.
## Schémas JSON-LD
Le module génère un bloc `@graph` unique regroupant tous les schémas de la page courante, validé Google Rich Results Test.
### Schémas générés automatiquement
- **Organization** — sur toutes les pages, identité de la société
- **WebSite** — sur l'accueil, avec `SearchAction` pour activer le sitelinks search box
- **LocalBusiness** — si une adresse physique est renseignée
- **BreadcrumbList** — fil d'Ariane
- **Product** — sur les fiches produit, avec `offers`, `priceValidUntil`, `gtin13`/`isbn`/`mpn`
- **AggregateRating** — agrégée depuis le module productcomments officiel
- **Article** — sur les pages CMS
- **FAQPage** — depuis les blocs FAQ produit ou page
### Identité de l'organisation
Onglet **Schema → Identité de l'organisation**. Champs à renseigner :
- **Type** : Organization, Corporation, LocalBusiness, Store, OnlineStore, OnlineBusiness
- **Logo** : URL absolue (recommandé 600x60 minimum, ratio carré ou paysage)
- **Téléphone**, **Email** : utilisés dans `contactPoint`
- **Adresse postale** : rue, code postal, ville, pays (ISO-2)
- **sameAs** : une URL par ligne (Facebook, Instagram, LinkedIn, Twitter/X, etc.)
### Validité des offres produit
Le champ _Validité des offres produit (jours)_ contrôle la valeur de `priceValidUntil` dans `Product.offers`. Par défaut : 60 jours. Google exige ce champ pour afficher le prix dans les résultats enrichis.
### Schémas personnalisés
Onglet **Schema → Schémas personnalisés**. Permet d'ajouter des blocs JSON-LD sur mesure (HowTo, Recipe, Event, JobPosting, VideoObject, Course, etc.) sur une portée précise :
- **global** : toutes les pages
- **home** : accueil uniquement
- **product** : toutes les pages produit
- **product_id** : un produit spécifique (utilise le champ ID)
- **category**, **category_id** : idem catégorie
- **cms**, **cms_id** : idem page CMS
Variables disponibles dans le JSON personnalisé : `{shop_name}`, `{base_url}`, `{entity_id}`, `{entity_type}`.
Le JSON-LD personnalisé est inséré tel quel dans le `@graph`. Validez-le avec le [Rich Results Test](https://search.google.com/test/rich-results) avant publication. Un JSON invalide est rejeté silencieusement.
## Sitemap XML
Le module génère un sitemap XML conforme à la [spécification sitemaps.org](https://www.sitemaps.org/protocol.html), avec hreflang sur chaque URL et support des images. Architecture : un _sitemap index_ par boutique, puis un sitemap par type d'entité × langue, découpé en chunks.
### Configuration
Onglet **Sitemap**. Activez le sitemap puis cochez le contenu à inclure :
- Produits (par défaut tous les produits actifs)
- Catégories
- Pages CMS
- Marques / Fabricants
- Fournisseurs
- Images (ajoute `image:image` à chaque URL produit)
- Vidéos (si présentes dans les fiches)
Options supplémentaires :
- **Exclure les ruptures** : retire les produits en out-of-stock
- **Gzip** : génère aussi les variantes `.xml.gz` (réduit 5 à 10x la taille téléchargée par les crawlers)
- **URLs par fichier** : taille de chunk (recommandé 5000-10000, max 50000 par spec XML)
### Régénération
La régénération est manuelle depuis l'admin pour éviter toute charge serveur imprévue. Cliquez sur **Régénérer maintenant**.
Pour automatiser, planifiez un cron qui appelle le script suivant (toutes les 6 ou 12 heures selon la fréquence de mise à jour de votre catalogue) :
```
0 */6 * * * php /var/www/html/index.php fc=module&module=dfallinoneseo&controller=sitemap&action=rebuild
```
### Soumission aux moteurs
Cliquez sur **Pinger les moteurs** pour notifier Google et Bing (endpoints legacy mais toujours actifs). Pour Google Search Console, soumettez l'URL du sitemap index une fois pour toutes dans GSC → Sitemaps. GSC re-crawl automatiquement à chaque modification.
URL du sitemap index : `https://votre-boutique.com/sitemap.xml`
## Sitemap HTML public
Un sitemap HTML lisible par les humains est généré automatiquement à `/plan-du-site`. Il agrège catégories (arbre), pages CMS, marques, fournisseurs et les 200 derniers produits. Utile pour le maillage interne et l'accessibilité.
## Redirections
Le module gère les redirections HTTP 301 (permanent), 302 (temporaire), 307, 308 et 410 (Gone) avec trois types de match.
### Types de match
- **Exact** : l'URL source doit correspondre exactement (sans query string)
- **Préfixe** : l'URL source est un préfixe de l'URL demandée. Le suffixe est conservé dans la destination si _Conserver query string_ est coché. Utile pour migrer des dossiers entiers (`/ancien-dossier/` → `/nouveau-dossier/`).
- **Regex** : expression régulière PHP (mode `~...~i` sensible/insensible). Les groupes de capture sont disponibles dans la destination via `$1`, `$2`, etc.
### Création manuelle
Onglet **Redirections → Nouvelle redirection**. Champs :
- **URL source** : chemin sans le domaine (ex: `/ancienne-page`)
- **URL destination** : chemin ou URL absolue. Laisser vide pour un code 410.
- **Type de match**, **Code HTTP**, **Conserver query string**
### Import / export CSV
Format CSV attendu (avec header) :
```
source,destination,type,code
/ancien-produit,/nouveau-produit,exact,301
/ancien-dossier/,/nouveau-dossier/,prefix,301
/old-(.*),/new-$1,regex,301
```
L'export CSV reprend les redirections actuellement filtrées dans la liste.
### Redirection automatique au changement de slug
Si l'option **Réglages → Monitoring → Redirection 301 auto en cas de changement d'URL** est cochée, le module crée une 301 automatiquement quand vous modifiez le slug d'un produit, d'une catégorie, d'une page CMS, d'une marque ou d'un fournisseur. Le `created_by` est alors marqué `auto:urlchange` pour distinction.
Cette option évite la majorité des 404 SEO classiques liés aux refontes de contenu. Activez-la dès l'installation.
## Monitoring 404
Onglet **Monitor 404**. Capture toutes les URLs en erreur 404 servies par PrestaShop, avec déduplication, comptage des hits, détection des bots et hash des adresses IP (sel `COOKIE_KEY` de PrestaShop pour conformité RGPD).
### Filtres disponibles
- **Non résolues** : URLs sans redirection couvrante (vue par défaut)
- **Résolues** : URLs pour lesquelles une redirection a été créée a posteriori
- **Bots** : hits venant de user-agents identifiés comme bots
- **Toutes**
### Créer une redirection en un clic
Sur chaque ligne, le bouton **Rediriger** ouvre un formulaire inline qui pré-remplit la source. Saisissez la destination, choisissez le code HTTP, validez. La 404 est automatiquement marquée comme résolue.
### Purge et maintenance
Le menu **Réglages → Monitoring** expose un seuil _Nombre maximum d'entrées 404 conservées_ (par défaut 5000). Au-delà, le bouton **Purger les vieux 404** supprime les entrées non résolues les plus anciennes.
## Robots.txt dynamique
Le module sert un fichier `/robots.txt` généré dynamiquement à chaque requête, basé sur les règles définies dans **Robots.txt**.
### Préréglages PrestaShop + blocage AI
Le bouton **Charger les défauts (PS + blocage AI)** écrase toutes les règles actuelles et charge un préréglage sain qui :
- Bloque les répertoires sensibles PrestaShop (`/admin*/`, `/cache/`, `/classes/`, etc.)
- Bloque les pages techniques (`/cart`, `/order`, `/my-account`, etc.)
- Bloque les principaux crawlers IA non respectueux : **GPTBot**, **ClaudeBot**, **CCBot**, **Google-Extended**, **anthropic-ai**
- Pointe vers le sitemap (`Sitemap: /sitemap.xml`)
### Règles personnalisées
Chaque règle a un user-agent, une directive (`Allow`, `Disallow`, `Crawl-delay`), une valeur et une position (ordre dans le fichier). Activez/désactivez une règle sans la supprimer via la pastille ON/OFF.
### Aperçu live
Le bloc **Aperçu du fichier généré** en bas de page rend le robots.txt tel qu'il sera servi, avant publication.
## Fichier llms.txt natif
Le module sert un fichier `/llms.txt` conforme à la [spécification llmstxt.org](https://llmstxt.org/). Ce fichier liste, en markdown, les sections principales du site pour les crawlers IA respectueux qui souhaitent une vue structurée plutôt que de scraper l'intégralité du HTML.
Aucune configuration n'est requise — le module génère automatiquement le fichier depuis votre arborescence de catégories, pages CMS et marques.
## Open Graph et Twitter Cards
Onglet **Social**. Le module injecte les balises `og:*` et `twitter:*` sur toutes les pages.
### Réglages
- **Activer Open Graph et Twitter Cards** : master switch
- **og:locale automatique** : calculé depuis la langue du contexte (ex: `fr_FR`)
- **Image OG par défaut** : URL absolue d'une image 1200×630 (utilisée quand la page n'a pas d'image dédiée)
- **og:site_name**, **og:type** par défaut
- **Twitter @handle** et type de carte (`summary` ou `summary_large_image`)
- **fb:app_id** : Facebook App ID
Pour les fiches produit, le module utilise automatiquement l'image principale de la fiche. Pour les autres pages, l'image OG par défaut est utilisée si aucune image n'est définie.
## Tracking : GA4, GTM, pixels
### GA4 et Enhanced Ecommerce
Champ **GA4 Measurement ID** : format `G-XXXXXXXXXX`. Validation automatique du format.
Cochez **Enhanced Ecommerce** pour activer les événements `view_item`, `view_item_list`, `add_to_cart`, `remove_from_cart`, `begin_checkout`, `add_payment_info`, `purchase`.
Cochez **Respecter Consent Mode v2** pour anonymiser les hits jusqu'au consentement explicite (compatible avec les CMP standards).
### Google Tag Manager
Champ **GTM ID** : format `GTM-XXXXXXX`. Le module injecte le snippet GTM dans le `head` et le fallback `noscript` juste après l'ouverture du `body`.
### Pixels publicitaires
- **Facebook Pixel ID** : 15 chiffres
- **TikTok Pixel ID** : alphanumérique
Si Consent Mode v2 est actif, ces pixels ne se déclenchent qu'après consentement.
### Vérifications de propriété
Collez les valeurs des balises de vérification (sans la balise `meta` complète, uniquement le contenu de l'attribut `content`) :
- Google Search Console
- Bing Webmaster Tools
- Yandex Webmaster
- Pinterest
- Baidu
### Code personnalisé head et body-end
Deux champs libres acceptent du HTML/JS arbitraire :
- **Code injecté dans head** : pour scripts tiers, méta complémentaires
- **Code injecté juste avant la fermeture du body** : idéal pour widgets de chat, retargeting tardif, scripts asynchrones
Ces champs n'effectuent aucune validation. Une erreur de syntaxe HTML peut casser le rendu de la page. Testez en pré-production avant publication.
## Analyseur de contenu
Onglet **Analyseur**. Soumettez un produit, une catégorie, une page CMS ou du HTML brut à l'analyseur pour obtenir un score SEO global et un détail des métriques.
### Métriques calculées
- **Score SEO global** (0-100) — pondération weighted des checks
- **Lisibilité Flesch** — approximation multilingue (vowel-group syllable count)
- **Nombre de mots**, **nombre de phrases**
- **Densité du mot-clé principal** (en %)
- **Liens internes / externes / nofollow**
- **Images sans attribut alt**
- **Structure des titres H1 à H6**
- Présence du mot-clé dans **slug** et **premier paragraphe**
### Vérifications (checks)
L'analyseur retourne une liste de checks avec statut `good` / `warn` / `bad` :
- Longueur du title (50-60 caractères)
- Longueur de la meta description (140-160 caractères)
- Présence et longueur du slug
- Longueur du corps (mini 300 mots)
- Présence d'au moins une image avec alt
- Mot-clé dans le title, dans le premier paragraphe, dans le slug
- Densité du mot-clé entre 0,5 % et 2,5 %
- Au moins un H1 et plusieurs H2/H3
L'analyseur est un guide, pas une vérité absolue. Un score de 80+ est excellent. En dessous de 50, revoyez la structure et le wording. Ne sacrifiez jamais la qualité éditoriale pour un score.
## Édition en masse
Onglet **Édition en masse**. Grille paginée (30 entrées/page) avec filtres pour modifier rapidement `meta_title`, `meta_description` et `link_rewrite` sur produits, catégories ou pages CMS.
### Filtres disponibles
- **Toutes**
- **Sans title** : seules les entrées avec meta_title vide
- **Sans description** : seules les entrées avec meta_description vide
- **Recherche par nom**
### Appliquer les templates en masse
Le bouton **Appliquer les templates** applique automatiquement le template défini pour le type d'entité courant aux fiches correspondant aux filtres. Cochez **Appliquer uniquement aux champs vides** pour éviter d'écraser les méta déjà saisies.
## Métabox SEO sur la fiche produit
Sur la page d'édition d'un produit en back-office, un encart **DataFirefly SEO** est ajouté avec :
- Un **score SEO live** (7 checks : longueur title, description, slug, body, image, EAN13, marque)
- Un **aperçu SERP Google** rendu fidèlement
- Le mot-clé principal détecté
## Réglages avancés
### Indexation
Onglet **Réglages → Indexation** :
- **hreflang multilingue** : génère les balises `link rel="alternate"` sur toutes les pages
- **Stratégie x-default** : _Langue par défaut_ (recommandé), _Anglais_, ou _Désactivé_
- **URL canonical** : injecte `link rel="canonical"`
- **Canonical sur les paginations** : _Sur la page courante_ (recommandé), _Toujours sur la page 1_, ou _Pas de canonical_
- **noindex automatiques** : pages /search, panier, mon compte, nouveautés, meilleures ventes, promos, facettes
- **Canonical vers la page mère sur facettes** : évite le duplicate content de la navigation à facettes
### Images
- **Génération automatique des attributs alt** : à l'enregistrement d'une image sans alt, applique le template
- **Template alt** : par défaut `{product_name} - {shop_name}`
- **Lazyload images natif** : ajoute `loading="lazy"` et `decoding="async"` à toutes les images, avec fallback IntersectionObserver pour les images `data-src`
### Maintenance
- **Vider le cache** : purge le cache Smarty + cache PrestaShop
- **Purger les vieux 404** : applique le seuil configuré
- **Exporter toutes les données (JSON)** : télécharge un fichier JSON avec toutes les tables SEO de la boutique courante (utile pour migration entre environnements ou backup avant désinstallation)
## Multi-boutique
Toutes les fonctionnalités sont scopées par `id_shop`. En passant d'une boutique à une autre via le sélecteur de contexte PrestaShop, vous voyez et modifiez uniquement les données de cette boutique.
Cas particuliers à connaître :
- **Templates** : un template par couple (type d'entité, boutique). Définissez explicitement les templates pour chaque boutique.
- **Sitemap** : un sitemap_index distinct par boutique, accessible à `https://boutique-1.com/sitemap.xml`, `https://boutique-2.com/sitemap.xml`, etc.
- **Robots.txt** : règles par boutique, servies sur le domaine correspondant
- **Redirections** : par boutique
- **Schémas personnalisés** : par boutique
## Dépannage
### Le sitemap ne se génère pas
- Vérifiez que le dossier `modules/dfallinoneseo/sitemaps/` est accessible en écriture par PHP
- Vérifiez les permissions : `chmod 755 modules/dfallinoneseo/sitemaps/`
- Augmentez `max_execution_time` dans php.ini si vous avez plus de 50 000 produits
### Les schémas JSON-LD n'apparaissent pas
- Vérifiez que le module est activé (**Réglages → Général**)
- Vérifiez que le type de schéma concerné est activé (**Schema → Types de schémas générés**)
- Videz le cache PrestaShop
- Inspectez la source HTML : les schémas sont injectés dans un bloc `script type="application/ld+json"`
### Les redirections 301 ne fonctionnent pas
- Vérifiez que le module est installé et activé
- Vérifiez que les redirections sont marquées **actives** (pastille ON)
- Pour les regex, testez votre expression sur [regex101.com](https://regex101.com/) en mode PCRE
- L'ordre de priorité est : exact → préfixe → regex (par `hit_count` décroissant)
### GA4 / GTM ne s'injecte pas
- Vérifiez le format de l'ID (`G-XXXXXXX` ou `GTM-XXXXXXX`)
- Si Consent Mode v2 est actif, le snippet est en mode "denied" par défaut jusqu'au consentement. Vérifiez la couche CMP.
- Inspectez le `head` de la page : le snippet GA4/GTM est injecté juste avant la fermeture
### Le robots.txt ne change pas
- Vérifiez qu'aucun fichier `robots.txt` statique n'existe à la racine du site (il prendrait priorité sur le module). Supprimez-le.
- Le module sert le robots.txt via une route PrestaShop — vérifiez que les _URL réécrites_ sont activées
### Erreur lors de la création des tables SQL à l'installation
- Vérifiez que l'utilisateur MySQL a les droits `CREATE` et `ALTER`
- Vérifiez l'encodage : MySQL doit supporter `utf8mb4` avec collation `utf8mb4_unicode_ci`
- Si le préfixe de table custom de PrestaShop dépasse 5 caractères, certains noms d'index peuvent dépasser la limite MySQL de 64 caractères. Contactez le support.
## Référence technique
### Hooks utilisés
Le module enregistre 18 hooks :
- `displayHeader` — injection des balises méta, canonical, hreflang, OG, Twitter, JSON-LD, GA4/GTM, vérifications
- `displayBeforeBodyClosingTag` — injection GTM noscript, FB Pixel noscript, custom body-end code
- `displayBackOfficeHeader` — CSS/JS du back-office
- `displayAdminProductsExtra` — métabox SEO sur la fiche produit
- `actionDispatcherBefore`, `actionDispatcherAfter` — routing des redirections et capture 404
- `actionObjectProductAddAfter`, `actionObjectProductUpdateAfter` — auto-fill méta + auto-301
- `actionObjectCategoryAddAfter`, `actionObjectCategoryUpdateAfter` — idem catégorie
- `actionObjectCmsAddAfter`, `actionObjectCmsUpdateAfter` — idem CMS
- `actionObjectManufacturerUpdateAfter`, `actionObjectSupplierUpdateAfter` — auto-301 sur changement de slug
- `actionAdminControllerSetMedia`, `actionFrontControllerSetMedia` — assets CSS/JS
- `displayProductExtraContent` — réservé pour usages futurs
- `moduleRoutes` — routes `/sitemap.xml`, `/plan-du-site`, `/robots.txt`, `/llms.txt`
### Tables SQL ajoutées
Toutes les tables utilisent le préfixe `df_seo_`, charset `utf8mb4`, collation `utf8mb4_unicode_ci` :
- `df_seo_meta`, `df_seo_meta_lang` — surcharges méta par entité
- `df_seo_template`, `df_seo_template_lang` — templates par type
- `df_seo_redirect` — redirections 301/302/307/308/410
- `df_seo_404` — journal des 404
- `df_seo_score` — snapshots de score (analyseur)
- `df_seo_keyword` — focus keywords
- `df_seo_robots_rule` — règles robots.txt
- `df_seo_schema_custom` — schémas JSON-LD personnalisés
- `df_seo_log` — log diagnostic interne
### Désinstallation
La désinstallation supprime les hooks et les onglets back-office, mais **conserve les tables SQL et les données**. Pour purger complètement :
```
DROP TABLE ps_df_seo_meta, ps_df_seo_meta_lang, ps_df_seo_template, ps_df_seo_template_lang,
ps_df_seo_redirect, ps_df_seo_404, ps_df_seo_score, ps_df_seo_keyword,
ps_df_seo_robots_rule, ps_df_seo_schema_custom, ps_df_seo_log;
DELETE FROM ps_configuration WHERE name LIKE 'DFSEO_%';
```
Avant désinstallation, utilisez **Réglages → Maintenance → Exporter toutes les données (JSON)** pour conserver une archive complète. Le format JSON permet de réimporter les redirections, templates et schémas sur une autre installation.
## Mises à jour et support
- **Mises à jour** : 12 mois inclus dès l'achat. Renouvellement annuel optionnel à 49 €.
- **Support** : 12 mois par email, réponse sous 48h ouvrées.
- **Changelog** et téléchargement des dernières versions sur [votre compte client DataFirefly](https://www.datafirefly.com/product/dfallinoneseo/).
---
### DataFirefly Allergens & Ingredients — Guide complet
_Source :_
> Présentation DataFirefly Allergens & Ingredients met votre boutique PrestaShop 8 ou 9 en conformité avec le règlement (UE) 1169/2011 (INCO) : affichage des 14 allergènes de l'Annexe II, liste d'ingrédients…
## Présentation
DataFirefly Allergens & Ingredients met votre boutique PrestaShop 8 ou 9 en conformité avec le règlement (UE) 1169/2011 (INCO) : affichage des 14 allergènes de l'Annexe II, liste d'ingrédients structurée avec mise en évidence automatique des allergènes (article 21), et information disponible avant l'achat comme l'exige l'article 14 pour la vente à distance.
Le module ajoute également deux différenciateurs : un profil allergènes personnel pour chaque client avec alerte en temps réel sur les fiches produits, et un enrichissement Schema.org JSON-LD automatique pour le référencement.
## Prérequis et compatibilité
- PrestaShop 8.0.0 à 9.99.99
- PHP 8.0 minimum
- MySQL 5.7+ ou MariaDB 10.3+
- Compatible multi-boutique et multi-langue
- Langues fournies : français, anglais, espagnol, allemand
## Installation
1. Dans le back-office, ouvrez **Modules → Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et sélectionnez le fichier `dfallergens-1.0.0.zip`.
3. Cliquez sur **Installer**. Le module crée 5 tables préfixées `df_` et précharge les 14 allergènes de l'Annexe II dans les 4 langues.
4. Un nouvel onglet **DataFirefly Allergens** apparaît dans le menu Modules pour gérer la taxonomie des allergènes.
À l'installation, les 14 allergènes officiels sont préchargés avec leurs icônes SVG et leurs noms en français, anglais, espagnol et allemand. Vous n'avez rien à saisir manuellement.
## Configuration
Ouvrez **Modules → Gestionnaire de modules → DataFirefly Allergens & Ingredients → Configurer**. Six réglages sont disponibles :
- **Style de mise en évidence** — la façon dont les allergènes sont marqués dans la liste d'ingrédients : gras (recommandé), majuscules, souligné ou couleur. Le gras est le style le plus courant sur les étiquettes physiques.
- **Afficher les icônes** — active ou désactive les pictogrammes SVG à côté du nom de chaque allergène.
- **Afficher les traces** — affiche ou masque la section « Peut contenir des traces » (article 36 §3).
- **Balisage JSON-LD** — injecte le balisage Schema.org dans la balise head des fiches produits concernées.
- **Profil client** — active la fonctionnalité de profil allergènes dans l'espace client et les alertes sur fiche produit.
- **Position de l'affichage** — onglet dédié sur la fiche produit, après la description, ou après le prix.
## Déclarer les allergènes d'un produit
1. Ouvrez la fiche du produit dans le back-office et rendez-vous dans l'onglet **Modules** (PrestaShop 8) ou la section du module (PrestaShop 9).
2. Dans le panneau **DataFirefly Allergens**, chaque allergène propose trois états : _non applicable_ (par défaut), _Contient_, ou _Traces_.
3. Sélectionnez **Contient** pour les allergènes présents dans la recette, **Traces** pour les contaminations croisées possibles.
4. Renseignez la **liste d'ingrédients** en langage naturel, dans l'ordre décroissant de quantité comme l'exige la réglementation. Le module détecte et met en évidence automatiquement les allergènes et leurs synonymes.
5. Facultativement, renseignez l'**origine** et les **conseils de conservation**.
6. Enregistrez le produit.
Les champs ingrédients, origine et conservation sont enregistrés par langue et par boutique : passez d'une langue à l'autre avec le sélecteur de langue de la fiche produit pour saisir chaque version.
## Détection automatique par synonymes
La mise en évidence ne se limite pas au nom officiel de l'allergène. Le dictionnaire interne reconnaît les variantes courantes dans les quatre langues :
- **Lait** → lait, beurre, crème, caséine, lactosérum, lactose
- **Gluten** → blé, épeautre, orge, seigle, avoine, kamut, malt
- **Sulfites** → SO2, anhydride sulfureux, E220 à E228
- **Fruits à coque** → amande, noisette, noix, cajou, pécan, pistache, macadamia
La détection utilise des limites de mots compatibles Unicode : « blé » est détecté dans « farine de blé » mais pas dans « établi ».
## Profil allergènes client
Lorsque l'option est activée, chaque client connecté dispose d'une section **Mes allergènes** dans son espace client. Il y sélectionne ses allergènes et un niveau de gravité : à éviter, intolérance, sévère ou anaphylactique.
Sur chaque fiche produit, le module compare les allergènes déclarés du produit au profil du client. En cas de conflit, un bandeau d'alerte rouge s'affiche au-dessus du prix, indiquant l'allergène concerné et le niveau de gravité enregistré.
Le profil client est un service d'aide à la décision. Il ne remplace ni l'étiquetage réglementaire ni la vigilance du consommateur : affichez toujours la liste complète des allergènes sur chaque fiche.
## Balisage Schema.org JSON-LD
Quand un produit possède au moins un allergène déclaré ou une liste d'ingrédients, le module injecte automatiquement un script JSON-LD dans la balise head contenant :
- `ingredients` — la liste d'ingrédients en texte plein
- `suitableForDiet` — les régimes compatibles inférés (par exemple GlutenFreeDiet si aucun allergène gluten n'est déclaré)
- `additionalProperty` — chaque allergène avec le propertyID INCO-1169-2011 et son niveau (contient ou traces)
Le balisage est généré côté serveur en PHP, sans template, avec protection contre les injections.
## Gérer la taxonomie des allergènes
Le menu **DataFirefly Allergens** du back-office permet de modifier les noms et descriptions des 14 allergènes dans chaque langue, de les activer ou désactiver individuellement, et d'ajuster leur ordre d'affichage. L'ordre par défaut suit la numérotation de l'Annexe II.
## Dépannage
- **Le bloc allergènes ne s'affiche pas** — vérifiez que le produit a au moins un allergène déclaré ou une liste d'ingrédients, et que la position d'affichage configurée correspond à un hook supporté par votre thème.
- **Tous les allergènes apparaissent en « Contient »** — assurez-vous d'utiliser la version 1.0.0 finale du module ; nettoyez les données du produit de test en repassant tous les sélecteurs sur « non applicable » puis en enregistrant.
- **La mise en évidence ne fonctionne pas sur un terme** — le terme est peut-être absent du dictionnaire de synonymes ; utilisez le nom officiel de l'allergène dans la liste d'ingrédients.
- **Le JSON-LD n'apparaît pas** — vérifiez que l'option est activée dans la configuration et inspectez le code source de la fiche produit (recherchez INCO-1169-2011).
## Désinstallation
La désinstallation supprime les 5 tables du module et toutes les données allergènes, ingrédients et profils clients associés. Exportez vos données avant si nécessaire.
## Responsabilité légale
Le module fournit les outils techniques d'affichage. Conformément à l'article 8 du règlement INCO, la responsabilité de l'exactitude des informations sur les denrées alimentaires incombe à l'exploitant du secteur alimentaire, c'est-à-dire au commerçant.
---
### DataFirefly Auction — Guide complet
_Source :_
> Présentation Le module DataFirefly Auction transforme n'importe quel produit de votre catalogue en véritable vente aux enchères en ligne. Il embarque un moteur d'enchères automatiques façon eBay (proxy bidding), un…
## Présentation
Le module **DataFirefly Auction** transforme n'importe quel produit de votre catalogue en véritable vente aux enchères en ligne. Il embarque un moteur d'enchères automatiques façon eBay (proxy bidding), un système anti-sniping, un prix de réserve masqué, une option d'achat immédiat, une liste de surveillance, et une clôture automatique par cron qui désigne le gagnant et lui génère un bon de réduction pour commander au prix remporté.
Le module est compatible PrestaShop 8.0 à 9.x, multiboutique, traduit en cinq langues (français, anglais, espagnol, allemand, italien), sans Composer ni dépendance externe.
## Installation
1. Dans votre back-office, ouvrez **Modules** puis **Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez le fichier `dfauction.zip`.
3. Une fois installé, cliquez sur **Configurer** pour régler les paramètres généraux.
À l'installation, le module crée ses tables, ses hooks et un menu **Vendre > Enchères** dans le back-office. Il génère aussi un jeton de sécurité unique pour l'URL du cron.
## Réglages du module
La page de configuration regroupe les paramètres globaux, appliqués par défaut à toutes les enchères :
- **Incrément par défaut** : pas minimal entre deux enchères (surenchère minimale).
- **Fenêtre anti-sniping** : durée, en minutes, avant la clôture pendant laquelle toute nouvelle offre déclenche une prolongation.
- **Prolongation anti-sniping** : durée, en minutes, ajoutée à la clôture lorsqu'une offre tombe dans la fenêtre.
- **Anonymisation RGPD** : affiche les enchérisseurs sous un pseudonyme stable (« Bidder #1234 ») dans l'historique public.
- **Liste de surveillance** : active le bouton « Suivre » permettant de suivre une enchère sans enchérir.
- **Notifications e-mail** : active les e-mails de surenchère et de victoire.
- **Validité du bon gagnant** : durée, en heures, de validité du bon de réduction émis au gagnant.
- **Jeton cron** : jeton de sécurité inclus dans l'URL du cron (voir plus bas).
## Créer une enchère
Rendez-vous dans **Vendre > Enchères** puis cliquez sur **Ajouter une enchère**. Les champs disponibles sont :
- **Produit** : le produit mis aux enchères (sélection dans le catalogue).
- **Prix de départ** : montant de la première enchère possible.
- **Prix de réserve** (facultatif) : prix plancher masqué. Tant qu'il n'est pas atteint, le lot n'est pas vendu.
- **Prix d'achat immédiat** (facultatif) : montant permettant d'emporter le lot sur-le-champ.
- **Incrément** : pas de surenchère propre à cette enchère (remplace l'incrément global).
- **Date de début** et **Date de fin** : période d'ouverture de l'enchère.
- **Fenêtre / prolongation anti-sniping** : valeurs spécifiques à l'enchère (sinon les valeurs globales s'appliquent).
- **Achat immédiat autorisé** : active ou non l'option Buy-Now pour cette enchère.
- **Statut** : En attente, Active, Terminée, Vendue ou Annulée.
Laissez le statut sur **En attente** et renseignez une date de début future : le cron passera automatiquement l'enchère en **Active** à l'heure prévue. Inutile de l'activer à la main.
## Comment fonctionnent les enchères automatiques (proxy bidding)
Le cœur du module est un moteur d'enchères automatiques inspiré d'eBay. L'enchérisseur ne saisit pas une offre fixe, mais le **montant maximum** qu'il est prêt à payer. Ce plafond reste confidentiel.
1. Le module n'affiche que l'enchère minimale nécessaire pour que l'enchérisseur reste en tête.
2. Lorsqu'un concurrent enchérit, le module surenchérit automatiquement pour le compte du leader, par paliers d'incrément, jusqu'à atteindre son plafond.
3. Si le nouvel arrivant dépasse le plafond du leader, il prend la tête, et le prix affiché monte juste au-dessus de l'ancien plafond.
Résultat : l'enchérisseur n'a pas besoin de surveiller la vente en continu. Il fixe son maximum une fois, et le module défend sa position pour lui.
## Anti-sniping et prix de réserve
Le **sniping** consiste à enchérir à la toute dernière seconde pour ne laisser à personne le temps de réagir. Pour le neutraliser, toute offre déposée dans la fenêtre anti-sniping prolonge automatiquement la clôture de la durée configurée. La vente ne se termine donc que lorsque plus aucune offre n'arrive dans la dernière fenêtre.
Le **prix de réserve** est un plancher masqué. S'il n'est pas atteint à la clôture, le lot n'est pas vendu. Dès qu'un enchérisseur saisit un maximum capable de couvrir la réserve, le prix affiché remonte automatiquement à la réserve, afin qu'il remporte le lot au juste prix.
## Achat immédiat et liste de surveillance
Si l'**achat immédiat** est autorisé, un client peut emporter le lot instantanément au prix fixe défini, ce qui clôture l'enchère sur-le-champ et déclenche la génération du bon gagnant.
La **liste de surveillance** permet à un client connecté de suivre une enchère via un bouton « Suivre », sans enchérir, pour la retrouver facilement.
## Clôture automatique : configurer le cron
Le module s'appuie sur une tâche cron pour démarrer les enchères programmées et clôturer celles arrivées à échéance. L'URL du cron, protégée par le jeton, est affichée sur la page de configuration. Elle ressemble à :
```
https://www.votreboutique.com/index.php?fc=module&module=dfauction&controller=cron&token=VOTRE_JETON
```
Programmez son appel à intervalle régulier (par exemple toutes les 5 minutes) via le cron de votre hébergeur ou un service de cron externe :
```
*/5 * * * * wget -q -O /dev/null "https://www.votreboutique.com/index.php?fc=module&module=dfauction&controller=cron&token=VOTRE_JETON"
```
Sans cron actif, les enchères ne se clôtureront pas automatiquement et les gagnants ne recevront pas leur bon. La fréquence du cron détermine aussi la précision de la clôture : un cron toutes les 5 minutes ferme les enchères avec au plus 5 minutes de décalage.
## Côté client
Sur la fiche produit mise aux enchères, le client voit un widget d'enchère affichant le prix actuel, un compte à rebours en direct, le nombre d'offres et d'enchérisseurs, ainsi qu'un champ pour saisir son enchère maximale. Le prix et le compte à rebours se rafraîchissent automatiquement. L'historique des offres est affiché sous pseudonymes si l'anonymisation est active.
## Le gagnant et le bon de réduction
À la clôture, si la réserve est atteinte (ou en cas d'achat immédiat), le module désigne le gagnant et génère pour lui un **bon de réduction privé et nominatif**, restreint à son compte. Ce bon lui permet de passer commande du produit au prix exact remporté. Sa durée de validité correspond au réglage « Validité du bon gagnant ».
## E-mails envoyés
- **Vous avez été surenchéri** : envoyé à un enchérisseur lorsqu'un concurrent passe devant lui.
- **Vous avez gagné** : envoyé au gagnant à la clôture, avec le code du bon de réduction.
Les modèles sont fournis en français et en anglais et sont personnalisables depuis la traduction des e-mails de PrestaShop.
## RGPD et confidentialité
Lorsque l'anonymisation est active, l'historique public des offres affiche un pseudonyme stable par enchérisseur (« Bidder #1234 ») au lieu de son nom réel. La transparence de la vente est préservée sans exposer l'identité des participants.
## Questions fréquentes
### Le prix de réserve est-il visible par les clients ?
Non. Il reste masqué. Les clients voient seulement si la réserve est atteinte ou non.
### Que se passe-t-il si la réserve n'est pas atteinte ?
Le lot n'est pas vendu et aucun bon n'est généré. L'enchère est clôturée sans gagnant.
### Deux enchérisseurs peuvent-ils saisir le même maximum ?
Oui. En cas d'égalité de plafond, c'est la première offre enregistrée qui conserve la tête.
### Puis-je avoir des fenêtres anti-sniping différentes selon les enchères ?
Oui. Chaque enchère peut définir sa propre fenêtre et sa propre prolongation, sinon les valeurs globales s'appliquent.
## Désinstallation
La désinstallation depuis le Gestionnaire de modules supprime les tables des enchères, des offres et des surveillances, ainsi que la configuration et les onglets de menu. Sauvegardez vos données au préalable si vous souhaitez les conserver.
---
### DataFirefly Avis Vérifiés — Documentation
_Source :_
> Prérequis et installation DataFirefly Avis Vérifiés fonctionne sur PrestaShop 8.0 à 9.0 avec PHP 8.0 à 8.4. Depuis la version 1.1.0, un seul ZIP couvre les deux branches : il…
## Prérequis et installation
DataFirefly Avis Vérifiés fonctionne sur PrestaShop 8.0 à 9.0 avec PHP 8.0 à 8.4. Depuis la version 1.1.0, un seul ZIP couvre les deux branches : il n'y a pas de version PS 8 et de version PS 9 à choisir au téléchargement.
1. Dans votre back-office, ouvrez **Modules → Gestionnaire de modules** puis cliquez sur **Installer un module**.
2. Déposez le fichier `dfreviews.zip` téléchargé depuis votre compte DataFirefly.
3. Cliquez sur **Configurer** une fois l'installation terminée.
L'installation crée six tables dédiées (avis, médias, demandes, votes utiles, résumés IA, statistiques) et ajoute un onglet **Avis Vérifiés** sous le menu **Catalogue**. C'est depuis cet onglet que vous modérez les avis ; l'écran de configuration, lui, reste accessible depuis le gestionnaire de modules.
Si une première tentative d'installation a échoué, relancez-la simplement : depuis la 1.1.0, l'onglet d'administration est créé de façon idempotente et ne se dupliquera pas.
## Configurer le déclenchement des demandes d'avis
C'est le cœur du module. Deux réglages, dans la section **Paramètres généraux** :
- **Déclencher après le statut** : _Expédié_ (par défaut) ou _Livré_. Choisissez celui qui, dans votre flux réel, signale que le client a le produit en main.
- **Délai avant envoi** : 3 jours par défaut. Comptez le temps de livraison plus quelques jours d'usage. Pour un produit qui se juge à l'usage (cosmétique, matelas), montez à 10 ou 15 jours.
Quand une commande atteint le statut choisi, une demande est mise en file d'attente avec sa date d'envoi calculée. Elle n'est pas envoyée immédiatement : c'est le CRON qui s'en charge.
## Mettre le CRON en place
Sans CRON, aucun email ne part. L'URL à appeler est affichée en haut de l'écran de configuration du module ; elle contient un jeton unique généré à l'installation. Programmez-la **toutes les heures** chez votre hébergeur :
```
0 * * * * wget -q -O /dev/null "URL_CRON_AFFICHEE_DANS_LE_MODULE"
```
À chaque passage, le CRON effectue trois traitements et renvoie un résumé JSON du travail accompli :
- envoi des demandes arrivées à échéance, par lots de 50 ;
- envoi des relances pour les demandes restées sans réponse ;
- expiration des demandes de plus de 60 jours.
Le jeton du CRON est un secret : ne le publiez pas et ne l'envoyez pas en clair. Toute requête sans le bon jeton reçoit une réponse 403.
## Relances et code promo en récompense
La section **Relance** active un second email si l'avis n'a pas été déposé après un délai configurable (5 jours par défaut, décompté depuis le premier envoi). Une seule relance est envoyée par demande.
La section **Code promo incitatif** génère un bon de réduction dès qu'un avis est publié par un client identifié. Vous définissez le pourcentage (10 % par défaut) et la durée de validité (30 jours). Le code créé est une règle panier PrestaShop native, nominative et à usage unique — vous le retrouvez donc dans **Catalogue → Réductions**.
Le code n'est généré que pour un client connecté ou identifié par une commande. Un avis invité ne déclenche aucune récompense.
## Activer le résumé IA
Renseignez votre clé API OpenAI dans la section **Intelligence Artificielle** et choisissez un modèle. `gpt-4o-mini` est retenu par défaut : c'est le plus économique, de l'ordre du demi-centime par résumé.
Le résumé se déclenche à partir de **trois avis publiés** sur un produit. Le module envoie jusqu'à 100 avis à OpenAI et récupère trois éléments structurés : points forts, points faibles, synthèse globale. Le résultat est mis en cache par produit, par boutique et par langue, puis affiché en haut de la zone avis de la fiche produit.
Vous pouvez désactiver l'affichage sans supprimer la clé grâce à l'option **Afficher le résumé IA sur la page produit**.
## Rich snippets et affichage front-office
Quand l'option **Rich Snippets** est active, le module injecte des données structurées Schema.org (AggregateRating, Review, Offer, Brand) sur chaque fiche produit atteignant le nombre minimum d'avis configuré. Vérifiez le rendu avec l'outil de test des résultats enrichis de Google après le passage du robot.
Côté affichage, le module s'accroche aux hooks natifs du thème :
- `displayProductAdditionalInfo` : les étoiles et la note moyenne sous le titre du produit ;
- `displayProductExtraContent` : l'onglet « Avis clients » avec la liste, les filtres et le formulaire ;
- `displayProductListReviews` : les étoiles sur les listings de catégorie ;
- `displayCustomerAccount` : le lien « Mes avis » dans le compte client.
Ces hooks existent dans les thèmes Classic et Hummingbird. Sur un thème sur mesure qui les aurait retirés, il faut les rétablir dans les templates concernés, sans quoi les avis ne s'afficheront nulle part.
## Modérer les avis
L'écran **Catalogue → Avis Vérifiés** affiche un tableau de bord (total, publiés, en attente, signalés, note moyenne, demandes en file) suivi de la liste complète des avis.
Par défaut, chaque avis attend votre validation. Activez **Approbation automatique** si vous préférez la publication immédiate. Depuis la liste, vous pouvez approuver ou rejeter en masse, et ouvrir un avis pour l'éditer ou lui répondre.
La **réponse du marchand** s'affiche publiquement sous l'avis. Si une clé OpenAI est configurée, un bouton **Suggestion IA de réponse** propose un brouillon adapté au ton de l'avis — à relire et ajuster avant enregistrement, jamais à publier tel quel.
## Photos client
Les clients peuvent joindre jusqu'à N photos par avis (3 par défaut). Formats acceptés : JPEG, PNG et WebP, 5 Mo maximum par fichier. Le type réel du fichier est vérifié à la réception, indépendamment de son nom.
Les images sont stockées dans `modules/dfreviews/uploads/`. Pensez à inclure ce dossier dans vos sauvegardes : supprimer un avis supprime aussi ses fichiers.
## Importer et exporter des avis
Depuis l'écran Avis Vérifiés, le bouton **Exporter CSV** produit un fichier UTF-8 séparé par des points-virgules, directement lisible dans Excel. Le bloc d'import, juste en dessous, permet de charger un fichier au même format.
Deux colonnes sont obligatoires : `id_product` et `rating` (de 1 à 5). Les autres sont facultatives : `customer_name`, `customer_email`, `title`, `content`, `id_customer`, `id_order`, `verified_purchase`, `active`, `merchant_reply` et `date_add`. Les lignes dont le produit n'existe pas sont ignorées et signalées. Cochez **Auto-approuver** pour publier directement les avis importés.
Le plus simple pour préparer une migration depuis Trustpilot ou un ancien module : exporter d'abord un fichier depuis le module pour récupérer l'en-tête exact, puis y verser vos données.
## Multi-boutique et multilingue
Toute la configuration est indépendante par sous-boutique : clé OpenAI, statut déclencheur, délais, couleurs, incentive. Les avis sont cloisonnés par `id_shop`, donc un même produit présent dans plusieurs boutiques peut afficher des ensembles d'avis différents selon le contexte.
Les avis et les résumés IA sont stockés avec leur `id_lang`. Un résumé est généré pour la langue dans laquelle il est demandé.
## Passer de PrestaShop 8 à PrestaShop 9
Aucune migration de données n'est nécessaire : le schéma est identique sur les deux branches. Remplacez le module par la version 1.1.0 avant ou après votre montée de version PrestaShop, dans l'ordre qui vous arrange.
Si vous mettez à jour depuis une 1.0.x sur une boutique déjà passée en PS 9, deux points à connaître : les versions antérieures à la 1.1.0 ne s'installent pas sur PS 9 (l'enregistrement de hooks sans méthode correspondante y est refusé), et la configuration existante est intégralement conservée lors de la mise à jour.
## Dépannage
**Aucun email de demande n'est envoyé.** Vérifiez d'abord que le CRON tourne réellement en appelant son URL à la main : la réponse JSON indique le nombre d'envois. Contrôlez ensuite le statut déclencheur configuré, puis les réglages email de la boutique dans **Paramètres avancés → E-mail**.
**Les étoiles n'apparaissent pas sur la fiche produit.** Le thème n'appelle probablement pas les hooks listés plus haut. Vérifiez aussi qu'au moins un avis est publié : sans avis actif, rien ne s'affiche.
**Le résumé IA ne se génère pas.** Il faut trois avis publiés minimum et une clé OpenAI valide et créditée. Les erreurs d'appel API sont tracées dans **Paramètres avancés → Logs**.
**Les étoiles ne remontent pas dans Google.** L'indexation prend de quelques jours à quelques semaines. Vérifiez le balisage avec l'outil de test des résultats enrichis, et contrôlez qu'un autre module SEO n'injecte pas un second bloc Product concurrent sur la même page.
**L'import CSV ne fait rien.** C'était un défaut des versions 1.0.x, corrigé en 1.1.0.
---
### DataFirefly B2B Team — Documentation
_Source :_
> Présentation DataFirefly B2B Team transforme un compte client PrestaShop en véritable organisation B2B : une société regroupe plusieurs acheteurs, chacun doté d'un rôle, d'un budget et d'un seuil d'autorisation. Les…
## Présentation
DataFirefly B2B Team transforme un compte client PrestaShop en véritable organisation B2B : une société regroupe plusieurs acheteurs, chacun doté d'un rôle, d'un budget et d'un seuil d'autorisation. Les commandes qui dépassent l'autorisation d'un acheteur passent par une chaîne de validation hiérarchique avant d'être créées.
Le module est complémentaire de _dfb2bquote_ (devis B2B) et de _dfgroupassign_ (validation VIES) : il joue le rôle de hub d'organisation du compte B2B.
## Installation
1. Déposez le dossier `dfb2bteam` dans le répertoire `/modules/` de votre boutique, ou installez l'archive ZIP depuis **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer**. Le module crée automatiquement ses tables, deux statuts de commande, cinq rôles système, deux paliers de validation par défaut et les onglets d'administration sous **Clients > B2B Team**.
3. Videz le cache PrestaShop si nécessaire depuis **Paramètres avancés > Performances**.
## Concepts clés
### Société
Une société représente une organisation cliente. Elle possède un client propriétaire (l'administrateur), un groupe client associé qui détermine le catalogue et les tarifs, un plafond de crédit et des options : paiement sur compte, bon de commande obligatoire, restriction des adresses et restriction du catalogue.
### Membre
Un membre relie un client à une société, avec un rôle, un budget éventuel et un seuil d'autorisation personnel. Dans cette version, un client n'appartient qu'à une seule société.
### Rôle
Un rôle définit les permissions et le niveau d'approbation. Cinq rôles système sont fournis et ne peuvent pas être supprimés ; vous pouvez créer vos propres rôles.
## Rôles et permissions
Chaque rôle combine quatre permissions et un niveau d'approbation :
- **Commander** : passer des commandes.
- **Approuver** : valider les demandes en attente.
- **Gérer** : administrer les membres, budgets et paramètres de la société.
- **Voir la comptabilité** : consulter l'encours et les factures.
- **Niveau d'approbation** : plus il est élevé, plus le rôle peut valider des paliers importants. La valeur 0 signifie aucun pouvoir d'approbation.
Rôles fournis : Administrateur (niveau 9), Approbateur (niveau 5), Acheteur (niveau 0), Comptabilité et Lecture seule.
## Validation hiérarchique
Une commande nécessite une approbation lorsque l'une de ces conditions est remplie : le budget du membre est dépassé, le montant atteint son seuil d'autorisation personnel, ou le montant correspond à un ou plusieurs paliers de workflow.
### Paliers de workflow
Chaque palier définit un montant minimum, un niveau de séquence et le niveau de rôle requis pour le valider. Les paliers peuvent être globaux (valables pour toutes les sociétés) ou propres à une société, qui prennent alors le pas sur les paliers globaux. Deux paliers globaux sont créés à l'installation : à partir de 1 000 € un Manager (niveau 5), à partir de 5 000 € la Direction (niveau 9).
### Déroulé
Lorsqu'une approbation est requise, l'acheteur soumet sa commande depuis le tunnel de paiement. Une demande est créée avec un instantané figé du panier ; aucune commande n'est créée à ce stade. Les approbateurs sont notifiés par e-mail et traitent la demande depuis **Mon compte > Validations**. À l'approbation finale, la commande est créée au statut « B2B - Paiement sur compte », puis le budget du membre et l'encours de la société sont consommés.
L'instantané figé garantit que les prix et les quantités ne dérivent pas entre la soumission et l'approbation.
## Budgets et départements
Chaque membre peut disposer d'un budget plafonné, réinitialisé automatiquement chaque mois, trimestre ou année. Un budget à 0 signifie illimité. Les départements, ou centres de coût, permettent de regrouper les membres et de suivre les dépenses par service.
## Paiement sur compte et bon de commande
Si la société autorise le paiement sur compte, ses acheteurs peuvent commander dans la limite de l'encours disponible (plafond de crédit moins encours utilisé). La commande est créée non réglée, au statut « B2B - Paiement sur compte », pour une facturation à terme. Un numéro de bon de commande (PO) peut être rendu obligatoire au niveau de la société.
## Commande rapide et listes partagées
La commande rapide permet d'ajouter de nombreux produits au panier par référence (SKU), avec recherche instantanée. Les listes d'achat, privées ou partagées avec toute la société, se rechargent dans le panier en un clic — idéal pour les réassorts récurrents.
## Journal d'audit et reporting
Chaque action — soumission, approbation, refus, ajout de membre — est enregistrée dans un journal d'audit inaltérable, avec horodatage et adresse IP, consultable sous **Clients > B2B Team > Journal d'audit**. Le tableau de bord des validations affiche les indicateurs clés : demandes en attente, approuvées, refusées, taux d'approbation et valeur en attente.
## Restriction stricte des paiements
Un module ne peut pas masquer de façon fiable les modes de paiement des autres modules au moment du checkout. Pour forcer les membres B2B à n'utiliser que le flux d'approbation ou le paiement sur compte, restreignez les modes de paiement du groupe client de la société dans **Paiement > Préférences**.
## FAQ
### Le module remplace-t-il dfb2bquote ?
Non. B2B Team gère l'organisation, les rôles et la validation ; dfb2bquote gère les devis. Les deux sont complémentaires et fonctionnent ensemble.
### Une commande est-elle créée avant l'approbation ?
Non. La commande n'est créée qu'à l'approbation finale, à partir de l'instantané figé du panier.
### Le module est-il compatible PrestaShop 9 et multiboutique ?
Oui. Les contrôleurs d'administration reposent sur ModuleAdminController pour la compatibilité PrestaShop 8 et 9, et le module gère le contexte multiboutique.
---
### DataFirefly Blog SEO IA Pro — Guide complet
_Source :_
> Présentation DataFirefly Blog SEO IA Pro transforme votre boutique PrestaShop 8 ou 9 en machine de publication éditoriale automatisée. Le module analyse votre catalogue, propose une structure de blog complète…
## Présentation
DataFirefly Blog SEO IA Pro transforme votre boutique PrestaShop 8 ou 9 en machine de publication éditoriale automatisée. Le module analyse votre catalogue, propose une structure de blog complète en un clic, suggère des articles en lot et les publie selon le calendrier que vous définissez — un article tous les N jours si vous le souhaitez, sans intervention manuelle.
Cinq fournisseurs d'IA sont pris en charge et basculables à tout moment : OpenAI, Anthropic Claude, Google Gemini, Mistral et DeepSeek. Chaque appel est journalisé avec son coût réel en USD.
## Installation
1. Téléchargez le fichier zip du module depuis votre compte DataFirefly.
2. Dans le back-office PrestaShop, ouvrez Modules puis Ajouter un module, et importez le zip.
3. Cliquez sur Installer. Le module crée ses 21 tables, ses 12 onglets d'administration et génère automatiquement un token de sécurité aléatoire pour le cron.
4. Un nouveau menu « Blog » apparaît dans la barre latérale du back-office.
Mise à jour depuis une version 1.0.x : remplacez simplement le dossier du module puis rechargez la page — le script de mise à niveau crée les nouvelles tables sans toucher à vos données existantes.
## Configuration des clés API
Ouvrez Blog puis Configuration. Renseignez la clé API du ou des fournisseurs d'IA que vous comptez utiliser :
- OpenAI : clé commençant par sk- depuis platform.openai.com
- Anthropic Claude : clé depuis console.anthropic.com
- Google Gemini : clé depuis aistudio.google.com
- Mistral : clé depuis console.mistral.ai
- DeepSeek : clé depuis platform.deepseek.com
Sélectionnez ensuite le fournisseur et le modèle par défaut. Vous pouvez changer de fournisseur à chaque génération sans reconfigurer.
## Setup automatique en 1 clic
Ouvrez Blog puis Stratégie & Setup. Le bouton « Analyser ma boutique et proposer une structure » lance une analyse de votre catalogue : catégories produits, fabricants, gammes de prix, échantillon de produits récents et articles de blog déjà existants.
L'IA vous propose alors :
- 5 à 8 catégories de blog avec nom, description, méta SEO et un prompt expert dédié par catégorie
- 15 à 25 tags transversaux
- 1 à 3 personas auteur avec biographie crédible
- Une ligne éditoriale globale et des mots-clés piliers
Chaque élément est présenté avec une case à cocher. Décochez ce que vous ne voulez pas, puis cliquez sur « Appliquer la sélection en bloc ». Les entités sont créées immédiatement. Un champ facultatif « Focus éditorial » vous permet d'orienter la proposition (par exemple : audience B2B, angle écoresponsable, ton technique).
## Suggestions d'articles en lot
Ouvrez Blog puis Suggestions d'articles. Choisissez le nombre d'idées à générer (de 3 à 50), éventuellement une catégorie de blog cible, un mix funnel (TOFU découverte, MOFU comparaison, BOFU conversion, ou équilibré), une longueur cible et un mot-clé pilier.
Chaque suggestion est une carte complète : titre SEO, mot-clé cible, plan en 4 à 6 H2, catégorie suggérée, produits de votre catalogue à mentionner en cross-sell, stade funnel et estimation du coût IA de génération.
Cochez les cartes à retenir puis choisissez le mode de planification :
- Générer maintenant : les articles sont traités dès le prochain passage du cron ou via le bouton de traitement manuel
- Planifier à une date précise : tous les articles sélectionnés partagent la même date
- Un article tous les N jours : les dates sont étalées automatiquement à partir de la date de départ que vous indiquez
Le sélecteur « Auto-publish » détermine si les articles générés sont publiés directement ou enregistrés en brouillon pour relecture.
## File de génération et cron
Ouvrez Blog puis File de génération. Vous y suivez chaque tâche : statut (en attente, en cours, publié, échoué, annulé), date programmée, tentatives, coût réel et message d'erreur éventuel. Les actions Annuler, Réessayer et Voir l'article sont disponibles par ligne.
Pour un fonctionnement entièrement automatique, copiez l'URL de cron affichée en haut de l'écran (elle contient votre token de sécurité) et configurez-la dans le cron de votre hébergement ou sur un service comme cron-job.org, à fréquence horaire. À chaque passage, le cron traite les tâches arrivées à échéance, par lot de 5 par défaut (configurable), avec 3 tentatives maximum par tâche en cas d'erreur d'API.
Le bouton « Traiter maintenant » permet aussi de lancer un lot manuellement sans attendre le cron.
## Mode expert : prompts par catégorie
Chaque catégorie de blog dispose d'un champ « Prompt override » dans sa fiche d'édition. Lorsqu'il est renseigné, ce texte est ajouté au prompt système de l'IA à chaque génération d'article dans cette catégorie. Vous pouvez ainsi imposer un ton expert sur une catégorie B2B et un ton accessible sur une catégorie grand public, dans la même boutique. Le setup automatique pré-remplit ce champ avec une proposition adaptée à chaque catégorie.
## Maillage interne automatique
Ouvrez Blog puis Liens internes. Définissez vos règles mot-clé vers URL : produit, catégorie, page CMS, autre article ou URL personnalisée. Options par règle : ancres rotatives, nofollow, correspondance exacte, nombre maximal d'insertions par article et distance minimale entre deux liens. Le moteur traite chaque article à la sauvegarde et injecte les liens dans le HTML rendu, sans impact sur les performances du front.
## SEO, données structurées et AEO
Le module gère automatiquement : balises title et description, Open Graph, Twitter Cards, canonical, hreflang multilingue, sitemap XML dédié au blog, flux RSS 2.0 et fichier llms.txt par catégorie pour les moteurs de réponse IA. Les données structurées Schema.org BlogPosting, BreadcrumbList et FAQPage sont générées sur chaque article. La FAQ de chaque article est stockée au format JSON et rendue en accordéon accessible.
## Produits associés et widget fiche produit
Trois modes de sélection des produits mis en avant sous chaque article : manuel, automatique par mots-clés, automatique par IA. Sur les fiches produit de votre boutique, un widget « Articles mentionnant ce produit » crée le maillage inverse blog vers catalogue.
## Design front
Le rendu front adopte une direction éditoriale soignée : titres en serif, sommaire collant avec suivi de lecture sur desktop, barre de progression de lecture, lettrine sur le premier paragraphe, FAQ en accordéon, bouton retour en haut et feuille de style d'impression. L'ensemble est isolé sous le préfixe dfblog et compatible avec les thèmes Classic et Hummingbird. Toutes les couleurs et polices sont centralisées en variables CSS en tête du fichier front.css pour une personnalisation en une ligne.
## Dépannage
- Erreur 500 sur les écrans IA : vérifiez que la clé API du fournisseur sélectionné est renseignée dans Configuration et que votre quota n'est pas épuisé. Le détail de l'erreur apparaît dans la réponse réseau (onglet Network du navigateur) et dans la colonne Erreur de la file de génération.
- Article vide ou trop court : la file passe la tâche en échec avec un message explicite. Vérifiez la clé API et le modèle configuré, puis utilisez Réessayer.
- CSS ou JS non chargés en front : assurez-vous d'utiliser la version 1.1.0 ou supérieure du module, qui autorise les ressources statiques dans son fichier htaccess, puis videz le cache PrestaShop (Paramètres avancés puis Performance).
- Tâches bloquées en attente : vérifiez que l'URL de cron est bien appelée (le test dans un navigateur doit renvoyer un JSON) et que le token correspond à celui affiché dans l'écran File de génération.
## Questions fréquentes
### Le module fonctionne-t-il en multiboutique et multilingue ?
Oui. Articles, catégories, tags et auteurs sont multilingues et associés par boutique. Les traductions d'interface sont fournies en français, anglais, espagnol et allemand.
### Puis-je changer de fournisseur d'IA en cours de route ?
Oui, à chaque génération. Les cinq fournisseurs partagent la même interface interne et le coût de chaque appel est journalisé.
### Les articles générés sont-ils publiés sans contrôle ?
Uniquement si vous activez Auto-publish. Par défaut, les articles arrivent en brouillon pour relecture avant publication.
### Que se passe-t-il à la désinstallation ?
La désinstallation supprime les tables du module et l'ensemble des contenus du blog. Exportez ou sauvegardez votre base au préalable si vous souhaitez conserver les articles.
---
### DataFirefly Cache Clear
_Source :_
> Présentation DataFirefly Cache Clear ajoute un bouton « Vider le cache » directement dans la barre d'outils du back-office de PrestaShop. Un seul clic purge l'ensemble des caches (Smarty, XML,…
## Présentation
DataFirefly Cache Clear ajoute un bouton « Vider le cache » directement dans la barre d'outils du back-office de PrestaShop. Un seul clic purge l'ensemble des caches (Smarty, XML, Media et Symfony), sans passer par Paramètres avancés puis Performances et sans recharger la page.
## Installation
1. Téléchargez l'archive `dfclearcache.zip` depuis votre compte DataFirefly.
2. Dans le back-office, ouvrez **Modules > Module Manager**.
3. Cliquez sur **Téléverser un module** et sélectionnez le ZIP.
4. Le module s'installe et s'active automatiquement.
Aucune configuration n'est nécessaire : dès l'activation, le bouton apparaît dans la barre d'outils de toutes les pages d'administration.
## Utilisation
Le bouton **« Vider le cache »** s'affiche dans la barre d'outils du back-office, à côté des actions de page et du bouton d'aide. Pour purger le cache :
1. Cliquez sur le bouton **« Vider le cache »**.
2. L'icône tourne pendant l'opération (purge en AJAX, sans rechargement).
3. Une notification verte confirme « Cache vidé avec succès » en quelques centièmes de seconde.
## Ce qui est vidé
En un clic, le module nettoie :
- le **cache Smarty** (templates compilés) ;
- le **cache XML** ;
- le **cache des médias** (CSS/JS combinés et minifiés) ;
- le **conteneur Symfony** de PrestaShop 8/9.
Si le conteneur Symfony n'est pas joignable, le module supprime directement le contenu du dossier `var/cache` de l'environnement courant (prod ou dev).
## Compatibilité
- PrestaShop 8.0 à 9.x
- PHP 7.4 à 8.x
- Mono-boutique et multiboutique
- Hook utilisé : `displayBackOfficeHeader`
## Dépannage
### Le bouton n'apparaît pas
Videz le cache de votre navigateur (Ctrl+F5) après l'installation : l'ancien CSS du back-office peut rester en cache. Vérifiez aussi que le module est bien activé dans le Module Manager.
### Le bouton reste sur sa propre ligne
Ce comportement d'affichage a été corrigé en version 1.0.1. Assurez-vous d'utiliser cette version ou une version ultérieure.
### Le clic n'a pas d'effet visible
La purge est silencieuse côté serveur ; seule la notification confirme l'opération. Si aucune notification n'apparaît, vérifiez la console de votre navigateur et les droits de l'employé connecté.
---
### DataFirefly Cleanup — Guide complet
_Source :_
> Présentation DataFirefly Cleanup est un module d'administration PrestaShop 8 et 9 qui nettoie votre base de données en toute sécurité : statistiques obsolètes, paniers abandonnés, logs anciens, recherches périmées, métadonnées…
## Présentation
DataFirefly Cleanup est un module d'administration PrestaShop 8 et 9 qui nettoie votre base de données en toute sécurité : statistiques obsolètes, paniers abandonnés, logs anciens, recherches périmées, métadonnées orphelines et images orphelines. Chaque nettoyeur propose trois modes — audit, dry-run et execute — et le module calcule le gain d'espace en MB avant toute action.
Le module ne modifie ni votre thème ni les fichiers du cœur PrestaShop. Il crée une seule table (l'historique des nettoyages) et un onglet d'administration.
## Installation
1. Téléchargez le fichier `dfcleanup.zip` depuis votre compte DataFirefly.
2. Dans votre back-office PrestaShop, allez dans **Modules > Gestionnaire de modules > Téléverser un module**.
3. Glissez le ZIP ou sélectionnez-le. L'installation crée la table d'historique, l'onglet admin et le jeton cron.
4. Ouvrez **Paramètres avancés > DataFirefly Cleanup**.
Prérequis : PrestaShop 8.0+ ou 9.0+, PHP 8.0+, MySQL 5.7+ ou MariaDB 10.3+.
## Le tableau de bord
L'écran principal affiche trois blocs d'information en tête :
- **Taille de la base** — l'espace total occupé par vos tables (données + index), calculé via `information_schema`.
- **Gain potentiel** — l'estimation de l'espace récupérable si tous les nettoyeurs étaient exécutés.
- **Pourcentage récupérable** — le ratio entre les deux.
En dessous, le **top 10 des plus grosses tables** vous montre où part réellement votre espace disque. Les tables de statistiques (`ps_connections`, `ps_page_viewed`) figurent presque toujours en tête sur un store actif.
## Les six nettoyeurs
### Statistiques
Nettoie `ps_connections` (et ses tables enfants `connections_page` et `connections_source`), `ps_page_viewed`, `ps_referrer_cache`, `ps_pagenotfound` et les guests orphelins. Rétention par défaut : 90 jours. C'est généralement le nettoyeur au plus fort gain — les tables de stats croissent à chaque visite.
### Paniers abandonnés
Supprime les paniers sans commande associée plus anciens que la rétention (30 jours par défaut), ainsi que les lignes orphelines de `cart_product` et `cart_cart_rule`, et les règles panier expirées.
Un panier converti en commande n'est **jamais** supprimé : chaque requête vérifie l'absence de commande via une jointure sur `ps_orders`. Vos données de commande sont intouchables.
### Logs application
Élague `ps_log` avec une rétention pondérée par sévérité : les entrées informatives et les avertissements (sévérité 1-2) sont supprimés après la rétention configurée (30 jours par défaut), tandis que les erreurs et erreurs critiques (sévérité 3-4) sont conservées deux fois plus longtemps.
### Recherches obsolètes
Nettoie l'historique `ps_statssearch` (60 jours par défaut) et les lignes orphelines de l'index de recherche (`search_index`, `search_word`) pointant vers des produits supprimés.
### Métadonnées orphelines
Cible les lignes dont le parent n'existe plus : `product_lang`, `product_shop`, `product_attribute`, `category_product`, `stock_available`, `specific_price`, `customization`, adresses soft-deleted sans commande, `image_lang` et `image_shop`. Pas de notion de rétention ici : un orphelin est un orphelin.
### Images orphelines
Deux volets : les entrées `ps_image` dont le produit n'existe plus (toujours actif), et un **scan du système de fichiers** optionnel qui parcourt le dossier des images produits à la recherche de fichiers JPG sans entrée en base. Le scan est plafonné à 200 000 fichiers par sécurité.
## Les trois modes
ModeÉcriture en baseUsage**Audit**AucuneCompter les lignes concernées et estimer le gain. À lancer en premier, toujours.**Dry-run**Historique uniquementSimuler l'exécution et garder une trace datée du périmètre.**Execute**Suppression réelleSupprimer par lots de 5 000 lignes (configurable), avec micro-pauses entre lots.
**Avant tout Execute : sauvegardez votre base.** Le nettoyage est irréversible. Workflow recommandé : Audit → Dry-run → Backup → Execute → OPTIMIZE TABLE.
## OPTIMIZE TABLE
Supprimer des lignes ne rend pas immédiatement l'espace au système : InnoDB conserve l'espace dans le fichier de table. La case **OPTIMIZE TABLE après exécution** reconstruit les tables nettoyées pour restituer l'espace physique au disque (nécessite `innodb_file_per_table`, activé par défaut sur les installations modernes). À réserver aux heures creuses : l'opération verrouille brièvement chaque table.
## Tâche cron
Le panneau **Nettoyage planifié (cron)** du dashboard vous permet d'automatiser les nettoyages.
### Configuration
- **Activer le cron** — interrupteur global. Désactivé, l'endpoint répond 503 même avec un jeton valide.
- **Mode** — audit, dry-run (défaut, sans risque), execute, ou execute + OPTIMIZE.
- **Nettoyeurs à exécuter** — cases à cocher. Par défaut : stats, cart, log, search. Metadata et image sont opt-in.
### URL et jeton
L'endpoint public est `/module/dfcleanup/cron?token=VOTRE_JETON`. Le jeton (32 caractères hexadécimaux) est généré à l'installation et vérifié en temps constant. Le bouton **Régénérer le jeton** invalide immédiatement l'ancienne URL.
### Planification
Deux options :
1. **Module cronjobs PrestaShop** — si installé, la tâche s'y inscrit automatiquement (hook `actionRetrieveCronJobs`), planifiée à 3h00 chaque jour. Modifiez l'horaire depuis la configuration du module cronjobs.
2. **Crontab système** — copiez la ligne affichée dans l'admin :
```
0 3 * * * /usr/bin/curl -s 'https://votre-boutique.com/module/dfcleanup/cron?token=XXXX' > /dev/null 2>&1
```
### Surcharges ponctuelles
Vous pouvez surcharger le mode et les nettoyeurs pour un appel donné, sans toucher à la configuration :
```
?token=XXXX&mode=audit
?token=XXXX&mode=execute&cleaners=stats,log
```
Le bouton **Lancer le cron maintenant** exécute immédiatement la configuration courante — pratique pour tester sans attendre la prochaine échéance.
## Réglages
- **Taille de lot** — nombre de lignes supprimées par requête (défaut 5 000, min 100, max 100 000). Baissez sur un mutualisé contraint, montez sur un serveur dédié costaud.
- **Rétention de l'historique** — durée de conservation des entrées d'historique du module (180 jours par défaut).
- **Rétention par nettoyeur** — en jours. 0 = désactive le filtre temporel (les nettoyeurs d'orphelins ignorent ce réglage).
## Historique
Chaque action (audit, dry-run, execute — manuelle ou cron) est consignée : nettoyeur, mode, lignes affectées, octets libérés, détail par table en JSON, opérateur (email admin, `cron` ou `cron (manual)`), date. La table d'historique est purgée automatiquement selon la rétention configurée.
## Dépannage
### Timeout sur les grosses suppressions
Le module désactive la limite de temps PHP pendant l'exécution, mais certains hébergeurs imposent des limites au niveau du serveur web. Dans ce cas, réduisez la taille de lot, exécutez cleaner par cleaner, ou passez par le cron en CLI (curl depuis crontab n'est pas soumis aux limites du serveur web).
### L'endpoint cron répond 403
Le jeton fourni ne correspond pas. Vérifiez que l'URL de votre crontab est à jour — un jeton régénéré invalide l'ancienne URL.
### L'endpoint cron répond 503
Le cron est désactivé dans les réglages du module. Activez-le depuis le panneau Nettoyage planifié.
### Le gain affiché diffère de l'espace réellement libéré
Le gain est une estimation proportionnelle (`lignes_supprimées / lignes_totales × taille_table`). L'espace réel restitué au disque dépend d'OPTIMIZE TABLE et de la fragmentation. L'estimation est volontairement conservatrice.
## Notes techniques
- Le module utilise une détection de schéma défensive (`tableExists` / `columnExists` via `information_schema`) : il s'adapte aux différences PS 8 / PS 9 et ignore les tables absentes.
- Les suppressions single-table sont batchées avec `LIMIT` ; les suppressions multi-table (jointures) s'exécutent en un seul ordre, MySQL n'autorisant pas `LIMIT` sur cette syntaxe.
- Le jeton cron est comparé via `hash_equals` (temps constant) pour résister aux attaques par chronométrage.
- Compatible multiboutique. Interface en FR/EN/ES/DE.
---
### DataFirefly Cookie Consent — Guide complet
_Source :_
> Présentation DataFirefly Cookie Consent est un plugin WordPress et WooCommerce de gestion du consentement aux cookies. Il combine trois briques : un bandeau de consentement conforme RGPD/CNIL/Garante, l'émission native des…
## Présentation
DataFirefly Cookie Consent est un plugin WordPress et WooCommerce de gestion du consentement aux cookies. Il combine trois briques : un bandeau de consentement conforme RGPD/CNIL/Garante, l'émission native des signaux Google Consent Mode v2 avant tout tag Google, et un audit qui détecte les trackers réellement chargés sur votre site avec journal de preuve exportable.
## Prérequis
- WordPress 6.2 ou supérieur
- PHP 8.0 ou supérieur
- WooCommerce 8.0+ (optionnel — le plugin fonctionne aussi sur WordPress seul, compatibilité HPOS déclarée)
- GTM ou GA4 déjà installé si vous voulez profiter du Consent Mode v2 (le plugin n'installe pas les tags Google à votre place)
## Installation
1. Téléchargez le fichier `df-cookie-consent.zip` depuis votre compte DataFirefly.
2. Dans l'admin WordPress, allez dans **Extensions → Ajouter → Téléverser une extension**, sélectionnez le ZIP puis cliquez sur **Installer maintenant**.
3. Cliquez sur **Activer**. À l'activation, le plugin crée la table de journal `wp_dfcc_consent_log`, génère un salt aléatoire pour le hash des IPs et programme deux tâches cron (purge quotidienne du journal et scan des trackers).
4. Un nouveau menu **Cookie Consent** apparaît dans la barre latérale de l'admin avec quatre pages : Tableau de bord, Réglages, Audit et Journal.
Le bandeau s'affiche immédiatement sur le frontend avec les réglages par défaut (layout barre en bas de page, thème clair, mode opt-in, les 4 catégories activées).
## Configuration du bandeau
Tous les réglages se trouvent dans **Cookie Consent → Réglages**.
### Comportement général
- **Activer le bandeau** : interrupteur global du plugin.
- **Mode** : opt-in (obligatoire en UE — aucun cookie non essentiel avant consentement) ou opt-out.
- **Bouton Tout refuser au premier niveau** : activé par défaut, conformément à la recommandation CNIL du 17 septembre 2020. Ne le désactivez pas si votre audience est européenne.
- **Durée de vie du cookie de consentement** : 180 jours par défaut. Le choix de l'utilisateur est stocké dans le cookie `dfcc_consent` (encodé, first-party).
- **Version de la politique** : incrémentez ce numéro quand votre politique cookies change de manière substantielle — le bandeau sera automatiquement re-présenté à tous les visiteurs et le journal enregistrera la nouvelle version.
### Apparence
- **Layout** : barre pleine largeur, carte d'angle ou modal centrée.
- **Position** : haut ou bas de page (pour les layouts barre et carte).
- **Thème** : clair, sombre ou auto (suit la préférence système du visiteur via prefers-color-scheme).
- **Couleur d'accent** : personnalise la couleur du bouton principal.
Sur mobile (moins de 640 px), le bandeau passe automatiquement en plein écran pour rester lisible. Les animations respectent prefers-reduced-motion.
### Catégories de cookies
Quatre catégories sont préconfigurées, chacune avec un libellé et une description modifiables :
- **Nécessaires** (necessary) — toujours actifs, non désactivables par le visiteur : panier, session, sécurité.
- **Fonctionnels** (functional) — préférences, langue, chat.
- **Mesure d'audience** (analytics) — Google Analytics, Matomo, etc.
- **Publicité ciblée** (marketing) — Google Ads, Meta Pixel, remarketing.
### Textes et liens
Le titre du bandeau, le texte d'introduction et les libellés des quatre boutons (Tout accepter, Tout refuser, Personnaliser, Enregistrer mes choix) sont modifiables dans les réglages. Renseignez également les URLs de votre politique de confidentialité et de votre politique cookies — elles s'affichent en liens discrets sous les boutons. Tous les textes passent par les fonctions de traduction WordPress : le plugin est livré avec 5 catalogues (FR, EN, ES, DE, IT) et reste surchargeable via Loco Translate.
## Google Consent Mode v2
C'est le cœur technique du plugin. Depuis mars 2024, Google exige que les sites européens émettent les 7 signaux Consent Mode v2 pour continuer à mesurer les conversions Google Ads et construire les audiences GA4.
### Fonctionnement
Le plugin imprime un bloc `gtag('consent', 'default', ...)` dans le head HTML avec la priorité 1 de wp_head — c'est-à-dire avant tout container GTM ou tag GA4 chargé de manière standard. Les 7 signaux émis :
- `ad_storage`, `ad_user_data`, `ad_personalization` — pilotés par la catégorie Publicité ciblée
- `analytics_storage` — piloté par la catégorie Mesure d'audience
- `functionality_storage`, `personalization_storage` — pilotés par la catégorie Fonctionnels
- `security_storage` — toujours granted (recommandation Google)
Le mapping catégories → signaux est automatique : aucun paramétrage manuel n'est nécessaire. Quand le visiteur fait son choix, un `gtag('consent', 'update', ...)` est émis immédiatement et le choix est réappliqué comme état par défaut à chaque page suivante.
### Réglages Consent Mode
- **Région EEA** : par défaut, le deny strict ne s'applique qu'aux 31 pays de l'EEE (plus Royaume-Uni et Suisse) via le paramètre region de gtag — le reste du monde reste en granted. Détection Cloudflare native via l'en-tête CF-IPCountry.
- **url_passthrough** : activé par défaut. Conserve les identifiants de clic gclid et dclid dans les URLs même en cas de refus, ce qui permet la mesure de conversions sans cookies.
- **ads_data_redaction** : activé par défaut. Censure les données utilisateur envoyées à Google quand ad_storage est denied.
- **wait_for_update** : 500 ms par défaut. Délai laissé aux tags Google pour attendre la mise à jour du consentement.
### Vérifier que tout fonctionne
1. Ouvrez votre site en navigation privée, ouvrez la console du navigateur et tapez `dataLayer` : vous devez voir l'entrée consent default avant l'entrée gtm.js.
2. Dans Google Tag Assistant ou le mode Preview de GTM, l'onglet Consent doit afficher les 7 signaux avec leur état.
3. Acceptez le bandeau puis retapez `dataLayer` : une entrée consent update doit apparaître avec les nouveaux états.
## Audit de conformité
La page **Cookie Consent → Audit** lance un scan qui va chercher votre page d'accueil et analyse le HTML réellement servi.
### Ce que détecte le scan
- **23 trackers connus** : Google Analytics 4, GTM, Meta Pixel, TikTok, LinkedIn, Pinterest, Snapchat, Twitter/X, Bing UET, Matomo, Microsoft Clarity, Hotjar, Mixpanel, Plausible, HubSpot, Intercom, Crisp, Tawk, YouTube, Vimeo, Stripe et autres — chacun classé dans sa catégorie de consentement attendue.
- **11 plugins WordPress à risque** : MonsterInsights, Site Kit, PixelYourSite, Facebook/Pinterest/TikTok for WooCommerce, HubSpot, MC4WP et autres plugins qui injectent des trackers de leur côté.
- **Cookies posés côté serveur** : snapshot avec identification automatique du vendor (_ga, _fbp, _gcl, etc.).
### Score et recommandations
Le scan produit un score de conformité de 0 à 100 basé sur l'écart entre vos catégories déclarées et les trackers réellement détectés. Les problèmes sont classés en trois niveaux — critical, warning, info — chacun avec une recommandation actionnable (par exemple : un tracker marketing détecté alors que la catégorie est désactivée dans le bandeau). Un scan automatique tourne aussi en tâche de fond via le cron `dfcc_cron_scan_trackers`.
## Journal de consentement
La page **Cookie Consent → Journal** liste chaque événement de consentement enregistré dans la table dédiée `wp_dfcc_consent_log`.
### Données enregistrées
- Horodatage UTC, UID anonyme persistant (traçabilité multi-événements d'un même visiteur)
- Type d'événement : accept_all, reject_all, custom, withdraw
- État complet par catégorie, version de la politique et du bandeau
- IP doublement protégée : hash SHA-256 avec le salt aléatoire généré à l'activation (irréversible), plus IP tronquée à /24 (IPv4) ou /64 (IPv6) pour analyse anonyme
- User agent, URL de la page, referer, région, langue, user_id WordPress si connecté
### Filtres et export
Filtrez par période, type d'événement ou UID, puis exportez en CSV (BOM UTF-8, séparateur point-virgule — s'ouvre directement dans Excel français) ou en JSON pretty. Ces exports constituent votre preuve de consentement en cas de contrôle CNIL ou Garante.
### Rétention
Par défaut, le journal est conservé 1825 jours (5 ans, durée recommandée par la CNIL). La purge automatique tourne chaque nuit via le cron `dfcc_cron_purge_logs`. La rétention est ajustable dans les réglages. À noter : la désactivation du plugin conserve les logs (preuve de consentement) ; seule la désinstallation complète via Extensions → Supprimer purge la table, les options et les crons.
## Lien "Gérer mes cookies" dans le footer
La réglementation impose que le visiteur puisse modifier son choix à tout moment. Deux options :
- **Shortcode** : placez `` dans un widget ou un menu de footer — il génère un lien qui rouvre la modal de personnalisation.
- **API JavaScript** : appelez `window.dfcc.open()` depuis n'importe quel élément de votre thème.
## API pour les développeurs
### API JavaScript
L'objet global `window.dfcc` expose :
- `dfcc.open()` — ouvre la modal de personnalisation
- `dfcc.accept()` — accepte toutes les catégories
- `dfcc.reject()` — refuse toutes les catégories optionnelles
- `dfcc.withdraw()` — retire le consentement (événement withdraw journalisé)
- `dfcc.getConsent()` — retourne l'état complet du consentement
- `dfcc.hasConsent('analytics')` — vérifie une catégorie donnée (utile pour conditionner vos propres scripts)
### Endpoint REST
Un endpoint POST est disponible sur `wp-json/dfcc/v1/consent` pour enregistrer un événement de consentement depuis votre propre code (protégé par nonce).
### Hooks WordPress
- `dfcc_before_banner_render` — action déclenchée avant le rendu du bandeau (pour le masquer sur certaines pages par exemple)
- `dfcc_after_consent_logged` — action déclenchée après chaque écriture dans le journal (pour synchroniser un CRM par exemple)
- `dfcc_consent_mode_defaults` — filtre sur les états par défaut des 7 signaux Consent Mode
- `dfcc_scan_trackers_patterns` — filtre pour ajouter vos propres patterns de détection au scanner
## Dépannage
- **Les signaux Consent Mode n'apparaissent pas avant GTM** : vérifiez qu'aucun plugin de performance ne déplace ou diffère les scripts du head. Le bloc dfcc-consent-mode-default doit rester inline et non différé.
- **Le bandeau réapparaît à chaque visite** : vérifiez qu'un système de cache ne sert pas une page figée avec un ancien cookie, et que la durée de vie du cookie n'est pas à 0.
- **Le scan d'audit échoue** : le serveur doit pouvoir faire une requête HTTP vers sa propre page d'accueil. Sur certains hébergements avec loopback bloqué, autorisez les requêtes locales ou vérifiez le pare-feu.
- **Les IPs journalisées sont celles de Cloudflare** : le plugin lit CF-Connecting-IP en priorité — si le problème persiste, vérifiez que votre configuration serveur transmet bien les en-têtes Cloudflare.
---
### DataFirefly Cookie Consent pour Shopware 6 — Documentation
_Source :_
> Présentation DataFirefly Cookie Consent est un plugin Shopware 6 qui remplace intégralement le bandeau cookies natif par un système moderne conforme RGPD/CNIL/Garante Privacy, avec Google Consent Mode v2 natif, audit…
## Présentation
DataFirefly Cookie Consent est un plugin Shopware 6 qui remplace intégralement le bandeau cookies natif par un système moderne conforme RGPD/CNIL/Garante Privacy, avec Google Consent Mode v2 natif, audit réel des trackers, et journal d'audit cryptographiquement protégé pour la preuve de consentement.
**En une phrase :** trois exigences réglementaires couvertes en un seul plugin — Consent Mode v2 (mars 2024), équivalence Accepter/Refuser (CNIL 2020), preuve de consentement (RGPD).
## Pré-requis et compatibilité
- **Shopware 6.6.x ou 6.7.x** (composer constraint `~6.6.0||~6.7.0`)
- **PHP 8.2 ou supérieur**
- Installation auto-hébergée (le plugin ne fonctionne **pas** sur Shopware Cloud SaaS)
- HTTPS recommandé en production (le flag cookie Secure n'est ajouté qu'en HTTPS)
- Cloudflare recommandé pour la détection EEE optimale (CF-IPCountry), mais non obligatoire
## Installation
### Installation par upload de ZIP (recommandé)
1. Téléchargez le fichier `DataFireflyCookieConsent-1.0.1.zip` depuis votre compte client DataFirefly
2. Dans l'admin Shopware, allez dans **Extensions → Mes extensions → Uploader une extension**
3. Sélectionnez le fichier ZIP et validez
4. Cliquez sur **Installer** puis **Activer**
5. Vider le cache : `bin/console cache:clear`
6. Recompiler le thème : `bin/console theme:compile`
### Installation par Composer (CLI)
```
cd /var/www/shopware
# Décompresser le ZIP dans custom/plugins/
unzip DataFireflyCookieConsent-1.0.1.zip -d custom/plugins/
# Rafraîchir la liste, installer, activer
bin/console plugin:refresh
bin/console plugin:install --activate DataFireflyCookieConsent
bin/console cache:clear
bin/console theme:compile
```
**Bon à savoir :** le JavaScript du plugin est livré pré-compilé dans `Resources/app/storefront/dist/`. Vous n'avez **pas besoin** d'exécuter `build-storefront.sh` pour que le bandeau fonctionne.
## Configuration générale
Toute la configuration se fait depuis **Extensions → Mes extensions → DataFirefly Cookie Consent → ⋮ → Configurer**. Les options sont scopables par sales channel (sélectionnez le canal en haut de la page de config).
### Section Général
- **Enabled** : active ou désactive complètement le plugin (le bandeau natif Shopware reprend la main si désactivé)
- **Policy version** : version de votre politique de confidentialité (par défaut `1.0`). Incrémentez-la quand vous changez votre politique pour forcer un nouveau consentement
- **Policy URL** : URL vers votre page de politique de confidentialité (affichée comme lien dans le bandeau)
- **Respect Do Not Track** : si activé, refuse automatiquement les cookies pour les visiteurs ayant DNT activé dans leur navigateur
### Section Bandeau
- **Layout** : `bar` (barre pleine largeur), `card` (carte d'angle discrète) ou `modal` (modale centrée bloquante)
- **Position** : `bottom` ou `top`
- **Theme** : `light`, `dark` ou `auto` (suit prefers-color-scheme)
- **Accent color** : couleur d'accent personnalisable via color picker (par défaut `#3b82f6`)
- **Show floating button** : affiche le bouton flottant persistant en bas à gauche pour rouvrir les préférences
### Section Catégories
Activez ou désactivez individuellement les 3 catégories optionnelles. La catégorie _Strictement nécessaires_ est toujours active.
- **Functional enabled** : cookies de personnalisation, préférences utilisateur
- **Analytics enabled** : Google Analytics 4, Matomo, mesure d'audience
- **Marketing enabled** : tracking publicitaire, retargeting
## Google Consent Mode v2
Le plugin imprime automatiquement le bloc `gtag('consent', 'default', ...)` en priorité 1 dans le head du storefront, avec les 7 signaux requis depuis mars 2024 : `ad_storage`, `ad_user_data`, `ad_personalization`, `analytics_storage`, `functionality_storage`, `personalization_storage`, `security_storage`.
### Section Consent Mode
- **GTM Container ID** : votre ID GTM (`GTM-XXXXXXX`). Si renseigné, le plugin charge automatiquement GTM **après** le bloc default. Laissez vide pour ne pas charger GTM
- **GA4 Measurement ID** : votre ID GA4 (`G-XXXXXXXXXX`). Si renseigné et GTM vide, le plugin charge GA4 en standalone. Laissez vide si vous chargez GA4 via GTM
- **URL passthrough** : préserve les paramètres URL pour les conversions Ads quand le consentement est refusé (recommandé)
- **Ads data redaction** : anonymise les données ads quand le consentement est refusé (recommandé)
- **Wait for update (ms)** : délai d'attente avant le premier ping GA4/Ads, le temps que le visiteur réponde au bandeau. Par défaut `500` ms
**Ordre d'exécution dans le head :** 1) bloc `gtag consent default` avec tous les signaux à `denied` — 2) loader GTM si configuré — 3) loader GA4 si configuré (et GTM vide) — 4) chargement de la bannière et signaux mis à jour via `gtag consent update` dès le clic visiteur.
### Mapping catégories → signaux
Quand le visiteur clique sur un bouton, les catégories sélectionnées sont automatiquement mappées vers les signaux Consent Mode v2 :
- **Functional** → `functionality_storage`, `personalization_storage`
- **Analytics** → `analytics_storage`
- **Marketing** → `ad_storage`, `ad_user_data`, `ad_personalization`
- **Necessary** → `security_storage` (toujours granted)
## Détection EEE et mode eeaOnly
Le plugin détecte automatiquement le pays du visiteur pour déterminer s'il est concerné par le RGPD (31 pays UE/EEE + Royaume-Uni + Suisse).
### Section EEE
- **EEA only mode** : si activé, le bandeau ne s'affiche qu'aux visiteurs détectés comme étant dans l'EEE. Les autres visiteurs reçoivent un consentement implicite et ne voient rien
- **Cloudflare support** : si activé (true par défaut), lit en priorité les en-têtes `CF-IPCountry` et `CF-Connecting-IP` ajoutés par Cloudflare
**Avec Cloudflare :** la détection est instantanée et fiable, l'en-tête `CF-IPCountry` est ajouté gratuitement sur chaque requête. **Sans Cloudflare :** fallback sur `Accept-Language` pour deviner le pays à partir de la locale du navigateur (moins fiable mais fonctionnel).
## Audit des trackers
Depuis le module admin (**Marketing → DataFirefly Cookie Consent → Audit**), lancez un audit de votre URL pour détecter les trackers réellement présents et obtenir un score de conformité 0-100.
### Comment lancer un audit
1. Allez dans **Marketing → DataFirefly Cookie Consent → Audit**
2. Renseignez l'URL à auditer (par défaut votre URL de boutique courante)
3. Cliquez sur **Lancer l'audit**
4. Le résultat s'affiche en quelques secondes : score visuel (anneau conique), trackers détectés, plugins à risque, issues classées critical/warning/info
### Ce qui est détecté
- **23 trackers JavaScript** : Google Analytics 4, Google Tag Manager, Meta Pixel, TikTok Pixel, LinkedIn Insight Tag, Pinterest Tag, Snapchat Pixel, Twitter X Pixel, Bing UET, Matomo, Microsoft Clarity, Hotjar, Mixpanel, Plausible, HubSpot, Intercom, Crisp, Tawk, YouTube embed, Vimeo embed, Stripe Elements et plus
- **11 plugins Shopware à risque** : interrogation de la base pour détecter les plugins serveur connus pour déposer des cookies non-conformes
### Interprétation du score
- **90-100** : excellent, conformité optimale
- **70-89** : bon, quelques ajustements mineurs à faire
- **50-69** : moyen, des issues critical à traiter
- **0-49** : non-conforme, action urgente requise
## Journal d'audit et exports
Chaque événement de consentement (accept_all, reject_all, custom, withdraw) est journalisé dans la table `dfcc_consent_log` avec horodatage milliseconde, sales channel, langue, version politique, snapshot des catégories et signaux Consent Mode v2, IP doublement protégée et user agent.
### Protection de l'IP visiteur
Double protection unique :
- **Hash SHA-256** avec un sel aléatoire de 64 caractères généré à l'installation et jamais exposé. Mathématiquement non inversible.
- **Version tronquée** en parallèle : IPv4 → dernier octet à zéro (réseau classe C), IPv6 → préfixe 64 bits. Permet l'analyse géographique sans réidentification.
### Consulter le journal
1. Allez dans **Marketing → DataFirefly Cookie Consent → Journal**
2. Filtrez par type d'événement et plage de dates si nécessaire
3. Le tableau pagine 50 entrées par page
### Exporter pour preuve CNIL
Depuis la page Journal, cliquez sur **Export CSV** ou **Export JSON** : le fichier téléchargé contient toutes les entrées correspondant aux filtres actifs.
- **CSV** : BOM UTF-8 + séparateur point-virgule (directement ouvrable dans Excel français/italien)
- **JSON** : pretty (indenté) avec unicode préservé
### Section Journal
- **Retention days** : durée de conservation en jours (1825 par défaut = 5 ans, recommandation CNIL)
- Une tâche planifiée Shopware purge automatiquement chaque nuit les entrées plus anciennes
## API JavaScript publique
Le plugin expose une API globale `window.dfcc` utilisable depuis n'importe quel code JavaScript de votre site.
```
// Ouvrir le bandeau et la modale de préférences
window.dfcc.open();
// Accepter / refuser tout par code
window.dfcc.acceptAll();
window.dfcc.rejectAll();
// Retirer le consentement (efface cookie + localStorage)
window.dfcc.withdraw();
// Récupérer l'état actuel
const cats = window.dfcc.getConsent();
// → { necessary: true, functional: false, analytics: true, marketing: false }
// ou null si aucun consentement encore donné
// Vérifier le consentement pour une catégorie
if (window.dfcc.hasConsent('analytics')) {
// charger ton script analytics
}
// Diagnostiquer l'état du storage (debug)
console.log(window.dfcc.debug());
// → { cookieRaw, localStorageRaw, parsed, policyVersion, protocol, domain }
// Version du plugin
console.log(window.dfcc.version);
// → "1.0.1"
```
## Événements DOM
Le plugin émet deux événements personnalisés sur `window` :
```
// Émis dès que le plugin est initialisé sur la page
window.addEventListener('dfcc:ready', (event) => {
console.log('DFCC ready', event.detail.config);
});
// Émis à chaque changement de consentement (accept, reject, custom, withdraw)
window.addEventListener('dfcc:consent', (event) => {
const { categories, eventType, consentMode } = event.detail;
console.log('Consent changed:', eventType, categories);
// Charger un script tiers si la catégorie marketing est acceptée
if (categories.marketing) {
loadMyMarketingScript();
}
});
```
## Multi-canal (sales channels)
Toute la configuration est scopable par sales channel. Pour configurer un canal spécifique différemment des autres :
1. Allez dans **Extensions → Mes extensions → DataFirefly Cookie Consent → Configurer**
2. En haut de la page, sélectionnez le sales channel à configurer
3. Modifiez les options : seules les options modifiées dans cette vue override la config par défaut
## Personnalisation avancée
### Wording du bandeau
Le texte du bandeau utilise les snippets storefront standard de Shopware. Pour personnaliser un texte, créez votre propre plugin de snippets et override les clés `dfcc.banner.*` et `dfcc.modal.*` :
```
{
"dfcc": {
"banner": {
"title": "Votre titre personnalisé",
"body": "Votre description personnalisée."
}
}
}
```
### Style CSS
Tous les éléments du bandeau utilisent des classes CSS préfixées `.dfcc-` (par exemple `.dfcc-banner`, `.dfcc-modal`, `.dfcc-button--primary`). Surchargez-les depuis votre thème ou via le plugin _Custom Code Manager DataFirefly_.
## Dépannage
### Le bandeau ne s'affiche pas
- Vérifiez que **Enabled** est bien coché dans la config plugin
- Vérifiez que le mode **EEA only** n'est pas activé alors que vous testez depuis hors EEE
- Vérifiez en console DevTools : `window.dfcc` doit être défini. Si non, le JS n'est pas chargé → relancer `bin/console theme:compile`
- Videz les cookies du domaine dans DevTools → Application → Cookies → Clear all, puis rechargez
### Le bandeau revient après chaque page (bug v1.0.0 corrigé en v1.0.1)
1. Mettez à jour en v1.0.1 si ce n'est déjà fait
2. Lancez `window.dfcc.debug()` en console pour diagnostiquer
3. Si `cookieRaw` est vide mais `localStorageRaw` est rempli : votre navigateur bloque l'écriture cookie (vérifiez le protocole HTTPS et les flags Secure/SameSite)
4. Si les deux sont vides mais qu'un consentement a bien été cliqué : ouvrir un ticket support avec le résultat de `debug()`
### Conversions Google Ads non remontées
- Vérifiez que **GTM Container ID** ou **GA4 Measurement ID** est bien renseigné
- Vérifiez en DevTools → Network : le bloc `gtag consent default` doit s'exécuter **avant** le chargement de GTM/GA4
- Activez **url_passthrough** et **ads_data_redaction** pour préserver les conversions des visiteurs ayant refusé
- Vérifiez dans GA4 → Admin → Data collection → Consent Mode que les paramètres sont reconnus
### Les exports CSV s'ouvrent mal dans Excel
Le fichier est généré avec BOM UTF-8 et séparateur point-virgule (standard Excel français). Si votre Excel attend une virgule (versions anglaises), utilisez l'export JSON à la place, ou importez via **Données → À partir d'un fichier CSV** et précisez le séparateur.
## Désinstallation
Pour désactiver temporairement :
```
bin/console plugin:deactivate DataFireflyCookieConsent
```
Les données restent en base, le bandeau natif Shopware reprend la main.
Pour désinstaller complètement :
```
bin/console plugin:uninstall --keep-user-data DataFireflyCookieConsent
# ou pour supprimer aussi la table dfcc_consent_log et la config :
bin/console plugin:uninstall DataFireflyCookieConsent
```
**Attention :** sans le flag `--keep-user-data`, le journal d'audit (dfcc_consent_log) est perdu. Si vous prévoyez de réinstaller plus tard, utilisez toujours `--keep-user-data`.
## Changelog
### 1.0.1 — 23 mai 2026 (patch persistance)
- Réécriture complète de la couche storage côté JavaScript
- Écriture cookie directe avec Max-Age et Expires combinés
- Flag Secure ajouté uniquement si HTTPS
- Fallback automatique localStorage si l'écriture cookie échoue
- Self-check write→read avec log console en cas de désynchro
- Nouvelle méthode `window.dfcc.debug()`
### 1.0.0 — 23 mai 2026 (release initiale)
- Compatibilité Shopware 6.6 et 6.7
- Bandeau v3 avec 3 layouts, 2 positions, 3 thèmes
- Google Consent Mode v2 natif avec les 7 signaux
- Audit réel des trackers (23 trackers + 11 plugins à risque)
- Journal d'audit avec IP doublement protégée (SHA-256 + truncate)
- Détection EEE intelligente (31 pays + UK + CH, support Cloudflare)
- Module Admin Vue 3 (mt-*) : dashboard, audit, journal
- Exports CSV et JSON
- Snippets storefront et admin pour 5 langues
---
### DataFirefly Digital Product Passport — Documentation
_Source :_
> Introduction Le plugin DataFirefly Digital Product Passport ajoute à WooCommerce tout ce qu'il faut pour générer un Passeport Numérique Produit (DPP) conforme au Règlement européen Écoconception pour des produits durables…
## Introduction
Le plugin **DataFirefly Digital Product Passport** ajoute à WooCommerce tout ce qu'il faut pour générer un **Passeport Numérique Produit (DPP)** conforme au Règlement européen Écoconception pour des produits durables (**ESPR**). Ce passeport devient progressivement obligatoire dans l'Union européenne à partir de 2027, en commençant par le textile, les batteries et l'électronique grand public, avant de s'étendre à la quasi-totalité des produits mis sur le marché européen.
Concrètement, chaque produit WooCommerce gagne un identifiant unique stable (UUID v4), un QR code natif, une URL publique propre du type `/dpp/{uuid}`, un registre complet des composants et matériaux, une timeline de traçabilité, et une API REST publique. Aucun appel externe : tout est généré côté serveur.
**À qui ça s'adresse ?**
Toute boutique WooCommerce vendant en UE : textile, mode, batteries, électronique, ameublement, matériaux de construction, cosmétiques, jouets, détergents, lubrifiants ou peintures. Si tu ne fais pas partie des premières vagues, tu as tout intérêt à structurer tes données dès maintenant.
## Prérequis
- WordPress 6.0 ou supérieur
- WooCommerce 7.0 ou supérieur, activé
- PHP 7.4 minimum (testé jusqu'à PHP 8.3)
- Un permalien autre que « Simple » (Réglages → Permaliens)
## Installation
1. Télécharge le ZIP `dfdpp-1.0.0.zip` depuis ton compte DataFirefly.
2. Va dans **Extensions → Ajouter → Téléverser une extension**, sélectionne le ZIP, puis **Installer maintenant**.
3. Clique sur **Activer**. Les 5 tables custom sont créées automatiquement (`wp_dfdpp_passports`, `wp_dfdpp_components`, `wp_dfdpp_materials`, `wp_dfdpp_suppliers`, `wp_dfdpp_events`) et les options par défaut sont posées.
4. Si l'URL publique `/dpp/{uuid}` ne répond pas immédiatement, va dans **Réglages → Permaliens** et clique sur **Enregistrer les modifications** (sans rien changer) pour forcer le flush.
## Configuration globale
Rends-toi dans **WooCommerce → Passeport DPP**. Cet écran regroupe tous les réglages du plugin.
### URL publique et QR Code
- **Préfixe d'URL** : par défaut `dpp`, ce qui donne `tondomaine.com/dpp/{uuid}`. Change-le si tu préfères `passeport`, `product-passport` ou autre. Pense à visiter Réglages → Permaliens après modification.
- **Taille du QR** : facteur de zoom de 1 à 10. La valeur 6 (par défaut) produit environ 240 px de côté.
- **Marge** : nombre de modules blancs autour du QR (4 par défaut).
- **Correction d'erreur** : L / M / Q / H. Reste sur **H** si le QR sera imprimé sur étiquette : jusqu'à 30 % du code peut être abîmé sans compromettre la lecture.
- **Format préféré** : PNG (raster, universel) ou SVG (vectoriel, meilleur pour l'impression grand format).
### Identité fabricant par défaut
Renseigne ici les informations que tu ne veux pas retaper produit par produit :
- Raison sociale, adresse, pays de fabrication
- Pays par défaut appliqué aux composants et matériaux
- Catégorie ESPR par défaut (textile, batterie, électronique, ameublement, etc.)
### Affichage public
Cinq bascules indépendantes contrôlent ce que tes clients voient sur la page publique du passeport :
- Empreinte carbone (activée par défaut)
- Fournisseurs (**désactivée par défaut** — données sensibles)
- Composition matière (activée)
- Réparabilité et pièces détachées (activée)
- Timeline de traçabilité (activée)
Tu peux activer les fournisseurs pour renforcer ton discours transparence radicale, mais valide-le au préalable avec tes acheteurs et tes juristes : c'est une information contractuellement sensible.
### Publication automatique
Si tu coches cette option, chaque passeport passe automatiquement en _published_ lorsque le produit WooCommerce lui-même est publié. Utile pour un catalogue de plusieurs centaines de produits gérés par une équipe non technique. Sinon, chaque passeport doit être publié manuellement — ce qui garantit un contrôle final.
### Branding
- **Couleur d'accent** : format hexadécimal (ex. `#0f172a`). Elle s'applique au hero, aux titres et aux boutons de la page publique.
- **URL du logo** : affiché en haut de la page publique. Utilise une image transparente (PNG ou SVG) — elle sera inversée sur fond sombre.
## Créer un passeport pour un produit
Ouvre n'importe quel produit dans WooCommerce. Un nouvel onglet **Passeport DPP** apparaît dans le panneau de données produit (à côté de Général, Inventaire, Livraison, etc.). Il regroupe 8 sections.
### Onglet Identification
Le point d'entrée obligatoire pour publier :
- **Statut** : Brouillon / Publié / Archivé. Seul _Publié_ rend l'URL publique accessible.
- **Catégorie ESPR** : détermine la structure de données que les auditeurs européens s'attendent à trouver. Choisis _textile_, _battery_, _electronics_, _furniture_, _iron_steel_, _aluminium_, _tyres_, _detergents_, _paints_, _lubricants_, _chemicals_, _cosmetics_, _toys_, _construction_ ou _general_.
- **GTIN / EAN / UPC** : le code-barres commercial international.
- **Référence modèle**, **Numéro de lot**, **Numéro de série** : renseigne les champs applicables à ton produit.
- **Fabricant** : nom, adresse, pays (préremplis depuis les réglages globaux si tu les as configurés).
- **Date de fabrication** et **Site de fabrication** (ville, usine ou atelier).
### Onglet Durabilité et empreinte
- **Empreinte carbone** : valeur numérique, unité (kgCO2e par défaut) et méthodologie de calcul de référence (_PEF_, _ISO 14067_, _GHG Protocol_). Ne renseigne l'empreinte que si tu peux la justifier avec une méthodologie documentée — c'est le point le plus scruté par les audits.
- **Indice de réparabilité** : note sur 10.
- **Durée de vie prévue** en années.
- **Durée de garantie** en mois (obligation d'au moins 24 mois en UE pour les biens de consommation).
- **Disponibilité pièces détachées** en années.
- **Contenu recyclé** en pourcentage.
- **Contenu recyclable** en pourcentage.
### Onglet Instructions
Quatre champs riches acceptant du HTML basique (paragraphes, listes, liens) :
- **Utilisation** : conseils pour tirer le meilleur parti du produit et allonger sa durée de vie.
- **Entretien** : lavage, séchage, stockage.
- **Recyclage** : filière de recyclage, tri sélectif, points de collecte.
- **Fin de vie** : que faire quand le produit n'est plus utilisable.
### Onglet Conformité
- **Substances préoccupantes (SCIP / REACH)** : liste des substances de la liste candidate REACH présentes à plus de 0,1 % en poids. Format libre, on recommande une liste à puces avec le nom et le numéro CAS.
- **Matières dangereuses** : mention des classes de danger applicables (CLP, GHS).
- **Certifications et labels** : OEKO-TEX, GOTS, GRS, Ecolabel, EPEAT, etc.
### Onglet Composants
Registre à plat des composants qui constituent le produit. Pour chaque composant, tu ajoutes :
- Nom (obligatoire)
- Type : parmi une liste prédéfinie (tissu principal, doublure, semelle, boucle, fermeture, etc.)
- Poids en grammes
- Nom du fournisseur (jamais exposé publiquement sauf si tu actives la bascule dédiée)
- Pays d'origine sur 3 caractères ISO 3166 alpha-3 (ex. `FRA`, `ITA`, `CHN`)
- Recyclable : oui / non
- Remplaçable : oui / non (pertinent pour l'électronique, l'ameublement)
Les composants sont sauvegardés en AJAX : chaque ajout ou suppression est immédiat, sans recharger la page. Le produit doit exister (au moins en brouillon) pour que le passeport puisse recevoir des composants.
### Onglet Matériaux
Registre matière plus granulaire, avec les codes normalisés :
- **Code matériau** : liste déroulante avec les principaux codes ISO 11469 / ISO 1043 pour les plastiques (`PET`, `PP`, `PE`, `PVC`, `PS`, `PA`, etc.), ISO 1833 pour les textiles (`WO` laine, `CO` coton, `PL` polyester, `VI` viscose, `EL` élasthanne, etc.), DIN 6120 pour les métaux, et les chimies batteries (`Li-ion`, `LFP`, `NMC`, `NCA`, `NiMH`, `Pb`).
- **Nom personnalisé** : si le code prédéfini ne convient pas.
- **Pourcentage** : part de ce matériau dans le produit (jusqu'à 4 décimales).
- **Recyclé** + **% recyclé** : est-ce qu'il s'agit d'un contenu recyclé, et si oui à quelle proportion.
- **Renouvelable** : matière d'origine biologique renouvelable.
- **N° CAS** : identifiant CAS de la substance (pour les substances chimiques régulées).
### Onglet Traçabilité
Timeline des événements-clés du cycle de vie. Chaque événement associe une date, un type, un acteur, un lieu et une description. Les types disponibles couvrent tout le cycle :
- Production
- Contrôle qualité
- Transport
- Import / Export
- Distribution
- Vente
- Réparation
- Reconditionnement
- Recyclage
- Fin de vie
Le minimum syndical pour un audit ESPR : une production initiale et une vente. Idéalement tu documentes aussi les étapes de contrôle qualité et de distribution. Les événements post-vente (réparation, recyclage) peuvent être ajoutés au fil de l'eau via l'API REST par un partenaire externe.
### Onglet QR Code
Cet onglet devient actif dès que le produit est enregistré une première fois. Il affiche :
- Le QR code généré (aperçu en data-URI)
- L'UUID du passeport
- L'URL publique cliquable
- Trois boutons de téléchargement : PNG, SVG et JSON brut
## Publier un passeport
Un passeport en statut _Brouillon_ n'est pas accessible publiquement — l'URL renvoie une 404. Pour le publier :
1. Ouvre le produit, va sur l'onglet **Passeport DPP → Identification**.
2. Passe **Statut** sur _Publié_.
3. Clique sur **Mettre à jour** en haut à droite du produit.
La date de première publication est mémorisée automatiquement dans `published_at`. Un passeport publié peut être remis en Brouillon ou passé en Archivé à tout moment.
## Page publique du passeport
L'URL de la forme `tondomaine.com/dpp/8f3a2c1d-4b5e-6f7a-8b9c-0d1e2f3a4b5c` ouvre une page responsive avec :
- Un **hero** avec le nom du produit, la catégorie ESPR, le logo de marque et l'image du produit
- Un bandeau **identifiants** (UUID, GTIN, modèle, lot, série, SKU)
- Une carte **fabricant** avec adresse et date de production
- Une carte **durabilité et empreinte** avec les métriques sous forme de tuiles
- Les tables **composants** et **matériaux** (selon les bascules d'affichage)
- Les **instructions** (utilisation, entretien, recyclage, fin de vie)
- La **conformité réglementaire** (certifications, substances, matières dangereuses)
- Une **timeline de traçabilité** verticale avec dates et lieux
- Une **sidebar QR code** avec téléchargement PNG / SVG / JSON
- Un bloc **JSON-LD schema.org Product** automatiquement injecté pour le SEO et l'interopérabilité
Sur la fiche produit publique WooCommerce, un bloc discret invite les visiteurs à consulter le passeport, avec un QR miniature. Ce bloc est ajouté automatiquement au-dessous du résumé produit (hook `woocommerce_after_single_product_summary`, priorité 25).
### Formats alternatifs
La même URL accepte deux suffixes :
- `/dpp/{uuid}?dfdpp_format=json` ou `/dpp/{uuid}.json` : retourne le payload JSON complet, y compris le bloc JSON-LD.
- `/dpp/{uuid}?dfdpp_format=qr` ou `/dpp/{uuid}/qr` : télécharge directement le QR code PNG.
## API REST
Tous les endpoints sont exposés sous le namespace `dfdpp/v1`.
### Endpoints publics
- `GET /wp-json/dfdpp/v1/passport/{uuid}` — retourne le payload JSON complet du passeport.
- `GET /wp-json/dfdpp/v1/passport/by-product/{product_id}` — même chose mais recherché par identifiant produit WooCommerce.
- `GET /wp-json/dfdpp/v1/passport/{uuid}/qr` — retourne le QR code en SVG vectoriel.
Ces endpoints ne renvoient que les passeports en statut _Publié_.
### Endpoints authentifiés
Nécessitent une authentification Application Password ou OAuth et une capability `manage_woocommerce` ou `edit_products` :
- `PATCH /wp-json/dfdpp/v1/passport/{product_id}` — met à jour partiellement les champs d'un passeport.
- `POST /wp-json/dfdpp/v1/passport/{product_id}/publish` — publie le passeport (raccourci sans avoir à passer par l'admin).
L'API REST est le canal idéal pour synchroniser tes passeports depuis un PIM, un ERP ou une chaîne de production automatisée. Elle permet aussi à un partenaire externe (atelier de réparation, filière de recyclage) d'ajouter des événements de traçabilité au fil du cycle de vie du produit.
## Personnalisation
### Surcharger la page publique
Copie `public/templates/dpp-public.php` depuis le plugin vers un dossier `dfdpp/` à la racine de ton thème actif. Le plugin utilisera prioritairement ce fichier, ce qui te permet de refondre entièrement le rendu sans toucher au plugin. La logique de récupération des données reste inchangée : tu disposes des variables `$passport` et `$data` exactement comme dans le template original.
### Filtre du payload JSON
Le filtre `dfdpp_passport_payload` te permet d'ajouter ou modifier des champs dans la charge JSON exposée. Exemple : ajouter un champ propriétaire _internal_reference_ visible uniquement pour ton ERP.
```
add_filter( 'dfdpp_passport_payload', function ( $data, $passport ) {
$data['custom'] = array(
'internal_reference' => get_post_meta( $passport->product_id, '_erp_ref', true ),
);
return $data;
}, 10, 2 );
```
### Bloc sur la fiche produit
Le bloc invitant à consulter le passeport sur la fiche produit publique WooCommerce peut être déplacé, désactivé ou remplacé en manipulant le hook :
```
// Le retirer complètement
remove_action( 'woocommerce_after_single_product_summary', array( dfdpp()->frontend, 'render_product_dpp_link' ), 25 );
// Le placer ailleurs, par exemple au-dessus du bouton Ajouter au panier
add_action( 'woocommerce_single_product_summary', array( dfdpp()->frontend, 'render_product_dpp_link' ), 25 );
```
## Traductions
Le plugin est livré avec une traduction française complète (`languages/dfdpp-fr_FR.po` et `.mo`) et un fichier template `dfdpp.pot` (291 chaînes uniques) pour traduire vers d'autres langues avec Poedit ou tout outil compatible gettext.
Polylang Pro et WPML sont supportés pour la traduction des contenus produit (nom, description, catégorie ESPR). Le passeport reste attaché au produit source, ce qui garantit une seule source de vérité pour les données de conformité tout en permettant un affichage multilingue de la page publique.
## Compatibilité HPOS
Le plugin déclare explicitement sa compatibilité avec le stockage haute performance des commandes WooCommerce (_High-Performance Order Storage_). Il ne stocke aucune donnée dans le custom post type `shop_order` — les 5 tables dédiées sont indépendantes. Tu peux activer HPOS sans crainte de rupture avec le plugin.
## FAQ et dépannage
### L'URL publique renvoie une 404
Trois causes possibles :
- Le passeport est en statut Brouillon ou Archivé — passe-le en Publié.
- Les rewrite rules n'ont pas été flushées — va dans Réglages → Permaliens et enregistre (sans rien changer).
- Un permalien « Simple » est actif — passe à « Titre de la publication » ou tout autre format non simple.
### Le QR code ne s'affiche pas
Vérifie que ton hébergeur autorise l'écriture du répertoire `wp-content/uploads/` et que l'extension GD est activée dans PHP (nécessaire pour la génération PNG). Si tu es en environnement contraint, force le format SVG dans les réglages : il ne dépend pas de GD.
### Comment fournir la traçabilité à un partenaire externe ?
Utilise l'API REST. Crée un Application Password dédié au partenaire dans son compte utilisateur WordPress (Utilisateurs → Profil → Application Passwords), puis fournis-lui la documentation d'un endpoint `PATCH` pour qu'il pousse ses propres événements de traçabilité au fil de l'eau.
### Puis-je générer les QR codes en masse ?
Oui, via WP-CLI. Un script personnalisé peut boucler sur les produits et appeler `DFDPP_QRCode::output_png()` ou `::as_svg()` pour générer les fichiers. Contacte le support si tu veux qu'on te fournisse un WP-CLI command clef en main pour ton catalogue.
### Est-ce que ça marche avec les produits variables ?
Oui, le passeport est attaché au produit parent. Si tu as besoin d'un passeport distinct par variation (typique pour l'électronique où chaque configuration a une empreinte carbone différente), contacte-nous pour discuter d'une extension.
## Désinstallation
La **désactivation** simple du plugin conserve toutes les données. Tes passeports restent en base, prêts à être réactivés.
La **désinstallation complète** (bouton Supprimer sur la page des extensions) déclenche `uninstall.php`, qui :
- Supprime les 5 tables custom
- Supprime toutes les options `dfdpp_*`
- Nettoie les transients éventuels
- Flushe les rewrite rules
La désinstallation est irréversible : sauvegarde ta base ou fais un export JSON de tes passeports (via l'API REST) avant de désinstaller si tu souhaites récupérer les données plus tard.
## Support
Le support technique est assuré par e-mail en français et en anglais. Écris à [support@datafirefly.com](mailto:support@datafirefly.com) en précisant la version du plugin, la version de WordPress et WooCommerce, ainsi qu'un extrait des logs si tu as un message d'erreur PHP.
---
### DataFirefly Dunning — Documentation
_Source :_
> Présentation DataFirefly Dunning automatise le recouvrement amiable des commandes B2B payées par virement et restées impayées. Dès la validation d'une commande éligible, le module ouvre une créance, suit son échéance,…
## Présentation
DataFirefly Dunning automatise le recouvrement amiable des commandes B2B payées par virement et restées impayées. Dès la validation d'une commande éligible, le module ouvre une créance, suit son échéance, déclenche des relances graduées selon un calendrier que vous définissez et calcule les pénalités de retard ainsi que l'indemnité forfaitaire de recouvrement de 40 € prévues par le Code de commerce.
Trois niveaux de relance sont fournis à l'installation (relance courtoise, relance ferme avec pénalités et PDF, mise en demeure) et restent entièrement paramétrables. Un tableau de bord dédié centralise l'encours, la balance âgée et le suivi des envois.
## Installation
1. Déposez le dossier `dfdunning` dans le répertoire `/modules/` de votre boutique, ou installez l'archive ZIP depuis **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer**. Le module crée ses tables, ses trois niveaux de relance par défaut, sa configuration initiale, un jeton de sécurité pour le cron et l'onglet d'administration sous **Commandes > Relances impayés (DF Dunning)**.
3. Videz le cache PrestaShop si nécessaire depuis **Paramètres avancés > Performances**.
## Configuration
La configuration est accessible depuis **Modules > Gestionnaire de modules > dfdunning > Configurer**. Les principaux réglages sont :
- **Modules de paiement suivis** : les modules dont les commandes ouvrent une créance. Par défaut, le virement bancaire (`ps_wirepayment`).
- **États de commande suivis** : les états considérés comme « en attente de paiement ». Par défaut, l'état Paiement par virement en attente.
- **Délai de paiement** : nombre de jours accordés avant échéance. Par défaut 30 jours.
- **Taux des pénalités de retard** : taux annuel appliqué. Par défaut 12,15 % (taux directeur de la BCE majoré de 10 points).
- **Indemnité forfaitaire** : montant fixe par facture en retard. Par défaut 40 €.
- **Intervalle minimum entre deux relances** : garde-fou anti-spam, par défaut 3 jours.
- **Envoi automatique** : active l'envoi des relances lors du passage du cron.
- **Copie cachée (BCC)** : adresse recevant une copie de chaque relance, pour la trace comptable.
Le taux par défaut correspond au taux de refinancement de la BCE majoré de 10 points. Ce taux évolue : pensez à le réviser chaque semestre (janvier et juillet) dans la configuration.
## Les trois niveaux de relance
Un niveau de relance définit quand et comment un client est relancé. Chaque niveau se paramètre depuis la configuration : position dans la séquence, délai de déclenchement (en jours après l'échéance), modèle d'e-mail, ajout ou non des pénalités, pièce jointe PDF, et activation.
### Niveau 1 — Relance courtoise (J+7)
Un rappel simple, sans pénalités ni pièce jointe, envoyé 7 jours après l'échéance. Objectif : signaler l'oubli sans dégrader la relation commerciale.
### Niveau 2 — Relance ferme (J+15)
Une relance plus ferme, avec le détail des pénalités de retard et l'indemnité forfaitaire, accompagnée d'une lettre PDF. Envoyée 15 jours après l'échéance.
### Niveau 3 — Mise en demeure (J+30)
Une mise en demeure formelle rappelant les sommes dues, les pénalités et la référence à l'article 1231-6 du Code civil, avec lettre PDF et délai de règlement sous 8 jours. Envoyée 30 jours après l'échéance.
Les délais et le contenu de chaque niveau sont indicatifs : adaptez-les à votre politique de recouvrement et à vos conditions générales de vente.
## Calcul des pénalités
Pour chaque créance en retard, le module calcule :
- **Les intérêts de retard** : montant dû × (taux / 100) × (jours de retard / 365).
- **L'indemnité forfaitaire de recouvrement** : un montant fixe par facture (40 € par défaut), dû dès le premier jour de retard.
Le montant dû est déterminé à partir du total payé et du total réellement encaissé sur la commande, ce qui prend en charge les paiements partiels. La base légale est constituée des articles L441-10 et D441-5 du Code de commerce pour l'indemnité et les pénalités, et de l'article 1231-6 du Code civil pour la mise en demeure.
Les modèles de courrier reflètent le cadre légal français en vigueur. Faites-les valider par votre conseil juridique et adaptez-les à votre activité avant la phase de mise en demeure. DataFirefly ne fournit pas de conseil juridique.
## Automatisation par cron
La synchronisation des créances et l'envoi automatique des relances reposent sur un contrôleur front sécurisé par un jeton. L'URL complète, avec le jeton généré à l'installation, est affichée dans l'écran de configuration, prête à copier. Elle a la forme suivante :
```
https://votreboutique.tld/index.php?fc=module&module=dfdunning&controller=cron&token=VOTRE_TOKEN
```
Programmez un appel quotidien, par exemple à 7 h du matin, via la tâche planifiée (crontab) de votre serveur :
```
0 7 * * * curl -s "https://votreboutique.tld/index.php?fc=module&module=dfdunning&controller=cron&token=VOTRE_TOKEN"
```
À chaque passage, le module met à jour les créances (échéances, clôtures, exclusions) puis, si l'envoi automatique est activé, expédie les relances arrivées à échéance en respectant l'intervalle minimum configuré.
Le jeton protège l'accès au cron : sans lui, l'URL renvoie une erreur. Régénérez-le si vous pensez qu'il a été exposé.
## Tableau de bord des créances
Le tableau de bord, sous **Commandes > Relances impayés (DF Dunning)**, présente :
- **Six indicateurs clés** : encours total, montant échu, créances en retard, dossiers ouverts, pénalités théoriques et relances du mois.
- **Une balance âgée** répartissant l'encours par tranche : non échu, 1-30, 31-60, 61-90 et plus de 90 jours.
- **Une liste filtrable** des créances (ouvertes, en retard, payées, exclues), avec pour chaque ligne des actions : envoyer un niveau de relance au choix, marquer comme payé, exclure ou réinclure, télécharger la lettre PDF.
Un dossier se clôt automatiquement lorsque la commande passe à un état payé, et s'exclut si la commande est annulée, remboursée ou en erreur de paiement.
## Lettres PDF et e-mails
Les relances sont envoyées par e-mail (versions HTML et texte) et, selon le niveau, accompagnées d'une lettre PDF. Les courriers sont générés en français ou en anglais selon la langue de la commande. Les modèles utilisent des variables remplacées à l'envoi : prénom, nom, référence de commande, montant dû, date d'échéance, jours de retard, pénalités, indemnité forfaitaire, total dû, taux appliqué et nom de la boutique.
Les e-mails sont modifiables depuis **Design > Traductions > Traductions des e-mails**, langue par langue, comme tout e-mail PrestaShop.
## FAQ
### Quelles commandes sont relancées ?
Uniquement celles qui correspondent aux modules de paiement et aux états sélectionnés dans la configuration. Par défaut, les commandes payées par virement en attente de règlement.
### Une commande partiellement payée est-elle gérée ?
Oui. Le montant dû tient compte des sommes déjà encaissées ; seule la part restante est relancée, et le dossier se clôt lorsque le solde est réglé.
### Le module est-il compatible PrestaShop 9 et multiboutique ?
Oui. Les contrôleurs d'administration reposent sur ModuleAdminController pour la compatibilité PrestaShop 8 et 9, sans Composer, et le module gère le contexte multiboutique.
### Puis-je déclencher une relance manuellement ?
Oui. Depuis le tableau de bord, vous pouvez envoyer immédiatement le niveau de votre choix pour une créance donnée, indépendamment du cron.
---
### DataFirefly Factur-X SW — Facture électronique Shopware 6 : guide complet
_Source :_
> Présentation DfFacturX SW génère des factures électroniques conformes EN 16931 pour Shopware 6.5, 6.6 et 6.7. À chaque création d'un document de facture, le plugin construit un XML UN/CEFACT CII…
## Présentation
DfFacturX SW génère des factures électroniques conformes **EN 16931** pour Shopware 6.5, 6.6 et 6.7. À chaque création d'un document de facture, le plugin construit un XML UN/CEFACT CII et, selon le profil choisi, l'embarque dans le PDF de facture (Factur-X / ZUGFeRD) ou le fournit en fichier autonome (XRechnung 3.0 pour le B2G allemand).
- **Factur-X / ZUGFeRD EN 16931** — profil recommandé pour le B2B : le PDF téléchargé par le client est l'e-facture hybride.
- **Factur-X BASIC** — profil allégé, pour les destinataires qui n'exigent pas le jeu complet EN 16931.
- **XRechnung 3.0** — XML autonome en syntaxe CII pour facturer les administrations allemandes, avec Leitweg-ID obligatoire.
## Installation
1. Copiez le dossier du plugin dans `custom/plugins/DfFacturX` (ou uploadez le ZIP depuis l'admin, Extensions puis Mes extensions).
2. Exécutez :
```
bin/console plugin:refresh
bin/console plugin:install --activate DfFacturX
bin/console cache:clear
```
L'activation installe le jeu de champs personnalisés **Facture électronique (DfFacturX)** avec le champ `df_facturx_buyer_reference` sur le client et la commande. C'est là que se saisit le Leitweg-ID (BT-10).
## Configuration
Admin, Extensions, DfFacturX, Configuration. Tous les réglages sont scopés par canal de vente.
### Général
- **Activer la génération** — déclenche la création du XML à chaque nouveau document de facture.
- **Profil** — Factur-X EN 16931, Factur-X BASIC ou XRechnung 3.0.
- **Embarquer le XML dans le PDF** — pour les profils Factur-X ; le média du document est remplacé par le PDF hybride.
- **Joindre le XML aux e-mails** — ajoute `factur-x.xml` (ou `numéro-xrechnung.xml`) aux e-mails de commande.
- **B2B uniquement** — ne génère que si la commande porte une société ou un numéro de TVA.
### Vendeur
Raison sociale, rue, code postal, ville, pays (ISO-2), numéro de TVA (BT-31), numéro fiscal (BT-32), e-mail (BT-34), téléphone et personne de contact (BG-6). L'e-mail et le contact sont exigés par XRechnung.
Champs vendeur minimum : nom, rue, code postal, ville, pays, plus le numéro de TVA _ou_ le numéro fiscal (règle BR-CO-26). Sans eux, la génération échoue avec une erreur explicite dans les logs.
### Paiement
IBAN et BIC (virement SEPA, code 58), texte des conditions de paiement (BT-20) et délai d'échéance en jours (BT-9). Sans IBAN, le moyen de paiement est déclaré en code 1 (non défini).
### Gestion de la TVA
Pour les taux à 0 %, le mode **Automatique** applique : **K** livraison intracommunautaire (acheteur avec TVA dans un autre pays UE), **G** export hors UE, **Z** sinon. Vous pouvez forcer une catégorie fixe (Z, E, K, G) et personnaliser le motif d'exonération (BT-120).
### XRechnung
Nom technique du champ personnalisé contenant la référence acheteur (par défaut `df_facturx_buyer_reference`) et valeur de repli si aucun champ n'est renseigné.
## Leitweg-ID et référence acheteur (BT-10)
Saisissez le Leitweg-ID une fois sur la fiche client (onglet champs personnalisés) : il sera repris sur toutes ses factures. Pour un cas ponctuel, renseignez-le directement sur la commande — la valeur commande prime sur la valeur client, qui prime sur la valeur de repli.
En profil XRechnung, si aucune référence acheteur n'est trouvée, le plugin **refuse de générer** un XML invalide et journalise une erreur. Corrigez la donnée puis relancez avec `df:facturx:generate --force`.
## Fonctionnement
1. À la création du document de facture (admin, Flow Builder ou API), le plugin charge la commande dans sa version de commande exacte.
2. Le XML CII est construit puis stocké dans les champs personnalisés du document (`df_facturx_xml`, `df_facturx_profile`, `df_facturx_generated_at`).
3. En profil Factur-X, le XML est embarqué dans le PDF par mise à jour incrémentale : fichier `factur-x.xml` attaché, métadonnées XMP PDF A-3 et schéma d'extension Factur-X. Le média du document est remplacé en place.
4. Si l'option est active, le XML est joint aux e-mails de commande.
Avec le Flow Builder, ajoutez l'action de génération de facture à votre flow de commande : l'e-facture suit automatiquement, aucune action supplémentaire n'est requise.
Par conception, une erreur d'e-facture ne bloque jamais la création du document : l'incident est journalisé et la facture PDF classique reste disponible.
## Modèle comptable EN 16931
- **Modèle net** — les commandes TTC sont converties via les taxes calculées de Shopware.
- **Promotions** — converties en remises au niveau document (BG-20), une entrée par taux de TVA, car la norme interdit les lignes négatives (BR-27).
- **Frais de port** — déclarés en charges au niveau document (BG-21), une entrée par taux.
- **RoundingAmount (BT-114)** — absorbe toute dérive d'arrondi : le GrandTotal du XML est strictement égal au total de la commande Shopware.
- **Paiement SEPA** — virement code 58 avec IBAN/BIC, échéance calculée depuis la date de facture.
## Commande console
```
# Régénérer l'e-facture de la dernière facture d'une commande
bin/console df:facturx:generate 10042 --force
# Exporter le XML vers un fichier (pour un validateur)
bin/console df:facturx:generate 10042 --output=/tmp/10042.xml
# Forcer un profil ponctuellement (implique la régénération)
bin/console df:facturx:generate 10042 --profile=xrechnung-30
```
## Checklist de validation avant production
1. Créez des commandes de test couvrant vos cas réels : canal TTC et canal HT, promotion, frais de port, vente intracommunautaire avec numéro de TVA, export hors UE.
2. Générez la facture pour chacune, puis exportez le XML avec `--output`.
3. Validez : [validateur KOSIT](https://github.com/itplr-kosit/validator) pour XRechnung, [Mustang](https://www.mustangproject.org) pour Factur-X / ZUGFeRD.
4. Ouvrez le PDF hybride dans Adobe Acrobat et vérifiez la présence de la pièce jointe `factur-x.xml`.
## Dépannage
- **Aucun XML généré** — vérifiez que le plugin est activé pour le canal de vente, que le type de document est bien _facture_, et que le mode B2B uniquement ne filtre pas la commande. Consultez les logs (`var/log`).
- **Erreur « Missing seller configuration »** — complétez la carte Vendeur (champs minimum ci-dessus).
- **Avertissement « PDF embedding skipped »** — la structure du PDF n'a pas permis l'embedding ; le XML reste disponible en pièce jointe e-mail et via la console. Cas typique : PDF généré par un moteur tiers.
- **XRechnung refusé** — référence acheteur absente : renseignez le champ personnalisé ou la valeur de repli, puis `--force`.
- **Régénération après changement de configuration** — les documents déjà traités ne sont pas retraités automatiquement ; utilisez `df:facturx:generate --force`.
## Limites connues et feuille de route
- Version 1.0 : factures uniquement (code 380). Avoirs (381) et factures rectificatives (384) prévus en 1.1.
- La conformité stricte PDF/A-3B dépend aussi de propriétés du PDF source produit par le moteur dompdf de Shopware (polices embarquées, output intent). Les destinataires et outils comptables exploitent le XML embarqué dans tous les cas ; pour une exigence stricte PDF/A-3B, utilisez le profil XRechnung ou la pièce jointe XML.
- Une seule ligne de TVA par ligne de commande (comportement standard Shopware).
---
### DataFirefly FAQ IA Produit pour WooCommerce — Documentation
_Source :_
> DataFirefly FAQ IA Produit génère automatiquement des FAQ contextuelles pour vos fiches produits WooCommerce à l'aide d'OpenAI ou d'Anthropic Claude, et injecte les rich snippets Schema.org FAQPage dans la balise…
DataFirefly FAQ IA Produit génère automatiquement des FAQ contextuelles pour vos fiches produits WooCommerce à l'aide d'OpenAI ou d'Anthropic Claude, et injecte les rich snippets Schema.org FAQPage dans la balise head pour les résultats enrichis Google. Ce guide couvre l'installation, la configuration complète et l'utilisation au quotidien.
## Prérequis
- WordPress 6.0 ou supérieur (testé jusqu'à 6.6)
- WooCommerce 7.0 ou supérieur (testé jusqu'à 9.4), compatible HPOS
- PHP 7.4 à 8.3
- Une clé API OpenAI ([platform.openai.com/api-keys](https://platform.openai.com/api-keys)) ou Anthropic ([console.anthropic.com](https://console.anthropic.com/))
- Facultatif : Polylang ou WPML pour le multilingue
## Installation
1. Téléchargez le fichier `dffaqai-1.0.0.zip` depuis votre compte DataFirefly.
2. Dans l'admin WordPress : **Extensions → Ajouter → Téléverser une extension**, sélectionnez le ZIP puis cliquez sur **Installer maintenant**.
3. Cliquez sur **Activer**. Le plugin crée sa table de stockage des FAQ et ses réglages par défaut.
À l'activation, un menu **FAQ IA** apparaît dans la barre latérale de l'admin, avec deux entrées : _Réglages_ et _Génération en masse_.
## Configuration du fournisseur IA
Rendez-vous dans **FAQ IA → Réglages → onglet Fournisseur**.
### Choisir OpenAI ou Anthropic Claude
- **OpenAI** : collez votre clé API, puis choisissez un modèle — `gpt-4o-mini` (le plus économique, recommandé), `gpt-4o`, `gpt-4-turbo` ou `gpt-3.5-turbo`.
- **Anthropic Claude** : collez votre clé API, puis choisissez — `claude-haiku-4-5` (économique, recommandé), `claude-sonnet-4-6` ou `claude-opus-4-7`.
Le plugin route automatiquement vers la bonne API selon le fournisseur sélectionné. Vous pouvez basculer à tout moment : les FAQ déjà générées sont conservées.
### Paramètres de génération
- **Nombre de questions par produit** : 1 à 15 (5 par défaut).
- **Température** : 0 (déterministe) à 2 (très créatif). 0,7 par défaut.
- **Max tokens** : longueur maximale de la réponse IA. 2000 par défaut.
Coût indicatif : une génération de 5 questions coûte environ 0,0005 $ avec gpt-4o-mini et 0,001 $ avec claude-haiku-4-5. Pour 200 produits en 3 langues, comptez 0,30 à 0,60 $ au total.
## Onglet Prompt — personnaliser le contenu généré
### Ton de voix
Six styles préconfigurés : professionnel, amical, décontracté, technique, enthousiaste, rassurant. Le ton change la formulation des réponses sans rien coder.
### Audience cible
Texte libre, par exemple « professionnels de santé (B2B) », « premiers acheteurs » ou « bricoleurs ». L'IA adapte le vocabulaire, les références et le niveau de détail.
### Prompt système personnalisé
Laissez vide pour utiliser le prompt par défaut construit à partir du ton et de l'audience. Si vous le remplissez, il remplace complètement les instructions par défaut — utile pour les boutiques avec une charte éditoriale stricte.
### Directives supplémentaires
Instructions ajoutées à chaque prompt, par exemple « toujours mentionner la garantie 2 ans », « éviter les superlatifs », « ne pas comparer aux concurrents ».
### Contexte produit à inclure
Trois cases à cocher enrichissent le contexte envoyé à l'IA : **catégorie principale**, **marque** (taxonomies `product_brand`, `pwb-brand` et `yith_product_brand` détectées automatiquement) et **attributs WooCommerce**. Sur les produits techniques, l'inclusion des attributs améliore nettement la pertinence des questions.
## Onglet Affichage & SEO
### Position d'affichage
Cinq hooks WooCommerce au choix :
- `woocommerce_after_single_product_summary` — sous les onglets (par défaut)
- `woocommerce_single_product_summary` — à l'intérieur du résumé produit
- `woocommerce_product_meta_end` — en fin de méta produit
- `woocommerce_after_single_product` — après toute la zone produit
- `woocommerce_before_single_product` — avant toute la zone produit
La **priorité du hook** (15 par défaut) est configurable pour gérer la coexistence avec d'autres plugins.
### Mode d'affichage
Accordéon (première question ouverte, navigation clavier ARIA) ou toutes les réponses dépliées.
### Rich snippets FAQPage
Lorsque l'option est active, le plugin injecte le JSON-LD Schema.org FAQPage dans la balise head de chaque fiche produit ayant au moins une FAQ active. L'encodage utilise `JSON_HEX_TAG`, `JSON_HEX_AMP`, `JSON_HEX_APOS` et `JSON_HEX_QUOT` et passe le Rich Results Test de Google.
### Titre de la FAQ par langue
Un champ de titre par langue active du site, avec des valeurs par défaut fournies en FR, EN, ES, DE, IT, PT et NL.
### Catégories exclues
Liste d'identifiants de catégories WooCommerce séparés par des virgules. Les produits de ces catégories sont ignorés en génération de masse et en auto-génération (produits virtuels, cartes cadeaux, etc.).
## La métabox FAQ sur la fiche produit
Sur l'écran d'édition de chaque produit, la métabox **FAQ IA** offre un contrôle complet :
- **Générer avec l'IA** : crée un jeu de questions/réponses pour la langue sélectionnée.
- **Ajouter une question** manuelle à tout moment.
- **Modifier** une question ou une réponse : la ligne s'enregistre automatiquement à la perte de focus.
- **Réordonner** par glisser-déposer via la poignée à gauche de chaque ligne.
- **Activer/désactiver** une entrée sans la supprimer.
- **Supprimer** définitivement une entrée.
Un sélecteur de langue en haut de la métabox permet de basculer instantanément entre les traductions Polylang ou WPML du produit — chaque traduction possède son propre jeu de FAQ.
## Génération en masse
Menu **FAQ IA → Génération en masse** :
1. Choisissez la **langue cible** : langue par défaut, langue spécifique, ou toutes les langues actives.
2. Cochez éventuellement **Forcer la régénération** pour écraser les FAQ existantes (utile après un changement de ton ou de fournisseur).
3. Cliquez sur **Démarrer**.
Le traitement est séquentiel (environ un produit par seconde selon la latence API) avec barre de progression en temps réel, compteur de produits traités et journal d'erreurs par produit. Le bouton **Stop** interrompt proprement entre deux produits. Les produits publiés uniquement sont traités ; les catégories exclues sont ignorées.
Laissez l'onglet du navigateur ouvert pendant la génération en masse : le traitement est piloté côté navigateur pour permettre la barre de progression et l'arrêt à la demande.
## Auto-génération à la création de produit
Option de l'onglet Fournisseur : lorsqu'elle est active, le plugin génère automatiquement une FAQ dans la langue par défaut à chaque enregistrement d'un produit qui n'en a pas encore. Les FAQ existantes ne sont jamais écrasées par ce mécanisme.
## Multilingue Polylang & WPML
Le plugin détecte automatiquement Polylang (`pll_languages_list`, `pll_get_post_translations`) et WPML (`wpml_active_languages`, `wpml_object_id`). Chaque traduction d'un produit reçoit son propre jeu de FAQ, généré nativement dans la langue cible — ce n'est pas une traduction de l'original. La génération en masse « toutes langues » parcourt chaque traduction de chaque produit.
## Vérifier les rich snippets
1. Ouvrez une fiche produit ayant au moins une FAQ active.
2. Affichez le code source et cherchez `application/ld+json` : un bloc `"@type":"FAQPage"` doit être présent.
3. Testez l'URL dans le [Rich Results Test de Google](https://search.google.com/test/rich-results) : la détection « FAQ » doit être valide.
Google décide seul de l'affichage des rich results en SERP ; le balisage valide est une condition nécessaire mais non suffisante. L'affichage apparaît généralement après réindexation de la page.
## Dépannage
### « La clé API du fournisseur IA n'est pas configurée »
Renseignez la clé du fournisseur actif dans l'onglet Fournisseur. Vérifiez qu'il n'y a pas d'espace avant/après la clé.
### Erreur API pendant la génération
Consultez **WooCommerce → État → Journaux** et sélectionnez la source `dffaqai` : chaque erreur API y est enregistrée avec le code HTTP et le message du fournisseur (clé invalide, quota dépassé, modèle inconnu…).
### Le bloc FAQ ne s'affiche pas
Vérifiez que le produit a au moins une FAQ _active_ dans la langue affichée, et que le thème exécute le hook choisi. En cas de doute, revenez au hook par défaut `woocommerce_after_single_product_summary`, présent sur tous les thèmes WooCommerce standards.
### Les questions générées sont dans la mauvaise langue
La langue de génération suit la traduction du produit (Polylang/WPML) ou la locale du site en mono-langue. Vérifiez le sélecteur de langue de la métabox avant de générer.
## Désinstallation
La désactivation conserve toutes les données. La **suppression** du plugin exécute `uninstall.php` : la table SQL des FAQ et toutes les options `dffaqai_*` sont supprimées définitivement.
## Support
Le support s'effectue par email avec une réponse sous 24 h ouvrées (FR/EN). Joignez si possible le journal `dffaqai` et les versions WordPress/WooCommerce/PHP.
---
### DataFirefly FEC — Export comptable WooCommerce
_Source :_
> Présentation DataFirefly FEC transforme vos commandes WooCommerce en écritures comptables en partie double et les exporte dans sept formats : le FEC officiel français (obligatoire en cas de contrôle fiscal,…
## Présentation
DataFirefly FEC transforme vos commandes WooCommerce en écritures comptables en partie double et les exporte dans sept formats : le FEC officiel français (obligatoire en cas de contrôle fiscal, article L.47 A-I du LPF), Sage 100, EBP Compta, Pennylane, Tiime, Indy et Quadratus. Toutes les écritures sont vérifiées (équilibre débit/crédit) avant export.
## Installation
1. Téléchargez le fichier `dfwoo-fec.zip` depuis votre compte client DataFirefly.
2. Dans l'admin WordPress, allez dans **Extensions → Ajouter → Téléverser une extension** et sélectionnez le ZIP.
3. Cliquez sur **Installer maintenant** puis **Activer**.
4. Le menu **WooCommerce → Export comptable FEC** apparaît.
Prérequis : WordPress 6.0+, WooCommerce 7.0+ (testé jusqu'à 9.4), PHP 7.4+. Le plugin est compatible HPOS (High-Performance Order Storage).
## Configuration initiale
Avant votre premier export, rendez-vous dans l'onglet **Paramètres comptables** et renseignez :
### Identité de l'entreprise
- **Raison sociale** — reprise dans les libellés.
- **SIREN** — 9 chiffres, utilisé pour le nommage du fichier FEC officiel (`SIRENFECAAAAMMJJ.txt`).
### Journaux
Par défaut : `VE` (Journal des ventes) et `BQ` (Journal de banque). Adaptez les codes si votre expert-comptable utilise une autre nomenclature (3 caractères maximum recommandé pour Quadratus).
### Plan de comptes
- **Compte client** : 411000 par défaut. Cochez « comptes auxiliaires par client » pour générer un auxiliaire stable par client (C+ID pour les clients connectés, G+hash email pour les invités).
- **Comptes de produits** : 707000 ventes, 708500 ports, 709000 remises, 708000 frais divers.
- **Comptes de TVA par taux** : 445712 (20 %), 445711 (10 %), 445713 (5,5 %), 445714 (2,1 %), 445715 (0 %). Chaque taux détecté dans une commande est ventilé sur son compte dédié.
- **Comptes de trésorerie par moyen de paiement** : laissez vide pour utiliser le compte banque par défaut (512000), ou attribuez un compte distinct par gateway (ex. 512100 Stripe, 512200 PayPal) pour faciliter le rapprochement bancaire.
### Statuts de commande
Deux réglages indépendants :
- **Statuts générant une écriture de vente** — par défaut Processing et Completed. L'écriture est datée à la date de création de la commande.
- **Statuts générant une écriture d'encaissement** — par défaut Completed. L'écriture est datée à la date de paiement enregistrée par WooCommerce.
## Schéma comptable généré
### Écriture de vente (journal VE, date de commande)
- Débit 411 Client : total TTC de la commande
- Crédit 707 Ventes : montant HT des produits, ventilé par taux de TVA
- Crédit 708 Ports : montant HT du transport, ventilé par taux
- Crédit 44571x TVA collectée : TVA par taux
### Écriture d'encaissement (journal BQ, date de paiement)
- Débit 512 Banque (ou compte du moyen de paiement) : total TTC
- Crédit 411 Client : total TTC
Chaque écriture est contrôlée : si l'écart débit/crédit dépasse 5 centimes, elle est rejetée. En dessous, l'arrondi est corrigé automatiquement sur la dernière ligne.
## Exporter un fichier
1. Onglet **Export** : choisissez la date de début et la date de fin.
2. Sélectionnez le format dans la liste déroulante.
3. Cliquez sur **Aperçu (50 lignes)** pour vérifier visuellement la structure, ou directement sur **Télécharger le fichier**.
## Détail des formats
### FEC (officiel France)
18 colonnes séparées par pipe (ou tabulation, au choix) : JournalCode, JournalLib, EcritureNum, EcritureDate, CompteNum, CompteLib, CompAuxNum, CompAuxLib, PieceRef, PieceDate, EcritureLib, Debit, Credit, EcritureLet, DateLet, ValidDate, Montantdevise, Idevise. Dates au format AAAAMMJJ, montants à virgule décimale. Encodage UTF-8 ou ISO-8859-15. Nommage `SIRENFECAAAAMMJJ.txt` conforme DGFiP.
### Sage 100
CSV point-virgule, encodage Windows-1252, colonnes compatibles avec l'Import paramétrable Sage 100c : JournalCode, DateEcriture, Compte, TiersCompte, LibelleEcriture, Debit, Credit, NumPiece, DateEcheance, ReferenceFacture.
### EBP Compta
CSV point-virgule Windows-1252 avec sens D/C par ligne : JournalCode, Date, NumeroCompte, CompteTiers, LibelleEcriture, NumeroPiece, Montant, Sens.
### Pennylane
CSV UTF-8 avec BOM, colonnes natives Pennylane : Date, Journal, Numéro de pièce, Libellé, Compte, Compte auxiliaire, Débit, Crédit.
### Tiime
CSV UTF-8 avec BOM : Date, Journal, Compte, Libelle, Debit, Credit, Piece, Tiers.
### Indy
CSV UTF-8 avec BOM adapté aux indépendants, avec une colonne Type distinguant Vente et Recette : Date, Type, Journal, Compte, Libelle, Debit, Credit, Reference.
### Quadratus
Fichier texte ASCII largeur fixe (lignes « M » de 102 caractères), encodage Windows-1252, compatible Cegid Quadra Compta. Montants en centimes cadrés à droite, dates JJMMAA.
Le format Quadratus varie légèrement selon les versions de Cegid Quadra Compta. Validez le premier export avec votre expert-comptable via l'aperçu 50 lignes ; un ajustement de positions est parfois nécessaire.
## Automatisation WP-CLI
Le plugin fournit une commande CLI pour les exports programmés :
```
wp dfwoo-fec export --from=2026-01-01 --to=2026-03-31 --format=fec --output=/chemin/fec-t1.txt
```
Options : `--format` accepte fec, sage100, ebp, pennylane, tiime, indy, quadratus. Sans `--output`, le contenu est envoyé sur la sortie standard. Exemple de cron mensuel :
```
0 6 1 * * cd /var/www/site && wp dfwoo-fec export --from=$(date -d "last month" +%Y-%m-01) --to=$(date -d "last month" +%Y-%m-31) --format=fec --output=/exports/fec-mensuel.txt
```
## Questions fréquentes
### Les remboursements et avoirs sont-ils gérés ?
La version 1.0.0 exporte les écritures de vente et d'encaissement. Les avoirs (credit notes) sont prévus dans une version ultérieure ; en attendant, saisissez-les manuellement dans votre logiciel comptable.
### Puis-je exporter plusieurs années ?
Oui, la plage de dates est libre. Pour de gros volumes (plus de 10 000 commandes), préférez la commande WP-CLI qui n'est pas soumise au timeout HTTP.
### Le plugin modifie-t-il mes commandes ?
Non, il travaille exclusivement en lecture. Aucune donnée de commande n'est modifiée, aucune table n'est créée.
## Support
Support technique inclus 12 mois via votre compte client DataFirefly. Joignez le fichier d'aperçu et la version de WooCommerce à toute demande concernant un format d'export.
---
### DataFirefly Google Shopping — Guide complet
_Source :_
> Présentation DataFirefly Google Shopping est un module PrestaShop 8 et 9 qui génère des flux Merchant Center conformes à la spec Google Shopping 2025 et les décline automatiquement sur 6…
## Présentation
DataFirefly Google Shopping est un module PrestaShop 8 et 9 qui génère des flux Merchant Center conformes à la spec Google Shopping 2025 et les décline automatiquement sur 6 canaux (Google, Bing, Meta Catalog, Kelkoo, Idealo, LeGuide). Il embarque 5 assistants IA (Anthropic Claude, OpenAI GPT-4o ou Mistral AI au choix), un score qualité 0-100, un éditeur de masse AJAX, un audit d'images par vision IA et des outils premium (A/B test de titres, forecaster saisonnier, export Google Ads Editor).
Le module crée 12 tables préfixées `dfgs_` et 9 onglets back-office sous le menu « Google Shopping ». Aucune surcharge core, aucun fichier PrestaShop modifié.
## Installation
1. Dans le back-office PrestaShop, allez dans **Modules → Gestionnaire de modules → Installer un module**.
2. Téléversez le fichier `dfexportgoogleshopping.zip`.
3. Cliquez sur **Installer**. Le module crée ses tables, ses onglets admin et ses valeurs de configuration par défaut.
Prérequis : PrestaShop 8.0 à 9.x, PHP 8.1+, MySQL 5.7+ ou MariaDB 10.3+, extension cURL activée. Le multiboutique et le multilingue sont supportés nativement.
## Créer votre premier flux
1. Allez dans **Google Shopping → Flux** et cliquez sur **Ajouter un flux**.
2. Renseignez le nom, le type de flux (Produits, Local Inventory Ads ou Promotions), la boutique, la langue, la devise et le pays cible.
3. Choisissez le **canal cible** : Google Shopping (défaut), Bing, Meta Catalog, Kelkoo, Idealo ou LeGuide. Le format XML est adapté automatiquement au canal (namespaces, renames d'attributs, limites de longueur).
4. Configurez les filtres d'inclusion : catégories, fabricants, exclusion des produits hors stock.
5. Enregistrez puis cliquez sur **Générer**. L'URL publique du flux (sécurisée par token) s'affiche dans la liste — c'est elle que vous déclarez dans Merchant Center.
Un flux par couple pays/langue est la bonne granularité : un flux FR pour la France, un EN pour le Royaume-Uni, un DE pour l'Allemagne, chacun avec sa devise.
## Mapping des catégories Google
Dans **Google Shopping → Mapping catégories**, associez chaque catégorie de votre boutique à une catégorie de la taxonomie Google (environ 6 000 entrées, mise en cache 30 jours). Deux méthodes :
- **Manuelle** : recherche avec autocomplétion dans la taxonomie.
- **Auto-mapping IA** : le bouton « Mapper automatiquement » envoie vos catégories non mappées à l'assistant IA, qui propose la meilleure correspondance. Les propositions à confiance élevée sont appliquées, les autres restent en attente de validation.
Le mapping se propage aux sous-catégories non mappées. L'attribut `google_product_category` et le `product_type` sont renseignés automatiquement dans le flux.
## Surcharges produit
L'onglet **Surcharges produits** permet de forcer, produit par produit (et par langue/boutique), les valeurs du flux : titre, marque, GTIN, MPN, condition, couleur, taille, matière, custom labels 0-4, catégorie Google, exclusion du flux, etc. Les surcharges priment toujours sur les valeurs extraites du catalogue.
## Édition de masse
L'onglet **Édition de masse** affiche une grille AJAX de 50 produits par page avec recherche par nom, référence ou ID. Fonctionnement :
- **Édition inline** : cliquez dans une cellule, saisissez la valeur, Entrée — la sauvegarde est immédiate (fond vert = succès).
- **Action en masse** : cochez plusieurs produits, choisissez un champ et une valeur, cliquez sur Appliquer. Le bouton « Supprimer overrides » retire les surcharges des produits sélectionnés.
## Import / Export CSV et prévisualisation
L'onglet **Import / Export / Preview** regroupe trois outils :
- **Export CSV** des surcharges ou des mappings catégorie (UTF-8 avec BOM, séparateur point-virgule, compatible Excel).
- **Import CSV** avec sémantique claire : cellule vide = aucun changement, astérisque (`*`) = vider le champ.
- **Prévisualisation XML** : saisissez un ID produit et un flux, obtenez le XML exact de ce produit avec les problèmes de validation détectés. Idéal pour déboguer un produit refusé.
## Assistants IA
Configurez d'abord le fournisseur dans **Google Shopping → Réglages** : Anthropic (Claude), OpenAI (ChatGPT/GPT-4o) ou Mistral AI, avec votre clé API et le modèle. Modèles recommandés : `claude-haiku-4-5-20251001` ou `gpt-4o-mini` (rapides, peu chers) ; `claude-sonnet-4-6` ou `gpt-4o` pour la qualité maximale.
L'onglet **Assistants IA** pilote les 5 assistants :
- **Mapping catégories** : associe vos catégories à la taxonomie Google.
- **Réécriture de titres** : optimise les titres selon le vertical détecté (apparel, electronics, books, home, beauty, food) et les patterns recommandés par Google.
- **Extraction d'attributs** : déduit color, size, material, pattern, age_group, gender depuis les descriptions (confiance ≥ 0.80).
- **Recherche GTIN** : retrouve le GTIN à partir de marque + MPN + nom, avec validation modulo 10 (confiance ≥ 0.85).
- **Correction des refus** : analyse chaque refus Merchant Center et propose (ou applique automatiquement à confiance ≥ 0.85) une correction structurée.
Chaque appel est journalisé dans la table `dfgs_ai_log` (fournisseur, modèle, tokens entrants/sortants, durée) : vous suivez votre budget IA au centime.
Toutes les features IA sont optionnelles. Sans clé API, le module reste un exportateur Google Shopping complet.
## Score qualité 0-100
À chaque génération d'un flux produits, le module échantillonne 500 items et calcule 9 sous-scores pondérés : couverture GTIN (15 pts), couverture images (10), qualité images (10), qualité titres (15), qualité descriptions (10), mapping catégorie (15), couverture highlights (10), absence de refus critiques ouverts (10), présence des frais de port (5). Le total donne une note de A+ à F affichée sur le dashboard, avec les 5 recommandations à plus fort impact en tête.
## Alertes Slack et email
Dans **Réglages**, renseignez un webhook Slack entrant et/ou une adresse email. Trois déclencheurs : nouveaux refus critiques détectés pendant une génération, chute du score qualité ≥ 10 points par rapport à la génération précédente, échec de génération. Anti-spam : maximum 1 alerte par type et par 6 heures.
## Features premium
L'onglet **Premium** regroupe 5 outils :
- **Analyse Search Console** : téléversez l'export CSV des requêtes (Search Console → Résultats de recherche → Exporter). Le module croise chaque requête avec vos titres produit et calcule un score d'opportunité (impressions × mots-clés absents du titre × multiplicateur de position). Les 20 meilleures opportunités s'affichent avec le produit suggéré.
- **A/B test des titres** : deux variantes alternent par cycles de 7 jours dans le flux. Le gagnant est déclaré quand chaque variante atteint ≥ 500 impressions avec un delta CTR ≥ 5 % ; il est alors appliqué automatiquement en surcharge.
- **Forecaster saisonnier** : analyse 24 mois d'historique de commandes et tague les produits dans `custom_label_4` — `upcoming_season` (index saisonnier > 1.5 sur les 2 prochains mois), `bestseller` (top 10 % du CA 30 jours), `declining_trend` (baisse ≥ 20 % sur 6 mois).
- **Audit qualité d'images** : par lots de 25, la vision IA (Claude Vision ou GPT-4o — Mistral non supporté) détecte filigranes, textes promotionnels, type de fond et produits multiples. Note 0-10 par image, cache 30 jours.
- **Export Google Ads Editor** : CSV importable directement, avec groupes d'annonces hiérarchisés par custom labels et multiplicateurs d'enchère par tag (bestseller ×1.5, upcoming_season ×1.3, on_sale ×1.2, declining_trend ×0.5).
## Automatisation par cron
Chaque flux expose une URL de génération sécurisée par token, affichée dans la liste des flux. Exemple de crontab pour régénérer toutes les 6 heures :
```
0 */6 * * * curl -s "https://votreboutique.com/module/dfexportgoogleshopping/cron?token=VOTRE_TOKEN&id_feed=1" > /dev/null
```
La génération est en streaming : les catalogues de 100 000+ produits passent sans saturation mémoire.
## Dépannage
- **Le flux est vide** : vérifiez les filtres du flux (catégories, stock) et que les produits sont actifs et visibles dans la boutique liée au flux.
- **Produits exclus à la génération** : consultez l'onglet Diagnostic — chaque exclusion est motivée (GTIN invalide, image manquante, prix à zéro…). Utilisez la prévisualisation XML pour le détail d'un produit précis.
- **Erreur d'appel IA** : vérifiez la clé API et le modèle dans Réglages. Le journal `dfgs_ai_log` enregistre les échecs avec leur cause.
- **L'audit d'images échoue avec Mistral** : c'est attendu — la vision nécessite Anthropic ou OpenAI.
- **Après mise à jour PrestaShop, un onglet ne s'affiche plus** : réinitialisez le module (Modules → dfexportgoogleshopping → Réinitialiser) pour recréer les onglets admin sans perdre vos données.
## Désinstallation
La désinstallation supprime les 12 tables `dfgs_`, les onglets admin et les valeurs de configuration `DFGS_`. Exportez vos surcharges et mappings en CSV avant si vous souhaitez les conserver.
---
### DataFirefly Google Tag Manager Pro — Guide complet
_Source :_
> Présentation et prérequis DataFirefly Google Tag Manager Pro pousse un dataLayer GA4 ecommerce complet pour votre boutique WooCommerce, puis vous permet de générer en un clic un conteneur Google Tag…
## Présentation et prérequis
DataFirefly Google Tag Manager Pro pousse un dataLayer GA4 ecommerce complet pour votre boutique WooCommerce, puis vous permet de générer en un clic un conteneur Google Tag Manager prêt à importer, déjà câblé sur ce dataLayer. Le plugin gère aussi le suivi server-side (Meta Conversions API, GA4 Measurement Protocol) avec déduplication automatique, le Consent Mode v2, et un mode d'injection directe des pixels pour les boutiques qui n'utilisent pas GTM.
- WordPress 5.8 et supérieur, testé jusqu'à 7.0.
- WooCommerce 7.0 et supérieur, testé jusqu'à 9.6, compatible HPOS et Cart/Checkout Blocks.
- PHP 7.4 et supérieur.
- Multilingue (FR/EN/ES/DE/IT), compatible Polylang et WPML.
- Aucun suivi émis en back-office, dans les flux ou le customizer.
Le plugin sépare deux rôles : il **produit les données** (le dataLayer GA4) et il **aide à les diffuser** (conteneur GTM généré, pixels directs, événements server-side). Vous choisissez le mode de diffusion qui vous convient.
## Installation
1. Téléchargez l'archive `datafirefly-gtm-pro-1.1.0.zip` depuis votre compte client.
2. Dans l'admin WordPress, allez dans **Extensions > Ajouter > Téléverser une extension** et déposez l'archive.
3. Cliquez sur **Activer**.
4. Ouvrez **Tag Manager Pro** dans le menu d'administration pour accéder aux réglages.
À l'activation, le plugin enregistre ses réglages par défaut. Vous pouvez ensuite renseigner votre conteneur, vos connexions et activer le server-side onglet par onglet.
## Onglet Général — conteneur et dataLayer
Cet onglet pilote l'injection du conteneur et la forme du dataLayer :
- **Identifiant du conteneur** : votre ID GTM au format `GTM-XXXXXXX`. Tant qu'il est vide, rien n'est injecté côté GTM (le dataLayer et le mode direct restent disponibles).
- **Nom du dataLayer** : `dataLayer` par défaut. À ne modifier que si votre installation l'exige.
- **Placement** : head + body (noscript), head seul ou body seul.
- **Priorité de sortie** : standard ou haute (le conteneur est écrit tôt dans le `head`).
Le suivi n'est jamais émis pour les administrateurs et le personnel selon les rôles exclus (onglet Avancé), ni en back-office, dans les flux RSS ou le customizer.
## Onglet Connexions — vos plateformes
Saisissez ici les identifiants des plateformes que vous utilisez. Cette base alimente à la fois le conteneur GTM généré, les pixels directs et les événements server-side. Laissez vide ce que vous n'utilisez pas.
- **Google Analytics 4** : Measurement ID (`G-XXXXXXXXXX`).
- **Google Ads** : Conversion ID (`AW-XXXXXXXXX`), libellé de conversion d'achat, remarketing dynamique (option).
- **Meta** : Pixel ID, jeton Conversions API, code de test CAPI (option).
- **TikTok** : Pixel ID, jeton Events API (option).
- **Pinterest** : Tag ID — **Snapchat** : Pixel ID — **LinkedIn** : Partner ID.
- **Microsoft Advertising (UET)** : Tag ID — **X** : Pixel ID.
- **Hotjar** : Site ID — **Microsoft Clarity** : Project ID.
En bas de l'onglet, le réglage **Diffusion des pixels** détermine le mode : **via Google Tag Manager** (recommandé, vous importez le conteneur généré) ou **injection directe** (le plugin charge lui-même les pixels).
## Tag Pilot — générer et importer le conteneur GTM
L'onglet **Tag Pilot** construit un conteneur Google Tag Manager complet à partir de vos connexions et l'offre en téléchargement. Il génère notamment :
- la balise Google de configuration GA4 et un tag d'événement GA4 par événement activé (avec envoi des données ecommerce depuis le dataLayer) ;
- le Conversion Linker, la conversion d'achat et le remarketing dynamique Google Ads ;
- le pixel Meta et ses événements standard (ViewContent, AddToCart, InitiateCheckout, AddPaymentInfo, Purchase, Search) ;
- des tags Custom HTML pour TikTok, Pinterest, Snapchat, LinkedIn, Microsoft UET, X, Hotjar et Clarity ;
- les Data Layer Variables et les déclencheurs d'événements personnalisés correspondants.
Pour l'importer :
1. Cliquez sur **Télécharger le conteneur GTM (.json)**.
2. Dans Google Tag Manager, ouvrez **Administration > Importer un conteneur**.
3. Sélectionnez le fichier JSON, choisissez votre espace de travail, puis **Fusionner** (conserve vos tags existants) ou **Écraser**.
4. Prévisualisez, puis **Envoyer et publier**.
Sur un conteneur existant, préférez **Fusionner** pour ne pas supprimer vos autres tags.
## Mode pixel direct (sans GTM)
Si vous ne souhaitez pas dépendre de GTM, passez la diffusion en **injection directe** dans l'onglet Connexions. Le plugin injecte alors lui-même les pixels de base (GA4, Meta, et les autres plateformes configurées) et rejoue les événements ecommerce du dataLayer vers Meta, TikTok, Pinterest, Snapchat et GA4. Le même dataLayer alimente les deux approches.
N'activez pas simultanément le même pixel via GTM _et_ en injection directe : vous risqueriez un double comptage. Choisissez un seul mode de diffusion par plateforme.
## Server-side — Meta CAPI et GA4 Measurement Protocol
Dans l'onglet **Server-side**, activez l'envoi des achats directement depuis votre serveur :
- **Meta Conversions API** : nécessite le Pixel ID et un jeton CAPI (onglet Connexions). L'événement Purchase est envoyé avec des données client hachées en SHA-256, les cookies `_fbp`/`_fbc`, l'adresse IP et le user-agent.
- **GA4 Measurement Protocol** : nécessite le Measurement ID (Connexions) et un **secret d'API** (GA4 > Admin > Flux de données > Protocole de mesure).
Le navigateur et le serveur partagent le même `event_id` déterministe par commande (`dfgtm.purchase.`). Meta et GA4 utilisent cet identifiant pour ne compter chaque conversion qu'une seule fois.
Les requêtes server-side sont envoyées de manière non bloquante après le paiement, sur les statuts « en cours », « terminée » ou « paiement complété », une seule fois par commande.
## Consent Mode v2 et Enhanced Conversions
L'onglet **Consent** active le Consent Mode v2 : des états de consentement _denied_ sont posés par défaut avant le chargement du conteneur, avec scoping EEA/UK, `wait_for_update`, URL passthrough et redaction des données publicitaires. Pour mettre à jour le consentement au choix de l'utilisateur, branchez votre bandeau cookies à l'API JavaScript fournie :
```
// Tout accepter
window.dfgtmConsent.grantAll();
// Tout refuser
window.dfgtmConsent.denyAll();
// Mise à jour fine
window.dfgtmConsent.update({ ad_storage: 'granted', analytics_storage: 'granted' });
```
Les **Enhanced Conversions** Google Ads (onglet GA4 Ecommerce) ajoutent des données client hachées en SHA-256 sur l'événement d'achat, pour améliorer l'attribution.
## Événements GA4 ecommerce
Le plugin pousse les événements ecommerce GA4 suivants, chacun activable individuellement, avec des objets `items` complets (item_id depuis le SKU ou l'ID, marque, catégories jusqu'à 5 niveaux, variante, prix, remise) :
- `view_item_list`, `view_item`, `select_item`
- `add_to_cart`, `remove_from_cart`, `view_cart`
- `begin_checkout`, `add_shipping_info`, `add_payment_info`
- `purchase` (dédupliqué : déclenché une seule fois par commande, même au rafraîchissement), `search`
## Hooks développeur
Le plugin expose des filtres aux points clés pour étendre son comportement sans modifier le cœur :
- `dfgtm_export_container` : modifier le conteneur GTM généré avant encodage.
- `dfgtm_meta_capi_payload` et `dfgtm_ga4_mp_payload` : ajuster les charges utiles server-side.
- `dfgtm_connections_registry` : ajouter ou modifier des destinations.
- `dfgtm_purchase_push` et `dfgtm_build_item` : personnaliser la donnée d'achat et la construction des items.
## FAQ et dépannage
### Rien n'est injecté côté GTM
Vérifiez que l'identifiant du conteneur (`GTM-XXXXXXX`) est renseigné dans l'onglet Général et que vous n'êtes pas connecté avec un rôle exclu. Le dataLayer et le mode direct fonctionnent même sans conteneur GTM.
### Les conversions sont comptées deux fois sur Meta
Assurez-vous de ne pas charger le même pixel à la fois via le conteneur GTM et en injection directe. Le server-side et le navigateur, eux, sont dédupliqués automatiquement par `event_id` : ce n'est pas une source de double comptage.
### L'événement d'achat ne remonte pas en server-side
Vérifiez que l'option correspondante est activée dans l'onglet Server-side et que les identifiants requis sont saisis : Pixel ID + jeton CAPI pour Meta, Measurement ID + secret d'API pour GA4. L'envoi a lieu une seule fois par commande.
### Le tag GA4 n'envoie pas les données ecommerce
Dans le conteneur généré, les tags d'événement GA4 lisent les données ecommerce depuis le dataLayer. Si vous avez construit vos tags manuellement, activez « Envoyer les données ecommerce » et choisissez « dataLayer » comme source.
### Que se passe-t-il à la désinstallation ?
Si l'option correspondante est activée dans l'onglet Avancé, les réglages et les méta de suivi des commandes sont supprimés. Sinon, ils sont conservés pour une éventuelle réinstallation.
---
### DataFirefly Guide des tailles — Documentation
_Source :_
> Vue d'ensemble DataFirefly Guide des tailles ajoute à votre boutique PrestaShop un système complet de guides des tailles modulables par catégorie, fabricant ou produit, avec tableaux de correspondance EU/US/UK/FR/JP, calculateur…
## Vue d'ensemble
**DataFirefly Guide des tailles** ajoute à votre boutique PrestaShop un système complet de guides des tailles modulables par catégorie, fabricant ou produit, avec tableaux de correspondance EU/US/UK/FR/JP, calculateur interactif de recommandation de taille, page SEO indexable dédiée par catégorie, et widget de feedback post-achat avec score de biais agrégé.
Le module cible les boutiques textile et chaussures où plus de 20% des retours sont liés à un problème de taille. Il transforme cette friction en un parcours d'achat rassurant : le client voit la bonne charte automatiquement, il peut saisir ses mensurations pour obtenir une recommandation personnalisée, et vous récupérez du feedback qualifié qui vous permet de détecter les produits mal gradués.
### Compatibilité
- PrestaShop 8.0.x, 8.1.x, 8.2.x, 9.0.x
- PHP 8.1, 8.2, 8.3
- Multi-boutique (toutes les affectations sont scopées par `id_shop`)
- Polylang FR/EN/ES/DE/IT/NL/PL prêt à l'emploi
- Thèmes classic, hummingbird et thèmes custom (7 emplacements différents disponibles)
## Installation
1. Téléversez le ZIP `dfsizeguide.zip` depuis **Modules → Module Manager → Téléverser un module**.
2. Cliquez sur **Installer**. Les 13 chartes preset (textile femme et homme haut et bas, robes, soutien-gorge, chaussures femme, homme et enfant, vêtements enfant, gants, chapeaux, bagues, ceintures) sont créées automatiquement en 7 langues, et une affectation par défaut est créée sur la charte textile femme.
3. Dès la fin de l'installation, l'onglet "Guide des tailles" s'affiche sur toutes vos fiches produit sans configuration supplémentaire.
4. Allez dans **Modules → DataFirefly Guide des tailles → Configurer** pour ajuster les emplacements, l'unité par défaut, les fonctionnalités activées.
## Concepts clés
### Le résolveur de chartes à 5 niveaux
Quand un client arrive sur une fiche produit, le module cherche quelle charte afficher en descendant une priorité stricte :
1. **Produit** — si vous avez explicitement affecté une charte à ce produit précis, elle gagne.
2. **Catégorie + Fabricant** — sinon, la charte affectée au couple formé par une catégorie du produit et sa marque. Plus spécifique que chacune des deux dimensions prise seule, ce niveau l'emporte donc sur les deux suivants. Les catégories sont parcourues de la plus profonde à la plus générale.
3. **Fabricant** — sinon, la charte affectée à la marque du produit.
4. **Catégorie** — sinon, la première catégorie du produit qui a une charte, en commençant par la plus profonde (respect de la spécificité).
5. **Défaut** — sinon, la charte marquée comme fallback global.
Cette hiérarchie permet de maintenir une seule charte par marque ou par rayon sans toucher les fiches produit individuelles, tout en gardant la possibilité d'override chirurgical.
### Types de colonnes
Chaque charte est composée de colonnes typées :
- **Colonne "taille"** — une seule valeur textuelle par ligne (S, M, 38, XL). Utilisée pour les correspondances internationales (EU, US, UK, FR, JP).
- **Colonne "mesure"** — une plage numérique min/max par ligne (ex. tour de poitrine 88–92 cm). Utilisée pour indiquer les mensurations qui correspondent à chaque taille.
Le calculateur interactif s'appuie exclusivement sur les colonnes "mesure" pour déterminer la taille recommandée.
## Configuration
### Emplacements sur la fiche produit
Le module expose 7 emplacements activables individuellement dans **Configurer → Emplacements fiche produit** :
- **Onglet produit** (activé par défaut, recommandé) — hook `displayProductExtraContent`, ajoute un onglet propre à côté de "Description" et "Détails". Fonctionne sur la quasi-totalité des thèmes PS 1.7+.
- **Sous le prix** — hook `displayProductPriceBlock` (type `after_price`), rend un lien compact juste sous le prix.
- **Près du bouton "Ajouter au panier"** — hook `displayProductActions`, rend un bouton compact.
- **Sous les infos produit** — hook `displayProductAdditionalInfo`, rend un bouton prominent.
- **Dans le bloc rassurance** — hook `displayReassurance`, s'intègre visuellement avec vos autres arguments (livraison, retours).
- **Après les images produit** — hook `displayAfterProductThumbs`, rend un bouton compact juste sous la galerie.
- **En bas de la page produit** — hook `displayFooterProduct`, rend un bouton prominent en pied de page.
Vous pouvez activer plusieurs emplacements en parallèle : la modale du guide n'est instanciée qu'une seule fois dans le DOM (anti-doublon), et les boutons supplémentaires ouvrent la même modale.
L'onglet produit est le seul emplacement qui rend le tableau _inline_. Les 6 autres emplacements rendent un bouton qui ouvre la modale.
### Paramètres généraux
- **Unité par défaut** — cm ou pouces. Le client peut basculer à la volée, la préférence est conservée dans le calcul.
- **Calculateur interactif** — active la saisie des mensurations et la recommandation de taille (activé par défaut).
- **Retours clients post-achat** — active le widget qui demande au client si la taille était adaptée (activé par défaut).
- **Données structurées JSON-LD** — active l'injection du balisage Schema.org pour améliorer le référencement (activé par défaut).
- **Couleur d'accent** — couleur des boutons, de l'unité active et de la ligne mise en avant. À accorder avec votre thème ; la nuance de survol est calculée automatiquement.
- **Slug page SEO** — préfixe de l'URL des pages guides dédiées (par défaut `size-guide`, à traduire en `guide-des-tailles` si vous voulez une URL francophone).
## Créer et éditer une charte
Menu **Modules → Guides des tailles → Chartes**. Cliquez sur "Ajouter" pour créer une nouvelle charte, ou sur l'icône crayon pour éditer une charte existante.
### Champs de la charte
- **Code interne** — identifiant technique unique (ex. `femme-robes-2026`). Utilisé dans les URLs SEO et les logs.
- **Type** — textile haut, textile bas, robe, chaussures, ou custom.
- **Nom** — libellé multilangue affiché aux clients (titre de l'onglet, titre de la modale, h1 de la page SEO).
- **Introduction (HTML)** — contenu multilangue affiché au-dessus du tableau.
- **Instructions de mesure (HTML)** — encart repliable qui explique comment prendre chaque mensuration.
- **Footer (HTML)** — contenu multilangue affiché sous le tableau (avertissement, lien vers politique de retour, etc.).
- **Meta title / Meta description** — pour la page SEO dédiée.
- **Actif** — bascule on/off. Une charte inactive n'est jamais servie même si elle est affectée.
### Éditer le tableau
Sous le formulaire de la charte, un éditeur visuel permet de construire le tableau :
1. Cliquez sur **Colonne taille** pour ajouter une colonne textuelle. Renseignez le code (ex. `eu`, `intl`) et le libellé multilangue.
2. Cliquez sur **Colonne mesure** pour ajouter une colonne numérique. Renseignez le code (ex. `chest_cm`) et l'unité (cm, pouces, mm).
3. Cliquez sur **Ligne** pour ajouter une ligne. Remplissez les cellules : texte simple pour les colonnes "taille", valeurs min/max pour les colonnes "mesure".
4. Cliquez sur **Enregistrer**. La sauvegarde se fait dans une transaction SQL atomique — soit tout est enregistré, soit rien ne l'est.
### Dupliquer une charte
Le bouton **Dupliquer** de la liste recopie la charte, ses traductions, ses colonnes et leurs libellés, ses lignes et toutes ses cellules. Utile pour dériver une variante d'une charte existante plutôt que de repartir d'un tableau vide.
Deux points à connaître. Les affectations ne sont pas copiées : elles sont uniques par cible, donc les dupliquer volerait les cibles de la charte d'origine. Et la copie est créée **inactive**, pour qu'elle ne puisse pas être servie avant votre relecture. Le code interne est dérivé automatiquement (`femme-haut` devient `femme-haut-copy`) puisqu'il doit rester unique.
## Affecter une charte
Menu **Modules → Guides des tailles → Affectations**.
1. Choisissez la charte à affecter dans la liste.
2. Choisissez le type de cible : Défaut (fallback global), Catégorie, Fabricant, Catégorie + Fabricant, ou Produit.
3. Selon le type, un second champ apparaît pour choisir la catégorie (dans un arbre indenté), la marque (liste déroulante) ou l'ID produit (saisie directe).
4. Cliquez sur **Ajouter / Mettre à jour**. Si une affectation existe déjà pour cette cible, elle est écrasée (upsert).
Toutes les affectations sont scopées par boutique en multi-boutique. Vous pouvez avoir une charte différente pour la même catégorie sur deux boutiques du même groupe.
### Modifier une affectation
Le crayon en bout de ligne recharge l'affectation dans le formulaire, avec sa charte, son type de cible et sa cible. Vous pouvez alors changer la charte, mais aussi déplacer l'affectation vers une autre cible ou transformer une affectation simple en combo catégorie + fabricant. La ligne concernée est mise en évidence dans la liste, et un bouton Annuler permet de ressortir sans rien changer.
Déplacer une affectation vers une cible déjà occupée par une autre est refusé avec un message explicite, puisque chaque cible ne peut porter qu'une seule charte.
## Le calculateur de taille
Le calculateur apparaît sous le tableau, uniquement si la charte a au moins une colonne "mesure".
### Algorithme de scoring
Le client saisit ses mensurations dans les champs (un champ par colonne "mesure"). À la soumission :
1. Les valeurs sont normalisées en centimètres (conversion automatique si l'utilisateur a choisi les pouces : ×2.54).
2. Pour chaque ligne du tableau, le module calcule un score : **+2 points** si la mesure du client tombe exactement dans la plage min/max de la cellule, **+1 point** si elle est proche (à ±5% de la plage), **0 point** sinon.
3. La ligne avec le score le plus élevé est déclarée gagnante.
4. En cas d'égalité, on prend la ligne dont les plages sont les plus centrées sur les valeurs du client.
5. La taille recommandée est extraite en priorité de la colonne `eu`, puis `fr`, `intl`, `uk`, `us`, `jp`.
### Retour utilisateur
Le calculateur affiche la taille recommandée avec un score de confiance en pourcentage, le top 3 des candidates possibles, chacune avec son score, une mise en surbrillance de la ligne recommandée dans le tableau du dessus, et la liste des mesures qui ne matchent aucune ligne (avec avertissement).
## Retours clients post-achat
Un widget "La taille était-elle adaptée ?" apparaît en bas de la fiche produit avec 5 choix : trop petit, un peu petit, parfait, un peu grand, trop grand. Il est rendu uniquement dans les conditions suivantes :
- Le client est connecté (session active).
- Le client a effectivement acheté ce produit (join avec `orders` et `order_detail`, statut valide).
- Le client n'a pas déjà donné son avis sur ce produit.
Le gating est intégralement côté serveur, sans risque de contournement.
### Dashboard des retours
Menu **Modules → Guides des tailles → Retours clients**. Une synthèse au-dessus du tableau montre le nombre de réponses dans chaque catégorie sur les 5 niveaux. En dessous, la liste complète des retours par produit avec l'ID client, la taille achetée et la date.
### Score de biais
Pour chaque produit ayant au moins 3 retours, un score de biais est calculé :
```
score = ((too_large × 2 + slightly_large) − (too_small × 2 + slightly_small)) / total
```
Un score **positif** indique que le produit taille systématiquement grand (à recadrer d'un cran vers le bas). Un score **négatif** indique qu'il taille petit (à recadrer d'un cran vers le haut). Un score proche de zéro indique un bon gradage.
## Page SEO dédiée
Le module expose une route publique par catégorie : `/{slug}/{category-link-rewrite}`, où `{slug}` est le préfixe configuré (par défaut `size-guide`).
Exemple : `https://votreboutique.com/size-guide/robes-femme`
La page contient un fil d'Ariane, le titre h1 de la charte, l'introduction, les instructions de mesure et le tableau complet, le calculateur (si activé), le footer HTML de la charte, et un balisage JSON-LD `WebPage` Schema.org qui aide Google à comprendre que la page est un guide pratique.
Les balises meta title et meta description viennent des champs SEO de la charte. Configurez-les correctement pour capter les recherches longue traîne type "guide des tailles robes femme".
## Multi-langue et multi-boutique
Le module est multilangue au niveau des chartes (nom, intro, instructions, footer, méta), au niveau des libellés de colonnes, et au niveau des libellés Polylang pour les URLs.
En multi-boutique, chaque affectation (guide → cible) est scopée par `id_shop`. Vous pouvez donc afficher la charte A pour la catégorie "Chaussures" sur la boutique française, et la charte B pour la même catégorie sur la boutique allemande.
## Structure technique
### Base de données
8 tables préfixées `dfsg_` : `dfsg_guide`, `dfsg_guide_lang`, `dfsg_column`, `dfsg_column_lang`, `dfsg_row`, `dfsg_cell`, `dfsg_assignment`, `dfsg_feedback`. Toutes les tables sont supprimées proprement à la désinstallation.
### Hooks utilisés
- `actionFrontControllerSetMedia` — injection CSS/JS front
- `displayBackOfficeHeader` — injection CSS/JS admin
- `displayProductExtraContent` — onglet fiche produit (recommandé)
- `displayProductPriceBlock`, `displayProductActions`, `displayProductAdditionalInfo`, `displayReassurance`, `displayAfterProductThumbs`, `displayFooterProduct` — emplacements alternatifs
- `displayHeader` — injection JSON-LD sur les fiches produit
- `actionValidateOrder` — trigger pour d'éventuelles relances (v2)
- `moduleRoutes` — page SEO dédiée
## FAQ
### Le guide ne s'affiche pas sur ma fiche produit, que faire ?
Vérifiez d'abord dans **Configurer → Emplacements fiche produit** qu'au moins un emplacement est activé (Onglet produit par défaut). Si votre thème custom ne rend pas les hooks natifs de PrestaShop, activez plusieurs emplacements en parallèle : au moins l'un des 7 devrait fonctionner. Vérifiez également qu'il existe au moins une charte active et une affectation par défaut dans **Guides des tailles → Affectations**.
### Puis-je importer des tableaux depuis un CSV ?
Pas à ce jour. L'éditeur visuel permet de construire et modifier les tableaux à la volée, colonne par colonne et ligne par ligne. L'import CSV est à l'étude pour une version ultérieure.
### Le calculateur fonctionne-t-il sans JavaScript ?
Non, le calculateur est interactif et nécessite JavaScript pour faire l'appel AJAX au serveur. En revanche, le tableau statique s'affiche parfaitement sans JS, ce qui préserve l'accessibilité et le référencement.
### Y a-t-il un risque de balisage JSON-LD dupliqué ?
Non. Le hook `displayHeader` émet un seul script JSON-LD par page produit, et la page SEO dédiée a son propre balisage `WebPage` distinct. Le validateur Schema.org de Google ne signale aucun doublon.
### Compatible avec la migration PrestaShop 8 vers 9 ?
Oui. Le module déclare `ps_versions_compliancy` de 8.0.0 à 9.99.99, utilise les classes ObjectModel et HelperForm qui restent supportées en PS 9, et n'utilise aucune API dépréciée.
### Comment purger toutes les données du module ?
La désinstallation via le Module Manager supprime toutes les tables `dfsg_*` et toutes les configurations `DFSG_*`. Aucune trace ne reste en base.
## Support
Email : [support@datafirefly.com](mailto:support@datafirefly.com). Réponse sous 5 jours ouvrés en français ou en anglais.
---
### DataFirefly Helpdesk & Ticketing — Guide complet
_Source :_
> Présentation Le module DataFirefly Helpdesk & Ticketing (dfhelpdesk) ajoute à votre boutique un véritable système de support client intégré : chaque demande devient un ticket avec une référence unique, un…
## Présentation
Le module **DataFirefly Helpdesk & Ticketing** (`dfhelpdesk`) ajoute à votre boutique un véritable système de support client intégré : chaque demande devient un **ticket** avec une référence unique, un statut, une priorité, une catégorie et un historique complet. Les agents traitent les tickets depuis une **file d'attente** en back-office, échangent avec le client ou en interne, et pilotent l'avancement sans quitter PrestaShop.
Le module est autonome : aucune dépendance Composer, et une architecture fondée sur `ModuleAdminController` qui garantit la compatibilité de PrestaShop 8.0 à 9.x.
Les tickets peuvent être rattachés automatiquement à une commande : vos agents disposent ainsi du contexte (numéro, montant) directement dans le ticket et sur la fiche commande.
## Compatibilité
- PrestaShop 8.0 à 9.x
- Mono-boutique et multi-boutique
- Catégories de tickets multilingues
- E-mails fournis en français et en anglais
- Aucune dépendance (ni Composer ni framework externe)
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** puis sélectionnez le fichier `dfhelpdesk.zip`.
3. Une fois installé, cliquez sur **Configurer**.
À l'installation, le module crée ses tables (catégories, tickets, messages, pièces jointes), ajoute ses onglets d'administration sous **Service client**, enregistre ses hooks et installe quatre catégories de tickets par défaut.
## Configuration
La page de configuration regroupe les réglages généraux du module :
- **Helpdesk front activé** : affiche ou masque l'espace tickets côté client (compte client et bouton sur le détail de commande).
- **Autoriser les invités** : permet l'ouverture d'un ticket sans compte client. Désactivé, l'ouverture exige une connexion.
- **E-mail de notification** : adresse qui reçoit l'alerte à chaque nouveau ticket. Laissée vide, l'adresse de la boutique est utilisée.
- **Catégorie par défaut** : catégorie pré-sélectionnée lors de la création d'un ticket.
- **Clôture sur réponse** : comportement de statut appliqué lorsqu'une réponse est envoyée.
### Catégories de tickets
L'onglet **Catégories** permet de créer et d'organiser les catégories (par exemple SAV, Livraison, Facturation, Avant-vente). Chaque catégorie possède un **nom multilingue**, une **couleur**, un état actif et une position d'affichage. Les catégories servent à classer les tickets dans la file et à orienter les demandes.
## Côté client
### Espace « Mes tickets »
Lorsque le helpdesk front est activé, un lien **« Mes tickets »** apparaît dans le compte client. Le client y retrouve la liste de ses tickets avec leur référence, leur sujet, leur statut et leur dernière mise à jour, et peut ouvrir chaque conversation.
### Ouvrir un ticket depuis une commande
Sur le détail d'une commande, un bouton **« Ouvrir un ticket »** permet de créer une demande directement liée à cette commande. Le rattachement est automatique : le ticket conserve le numéro de commande comme contexte.
### Ouverture invité
Si l'option est activée, un visiteur non connecté peut ouvrir un ticket en renseignant son nom et son e-mail. La consultation ultérieure du fil reste protégée.
### Suivi et réponse
Depuis le fil d'un ticket, le client lit les réponses de l'équipe et répond en quelques clics. Une réponse du client rouvre le ticket afin qu'il remonte dans la file de traitement.
Les notes internes ne sont jamais visibles côté client : seules les réponses qui lui sont destinées apparaissent dans son fil.
## Côté back-office
### File d'attente
L'onglet **Tickets** affiche la file d'attente : une liste filtrable et triable présentant la référence, le sujet, le client, la catégorie, la **priorité** (badge coloré), le **statut** (badge coloré), l'agent assigné et la date de dernière mise à jour. Vous identifiez ainsi d'un coup d'œil les demandes urgentes et celles en attente.
### Vue d'un ticket
L'ouverture d'un ticket affiche le **fil de conversation** complet, le contexte commande éventuel, et un panneau latéral de gestion. Tout se traite depuis cet écran unique.
### Répondre au client
La zone de réponse envoie un message au client et déclenche, selon la configuration, la notification e-mail et la mise à jour du statut.
### Note interne privée
La **note interne** permet à votre équipe de consigner une information ou d'échanger sur un ticket sans que le client ne la voie. Elle est clairement distinguée dans le fil et reste strictement interne.
### Gestion du ticket
Le panneau de gestion permet de modifier en un clic le **statut**, la **priorité**, la **catégorie** et l'**assignation** à un employé. Chaque changement est immédiatement reflété dans la file.
### Tickets liés à une commande
Sur la fiche commande en back-office, un panneau dédié liste tous les tickets associés à cette commande. Vos agents accèdent ainsi à l'historique support d'une commande sans changer d'écran.
## Statuts et priorités
### Statuts
- **Ouvert** : nouveau ticket en attente de prise en charge.
- **En cours** : pris en charge par un agent.
- **En attente client** : la balle est dans le camp du client.
- **Répondu** : une réponse a été apportée.
- **Fermé** : demande clôturée.
### Priorités
- **Basse**, **Normale**, **Haute**, **Urgente** — chacune associée à un badge coloré dans la file.
## Notifications e-mail
Le module envoie deux types de notifications, avec des templates fournis en **français** et en **anglais** (versions HTML et texte) :
- **Nouveau ticket** : envoyé à l'équipe à chaque ouverture, avec un lien direct vers le ticket en back-office.
- **Réponse au client** : envoyé au client à chaque réponse de l'équipe, avec un lien vers la conversation côté boutique.
Les templates exploitent les variables de référence, de sujet, de nom du client et de message. Ils sont personnalisables comme tout e-mail de module PrestaShop.
## Architecture technique
- **Tables** : catégories (et leur version multilingue), tickets, messages et pièces jointes, toutes préfixées et supprimées à la désinstallation.
- **Hooks** : compte client, détail de commande, chargement des ressources front, en-tête back-office et panneaux sur la fiche commande.
- **Architecture** : contrôleurs d'administration fondés sur `ModuleAdminController` et modèles objet chargés directement, pour une compatibilité totale PrestaShop 8 et 9.
- **Dépendances** : aucune (pas de Composer).
## FAQ et dépannage
### Le module est-il compatible PrestaShop 9 ?
Oui, de PrestaShop 8.0 à 9.x, en mono-boutique comme en multi-boutique, sans méthode dépréciée.
### Les clients invités peuvent-ils ouvrir un ticket ?
Oui, à condition d'activer l'option **Autoriser les invités** dans la configuration. Sinon, l'ouverture nécessite une connexion.
### Le client voit-il les notes internes ?
Non. Les notes internes sont strictement réservées à l'équipe et n'apparaissent jamais dans le fil côté client.
### L'équipe ne reçoit pas les e-mails de nouveau ticket
Vérifiez l'adresse renseignée dans **E-mail de notification** (ou l'adresse de la boutique si le champ est vide), puis la configuration e-mail de PrestaShop (Paramètres avancés > E-mail) et les journaux d'envoi.
### Comment lier un ticket à une commande ?
Côté client, ouvrez le ticket depuis le détail de la commande : le rattachement est automatique. Les tickets liés apparaissent ensuite sur la fiche commande en back-office.
---
### DataFirefly Image Optimizer — Documentation Shopware 6
_Source :_
> DataFirefly Image Optimizer transforme automatiquement chaque image média Shopware en variantes WebP et AVIF, recompresse les JPEG et PNG d'origine, et réécrit les URLs vers votre CDN — sans modification…
DataFirefly Image Optimizer transforme automatiquement chaque image média Shopware en variantes WebP et AVIF, recompresse les JPEG et PNG d'origine, et réécrit les URLs vers votre CDN — sans modification de thème. Cette documentation couvre l'installation, la configuration complète, l'API Twig exposée aux thèmes, et le dépannage.
## Installation
Le plugin est livré sous forme de ZIP. Deux méthodes d'installation, équivalentes fonctionnellement.
### Via l'administration Shopware
1. Réglages → Système → Extensions → Téléverser une extension
2. Sélectionnez `DfImageOptimizer-1.0.0.zip`
3. Cliquez sur Installer puis Activer
4. Vider le cache : Réglages → Système → Cache & Index → Vider
### Via CLI (recommandé)
```
cd /chemin/vers/shopware
unzip DfImageOptimizer-1.0.0.zip -d custom/plugins/
sudo -u www-data setsid php bin/console plugin:refresh
sudo -u www-data setsid php bin/console plugin:install --activate DfImageOptimizer
sudo -u www-data setsid php bin/console cache:clear
sudo -u www-data setsid php bin/console theme:compile
```
**Astuce.**`theme:compile` est obligatoire après installation pour que l'override Twig du composant thumbnail soit actif sur le storefront. Sans cette étape, les balises `` ne seront pas générées même si WebP et AVIF sont produits.
### Vérification post-installation
Allez dans le menu admin **Catalogues → Image Optimizer**. Le dashboard doit s'afficher avec une carte _Compatibilité serveur_ indiquant en temps réel :
- Version PHP détectée (8.2 minimum)
- Présence d'Imagick (recommandé)
- Présence de GD (obligatoire)
- Support effectif WebP — doit être ✓
- Support effectif AVIF — peut être ✗ selon le serveur, pas bloquant
- Moteur recommandé : Imagick ou GD
## Architecture en deux mots
Quand une image est uploadée, le plugin écoute l'événement entity `media.written`, charge l'image dans un fichier temporaire local, puis produit en parallèle :
- L'original recompressé (remplace le fichier d'origine si _Compresser original_ est coché)
- Un sibling WebP à côté avec extension cumulée : `foo.jpg` → `foo.jpg.webp`
- Un sibling AVIF à côté : `foo.jpg` → `foo.jpg.avif`
Les vignettes Shopware générées par le `ThumbnailService` natif sont traitées de la même manière. Côté storefront, l'override Twig de `storefront/component/image/thumbnail.html.twig` wrappe la balise `` dans un `` avec sources AVIF, WebP, et fallback original — le navigateur choisit automatiquement le format le plus léger qu'il supporte.
## Configuration
Accès : **Réglages → Système → Extensions → DfImageOptimizer → Configurer**. Sept cartes regroupent les options.
### Carte « Général »
OptionDéfautEffetAuto-optimisation à l'uploadActivéDéclenche le pipeline immédiatement à chaque upload. Désactivez si vous préférez tout faire en arrière-plan via le cron.Traiter les vignettesActivéGénère WebP/AVIF aussi pour les vignettes Shopware (typiquement 4 à 6 tailles par image source).
### Carte « WebP »
OptionDéfautRecommandationActiver WebPActivéÀ garder activé sauf cas très spécifique. WebP est supporté par 96 % des navigateurs.Qualité WebP (1-100)8275-85 pour un bon compromis. 90+ pour photographie haut de gamme, 70 pour catalogue volumineux.Lossless pour PNGDésactivéActivez seulement si vos PNG contiennent du texte ou des graphiques nets (logos, icônes). Sinon le mode lossy donne de meilleurs gains.
### Carte « AVIF »
OptionDéfautRecommandationActiver AVIFDésactivéActivez si le dashboard indique que votre serveur supporte AVIF. Gain typique de 50 % vs JPEG, mais encodage plus lent que WebP.Qualité AVIF (1-100)5545-65 pour un excellent rendu. AVIF tolère des qualités plus basses que JPEG/WebP grâce à son codec moderne.Largeur max pour AVIF (px)2400Garde-fou CPU. Les images au-delà sont sautées pour AVIF mais conservent leur WebP. Augmentez si vous avez un serveur puissant et besoin d'AVIF sur grandes images.**À propos d'AVIF.** L'encodage AVIF nécessite soit PHP 8.1+ avec le flag `IMG_AVIF` compilé, soit Imagick avec libheif. Le dashboard _Compatibilité serveur_ vous indique exactement ce qui est disponible. Si AVIF n'est pas supporté, l'option reste inopérante même cochée — pas d'erreur, juste pas de génération AVIF.
### Carte « Compression »
OptionDéfautRecommandationCompresser les JPG/PNG originauxActivéRemplace l'original par sa version recompressée. Action **irréversible** — désactivez si vous voulez conserver les sources brutes pour des retouches futures.Qualité JPEG (1-100)8585 est le standard photo web. Descendre à 80 pour gain supplémentaire si la qualité reste acceptable visuellement.Niveau de compression PNG (0-9)79 = compression maximale mais 3-4× plus lente. 7 est l'équilibre standard.Supprimer les métadonnées EXIF/ICCActivéGain typique 5 à 30 Ko par photo issue d'appareil. Conservez si vous gérez du contenu nécessitant des profils colorimétriques précis.
### Carte « CDN »
OptionDéfautExplicationActiver la réécriture CDNDésactivéSi désactivé, les URLs pointent vers votre origine. Activez après avoir configuré votre CDN.URL de base du CDN—Format : `https://cdn.exemple.com` sans slash final. Ex : `https://shop-cdn.b-cdn.net` pour BunnyCDN.Portée de réécritureMédias uniquementVoir détail ci-dessous.Conserver les query stringsActivéPréserve les paramètres de cache-busting (`?v=1234`) lors de la réécriture.
**Détail des trois portées :**
- **Médias uniquement** — réécrit uniquement les URLs commençant par `/media/`. C'est le plus sûr et couvre 95 % des cas d'usage typiques.
- **Médias + vignettes** — ajoute `/thumbnail/`. Utile si votre storefront sert beaucoup de vignettes générées dynamiquement.
- **Tous les assets statiques** — ajoute `/theme/`, `/bundles/` et `/assets/`. Ne choisissez cette option que si votre CDN est correctement configuré pour pull-cache tous les assets et que vous avez testé en staging.
### Carte « Rendu frontend »
OptionDéfautEffetSortie en balise ``ActivéWrappe les `` du storefront dans un `` avec sources AVIF/WebP.Ajouter `loading="lazy"`ActivéLazy-loading natif navigateur. À conserver sauf si vous avez votre propre solution.Ajouter `decoding="async"`ActivéPermet au navigateur de décoder en parallèle du parsing HTML.Forcer `width`/`height`ActivéAnti-CLS (Cumulative Layout Shift). Le navigateur réserve la place du visuel avant son chargement.
### Carte « Traitement en lot »
OptionDéfautRecommandationTaille de lot pour la tâche cron5050 est un bon équilibre. Montez à 100-200 si vous avez besoin de rattraper un gros catalogue rapidement et que votre serveur tient.Intervalle cron (minutes)15Information seule — l'intervalle réel est défini par la classe `OptimizeImagesTask::getDefaultInterval()`. Pour changer effectivement, modifiez la valeur dans la table `scheduled_task` ou réinstallez le plugin après modification.
## Configurer un CDN — exemples concrets
### BunnyCDN (recommandé)
1. Créez une _Pull Zone_ sur bunny.net avec votre URL d'origine, par exemple `https://shop.exemple.com`
2. BunnyCDN vous donne un hostname du type `shop-cdn.b-cdn.net`
3. Dans la config du plugin, mettez : `https://shop-cdn.b-cdn.net`
4. Choisissez la portée _Médias uniquement_ pour démarrer
5. Activez la réécriture CDN
Le plugin injecte automatiquement `` et `` dans le `` du storefront — gain de 50 à 200 ms sur la première requête CDN.
### Cloudflare
Cloudflare en mode proxy DNS standard ne nécessite pas de réécriture CDN — Cloudflare cache automatiquement sur votre hostname principal. Mais si vous utilisez un _Custom Hostname_ Cloudflare dédié pour les assets (par exemple `cdn.exemple.com`), configurez-le ici. Activez aussi _Cache Reserve_ ou _Polish_ côté Cloudflare pour bénéficier en plus de l'optimisation Cloudflare par-dessus la vôtre.
### KeyCDN
Configuration identique à BunnyCDN : créez une Pull Zone, récupérez l'URL du type `shop-12345.kxcdn.com`, configurez-la dans le plugin avec le préfixe `https://`.
### AWS CloudFront
Créez une distribution CloudFront avec votre serveur Shopware comme origine. L'URL de distribution est du type `https://d1234abc.cloudfront.net` — ou votre domaine personnalisé si vous avez configuré un alias. Configurez le TTL minimum à 1 jour pour profiter pleinement du cache.
## Pipeline d'optimisation détaillé
Pour chaque image (originale ou vignette) à traiter, le plugin exécute les étapes suivantes dans l'ordre :
1. Téléchargement de l'image source depuis le filesystem public Shopware vers un fichier temporaire local (`/tmp/dfimgopt_xxx.jpg`)
2. **Si Compresser original activé** : recompression in-place avec qualité configurée, suppression métadonnées si activé. Si la version recompressée est plus petite que l'originale, elle remplace le fichier d'origine sur le filesystem.
3. **Si WebP activé** : conversion vers WebP, écriture du sibling `foo.jpg.webp` sur le filesystem public
4. **Si AVIF activé et largeur ≤ largeur max** : conversion vers AVIF, écriture du sibling `foo.jpg.avif`
5. Enregistrement dans la table `df_image_optimizer` avec compteurs et taille économisée
6. Nettoyage du fichier temporaire local via bloc `finally` (même en cas d'erreur)
Imagick est utilisé en priorité quand disponible (qualité supérieure et seul moteur AVIF via libheif sur de nombreux serveurs). GD prend le relais sinon — il supporte WebP depuis longtemps et AVIF depuis PHP 8.1.
**Compression du JPEG original — irréversible.** Quand l'option _Compresser original_ est cochée, la version compressée remplace l'originale sur le filesystem. Si vous avez besoin de retrouver les sources brutes pour d'autres usages (impression, retouches), désactivez cette option — vous garderez quand même les gains via WebP et AVIF.
## Tâche planifiée — rattrapage des images existantes
Activer le plugin sur une boutique avec déjà des milliers d'images en base ne déclenche pas l'optimisation rétroactive. C'est intentionnel : convertir 50 000 images en AVIF d'un coup saturerait votre serveur. À la place, la tâche planifiée `df_image_optimizer.optimize_pending` s'exécute toutes les 15 minutes par défaut :
1. Requête SQL via LEFT JOIN sur `df_image_optimizer` pour identifier les médias non encore optimisés
2. Traite un lot de 50 images (taille de lot configurable)
3. Termine et libère le worker pour la prochaine tâche
Sur une boutique de 10 000 images, comptez environ 50 heures pour tout rattraper en arrière-plan. Pour accélérer :
- Augmentez la taille de lot dans la config (essayez 100 ou 200)
- Utilisez le bouton **Lancer un lot** du dashboard plusieurs fois d'affilée
- Exécutez la tâche en boucle manuellement via CLI : ``` for i in {1..100}; do sudo -u www-data setsid php bin/console scheduled-task:run-single df_image_optimizer.optimize_pending; done ```
## API Twig exposée aux thèmes
Deux helpers Twig sont enregistrés et utilisables dans n'importe quel template de thème ou plugin.
### Filtre `|df_cdn`
Réécrit une URL vers le CDN si activé, sinon retourne l'URL inchangée. Utile pour les assets que vous incluez manuellement.
```
.hero { background-image: url("{{ bgImage.url|df_cdn }}"); }
```
### Fonction `df_picture()`
Rend une balise `` complète avec sources AVIF, WebP et fallback original, plus tous les attributs configurés (lazy, async, width/height).
```
{{ df_picture(
media,
alt='Description accessible',
classes='product-image card-img',
sizes='(max-width: 768px) 100vw, 50vw'
) }}
```
Génère :
```
```
## Endpoints API admin
Trois endpoints REST sont disponibles, authentifiés via le Bearer token admin standard.
MéthodeRouteDescriptionGET`/api/_action/df-image-optimizer/stats`Vue d'ensemble + activité 30j + capacités serveurPOST`/api/_action/df-image-optimizer/run-batch`Lance un lot. Paramètre POST optionnel `batchSize` (défaut 50, max 500)GET`/api/_action/df-image-optimizer/capabilities`Détection serveur (Imagick / GD / WebP / AVIF)
**Exemple curl :**
```
TOKEN=$(curl -s -X POST https://shop.exemple.com/api/oauth/token
-H "Content-Type: application/json"
-d '{"grant_type":"password","client_id":"administration","scope":"write","username":"admin","password":"shopware"}'
| jq -r .access_token)
curl -X POST https://shop.exemple.com/api/_action/df-image-optimizer/run-batch
-H "Authorization: Bearer $TOKEN"
-H "Content-Type: application/json"
-d '{"batchSize":200}'
```
## Tables créées
### `df_image_optimizer`
Une ligne par média optimisé. Clé unique sur `media_id` — une nouvelle optimisation du même média écrase la ligne.
```
id BINARY(16) UUID
media_id BINARY(16) FK media.id ON DELETE CASCADE, UNIQUE
has_webp TINYINT(1)
has_avif TINYINT(1)
compressed TINYINT(1)
original_size BIGINT Poids original en octets
bytes_saved BIGINT Cumul économies (compression + delta WebP/AVIF)
sales_channel_id BINARY(16) FK sales_channel.id ON DELETE SET NULL
optimized_at DATETIME(3)
created_at DATETIME(3)
```
### `df_image_optimizer_log`
Journal optionnel des erreurs. Lecture seule pour le debug — pas de purge automatique.
## Dépannage
### « Le dashboard affiche AVIF : Indisponible »
Votre serveur n'a pas la stack AVIF requise. Options :
- **Si GD-only** : vérifiez `php -m | grep gd` et `php -i | grep AVIF`. Il faut PHP 8.1+ _et_ GD compilé avec `--with-avif`. Sur Debian/Ubuntu récents, c'est par défaut.
- **Si Imagick disponible** : vérifiez `php -r "print_r(Imagick::queryFormats('AVIF'));"`. Vide ? Votre Imagick n'est pas compilé avec libheif — recompilation nécessaire ou passage à GD.
- **Fallback acceptable** : laissez AVIF désactivé et concentrez-vous sur WebP. Le gain de WebP seul est déjà énorme par rapport au JPEG natif Shopware.
### « Les images `.webp` sont bien générées mais le storefront affiche du JPEG »
Le compilateur de thème n'a pas pris en compte l'override Twig. Solution :
```
sudo -u www-data setsid php bin/console theme:compile
sudo -u www-data setsid php bin/console cache:clear
```
Vérifiez ensuite avec les DevTools du navigateur (Chrome ou Firefox) : ouvrez l'onglet Réseau, rechargez une page produit, et regardez le type MIME des images chargées. Vous devriez voir `image/avif` ou `image/webp` au lieu de `image/jpeg`.
### « L'upload des médias est devenu lent »
La conversion AVIF en particulier est CPU-intensive — comptez 1 à 3 secondes par image. Si c'est gênant, désactivez l'auto-optimisation à l'upload (carte Général) et laissez uniquement la tâche planifiée traiter en arrière-plan. Les uploads redeviennent instantanés et les images sont optimisées sous 15 minutes max.
### « Les vignettes `.webp` ne sont pas générées »
Vérifiez que _Traiter les vignettes_ est coché dans la carte Général. Régénérez ensuite manuellement les vignettes pour qu'elles repassent dans le pipeline :
```
sudo -u www-data setsid php bin/console media:generate-thumbnails
```
### « Comment vider tous les fichiers WebP/AVIF générés ? »
Le plugin ne les supprime pas automatiquement, même à la désinstallation (pour préserver vos sauvegardes). Pour les nettoyer manuellement :
```
cd /chemin/vers/shopware
find public/media -name "*.webp" -delete
find public/media -name "*.avif" -delete
```
### « Les URLs CDN ne sont pas appliquées partout »
Vérifiez la portée configurée. Si vous voyez des URLs origine pour des assets de thème (`/theme/.../style.css`), c'est normal avec la portée par défaut _Médias uniquement_. Passez à _Tous les assets statiques_ si votre CDN est configuré pour servir tous les assets.
Notez aussi que les URLs réécrites concernent le rendu Twig serveur. Si votre frontend appelle l'API Store-API et reconstruit les URLs côté JS, vous devrez appliquer la réécriture côté client séparément.
## Désinstallation
```
sudo -u www-data setsid php bin/console plugin:uninstall DfImageOptimizer
sudo -u www-data setsid php bin/console plugin:remove DfImageOptimizer
```
Lors de la désinstallation, Shopware demande si vous voulez conserver les données utilisateur :
- **Conserver** (par défaut) : les tables `df_image_optimizer` et `df_image_optimizer_log` restent en base. Réinstaller le plugin reprendra l'historique.
- **Ne pas conserver** : les deux tables sont supprimées (DROP TABLE).
Dans les deux cas, les fichiers `.webp` et `.avif` sur le filesystem restent — utilisez les commandes `find` ci-dessus pour les nettoyer si nécessaire.
## Pour aller plus loin
- Surveillez votre score Core Web Vitals dans Google Search Console — le LCP doit baisser dans les 2 à 4 semaines suivant l'activation
- Testez avec PageSpeed Insights avant/après — gain typique 20 à 40 points sur mobile
- Activez aussi un outil HTTP/2 ou HTTP/3 côté serveur pour multiplier le bénéfice du CDN
- Combinez avec un cache plein page Shopware pour des temps de réponse statiques
---
### DataFirefly Indexing API — Documentation
_Source :_
> Présentation DataFirefly Indexing API soumet automatiquement les produits, catégories et pages CMS de votre boutique PrestaShop aux deux canaux de soumission directe existants : IndexNow via le relais api.indexnow.org, qui…
## Présentation
DataFirefly Indexing API soumet automatiquement les produits, catégories et pages CMS de votre boutique PrestaShop aux deux canaux de soumission directe existants : **IndexNow** via le relais `api.indexnow.org`, qui propage vers Bing, Yandex, Naver et Seznam en un seul appel, et **Google Indexing API** (authentification Service Account OAuth2, signature JWT RS256 native). Le module s'accroche aux hooks PrestaShop natifs, enfile chaque modification dans une file d'attente déduplifiée, et un CRON traite le lot toutes les quelques minutes. Vous gardez un journal complet des soumissions et un dashboard du taux d'acceptation.
**À lire avant de configurer Google :** Google restreint officiellement son Indexing API aux pages comportant des données structurées `JobPosting`, ou `BroadcastEvent` intégré dans un `VideoObject`. Une fiche produit ou une page catégorie n'entre dans aucun des deux cas. L'API accepte quand même la soumission et répond 200, mais ce code signifie seulement que la notification a été reçue, pas que l'URL sera crawlée ni indexée. Pour un catalogue e-commerce, **IndexNow est le canal qui produit un effet mesurable** : configurez-le en priorité, et traitez Google comme un canal secondaire journalisé.**En résumé :** vos nouveaux produits et modifications de fiches sont poussés à Bing, Yandex, Naver et Seznam dans les minutes qui suivent, sans abonnement tiers ni commission par URL. Côté Google, la soumission accélère la découverte sans garantie d'indexation.
## Prérequis
- PrestaShop 8.0 à 8.99, ou PrestaShop 9.x
- PHP 7.4 à 8.3
- Extensions PHP `openssl` (pour la signature JWT RS256 de Google) et `curl` (pour les requêtes HTTP)
- Un CRON système ou un service de CRON externe pour appeler le traitement de la file d'attente toutes les 5 à 15 minutes
- **Optionnel, pour Google :** un compte Google Cloud avec un projet où activer l'Indexing API et créer un Service Account, et une propriété Search Console vérifiée pour votre domaine
## Installation
### Étape 1 : téléchargement
Téléchargez le ZIP `dfindexingapi-1.0.0.zip` depuis votre compte DataFirefly après achat.
### Étape 2 : installation via le back-office
1. Connectez-vous à votre back-office PrestaShop
2. Allez dans **Modules › Gestionnaire de modules › Installer un module**
3. Cliquez sur **Sélectionner un fichier** et choisissez le ZIP téléchargé
4. Validez. PrestaShop décompresse et installe le module
5. Une fois installé, cliquez sur **Configurer**
### Étape 3 : vérifications post-installation
À l'installation, le module crée automatiquement :
- Les deux tables SQL `ps_df_indexapi_queue` (file d'attente) et `ps_df_indexapi_log` (journal)
- Une clé IndexNow alphanumérique de 32 caractères
- Un jeton CRON aléatoire de 32 caractères
- 5 onglets dans le menu admin : parent **DataFirefly Indexing API**, puis **Dashboard**, **File d'attente**, **Journal**, **Configuration**
Ouvrez l'onglet **Configuration** pour passer à l'étape suivante.
## Configuration d'IndexNow
IndexNow est le canal à configurer en premier : pas de Service Account, pas d'OAuth, pas de quota, et aucune restriction sur le type de page. Juste une clé à publier à la racine de votre domaine.
### Comprendre IndexNow
IndexNow est un protocole ouvert poussé par Microsoft Bing et Yandex en 2021, rejoint depuis par Naver et Seznam. Vous générez une clé alphanumérique, vous la publiez à la racine de votre domaine sous la forme d'un fichier accessible publiquement, et vous appelez `api.indexnow.org` avec une liste d'URLs. Le serveur vérifie la clé en lisant le fichier de votre domaine, puis propage les URLs aux moteurs participants. Fiches produits, catégories et pages CMS sont dans son périmètre normal.
### Méthode 1 : récriture .htaccess (recommandée)
C'est la méthode la plus simple : le module sert lui-même le contenu du fichier clé via un contrôleur frontend, et une règle `.htaccess` à la racine de votre boutique réécrit la requête vers ce contrôleur.
1. Dans la configuration du module, ouvrez l'onglet **IndexNow**
2. Cochez **Activer IndexNow**
3. Vérifiez le champ **Hôte**, qui doit correspondre au domaine de votre boutique sans le protocole (par exemple `ma-boutique.fr`)
4. Enregistrez
5. Copiez le snippet `.htaccess` affiché dans la page de configuration, généré dynamiquement avec votre clé courante
6. Collez ce snippet en haut du fichier `.htaccess` à la racine de PrestaShop, juste après le bloc `RewriteEngine on`
7. Cliquez sur **Tester IndexNow** dans la configuration : le module appelle l'URL du fichier clé sur votre domaine et vérifie qu'elle renvoie bien le contenu attendu en `text/plain`
### Méthode 2 : fichier physique
Si vous ne pouvez pas modifier le `.htaccess`, créez manuellement un fichier physique à la racine du domaine.
1. Récupérez votre clé IndexNow depuis la configuration du module (champ **Clé IndexNow**)
2. Créez un fichier dont le nom est exactement **la clé + .txt** (par exemple `a1b2c3d4e5f6.txt`) à la racine de votre domaine
3. Le contenu du fichier doit être uniquement la clé elle-même, sans saut de ligne
4. Vérifiez que `https://votre-domaine.com/a1b2c3d4e5f6.txt` renvoie bien la clé en `text/plain`
5. Cliquez sur **Tester IndexNow**
Vous pouvez régénérer la clé IndexNow à tout moment depuis la configuration (bouton **Régénérer la clé**). N'oubliez pas alors de mettre à jour le snippet `.htaccess` ou le fichier physique en conséquence.
## Configuration de Google Indexing API
**Portée officielle :** cette API est réservée par Google aux pages `JobPosting` ou `BroadcastEvent` dans un `VideoObject`. Sur un catalogue produit, elle reste utilisable techniquement (l'API répond 200 et le module journalise la réponse), mais Google décide seul du crawl et de l'indexation. Cette section est facultative : le module fonctionne parfaitement avec IndexNow seul.
L'API Google Indexing nécessite un Service Account Google Cloud. La procédure prend environ 5 minutes.
### Étape 1 : créer un projet Google Cloud
1. Allez sur [console.cloud.google.com](https://console.cloud.google.com) et connectez-vous
2. En haut, cliquez sur le sélecteur de projet, puis **Nouveau projet**
3. Donnez-lui un nom (par exemple _Indexing API Boutique_) et créez-le
4. Sélectionnez le projet nouvellement créé
### Étape 2 : activer l'Indexing API
1. Dans le menu de gauche, allez dans **APIs et services › Bibliothèque**
2. Recherchez _Indexing API_
3. Cliquez sur **Activer**
### Étape 3 : créer un Service Account
1. Allez dans **APIs et services › Identifiants**
2. Cliquez sur **Créer des identifiants › Compte de service**
3. Donnez-lui un nom (par exemple _indexing-api-prestashop_)
4. Aucun rôle IAM n'est nécessaire : passez à l'étape suivante et finalisez la création
5. Dans la liste des comptes de service, cliquez sur le compte créé
6. Onglet **Clés › Ajouter une clé › Créer une nouvelle clé**
7. Format **JSON**. Téléchargez et conservez le fichier, il ne pourra plus être récupéré ensuite
**Sécurité :** le fichier JSON contient la clé privée du Service Account. Ne le partagez jamais publiquement et ne le commitez pas dans un dépôt Git.
### Étape 4 : ajouter le Service Account à Search Console
1. Copiez l'email du Service Account (forme `nom@projet.iam.gserviceaccount.com`) depuis Google Cloud
2. Allez sur [Google Search Console](https://search.google.com/search-console)
3. Sélectionnez votre propriété (le domaine de votre boutique)
4. Allez dans **Paramètres › Utilisateurs et autorisations**
5. Cliquez sur **Ajouter un utilisateur**, collez l'email du Service Account, sélectionnez le rôle **Propriétaire**
6. Validez
Le rôle **Propriétaire** est requis par Google Indexing API. Le rôle **Lecteur** ou **Pleine autorisation** ne suffit pas, l'API renverra `403 Permission denied`.
### Étape 5 : coller le JSON dans le module
1. Ouvrez le fichier JSON téléchargé dans un éditeur de texte
2. Copiez tout son contenu
3. Dans la configuration du module, section **Google Indexing API**, cochez **Activer Google Indexing API**
4. Collez le JSON complet dans le champ **Service Account JSON**
5. Enregistrez
### Étape 6 : tester la connexion
Cliquez sur le bouton **Tester Google** dans la page de configuration. Le module signe un JWT RS256, l'échange contre un jeton OAuth2, et affiche le résultat. Si tout est correct, vous voyez un message vert _Authentification OK_. Ce test valide l'authentification, pas la prise en compte de vos URLs par Google.
## Configuration du CRON
Le CRON est l'élément qui fait tourner le traitement de la file d'attente. Sans CRON appelé régulièrement, les soumissions s'empilent mais ne partent jamais.
### Action process : traitement de la file d'attente
À appeler **toutes les 5 à 15 minutes**. Le module traite un lot configurable (par défaut 50 jobs) en suivant la déduplication et les filtres d'indexation, puis met à jour le journal et la file.
L'URL exacte est affichée dans la configuration. Elle ressemble à :
```
https://votre-domaine.com/index.php?fc=module&module=dfindexingapi&controller=cron&dfaction=process&token=VOTRE_JETON
```
### Action purge : nettoyage du journal
À appeler **une fois par jour**. Le module supprime les jobs et logs traités au-delà de la rétention configurée (par défaut 30 jours).
```
https://votre-domaine.com/index.php?fc=module&module=dfindexingapi&controller=cron&dfaction=purge&token=VOTRE_JETON
```
### Action key : fichier clé IndexNow
Utilisée uniquement par la récriture `.htaccess`. Vous n'appelez jamais cette URL manuellement.
### Configurer votre CRON système
Sous Linux/cPanel, ajoutez deux lignes dans crontab :
```
# Toutes les 10 minutes : traitement de la file d'attente
*/10 * * * * curl -s "https://votre-domaine.com/index.php?fc=module&module=dfindexingapi&controller=cron&dfaction=process&token=VOTRE_JETON" > /dev/null
# Une fois par jour à 3h : purge du journal
0 3 * * * curl -s "https://votre-domaine.com/index.php?fc=module&module=dfindexingapi&controller=cron&dfaction=purge&token=VOTRE_JETON" > /dev/null
```
### Sécurité du jeton CRON
Le jeton est un secret de 32 caractères généré à l'installation. Sans le bon jeton dans le paramètre `token=`, le contrôleur renvoie HTTP 403. Vous pouvez régénérer le jeton à tout moment depuis la configuration (bouton **Régénérer le jeton CRON**), en pensant alors à mettre à jour vos lignes crontab avec le nouveau jeton.
## Le Dashboard
L'onglet **Dashboard** est votre vue d'ensemble en temps réel. Il mesure la santé technique des appels API, pas l'indexation effective de vos pages.
### Compteurs de file d'attente
Cinq cartes en haut de page :
- **En attente** : jobs créés mais pas encore traités
- **En cours** : jobs verrouillés en traitement par un CRON actif
- **Soumis** : jobs traités avec succès (cumul historique non purgé)
- **Erreur** : jobs ayant échoué après N tentatives maximales
- **Ignoré** : jobs créés mais ignorés par un filtre (par exemple URL_DELETED en IndexNow)
### Diagnostic des providers
Deux cartes affichent l'état de configuration :
- **Google Indexing API** : actif, mal configuré, ou désactivé. Indique si le JSON Service Account est présent et valide
- **IndexNow** : actif, mal configuré, ou désactivé. Indique si la clé et l'hôte sont configurés
### Taux d'acceptation 30 jours
Tableau croisé provider × statut sur les 30 derniers jours, avec coloration sémantique : vert au-dessus de 90 %, orange entre 60 et 90 %, rouge en dessous. Si Google chute sous 90 %, c'est généralement un signe que vous avez dépassé le quota ou que des URLs ne sont plus accessibles. Un taux d'acceptation de 100 % signifie que vos notifications ont été reçues, pas que les URLs ont été indexées.
### Graphique des soumissions quotidiennes
Graphique Chart.js superposant deux courbes par jour : total soumis et total accepté. Utile pour repérer rapidement les chutes ou les pics anormaux.
## La File d'attente
L'onglet **File d'attente** liste tous les jobs (pending, processing, submitted, error, skipped) avec filtres natifs PrestaShop par boutique, type d'objet, ID, provider, statut, date.
### Statuts des jobs
- **pending** : créé, en attente de traitement par le prochain CRON
- **processing** : verrouillé par un CRON actif (transition logique pour éviter le double traitement en parallèle)
- **submitted** : soumission réussie à l'API. Le compteur de tentatives est gelé
- **error** : toutes les tentatives ont échoué. Reste consultable avec le message d'erreur exact retourné par l'API
- **skipped** : créé puis ignoré (par exemple URL_DELETED IndexNow, ou filtre désactivé)
### Actions individuelles
Chaque ligne propose :
- **Relancer** : remet le job en pending et réinitialise le compteur de tentatives
- **Supprimer** : efface le job de la file
### Actions en masse
Boutons en haut de liste :
- **Relancer tous les jobs en erreur** : remet en pending tous les jobs en statut error
- **Purger les jobs traités** : supprime tous les submitted/skipped quel que soit leur âge
## Le Journal
L'onglet **Journal** liste chaque soumission individuelle réalisée : provider, type, ID d'objet, URL soumise, action (URL_UPDATED ou URL_DELETED), code HTTP retourné, indicateur accepté/refusé, message complet de réponse, et date. Filtrable, triable, exportable en CSV via le HelperList PrestaShop standard.
Si Google refuse une URL avec un code HTTP 400 et un message _Unable to fetch URL_, c'est généralement que l'URL n'est pas accessible publiquement (mode maintenance actif, robots.txt qui bloque, redirection en boucle, etc.). Vérifiez l'URL dans un navigateur en navigation privée.
## Filtres d'indexation
Dans la configuration, vous pouvez activer ou désactiver indépendamment trois types d'objets :
- **Produits** : soumission sur création, modification, suppression, désactivation
- **Catégories** : soumission sur création, modification, suppression. La racine catégorie (ID 1 et 2) est ignorée par sécurité
- **Pages CMS** : soumission sur création, modification, suppression
Désactiver un filtre arrête immédiatement l'enfilage pour ce type, mais ne purge pas la file existante. Sur un gros catalogue, restreindre les filtres côté Google est le bon réflexe pour ne pas épuiser le quota de 200 URLs par jour.
## Multi-boutique
Le module est nativement multi-boutique. La configuration (clés Google, clé IndexNow, hôte, activations) est indépendante par sous-boutique. Les jobs et logs sont scopés par `id_shop` : un même produit dans deux sous-boutiques génère deux jobs distincts avec leurs propres URLs canoniques.
Pour configurer indépendamment chaque sous-boutique, utilisez le sélecteur multistore en haut de l'admin avant d'ouvrir la configuration.
## Hooks PrestaShop écoutés
Le module enregistre les hooks suivants à l'installation :
- `actionProductSave` : création ou modification d'un produit. Si actif, enfile URL_UPDATED ; sinon URL_DELETED
- `actionProductDelete` : suppression définitive d'un produit. Enfile URL_DELETED
- `actionObjectCmsAddAfter` : création d'une page CMS
- `actionObjectCmsUpdateAfter` : modification d'une page CMS
- `actionObjectCmsDeleteAfter` : suppression d'une page CMS
- `actionCategoryAdd` : création d'une catégorie
- `actionCategoryUpdate` : modification d'une catégorie
- `actionCategoryDelete` : suppression d'une catégorie
- `displayBackOfficeHeader` : injection d'un fragment CSS pour le styling du dashboard
Chaque hook construit l'URL canonique via l'objet `Link` officiel de PrestaShop, ce qui respecte vos préférences **SEO friendly URL** et les préfixes de langue multilingue.
## Dépannage
### Le test Google échoue avec un code 401
L'authentification a échoué. Vérifiez que :
- Le JSON Service Account collé est complet et bien formé
- L'Indexing API est bien activée dans Google Cloud (bibliothèque)
- L'horloge système du serveur est correcte : un décalage de plus de 5 minutes invalide le JWT
### Le test Google échoue avec un code 403
L'authentification réussit mais Google refuse la requête. Cause habituelle : le Service Account n'a pas été ajouté comme **Propriétaire** de la propriété Search Console. Re-vérifiez l'étape 4 de la configuration Google.
### Le test IndexNow échoue
Le serveur api.indexnow.org n'a pas pu lire le fichier clé sur votre domaine. Causes possibles :
- Le snippet `.htaccess` n'a pas été collé, ou collé au mauvais endroit (il doit être après `RewriteEngine on`)
- Le fichier physique n'a pas été créé, ou n'a pas le bon nom (doit être exactement _la clé + .txt_)
- Le contenu du fichier ne correspond pas à la clé (faute de frappe, saut de ligne supplémentaire)
- Le serveur web sert le fichier avec le mauvais Content-Type (doit être `text/plain`)
- Le pare-feu ou le CDN bloque les requêtes du robot IndexNow
Ouvrez `https://votre-domaine.com/VOTRE_CLE.txt` dans un navigateur en navigation privée : vous devez voir uniquement la clé en texte brut.
### Des jobs restent bloqués en statut processing
Cela signifie qu'un CRON a verrouillé les jobs mais n'a jamais relâché le lock (par exemple le processus a été tué par un timeout PHP). Vous pouvez les débloquer manuellement en passant par phpMyAdmin :
```
UPDATE ps_df_indexapi_queue SET status = 'pending', attempts = 0 WHERE status = 'processing';
```
Si le problème se reproduit régulièrement, augmentez le `max_execution_time` PHP de votre hébergement, ou réduisez la taille du lot dans la configuration du module.
### Le quota Google est dépassé
Google répond avec un code 429 ou un message _Quota exceeded_. Le quota par défaut est de 200 URLs par jour par Service Account.
**Ne comptez pas sur une augmentation de quota.** Google propose bien un formulaire de demande, mais l'approbation est conditionnée à l'usage effectif du balisage `JobPosting` ou `BroadcastEvent` sur le site. Un catalogue e-commerce ne remplit pas ce critère : la demande sera refusée. Traitez les 200 URLs par jour comme un plafond fixe.
Trois options réalistes :
- Attendre 24h, le quota se réinitialisant quotidiennement
- Restreindre les filtres d'indexation côté Google aux types qui comptent vraiment pour vous (par exemple produits seuls, en désactivant catégories et CMS)
- Créer un second Service Account et alterner, chaque Service Account ayant son propre quota de 200 URLs par jour
Rappel : IndexNow n'a pas de quota. Si le volume est votre contrainte principale, c'est le canal sur lequel s'appuyer.
### Réinitialisation complète
Pour repartir de zéro (utile en cas de migration ou de problème complexe) :
1. Désinstaller le module depuis Modules › Gestionnaire
2. Réinstaller : les tables sont recréées, la clé IndexNow et le jeton CRON sont régénérés
3. Reconfigurer Google et IndexNow
4. Mettre à jour le snippet `.htaccess` avec la nouvelle clé
5. Mettre à jour les lignes crontab avec le nouveau jeton
La désinstallation supprime la file d'attente et le journal, mais ne supprime pas les soumissions déjà effectuées côté Google ou IndexNow : elles restent dans leurs historiques respectifs.
## Limites connues
- **Google Indexing API officiellement limitée** aux pages `JobPosting` ou `BroadcastEvent` dans un `VideoObject`. L'API accepte les autres types et répond 200, mais ce code atteste seulement de la réception de la notification. Pour un catalogue produit, IndexNow est le canal principal et Google un complément journalisé
- **Quota Google plafonné** à 200 URLs par jour par Service Account, sans augmentation possible en pratique pour un e-commerce (voir la section Dépannage)
- **IndexNow ne gère pas URL_DELETED** : le protocole considère qu'une 404 ou 410 sur l'URL est la bonne façon de signaler une suppression. Le module ignore donc les jobs IndexNow en URL_DELETED (Google les soumet bien, lui)
- **Variantes produit non soumises individuellement** : l'URL canonique du produit principal suffit, Google consolide naturellement les variantes
- **Racine catégorie ignorée** (ID 1 et 2) pour éviter de soumettre des URLs non pertinentes
- **Le module ne remplace pas un sitemap XML** : le sitemap reste le canal de découverte officiel et doit rester propre et à jour. La soumission directe s'ajoute par-dessus, elle ne s'y substitue pas
## Support
Pour toute question technique : [support@datafirefly.com](mailto:support@datafirefly.com), réponse sous 24h ouvrées en français ou anglais. Inclus pendant 12 mois après l'achat.
---
### DataFirefly Inflation Pricing pour WooCommerce
_Source :_
> Guide complet du plugin DataFirefly Inflation Pricing pour WooCommerce : installation, paliers d'arrondi psychologique, périmètre des campagnes, aperçu, application par lots, annulation et commandes WP-CLI.
## Ce que fait le plugin
DataFirefly Inflation Pricing applique un pourcentage à tout ou partie de votre catalogue WooCommerce, puis recale chaque prix obtenu sur une échelle de prix psychologiques que vous définissez. Une hausse de 3 % sur un produit à 59 € ne donne pas 60,77 € mais 60,90 €, ou 69 € si vous préférez des entiers finissant par 9.
Le parcours complet se fait en trois temps : vous décrivez le périmètre et le pourcentage, le plugin calcule tous les nouveaux prix et vous les présente dans un tableau, puis vous validez. Rien n'est écrit en base avant cette validation, et chaque ancien prix est conservé pour permettre une annulation.
## Installation
1. Téléchargez l'archive ZIP depuis votre compte client DataFirefly.
2. Dans l'administration WordPress, allez dans Extensions puis Ajouter une extension et cliquez sur Téléverser une extension.
3. Sélectionnez le fichier ZIP, installez puis activez.
4. Un nouveau menu apparaît dans WooCommerce, Inflation Pricing.
L'activation crée deux tables : `wp_df_inflation_campaigns` pour les campagnes et `wp_df_inflation_items` pour les lignes de prix. Le préfixe suit celui de votre installation.
**Prérequis** : WordPress 5.8 ou supérieur, WooCommerce 6.0 ou supérieur, PHP 7.4 ou supérieur. Le plugin déclare sa compatibilité avec HPOS et les blocs panier et commande dès son initialisation.
## Les trois écrans
### Nouvelle campagne
C'est l'écran de travail principal. Il regroupe trois cartes : Augmentation, Périmètre et Arrondi. Vous y construisez la campagne puis lancez l'aperçu.
### Historique
La liste de toutes les campagnes avec leur statut. Depuis cette page vous consultez le détail ligne à ligne d'une campagne, vous appliquez une campagne restée en attente, vous annulez une campagne appliquée ou vous supprimez une campagne devenue inutile.
### Règles d'arrondi
Les réglages globaux : paliers d'arrondi, sens, garantie d'augmentation, base de calcul TTC ou HT, taille des lots, comportement à la désinstallation. Un simulateur en bas de page affiche le résultat sur des prix d'exemple.
## Comprendre les paliers d'arrondi
Un palier se définit par trois valeurs :
- **S'applique jusqu'à** : la borne haute de la tranche de prix concernée. La valeur 0 signifie aucune limite, et désigne donc le palier qui traite tous les prix au-dessus des autres paliers.
- **Pas** : l'écart entre deux prix possibles.
- **Terminaison** : le décalage appliqué à cet écart.
Le prix final vaut toujours pas multiplié par un entier, plus la terminaison. Quelques exemples :
- Pas 10, terminaison 9 donne 9, 19, 29, 59, 89, 569, 899
- Pas 1, terminaison 0,90 donne 9,90, 14,90, 60,90, 99,90
- Pas 5, terminaison 4 donne 24, 29, 124, 129, 134
- Pas 0,50, terminaison 0,40 donne 4,40, 4,90, 9,40, 9,90
- Pas 100, terminaison 99 donne 599, 1299, 2499
La terminaison doit rester inférieure au pas, sinon elle n'a plus d'effet visible. Un pas de 1 avec une terminaison de 9 produit simplement tous les entiers.
### Le palier est choisi sur le prix d'origine
Pour éviter qu'un produit situé juste sous une borne ne bascule dans une tranche beaucoup plus grossière, le palier retenu est celui du prix actuel du produit, pas celui du prix calculé. Un article à 19,90 € reste donc traité par le palier des petits prix même si la hausse le fait passer au-dessus de 20 €.
## Le compromis entre lisibilité et précision
C'est le point le plus important à comprendre avant de lancer une campagne. Plus l'échelle d'arrondi est grossière, plus la variation réelle s'écarte du pourcentage demandé.
Prenons une hausse de 3 % sur un produit à 59 €. Le prix brut calculé vaut 60,77 €. Selon l'échelle choisie :
- Pas 1, terminaison 0,90 donne 60,90 €, soit +3,2 %
- Pas 5, terminaison 4 donne 64 €, soit +8,5 %
- Pas 10, terminaison 9 donne 69 €, soit +16,9 %
Aucun plugin ne peut contourner cette arithmétique : si vous exigez des prix entiers finissant par 9, l'écart minimal entre deux prix vaut 10 €, ce qui représente 17 % à 59 €. Le plugin ne masque pas ce fait, il le rend visible avant l'écriture grâce au simulateur, à la colonne Variation de l'aperçu et au plafond par campagne.
Une règle simple : le pas doit rester petit devant les prix de la tranche. Un pas de 1 sur des prix entre 20 et 100 € donne des écarts de 1 à 5 %, ce qui reste cohérent avec une inflation annuelle. Un pas de 10 sur cette même tranche ne l'est pas.
## Les préréglages
Cinq préréglages remplissent le tableau des paliers en un clic depuis l'onglet Règles d'arrondi.
- **Équilibré** : le réglage par défaut. Jusqu'à 10 € pas 0,50 terminaison 0,40, jusqu'à 100 € pas 1 terminaison 0,90, jusqu'à 300 € pas 5 terminaison 4, au-delà pas 10 terminaison 9. La variation réelle reste comprise entre 2 et 5 % pour une consigne à 3 %.
- **Entiers finissant par 9** : jusqu'à 100 € et au-delà, pas 10 terminaison 9. Vous obtenez exactement 59, 89, 569, 899. Les écarts sur les petits prix sont importants.
- **Entiers finissant par 4 ou 9** : pas 5 terminaison 4 sous 100 €, pas 10 terminaison 9 au-delà. Un compromis courant en retail.
- **Décimales finissant par ,90** : pas 1 terminaison 0,90 sous 100 €, pas 10 terminaison 9,90 au-delà.
- **Aucun arrondi psychologique** : pas 0,01 terminaison 0. Le pourcentage est appliqué au centime près.
Les préréglages ne sont qu'un point de départ. Vous pouvez ajouter, retirer ou modifier des paliers librement, puis enregistrer.
## Sens d'arrondi et garantie d'augmentation
### Sens
- **Prix psychologique le plus proche** : le comportement recommandé. Le prix calculé bascule vers la valeur la plus proche de son palier, au-dessus ou en dessous.
- **Toujours vers le haut** : le prix monte systématiquement au cran supérieur. Les marges sont protégées mais les hausses réelles dépassent souvent la consigne.
- **Toujours vers le bas** : le prix descend au cran inférieur. À réserver aux baisses de prix.
### Garantie d'augmentation
Avec le sens au plus proche, un petit pourcentage peut être entièrement absorbé par l'arrondi. Une hausse de 3 % sur 59 € donne 60,77 €, et le prix le plus proche sur une échelle de 10 reste 59 € : le prix ne bouge pas.
L'option _Ne jamais laisser l'arrondi annuler l'augmentation_ corrige ce cas en poussant au cran suivant tant que le résultat reste inférieur ou égal au prix de départ. Elle n'agit que sur les pourcentages positifs. Pour une baisse de prix, décochez-la.
## Arrondi sur le prix TTC ou sur le prix stocké
WooCommerce stocke les prix hors taxes ou taxes comprises selon le réglage _Saisir les prix avec la taxe_. Si votre boutique stocke des prix HT et affiche des prix TTC, arrondir la valeur stockée ne produit rien de lisible côté client : 49,17 € HT affiché avec 20 % de TVA donne 59,00 € TTC, mais 49,00 € HT donne 58,80 € TTC.
Le réglage **Arrondir sur** propose deux comportements :
- **Le prix vu par le client, TTC** : le plugin convertit le prix stocké en TTC via la classe de taxe du produit, applique l'arrondi sur cette valeur, puis reconvertit en HT avec quatre décimales avant enregistrement. C'est le réglage par défaut.
- **Le prix stocké** : l'arrondi s'applique directement à la valeur enregistrée en base, sans conversion.
Si votre boutique stocke déjà des prix TTC, ou si la taxe est désactivée, les deux réglages produisent le même résultat. Les produits marqués comme non taxables ne subissent aucune conversion.
## Construire une campagne
### Carte Augmentation
- **Nom de la campagne** : facultatif, un nom horodaté est généré si vous le laissez vide.
- **Pourcentage** : positif pour une hausse, négatif pour une baisse. Deux décimales acceptées.
- **Prix promo** : voir la section dédiée plus bas.
- **Ignorer un produit si la variation réelle dépasse X %** : le garde-fou principal. Avec une consigne à 3 % et un plafond à 6 %, tout produit dont l'arrondi produirait une hausse supérieure à 6 % est écarté de la campagne, avec le motif indiqué dans l'aperçu. Laissez le champ vide pour désactiver ce contrôle.
### Carte Périmètre
- **Catégories à inclure** : laissez vide pour traiter tout le catalogue. Les sous-catégories des catégories choisies sont automatiquement incluses.
- **Catégories à exclure** : prioritaire sur l'inclusion, sous-catégories comprises.
- **Étiquettes** : restreint aux produits portant l'une des étiquettes cochées.
- **Types de produits** : simple, variable, externe, groupé. Cocher variable traite les déclinaisons, pas le produit parent qui n'a pas de prix propre.
- **État des produits** : publié, brouillon, privé, en attente. Pour les déclinaisons, c'est l'état du produit parent qui est évalué.
- **Prix de base compris entre** : deux bornes facultatives évaluées sur le prix de base enregistré.
- **Ignorer les produits actuellement en promotion** : écarte les produits ayant un prix promo renseigné.
- **Exclure ces ID ou UGS** et **Limiter à ces ID ou UGS** : listes libres séparées par des virgules, des espaces ou des retours à la ligne. Les UGS sont résolues en identifiants au moment de la sélection. Sur un produit variable, indiquer l'ID du parent couvre toutes ses déclinaisons.
### Carte Arrondi
Par défaut, la campagne utilise les règles globales, rappelées en haut de la carte. Cochez _Remplacer les règles globales pour cette campagne_ pour ajuster le sens, la garantie d'augmentation et la base de calcul uniquement pour cette campagne. Les paliers eux-mêmes restent ceux des réglages globaux.
La case _Lors d'une annulation, ignorer les produits modifiés après l'application_ détermine le comportement du rollback. Laissez-la cochée dans la grande majorité des cas.
## Les prix promotionnels
Quatre modes sont proposés. Ils ne s'appliquent qu'aux produits ayant réellement un prix promo renseigné.
- **Recalculer en conservant le même taux de remise** : le mode par défaut. Un produit à 100 € affiché 80 € conserve sa remise de 20 % après la hausse. Le nouveau prix promo passe lui aussi par l'arrondi.
- **Appliquer le même pourcentage** : le prix promo subit exactement le même traitement que le prix de base.
- **Ne pas toucher** : le prix promo reste strictement inchangé. La remise affichée augmente donc mécaniquement.
- **Supprimer le prix promotionnel** : la promo est retirée, ainsi que ses dates de début et de fin.
Dans tous les cas, si le nouveau prix promo devait atteindre ou dépasser le nouveau prix de base, il est supprimé automatiquement pour éviter une incohérence côté boutique.
## Aperçu et application
Le bouton **Prévisualiser les nouveaux prix** déclenche trois opérations successives, avec une barre de progression :
1. Sélection des produits correspondant au périmètre et enregistrement de la file d'attente.
2. Calcul du nouveau prix de chaque ligne, par lots.
3. Affichage du tableau et des statistiques.
Le tableau affiche, pour chaque ligne, le produit avec un lien vers sa fiche, l'UGS, le prix actuel, le nouveau prix, la variation réelle en pourcentage, le prix promo avant et après, et le statut. Les lignes écartées portent le statut _skipped_ et un motif : produit gratuit, aucun prix de base, prix déjà à la valeur cible, ou variation supérieure à la limite autorisée.
Le bouton **Charger 50 lignes de plus** pagine le tableau. **Télécharger le CSV** exporte l'intégralité de la campagne, y compris les lignes écartées, ce qui permet une relecture hors ligne ou une validation par un tiers.
Tant que vous n'avez pas cliqué sur **Appliquer au catalogue**, aucun prix n'a été modifié. La campagne reste consultable dans l'historique avec le statut _Prête à appliquer_, et peut être appliquée plus tard.
L'application se fait par lots via l'API produit de WooCommerce, ce qui garantit la mise à jour du prix affiché, de la table de recherche interne et des caches. Après chaque lot, les produits variables concernés sont resynchronisés pour que les prix minimum et maximum affichés en boutique restent corrects.
## Annuler une campagne
Depuis l'écran Historique, une campagne au statut _Appliquée_ propose un bouton **Annuler**. La restauration se fait par lots et remet chaque produit à son prix de base et à son prix promo d'origine.
Si l'option de sécurité était active à la création de la campagne, chaque produit est vérifié avant restauration : si son prix actuel ne correspond plus au prix appliqué par la campagne, la ligne est laissée de côté avec un message explicite. Cela évite d'écraser une modification manuelle réalisée entre-temps.
Supprimer une campagne efface également ses données de restauration. Une campagne appliquée puis supprimée ne peut plus être annulée.
## Lignes de commande WP-CLI
Quatre commandes couvrent le même parcours sans passer par le navigateur, ce qui convient aux très gros catalogues et aux scripts de déploiement.
```
wp df-inflation preview --percent=3 --categories=15,22
wp df-inflation apply --campaign=12 --yes
wp df-inflation apply --percent=4.5 --types=simple,variable --sale=ratio --yes
wp df-inflation revert --campaign=12 --yes
wp df-inflation campaigns
```
Options disponibles : `--percent`, `--name`, `--categories`, `--types`, `--sale` (keep, percent, ratio ou remove), `--campaign` et `--yes`. La commande _preview_ construit la campagne et affiche les statistiques sans rien écrire, elle renvoie l'identifiant à réutiliser avec _apply_.
## Réglages globaux
- **Paliers de prix** : le tableau décrit plus haut, avec les boutons d'ajout, de retrait et les préréglages.
- **Sens** et **Garantie de l'augmentation** : valeurs par défaut proposées à chaque nouvelle campagne.
- **Arrondir sur** : base de calcul TTC ou prix stocké.
- **Taille des lots** : nombre de produits traités par requête, de 1 à 200. La valeur par défaut de 25 convient à la plupart des hébergements. Descendez à 10 en cas de délai d'exécution dépassé, montez à 50 ou 100 sur un serveur dédié.
- **Désinstallation** : si la case est cochée, la suppression de l'extension efface les deux tables et les options. Décochée, les données de campagne survivent à une réinstallation.
## Personnalisation pour les développeurs
Deux filtres permettent d'intervenir sur le comportement du moteur.
```
// Ajuster un prix arrondi.
add_filter( 'df_inflation_rounded_price', function ( $result, $raw_price, $tier ) {
return $result;
}, 10, 3 );
// Modifier la liste des produits sélectionnés par une campagne.
add_filter( 'df_inflation_scope_rows', function ( $rows, $filters ) {
return $rows;
}, 10, 2 );
```
Toutes les actions d'administration exigent la capacité `manage_woocommerce`. Les requêtes AJAX sont protégées par un nonce et vérifient cette capacité côté serveur.
## Dépannage
### Aucun produit ne correspond au périmètre
Vérifiez que les types de produits cochés correspondent bien à votre catalogue et que les produits ciblés possèdent un prix de base renseigné. Un produit variable dont seules les déclinaisons portent un prix nécessite de cocher le type variable, pas le type simple.
### La barre de progression se bloque
Réduisez la taille des lots dans les réglages, puis relancez. Un lot de 10 produits suffit sur les hébergements les plus contraints. La console du navigateur affiche le détail de la requête en échec.
### Les nouveaux prix ne s'affichent pas en boutique
Videz le cache de votre extension de mise en cache et le cache serveur. Le plugin purge les transients WooCommerce des produits modifiés, mais n'a pas la main sur un cache de page tiers.
### Les prix des produits variables sont incohérents
Les prix minimum et maximum affichés sur la fiche parent proviennent d'une synchronisation WooCommerce. Le plugin la déclenche après chaque lot. Si un écart persiste, l'outil WooCommerce, État, Outils, Vider les transients des produits force un recalcul complet.
### Une variation réelle très supérieure à la consigne
C'est le comportement attendu sur une échelle grossière. Renseignez le champ de plafond par campagne pour écarter ces produits, ou ajoutez un palier plus fin sur la tranche de prix concernée.
## Désinstallation
Désactiver l'extension ne supprime rien : les campagnes et les données de restauration restent en base. La suppression complète depuis la liste des extensions déclenche le nettoyage uniquement si l'option correspondante a été cochée dans les réglages avant la suppression.
---
### DataFirefly Inventory Forecasting — Guide complet
_Source :_
> Guide complet d'installation, de configuration et d'utilisation de DataFirefly Inventory Forecasting pour prédire vos ruptures de stock, générer des bons de commande fournisseur et déclencher des alertes automatiques sur WooCommerce.
## Vue d'ensemble
DataFirefly Inventory Forecasting est un plugin WooCommerce de prévision de stock, de génération automatique de bons de commande fournisseur et d'alertes de rupture. Il transforme votre back-office WordPress en poste de pilotage supply chain, sans passer par un SaaS externe et sans frais par SKU.
Le plugin s'appuie sur un algorithme **Holt-Winters multiplicatif** qui décompose vos ventes historiques en deux composantes : une tendance estimée par régression linéaire sur une moyenne mobile de sept jours, et une saisonnalité calculée comme indice mensuel multiplicatif. Les prévisions à 30, 60 et 90 jours sont ensuite comparées au stock actuel pour produire un point de commande, une quantité de réapprovisionnement (tenant compte de la MOQ et de la taille de lot) et une estimation de date de rupture.
**Positionnement.** Inventory Forecasting est conçu comme une alternative auto-hébergée à Veeqo, Cin7 ou Lokad. Il vise les catalogues de 100 à quelques milliers de SKU, avec ou sans historique saisonnier stable.
## Prérequis et installation
### Prérequis techniques
- WordPress 6.4 ou supérieur
- WooCommerce 8.0 ou supérieur
- PHP 8.1 ou supérieur
- MySQL 5.7 ou MariaDB 10.3 minimum
- WP-Cron activé (ou remplacé par un cron système déclenchant wp-cron.php)
### Installation
1. Téléchargez l'archive ZIP depuis votre compte client sur datafirefly.com.
2. Dans WordPress, allez dans _Extensions → Ajouter une extension → Téléverser une extension_.
3. Sélectionnez le ZIP puis cliquez sur _Installer maintenant_.
4. Activez l'extension. À l'activation, le plugin crée sept tables préfixées `wp_dfif_`, déclare la compatibilité HPOS et planifie quatre tâches cron quotidiennes.
**Vérification post-installation.** Un nouveau menu _Inventory Forecasting_ apparaît dans la sidebar admin, avec l'icône graphique. Ouvrez le tableau de bord pour vérifier que les compteurs KPI s'affichent bien à zéro.
### Premier démarrage : reconstruire l'historique
Le plugin a besoin de connaître vos ventes passées pour calibrer la tendance et les indices saisonniers. À la première utilisation, cliquez sur _Reconstruire l'historique_ depuis le tableau de bord. Cette action parcourt les commandes complétées de la fenêtre configurée (365 jours par défaut) et agrège les quantités vendues par produit et par jour dans la table `wp_dfif_sales_daily`.
Sur un catalogue de quelques centaines de produits et 12 mois d'historique, l'opération prend une à cinq minutes. Elle est paginée par blocs de 100 commandes et compatible HPOS.
## Concepts fondamentaux
### Tendance et saisonnalité
À chaque cycle de prévision, le plugin construit pour chaque produit une série journalière lissée par moyenne mobile de sept jours. Une régression linéaire sur cette série donne la **tendance** (pente et ordonnée à l'origine). Séparément, les indices **saisonniers** mensuels sont calculés comme le rapport entre les ventes de chaque mois calendaire et la moyenne annuelle, avec un plancher à 0,3 et un plafond à 3,0 pour absorber les valeurs aberrantes.
La prévision à l'horizon H jours combine ensuite tendance et indice du mois cible : ventes_prévues = ventes_moyennes × (1 + tendance × H) × indice_saisonnier.
### Safety stock
Le safety stock est calculé selon la formule classique z × σ × √lead_time, où z est le quantile normal correspondant au niveau de service souhaité (1,645 pour 95 %, 2,326 pour 99 %), σ l'écart-type des ventes journalières et lead_time le délai de livraison du fournisseur en jours. Cette réserve absorbe les variations aléatoires de la demande pendant le réapprovisionnement.
### Reorder point et reorder quantity
Le **reorder point** est le seuil de stock déclenchant une commande. Il vaut ventes_moyennes × lead_time + safety_stock. En pratique, dès que le stock actuel descend sous ce seuil, une commande doit être passée pour éviter la rupture.
Le **reorder quantity** est la quantité à commander. Elle est arrondie au multiple de la taille de lot (pack size), puis remontée à la MOQ (quantité minimale de commande du fournisseur) si nécessaire.
### Niveau de confiance
Chaque prévision est accompagnée d'un score de confiance de 0 à 100 %, calculé heuristiquement selon la longueur de l'historique disponible, la régularité des ventes et la présence de saisonnalité marquée. Une confiance inférieure à 40 % s'affiche en rouge et bascule automatiquement sur une prévision naïve (moyenne mobile) plus prudente.
## Gestion des fournisseurs
### Créer un fournisseur
Depuis le menu _Inventory Forecasting → Fournisseurs_, cliquez sur _Ajouter un fournisseur_. Renseignez au minimum le nom et l'e-mail (utilisé pour l'envoi des bons de commande). Les champs facultatifs sont : contact, téléphone, adresse postale, devise de facturation et notes internes.
### Associer un fournisseur à un produit
Sur la page d'édition d'un produit WooCommerce, une méta-boîte _Fournisseurs Inventory Forecasting_ apparaît dans la colonne principale. Elle permet d'ajouter un ou plusieurs fournisseurs pour ce produit, chacun avec ses propres paramètres :
- **Prix d'achat** hors taxes, utilisé sur la ligne de bon de commande
- **SKU fournisseur**, souvent différent du SKU interne, imprimé sur le PDF
- **Délai de livraison** en jours, entrant dans le calcul du reorder point
- **MOQ**, quantité minimale exigée par le fournisseur
- **Taille de lot**, incrément par lequel les quantités sont arrondies
- **Fournisseur principal**, coche radio qui désigne le fournisseur retenu par la génération automatique des bons de commande
**Multi-fournisseurs.** Un même produit peut être associé à plusieurs fournisseurs, par exemple un principal moins cher et un secondaire de repli. Seul le principal est utilisé par la génération automatique, mais vous pouvez basculer manuellement sur un autre depuis la page produit.
## Prévisions et horizons
La page _Inventory Forecasting → Prévisions_ liste tous les produits avec, pour chacun, la prévision à l'horizon sélectionné, le reorder point, la quantité à commander, la date de rupture estimée et le niveau de confiance.
### Filtres
- **Horizon** : 30, 60 ou 90 jours (les trois sont calculés en parallèle par le cron)
- **Sévérité** : critique (rupture sous 7 jours), warning (rupture sous 14 jours), normal
- **Recherche** : par titre de produit ou SKU
### Recalcul manuel
Le bouton _Recalculer les prévisions_ du tableau de bord force un cycle immédiat sans attendre le cron de 2 h 30. Utile après un changement de paramètre (niveau de service, taille de fenêtre d'historique) ou après un import massif de commandes.
## Bons de commande fournisseur
### Cycle de vie d'un bon de commande
1. **Brouillon** : créé mais non envoyé, éditable
2. **Envoyé** : PDF généré et expédié au fournisseur par e-mail
3. **Partiellement reçu** : au moins une ligne mais pas toutes les quantités reçues
4. **Reçu** : toutes les quantités enregistrées
5. **Annulé** : commande abandonnée avant réception
### Génération manuelle
Depuis _Inventory Forecasting → Bons de commande_, le bouton _Générer depuis les prévisions_ parcourt les produits sous reorder point, les groupe par fournisseur principal et crée un bon de commande en brouillon par fournisseur. Vous pouvez ensuite éditer les quantités, ajouter ou retirer des lignes, puis envoyer.
### Génération automatique
Le cron de 4 h peut générer automatiquement les bons de commande, avec ou sans envoi immédiat. Cette option est **désactivée par défaut**. Une fois activée dans les réglages, deux modes sont possibles : création en brouillon (envoi manuel après validation) ou envoi immédiat.
**Recommandation.** Laissez l'envoi automatique désactivé pendant au moins deux semaines après l'installation. Vérifiez la pertinence des prévisions avant de faire confiance à l'automatisme complet, sinon vous risquez de commander trop tôt ou en trop grande quantité.
### PDF natif
Le PDF est généré par un moteur PHP pur embarqué (police Helvetica, format A4, environ 250 lignes de code). Il inclut l'en-tête de votre société, les coordonnées du fournisseur, le tableau des lignes avec SKU fournisseur et prix d'achat, le total HT, et un pied de page personnalisable. Aucune dépendance à Dompdf, TCPDF ou mPDF n'est requise.
### Réception de la marchandise
Sur la vue détail d'un bon de commande, chaque ligne dispose d'un champ _Quantité reçue_. Saisir la valeur reçue met à jour le stock WooCommerce du produit du _delta_ par rapport à la valeur précédente. Cette logique évite les double-comptages si vous corrigez une réception a posteriori.
## Alertes de rupture
Le plugin détecte quotidiennement quatre types de situations et attribue à chacune un niveau de sévérité.
### Types d'alertes
- **IMMINENT** : rupture prévue sous 7 jours (paramétrable), sévérité critique
- **WARNING** : rupture prévue sous 14 jours (paramétrable), sévérité warning
- **OVERSTOCK** : couverture stock supérieure à 180 jours, sévérité info
- **REORDER** : stock passé sous le reorder point, sévérité warning
### Cycle de vie
Une alerte est créée avec le statut _active_. Lors du cycle suivant, si la situation persiste, elle est marquée _pending_recheck_ ; si elle a disparu, elle passe à _resolved_ avec un horodatage. Ce mécanisme évite le spam d'alertes répétitives.
### Notifications e-mail
Un digest quotidien est envoyé à l'adresse configurée dans les réglages, listant les alertes critiques et warning nouvelles. Le contenu de l'e-mail est un tableau HTML sobre, filtrable par sévérité.
## Réglages
La page _Inventory Forecasting → Réglages_ regroupe quatre sections.
### Prévisions
- **Fenêtre d'historique** : 365 jours par défaut. Plus la fenêtre est longue, plus la saisonnalité est robuste, mais le poids de la table sales_daily augmente.
- **Horizons de prévision** : liste séparée par virgules, 30, 60, 90 par défaut. Vous pouvez ajouter par exemple 14 ou 180.
- **Niveau de service** : 95 % par défaut. Traduit en z = 1,645 par inverse normale. Passez à 99 % (z = 2,326) pour du stock critique, à 90 % (z = 1,282) pour du non stratégique.
### Alertes
- **Jours d'anticipation warning** : 14 par défaut
- **Jours d'anticipation critique** : 7 par défaut
- **E-mail destinataire du digest quotidien**
### Bons de commande
- **Génération automatique activée** : décochée par défaut
- **Préfixe de numérotation** : PO- par défaut, produit des identifiants comme PO-2026-00042
- **Devise** : héritée de WooCommerce, surchargeable par fournisseur
### Société
Coordonnées de votre entreprise imprimées sur l'en-tête des PDF de bons de commande : raison sociale, adresse, SIREN ou numéro de TVA, e-mail, téléphone, logo.
## Tâches cron
Quatre tâches sont planifiées automatiquement à l'activation du plugin, sur le fuseau horaire du site.
- `02:00` — **Reconstruction de l'historique** : agrège les commandes de la veille dans la table sales_daily. Léger, quelques secondes.
- `02:30` — **Calcul des prévisions** : recalcule tendance, saisonnalité et reorder points. Plus lourd, une à cinq minutes selon le catalogue.
- `03:00` — **Détection des alertes** : crée et résout les alertes selon les seuils. Rapide.
- `04:00` — **Génération automatique des bons de commande** : ne s'exécute que si l'option est activée dans les réglages.
**WP-Cron.** Par défaut, WP-Cron ne s'exécute que sur un événement visiteur. Sur un site à faible trafic, cela peut retarder les tâches nocturnes. Configurez de préférence un cron système appelant wp-cron.php toutes les 15 minutes, ou désactivez WP-Cron dans wp-config.php et pilotez-le entièrement en cron système.
## REST API
Le plugin expose plusieurs routes REST sous le namespace `dfif/v1`. Toutes exigent la capacité `manage_woocommerce` et le nonce WordPress `wp_rest`.
```
POST /wp-json/dfif/v1/run-forecast
POST /wp-json/dfif/v1/rebuild-history
POST /wp-json/dfif/v1/detect-alerts
POST /wp-json/dfif/v1/generate-pos
POST /wp-json/dfif/v1/send-po/{id}
POST /wp-json/dfif/v1/po/{id}/items/{item_id}/receive
GET /wp-json/dfif/v1/stats
```
Ces routes sont utilisées en interne par les boutons du tableau de bord (via wp.apiFetch avec en-tête X-WP-Nonce) et peuvent également être appelées depuis n'importe quel client authentifié via cookies WordPress ou clés d'application.
### Hooks WordPress
Les principales étapes du plugin émettent des actions et filtres que vous pouvez intercepter :
```
do_action('dfif_forecast_calculated', $product_id, $forecast_data);
do_action('dfif_purchase_order_created', $po_id, $supplier_id);
do_action('dfif_purchase_order_sent', $po_id);
do_action('dfif_alert_triggered', $alert_id, $alert_type);
apply_filters('dfif_reorder_qty', $qty, $product_id, $supplier_id);
apply_filters('dfif_pdf_company_info', $info);
```
## Dépannage
### Les prévisions restent à zéro
Vérifiez que la reconstruction d'historique a bien été exécutée et que la table sales_daily contient des lignes. Si vous n'avez pas de commandes complétées ou en cours de traitement dans la fenêtre configurée, le plugin ne peut rien prévoir. Vérifiez aussi que WooCommerce est bien activé.
### Les prévisions semblent incohérentes
Deux causes fréquentes : un historique trop court (moins de 30 jours, le plugin bascule sur une prévision naïve) ou une saisonnalité extrême non représentative (Black Friday isolé). Regardez le niveau de confiance affiché : sous 40 %, la prévision doit être prise avec précaution.
### Le PDF n'est pas généré
Vérifiez que le répertoire `wp-content/uploads/dfif-po/` est accessible en écriture. Le plugin y dépose les PDF avant envoi. Un fichier .htaccess est déposé automatiquement pour empêcher l'accès public direct.
### L'e-mail n'est pas envoyé
Le plugin utilise wp_mail, qui est parfois défaillant sur certains hébergeurs. Installez un plugin SMTP (WP Mail SMTP, FluentSMTP) et configurez un service de délivrabilité (Postmark, SendGrid, Mailjet, Brevo). Vérifiez aussi que l'e-mail du fournisseur est bien saisi et valide.
### Le cron ne tourne pas
Utilisez le plugin WP Crontrol pour lister les hooks planifiés et voir leur prochaine exécution. Les quatre hooks sont préfixés `dfif_`. Si vous ne les voyez pas, désactivez et réactivez Inventory Forecasting.
## Désinstallation
À la désactivation, les crons sont dé-planifiés mais les tables et données sont conservées. À la désinstallation complète via _Extensions → Supprimer_, deux comportements sont possibles selon l'option `dfif_delete_data_on_uninstall` dans les réglages :
- **Décochée par défaut** : les tables sont conservées, vous pouvez réinstaller sans perdre l'historique.
- **Cochée** : les sept tables et le répertoire `wp-content/uploads/dfif-po/` sont supprimés.
## FAQ
### Puis-je utiliser le plugin sur un catalogue variable (variations de produit) ?
Oui. Les prévisions et les bons de commande fonctionnent au niveau de la variation individuelle. Chaque variation peut avoir ses propres fournisseurs et ses propres paramètres.
### Le plugin est-il compatible multisite ?
Oui, mais chaque site du réseau gère son propre catalogue, ses propres fournisseurs et ses propres prévisions. Il n'y a pas de mutualisation cross-site.
### Puis-je exporter les données ?
Toutes les tables sont accessibles via SQL standard. Un export CSV natif est prévu dans une version ultérieure. En attendant, un simple `SELECT INTO OUTFILE` ou un plugin comme WP All Export suffit.
### Le plugin bloque-t-il l'admin si le cron n'a pas tourné ?
Non. Le plugin fonctionne toujours, simplement les prévisions affichées peuvent être datées de plusieurs jours. Un badge _Dernier cron_ sur le tableau de bord indique la fraîcheur des données.
### Comment se comporte le plugin sur un catalogue de plusieurs milliers de SKU ?
La reconstruction d'historique et le calcul des prévisions restent linéaires en nombre de produits actifs. Sur 5 000 SKU avec 12 mois d'historique, comptez 10 à 30 minutes de traitement nocturne selon la puissance du serveur. Aucun impact sur les performances front-office : tous les calculs sont asynchrones.
---
### DataFirefly Live Counters
_Source :_
> DataFirefly Live Counters affiche sur votre site WordPress/WooCommerce des compteurs animés (clients, commandes, abonnés sociaux, KPI maison) qui restent justes même quand le site entier est servi depuis un full-page…
DataFirefly Live Counters affiche sur votre site WordPress/WooCommerce des compteurs animés (clients, commandes, abonnés sociaux, KPI maison) qui restent justes même quand le site entier est servi depuis un full-page cache comme LiteSpeed Cache ou WP Rocket.
## Installation et démarrage
### Prérequis
- WordPress 6.2 ou supérieur (testé sur 6.7).
- PHP 8.1 ou supérieur.
- WooCommerce 7.0+ recommandé pour les compteurs boutique. Sans WooCommerce, les compteurs sociaux et KPI personnalisés restent pleinement fonctionnels.
- Polylang ou WPML facultatif pour les libellés multilingues.
### Installation
1. Téléchargez le fichier `dflivecounters.zip` depuis votre compte DataFirefly.
2. Dans WordPress, allez dans **Extensions → Ajouter une extension → Téléverser une extension**.
3. Choisissez le zip puis cliquez sur **Installer maintenant**.
4. Activez l'extension. Un nouvel élément **Live Counters** apparaît dans le menu WooCommerce (ou Réglages si WooCommerce n'est pas installé).
### Premier affichage en 30 secondes
Placez ce shortcode dans n'importe quelle page ou article :
```
[dflivecounters]
```
Au premier chargement, une grille de quatre compteurs apparaît avec une animation count-up. Les chiffres sont calculés depuis votre catalogue WooCommerce et mis en cache.
## Réglages généraux
Allez dans **WooCommerce → Live Counters**. La page est organisée en quatre cartes, suivie d'un aperçu en direct et d'un bouton de vidage de cache.
### Carte « Affichage & cache »
- **Style** : `Cartes`, `Minimaliste`, `Dégradé`.
- **Colonnes** : entre 1 et 6. Responsive : 2 colonnes sur mobile, 1 sur très petit écran.
- **Couleur d'accent** : utilisée pour icônes, chiffres (cartes) et fond (dégradé). Défaut `#0f172a`.
- **Durée animation (ms)** : 200 à 8 000. 0 désactive l'animation.
- **Cache compteurs (min)** : 60 par défaut.
- **Cache réseaux sociaux (min)** : 360 par défaut (APIs sociales rate-limited).
- **Abréger les grands nombres** : affiche `12,4 k` au lieu de `12 400`.
- **Ajouter « + » aux compteurs cumulatifs**.
- **Pré-chauffer le cache automatiquement (cron)** : Action Scheduler en priorité, WP-Cron en fallback.
### Statuts de commande comptés
- **Statuts comptés (clients, commandes, articles, pays)** : par défaut `Processing` et `Completed`.
- **Statuts « expédiés »** : utilisé uniquement pour _Produits expédiés_. Par défaut `Completed`.
### Date de création
Le compteur _Années d'expérience_ calcule sa valeur à partir de la date renseignée dans **« Date de création »**.
### Vider et régénérer le cache
Le bouton **« ↻ Vider et régénérer le cache maintenant »** supprime tous les transients du plugin et déclenche un warm-up immédiat. Toute modification des réglages vide automatiquement le cache et reprogramme le warm-up.
## Compteurs WooCommerce
### Liste des compteurs disponibles
- **Clients satisfaits** (`customers`) : adresses email distinctes ayant passé une commande dans un statut compté.
- **Produits expédiés** (`shipped`) : somme des quantités d'articles dans les commandes « expédié ».
- **Commandes traitées** (`orders`).
- **Articles vendus** (`items_sold`) : somme des quantités sur toutes les lignes.
- **Produits au catalogue** (`products`).
- **Avis clients** (`reviews`) : avis approuvés.
- **Pays livrés** (`countries`).
- **Années d'expérience** (`years`) : à partir de la date de création.
### Activer et personnaliser un compteur
Dans le tableau **« Compteurs boutique »**, cochez _Actif_ et optionnellement :
- Renseignez un **libellé personnalisé**.
- Choisissez une **période** (voir section dédiée).
- Ajoutez un **offset** pour intégrer un historique antérieur (par exemple 1 200 clients hérités d'une précédente boutique).
- Définissez un **objectif** qui activera la barre de progression.
### Compatibilité HPOS
Le plugin détecte automatiquement HPOS (High-Performance Order Storage) ou le stockage legacy (CPT). Les requêtes sont écrites en deux versions optimisées. La compatibilité HPOS et Cart/Checkout Blocks est déclarée via le hook `before_woocommerce_init`.
## Compteurs sociaux et KPI personnalisés
### Réseaux sociaux supportés
- **Facebook** et **Instagram** — récupération automatique via l'API Meta Graph v19 (Instagram en compte Business ou Creator uniquement).
- **TikTok**, **X (Twitter)**, **LinkedIn**, **YouTube** — saisie manuelle.
TikTok, X et LinkedIn n'exposent pas de compteur d'abonnés via une API publique fiable, d'où la saisie manuelle.
### Configurer Facebook ou Instagram via l'API Meta Graph
1. Créez une application sur [developers.facebook.com](https://developers.facebook.com).
2. Générez un jeton d'accès longue durée avec la permission `pages_read_engagement` (Facebook) ou `instagram_basic` + `pages_show_list` (Instagram).
3. Récupérez l'ID de la Page Facebook ou de l'IG Business.
4. Dans la carte « Réseaux sociaux », cochez **« Récupérer via l'API »**, collez l'ID dans _ID objet_ et le jeton dans _Jeton d'accès_.
Si l'appel API échoue (jeton expiré, rate limit), le plugin conserve la dernière valeur connue. Le champ « manuel » sert de fallback ultime.
### Compteurs KPI personnalisés
Dans la carte **« Compteurs personnalisés (KPI) »**, cliquez sur **« + Ajouter un compteur »**, puis renseignez : icône (users, award, heart, leaf, download…), libellé, valeur, préfixe optionnel (« $ », « + »), suffixe optionnel (« %, h, M »), objectif optionnel.
## Périodes, objectifs et tendance
### Périodes par compteur
Compteurs qui agrègent dans le temps (`customers`, `shipped`, `orders`, `items_sold`, `reviews`, `countries`) peuvent être restreints :
- **Total** : comportement par défaut.
- **Cette année** : depuis le 1er janvier.
- **Ce mois** : depuis le 1er du mois.
- **30 derniers jours** : fenêtre glissante.
L'effet « 124 commandes ce mois-ci » est souvent plus engageant que « 9 421 commandes ».
### Objectifs et barre de progression
Renseigner un objectif dans la colonne **« Objectif (0 = aucun) »** active automatiquement une barre sous le compteur, animée en même temps que le count-up, jusqu'à `min(100 %, valeur / objectif)`. Disponible aussi sur les compteurs sociaux et personnalisés.
### Indicateur de tendance ▲/▼
Une puce colorée apparaît à côté du chiffre :
- ▲ vert si la valeur a augmenté depuis le snapshot précédent.
- ▼ rouge si elle a baissé.
- Aucune puce si la variation est nulle ou si l'historique est insuffisant.
Le pourcentage est calculé sur une fenêtre glissante de 7 jours par défaut, modifiable via le filtre `dflc_trend_window`. Les baselines sont stockés dans une option WordPress unique (`dflc_trend`).
**Patience attendue.** Sur un site neuf, la puce de tendance n'apparaîtra qu'après l'écoulement de la fenêtre (par défaut 7 jours).
## Affichage : bloc, widget, shortcode
### Bloc Gutenberg
Dans l'éditeur de bloc, cherchez **« DataFirefly Live Counters »** (catégorie « Widgets »). Le panneau d'inspection permet de configurer colonnes, style et liste des compteurs à afficher. L'aperçu utilise `ServerSideRender`, identique au rendu front.
### Widget classique
Dans **Apparence → Widgets**, ajoutez **« DataFirefly Live Counters »**. Champs : titre, colonnes (0 à 6), style, clés (liste séparée par des virgules ou vide = tous les compteurs activés).
### Shortcode
```
[dflivecounters]
[dflivecounters keys="customers,orders,reviews" columns="3"]
[dflivecounters keys="social_facebook,social_instagram" columns="2" style="gradient"]
[dflivecounters keys="custom_0,custom_1" style="minimal"]
```
Attributs supportés : `keys` (string, liste de clés), `columns` (int 1-6), `style` (`cards`, `minimal`, `gradient`).
### Liste des clés disponibles
CompteurCléClients`customers`Produits expédiés`shipped`Commandes traitées`orders`Articles vendus`items_sold`Produits au catalogue`products`Avis clients`reviews`Pays livrés`countries`Années d'expérience`years`Réseaux sociaux`social_facebook`, `social_instagram`, `social_tiktok`, `social_twitter`, `social_linkedin`, `social_youtube`Compteurs personnalisés`custom_0`, `custom_1`, etc.
### Insertion dans un thème (PHP)
```
echo do_shortcode( '[dflivecounters keys="customers,orders" columns="2"]' );
```
## Architecture du cache
### Le problème
Quand un cache de page (LiteSpeed, WP Rocket, NGINX micro-cache, Varnish, Cloudflare APO) sert une HTML pré-générée, tout chiffre rendu en PHP est figé. La réponse classique — désactiver le cache sur ces pages — dégrade gravement les performances.
### Le principe : séparer structure et valeurs
- **Structure cacheable** : grille, icônes, libellés et emplacements vides, rendus côté serveur, parfaitement cacheables.
- **Valeurs non cacheables** : récupérées par `fetch()` vers une route REST dédiée, avec un en-tête `Cache-Control` court.
Le visiteur reçoit instantanément le HTML caché, puis les chiffres se remplissent en JavaScript avec une animation count-up.
### Transient cache + warm-up
La route REST ne fait jamais de requête SQL lourde pendant la visite. Elle lit des transients WordPress, pré-chauffés par Action Scheduler (job `dflc_warm_cache`) ou par WP-Cron en fallback.
### Stale-while-revalidate
Si un transient expire pile entre deux warm-ups :
1. La **dernière valeur connue** est lue depuis l'option persistante `dflc_lastgood` (qui survit à l'expiration du transient) et renvoyée immédiatement.
2. Un job de refresh asynchrone est programmé.
3. Un verrou court (2 minutes) empêche d'empiler plusieurs refresh concurrents.
Le cold start réel n'arrive qu'au tout premier affichage après installation.
### Sécurité de l'endpoint REST
- Lecture publique uniquement.
- Whitelist des clés : seules les clés correspondant à des compteurs réellement configurés sont acceptées.
- En-tête `Cache-Control: public, max-age=...` dimensionné sur le TTL des compteurs.
**Attention.** Si votre CDN ignore le `Cache-Control` de la route REST et la cache agressivement, les chiffres seront figés au niveau du CDN. Excluez `/wp-json/dflivecounters/v1/counters` de votre cache CDN si vous observez ce comportement.
## API développeur
Cinq filtres PHP permettent d'étendre le plugin sans toucher au cœur.
### dflc_counter_definitions
Ajouter, réordonner ou masquer des compteurs.
```
add_filter( 'dflc_counter_definitions', static function ( array $items, array $settings ) {
$items[] = array(
'key' => 'newsletter_subscribers',
'label' => 'Abonnés newsletter',
'icon' => 'heart',
'suffix' => '+',
'prefix' => '',
'abbreviate' => true,
'goal' => 5000,
);
return $items;
}, 10, 2 );
```
### dflc_compute
Court-circuite le calcul. Retourner un entier prend la main, `null` laisse le core gérer.
```
add_filter( 'dflc_compute', static function ( $pre, string $key, array $settings ) {
if ( 'newsletter_subscribers' === $key ) {
return (int) get_option( 'my_newsletter_count', 0 );
}
return $pre;
}, 10, 3 );
```
### dflc_counter_value
Filtre la valeur finale juste avant l'envoi au front.
```
add_filter( 'dflc_counter_value', static function ( int $value, string $key ) {
if ( 'customers' === $key && $value < 1000 ) {
return 1000;
}
return $value;
}, 10, 2 );
```
### dflc_payload
Filtre la totalité du payload REST.
```
add_filter( 'dflc_payload', static function ( array $payload, array $only, bool $force ) {
foreach ( $payload as &$item ) {
$item['emoji'] = '🎉';
}
return $payload;
}, 10, 3 );
```
### dflc_trend_window
Modifie la fenêtre glissante de tendance. Valeur en secondes, défaut `7 * DAY_IN_SECONDS`.
```
add_filter( 'dflc_trend_window', static fn() => 30 * DAY_IN_SECONDS );
```
### Recette : compteur Mailchimp
```
add_filter( 'dflc_counter_definitions', static function ( array $items ) {
$items[] = array(
'key' => 'mailchimp_subs', 'label' => 'Abonnés newsletter',
'icon' => 'heart', 'suffix' => '+', 'prefix' => '',
'abbreviate' => true, 'goal' => 0,
);
return $items;
} );
add_filter( 'dflc_compute', static function ( $pre, string $key ) {
if ( 'mailchimp_subs' !== $key ) {
return $pre;
}
$response = wp_remote_get( 'https://us1.api.mailchimp.com/3.0/lists/LIST_ID', array(
'headers' => array( 'Authorization' => 'Bearer ' . MAILCHIMP_API_KEY ),
) );
if ( is_wp_error( $response ) ) {
return 0;
}
$body = json_decode( wp_remote_retrieve_body( $response ), true );
return (int) ( $body['stats']['member_count'] ?? 0 );
}, 10, 2 );
```
## Dépannage
### Les chiffres ne s'animent pas
- Vérifier que le script `dflc-front.js` se charge (onglet réseau).
- Vérifier que la route REST `/wp-json/dflivecounters/v1/counters` répond en 200 avec un JSON valide.
- Tester avec un autre thème.
### Les chiffres affichent toujours « — »
- L'appel REST a échoué. Vérifier la console JS.
- La route REST peut être bloquée par une extension de sécurité.
### Les chiffres ne se mettent pas à jour
- Vérifier que **« Pré-chauffer le cache automatiquement »** est activé.
- Sur sites à faible trafic, envisager un vrai cron système au lieu de WP-Cron.
- Forcer un rafraîchissement via le bouton **« ↻ Vider et régénérer le cache maintenant »**.
### L'appel API Meta retourne 0
- Vérifier la validité du jeton sur [Access Token Debugger](https://developers.facebook.com/tools/debug/accesstoken/).
- Vérifier que le compte Instagram est bien Business ou Creator.
### Notice WP 6.7 « _load_textdomain_just_in_time »
Corrigée depuis la version 1.1.1.
---
### DataFirefly Live Counters — Guide complet
_Source :_
> DataFirefly Live Counters affiche sur votre boutique PrestaShop un widget de compteurs animés alimenté en partie automatiquement par votre base (clients actifs, commandes expédiées, produits, pays livrés) et en partie…
DataFirefly Live Counters affiche sur votre boutique PrestaShop un widget de compteurs animés alimenté en partie automatiquement par votre base (clients actifs, commandes expédiées, produits, pays livrés) et en partie par des valeurs que vous saisissez (avis, satisfaction, abonnés réseaux sociaux…). Le widget se positionne nativement sur plusieurs hooks (accueil, footer, panier, colonnes) ou n'importe où dans votre thème via la balise Smarty `widget name="dflivecounters"`. Cette documentation couvre l'installation, la configuration des 17 compteurs disponibles, les 5 thèmes visuels, la stratégie de cache, le branchement des APIs Facebook et Instagram, le refresh AJAX live et la résolution des principaux problèmes.
## Installation
1. Téléchargez l'archive `dflivecounters.zip` depuis votre compte DataFirefly.
2. Back-office PrestaShop → **Modules** → **Téléverser un module** → envoyez le ZIP.
3. À l'installation, le module enregistre 7 hooks d'affichage et initialise une dizaine de variables de configuration. **Aucune table SQL n'est créée** : tous les réglages sont stockés dans `ps_configuration`.
4. Le module charge son autoloader PSR-4 standalone — aucun `composer install` requis sur le serveur.
Compatible PrestaShop 8.0 à 9.x, PHP 8.1+. Multi-boutique natif, multilingue via Polylang Pro ou le système natif PrestaShop. Compatible mode démo.
## Apparence du widget
Ouvrez **Modules → DataFirefly Live Counters → Configurer**. La première section regroupe les réglages d'apparence globale.
### Thème visuel
Cinq thèmes prêts à l'emploi :
- **Minimal** : sobriété maximale, fond blanc, idéal pour les thèmes épurés.
- **Glassmorphism** : verre dépoli avec `backdrop-blur`, fond légèrement teinté de la couleur primaire. Très tendance.
- **Gradient** : fond en dégradé pleine largeur de la couleur primaire vers une teinte sombre. Fort impact visuel, texte blanc.
- **Card** : cartes blanches élevées avec ombre douce et hover. Classique premium.
- **Flat** : fond légèrement teinté de la couleur primaire, valeurs colorées en primaire.
### Titre et sous-titre
Affichés au-dessus du grid de compteurs. Laissez vides pour masquer l'en-tête (utile dans le footer où le contexte est déjà donné par l'environnement).
### Couleurs
Trois couleurs principales pilotent l'ensemble du widget via des variables CSS (`--dflc-primary`, `--dflc-text`, `--dflc-bg`) :
- **Couleur principale** : icônes par défaut, accent du thème Flat, dégradé du thème Gradient.
- **Couleur du texte** : titre, sous-titre, valeurs et labels.
- **Couleur de fond** : fond de la section (ignoré sur les thèmes Glassmorphism et Gradient qui appliquent leur propre fond).
Chaque compteur peut aussi avoir **sa propre couleur d'icône** (champ « Icon color » dans la ligne du compteur), ce qui permet par exemple de garder les icônes Facebook et Instagram dans leurs couleurs de marque tout en conservant la cohérence du reste.
### Colonnes
Deux réglages indépendants :
- **Colonnes desktop** : 1 à 6 (par défaut 4).
- **Colonnes mobile** : 1 à 3 (par défaut 2). Le breakpoint est 768 px.
### Durée de l'animation CountUp
Durée en millisecondes pendant laquelle les chiffres défilent de 0 vers leur valeur cible (par défaut 2 000 ms). Une courbe d'ease-out cubique est appliquée pour une décélération douce. Mettez `0` pour désactiver l'animation et afficher la valeur finale tout de suite.
Sur les appareils en `prefers-reduced-motion: reduce`, l'animation est automatiquement désactivée, quelle que soit la durée configurée.
### Refresh AJAX live (optionnel)
Lorsqu'activé, le widget interroge périodiquement un endpoint JSON pour mettre à jour les valeurs sans rechargement de page. Deux paramètres :
- **Live refresh** : ON/OFF.
- **Intervalle** : en secondes, minimum 30 (par défaut 60). Réglage forcé à 30 si vous saisissez moins.
L'endpoint répond avec un `Cache-Control: public, max-age=30` qui permet à votre CDN d'absorber le trafic. L'animation de transition d'une valeur à l'autre démarre depuis la valeur précédemment affichée, pas depuis zéro — l'effet visuel est plus naturel.
### « Date from »
Date de référence utilisée par deux compteurs :
- **Commandes expédiées** : ne comptabilise que les commandes créées après cette date (filtre `WHERE date_add >= ?`).
- **Années d'expertise** : calcule automatiquement le nombre d'années écoulées depuis cette date jusqu'à aujourd'hui.
## Catalogue des compteurs
17 compteurs sont disponibles, répartis en trois groupes selon leur mode de calcul.
### Compteurs automatiques (5)
Ces compteurs lisent en temps réel les données de votre PrestaShop. Aucune saisie nécessaire.
- **Clients** : clients actifs (`active = 1 AND deleted = 0`), scopés au shop context. TTL 15 min.
- **Commandes expédiées** : commandes dont au moins un historique de statut figure parmi les états sélectionnés (champ « Order states counted as shipped »). Si aucun état n'est sélectionné, le module utilise automatiquement le flag `shipped = 1` de la table `ps_order_state`. TTL 15 min.
- **Commandes traitées** : toutes les commandes dont l'état courant a le flag `logable = 1` (le flag canonique PrestaShop pour les commandes qui comptent dans les statistiques). Exclut donc les annulations et remboursements. TTL 15 min.
- **Produits** : produits actifs et visibles du catalogue, scopés au shop context. TTL 30 min.
- **Pays livrés** : nombre de pays distincts ayant reçu au moins une commande (`COUNT(DISTINCT id_country)` sur la table `ps_address` jointe à `ps_orders`). TTL 1 h.
### Compteurs hybrides (4)
Ces compteurs tentent d'abord un calcul automatique, puis basculent sur la valeur manuelle que vous avez saisie en backup.
- **Années d'expertise** : calculé depuis la date « Date from » ; valeur manuelle si vous préférez fixer un chiffre arrondi (ex : « 12 » au lieu de « 11 »). TTL 24 h.
- **Articles publiés** : auto-détection des tables des principaux modules de blog PrestaShop (`smart_blog_post`, `prestablog_news`, `psblog_post`, `ph_simpleblog_post`) via `INFORMATION_SCHEMA`. Si aucune correspondance, utilisez la valeur manuelle. TTL 24 h.
- **Abonnés Facebook** : appel à la Graph API Facebook avec un Page Access Token longue durée. Fallback manuel si non configuré ou si l'API échoue. TTL 1 h.
- **Abonnés Instagram** : appel à la Graph API Instagram (compte Business ou Creator requis). Fallback manuel. TTL 1 h.
### Compteurs manuels (8)
Ces compteurs affichent simplement la valeur que vous saisissez. Idéaux pour les métriques que PrestaShop ne peut pas calculer ou que vous voulez maîtriser totalement.
- **Avis clients** : nombre d'avis (depuis Trustpilot, Avis Vérifiés, Google, etc.).
- **Satisfaction** : taux de satisfaction. Astuce : utilisez un suffixe « % » et une valeur 0–100.
- **CO₂ économisé** : kg d'émissions évitées. Astuce : suffixe « kg ».
- **Récompenses** : prix, certifications, distinctions.
- **Heures de support** : suffixe « h ».
- **Abonnés TikTok** : la Display API TikTok nécessite un OAuth par utilisateur impraticable pour un widget public. Saisie manuelle.
- **Abonnés X (Twitter)** : l'API X v2 est payante. Saisie manuelle.
- **Abonnés LinkedIn** : LinkedIn Organization Followers requiert une approbation Marketing Developer Platform. Saisie manuelle.
## Configuration par compteur
Chaque ligne de compteur dans l'admin propose les mêmes réglages :
- **Activé** (ON/OFF) : seuls les compteurs activés apparaissent dans le widget. L'ordre d'affichage suit celui de l'admin.
- **Libellé personnalisé** : remplace le libellé par défaut. Laissez vide pour utiliser le libellé natif traduit dans la langue du visiteur.
- **Valeur (manuel)** : pour les compteurs manuels et le fallback des hybrides.
- **Offset** : entier ajouté à la valeur calculée. Pratique pour partir d'un chiffre flatteur sans toucher à votre base de données. Pour les compteurs « Clients » et « Commandes expédiées » par exemple, vous pouvez ajouter respectivement +500 et +2 000 si votre boutique vient d'être migrée. Le label « Current live » à côté du champ Offset vous indique la valeur brute calculée par PrestaShop, sans offset.
- **Préfixe / Suffixe** : 4 et 6 caractères respectivement. Le préfixe et le suffixe restent fixes même pendant l'animation.
- **Décimales** : 0 à 3. Le formatage utilise `Intl.NumberFormat` avec la locale du visiteur (séparateurs de milliers et virgule décimale localisés).
- **Couleur d'icône** : remplace la couleur primaire pour cette icône uniquement.
Les libellés personnalisés sont stockés en configuration **par boutique et par langue** via le système natif PrestaShop. Vous pouvez donc avoir « Clients heureux » en français et « Happy customers » en anglais — ou même un libellé différent par boutique multi-shop.
## États de commande « expédiés »
Le compteur « Commandes expédiées » s'appuie par défaut sur l'historique des statuts. Le réglage **Order states counted as shipped** vous laisse choisir précisément les états qui comptent. Sur une installation PrestaShop standard, ce sont les états ID 4 (Expédiée) et 5 (Livrée) qui sont préconfigurés.
Si votre boutique utilise des statuts personnalisés (ex : « Remise en main propre », « Click & Collect retiré »), pensez à les ajouter à la sélection — sinon ces commandes ne seront pas comptabilisées.
Si aucun état n'est sélectionné, le module bascule sur un fallback qui interroge le flag `shipped = 1` de la table `ps_order_state`. Cette approche est plus permissive et capture la plupart des configurations courantes.
## Configurer Facebook
1. Rendez-vous sur [developers.facebook.com](https://developers.facebook.com/) et créez une App de type « Business ».
2. Dans la section **Graph API Explorer**, sélectionnez votre App puis votre Page Facebook.
3. Générez un **Page Access Token** avec les scopes `pages_read_engagement` et `pages_show_list`.
4. Échangez ce token court (1 h) contre un **token longue durée** (60 jours) via l'endpoint `/oauth/access_token?grant_type=fb_exchange_token`.
5. Récupérez votre **Page ID** dans les paramètres de votre Page (section « Transparence de la Page » ou directement dans le Graph API Explorer).
6. Renseignez les deux champs dans la configuration Live Counters et sauvez. Le compteur Facebook se met à jour à la sauvegarde.
Le token longue durée expire au bout de 60 jours. Au-delà, le compteur bascule sur le fallback manuel. Mettez-vous un rappel pour renouveler le token avant expiration.
## Configurer Instagram
1. Votre compte Instagram doit être en mode **Business** ou **Creator**. Les comptes personnels ne sont pas supportés par la Graph API.
2. Liez votre compte Instagram à une Page Facebook (paramètres de la Page → Instagram).
3. Dans le Graph API Explorer, interrogez `/me/accounts` avec votre Page Access Token pour récupérer le **Instagram User ID** associé (champ `instagram_business_account`).
4. Utilisez le même token Facebook longue durée pour l'API Instagram.
5. Renseignez l'IG User ID et le token dans la configuration Live Counters.
## Stratégie de cache
Le cache fonctionne sur deux niveaux pour garantir un TTFB constant même sous trafic.
### Cache par compteur
Chaque compteur a son propre TTL :
- 15 minutes : Clients, Commandes expédiées, Commandes traitées.
- 30 minutes : Produits.
- 1 heure : Pays livrés, Facebook, Instagram.
- 24 heures : Années d'expertise, Articles publiés, et tous les compteurs manuels.
Le cache utilise d'abord la couche `Cache` native PrestaShop (memcached, APCu ou Redis si configurés sur votre serveur), puis un fallback filesystem dans `var/cache/dflivecounters/`. Cela garantit que les TTL sont respectés même si la couche native est en mode « no-cache ».
### Cache du widget rendu
Le HTML complet du widget est lui-même mis en cache pendant **60 secondes** par langue et par hook (`dflc_widget_LANG_HASH`). Cette deuxième couche absorbe la majorité du trafic même lorsque les compteurs internes sont déjà à jour.
### Purge automatique
- La sauvegarde de la configuration purge automatiquement tous les caches du module.
- Un bouton **Purger le cache** est disponible dans le panneau d'administration pour invalidation manuelle.
- La désinstallation du module purge le cache automatiquement.
Le panneau d'administration affiche les statistiques en direct : nombre d'entrées en cache, taille en KB, chemin du dossier. Utile pour vérifier que le cache filesystem est bien actif.
## Placer le widget dans votre thème
Le module enregistre 7 hooks à l'installation :
- `displayHome` — page d'accueil
- `displayFooter` — pied de page
- `displayFooterBefore` — juste avant le footer (PS 8+)
- `displayLeftColumn` / `displayRightColumn` — colonnes latérales
- `displayShoppingCartFooter` — page panier, sous le résumé
- `actionFrontControllerSetMedia` — enregistre les assets CSS/JS
Vous pouvez ajouter ou retirer des hooks depuis **Conception → Positions** dans le back-office.
### Placement libre via Smarty
Pour placer le widget à un endroit précis de votre thème (ex : sur la fiche produit, sous le titre d'une catégorie), utilisez la balise widget Smarty :
```
{widget name="dflivecounters"}
```
Le widget implémente l'interface `WidgetInterface` native PrestaShop, ce qui le rend appelable depuis n'importe quel template `.tpl` de votre thème.
## Personnaliser le template du widget
Le template Smarty principal est `views/templates/hook/widget.tpl`. Pour le surcharger sans modifier le module (afin de préserver les mises à jour), recopiez-le dans votre thème, dans le dossier `themes/votre-theme/modules/dflivecounters/views/templates/hook/widget.tpl`.
Variables Smarty exposées :
- `{$dflc.counters}` — tableau de chaque compteur avec les clés `key`, `label`, `value`, `icon`, `prefix`, `suffix`, `decimals`, `icon_color`
- `{$dflc.theme}` — slug du thème (`minimal`, `glassmorphism`, `gradient`, `card`, `flat`)
- `{$dflc.title}`, `{$dflc.subtitle}`
- `{$dflc.primary_color}`, `{$dflc.text_color}`, `{$dflc.bg_color}`
- `{$dflc.cols_desktop}`, `{$dflc.cols_mobile}`
- `{$dflc.hook}` — nom du hook d'origine (utile pour adapter le rendu selon le placement)
## Endpoint AJAX
Le contrôleur front `refresh` expose une URL JSON utilisable par le live refresh ou par toute intégration tierce :
```
index.php?fc=module&module=dflivecounters&controller=refresh
```
La réponse JSON contient un booléen `success`, un `timestamp` Unix, et un objet `counters` où chaque clé est l'identifiant du compteur (customers, shipped_orders, facebook, instagram, etc.) et chaque valeur est le nombre courant. Le contenu reflète les compteurs activés au moment de l'appel, avec les offsets appliqués. La réponse est servie avec `Cache-Control: public, max-age=30`.
## Accessibilité
Le widget est conçu pour respecter les recommandations WCAG 2.2 AA :
- Structure sémantique : `section`, `header`, `ul role="list"`, `li`.
- Toutes les icônes SVG ont `aria-hidden="true"` (décoratives).
- Respect strict de `prefers-reduced-motion: reduce` : animation désactivée, valeur finale affichée tout de suite.
- Contrastes : les couleurs par défaut respectent un ratio supérieur à 4.5:1 sur les thèmes Minimal et Card. Vérifiez vos couleurs personnalisées avec un outil comme axe DevTools.
- Format des nombres : `font-variant-numeric: tabular-nums` pour une largeur de chiffre constante (évite le « saut » visuel pendant l'animation).
## RGPD
Le widget est conçu pour ne nécessiter aucune mention de consentement :
- Aucun cookie déposé côté visiteur.
- Aucun script tiers chargé (pas de Facebook Pixel, pas de Google Tag Manager).
- Les appels API Facebook et Instagram sont effectués **côté serveur en PHP**, jamais depuis le navigateur. Aucune donnée du visiteur n'est transmise à Meta.
- Aucune donnée personnelle collectée ou stockée par le module.
## Compatibilité et notes techniques
- PrestaShop 8.0 à 9.x, PHP 8.1+.
- Multi-boutique natif : toutes les requêtes SQL sont scopées au `Shop::getContextListShopID()`.
- Multilingue : Polylang Pro ou système multilingue natif PrestaShop.
- Aucune table SQL créée : configuration stockée dans `ps_configuration`.
- Autoloader PSR-4 standalone (pas de `composer install` sur le serveur).
- WidgetInterface PrestaShop natif : usable via `{widget name="dflivecounters"}`.
- Poids des assets : 3 KB JS, 2 KB CSS. Aucune requête externe par défaut.
- Conforme aux conventions PrestaShop 9 AJAX : `$this->module->l()` au lieu de `$this->l()`, controller front dédié pour le refresh, jamais d'override de `ajaxRender`.
## FAQ et résolution des problèmes
**Le widget ne s'affiche pas sur la page d'accueil.** Vérifiez que le module est bien greffé au hook `displayHome` dans **Conception → Positions**. Vérifiez aussi qu'au moins un compteur est activé : sans compteur activé, le widget ne retourne rien (silencieusement).
**Le compteur Facebook reste à zéro.** Plusieurs causes possibles : Page ID incorrect, token expiré (durée de vie 60 jours), scope manquant (`pages_read_engagement` est requis). Purgez le cache du module et rechargez la configuration : la valeur retournée par Graph API apparaîtra à côté du label « Current live ».
**Le compteur Commandes expédiées est trop bas.** Vérifiez la sélection « Order states counted as shipped » : seuls les états sélectionnés sont comptés. Si vous voulez inclure des statuts personnalisés (ex : « Click & Collect retiré »), ajoutez-les à la sélection.
**Les chiffres semblent figés et ne reflètent pas mon trafic réel.** C'est le cache qui fait son travail. Le TTL par défaut va de 15 minutes (clients, commandes) à 24 heures (compteurs statiques). Utilisez le bouton **Purger le cache** pour invalider manuellement. Pour un rafraîchissement automatique, activez le mode **Live refresh**.
**L'animation CountUp ne se déclenche pas.** Le widget utilise IntersectionObserver et se déclenche au moment où il entre dans le viewport. Si le widget est déjà visible au chargement de la page (ex : placé tout en haut), l'animation se lance immédiatement. Si elle reste figée à zéro : vérifiez la console JavaScript de votre navigateur, un autre module pourrait casser le bundle JS.
**Le widget casse mon Lighthouse / Core Web Vitals.** Avec un placement bas de page (footer) et le cache de 60 s sur le HTML rendu, l'impact CLS / LCP est négligeable. Si vous constatez un problème, vérifiez que vous n'avez pas activé le **Live refresh** avec un intervalle trop court (l'AJAX se déclenche pendant que Lighthouse mesure). Pour un audit propre, désactivez le live refresh.
**Sur multi-boutique, est-ce que les compteurs sont scopés par boutique ?** Oui. Toutes les requêtes SQL utilisent `Shop::getContextListShopID()`. En mode « toutes les boutiques », les compteurs cumulent ; en mode « une boutique », ils ne comptent que celle-ci. Les libellés et la valeur manuelle sont également par-boutique-par-langue.
**Comment ajouter un nouveau compteur personnalisé ?** Créez une classe qui étend `Df/LiveCounters/Counter/AbstractCounter` (ou `ManualCounter` pour un compteur 100 % manuel), implémentez `getKey()`, `getDefaultLabel()` et `getValue()`, puis ajoutez l'instance au tableau d'instances du `CounterRegistry`. Pour ne pas perdre votre code à la prochaine mise à jour, créez un mini-module compagnon qui injecte votre compteur dans le registry via un hook custom — n'hésitez pas à nous contacter pour un exemple.
---
### DataFirefly Live Shopping — Guide complet
_Source :_
> Présentation Le module DataFirefly Live Shopping (dflive) transforme votre boutique PrestaShop en plateforme de vente vidéo en direct. Vous diffusez un live, vous épinglez des produits en temps réel, vous…
## Présentation
Le module **DataFirefly Live Shopping** (`dflive`) transforme votre boutique PrestaShop en plateforme de **vente vidéo en direct**. Vous diffusez un live, vous épinglez des produits en temps réel, vous lancez des offres flash, vos clients ajoutent au panier sans quitter la diffusion, et la session reste accessible en replay. Tout fonctionne sur votre boutique : aucune plateforme de live shopping tierce, aucun abonnement récurrent.
Trois piliers : une **vidéo native** (HLS, MP4 ou embed), un **Studio temps réel** intégré au back-office pour piloter le live, et une **couche shopping** (épinglage produit, offres flash, panier natif, chat, réactions, preuve sociale).
## Compatibilité
- PrestaShop 8.0 à 9.x
- PHP 7.4 à 8.3
- Mono-boutique et multi-boutique
- Multilingue (5 langues incluses : FR, EN, ES, DE, IT)
- Aucune dépendance (ni Composer ni framework) ; `hls.js` est embarqué dans le module
- Compatible hébergement mutualisé (synchronisation par polling AJAX, sans WebSocket ni SFU)
## Prérequis
Le module gère la **lecture** de la vidéo et toute la couche shopping, mais c'est vous qui fournissez la **source vidéo**. Selon le mode choisi :
- **HLS** : un flux `.m3u8` servi par votre propre serveur HLS, par Mux ou par Cloudflare Stream, alimenté par un encodeur comme OBS.
- **MP4** : une URL pointant vers un fichier `.mp4` accessible publiquement.
- **Embed** : un live YouTube, Twitch ou Vimeo (URL ou code d'intégration).
HTTPS est recommandé : la lecture automatique et le plein écran se comportent mieux sur une boutique servie en HTTPS, ce dont disposent déjà la quasi-totalité des boutiques en production.
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** puis sélectionnez le fichier `dflive.zip`.
3. Une fois installé, ouvrez le menu **Vendre > Live Shopping**.
À l'installation, le module crée ses tables (sessions, produits de session, messages, évènements, présence, rappels), enregistre les onglets sous **Vendre**, ajoute les routes `/live` et `/live/{id}-{slug}`, et active le widget de page d'accueil.
## Créer un live
Depuis **Vendre > Live Shopping**, cliquez sur **Ajouter**. Le formulaire est organisé en onglets :
### Général
- **Titre** et **description** du live (multilingues).
- **Animateur** : nom affiché comme hôte dans le chat et sous la vidéo.
- **Date programmée** : déclenche le compte à rebours côté spectateur.
- **Statut** : programmé, en direct ou terminé.
- **Image de couverture** : affichée avant le live et dans les listes.
### Vidéo
- **Type de vidéo** : HLS, MP4 ou embed.
- **Source vidéo** : l'URL `.m3u8`, l'URL `.mp4` ou l'URL / code embed selon le type.
- **URL de replay** (optionnelle) : par exemple l'enregistrement VOD de votre serveur HLS, servi après le live.
### Produits
Associez les produits qui seront présentés pendant le live grâce au sélecteur à recherche AJAX. Ces produits alimentent le rail côté spectateur et deviennent épinglables depuis le Studio.
### Options & SEO
Activez ou non le chat, le chat invité, les réactions et la preuve sociale pour cette session, et renseignez le titre et la description SEO de la page du live.
## Diffuser le flux
Pour un live en HLS, le principe est le suivant :
1. Configurez votre encodeur (OBS, par exemple) pour diffuser vers votre serveur HLS, Mux ou Cloudflare Stream.
2. Récupérez l'URL `.m3u8` de sortie et collez-la dans le champ **Source vidéo** de la session.
3. Lancez la diffusion depuis votre encodeur, puis ouvrez le Studio et cliquez sur **Lancer le live**.
Le module ne vous enferme dans aucune infrastructure : vous choisissez votre chaîne de diffusion (auto-hébergée ou cloud) et vous collez simplement l'URL. Pour un test rapide, un fichier MP4 ou un embed YouTube / Twitch suffit.
## Le Studio (régie)
Le Studio est la salle de contrôle intégrée au back-office. Ouvrez-le depuis le bouton **Studio** de la liste des lives.
- **Lancer / Terminer le live** : bascule le statut de la session. À la fin, les offres flash en cours sont automatiquement nettoyées.
- **Épingler un produit** : sa carte apparaît immédiatement en surimpression chez les spectateurs. Épingler un produit désépingle automatiquement le précédent.
- **Offre flash** : saisissez une réduction (par exemple `20%` ou `10€`). Le module crée un `SpecificPrice` à la volée et le prix recalculé s'affiche instantanément côté spectateurs. Le bouton dédié permet de stopper l'offre.
- **Annonce** : diffuse un message hôte épinglé dans le chat.
- **Modération** : masquer, afficher ou épingler n'importe quel message du chat.
- **Statistiques live** : nombre de spectateurs et de réactions en temps réel.
Le Studio pousse des évènements (épinglage, offre, annonce, changement de statut) qui sont récupérés par les spectateurs au cycle de polling suivant. L'intervalle est configurable dans les réglages du module.
## Côté spectateur
La page d'un live (`/live/{id}-{slug}`) présente :
- Le **lecteur vidéo** avec un bandeau « EN DIRECT » et le nombre de spectateurs.
- La **carte du produit épinglé** en surimpression, avec bouton d'ajout au panier.
- Le **rail de produits** du live, chacun ajoutable au panier PrestaShop natif d'un clic.
- Le **chat** (clients et, si activé, invités) avec anti-flood, messages hôte et réactions cœurs animées.
- Les **toasts de preuve sociale** « Quelqu'un vient d'ajouter… » lors des ajouts au panier.
Pour une session **programmée**, le spectateur voit un compte à rebours et peut s'inscrire par e-mail pour être prévenu du démarrage. Après le live, la session bascule en **replay** et reste accessible.
## Réglages du module
La page de configuration regroupe les réglages globaux, notamment :
- **Intervalle de polling** (3 000 ms par défaut) : fréquence de rafraîchissement du chat et des évènements.
- **Chat activé** et **chat invité** : autorise le chat et, le cas échéant, la participation des visiteurs non connectés.
- **Réactions** et **preuve sociale** : active les cœurs et les toasts d'ajout au panier.
- **Délai de présence** : durée au-delà de laquelle un spectateur inactif n'est plus compté.
- **Longueur maximale d'un message** et **anti-flood** : encadrent le chat.
- **Widget d'accueil** et **nombre de lives affichés** : pilotent l'encart de la page d'accueil.
## Page liste et widget d'accueil
La page `/live` liste les lives **en cours**, **à venir** et les **replays**. Le widget de page d'accueil met en avant les sessions actives et programmées, dans la limite configurée.
## FAQ et dépannage
### La vidéo ne se lance pas
Vérifiez le type de vidéo et la source. Pour un flux HLS, assurez-vous que l'URL `.m3u8` est accessible publiquement et que votre encodeur diffuse bien. Pour un embed, vérifiez que l'URL YouTube, Twitch ou Vimeo est valide.
### Le prix de l'offre flash ne change pas chez les spectateurs
L'offre est appliquée via un `SpecificPrice` créé à la volée et propagée au cycle de polling suivant. Vérifiez l'intervalle de polling et que l'offre n'a pas déjà été stoppée. Les offres en cours sont nettoyées automatiquement à la fin du live.
### Le chat n'apparaît pas ou refuse mes messages
Contrôlez que le chat est activé pour la session et globalement. Le chat invité doit être activé pour autoriser les visiteurs non connectés. L'anti-flood impose un délai minimal entre deux messages.
### Le compte à rebours ne s'affiche pas
Le compte à rebours n'apparaît que pour les sessions au statut **programmé** dont la date est dans le futur. Vérifiez le statut et la date programmée.
### Le module fonctionne-t-il sur hébergement mutualisé ?
Oui. La synchronisation temps réel utilise du polling AJAX, sans serveur WebSocket ni SFU, ce qui garantit la compatibilité avec les hébergements mutualisés courants.
---
### DataFirefly Loyalty — Programme de fidélité Shopware 6
_Source :_
> Installation, configuration et utilisation de DataFirefly Loyalty : points, paliers, conversion en bons d'achat et dépannage.
## Présentation
DataFirefly Loyalty ajoute un programme de fidélité complet à Shopware 6 : vos clients gagnent des points à chaque commande, progressent dans des paliers avec multiplicateurs et convertissent leurs points en bons d'achat basés sur les promotions natives de Shopware. L'extension fonctionne sur Shopware 6.5, 6.6 et 6.7 avec un seul et même ZIP, sans aucune compilation.
## Installation
### Depuis l'administration
1. Rendez-vous dans **Extensions > Mes extensions**.
2. Cliquez sur **Téléverser une extension** et sélectionnez le fichier `DfLoyalty-1.0.0.zip`.
3. Cliquez sur **Installer**, puis activez l'extension.
### En ligne de commande
```
bin/console plugin:refresh
bin/console plugin:install --activate DfLoyalty
bin/console cache:clear
```
L'installation crée deux tables dédiées : `df_loyalty_account` (une ligne par client) et `df_loyalty_transaction` (le registre de toutes les opérations de points).
Aucun build JavaScript n'est nécessaire : l'extension ne contient pas de module d'administration compilé, ce qui garantit la compatibilité avec les trois branches 6.5, 6.6 et 6.7.
## Configuration
Ouvrez **Extensions > Mes extensions > DataFirefly Loyalty > Configurer**. Tous les réglages sont disponibles par canal de vente : vous pouvez activer le programme sur une boutique uniquement, ou appliquer des taux différents selon les canaux.
### Attribution des points
- **Activer le programme** : interrupteur général. Désactivé, la page compte client renvoie une erreur 404 et aucun point n'est attribué.
- **Déclencheur d'attribution** : _Paiement encaissé_ (statut de transaction `paid`, recommandé) ou _Commande terminée_ (statut de commande `completed`).
- **Points par unité monétaire** : nombre de points gagnés par euro dépensé. Défaut : 1.
- **Base de calcul** : montant TTC ou HT de la commande.
- **Inclure les frais de port** : par défaut, les frais de port sont exclus du calcul.
### Paliers
Trois paliers sont configurables, chacun avec un nom, un seuil et un multiplicateur. Les seuils s'appliquent aux **points cumulés à vie** (jamais décrémentés par une conversion), le multiplicateur s'applique à tous les gains futurs.
- **Palier 1** — défaut : Bronze, dès 0 point, multiplicateur ×1.0
- **Palier 2** — défaut : Silver, dès 500 points, multiplicateur ×1.25
- **Palier 3** — défaut : Gold, dès 2 000 points, multiplicateur ×1.5
Exemple : un client Silver (×1.25) qui passe une commande de 100 € TTC avec un taux de 1 point/€ gagne 125 points.
### Conversion en bons d'achat
- **Taux de conversion** : nombre de points nécessaires pour 1 € de bon. Défaut : 100 (100 points = 1,00 €).
- **Minimum de conversion** : nombre de points minimum pour lancer une conversion. Défaut : 200.
- **Pas de conversion** : les points se convertissent par multiples de cette valeur. Défaut : 100.
- **Validité des bons** : durée de vie du bon d'achat en jours. Défaut : 90.
## Fonctionnement côté client
Une entrée **Programme de fidélité** apparaît dans le menu du compte client. La page `/account/loyalty` affiche :
- le solde de points disponible et le total des points gagnés à vie ;
- le palier actuel avec une barre de progression vers le palier suivant ;
- le formulaire de conversion en bon d'achat ;
- l'historique des 50 dernières opérations (gains, conversions, annulations).
Lorsqu'un client convertit ses points, l'extension crée une **promotion Shopware native** : code unique de type `LOYAL-XXXXXXXX`, réservé à son compte, utilisable une seule fois, avec une remise fixe sur le panier. Le code s'applique dans le panier comme n'importe quel code promo. Vous retrouvez toutes les promotions générées dans **Marketing > Promotions**.
## Annulations et remboursements
Lorsqu'une commande passe au statut _Annulée_ ou que son paiement passe au statut _Remboursé_, les points gagnés sur cette commande sont automatiquement repris. L'opération est tracée dans l'historique du client sous le libellé « Annulés ». La reprise est idempotente : elle ne peut se produire qu'une seule fois par commande.
En version 1.0, un remboursement partiel n'est pas proratisé : c'est le passage du paiement complet au statut _Remboursé_ qui déclenche la reprise de la totalité des points de la commande.
## Sécurité et intégrité des données
- Le débit des points est atomique en base de données : deux conversions simultanées ne peuvent pas dépenser deux fois le même solde.
- Chaque opération est inscrite dans un registre en ajout seul, avec référence de commande, type, points signés et code du bon le cas échéant.
- La création du bon et l'écriture comptable sont exécutées dans la même transaction SQL : jamais de bon sans débit ni de débit sans bon.
## Dépannage
### Le lien Programme de fidélité n'apparaît pas dans le compte
L'extension injecte son lien via le bloc Twig `page_account_sidebar_link_orders`. Si votre thème personnalisé a supprimé ou renommé ce bloc, ajoutez le lien manuellement dans le template de la sidebar du compte, en pointant vers la route `frontend.account.dfloyalty.page`.
### Les points ne sont pas attribués
1. Vérifiez que le programme est activé pour le canal de vente concerné.
2. Vérifiez le déclencheur configuré : avec _Paiement encaissé_, la transaction doit atteindre le statut `paid` ; avec _Commande terminée_, la commande doit atteindre `completed`.
3. Videz le cache après un changement de configuration : `bin/console cache:clear`.
### Désinstallation
Lors de la désinstallation, Shopware propose de conserver les données. Si vous décochez cette option, les tables `df_loyalty_account` et `df_loyalty_transaction` sont supprimées définitivement — les promotions déjà générées restent en place car ce sont des promotions Shopware standards.
---
### DataFirefly Magic Link — Connexion sans mot de passe
_Source :_
> Présentation DataFirefly Magic Link ajoute une connexion sans mot de passe à votre boutique PrestaShop 8 ou 9. Le client saisit son adresse email sur la page de connexion, reçoit…
## Présentation
DataFirefly Magic Link ajoute une connexion sans mot de passe à votre boutique PrestaShop 8 ou 9. Le client saisit son adresse email sur la page de connexion, reçoit un lien sécurisé à usage unique, clique, confirme, et il est connecté. Le formulaire classique identifiant + mot de passe reste disponible : le magic link s'y ajoute, il ne le remplace pas.
Le module est entièrement autonome : aucune dépendance Composer, aucun service externe, aucun appel CDN. Tout fonctionne avec le système d'emails natif de PrestaShop.
## Prérequis
- PrestaShop 8.0 à 9.x
- PHP 8.1 ou supérieur
- MySQL 5.7+ ou MariaDB 10.3+
- Envoi d'emails fonctionnel (si vos emails de confirmation de commande partent, c'est bon)
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et sélectionnez le fichier `dfmagiclink.zip`.
3. PrestaShop installe le module, crée la table `ps_dfmagiclink_token` et enregistre les hooks automatiquement.
4. Cliquez sur **Configurer** pour ouvrir la page de réglages.
Dès l'installation, le formulaire magic link apparaît sous le formulaire de connexion standard de votre boutique, avec les réglages par défaut (liens valables 15 minutes, rate limiting activé).
## Configuration
Tous les réglages se trouvent dans **Modules > Gestionnaire de modules > DataFirefly Magic Link > Configurer**.
### Activer Magic Link
Interrupteur général. Sur _Non_, le formulaire disparaît du front et les liens existants cessent de fonctionner (message explicite pour le client).
### Afficher sur la page de connexion
Contrôle l'injection du formulaire sous le login standard. Vous pouvez désactiver l'affichage tout en gardant le module actif, par exemple si vous intégrez le formulaire ailleurs via votre thème.
### Durée de validité (minutes)
Durée pendant laquelle un lien reste utilisable après émission. Par défaut : **15 minutes**. Minimum 1, maximum 1440 (24 heures). Nous recommandons de rester entre 15 et 60 minutes : assez long pour la remise des emails, assez court pour limiter la fenêtre d'exposition.
### Max requêtes par IP / heure
Plafond de demandes de lien acceptées depuis une même adresse IP sur une heure glissante. Par défaut : **5**. Protège contre les tentatives d'abus automatisées.
### Max requêtes par email / heure
Plafond de demandes pour un même compte client sur une heure glissante. Par défaut : **3**. Au-delà, les demandes sont silencieusement ignorées (le message affiché reste générique pour ne pas divulguer l'état du compte).
Pendant vos tests, pensez à augmenter temporairement ces plafonds ou à vider la table `ps_dfmagiclink_token` — sinon vous atteindrez vite la limite de 3 demandes par heure sur votre propre compte.
### Redirection après connexion
Page vers laquelle le client est envoyé après une connexion réussie : **Mon compte** (défaut), **Historique des commandes** ou **Page d'accueil**.
### Statistiques et purge
Trois compteurs en haut de la page de configuration : tokens actifs, connexions des dernières 24 heures, liens émis sur 24 heures. Le bouton **Purger les tokens expirés** supprime les tokens périmés et les tokens consommés de plus de 24 heures.
## Parcours client
1. Le client ouvre la page de connexion et saisit son email dans le bloc « Connexion sans mot de passe ».
2. Le module vérifie le compte, génère un token de 256 bits, stocke son hash SHA-256 et envoie l'email. La réponse à l'écran est volontairement générique (« Si un compte existe pour cet email... ») pour empêcher l'énumération de comptes.
3. Le client clique sur le bouton dans l'email et arrive sur une **page de confirmation** autonome affichant son prénom.
4. Il clique sur « Me connecter » : le token est consommé, la session PrestaShop est ouverte, les hooks d'authentification natifs sont déclenchés, puis redirection vers la page configurée.
**Pourquoi une page de confirmation ?** Outlook Safe Links, Gmail et les antivirus d'entreprise visitent automatiquement les liens des emails reçus. Sans cette étape, ces scanners consommeraient le lien avant le client. Le token n'est consommé qu'au clic réel (requête POST), jamais à la simple visite (GET). C'est le pattern utilisé par Slack, Notion et Vercel.
## Emails
Les templates se trouvent dans `modules/dfmagiclink/mails//` (fr, en, es, de), en HTML (`magiclink.html`) et texte brut (`magiclink.txt`). La langue de l'email suit automatiquement la langue du compte client.
Variables disponibles : `{firstname}`, `{lastname}`, `{email}`, `{magic_link}`, `{ttl}`, `{shop_name}`, `{ip}`.
Pour personnaliser un template, copiez-le dans le dossier mails de votre thème (`themes/votre-theme/modules/dfmagiclink/mails/`) afin de préserver vos modifications lors des mises à jour du module.
## Sécurité
- **Tokens 256 bits** générés via `random_bytes()`, encodés en base64 URL-safe.
- **Hash SHA-256 en base** : le token brut n'existe que dans l'email. Une fuite de la table ne donne aucun lien exploitable.
- **Usage unique strict** : le token est marqué consommé avant l'ouverture de session.
- **Anti-énumération** : réponse identique que le compte existe ou non.
- **Rate limiting double** par IP et par compte.
- **CSRF** : la demande AJAX est protégée par le token de sécurité natif PrestaShop.
- **noindex** : toutes les pages du module portent l'en-tête `X-Robots-Tag: noindex, nofollow, noarchive`.
## Dépannage
### L'email n'arrive pas
Vérifiez dans l'ordre : le dossier spam du client (SPF/DKIM de votre domaine), le rate limit (compteur « liens émis » dans la config), et l'état actif du compte client. Vous pouvez confirmer l'émission côté serveur en consultant la table `ps_dfmagiclink_token` : une ligne avec `used_at` à NULL doit apparaître après chaque demande.
### « Ce lien a expiré ou a déjà été utilisé »
Le lien a dépassé sa durée de validité, ou a déjà servi. Le client peut simplement redemander un lien depuis la page de connexion.
### Le formulaire n'apparaît pas sur la page de connexion
Vérifiez que « Afficher sur la page de connexion » est activé, puis videz le cache (**Paramètres avancés > Performances > Vider le cache**). Vérifiez aussi que votre thème exécute bien le hook `displayCustomerLoginFormAfter` — c'est le cas des thèmes Classic et Hummingbird et de la quasi-totalité des thèmes du marché.
## Désinstallation
La désinstallation supprime la table `ps_dfmagiclink_token` et toutes les valeurs de configuration. Aucun compte client n'est modifié, aucun mot de passe touché. La connexion standard continue de fonctionner normalement.
---
### DataFirefly Marketplace — Guide complet
_Source :_
> Guide complet d'installation, de configuration et d'utilisation du module DataFirefly Marketplace pour PrestaShop 8 et 9.
## Présentation
DataFirefly Marketplace transforme votre boutique PrestaShop en place de marché multi-vendeurs. Des vendeurs tiers s'inscrivent, publient leurs produits et gèrent leurs commandes, pendant que vous orchestrez les commissions, les paiements et la conformité depuis le back-office.
Le module couvre l'ensemble du cycle : inscription et validation des vendeurs, espace vendeur complet, découpage réel des commandes en sous-commandes, moteur de commissions, paiement éclaté régulé (Mangopay et Stripe Connect), livraison par vendeur, conformité européenne (DSA, P2B, TVA), avis, messagerie, plans, litiges et analytics — le tout en cinq langues (FR, EN, ES, DE, IT).
## Compatibilité et prérequis
- PrestaShop 8.0, 8.1, 8.2 et 9.x
- PHP 8.1 ou supérieur
- Multiboutique et multilingue
- Pour le paiement éclaté : un compte Mangopay et/ou Stripe Connect (clés sandbox pour les tests, clés de production pour l'exploitation)
## Installation
1. Dans le back-office, allez dans **Modules > Module Manager**, cliquez sur **Téléverser un module** et sélectionnez l'archive `dfmarketplace.zip`.
2. L'installation crée les tables nécessaires, enregistre les hooks et ajoute le menu **Marketplace** dans le back-office, ainsi qu'un jeu de données de démonstration (plans et règles de commission).
3. Ouvrez **Marketplace > Configuration** pour paramétrer le module.
À la désinstallation, les tables de données sont **conservées** volontairement afin de ne pas perdre l'historique des vendeurs, commandes et commissions.
## Configuration initiale
Dans **Marketplace > Configuration**, renseignez les paramètres principaux :
- **Commission par défaut** : taux appliqué quand aucune règle plus spécifique n'existe (15 % par défaut).
- **Prestataire de paiement par défaut** : Mangopay ou Stripe Connect, puis les clés correspondantes.
- **Mode hybride** : autorise l'opérateur à vendre ses propres produits aux côtés des vendeurs tiers.
- **Facturer les commandes filles** : génère une facture dédiée pour chaque sous-commande vendeur.
- **État libérant l'escrow** : état de commande qui déclenche la libération des fonds vers les portefeuilles vendeurs (par exemple « Expédié » ou « Livré »).
- **Afficher l'identité vendeur (DSA)** : active le bloc d'identité du vendeur professionnel sur la vitrine.
- **Préfixe de facture de commission** et **préavis P2B (jours)**.
- **Validation automatique des produits** : si activée, les produits vendeurs sont publiés sans modération.
## Gestion des vendeurs
### Inscription
Un client connecté peut devenir vendeur via la page d'inscription du module (lien depuis son compte). Il renseigne le nom de la boutique, sa forme juridique et ses informations légales. Un e-mail d'accusé de réception lui est envoyé.
### Validation et KYC
Depuis **Marketplace > Vendeurs**, l'opérateur peut **approuver**, **suspendre** ou **rejeter** un vendeur. À l'approbation, l'onboarding PSP est déclenché et un e-mail de validation est envoyé. Le vendeur peut téléverser ses pièces KYC (Kbis, pièce d'identité, RIB) depuis son tableau de bord.
Conformément au règlement P2B, toute suspension s'accompagne d'un e-mail informant le vendeur, avec un exposé des motifs communiqué séparément.
## Espace vendeur
Le vendeur dispose d'un tableau de bord cloisonné : il n'accède qu'à ses propres données.
- **Tableau de bord** : solde du portefeuille, montant à reverser, nombre de produits, statut, commandes, grand-livre.
- **Mon profil** : logo, bannière, présentation, politiques de retour et de livraison, coordonnées publiques et champs DSA.
- **Mes produits** : création et édition de fiches complètes (photos, référence/SKU, EAN, état, prix et TVA, quantité, catégorie, poids et dimensions, descriptions).
- **Livraison** : sélection des transporteurs proposés et règles de frais (par prix ou poids, par zone, avec seuil de gratuité).
## Découpage des commandes
Lorsqu'une commande contient des produits de plusieurs vendeurs, le module la découpe en véritables **commandes filles** (une par vendeur). Chaque sous-commande possède ses propres frais de port, sa commission figée, sa facture et son crédit de portefeuille. Le détail logique est conservé pour la traçabilité, et le cloisonnement entre vendeurs est strict.
La facture de la commande parente suit le flux natif PrestaShop. Vérifiez, sur votre version, que le module de paiement ne fige pas une facture parente au montant complet avant le découpage.
## Commissions
Le moteur applique une cascade de règles, de la plus spécifique à la plus générale : **produit › vendeur › catégorie › global**, avec repli sur la commission par défaut. Les règles peuvent être en pourcentage, en montant fixe ou hybride, sur une base TTC ou HT.
Des **paliers de chiffre d'affaires mensuel** sont pris en charge : par exemple, 15 % jusqu'à 5 000 € de CA mensuel, puis 12 % au-delà. La commission est figée au moment de la commande et n'est jamais recalculée.
## Paiement éclaté, portefeuille et escrow
Les adaptateurs Mangopay et Stripe Connect encaissent les fonds de façon éclatée et les conservent en escrow. À l'atteinte de l'**état de commande configuré**, les fonds sont libérés vers les portefeuilles vendeurs.
### Reversements
Le vendeur demande un retrait depuis son tableau de bord. L'opérateur exécute les reversements depuis **Marketplace > Commissions & paiements** en un clic (virement SEPA via le PSP). Chaque mouvement est tracé dans le grand-livre du portefeuille.
### Webhooks
Configurez l'URL de webhook du module côté PSP (contrôleur `webhook`) afin de synchroniser les statuts de paiement. La signature est vérifiée à chaque appel.
## Livraison par vendeur
Chaque vendeur définit ses transporteurs et ses règles de frais. Lors de l'expédition, il saisit le transporteur et le numéro de suivi depuis son tableau de bord : un e-mail est envoyé à l'acheteur, et lorsque toutes les sous-commandes d'une commande sont expédiées, la commande parente passe automatiquement au statut « Expédié ».
## Conformité européenne
- **DSA** : l'identité du vendeur professionnel (raison sociale, numéro d'enregistrement, TVA, point de contact) est affichée sur sa vitrine.
- **Factures de commission** : générées automatiquement par période mensuelle, numérotées et archivées. L'opérateur peut lancer la génération en masse depuis **Marketplace > Factures de commission**.
- **P2B** : une page publie les conditions applicables aux vendeurs, les paramètres de classement et le préavis en cas de modification.
- **TVA « plateforme réputée fournisseur »** : un indicateur par vendeur est affiché et reporté sur la facture de commission.
Le module expose et affiche l'indicateur TVA, mais n'embarque pas de moteur de ventilation OSS. La ventilation fine de la TVA reste pilotée par la configuration des taxes de votre boutique.
## Avis, messagerie, plans, litiges et analytics
- **Avis** : les acheteurs ayant commandé chez un vendeur peuvent laisser un avis, modéré depuis **Marketplace > Avis**. La note moyenne est recalculée automatiquement.
- **Messagerie** : fils de discussion entre acheteur, vendeur et opérateur ; boîte de réception côté vendeur.
- **Plans vendeur** : Free, Pro et Premium par défaut, avec quotas de produits, taux de commission et accès analytics. Gérés depuis **Marketplace > Plans vendeur**.
- **Litiges et retours** : ouverts par sous-commande, résolus depuis **Marketplace > Litiges & retours**, avec remboursement éventuel répercuté sur le portefeuille du vendeur.
- **Analytics** : vue opérateur (GMV, taux de commission, meilleurs vendeurs) dans **Marketplace > Analytics**, et statistiques par vendeur (gated par le plan) dans son tableau de bord.
## Onglets du back-office
Le menu **Marketplace** regroupe : Vendeurs, Commandes vendeurs, Commissions & paiements, Factures de commission, Avis, Litiges & retours, Plans vendeur, Analytics et Configuration.
## FAQ et dépannage
### Les fonds ne sont pas libérés vers les vendeurs
Vérifiez que l'« État libérant l'escrow » est bien défini dans la configuration et que les vendeurs concernés ont terminé leur onboarding PSP (portefeuille créé).
### Un produit vendeur n'apparaît pas en boutique
Un produit reste masqué tant qu'il n'est pas approuvé. Vérifiez son statut de validation dans la liste des produits du vendeur, ou activez la validation automatique.
### Après mise à jour, un écran d'administration est en erreur
Videz le cache PrestaShop (dossier `var/cache`) après l'installation ou la mise à jour, puis rechargez le back-office.
---
### DataFirefly MCP Commerce — Guide complet
_Source :_
> Le module DataFirefly MCP Commerce transforme votre boutique PrestaShop en serveur MCP (Model Context Protocol) que les agents IA — ChatGPT, Claude, Claude Desktop, Claude Code, n8n — peuvent consommer…
Le module **DataFirefly MCP Commerce** transforme votre boutique PrestaShop en **serveur MCP** (Model Context Protocol) que les agents IA — ChatGPT, Claude, Claude Desktop, Claude Code, n8n — peuvent consommer directement pour parcourir le catalogue, constituer des paniers et préparer des commandes. Ce guide couvre l'installation, l'endpoint, la double authentification (OAuth 2.1 et jetons Bearer), la connexion des principaux agents, les outils exposés, les scopes, les modes de commande et le dépannage.
## Prérequis
- PrestaShop 8.0 à 9.x.
- PHP 7.4 à 8.3 avec l'extension cURL active.
- Une boutique servie en **HTTPS** (obligatoire pour les connecteurs IA).
- Recommandé : les **URL simplifiées** activées (_Paramètres avancés > SEO & URL_) pour des points de terminaison propres.
Le module fonctionne aussi sans URL simplifiées : il expose alors des liens de repli basés sur `index.php`, affichés dans l'onglet _Connecter un agent_ de la configuration.
## Installation
1. Dans le back-office, ouvrez _Modules > Module Manager_ puis _Téléverser un module_ et déposez le fichier `dfmcpcommerce.zip`.
2. Une fois installé, ouvrez la configuration via le bouton _Configurer_.
3. L'installation crée les tables techniques (jetons, clients OAuth, paniers, journal, limiteur de débit) et active le serveur par défaut.
## Votre endpoint MCP
L'URL du serveur MCP est affichée dans l'onglet _Connecter un agent_. Avec les URL simplifiées, elle ressemble à :
```
https://votre-boutique.com/mcp
```
C'est cette URL que vous collez dans le connecteur de l'agent. Le transport est **Streamable HTTP** (JSON-RPC 2.0) : un endpoint unique, en POST.
## Authentification : deux mécanismes
Le module gère deux modes d'authentification en parallèle, selon le client utilisé.
### OAuth 2.1 — connecteurs web (Claude.ai, ChatGPT)
Les connecteurs web de Claude.ai et de ChatGPT **n'acceptent qu'OAuth** : pas de jeton collé, pas de jeton dans l'URL. Le module fournit un serveur d'autorisation OAuth 2.1 complet (authorization code + PKCE S256, métadonnées de ressource protégée et enregistrement dynamique de client). L'agent se déclare seul et ouvre un écran de consentement où le client se connecte et approuve l'accès.
### Jetons Bearer — API, Desktop, CLI, n8n
Pour l'API Anthropic (connecteur MCP), Claude Desktop, Claude Code ou n8n, vous créez un **jeton Bearer statique** dans l'onglet _Jetons d'accès_ et le passez dans l'en-tête `Authorization: Bearer`.
Les jetons sont affichés **une seule fois** à la création et stockés hachés (SHA-256). Copiez-le immédiatement ; il ne sera plus jamais affiché en clair.
## Connecter Claude.ai ou ChatGPT (web)
1. Gardez **OAuth 2.1** activé dans l'onglet _Réglages_.
2. Dans l'agent, ajoutez un connecteur personnalisé et collez l'URL du serveur MCP.
3. L'agent découvre automatiquement l'authentification, s'enregistre et ouvre l'écran de consentement.
4. Le client se connecte à son compte boutique et approuve les scopes demandés. Aucun jeton à saisir.
## Connecter l'API Anthropic, Claude Desktop, Claude Code ou n8n
1. Ouvrez l'onglet _Jetons d'accès_, choisissez les scopes et cliquez sur **Créer un jeton**.
2. Copiez le jeton affiché.
3. Configurez le connecteur avec l'URL du serveur MCP et l'en-tête `Authorization: Bearer VOTRE_JETON`.
## Scopes
Chaque accès est borné par des scopes, demandés par l'agent et accordés au consentement (OAuth) ou portés par le jeton (Bearer) :
- `catalog:read` — recherche et fiches produits, catégories, infos boutique, transporteurs.
- `cart:write` — création et gestion de paniers.
- `order:write` — préparation de commande.
## Outils exposés
Neuf outils sont disponibles. Chacun est activable ou désactivable individuellement dans l'onglet _Réglages_, et soumis au scope correspondant.
- `search_products` — recherche par mot-clé, référence ou EAN, avec filtres catégorie et prix.
- `get_product` — fiche détaillée d'un produit (prix, stock, déclinaisons, images).
- `list_categories` — arborescence des catégories.
- `get_shop_info` — nom, langues, devises et pays livrés.
- `get_carriers` — transporteurs disponibles.
- `create_cart` — création d'un panier.
- `add_to_cart` — ajout d'un produit au panier.
- `view_cart` — contenu et totaux du panier.
- `create_order` — finalisation, selon le mode de commande configuré.
Désactivez les outils que vous ne souhaitez pas exposer. Par exemple, ne laisser que `catalog:read` et ses outils transforme le module en serveur de catalogue en lecture seule pour les agents.
## Modes de commande
L'onglet _Réglages_ propose deux comportements pour `create_order`.
### Mode transfert (par défaut)
L'agent assemble le panier puis renvoie une **URL de paiement sécurisée**. En la suivant, le client retrouve exactement ce panier dans sa session et finalise le paiement sur le tunnel PrestaShop habituel. Aucune donnée de paiement ne transite par l'agent : **zéro exposition PCI**.
### Mode commande
L'agent crée directement une commande en **attente de paiement**, dans l'état configurable (par défaut « Virement bancaire en attente »). Pensé pour le B2B, le paiement à la livraison ou les devis.
En mode commande, la commande est créée sans paiement encaissé. Le règlement est ensuite collecté selon la méthode associée à l'état de commande choisi.
## Réglages complémentaires
- **Exiger l'authentification** : recommandé. Une requête non authentifiée déclenche le flux OAuth (réponse 401 avec en-tête `WWW-Authenticate`).
- **Lecture anonyme du catalogue** : autorise les appels `catalog:read` sans jeton, pour exposer un catalogue public.
- **Limite de débit** : nombre de requêtes par minute et par IP (par défaut 120), en fenêtre glissante.
- **Journalisation** et **rétention** : trace chaque requête (méthode, outil, statut, durée) dans l'onglet _Journal d'activité_, avec un nombre de lignes conservées configurable.
## Découverte et points de terminaison
Les agents découvrent le serveur automatiquement. Les URL utiles sont listées dans l'onglet _Connecter un agent_ :
- **Protected Resource Metadata** (RFC 9728) — `/.well-known/oauth-protected-resource`.
- **Authorization Server Metadata** (RFC 8414) — `/.well-known/oauth-authorization-server`.
- **Enregistrement dynamique de client** (RFC 7591), **autorisation** et **jeton** : endpoints OAuth gérés par le module.
Même sans URL simplifiées, l'en-tête `WWW-Authenticate` renvoyé par l'endpoint pointe toujours vers la bonne URL de découverte basée sur `index.php` : la connexion fonctionne dans tous les cas.
## Sécurité
- Tous les jetons sont stockés **hachés en SHA-256**, jamais en clair.
- PKCE S256 obligatoire, `redirect_uri` validées, codes d'autorisation à usage unique, rotation des refresh tokens.
- Limitation de débit par IP et journal d'activité consultable.
- CORS géré pour les connecteurs web. Compatibilité multiboutique, multilingue et multidevise native.
## Dépannage
- **L'agent web ne se connecte pas** : vérifiez que la boutique est en HTTPS et qu'OAuth est activé. Collez bien l'URL `/mcp` (pas une page du back-office).
- **Le client API renvoie 401** : le jeton Bearer est absent, révoqué ou expiré. Recréez-en un dans l'onglet _Jetons d'accès_ et vérifiez l'en-tête `Authorization`.
- **Un outil n'apparaît pas** : il est probablement désactivé dans les _Réglages_, ou le scope correspondant n'a pas été accordé.
- **Erreur 429** : la limite de débit par IP est atteinte. Augmentez le seuil dans les _Réglages_ si nécessaire.
- **Le lien de paiement transféré expire** : les liens de panier ont une durée de vie limitée ; demandez à l'agent de régénérer le panier.
## Désinstallation
La désinstallation supprime les tables du module (jetons, clients OAuth, paniers, journal, limiteur) et ses variables de configuration. Vos produits, clients et commandes ne sont pas affectés. Pour une simple mise à jour, remplacer les fichiers suffit : le schéma et les jetons existants sont préservés.
---
### DataFirefly Native Live Shopping — Documentation
_Source :_
> Vue d'ensemble DataFirefly Native Live Shopping transforme votre boutique WooCommerce en plateforme de live shopping autonome, sans dépendance à un service tiers type Bambuser ou CommentSold. La diffusion utilise du…
## Vue d'ensemble
DataFirefly Native Live Shopping transforme votre boutique WooCommerce en plateforme de live shopping autonome, sans dépendance à un service tiers type Bambuser ou CommentSold. La diffusion utilise du **WebRTC peer-to-peer mesh** depuis le navigateur de l'hôte vers chaque spectateur, la signalisation passe par l'API REST WordPress, et l'enregistrement du replay est réalisé côté client via l'API MediaRecorder puis stocké en tant que pièces jointes WordPress.
Le plugin fournit :
- Un CPT `dfnls_live_show` pour créer et planifier vos lives
- Une console hôte intégrée à l'admin WordPress (preview caméra, contrôles, produits, chat)
- Une expérience spectateur clé en main avec produits cliquables en surimpression et chat
- Un bridge panier WooCommerce (ajout au panier officiel sans quitter le live)
- Un replay automatique synchronisé avec les événements du live (spotlights, coupons, messages)
- Un bloc Gutenberg dédié et le shortcode `[dfnls_live]`
**Architecture** — La topologie WebRTC mesh est idéale jusqu'à ~25 spectateurs simultanés par hôte. Au-delà, prévoir un serveur TURN externe ou envisager un SFU. La bande passante montante de l'hôte doit être d'environ 500 kbps par spectateur connecté.
## Prérequis
- **WordPress** 6.3 ou supérieur
- **WooCommerce** 8.0 ou supérieur (compatible HPOS)
- **PHP** 8.1 ou supérieur (testé jusqu'à 8.3)
- **HTTPS obligatoire** — `getUserMedia()` et `getDisplayMedia()` refusent de fonctionner sur du HTTP non sécurisé
- Navigateurs supportés côté spectateur : Chrome 80+, Firefox 75+, Edge 80+, Safari 14+, Opera 67+
- Un navigateur récent côté hôte avec caméra et micro accessibles
**Important** — Sans HTTPS valide (Let's Encrypt suffit), la console hôte ne pourra pas accéder à la caméra ni au micro. Testez sur `localhost` ou sur un domaine avec certificat TLS.
## Installation
1. Téléchargez l'archive `df-native-live-shopping.zip` depuis votre compte DataFirefly.
2. Dans WordPress, allez sur _Extensions → Ajouter_ → _Téléverser une extension_.
3. Sélectionnez le fichier ZIP puis cliquez sur _Installer maintenant_.
4. Une fois installé, cliquez sur _Activer l'extension_.
5. Un nouveau menu **Live Shopping** apparaît dans la barre latérale de l'admin.
À l'activation, le plugin :
- Crée 5 tables custom (`wp_dfnls_signaling`, `_sessions`, `_events`, `_replay_parts`, `_chat`)
- Ajoute les capabilities `manage_dfnls_lives` et `host_dfnls_lives` aux rôles `administrator` et `shop_manager`
- Planifie deux crons : purge quotidienne des replays anciens, purge horaire des messages de signalisation obsolètes
- Enregistre les options par défaut (serveurs STUN de Google, rétention 90 jours, 25 viewers max, etc.)
## Premier live en 5 minutes
Le parcours le plus court pour lancer votre premier live :
1. Menu **Live Shopping → Nouveau live**
2. Renseignez un titre (ex. « Ventes flash printemps »)
3. Dans la metabox _Produits_, recherchez et sélectionnez les produits WooCommerce que vous voulez présenter (glisser-déposer pour réordonner)
4. Optionnel : dans _Planification_, définissez une date et une heure de démarrage (un compte à rebours s'affichera côté spectateur)
5. Publiez le live
6. Allez dans **Live Shopping → Console hôte** et sélectionnez votre live
7. Cliquez sur _Démarrer la diffusion_, autorisez l'accès à la caméra et au micro
8. Partagez l'URL publique du live (`/live/votre-slug/`) avec votre audience
## Console hôte
La console hôte est le tableau de bord depuis lequel vous animez votre live. Elle est accessible via _Live Shopping → Console hôte_. Fonctionnalités :
### Preview vidéo et contrôles
- **Caméra** : bascule d'activation/désactivation de la caméra
- **Micro** : bascule d'activation/désactivation du micro
- **Partage d'écran** : remplace le flux caméra par un partage d'écran (utile pour démos)
- **Démarrer / Arrêter** : boutons de contrôle principal du live
### Mise en avant produits
La liste des produits liés au live s'affiche à droite. Chaque produit a un bouton _Mettre en avant_. Cliquer dessus :
- Fait apparaître immédiatement le produit en surimpression chez tous les spectateurs
- Enregistre un événement `product.spotlight` horodaté pour synchronisation replay
- Un second clic sur le même bouton retire la surimpression
### Diffusion de coupons
Saisissez un code promo (ex. `LIVE20`) et éventuellement une description, puis cliquez sur _Diffuser_. Un flash animé apparaît à l'écran des spectateurs avec un bouton « Copier » pour récupérer le code d'un clic.
### Messages animateur
Un champ de saisie libre permet d'envoyer un message qui s'affiche en bannière temporaire côté spectateur (8 secondes par défaut).
### Chat live
Le chat animateur/spectateurs est intégré à la console. Les messages de l'animateur sont visuellement distingués (badge et bordure rouge) sur toutes les vues.
### Journal d'activité
Un log en bas de la console affiche en temps réel les connexions/déconnexions, les événements diffusés, les uploads de chunks replay, et les éventuelles erreurs.
## Vue spectateur
Ce que vit l'audience une fois sur l'URL publique du live :
- **Avant le live** — Si le live est planifié, affichage d'un écran d'attente avec compte à rebours jusqu'à l'heure prévue. Poll automatique du statut toutes les 5 secondes pour détecter le démarrage.
- **Pendant le live** — Vidéo en direct avec pastille « EN DIRECT » pulsante et compteur de spectateurs. Sidebar avec deux onglets : _Produits_ (liste cliquable des produits du live) et _Chat_.
- **Surimpression produit** — Lorsque l'animateur met un produit en avant, une carte glisse à l'écran (par défaut en bas à droite) avec photo, nom, prix et bouton _Ajouter au panier_.
- **Ajout au panier** — Un clic sur le bouton ajoute le produit au panier WooCommerce officiel. Un FAB (bouton flottant) apparaît en bas à droite avec le compteur d'articles au panier.
- **Coupon flash** — Diffusé par l'animateur, s'affiche en haut avec animation et bouton copie.
- **Après le live** — Si le replay est activé, un bouton « Regarder le replay » permet de rejouer le live avec synchronisation intégrale des événements.
## Réglages globaux
Menu **Live Shopping → Réglages**. Sections principales :
### Serveurs STUN
Par défaut, les serveurs STUN publics de Google sont utilisés :
```
stun:stun.l.google.com:19302
stun:stun1.l.google.com:19302
```
Vous pouvez ajouter vos propres serveurs STUN (un par ligne).
### Serveurs TURN
Optionnel mais recommandé pour les spectateurs derrière NAT symétrique (certains opérateurs 4G, VPN d'entreprise). Format :
```
turn:turn.exemple.com:3478
turns:turn.exemple.com:5349
```
Renseignez les identifiants _TURN username_ et _TURN credential_ associés.
### Enregistrement et replay
- **Enregistrement activé** : oui / non global
- **Durée des chunks** (ms) : 5000 par défaut. Plus court = plus de résilience au crash mais plus de requêtes ; plus long = moins de requêtes mais perte plus importante en cas de crash
- **Rétention des replays** (jours) : 90 par défaut. Au-delà, le cron quotidien supprime automatiquement les fichiers WebM et les entrées associées
### Capacité et surimpression
- **Nombre max de spectateurs par hôte** : 25 par défaut. Ajustez selon votre bande passante montante
- **Position de la surimpression** : droite, gauche ou bas
### Défauts par live
- Chat activé par défaut
- Replay activé par défaut
- Connexion requise par défaut
## Serveurs STUN et TURN — quand configurer un TURN
STUN est un simple serveur de découverte d'IP publique, gratuit et suffisant dans ~85 % des cas. TURN, en revanche, relaie effectivement le trafic média : il consomme de la bande passante, mais permet de connecter deux clients qui ne peuvent pas se joindre en direct.
Configurez un TURN si :
- Vos spectateurs se plaignent régulièrement de ne pas voir la vidéo (état de connexion WebRTC bloqué en « connecting »)
- Votre audience contient beaucoup de mobiles sous 4G/5G chez des opérateurs à NAT symétrique (Free Mobile en France notamment)
- Votre hôte ou vos spectateurs sont derrière un VPN d'entreprise strict
**Solution recommandée** — Déployer un [coturn](https://github.com/coturn/coturn) auto-hébergé sur un petit VPS (5 à 10 € / mois) suffit pour 30-40 spectateurs simultanés. Alternative payante : Xirsys, Twilio Network Traversal Service.
## Enregistrement et replay
### Comment fonctionne l'enregistrement
L'enregistrement se fait entièrement **côté navigateur de l'hôte** via l'API MediaRecorder :
1. Au démarrage du live, MediaRecorder est instancié avec détection automatique du meilleur codec disponible (VP9 > VP8 > H.264, opus pour l'audio, ~1,5 Mbps vidéo + 96 kbps audio)
2. Toutes les 5 secondes (configurable), un chunk WebM est déclenché et uploadé via `POST /wp-json/df-nls/v1/shows/{id}/replay/chunk`
3. Le chunk est stocké comme pièce jointe WordPress, nommée `dfnls-show-{id}-part-{NNNNN}.webm`, avec `post_parent` pointant vers le live
4. La table `wp_dfnls_replay_parts` conserve l'ordre et la durée de chaque chunk
### Comment fonctionne le replay
Au chargement de la page en mode replay :
1. Le viewer appelle `GET /wp-json/df-nls/v1/shows/{id}/replay` qui retourne la liste ordonnée des segments et la timeline des événements
2. Les segments sont chargés séquentiellement via l'événement `ended` du `` (fallback natif)
3. Une variante MediaSource permet la concaténation transparente si le navigateur le supporte
4. La position de lecture (temps cumulé) est comparée aux `offset_ms` de chaque événement — quand le point est franchi, le viewer déclenche localement le même comportement qu'en live (afficher la surimpression, flash coupon, message)
### Stockage et espace disque
Ordre de grandeur : un live d'une heure à 1,5 Mbps vidéo + 96 kbps audio produit environ **720 Mo** de fichiers WebM. Avec 90 jours de rétention et 4 lives par mois, comptez ~10 Go d'espace disque dédié aux replays.
**MIME et upload** — Le plugin ajoute un filtre `upload_mimes` pour autoriser `video/webm` et `video/mp4` depuis la médiathèque. Vérifiez que votre serveur n'a pas de règle `LimitRequestBody` ou `upload_max_filesize` trop stricte (viser 20 Mo minimum par chunk).
## Intégration : shortcode, bloc, URL directe
### URL publique directe
Chaque live publié possède sa propre URL générée automatiquement :
```
https://votre-site.com/live/votre-slug/
```
C'est la manière la plus simple : partagez ce lien avec votre audience.
### Shortcode
Pour insérer un live dans une page ou un article existant :
```
[dfnls_live id="42"]
[dfnls_live id="42" mode="live"]
[dfnls_live id="42" mode="replay"]
[dfnls_live id="42" mode="auto"]
```
Modes disponibles :
- `auto` (défaut) : détecte le statut du live et affiche live / attente / replay selon
- `live` : force l'affichage en mode diffusion (utile pour des tests)
- `replay` : force le mode replay même si le live est encore en cours
### Bloc Gutenberg
Dans l'éditeur de blocs, cherchez _« Live Shopping »_. Le bloc supporte les alignements `wide` et `full`, expose un sélecteur pour choisir le live et un sélecteur de mode dans la barre latérale de l'inspecteur.
### Template PHP personnalisé
Le CPT utilise `templates/single-live-show.php`. Pour surcharger, copiez ce fichier dans votre thème sous `votre-theme/df-native-live-shopping/single-live-show.php`.
## Multilingue avec Polylang
Le plugin déclare le CPT `dfnls_live_show` comme traduisible auprès de Polylang. À l'activation, si Polylang est déjà installé :
- Chaque live peut avoir une version FR, EN, ES, DE, IT, etc.
- Les métadonnées critiques (`_dfnls_product_ids`, `_dfnls_scheduled_at`, options de live) sont copiées automatiquement entre traductions
- Les 5 langues intégrées (FR, EN, ES, DE, IT) sont chargées automatiquement selon la locale WordPress
**Astuce Polylang Pro** — Si vous utilisez Polylang Pro et que vos produits WooCommerce sont eux-mêmes traduits, chaque traduction du live doit être associée à la version linguistique correspondante des produits. Le plugin ne fait pas de mapping automatique inter-langues sur les IDs produits.
## HPOS et compatibilités
Le plugin déclare officiellement sa compatibilité avec le stockage haute performance des commandes de WooCommerce (HPOS) via `FeaturesUtil`. Vous pouvez activer HPOS sur votre installation sans risque de dysfonctionnement du bridge panier.
Compatible également avec :
- WordPress Multisite (installation par site, pas de mode réseau)
- Hébergement mutualisé (o2switch, OVH, Infomaniak, PlanetHoster) — la signalisation utilise le polling REST, pas de WebSocket
- Plugins de cache (WP Rocket, WP Super Cache) — les endpoints REST du plugin sont exclus automatiquement
## Sécurité et capabilities
Le plugin ajoute deux capabilities dédiées :
- `manage_dfnls_lives` — création, édition, suppression des lives ; accès aux réglages
- `host_dfnls_lives` — accès à la console hôte, démarrage / arrêt d'un live
Les deux capabilities sont attribuées par défaut aux rôles `administrator` et `shop_manager`. Pour donner à un utilisateur uniquement le droit d'animer sans pouvoir créer de lives :
```
$user = get_user_by('login', 'animateur');
$user->add_cap('host_dfnls_lives');
```
### Nonces REST
Toutes les routes d'action (POST) sont protégées par nonce `wp_rest`. Le viewer et l'host reçoivent leur nonce respectif via `wp_localize_script` au chargement de la page.
### Validation MIME uploads
L'upload de chunks replay est strictement validé via `wp_check_filetype_and_ext` pour n'accepter que `video/webm` et `video/mp4`. Les fichiers sont renommés côté serveur (`dfnls-show-{id}-part-{NNNNN}.webm`).
## Cron et maintenance
Deux crons WordPress sont planifiés à l'activation :
- `dfnls_cleanup_expired_replays` — **quotidien**. Supprime les replays des lives terminés depuis plus de N jours (rétention configurable). Utilise `wp_delete_attachment(..., true)` pour supprimer aussi le fichier physique.
- `dfnls_cleanup_stale_signaling` — **horaire**. Purge les messages de signalisation de plus de 24h et les sessions inactives de plus de 90 secondes.
**WP-Cron désactivé** — Si vous avez désactivé WP-Cron au profit d'un cron système, assurez-vous d'appeler `wp-cron.php` au moins une fois par heure pour que les purges s'exécutent.
## Pour les développeurs — API REST
Toutes les routes sont sous le namespace `df-nls/v1`.
### Show
- `GET /shows/{id}` — récupère un live (statut, produits, options)
- `POST /shows/{id}/join` — rejoint comme viewer ou host (body : `peer_id`, `role`)
- `POST /shows/{id}/leave` — quitte proprement
- `POST /shows/{id}/heartbeat` — maintient la session ouverte (auto toutes les 15s côté viewer)
- `POST /shows/{id}/start` — démarre le live (host uniquement)
- `POST /shows/{id}/end` — termine le live (host uniquement)
- `GET /shows/{id}/viewers` — compteur de spectateurs actifs
### Signaling WebRTC
- `POST /signal/send` — envoie un message SDP/ICE à un peer distant
- `GET /signal/pull?peer={id}` — récupère les messages en attente et effectue un heartbeat implicite
### Events
- `POST /shows/{id}/event` — enregistre un événement (spotlight, message, coupon)
- `GET /shows/{id}/events?since={id}` — pull des événements depuis un ID donné
### Chat
- `GET /shows/{id}/chat?since={id}` — pull des messages depuis un ID
- `POST /shows/{id}/chat` — envoie un message
### Cart bridge
- `POST /cart/add` — ajoute un produit au panier avec traçage source (`show_id`, `product_id`, `quantity`)
- `GET /cart/summary` — compteur et total du panier courant
### Recording et replay
- `POST /shows/{id}/replay/chunk` — upload multipart d'un chunk WebM
- `GET /shows/{id}/replay` — segments + timeline events pour lecture
## Structure du plugin (PSR-4)
```
df-native-live-shopping/
├── df-native-live-shopping.php # Bootstrap
├── uninstall.php
├── readme.txt
├── assets/
│ ├── js/ (host.js, viewer.js, admin.js, block-editor.js)
│ └── css/ (host.css, viewer.css, admin.css)
├── languages/ # 5 .po/.mo + .pot
├── templates/ # single-live-show.php, viewer-container.php, ...
└── src/
├── Plugin.php
├── Activator.php Deactivator.php
├── PostType/ (LiveShow.php)
├── Database/ (Schema + 5 Repository.php)
├── Admin/ (AdminPages, MetaBoxes, SettingsPage)
├── Api/ (RestController, SignalingController, CartController)
├── Recording/ (RecordingHandler)
├── Replay/ (ReplayHandler)
├── Frontend/ (Renderer, Shortcode, Block)
└── Compat/ (PolylangCompat)
```
Namespace racine : `DataFireflyNativeLiveShopping`, autoloader manuel PSR-4 déclaré dans `df-native-live-shopping.php`.
## Dépannage
### Les spectateurs ne voient pas la vidéo
- Vérifier que le site est en HTTPS (obligatoire pour WebRTC)
- Ouvrir la console du navigateur côté spectateur, chercher les erreurs `ICE failed` ou `connection state failed`
- Configurer un serveur TURN si l'audience contient beaucoup de mobiles 4G
- Vérifier que la bande passante montante de l'hôte est suffisante (utilitaire fast.com côté hôte)
### La console hôte ne détecte pas la caméra
- Vérifier que le navigateur a bien accordé l'autorisation (icône cadenas dans la barre d'URL)
- Sur macOS, vérifier les permissions système : _Préférences → Sécurité → Caméra_
- Fermer les autres applications utilisant la caméra (Zoom, Teams, OBS...)
### Les chunks replay ne s'uploadent pas
- Vérifier `upload_max_filesize` et `post_max_size` dans php.ini (viser 20 Mo minimum)
- Vérifier `LimitRequestBody` côté Apache si applicable
- Regarder le journal d'activité de la console hôte pour identifier l'erreur exacte
- Vérifier les permissions du dossier `wp-content/uploads`
### Le panier ne conserve pas les ajouts
- Vérifier qu'aucun plugin de cache ne met en cache les endpoints `/wp-json/df-nls/v1/*`
- Vérifier que les cookies WooCommerce (`woocommerce_cart_hash`, `wp_woocommerce_session_*`) sont bien émis
- Sur HTTPS strict, vérifier que les cookies ont bien le flag `Secure`
### Les replays occupent trop d'espace
- Réduire la rétention (par ex. de 90 à 30 jours) dans les réglages
- Désactiver l'enregistrement pour les lives où ce n'est pas nécessaire (case « Autoriser le replay » dans la metabox _Options_)
- Réduire le bitrate en modifiant `host.js` (variable `videoBitsPerSecond`)
## Désinstallation
À la désactivation simple, les données sont conservées et les crons désinscrits. À la **suppression complète** du plugin depuis _Extensions_, `uninstall.php` effectue :
- Suppression des 5 tables custom
- Suppression de toutes les options `dfnls_*`
- Retrait des capabilities des rôles
- Désinscription des crons
- Optionnel : suppression des CPT et de toutes les pièces jointes replay si l'option `dfnls_uninstall_delete_data` a été activée avant désinstallation
**Attention** — Par défaut, les lives et leurs replays ne sont PAS supprimés à la désinstallation. Pour tout supprimer, activez l'option _Supprimer toutes les données à la désinstallation_ dans les réglages avant de désinstaller.
## Support et évolutions
Support technique inclus pendant 12 mois via l'espace client DataFirefly. Les mises à jour du plugin sont disponibles depuis votre compte, avec notification par email des versions majeures.
Idées d'évolution sur la roadmap :
- Basculement SFU automatique au-delà d'un seuil de spectateurs
- Sondages live (poll.open / poll.close déjà réservés dans le protocole d'événements)
- Analytics natives (temps moyen de visionnage, taux de conversion par live)
- Multi-hôtes (deux animateurs simultanés)
---
### DataFirefly Odoo Connector — guide d'installation et de configuration
_Source :_
> Ce guide couvre l'installation, la configuration et l'exploitation du plugin DataFirefly Odoo Connector pour Shopware 6.6 et 6.7. À la fin, votre boutique synchronisera produits, stock, clients et commandes avec…
Ce guide couvre l'installation, la configuration et l'exploitation du plugin **DataFirefly Odoo Connector** pour Shopware 6.6 et 6.7. À la fin, votre boutique synchronisera produits, stock, clients et commandes avec votre instance Odoo via XML-RPC natif, sans aucune dépendance externe ni surcoût d'API tierce.
## Présentation
Le plugin établit un pont bidirectionnel entre Shopware et Odoo en parlant directement le protocole XML-RPC d'Odoo (stable depuis la version 8). Aucun module à installer côté Odoo, aucun middleware payant, aucun SaaS intermédiaire.
EntitéOdoo → Shopware (pull)Shopware → Odoo (push)Produits (product.template)✅✅Stock (qty_available / free_qty)✅—Catégories (product.category)✅✅Clients (res.partner)—✅ avec adresses enfantsCommandes (sale.order)—✅ avec confirmation et facture optionnelles
## Prérequis
- **Shopware** 6.6.x ou 6.7.x (toutes versions mineures).
- **PHP** 8.2, 8.3 ou 8.4.
- **Extensions PHP** : curl, xml, simplexml (présentes par défaut sur la quasi-totalité des hébergeurs).
- **Odoo** 12, 13, 14, 15, 16, 17 ou 18, en Community ou Enterprise. Odoo.sh, Odoo Online (SaaS) et instances auto-hébergées fonctionnent identiquement.
- Un utilisateur Odoo dédié à l'API (recommandé) avec droits de lecture/écriture sur les modèles utilisés (product.template, product.product, res.partner, sale.order, stock.warehouse, product.category, res.country, account.tax).
## Installation
### Via téléversement dans l'administration
1. Téléchargez l'archive `DfOdooConnector-v1.0.0.zip` depuis votre compte client.
2. Dans l'administration Shopware : _Extensions → Mes extensions → Téléverser une extension_.
3. Sélectionnez le ZIP puis cliquez sur _Installer_.
4. Activez l'extension en cliquant sur l'interrupteur.
### Via console SSH
```
cd /chemin/vers/shopware
cp DfOdooConnector-v1.0.0.zip custom/plugins/
cd custom/plugins && unzip DfOdooConnector-v1.0.0.zip
sudo -u www-data setsid php bin/console plugin:refresh
sudo -u www-data setsid php bin/console plugin:install --activate DfOdooConnector
sudo -u www-data setsid php bin/console cache:clear
```
Recompilation de l'administration pour charger le module Vue 3 :
```
sudo -u www-data setsid php bin/build-administration.sh
```
**Note** — L'installation crée deux tables : `df_odoo_mapping` (correspondances persistantes Shopware ↔ Odoo) et `df_odoo_log` (journal des opérations). Aucune table existante n'est modifiée.
## Configuration côté Odoo
### Créer un utilisateur dédié
Il est fortement recommandé de créer un utilisateur Odoo dédié à l'intégration plutôt que d'utiliser un compte administrateur personnel. Cela permet d'auditer précisément les actions du connecteur et de révoquer son accès indépendamment.
1. Dans Odoo : _Paramètres → Utilisateurs et sociétés → Utilisateurs_.
2. Créez un utilisateur nommé par exemple `Shopware Bridge`.
3. Donnez-lui les droits requis : Inventaire (utilisateur), Ventes (administrateur des documents), Facturation (utilisateur si vous activez la création de facture), Contacts (utilisateur).
### Générer une clé API
1. Connectez-vous à Odoo avec ce nouvel utilisateur.
2. Cliquez sur l'avatar en haut à droite → _Préférences_.
3. Onglet _Compte_ → _Clés API_ → _Nouvelle clé API_.
4. Donnez un nom descriptif (par exemple `Shopware Connector`) et copiez la valeur générée.
**Important** — La clé API ne s'affiche qu'une seule fois. Si vous la perdez, il faudra en générer une nouvelle. Stockez-la dans un gestionnaire de mots de passe avant de fermer la modale.
## Configuration côté Shopware
### Renseigner la connexion
Dans l'administration Shopware : _Paramètres → Système → Plugins → Df Odoo → Paramètres_, ou directement via le menu latéral _Paramètres → Df Odoo → Paramètres_.
- **URL Odoo** : URL complète de votre instance sans slash final, par exemple `https://moncompte.odoo.com`.
- **Nom de la base** : visible dans l'URL Odoo après `?db=`, ou dans _Paramètres → Technique → Base de données_.
- **Utilisateur** : login de l'utilisateur dédié, généralement son adresse email.
- **Clé API Odoo** : valeur copiée à l'étape précédente.
- **Délai d'attente** : 30 secondes par défaut, suffisant dans la majorité des cas.
### Tester la connexion
Cliquez sur le bouton _Tester la connexion_ en haut à droite. Si tout est correct, une notification verte affiche la version d'Odoo et l'identifiant utilisateur (uid). Si la connexion échoue, le message d'erreur retourné par Odoo est affiché tel quel.
**Conseil** — Le test de connexion peut aussi être appelé depuis la console pour scripter une vérification :
`curl -X POST -H "Authorization: Bearer ADMIN_TOKEN" https://votreshopware.com/api/_action/df-odoo/test-connection`
## Directions de synchronisation
Chaque entité dispose d'un sélecteur indépendant : _désactivé_, _Odoo → Shopware_ (pull), _Shopware → Odoo_ (push), ou _bidirectionnel_. Les valeurs par défaut sont :
- **Produits** : bidirectionnel
- **Stock** : Odoo → Shopware (Odoo est la source de vérité)
- **Clients** : Shopware → Odoo
- **Commandes** : Shopware → Odoo
- **Catégories** : désactivé (à activer manuellement selon votre organisation)
## Synchronisation des produits
### Stratégies de correspondance
Trois stratégies sont configurables :
- **SKU** (recommandé) : Shopware `productNumber` ↔ Odoo `default_code`.
- **ID Odoo** : repose uniquement sur la table de mapping persistante. Utile si vos SKU sont volatiles.
- **Code-barres** (EAN) : Shopware `ean` ↔ Odoo `barcode`. Exige des EAN renseignés des deux côtés.
Une fois liés, deux produits restent appariés via la table `df_odoo_mapping`, même si la SKU change ensuite.
### Pull depuis Odoo
La tâche planifiée lit les `product.template` modifiés depuis la dernière exécution (champ `write_date`) et crée ou met à jour les produits correspondants côté Shopware. Les champs synchronisés sont : nom, SKU, prix de vente, prix de revient, description courte, description longue, poids, volume, état actif, catégorie, taxes.
### Push vers Odoo
Les produits maîtres Shopware (avec `parentId = null`) actifs sont envoyés vers Odoo en tant que `product.template` de type _product_ (article stockable). Les variantes Shopware sont remontées sous leur produit parent.
**Détection des changements** — Avant chaque écriture, un hash SHA-1 du contenu est comparé à celui mémorisé dans le mapping. Si rien n'a changé, l'écriture est ignorée et l'opération est journalisée comme `skipped`. Cela évite de saturer Odoo lors des cron successifs.
## Synchronisation du stock
Le stock est toujours tiré depuis Odoo (jamais l'inverse). Toutes les 15 minutes, la tâche planifiée lit les variantes `product.product` par lots de 100 par identifiant de template parent, agrège `qty_available` ou `free_qty` (configurable globalement) puis met à jour le champ `stock` de chaque produit Shopware en une seule requête DAL.
**qty_available vs free_qty** — `qty_available` reflète le stock physique présent en entrepôt. `free_qty` retire les quantités déjà réservées sur des commandes non livrées. _free_qty_ est généralement préférable pour un site marchand car il évite la survente.
## Synchronisation des catégories
Désactivée par défaut. Activez-la si votre arborescence de catégories doit rester synchrone avec celle d'Odoo. La hiérarchie `parent_id` est préservée des deux côtés. Comme pour les produits, un hash de contenu évite les écritures inutiles.
## Synchronisation des clients
Les clients Shopware sont poussés comme `res.partner` Odoo avec :
- **Déduplication par email** : avant toute création, un partenaire existant avec le même email et `parent_id = false` est cherché. S'il existe, il est mis à jour au lieu d'être dupliqué.
- **company_type** : _company_ si le champ société de l'adresse de facturation est renseigné, _person_ sinon.
- **Adresses enfants** : l'adresse de facturation par défaut est créée comme partenaire enfant avec `type='invoice'`, l'adresse de livraison comme partenaire enfant avec `type='delivery'`.
- **TVA intracommunautaire** : reportée sur le champ `vat` du partenaire principal.
- **Pays et région** : résolus par code ISO avec cache mémoire intra-requête.
## Synchronisation des commandes
### En temps réel au checkout
Si l'option _Pousser chaque commande dès validation_ est activée, un event subscriber écoute `CheckoutOrderPlacedEvent` et envoie immédiatement la commande vers Odoo après la finalisation du checkout. Le client est créé dans Odoo si nécessaire (via la synchronisation client), puis la commande est créée comme `sale.order` avec :
- `partner_id` résolu via le mapping client.
- `order_line` en syntaxe tuple Odoo : `[0, 0, {name, product_uom_qty, price_unit, product_id}]`.
- Une ligne supplémentaire pour les frais de transport si `totalPrice` du shipping est supérieur à zéro.
- `company_id`, `warehouse_id`, `pricelist_id` selon les valeurs par défaut configurées.
**Le checkout n'est jamais bloqué** — Si Odoo est inaccessible, l'erreur est tracée dans `df_odoo_log` et la commande sera reprise dans les 10 minutes par la tâche planifiée `df_odoo.order_sync`, qui scanne les commandes des 7 derniers jours non encore mappées.
### Filtre d'état
Le filtre _État des commandes_ permet de restreindre les commandes poussées :
- **Toutes** : toute commande validée est envoyée (recommandé en B2C avec paiement immédiat).
- **Payées uniquement** : seules les commandes dont l'état de paiement est _paid_ sont poussées. Évite de remonter des paniers abandonnés à paiement manuel.
- **Payées ou expédiées** : ajoute aux précédentes les commandes expédiées avant paiement (B2B avec délais).
### Confirmation et facture automatiques
Deux options pilotent ce qui se passe côté Odoo une fois la commande créée :
- **Confirmer la commande** : appelle `action_confirm` sur la `sale.order`, qui passe alors directement à l'état _commande confirmée_ au lieu de rester _devis_.
- **Créer la facture** : appelle `_create_invoices` pour générer immédiatement une facture validée. L'identifiant de la facture créée est mémorisé comme mapping de type `invoice`.
## Multi sales channel
Tous les paramètres du plugin peuvent être surchargés par canal de vente. En haut de la page _Paramètres_, le sélecteur natif Shopware permet de basculer entre _Tous les canaux_ et un canal spécifique.
Cas d'usage typiques :
- Un canal B2C qui pousse vers un Odoo principal et un canal B2B qui pousse vers un Odoo distinct.
- Un canal de production avec direction _push_ et un canal staging avec direction _désactivée_.
- Différents identifiants Odoo (warehouse, sales team, pricelist) selon le canal.
## Tâches planifiées
Nom interneFréquenceAction`df_odoo.product_sync`1 heurePull puis push produits selon la direction configurée. Le pull n'examine que les fiches modifiées depuis -2 h.`df_odoo.stock_sync`15 minutesPull du stock depuis Odoo pour tous les produits déjà mappés.`df_odoo.customer_sync`1 heurePush des clients actifs non encore mappés (100 max par exécution).`df_odoo.order_sync`10 minutesPush des commandes des 7 derniers jours non encore mappées (50 max par exécution).
Forcer l'exécution d'une tâche depuis la console :
```
sudo -u www-data setsid php bin/console scheduled-task:run-single df_odoo.product_sync
```
**Worker Shopware** — Pour que les tâches planifiées se déclenchent automatiquement, le worker messenger Shopware doit tourner (cron `messenger:consume` ou tâche systemd). Vérifiez dans _Paramètres → Système → File d'attente_ que _scheduled_task_ est consommée régulièrement.
## Module d'administration
Une section **Df Odoo** apparaît dans _Paramètres → Plugins_ avec quatre pages.
### Dashboard
Compteurs en direct (mappings actifs par entité, activité des dernières 24 h par statut), boutons de synchronisation manuelle par entité (pull et push), bandeau d'état de la connexion, liste des erreurs récentes et raccourcis vers les autres pages.
### Paramètres
Formulaire complet avec sélecteur de canal de vente. Bouton _Tester la connexion_ et _Enregistrer_ dans la barre d'actions.
### Journal
Toutes les opérations sont tracées dans `df_odoo_log` avec leur statut (_success_, _error_, _warning_, _skipped_), leur direction, l'entité concernée, la durée en millisecondes et le message complet. Filtres combinables par statut, type d'entité et direction. Pagination serveur.
**Mode debug** — Les opérations _skipped_ ne sont écrites dans le journal que si le mode debug est activé dans les paramètres. À utiliser ponctuellement pour diagnostiquer un comportement, à désactiver en production pour éviter de saturer la table.
### Correspondances
Vue lecture sur la table `df_odoo_mapping` avec recherche, filtre par type d'entité et tri par date de dernière synchronisation. Pratique pour vérifier qu'un produit donné est bien mappé à l'ID Odoo attendu.
## API REST admin
Tous les endpoints requièrent une authentification admin standard (Bearer token).
MéthodeEndpointParamètresPOST`/api/_action/df-odoo/test-connection``salesChannelId` (optionnel)POST`/api/_action/df-odoo/sync/products``direction=pull|push`, `salesChannelId`POST`/api/_action/df-odoo/sync/stock``salesChannelId`POST`/api/_action/df-odoo/sync/customers``salesChannelId`POST`/api/_action/df-odoo/sync/orders``salesChannelId`, `limit` (1-500)POST`/api/_action/df-odoo/sync/categories``direction=pull|push`GET`/api/_action/df-odoo/stats`—GET`/api/_action/df-odoo/logs``status`, `entityType`, `direction`, `page`, `perPage`
Exemple d'appel pour forcer un push produit :
```
curl -X POST
-H "Authorization: Bearer ADMIN_TOKEN"
-d "direction=push"
https://votreshopware.com/api/_action/df-odoo/sync/products
```
## Tables et données stockées
Le plugin crée deux tables MySQL :
- `df_odoo_mapping` — correspondances persistantes (identifiant Shopware ↔ identifiant Odoo) avec hash de synchronisation et payload optionnel. Une ligne est unique sur le couple (type d'entité, identifiant Shopware) et sur (type d'entité, identifiant Odoo).
- `df_odoo_log` — journal des opérations avec statut, durée, message, payload, identifiant du canal de vente.
Aucune table Shopware standard n'est modifiée.
## Désinstallation
Depuis l'administration : _Extensions → Mes extensions → Df Odoo → Désinstaller_.
Une boîte de dialogue propose deux options :
- **Conserver les données utilisateur** coché : les tables `df_odoo_mapping` et `df_odoo_log` sont préservées, ainsi que les paramètres système. Pratique en cas de réinstallation ultérieure.
- **Conserver les données utilisateur** décoché : les deux tables sont supprimées (DROP TABLE) à la désinstallation. L'instance Odoo n'est jamais touchée.
## Dépannage
### « Configuration Odoo incomplète » au test de connexion
L'un des quatre champs obligatoires (URL, base, utilisateur, clé API) est vide. Vérifiez que vous avez bien sélectionné le bon canal de vente avant d'enregistrer.
### « 401 Unauthorized » ou « access denied »
La clé API a été révoquée côté Odoo, ou l'utilisateur n'a pas les droits requis sur le modèle ciblé. Régénérez une clé API et vérifiez les droits Odoo de l'utilisateur (notamment _Inventaire → Utilisateur_ et _Ventes → Administrateur des documents_).
### « Connexion refusée » ou timeout
L'URL Odoo n'est pas accessible depuis le serveur Shopware. Vérifiez que le pare-feu autorise les connexions sortantes HTTPS vers le domaine Odoo. Augmentez le délai d'attente si votre instance Odoo est lente à répondre.
### Les produits ne se synchronisent pas
Vérifiez le journal (page _Journal_) pour des entrées en erreur. Activez le mode debug pour tracer également les opérations _skipped_ et identifier si le hash de contenu fait que rien ne change réellement.
### Les commandes ne partent pas au checkout
Vérifiez que l'option _Pousser chaque commande dès validation_ est cochée et que la direction _Commandes_ est sur _Shopware → Odoo_. Si le filtre d'état est sur _Payées uniquement_ et que le paiement est asynchrone, c'est la tâche planifiée qui pousse la commande quelques minutes après l'encaissement.
## Limites connues
- Les attributs de variantes Odoo (`product.attribute`) ne sont pas encore mappés automatiquement. Les variantes Shopware sont remontées comme produits parents Odoo (`product.template`). Les variantes Odoo créées manuellement restent correctement liées via leur template parent. Une gestion native est prévue en version 1.1.
- Les remises de ligne de commande sont reportées comme `price_unit` ajusté, pas comme `discount` Odoo.
- Les modes de paiement et expédition Shopware ne sont pas mappés vers les `journal_id` Odoo — les valeurs par défaut Odoo sont utilisées.
## Support
Pour toute question, contactez l'équipe DataFirefly via le formulaire de contact sur [datafirefly.com](https://www.datafirefly.com/contact/). Pensez à joindre l'export du journal (page _Journal_ → bouton d'export à venir) ou à minima une capture de la ligne en erreur ainsi que la version exacte de Shopware, PHP et Odoo.
---
### DataFirefly Order Vouchers — Guide complet
_Source :_
> Présentation et prérequis DataFirefly Order Vouchers ajoute deux colonnes à la liste des commandes du back-office : le ou les codes promo utilisés sur chaque commande, et le montant total…
## Présentation et prérequis
DataFirefly Order Vouchers ajoute deux colonnes à la liste des commandes du back-office : le ou les codes promo utilisés sur chaque commande, et le montant total de la réduction (formaté dans la devise de la commande). Le module ne crée aucune table, n'écrit rien en base et ne surcharge aucun contrôleur : il lit simplement les bons de réduction déjà enregistrés sur vos commandes et les affiche dans la grille.
- Compatible PrestaShop 8.0 à 9.x.
- PHP 7.4 à 8.3.
- Multiboutique et multilingue (FR/EN/ES/DE/IT).
- Aucune surcharge de fichiers : uniquement les hooks natifs de la grille Symfony des commandes.
Les données proviennent des tables `order_cart_rule` et `cart_rule`. Une commande sans bon de réduction affiche simplement une cellule vide dans les deux colonnes.
## Installation
1. Téléchargez l'archive `dfordervouchers.zip` depuis votre compte client.
2. Dans le back-office, allez dans **Modules > Gestionnaire de modules**.
3. Cliquez sur **Installer un module** et déposez l'archive.
4. L'installation enregistre les deux hooks de la grille des commandes. Aucune configuration n'est nécessaire.
Dès l'installation, ouvrez **Commandes > Commandes** : les deux nouvelles colonnes apparaissent à la suite de la colonne « Total ».
Le module ne possède pas de page de configuration : il fonctionne immédiatement après l'installation, sans aucun réglage.
## Les deux colonnes ajoutées
### Code(s) promo
Cette colonne affiche le code de chaque bon de réduction réellement appliqué à la commande. Lorsqu'une commande cumule plusieurs codes, ils sont regroupés, dédoublonnés et séparés par des virgules. Les promotions automatiques (règles panier sans code) ne sont pas affichées dans cette colonne, puisqu'elles n'ont pas de code à présenter.
### Réduction
Cette colonne totalise le montant remisé sur la commande, tel qu'il a été enregistré au moment de la validation (TTC par défaut), et l'affiche dans la devise de la commande. Une commande en livres ou en dollars affiche donc son montant dans sa propre devise. Si aucune réduction n'a été appliquée, la cellule reste vide.
## Fonctionnement technique
À partir de PrestaShop 1.7.7, la liste des commandes repose sur la grille Symfony. Le module s'y branche via deux hooks officiels :
- `actionOrderGridDefinitionModifier` : ajoute les deux colonnes à la définition de la grille, juste après la colonne « Total ».
- `actionOrderGridQueryBuilderModifier` : enrichit la requête de la grille avec deux sous-requêtes corrélées sur `order_cart_rule` et `cart_rule`.
Les sous-requêtes étant corrélées à l'identifiant de commande, elles ne produisent aucune duplication de lignes et n'entrent pas en conflit avec le regroupement interne de la grille. Le montant réutilise la devise déjà jointe par le cœur dans la requête de la grille.
Le module est en **lecture seule** : il n'écrit jamais en base et ne modifie aucune commande. Il peut être installé et désinstallé sans aucun impact sur vos données.
## Cas particuliers
### Plusieurs codes sur une commande
Tous les codes sont affichés, séparés par des virgules. Le montant de la colonne « Réduction » additionne l'ensemble des bons appliqués à la commande.
### Promotions automatiques sans code
Par défaut, la colonne « Réduction » additionne toutes les réductions de la commande, y compris d'éventuelles promotions automatiques sans code. La colonne « Code(s) promo », elle, n'affiche que les bons possédant un code. Une variante limitant le montant aux seuls bons avec code est disponible sur demande.
### Multidevise
Le montant est toujours affiché dans la devise de la commande concernée, en réutilisant la devise jointe par la grille native.
### Multiboutique
L'affichage respecte le contexte boutique courant du back-office, exactement comme la grille native des commandes.
## Tri et personnalisation
Les libellés des deux colonnes sont traduisibles via le système de traduction des modules PrestaShop, dans les cinq langues. Le tri natif de la grille reposant sur une liste blanche de champs, un clic sur l'en-tête de ces colonnes calculées ne déclenche pas de tri mais ne provoque aucune erreur.
## FAQ et dépannage
### Les colonnes n'apparaissent pas
Vérifiez que le module est bien installé et actif dans le Gestionnaire de modules, puis rechargez la page **Commandes > Commandes**. Les colonnes apparaissent à la suite de la colonne « Total ».
### La colonne « Réduction » est vide alors qu'un code est affiché
Cela peut arriver si le bon enregistré sur la commande a une valeur nulle, par exemple un bon de livraison gratuite. Le code reste affiché, mais le montant remisé est égal à zéro.
### Le module fonctionne-t-il sur PrestaShop 8 et 9 ?
Oui. Il s'appuie sur la grille Symfony des commandes présente dans les deux versions, via les hooks officiels de définition et de query builder.
### Que se passe-t-il à la désinstallation ?
La désinstallation retire simplement les deux hooks. Aucune table n'ayant été créée et aucune donnée n'ayant été écrite, il ne reste rien en base.
---
### DataFirefly Page Builder pour Shopware 6.7 — Installation, configuration et documentation technique
_Source :_
> Présentation Le DataFirefly Page Builder est un éditeur de pages visuel autonome pour Shopware 6.7. Il possède son propre moteur de rendu storefront (Twig) et fonctionne indépendamment du CMS natif…
## Présentation
Le **DataFirefly Page Builder** est un éditeur de pages visuel **autonome** pour Shopware 6.7. Il possède son propre moteur de rendu storefront (Twig) et fonctionne indépendamment du CMS natif « Shopping Experiences ». Vous composez des pages par **sections** et **colonnes**, puis remplissez ces colonnes avec des **blocs** en glisser-déposer, sans écrire de code.
L'éditeur tourne dans l'administration en **Vue 3 / Pinia** (build Vite de la 6.7) et propose le glisser-déposer, le monter/descendre, la duplication et un **undo/redo**. Le contenu est enregistré en **JSON versionné** : un brouillon de travail distinct de la version publiée, un historique de versions créé à chaque publication, la publication planifiée et des liens de prévisualisation signés partageables. Les pages publiées sont servies sur `/p/{slug}` avec le **cache HTTP** Shopware actif, et prennent en charge le multilingue et le multi-canaux.
Ce module est un **plugin** (code PHP). Il s'installe donc sur Shopware **self-hosted** et **PaaS** — pas sur Shopware Cloud (SaaS), réservé aux apps.
## Prérequis
- Shopware **≥ 6.7.0** (`shopware/core`, `shopware/storefront` et `shopware/administration` en `~6.7.0`)
- PHP **≥ 8.2**
- MySQL 8 / MariaDB 10.11+
- Accès à la ligne de commande pour installer le plugin, compiler les assets et vider le cache
- Variable d'environnement `APP_SECRET` définie — elle sert à signer les liens de prévisualisation
## Installation
1. Copiez le dossier `DataFireflyPageBuilder` dans `custom/plugins/` de votre instance (ou téléversez le ZIP via **Extensions → Mes extensions → Téléverser l'extension**).
2. Rafraîchissez la liste des plugins, installez puis activez l'extension.
3. Compilez l'administration et le storefront, puis videz le cache :
```
bin/console plugin:refresh
bin/console plugin:install --activate DataFireflyPageBuilder
bin/build-administration.sh
bin/build-storefront.sh
bin/console assets:install
bin/console cache:clear
```
Après une installation ou une mise à jour, videz aussi le cache de votre navigateur (Ctrl+F5) sur la page d'administration pour recharger le module.
## Créer et éditer une page
Ouvrez l'administration puis **Contenus → Page Builder** et cliquez sur **« Créer une page »**. L'édition se répartit sur deux onglets.
### Onglet Éditeur
Ajoutez d'abord une **section** (avec un choix de disposition de colonnes), puis déposez des **blocs** dans les colonnes. Chaque bloc peut être glissé-déposé, monté ou descendu, dupliqué ou supprimé, et toutes les actions sont annulables/rétablissables (undo/redo). Le canvas affiche des **aperçus visuels en direct** : images, vignettes de galerie, texte riche, boutons, noms de produits et champs de formulaire.
### Onglet Paramètres & SEO
Vous y définissez le **nom** de la page, son **slug**, son **statut**, la **planification**, les **canaux de vente** d'affectation, le **méta-titre**, la **méta-description** et l'option **noindex**. Le slug est **généré automatiquement** à partir du nom, son **unicité est validée par langue**, et tout changement de slug crée une **redirection 301** automatique depuis l'ancienne URL.
## Blocs disponibles
Le builder livre **15 types de blocs**, déclarés dans le `BlockRegistry` :
- **Structure & texte** : titre, texte riche (édition WYSIWYG via `sw-text-editor`), séparateur, espaceur, citation.
- **Média** : image, galerie (sélecteur multi-images), vidéo (façade RGPD YouTube/Vimeo), HTML/embed.
- **Interaction** : bouton, accordéon (éditeur d'items visuel), compte à rebours, formulaire (éditeur de champs visuel).
- **E-commerce** : produit unique et listing produits.
Le bloc **HTML** permet d'insérer du code libre : il est réservé à un privilège ACL dédié (`editor_html`) et son contenu passe par la sanitisation serveur.
## Publier, planifier et versionner
Une page connaît quatre statuts : `draft` (brouillon), `scheduled` (planifiée), `published` (publiée) et `archived` (archivée).
- **Enregistrer le brouillon** met à jour le contenu de travail (`draftContent`) **sans** toucher à la version en ligne.
- **Publier** copie le brouillon vers la version publiée (`publishedContent`) et crée une **version d'historique**. La publication depuis l'administration traite **toutes les langues en une fois**, avec un avertissement si une traduction est manquante.
- **Planifier** : passez la page en statut « Planifiée » avec une date ; une **tâche planifiée s'exécute toutes les 5 minutes** pour publier automatiquement les pages arrivées à échéance (toutes langues).
## Prévisualisation
Le bouton **Prévisualiser** ouvre le storefront via un **lien signé et expirable** (`/dfpb/preview/{pageId}?token=…`) : le brouillon est visible sans compte administrateur, la page n'est jamais mise en cache et renvoie un en-tête `X-Robots-Tag: noindex, nofollow`.
Le lien de prévisualisation s'ouvre sur l'hôte de l'administration. Si votre storefront est sur un autre domaine, recopiez le lien sur le bon domaine. La durée de validité du lien se règle dans la configuration (défaut : 3600 s).
## Multilingue et multi-canaux
Le nom, le slug, les champs SEO et le contenu sont **traduisibles** par langue Shopware. Une page s'affecte à un ou plusieurs **canaux de vente** ; elle n'est servie sur `/p/{slug}` que pour les canaux auxquels elle est rattachée, dans la langue du contexte courant.
## SEO
Par page et par langue, vous gérez le méta-titre, la méta-description et l'indexation (`noindex`). Le contrôleur storefront injecte ces méta-données dans la page rendue et force `noindex,nofollow` en prévisualisation. Les changements de slug génèrent des redirections 301 pour préserver le référencement.
## Configuration
Rendez-vous dans **Extensions → Mes extensions → DataFirefly Page Builder → Configuration**. La carte _Général_ expose deux réglages :
- **Durée de vie du lien de prévisualisation** (`previewTokenLifetime`, défaut : **3600** secondes).
- **Rétention des soumissions de formulaires** (`submissionRetentionDays`, défaut : **90** jours ; `0` = conservation illimitée).
## Formulaires
Le bloc formulaire se configure avec un **éditeur de champs visuel** et intègre une protection anti-spam par **honeypot** et **piège temporel**, ainsi qu'un **consentement RGPD obligatoire**. Les soumissions sont stockées en base avec une **purge automatique** selon la rétention configurée. À chaque envoi, un événement `FormSubmittedEvent` est déclenché pour brancher vos intégrations (Flow Builder, e-mail, webhook, etc.).
## Architecture technique
Le plugin suit les conventions Shopware 6.7 : entités déclarées via la Data Abstraction Layer (DAL), contenu stocké en JSON versionné, contrôleurs storefront et API, tâches planifiées Messenger et migrations SQL.
### Entités et Data Abstraction Layer
L'entité principale `datafirefly_pb_page` (`PageDefinition`) porte le statut, les dates `publishedAt`/`scheduledAt`, l'option `noIndex`, ainsi que les champs traduisibles `name`, `slug`, `metaTitle`, `metaDescription`, `draftContent` et `publishedContent`. Elle est associée en `ManyToMany` aux canaux de vente et en `OneToMany` à ses versions (avec `CascadeDelete`). Les six entités du plugin utilisent le préfixe `datafirefly_pb_` :
- `datafirefly_pb_page` et `datafirefly_pb_page_translation` : la page et ses traductions.
- `datafirefly_pb_page_sales_channel` : affectation aux canaux de vente.
- `datafirefly_pb_page_version` : snapshots du contenu créés à la publication.
- `datafirefly_pb_saved_block` : blocs sauvegardés réutilisables.
- `datafirefly_pb_form_submission` : soumissions de formulaires.
Le contenu de page est un **JSON structuré versionné** (`schemaVersion`) pour permettre les migrations futures. Deux migrations initialisent le schéma : `Migration1781222400InitialSchema` et `Migration1781222402SlugRedirect` (table de redirections de slug).
### Routes
Les contrôleurs sont importés par attributs (`Resources/config/routes.xml`).
- `GET /p/{slug}` → `frontend.dfpb.page.detail` : rend la page publiée (cache HTTP actif). Si le slug ne correspond plus, une redirection **301** est émise vers le nouveau slug via la table de redirections.
- `GET /dfpb/preview/{pageId}?token=…` → `frontend.dfpb.page.preview` : rendu du brouillon avec token signé, sans cache, en `noindex,nofollow`.
- `GET /api/_action/dfpb/preview-token/{pageId}` : génère un token de prévisualisation (ACL `datafirefly_pb_page:read`).
- `POST /api/_action/dfpb/publish/{pageId}` : publie la page (ACL `datafirefly_pb_page:update`).
### Tâches planifiées
- **PublishScheduledPagesTask** : publie les pages planifiées arrivées à échéance (exécution toutes les 5 minutes).
- **CleanupFormSubmissionsTask** : purge les soumissions de formulaires au-delà de la rétention configurée.
### Contrôle d'accès (ACL)
Le plugin déclare des privilèges autour de l'entité page : `datafirefly_pb_page.viewer`, `.editor`, `.creator` et `.deleter`, plus un privilège distinct `editor_html` requis pour éditer le bloc HTML. Shopware compose les rôles administrateur à partir de ces privilèges.
### Sécurité et sanitisation
Tout contenu riche est assaini côté serveur via le filtre Twig `dfpb_sanitize` (whitelist de balises), les types de blocs sont eux-mêmes soumis à une whitelist, et les styles inline sont filtrés par expression régulière. Le JSON de page ne peut jamais injecter de Twig brut ; l'échappement Twig par défaut s'applique au rendu. Les tokens de prévisualisation sont signés (HMAC via `APP_SECRET`) et expirables.
### Extension par des plugins tiers
Pour ajouter un bloc custom, décorez le service `DataFirefly\PageBuilder\Service\BlockRegistry` et appelez `register(type, template, label)` pour enregistrer le type et son template Twig de rendu, puis déclarez le type correspondant côté administration (composant d'édition Vue).
## Confidentialité (RGPD)
Les blocs à contenu tiers utilisent une **façade à consentement** : la vidéo YouTube (`youtube-nocookie`) ou Vimeo (`dnt=1`) n'est chargée qu'après un clic explicite — aucun appel tiers au chargement de la page. Les formulaires imposent un consentement RGPD, et les soumissions font l'objet d'une **purge automatique** selon la rétention configurée.
## Limites connues de la v1
- L'éditeur d'administration est **structurel** (canvas par blocs), et non un WYSIWYG en iframe du storefront réel.
- La publication manuelle copie le brouillon vers la version publiée ; la publication planifiée couvre toutes les langues.
- Ne sont pas encore inclus : templates de pages prêts à l'emploi, blocs globaux synchronisés, règles de visibilité (Rule Builder), import/export, surcharges responsive par point de rupture et assistant IA.
## Désinstallation
À la désinstallation, les tables du plugin (`datafirefly_pb_slug_redirect`, `datafirefly_pb_form_submission`, `datafirefly_pb_saved_block`, `datafirefly_pb_page_version`, `datafirefly_pb_page_sales_channel`, `datafirefly_pb_page_translation`, `datafirefly_pb_page`) sont supprimées — **sauf** si l'option « conserver les données de l'utilisateur » est cochée.
## Dépannage
- **Une page publiée renvoie 404** : vérifiez que la page est bien en statut « publiée », que son slug est correct et qu'elle est affectée au canal de vente courant.
- **Le module d'administration ne se charge pas** : relancez `bin/build-administration.sh`, `assets:install` puis `cache:clear`, et forcez le rechargement navigateur (Ctrl+F5).
- **Le lien de prévisualisation est invalide ou expiré** : régénérez-le ; vérifiez que `APP_SECRET` est défini et augmentez au besoin la durée de vie du token dans la configuration.
- **La publication planifiée ne se déclenche pas** : assurez-vous que le worker Shopware (Messenger / scheduled tasks) tourne ; la tâche s'exécute toutes les 5 minutes.
- **Les soumissions de formulaires ne sont pas purgées** : vérifiez la valeur de rétention dans la configuration (`0` = illimité) et que la tâche de nettoyage est bien planifiée.
---
### DataFirefly Price Alert — Documentation
_Source :_
> Présentation DataFirefly Price Alert ajoute une alerte de baisse de prix à votre boutique PrestaShop 8 ou 9. Vos visiteurs s'inscrivent depuis la fiche produit (avec ou sans compte client),…
## Présentation
DataFirefly Price Alert ajoute une alerte de baisse de prix à votre boutique PrestaShop 8 ou 9. Vos visiteurs s'inscrivent depuis la fiche produit (avec ou sans compte client), choisissent entre deux modes — **toute baisse** ou **prix cible** — et reçoivent un email dès que le prix descend. Chaque commande passée par un abonné notifié est automatiquement attribuée comme conversion, avec le chiffre d'affaires récupéré visible dans le dashboard admin.
## Installation
1. Dans le back-office, allez dans **Modules → Gestionnaire de modules → Installer un module**.
2. Uploadez le fichier `dfpricealert-x.x.x.zip`.
3. Cliquez sur **Installer**. Le module crée deux tables (`df_pricealert_subscriber` et `df_pricealert_event`), enregistre ses hooks et ajoute l'onglet **Price Alerts** sous Catalogue.
Aucune dépendance Composer n'est requise : le module embarque un autoloader PSR-4 autonome. PHP 8.0 minimum.
## Configuration
Rendez-vous dans **Modules → DataFirefly Price Alert → Configurer**. Les réglages disponibles :
- **Double opt-in (RGPD)** — activé par défaut. L'abonné reçoit un email de confirmation et l'alerte ne devient active qu'après son clic. Fortement recommandé pour la conformité RGPD.
- **Mode d'alerte par défaut** — le mode pré-sélectionné sur le formulaire : toute baisse ou prix cible. Le client peut toujours changer.
- **Position du formulaire** — `displayProductActions` (sous le bouton d'achat) ou `displayProductAdditionalInfo` (zone d'informations complémentaires).
- **Pourcentage de baisse minimum** — en mode toute baisse, ignorer les baisses inférieures à N %. 0 = toute baisse déclenche.
- **Seuil d'alerte marchand** — recevez un email quand un produit atteint N abonnés actifs. 0 désactive.
- **Email marchand** — destinataire de l'alerte ci-dessus (par défaut : email de la boutique).
- **Rétention (jours)** — auto-purge des abonnés désinscrits/notifiés plus anciens que N jours. 180 par défaut, 0 désactive.
## Fonctionnement côté client
### Inscription
Le formulaire est toujours visible sur la fiche produit. Le client saisit son email et choisit :
- **Toute baisse** — il sera prévenu à la première réduction sous le prix affiché au moment de l'inscription (sous réserve du seuil minimum configuré).
- **Quand il atteint** — il saisit un prix cible, obligatoirement inférieur au prix actuel. L'alerte part uniquement quand le prix descend à ce niveau ou en dessous.
Si le produit a des déclinaisons, la combinaison sélectionnée est capturée automatiquement — et mise à jour si le client change de déclinaison avant de valider.
### Confirmation (double opt-in)
Avec le double opt-in actif, l'abonné reçoit un email de confirmation. L'alerte reste en statut `pending` jusqu'au clic, puis passe en `active`. Sans double opt-in, l'alerte est active immédiatement.
### Notification
Quand une baisse éligible est détectée, l'abonné reçoit un email avec l'ancien prix barré, le nouveau prix, le pourcentage de réduction, le montant économisé, et un lien direct vers le produit. Son statut passe en `notified` — il ne recevra pas d'autre email pour la même inscription.
## Détection des baisses : les trois triggers
Le module détecte les baisses de prix par trois canaux complémentaires :
1. **Hook actionObjectProductUpdateAfter** — se déclenche à chaque sauvegarde d'un produit dans le back-office. Couvre les modifications manuelles de prix avec une latence nulle.
2. **Hook actionUpdateProductAttribute** — se déclenche à la modification d'une déclinaison. Couvre les changements de prix par combinaison.
3. **Commande CLI bin/scan-prices.php** — à brancher en cron. Indispensable pour les _prix spécifiques programmés_ (specific prices à date), qui s'activent sans déclencher aucun hook.
### Mise en place du cron
```
*/30 * * * * php /chemin/vers/votre/boutique/modules/dfpricealert/bin/scan-prices.php --shop=1 >> /var/log/dfpricealert.log 2>&1
```
Le paramètre `--shop` est optionnel (boutique par défaut sinon). La commande affiche le nombre d'alertes envoyées et le temps d'exécution.
Configuration recommandée : laissez les hooks actifs (latence zéro sur les modifications manuelles) et ajoutez le cron toutes les 30 minutes pour couvrir les promotions programmées.
## Tracking de conversion
Sur le hook `actionOrderStatusPostUpdate`, le module parcourt chaque ligne de la commande et recherche un abonné en statut `notified` correspondant au triplet (email du client, id produit, id déclinaison). En cas de correspondance, l'abonné passe en `purchased` et l'`id_order` est enregistré.
Le match accepte soit la déclinaison exacte, soit une inscription générique (déclinaison 0) — les produits sans déclinaison et les inscriptions « produit principal » sont donc correctement attribués. Le tracking fonctionne aussi en guest checkout, car la correspondance se fait par email.
## Dashboard admin
L'onglet **Catalogue → Price Alerts** affiche :
- **6 KPI** — abonnés actifs, notifiés, convertis, taux de conversion, baisse moyenne consentie, chiffre d'affaires récupéré.
- **Produits à fort potentiel** — top 10 des produits par nombre d'abonnés actifs, avec prix moyen d'inscription. C'est votre liste de candidats prioritaires pour une promotion ciblée.
- **Liste des abonnés** — filtrable par statut, email et produit, paginée à 25 lignes.
- **Actions** — scanner tous les produits immédiatement, purger les anciennes entrées, exporter la liste complète en CSV.
## Cycle de vie d'un abonné
Chaque inscription passe par les statuts suivants :
- `pending` — inscrit, en attente de confirmation (double opt-in).
- `active` — alerte active, surveillée par les scans.
- `notified` — email de baisse envoyé. Statut terminal sauf achat.
- `purchased` — commande détectée après notification, conversion attribuée.
- `unsubscribed` — désinscription via le lien présent dans chaque email.
Chaque transition est journalisée dans la table `df_pricealert_event` (audit trail complet).
## Emails
Trois modèles, chacun fourni en FR/EN/ES/DE au format HTML + texte :
- **confirm** — confirmation double opt-in avec bouton d'activation.
- **alert** — notification de baisse : ancien prix barré, nouveau prix en évidence, économie en euros et en pourcentage, bouton vers le produit.
- **merchant** — notification au marchand quand un produit dépasse le seuil d'abonnés actifs.
L'email part dans la langue de l'abonné (celle de la page au moment de l'inscription), avec repli automatique sur l'anglais si la langue n'est pas disponible. Les modèles sont personnalisables dans `modules/dfpricealert/mails//`.
## RGPD
- Double opt-in par email avant activation (activé par défaut).
- Tokens cryptographiques 32 octets (`random_bytes`) uniques par abonné pour la confirmation et la désinscription.
- Lien de désinscription en un clic dans chaque email.
- Auto-purge configurable des données anciennes (minimisation des données).
- Aucune donnée envoyée à des services tiers — tout reste sur votre serveur.
## Dépannage
### Les alertes ne partent pas
- Vérifiez que l'abonné est en statut `active` (pas `pending` — le double opt-in exige la confirmation).
- Vérifiez le seuil de baisse minimum : une baisse de 3 % avec un seuil à 5 % ne déclenche pas.
- En mode prix cible, le prix doit atteindre ou passer sous la cible — pas seulement baisser.
- Pour les prix spécifiques programmés, vérifiez que le cron tourne (consultez le log).
- Testez l'envoi d'email PrestaShop en général (Paramètres avancés → E-mail → Test).
### Erreurs lors de l'inscription
Le module journalise toutes les erreurs dans **Paramètres avancés → Logs** avec le préfixe `[dfpricealert]`. Le formulaire affiche par ailleurs les erreurs serveur détaillées directement sous le bouton (statut HTTP et extrait de la réponse), ce qui accélère le diagnostic.
### Le formulaire n'apparaît pas
- Vérifiez la position configurée : certains thèmes n'implémentent pas `displayProductAdditionalInfo` — basculez sur `displayProductActions`.
- Videz le cache PrestaShop (Paramètres avancés → Performances).
## Désinstallation
La désinstallation supprime les deux tables du module (abonnés et événements inclus), les hooks, l'onglet admin et toutes les clés de configuration. Exportez le CSV avant si vous souhaitez conserver l'historique.
---
### DataFirefly Product Order — Guide complet
_Source :_
> Guide complet d'installation, de configuration et d'utilisation de DataFirefly Product Order pour trier vos produits WooCommerce par glisser-déposer.
DataFirefly Product Order ajoute une page d'administration dédiée pour définir, par simple glisser-déposer, l'ordre d'affichage de vos produits WooCommerce. Vous pouvez fixer un ordre global pour toute la boutique ou un ordre indépendant pour chaque catégorie. L'ordre personnalisé ne s'applique au front que lorsque le client utilise le tri par défaut : les tris par prix, popularité ou note restent intacts. Ce guide couvre l'installation, l'écran de tri, la différence entre ordre global et ordre par catégorie, l'application au front, la règle « rupture de stock en bas », la performance, la compatibilité et le dépannage.
## Installation
1. Téléchargez l'archive `df-product-order.zip` depuis votre compte DataFirefly.
2. Back-office WordPress → **Extensions** → **Ajouter** → **Téléverser une extension** → envoyez le ZIP, puis **Activer**.
3. À l'activation, l'extension crée sa table de positions (`wp_dfpord_order`) et ajoute l'entrée **Produits → Ordre des produits**.
Nécessite WordPress 6.4 ou supérieur, PHP 8.0 ou supérieur et WooCommerce 7.0 ou supérieur. Compatible HPOS (stockage haute performance des commandes), multisite et multilingue. Aucune dépendance Composer, aucun service externe.
## Prise en main en deux minutes
1. Ouvrez **Produits → Ordre des produits**.
2. Dans le menu **Portée**, laissez « Ordre global (boutique) » ou choisissez une catégorie.
3. Glissez-déposez les produits dans l'ordre souhaité à l'aide de la poignée située à gauche de chaque ligne. Chaque dépôt est enregistré automatiquement.
4. Visitez votre boutique : les produits apparaissent dans le nouvel ordre dès que le tri actif est « par défaut ».
Pour un résultat visible immédiatement, vérifiez que le tri par défaut de votre boutique est bien « Tri par défaut » (Réglages WooCommerce → Produits → Affichage), et non un tri par date ou par prix.
## L'écran « Ordre des produits »
Toute la gestion se fait depuis **Produits → Ordre des produits**. L'écran comprend une barre d'outils et la liste triable.
### Barre d'outils
- **Portée** : choisissez « Ordre global (boutique) » ou une catégorie de produits précise. Changer de portée recharge la liste correspondante.
- **Rechercher** : filtre la liste par nom de produit, utile pour retrouver rapidement un article dans une grande catégorie.
- **Produits en rupture en bas** : interrupteur qui active la règle automatique côté boutique (voir plus bas). Son état est enregistré dès que vous le modifiez.
### Liste triable
Chaque ligne affiche une poignée de déplacement, la vignette du produit, son nom (avec un badge _Rupture_ le cas échéant) et son prix. Saisissez une ligne par sa poignée, déplacez-la, relâchez : l'ordre est sauvegardé en arrière-plan et un message « Ordre enregistré » confirme l'opération.
La liste charge jusqu'à 200 produits par portée, ce qui est largement suffisant pour trier une catégorie. Pour une très grande boutique, privilégiez le tri catégorie par catégorie plutôt que la vue globale.
## Ordre global ou ordre par catégorie
Les deux portées sont indépendantes et cohabitent sans conflit.
### Ordre global (boutique)
Définit l'ordre utilisé sur la page boutique et partout où les produits sont affichés sans contexte de catégorie. Pour rester compatible avec votre thème et vos autres extensions, l'ordre global synchronise le champ natif `menu_order` de chaque produit.
### Ordre par catégorie
Chaque catégorie conserve son propre ordre, stocké dans la table dédiée `wp_dfpord_order`. Un même produit peut donc figurer en tête d'une catégorie et plus bas dans une autre. Cet ordre s'applique sur les pages d'archive de catégorie de produits.
Définissez d'abord un ordre global propre, puis affinez catégorie par catégorie uniquement là où c'est nécessaire. Les produits sans position dans une catégorie se placent automatiquement après ceux qui en ont une, selon l'ordre global puis le titre.
## Application au front
L'ordre personnalisé ne remplace jamais le choix de tri de vos visiteurs. Il s'applique uniquement lorsque le tri actif est le **tri par défaut** de la boutique. Dès qu'un client sélectionne « Trier par tarif », « par popularité » ou « par note moyenne », son choix prévaut et l'ordre personnalisé est ignoré pour cette page.
- Page **Boutique** et listes sans catégorie : ordre global.
- Pages d'**archive de catégorie** : ordre de la catégorie concernée (à défaut, repli sur l'ordre global puis le titre).
## Règle « rupture de stock en bas »
Activée via l'interrupteur de la barre d'outils, cette règle repousse automatiquement les produits en rupture de stock en fin de liste, côté boutique, tout en conservant votre ordre personnalisé pour les produits disponibles. Elle s'ajoute au tri par défaut sans affecter les tris choisis par le client.
La règle agit à l'affichage : elle ne modifie pas l'ordre que vous avez enregistré. Désactivez l'interrupteur pour revenir à un classement strictement manuel.
## Volume, performance et limites
- Les positions sont mises en cache (cache objet) pour éviter des requêtes répétées et garder des pages boutique rapides.
- L'écran d'administration charge au maximum 200 produits par portée ; ce plafond peut être relevé par un développeur en ajustant la limite de chargement dans le code.
- L'enregistrement d'un nouvel ordre met à jour les positions de la portée et, pour l'ordre global, le champ `menu_order` des produits concernés.
## Compatibilité et notes techniques
- WordPress 6.4+, PHP 8.0 à 8.3, WooCommerce 7.0+, multisite.
- Compatibilité HPOS (stockage haute performance des commandes) déclarée.
- Ordre global stocké via le champ natif `menu_order` ; ordre par catégorie stocké dans la table `wp_dfpord_order` (clé unique produit + catégorie).
- Application au front via le filtrage des clauses de requête, uniquement sur le tri par défaut.
- Multilingue : un modèle de traduction `.pot` est fourni (compatible Polylang, WPML, Loco Translate).
- Architecture PSR-4 avec autoloader, sans dépendance Composer ni appel à un service tiers.
## Désinstallation
La suppression de l'extension depuis l'écran des extensions exécute un nettoyage complet : la table `wp_dfpord_order` est supprimée et les options du plugin sont effacées. Le champ `menu_order` des produits, étant une donnée native de WooCommerce, est conservé. La simple désactivation ne supprime aucune donnée.
## FAQ et dépannage
**L'ordre n'apparaît pas sur la boutique.** Vérifiez que le tri par défaut est sélectionné (et non un tri par prix ou par date). Contrôlez aussi le réglage WooCommerce → Produits → Affichage et videz le cache si vous utilisez une extension de cache de pages.
**Mon ordre par catégorie n'est pas pris en compte.** Assurez-vous d'avoir sélectionné la bonne catégorie dans le menu « Portée » avant de trier, et de consulter la page d'archive de cette catégorie au front (et non la page boutique).
**Le glisser-déposer ne réagit pas.** Forcez le rechargement de la page (cache du navigateur) et vérifiez qu'aucune extension de minification ou de blocage JavaScript n'empêche le chargement des scripts d'administration.
**Un produit n'apparaît pas dans la liste.** La liste est limitée à 200 produits par portée et n'affiche que les produits publiés. Utilisez le champ de recherche, ou triez par catégorie pour réduire le volume.
**Les produits en rupture ne descendent pas.** Activez l'interrupteur « Produits en rupture en bas » ; la règle ne s'applique qu'au tri par défaut, pas aux tris par prix, popularité ou note.
---
### DataFirefly Product Video
_Source :_
> Guide d'utilisation du module DataFirefly Product Video : ajout de vidéos (MP4, YouTube, Vimeo) dans la galerie produit PrestaShop.
## Présentation
**DataFirefly Product Video** ajoute des vidéos directement dans la galerie de miniatures de la fiche produit PrestaShop, aux côtés des images. Trois sources sont prises en charge : fichiers hébergés (MP4, WebM, OGG), **YouTube** et **Vimeo**. Chaque vidéo dispose de son propre poster, de ses options de lecture et d'une position personnalisable.
- Compatibilité : PrestaShop 8.0 à 8.9
- Multiboutique : oui
- Multilingue : titre et description traduisibles par langue
- Version : 1.0.0
## Installation
1. Dans le back-office, allez dans _Modules > Module Manager_.
2. Cliquez sur _Charger un module_ et sélectionnez le fichier `dfproductvideo.zip`.
3. Le module crée automatiquement ses tables et les dossiers d'upload (`img/dfproductvideo/videos` et `img/dfproductvideo/posters`).
4. Cliquez sur _Configurer_ pour définir les réglages par défaut.
## Configuration globale
La page de configuration définit les valeurs appliquées par défaut à chaque nouvelle vidéo :
- **Autoplay** – lecture automatique (le mode muet est requis par Chrome et Safari).
- **Muet** – obligatoire si l'autoplay est activé.
- **Boucle** – relit la vidéo en continu.
- **Afficher les contrôles** – barre de lecture native.
- **Chargement paresseux (lazy load)** – charge la vidéo seulement quand elle devient visible.
- **Lightbox / Plein écran** – ouverture de la vidéo en superposition.
- **Responsive** – adaptation à la largeur de l'écran.
- **Analytics** – comptage du nombre de lectures par vidéo.
- **Taille max fichier (Mo)** – limite d'upload, 50 Mo par défaut.
- **Extensions autorisées** – par défaut `mp4,webm,ogg`.
- **Couleur et fond de l'icône Play** – personnalisation du bouton de lecture.
## Ajouter une vidéo à un produit
1. Ouvrez une fiche produit dans le back-office.
2. Rendez-vous dans l'onglet **Vidéos** ajouté par le module.
3. Choisissez la source : fichier à téléverser, lien YouTube ou lien Vimeo.
4. Renseignez si besoin un **poster** (image de couverture) et un **titre / description** par langue.
5. Ajustez les options de lecture (autoplay, muet, boucle, contrôles) si elles diffèrent des valeurs par défaut.
6. Enregistrez. La vidéo apparaît dans la galerie du produit.
Les vidéos peuvent être réordonnées par glisser-déposer, activées ou désactivées, et l'une d'elles peut être désignée comme **vidéo de couverture** (une seule par produit et par boutique).
## Posters automatiques
Si aucun poster n'est fourni, le module génère automatiquement une image d'aperçu : la miniature YouTube (`hqdefault`) pour les vidéos YouTube, et la vignette Vimeo pour les vidéos Vimeo. Pour les fichiers téléversés, fournir un poster manuellement est recommandé.
## Affichage en front-office
Les vidéos s'insèrent dans la galerie de miniatures de la fiche produit, juste après les images. Au clic, la vidéo se lit en place ou s'ouvre en lightbox selon la configuration. Les vidéos uploadées utilisent le lecteur HTML5 natif ; YouTube et Vimeo sont intégrés via leur lecteur officiel avec les paramètres correspondant aux options choisies (autoplay, muet, boucle, contrôles).
## Analytics
Lorsque l'option Analytics est active, chaque lecture incrémente un compteur (`play_count`) stocké en base. Cela permet de mesurer l'engagement vidéo par produit.
## Désinstallation
La désinstallation supprime les tables du module ainsi que ses réglages. Les fichiers vidéo et posters associés aux produits sont également nettoyés.
## Détails techniques
- Tables : `dfproductvideo` (vidéos et options) et `dfproductvideo_lang` (titre / description traduits).
- Hooks utilisés : `displayAdminProductsExtra`, `displayAfterProductThumbs`, `actionFrontControllerSetMedia`, `actionProductUpdate`, `actionProductDelete`, `displayBackOfficeHeader`.
- Gestion des vidéos via contrôleur AJAX (enregistrement, suppression, réordonnancement, activation).
- Suivi des lectures via contrôleur front dédié.
---
### DataFirefly Push — Guide complet
_Source :_
> Présentation et prérequis DataFirefly Push transforme votre boutique WooCommerce en plateforme de notifications Web Push native. Sans SDK, sans tracking de tiers : toute la cryptographie (VAPID et chiffrement RFC…
## Présentation et prérequis
DataFirefly Push transforme votre boutique WooCommerce en plateforme de notifications Web Push native. Sans SDK, sans tracking de tiers : toute la cryptographie (VAPID et chiffrement RFC 8291) tourne sur votre serveur en PHP pur via OpenSSL. Le plugin couvre un opt-in intelligent multi-styles, dix triggers automatiques, des campagnes manuelles avec builder visuel et segmentation, un dashboard d'analytics complet, une page Mon compte dédiée pour vos clients, et une conformité RGPD native.
- WordPress 6.2 et supérieur.
- WooCommerce 7.0 et supérieur, testé jusqu'à 9.6, compatible HPOS et Cart/Checkout Blocks.
- PHP 8.1 et supérieur.
- Multilingue (FR/EN/ES/DE/IT), compatible Polylang et WPML.
- Compatible LiteSpeed Cache, WP Rocket et autres plugins de cache : le Service Worker est servi en standalone PHP.
Aucun service tiers à brancher, aucune librairie Composer à maintenir. Les clés VAPID sont générées automatiquement à l'activation, les abonnements et les évènements restent stockés dans votre base de données.
## Installation
1. Téléchargez l'archive `df-push.zip` depuis votre compte client.
2. Dans l'admin WordPress, allez dans **Extensions > Ajouter > Téléverser une extension** et déposez l'archive.
3. Cliquez sur **Activer**.
4. Le menu **DF Push** apparaît dans la barre latérale d'administration avec sept sous-menus : Dashboard, Campagnes, Abonnés, Triggers, Opt-in, Réglages, Webhooks & API.
À l'activation, le plugin crée huit tables dédiées préfixées `dfpush_`, génère vos clés VAPID, planifie le cron quotidien `df_push_daily_lifecycle` et enregistre l'endpoint Mon compte. Aucune intervention manuelle n'est requise.
## Première configuration : clés VAPID et opt-in
Une fois activé, le plugin est immédiatement fonctionnel avec ses réglages par défaut : la cloche flottante apparaît en bas à droite après cinq secondes, le pre-prompt est activé, les triggers automatiques sont prêts. Vérifiez simplement deux choses dans **DF Push > Réglages** avant de communiquer sur le service :
- **Clé publique VAPID** : le bloc affiche votre clé publique générée automatiquement (l'application server key utilisée par le navigateur). Vous pouvez la régénérer mais cela invalidera tous les abonnements existants.
- **Manifest PWA** et **icône par défaut** : ajoutez votre icône (192×192 minimum) si `site_icon` n'est pas défini sur le site.
Aucun service externe à enregistrer, aucun compte développeur Firebase / OneSignal à créer. Les clés VAPID que le plugin génère suffisent : elles authentifient votre serveur d'application auprès des push services FCM, Mozilla Push et WNS.
## Onglet Opt-in — prompt, styles et déclencheurs
Cet onglet pilote la demande d'abonnement. Cinq styles disponibles, chacun positionnable et thématisable :
- **Cloche flottante** (par défaut) : pastille discrète en bas à droite ou en bas à gauche.
- **Bannière** en haut ou en bas de la page.
- **Modal** centré avec overlay.
- **Slide-in** latéral.
- **Sticky bar** fixée en haut.
Le **pre-prompt soft ask** (recommandé) affiche votre message personnalisé avant la demande native du navigateur. Ce mécanisme préserve votre quota d'opt-in : sur Chrome, refuser le pre-prompt n'épuise pas le quota de demandes natives (×3 contre 1 sans pre-prompt).
Cinq déclencheurs configurables, combinables :
- **Délai** (en secondes) après chargement de la page.
- **Scroll** en pourcentage de la page (0 = désactivé).
- **Exit-intent** au mouvement de sortie de la souris (desktop uniquement).
- **X pages vues** dans la session.
- **Ajout au panier** (capture l'événement WooCommerce `added_to_cart`).
Activez l'**A/B test du prompt** avec un titre et un message variante B, et un split configurable. La répartition est persistée en localStorage pour assurer une cohérence inter-sessions par visiteur.
Une fois la permission navigateur refusée, elle ne peut pas être redemandée par script. Soignez votre pre-prompt et n'enchaînez pas une demande sur le premier scroll : on observe alors 70 % de refus contre 20-30 % avec un pre-prompt déclenché au bon moment.
## Onglet Triggers — les automatismes
Dix triggers automatiques, tous activables individuellement depuis l'onglet **Triggers**. Chacun s'appuie sur Action Scheduler pour les envois différés, avec un fallback synchrone si Action Scheduler n'est pas disponible.
### Panier abandonné
Trois relances configurables, par défaut à 1 heure, 24 heures et 72 heures après l'abandon. La détection capture l'événement `added_to_cart` pour les utilisateurs abonnés au Push et planifie trois actions `df_push_abandoned_cart` à intervalles décroissants. Les relances sont annulées automatiquement si la commande est passée entre-temps.
### Retour en stock (back-in-stock)
Sur la page produit, vos visiteurs abonnés peuvent rejoindre une liste d'attente par produit. Quand WooCommerce déclenche `woocommerce_product_set_stock_status` avec un retour à _instock_, le plugin envoie une notification à la liste d'attente du produit, puis la vide.
### Baisse de prix
Le plugin maintient une méta `_df_push_last_price` par produit. À chaque mise à jour de produit, il compare l'ancien et le nouveau prix. Si la baisse dépasse le **seuil minimum en pourcentage** configuré, une notification est envoyée au topic _Promos_.
### Confirmation, expédition, avis
- **Confirmation de commande** : envoi immédiat sur `woocommerce_thankyou` à l'abonné si l'identifiant utilisateur correspond.
- **Expédition** : détecte le numéro de suivi sur la commande en lisant successivement les méta `_tracking_number`, `_wc_shipment_tracking_items` (WooCommerce Shipment Tracking) et `_aftership_tracking_number` (AfterShip). Si un numéro est trouvé, la notification l'inclut dans son message.
- **Demande d'avis** : programmée X jours après le passage de la commande au statut _completed_ (délai configurable).
### Anniversaire, réengagement, nouveau produit
- **Anniversaire** : le cron quotidien `df_push_daily_lifecycle` lit le champ `billing_birthday` de WooCommerce et envoie une notification aux abonnés dont c'est l'anniversaire.
- **Réengagement** : envoi aux abonnés inactifs depuis 30, 60 et 90 jours (fenêtres configurables en CSV : `30,60,90`).
- **Nouveau produit** : à la publication d'un produit, une notification est envoyée au topic _Nouveautés_.
Chaque trigger accepte un payload templatisé : `{firstname}`, `{product_name}`, `{product_price}`, `{old_price}`, `{order_number}`, `{tracking_number}`, `{category}`, `{discount_code}`. Les variables sont résolues au moment de l'envoi, pas à la planification.
## Onglet Campagnes — builder visuel, segmentation, A/B test
Construisez une campagne manuelle dans **DF Push > Campagnes > Nouvelle campagne**. Le builder propose un aperçu live de la notification telle qu'elle apparaîtra sur l'appareil de l'abonné.
- **Contenu** : titre, message, URL de destination, image hero, jusqu'à deux boutons d'action avec libellé et URL propres.
- **Notification persistante** (option _requireInteraction_) : la notification reste affichée jusqu'à interaction.
- **Segmentation** par langue, pays, device, topic, et par comportement RFM : commandes minimum, panier moyen minimum, jours d'inactivité, catégorie achetée. Les segments comportementaux sont calculés via `wc_get_orders` au lancement.
- **A/B test** : activez une variante B (titre et message), le split est configurable en pourcentage. La répartition est aléatoire par abonné, déterministe par identifiant pour la cohérence des analytics.
- **Planification** : choisissez la date et l'heure, ou lancez immédiatement.
- **Mode test** : envoyez la campagne aux administrateurs uniquement, depuis le builder, avant le lancement de production.
Le moteur d'envoi fragmente automatiquement le segment, respecte les quiet hours par fuseau horaire de l'abonné, applique le frequency capping configuré, et purge à la volée les endpoints qui retournent 404 ou 410 (désabonnement côté navigateur).
## Dashboard et analytics
Le tableau de bord **DF Push > Dashboard** agrège vos KPIs sur 30 jours. Chart.js est bundlé localement (aucune dépendance CDN externe).
- **KPIs** : abonnés actifs, taux d'opt-in, envois, taux de clic (CTR), conversions, revenu attribué.
- **Série temporelle 30 jours** : envois versus clics, ligne par jour.
- **Heatmap 7 × 24** : meilleurs créneaux d'envoi en fonction des clics, croisée jour de la semaine et heure de la journée.
- **Funnel par campagne** : envoyé > livré > cliqué > converti.
- **Revenu attribué** : une fenêtre d'attribution configurable (par défaut 72 heures) lie chaque clic au premier achat passé dans la fenêtre par cet abonné.
- **Export CSV** de tous les événements pour audit RGPD ou intégration BI.
## Page client : Mon compte → Notifications
Une page dédiée **Mon compte → Notifications** est ajoutée automatiquement au tableau de bord WooCommerce. Le client y dispose de quatre blocs :
- **Cet appareil** : statut courant (activé, désactivé, bloqué par le navigateur, non supporté), avec bouton Activer ou Désactiver sur cet appareil.
- **Tous vos appareils** : liste des devices abonnés (type, navigateur, langue, dernière activité), avec désabonnement individuel ou désabonnement total en un clic.
- **Mes préférences** : cases à cocher pour les topics natifs (Nouveautés, Promotions, Retour en stock). Sauvegarde via REST avec confirmation.
- **Historique des notifications** : les 30 dernières notifications reçues, avec titre, corps, icône, lien et date.
L'URL est `/my-account/df-push-notifications/` en français. Le rewrite endpoint est enregistré au mask `EP_ROOT | EP_PAGES`, avec un auto-réparateur sur `init:999` qui détecte une règle manquante (cas d'un permalink flush concurrent) et reflush automatiquement.
Les actions client (désabonnement, préférences) passent par les routes REST sous `df-push/v1/account/*`, authentifiées par cookie + nonce `wp_rest`. Aucune action ne peut être effectuée sur un autre compte, même en cas de manipulation de l'identifiant device dans la requête.
## RGPD et registre de consentement
La conformité RGPD est traitée nativement, pas en ajout cosmétique. Chaque opt-in et chaque désabonnement est inscrit dans la table `dfpush_consent_log` avec :
- Identifiant de l'abonné.
- Action : _subscribe_ ou _unsubscribe_.
- IP hashée en SHA-256 (l'IP en clair n'est jamais persistée).
- User-agent.
- Horodatage UTC.
Les WordPress Privacy Exporters et Erasers natifs sont branchés : un client peut demander l'export ou l'effacement de ses données personnelles depuis **Outils → Exporter les données personnelles** ou **Outils → Effacer les données personnelles**. Le plugin inclut alors ses abonnements, ses topics, son inbox et son registre de consentement dans la réponse — ou les supprime selon la demande.
## Onglet Réglages — anti-spam et attribution
Cet onglet centralise les paramètres de respect des abonnés et la fenêtre d'attribution :
- **Heures calmes** (quiet hours) : intervalle pendant lequel aucune notification n'est envoyée. Sensible au fuseau horaire de l'abonné (lu sur sa device au moment de l'opt-in via `Intl.DateTimeFormat().resolvedOptions().timeZone`). Par défaut 22h-8h locales.
- **Frequency cap** : nombre maximum de notifications par jour par abonné. 0 = illimité.
- **Smart send time** : optimise l'heure d'envoi par abonné en se basant sur ses créneaux de clic historiques.
- **Fenêtre d'attribution** : durée en heures entre un clic et une commande pour que la commande soit attribuée à la notification. Par défaut 72 heures.
- **Inbox in-site** : active ou désactive la cloche flottante avec l'historique des notifications côté front.
- **Manifest PWA** : active la génération du manifest pour rendre le site installable sur mobile.
## Onglet Webhooks et API REST
L'onglet **Webhooks & API** couvre deux mécanismes d'intégration.
### Webhooks sortants
Configurez un ou plusieurs endpoints HTTP par événement. Trois formats sont disponibles :
- **Slack** : payload `{ text }` compatible avec les Incoming Webhooks Slack.
- **Discord** : payload `{ content }` compatible avec les Webhooks Discord.
- **Generic** : payload JSON complet avec event, timestamp, data — compatible Zapier, n8n, Make.
Les événements disponibles : `subscriber.created`, `campaign.launched`, `notification.clicked`, `order.attributed`. Les requêtes sont non-bloquantes (`wp_remote_post` avec `blocking=false`) pour ne jamais ralentir l'envoi principal.
### API REST
Sous le namespace `df-push/v1`, le plugin expose une route publique d'envoi tokenisée : `POST /wp-json/df-push/v1/send` avec l'en-tête `X-DF-Push-Token`. Le token est régénérable en un clic depuis l'admin.
```
curl -X POST https://votre-site.com/wp-json/df-push/v1/send
-H "Content-Type: application/json"
-H "X-DF-Push-Token: VOTRE_TOKEN"
-d '{
"title": "Promo flash",
"body": "20 % sur tout le catalogue jusqu'à minuit",
"url": "https://votre-site.com/promotions",
"segment": { "lang": "fr", "topic": "promos" }
}'
```
Conservez ce token comme un mot de passe. Quiconque le détient peut envoyer des notifications à vos abonnés. Régénérez-le immédiatement si vous suspectez une compromission.
## Inbox in-site, PWA et multilingue
Trois fonctions complémentaires couvrent les cas où l'utilisateur n'a pas autorisé le Push.
- **Inbox in-site** : une cloche flottante (configurable côté front) ouvre une liste des dernières notifications reçues par l'utilisateur, lues ou non, même s'il n'a jamais autorisé le Push. Particulièrement utile pour iOS Safari avant 16.4 et les utilisateurs PWA.
- **Manifest PWA** : généré dynamiquement à `/df-push-manifest.json` à partir de `site_icon` ou d'une icône personnalisée. Filtre `df_push_manifest` disponible pour ajuster theme color, display, scope, start_url.
- **Multilingue** : compatible Polylang et WPML. Les notifications sont envoyées dans la langue de l'abonné (détectée à l'opt-in), avec fallback sur la langue par défaut du site. Les fichiers `.po` et `.mo` en FR, EN, ES, DE, IT sont inclus.
## Service Worker et architecture technique
Le Service Worker est servi par un fichier PHP standalone à l'URL `/wp-content/plugins/df-push/sw.php`. Cette approche court-circuite complètement le routing WordPress : aucune chance d'interférence avec un plugin de cache, un canonical redirect ou un autre handler `template_redirect`.
L'en-tête `Service-Worker-Allowed: /` est envoyé en réponse pour permettre l'enregistrement avec le scope racine (`scope: '/'`), bien que le script vive sous `/wp-content/`.
Côté base de données, huit tables préfixées `dfpush_` :
- `dfpush_subscribers` : abonnés et leur endpoint Push.
- `dfpush_topic_subs` : assignations topic ↔ abonné.
- `dfpush_campaigns` : campagnes manuelles avec payload, segment et planification.
- `dfpush_notifications` : journal des notifications individuelles envoyées.
- `dfpush_events` : événements bruts (opt-in, sent, delivered, clicked, converted) pour l'analytics.
- `dfpush_inbox` : copie persistante des notifications pour l'inbox in-site.
- `dfpush_stock_waitlist` : listes d'attente de retour en stock.
- `dfpush_consent_log` : registre RGPD.
L'**uninstall** (suppression complète depuis Extensions) drop ces huit tables et purge toutes les options. La désactivation simple, elle, conserve les données pour une réactivation ultérieure.
## Hooks développeur
Le plugin expose des actions et filtres aux points clés pour étendre son comportement sans modifier le cœur.
- `df_push_booted` (action) : déclenchée après le boot du plugin, utile pour enregistrer des extensions personnalisées.
- `df_push_payload_build` (filtre) : modifier le payload JSON envoyé au push service avant chiffrement.
- `df_push_should_send` (filtre) : court-circuiter l'envoi sur conditions personnalisées (renvoyer _false_ pour skip).
- `df_push_segment_query` (filtre) : enrichir les critères de segmentation comportementale.
- `df_push_webhook_payload` (filtre) : ajuster les payloads des webhooks sortants.
- `df_push_manifest` (filtre) : modifier le manifest PWA généré.
- Actions Scheduler enregistrées : `df_push_send_one`, `df_push_fan_out`, `df_push_abandoned_cart`, `df_push_review_request`, `df_push_dispatch_campaign`.
## FAQ et dépannage
### Le prompt d'opt-in ne s'affiche pas
Trois causes possibles : la permission navigateur est déjà refusée (vérifiez dans les réglages du navigateur), la permission est déjà accordée (le prompt n'a plus lieu d'être), ou un déclencheur n'a pas été atteint (délai non écoulé, scroll insuffisant). Dans la console JavaScript, exécutez `window.DFPush.isSubscribed()` pour vérifier l'état courant.
### L'admin Abonnés est vide alors qu'un opt-in a réussi
Vérifiez dans la console réseau que la requête `POST /wp-json/df-push/v1/subscribe` renvoie bien un code 200. À partir de la version 1.0.1, le plugin re-synchronise automatiquement toute `PushSubscription` existante avec le serveur sur chaque chargement de page, et logue toute erreur d'insertion DB dans `error_log`.
### Le Service Worker renvoie une erreur d'enregistrement
Si l'erreur navigateur est « The script resource is behind a redirect » ou « Unexpected token '<' », testez directement l'URL `https://votre-site.com/wp-content/plugins/df-push/sw.php`. Vous devez voir le code JavaScript du Service Worker avec un `Content-Type: application/javascript` et le header `Service-Worker-Allowed: /`. Si vous voyez un HTML 403, vérifiez les règles htaccess qui pourraient bloquer l'exécution directe de fichiers PHP sous `wp-content/plugins/`.
### Les notifications ne sont pas reçues sur iOS
Safari sur iOS ne supporte les notifications Push que depuis la version 16.4 et uniquement pour les sites installés en PWA via le bouton **Ajouter à l'écran d'accueil**. Le manifest PWA généré par le plugin facilite cette installation. Si vous ne ciblez pas spécifiquement iOS, ce n'est pas un problème : les autres navigateurs reçoivent les notifications normalement.
### Comment migrer depuis OneSignal ou Pusher
Les abonnés existants chez ces services tiers ne sont pas portables : la cryptographie Push lie chaque abonnement à un couple unique (clé VAPID du serveur, endpoint navigateur). Vos visiteurs devront se réabonner après votre passage à DataFirefly Push. Vous pouvez préparer la transition en désactivant l'ancien SDK quelques jours avant et en communiquant via une bannière de pré-annonce sur la nouvelle expérience.
### Que se passe-t-il à la désinstallation ?
La **désactivation** simple conserve toutes les tables et options : vous pouvez réactiver le plugin et reprendre où vous en étiez. La **suppression complète** depuis Extensions exécute `uninstall.php` qui drop les huit tables `dfpush_`, purge toutes les options du plugin (y compris les clés VAPID et le token API), et déprogramme les crons. Les permaliens sont automatiquement flushés à la prochaine requête.
---
### DataFirefly Push Pro — Guide complet
_Source :_
> DataFirefly Push Pro apporte les notifications push web natives à PrestaShop 8 et 9 sans aucun service tiers de type OneSignal ni abonnement mensuel. Ce guide couvre l'installation, la configuration…
DataFirefly Push Pro apporte les notifications push web natives à PrestaShop 8 et 9 sans aucun service tiers de type OneSignal ni abonnement mensuel. Ce guide couvre l'installation, la configuration initiale, les neuf automatisations, le builder de campagnes, la segmentation, l'A/B testing, l'attribution du chiffre d'affaires, les topics, l'inbox, les webhooks et le dépannage.
## 1. Présentation et cas d'usage
Le module implémente nativement le protocole Web Push VAPID (RFC 8292) avec chiffrement aes128gcm côté serveur. Les abonnements sont stockés dans votre base PrestaShop, les envois partent directement de votre hébergement, aucune donnée ne transite par un service tiers.
Cas d'usage typiques :
- **Récupération de paniers abandonnés** : trois relances espacées (1 h, 24 h, 72 h) sans dépendre de l'e-mail du visiteur.
- **Alertes produit** : retour en stock, baisse de prix, opt-in directement sur la fiche produit.
- **Transactionnel** : confirmation de commande, expédition, demande d'avis après livraison.
- **Réengagement** : anniversaire, clients inactifs, digest des nouveaux produits.
- **Campagnes ponctuelles** : soldes, lancements, Black Friday, avec segmentation et A/B testing.
## 2. Pré-requis
- PrestaShop 8.0 à 9.x
- PHP 7.4 minimum, 8.x recommandé
- MySQL 5.7 minimum ou MariaDB 10.3
- **HTTPS obligatoire** : l'API Web Push des navigateurs ne fonctionne que sur une origine sécurisée. Seul `localhost` fait exception pour les tests en développement.
- Un cron externe capable d'appeler une URL HTTP toutes les 5 minutes (cron Linux, tâches planifiées de l'hébergeur, cron PrestaShop natif, etc.)
- OpenSSL activé en PHP (utilisé pour la génération des clés VAPID et le chiffrement aes128gcm)
**Pourquoi HTTPS ?** Tous les navigateurs (Chrome, Firefox, Safari, Edge) refusent d'enregistrer un service worker ou d'accorder la permission notifications sur une page HTTP. C'est une limitation des navigateurs, pas du module.
## 3. Installation
1. Téléchargez le ZIP `dfpushnotifications-v1.2.0-phase3.zip` depuis votre espace client DataFirefly.
2. Back-office PrestaShop → Modules → Gestionnaire de modules → **Téléverser un module** → sélectionnez le ZIP.
3. Cliquez sur **Installer**. L'installation crée 14 tables sous le préfixe `ps_dfpush_*`, génère un token cron unique et enregistre les onglets BO.
4. Un nouveau menu apparaît : **Améliorer → DataFirefly Push** avec 8 onglets (Dashboard, Campaigns, Automations, Queue, Subscribers, Topics, Webhooks, Settings).
## 4. Génération des clés VAPID
Les clés VAPID identifient votre serveur auprès des push services des navigateurs (FCM, Mozilla autopush, Apple push). Elles sont générées une seule fois et ne doivent jamais changer après mise en production (sinon tous les abonnés deviennent injoignables).
1. Allez dans **DataFirefly Push → Opt-in & Settings**.
2. Cliquez sur **Generate VAPID keys**. Le module crée une paire de clés ECDSA P-256 stockée dans la configuration PrestaShop.
3. Saisissez un **VAPID subject** : une URL `mailto:` avec votre adresse de contact technique (ex. `mailto:admin@votreshop.com`). C'est l'identifiant que les push services peuvent contacter en cas d'abus.
4. Activez le module via le toggle **Push notifications enabled**.
**Sauvegardez vos clés.** Si vous régénérez les clés VAPID après le lancement, tous vos abonnés existants seront rejetés par les push services avec un code 410 Gone. Conservez une sauvegarde de la base PrestaShop avant toute manipulation des clés.
## 5. Configuration de l'opt-in
L'onglet **Opt-in & Settings** contrôle l'affichage de la demande de permission. Trois styles sont disponibles :
- **Bell** : une cloche flottante en bas à droite. L'utilisateur clique, puis le navigateur affiche sa demande native. Le moins intrusif.
- **Banner** : une bannière persistante en haut ou en bas de page avec deux boutons (autoriser / refuser).
- **Modal** : une fenêtre modale centrée, plus visible mais aussi plus agressive.
### Déclencheurs
Pour ne pas afficher la demande dès la première seconde (taux de refus élevé), choisissez un déclencheur :
- **Delay** : afficher après X secondes (par défaut 15 s)
- **Scroll** : afficher après X % de scroll de la page (par défaut 40 %)
- **Pages** : afficher après X pages vues dans la session (par défaut 2)
### Cooldown
Si le visiteur ferme ou refuse la demande, un cooldown empêche de la lui repropose pendant N jours (par défaut 7). Ça évite l'effet "popup harceleur" qui pousse les utilisateurs à bloquer définitivement le domaine.
### Plafond journalier et heures de silence
- **Max per day** : nombre maximum de notifications envoyées à un même abonné par jour (par défaut 3). Au-delà, la file d'envoi rejette silencieusement les messages excédentaires.
- **Quiet hours** : plage horaire pendant laquelle aucune notification n'est délivrée. Les messages enfilés pendant cette plage sont reprogrammés au matin de la première fenêtre non-silencieuse.
## 6. Cron : configuration et token
Le cron pilote toutes les opérations différées : automatisations, file d'envoi, drainage des webhooks, nettoyage. Il doit être appelé toutes les 5 minutes via une URL HTTP sécurisée par token.
### Token
Un token unique est généré à l'installation. Pour le récupérer : **DataFirefly Push → Automations**, le bandeau bleu en haut affiche l'URL complète à copier-coller dans votre cron.
### Exemple de cron Linux
```
*/5 * * * * curl -s "https://votreshop.com/module/dfpushnotifications/cron?token=VOTRE_TOKEN" > /dev/null
```
### Tâches exécutées à chaque tick
1. Réinitialisation des compteurs journaliers (une fois par jour, au franchissement de minuit)
2. Exécution des automatisations à délai mature (paniers abandonnés 1 h / 24 h / 72 h, anniversaire, inactivité, nouveaux produits, demandes d'avis programmées)
3. Déclenchement des campagnes programmées dont la date est arrivée
4. Drainage de la file d'envoi (jusqu'à 50 notifications par batch par défaut, configurable)
5. Drainage de la file des webhooks (jusqu'à 100 par batch)
6. Nettoyage des entrées anciennes (sent > 60 jours, webhook log > 30 jours)
La réponse du cron est un JSON détaillant chaque étape :
```
{
"success": true,
"tasks": {
"reset_counters": "ok",
"triggers": { "abandoned_1h": 12, "abandoned_24h": 4, "birthday": 2, "inactivity": 38 },
"scheduled_campaigns": 1,
"queue": { "processed": 50, "sent": 47, "failed": 2, "expired": 1 },
"webhooks": { "processed": 8, "sent": 8, "failed": 0, "dropped": 0 },
"cleanup": "ok"
},
"duration_ms": 1842
}
```
Si votre hébergeur ne dispose pas de cron, configurez un service tiers gratuit (cron-job.org, EasyCron, cronless) en pointant sur la même URL toutes les 5 minutes.
## 7. Automatisations : les 9 triggers
Désactivées par défaut, à activer une par une depuis **DataFirefly Push → Automations**. Chaque carte affiche le titre, le corps et les stats. Cliquez sur **Edit** pour personnaliser le wording et les options.
### Variables disponibles
Selon le trigger, vous pouvez insérer dans le titre et le corps :
- `{first_name}` : prénom du client (vide pour les visiteurs anonymes)
- `{cart_total}` : montant du panier abandonné, formaté avec la devise
- `{order_reference}` : référence de commande
- `{order_total}` : montant total de la commande
- `{product_name}` : nom du produit (retour en stock, baisse de prix)
- `{product_price}` : prix actuel du produit
- `{products_count}` : nombre de nouveaux produits (digest)
### Panier abandonné (3 relances)
Trois triggers indépendants : `abandoned_cart_1h`, `abandoned_cart_24h`, `abandoned_cart_72h`. Le module enregistre chaque modification de panier dans `ps_dfpush_cart_watch` et marque le panier converti dès la validation d'une commande. Le cron envoie chaque relance à maturité, sauf si le panier a été converti entre-temps.
### Retour en stock
Sur la fiche produit, un bouton _Notify me when back in stock_ apparaît automatiquement quand le produit est en rupture. L'abonné clique, son opt-in push est demandé si nécessaire, puis le module enregistre un watcher dans `ps_dfpush_product_watch`. Dès qu'une modification de stock ramène la quantité disponible au-dessus de 0, le watcher est notifié et marqué comme traité.
### Baisse de prix
Même principe avec le bouton _Notify me on price drop_. Le watcher stocke le prix de référence au moment de l'opt-in. La notification est envoyée dès qu'une mise à jour produit fait passer le prix sous 99 % du prix de référence (un seuil qui évite les déclenchements parasites lors des arrondis).
### Confirmation de commande
Déclenchée par le hook `actionValidateOrder`. Envoyée immédiatement, sans respect des heures de silence (transactionnel). Lien direct vers la page de détail de la commande.
### Expédition
Déclenchée par `actionOrderStatusUpdate` dès que le statut passe à un état marqué _shipped_ dans PrestaShop. Lien vers le détail de commande (qui contient le tracking si vous utilisez un module de suivi).
### Demande d'avis
Programmée X jours après le passage de la commande à un état _delivery_ (par défaut 7 jours, configurable dans le JSON config du trigger). La notification est enfilée avec un `scheduled_at` futur, le cron la délivre quand l'heure arrive.
### Anniversaire
Le cron lit le champ `birthday` du client PrestaShop et envoie la notification le jour J à l'heure configurée. Un dédoublonneur évite plusieurs envois la même année.
### Inactivité
Identifie les abonnés dont `last_visit` remonte à plus de N jours (par défaut 30). Pour éviter le harcèlement, un même abonné n'est notifié au maximum qu'une fois tous les 30 jours via ce trigger.
### Nouveaux produits
Digest quotidien envoyé à une heure configurable (par défaut 10 h). Le module agrège les produits créés dans les 24 dernières heures et envoie une notification mentionnant le nom du premier et le nombre total. Idéal pour une boutique qui ajoute régulièrement du catalogue.
## 8. Builder de campagnes
Pour les opérations ponctuelles : **DataFirefly Push → Campaigns → New campaign**. Le formulaire est divisé en cinq sections.
### Contenu
- **Campaign name** : nom interne (jamais affiché aux abonnés)
- **Notification title** : 80 caractères max
- **Body** : 250 caractères max
- **Click URL** : où le clic redirige
- **Icon URL** : petit logo (par défaut votre logo boutique)
- **Large image URL** : image hero, 1024 × 512 recommandé (Chrome uniquement)
- **Badge URL** : PNG monochrome 72 × 72 (Android)
### Boutons d'action
Jusqu'à deux boutons avec leur libellé et URL. Ils apparaissent sous la notification sur Chrome desktop et Android. Idéal pour proposer plusieurs CTA (_Voir l'offre_ / _Ignorer_).
### Audience
Voir la section Segmentation ci-après.
### Schedule & delivery
- **Send at** : date / heure de l'envoi. Vide = immédiat (à la prochaine drainage du cron).
- **Urgency** : `very-low`, `low`, `normal`, `high`. Influe sur la priorité côté push service.
- **TTL** : temps de vie en secondes (par défaut 86400 = 24 h). Si le navigateur de l'abonné est hors ligne plus longtemps, la notification expire.
- **Require interaction** : notification persistante jusqu'à clic ou fermeture manuelle (Chrome uniquement).
## 9. Segmentation
Combinable avec ET logique. Tous les critères vides = aucune restriction.
CritèreEffetLanguagesL'abonné parle au moins une de ces langues (cases cochées)CountriesPays détecté à l'inscription (basé sur la langue / IP / geo)Devicesmobile / desktop / tablet (détecté à l'inscription)BrowsersChrome, Firefox, Safari, Edge, Opera, Samsung InternetCustomer groupsL'abonné est lié à un client PrestaShop dans au moins un des groupesPurchase history_Any_ (défaut), _Has bought_, _Never bought_Active within N daysDernière visite il y a moins de N jours (basé sur `ps_dfpush_customer_activity`)
Le bouton **Preview audience size** calcule en AJAX le nombre exact d'abonnés correspondants. Utile pour vérifier qu'un ciblage n'est pas trop restrictif avant l'envoi.
## 10. A/B testing
Sur chaque campagne, le champ **% of audience for variant B** définit la part de l'audience qui reçoit la variante B (de 0 à 50). La répartition est déterministe : pour un `id_subscriber` donné, l'abonné reçoit toujours la même variante (basé sur `id_subscriber % 100 < split`).
La variante B override seulement les champs renseignés. Vous pouvez par exemple ne changer que le titre, ou ne tester qu'une image. Les statistiques sont stockées séparément :
- `stats_delivered` / `stats_clicked` / `stats_revenue` : variante A
- `stats_b_delivered` / `stats_b_clicked` / `stats_b_revenue` : variante B
Les colonnes apparaissent dans la liste des campagnes avec un badge _A/B_ à côté du nom.
## 11. Attribution du chiffre d'affaires
Mécanisme clé du module : relier les commandes aux notifications qui les ont déclenchées.
### Flux
1. Le module envoie une notification avec un `track_token` unique (32 caractères hex) en payload.
2. Le service worker intercepte le clic et redirige vers `/module/dfpushnotifications/track?t=TOKEN&click=1&u=URL`.
3. Le contrôleur `track` pose un cookie `dfpush_attr=TOKEN` (30 jours, SameSite=Lax) et redirige vers l'URL finale.
4. Le client navigue, ajoute au panier, valide la commande.
5. Au hook `actionValidateOrder`, l'`AttributionService` lit le cookie, retrouve la notification dans `ps_dfpush_notifications`, écrit `id_order` + `revenue` + `currency` sur la ligne.
6. Le service incrémente `stats_revenue` (ou `stats_b_revenue` selon la variante) sur la campagne ou le trigger, déclenche le webhook `order.attributed`, puis efface le cookie.
### Limites de l'attribution
- Fenêtre fixe à 30 jours. Au-delà, l'attribution n'a plus lieu.
- Un seul cookie par abonné. Si l'utilisateur clique sur une seconde notification avant de commander, c'est la dernière qui est créditée (modèle _last click_).
- L'attribution exige que le clic et la commande aient lieu sur le même navigateur (le cookie est lié au navigateur).
- Une commande déjà attribuée ne peut pas être réattribuée (champ `id_order > 0` bloque la double comptabilisation).
## 12. Topics
Les topics sont des canaux d'abonnement thématiques que les clients activent depuis leur compte. Exemple : _Promotions_, _Nouveaux produits_, _Alertes stock_. Un abonné qui ne coche que _Promotions_ ne recevra que les campagnes ciblant ce topic.
### Créer un topic
1. **DataFirefly Push → Topics → New topic**
2. **Code** : identifiant interne sans espaces (ex. `flash_deals`)
3. **Display order** : position dans la liste affichée au client
4. **Active** : visible des clients
5. **Default opt-in** : pré-coché au moment de l'inscription
6. **Translations** : un nom et une description par langue installée
### Cibler un topic dans une campagne
La segmentation inclut un critère _Topics_ dans le résolveur. Pour l'activer depuis l'UI : actuellement uniquement via JSON personnalisé (la case à cocher Topics arrive dans une mise à jour mineure). Les abonnés sans aucun topic souscrit reçoivent tout (rétrocompatibilité).
## 13. Inbox in-app
L'endpoint `/module/dfpushnotifications/inbox` retourne les 20 dernières notifications du subscriber courant en JSON. Le frontend ouvre cette inbox via la modale unifiée accessible depuis le compte client (tile _Push notifications_).
La modale affiche aussi le statut de souscription (avec bouton subscribe / unsubscribe) et la liste des topics. Pour l'appeler manuellement depuis votre thème :
```
// Ouvrir la modale
window.dfpush.openManagePopup();
// Vérifier l'état d'abonnement
const isOn = window.dfpush.isSubscribed();
```
## 14. Webhooks
Les webhooks envoient les événements du module vers Zapier, Make, n8n ou votre propre backend. Chaque webhook est signé HMAC-SHA256 sur le corps brut de la requête.
### Créer un webhook
1. **DataFirefly Push → Webhooks → New webhook**
2. **URL** : votre endpoint (HTTPS recommandé)
3. **Secret** : généré automatiquement, copiez-le côté receveur
4. **Events** : cochez les événements à délivrer parmi les 8 disponibles
5. Cliquez sur **Send test ping** pour vérifier que votre endpoint répond bien 2xx
### Événements disponibles
- `subscriber.subscribed` : nouvel opt-in
- `subscriber.unsubscribed` : désabonnement
- `subscriber.expired` : push service a renvoyé 410 Gone
- `notification.sent` : notification délivrée avec succès
- `notification.clicked` : clic enregistré
- `notification.failed` : échec définitif après 3 tentatives
- `campaign.sent` : campagne terminée
- `order.attributed` : commande reliée à une notification
### Format du payload
```
{
"event": "notification.clicked",
"timestamp": "2026-05-28T14:32:18+00:00",
"shop": 1,
"data": {
"id_subscriber": 482,
"id_campaign": 12,
"id_trigger": 0,
"id_notification": 9182,
"track_token": "abc123...",
"url": "https://votreshop.com/promotions",
"ab_variant": "A"
}
}
```
### Headers HTTP envoyés
- `Content-Type: application/json`
- `X-DfPush-Event: notification.clicked`
- `X-DfPush-Signature: sha256=`
- `X-DfPush-Timestamp: 1748443938`
- `User-Agent: DataFireflyPush/1.2`
### Vérifier la signature côté receveur
Exemple PHP :
```
$body = file_get_contents('php://input');
$expected = hash_hmac('sha256', $body, $YOUR_SECRET);
$received = explode('=', $_SERVER['HTTP_X_DFPUSH_SIGNATURE'])[1] ?? '';
if (!hash_equals($expected, $received)) {
http_response_code(401);
exit;
}
// Signature valide, traiter la payload
$payload = json_decode($body, true);
```
### Retry et drop
Si votre endpoint répond autre chose que 2xx, le module retente avec un backoff exponentiel jusqu'à 5 tentatives. Après quoi, le log est marqué _dropped_ et l'événement est perdu. Les logs _sent_ et _dropped_ sont purgés après 30 jours.
## 15. Multi-boutique et multilingue
Tous les abonnés, campagnes, automatisations, topics et webhooks sont rattachés à un `id_shop`. En multi-boutique :
- Sélectionnez la boutique cible dans le sélecteur du back-office avant de créer une campagne ou une automatisation
- Le cron est unique mais filtre automatiquement par boutique
- Les clés VAPID sont partagées entre boutiques (une seule paire pour toutes)
Côté langue : le module est livré en FR, EN, ES, DE et IT. La langue de l'abonné est détectée à l'inscription et stockée. Vous pouvez segmenter par langue dans les campagnes.
## 16. RGPD et bonnes pratiques
- **Consentement** : la souscription repose sur l'opt-in natif du navigateur, qui est une preuve de consentement RGPD-compatible.
- **Données personnelles** : le module stocke l'endpoint Web Push, l'IP au moment de l'inscription, le user-agent, la langue et le pays. Aucune transmission vers un tiers.
- **Désinscription** : un clic sur le bouton _Unsubscribe_ de la modale ou la désactivation des notifications dans le navigateur met l'abonné en statut `revoked`.
- **Droit à l'effacement** : la suppression d'un compte client en BO supprime aussi ses subscribers liés.
- **Heures de silence** : par défaut 22 h - 8 h. Adaptez à votre cible (B2B = horaires bureau, B2C = soirée).
- **Plafond journalier** : par défaut 3 / jour. Au-delà, taux de désabonnement très élevé.
## 17. Dépannage
### L'opt-in ne s'affiche pas
- Vérifiez que votre site est en HTTPS (pas HTTP).
- Vérifiez que les clés VAPID sont générées (**Settings**).
- Vérifiez que le toggle **Push notifications enabled** est activé.
- Ouvrez la console du navigateur (F12) et cherchez des erreurs côté `dfpush-frontend.js`.
- Si vous avez déjà refusé ou ignoré la demande, le cooldown bloque pendant N jours. Effacez les cookies du domaine pour réinitialiser, ou changez de navigateur pour tester.
### Le cron ne s'exécute pas
- Appelez l'URL manuellement dans votre navigateur : vous devriez voir un JSON avec `success: true`. Si vous voyez un `403 invalid_token`, le token est mal recopié.
- Vérifiez la dernière exécution dans le tableau de bord (**Dashboard**, bloc _System_).
- Sur certains hébergeurs, le timeout cURL des crons est de 30 s. Si la file est très grosse, augmentez la fréquence du cron à toutes les 1 ou 2 minutes pour traiter par plus petits batches.
### Les notifications ne partent pas
- Onglet **Queue** : si les lignes sont en _pending_, c'est que le cron n'a pas tourné depuis leur création.
- Si elles sont en _failed_, cliquez sur la ligne pour voir le code HTTP et le message d'erreur du push service.
- `410 Gone` = l'abonnement n'est plus valide (utilisateur s'est désabonné ou a effacé son navigateur). Le module marque automatiquement le subscriber en _expired_.
- `429 Too Many Requests` = rate limit côté push service. Le module retente automatiquement avec backoff.
### Les commandes ne sont pas attribuées
- Vérifiez que les cookies tiers ne sont pas bloqués par le navigateur du client (mode privé, certains anti-trackers).
- Le cookie expire à 30 jours : une commande passée 31 jours après le clic ne sera pas attribuée.
- Si vous voyez `id_order = 0` dans `ps_dfpush_notifications` alors que la commande a été passée, vérifiez que les hooks `actionValidateOrder` sont bien enregistrés (**Modules → Hooks → actionValidateOrder**).
### Erreur SQL avec "LIMIT 1 LIMIT 1"
Bug interne corrigé en 1.2.0 (`Db::getValue` et `Db::getRow` ajoutent automatiquement leur propre `LIMIT 1`). Si vous voyez encore cette erreur, vérifiez que vous avez bien la dernière version du module installée.
## 18. FAQ
### Combien d'abonnés peut gérer le module ?
Le module n'a pas de limite codée. En pratique, le facteur limitant est le temps d'exécution du cron : sur un hébergement mutualisé standard, comptez environ 50 envois par minute (limité par les push services). Pour 10 000 abonnés, prévoyez un cron toutes les 1 ou 2 minutes pendant l'envoi d'une grosse campagne.
### Safari iOS est-il vraiment exclu ?
Safari iOS supporte le Web Push depuis iOS 16.4 mais uniquement pour les sites installés comme PWA sur l'écran d'accueil. Sur un Safari classique, l'API `Notification` renvoie `undefined`. C'est une limitation Apple, pas du module.
### Puis-je migrer mes abonnés depuis OneSignal ou Firebase ?
Non. Les endpoints push sont liés à la paire de clés VAPID utilisée à l'inscription. Si vous changez de paire, les abonnements existants deviennent invalides. Une migration nécessiterait une réinscription des utilisateurs.
### Le module fonctionne-t-il sur PrestaShop 1.7 ?
Non, uniquement PrestaShop 8.0 à 9.x. La version 1.7 utilise une architecture admin différente qui nécessiterait un fork dédié.
### Puis-je customiser le service worker ?
Oui, le fichier `views/js/sw-template.js` est rendu par le contrôleur `swjs.php` et peut être étendu. Attention : toute modification du service worker nécessite une nouvelle `register()` côté client. Les anciens visiteurs garderont la version précédente jusqu'à ce que le navigateur détecte le changement (généralement 24 h).
### Comment exporter les abonnés ?
Onglet **Subscribers**, bouton **Export CSV**. Le fichier contient endpoint, browser, device, langue, pays, date d'inscription et compteurs d'envoi / clics.
## Support
Pour toute question non couverte par ce guide, contactez le support DataFirefly. Pour signaler un bug, joignez le détail de votre version PrestaShop, PHP et le contenu de la réponse JSON du cron.
---
### DataFirefly PWA — Guide complet
_Source :_
> Présentation Le module DataFirefly PWA (dfpwa) transforme votre boutique PrestaShop en Progressive Web App : vos clients peuvent l'installer sur leur écran d'accueil, recevoir des notifications push web et continuer…
## Présentation
Le module **DataFirefly PWA** (`dfpwa`) transforme votre boutique PrestaShop en **Progressive Web App** : vos clients peuvent l'installer sur leur écran d'accueil, recevoir des **notifications push web** et continuer à naviguer même hors connexion. Le module est entièrement autonome : le chiffrement des notifications est géré en PHP natif, sans Composer, sans service tiers et sans abonnement.
Trois piliers : une boutique **installable** (icône sur l'écran d'accueil), des **notifications push** (campagnes, suivi de commande, relance panier) et un **mode hors-ligne** (service worker + page de repli).
## Compatibilité
- PrestaShop 8.0 à 9.x
- Mono-boutique et multi-boutique
- 5 langues : FR, EN, ES, DE, IT
- Aucune dépendance (ni Composer ni framework)
## Prérequis
- **HTTPS obligatoire** : les PWA et le push web ne fonctionnent que sur une boutique servie en HTTPS. La quasi-totalité des boutiques en production en disposent déjà.
- **Extension PHP openssl** : utilisée pour le chiffrement VAPID des notifications. Le module vérifie sa présence à l'installation.
Si openssl ou la courbe `prime256v1` ne sont pas disponibles sur votre serveur, l'installation est bloquée avec un message explicite. Contactez votre hébergeur pour activer l'extension.
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** puis sélectionnez le fichier `dfpwa.zip`.
3. Une fois installé, cliquez sur **Configurer**.
À l'installation, le module génère automatiquement vos **clés VAPID** (publique et privée) et un **jeton de cron**, crée les tables des abonnements et du journal d'envois, et enregistre la page de configuration des campagnes dans le menu d'administration.
## Configuration
### Application (PWA)
- **Nom de l'application** et **nom court** : affichés sous l'icône une fois la boutique installée.
- **Couleur du thème** et **couleur de fond** : utilisées pour la barre système et l'écran de démarrage.
- **Mode d'affichage** : _standalone_ (plein écran, recommandé), _fullscreen_ ou _minimal-ui_.
- **URL de démarrage** : page ouverte au lancement de l'application installée.
- **Icônes 192 et 512 px** : téléchargez vos propres icônes (PNG ou WebP). À défaut, le logo de la boutique est utilisé automatiquement.
### Bannière d'installation
- **Afficher la bannière** : propose l'installation aux visiteurs éligibles.
- **Délai d'affichage** : nombre de secondes avant l'apparition de la bannière, pour ne pas gêner l'arrivée sur le site.
- **Aide iOS** : affiche un guide pas-à-pas « Ajouter à l'écran d'accueil » pour les utilisateurs de Safari sur iPhone et iPad.
Sur iOS, l'installation ne peut pas être déclenchée automatiquement par le site : elle passe obligatoirement par le menu de partage de Safari. Le guide intégré explique chaque étape au visiteur.
### Notifications push
- **Activer le push** : autorise l'inscription et l'envoi de notifications.
- **Consentement préalable** : affiche un message explicite avant la demande native du navigateur, conforme au RGPD.
- **Délai avant la demande** : temps d'attente avant de proposer l'inscription au push.
- **Sujet VAPID** : adresse de contact (mailto ou URL) transmise aux serveurs de push, conformément à la spécification.
- **Notification au changement de statut de commande** : prévient automatiquement le client (commande expédiée, par exemple).
- **Relance des paniers abandonnés** et **délai de relance** : déclenche une notification après un panier laissé sans commande.
### Mode hors-ligne
- **Activer le mode hors-ligne** : enregistre le service worker et la page de repli.
- **Stratégie de cache** : _stale-while-revalidate_ (affichage immédiat puis mise à jour en arrière-plan, recommandé), _réseau-d'abord_ ou _cache-d'abord_.
- **Titre** et **message hors-ligne** : textes affichés sur la page de repli.
- **Pré-cache** : liste d'URL à mettre en cache dès l'installation du service worker.
Les pages sensibles (panier, tunnel de commande, compte client) sont toujours exclues du cache afin de ne jamais servir de contenu périmé sur des données personnelles ou transactionnelles.
### Partage
Activez le **bouton de partage natif** pour permettre à vos clients de partager une fiche produit via la fenêtre de partage de leur appareil (Web Share API). Ajoutez l'attribut `data-dfpwa-share` à n'importe quel élément de votre thème pour en faire un déclencheur de partage.
## Notifications push : fonctionnement
Le module implémente le push web standard (VAPID + chiffrement conforme aux RFC 8291 et 8188), entièrement en PHP via openssl. Aucune donnée d'abonnement ne quitte votre serveur.
### Envoyer une campagne
1. Ouvrez la page **Campagnes push** dans le menu d'administration.
2. Saisissez un **titre**, un **message** et une **URL de destination**.
3. Ciblez par **langue** et par **groupe de clients** si nécessaire.
4. Utilisez le **mode test** pour vous envoyer la notification avant un envoi de masse, puis validez.
Les notifications sont envoyées en parallèle par lots, et les abonnements expirés (codes 404 / 410) sont automatiquement purgés. Chaque envoi est enregistré dans le journal avec le nombre de destinataires, de livraisons et de clics.
### Déclencheurs automatiques
- **Suivi de commande** : à chaque changement de statut, le client abonné reçoit une notification (s'il a accepté le push).
- **Panier abandonné** : une tâche cron repère les paniers contenant des articles, rattachés à un client abonné et sans commande, dans la fenêtre de relance configurée.
La relance de panier s'exécute via une **tâche cron protégée par un jeton**. Récupérez l'URL de cron complète sur la page de configuration et ajoutez-la à votre planificateur (par exemple toutes les heures). Le jeton empêche tout déclenchement non autorisé.
## Mode hors-ligne : fonctionnement
Le service worker est enregistré au périmètre racine de la boutique grâce à l'en-tête `Service-Worker-Allowed`, ce qui lui permet de contrôler l'ensemble des pages. Selon la stratégie choisie, il sert les pages depuis le cache, le réseau, ou les deux. Lorsque la connexion est totalement perdue et qu'aucune version en cache n'est disponible, une **page de repli autonome** aux couleurs de votre boutique s'affiche, avec un bouton « Réessayer » et un retour à l'accueil.
## Tableau de bord
La page de configuration affiche en un coup d'œil le nombre d'**abonnés au push**, le nombre de **notifications envoyées** et le **taux de clic** de vos campagnes. Les abonnements expirés étant purgés automatiquement, ces statistiques restent fiables.
## FAQ et dépannage
### La bannière d'installation n'apparaît pas
Vérifiez que la boutique est servie en HTTPS, que le module est activé et que la PWA n'est pas déjà installée. Sur navigateur de bureau, l'installation se fait souvent via l'icône dédiée dans la barre d'adresse. Sur iOS, utilisez le guide « Ajouter à l'écran d'accueil ».
### Les notifications ne partent pas
Assurez-vous que le push est activé, que les clés VAPID sont présentes (un avertissement s'affiche sur le tableau de bord dans le cas contraire) et que des clients se sont bien abonnés. Le mode test permet de valider la chaîne d'envoi de bout en bout.
### La relance de panier ne se déclenche pas
Contrôlez que l'URL de cron est bien appelée par votre planificateur et qu'elle contient le bon jeton. Vérifiez aussi le délai de relance configuré et la présence de clients abonnés avec un panier éligible.
### Le push fonctionne-t-il sur iPhone ?
Oui, à partir d'iOS 16.4, mais uniquement une fois la boutique installée sur l'écran d'accueil. Le guide d'installation iOS est donc essentiel pour activer le push sur ces appareils.
---
### DataFirefly Retour en haut — Documentation
_Source :_
> Le module DataFirefly Retour en haut ajoute un bouton flottant qui ramène vos visiteurs en haut de page d'un seul clic. Ce guide couvre l'installation et l'ensemble des réglages disponibles.…
Le module **DataFirefly Retour en haut** ajoute un bouton flottant qui ramène vos visiteurs en haut de page d'un seul clic. Ce guide couvre l'installation et l'ensemble des réglages disponibles.
## Installation
1. Dans votre back-office, allez dans **Modules > Module Manager**.
2. Cliquez sur **Installer un module** (en haut à droite) et envoyez l'archive `dfbacktotop.zip`.
3. Une fois l'installation terminée, cliquez sur **Configurer**.
Le module s'enregistre automatiquement sur les hooks `actionFrontControllerSetMedia` et `displayFooter`. Aucune intervention manuelle sur les hooks n'est nécessaire.
## Configuration
La page de configuration se compose de deux onglets : **Comportement** et **Apparence**.
### Onglet Comportement
- **Seuil de déclenchement (px)** — nombre de pixels de défilement à partir duquel le bouton apparaît. Valeur par défaut : `300`.
- **Défilement fluide** — active la remontée animée et progressive. Désactivé, le retour en haut est instantané.
- **Afficher sur mobile** — affiche ou masque le bouton sur les écrans de moins de 768 px de large.
### Onglet Apparence
- **Position** — en bas à droite ou en bas à gauche.
- **Icône** — chevron, flèche ou triangle (icônes SVG intégrées).
- **Taille du bouton** — diamètre du bouton, de 24 à 120 px.
- **Rayon des angles** — de 0 % (carré) à 50 % (cercle).
- **Marge horizontale / verticale** — distance par rapport aux bords de l'écran.
- **Couleur de fond**, **Couleur de fond (survol)**, **Couleur de l'icône** — codes hexadécimaux.
- **Ombre portée** — ajoute une ombre douce sous le bouton.
- **z-index** — augmentez cette valeur si le bouton passe sous d'autres éléments fixes (bandeau cookies, chat, etc.).
Chaque réglage est validé à l'enregistrement : les couleurs doivent être des codes hexadécimaux valides, et la taille comme le rayon sont bornés pour éviter tout affichage cassé.
## Formes du bouton
La forme est entièrement pilotée par le **rayon des angles** :
- `50 %` — cercle parfait.
- `20 %` — carré aux angles arrondis.
- `0 %` — carré net.
## Compatibilité avec votre thème
Le bouton est injecté via le hook `displayFooter`, présent dans le thème Classic et la grande majorité des thèmes PrestaShop. Si votre thème personnalisé n'appelle pas ce hook, le bouton ne s'affichera pas : il suffit d'ajouter l'appel au hook dans le template de pied de page du thème.
## Performance et accessibilité
- JavaScript natif d'environ 1,5 ko, sans jQuery ni dépendance externe.
- Suivi du défilement via `requestAnimationFrame` et écouteur passif, sans impact perceptible sur les Core Web Vitals.
- Bouton natif avec attribut `aria-label` et focus clavier visible.
- Respect de la préférence système `prefers-reduced-motion` : le défilement devient instantané si l'utilisateur a réduit les animations.
- Aucune donnée personnelle collectée — compatible RGPD par conception.
## FAQ
### Le bouton ne s'affiche pas, que vérifier ?
Vérifiez que votre thème implémente le hook `displayFooter` et que vous avez suffisamment défilé pour dépasser le seuil de déclenchement (300 px par défaut). Videz également le cache PrestaShop après installation.
### Puis-je l'utiliser en multiboutique ?
Oui. Les réglages sont enregistrés via `Configuration` et s'appliquent selon le contexte de boutique actif.
### Le module est-il vraiment gratuit ?
Oui, sous licence gratuite, sans limitation de fonctionnalité.
---
### DataFirefly Server-Side — Guide complet
_Source :_
> Guide complet d'installation, de connexion et d'exploitation du connecteur gratuit DataFirefly Server-Side pour WooCommerce : suivi client + serveur, déduplication, purchase server-side, consentement et abonnement au service.
DataFirefly Server-Side est le connecteur WooCommerce **gratuit** du service _DataFirefly Server-Side Tracking_. Le plugin capte les événements de votre boutique et les signe ; le service les diffuse côté serveur vers vos plateformes publicitaires et analytics. Ce guide couvre l'installation, la connexion, le fonctionnement du tunnel client + serveur, la déduplication, le purchase serveur, le choix des destinations client, la gestion du consentement, la fiabilité et l'abonnement.
**Modèle plugin gratuit + service payant.** Le plugin ne coûte rien et restera gratuit. Pour _envoyer_ réellement vos événements, il faut un abonnement au service DataFirefly Server-Side (à partir de 39 €/mois), qui assure l'ingestion et la diffusion server-side.
## Prérequis
- WordPress 5.8 ou supérieur
- WooCommerce 5.0 ou supérieur (compatible HPOS — High-Performance Order Storage)
- PHP 7.4 ou supérieur
- Un cron WordPress fonctionnel (ou un vrai cron système) pour la file de reprise et l'envoi différé
- Un abonnement DataFirefly Server-Side pour obtenir votre clé de connexion
## Installation
1. Récupérez le fichier `datafirefly-serverside-2_2_0.zip` depuis votre espace client DataFirefly.
2. Dans le back-office WordPress, allez dans **Extensions → Ajouter → Téléverser une extension**, sélectionnez le ZIP puis cliquez sur _Installer maintenant_.
3. Activez l'extension. Un nouveau menu **DataFirefly Server-Side** apparaît dans l'administration.
## Connexion en une clé
Le module se configure avec une seule clé de connexion, qui active en même temps le suivi client et le suivi serveur.
1. Depuis votre espace client DataFirefly, copiez la **clé de connexion** (elle commence par `dfss_`).
2. Collez-la dans le champ prévu de l'écran _Connexion_ du plugin.
3. Cliquez sur **Connecter**. Le module active le suivi client et serveur, envoie un événement de test au dispatcher et met en place les balises client pour les destinations configurées.
4. Vérifiez que le statut passe à **Connecté ✓** et utilisez le bouton _Tester l'événement_ pour confirmer la remontée.
La clé `dfss_…` encode votre tenant, un secret et l'endpoint du dispatcher. Elle est restreinte aux hôtes `datafirefly.com` en HTTPS : une clé pointant vers un autre domaine est refusée.
### Mode avancé (saisie manuelle)
Si vous préférez ne pas utiliser la clé unique, le **mode avancé** permet de renseigner manuellement le tenant, le secret et l'endpoint. Réservez-le aux configurations spécifiques : le mode une-clé couvre la quasi-totalité des cas.
## Tunnel complet client + serveur
Le plugin suit l'ensemble du tunnel côté navigateur, tandis que la conversion d'achat part côté serveur.
- **Côté navigateur :**`page_view`, `view_content` (vue produit), `add_to_cart`, `initiate_checkout` et `add_payment_info`.
- **Côté serveur :**`purchase`, déclenché depuis les hooks de commande WooCommerce.
Les deux couches partagent le même identifiant d'événement pour permettre la déduplication.
### Événements merchandising (depuis la v2.1.1)
Le tracker couvre également le merchandising de votre catalogue : `view_item_list` (vue d'une liste de produits — catégorie, résultats de recherche), `select_item` (clic sur un produit d'une liste), `view_promotion` et `select_promotion` (vue et clic d'une promotion). Le contexte associé — identifiant et nom de liste, identifiant et nom de promotion, créatif et emplacement — est transmis au server-side pour enrichir vos analyses de parcours.
### Déduplication par event_id
Pour chaque commande, l'événement client et l'événement serveur portent le même `event_id`, construit sur l'identifiant de commande (par exemple `order_1042`). Meta, GA4 et les autres plateformes s'appuient dessus pour **ne compter chaque conversion qu'une seule fois**. Vous récupérez ainsi les conversions que le navigateur laisse échapper, sans double comptage.
## Choisir les destinations client (Meta, GA4, TikTok)
Depuis la version 2.2.0, chaque balise client s'active ou se désactive individuellement dans les réglages du plugin, ligne **Destinations client** :
- **Meta** (pixel Facebook, `fbevents.js`)
- **Google Analytics 4** (`gtag.js`)
- **TikTok** (pixel TikTok)
Une destination décochée **ne charge jamais son script tiers** dans le navigateur de vos visiteurs et **ne pose jamais ses cookies**. Vous n'utilisez pas Meta ? Décochez-le : moins de JavaScript, moins de requêtes, une page plus rapide et plus sobre. Les destinations non configurées sur votre compte DataFirefly sont signalées dans l'écran de réglages.
Ces cases ne concernent que les _balises client_. La diffusion server-side vers Meta CAPI, GA4, TikTok, Pinterest et Google Ads reste pilotée par la configuration de votre compte dans l'espace client DataFirefly. Notez qu'en désactivant GA4, le cookie `_ga` n'est plus posé par le plugin, ce qui réduit la qualité de correspondance GA4 côté serveur — cohérent si vous n'utilisez pas GA4.
## Purchase server-side : fiable et infalsifiable
La conversion d'achat est déclenchée par les hooks de commande WooCommerce (paiement complété, en cours de traitement, terminé), de manière **idempotente** : un verrou (`_dfss_sent`) garantit qu'un même achat n'est jamais envoyé deux fois, même si plusieurs hooks se déclenchent.
- Comme l'événement part du serveur, aucun bloqueur de publicités ni ITP ne peut l'empêcher.
- À l'inverse, l'endpoint public de collecte (beacon) **exclut volontairement** l'événement `purchase` : il est impossible d'injecter un faux achat depuis le navigateur pour gonfler vos revenus Meta ou GA4.
- Le contexte de l'événement (valeur, devise, produits) fait autorité côté serveur : le navigateur ne « devine » rien.
Pour fiabiliser l'attribution même via une passerelle de paiement avec redirection, le plugin capture au checkout les cookies `_fbp`, `_fbc`, `_ga`, `_ttp` et les rattache à la commande, et pose des cookies first-party de click-id (90 jours) pour transporter `fbc`, `ttclid` et `gclid` jusqu'à l'achat.
## Gestion du consentement
Le **gate de consentement est activé par défaut** : rien n'est envoyé tant que le consentement marketing n'est pas accordé.
### Compatibilité native avec Cookie Consent v2
Le plugin détecte nativement le module **DataFirefly Cookie Consent — RGPD & Google Consent Mode v2** et lit son cookie de consentement (`dfcc_consent`) directement côté serveur. Si la catégorie _marketing_ est refusée, l'événement est écarté, quoi que prétende le navigateur. C'est la combinaison recommandée : bannière, Consent Mode v2 et tracking server-side parlent le même langage.
### Autres solutions de consentement
À défaut de Cookie Consent v2, le plugin prend aussi en charge **WP Consent API**, **Complianz**, **Cookiebot** et **IAB TCF v2**. Vous pouvez conserver votre bannière actuelle et brancher le suivi dessus.
## Fiabilité : file de reprise et journal d'activité
Un événement qui n'a pas pu être livré n'est pas perdu : il est mis en file d'attente et **renvoyé automatiquement** par un cron toutes les 5 minutes.
Le **journal d'activité** affiche en temps réel, sans jargon, ce qui a été livré, ce qui est en file d'attente et ce qui a été rejeté, avec le code HTTP et le nombre de tentatives. C'est votre premier réflexe de diagnostic.
Le cron WordPress ne s'exécute qu'au trafic. Sur une boutique à faible trafic, configurez un vrai cron système appelant `wp-cron.php` pour que la file de reprise se vide régulièrement.
## Sécurité
- Aucun secret dans le navigateur : seuls des identifiants publics (pixel, measurement id) sont exposés côté client.
- Le secret de signature et vos identifiants de destination restent côté serveur.
- Chaque événement est signé en HMAC avant d'atteindre le dispatcher, hébergé dans l'UE (Allemagne).
- Le plugin est distribué sous licence GPLv2 ou ultérieure et suit les standards de codage WordPress.
## Abonnement au service DataFirefly Server-Side
Le plugin capte et signe ; le service _DataFirefly Server-Side Tracking_ ingère et diffuse côté serveur vers cinq destinations : **Meta CAPI, GA4 (Measurement Protocol), TikTok Events API, Pinterest Conversions API et Google Ads**. Le dispatcher est hébergé en Allemagne, l'ingestion est signée en HMAC, les données personnelles sont masquées et le déclenchement respecte le consentement. Une seule intégration, une facture consolidée, plusieurs sites possibles.
Découvrez les offres et abonnez-vous sur [server-side.datafirefly.com](https://server-side.datafirefly.com/) :
- **Starter** — 39 €/mois : 1 site, jusqu'à 500 K événements
- **Growth** — 119 €/mois : 5 sites, jusqu'à 2 M événements
- **Scale** — 349 €/mois : 20 sites, jusqu'à 10 M événements
## Dépannage
### Le statut reste « Non connecté »
Vérifiez que la clé commence bien par `dfss_` et qu'elle a été copiée en entier. Une clé pointant vers un autre domaine que `datafirefly.com` (HTTPS) est refusée. Réessayez le bouton _Tester l'événement_.
### Le purchase ne remonte pas
Le purchase part des hooks de commande : assurez-vous que la commande atteint un statut de paiement (complété / en traitement / terminé). Consultez le journal d'activité pour voir si l'événement est en file d'attente ou rejeté, et vérifiez le cron si des événements stagnent.
### Le script Meta (ou GA4, TikTok) ne se charge pas
Deux causes possibles : la destination est décochée dans **Destinations client** (comportement voulu depuis la v2.2.0), ou elle n'est pas configurée sur votre compte DataFirefly — l'écran de réglages l'indique alors. Après une modification côté compte, utilisez le bouton _Rafraîchir les identifiants de destination_.
### Des conversions comptées deux fois
Vérifiez qu'aucun autre plugin de tracking n'envoie déjà un `purchase` concurrent sans `event_id` partagé. Avec DataFirefly Server-Side seul, l'`event_id` basé sur la commande garantit la déduplication.
### Rien ne part alors que le consentement semble donné
Le gate est actif par défaut. Vérifiez que la catégorie _marketing_ est bien acceptée dans votre solution de consentement, et que celle-ci est détectée (Cookie Consent v2, WP Consent API, Complianz, Cookiebot ou IAB TCF v2).
Besoin d'aide ? Contactez le support DataFirefly depuis votre espace client en joignant une capture du journal d'activité (code HTTP + nombre de tentatives).
---
### DataFirefly Server-Side — Guide complet
_Source :_
> Guide complet du module gratuit DataFirefly Server-Side pour PrestaShop 8 et 9 : installation, identifiants, événement de test, gate de consentement avec le Cookie Manager et dépannage.
## Présentation
DataFirefly Server-Side est le connecteur PrestaShop gratuit du service [DataFirefly Server-Side Tracking](https://server-side.datafirefly.com/). À chaque commande validée, le module construit un événement d'achat complet et l'envoie de serveur à serveur, signé HMAC-SHA256, vers le dispatcher DataFirefly hébergé dans l'UE (Allemagne). Le service diffuse ensuite l'événement vers vos destinations configurées : Meta Conversions API, GA4 Measurement Protocol, TikTok Events API, Pinterest Conversions API et Google Ads.
Le partage des rôles est simple : le module **capte et signe**, le service **ingère, déduplique et diffuse**. Le module est gratuit ; la diffusion nécessite un abonnement au service (Starter dès 39 €/mois).
Un incident de tracking ne cassera jamais votre checkout : le module est fail-safe par conception (timeouts de 2 s / 4 s, erreurs journalisées dans les logs PrestaShop, aucune exception ne remonte au tunnel de commande).
## Prérequis
- PrestaShop 1.7.6 ou supérieur, 8.x ou 9.x
- PHP 7.4 ou supérieur, avec l'extension cURL (présente sur la quasi-totalité des hébergements)
- Un compte DataFirefly Server-Side Tracking actif — abonnez-vous sur [server-side.datafirefly.com](https://server-side.datafirefly.com/)
- Recommandé : notre module [DataFirefly Cookie Manager](https://www.datafirefly.com/product/cookie-manager-tarteaucitron-conformite-rgpd-cle-en-main-pour-prestashop/) (bandeau tarteaucitron conforme CNIL avec Google Consent Mode v2) pour la gate de consentement native
## Installation
1. Téléchargez le ZIP du module depuis votre compte DataFirefly.
2. Dans le back-office PrestaShop, ouvrez **Modules > Gestionnaire de modules > Installer un module** et déposez le fichier `datafirefly_serverside.zip`.
3. Cliquez sur **Installer**. Le module s'enregistre sur le hook de validation de commande ; aucun override ni modification de thème n'est nécessaire.
À l'installation, le tracking est **désactivé** et l'exigence de consentement est **activée** : rien ne part tant que vous n'avez pas configuré et activé le module.
## Récupérer vos identifiants
1. Connectez-vous à votre [espace client DataFirefly](https://admin.datafirefly.com/app/login) (ou [abonnez-vous](https://admin.datafirefly.com/pricing) si ce n'est pas encore fait).
2. Ouvrez la section **Connecter votre boutique** de votre site.
3. Copiez les trois valeurs affichées : le **Tenant ID** (au format `shop_votreboutique_xxxx`), le **secret HMAC** (clé de signature de 64 caractères) et l'**endpoint d'événements**.
Le secret HMAC est une clé privée : ne la partagez pas et ne la collez nulle part ailleurs que dans la configuration du module. En cas de fuite, régénérez-la depuis votre espace client.
## Configuration
Ouvrez **Modules > Gestionnaire de modules > DataFirefly Server-Side > Configurer**. Le formulaire comporte cinq réglages :
- **Activer le tracking** — l'interrupteur principal. Tant qu'il est sur Non, aucun événement n'est envoyé.
- **Tenant ID** — l'identifiant de votre boutique dans le service, copié depuis votre espace client.
- **Secret HMAC** — la clé de signature de 64 caractères. Chaque événement est signé avec cette clé avant l'envoi.
- **Events endpoint** — l'URL d'ingestion du dispatcher. La valeur par défaut convient dans la quasi-totalité des cas ; ne la modifiez que si votre espace client vous en indique une autre.
- **Exiger le consentement** — activé par défaut. Quand il est actif, l'achat n'est transmis que si le visiteur a accordé un consentement marketing (voir ci-dessous). Désactivez-le uniquement si vous gérez le consentement en amont par un autre dispositif.
Enregistrez, puis passez au test.
## Tester la connexion
Cliquez sur **Envoyer un événement de test** dans le formulaire de configuration. Le module envoie un `page_view` synthétique, signé, vers le dispatcher — sans toucher aux vraies commandes.
- **« Événement de test livré » (HTTP 200)** : votre Tenant ID, votre secret et votre endpoint sont corrects. Votre boutique est connectée, même si aucune destination n'est encore configurée côté service.
- **« Événement de test échoué »** : le code HTTP et le message du dispatcher s'affichent pour le diagnostic (voir Dépannage).
## Le consentement (RGPD)
Quand **Exiger le consentement** est actif, le module lit — directement côté serveur, au moment de la validation de commande — le cookie de consentement au format tarteaucitron déposé par notre module [DataFirefly Cookie Manager](https://www.datafirefly.com/product/cookie-manager-tarteaucitron-conformite-rgpd-cle-en-main-pour-prestashop/) (Google Consent Mode v2). Le nom du cookie est repris automatiquement de la configuration du Cookie Manager (par défaut `tarteaucitron`).
L'achat est transmis si le visiteur a consenti à **au moins un service publicitaire** : Meta Pixel, Google Ads, TikTok Pixel ou LinkedIn Insight. L'approche est privacy-first : cookie absent ou illisible = pas d'envoi.
C'est la combinaison recommandée sur PrestaShop : le Cookie Manager gère le bandeau, le Consent Mode v2 et la preuve du consentement ; ce module applique la même décision au tracking server-side. Une seule source de vérité pour toute la chaîne.
Si vous gérez le consentement avec un autre dispositif, désactivez **Exiger le consentement** et appliquez votre propre logique en amont : c'est alors à votre dispositif de garantir qu'aucune commande ne provient d'un visiteur non consentant.
## Ce qui est envoyé
À chaque commande validée, le module construit un événement `purchase` avec :
- **Transaction** : montant payé, devise ISO, référence de commande, produits (id, nom, quantité, prix TTC unitaire) et nombre total d'articles.
- **Données de correspondance** : e-mail et identifiant client, téléphone, prénom, nom, ville, code postal et pays ISO de l'adresse de facturation (repli sur l'adresse de livraison).
- **Identifiants navigateur** capturés au moment de la commande : `_fbp` et `_fbc` (Meta), `_ttp` (TikTok) et le client id GA4 extrait du cookie `_ga`.
Chaque champ optionnel n'est ajouté que s'il est présent et valide : le dispatcher valide strictement, et un événement bien formé est un événement livré. L'identifiant d'événement est calé sur la commande (`order_ID`), de façon idempotente — c'est lui qui permet la déduplication client + serveur côté plateformes si vous utilisez aussi des tags navigateur.
Côté transport, chaque requête porte trois en-têtes : le tenant, l'horodatage (vérifié dans une fenêtre anti-rejeu de 300 secondes) et la signature HMAC-SHA256 du corps exact de la requête. Vos credentials Meta, GA4, TikTok, Pinterest et Google Ads restent dans votre espace DataFirefly : ni la boutique ni le navigateur ne les voient.
## Suivre vos événements côté service
Dans votre espace client, l'**Event Inspector** vous montre les événements un par un, avec les données personnelles masquées (conforme RGPD). Vous y vérifiez ce qui est réellement livré à chaque destination. La disponibilité des plateformes est consultable à tout moment sur la [page de statut publique](https://serverside.datafirefly.com/status).
## Dépannage
### L'événement de test échoue avec « not_configured »
L'un des trois champs (Tenant ID, secret, endpoint) est vide. Recopiez les trois valeurs depuis votre espace client et enregistrez avant de retester.
### L'événement de test échoue en HTTP 401 ou 403
La signature est rejetée : le secret HMAC ne correspond pas au tenant, ou le Tenant ID est erroné. Recopiez les deux valeurs sans espace ni retour à la ligne. Vérifiez aussi que l'horloge de votre serveur est correcte (NTP) : un décalage supérieur à 300 secondes fait échouer la fenêtre anti-rejeu.
### L'événement de test échoue avec « curl: … » ou HTTP 0
Votre serveur ne parvient pas à joindre le dispatcher : pare-feu sortant, DNS ou proxy. Autorisez les connexions HTTPS sortantes vers l'endpoint indiqué dans votre espace client.
### Le test passe, mais aucune commande n'arrive
- Vérifiez que **Activer le tracking** est bien sur Oui.
- Si **Exiger le consentement** est actif, seules les commandes de visiteurs ayant consenti à un service publicitaire sont transmises. Passez une commande de test après avoir accepté les cookies publicitaires dans le bandeau.
- Consultez **Paramètres avancés > Logs** dans le back-office : chaque échec de livraison y est journalisé avec le code HTTP et l'identifiant de commande (préfixe `[DataFirefly SS]`).
### Les conversions sont comptées deux fois
Impossible côté module : l'identifiant d'événement est idempotent par commande. Si vous utilisez aussi des tags navigateur en dehors du service, assurez-vous qu'ils envoient le même identifiant d'événement (`order_ID`) pour que les plateformes dédupliquent.
## Désinstallation
La désinstallation supprime toute la configuration du module (tenant, secret, endpoint, réglages). Aucune table n'est créée en base : le module ne stocke rien d'autre que sa configuration.
---
### DataFirefly Server-Side pour Shopware — Guide complet
_Source :_
> Présentation DataFirefly Server-Side est le connecteur Shopware gratuit du service DataFirefly Server-Side Tracking. À chaque commande validée, le plugin construit un événement d'achat complet et l'envoie de serveur à serveur,…
## Présentation
DataFirefly Server-Side est le connecteur Shopware gratuit du service [DataFirefly Server-Side Tracking](https://server-side.datafirefly.com/). À chaque commande validée, le plugin construit un événement d'achat complet et l'envoie de serveur à serveur, signé HMAC-SHA256, vers le dispatcher DataFirefly hébergé dans l'UE. Le service ingère l'événement, le déduplique et le diffuse vers vos destinations : Meta CAPI, GA4, TikTok Events API, Pinterest Conversions API et Google Ads.
Le plugin est volontairement minimaliste côté boutique : aucune credential de destination n'y est stockée, aucun script n'est ajouté au storefront, aucune table n'est créée. Il capte, construit, signe, envoie — le reste se passe côté service.
**Modèle économique :** le plugin est gratuit ; la diffusion des événements nécessite un abonnement au service (Starter 39 €/mois, Growth 119 €/mois, Scale 349 €/mois). Détails et souscription sur [server-side.datafirefly.com](https://server-side.datafirefly.com/).
## Prérequis
- Shopware 6.5.x, 6.6.x ou 6.7.x (installation auto-hébergée — Shopware Cloud n'accepte pas les plugins serveur)
- PHP 8.1 ou supérieur, selon votre version de Shopware, avec l'extension curl
- Un abonnement actif au service DataFirefly Server-Side Tracking pour obtenir votre clé de connexion
## Installation
### Par upload de ZIP
1. Dans l'administration Shopware, ouvrez **Extensions → Mes extensions → Télécharger l'extension** et sélectionnez le fichier ZIP du plugin.
2. Cliquez sur **Installer**, puis **Activer**.
### Via la ligne de commande
```
bin/console plugin:refresh
bin/console plugin:install --activate DatafireflyServerSide
bin/console cache:clear
```
Le plugin n'ajoute rien au storefront : aucun `build-storefront` n'est nécessaire après l'installation.
## Connexion au service
### Obtenir votre clé de connexion
1. Connectez-vous à votre espace client sur [server-side.datafirefly.com](https://server-side.datafirefly.com/).
2. Ouvrez la section **Connecter votre boutique**.
3. Copiez la clé de connexion en une ligne, au format `dfss_…`. Elle encode votre identifiant tenant, votre secret de signature HMAC et l'endpoint d'ingestion.
La clé de connexion contient votre secret de signature : gardez-la confidentielle, comme un mot de passe. En cas de fuite, régénérez-la depuis votre espace client et remplacez-la dans la configuration du plugin.
### Coller la clé dans Shopware
1. Ouvrez **Extensions → Mes extensions → DataFirefly Server-Side → Configuration**.
2. Collez la clé dans le champ **Clé de connexion**.
3. Activez le toggle **Activer le tracking** et enregistrez.
C'est tout : dès la prochaine commande validée, l'événement d'achat part vers le dispatcher. Une clé absente ou mal formée n'est jamais une erreur bloquante — le plugin considère simplement qu'il n'est pas configuré et n'envoie rien.
## Configuration
- **Activer le tracking** — interrupteur principal. Désactivé par défaut.
- **Clé de connexion** — la clé `dfss_…` copiée depuis votre espace client.
- **Exiger le consentement marketing** — active la gate de consentement (désactivée par défaut, voir ci-dessous).
- **Nom du cookie de consentement** — le cookie déposé par votre outil de consentement (CMP).
- **Valeur du cookie de consentement (contient)** — optionnel : fragment de valeur attendu dans le cookie.
La configuration est gérée par sales channel : vous pouvez activer le tracking sur une boutique et pas sur une autre, ou utiliser des clés différentes par canal.
## Gate de consentement
Shopware ne pose pas nativement de cookie unique de consentement marketing lisible côté serveur. Le plugin propose donc une gate générique, désactivée par défaut : lorsqu'elle est active, l'événement d'achat n'est envoyé que si le cookie configuré est présent dans la requête du client — et, si une valeur attendue est renseignée, que si la valeur du cookie la contient.
### Avec DataFirefly Cookie Consent
La combinaison recommandée sur Shopware est notre plugin [DataFirefly Cookie Consent](https://www.datafirefly.com/product/df-cookie-consent/) (bandeau RGPD/CNIL avec Google Consent Mode v2 natif) : activez la gate et renseignez le nom du cookie de consentement déposé par le bandeau (indiqué dans sa documentation). Le refus ou l'absence de consentement marketing bloque l'envoi, côté serveur, avant toute transmission.
### Avec un autre CMP
Renseignez le nom du cookie que votre CMP dépose lorsque le visiteur accepte les cookies marketing (par exemple `CookieConsent` pour Cookiebot), et éventuellement un fragment de valeur (par exemple `marketing:true`). Si votre CMP ne pose pas de cookie lisible côté serveur, ou si vous gérez le consentement entièrement en amont, laissez la gate désactivée.
### Comportement privacy-first
- Gate active + nom de cookie non configuré → rien ne part.
- Gate active + cookie absent ou vide → rien ne part.
- Gate active + valeur attendue configurée mais absente de la valeur du cookie → rien ne part.
- Requête absente (flux CLI ou headless sans requête HTTP) → rien ne part.
En cas de doute, le plugin n'envoie pas : c'est un choix de conception. Aucun événement ne peut partir « par accident » sans consentement lorsque la gate est active.
## Tester la connexion
Le plugin fournit une commande console qui envoie un `page_view` synthétique vers le dispatcher, sans toucher aux vraies commandes :
```
bin/console datafirefly:serverside:test
```
Options disponibles :
- `--sales-channel-id=` — lit la configuration d'un sales channel spécifique (par défaut : configuration globale).
- `--source-url=` — inclut une sourceUrl dans l'événement de test.
Un code HTTP 2xx confirme que la clé de connexion, la signature et l'endpoint sont corrects — même si aucune destination n'est encore configurée côté service.
## Fonctionnement technique
### L'événement purchase
Le plugin s'abonne à l'événement de commande validée de Shopware. À chaque déclenchement, il construit un événement `purchase` avec un identifiant idempotent calé sur la commande (`order_`) : si vous utilisez aussi des tags navigateur, le service applique la déduplication client + serveur et chaque conversion n'est comptée qu'une fois.
### Données envoyées
- **Transaction :** valeur payée, devise, numéro de commande, produits, quantités, nombre d'articles.
- **Correspondance :** e-mail, identifiant client, téléphone, prénom, nom, ville, code postal et pays de l'adresse de facturation.
- **Identifiants navigateur** capturés au moment de la commande : `_fbp`, `_fbc`, `_ttp` et le client id GA4 (cookie `_ga`).
La construction est défensive : chaque champ optionnel n'est ajouté que s'il est présent et valide (le dispatcher valide strictement — pays sur 2 caractères, devise sur 3, etc.). Dans les flux headless où certaines associations de la commande peuvent manquer, les champs correspondants sont simplement omis, jamais fabriqués.
### Signature HMAC
Chaque événement est signé HMAC-SHA256 avec votre secret de tenant : les octets signés sont exactement les octets envoyés, avec un horodatage vérifié dans une fenêtre de 300 secondes contre le rejeu. Les en-têtes transmis sont l'identifiant tenant, le timestamp et la signature. Vos credentials Meta, GA4, TikTok, Pinterest et Google Ads restent côté service — jamais dans la boutique, jamais dans le navigateur.
### Fail-safe
Tout le sous-système est conçu pour ne jamais impacter le checkout : timeouts de 2 secondes (connexion) et 4 secondes (total), toutes les erreurs capturées et journalisées en warning dans les logs Shopware avec le code HTTP et le numéro de commande — aucune exception ne remonte jusqu'au tunnel de commande.
## Dépannage
- **Aucun événement ne part** — vérifiez que le toggle est activé pour le bon sales channel, que la clé commence par `dfss_` sans espace ni retour à la ligne, et que la gate de consentement n'est pas active sans cookie configuré.
- **La commande de test échoue** — un code 0 avec un message curl indique un problème réseau sortant (firewall) ; un code 401/403 indique une clé invalide ou régénérée : recopiez-la depuis votre espace client.
- **Événements marqués non livrés dans les logs** — le code HTTP et le numéro de commande sont journalisés dans les logs Shopware (canal warning). Un code 4xx signale un payload rejeté par la validation stricte du dispatcher ; vérifiez l'Event Inspector de votre espace client pour le détail.
- **Conversions en double sur Meta ou GA4** — assurez-vous que vos tags navigateur envoient le même identifiant d'événement (`order_`) pour bénéficier de la déduplication.
## Changelog
- **1.0.0** (01/07/2026) — version initiale : événement purchase serverside idempotent, signature HMAC-SHA256 avec fenêtre anti-rejeu, clé de connexion en une ligne, gate de consentement opt-in par cookie CMP, configuration par sales channel, commande console de test, conception fail-safe.
---
### DataFirefly Shopify Migrator — Guide complet
_Source :_
> Le guide complet du module DataFirefly Shopify Migrator : installation, choix entre mode CSV et mode API, création de l'app Shopify avec Client Credentials Grant, migration entité par entité, outils de réparation des images et des variantes, push des features en metafields, filtres d'exclusion, worker cron asynchrone et dépannage des cas courants.
## Présentation
DataFirefly Shopify Migrator est un module PrestaShop 8 et 9 qui exporte l'intégralité d'un catalogue vers Shopify, avec deux modes au choix : **CSV** (génération de fichiers prêts à importer manuellement via l'admin Shopify, sans clé API) ou **API** (push direct vers une boutique Shopify connectée via l'Admin REST API 2026-04).
Le module gère huit entités, dans l'ordre où elles doivent typiquement être migrées :
- **Produits** — fiches complètes, déclinaisons jusqu'à 3 groupes d'attributs, images, stocks, prix HT ou TTC, balises SEO préservées via metafields global title_tag/description_tag
- **Collections** — catégories PrestaShop converties en custom collections avec image et description
- **Pages CMS** — pages PrestaShop converties en pages Shopify avec slug et meta SEO
- **Clients** — fiches client + adresse par défaut + statistiques de commandes, tagués imported-prestashop
- **Commandes** — export CSV consultatif uniquement (Shopify n'accepte pas d'import natif des commandes via CSV standard)
- **Redirections 301** — table de correspondance anciennes URLs PrestaShop → nouvelles URLs Shopify pour préserver le référencement
- **Repair images** et **Variant images** — deux jobs de réparation pour récupérer les images que Shopify a silencieusement perdues pendant le fetch asynchrone, et pour rattacher chaque déclinaison Shopify à son image
- **Features → Metafields** — push des caractéristiques produits PrestaShop comme metafields Shopify avec création automatique des Metafield Definitions via GraphQL
L'architecture est asynchrone par jobs : chaque migration crée un job en base, ensuite traité par lots configurables via un worker cron protégé par token. Le rate limit de Shopify est respecté automatiquement (1,8 req/s, retry 429), et un mapping persistant en base relie les identifiants PrestaShop aux identifiants Shopify pour permettre les redirections et éviter les doublons en cas de relance.
## Prérequis
- PrestaShop 8.0 à 9.x
- PHP 7.4 à 8.3
- Pour le mode API : une boutique Shopify cible (plan Basic suffit), un compte Shopify Partners ou un accès au Shopify Dev Dashboard
- Pour le mode cron : la possibilité de planifier une URL côté hébergeur (crontab, cron-as-a-service, ou Plesk/cPanel)
- Côté serveur : extensions PHP curl et iconv activées
## Installation
1. Téléchargez le ZIP depuis votre compte client DataFirefly (espace Téléchargements de la fiche produit).
2. Dans le back-office PrestaShop, allez dans _Modules → Gestionnaire de modules → Téléverser un module_, déposez le ZIP.
3. Cliquez sur _Installer_. Le module crée trois tables (jobs, mapping, log) et un onglet dédié dans Paramètres avancés → Shopify Migrator.
4. Cliquez sur _Configurer_ pour accéder à l'interface principale.
**Premier réflexe :** commencez en mode CSV pour tester sans risque. Aucune clé API n'est requise et vous pouvez inspecter les fichiers générés avant de les importer dans Shopify.
## Choisir entre mode CSV et mode API
### Mode CSV
Le module génère des fichiers CSV au format natif attendu par Shopify Admin (Products Import, Customers Import, URL Redirects Import). Vous téléchargez chaque fichier depuis l'onglet Jobs puis l'importez manuellement dans Shopify.
**Avantages :** aucune clé API à configurer, possibilité d'inspecter et d'ajuster les fichiers avant import, traitement très rapide côté PrestaShop.
**Limites :** les collections Shopify n'ont pas d'import CSV natif (le fichier généré sert de référence), et les commandes ne sont jamais importables en CSV standard côté Shopify.
### Mode API
Le module envoie chaque entité directement à votre boutique Shopify via l'API Admin REST 2026-04, avec gestion du rate limit, retry automatique sur erreur 429, et mapping persistant des IDs pour permettre les redirections automatiques et l'idempotence des relances.
**Avantages :** migration de bout en bout en une commande, redirections poussées directement, collections créées automatiquement avec attachement des produits, parfait pour les gros catalogues.
**Limites :** nécessite une app Shopify avec les bons scopes, et certaines organisations Shopify créées après avril 2025 sont GraphQL-only (le module reste compatible REST pour les organisations standard).
## Mode API : créer l'app Shopify
**Important :** depuis le 1er janvier 2026, l'ancien flux "Settings → Apps → Develop apps" a été déprécié. Vous devez passer par le Shopify Dev Dashboard. Les tokens ne sont plus affichés directement dans l'admin Shopify — il faut les échanger via Client Credentials Grant (CCG).
### Création de l'app dans le Dev Dashboard
1. Connectez-vous au Shopify Dev Dashboard (dev.shopify.com/dashboard) avec votre compte Partners.
2. Cliquez sur _Create app_, donnez-lui un nom (par exemple "Migrator"), puis confirmez.
3. Dans l'écran de configuration, l'_App URL_ peut être laissée à n'importe quelle valeur HTTPS valide. Elle n'est utilisée que pour l'OAuth, ce qui ne concerne pas notre cas.
### Configuration des scopes
Dans _Configuration → Admin API integration → Configure access scopes_, activez les scopes suivants :
- `read_products`, `write_products`
- `read_customers`, `write_customers`
- `read_content`, `write_content`
- `read_inventory`, `write_inventory`
- `read_online_store_pages`, `write_online_store_pages`
- `read_online_store_navigation`, `write_online_store_navigation`
- `write_metaobject_definitions` (uniquement si vous utilisez l'entité Features → Metafields)
Cliquez sur _Save_.
### Installation sur la boutique cible
1. Dans _Distribution_, choisissez _Custom distribution_ et ajoutez votre boutique Shopify cible.
2. Cliquez sur le lien d'installation généré, qui ouvre l'écran de consentement merchant côté Shopify Admin.
3. Validez l'installation : vous obtenez l'écran final de l'app.
**Si vous modifiez les scopes après installation,** le merchant n'aura pas approuvé les nouveaux. Désinstallez puis réinstallez l'app pour rafraîchir le consentement, sinon vous obtiendrez _This action requires merchant approval for scope_name_ sur les appels concernés.
### Récupération du Client ID et du Client Secret
Dans _Settings → Credentials_ de l'app, copiez le Client ID, puis cliquez sur l'icône œil à côté de Secret pour le révéler et le copier.
**L'App Automation Token n'est pas un Admin API token.** Il sert uniquement à authentifier Shopify CLI pour les déploiements CI/CD. N'utilisez pas le bouton "Create token" de cette section pour configurer le module.
## Mode API : configuration des credentials
Dans l'onglet _Settings_ du module, choisissez le mode _Shopify Admin REST API_, puis renseignez :
- **Shopify store domain** — soit le nom court (`my-store`) soit le domaine complet (`my-store.myshopify.com`).
- **API version** — par défaut 2026-04, la version stable courante.
- **Authentication method** — deux choix sont possibles :
### Méthode 1 : Admin access token
Pour les rares cas où vous disposez déjà d'un token Admin API valide (custom app legacy ou token obtenu manuellement via OAuth). Collez le token dans le champ dédié et sauvegardez.
### Méthode 2 : Client Credentials Grant (recommandée)
Le module échange votre Client ID + Client Secret contre un Admin API access token via le flow OAuth Client Credentials Grant. Le token est mis en cache (24 h), automatiquement renouvelé moins de 5 minutes avant son expiration. Aucune intervention manuelle pendant la migration.
Renseignez les deux champs et sauvegardez. Cliquez sur _Test connection_ : le module affiche le nom de votre boutique Shopify et le temps restant avant expiration du token.
**Limite du CCG :** votre boutique Shopify et votre app Dev Dashboard doivent appartenir à la même Shopify organization. Sur une boutique payante hors organisation, Shopify renvoie `shop_not_permitted`. Dans ce cas, il faut soit rattacher la boutique à votre organisation Partners, soit obtenir manuellement un token via Authorization Code Grant OAuth (hors périmètre du module).
## Migration des produits
L'export produits est le plus complexe. Il gère les produits, les déclinaisons (jusqu'à 3 groupes d'attributs comme Shopify l'autorise), les images (URL absolue depuis votre PrestaShop), les stocks, les prix, les fabricants utilisés comme vendor, les catégories converties en tags et type, les balises SEO préservées via les metafields `global.title_tag` et `global.description_tag`.
### Lancer le job
1. Dans _Run a migration_, sélectionnez la carte _Products_.
2. Cliquez sur _Create export job_. Le job apparaît dans la liste de l'onglet _Jobs_ avec le statut _pending_.
3. Si vous avez configuré le cron, le worker le prend en charge dans la minute qui suit. Sinon cliquez sur le bouton _Run now_ pour le faire avancer synchronement (limité par le timeout PHP, environ 30 secondes).
### Suivi de la progression
L'onglet Jobs auto-actualise toutes les 10 secondes. Chaque ligne affiche le statut (pending/running/done/failed/cancelled), le pourcentage d'avancement, le nombre de succès et d'erreurs, et un bouton de logs déroulant qui affiche les 30 dernières lignes du journal.
### Cas du mode CSV
Le fichier `job_X_products.csv` est généré au format Shopify Products Import. Téléchargez-le depuis la liste des jobs, puis dans Shopify Admin allez dans _Products → Import_ et déposez le fichier. Shopify gère ensuite le traitement de son côté, avec une notification par email à la fin.
## Migration des collections
Les catégories PrestaShop (hors racine et hors catégorie ID 1) deviennent des _custom collections_ Shopify, avec leur titre, description, image, balises SEO et le slug nettoyé. En mode API, les produits déjà migrés sont automatiquement attachés à chaque collection via l'endpoint `/collects.json`.
**Ordre important :** en mode API, migrez les produits avant les collections, sinon le mapping des IDs Shopify n'est pas encore disponible et les produits ne pourront pas être attachés.
## Migration des pages CMS
Les pages PrestaShop actives sont exportées en pages Shopify avec leur titre, contenu HTML (les URLs d'images relatives sont automatiquement résolues en URL absolues vers votre domaine PrestaShop), slug et balises SEO.
## Migration des clients
Pour chaque client actif et non supprimé, le module exporte le nom, l'email, l'adresse par défaut, le total dépensé, le nombre de commandes valides, et l'opt-in newsletter. Chaque client reçoit le tag `imported-prestashop` pour faciliter le filtrage ultérieur.
**Les mots de passe ne sont pas migrés,** par sécurité. Shopify enverra une invitation de réinitialisation à chacun de vos clients lors de votre premier envoi commercial.
## Migration des commandes (CSV uniquement)
L'export commandes est consultatif : Shopify ne propose pas d'import natif des commandes via CSV standard. Le fichier généré contient toutes les informations utiles pour archive ou analyse : référence, date, statut, client, adresses de facturation et livraison, devise, totaux HT et TTC, transporteur, suivi, et une ligne par produit acheté.
Vous pouvez filtrer par plage de dates dans le formulaire de création du job (champs _Orders from_ et _Orders to_).
Pour les utilisateurs Shopify Plus, des outils tiers comme Matrixify acceptent ce format en entrée pour effectuer une véritable réimportation.
## Migration des redirections 301
C'est le point clé pour préserver votre référencement le jour du basculement de domaine. Le module lit la table de mapping construite par les exports précédents (produits, collections, pages) et génère un CSV à deux colonnes au format natif Shopify URL Redirects, avec les anciennes URLs PrestaShop en première colonne et les nouvelles URLs Shopify en seconde.
En mode API, le module pousse directement chaque redirection via `POST /redirects.json`. En mode CSV, importez le fichier dans Shopify Admin via _Online Store → Navigation → URL Redirects → Import_.
**Les redirections doivent être migrées en dernier,** après les produits, collections et pages CMS. Elles consomment la table de mapping construite par ces trois jobs précédents.
## Filtres d'exclusion (v1.1)
Deux filtres optionnels permettent d'exclure des produits de l'export, configurables dans _Settings → Product filters (exclusions)_.
### Exclure des catégories
Champ texte avec une liste d'IDs de catégories PrestaShop séparés par des virgules. Un produit appartenant à au moins une de ces catégories est exclu de l'export Products. Les catégories elles-mêmes restent migrées par l'entité Collections (utile si une catégorie technique n'a pas vocation à être affichée mais peut contenir des produits).
### Exclure des préfixes de référence
Champ texte avec une liste de préfixes séparés par des virgules. Tout produit dont la référence commence par un de ces préfixes est exclu. Utile pour ne pas migrer des produits internes (NS pour non-vendables, HB pour hors-business, OBSOLETE- pour les gammes arrêtées, etc.). Les préfixes sont insensibles à la casse.
**Snapshot au moment du job :** les filtres sont stockés en config persistante mais figés au moment de la création du job (snapshot dans les params). Modifier les filtres ne change pas un job déjà en cours.
## Réparation des images (v1.3)
Shopify télécharge les images de manière _asynchrone_ après la création d'un produit : il fetch l'URL que vous avez fournie, et si ça échoue silencieusement (timeout, URL bloquée, fichier trop gros, format refusé), il ne renvoie aucune erreur. Le produit est créé "success" côté API mais sans image.
L'entité _Repair images_ répare ces cas. Pour chaque produit du mapping :
1. GET `/products/{shopify_id}/images.json` pour compter les images actuelles côté Shopify.
2. Lecture des images correspondantes en PrestaShop.
3. Si Shopify a déjà autant d'images que PS → le produit est sauté.
4. Sinon : suppression des images Shopify partielles, puis upload de chaque image PS via base64 attachment (mode synchrone, Shopify confirme la création immédiatement), avec fallback URL pour les fichiers de plus de 3 MB.
Mode API obligatoire. Idempotent : vous pouvez relancer le job autant de fois que nécessaire.
## Variant images (v1.4)
Une fois les images principales en place, il reste à associer chaque déclinaison Shopify à son image correspondante. L'entité _Variant images_ s'en charge : pour chaque produit du mapping, elle interroge la liste des variantes et des images Shopify, puis croise avec les relations `product_attribute_image` de PrestaShop.
La correspondance variante PS → variante Shopify utilise d'abord le SKU (référence de la déclinaison), avec un fallback par tuple d'options (option1/option2/option3 en minuscules) si la référence est vide.
La correspondance image PS → image Shopify se fait par alignement de position : la N-ième image PS correspond à la N-ième image Shopify. C'est valable tant que vous n'avez pas réorganisé manuellement les images dans l'admin Shopify.
Idempotent : un variant déjà sur le bon image_id est sauté (loggé `already_ok`). Le journal compte par produit : assigned / already_ok / missing_image / missing_variant.
## Features → Metafields (v1.5)
Les caractéristiques produits PrestaShop (_Catalogue → Attributs et Caractéristiques → Caractéristiques_) sont poussées comme metafields Shopify sous le namespace `custom`, avec création automatique des Metafield Definitions pour qu'elles soient éditables depuis l'admin Shopify.
### Phase A : creation des Definitions (premier lot)
Au premier batch du job, le module liste toutes les features distinctes du shop et crée pour chacune une Metafield Definition via la mutation GraphQL `metafieldDefinitionCreate`. Les definitions déjà existantes (code TAKEN ou DUPLICATE_KEY) sont silencieusement ignorées.
### Phase B : push des valeurs (chaque batch)
Pour chaque produit du mapping, le module liste les metafields `custom.*` existants, puis pour chaque feature PS effectue un upsert : PUT si la clé existe avec une valeur différente, POST si la clé n'existe pas. Les valeurs déjà identiques sont sautées.
### Conversion nom → clé
Le nom de la feature PrestaShop est converti en clé metafield Shopify par translittération ASCII, mise en minuscules, remplacement des caractères non alphanumériques par des underscores, troncature à 30 caractères. Exemples :
- `Matière principale` devient `matiere_principale`
- `Poids (kg)` devient `poids_kg`
- `Couleur` devient `couleur`
**Scope requis :** sans `write_metaobject_definitions` dans l'app Shopify, la Phase A échoue. La Phase B fonctionne quand même mais les metafields ne sont pas visibles dans l'UI admin Shopify de manière éditable. Pour les ajouter sans réinstaller l'app, ajoutez le scope dans Configuration, sauvegardez, puis désinstallez/réinstallez l'app pour rafraîchir le consentement merchant.
## Worker cron
Le module expose un endpoint front protégé par token qui traite un job par tick, à raison de 20 lots par tick. L'URL complète avec token est affichée dans l'onglet _Run a migration_, avec un bouton de copie.
Exemple d'entrée crontab pour un tick par minute :
```
* * * * * curl -s "https://votre-prestashop.com/index.php?fc=module&module=dfshopifymigrator&controller=cron&token=VOTRE_TOKEN" > /dev/null
```
Sans cron configuré, vous pouvez toujours faire avancer un job à la main avec le bouton _Run now_ de la liste des jobs (avancement synchrone, limité par le timeout PHP du back-office, environ 30 secondes).
## Ordre recommandé des jobs
Pour une migration complète sans surprise, lancez les jobs dans cet ordre :
1. **Products** — crée le mapping PS→Shopify pour les produits, utilisé par toutes les étapes suivantes.
2. **Collections** — crée le mapping pour les catégories et attache automatiquement les produits.
3. **Pages** — crée le mapping pour les pages CMS.
4. **Customers** — indépendant du reste.
5. **Orders** — CSV consultatif uniquement, lancement à votre rythme.
6. **Repair images** (si nécessaire) — répare les images perdues pendant le fetch asynchrone Shopify.
7. **Variant images** — réassocie chaque déclinaison à son image.
8. **Features → Metafields** — pousse les caractéristiques produits comme metafields visibles.
9. **Redirects** — en dernier, consomme tout le mapping construit ci-dessus.
## Limites connues (v1)
- Une seule langue est exportée par migration (la langue sélectionnée dans Settings). La v2 ajoutera le mapping des langues PrestaShop vers Shopify Markets et Translate & Adapt.
- Les commandes sont exportées au format CSV consultatif uniquement.
- Les mots de passe clients ne sont pas migrés.
- Les déclinaisons sont limitées à 3 groupes d'attributs (limite Shopify Option1/Option2/Option3).
- Les images sont servies depuis l'URL publique de votre PrestaShop : gardez votre PS en ligne pendant l'import Shopify, et au minimum pendant l'éventuel job Repair images.
## Dépannage
### Shopify API error: Not Found
Vérifiez en priorité le champ _API version_ dans Settings : il doit être `2026-04` (les anciennes versions comme 2024-10 sont retirées). Vérifiez aussi que votre app est bien installée sur la boutique cible dans Distribution.
### Shopify API error: Invalid API key or access token
Le token a expiré (CCG : durée de vie 24 h, rafraîchi automatiquement) ou l'app a été désinstallée. Cliquez sur _Test connection_ pour forcer un renouvellement du token CCG. Si l'erreur persiste, allez dans Shopify Admin → Apps and sales channels et vérifiez que l'app Migrator est bien dans la liste des applications installées.
### This action requires merchant approval for write_X scope
Vous avez modifié les scopes après l'installation initiale de l'app, le merchant n'a pas eu l'occasion de les approuver. Désinstallez l'app dans Shopify Admin puis réinstallez-la via le lien de Distribution du Dev Dashboard. L'écran de consentement merchant apparaîtra à nouveau avec les nouveaux scopes.
### shop_not_permitted lors de l'échange CCG
Votre boutique Shopify n'est pas dans la même organization que votre app Dev Dashboard. Soit rattachez la boutique à votre organization Partners, soit utilisez un token Admin obtenu manuellement (Authorization Code Grant OAuth, hors périmètre du module).
### Cardinality violation: Subquery returns more than 1 row
Bug corrigé en v1.2.1. Mettez à jour vers la dernière version du module.
### Beaucoup de fiches Shopify sont arrivées sans image
C'est le comportement Shopify documenté pour les images push via URL. Lancez le job _Repair images_ en mode API : il détecte les fiches avec moins d'images que PS et republie tout en base64 (mode synchrone, garantit l'arrivée).
### Beaucoup de "missing_variant" dans les logs de Variant images
Le SKU de la déclinaison Shopify ne correspond pas à la référence du `product_attribute` PrestaShop, et le fallback par tuple d'options n'a pas matché non plus. Vérifiez que vos déclinaisons PS ont bien des références renseignées, ou contactez le support DataFirefly pour un ajustement personnalisé du matching.
## Ressources
- Fiche produit DataFirefly Shopify Migrator (téléchargements, achat, licence)
- Documentation officielle Shopify Admin REST API : shopify.dev/docs/api/admin-rest
- Documentation Shopify Client Credentials Grant : shopify.dev/docs/apps/build/authentication-authorization/access-tokens/client-credentials-grant
- Support DataFirefly : hello@datafirefly.com
---
### DataFirefly Social Connect — Documentation
_Source :_
> Présentation DataFirefly Social Connect ajoute à PrestaShop 8 et 9 trois boutons de connexion sociale (Google, Apple, Facebook) couplés à un tableau de bord analytique complet. Le module ne se…
## Présentation
DataFirefly Social Connect ajoute à PrestaShop 8 et 9 trois boutons de connexion sociale (Google, Apple, Facebook) couplés à un tableau de bord analytique complet. Le module ne se contente pas d'authentifier : il mesure la conversion, génère automatiquement des bons de bienvenue, alimente votre CRM via un webhook signé, et reste 100% conforme RGPD.
L'objectif est double : **supprimer la friction d'inscription** (un clic au lieu d'un formulaire) et **mesurer l'impact réel** sur votre business (clics, conversions, chiffre d'affaires généré par les clients sociaux).
## Installation
1. Téléchargez l'archive `dfsocialconnect.zip` depuis votre compte client sur datafirefly.com.
2. Dans le back-office PrestaShop, allez dans **Modules > Gestionnaire de modules > Installer un module** et déposez le ZIP.
3. Cliquez sur **Installer**. Le module crée 5 tables (`ps_dfsc_identity`, `ps_dfsc_log`, `ps_dfsc_stats_daily`, `ps_dfsc_button_click`, `ps_dfsc_consent`) et un onglet BO masqué `AdminDfSocialConnect`.
4. Cliquez sur **Configurer**. Vous arrivez sur le tableau de bord vide — les premières données apparaîtront dès qu'un utilisateur cliquera sur un bouton social.
Le module est compatible PrestaShop 8.0.0 à 9.99.99 et PHP 7.4 à 8.3. Aucune dépendance Composer externe n'est requise : un autoloader PSR-4 minimal est inclus.
## Configuration des providers
Chaque provider exige des identifiants OAuth obtenus depuis sa console développeur. Le module affiche l'URL de callback exacte à copier-coller dans chaque console — c'est l'étape la plus importante : la moindre faute de frappe provoque une erreur `redirect_uri_mismatch`.
### Google OAuth2 / OpenID Connect
1. Rendez-vous sur [https://console.cloud.google.com/apis/credentials](https://console.cloud.google.com/apis/credentials).
2. Créez ou sélectionnez un projet, puis cliquez sur **Créer des identifiants > ID client OAuth 2.0**.
3. Type d'application : **Application Web**.
4. Dans **URI de redirection autorisés**, collez l'URL affichée dans l'onglet "Providers" de la configuration du module (forme : `https://votre-boutique.com/module/dfsocialconnect/callback?provider=google`).
5. Récupérez le **Client ID** et le **Client Secret** et collez-les dans le module.
6. Activez le toggle "Google activé".
### Apple Sign In
1. Rendez-vous sur [https://developer.apple.com/account/resources/identifiers/list](https://developer.apple.com/account/resources/identifiers/list) (compte développeur Apple payant requis).
2. Créez un **Services ID** (et non un App ID). Notez son identifier — c'est votre _Client ID_.
3. Activez **Sign In with Apple** sur ce Services ID, configurez le domaine de votre boutique et collez l'URL de callback affichée par le module (provider=apple) en _Return URL_.
4. Dans **Keys**, créez une nouvelle clé avec **Sign In with Apple** activé. Téléchargez le fichier `.p8` — vous ne pourrez plus jamais le récupérer ensuite.
5. Récupérez votre **Team ID** (en haut à droite de la console Apple), votre **Key ID** (l'identifiant de la clé créée à l'étape 4) et le contenu intégral du fichier .p8 (avec les lignes BEGIN PRIVATE KEY et END PRIVATE KEY).
6. Collez les 4 champs dans la configuration du module (Services ID, Team ID, Key ID, contenu .p8).
7. Activez le toggle "Apple activé".
Le module signe la JWT client_secret en ES256 à la volée et la régénère automatiquement tous les 5 mois (la validité maximale autorisée par Apple est de 6 mois). Vous n'avez aucune rotation manuelle à gérer.
### Facebook Login
1. Rendez-vous sur [https://developers.facebook.com/apps](https://developers.facebook.com/apps).
2. Créez une nouvelle app type **Consommateurs**.
3. Dans la section **Add products**, ajoutez **Facebook Login**.
4. Sous **Facebook Login > Settings**, collez l'URL de callback affichée par le module (provider=facebook) dans _Valid OAuth Redirect URIs_.
5. Récupérez l'**App ID** et l'**App Secret** sous **Settings > Basic** et collez-les dans le module.
6. Activez le toggle "Facebook activé".
Le module utilise l'API Graph v19.0 et active automatiquement `appsecret_proof`, qui empêche le rejeu d'un access token volé en exigeant une signature HMAC du secret de l'app.
## Onglet Comportement
Cet onglet pilote ce qui se passe une fois la connexion sociale aboutie.
- **Auto-link par email vérifié** — si l'email retourné par le provider est marqué comme vérifié _et_ correspond à un compte client existant, le module relie automatiquement le provider à ce compte au lieu d'en créer un nouveau. Recommandé : ON.
- **Importer l'avatar** — télécharge la photo de profil dans `/img/dfsc/avatars/.` (limite 2 Mo, MIME whitelist JPEG/PNG/WebP). Survit à l'expiration des CDN provider.
- **Bon de bienvenue** — pour chaque nouveau compte créé via une connexion sociale, le module crée une CartRule PrestaShop à usage unique au nom du client. Configurez le préfixe (par défaut `WELCOME`), le montant et la durée de validité.
- **Groupe client par provider** — assignez un ID de groupe PrestaShop à chaque provider (Google / Apple / Facebook). Utile pour segmenter vos campagnes marketing par origine.
- **Newsletter opt-in par défaut** — si activé, le client créé est marqué comme abonné à la newsletter (à n'activer que si votre processus inclut un double opt-in conforme RGPD).
- **Rate limiting** — nombre maximum de tentatives par IP sur une fenêtre de 15 minutes. Par défaut : 30 tentatives. Au-delà, l'utilisateur reçoit un message "Trop de tentatives".
- **Rétention des logs** — nombre de jours pendant lesquels conserver les logs bruts (`ps_dfsc_log` et `ps_dfsc_button_click`). Le rollup quotidien (`ps_dfsc_stats_daily`) est conservé indéfiniment et alimente le dashboard.
## Onglet Apparence
Choisissez le rendu visuel des boutons :
- **Style** — 5 variantes : _rounded_ (par défaut, coins 8 px), _pill_ (entièrement arrondi), _square_ (anguleux), _ghost_ (transparent avec bordure), _minimal_ (compact).
- **Mode de libellé** — 3 modes : _Continuer avec X_ (par défaut, neutre), _Se connecter avec X_ (page de login), _S'inscrire avec X_ (page d'inscription).
- **Afficher sur la page de login** et **Afficher sur la page d'inscription** — toggles indépendants.
- **Widget Mon compte** — affiche dans l'espace client une zone "Comptes connectés" permettant de lier ou délier chaque provider à tout moment (exigence RGPD).
## Tableau de bord analytique
Le premier onglet de la configuration agrège les statistiques sur 30 jours glissants par défaut (configurable).
- **4 KPI cards** — Connexions réussies, Clics sur les boutons, Nouveaux clients créés, Échecs.
- **Courbe temporelle** — connexions réussies par jour, segmentées par provider (Google bleu, Apple noir, Facebook bleu Meta).
- **Répartition par provider** — doughnut Chart.js avec le pourcentage de chaque provider.
- **Taux de conversion par provider** — clic vs connexion aboutie. Permet d'identifier un provider mal configuré (taux anormalement bas).
- **Breakdown device et navigateur** — bar chart agrégé sur la fenêtre.
- **Heatmap jour × heure** — grille 7 × 24 en 7 nuances de bleu. Identifiez les pics d'usage pour ajuster vos campagnes.
- **Pénétration sociale** — pourcentage de votre base client qui a au moins un provider lié.
- **Revenu généré par les clients sociaux** — somme des commandes payées des clients créés via une connexion sociale, calculée par JOIN SQL sur `ps_orders`.
## Webhook CRM
Sur chaque connexion réussie ou compte lié, le module peut envoyer une requête HTTP POST à une URL de votre choix, en mode _fire-and-forget_ (le temps de réponse de votre endpoint n'impacte pas le temps de connexion utilisateur).
- **URL du webhook** — endpoint HTTPS recommandé. Make, n8n, Zapier ou votre stack interne.
- **Secret partagé** — utilisé pour signer la payload en HMAC-SHA256. La signature est envoyée dans l'en-tête `X-Dfsc-Signature`. Côté réception, recalculez le HMAC sur le body brut pour valider l'authenticité.
Payload type envoyée :
```
{
"event": "social_login_success",
"provider": "google",
"id_customer": 1234,
"email": "marie.dupont@example.com",
"is_new_account": true,
"ip": "203.0.113.42",
"timestamp": 1748378400
}
```
## RGPD et consentement
Le module est conçu pour respecter le RGPD _by design_ :
- À chaque connexion sociale, une ligne est insérée dans `ps_dfsc_consent` avec horodatage, IP, user agent et provider — c'est votre audit trail.
- Le widget "Comptes connectés" dans Mon compte permet au client de délier un provider à tout moment.
- La désinstallation du module supprime proprement les 5 tables et toutes les clés de configuration. Les comptes clients restent intacts.
- Aucun secret OAuth n'est jamais transmis en clair : tous les échanges passent par HTTPS et la JWT Apple est signée localement avec votre clé .p8.
## Désinstallation
Depuis **Modules > Gestionnaire de modules**, désinstallez le module. Le processus :
1. Supprime les 5 tables `ps_dfsc_*`.
2. Supprime l'onglet BO `AdminDfSocialConnect`.
3. Supprime toutes les clés de configuration `DFSC_*`.
4. Les liens sociaux des clients sont supprimés mais **les comptes clients et leurs commandes restent intacts**. Les avatars cachés dans `/img/dfsc/avatars/` sont supprimés.
## Dépannage
**Erreur "redirect_uri_mismatch" (Google)** — l'URL collée dans la console Google ne correspond pas exactement à celle affichée par le module. Vérifiez le scheme (https), le domaine (avec ou sans www), et le chemin complet. Aucun caractère de fin (slash, espace).
**Erreur "invalid_client" (Apple)** — votre JWT client_secret est invalide. Causes fréquentes : Team ID ou Key ID incorrect, contenu .p8 tronqué (vérifiez les lignes BEGIN/END PRIVATE KEY), ou Services ID confondu avec App ID.
**Erreur "Invalid OAuth access token signature" (Facebook)** — votre App Secret est faux. Régénérez-le depuis Settings > Basic et collez-le à nouveau.
**"Trop de tentatives, veuillez patienter"** — déclenchement du rate limiter. Soit attendez 15 minutes, soit augmentez le seuil dans Comportement.
**Les statistiques ne montent pas** — vérifiez que `ps_dfsc_button_click` reçoit bien des lignes (un clic en mode incognito doit suffire). Si rien ne s'écrit, le contrôleur front est probablement non joignable : vérifiez vos règles de réécriture URL.
**Le bon de bienvenue n'est pas créé** — vérifiez que la fonction est activée dans Comportement, que le montant et le préfixe sont renseignés, et que le compte client a bien été créé (et non simplement relié à un compte existant — l'auto-link n'émet pas de voucher).
---
### DataFirefly Social Connect — Guide complet
_Source :_
> Guide complet d'installation, de configuration et d'utilisation de DataFirefly Social Connect : connexion sociale via Google, Apple, Facebook, Microsoft, LinkedIn et X pour WooCommerce, avec statistiques, attribution des commandes, test A/B et anti-fraude.
## Présentation
DataFirefly Social Connect ajoute à votre boutique WooCommerce une connexion sociale en un clic via six fournisseurs (Google, Apple, Facebook, Microsoft, LinkedIn et X), un tableau de bord statistique complet, l'attribution des commandes au fournisseur d'origine, un test A/B des boutons, un système anti-fraude et la conformité RGPD native.
Le plugin n'utilise aucune librairie CDN externe : les graphiques du tableau de bord sont rendus en canvas HTML5 natif, les flux OAuth 2.0 et OpenID Connect sont implémentés directement dans le module (vérification complète des signatures JWKS pour Google One-Tap, signature ES256 à la volée pour Apple, durcissement `appsecret_proof` pour Facebook, PKCE S256 pour X).
**Pré-requis** : WordPress 6.2 ou supérieur, WooCommerce 7.0 ou supérieur, PHP 8.0 ou supérieur. La compatibilité avec HPOS et les blocs de commande WooCommerce est déclarée par le plugin à l'activation.
## Installation
1. Téléchargez le fichier ZIP du plugin depuis votre espace client DataFirefly.
2. Dans WordPress, allez dans _Extensions → Ajouter → Téléverser une extension_.
3. Sélectionnez le ZIP puis cliquez sur _Installer maintenant_.
4. Cliquez sur _Activer_. WooCommerce doit être actif au moment de l'activation, sinon le plugin refuse de s'installer.
5. Un nouveau menu _Social Connect_ apparaît dans la barre latérale d'administration, avec deux sous-pages : _Statistiques_ et _Réglages_.
À l'activation, deux tables SQL sont créées : `wp_dfsc_connections` (comptes liés) et `wp_dfsc_events` (journal des événements pour les statistiques). Les options par défaut sont écrites dans `dfsc_settings`.
## Configuration des fournisseurs
Chaque fournisseur dispose de sa propre carte dans l'onglet _Fournisseurs_ des réglages. Pour chacun, vous trouvez en haut de la carte l'**URI de redirection** à copier-coller dans la console du fournisseur. C'est ce paramètre qui autorise votre site à recevoir le retour de l'authentification.
### Google (avec One-Tap)
1. Allez sur [Google Cloud Console](https://console.cloud.google.com/) et créez (ou sélectionnez) un projet.
2. Dans _APIs & Services → OAuth consent screen_, configurez l'écran de consentement (type Externe pour une boutique publique, ajoutez votre domaine dans les domaines autorisés).
3. Dans _Credentials → Create credentials → OAuth client ID_, choisissez _Web application_.
4. Dans _Authorized redirect URIs_, collez l'URI affichée dans la carte Google de Social Connect (forme : `https://votre-domaine.com/?dfsc_action=callback&dfsc_provider=google`).
5. Pour activer Google One-Tap, ajoutez aussi votre domaine racine dans _Authorized JavaScript origins_.
6. Copiez le _Client ID_ et le _Client secret_ dans les champs correspondants de la carte Google, activez l'interrupteur du fournisseur, et cochez _Afficher l'invite One-Tap aux visiteurs non connectés_ si vous le souhaitez.
One-Tap fonctionne avec une vérification complète de la signature JWKS et un contrôle des claims `aud`, `iss` et `exp`. La validation est cryptographique, pas seulement déclarative.
### Apple (Sign in with Apple)
1. Sur [Apple Developer](https://developer.apple.com/) (compte payant requis), allez dans _Certificates, Identifiers & Profiles → Identifiers_.
2. Créez un _App ID_ avec la capability _Sign In with Apple_ activée.
3. Créez ensuite un _Services ID_ (c'est cet identifiant que vous utiliserez comme « Client ID » côté Social Connect). Configurez son Sign In with Apple : ajoutez votre domaine dans _Domains_, et l'URI de redirection affichée dans la carte Apple dans _Return URLs_.
4. Créez une clé privée (_Keys → +_), avec _Sign In with Apple_ coché, associée à votre App ID. Téléchargez le fichier `.p8` (vous ne pourrez le télécharger qu'une seule fois).
5. Dans la carte Apple, renseignez le _Services ID_, votre _Team ID_ (visible en haut à droite du portail), le _Key ID_ (affiché à côté de la clé créée), et collez le contenu complet du fichier `.p8` dans la zone _Clé privée_ (lignes `-----BEGIN PRIVATE KEY-----` incluses).
Apple ne renvoie le nom de l'utilisateur qu'au tout premier consentement, et ne fournit jamais de photo de profil. Si l'utilisateur active « Hide My Email », un e-mail relais Apple est fourni — le plugin l'utilise normalement. S'il refuse de partager son adresse, un e-mail technique est généré automatiquement par le plugin.
### Facebook
1. Sur [Meta for Developers](https://developers.facebook.com/), créez une application de type _Consumer_.
2. Dans l'application, ajoutez le produit _Facebook Login → Web_.
3. Dans les paramètres de Facebook Login, ajoutez l'URI de redirection affichée dans la carte Facebook dans _Valid OAuth Redirect URIs_.
4. Récupérez l'_App ID_ et l'_App Secret_ dans _Settings → Basic_ et collez-les dans la carte Facebook.
Le plugin durcit chaque appel à la Graph API avec `appsecret_proof` (HMAC-SHA256 du jeton signé avec votre App Secret), conformément aux bonnes pratiques de Meta.
### Microsoft
1. Sur [Microsoft Entra (anciennement Azure AD)](https://entra.microsoft.com/), allez dans _App registrations → New registration_.
2. Donnez un nom à votre application. Pour _Supported account types_, choisissez _Accounts in any organizational directory and personal Microsoft accounts_ si vous voulez accepter les deux (utilise le tenant `common`).
3. Dans _Redirect URI_, choisissez _Web_ et collez l'URI affichée dans la carte Microsoft.
4. Une fois créée, copiez l'_Application (client) ID_ dans le champ correspondant.
5. Dans _Certificates & secrets_, créez un _New client secret_, copiez immédiatement la valeur (elle ne sera plus visible ensuite) dans le champ _Client Secret_.
6. Laissez le champ _Tenant_ sur `common` pour accepter comptes pro et personnels, ou renseignez votre ID de tenant pour restreindre à une organisation.
### LinkedIn
1. Sur [LinkedIn Developers](https://www.linkedin.com/developers/), créez une application liée à votre page entreprise.
2. Dans l'onglet _Products_, demandez l'activation de _Sign In with LinkedIn using OpenID Connect_. L'approbation est automatique.
3. Dans l'onglet _Auth_, ajoutez l'URI de redirection affichée dans la carte LinkedIn dans _Authorized redirect URLs_.
4. Récupérez le _Client ID_ et le _Client Secret_ de l'onglet _Auth_ et collez-les dans Social Connect.
### X (Twitter)
1. Sur le [portail développeurs X](https://developer.x.com/), créez un projet puis une application.
2. Dans _User authentication settings_, activez OAuth 2.0, choisissez le type _Confidential client_ (recommandé), et collez l'URI de redirection affichée dans la carte X dans _Callback URI / Redirect URL_.
3. Renseignez votre _Website URL_ (page d'accueil de votre boutique).
4. Récupérez le _Client ID_ et le _Client Secret_ et collez-les dans Social Connect.
L'API X v2 ne renvoie pas l'adresse e-mail. Le plugin génère automatiquement une adresse technique pour créer le compte WordPress correspondant. Si vous tenez à un e-mail réel, l'utilisateur peut toujours le mettre à jour dans son espace client.
## Placements et apparence
Dans l'onglet _Apparence_, vous choisissez où afficher les boutons :
- **Formulaire de connexion** WooCommerce (page Mon compte non connecté).
- **Formulaire d'inscription** WooCommerce.
- **Page de commande (checkout)**, au-dessus du formulaire.
- **Tableau de bord Mon compte**, avec la liste des comptes liés et les boutons d'association manuelle.
Vous pouvez aussi insérer les boutons n'importe où via le shortcode :
```
[datafirefly_social_connect]
[datafirefly_social_connect context="login" heading="yes" providers="google,apple"]
[datafirefly_social_connect context="custom" redirect="https://votre-site/destination/"]
```
L'apparence est paramétrable sur quatre axes :
- **Style** : plein (couleurs de marque), contour (fond blanc, bordure colorée), minimal (fond gris clair).
- **Forme** : arrondi, pilule, carré.
- **Disposition** : empilés ou en ligne.
- **Libellé** : « Continuer avec… », « Se connecter avec… » ou icône seule.
## Tableau de bord statistique
Le tableau de bord (menu _Social Connect → Statistiques_) regroupe toute l'activité de connexion sociale de votre boutique.
### KPI et graphiques
Sélecteur de période en haut à droite : 7, 30, 90 ou 365 jours. Les six KPI affichés couvrent :
- **Connexions** — total des authentifications sur la période.
- **Inscriptions** — nouveaux comptes créés via connexion sociale.
- **Comptes liés (total)** — nombre cumulé d'identités sociales associées à des utilisateurs.
- **Commandes attribuées** et **CA attribué** — voir la section suivante.
- **Taux de conversion** — ratio commandes / connexions.
Quatre graphiques complètent les KPI : une courbe d'évolution dans le temps par fournisseur, un donut de répartition par fournisseur, un donut de répartition par type d'appareil (ordinateur, mobile, tablette) et une carte « Top pays » alimentée par la géolocalisation.
### Attribution des commandes
Chaque commande WooCommerce passée par un utilisateur arrivé via connexion sociale est attribuée à son fournisseur d'origine. L'attribution s'appuie sur la méta utilisateur `_dfsc_registered_via` et, en secours, sur la première connexion sociale active de l'utilisateur.
Les hooks `woocommerce_checkout_order_processed` et `woocommerce_store_api_checkout_order_processed` sont écoutés, ce qui couvre à la fois le checkout classique et le checkout en blocs.
## Test A/B des boutons
Dans l'onglet _Apparence_, activez le bloc _Test A/B des boutons_ et configurez la variante B (style, forme, disposition, libellé). À partir de ce moment, chaque visiteur reçoit aléatoirement la variante A (vos réglages de base) ou la variante B (cookie `dfsc_ab`, 50/50, conservé 30 jours).
Une impression est comptée une fois par session de visiteur (cookie `dfsc_ab_imp`), pour ne pas gonfler le volume. Les conversions sont mesurées sur les événements de connexion, d'inscription, de liaison et de commande, et reportées sur la carte _Test A/B_ du tableau de bord avec impressions, conversions, commandes attribuées, taux par variante et désignation automatique de la variante gagnante.
Pour obtenir un résultat statistiquement significatif, comptez au minimum 500 impressions par variante. Sous 200, les écarts mesurés sont essentiellement du bruit.
## Anti-fraude — vélocité de connexion
Dans l'onglet _Confidentialité_, vous pouvez activer la limitation de vélocité par adresse IP. Trois seuils sont configurables :
- **Tentatives maximum** — par défaut 8.
- **Fenêtre (minutes)** — par défaut 5.
- **Durée de blocage (minutes)** — par défaut 15.
Une fois la limite franchie, l'IP est bloquée pour la durée configurée. Un événement de type `blocked` est journalisé et apparaît dans l'activité récente. La protection s'applique à la fois aux redirections OAuth classiques et au flux Google One-Tap.
Indépendamment, le plugin maintient une liste de domaines d'e-mails jetables (Mailinator, Yopmail, 10MinuteMail, etc.) qui peuvent être bloqués à l'inscription. La liste est extensible via le filtre `dfsc_disposable_domains`.
## Géolocalisation
Activez la géolocalisation dans l'onglet _Confidentialité_. Le plugin utilise la base MaxMind **déjà embarquée par WooCommerce** — aucun appel à un service externe n'est effectué. Si vous n'avez pas encore activé la géolocalisation côté WooCommerce, allez dans _WooCommerce → Réglages → Général_ et activez l'option de géolocalisation par défaut (WooCommerce téléchargera automatiquement la base de données).
Une fois activée, le pays de chaque connexion est résolu et alimente la carte _Top pays_ du tableau de bord et la colonne « Pays » de l'export CSV.
## Export CSV
Le bouton _Exporter en CSV_ en haut du tableau de bord exporte tous les événements de la période sélectionnée. Le fichier inclut une colonne pour chaque champ pertinent (date UTC, événement, fournisseur, contexte, pays, appareil, variante A/B, utilisateur, commande, montant, message). Le BOM UTF-8 est ajouté en début de fichier pour qu'Excel et LibreOffice Calc affichent correctement les accents.
## Liaison de comptes
Trois mécanismes coexistent pour relier une identité sociale à un compte WordPress :
1. **Identité déjà connue** — l'utilisateur a déjà utilisé ce fournisseur, sa connexion est immédiate.
2. **Liaison automatique par e-mail** — un utilisateur WordPress existe déjà avec la même adresse e-mail que celle renvoyée par le fournisseur. Si l'e-mail est vérifié par le fournisseur (et que l'option _E-mail vérifié requis_ est activée), la liaison est faite automatiquement.
3. **Liaison manuelle** — depuis le tableau de bord _Mon compte_, un client connecté peut associer ou dissocier chaque fournisseur via le panneau _Comptes connectés_.
## RGPD et confidentialité
Trois modes de stockage des IP sont disponibles dans l'onglet _Confidentialité_ :
- **Hachée** (par défaut) — HMAC-SHA256 avec `wp_salt`, non réversible.
- **Complète** — IP en clair (à n'utiliser que si votre politique de confidentialité le mentionne explicitement).
- **Aucune** — l'IP n'est pas du tout enregistrée.
Le plugin déclare un _exporter_ et un _eraser_ auprès du système RGPD natif de WordPress (_Outils → Exporter / Effacer des données personnelles_). À la suppression d'un utilisateur, ses comptes liés et ses événements sont également supprimés (ou anonymisés en cas d'effacement).
## Shortcode et intégration avancée
Le shortcode `[datafirefly_social_connect]` accepte les attributs suivants :
- `context` — `login`, `register`, `checkout` ou `custom`.
- `heading` — `yes` ou `no`, pour afficher le titre « Connexion rapide » au-dessus des boutons.
- `providers` — liste séparée par des virgules pour limiter l'affichage (ex. `google,apple`).
- `redirect` — URL absolue de redirection après connexion (prime sur le réglage global).
Vous pouvez aussi appeler le rendu directement en PHP :
```
echo do_shortcode('[datafirefly_social_connect context="custom" providers="google,microsoft"]');
```
## Hooks et filtres pour développeurs
- `dfsc_disposable_domains` (filtre) — étend ou remplace la liste des domaines d'e-mails jetables.
- `dfsc_user_registered` (action) — déclenchée juste après la création d'un compte via connexion sociale, avec l'ID utilisateur et le profil normalisé.
- `dfsc_after_login` (action) — déclenchée après chaque connexion réussie.
- `dfsc_welcome_subject` et `dfsc_welcome_body` (filtres) — personnalisent le sujet et le corps de l'e-mail de bienvenue.
- `dfsc_placeholder_email_domain` (filtre) — change le domaine utilisé pour les e-mails techniques (Apple Hide My Email refusé, X).
Une API REST en lecture seule expose les statistiques agrégées sur `/wp-json/datafirefly-social-connect/v1/stats?days=30` (capacité `manage_woocommerce` requise). Activez-la dans l'onglet _Confidentialité_.
## Compatibilité
- **WooCommerce HPOS** — la compatibilité `custom_order_tables` est déclarée à l'activation, vos commandes en stockage haute performance sont supportées sans réserve.
- **Blocs de commande** — le hook `woocommerce_store_api_checkout_order_processed` est écouté en parallèle du hook classique, l'attribution des commandes fonctionne sur les deux types de checkout.
- **Polylang et WPML** — les chaînes d'interface sont traduisibles via le fichier `.pot` fourni (FR, EN, ES, DE, IT). Le contenu (e-mail de bienvenue, etc.) est compatible avec les deux plugins multilingues.
- **Multisite** — chaque site du réseau a ses propres tables et options. La désinstallation nettoie chaque site.
## Désinstallation
À la suppression du plugin depuis _Extensions_, le fichier `uninstall.php` est exécuté automatiquement. Il supprime :
- Les tables `wp_dfsc_connections` et `wp_dfsc_events`.
- Les options `dfsc_settings` et `dfsc_db_version`.
- Les transients liés (cache JWKS Google, cache du secret client Apple, jetons d'état).
- Les métadonnées utilisateur (`_dfsc_provider`, `_dfsc_registered_via`, `_dfsc_avatar_id`, etc.).
Vos utilisateurs WordPress et vos commandes WooCommerce ne sont jamais touchés. En multisite, la désinstallation parcourt tous les sites du réseau.
## FAQ et dépannage
### Le bouton Google m'affiche « redirect_uri_mismatch »
L'URI de redirection collée dans Google Cloud Console ne correspond pas exactement à celle affichée dans la carte Google de Social Connect. Vérifiez que vous avez bien copié l'URI complète (avec `https://`, le slash final, et les paramètres `?dfsc_action=callback&dfsc_provider=google`).
### Apple me retourne « invalid_client »
Trois causes possibles : le _Services ID_ renseigné n'est pas un Services ID mais un App ID, le _Team ID_ est erroné, ou le contenu de la clé privée `.p8` est incomplet (lignes `-----BEGIN PRIVATE KEY-----` manquantes). Re-vérifiez les trois et videz le cache du secret client Apple en sauvegardant à nouveau les réglages.
### Facebook me retourne une erreur d'`appsecret_proof`
L'App Secret saisi est incorrect ou a été régénéré côté Meta sans être mis à jour ici. Allez dans Meta for Developers, copiez à nouveau le secret, et collez-le dans la carte Facebook.
### X / Twitter me retourne « invalid_request » au moment du retour
Le _Callback URI_ n'a pas été correctement renseigné dans le portail développeurs X, ou le type d'application n'est pas _Confidential client_ alors que le Client Secret est obligatoire. Re-vérifiez le portail.
### Le tableau de bord est vide alors que j'ai eu des connexions
Vérifiez que la période sélectionnée couvre bien les connexions (par défaut 30 jours). Si vous venez d'activer le plugin, attendez d'avoir au moins quelques événements pour voir les graphiques s'animer.
### Le test A/B affiche des taux à 0 %
Il faut un minimum d'impressions et de conversions pour que les taux deviennent significatifs. Comptez quelques centaines d'impressions par variante avant d'interpréter les résultats.
### La géolocalisation ne renvoie aucun pays
Vérifiez que WooCommerce a bien téléchargé la base MaxMind. Allez dans _WooCommerce → Réglages → Général_, activez la géolocalisation par défaut, et patientez quelques minutes. La base est mise à jour automatiquement par WooCommerce ensuite.
### Comment forcer la dissociation d'un compte côté admin ?
Allez dans la table `wp_dfsc_connections` et supprimez la ligne correspondante. À sa prochaine connexion via ce fournisseur, l'utilisateur sera traité comme une identité nouvelle (rattachée à son compte WordPress par e-mail si la liaison automatique est active).
---
### DataFirefly Speed Pack — Documentation
_Source :_
> DataFirefly Speed Pack regroupe en un seul module le cache page complet, le Critical CSS, la minification et la combinaison des actifs, le Delay JS, le lazy loading natif, les…
DataFirefly Speed Pack regroupe en un seul module le cache page complet, le Critical CSS, la minification et la combinaison des actifs, le Delay JS, le lazy loading natif, les resource hints, la réécriture CDN, les directives serveur et le nettoyage de la base de données. Ce guide couvre l'installation, la prise en main et chaque onglet de configuration.
## Prérequis et compatibilité
- PrestaShop 8.0 à 9.x
- PHP 7.2 à 8.3
- Accès en écriture au dossier de cache et, pour les directives serveur, au fichier htaccess racine
- Multiboutique et multilingue pris en charge
Speed Pack est complémentaire des modules DataFirefly Core Web Vitals et WebP AVIF Pro : il ne duplique ni la conversion d'images, ni les optimisations déjà fournies par ces modules.
## Installation
1. Téléversez l'archive depuis **Modules > Gestionnaire de modules > Téléverser un module**, ou copiez le dossier `datafireflyspeedpack` dans le répertoire `modules/`.
2. Cliquez sur **Installer**.
3. Ouvrez la configuration du module. Un jeton de préchargement est généré automatiquement et affiché dans l'onglet Tableau de bord.
## Prise en main rapide
Pour un démarrage sûr, activez les options dans cet ordre et vérifiez le rendu à chaque étape :
1. Activez uniquement le **Cache page**. Naviguez sur une page de catégorie en navigation privée : le premier chargement renvoie l'en-tête `X-DfSpeedPack-Cache: MISS`, le rechargement renvoie `HIT`.
2. Activez la **minification** HTML/CSS/JS et le **defer**.
3. Activez le **lazy load** des images (en protégeant l'image LCP, voir plus bas).
4. Activez le **Critical CSS** puis le **CSS asynchrone**.
5. Activez le **Delay JS**.
6. En dernier, et seulement après vérification visuelle, activez la **combinaison** CSS/JS.
Dans **Paramètres avancés > Performances**, désactivez l'optimisation CSS/JS native (CCC) et laissez Speed Pack gérer la minification et la combinaison. Le module détecte ce conflit et l'affiche dans le Tableau de bord.
## Cache page
Le cache page sert le HTML mis en cache très tôt, via le hook `actionDispatcherBefore`, avant l'instanciation du contrôleur et les requêtes produits. La clé de cache varie par boutique, langue, devise et appareil.
### Périmètre
Seules les pages d'**invités au panier vide** sont mises en cache. La détection du client connecté et du panier se fait au plus tôt via le cookie. Aucune page de client connecté n'est jamais servie depuis le cache.
### Contrôleurs cachables
La liste blanche des contrôleurs (un par ligne) détermine les pages éligibles : par exemple `index`, `category`, `product`, `cms`, `manufacturer`. Retirez un contrôleur pour l'exclure totalement du cache.
### Exclusions
- **URLs** : sous-chaînes, une par ligne.
- **Cookies** : la présence d'un de ces cookies désactive la mise en cache.
- **User-Agents** : agents exclus.
- **Paramètres d'URL ignorés** : les paramètres de tracking (utm, fbclid, gclid…) sont retirés de la clé pour éviter la fragmentation du cache.
### Durée de vie et invalidation
La durée de vie est configurable (0 = jusqu'à purge manuelle). L'invalidation est **automatique** à chaque modification de produit, catégorie, page CMS, fabricant, fournisseur ou stock. Vous pouvez aussi vider le cache à tout moment depuis le bouton dédié.
## CSS
- **Minification** du CSS inline et combiné.
- **Combinaison** des feuilles locales en un fichier unique, avec réécriture des chemins relatifs dans les règles url().
- **CSS asynchrone** : les feuilles sont chargées via preload puis onload pour éliminer le CSS bloquant.
### Critical CSS
Collez votre CSS above-the-fold par type de page dans les champs dédiés. Il est injecté inline dans l'en-tête, tandis que le reste est chargé en asynchrone. Le champ `*` sert de repli pour toutes les pages sans règle spécifique.
Activez le CSS asynchrone _avec_ le Critical CSS pour éviter tout effet de page non stylée (FOUC).
## JavaScript
- **Minification** du JS inline et combiné.
- **Combinaison** des fichiers JS locaux.
- **Defer** automatique des scripts.
### Delay JS
Le Delay JS reporte l'exécution des scripts jusqu'à la première interaction de l'utilisateur (scroll, clic, touche, mouvement de souris ou toucher), avec un repli temporisé. C'est le gain le plus important sur le TBT et le score mobile.
- **Inclure uniquement** : si renseigné, seuls les scripts contenant ces mots-clés sont retardés.
- **Exclure** : mots-clés des scripts à ne jamais retarder (ex. jquery, core).
- Ajoutez l'attribut `data-df-nodelay` sur une balise script pour l'exclure individuellement.
## Médias
Le lazy loading natif ajoute les attributs `loading=lazy` et `decoding=async` aux images, et `loading=lazy` aux iframes.
Protégez votre image LCP (visuel hero, première image visible) en lui ajoutant l'attribut `data-no-lazy` ou en l'ajoutant aux exclusions. Sinon le lazy load peut dégrader le LCP.
## Resource hints
- **Preconnect** et **DNS-prefetch** : une URL par ligne, pour les domaines tiers (polices, analytics, CDN).
- **Preload** : au format `url|type` (ex. `/img/hero.webp|image`). Types possibles : image, font, style, script. Préchargez votre image LCP et vos polices critiques.
- **font-display swap** : injecté dans les règles de polices inline pour éviter le texte invisible.
## CDN
La réécriture CDN remplace l'hôte local des actifs statiques par votre domaine CDN. Renseignez l'URL du CDN, puis les motifs (expressions régulières) inclus et exclus, une par ligne. Seuls les actifs locaux correspondant aux motifs inclus sont réécrits.
## Serveur (htaccess)
Speed Pack peut écrire des directives serveur entre des marqueurs dédiés dans le fichier htaccess racine :
- Compression GZIP / Brotli
- Cache navigateur des actifs (un an, immutable)
- Connection Keep-Alive
Les directives sont retirées automatiquement à la désinstallation. Si le fichier n'est pas accessible en écriture, un avertissement s'affiche.
Si votre serveur active déjà la compression (par exemple via la configuration du serveur web), il est inutile de la dupliquer ici.
## Base de données
Le nettoyage supprime les paniers abandonnés (sans commande, au-delà du nombre de jours configuré) et les lignes orphelines associées, les connexions et invités anciens, ainsi que les statistiques de recherche et logs anciens.
Les commandes ne sont jamais touchées. Réalisez néanmoins une sauvegarde de la base avant le premier nettoyage.
## Préchargement du cache
Le préchargement (warmer) collecte les URLs depuis votre sitemap puis préchauffe le cache, afin que vos visiteurs reçoivent toujours une page en HIT.
### Depuis le back-office
Onglet Tableau de bord : cliquez sur **Collecter les URLs** puis sur **Précharger**. Une barre de progression suit l'avancement par lots.
### Par tâche CRON
Automatisez la collecte et le préchargement après chaque purge nocturne. Le jeton est affiché dans le Tableau de bord.
```
curl -s "https://votre-boutique/module/datafireflyspeedpack/preload?action=collect&token=VOTRE_TOKEN"
curl -s "https://votre-boutique/module/datafireflyspeedpack/preload?action=warm&token=VOTRE_TOKEN"
```
## Attributs de contrôle dans le thème
- `data-no-lazy` — désactive le lazy load sur une image ou un iframe (image LCP).
- `data-df-nodelay` — exclut une balise script du Delay JS.
- `data-df-nodefer` — exclut une balise script du defer.
- `data-df-nooptim` — exclut un bloc ou un lien de la minification et de la combinaison.
## Import / Export des réglages
Depuis l'onglet Avancé, exportez l'ensemble des réglages au format JSON pour les répliquer sur une autre boutique, ou importez un fichier existant.
## Dépannage
### Une page reste en MISS
Vérifiez que vous naviguez en invité (déconnecté, panier vide), que le contrôleur est dans la liste blanche, que l'URL n'est pas exclue et qu'aucun cookie d'exclusion n'est présent. Les employés connectés au back-office ne reçoivent jamais de page cachée.
### Un affichage casse après activation de la combinaison
Désactivez la combinaison CSS/JS, ou ajoutez le fichier fautif aux exclusions correspondantes. La combinaison est volontairement désactivée par défaut.
### Texte non stylé au chargement (FOUC)
Activez ou complétez le Critical CSS de la page concernée, et assurez-vous que le CSS asynchrone est activé.
### Un script ne fonctionne plus avec le Delay JS
Ajoutez son mot-clé à la liste d'exclusion du Delay JS, ou l'attribut `data-df-nodelay` sur la balise.
## Désinstallation
La désinstallation retire les directives htaccess, vide les caches et supprime les réglages et l'onglet d'administration du module.
---
### DataFirefly Staging Pro — Guide complet
_Source :_
> Staging Pro crée une copie complète de votre boutique (fichiers + base de données) dans un sous-dossier protégé de votre hébergement actuel, sans aucun timeout grâce à son moteur de…
Staging Pro crée une copie complète de votre boutique (fichiers + base de données) dans un sous-dossier protégé de votre hébergement actuel, sans aucun timeout grâce à son moteur de copie par lots. Vous testez modules, thèmes et mises à jour en toute sécurité, puis renvoyez vos modifications en production table par table, avec backup automatique et rollback en un clic. Ce guide couvre l'installation, la création d'un staging, les options de protection, le push vers la production et le rollback.
## Installation
1. Téléchargez l'archive `dfstagingpro.zip` depuis votre compte DataFirefly.
2. Back-office PrestaShop → **Modules** → **Téléverser un module** → envoyez le ZIP.
3. À l'installation, le module crée ses tables `df_staging_env` et `df_staging_log`, enregistre ses hooks et ajoute l'onglet **Paramètres avancés → Staging Pro**.
Compatible PrestaShop 8.0 à 9.x. PHP doit pouvoir écrire à la racine de la boutique (création du sous-dossier de staging) et l'utilisateur MySQL doit pouvoir CREATE, DROP et RENAME TABLE — ce qui est le cas d'une installation PrestaShop standard. Aucune dépendance Composer.
## Comment fonctionne le staging
Un environnement de staging est créé dans un sous-dossier à la racine de votre boutique (par exemple `/staging-v2/`) et utilise un préfixe de tables dédié (par exemple `dfs1_`) dans la **même base de données** que la production. Vous n'avez donc besoin ni d'un second serveur, ni d'un nouvel accès MySQL, ni d'une configuration DNS.
Le moteur de copie travaille par lots de quelques secondes puis rend la main, en reprenant exactement où il s'était arrêté : copie des fichiers via une file d'attente persistante, clonage de la base par paquets de lignes. Une boutique de plusieurs gigaoctets se clone ainsi sans erreur, même sur un hébergement mutualisé avec un `max_execution_time` bas.
## Créer un staging
Rendez-vous dans **Paramètres avancés → Staging Pro**, puis dans le panneau de création :
1. Saisissez un **nom** (minuscules, chiffres et tirets uniquement, par exemple `v2`). L'URL du staging sera `votre-boutique.com/staging-v2/`.
2. Choisissez vos **options de protection et de copie** (voir ci-dessous).
3. Cliquez sur **Créer**. La progression s'affiche en direct avec une barre d'avancement.
À la fin du processus, l'URL du staging et, le cas échéant, les identifiants htpasswd s'affichent sur la ligne de l'environnement.
### Options de protection et de copie
- **Protéger avec .htpasswd** : ajoute une authentification HTTP (utilisateur `staging`). Le mot de passe peut être saisi ou généré automatiquement, puis affiché sur le tableau de bord.
- **Désactiver les e-mails** : coupe les e-mails sortants du staging (PS_MAIL_METHOD = 3). Aucun risque d'écrire à un vrai client.
- **Désactiver les paiements** : désactive et déshooke les modules de paiement connus sur le staging.
- **Ignorer les statistiques** : exclut de la copie les tables volumineuses et non essentielles (connexions, logs, paniers abandonnés…) pour une copie beaucoup plus rapide.
- **Sans données clients** : crée vides sur le staging les tables de clients, adresses clients, commandes, paniers, messages, invités, newsletter et logs RGPD. Les adresses fournisseurs, fabricants et entrepôts sont conservées, ainsi que les tables de configuration des commandes (états, modèles de messages, états de retour, règles panier). Voir la section dédiée plus bas.
- **Symlink du dossier img/** : crée un lien symbolique vers les images au lieu de les copier, pour une énorme économie d'espace disque.
- **Mode maintenance** : place le staging en maintenance avec votre IP d'administration en liste blanche.
Dès sa création, tout staging reçoit automatiquement un en-tête `X-Robots-Tag: noindex`, une meta `noindex` et un `robots.txt` bloquant, ainsi qu'une bannière orange STAGING sur le front-office et dans le back-office. Vos environnements de test ne risquent pas d'être indexés par Google.
L'option symlink `img/` partage le dossier d'images avec la production : modifier ou supprimer une image côté staging affecte aussi la boutique en ligne. À réserver aux tests qui ne touchent pas aux images.
## Le moteur de copie par lots
La création d'un staging enchaîne plusieurs étapes, chacune budgétée en temps et reprise automatiquement : préparation, copie des fichiers, clonage de la base de données, réécriture des URLs, configuration et protection, puis finalisation. La réécriture d'URL couvre `shop_url`, la configuration (y compris les valeurs sérialisées et JSON, traitées sans corruption), ainsi que les contenus CMS, produits, catégories, marques, fournisseurs et magasins.
Si la page est fermée pendant la création, l'environnement reste en cours et reprend automatiquement la copie à la réouverture du tableau de bord, exactement là où elle s'était arrêtée.
## Rafraîchir, multi-environnements et suppression
- **Refresh** : reconstruit un staging existant depuis l'état actuel de la production (suppression puis recréation du dossier et du préfixe), en un clic.
- **Multi-environnements** : créez autant de stagings que nécessaire (v2, hotfix, test-module…), chacun indépendant.
- **Suppression** : supprime le dossier et les tables d'un environnement de façon budgétée, sans timeout.
## Pousser vers la production
Une fois vos tests validés, le bouton **Push** permet de renvoyer vos modifications en production, table par table :
1. Cliquez sur **Push** sur la ligne de l'environnement : la liste des tables s'affiche, avec le nombre de lignes de chacune.
2. Cochez précisément les tables à transférer.
3. Confirmez. Avant chaque remplacement, la table de production correspondante est sauvegardée automatiquement par un renommage horodaté vers un préfixe `dfbak{horodatage}_`.
Les URLs sont réécrites dans le sens staging → production lors du transfert. Les tables critiques (`shop_url`, `configuration`, `shop`, sessions et tables du module) sont protégées et ne peuvent jamais être poussées.
Le push modifie votre boutique en production. Le backup automatique protège les tables remplacées, mais vérifiez toujours votre sélection. Évitez de pousser les tables de commandes ou de clients si la production a continué à enregistrer des ventes depuis la création du staging.
## Rollback
Le bouton **Rollback** restaure la production depuis le dernier backup de push, en un clic. Le module renomme les tables de sauvegarde `dfbak…_` pour reprendre leur place d'origine.
Une fois un push validé et stable, supprimez les anciennes tables `dfbak*` (via phpMyAdmin ou tout client SQL) pour libérer de l'espace dans votre base de données.
## Garde-fous et journal
- Toutes les actions sont bloquées si la boutique courante est elle-même un staging, pour éviter les manipulations en cascade.
- Un journal détaillé est disponible par environnement via le bouton **Logs**.
- Le `robots.txt` dans un sous-dossier n'étant pas honoré par les moteurs, la vraie protection anti-indexation repose sur l'en-tête `X-Robots-Tag` et la meta `noindex` ; l'option `.htpasswd` reste la protection la plus sûre.
## Compatibilité et notes techniques
- PrestaShop 8.0 à 9.x, compatible hébergement mutualisé et multilingue.
- Contrôleur d'administration legacy (pas de contrôleur Symfony) pour la compatibilité PS8/PS9.
- Endpoints AJAX back-office via le 4ᵉ argument de `getAdminLink()` ; rendu JSON par une méthode dédiée.
- Staging = sous-dossier à la racine + préfixe de tables `dfs{id}_` dans la même base MySQL.
- Backups de push horodatés sous le préfixe `dfbak{YmdHis}_`, à purger après validation.
## Staging sans données clients
L'option **Sans données clients**, disponible depuis la version 1.1.0, crée le staging sans aucune donnée personnelle. Les tables concernées sont bien créées, avec leur structure exacte, mais restent vides. C'est le choix recommandé pour confier un staging à un prestataire externe, pour un test de thème ou de module qui ne touche pas au tunnel de commande, et pour limiter la surface RGPD de vos environnements de test.
### Ce qui n'est pas copié
- Clients, groupes de clients, fils de discussion et messages du SAV, sessions clients, invités et statistiques de connexion.
- Commandes et toute la famille associée : détails, historique, factures, paiements, transporteurs, règles panier appliquées, avoirs et retours.
- Paniers, produits des paniers, listes d'envies, messages, inscriptions à la newsletter, logs RGPD et logs de mails.
- Adresses des clients : la table `address` est copiée avec un filtre, seules les lignes rattachées à un client sont écartées.
### Ce qui est conservé
- Adresses de fournisseurs, fabricants, entrepôts et magasins.
- Tables de configuration des commandes : états de commande et leurs traductions, modèles de messages, états de retour, types d'avoirs.
- Règles panier, bons de réduction, transporteurs, taxes et l'ensemble du catalogue.
- Employés du back-office : vous vous connectez au staging avec vos identifiants habituels.
Sur un staging créé avec cette option, les tables clients et commandes sont retirées de la liste de push et refusées par le serveur si la requête est forgée. Sans ce garde-fou, pousser une table vide écraserait les données de production correspondantes.
Pour tester le tunnel de commande sur un tel staging, passez une commande en tant qu'invité ou créez un compte de test : les tables sont vides mais pleinement fonctionnelles.
## Authentification HTTP et hébergements cPanel / LiteSpeed
Depuis la version 1.0.1, le fichier `.htpasswd` est généré au format APR1-MD5 (celui de la commande `htpasswd -m`), lu par Apache, LiteSpeed et nginx. La version 1.0.0 utilisait bcrypt, que LiteSpeed (très courant derrière cPanel, par exemple chez o2switch) ne sait pas lire : le staging répondait alors 404 sur toutes ses pages.
Le bloc de protection ajoute aussi une page d'erreur 401 inline. Sur cPanel, l'erreur 401 est redirigée globalement vers `/401.shtml`, une page qui n'existe pas dans PrestaShop : la sous-requête tombe dans le dispatcher de la production et renvoie sa page 404, si bien que le navigateur n'affiche jamais la boîte de connexion. La page inline court-circuite cette redirection.
Enfin, la ligne `ErrorDocument 404` du `.htaccess` copié est réécrite vers le sous-dossier de staging : une erreur sur le staging affiche la page 404 du staging, et non celle de la production.
### Auto-vérification à la création
À la fin de la configuration, le module envoie une requête HEAD sur le `robots.txt` du staging, avec les identifiants si la protection est active, puis sans identifiants pour vérifier que le serveur répond bien 401. Le résultat est consigné dans les logs de l'environnement :
- 200 avec identifiants et 401 sans : tout est en ordre.
- Le serveur refuse le bloc d'authentification : le module retire le bloc et le `.htpasswd`, désactive l'option et affiche « Ready with warning » sur la ligne de l'environnement. Le staging est alors accessible sans mot de passe ; activez le mode maintenance.
- Code 0 : le serveur ne peut pas s'appeler lui-même (requêtes sortantes bloquées). Ouvrez l'URL du staging manuellement.
Pour vérifier depuis un terminal : `curl -sI https://votre-boutique.com/staging-v2/robots.txt` doit répondre 401, et la même commande avec `-u staging:motdepasse` doit répondre 200.
## FAQ et dépannage
**Le module fonctionne-t-il sur un hébergement mutualisé ?** Oui. Le moteur de copie par lots avec reprise automatique évite tout timeout, quel que soit le `max_execution_time` du serveur.
**La création s'est interrompue, que faire ?** Rouvrez le tableau de bord Staging Pro : l'environnement reprend automatiquement la copie là où elle s'était arrêtée.
**Le staging peut-il envoyer des e-mails à mes clients ?** Non si l'option « Désactiver les e-mails » est active (recommandé) : les e-mails sortants sont coupés sur le staging.
**Après un push, comment annuler ?** Utilisez le bouton Rollback, qui restaure le dernier backup automatique. Pensez ensuite à purger les tables `dfbak*` obsolètes.
**Puis-je créer plusieurs stagings en même temps ?** Oui, le nombre d'environnements est illimité et chacun est totalement indépendant.
**Le staging répond 404 partout, ou la boîte de connexion ne s'affiche pas ?** C'est le symptôme corrigé en 1.0.1 sur les hébergements cPanel / LiteSpeed. Mettez le module à jour puis relancez un Refresh de l'environnement ; consultez la section « Authentification HTTP et hébergements cPanel / LiteSpeed » ci-dessus.
**Puis-je créer un staging sans les données de mes clients ?** Oui, cochez « Sans données clients » à la création. Voir la section « Staging sans données clients » ci-dessus.
## Historique des versions
### 1.1.0 (4 septembre 2026)
- Nouvelle option « Sans données clients » : clients, adresses clients, commandes, paniers, messages, invités, newsletter et logs RGPD créés vides sur le staging.
- Adresses fournisseurs, fabricants et entrepôts conservées, ainsi que les tables de configuration des commandes.
- Garde-fou de push : ces tables sont retirées de la liste et refusées côté serveur sur un staging créé sans données clients.
### 1.0.1 (3 septembre 2026)
- Protection htpasswd : hash généré en APR1-MD5, compatible Apache et LiteSpeed (bcrypt était rejeté sur certains hébergements cPanel, rendant le staging inaccessible).
- Boîte de connexion HTTP : page 401 inline, pour les hébergements qui redirigent les erreurs 401 vers une page inexistante.
- Ligne `ErrorDocument` du `.htaccess` réécrite vers le sous-dossier de staging.
- Auto-vérification à la fin de la création : contrôle HTTP du staging, retrait automatique de la protection si le serveur la refuse et avertissement dans le dashboard.
### 1.0.0 (11 juin 2026)
Première version publique.
---
### DataFirefly Subscriptions — Guide complet (PrestaShop 8 & 9)
_Source :_
> Présentation DataFirefly Subscriptions transforme votre boutique PrestaShop 8 ou 9 en machine à revenus récurrents. Le module repose sur une architecture « card on file » : le client paie…
## Présentation
DataFirefly Subscriptions transforme votre boutique PrestaShop 8 ou 9 en machine à revenus récurrents. Le module repose sur une architecture **« card on file »** : le client paie une seule fois au checkout via une option de paiement native, sa carte est enregistrée de façon sécurisée chez Stripe, puis un cron quotidien débite automatiquement la carte à chaque échéance et crée une **vraie commande PrestaShop** au montant exact, frais de port inclus.
Points clés de l'architecture :
- **Un seul moteur de facturation** — aucun objet Subscription côté Stripe, tout est piloté par votre boutique. Les doubles débits sont structurellement impossibles.
- **Montants exacts** — chaque renouvellement reconstruit un panier réel et calcule le total via le moteur de prix PrestaShop (remises, taxes, port).
- **3DS/SCA géré** — l'authentification forte est gérée au paiement initial ; les renouvellements utilisent le mécanisme off-session conforme SCA.
- **Aucune donnée bancaire côté PrestaShop** — la conformité PCI-DSS est portée par Stripe.
## Installation
1. Téléchargez le ZIP du module depuis votre compte client DataFirefly.
2. Dans votre back-office PrestaShop : **Modules → Gestionnaire de modules → Installer un module**, puis sélectionnez le ZIP.
3. Le module crée automatiquement ses tables, ses onglets d'administration (Abonnements, Plans, Logs, Dashboard) et enregistre ses hooks.
4. Cliquez sur **Configurer** pour ouvrir la page de configuration.
**Prérequis :** PrestaShop 8.0 à 9.x, PHP 8.0 à 8.4, un compte Stripe (gratuit), et la possibilité de créer une tâche cron chez votre hébergeur. Aucune dépendance Composer n'est requise.
**Mise à jour depuis une version 1.x :** installez simplement le nouveau ZIP par-dessus. Les scripts de migration s'exécutent automatiquement et enregistrent notamment les restrictions devises/pays/transporteurs nécessaires à l'affichage de l'option de paiement au checkout.
## Configuration Stripe
### Clés API
Dans la configuration du module, renseignez vos clés Stripe. Le module gère deux jeux de clés distincts :
- **Mode test** : clé publique `pk_test_...` et clé secrète `sk_test_...` — pour valider le parcours complet sans débit réel (carte de test `4242 4242 4242 4242`).
- **Mode live** : clé publique `pk_live_...` et clé secrète `sk_live_...` — pour la production.
Vous trouverez ces clés dans votre dashboard Stripe : **Développeurs → Clés API**. Basculez entre test et live avec l'interrupteur « Mode » du module.
### Webhook
Le webhook sert uniquement aux événements exceptionnels (la facturation est pilotée par le cron, pas par Stripe). Dans votre dashboard Stripe : **Développeurs → Webhooks → Ajouter un endpoint**, avec l'URL affichée dans la configuration du module (de la forme `https://votreboutique.fr/module/dfsubscription/webhook`), et abonnez-vous à ces trois événements :
- `payment_method.detached` — carte supprimée côté Stripe : l'abonnement passe en « paiement échoué » pour vous prévenir avant l'échéance.
- `charge.dispute.created` — litige (chargeback) : journalisé sur l'abonnement concerné.
- `charge.refunded` — remboursement : journalisé sur l'abonnement concerné.
Copiez ensuite le **secret de signature** (`whsec_...`) fourni par Stripe dans le champ correspondant de la configuration.
**Important :** en mode live, les requêtes webhook non signées sont refusées. Renseignez impérativement le secret de signature avant de passer en production.
## Configuration du cron
Le cron est le moteur des renouvellements : il détecte chaque jour les abonnements arrivés à échéance, débite les cartes enregistrées et crée les commandes. L'URL sécurisée par token est affichée dans la configuration et le dashboard du module, de la forme :
```
https://votreboutique.fr/module/dfsubscription/cron?token=VOTRE_TOKEN
```
Créez une tâche cron quotidienne chez votre hébergeur (cPanel, Plesk, crontab) qui appelle cette URL. Exemple crontab pour une exécution chaque jour à 6h00 :
```
0 6 * * * curl -s "https://votreboutique.fr/module/dfsubscription/cron?token=VOTRE_TOKEN" > /dev/null 2>&1
```
Une exécution quotidienne suffit : le module traite en une passe tous les abonnements dus, avec une limite de temps étendue pour les gros volumes. Vous pouvez aussi utiliser un service externe comme cron-job.org si votre hébergeur ne propose pas de cron.
## Créer des plans d'abonnement
Les plans se gèrent directement depuis la fiche produit du back-office : **Catalogue → Produits → votre produit → onglet Modules / DataFirefly Subscriptions**. Pour chaque plan, définissez :
- **Fréquence de facturation** — hebdomadaire, bimensuelle, mensuelle, trimestrielle, semestrielle ou annuelle.
- **Fréquence de livraison** — identique à la facturation, hebdomadaire, bimensuelle ou mensuelle. Exemple : facturation mensuelle + livraison hebdomadaire = box hebdo à paiement mensuel.
- **Remise (%)** — la réduction accordée aux abonnés par rapport au prix one-shot. Elle s'affiche sur la fiche produit et s'applique aussi à chaque renouvellement.
- **Engagement minimum** — nombre de cycles avant que la résiliation soit possible (0 = résiliation libre).
- **Cycles maximum** — pour des abonnements à durée limitée (0 = illimité).
- **Jours d'essai** — période d'essai avant la première facturation.
Un produit peut proposer plusieurs plans (ex. mensuel -10 % et annuel -20 %) : le client choisit dans le bloc « Abonnez-vous et économisez » de la fiche produit.
## Parcours client
### Fiche produit
Un bloc dépliable présente les plans disponibles avec leurs prix remisés. Le client sélectionne son plan (la sélection est enregistrée en base, fiable même s'il change d'appareil), puis ajoute au panier normalement.
### Checkout et paiement
À l'étape paiement, l'option **« Payer par carte et activer mon abonnement »** apparaît si le panier contient uniquement des produits en abonnement et que le client est connecté. Le formulaire carte sécurisé Stripe s'affiche directement dans la page :
1. Le client saisit sa carte ; le 3D Secure se déclenche automatiquement si sa banque l'exige.
2. Le paiement couvre le **total exact du panier**, frais de port inclus.
3. La carte est enregistrée chez Stripe pour les cycles suivants (card on file, avec consentement conforme SCA).
4. Le module re-vérifie côté serveur le statut et le montant du paiement avant de créer la commande — le navigateur n'est jamais cru sur parole.
Les paniers mixtes (abonnement + produit classique) sont bloqués côté client et côté serveur : le client est invité à finaliser séparément. C'est ce qui garantit des montants de renouvellement toujours cohérents.
## Renouvellements
À chaque exécution du cron, pour chaque abonnement arrivé à échéance :
1. Le module reconstruit un **vrai panier PrestaShop** : produit, déclinaison, adresse et transporteur d'origine.
2. La remise du plan est appliquée via une règle panier automatique à usage unique.
3. Le total exact est calculé par le moteur de prix natif — taxes et frais de port inclus si l'option « Port sur les renouvellements » est activée (elle l'est par défaut).
4. La carte enregistrée est débitée hors session pour précisément ce montant.
5. Une commande PrestaShop standard est créée, avec l'état de commande de votre choix (configurable, ex. un état dédié « Renouvellement »).
6. Le client reçoit l'email de confirmation de renouvellement ; l'événement est journalisé.
Chaque commande de renouvellement est visible dans **Commandes** comme n'importe quelle vente, avec sa transaction Stripe associée — vos exports comptables et votre gestion de stock fonctionnent sans modification.
## Dunning : gestion des échecs de paiement
Quand un débit de renouvellement échoue (carte expirée, plafond, refus bancaire) :
1. L'abonnement passe en statut **« paiement échoué »** et le client reçoit immédiatement un email de relance l'invitant à mettre à jour sa carte.
2. Le cron retente automatiquement le paiement — par défaut **3 tentatives à 3 jours d'intervalle**, les deux valeurs étant configurables.
3. Après le nombre d'échecs consécutifs configuré, l'abonnement est annulé automatiquement et le client en est informé.
Chaque tentative et son résultat sont journalisés dans les logs de l'abonnement. En pratique, le dunning récupère 50 à 70 % des paiements qui auraient été perdus en échec sec.
## Espace client « Mes abonnements »
Accessible depuis le compte client, cet espace liste les abonnements avec leur statut, la prochaine date de facturation et de livraison. Selon vos réglages, le client peut :
- **Mettre en pause / reprendre** — les dates sont recalculées à la reprise.
- **Sauter le prochain cycle** — la facturation et la livraison sont décalées ensemble d'une période.
- **Résilier** — librement, ou seulement après l'engagement minimum du plan. À la résiliation, la carte enregistrée est automatiquement détachée chez Stripe et un email de confirmation est envoyé.
Chaque action demande une confirmation et suit le pattern POST-redirect-GET : pas de double soumission possible, messages de confirmation natifs PrestaShop.
## Back-office
- **Dashboard** — MRR, abonnements actifs, taux de churn, paiements en échec, URL de cron et de webhook prêtes à copier.
- **Abonnements** — liste filtrable par statut, fréquence et client ; vue détaillée avec l'historique des commandes générées et les logs, et liens directs vers la commande et la fiche client.
- **Plans** — vue d'ensemble de tous les plans existants (la création se fait depuis la fiche produit).
- **Logs** — tous les événements horodatés : créations, renouvellements, échecs, relances, pauses, résiliations, webhooks reçus.
### Actions administrateur sur un abonnement (v2.2)
Depuis la vue détail d'un abonnement, un employé disposant de la permission de modification peut agir directement. Chaque action demande une confirmation, est journalisée avec le nom de l'administrateur, et le client est notifié par email quand c'est pertinent :
- **Pause / Reprise** — la reprise recalcule les dates depuis aujourd'hui et remet le compteur d'échecs à zéro.
- **Sauter le prochain cycle** — facturation et livraison reportées ensemble d'une période.
- **Facturer maintenant** — débite immédiatement la carte enregistrée via le même moteur que le cron (panier reconstruit, total exact) et crée la commande. Idéal pour relancer un abonnement en « paiement échoué » après que le client a mis sa carte à jour ; en cas de nouvel échec, le dunning normal prend le relais.
- **Modifier les prochaines dates** — édition directe de la prochaine facturation et de la prochaine livraison.
- **Changer de plan** — bascule vers un autre plan actif du même produit, applicable aux cycles suivants (la date de prochaine facturation n'est pas modifiée).
- **Résilier** — motif facultatif journalisé, détachement de la carte coché par défaut. L'administrateur n'est pas soumis à l'engagement minimum, contrairement au client.
Sur la liste des abonnements, deux actions groupées sont disponibles : pause et résiliation en masse. Les abonnements dans un état incompatible sont ignorés et comptabilisés dans le message de résultat.
## FAQ technique et dépannage
### L'option de paiement n'apparaît pas au checkout
- Vérifiez que le panier ne contient **que** des produits avec un plan sélectionné et que le client est connecté.
- Vérifiez que les clés Stripe du mode actif sont renseignées.
- Si vous venez de migrer depuis une version 1.x : réinstallez le module ou relancez la mise à jour — les restrictions devises/pays/transporteurs sont ajoutées par les scripts de migration 2.x et sont indispensables à l'affichage de l'option.
### Les renouvellements ne se déclenchent pas
- Vérifiez que la tâche cron est bien planifiée et que son URL contient le bon token (testez l'URL dans un navigateur : elle doit répondre avec un résumé JSON).
- Consultez l'onglet Logs : chaque exécution du cron y laisse une trace.
### Un paiement 3DS reste « en attente »
Si le client ferme la page pendant l'authentification 3D Secure, aucun débit n'a lieu et aucune commande n'est créée. Il peut simplement repasser commande ; le paiement précédent expirera de lui-même côté Stripe.
### Comment tester le parcours complet ?
1. Passez le module en mode test et renseignez les clés `pk_test`/`sk_test`.
2. Créez un plan sur un produit, passez une commande avec la carte `4242 4242 4242 4242` (ou `4000 0027 6000 3184` pour forcer un défi 3DS).
3. Dans la base, avancez la date `next_billing_date` de l'abonnement à hier, puis appelez l'URL de cron : une commande de renouvellement doit apparaître.
4. Pour tester le dunning, utilisez la carte `4000 0000 0000 0341` (échec au débit off-session).
Besoin d'aide ? Ouvrez un ticket depuis votre compte client DataFirefly — réponse sous 24h ouvrées, en français ou en anglais.
---
### DataFirefly Vente Flash & Compte à rebours pour Shopware 6 — Installation, configuration et utilisation
_Source :_
> Présentation DataFirefly Vente Flash & Compte à rebours transforme vos promotions Shopware en ventes flash planifiées : la remise est appliquée à la volée par un processeur de panier natif,…
## Présentation
DataFirefly Vente Flash & Compte à rebours transforme vos promotions Shopware en ventes flash planifiées : la remise est appliquée à la volée par un processeur de panier natif, activée et coupée à la seconde près, sans CRON et sans modifier les données de vos produits. Le prix barré s'affiche nativement sur les fiches produit et les listings, et une bannière sticky à compte à rebours synchronisée sur l'heure du serveur crée l'urgence.
## Prérequis
- Shopware 6.5.x, 6.6.x ou 6.7.x (un seul et même ZIP)
- PHP 8.1 minimum
- Aucun CRON, aucune Scheduled Task, aucun build Node.js requis
## Installation
### Via l'administration
1. Extensions > Mes extensions > **Charger l'extension**, puis sélectionnez le fichier `DfFlashSale-1.0.0.zip`.
2. Cliquez sur **Installer**, puis **Activer**.
### Via la ligne de commande
```
bin/console plugin:refresh
bin/console plugin:install --activate DfFlashSale
bin/console assets:install
bin/console cache:clear
```
Le JS d'administration est livré **pré-compilé**, y compris pour le nouveau chargeur Vite de Shopware 6.7 : aucun `build-administration.sh` n'est nécessaire. Après `assets:install` + `cache:clear`, rechargez l'admin avec Ctrl+F5.
Si vous transférez le plugin par FTP, vérifiez que le dossier caché `src/Resources/public/administration/.vite/` est bien copié : certains clients FTP excluent les fichiers commençant par un point. Sans lui, l'entrée de menu n'apparaît pas sur Shopware 6.7.
## Créer une campagne
Rendez-vous dans **Marketing > Ventes Flash > Créer une vente flash**. Une campagne se configure en cinq blocs :
### Campagne
- **Nom interne** : visible uniquement dans l'admin.
- **Active** : interrupteur général de la campagne.
- **Dates de début et de fin** : la remise et la bannière s'activent et se coupent automatiquement à la seconde près, selon l'heure du serveur.
### Remise
- **Type** : pourcentage ou montant fixe.
- **Valeur** : ex. 30 pour −30 %, ou 10 pour −10 € par unité.
### Ciblage
- **Tout le catalogue**, **Catégories** (les sous-catégories sont incluses automatiquement via l'arbre de catégories) ou **Produits sélectionnés** (les variantes d'un produit parent sélectionné sont couvertes).
- **Canaux de vente** : laissez vide pour tous les canaux, ou restreignez la campagne à certains canaux.
### Bannière sticky
- **Portée** : toutes les pages (hors checkout), page d'accueil uniquement ou fiches produit uniquement.
- **Position** : haut ou bas de page, avec décalage automatique du contenu.
- **Couleurs** : fond, texte et accent, par campagne.
- **Textes** : texte de la bannière, texte du teaser et message de fin — traduisibles via le sélecteur de langue en haut de la page.
### Compte à rebours
- **Teaser** : avant le démarrage, la bannière affiche le texte du teaser avec un compte à rebours jusqu'au lancement, puis la page se recharge automatiquement.
- **Fin de campagne** : masquez la bannière ou affichez votre message de fin.
- **Mode evergreen** : chaque visiteur voit son propre minuteur (durée en heures, stockée dans son navigateur), borné par la date de fin de campagne. La remise reste active pendant toute la fenêtre de campagne ; le minuteur individuel est un levier d'urgence visuel.
## Fonctionnement de la remise
La remise est appliquée par un processeur de panier exécuté après le calcul des prix produits et avant les promotions Shopware. Sur la fiche produit, les listings, la recherche et les sliders, le prix remisé s'affiche avec l'ancien prix barré via le mécanisme de _list price_ natif — compatible avec tout thème. Rien n'est écrit en base sur vos produits : à la fin de la campagne, tout revient instantanément à la normale.
Le compte à rebours est calé sur l'heure du serveur via un décalage calculé au chargement de la page : modifier l'horloge du navigateur n'a aucun effet.
Si un produit possède déjà un prix barré (list price), celui de la vente flash le remplace pendant la campagne.
## Multilingue
Les textes de campagne (bannière, teaser, message de fin) se traduisent par le sélecteur de langue de la page de détail. Les libellés du compte à rebours (j/h/min/s) sont fournis en français, anglais et allemand et peuvent être ajustés via les snippets Shopware (Paramètres > Boutique > Snippets, clés `dfFlashSale.*`).
## Dépannage
- **L'entrée « Ventes Flash » n'apparaît pas** : vérifiez que le plugin est actif (`bin/console plugin:list`), relancez `assets:install` + `cache:clear`, puis rechargez l'admin avec Ctrl+F5. Sur 6.7, vérifiez la présence du dossier `.vite` (voir Installation).
- **La bannière ne s'affiche pas** : campagne active ? dates courantes dans la fenêtre ? portée de la bannière compatible avec la page visitée ? canal de vente inclus ? Videz aussi le cache HTTP (`bin/console cache:clear`).
- **La remise n'apparaît pas au panier** : vérifiez le ciblage (le produit appartient-il aux catégories/produits sélectionnés ?) et le canal de vente.
## Désinstallation
Lors de la désinstallation, les tables du plugin (`df_flash_sale`, `df_flash_sale_translation`) sont supprimées, sauf si vous cochez « Conserver les données » dans le gestionnaire d'extensions.
---
### DataFirefly Waitlist — Documentation
_Source :_
> Présentation DataFirefly Waitlist ajoute une alerte de retour en stock à votre boutique PrestaShop 8 ou 9. Dès qu'un produit — ou une combinaison précise — passe sous le seuil…
## Présentation
DataFirefly Waitlist ajoute une alerte de retour en stock à votre boutique PrestaShop 8 ou 9. Dès qu'un produit — ou une combinaison précise — passe sous le seuil de stock configuré, un bouton « M'avertir du retour en stock » apparaît automatiquement sur la fiche produit. Le visiteur laisse son email, et reçoit une alerte dès le réapprovisionnement. Chaque commande passée ensuite par un inscrit notifié est attribuée comme conversion dans le dashboard.
## Installation
1. Dans le back-office, allez dans **Modules → Gestionnaire de modules → Installer un module**.
2. Uploadez le fichier `dfwaitlist-x.x.x.zip`.
3. Cliquez sur **Installer**. Le module crée la table `df_dfwaitlist_subscriber`, enregistre ses hooks et ajoute son onglet d'administration.
4. Ouvrez la configuration pour renseigner l'email commerçant et récupérer l'URL du cron.
Aucune dépendance externe. PHP 7.4 minimum, compatible jusqu'à PHP 8.3. Code source non chiffré.
## Configuration
Rendez-vous dans **Modules → DataFirefly Waitlist → Configurer**. Les réglages disponibles :
- **Double opt-in** — quand il est actif, l'inscription envoie d'abord un email de confirmation. Tant que le visiteur n'a pas cliqué, l'inscription reste non confirmée et ne déclenchera aucune alerte. Désactivable si vous préférez l'inscription instantanée.
- **Seuil de stock** — quantité en dessous de laquelle un produit est considéré comme indisponible et fait apparaître le bouton.
- **Seuil d'alerte commerçant** — nombre d'inscrits sur un même produit à partir duquel vous recevez un email de notification. 10 par défaut.
- **Email commerçant** — destinataire de l'alerte ci-dessus.
- **Durée de vie des inscriptions** — les inscriptions jamais notifiées sont purgées automatiquement au-delà de N jours. 90 par défaut.
- **Texte du bouton** — personnalisable par langue.
- **Mention RGPD** — texte affiché sous le formulaire, personnalisable par langue.
- **URL du cron** — sécurisée par token, régénérable d'un clic depuis le back-office.
## Fonctionnement côté client
### Apparition du bouton
Le bouton est injecté via le hook `displayProductActions` et sa visibilité est décidée côté client. Le module interroge l'endpoint `/modules/dfwaitlist/stockcheck` pour connaître l'état de stock réel de la combinaison affichée — ce qui le rend indépendant du comportement de re-rendu AJAX du thème. Résultat : le bouton disparaît si la variante sélectionnée est disponible, et réapparaît sinon, sans rechargement de page.
### Combinaisons (déclinaisons)
L'inscription se fait par couple _(produit, combinaison)_. Le formulaire affiche explicitement la variante concernée, par exemple « Variante : Rouge / Taille L ». Quand le visiteur change de déclinaison avant de valider, la cible bascule automatiquement. L'email d'alerte mentionne la combinaison exacte et pointe vers la fiche avec la variante pré-sélectionnée : aucune confusion possible entre une taille et une autre.
### Confirmation (double opt-in)
Avec le double opt-in actif, l'inscrit reçoit un email contenant un lien de confirmation tokené. L'inscription n'est prise en compte qu'après le clic. Ce mécanisme garantit la qualité de la liste (pas d'emails fantaisistes) et fournit une preuve de consentement explicite.
### Alerte de retour en stock
Au réapprovisionnement, l'inscrit reçoit un email HTML responsive avec le nom du produit, la combinaison concernée et un lien direct vers la fiche. Chaque email contient un lien de désinscription en un clic.
## Détection des retours en stock
Deux canaux complémentaires, à laisser actifs tous les deux :
1. **Hook actionUpdateQuantity** — temps réel. Dès qu'un employé modifie un stock dans le back-office, ou qu'une commande annulée libère du stock, les emails partent immédiatement.
2. **Cron de filet** — sécurisé par token. Il rattrape les mouvements de stock qui ne passent pas par les hooks : imports API, synchronisation ERP, scripts CLI, mises à jour via le Webservice PrestaShop.
### Mise en place du cron
Copiez l'URL affichée dans la configuration du module (elle contient le token de sécurité) et branchez-la sur un appel horaire :
```
0 * * * * curl -s "https://votre-boutique.com/module/dfwaitlist/cron?token=VOTRE_TOKEN" > /dev/null 2>&1
```
Si vous soupçonnez une fuite du token, régénérez-le d'un clic depuis la configuration — l'ancienne URL devient immédiatement inopérante. Pensez à mettre à jour votre crontab après régénération.
## Tracking de conversion
Sur le hook `actionValidateOrder`, le module compare chaque ligne de la commande aux inscriptions en statut « notifié ». La correspondance se fait sur le triplet _(email, id_product, id_product_attribute)_. En cas de match, l'inscription est marquée comme convertie et l'`id_order` est enregistré.
Le tracking étant basé sur l'email et non sur le compte client, il fonctionne aussi bien pour les commandes invité que pour les clients connectés.
## Dashboard admin
- **6 KPI** — inscrits, en attente de confirmation, notifiés, achats, taux de conversion, désinscrits.
- **Liste des produits avec demandes** — triable et paginée. C'est votre liste de priorités de réassort : un produit avec 47 inscrits, ce sont 47 ventes quasi acquises si vous réapprovisionnez vite.
- **Vue détaillée par produit** — chaque inscrit avec son statut individuel.
- **Export CSV** — export complet de la boutique active : email, produit, combinaison, statuts (confirmé, notifié, acheté, désinscrit), dates, IP, id de commande en cas de conversion. Le fichier inclut un BOM UTF-8 pour s'ouvrir directement dans Excel sans casse d'encodage.
## Alerte commerçant
Quand un produit en rupture atteint le seuil d'inscrits configuré, un email automatique vous prévient avec le nombre d'attentes et un lien vers le dashboard. L'email n'est envoyé qu'une fois par produit, pour éviter le bruit. C'est le signal qui transforme votre liste d'attente en outil de pilotage du réassort : vous priorisez sur de la demande mesurée, pas sur de l'intuition.
## Emails
Trois modèles, chacun fourni en FR/EN/ES/DE au format HTML responsive + texte brut :
- **Confirmation** — envoyé uniquement si le double opt-in est actif, avec le lien d'activation.
- **Alerte retour en stock** — produit, combinaison, lien direct vers la fiche, lien de désinscription.
- **Alerte commerçant** — nombre d'inscrits en attente et lien vers le dashboard.
Les modèles sont modifiables dans `modules/dfwaitlist/mails//`.
## RGPD et qualité de liste
- Double opt-in activable, avec preuve de consentement (l'IP est enregistrée à l'inscription).
- Désinscription en un clic dans chaque email d'alerte, via un token unique **distinct** du token de confirmation. L'inscription est marquée désinscrite sans être supprimée, pour conserver la traçabilité, et aucun email futur ne part.
- Purge automatique des inscriptions jamais notifiées au-delà de la durée configurée (90 jours par défaut) — minimisation des données.
- Honeypot anti-bot intégré au formulaire, et limite d'un seul email par produit pour éviter les inscriptions en rafale.
- Aucun appel externe : les données restent dans la base PrestaShop, scopées par boutique. Rien n'est envoyé à DataFirefly ni à un service tiers.
## Multi-boutique et multilingue
La table d'inscriptions porte les colonnes `id_shop` et `id_lang`. Chaque sous-boutique d'un réseau multi-shop dispose donc de sa propre liste d'attente, de ses propres alertes commerçant et de ses propres KPI. Les emails partent dans la langue de l'inscrit au moment de l'inscription.
## Dépannage
### Le bouton n'apparaît pas
- Vérifiez que le produit est bien sous le seuil de stock configuré — au-dessus, le bouton est masqué volontairement.
- Sur un produit à déclinaisons, vérifiez la variante sélectionnée : le bouton ne s'affiche que si _cette_ variante est indisponible.
- Le thème doit implémenter le hook `displayProductActions`. C'est le cas de Classic et Hummingbird ; sur un thème custom exotique, vérifiez sa présence dans le template produit.
- Videz le cache PrestaShop (Paramètres avancés → Performances).
### Les alertes ne partent pas au réappro
- Vérifiez que l'inscription est confirmée : avec le double opt-in, une inscription non confirmée ne reçoit jamais d'alerte.
- Si le stock a été modifié hors back-office (API, ERP, CLI), le hook temps réel ne se déclenche pas — c'est le cron qui prend le relais. Vérifiez qu'il tourne bien et que le token de l'URL est à jour.
- Testez l'envoi d'email PrestaShop en général (Paramètres avancés → E-mail → Test).
### Des conversions ne sont pas comptabilisées
La correspondance exige l'email _et_ le produit _et_ la combinaison. Si le client commande avec une autre adresse email que celle de son inscription, ou achète une déclinaison différente de celle qu'il attendait, la conversion n'est pas attribuée — c'est volontaire, pour éviter les faux positifs qui fausseraient vos KPI.
## Désinstallation
La désinstallation supprime la table `df_dfwaitlist_subscriber` et toutes les clés de configuration préfixées `DFWAITLIST_`. Aucune trace ne subsiste en base. Une confirmation est demandée, puisque les inscriptions et les statistiques de conversion seront définitivement perdues — exportez le CSV avant si vous souhaitez conserver l'historique.
---
### DataFirefly WhatsApp — Documentation
_Source :_
> Bienvenue dans la documentation du module DataFirefly WhatsApp. Ce guide couvre tout ce dont vous avez besoin pour installer, configurer et exploiter au maximum votre bouton WhatsApp flottant multi-agents sur…
Bienvenue dans la documentation du module **DataFirefly WhatsApp**. Ce guide couvre tout ce dont vous avez besoin pour installer, configurer et exploiter au maximum votre bouton WhatsApp flottant multi-agents sur PrestaShop 8 et 9.
## Installation
Le module s'installe comme n'importe quel module PrestaShop, en quelques clics.
### Prérequis
- PrestaShop **8.0.x** ou **9.0.x**
- PHP **8.0** ou supérieur (8.1+ recommandé)
- MySQL 5.6+ ou MariaDB 10.3+
- Au moins un numéro WhatsApp (personnel ou Business)
### Étapes d'installation
1. Téléchargez le fichier `dfwhatsapp-v1.0.0.zip` depuis votre espace client DataFirefly
2. Dans le back-office PrestaShop, allez dans **Modules > Module Manager**
3. Cliquez sur **Téléverser un module** en haut à droite
4. Sélectionnez le fichier ZIP et validez
5. Cliquez sur **Installer** quand le module apparaît
6. Cliquez sur **Configurer** pour ouvrir l'écran de paramétrage
**Astuce :** le module crée automatiquement 6 tables dans votre base de données et ajoute deux entrées de menu dans **Vendre > Catalogue** pour la gestion des agents et le dashboard analytics.
## Configuration générale
La page de configuration du module s'organise en 6 onglets pour vous permettre de tout paramétrer sans vous perdre.
### Onglet Général
- **Activer le module** : interrupteur principal, désactive le bouton sur toute la boutique
- **Mode de sélection d'agent** : round-robin, aléatoire, premier disponible, ou manuel
- **Activer le tracking** : nécessaire pour alimenter le dashboard analytics
- **QR code desktop** : affiche un QR code au lieu d'ouvrir WhatsApp Web sur les postes fixes
### Onglet Apparence
- **Position** : quatre coins possibles (bas-droite, bas-gauche, haut-droite, haut-gauche)
- **Couleur** : par défaut le vert WhatsApp `#25D366`
- **Taille de l'icône** : en pixels (défaut 60)
- **Décalage X / Y** : distance depuis le bord de l'écran
- **Animation** : pulse, bounce, shake, ou aucune
- **Label texte** : label optionnel affiché à côté du bouton
### Onglet Messages
Un message pré-rempli distinct pour chaque type de page (produit, panier, catégorie, CMS, commande, accueil), traduit dans les 4 langues incluses.
### Onglet Planning
- **Mode hors-horaires** : `hide` — le bouton disparaît complètement
- `show_offline` — le bouton reste visible en grisé avec un message d'attente
- `callback` — un formulaire de rappel remplace la conversation directe
**Message hors-horaires** : texte affiché quand tous les agents sont offline
### Onglet RGPD
- **Activer le consentement** : affiche un texte de consentement avant chaque ouverture de WhatsApp
- **Texte du consentement** : personnalisable par langue
### Onglet Exclusions
- **Pages exclues** : liste de contrôleurs (ex. `checkout`, `identity`)
- **Catégories exclues** : IDs de catégories séparés par des virgules
- **Produits exclus** : IDs de produits séparés par des virgules
## Gestion des agents
Le cœur du module : c'est ici que vous ajoutez les personnes qui recevront les messages WhatsApp.
### Ajouter un agent
1. Allez dans **Vendre > Catalogue > Agents WhatsApp**
2. Cliquez sur **Ajouter**
3. Renseignez : **Nom** — nom affiché au client (ex. "Alex")
4. **Téléphone** — au format international sans espaces (ex. `33604525981`)
5. **Département** — libre (Support, Ventes, Technique...)
6. **Avatar** — image optionnelle (png, jpg, svg, webp)
7. **Position** — ordre d'affichage en mode manuel
8. **Rôle** — texte traduit dans les 4 langues (ex. "Support technique")
9. **Message personnalisé** — surcharge optionnelle des messages contextuels
### Configurer les horaires d'un agent
Directement dans le formulaire de l'agent, un tableau hebdomadaire vous permet de définir :
- Plusieurs créneaux par jour (ex. 9h00-12h30 + 14h00-18h30)
- Un jour vide = agent offline ce jour-là
- Un agent sans _aucun_ créneau défini est considéré comme toujours en ligne (mode 24/7)
### Ajouter une exception (jour férié, congé)
1. Dans le formulaire de l'agent, section **Exceptions**
2. Renseignez une date de début et une date de fin
3. Ajoutez un libellé optionnel (ex. "Congés d'été")
**À noter :** vous pouvez aussi ajouter des exceptions _globales_ qui s'appliquent à tous les agents en laissant l'ID agent à 0 dans la base de données.
## Variables contextuelles
Les messages pré-remplis supportent 12 variables qui sont remplacées à la volée selon la page où se trouve le client :
- `{product_name}` — nom du produit (fiche produit)
- `{product_url}` — URL complète du produit
- `{product_price}` — prix formaté avec devise
- `{product_ref}` — référence produit
- `{customer_name}` — nom du client si connecté
- `{cart_id}` — ID du panier
- `{cart_total}` — total du panier formaté
- `{cart_summary}` — liste des articles du panier
- `{order_ref}` — référence de la commande
- `{order_total}` — total de la commande
- `{category_name}` — nom de la catégorie en cours
- `{shop_name}` — nom de la boutique
## Modes de routage d'agents
### Round-robin
Le module alterne entre les agents disponibles à chaque nouvelle ouverture, équilibrant naturellement la charge.
### Aléatoire
Un agent est tiré au sort parmi ceux en ligne. Utile quand l'équité entre les agents n'est pas critique.
### Premier disponible
Le premier agent de la liste (selon la position) qui est actuellement en ligne est sélectionné.
### Manuel
Un popup s'affiche au client avec la liste des agents disponibles (avatar, nom, rôle, statut). Le client choisit lui-même son interlocuteur.
## Analytics et RGPD
### Le dashboard
Accessible via **Vendre > Catalogue > WhatsApp Analytics**, il vous montre :
- Total de clics sur la période
- Nombre de visiteurs uniques (via hachage IP)
- Ratio clics par visiteur
- Répartition par jour, par type de page, par agent
- Top 20 des produits déclencheurs de conversations
### Protection des données
**Conformité RGPD :**
- Consentement explicite affiché avant chaque ouverture de WhatsApp
- IP des visiteurs hachée en **SHA-256** avec un sel propre à votre boutique (`PS_SHOP_DOMAIN` + `_COOKIE_KEY_`)
- Aucune donnée personnelle directe stockée
- Aucun cookie tiers déposé
## QR code sur desktop
Sur les ordinateurs de bureau, plutôt que d'ouvrir WhatsApp Web (qui nécessite un scan systématique du QR code chez le client), vous pouvez activer le mode QR code direct :
- Le module génère un QR code contenant le lien `wa.me` avec le message pré-rempli
- Le client scanne avec son téléphone
- WhatsApp s'ouvre directement sur son mobile avec le message prêt à envoyer
Ce mode maintient la conversation sur le canal préféré du client sans friction supplémentaire.
## Formulaire de rappel
Quand tous vos agents sont hors ligne et que vous avez choisi le mode `callback` :
1. Le client voit un formulaire à la place de la conversation habituelle
2. Il renseigne son nom, son téléphone et un message optionnel
3. La demande est stockée dans la table `ps_dfwhatsapp_callback` avec statut `pending`
4. Vous pouvez consulter les demandes via phpMyAdmin ou construire un rapport personnalisé
## Multilangue
Le module est livré avec 4 langues complètes : **français, anglais, espagnol, allemand**. Tous les textes visibles côté client sont traduits :
- Messages contextuels par page
- Texte de consentement RGPD
- Message de popup de bienvenue
- Labels d'agents (rôle, statut)
- Interface du formulaire de rappel
- Message hors-horaires
Vous pouvez également définir un **rôle** et un **message personnalisé** différents pour chaque langue et chaque agent, directement depuis le formulaire de l'agent en changeant l'onglet de langue.
## Compatibilité
- PrestaShop **8.0.x, 8.1.x, 8.2.x, 9.0.x**
- PHP **8.0 à 8.3**
- Multiboutique **oui** (configurations distinctes par boutique)
- Multilangue **oui** (Polylang non requis)
- Cache **compatible** (Hummingbird, LSCache, Redis)
- Override de classe core : **aucun**
## Dépannage
### Le bouton ne s'affiche pas
1. Vérifiez que le module est activé dans **Général**
2. Vérifiez qu'au moins un agent existe avec le statut _Actif_
3. Vérifiez que la page en cours n'est pas dans la liste des exclusions
4. Videz le cache PrestaShop (**Paramètres avancés > Performances**)
5. Videz le cache navigateur (Ctrl+Shift+R)
### Le clic sur le bouton ne fait rien
1. Ouvrez la console navigateur (F12) et vérifiez qu'il n'y a pas d'erreur JavaScript
2. Vérifiez qu'aucun autre module ne bloque le JS du module
3. Vérifiez que `dfwhatsapp.js` est bien chargé dans le HTML
### Les statistiques ne s'incrémentent pas
1. Vérifiez que le tracking est activé dans **Général**
2. Vérifiez qu'aucun bloqueur de publicité côté client ne filtre l'URL `module/dfwhatsapp/track`
3. Consultez la table `ps_dfwhatsapp_click` pour voir si les événements arrivent
### Erreur SQL "LIMIT 1 LIMIT 1"
Corrigé en version 1.0.1. Mettez à jour votre module vers la dernière version depuis votre espace client DataFirefly.
## Support et mises à jour
- Support par email : [hello@datafirefly.com](mailto:hello@datafirefly.com)
- Mises à jour incluses pendant 12 mois depuis votre espace client
- Compatibilité PS 8 → 9 assurée sans surcoût
## Changelog
### 1.0.0 — 13 mai 2026 — Lancement
- Version initiale publique
- Multi-agents avec quatre modes de routage
- Planning hebdomadaire par agent avec exceptions
- Popup de bienvenue, QR code desktop, formulaire de rappel
- Consentement RGPD natif et analytics avec IP hachée
- Quatre langues : FR, EN, ES, DE
- Compatible PrestaShop 8.0+ et 9.0+
---
### Date de livraison estimée — Guide complet
_Source :_
> Présentation DataFirefly Delivery Date affiche une date de livraison estimée sur la fiche produit, le panier et le checkout de votre boutique PrestaShop 8 ou 9. Le calcul combine quatre…
## Présentation
DataFirefly Delivery Date affiche une date de livraison estimée sur la fiche produit, le panier et le checkout de votre boutique PrestaShop 8 ou 9. Le calcul combine quatre facteurs : le délai de préparation propre à chaque produit, la fourchette de livraison du transporteur (min/max jours ouvrés), les week-ends et jours fériés, et votre heure de cut-off quotidienne. Avant la cut-off, un compte à rebours live indique au client le temps restant pour une expédition le jour même.
## Installation
1. Dans votre back-office PrestaShop, ouvrez **Modules → Gestionnaire de modules → Installer un module**.
2. Téléversez le fichier `dfdeliverydate.zip`.
3. Cliquez sur **Installer**, puis sur **Configurer**.
L'installation crée trois tables (`ps_dfdeliverydate_product`, `ps_dfdeliverydate_carrier`, `ps_dfdeliverydate_holiday`), enregistre les hooks nécessaires, ajoute un onglet d'administration pour les jours fériés et pré-remplit les 8 jours fériés nationaux français en récurrent annuel.
## Configuration générale
Depuis **Modules → Gestionnaire de modules → DataFirefly Delivery Date → Configurer**, le premier panneau regroupe les réglages globaux :
- **Heure et minute de cut-off** — l'heure limite de commande pour une expédition le jour même (par défaut 14h00).
- **Fuseau horaire d'expédition** — chaîne de fuseau PHP, par défaut `Europe/Paris`. Tous les calculs de dates sont effectués dans ce fuseau, indépendamment du fuseau du serveur.
- **Délai de préparation par défaut** — appliqué à tous les produits pour lesquels aucun délai spécifique n'a été saisi.
- **Min/max jours transporteur par défaut** — utilisés quand un transporteur n'a pas de fourchette propre.
- **Exclusion des week-ends** — exclut samedi et dimanche du calcul. Si désactivé, vous pouvez exclure uniquement le dimanche (option suivante) si vous expédiez le samedi.
- **Mode d'affichage** — fourchette (entre min et max), date au plus tard uniquement, ou fourchette accompagnée de la date d'expédition.
- **Zones d'affichage** — trois interrupteurs indépendants : fiche produit, panier, checkout.
- **Compte à rebours live** — active ou désactive le compteur HH:MM:SS jusqu'à la cut-off.
## Délai de préparation par produit
Chaque fiche produit du back-office affiche un panneau **« Delivery date — preparation time »**. Saisissez le nombre de jours ouvrés nécessaires avant que ce produit puisse être expédié :
- `0` — produit en stock, expédiable immédiatement (éligible à l'expédition le jour même avant la cut-off) ;
- `2` — produit nécessitant deux jours ouvrés de préparation ;
- `14` — produit fabriqué ou personnalisé à la commande.
La valeur est enregistrée lors de la sauvegarde du produit. Dans le panier, c'est le produit au délai de préparation le plus long qui détermine la date d'expédition de la commande complète.
## Configuration des transporteurs
Le deuxième panneau de la page de configuration liste tous les transporteurs actifs. Pour chacun, définissez le **minimum** et le **maximum** de jours ouvrés de livraison. Exemples courants : Chronopost 1–2, Colissimo 3–5, Mondial Relay 4–7. Sur la fiche produit et le panier, la fourchette du transporteur par défaut de la boutique est utilisée ; au checkout, le module bascule sur le transporteur réellement sélectionné par le client.
Lorsque PrestaShop versionne un transporteur (nouvel ID créé automatiquement après modification), le module recopie la configuration vers le nouvel ID — aucun paramétrage n'est perdu.
## Jours fériés
Les jours fériés se gèrent depuis **Améliorer → Livraison → Jours fériés (Delivery Date)**. Chaque entrée comporte une date, un nom, un indicateur _récurrent_ et un statut actif/inactif :
- **Récurrent** — seul le mois et le jour comptent ; le férié est projeté automatiquement sur l'année courante et l'année suivante (ex. Noël chaque 25 décembre).
- **Ponctuel** — une date précise unique, idéale pour un pont ou une fermeture exceptionnelle.
Les 8 fériés nationaux français sont pré-installés en récurrent : 1er janvier, 1er mai, 8 mai, 14 juillet, 15 août, Toussaint, 11 novembre, 25 décembre. Vous pouvez les désactiver individuellement et ajouter vos fériés régionaux (Alsace-Moselle, DOM-TOM) ou étrangers.
## Algorithme de calcul
Le calcul suit ces étapes, toutes exprimées en jours ouvrés dans le fuseau configuré :
1. La date d'expédition démarre à aujourd'hui. Si l'heure actuelle dépasse la cut-off, elle est décalée à demain.
2. Le délai de préparation du produit (ou le maximum du panier) est ajouté en jours ouvrés, en sautant week-ends et fériés.
3. Si la date d'expédition obtenue tombe un jour non ouvré, elle est poussée au jour ouvré suivant.
4. La fourchette de livraison est calculée en ajoutant le min et le max du transporteur, toujours en jours ouvrés.
La mention « expédition aujourd'hui » et le compte à rebours n'apparaissent que si trois conditions sont réunies : l'heure actuelle est avant la cut-off, aujourd'hui est un jour ouvré, et le délai de préparation vaut zéro.
## Personnalisation des templates
Les trois widgets frontend sont rendus par des templates Smarty surchargeables. Copiez le ou les fichiers concernés depuis `modules/dfdeliverydate/views/templates/hook/` vers `themes/votre-theme/modules/dfdeliverydate/views/templates/hook/` :
- `product-delivery-date.tpl` — fiche produit ;
- `cart-delivery-date.tpl` — panier ;
- `checkout-delivery-date.tpl` — checkout et confirmation de commande.
Chaque template reçoit un tableau `$dfdd` contenant notamment `ships_today`, `min_date_label`, `max_date_label`, `ship_date_label`, `cutoff_ts` et `display_mode`. Le CSS se trouve dans `views/css/front.css` (classes préfixées `dfdd-`).
## Dépannage
- **Le widget n'apparaît pas sur la fiche produit** — vérifiez que la zone est activée dans la configuration et que votre thème implémente bien le hook `displayProductAdditionalInfo` (c'est le cas du thème Classic et de la plupart des thèmes du marché).
- **Le compte à rebours affiche 00:00:00** — la cut-off du jour est dépassée ; le compteur ne s'affiche que lorsque l'expédition le jour même est encore possible.
- **Les dates semblent décalées d'un jour** — contrôlez le fuseau horaire configuré dans le module : le calcul utilise ce fuseau et non celui du serveur ni celui du navigateur.
- **Un férié n'est pas pris en compte** — vérifiez qu'il est actif, et pour un férié ponctuel que son année correspond bien à l'année en cours.
## Désinstallation
La désinstallation supprime les trois tables du module, toutes les entrées de configuration (préfixe `DFDD_`), l'onglet d'administration des jours fériés et les enregistrements de hooks. Les délais de préparation saisis produit par produit sont donc définitivement perdus — exportez-les au préalable si nécessaire.
---
### Décoration Saisonnière Planifiée — Documentation
_Source :_
> La Décoration Saisonnière Planifiée (module dfthemescheduler) habille automatiquement votre boutique PrestaShop pour chaque temps fort commercial. Vous créez des campagnes datées — Noël, Black Friday, soldes, Saint-Valentin — combinant bandeau,…
La **Décoration Saisonnière Planifiée** (module `dfthemescheduler`) habille automatiquement votre boutique PrestaShop pour chaque temps fort commercial. Vous créez des campagnes datées — Noël, Black Friday, soldes, Saint-Valentin — combinant bandeau, bannière, palette de couleurs, effets visuels et bloc d'accueil. Chaque campagne s'active et se retire seule aux dates programmées, sans aucune tâche planifiée.
## Présentation
Le module repose sur une logique simple : une **campagne** est un ensemble d'éléments visuels associé à une plage de dates. Quand la date courante tombe dans cette plage, la campagne devient « live » et son habillage s'applique au front-office. En dehors, la boutique retrouve son apparence normale sans laisser de trace.
Une seule campagne est affichée à la fois. Si plusieurs campagnes se chevauchent, celle qui possède la **priorité** la plus élevée gagne. Vous pouvez ainsi superposer une longue campagne de Noël et un pic Black Friday plus prioritaire au milieu.
Chaque campagne peut combiner, au choix, les éléments suivants : un bandeau haut de page avec message et compte à rebours, une bannière image par langue, une palette de sept couleurs, un effet d'ambiance (neige, confettis, cœurs, feuilles, étoiles, feux d'artifice), un bloc HTML sur la page d'accueil et du CSS personnalisé. Tous ces éléments sont optionnels.
## Installation
Installez le module comme n'importe quel module PrestaShop :
1. Dans le back-office, allez dans **Modules > Module Manager**.
2. Cliquez sur **Envoyer un module** et sélectionnez le fichier `dfthemescheduler.zip`.
3. Une fois l'installation terminée, cliquez sur **Configurer** pour ouvrir le planificateur de campagnes.
Le module crée ses tables, enregistre ses hooks d'affichage et ajoute un onglet d'administration accessible via le bouton **Configurer**. Aucune dépendance externe n'est requise : ni Composer, ni jQuery, ni service tiers.
Si vous êtes déjà en version 1.0.0, remplacez simplement le dossier du module par la 1.1.0 : le script de mise à jour ajoute automatiquement la colonne de position de bannière et enregistre les nouveaux hooks. Aucune réinstallation n'est nécessaire.
## Créer une campagne
Depuis l'écran de configuration, cliquez sur **Ajouter une campagne**. Le formulaire est organisé du plus important au plus optionnel.
### Informations générales
- **Nom de la campagne** : libellé interne, par exemple « Noël 2026 » ou « Black Friday ». Il n'est jamais affiché aux visiteurs.
- **Activé** : interrupteur maître. Une campagne désactivée n'est jamais affichée, même à l'intérieur de sa plage de dates.
- **Priorité** : nombre entier. En cas de chevauchement, la campagne à la priorité la plus élevée l'emporte. Laissez 0 si vous n'avez qu'une campagne à la fois.
### Dates
Les champs **Date de début** et **Date de fin** utilisent un sélecteur de date et d'heure natif, précis à la seconde. Les dates sont interprétées à l'heure du serveur de votre boutique.
Si votre navigateur affiche un champ texte au lieu du sélecteur, le format attendu est `AAAA-MM-JJ HH:MM:SS`, par exemple `2026-11-27 00:00:00`.
## Récurrence annuelle
Cochez **Répéter chaque année** pour qu'une campagne revienne automatiquement aux mêmes dates, année après année. Seuls le mois, le jour et l'heure sont comparés : l'année est ignorée.
Le module gère nativement les campagnes **à cheval sur le Nouvel An**. Une campagne du 20 décembre au 6 janvier fonctionne parfaitement et se réactive chaque hiver, sans avoir à la dédoubler.
Pour une campagne récurrente, la validation « date de fin après date de début » est volontairement désactivée, puisque la fin peut se situer sur l'année civile suivante.
## Bandeau haut de page
Le champ **Message du bandeau** (multilingue) affiche une barre en haut de toutes les pages. Il accepte du HTML basique : liens, gras. Laissez-le vide pour masquer la barre.
Activez **Afficher le compte à rebours** pour ajouter un décompte en temps réel jusqu'à la date de fin de la campagne, au format « 12j 04:31:07 ». Pour une campagne récurrente, le décompte vise automatiquement la prochaine occurrence de la date de fin.
Les couleurs du bandeau (fond et texte) se règlent dans la section Palette.
## Bannière image
Vous pouvez charger une **bannière différente par langue**, avec un lien cliquable et un texte alternatif. Les formats acceptés sont jpg, png, gif et webp. Une largeur généreuse est recommandée (par exemple 1920 × 300).
Le champ **Position de la bannière** détermine la zone du thème où l'image s'affiche :
- **Bandeau haut — displayBanner** : position par défaut, en tête de page.
- **Sous l'en-tête, pleine largeur — displayNavFullWidth** : juste sous le menu principal.
- **Au-dessus du contenu — displayWrapperTop** : au-dessus du corps de la page.
Si votre bannière ne s'affiche pas, c'est généralement que votre thème n'accroche pas le hook choisi. Essayez simplement une autre position dans la liste.
## Palette de couleurs
La campagne expose sept couleurs : primaire, secondaire, liens, fond de l'en-tête, fond du pied de page, fond du bandeau et texte du bandeau.
Ces sept valeurs sont **toujours exposées** en variables CSS (`--dfts-primary`, `--dfts-secondary`, etc.) que votre thème ou votre CSS personnalisé peuvent réutiliser.
Activez **Appliquer la palette au thème** pour que le module applique lui-même ces couleurs aux boutons, liens, en-tête et pied de page. Laissez l'option désactivée si vous préférez piloter l'habillage uniquement via les variables CSS et votre propre feuille de style.
## Effets visuels
Le champ **Effet visuel** propose six animations en JavaScript pur, dessinées sur un canvas plein écran : neige, confettis, cœurs, feuilles d'automne, étoiles scintillantes et feux d'artifice. Choisissez **Aucun** pour désactiver l'effet.
L'**Intensité** (faible, moyenne, forte) règle la densité des particules. Le nombre de particules est plafonné pour préserver les performances.
Les effets se chargent uniquement quand une campagne est active. Ils se désactivent automatiquement pour les visiteurs ayant activé la préférence « réduction de mouvement » de leur système, et se mettent en pause lorsque l'onglet n'est pas visible.
## Bloc d'accueil et CSS personnalisé
Le champ **Bloc page d'accueil** (multilingue, éditeur visuel) affiche un contenu HTML libre sur la page d'accueil pendant toute la durée de la campagne — idéal pour une offre, un bandeau promotionnel enrichi ou un message saisonnier.
Le champ **CSS personnalisé** permet d'aller plus loin. Le CSS est assaini avant injection (les tentatives de sortie du conteneur de style sont neutralisées) et n'est chargé que lorsque la campagne est active. Vous pouvez y utiliser les variables `--dfts-*`.
## Prévisualisation sécurisée
Chaque campagne dispose d'un lien de prévisualisation protégé par un jeton unique de 32 caractères. Depuis la liste des campagnes, cliquez sur le bouton **Preview** : la boutique s'ouvre avec l'habillage de la campagne appliqué, exactement comme le verront vos visiteurs le jour J.
L'aperçu persiste pendant votre navigation : vous pouvez parcourir toutes les pages de la boutique. Une barre fixe « Aperçu : {nom} — Quitter » s'affiche en bas à gauche ; cliquez sur **Quitter** pour revenir à l'affichage normal.
La prévisualisation est totalement invisible pour vos visiteurs : elle ne s'active qu'avec le lien secret contenant le bon jeton. Vous pouvez ainsi vérifier votre habillage de Noël en plein mois d'août, ou partager le lien à un client pour validation, sans rien changer pour le public.
## Planificateur annuel
En tête de la liste des campagnes, le back-office affiche un tableau de bord synthétique : nombre de campagnes, campagnes actives, campagne actuellement « live » et prochaine campagne à démarrer avec le nombre de jours restants.
En dessous, une **timeline sur douze mois** représente chaque campagne par une barre colorée positionnée selon ses dates. Un marqueur vertical indique le jour courant, les campagnes récurrentes à cheval sur le Nouvel An sont affichées en deux segments, et chaque barre est cliquable pour ouvrir directement l'édition de la campagne.
## Dupliquer, exporter, importer
Depuis la liste, l'action **Dupliquer** crée une copie de la campagne avec un nouveau jeton de prévisualisation, désactivée par défaut, dont les images de bannière sont physiquement recopiées — supprimer l'une n'affecte jamais l'autre. Les associations de boutique sont conservées.
Le bouton **Export JSON** (dans la barre d'outils) télécharge l'ensemble de vos campagnes dans un fichier. Le formulaire **Import JSON** du tableau de bord permet de réinjecter ce fichier sur une autre boutique. Les campagnes importées arrivent désactivées par défaut ; les images de bannière ne sont pas incluses dans l'export.
## Multiboutique et multilingue
En contexte multiboutique, chaque campagne est associée aux boutiques de votre choix via la section **Association boutique** du formulaire. Une campagne ne s'affiche que sur les boutiques auxquelles elle est rattachée.
Le message du bandeau, la bannière (image, lien, texte alternatif) et le bloc d'accueil sont **traduisibles par langue**. Renseignez chaque langue depuis les onglets de langue du formulaire.
## Intégration pour développeurs de thème
Quand une campagne est active, le module ajoute des classes sur la balise `body` : `dfts-active`, `dfts-campaign-{id}`, `dfts-effect-{effet}`, et `dfts-preview` en mode aperçu. Vous pouvez ainsi cibler finement votre CSS.
Un évènement JavaScript `dfts:ready` est également émis sur le `document` une fois le script initialisé, avec la configuration de la campagne dans son détail. Combiné aux variables CSS `--dfts-*`, cela permet des intégrations sur mesure sans toucher au module.
## Performances
Le module est léger par conception. La résolution de la campagne active tient en une seule requête SQL mémoïsée par affichage. Le CSS et le JavaScript du front ne sont chargés que lorsqu'une campagne est réellement active. Aucun override de classe n'est utilisé : uniquement des hooks natifs PrestaShop.
## Dépannage
### La bannière ne s'affiche pas
Votre thème n'accroche probablement pas le hook de position choisi. Changez la **Position de la bannière** pour une autre valeur de la liste.
### Les couleurs ne s'appliquent pas
Vérifiez que l'option **Appliquer la palette au thème** est activée. Si elle l'est mais que certains éléments restent inchangés, votre thème utilise des sélecteurs spécifiques : ajoutez quelques règles dans le champ CSS personnalisé en vous appuyant sur les variables `--dfts-*`.
### L'effet ne s'anime pas
Les animations sont volontairement désactivées pour les visiteurs ayant activé la réduction de mouvement dans leur système d'exploitation, et se mettent en pause quand l'onglet est en arrière-plan. Vérifiez aussi qu'un effet autre qu'« Aucun » est sélectionné.
### Deux campagnes se chevauchent
C'est le comportement attendu : une seule campagne s'affiche, celle qui a la priorité la plus élevée. Ajustez les priorités pour choisir laquelle prime.
### La campagne ne se déclenche pas à l'heure prévue
Les dates sont interprétées à l'heure du serveur, qui peut différer de votre heure locale. Vérifiez le fuseau horaire de votre boutique dans les paramètres PrestaShop.
---
### Demande de Devis B2B — Guide complet
_Source :_
> Présentation Le module Demande de Devis B2B (dfb2bquote) ajoute un véritable circuit de vente sur devis à votre boutique PrestaShop. Un bouton « Devis » remplace ou complète l'ajout au…
## Présentation
Le module **Demande de Devis B2B** (`dfb2bquote`) ajoute un véritable circuit de vente sur devis à votre boutique PrestaShop. Un bouton **« Devis »** remplace ou complète l'ajout au panier : vos clients professionnels composent leur demande dans un **panier de devis dédié**, l'envoient, et vous reprenez la main au back-office pour **négocier les prix ligne par ligne**, appliquer une remise, fixer une validité et générer un **PDF** au style de votre boutique. Une fois le devis accepté par le client, un clic le **convertit en commande réelle** avec les prix négociés figés.
Pensé pour le B2B et la vente sur mesure : grossistes, fournitures professionnelles, gros volumes, produits configurables. Le parcours d'achat classique de vos clients particuliers reste intact : le bouton Devis peut remplacer l'achat, ou simplement s'ajouter à côté.
## Compatibilité
- PrestaShop 8.0 à 9.x
- PHP 7.4 à 8.3
- Mono-boutique et multi-boutique
- Multilingue (statuts traduits, emails fournis en FR et EN)
- Thème Classic et thèmes personnalisés (le bouton s'injecte même si le thème n'appelle pas le hook)
- Aucune dépendance (ni Composer ni framework)
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** puis sélectionnez le fichier `dfb2bquote.zip`.
3. Une fois installé, cliquez sur **Configurer**.
À l'installation, le module crée ses tables (devis, lignes, statuts, panier de devis, historique), initialise les **sept statuts** par défaut, enregistre ses hooks (fiche produit, en-tête, espace client, authentification) et ajoute l'onglet **Devis** sous _Commandes_ dans le menu d'administration. Un lien **Mes devis** apparaît dans l'espace client.
## Configuration
### Bouton et affichage
- **Activer le module** : active ou désactive l'ensemble du circuit devis côté front.
- **Mode du bouton** : _Remplacement_ (le bouton Devis prend la place de l'ajout au panier, pour une boutique 100 % sur devis) ou _Complément_ (le bouton s'ajoute à côté de l'achat classique, pour servir à la fois B2C et B2B).
- **Libellé du bouton** : texte affiché sur le bouton (« Devis », « Demander un prix »…).
- **Masquer les prix** : masque les prix catalogue côté front, pour une logique entièrement sur devis.
- **Groupes clients** : laissez vide pour afficher le bouton à tout le monde, ou sélectionnez les groupes (par exemple vos groupes professionnels) pour le réserver au B2B.
### Demande et règles
- **Autoriser les invités** : permet à un visiteur non connecté de soumettre une demande en renseignant ses coordonnées (nom, email, société, téléphone). Désactivez pour n'accepter que les clients connectés.
- **Montant minimum** : seuil HT requis pour pouvoir soumettre une demande.
- **Validité (jours)** : durée de validité appliquée par défaut aux devis.
- **Afficher le lien « Mes devis »** : affiche l'indicateur de devis et le lien d'accès dans l'en-tête.
### Conversion et documents
- **Email administrateur** : adresse qui reçoit la notification à chaque nouvelle demande.
- **État de commande à la conversion** : statut appliqué à la commande générée lors de la conversion d'un devis accepté.
- **Conditions (CGV)** : texte affiché en bas du PDF de devis.
## Utilisation — côté client
### Demander un devis
Sur la fiche produit et les listings, le client clique sur le bouton **Devis**. Le produit (et sa déclinaison) est ajouté à son **panier de devis**, indépendant du panier d'achat. Un indicateur « Mon devis » se met à jour dans l'en-tête.
### Le panier de devis
Sur la page du panier de devis, le client ajuste les quantités, retire des lignes, ajoute un message, puis soumet sa demande. S'il n'est pas connecté et que le mode invité est autorisé, il renseigne ses coordonnées. À la soumission, le devis est créé au statut **Nouvelle demande** et une notification est envoyée à votre équipe.
Le panier de devis est rattaché à la session du visiteur et **persiste entre les pages**. À la connexion, un panier constitué en tant qu'invité est automatiquement **transféré** au compte client.
### L'espace « Mes devis »
Depuis son compte, le client retrouve la liste de ses devis avec leur statut. Sur le détail d'un devis, il consulte les lignes et les totaux, **télécharge le PDF**, et lorsque le devis lui a été envoyé, peut l'**accepter** ou le **refuser**. Un invité accède à son devis via un lien sécurisé par clé unique.
## Utilisation — back-office
### Liste des devis
L'onglet **Devis** (sous _Commandes_) liste toutes les demandes avec leur référence, le client, un badge de statut coloré, le total HT et la date. Un clic ouvre l'écran de gestion.
### Négocier le devis
Sur l'écran de détail, pour chaque ligne, le **prix catalogue** est rappelé et vous saisissez le **prix négocié HT**. Vous pouvez aussi :
- appliquer une **remise globale** en montant HT ou en pourcentage ;
- ajouter des **frais de port indicatifs** ;
- saisir un **message destiné au client** ;
- fixer ou ajuster la **date de validité**.
### Statut et notification
Vous changez le **statut** du devis et, en cochant **Notifier le client**, déclenchez l'envoi d'un email. Passez le devis à **Devis envoyé** pour que le client puisse l'accepter depuis son espace. Tout l'historique des statuts est conservé, horodaté.
### Convertir en commande
Lorsque le devis est **Accepté**, le bouton **Convertir en commande** apparaît. La conversion crée un panier, applique chaque prix négocié via un `SpecificPrice` rattaché à ce panier, ajoute l'éventuelle remise globale via une règle panier (`CartRule`), puis crée la commande via `validateOrder` avec l'état configuré.
Les prix spécifiques et règles temporaires sont **nettoyés automatiquement** après la création de la commande : votre catalogue n'est jamais modifié, et la commande porte exactement les montants négociés.
## Les statuts de devis
- **Nouvelle demande** : devis reçu, à traiter.
- **En cours** : en cours de préparation côté boutique.
- **Devis envoyé** : transmis au client, qui peut l'accepter ou le refuser.
- **Accepté** : validé par le client, prêt à convertir en commande.
- **Refusé** : décliné par le client.
- **Expiré** : date de validité dépassée.
- **Converti en commande** : transformé en commande réelle.
## FAQ et dépannage
### Le bouton « Devis » ne s'affiche pas
Vérifiez que le module est activé, que le visiteur appartient à un groupe autorisé (si vous avez restreint l'affichage), et videz le cache de PrestaShop. Le module sait injecter le bouton même si votre thème n'appelle pas le hook de la fiche produit ; en cas de thème très personnalisé, vérifiez la présence du conteneur d'achat.
### Page blanche ou erreur « JSON invalide » à l'ajout
Videz le cache (Paramètres avancés > Performances) et, pendant vos tests, désactivez la combinaison/compression des fichiers (CCC). Les réponses AJAX du module sont du JSON strict, renvoyé directement pour rester compatible PrestaShop 9.
### Les prix ne sont pas masqués
Activez l'option **Masquer les prix**. Selon votre thème, certains emplacements de prix très spécifiques peuvent nécessiter un ajustement ; le module masque les emplacements standard de PrestaShop.
### Le client ne peut pas accepter son devis
L'acceptation et le refus ne sont possibles que lorsque le devis est au statut **Devis envoyé**. Passez le devis à ce statut depuis le back-office.
### Les emails ne sont pas reçus
Vérifiez l'adresse renseignée dans **Email administrateur** et la configuration email de PrestaShop (Paramètres avancés > E-mail). Les modèles sont fournis en français et en anglais et restent personnalisables.
### Est-ce compatible PrestaShop 9 et multiboutique ?
Oui. Le module est compatible PrestaShop 8 et 9, en mono-boutique comme en multi-boutique. Les devis sont rattachés à la boutique et à la langue du client.
---
### Demande de Devis B2B (Devis Express) — Guide complet
_Source :_
> Présentation Le module Devis Express Multi-Produits B2B (dfexpressquote) ajoute un bouton « Demander un devis » en pied de page panier. En un clic, votre client professionnel transforme son panier…
## Présentation
Le module **Devis Express Multi-Produits B2B** (`dfexpressquote`) ajoute un bouton **« Demander un devis »** en pied de page panier. En un clic, votre client professionnel transforme son panier en un **devis PDF** propre, reçu par email, sans avoir à créer de compte. Une copie est envoyée à votre boutique et chaque devis est suivi dans le back-office avec ses statuts.
Le PDF est généré avec TCPDF, déjà embarqué dans PrestaShop : aucune bibliothèque externe ni dépendance Composer. Le document n'est jamais stocké sur le serveur, il est régénéré à la demande depuis un instantané du panier enregistré en base.
## Compatibilité
- PrestaShop 8.0 à 9.x
- PHP 7.4 à 8.3
- Mono-boutique et multi-boutique
- 5 langues : FR, EN, ES, DE, IT
- Thème Classic et thèmes personnalisés (modale en JavaScript natif, indépendante du thème)
- Aucune dépendance (ni Composer ni framework)
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** puis sélectionnez le fichier `dfexpressquote.zip`.
3. Une fois installé, cliquez sur **Configurer**.
À l'installation, le module crée sa table de devis, enregistre ses hooks (`actionFrontControllerSetMedia`, `displayShoppingCartFooter`, `displayExpressCheckout`), ajoute un onglet **Devis Express** sous le menu Commandes et initialise ses réglages par défaut.
## Configuration
### Affichage et bouton
- **Libellé du bouton** : texte affiché en pied de panier, personnalisable.
- **Demander les coordonnées** : active le mode formulaire de contact. Désactivé, le module bascule en mode 1 clic instantané (le devis PDF est généré sans aucun formulaire).
### Devis
- **Préfixe de référence** : préfixe des numéros de devis (par défaut `DEV`), suivi de la date et d'un compteur.
- **Durée de validité** : nombre de jours de validité du devis, utilisé pour calculer la date d'échéance.
- **Afficher la TVA** : affiche les colonnes et totaux de TVA sur le PDF.
- **Afficher l'adresse** : ajoute le bloc adresse du destinataire sur le PDF.
- **Mentions légales TVA** et **Conditions** : textes libres ajoutés en pied de devis.
### Emails
- **Email au client** : envoie automatiquement le devis PDF en pièce jointe au client.
- **Email à la boutique** : envoie une notification à votre équipe.
- **Adresse email de notification** : destinataire interne (par défaut l'email de la boutique).
## Fonctionnement
### Deux modes de demande
En **mode formulaire**, un clic ouvre une modale légère où le client renseigne sa société, son nom, son email et, en option, son téléphone, son numéro de TVA intracommunautaire et un message. En **mode 1 clic instantané**, le devis PDF est produit immédiatement, sans formulaire. Aucune création de compte n'est requise dans les deux cas.
### Le devis PDF
Le PDF reprend l'identité de votre boutique : logo, coordonnées, référence unique, date d'émission et date de validité, bloc destinataire, tableau des produits (référence, désignation, quantité, prix unitaire HT, TVA, total HT) et totaux HT, TVA et TTC, suivis de vos mentions et conditions. Il n'est jamais stocké sur disque : il est régénéré à la demande depuis l'instantané du panier enregistré en base, ce qui évite l'accumulation de fichiers et garantit un document toujours cohérent.
### Emails automatiques
Selon votre configuration, le client reçoit son devis en pièce jointe et votre boutique est notifiée à l'adresse de votre choix. Les modèles d'emails sont fournis en français et en anglais.
### Suivi dans le back-office
L'onglet **Devis Express** liste tous les devis avec leur référence, le destinataire, le montant TTC, le statut et la date. Vous ouvrez un devis pour en voir le détail, faites évoluer son statut (nouveau, envoyé, accepté, refusé, converti) et régénérez ou téléchargez le PDF à tout moment.
### Sécurité
Le téléchargement du PDF est protégé par un jeton déterministe dérivé de la clé de votre boutique. Chaque demande est protégée par un pot de miel anti-robot et un jeton lié au panier en cours, et n'agit que sur le panier de la session courante.
## FAQ et dépannage
### Le client doit-il créer un compte ?
Non. La demande de devis fonctionne en mode invité. Le mode 1 clic instantané génère même le PDF sans aucun formulaire.
### Faut-il installer une bibliothèque PDF ?
Non. Le devis est généré avec TCPDF, déjà embarqué dans PrestaShop 8 et 9. Aucune dépendance Composer.
### Le bouton n'apparaît pas sur la page panier
Videz le cache de PrestaShop (Paramètres avancés > Performances) et, pendant vos tests, désactivez la combinaison/compression (CCC). Le bouton ne s'affiche que lorsque le panier contient au moins un article. Si votre thème ne déclenche pas le hook `displayShoppingCartFooter`, le bouton est inséré via le chargement des ressources sur le front.
### Les fichiers PDF s'accumulent-ils sur le serveur ?
Non. Le devis n'est pas stocké sur disque : il est régénéré à la demande à partir de l'instantané du panier en base.
### Est-ce compatible PrestaShop 9 ?
Oui. Le module est compatible PrestaShop 8 et 9, en multi-boutique et multilingue.
---
### Détecteur de Topic Clusters — Documentation
_Source :_
> Cette documentation décrit l'installation, la configuration et l'utilisation du module Détecteur de Topic Clusters sur PrestaShop 8 et 9. Le module détecte automatiquement les regroupements thématiques de votre catalogue par…
Cette documentation décrit l'installation, la configuration et l'utilisation du module **Détecteur de Topic Clusters** sur PrestaShop 8 et 9. Le module détecte automatiquement les regroupements thématiques de votre catalogue par clustering sémantique et suggère les pillar pages manquantes avec un brouillon SEO complet pour chaque opportunité.
## Présentation
Le Détecteur de Topic Clusters analyse votre catalogue produit pour faire émerger les **topic clusters réellement présents** dans votre offre, puis détecte les **pillar pages manquantes** : ces sujets transversaux fortement couverts par vos produits mais sans page-mère structurante (CMS ou catégorie).
Pour chaque gap détecté, le module génère un brouillon complet :
- Titre H1 SEO-optimisé
- Slug URL-safe
- Meta description
- Plan H2 markdown complet
- Liste des mots-clés cibles
- Score de priorité (taille × cohésion)
**À retenir.** Le module ne crée pas de pages directement dans PrestaShop. Il vous donne un brouillon à copier-coller dans une nouvelle page CMS ou landing catégorie, en gardant la décision éditoriale entre vos mains.
## Installation
### Prérequis
- PrestaShop **8.0+** ou **9.x**
- PHP **8.0 minimum** (PHP 8.1 ou 8.2 recommandé)
- `memory_limit` de 512 Mo minimum (1024 Mo recommandé pour les gros catalogues)
- Optionnel : clé API OpenAI ou Mistral pour le mode embeddings
### Procédure d'installation
1. Téléchargez le fichier `dftopicclusters.zip` depuis votre espace client DataFirefly.
2. Dans le back-office PrestaShop, allez dans **Modules → Module Manager** puis cliquez sur **Téléverser un module**.
3. Sélectionnez le ZIP et confirmez. Le module s'installe automatiquement.
4. Une fois installé, cliquez sur **Configurer**.
À l'installation, le module crée automatiquement :
- Les 5 tables SQL préfixées `df_topicclusters_`
- L'onglet parent **DataFirefly** sous le menu Améliorer (s'il n'existe pas déjà)
- L'onglet enfant **Topic Clusters** sous ce parent
- Les 19 clés de configuration par défaut
### Premier accès
Une fois installé, le module est accessible via **Améliorer → DataFirefly → Topic Clusters**. Le tableau de bord vous présente le formulaire de lancement d'une nouvelle analyse et l'historique des runs précédents (vide à la première ouverture).
## Configuration
Cliquez sur le bouton **Paramètres** en haut à droite du tableau de bord pour accéder à la page de configuration. Les réglages sont groupés en cinq sections.
### Général
CléDéfautDescription`DFTC_MODE``tfidf`Mode de clustering : `tfidf` (local), `openai` ou `mistral``DFTC_K_AUTO`activéSi activé, calcule automatiquement k = ceil(√(N/2)) borné à [5, 30]`DFTC_K_MANUAL`12Valeur de k utilisée si `DFTC_K_AUTO` est désactivé`DFTC_MAX_ITER`60Nombre maximum d'itérations du k-means`DFTC_MIN_CLUSTER_SIZE`3Taille minimale d'un cluster ; en-dessous, écarté
### Extraction de texte
Permet de choisir quels champs du produit sont injectés dans l'analyse. La pondération par champ est fixe (nom × 3, meta × 2, description courte × 2, catégories × 2, tags × 2, description longue × 1, features × 1).
- `DFTC_INCLUDE_DESCRIPTION` — Inclure la description longue (recommandé : activé)
- `DFTC_INCLUDE_CATEGORIES` — Inclure les noms de catégories (recommandé : activé)
- `DFTC_INCLUDE_TAGS` — Inclure les tags PrestaShop (recommandé : activé)
- `DFTC_INCLUDE_FEATURES` — Inclure les caractéristiques produit (recommandé : désactivé sauf si vous avez des features très descriptives)
### Réglages TF-IDF
CléDéfautDescription`DFTC_MIN_DOC_FREQ`2Terme ignoré s'il apparaît dans moins de N produits`DFTC_MAX_DOC_FREQ_RATIO`0.50Terme ignoré s'il apparaît dans plus de X % du catalogue`DFTC_NGRAM_MAX`21 = unigrammes, 2 = unigrammes + bigrammes`DFTC_TOP_TERMS_COUNT`8Nombre de termes affichés par cluster
### APIs d'embeddings
CléDescription`DFTC_OPENAI_API_KEY`Bearer token OpenAI (sk-...)`DFTC_OPENAI_MODEL`Modèle (défaut `text-embedding-3-small`)`DFTC_MISTRAL_API_KEY`Clé API Mistral`DFTC_MISTRAL_MODEL`Modèle (défaut `mistral-embed`)`DFTC_BATCH_SIZE`Nombre de produits par appel API (défaut 32)
### Détection des pillar pages
- `DFTC_PILLAR_MATCH_THRESHOLD` — Seuil de match (défaut 0.45). En-dessous, le cluster est marqué _pillar gap_. Augmentez le seuil pour être plus strict, diminuez-le pour être plus tolérant.
## Les trois modes en détail
### Mode TF-IDF (recommandé pour démarrer)
Le TF-IDF (Term Frequency × Inverse Document Frequency) est une méthode statistique classique en NLP. Le module construit un vocabulaire à partir de tous les textes produits, filtre les termes trop rares ou trop fréquents, puis représente chaque produit comme un vecteur creux dans cet espace.
**Avantages :** 100 % local, instantané, aucun coût, aucune dépendance externe. Excellent pour les catalogues lexicalement homogènes (un domaine, un vocabulaire cohérent).
**Limites :** ne comprend pas les synonymes (deux produits utilisant des termes différents pour le même concept seront mal regroupés).
### Mode OpenAI embeddings
Utilise l'API OpenAI `text-embedding-3-small` par défaut. Chaque produit est représenté par un vecteur dense de 1536 dimensions qui capture sa sémantique.
**Avantages :** comprend les synonymes, les variantes lexicales et le contexte. Excellent pour les catalogues diversifiés ou aux descriptions narratives.
**Coût indicatif :** environ 0,02 USD par million de tokens, soit moins de 0,10 USD pour un catalogue de 1 000 produits.
**Astuce.** Le cache d'embeddings est automatique : si vous relancez un run sur le même catalogue sans modifier les textes, les vecteurs sont récupérés depuis la table `df_topicclusters_embedding_cache` sans nouvel appel API.
### Mode Mistral embeddings
Utilise l'API Mistral `mistral-embed` par défaut. Modèle multilingue performant, particulièrement bon en français.
**Avantages :** hébergé en Europe (conformité RGPD facilitée), excellent sur les contenus francophones, tarif compétitif.
## Lancer une analyse
Depuis le tableau de bord, le formulaire **Lancer une nouvelle analyse** propose six paramètres :
- **Langue** — la langue dans laquelle les textes produits seront extraits et analysés. Lancez un run distinct pour chaque langue active de votre boutique.
- **Mode** — TF-IDF, OpenAI ou Mistral (surcharge le réglage par défaut pour ce run uniquement).
- **Nb clusters (k)** — Laissez 0 pour l'auto-k. Sinon, forcez une valeur entre 2 et 100.
- **Taille minimale** — Clusters plus petits écartés (défaut 3).
- **Seuil pillar** — Seuil de match en-dessous duquel un cluster est marqué gap (défaut 0.45).
- **Limite produits** — Limite le nombre de produits analysés (utile pour debug ou test rapide). Laissez 0 pour analyser tout le catalogue.
Cliquez sur **Lancer l'analyse**. Le run démarre immédiatement. Pour un catalogue de 1 000 produits :
- Mode TF-IDF : 5 à 15 secondes
- Mode embeddings (premier run) : 30 secondes à 2 minutes selon le batch size
- Mode embeddings (runs suivants avec cache chaud) : équivalent au TF-IDF
**Important.** Le module pose `set_time_limit(0)` et `memory_limit=1024M` pour la durée du run. Sur les hébergements très contraints, ces directives peuvent être ignorées. Privilégiez un run de nuit ou utilisez la limite produits pour découper.
## Lire les résultats
Une fois le run terminé, vous accédez à la page de détail. Chaque cluster est affiché sous forme de carte avec quatre sections.
### En-tête de cluster
L'en-tête combine un badge de statut, un numéro de cluster et un label généré. Le badge est :
- **PILLAR GAP** (orange) — Aucune pillar page existante ne couvre ce sujet. Opportunité forte.
- **OK** (vert) — Une page CMS ou catégorie couvre déjà ce sujet (le module l'a matchée).
Le label est composé des 3 top-termes du cluster joints par `·`. Exemple : "sneakers · cuir premium · chaussures".
### Statistiques
- **Produits** — Nombre de produits dans le cluster
- **Cohésion** — Similarité moyenne des membres au centroïde (0 à 100 %). Plus c'est élevé, plus le cluster est homogène.
- **Match** — Score de match avec la meilleure pillar page existante. Si en-dessous du seuil → gap.
### Top termes
Les termes les plus représentatifs du cluster. En mode TF-IDF, ce sont les termes ayant la plus forte composante dans le centroïde. En mode embeddings, le module calcule un TF interne au cluster pondéré par l'IDF global pour faire ressortir les termes distinctifs.
### Suggestion de pillar page
Présente uniquement si le cluster est marqué gap. Contient :
- **Titre** — Titre H1 SEO-optimisé en français naturel
- **Slug** — URL-safe, en kebab-case
- **Meta description** — 150-160 caractères
- **Priorité** — Score combiné taille (0.6) × cohésion (0.4)
- **Plan suggéré** — Plan H2 en markdown avec sections classiques (intro, qu'est-ce que, comment choisir, comparatif, meilleurs produits, cas d'usage, erreurs à éviter, FAQ, CTA)
### Produits du cluster
Liste des produits regroupés avec leur score de similarité au centroïde, classés par similarité décroissante. Cliquez sur l'ID produit pour ouvrir directement la fiche dans une nouvelle fenêtre.
## Workflow recommandé
Voici une utilisation typique du module en 4 étapes.
1. **Premier audit** — Lancez un run TF-IDF sur votre langue principale, avec les paramètres par défaut. Examinez les clusters marqués gap : sont-ils pertinents éditorialement ?
2. **Tri** — Pour chaque gap, utilisez le bouton **Ignorer** si le cluster ne mérite pas une pillar page (par exemple un regroupement accidentel de produits hétéroclites). Les gaps restants sont vos priorités.
3. **Rédaction** — Pour chaque gap retenu, créez une nouvelle page CMS dans PrestaShop avec le titre, slug et meta du brouillon. Utilisez le plan H2 comme squelette de rédaction. Cliquez sur **Marquer Fait** une fois publié.
4. **Relance** — Après publication des nouvelles pages, relancez un run. Les anciens gaps doivent maintenant être OK (le module détectera les nouvelles pillar pages).
**Bonnes pratiques SEO.** Une pillar page de qualité fait au moins 1 500 mots, intègre des liens internes vers les produits du cluster, et utilise les top-termes naturellement dans le contenu. Le brouillon généré est un point de départ, pas un livrable final.
## Export
Depuis la page de détail d'un run, deux boutons en haut à droite permettent d'exporter :
- **CSV** — Tableau avec une ligne par cluster, colonnes : id_cluster, label, n_members, cohésion, pillar_gap, match_score, suggested_title, suggested_slug, suggested_meta, priority_score, target_keywords. Encodage UTF-8 avec BOM (compatible Excel).
- **JSON** — Export complet incluant la liste des produits par cluster et le plan markdown intégral. Idéal pour automatisation ou intégration externe.
## Architecture technique
### Base de données
Le module crée 5 tables avec préfixe `df_topicclusters_` :
- `run` — Métadonnées de chaque exécution (mode, langue, statut, durée, compteurs)
- `cluster` — Clusters individuels (label, top termes JSON, cohésion, flag pillar_gap, match_score)
- `cluster_product` — Appartenance produit → cluster avec score de similarité
- `pillar` — Suggestions de pillar pages (titre, slug, meta, outline, priorité, statut)
- `embedding_cache` — Cache des vecteurs d'embeddings indexé par hash de texte
### PSR-4 et autoload
Le namespace racine est `DataFirefly/TopicClusters/`. Un autoload manuel est enregistré via `spl_autoload_register` dans le fichier principal du module, donc aucune dépendance Composer n'est requise.
### Controllers et compatibilité PS 8 / PS 9
Le module utilise un `ModuleAdminController` legacy (et non un controller Symfony) pour garantir la compatibilité avec les deux versions majeures. Les requêtes SQL sont écrites pour respecter les schémas des deux versions, notamment la suppression de la colonne `meta_keywords` en PS 9.
## Performances et limites
- **Catalogues jusqu'à 1 000 produits** — Runs en quelques secondes. Aucune préoccupation particulière.
- **1 000 à 10 000 produits** — Mode TF-IDF reste rapide (10-60 s). Mode embeddings : prévoir 1 à 5 minutes pour le premier run, instantané ensuite grâce au cache.
- **Plus de 10 000 produits** — Privilégier le paramètre **Limite produits** pour découper, ou augmenter `memory_limit` à 2 Go.
La complexité du k-means est O(n × k × iter × d) où n est le nombre de produits, k le nombre de clusters, iter le nombre d'itérations (typiquement 10-30) et d la dimension des vecteurs (variable en TF-IDF, 1536 en OpenAI).
## Dépannage
### Aucun cluster détecté
Vérifiez que vos produits ont bien du contenu textuel dans la langue analysée (au moins un nom et idéalement une description). Si `DFTC_MIN_DOC_FREQ` est trop haut pour votre catalogue, baissez-le à 1.
### Tous les clusters sont marqués pillar gap
Le seuil `DFTC_PILLAR_MATCH_THRESHOLD` est probablement trop élevé. Essayez 0.30 au lieu de 0.45 si votre boutique a peu de pages CMS. Vérifiez aussi que vos pages CMS et catégories sont bien actives.
### Erreur "Unknown column meta_keywords"
Cette erreur survient sur PrestaShop 9 avec une version antérieure du module. Mettez à jour vers la version 1.0.0 ou supérieure qui retire toute référence à `meta_keywords` (colonne supprimée en PS 9).
### Erreur "Compile Error: Access level to processExport() must be public"
Cette erreur survenait sur une version pré-1.0.0. Le nom de méthode est désormais `doExport()` pour éviter la collision avec `AdminControllerCore`. Mettez à jour le module.
### Le run échoue avec erreur API
Vérifiez que la clé API renseignée dans la configuration est valide et a des crédits. Testez avec `curl` en CLI pour confirmer que le serveur peut atteindre `api.openai.com` ou `api.mistral.ai`.
## Évolutions à venir
- Création directe de pages CMS depuis le brouillon (en un clic)
- Comparaison de runs (avant/après publication de pillar pages)
- Visualisation graphique du réseau sémantique inter-clusters
- Support des embeddings Cohere et Voyage AI
- Cron automatique pour relances périodiques
**Support.** Pour toute question ou bug, contactez [support@datafirefly.com](mailto:support@datafirefly.com). Les retours sont précieux pour orienter la roadmap.
---
### DF Audio Product — Lecture audio des fiches produit
_Source :_
> Introduction DF Audio Product ajoute un lecteur audio sur chaque fiche produit de votre boutique PrestaShop. Un clic sur « Écouter la description » et le nom du produit, sa…
## Introduction
DF Audio Product ajoute un lecteur audio sur chaque fiche produit de votre boutique PrestaShop. Un clic sur « Écouter la description » et le nom du produit, sa description courte et sa description longue sont lus à voix haute, à la vitesse choisie par le visiteur.
Le module fonctionne avec quatre moteurs de synthèse vocale : le moteur du navigateur (gratuit, sans clé API) et trois moteurs serveur premium (OpenAI, Google Cloud, ElevenLabs) dont les fichiers MP3 sont mis en cache pour maîtriser les coûts.
## Prérequis
- PrestaShop 8.0 à 9.x
- PHP 8.0 ou supérieur
- Extension cURL activée (uniquement pour les moteurs serveur)
- Dossier `var/` accessible en écriture par PHP (uniquement pour les moteurs serveur)
- Aucune dépendance Composer
## Installation
1. Dans le back-office, allez dans **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez le fichier `dfaudioproduct-1.0.0.zip`.
3. Cliquez sur **Configurer** une fois l'installation terminée.
À l'installation, le module crée automatiquement la table de cache, l'onglet d'administration sous _Catalogue_, le dossier de cache `var/dfaudioproduct/` protégé par un fichier .htaccess, et s'enregistre sur les hooks nécessaires.
**Démarrage immédiat :** avec le moteur navigateur activé par défaut, le lecteur fonctionne dès l'installation, sans aucune configuration ni clé API.
## Choisir un moteur de synthèse vocale
### Moteur navigateur (Web Speech API)
C'est le moteur par défaut. La voix est synthétisée directement sur l'appareil du visiteur par son navigateur (Chrome, Edge, Safari, Firefox). Aucune clé API, aucun coût, aucune donnée envoyée à un service tiers, et aucun fichier stocké sur votre serveur.
Le module transmet le texte de la fiche au navigateur, qui choisit automatiquement une voix correspondant à la langue du visiteur. La qualité et le catalogue de voix dépendent donc du système d'exploitation du visiteur : très bons sur macOS et iOS, corrects sur Windows et Android.
### OpenAI TTS
Voix naturelles de haute qualité. Renseignez votre clé API OpenAI, choisissez un modèle (`tts-1` pour la rapidité, `tts-1-hd` pour la qualité maximale, `gpt-4o-mini-tts` pour le meilleur compromis) et une voix parmi : `alloy`, `echo`, `fable`, `onyx`, `nova`, `shimmer`. Si le champ Voix est vide, `alloy` est utilisée.
### Google Cloud Text-to-Speech
Renseignez une clé API Google Cloud avec l'API Text-to-Speech activée. Le champ Voix est optionnel : laissez-le vide et le module déduit automatiquement le code langue depuis la langue du visiteur (fr-FR, en-US, es-ES, de-DE, it-IT). Pour forcer une voix précise, saisissez son nom complet, par exemple `fr-FR-Neural2-A` — le code langue est alors déduit du nom de la voix.
### ElevenLabs
Renseignez votre clé API ElevenLabs et, obligatoirement, l'identifiant de la voix (Voice ID) dans le champ Voix. Vous le trouverez dans votre bibliothèque de voix ElevenLabs. Le module utilise le modèle multilingue `eleven_multilingual_v2`, qui gère nativement les cinq langues.
**Tester avant de publier :** le bouton **Tester la connexion API** en bas de la page de configuration synthétise une phrase courte et affiche la taille du fichier obtenu. Il ne stocke rien en cache. Si la clé est invalide ou la voix inconnue, le message d'erreur renvoyé par l'API s'affiche directement.
## Configuration
### Activer
Interrupteur global. Désactivé, le lecteur disparaît des fiches produit et le contrôleur de génération audio ne répond plus.
### Vitesse de lecture par défaut
Vitesse appliquée au premier chargement de la page : 0,75×, 1×, 1,25×, 1,5× ou 2×. Le visiteur peut ensuite cycler entre ces valeurs avec le bouton de vitesse du lecteur.
### Nombre maximum de caractères
Longueur maximale du texte lu, entre 200 et 20 000 caractères (3 000 par défaut). Le texte est coupé proprement à la fin de la dernière phrase complète. Ce réglage a un impact direct sur le coût des moteurs serveur, facturés au caractère : une valeur basse réduit la facture, une valeur haute lit l'intégralité de vos descriptions.
### Lire la description courte / la description longue
Deux interrupteurs indépendants. Le nom du produit est toujours lu en premier. Vous pouvez ne lire que la description courte (rapide, économique) ou l'ensemble.
### Position d'affichage
- **Sous le bloc d'achat** (hook `displayProductAdditionalInfo`) — position recommandée, bien visible sous le prix et le bouton d'ajout au panier.
- **Dans les actions produit** (hook `displayProductActions`) — plus intégré aux boutons du thème.
Le module est enregistré sur les deux hooks, mais n'affiche le lecteur que sur celui sélectionné : changer de position ne demande aucune manipulation dans le positionnement des modules.
### Durée de vie du cache (jours)
0 = les fichiers audio ne périment jamais (recommandé). Une valeur supérieure supprime automatiquement les fichiers générés depuis plus de N jours, lors de la prochaine génération. Utile si vous changez régulièrement de voix ou de moteur.
## Fonctionnement du cache
Le cache ne concerne que les moteurs serveur ; le moteur navigateur ne génère aucun fichier.
1. Un visiteur clique sur « Écouter la description » pour la première fois.
2. Le module extrait le texte de la fiche côté serveur, le nettoie du HTML et le tronque selon votre limite de caractères.
3. Il calcule une empreinte unique à partir du moteur, du modèle, de la voix, de la langue, de la boutique et du texte lui-même.
4. Si aucun fichier ne correspond, il appelle l'API du moteur, reçoit le MP3 et l'écrit dans `var/dfaudioproduct/`.
5. Le fichier est servi avec un en-tête ETag et un Cache-Control d'un jour. Les visiteurs suivants reçoivent le fichier en cache, et les rechargements de page renvoient une réponse 304 sans retransférer l'audio.
Conséquence importante : **vous payez au maximum une génération par produit et par langue**, pas une par visite. Votre coût dépend de la taille de votre catalogue, jamais de votre trafic.
La vitesse de lecture n'entre pas dans l'empreinte : elle est appliquée par le navigateur sur le fichier existant. Un seul MP3 couvre donc les cinq vitesses.
### Invalidation automatique
Le cache audio d'un produit est purgé automatiquement — dans toutes les langues et toutes les boutiques — dès que ce produit est modifié ou supprimé, via les hooks `actionObjectProductUpdateAfter` et `actionObjectProductDeleteAfter`. Le nouvel audio est généré à la prochaine écoute, avec le contenu à jour. Aucune action manuelle n'est nécessaire après une correction de description.
### Emplacement des fichiers
Les MP3 sont stockés dans `var/dfaudioproduct/`, à la racine de PrestaShop, volontairement en dehors du dossier du module : une mise à jour du module ne détruit donc pas le cache. Le dossier est protégé par un fichier .htaccess et un index.php : les fichiers ne sont accessibles qu'à travers le contrôleur du module, jamais en accès direct.
## Gestion du cache dans le back-office
La page de configuration affiche en haut un panneau de statistiques : nombre de fichiers en cache, espace disque occupé et nombre total de lectures.
Le bouton **Parcourir les fichiers en cache** ouvre l'onglet _Catalogue > DF Audio Product_, qui liste chaque fichier avec l'identifiant du produit, son nom, la langue, le moteur, la voix, la taille, le nombre de lectures et la date de génération. Vous pouvez supprimer un fichier, une sélection de fichiers, ou tout purger via le bouton **Tout purger** de la barre d'outils.
Le bouton **Purger le cache audio** de la page de configuration a le même effet : il supprime les fichiers du disque et vide la table. Les audios seront simplement régénérés à la demande.
**Après un changement de moteur ou de voix :** les anciens fichiers ne sont plus utilisés (l'empreinte a changé) mais restent sur le disque jusqu'à expiration de la durée de vie ou purge manuelle. Pensez à purger le cache pour libérer l'espace.
## Le lecteur côté boutique
Le lecteur se compose d'un bouton « Écouter la description », d'une barre de progression, d'un compteur de temps et d'un bouton de vitesse.
- **Moteurs serveur :** la barre de progression est cliquable pour se déplacer dans l'audio, et le compteur affiche le temps écoulé et la durée totale.
- **Moteur navigateur :** la barre de progression est indicative (elle avance mot par mot) et le compteur est masqué, la Web Speech API ne fournissant pas de durée.
Le changement de vitesse en cours de lecture est géré dans les deux cas. Avec le moteur navigateur, la synthèse ne pouvant pas changer de vitesse à la volée, le module la relance silencieusement depuis le dernier mot prononcé — la reprise est imperceptible. Un mécanisme de maintien en vie contourne également la coupure des synthèses longues après une quinzaine de secondes sur les navigateurs Chromium.
Le lecteur se réinitialise automatiquement lors d'un changement de déclinaison en AJAX, en écoutant l'événement `updatedProduct` du thème.
## Accessibilité
Le lecteur est conçu pour être utilisable par tous, dans l'esprit de la directive européenne sur l'accessibilité (European Accessibility Act) :
- Bouton de lecture avec état `aria-pressed` reflétant la lecture en cours
- Zone d'annonce `aria-live` pour signaler le chargement, la lecture ou une erreur aux lecteurs d'écran
- Navigation et activation entièrement au clavier, avec anneau de focus visible
- Barre de progression étiquetée et manipulable au clavier
- Respect de la préférence système `prefers-reduced-motion` (ralentissement de l'animation de chargement)
- Cibles tactiles généreuses et disposition adaptée aux petits écrans
La lecture audio du contenu produit constitue une réponse concrète aux exigences d'accessibilité. La conformité globale de votre boutique dépend toutefois de l'ensemble de vos pages — thème, tunnel de commande, contenus éditoriaux.
## Multilingue et multiboutique
Le texte est extrait dans la langue du visiteur : chaque langue produit donc son propre fichier audio, avec la voix adaptée. En multiboutique, le cache est également séparé par boutique, ce qui permet des descriptions différentes d'une boutique à l'autre.
Les libellés de l'interface du lecteur (« Écouter la description », « Pause », « Reprendre », « Chargement… ») sont traduisibles depuis **International > Traductions > Traductions des modules**.
## Personnalisation du style
Le lecteur utilise des variables CSS que vous pouvez surcharger depuis la feuille de style de votre thème enfant, sans modifier le module :
```
.dfap-player {
--dfap-accent: #2b6cb0;
--dfap-accent-hover: #1f4f85;
--dfap-muted: #718096;
--dfap-bg: #ffffff;
}
```
Les classes utiles sont `.dfap-player` (conteneur), `.dfap-play` (bouton principal), `.dfap-progress` (barre), `.dfap-speed` (bouton de vitesse) et l'état `.dfap-is-playing`.
## Coûts et bonnes pratiques
- **Commencez par le moteur navigateur.** Il est gratuit et permet de valider l'intérêt de la fonctionnalité sur votre audience avant tout investissement.
- **Ajustez la limite de caractères.** Passer de 3 000 à 1 200 caractères divise votre facture API par deux et suffit largement pour la plupart des descriptions.
- **Ne lisez que la description courte** si vos descriptions longues sont très denses ou contiennent des tableaux techniques peu adaptés à l'oral.
- **Préchauffez le cache** en visitant vos meilleures ventes après un changement de moteur : les premiers visiteurs n'auront pas à attendre la génération.
## Dépannage
### Le lecteur ne s'affiche pas
Vérifiez que le module est activé dans sa configuration, que la position d'affichage correspond bien à un hook présent dans votre thème, et que la fiche contient au moins vingt caractères de texte lisible. Videz ensuite le cache PrestaShop.
### Le bouton passe en erreur au clic (moteurs serveur)
Utilisez le bouton **Tester la connexion API** : il affiche le message d'erreur exact renvoyé par le fournisseur. Les causes les plus fréquentes sont une clé API invalide ou expirée, un quota dépassé, une voix inexistante (notamment un Voice ID ElevenLabs erroné) ou l'extension cURL désactivée. Les erreurs sont également tracées dans **Paramètres avancés > Journaux**, préfixées par dfaudioproduct.
### Rien ne se passe avec le moteur navigateur
Certains navigateurs exigent une interaction de l'utilisateur avant d'autoriser la synthèse vocale — c'est le cas ici, la lecture démarre au clic. Vérifiez ensuite qu'une voix est installée pour la langue concernée sur le système du visiteur. Sur un poste Windows sans pack vocal français, le navigateur peut n'avoir aucune voix disponible ; le module bascule alors sur la première voix compatible ou reste silencieux. Enfin, la Web Speech API exige une connexion HTTPS sur la plupart des navigateurs.
### Erreur d'écriture du cache
Le dossier `var/dfaudioproduct/` doit être accessible en écriture par l'utilisateur PHP. Vérifiez les droits du dossier `var/` et l'espace disque disponible.
### L'audio ne se met pas à jour après modification d'un produit
L'invalidation est automatique. Si l'ancien audio persiste, il s'agit du cache navigateur du visiteur : le fichier étant servi avec un Cache-Control d'un jour, un rechargement forcé (Ctrl+F5) résout le cas. Le nouvel ETag remplace ensuite l'ancien pour tous.
## Désinstallation
La désinstallation supprime la table de cache, l'onglet d'administration, tous les réglages et l'intégralité des fichiers MP3 générés, dossier `var/dfaudioproduct/` compris. Aucun résidu n'est laissé sur le serveur.
## Support
Une question, un bug, une demande d'évolution ? Contactez l'équipe DataFirefly depuis la page de support du site. Précisez votre version de PrestaShop, votre version de PHP, le moteur utilisé et, le cas échéant, le contenu du journal d'erreurs.
---
### DF Dark Mode pour PrestaShop 8 et 9 — Documentation
_Source :_
> DF Dark Mode ajoute un mode sombre complet à votre boutique PrestaShop 8 ou 9, sans aucune modification de votre thème. Le module détecte la préférence système du visiteur, mémorise…
DF Dark Mode ajoute un mode sombre complet à votre boutique PrestaShop 8 ou 9, sans aucune modification de votre thème. Le module détecte la préférence système du visiteur, mémorise son choix, et génère le thème sombre côté serveur.
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez le fichier `dfdarkmode-1.1.0.zip`.
3. Une fois l'installation terminée, cliquez sur **Configurer**.
Le module est actif immédiatement avec ses réglages par défaut : moteur « filtre intelligent », mode « automatique » et bouton flottant en bas à droite. Aucune configuration n'est nécessaire pour un fonctionnement correct.
## Choisir le moteur de rendu
Le module propose deux moteurs. Le choix se fait dans le champ **Moteur de rendu** de la configuration.
### Filtre intelligent (recommandé)
Ce moteur inverse la page entière puis contre-inverse chaque média (images, vidéos, iframes, canvas, arrière-plans) afin que vos photos produit conservent leurs couleurs naturelles. Il fonctionne sur n'importe quel thème, sans configuration ni CSS supplémentaire.
Deux réglages permettent d'affiner le rendu :
- **Luminosité** (50 à 150 %, défaut 100) — abaissez-la légèrement, à 92 par exemple, si le rendu sombre vous paraît trop lumineux.
- **Contraste** (50 à 150 %, défaut 100).
### Palette générée
Ce moteur calcule une gamme sombre complète à partir de deux couleurs que vous choisissez : une **couleur de fond** et une **couleur d'accent**. Neuf variables CSS en sont dérivées automatiquement :
- `--df-bg` — le fond de page
- `--df-surface`, `--df-surface-2`, `--df-surface-3` — trois niveaux de surface (cartes, en-têtes, survols)
- `--df-border` — les bordures
- `--df-text`, `--df-text-muted` — le texte principal et le texte atténué
- `--df-accent`, `--df-accent-hover` — l'accent et son état de survol
La couleur du texte des boutons est choisie automatiquement (clair ou sombre) selon la luminance relative de votre accent, afin de garantir un contraste lisible. Ce moteur produit un rendu plus net que le filtre, mais peut demander quelques ajustements CSS selon votre thème.
## Mode par défaut
Le champ **Mode par défaut** détermine ce que voit un visiteur qui n'a encore jamais utilisé le bouton :
- **Automatique** — le module suit la préférence du système d'exploitation du visiteur (réglage `prefers-color-scheme`). Si le visiteur bascule son appareil en mode sombre pendant sa navigation, la boutique suit en direct, sans rechargement.
- **Clair** — la boutique reste claire tant que le visiteur ne demande pas le mode sombre.
- **Sombre** — la boutique s'affiche en sombre pour tout le monde par défaut.
Dès que le visiteur clique sur le bouton, son choix est mémorisé dans son navigateur et prime sur le mode par défaut, pour toutes ses visites suivantes.
## Placer le bouton
Le champ **Emplacement du bouton** propose deux modes.
### Bouton flottant
Un bouton rond superposé à la page, dans l'un des quatre coins (haut/bas, gauche/droite). Vous pouvez le masquer sur mobile via le réglage dédié.
### Hook de thème
Le bouton est rendu en ligne, dans la mise en page de votre thème. Sélectionnez le hook cible dans la liste :
- `displayNav1`, `displayNav2` — barres supérieures du header (displayNav2 correspond à la zone en haut à droite sur la plupart des thèmes)
- `displayTop`, `displayNavFullWidth`, `displayBanner`
- `displayFooter`, `displayFooterAfter`
La variante en ligne du bouton est plus compacte et transparente : elle hérite des couleurs de son conteneur et se fond dans votre header ou votre footer.
### Hook personnalisé
Si votre thème exécute un hook qui lui est propre, saisissez simplement son nom dans le champ **Nom du hook personnalisé**. Le module l'enregistre automatiquement à l'enregistrement du formulaire — aucune ligne de code à écrire. Ce champ est prioritaire sur la liste ci-dessus.
Le nom doit commencer par une lettre et ne contenir que des lettres, des chiffres et des tirets bas. Exemple : `displayMonSwitcher`.
### Depuis un template
Les intégrateurs peuvent afficher le bouton n'importe où dans un fichier .tpl du thème avec la syntaxe widget de PrestaShop :
```
{widget name='dfdarkmode'}
```
Cet appel rend toujours le bouton, quel que soit le mode d'emplacement configuré.
### Bouton cycle à trois états
Activez l'option **Bouton à 3 états** pour que le bouton alterne entre clair, sombre et automatique au lieu du simple basculement clair/sombre. Un petit badge « A » apparaît sur le bouton lorsque le mode automatique est actif.
## Exclure des éléments
Le champ **Sélecteurs CSS exclus** accepte une liste de sélecteurs, un par ligne ou séparés par des virgules. Les éléments correspondants conservent leur rendu clair d'origine — pratique pour un logo, une bannière partenaire ou un widget tiers.
```
.mon-logo
#banniere-partenaire
.widget-avis
```
Les sélecteurs contenant des accolades, des chevrons ou des points-virgules sont ignorés à l'enregistrement.
Vous pouvez aussi ajouter directement la classe `df-no-invert` à un élément de votre thème : il sera automatiquement préservé.
## CSS personnalisé
Le champ **CSS personnalisé** est injecté uniquement lorsque le mode sombre est actif. Préfixez vos règles par `html.df-dark` :
```
html.df-dark .header-banner {
background: var(--df-surface);
color: var(--df-text);
}
```
Les variables CSS (`--df-surface`, `--df-text`, etc.) ne sont disponibles qu'avec le moteur « palette générée ».
## API JavaScript
Le module expose une API publique pour vos propres intégrations :
```
// Mode configuré : "light", "dark" ou "auto"
DFDarkMode.get();
// Mode réellement affiché : "light" ou "dark"
DFDarkMode.effective();
// Forcer un mode (mémorisé dans le navigateur)
DFDarkMode.set('dark');
// Basculer
DFDarkMode.toggle();
```
Un évènement est émis sur le document à chaque changement de mode :
```
document.addEventListener('dfdarkmode:change', function (e) {
console.log(e.detail.mode); // "light" | "dark" | "auto"
console.log(e.detail.dark); // true | false
});
```
Enfin, tout élément portant l'attribut `data-df-darkmode-toggle` devient automatiquement un déclencheur, sans code supplémentaire.
## Fonctionnement technique
### Absence de flash au chargement
Un script synchrone, injecté dans l'en-tête de la page, lit la préférence mémorisée puis applique la classe `df-dark` à l'élément racine avant le premier rendu du navigateur. Le visiteur en mode sombre ne voit donc jamais la version claire, même brièvement.
### Contre-inversion des médias
Avec le moteur filtre, les filtres CSS se composent lorsqu'ils sont imbriqués : ils ne s'annulent pas. Une image placée dans un élément `picture` déjà contre-inversé serait donc inversée deux fois. Le module neutralise ce cas avec une règle de garde qui remet à zéro le filtre de tout média imbriqué dans un ancêtre déjà contre-inversé.
### Mémorisation
Le choix du visiteur est stocké dans le `localStorage` de son navigateur, sous la clé `dfdm`. Aucune donnée personnelle n'est collectée ni transmise à un serveur : le module n'utilise ni cookie ni appel réseau, et n'a donc aucune implication RGPD.
## Dépannage
### Les photos produit apparaissent en négatif
Vérifiez que vous utilisez bien la version 1.1.0 ou supérieure, puis videz le cache PrestaShop (**Paramètres avancés > Performances > Vider le cache**). Si un élément spécifique reste inversé, ajoutez son sélecteur dans le champ des sélecteurs exclus.
### Le bouton n'apparaît pas sur le hook choisi
Certains thèmes n'exécutent pas tous les hooks standards. Vérifiez dans **Design > Positions** que le module est bien greffé au hook visé, et que ce hook est effectivement appelé par votre thème. En dernier recours, utilisez la syntaxe widget dans le fichier .tpl de votre choix.
### Un élément reste illisible en mode sombre
Ajoutez une règle dans le champ CSS personnalisé, préfixée par `html.df-dark`. Si le problème concerne un bloc entier, l'exclure via les sélecteurs CSS est souvent plus simple.
## Désinstallation
La désinstallation supprime toute la configuration du module. Les préférences enregistrées dans le navigateur de vos visiteurs ne sont pas affectées, mais elles deviennent sans effet une fois le module retiré.
---
### DF Download Center — Documentation
_Source :_
> Présentation DF Download Center rattache vos notices, manuels, fiches techniques et certificats CE directement à vos produits. Chaque fiche produit gagne un onglet « Documents & téléchargements » qui liste…
## Présentation
DF Download Center rattache vos notices, manuels, fiches techniques et certificats CE directement à vos produits. Chaque fiche produit gagne un onglet « Documents & téléchargements » qui liste les fichiers groupés par type. En parallèle, une page centrale indexable regroupe tout le catalogue documentaire, avec recherche, filtres par type et données structurées JSON-LD.
Le module est compatible PrestaShop 8.0 à 9.x, multiboutique, disponible en cinq langues, et ne dépend ni de Composer ni d'aucun framework externe.
## Installation
1. Depuis le back-office, allez dans **Modules** puis **Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez le fichier `dfdownloadcenter-1.0.0.zip`.
3. Cliquez sur **Installer**.
L'installation crée les tables du module, quatre types de documents par défaut, un onglet d'administration sous le menu **Catalogue**, et enregistre les hooks nécessaires.
**Après l'installation, videz le cache** depuis Paramètres avancés puis Performances. La route de la page centrale est déclarée par le hook de routage et n'est active qu'après régénération du cache.
### Permissions
Le dossier `modules/dfdownloadcenter/uploads/` doit être accessible en écriture par le serveur web. Il contient un fichier htaccess qui bloque tout accès HTTP direct : les fichiers ne sortent que par le contrôleur de téléchargement.
## Configuration
Ouvrez le module depuis **Modules** puis **Gestionnaire de modules**, et cliquez sur **Configurer**.
### Page centrale
- **Activer la page centrale** — quand elle est désactivée, la page renvoie une 404 et le lien depuis l'onglet produit disparaît.
- **Slug de l'URL** — le segment d'URL de la page, par exemple `telechargements` ou `downloads`. Videz le cache après toute modification.
- **Documents par page** — 20 par défaut.
- **Meta title** et **Meta description** — configurables langue par langue, utilisés dans la balise title et la meta description de la page.
### Types de documents
Quatre types sont installés par défaut, traduits dans les cinq langues du catalogue :
- Notices & manuels
- Fiches techniques
- Certificats CE
- Autres documents
Depuis l'écran de configuration, vous pouvez créer, renommer et réordonner les types. La **position** détermine l'ordre d'affichage des groupes dans l'onglet produit et sur la page centrale.
Un type utilisé par au moins un document ne peut pas être supprimé. Le module affiche le nombre de documents concernés et vous demande de les réaffecter à un autre type au préalable.
## Gérer les documents
Les documents se gèrent depuis **Catalogue** puis **Centre de téléchargement**. La liste affiche pour chaque document son titre, son type, le nom du fichier, sa taille, le nombre de téléchargements et son statut d'activation.
### Créer un document
1. Cliquez sur **Ajouter**.
2. Saisissez le **titre** dans chaque langue. Le titre est obligatoire dans la langue par défaut.
3. Ajoutez une **description** facultative, également par langue. Elle s'affiche sous le titre dans l'onglet produit et sur la page centrale.
4. Choisissez le **type** du document.
5. Sélectionnez le **fichier** à mettre en ligne.
6. Rattachez les **produits associés** en tapant leur nom ou leur référence dans le champ de recherche : les suggestions apparaissent au bout de deux caractères, et chaque produit sélectionné devient une pastille retirable en un clic.
7. Définissez la **position** du document au sein de son type, et son statut **actif**.
8. Enregistrez.
### Formats et taille des fichiers
Les extensions acceptées sont : PDF, DOC, DOCX, ODT, XLS, XLSX, ODS, CSV, TXT, RTF, ZIP, PNG, JPG, JPEG, WEBP, SVG, DWG, DXF, STEP et STP. La taille maximale par fichier est de 50 Mo.
Si un fichier de moins de 50 Mo est refusé, vérifiez les directives `upload_max_filesize` et `post_max_size` de votre configuration PHP : le module ne peut pas recevoir un fichier que PHP refuse en amont.
### Remplacer un fichier
Ouvrez le document en édition et sélectionnez un nouveau fichier. L'ancien fichier est supprimé du serveur automatiquement une fois la mise à jour réussie. Le compteur de téléchargements est conservé.
### Un document, plusieurs produits
L'association document-produits est multiple. Un certificat CE qui couvre trois références se rattache aux trois en une seule saisie, et apparaît alors dans l'onglet de chacune. Inversement, un produit peut porter autant de documents que nécessaire.
Un document sans aucun produit associé reste valide : il n'apparaît dans aucun onglet produit, mais reste visible sur la page centrale. C'est l'usage à retenir pour une charte qualité, un catalogue général ou tout document d'entreprise.
## L'onglet produit
Sur la fiche produit, l'onglet « Documents & téléchargements » apparaît aux côtés de la description, via le hook natif d'extra content de PrestaShop. Aucun fichier de thème n'est surchargé.
Les documents y sont groupés par type, dans l'ordre défini par la position des types. Chaque ligne affiche une pastille d'extension colorée, le titre, la description facultative, la taille du fichier et un bouton de téléchargement. Un lien vers la page centrale ferme l'onglet lorsque celle-ci est activée.
Si un produit n'a aucun document actif rattaché, l'onglet n'apparaît pas du tout.
## La page centrale
La page centrale est servie à l'URL définie par le slug, par exemple `/telechargements` en français, ou `/en/telechargements` dans les autres langues selon la configuration multilingue de votre boutique.
### Recherche et filtres
Le champ de recherche interroge simultanément le titre du document, sa description, le nom du fichier d'origine, ainsi que le nom et la référence des produits associés. Un client qui tape une référence produit retrouve donc la notice correspondante.
Les filtres par type s'affichent sous forme de pastilles, avec pour chacune le nombre de documents actifs. La pagination est configurable depuis les réglages.
### SEO
La page est conçue pour être indexée :
- meta title et meta description configurables par langue ;
- directive robots en index follow ;
- URL canonique propre — seul le numéro de page est conservé, les filtres et la recherche sont exclus pour éviter la duplication ;
- fil d'Ariane ;
- bloc de données structurées JSON-LD de type ItemList, décrivant chaque fichier comme un DigitalDocument ;
- liens internes vers les produits concernés, sous chaque document.
## Téléchargement et sécurité
Les fichiers ne sont jamais accessibles en direct. Ils sont écrits sous un nom haché dans le dossier `uploads/` du module, verrouillé par un fichier htaccess.
Le téléchargement passe obligatoirement par un contrôleur front qui, avant de servir le fichier :
- vérifie que le document existe et qu'il est actif ;
- vérifie qu'il est rattaché à la boutique courante ;
- incrémente le compteur de téléchargements ;
- restitue le fichier sous son nom d'origine.
Les PDF et les images s'ouvrent dans le navigateur ; les autres formats déclenchent un téléchargement. Toute requête invalide est redirigée vers la page 404 de la boutique.
## Multiboutique
Les documents sont associés aux boutiques nativement, via l'association de table standard de PrestaShop. En contexte multiboutique, un document créé dans une boutique n'apparaît que dans celle-ci, et le contrôleur de téléchargement refuse de servir un fichier rattaché à une autre boutique.
Les réglages de la page centrale — slug, meta, pagination — sont eux aussi gérés par boutique.
## Désinstallation
La désinstallation supprime les tables du module, ses variables de configuration, son onglet d'administration, et efface l'intégralité des fichiers présents dans le dossier `uploads/`.
Sauvegardez vos fichiers avant de désinstaller le module : les documents mis en ligne ne sont pas récupérables après désinstallation.
## Dépannage
### L'URL de la page centrale renvoie une 404
Videz le cache depuis Paramètres avancés puis Performances. Les routes déclarées par le hook de routage sont mises en cache par PrestaShop et ne sont prises en compte qu'après régénération.
Vérifiez également que les URL simplifiées sont activées dans Paramètres de la boutique puis Trafic & SEO, et que la page centrale est activée dans la configuration du module.
### L'onglet n'apparaît pas sur la fiche produit
Vérifiez que le produit a au moins un document **actif** rattaché, et que le hook d'extra content est bien enregistré pour le module dans la page Positions du back-office. Sur un thème très personnalisé, assurez-vous que le modèle de fiche produit affiche bien les blocs d'extra content.
### Le téléchargement renvoie une 404
Trois causes possibles : le document est désactivé, il n'est pas rattaché à la boutique courante, ou le fichier physique est absent du dossier `uploads/`. Rééditez le document et remettez le fichier en ligne.
### L'upload échoue sans message clair
Vérifiez les permissions en écriture sur `modules/dfdownloadcenter/uploads/`, puis les directives PHP `upload_max_filesize`, `post_max_size` et `max_file_uploads`.
## Compatibilité technique
- PrestaShop 8.0 à 9.x
- PHP 7.4 à 8.3
- Hooks utilisés : displayProductExtraContent, moduleRoutes, displayHeader, actionObjectProductDeleteAfter
- Aucun override du cœur, aucune dépendance Composer
- Interface d'autocomplétion en JavaScript natif, sans jQuery
- Multiboutique et multilingue : FR, EN, ES, DE, IT
---
### DF ERP Bridge — Export ERP planifié (Sage 100, EBP, Cegid, Codial)
_Source :_
> DF ERP Bridge exporte automatiquement vos commandes, clients et stock PrestaShop vers votre logiciel de gestion — Sage 100, EBP, Cegid, Codial — ou vers un format générique CSV, XML…
DF ERP Bridge exporte automatiquement vos **commandes**, **clients** et **stock** PrestaShop vers votre logiciel de gestion — Sage 100, EBP, Cegid, Codial — ou vers un format générique CSV, XML ou JSON. Les fichiers sont générés selon la cadence que vous définissez et livrés automatiquement par FTP/FTPS ou par e-mail, sous le contrôle d'un cron. Ce guide couvre l'installation, la création de profils, les formats, les transports, la planification et la sécurité.
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**, cliquez sur **Installer un module** et déposez le fichier `dferpbridge.zip`.
2. Une fois installé, cliquez sur **Configurer**.
3. À la première installation, un jeton de cron est généré automatiquement et la rétention des journaux est fixée à 30 jours. Ces réglages sont modifiables dans la section **Réglages** en bas de la page de configuration.
Le module est purement back-office : il n'ajoute rien au front de votre boutique. Il est compatible PrestaShop 8.0 à 9.x et multiboutique.
## Créer un profil d'export
Un **profil** décrit un export : quelles données, dans quel format, vers quelle destination et à quelle fréquence. Vous pouvez créer autant de profils que nécessaire. Cliquez sur **Ajouter un profil** et renseignez les champs.
### Champs principaux
- **Nom du profil** — un libellé qui vous aide à l'identifier (ex. « Commandes vers Sage — quotidien »).
- **Données à exporter** — Commandes, Clients ou Stock.
- **Format ERP** — Sage 100, EBP, Cegid, Codial, ou un format générique CSV / XML / JSON.
- **Transport** — Dépôt FTP ou pièce jointe e-mail.
- **Fréquence** — Horaire, Quotidienne ou Hebdomadaire. Évaluée à chaque appel du cron.
- **Filtre de statuts de commande** — (commandes uniquement) sélection multiple ; laissez vide pour exporter tous les statuts.
- **Export incrémental** — n'exporte que les enregistrements créés depuis le dernier passage.
- **Actif** — un profil inactif est ignoré par le cron mais reste exécutable manuellement.
## Les formats d'export
Les quatre presets ERP sont produits en encodage **Windows-1252**, avec un séparateur point-virgule, des retours à la ligne CRLF et des décimales à la virgule — la convention attendue par les outils d'import français. Les formats génériques sortent en **UTF-8**.
### Sage 100
Fichier `.txt` à deux niveaux : des lignes d'entête « E » suivies de leurs lignes de détail « L », dans une structure compatible avec l'import de documents de Sage 100 Gestion Commerciale. Les frais de port sont ajoutés en ligne dédiée « PORT ». L'ordre des colonnes est remappable dans l'assistant « Format d'import paramétrable » de Sage.
### EBP
CSV plat `.csv` avec ligne d'en-têtes, une ligne par ligne de commande (les champs d'entête sont répétés). Adapté à l'import paramétrable d'EBP Gestion Commerciale.
### Cegid
Document XML `.xml` structuré en DOCUMENTS / DOCUMENT avec un bloc ENTETE et un bloc LIGNES, pour l'intégration de documents façon Cegid Business / XRP Flex.
### Codial
CSV plat `.csv` avec en-têtes, une ligne par ligne de commande, pensé pour le module d'import configurable de Codial.
### Génériques CSV / XML / JSON
Pour tout autre outil (Odoo, Dolibarr, ERP maison, tableur), ces formats exportent l'intégralité des champs en UTF-8. Le CSV générique inclut un BOM pour une ouverture propre dans Excel ; le XML imbrique les lignes sous chaque commande ; le JSON encapsule les enregistrements dans une enveloppe avec entité, date et nombre.
## Transports
### FTP / FTPS
Renseignez l'hôte, le port (21 par défaut), l'utilisateur, le mot de passe et le chemin distant (ex. `/exports/prestashop`). Le mode passif et le SSL explicite (FTPS) sont pris en charge par des interrupteurs dédiés.
Le mot de passe FTP est chiffré au repos en base avec la clé de chiffrement de votre boutique. Lors de la modification d'un profil, laissez le champ mot de passe vide pour conserver la valeur existante.
### E-mail
Le fichier est envoyé en pièce jointe à l'adresse indiquée dans **E-mail destinataire**. Les modèles d'e-mail sont fournis en français et en anglais.
## Planification par cron
Le panneau **Exécution planifiée (cron)** affiche l'URL sécurisée à appeler. Ajoutez-la à votre crontab ou à un service de cron. À chaque appel, seuls les profils dont la fréquence est échue s'exécutent (avec une tolérance de 5 minutes).
```
*/15 * * * * curl -s "https://votre-boutique.tld/module/dferpbridge/cron?token=VOTRE_TOKEN" > /dev/null 2>&1
```
Paramètres optionnels de l'URL :
- `id_profile=N` — n'exécute qu'un seul profil.
- `force=1` — ignore le contrôle de fréquence et exécute quoi qu'il arrive.
Planifiez le cron au moins aussi souvent que la fréquence la plus élevée utilisée par vos profils. Un profil « horaire » a besoin d'un cron appelé au minimum toutes les heures.
### Exécution manuelle
Chaque profil dispose d'un bouton **Lancer maintenant** sous la liste, qui déclenche l'export immédiatement en ignorant la fréquence — pratique pour tester un profil après configuration.
## Export incrémental et filtres
En mode incrémental, les **commandes** et les **clients** exportés sont uniquement ceux créés après la date du dernier passage réussi, ce qui évite les doublons dans votre ERP. Le **stock** est toujours exporté en instantané complet, quel que soit ce réglage.
Pour les commandes, le filtre de statuts limite l'export aux états sélectionnés (par exemple « Paiement accepté » et « Expédié »). Chaque commande embarque ses lignes de détail, la TVA calculée par ligne, les frais de port et l'adresse de facturation complète (SIRET, TVA intracommunautaire).
## Journal des exports et rétention
Les 20 derniers exports apparaissent en back-office avec leur statut (succès, vide, erreur), le nombre d'enregistrements, le fichier généré et un message éventuel. Les journaux plus anciens que la durée de **rétention** configurée (30 jours par défaut) sont purgés automatiquement à chaque passage du cron.
## Sécurité
- L'URL de cron est protégée par un jeton comparé en temps constant ; un appel sans jeton valide renvoie une erreur 403.
- Le mot de passe FTP est chiffré au repos et n'est déchiffré qu'au moment de la connexion.
- Vous pouvez régénérer le jeton de cron depuis les **Réglages** ; l'ancienne URL cesse alors de fonctionner.
## Dépannage
### « Invalid token » lors de l'appel du cron
Vérifiez que le jeton dans l'URL correspond exactement à celui affiché dans le panneau cron. S'il a été régénéré, mettez à jour votre crontab.
### L'export FTP échoue
Assurez-vous que l'extension PHP FTP est disponible sur le serveur, que l'hôte et l'utilisateur sont corrects, et que le chemin distant existe. Essayez d'activer ou de désactiver le mode passif selon votre serveur.
### Le profil s'exécute mais aucun fichier n'est produit
Le statut « vide » signifie qu'aucun enregistrement ne correspondait aux filtres (par exemple, aucune nouvelle commande depuis le dernier passage en mode incrémental, ou un filtre de statuts trop restrictif).
### Les formats XML sont en erreur
Les presets Cegid et XML générique nécessitent l'extension PHP XMLWriter, standard sur la plupart des hébergements PrestaShop.
## Compatibilité
- PrestaShop 8.0, 8.1, 8.2 et 9.x
- PHP 7.4 à 8.3
- Multiboutique
- Extension PHP FTP requise pour le transport FTP ; XMLWriter requis pour les formats XML
---
### DF Faceted SEO — Recherche à facettes et SEO PrestaShop
_Source :_
> DF Faceted SEO transforme la recherche à facettes de PrestaShop en levier SEO durable et accélère vos pages catégorie de 10 à 30 fois grâce à un index dénormalisé. Cette…
DF Faceted SEO transforme la recherche à facettes de PrestaShop en levier SEO durable et accélère vos pages catégorie de 10 à 30 fois grâce à un index dénormalisé. Cette documentation couvre l'installation, la configuration des règles d'indexation, la création de landing pages SEO et l'exploitation des statistiques de combinaisons populaires.
## Présentation
Le module natif `ps_facetedsearch` génère mécaniquement une URL pour chaque combinaison de filtres possible. Sur un catalogue de quelques milliers de produits avec cinq facettes, cela représente des millions d'URLs que Google explore, diluant votre budget de crawl et votre PageRank entre des pages quasi identiques.
DF Faceted SEO résout ce problème en parallèle de deux manières :
- **Indexation intelligente** : des règles métier décident quelles combinaisons sont indexables, lesquelles reçoivent `noindex follow`, et où pointe le canonical.
- **Landing pages SEO dédiées** : pour vos combinaisons à fort potentiel commercial (par exemple « chaussures rouges taille 42 »), créez des pages d'atterrissage avec URL propre, H1, meta et contenus personnalisés par langue.
En bonus, le moteur de recherche du module remplace le moteur natif par un système beaucoup plus rapide basé sur un index dénormalisé et un cache deux niveaux.
## Pré-requis
- PrestaShop 8.0 à 9.x
- PHP 8.1 ou supérieur
- MySQL 5.7 ou MariaDB 10.3 minimum
- URLs simplifiées activées (_Préférences → SEO et URLs_)
- Permissions standards pour création de tables MySQL
## Installation
1. Téléversez l'archive ZIP via _Modules → Module Manager → Téléverser un module_.
2. Cliquez sur **Installer**. Le module crée automatiquement 10 tables `ps_dffacetedseo_*` et 5 onglets sous _Améliorer_.
3. Allez dans _Améliorer → DF Faceted SEO → Tableau de bord_.
4. Cliquez sur **Reconstruire l'index**. _Cette étape est obligatoire la première fois_ : sans index, le moteur de recherche du module n'a aucune donnée à exploiter.
5. Videz le cache PrestaShop : _Paramètres avancés → Performance → Vider le cache_.
Sur un catalogue de 50 000 produits, la reconstruction de l'index prend typiquement entre 2 et 5 minutes. Le module insère les lignes par lots de 500.
## Premiers pas — Tableau de bord
Le tableau de bord (_Améliorer → DF Faceted SEO_) affiche six tuiles statistiques :
- **Règles actives** : nombre de règles d'indexation activées
- **Landing pages** : nombre de pages d'atterrissage SEO créées
- **Produits dans l'index** : nombre de produits indexés (doit être proche du total catalogue)
- **Lignes dans l'index** : nombre de couples (produit, valeur de filtre) — c'est la table dénormalisée
- **Entrées en cache** : nombre de requêtes mises en cache
- **Combinaisons populaires** : nombre de combinaisons de filtres observées
Sous les tuiles, deux blocs d'opérations :
- **Reconstruire l'index** : utile après une grosse modification catalogue (import en masse, changement de structure d'attributs)
- **Vider le cache** : utile après une modification de règles ou de paramètres
## Règles d'indexation
Les règles décident, pour chaque combinaison de filtres visitée, quelle balise `robots` et quel `canonical` sont envoyés au navigateur et à Google. Une règle a un **scope** (zone d'application) et une **politique** (décision).
### Scopes disponibles
- **Global** : s'applique à toutes les pages facettées du catalogue
- **Catégorie spécifique** : s'applique uniquement aux pages d'une catégorie donnée
- **Groupe d'attributs** : s'applique aux combinaisons contenant un groupe précis (par exemple toutes les pages où Couleur est filtrée)
- **Feature** : idem, pour une caractéristique produit
- **Marque** : idem, pour une marque (manufacturer)
- **Fourchette de prix** : s'applique aux pages filtrées sur une plage tarifaire donnée
### Politiques disponibles
- **Index, follow** : page indexable, canonical pointant sur elle-même normalisée
- **Noindex, follow** : page non indexée, mais les liens sont suivis (recommandé pour les combinaisons rares)
- **Canonical parent** : page accessible mais le canonical pointe sur la catégorie parente (la valeur SEO est transférée)
- **Canonical self normalisé** : canonical sur la page elle-même avec les filtres triés et regroupés (élimine les doublons d'URL pour la même combinaison)
### Chaîne de priorité
Le module évalue les règles de la **plus spécifique à la plus générique**. Concrètement, pour une page de la catégorie Chaussures filtrée par couleur :
1. Le module cherche d'abord une règle scope `category` sur Chaussures
2. Si elle existe et matche, elle est appliquée
3. Sinon il cherche une règle scope `attribute_group` sur Couleur
4. Sinon il remonte vers la règle globale
5. Si aucune règle ne matche, la politique par défaut du tableau de bord est appliquée
### Champs avancés d'une règle
- **Maximum de filtres indexables** : si la combinaison contient plus de filtres que cette limite, la politique passe automatiquement en `noindex follow`. Exemple : 2 filtres maximum sur les chaussures (couleur + taille indexées, mais pas couleur + taille + matière + saison).
- **Whitelist de valeurs** : IDs de valeurs autorisées (séparés par virgules). Une combinaison contenant uniquement des valeurs de la whitelist est indexable. Exemple : whitelister les couleurs rouge, noir, blanc, bleu — les couleurs rares comme « vert pomme » ne seront pas indexées.
- **Blacklist de valeurs** : l'inverse. Toute combinaison contenant une valeur blacklisée tombe automatiquement en `noindex`.
- **Minimum de produits** : si la combinaison ne retourne pas au moins ce nombre de produits, elle passe en `noindex`. Évite d'indexer des pages presque vides.
- **Priorité** : entier. En cas de conflit entre deux règles du même scope, la priorité la plus haute gagne.
Stratégie recommandée pour démarrer : créez une règle _globale_ avec politique `canonical parent` et maximum 1 filtre indexable, puis ajoutez progressivement des règles plus spécifiques pour ouvrir l'indexation des combinaisons à fort potentiel.
## Landing pages SEO
Les landing pages sont des pages d'atterrissage dédiées à des combinaisons de filtres stratégiques. Elles ont leur propre URL propre, leur propre H1, leurs propres meta, et un contenu rédactionnel par langue.
### Créer une landing page
1. Allez dans _Améliorer → DF Faceted SEO → Landing pages_
2. Cliquez sur **Ajouter**
3. Section **Ciblage** : choisissez la catégorie et éventuellement la marque concernée
4. Section **Affichage** : tri par défaut, direction, activation, indexation, priorité
5. Section **Combinaison de filtres** : ajoutez les filtres qui composent la combinaison (groupe d'attributs et valeurs, feature, ou marque). Exemple : Couleur = Rouge ET Taille = 42.
6. Onglets multilingues : renseignez pour chaque langue le nom interne, le slug d'URL, le H1, le meta title, la meta description, le contenu d'intro et le contenu d'outro.
7. Sauvegardez
### Structure d'URL
L'URL d'une landing page suit le motif :
```
https://votre-domaine.com/landing/votre-slug
https://votre-domaine.com/en/landing/votre-slug
https://votre-domaine.com/fr/landing/votre-slug
```
Le préfixe de langue est automatiquement géré par le routeur PrestaShop dès que les URLs simplifiées sont activées et que plusieurs langues sont actives sur la boutique.
Si vous avez une 404 sur l'URL d'une landing, vérifiez dans cet ordre : URLs simplifiées activées, `.htaccess` régénéré (bouton Sauvegarder en bas de SEO et URLs), cache vidé, landing active dans le formulaire, hook `moduleRoutes` bien attaché au module dans _Modules → Positions_.
### Contenu rédactionnel
Pour chaque langue, vous disposez de deux blocs HTML riches :
- **Intro** : affiché au-dessus de la grille de produits. Idéal pour un paragraphe d'introduction SEO de 150 à 300 mots avec vos mots-clés cibles.
- **Outro** : affiché sous la grille. Idéal pour des éléments de réassurance, des guides d'achat, des FAQ.
### JSON-LD automatique
Chaque landing page injecte automatiquement deux blocs JSON-LD dans la page :
- **BreadcrumbList** : Accueil → Catégorie → Landing
- **Product** : un bloc Product par produit affiché (nom, prix, image, URL, disponibilité)
Vous obtenez automatiquement les rich snippets Google sans configuration supplémentaire.
## Statistiques des combinaisons populaires
Le module enregistre automatiquement, dans la table `ps_dffacetedseo_combination_log`, chaque combinaison de filtres réellement visitée par vos clients : signature, nombre de hits, dernière vue.
### Exploiter les statistiques
1. Allez dans _Améliorer → DF Faceted SEO → Statistiques_
2. Filtrez par catégorie, nombre minimum de hits, limite d'affichage
3. Triez par hits décroissants
4. Repérez les combinaisons à plus de 50 hits par semaine
5. Cliquez sur **Promouvoir** dans la colonne action
6. Le formulaire de landing page s'ouvre **pré-rempli** avec la combinaison de filtres
7. Vous n'avez plus qu'à renseigner le contenu rédactionnel et sauvegarder
### Maintenance
Le bas de la page Statistiques propose un bouton _Purger les anciennes données_ avec un champ « jours à conserver ». Recommandé : purger tous les 90 jours pour éviter une croissance illimitée de la table.
## Paramètres globaux
Le tableau de bord propose 11 paramètres globaux regroupés en 3 sections.
### Indexation
- **Politique par défaut** : politique appliquée quand aucune règle ne matche
- **Maximum de filtres indexables** : valeur globale (peut être surchargée par règle)
- **Minimum de produits par combinaison** : seuil global pour considérer une page indexable
### Performance
- **TTL du cache (secondes)** : durée de vie d'une entrée en cache. Défaut : 3600 (1 heure). Augmentez à 86400 (24 h) en production stable.
- **Masquer les filtres vides** : si activé, les valeurs avec 0 résultat sont cachées dans le panneau de filtres
- **Limite de résultats par page** : pagination produits
### URLs
- **Préfixe des URLs de landings** : par défaut `landing`. Le motif de route est défini en dur dans le hook `moduleRoutes` du module et utilise ce préfixe.
## Canonical intelligent
Sur chaque page facettée, le module calcule le canonical optimal :
- Combinaison qui matche une landing existante : canonical = URL pretty de la landing
- Combinaison indexable selon les règles : canonical = self normalisé (filtres triés et regroupés)
- Combinaison non indexable selon les règles : canonical = catégorie parente
- Page de catégorie sans filtre : canonical = self standard
La normalisation regroupe les valeurs par groupe et trie les groupes par ID. Deux URLs visuellement différentes mais sémantiquement identiques (par exemple ordre des paramètres GET différent) reçoivent le même canonical.
## Moteur de filtres haute performance
Le moteur s'appuie sur la table `ps_dffacetedseo_index` : une ligne par couple (produit, type de filtre, valeur). La recherche se transforme en une intersection d'ensembles d'identifiants produits.
### Cache deux niveaux
- **Niveau 1 : mémoire (in-process)**. Évite de retaper la même requête deux fois dans la même page.
- **Niveau 2 : base de données (table ps_dffacetedseo_cache)**. Persiste les résultats entre les requêtes avec TTL.
### Invalidation automatique
Le module écoute les hooks `actionProductSave`, `actionProductDelete` et `actionCategoryUpdate`. Chaque fois qu'un produit est sauvegardé, son entrée dans l'index est régénérée et toutes les entrées de cache liées à ce produit sont invalidées.
### AJAX et UX
Le panneau de filtres front est entièrement piloté en AJAX :
- Debounce de 250 ms sur les changements de filtres
- `pushState` pour mettre à jour l'URL sans recharger la page
- Mise à jour en temps réel des balises `canonical` et `robots` dans la tête du document
- Scroll fluide vers la grille de produits après mise à jour
- Chips actifs cliquables pour retirer un filtre individuel
- Slider de prix avec champs numériques et bouton Appliquer
- Swatches de couleur visibles sur les attributs de type Couleur
## Multiboutique et multilingue
Le module est nativement multi-boutique et multi-langue :
- Chaque landing page a des traductions par langue (table `ps_dffacetedseo_landing_page_lang`)
- Chaque landing peut être restreinte à une ou plusieurs boutiques (table `ps_dffacetedseo_landing_page_shop`)
- Les règles d'indexation s'appliquent par défaut à toutes les boutiques
- L'index est partitionné par boutique
- Les traductions de l'interface sont fournies en français et en anglais (XLIFF dans `translations/`)
## Architecture technique
### Hooks utilisés
- `displayHeader` : canonical et meta robots dynamiques
- `actionFrontControllerSetMedia` : CSS et JS frontend
- `moduleRoutes` : route propre pour les landing pages
- `displayLeftColumn` : injection du panneau de filtres
- `displayBeforeBodyClosingTag` : JSON-LD sur les landings
- `actionProductSearchProviderRunQuery` : intégration avec le moteur PS
- `actionProductSave` et `actionProductDelete` : réindexation incrémentale
- `actionCategoryUpdate` : invalidation du cache catégorie
- `displayBackOfficeHeader` : CSS et JS admin
### Tables créées
TableRôle`dffacetedseo_rule`Règles d'indexation par scope`dffacetedseo_landing_page`Landings (données métier)`dffacetedseo_landing_page_lang`Traductions des landings`dffacetedseo_landing_page_shop`Liens multi-boutique`dffacetedseo_landing_filter`Filtres associés aux landings`dffacetedseo_combination_log`Statistiques de visite`dffacetedseo_cache`Cache résultats requêtes`dffacetedseo_filter_template`Templates de filtres réutilisables`dffacetedseo_index`Index dénormalisé (clé performance)`dffacetedseo_setting`Paramètres internes
### Convention d'URL des filtres
```
?attribute_group__{id_group}=v1,v2&feature__{id_feature}=v3&manufacturer__0=5&price=10-50&s=needle
```
Une signature SHA-1 stable est calculée pour comparer les combinaisons (matching landing, clé de cache, log).
## Performance attendue
Mesures réalisées sur un catalogue de référence (50 000 produits, 8 facettes actives) :
MoteurTemps moyen`ps_facetedsearch` natif800 ms à 1,4 s par requêteDF Faceted SEO sans cache50 à 120 msDF Faceted SEO avec cachemoins de 10 ms
Gain typique : **×10 à ×30**
## FAQ technique
### Faut-il désinstaller ps_facetedsearch
Non, le module s'intègre via les hooks officiels. Vous pouvez le tester en parallèle. Une fois validé, désinstallez `ps_facetedsearch` pour éviter la duplication du panneau de filtres.
### Le module est-il compatible HTTPS et URL canoniques absolus
Oui. Le module utilise `Context::getContext()->link->getPageLink()` et `getModuleLink()` qui respectent la configuration HTTPS de PrestaShop.
### Comment ajouter une nouvelle langue côté module
Copiez le fichier `translations/fr-FR.xlf` en `translations/xx-XX.xlf` et traduisez les `trans-unit`. Aucune autre intervention nécessaire.
### Le module supporte-t-il les attributs composés (combinaisons d'attributs)
Oui. L'index dénormalisé indexe les déclinaisons via leurs attributs. Le moteur de recherche filtre sur les produits dont au moins une déclinaison correspond à tous les filtres actifs.
### Comment déboguer une règle qui ne s'applique pas
Activez les logs PrestaShop (_Paramètres avancés → Logs_) et consultez la section `dffacetedseo`. Chaque résolution de directive logge la règle matchée et la raison.
## Dépannage
### Fatal error sur un appel à `getBySlug`
Symptôme : `Call to a member function getBySlug() on false`. Cause : ancien helper `get()` qui retournait `false` au lieu de l'objet service. Corrigé en v1.0.1. Mettez à jour le module.
### 404 sur l'URL d'une landing page
Symptôme : `https://votre-site/en/landing/votre-slug` renvoie 404. Cause typique : le hook `moduleRoutes` n'est pas enregistré ou le cache de routes PrestaShop est obsolète.
1. Vérifiez que _Préférences → SEO et URLs → Activer les URL simplifiées_ est sur OUI
2. Sauvegardez cette page (régénère le `.htaccess`)
3. Videz le cache PrestaShop deux fois
4. Allez dans _Modules → Positions_, vérifiez que `dffacetedseo` est attaché à `moduleRoutes`
5. Fallback de test : `https://votre-site/index.php?fc=module&module=dffacetedseo&controller=landing&slug=votre-slug`
### Le moteur de recherche ne retourne aucun produit
L'index est probablement vide. Allez dans le tableau de bord et cliquez sur **Reconstruire l'index**.
### Les filtres ne s'affichent pas dans la colonne
Vérifiez dans _Modules → Positions_ que `dffacetedseo` est attaché au hook `displayLeftColumn`. Selon votre thème, vous pouvez également l'attacher à `displayRightColumn` ou `displayHome`.
### Performance dégradée après import massif de produits
L'invalidation incrémentale fonctionne bien pour des modifications unitaires. Après un import en masse, il est plus rapide de reconstruire l'index entier depuis le tableau de bord et de vider le cache.
## Mises à jour
Le module suit un cycle de versionnage `MAJEUR.MINEUR.PATCH`. Les correctifs critiques (sécurité, fatal errors) sont fournis sous forme de patch ; les nouvelles fonctionnalités déclenchent un bump mineur. Chaque mise à jour majeure inclut un script `upgrade/upgrade-X.Y.Z.php` qui s'exécute automatiquement à l'installation de la nouvelle version.
## Support
Pour toute question ou rapport de bug, contactez [support@datafirefly.com](mailto:support@datafirefly.com) en précisant la version PrestaShop, la version PHP, la version du module et les logs PHP/PrestaShop.
---
### DF Fitment Finder — Recherche par véhicule et compatibilité produit
_Source :_
> DF Fitment Finder ajoute à votre boutique PrestaShop une recherche par compatibilité : le client sélectionne son véhicule (ou son appareil) et le catalogue ne lui montre plus que les…
DF Fitment Finder ajoute à votre boutique PrestaShop une recherche par compatibilité : le client sélectionne son véhicule (ou son appareil) et le catalogue ne lui montre plus que les produits qui lui vont. Cette documentation couvre l'installation, la configuration, l'alimentation du référentiel véhicules et l'affichage en front.
## Installation
1. Rendez-vous dans **Modules > Gestionnaire de modules**, puis cliquez sur **Installer un module**.
2. Déposez le fichier `dffitmentfinder.zip` et lancez l'installation.
3. Cliquez sur **Configurer** pour accéder aux réglages.
L'installation crée trois tables (référentiel véhicules, correspondances produits, garages clients), enregistre les hooks nécessaires et ajoute l'onglet **Véhicules** sous le menu **Catalogue**. Aucun override du cœur n'est posé, aucune dépendance Composer n'est requise.
Compatible PrestaShop 8.0 à 9.x, PHP 7.4 à 8.3, en boutique simple comme en multiboutique.
## Configuration
### Niveaux de recherche
Le sélecteur repose sur quatre niveaux : **Marque**, **Modèle**, **Année** et **Motorisation**. Les deux premiers sont toujours actifs ; les deux derniers s'activent ou se désactivent selon votre catalogue.
- **Utiliser l'année** : à désactiver pour un catalogue sans notion d'année (cartouches d'imprimante, coques de téléphone, pièces d'électroménager).
- **Utiliser la motorisation** : à désactiver si le niveau le plus fin de votre référentiel est le modèle.
La recherche reste possible dès que la marque et le modèle sont renseignés : le client n'est jamais obligé d'aller jusqu'au niveau le plus fin.
### Libellés des niveaux
Chaque niveau porte un libellé modifiable par langue. Par défaut : Marque, Modèle, Année, Motorisation. Adaptez-les à votre secteur :
- Pièces auto : Marque / Modèle / Année / Motorisation
- Cartouches d'imprimante : Marque / Série / — / Référence
- Coques de téléphone : Marque / Modèle
- Électroménager : Fabricant / Gamme / Année / Référence
### Zones d'affichage
- **Afficher en en-tête** : le sélecteur apparaît en haut de toutes les pages.
- **Afficher en page d'accueil** : le sélecteur apparaît dans le contenu de la page d'accueil.
- **Widget** : placez le sélecteur où vous voulez dans votre thème avec le tag Smarty `{widget name='dffitmentfinder'}`.
### Fiche produit
- **Vérification de compatibilité** : affiche sous le prix un bandeau vert (le produit va sur le véhicule courant), rouge (il n'y va pas) ou neutre (aucun véhicule sélectionné).
- **Tableau de correspondances** : affiche en bas de fiche la liste complète des véhicules compatibles, groupée par marque et repliable.
### Résultats par page
Nombre de produits affichés par page sur la page de résultats. Valeur par défaut : 12.
## Alimenter le référentiel véhicules
### Saisie manuelle
Rendez-vous dans **Catalogue > Véhicules**. Le bouton **Ajouter** ouvre le formulaire d'un véhicule :
- **Marque** et **Modèle** : obligatoires.
- **Année de début** et **Année de fin** : facultatives. Laissées vides, le véhicule est considéré comme valable pour toutes les années. Renseignées, elles définissent une plage : un véhicule 2012–2019 apparaîtra pour chacune des années de la plage dans le sélecteur.
- **Motorisation** : facultative, c'est le niveau le plus fin (par exemple « 1.2 PureTech »).
- **Actif** : un véhicule inactif n'apparaît plus dans le sélecteur mais conserve ses correspondances.
### Rattacher des produits à un véhicule
Une fois le véhicule enregistré, un panneau **Produits compatibles** apparaît en bas de son formulaire. Tapez au moins deux caractères (nom ou référence) dans le champ de recherche, cliquez sur un résultat, et le produit est rattaché immédiatement. Le champ **Note**, facultatif, permet de préciser la portée de la compatibilité : « essieu avant uniquement », « boîte manuelle », « à partir du châssis n° 12000 »… Cette note s'affiche dans le tableau de correspondances en fiche produit.
### Import CSV
Pour les référentiels volumineux, l'import CSV est la voie recommandée. Le fichier attendu comporte six colonnes :
```
make;model;year_from;year_to;variant;references
```
Exemple :
```
Peugeot;208;2012;2019;1.2 PureTech;BRK-P208-F|FLT-P208
Peugeot;208;2012;2019;1.6 BlueHDi;BRK-P208-F
HP;LaserJet Pro M404;;;;TNR-59A|TNR-59X
```
- Le séparateur, point-virgule ou virgule, est détecté automatiquement.
- La colonne **references** contient les références produit compatibles, séparées par une barre verticale.
- Les colonnes d'années et de motorisation peuvent rester vides.
- Un véhicule déjà présent dans le référentiel n'est pas dupliqué : ses correspondances sont simplement complétées.
- À la fin de l'import, un rapport indique le nombre de véhicules créés, de correspondances ajoutées et de lignes en erreur.
### Export CSV
Le bouton **Exporter en CSV**, sur la page de configuration du module, télécharge l'intégralité du référentiel au même format. Pratique pour retravailler les données dans un tableur puis les réimporter.
## Le parcours client
### Sélection du véhicule
Le client choisit sa marque, puis son modèle, puis (si les niveaux sont actifs) son année et sa motorisation. Chaque menu se remplit à partir du précédent, sans rechargement de page. Le bouton **Rechercher** ouvre la page de résultats, qui affiche les produits compatibles avec les miniatures natives de votre thème.
Le véhicule sélectionné est ensuite mémorisé et rappelé sur toutes les pages, jusqu'à ce que le client en change ou l'efface.
### Mon garage
Le bouton **Ajouter à mon garage** enregistre le véhicule courant. La page **Mon garage**, accessible depuis l'espace client, liste les véhicules enregistrés et permet de :
- désigner un véhicule comme **véhicule courant** ;
- voir directement les produits compatibles avec un véhicule ;
- supprimer un véhicule du garage.
Le garage fonctionne aussi pour les visiteurs non connectés : leurs véhicules sont conservés et rattachés automatiquement à leur compte dès qu'ils se connectent ou créent un compte.
### Sur la fiche produit
Si la vérification de compatibilité est activée et qu'un véhicule courant est sélectionné, un bandeau apparaît sous le prix : vert si le produit est compatible, rouge sinon. En l'absence de véhicule sélectionné, un message neutre invite le client à en choisir un.
Si le tableau de correspondances est activé, la fiche affiche en bas la liste complète des véhicules compatibles, groupée par marque et repliable, avec la note éventuelle de chaque correspondance.
## Questions fréquentes
### Puis-je utiliser le module sans notion de véhicule ?
Oui. Désactivez les niveaux Année et Motorisation, renommez les libellés, et le module devient un sélecteur Marque / Série adapté aux cartouches, aux coques, aux pièces d'électroménager ou à tout catalogue où la compatibilité conditionne l'achat.
### Que devient une correspondance quand je supprime un produit ?
Elle est supprimée automatiquement. Le référentiel ne conserve pas de lignes orphelines.
### Le sélecteur ralentit-il mon site ?
Non. Les menus sont remplis en AJAX à la demande, en JavaScript natif et sans dépendance jQuery : seule la liste des marques est chargée au premier affichage.
### Le module est-il compatible multiboutique ?
Oui. Les correspondances produit et les garages clients respectent le contexte boutique.
---
### DF Glossary — Glossaire SEO pour PrestaShop 8 & 9
_Source :_
> Présentation DF Glossary transforme votre vocabulaire métier en actif SEO. Vous saisissez vos termes une seule fois — avec une définition courte et une définition longue — et le module…
## Présentation
DF Glossary transforme votre vocabulaire métier en actif SEO. Vous saisissez vos termes une seule fois — avec une définition courte et une définition longue — et le module fait trois choses automatiquement : il injecte un lien avec infobulle sur chaque occurrence du terme dans vos descriptions produits, catégories et pages CMS ; il publie une page de définition indexable par terme ; et il relie chaque définition aux produits que vous lui associez.
Le résultat est un maillage interne bidirectionnel qui se construit sans effort éditorial : vos fiches renforcent vos définitions, vos définitions renforcent vos produits, et vos définitions se renforcent entre elles.
**Aucune IA, aucune API.** Tout le traitement est effectué en PHP, côté serveur. Il n'y a pas de clé API à fournir, aucun coût récurrent, aucune donnée de votre catalogue ne quitte votre serveur, et le rendu est parfaitement compatible avec le cache full-page.
## Installation
### Prérequis
- PrestaShop 8.0, 8.1, 8.2 ou 9.x
- PHP 7.4 à 8.3
- MySQL 5.7 / MariaDB 10.3 ou supérieur
- URLs simplifiées activées (Paramètres de la boutique, Trafic et SEO) — indispensable pour les pages du glossaire
### Procédure
1. Dans le back-office, allez dans **Modules → Gestionnaire de modules → Installer un module**.
2. Uploadez le fichier `dfglossary-1.0.0.zip`.
3. L'installation crée quatre tables SQL, un onglet de back-office et les clés de configuration par défaut.
4. Un nouvel onglet **Catalogue → Glossaire SEO** apparaît dans le menu. C'est là que vous gérez vos termes.
5. Cliquez sur **Configurer** depuis le gestionnaire de modules pour accéder aux réglages globaux.
Après l'installation, vérifiez que les URLs simplifiées sont bien actives. Sans elles, les pages du glossaire restent accessibles mais avec des URLs techniques peu adaptées au référencement.
## Configuration du module
Le panneau de configuration se divise en trois sections.
### Activation et mode d'injection
- **Activer l'injection** — interrupteur maître. Désactivé, le module cesse d'enrichir vos contenus, mais les pages du glossaire restent en ligne et indexées.
- **Mode** — trois valeurs possibles : _Lien + infobulle_ (par défaut) : le terme devient un lien vers sa page de définition et affiche l'infobulle au survol. C'est le mode qui combine bénéfice SEO et bénéfice conversion.
- _Lien seul_ : le terme devient un lien, sans infobulle. À privilégier si vous ne visez que le maillage interne.
- _Infobulle seule_ : le terme affiche la définition au survol, sans devenir un lien. À privilégier si vous voulez de la pédagogie sans ajouter de liens sortants dans vos fiches produits.
### Limites (garde-fous anti-suroptimisation)
- **Occurrences maximum par terme** — 1 par défaut. Même si un mot apparaît huit fois dans une description, seule la première occurrence devient un lien. Nous recommandons fortement de conserver cette valeur : un seul lien par notion suffit à transmettre le signal sémantique, et les suivants diluent le PageRank interne sans rien apporter.
- **Liens maximum par contenu** — 10 par défaut, tous termes confondus. Au-delà, le moteur s'arrête, quels que soient les termes restants.
### Contenus ciblés
Quatre interrupteurs indépendants déterminent où l'injection s'applique :
- **Descriptions produits** — la description longue.
- **Inclure la description courte** — option distincte. Attention : la description courte s'affiche souvent en haut de fiche et dans les listings ; y placer des liens peut être excessif.
- **Descriptions de catégories** — description et description additionnelle.
- **Pages CMS et catégories CMS** — contenu des pages CMS.
### Base d'URL
Le champ **Base d'URL** définit le segment sous lequel les pages du glossaire sont publiées. Valeur par défaut : `glossaire`, ce qui donne `/glossaire` pour l'index et `/glossaire/toile-enduite` pour une fiche de terme. Le champ est validé comme une réécriture de lien : uniquement des lettres, chiffres et tirets.
Si vous changez la base d'URL après avoir laissé les pages s'indexer, toutes les URLs du glossaire changent d'un coup. Prévoyez des redirections 301 depuis les anciennes URLs, ou fixez la base d'URL une bonne fois au moment de l'installation.
## Gérer les termes
Rendez-vous dans **Catalogue → Glossaire SEO**. La liste affiche tous vos termes avec leur slug, leur état d'auto-liaison et leur statut. Vous pouvez rechercher, trier, filtrer, activer ou désactiver en un clic, et supprimer en masse.
### Créer un terme
Cliquez sur **Ajouter un terme**. Le formulaire est entièrement multilingue : chaque champ texte se saisit langue par langue.
- **Terme** — le libellé exact recherché dans vos contenus. La correspondance est insensible à la casse et respecte les frontières de mots.
- **Slug** — l'identifiant dans l'URL. Laissez vide pour qu'il soit généré automatiquement à partir du nom.
- **Synonymes** — liste séparée par des virgules. Pluriels, abréviations, variantes orthographiques : toutes ces formes déclenchent le même lien et la même infobulle.
- **Définition courte** — c'est le texte de l'infobulle. Texte brut recommandé. Elle est tronquée à 180 caractères dans la bulle, mais s'affiche en entier en tête de la page de définition.
- **Définition longue** — éditeur riche. C'est le corps de la page de définition, et le contenu qui va se positionner dans Google.
- **Meta title / Meta description** — optionnels. En leur absence, le module se rabat automatiquement sur le nom du terme et la définition courte.
- **Produits associés** — liste d'IDs produits séparés par des virgules. Leurs vignettes s'afficheront sur la page du terme.
- **Auto-liaison** — interrupteur individuel. Désactivé, le terme conserve sa page de définition indexée mais n'est jamais injecté dans les contenus.
- **Actif** — désactivé, le terme disparaît du glossaire et sa page renvoie une 404 propre.
### Bonnes pratiques éditoriales
- **Visez 20 à 50 termes.** Le volume n'est pas la variable importante : un terme mérite sa place s'il apparaît réellement dans vos descriptions et s'il correspond à une question que vos clients se posent.
- **Rédigez des définitions longues de 150 à 400 mots.** Assez pour constituer un contenu autonome aux yeux de Google, assez court pour être produit rapidement.
- **Associez 2 à 6 produits par terme**, pas davantage. Une page de définition qui pointe vers vingt produits dilue son autorité.
- **Soignez les synonymes.** C'est le levier qui multiplie la couverture : un catalogue rédigé sur plusieurs années par plusieurs personnes exprime rarement un même concept d'une seule façon.
- **Ne traduisez pas les synonymes mot à mot.** Chaque langue a ses propres variantes ; saisissez-les indépendamment.
## Comment fonctionne l'injection
L'enrichissement s'effectue côté serveur, au moment du rendu de la page, via les hooks de filtrage de contenu de PrestaShop. Vos descriptions ne sont jamais modifiées en base de données : si vous désactivez le module, vos contenus retrouvent immédiatement leur état d'origine.
### Le moteur de remplacement
Le contenu est découpé en segments balises et segments texte. Seuls les segments texte sont candidats au remplacement. Les zones suivantes sont systématiquement ignorées :
- liens existants (aucun risque de créer un lien imbriqué),
- titres h1, h2 et h3,
- blocs script, style, code, pre, svg, noscript,
- champs de formulaire : textarea, select, option, button,
- iframes.
Sur les segments autorisés, la recherche utilise des frontières de mots Unicode : impossible de transformer un fragment situé à l'intérieur d'un mot ou d'un identifiant. La correspondance ignore la casse et tolère les espaces multiples ou les retours à la ligne. Enfin, chaque lien injecté est temporairement remplacé par un jeton unique le temps du traitement — un terme ne peut donc jamais être re-lié à l'intérieur d'un lien que le module vient lui-même de créer.
### Ordre de priorité des variantes
Toutes les variantes d'un terme (nom principal et synonymes) sont fusionnées puis triées par longueur décroissante. L'expression la plus longue gagne toujours. Concrètement, si _toile enduite PVC_ et _toile enduite_ figurent tous deux dans vos synonymes, c'est le premier qui sera lié lorsqu'il apparaît en entier.
## Les pages du glossaire
### Page d'index
Accessible à `/glossaire`, elle liste tous les termes actifs, groupés par lettre, avec une navigation alphabétique et un extrait par terme. Elle émet un JSON-LD de type **DefinedTermSet**.
### Page de définition
Accessible à `/glossaire/{slug}`, chaque fiche comporte :
- un titre H1 et la définition courte mise en avant,
- la définition longue au format riche, dans laquelle les autres termes du glossaire sont automatiquement liés à leur tour (le terme courant est exclu, pas d'auto-lien),
- les vignettes des produits associés,
- un nuage de termes connexes,
- meta title et meta description dédiés, URL canonique, fil d'Ariane,
- un JSON-LD de type **DefinedTerm**.
Si un slug n'existe pas ou si le terme est désactivé, la page renvoie une 404 propre.
**Pourquoi ce balisage compte.** DefinedTerm et DefinedTermSet indiquent au moteur non seulement de quoi parle la page, mais quelle fonction elle occupe dans l'architecture du site. À l'ère des réponses génératives (AI Overviews, ChatGPT, Perplexity), les contenus définitionnels correctement balisés sont surreprésentés dans les citations.
## Multilingue et multi-boutique
Tous les champs texte du glossaire sont multilingues : nom, synonymes, définitions, slug, meta title et meta description peuvent différer dans chaque langue. Le matching s'effectue toujours dans la langue du contexte courant : une description française ne sera jamais enrichie avec des termes anglais.
Côté multi-boutique, les termes sont rattachés aux boutiques via la table d'association standard de PrestaShop. Vous pouvez donc avoir un glossaire technique dense sur une boutique B2B et un glossaire vulgarisé sur une boutique B2C, dans la même installation.
## Comportement sur mobile
Il n'y a pas de survol sur un écran tactile. Le module charge un mini-script qui gère le tap : le premier tap sur un terme affiche l'infobulle et bloque la navigation, le second tap ouvre la page de définition. Les autres infobulles ouvertes se referment automatiquement, et un tap en dehors du terme ferme la bulle.
## Performance
Le dictionnaire des termes est chargé une seule fois par requête et mis en cache statique : même une page catégorie affichant trente produits ne déclenche qu'une seule requête SQL pour le glossaire. Le remplacement lui-même est une manipulation de chaîne en PHP, de l'ordre de la milliseconde. Aucun JavaScript bloquant n'est chargé, aucun appel réseau n'est effectué, et le résultat est parfaitement compatible avec le cache full-page.
## Dépannage
### Aucun lien n'apparaît dans mes fiches produits
- Vérifiez que l'interrupteur maître **Activer l'injection** est bien sur Oui.
- Vérifiez que **Descriptions produits** est activé dans les contenus ciblés.
- Vérifiez que le terme est **actif** et que son **auto-liaison** est activée.
- Vérifiez que le terme est bien renseigné **dans la langue de la fiche consultée** — un terme saisi uniquement en français ne sera jamais injecté dans une description anglaise.
- Videz le cache PrestaShop (Paramètres avancés → Performances).
### Le terme apparaît dans le texte mais n'est pas lié
Trois causes possibles. Soit le terme est déjà à l'intérieur d'un lien, d'un titre h1–h3 ou d'une zone protégée — c'est le comportement voulu. Soit la limite d'occurrences par terme (1 par défaut) est déjà atteinte pour ce contenu : les occurrences suivantes restent en texte brut, c'est normal. Soit la limite globale de 10 liens par contenu est atteinte.
### Les pages du glossaire renvoient une 404
- Vérifiez que les URLs simplifiées sont activées.
- Régénérez le fichier .htaccess (Paramètres de la boutique → Trafic et SEO → Générer le fichier .htaccess).
- Vérifiez que le terme est actif et que son slug est bien renseigné dans la langue consultée.
### Les infobulles ne s'affichent pas
Vérifiez que le mode n'est pas réglé sur _Lien seul_. Si le mode est correct, videz le cache et vérifiez que la feuille de style du module est bien chargée (elle est ajoutée automatiquement sur toutes les pages du front).
## Désinstallation
La désinstallation supprime les quatre tables SQL du module, l'onglet de back-office et l'ensemble des clés de configuration. Vos termes sont donc définitivement perdus — exportez-les si vous comptez réinstaller plus tard. En revanche, aucune description produit, catégorie ou CMS n'a jamais été modifiée en base : vos contenus retrouvent simplement leur état d'origine, sans aucun nettoyage à effectuer.
## Limites connues
- L'unicité des slugs n'est pas forcée par langue. Si deux termes partagent le même slug dans la même langue, le premier trouvé gagne. Vérifiez vos slugs à la saisie.
- Les zones protégées (liens, titres h1–h3, code, formulaires) ne sont jamais enrichies. C'est un choix de conception, pas une limitation contournable.
---
### DF Product Q&A — Questions/Réponses produit pour PrestaShop 8 & 9
_Source :_
> Présentation DF Product Q&A ajoute un bloc Questions/Réponses sous vos fiches produit. Les visiteurs posent leurs questions depuis un formulaire public, vous les modérez en back-office, vous y répondez officiellement,…
## Présentation
DF Product Q&A ajoute un bloc Questions/Réponses sous vos fiches produit. Les visiteurs posent leurs questions depuis un formulaire public, vous les modérez en back-office, vous y répondez officiellement, et la communauté peut également apporter ses réponses. L'ensemble est exposé en données structurées JSON-LD QAPage pour permettre à Google d'afficher un accordéon de questions sous votre résultat de recherche.
Le module ne dépend d'aucune bibliothèque externe : ni Composer, ni jQuery. Le CSS et le JavaScript ne sont chargés que sur les pages produit.
## Installation
### Depuis le back-office
1. Rendez-vous dans **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez l'archive `dfproductqa-1.0.0.zip`.
3. Cliquez sur **Configurer** une fois l'installation terminée.
### Par FTP
1. Décompressez l'archive et téléversez le dossier `dfproductqa` dans le répertoire `/modules/` de votre boutique.
2. Dans **Modules > Gestionnaire de modules**, recherchez « DF Product Q&A » et cliquez sur **Installer**.
À l'installation, le module crée deux tables dédiées, enregistre ses hooks et ajoute un onglet **Q&R Produits** sous le menu **Catalogue**.
## Configuration
Toutes les options se règlent depuis la page de configuration du module. Un bandeau d'avertissement y indique en permanence le nombre de questions et de réponses en attente de modération, avec un lien direct vers l'onglet dédié.
### Modération des questions
- **Approuver automatiquement les nouvelles questions** — désactivé par défaut. Tant qu'il est désactivé, aucune question n'apparaît sur la boutique avant votre approbation.
- **Seuls les clients connectés peuvent poser une question** — désactivé par défaut. Les visiteurs invités peuvent poser une question en fournissant un nom et une adresse e-mail.
### Réponses de la communauté
- **Autoriser les réponses de la communauté** — activé par défaut. Les visiteurs peuvent répondre aux questions déjà approuvées.
- **Modérer les réponses de la communauté** — activé par défaut. Ce réglage est indépendant de celui des questions. Les réponses du marchand ne passent jamais par la modération : elles sont publiées immédiatement.
- **Activer les votes « Utile » sur les réponses** — activé par défaut. Le compteur de votes alimente le champ `upvoteCount` des données structurées.
### Affichage et SEO
- **Nombre de questions affichées par produit** — 5 par défaut. Au-delà, un bouton « Voir plus de questions » révèle le reste du fil.
- **Injecter les données structurées QAPage** — activé par défaut.
- **Afficher la case de consentement RGPD aux invités** — activé par défaut.
### Notifications par e-mail
- **Prévenir le marchand à chaque nouvelle question** — activé par défaut.
- **Adresse e-mail de notification** — laissez vide pour utiliser l'adresse de la boutique.
- **Prévenir le client quand sa question reçoit une réponse** — activé par défaut. L'e-mail est envoyé lorsqu'une réponse du marchand est publiée sur une question approuvée. Si vous répondez à une question encore en attente, l'e-mail partira au moment de son approbation.
## Utilisation en front-office
Le bloc s'affiche sous la fiche produit, via le hook `displayFooterProduct`. Il comporte trois zones.
### Poser une question
Un bouton « Poser une question sur ce produit » déplie le formulaire. Pour un client connecté, le nom est prérempli sous la forme « Prénom N. » et l'adresse e-mail est reprise du compte. Pour un visiteur invité, le nom et l'adresse e-mail sont demandés ; l'adresse n'est jamais affichée publiquement. L'envoi se fait en AJAX, sans rechargement de la page.
### Consulter les réponses
Chaque question affiche ses réponses approuvées, triées automatiquement : la réponse du marchand d'abord, mise en avant sur fond vert avec le libellé « Réponse officielle », puis les réponses de la communauté classées par nombre de votes décroissant. Un bouton « Utile » permet de voter ; le double vote depuis un même navigateur est bloqué.
### Répondre à une question
Si les réponses de la communauté sont activées, un lien « Répondre à cette question » apparaît sous chaque fil. La réponse est soumise à modération ou publiée immédiatement selon votre réglage.
## Modération en back-office
L'onglet **Catalogue > Q&R Produits** liste toutes les questions avec leur produit, leur auteur, leur nombre de réponses, leur statut et leur date. Les filtres et le tri fonctionnent sur chaque colonne.
### Actions groupées
Sélectionnez plusieurs questions pour les **approuver**, les **rejeter** ou les **supprimer** en une opération. La suppression d'une question entraîne celle de toutes ses réponses.
### Vue détaillée
Le bouton « Voir » ouvre le détail d'une question. Vous y trouvez :
- le produit concerné, avec un lien vers sa fiche en back-office et en boutique ;
- l'auteur et son adresse e-mail, cliquable ;
- deux boutons pour approuver ou rejeter la question ;
- le tableau de toutes ses réponses, marchand et communauté confondues, avec leur statut, leur nombre de votes et des actions unitaires d'approbation, de rejet et de suppression ;
- un champ de réponse marchand.
### Répondre en tant que marchand
Saisissez votre réponse dans le champ prévu, puis cliquez sur **Publier la réponse**. Elle est publiée immédiatement, signée du nom de votre boutique et marquée « Réponse officielle ». Si la question est encore en attente, une case cochée par défaut l'approuve en même temps, ce qui rend le fil visible d'un seul geste. Le client est alors prévenu par e-mail.
## Données structurées QAPage
Sur toute fiche produit possédant au moins une question approuvée, le module injecte dans l'en-tête un bloc JSON-LD de type `QAPage`. La structure produite est la suivante :
- chaque question devient une entité `Question` avec son `name`, son `text`, son `answerCount`, sa `dateCreated` et son `author` ;
- la réponse du marchand devient l'`acceptedAnswer`, avec un auteur de type `Organization` ;
- les réponses de la communauté deviennent des `suggestedAnswer`, avec un auteur de type `Person` ;
- chaque réponse porte son `upvoteCount`, alimenté par les votes « Utile », et une `url` pointant vers son ancre sur la fiche produit.
Après avoir approuvé vos premières questions, validez une fiche produit dans le test des résultats enrichis de Google, puis demandez une réindexation depuis la Search Console. L'affichage effectif de l'accordéon reste à la discrétion de Google.
## Anti-spam et RGPD
### Protections intégrées
- **Honeypot** : un champ invisible pour l'utilisateur est présent dans le formulaire. Les robots qui remplissent tous les champs sont écartés silencieusement.
- **Anti-flood** : un même auteur ne peut pas envoyer plusieurs questions coup sur coup.
- **Modération** : le filtre final, activé par défaut.
- **Connexion obligatoire** : option la plus stricte, à activer si le spam persiste.
### Données personnelles
Le module collecte le nom et l'adresse e-mail des visiteurs invités. L'adresse n'est jamais affichée publiquement : elle sert uniquement à envoyer la notification de réponse. La case de consentement RGPD, affichée aux invités, est activée par défaut. Les questions et réponses d'un produit supprimé sont effacées automatiquement.
## Compatibilité technique
- **PrestaShop** : 8.0 à 9.x
- **PHP** : 7.4 à 8.3
- **Multiboutique** : oui, les questions sont cloisonnées par boutique
- **Hooks utilisés** : `displayHeader`, `displayFooterProduct`, `actionProductDelete`
- **Langues** : FR, EN, ES, DE, IT
## Résolution des problèmes
### Le bloc n'apparaît pas sur la fiche produit
Vérifiez que le module est bien greffé sur le hook `displayFooterProduct` depuis **Design > Positions**. Certains thèmes personnalisés n'appellent pas ce hook : dans ce cas, ajoutez son appel dans le template produit de votre thème.
### Les questions envoyées n'apparaissent pas
C'est le comportement attendu : la modération est activée par défaut. Rendez-vous dans **Catalogue > Q&R Produits** et approuvez la question. Pour publier sans modération, activez l'auto-approbation dans la configuration.
### Le JSON-LD n'est pas présent dans la page
Le bloc n'est injecté que si la fiche possède au moins une question **approuvée** et si l'option correspondante est activée. Videz ensuite le cache de PrestaShop.
### Le client ne reçoit pas l'e-mail de réponse
Vérifiez que l'option de notification client est activée et que la question porte bien une adresse e-mail (les clients connectés utilisent celle de leur compte). L'e-mail n'est envoyé qu'une fois par question, sur publication d'une réponse marchand, et uniquement si la question est approuvée.
---
### DF Product Story — Blocs storytelling fiche produit
_Source :_
> Présentation DF Product Story ajoute des sections storytelling riches sur vos fiches produit PrestaShop 8 et 9 : blocs image + texte alterné, vidéo click-to-play, tableau comparatif, grille d'icônes bénéfices…
## Présentation
DF Product Story ajoute des sections storytelling riches sur vos fiches produit PrestaShop 8 et 9 : blocs image + texte alterné, vidéo click-to-play, tableau comparatif, grille d'icônes bénéfices et texte libre. Les stories se composent dans un builder drag & drop en back-office puis s'affichent automatiquement sur les produits ou catégories que vous ciblez — sous la description ou dans un onglet dédié.
Une story assignée à une catégorie couvre automatiquement tous ses produits. Les assignations produit directes restent prioritaires : idéal pour donner un contenu spécifique à vos best-sellers.
## Installation
1. Dans votre back-office PrestaShop, allez dans **Modules > Gestionnaire de modules > Installer un module**.
2. Téléversez le fichier `dfproductstory-1.1.0.zip`.
3. Cliquez sur **Installer**. Le module crée ses tables, son onglet d'administration et les titres d'onglet par défaut en FR/EN/ES/DE/IT.
Après installation, deux entrées sont disponibles : la page de configuration du module (Modules > DF Product Story > Configurer) et le gestionnaire de stories sous **Catalogue > DF Product Story**.
## Configuration générale
La page de configuration du module contient quatre réglages :
- **Emplacement d'affichage** : « Sous le contenu produit » (hook displayFooterProduct, par défaut) ou « Onglet produit supplémentaire » (hook displayProductExtraContent, à côté de la description).
- **Titre de l'onglet** : libellé multilingue utilisé uniquement en mode onglet. Des valeurs par défaut sont fournies dans les cinq langues.
- **Lazy-load des vidéos** : activé par défaut. Remplace les iframes YouTube/Vimeo par une façade click-to-play légère — fortement recommandé pour les Core Web Vitals.
- **Charger Font Awesome (CDN)** : désactivé par défaut. Charge Font Awesome 6 sur les fiches produit pour utiliser des classes comme « fa-solid fa-star » dans les icônes bénéfices. Inutile si votre thème inclut déjà Font Awesome.
## Créer une story
1. Allez dans **Catalogue > DF Product Story** puis cliquez sur **Ajouter une story**.
2. Renseignez le **nom interne** (jamais affiché en front), la **priorité** (plus le chiffre est bas, plus la story s'affiche haut quand plusieurs se cumulent) et le statut **Actif**.
3. Ajoutez vos blocs via les boutons **+ Ajouter un bloc**, remplissez-les, puis cliquez sur **Enregistrer la story**.
L'enregistrement se fait en AJAX : vous restez sur la page et pouvez enchaîner les modifications. Un toast confirme chaque sauvegarde.
## Les 5 types de blocs
### Image + texte
Le bloc signature du storytelling : une image d'un côté, un titre et un texte de l'autre. Choisissez la position de l'image (gauche ou droite) et alternez les blocs pour créer un rythme visuel en zigzag. L'image s'uploade directement depuis le builder (jpg, png, webp, gif — 4 Mo max). Le champ texte accepte le HTML.
### Vidéo
Trois sources possibles : **YouTube** (collez n'importe quelle URL watch, embed, shorts ou youtu.be), **Vimeo** ou **MP4 direct** (URL complète du fichier). Avec le lazy-load activé, YouTube et Vimeo s'affichent en façade click-to-play avec miniature — l'iframe n'est chargée qu'au clic, via youtube-nocookie.com et le paramètre dnt=1 de Vimeo. Le champ légende s'affiche sous la vidéo.
### Tableau comparatif
Ajoutez autant de colonnes et de lignes que nécessaire avec les boutons + Colonne / + Ligne. Le réglage **Colonne mise en avant** applique un surlignage bleu à la colonne de votre choix — pratique pour orienter vers votre gamme phare. Le tableau défile horizontalement sur mobile.
### Icônes bénéfices
Une grille de 2 à 4 colonnes d'arguments clés. Chaque item comporte une icône (un emoji, une classe Font Awesome comme « fa-solid fa-star » ou le chemin d'une image uploadée), un titre et un texte. Les items se réordonnent avec les flèches.
### Texte
Un titre et un contenu HTML libre, pour les sections narratives longues ou tout besoin non couvert par les autres blocs.
## Organiser les blocs
- **Drag & drop** : saisissez la poignée ⋮⋮ d'un bloc et déposez-le sur sa nouvelle position.
- **Flèches** ↑ ↓ : alternative clavier/souris au drag & drop.
- **Dupliquer** : copie le bloc avec tous ses réglages et contenus dans toutes les langues.
- **Supprimer** : demande confirmation avant de retirer le bloc.
## Traduire le contenu
En haut du panneau des blocs, des onglets affichent chaque langue active de votre boutique (FR, EN, ES…). Cliquez sur un onglet pour basculer tous les éditeurs dans cette langue : titres, textes, colonnes de tableau et items de bénéfices se traduisent indépendamment. Les réglages structurels (position d'image, source vidéo, nombre de colonnes) sont partagés entre toutes les langues.
Pensez à enregistrer avant de quitter la page : les contenus saisis dans toutes les langues sont envoyés en une seule sauvegarde.
## Cibler produits et catégories
Le panneau Ciblage fonctionne en deux niveaux :
- **Produits ciblés** : recherchez par nom, référence ou ID, puis cliquez sur un résultat pour l'ajouter en chip. Si au moins un produit est sélectionné, la story ne s'affiche que sur ces produits.
- **Catégories (fallback)** : cochez des catégories dans l'arbre. La story s'affiche sur tous les produits appartenant à ces catégories, sauf si une story produit directe existe déjà pour eux.
Quand plusieurs stories correspondent à un même produit, elles s'affichent toutes, triées par priorité croissante.
## Multiboutique
En contexte multiboutique, une story créée depuis le contexte « Toutes les boutiques » est visible sur tout le réseau. Une story créée depuis une boutique précise est limitée à cette boutique.
## Performance et RGPD
- Les CSS et JS front ne sont chargés que sur les fiches produit.
- Les images des blocs utilisent le lazy loading natif du navigateur.
- Les vidéos en façade click-to-play ne chargent aucun script tiers avant le clic du visiteur, via youtube-nocookie.com et Vimeo dnt=1 — aucun cookie tiers déposé au chargement de la page.
- Le CSS front est neutre et hérite de la typographie de votre thème.
## Désinstallation
La désinstallation supprime les tables du module, les stories et blocs, les assignations, l'onglet d'administration et les valeurs de configuration. Les images uploadées dans le dossier du module sont également retirées avec celui-ci.
## FAQ / Dépannage
### La story ne s'affiche pas sur le front
- Vérifiez que la story est **active** et qu'elle contient au moins un bloc avec du contenu dans la langue consultée.
- Vérifiez le ciblage : si des produits sont sélectionnés, la story n'apparaît que sur eux ; sinon elle suit les catégories cochées.
- En mode onglet, certains thèmes fortement personnalisés n'implémentent pas displayProductExtraContent : basculez sur « Sous le contenu produit ».
### La vidéo YouTube n'apparaît pas
Vérifiez que l'URL contient bien un identifiant de vidéo valide (formats watch?v=, youtu.be/, embed/ ou shorts/ acceptés). Les playlists seules ne sont pas supportées.
### L'upload d'image échoue
Formats acceptés : jpg, jpeg, png, webp, gif, taille maximale 4 Mo. Vérifiez aussi que le dossier du module est accessible en écriture par le serveur web.
---
### DF Quantity Tiers — Documentation
_Source :_
> Présentation et prérequis DF Quantity Tiers transforme les remises par quantité natives de PrestaShop en un bloc de vente clair et cliquable. Le module n'introduit aucune nouvelle logique de prix…
## Présentation et prérequis
DF Quantity Tiers transforme les remises par quantité natives de PrestaShop en un bloc de vente clair et cliquable. Le module n'introduit aucune nouvelle logique de prix : il lit les prix spécifiques « à partir de N unités » déjà configurés dans votre catalogue et les met en scène sous forme de cartes ou de tableau, avec un bouton d'ajout au panier pour chaque palier.
- Compatible PrestaShop 8.0 à 9.x, thème Classic et thèmes dérivés.
- PHP 7.4 à 8.3.
- Multiboutique et multilingue (FR/EN/ES/DE/IT).
- Aucune surcharge de fichiers : uniquement des hooks natifs.
Les paliers proviennent de **Catalogue > Produit > Prix > Prix spécifiques**, champ « À partir de la quantité ». Si un produit n'a pas de prix spécifiques par quantité, le bloc ne s'affiche pas pour ce produit.
## Installation
Installez le module comme n'importe quel module PrestaShop :
1. Téléchargez l'archive `dfquantitytiers-1.1.0.zip` depuis votre compte client.
2. Dans le back-office, allez dans **Modules > Gestionnaire de modules**.
3. Cliquez sur **Installer un module** et déposez l'archive.
4. Une fois installé, cliquez sur **Configurer**.
À l'installation, le module enregistre ses hooks, crée sa table de statistiques et pré-remplit un titre de bloc traduit dans les cinq langues. Vos prix dégressifs existants s'affichent immédiatement sur les fiches produit concernées.
## Mise à jour depuis la 1.0.0
La mise à jour vers la 1.1.0 s'effectue normalement depuis le Gestionnaire de modules. Le script d'upgrade intégré crée la table de statistiques, enregistre le nouveau hook de page panier et applique les valeurs par défaut des nouvelles options (mode fiscal, JSON-LD, nudge panier, statistiques, libellés de conditionnement). Aucune action manuelle n'est nécessaire et votre configuration existante est conservée.
## Configuration générale
La page de configuration regroupe l'ensemble des réglages d'affichage :
- **Titre du bloc** : texte affiché au-dessus des paliers, traduisible par langue.
- **Disposition** : « Cartes » (recommandé, une carte par palier) ou « Tableau compact » (une ligne par palier).
- **Position sur la fiche produit** : sous le bloc d'achat (hook `displayProductAdditionalInfo`, par défaut) ou directement sous le prix (hook `displayProductPriceBlock`).
- **Couleur d'accent** : appliquée au palier « Meilleure offre », aux badges et aux boutons.
- **Affichage de l'économie** : en pourcentage, en montant, ou les deux.
- **Afficher le prix total du palier** : ajoute le total pour la quantité du palier.
- **Afficher le palier « à l'unité »** : affiche le prix de base comme premier palier de comparaison.
Le palier offrant la remise unitaire la plus forte reçoit automatiquement le badge « Meilleure offre ». Quand le client modifie la quantité, la carte correspondant à son choix est surlignée en temps réel.
## Mode fiscal (B2B)
Le mode fiscal détermine si les prix des paliers sont affichés hors taxes ou toutes taxes comprises :
- **Automatique** : suit le réglage d'affichage du groupe client courant (comportement standard PrestaShop).
- **Forcer HT** : affiche systématiquement les prix hors taxes, avec la mention « HT » à côté de chaque prix unitaire. Idéal pour une boutique professionnelle.
- **Forcer TTC** : affiche systématiquement les prix toutes taxes comprises, avec la mention « TTC ».
Le mode choisi s'applique à la fois aux cartes de la fiche produit et au bloc de relance du panier.
## Libellés de conditionnement
Vous pouvez associer un libellé métier à chaque quantité, par exemple « carton » ou « palette ». Dans le champ **Libellés de conditionnement**, saisissez une association par ligne au format `quantité=libellé` :
```
12=Carton de 12
48=Demi-palette
96=Palette
```
Le libellé s'affiche sous la quantité du palier correspondant. Ce champ est traduisible : renseignez-le dans chaque langue depuis le sélecteur de langue du formulaire.
## Relance vers le palier suivant
Deux mécanismes d'encouragement sont disponibles, activables indépendamment.
### Sur la fiche produit
Une barre de progression affiche un message du type « Ajoutez encore 3 unité(s) pour économiser 15 % », recalculé en temps réel selon la quantité saisie. Lorsque le client atteint le palier le plus avantageux, le message bascule sur « Vous bénéficiez de la meilleure remise ! ».
### Sur la page panier
Pour chaque produit du panier dont un palier supérieur reste atteignable, le module affiche sous le panier un bloc « Ajoutez encore N unités pour passer à X € / unité », accompagné d'un bouton d'ajout en un clic. Le bouton utilise le mécanisme natif de mise à jour du panier de PrestaShop, puis rafraîchit la page. Si aucun palier supérieur n'est atteignable, aucun bloc n'est affiché.
## Données structurées (JSON-LD)
Lorsque l'option est activée, le module ajoute sur la fiche produit un balisage JSON-LD de type `AggregateOffer`, avec une offre par palier et la quantité éligible associée. Cela permet aux moteurs de recherche de comprendre vos fourchettes de prix par quantité.
Si votre thème ou un autre module SEO génère déjà un balisage `Offer` complet pour vos produits, désactivez cette option afin d'éviter un balisage en double signalé dans la Search Console.
## Statistiques de clics par palier
Quand l'option est activée, chaque clic sur un bouton d'ajout par palier est enregistré de façon anonyme : produit, déclinaison, quantité et remise du palier cliqué. Aucune donnée personnelle ni cookie n'est utilisé, ce qui rend la fonction conforme au RGPD.
La page de configuration affiche un tableau de bord des 30 derniers jours : nombre total de clics et top des combinaisons produit / palier / remise les plus cliquées. Ces données vous aident à calibrer vos remises en identifiant les paliers qui déclenchent réellement des ajouts au panier.
## FAQ et dépannage
### Le bloc ne s'affiche pas sur un produit
Vérifiez que le produit possède bien des prix spécifiques avec une quantité de départ supérieure à 1, et que ces prix s'appliquent au groupe client, à la devise et au pays courants. Le palier de base seul ne déclenche pas l'affichage s'il n'existe aucun palier de remise.
### Le bouton d'ajout ne fonctionne pas avec mon thème
Le module s'appuie sur le bouton d'ajout au panier standard du thème Classic. Sur un thème fortement personnalisé, assurez-vous que le champ de quantité et le bouton d'ajout suivent le balisage standard de PrestaShop.
### Fonctionne-t-il avec les déclinaisons ?
Oui. Les paliers sont recalculés pour chaque combinaison et le bloc se met à jour automatiquement au changement de déclinaison, sans rechargement de page.
### Que se passe-t-il à la désinstallation ?
La désinstallation supprime proprement les hooks, les variables de configuration et la table de statistiques. Aucune donnée résiduelle n'est laissée en base.
---
### DF Recently Viewed — Produits récemment consultés (PrestaShop 8/9)
_Source :_
> Présentation DF Recently Viewed (dfrecentlyviewed) affiche les produits récemment consultés par vos visiteurs, mais avec une architecture pensée pour la conversion : l'historique est stocké côté serveur, fusionné dans le…
## Présentation
DF Recently Viewed (`dfrecentlyviewed`) affiche les produits récemment consultés par vos visiteurs, mais avec une architecture pensée pour la conversion : l'historique est stocké côté serveur, fusionné dans le compte client à la connexion, rendu en AJAX pour rester exact derrière un cache de page, et enrichi de badges de baisse de prix. Un tableau de bord analytique complète l'ensemble avec un taux de conversion vue vers achat.
### Prérequis
- PrestaShop 8.0 à 9.x
- PHP 7.4 à 8.3
- Aucune dépendance externe (ni Composer, ni jQuery, ni librairie de carrousel)
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** puis déposez le fichier `dfrecentlyviewed.zip`.
3. Cliquez sur **Installer**. Le module crée sa table, enregistre ses hooks et ajoute un onglet **Catalogue > Stats produits consultés**.
4. Cliquez sur **Configurer** pour accéder aux réglages.
Le module fonctionne dès l'installation avec des réglages par défaut sensés : 8 produits, carrousel, rendu AJAX, badges de baisse de prix activés, rétention de 90 jours.
## Configuration
### Onglet Affichage
- **Titre du bloc** — traduisible dans chacune de vos langues.
- **Nombre de produits** — de 1 à 24 produits affichés dans le bloc.
- **Mise en page carrousel** — activé : carrousel horizontal avec flèches de navigation. Désactivé : grille responsive.
- **Afficher sur les fiches produit** — hook `displayFooterProduct`.
- **Afficher sur la page d'accueil** — hook `displayHome`.
- **Afficher sur la page panier** — hook `displayShoppingCartFooter`.
- **Afficher le lien « effacer mon historique »** — recommandé pour la transparence RGPD.
### Onglet Comportement intelligent
- **Exclure le produit actuellement affiché** — évite de recommander la fiche déjà à l'écran.
- **Masquer les produits en rupture** — le filtre tient compte des précommandes autorisées.
- **Masquer les produits déjà au panier** — le panier est recalculé côté serveur, jamais depuis la page en cache.
- **Badges de baisse de prix** — affiche un badge « -X % » lorsque le prix a baissé depuis la dernière consultation du visiteur.
- **Rendu AJAX (compatible cache)** — fortement recommandé, voir la section dédiée ci-dessous.
- **Rétention de l'historique (jours)** — de 1 à 730 jours. Les vues plus anciennes sont purgées automatiquement.
## Compatibilité avec le full page cache
Sur une boutique équipée de Varnish, Cloudflare, LiteSpeed Cache ou d'un CDN, un bloc personnalisé rendu côté serveur est mis en cache avec la page : le visiteur suivant voit l'historique de quelqu'un d'autre, ou un bloc vide.
Le mode **Rendu AJAX**, activé par défaut, résout ce problème : le bloc est injecté après le rendu de la page, via une requête au contrôleur front du module. Le tracking de la vue produit part quant à lui en _beacon_ non bloquant, qui fonctionne également lorsque la page provient du cache.
Ne désactivez le mode AJAX que si votre boutique n'utilise aucun cache de page. Sinon, le bloc affichera des données incorrectes.
## Badges de baisse de prix
À chaque consultation d'une fiche produit, le module enregistre le prix TTC affiché à ce moment-là pour ce visiteur précis. Lors de l'affichage du bloc, il compare ce prix mémorisé au prix courant :
- Si le prix a baissé d'au moins 1 %, un badge rouge « ↓ -X % » s'affiche en haut à gauche de la miniature.
- Le prix mémorisé est mis à jour à chaque nouvelle consultation : le badge signifie donc toujours « le prix a baissé depuis votre dernière visite sur cette fiche ».
- Si le prix remonte, le badge disparaît.
## Historique cross-device
Les vues sont enregistrées avec l'identifiant invité (`id_guest`) pour les visiteurs anonymes, et avec l'identifiant client (`id_customer`) pour les visiteurs connectés.
Au moment de la connexion (hook `actionAuthentication`), l'historique invité est fusionné dans le compte client : les compteurs de vues sont additionnés et la date de dernière consultation la plus récente est conservée. Le client retrouve ainsi ses produits consultés sur tous ses appareils.
## Page « Mon historique de navigation »
Le module ajoute une tuile dans l'espace client (hook `displayCustomerAccount`) menant à une page dédiée affichant jusqu'à 48 produits consultés, avec un bouton d'effacement si l'option est activée.
URL de la page : `/module/dfrecentlyviewed/history` (réécrite selon votre configuration d'URL).
## Widget
Le bloc peut être appelé depuis n'importe quel template de votre thème :
```
{widget name='dfrecentlyviewed'}
{widget name='dfrecentlyviewed' limit=6}
```
Le paramètre `limit` est facultatif et plafonné à 24 ; sans lui, le nombre configuré dans le back-office s'applique.
## Tableau de bord analytique
Rendez-vous dans **Catalogue > Stats produits consultés**. Vous y trouverez, sur une période de 7, 30, 90 ou 365 jours :
- **Vues produits** — nombre total de consultations enregistrées.
- **Produits distincts consultés** — étendue réelle de la découverte catalogue.
- **Visiteurs uniques** — invités et clients confondus.
- **Conversion vue vers achat** — pourcentage de couples client/produit consultés qui ont donné lieu à une commande valide postérieure à la consultation. Calculé uniquement sur les clients connectés.
- **Produits les plus consultés** — classement avec lien direct vers la fiche produit en back-office.
## RGPD et rétention
### Hooks psgdpr
Le module implémente `actionExportGDPRData` et `actionDeleteGDPRCustomer` : si le module officiel psgdpr est installé, l'historique de navigation est inclus dans les exports et les suppressions de données personnelles demandées par vos clients.
### Effacement libre-service
Lorsque l'option est activée, un lien « Effacer mon historique » apparaît à côté du titre du bloc et sur la page d'historique. Le visiteur peut supprimer lui-même ses données, avec confirmation.
### Purge automatique
Les vues plus anciennes que la durée de rétention configurée sont purgées automatiquement, de façon opportuniste (sur environ 1 % des vues enregistrées). Aucune configuration n'est nécessaire.
### CRON facultatif
Pour les boutiques à fort trafic, une URL de purge protégée par jeton est affichée sur la page de configuration. Vous pouvez l'appeler quotidiennement :
```
0 4 * * * curl -s "https://votre-boutique.com/module/dfrecentlyviewed/tracking?action=cleanup&token=VOTRE_JETON"
```
## Intégration au thème
Les produits sont rendus via la miniature native de votre thème (`catalog/_partials/miniatures/product.tpl`). Le bloc hérite donc automatiquement du design de vos listings : image, nom, prix, badges de promotion, bouton d'ajout rapide si votre thème en propose un.
Si vous souhaitez personnaliser le conteneur, surchargez les templates du module depuis votre thème :
```
themes/votre-theme/modules/dfrecentlyviewed/views/templates/hook/recentlyviewed.tpl
themes/votre-theme/modules/dfrecentlyviewed/views/templates/hook/_products.tpl
```
## Multiboutique
Les historiques sont cloisonnés par boutique : un visiteur consultant un produit sur la boutique A ne le verra pas apparaître sur la boutique B. Tous les réglages sont stockés via la table Configuration de PrestaShop, avec support multiboutique natif.
## Désinstallation
La désinstallation supprime la table d'historique, l'ensemble des réglages et l'onglet de statistiques. Une confirmation est demandée avant l'opération.
## Dépannage
### Le bloc n'apparaît pas
- Vérifiez que le hook correspondant à la page est bien activé dans la configuration (fiche produit, accueil, panier).
- Le bloc ne s'affiche que si le visiteur a consulté au moins un produit éligible. Un visiteur arrivant pour la première fois sur la boutique ne verra rien.
- Si l'exclusion du produit courant et l'exclusion du panier sont toutes deux actives, il est possible qu'aucun produit ne reste à afficher.
### Le bloc reste vide sur une page en cache
Assurez-vous que le mode **Rendu AJAX** est activé. Vérifiez également que votre configuration de cache n'intercepte pas les requêtes vers `/module/dfrecentlyviewed/tracking`.
### Les badges de baisse de prix ne s'affichent jamais
Le badge ne peut apparaître que si le visiteur a consulté le produit _avant_ la baisse de prix. Après une modification de tarif, laissez le temps aux visiteurs de revenir. Vérifiez également que l'option est bien activée.
---
### DF Samples — Commande d'échantillons (PrestaShop 8 & 9)
_Source :_
> Présentation DF Samples ajoute un bouton « Commander un échantillon » sur vos fiches produit. L'échantillon peut être gratuit ou facturé quelques euros. Le module génère automatiquement un produit échantillon…
## Présentation
DF Samples ajoute un bouton « Commander un échantillon » sur vos fiches produit. L'échantillon peut être gratuit ou facturé quelques euros. Le module génère automatiquement un produit échantillon caché pour chaque produit inscrit au programme, applique des limites par client, trace la conversion échantillon → achat et relance automatiquement vos clients par email avec un bon de réduction optionnel.
Le module est compatible PrestaShop 8.0 à 9.x, multi-boutique et multi-langues, et n'utilise aucun override du cœur.
## Installation
1. Dans le back-office, allez dans **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez le fichier `dfsamples.zip`.
3. À l'installation, le module crée ses deux tables, ses réglages par défaut, un jeton de sécurité pour la tâche cron et un onglet d'administration **Catalogue > Échantillons (DF)**.
Le module s'enregistre sur les hooks displayProductActions, displayProductAdditionalInfo, actionFrontControllerSetMedia, actionValidateOrder et actionObjectProductDeleteAfter.
## Ajouter un produit au programme d'échantillons
1. Ouvrez **Catalogue > Échantillons (DF)**.
2. Cliquez sur **Ajouter**.
3. Recherchez un produit par nom ou par référence dans le champ d'autocomplétion, puis sélectionnez-le dans la liste. Les produits déjà inscrits au programme et les produits échantillons eux-mêmes sont automatiquement exclus des résultats.
4. Saisissez le **prix de l'échantillon TTC**. Saisissez 0,00 pour un échantillon gratuit.
5. Définissez le **maximum par client** pour ce produit (0 = illimité).
6. Enregistrez.
### Ce que fait le module à l'enregistrement
Le module crée automatiquement un produit échantillon caché :
- Nom préfixé et traduit dans vos langues : Échantillon, Sample, Muestra, Muster, Campione.
- Référence dédiée au format SMPL suivi de l'identifiant du produit source.
- Prix HT calculé à partir du prix TTC saisi et du taux de TVA du produit source.
- Image de couverture du produit source recopiée et redimensionnée sur tous les formats.
- Visibilité définie sur « nulle part » : le produit n'apparaît ni en navigation ni en recherche.
- Stock illimité (autorisation de commande en rupture) pour ne jamais bloquer une demande.
- Poids d'échantillon issu du réglage global, utilisé par les transporteurs.
Si vous modifiez ensuite le prix, le poids global ou l'état actif, le produit échantillon est resynchronisé. Si le produit échantillon a été supprimé manuellement du catalogue, il est recréé au prochain enregistrement.
## Réglages
Les réglages se trouvent en bas de la page **Catalogue > Échantillons (DF)**, sous la liste des produits.
### Réglages généraux
- **Position du bouton** — sous le bouton d'ajout au panier (displayProductActions) ou dans le bloc d'informations complémentaires (displayProductAdditionalInfo). Changez ce réglage si votre thème ne rend pas le premier hook.
- **Prix d'échantillon par défaut TTC** — valeur pré-remplie à la création d'un nouvel échantillon.
- **Poids d'échantillon** — en kilogrammes, appliqué à tous les produits échantillons générés. Utilisé pour le calcul des frais de port.
- **Compte client obligatoire** — recommandé et activé par défaut. Les limites par client ne peuvent être appliquées de manière fiable que sur des clients identifiés.
- **Conversion comptabilisée sur** — l'achat du produit échantillonné uniquement, ou n'importe quel achat ultérieur.
### Limites
- **Maximum d'échantillons par panier** — 0 pour illimité.
- **Maximum d'échantillons par client et par fenêtre** — tous produits échantillons confondus. 0 pour illimité.
- **Fenêtre glissante** — en jours, 30 par défaut. Les compteurs par client portent sur cette période glissante.
Un même échantillon ne peut jamais être ajouté deux fois dans un même panier, quelle que soit la configuration.
### Relance automatique
- **Activer les emails de relance**.
- **Délai après la commande d'échantillon** — en jours, 14 par défaut.
- **Inclure un bon de réduction** — un bon nominatif, à usage unique, est généré pour chaque relance.
- **Montant du bon** — en pourcentage, 10 par défaut.
- **Validité du bon** — en jours, 30 par défaut.
L'URL de la tâche cron, sécurisée par un jeton, est affichée dans cette section ainsi que dans le panneau de statistiques.
## Configurer la tâche cron
Les relances sont envoyées par une tâche cron. Planifiez l'URL affichée dans les réglages toutes les heures. Exemple de crontab :
```
0 * * * * wget -q -O /dev/null "https://votre-boutique.com/module/dfsamples/cron?token=VOTRE_JETON"
```
Chaque exécution traite jusqu'à cinquante relances en attente et renvoie un résumé JSON : nombre d'enregistrements traités, envoyés, ignorés et en attente.
### Règles appliquées par la tâche cron
- Seuls les échantillons non encore convertis et non encore relancés sont considérés.
- La commande d'échantillon doit avoir atteint un statut payé, expédié ou livré.
- Les commandes annulées ou en erreur de paiement sont définitivement ignorées.
- Les commandes en attente de règlement sont repoussées à l'exécution suivante.
## Suivi de conversion
À la validation de chaque commande, le module enregistre les lignes d'échantillon : client, email, produit source, langue et boutique.
Lorsque ce même client passe une commande ultérieure, le module marque comme convertis les échantillons correspondants :
- En mode **produit** (par défaut) : uniquement si la commande contient le produit dont l'échantillon a été reçu.
- En mode **tout achat** : dès que la commande contient un produit réel, quel qu'il soit.
La commande courante est exclue du calcul : commander un échantillon et son produit dans le même panier ne compte pas comme une conversion.
## Tableau de bord
Le panneau affiché au-dessus de la liste des produits présente :
- **Échantillons commandés** — nombre total de lignes d'échantillon enregistrées.
- **Conversions** — nombre d'échantillons suivis d'un achat, et taux de conversion associé.
- **Chiffre d'affaires des conversions** — somme du montant TTC des commandes de conversion.
- **Relances en attente** — nombre d'échantillons éligibles à une relance non encore envoyée.
La liste des produits affiche également, par produit, le nombre d'échantillons commandés et le nombre de conversions.
## Emails de relance
Les modèles se trouvent dans le dossier mails du module, en cinq langues : fr, en, es, de, it. Chaque langue dispose d'une version HTML et d'une version texte du modèle dfsamples_followup.
Variables disponibles : firstname, lastname, product_name, product_link, voucher_block et shop_name. Le bloc voucher_block contient le bon de réduction mis en forme, ou une chaîne vide si le bon est désactivé.
Vous pouvez personnaliser librement ces modèles. Conservez les variables entre accolades pour que le remplacement fonctionne.
## Bons de réduction
Lorsque l'option est activée, chaque relance génère une règle panier PrestaShop :
- Code au format SMPL suivi de huit caractères aléatoires.
- Restreint au client destinataire.
- Utilisable une seule fois.
- Réduction en pourcentage, sur le montant TTC.
- Durée de validité configurable.
Les bons générés sont visibles dans **Promotions > Règles panier**.
## Désinstallation
À la désinstallation, le module supprime ses deux tables, ses réglages et son onglet d'administration. Les produits échantillons générés sont **désactivés et non supprimés**, afin que l'historique de vos commandes passées reste cohérent. Vous pouvez les supprimer manuellement depuis le catalogue si vous le souhaitez.
## Dépannage
### Le bouton n'apparaît pas sur la fiche produit
Vérifiez que le produit est bien inscrit au programme et actif dans **Catalogue > Échantillons (DF)**. Si le produit est bien actif, changez le réglage « Position du bouton » : certains thèmes ne rendent pas le hook displayProductActions.
### Les relances ne partent pas
Vérifiez que la tâche cron est bien planifiée et que l'URL contient le bon jeton. Appelez l'URL manuellement dans un navigateur : le module renvoie un résumé JSON. Vérifiez aussi que l'option de relance est activée et que le délai configuré est bien écoulé depuis les commandes d'échantillon.
### Le prix de l'échantillon n'est pas celui attendu
Le prix se saisit TTC et est converti en HT selon la TVA du produit source. Si le produit source n'a pas de règle de taxe, le prix HT est égal au prix saisi.
### Un client dépasse ses limites
Les limites par client ne s'appliquent qu'aux clients identifiés. Activez le réglage « Compte client obligatoire » pour les rendre effectives.
---
### DF Smart 404 — Documentation
_Source :_
> Présentation DF Smart 404 transforme la page « page introuvable » de votre boutique en un carrefour de conversion. Quand un visiteur atterrit sur une URL cassée, le module analyse…
## Présentation
DF Smart 404 transforme la page « page introuvable » de votre boutique en un carrefour de conversion. Quand un visiteur atterrit sur une URL cassée, le module analyse cette URL, en extrait les mots-clés, et affiche les produits de votre catalogue qui correspondent le mieux, accompagnés d'un formulaire de recherche déjà prérempli.
En parallèle, chaque 404 est enregistrée dans un journal en back-office. Vous voyez exactement quelles URL cassent, combien de visiteurs les touchent, et d'où ils viennent. Depuis ce journal, une redirection 301 vers le bon produit se crée en un clic.
### Ce que le module fait
- Injecte un bloc de suggestions produits dans la page 404 de votre thème, sans surcharge de template.
- Préremplit le formulaire de recherche avec les mots-clés humanisés extraits de l'URL cassée.
- Journalise chaque 404 avec déduplication, compteur de hits, referer et user-agent.
- Crée des redirections 301 ou 302 en un clic, avec protection anti-boucle.
- Applique ces redirections avant le dispatch de la page.
## Prérequis
- PrestaShop 8.0 à 9.x
- PHP 7.4 ou supérieur
- Aucune dépendance externe, aucun Composer
## Installation
1. Rendez-vous dans **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez le fichier `df404smart-1.0.0.zip`.
3. Cliquez sur **Installer**.
À l'installation, le module crée deux tables SQL (journal des 404 et redirections), enregistre trois hooks et ajoute un menu **DF Smart 404** dans le back-office avec deux sous-onglets.
Le bloc est actif immédiatement sur la page 404 avec des réglages par défaut opérationnels. Vous pouvez tester en visitant une URL inexistante de votre boutique.
## Configuration
Ouvrez la page **Configurer** du module. Elle affiche d'abord quatre indicateurs de suivi, puis le formulaire de réglages.
### Tableau de bord
- **URL cassées à corriger** — nombre d'entrées au statut « nouvelle » dans le journal.
- **Hits 404 sur ces URL** — somme des visites sur les URL non encore traitées.
- **Redirections actives** — nombre de règles de redirection en service.
- **Visites sauvées par les redirections** — somme des hits interceptés par vos redirections.
### Réglages disponibles
- **Enrichir la page 404** — active ou désactive l'injection du bloc de suggestions.
- **Afficher le formulaire de recherche** — affiche le champ de recherche prérempli dans le bloc.
- **Activer le moteur de redirection** — applique les redirections créées depuis le journal. Décochez cette case si vous utilisez déjà un module de redirections tiers.
- **Nombre de suggestions** — entre 0 et 12 produits affichés. La valeur 0 désactive les suggestions tout en conservant le formulaire de recherche.
- **Type de redirection par défaut** — 301 permanente (recommandée pour le SEO) ou 302 temporaire.
- **Journaliser le trafic des robots** — si désactivé, les hits provenant de crawlers connus ne sont pas écrits dans le journal.
- **Rétention du journal (jours)** — les entrées plus anciennes sont purgées automatiquement. Les règles de redirection ne sont jamais purgées.
- **Motifs d'exclusion** — une expression régulière insensible à la casse par ligne. Les URL correspondantes ne sont jamais journalisées.
### Motifs d'exclusion par défaut
Le module est livré avec une liste de motifs qui écartent le bruit généré par les scanners de vulnérabilités et les requêtes automatisées : tentatives sur wp-admin, wp-login, xmlrpc, phpmyadmin, les dossiers .git, ainsi que les ressources statiques (images, feuilles de style, scripts). Ajoutez vos propres motifs, un par ligne. Un motif invalide est signalé à l'enregistrement, avec le numéro de ligne concerné.
## Le bloc de suggestions en front
### Comment les produits sont sélectionnés
Lorsqu'une 404 se produit, le module découpe les **deux derniers segments** de l'URL en mots-clés. Les mots vides sont écartés dans cinq langues (français, anglais, espagnol, allemand, italien), seuls les tokens d'au moins trois caractères sont conservés, et les identifiants purement numériques sont exclus.
Chaque token restant est ensuite confronté au catalogue avec un scoring pondéré :
- correspondance dans le **link_rewrite** du produit : **4 points**
- correspondance dans le **nom** du produit : **3 points**
- correspondance dans la **référence** : **2 points**
Les produits sont classés par score décroissant, et seuls ceux dont le score est supérieur à zéro sont retenus.
### Le repli
Si aucun produit ne ressort de l'analyse — cas fréquent sur une URL très courte ou obscure — le module bascule automatiquement sur les **meilleures ventes**. Si celles-ci sont également indisponibles (catalogue neuf, statistiques non calculées), il affiche les **produits les plus récents**. Le visiteur voit donc toujours des produits, jamais un bloc vide.
### Le formulaire de recherche
Le champ de recherche est prérempli avec la version humanisée des mots-clés de l'URL. Un visiteur arrivant sur `/sneakers-cuir-premium-edition` voit déjà « sneakers cuir premium edition » dans le champ.
Le formulaire pointe vers la page de recherche native de votre thème, avec les paramètres de la query string correctement transmis en champs cachés. Aucun conflit avec un module de recherche instantanée tiers : le module ne surcharge rien, il utilise le point d'entrée standard de PrestaShop.
### Où le bloc s'affiche
Le module détecte la section de contenu de la page 404 de votre thème et y insère le bloc, juste sous le message natif. Si la structure du thème est atypique, plusieurs replis successifs garantissent que le bloc reste au-dessus du pied de page. Aucun fichier de thème n'est modifié.
## Le journal des 404
Menu **DF Smart 404 > Journal des 404**.
### Colonnes
- **URL cassée** — le chemin appelé, normalisé.
- **Hits** — nombre de visites sur cette URL. La liste est triée par hits décroissants par défaut : les URL les plus coûteuses apparaissent en premier.
- **Dernier referent** — d'où venait le dernier visiteur (Google, un site tiers, une page interne…).
- **Statut** — Nouvelle, Redirigée ou Ignorée.
- **Dernier hit** — date de la dernière visite.
### Déduplication
La déduplication repose sur un hash de l'URL, scopé par boutique. Mille visites sur la même URL cassée produisent **une seule ligne avec mille hits**, jamais mille lignes. L'écriture se fait en une requête upsert unique.
### Actions disponibles sur chaque ligne
- **Redirection auto** (icône éclair) — crée instantanément une redirection vers le produit le plus pertinent, en AJAX, sans quitter la page. Cette action n'est proposée que si le score de correspondance dépasse le seuil de confiance ; sinon, un message vous invite à utiliser le formulaire guidé.
- **Créer une redirection** — ouvre le formulaire guidé (voir ci-dessous).
- **Ignorer** — bascule l'entrée au statut « ignorée ». Elle disparaît des indicateurs de suivi mais reste consultable.
- **Supprimer** — supprime l'entrée du journal.
Une action groupée de suppression et un export CSV sont également disponibles depuis la barre d'outils.
## Créer une redirection
### La redirection automatique
Le bouton éclair calcule le meilleur produit correspondant à l'URL cassée. Si le score dépasse le seuil de confiance interne, la redirection est créée immédiatement avec le type par défaut configuré, et l'entrée du journal passe au statut « redirigée ». Un message de confirmation indique le produit cible.
Le seuil de confiance évite les redirections hasardeuses. Une URL comme `/promo-ete-2024` n'aura probablement pas de match fiable : le module refusera la redirection automatique et vous renverra vers le formulaire guidé.
### Le formulaire guidé
Il affiche l'URL cassée, son nombre de hits, puis la liste des produits suggérés classés par score. Chaque suggestion est un bouton radio, la première étant présélectionnée. Un champ **URL personnalisée** permet de saisir n'importe quelle cible : une catégorie, une page CMS, une URL externe.
Vous choisissez ensuite le type de redirection (301 ou 302) et validez. Le module vérifie que la cible n'est pas vide, qu'elle ne pointe pas vers l'URL source elle-même (protection anti-boucle), et qu'aucune redirection n'existe déjà pour cette source.
## Gérer les redirections
Menu **DF Smart 404 > Redirections 404**.
Cet écran offre un CRUD complet sur vos règles de redirection :
- **URL source** — le chemin cassé (ex. `/ancienne-categorie/ancien-produit`).
- **URL cible** — chemin ou URL complète vers laquelle rediriger.
- **Type** — 301 (permanente) ou 302 (temporaire).
- **Hits** — nombre de visites interceptées par cette règle. C'est votre mesure directe des visites sauvées.
- **Actif** — interrupteur pour désactiver une règle sans la supprimer.
Les mêmes validations qu'au formulaire guidé s'appliquent : source non vide, pas de boucle, pas de doublon de source (l'identifiant courant est exclu du contrôle en édition).
### Fonctionnement du moteur
Les redirections sont évaluées avant le dispatch de la page, en amont du contrôleur front. Le chemin appelé est normalisé, puis un lookup indexé sur son hash cherche une règle active pour la boutique courante. Si une règle correspond, le compteur de hits est incrémenté et la redirection est émise avec le code HTTP configuré.
## Performance
- Le journal n'écrit qu'en cas de 404 réelle, en une seule requête upsert.
- Le moteur de redirection effectue un lookup indexé sur un hash : coût négligeable, même avec des centaines de règles.
- La purge des entrées anciennes est déclenchée aléatoirement sur environ 1 % des hits, afin de ne jamais bloquer une requête visiteur.
- Les hits provenant de robots peuvent être exclus de l'écriture, ce qui réduit encore la charge sur les boutiques fortement crawlées.
## Multi-boutique
Toutes les données du module sont scopées par identifiant de boutique : le journal, les redirections et les suggestions. Chaque boutique dispose de son propre journal, de ses propres règles et de sa propre configuration. Une URL cassée sur la boutique A n'apparaît pas dans le journal de la boutique B.
## RGPD
Le journal enregistre l'URL cassée, le referer et le user-agent. **Aucune adresse IP n'est stockée**, aucune donnée nominative n'est collectée. La rétention est configurable et la purge automatique. Le module n'envoie aucune donnée vers un service externe.
## Désinstallation
La désinstallation supprime les deux tables du module (journal des 404 et redirections), les onglets back-office et la configuration. **Les redirections créées seront perdues.** Une confirmation est demandée avant l'opération.
Si vous prévoyez de réinstaller le module ou de migrer, exportez d'abord vos redirections en CSV depuis l'écran de gestion.
## Dépannage
### Le bloc ne s'affiche pas sur la page 404
- Vérifiez que le réglage **Enrichir la page 404** est activé.
- Videz le cache PrestaShop (**Paramètres avancés > Performances > Vider le cache**).
- Assurez-vous que le thème utilise bien le contrôleur `pagenotfound` standard.
### Le bloc s'affiche sous le pied de page
Ce cas est traité depuis la version 1.0.0 : le module cible la section de contenu et non la balise de fermeture du conteneur principal. Si vous rencontrez encore ce comportement, videz le cache Smarty et signalez la structure de votre thème au support.
### Aucun produit n'est suggéré
- Vérifiez que le **Nombre de suggestions** n'est pas réglé sur 0.
- Sur un catalogue neuf sans historique de ventes, le repli meilleures ventes est vide : le module bascule alors sur les produits récents. Assurez-vous d'avoir au moins un produit actif et visible.
### La redirection automatique refuse de se créer
C'est le comportement attendu quand le score de correspondance est trop faible. Utilisez le formulaire guidé, qui affiche les suggestions même en dessous du seuil, et permet de saisir une cible personnalisée.
### Une redirection ne s'applique pas
- Vérifiez que le réglage **Activer le moteur de redirection** est coché.
- Vérifiez que la règle est bien **active** dans l'écran de gestion.
- Vérifiez que la règle appartient à la bonne boutique en contexte multi-boutique.
- Si un autre module de redirections est installé, il peut intercepter la requête en amont.
## Support
12 mois de mises à jour et 12 mois de support par email sont inclus avec votre licence. Le code source PHP complet est fourni, non obfusqué.
---
### DF Swipe Gallery — Navigation produits par swipe
_Source :_
> Présentation DF Swipe Gallery transforme les pages catégorie de votre boutique PrestaShop en deck de cartes plein écran façon Tinder. Le visiteur découvre les produits un par un : swipe…
## Présentation
DF Swipe Gallery transforme les pages catégorie de votre boutique PrestaShop en deck de cartes plein écran façon Tinder. Le visiteur découvre les produits un par un : swipe à droite pour liker (wishlist), swipe à gauche pour passer, swipe vers le haut pour ajouter au panier. Une barre de progression style stories indique l'avancement et un écran final récapitule les coups de cœur de la session. Toutes les interactions alimentent un dashboard analytics dans le back-office.
Le module fonctionne sans aucune dépendance : pas de Composer, pas de jQuery, pas de service externe. Compatible PrestaShop 8.0 à 9.x, multiboutique et multilingue.
## Installation
1. Dans votre back-office, ouvrez **Modules → Gestionnaire de modules → Installer un module**.
2. Envoyez le fichier `dfswipegallery.zip` puis cliquez sur **Installer**.
3. Le module crée automatiquement ses deux tables (`df_swipegallery_like` et `df_swipegallery_stat`), enregistre ses hooks et ajoute l'onglet **Catalogue → Swipe Gallery**.
Aucune modification de thème n'est nécessaire : le bouton de lancement et l'overlay sont injectés via le hook `displayFooterAfter`, indépendamment de votre template.
## Configuration
Ouvrez **Modules → DF Swipe Gallery → Configurer**. Les options disponibles :
- **Enable swipe gallery** — active ou désactive globalement le module.
- **Mobile devices only** — limite le bouton flottant aux écrans de moins de 992 px (activé par défaut). Désactivez-le pour proposer aussi le deck sur desktop.
- **Maximum products per deck** — nombre de cartes par session, de 5 à 100 (30 par défaut).
- **Deck order** — ordre des cartes : position catégorie, aléatoire (recommandé pour la découverte) ou nouveautés d'abord.
- **Swipe up adds to cart** — active le super-like : un swipe vers le haut ajoute le produit au panier.
- **Hide already liked products** — exclut des nouveaux decks les produits déjà likés par le visiteur.
- **Show price on cards** — affiche ou masque le prix sur les cartes (automatiquement masqué en mode catalogue).
- **Launcher button position** — position du bouton flottant : bas droite, bas gauche ou bas centre.
Pour une démo percutante, choisissez l'ordre **aléatoire** et laissez le swipe-up panier activé : c'est le combo qui génère le plus d'engagement.
## Utilisation côté boutique
Sur toute page catégorie, un bouton flottant « Swipe mode » apparaît. Au tap, le deck s'ouvre en plein écran :
- **Swipe à droite** (ou bouton cœur) — like : le produit est enregistré en wishlist.
- **Swipe à gauche** (ou bouton croix) — passe au produit suivant.
- **Swipe vers le haut** (ou bouton panier) — ajoute le produit au panier.
- **Tap sur « Voir le produit »** — ouvre la fiche produit.
Sur desktop, les flèches du clavier reproduisent les gestes (→ like, ← passer, ↑ panier) et la touche Échap ferme le deck. Une vibration haptique accompagne chaque swipe sur les appareils compatibles, et l'animation est désactivée si le visiteur a activé `prefers-reduced-motion`.
À la fin du deck, un écran récapitulatif liste les produits likés avec leur prix et un lien direct vers chaque fiche, plus un bouton pour relancer une session.
## Wishlist, clients et invités
Chaque like est persisté dans la table native du module, qu'il provienne d'un client connecté ou d'un visiteur invité (rattaché à son `id_guest`). Une clé unique empêche les doublons.
Si le module officiel **blockwishlist** est installé et que le client est connecté, le produit est également ajouté à sa liste d'envies par défaut — créée automatiquement si elle n'existe pas encore. Aucune configuration n'est requise : le pont est silencieux et n'échoue jamais bruyamment.
Les likes des invités restent rattachés à leur session. Le module expose un helper de fusion (`attachGuestLikesToCustomer`) permettant de rattacher ces likes au compte client après connexion si vous souhaitez brancher ce comportement.
## Ajout panier par swipe
Le swipe vers le haut ajoute le produit côté serveur : le panier est créé si nécessaire, la quantité minimale du produit est respectée et le badge panier du thème est rafraîchi via l'événement standard `prestashop.emit('updateCart')`. Les produits non commandables (indisponibles à la commande) sont refusés proprement avec un message.
## Analytics back-office
L'onglet **Catalogue → Swipe Gallery** présente le dashboard :
- Compteurs globaux : cartes vues, likes, skips, ajouts panier.
- **Taux de like global** : likes / (likes + skips).
- **Top 20 des produits par likes**, avec vues, skips, paniers et taux de like par produit.
Ces données constituent un signal merchandising direct : les produits au taux de like élevé méritent d'être mis en avant, ceux qui sont massivement skippés méritent une meilleure photo ou un repositionnement. Les statistiques d'un produit supprimé sont purgées automatiquement.
Aucune donnée n'est envoyée à un service tiers : toutes les statistiques restent dans votre base de données.
## Multiboutique et multilingue
Les likes et statistiques sont enregistrés par boutique (`id_shop`). Les textes du deck (Like, Passer, Voir le produit, écran récapitulatif…) passent par le système de traduction natif de PrestaShop : traduisez-les dans **International → Traductions → Traductions des modules installés**.
## Dépannage
- **Le bouton n'apparaît pas** — vérifiez que le module est activé, que vous êtes bien sur une page catégorie et que l'option mobile-only n'est pas active si vous testez sur desktop.
- **Le deck est vide** — la catégorie ne contient aucun produit actif visible, ou tous les produits sont exclus par l'option « Hide already liked products ».
- **Le badge panier ne se met pas à jour** — votre thème custom n'écoute peut-être pas l'événement `updateCart` ; adaptez l'écouteur dans votre thème ou contactez le support.
- **Conflit d'affichage** — l'overlay utilise un z-index de 1060 ; augmentez-le via CSS si un élément de votre thème passe au-dessus.
## Changelog
- **1.0.0** (2026-07-16) — Version initiale : deck swipe plein écran, wishlist par swipe à droite avec pont blockwishlist, ajout panier par swipe vers le haut, support des invités, dashboard analytics, barre de progression stories, accessibilité, compatibilité PrestaShop 8 & 9 et multiboutique.
---
### DF Translate — Guide complet
_Source :_
> DF Translate rend votre site WordPress et votre boutique WooCommerce réellement multilingues. Chaque traduction est un contenu réel en base de données (façon Polylang ou WPML), pas une couche de…
DF Translate rend votre site WordPress et votre boutique WooCommerce réellement multilingues. Chaque traduction est un contenu réel en base de données (façon Polylang ou WPML), pas une couche de texte réécrite à la volée : c'est ce qui garantit un SEO impeccable et une compatibilité totale avec votre thème, votre page builder et vos extensions. La traduction automatique est optionnelle et repose sur votre propre clé d'API. Ce guide couvre l'installation, la configuration des langues et du moteur IA, la traduction des contenus et des chaînes, le SEO multilingue, l'éditeur côte à côte, la migration depuis Polylang, WooCommerce et le dépannage.
## Installation
1. Téléchargez l'archive `dftranslate.zip` depuis votre compte DataFirefly.
2. Back-office WordPress → **Extensions** → **Ajouter** → **Téléverser une extension** → envoyez le ZIP, puis **Activer**.
3. À l'activation, l'extension crée ses tables (groupes de traduction, chaînes, traductions de chaînes) et ajoute le menu **DF Translate**.
Compatible WordPress 6.2 et supérieur, PHP 8.0 à 8.3, multisite. Compatible WooCommerce (produits simples, catégories, étiquettes) et les extensions SEO Yoast, Rank Math, AIOSEO et SEOPress. Aucune dépendance Composer au déploiement.
## Prise en main en cinq minutes
1. Ouvrez **DF Translate → Réglages**, onglet **Langues**, et ajoutez votre deuxième langue depuis la liste de préréglages (la version gratuite couvre 2 langues). Définissez la langue par défaut.
2. Onglet **Traduction** : choisissez un moteur IA et saisissez votre clé d'API (ou laissez vide pour tout traduire à la main). Cliquez sur **Tester la connexion**.
3. Ouvrez un article ou un produit : dans la boîte **Langue & traductions**, cliquez sur **⚡ Créer & traduire** pour la langue cible.
4. Relisez la traduction dans l'éditeur côte à côte, puis publiez-la.
5. Ajoutez le sélecteur de langue à votre site (bloc, widget, menu ou barre d'administration) pour que vos visiteurs puissent changer de langue.
DeepL propose un palier gratuit d'API : c'est une bonne option pour démarrer sans coût. Pour la meilleure qualité rédactionnelle sur des fiches produit, Claude (Anthropic) est recommandé.
## Configurer les langues
Tout se passe dans **DF Translate → Réglages → Langues**.
### Ajouter une langue
Utilisez le menu déroulant de préréglages (27 langues avec code, locale, nom et drapeau préremplis) ou le bouton **Personnalisé…** pour saisir manuellement le code (ex. `de`), la locale (ex. `de_DE`) et le nom affiché. La version gratuite autorise 2 langues ; DF Translate Pro les rend illimitées.
### Langue par défaut, ordre et suppression
La langue par défaut est celle de vos contenus d'origine (elle n'a pas de préfixe d'URL). Réordonnez les langues avec les flèches **▲▼** (l'ordre se retrouve dans le sélecteur) et retirez-en une avec **✕**. Supprimer une langue de la configuration ne détruit pas les contenus : ils restent en base et sont ré-attachés si vous rajoutez la langue.
Vous ne pouvez pas supprimer la langue par défaut : désignez d'abord une autre langue comme défaut. Après avoir modifié les langues ou les préfixes d'URL, videz le cache de votre site et, si besoin, rafraîchissez les permaliens (Réglages → Permaliens → Enregistrer).
## Configurer le moteur de traduction IA
Dans **DF Translate → Réglages → Traduction**, choisissez le moteur et renseignez votre clé.
- **Claude (Anthropic)** : meilleure qualité rédactionnelle, idéale pour le contenu marketing et les fiches produit.
- **DeepL** : excellent rapport qualité/prix, palier gratuit disponible.
- **OpenAI** : moteur généraliste GPT.
- **LibreTranslate** : serveur auto-hébergé, pour une souveraineté totale des données (vous indiquez l'URL de votre instance).
Le champ **Tonalité** permet d'orienter le style (par exemple « professionnel », « chaleureux »). Vos clés sont chiffrées au repos (libsodium, avec repli OpenSSL) et ne sont jamais exposées côté visiteur.
Pas d'abonnement au mot ni de proxy : votre contenu ne quitte votre site que vers le fournisseur que vous configurez, et uniquement lorsque vous déclenchez une traduction. Vous pouvez aussi ne configurer aucun moteur et traduire entièrement à la main.
## Traduire un contenu
Chaque article, page, produit, catégorie ou étiquette dispose d'une boîte **Langue & traductions** dans l'éditeur, et d'une colonne **Langue** dans les listes.
### Depuis l'éditeur
La boîte affiche la langue du contenu et l'état de chaque traduction. Pour chaque langue manquante, **⚡ Créer & traduire** crée la traduction et la remplit avec le moteur IA ; sans moteur configuré, **+ Créer** crée une ébauche vide. Un contenu traduit par IA est marqué **⚑ MT** (« à relire ») jusqu'à ce qu'un humain l'édite.
### Depuis les listes (matrice de traductions)
Dans la colonne **Langue**, une matrice montre pour chaque ligne : sa propre langue (drapeau plein), un lien **✎** vers chaque traduction existante (bordure pointillée si brouillon, orange si obsolète), et un bouton **⚡** ou **+** pour créer les manquantes. Les contenus sans langue (« orphelins ») proposent une assignation rapide directement dans la cellule.
### Filtrer et éditer en lot
Au-dessus des listes, des liens de vues filtrent par langue avec des compteurs, plus une vue **⚑ À relire**. La langue se définit aussi en **Modification rapide** et en **Modification en lot** (option « — Aucun changement — » pour ne pas écraser les lignes non concernées).
## L'éditeur côte à côte
Depuis une traduction, le bouton **⇆ Côte à côte** (dans la boîte de traduction, les actions de ligne ou l'éditeur) ouvre un écran comparant la source et la cible : titre, slug, extrait et métadonnées SEO alignés. Chaque champ dispose d'un bouton **⧉** (copier depuis la source) et **⚡** (traduire ce champ par IA). Un sélecteur de statut, la navigation entre les langues du groupe et un indicateur d'obsolescence complètent l'écran. Raccourci **Ctrl/Cmd + S** pour enregistrer.
Quand vous modifiez un contenu source déjà traduit, ses traductions sont signalées « obsolètes » (↻). Ouvrez-les en côte à côte pour ne retraduire que les champs concernés.
## Traduire les chaînes (textes de l'interface)
Les textes qui ne sont pas du contenu éditorial — titre du site, slogan, titres de widgets, libellés de thème — se gèrent dans **DF Translate → Chaînes**. Saisissez la traduction de chaque chaîne par langue, ou utilisez l'**import/export .po** pour confier ce travail à un traducteur ou réutiliser un catalogue existant.
## SEO multilingue
- **hreflang** : les balises `hreflang` (avec `x-default`) sont ajoutées automatiquement sur chaque page pour indiquer aux moteurs les versions linguistiques.
- **URLs par langue** : chaque langue non par défaut est préfixée (ex. `/fr/`), pour des URLs propres et indexables.
- **Slugs traduits** : le slug de la traduction est régénéré depuis le titre traduit.
- **Métadonnées SEO** : les titres, descriptions et mots-clés de Yoast, Rank Math, AIOSEO et SEOPress sont traduits en même temps que le contenu.
## Le sélecteur de langue
Proposez le changement de langue à vos visiteurs de la façon qui convient à votre thème :
- **Bloc Gutenberg** « Sélecteur de langue » dans l'éditeur de site ou de contenu.
- **Widget** classique dans une zone de widgets.
- **Shortcode**`[dft_switcher]` n'importe où.
- **Dans un menu** : ajoutez un lien personnalisé avec l'URL `#dft_switcher`, il se déploie en un élément par langue.
- **Barre d'administration** : un sélecteur est disponible pour les utilisateurs connectés.
Les drapeaux sont des SVG embarqués, nets sur tous les systèmes (y compris Windows, où les drapeaux emoji ne s'affichent pas).
## Menus traduits
Dans **Réglages → Menus**, assignez un menu différent par langue à chaque emplacement de thème, ou laissez vide pour réutiliser le menu par défaut. Le bouton **⚡ Générer** clone le menu par défaut en remappant chaque élément vers sa traduction (les libellés suivent alors les titres traduits) et en traduisant les liens personnalisés.
## WooCommerce
DF Translate traduit les produits simples, les catégories et les étiquettes de produits comme n'importe quel contenu. Le **stock** et le **prix** restent synchronisés entre les langues d'un même produit, et la **langue du client** est enregistrée sur la commande.
Les produits variables, les e-mails de commande dans la langue du client et les bases d'URL traduites font partie de DF Translate Pro.
## Migrer depuis Polylang
Si vous utilisez déjà Polylang, ouvrez **DF Translate → Réglages** et lancez la migration en un clic. Vos langues, les affectations de langue de vos contenus et vos groupes de traduction sont importés automatiquement. Vos données Polylang ne sont pas modifiées et vos langues existantes sont préservées (fusion, pas écrasement).
Faites une sauvegarde de votre base avant toute migration, par principe. La migration est conçue pour être non destructive, mais une sauvegarde reste la bonne pratique.
## Tableau de bord et contrôles de santé
Le tableau de bord (**DF Translate**) montre la couverture de traduction par type de contenu et par langue, les contenus à relire, et des **contrôles de santé** : permaliens, contenus sans langue, moteur non configuré. Plusieurs problèmes (comme les contenus orphelins) se réparent en un clic.
## Support REST / headless
Les champs `dft_lang` et `dft_translations` sont exposés dans l'API REST sur les types de contenu traduisibles. Le filtrage par langue se fait explicitement via `?lang=` ; les réponses de l'API ne sont jamais filtrées implicitement par un cookie de langue, ce qui évite de corrompre les résultats d'un front headless.
## Désinstallation
La simple désactivation conserve toutes vos données. Si vous cochez l'option de suppression des données dans les réglages, la suppression de l'extension efface les tables et options de DF Translate ; vos contenus WordPress et vos commandes ne sont jamais touchés.
## FAQ et dépannage
**Le test de connexion au moteur échoue.** Vérifiez la clé d'API, son quota côté fournisseur, et que votre serveur peut joindre l'API en sortie. Pour LibreTranslate, vérifiez l'URL de l'instance.
**Une traduction reste marquée « à relire » (⚑ MT).** C'est normal après une traduction machine : ouvrez-la et enregistrez une modification humaine (éditeur, côte à côte ou import) pour lever le drapeau.
**Le sélecteur de langue n'apparaît pas dans mon menu.** Vérifiez que le lien personnalisé a bien l'URL exacte `#dft_switcher`, puis enregistrez le menu.
**Des drapeaux s'affichaient en lettres.** DF Translate utilise des drapeaux SVG embarqués justement pour éviter ce problème (les drapeaux emoji ne sont pas rendus sous Windows). Videz le cache si un ancien rendu persiste.
**Une page traduite renvoie une erreur 404.** Rafraîchissez les permaliens (Réglages → Permaliens → Enregistrer) après avoir ajouté une langue ou modifié les préfixes d'URL.
**Comment passer à plus de 2 langues ?** DF Translate Pro rend les langues illimitées et ajoute la traduction en masse, l'autopilote, la mémoire de traduction, le glossaire, l'export/import XLIFF et les commandes WP-CLI.
---
### DF Translate Pro — Guide complet
_Source :_
> DF Translate Pro est l'add-on payant qui industrialise la traduction de votre site WordPress et WooCommerce. Il s'installe par-dessus la version gratuite DF Translate (requise) et débride les langues (illimitées…
DF Translate Pro est l'add-on payant qui industrialise la traduction de votre site WordPress et WooCommerce. Il s'installe par-dessus la version gratuite DF Translate (requise) et débride les langues (illimitées au lieu de 2), ajoute la traduction en masse de tout le site avec estimation du coût, l'autopilote à diff intelligent, la mémoire de traduction, le glossaire de marque, les produits variables WooCommerce, les e-mails de commande dans la langue du client, les bases d'URL traduites, l'export/import XLIFF et les commandes WP-CLI. Ce guide couvre l'installation, l'activation de la licence, chacune de ces fonctions et le dépannage.
DF Translate Pro est un **add-on** : la version gratuite DF Translate doit être installée et activée. Le Pro réutilise le moteur IA et la clé d'API que vous avez déjà configurés dans le gratuit — rien à reconfigurer côté traduction.
## Installation
1. Assurez-vous que DF Translate (gratuit) est installé et activé, avec au moins un moteur de traduction configuré.
2. Téléchargez l'archive `dftranslate-pro.zip` depuis votre compte DataFirefly.
3. Back-office WordPress → **Extensions** → **Ajouter** → **Téléverser une extension** → envoyez le ZIP, puis **Activer**.
4. À l'activation, l'extension ajoute ses tables (mémoire de traduction, glossaire, file d'attente) et déverrouille les fonctions Pro dans le menu **DF Translate**.
## Activer votre licence
Ouvrez **DF Translate → Licence**, collez votre clé de licence et cliquez sur **Activer**. L'activation débloque les mises à jour automatiques hébergées et confirme le nombre de sites autorisés par votre palier (1 site en licence standard, 5 en Business, 25 en Agency).
Une licence par site actif. Pour déplacer une licence d'un site à un autre (par exemple d'un site de préproduction vers la production), désactivez-la d'abord depuis l'écran Licence du premier site, puis activez-la sur le second.
Sans licence active, les fonctions Pro déjà configurées continuent de fonctionner, mais vous ne recevez plus les mises à jour automatiques. Réactivez la licence pour retrouver les mises à jour et le support.
## Langues illimitées
Dès que le Pro est actif, la limite de 2 langues de la version gratuite disparaît. Dans **DF Translate → Réglages → Langues**, ajoutez autant de langues que nécessaire depuis la liste de préréglages ou en personnalisé. Tout le reste (langue par défaut, ordre, sélecteur) fonctionne comme dans la version gratuite, mais sans plafond.
## Traduction en masse de tout le site
La traduction en masse traduit d'un coup un grand ensemble de contenus. Ouvrez **DF Translate → Traduction en masse**.
1. Choisissez les **types de contenu** (articles, pages, produits, catégories, étiquettes) et les **langues cibles**.
2. Filtrez si besoin (par exemple seulement les contenus non encore traduits).
3. DF Translate Pro affiche une **estimation** : nombre de contenus, nombre de caractères à traduire et coût correspondant selon le moteur configuré.
4. Vérifiez l'estimation, puis cliquez sur **Lancer**. Les traductions sont créées et placées dans la file d'attente.
Rien n'est envoyé au moteur tant que vous n'avez pas confirmé après l'estimation. Sur un très gros catalogue, commencez par un seul type de contenu ou une seule langue pour valider le rendu avant de lancer la totalité.
La progression s'affiche en direct. Les traductions issues de la masse sont marquées **⚑ MT** (« à relire ») : relisez-les dans l'éditeur côte à côte quand vous le souhaitez.
## L'autopilote
L'autopilote traduit automatiquement vos contenus nouveaux et modifiés, sans action manuelle. Activez-le dans **DF Translate → Réglages → Autopilote** et choisissez les types de contenu et les langues concernés.
### Le diff intelligent
Quand un contenu source déjà traduit est modifié, l'autopilote ne retraduit **que les champs réellement changés**. Si vous ne modifiez que le titre d'un produit, seul le titre est retraduit ; le reste de la fiche n'est pas renvoyé au moteur. C'est ce qui rend l'autopilote économe en tokens.
### Exclure un contenu
Chaque contenu dispose d'une case **« Exclure de l'autopilote »** dans la boîte de traduction. Cochez-la pour garder la main sur un contenu précis (par exemple une page que vous traduisez vous-même) : l'autopilote l'ignorera.
L'autopilote s'appuie sur la file d'attente : les traductions sont traitées en arrière-plan (Action Scheduler, avec repli WP-Cron), sans bloquer l'enregistrement de votre contenu.
## Mémoire de traduction
La mémoire de traduction enregistre chaque segment traduit (une phrase, un titre) et le réutilise automatiquement lorsqu'il réapparaît. Résultat : la même phrase n'est jamais envoyée deux fois au moteur, ce qui réduit le coût et garantit la cohérence entre vos contenus. Elle fonctionne en arrière-plan dès que le Pro est actif ; vous pouvez consulter et purger la mémoire depuis **DF Translate → Mémoire de traduction**.
## Glossaire de marque
Le glossaire garantit que vos termes clés — noms de produits, nom de marque, expressions métier — sont toujours rendus exactement comme vous le décidez, dans chaque langue. Ouvrez **DF Translate → Glossaire**.
- Ajoutez une entrée : le terme source et sa traduction imposée pour chaque langue.
- Indiquez si la correspondance est sensible à la casse et si elle doit porter sur le mot entier.
- **Importez / exportez** le glossaire au format CSV pour le partager, le réutiliser sur un autre site ou le faire remplir par un tiers.
Renseignez au minimum votre nom de marque et vos noms de produits : ce sont les termes qu'un moteur de traduction a le plus tendance à « traduire » alors qu'ils doivent rester tels quels.
## WooCommerce Pro
### Produits variables
Le Pro traduit les **produits variables** et leurs variations (au-delà des produits simples couverts par le gratuit) : noms d'attributs, valeurs et descriptions de variation.
### E-mails de commande dans la langue du client
Les e-mails de commande WooCommerce (confirmation, facture, etc.) partent dans la **langue du client** enregistrée sur la commande : sujets et en-têtes compris. Activez cette option dans les réglages WooCommerce du Pro.
### Bases d'URL traduites
Vous pouvez traduire les **bases d'URL** WooCommerce (boutique, catégorie de produit, étiquette) par langue, avec des redirections 301 depuis les anciennes adresses, pour des URLs parfaitement localisées.
La synchronisation du stock et des prix entre langues, et l'enregistrement de la langue du client sur la commande, viennent déjà de la version gratuite : le Pro ne fait qu'ajouter les variations, les e-mails localisés et les bases d'URL.
## Export / import XLIFF (traducteurs professionnels)
Pour travailler avec un traducteur humain ou une agence, ouvrez **DF Translate → XLIFF**.
1. **Exportez** les contenus choisis au format XLIFF 1.2 standard (titre, contenu, extrait, métadonnées SEO). Un fichier par langue cible.
2. Confiez le fichier à votre traducteur ou à son outil TAO (Trados, memoQ, Smartcat, etc.).
3. **Réimportez** le fichier traduit : les traductions sont créées ou mises à jour, leurs empreintes de diff rafraîchies, et le drapeau « à relire » est levé (un contenu traduit par un humain est relu par définition).
## Commandes WP-CLI
Pour les gros volumes et l'intégration continue, le Pro fournit des commandes en ligne de commande :
- `wp dft translate` — lance la traduction d'un ensemble de contenus (options de type, langue, filtre).
- `wp dft process` — traite la file d'attente en attente.
- `wp dft status` — affiche l'état de la couverture et de la file d'attente.
- `wp dft orphans` — liste ou répare les contenus sans langue.
Sur un serveur avec accès SSH, `wp dft translate` puis `wp dft process` permettent de traduire un très gros catalogue sans passer par le navigateur, idéal en tâche planifiée ou en pipeline de déploiement.
## La file d'attente de traduction
La traduction en masse et l'autopilote passent par une file d'attente traitée en arrière-plan (Action Scheduler, avec repli WP-Cron). En cas d'échec temporaire d'une API, la tâche est **relancée automatiquement**. Vous suivez l'état de la file dans le tableau de bord et pouvez la relancer manuellement (ou via `wp dft process`).
## Mises à jour
Tant que votre licence est active, DF Translate Pro reçoit ses **mises à jour automatiques** directement depuis DataFirefly, comme n'importe quelle extension WordPress. La version gratuite se met à jour indépendamment. Gardez les deux à jour pour garantir leur compatibilité.
## FAQ et dépannage
**Les fonctions Pro n'apparaissent pas.** Vérifiez que DF Translate (gratuit) est bien activé _et_ que le Pro est activé par-dessus. Les deux extensions doivent être actives.
**Ma licence est refusée.** Vérifiez la clé (copier/coller sans espace), le palier (nombre de sites) et que le site n'a pas déjà consommé toutes ses activations. Désactivez la licence sur un site inutilisé pour libérer une place.
**L'estimation de coût me semble élevée.** Réduisez le périmètre (un type de contenu, une langue), ou laissez la mémoire de traduction se remplir : les segments déjà traduits ne sont pas refacturés. Le glossaire n'affecte pas le coût mais garantit la cohérence.
**L'autopilote ne traduit pas un contenu.** Vérifiez qu'il est activé pour ce type de contenu et cette langue, et que le contenu n'est pas coché « Exclure de l'autopilote ». Contrôlez aussi que la file d'attente tourne (WP-Cron actif ou `wp dft process`).
**Un import XLIFF ne met pas à jour les traductions.** Vérifiez que le fichier correspond bien aux contenus exportés (les identifiants d'unité de traduction ne doivent pas être modifiés) et qu'il est resté en XLIFF 1.2 valide après passage dans l'outil TAO.
**La traduction en masse s'arrête avant la fin.** C'est généralement la file d'attente qui attend le prochain passage de WP-Cron. Relancez avec `wp dft process`, ou configurez un vrai cron système pour les très gros volumes.
---
### DfAddressAutocomplete — Auto-complétion d'adresse pour Shopware 6
_Source :_
> Présentation DfAddressAutocomplete ajoute une recherche d'adresse instantanée aux formulaires d'adresse de Shopware 6 : checkout, carnet d'adresses du compte client et inscription. Le client tape le début de son adresse,…
## Présentation
DfAddressAutocomplete ajoute une recherche d'adresse instantanée aux formulaires d'adresse de Shopware 6 : checkout, carnet d'adresses du compte client et inscription. Le client tape le début de son adresse, sélectionne une suggestion et tous les champs se remplissent automatiquement — rue, complément, code postal, ville et pays.
Deux providers sont inclus : **BAN** (Base Adresse Nationale, gratuit, France) et **Google Places (New)** (payant, mondial). L'architecture est extensible : n'importe quelle API d'adresse peut être branchée via une interface PHP.
## Prérequis
- Shopware 6.6 ou 6.7
- PHP 8.2 minimum
- Pour Google Places : une clé API Google Cloud avec la **Places API (New)** activée (pas l'ancienne Places API)
## Installation
1. Uploadez le ZIP dans `custom/plugins/` ou via l'admin Shopware (Extensions → Mes extensions → Uploader une extension).
2. Exécutez les commandes suivantes :
```
bin/console plugin:refresh
bin/console plugin:install --activate DfAddressAutocomplete
bin/console cache:clear
```
1. Compilez le storefront pour que le JavaScript et le CSS soient intégrés :
```
./bin/build-storefront.sh
```
Sur les environnements sans script de build, utilisez `bin/console theme:compile` après avoir compilé les assets une première fois.
## Configuration
Rendez-vous dans **Extensions → Mes extensions → DfAddressAutocomplete → Configurer**. Tous les réglages sont scopables par sales channel.
### Fournisseur
- **Fournisseur d'auto-complétion** : BAN (par défaut) ou Google Places.
- **Clé API Google Places** : requise uniquement si Google est sélectionné. La clé reste côté serveur et n'est jamais envoyée au navigateur.
- **Restriction pays** : codes ISO 3166-1 alpha-2 séparés par des virgules (ex. `FR,BE,LU,CH`). Vide = aucune restriction. La restriction ne s'applique qu'à Google (BAN est France uniquement par nature).
### Pages d'activation
Trois interrupteurs indépendants : **checkout**, **compte client** (carnet d'adresses) et **inscription**. Chacun s'active ou se désactive séparément.
### Comportement
- **Caractères minimum** (défaut 3) : aucune recherche en dessous de ce seuil.
- **Délai anti-rebond** (défaut 250 ms) : temps d'attente après la dernière frappe avant d'interroger l'API.
- **Suggestions maximum** (défaut 5).
- **Cache serveur** (activé par défaut) : 5 minutes sur les recherches, 15 minutes sur les détails. Réduit la facturation Google et la latence.
## Configurer Google Places
1. Dans la [Google Cloud Console](https://console.cloud.google.com/), créez ou sélectionnez un projet.
2. Activez la **Places API (New)** — attention, pas l'ancienne « Places API ».
3. Créez une clé API et restreignez-la **par adresse IP de serveur** (celle de votre hébergement Shopware). Ne la restreignez pas par référent HTTP : le trafic est server-to-server.
4. Collez la clé dans la configuration du plugin.
L'API Places (New) est facturée à l'usage. Le cache serveur du plugin et l'anti-rebond limitent le nombre d'appels, mais surveillez votre consommation dans la console Google.
## Fonctionnement côté client
Un champ de recherche apparaît au-dessus du formulaire d'adresse standard. La navigation clavier est complète : flèches haut/bas pour parcourir les suggestions, Entrée pour sélectionner, Échap pour fermer. À la sélection, les champs Shopware standards sont remplis et le pays est sélectionné automatiquement dans le menu déroulant.
## Ajouter un provider personnalisé
Implémentez l'interface `AutocompleteProviderInterface` (namespace `DataFirefly\DfAddressAutocomplete\Provider`) dans votre propre plugin :
```
final class MapboxProvider implements AutocompleteProviderInterface
{
public function getKey(): string { return 'mapbox'; }
public function search(string $query, int $limit, string $salesChannelId, array $countryCodes = []): array
{
// Interrogez votre API et retournez un tableau d'AddressSuggestion
}
public function details(string $id, string $salesChannelId): ?AddressDetails
{
// Résolvez l'id en AddressDetails complet
}
}
```
Puis taguez le service dans votre services.xml (id du service = classe complète de votre provider) :
```
```
Chaque suggestion embarque le préfixe de son provider dans son id (ex. `mapbox:abc123`) : le routage des appels de détail est automatique.
## Thèmes personnalisés
Le plugin étend le composant standard `component_address_form` et détecte les champs par leur nom (`*AddressStreet`, `*AddressZipcode`, `*AddressCity`, `*AddressCountry`). Si votre thème renomme ces champs, surchargez la méthode `_cacheTargetFields` du plugin JavaScript pour lui indiquer les nouveaux noms.
## Dépannage
- **Le champ de recherche n'apparaît pas** : vérifiez que le storefront a bien été recompilé après l'activation, et que la page concernée est activée dans la configuration.
- **Aucune suggestion avec Google** : vérifiez que la Places API (New) est activée sur le projet, que la clé est valide et que sa restriction IP correspond à l'IP de votre serveur.
- **Le pays ne se sélectionne pas** : le plugin compare le code ISO avec l'attribut `data-country-iso` des options du menu déroulant, puis avec leur texte visible. Si votre thème n'expose ni l'un ni l'autre, le pays courant est conservé.
## Confidentialité (RGPD)
Le plugin ne stocke aucune donnée personnelle. Les saisies de l'utilisateur transitent par votre serveur Shopware vers le provider choisi. Avec BAN, les données sont traitées par un service public français (DINUM). Avec Google, elles sont soumises aux conditions de Google Cloud — mentionnez-le dans votre politique de confidentialité si nécessaire.
---
### dfaimetagen — Générateur IA de méta titles, descriptions & ALT
_Source :_
> Présentation dfaimetagen génère en masse vos meta titles, meta descriptions et balises ALT d'images via IA (Anthropic Claude, OpenAI GPT ou Mistral) sur PrestaShop 8 et 9. Le module couvre…
## Présentation
dfaimetagen génère en masse vos meta titles, meta descriptions et balises ALT d'images via IA (Anthropic Claude, OpenAI GPT ou Mistral) sur PrestaShop 8 et 9. Le module couvre 6 types d'entités (produits, catégories, pages CMS, fabricants, fournisseurs, images produits), applique des patterns CTR éprouvés, produit des variantes A/B, contrôle les longueurs SERP et rejette les doublons via similarité Jaccard.
## Prérequis
- PrestaShop 8.0 à 9.x
- PHP 8.1, 8.2, 8.3 ou 8.4
- Extensions PHP : curl, json, iconv
- MySQL 5.7+ ou MariaDB 10.3+
- Une clé API auprès d'au moins un provider : [Anthropic](https://console.anthropic.com), [OpenAI](https://platform.openai.com) ou [Mistral](https://console.mistral.ai)
## Installation
1. Téléchargez le fichier `dfaimetagen.zip` depuis votre compte client.
2. Dans le back-office PrestaShop, allez dans **Modules > Module Manager > Ajouter un nouveau module**.
3. Téléversez le ZIP et cliquez sur **Installer**.
4. Le module crée 6 tables en base (préfixe `df_aimeta_`), installe 11 patterns CTR par défaut et génère un token CRON aléatoire.
5. Un nouvel onglet **AI Meta Generator** apparaît sous le menu **Catalogue**.
## Configuration du provider IA
1. Allez dans **Catalogue > AI Meta Generator > Paramètres**.
2. Sélectionnez votre provider actif : Anthropic (recommandé pour le français), OpenAI ou Mistral.
3. Collez votre clé API dans le champ correspondant.
4. Cliquez sur le bouton **Test** à côté du champ pour vérifier la connectivité — vous devez recevoir la réponse « OK ».
5. Les modèles par défaut sont `claude-sonnet-4-5`, `gpt-4o-mini` et `mistral-large-latest`. Vous pouvez les modifier si vous préférez un autre modèle du même provider.
Les clés API sont stockées dans la table Configuration de PrestaShop et ne sont jamais exposées côté front-office. Le module n'inclut pas de crédits IA : chaque génération consomme votre propre quota chez le provider (environ 0,0005 à 0,003 € par génération).
## Réglages de génération
Toujours dans **Paramètres**, vous pouvez ajuster :
- **Limites de longueur** — par défaut alignées sur les recommandations Google SERP : meta title 35–60 caractères, meta description 120–158, ALT 25–125. Si l'IA dépasse, le texte est tronqué proprement sur une frontière de mot.
- **Variantes A/B par item** — de 1 à 5 alternatives générées par entité et par langue.
- **Seuil anti-duplication** — pourcentage de similarité Jaccard au-delà duquel une variante est rejetée (85 % par défaut). La comparaison est insensible aux accents.
- **Taille de lot** — nombre d'items traités par tick AJAX ou CRON (10 par défaut, jusqu'à 100).
- **Timeout HTTP** — délai maximal d'attente d'une réponse du provider (60 s par défaut).
- **Écrasement / Ignorer les non-vides** — comportement par défaut face aux méta déjà renseignées.
## Lancer une génération en masse
1. Allez dans **Catalogue > AI Meta Generator > Bulk Generation**.
2. **Entité** : produits, catégories, pages CMS, fabricants, fournisseurs ou images produits.
3. **Champ** : meta title, meta description ou ALT d'image (les ALT s'appliquent aux images produits).
4. **Pattern CTR** : choisissez un pattern précis ou laissez _Auto_ pour utiliser le pattern par défaut du champ.
5. **Langues** : sélection multiple — la génération est multipliée (items × langues).
6. **Scope** : toutes les entités, par liste d'IDs, ou par filtre catégorie / fabricant.
7. **Limite** : fixez 10 ou 20 pour un test, 0 pour tout traiter.
8. Cliquez sur **Créer le job**.
Commencez toujours par un job limité à 10–20 items pour valider le ton et le format des textes générés, ajustez le pattern ou le template si besoin, puis relancez sans limite.
## Suivre et exécuter les jobs
La page **Jobs** liste tous les jobs avec leur progression, leurs statistiques (réussis / échoués / ignorés) et leur statut. Trois modes d'exécution :
- **Exécuter jusqu'à terminé** (page détail du job) — traite les lots en boucle via AJAX avec barre de progression en direct. Gardez l'onglet ouvert.
- **Exécuter un lot** — traite un seul lot puis recharge la page.
- **CRON** — traitement en arrière-plan, recommandé pour les gros catalogues (voir ci-dessous).
Un job peut être annulé en cours, relancé depuis le début, ou supprimé. L'historique complet de chaque génération (statut, tokens entrée/sortie, erreur éventuelle) est conservé dans l'onglet Historique du détail du job.
## Configurer le CRON
1. Dans **Paramètres**, section CRON, copiez l'URL affichée. Elle a la forme : `https://votre-boutique.com/modules/dfaimetagen/cron.php?token=VOTRE_TOKEN`
2. Ajoutez-la à votre crontab serveur, par exemple toutes les 5 minutes : `*/5 * * * * curl -s "https://votre-boutique.com/modules/dfaimetagen/cron.php?token=VOTRE_TOKEN" >/dev/null`
3. Chaque passage traite jusqu'à 5 lots du job en attente le plus ancien. Paramètres optionnels : `&batch=20` (taille de lot) et `&loops=10` (nombre de lots par passage).
Le token protège l'endpoint : ne le partagez pas. En cas de doute, régénérez-le depuis les Paramètres (bouton « Regénérer le token ») — pensez alors à mettre à jour votre crontab.
## Variantes A/B et activation
Chaque génération produit le nombre de variantes configuré (1 à 5). La première variante valide est écrite sur l'entité et marquée **Active**. Les autres restent en réserve dans la page de détail du job :
- Cliquez sur **Activer** à côté d'une variante pour l'écrire immédiatement sur l'entité.
- Les autres variantes du même triplet (entité, champ, langue) sont automatiquement désactivées.
- Le compteur de caractères de chaque variante permet de vérifier la conformité SERP d'un coup d'œil.
## Patterns CTR
Les 11 patterns préinstallés couvrent trois familles :
- **Meta titles** : bénéfice + année, liste numérotée, crochets USP, question hook, mots de pouvoir.
- **Meta descriptions** : empilement de bénéfices, social proof, problem-solution, CTA direct.
- **ALT d'images** : descriptif, contextuel.
Pour créer vos propres patterns, allez dans **Catalogue > AI Meta Generator > Patterns**. Le template accepte des tokens dynamiques :
- `{NAME}`, `{BRAND}`, `{CATEGORY}`, `{PRICE}`, `{YEAR}`, `{NUMBER}`, `{LANG_NAME}` — remplis automatiquement par le module ;
- `{BENEFIT}`, `{USP}`, `{CONTEXT}` — remplis par l'IA au moment de la génération.
Les patterns marqués « système » sont livrés avec le module et préservés lors des mises à jour.
## Templates de prompts avancés
Pour un contrôle total du comportement de l'IA, créez des templates dans **Catalogue > AI Meta Generator > Prompt Templates**. Chaque template cible un triplet (entité, champ, langue — ou toutes les langues) et définit :
- le **system prompt** — rôle, ton, contraintes globales ;
- le **user prompt** — avec les tokens `{NAME}`, `{BRAND}`, `{CATEGORY}`, `{DESCRIPTION}`, `{PRICE}`, `{PATTERN}`, `{LANG_NAME}`, `{MIN_LENGTH}`, `{MAX_LENGTH}`, `{AB_VARIANTS}`, `{EXISTING}`.
Marquez un template « par défaut » pour qu'il s'applique automatiquement à son triplet.
## Anti-duplication
Avant de conserver une variante, le module la compare aux variantes déjà stockées :
1. **Hash exact** (sha1 de la version normalisée) — rejet immédiat en cas de duplicata parfait.
2. **Similarité Jaccard** sur les ensembles de mots normalisés (minuscules, sans accents) — rejet si la similarité dépasse le seuil configuré.
Une variante rejetée est automatiquement régénérée par l'IA (dans la limite des tentatives du lot).
## Tableau de bord
La page **Dashboard** agrège : nombre de jobs (total, en attente, terminés), variantes générées et actives, générations réussies / échouées, tokens consommés (entrée + sortie), derniers jobs et dernières générations. Utilisez-la pour surveiller le budget IA et détecter les erreurs de provider.
## Multi-boutique
Le module lit et écrit les valeurs en tenant compte du contexte boutique lorsque la table `*_lang` concernée possède une colonne `id_shop`. Sélectionnez la boutique cible dans le formulaire de génération en masse si votre installation est multi-boutique.
## Dépannage
- **« FAIL » au test de connectivité** — vérifiez la clé API, le solde de crédits du provider, et que votre serveur autorise les connexions HTTPS sortantes (cURL) vers api.anthropic.com, api.openai.com ou api.mistral.ai.
- **Job bloqué en « running »** — relancez un lot manuellement depuis la page détail, ou attendez le prochain passage CRON. Un job peut toujours être annulé puis relancé.
- **Variantes vides ou tronquées** — augmentez le timeout HTTP dans les Paramètres, ou choisissez un modèle plus rapide.
- **403 sur l'URL CRON** — le token de l'URL ne correspond plus (il a peut-être été régénéré). Copiez à nouveau l'URL depuis les Paramètres.
- **Rien ne se génère pour certaines entités** — si « Ignorer les non-vides » est actif, les entités déjà renseignées sont sautées volontairement. Cochez « Écraser » pour forcer.
## Désinstallation
La désinstallation supprime les 6 tables du module et ses clés de configuration. Les méta générées et déjà écrites sur vos produits, catégories et images sont conservées : elles font partie de votre catalogue.
---
### dfbackup — Sauvegarde PrestaShop 8 & 9 : guide complet
_Source :_
> Présentation dfbackup est un module de sauvegarde complet pour PrestaShop 8 et 9. Il sauvegarde votre base de données et vos fichiers en pur PHP (sans mysqldump ni shell_exec), chiffre…
## Présentation
dfbackup est un module de sauvegarde complet pour PrestaShop 8 et 9. Il sauvegarde votre base de données et vos fichiers en pur PHP (sans mysqldump ni shell_exec), chiffre optionnellement les archives en AES-256, les envoie vers plusieurs destinations (Local, S3, FTP, Dropbox, réplication PrestaShop) et permet une restauration en un clic avec snapshot de sécurité automatique.
Trois onglets sont ajoutés dans le menu **Paramètres avancés** de votre back-office : **Dashboard** (vue d'ensemble et lancement manuel), **Historique** (liste des sauvegardes, restauration, vérification, suppression) et **Réglages** (planification, stockage, chiffrement, notifications).
## Installation
1. Dans votre back-office, allez dans **Modules > Gestionnaire de modules > Installer un module**.
2. Sélectionnez le fichier `dfbackup-1.0.0.zip` téléchargé après votre achat.
3. Cliquez sur **Installer**. Le module crée quatre tables (`dfbackup`, `dfbackup_log`, `dfbackup_filemap`, `dfbackup_audit`) et le répertoire de stockage `var/dfbackup/` protégé par un .htaccess.
4. Ouvrez **Paramètres avancés > DF Backup** pour accéder au dashboard.
Après chaque mise à jour du module, videz le cache PHP (opcache) et le cache Smarty : **Paramètres avancés > Performances > Vider le cache**. Sur certains hébergements, un redémarrage de PHP-FPM est nécessaire pour recharger le bytecode.
## Lancer une première sauvegarde
Depuis le Dashboard, trois boutons permettent un lancement manuel :
- **Run backup now** — sauvegarde complète (BDD + fichiers) ;
- **Database only** — dump BDD seul, rapide (moins d'une minute sur la plupart des boutiques) ;
- **Files only** — archive des fichiers seule.
La sauvegarde s'exécute en arrière-plan dans son propre process PHP : la page ne bloque pas, et une carte de progression affiche les logs en temps réel avec un pourcentage estimé (dump BDD, archivage fichiers, chiffrement, checksum, upload, rotation). Vous pouvez quitter la page : la sauvegarde continue côté serveur.
## Planification
Dans **Réglages > Planification**, trois fréquences sont proposées :
- **Daily** — chaque jour à l'heure cible (ex. 03:00) ;
- **Weekly** — un jour de la semaine + heure ;
- **Monthly** — un jour du mois + heure.
Une fenêtre de tolérance de 30 minutes et une déduplication de 60 minutes évitent les doubles déclenchements. Deux mécanismes d'exécution coexistent :
### Cron natif PrestaShop
Le hook `actionCronJob` s'exécute lors des visites de la boutique. Suffisant pour les boutiques à trafic régulier, mais non garanti la nuit.
### Web-cron (recommandé)
Une URL signée par token est affichée dans les Réglages, au format :
```
https://votre-boutique.com/index.php?fc=module&module=dfbackup&controller=webcron&token=VOTRE_TOKEN
```
Configurez un service externe gratuit comme [cron-job.org](https://cron-job.org) ou EasyCron pour appeler cette URL toutes les heures (ou toutes les 15 minutes). Le module vérifie en interne si l'heure cible est atteinte et répond immédiatement `QUEUED | id=N` quand une sauvegarde est déclenchée, ou `Not scheduled now.` sinon. La réponse est instantanée — aucun risque de timeout côté service de cron.
Le bouton **Régénérer le token** invalide immédiatement l'ancienne URL. Pensez à mettre à jour votre service de cron externe après régénération.
## Destinations de stockage
Chaque sauvegarde peut être envoyée vers **plusieurs destinations simultanément** — c'est la règle 3-2-1 (trois copies, deux supports, une hors site). Cochez les destinations voulues dans **Réglages > Stockage** :
### Local
Les archives restent dans `var/dfbackup/` sous la racine PrestaShop, protégées par un .htaccess Deny. Toujours actif comme copie de travail.
### Amazon S3 et compatibles
Renseignez Access Key, Secret Key, bucket, région. Le champ **Endpoint** permet d'utiliser n'importe quel service compatible S3 :
- Amazon S3 : laisser l'endpoint vide, indiquer la région (ex. `eu-west-3`) ;
- Cloudflare R2 : `https://ACCOUNT_ID.r2.cloudflarestorage.com`, région `auto` — 10 Go gratuits, zéro coût de sortie ;
- MinIO auto-hébergé : `https://minio.votre-domaine.com` ;
- OVH Object Storage, Scaleway, Wasabi, Backblaze B2 : endpoint fourni par votre hébergeur.
Le multipart upload se déclenche automatiquement au-delà de 100 Mo (parts de 10 Mo) — les archives de plusieurs Go passent sans saturer la mémoire PHP.
### FTP / FTPS
Hôte, port, identifiants, répertoire distant (créé automatiquement s'il n'existe pas), FTPS et mode passif activables.
### Dropbox
Collez un access token généré depuis la [console développeur Dropbox](https://www.dropbox.com/developers/apps) (permission `files.content.write`). Les archives au-dessus de 150 Mo passent automatiquement en upload_session chunké.
Chaque destination dispose d'un bouton **Test** qui vérifie la connexion et les droits d'écriture avant la première sauvegarde réelle.
## Réplication vers un PrestaShop staging
La réplication pousse chaque sauvegarde vers une seconde installation PrestaShop équipée de dfbackup — idéal pour maintenir un environnement de pré-production synchronisé chaque nuit.
### Configuration
1. **Sur la boutique cible (staging)** : installez dfbackup, puis enregistrez un secret partagé (32+ caractères aléatoires) sous la clé de configuration `DFBACKUP_REPLICATION_SECRET` (via Réglages ou Paramètres avancés > Configuration).
2. **Sur la boutique source (prod)** : dans **Réglages > Stockage > Réplication PrestaShop**, renseignez l'URL du staging (ex. `https://staging.example.com`) et le même secret. Cochez **Réplication** parmi les destinations.
3. Cliquez sur **Test replication target** : la cible doit répondre OK.
### Restauration automatique (optionnelle)
Pour que le staging applique automatiquement chaque archive reçue, activez sur la **cible** la clé `DFBACKUP_REPLICATION_AUTO_RESTORE = 1` et cochez l'option correspondante côté source. Le lendemain matin, votre staging reflète la prod de la veille.
L'auto-restore écrase la BDD et les fichiers du staging à chaque réception. Ne l'activez jamais sur une boutique de production. Le flag côté cible est une protection volontairement séparée du secret partagé.
### Sécurité du transport
Les archives sont transférées par chunks de 8 Mo, chacun signé HMAC-SHA-256 (la signature couvre les paramètres et le hash du corps). Un contrôle anti-rejeu rejette toute requête dont le timestamp dévie de plus de 5 minutes.
## Chiffrement AES-256
Dans **Réglages > Chiffrement**, activez la case et définissez une passphrase. Les archives sont alors chiffrées en AES-256-CBC avec HMAC-SHA-256 (pattern encrypt-then-MAC, dérivation PBKDF2 à 120 000 itérations).
- La passphrase n'est **jamais stockée en clair** — seul son hash sert à la vérification lors de la restauration.
- Une archive chiffrée dont la passphrase est perdue est **définitivement irrécupérable**. Stockez la passphrase dans un gestionnaire de mots de passe (Bitwarden, 1Password) avant d'activer l'option.
- Le checksum SHA-256 est calculé sur l'archive avant chiffrement et vérifié à la restauration.
## Restauration
Depuis **Historique**, chaque sauvegarde propose trois actions : **Vérifier** (recalcule le SHA-256), **Restaurer** et **Supprimer**.
### Déroulement d'une restauration
1. Un **snapshot BDD de sécurité** est créé automatiquement avant toute opération.
2. Vous choisissez le périmètre : tout, BDD seule, ou fichiers seuls.
3. Si l'archive est chiffrée, la passphrase est demandée.
4. La BDD est restaurée instruction par instruction ; les fichiers sont extraits par lots.
5. Les tables `dfbackup*` sont **toujours préservées** : votre historique de sauvegardes survit à la restauration.
### Mode migration (changement de domaine)
Cochez **Mode migration** et indiquez le nouveau domaine : le module met à jour `PS_SHOP_DOMAIN`, `PS_SHOP_DOMAIN_SSL`, la table `shop_url` et réécrit les URLs hardcodées dans les contenus CMS, produits et meta. Pratique pour cloner une boutique en pré-prod ou déménager de domaine.
Après une restauration, videz systématiquement le cache (Performances > Vider le cache) et vérifiez la page d'accueil en navigation privée.
## Rotation et rétention
Deux règles cumulatives dans **Réglages > Rétention** :
- **Garder N sauvegardes** — au-delà, les plus anciennes sont supprimées ;
- **Supprimer après X jours** — indépendamment du nombre.
Seules les sauvegardes en statut `completed` ou `verified` sont comptées et purgées ; les snapshots pré-restauration et pré-upgrade suivent les mêmes règles.
## Notifications et alertes
- **Email** — envoi via `Mail::Send` (vos réglages SMTP PrestaShop sont respectés) en cas de succès et/ou d'échec, templates FR/EN/ES/DE.
- **Webhook** — collez une URL Slack, Discord ou Microsoft Teams : le format est auto-détecté. Toute autre URL reçoit un JSON générique.
- **Alerte back-office** — un bandeau apparaît en tête de toutes les pages admin si la dernière sauvegarde a échoué (rouge) ou date de plus de 7 jours (jaune).
- **Snapshot pré-upgrade** — une sauvegarde BDD est lancée automatiquement avant chaque mise à jour de module (hook `actionAdminModulesUpgradeBefore`), désactivable dans les Réglages.
## Exclusions de fichiers
Le module exclut d'office `var/dfbackup`, `var/cache`, `.git`, `node_modules` et le dossier autoupgrade. Vous pouvez ajouter vos propres chemins et patterns glob (ex. `img/tmp/*`, `*.log`) dans **Réglages > Exclusions**. Le mode incrémental (fichiers modifiés uniquement, détection par empreinte chemin + taille + date) réduit fortement la taille des sauvegardes intermédiaires.
## Dépannage
### Une sauvegarde reste bloquée en "running"
Si le process a été tué (redémarrage serveur), la ligne sera marquée en échec au prochain lancement grâce au verrou `flock`. Vous pouvez aussi la supprimer depuis l'Historique.
### "Another backup is already running"
Un verrou fichier empêche deux sauvegardes simultanées. Attendez la fin de la sauvegarde en cours (visible dans le Dashboard) ou vérifiez qu'un cron externe ne tourne pas au même moment qu'un lancement manuel.
### La sauvegarde échoue sur une grosse boutique
Augmentez **Max execution time** et **Memory limit** dans les Réglages (le module les applique à son propre process). Activez le mode incrémental pour les fichiers et excluez les répertoires volumineux inutiles (exports, logs).
### Les modifications du module ne semblent pas prises en compte
C'est presque toujours l'opcache PHP qui sert l'ancien bytecode. Videz le cache PrestaShop _et_ redémarrez PHP-FPM (ou attendez l'expiration de l'opcache).
### L'URL de web-cron renvoie une 404
Utilisez l'URL au format dispatcher (`index.php?fc=module&module=dfbackup&controller=webcron`) affichée dans les Réglages — certains hébergements bloquent l'accès direct aux fichiers PHP sous `/modules/`.
## Désinstallation
La désinstallation supprime les quatre tables et toutes les configurations. Les archives présentes dans `var/dfbackup/` ne sont **pas** supprimées automatiquement — téléchargez vos sauvegardes récentes avant de désinstaller si vous comptez réinstaller plus tard.
---
### DfBackup SW — Guide complet
_Source :_
> DfBackup SW est un système de sauvegarde production-grade pour Shopware 6.5, 6.6 et 6.7, sans aucune dépendance externe : pas de mysqldump, pas de shell_exec, pas de SDK Amazon. Il…
DfBackup SW est un système de sauvegarde production-grade pour Shopware 6.5, 6.6 et 6.7, sans aucune dépendance externe : pas de mysqldump, pas de shell_exec, pas de SDK Amazon. Il sauvegarde la base de données et les fichiers en pur PHP, chiffre les archives en AES-256 authentifié, les pousse vers Local, S3, FTP ou Dropbox, et sait même répliquer chaque sauvegarde vers un second Shopware staging. La restauration se fait en un clic, avec un snapshot de sécurité automatique. Ce guide couvre l'installation, l'exécution en arrière-plan, le chiffrement, les backends de stockage, la réplication, la restauration, la planification et le dépannage.
## Installation
1. Téléchargez l'archive `DfBackup-SW-1.0.0.zip` depuis votre compte DataFirefly.
2. Copiez le dossier décompressé `DfBackup` dans `custom/plugins/` de votre Shopware, ou installez le ZIP via **Administration → Extensions → Mes extensions → Charger l'extension**.
3. Lancez l'installation et l'activation : ``` bin/console plugin:refresh bin/console plugin:install --activate DfBackup bin/console cache:clear ```
4. À l'installation, le plugin crée ses quatre tables (`df_backup`, `df_backup_log`, `df_backup_filemap`, `df_backup_audit`) et enregistre sa ScheduledTask.
Compatible Shopware 6.5.x, 6.6.x et 6.7.x sur un seul codebase, PHP 8.1 à 8.3. Extensions PHP requises : `zip` et `openssl` (toujours), `curl` (S3, Dropbox, réplication) et `ftp` (backend FTP/FTPS). Aucune dépendance Composer supplémentaire.
## Où trouver le plugin dans l'administration
Après activation, un module d'administration dédié **DfBackup** apparaît dans le menu. Il regroupe la liste des sauvegardes, le bouton **Sauvegarder maintenant**, la progression en temps réel, et l'accès aux actions par sauvegarde (vérifier, télécharger, protéger, restaurer, supprimer). La configuration (planification, chiffrement, backends, réplication, notifications) se fait dans la configuration du plugin via **Extensions → Mes extensions → DfBackup → ⋯ → Configurer**.
## Exécution en arrière-plan : Messenger, ScheduledTask et web-cron
Une sauvegarde ne bloque jamais l'interface. Le clic sur **Sauvegarder maintenant** pré-alloue une ligne, dispatche un message asynchrone Symfony Messenger et retourne immédiatement l'identifiant. Le travail réel s'exécute dans le worker, et l'administration affiche la progression en direct via 15 jalons (démarrage, dump BDD, archivage, chiffrement, checksum, upload par backend, rotation).
### Worker recommandé en production
Pour les boutiques de production, faites tourner un consumer Messenger supervisé en permanence :
```
bin/console messenger:consume async --time-limit=300 --memory-limit=512M
```
Placez-le sous systemd ou supervisor pour qu'il redémarre automatiquement. C'est la configuration qui permet d'exécuter les sauvegardes sans aucune limite de temps web.
### ScheduledTask
Une ScheduledTask native s'exécute toutes les 10 minutes et sert de porte d'entrée à la planification : elle vérifie si une sauvegarde planifiée doit partir et, le cas échéant, dispatche le message. Elle dépend du scheduler Shopware, lui-même actionné par le worker ou par le cron Shopware.
### Web-cron de secours
Sur les hébergements sans accès CLI ni worker permanent, activez le web-cron : une URL signée par token (régénérable depuis la configuration) qu'un service externe comme cron-job.org appelle toutes les 10 à 15 minutes. La porte de planification interne (fenêtre de 30 minutes, déduplication de 60 minutes) évite les doubles déclenchements.
Si la page d'administration est fermée pendant une sauvegarde, le processus continue dans le worker. Rouvrez le module DfBackup pour retrouver la progression et le résultat.
## Le dump base de données, pensé pour Shopware
Un dump SQL naïf casse sur Shopware. DfBackup SW gère nativement les particularités du schéma :
- Les **colonnes générées** (STORED ou VIRTUAL) sont exclues des INSERT, car MySQL refuse qu'on les écrive.
- Les **colonnes binaires** — dont les clés primaires UUID en BINARY 16, omniprésentes dans Shopware — sont émises en littéraux hexadécimaux `0x…` pour une réimportation parfaitement fidèle.
- La **pagination keyset** sur clé primaire entière permet de dumper les très grosses tables (order, log_entry) sans saturer la mémoire.
- Les **vues** sont recréées en dernier, après toutes les tables.
Le dump est chunké (500 lignes par lot) et le fichier produit se réimporte proprement, instruction par instruction, avec `FOREIGN_KEY_CHECKS` désactivé pendant l'import.
## La sauvegarde des fichiers
Les fichiers sont archivés via `ZipArchive` avec des exclusions glob configurables (par défaut `var/cache`, `var/log`, `node_modules`, miniatures…). Le mode incrémental optionnel s'appuie sur un `sha1` de path + size + mtime suivi en base : seules les fichiers modifiés depuis la dernière sauvegarde complète sont réarchivés.
## Chiffrement AES-256
Le chiffrement est optionnel mais fortement recommandé pour les archives stockées hors site. DfBackup SW applique un schéma AES-256-CBC plus HMAC-SHA-256 selon le pattern encrypt-then-MAC :
- La passphrase passe par PBKDF2-SHA256 avec 120 000 itérations pour dériver des clés de chiffrement et de HMAC séparées.
- Le chiffrement est réalisé en streaming par blocs de 1 Mio : une archive de plusieurs Go se chiffre avec une empreinte mémoire constante.
- À la lecture, le HMAC est vérifié **avant** tout déchiffrement (protection contre les attaques padding oracle et bit-flip).
- Un SHA-256 indépendant garantit l'intégrité du fichier brut (statut `verified` ou `corrupted` en base).
Si la passphrase est perdue, les archives chiffrées deviennent définitivement irrécupérables — c'est la garantie même du chiffrement authentifié. Stockez la passphrase dans un gestionnaire de mots de passe externe (Bitwarden, 1Password) avant d'activer le chiffrement.
## Backends de stockage
Chaque sauvegarde peut être envoyée vers un ou plusieurs backends simultanément, pour appliquer la règle 3-2-1 :
- **Local** : sous `var/df-backup`, avec protection anti-listing.
- **Amazon S3 et compatibles** : signature AWS V4 native (sans SDK), multipart upload automatique au-delà de 100 Mo (parts de 10 Mo). Compatible MinIO, Wasabi, Cloudflare R2, OVH, Scaleway, Backblaze B2 via la surcharge d'endpoint et de région.
- **FTP et FTPS** : mode passif, création automatique du répertoire distant.
- **Dropbox v2** : REST avec `upload_session` chunké pour les archives au-dessus de 150 Mo.
Cloudflare R2 offre 10 Go gratuits avec zéro coût de sortie : un excellent backend distant pour des sauvegardes chiffrées. Renseignez l'endpoint R2 et la région `auto` dans la configuration S3.
## Réplication vers un Shopware staging
C'est la fonction qui distingue DfBackup SW : pousser chaque sauvegarde vers une seconde installation Shopware équipée du même plugin.
1. Installez DfBackup SW sur la prod **et** sur le staging.
2. Générez un secret commun (longue chaîne aléatoire) et renseignez-le des deux côtés.
3. Côté prod, activez **Réplication** comme destination et indiquez l'URL du staging.
À chaque sauvegarde, l'archive est uploadée par chunks de 8 Mo signés HMAC-SHA-256 vers des endpoints dédiés sur la cible (chunk, commit, delete, ping), avec anti-rejeu par horodatage à tolérance de 5 minutes. Si l'option auto-restore est activée côté staging, l'archive est appliquée automatiquement — votre staging reflète la prod de la veille dès le lendemain matin.
Combinée à la migration de domaine (voir ci-dessous), la réplication donne un clone immédiatement navigable sur son propre domaine, sans rsync ni scripts cron sysadmin.
## Restauration 1-clic
Depuis la liste des sauvegardes, le bouton **Restaurer** ouvre une modale :
1. Choisissez le périmètre : **tout**, **BDD seule** ou **fichiers seuls**.
2. Pour confirmer, tapez le mot `RESTORE` — garde-fou contre les fausses manipulations.
3. Optionnellement, activez le **mode migration de domaine** et indiquez le nouveau domaine.
Avant toute restauration, un snapshot BDD protégé est créé automatiquement : si la restauration échoue à mi-chemin, vous revenez à l'état initial en quelques minutes. Les tables du plugin (`df_backup*`) ne sont jamais écrasées — votre historique de sauvegardes est préservé même en restaurant une version d'il y a six mois.
Une restauration écrase la base et les fichiers en place. Vérifiez le périmètre sélectionné et évitez de restaurer une version ancienne sur une prod qui a continué d'enregistrer des commandes, sauf migration maîtrisée.
### Migration de domaine
En mode migration, le plugin réécrit les `sales_channel_domain` et applique un remplacement best-effort sur les colonnes texte des tables de traduction (CMS, produits, catégories) ainsi que sur `seo_url`, pour que le clone soit immédiatement navigable sur son propre domaine.
## Planification, rotation et mode maintenance
- **Fréquences** : daily (heure cible), weekly (jour + heure), monthly (jour du mois + heure). Fenêtre de tolérance de 30 minutes et déduplication de 60 minutes.
- **Rotation** : par nombre de sauvegardes à conserver et par âge en jours. Les sauvegardes marquées **protégées** (snapshots pré-restauration notamment) ne sont jamais rotatées.
- **Mode maintenance** optionnel : bascule les sales channels en maintenance pendant le dump BDD pour une cohérence transactionnelle parfaite, utile sur les boutiques à très fort volume de commandes.
## Notifications et audit
- **Email** via Symfony Mailer (succès, échec, ou les deux au choix).
- **Webhook** avec auto-détection du format : Slack, Discord, Microsoft Teams ou JSON générique.
- **Alerte** dans le module si aucune sauvegarde réussie depuis N jours.
- **Journal d'audit** : chaque action sensible (lancement, restauration, suppression, vérification, téléchargement) est tracée avec utilisateur admin, IP et horodatage.
## FAQ et dépannage
**Le plugin fonctionne-t-il sans shell_exec ?** Oui. Aucun appel à shell_exec, exec, passthru ni mysqldump. Tout est en pur PHP (DBAL, ZipArchive, cURL, fonctions ftp natives).
**Mes sauvegardes ne partent pas automatiquement.** Vérifiez qu'un worker Messenger tourne (ou que le web-cron est appelé régulièrement) et que la ScheduledTask DfBackup est active dans Shopware. Sans worker ni web-cron, la planification ne peut pas s'exécuter.
**Le dump échoue sur une grosse table.** La pagination keyset gère normalement les grosses tables ; assurez-vous que la clé primaire entière est présente et augmentez la mémoire du worker si nécessaire (`--memory-limit`).
**Une archive ressort en statut corrupted.** Le SHA-256 ne correspond pas : l'upload ou l'écriture a été tronqué. Relancez la sauvegarde et vérifiez l'espace disque et les quotas du backend distant.
**Comment vérifier une sauvegarde sans la restaurer ?** Le bouton **Vérifier** recalcule le SHA-256 et, pour les archives chiffrées, contrôle le HMAC — sans rien restaurer.
**Que se passe-t-il à la désinstallation ?** Avec l'option de suppression des données, les quatre tables `df_backup*` sont supprimées et la configuration effacée. Les fichiers sous `var/df-backup` ne sont pas supprimés automatiquement : téléchargez vos sauvegardes récentes avant de désinstaller.
---
### dfbulkcategory — Affectation de catégories en masse
_Source :_
> Présentation dfbulkcategory ajoute deux actions groupées dans la liste produit du back-office PrestaShop : Ajouter à une catégorie et Retirer d'une catégorie. Sélectionnez vos produits avec les cases à cocher…
## Présentation
dfbulkcategory ajoute deux actions groupées dans la liste produit du back-office PrestaShop : **Ajouter à une catégorie** et **Retirer d'une catégorie**. Sélectionnez vos produits avec les cases à cocher natives, choisissez une ou plusieurs catégories dans une modale avec arbre et recherche, confirmez — l'opération s'exécute en AJAX sans rechargement de page.
Le module est compatible **PrestaShop 8.0.0 à 9.99.99** et fonctionne en multiboutique. Il ne crée aucune table SQL et ne modifie aucun fichier core.
## Installation
1. Téléchargez le fichier ZIP du module depuis votre compte DataFirefly.
2. Dans le back-office PrestaShop, allez dans **Modules → Gestionnaire de modules → Installer un module**.
3. Glissez-déposez le fichier `dfbulkcategory.zip` et validez.
4. Le module est prêt immédiatement : aucune configuration n'est requise.
À l'installation, le module enregistre un onglet admin caché nécessaire aux contrôles d'accès de PrestaShop 9. Aucune entrée visible n'est ajoutée à votre menu back-office.
### Mise à jour depuis la version 1.0.0
Remplacez simplement le module par la nouvelle version via **Installer un module** (ou le bouton Mettre à jour). Un script d'upgrade s'exécute automatiquement et installe l'onglet admin requis par PrestaShop 9 sur les installations existantes. Aucune action manuelle n'est nécessaire.
## Utilisation
### Ajouter des produits à des catégories
1. Ouvrez **Catalogue → Produits**.
2. Cochez les produits à modifier (la case d'en-tête sélectionne toute la page).
3. Ouvrez le menu **Actions groupées** et cliquez sur **Ajouter à une catégorie**.
4. Dans la modale, cochez une ou plusieurs catégories dans l'arbre, puis cliquez sur **Appliquer**.
Les catégories cochées sont ajoutées aux catégories existantes de chaque produit — rien n'est écrasé.
### Retirer des produits de catégories
Même principe avec l'onglet **Retirer d'une catégorie** de la modale. Les catégories cochées sont retirées de chaque produit sélectionné.
La catégorie par défaut d'un produit n'est jamais supprimée : si elle fait partie des catégories à retirer, le module la conserve automatiquement pour que le produit garde toujours une catégorie principale.
### Mode combiné (ajouter et retirer en une opération)
L'onglet **Les deux** affiche deux panneaux côte à côte : à gauche les catégories à ajouter, à droite celles à retirer. C'est le mode idéal pour déplacer des produits d'une catégorie vers une autre en une seule confirmation.
### Recherche et navigation dans l'arbre
Le champ de recherche filtre l'arbre en temps réel et déplie automatiquement les branches contenant des résultats. Les boutons **Déployer tout** et **Réduire tout** permettent de naviguer rapidement dans les grandes arborescences.
### Catégories désactivées
Par défaut, seules les catégories actives sont affichées. Activez l'interrupteur **Afficher les catégories désactivées** en haut de la modale pour les inclure — utile pendant une restructuration de catalogue. Les catégories désactivées sont signalées par un badge.
## Multiboutique
Chaque opération s'exécute dans le contexte de la boutique active en back-office :
- L'arbre de catégories affiché est celui de la boutique en cours.
- Le module vérifie que chaque produit sélectionné appartient bien à cette boutique avant modification.
- Les associations de catégories des autres boutiques ne sont pas affectées.
En contexte « Toutes les boutiques », sélectionnez d'abord une boutique précise dans le sélecteur multiboutique pour cibler correctement les associations.
## Compatibilité PrestaShop 9
Depuis la version 1.1.0, le module est entièrement compatible PrestaShop 9 :
- Les URLs AJAX sont générées côté serveur selon le mécanisme attendu par PrestaShop 9 (jeton inclus).
- Un onglet admin caché est enregistré pour satisfaire les contrôles d'accès renforcés — les employés non super-administrateurs peuvent utiliser le module dès lors qu'ils ont accès au catalogue.
- Le fonctionnement sur PrestaShop 8.0, 8.1 et 8.2 reste inchangé.
## Dépannage
### Les boutons n'apparaissent pas dans le menu Actions groupées
Videz le cache PrestaShop (**Paramètres avancés → Performances → Vider le cache**) et rechargez la page produits avec Ctrl+F5. Vérifiez aussi que le module est bien installé et activé dans le Gestionnaire de modules.
### Erreur « Accès refusé » lors de l'application
Sur PrestaShop 9, cette erreur indique généralement que l'onglet admin du module est manquant (installation antérieure à la 1.1.0). Réinstallez le module ou appliquez la mise à jour : le script d'upgrade recrée l'onglet automatiquement.
### Un produit n'a pas été modifié
Le message de résultat détaille les produits ignorés. Les causes habituelles : le produit n'est pas associé à la boutique active (multiboutique), ou il a été supprimé entre la sélection et la confirmation.
## Changelog
### 1.1.0 — 2 juillet 2026
- Compatibilité PrestaShop 9 (plage supportée : 8.0.0 — 9.99.99)
- URLs AJAX générées côté serveur (conformes PS9)
- Onglet admin caché enregistré à l'installation pour les contrôles d'accès de PrestaShop 9
- Script de mise à jour automatique pour les installations 1.0.0 existantes
- Libellés de catégories systématiquement filtrés par boutique
- Affichage sécurisé des messages d'erreur dans la modale
### 1.0.0 — 11 février 2026
- Première version publique
- Actions groupées Ajouter / Retirer dans la liste produit
- Modale avec arbre de catégories, recherche en temps réel, mode combiné
- Option catégories désactivées, gestion multiboutique, préservation de la catégorie par défaut
---
### dfbundlevisual — Souvent achetés ensemble
_Source :_
> Présentation dfbundlevisual affiche sur la fiche produit un bloc « Souvent achetés ensemble » façon Amazon : des cartes produits cochables séparées par des « + », un prix total…
## Présentation
dfbundlevisual affiche sur la fiche produit un bloc « Souvent achetés ensemble » façon Amazon : des cartes produits cochables séparées par des « + », un prix total recalculé en direct et un bouton unique pour ajouter la sélection au panier. Une remise de lot (pourcentage ou montant fixe TTC) est appliquée automatiquement lorsque le lot complet est au panier. Sans lot manuel, le module peut suggérer les produits réellement achetés ensemble d'après votre historique de commandes.
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules > Installer un module**.
2. Téléversez le fichier `dfbundlevisual.zip` puis cliquez sur **Installer**.
3. Le module crée ses tables, son onglet **Catalogue > Lots visuels** et s'enregistre sur les hooks nécessaires.
Compatible PrestaShop 8.0 à 9.x, mono et multiboutique. Aucune dépendance : ni Composer, ni framework, ni jQuery.
## Configuration
Ouvrez la page de configuration du module (**Modules > Gestionnaire de modules > dfbundlevisual > Configurer**) :
- **Activer le module** : interrupteur général du bloc front.
- **Point d'accroche d'affichage** : `displayFooterProduct` (pied de fiche produit, recommandé) ou `displayProductAdditionalInfo` (sous le bouton d'achat, selon le thème).
- **Titre du bloc** : personnalisable par langue. Par défaut « Souvent achetés ensemble » en français.
- **Activer les suggestions automatiques** : affiche des suggestions par co-achat lorsqu'aucun lot manuel n'existe pour le produit consulté.
- **Nombre max de suggestions automatiques** : nombre de produits complémentaires proposés (2 par défaut).
- **Co-achats minimum** : nombre minimal de commandes contenant les deux produits pour qu'une suggestion apparaisse (2 par défaut).
- **Fenêtre d'historique de commandes (jours)** : période analysée pour la co-occurrence (365 par défaut).
## Créer un lot
1. Ouvrez **Catalogue > Lots visuels** puis cliquez sur **Ajouter**.
2. **Nom du lot** : nom interne, également utilisé comme libellé de la remise dans le panier.
3. **Produit principal** : recherchez par nom, référence ou ID. C'est sur la fiche de ce produit que le bloc s'affichera.
4. **Produits du lot** : ajoutez un ou plusieurs produits complémentaires via la recherche avec autocomplétion.
5. **Type et valeur de remise** : aucune remise, pourcentage (max 100) ou montant fixe TTC.
6. Activez le lot puis enregistrez.
Un seul lot par produit principal et par boutique : le bloc reste lisible et le message commercial unique. En multiboutique, chaque boutique peut avoir son propre lot pour le même produit.
## Fonctionnement de la remise
La remise est appliquée par une **règle panier dynamique** créée à la volée pour chaque panier (code `DFBV-{id_lot}-{id_panier}`) et **restreinte aux seuls produits du lot** :
- Elle n'est créée que si le lot complet est présent au panier — vérification effectuée côté serveur.
- Une remise en pourcentage s'applique uniquement aux produits du lot, jamais au reste du panier.
- Si le client retire un produit du lot, la remise est supprimée automatiquement.
- À la validation de la commande, la règle est désactivée pour ne pas être réutilisée.
- À la désinstallation du module, toutes les règles générées sont purgées.
La remise en pourcentage s'ajoute aux prix spécifiques éventuels : le calcul part du prix affiché au client. Vérifiez vos marges si vous cumulez promotions catalogue et remise de lot.
## Suggestions automatiques
Lorsqu'aucun lot manuel actif n'existe pour le produit consulté et que l'option est activée, le module analyse la co-occurrence des produits dans vos **commandes valides** sur la fenêtre configurée, puis affiche les combinaisons les plus fréquentes qui respectent le seuil de co-achats. Les produits hors stock sont exclus. Le résultat est mis en cache pour préserver les performances. Aucune remise n'est appliquée sur les suggestions automatiques : la remise est réservée aux lots manuels.
## Statistiques
La liste **Catalogue > Lots visuels** affiche pour chaque lot ses **vues** (affichages du bloc) et ses **conversions** (ajouts complets au panier). Les suggestions automatiques sont comptabilisées globalement. Utilisez ces chiffres pour ajuster compositions et remises.
## Dépannage
- **Le bloc ne s'affiche pas** : vérifiez que le module est activé, qu'un lot actif existe pour le produit (ou que les suggestions automatiques sont activées avec un historique suffisant), et que le hook choisi est bien présent dans votre thème.
- **La remise n'apparaît pas** : elle n'est créée que si tous les produits du lot sont au panier. Vérifiez aussi que le type de remise n'est pas « Aucune remise ».
- **Aucune suggestion automatique** : abaissez le seuil de co-achats minimum ou élargissez la fenêtre d'historique ; il faut des commandes valides contenant les produits ensemble.
- **Produits à déclinaisons** : la déclinaison par défaut est utilisée à l'ajout, avec contrôle du stock.
---
### DfCartRecovery — Récupération de panier abandonné pour Shopware 6
_Source :_
> Présentation DfCartRecovery ajoute à Shopware 6 (Community Edition) la récupération de paniers abandonnés, normalement réservée au plan Commercial : détection des paniers, jusqu'à 3 emails de relance planifiés, code promo…
## Présentation
DfCartRecovery ajoute à Shopware 6 (Community Edition) la récupération de paniers abandonnés, normalement réservée au plan Commercial : détection des paniers, jusqu'à 3 emails de relance planifiés, code promo unique par client, lien de restauration du panier en 1 clic et tracking des commandes récupérées. Aucun service externe, aucun build d'administration : tout se configure dans les réglages du plugin.
## Prérequis
- Shopware 6.5, 6.6 ou 6.7 (Community Edition auto-hébergée — Shopware Cloud SaaS non supporté)
- PHP 8.1 ou supérieur (8.2+ recommandé)
- Le consommateur de messages et l'exécution des tâches planifiées actifs (recommandation standard de Shopware en production)
- L'envoi d'emails fonctionnel sur la boutique (les relances passent par le service mail natif de Shopware)
## Installation
1. Décompressez l'archive et placez le dossier `DfCartRecovery` dans `custom/plugins/`.
2. Depuis la racine Shopware, exécutez :
```
bin/console plugin:refresh
bin/console plugin:install --activate DfCartRecovery
bin/console cache:clear
```
La tâche planifiée `df_cart_recovery.process` est enregistrée automatiquement et s'exécute toutes les 15 minutes. Vérifiez que vos workers tournent :
```
bin/console scheduled-task:run
bin/console messenger:consume async low_priority
```
L'installation crée la table de suivi `df_cart_recovery` et le template email « Relance panier abandonné (DataFirefly) », pré-traduit en FR, EN, DE, ES et IT.
## Configuration
Rendez-vous dans **Extensions → Mes extensions → DfCartRecovery → Configuration**. Trois cartes de réglages :
### Général
- **Activer la récupération de panier** — interrupteur global du plugin.
- **Valeur minimale du panier** — les paniers sous ce montant sont ignorés (0 = pas de minimum).
- **Rétention des données (jours)** — les fiches de suivi plus anciennes sont supprimées automatiquement (30 jours par défaut, voir la section RGPD).
### Emails de relance
- **Nombre de relances** — 1, 2 ou 3 (2 par défaut).
- **Relance 1** — minutes après l'abandon du panier (60 par défaut, soit 1 heure).
- **Relance 2** — minutes après la relance 1 (1440 par défaut, soit 24 heures).
- **Relance 3** — minutes après la relance 2 (4320 par défaut, soit 72 heures).
La séquence 1 h / +24 h / +72 h est le standard éprouvé du retargeting email : gardez-la comme point de départ, puis ajustez selon vos statistiques de récupération.
### Code promo
- **Inclure un code promo unique** — active la génération de codes individuels.
- **Promotion pour les codes générés** — sélectionnez la promotion Shopware qui portera les codes (voir ci-dessous).
- **Envoyer le code avec la relance n°** — 2 par défaut : les clients qui reviennent dès le premier email commandent sans remise.
- **Préfixe du code** — CART par défaut ; les codes générés ressemblent à `CART-7F3A91B2`.
## Créer la promotion pour les codes uniques
1. Dans l'admin Shopware, ouvrez **Marketing → Promotions** et créez une promotion (ou réutilisez-en une).
2. Dans l'onglet général, activez **Codes promotionnels individuels**.
3. Définissez la remise (pourcentage ou montant), les conditions et la période de validité comme d'habitude.
4. Activez la promotion, puis sélectionnez-la dans la configuration du plugin.
La promotion doit impérativement avoir les codes individuels activés : le plugin insère ses codes générés dans cette liste. Sans cette option, les codes envoyés ne seront pas acceptés au checkout.
## Personnaliser l'email de relance
Le contenu s'édite dans **Paramètres → Modèles d'email**, type « Relance panier abandonné (DataFirefly) », pour chaque langue de la boutique. Variables Twig disponibles :
- `firstName` / `lastName` — prénom et nom du client
- `items` — articles du panier, chacun avec `label` et `quantity`
- `total` et `currency` — montant du panier et code devise
- `recoveryUrl` — lien de restauration du panier (à placer sur le bouton d'action)
- `voucherCode` — code promo unique (vide si non activé ou relance sans code : entourez son bloc d'une condition Twig)
- `shopName` — nom de la boutique du canal de vente
- `reminderNumber` — numéro de la relance en cours (1, 2 ou 3)
## Le lien de restauration
Chaque email contient un lien unique de la forme `/df-cart-recovery/jeton`, généré sur le domaine du canal de vente du client, dans sa langue. Au clic, le plugin reconstruit le panier article par article, signale les produits devenus indisponibles par un message storefront, horodate le clic et redirige vers la page panier. Les liens invalides ou expirés redirigent vers l'accueil avec un message explicite.
## Tracking de récupération
Dès qu'une commande est passée, le plugin rapproche l'email du client des paniers abandonnés en cours : la fiche passe en « récupérée » avec l'identifiant de commande, la date et le nombre de relances envoyées. Les relances s'arrêtent immédiatement pour ce panier. Les données sont consultables dans la table `df_cart_recovery` (jetons, statuts, clics, commandes liées) pour vos rapports SQL ou BI.
## RGPD et données
- Aucune donnée ne quitte votre serveur ; aucun service tiers n'est appelé.
- Les fiches de suivi sont purgées automatiquement après le délai de rétention configuré.
- À la désinstallation, choisissez « Supprimer toutes les données de l'application » pour effacer la table, le template email et la configuration — ou conservez-les pour garder l'historique.
## Dépannage
### Aucun email n'est envoyé
- Vérifiez que la tâche planifiée tourne : `bin/console scheduled-task:list` doit montrer `df_cart_recovery.process` en statut scheduled, et vos workers messenger doivent être actifs.
- Testez l'envoi d'email global de la boutique (Paramètres → Agent de messagerie) : le plugin utilise le service mail standard.
- Contrôlez la valeur minimale de panier et le délai de la relance 1 : un panier abandonné il y a 20 minutes avec un délai de 60 minutes n'est pas encore éligible.
### Les invités ne reçoivent rien
C'est le comportement attendu : sans adresse email, aucune relance n'est possible. Les invités sont suivis dès qu'ils s'identifient (connexion ou création de compte pendant le checkout) — la fusion de panier met la fiche à jour avec leur adresse.
### Le code promo n'apparaît pas dans l'email
- Vérifiez que l'option « Inclure un code promo unique » est active et qu'une promotion est sélectionnée.
- La promotion doit exister, être active et avoir les codes individuels activés.
- Le code n'est joint qu'à partir de la relance configurée (la 2e par défaut) : la relance 1 n'en contient pas dans la configuration standard.
### Le lien de restauration renvoie à l'accueil
Le jeton est invalide ou la fiche a été purgée (rétention dépassée) — le client reçoit un message l'invitant à recomposer son panier. Augmentez la durée de rétention si vos délais de relance sont longs.
---
### DfCustomCodeManager — Guide complet
_Source :_
> DfCustomCodeManager apporte une réponse simple à un problème universel des boutiques Shopware : où mettre, comment versionner et comment sécuriser le CSS et le JavaScript custom qu'on finit toujours par…
DfCustomCodeManager apporte une réponse simple à un problème universel des boutiques Shopware : **où mettre, comment versionner et comment sécuriser le CSS et le JavaScript custom** qu'on finit toujours par ajouter à un thème ? Le plugin propose un éditeur de code intégré à l'administration, un système de **conteneurs** regroupant des **snippets SCSS ou JavaScript**, et surtout une **injection directe dans la compilation du thème** via les événements natifs de Shopware. Conséquence : aucun fichier servi en plus, aucune requête HTTP additionnelle pour le visiteur, et vos snippets SCSS héritent automatiquement des variables et mixins du thème actif. Ce guide couvre l'installation, la configuration, la création de conteneurs et snippets, la compilation du thème, l'historique de versions, le safe mode, la bibliothèque de presets, l'import/export et le dépannage.
## Installation
1. Téléchargez l'archive `DfCustomCodeManager-1.0.0.zip` depuis votre espace DataFirefly.
2. Installez-la via **Administration → Extensions → Mes extensions → Téléverser une extension**, ou décompressez le dossier `DfCustomCodeManager` dans `custom/plugins/`.
3. Lancez l'installation et l'activation : ``` bin/console plugin:refresh bin/console plugin:install --activate DfCustomCodeManager bin/console cache:clear ```
4. À l'installation, le plugin crée ses 4 tables (`df_ccm_container`, `df_ccm_container_sales_channel`, `df_ccm_snippet`, `df_ccm_snippet_version`) et enregistre ses subscribers aux événements de compilation du thème.
5. Recompilez le thème pour qu'il prenne en compte le plugin : ``` bin/console theme:compile ```
Compatible Shopware 6.6.x et 6.7.x sur un même code (composer `^6.6.0 || ^6.7.0`). Le module d'administration est **précompilé**, **aucun build n'est nécessaire**. PHP 8.2+ requis. La compilation SCSS s'appuie sur `scssphp/scssphp`, déjà fourni par `shopware/storefront`. Aucune dépendance Composer supplémentaire.
## Où trouver le plugin dans l'administration
Après activation, une entrée **Custom Code Manager** apparaît dans le menu **Catalogues** de l'administration (icône orange, position 100). C'est l'écran central : liste des conteneurs, recherche, filtres, et les actions globales **Importer**, **Exporter**, **Presets** et **Compiler le thème**. Toute la configuration de bas niveau (safe mode, minify, bannière) se fait depuis **Extensions → Mes extensions → DfCustomCodeManager → ⋯ → Configurer**.
Si l'entrée n'apparaît pas après une mise à jour, lancez `bin/console assets:install && bin/console cache:clear` puis rechargez l'administration avec un rafraîchissement forcé (Ctrl+Shift+R).
## Configuration du plugin
La carte de configuration plugin Shopware expose trois interrupteurs simples mais essentiels :
- **Safe mode** (`DfCustomCodeManager.config.safeMode`) : désactivé par défaut. Quand il est activé, **tous** les conteneurs sont ignorés à la prochaine compilation, comme s'ils étaient tous inactifs. C'est le filet de sécurité décrit plus bas.
- **Minify JS** (`DfCustomCodeManager.config.minifyJs`) : minification basique du JavaScript injecté. Utile en production, à laisser désactivé en développement pour pouvoir lire les snippets dans le bundle compilé.
- **Ajouter une bannière** (`DfCustomCodeManager.config.addBanner`) : ajoute un commentaire `/* DataFirefly Custom Code Manager */` au début du code injecté. Pratique pour repérer rapidement vos snippets dans le bundle compilé.
## Le modèle mental : conteneurs et snippets
Le plugin s'organise sur **deux niveaux** :
- Un **conteneur** est un regroupement logique : _Promo été 2026_, _GTM analytics_, _Dark mode opt-in_, _A/B test bouton CTA_… Chaque conteneur a un nom, une description, une priorité, un toggle actif/inactif et une portée par canal de vente.
- Un **snippet** est une unité de code à l'intérieur d'un conteneur. Type SCSS ou JavaScript, nom, code, priorité, toggle actif/inactif, notes Markdown, et un toggle pour activer ou non l'injection des variables du thème.
Un conteneur peut contenir **plusieurs snippets de types mélangés**. C'est utile pour regrouper logiquement les snippets qui vont ensemble : par exemple un conteneur _Dark mode opt-in_ avec un snippet SCSS pour les styles et un snippet JavaScript pour le toggle de classe sur `html`.
## Créer son premier conteneur
1. Depuis **Catalogues → Custom Code Manager**, cliquez sur **Nouveau conteneur** en haut à droite.
2. Donnez-lui un nom évocateur (ex. _Promo été 2026 — sticky header & badge_).
3. Réglez la **priorité** (laissez 0 par défaut, montez la valeur si vous voulez que ce conteneur soit injecté plus tard dans le bundle et donc surcharge d'autres styles).
4. (Optionnel) Activez **Limiter à des canaux de vente** et sélectionnez un ou plusieurs canaux. Si l'option est désactivée, le conteneur s'applique à **tous** les canaux.
5. Renseignez une description (notes internes, contexte, ticket associé) — elle ne sera jamais injectée dans le bundle.
6. Enregistrez. Vous êtes maintenant prêt à ajouter des snippets.
## Ajouter un snippet SCSS ou JavaScript
Dans la carte **Extraits de code** de la page conteneur, deux boutons : **Ajouter du SCSS** et **Ajouter du JavaScript**. Chaque snippet ajouté apparaît sous forme de carte avec :
- Un badge **SCSS** (info) ou **JS** (warning).
- Un champ nom (visible en édition uniquement).
- Un toggle actif/inactif.
- Un bouton **Valider la syntaxe** (✓).
- Un bouton **Historique** (horloge) — disponible dès le premier enregistrement.
- Un bouton **Dupliquer**.
- Un bouton **Supprimer**.
- Un **éditeur de code** avec coloration syntaxique adaptée au type.
- Une zone **Notes** Markdown pour documenter ce que fait le snippet.
L'éditeur de code utilise nativement le composant `mt-code-editor` introduit dans Shopware 6.7 (basé sur Meteor). Sur Shopware 6.6, le plugin bascule automatiquement sur `sw-code-editor` (l'ancien composant basé sur Ace). En dernier recours (composant indisponible), un `textarea` en police monospace prend le relais — sans coloration syntaxique mais parfaitement fonctionnel.
## Compiler le thème
Un snippet enregistré n'est **pas encore visible** sur le storefront tant que le thème n'a pas été recompilé. Deux façons de le faire :
- Depuis l'administration, bouton **Compiler le thème** (en haut à droite de la liste, ou dans la page conteneur). Une notification confirme la fin de l'opération.
- Depuis la ligne de commande : ``` bin/console theme:compile ```
À la compilation, le plugin écoute trois événements Shopware et y injecte vos snippets :
- `ThemeCompilerEnrichScssVariablesEvent` — capture la map des variables SCSS du thème actif. C'est ce qui permet à vos snippets SCSS d'utiliser `$sw-color-brand-primary`, `$font-family-base`, etc.
- `ThemeCompilerConcatenatedStylesEvent` — concatène votre SCSS compilé en fin de feuille de styles principale.
- `ThemeCompilerConcatenatedScriptsEvent` — concatène votre JavaScript en fin de bundle scripts principal.
Résultat : **zéro requête HTTP supplémentaire** servie au visiteur, votre code passe par toute la chaîne d'optimisation Shopware (concaténation, minification, fingerprinting de cache).
## Héritage des variables et mixins du thème
Par défaut, chaque snippet SCSS bénéficie d'un **préambule automatique** contenant toutes les variables et tous les mixins exposés par le thème actif et ses plugins de thème. Vous pouvez donc écrire dans un snippet :
```
.header {
background: $sw-color-brand-primary;
font-family: $font-family-base;
transition: $transition-base;
}
```
…sans rien importer manuellement, exactement comme dans un fichier SCSS du thème. Si pour une raison particulière (conflit de variable, snippet auto-contenu) vous voulez désactiver cet héritage sur un snippet précis, décochez le toggle **Variables du thème disponibles** dans le footer de la carte snippet.
## Portée multi-canal
Sur la carte **Portée & canaux** du conteneur, activez **Limiter à des canaux de vente** et sélectionnez les canaux concernés. Le conteneur ne sera alors injecté que dans les compilations de thème pour ces canaux. Très pratique pour :
- Une bannière promo réservée à une boutique de marque secondaire.
- Un script de tracking spécifique à un marché.
- Un test A/B sur un seul canal pour mesurer l'impact.
## Priorité de chargement
La priorité est un entier (par défaut 0) qui contrôle l'**ordre d'injection** dans le bundle compilé : plus la valeur est élevée, plus le code est injecté tardivement, et donc plus il peut surcharger ce qui le précède. La priorité existe à **deux niveaux** :
- **Au niveau conteneur** : ordre entre conteneurs.
- **Au niveau snippet** : ordre entre snippets _à l'intérieur_ d'un même conteneur.
L'ordre final est : `(priorité conteneur, priorité snippet)` en ordre croissant. Conseil simple : laissez tout à 0 par défaut, n'utilisez la priorité que si vous avez explicitement besoin de surcharger quelque chose.
## Historique des versions
À chaque enregistrement d'un snippet, le plugin crée automatiquement une **version** dans la table `df_ccm_snippet_version`. Les **5 dernières versions** par snippet sont conservées (la plus ancienne est supprimée quand le seuil est atteint). Pour consulter et restaurer une version :
1. Sur la carte snippet, cliquez sur l'icône **Historique** (horloge).
2. Une modale s'ouvre avec la liste des versions, date, auteur, commentaire et aperçu.
3. Cliquez sur **Restaurer** à droite de la version souhaitée — le code du snippet est immédiatement remplacé par celui de la version. Une nouvelle version est créée pour acter la restauration.
4. Enregistrez le conteneur et recompilez pour voir l'effet.
Pour des historiques plus longs, le journal complet reste dans la table `df_ccm_snippet_version` (les vieilles versions sont seulement masquées de la modale). Un développeur peut très facilement étendre `VersionTracker::MAX_VERSIONS_PER_SNIPPET` si nécessaire.
## Safe mode : le filet de sécurité d'urgence
Le safe mode est un toggle global dans la configuration plugin. Activé, il fait que **tous les conteneurs sont ignorés à la prochaine compilation**, sans modifier la moindre donnée. Utilisation typique :
1. Un snippet mal testé casse quelque chose en production à 22h.
2. Allez dans **Extensions → Mes extensions → DfCustomCodeManager → ⋯ → Configurer**.
3. Activez le toggle **Safe mode** et enregistrez.
4. Recompilez le thème : `bin/console theme:compile`.
5. Le storefront retrouve son état natif (sans aucun snippet injecté). Vous pouvez maintenant identifier et corriger le snippet fautif au calme.
6. Une fois corrigé, désactivez le safe mode et recompilez à nouveau.
Le safe mode est un outil d'urgence, pas un mode d'exploitation. Une fois l'incident résolu, pensez à le désactiver, sinon aucun de vos conteneurs ne sera injecté.
## Bibliothèque de presets
Le bouton **Presets** (depuis la liste des conteneurs) ouvre une bibliothèque de 8 conteneurs prêts à installer en un clic :
- **Sticky header** — header qui se transforme au scroll (classe `is-sticky` ajoutée au-delà d'un seuil).
- **Back to top** — bouton retour en haut, visible à partir d'un certain scroll.
- **Cookie banner skin** — re-skinning du bandeau cookies natif pour l'aligner sur votre charte.
- **Product badge — Nouveau** — badge "Nouveau" sur les produits créés récemment.
- **Free shipping bar** — barre de progression livraison gratuite en haut de page.
- **Rounded buttons** — boutons arrondis sur toute la boutique.
- **GTM DOM-ready event** — déclenche un event personnalisé une fois le DOM prêt, pour amorcer vos data layers.
- **Fade-in on scroll** — apparition progressive des éléments au scroll.
Cliquer sur **Installer** crée le conteneur et ses snippets dans la base. Il ne reste plus qu'à recompiler le thème pour les voir en ligne. Les conteneurs créés à partir d'un preset sont des conteneurs comme les autres : vous pouvez les éditer, les enrichir, les désactiver, les supprimer.
## Import / Export JSON
Pour migrer des snippets entre environnements (dev, staging, production) ou entre boutiques :
1. **Export** — sélectionnez un ou plusieurs conteneurs dans la liste (cases à cocher), puis cliquez sur **Exporter**. Un fichier JSON est téléchargé, contenant tous les conteneurs sélectionnés avec leurs snippets, leur priorité, leurs notes — et le numéro de version du format (`EXPORT_VERSION = 1`) pour la rétrocompatibilité.
2. **Import** — sur l'environnement de destination, cliquez sur **Importer** et sélectionnez le fichier JSON. Les conteneurs et snippets sont recréés à l'identique.
L'import ne touche pas aux conteneurs existants (pas de fusion par nom) : il crée systématiquement de nouvelles entrées. Si vous voulez écraser un conteneur existant, supprimez-le manuellement avant d'importer.
## Validation syntaxique
Le bouton ✓ **Valider la syntaxe** sur chaque carte snippet déclenche une validation côté serveur sans rien enregistrer. Selon le type :
- **SCSS** — le plugin lance une **compilation à blanc** via `scssphp/scssphp` en injectant le préambule des variables du thème. Si la compilation passe, le snippet est valide. Sinon, les erreurs sont remontées dans une zone d'erreur sur la carte (numéro de ligne, message).
- **JavaScript** — le plugin nettoie le code des chaînes et commentaires, puis vérifie l'**équilibre des accolades**`{}`, **parenthèses**`()` et **crochets**`[]`. Ce check ne remplace pas un vrai parser ECMAScript, mais il attrape 90 % des erreurs de copier-coller (accolade oubliée, chaîne mal fermée). Pour aller plus loin, validez votre JavaScript dans un outil dédié avant collage.
## Architecture technique
Pour les développeurs qui veulent comprendre ou étendre le plugin :
- **Namespace PHP racine** : `DataFirefly` (sous-namespace : `CustomCodeManager`, classes sous `src/`).
- **Plugin class** : `DfCustomCodeManager` (étend `ShopwareCoreFrameworkPlugin`).
- **Préfixe SystemConfig** : `DfCustomCodeManager.config.*`.
- **Tables** : `df_ccm_container`, `df_ccm_container_sales_channel`, `df_ccm_snippet`, `df_ccm_snippet_version`.
- **Migrations** : `Migration1779580800CreateCcmContainerTable`, `Migration1779580801CreateCcmSnippetTable`, `Migration1779580802CreateCcmSnippetVersionTable`.
- **Services** : `CodeCompiler` (orchestration + cache), `SnippetExporter` (import/export JSON), `SnippetValidator` (validation syntaxique), `VersionTracker` (snapshot + restore + trim).
- **Subscribers** : `ThemeCompilerSubscriber` (les 3 events de compilation), `SnippetWrittenSubscriber` (snapshot auto sur écriture).
- **Routes API privées** sous `/api/_action/df-ccm/` (scope `api`) : `validate`, `export`, `import`, `restore-version`, `recompile`, `presets`.
Toutes les déclarations de services sont explicites dans `services.xml` (pas d'autowiring) pour rester aligné sur les conventions DataFirefly.
## Étendre le module d'administration
Le module d'administration est compilé et placé sous `Resources/public/administration/js/df-custom-code-manager.js`. Il est **précompilé dans le ZIP** et ne nécessite **aucun build local**. Pour l'étendre, dépliez les composants (`df-ccm-list`, `df-ccm-detail`, `df-ccm-snippet-card`, `df-ccm-code-field`, `df-ccm-preset-modal`, `df-ccm-version-modal`) et personnalisez via le système d'override standard Shopware (`Component.override`).
## FAQ et dépannage
**Mes snippets n'apparaissent pas sur le storefront.** Avez-vous recompilé le thème ? Tant que `theme:compile` n'a pas tourné après modification, rien ne change. Vérifiez aussi que le conteneur et le snippet sont bien actifs, que le canal de vente concerné est dans la portée (si la portée est restreinte), et que le safe mode n'est pas activé.
**Erreur de compilation SCSS dans la console après theme:compile.** Le plus souvent, c'est une variable de thème qui n'existe pas (faute de frappe) ou un snippet SCSS qui ouvre un bloc sans le refermer. Désactivez le snippet incriminé, recompilez pour confirmer, puis corrigez à tête reposée. La validation syntaxique sur la carte snippet attrape la plupart de ces cas avant enregistrement.
**Le menu Custom Code Manager n'apparaît pas dans l'admin.** Lancez `bin/console assets:install && bin/console cache:clear` puis rechargez l'administration avec Ctrl+Shift+R. Le module est dans le groupe **Catalogues**.
**L'éditeur de code affiche un textarea sans coloration.** C'est le fallback quand ni `mt-code-editor` (6.7) ni `sw-code-editor` (6.6) ne sont disponibles. Vérifiez votre version Shopware et que le module d'administration est bien chargé.
**Je veux désactiver temporairement tous les snippets sans rien supprimer.** C'est exactement le safe mode. Toggle dans la config plugin, recompilation, fini.
**Le bouton "Compiler le thème" tourne sans fin.** Vérifiez les logs Shopware. La compilation peut prendre du temps sur un gros thème ; en cas de blocage réel, la cause habituelle est un snippet SCSS qui boucle ou contient une variable inconnue. Activez le safe mode, recompilez, puis réactivez les snippets un par un pour identifier le coupable.
**Mon snippet JavaScript ne se déclenche pas.** N'oubliez pas que le code injecté est exécuté **dans le bundle global**, donc dans un contexte différent de celui des plugins Shopware classiques. Pour interagir avec les plugins JavaScript du storefront, écoutez plutôt `document.addEventListener('DOMContentLoaded', …)` ou les events globaux que le storefront émet.
**Que se passe-t-il à la désinstallation ?** Lors de `plugin:uninstall`, Shopware affiche la case standard **Conserver les données utilisateur**. Si elle est **décochée**, le plugin supprime ses 4 tables et toutes les données associées (conteneurs, snippets, versions, liaisons canal). Si elle est **cochée**, les tables restent en place et vous pourrez retrouver vos snippets si vous réinstallez le plugin plus tard.
---
### DfDarkMode – Mode sombre pour Shopware 6.7
_Source :_
> Présentation DfDarkMode ajoute un mode sombre complet au storefront Shopware 6.7. Le plugin applique l'attribut data-bs-theme sur la balise racine html de la page : vos variables CSS déclarées sous…
## Présentation
DfDarkMode ajoute un mode sombre complet au storefront Shopware 6.7. Le plugin applique l'attribut `data-bs-theme` sur la balise racine html de la page : vos variables CSS déclarées sous `[data-bs-theme="dark"]` s'activent automatiquement, sans aucune modification de votre thème.
- **Détection automatique** du réglage `prefers-color-scheme` du navigateur (mode Auto)
- **Toggle dans le header** : un bouton qui cycle entre Auto → Clair → Sombre
- **Préférence client** : sélecteur visuel dans la page profil du compte client
- **Persistance double** : cookie pour les visiteurs, custom field client pour les comptes connectés
- **Anti-FOUC** : le thème est appliqué avant le rendu de la page, aucun flash blanc
- **Synchronisation au login** : la préférence du compte est restaurée automatiquement à la connexion
## Prérequis
- Shopware 6.7.0 ou supérieur
- Un thème dont les couleurs sont définies via des variables CSS sous `[data-bs-theme="dark"]` (convention Bootstrap 5.3)
Le plugin ne fournit pas de palette sombre : il pilote uniquement l'attribut `data-bs-theme`. Vos CSS dark mode doivent déjà exister dans le thème.
## Installation
1. Copiez le dossier `DfDarkMode` dans `custom/plugins/` de votre installation Shopware.
2. Exécutez les commandes suivantes :
```
bin/console plugin:refresh
bin/console plugin:install --activate DfDarkMode
bin/console theme:compile
```
Après compilation du thème, le bouton de bascule apparaît dans le header du storefront et la carte « Apparence » s'affiche dans la page profil du compte client.
En environnement de développement, utilisez `bin/console theme:compile --active-only` ou le watcher storefront pour recompiler à chaud.
## Fonctionnement
### Les trois modes
- **Auto** (défaut) : suit le réglage du navigateur ou du système d'exploitation. Si l'utilisateur bascule son OS en sombre, le storefront suit en temps réel.
- **Clair** : force le mode clair quel que soit le navigateur.
- **Sombre** : force le mode sombre quel que soit le navigateur.
### Ordre de priorité de la préférence
1. **Client connecté** : le custom field `df_dark_mode_preference` du compte client prime sur tout.
2. **Visiteur** : le cookie `df-dark-mode` (durée de vie 1 an).
3. **Aucune préférence** : mode Auto.
### Anti-FOUC
Un script inline placé dans la balise head lit le cookie et applique `data-bs-theme` avant que le navigateur ne peigne la page. Résultat : aucun flash de fond clair lors du chargement en mode sombre, même sur connexion lente.
### Synchronisation au login
À la connexion d'un client, sa préférence enregistrée est copiée dans le cookie. Le script anti-FOUC dispose donc de la bonne valeur dès la page suivante, sur tous ses appareils.
## Utilisation côté client
### Bouton du header
Le bouton affiche une icône selon le mode actif : moniteur (Auto), soleil (Clair) ou lune (Sombre). Chaque clic passe au mode suivant. Le changement est appliqué instantanément avec une transition douce et sauvegardé en arrière-plan.
### Page profil du compte
Dans **Mon compte → Profil**, une carte « Apparence » propose trois vignettes cliquables (Auto, Clair, Sombre). La sélection est enregistrée dans le compte client et un message de confirmation s'affiche. La navigation clavier (Entrée / Espace) est prise en charge.
## Personnalisation
### Déplacer le bouton du header
Par défaut, le toggle est injecté dans le block `base_header_actions_wishlist`. Pour le placer ailleurs, surchargez le template de base dans votre thème et incluez le composant dans le block de votre choix :
```
{% sw_extends '@Storefront/storefront/base.html.twig' %}
{% block base_header_actions_search %}
{{ parent() }}
{% sw_include '@Storefront/storefront/component/dark-mode-toggle.html.twig' %}
{% endblock %}
```
### Réagir aux changements de thème en JavaScript
Le plugin émet l'événement `df-dark-mode-changed` sur `document` à chaque changement :
```
document.addEventListener('df-dark-mode-changed', (e) => {
console.log(e.detail.preference); // 'auto', 'light' ou 'dark'
console.log(e.detail.resolvedTheme); // 'light' ou 'dark'
});
```
Utile pour recharger une carte, un graphique ou tout composant tiers qui ne lit pas les variables CSS.
### Textes et traductions
Tous les libellés sont des snippets Shopware (préfixe `df-dark-mode.`) modifiables dans l'administration, rubrique **Paramètres → Snippets**. Le plugin embarque le français, l'anglais et l'allemand.
## Référence technique
### Custom field
Le plugin crée à l'installation un set de custom fields `df_dark_mode` contenant le champ `df_dark_mode_preference` (select : auto / light / dark) rattaché à l'entité customer. Il est visible et modifiable dans l'administration sur la fiche client.
### Route AJAX
`POST /df-dark-mode/save` avec le paramètre `mode` (auto / light / dark). Pose le cookie et, si un client est connecté, met à jour son custom field. Réponse JSON.
### Cookie
Nom : `df-dark-mode` · Valeurs : auto / light / dark · Durée : 365 jours · SameSite=Lax. Cookie strictement fonctionnel : il ne contient aucune donnée personnelle ni identifiant de suivi.
## Désinstallation
```
bin/console plugin:deactivate DfDarkMode
bin/console plugin:uninstall DfDarkMode
```
Lors de la désinstallation, le set de custom fields et les préférences clients sont supprimés, sauf si l'option « conserver les données » est cochée.
## Dépannage
### Le bouton n'apparaît pas dans le header
Vérifiez que le thème a bien été recompilé (`bin/console theme:compile`) et videz le cache (`bin/console cache:clear`). Si votre thème surcharge fortement le block `base_header_actions_wishlist`, déplacez l'include du composant dans un autre block (voir Personnalisation).
### Le mode sombre s'active mais les couleurs ne changent pas
Le plugin pose bien `data-bs-theme="dark"` (vérifiable dans l'inspecteur du navigateur) mais vos CSS ne définissent pas de variables sous ce sélecteur. Ajoutez vos variables sombres dans le bloc `[data-bs-theme="dark"]` de votre thème.
### Flash blanc au chargement
Assurez-vous qu'aucun autre plugin ne surcharge le block `base_head` sans appeler `{{ parent() }}`, ce qui supprimerait le script anti-FOUC.
### La préférence n'est pas conservée entre appareils
Seuls les clients connectés bénéficient de la synchronisation multi-appareils via leur compte. Pour les visiteurs, la préférence est locale au navigateur (cookie).
## Changelog
### 1.0.0
- Version initiale : détection navigateur, toggle header, préférence compte client, anti-FOUC, synchronisation au login, snippets FR/EN/DE.
---
### dffreegift — Cadeau offert au seuil panier — Guide complet
_Source :_
> Guide complet du module dffreegift pour PrestaShop 8 et 9 : installation, configuration, fonctionnement interne (CartRule native), personnalisation, dépannage et désinstallation. Toutes les étapes sont accompagnées de captures conceptuelles et…
Guide complet du module **dffreegift** pour PrestaShop 8 et 9 : installation, configuration, fonctionnement interne (CartRule native), personnalisation, dépannage et désinstallation. Toutes les étapes sont accompagnées de captures conceptuelles et des paramètres exacts à utiliser en production.
## Aperçu
dffreegift ajoute automatiquement un produit cadeau au panier dès qu'un seuil configuré est atteint, et le retire si le panier redescend en dessous. La mécanique s'appuie intégralement sur le système natif `CartRule` de PrestaShop (champ `gift_product`) : le module ne manipule jamais directement les prix des produits, ne crée pas de `SpecificPrice` temporaire, et n'injecte rien dans les hooks de calcul de prix. Résultat : compatibilité complète avec vos autres promotions, codes promo, taxes et le multi-devise.
Le module affiche également un **bloc de progression** sur la page panier avec le message « Ajoutez X € pour recevoir votre cadeau », une barre colorée qui se remplit à mesure que le seuil approche, et une animation au franchissement.
## Prérequis
- PrestaShop 8.0 à 9.x (testé sur 8.0, 8.1, 8.2, 9.0)
- PHP 8.1 minimum (8.2 et 8.3 supportées)
- Un produit actif dans votre catalogue qui servira de cadeau (produit simple ou avec déclinaisons)
- Accès administrateur au back office PrestaShop
## Installation
1. Dans le back office, aller dans **Modules → Gestionnaire de modules → Envoyer un module**.
2. Uploader le fichier `dffreegift-1.0.0.zip`.
3. Cliquer sur **Installer** puis **Configurer**.
À l'installation, le module effectue les opérations suivantes en arrière-plan :
- Enregistrement de 5 hooks : `actionCartSave`, `actionObjectCartRuleDeleteBefore`, `displayShoppingCart`, `displayCartExtraProductActions`, `displayHeader`.
- Écriture des valeurs de configuration par défaut (seuil 50 €, calcul TTC, sans frais de port, vérification stock activée).
- Création d'une `CartRule` « fantôme » avec un code unique du type `DFFREEGIFT_A7B3F2D9`, visible dans **Catalogue → Réductions → Règles panier**.
**Note.** La CartRule créée à l'installation n'a pas encore de produit cadeau assigné (`gift_product = 0`) et n'est donc pas active fonctionnellement. Elle sera synchronisée dès que vous enregistrerez un ID de produit cadeau dans l'écran de configuration.
## Configuration
L'écran de configuration se trouve dans **Modules → DataFirefly Free Gift → Configurer**. Tous les paramètres sont regroupés dans un seul formulaire.
### Activer le module
Le switch **Activer le module** agit comme un interrupteur maître. En position _Non_, le module reste installé mais ne fait rien : pas d'auto-ajout, pas de bloc frontend, pas de calcul de seuil. Utile pour désactiver temporairement l'offre (fin d'une opération saisonnière par exemple) sans perdre la configuration.
### Produit cadeau et déclinaison
Deux champs à renseigner dans l'ordre :
1. **ID du produit cadeau** : saisir l'ID PrestaShop du produit à offrir. L'ID se trouve dans **Catalogue → Produits** (colonne ID). Après avoir enregistré une première fois, le nom du produit s'affiche en aide sous le champ pour confirmation.
2. **Déclinaison** : liste déroulante des combinaisons disponibles pour le produit. Se remplit automatiquement _après_ avoir enregistré l'ID produit. Choisir une déclinaison spécifique (par exemple « Taille M, couleur noire ») ou laisser sur _— Sans déclinaison —_ pour un produit simple.
**Astuce.** Si vous changez de produit cadeau plus tard, la CartRule est automatiquement resynchronisée à l'enregistrement. Vous n'avez pas à toucher manuellement à la règle dans la section Réductions.
### Seuil de déclenchement
Le champ **Seuil de déclenchement** définit le montant panier à partir duquel le cadeau est ajouté. Deux paramètres associés déterminent la base de calcul :
- **Calcul TTC** : si activé, le total inclut toutes les taxes appliquées au panier. Si désactivé, le seuil est comparé au total HT. La plupart des boutiques B2C fonctionnent en TTC ; les boutiques B2B raisonnent souvent en HT.
- **Inclure les frais de port** : si activé, les frais de livraison estimés sont ajoutés au total avant comparaison. En pratique, on l'active rarement puisque les frais de port ne sont pas toujours calculés au moment où le client consulte son panier (aucun transporteur choisi = 0 €).
Concrètement, le total évalué correspond à un appel PrestaShop natif :
```
Cart::getOrderTotal(
$with_taxes = (bool) CFG_TAX_INCL,
$type = CFG_INCLUDE_SHIPPING ? Cart::BOTH : Cart::ONLY_PRODUCTS
);
```
Cela garantit que la valeur utilisée pour la comparaison est strictement identique à celle affichée dans le récapitulatif panier de PrestaShop.
### Vérification du stock
Le switch **Vérifier le stock du cadeau** (activé par défaut) suspend l'auto-ajout si le produit cadeau est indisponible. Le contrôle respecte la stratégie _out of stock_ configurée globalement dans PrestaShop :
- Si le produit est marqué « autoriser la commande hors stock », l'auto-ajout reste actif même à quantité 0.
- Si le produit refuse les commandes hors stock, l'auto-ajout est suspendu quand la quantité atteint 0.
**Recommandation.** Laisser cette vérification activée. Désactiver le contrôle peut conduire à des commandes bloquées au checkout pour cause de rupture de stock du cadeau — expérience client dégradée et intervention manuelle nécessaire.
### Restriction par groupes clients
La grille **Groupes clients éligibles** liste tous les groupes de la boutique avec une case à cocher par groupe. Deux comportements :
- **Aucune case cochée** : tous les clients sont éligibles, y compris les visiteurs non identifiés (à condition que le groupe par défaut `PS_UNIDENTIFIED_GROUP` ne soit pas exclu, ce qui est le comportement par défaut).
- **Une ou plusieurs cases cochées** : seuls les clients membres d'au moins un groupe coché voient le bloc de progression et bénéficient de l'auto-ajout.
Cas d'usage typiques :
- Cadeau réservé au groupe « Professionnels » pour une clientèle B2B.
- Cadeau réservé au groupe « VIP » pour un programme de fidélité.
- Cadeau proposé à tous _sauf_ aux revendeurs (cocher tous les groupes sauf le groupe revendeur).
### Options d'affichage
Deux switches indépendants contrôlent l'apparence du bloc frontend :
- **Afficher le message de progression** : active ou désactive complètement le bloc sur la page panier. En position _Non_, l'auto-ajout continue de fonctionner mais aucun message n'apparaît côté client (utile si vous voulez piloter l'affichage via votre propre thème).
- **Afficher la barre de progression** : active ou désactive la barre colorée sous le message. Le message texte reste visible.
## Comment ça marche techniquement
### La CartRule fantôme
Au lieu de manipuler les prix produits, dffreegift exploite le mécanisme natif PrestaShop de cadeau via `CartRule`. À l'installation, une règle avec les propriétés suivantes est créée :
- `code` = `DFFREEGIFT_A7B3F2D9` (suffixe généré aléatoirement à l'installation)
- `gift_product` = 0 (mis à jour à chaque enregistrement de configuration)
- `gift_product_attribute` = 0 (mis à jour à chaque enregistrement de configuration)
- `quantity` = 999 999 et `quantity_per_user` = 999 999 (pratiquement illimité)
- `date_from` = maintenant, `date_to` = +50 ans
- `active` = 1, aucun code, aucune réduction, aucune restriction produit ni catégorie
Quand le seuil est atteint, le module attache cette règle au panier via `Cart::addCartRule($id)`. PrestaShop se charge ensuite du reste :
- Insertion d'une ligne panier avec `gift = 1` et `price = 0`.
- Affichage dans le récapitulatif panier avec un badge « Cadeau ».
- Prise en compte au moment de la conversion en commande.
- Snapshot dans l'historique de commande (le cadeau reste visible même si vous changez de produit cadeau plus tard).
Quand le panier redescend sous le seuil, le module détache la règle via `Cart::removeCartRule($id)`. La ligne cadeau est retirée dans la même requête.
### Les hooks utilisés
- **actionCartSave** : hook principal. Appelé à chaque sauvegarde du panier (ajout, modification, retrait, login client avec fusion de panier). Le module calcule le total, décide d'attacher ou de détacher la règle. Un drapeau statique `self::$syncing` empêche la récursion si l'attachement de la règle déclenche à son tour un save.
- **actionObjectCartRuleDeleteBefore** : auto-réparation. Si un administrateur supprime manuellement la règle fantôme depuis **Catalogue → Réductions**, ce hook détecte la suppression et remet l'ID à zéro dans la configuration. La prochaine sync recréera une règle propre.
- **displayHeader** : enregistre le CSS et le JS frontend (`views/css/dffreegift.css` et `views/js/dffreegift.js`).
- **displayShoppingCart** : rend le bloc de progression sur la page panier.
- **displayCartExtraProductActions** : réservé pour évolutions futures (badge sur la ligne cadeau).
### Le calcul du seuil
À chaque appel de `syncCartGift()`, le module vérifie dans l'ordre :
1. Le module est-il activé ? (sinon on sort)
2. Le client est-il éligible selon les groupes configurés ? (sinon on détache si attaché)
3. Le produit cadeau est-il valide (existe, actif, en stock si vérification activée) ? (sinon on détache)
4. Calcul du total selon TTC/HT et frais de port inclus/exclus.
5. Comparaison au seuil avec tolérance d'arrondi de 0,001 €.
6. Attacher la règle si seuil atteint et pas encore attachée. Détacher si sous le seuil et attachée.
## Bloc de progression frontend
Le bloc s'affiche automatiquement sur la page panier, entre le récapitulatif produits et le total. Deux états visuels :
- **En attente** (seuil non atteint) : fond gris clair, message « Ajoutez X,XX € pour recevoir votre cadeau », barre orange qui se remplit à mesure que le seuil approche.
- **Objectif atteint** (seuil franchi) : fond vert clair, message « Cadeau ajouté à votre panier ! », barre pleine en vert. Une animation `pulse` se déclenche lors de la transition de l'état _en attente_ vers _atteint_.
### Personnaliser les couleurs
Les couleurs sont définies dans `views/css/dffreegift.css`. Pour personnaliser sans modifier le module (ce qui écraserait vos changements aux mises à jour), surcharger les classes dans le CSS de votre thème :
```
.dffreegift-progress {
border-color: #votre-couleur;
background: #votre-fond;
}
.dffreegift-progress--reached {
background: #votre-vert-clair;
border-color: #votre-vert;
}
.dffreegift-progress__bar-fill {
background: linear-gradient(90deg, #couleur1, #couleur2);
}
```
### Personnaliser les textes
Les textes affichés côté client sont traduisibles via le mécanisme PrestaShop standard. Aller dans **International → Traductions**, sélectionner « Traductions du module », choisir _dffreegift_ et la langue, puis chercher le domaine `Modules.Dffreegift.Shop`. Les chaînes disponibles :
- _« Ajoutez %amount% pour recevoir votre cadeau »_ — message en attente (`%amount%` est remplacé automatiquement par le montant restant formaté selon la devise et la locale).
- _« Cadeau ajouté à votre panier ! »_ — message objectif atteint.
- _« Progression vers le cadeau »_ — label ARIA de la barre (lu par les lecteurs d'écran).
## Cohabitation avec d'autres promotions
Le cadeau étant ajouté via une `CartRule` native, il cohabite normalement avec toute autre `CartRule`. Comportements attendus :
- **Autres codes promo client** (réduction pourcentage, montant fixe, livraison gratuite) : s'appliquent normalement en parallèle du cadeau. Le cadeau ne consomme pas la remise, et inversement.
- **Autre règle avec gift_product** configuré ailleurs : PrestaShop traite les deux comme des règles indépendantes et ajoute les deux cadeaux. Attention si vous cumulez plusieurs modules cadeaux.
- **Règle avec product_restriction** excluant le produit cadeau : la règle qui restreint l'emporte. Le cadeau n'est pas ajouté si une autre règle active l'exclut explicitement.
- **Règle avec cart_rule_restriction** : si une autre règle interdit l'usage de la nôtre par restriction croisée, l'auto-ajout est bloqué (comportement PrestaShop natif).
**Note.** Le seuil de dffreegift est évalué sur le total _hors cadeau_. Si vous avez un autre cart rule qui remise le total avant que dffreegift ne l'évalue, la comparaison se fait sur le total _après_ remise. Un panier de 60 € avec remise de 15 € tombe à 45 € et ne déclenchera pas un seuil de 50 €.
## Multi-boutique
Le module fonctionne avec la configuration multi-boutique de PrestaShop sur le **contexte boutique par défaut**. Les configurations (seuil, produit cadeau, options) sont stockées via `Configuration::updateValue`, qui respecte le contexte boutique courant. La `CartRule` créée à l'installation est associée à la boutique active au moment de l'installation.
Pour un déploiement multi-boutique avec des _cadeaux différents par boutique_, il faut actuellement installer et configurer le module dans chaque contexte boutique séparément. Contacter le support pour une variante avec scoping explicite par `id_shop`.
## Dépannage
### Le cadeau ne s'ajoute pas au panier
Vérifier dans l'ordre :
1. Le module est-il bien activé ? (Modules → Configurer → switch _Activer le module_).
2. Le produit cadeau est-il valide ? (ID correct, produit actif, en stock si vérification stock activée).
3. Le client est-il dans un groupe autorisé ? (si vous avez restreint aux groupes, un visiteur non identifié qui n'est dans aucun groupe autorisé ne verra rien).
4. Le seuil est-il réellement atteint ? Recalculer manuellement le total selon vos paramètres (TTC/HT, avec/sans port).
5. La `CartRule` fantôme existe-t-elle et est-elle active ? Aller dans **Catalogue → Réductions → Règles panier** et chercher `DFFREEGIFT_`.
### Le bloc de progression ne s'affiche pas sur la page panier
Causes courantes :
- Le switch _Afficher le message de progression_ est en position _Non_.
- Le client n'est pas éligible selon les groupes clients configurés.
- Le produit cadeau est invalide (n'existe pas, inactif, ou en rupture avec vérification stock activée).
- Votre thème custom n'appelle pas le hook `displayShoppingCart`. Vérifier avec la commande `grep -r "displayShoppingCart" themes/votre-theme/` ou dans **Modules → Positions**.
### La CartRule a disparu du back office
Si quelqu'un a supprimé la règle depuis **Catalogue → Réductions**, le hook `actionObjectCartRuleDeleteBefore` a détecté la suppression et remis la configuration à zéro. À la prochaine synchronisation panier (donc au prochain ajout de produit par un client), une nouvelle règle est créée automatiquement avec un nouveau code `DFFREEGIFT_xxxxxxxx`.
Pour forcer la régénération immédiatement sans attendre un client :
1. Aller dans **Modules → DataFirefly Free Gift → Désactiver**.
2. Puis **Activer** à nouveau. Cela recrée une règle propre.
### Erreurs dans les logs PrestaShop
Le module logue les exceptions dans **Paramètres avancés → Logs** avec le préfixe `[dffreegift]`. Un message typique en cas de problème :
```
[dffreegift] actionCartSave error:
---
### dfgoogletryon — Module d'essayage virtuel IA (Google Vertex AI)
_Source :_
> Présentation dfgoogletryon ajoute un widget d'essayage virtuel sur vos fiches produit PrestaShop 8 et 9. Le client téléverse une photo (ou utilise sa caméra) et se voit porter le vêtement…
## Présentation
dfgoogletryon ajoute un widget d'essayage virtuel sur vos fiches produit PrestaShop 8 et 9. Le client téléverse une photo (ou utilise sa caméra) et se voit porter le vêtement de la fiche, grâce au modèle génératif **Google Vertex AI Virtual Try-On**. Tous les appels à Google sont proxifiés côté serveur : la clé du compte de service n'atteint jamais le navigateur. Le module intègre le consentement RGPD, le non-stockage des photos, le watermark SynthID et des garde-fous anti-coûts.
## En quoi est-ce différent du try-on de Google Shopping ?
Google propose deux choses distinctes, à ne pas confondre :
- **L'essayage d'apparel du Merchant Center** — un badge qui apparaît uniquement sur la recherche Google et Google Shopping. Il n'est _pas_ intégrable sur votre boutique et n'offre aucune API pour votre fiche produit.
- **Vertex AI Virtual Try-On** — l'API générative que ce module utilise. C'est la seule brique qui permet un widget d'essayage directement sur vos pages produit.
dfgoogletryon repose exclusivement sur Vertex AI. C'est un service génératif **payant à l'image** : chaque essayage génère une ou plusieurs images facturées par Google.
## Prérequis
- PrestaShop 8.0 à 9.x
- PHP 8.1, 8.2, 8.3 ou 8.4
- Extensions PHP : `curl`, `openssl`, `gd`
- Un projet **Google Cloud** avec la facturation activée
- L'**API Vertex AI** activée sur ce projet
- Un **compte de service** doté du rôle _Utilisateur Vertex AI_ et sa clé JSON
## Étape 1 — Préparer Google Cloud
1. Ouvrez [console.cloud.google.com](https://console.cloud.google.com) et créez (ou sélectionnez) un projet. Notez son **ID de projet**.
2. Activez la **facturation** sur le projet (menu Facturation).
3. Activez l'**API Vertex AI** : recherchez « Vertex AI API » (`aiplatform.googleapis.com`) dans la bibliothèque d'API et cliquez sur Activer.
## Étape 2 — Créer le compte de service
1. Allez dans **IAM et administration > Comptes de service**.
2. Cliquez sur **Créer un compte de service**, donnez-lui un nom (par exemple `tryon-prestashop`).
3. Attribuez-lui le rôle **Utilisateur Vertex AI** (`roles/aiplatform.user`).
4. Une fois créé, ouvrez-le, onglet **Clés > Ajouter une clé > Créer une clé > JSON**. Le fichier JSON se télécharge.
Cette clé JSON donne accès à Vertex AI en votre nom. Ne la publiez jamais et ne la déposez pas dans un dépôt public. Le module la conserve côté serveur et ne l'expose jamais au front-office.
## Étape 3 — Installer le module
1. Téléchargez `dfgoogletryon.zip` depuis votre compte client.
2. Dans le back-office PrestaShop : **Modules > Module Manager > Ajouter un nouveau module**.
3. Téléversez le ZIP et cliquez sur **Installer**.
4. À l'installation, le module enregistre ses réglages par défaut et un texte de consentement, puis se branche sur les hooks `displayProductAdditionalInfo` (bouton sur la fiche) et `actionFrontControllerSetMedia` (chargement des assets, page produit uniquement).
## Étape 4 — Configurer le module
Ouvrez la configuration du module. Renseignez la section **Google Cloud / Vertex AI** :
- **GCP Project ID** — l'ID de projet noté à l'étape 1.
- **Region** — la localisation Vertex AI, par exemple `us-central1`.
- **Model ID** — par défaut `virtual-try-on-preview-08-04` (vous pouvez aussi utiliser `virtual-try-on-001`).
- **Service-account JSON key** — collez le contenu intégral du fichier JSON téléchargé à l'étape 2.
Cliquez ensuite sur **Save & test authentication**. Le module signe un JWT, obtient un jeton OAuth et confirme « Authentication OK » si tout est correct.
Le jeton OAuth est mis en cache environ 55 minutes pour éviter de le régénérer à chaque essayage. Toute modification des identifiants invalide automatiquement le cache.
## Réglages de génération et de sécurité
Section **Generation & safety** :
- **Images per try-on** — de 1 à 4 images générées par essayage. Chaque image est facturée par Google.
- **SynthID watermark** — ajoute un filigrane IA invisible aux images générées (recommandé).
- **Safety setting** — niveau de filtrage (`block_low_and_above`, `block_medium_and_above`, `block_only_high`, `block_none`). `block_medium_and_above` par défaut.
- **Person generation** — `allow_adult` recommandé pour une boutique de prêt-à-porter.
- **Max generations per session** — plafond anti-abus par session client.
- **Cooldown between generations (seconds)** — délai minimal entre deux essayages d'une même session.
Section **Display** :
- **Enable widget** — active ou désactive le widget globalement.
- **Restrict to category IDs** — liste d'IDs de catégories séparés par des virgules. Laissez vide pour afficher sur tous les produits, ou renseignez vos catégories de vêtements pour n'afficher le widget que là où il a du sens.
- **Consent text (GDPR)** — le texte affiché à côté de la case de consentement obligatoire.
## Fonctionnement côté client
1. Sur la fiche produit éligible, un bouton **Try it on** apparaît.
2. Le client ouvre la modale, téléverse une photo (JPEG, PNG ou WebP) ou capture depuis sa webcam.
3. La photo est redimensionnée dans le navigateur (max 1024 px, JPEG) avant envoi, pour réduire la latence et le coût.
4. Le client coche la case de consentement, puis clique sur **Generate try-on**.
5. Le module transmet la photo et l'image de couverture du produit à Vertex AI, puis affiche la ou les images générées.
## Confidentialité et RGPD
La photo du client est traitée en mémoire et transmise à Google pour la génération, mais n'est **jamais** enregistrée sur le système de fichiers ni en base de la boutique. La case de consentement, obligatoire et personnalisable, s'affiche avant tout envoi. Adaptez le texte de consentement à votre politique de confidentialité et mentionnez le transfert vers Google.
## Maîtrise des coûts
Chaque image générée est facturée par Google selon la tarification Vertex AI par image. Pour garder des coûts prévisibles :
- Limitez **Images per try-on** à 1 si vous débutez.
- Fixez un **Max generations per session** raisonnable (5 par défaut).
- Utilisez un **Cooldown** pour éviter le spam de génération.
- Restreignez l'affichage aux catégories de vêtements via **Restrict to category IDs**.
Un jeton par produit et la vérification same-origin découragent l'utilisation du proxy hors de vos pages. Ce n'est pas une authentification forte, mais un garde-fou coût combiné aux plafonds ci-dessus.
## Bonnes pratiques pour l'image produit
Le module envoie l'**image de couverture** du produit comme référence vêtement. La qualité de l'essayage est bien meilleure avec un packshot propre du vêtement (fond neutre, vêtement bien visible) qu'avec une photo lifestyle déjà portée par un mannequin. Les hauts, bas et pièces uniques (robes) donnent les meilleurs résultats.
## Dépannage
- **« Authentication failed » au test** — vérifiez l'ID de projet, la validité de la clé JSON, l'activation de l'API Vertex AI et le rôle Utilisateur Vertex AI du compte de service.
- **Aucune image générée** — la requête a pu être filtrée par les réglages de sécurité. Essayez une autre photo, ou assouplissez **Safety setting**. Vérifiez aussi le solde de facturation Google Cloud.
- **Le bouton n'apparaît pas** — vérifiez que **Enable widget** est actif et que le produit appartient à une catégorie autorisée (champ **Restrict to category IDs**).
- **Erreur réseau / timeout** — assurez-vous que le serveur autorise les connexions HTTPS sortantes vers `oauth2.googleapis.com` et `REGION-aiplatform.googleapis.com`.
- **« You have reached the maximum number of try-ons »** — le plafond par session est atteint ; c'est le comportement attendu. Ajustez **Max generations per session** si besoin.
## Désinstallation
La désinstallation supprime les réglages du module, y compris la clé du compte de service et le jeton en cache. Aucune photo client n'est stockée par le module, il n'y a donc rien d'autre à nettoyer.
---
### DfGpsr SW — Guide complet
_Source :_
> DfGpsr SW affiche sur vos fiches produit Shopware les informations de sécurité rendues obligatoires par le règlement (UE) 2023/988 — le règlement général sur la sécurité des produits (RGPS), applicable…
DfGpsr SW affiche sur vos fiches produit Shopware les informations de sécurité rendues obligatoires par le règlement (UE) 2023/988 — le règlement général sur la sécurité des produits (RGPS), applicable depuis le 13 décembre 2024. Shopware n'offre rien de natif solide sur ce point. DfGpsr SW comble ce vide avec des champs personnalisés par produit, des valeurs de repli globales configurables par canal de vente, et un affichage automatique sous la description du produit. Le plugin est volontairement construit sans composant d'administration sur mesure et sans JavaScript storefront : un seul et même ZIP s'installe à l'identique sur Shopware 6.5, 6.6 et 6.7, sans aucune compilation. Ce guide couvre l'installation, la configuration globale, la saisie par produit, la traduction, la personnalisation du template et le dépannage.
DfGpsr SW est un outil technique d'affichage. Il vous aide à présenter les informations exigées, mais l'exactitude et l'exhaustivité des données saisies restent de votre responsabilité, de même que l'évaluation de l'applicabilité du règlement à vos produits. Ce guide ne constitue pas un conseil juridique.
## Ce qu'impose le RGPS
Pour la vente en ligne, le règlement (UE) 2023/988 impose que chaque offre affiche clairement, avant l'achat :
- le **fabricant** : nom, adresse postale et adresse électronique ;
- la **personne responsable établie dans l'UE** (article 16) lorsque le fabricant est établi hors de l'Union : nom, adresse postale et adresse électronique ;
- les **avertissements et informations de sécurité** dans la langue du pays ciblé.
DfGpsr SW couvre ces trois exigences, plus une liste de documents de sécurité (notices, fiches de données de sécurité, certificats) et un interrupteur de masquage pour les références hors champ du règlement.
## Installation
1. Téléchargez l'archive `DfGpsr-v1.0.0.zip` depuis votre compte DataFirefly.
2. Copiez le dossier décompressé `DfGpsr` dans `custom/plugins/` de votre Shopware, ou installez le ZIP via **Administration → Extensions → Mes extensions → Charger l'extension**.
3. Lancez l'installation et l'activation : ``` bin/console plugin:refresh bin/console plugin:install --activate DfGpsr bin/console cache:clear ```
4. À l'installation, le plugin crée son jeu de champs personnalisés `df_gpsr` sur l'entité produit. À la désinstallation sans conservation des données, ce jeu de champs et toutes ses valeurs sont supprimés.
Compatible Shopware 6.5.x, 6.6.x et 6.7.x sur un seul codebase. Aucun build storefront ni administration n'est nécessaire, et le plugin n'ajoute aucune dépendance Composer. C'est ce qui garantit l'installation à l'identique sur les trois versions, y compris la nouvelle administration de la 6.7.
## Configuration globale (valeurs de repli)
Ouvrez **Extensions → Mes extensions → DataFirefly GPSR Compliance → ⋯ → Configurer**. La configuration est organisée en cartes :
- **Général** : activer l'affichage du bloc, afficher ou non le titre de section, et une option d'affichage forcé même sans données (réservée au theming/debug).
- **Fabricant par défaut** : nom, adresse postale et e-mail utilisés lorsqu'un produit ne définit pas son propre fabricant.
- **Personne responsable UE par défaut** : nom, adresse postale et e-mail.
- **Textes de sécurité par défaut** : avertissements et informations de sécurité génériques.
Toutes ces valeurs sont configurables **par canal de vente** grâce au sélecteur natif de Shopware en haut de la configuration. Sélectionnez un canal pour lui attribuer des valeurs spécifiques, ou laissez « Tous les canaux de vente » pour des valeurs communes.
Si vous vendez votre propre marque, renseignez le fabricant une seule fois dans la configuration globale : tout le catalogue est couvert sans toucher aux produits. Les champs par produit ne servent alors que pour les exceptions.
## Renseigner un produit
Ouvrez un produit dans **Catalogues → Produits**, puis l'onglet **Spécifications → Champs personnalisés**. Le groupe **RGPS — Sécurité du produit** regroupe les champs suivants :
- **Masquer les informations RGPS pour ce produit** : interrupteur à activer pour les références hors champ du règlement.
- **Fabricant** : nom, adresse postale, adresse e-mail.
- **Personne responsable UE** : nom, adresse postale, adresse e-mail.
- **Avertissements** et **Informations de sécurité** : éditeurs de texte enrichi.
- **Documents de sécurité** : un par ligne, au format `Libellé|URL` ou simplement une URL.
La règle de résolution est simple : pour chaque champ, le plugin utilise la valeur du produit si elle est renseignée, sinon il retombe sur la valeur par défaut du canal de vente. Le champ « Documents » n'a pas de valeur de repli globale — il est propre à chaque produit.
### Format des documents de sécurité
Saisissez un document par ligne. Deux formats sont acceptés :
```
Notice d'utilisation|https://exemple.com/notice.pdf
Fiche de données de sécurité|https://exemple.com/fds.pdf
https://exemple.com/certificat.pdf
```
Avec le format `Libellé|URL`, le libellé devient le texte cliquable ; une URL seule s'affiche telle quelle. Tous les liens s'ouvrent dans un nouvel onglet.
## Traduction
Les champs sont des champs personnalisés Shopware standards : ils se traduisent produit par produit via le sélecteur de langue de l'administration, en haut de la fiche produit. Renseignez par exemple les avertissements en français pour la langue FR, puis basculez sur DE pour saisir la version allemande.
Les **libellés du bloc storefront** (titre « Sécurité du produit », « Fabricant », « Personne responsable dans l'UE », etc.) sont fournis nativement dans cinq langues : français, anglais, allemand, espagnol et italien. Ils s'affichent automatiquement selon la langue du canal de vente, sans configuration.
Pensez à fournir vos avertissements dans la langue de chaque pays ciblé : le RGPS exige que les informations de sécurité soient compréhensibles par le consommateur du marché visé.
## Affichage storefront
Le bloc RGPS est injecté automatiquement sur la page de détail produit, juste après la description, dans le bloc Twig `page_product_detail_description_content_text`. Il présente le fabricant et la personne responsable côte à côte, puis les avertissements, les informations de sécurité et la liste des documents. Le bloc se masque automatiquement lorsqu'aucune donnée n'est disponible — ni sur le produit, ni dans la configuration globale.
### Personnaliser le template
Le composant d'affichage est isolé dans `views/storefront/component/df-gpsr/gpsr-info.html.twig` et injecté via `views/storefront/page/product-detail/description.html.twig`. Pour déplacer le bloc ou en modifier le rendu, surchargez l'un de ces deux fichiers dans votre thème. Le style de base est inline et volontairement neutre, facile à remplacer par vos propres classes.
## FAQ et dépannage
**Le RGPS s'applique-t-il à ma boutique ?** Si vous vendez des produits de consommation non alimentaires à des clients situés dans l'UE, très probablement oui. Le règlement s'applique depuis le 13 décembre 2024 à la plupart des produits, y compris ceux vendus en ligne et importés de pays tiers.
**Le bloc ne s'affiche pas.** Vérifiez que l'option « activer l'affichage » est bien cochée dans la configuration, que le produit ou la configuration globale contient au moins une donnée, et que l'interrupteur « Masquer » n'est pas activé sur le produit. Videz le cache après toute modification de configuration.
**Le bloc s'affiche mais vide.** C'est probablement l'option « afficher même sans données » laissée active : désactivez-la pour revenir au comportement normal (masquage automatique).
**Mes champs personnalisés rendent en simple champ texte dans l'admin 6.7.** Le mapping des composants de champs personnalisés a évolué avec l'administration Meteor. Si un champ adresse rend en input simple au lieu d'une zone de texte, ce n'est qu'un détail d'affichage admin sans impact sur le storefront ; signalez-le au support pour un ajustement.
**Les valeurs par défaut ne s'appliquent pas.** Vérifiez que vous avez renseigné la configuration pour le bon canal de vente. Une valeur définie sur « Tous les canaux de vente » est écrasée par une valeur spécifique au canal si celle-ci existe.
**Que se passe-t-il à la désinstallation ?** Avec l'option de suppression des données, le jeu de champs `df_gpsr` et toutes les valeurs saisies sur les produits sont supprimés. Sans cette option, les données sont conservées pour une réinstallation ultérieure.
---
### DfGtagManager — Documentation complète
_Source :_
> DfGtagManager est un plugin Shopware 6.7 qui injecte un conteneur Google Tag Manager, émet les évènements GA4 e-commerce complets, gère Consent Mode v2 avec le bandeau cookies Shopware natif, pousse…
DfGtagManager est un plugin Shopware 6.7 qui injecte un conteneur Google Tag Manager, émet les évènements GA4 e-commerce complets, gère Consent Mode v2 avec le bandeau cookies Shopware natif, pousse les Enhanced Conversions hashées SHA-256, et aligne le data layer sur votre flux Google Merchant Center. Cette documentation couvre l'installation, la configuration complète et la vérification.
## Prérequis
- Shopware 6.7.0 ou plus récent
- PHP 8.2 minimum
- Accès SSH ou administration Shopware pour l'installation du ZIP
- Un compte Google Tag Manager (recommandé) ou au minimum un compte Google Analytics 4
- Pour les Enhanced Conversions : un compte Google Ads avec des campagnes de conversion configurées
## Installation
Trois méthodes possibles selon votre environnement.
### Depuis l'administration Shopware
1. Dans le back-office : **Extensions → Mes extensions → Charger l'extension**
2. Sélectionnez le fichier `DfGtagManager.zip`
3. Cliquez sur **Installer** puis sur **Activer**
4. Videz le cache : **Paramètres → Système → Cache et index → Vider et regénérer**
### Depuis la ligne de commande (recommandé en production)
```
cd /chemin/vers/shopware
unzip DfGtagManager.zip -d custom/plugins/
bin/console plugin:refresh
bin/console plugin:install --activate DfGtagManager
bin/console assets:install
bin/console cache:clear
```
**Astuce.** Après `assets:install`, le fichier `df-gtag-manager.js` est publié dans `public/bundles/dfgtagmanager/` et devient accessible via l'asset helper Twig. Aucun build webpack ou TypeScript n'est nécessaire.
## Configuration
Ouvrez la configuration : **Extensions → Mes extensions → DataFirefly Google Tag Manager → menu ⋮ → Configurer**. Sélectionnez le sales-channel concerné en haut de l'écran — chaque sales-channel peut avoir sa propre configuration indépendante.
### Réglages généraux
- **Activer le plugin** : bascule maître. Désactivez pour couper toute injection sans désinstaller.
- **Mode debug** : affiche des logs préfixés `[DfGtag]` dans la console navigateur (add_to_cart, remove_from_cart, consent update…). À activer uniquement en environnement de test.
### Google Tag Manager
- **GTM Container ID** : format `GTM-XXXXXXX`. Récupérable dans [tagmanager.google.com](https://tagmanager.google.com) en haut à droite de votre conteneur. Laissez vide si vous n'utilisez pas GTM — le plugin basculera automatiquement sur le loader `gtag.js` si un Measurement ID GA4 est renseigné.
- **Server-side GTM URL** (optionnel) : URL de votre loader Tag Manager server-side (par exemple `https://gtm.votredomaine.com`, sans slash final). Voir la section [Server-side GTM](#server-side-gtm) plus bas.
### Google Analytics 4
- **GA4 Measurement ID** : format `G-XXXXXXXXXX`. Récupérable dans GA4 sous **Admin → Flux de données → Web**. Utilisé comme fallback `gtag.js` si aucun conteneur GTM n'est configuré, et poussé dans le dataLayer pour les tags GTM.
- **Envoyer l'évènement page_view automatique** : activé par défaut. Désactivez si vous préférez déclencher `page_view` manuellement depuis GTM.
### Consent Mode v2
- **Activer Consent Mode v2** : émet `gtag consent default` avant le chargement de GTM, avec les sept catégories du Consent Mode v2. Voir [Consent Mode v2 en détail](#consent-mode-v2).
- **État de consentement par défaut** : _Refusé_ — recommandé pour l'UE/RGPD. Aucun cookie analytique ou publicitaire n'est déposé avant l'acceptation utilisateur.
- _Accordé_ — à réserver aux visiteurs hors UE, ou aux boutiques réservées à un public professionnel non soumis au RGPD.
**Activer url_passthrough** : conserve les paramètres `gclid`, `_gl`, `dclid` entre les pages même quand les cookies sont refusés. Utile pour l'attribution multi-touch.**Activer ads_data_redaction si refusé** : redact les identifiants publicitaires envoyés à Google Ads quand l'utilisateur refuse. Réduit encore la surface de tracking.
### Enhanced Conversions
- **Activer Enhanced Conversions** : pousse un objet `user_data` avec email, téléphone, prénom, nom, rue, ville, code postal, tous hashés SHA-256 côté serveur, sur les pages _confirm_ et _finish_ du tunnel. Voir [Enhanced Conversions en détail](#enhanced-conversions).
### Google Shopping / Merchant Center
- **Source item_id** : détermine ce que le plugin pousse comme `item_id` dans chaque item GA4. Cette valeur **doit** correspondre au champ `id` de votre flux Merchant Center. Trois options : _Product number (SKU)_ — recommandé, le format le plus courant dans les flux XML/CSV Merchant Center.
- _Shopware UUID_ — utile si vous générez votre flux directement depuis la base Shopware.
- _EAN / GTIN_ — utile si votre flux est aligné sur les codes-barres internationaux.
**Catégorie Google par défaut** : valeur poussée dans `google_product_category` quand ni le produit ni sa catégorie n'en définit une. Format Google (par exemple `Apparel & Accessories > Clothing`).**Marque par défaut** : utilisée en fallback dans `item_brand` quand le produit n'a pas de fabricant assigné.
### Évènements
Chaque évènement GA4 est activable individuellement. Décochez ceux dont vous ne voulez pas.
- **view_item** — fiche produit
- **view_item_list** — page catégorie et résultats de recherche
- **add_to_cart** — clic sur le bouton d'ajout au panier (listener JavaScript)
- **remove_from_cart** — suppression d'une ligne panier ou offcanvas
- **view_cart** — page panier
- **begin_checkout** — page de confirmation du tunnel
- **purchase** — page finish après commande
- **search** — page de résultats de recherche
- **login / sign_up** — soumission des formulaires de compte
## Consent Mode v2 en détail
Le Consent Mode v2 est le mécanisme officiel de Google pour gérer le consentement utilisateur. Depuis mars 2024, Google Ads l'exige pour les annonceurs ciblant l'Espace économique européen — sans lui, vous perdez l'accès au remarketing et à la mesure des conversions.
### Ordre de chargement
Le plugin garantit l'ordre suivant sur chaque page du storefront :
1. Initialisation de `window.dataLayer` et du stub `gtag()`
2. Émission de `gtag consent default` avec les sept catégories Consent Mode v2 et `wait_for_update: 500`
3. Émission de `url_passthrough` et `ads_data_redaction` si activés
4. Push des évènements GA4 de la page (view_item, view_cart…) dans le dataLayer
5. Chargement du script GTM (ou `gtag.js` en fallback)
**Pourquoi wait_for_update: 500 ?** Cette instruction dit à Google de patienter jusqu'à 500 ms après le chargement de la page avant d'émettre les hits en mode dénié — le temps pour votre bandeau cookies de collecter la réponse utilisateur et pour le plugin de pousser un `gtag consent update`. Sans ce délai, tous les hits initiaux sont émis en mode dénié même si l'utilisateur accepte immédiatement.
### Intégration au bandeau cookies Shopware
Le plugin décore `CookieProviderInterface` et enregistre deux cookies virtuels dans les groupes du bandeau natif :
- `df-gtag-analytics` dans le groupe **Statistiques** — contrôle `analytics_storage`
- `df-gtag-ads` dans le groupe **Marketing** — contrôle `ad_storage`, `ad_user_data`, `ad_personalization`
Quand l'utilisateur valide ses préférences, Shopware émet l'évènement `CookieConfiguration_Update`. Le contrôleur JavaScript du plugin écoute cet évènement, lit la valeur des deux cookies virtuels, et émet immédiatement le `gtag consent update` correspondant.
### Compatibilité avec un bandeau tiers
Si vous utilisez Cookiebot, CookieFirst, OneTrust ou Axeptio à la place du bandeau natif Shopware, vous devez émettre vous-même le `gtag consent update` depuis le bandeau tiers avec les catégories correctes. Le plugin ne vous en empêche pas — il gère seulement le `consent default` initial et l'écoute de l'évènement Shopware.
## Enhanced Conversions en détail
Les Enhanced Conversions améliorent la précision de la mesure Google Ads en envoyant des données utilisateur first-party (email, téléphone, nom, adresse) hashées SHA-256 lors d'une conversion. Google reconnecte ensuite ces conversions aux utilisateurs Google connectés, ce qui restaure typiquement 10 à 30 % de conversions auparavant perdues à cause des bloqueurs cookies, du cross-device ou des changements de navigateur.
### Normalisation appliquée
Le plugin normalise chaque champ conformément à la spécification Google avant hashage :
- **Email** : lowercased, trimmed, puis SHA-256
- **Téléphone** : E.164 (préfixe pays automatique depuis l'ISO de l'adresse de facturation, exemple `+33612345678`), puis SHA-256
- **Prénom, nom, rue, ville** : lowercased, trimmed, puis SHA-256
- **Code postal** : lowercased, trimmed ; pour les US, tronqué aux 5 premiers chiffres avant hashage
- **Pays** : code ISO-2 en majuscules, non hashé
### Payload dataLayer
Sur les évènements `begin_checkout` et `purchase`, le plugin pousse :
```
{
"event": "purchase",
"ecommerce": { ... },
"user_data": {
"sha256_email_address": "...",
"sha256_phone_number": "...",
"address": {
"sha256_first_name": "...",
"sha256_last_name": "...",
"sha256_street": "...",
"sha256_city": "...",
"postal_code": "...",
"country": "FR"
}
}
}
```
### Configuration dans GTM
1. Dans votre conteneur GTM, créez ou éditez votre tag **Google Ads Conversion Tracking**
2. Section **Include user-provided data from your website** → **Manual configuration**
3. Créez huit variables Data Layer Variable pointant vers : `user_data.sha256_email_address` → mappé sur **Email (hashed)**
4. `user_data.sha256_phone_number` → mappé sur **Phone (hashed)**
5. `user_data.address.sha256_first_name` → **First name (hashed)**
6. `user_data.address.sha256_last_name` → **Last name (hashed)**
7. `user_data.address.sha256_street` → **Street (hashed)**
8. `user_data.address.sha256_city` → **City (hashed)**
9. `user_data.address.postal_code` → **Postal code**
10. `user_data.address.country` → **Country**
11. Enregistrez et publiez le conteneur
**Attention.** Google exige que les valeurs hashées le soient déjà côté site — n'appliquez pas la variable _SHA-256 Hash_ de GTM à ces variables, elles sortent déjà hashées du plugin. Un double hashage rendrait le matching impossible.
## Google Shopping et flux Merchant Center
Pour que GA4 et Google Ads puissent matcher les évènements e-commerce avec vos produits Shopping, chaque item du dataLayer doit utiliser le même `item_id` que celui du flux Merchant Center.
### Champs poussés dans chaque item
- `item_id` — source configurable (SKU / UUID / EAN)
- `item_name` — nom du produit dans la langue active
- `item_brand` — nom du fabricant, ou marque par défaut si non renseigné
- `item_category` à `item_category5` — breadcrumb complet en partant de la catégorie la plus profonde
- `google_product_category` — voir ci-dessous
- `price`, `quantity`, `currency`
- `mpn` — Manufacturer Part Number si renseigné sur le produit
- `gtin` — EAN si renseigné
- `discount` — calculé depuis la différence entre prix barré et prix de vente
### google_product_category par produit
Vous pouvez surcharger la catégorie Google Shopping pour un produit ou une catégorie via un custom field :
1. Dans le back-office : **Paramètres → Système → Custom fields → Créer un nouveau set**
2. Nom technique : `df_google_product_category`, type **Texte**
3. Assignez ce set aux entités **Produit** et/ou **Catégorie**
4. Sur chaque produit ou catégorie, renseignez la valeur Google (par exemple `Sporting Goods > Athletics > Football > Football Balls`)
Le plugin cherche la valeur dans cet ordre : custom field du produit → custom field de sa catégorie la plus profonde → valeur globale par défaut de la configuration.
## Server-side GTM
Le server-side tagging permet de router le trafic GTM via un domaine que vous contrôlez, ce qui contourne les bloqueurs navigateur, protège les données utilisateur, et améliore la résilience face aux changements de politique cookies.
### Prérequis
- Un conteneur server-side GTM configuré (voir [documentation Google](https://developers.google.com/tag-platform/tag-manager/server-side))
- Un domaine ou sous-domaine dédié pointant vers votre serveur Tag Manager, par exemple `gtm.votredomaine.com`
### Activation
Dans la configuration du plugin, section **Google Tag Manager**, renseignez **Server-side GTM URL** avec votre domaine _sans slash final_ :
```
https://gtm.votredomaine.com
```
Le script GTM et l'iframe noscript pointeront automatiquement vers votre serveur au lieu de `www.googletagmanager.com`.
## Vérification
### Google Tag Assistant
1. Installez l'extension Chrome **Tag Assistant Companion**
2. Ouvrez [tagassistant.google.com](https://tagassistant.google.com), cliquez sur **Add domain** et entrez l'URL de votre storefront
3. Naviguez sur une fiche produit, ajoutez au panier, allez au checkout — chaque étape doit apparaître dans l'assistant avec les évènements GA4 correspondants
### GA4 DebugView
Dans GA4 : **Admin → DebugView**. Les évènements y apparaissent en temps réel dès que Debug mode est actif dans le plugin ou que le paramètre `debug_mode=true` est envoyé.
### Mode debug du plugin
Activez **Debug mode** dans la configuration puis ouvrez la console navigateur. Vous verrez :
```
[DfGtag] consent update { analytics_storage: "granted", ad_storage: "denied", ... }
[DfGtag] add_to_cart { item_id: "SW10001", item_name: "...", price: 129, quantity: 1 }
[DfGtag] remove_from_cart { ... }
```
### Checklist de validation
- Sur la home : consent default émis avant le script GTM (ordre des balises dans le head)
- Sur une fiche produit : `view_item` avec `item_id`, `item_brand`, `item_category`, `google_product_category`
- Sur ajout au panier : `add_to_cart` avec le même item
- Sur le panier : `view_cart` avec tous les items
- Sur la page confirm : `begin_checkout` avec `user_data` hashé
- Sur la page finish : `purchase` avec `transaction_id`, `value`, `tax`, `shipping`, `currency`, `items` et `user_data` hashé
- Sur acceptation cookies : `consent update` avec les catégories granted
## Résolution de problèmes
### Les évènements n'apparaissent pas dans GA4 DebugView
- Vérifiez que le Measurement ID GA4 est correct dans la configuration
- Vérifiez que le tag GA4 Configuration est bien créé et publié dans votre conteneur GTM
- Vérifiez que le déclencheur du tag couvre bien toutes les pages (_All Pages_)
- Videz le cache Shopware et rechargez la page en _hard reload_ (Ctrl+F5)
### Les Enhanced Conversions ne matchent pas
- Vérifiez qu'aucune transformation supplémentaire (variable SHA-256 Hash de GTM) n'est appliquée aux variables `user_data` — les valeurs sortent déjà hashées
- Vérifiez le format E.164 du téléphone dans le dataLayer (avec préfixe pays commençant par `+`)
- Vérifiez que le champ `country` est bien en ISO-2 majuscule (`FR`, pas `France`)
- Attendez 24 à 48 heures après l'activation : Google Ads a besoin de ce délai pour la première synchronisation
### Consent update pas émis quand l'utilisateur accepte
- Confirmez que le bandeau utilisé est bien celui de Shopware natif
- Ouvrez la console navigateur en mode debug et vérifiez que l'évènement `CookieConfiguration_Update` est bien émis quand l'utilisateur valide le bandeau
- Vérifiez que les cookies `df-gtag-analytics` et `df-gtag-ads` apparaissent dans le bandeau et sont bien cochés
### item_id ne matche pas mon flux Merchant Center
- Ouvrez votre flux XML/CSV et regardez le champ `` pour un produit
- Dans la configuration du plugin, choisissez la source `item_id` qui produit exactement la même valeur (SKU, UUID ou EAN)
- Si votre flux utilise un préfixe (par exemple `shopware_SW10001`), il faudra créer un tag GTM qui préfixe la valeur avant envoi à Google Ads
### Le plugin ne se charge pas sur certaines pages
- Vérifiez que le sales-channel en cours a bien **Activer le plugin** à ON dans sa configuration spécifique
- Certaines pages personnalisées (landing pages CMS custom) peuvent ne pas déclencher les Page Loaded Events standards. Dans ce cas, le conteneur GTM est quand même chargé via le header pagelet.
---
### dfomnibus — Conformité Directive Omnibus PrestaShop
_Source :_
> Le module dfomnibus met votre boutique PrestaShop en conformité avec la directive européenne 2019/2161 dite Omnibus, en vigueur dans toute l'Union européenne depuis le 28 mai 2022. Il construit automatiquement…
Le module **dfomnibus** met votre boutique PrestaShop en conformité avec la directive européenne 2019/2161 dite Omnibus, en vigueur dans toute l'Union européenne depuis le 28 mai 2022. Il construit automatiquement l'historique de prix de chaque produit et affiche, dès qu'une promotion est active, le prix le plus bas constaté pendant les 30 jours précédents.
**Compatibilité :** PrestaShop 8.0 à 9.x. PHP 7.4 à 8.3. Multi-boutique, multi-devise et multi-déclinaison pris en charge nativement. Aucun composant tiers, aucun CDN, RGPD-friendly.
## Installation
L'installation prend moins de cinq minutes.
1. Téléchargez le fichier `dfomnibus_v1.0.1.zip` depuis votre espace client DataFirefly.
2. Dans le back-office PrestaShop, allez dans **Modules → Gestionnaire de modules → Installer un module**.
3. Uploadez le ZIP. PrestaShop crée les tables, génère un jeton cron et enregistre les hooks nécessaires.
4. Cliquez sur **Configurer** pour ouvrir l'écran de paramétrage.
**Deux tables créées :**`ps_dfomnibus_price_history` pour les snapshots et `ps_dfomnibus_compliance_log` pour les événements de conformité (réservée à des évolutions futures). Le préfixe `ps_` est remplacé automatiquement par le vôtre.
## Programmation du cron quotidien
Le cron amorce l'historique de votre catalogue et garantit la continuité des snapshots quotidiens, même pour les produits dont le prix ne change jamais. Sans cron actif, le module fonctionne mais son historique reste limité aux produits modifiés manuellement.
### Récupération du jeton
Ouvrez la page de configuration du module. Le jeton cron affiché est unique à votre installation. Vous obtenez une URL de la forme :
```
https://votre-boutique.com/modules/dfomnibus/cron.php?token=VOTRE_JETON
```
### Programmation via cron Unix
Ajoutez la ligne suivante à votre crontab, ajustez l'heure selon votre trafic (idéalement en heures creuses) :
```
15 3 * * * curl -s "https://votre-boutique.com/modules/dfomnibus/cron.php?token=VOTRE_JETON" > /dev/null
```
### Programmation via CLI
Si vous préférez éviter toute exposition HTTP, exécutez le cron directement en ligne de commande :
```
php /chemin/vers/votre-boutique/modules/dfomnibus/cron.php token=VOTRE_JETON
```
**Sécurité du jeton :** le module utilise `hash_equals()` pour comparer les jetons, ce qui protège contre les attaques par timing. Ne partagez jamais ce jeton et régénérez-le si vous suspectez une compromission (bouton _Régénérer le jeton_ dans la configuration).
## Configuration des options
### Activation de l'affichage
La bascule **Activer l'affichage** contrôle l'insertion du message de conformité sous le prix produit. Vous pouvez la désactiver temporairement pour maintenir la collecte de l'historique sans afficher la mention en frontend (utile lors d'une bascule ou pendant les tests).
### Mode de calcul
Deux modes sont disponibles :
- **Strict** : le prix de référence est le minimum constaté pendant les 30 jours qui précèdent le début effectif de la promotion en cours. Correspond à la lettre de la directive.
- **Conservateur** (recommandé par défaut) : le prix de référence est le minimum sur les 30 derniers jours glissants. Interprétation plus défavorable au commerçant mais plus défensive en cas de contrôle.
**Quel mode choisir ?** Si votre boutique a une politique promotionnelle claire, avec des dates de début et fin bien tracées, le mode strict est parfait. En cas de doute, ou si vos règles SpecificPrice sont modifiées fréquemment sans discontinuité franche entre les périodes promo et non-promo, le mode conservateur est plus sûr.
### Période de référence
La période est fixée à 30 jours par défaut, conformément à la directive. Vous pouvez l'augmenter (60, 90 jours) pour être encore plus prudent, mais la valeur minimale reste à 30 jours.
### Exclusion des produits récents
L'option **Exclure les produits de moins de X jours** masque l'affichage sur les produits trop récents. Valeur par défaut : 30 jours. C'est cohérent avec l'esprit de la directive, qui ne s'applique qu'aux produits dont l'historique de prix est significatif.
### Restriction UE
Si vous vendez dans et hors UE, cochez **Restreindre l'affichage à l'Union européenne**. Le module détecte le pays du client dans cet ordre :
1. Adresse de livraison du client connecté
2. Adresse du panier en cours
3. Pays par défaut de la boutique
Si aucune de ces informations n'est disponible, l'affichage est actif par défaut pour éviter tout risque de non-conformité involontaire.
### Masquer lorsque prix égal
L'option **Masquer si prix identique** supprime le message lorsque le prix actuel correspond exactement au prix le plus bas des 30 derniers jours. Utile pour éviter d'afficher une information sans valeur ajoutée pour le consommateur.
### Remise réelle
Activez **Afficher la remise réelle** pour compléter le message par le pourcentage calculé sur la base du prix Omnibus, et non du prix barré. Exemple : un produit à 89 €, en promo à 59 €, avec un prix Omnibus de 65 € affichera _-9,2 %_ de remise réelle au lieu du -33 % calculé sur le prix barré. C'est plus honnête, mais chaque commerçant est libre de choisir.
### Graphique
Le graphique 30 jours peut s'afficher dans un onglet dédié de la fiche produit ou en ligne sous le prix. Il est lazy-loaded via IntersectionObserver et ne se déclenche qu'à l'entrée dans le viewport, ce qui garantit un impact nul sur le Core Web Vitals de vos fiches produit.
### Suivi par déclinaison
Cochez **Suivre les déclinaisons** si vos produits ont des prix différents par combinaison (par exemple des tailles XL avec supplément). L'historique est alors segmenté par `id_product_attribute` et la mention Omnibus s'adapte au prix de la déclinaison sélectionnée.
### Rétention
La durée de conservation par défaut est de 365 jours. Au-delà, l'historique est purgé automatiquement lors de l'exécution du cron. La valeur minimale est de 60 jours pour garantir une marge de sécurité par rapport à la fenêtre légale de 30 jours.
## Tableau de bord de conformité
Accessible via **Modules → Tableau de bord DataFirefly Omnibus**, le tableau de bord regroupe :
- Le nombre de produits suivis
- Le total de snapshots enregistrés
- La date et l'heure du dernier passage du cron
- La liste des produits avec, pour chacun, la date de première capture, la date de dernière capture, le prix le plus bas des 30 derniers jours et un indicateur de promotion active
Pour chaque produit, trois actions sont disponibles :
- **Voir l'historique** : affiche jusqu'à 1000 snapshots horodatés
- **Snapshot manuel** : force la capture immédiate
- **Supprimer l'historique** : réinitialise le suivi pour ce produit (à utiliser avec prudence)
### Export CSV
Depuis la vue d'historique d'un produit, le bouton **Exporter en CSV** génère un fichier avec toutes les colonnes horodatées (date, prix HT, prix TTC, devise, boutique, déclinaison, indicateur promo, source de la capture). Format prêt à archiver ou à transmettre à un contrôleur DGCCRF.
## Comportement en frontend
Sur la fiche produit, dès qu'une promotion est active, la mention suivante s'affiche automatiquement sous le prix :
> Prix le plus bas des 30 derniers jours : 65,00 €
Le message est traduit selon la langue de la boutique (français, anglais, espagnol, allemand). L'affichage utilise le hook standard `displayProductPriceBlock` et fonctionne avec tous les thèmes respectant les standards PrestaShop (Classic, Hummingbird, Warehouse, Transformer, Panda).
**Rendu unique par page :** le module inclut une protection `static $rendered` qui garantit que la mention n'apparaît qu'une seule fois par page, même si le hook `displayProductPriceBlock` est appelé plusieurs fois (blocs récapitulatifs, sticky, etc.).
## Multi-boutique et multi-devise
L'historique est stocké par combinaison unique `(id_product, id_product_attribute, id_shop, id_currency)`. Chaque boutique de votre installation conserve donc son historique propre, et chaque devise active a sa propre courbe de prix. Aucune conversion à la volée : les montants affichés correspondent exactement à ce qui a été enregistré au moment de la capture.
## Dépannage
### La mention n'apparaît pas sur la fiche produit
Vérifiez dans l'ordre :
1. L'option **Activer l'affichage** est-elle bien cochée dans la configuration ?
2. Un cron a-t-il été exécuté au moins une fois ? Sinon, aucun historique n'existe.
3. La restriction UE est-elle activée alors que vous testez depuis un pays hors UE ?
4. L'option **Masquer si prix identique** est-elle activée et le prix actuel correspond-il au prix minimum ?
5. Le produit a-t-il moins de 30 jours (avec l'option d'exclusion des nouveautés active) ?
### Le graphique ne se charge pas
Ouvrez la console navigateur. Le module attend un point d'entrée AJAX exposé par le contrôleur front `pricehistory`. Vérifiez qu'aucun système de cache ou pare-feu n'intercepte cette route. Si vous utilisez un CDN, autorisez explicitement les URL `/module/dfomnibus/pricehistory`.
### Le cron retourne une erreur 403 ou 401
Le jeton dans l'URL ne correspond pas à celui enregistré. Retournez dans la configuration du module et copiez le jeton actuel. Si vous suspectez une fuite, cliquez sur **Régénérer le jeton** et mettez à jour votre cron Unix.
### Erreur SQL au moment du snapshot
Si vous êtes sur la version 1.0.0, mettez à jour vers la 1.0.1. La version initiale contenait un défaut sur trois requêtes `Db::getRow()` qui ajoutaient un `LIMIT 1` manuel alors que PrestaShop en ajoute déjà un automatiquement, ce qui produisait un `LIMIT 1 LIMIT 1` invalide en SQL. Voir le changelog.
## FAQ
### Le module est-il obligatoire pour ma boutique ?
Oui, si vous vendez à des consommateurs établis dans l'Union européenne et que vous affichez des prix réduits, des promotions, des codes promo, des soldes ou toute mention de réduction. La directive Omnibus s'applique sans seuil de chiffre d'affaires.
### Quelle différence avec les CartRule ?
Le module suit uniquement les prix issus des `SpecificPrice` de PrestaShop (remises produit, remises quantité, remises groupe client). Les règles de panier (`CartRule`) s'appliquent au checkout et ne modifient pas le prix unitaire affiché en fiche produit : elles sortent donc du périmètre de la directive.
### Comment fonctionne le mode strict précisément ?
Le module cherche dans l'historique le dernier snapshot non-promo, puis le premier snapshot promo qui suit. Cette date est le début de la promotion en cours. La fenêtre de référence est alors les 30 jours qui précèdent cette date. Si aucune bascule non-promo vers promo n'est détectable, le module bascule automatiquement sur le mode conservateur.
### Puis-je masquer le message sur certains produits ?
Le module s'applique globalement, mais l'option d'exclusion des produits récents et l'option de masquage si prix égal couvrent la majorité des cas où l'affichage n'apporte pas d'information utile.
### Compatible avec les prix HT/TTC ?
Oui. Le module enregistre les deux montants (`price_tax_excl` et `price_tax_incl`) à chaque snapshot et affiche celui utilisé par la boutique. Si vous basculez d'un mode à l'autre, l'historique reste exploitable.
## Changelog
### 1.0.1 — 14 mai 2026
- Correction : suppression du `LIMIT 1` manuel dans trois requêtes `Db::getRow()` qui produisaient un `LIMIT 1 LIMIT 1` invalide en SQL. Affectait la garde d'idempotence de l'enregistrement et la détection du début de promo en mode strict.
### 1.0.0 — 14 mai 2026
- Sortie initiale
- Capture automatique de l'historique de prix via hooks et cron quotidien
- Affichage du prix le plus bas sur 30 jours sur la fiche produit
- Graphique 30 jours en canvas vanilla, lazy-load, environ 3 Ko
- Tableau de bord de conformité avec statistiques et export CSV
- Modes de calcul strict et conservateur
- Support multi-boutique, multi-devise, multi-déclinaison
- Restriction UE configurable, exclusion des produits récents, option de masquage si prix identique
- Traductions FR, EN, ES, DE
---
### dfomnibus-woo — Conformité Directive Omnibus WooCommerce
_Source :_
> Le plugin DataFirefly Omnibus Compliance for WooCommerce met votre boutique en conformité avec la directive européenne 2019/2161, dite Omnibus, applicable depuis le 28 mai 2022. Il capture l'historique de prix…
Le plugin **DataFirefly Omnibus Compliance for WooCommerce** met votre boutique en conformité avec la directive européenne 2019/2161, dite Omnibus, applicable depuis le 28 mai 2022. Il capture l'historique de prix dès son activation, calcule le prix de référence légal en appliquant les règles que presque personne n'implémente, et vous fournit le dossier à remettre en cas de contrôle.
**Compatibilité :** WordPress 6.2 minimum, WooCommerce 8.0 minimum, PHP 8.0 minimum (compatible 8.1, 8.2 et 8.3). HPOS déclaré compatible. Produits simples et variables, multi-devise, WPML et Polylang. Aucune dépendance externe, aucun CDN.
## Installation
1. Téléchargez l'archive `dfomnibus-woo-1.0.0.zip` depuis votre espace client DataFirefly.
2. Dans l'administration WordPress, allez dans **Extensions, Ajouter une extension, Téléverser une extension**, puis activez le plugin. WooCommerce doit être actif.
3. La capture démarre immédiatement : trois tables sont créées et un premier instantané est planifié dans les minutes qui suivent l'activation.
4. Ouvrez **WooCommerce, Omnibus Compliance** pour configurer l'affichage et activer votre licence.
**Trois tables créées :**`wp_dfwomni_price_history` pour les relevés de prix, `wp_dfwomni_display_log` pour le journal des mentions servies, `wp_dfwomni_license_cache` pour le cache de licence. Le préfixe `wp_` est remplacé automatiquement par le vôtre.
## Le moteur de calcul
Le calcul du prix de référence est isolé dans un moteur sans dépendance à WordPress, couvert par des tests unitaires. Les règles sont évaluées dans cet ordre.
### 1. Séries de réductions successives
Quand des promotions s'enchaînent sans que le produit revienne à son prix non réduit, la référence légale reste le prix pratiqué avant la _première_ réduction de la série. Elle n'est jamais recalculée à chaque nouvelle promotion. Le plugin détecte ces enchaînements, gèle la référence et affiche l'explication en back-office, par exemple « référence gelée depuis le 12 octobre, promotions successives en cours ».
Une série est bornée dans le temps. Au-delà de 60 jours par défaut, réglable de 30 à 120 jours, on considère que le prix réduit est devenu le prix normal du produit : la règle générale des 30 jours s'applique de nouveau, et le rapport de conformité signale une promotion permanente.
### 2. Cas normal, fenêtre ancrée
Le prix de référence est le plus bas pratiqué sur l'intervalle qui va de 30 jours avant le début de la réduction jusqu'au début de la réduction. La fenêtre est **ancrée** au démarrage de la promotion : elle ne glisse pas jour après jour pendant que la promotion tourne, contrairement à un minimum glissant qui finirait par avaler le prix promotionnel lui-même.
### 3. Produit récemment commercialisé
Pour un produit mis en vente depuis moins de 30 jours, la référence est le prix le plus bas depuis sa mise en vente, et la mention affichée en boutique indique la durée réelle de commercialisation, comme l'exige le texte.
### 4. Données insuffisantes
Si l'historique capturé ne couvre pas la fenêtre légale pour un produit qui n'est pas récent, aucune référence n'est renvoyée et rien n'est affiché. Une référence jamais réellement capturée ne doit jamais être affichée ni reconstruite après coup.
**Conséquence pratique :** installez le plugin **avant** votre saison promotionnelle, pas le jour même. L'historique ne se reconstruit pas rétroactivement, c'est votre preuve et il ne peut être constitué qu'en avance.
## Capture automatique
Deux mécanismes tournent en parallèle.
- **Instantané quotidien** : la tâche `dfwomni_daily_snapshot` parcourt le catalogue et enregistre l'état des prix. Si le dernier passage remonte à plus de 24 heures, un rattrapage ponctuel `dfwomni_catchup_snapshot` est planifié automatiquement.
- **Capture événementielle** : chaque changement réel de prix est enregistré, qu'il vienne de l'éditeur produit, d'une modification rapide ou en masse, d'un import CSV, d'une mise à jour REST ou CRUD, d'un outil de repricing, ou du démarrage et de la fin des promotions programmées.
Une ligne d'historique correspond à un changement de prix réel, les doublons sont écartés. Les prix sont stockés bruts avec leur contexte fiscal et leur devise, jamais le prix déjà mis en forme.
### Fiabiliser le cron sur une boutique à faible trafic
WP-Cron ne s'exécute qu'au passage d'un visiteur. Sur une boutique peu fréquentée, configurez un vrai cron système :
```
*/15 * * * * wget -q -O /dev/null "https://votre-boutique.com/wp-cron.php?doing_wp_cron"
```
Le tableau de bord affiche un avertissement si le dernier instantané date de plus de 48 heures.
## Réglages
Onglet **Réglages** de la page WooCommerce, Omnibus Compliance.
- **Afficher la référence sur** : produits en promotion uniquement, ce qui correspond au minimum légal, ou tous les produits disposant d'un historique, mode transparence réservé à la licence Pro.
- **Position de la ligne** : juste sous le prix, ou après le bloc prix dans le résumé produit. Choisissez la seconde option si votre thème réécrit le rendu du prix.
- **Graphique 30 jours** : propose la courbe de prix sur la fiche produit, en canvas natif d'environ 3 Ko, sans script externe. Fonctionnalité Pro.
- **Textes personnalisés** : deux gabarits, la ligne standard avec le marqueur `{price}` et la ligne produit récent avec `{price}` et `{days}`. Laissez vides pour utiliser les textes traduits fournis en français, anglais, allemand, espagnol et italien. Fonctionnalité Pro.
- **Exclusions** : identifiants de produits et de catégories qui n'affichent jamais la mention, utile pour des prix négociés ou du B2B.
- **Seuils d'audit** : nombre de jours au-delà duquel une promotion est signalée comme permanente, 60 par défaut, et âge maximal d'une série de réductions successives, 60 par défaut.
- **À la désinstallation** : case à cocher pour supprimer aussi l'historique capturé. Décochée par défaut, et c'est volontaire.
## Tableau de bord
L'onglet **Tableau de bord** réunit trois blocs.
### Santé de la capture
Nombre de relevés capturés, nombre de produits suivis et date du dernier instantané quotidien, avec l'alerte évoquée plus haut si le cron ne passe plus.
### Rapport de conformité
Audit calculé en direct sur vos données les plus récentes, qui liste les produits dont l'affichage actuel pourrait être contesté lors d'un contrôle. Quatre statuts :
- **Référence manquante** : le produit est en promotion sans référence capturée, la remise est affichée sans prix antérieur défendable.
- **Promotion permanente** : la promotion tourne depuis trop longtemps, le prix réduit est devenu le prix normal et la remise annoncée devient contestable.
- **Produit récent** : information, l'affichage indique correctement la durée réelle de commercialisation.
- **Référence gelée (série)** : promotions successives en cours, la référence ne sera pas recalculée tant que le produit ne sera pas revenu à un prix non réduit.
### Exports horodatés
Deux exports CSV générés en flux, nommés avec le domaine et l'horodatage UTC :
- **Historique de prix** : l'intégralité des relevés capturés.
- **Journal d'affichage** : quelle référence a été réellement servie, quand, et sur quelle fiche produit.
Le rapport de conformité, les exports et le journal d'affichage font partie de la licence Pro. La capture, elle, n'est jamais bridée.
## Historique de prix
L'onglet **Historique de prix** affiche les relevés produit par produit, avec la variation, la devise, le prix régulier, le prix promotionnel, le prix effectif et la source du relevé. Quand une référence est gelée, la date et la raison du gel sont indiquées.
## Planificateur de gel
Votre première promotion verrouille la référence de la suivante : tout prix pratiqué dans les 30 jours qui précèdent une date clé abaisse la remise que vous pourrez annoncer ce jour là. Le planificateur raisonne à rebours.
Choisissez une date commerciale dans la liste fournie (Black Friday, Cyber Monday, Noël, soldes d'hiver et d'été, Saint-Valentin, fête des mères et des pères) ou saisissez une date personnalisée. Le planificateur vous indique la date limite à laquelle votre dernière promotion doit se terminer pour préserver la remise visée, et la période pendant laquelle chaque prix pratiqué alimente la fenêtre légale. Un calendrier abonnable regroupe toutes les échéances. Fonctionnalité Pro.
## Import d'un historique existant
Si une autre extension a déjà enregistré vos prix, ces données sont irremplaçables. L'onglet **Import** analyse la structure des tables de votre base, sans se baser sur le nom de l'extension, et repère celles qui contiennent un identifiant produit, un prix et une date, avec détection optionnelle d'une colonne de variation. Les tables système de WooCommerce et d'Action Scheduler sont ignorées.
Le tableau affiche chaque table candidate, les colonnes détectées et le nombre de lignes. L'import est idempotent : les doublons et les lignes inexploitables sont comptés séparément et ne polluent pas votre historique. Fonctionnalité Pro.
## Licence
L'onglet **Licence** affiche le plan en cours, la clé masquée et la date de dernière vérification. Saisissez la clé reçue par e-mail après l'achat, au format `DFWOM-PRO-XXXX-XXXX-XXXX-XXXX`, puis cliquez sur Activer.
Achat unique, 12 mois de mises à jour, remboursement sous 30 jours, code source non chiffré, une boutique par licence. Si le serveur de licences est injoignable, le plugin conserve toutes ses fonctionnalités pendant 7 jours puis revient au niveau Free, sans jamais casser votre boutique. La capture de l'historique ne s'arrête jamais, quel que soit le plan.
### Ce que la licence Pro débloque
- Affichage sur tous les produits disposant d'un historique, et pas seulement sur les produits en promotion
- Textes de mention personnalisés
- Graphique de prix sur 30 jours
- Tableau de bord de défense, rapport de conformité et journal d'affichage
- Exports CSV horodatés
- Planificateur de gel
- Import d'un historique existant
Restent toujours actifs, quelle que soit la licence : la capture complète de l'historique, l'affichage de la mention sur les produits en promotion et la consultation de l'historique en back-office.
## Dépannage
### Aucune mention ne s'affiche
Vérifiez dans l'ordre :
1. Le produit est il réellement en promotion ? Par défaut la mention ne s'affiche que sur les produits remisés.
2. L'historique capturé couvre t il la fenêtre requise ? Sur une installation récente, la réponse est souvent non, et c'est le comportement voulu.
3. Le produit ou sa catégorie figurent ils dans les exclusions ?
4. Le tableau de bord signale t il un instantané trop ancien ? Si oui, fiabilisez le cron.
### La mention s'affiche à un endroit inattendu
Basculez la position sur **après le bloc prix dans le résumé produit**. Certains thèmes réécrivent le rendu du prix et absorbent l'insertion faite juste sous celui ci.
### Le dernier instantané date de plus de 48 heures
WP-Cron dépend du trafic. Mettez en place le cron système indiqué plus haut, ou vérifiez que la constante `DISABLE_WP_CRON` n'est pas activée sans cron système en remplacement.
### Le graphique n'apparaît pas
Le graphique fait partie de la licence Pro et doit être activé dans les réglages. Vérifiez aussi que l'historique du produit contient assez de points sur les 30 derniers jours.
### L'import ne détecte aucune table
La détection est structurelle : une table candidate doit contenir une colonne d'identifiant produit, une colonne de prix décimale et une colonne de date. Les tables natives de WooCommerce et d'Action Scheduler sont volontairement écartées.
## FAQ
### La référence est elle recalculée à chaque nouvelle promotion ?
Non, et c'est le point le plus mal compris de la règle. Tant que le produit ne revient pas à un prix non réduit, la référence reste le prix pratiqué avant la première réduction de la série.
### Les produits variables sont ils gérés ?
Oui. La référence est calculée par variation et non au niveau du produit parent, et la mention se met à jour lorsque le visiteur change de variation.
### Que se passe t il à la désinstallation ?
Les réglages, le cache de licence et sa table sont supprimés. L'historique de prix et le journal d'affichage sont conservés par défaut, car ces données ne peuvent pas être reconstituées. Cochez explicitement l'option de purge dans les réglages si vous voulez tout effacer.
### Le plugin ralentit il la boutique ?
Non. La capture écrit une petite ligne par changement de prix réel, l'affichage lit une plage indexée courte avec cache, et le graphique représente environ 3 Ko de code natif sans aucune requête externe.
### Le plugin gère t il le multi-devise ?
Oui. Chaque relevé porte sa devise, l'historique n'est donc jamais converti après coup.
## Changelog
### 1.0.0 - 10 août 2026
- Version initiale
- Double capture : instantané quotidien avec rattrapage et capture événementielle des changements de prix
- Prix de référence sur fenêtre de 30 jours ancrée au début de la réduction
- Règle des réductions successives avec gel de la référence sur le prix pré-série
- Mention adaptée aux produits récemment commercialisés, avec durée réelle de commercialisation
- Planificateur de gel et calendrier des échéances
- Tableau de bord de défense, rapport de conformité, exports horodatés et journal d'affichage
- Import structurel d'un historique de prix existant
- Référence par variation, relevés multi-devise
- Traductions FR, EN, DE, ES, IT, compatibilité WPML et Polylang, compatibilité HPOS
---
### DfPreorder SW — Guide complet
_Source :_
> Shopware ne propose nativement aucune fonction « Prévenez-moi quand c'est de nouveau en stock ». DfPreorder SW comble ce manque : sur chaque fiche produit en rupture, un formulaire d'inscription…
Shopware ne propose nativement aucune fonction « Prévenez-moi quand c'est de nouveau en stock ». DfPreorder SW comble ce manque : sur chaque fiche produit en rupture, un formulaire d'inscription apparaît automatiquement, et le client reçoit une alerte par e-mail — dans sa propre langue — dès que le produit revient. Le plugin ajoute aussi un mode précommande léger (badge et date d'expédition prévue) et un module d'administration pour suivre les inscriptions. Un seul et même ZIP s'installe sur Shopware 6.5, 6.6 et 6.7. Ce guide couvre l'installation, la compilation des assets, le worker et la tâche planifiée, la configuration, l'usage storefront, le mode précommande, les e-mails, la Store API, la conformité RGPD et le dépannage.
Compatible Shopware 6.5.x, 6.6.x et 6.7.x sur un seul codebase. Aucune dépendance Composer n'est ajoutée. Contrairement à certains plugins livrés avec un dist précompilé, DfPreorder embarque les sources JavaScript : une compilation du storefront et de l'administration est nécessaire après l'installation (voir ci-dessous).
## Comment fonctionne la détection du retour en stock
DfPreorder détecte les réapprovisionnements de deux façons complémentaires, qui convergent vers un même traitement idempotent — vos clients sont donc toujours prévenus, jamais deux fois :
- **En temps réel** : un abonné écoute l'écriture des produits et réagit dès que le stock ou le stock disponible change.
- **Balayage planifié** : une tâche planifiée s'exécute toutes les 15 minutes et rattrape les mises à jour de stock effectuées en SQL direct — typiquement la décrémentation du stock disponible au passage d'une commande, ou un import ERP, qui ne déclenchent pas d'événement applicatif.
Le formulaire de liste d'attente s'affiche sur une fiche produit lorsque deux conditions sont réunies : le produit est en mode « épuisé masque la disponibilité » (closeout) _et_ son stock disponible est tombé à zéro.
## Installation
1. Téléchargez l'archive `DfPreorder-v1.0.0.zip` depuis votre compte DataFirefly.
2. Copiez le dossier décompressé `DfPreorder` dans `custom/plugins/`, ou installez le ZIP via **Administration → Extensions → Mes extensions → Charger l'extension**.
3. Installez et activez le plugin : ``` bin/console plugin:refresh bin/console plugin:install --activate DfPreorder ```
4. Compilez les assets du storefront et de l'administration (étape indispensable, aucun dist n'est fourni) : ``` ./bin/build-storefront.sh ./bin/build-administration.sh ```
5. Videz le cache : ``` bin/console cache:clear ```
À l'installation, le plugin crée la table `df_stock_notification`, le jeu de champs personnalisés `df_preorder` sur l'entité produit, deux modèles d'e-mail et la tâche planifiée. À la désinstallation sans conservation des données, tout est supprimé.
## Worker et tâche planifiée
Pour que les e-mails partent réellement, deux mécanismes doivent tourner — ce qui est généralement déjà le cas en production via l'admin-worker, systemd ou cron :
- Le **worker Messenger**, qui consomme le message asynchrone de réapprovisionnement et envoie les e-mails ;
- Le **planificateur de tâches**, qui déclenche le balayage de sécurité toutes les 15 minutes.
```
bin/console messenger:consume async --time-limit=60
bin/console scheduled-task:run
```
Si ni le worker ni le planificateur ne tournent, les inscriptions sont enregistrées mais aucun e-mail n'est envoyé. C'est la cause numéro un de « le plugin ne notifie personne ». Vérifiez l'état de l'admin-worker dans **Paramètres → Système → File d'attente** et celui des tâches planifiées dans **Paramètres → Système → Tâches planifiées**.
## Configuration
Ouvrez **Extensions → Mes extensions → DataFirefly Précommande & Liste d'attente → ⋯ → Configurer**. Toutes les options sont réglables **par canal de vente** grâce au sélecteur natif en haut de la page.
- **Activer la liste d'attente** : interrupteur principal. Affiche le formulaire sur les fiches en rupture.
- **Double opt-in** : exige une confirmation par e-mail avant d'activer l'inscription (recommandé pour le RGPD). Désactivé par défaut.
- **Autoriser les invités** : si désactivé, seuls les clients connectés peuvent s'inscrire.
- **Supprimer l'inscription après notification** : minimisation des données — l'adresse e-mail est effacée une fois l'alerte envoyée. Si désactivé, l'inscription est conservée avec le statut « notifié ».
- **Notifications par lot** : nombre maximal d'e-mails envoyés par exécution (worker ou balayage). 100 par défaut.
- **Afficher le badge précommande** : active l'affichage du badge et de la date d'expédition sur les produits configurés en précommande.
## La liste d'attente côté storefront
Lorsqu'un produit est en rupture (closeout + stock disponible à zéro), le formulaire « Être averti du retour en stock » s'affiche automatiquement sous le bouton d'achat. Le client saisit son e-mail (pré-rempli s'il est connecté) et valide.
- La soumission se fait en **AJAX** avec un repli complet sans JavaScript (message flash + redirection).
- Un champ **honeypot** invisible filtre les robots.
- Si le **double opt-in** est activé, un e-mail de confirmation est envoyé ; l'inscription ne devient active qu'après le clic sur le lien de confirmation.
- Chaque e-mail peut contenir un **lien de désinscription en un clic**.
Le formulaire est rendu dans un template surchargeable : `views/storefront/component/df-waitlist/waitlist-form.html.twig`, injecté via le buy-widget. Surchargez-le dans votre thème pour en modifier l'apparence ou l'emplacement.
## Mode précommande
Le plugin crée un groupe de champs personnalisés **Précommande** sur l'entité produit. Ouvrez un produit dans **Catalogues → Produits**, onglet **Spécifications → Champs personnalisés**, groupe **Précommande** :
- **Activer la précommande** : interrupteur d'activation pour ce produit.
- **Date d'expédition prévue** : la date affichée dans le badge.
- **Note de précommande** : texte libre affiché sous le badge.
Quand la précommande est activée et que le badge est autorisé dans la configuration, un badge ambre s'affiche au-dessus du bouton d'achat avec la date d'expédition prévue. Le rendu est isolé dans le template du buy-widget et reste surchargeable.
## E-mails et traductions
Deux modèles d'e-mail sont créés à l'installation et traduits en cinq langues — français, anglais, allemand, espagnol et italien :
- **Retour en stock** (`df_preorder.back_in_stock`) : variables `productName`, `productUrl` et l'objet `product` complet.
- **Confirmation d'inscription** (`df_preorder.double_opt_in`) : ajoute la variable `confirmUrl`.
Chaque client est notifié dans la langue de la boutique au moment de son inscription : le plugin reconstruit un contexte de langue propre au souscripteur pour résoudre le nom du produit traduit et le bon modèle. L'URL du produit est résolue via l'URL SEO canonique du canal et de la langue concernés.
Les modèles restent entièrement éditables dans **Paramètres → E-mails → Modèles d'e-mail**. Recherchez « retour en stock » ou « back in stock » pour les retrouver.
## Module d'administration
Le menu **Marketing → Liste d'attente & Précommande** liste toutes les inscriptions : adresse e-mail, produit, statut (en attente / confirmé / notifié), date d'inscription et date de notification. La suppression en masse est disponible, utile pour purger manuellement d'anciennes inscriptions.
## Store API (headless / mobile)
Pour les boutiques headless ou les applications mobiles, un point d'entrée Store API permet d'inscrire un client à la liste d'attente :
```
POST /store-api/df-waitlist/subscribe
Content-Type: application/json
sw-access-key:
{
"productId": "0189a1b2c3d4...",
"email": "client@example.com"
}
```
Une requête valide renvoie une réponse de succès ; un identifiant produit ou un e-mail invalide renvoie une erreur 400. Les mêmes règles de configuration s'appliquent (double opt-in, autorisation des invités, etc.).
## Conformité RGPD
- Les adresses e-mail sont collectées uniquement pour la notification demandée.
- Le double opt-in optionnel enregistre un consentement explicite.
- Le comportement par défaut supprime la donnée personnelle dès l'alerte envoyée.
- Un lien de désinscription en un clic peut être inséré dans les modèles d'e-mail.
- La désinstallation avec suppression des données efface la table, les modèles, les champs personnalisés et la configuration.
## Compatibilité 6.5 → 6.7 et dépannage
**Le formulaire ne s'affiche pas sur un produit en rupture.** Vérifiez que l'option « Activer la liste d'attente » est cochée pour le bon canal de vente, que le produit est bien en mode closeout, et que son stock disponible est à zéro. Videz le cache après toute modification de configuration.
**Les inscriptions sont enregistrées mais aucun e-mail ne part.** Le worker Messenger et/ou le planificateur de tâches ne tournent pas. Lancez-les manuellement pour tester (voir la section Worker), puis assurez-vous qu'ils s'exécutent en continu en production.
**Erreur de service mail à l'activation sur Shopware 6.7.** La classe de service mail abstraite a été remplacée par une classe concrète en 6.7. Le plugin gère cette différence automatiquement via un compiler pass qui crée l'alias adéquat ; un simple `cache:clear` recompile le conteneur si l'erreur subsiste après une mise à jour.
**L'e-mail part dans la mauvaise langue.** La langue retenue est celle du canal de vente au moment de l'inscription. Vérifiez que le canal concerné a bien la langue attendue et que le modèle d'e-mail dispose d'une traduction pour cette langue.
**Des e-mails semblent envoyés en double.** Cela ne devrait pas arriver : le traitement est idempotent et marque (ou supprime) chaque inscription après envoi. Si vous l'observez, vérifiez que vous n'exécutez pas plusieurs workers concurrents sans la configuration de transport adéquate.
**Que se passe-t-il à la désinstallation ?** Avec l'option de suppression des données, la table `df_stock_notification`, les deux modèles d'e-mail, le jeu de champs `df_preorder`, la tâche planifiée et la configuration sont supprimés. Sans cette option, tout est conservé pour une réinstallation ultérieure.
---
### dfproforma — Génération automatique de factures proforma
_Source :_
> Présentation dfproforma automatise la génération de factures proforma dans PrestaShop 8. Dès qu'une commande atteint un statut configuré, le module crée un PDF personnalisé (logo, numérotation, pied de page multilingue)…
## Présentation
dfproforma automatise la génération de factures proforma dans PrestaShop 8. Dès qu'une commande atteint un statut configuré, le module crée un PDF personnalisé (logo, numérotation, pied de page multilingue) et le met à disposition du client depuis son espace compte. La génération manuelle depuis la fiche commande reste disponible à tout moment.
**Cas d'usage principal :** contextes B2B où le client doit obtenir une proforma avant de confirmer son paiement ou de faire valider une dépense en interne.
## Installation
1. Dans le back-office PrestaShop, aller dans **Modules > Gestionnaire de modules**.
2. Cliquer sur **Télécharger un module** et sélectionner le fichier `dfproforma.zip`.
3. Cliquer sur **Installer**. Les tables SQL sont créées automatiquement.
4. Le module apparaît dans la liste sous le nom _Proforma Invoice Generator_.
Compatibilité : PrestaShop 8.0 à 8.x, PHP 7.4 à 8.3, multiboutique.
## Configuration générale
Accédez à la configuration via **Modules > Gestionnaire de modules > dfproforma > Configurer**.
### Statuts déclencheurs
Cochez les statuts de commande qui doivent déclencher la génération automatique de la proforma. Dès qu'une commande passe dans l'un de ces statuts, le PDF est créé et stocké sur le serveur.
Recommandation : déclencher sur le statut _Paiement accepté_ pour les flux standards, ou sur _En attente de paiement_ pour les contextes B2B (la proforma précède le paiement).
### Logo PDF
Uploadez un logo dédié aux proformas (formats acceptés : PNG, JPG). Si ce champ est laissé vide, le logo de la boutique est utilisé par défaut.
### Pièce jointe e-mail
Activez l'option **Joindre la proforma aux e-mails de confirmation** pour que le PDF soit automatiquement attaché aux e-mails de commande (`order_conf`, `bankwire`, `cheque`, `payment`).
## Numérotation des proformas
La numérotation est configurable par langue installée. Pour chaque langue :
- **Préfixe** : texte ajouté avant le numéro (ex. `PROFORMA`, `PRO`).
- **Numéro de départ** : entier à partir duquel le compteur commence (ex. `1` ou `1000`).
- **Nombre de chiffres** : longueur du compteur avec zéros de remplissage (ex. `6` → `000001`).
Exemple : préfixe `PROFORMA`, départ `1`, 6 chiffres → première proforma numérotée `PROFORMA-000001`.
En multiboutique, la numérotation est isolée par boutique : la clé composite `proforma_number + id_shop` garantit l'unicité sans doublons entre boutiques.
### Pied de page PDF
Saisissez le texte de pied de page pour chaque langue active. Ce texte apparaît en bas de chaque proforma générée dans la langue correspondante.
## Génération manuelle depuis le back-office
Sur chaque fiche commande, une carte **Facture proforma** s'affiche dans le panneau latéral :
- Si une proforma existe : lien de téléchargement direct du PDF.
- Si aucune proforma n'existe : bouton **Générer la proforma** pour la créer immédiatement, quel que soit le statut de la commande.
## Téléchargement client
Le client accède à ses proformas depuis son espace compte :
- **Page de détail de commande** : un bouton _Télécharger la proforma_ apparaît directement sous les informations de commande.
- **Historique des commandes** : les liens proforma sont intégrés via JavaScript sans requête AJAX supplémentaire (ajout en v1.0.2).
L'accès est protégé par la clé sécurisée de la commande (`secure_key`) — un client ne peut télécharger que ses propres proformas.
## Structure du PDF
Chaque proforma générée contient :
- Numéro de proforma (selon la numérotation configurée)
- Date de génération
- Logo de la boutique (ou logo personnalisé)
- Coordonnées de la boutique et de l'acheteur
- Tableau des produits avec quantités et prix unitaires HT et TTC
- Totaux (HT, TVA, TTC, frais de port)
- Pied de page personnalisé dans la langue de la commande
## Multiboutique
dfproforma est nativement compatible avec le mode multiboutique PrestaShop 8 :
- La configuration (statuts, logo, numérotation, pied de page) est indépendante par boutique.
- Les fichiers PDF sont stockés dans un dossier séparé par boutique.
- La numérotation est unique par combinaison numéro + boutique.
## Désinstallation
La désinstallation supprime la table SQL `df_proforma` et toutes les clés de configuration préfixées `DFPROFORMA_`. Les fichiers PDF déjà générés sont conservés sur le serveur.
## Changelog
- **v1.0.2** — Intégration dans l'historique des commandes via le hook `actionFrontControllerSetMedia` ; affichage des liens sans AJAX supplémentaire.
- **v1.0.1** — Corrections mineures de stabilité.
- **v1.0.0** — Version initiale : génération par statut, PDF personnalisable, pièce jointe e-mail, téléchargement client.
---
### DfProforma Shopware — Devis pro forma avec acceptation client et auto-conversion
_Source :_
> Ce que fait DfProforma Shopware 6.7 sait émettre des factures, des bons de livraison et des avoirs — mais pas de devis pro forma. Or dans la quasi-totalité des contextes…
## Ce que fait DfProforma
Shopware 6.7 sait émettre des factures, des bons de livraison et des avoirs — mais pas de devis pro forma. Or dans la quasi-totalité des contextes B2B (équipement industriel, services aux entreprises, achats publics, ventes par appel d'offres), le client doit recevoir un document formel qu'il accepte _avant_ que la commande devienne ferme.
DfProforma comble ce manque sans bricoler : un véritable type de document Shopware natif `df_proforma`, sa propre plage de numérotation `PF{n}`, son template PDF brandé Twig, un workflow d'acceptation client autonome avec URL publique signée HMAC-SHA256, et une auto-conversion en commande dès que la transaction sous-jacente passe à l'état payé.
**En résumé :** le commercial génère un devis depuis la fiche commande dans l'admin, l'envoie par email, le client clique le lien, accepte en ligne sans compte Shopware, paie, et le devis bascule automatiquement en statut _Converti_. Aucun clic manuel post-paiement.
## Prérequis
- **Shopware** 6.7.0 ou supérieur (le plugin n'est pas rétro-compatible 6.6 en raison des refontes du système de documents)
- **PHP** 8.2 minimum
- **MySQL** 8.0+ ou **MariaDB** 10.6+
- Workers de messages Shopware actifs (recommandé pour la gestion automatique des expirations)
- Mail service Shopware configuré (SMTP fonctionnel pour les envois transactionnels)
## Installation
### 1. Téléverser le plugin
Depuis l'administration Shopware, allez dans _Extensions → Mes extensions → Téléverser une extension_, et sélectionnez le fichier `DfProforma-1.0.6.zip`.
### 2. Installer et activer
Dans la liste des extensions, cliquez _Installer_ puis _Activer_. Les migrations Shopware s'exécutent automatiquement et créent :
- La table SQL `df_proforma` et ses index sur `order_id`, `status`, `public_token`
- Le type de document `df_proforma` dans `document_type`
- La plage de numérotation `document_df_proforma` au format `PF{n}`, configurable
- Le template email transactionnel de base pour la génération, l'envoi et l'acceptation
### 3. Recompiler l'administration
Le plugin fournit un module Vite admin qui étend la fiche commande (`sw-order-detail-base`). Il faut recompiler le bundle d'administration global pour que l'onglet _Pro forma_ apparaisse :
```
bin/build-administration.sh
bin/console cache:clear
```
**Oublier cette étape** est la première cause de « l'onglet Pro forma n'apparaît pas sur la fiche commande » — pensez à recompiler après chaque mise à jour du plugin.
## Configuration
### Paramètres globaux
Depuis _Extensions → Mes extensions → DfProforma → Configurer_, vous accédez aux paramètres suivants :
- **Validité par défaut** — Nombre de jours pendant lesquels le lien d'acceptation reste valide (30 par défaut). Chaque devis peut surcharger cette valeur individuellement.
- **Auto-conversion à l'encaissement** — Activée par défaut. Désactivez-la si vous souhaitez conserver le contrôle manuel du basculement _Accepté → Converti_.
- **Nom de l'expéditeur** — Nom affiché comme expéditeur des emails transactionnels (par défaut : le nom du sales-channel).
- **Accent de marque du PDF** — Couleur d'accent utilisée dans le template PDF livré (bandeau d'en-tête, ligne de séparation, badge de statut).
### Configuration par sales-channel
Les paramètres ci-dessus peuvent être surchargés par sales-channel dans _Paramètres → Sales channels → [votre canal] → Configuration du plugin_. Utile si vous gérez plusieurs boutiques avec des politiques de validité différentes (par exemple 30 jours pour le B2C, 60 jours pour le B2B).
## Générer un devis pro forma
### Depuis la fiche commande (admin)
1. Ouvrez une commande dans _Commandes → Vue d'ensemble_
2. Cliquez sur l'onglet _Pro forma_ (à côté de _Documents_)
3. Cliquez _Générer un devis pro forma_
4. Le PDF est créé, le devis apparaît dans la liste avec un numéro `PF-…` et le statut _Brouillon_
### Depuis l'API admin
Trois endpoints sont exposés pour intégrer la génération dans vos workflows externes :
```
POST /api/_action/df-proforma/generate
Body: { "orderId": "…" }
POST /api/_action/df-proforma/mark-sent
Body: { "proformaId": "…" }
GET /api/_action/df-proforma/by-order/{orderId}
```
Authentification standard OAuth2 admin de Shopware. Utile pour brancher DfProforma sur un CRM externe ou un pipeline d'automatisation.
## Envoyer un devis au client
### Email transactionnel
Depuis la liste des devis (onglet Pro forma de la fiche commande), cliquez l'icône enveloppe à côté du devis. Le module :
1. Passe le devis en statut _Envoyé_ (avec horodatage)
2. Envoie un email au client via le Mail Service Shopware, en utilisant le template `df_proforma_sent`, dans la langue du sales-channel
3. Joint le PDF du devis et inclut l'URL publique d'acceptation
4. Émet l'événement `ProformaGeneratedEvent` (déclencheur Flow Builder)
### URL publique d'acceptation
Chaque devis envoyé porte une URL de la forme :
```
https://votre-boutique.com/proforma/accept/{token}
```
Le token est chiffré et signé HMAC-SHA256 avec la clé secrète Shopware (`APP_SECRET` / `kernel.secret`). Impossible à forger ou à deviner. L'URL expire après la validité du devis (30 jours par défaut).
## Page publique d'acceptation client
Le client ouvre l'URL — **sans compte Shopware requis** (la page contourne l'authentification standard du compte client). Il voit :
- Un récapitulatif propre de la commande : lignes, prix, TVA, totaux, conditions
- Un bouton principal _Accepter ce devis_
- Un bouton secondaire _Décliner avec motif_
- La validité affichée (« Valable jusqu'au 20/06/2026 »)
À l'acceptation :
- Signature horodatée à la milliseconde et persistée en base
- Adresse IP client persistée pour preuve
- Statut passe à _Accepté_ avec l'historique de transition marqué
- Événement `ProformaAcceptedEvent` dispatché vers Flow Builder
En cas de refus, le champ _Motif_ est obligatoire — utile pour vos commerciaux qui peuvent recontacter le client avec une contre-proposition.
**Personnalisation :** la page d'acceptation utilise les blocs Twig standards du Storefront et hérite de votre thème. Vous pouvez surcharger `@DfProforma/storefront/page/account/proforma/quote.html.twig` depuis votre thème.
## Workflow de statuts
Six statuts couvrent l'intégralité du cycle de vie d'un devis :
- **Brouillon** — Devis créé mais pas encore envoyé au client
- **Envoyé** — Email envoyé, en attente de réponse client
- **Accepté** — Client a cliqué _Accepter_ sur la page publique
- **Décliné** — Client a cliqué _Décliner_ avec motif
- **Expiré** — Validité dépassée sans réponse (transition automatique via scheduled task)
- **Converti** — Commande sous-jacente payée, conversion automatique
Chaque transition est persistée avec date à la seconde, identifiant de l'acteur, type de déclencheur (_commercial_, _client_, _système_, _paiement_) et payload JSON pour les métadonnées libres. Vous pouvez reconstituer l'historique exact d'un devis à tout moment.
## Auto-conversion à l'encaissement
Le module enregistre un Subscriber sur l'événement `order_transaction.state.paid` de la machine à états Shopware. Quand une transaction bascule en _payée_ (Stripe, virement, PayPal, etc.), le Subscriber :
1. Cherche tous les devis pro forma au statut _Accepté_ rattachés à la commande
2. Les bascule en statut _Converti_
3. Marque l'historique de transition avec le type de déclencheur _paiement_
Aucune intervention humaine, aucun cron, aucun délai. Vos rapports commerciaux restent cohérents sans effort.
Pour désactiver l'auto-conversion (si votre équipe préfère un contrôle manuel), décochez l'option dans _Configuration du plugin → Auto-conversion à l'encaissement_.
## Flow Builder — événements Business Event
Deux événements standards Shopware sont émis par le module :
- `ProformaGeneratedEvent` — À la génération d'un devis (implémente `BusinessEventInterface`)
- `ProformaAcceptedEvent` — À l'acceptation par le client (implémente `BusinessEventInterface`)
Les deux apparaissent automatiquement dans la liste des déclencheurs du Flow Builder Shopware natif. Vous pouvez brancher dessus n'importe quelle action Flow :
- Notification Slack à l'équipe vente à l'acceptation
- Email récap interne au commercial responsable
- Webhook vers votre CRM (HubSpot, Salesforce, Pipedrive…)
- Mise à jour de champ personnalisé sur le client (par exemple, tag `quote-accepted`)
- Notification push mobile via un service tiers
Aucune intervention dans le code du module nécessaire — tout se configure depuis _Paramètres → Shop → Flow Builder_.
## Personnalisation du template PDF
Le PDF du devis est rendu via `DocumentFileRendererRegistry` (le nouveau système de rendu de fichiers Shopware 6.7), à partir du template Twig `@DfProforma/documents/proforma.html.twig` livré dans le module.
Pour le personnaliser, créez un plugin custom ou surchargez-le depuis votre thème en respectant la hiérarchie de templates Twig standard de Shopware :
```
custom/plugins/YourTheme/src/Resources/views/documents/proforma.html.twig
```
Le template livré expose ces blocs Twig identifiés :
- En-tête avec logo et coordonnées société
- Bloc client
- Récapitulatif des lignes de commande
- Totaux HT/TTC avec ventilation TVA
- Bandeau résumé en pied (numéro PF, dates d'émission et d'expiration)
- Filigrane _PRO FORMA_
- Accent de marque configurable via `config.accentColor`
Variables disponibles dans le template : `order` (OrderEntity chargée avec toutes ses associations), `config` (config du document dont `documentNumber`, `documentDate`, `validUntil`, `validityDays`), `context`.
## Multilingue
FR, EN, DE et ES sont livrés par défaut, snippets Storefront et Admin. Pour ajouter d'autres langues, créez un fichier de snippets par locale dans `src/Resources/snippet/` en suivant la convention Shopware standard.
Les templates email transactionnels sont également multilingues : le bon template est sélectionné automatiquement selon la langue du sales-channel du client au moment de l'envoi. Vous pouvez personnaliser les templates par langue depuis _Paramètres → Shop → Templates d'email_.
## API — endpoints admin disponibles
```
POST /api/_action/df-proforma/generate # Génère un devis pour une commande
POST /api/_action/df-proforma/mark-sent # Marque comme envoyé (transition manuelle)
GET /api/_action/df-proforma/by-order/{id} # Liste les devis d'une commande
```
Les entités `df_proforma` sont également accessibles via l'API DAL standard Shopware (`/api/df-proforma`) pour recherches, exports ou intégrations avancées.
## Désinstallation
Par défaut, les données métier sont conservées à la désinstallation (option _Keep User Data_ activée). Vous préservez ainsi l'historique d'audit des devis émis, utile pour la conformité et la traçabilité commerciale.
Pour forcer la suppression complète (table `df_proforma`, type de document, plage de numérotation, template email), désactivez l'option _Keep User Data_ dans le prompt de désinstallation.
**Recommandation :** gardez les données par défaut. Ne forcez la suppression que si vous êtes certain de ne plus jamais avoir besoin de remonter à l'historique des devis pour des raisons commerciales, comptables ou légales.
## Dépannage
### L'onglet Pro forma n'apparaît pas sur la fiche commande
Le bundle d'administration n'a pas été recompilé après installation. Lancez `bin/build-administration.sh` puis `bin/console cache:clear`.
### Erreur « Unable to find a document generator with type df_proforma »
Le tag de service du renderer n'est pas correct — ce bug est corrigé depuis la 1.0.2. Assurez-vous d'utiliser une version ≥ 1.0.2 du plugin.
### Erreur « Call to undefined method Context::getSalesChannelId() »
Cause historique : ancienne signature du constructeur `RenderedDocument`. Corrigé en 1.0.4. Mettez à jour vers 1.0.6.
### Erreur Twig « Cannot rewind a generator that was already run »
Corrigé en 1.0.6 — le template a été adapté pour ne pas consommer deux fois un générateur issu de `|filter()`.
### Le client reçoit l'email mais l'URL d'acceptation renvoie une erreur 404
Vérifiez que le sales-channel Storefront est bien enregistré comme domaine du canal de vente utilisé pour la commande. La route publique `/proforma/accept/{token}` est enregistrée sur le Storefront — elle ne fonctionne pas si vous accédez à l'URL via le domaine admin.
### L'expiration automatique ne fonctionne pas
Vérifiez que les _message workers_ Shopware sont bien lancés en arrière-plan (`bin/console messenger:consume` ou via un superviseur type systemd/supervisord). L'expiration passe par la file de messages Shopware standard.
## Support et mises à jour
12 mois de mises à jour incluses (compatibilité Shopware, corrections de bugs, ajouts fonctionnels mineurs). Support par email en français et anglais sous 24 heures ouvrées. Code source PHP livré en clair, conforme PSR-4, auditable et modifiable.
Pour toute question ou remontée : [contact@datafirefly.com](https://www.datafirefly.com/contact/).
---
### DfPwaPush — Guide complet
_Source :_
> DfPwaPush combine deux fonctions en un seul plugin Shopware : il transforme votre storefront en Progressive Web App installable (manifest, service worker, page hors-ligne, bannière d'installation) et vous permet de…
DfPwaPush combine deux fonctions en un seul plugin Shopware : il transforme votre storefront en **Progressive Web App installable** (manifest, service worker, page hors-ligne, bannière d'installation) et vous permet de réengager vos clients avec des **notifications Web Push** entièrement auto-hébergées. Aucun service tiers (ni Firebase, ni OneSignal), aucune dépendance Composer : le chiffrement Web Push (RFC 8291) et la signature VAPID (RFC 8292) sont implémentés nativement avec les extensions OpenSSL et cURL déjà requises par Shopware. Toutes les données d'abonnement restent sur votre serveur. Ce guide couvre l'installation, la configuration PWA et Push, la génération des clés VAPID, la création et l'envoi de campagnes, l'exécution en arrière-plan, ainsi que le dépannage.
## Installation
1. Téléchargez l'archive `DfPwaPush-1.0.2.zip` depuis votre compte DataFirefly.
2. Installez-la via **Administration → Extensions → Mes extensions → Charger l'extension**, ou copiez le dossier décompressé `DfPwaPush` dans `custom/plugins/`.
3. Lancez l'installation et l'activation : ``` bin/console plugin:refresh bin/console plugin:install --activate DfPwaPush bin/console cache:clear ```
4. À l'installation, le plugin crée ses deux tables (`df_push_subscription` et `df_push_campaign`) et enregistre sa ScheduledTask d'envoi.
Compatible Shopware 6.5.x, 6.6.x et 6.7.x sur un seul codebase. Le module d'administration est livré **précompilé** et le JavaScript du storefront est injecté via Twig : **aucun build n'est nécessaire**, ni `build-administration.sh` ni build storefront. Extensions PHP requises : `openssl` et `curl`, toutes deux déjà exigées par Shopware. Aucune dépendance Composer supplémentaire.
## Prérequis HTTPS
Les service workers et l'API Web Push n'existent que sur une origine sécurisée. Votre boutique **doit** être servie en HTTPS (seul `localhost` fait exception en développement). Sur une boutique en HTTP, le plugin reste silencieux côté front et le journalise dans la console du navigateur.
## Où trouver le plugin dans l'administration
Après activation, une entrée **Campagnes push** apparaît dans le menu **Marketing** de l'administration. C'est là que vous créez, planifiez et suivez vos campagnes. Toute la configuration PWA et Push se fait dans la configuration du plugin, par canal de vente, via **Extensions → Mes extensions → DfPwaPush → ⋯ → Configurer**.
Si l'entrée de menu n'apparaît pas après une mise à jour, exécutez `bin/console assets:install && bin/console cache:clear` puis rechargez l'administration avec un rafraîchissement forcé (Ctrl+Shift+R).
## Génération des clés VAPID
Le Web Push repose sur une paire de clés VAPID (norme RFC 8292) qui authentifie votre serveur auprès des services de push des navigateurs. Générez-les en une commande :
```
bin/console df:pwa-push:vapid:generate
```
Les clés sont écrites directement dans la configuration du plugin. Utilisez l'option `--force` pour les régénérer. Vous pouvez aussi coller des clés VAPID existantes dans les champs de configuration.
Régénérer les clés VAPID **invalide tous les abonnements existants** : les navigateurs déjà abonnés ne pourront plus recevoir de notifications et devront se réabonner. Ne le faites qu'en connaissance de cause.
## Configuration PWA
La carte **PWA** de la configuration (réglable par canal de vente) pilote l'installabilité de votre boutique :
- **Activer la PWA** : sert le manifest et le service worker.
- **Nom et nom court de l'application** : affichés sur l'écran d'accueil une fois installée.
- **Couleur du thème / couleur de fond** : par défaut `#0f172a` pour le thème.
- **Mode d'affichage** : `standalone`, `minimal-ui`, `fullscreen` ou `browser`.
- **Icônes 192 px et 512 px** : uploads PNG, **indispensables** à l'installabilité.
- **Bannière d'installation** : active l'invite « Ajouter à l'écran d'accueil ».
Sans les deux icônes 192 px et 512 px renseignées, Chrome ne considère pas le site comme installable et la bannière d'installation ne s'affichera jamais. C'est la cause numéro un d'une PWA qui « ne fait rien » côté front.
## Configuration Push
La carte **Push** contrôle les notifications :
- **Activer le Web Push** : active la bannière d'opt-in et les endpoints d'abonnement. Activé par défaut.
- **Clé publique / clé privée VAPID** : générées par la commande ci-dessus.
- **Sujet VAPID** : une adresse `mailto:` ou l'URL de votre site.
- **Délai d'opt-in** : nombre de secondes avant l'apparition de la bannière d'autorisation (8 par défaut).
## Le service worker et les endpoints du storefront
Toutes les ressources PWA sont servies dynamiquement par un contrôleur, ce qui les rend insensibles au passage de webpack à Vite en 6.7 :
- `GET /df-pwa/manifest.json` — le manifest PWA, généré par canal de vente.
- `GET /df-pwa/sw.js` — le service worker (en-tête `Service-Worker-Allowed: /` pour contrôler toute l'origine).
- `GET /df-pwa/icon/{192|512}` — les icônes PWA.
- `GET /df-pwa/offline` — la page de repli hors-ligne, mise en cache par le service worker.
- `POST /df-pwa/subscribe` et `POST /df-pwa/unsubscribe` — enregistrement et suppression d'un abonnement (XHR).
Le service worker met la page hors-ligne en cache à l'installation, sert un repli pour les navigations en échec, et affiche les notifications reçues via l'événement `push` avec redirection au clic vers l'URL de la campagne.
## Créer et envoyer une campagne
1. Rendez-vous dans **Marketing → Campagnes push → Créer une campagne**.
2. Renseignez le titre, le message, et éventuellement une URL cible et une icône.
3. Restreignez si besoin la campagne à un canal de vente (sinon tous les abonnés sont ciblés).
4. Soit vous définissez une **date de planification** et enregistrez, soit vous cliquez sur **Envoyer maintenant**.
« Envoyer maintenant » place la campagne en file immédiate (statut `scheduled` avec une date d'envoi à l'instant présent) ; la tâche planifiée la prend en charge dans les minutes qui suivent. Une campagne passe par les statuts `draft` → `scheduled` → `sending` → `sent` (ou `failed`), et la fiche affiche les compteurs d'envois réussis et d'échecs.
## Envoi en arrière-plan : ScheduledTask et CLI
L'envoi des campagnes est assuré par la ScheduledTask `df_pwa_push.send_campaigns`, exécutée toutes les 300 secondes. Elle récupère les campagnes planifiées arrivées à échéance et les envoie par lots. Vous pouvez aussi déclencher l'envoi manuellement :
```
bin/console df:pwa-push:send
```
Comme toute ScheduledTask Shopware, l'envoi dépend d'un worker actif. Assurez-vous qu'un consumer Messenger tourne (`bin/console messenger:consume`) ou que le scheduler Shopware est déclenché régulièrement, sinon les campagnes planifiées ne partiront pas.
## Web Push natif, sans dépendance
DfPwaPush implémente la pile Web Push complète en PHP pur, sans bibliothèque externe :
- **VAPID / ES256** (RFC 8292) : génération de clés P-256 via OpenSSL et signature JWT ES256 pour authentifier le serveur.
- **Chiffrement aes128gcm** (RFC 8291) : ECDH éphémère, dérivation HKDF et chiffrement AES-128-GCM du message pour chaque abonné.
- **Envoi parallèle** via `curl_multi` par lots, avec gestion des codes de retour des services de push.
L'implémentation est validée octet par octet contre le vecteur de test officiel du RFC 8291, ce qui garantit l'interopérabilité avec Chrome, Firefox, Edge et Safari.
## Nettoyage automatique des abonnements
Quand un service de push répond qu'un abonnement n'existe plus (codes HTTP 404 ou 410), l'abonnement correspondant est automatiquement désactivé. Les abonnements qui échouent de façon répétée (5 échecs consécutifs) sont eux aussi désactivés. Votre base d'abonnés reste ainsi propre sans intervention.
## Compatibilité iOS et Safari
Sur iOS, le Web Push exige **iOS 16.4 ou supérieur**_et_ que la PWA soit installée sur l'écran d'accueil : Safari ne délivre pas de notifications push à un simple onglet. Le plugin gère ce cas proprement — la bannière d'opt-in n'apparaît que lorsque l'API Push est réellement disponible, donc aucune fausse promesse n'est faite à vos visiteurs iOS.
## FAQ et dépannage
**L'installation par ZIP échoue avec « package minishlink/web-push manquant ».** Cette erreur concernait les versions antérieures. Depuis la 1.0.1, le Web Push est natif et le plugin n'a plus aucune dépendance Composer : la version actuelle s'installe sur n'importe quel hébergement, y compris mutualisé.
**Rien n'apparaît pour créer des campagnes dans le back-office.** Le module d'administration est précompilé depuis la 1.0.1. Après mise à jour, lancez `bin/console assets:install && bin/console cache:clear` et rechargez l'administration en forçant le cache (Ctrl+Shift+R). L'entrée se trouve sous **Marketing → Campagnes push**.
**L'URL /df-pwa/manifest.json renvoie une erreur 500.** Corrigé en 1.0.2 : la méthode `setTwig()` du contrôleur parent a été supprimée en Shopware 6.7, ce qui faisait échouer toutes les routes `/df-pwa/*`. Mettez à jour vers la 1.0.2 ou une version ultérieure.
**Rien ne se passe sur le storefront.** Ouvrez la console du navigateur : le plugin journalise chaque décision avec le préfixe `[DfPwaPush]` (service worker enregistré ou non, clé VAPID manquante, permission refusée, iOS sans PWA installée…). Vérifiez aussi que la boutique est en HTTPS.
**La bannière d'installation PWA ne s'affiche pas.** Chrome n'émet l'événement `beforeinstallprompt` que si le site est installable, ce qui exige les icônes 192 px et 512 px renseignées dans la configuration et un service worker actif. Sans icônes, pas de bannière.
**La bannière de notifications ne s'affiche pas.** Vérifiez que les clés VAPID sont générées, que le Web Push est activé, et que l'utilisateur n'a pas déjà refusé les notifications. La console affichera la raison exacte.
**Que se passe-t-il à la désinstallation ?** Avec l'option de suppression des données, les tables `df_push_subscription` et `df_push_campaign` sont supprimées. Sans cette option, elles sont conservées pour préserver vos abonnés et l'historique de campagnes.
---
### dfredirects — Gestionnaire de redirections 301
_Source :_
> Introduction dfredirects est un gestionnaire de redirections complet pour PrestaShop 8 et 9. Il gère les codes HTTP 301, 302, 307, 308 et 410, propose trois stratégies de matching (exact,…
## Introduction
dfredirects est un gestionnaire de redirections complet pour PrestaShop 8 et 9. Il gère les codes HTTP 301, 302, 307, 308 et 410, propose trois stratégies de matching (exact, wildcard, regex PCRE), surveille les erreurs 404 et crée automatiquement des redirections lorsque vous modifiez le slug d'un produit, d'une catégorie, d'une page CMS, d'un fabricant ou d'un fournisseur.
## Installation
1. Rendez-vous dans **Modules → Gestionnaire de modules → Installer un module**.
2. Uploadez le fichier `dfredirects-1.0.1.zip`.
3. Cliquez sur **Installer**.
4. Un nouveau menu **Redirects** apparaît dans le back-office avec quatre onglets : Dashboard, Rules, 404 Log et Import / Export / Settings.
L'installation crée trois tables : `ps_dfredirects_rule` (les règles), `ps_dfredirects_notfound` (les 404 loggées) et `ps_dfredirects_slug_snapshot` (les instantanés d'URL avant modification). La désinstallation supprime ces tables et toute la configuration.
**Prérequis :** PrestaShop 8.0 minimum, PHP 8.1 ou supérieur. Le module fonctionne à l'identique sur PrestaShop 9.
## Configuration
Rendez-vous dans **Redirects → Import / Export / Settings**. Les paramètres disponibles :
- **Log 404 errors** — interrupteur principal du logger 404.
- **Log bot 404s** — inclure ou non les requêtes des robots connus (Googlebot, Bingbot, GPTBot, ClaudeBot, etc.). Recommandé : désactivé pour garder un log propre.
- **Auto-redirect on slug change** — activation de la création automatique de 301 au changement d'URL.
- **Preserve query string by default** — valeur par défaut du champ preserve_qs pour les nouvelles règles.
- **404 log retention (days)** — durée de rétention des logs 404 avant purge automatique. 0 désactive la purge.
- **Default HTTP code** — code utilisé pour les règles créées automatiquement (301 recommandé).
- **Ignored URL patterns** — un motif par ligne, matching par sous-chaîne. Exemple : `.well-known`, `wp-admin`, `autodiscover`. Les URLs correspondantes ne seront jamais loggées.
## Créer une règle de redirection
Dans **Redirects → Rules**, cliquez sur **New rule**. Chaque règle comporte :
- **Source URL** — l'URL à intercepter (chemin relatif, ex. `/ancienne-page`).
- **Match type** — exact, wildcard ou regex (voir ci-dessous).
- **Target URL** — la destination (chemin relatif ou URL absolue pour un domaine externe). Vide pour un code 410.
- **HTTP code** — 301 (permanent, recommandé SEO), 302 (temporaire), 307/308 (conservent la méthode HTTP), 410 (contenu définitivement supprimé, sans cible).
- **Preserve query string** — si activé, `?utm_source=x` est transféré vers la cible.
- **Shop / Language** — scope de la règle. 0 = toutes les boutiques / toutes les langues.
- **Note** — champ libre pour vos annotations.
### Matching exact
L'URL demandée doit correspondre exactement à la source (après normalisation : minuscules, sans query string, sans slash final). C'est le type le plus performant — lookup indexé en base, coût constant quelle que soit la taille de la table.
### Matching wildcard
L'étoile `*` capture n'importe quelle séquence. Les captures sont réutilisables dans la cible avec `$1`, `$2`, etc.
```
Source : /ancienne-categorie/*
Cible : /nouvelle-categorie/$1
/ancienne-categorie/mon-produit → /nouvelle-categorie/mon-produit
```
### Matching regex
Syntaxe PCRE complète entre délimiteurs tilde. Les groupes capturants s'utilisent avec `$1`, `$2`, etc. Utilisez la classe `[0-9]` pour les chiffres (équivalente au raccourci antislash-d).
```
Source : ~^/product/([0-9]+)/(.*)$~
Cible : /p/$1-$2
/product/42/super-produit → /p/42-super-produit
```
Le modificateur `e` (évaluation de code) est automatiquement retiré par sécurité. Les règles regex invalides sont refusées à la création et à l'import.
## Redirections automatiques au changement de slug
Quand l'option est activée, le module capture l'URL de chaque objet avant sa mise à jour (hook `UpdateBefore`), la compare après la mise à jour (hook `UpdateAfter`), et crée une redirection 301 si l'URL a changé. Cela fonctionne pour les produits, catégories, pages CMS, fabricants et fournisseurs, pour chaque langue et boutique actives.
À la **suppression** d'un produit, une redirection est créée vers sa catégorie par défaut. À la suppression d'une catégorie, vers sa catégorie parente. Si aucune cible pertinente n'existe, le fallback est la page d'accueil.
### Détection de chaînes et de boucles
Si une règle A→B existe et que vous changez le slug de B en C, le module met automatiquement à jour la règle A pour pointer directement vers C (résolution récursive, 5 niveaux max). Les règles mises à jour de cette manière portent la mention `[chain-fix]` dans leur note. Les boucles (A→B→A) sont détectées et la création est refusée.
Les redirections automatiques ne sont créées que si le `link_rewrite` de l'objet est renseigné dans la langue concernée. Les URLs malformées (segments composés uniquement de chiffres et de tirets) sont rejetées.
## Monitoring des 404
Chaque page introuvable est enregistrée dans **Redirects → 404 Log** avec l'URL, le referrer, le user-agent, l'adresse IP, un compteur de hits et la date de dernière visite. Le filtre par défaut masque les bots et les entrées déjà résolues.
### Créer une redirection depuis une 404
Cliquez sur l'action **Create redirect** d'une entrée 404. Le module analyse votre catalogue et propose jusqu'à 5 cibles probables (produits, catégories, pages CMS) classées par similarité, avec un score visuel. Sélectionnez une suggestion ou saisissez une URL manuelle, choisissez le code HTTP, validez : la règle est créée et la 404 est marquée résolue.
## Import et export CSV
### Format du fichier
```
source_url,target_url,match_type,http_code,id_shop,id_lang,preserve_qs,active,note
/ancienne-page,/nouvelle-page,exact,301,0,0,1,1,migration 2026
/produits/*,/products/$1,wildcard,301,0,0,1,1,fr vers en
~^/cat-([0-9]+)/$~,/category/$1,regex,301,0,0,1,1,ids numeriques
```
Seules les colonnes `source_url` et `target_url` sont obligatoires (target facultative pour un code 410). Les délimiteurs virgule, point-virgule, tabulation et pipe sont auto-détectés. L'option **Update existing rules** active l'UPSERT : une source déjà présente est mise à jour au lieu d'être ignorée.
Le rapport d'import affiche le nombre de règles importées, mises à jour, ignorées, et le détail des erreurs ligne par ligne (regex invalide, source manquante, etc.).
### Export
Le bouton **Download CSV** exporte toutes les règles au format UTF-8 avec BOM, directement ouvrable dans Excel.
## Dashboard
Le tableau de bord affiche : le nombre de règles actives (avec la part auto-générée), le total de redirections servies, le nombre de 404 non résolues, la tendance 404 sur 30 jours, le top 5 des 404 les plus fréquentes, le top 5 des redirections les plus utilisées, et la liste des règles mortes (créées il y a plus de 90 jours, jamais déclenchées) — candidates à la suppression pour garder une table légère.
## Dépannage
### Ma redirection ne se déclenche pas
- Vérifiez que la règle est **active** et que son scope boutique / langue correspond à la requête.
- Les règles exact sont évaluées avant les wildcard et regex : vérifiez qu'une règle exact ne masque pas votre pattern.
- Videz le cache PrestaShop (`var/cache/`).
### Trop de 404 générées par des bots
Désactivez **Log bot 404s** dans les paramètres, ou ajoutez des motifs dans **Ignored URL patterns** (ex. `.well-known`, `wp-`, `autodiscover`).
### L'auto-redirect ne s'est pas créé au changement de slug
- L'auto-redirect ne se déclenche que si le `link_rewrite` change réellement — une modification du nom seul ne suffit pas.
- Vérifiez que l'option **Auto-redirect on slug change** est activée.
- Si l'objet était désactivé ou que son `link_rewrite` était vide dans la langue concernée, aucun instantané n'est pris.
## Changelog
### 1.0.1 — 11 mai 2026
- Validation des URLs générées avant enregistrement : rejet des sources malformées.
- Skip de la génération si le link_rewrite est vide pour la langue ou la boutique courante.
### 1.0.0 — 11 mai 2026
- Version initiale : moteur de redirection (exact / wildcard / regex), monitoring 404, auto-redirect, import/export CSV, suggestions, dashboard.
---
### DfRedirects — Redirections 301 et capture des 404 pour Shopware 6
_Source :_
> Installation, configuration et utilisation de DfRedirects : règles 301/302/410, wildcards et regex, journal des 404, suggestions de cible, import CSV et dépannage.
## Présentation
DfRedirects ajoute à Shopware 6 un véritable gestionnaire de redirections : règles 301, 302, 307, 308 et 410 avec correspondance exacte, wildcard ou expression régulière, capture automatique des erreurs 404 rencontrées par vos visiteurs, suggestions de cible par similarité d'URL et import CSV en masse. Le plugin fonctionne sur Shopware 6.5, 6.6 et 6.7 avec un seul et même ZIP.
## Installation
### Depuis l'administration
1. Rendez-vous dans **Extensions > Mes extensions**.
2. Cliquez sur **Téléverser une extension** et sélectionnez le fichier `DfRedirects-1.0.0.zip`.
3. Cliquez sur **Installer**, puis activez l'extension.
### En ligne de commande
```
bin/console plugin:refresh
bin/console plugin:install --activate DfRedirects
bin/build-administration.sh
bin/console cache:clear
```
La compilation de l'administration est **indispensable** : sans elle, le module DfRedirects n'apparaîtra pas dans le menu Contenus de votre back-office. En environnement de production, utilisez `bin/build-administration.sh` ; en développement, `./psh.phar administration:build` ou la commande équivalente de votre installation.
L'installation crée deux tables dédiées : `df_redirect` (vos règles de redirection) et `df_redirect_404` (le journal des URL introuvables).
## Configuration générale
Ouvrez **Extensions > Mes extensions > DfRedirects > Configurer**. Trois réglages sont disponibles :
- **Activer le journal des 404** : enregistre les URL introuvables rencontrées par vos visiteurs. Activé par défaut.
- **Motifs ignorés** : une entrée par ligne. Les URL correspondantes ne sont ni redirigées ni journalisées. Les jokers sont acceptés (par exemple `/api-legacy/*`) ; une simple chaîne suffit également, elle est recherchée dans l'URL.
- **Conserver la query string** : reporte les paramètres d'URL (par exemple `?utm_source=newsletter`) sur l'URL de destination. Activé par défaut, sans effet sur les réponses 410.
Les requêtes vers les ressources statiques sont ignorées d'office : dossiers système (médias, miniatures, bundles, thème) et extensions de fichiers courantes (images, CSS, JS, polices). Vous n'avez pas besoin de les déclarer dans les motifs ignorés.
## Créer une redirection
Le module se trouve dans le menu **Contenus > Redirections** de l'administration. Cliquez sur **Ajouter une redirection** et renseignez :
- **URL source** : le chemin à intercepter, relatif à la racine du canal de vente (par exemple `/anciens-produits/sneakers-cuir`).
- **URL cible** : le chemin ou l'URL absolue de destination. Ce champ est masqué pour le code 410.
- **Code HTTP** : 301 (permanent), 302 (temporaire), 307, 308 ou 410 (page définitivement supprimée).
- **Type de correspondance** : exact, wildcard ou regex (voir la section suivante).
- **Priorité** : ordre d'évaluation des motifs, du plus élevé au plus faible. Sans effet sur les correspondances exactes.
- **Canal de vente** : laissez vide pour appliquer la règle à toute la boutique, ou sélectionnez un canal précis.
- **Actif** : permet de désactiver une règle sans la supprimer.
## Les trois modes de correspondance
### Exact
L'URL source doit correspondre au chemin demandé. La présence ou l'absence de barre oblique finale est tolérée : `/ma-page` et `/ma-page/` déclenchent la même règle. C'est le mode à privilégier, il couvre la grande majorité des cas et reste le plus rapide.
### Wildcard
L'astérisque `*` capture n'importe quelle portion d'URL. Dans l'URL cible, un astérisque au même rang reprend la valeur capturée.
```
Source : /collection/ete-*
Cible : /nouveautes/*
/collection/ete-robes → /nouveautes/robes
/collection/ete-shorts → /nouveautes/shorts
```
### Regex
Pour les cas les plus fins, saisissez une expression régulière (sans délimiteurs) et référencez les groupes capturés dans la cible avec `$1`, `$2`, etc.
```
Source : ^/produit/([0-9]+)-(.+)$
Cible : /p/$2
```
Les expressions invalides sont refusées à l'enregistrement et à l'import : une règle cassée ne peut pas mettre votre boutique en erreur.
### Ordre d'évaluation
1. Correspondances exactes attachées au canal de vente courant.
2. Correspondances exactes globales.
3. Motifs wildcard et regex actifs, triés par priorité décroissante.
## Journal des 404
L'onglet **Journal des 404** liste toutes les URL introuvables rencontrées par vos visiteurs. Chaque entrée est dédupliquée : une même URL n'apparaît qu'une fois, avec son nombre d'occurrences, le référent de la dernière visite et la date du dernier passage. Triez par nombre d'occurrences pour traiter en priorité les URL cassées qui vous coûtent le plus de trafic.
Deux actions sont disponibles sur chaque ligne :
- **Créer une redirection** : ouvre le formulaire avec l'URL source pré-remplie et les suggestions de cible déjà chargées. Après enregistrement, la 404 est automatiquement marquée comme résolue.
- **Marquer comme résolu** : classe l'entrée sans créer de règle, par exemple pour une URL qui n'a jamais existé.
Un interrupteur **Afficher les résolus** permet de réafficher les entrées traitées.
## Suggestions de cible
Dès que vous saisissez une URL source, le plugin propose jusqu'à cinq destinations classées par score de similarité. Le calcul compare le dernier segment de l'URL cassée à vos URL SEO canoniques : un pré-filtre en base restreint le champ des candidats, puis un score de proximité textuelle les classe. Un clic sur une suggestion remplit le champ cible.
Les suggestions reposent sur les URL SEO canoniques et non supprimées de votre boutique. Si votre catalogue vient d'être modifié, régénérez les URL SEO de Shopware avant de vous appuyer sur les scores.
## Import CSV
Le bouton **Importer** ouvre une fenêtre acceptant soit un fichier, soit un collage direct. Le format attendu comporte cinq colonnes :
```
source;cible;code;type;actif
/ancienne-page;/nouvelle-page;301;exact;1
/collection/ete-*;/nouveautes/*;301;wildcard;1
/produit-supprime;;410;exact;1
```
- **Délimiteur** : point-virgule ou virgule, détecté automatiquement.
- **Ligne d'en-tête** : optionnelle, elle est ignorée si elle est détectée.
- **Colonnes 3 à 5** : facultatives. Par défaut, code 301, type exact, règle active.
- **Type** : déduit automatiquement si la source contient un astérisque.
- **Codes acceptés** : 301, 302, 307, 308 et 410. La cible peut rester vide pour un 410.
L'import fonctionne en mise à jour : une règle existante portant la même URL source est mise à jour plutôt que dupliquée. Les règles importées sont créées en portée globale (tous canaux). À la fin, le plugin affiche le nombre de lignes créées, mises à jour et ignorées, avec le détail des erreurs rencontrées.
## Suivi des performances
Chaque règle compte ses déclenchements et mémorise la date du dernier passage. Une règle restée à zéro pendant plusieurs mois peut souvent être archivée ; à l'inverse, une règle très sollicitée signale une ancienne URL toujours largement diffusée, qu'il peut être utile de faire corriger à la source (backlink, campagne, catalogue papier).
## Dépannage
### Le module n'apparaît pas dans le menu Contenus
La compilation de l'administration n'a pas été exécutée après l'installation. Lancez `bin/build-administration.sh` puis videz le cache de votre navigateur.
### Une redirection ne se déclenche pas
1. Vérifiez que la règle est active et que son canal de vente correspond (ou qu'elle est globale).
2. Vérifiez que l'URL source est bien relative à la racine du canal : sur un canal servi depuis un sous-dossier, ne saisissez pas le préfixe du domaine.
3. Vérifiez qu'aucun motif ignoré ne couvre cette URL.
4. Videz le cache : `bin/console cache:clear`.
5. Assurez-vous qu'aucune redirection ne soit déjà appliquée en amont par votre serveur web ou votre CDN — dans ce cas, la requête n'atteint jamais Shopware.
### Le journal des 404 reste vide
Vérifiez que l'option **Activer le journal des 404** est cochée dans la configuration du plugin, et que vos motifs ignorés ne sont pas trop larges. Rappelez-vous que les ressources statiques sont exclues par conception.
### Une boucle de redirection
Elle survient lorsqu'une règle pointe vers une URL elle-même redirigée en retour, directement ou via un motif wildcard trop large. Recherchez l'URL cible dans la liste des sources et resserrez le motif fautif.
## Désinstallation
Lors de la désinstallation, Shopware propose de conserver les données. Si vous décochez cette option, les tables `df_redirect` et `df_redirect_404` sont supprimées définitivement, ainsi que toutes vos règles et l'historique des 404. Pensez à exporter vos règles avant si vous prévoyez une réinstallation.
---
### dfreparability — Indice de réparabilité et durabilité pour PrestaShop
_Source :_
> Le module dfreparability couvre l'obligation d'affichage de l'indice de réparabilité (loi AGEC, arrêté du 29 décembre 2020) et de l'indice de durabilité (décret du 22 avril 2022) pour les 11…
Le module **dfreparability** couvre l'obligation d'affichage de l'indice de réparabilité (loi AGEC, arrêté du 29 décembre 2020) et de l'indice de durabilité (décret du 22 avril 2022) pour les 11 catégories concernées, sur PrestaShop 8 et 9.
## Cadre légal
Deux textes structurent l'obligation :
- **Indice de réparabilité** — obligatoire depuis le 1er janvier 2021 pour 9 catégories initiales, étendu progressivement (loi AGEC de février 2020, arrêté du 29 décembre 2020).
- **Indice de durabilité** — introduit par le décret du 22 avril 2022. Remplace la réparabilité pour les téléviseurs depuis avril 2024, puis pour les lave-linge à hublot depuis avril 2025.
Les deux indices se calculent sur 10 à partir des 5 critères Bercy (chacun sur 20 sous-points). L'indice de durabilité y ajoute 3 critères supplémentaires (fiabilité, améliorabilité, maintenance).
**Sanction encourue** — l'absence d'affichage expose une personne morale à jusqu'à 15 000 € d'amende par produit non conforme (article L541-9-2 du Code de l'environnement).
## Installation
1. Depuis le back-office PrestaShop, ouvrez _Modules → Gestionnaire de modules_, cliquez sur _Envoyer un module_ et déposez le fichier `dfreparability.zip`.
2. Cliquez sur _Installer_. Le module : crée la table `ps_dfreparability_product` pour stocker les notes par produit ;
3. crée une page CMS _Indice de réparabilité et de durabilité_ avec un contenu de référence prêt à personnaliser ;
4. enregistre 11 catégories préconfigurées avec les critères Bercy correspondants.
5. À l'installation seule, le module ne modifie _aucune_ fiche produit existante. Vous saisissez les notes produit par produit.
## Saisie de l'indice sur une fiche produit
dfreparability ajoute un panneau _Indice de réparabilité / durabilité_ à la fiche produit, disponible aussi bien en mode legacy qu'en mode Symfony (PrestaShop 9). La procédure est la même dans les deux modes.
### Les 4 étapes
1. **Type d'indice** — choisissez _Réparabilité_ ou _Durabilité_. Pour les téléviseurs et lave-linge à hublot, sélectionnez directement _Durabilité_ (nouvelle obligation).
2. **Catégorie** — sélectionnez parmi les 11 catégories préconfigurées. La grille des critères s'adapte automatiquement.
3. **Notes par critère** — chacun sur 20. Les 5 critères Bercy sont toujours présents. Si vous avez sélectionné _Durabilité_, les 3 critères supplémentaires apparaissent.
4. **Score final** — calculé automatiquement à partir des critères. Un champ _Score manuel_ permet de surcharger la note si vous appliquez un ajustement Bercy spécifique documenté dans la grille officielle du fabricant.
**Champ optionnel — Grille de calcul PDF** : renseignez le lien vers le PDF officiel de la grille détaillée fournie par le fabricant. Le lien est affiché sur la page de note détaillée du produit.
## Calcul du score sur 10
Le module applique la méthode officielle Bercy :
```
score_sur_10 = (somme des notes / nombre de critères) / 2
```
Exemple pour un smartphone en indice de réparabilité avec les 5 notes suivantes :
- Documentation : 16 / 20
- Démontabilité : 14 / 20
- Disponibilité des pièces : 12 / 20
- Prix des pièces : 10 / 20
- Spécifiques : 18 / 20
Score : (16 + 14 + 12 + 10 + 18) / 5 / 2 = 14 / 2 = **7,0 sur 10** — bande vert clair.
### Les 5 bandes réglementaires
La couleur du logo dépend du score et suit strictement les seuils officiels :
ScoreBandeCode couleur≥ 8,0Vert foncé`#2d8c3c`7,0 à 7,9Vert clair`#79c142`5,0 à 6,9Jaune`#f5d70a`3,0 à 4,9Orange`#f08017`< 3,0Rouge`#cf2127`
## Les 11 catégories préconfigurées
1. Smartphones
2. Ordinateurs portables
3. Téléviseurs _(durabilité depuis avril 2024)_
4. Lave-linge à hublot _(durabilité depuis avril 2025)_
5. Lave-linge top
6. Lave-vaisselle
7. Aspirateurs filaires
8. Aspirateurs sans fil
9. Aspirateurs robots
10. Nettoyeurs haute-pression
11. Tondeuses à gazon électriques
Pour chaque catégorie, le module contient la grille des critères conforme aux textes officiels. Si Bercy publie une évolution des critères, une mise à jour du module est fournie dans le cadre de votre licence.
## Affichage sur la boutique
### Choix de la position
Depuis la configuration du module (_Modules → dfreparability → Configurer_), trois positions sont proposées sur la fiche produit :
- **Sous le prix** (recommandé) — utilise le hook `displayProductPriceBlock` avec `type=after_price`. Visible dès l'ouverture de la fiche produit.
- **Dans un onglet d'informations complémentaires** — utilise `displayProductAdditionalInfo`. Cache l'indice sous un onglet dédié.
- **Sous les miniatures** — utilise `displayAfterProductThumbs`. Recommandé si votre thème place les infos produit à droite des miniatures.
Une seule position doit être active à la fois pour éviter les doublons. Le module force l'exclusivité côté configuration.
### Affichage compact dans les listes
Une option distincte active un badge compact sur les fiches produit en liste (page catégorie, recherche, résultats) via le hook `displayProductListReviews`. Le badge reprend le logo coloré et la note sur 10 sans le détail des critères.
### Page de note détaillée
Chaque produit avec un indice renseigné dispose d'une page publique `/module/dfreparability/detail?id_product={id}` qui affiche :
- le logo coloré grand format ;
- la note sur 10 avec la bande de couleur correspondante ;
- la grille complète des critères et leurs notes ;
- le lien vers le PDF officiel si vous l'avez renseigné ;
- un lien vers la page CMS d'information légale.
## Page CMS d'information légale
À l'installation, le module crée une page CMS _Indice de réparabilité et de durabilité_ avec un contenu de référence en français couvrant :
- les fondements juridiques (loi AGEC, arrêté 2020, décret 2022) ;
- la table des 5 bandes de couleurs avec les seuils ;
- la liste des 11 catégories concernées et leur date d'entrée en vigueur ;
- les 5 critères Bercy et leur pondération ;
- les critères supplémentaires pour la durabilité.
Vous pouvez modifier librement cette page depuis _Design → Pages_ et la traduire dans toutes vos langues actives. Les liens depuis les fiches produit pointent automatiquement vers la version dans la langue de navigation.
## Personnalisation du rendu
### Remplacer les logos par les originaux Bercy
Le module fournit 10 logos SVG (2 indices × 5 bandes) inspirés du visuel officiel. Si le fabricant vous a fourni les PNG ou SVG officiels, remplacez les fichiers dans `views/img/logos/` en conservant les noms :
```
reparability-dark-green.svg
reparability-light-green.svg
reparability-yellow.svg
reparability-orange.svg
reparability-red.svg
durability-dark-green.svg
durability-light-green.svg
durability-yellow.svg
durability-orange.svg
durability-red.svg
```
### Ajuster le CSS
Le rendu frontend utilise les classes `.dfrep-badge`, `.dfrep-score`, `.dfrep-band-*`. Le CSS principal est dans `views/css/dfreparability.css`. Pour surcharger sans modifier le module, ajoutez vos règles dans le CSS de votre thème enfant — les sélecteurs restent stables entre les versions.
## Multilingue et multiboutique
Traductions incluses : français, anglais, espagnol, allemand. Ajouter une langue supplémentaire se fait via l'outil standard de traduction PrestaShop (_International → Traductions_).
Les notes des produits sont stockées par `id_product` — donc partagées entre les boutiques d'un réseau multiboutique. Si un produit a des notes différentes par boutique, il faut le décliner. La page CMS d'information légale, elle, peut être différenciée par boutique via l'outil PrestaShop standard.
## Duplication de produit
Le module écoute le hook `actionProductAdd` : quand vous dupliquez un produit ayant un indice renseigné, les notes et la grille des critères sont automatiquement copiées vers le nouveau produit.
## Compatibilité et prérequis
- **PrestaShop** : 8.0 à 9.x (les deux modes fiche produit, legacy et Symfony).
- **PHP** : 7.4 minimum, 8.1+ recommandé.
- **Thèmes** : compatible Classic, Hummingbird et thèmes tiers qui déclenchent les hooks standards de la fiche produit.
- **PrestaShop 1.7** : non supporté.
## Dépannage
### Le badge s'affiche deux fois sur la fiche produit
Vérifiez que vous n'avez pas activé plusieurs positions d'affichage simultanément dans la configuration du module. Depuis la v1.0.1, le hook `displayProductPriceBlock` ne répond qu'au type `after_price`, ce qui évite le doublon interne du bloc prix.
### La page de détail renvoie « Controller not found »
Sur PrestaShop 9, vider le cache Symfony (_Paramètres avancés → Performances → Vider le cache_) après installation. La v1.0.1 corrige la casse du nom de classe du contrôleur pour la forme canonique attendue par le Dispatcher PS 9.
### Le panneau ne s'affiche pas dans la fiche produit Symfony
Vérifiez que le hook `actionProductFormBuilderModifier` est bien associé au module (_Design → Positions_). C'est le hook Symfony natif — si un autre module l'a désactivé globalement, réactivez-le sur dfreparability.
## Historique des versions
### 1.0.1 — 14 mai 2026
- Correction de l'affichage en double du badge dans le bloc prix (`displayProductPriceBlock` restreint à `after_price`).
- Correction de la classe du contrôleur frontend pour la forme canonique attendue par PrestaShop 9.
- Chargement défensif de `dfreparability.php` et `classes/DfReparabilityProduct.php` en tête du contrôleur frontend.
- Bascule de la variable Smarty `$link` vers `$module_dir` dans le template d'admin (contexte ExtraModulesType de PS 9 n'injecte pas `$link`).
### 1.0.0 — 14 mai 2026
- Première version publique.
- Indice de réparabilité et de durabilité par produit.
- 11 catégories préconfigurées, 5 bandes réglementaires, 10 logos SVG.
- Page de note détaillée, page CMS d'information légale.
- Traductions FR, EN, ES, DE. Compatible PrestaShop 8 et 9.
---
### dfsavecart — Sauvegarde de panier par lien magique
_Source :_
> Présentation dfsavecart ajoute une fonctionnalité « Garder pour plus tard » sur la page panier de votre boutique PrestaShop 8 ou 9. Le visiteur, connecté ou invité, saisit son adresse…
## Présentation
dfsavecart ajoute une fonctionnalité « Garder pour plus tard » sur la page panier de votre boutique PrestaShop 8 ou 9. Le visiteur, connecté ou invité, saisit son adresse email et reçoit un lien sécurisé (« lien magique ») qui restaure son panier exact — mêmes produits, mêmes quantités — sur n'importe quel appareil, à tout moment pendant la durée de validité configurée.
Le module est non intrusif : il n'affecte ni le tunnel de commande, ni le checkout, ni les autres modules. Il fonctionne avec le système d'email natif de PrestaShop (et donc avec votre SMTP existant).
## Prérequis
- PrestaShop 8.0.x à 9.x
- PHP 8.1 ou supérieur
- MySQL 5.7+ ou MariaDB 10.3+
- Un envoi d'email fonctionnel (Paramètres avancés > E-mail — testez l'envoi avant d'installer le module)
## Installation
1. Téléchargez le fichier `dfsavecart.zip` depuis votre compte DataFirefly.
2. Dans le back office PrestaShop, allez dans **Modules > Gestionnaire de modules**.
3. Cliquez sur **Téléverser un module** et sélectionnez le ZIP.
4. PrestaShop installe le module automatiquement : la table `ps_df_savecart` est créée et les hooks sont enregistrés.
5. Cliquez sur **Configurer** pour accéder aux réglages.
Aucun override de classe ni de contrôleur n'est installé : la désinstallation est propre et sans résidu (la table et les configurations sont supprimées).
## Configuration
Tous les réglages se trouvent sur une seule page : **Modules > Gestionnaire de modules > dfsavecart > Configurer**.
### Réglages principaux
- **Activer le module** — interrupteur général. Désactivé, le bloc disparaît du front sans désinstaller.
- **Position du bouton** — _Pied du panier_ (recommandé, hook `displayShoppingCartFooter`), _Dans le panier_ (hook `displayShoppingCart`) ou _Les deux_. Le choix dépend de votre thème : testez le rendu sur la page panier après modification.
- **Durée de validité du lien** — de 1 à 365 jours, 30 par défaut. Au-delà, le lien expire et l'entrée est purgée.
### Sécurité et anti-spam
- **Limite par email / jour** — nombre maximal d'envois pour une même adresse sur 24 h glissantes (10 par défaut). Mettre 0 pour désactiver. Le compteur repose sur un hash salé de l'email : l'adresse n'est pas stockée en clair pour cette fonction.
- **Lien à usage unique** — si activé, le lien devient invalide après la première restauration. Utile pour des paniers à caractère confidentiel (B2B, devis).
### Comportement de restauration
- **Vider le panier actuel avant restauration** — activé par défaut. Si désactivé, les produits du lien s'ajoutent au panier en cours (cumul).
### RGPD et email
- **Demander un consentement RGPD** — affiche une case à cocher obligatoire avant l'envoi (activé par défaut, recommandé).
- **Envoyer en copie cachée au marchand** — ajoute l'email de contact de la boutique en BCC sur chaque envoi, pour suivi interne.
- **Sujet email (par langue)** — personnalisable pour chaque langue active de la boutique. Variables disponibles : `{shop_name}` et `{firstname}`.
## Fonctionnement côté client
1. Le client ajoute des produits à son panier et ouvre la page panier.
2. Il voit le bloc « Garder ce panier pour plus tard » avec un champ email (pré-rempli s'il est connecté).
3. Il saisit son email, coche le consentement si demandé, et clique sur **Envoyer le lien**.
4. Il reçoit un email contenant un résumé du panier (produits, quantités, total estimé), la date d'expiration et un bouton **Restaurer mon panier**.
5. Un clic sur le bouton restaure le panier exact et redirige vers la page panier, avec un message de confirmation.
### Cas particuliers à la restauration
- **Produit désactivé ou supprimé** — la ligne est ignorée et le client est informé par un message listant les produits indisponibles.
- **Stock insuffisant** — la quantité est ajustée au maximum disponible, avec un message signalant l'ajustement.
- **Lien expiré ou déjà utilisé** (mode usage unique) — une page d'erreur sobre s'affiche, avec des liens vers le panier actuel et l'accueil.
- **Langue et devise** — celles du panier d'origine sont restaurées.
## Emails
Les templates HTML et texte sont fournis en **français, anglais, espagnol et allemand** dans `modules/dfsavecart/mails/{iso}/savecart.html` et `savecart.txt`. La langue utilisée est celle du panier au moment de la sauvegarde.
Variables disponibles dans les templates : `{firstname}`, `{shop_name}`, `{restore_link}`, `{cart_items_html}`, `{cart_items_txt}`, `{cart_total}`, `{expiry_date}`.
Pour personnaliser durablement les templates, dupliquez-les dans le dossier mails de votre thème plutôt que de modifier ceux du module : ils seraient écrasés à la mise à jour.
## Sécurité
- **Token 256 bits** — généré par `random_bytes(32)`, le générateur cryptographiquement sûr de PHP. 64 caractères hexadécimaux dans l'URL.
- **Stockage en hash** — seule l'empreinte SHA-256 du token est stockée en base. En cas de compromission de la base de données, aucun lien ne peut être reconstruit.
- **CSRF** — l'endpoint AJAX de sauvegarde vérifie le jeton de session PrestaShop.
- **Validation stricte** — le format du token est vérifié côté serveur (`[a-f0-9]{64}`) avant toute requête en base.
## RGPD
- Consentement explicite configurable avant l'envoi de l'email.
- Pour la limitation anti-spam, l'email n'est pas conservé en clair : seul un hash salé (avec la clé secrète de la boutique) est utilisé.
- Les enregistrements expirés sont supprimés automatiquement (purge) — voir section suivante.
- Aucune donnée n'est transmise à un service tiers : tout reste dans votre base PrestaShop.
- En cas de demande d'effacement d'un client, supprimez ses lignes dans la table `ps_df_savecart` (colonne `email`).
## Purge des liens expirés
Trois options, de la plus simple à la plus automatisée :
1. **Bouton manuel** — sur la page de configuration du module, « Purger les entrées expirées ».
2. **Module CronJobs** — installez le module gratuit CronJobs de PrestaShop : le hook `actionCronJob` du module est appelé automatiquement et déclenche la purge.
3. **Crontab système** — planifiez un appel régulier au cron de votre boutique selon votre configuration serveur.
## Statistiques
La page de configuration affiche quatre compteurs en temps réel : **total enregistrés**, **actifs** (non expirés), **expirés** (en attente de purge) et **restaurés** (liens utilisés au moins une fois). Le ratio restaurés / total vous donne le taux de conversion de la fonctionnalité.
## Multiboutique
Le module est compatible multiboutique : chaque sauvegarde mémorise l'identifiant de la boutique d'origine, utilisé lors de la restauration. La configuration se fait par contexte de boutique standard PrestaShop.
## Dépannage
### L'email n'arrive pas
- Vérifiez l'envoi d'email global de la boutique : **Paramètres avancés > E-mail > Tester l'envoi**.
- Vérifiez le dossier spam du destinataire.
- Consultez les logs : **Paramètres avancés > Logs** (les erreurs du module sont préfixées `[dfsavecart]`).
### Le bloc n'apparaît pas sur la page panier
- Vérifiez que le module est activé dans sa configuration.
- Vérifiez que le panier contient au moins un produit (le bloc est masqué sur panier vide).
- Vérifiez la position choisie : certains thèmes n'implémentent pas le hook `displayShoppingCartFooter` — passez alors sur « Dans le panier » ou « Les deux ».
- Videz le cache : **Paramètres avancés > Performances > Vider le cache**.
### Message « Jeton de sécurité invalide »
- La page panier est restée ouverte trop longtemps et la session a expiré : rafraîchissez la page et réessayez.
### Message « Trop de demandes pour cette adresse »
- La limite anti-spam quotidienne est atteinte pour cet email. Augmentez la limite dans la configuration ou attendez 24 h.
## Désinstallation
La désinstallation supprime la table `ps_df_savecart` (tous les paniers sauvegardés sont perdus) et l'ensemble des clés de configuration. Aucun résidu n'est laissé en base ni dans les fichiers.
---
### dfsearchconsole — Google Search Console pour PrestaShop
_Source :_
> Présentation dfsearchconsole synchronise les données de Google Search Console directement dans le back-office PrestaShop 8 et 9 : top requêtes par URL, CTR par page, position moyenne, et surtout quatre…
## Présentation
dfsearchconsole synchronise les données de Google Search Console directement dans le back-office PrestaShop 8 et 9 : top requêtes par URL, CTR par page, position moyenne, et surtout quatre catégories d'opportunités SEO calculées automatiquement avec des suggestions d'optimisation contextuelles.
Le module ajoute 5 onglets sous **Améliorer → Search Console** : Tableau de bord, Pages, Requêtes, Opportunités et Paramètres. La communication avec Google se fait via OAuth2 en lecture seule (périmètre `webmasters.readonly`), sans dépendance Composer — uniquement cURL natif.
## Installation
1. Téléchargez le fichier ZIP du module depuis votre compte client DataFirefly.
2. Dans le back-office PrestaShop : **Modules → Module Manager → Téléverser un module**.
3. Sélectionnez le fichier ZIP et laissez l'installation se terminer.
4. Le module crée 4 tables SQL (`ps_dfgsc_sync`, `ps_dfgsc_page`, `ps_dfgsc_query`, `ps_dfgsc_opportunity`) et enregistre ses 5 onglets sous le menu Améliorer.
Prérequis : PrestaShop 8.0 à 8.2 ou 9.0, PHP 7.4 minimum (8.1+ recommandé), extension cURL activée, et une propriété validée dans Google Search Console.
## Configuration OAuth Google Cloud
Le module communique avec l'API Search Console via vos propres identifiants OAuth2. La création est gratuite et prend une dizaine de minutes.
### 1. Créer le projet et activer l'API
1. Rendez-vous sur [console.cloud.google.com](https://console.cloud.google.com/) et créez un projet (ou réutilisez-en un).
2. Dans **API et services → Bibliothèque**, recherchez **Google Search Console API** et activez-la.
### 2. Configurer l'écran de consentement
1. Ouvrez **API et services → Écran de consentement OAuth**.
2. Type d'utilisateur : **Externe** (ou Interne si vous utilisez Google Workspace).
3. Renseignez le nom de l'application, l'email de support et votre domaine.
4. Ajoutez l'étendue `https://www.googleapis.com/auth/webmasters.readonly`.
5. Tant que l'application n'est pas publiée, ajoutez votre adresse Google comme **utilisateur de test**.
### 3. Créer l'ID client OAuth
1. Dans **API et services → Identifiants**, cliquez sur **Créer des identifiants → ID client OAuth**.
2. Type d'application : **Application Web**.
3. Dans **URI de redirection autorisés**, collez l'URL affichée dans l'écran Paramètres du module (de la forme `https://votre-domaine.com/module/dfsearchconsole/oauth`).
4. Notez le **Client ID** et le **Client Secret**.
### 4. Connecter le module
1. Dans PrestaShop, ouvrez **Améliorer → Search Console → Paramètres**.
2. Collez le Client ID et le Client Secret, puis enregistrez.
3. Cliquez sur **Se connecter à Google** et autorisez l'accès.
4. De retour dans le back-office, sélectionnez la propriété Search Console à synchroniser dans la liste déroulante.
Le bouton **Tester la connexion** vérifie que le token fonctionne et affiche le nombre de propriétés accessibles depuis le compte connecté.
## Synchronisation
### Synchronisation manuelle
Le bouton **Synchroniser maintenant** de l'écran Paramètres lance immédiatement une synchronisation complète. Comptez de quelques secondes pour une petite boutique à 2-3 minutes pour un site avec des milliers de pages indexées.
### Synchronisation automatique (cron)
L'écran Paramètres affiche une URL de cron protégée par un jeton aléatoire de 32 caractères. Ajoutez-la à votre crontab pour une synchronisation quotidienne :
```
0 4 * * * curl -s "https://votre-domaine.com/module/dfsearchconsole/cron?token=VOTRE_TOKEN" > /dev/null
```
Google Search Console applique un délai d'environ 2 jours sur les données. Le module synchronise donc toujours la fenêtre se terminant à _aujourd'hui − 2 jours_. Une synchronisation par jour est suffisante.
### Période de lookback
Par défaut, le module récupère 90 jours de données ainsi que les 90 jours précédents pour calculer les deltas. Cette période est configurable de 28 à 480 jours dans Paramètres. Plus la fenêtre est grande, plus la synchronisation est longue.
## Tableau de bord
Le tableau de bord donne une vue d'ensemble : 4 cartes KPI (clics, impressions, CTR, position moyenne) avec les évolutions par rapport à la période précédente, le top 10 des pages, le top 15 des requêtes et un aperçu des opportunités prioritaires.
Pour la position moyenne, une baisse est une amélioration (plus la position est basse, mieux la page est classée). Le tableau de bord affiche donc une flèche verte quand la position diminue.
## Pages et Requêtes
### Onglet Pages
Liste paginée et triable de toutes les URL remontées par Search Console, avec clics, impressions, CTR, position et delta de clics. Un filtre permet de restreindre par type de page (produit, catégorie, CMS, autre) ou par texte. Cliquer sur une URL ouvre sa vue détail : KPI de la page avec valeurs de la période précédente, requêtes ciblant cette URL, opportunités associées, et lien direct vers l'édition de l'entité PrestaShop correspondante.
### Onglet Requêtes
Deux modes d'affichage :
- **Vue groupée** — une ligne par requête, agrégée toutes URL confondues. Idéale pour identifier vos termes principaux.
- **Vue détaillée** — une ligne par couple requête × URL. Indispensable pour analyser la cannibalisation.
Les positions sont affichées avec un code couleur : vert (1-3), bleu (4-10), jaune (11-20, boostables), gris (21+).
## Opportunités SEO
Après chaque synchronisation, le module recalcule automatiquement quatre catégories d'opportunités :
- **Top 11–20 boostables (striking distance)** — requêtes positionnées entre 11 et 20 (seuils configurables) avec un minimum d'impressions. Le module calcule le gain de clics potentiel en simulant un passage en position 5.
- **CTR sous la moyenne (top 10)** — pages en top 10 dont le CTR réel est inférieur à 50 % du CTR attendu selon la courbe de référence intégrée (agrégée d'études Advanced Web Ranking, Sistrix, Backlinko).
- **Cannibalisation** — même requête remontant 2 URLs ou plus. Le module liste les URLs concurrentes.
- **Perte de clics** — pages ayant perdu plus de 25 % de clics vs la période précédente.
Chaque opportunité affiche un score de priorité, les métriques associées, et des suggestions d'optimisation adaptées au type de page (fiche produit, catégorie ou page CMS). Le workflow **Ouverte / Traitée / Ignorée** permet de suivre votre avancement. Le bouton **Recalculer** reforge toutes les opportunités à partir des données déjà en base, sans rappeler l'API Google.
## Réglages des seuils
Dans Paramètres, trois seuils pilotent la détection :
- **Impressions minimum** (défaut 50) — en dessous, le couple requête × URL est ignoré par les détecteurs.
- **Position min / max striking distance** (défaut 11 / 20) — la fenêtre de positions considérée comme boostable.
Pour une petite boutique avec peu de trafic, abaissez le seuil d'impressions à 20-30. Pour un gros site, montez-le à 100+ pour ne remonter que les chantiers significatifs.
## Dépannage
### « Token expiré » ou erreur 401
Le refresh token est utilisé automatiquement toutes les heures. Si Google a révoqué l'accès (changement de mot de passe, longue inactivité, révocation manuelle), reconnectez le module via le bouton **Se connecter à Google** de l'écran Paramètres.
### Aucun site dans la liste déroulante
Le compte Google connecté doit avoir accès à au moins une propriété Search Console (propriétaire ou utilisateur). Vérifiez sur [search.google.com/search-console](https://search.google.com/search-console) avec le même compte.
### Erreur « redirect_uri_mismatch » lors de la connexion
L'URI de redirection déclarée dans Google Cloud Console doit correspondre exactement à celle affichée dans l'écran Paramètres du module (protocole https inclus, sans slash final surnuméraire).
### Synchronisation très longue ou timeout
L'API pagine par lots de 25 000 lignes. Pour les gros sites : augmentez `memory_limit` à 512M, augmentez `max_execution_time`, et privilégiez le cron (qui n'a pas la limite de temps du navigateur).
### URLs non résolues en entités PrestaShop
Le résolveur travaille sur le `link_rewrite` (slug d'URL simplifiée). Les URLs générées par des modules de routing tiers peuvent rester non liées : elles apparaissent avec le type « other » mais restent pleinement analysées.
## Désinstallation
La désinstallation supprime les 4 tables SQL, les onglets d'administration et toutes les clés de configuration (y compris les tokens OAuth). Pensez à révoquer l'accès de l'application dans les [paramètres de sécurité de votre compte Google](https://myaccount.google.com/permissions) si vous n'utilisez plus le module.
---
### DfSocialConnect SW — Guide complet
_Source :_
> DfSocialConnect ajoute à Shopware 6 la connexion sociale Google, Apple et Facebook, avec un dashboard analytique complet intégré à l'administration. Le plugin est volontairement bâti sans bibliothèque JWT externe :…
DfSocialConnect ajoute à Shopware 6 la connexion sociale Google, Apple et Facebook, avec un dashboard analytique complet intégré à l'administration. Le plugin est volontairement bâti sans bibliothèque JWT externe : la signature ES256 du client_secret Apple est générée nativement en PHP via openssl. Un seul codebase couvre Shopware 6.6 et 6.7, sans build storefront ni administration sur mesure imposés. Ce guide couvre l'installation, la configuration par canal de vente de chaque fournisseur, l'affichage des boutons, le dashboard, la liaison automatique des comptes, la sécurité et le dépannage.
Apple Sign In exige une configuration sérieuse côté Apple Developer (Services ID, Team ID, Key ID, clé .p8) et un domaine HTTPS valide. Sans ces éléments, seuls Google et Facebook seront opérationnels. Le module fonctionne aussi parfaitement avec un seul fournisseur activé.
## Prérequis
- Shopware **6.6.x** ou **6.7.x** (la 6.5 n'est pas supportée, le plugin utilise `AccountService::loginById` introduit en 6.6).
- PHP 8.2 ou plus récent, avec l'extension `openssl` (utilisée pour la signature ES256 et le HMAC du cookie de state).
- Une URL HTTPS valide pour votre boutique : tous les fournisseurs OAuth refusent les URI de redirection en HTTP en production.
## Installation
1. Téléchargez `DfSocialConnect-v1.0.1.zip` depuis votre compte DataFirefly.
2. Installez le ZIP via **Administration → Extensions → Mes extensions → Charger l'extension**, ou copiez le dossier décompressé `DfSocialConnect` dans `custom/plugins/`.
3. Activez le plugin et rafraîchissez les caches : ``` bin/console plugin:refresh bin/console plugin:install --activate DfSocialConnect bin/console cache:clear ```
4. À l'installation, le plugin crée deux tables : `df_social_account` (identités sociales liées aux clients) et `df_social_log` (journal d'événements pour le dashboard). À la désinstallation sans conservation des données, ces deux tables sont supprimées.
Sur Shopware 6.7, la nouvelle administration Meteor charge automatiquement les modules de plugin sans build administration. Sur 6.6, si le menu « Social Connect » sous Clients ne s'affiche pas après l'installation, lancez `bin/console administration:build` puis videz les caches navigateur.
## Configuration générale
Ouvrez **Extensions → Mes extensions → DataFirefly Social Connect → ⋯ → Configurer**. Toutes les options sont scopables au canal de vente via le sélecteur natif en haut de la page : sélectionnez un canal pour lui attribuer des valeurs spécifiques, ou laissez « Tous les canaux de vente » pour des valeurs communes.
La carte **Général** contient :
- **Style des boutons** : « pleine couleur » (par défaut, aux teintes officielles), « contour » (variante sobre pour les thèmes minimalistes) ou « icône seule » (très compact, idéal en mobile).
- **Lier automatiquement par email vérifié** : si le fournisseur certifie l'email et qu'un client existe avec cette adresse, l'identité sociale est rattachée à ce compte au lieu d'en créer un doublon. Activé par défaut.
- **Ignorer le double opt-in** : les emails fournis par Google, Apple ou Facebook étant déjà vérifiés, le double opt-in est court-circuité par défaut.
- **Newsletter à l'inscription** : ajoute un flag d'opt-in newsletter sur les comptes créés via une connexion sociale.
- **Tentatives par heure (par IP)** : seuil de rate limiting du flow d'authentification. Défaut 30, augmentez si vous avez beaucoup de visiteurs derrière un même NAT.
## Google Connect
1. Allez sur **console.cloud.google.com → APIs et services → Identifiants**.
2. Créez un **ID client OAuth 2.0**, type **Application Web**.
3. Dans **URI de redirection autorisées**, ajoutez : ``` https://votre-domaine/df-social-connect/callback/google ``` Pour un multi-canal, ajoutez une ligne par domaine de canal de vente.
4. Copiez **Client ID** et **Client Secret** dans la carte **Google Connect** de la configuration du plugin, et activez le toggle **Activer Google Connect**.
Le flow est OpenID Connect avec PKCE S256, le scope demandé est `openid email profile`, et le nonce de l'`id_token` est validé côté serveur à chaque retour.
## Apple Connect
Apple est plus exigeant à configurer mais offre la meilleure expérience utilisateur sur iOS et macOS.
1. Allez sur **developer.apple.com → Certificates, Identifiers and Profiles**.
2. Créez un **App ID** avec la capability _Sign In with Apple_.
3. Créez un **Services ID** (par exemple `com.votre-marque.web`) lié à l'App ID. Dans sa configuration : **Domains** : votre domaine (sans `https://`).
4. **Return URLs** : `https://votre-domaine/df-social-connect/callback/apple`.
5. Créez une **Key** avec le service _Sign In with Apple_, téléchargez le fichier `AuthKey_XXXXX.p8` et notez son **Key ID**.
6. Récupérez votre **Team ID** en haut à droite du portail.
7. Dans la carte **Apple Connect** du plugin, renseignez : **Services ID** (ex. `com.votre-marque.web`),
8. **Team ID**,
9. **Key ID**,
10. **Clé privée** : collez le contenu complet du `.p8`, lignes BEGIN/END comprises.
Le client_secret JWT signé en ES256 est généré à la volée à chaque requête à partir de la clé .p8, sans cache : aucune rotation à gérer.
**Le piège du callback Apple form_post.** Quand on demande le scope `name email`, Apple renvoie le callback en POST cross-site, ce qui empêche le cookie de session SameSite Lax d'être renvoyé. La majorité des intégrations cassent à ce moment. DfSocialConnect pose en parallèle un cookie de state signé HMAC en SameSite None, et revalide via ce cookie quand la session n'est pas disponible. Aucune configuration n'est requise de votre côté, mais cela suppose que votre boutique est servie en HTTPS strict (les cookies SameSite=None nécessitent `Secure`).
## Facebook Connect
1. Allez sur **developers.facebook.com → Mes applications** et créez une **App** de type _Consumer_.
2. Ajoutez le produit **Facebook Login → Settings**.
3. Dans **Valid OAuth Redirect URIs**, ajoutez : ``` https://votre-domaine/df-social-connect/callback/facebook ```
4. Récupérez **App ID** et **App Secret** dans **Settings → Basic**, et collez-les dans la carte **Facebook Connect** du plugin. Activez le toggle.
Le module appelle la Graph API v21.0 avec `appsecret_proof` obligatoire (signature HMAC-SHA256 du token avec votre App Secret), ce que Facebook recommande pour toute application en production.
## Affichage des boutons côté storefront
Une fois au moins un fournisseur activé et configuré, les boutons apparaissent automatiquement :
- sur la page **/account/login**, juste sous le formulaire de connexion, précédés du séparateur « ou continuer avec » ;
- sur la page **/account/register**, au même endroit ;
- dans la page **profil du client** (`/account/profile`), un bloc **Connexions sociales** liste les identités déjà liées avec un bouton _Dissocier_ par identité, et propose en complément les fournisseurs encore disponibles.
Aucune surcharge de thème n'est nécessaire. Les templates Twig du plugin étendent les blocs `page_account_login_login`, `page_account_register_content` et `page_account_profile_personal` de Shopware. Si votre thème personnalisé surcharge déjà ces blocs et oublie d'appeler `{{ parent() }}`, ajoutez-le pour réintégrer les boutons.
### Personnaliser le style
Les boutons sont stylés via `Resources/app/storefront/src/scss/base.scss`. Trois variantes sont fournies de base (`--default`, `--outline`, `--icon`) ; pour aller plus loin, surchargez les classes `.df-social-connect__btn--google`, `--apple` et `--facebook` dans votre thème.
## Dashboard analytique
L'administration expose un module dédié sous **Clients → Social Connect**. Quatre cartes filtrables par période (7, 30 ou 90 jours) et par canal de vente :
- **Vue d'ensemble** : connexions, inscriptions, comptes liés, taux de réussite global, erreurs.
- **Par fournisseur** : barres de progression aux couleurs officielles de chaque marque.
- **Tendance quotidienne** : courbe multi-séries ApexCharts (une ligne par fournisseur).
- **Activité récente** : 25 derniers événements avec client, fournisseur, type d'événement et message.
Le module est protégé par une ACL viewer dédiée : `df_social_connect.viewer`. Pour donner accès au dashboard à un rôle utilisateur, ouvrez son profil sous **Réglages → Système → Utilisateurs et permissions**, et cochez la permission correspondante dans la catégorie _Clients_.
## Liaison automatique et anti-doublon
À chaque connexion sociale, le plugin tente trois résolutions successives :
1. **Lookup direct** par paire (fournisseur, `provider_user_id`) dans `df_social_account`. Trouvé : login immédiat sur le client lié.
2. **Liaison par email vérifié** : si le fournisseur a marqué l'email comme vérifié et qu'un client existe avec cette adresse dans le canal de vente, l'identité sociale est rattachée à ce compte. Préserve l'historique de commandes et le groupe client.
3. **Création de compte** : en dernier recours uniquement, un nouveau client est créé via `AccountService::loginById` avec un mot de passe aléatoire jamais réutilisé, une salutation neutre et une adresse minimale liée au pays par défaut du canal de vente.
La liaison automatique par email se désactive par canal de vente dans la configuration générale, si vous préférez forcer la création explicite à chaque inscription sociale.
## Sécurité
- **State OAuth signé HMAC** : protection CSRF sur tous les flows.
- **PKCE S256** sur Google : le `code_verifier` ne quitte jamais le serveur.
- **Nonce OIDC** validé côté serveur sur l'`id_token` Google.
- **appsecret_proof Facebook** : le token utilisateur ne peut pas être rejoué depuis un autre client.
- **IP hachée** : les adresses IP des événements sont hachées avant stockage dans `df_social_log`.
- **Rate limiting** par IP, seuil configurable par heure.
- **Sanitisation anti open-redirect** : les URL de retour fournies par l'utilisateur sont vérifiées contre le domaine du canal de vente avant toute redirection.
## Désinstallation
Depuis **Mes extensions**, désactivez puis désinstallez le plugin. Si l'option _Conserver les données utilisateurs_ est désactivée, les deux tables `df_social_account` et `df_social_log` sont supprimées. Les comptes clients restent intacts — seuls les liens sociaux et le journal d'événements sont effacés.
## FAQ et dépannage
**Aucun bouton ne s'affiche sur la page login.** Vérifiez que (a) au moins un fournisseur a son toggle _activé_ ET ses identifiants saisis dans la configuration ; (b) que vous êtes bien sur le canal de vente configuré ; (c) que le thème a été recompilé : `bin/console assets:install && bin/console theme:compile && bin/console cache:clear`.
**Apple renvoie invalid_client.** Le client_secret JWT a échoué côté Apple. Vérifiez Services ID, Team ID, Key ID et que le contenu de la clé .p8 inclut bien les lignes BEGIN et END. Une heure serveur dérivée déclenche aussi cette erreur car le JWT a un `iat` dans le futur.
**Apple renvoie une erreur de state au retour.** Vérifiez que votre boutique est servie en HTTPS strict (pas de redirection HTTP → HTTPS sur le callback) et que vos cookies tiers ne sont pas bloqués par un proxy frontal qui réécrirait `SameSite=None`.
**Facebook renvoie Invalid appsecret_proof provided.** Le App Secret saisi ne correspond pas à l'App ID. Régénérez-le depuis **Settings → Basic** de votre App Facebook et recollez-le.
**Le dashboard est vide alors qu'il y a eu des connexions.** Vérifiez le filtre canal de vente en haut du dashboard : il restreint toutes les statistiques. Sélectionnez « Tous les canaux de vente » pour voir l'agrégat global.
**Un utilisateur a deux comptes : l'un créé par formulaire, l'autre par Google.** La liaison automatique par email était désactivée, ou l'email du compte initial n'était pas exactement identique à celui retourné par Google. Pour fusionner, supprimez le compte le plus récent puis demandez à l'utilisateur de se reconnecter via Google : la liaison automatique le rattachera au compte conservé.
**Compatible Shopware 6.5 ?** Non. `AccountService::loginById` a été introduit en 6.6 ; ce mécanisme est central au plugin et ne peut pas être backporté proprement.
---
### dfvariantswatch — Swatches variantes photo & stock
_Source :_
> Présentation dfvariantswatch remplace les listes déroulantes de déclinaisons des fiches produit PrestaShop par des vignettes visuelles cliquables (photos, couleurs ou texte), affiche un aperçu de la variante dans la galerie…
## Présentation
dfvariantswatch remplace les listes déroulantes de déclinaisons des fiches produit PrestaShop par des vignettes visuelles cliquables (photos, couleurs ou texte), affiche un aperçu de la variante dans la galerie principale au survol, et indique le stock de chaque variante directement sur la vignette.
Le module fonctionne en améliorant les widgets natifs de PrestaShop via JavaScript : il ne remplace aucun template du thème, ce qui le rend compatible avec Classic, Hummingbird et la plupart des thèmes premium.
## Installation
1. Back-office → **Modules** → **Module Manager** → **Téléverser un module**
2. Glissez-déposez l'archive `dfvariantswatch.zip` puis cliquez sur **Installer**
3. Cliquez sur **Configurer** pour accéder aux réglages
L'installation crée la table `df_variant_swatch`, le dossier d'images `img/dfvariantswatch/` et les valeurs de configuration par défaut. Aucune modification de thème n'est nécessaire.
Dès l'installation, ouvrez une fiche produit avec des déclinaisons couleur : si vos combinaisons ont des photos, les vignettes s'affichent déjà — c'est la dérivation automatique.
## Fonctionnement des vignettes
Pour chaque attribut, le module choisit la source de la vignette dans cet ordre de priorité :
1. **Image uploadée en back-office** pour cet attribut (onglet Vignettes par attribut)
2. **Code couleur hexadécimal** défini en back-office
3. **Image dérivée automatiquement** de la première combinaison utilisant cet attribut
4. **Couleur native PrestaShop** de l'attribut (champ couleur du groupe)
5. **Pastille texte** avec le nom de l'attribut
### Le garde-fou des groupes non différenciés
La dérivation automatique n'est conservée que si les images diffèrent réellement entre les attributs du groupe, ou si le groupe est marqué comme groupe de couleurs dans PrestaShop. Concrètement : sur un produit avec un groupe Taille (S, M, L, XL) dont toutes les combinaisons partagent les mêmes photos, les tailles restent en pastilles texte au lieu d'afficher quatre fois la même photo.
## Configuration
### Paramètres généraux
- **Activer le module** — coupe le rendu front sans désinstaller
- **Survol = changement de galerie** — l'aperçu de la variante au survol d'une vignette
- **Afficher le badge stock** — état de disponibilité sous chaque vignette
- **Masquer les variantes en rupture** — cache complètement les vignettes épuisées au lieu de les barrer
- **Forme** — ronde, carrée ou pilule ; **Taille** en pixels
- **Seuil stock faible** — en dessous, le badge passe à l'état stock faible
- **Libellés stock** — les trois textes sont personnalisables et traduisibles via Localisation → Traductions
- **Mode de chargement des données** — Inline (recommandé) ou AJAX, voir ci-dessous
- **Groupes non rendus en swatches** — les groupes sélectionnés conservent leur widget natif
### Vignettes par attribut
Cet onglet liste tous les groupes d'attributs de la boutique. Pour chaque valeur, vous pouvez uploader une image (jpg, png, webp ou gif, 2 Mo maximum, 200 sur 200 pixels recommandé) ou saisir un code couleur au format #RRGGBB, prévisualiser la vignette actuelle et supprimer un swatch existant.
## Modes de chargement
**Inline (défaut, recommandé)** : les données de variantes sont embarquées dans la page au moment du rendu. Aucun appel AJAX au chargement, affichage immédiat des vignettes, robustesse maximale.
**AJAX** : les données sont récupérées via un appel après le chargement de la page. Réservez ce mode aux boutiques derrière un cache full-page agressif où la fraîcheur du stock affiché prime sur la vitesse d'affichage.
## Accessibilité clavier
Le sélecteur implémente le pattern WAI-ARIA radiogroup : la touche Tab place le focus sur la variante sélectionnée du groupe (un seul point de tabulation par groupe), les flèches naviguent et sélectionnent au sein du groupe en bouclant et en sautant les variantes indisponibles, Espace ou Entrée valide la vignette focalisée. Les états sont annoncés aux lecteurs d'écran via aria-checked et les infobulles respectent prefers-reduced-motion.
## Personnalisation CSS
Les variables CSS exposées permettent d'ajuster l'apparence depuis le CSS de votre thème enfant sans toucher au module :
```
.dfvs-swatch {
--dfvs-size: 56px; /* taille des vignettes */
}
.dfvs-swatch.dfvs-active {
box-shadow: 0 0 0 2px #b8860b; /* anneau de la variante active */
}
```
Pour désactiver l'aperçu au survol sur un produit précis, ajoutez un élément portant l'attribut `data-dfvs-disable-hover` dans le template produit.
## Dépannage
### Les vignettes ne s'affichent pas
- Vérifiez que le module est activé dans sa configuration
- Ouvrez la console du navigateur : le module trace ses étapes avec le préfixe `[dfvariantswatch]` — vous verrez le nombre de groupes rendus ou la raison du non-rendu
- Le produit doit avoir des déclinaisons ; un produit simple n'affiche rien, c'est normal
### Les tailles s'affichent en texte et pas en photo
C'est le comportement attendu du garde-fou : les valeurs du groupe partagent les mêmes photos de combinaisons. Uploadez des images dédiées par taille dans l'onglet Vignettes par attribut si vous souhaitez des visuels (par exemple des pictogrammes de gabarit).
### Le bloc natif réapparaît après un clic
Le module ré-applique le masquage après chaque mise à jour AJAX de PrestaShop. Si un thème très personnalisé contourne les événements standards, contactez le support avec l'URL de la fiche produit concernée.
## Désinstallation
La désinstallation supprime la table du module, les images uploadées dans `img/dfvariantswatch/` et toutes les clés de configuration. Les photos de vos combinaisons ne sont évidemment pas touchées.
---
### Digital Product Passport (DPP) — Guide complet
_Source :_
> Le module DataFirefly — Digital Product Passport (dfdpp) ajoute à votre boutique PrestaShop 8 ou 9 un système complet de passeport numérique produit conforme au règlement européen ESPR (Ecodesign for…
Le module **DataFirefly — Digital Product Passport (dfdpp)** ajoute à votre boutique PrestaShop 8 ou 9 un système complet de passeport numérique produit conforme au règlement européen **ESPR** (Ecodesign for Sustainable Products Regulation), applicable progressivement à partir de 2027 pour le textile, les batteries et l'électronique.
Chaque produit reçoit un passeport avec identifiant unique (UUID), une page publique multilingue accessible par QR code, un registre de composants (nomenclature / BOM), un journal des événements de cycle de vie et une gestion des certificats de conformité.
## Prérequis
- PrestaShop **8.0.0 à 9.x**
- PHP 7.4 minimum (8.1+ recommandé)
- Extension GD activée (génération des QR codes en secours si Endroid n'est pas disponible)
- Compatible multiboutique et multilingue (FR / EN / ES / DE / IT inclus)
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et téléversez `dfdpp.zip`.
3. Le module crée automatiquement ses tables, son menu **Passeports produit** sous _Catalogue_ et enregistre ses routes publiques.
Aucune bibliothèque externe n'est embarquée : le module utilise Endroid QR Code fourni par le cœur PrestaShop (v3, v4 ou v5 détectée automatiquement), avec un rendu GD de secours.
## Configuration
Ouvrez **Modules > dfdpp > Configurer**. Trois blocs sont disponibles :
### Paramètres généraux
- **Activer le module** — interrupteur global.
- **Création automatique** — génère un passeport brouillon à chaque enregistrement de produit.
- **Catégorie ESPR par défaut** — textile, batterie, électronique, mobilier, chaussure ou général.
- **Affichage public** — active la page publique `/dpp/{uuid}`.
- **Onglet fiche produit** — affiche le passeport dans un onglet de la fiche produit.
- **Export JSON public** — autorise le téléchargement du passeport au format JSON.
### QR code
- **Taille** (par défaut 220 px) et **marge** (10 px).
- **Niveau de correction d'erreur** — M recommandé (équilibre densité / robustesse).
### Informations société
Nom, numéro de TVA, adresse et pays de l'opérateur économique responsable — ces informations apparaissent sur la page publique du passeport, comme l'exige l'ESPR.
## Créer un passeport
### Création automatique
Si l'option est activée, un passeport en statut _brouillon_ est créé à chaque enregistrement de produit, avec la catégorie ESPR par défaut. Il ne devient visible publiquement qu'une fois **publié** manuellement.
### Création manuelle
1. Ouvrez **Catalogue > Passeports produit > Passeports**.
2. Cliquez sur **Ajouter**, sélectionnez le produit (et la déclinaison si nécessaire).
3. Renseignez les champs puis enregistrez : un UUID v4 unique est généré automatiquement.
Depuis la fiche produit du back-office, l'onglet **Passeport numérique** permet de créer ou d'ouvrir directement le passeport du produit en cours d'édition.
## Données du passeport
Le formulaire est organisé en cinq blocs :
- **Identification** — produit, déclinaison, catégorie ESPR, GTIN, fabricant, pays d'origine, date de production, numéro de lot.
- **Durabilité** — empreinte carbone (kg CO₂e), score de recyclabilité, pourcentage de contenu recyclé, indice de réparabilité, durée de vie attendue, garantie.
- **Contenus multilingues** — composition des matériaux, instructions d'entretien, consignes de tri et de fin de vie, informations de réparation, informations de sécurité, certificats de conformité (six champs texte riches, traduisibles dans chaque langue de la boutique).
- **Composants, événements et documents** — gérés en AJAX directement dans la fiche passeport (voir ci-dessous).
- **Champs personnalisés** — un objet JSON libre pour toute donnée sectorielle supplémentaire.
## Registre des composants (BOM)
Chaque passeport peut recenser sa nomenclature complète : nom du composant, matériau, poids (g), pourcentage du produit, part recyclée, caractère recyclable, dangerosité, numéro CAS, fournisseur et pays. Les composants peuvent être **imbriqués** (composant parent / sous-composant) pour modéliser des assemblages.
Le menu **Catalogue > Passeports produit > Registre** offre une vue transversale de tous les composants de la boutique, filtrable par matériau, dangerosité ou fournisseur — pratique pour les audits REACH.
## Événements de cycle de vie
Le journal retrace la vie du produit : conception, matière première, fabrication, contrôle qualité, distribution, première vente, revente, réparation, reconditionnement, recyclage, fin de vie. Chaque événement porte une date, un lieu, un acteur (nom + rôle), une description et une URL de preuve facultative.
La vue **Catalogue > Passeports produit > Événements** centralise tous les événements avec filtre par type.
## Documents et certificats
Attachez à chaque passeport les certificats exigés : déclaration CE, REACH, RoHS, DEEE, règlement batteries UE, OEKO-TEX, GOTS, Écolabel, FSC, ISO 14001 / 9001, PEF, EPD ou autre. Chaque document porte un numéro, un émetteur, des dates de validité et une URL de fichier.
Un certificat expiré est signalé comme _blocker_ par le moteur de conformité et fait chuter le score du passeport.
## Score de conformité ESPR
Le module évalue chaque passeport selon des règles propres à sa catégorie ESPR et affiche un score sur 100 accompagné d'un niveau :
- **Conforme** — score ≥ 90 sans point bloquant.
- **Partiel** — score ≥ 60.
- **Brouillon** — données incomplètes.
- **Non conforme** — points bloquants présents.
La liste des vérifications et des points bloquants est détaillée dans la fiche passeport ; le bouton **Recalculer** actualise le score après modification.
## Page publique et QR code
Chaque passeport publié est accessible à l'adresse `https://votre-boutique.com/dpp/{uuid}` et son QR code PNG à `/dpp/{uuid}/qr.png` (paramètre `?size=` accepté de 80 à 800 px, cache navigateur de 24 h).
La page publique présente : visuel et identité du produit, QR code, indicateurs de durabilité, composition, tableau des composants, entretien et réparation, consignes de tri, chronologie du cycle de vie, certificats, informations de sécurité et coordonnées de l'opérateur responsable. Elle embarque un balisage **JSON-LD schema.org** pour le référencement.
Imprimez le QR code sur l'étiquette, la notice ou l'emballage du produit : c'est le mode d'accès prévu par l'ESPR pour le consommateur final, les réparateurs et les recycleurs.
## Affichage sur la fiche produit
Si l'option est activée, un onglet **Passeport numérique** apparaît sur la fiche produit du front-office avec le QR code, les indicateurs clés et le lien vers la page publique. Un bloc de secours peut également s'afficher sous la description.
## RGPD et journal d'accès
Les consultations publiques peuvent être journalisées de façon anonymisée : l'adresse IP est hachée en SHA-256 avec un sel quotidien et la clé secrète de la boutique — aucune donnée personnelle exploitable n'est conservée. L'option est désactivable dans la configuration.
## Multiboutique et multilingue
Les passeports sont rattachés à une boutique (contexte multishop respecté) et tous les contenus rédactionnels existent dans chaque langue active. Le module est livré traduit en français, anglais, espagnol, allemand et italien (format XLIFF, modifiable via **International > Traductions**).
## Désinstallation et conservation des données
À la désinstallation, la configuration et les onglets d'administration sont supprimés, mais **les tables de données sont conservées** : le règlement ESPR impose la disponibilité du passeport pendant toute la durée de vie du produit. Pour une suppression définitive, supprimez manuellement les tables `ps_dfdpp_*`.
## Dépannage
### La page /dpp/{uuid} renvoie une 404
- Vérifiez que le passeport est bien **publié** et que l'affichage public est activé.
- Videz le cache PrestaShop (_Paramètres avancés > Performances_) pour régénérer les routes.
- Vérifiez la réécriture d'URL (URL simplifiées activées).
### Le QR code ne s'affiche pas
- Vérifiez que l'extension PHP GD est active si votre installation ne fournit pas Endroid QR Code.
### L'onglet n'apparaît pas sur la fiche produit
- Activez l'option **Onglet fiche produit** dans la configuration et vérifiez que votre thème supporte le hook `displayProductExtraContent`.
## Journal des versions
- **1.0.0** — Version initiale : passeports UUID, page publique multilingue, QR codes, composants imbriqués, événements de cycle de vie, documents, score de conformité ESPR par catégorie, export JSON / JSON-LD, journal d'accès RGPD, multiboutique.
---
### Disponibilité des pièces détachées (dfspareparts)
_Source :_
> Le module Disponibilité des pièces détachées affiche, pour chaque produit, la durée pendant laquelle ou la date jusqu'à laquelle les pièces détachées sont disponibles, conformément à l'obligation d'information de l'article…
Le module **Disponibilité des pièces détachées** affiche, pour chaque produit, la durée pendant laquelle ou la date jusqu'à laquelle les pièces détachées sont disponibles, conformément à l'obligation d'information de l'article L111-4 du Code de la consommation. L'information apparaît avant l'achat (fiche produit) et comme confirmation écrite lors de l'achat (page de commande et facture PDF).
## Compatibilité
- PrestaShop 8.0 à 9.x, mono et multiboutique.
- PHP 8.1 et supérieur.
- Interface en français, chaînes traduisibles via le système de traduction de PrestaShop.
## Installation
1. Dans le back-office, ouvrez _Modules > Gestionnaire de modules_.
2. Cliquez sur _Installer un module_ et déposez le fichier `dfspareparts.zip`.
3. Cliquez sur _Installer_. Le module crée sa table, son onglet produit et enregistre ses hooks d'affichage.
La table de données est conservée à la désinstallation : vous ne perdez pas vos saisies en cas de réinstallation.
## Réglages généraux
Ouvrez la page de configuration du module (_Configurer_). Vous y trouvez :
- **Libellé affiché** : l'intitulé montré au client (par défaut « Disponibilité des pièces détachées »).
- **Afficher sur la fiche produit / la confirmation de commande / la facture PDF** : activez ou désactivez chaque emplacement.
- **Masquer si non renseigné** : ne rien afficher pour les produits sans information ni valeur par défaut.
- **Valeurs par défaut** : statut, durée, unité et point de départ appliqués aux produits non renseignés individuellement.
## Renseigner un produit
Sur la fiche produit (back-office), ouvrez l'onglet **Disponibilité des pièces détachées**. Choisissez un statut :
- **Disponible — durée** : saisissez une durée (années ou mois) et un point de départ (mise sur le marché de la dernière unité, ou date d'achat).
- **Disponible — jusqu'à une date** : sélectionnez une date limite.
- **Non disponible** : indique l'absence de pièces détachées pour ce produit.
- **Non renseigné** : le produit hérite des valeurs par défaut du module.
Une **note complémentaire** facultative peut être ajoutée à la suite, et un **aperçu en direct** montre le texte tel qu'il sera affiché.
L'aperçu reflète aussi l'héritage : si le produit reste « Non renseigné », l'aperçu affiche la valeur par défaut configurée.
## Affectation en masse
Toujours depuis la page de configuration, le panneau **Affectation en masse** applique une même information à un ensemble de produits :
- par **catégories** sélectionnées, ou sur **tout le catalogue** de la boutique courante ;
- choisissez le statut, la durée et le point de départ, puis cliquez sur _Appliquer_.
L'affectation en masse remplace les valeurs individuelles déjà saisies sur les fiches concernées. Le bouton _Tout réinitialiser_ efface les données de la boutique courante.
## Où l'information s'affiche
- **Fiche produit** : encart sous le prix et le bouton d'ajout au panier (hook `displayProductAdditionalInfo`).
- **Confirmation de commande** : récapitulatif des produits concernés (hook `displayOrderConfirmation`).
- **Facture PDF** : bloc repris sur la facture (hook `displayPDFInvoice`).
## Multiboutique
Les données et les réglages sont gérés par boutique. Renseignez chaque boutique dans son propre contexte ; l'affectation en masse agit sur la boutique courante.
## Notes légales
Le module fournit le cadre d'affichage et de saisie conforme à l'article L111-4. L'exactitude des durées renseignées relève de l'information transmise par le fabricant ou l'importateur. Ce module ne constitue pas un conseil juridique.
## Dépannage
- **Rien ne s'affiche sur la fiche produit** : vérifiez que l'affichage fiche produit est activé, que le produit est renseigné (ou qu'une valeur par défaut existe et que « Masquer si non renseigné » est désactivé).
- **Rien sur la facture** : si vous utilisez un modèle de facture fortement personnalisé, vérifiez la présence du hook `displayPDFInvoice` dans votre modèle.
---
### Documentation DfStreamCategoryTree pour Shopware 6
_Source :_
> DfStreamCategoryTree ajoute un champ Category (including subcategories) au constructeur de conditions des groupes de produits dynamiques de Shopware 6. Filtrer sur une catégorie parente inclut alors tous les produits rangés…
DfStreamCategoryTree ajoute un champ **Category (including subcategories)** au constructeur de conditions des groupes de produits dynamiques de Shopware 6. Filtrer sur une catégorie parente inclut alors tous les produits rangés dans ses sous-catégories, quelle que soit la profondeur.
## Le problème que le plugin résout
Le constructeur de conditions natif propose un champ _Categories_ qui interroge la relation `product.categoriesRo`. Cette relation ne contient que les catégories auxquelles un produit est explicitement rattaché dans son onglet Categories.
Un catalogue correctement organisé range ses produits dans les catégories feuilles. Un modèle de sneakers est affecté à Homme / Chaussures / Sneakers, pas à Homme. Un filtre sur Homme ne retourne donc que les rares produits affectés directement à ce niveau, souvent aucun.
La solution native consiste à cocher manuellement chaque sous-catégorie, puis à rouvrir la configuration du stream à chaque évolution de l'arborescence. Ce plugin supprime cette maintenance.
## Comment ça fonctionne
Shopware maintient déjà, pour chaque produit, un champ JSON nommé `categoryTree` qui contient l'identifiant de toutes les catégories du chemin, depuis la racine jusqu'à la catégorie d'affectation. Ce champ est recalculé par le CategoryIndexer natif à chaque déplacement de catégorie et à chaque changement d'affectation produit.
Un filtre `equalsAny` sur ce champ avec l'identifiant d'une catégorie parente remonte donc tous les produits dont le chemin passe par elle. Le champ existe et fonctionne parfaitement dans le DAL, mais l'administration ne l'expose pas dans le sélecteur du constructeur de conditions : il ne figure pas dans la liste d'autorisation du service `productStreamConditionService`.
Le plugin ajoute une entrée à cette liste d'autorisation et fournit les libellés traduits associés. Il n'introduit aucun décorateur de service, aucun listener sur les événements produit, aucune table et aucune migration.
## Prérequis
- Shopware 6.7.x auto-hébergé
- PHP 8.2 ou supérieur
- Accès à la ligne de commande ou à un pipeline de déploiement capable de recompiler l'administration
Le plugin ne fonctionne pas sur Shopware Cloud, la version SaaS hébergée par Shopware n'autorisant pas l'installation de plugins serveur.
## Installation
### Par upload de ZIP
1. Dans l'administration, ouvrez Extensions puis Mes extensions
2. Cliquez sur Charger l'extension et sélectionnez l'archive DfStreamCategoryTree-1.0.0.zip
3. Installez puis activez le plugin
4. Recompilez l'administration (voir la section suivante)
### Par dépôt du dossier
Décompressez l'archive dans le répertoire des plugins personnalisés de votre instance, puis exécutez :
```
bin/console plugin:refresh
bin/console plugin:install --activate DfStreamCategoryTree
bin/console cache:clear
```
## Recompilation de l'administration
Le plugin modifie le comportement de l'interface d'administration. Une recompilation du bundle admin est nécessaire une fois après l'installation, sans quoi le nouveau champ n'apparaîtra pas dans le sélecteur de conditions.
```
bin/console bundle:dump
./bin/build-administration.sh
bin/console cache:clear
```
Sur un environnement de production géré par un pipeline de déploiement, cette étape fait généralement déjà partie du processus standard. Videz ensuite le cache de votre navigateur ou ouvrez l'administration dans une fenêtre privée pour être certain de charger le bundle à jour.
## Utilisation
### Créer un groupe dynamique récursif
1. Ouvrez Catalogues puis Dynamic product groups
2. Créez un nouveau groupe ou ouvrez un groupe existant
3. Dans le constructeur de conditions, déroulez le sélecteur de champ
4. Choisissez **Category (including subcategories)**, juste au-dessus de l'entrée _Categories_ d'origine
5. Sélectionnez l'opérateur **Is equal to any of**
6. Choisissez une ou plusieurs catégories parentes dans le champ de valeur
7. Enregistrez, puis ouvrez l'onglet Preview pour vérifier le nombre de produits retournés
### Opérateurs disponibles
- **Is equal to any of** : le produit appartient au sous-arbre d'au moins une des catégories sélectionnées
- **Is not equal to any of** : le produit n'appartient au sous-arbre d'aucune des catégories sélectionnées, utile pour exclure un rayon entier d'une opération commerciale
### Combiner avec d'autres conditions
Le champ se comporte comme n'importe quelle autre condition du stream. Il se combine librement avec le fabricant, le prix, l'état du stock, les propriétés, les tags, et s'utilise dans les groupes AND et OR imbriqués du constructeur.
Exemple de configuration typique pour une opération de déstockage : Category (including subcategories) is equal to any of Homme, ET Stock is greater than 0, ET Price is greater than 50.
### Où le groupe est utilisable
- Page de catégorie de navigation alimentée par un groupe dynamique
- Blocs de produits dans les Shopping Experiences
- Conditions de règles de promotion
- Cross-selling automatique sur la fiche produit
- Toute intégration consommant un product stream via l'Admin API ou la Store API
## Utilisation via l'Admin API
Le champ étant natif au DAL, une condition posée directement en API fonctionne même sans le plugin. Le plugin sert à rendre ce filtre visible et modifiable dans l'interface, ce qui compte dès qu'une équipe marketing gère les groupes sans passer par l'API.
```
POST /api/product-stream
{
"name": "Tout le rayon Homme",
"filters": [
{
"type": "equalsAny",
"field": "product.categoryTree",
"value": "01920f7c8a3d71c2b4e5f6a7b8c9d0e1"
}
]
}
```
Sans le plugin installé, un stream contenant ce filtre reste fonctionnel côté DAL mais son champ n'est pas affichable dans le constructeur de conditions.
## Dépannage
### Le champ n'apparaît pas dans le sélecteur
Dans l'immense majorité des cas, l'administration n'a pas été recompilée après l'installation. Relancez la séquence bundle:dump, build-administration puis cache:clear, et rechargez l'administration en vidant le cache navigateur. Vérifiez aussi que le plugin est bien actif dans Extensions puis Mes extensions.
### Le groupe ne retourne toujours pas les bons produits
Vérifiez que vous avez bien sélectionné le nouveau champ et non l'entrée _Categories_ d'origine, les deux coexistant dans le sélecteur. Vérifiez ensuite dans la fiche d'un produit attendu que celui-ci est bien affecté à une sous-catégorie du parent choisi, et qu'il est actif et visible sur le canal de vente concerné.
### Un produit récemment déplacé ne remonte pas
Le champ categoryTree est recalculé par le CategoryIndexer natif. Si la file de messages est en retard ou si l'indexation a été mise en pause, forcez une réindexation :
```
bin/console dal:refresh:index --only=product.indexer,category.indexer
```
### Réinitialiser après une mise à jour majeure de Shopware
Après une montée de version mineure de Shopware, recompilez l'administration pour que le plugin réenregistre son entrée dans la liste d'autorisation. Aucune autre action n'est nécessaire, le plugin ne stockant aucune donnée.
## Désinstallation
Désactivez puis désinstallez le plugin depuis Extensions ou en ligne de commande. Le plugin ne crée aucune table et ne stocke aucune configuration, la désinstallation est donc entièrement neutre.
```
bin/console plugin:deactivate DfStreamCategoryTree
bin/console plugin:uninstall DfStreamCategoryTree
```
Les groupes dynamiques déjà configurés avec le filtre continuent de fonctionner : la condition est stockée en base sous forme de filtre DAL standard et reste évaluée par le moteur natif. Seul l'affichage du champ dans le constructeur de conditions disparaît, ce qui rend le filtre non modifiable depuis l'interface tant que le plugin n'est pas réactivé. Aucune donnée n'est perdue.
## Limites connues
- Le plugin ne s'applique pas aux filtres de listing du storefront ni à la navigation à facettes, qui relèvent d'un mécanisme distinct
- Il ne modifie pas l'algorithme d'indexation des catégories, il consomme le champ que Shopware produit déjà
- Il ne fonctionne pas sur Shopware Cloud
---
### Duplication Multiboutique d'une Catégorie Complète — PrestaShop 8 & 9
_Source :_
> Ce module ajoute au back-office un assistant qui duplique une catégorie entière — avec tous ses produits, déclinaisons, images, attributs, prix spécifiques et stock — d'une boutique vers une ou…
Ce module ajoute au back-office un assistant qui duplique une **catégorie entière** — avec tous ses produits, déclinaisons, images, attributs, prix spécifiques et stock — d'une boutique vers une ou plusieurs autres boutiques d'un même PrestaShop en multiboutique. Cette documentation couvre l'installation, le fonctionnement interne et l'utilisation pas à pas de l'assistant.
## Prérequis
- PrestaShop 8.0 à 9.x.
- Le **mode multiboutique doit être activé** (Paramètres avancés puis Multiboutique), avec au moins deux boutiques.
- Un profil employé disposant de l'accès en écriture au catalogue.
Si le multiboutique est désactivé ou qu'une seule boutique existe, l'assistant affiche un message et n'autorise pas la duplication : il n'y aurait aucune boutique cible.
## Installation
1. Dans le back-office, ouvrez Modules puis Gestionnaire de modules.
2. Cliquez sur « Envoyer un module » et déposez le fichier ZIP.
3. Une fois installé, un onglet apparaît sous Catalogue, nommé « DF Shop Duplicator ».
## Comment ça fonctionne
Contrairement à un simple duplicateur de produits, le module ne crée pas de nouvelles entités produit. Il s'appuie sur le mécanisme d'**association multiboutique** natif de PrestaShop : un produit reste une entité partagée, et seules les données propres à chaque boutique sont copiées vers la boutique cible.
Concrètement, pour chaque produit dupliqué, le module recopie les lignes par boutique : product_shop, product_lang, image_shop, product_attribute_shop, stock_available, specific_price (limité à la boutique, hors panier), ainsi que les associations de transporteurs et les tables de correspondance nécessaires (attributs, groupes d'attributs, caractéristiques, marque, fournisseur, groupe de taxes).
Conséquence directe : aucune référence produit dupliquée, aucune image recopiée sur le disque, et les modifications globales futures d'un produit restent propagées à toutes les boutiques qui le partagent.
Les **catégories**, en revanche, sont traitées différemment. L'identifiant du parent d'une catégorie (id_parent) étant global, on ne peut pas simplement « associer » une arborescence sous un autre parent. Le module crée donc de nouvelles catégories sous le parent cible que vous avez désigné — ou réutilise celles qui existent déjà, selon l'option choisie.
## Utiliser l'assistant en 3 étapes
### Étape 1 — Boutique et catégorie source
Sélectionnez la boutique de départ, puis la catégorie à dupliquer dans l'arbre. Cochez « inclure les sous-catégories » si vous souhaitez traiter toute la branche et non la seule catégorie sélectionnée. Le nombre de produits concernés est affiché pour vous repérer.
### Étape 2 — Boutiques cibles et mapping
Cochez la ou les boutiques de destination. Pour chaque boutique cochée, un arbre de catégories apparaît : désignez-y la **catégorie de destination** sous laquelle les produits (et éventuellement l'arborescence) seront placés. Par défaut, la racine de la boutique cible est présélectionnée.
### Étape 3 — Options et exécution
Réglez les options de copie (voir la section suivante), vérifiez le résumé, puis lancez la duplication. Une barre de progression et un journal en direct affichent l'avancement, produit par produit, ainsi que les éventuels avertissements.
## Les options en détail
- **Copier l'arborescence** : recrée les sous-catégories sous la catégorie cible en respectant la hiérarchie. Décochée, tous les produits sont placés directement sous la catégorie cible (mode « flatten »).
- **Réutiliser les catégories existantes** : au lieu de recréer des catégories, le module retrouve celles déjà présentes sous le parent cible par correspondance de leur réécriture d'URL. C'est ce qui rend la duplication **idempotente**.
- **Copier les quantités** : duplique le stock vers la boutique cible (voir la gestion du stock ci-dessous).
- **Prix spécifiques** : recopie les prix spécifiques limités à la boutique.
- **Produits de packs (récursif)** : associe également les produits enfants des packs présents dans la sélection.
- **Réindexation de la recherche** : réindexe chaque produit copié pour la recherche front-office. Utile mais plus lent sur de gros volumes.
- **Taille de lot** : nombre de produits traités par passe AJAX (20 par défaut, jusqu'à 200). Réduisez-la sur un hébergement contraint, augmentez-la pour aller plus vite.
## Recréation et réutilisation des catégories
Lorsque « Réutiliser les catégories existantes » est activée, le module recherche sous le parent cible une catégorie dont la réécriture d'URL correspond à celle de la source. S'il en trouve une, il l'utilise ; sinon, il en crée une nouvelle. Vous pouvez ainsi **relancer la duplication autant de fois que nécessaire** sans accumuler de doublons de catégories — par exemple après avoir ajouté de nouveaux produits à la source.
Pour une première synchronisation « à plat » où tous les produits doivent atterrir sous une seule catégorie cible, décochez « Copier l'arborescence » et laissez « Réutiliser les catégories existantes » cochée.
## Gestion du stock et partage entre boutiques
La copie du stock tient compte du paramètre de **partage du stock** du groupe de boutiques. Si la boutique source et la boutique cible partagent déjà le même pool de stock, la copie est ignorée : dupliquer les quantités créerait des incohérences. Dans le cas contraire, les quantités sont recopiées vers la boutique cible. Ces décisions sont tracées dans le journal d'exécution.
## Produits de packs
Si la sélection contient des packs et que l'option correspondante est activée, le module associe récursivement les produits enfants de chaque pack à la boutique cible, afin que le pack reste vendable. Une protection évite les boucles en cas de packs imbriqués.
## Gros catalogues et reprise
L'exécution se déroule par **lots AJAX successifs** : le navigateur enchaîne les appels jusqu'à la fin, ce qui évite tout timeout PHP même sur plusieurs milliers de produits et de déclinaisons. Le job est **persisté en base de données** (table dédiée), avec un pointeur de position : si le traitement est interrompu (fermeture d'onglet, coupure réseau), il peut reprendre là où il s'était arrêté plutôt que de tout recommencer.
## Dépannage
### L'assistant indique que le multiboutique n'est pas disponible
Vérifiez que le mode multiboutique est activé et qu'au moins deux boutiques existent. L'assistant a besoin d'une boutique source et d'au moins une boutique cible distincte.
### Des produits semblent « manquants » dans la boutique cible
Assurez-vous que la catégorie de destination est correctement mappée à l'étape 2 et que les produits sont bien actifs. En mode « flatten », les produits sont placés sous la catégorie cible unique, pas sous une arborescence recréée.
### Le stock n'a pas été copié
C'est le comportement attendu si les deux boutiques partagent le même pool de stock. Le journal d'exécution le signale par un avertissement.
### Après une deuxième exécution, je vois des catégories en double
Activez « Réutiliser les catégories existantes ». Sans cette option, chaque exécution recrée de nouvelles catégories sous le parent cible.
---
### Dynamic Pricing Engine — Guide complet
_Source :_
> Guide complet du plugin Dynamic Pricing Engine pour WooCommerce : installation, configuration, 4 types de règles (heure, stock, segment, concurrent), segments clients, scraping concurrentiel, A/B testing natif, journal, garde-fous à 3 niveaux, FAQ.
Bienvenue dans la documentation complète de **Dynamic Pricing Engine**, le moteur de tarification dynamique pour WooCommerce édité par DataFirefly. Ce guide couvre l'installation, la configuration initiale, chaque type de règle, la segmentation client, le scraping concurrentiel, l'A/B testing, le journal, les garde-fous, et la désinstallation.
**Prérequis :** WordPress 6.0+, WooCommerce 8.0+, PHP 7.4+. Compatible HPOS et blocs Checkout.
## Installation
### Téléversement du plugin
1. Depuis le back-office WordPress, allez dans **Extensions → Ajouter → Téléverser une extension**.
2. Sélectionnez le fichier `dfdynamicpricing.zip` et cliquez sur _Installer maintenant_.
3. Une fois l'installation terminée, cliquez sur _Activer l'extension_.
### Ce qui se passe à l'activation
Le plugin crée 6 tables personnalisées (préfixées par `wp_dfdpe_`) :
- `wp_dfdpe_rules` — les règles de prix
- `wp_dfdpe_logs` — le journal des ajustements
- `wp_dfdpe_segments` — les segments clients (3 seedés automatiquement)
- `wp_dfdpe_competitors` — le suivi concurrentiel
- `wp_dfdpe_ab_tests` — les tests A/B
- `wp_dfdpe_ab_events` — les événements d'exposition, ATC et conversion
Deux tâches cron sont également planifiées : le scraping concurrentiel (horaire par défaut) et la purge du journal (quotidienne).
### Menu d'administration
Un nouveau menu **Dynamic Pricing** apparaît dans la barre latérale avec 7 sous-menus : Tableau de bord, Règles, Segments, Concurrents, A/B Testing, Journal, Réglages. Toutes les actions requièrent la capacité WordPress `manage_woocommerce`.
## Configuration initiale (Réglages)
Avant de créer votre première règle, faites un tour rapide dans **Dynamic Pricing → Réglages** pour ajuster les paramètres globaux.
### Journal
- **Activer le journal** : coché par défaut. Chaque ajustement est enregistré avec produit, règle, client, contexte.
- **Rétention (jours)** : 60 jours par défaut. La purge automatique tourne quotidiennement.
Le journal est rate-limité à 1 entrée par session, produit et heure pour éviter le flood. Vous pouvez le désactiver complètement si vous ne l'utilisez pas.
### Garde-fous globaux
- **Prix plancher (% du prix initial)** : par exemple, 70 = ne jamais descendre sous 70 % du prix initial. 0 = désactivé.
- **Prix plafond (% du prix initial)** : par exemple, 130 = ne jamais dépasser 130 %. 0 = désactivé.
- **Ne jamais vendre sous le coût d'achat** : à activer si vous stockez le coût dans un meta produit.
- **Clé meta du coût d'achat** : `_cost` par défaut (compatible WooCommerce Cost of Goods).
### Scraper concurrents
- **Fréquence d'exécution** : horaire, deux fois par jour ou quotidienne. Le scraper traite 25 URLs par batch.
### Affichage front-office
- **Afficher le prix initial barré** : utile pour un effet promo visible. À désactiver pour des tests A/B confidentiels.
## Créer votre première règle
Rendez-vous dans **Dynamic Pricing → Règles → Ajouter**. Chaque règle possède les mêmes champs de base, quel que soit son type.
### Champs communs
- **Nom** : libellé interne, utile dans le journal (ex : « Happy hour 18h-20h »).
- **Type** : Heure, Stock, Segment client, ou Concurrent.
- **Statut** : Actif ou Inactif. Une règle inactive n'est jamais évaluée.
- **Priorité** : les règles s'exécutent dans l'ordre croissant de priorité. Chaque règle travaille sur le résultat de la précédente.
- **Portée** : Global, Catégorie, Étiquette, ou Produit spécifique.
- **Ajustement** : Pourcentage, Montant fixe, Valeur définie, ou Match concurrent (uniquement avec le type Concurrent).
- **Plancher / Plafond** : garde-fous optionnels au niveau de la règle.
- **Fenêtre de dates** : dates de début et de fin pour rendre la règle active uniquement pendant une période donnée.
- **A/B Test** : lien optionnel vers un test A/B et sa variante (voir section A/B Testing).
**Conseil de priorisation :** commencez par les règles les plus larges (globales) à faible priorité, puis affinez avec des règles ciblées à priorité plus élevée. Les garde-fous globaux configurés dans Réglages s'appliquent toujours en dernier.
## Type 1 — Règle par heure
Ajuste le prix selon l'heure et le jour de la semaine. Idéal pour l'effet happy hour, les promotions week-end, ou les tarifs de nuit.
### Conditions disponibles
- **Jours de la semaine** : sélectionnez un ou plusieurs jours (lundi à dimanche, format ISO).
- **Heure de début / Heure de fin** : au format 24h. Les plages qui chevauchent minuit sont gérées automatiquement (ex : 22h-02h).
- **Fuseau horaire** : _site_ (par défaut, utilise le fuseau WordPress) ou un fuseau spécifique (ex : `Europe/Paris`).
### Exemples concrets
- **Happy hour** : −15 %, jeudi-vendredi, 18h-20h, fuseau Europe/Paris.
- **Weekend promo** : −10 %, samedi-dimanche, 00h-23h59.
- **Prix de nuit** : +5 %, tous les jours, 22h-06h (chevauche minuit, géré automatiquement).
## Type 2 — Règle par stock
Ajuste le prix selon le niveau de stock du produit. Utile pour déstocker rapidement les produits en surstock ou valoriser ceux devenant rares.
### Conditions disponibles
- **Opérateur** : <, <=, ==, >=, >.
- **Seuil** : nombre entier.
- **Mode** : _Absolu_ (nombre d'unités) ou _Pourcentage du stock initial_ (nécessite le meta `_initial_stock` défini sur le produit).
### Exemples concrets
- **Déstockage** : stock >= 50 (surstock) → −20 %.
- **Rareté** : stock < 5 → +10 %.
- **Stock initial pourcentage** : mode pourcentage, stock < 20 % du stock initial → −5 %.
Pour utiliser le mode Pourcentage, ajoutez un champ meta `_initial_stock` à vos produits (via WP All Import, ACF, ou un simple `update_post_meta`). Sans ce meta, le mode pourcentage est ignoré.
## Type 3 — Règle par segment client
Applique un ajustement uniquement aux clients appartenant à un ou plusieurs segments définis.
### Conditions disponibles
- **Segments** : un ou plusieurs segments existants (voir section Segments).
- **Correspondance** : _Any_ (le client appartient à au moins un segment) ou _All_ (il appartient à tous).
### Exemples concrets
- **Fidélité** : segment _loyal-customers_, ajustement −10 %.
- **Reconquête** : segment _dormant_ (à créer), ajustement −20 % pendant 7 jours.
- **B2B** : segment _b2b_ (rôle `wholesale`), ajustement −25 %.
## Type 4 — Règle par prix concurrent
Aligne votre prix sur celui d'un concurrent que vous avez configuré dans la section Concurrents. Trois stratégies disponibles.
### Stratégies
- **Match** : votre prix devient exactement le prix du concurrent.
- **Undercut** : votre prix passe sous celui du concurrent, en pourcentage ou en montant fixe.
- **Overprice** : votre prix passe au-dessus du concurrent (positionnement premium).
### Conditions disponibles
- **Mode** : _Pourcentage_ ou _Montant fixe_.
- **Montant** : pourcentage (ex : 5 pour 5 %) ou montant en devise.
- **Âge maximum des données (heures)** : au-delà, les données du scraping sont considérées trop anciennes et la règle bascule sur le comportement de fallback.
- **Fallback** : comportement si les données concurrent sont indisponibles (par exemple, appliquer un ajustement neutre ou skipper la règle).
### Exemple concret
Undercut de 3 % du concurrent A, avec âge max de 6 heures. Si le concurrent A n'a pas été scrapé depuis 6 heures, la règle est ignorée et le prix reste inchangé.
## Segments clients
Un segment est une combinaison de critères qui définit un groupe de clients. Une fois créé, un segment peut être ciblé par une règle de type _Segment client_.
### Segments seedés à l'activation
- **new-customers** : clients avec 0 ou 1 commande.
- **loyal-customers** : clients avec 5 commandes ou plus.
- **vip** : clients ayant dépensé au moins 500 €.
### Créer un segment
Depuis **Dynamic Pricing → Segments → Ajouter**, définissez :
- **Nom** et **Slug** (auto-généré si vide).
- **Description** (optionnelle, pour votre équipe).
- **Critères** : ajoutez autant de lignes que nécessaire. Tous les critères doivent être satisfaits (ET logique).
- **Statut** : actif ou inactif.
### Champs disponibles pour les critères
- `order_count` — nombre de commandes du client.
- `total_spent` — total dépensé (dans la devise du site).
- `is_guest` — 1 si le visiteur n'est pas connecté, 0 sinon.
- `user_roles` — rôles WordPress du client (ex : `customer`, `subscriber`, `wholesale`).
- `days_since_last_order` — jours écoulés depuis la dernière commande.
### Opérateurs disponibles
Dix opérateurs : `==`, `!=`, `>`, `>=`, `= 60`. Cible les anciens clients qui n'ont pas commandé depuis 2 mois.
## Concurrents (scraping)
Le scraper récupère automatiquement le prix affiché sur une page produit d'un concurrent, selon une fréquence configurable. Les prix récupérés sont ensuite utilisés par les règles de type _Concurrent_.
### Ajouter un concurrent
Depuis **Dynamic Pricing → Concurrents → Ajouter** :
1. **Produit WooCommerce (ID)** : l'ID du produit local auquel rattacher le suivi.
2. **Nom du concurrent** : libellé libre (ex : « Amazon », « Fnac »).
3. **URL** : la page produit du concurrent à scraper.
4. **Type de sélecteur** : CSS, XPath, Regex, ou JSON-LD.
5. **Sélecteur** : le sélecteur qui pointe vers le prix (voir exemples ci-dessous).
6. **Devise** : par défaut la devise WooCommerce du site.
7. **Statut** : suivi actif ou en pause.
### Types de sélecteurs
- **CSS** : sélecteur CSS classique. Exemples : `.price .amount`, `#product-price`, `span[itemprop=price]`.
- **XPath** : expression XPath. Exemple : `//span[@class="price"]`.
- **Regex** : expression régulière PHP. Exemple : `/€s*([d,.]+)/` — le premier groupe capturé est utilisé.
- **JSON-LD** : auto-détection Schema.org. Cherche `price`, `offers.price`, `offers.lowPrice` dans les balises JSON-LD. Laissez le champ Sélecteur vide.
### Parsing des prix
Le scraper gère les formats européens (`1 299,90`) et américains (`1,299.90`) automatiquement. Les symboles de devise et espaces sont nettoyés.
### Exécution manuelle
Le bouton **Scraper maintenant** à côté de chaque concurrent force une mise à jour immédiate en AJAX. Utile pour tester un nouveau sélecteur.
### Statuts possibles
- **pending** — jamais scrapé, en attente du prochain cron.
- **ok** — dernière exécution réussie.
- **error** — dernière exécution en échec (message stocké dans le champ _last_error_).
**Respect des CGU des concurrents :** le scraper effectue une requête HTTP simple avec un timeout court, mais il vous appartient de vérifier que le scraping est autorisé par les Conditions Générales d'Utilisation des sites cibles. Certaines juridictions encadrent cette pratique.
## A/B Testing
Le module A/B intégré permet de comparer plusieurs stratégies de prix sur un même produit et de mesurer leur impact en temps réel (expositions, ajouts panier, conversions, RPV).
### Créer un test
Depuis **Dynamic Pricing → A/B Testing → Nouveau test** :
1. **Nom** et **slug**.
2. **Variantes** : liste de libellés séparés par des virgules. Par défaut `A,B`.
3. **Répartition du trafic** : poids relatif par variante (normalisé automatiquement). Par exemple `50/50`, `70/30`, ou `1/1/1` pour trois variantes équi-réparties.
4. **Statut** : Brouillon, En cours, En pause, ou Terminé. Seul un test _En cours_ assigne des visiteurs.
5. **Fenêtre** : dates optionnelles de début et de fin.
### Lier une règle à une variante
Dans le formulaire d'une règle, sélectionnez le test A/B et la variante ciblée. La règle ne s'appliquera qu'aux visiteurs assignés à cette variante précise.
### Comment fonctionne l'assignation
À la première exposition, le plugin attribue le visiteur à une variante selon les poids configurés, puis stocke ce choix dans un cookie `dfdpe_ab`. Un cookie de session distinct `dfdpe_sid` permet de suivre le même visiteur sur l'ensemble de sa session, connecté ou non.
### Événements suivis
- **exposure** — première fois que le visiteur voit un prix affecté par le test.
- **atc** — ajout au panier (hook `woocommerce_add_to_cart`).
- **conversion** — commande finalisée (hook `woocommerce_thankyou`). Le montant total de la commande est enregistré.
### Métriques calculées (page Résultats)
- **Expositions** et **Sessions uniques**.
- **CR ATC** — taux d'ajout au panier (ATC / expositions).
- **CR Conv.** — taux de conversion (conversions / expositions).
- **Revenu** — total des conversions.
- **RPV** — revenu par visiteur (revenu / expositions). C'est la métrique clé de décision : la variante avec le RPV le plus élevé est mise en avant automatiquement (badge _Gagnant_).
**Bonne pratique :** laissez tourner un test au moins 2 semaines avant de conclure. Un test A/B fiable nécessite plusieurs milliers d'expositions pour dégager une significativité statistique.
## Journal des ajustements
Chaque ajustement de prix appliqué au front-office peut être loggué. Le journal est accessible via **Dynamic Pricing → Journal**.
### Informations enregistrées
- Date et heure.
- Produit et variation.
- Règle déclenchée (ID).
- Client (ID) ou session anonyme.
- Prix initial, prix final, montant de l'ajustement.
- Test A/B et variante (le cas échéant).
- Contexte : `frontend`, `cart`, `checkout`.
### Filtres disponibles
Vous pouvez filtrer par ID de produit, ID de règle, ou ID de test A/B. La pagination affiche 50 entrées par page.
### Rate-limiting
Pour éviter le flood, le plugin limite l'enregistrement à 1 entrée par session, produit et heure. Une session qui consulte 100 fois la même fiche produit dans l'heure ne génère qu'une seule ligne.
### Purge automatique
Une tâche cron quotidienne (`dfdpe_cron_purge_logs`) supprime les entrées plus anciennes que la rétention configurée (60 jours par défaut).
## Garde-fous : comment ça marche
Trois niveaux de protection successifs empêchent votre prix final d'atteindre un niveau dangereux.
### Niveau 1 — Garde-fous par règle
Chaque règle peut définir son propre plancher et plafond. Ils s'appliquent immédiatement après l'ajustement de cette règle. Utile pour capper les effets d'une règle particulière (ex : « la happy hour ne peut jamais descendre sous 30 €, quel que soit le prix initial »).
### Niveau 2 — Garde-fous globaux
Définis dans Réglages, en pourcentage du prix initial :
- **Prix plancher** : le prix final ne peut pas descendre sous ce pourcentage.
- **Prix plafond** : le prix final ne peut pas dépasser ce pourcentage.
Exemple : plancher à 70 % et plafond à 130 %. Un produit à 100 € ne pourra jamais descendre sous 70 € ni dépasser 130 €, quelles que soient les règles appliquées.
### Niveau 3 — Protection coût d'achat
Si activée dans Réglages, cette protection empêche le prix final de descendre sous la valeur du meta `_cost` (ou de la clé personnalisée que vous configurez). C'est la garantie ultime pour ne jamais vendre à perte.
Les trois niveaux sont cumulatifs et s'appliquent dans cet ordre : règle → global → coût. Le prix final est toujours le résultat le plus « protégé » des trois.
## Compatibilité HPOS et cache
### HPOS (High-Performance Order Storage)
Le plugin déclare la compatibilité avec `custom_order_tables` et `cart_checkout_blocks` dès l'initialisation. Aucune action supplémentaire n'est requise si vous avez activé HPOS dans WooCommerce.
### Cache des prix de variations
WooCommerce met en cache les prix minimum et maximum des produits variables via un hash. Le plugin injecte un seed dynamique (utilisateur + session + bucket de 5 minutes) dans ce hash via le filtre `woocommerce_get_variation_prices_hash`, ce qui force WooCommerce à recalculer les prix au bon moment sans casser le cache pour les autres visiteurs.
## FAQ
### Puis-je combiner plusieurs règles sur le même produit ?
Oui. Les règles s'exécutent dans l'ordre de priorité, chacune travaillant sur le résultat de la précédente. Vous pouvez ainsi enchaîner « −10 % VIP » puis « plafond à 130 % du coût ».
### Les règles s'appliquent-elles aussi au panier et au checkout ?
Oui. Un hook sur `woocommerce_before_calculate_totals` recalcule les prix des lignes de panier à chaque affichage.
### Le plugin est-il compatible avec les caches serveur (Redis, Varnish) ?
Oui, mais si votre cache est très agressif au niveau de la page complète, les prix affichés peuvent être ceux mis en cache. Pour un affichage dynamique fiable, excluez les pages produit du cache full-page, ou utilisez des fragments ESI.
### Puis-je désactiver le plugin sans perdre mes règles ?
Oui. La désactivation ne supprime aucune donnée. Seule la désinstallation via _Extensions → Supprimer_ déclenche le script `uninstall.php`.
### Comment exporter mes données ?
Toutes les données sont stockées dans les 6 tables `wp_dfdpe_*`. Vous pouvez les exporter via phpMyAdmin, WP-CLI (`wp db export`), ou n'importe quel outil de sauvegarde WordPress.
## Désinstallation
Pour désinstaller complètement :
1. Désactivez le plugin depuis **Extensions**.
2. Cliquez sur _Supprimer_.
Le script `uninstall.php` supprime alors :
- Les 6 tables `wp_dfdpe_*`.
- Les 9 options WordPress créées.
- Les tâches cron planifiées.
La désinstallation est définitive et non-réversible. Sauvegardez vos règles, segments et journal avant si vous souhaitez pouvoir revenir en arrière.
## Support
Votre licence inclut 12 mois de support et de mises à jour. Pour toute question, contactez-nous via [datafirefly.com/contact](https://www.datafirefly.com/contact/).
---
### E-reporting & Plateforme Agréée (PDP) — Documentation
_Source :_
> Ce module transmet à l'administration fiscale les données de vos transactions B2C (e-reporting) ainsi que le cycle de vie de vos factures, dans le cadre de la réforme française de…
Ce module transmet à l'administration fiscale les données de vos transactions B2C (e-reporting) ainsi que le cycle de vie de vos factures, dans le cadre de la réforme française de la facturation électronique. Il génère le flux au format attendu par la DGFiP (sémantique CII, flux 10, en XML et JSON) et le dépose sur votre Plateforme Agréée (PDP) ou vous permet de le déposer manuellement. Ce guide couvre l'installation, la configuration et l'utilisation quotidienne.
**Rappel réglementaire.** À partir du 1er septembre 2026, la réception des factures électroniques est obligatoire pour toutes les entreprises, et l'émission ainsi que l'e-reporting le deviennent pour les grandes entreprises et les ETI. Les PME, TPE et micro-entreprises suivent au 1er septembre 2027. Chaque transmission d'e-reporting manquante est passible d'une amende de 250 € (plafond 45 000 €/an).
## Prérequis
- PrestaShop 8.0 à 9.x, PHP 7.4 à 8.3.
- Votre numéro SIREN (9 chiffres).
- La connaissance de votre régime de TVA (réel normal, réel simplifié, ou franchise en base).
- Pour le dépôt automatique : les informations de connexion fournies par votre Plateforme Agréée (URL de dépôt, URL de statut, identifiants OAuth2 ou clé API). Ces informations ne sont pas nécessaires en mode manuel.
## Installation
1. Dans le back-office, ouvrez **Modules > Module Manager**, cliquez sur **Téléverser un module** et sélectionnez le fichier ZIP.
2. Une fois l'installation terminée, cliquez sur **Configurer**. Le module crée automatiquement ses tables et un onglet **E-reporting** sous **Commandes**.
3. Rendez-vous dans l'onglet **Réglages** pour la configuration initiale.
## Configuration initiale
Tous les réglages se trouvent dans l'onglet **Réglages** de la page de configuration du module.
### Identité et régime
- **SIREN** : votre numéro à 9 chiffres. Il identifie la partie vendeur dans chaque flux transmis.
- **Régime de TVA** : détermine la périodicité de vos transmissions. Réel normal = décadaire, réel simplifié = mensuel, franchise en base = bimestriel.
- **Type d'activité** : biens, services ou mixte. Les activités de services et mixtes déclenchent le suivi des encaissements, car la TVA y est exigible à l'encaissement.
- **Date de début** : première date à partir de laquelle le module collecte les transactions. Fixez-la au plus tôt à votre date d'entrée dans l'obligation.
### Options de collecte
- **Inclure les ventes intracommunautaires B2B** : ajoute au flux les ventes à des professionnels d'un autre État membre de l'UE, elles aussi soumises à e-reporting.
- **Inclure les avoirs** : intègre les avoirs (order slips) au flux en montants négatifs.
## Choix du mode de dépôt
Le réglage **Mode PDP** détermine comment les flux sont transmis.
### Mode manuel
Le module génère les flux ; vous les téléchargez en XML ou JSON et les déposez vous-même sur le portail de votre plateforme, puis vous marquez la transmission comme déposée. C'est le mode recommandé si votre plateforme n'expose pas encore d'API, ou si vous préférez garder le contrôle.
### Mode API
Le module dépose automatiquement les flux sur votre plateforme. Renseignez :
- **URL de dépôt** et **URL de statut** fournies par votre plateforme.
- **Mode d'authentification** : OAuth2 (client credentials), clé API, ou Bearer statique.
- Selon le mode : **URL du token**, **Client ID** et **Client Secret** pour OAuth2 ; ou **Clé API** ; ou jeton Bearer.
- **Format de payload** : XML ou JSON, selon ce qu'attend l'API de votre plateforme.
Utilisez le bouton **Tester la connexion PDP** pour valider vos identifiants avant la mise en production.
**Le secret est conservé.** Lorsque vous enregistrez les réglages en laissant le champ Client Secret ou Clé API vide, la valeur précédemment enregistrée est conservée. Vous n'avez donc pas besoin de resaisir le secret à chaque modification.
## Générer et transmettre une période
### Depuis le tableau de bord
L'onglet **Tableau de bord** affiche les périodes dues, chacune avec sa date limite légale. Une période en retard est signalée en rouge. Cliquez sur **Générer** en face d'une période pour produire son flux. Le bouton **Tout générer** traite en une fois toutes les périodes échues.
### Depuis l'onglet Transmissions
L'onglet **Transmissions** liste tous les flux générés avec leur statut. Pour chaque transmission vous pouvez :
- Consulter le détail de la ventilation par taux de TVA.
- Télécharger le flux en XML ou JSON.
- En mode API, cliquer sur **Envoyer à la PDP**.
- En mode manuel, marquer la transmission comme **déposée**, puis **acceptée** ou **rejetée** selon le retour de la plateforme.
- Supprimer une transmission tant qu'elle n'a pas été soumise.
**Statuts d'une transmission.** Une transmission passe par les états brouillon, généré, soumis, accepté, rejeté ou erreur. Une transmission déjà soumise ou acceptée ne peut plus être supprimée, afin de préserver votre piste d'audit.
## Périodicité selon le régime
Le module calcule automatiquement les périodes en fonction du régime configuré, conformément au décret 2022-1299 :
- **Réel normal — décadaire** : trois périodes par mois (du 1 au 10, du 11 au 20, du 21 à la fin du mois). Chaque flux doit être déposé dans les 10 jours suivant la fin de la période.
- **Réel simplifié — mensuel** : une transmission par mois, à déposer entre le 25 et le 30 du mois suivant.
- **Franchise en base — bimestriel** : une transmission tous les deux mois.
## Comment les montants sont calculés
Le module reconstitue la ventilation par taux de TVA à partir des lignes de commande réelles. Il ajoute les frais de port au taux du transporteur, intègre l'emballage cadeau, et replie les écarts d'arrondi et les remises sur le plus gros poste afin que les totaux transmis correspondent exactement aux totaux de vos commandes. Les commandes en devise étrangère sont converties au taux enregistré au moment de la vente. Les avoirs, s'ils sont activés, sont intégrés en montants négatifs et alloués proportionnellement sur les taux de la commande d'origine.
## Cycle de vie des factures
L'onglet **Cycle de vie** permet de suivre les statuts de vos factures : dépôt, rejet, refus et encaissement. Les encaissements sont détectés automatiquement à partir des paiements PrestaShop, et le passage d'une commande à un état « payé » enregistre le statut encaissé. Vous pouvez également saisir un statut manuellement pour une commande donnée. Chaque fiche commande du back-office affiche par ailleurs un panneau récapitulant son statut e-reporting.
## Automatisation par cron
L'onglet **Tableau de bord** affiche une URL de cron sécurisée par un jeton. Configurez une tâche planifiée (cron) chez votre hébergeur pour appeler cette URL, par exemple une fois par jour. À chaque appel, le module génère toutes les périodes échues et, si l'option **Soumission automatique** est activée en mode API, dépose les flux sur votre plateforme.
**Gardez l'URL de cron confidentielle.** Elle contient un jeton qui autorise la génération et la soumission des flux. Ne la partagez pas publiquement. Si vous pensez qu'elle a été exposée, régénérez le jeton dans les réglages.
## Mode test
Activez le **Mode test** pour valider toute la chaîne sans effet réel. Chaque flux transmis dans ce mode porte l'indicateur de test prévu par le format officiel : votre plateforme le traite comme un essai. Un bandeau **MODE TEST** reste visible dans l'interface tant que l'option est active. Désactivez-la avant la première transmission réelle.
## Foire aux questions
### Suis-je concerné si je ne vends qu'à des particuliers ?
Oui. Les ventes B2C relèvent précisément de l'e-reporting : leurs données de transactions doivent être transmises périodiquement, même si aucune facture électronique n'est émise.
### Le module fonctionne-t-il avec ma Plateforme Agréée ?
Le client API est générique et compatible avec toute plateforme exposant une API REST avec authentification OAuth2, clé API ou Bearer. Si votre plateforme n'a pas d'API, le mode manuel reste disponible.
### Est-il compatible avec le module Factur-X DataFirefly ?
Oui. Les deux modules sont complémentaires : Factur-X couvre la facturation électronique B2B, ce module couvre l'e-reporting des transactions B2C et le cycle de vie des factures. Ils peuvent être utilisés ensemble sans conflit.
### Que se passe-t-il si j'installe le module en cours d'année ?
Réglez la **Date de début** sur la date à partir de laquelle vous êtes soumis à l'obligation. Le module ne génère de périodes qu'à partir de cette date.
---
### EAA Accessibility Auto-Fixer — Guide complet
_Source :_
> Présentation EAA Accessibility Auto-Fixer met votre site WordPress et WooCommerce en conformité avec l'European Accessibility Act (directive UE 2019/882, applicable depuis le 28 juin 2025). Le plugin combine quatre briques…
## Présentation
EAA Accessibility Auto-Fixer met votre site WordPress et WooCommerce en conformité avec l'European Accessibility Act (directive UE 2019/882, applicable depuis le 28 juin 2025). Le plugin combine quatre briques : un scanner WCAG 2.2 niveau AA, un correcteur frontend automatique, un générateur de textes alternatifs par IA (Anthropic Claude) et un générateur de déclaration légale d'accessibilité.
**Qui est concerné ?** Les e-commerces de l'UE avec plus de 10 salariés OU plus de 2 M€ de chiffre d'affaires annuel. Les micro-entreprises sont exemptées pour les services mais doivent rendre leurs produits accessibles.
## Installation
1. Téléchargez le ZIP depuis votre compte DataFirefly.
2. Dans WordPress, allez dans **Extensions → Ajouter → Téléverser une extension**, sélectionnez le ZIP puis cliquez sur **Installer maintenant**.
3. Cliquez sur **Activer**. Le plugin crée automatiquement 4 tables (`wp_eaa_audits`, `wp_eaa_issues`, `wp_eaa_fixes`, `wp_eaa_alt_cache`), programme un audit hebdomadaire et génère une page « Déclaration d'accessibilité » contenant le shortcode `[eaa_accessibility_declaration]`.
Prérequis : WordPress 6.2+, WooCommerce 8.0+ (facultatif — le plugin fonctionne aussi sur WordPress seul), PHP 8.1+.
## Premier audit
1. Allez dans **EAA Accessibility → Audit**.
2. L'URL de la page d'accueil est pré-remplie ; vous pouvez la remplacer par n'importe quelle URL du site.
3. Cliquez sur **Lancer l'audit**. Le scanner analyse la page et affiche le score sur 100, la liste des anomalies (sévérité, règle, critère WCAG, extrait HTML, suggestion) et un bouton **Corriger** pour les anomalies auto-corrigeables.
### Comprendre le score
Le score démarre à 100 et chaque anomalie retire des points selon sa sévérité : critique 15 points, sérieuse 8, modérée 3, mineure 1. Un score de 90 ou plus s'affiche en vert, de 70 à 89 en orange, en dessous en rouge. La déclaration légale reprend ce score : 90+ donne « Totalement conforme », 50 à 89 « Partiellement conforme », moins de 50 « Non conforme ».
### Les 15 règles vérifiées
- **html-lang** — attribut lang sur l'élément racine (WCAG 3.1.1)
- **page-title** — présence et contenu de la balise title (2.4.2)
- **headings** — présence d'un h1 unique et hiérarchie sans saut (1.3.1)
- **image-alt** — attribut alt sur toutes les images (1.1.1)
- **link-name** — texte accessible sur chaque lien (2.4.4)
- **button-name** — nom accessible sur chaque bouton (4.1.2)
- **label** — étiquette sur chaque champ de formulaire (1.3.1, 4.1.2)
- **skip-link** — lien d'évitement en début de page (2.4.1)
- **landmarks** — repère main présent (1.3.1)
- **duplicate-id** — pas d'identifiant en double (4.1.1)
- **aria-roles** — rôles ARIA valides (4.1.2)
- **target-size** — cibles tactiles de 24×24 px minimum (2.5.8, nouveauté WCAG 2.2)
- **color-contrast** — contraste texte/fond de 4,5:1 minimum (1.4.3)
- **tabindex** — pas de tabindex positif (2.4.3)
- **autoplay** — pas de lecture automatique non contrôlable (1.4.2)
## Corrections automatiques
Dans **EAA Accessibility → Réglages → Corrections actives**, activez les corrections que le plugin applique en temps réel via output buffer, sans modifier votre thème :
- **Attribut lang** — ajoute la langue du site sur l'élément racine si absente.
- **Lien d'évitement** — insère « Aller au contenu » en tête de page, visible au focus clavier.
- **Texte alternatif manquant** — marque les images décoratives (classes decoration, icon…) avec un alt vide ; les images de contenu passent par l'IA si activée.
- **Étiquettes de formulaire** — ajoute un aria-label déduit du placeholder ou du name sur les champs sans label.
- **Rôles ARIA et icônes** — aria-label sur les boutons-icônes, role="presentation" sur les SVG décoratifs.
- **Indicateur de focus** — injecte un style :focus-visible contrasté.
- **Contrastes** — corrige les couleurs inline sous 4,5:1 en assombrissant ou éclaircissant automatiquement.
- **Taille des cibles** — garantit 24×24 px sur boutons et liens via CSS.
Chaque correction est journalisée dans la table `wp_eaa_fixes` avec la valeur avant/après — utile en cas de contrôle. Consultez le total par type dans le Tableau de bord.
Si une correction entre en conflit avec votre thème (par exemple un skip-link déjà présent), désactivez la correction concernée : le plugin détecte les éléments existants mais certains thèmes très personnalisés peuvent nécessiter un ajustement.
## Génération IA des textes alternatifs
### Configuration
1. Créez une clé API sur [console.anthropic.com](https://console.anthropic.com/).
2. Dans **EAA Accessibility → Réglages → Génération IA**, cochez **Activer l'IA**, collez la clé, puis cliquez sur **Tester la connexion**.
3. Choisissez le modèle : **Claude Haiku 4.5** (par défaut, environ 0,0001 € par image, recommandé), **Sonnet 4.6** (qualité supérieure) ou **Opus 4.7** (qualité maximale).
### Génération en masse
Depuis le Tableau de bord, le bouton de génération en masse traite la médiathèque par lots de 5 images. Chaque description est générée dans la langue de l'attachement (FR/EN/ES/DE/IT), stockée dans `wp_eaa_alt_cache` et écrite dans le champ alt de WordPress. Le cache évite toute re-génération : une image déjà décrite dans une langue n'est jamais renvoyée à l'API.
Les images de plus de 4 Mo sont automatiquement redimensionnées à 1024 px maximum avant envoi à l'API — aucun impact sur vos fichiers originaux.
## Widget visiteur
Activez-le dans **Réglages → Widget visiteur**. Un bouton flottant ♿ apparaît en bas à droite du site et ouvre un panneau avec 8 préférences : taille du texte (5 paliers, de 100 % à 200 %), contraste élevé, police adaptée à la dyslexie, espacement amélioré, animations réduites, soulignement des liens, curseur agrandi, et un bouton de réinitialisation. Les choix sont enregistrés en localStorage (aucun cookie, aucune donnée envoyée au serveur) et restaurés à chaque visite. Le panneau est entièrement navigable au clavier et se ferme avec Échap.
## Déclaration légale
La page créée à l'activation affiche via le shortcode `[eaa_accessibility_declaration]` : l'état de conformité calculé sur le dernier audit, le score, la date, les contenus non accessibles, la méthodologie et vos coordonnées de contact. Renseignez ces informations dans **Réglages → Informations pour la déclaration légale** : raison sociale, e-mail de contact accessibilité, téléphone, adresse postale.
**Complément manuel recommandé.** Ajoutez vos identifiants légaux (SIRET, RCS ou équivalent) et faites valider la déclaration par un expert en accessibilité : le plugin couvre 30 à 40 % des critères automatisables, une revue humaine reste nécessaire pour la conformité totale.
Ajoutez ensuite un lien vers cette page dans votre pied de page — c'est une exigence de l'EAA.
## Audits programmés
Dans **Réglages → Audit programmé**, choisissez la fréquence : quotidien, hebdomadaire (par défaut) ou mensuel. Le cron WordPress scanne alors la page d'accueil automatiquement et alimente l'historique. Consultez tous les audits passés dans **EAA Accessibility → Historique** avec score, durée et répartition des anomalies par sévérité.
## Désinstallation
Par défaut, la désinstallation conserve les tables et l'historique (traçabilité légale). Pour tout supprimer, activez l'option de suppression des données dans les réglages avant de désinstaller : les 4 tables, les options et la page de déclaration seront alors retirées.
## Dépannage
### Le scanner retourne une erreur de connexion
Le scanner utilise `wp_remote_get` pour récupérer la page. Vérifiez que votre serveur peut s'appeler lui-même (loopback) : certains hébergeurs bloquent les requêtes sortantes vers le propre domaine du site. Testez avec **Outils → Santé du site**.
### Le test de la clé API échoue
Vérifiez que la clé commence par `sk-ant-`, que votre compte Anthropic a du crédit, et que le serveur autorise les connexions sortantes vers `api.anthropic.com` en HTTPS.
### Les corrections ne s'appliquent pas
Le correcteur est inactif sur les flux RSS, les requêtes REST/AJAX, l'administration et le cron. Si un plugin de cache sert une version statique, videz le cache après activation. Vérifiez aussi que **Activer le correcteur frontend** est bien coché.
### Le widget n'apparaît pas
Vérifiez que **Widget visiteur** est activé dans les réglages et que votre thème appelle bien `wp_footer()` — le widget s'injecte sur ce hook.
---
### Éditeur robots.txt — Guide d'installation et d'utilisation
_Source :_
> Guide complet du module Éditeur robots.txt : installation, édition, validation, régénération, modèles de blocage des robots d'IA et restauration de sauvegarde.
L'**Éditeur robots.txt** de DataFirefly vous permet de modifier, valider, régénérer et sauvegarder le fichier `robots.txt` de votre boutique directement depuis le back-office PrestaShop, sans accès FTP ni SSH. Ce guide couvre l'installation et l'ensemble des fonctionnalités.
## Compatibilité
- PrestaShop 8.0 à 9.x
- PHP 7.4 à 8.x
- Multiboutique
- Interface en français
## Installation
1. Téléchargez l'archive `dfrobotseditor.zip`.
2. Dans le back-office, ouvrez **Modules → Gestionnaire de modules**.
3. Cliquez sur **Installer un module** et déposez le ZIP (ou copiez le dossier `dfrobotseditor` dans `/modules/` puis installez-le depuis la liste).
4. Une fois installé, cliquez sur **Configurer** : l'éditeur s'ouvre directement.
À l'installation, aucun fichier `robots.txt` n'est modifié. Le module se contente d'ouvrir un éditeur ; chaque enregistrement reste sous votre contrôle.
## Accéder à l'éditeur
Deux accès possibles :
- Via le bouton **Configurer** du module (recommandé).
- Via le menu **Modules → Éditeur robots.txt** dans le back-office.
L'écran principal affiche le chemin du fichier, son état d'écriture, un lien « Voir en ligne » et, le cas échéant, la date de la dernière sauvegarde.
## Modifier et enregistrer
Le contenu du fichier s'affiche dans un éditeur monospace. Modifiez-le librement, puis cliquez sur **Enregistrer**. À chaque enregistrement :
- la version précédente est automatiquement sauvegardée ;
- les fins de ligne sont normalisées ;
- le contenu est plafonné à 64 Ko.
## Régénérer le fichier par défaut
Le bouton **Régénérer (défaut)** reconstruit un `robots.txt` standard. Le module utilise les règles natives de PrestaShop lorsqu'elles sont disponibles, sinon un modèle DataFirefly équivalent. La version actuelle est sauvegardée avant remplacement.
La régénération écrit immédiatement le fichier. Une sauvegarde est créée au préalable : vous pouvez revenir en arrière via **Restaurer la sauvegarde**.
## Valider la syntaxe
Le bouton **Valider la syntaxe** analyse le contenu de l'éditeur et liste les anomalies, classées par gravité :
- **Erreur** : Sitemap non absolu, règle placée avant tout `User-agent`, ligne mal formée.
- **Avertissement** : directive inconnue, présence d'un BOM, directive `Noindex` obsolète, `Crawl-delay` non numérique.
- **Info** : fichier vide (tous les robots sont autorisés).
La validation ne modifie pas le fichier : elle vous aide à corriger avant d'enregistrer.
## Modèles rapides
Le menu **Insérer un modèle** ajoute du contenu prêt à l'emploi à l'endroit du curseur :
- **Ligne Sitemap** : insère l'URL absolue de votre sitemap.
- **Bloquer les robots d'IA** : insère un bloc bloquant GPTBot, ClaudeBot, CCBot, Google-Extended, PerplexityBot, Bytespider et d'autres.
- **Tout autoriser** / **Tout bloquer**.
Exemple de bloc de blocage des robots d'IA :
```
# Blocage des robots d'IA — DataFirefly
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: CCBot
Disallow: /
```
Google-Extended concerne l'entraînement des IA de Google, pas l'indexation Google Search. Ajustez la liste selon votre stratégie de référencement et d'AEO.
## Restaurer une sauvegarde
Chaque enregistrement ou régénération crée une sauvegarde de la version précédente, stockée en base de données (donc **jamais accessible publiquement**). Le bouton **Restaurer la sauvegarde** réécrit instantanément cette version dans le fichier.
## Permissions et dépannage
Le fichier `robots.txt` doit être accessible en écriture par le serveur web. Si ce n'est pas le cas, le module affiche un avertissement et désactive l'enregistrement.
```
chmod 644 /chemin/vers/robots.txt
# si le fichier n'existe pas encore :
chmod 755 /chemin/vers/racine/
```
- **« Lecture seule »** : appliquez les permissions ci-dessus, ou ajustez le propriétaire du fichier (utilisateur du serveur web).
- **Le fichier n'apparaît pas en ligne** : vérifiez qu'aucune règle serveur ou CDN ne sert un `robots.txt` statique différent.
## Multiboutique
`robots.txt` est un fichier unique servi à la racine de chaque domaine. En multiboutique mono-domaine, un seul fichier suffit. En multi-domaines, regroupez les sections par domaine dans ce même fichier.
## Désinstallation
La désinstallation du module supprime son onglet et sa sauvegarde en base. **Votre fichier robots.txt n'est pas modifié** : il reste tel que vous l'avez enregistré.
---
### Emballage Cadeau & Message — Guide complet
_Source :_
> Présentation Le module Emballage Cadeau & Message (dfgiftwrap) ajoute, dans le tunnel de commande, le choix d'un emballage cadeau payant et d'une carte message personnalisée. Le client sélectionne une option…
## Présentation
Le module **Emballage Cadeau & Message** (`dfgiftwrap`) ajoute, dans le tunnel de commande, le choix d'un **emballage cadeau payant** et d'une **carte message personnalisée**. Le client sélectionne une option d'emballage illustrée, peut y joindre un message libre, et les frais correspondants s'intègrent proprement au total de la commande — TVA, devise et multiboutique étant gérés par le cœur de PrestaShop, jusqu'à la facture.
Les frais ne sont pas un simple affichage : ils sont portés par un produit-frais dédié et un prix spécifique limité au panier du client. Le montant se retrouve donc naturellement dans les totaux, la commande et la facture, avec la bonne TVA.
## Compatibilité
- PrestaShop 8.0 à 9.x
- Mono-boutique et multiboutique
- PHP 7.4 à 8.3
- Thème Classic et thèmes personnalisés
- Interface livrée en français et entièrement traduisible
- Aucune dépendance (ni Composer ni framework)
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** puis sélectionnez le fichier `dfgiftwrap.zip`.
3. Une fois installé, cliquez sur **Configurer**.
À l'installation, le module crée ses tables, enregistre ses hooks (ressources front, bloc au checkout, validation de commande, fiche commande BO, confirmation) et génère un **produit-frais caché** (référence `DF-GIFTWRAP-FEE`) : virtuel, non visible en boutique, prix non affiché. C'est lui qui porte le montant emballage + carte dans le panier. Ne le supprimez pas manuellement.
## Configuration
### Réglages généraux
- **Activer l'emballage cadeau** : affiche ou masque le bloc des options d'emballage au checkout.
- **Activer la carte message** : affiche ou masque l'option carte + message.
- **Prix de la carte** : montant (hors taxe) facturé lorsque le client ajoute une carte message.
- **Longueur maximale du message** : nombre de caractères autorisés (200 par défaut). Un compteur accompagne le client pendant la saisie.
- **Groupe de règles de taxe** : groupe de TVA appliqué aux frais d'emballage et de carte.
### Gérer les options d'emballage
Depuis la page de configuration, cliquez sur **« Gérer les options »** pour ouvrir l'écran dédié (contrôleur `AdminDfGiftWrapOptions`). Vous y créez autant d'options que souhaité, chacune avec :
- **Nom** : libellé multilingue de l'option (ex. « Papier kraft élégant », « Coffret cadeau premium »).
- **Prix** : montant hors taxe de l'option d'emballage.
- **Image** : visuel illustrant l'option (normalisé automatiquement en JPG).
- **Position** : ordre d'affichage, modifiable par glisser-déposer.
- **Actif** : affiche ou masque l'option côté boutique sans la supprimer.
Le nom est un champ multilingue : sélectionnez chaque langue dans le sélecteur du champ pour traduire l'intitulé de l'option.
## Fonctionnement
### Au checkout
Le bloc d'emballage et de carte est injecté en haut du récapitulatif de commande via le hook `displayCheckoutSummaryTop`. Le client choisit une option d'emballage, active éventuellement la carte et saisit son message. La sélection est enregistrée en AJAX. Comme le choix modifie le montant, le total est rafraîchi pour refléter les frais ; le message, lui, est enregistré sans rechargement superflu.
### Mécanisme des frais
À chaque sélection, le module calcule le montant total (option d'emballage + carte) et crée un **prix spécifique** (`SpecificPrice`) limité au panier courant, appliqué au produit-frais caché. Ce produit est ajouté au panier lorsque le montant est supérieur à zéro, retiré sinon. PrestaShop applique alors la TVA, la devise et le contexte multiboutique, et le frais apparaît comme une ligne normale dans les totaux, la commande et la facture.
### Où apparaît le message
À la validation de la commande (`actionValidateOrder`), la sélection est figée. Le message saisi par le client est visible à trois endroits :
- sur la **fiche commande en back-office** (bloc dédié via `displayAdminOrderMain`) ;
- sur la **page de confirmation** affichée au client après l'achat ;
- dans le **champ cadeau natif** de la commande (`gift_message`, avec `gift = 1`), ce qui le fait apparaître dans les e-mails standards de PrestaShop.
Comme le message est aussi écrit dans le champ cadeau natif, vos modèles d'e-mails et vos outils de préparation qui exploitent déjà ce champ affichent le mot du client sans configuration supplémentaire.
## FAQ et dépannage
### S'agit-il d'une carte cadeau ou d'un bon d'achat ?
Non. Le module gère un service d'emballage cadeau et une carte message à offrir, pas un moyen de paiement ni un bon d'achat. Le client paie un emballage et peut y joindre une dédicace.
### Le frais n'apparaît pas dans le total
Vérifiez que le produit-frais caché (`DF-GIFTWRAP-FEE`) existe toujours et qu'au moins une option d'emballage est active. Videz le cache de PrestaShop, puis rechargez la page de commande. Le frais ne s'applique que lorsque le montant calculé est supérieur à zéro.
### La page d'accueil ou la boutique devient blanche après installation
Assurez-vous d'utiliser la dernière version du module et videz le cache. Le produit-frais est volontairement non visible en boutique ; ne le rendez pas visible et ne le supprimez pas manuellement.
### Le message est coupé
Le message est limité par le réglage **Longueur maximale du message**. Augmentez cette valeur dans la configuration si vos clients ont besoin de textes plus longs.
### Comment ajouter l'anglais, l'espagnol, l'allemand ou l'italien ?
L'interface est livrée en français et entièrement traduisible. Rendez-vous dans **Paramètres avancés > Traductions > Traductions des modules installés**, choisissez `dfgiftwrap` et la langue, puis traduisez les chaînes. Les noms d'options d'emballage se traduisent directement dans leur champ multilingue.
### Est-ce compatible PrestaShop 9 ?
Oui. Le module est conçu et testé de PrestaShop 8.0 à 9.x, avec un contrôleur d'administration legacy, en mono-boutique comme en multiboutique.
---
### Espace Membre & Contenu Payant (dfmembership) — Guide complet
_Source :_
> Présentation Le module Espace Membre & Contenu Payant (dfmembership) transforme votre boutique en plateforme d'adhésion : vous vendez des abonnements qui ouvrent l'accès à un espace membre et à du…
## Présentation
Le module **Espace Membre & Contenu Payant** (`dfmembership`) transforme votre boutique en plateforme d'adhésion : vous vendez des **abonnements** qui ouvrent l'accès à un **espace membre** et à du **contenu réservé** (articles, vidéos, fichiers, liens), à des prix de groupe, ou à des pages CMS privées. Chaque plan est relié à un **groupe client natif** de PrestaShop, ce qui laisse la boutique gérer nativement la visibilité catalogue et les prix par groupe ; le module ajoute par-dessus la facturation, le paywall, la bibliothèque, l'expiration automatique et la synchronisation des groupes.
Deux modèles économiques sont disponibles **dès la première version**, et se choisissent plan par plan : un **accès à durée limitée** (le client paie une fois pour N jours, l'accès expire automatiquement) et un **abonnement récurrent réel** via Stripe Billing (renouvellement et résiliation pilotés par webhooks).
## Compatibilité
- PrestaShop 8.0 à 9.x
- PHP 7.4 à 8.3
- Mono-boutique et multi-boutique
- 5 langues : FR, EN, ES, DE, IT
- Thème Classic et thèmes personnalisés
- Aucune dépendance : pas de Composer, pas de SDK Stripe embarqué (appels API en cURL natif)
## Concepts clés
### Plan = groupe client
Un **plan** représente une formule d'adhésion (par exemple « Premium » ou « Pro annuel »). Chaque plan est **mappé à un groupe client** PrestaShop : quand un client devient membre, il est ajouté à ce groupe ; quand son abonnement expire ou est résilié, il en est retiré. Vous bénéficiez ainsi de toute la mécanique native de PrestaShop : **prix spécifiques par groupe**, **restrictions de transporteurs**, **visibilité de catégories**, etc. — sans configuration supplémentaire dans le module.
Créez d'abord vos groupes clients dans **Clients > Groupes**, puis associez-les à vos plans. Un même groupe peut servir de socle à vos prix de groupe et à la réservation de contenu.
### Les deux modes de facturation
- **Durée limitée** : le client paie une fois et obtient l'accès pour la durée du plan (en jours). Une tâche cron expire les accès arrivés à terme. Idéal pour un pass ponctuel, un accès saisonnier ou un contenu à durée déterminée. En cas de renouvellement anticipé, le temps restant se cumule.
- **Abonnement Stripe** : un véritable abonnement récurrent géré par Stripe Billing. Le renouvellement, l'échec de paiement et la résiliation sont reçus par **webhooks** et reflétés automatiquement sur l'accès du client. Idéal pour un revenu récurrent (MRR).
## Installation
1. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** puis sélectionnez le fichier `dfmembership.zip`.
3. Une fois installé, cliquez sur **Configurer**.
À l'installation, le module crée ses tables (plans, abonnements, contenus), enregistre ses hooks, génère un **jeton cron** aléatoire et ajoute un menu **Membership** dans **Vendre**, avec trois sous-onglets : **Plans**, **Abonnements** et **Contenu**. Un lien **Mon adhésion** apparaît dans l'espace client.
## Configuration générale
La page de configuration du module regroupe les réglages globaux ainsi que les deux **URL d'intégration** (webhook Stripe et cron) à reporter dans vos outils externes.
### Réglages Stripe
- **Clé secrète Stripe** : votre clé `sk_live_…` (ou `sk_test_…` en test). Requise pour la facturation récurrente.
- **Clé publiable Stripe** : votre clé `pk_…`.
- **Secret de signature des webhooks** : la valeur `whsec_…` fournie par Stripe pour le point de terminaison. Elle sert à **vérifier la signature** de chaque webhook entrant.
### Contenu et paywall
- **Pages CMS protégées** : la liste des identifiants de pages CMS réservées aux membres, séparés par des virgules (par exemple `4,7,9`). Les non-membres qui tentent d'y accéder sont redirigés vers la bibliothèque.
- **Schéma SEO du paywall** : injecte des données structurées `isAccessibleForFree` à false sur le contenu réservé, afin qu'il reste indexable par Google sans être considéré comme du cloaking.
- **Longueur du teaser (mots)** : nombre de mots affichés avant le paywall lorsqu'aucun teaser explicite n'est saisi sur un contenu.
- **Régénérer le jeton cron** : remplace le jeton de l'URL cron (utile s'il a fuité).
La clé secrète et le secret de webhook sont sensibles. Utilisez les clés **de test** tant que vous validez le parcours, puis basculez sur les clés **live** en production. Ne partagez jamais l'URL cron avec son jeton publiquement.
## Créer un plan
Dans **Membership > Plans**, ajoutez une formule et renseignez :
- **Nom, accroche, description** (multilingues) : affichés sur la page d'abonnement et le bloc d'accueil.
- **Mode de facturation** : « Accès à durée limitée (cron) » ou « Abonnement récurrent (Stripe) ».
- **Prix** : le montant affiché au client.
- **Durée (jours)** : durée de l'accès en mode durée limitée.
- **Essai (jours)** : période d'essai éventuelle (0 = aucun). En mode Stripe, l'essai est transmis à l'abonnement Stripe.
- **Stripe Price ID** : l'identifiant `price_…` du tarif récurrent créé dans Stripe (mode Stripe uniquement).
- **Groupe client associé** : le groupe dans lequel le membre est placé tant que son accès est actif.
- **Position** et **Actif** : ordre d'affichage et disponibilité du plan.
## Mode durée limitée et cron
En mode durée, l'abonnement est créé puis activé pour la durée du plan ; sa date de fin est calculée à partir de la date d'activation. Les plans gratuits (prix nul) sont activés immédiatement, et un plan avec essai ouvre d'abord une fenêtre d'essai.
Pour fermer automatiquement les accès arrivés à terme, programmez l'**URL cron** affichée dans la configuration (protégée par un jeton). Une exécution quotidienne suffit :
```
curl "https://votre-boutique/index.php?fc=module&module=dfmembership&controller=cron&token=VOTRE_JETON"
```
Le cron passe en statut « expiré » tout abonnement durée dont la date de fin est dépassée, puis **resynchronise les groupes** du client concerné. Sans cron, les accès n'expirent pas tout seuls : pensez à le planifier.
## Mode abonnement Stripe
En mode Stripe, le client est redirigé vers une page de paiement **Stripe Checkout** en mode abonnement. À la fin du paiement, Stripe notifie votre boutique par webhook et l'accès est activé. Le cycle de vie complet est ensuite piloté par Stripe.
### Mise en place
1. Dans Stripe, créez un **produit** et un **tarif récurrent** (mensuel, annuel…), puis copiez son `price_…` dans le plan correspondant.
2. Renseignez vos clés Stripe et le secret de webhook dans la configuration du module.
3. Dans Stripe, ajoutez un **point de terminaison webhook** pointant vers l'URL affichée dans la configuration, et abonnez-le aux événements : `checkout.session.completed`, `invoice.paid`, `invoice.payment_failed`, `customer.subscription.updated` et `customer.subscription.deleted`.
### Que font les webhooks ?
- **checkout.session.completed** : active l'abonnement et enregistre l'identifiant d'abonnement Stripe.
- **invoice.paid** : renouvelle l'accès et reporte la date de fin de période.
- **invoice.payment_failed** : laisse l'accès pendant la période de relance (dunning) gérée par Stripe.
- **customer.subscription.updated** : reflète une résiliation programmée en fin de période ou un changement de date.
- **customer.subscription.deleted** : clôt définitivement l'accès et retire le client de son groupe.
Chaque webhook est vérifié par signature à l'aide du secret `whsec_…`. Si la signature est invalide ou si le secret n'est pas renseigné, la requête est rejetée. Vérifiez ce réglage en premier si les abonnements ne s'activent pas.
## Bibliothèque de contenu et paywall
Dans **Membership > Contenu**, créez les éléments réservés. Chaque contenu possède :
- **Type** : article, vidéo, fichier ou lien.
- **Titre, teaser, contenu** (multilingues). Le **teaser** est l'aperçu public affiché avant le paywall ; laissé vide, il est généré automatiquement à partir des premiers mots du contenu (longueur réglable).
- **URL média** : l'intégration vidéo, le fichier à télécharger ou le lien externe.
- **Plan requis** : le plan donnant accès au contenu. La valeur « Tout membre actif » ouvre le contenu à n'importe quel abonnement en cours.
- **Délai de drip (jours)** : nombre de jours après le début de l'abonnement avant que le contenu ne se débloque, pour diffuser progressivement une bibliothèque (drip content).
Côté boutique, la **bibliothèque** liste les contenus avec leur teaser. Un membre voit le contenu complet ; un visiteur ou un non-membre voit le teaser puis un **paywall** l'invitant à s'abonner. Le contrôle d'accès combine le plan requis et le délai de drip.
### Référencement du contenu réservé
Lorsque l'option de schéma SEO est activée, le module ajoute sur le contenu débloqué des données structurées indiquant qu'il s'agit de contenu payant (échantillonnage flexible de Google). Le bloc réservé est marqué par une classe CSS dédiée, ce qui permet à Google d'indexer la page sans pénaliser la différence entre ce que voient le robot et le membre.
## Pages CMS réservées
Pour réserver des pages CMS existantes (page de ressources, espace privé…), indiquez leurs identifiants dans **Pages CMS protégées**. Un non-membre qui ouvre l'une de ces pages est automatiquement redirigé vers la bibliothèque, où il peut découvrir les formules. Les membres y accèdent normalement.
## Espace membre
Depuis **Mon compte > Mon adhésion**, le client retrouve ses abonnements en cours : plan, statut, mode de facturation, date de renouvellement ou de fin. Il peut **ouvrir la bibliothèque** et, le cas échéant, **résilier** un abonnement. La résiliation se fait **en fin de période** : l'accès reste ouvert jusqu'au terme déjà payé, puis se ferme. En mode Stripe, la demande est transmise à Stripe ; en mode durée, l'accès n'est tout simplement pas reconduit.
## Gérer les abonnements (back-office)
Dans **Membership > Abonnements**, vous visualisez tous les abonnements (client, e-mail, plan, statut, mode, dates) avec recherche et export. La vue détaillée permet de **forcer un statut** (actif, expiré, résilié) en cas de besoin : un geste commercial, une régularisation, un litige. Tout changement de statut **resynchronise immédiatement le groupe** du client.
Les groupes sont également resynchronisés à la connexion du client et à la validation d'une commande, pour garantir que l'accès reflète toujours les abonnements réellement actifs.
## Aller plus loin
L'architecture de facturation est **extensible** : un nouveau fournisseur (par exemple PayPal récurrent) s'ajoute en implémentant l'interface `BillingManagerInterface` du dossier `src/Billing/` et en l'enregistrant dans la fabrique `BillingManagerFactory`, sans toucher au reste du module. Parmi les évolutions envisageables : teasers générés par IA, e-mails de relance, abonnements cadeaux, changement de formule avec prorata, ou tableau de bord MRR / taux de résiliation.
## FAQ et dépannage
### Un client a payé mais n'a pas accès
En mode Stripe, vérifiez d'abord le **secret de webhook** et que le point de terminaison reçoit bien les événements dans le tableau de bord Stripe (onglet Webhooks). L'activation dépend de l'événement `checkout.session.completed`. En mode durée, vérifiez que l'abonnement est bien passé en statut actif ; vous pouvez le forcer depuis la vue détaillée.
### Les accès n'expirent jamais
Le mode durée repose sur le cron. Assurez-vous d'avoir **programmé l'URL cron** (quotidienne) avec le bon jeton. Vous pouvez l'appeler manuellement pour tester : la réponse JSON indique le nombre d'abonnements expirés.
### Comment relier le plan à des prix réduits ?
Associez le plan à un **groupe client**, puis définissez des **prix spécifiques** pour ce groupe dans vos fiches produits (ou via une règle de prix catalogue). Tant que le membre est actif, il appartient au groupe et bénéficie de ces prix automatiquement.
### Le contenu réservé est-il indexable par Google ?
Oui, si l'option de schéma SEO est activée : le contenu payant est signalé comme tel via des données structurées, ce qui correspond aux recommandations de Google sur l'échantillonnage flexible. Vous gardez l'indexation sans masquer la nature payante.
### Puis-je proposer un essai gratuit ?
Oui. Renseignez un nombre de jours d'essai sur le plan. En mode durée, une fenêtre d'essai est ouverte ; en mode Stripe, l'essai est transmis à l'abonnement Stripe (`trial_period_days`).
### PayPal est-il géré ?
La version 1 implémente les modes durée et Stripe. PayPal récurrent peut être ajouté grâce à l'interface de facturation extensible, sans refonte du module.
### Est-ce compatible PrestaShop 9 ?
Oui. Le module est compatible PrestaShop 8 et 9, en multi-boutique et multilingue (FR, EN, ES, DE, IT).
---
### Essayage Virtuel IA pour Shopware 6 — Guide
_Source :_
> Ce module ajoute un widget d'essayage virtuel sur les fiches produit Shopware 6. Le client ajoute une photo de lui et l'IA de Google Vertex AI génère un aperçu du…
Ce module ajoute un widget d'essayage virtuel sur les fiches produit Shopware 6. Le client ajoute une photo de lui et l'IA de Google Vertex AI génère un aperçu du vêtement porté. Compatible Shopware 6.5, 6.6 et 6.7.
## Comment ça fonctionne
Le widget s'affiche sur la fiche produit, sous le bouton d'achat. Le client téléverse une photo (ou la prend avec la caméra sur mobile). La photo est réduite côté navigateur puis envoyée à votre serveur. Le serveur récupère l'image du produit, appelle l'API Google Vertex AI (modèle virtual-try-on-001) et renvoie l'aperçu généré.
Il s'agit d'un rendu génératif, pas d'un essayage en réalité augmentée en temps réel. Chaque aperçu est un appel API qui renvoie une image en quelques secondes.
## Prérequis Google Cloud
Le module s'appuie sur Vertex AI. Une configuration unique côté Google Cloud est nécessaire.
### 1. Créer un projet et activer la facturation
- Créez ou sélectionnez un projet dans la console Google Cloud.
- Activez la facturation sur le projet, obligatoire pour Vertex AI.
### 2. Activer l'API Vertex AI
Activez l'API Vertex AI (aiplatform.googleapis.com) pour le projet.
### 3. Créer un compte de service
- Créez un compte de service.
- Attribuez-lui le rôle Vertex AI User (roles/aiplatform.user).
- Créez une clé JSON pour ce compte et téléchargez-la.
## Installation
Installez le module comme toute extension Shopware (téléversement du ZIP dans Extensions puis Mes extensions, ou dépôt du dossier dans custom/plugins/DfVirtualTryOn), puis en ligne de commande :
```
bin/console plugin:refresh
bin/console plugin:install --activate DfVirtualTryOn
bin/console cache:clear
```
Aucune compilation du storefront n'est nécessaire : le widget est autonome, styles et JavaScript inclus.
## Configuration
Dans l'administration Shopware, ouvrez la configuration du module et renseignez :
- **ID du projet Google Cloud** : l'identifiant de votre projet.
- **Région** : une région où le modèle est disponible (us-central1 par défaut).
- **Modèle** : virtual-try-on-001 (recommandé).
- **Clé JSON du compte de service** : collez l'intégralité du fichier JSON téléchargé.
- **Nombre d'images** : de 1 à 4 aperçus par essayage.
- **Exiger le consentement** : activé par défaut, recommandé.
- **URL de politique de confidentialité** : affichée dans la case de consentement.
- **Libellé du bouton** : optionnel, remplace le texte traduit par défaut.
La région est importante : le modèle n'est pas disponible partout. Si vous choisissez une région qui ne l'héberge pas, les appels échouent avec une erreur « modèle introuvable ». En cas de doute, utilisez us-central1.
## Confidentialité et RGPD
Les photos des clients sont des données personnelles. Ce module envoie la photo uniquement à Google Vertex AI pour générer l'aperçu, ne conserve ni la photo ni le résultat sur votre serveur, peut exiger un consentement explicite avant chaque génération, et permet de lier votre politique de confidentialité dans la case de consentement.
Vous restez responsable de traitement. Pensez à mettre à jour votre politique de confidentialité pour indiquer que les images d'essayage sont traitées par Google Cloud.
## Coûts
Vertex AI facture chaque image générée (tarification Imagen). Ces frais sont côté Google Cloud, indépendants du prix du module. Réglez le nombre d'images sur 1 pour maîtriser le coût.
## Conseils pour de bons résultats
- Utilisez une photo nette, bien éclairée, en pied.
- Privilégiez des images produit claires (à plat ou sur mannequin).
- Les hauts, les bas et les pièces uniques comme les robes donnent les meilleurs résultats.
## Dépannage
- **Non autorisé** : le compte de service n'a pas le rôle Vertex AI User, ou la clé est incorrecte.
- **Modèle introuvable dans la région** : la région ne propose pas le modèle. Utilisez us-central1.
- **Non configuré** : l'ID du projet ou la clé JSON est vide.
- **Limite de débit atteinte** : quota Vertex AI dépassé. Réessayez plus tard ou demandez une augmentation de quota.
---
### Essayage virtuel IA pour WooCommerce — Documentation
_Source :_
> Ce que fait le plugin DF Google Try-On ajoute un bouton d'essayage virtuel sur vos fiches produit WooCommerce. La cliente charge une photo ou utilise sa webcam, et l'intelligence artificielle…
## Ce que fait le plugin
DF Google Try-On ajoute un bouton d'essayage virtuel sur vos fiches produit WooCommerce. La cliente charge une photo ou utilise sa webcam, et l'intelligence artificielle génère une image d'elle portant le vêtement. L'aperçu s'affiche dans une modale, sans jamais quitter la fiche produit.
**Important :** ce plugin utilise l'API développeur _Vertex AI Virtual Try-On_ de Google Cloud. Ce n'est pas l'essayage grand public visible dans Google Search et Google Shopping, qui n'est pas intégrable sur un site tiers. Chaque génération d'image est facturée par Google.
## Prérequis
- WordPress 6.2 ou supérieur, WooCommerce 7.0 ou supérieur
- PHP 7.4 ou supérieur, avec l'extension OpenSSL activée
- Un projet Google Cloud avec la facturation active
- L'API Vertex AI activée sur ce projet
- Un compte de service disposant du rôle _Vertex AI User_
## Étape 1 — Préparer Google Cloud
### Activer l'API Vertex AI
Dans la console Google Cloud, sélectionnez votre projet, puis rendez-vous dans la bibliothèque d'API et activez _Vertex AI API_. Vérifiez que la facturation est bien active sur le projet : sans elle, tous les appels échoueront.
### Créer le compte de service
1. Ouvrez la section IAM et administration, puis Comptes de service.
2. Créez un compte de service (le nom importe peu, par exemple _woocommerce-tryon_).
3. Attribuez-lui le rôle **Vertex AI User**. N'accordez pas de rôle plus large que nécessaire.
4. Dans l'onglet Clés, créez une clé de type JSON et téléchargez le fichier.
Ce fichier JSON contient une clé privée. Traitez-le comme un mot de passe : ne le versionnez pas, ne le partagez pas, et restreignez l'accès à votre administration WordPress.
### Choisir une région
Le modèle doit être disponible dans la région que vous indiquez. La valeur par défaut _us-central1_ est la plus sûre. Si vous souhaitez une région européenne, vérifiez au préalable la disponibilité du modèle Virtual Try-On dans la documentation Google, car la couverture régionale évolue.
## Étape 2 — Installer le plugin
1. Dans WordPress, allez dans Extensions, Ajouter, Téléverser une extension.
2. Sélectionnez le fichier ZIP fourni, puis installez et activez.
3. Un nouveau menu apparaît : WooCommerce, Google Try-On.
## Étape 3 — Configurer
Tous les réglages se trouvent dans WooCommerce, Google Try-On.
### Connexion à Google
- **Identifiant du projet GCP** : l'identifiant du projet, pas son nom d'affichage.
- **Région** : par exemple _us-central1_.
- **JSON du compte de service** : collez le contenu intégral du fichier téléchargé. Le plugin valide le JSON à l'enregistrement et refuse une clé mal formée.
À l'enregistrement, le cache du jeton d'accès est vidé automatiquement : une modification de clé est donc prise en compte immédiatement.
### Affichage
- **Activer l'essayage** : interrupteur général. Tant qu'il est décoché, rien ne s'affiche côté boutique.
- **Libellé du bouton** : le texte affiché sur la fiche produit.
- **Catégories éligibles** : limite le widget à certaines catégories. Laissez vide pour autoriser tous les produits.
### Sécurité et coûts
- **Filtre de sécurité** : niveau de filtrage appliqué par Google aux images. Le réglage le plus strict est recommandé sur une boutique publique.
- **Filigrane** : ajoute le filigrane SynthID de Google aux images générées. Recommandé, pour signaler qu'il s'agit d'une image de synthèse.
- **Plafond mensuel** : nombre maximal d'essayages réussis par mois civil. Mettez 0 pour ne pas plafonner, mais gardez en tête que chaque génération est facturée.
- **Texte de consentement** : le message affiché à côté de la case à cocher obligatoire.
Le compteur du mois en cours est affiché en haut de la page de réglages.
## Étape 4 — Contrôler l'affichage produit par produit
Dans la fiche d'un produit, onglet Général des données produit, un réglage _Essayage virtuel_ propose trois valeurs :
- **Auto** : suit les catégories configurées globalement.
- **Toujours afficher** : force l'affichage, même hors des catégories éligibles.
- **Ne jamais afficher** : masque le widget, quelle que soit la configuration globale.
Le vêtement envoyé à l'IA est l'image principale du produit, récupérée côté serveur. Une photo nette du vêtement seul, bien détourée et sur fond clair, donne de bien meilleurs résultats qu'une photo portée ou une mise en scène chargée.
## Comment ça fonctionne côté technique
Le parcours d'un essayage est le suivant :
1. La cliente ouvre la modale et fournit une photo, par import ou capture webcam. L'image est redimensionnée dans le navigateur, sur son plus grand côté, avant tout envoi.
2. Elle coche la case de consentement, obligatoire : sans elle, la requête est refusée par le serveur.
3. Le serveur vérifie le jeton de sécurité, le produit, la limitation par adresse IP et le plafond mensuel.
4. Le plugin signe un jeton JWT en RS256 avec la clé privée du compte de service, l'échange contre un jeton d'accès OAuth2, puis le met en cache jusqu'à sa quasi-expiration.
5. La photo et l'image produit sont envoyées au modèle Vertex AI, qui renvoie l'image générée.
6. L'image est retournée au navigateur et affichée dans la modale.
L'image du vêtement n'est jamais fournie par le navigateur : elle est toujours lue côté serveur depuis la fiche produit. Cela empêche un visiteur de détourner le service pour essayer une image arbitraire.
## Données personnelles et RGPD
La photo de la cliente est une donnée personnelle. Le plugin est conçu en conséquence :
- La photo n'est jamais enregistrée sur votre serveur, ni dans la médiathèque, ni en base de données. Elle transite en mémoire le temps de l'appel.
- L'image générée est renvoyée directement au navigateur et n'est pas stockée non plus.
- Une case de consentement explicite, dont vous rédigez le texte, doit être cochée avant tout traitement.
- La photo est transmise à Google, qui agit comme sous-traitant. Mentionnez ce transfert dans votre politique de confidentialité, en indiquant la finalité et le destinataire.
Le plugin ne conserve aucune image, mais il vous appartient de documenter ce traitement dans votre registre et votre politique de confidentialité, et de vérifier les conditions d'utilisation de Google Cloud applicables à votre projet.
## Maîtriser les coûts
Chaque essayage réussi correspond à une génération d'image facturée par Google. Trois garde-fous sont intégrés :
- Le plafond mensuel, qui bloque les nouvelles générations une fois atteint.
- Une limitation par adresse IP, qui empêche les appels en rafale.
- L'usage exclusif de l'image produit côté serveur, qui interdit tout usage détourné du service.
Le compteur est réinitialisé automatiquement à chaque nouveau mois civil. Surveillez en parallèle le budget dans la console Google Cloud, où vous pouvez définir des alertes de facturation.
## Résolution des problèmes
### Le bouton n'apparaît pas
Vérifiez dans l'ordre : l'interrupteur général est activé, l'identifiant de projet et le JSON sont renseignés, le produit appartient à une catégorie éligible ou est forcé sur Toujours afficher, et le produit possède bien une image principale.
### Message d'erreur d'authentification
La clé JSON est invalide, incomplète, ou le compte de service n'a pas le rôle Vertex AI User. Recollez le fichier complet et vérifiez le rôle dans la console Google Cloud. Vérifiez aussi que l'extension OpenSSL est disponible sur votre hébergement.
### Aucune image générée
Le modèle peut refuser une photo trop sombre, floue, recadrée sur le visage, ou comportant plusieurs personnes. Demandez une photo nette, bien éclairée, de préférence en pied et de face. Un filtre de sécurité très strict peut aussi bloquer certaines images.
### Erreur de région ou de modèle introuvable
Le modèle n'est pas disponible dans la région saisie. Revenez à _us-central1_ et vérifiez la disponibilité régionale du modèle dans la documentation Google.
### Le service indique être à pleine capacité
Le plafond mensuel est atteint. Augmentez-le dans les réglages, ou attendez le mois suivant. Le compteur du mois en cours est visible en haut de la page de réglages.
## Questions fréquentes
### Faut-il installer Composer ?
Non. Le plugin utilise un autoloader natif et signe l'authentification Google en PHP pur, via OpenSSL.
### Le plugin est-il compatible HPOS ?
Oui, la compatibilité avec le stockage haute performance des commandes est déclarée.
### Fonctionne-t-il sur mobile ?
Oui. La capture utilise la caméra frontale lorsque le navigateur l'autorise, et l'import de photo reste toujours disponible.
### Peut-on essayer autre chose que des vêtements ?
Le modèle est entraîné pour les vêtements portés. Les résultats sur des accessoires, des chaussures ou des objets sont beaucoup moins fiables. Restreignez le widget à vos catégories de vêtements.
### Que se passe-t-il si je désinstalle le plugin ?
La désinstallation supprime les réglages, le jeton en cache et les compteurs mensuels. Le réglage par produit est conservé, afin de ne rien perdre en cas de réinstallation.
---
### Expédition Partielle & Reliquats Automatiques (dfavailsplit)
_Source :_
> Présentation Ce module découpe automatiquement chaque commande selon le stock réellement disponible. Les articles en stock partent immédiatement dans une commande prête à préparer, tandis que les articles en rupture…
## Présentation
Ce module découpe automatiquement chaque commande selon le stock réellement disponible. Les articles en stock partent immédiatement dans une commande prête à préparer, tandis que les articles en rupture sont déplacés dans une commande _reliquat_ (backorder) dédiée. Les deux commandes partagent la même référence et la somme de leurs totaux est strictement égale à la commande d'origine, taxes comprises.
Tout se déclenche à la validation de la commande, et une découpe manuelle ligne par ligne est disponible sur chaque fiche commande.
## Installation
1. Téléversez le dossier `dfavailsplit` dans `/modules/`, ou installez l'archive ZIP via **Modules > Module Manager > Téléverser un module**.
2. Cliquez sur **Installer**.
3. Ouvrez la configuration via **Configurer**.
À l'installation, le module crée un état de commande dédié **« En réapprovisionnement (Backorder) »** (couleur orange). Cet état et l'historique des splits sont conservés à la désinstallation pour préserver vos données.
## Configuration
Rendez-vous dans **Modules > Module Manager > dfavailsplit > Configurer**.
### Activer le split automatique
Interrupteur principal. Désactivé, aucune commande n'est découpée automatiquement ; la découpe manuelle reste disponible sur la fiche commande.
### État de commande backorder
État appliqué à la commande contenant les articles en rupture. Par défaut, l'état « En réapprovisionnement (Backorder) » créé à l'installation.
### Surcharge de l'état de la commande expédiable
Optionnel. Activez cette option pour forcer un état précis (par exemple « Préparation en cours ») sur la commande expédiable. Désactivé, la commande conserve son état courant.
### Port gratuit sur le backorder
Activé par défaut. Les frais de port restent sur la commande expédiable ; le reliquat est livré sans frais, car le client a déjà payé le port une seule fois.
### Découpe des lignes partielles
Activé par défaut. Une ligne partiellement disponible (3 en stock sur 5 commandés) est scindée en 3 expédiés + 2 en reliquat. Désactivé, la ligne entière bascule en reliquat.
### E-mail backorder
Envoie au client un e-mail dans sa langue (FR/EN/ES/DE/IT/PL fournis, repli anglais) l'informant que sa commande sera expédiée en plusieurs fois.
### Régénération des factures après split
Désactivé par défaut. Laissez désactivé pour émettre les factures au moment de l'expédition réelle de chaque commande. Activé, le module régénère les factures des deux commandes après le split si l'état courant l'exige.
### Journalisation
Enregistre chaque opération de split dans les journaux PrestaShop pour la traçabilité.
## Comment fonctionne le split
La découpe automatique s'exécute juste après la validation de la commande (hook `actionValidateOrderAfter`, avec repli sur `actionOrderStatusPostUpdate` pour les flux qui ne l'émettent pas). Le module déduit la quantité expédiable de chaque ligne à partir de la pénurie réelle du stock, mutualisée par produit et déclinaison. Ce modèle reste juste même pour une découpe manuelle lancée des jours plus tard, quand le stock a bougé.
Trois cas se présentent :
- **Tout est disponible** : aucune découpe. La commande suit son cours (option de forçage d'état possible).
- **Tout est en rupture** : pas de découpe, la commande entière passe à l'état backorder.
- **Commande mixte** : la commande d'origine conserve la part expédiable (port, remises, emballage, paiement) ; une nouvelle commande reliquat est créée pour le reste, avec la même référence.
Les totaux (produits, port, remises, emballage, poids) et la ventilation TVA sont recalculés au centime près, ligne par ligne. La somme des deux commandes égale exactement la commande d'origine, taxes comprises, y compris sur les factures régénérées et les rapports fiscaux. Le paiement, agrégé par référence, se réconcilie nativement.
La découpe est atomique : toutes les mutations (création du reliquat, déplacement des lignes, totaux, transporteur, factures) sont encadrées par une transaction SQL. Un échec en cours de route annule tout, jamais de commande à moitié découpée.
## Découpe manuelle depuis la fiche commande
Sur chaque fiche commande non découpée, le panneau **« Découpe par disponibilité »** affiche un tableau ligne par ligne : produit, quantité commandée, stock actuel et quantité à mettre en reliquat. Les champs sont pré-remplis avec la suggestion de l'analyse de stock ; ajustez-les librement, 0 conservant la ligne sur la commande d'origine, puis cliquez sur **« Découper cette commande maintenant »**.
- Disponible même quand la découpe automatique est désactivée.
- Une commande déjà découpée ne peut jamais l'être une seconde fois.
- La sélection est refusée si elle viderait entièrement l'une des deux commandes.
- Les lignes personnalisées et le réglage « découpe des lignes partielles » sont respectés.
## Sur la fiche commande (back-office)
Une fois la découpe effectuée, le panneau relie les deux commandes : depuis la commande expédiable, il renvoie vers le reliquat associé, et inversement. La référence partagée est rappelée dans les deux sens.
## Page de confirmation et e-mail client
Sur la page de confirmation de commande, un bloc liste les articles qui seront expédiés séparément, avec le rappel de la référence commune et du port payé une seule fois. Le bloc fonctionne avec tous les thèmes : il s'appuie sur les trois ancres de confirmation (`displayOrderConfirmation`, `displayOrderConfirmation1`, `displayOrderConfirmation2`) et résout la commande depuis l'URL de confirmation avec vérification de la clé de sécurité, sans jamais s'afficher deux fois.
Si l'option e-mail est active, le client reçoit également un e-mail dans sa langue l'informant de l'expédition partielle et du reliquat livré sans frais supplémentaires. Les modèles FR, EN, ES, DE, IT et PL sont fournis dans le dossier `mails/` du module, avec repli sur l'anglais pour toute autre langue.
L'e-mail de confirmation initial (commande complète) est envoyé par PrestaShop avant la découpe. L'e-mail backorder du module vient ensuite informer le client de l'expédition en plusieurs fois.
## Cas particuliers et limites
- Les produits **virtuels** ne sont jamais mis en reliquat.
- Les produits en **gestion avancée des stocks (ASM)** sont exclus de la découpe et restent sur la commande expédiable.
- Une ligne **personnalisée** n'est pas scindée : elle est routée entière vers l'une des deux commandes.
- Si la gestion des stocks est désactivée dans PrestaShop, aucune découpe n'est effectuée.
## Dépannage
### Aucune commande n'est découpée
Vérifiez que le split est activé, que la gestion des stocks PrestaShop est active et que les produits concernés ne sont ni virtuels ni en gestion avancée des stocks. Un split automatique n'a lieu que pour une commande mixte (à la fois du disponible et de la rupture). Pour tout autre cas, utilisez la découpe manuelle sur la fiche commande.
### Le reliquat affiche des frais de port
Activez l'option « Port gratuit sur le backorder ». Les frais restent alors uniquement sur la commande expédiable.
### Le bloc n'apparaît pas sur la page de confirmation
Depuis la version 1.3.4, le bloc s'affiche avec tous les thèmes via trois ancres de confirmation. Si vous utilisez une version antérieure, mettez le module à jour.
### Compatibilité
PrestaShop 8.x et 9.x, multiboutique, sans override ni Composer.
---
### Explorer FTP (explorerftp) — Documentation
_Source :_
> Explorer FTP (explorerftp) est un gestionnaire de fichiers intégré au back-office de PrestaShop. Il permet de parcourir l'arborescence de la boutique, d'éditer les fichiers texte et code grâce à un…
**Explorer FTP** (`explorerftp`) est un gestionnaire de fichiers intégré au back-office de PrestaShop. Il permet de parcourir l'arborescence de la boutique, d'éditer les fichiers texte et code grâce à un éditeur intégré, d'importer et de télécharger des fichiers, et d'exporter des dossiers au format ZIP — sans passer par un client FTP externe. Cette documentation couvre l'installation, l'utilisation complète, le modèle de sécurité et le dépannage.
## Présentation
Explorer FTP ajoute une entrée dans _Paramètres avancés_ du back-office. Depuis cette interface, un employé disposant des droits nécessaires peut naviguer dans les fichiers de la boutique, ouvrir un éditeur de code avec coloration syntaxique, créer des dossiers, renommer, copier, déplacer ou supprimer des éléments, importer des fichiers par glisser-déposer et générer des archives ZIP. L'ensemble des accès est strictement limité au répertoire racine de PrestaShop.
## Prérequis
- PrestaShop 8.0 ou supérieur (compatible 9.x).
- PHP 8.0 ou supérieur.
- Extension PHP `ZipArchive` pour les fonctions d'export ZIP.
## Installation
### Depuis le back-office
1. Rendez-vous dans _Modules > Gestionnaire de modules_.
2. Cliquez sur _Téléverser un module_ et sélectionnez l'archive `explorerftp.zip`.
3. Le module s'installe automatiquement et crée son onglet d'administration.
### Via FTP
1. Décompressez l'archive et déposez le dossier `explorerftp` dans le répertoire `/modules` de la boutique.
2. Dans _Modules > Gestionnaire de modules_, recherchez « Explorer FTP » puis cliquez sur _Installer_.
Après l'installation, l'entrée **Explorer FTP** apparaît dans le menu _Paramètres avancés_.
## Accès au module
Ouvrez _Paramètres avancés > Explorer FTP_. L'accès est réservé aux profils disposant de la permission sur l'onglet _AdminExplorerFtp_ : vous pouvez restreindre son usage à certains profils employés depuis _Équipe > Permissions_.
## Interface
### Barre d'outils
- **Retour / Dossier parent / Actualiser** : navigation dans l'arborescence.
- **Fil d'Ariane** : affiche le chemin courant et permet de remonter à n'importe quel niveau.
- **Recherche** : recherche par nom de fichier ou de dossier dans le répertoire courant et ses sous-dossiers (les répertoires lourds comme `vendor`, `var`, `cache`, `node_modules` et `.git` sont ignorés).
- **Téléverser** et **Nouveau dossier** : ajout de fichiers ou création de répertoires.
### Arborescence et liste
Le panneau latéral affiche l'arborescence des dossiers ; le panneau principal liste les éléments du dossier courant avec leur taille, date de modification et permissions. Les colonnes sont triables (nom, taille, date). Un clic droit sur un élément ouvre le menu contextuel complet.
## Éditeur de code
Un clic sur l'icône d'édition (ou sur _Modifier_ dans le menu contextuel) ouvre le fichier dans un éditeur plein écran basé sur CodeMirror, avec coloration syntaxique pour PHP, HTML, Smarty (.tpl), Twig, CSS/SCSS/LESS, JavaScript, JSON, XML, YAML, SQL et Markdown. La recherche, le repli de code et l'appariement des accolades sont pris en charge.
- Seuls les types de fichiers texte et code sont éditables (php, tpl, twig, css, js, json, xml, yml, md, sql, etc.).
- La taille maximale d'édition est de 5 Mo par fichier.
- Cliquez sur _Enregistrer_ pour écrire les modifications.
À chaque enregistrement, une sauvegarde horodatée du fichier est créée dans `var/explorer_backups`. Les 50 sauvegardes les plus récentes sont conservées ; les plus anciennes sont supprimées automatiquement.
## Import de fichiers
Importez des fichiers par glisser-déposer dans la zone dédiée ou via le bouton _Téléverser_. Les fichiers sont déposés dans le dossier courant, à condition qu'il soit accessible en écriture.
Pour des raisons de sécurité, les types de fichiers exécutables côté serveur (`php`, `phtml`, `phar`, `cgi`, `sh`, etc.) sont refusés à l'import. Seuls les formats sûrs (documents, images, polices, archives, fichiers texte et web) sont acceptés. Les fichiers PHP existants restent modifiables via l'éditeur.
## Téléchargement et archives ZIP
- **Télécharger un fichier** : télécharge le fichier sélectionné.
- **Télécharger ZIP** : compresse un dossier et le télécharge sous forme d'archive ZIP horodatée.
- **Enregistrer ZIP sur le serveur** : génère l'archive et l'enregistre directement dans un dossier de destination de la boutique, sans téléchargement.
## Opérations sur les fichiers
Le menu contextuel (clic droit) et les actions de ligne permettent de :
- **Renommer** un fichier ou un dossier.
- **Copier** ou **Déplacer** un élément vers un autre dossier via l'arborescence de destination.
- **Supprimer** un fichier ou un dossier (récursivement).
- **Propriétés** : affiche le chemin, la taille, les dates, les permissions, le propriétaire et le type MIME.
## Modèle de sécurité
Explorer FTP applique plusieurs couches de protection :
- **Périmètre racine** : toutes les opérations sont confinées au répertoire racine de PrestaShop. Les chemins fournis sont normalisés via `realpath()` puis vérifiés afin d'empêcher toute traversée de répertoire (« path traversal »).
- **Jeton de sécurité** : chaque requête AJAX est validée par un jeton d'administration, comparé en temps constant.
- **Dossiers protégés** : les répertoires critiques (`app`, `bin`, `classes`, `config`, `controllers`, `override`, `src`, `tools`, `var`, `vendor`) ne peuvent pas être supprimés.
- **Import restreint** : liste blanche d'extensions et blocage des types exécutables (voir « Import de fichiers »).
- **En-têtes de sécurité** : anti-clickjacking (`X-Frame-Options`) et anti-sniffing MIME (`X-Content-Type-Options`) sur les réponses du contrôleur.
Explorer FTP est un outil d'administration puissant. Réservez son accès aux profils employés de confiance et veillez à ce que votre back-office soit servi en HTTPS.
## Dépannage
### « Répertoire non accessible en écriture » à l'import ou à la création
Le dossier de destination n'a pas les droits d'écriture. Ajustez les permissions du dossier concerné sur votre serveur.
### Les fonctions ZIP sont indisponibles
L'extension PHP `ZipArchive` n'est pas installée ou activée sur le serveur. Activez-la auprès de votre hébergeur.
### Un fichier PHP ne peut pas être importé
C'est le comportement attendu : l'import de fichiers exécutables est bloqué. Pour modifier un fichier PHP existant, utilisez l'éditeur intégré.
En cas de modification malencontreuse d'un fichier, récupérez la version précédente depuis `var/explorer_backups`.
## Désinstallation
Depuis _Modules > Gestionnaire de modules_, cliquez sur _Désinstaller_ en regard d'Explorer FTP. L'onglet d'administration est retiré. Les fichiers de la boutique et les sauvegardes présentes dans `var/explorer_backups` ne sont pas supprimés.
---
### Export Comptable — Guide complet
_Source :_
> Présentation DataFirefly Export Comptable (dfaccountingexport) génère vos écritures comptables PrestaShop dans huit formats : FEC (obligation fiscale française, article A-47 A-1 du LPF), Sage 100, EBP Compta, Ciel XIMPORT, Quadratus…
## Présentation
DataFirefly Export Comptable (`dfaccountingexport`) génère vos écritures comptables PrestaShop dans huit formats : **FEC** (obligation fiscale française, article A-47 A-1 du LPF), **Sage 100**, **EBP Compta**, **Ciel XIMPORT**, **Quadratus ASCFIC**, **Pennylane**, **Tiime** et **Indy**. Le module lit les commandes payées et les avoirs de la période choisie, construit les écritures (journal des ventes VE et journal des avoirs AV), ventile automatiquement par taux de TVA et produit un fichier prêt à transmettre à votre cabinet ou à importer dans votre logiciel comptable.
## Installation
1. Dans le back-office PrestaShop, allez dans **Modules → Gestionnaire de modules → Installer un module**.
2. Uploadez le fichier `dfaccountingexport.zip`.
3. Le module crée automatiquement la table `ps_dfae_export_log` (historique des exports) et un onglet **Export comptable** sous le menu **Commandes**.
Compatibilité : PrestaShop 8.0 à 9.x, PHP 7.4 minimum (8.1+ recommandé), multiboutique supporté.
## Configuration
Ouvrez **Modules → dfaccountingexport → Configurer**. La configuration est organisée en trois panneaux.
### Journaux
- **Code journal ventes** (défaut `VE`) et son libellé.
- **Code journal avoirs** (défaut `AV`) et son libellé.
### Plan de comptes
Les valeurs par défaut suivent le Plan Comptable Général français. Tous les numéros sont modifiables :
- `411` — Clients (compte général, racine)
- `707` — Ventes de marchandises
- `4457` — TVA collectée
- `708` — Frais de port facturés
- `709` — Rabais, remises, ristournes
- Comptes d'encaissement : un compte par mode de paiement, configurés dans le panneau dédié (voir la section Journal des règlements)
**Mode de ventilation** : par taux de TVA (défaut), par catégorie produit, ou aucune. En mode taux, chaque taux rencontré génère un sous-compte : `707000` (20 %), `707010` (10 %), `707055` (5,5 %), `707021` (2,1 %). La TVA collectée suit la même logique sur `4457`.
**Compte auxiliaire client** : activé, chaque écriture client porte un numéro auxiliaire de la forme `C000123` (client 123) en plus du compte général. Recommandé pour la conformité FEC et le lettrage des règlements par votre cabinet.
### Options
- **SIREN** : indispensable pour le FEC. Le nom de fichier réglementaire est `SIREN + FEC + date de clôture` (ex. `123456789FEC20261231.txt`). Sans SIREN configuré, le fichier porte le mot « SIREN » littéral et n'est pas conforme pour un dépôt.
- **États de commande inclus** : par défaut « Paiement accepté » et « Livré ». Cochez les états que votre flux considère comme comptabilisables.
- **Encodage de sortie** : UTF-8 ou ISO-8859-15. Sage, Ciel et Quadratus préfèrent souvent l'ISO ; Pennylane, Tiime et le FEC restent en UTF-8.
## Générer un export
1. Allez dans **Commandes → Export comptable**.
2. Choisissez la **période** (date de début / date de fin). Le filtre s'applique sur la date de facture pour les commandes et la date de création pour les avoirs.
3. Sélectionnez le **format** parmi les huit disponibles.
4. Cliquez sur **Aperçu** : le module calcule sans générer de fichier le nombre de commandes, le nombre de lignes d'écritures, le total débit et le total crédit. Un bandeau vert confirme l'équilibre parfait ; un bandeau rouge signale un écart.
5. Cliquez sur **Exporter** : le fichier est généré et téléchargé immédiatement, et l'opération est journalisée dans l'historique.
### Logique des écritures — journal des ventes
Pour chaque commande payée : débit `411` (client, TTC), crédit `707xxx` par taux (ventes HT), crédit `4457xxx` par taux (TVA), crédit `708` (port HT) et débit `709` (remises) le cas échéant. Un ajustement d'arrondi automatique (écart < 0,10 €) est injecté sur le compte de TVA pour garantir l'équilibre — les centimes de TVA résiduels sont un classique des exports e-commerce.
### Logique des écritures — journal des avoirs
Les `OrderSlip` de la période génèrent des écritures miroir dans le journal AV : crédit `411`, débit `707xxx`, débit `4457xxx`. Les avoirs sont inclus dans la vérification d'équilibre globale.
## Les huit formats en détail
- **FEC** — 18 colonnes séparées par pipe, dates AAAAMMJJ, montants positifs avec sens débit/crédit, UTF-8 sans BOM. Conforme article A-47 A-1 du LPF.
- **Sage 100** — CSV point-virgule : Journal;Date;NumPièce;CompteGénéral;CompteAuxiliaire;Libellé;Sens;Montant;Devise.
- **EBP Compta** — Format tabulé avec débit/crédit en colonnes séparées et lettrage.
- **Ciel XIMPORT** — Largeur fixe 81 caractères, montants sur 13 caractères zero-padded.
- **Quadratus ASCFIC** — Largeur fixe, montants en centimes entiers.
- **Pennylane** — CSV moderne, UTF-8 forcé, décimale point, dates ISO.
- **Tiime** — CSV point-virgule avec dates JJ/MM/AAAA.
- **Indy** — CSV simplifié adapté aux indépendants.
Les layouts **Ciel XIMPORT** et **Quadratus ASCFIC** connaissent des variantes selon les cabinets. Faites valider le premier fichier par le destinataire avant de passer en production.
## Journal des règlements (depuis 1.1.1)
Optionnel et désactivé par défaut. Activez **Générer le journal des règlements** dans le panneau **Comptes d'encaissement par mode de paiement** de la configuration.
### Mapping mode de paiement vers compte
Le panneau liste automatiquement vos modules de paiement (installés et présents dans l'historique des commandes, avec compteur de commandes). Saisissez un compte en face de chaque module, par exemple `580000` espèces, `580100` chèques, `580200` CB, `580300` virements, `580400` PayPal. Un champ laissé vide bascule sur le **compte par défaut**, repris de l'ancien compte banque lors de la mise à jour.
### Logique des écritures
Chaque paiement enregistré (`ps_order_payment`) sur la période génère dans le journal de banque (BQ) : débit compte d'encaissement / crédit `411` client (avec compte auxiliaire le cas échéant). La date d'écriture est la **date du paiement**, pas la date de facture : une commande de mars payée en avril sort dans les règlements d'avril, en cohérence avec vos relevés bancaires. Les montants négatifs (transactions de remboursement) inversent automatiquement le sens débit/crédit. La pièce porte la référence `RG` suivie du numéro de paiement et de la référence commande, pour faciliter le lettrage.
## Historique des exports
Chaque export est journalisé en base (`ps_dfae_export_log`) : format, période, nombre de commandes et de lignes, totaux débit/crédit, nom de fichier, opérateur, horodatage. Les 20 derniers exports sont affichés en bas de l'écran d'export.
## FAQ & dépannage
### L'aperçu montre un écart débit/crédit — que faire ?
Un écart supérieur à 0,10 € indique généralement une commande à la taxation atypique (taxe personnalisée, ecotaxe, arrondi de devise). Réduisez la période pour isoler la commande fautive, vérifiez sa configuration de taxe, puis relancez l'aperçu.
### Le fichier FEC est refusé par l'outil de contrôle de la DGFiP
Vérifiez d'abord que le SIREN est renseigné dans la configuration, puis que la période exportée correspond bien à l'exercice, et que l'encodage est resté en UTF-8. L'outil « Test Compta Demat » de la DGFiP permet de valider le fichier en local.
### Puis-je exporter plusieurs formats pour la même période ?
Oui, sans reparamétrage : sélectionnez simplement un autre format et relancez l'export. Chaque génération est journalisée séparément.
### Le module modifie-t-il mes données de commande ?
Non. Le module est strictement en lecture sur les commandes, factures et avoirs. Sa seule écriture en base est la journalisation de l'historique.
---
### Express Checkout — Apple Pay, Google Pay & Amazon Pay via Stripe — Guide complet
_Source :_
> Présentation DataFirefly Express Checkout ajoute le paiement par portefeuille — Apple Pay, Google Pay et Amazon Pay — à votre boutique PrestaShop 8 ou 9, via Stripe. Le module s'appuie…
## Présentation
DataFirefly Express Checkout ajoute le paiement par portefeuille — **Apple Pay**, **Google Pay** et **Amazon Pay** — à votre boutique PrestaShop 8 ou 9, via Stripe. Le module s'appuie sur l'**Express Checkout Element** de Stripe : un composant unique qui détecte automatiquement les portefeuilles disponibles sur l'appareil du client et affiche les boutons correspondants.
Les boutons peuvent apparaître à trois emplacements, activables indépendamment : sur la **fiche produit** (achat express), dans le **panier** et sur la **page de paiement**. Après paiement, la commande est créée et validée par un **webhook Stripe à signature vérifiée**, avec une logique idempotente qui empêche toute commande en double. Le module est compatible mono et multi-boutique, et fourni en cinq langues (FR, EN, ES, DE, IT).
## Prérequis
- PrestaShop **8.0 à 9.x**, PHP 7.4 ou supérieur.
- L'extension **PHP cURL** activée (vérifiée à l'installation).
- Un **compte Stripe** actif.
- Une boutique servie en **HTTPS** (obligatoire pour Apple Pay et Google Pay).
## Installation
1. Depuis le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez l'archive ZIP du module.
3. Une fois l'installation terminée, cliquez sur **Configurer**.
À l'installation, le module crée une table de suivi des transactions et un état de commande dédié « Paiement autorisé (en attente de capture) » utilisé par le mode de capture manuelle.
## Connexion à Stripe
Le module propose deux modes de connexion, réglés par le champ **Mode de connexion**.
### Mode manuel (clés API)
Renseignez vos clés depuis le Dashboard Stripe (**Développeurs > Clés API**) :
- **Clé publique** et **Clé secrète**, en version Test puis Live.
- **Secret du webhook** (voir la section Webhook ci-dessous).
Basculez le champ **Mode** sur Test pendant l'intégration, puis sur Live en production. Chaque mode possède son propre jeu de clés.
### Mode automatique (Stripe Connect / OAuth)
Ce mode connecte votre compte Stripe en un clic. Cliquez sur **Se connecter avec Stripe**, autorisez l'accès, et le module récupère automatiquement les clés publique et secrète, **crée le webhook** (et son secret de signature) et tente d'enregistrer le **domaine wallet** pour Apple Pay / Google Pay. Le bouton **Déconnecter** révoque l'accès et purge les clés.
Le mode automatique nécessite une **application Stripe Connect**. Deux possibilités :
- **Votre propre application Connect** : renseignez le `client_id` et le **secret de plateforme** (Test et Live).
- **Courtier DataFirefly** : renseignez l'**URL du courtier**, qui détient le secret de plateforme et réalise l'échange OAuth. Si cette URL est renseignée, elle est prioritaire.
Déclarez l'**URL de redirection** affichée dans le panneau de connexion au niveau des _Redirect URIs_ de votre application Stripe Connect, sinon l'autorisation OAuth sera refusée.
## Configuration Stripe (Dashboard)
### Webhook
En mode manuel, créez le point de terminaison dans **Développeurs > Webhooks > Ajouter un endpoint** :
- **URL** : celle affichée en haut de la page de configuration du module (`.../module/dfexpresscheckout/webhook`).
- **Événements** : `payment_intent.succeeded` et `payment_intent.payment_failed`.
- Copiez le **secret de signature** (`whsec_…`) dans la configuration du module.
En mode automatique, le webhook et son secret sont créés automatiquement lors de la connexion.
Sans secret de webhook configuré, le module refuse les appels entrants : c'est une mesure de sécurité, la commande n'est jamais créée sur la base d'un appel non vérifié.
### Activer les portefeuilles
- **Amazon Pay** : activez-le dans **Paramètres > Moyens de paiement** de votre Dashboard Stripe. Il apparaît ensuite automatiquement dans l'Express Checkout Element.
- **Apple Pay** : votre domaine doit être vérifié dans Stripe (**Paramètres > Apple Pay**). En mode automatique, le module tente cet enregistrement pour vous.
- **Google Pay** : actif automatiquement, aucune action requise.
## Configuration du module
### Emplacements d'affichage
Trois interrupteurs contrôlent l'affichage des boutons : **fiche produit**, **panier** et **checkout**. Activez-les indépendamment selon votre stratégie.
### Mode de capture
- **Capture immédiate** (par défaut) : le paiement est encaissé tout de suite et la commande passe à « Paiement accepté ».
- **Autorisation puis capture manuelle** : Stripe autorise le paiement sans l'encaisser ; la commande arrive dans l'état « Paiement autorisé (en attente de capture) ».
### Intitulé et thème
Personnalisez l'**intitulé affiché** au-dessus des boutons et le **thème des boutons** (noir, blanc, blanc contour) pour l'accorder à votre design.
## Côté client
Selon l'emplacement, le client voit un ou plusieurs boutons wallet. Il confirme le paiement en une authentification (Face ID, empreinte, mot de passe Amazon), sans créer de compte : l'e-mail ainsi que les adresses de livraison et de facturation sont récupérés depuis le portefeuille. Lorsque des frais de port s'appliquent, le module propose les transporteurs actifs et **recalcule le total** à chaque changement d'adresse. Les produits dématérialisés fonctionnent sans étape de livraison.
Depuis la fiche produit, l'achat express porte sur le produit affiché (et la quantité choisie) via un panier dédié, sans modifier le panier courant du client.
## Capture manuelle : encaisser ou annuler
En mode de capture manuelle, le pilotage se fait par le statut de commande :
- Pour **capturer** le paiement, passez la commande au statut **« Paiement accepté »**.
- Pour **libérer l'autorisation**, passez la commande au statut **« Annulé »**.
Une autorisation Stripe a une durée de vie limitée (généralement 7 jours). Pensez à capturer avant expiration, sinon l'autorisation est libérée automatiquement.
## Commandes, webhook et idempotence
La commande est créée et validée à la réception de l'événement `payment_intent.succeeded` (webhook signé). Un contrôleur de retour sert de filet de sécurité lorsque le client revient sur la boutique. Une table de transactions relie chaque PaymentIntent à sa commande : une même transaction ne génère donc jamais deux commandes, quel que soit l'ordre d'arrivée du retour navigateur et du webhook. Le client invité et ses adresses sont reconstitués à partir des informations renvoyées par le portefeuille.
## Multilingue et multi-boutique
Le module est fourni avec des fichiers de traduction FR, EN, ES, DE, IT et fonctionne en contexte multi-boutique. Les clés Stripe, le mode de connexion et le mode de capture sont des réglages de configuration standard.
## Dépannage
### Les boutons ne s'affichent pas
Vérifiez que la boutique est en HTTPS, que les clés Stripe sont renseignées pour le mode actif (Test/Live), et que l'emplacement concerné est activé. Apple Pay n'apparaît que sur Safari/iOS avec un domaine vérifié ; Google Pay sur Chrome/Android.
### Le paiement réussit mais aucune commande n'est créée
Contrôlez le webhook : URL correcte, événements `payment_intent.succeeded` et `payment_intent.payment_failed`, et secret de signature identique à celui du module. Consultez les journaux Stripe (tentatives de livraison du webhook) et les logs PrestaShop.
### Amazon Pay est absent
Il doit être activé dans **Paramètres > Moyens de paiement** du Dashboard Stripe. Il apparaît ensuite automatiquement.
### La connexion automatique échoue
Vérifiez que le `client_id` Connect est renseigné pour le mode actif et que l'URL de redirection du module est bien déclarée dans votre application Connect. Un jeton d'état invalide indique une session expirée : relancez la connexion depuis le back-office.
## Désinstallation
La désinstallation retire la configuration du module. La table de suivi des transactions est conservée par défaut pour la traçabilité des commandes passées.
## FAQ
### Amazon Pay fonctionne-t-il vraiment via Stripe ?
Oui. Stripe prend en charge Amazon Pay au sein de l'Express Checkout Element ; il suffit de l'activer dans le Dashboard Stripe.
### Faut-il installer des dépendances (Composer) ?
Non. Le module embarque un client Stripe interne en cURL. Il suffit d'installer le module et de renseigner (ou connecter) vos clés.
### Le module est-il compatible PrestaShop 9 ?
Oui, il est compatible PrestaShop 8.0 à 9.x et testé sur PHP 8.1 à 8.3.
### Puis-je passer du mode manuel au mode automatique ?
Oui, à tout moment depuis la configuration. En mode automatique, les clés sont renseignées par la connexion OAuth ; en mode manuel, vous les saisissez vous-même.
---
### Facebook Dynamic Ads + Pixel PRO — Guide complet
_Source :_
> Présentation Facebook Dynamic Ads + Pixel PRO connecte votre catalogue PrestaShop à Facebook et Instagram. Le module exporte un flux produits de haute qualité (XML au format Facebook RSS ou…
## Présentation
Facebook Dynamic Ads + Pixel PRO connecte votre catalogue PrestaShop à Facebook et Instagram. Le module exporte un flux produits de haute qualité (XML au format Facebook RSS ou CSV), installe le pixel Facebook sur votre boutique et active l'API Conversions pour un suivi fiable côté serveur. Il génère un flux distinct par combinaison Pays / Langue / Devise, offre un contrôle fin des données exportées (exclusions, libellés personnalisés, mapping des catégories Google) et est conçu pour les catalogues volumineux jusqu'à 200 000 produits.
Compatible PrestaShop 8.0 à 9.x, PHP 7.4 à 8.3, multiboutique et multilingue. `cURL` est requis pour l'API Conversions. Aucune dépendance Composer en production.
## Installation
1. Dans votre back-office, ouvrez **Modules → Gestionnaire de modules → Installer un module**.
2. Uploadez le fichier `dffbadspixel.zip`.
3. Le module s'installe et crée automatiquement ses tables (`dffbadspixel_exclusion`, `dffbadspixel_label`, `dffbadspixel_capi_queue`) ainsi que l'onglet d'administration **Facebook Dynamic Ads + Pixel**.
Un jeton de sécurité (token) unique est généré à l'installation. Il sécurise les URLs du flux et du CRON, et s'affiche dans l'onglet **URLs & CRON** du module.
## Onglet Flux produits
C'est le cœur du module. Vous y choisissez le format et le mode de génération, la sélection des produits et le détail des données exportées.
### Format et génération
- **Format** — XML (Facebook RSS + namespace Google), CSV, ou les deux.
- **Mode de génération** — _À la volée_ (streaming à chaque appel de l'URL) ou _CRON_ (fichiers mis en cache, recommandé pour les gros catalogues).
- **Compression gzip**, **taille de lot** (chunking) et **pays activés uniquement** pour optimiser les performances.
### Sélection et granularité
- **Exporter par** catégorie ou par marque, avec sélection fine (un champ de filtre facilite la recherche dans la liste).
- **Granularité** par produit ou par déclinaison.
- **Construction de l'ID de flux** : ID back-office (avec option langue et/ou déclinaison), référence ou EAN.
- **Type de description** (courte/longue), **disponibilité** (selon le stock ou toujours en stock), **couleurs**, **tailles**, images additionnelles ou **image de couverture uniquement**.
### Frais de port, tracking et qualité
- **Frais de port réels** calculés via vos transporteurs PrestaShop (zone, plages poids/prix), transporteur de référence ou le moins cher, avec franco de port paramétrable.
- **Paramètres UTM** et intégration **GA4**.
- **Limites qualité** : longueurs maximales de titre et de description utilisées par le validateur (onglet Diagnostic).
### Exclusions générales
Directement sous l'onglet Flux : exclure les produits hors stock, sans EAN/MPN, ou en dessous d'un prix minimum.
## Exclusions avancées
Dans l'onglet **Exclusions**, ajoutez des règles ciblées pour écarter certains produits du flux. Chaque règle repose sur un type et une valeur :
- **Mot / expression** — exclut si le nom ou la description contient le terme.
- **Produit**, **Déclinaison**, **Fournisseur** — par ID.
- **Valeur de caractéristique** ou **Attribut** — par ID.
## Libellés personnalisés et tags vestimentaires
Les **libellés personnalisés** (`custom_label_0` à `custom_label_4`) enrichissent la segmentation de vos campagnes : nom de catégorie, valeur d'une caractéristique, tranche de prix, ou labels « nouveau » / « meilleure vente ».
L'onglet **Tags vestimentaires** ajoute les champs Meta dédiés au prêt-à-porter : `age_group`, `gender`, ainsi que `pattern` (motif) et `material` (matière) mappés sur des caractéristiques produit.
## Mapping des catégories & devises
Dans l'onglet **Mapping & devises**, associez vos catégories PrestaShop aux catégories Google/Facebook :
- **Import CSV** au format `id_category;google_category` (séparateur `;` ou `,`, en-tête optionnel).
- **Import depuis un autre module** DataFirefly installé (version standard, Google Merchant Center, GMC Pro ou TikTok Ads).
- **Suggestion automatique par mots-clés** — remplit les correspondances vides à partir du nom de catégorie.
- Édition manuelle ligne par ligne, avec filtre de recherche.
La **table Devise / Pays** définit la devise utilisée pour chaque pays lors de la génération des flux multi-pays. Sans association, la devise par défaut de la boutique est utilisée.
Commencez sans mapping catégories : Meta accepte le flux sans `google_product_category`. Ajoutez-le progressivement sur vos catégories principales pour améliorer la diffusion.
## Pixel Facebook
Dans l'onglet **Pixel**, activez le pixel et renseignez votre **ID de pixel**. Le module injecte le code de base (PageView) et les événements contextuels : ViewContent, ViewCategory, Search, InitiateCheckout, AddToCart et AddToWishlist.
- **Correspondance avancée** (advanced matching) — envoie des informations client supplémentaires, hachées en SHA-256, pour améliorer vos audiences.
- **Sélecteurs HTML personnalisables** pour les boutons « liste d'envie » et « commander », utiles si votre thème a modifié le balisage par défaut.
- **Montant Purchase configurable** : avec ou sans taxe, avec ou sans frais de port et/ou d'emballage.
## API Conversions (asynchrone)
L'API Conversions envoie les événements directement depuis votre serveur et récupère les conversions que le pixel seul ne détecte pas (bloqueurs, cookies). Dans l'onglet **API Conversions** :
1. Activez l'API Conversions et collez le **token d'accès** généré dans votre Business Manager Meta.
2. Laissez le **mode asynchrone** activé (recommandé) : les événements sont mis en file d'attente puis envoyés par lots via le CRON, sans ralentir la boutique.
3. Ajustez la **taille de lot** et le nombre de **tentatives max** (retry) si besoin. Un **code d'événement test** permet de valider l'intégration dans le Business Manager.
Les événements sont dédupliqués avec le pixel navigateur grâce à un `event_id` partagé (par exemple `order-1234` pour un achat). Les données utilisateur sont hachées SHA-256 avant envoi.
## URLs du flux et tâche CRON
L'onglet **URLs & CRON** affiche l'URL de base du flux, l'URL du CRON et la liste des URLs par combinaison Pays / Langue / Devise.
### URL du flux
```
https://votre-boutique.com/index.php?fc=module&module=dffbadspixel&controller=feed&token=VOTRE_TOKEN&id_lang=1&id_currency=1&id_country=8&format=xml
```
Les paramètres `id_lang`, `id_currency`, `id_country` et `format` (`xml` ou `csv`) sélectionnent le flux à servir. C'est cette URL que vous déclarez comme source de flux dans le catalogue Meta.
### Tâche CRON
En mode CRON, programmez l'appel de l'endpoint pour (re)générer les fichiers en cache et vider la file de l'API Conversions :
```
*/30 * * * * curl -s "https://votre-boutique.com/index.php?fc=module&module=dffbadspixel&controller=cron&token=VOTRE_TOKEN" > /dev/null
```
Le paramètre optionnel `job` cible une tâche précise : `feeds` (génération des flux), `capi` (envoi de la file API Conversions) ou `all` (défaut). La réponse est un récapitulatif texte.
## Diagnostic : aperçu et validation
L'onglet **Diagnostic** réunit deux outils :
- **File d'attente API Conversions** — nombre d'événements en attente, en échec et envoyés.
- **Aperçu & validation du flux** — génère un échantillon XML et un rapport qualité signalant les lignes problématiques : image manquante, GTIN invalide (vérifié par chiffre de contrôle), titre ou description trop longs, identifiant produit insuffisant.
## Sécurité
Dans l'onglet **Sécurité** :
- **Liste d'IP autorisées** — restreint l'accès au flux et au CRON à certaines adresses ou plages CIDR (par exemple les serveurs Meta). Vide = aucune restriction.
- **Rotation du token** — régénère le token des URLs. L'ancien reste toléré jusqu'à invalidation, le temps de mettre à jour vos flux dans Meta.
Après une rotation de token, pensez à mettre à jour vos sources de flux dans le Business Manager, puis à invalider l'ancien token depuis l'onglet Sécurité pour fermer la fenêtre de transition.
## Dépannage
### Le flux renvoie « Forbidden »
Le token est absent, incorrect, ou l'IP appelante n'est pas dans la liste autorisée. Vérifiez le token dans l'onglet URLs & CRON et videz la liste d'IP autorisées le temps du test.
### Le flux est vide ou incomplet
Vérifiez la sélection de catégories/marques (vide = tout le catalogue), les règles d'exclusion, et le stock si l'exclusion « hors stock » est active. En mode CRON, lancez d'abord la tâche `job=feeds` pour générer le cache.
### Les événements API Conversions n'arrivent pas dans Meta
Assurez-vous que `cURL` est disponible, que le token d'accès est valide, et exécutez la tâche `job=capi`. Suivez la file dans l'onglet Diagnostic ; les erreurs sont journalisées dans **Paramètres avancés → Logs** avec le préfixe `[dffbadspixel]`.
### Le pixel ne se déclenche pas sur un bouton
Si votre thème a modifié le balisage, ajustez les sélecteurs HTML « liste d'envie » et « commander » dans l'onglet Pixel.
## Bonnes pratiques
- Utilisez le **mode CRON + gzip** pour les catalogues volumineux : la génération à la volée reste possible mais plus coûteuse à chaque appel.
- Activez **pixel et API Conversions ensemble** : la déduplication par `event_id` évite le double comptage tout en améliorant la couverture.
- Renseignez le **mapping des catégories Google** et les **GTIN** pour maximiser l'éligibilité de vos produits aux placements Advantage+ et Shopping.
---
### Factur-X — Guide complet (PrestaShop 8 & 9)
_Source :_
> Ce guide couvre l'installation, la configuration et l'utilisation du module DataFirefly Factur-X (dffacturx) pour PrestaShop 8 et 9. Le module transforme vos commandes en factures électroniques hybrides au format Factur-X…
Ce guide couvre l'installation, la configuration et l'utilisation du module **DataFirefly Factur-X** (`dffacturx`) pour PrestaShop 8 et 9. Le module transforme vos commandes en factures électroniques hybrides au format Factur-X : un PDF/A-3b lisible et imprimable qui contient, embarquées à l'intérieur, les données structurées de la facture au format XML CII (norme EN 16931).
## Présentation
Une facture Factur-X est un fichier unique qui réunit deux usages. Votre client ouvre un PDF classique, qu'il peut lire, imprimer et archiver. Son logiciel comptable, ou la plateforme qui traite la facture, lit directement le XML embarqué sans avoir à interpréter l'image. Il n'y a plus deux fichiers à synchroniser, donc plus de risque d'écart entre ce qui est affiché et ce qui est traité.
Le module couvre la **génération** de ces fichiers : il produit le XML, rend le PDF et embarque l'un dans l'autre avec les métadonnées attendues. La transmission via une Plateforme Agréée est une couche distincte, détaillée dans la section sur la portée réglementaire.
## Prérequis
- PrestaShop 8.0 à 9.x
- PHP 7.4 minimum, 8.1 ou supérieur recommandé
- TCPDF, fourni d'origine avec PrestaShop — aucune installation supplémentaire
- Extensions PHP : `dom` (construction du XML), `zlib` (lecture des métadonnées XMP compressées), `zip` (génération en masse)
Le module n'utilise pas Composer. Les classes sont chargées par un autoloader PSR-4 manuel embarqué, ce qui évite tout conflit de dépendances avec votre installation.
## Installation
1. Dans le back-office, allez dans **Modules → Gestionnaire de modules → Installer un module**.
2. Déposez le fichier `dffacturx.zip`. Vous pouvez aussi copier le dossier `dffacturx` directement dans le répertoire `modules/` de votre boutique.
3. Lancez l'installation. Le module enregistre ses hooks et crée un onglet **Factur-X** sous le menu **Commandes**.
4. Ouvrez la configuration et renseignez l'identité du vendeur _avant_ de générer votre première facture.
## Configuration
### Identité du vendeur
C'est l'étape obligatoire. Ces informations alimentent à la fois le PDF visible et le XML structuré. Sans elles, le XML sera rejeté par un validateur.
- **Raison sociale** — pré-remplie avec le nom de votre boutique, à corriger si votre dénomination légale diffère.
- **SIREN** — 9 chiffres, sans espaces. Indispensable : il est transmis dans le XML avec l'identifiant de schéma adéquat.
- **SIRET** — 14 chiffres, optionnel mais recommandé.
- **N° de TVA intracommunautaire** — indispensable si vous êtes assujetti (ex. `FR12345678901`).
- **Forme juridique** et **capital social** — affichés dans les mentions légales en pied de facture.
- **Adresse, code postal, ville, pays** — le pays est attendu au format ISO à deux lettres (ex. `FR`).
- **Contact, téléphone, email** — repris dans le XML sur les profils EN 16931 et supérieurs.
Tant que le SIREN n'est pas renseigné, un bandeau d'avertissement s'affiche sur la fiche commande. La génération reste possible, mais le fichier produit ne passera pas un contrôle de conformité.
### Profil Factur-X
Le profil détermine le niveau de détail du XML et l'identifiant de spécification qui y est inscrit. Le module l'ajuste automatiquement selon votre choix.
- **EN 16931** — recommandé. Correspond au socle complet de la norme européenne, accepté partout.
- **BASIC** — XML plus léger, conserve le détail des lignes.
- **EXTENDED** — profil étendu, pour les cas nécessitant des données supplémentaires.
- **MINIMUM** et **BASIC WL** — profils sans détail de lignes, réservés à des usages spécifiques.
### Options
- **Téléchargement client** — active un lien dans l'espace compte. Le module vérifie que la commande appartient bien au client connecté avant de servir le fichier.
- **Génération automatique** — si vous renseignez un identifiant d'état de commande, une facture est générée et enregistrée dans le dossier `generated` du module dès qu'une commande atteint cet état. Les erreurs éventuelles sont écrites dans les logs PrestaShop sans bloquer le changement de statut.
## Générer une facture
### Depuis la fiche commande
Ouvrez une commande dans le back-office : un panneau **Factur-X** apparaît en bas de la page principale. Il rappelle le profil actif et propose deux boutons — **Télécharger PDF Factur-X** pour le fichier hybride complet, et **Télécharger XML** pour le XML seul, utile lors des phases de test et de validation.
### Génération en masse
Le menu **Commandes → Factur-X** affiche la liste de vos commandes avec, sur chaque ligne, un accès direct au PDF et au XML. Pour traiter un lot, cochez les commandes concernées et choisissez l'action groupée **Télécharger les Factur-X (ZIP)** : le module assemble toutes les factures dans une archive. Si une commande échoue, elle est ignorée et l'erreur est journalisée — l'archive reste exploitable.
### Côté client
Si l'option est activée, un lien **Mes factures Factur-X** apparaît dans l'espace compte. Le contrôleur front vérifie que le client est connecté et que la commande lui appartient, sinon il redirige vers l'historique des commandes.
## Ce que contient le fichier généré
Le PDF produit est un PDF/A-3b rendu par le TCPDF de PrestaShop. Le module y ajoute ensuite, par **mise à jour incrémentale**, les éléments qui en font une facture Factur-X :
- un objet fichier embarqué contenant le XML, nommé `factur-x.xml` ;
- une entrée dans le tableau des fichiers associés du catalogue, avec la relation `Data` ;
- une entrée dans le dictionnaire des fichiers embarqués nommés ;
- des métadonnées XMP décrivant le type de document, le nom du fichier, la version et le niveau de conformité, accompagnées du schéma d'extension PDF/A correspondant.
La mise à jour incrémentale ajoute ces objets à la fin du fichier sans modifier un seul octet du document rendu. Les polices, les flux de contenu et le profil colorimétrique produits par TCPDF restent intacts — et le module ne dépend d'aucun détail interne de TCPDF, donc d'aucune version particulière.
Le XML est un `CrossIndustryInvoice` UN/CEFACT. Il contient le contexte du document avec l'identifiant de spécification du profil, l'en-tête de facture, les lignes le cas échéant, l'accord commercial (vendeur et acheteur), la livraison, et le règlement avec la ventilation TVA, les remises, les charges et le récapitulatif monétaire.
## Modélisation comptable
Les validateurs Factur-X ne comparent pas vos totaux à ceux de PrestaShop : ils vérifient que le document est _cohérent avec lui-même_. Le module recalcule donc l'ensemble des montants à partir des lignes et de la ventilation TVA, afin de satisfaire les règles d'équilibre de la norme.
- **Lignes** — le prix unitaire net est déduit du total ligne divisé par la quantité. L'unité utilisée est le code unité générique.
- **Frais de port** — modélisés en charge au niveau du document, avec leur propre taux de TVA.
- **Remises** — modélisées en allowance au niveau du document, réparties proportionnellement sur les différentes bases de TVA.
- **Ventilation TVA** — une occurrence par taux rencontré, avec base, montant et catégorie.
- **Catégorie TVA** — catégorie standard si le taux est supérieur à zéro, catégorie zéro sinon.
- **Acompte** — le montant prépayé est à zéro et le net à payer égale le total TTC : la facture est émise, la totalité reste due au sens du document.
Un écart d'un centime avec les totaux affichés par PrestaShop est possible dans des cas d'arrondi limites. C'est attendu : la cohérence interne du document prime, et c'est elle que contrôlent les validateurs.
Les cas de TVA particuliers — exonération, autoliquidation, livraison intracommunautaire — ne sont pas dérivés automatiquement. Si votre activité les implique, faites valider quelques factures représentatives et adaptez la catégorie utilisée.
## Valider avant la mise en production
Cette étape n'est pas optionnelle. Générez quelques factures représentatives de votre activité — une commande simple, une commande avec remise, une commande à plusieurs taux de TVA — puis contrôlez-les avec :
- le validateur de la **FNFE-MPE**, référence française pour Factur-X ;
- **Mustangproject**, validateur open source pour la conformité EN 16931 ;
- **veraPDF**, pour la conformité du conteneur PDF/A-3.
Le bouton de téléchargement du XML seul est fait pour cette phase : il vous évite d'extraire manuellement la pièce jointe du PDF à chaque essai.
## Portée réglementaire
La réforme française de la facturation électronique suit un calendrier en deux temps. Au **1er septembre 2026**, toutes les entreprises assujetties à la TVA doivent pouvoir _recevoir_ des factures électroniques, et les grandes entreprises et ETI doivent en _émettre_. Au **1er septembre 2027**, l'obligation d'émission s'étend aux PME, TPE et micro-entreprises. La plupart des marchands PrestaShop doivent donc recevoir dès 2026 et émettre à partir de 2027.
Trois rôles doivent être distingués :
- **Générer** des fichiers Factur-X conformes — ce que fait ce module. Aucune certification ni immatriculation n'est requise.
- **Transmettre** les factures via une Plateforme Agréée (anciennement PDP). Le marchand choisit sa plateforme et lui remet les fichiers.
- **Être** une Plateforme Agréée — activité soumise à immatriculation par l'État, hors périmètre du module.
Installer ce module ne suffit pas, à lui seul, à vous mettre en conformité complète avec la réforme. Il produit le format attendu, ce qui est le socle indispensable, mais la transmission via une plateforme reste à organiser de votre côté.
## Dépannage
### Le validateur rejette le XML
Vérifiez d'abord l'identité du vendeur, en particulier le SIREN et le numéro de TVA : ce sont les causes de rejet les plus fréquentes. Contrôlez ensuite l'adresse de facturation du client — un pays ou un code postal manquant peut également faire échouer la validation.
### Message indiquant que TCPDF est indisponible
Le module utilise la classe TCPDF fournie par PrestaShop et, à défaut, tente de la charger depuis le répertoire des outils. Si l'erreur persiste, c'est que la bibliothèque a été retirée de votre installation : restaurez-la depuis une archive PrestaShop de la même version.
### L'action groupée ZIP est indisponible
L'extension PHP `zip` n'est pas activée sur le serveur. Le téléchargement unitaire depuis chaque fiche commande reste disponible sans elle.
### La génération automatique ne produit rien
Vérifiez que l'identifiant d'état de commande est bien renseigné dans la configuration, puis que le dossier `generated` du module est accessible en écriture. Les erreurs de génération sont consignées dans les logs PrestaShop avec le préfixe `Factur-X`.
### Le PDF s'ouvre mais la pièce jointe n'apparaît pas
Tous les lecteurs n'affichent pas le panneau des pièces jointes par défaut. Ouvrez le volet dédié de votre lecteur PDF, ou utilisez le téléchargement du XML seul pour contrôler son contenu.
## Architecture
Le module suit une organisation classique, avec un autoloader PSR-4 manuel dont la racine de namespace DataFirefly/FacturX pointe vers le dossier `src`.
- `src/Builder` — définition des profils et construction du XML CII.
- `src/Pdf` — rendu du PDF/A-3b et embarquement du XML.
- `src/Service` — extraction des données de commande et orchestration.
- `src/Install` — installation, onglet d'administration et hooks.
- `controllers/admin` et `controllers/front` — contrôleurs de téléchargement back-office et front-office.
L'architecture repose sur `ModuleAdminController` et Smarty, identiques entre PrestaShop 8 et 9, sans branche de code séparée ni dépendance Symfony spécifique.
## Changelog
### 1.0.0 — 4 juin 2026
- Génération de factures hybrides Factur-X : PDF/A-3b avec XML CII embarqué.
- Profils BASIC, EN 16931 et EXTENDED sélectionnables.
- Construction du XML CII conforme UN/CEFACT avec ventilation TVA par taux.
- Embarquement autonome du XML par mise à jour incrémentale du PDF.
- Métadonnées XMP Factur-X et schéma d'extension PDF/A injectés.
- Identité vendeur entièrement paramétrable.
- Téléchargement PDF et XML sur la fiche commande, génération en masse en ZIP.
- Lien de téléchargement dans l'espace client, activable.
- Génération automatique optionnelle au passage d'un statut de commande.
- Compatible PrestaShop 8.0 à 9.0 sans branche de code séparée.
---
### Facturation Récapitulative B2B — Documentation
_Source :_
> Présentation Facturation Récapitulative regroupe toutes les commandes d'un client professionnel sur une période (le mois écoulé, par défaut) en une seule facture consolidée. Au lieu d'une facture par commande, vos…
## Présentation
Facturation Récapitulative regroupe toutes les commandes d'un client professionnel sur une période (le mois écoulé, par défaut) en une seule facture consolidée. Au lieu d'une facture par commande, vos clients B2B reçoivent une facture mensuelle unique, numérotée en séquence, avec la ventilation de TVA par taux et le détail commande par commande. Le module génère le PDF via le moteur natif de PrestaShop, l'envoie par email et retire au passage les factures individuelles des emails de commande adressés aux clients professionnels.
Les factures PrestaShop individuelles ne sont jamais supprimées : elles restent générées et disponibles dans votre back-office et dans l'historique de commande. Seul l'email envoyé au client B2B est allégé de son PDF individuel.
## Installation
Installez le module comme n'importe quel module PrestaShop, depuis **Modules > Module Manager > Téléverser un module**, en envoyant le fichier ZIP. À l'installation, le module crée ses tables, son onglet d'administration et une valeur de jeton (token) aléatoire pour le cron. Aucune dépendance Composer n'est requise.
## Configuration
Rendez-vous dans **Modules > Module Manager**, puis cliquez sur **Configurer** en face de Facturation Récapitulative. La page de configuration regroupe tous les réglages.
### Groupes de clients B2B
Cochez le ou les groupes de clients considérés comme professionnels. Seuls les clients appartenant à ces groupes voient leurs commandes consolidées, reçoivent la facture récapitulative et accèdent à l'espace « Mes factures récapitulatives ». C'est ce réglage qui définit votre périmètre B2B.
### États de commande inclus
Sélectionnez les états de commande qui rendent une commande éligible à la consolidation (par défaut : paiement accepté, préparation en cours, expédié, livré). Une commande dont l'état courant ne figure pas dans cette liste est ignorée à la génération.
### Jour de génération
Choisissez le jour du mois (de 1 à 28) auquel le cron déclenche la génération du mois précédent. Un jour compris entre 1 et 28 garantit que la date existe dans tous les mois.
### Préfixe et numérotation
Définissez le préfixe de numérotation (par défaut `REC`). Les factures récapitulatives sont numérotées en séquence au format `PREFIXE-AAAA-00042`, via un compteur dédié. Les numéros ne sont jamais réutilisés, même après suppression d'une facture.
### Envoi automatique et nettoyage des emails
Deux interrupteurs pilotent le comportement d'envoi :
- **Envoi automatique par email** : à la génération (cron ou manuelle), la facture récapitulative est envoyée au client avec le PDF joint.
- **Retirer la facture individuelle des emails de commande** : pour les clients B2B, le PDF de facture individuelle est retiré des emails de commande, afin de ne conserver qu'un envoi propre — la facture récapitulative mensuelle.
### Mentions légales et conditions de paiement
Deux zones de texte multilingues vous permettent de personnaliser les mentions légales (par défaut, un rappel de l'article 289 I-3 du CGI relatif à la facture périodique récapitulative) et les conditions de paiement affichées en pied de facture. Ces textes sont saisissables dans chacune des langues de la boutique.
## Automatisation par cron
La génération automatique s'appuie sur une URL de cron protégée par un jeton. Récupérez l'URL complète (jeton inclus) dans le panneau d'information de la page de configuration, puis programmez-la dans le planificateur de tâches de votre serveur. Exemple d'entrée crontab pour un déclenchement quotidien :
```
0 6 * * * wget -q -O /dev/null "https://votreboutique.tld/module/dfdeferredinvoicing/cron?token=VOTRE_TOKEN"
```
Le cron est **idempotent** : il ne génère la facture d'un client que si elle n'existe pas déjà pour la période. Vous pouvez donc l'exécuter chaque jour sans risque — seul le jour de génération configuré déclenche réellement le traitement du mois précédent.
### Paramètres optionnels
- `&force=1` : force la génération quel que soit le jour du mois.
- `&month=6&year=2026` : cible une période précise (utile pour rejouer un mois passé).
La réponse est renvoyée au format JSON, avec le nombre de clients traités, de factures créées et de commandes consolidées.
Pour tester immédiatement, ouvrez l'URL du cron avec `&force=1` dans votre navigateur : vous obtiendrez le récapitulatif JSON de la génération sans attendre le jour programmé.
## Utilisation au quotidien
### Onglet « Factures récapitulatives »
Un onglet **Factures récapitulatives** est ajouté sous **Commandes**. Il liste toutes les factures récapitulatives générées, avec le numéro, le client, la période, le nombre de commandes, le total TTC et l'état d'envoi de l'email. Chaque ligne propose de télécharger le PDF, de renvoyer l'email ou de supprimer la facture.
### Génération manuelle
En haut de cet onglet, un panneau permet de générer manuellement une période (mois et année, pré-remplis sur le mois précédent) pour l'ensemble des clients B2B ou pour un client précis. C'est utile pour un rattrapage ponctuel ou pour émettre la facture d'un client à la demande.
### Espace client
Les clients professionnels disposent d'un lien « Mes factures récapitulatives » dans leur compte, où ils retrouvent et téléchargent l'ensemble de leurs factures consolidées. Ce lien n'apparaît que pour les clients appartenant aux groupes B2B configurés.
## Ce que contient la facture récapitulative
Chaque facture reprend : les coordonnées de la boutique et l'adresse de facturation du client (raison sociale, numéro de TVA), le détail commande par commande (date, référence, numéro de facture PrestaShop d'origine, montant), la ventilation de TVA par taux (produits et frais de port), avec une ligne d'ajustement d'arrondi si un écart minime apparaît, puis les totaux HT / TVA / TTC, et enfin vos conditions de paiement et mentions légales.
Les commandes sont regroupées par devise : un client ayant commandé dans deux devises différentes sur la même période reçoit une facture récapitulative par devise.
## Garanties et limites
- **Anti-doublon** : chaque commande est enregistrée dans une table de liaison où elle est unique. Une commande déjà consolidée ne peut jamais être reprise dans une autre facture récapitulative.
- **Suppression** : supprimer une facture récapitulative libère ses commandes, qui redeviennent éligibles à une nouvelle consolidation. Le numéro supprimé n'est toutefois pas réattribué.
- **Factures individuelles** : elles restent visibles dans l'historique de commande côté client ; seul l'email est allégé. Les masquer casserait la comptabilité PrestaShop.
- **Ventilation TVA** : la répartition par taux est reconstituée à partir des lignes de commande et de la livraison ; elle peut être approximative dans le cas rare où un même produit cumule plusieurs taxes empilées.
## Compatibilité
Facturation Récapitulative est compatible PrestaShop 8.0 à 9.x, en boutique simple comme en multiboutique, sur les cinq langues du catalogue (français, anglais, espagnol, allemand, italien), sans aucune dépendance Composer.
---
### Factures Proforma PDF pour WooCommerce — Documentation
_Source :_
> Présentation Le plugin Factures Proforma PDF pour WooCommerce génère des factures proforma professionnelles au format PDF directement depuis vos commandes WooCommerce. Chaque document reprend automatiquement les produits avec leurs attributs…
## Présentation
Le plugin **Factures Proforma PDF pour WooCommerce** génère des factures proforma professionnelles au format PDF directement depuis vos commandes WooCommerce. Chaque document reprend automatiquement les produits avec leurs attributs (dimensions, options, personnalisations), l'intégralité des totaux WooCommerce (sous-total, expédition, remises, TVA) et vos coordonnées d'entreprise.
Une facture proforma est un document non contractuel remis avant paiement. Elle ne remplace pas la facture définitive.
## Installation
### 1. Installer le plugin
1. Dans votre administration WordPress, allez dans **Extensions → Ajouter → Téléverser une extension**.
2. Sélectionnez l'archive ZIP du plugin puis cliquez sur **Installer maintenant**.
3. Activez le plugin.
### 2. Prérequis
- WordPress 6.0 ou supérieur
- WooCommerce 7.0 ou supérieur (compatible HPOS)
- PHP 8.0 ou supérieur
## Configuration
Les réglages se trouvent dans **WooCommerce → Proforma**, organisés en trois onglets.
### Onglet Entreprise
Renseignez les informations qui apparaîtront dans le bloc émetteur du PDF : logo (via la médiathèque), raison sociale, adresse complète, téléphone, e-mail, numéro de TVA intracommunautaire et SIRET.
### Onglet Document
- **Préfixe numéro** : par exemple `PRO-` donnera PRO-00001, PRO-00002, etc. Le compteur s'incrémente automatiquement et chaque numéro reste attaché à sa commande.
- **Validité** : nombre de jours pendant lesquels la proforma est valable (la date limite est imprimée sur le document).
- **Symbole et position monétaire** : 10,00 € ou € 10,00.
- **Couleur accent** : couleur des bandes, titres et en-têtes de tableau du PDF.
- **Texte pied de page** : mention légale imprimée en bas de chaque page.
### Onglet E-mail
Activez **Joindre automatiquement** pour que la proforma soit attachée aux e-mails de confirmation de commande (nouvelle commande, commande en cours, commande en attente).
## Générer une proforma
### Depuis la fiche commande
Une boîte **Facture Proforma** apparaît dans la colonne latérale de chaque commande. Elle permet de générer le PDF, de le télécharger et de le régénérer après modification de la commande. L'action est aussi disponible dans le menu déroulant _Actions de commande_.
### Depuis la liste des commandes
- **Colonne dédiée** : une icône indique si une proforma existe (bleue) ou non (grise) ; un clic la télécharge ou la génère.
- **Action groupée** : cochez plusieurs commandes puis choisissez _Générer proforma(s)_ pour un traitement en masse.
Après modification d'une commande (ajout de produit, remise), utilisez le bouton **Régénérer** pour mettre à jour le PDF : le numéro proforma reste identique.
## Contenu du PDF
- Blocs émetteur / destinataire avec adresses complètes
- Tableau des produits avec référence, désignation et **attributs produits** (dimensions, options de personnalisation…)
- Totaux complets identiques à WooCommerce : sous-total, expédition, remises et coupons, TVA, total TTC
- Mode de paiement et notes client (optionnel)
- Numérotation, date d'émission et date de validité
## Stockage et sécurité
Les PDF sont enregistrés dans `wp-content/uploads/df-proforma/`, un dossier protégé contre le listage. Seuls les utilisateurs disposant de la capacité `manage_woocommerce` peuvent générer ou télécharger les documents.
## Questions fréquentes
### Le PDF ne se génère pas
Vérifiez que la bibliothèque PDF est bien installée (une notice s'affiche dans l'administration si elle est absente) et que le dossier `uploads` est accessible en écriture.
### Puis-je modifier le numéro d'une proforma existante ?
Le numéro est fixé à la première génération et stocké dans la commande afin de garantir la traçabilité. Régénérer le document conserve le même numéro.
### Les remises et frais de port apparaissent-ils ?
Oui, le document reprend exactement les lignes de totaux calculées par WooCommerce, y compris les livraisons offertes et les coupons.
---
### FAQ IA Produit — Guide complet d'installation et de configuration
_Source :_
> Présentation DataFirefly FAQ IA Produit génère automatiquement des FAQ contextuelles pour vos fiches produits PrestaShop 8 via OpenAI ou Anthropic Claude, avec injection de rich snippets Schema.org FAQPage dans le…
## Présentation
**DataFirefly FAQ IA Produit** génère automatiquement des FAQ contextuelles pour vos fiches produits PrestaShop 8 via OpenAI ou Anthropic Claude, avec injection de rich snippets Schema.org `FAQPage` dans le head pour les résultats enrichis Google. Les FAQ sont stockées en base (table `ps_product_faq`) — aucun appel API n'est effectué côté front-office.
- **Compatibilité :** PrestaShop 8.0 → 8.99, PHP 7.2 → 8.3
- **Multilingue :** FAQ générées et stockées par langue
- **Multi-boutique :** configuration indépendante par sous-boutique
## Installation
1. Dans votre back-office, allez dans **Modules → Gestionnaire de modules → Installer un module**.
2. Téléversez `productfaqai-3.0.0.zip`.
3. Cliquez sur **Installer**, puis **Configurer**.
**Mise à jour depuis la v2.x (module Sash) :** l'upgrade est non destructif. Le schéma de la table `ps_product_faq` est inchangé — vos FAQ existantes sont conservées. Installez simplement la v3.0.0 par-dessus, puis reconfigurez votre clé API dans la nouvelle interface.
## 1. Fournisseur IA & modèle
Premier formulaire de la page de configuration.
- **Fournisseur IA :** OpenAI ou Anthropic Claude. Le module bascule automatiquement vers la bonne API.
- **Clé API OpenAI :** depuis [platform.openai.com](https://platform.openai.com) (commence par `sk-`).
- **Clé API Anthropic :** depuis [console.anthropic.com](https://console.anthropic.com) (commence par `sk-ant-`).
- **Modèle :** pour OpenAI, `gpt-4o-mini` recommandé (le plus économique). Pour Anthropic, `claude-haiku-4-5` recommandé.
- **Nombre de questions :** 1 à 15 (défaut : 5).
- **Température :** 0 = déterministe, 2 = très créatif. Recommandé : 0,7.
- **Max tokens :** longueur maximale de la réponse (défaut : 2000). Augmentez si vous générez plus de 8 questions.
- **Auto-génération :** génère automatiquement la FAQ (langue par défaut) à chaque création de produit.
**Coût indicatif :** une génération de 5 questions coûte ~0,0005 $ avec gpt-4o-mini et ~0,001 $ avec claude-haiku-4-5. 200 produits × 3 langues ≈ 0,30 à 0,60 $ au total.
## 2. Prompt & directives de contenu
Deuxième formulaire — contrôle la qualité et le style des FAQ générées.
- **Ton de voix :** professionnel, amical, décontracté, technique, enthousiaste ou rassurant.
- **Audience cible** (optionnel) : texte libre, ex. « professionnels médicaux B2B », « premiers acheteurs ». L'IA adapte vocabulaire et niveau de détail.
- **Prompt système personnalisé** (optionnel) : remplace intégralement les instructions par défaut. Laissez vide pour utiliser le prompt intégré.
- **Directives additionnelles** (optionnel) : instructions ajoutées au prompt, ex. « toujours mentionner la garantie 2 ans », « éviter le jargon ».
- **Inclure catégorie / fabricant / caractéristiques :** trois interrupteurs qui enrichissent le contexte envoyé à l'IA. Activez « caractéristiques » pour les produits techniques — la précision des réponses s'améliore nettement.
## 3. Affichage & SEO
- **Position d'affichage (hook) :** choisissez parmi 5 emplacements : `displayProductFooter` — sous toute la fiche (défaut, fonctionne partout)
- `displayFooterProduct` — variante selon le thème
- `displayProductAdditionalInfo` — sous le bouton d'achat (plus visible)
- `displayReassurance` — bloc réassurance
- `displayAfterProductThumbs` — sous les miniatures
**Titre FAQ :** un champ par langue de la boutique. Défauts fournis en FR/EN/ES/DE/IT/PT/NL.**Mode accordéon :** activé = questions repliables (première ouverte). Désactivé = toutes les réponses visibles.**Rich snippets JSON-LD :** injecte le balisage Schema.org `FAQPage` dans le head. Recommandé : activé.**Catégories exclues :** IDs séparés par des virgules (ex. `12,45,78`). Les produits de ces catégories sont ignorés en génération de masse.
Le module enregistre les 5 hooks à l'installation mais ne rend le bloc qu'au hook configuré. Si un hook n'existe pas dans votre thème, le bloc ne s'affichera simplement pas — testez avec le hook par défaut d'abord.
## Générer des FAQ
### Génération individuelle
Dans le panneau « Générer des FAQs pour les produits », chaque ligne produit affiche un bouton **Générer**. Sélectionnez d'abord la langue cible dans le menu déroulant en haut du tableau. Le nombre de FAQ existantes par langue est affiché pour chaque produit.
### Génération en masse
- **Générer pour tous les produits (langue actuelle) :** traite tous les produits sans FAQ dans la langue active.
- **Générer pour tous les produits (toutes langues) :** traite toutes les langues actives de la boutique.
- **Forcer la régénération :** cochez cette case pour écraser les FAQ existantes — utile après un changement de prompt, de ton ou de fournisseur.
**Durée :** comptez ~1 produit/seconde par langue (latence API variable). 100 produits × 3 langues ≈ 5 minutes. Ne fermez pas l'onglet pendant le traitement. Les produits des catégories exclues sont automatiquement ignorés.
### Auto-génération
Si activée dans le premier formulaire, chaque nouveau produit (hook `actionProductAdd`) reçoit automatiquement une FAQ dans la langue par défaut de la boutique.
## Éditeur FAQ par produit
Cliquez sur **Modifier FAQs** sur une ligne produit pour ouvrir l'éditeur :
- **Sélecteur de langue** en haut — bascule instantanée entre les langues.
- **Position :** poids numérique, ordre croissant d'affichage.
- **Question / Réponse :** édition directe du texte.
- **Statut :** activer/désactiver une entrée sans la supprimer (une entrée inactive n'apparaît ni sur la fiche ni dans le JSON-LD).
- **Supprimer :** suppression définitive d'une entrée.
- **Ajouter une FAQ :** ajout manuel d'une question/réponse.
Cliquez sur **Enregistrer** pour valider l'ensemble des modifications de la page.
## Rich snippets FAQPage
Quand l'option JSON-LD est active, le module injecte dans le `head` de chaque fiche produit ayant au moins une FAQ active un bloc `application/ld+json` conforme à Schema.org `FAQPage` :
```
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "…",
"acceptedAnswer": { "@type": "Answer", "text": "…" }
}
]
}
```
Vérifiez le balisage avec le [test des résultats enrichis Google](https://search.google.com/test/rich-results). L'apparition dans la SERP dépend de Google et peut prendre plusieurs jours après la réindexation de la page.
## Dépannage
### « Veuillez configurer votre clé API »
La clé du fournisseur sélectionné est vide ou invalide. Vérifiez que la clé correspond bien au fournisseur actif (OpenAI = `sk-…`, Anthropic = `sk-ant-…`).
### Erreurs de génération en masse
Les erreurs API (quota dépassé, clé révoquée, timeout) sont consignées dans **Paramètres avancés → Logs** via PrestaShopLogger. Le compte-rendu de fin de traitement affiche le détail réussites / ignorés / erreurs par langue.
### La FAQ ne s'affiche pas sur la fiche produit
1. Vérifiez que le produit a au moins une FAQ **active** dans la langue consultée.
2. Vérifiez que le hook configuré existe dans votre thème — repassez sur `displayProductFooter` pour tester.
3. Videz le cache PrestaShop (**Paramètres avancés → Performances**).
### Les rich snippets n'apparaissent pas dans Google
Le balisage peut être valide sans que Google l'affiche : l'affichage des résultats enrichis reste à la discrétion de Google. Vérifiez d'abord le balisage avec le test des résultats enrichis, puis patientez le temps de la réindexation.
## Désinstallation
La désinstallation supprime la table `ps_product_faq` (toutes les FAQ générées) et l'ensemble des clés de configuration. Une confirmation est demandée. Exportez vos données au préalable si nécessaire.
---
### FAQ Produit — Accordéon Statique
_Source :_
> Guide d'installation et d'utilisation du module FAQ Produit — Accordéon Statique pour PrestaShop 8 et 9.
## Présentation
Le module **FAQ Produit — Accordéon Statique** ajoute une foire aux questions pliable sous vos fiches produit. Vous saisissez vos questions et réponses à la main depuis le back-office, et le module les affiche dans un accordéon HTML natif, accessible et sans JavaScript. Il injecte également les données structurées `schema.org FAQPage` en JSON-LD pour le SEO et l'AEO.
Besoin de générer automatiquement vos FAQ à partir des caractéristiques produit, des avis et des recherches réelles ? Découvrez la **FAQ IA Produit** de DataFirefly, qui automatise tout le processus en plusieurs langues.
## Installation
1. Téléchargez l'archive `dfstaticfaq.zip` depuis votre compte DataFirefly.
2. Dans le back-office PrestaShop, ouvrez **Modules > Module Manager**, puis cliquez sur **Téléverser un module**.
3. Sélectionnez le fichier ZIP et lancez l'installation.
4. Une fois installé, cliquez sur **Configurer** pour accéder aux réglages.
Le module est compatible PrestaShop 8.0 jusqu'aux versions 9.x, en multiboutique et multilingue. Aucune dépendance front n'est chargée.
## Réglages du module
La page de configuration regroupe trois réglages :
- **Titre du bloc FAQ** — le titre affiché au-dessus de l'accordéon sur la fiche produit. Il est traduisible par langue.
- **Ouverture exclusive** — lorsqu'il est activé, une seule réponse reste ouverte à la fois. Le comportement est natif, sans JavaScript.
- **Données structurées FAQPage (JSON-LD)** — active ou désactive l'injection du balisage `schema.org FAQPage` sur la fiche produit.
Le bouton **Gérer la FAQ** ouvre l'écran de saisie des questions.
## Ajouter et gérer les questions
Depuis l'écran **Gérer la FAQ**, cliquez sur **Ajouter** pour créer une question. Chaque entrée comporte :
- **Question** — le libellé affiché dans l'accordéon (traduisible).
- **Réponse** — le contenu déplié, édité avec un éditeur de texte enrichi (traduisible).
- **ID produit** — l'identifiant du produit ciblé. Laissez `0` pour afficher la question sur toutes les fiches produit.
- **Position** — l'ordre d'affichage croissant.
- **Activé** — affiche ou masque la question sans la supprimer.
**FAQ globale ou ciblée :** une question avec `ID produit = 0` apparaît sur toutes les fiches. Pour une question propre à un produit, renseignez son identifiant. Les deux peuvent coexister sur une même fiche.
### Réorganiser les questions
L'ordre d'affichage est défini par le champ **Position** (croissant). Vous pouvez aussi trier la liste en cliquant sur l'en-tête de la colonne Position.
## Affichage sur la fiche produit
L'accordéon s'affiche automatiquement sous le bloc produit, via le hook `displayFooterProduct`. Il repose sur les éléments `details` et `summary` natifs du HTML : navigation clavier native, aucune dépendance de thème et respect des préférences de mouvement réduit. Une icône plus/moins indique l'état ouvert ou fermé de chaque question.
## Données structurées FAQPage
Quand l'option JSON-LD est activée, le module ajoute sur la fiche produit un script `application/ld+json` décrivant la FAQ au format `schema.org FAQPage`. Les réponses sont nettoyées de leur mise en forme HTML pour produire un JSON valide.
Google réserve désormais l'affichage enrichi des FAQ à certains sites institutionnels. Le balisage reste néanmoins valide et exploitable par les moteurs de réponse et les assistants IA. Vous pouvez le désactiver d'un clic si vous le souhaitez.
## Compatibilité
- **PrestaShop** : 8.0 jusqu'aux versions 9.x
- **Multiboutique** : oui
- **Multilingue** : questions et réponses traduisibles par langue
- **Front** : HTML et CSS natifs, zéro JavaScript
## Passer à la FAQ IA Produit
Ce module repose sur une saisie manuelle. Pour générer automatiquement vos questions et réponses à l'échelle de tout votre catalogue, à partir des caractéristiques produit, des avis et des recherches réelles, optez pour la **FAQ IA Produit** de DataFirefly. La migration ne nécessite aucune perte de contenu.
## Dépannage
- **L'accordéon n'apparaît pas** — vérifiez qu'au moins une question est active et qu'elle est soit globale (`ID produit = 0`), soit rattachée au produit consulté.
- **Les modifications ne s'affichent pas** — videz le cache PrestaShop (**Paramètres avancés > Performances**).
- **Le titre n'est pas traduit** — renseignez le titre du bloc pour chaque langue dans les réglages.
Après la désinstallation, toutes les questions et réponses saisies sont définitivement supprimées. Exportez votre base au préalable si vous souhaitez les conserver.
---
### Fil d'Ariane Pro — Guide complet
_Source :_
> Fil d'Ariane Pro (dfbreadcrumbpro) remplace le fil d'Ariane basique de votre thème par une navigation enrichie : menus déroulants de catégories sœurs sur chaque niveau, données structurées JSON-LD BreadcrumbList conformes…
Fil d'Ariane Pro (`dfbreadcrumbpro`) remplace le fil d'Ariane basique de votre thème par une navigation enrichie : menus déroulants de catégories sœurs sur chaque niveau, données structurées JSON-LD BreadcrumbList conformes aux guidelines Google, et chemin intelligent pour les produits appartenant à plusieurs catégories.
## Installation
1. Rendez-vous dans **Modules > Gestionnaire de modules > Installer un module**.
2. Uploadez l'archive `dfbreadcrumbpro.zip` puis cliquez sur **Installer**.
3. Le module s'enregistre automatiquement sur les hooks `displayHeader`, `displayWrapperTop` et `actionFrontControllerSetMedia`. Aucune manipulation supplémentaire n'est nécessaire.
Le module ne crée aucune table SQL et n'effectue aucun override : la désinstallation supprime simplement ses clés de configuration.
Compatibilité : PrestaShop 8.0 à 9.x, PHP 7.4 à 8.3, multiboutique et multilingue.
## Configuration
Ouvrez **Modules > Gestionnaire de modules**, recherchez « Fil d'Ariane Pro » et cliquez sur **Configurer**. Les options suivantes sont disponibles :
- **Remplacer le fil d'Ariane du thème** (activé par défaut) — masque en CSS le fil rendu par le thème (classes `.breadcrumb` et `.breadcrumb-wrapper`) pour éviter tout doublon visuel.
- **Activer les menus déroulants** (activé par défaut) — affiche les catégories sœurs dans un menu déroulant sur chaque niveau du fil.
- **Afficher les sous-catégories sur le dernier niveau** (désactivé par défaut) — sur les pages catégorie, le dernier menu liste les sous-catégories de la catégorie courante plutôt que ses catégories sœurs. Si la catégorie n'a pas d'enfant, le module revient automatiquement aux catégories sœurs.
- **Stratégie de chemin pour les produits** — voir la section dédiée ci-dessous.
- **Activer le JSON-LD BreadcrumbList** (activé par défaut) — injecte les données structurées schema.org dans la balise head.
- **Afficher le lien Accueil** (activé par défaut) — premier élément du fil pointant vers la page d'accueil.
- **Séparateur** — caractère affiché entre les niveaux (par défaut `›`, 8 caractères maximum).
- **Nombre maximum d'éléments par menu** — plafond des catégories listées dans chaque menu déroulant (par défaut 15, de 1 à 50).
## Stratégies de chemin produit
Quand un produit appartient à plusieurs catégories, le module doit choisir quel chemin afficher. Trois stratégies sont proposées :
### Catégorie par défaut
Le fil utilise la catégorie par défaut du produit (`id_category_default`), c'est-à-dire le comportement PrestaShop classique. Si cette catégorie est désactivée ou non associée à la boutique courante, le module se replie automatiquement sur la catégorie la plus profonde.
### Catégorie la plus profonde
Le fil utilise la catégorie active la plus profonde (plus grand `level_depth`) parmi celles du produit. C'est le chemin le plus spécifique, généralement le plus intéressant pour le SEO puisqu'il maximise le nombre de niveaux et de mots-clés dans le fil et dans le JSON-LD.
### Contextuelle (recommandée, par défaut)
Le module mémorise la dernière catégorie visitée par le client dans un cookie (`dfbcp_last_cat`). Sur une fiche produit, si le produit appartient à cette catégorie, le fil affiche ce chemin : la navigation reflète le parcours réel du visiteur. Sinon, le module se replie sur la catégorie la plus profonde.
Le mode contextuel repose sur un cookie visiteur. Si votre boutique est derrière un cache pleine page très agressif (Varnish sans variation sur les cookies, CDN en mode cache total), le cookie peut être ignoré : préférez alors la stratégie « Catégorie la plus profonde ».
## Menus déroulants
Chaque niveau du fil correspondant à une catégorie affiche un bouton caret. Comportement :
- **Desktop** — ouverture au survol du niveau ou au clic sur le caret.
- **Mobile** — ouverture au tap sur le caret, fil défilable horizontalement sur les petits écrans.
- **Fermeture** — clic en dehors du fil ou touche Échap.
- **Accessibilité** — attributs `aria-haspopup`, `aria-expanded` et `aria-current`, navigation clavier complète.
- **Anti-débordement** — les menus se repositionnent automatiquement pour ne jamais sortir de l'écran.
Les listes de catégories sœurs sont mises en cache par requête et respectent la langue et la boutique courantes. La catégorie active est mise en évidence dans le menu.
## JSON-LD BreadcrumbList
Le module injecte dans la balise head un script `application/ld+json` de type `BreadcrumbList` :
- positions numérotées à partir de 1 ;
- nom et URL pour chaque niveau ;
- dernier élément (page courante) volontairement **sans URL**, conformément aux recommandations Google ;
- jamais émis si le fil compte moins de deux niveaux.
Vous pouvez vérifier la validité du balisage avec le [test des résultats enrichis Google](https://search.google.com/test/rich-results).
Si votre thème génère déjà son propre JSON-LD BreadcrumbList, deux balisages coexisteront et Search Console pourra signaler des doublons. Désactivez soit le balisage du thème, soit l'option JSON-LD du module.
## Pages couvertes
- **Catégories** — chemin complet depuis la racine du catalogue.
- **Fiches produit** — chemin de catégorie selon la stratégie choisie, produit en dernier niveau.
- **Pages CMS** — arborescence des catégories CMS puis titre de la page.
- **Marques et fournisseurs** — page liste puis fiche.
- **Autres pages** (contact, promotions, plan du site…) — repli générique sur le titre meta de la page.
- **Page d'accueil** — aucun fil affiché.
## Multiboutique et multilingue
Toutes les requêtes SQL respectent les associations de la boutique courante (contexte multiboutique) ainsi que la langue du visiteur : noms de catégories, URL réécrites et libellés sont résolus dans la bonne langue. La traduction française du back-office est incluse ; les autres langues se traduisent via **International > Traductions > Traductions des modules installés**.
## Dépannage
### Le fil ne s'affiche pas
Vérifiez que votre thème expose bien le hook `displayWrapperTop` (présent dans le thème Classic et la quasi-totalité des thèmes du marché). Si ce n'est pas le cas, greffez le module sur un hook d'affichage équivalent via **Design > Positions**.
### Deux fils d'Ariane apparaissent
L'option « Remplacer le fil d'Ariane du thème » est désactivée, ou votre thème utilise des classes CSS non standard. Réactivez l'option ou ajoutez une règle CSS ciblant le conteneur du fil de votre thème.
### Le mode contextuel affiche toujours le même chemin
Un cache pleine page ignore probablement le cookie `dfbcp_last_cat`. Basculez sur la stratégie « Catégorie la plus profonde » ou excluez ce cookie de la clé de cache.
### Le menu déroulant est vide sur un niveau
La catégorie n'a pas de catégorie sœur active associée à la boutique courante : le caret n'est simplement pas affiché dans ce cas.
Après toute modification de la configuration, pensez à vider le cache PrestaShop (**Paramètres avancés > Performances**) pour voir les changements en front immédiatement.
## Historique des versions
- **1.0.0** (16/07/2026) — Publication initiale : menus déroulants de catégories sœurs, JSON-LD BreadcrumbList, stratégies par défaut / plus profonde / contextuelle, couverture catégories, produits, CMS, marques et fournisseurs, multiboutique et multilingue.
---
### Filigrane Automatique des Images Produit — Guide complet
_Source :_
> Présentation Le module Filigrane Automatique appose votre logo ou votre nom sur les miniatures de vos images produit, sans intervention manuelle. Le filigrane est appliqué dès qu'une image est ajoutée…
## Présentation
Le module Filigrane Automatique appose votre logo ou votre nom sur les miniatures de vos images produit, sans intervention manuelle. Le filigrane est appliqué dès qu'une image est ajoutée à un produit et lors de chaque régénération des miniatures. Point essentiel : vos fichiers originaux ne sont jamais modifiés. Seules les déclinaisons par type d'image (large, home, catégorie, etc.) sont tamponnées, ce qui garantit qu'une nouvelle régénération repart toujours d'une source propre.
Le module propose deux modes — un logo PNG transparent ou un texte — avec un réglage fin de l'opacité, de la taille, de la position et des formats traités. Il est compatible PrestaShop 1.7, 8 et 9, et ne requiert que l'extension PHP GD, présente sur la quasi-totalité des hébergements.
## Installation
1. Depuis le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez l'archive ZIP du module.
3. Une fois l'installation terminée, cliquez sur **Configurer**.
À l'installation, le module enregistre le hook `actionWatermark` et applique des réglages par défaut prêts à l'emploi (opacité 60 %, position en bas à droite, taille du logo à 25 % de la largeur, tous les types d'images sélectionnés). L'extension GD est vérifiée : si elle est absente, l'installation est interrompue avec un message explicite.
## Configuration
La page de configuration est organisée en trois panneaux : **Type de filigrane**, **Apparence & position** et **Application**. Un aperçu du logo actuellement téléversé est affiché en haut de la page, ainsi qu'un bouton direct vers la régénération des miniatures.
### Type de filigrane
- **Mode** — choisissez entre _Logo (image PNG)_ et _Texte_.
- **Logo du filigrane** — téléversez votre image (PNG transparent recommandé, 4 Mo maximum). Le fichier est converti en PNG pour préserver la transparence. Laissez ce champ vide pour conserver le logo actuel.
- **Supprimer le logo** — cochez cette case pour retirer le logo enregistré.
- **Texte du filigrane** — le texte à incruster en mode Texte (nom de boutique, copyright, URL…).
- **Couleur du texte** — la couleur du texte, en mode Texte.
### Apparence & position
- **Opacité (%)** — de 1 (très transparent) à 100 (opaque).
- **Taille du logo (% largeur image)** — la largeur du logo exprimée en pourcentage de la largeur de l'image. La valeur **0** conserve la taille native du logo. Exprimer la taille en pourcentage permet au filigrane de garder des proportions cohérentes sur tous les formats d'image, de la grande fiche produit à la vignette de catégorie.
- **Taille du texte (% largeur image)** — même principe, pour le mode Texte.
- **Angle du texte (°)** — inclinaison du texte, en mode Texte.
- **Position** — neuf ancrages (haut/centre/bas × gauche/centre/droite) ou le mode **Mosaïque**, qui répète le filigrane sur toute l'image.
- **Marges horizontale et verticale (px)** — l'écart en pixels par rapport au bord, pour les positions d'ancrage.
- **Espacement mosaïque (%)** — l'écart entre les répétitions, utilisé uniquement avec la position Mosaïque.
### Application
- **Largeur minimale (px)** — les images plus étroites que cette valeur ne sont pas filigranées. Cela évite de tamponner les micro-vignettes (panier, recherche), où un filigrane serait illisible.
- **Types d'images à filigraner** — sélectionnez les types d'images concernés (large_default, home_default, etc.). Chaque type affiche ses dimensions pour vous aider à choisir.
- **Formats à traiter** — JPG, PNG, WebP et AVIF. Sélectionnez les formats générés par votre boutique. PrestaShop 8 et 9 produisent souvent WebP et AVIF en plus du format principal.
Après chaque modification, pensez à **enregistrer**, puis à régénérer les miniatures pour appliquer les nouveaux réglages aux images déjà en ligne. Les nouvelles images uploadées sont filigranées automatiquement avec les réglages en cours.
## Comment fonctionne le filigrane
Le module s'accroche au hook natif `actionWatermark` de PrestaShop, déclenché à chaque (re)génération des miniatures d'une image produit. Pour chaque type d'image sélectionné et chaque format actif, le module charge la miniature générée, applique le filigrane, puis réenregistre le fichier en reprenant les niveaux de qualité définis dans les paramètres d'images de votre boutique.
Seules les déclinaisons par type d'image sont traitées : le fichier original reste intact. Vous pouvez donc changer de filigrane et régénérer autant de fois que nécessaire sans jamais dégrader la source.
En mode logo, la transparence de votre PNG est préservée grâce à une fusion alpha sur mesure qui combine l'opacité globale que vous réglez avec la transparence native de l'image. Pas de cadre ni de fond opaque ajouté autour du logo.
## Appliquer le filigrane aux produits existants
Le hook ne traite une image qu'au moment où elle est générée. Pour filigraner tout un catalogue déjà en ligne, lancez une régénération des miniatures :
1. Ouvrez **Design > Paramètres d'images** (un bouton direct est présent sur la page du module).
2. Lancez la **régénération des miniatures** pour les images produit.
La régénération recrée les miniatures à partir des originaux, puis le module y applique le filigrane. Sur les très gros catalogues, préférez la régénération native de PrestaShop, conçue pour traiter de grands volumes. La régénération est aussi disponible en ligne de commande :
```
bin/console prestashop:thumbnails:regenerate products
```
## Mode logo ou mode texte
Le **mode logo** convient si vous avez une identité visuelle forte : un PNG transparent posé en bas à droite, à 60 % d'opacité, suffit à signer vos visuels sans gêner la lecture du produit.
Le **mode texte** est idéal pour une mention rapide sans préparer de fichier. La police DejaVuSans est embarquée dans le module, ce qui garantit un rendu identique sur tous les hébergements, sans dépendre des polices installées sur le serveur.
## Compatibilité
- **PrestaShop** — 1.7, 8.x et 9.x. La compatibilité 9.x couvre la nouvelle régénération basée sur Symfony : le module résout ses chemins de fichiers de façon défensive pour fonctionner même lorsque les constantes historiques ne sont pas chargées.
- **PHP** — 7.2 et supérieur, avec l'extension GD.
- **Formats** — JPG, PNG, WebP et AVIF, ainsi que les variantes haute densité `@2x`. Le traitement de WebP et AVIF dépend du support de ces formats par la bibliothèque GD du serveur.
## Désinstallation
La désinstallation supprime la configuration du module et son hook. Les filigranes déjà appliqués restent présents sur les miniatures jusqu'à la prochaine régénération. Pour retrouver des images sans filigrane, désinstallez le module puis régénérez les miniatures : elles repartent des fichiers originaux, restés intacts.
## Dépannage
**Le filigrane ne s'applique pas.** Vérifiez qu'au moins un type d'image et un format sont cochés dans le panneau _Application_, qu'un logo est bien téléversé en mode logo (ou un texte saisi en mode texte), et que la largeur minimale n'exclut pas le type d'image visé. Lancez ensuite une régénération des miniatures.
- **Le logo apparaît trop petit ou trop grand** — ajustez la _Taille du logo_ (en % de la largeur), ou mettez-la à 0 pour conserver la taille native.
- **WebP ou AVIF non filigranés** — le serveur doit disposer d'une bibliothèque GD compilée avec le support de ces formats. Si ce n'est pas le cas, les fichiers concernés sont simplement ignorés, sans erreur.
- **Filigrane sur les vignettes minuscules** — augmentez la _Largeur minimale_ pour exclure les petits formats.
## FAQ
### Mes images originales sont-elles modifiées ?
Non. Seules les miniatures générées par type d'image sont filigranées. Le fichier original reste intact.
### Comment appliquer le filigrane aux produits déjà en ligne ?
Configurez le module, puis lancez une régénération des miniatures depuis Design > Paramètres d'images. Les nouvelles images uploadées sont filigranées automatiquement.
### Le module fonctionne-t-il avec WebP et AVIF ?
Oui, ainsi qu'avec les variantes @2x, à condition que l'extension GD du serveur supporte ces formats.
### Faut-il préparer un fichier pour le mode texte ?
Non. Il suffit de saisir le texte ; la police est embarquée dans le module.
### La transparence de mon logo PNG est-elle conservée ?
Oui, grâce à une fusion alpha sur mesure qui préserve la transparence tout en appliquant l'opacité choisie.
### Le module est-il compatible PrestaShop 9 ?
Oui, le module est compatible PrestaShop 1.7, 8 et 9, y compris la nouvelle régénération via le moteur Symfony.
---
### Filtres à Facettes AJAX pour PrestaShop — Documentation
_Source :_
> Ce guide couvre l'installation, la configuration et l'exploitation du module Filtres à Facettes AJAX pour PrestaShop 8 et 9. Le module remplace la recherche à facettes native par une navigation…
Ce guide couvre l'installation, la configuration et l'exploitation du module **Filtres à Facettes AJAX** pour PrestaShop 8 et 9. Le module remplace la recherche à facettes native par une navigation AJAX plus rapide, un slider de prix avec histogramme et un contrôle fin de l'indexation SEO des pages filtrées.
## Installation
Depuis votre back-office, ouvrez **Modules > Module Manager**, cliquez sur _Installer un module_ et déposez le fichier `dffacetedfilter.zip`. À l'installation, le module effectue automatiquement trois actions :
- il crée ses tables et son onglet d'administration ;
- il synchronise une première fois les facettes à partir de votre catalogue ;
- il préchauffe l'index de prix (dans la limite de quelques secondes).
Le module se place en priorité sur le hook `productSearchProvider` afin de passer devant la recherche à facettes native de PrestaShop. Aucun fichier de votre thème n'est surchargé.
## Première configuration
Rendez-vous dans **Catalogue > Filtres à facettes**. Vous y trouvez la liste des facettes, un tableau de bord de synthèse et les réglages généraux et SEO.
### Synchroniser les facettes
Le bouton **Synchroniser depuis le catalogue** crée automatiquement les facettes manquantes à partir de vos groupes d'attributs, de vos caractéristiques et des facettes intégrées (prix, marque, promotions, disponibilité, état). Les facettes existantes ne sont jamais modifiées : vous pouvez relancer la synchronisation sans risque après avoir ajouté un attribut ou une caractéristique.
### Reconstruire l'index de prix
Le bouton **Reconstruire l'index prix** recalcule les bornes de prix de tous les produits, par lots, avec une barre de progression. Lancez-le après l'installation puis après tout import massif de produits.
## Gérer les facettes
Chaque ligne de la liste peut être réordonnée par glisser-déposer (l'ordre définit l'ordre d'affichage en front et l'ordre normalisé des URLs), activée ou désactivée, et éditée.
### Options d'une facette
- **Libellé** : le nom affiché, traduisible par langue.
- **Affichage** : cases à cocher, pastilles couleur / texture, ou liens simples. Les groupes de couleurs héritent automatiquement de l'affichage en pastilles.
- **Multi-sélection** : autorise la sélection simultanée de plusieurs valeurs d'une même facette, combinées par un OU.
- **Afficher les compteurs** : affiche le nombre de produits en face de chaque valeur.
- **Masquer les valeurs vides** : masque les valeurs à zéro produit au lieu de les afficher grisées.
- **Repliée par défaut** : la facette s'affiche fermée, l'internaute la déplie au clic.
- **Valeurs avant « Voir plus »** : nombre de valeurs visibles avant le bouton d'expansion (0 = tout afficher).
Le **comptage disjonctif** est appliqué : chaque facette est comptée en tenant compte de toutes les autres sélections, mais pas de la sienne. Sélectionner « Rouge » ne met donc jamais « Bleu » à zéro dans la même facette.
## Le slider de prix et son index
La facette Prix s'affiche sous forme d'un double curseur. Au-dessus, un histogramme de répartition des produits sur douze tranches aide l'internaute à situer les prix. Ces données proviennent d'un index de prix dédié, distinct des tables PrestaShop, pour rester rapide même sur un gros catalogue.
### Maintenance de l'index
L'index est mis à jour en temps réel par des hooks lorsqu'un produit, un prix spécifique ou une déclinaison change. Pour une reconstruction complète planifiée, utilisez l'endpoint cron affiché en back-office :
```
/module/dffacetedfilter/cron?token=VOTRE_JETON
```
L'appel traite l'index par tranches avec une garde-temps d'environ 20 secondes ; s'il reste des produits, la réponse fournit l'URL de continuation à rappeler. Un appel nocturne quotidien suffit dans la plupart des cas.
Le réglage **Filtrer les prix TTC** détermine si le slider raisonne en prix taxe comprise ou hors taxe. L'index stocke les prix dans la devise par défaut ; l'affichage est converti dans la devise courante.
## La facette Promotions
La facette **En promo** filtre les produits actuellement en réduction : produits marqués « en soldes » ou couverts par un prix spécifique actif (réduction en cours, dans la plage de dates, pour la devise, le pays et le groupe courants). Elle est créée activée par défaut lors de la synchronisation.
## Disponibilité et état
Deux facettes intégrées complémentaires sont créées désactivées, à activer selon vos besoins :
- **Disponibilité** : une valeur « En stock » qui tient compte de votre réglage de commande en rupture de stock.
- **État** : neuf, occasion, reconditionné.
## Restreindre une facette à des catégories
Par défaut, une facette s'affiche sur toutes les pages de listing. Dans le formulaire d'édition, la section **Restreindre à des catégories** vous permet de cocher une ou plusieurs catégories : la facette n'apparaîtra alors que sur ces catégories et leurs sous-catégories.
C'est le bon moyen de garder un menu de filtres pertinent sur un catalogue hétérogène : n'affichez « Pointure » que sous Chaussures, « Taille écran » que sous High-tech. Laissez tout décoché pour une facette globale.
## Le SEO des facettes
C'est l'un des points forts du module : vous décidez précisément quelles pages filtrées peuvent être indexées. Les URLs de filtres sont lisibles et suivent le format :
```
/categorie?dff=couleur:rouge,bleu-marine/prix:10,50/marque:nike
```
Les facettes sont séparées par une barre oblique, le slug de la facette et ses valeurs par deux-points, et les valeurs entre elles par une virgule. L'ordre des facettes et le tri des valeurs sont normalisés afin qu'une même combinaison produise toujours une seule URL canonique.
### Réglages SEO
- **Indexable (par facette)** : une facette non indexable force la page filtrée en `noindex, follow` et ajoute `rel="nofollow"` sur ses liens.
- **Nombre max. de valeurs indexables** : au-delà de ce seuil de valeurs sélectionnées, la page passe en `noindex, follow`. La valeur 1 est la plus sûre contre l'explosion du budget de crawl.
- **Canonical auto sur les pages indexables** : les pages indexables reçoivent une balise canonical pointant vers leur propre URL de filtre normalisée. Le canonical du thème est retiré côté front pour éviter les doublons.
- **Tout passer en noindex** : force le `noindex, follow` sur toutes les pages filtrées, quels que soient les réglages par facette.
Une page filtrée est aussi mise en `noindex, follow` lorsqu'un paramètre de tri est présent, car il s'agit d'un doublon de la page dans son ordre par défaut.
## Modes AJAX
Le réglage **Mode AJAX** détermine comment la page se met à jour au clic sur un filtre :
- **Thème (événements natifs)** — recommandé : le module émet l'événement natif de PrestaShop et laisse le cœur et le thème rafraîchir la liste, les facettes et l'historique du navigateur. C'est le mode le plus compatible avec les thèmes basés sur classic.
- **Autogéré** : pour les thèmes non standards, le module récupère lui-même la page en AJAX et remplace les blocs concernés. À utiliser seulement si le mode Thème ne rafraîchit pas correctement la page.
## Cache des compteurs
Le calcul des compteurs disjonctifs peut être coûteux sur un gros catalogue. Le module met leur résultat en cache pour une courte durée configurable (300 secondes par défaut). Ce cache est **invalidé automatiquement** à chaque changement de catalogue et à chaque modification d'une facette. Un bouton **Vider le cache des compteurs** est disponible en back-office.
## Statistiques d'usage
Le tableau de bord, en haut de la page d'administration, résume l'activité des 30 derniers jours : produits indexés, nombre de vues de pages filtrées, part du budget de crawl gardée hors index (pages filtrées servies en noindex) et un classement des facettes les plus utilisées. Vous pouvez désactiver l'enregistrement des statistiques dans les réglages de performance.
## Pages prises en charge
Les facettes s'appliquent aux pages de catégorie, marque, fournisseur, nouveautés, meilleures ventes, promotions et **résultats de recherche** (en respectant le classement natif de PrestaShop). La facette Marque est automatiquement masquée sur une page de marque, et la facette scoping-catégorie sur une page de recherche.
## Désactiver la recherche à facettes native
Le module prend la priorité sur `ps_facetedsearch`, mais nous recommandons de désactiver ce dernier pour éviter un double travail d'indexation. Un avertissement vous le rappelle en back-office s'il reste actif.
## Dépannage
- **Les facettes n'apparaissent pas** : lancez une synchronisation, vérifiez qu'au moins une facette est active, et que vous êtes bien sur une page de listing prise en charge.
- **Le slider de prix est absent** : reconstruisez l'index de prix ; la facette Prix se masque tant que l'index est vide pour la catégorie affichée.
- **La page ne se rafraîchit pas en AJAX** : passez le mode AJAX en « Autogéré » si votre thème ne suit pas le standard de PrestaShop.
- **Trop de pages indexées** : abaissez le nombre max. de valeurs indexables, rendez non indexables les facettes à forte cardinalité (couleur, taille), ou activez « Tout passer en noindex » le temps de reprendre la main.
Le code source est fourni non chiffré. Vous bénéficiez de 12 mois de mises à jour de compatibilité et d'un support sous 24 h.
## Nouveautés de la version 1.2
### Landing pages SEO
Dans **Catalogue > Filtres à facettes > Landing pages SEO**, transformez une combinaison de filtres précise (par exemple Chaussures × Couleur : rouge × Marque : Nike) en véritable page d'atterrissage : meta title, meta description, H1 et introduction éditoriale, par langue. Pour cibler une combinaison, copiez la valeur du paramètre `dff` depuis une URL filtrée de votre boutique et collez-la dans le formulaire.
Une landing active est **toujours indexable** : elle passe devant les réglages par facette, le plafond de valeurs et même l'interrupteur « Tout passer en noindex ». La stratégie « tout en noindex sauf mes pages curées » devient donc possible.
Toutes les landings actives sont listées dans un sitemap XML dédié, avec alternates hreflang, à soumettre dans Search Console :
```
/module/dffacetedfilter/sitemap
```
### Autres nouveautés
- **Facette Sous-catégories** : propose les sous-catégories directes de la catégorie affichée ; le listing inclut alors automatiquement tout le sous-arbre.
- **Tri des valeurs par facette** : position catalogue, alphabétique ou nombre de produits décroissant.
- **Pastilles couleur en grille ou en liste** : chaque facette couleur peut s'afficher en grille horizontale de pastilles ou en liste verticale avec libellés et compteurs.
- **Masquer les facettes à valeur unique** : une facette dont l'unique valeur couvre tout le listing n'apporte aucun pouvoir de filtrage ; ce réglage l'écarte automatiquement.
- **Couleur d'accent** : choisissez au sélecteur la couleur des cases cochées, interrupteurs, slider et badges ; le contraste du texte est calculé automatiquement.
- **AJAX résilient** : si le thème ne répond pas à l'événement natif, le module bascule automatiquement en mode autogéré ; la position de scroll est préservée après chaque filtrage et les filtres mobiles s'ouvrent dans un modal plein écran.
- **8 langues front** : FR, EN, ES, DE, IT, PL, PT, NL livrées dans le module.
---
### Final Sales — Vente ferme & mention non retournable
_Source :_
> Présentation Le module Final Sales permet de marquer certains produits comme vendus en « vente ferme » : le client est informé, avant l'achat, que l'article ne pourra pas être…
## Présentation
Le module Final Sales permet de marquer certains produits comme vendus en « vente ferme » : le client est informé, avant l'achat, que l'article ne pourra pas être retourné, échangé ou remboursé au titre du droit de rétractation. L'information apparaît sous forme de badge sur les listes de produits, la fiche produit et le panier, puis elle est reprise clairement sur la facture PDF à des fins de preuve.
Le module va plus loin qu'un simple badge grâce à la **double tarification** optionnelle : le prix vente ferme, réduit, devient le prix affiché par défaut partout dans la boutique, et le client peut choisir sur la fiche produit de payer le prix standard pour conserver son droit de retour de 14 jours. Le module est compatible PrestaShop 8 et 9, en mono comme en multi-boutique, et entièrement traduisible (FR, EN, ES, DE, IT).
**Important — cadre juridique.** En vente à distance auprès de consommateurs (B2C) dans l'Union européenne, la mention « vente ferme » ne suffit pas à elle seule à écarter le droit de rétractation de 14 jours. Ce droit ne peut être exclu que dans les cas prévus par la loi (article L221-28 du Code de la consommation, directive 2011/83/UE article 16) : biens personnalisés, produits périssables, articles descellés non retournables pour raisons d'hygiène, etc. Ce module est un outil d'information et de traçabilité du consentement ; il ne crée pas à lui seul un motif légal d'exclusion. En cas de doute, faites valider vos conditions générales de vente par un juriste.
## Installation
1. Depuis le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez l'archive ZIP du module.
3. Une fois l'installation terminée, cliquez sur **Configurer** pour ouvrir la page de réglages.
À l'installation, le module crée ses tables techniques et enregistre ses hooks. Aucune manipulation supplémentaire n'est nécessaire.
**Mise à jour par FTP.** Si vous remplacez les fichiers du module par FTP sans passer par le Gestionnaire de modules, PrestaShop peut ne pas exécuter les scripts de mise à jour. Le module intègre une auto-réparation de schéma qui recrée automatiquement les tables ou colonnes manquantes au premier chargement. Videz malgré tout le cache après chaque mise à jour (**Paramètres avancés > Performances > Vider le cache**).
## Les trois niveaux de marquage
Un produit peut être marqué en vente ferme de trois façons, qui se combinent.
### 1. Marquage individuel sur la fiche produit
Sur chaque fiche produit, une case **« Marquer comme vente ferme »** permet de marquer l'article. C'est le réglage le plus direct pour quelques produits.
### 2. Règles par catégorie
Dans l'onglet **Règles (catégories)** de la configuration, cochez les catégories dont tous les produits doivent être automatiquement marqués en vente ferme. Tout produit appartenant à l'une de ces catégories hérite du marquage, sans intervention sur chaque fiche.
### 3. Sélection manuelle
L'onglet **Produits marqués** liste les produits marqués individuellement et permet d'en ajouter ou d'en retirer via un outil de recherche, sans ouvrir chaque fiche.
## La double tarification
La double tarification est la fonctionnalité centrale du module. Elle repose sur un principe simple : **le prix vente ferme, réduit, devient le prix affiché par défaut** dans toute la boutique, et le client qui souhaite conserver son droit de retour paie le prix standard.
### Activation
Dans l'onglet **Double tarification**, activez l'interrupteur global **« Activer la double tarification »**. C'est le commutateur maître : sans lui, aucune double tarification n'est proposée, quels que soient les réglages par produit ou par catégorie.
### Définir le prix vente ferme
Le prix vente ferme peut être défini de trois manières, résolues dans cet ordre de priorité :
1. **Prix fixe par produit** — saisi directement sur la fiche produit (prioritaire).
2. **Pourcentage de remise par produit** — saisi sur la fiche produit.
3. **Pourcentage de remise par catégorie** — défini dans l'onglet Règles, hérité par tous les produits de la catégorie.
Le pourcentage par catégorie permet d'appliquer une remise vente ferme globale à des dizaines de produits en une seule saisie. Un produit peut toujours surcharger cette valeur avec son propre prix ou pourcentage.
**Comment ça fonctionne techniquement.** Pour chaque produit éligible, le module crée un prix spécifique catalogue natif PrestaShop. Le prix réduit s'affiche donc partout où PrestaShop affiche un prix : listes de produits (avec prix barré), fiche produit, panier, tri par prix, recherche à facettes, flux d'export. Lorsque le client choisit l'option standard retournable, un prix spécifique limité à son panier ramène le tarif au prix de base.
### Choix par défaut
Le choix pré-sélectionné sur la fiche produit est configurable. Par défaut, l'option **vente ferme** (prix réduit) est cochée, cohérente avec le principe « prix vente ferme = prix affiché ». Vous pouvez basculer ce défaut sur l'option standard si vous préférez une logique de retour par défaut.
## Côté client
Sur une fiche produit en double tarification, deux cartes apparaissent au-dessus du bouton d'ajout au panier :
- La carte **vente ferme** affiche le badge, le prix réduit et l'économie réalisée. Une mention rappelle que l'article ne sera pas retournable.
- La carte **prix standard** affiche le prix plein et rappelle que l'article reste retournable pendant 14 jours.
Le client bascule d'une carte à l'autre d'un clic ; le prix du panier est mis à jour immédiatement. Sur les listes de produits et la fiche, le badge affiche directement le prix vente ferme, par exemple « VENTE FERME · 44,50 € ».
## Panier, commande et facture
Dans le panier, une mention rappelle la présence d'articles en vente ferme, uniquement pour les lignes où le client a effectivement choisi le prix vente ferme. Vous pouvez rendre obligatoire une case d'acceptation avant le passage en caisse (onglet **Affichage**).
À la validation de la commande, le choix du client est figé pour chaque ligne. Sur la facture PDF, une mention « VENTE FERME » et le texte juridique associé n'apparaissent que pour les articles effectivement achetés au prix vente ferme — jamais pour ceux achetés au prix standard retournable. Cette traçabilité constitue la preuve du consentement du client.
## Personnalisation de l'affichage
L'onglet **Apparence** permet de choisir les couleurs du badge (fond et texte). L'onglet **Affichage** contrôle où le badge et les mentions apparaissent (listes, fiche, panier, facture) et l'onglet **Textes juridiques** permet de personnaliser, par langue, le libellé du badge, la mention d'information, le texte de la facture et le texte de la case d'acceptation.
## Désinstallation
La désinstallation supprime tous les prix spécifiques catalogue créés par le module : les prix reviennent immédiatement à la normale, sans prix fantôme. Les tables techniques, la configuration et les choix enregistrés sont également supprimés. Les commandes déjà passées conservent la mention vente ferme figée sur leurs lignes.
## FAQ
### La mention « vente ferme » me dispense-t-elle du droit de rétractation ?
Non, pas à elle seule. En B2C dans l'Union européenne, le droit de rétractation de 14 jours ne peut être écarté que dans les cas limitativement prévus par la loi (biens personnalisés, produits périssables, articles descellés pour raisons d'hygiène, etc.). Le module informe le client et trace son consentement, mais ne crée pas de motif légal d'exclusion. Faites valider vos conditions de vente par un juriste.
### Le prix vente ferme s'affiche-t-il partout ?
Oui. Grâce aux prix spécifiques catalogue natifs, le prix vente ferme apparaît sur les listes de produits, la fiche, le panier, le tri par prix et la recherche à facettes, exactement comme une promotion PrestaShop classique.
### Puis-je appliquer une remise vente ferme à toute une catégorie ?
Oui. Dans l'onglet Règles, définissez un pourcentage de remise par catégorie : tous les produits de la catégorie proposent alors la double tarification à ce taux, sans réglage individuel.
### Que se passe-t-il si un produit a déjà une promotion ?
PrestaShop applique la règle de prix spécifique prioritaire ; les réductions ne se cumulent pas. Vérifiez la cohérence de vos promotions existantes avec le prix vente ferme.
### Le module est-il compatible PrestaShop 9 ?
Oui, le module est compatible PrestaShop 8.x et 9.x, en mono comme en multi-boutique.
---
### Formulaire de Livraison Objets Lourds — Guide d'installation et de configuration
_Source :_
> Le module Formulaire de Livraison Objets Lourds & Volumineux affiche, à l'étape transporteur du checkout, un questionnaire de conditions d'accès (étage, ascenseur, escaliers, passages étroits, obstacles) pour les produits lourds…
Le module **Formulaire de Livraison Objets Lourds & Volumineux** affiche, à l'étape transporteur du checkout, un questionnaire de conditions d'accès (étage, ascenseur, escaliers, passages étroits, obstacles) pour les produits lourds ou volumineux : meubles, électroménager, téléviseurs grand format, mobilier professionnel ou médical. Les champs sont entièrement configurables en back-office, sans écrire une ligne de code.
Ce module est développé pour PrestaShop 8.0 à 9.x, compatible multiboutique et multilingue. Il n'utilise aucune dépendance externe : JavaScript vanilla, sans jQuery ni Composer.
## Installation
1. Depuis le back-office, ouvrez **Modules > Module Manager** puis cliquez sur **Installer un module**.
2. Sélectionnez le fichier `dfdeliveryform.zip` et lancez l'installation.
3. À la fin de l'installation, cliquez sur **Configurer** pour accéder aux réglages.
À l'installation, le module crée automatiquement ses tables, enregistre ses hooks et pré-installe un jeu de **17 champs prêts à l'emploi** (horaires de présence, accès camion poids lourd, distance de stationnement, étage, ascenseur, escaliers, passages étroits, obstacles, confirmation d'exactitude). Vous pouvez les garder, les modifier ou repartir de zéro.
## Réglages généraux
La page de configuration se divise en deux zones : les **réglages** (en haut) et le **constructeur de champs** (en bas).
- **Activer le module** — affiche ou masque le formulaire côté boutique.
- **Bloquer le checkout tant que non complété** — si activé, le client ne peut pas confirmer l'étape livraison avant d'avoir soumis le formulaire. Si désactivé, le formulaire reste facultatif.
- **Mode de déclenchement** — détermine quand le formulaire s'affiche (voir la section suivante).
- **Email de notification** — adresse qui reçoit le formulaire complété à la validation de la commande. Laissez vide pour utiliser l'email de la boutique.
- **Titre du formulaire** et **Texte d'introduction** — personnalisables par langue.
## Modes de déclenchement
Le formulaire ne doit apparaître que pour les commandes concernées. Quatre modes sont disponibles :
- **Toutes les commandes** — le formulaire s'affiche systématiquement.
- **Seuil de poids produit** — le formulaire s'affiche dès qu'un produit du panier atteint le poids défini (30 kg par défaut). Idéal pour l'électroménager et le mobilier. Le poids utilisé est le poids unitaire du produit renseigné dans sa fiche.
- **Produits spécifiques** — saisissez une liste d'IDs produits séparés par des virgules (ex. `12,45,102`).
- **Catégories spécifiques** — saisissez une liste d'IDs catégories séparés par des virgules. Tout produit appartenant à l'une de ces catégories déclenche le formulaire.
Le formulaire affiche au client la liste des produits concernés de son panier, pour qu'il comprenne pourquoi ces questions lui sont posées.
## Constructeur de champs
Le constructeur, situé sous les réglages, liste tous les champs du formulaire. Pour chaque champ, vous pouvez le réordonner (flèches haut/bas), l'activer/désactiver, le modifier ou le supprimer.
### Ajouter ou modifier un champ
Cliquez sur **Ajouter un champ** ou sur l'icône crayon d'un champ existant. L'éditeur propose :
- **Type** — 7 types disponibles : titre de section, texte, nombre, texte long, interrupteur, Oui/Non, liste déroulante.
- **Libellé** et **texte d'aide** — saisis par langue. Le libellé dans la langue par défaut est obligatoire ; les langues laissées vides reprennent ce libellé.
- **Options** (type liste déroulante uniquement) — une option par ligne, indépendamment pour chaque langue.
- **Afficher seulement si** — condition d'affichage (voir ci-dessous).
- **Obligatoire** et **Actif**.
Le code technique d'un champ est généré automatiquement à partir du libellé lors de la création et reste stable ensuite, même si vous renommez le libellé.
### Types de champs
- **Titre de section** — séparateur visuel, sans saisie.
- **Texte** — champ de saisie sur une ligne.
- **Nombre** — saisie numérique (distance, largeur, nombre de marches…).
- **Texte long** — zone de texte multiligne pour les descriptions.
- **Interrupteur** — bascule oui/non stylisée, idéale pour une confirmation.
- **Oui / Non** — deux pastilles exclusives, sert souvent de parent à un champ conditionnel.
- **Liste déroulante** — choix parmi des options définies par langue.
## Champs conditionnels
Un champ peut ne s'afficher que selon la réponse à un champ parent de type **Oui/Non** ou **interrupteur**.
1. Dans l'éditeur du champ enfant, ouvrez la liste **Afficher seulement si** et choisissez le champ parent.
2. Sélectionnez la valeur attendue : **= Oui / coché** ou **= Non / décoché**.
Exemple : le champ « Largeur de la porte de l'ascenseur » n'apparaît que si la question « Ascenseur / monte-charge » est activée ; le champ « Nombre de marches » n'apparaît que si « Escaliers » est activé. Un champ masqué par sa condition n'est jamais requis, même s'il est marqué obligatoire.
## Côté client
À l'étape transporteur, le client voit une carte indiquant le statut du formulaire (_À compléter_ / _Complété_) et un bouton pour l'ouvrir. Le formulaire s'ouvre dans une fenêtre moderne : cartes de choix, interrupteurs, pastilles Oui/Non, validation en direct des champs obligatoires.
- Les réponses sont enregistrées par panier : un client qui revient retrouve ses réponses pré-remplies.
- En mode bloquant, le bouton de confirmation de l'étape livraison rouvre automatiquement le formulaire tant qu'il n'est pas complété.
## Suivi des réponses
Les réponses du client sont exploitables à trois endroits :
- **Email de notification** — à la validation de la commande, un email HTML récapitulant toutes les réponses est envoyé à l'adresse configurée (service logistique, transporteur ou préparateur). Les gabarits FR et EN sont inclus.
- **Fiche commande** — un panneau dédié affiche le récapitulatif question/réponse dans la commande, en back-office.
- **Base de données** — les réponses sont stockées, rattachées au panier puis à la commande validée.
## Désinstallation
La désinstallation depuis le Module Manager supprime proprement les tables du module (champs, réponses) et sa configuration.
## Questions fréquentes
### Le formulaire ne s'affiche pas
Vérifiez que le module est activé, que le mode de déclenchement correspond au panier de test (par exemple, qu'un produit atteint bien le seuil de poids), et qu'au moins un champ est actif.
### Puis-je traduire les intitulés ?
Oui. Chaque libellé, texte d'aide et option de liste se saisit par langue directement dans le constructeur de champs. Le titre et l'introduction du formulaire sont également multilingues.
### Le module est-il compatible PrestaShop 9 et multiboutique ?
Oui, le module cible PrestaShop 8.0 à 9.x et fonctionne en contexte multiboutique.
---
### Forum Communautaire — Guide complet
_Source :_
> Présentation et prérequis Forum Communautaire ajoute un véritable forum à votre boutique PrestaShop, directement relié au compte client existant. Vos clients ouvrent des sujets, se répondent, modifient ou suppriment leurs…
## Présentation et prérequis
Forum Communautaire ajoute un véritable forum à votre boutique PrestaShop, directement relié au compte client existant. Vos clients ouvrent des sujets, se répondent, modifient ou suppriment leurs propres messages et signalent les abus, pendant que vous gardez la main depuis le back-office : catégories et sous-forums, modération à l'unité ou par lot, pré-modération optionnelle et file de signalements. Le tout sans outil tiers ni base de données externe.
- Compatible PrestaShop 8.0 à 9.x, thème Classic et thèmes dérivés.
- PHP 8.1 à 8.3.
- Multiboutique et multilingue (FR/EN/ES/DE/IT).
- Aucune tâche CRON requise, aucune dépendance Composer.
- Architecture conforme PrestaShop (ObjectModel, ModuleAdminController), compatible PS 8 et PS 9 sans adaptation.
Les membres utilisent leur **compte client PrestaShop habituel**. Aucun second compte n'est nécessaire : un lien vers le forum est ajouté dans l'espace client et en pied de page.
## Installation
Installez le module comme n'importe quel module PrestaShop :
1. Téléchargez l'archive `dfforum.zip` depuis votre compte client.
2. Dans le back-office, allez dans **Modules > Gestionnaire de modules**.
3. Cliquez sur **Installer un module** et déposez l'archive.
4. Une fois installé, cliquez sur **Configurer**.
À l'installation, le module crée ses tables (catégories, sujets, messages, signalements), enregistre ses hooks, ajoute l'onglet parent **DataFirefly Forum** et amorce une première catégorie de démonstration « Discussion générale » pour vous permettre de tester immédiatement.
Si les URLs propres ne s'activent pas tout de suite, videz le cache (**Paramètres avancés > Performances**) et régénérez les URLs depuis **Trafic & SEO**.
## Réglages généraux du module
La page de configuration regroupe tous les réglages du forum :
- **Pré-modération** : si activée, chaque nouveau sujet ou message passe en file d'attente avant d'être public.
- **Lecture par les invités** : autorise ou non la consultation du forum sans être connecté (l'écriture reste réservée aux clients connectés).
- **Sujets par page** : nombre de sujets affichés dans une catégorie (20 par défaut).
- **Messages par page** : nombre de messages affichés dans un sujet (15 par défaut).
- **Longueur minimale** : nombre minimal de caractères exigé pour un message (10 par défaut).
- **Délai anti-flood** : durée minimale, en secondes, entre deux messages d'un même membre (30 par défaut ; 0 pour désactiver).
- **Signalements** : active ou non la possibilité pour les membres de signaler un message.
- **Fenêtre d'édition** : durée, en minutes, pendant laquelle un membre peut encore modifier son message (30 par défaut ; 0 pour interdire l'édition).
- **E-mail de notification** : adresse qui reçoit les signalements (par défaut, l'e-mail de la boutique).
## Créer des catégories et des sous-forums
Depuis l'onglet **DataFirefly Forum > Catégories**, structurez votre forum. Une catégorie peut être un thème de premier niveau ou un sous-forum rattaché à une autre catégorie.
- **Nom et description** : textes traduisibles par langue, affichés sur l'accueil du forum.
- **Catégorie parente** : laissez vide pour une catégorie racine, ou sélectionnez une catégorie pour créer un sous-forum.
- **Icône** : pictogramme facultatif affiché à côté du nom.
- **Position** : ordre d'affichage, réglable par glisser-déposer dans la liste.
- **Active** : masque ou affiche la catégorie côté boutique.
Chaque sous-forum affiche automatiquement son nombre de sujets, son nombre de messages et son dernier message.
Supprimer une catégorie supprime aussi les sujets et messages qu'elle contient. Ses éventuels sous-forums sont détachés (replacés à la racine), pas supprimés.
## Côté visiteur : créer un sujet et répondre
Un client connecté ouvre un sujet depuis le bouton **Nouveau sujet** : il choisit la catégorie, saisit un titre et un message. Le module génère automatiquement un _slug_ et une URL propre pour le sujet. Dans un sujet, le formulaire de réponse apparaît en bas de page pour les membres connectés.
Chaque message affiche une fiche auteur : avatar à initiale, nom, nombre de messages et date d'inscription. Tant que la fenêtre d'édition n'est pas dépassée, l'auteur peut **modifier** ou **supprimer** son propre message directement, sans rechargement de page (AJAX).
Si l'auteur supprime l'unique message d'un sujet qu'il a créé, le sujet entier est supprimé. C'est le comportement attendu pour éviter les sujets vides.
## Modération des sujets et des messages
Deux onglets dédiés vous permettent de modérer :
- **DataFirefly Forum > Sujets** : activez ou désactivez, **épinglez**, **verrouillez** ou supprimez les sujets, à l'unité ou par lot. Un sujet verrouillé reste lisible mais n'accepte plus de réponses ; un sujet épinglé remonte en haut de sa catégorie.
- **DataFirefly Forum > Messages** : modérez chaque message individuellement ou par lot, validez les messages en attente, ou filtrez les messages d'un sujet précis.
Le **tableau de bord** (premier onglet) affiche en un coup d'œil le nombre de catégories, de sujets, de messages, de messages en attente et de signalements, avec des accès directs vers la modération.
## Pré-modération
Quand la pré-modération est activée dans les réglages, chaque nouveau sujet et chaque nouvelle réponse sont créés en statut « en attente » et n'apparaissent pas tant que vous ne les avez pas validés. Le membre est informé que son message sera publié après validation.
Pour valider, rendez-vous dans **Messages** : les contenus en attente y sont signalés et peuvent être approuvés à l'unité ou par lot. Le compteur « en attente » du tableau de bord vous indique en permanence ce qui reste à traiter.
La pré-modération s'applique aux nouveaux contenus. Les messages déjà publiés ne repassent pas en file d'attente si vous activez l'option par la suite.
## Signalements et notifications
Si les signalements sont activés, chaque membre peut signaler un message qu'il juge abusif (un seul signalement par membre et par message). Le signalement arrive dans l'onglet **DataFirefly Forum > Signalements**, avec un accès direct au message concerné, et peut être marqué comme traité.
À chaque signalement, un e-mail est envoyé à l'adresse de notification configurée. Des modèles d'e-mail prêts à l'emploi sont fournis en **français** et en **anglais**.
Pour ne pas manquer un signalement, renseignez une adresse de notification dédiée à la modération plutôt que l'e-mail générique de la boutique.
## Recherche et URLs propres
Le forum expose une recherche plein texte basée sur un index **FULLTEXT** portant sur les titres et le contenu des messages : vos visiteurs retrouvent instantanément une discussion. Côté adresses, le module génère des URLs propres et lisibles pour le forum, les catégories et les sujets, ainsi que pour la création d'un nouveau sujet.
Ce contenu généré par vos clients, accessible via des URLs claires, alimente naturellement votre référencement sur des requêtes de longue traîne. Laissez la lecture ouverte aux invités pour maximiser l'indexation.
## Intégration au compte client
Le module s'intègre à l'espace client PrestaShop via les hooks `displayCustomerAccount` et `displayMyAccountBlock` : un lien vers le forum apparaît dans le tableau de bord du compte client. Un second lien est ajouté en pied de page via le hook `displayFooter`, pour rendre le forum visible depuis n'importe quelle page.
## FAQ et dépannage
### Le lien du forum n'apparaît pas dans l'espace client
Vérifiez que les hooks `displayCustomerAccount` et `displayMyAccountBlock` sont bien greffés (onglet **Modules > Positions**). Certains thèmes personnalisés n'appellent pas ces hooks : il faut alors les ajouter au template du compte client.
### Les URLs du forum renvoient une erreur 404
Videz le cache et régénérez les URLs depuis **Trafic & SEO**. Assurez-vous que la réécriture d'URL (URL simplifiées) est activée dans votre boutique.
### Un membre ne peut plus modifier son message
La modification n'est possible que pendant la fenêtre d'édition définie dans les réglages. Passé ce délai, le bouton de modification disparaît. Réglez la fenêtre à 0 pour interdire toute édition, ou augmentez-la pour laisser plus de temps.
### Les messages n'apparaissent pas immédiatement
C'est le comportement normal quand la pré-modération est active : les messages restent en attente jusqu'à validation depuis l'onglet **Messages**. Désactivez la pré-modération pour une publication immédiate.
### Comment lutter contre le spam ?
Le module combine plusieurs garde-fous : champ honeypot invisible, anti-flood paramétrable, longueur minimale et signalement communautaire. Pour un contrôle maximal, activez la pré-modération.
### Que se passe-t-il à la désinstallation ?
La désinstallation supprime les tables du module et ses onglets back-office. Une confirmation est demandée car cette opération efface définitivement les catégories, sujets et messages.
---
### Frais de Douane DDP / DAP — Guide complet
_Source :_
> Présentation et prérequis Le module Frais de Douane DDP / DAP est conçu pour les boutiques établies dans l'Union européenne qui expédient vers des destinations hors UE. Dès que l'adresse…
## Présentation et prérequis
Le module Frais de Douane DDP / DAP est conçu pour les boutiques établies dans l'Union européenne qui expédient vers des destinations hors UE. Dès que l'adresse de livraison sort du territoire douanier de l'UE, un bloc de choix apparaît dans l'étape transporteur du checkout : le client décide de régler les droits de douane et taxes d'importation immédiatement avec sa commande (DDP) ou à la livraison auprès du transporteur (DAP).
- Compatible PrestaShop 8.0 à 9.x, thème Classic et thèmes dérivés.
- PHP 7.4 à 8.3.
- Multiboutique et multidevise : les frais sont calculés dans la devise du panier.
- Multilingue (FR/EN/ES/DE/IT, plus PT fourni).
- Aucune surcharge de fichiers : uniquement des hooks natifs.
Le module ne calcule pas les droits réels auprès des douanes : il applique **votre** barème (taux en pourcentage, frais fixes, seuils) pour produire une estimation fiable affichée au client. En mode DDP, c'est ce montant qui est facturé sur la boutique ; à vous d'expédier ensuite avec un service DDP auprès de votre transporteur.
## Installation
Installez le module comme n'importe quel module PrestaShop :
1. Téléchargez l'archive `dfcustomsduty.zip` depuis votre compte client.
2. Dans le back-office, allez dans **Modules > Gestionnaire de modules**.
3. Cliquez sur **Installer un module** et déposez l'archive.
4. Une fois installé, cliquez sur **Configurer**.
À l'installation, le module enregistre ses hooks, crée ses tables (suivi du choix par panier, persistance par commande, taux par pays) et crée automatiquement un produit virtuel masqué « Frais de douane et taxes d'importation (DDP) », hors taxe et commandable hors stock. Ce produit n'apparaît jamais au catalogue : il sert uniquement de support de facturation lorsque le client choisit le mode DDP.
Le **taux par défaut est à 0 % après l'installation**. Tant qu'il n'est pas configuré (taux global ou taux par pays), aucun frais n'est calculé et le bloc de choix ne s'affiche pas. C'est volontaire, pour éviter de facturer un taux arbitraire à vos clients.
## Configuration générale
La page de configuration regroupe les réglages du barème et de l'affichage :
- **Activer le module** : interrupteur global.
- **Mode présélectionné au checkout** : DDP (recommandé) ou DAP. C'est l'option cochée par défaut tant que le client n'a pas fait de choix.
- **Taux par défaut (%)** : pourcentage appliqué à la valeur de la commande pour estimer droits + TVA d'importation. Surchargé au cas par cas par les taux par pays.
- **Frais fixes de dossier** : montant fixe ajouté au calcul, dans la devise par défaut de la boutique, hors taxe.
- **Seuil de franchise (de minimis)** : en dessous de cette valeur de commande, aucun frais n'est appliqué. 0 = pas de seuil.
- **Inclure les frais de port dans la base de calcul** : la valeur en douane (CIF) inclut généralement le transport.
- **Afficher une notice dans le panier** : informe le client en amont qu'une livraison hors UE entraînera des frais.
- **Pays imposant le DDP (codes ISO)** : liste de destinations, séparées par des virgules, pour lesquelles le mode DDP est obligatoire. Le client livré dans ces pays ne peut pas basculer en DAP. Valeur par défaut : `US` (aux États-Unis, les droits doivent être pris en charge par le vendeur). Laissez vide pour désactiver le forçage global.
- **Pays du territoire douanier UE (codes ISO)** : liste séparée par des virgules. Toute livraison vers un pays absent de cette liste est traitée comme hors UE.
Par défaut, la liste UE contient les 27 États membres plus Monaco (en union douanière avec la France). Vous pouvez l'ajuster librement, par exemple pour traiter à part certains territoires à fiscalité spéciale.
## Base et formule de calcul
Les frais estimés sont calculés ainsi, dans la devise du panier et hors taxe :
```
base = total produits HT (hors produit de frais)
+ frais de port HT (si l'option est activée)
frais = base × taux_pays(%) + frais_fixes
```
Le seuil de franchise est évalué avant tout : si la base est inférieure au seuil applicable (seuil du pays s'il est défini, sinon seuil global), aucun frais n'est facturé. Les frais fixes et les seuils, stockés dans la devise par défaut de la boutique, sont automatiquement convertis dans la devise du panier.
## Taux par pays de destination
Sous les réglages généraux, le formulaire « Ajouter / modifier un taux par pays » permet d'affiner le barème destination par destination :
- **Pays de destination** : sélectionné dans la liste des pays de la boutique.
- **Taux (%)** : remplace le taux global pour ce pays.
- **Frais fixes** : frais de dossier propres à ce pays.
- **Seuil de franchise** : seuil de minimis spécifique. Laissez 0 pour utiliser le seuil global.
- **Imposer le DDP pour ce pays** : rend le mode DDP obligatoire pour cette destination (le client ne peut pas choisir DAP). Cumulatif avec la liste globale des pays imposant le DDP.
Les taux enregistrés apparaissent dans un tableau récapitulatif sous le formulaire, avec une colonne « DDP imposé » (Oui / Non) et la possibilité de supprimer chaque ligne. Un pays sans taux dédié utilise automatiquement les valeurs globales.
Exemple courant : pour les États-Unis, saisissez un seuil de franchise de 800 afin de refléter le de minimis de 800 USD. Pour la Suisse ou le Royaume-Uni, définissez le taux et le seuil correspondant à leurs règles d'importation.
## Imposer le DDP pour certains pays
Pour certaines destinations, laisser le choix au client n'est pas souhaitable : c'est le cas des États-Unis, où les droits doivent être pris en charge par le vendeur. Le module permet d'imposer le mode DDP à deux niveaux :
- **Globalement**, via le champ « Pays imposant le DDP (codes ISO) » de la configuration générale (par défaut `US`).
- **Par pays**, via l'option « Imposer le DDP pour ce pays » du formulaire de taux par pays. La colonne « DDP imposé » du tableau récapitulatif affiche alors « Oui ».
Un pays est considéré comme imposant le DDP s'il figure dans la liste globale **ou** si son taux pays porte le drapeau correspondant. Pour ces destinations, le bloc de checkout n'affiche plus qu'un message indiquant que les droits doivent être réglés avec la commande : l'option DAP est retirée et le mode DDP est appliqué automatiquement, y compris si le client avait précédemment sélectionné DAP.
Si vous imposez le DDP pour un pays **sans lui associer de barème** (taux global à 0 % et aucun taux dédié), la commande est bien enregistrée en DDP mais **aucun frais n'est facturé**. Dans ce cas, le module n'affiche aucune mention douane (facture PDF, détail client, bloc back-office) afin de ne pas indiquer au client qu'il a réglé des droits qu'il n'a jamais payés. Pensez donc à définir un taux ou des frais fixes pour chaque pays où vous imposez le DDP.
## Expérience client au checkout
Lorsque la livraison est hors UE et qu'un barème s'applique, le client voit dans l'étape transporteur deux options :
### Mode DDP — payer maintenant
Le produit de frais est ajouté au panier avec un prix calculé dynamiquement. Le montant s'intègre aux totaux de la commande, apparaît sur la facture et les e-mails natifs, et le client n'a plus rien à régler à la réception du colis. C'est l'expérience la plus proche d'un achat domestique.
### Mode DAP — payer à la livraison
Aucun frais n'est ajouté à la commande, mais une estimation chiffrée est affichée et le client est averti que le transporteur lui réclamera les droits, taxes et éventuels frais de dossier avant la remise du colis. La mention figure ensuite sur sa commande et sa facture.
Le changement d'option est instantané : le panier et les totaux sont recalculés en AJAX, et la progression du checkout est préservée (le client reste à l'étape transporteur). Pour un pays imposant le DDP, seul le mode DDP est proposé.
## Suivi côté commande et facture
À la validation de la commande, le mode choisi, le montant et le pays de destination sont enregistrés. Ces informations sont ensuite visibles :
- dans le **détail de commande côté client**, avec un rappel clair de ce qui a été réglé ou reste dû ;
- sur la **fiche commande du back-office**, via un badge DDP ou DAP indiquant le montant et la destination ;
- sur la **facture PDF**, avec la mention Incoterm correspondante (DDP : droits réglés à la commande ; DAP : droits à la charge du destinataire).
Lorsqu'une commande est en DDP mais sans frais facturés (montant à 0 — par exemple un DDP imposé pour un pays sans taux configuré), aucune de ces mentions n'apparaît : ni badge back-office, ni bloc client, ni mention sur la facture.
## Traductions
Tous les libellés visibles (bloc checkout, notice panier, détail de commande, back-office, mentions de facture) sont traduits. Le module est livré avec les fichiers de traduction pour le français, l'anglais, l'espagnol, l'allemand, l'italien et le portugais. Vous pouvez aussi ajuster n'importe quel texte depuis **Paramètres avancés > Traductions > Traductions des modules** dans le back-office.
## FAQ et dépannage
### Le bloc de choix ne s'affiche pas
Vérifiez trois points : le module est activé, l'adresse de livraison est bien hors du territoire douanier UE configuré, et un barème produit un montant supérieur à zéro (taux global ou taux pays renseigné, base supérieure au seuil de franchise). Tant que le taux reste à 0 % sans frais fixes, aucun bloc n'apparaît — sauf pour un pays imposant le DDP, où un message d'information est présenté même sans montant.
### Le montant semble incorrect en multidevise
Les frais fixes et les seuils sont saisis dans la devise par défaut de la boutique puis convertis dans la devise du panier selon vos taux de change. Vérifiez que les taux de conversion de vos devises sont à jour.
### Le produit « Frais de douane » apparaît-il dans mon catalogue ?
Non. Il est créé avec une visibilité « nulle part » et n'est utilisé que comme support de facturation interne en mode DDP. Ne le supprimez pas manuellement : la désinstallation s'en charge proprement.
### Dois-je expédier différemment en DDP ?
Oui. En DDP, vous avez collecté les droits auprès du client : vous devez donc choisir un service d'expédition DDP auprès de votre transporteur ou transitaire, qui vous refacturera les droits réellement acquittés. Le module gère la collecte et l'information, pas la déclaration douanière elle-même.
### Que se passe-t-il à la désinstallation ?
La désinstallation supprime les hooks, les variables de configuration, les tables du module et le produit virtuel de frais. Aucune donnée résiduelle n'est laissée en base.
---
### Frais de Paiement (dfpaymentfees) — Guide complet
_Source :_
> Présentation DataFirefly Frais de Paiement permet d'appliquer des frais supplémentaires à chaque moyen de paiement de votre boutique PrestaShop 8 ou 9. L'objectif est double : répercuter le coût réel…
## Présentation
DataFirefly Frais de Paiement permet d'appliquer des frais supplémentaires à chaque moyen de paiement de votre boutique PrestaShop 8 ou 9. L'objectif est double : répercuter le coût réel d'un mode de règlement (commissions carte, gestion du paiement à la livraison, traitement des chèques ou virements) et orienter vos clients vers les moyens de paiement les plus avantageux pour votre boutique.
Le module repose sur un moteur de règles : chaque règle combine un montant fixe et/ou un pourcentage, une base de calcul, des plafonds, un seuil de gratuité, et un ensemble de conditions (groupe de clients, pays, devise, montant de panier). Les frais sont affichés au client pendant le tunnel de commande, puis ajoutés automatiquement à la commande à sa validation.
## Installation
1. Dans votre back-office PrestaShop, allez dans **Modules → Gestionnaire de modules → Installer un module**.
2. Sélectionnez le fichier `dfpaymentfees.zip` téléchargé depuis votre compte DataFirefly.
3. Cliquez sur **Installer** puis sur **Configurer**.
4. Videz le cache PrestaShop (**Paramètres avancés → Performance → Vider le cache**).
5. Depuis la page de configuration, cliquez sur **Gérer les règles de frais** pour créer votre première règle.
Le module est compatible PrestaShop 8.0 → 9.x et testé sur PHP 8.1 à 8.3. Aucune modification de thème n'est requise. La désinstallation supprime les tables du module et l'onglet d'administration.
## Paramètres généraux
La page de configuration du module (**Modules → Gestionnaire de modules → Frais de Paiement → Configurer**) contient deux réglages globaux :
- **Afficher les frais dans le checkout** — affiche le montant des frais à côté de chaque moyen de paiement pendant la commande. Désactivez cette option si vous préférez n'appliquer les frais qu'au moment de la validation, sans les annoncer dans la liste des moyens de paiement.
- **Libellé des frais** — libellé par défaut affiché au client et sur la commande (par exemple « Frais de paiement »). Ce champ est multilingue et peut être surchargé règle par règle.
## Créer une règle de frais
Depuis **Gérer les règles de frais**, cliquez sur **Ajouter une règle de frais**. Le formulaire est organisé en quatre blocs : identification, montant, plafonds et conditions.
### Identification
- **Active** — active ou désactive la règle sans la supprimer.
- **Libellé (client)** — le texte affiché au client au checkout et sur la commande. Champ multilingue et obligatoire.
- **Moyen de paiement** — le module concerné (par exemple `ps_wirepayment`, `ps_checkpayment`, votre module de carte bancaire…), ou **Tous les moyens de paiement** pour une règle générique.
- **Priorité** — un entier. Une valeur plus basse est évaluée en premier. Voir la section « Ordre d'évaluation » ci-dessous.
### Montant des frais
- **Frais fixe** — un montant fixe ajouté (par exemple `1.50`).
- **Frais en pourcentage** — un pourcentage appliqué à la base de calcul (par exemple `2.5` pour 2,5 %).
- **Inclure les frais de port dans la base %** — si activé, le pourcentage porte sur les produits _et_ les frais de port ; sinon uniquement sur les produits.
- **Base de calcul TTC** — choisissez si le pourcentage est calculé sur le total TTC ou sur le total HT.
Les deux montants sont cumulables. La formule appliquée est :
```
frais = frais_fixe + (base × frais_pourcentage / 100)
```
### Plafonds et gratuité
- **Frais minimum** — si le calcul donne un montant inférieur, ce minimum est appliqué. `0` = pas de minimum.
- **Frais maximum** — plafonne le montant des frais. `0` = pas de maximum.
- **Seuil de gratuité** — si le total TTC du panier atteint ce montant, aucun frais n'est appliqué. `0` = désactivé.
Le seuil de gratuité est un excellent levier de panier moyen : « Frais de paiement offerts dès 150 € d'achat » incite le client à compléter sa commande.
## Conditions d'application
Quatre familles de conditions permettent de cibler précisément quand la règle s'applique. Une liste laissée vide signifie « aucune restriction » sur ce critère.
- **Groupes de clients** — la règle ne s'applique que si le client appartient à l'un des groupes sélectionnés. Typiquement : appliquer les frais aux particuliers et en exonérer les professionnels.
- **Pays** — basé sur le _pays de l'adresse de facturation_ du panier.
- **Devises** — la règle ne s'applique qu'aux devises sélectionnées.
- **Montant panier minimum / maximum** — la règle ne s'applique que si le total TTC du panier se situe dans cette fourchette. `0` désactive la borne concernée.
En multiboutique, un champ **Boutiques** supplémentaire permet d'associer la règle à une ou plusieurs boutiques. Laisser vide associe la règle à toutes les boutiques.
## Ordre d'évaluation des règles
Pour un moyen de paiement donné, le module récupère toutes les règles actives qui ciblent ce module (ou « Tous »), triées par priorité croissante puis par identifiant. Il évalue les conditions de chaque règle dans cet ordre et **applique la première règle dont toutes les conditions sont satisfaites**. Les règles suivantes sont ignorées.
Conséquence pratique : placez vos règles les plus spécifiques (par exemple « paiement à la livraison, France, particuliers ») en priorité basse (0, 10, 20…) et vos règles génériques (« tous les moyens de paiement ») en priorité haute (100), afin qu'elles ne servent que de repli.
Cas particulier du seuil de gratuité : si une règle correspond mais que le panier atteint son seuil de gratuité, aucun frais n'est appliqué — et le module n'évalue pas les règles suivantes. La gratuité est donc une décision finale, pas un simple « passage à la règle suivante ».
## Gestion de la TVA
Deux réglages déterminent le traitement fiscal des frais :
- **Montants saisis TTC** — indiquez si les montants que vous avez renseignés (frais fixe, plafonds) incluent déjà la TVA ou non.
- **Règle de taxe** — la règle de taxe PrestaShop appliquée aux frais. Sélectionnez **Aucune taxe** pour des frais sans TVA.
Le module calcule le taux applicable à partir de la règle de taxe et de l'adresse de facturation du client, puis en déduit la ventilation :
- Si les montants sont saisis **TTC** : `HT = TTC / (1 + taux)`.
- Si les montants sont saisis **HT** : `TTC = HT × (1 + taux)`.
Les deux valeurs, ainsi que le taux appliqué, sont enregistrées sur la commande pour votre comptabilité.
### Exemple de calcul
Règle : frais fixe 1,00 € + 2 % du panier, base TTC produits + port, plafond max 5,00 €, montants saisis TTC, TVA 20 %.
- Panier : 120,00 € TTC de produits + 5,00 € TTC de port = base 125,00 €.
- Frais bruts : 1,00 + (125,00 × 2 / 100) = **3,50 € TTC**.
- Sous le plafond de 5,00 € : conservé tel quel.
- Ventilation : HT = 3,50 / 1,20 = **2,92 €**, TVA = **0,58 €**.
## Affichage côté client
Lorsque l'option **Afficher les frais dans le checkout** est activée, le module calcule les frais pour chaque moyen de paiement disponible et les transmet au front-office. Sur la page `/order` :
- Le montant des frais est ajouté à côté du libellé de chaque moyen de paiement concerné.
- Un rappel s'affiche sous la liste des moyens de paiement pour l'option actuellement sélectionnée, et se met à jour en temps réel lorsque le client change de moyen de paiement.
L'affichage est purement informatif : le montant réellement facturé est recalculé côté serveur à la validation de la commande.
## Application sur la commande
À la validation de la commande (hook `actionValidateOrder`), le module recalcule les frais pour le moyen de paiement effectivement utilisé, puis :
1. Met à jour les totaux de la commande (`total_paid`, `total_paid_tax_incl`, `total_paid_tax_excl`, et `total_paid_real` le cas échéant).
2. Met à jour les totaux de la facture si une facture existe déjà.
3. Met à jour le montant du paiement enregistré, pour rester cohérent avec le montant encaissé.
4. Enregistre la ligne de frais (libellé, HT, TTC, taux) dans la table `df_payment_fee_order`.
La ligne de frais est ensuite affichée sur la page de confirmation de commande, dans le détail de commande côté client, sur la page commande du back-office, et ajoutée à l'e-mail de confirmation.
Une protection empêche le double traitement : si une commande possède déjà une ligne de frais, le module ne fait rien.
## Compatibilité avec les passerelles de paiement
**Point important à comprendre avant la mise en production.** PrestaShop ne fournit pas de hook natif permettant d'injecter des frais propres à un moyen de paiement _dans le total du panier avant_ l'appel à la passerelle. Les frais sont donc affichés au client au checkout, puis enregistrés sur la commande après sa création.
- **Paiements hors ligne** (virement, chèque, paiement à la livraison, paiement en magasin) : le fonctionnement est complet et sans réserve. Le client voit les frais, la commande et la facture les incluent, et vous encaissez le montant total affiché.
- **Passerelles à redirection ou embarquées** (PayPal, Stripe, solutions bancaires) : le montant transmis à la passerelle est celui calculé par le module de paiement à partir du panier. Selon votre passerelle et sa configuration, ce montant peut ne pas inclure les frais. Vérifiez le comportement en environnement de test avant la mise en production.
Pour ces dernières, deux approches sont courantes : réserver les règles de frais aux moyens de paiement hors ligne, ou capturer/ajuster le montant côté passerelle. Notre support peut vous conseiller selon la passerelle utilisée.
## Multiboutique et multilingue
**Multiboutique** — chaque règle est associée à une ou plusieurs boutiques via le champ **Boutiques** du formulaire. Seules les règles associées à la boutique courante sont évaluées. Une règle enregistrée sans sélection est associée à toutes les boutiques.
**Multilingue** — le libellé de chaque règle est traduisible dans toutes les langues actives de la boutique. Si le libellé n'est pas renseigné dans la langue du client, le module utilise le libellé global défini dans les paramètres du module.
## Dépannage
### Les frais ne s'affichent pas au checkout
- Vérifiez que l'option **Afficher les frais dans le checkout** est activée dans les paramètres du module.
- Vérifiez que la règle est **active** et qu'elle cible bien le moyen de paiement concerné (ou « Tous »).
- Vérifiez que le contexte du client satisfait toutes les conditions : groupe, pays de _facturation_, devise, montant du panier.
- Assurez-vous que le panier n'atteint pas le seuil de gratuité de la règle.
- Videz le cache PrestaShop et faites un rechargement forcé du navigateur (Ctrl+F5) pour purger l'ancien JavaScript.
### Les frais s'affichent mais ne sont pas ajoutés à la commande
Le calcul au checkout et le calcul à la validation utilisent le nom technique du module de paiement. Si votre module de paiement enregistre un libellé différent du nom technique, vérifiez dans la table `df_payment_fee_order` qu'une ligne a bien été créée pour la commande. Si ce n'est pas le cas, créez une règle ciblant **Tous les moyens de paiement** pour valider le fonctionnement, puis contactez le support avec le nom du module de paiement utilisé.
### Une règle ne s'applique jamais alors qu'elle semble correcte
Une règle plus prioritaire (valeur de priorité plus basse) correspond probablement en premier. Rappelez-vous que seule la première règle correspondante est appliquée. Augmentez la priorité des règles génériques ou affinez les conditions des règles concurrentes.
### Le montant de TVA semble incorrect
Vérifiez la cohérence entre le réglage **Montants saisis TTC** et les valeurs que vous avez renseignées. Un montant saisi TTC alors que le réglage indique HT (ou l'inverse) décale la ventilation. Vérifiez également que la règle de taxe sélectionnée s'applique bien au pays de facturation du client.
### Le checkout est lent ou se fige
Assurez-vous d'utiliser la version 1.0.0 ou supérieure du module, videz le cache PrestaShop et forcez le rechargement du navigateur (Ctrl+F5) pour éliminer une version JavaScript mise en cache.
## Désinstallation
Désinstallez le module depuis le Gestionnaire de modules. La désinstallation supprime l'onglet d'administration, les variables de configuration et toutes les tables du module, y compris l'historique des frais appliqués aux commandes. Les totaux déjà enregistrés sur les commandes existantes ne sont pas modifiés.
Si vous souhaitez conserver l'historique des frais à des fins comptables, exportez la table `df_payment_fee_order` avant de désinstaller le module.
---
### Galerie Photos Clients Shoppable — Guide complet
_Source :_
> Présentation Galerie Photos Clients Shoppable (dfugcgallery) affiche les photos réelles de vos clients sur la page d'accueil et sous les fiches produits, avec des hotspots cliquables qui renvoient vers les…
## Présentation
Galerie Photos Clients Shoppable (`dfugcgallery`) affiche les photos réelles de vos clients sur la page d'accueil et sous les fiches produits, avec des hotspots cliquables qui renvoient vers les produits présents sur chaque photo. Les photos proviennent de deux sources : l'upload par vos clients connectés (acheteurs vérifiés) et l'import de vos publications Instagram via l'API officielle. Tout passe par une file de modération en back office, où vous placez également les hotspots produits.
## Installation
1. Dans votre back office PrestaShop, allez dans **Modules → Gestionnaire de modules → Installer un module**.
2. Sélectionnez le fichier `dfugcgallery.zip` et validez.
3. Le module crée automatiquement ses deux tables de base de données, son onglet d'administration **Galerie UGC** (sous Catalogue) et son dossier de stockage d'images protégé.
4. Cliquez sur **Configurer** pour ouvrir les réglages.
Le module est compatible PrestaShop 8.0 à 8.2 et 9.x, PHP 8.0 minimum. Il ne crée aucun override et n'utilise que des hooks natifs : `displayHome`, `displayFooterProduct`, `displayCustomerAccount` et `displayHeader`.
## Configuration
La page de configuration du module regroupe tous les réglages :
- **Galerie page d'accueil** : activation et nombre maximum de photos affichées.
- **Galerie fiche produit** : activation et nombre maximum de photos affichées dans le strip sous chaque fiche.
- **Auto-approbation** : si activée, les uploads clients sont publiés immédiatement sans modération. Les imports Instagram passent toujours par la modération, quel que soit ce réglage.
- **Taille maximale par fichier** : en mégaoctets, appliquée à chaque photo uploadée.
- **Token Instagram** : le token long-lived permettant l'import de vos publications (voir section suivante).
## Connecter Instagram
L'import utilise l'API officielle « Instagram API with Instagram Login ». Une configuration unique est nécessaire :
1. Rendez-vous sur le portail développeurs Meta et créez une application de type Business.
2. Ajoutez le produit **Instagram** et configurez « API setup with Instagram login ».
3. Associez le compte Instagram professionnel de votre boutique.
4. Générez un **token long-lived** avec la permission `instagram_business_basic`.
5. Collez ce token dans le champ **Token Instagram** de la configuration du module et enregistrez.
Le module rafraîchit le token automatiquement avant chaque import. Tant que vous lancez un import au moins une fois tous les 60 jours, le token ne périme jamais et vous n'avez plus à y toucher.
Pour importer, ouvrez **Catalogue → Galerie UGC** et cliquez sur le bouton **Importer depuis Instagram** de la barre d'outils. Le module récupère vos publications récentes, ignore les doublons déjà importés (déduplication par identifiant de média), prend la première image des carrousels et place tout en statut « En attente ». Les vidéos et Reels sont ignorés dans cette version.
## Upload par vos clients
Les clients connectés disposent d'un lien **Mes photos** dans leur espace client. La page d'envoi leur permet de :
- envoyer jusqu'à 5 photos par soumission (jpg, png ou webp) ;
- associer optionnellement un produit — la liste ne propose que les produits de leurs commandes valides, ce qui garantit que chaque photo taggée provient d'un acheteur vérifié ;
- ajouter une légende ;
- consulter le statut de leurs photos (en attente, approuvée, refusée) et les supprimer à tout moment.
Une case de consentement explicite est obligatoire avant tout envoi. La suppression par le client efface les fichiers du serveur, pas seulement l'entrée en base : le module est conçu pour la conformité RGPD.
## Modération
La liste **Catalogue → Galerie UGC** affiche toutes les photos avec vignette, source (Upload ou Instagram), auteur, statut et date. Vous pouvez :
- filtrer par source et par statut ;
- approuver, refuser ou supprimer chaque photo en un clic depuis les actions de ligne ;
- appliquer ces actions en masse via les cases à cocher ;
- ouvrir l'éditeur de hotspots via l'action **Voir**.
Seules les photos approuvées apparaissent sur la boutique.
## Éditeur de hotspots
L'éditeur permet d'associer des produits à des emplacements précis sur chaque photo :
1. Recherchez un produit par nom, référence ou identifiant dans le champ de recherche.
2. Sélectionnez-le puis **cliquez sur la photo** à l'endroit souhaité pour placer le point.
3. Glissez-déposez un point existant pour le repositionner.
4. Supprimez un point depuis la liste latérale si besoin.
5. Cliquez sur **Enregistrer** pour sauvegarder les positions.
Les positions sont enregistrées en pourcentage de la largeur et de la hauteur de l'image : le rendu est identique sur mobile, tablette et desktop. Côté boutique, chaque point pulse discrètement et ouvre au clic une carte produit avec le nom, le prix à jour formaté selon la devise du visiteur, l'image de couverture et un lien direct vers la fiche.
Lorsqu'un client tague un produit à l'upload, un hotspot est créé automatiquement au centre de la photo. Il vous suffit de le déplacer au bon endroit pendant la modération.
## Affichage sur la boutique
- **Page d'accueil** : grille responsive avec badge indiquant le nombre de produits taggés par photo et bouton d'appel au partage.
- **Fiche produit** : strip horizontal des photos clients liées au produit consulté.
- **Lightbox** : plein écran, navigation par flèches et clavier, hotspots animés, préférence `prefers-reduced-motion` respectée.
Le JavaScript front est en vanilla, sans jQuery, et les assets ne sont chargés que sur les pages concernées. Les images sont ré-encodées en JPEG en deux tailles (1600 px et vignette 600 px) pour préserver les performances.
## Dépannage
- **L'import Instagram échoue** : vérifiez que le token est bien un token long-lived valide associé à un compte professionnel, et que la permission de lecture des médias est accordée. Un token expiré (plus de 60 jours sans import) doit être régénéré depuis le portail Meta.
- **Une photo uploadée est refusée à l'envoi** : vérifiez le format (jpg, png, webp uniquement) et la taille maximale configurée.
- **Les photos n'apparaissent pas sur la boutique** : seules les photos au statut « Approuvée » sont affichées ; vérifiez également que la galerie concernée (accueil ou fiche produit) est activée dans la configuration.
- **Multiboutique** : chaque boutique gère sa propre galerie ; vérifiez le contexte boutique sélectionné dans le back office.
## Désinstallation
La désinstallation supprime les tables du module, son onglet d'administration et sa configuration. Les fichiers images du dossier d'upload sont également retirés avec les photos supprimées.
---
### Galerie Produit PrestaShop — Guide complet
_Source :_
> Présentation Galerie Produit PrestaShop (dossier module dfgallerypro) remplace la galerie d'images native de la fiche produit par une galerie moderne : zoom interne haute résolution au survol, vignettes verticales ou…
## Présentation
Galerie Produit PrestaShop (dossier module `dfgallerypro`) remplace la galerie d'images native de la fiche produit par une galerie moderne : zoom interne haute résolution au survol, vignettes verticales ou horizontales, visionneuse plein écran avec pincement sur mobile, filtrage des images par déclinaison sélectionnée et stratégie de chargement optimisée pour le Largest Contentful Paint.
Le module ne remplace aucun template : la galerie est montée en JavaScript à la place du bloc d'images natif, qui est masqué. Il n'utilise aucune table SQL, aucun override, et son JavaScript est écrit en natif, sans jQuery.
## Installation
### Prérequis
- PrestaShop 8.0 à 9.x
- PHP 7.4 ou supérieur
- Un thème basé sur le thème classic (ou exposant les conteneurs d'images standards de la fiche produit)
### Installer le module
1. Dans le back office, ouvrez **Modules → Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et sélectionnez l'archive `dfgallerypro.zip`.
3. Une fois l'installation terminée, cliquez sur **Configurer**.
L'installation n'ajoute aucune table en base de données : seules des clés de configuration standards sont créées. La désinstallation les supprime intégralement.
## Configuration
Tous les réglages se trouvent sur l'écran de configuration du module. Les modifications sont prises en compte immédiatement côté boutique, sans vider le cache.
### Position des vignettes
- **Gauche (vertical)** — colonne de vignettes à gauche de l'image principale. C'est le réglage par défaut.
- **Droite (vertical)** — colonne à droite de l'image principale.
- **Bas (horizontal)** — bandeau horizontal sous l'image principale.
Sur mobile (moins de 768 px), les vignettes passent toujours en bandeau horizontal défilant sous l'image principale, quel que soit le réglage choisi.
### Mode de zoom et niveau de zoom
- **Survol (zoom interne)** — le zoom suit le curseur à l'intérieur de l'image. Actif uniquement sur les appareils avec pointeur précis (ordinateurs), détectés automatiquement.
- **Clic (ouvre le plein écran)** — pas de zoom au survol ; un clic ouvre la visionneuse plein écran.
- **Désactivé** — aucune interaction de zoom sur la scène.
Le **niveau de zoom** définit le facteur de grossissement du zoom au survol, entre 1,5 et 4. La valeur recommandée se situe entre 2 et 3.
Au premier survol, le module précharge en arrière-plan l'image source originale que vous avez téléversée (sans redimensionnement) puis l'utilise pour le zoom. Plus vos images sources sont grandes, plus le zoom est net.
### Visionneuse plein écran et pincement
Quand la **visionneuse plein écran** est activée, un clic sur l'image principale (ou sur le bouton d'agrandissement en bas à droite) ouvre une visionneuse immersive sur fond sombre : compteur d'images, flèches, fermeture par la touche Échap ou par un clic sur le fond.
L'option **Zoom par pincement sur mobile** active dans cette visionneuse le pincement à deux doigts (jusqu'à ×4), le double appui pour zoomer et dézoomer, et le déplacement de l'image zoomée au doigt. Sur ordinateur, la molette de la souris permet de zoomer.
### Filtrage des images par déclinaison
- **Strict** — seules les images associées à la déclinaison sélectionnée sont affichées.
- **Intelligent (recommandé)** — les images de la déclinaison sont affichées en premier, suivies des autres images du produit.
- **Désactivé** — toutes les images sont toujours affichées.
Dans tous les modes, si la déclinaison sélectionnée n'a aucune image associée, la galerie complète est affichée en repli. La galerie se resynchronise automatiquement à chaque changement de variante, y compris après le rafraîchissement AJAX du bloc d'images par le cœur de PrestaShop.
### Lazy loading et préchargement LCP
- **Lazy loading** — seule la première image est chargée immédiatement ; les vignettes au-delà de la quatrième et les images suivantes sont chargées en différé. Les images voisines sont préchargées à chaque navigation pour des transitions instantanées.
- **Précharger l'image de couverture (LCP)** — ajoute dans l'en-tête de la page une balise de préchargement avec priorité haute pour l'image de couverture, ce qui améliore le Largest Contentful Paint de la fiche produit.
- **Afficher les flèches de navigation** — affiche des flèches précédent / suivant sur l'image principale (visibles au survol sur ordinateur, toujours visibles sur mobile).
## Associer des images aux déclinaisons
Le filtrage par déclinaison s'appuie sur les associations natives de PrestaShop, sans configuration supplémentaire dans le module :
1. Ouvrez la fiche produit dans le back office, onglet **Déclinaisons**.
2. Ouvrez chaque déclinaison et cochez les images qui lui correspondent dans la section **Images**.
3. Enregistrez : la galerie utilisera ces associations immédiatement côté boutique.
Bonnes pratiques : associez à chaque déclinaison ses photos spécifiques (couleur, finition) et laissez les photos génériques (packshots d'ambiance, tableaux de dimensions) sans association. En mode intelligent, elles resteront visibles après les photos de la déclinaison.
## Fonctionnement côté boutique
### Sur ordinateur
- Survol de l'image : zoom interne suivant le curseur (si le mode survol est actif).
- Clic sur l'image ou sur le bouton d'agrandissement : ouverture de la visionneuse plein écran.
- Flèches du clavier pour naviguer, Échap pour fermer, molette pour zoomer dans la visionneuse.
### Sur mobile
- Balayage horizontal sur l'image principale pour passer d'une image à l'autre.
- Appui sur l'image : ouverture du plein écran.
- Dans le plein écran : pincement à deux doigts, double appui, balayage pour naviguer, compteur de position.
## Performance et LCP
Le module est conçu pour améliorer les Core Web Vitals de la fiche produit plutôt que de les dégrader :
- L'image de couverture est annoncée en préchargement avec priorité haute dès l'en-tête de la page (option activable).
- La première image de scène est chargée avec l'attribut de priorité haute et un décodage asynchrone.
- Les vignettes utilisent le lazy loading natif du navigateur ; l'image originale destinée au zoom n'est chargée qu'au premier survol.
- Le JavaScript est chargé en bas de page, sans dépendance externe.
## Compatibilité thèmes et dépannage
Le module cible les conteneurs d'images standards des thèmes basés sur classic. Si votre thème utilise une structure entièrement différente, la galerie native reste affichée telle quelle, sans erreur.
- **La galerie ne s'affiche pas** — vérifiez que votre thème expose bien un conteneur d'images standard sur la fiche produit. Contactez notre support avec l'URL d'une fiche produit : l'adaptation à un thème spécifique est généralement rapide.
- **Le zoom paraît flou** — la netteté du zoom dépend de la résolution des images sources téléversées. Téléversez des images d'au moins 1500 px de large pour un résultat optimal.
- **Le filtrage ne réagit pas au changement de déclinaison** — vérifiez que les images sont bien associées aux déclinaisons dans l'onglet Déclinaisons de la fiche produit, et que le mode de filtrage n'est pas sur Désactivé.
- **Aperçu rapide** — la fenêtre d'aperçu rapide conserve volontairement la galerie native pour éviter toute interférence avec le JavaScript du cœur.
## Désinstallation
La désinstallation depuis le gestionnaire de modules supprime toutes les clés de configuration du module. Aucune donnée résiduelle ne subsiste : le module n'a créé ni table, ni override, ni fichier en dehors de son propre dossier.
## Changelog
- **1.0.0** (16/07/2026) — Version initiale : zoom HD au survol basé sur l'image originale, visionneuse plein écran avec pincement, filtrage des images par déclinaison (strict / intelligent), préchargement LCP, lazy loading, vignettes verticales ou horizontales, traductions FR, EN, ES, DE, IT.
---
### Garantie Légale de Conformité 2 ans — Installation et configuration
_Source :_
> Guide d'installation et de configuration du module Garantie Légale de Conformité pour PrestaShop 8 et 9.
Ce module affiche sur vos fiches produits les mentions d'information sur la garantie légale exigées en France : garantie légale de conformité (2 ans), garantie des vices cachés et extension de garantie après réparation. Les textes sont pré-rédigés, traduits en cinq langues et entièrement modifiables.
## Prérequis
- PrestaShop 8.0 à 9.x
- PHP 7.4 à 8.3
- Compatible multiboutique et avec les thèmes basés sur le thème classic
## Installation
1. Dans le back-office, ouvrez **Modules > Module Manager**, puis cliquez sur **Installer un module**.
2. Sélectionnez le fichier ZIP du module et lancez l'installation.
3. Une fois installé, cliquez sur **Configurer**.
Le module enregistre automatiquement ses hooks et pré-remplit les textes dans toutes les langues installées de votre boutique.
## Configuration
La page de configuration est organisée en deux panneaux : **Affichage** et **Textes des mentions**.
### Panneau Affichage
- **Activer le module** : active ou désactive l'affichage du bloc sur l'ensemble de la boutique.
- **Emplacement** : choisissez où afficher le bloc sur la fiche produit (voir la section suivante).
- **Afficher une icône** : affiche une petite icône de balance devant le titre.
- **Mentions** : activez ou désactivez indépendamment la garantie légale de conformité, la garantie des vices cachés, l'extension après réparation et la garantie commerciale.
- **Page « En savoir plus »** : associez une page CMS (CGV, conditions de garantie) ; un lien apparaît alors sous les mentions.
- **Restreindre à des catégories** : limitez l'affichage à certaines catégories. Laissez vide pour afficher partout.
### Panneau Textes des mentions
Chaque mention dispose de son propre champ, éditable langue par langue : titre du bloc, garantie légale de conformité, garantie des vices cachés, extension après réparation et garantie commerciale. Modifiez le texte affiché dans l'onglet de langue correspondant, puis enregistrez.
## Emplacements d'affichage
Quatre emplacements sont disponibles :
- **Sous le bouton « Ajouter au panier »** (informations complémentaires) : emplacement par défaut, très visible.
- **Bloc de réassurance** : intègre les mentions au bloc de réassurance du thème.
- **Bas de la fiche produit** : affiche le bloc en pied de fiche.
- **Onglet dédié** : ajoute un onglet « Garanties légales » à la fiche produit.
Les emplacements « Bloc de réassurance » et « Onglet dédié » nécessitent que votre thème implémente le hook correspondant. Le thème classic de PrestaShop les prend en charge.
## Restriction par catégories
Le décret n°2022-946 impose, pour certaines catégories de produits, un encadré rappelant la garantie légale de conformité. Pour cibler ces produits, sélectionnez les catégories concernées dans le champ **Restreindre à des catégories**. Le bloc ne s'affichera alors que sur les produits appartenant à ces catégories.
## Personnalisation des textes
Les textes par défaut couvrent la garantie légale de conformité (articles L.217-3 et suivants du Code de la consommation), la garantie des vices cachés (article 1641 du Code civil) et l'extension de 6 mois après réparation (article L.217-13). Vous pouvez les adapter à votre activité, par exemple pour les produits d'occasion ou reconditionnés, depuis le panneau Textes des mentions.
Les textes fournis sont des modèles reflétant le cadre légal français en vigueur. Nous vous recommandons de les faire valider par votre conseil juridique et de les adapter à votre activité.
## Compatibilité
- PrestaShop 8 et 9 (architecture legacy, sans Composer)
- Multiboutique : chaque boutique conserve sa propre configuration
- Aucune surcharge de template ni dépendance externe
## FAQ
### Le bloc ne s'affiche pas sur ma boutique
Vérifiez que le module est activé, que l'emplacement choisi est pris en charge par votre thème, qu'au moins une mention est active avec un texte non vide, et que la restriction par catégories n'exclut pas le produit testé.
### Puis-je afficher le bloc à plusieurs endroits ?
Le module affiche le bloc à l'emplacement sélectionné. Pour un autre besoin, contactez le support.
### Le module ralentit-il la boutique ?
Non. Il ne s'affiche que sur les fiches produits concernées et n'ajoute aucune dépendance externe.
---
### Générateur de FAQ Schema.org — Documentation
_Source :_
> Présentation DfFaqSchema ajoute des blocs de questions-réponses éditables sur les fiches produits, les pages de catégories et les layouts Shopping Experiences de Shopware 6. Chaque bloc est rendu sous forme…
## Présentation
DfFaqSchema ajoute des blocs de questions-réponses éditables sur les fiches produits, les pages de catégories et les layouts Shopping Experiences de Shopware 6. Chaque bloc est rendu sous forme d'accordéon Bootstrap et accompagné d'un balisage Schema.org FAQPage en JSON-LD, injecté automatiquement dans la page. Le plugin est compatible Shopware 6.5, 6.6 et 6.7 et ne nécessite aucune modification de votre thème.
## Installation
### Via l'administration
1. Ouvrez Extensions puis Mes extensions et téléversez le fichier ZIP du plugin.
2. Cliquez sur Installer, puis activez le plugin.
### Via la console
```
bin/console plugin:refresh
bin/console plugin:install --activate DfFaqSchema
bin/console cache:clear
```
### Compilation de l'administration
Le module d'administration et l'élément CMS nécessitent une compilation unique des assets :
```
./bin/build-administration.sh
```
Sans cette étape, le menu FAQ Schema.org et l'élément CMS n'apparaissent pas dans l'administration. Le storefront fonctionne quant à lui immédiatement après l'activation.
## Configuration
Ouvrez Extensions, Mes extensions, puis la configuration de DfFaqSchema. Deux options sont disponibles, réglables globalement ou par canal de vente :
- **Afficher les FAQ sur les fiches produits** : active l'accordéon et le JSON-LD sur les pages produits (activé par défaut).
- **Afficher les FAQ sur les pages de catégories** : active l'accordéon et le JSON-LD sur les pages de navigation (activé par défaut).
## Créer des entrées FAQ
Ouvrez Contenus puis FAQ Schema.org. Le listing affiche toutes les entrées avec leur question, leur assignation, leur position et leur statut.
### Champs d'une entrée
- **Question** : le texte de la question (champ traduit).
- **Réponse** : la réponse en texte enrichi via l'éditeur intégré (champ traduit).
- **Position** : l'ordre d'affichage dans l'accordéon, croissant.
- **Actif** : seules les entrées actives sont affichées et balisées.
- **Assignation** : produit, catégorie ou page CMS. Le sélecteur de type affiche le champ de recherche correspondant.
### Traduire une entrée
Utilisez le sélecteur de langue en haut de la page de détail pour basculer de langue, puis saisissez la question et la réponse traduites. Chaque vitrine affiche les contenus de sa langue et le JSON-LD suit automatiquement.
Une entrée sans traduction dans une langue retombe sur la langue par défaut du système, selon le mécanisme standard de Shopware.
## Affichage produit et catégorie
Les entrées assignées à un produit s'affichent sous le contenu principal de la fiche produit. Les entrées assignées à une catégorie s'affichent sous le listing de la page de navigation. Dans les deux cas, le JSON-LD FAQPage correspondant est injecté dans l'en-tête du document. La première question de l'accordéon est ouverte par défaut.
## Élément CMS pour les Shopping Experiences
1. Créez vos entrées dans le module sans les assigner à un produit ou une catégorie (assignation page CMS).
2. Ouvrez Contenus puis Expériences d'achat et éditez un layout.
3. Ajoutez un bloc de texte, puis remplacez son élément par l'élément **FAQ (Schema.org)**.
4. Dans la configuration de l'élément, sélectionnez les entrées à afficher.
L'accordéon et son JSON-LD sont rendus à l'emplacement exact de l'élément. Vous pouvez utiliser plusieurs éléments FAQ sur un même layout.
## Balisage JSON-LD et validation
Le plugin génère un objet FAQPage contenant une entité Question par entrée affichée, avec la réponse en HTML dans le champ text de l'entité Answer, ce que Google accepte. Le balisage ne couvre que le contenu réellement visible sur la page, conformément aux consignes rich results.
Pour valider une page, utilisez le test des résultats enrichis de Google : collez l'URL de votre fiche produit et vérifiez que l'élément FAQ est détecté sans erreur.
L'affichage effectif des rich results reste à la discrétion de Google, qui les réserve principalement aux sites gouvernementaux et médicaux depuis 2023. Le balisage reste utile pour la compréhension de vos pages par les moteurs et les assistants IA.
## Dépannage
- **Le menu FAQ Schema.org n'apparaît pas** : exécutez la compilation de l'administration puis videz le cache du navigateur.
- **L'accordéon ne s'affiche pas sur une fiche produit** : vérifiez que l'entrée est active, qu'elle est bien assignée à ce produit et que l'option d'affichage produit est activée pour le canal de vente concerné.
- **Le JSON-LD est absent** : le balisage n'est généré que si au moins une entrée active est affichée sur la page. Vérifiez le code source de la page en recherchant application/ld+json.
- **L'élément CMS n'affiche rien** : vérifiez que des entrées ont été sélectionnées dans la configuration de l'élément et qu'elles sont actives.
## Désinstallation
La désinstallation supprime les tables du plugin et sa configuration. Cochez l'option de conservation des données lors de la désinstallation pour préserver vos questions-réponses en vue d'une réinstallation.
---
### Gestion DLC & DLUO — Documentation
_Source :_
> Installation Le module s'installe comme n'importe quel module PrestaShop, sans dépendance ni Composer. Dans votre back-office, ouvrez Modules → Gestionnaire de modules. Cliquez sur Installer un module et déposez le…
## Installation
Le module s'installe comme n'importe quel module PrestaShop, sans dépendance ni Composer.
1. Dans votre back-office, ouvrez **Modules → Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez le fichier `dfdlc-1.0.0.zip`.
3. Une fois l'installation terminée, cliquez sur **Configurer**.
À l'installation, le module crée deux tables (lots et mouvements de stock), ajoute l'onglet **Catalogue → Lots DLC/DLUO** et enregistre quatre hooks : `displayHeader`, `displayProductAdditionalInfo`, `actionValidateOrder` et `actionProductDelete`.
Si l'onglet Lots DLC/DLUO n'apparaît pas immédiatement dans le menu Catalogue, videz le cache PrestaShop depuis Paramètres avancés → Performances, puis reconnectez-vous au back-office.
## Comprendre DLC et DLUO
Le module distingue deux types de date, et cette distinction n'est pas cosmétique : elle détermine ce que le module s'autorise à faire automatiquement.
### DLC — date limite de consommation
Mention « à consommer jusqu'au ». Elle concerne les denrées microbiologiquement périssables. Au-delà de cette date, le produit est réputé dangereux et sa commercialisation est interdite. Le module applique donc aux lots DLC les actions automatiques sur le stock et, si vous le souhaitez, la désactivation du produit.
### DLUO / DDM — date de durabilité minimale
Mention « à consommer de préférence avant ». Elle signale une perte de qualité, pas un risque sanitaire. Le produit reste légalement vendable après cette date, sous réserve d'une information claire du client. Le module se limite donc à désactiver le lot échu : il ne retire jamais le stock et ne désactive jamais le produit sur une DLUO.
Choisissez le type de date avec attention à la création de chaque lot. C'est ce champ, et lui seul, qui déclenche ou non les actions automatiques sur le stock à l'expiration.
## Configurer le module
La page de configuration regroupe l'ensemble des réglages, ainsi que l'URL de la tâche cron et un état rapide de vos lots.
### Affichage en front-office
- **Afficher la date sur la fiche produit** : affiche la date du lot disponible le plus proche, avec la mention adaptée au type de date.
- **Seuil du badge date courte (jours)** : en dessous de ce nombre de jours restants, un badge « Date courte » apparaît à côté de la date. Valeur par défaut : 10 jours.
### Promotions automatiques
- **Activer les promotions automatiques** : active ou coupe entièrement le mécanisme.
- **Appliquer la remise à partir de (jours)** : fenêtre avant la date limite dans laquelle un lot devient éligible. Valeur par défaut : 15 jours.
- **Pourcentage de remise** : taux appliqué, entre 1 et 90 %. Valeur par défaut : 30 %.
### Traitement des lots périmés
Trois modes sont disponibles, du plus prudent au plus automatique :
1. **Désactiver le lot uniquement** — aucune action sur le stock. À privilégier si vous préférez arbitrer chaque cas manuellement.
2. **Désactiver le lot et retirer sa quantité restante du stock** — aligne immédiatement le stock PrestaShop sur la réalité de l'entrepôt. C'est le mode recommandé.
3. **Retirer le stock et désactiver le produit s'il ne reste aucun lot valide** — évite la vente d'un article dont tout le stock est périmé.
### Alertes
- **Seuil d'alerte (jours avant expiration)** : fenêtre de surveillance pour l'e-mail récapitulatif. Valeur par défaut : 30 jours.
- **E-mail destinataire** : laissez vide pour utiliser l'adresse de la boutique.
## Créer et gérer les lots
Rendez-vous dans **Catalogue → Lots DLC/DLUO**. La liste affiche vos lots triés par date d'expiration croissante, avec un code couleur et le nombre de jours restants. Deux indicateurs en tête de page rappellent le nombre de lots périmés encore actifs et le nombre de lots proches de l'échéance.
### Ajouter un lot
1. Cliquez sur **Ajouter un lot**.
2. Saisissez au moins deux caractères dans le champ Produit : la recherche propose les produits correspondants. Sélectionnez-en un.
3. Si le produit a des déclinaisons, un second champ apparaît. Laissez « Toutes les déclinaisons » pour rattacher le lot au produit entier, ou choisissez une déclinaison précise.
4. Renseignez le numéro de lot, le type de date, la date limite et la quantité reçue.
5. La référence fournisseur et la note sont facultatives mais utiles en cas de rappel.
Vous pouvez mélanger les deux niveaux sur un même produit : quelques lots rattachés à une déclinaison précise et un lot générique au niveau produit. Le déstockage consomme d'abord les lots de la déclinaison commandée, puis les lots du produit.
### Modifier ou supprimer un lot
L'édition permet d'ajuster la quantité (après un inventaire par exemple) ou de corriger une date. La suppression d'un lot retire également la règle de prix associée si une promotion automatique était en cours, ainsi que son historique de mouvements.
### Exporter
Le bouton d'export de la liste génère un CSV de vos lots, filtres et tri appliqués compris. Pratique pour un contrôle qualité ou un inventaire.
## Le déstockage FEFO
FEFO signifie First Expired, First Out : le lot dont la date est la plus proche sort en premier. Aucun réglage n'est nécessaire, le mécanisme s'applique automatiquement.
À la validation d'une commande, pour chaque ligne de produit, le module :
1. rassemble les lots actifs du produit ayant encore une quantité disponible ;
2. place en tête ceux rattachés à la déclinaison exactement commandée, puis ceux rattachés au produit ;
3. trie ce sous-ensemble par date d'expiration croissante ;
4. décompte la quantité commandée en remontant cette liste, lot après lot.
Exemple : une commande de 10 unités face à un lot de 4 (expirant le 12 août) et un lot de 8 (expirant le 3 octobre) consommera les 4 unités du premier lot, puis 6 unités du second. Les deux mouvements sont enregistrés séparément, avec la même commande d'origine.
Le déstockage FEFO est indépendant du stock PrestaShop, qui continue de fonctionner normalement. Le module tient la ventilation de ce stock en lots datés ; le stock PrestaShop reste la référence pour la disponibilité à la vente.
## Promotions automatiques sur les dates courtes
Quand un lot entre dans la fenêtre configurée, le cron crée une règle de prix catalogue (une _specific price_ PrestaShop standard) sur le produit :
- remise en pourcentage, au taux que vous avez défini ;
- date de début : le jour de création ;
- date de fin : la date de péremption du lot, à 23h59.
La promotion s'éteint donc d'elle-même à l'échéance, sans laisser de règle orpheline dans votre catalogue. Le module ne crée qu'une seule promotion à la fois par produit, même si plusieurs lots entrent simultanément dans la fenêtre.
Côté client, la remise s'affiche normalement sur la fiche produit, et le badge « Date courte » indique le pourcentage en cours.
La règle créée est une règle de prix catalogue standard, soumise aux mêmes mécanismes de priorité que vos autres règles. Si vous appliquez déjà des remises catalogue larges, vérifiez la cohérence des priorités avant d'activer les promotions automatiques.
## Configurer la tâche cron
Le déstockage FEFO fonctionne sans cron, puisqu'il est déclenché par les commandes. En revanche, trois traitements nécessitent un appel quotidien : les promotions automatiques, le traitement des lots périmés et l'alerte e-mail.
L'URL sécurisée par jeton est affichée dans la page de configuration du module. Elle a la forme suivante :
```
https://votre-boutique.com/index.php?fc=module&module=dfdlc&controller=cron&token=VOTRE_JETON
```
Programmez un appel par jour, de préférence tôt le matin. Deux méthodes courantes :
- **Cron de votre hébergeur** : ajoutez une tâche quotidienne appelant l'URL avec `wget` ou `curl`.
- **Service externe** : n'importe quel service de cron en ligne accepte cette URL.
La réponse est un JSON détaillant l'exécution :
```
{
"success": true,
"promos_applied": 3,
"expired": {
"lots_deactivated": 2,
"stock_deducted": 7,
"products_disabled": 0
},
"alerts_sent": 5
}
```
Ce format est directement exploitable dans un outil de supervision, ce qui évite de laisser l'automatisation tourner à l'aveugle.
Le jeton est généré aléatoirement à l'installation. Si vous pensez qu'il a fuité, réinstallez le module pour en générer un nouveau, et pensez à mettre à jour votre tâche planifiée.
## Les alertes e-mail
À chaque exécution du cron, le module recherche les lots dont la date arrive dans la fenêtre d'alerte et qui n'ont pas encore été signalés. S'il en trouve, il envoie un e-mail récapitulatif unique listant, pour chaque lot : le numéro, le produit, le type de date, l'échéance et la quantité restante.
Chaque lot n'est signalé qu'une seule fois, grâce à un marqueur en base. Vous ne recevez donc pas le même rappel tous les jours.
Les modèles d'e-mail sont fournis en français et en anglais dans le dossier `mails/` du module. Vous pouvez les personnaliser librement, ou en ajouter d'autres langues en dupliquant un dossier existant.
## Affichage sur la fiche produit
Le module utilise le hook `displayProductAdditionalInfo`, présent dans les thèmes Classic, Hummingbird et la grande majorité des thèmes tiers. Le bloc affiche :
- la mention adaptée au type de date : « À consommer jusqu'au » pour une DLC, « À consommer de préférence avant » pour une DLUO ;
- la date du lot disponible le plus proche ;
- le badge « Date courte » si le seuil est franchi, avec le pourcentage de remise si une promotion est active.
Si le produit n'a aucun lot actif avec du stock et une date valide, rien ne s'affiche : aucun cadre vide n'apparaît sur la fiche.
### Personnaliser l'affichage
Le rendu est isolé dans le template `views/templates/hook/product-expiry.tpl` et les styles dans `views/css/front.css`. Vous pouvez surcharger le template depuis votre thème pour ajuster la position ou la mise en forme, sans modifier le module.
## Traçabilité et rappel de lot
Chaque sortie de stock est enregistrée dans la table des mouvements avec le lot concerné, la quantité et la commande à l'origine. Vous pouvez donc, à partir d'un numéro de lot, remonter la liste des commandes qui l'ont consommé.
C'est la base d'une procédure de rappel. Le module fournit la donnée brute ; la procédure de rappel elle-même (information des clients, gestion des retours, déclaration éventuelle aux autorités) relève de votre organisation qualité.
## Questions fréquentes
### Le module remplace-t-il le stock PrestaShop ?
Non, il le complète. Les quantités PrestaShop restent la référence pour la vente. Le module tient en parallèle la ventilation de ce stock en lots datés. En mode retrait du stock, il ajuste la quantité PrestaShop lorsqu'un lot DLC périmé est retiré, pour que les deux vues restent cohérentes.
### Que se passe-t-il si mes lots ne couvrent pas tout mon stock ?
Rien de bloquant. Le déstockage FEFO ne consomme que ce qui est disponible dans les lots ; si les lots sont épuisés, la commande se poursuit normalement et seule la quantité PrestaShop est décomptée. À vous de compléter la saisie des lots à mesure des réceptions.
### Puis-je saisir un lot avec une date déjà passée ?
Oui, mais il sera traité comme périmé à la prochaine exécution du cron. Pour l'historique, mieux vaut le saisir avec sa vraie date puis laisser le module faire son travail.
### Le module est-il compatible multiboutique ?
Oui. Chaque lot est rattaché à la boutique dans laquelle il a été créé, et les retraits de stock sont appliqués sur cette boutique.
### Que se passe-t-il à la désinstallation ?
Les deux tables sont supprimées, l'onglet d'administration est retiré et les hooks désenregistrés. Les lots et leur historique ne sont pas conservés : sauvegardez votre base si vous prévoyez une réinstallation.
---
### Google Fonts Local — Polices Auto-hébergées RGPD (dffontmanager)
_Source :_
> DF Font Manager héberge vos polices Google Fonts directement sur votre serveur PrestaShop : vos visiteurs ne contactent plus jamais les serveurs de Google (conformité RGPD), et vous changez la…
DF Font Manager héberge vos polices Google Fonts directement sur votre serveur PrestaShop : vos visiteurs ne contactent plus jamais les serveurs de Google (conformité RGPD), et vous changez la typographie de votre boutique par simples règles CSS, sans modifier un seul fichier du thème. Le module gère l'import depuis le catalogue Google Fonts, le subsetting automatique par alphabet, le préchargement du fichier critique, la stratégie font-display et l'upload de polices maison.
Cette documentation couvre la version **1.0.0** du module, compatible PrestaShop **8.0.0 à 9.x**. Aucun override de classe, aucune dépendance Composer, JS vanilla sans jQuery.
## Installation
1. Dans votre back-office PrestaShop, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez le fichier `dffontmanager.zip`.
3. Un onglet **Gestionnaire de polices** apparaît sous le menu **Design** : c'est là que tout se passe (le bouton Configurer du module y redirige également).
Le module s'enregistre sur trois hooks (`displayHeader`, `actionFrontControllerSetMedia`, `actionOutputHTMLBefore`) et crée deux tables : les polices installées et les règles de remplacement. Les fichiers de police sont stockés dans `modules/dffontmanager/views/fonts/` et la feuille de style générée dans `modules/dffontmanager/views/css/generated/` — vérifiez que ces dossiers sont accessibles en écriture.
## Réglages généraux
- **Activer les polices auto-hébergées** — interrupteur principal : charge la feuille de style générée et les balises de préchargement en front-office.
- **Supprimer les appels externes Google Fonts (RGPD)** — nettoie le HTML rendu de la boutique : toutes les balises link pointant vers `fonts.googleapis.com` ou `fonts.gstatic.com` (feuilles de style, preconnect, préchargements) ainsi que les `@import` inline correspondants sont retirés avant l'envoi de la page. C'est cette option qui garantit qu'aucune requête ne part vers Google, même si votre thème ou un autre module en injecte.
- **Stratégie font-display** — appliquée à toutes les déclarations `@font-face` générées. `swap` (défaut) garde le texte visible pendant le chargement ; `block`, `fallback`, `optional` et `auto` sont disponibles pour des besoins spécifiques.
Recommandation : laissez `swap`. C'est le meilleur compromis Core Web Vitals — pas de texte invisible (FOIT), pas de pénalité LCP.
## Importer une police Google Fonts
1. Dans le panneau **Importer une police Google**, tapez au moins deux caractères : l'autocomplétion parcourt le catalogue Google Fonts complet, mis en cache 7 jours sur votre serveur (bouton de rafraîchissement à côté du champ).
2. Sélectionnez une famille : les **variantes** disponibles (graisses 100 à 900, normal et italique) et les **alphabets** s'affichent. Par défaut, les graisses 400 et 700 et les subsets latin + latin-ext sont pré-cochés.
3. Cliquez sur **Importer localement**.
Le module interroge alors l'API CSS de Google, télécharge les fichiers woff2 officiels correspondant à votre sélection (un fichier par alphabet et par variante), vérifie leur signature binaire, les range dans `views/fonts/nom-de-la-famille/` et régénère la feuille de style. La page se recharge avec la famille visible dans le tableau des polices installées, avec son poids total sur disque.
Le téléchargement s'effectue une seule fois, de serveur à serveur, au moment de l'import. Vos visiteurs ne participent jamais à cette requête : côté front, tout est servi depuis votre domaine.
### Le subsetting automatique
Google découpe chaque police en fichiers par alphabet (latin, latin-ext, cyrillique, grec, vietnamien, etc.). Le module ne télécharge que les alphabets cochés et conserve pour chaque fichier son `unicode-range` d'origine dans la déclaration `@font-face`. Le navigateur ne demande donc que les plages de caractères réellement affichées sur la page : une boutique francophone typique sert 20 à 90 Ko de polices au lieu de plusieurs centaines.
Ne cochez que les alphabets de votre audience réelle. Vous pourrez toujours réimporter la famille plus tard avec des subsets supplémentaires : l'import remplace proprement les fichiers existants en conservant vos réglages (préchargement, activation) et vos règles.
### Réimporter ou modifier une famille
Pour ajouter une graisse ou un alphabet à une famille déjà installée, refaites simplement l'import avec la nouvelle sélection : les anciens fichiers de la famille sont remplacés, les règles de remplacement qui l'utilisent restent intactes.
## Uploader une police maison
Le panneau **Upload d'une police personnalisée** accepte les formats `woff2` (recommandé), `woff`, `ttf` et `otf`. Indiquez le nom de la famille, la graisse et le style, puis envoyez le fichier — un fichier par combinaison graisse/style, fusionnés automatiquement sous la même famille. Chaque fichier est validé par sa signature binaire (et non par son extension), puis intégré à la feuille générée et disponible dans les règles exactement comme une police Google.
Vérifiez que votre licence autorise l'usage web en auto-hébergement, notamment pour les polices commerciales achetées auprès de fonderies.
## Gérer les polices installées
Le tableau des polices installées affiche pour chaque famille : la source (google ou custom), les variantes, les subsets, le nombre de fichiers et leur poids sur disque, puis deux interrupteurs :
- **Actif** — inclut ou exclut la famille de la feuille de style générée (les fichiers restent sur le disque).
- **Préchargement** — voir la section dédiée ci-dessous.
Le bouton de suppression retire la famille, ses fichiers sur disque et toutes les règles qui l'utilisent, puis reconstruit la feuille de style.
## Règles de remplacement
C'est ici que vous appliquez vos polices sans toucher au thème. Chaque règle associe un **sélecteur CSS** à une **police installée**, avec quatre options :
- **Graisse** — force un `font-weight` (laissez vide pour hériter du thème) ;
- **Style** — normal ou italique (vide pour hériter) ;
- **Pile de secours** — familles génériques affichées si la police n'est pas encore chargée : `sans-serif`, `serif`, `monospace` ou `system-ui, sans-serif` ;
- **!important** — coché par défaut, garantit que la règle l'emporte sur les styles du thème quelle que soit leur spécificité.
Exemples de sélecteurs courants :
- `body` — toute la boutique ;
- `h1, h2, h3, h4, h5, h6` — tous les titres ;
- `.btn, button` — les boutons ;
- `.product-title, .h3.product-title` — les titres produits des listings (à adapter à votre thème).
Configuration type en deux règles : `body` vers votre police en 400 avec pile `sans-serif`, puis `h1, h2, h3, h4` vers la même famille en 700. Inspectez votre thème avec les outils de développement du navigateur pour identifier les sélecteurs à cibler plus finement.
Chaque ajout ou suppression de règle reconstruit immédiatement la feuille de style. La feuille est chargée _après_ le CSS du thème : même sans `!important`, vos règles gagnent la cascade à spécificité égale.
## Préchargement — bonnes pratiques
L'interrupteur **Préchargement** d'une famille émet en tête de page une balise `link rel=preload as=font crossorigin` pour son fichier critique, choisi automatiquement : woff2, style normal, alphabet latin, graisse la plus proche de 400. Le navigateur télécharge ainsi la police en parallèle du CSS, avant même d'en découvrir l'usage — le texte définitif s'affiche plus tôt.
Ne préchargez qu'une ou deux familles réellement utilisées au-dessus de la ligne de flottaison. Chaque préchargement consomme de la bande passante prioritaire : en abuser dégrade le LCP au lieu de l'améliorer.
## Fonctionnement technique
- La feuille générée `fonts-v{horodatage}.css` contient toutes les déclarations `@font-face` (avec `font-display` et `unicode-range`) suivies des règles de remplacement. Chaque reconstruction produit un nouveau nom de fichier (cache-busting automatique) et purge les anciennes versions.
- Elle est enregistrée via `actionFrontControllerSetMedia` avec une priorité qui la place après le CSS du thème.
- Les balises de préchargement sont émises par `displayHeader` ; la liste des fichiers critiques est mise en cache en configuration — aucune requête SQL supplémentaire par page front.
- La suppression des appels externes s'exécute dans `actionOutputHTMLBefore`, sur le HTML final, après le cache Smarty.
- Le bouton **Reconstruire le CSS** force une régénération complète — utile après une intervention manuelle sur les fichiers ou une restauration de sauvegarde.
## Vérifier la conformité RGPD
1. Ouvrez votre boutique dans une fenêtre de navigation privée.
2. Ouvrez les outils de développement (F12), onglet **Réseau**, et filtrez sur `fonts.g`.
3. Rechargez la page : la liste doit rester vide. Si une requête vers `fonts.googleapis.com` ou `fonts.gstatic.com` apparaît, activez l'option de suppression des appels externes et videz le cache PrestaShop.
Testez la page d'accueil, une fiche produit et le checkout : certains modules de paiement ou de widgets tiers chargent leurs propres polices dans des iframes, hors de portée du nettoyage HTML (leurs bandeaux de consentement respectifs s'appliquent alors).
## Multiboutique
Les polices importées et les règles de remplacement sont partagées entre toutes les boutiques d'une même installation. Les interrupteurs d'activation et l'option de suppression des appels externes suivent le contexte de configuration PrestaShop standard.
## Dépannage
- **La police ne s'affiche pas en front** — vérifiez dans l'ordre : l'interrupteur principal est activé, la famille est active, une règle de remplacement existe pour le bon sélecteur, et le cache PrestaShop est vidé (Paramètres avancés > Performances). Inspectez ensuite l'élément dans le navigateur : si la règle apparaît barrée, un style du thème plus spécifique la surcharge — cochez `!important` sur la règle.
- **L'import échoue avec une erreur réseau** — votre serveur doit pouvoir joindre `fonts.googleapis.com` et `fonts.gstatic.com` en sortie (cURL ou allow_url_fopen). Sur un serveur derrière un pare-feu strict, demandez l'ouverture de ces deux domaines à votre hébergeur.
- **L'autocomplétion ne propose rien** — le catalogue n'a pas pu être téléchargé (réseau). Cliquez sur le bouton de rafraîchissement du catalogue, ou tapez le nom exact de la famille et validez avec Entrée : l'import direct fonctionne sans le catalogue.
- **Erreur d'écriture à l'import ou à la reconstruction** — donnez les droits d'écriture au serveur web sur `modules/dffontmanager/views/fonts/` et `modules/dffontmanager/views/css/generated/`.
- **Des appels Google subsistent malgré l'option de suppression** — identifiez la source dans l'onglet Réseau (colonne initiateur). S'il s'agit d'une iframe tierce (paiement, avis, carte), le nettoyage HTML ne peut pas s'y appliquer : c'est le consentement de ce service tiers qui gouverne.
## Mise à jour du module
Les fichiers de police et la feuille générée vivent dans le dossier du module. Une mise à jour effectuée en **écrasant le dossier**`modules/dffontmanager/` supprime les polices importées. Après une telle mise à jour, ouvrez le gestionnaire et réimportez vos familles (deux clics par famille : vos réglages et règles, stockés en base, sont conservés). Une mise à jour via le Gestionnaire de modules standard déclenche le même comportement : prévoyez la réimportation dans la foulée.
## Désinstallation
La désinstallation supprime les deux tables, les clés de configuration, les fichiers de police téléchargés et la feuille de style générée. Votre boutique retrouve instantanément les polices d'origine de son thème — aucun résidu.
---
### Google Tag Pro (GTM & GA4) — Guide complet
_Source :_
> Google Tag Pro (module dfgtagmanager) installe un tracking e-commerce complet et fiable sur votre boutique : 16 événements GA4 Enhanced Ecommerce, Consent Mode v2, Enhanced Conversions, suivi des conversions Google…
Google Tag Pro (module `dfgtagmanager`) installe un tracking e-commerce complet et fiable sur votre boutique : 16 événements GA4 Enhanced Ecommerce, Consent Mode v2, Enhanced Conversions, suivi des conversions Google Ads, pixels publicitaires, Server-side GTM et un système de **Conversion Recovery** qui rejoue les conversions perdues. Ce guide couvre l'installation, chaque section de configuration et le dépannage.
## Prérequis
- PrestaShop 8.0 à 9.0 (PHP 8.1 à 8.4 recommandé).
- Un compte **Google Tag Manager** avec un conteneur Web (ID au format `GTM-XXXXXXX`).
- Une propriété **Google Analytics 4** (ID de mesure au format `G-XXXXXXXXXX`).
- Facultatif : un compte Google Ads (ID de conversion `AW-XXXXXXXXX`), Google Merchant Center, et/ou un serveur sGTM.
## Installation
1. Dans le back-office, allez dans **Modules > Module Manager**, cliquez sur **Installer un module** et sélectionnez le fichier `dfgtagmanager.zip`.
2. Une fois installé, cliquez sur **Configurer**.
3. Le module crée ses tables (journal des conversions et des événements) et enregistre ses hooks automatiquement.
Le module est compatible multiboutique : chaque boutique conserve son propre conteneur GTM, son ID GA4, ses pixels et ses réglages de consentement. Configurez chaque contexte depuis le sélecteur de boutique en haut de page.
## 1. Configuration Google Tag Manager
Dans la section **Google Tag Manager – Configuration** :
- **Activer GTM** : active l'injection du conteneur sur le front-office.
- **ID Conteneur GTM** : votre identifiant `GTM-XXXXXXX`. Tant qu'il est vide, le module n'injecte rien.
- **ID de mesure GA4** : votre identifiant `G-XXXXXXXXXX`. Il est utilisé pour pré-remplir le tag GA4 dans l'export du conteneur.
Le module pousse les données dans le `dataLayer`_avant_ le chargement de GTM, afin que tous vos tags disposent immédiatement des données de page et e-commerce.
## 2. Événements de tracking (GA4 Enhanced Ecommerce)
Une fois activé, le module envoie automatiquement jusqu'à 16 événements conformes au schéma GA4 officiel :
- **Découverte** : `view_item`, `view_item_list`, `select_item`
- **Panier & checkout** : `add_to_cart`, `remove_from_cart`, `view_cart`, `begin_checkout`, `add_shipping_info`, `add_payment_info`
- **Conversion** : `purchase` (avec `items[]`, `value`, `tax`, `shipping`, `coupon`, `transaction_id`)
- **Utilisateur & marketing** : `login`, `sign_up`, `search`, `add_to_wishlist`, `view_promotion`, `select_promotion`
Les événements panier, checkout, promotions et recherche sont déclenchés côté navigateur (interception AJAX et `IntersectionObserver`), l'événement `purchase` est construit côté serveur à la confirmation de commande.
Depuis la version 1.2.0, l'événement `search` est émis côté client afin de rester compatible avec PrestaShop 9.1, où le hook `displaySearch` est déprécié. Aucune action n'est nécessaire de votre part.
Réglages associés dans la section **Événements de tracking** : activez/désactivez GA4 Enhanced Ecommerce, les données utilisateur (`user_data`), la recherche interne, login, inscription, promotions, wishlist et le remarketing dynamique.
## 3. Consent Mode v2 (RGPD / DMA)
Le Consent Mode v2 est obligatoire depuis mars 2024 pour mesurer les conversions Google dans l'EEE. Dans la section **Consent Mode v2** :
- **Activer Consent Mode v2** : injecte les valeurs de consentement par défaut avant GTM.
- **analytics_storage / ad_storage par défaut** : laissez sur **Refusé** (recommandé RGPD) ; le consentement sera mis à jour par votre bannière.
Le module active aussi `url_passthrough` et `ads_data_redaction` pour maximiser la modélisation des conversions en l'absence de consentement.
### Connecter votre bandeau cookies (CMP)
Quand le visiteur accepte ou refuse, appelez la fonction fournie par le module depuis votre CMP (Tarteaucitron, Axeptio, Cookiebot, etc.) :
```
DFGTM.updateConsent({
analytics_storage: 'granted',
ad_storage: 'granted',
ad_user_data: 'granted',
ad_personalization: 'granted'
});
```
Si vous n'appelez jamais `updateConsent()`, le consentement reste sur les valeurs par défaut (refusé) et vous ne collecterez que des données modélisées. Reliez impérativement votre CMP.
## 4. Enhanced Conversions
Lorsqu'ils sont activés, les Enhanced Conversions améliorent l'attribution Google Ads. Le module hashe côté serveur en **SHA-256** les données du client (e-mail, nom, téléphone, ville) et les transmet via le `dataLayer`. Les données ne sont jamais transmises en clair ; le code postal et le pays sont envoyés non hashés, conformément aux spécifications Google.
## 5. Conversions Google Ads & Merchant Center
Dans la section **Google Ads – Suivi des conversions** :
- **Activer Google Ads Conversion** : ajoute le Conversion Linker, le tag de conversion d'achat et le remarketing dynamique à l'export GTM.
- **Conversion ID** : votre identifiant `AW-XXXXXXXXX`.
- **Conversion Label (Achat)** : le label de la conversion « Achat » (chaîne alphanumérique).
- **Merchant Center ID** + **pays** et **langue du flux** : requis pour les « conversions avec données du panier ».
- **Source de l'ID produit** : choisissez le format correspondant au champ `id` de votre flux Merchant Center (ID + séparateur + déclinaison, référence/SKU, ID seul, EAN13, UPC ou MPN).
La source de l'ID produit doit correspondre **exactement** à l'ID utilisé dans votre flux Merchant Center, sinon les conversions avec données panier ne remonteront pas. En cas de doute, utilisez la même source que votre module de flux produit.
## 6. Pixels publicitaires (Meta, TikTok, Pinterest)
Dans la section **Pixels publicitaires**, saisissez vos identifiants Facebook/Meta, TikTok et Pinterest. Ils sont intégrés à l'export du conteneur GTM avec les événements e-commerce mappés automatiquement (Purchase, AddToCart, ViewContent, InitiateCheckout, Search / CompletePayment / checkout selon la plateforme).
## 7. Export du conteneur GTM
Plutôt que de créer manuellement des dizaines de tags, le module génère un conteneur prêt à importer :
1. Dans la section **Export conteneur GTM**, cliquez sur **Exporter le conteneur GTM (JSON)**.
2. Dans Google Tag Manager, allez dans **Admin > Importer le conteneur**.
3. Sélectionnez le fichier JSON, choisissez un espace de travail, et l'option **Fusionner** (ou **Écraser** sur un conteneur vide).
4. Vérifiez l'aperçu puis **Publiez** votre conteneur.
L'export contient le tag GA4 Configuration et tous les événements Enhanced Ecommerce, les variables DataLayer, les déclencheurs Custom Event, le Consent Mode v2, ainsi que les tags Google Ads et pixels activés.
Régénérez et réimportez l'export après avoir modifié vos IDs (GA4, Google Ads, pixels) pour que le conteneur reflète vos nouveaux réglages.
## 8. Server-Side GTM (sGTM)
Dans la section **Server-Side GTM**, activez l'option et renseignez l'URL de votre serveur (par ex. `https://sgtm.votre-domaine.com`). Le module charge alors le script GTM et le noscript depuis votre serveur au lieu de `googletagmanager.com`, ce qui contourne les ad-blockers et améliore la fiabilité du tracking.
## 9. Conversion Recovery
C'est la fonctionnalité clé du module. À la confirmation de chaque commande, la conversion est enregistrée en base. Un contrôle asynchrone vérifie que GTM a bien reçu l'événement `purchase` ; sinon (ad-blocker, redirection de paiement, erreur réseau), l'événement est **rejoué automatiquement** à la prochaine visite du client. Aucune configuration n'est requise ; laissez l'option activée dans **Options avancées**.
## 10. Options avancées
- **Cross-domain tracking** : listez les domaines concernés (séparés par des virgules).
- **Exclure les taxes / frais de livraison du revenu** : ajuste le calcul de `value` pour `purchase`.
- **Mode debug** : affiche chaque push `dataLayer` dans la console du navigateur (préfixe coloré « DataFirefly GTM »). À désactiver en production.
## 11. Tableau de bord de monitoring
En haut de la page de configuration, un tableau de bord affiche sur 30 jours : le nombre de conversions trackées, celles poussées avec succès, celles en attente de recovery, le revenu tracké, le taux de réussite du tracking et le top des événements sur 7 jours. Un bouton **Rejouer** permet de re-marquer les conversions en échec pour un nouvel essai.
Visez un taux de tracking > 95 %. En dessous de 80 %, activez le Server-Side GTM pour contourner les ad-blockers.
## Compatibilité PrestaShop 9
Depuis la version 1.2.0, le module est compatible PrestaShop 8 et 9 (Symfony 6.4, PHP 8.1 à 8.4). Le formatage des prix passe par la Locale (l'ancienne méthode `Tools::displayPrice` a été retirée de PS9), le suivi de recherche est côté client, et les sessions comme le téléchargement de l'export ont été sécurisés pour le kernel Symfony. Aucune action n'est requise lors de la mise à niveau ; le script d'upgrade nettoie les hooks obsolètes automatiquement.
## Dépannage
### Aucune donnée ne remonte dans GTM / GA4
Vérifiez que **Activer GTM** est coché et que l'ID conteneur est renseigné. Le module n'injecte rien tant que ces deux conditions ne sont pas remplies. Utilisez l'aperçu de GTM (Preview) et le mode debug du module pour voir les pushes `dataLayer`.
### Les conversions Google Ads ne se déclenchent pas
Assurez-vous d'avoir importé et **publié** le conteneur exporté après avoir renseigné l'ID de conversion et le label. Vérifiez le format `AW-XXXXXXXXX` et le label d'achat.
### Les données du panier (Merchant Center) sont absentes
Renseignez le Merchant Center ID, le pays et la langue du flux, et vérifiez que la **source de l'ID produit** correspond au champ `id` de votre flux.
### Le consentement reste « refusé »
Reliez votre CMP en appelant `DFGTM.updateConsent()` lors de l'acceptation. Sans cet appel, seules des données modélisées sont collectées.
### Le fichier d'export est vide ou corrompu
Désactivez temporairement les modules de cache/optimisation HTML et réessayez ; l'export nettoie les buffers de sortie mais un module tiers peut injecter du contenu avant le téléchargement.
---
### GSC Connect — Documentation
_Source :_
> GSC Connect ramène toute la puissance de Google Search Console directement dans le back-office PrestaShop : connexion OAuth en un clic, soumission de sitemaps, inspection d'URL en masse, rapports clics et…
**GSC Connect** ramène toute la puissance de Google Search Console directement dans le back-office PrestaShop : connexion OAuth en un clic, soumission de sitemaps, inspection d'URL en masse, rapports clics et positions par produit et catégorie, alertes automatiques de chute et de désindexation. Ce guide couvre l'installation, la configuration OAuth Google, la première synchronisation, la planification cron, la lecture des rapports, la résolution des cas d'erreur courants et l'architecture interne.
## Installation
Le module se déploie comme tout module PrestaShop standard : aucune dépendance Composer, aucun worker persistant, aucun service externe à part Google.
1. Téléchargez `dfgscconnect.zip` depuis votre compte DataFirefly (lien de téléchargement reçu après commande).
2. Back-office → **Modules → Gestionnaire de modules → Uploader un module**.
3. Glissez-déposez le ZIP. PrestaShop installe automatiquement les 8 tables `dfgsc_*`, les onglets de menu et les hooks associés.
4. Cliquez sur **Configurer** sur la fiche du module.
**Multi-boutique natif.** Le module est multishop. Chaque boutique stocke son propre jeton OAuth, sa propre propriété Search Console et son propre historique de métriques. Vous pouvez connecter une boutique sans toucher aux autres.
### Prérequis
- PrestaShop 8.0.0 à 9.99.99
- PHP 7.4, 8.0, 8.1, 8.2 ou 8.3
- MySQL 5.6+ ou MariaDB 10.3+
- Extension PHP `curl` activée (par défaut sur tous les hébergeurs)
- Un compte Google qui possède déjà l'accès propriétaire ou propriétaire délégué à la propriété Search Console de votre boutique
## Configuration OAuth Google
Le module utilise OAuth 2.0 pour accéder à Search Console au nom du propriétaire de la boutique. Cette étape se fait une seule fois et prend environ 5 minutes. Aucun compte de service n'est requis : l'authentification utilise directement le compte Google qui a déjà l'accès à votre propriété Search Console.
### Étape 1 — Créer un projet Google Cloud
1. Rendez-vous sur [console.cloud.google.com](https://console.cloud.google.com/) avec le compte Google qui possède l'accès Search Console.
2. Cliquez sur le sélecteur de projet en haut, puis sur **Nouveau projet**.
3. Nommez-le par exemple `prestashop-gsc` et créez-le.
4. Sélectionnez ce nouveau projet une fois créé.
### Étape 2 — Activer l'API Search Console
1. Menu → **API & Services → Bibliothèque**.
2. Recherchez **Google Search Console API**.
3. Cliquez dessus puis sur **Activer**.
### Étape 3 — Configurer l'écran de consentement
1. Menu → **API & Services → OAuth consent screen**.
2. Choisissez **External** si votre compte Google n'est pas membre d'une organisation Google Workspace, sinon **Internal**.
3. Renseignez le nom de l'application (par exemple `GSC Connect`), votre adresse de support et votre domaine de boutique.
4. Sur l'écran **Scopes**, ajoutez le scope `https://www.googleapis.com/auth/webmasters` (lecture/écriture Search Console).
5. Sur l'écran **Test users**, ajoutez votre adresse Google. Tant que l'écran reste en mode test, c'est suffisant pour un usage privé : il n'est pas nécessaire de soumettre l'application à vérification par Google.
### Étape 4 — Créer les identifiants OAuth
1. Menu → **API & Services → Credentials**.
2. **Create Credentials → OAuth client ID**.
3. Type d'application : **Web application**.
4. Nom : `GSC Connect` (libre).
5. Dans **Origines JavaScript autorisées**, ajoutez le domaine de votre boutique avec le protocole HTTPS : `https://votre-boutique.fr`.
6. Dans **URI de redirection autorisé**, collez l'URL exacte affichée dans la configuration du module PrestaShop (encadré _URL de redirection OAuth_).
7. Cliquez sur **Create**. Google affiche un **Client ID** et un **Client Secret**.
**L'URL de redirection doit être strictement identique.** Y compris le protocole (`https`), les sous-domaines (`www` ou non) et l'absence de slash final. Une seule différence et Google bloque la connexion avec `redirect_uri_mismatch`.
### Étape 5 — Renseigner les identifiants dans PrestaShop
1. Back-office → module → **Configurer**.
2. Collez le Client ID et le Client Secret.
3. Enregistrez le formulaire. Un bouton **Se connecter avec Google** apparaît.
4. Cliquez dessus. Vous êtes redirigé sur la page de consentement Google.
5. Validez les permissions, vous êtes redirigé dans le BO PrestaShop.
6. La liste de vos propriétés Search Console est récupérée automatiquement : le module sélectionne par défaut celle qui correspond au domaine de votre boutique.
## Premier lancement
Une fois la connexion OAuth établie, lancez la première synchronisation pour rapatrier vos données :
1. Onglet **Tableau de bord**. La propriété par défaut est déjà sélectionnée.
2. Cliquez sur **Synchroniser maintenant**. Le module récupère les 28 derniers jours de données (clics, impressions, CTR, position) au niveau page et requête. Comptez 30 secondes à 2 minutes selon le volume de votre catalogue.
3. Onglet **Sitemaps**. Les candidats sont détectés automatiquement (`/sitemap.xml` racine + pattern `*_sitemap.xml` généré par le module `gsitemap` de PrestaShop). Cliquez sur **Soumettre** à côté de chaque sitemap pertinent.
4. Onglet **Inspection**. Cliquez sur **Enfourner tous les produits actifs**. La file se remplit instantanément. Le traitement réel se fait via le cron en respectant le quota Google de 2000 inspections par jour.
**Latence Search Console.** Google diffuse les données de Search Analytics avec environ 48 h de retard. Si vous venez tout juste de vous connecter, certaines métriques de la veille ou de l'avant-veille ne seront pas encore disponibles. C'est normal. Le module en tient compte automatiquement dans les calculs de drops (fenêtre glissante avec offset de 2 jours).
## Tableau de bord
Le tableau de bord regroupe 8 KPIs sur 28 jours :
- **Clics** — total des clics organiques sur la fenêtre
- **Impressions** — total des affichages dans la SERP
- **CTR moyen** — pourcentage de clics par rapport aux impressions
- **Position moyenne** — position moyenne pondérée sur l'ensemble des requêtes
- **Alertes non lues** — nombre d'alertes ouvertes à traiter
- **Pages non indexées** — nombre de pages inspectées dont le verdict Google est FAIL ou NEUTRAL
- **Quota du jour** — appels API Inspection consommés sur le quota journalier
- **Dernière synchronisation** — date et heure de la dernière passe cron `sync`
Sous les KPIs, un graphique d'évolution sur 28 jours affiche les clics (ligne pleine) et les impressions (ligne pointillée sur axe secondaire). Chart.js est bundlé en local, aucune dépendance CDN n'est chargée.
Sur la droite, le **Top 10 produits** et le **Top 10 catégories** classent vos pages par clics avec leur position moyenne et leur CTR. La résolution URL → entité utilise le routing natif PrestaShop : pattern `id-slug` pour les produits, `link_rewrite` pour les catégories, `cms_lang` pour les pages CMS.
## Rapports clics et positions
L'onglet **Rapports** propose trois vues détaillées : **Produits**, **Catégories**, **Requêtes**. Chaque vue accepte un lookback configurable : **7 / 14 / 28 / 90 jours**.
Pour chaque ligne, vous obtenez les clics, les impressions, le CTR et la position moyenne. Cliquez sur n'importe quel en-tête de colonne pour trier (tri client, instantané). L'export CSV produit un fichier UTF-8 avec BOM et séparateur point-virgule (compatible Excel natif), jusqu'à 5000 lignes par export.
### Comparaison de fenêtres
Pour chaque produit ou catégorie listé, le rapport affiche également la variation par rapport à la fenêtre précédente de même durée. Une chute de position significative apparaît en rouge, une amélioration en vert.
## Sitemaps
L'onglet **Sitemaps** détecte automatiquement les candidats sur votre boutique :
- `https://votre-boutique.fr/sitemap.xml` — sitemap racine
- `https://votre-boutique.fr/sitemap_index.xml` — index de sitemaps
- Pattern `*_sitemap.xml` à la racine — généré par le module `gsitemap` de PrestaShop, un fichier par boutique et par langue
Soumettez en un clic. Le module suit ensuite pour vous :
- Le nombre d'URL soumises (déclaré par votre sitemap)
- Le nombre d'URL réellement indexées (rapporté par Google)
- Le nombre d'erreurs détectées par Google
- La date du dernier téléchargement par Googlebot
Si Google détecte des erreurs sur un sitemap, une alerte automatique est levée : sévérité **HIGH** si ≥ 10 erreurs, sinon **MEDIUM**.
## Inspection d'URL en masse
L'API URL Inspection de Google est limitée à 2000 appels par jour par propriété. GSC Connect gère cette limite via une file d'attente avec retry automatique.
### Actions disponibles
- **Enfourner tous les produits actifs** — ajoute tous les produits avec visibilité `both`, `search` ou `catalog`
- **Enfourner toutes les catégories** — ajoute toutes les catégories actives (la racine est exclue)
- **Re-inspecter les pages modifiées** — ajoute uniquement les entités marquées comme périmées par les hooks `actionProductUpdate` et `actionCategoryUpdate`
- **Traiter la file maintenant** — pour les tests, sans attendre le cron
- **Inspecter une URL ad-hoc** — pour valider une correction immédiate sur une page précise
### Données enregistrées
Pour chaque URL inspectée, le module enregistre :
- Le verdict global Google : PASS, PARTIAL, FAIL ou NEUTRAL
- L'état de couverture (Indexed, Discovered, Crawled but not indexed, etc.)
- Le statut robots.txt et l'indexabilité déclarée
- Les résultats enrichis détectés (Product, Breadcrumb, Review, etc.)
- Le statut AMP et la conformité mobile-friendly
- Le sitemap référent et les URL référentes
- La date de la dernière exploration par Googlebot
**Désindexation détectée → alerte automatique.** Si le verdict est FAIL ou NEUTRAL, ou si l'état de couverture est DEINDEXED ou INDEXING_NOT_ALLOWED, une alerte HIGH est levée automatiquement avec la raison renvoyée par Google.
## Alertes et chutes
Trois familles d'alertes sont gérées automatiquement par le module :
### Chutes de position
Détecte une chute significative de position sur une page déjà bien classée. Par défaut : chute de **5 places ou plus** sur une page positionnée à ≤ 50. Seuil ajustable dans la configuration (`DFGSC_DROP_POS`).
### Chutes de clics
Détecte une chute significative du nombre de clics sur une page qui en générait un volume minimum. Par défaut : chute de **30 %** avec un minimum de **5 clics** sur la fenêtre précédente. Seuils ajustables dans la configuration (`DFGSC_DROP_CLICKS`, `DFGSC_DROP_MIN_CLICKS`).
### Désindexations
Levée automatiquement quand une URL inspectée revient avec un verdict FAIL ou NEUTRAL, ou un état de couverture DEINDEXED / INDEXING_NOT_ALLOWED.
### Mécanique de comparaison
La comparaison drops se fait sur une fenêtre glissante de **7 jours** contre les **7 jours précédents**, avec un offset de 2 jours pour respecter la latence de Search Console. Le module compare `D-9..D-2` à `D-16..D-9`.
### Déduplication 24h
Une même alerte (même page, même type) ne se déclenche qu'une fois par 24h pour éviter le bruit, même si le cron tourne toutes les heures.
### Notifications e-mail
Les alertes peuvent être envoyées par e-mail sous forme de digest HTML groupé par sévérité, en français ou en anglais. Activez-les depuis la configuration et renseignez l'adresse destinataire.
## Cron et planification
Toutes les tâches en arrière-plan passent par un endpoint unique protégé par token, visible dans la page de configuration :
```
https://votre-boutique.fr/index.php?fc=module&module=dfgscconnect&controller=cron&token=XXXXXXXXXX
```
Programmez-le toutes les 1 à 6 heures depuis le panneau cron de votre hébergeur (cPanel, Plesk, o2switch, OVH). Exemple crontab :
```
0 */2 * * * curl -fsS "https://votre-boutique.fr/index.php?fc=module&module=dfgscconnect&controller=cron&token=XXXX" > /dev/null 2>&1
```
### Tâches exécutées
Par défaut, l'endpoint exécute toutes les tâches. Vous pouvez en filtrer une partie avec le paramètre `&tasks=` :
TâcheAction`sync`Récupération des nouvelles données Search Analytics (lookback configurable)`inspect`Traitement de la file d'inspection d'URL en respectant le quota`sitemaps`Rafraîchissement du statut des sitemaps soumis`drops`Détection des baisses de position et de clics`notify`Envoi du digest d'alertes par e-mail`prune`Purge des entrées de file terminées et des compteurs de quota anciens
Exemple pour ne synchroniser que les métriques sans toucher à l'inspection :
```
curl "https://votre-boutique.fr/index.php?fc=module&module=dfgscconnect&controller=cron&token=XXXX&tasks=sync,drops,notify"
```
**Hébergement mutualisé compatible.** Aucune dépendance Redis, BullMQ, worker persistant ou PHP-FPM dédié. L'endpoint cron est un simple URL HTTPS protégé par token. Fonctionne nativement sur o2switch, OVH mutualisé et tout hébergement Linux standard.
## Configuration de référence
Toutes les options sont dans la page **Configurer** du module :
OptionCléDéfautClient ID Google`DFGSC_CLIENT_ID`(à renseigner)Client Secret Google`DFGSC_CLIENT_SECRET`(à renseigner)Lookback synchronisation (jours)`DFGSC_LOOKBACK_DAYS`28Quota journalier inspection URL`DFGSC_DAILY_QUOTA`2000Seuil chute de position`DFGSC_DROP_POS`5Seuil chute de clics (%)`DFGSC_DROP_CLICKS`30Clics minimum pour détecter chute`DFGSC_DROP_MIN_CLICKS`5Notifications e-mail activées`DFGSC_ALERT_ENABLED`ouiAdresse destinataire alertes`DFGSC_ALERT_EMAIL`e-mail adminToken cron`DFGSC_CRON_TOKEN`auto-généré
## Quotas et limites API Google
L'API Search Console est gratuite, mais soumise à des quotas Google :
- **URL Inspection** : 2000 appels par jour par propriété, 600 par minute (hard limit Google, non négociable)
- **Search Analytics** : 25000 lignes par appel, ~1200 appels par minute, 30000 par jour (soft cap)
- **Sitemaps** : 5000 appels par jour
Le module enregistre tous les appels par endpoint et par jour dans la table `dfgsc_quota`. La file d'inspection s'arrête proprement lorsque le quota configuré est atteint, en générant une alerte de sévérité MEDIUM. Les compteurs sont purgés automatiquement après 30 jours par la tâche `prune`.
## Architecture et données
Le module suit une architecture PSR-4 classique sous le namespace `DataFireflyGscConnect`, avec un autoloader maison livré dans `vendor/autoload.php`. Aucune dépendance Composer. Aucune dépendance externe : les appels Google API se font en cURL natif avec vérification SSL.
### Couches
- `Api` — clients HTTP (GoogleOAuth, SearchConsoleClient)
- `Model` — repositories d'accès à la base (Token, Site, Metric, Inspection, Sitemap, Alert, Queue, Quota)
- `Services` — orchestration (MetricsSync, Inspection, Sitemap, Alert)
### Tables créées
TableRôle`dfgsc_token`Refresh token OAuth + expiration par boutique`dfgsc_site`Propriétés Search Console connues (par boutique, avec celle par défaut)`dfgsc_metric`Lignes Search Analytics (par jour, par page, optionnellement par requête)`dfgsc_inspection`Cache local des inspections d'URL avec leur verdict complet`dfgsc_sitemap`État des sitemaps soumis (URL, soumis, indexés, erreurs, dernier téléchargement)`dfgsc_alert`Alertes générées (type, sévérité, page, delta, statut)`dfgsc_queue`File d'inspection avec statuts pending/processing/done/failed`dfgsc_quota`Compteurs d'appels API par endpoint et par jour
### Hooks utilisés
- `actionAdminControllerSetMedia` — chargement des assets BO
- `displayBackOfficeHeader` — réservé pour notifications futures
- `actionProductUpdate` / `actionCategoryUpdate` — invalidation du cache d'inspection
- `actionObjectProductDeleteAfter` / `actionObjectCategoryDeleteAfter` — purge des inspections orphelines
### Sécurité
- CSRF state token cookie-based sur le flux OAuth
- Validation `hash_equals` sur le token cron
- Refresh token stocké en base, jamais loggé
- Access token jamais persisté : régénéré à la demande depuis le refresh token et tenu en mémoire le temps de la requête
- Fichiers `index.php` anti-listing dans tous les sous-répertoires
- Échappement systématique via `Tools::safeOutput` sur toutes les sorties templates
## Dépannage
### Le bouton « Se connecter avec Google » n'apparaît pas
Vérifiez que Client ID et Client Secret sont bien enregistrés. Sauvegardez le formulaire, puis rechargez la page de configuration.
### L'écran Google affiche `redirect_uri_mismatch`
L'URI de redirection dans Google Cloud doit être strictement identique à celle affichée dans la configuration du module : même protocole (`https`), même sous-domaine (`www` ou non), même chemin, sans slash final. Copiez-collez sans modification.
### La synchronisation ne ramène pas de données
Vérifiez trois points : (1) la propriété sélectionnée est bien votre boutique ; (2) elle a au moins 72 h d'historique dans Search Console (Google diffuse avec ~48 h de latence) ; (3) le compte Google connecté a bien l'accès propriétaire ou propriétaire délégué à cette propriété.
### Les inspections ne se font pas
Vérifiez que le cron est bien programmé et qu'il s'exécute. Vérifiez ensuite le quota du jour : si vous avez consommé les 2000 appels Google, la file est en pause jusqu'au lendemain. Vous pouvez forcer manuellement via le bouton **Traiter la file maintenant**.
### Les alertes par e-mail n'arrivent pas
Vérifiez que l'adresse renseignée est valide, que la configuration SMTP de PrestaShop fonctionne (testez avec un e-mail de bienvenue par exemple), et que les notifications sont activées dans la configuration du module.
### Erreur 401 ou 403 sur les appels Search Console
Le refresh token a probablement été révoqué côté Google (changement de mot de passe, sécurité du compte, ou consentement expiré). Déconnectez et reconnectez la boutique depuis la configuration.
### Erreur `Quota Exhausted` (429)
Le quota Google de la propriété est atteint. C'est limité à 2000 inspections par jour par Google, indépendamment du nombre de modules ou d'outils qui interrogent la propriété. La file reprend automatiquement le lendemain.
## Changelog
Voir le fichier `CHANGELOG.md` inclus dans le ZIP du module pour la liste complète des évolutions par version.
---
_Pour toute question non couverte ici, contactez le support DataFirefly à support@datafirefly.com._
---
### Headless Starter Kit — Guide complet
_Source :_
> Guide complet d'installation, configuration et déploiement de Headless Starter Kit : plugin WordPress qui transforme votre boutique WooCommerce en commerce headless, avec starter Next.js 15 clé en main livré préconfiguré.
Ce guide couvre l'installation, la configuration et l'utilisation complète de **Headless Starter Kit** — plugin WordPress qui transforme votre boutique WooCommerce en commerce headless, accompagné d'un starter Next.js 15 clé en main.
**À qui s'adresse ce guide.** Développeur, agence ou marchand technique qui veut passer un WooCommerce existant en headless sans réinventer authentification, panier et checkout. Vous devez être à l'aise avec la ligne de commande, Node.js et un peu de configuration serveur si vous choisissez Hetzner.
## Vue d'ensemble
Headless Starter Kit se présente en **deux livrables** distribués dans le même achat :
1. **Le plugin WordPress** (ZIP à uploader dans `/wp-admin/plugins.php`) qui expose côté backend : authentification JWT, API panier, pont de checkout, endpoint de configuration public, webhooks ISR et CORS strict.
2. **Le starter Next.js 15** (ZIP téléchargeable depuis l'admin WordPress une fois le plugin activé et configuré) qui contient un projet Next.js complet avec pages home, listing, fiche produit ISR, panier, checkout, login, register et espace client — variables d'environnement déjà pré-remplies avec vos URLs et secrets.
L'architecture est volontairement simple : votre WooCommerce reste la source de vérité (produits, commandes, stocks, paiements), et Next.js consomme l'API REST via des routes proxy sécurisées. Aucune duplication de base de données, aucune réplication à gérer.
## Prérequis
### Côté WordPress
- WordPress **6.4 ou supérieur**
- WooCommerce **8.0 ou supérieur** (testé jusqu'à 9.5)
- PHP **8.1 ou supérieur**
- Permaliens configurés en _Nom de l'article_ (pas en _Simple_)
- HTTPS actif (indispensable pour les cookies httpOnly et l'authentification en production)
- Une paire de clés WooCommerce REST en lecture-écriture (générées dans _WooCommerce → Réglages → Avancé → API REST_)
### Côté frontend Next.js
- Node.js **20 ou supérieur** (recommandé : gérer les versions avec `nvm`)
- Hébergement compatible Node : Vercel, Hetzner VPS, Netlify, Railway ou tout serveur pouvant exécuter Node 20+
**Hébergement mutualisé classique (o2switch, OVH mutualisé, etc.) n'est pas adapté** pour héberger le frontend Next.js, qui requiert un runtime Node persistant. Le plugin WordPress, lui, fonctionne sur tout hébergement WP.
## Installation du plugin WordPress
1. Depuis le back-office WordPress, allez dans _Extensions → Ajouter une extension → Téléverser une extension_.
2. Sélectionnez le fichier `dfheadlessstarterkit.zip`, puis cliquez sur _Installer maintenant_.
3. Cliquez sur _Activer l'extension_.
4. Un nouveau menu **Headless Kit** apparaît dans la barre latérale gauche, avec trois onglets : _Réglages_, _Diagnostics_, _Télécharger le starter_.
À l'activation, le plugin génère automatiquement un secret JWT et un jeton de revalidation aléatoires. Vous pouvez les régénérer à tout moment depuis les réglages.
## Configuration
Ouvrez _Headless Kit → Réglages_. Chaque section est indépendante et peut être ajustée sans redémarrer quoi que ce soit.
### URL du frontend
Renseignez l'URL publique complète de votre application Next.js, sans slash final. Exemple :
```
https://shop.exemple.fr
```
Cette URL sert à trois choses : construire les webhooks ISR, alimenter la variable `NEXT_PUBLIC_SITE_URL` du starter livré, et valider l'origine CORS par défaut.
### Secret JWT et jeton de revalidation
Deux secrets sont utilisés :
- **Secret JWT** — signe les tokens d'accès et de refresh. Au moins 32 caractères. Ne le partagez jamais.
- **Jeton de revalidation** — envoyé dans le header `Authorization: Bearer …` des webhooks ISR. Doit être identique à la variable `REVALIDATE_TOKEN` côté Next.js.
Un bouton _Régénérer_ à côté de chaque champ produit un secret aléatoire cryptographiquement solide via `crypto.getRandomValues`.
**Après régénération du secret JWT, tous les tokens d'accès et de refresh existants deviennent invalides.** Les utilisateurs devront se reconnecter. Prévenez-les ou faites-le en dehors des heures de trafic.
### Mode panier : JWT ou serveur ?
Le choix se fait via un bouton radio dans les réglages.
#### Mode JWT (par défaut, recommandé)
Le panier complet est sérialisé dans un token signé HS256 et renvoyé via le header `X-DFHSK-Cart`. Aucune donnée n'est stockée côté WordPress. Idéal pour :
- Déploiements sur Vercel edge, Cloudflare, ou multi-instances
- Boutiques à fort trafic où éviter la base de données à chaque appel est un gain net
- Setups où le WordPress est purement API et n'a pas besoin de sessions
#### Mode serveur (WC_Session)
Le panier vit dans la table native WC_Session de WooCommerce. À privilégier si :
- Vous utilisez des extensions WooCommerce qui hookent sur le panier (WooCommerce Subscriptions, Dynamic Pricing, YITH plugins, etc.)
- Vous voulez conserver la logique de session native de WooCommerce (relances de paniers abandonnés natifs, cross-sell côté serveur, etc.)
### Origines CORS
Une liste blanche stricte d'origines autorisées à appeler l'API. Une origine par ligne, format complet `https://…`. Les wildcards de sous-domaines sont supportés :
```
https://shop.exemple.fr
https://preview.exemple.fr
https://*.previews.exemple.fr
http://localhost:3000
```
Ajoutez `http://localhost:3000` pendant le développement, puis retirez-le en production.
### Événements ISR
Cinq cases à cocher indiquent quels événements WordPress déclenchent un webhook ISR vers Next.js :
- **Produits** — `save_post_product`, `woocommerce_update_product`
- **Catégories** — création, mise à jour, suppression de termes de la taxonomie `product_cat`
- **Commandes** — changements de statut (utile pour rafraîchir la page compte client)
- **Pages** — `save_post_page`
- **Coupons** — création et mise à jour de codes promo
Un textarea _Chemins à revalider_ vous permet de définir précisément quels chemins Next.js sont revalidés pour chaque événement (par défaut, le plugin déduit intelligemment les chemins concernés).
## Diagnostics
Onglet _Headless Kit → Diagnostics_. Onze contrôles automatiques sont exécutés à chaque affichage de la page :
1. **WooCommerce actif** — la classe `WooCommerce` est disponible
2. **Permaliens propres** — la structure n'est pas _Simple_
3. **REST API joignable** — `/wp-json/` répond en 200
4. **HTTPS actif** — `is_ssl()` renvoie true
5. **WPGraphQL détecté** — information seulement, non bloquant
6. **Secret JWT défini** — au moins 32 caractères
7. **URL du frontend configurée** — non vide et format URL valide
8. **Origines CORS renseignées** — au moins une origine
9. **Jeton de revalidation défini** — au moins 24 caractères
10. **Clés WooCommerce REST** — le plugin détecte une paire consumer_key/consumer_secret active
11. **Mode panier lisible** — le stockage choisi fonctionne
Chaque contrôle affiche vert (OK), orange (avertissement, non bloquant) ou rouge (bloquant). Résolvez tout ce qui est rouge avant de mettre en production.
## Télécharger et lancer le starter Next.js
Une fois les réglages remplis et les diagnostics au vert, ouvrez _Headless Kit → Télécharger le starter_. Cliquez sur le gros bouton _Télécharger le starter Next.js_.
Le ZIP livré est un projet Next.js 15 complet, généré à la volée avec vos URLs et secrets déjà injectés. Les placeholders remplacés à la génération :
- `{{SITE_URL}}` → URL de votre WordPress
- `{{FRONTEND_URL}}` → URL du front configurée
- `{{REVALIDATE_TOKEN}}` → votre jeton de revalidation
- `{{CURRENCY}}` → devise WooCommerce
- `{{SITE_NAME}}` → titre du site
- `{{LOCALE}}` → locale WordPress (fr, en, es, etc.)
Le fichier `.envtmpl` est renommé en `.env.example` à la génération.
### Variables d'environnement à compléter manuellement
Certaines valeurs ne peuvent pas être récupérées automatiquement — vous devez les ajouter au fichier `.env` (à créer depuis `.env.example`) :
```
WOO_REST_CONSUMER_KEY=ck_xxxxxxxxxxxxxx
WOO_REST_CONSUMER_SECRET=cs_xxxxxxxxxxxxxx
SESSION_PASSWORD=votre-mot-de-passe-32-caracteres-minimum
```
Générez un `SESSION_PASSWORD` solide :
```
node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
```
### Développement local
```
npm install
cp .env.example .env
# Éditez .env avec vos secrets manquants
npm run dev
```
Le front est accessible sur `http://localhost:3000`. Ajoutez cette URL dans les origines CORS côté WordPress pendant le développement.
### Déploiement sur Vercel
```
npx vercel link
npx vercel env pull .env.production
npx vercel deploy --prod
```
Configurez ensuite toutes les variables d'environnement dans le dashboard Vercel (_Project → Settings → Environment Variables_). Le fichier `vercel.json` livré fixe la région sur `cdg1` (Paris) et désactive le cache sur les routes `/api/*`.
### Déploiement sur Hetzner (ou tout VPS Ubuntu/Debian)
```
# Sur le serveur, en tant que root ou avec sudo
git clone votre-repo.git storefront && cd storefront
cp .env.example .env
nano .env # Renseignez toutes les variables
bash deploy/hetzner.sh
```
Le script installe Docker si nécessaire, construit l'image, lance le conteneur et expose le service sur `127.0.0.1:3000`. Ajoutez Caddy ou nginx en reverse-proxy pour le TLS. Exemple de Caddyfile minimal :
```
shop.exemple.fr {
encode zstd gzip
reverse_proxy 127.0.0.1:3000
}
```
## Endpoints REST exposés
Tous les endpoints du plugin sont sous le namespace `dfhsk/v1`. URL complète : `https://exemple.fr/wp-json/dfhsk/v1/…`
### Authentification
- `POST /auth/login` — body : `{ username, password }` → renvoie `{ token, refresh_token, user }`
- `POST /auth/refresh` — body : `{ refresh_token }` → renvoie un nouveau `token`
- `GET /auth/me` — header : `Authorization: Bearer …` → renvoie l'utilisateur courant
- `POST /auth/register` — body : `{ email, password, first_name, last_name }`
- `POST /auth/logout` — invalide le refresh token
### Panier
Tous les appels transmettent le token de panier via le header `X-DFHSK-Cart`. Le serveur renvoie un nouveau token dans le même header à chaque réponse.
- `GET /cart` — snapshot complet (items, totaux, taxes, frais de port)
- `POST /cart/add` — body : `{ product_id, quantity, variation? }`
- `POST /cart/update` — body : `{ key, quantity }`
- `POST /cart/remove` — body : `{ key }`
- `POST /cart/coupon` — body : `{ code }`
- `DELETE /cart/coupon/{code}`
- `POST /cart/shipping` — body : `{ country, postcode }` → renvoie les tarifs applicables
- `POST /cart/clear`
### Checkout
- `POST /checkout/create-order` — body : `{ payment_method, billing, shipping? }` → renvoie `{ order_id, order_key, redirect }`. Le `redirect` est l'URL vers la passerelle de paiement (Stripe, PayPal, etc.).
- `GET /checkout/order/{id}` — header `Authorization: Bearer …` requis
### Configuration publique
- `GET /config` — accessible sans authentification. Renvoie `{ currency, base_country, countries, payment_methods, tax_settings }`. Le starter Next.js utilise cet endpoint pour hydrater les formulaires de checkout.
### Webhooks ISR (côté Next.js)
Le plugin envoie des `POST` vers `{FRONTEND_URL}/api/revalidate` avec le header `Authorization: Bearer {REVALIDATE_TOKEN}`. Le corps est un JSON :
```
{
"paths": ["/products/veste-lin", "/products"],
"tags": ["product:veste-lin"],
"reason": "wc_update_product"
}
```
La route `/api/revalidate` livrée dans le starter valide le token puis appelle `revalidatePath` et `revalidateTag` pour chaque entrée.
## Personnaliser le starter
Le code livré est sous licence GPL v2 — vous pouvez modifier, étendre, redistribuer sans restriction. Les points d'entrée usuels :
- **Palette de couleurs** : `tailwind.config.ts`, palette `brand` (orange par défaut)
- **Composants boutique** : `src/components/shop/` (Header, Footer, ProductCard, CartProvider)
- **Pages publiques** : `src/app/(shop)/`
- **Pages compte client** : `src/app/(auth)/`
- **Format prix et dates** : `src/lib/format.ts`
- **Types TypeScript** : `src/types/woo.ts`
- **Helper d'appel API** : `src/lib/woo-rest.ts` (fonctions `wooRest` et `dfhskFetch`)
Pour ajouter une nouvelle page qui liste par exemple les produits d'une marque, dupliquez `src/app/(shop)/products/page.tsx` et adaptez la query WooCommerce REST. La fonction `wooRest()` gère l'authentification Basic automatiquement.
## Résolution de problèmes
### Erreur CORS dans la console navigateur
L'origine du front n'est pas dans la liste blanche. Ajoutez-la dans _Réglages → Origines CORS_, une par ligne, sans slash final.
### Webhooks ISR qui répondent 401
Le `REVALIDATE_TOKEN` côté Next.js ne correspond pas au jeton configuré côté WordPress. Copiez-collez la valeur exacte des réglages WP dans le `.env` Next.js, puis redéployez.
### Login retourne 403 malgré des identifiants corrects
Vérifiez que le compte utilisateur a bien un mot de passe défini (pas un login social uniquement), que HTTPS est actif en production, et que le secret JWT fait au moins 32 caractères. Consultez l'onglet Diagnostics.
### Le panier se vide entre deux pages
En mode JWT, vérifiez que le starter lit et écrit bien le token dans `localStorage` (clé `dfhsk_cart_token`). Ouvrez l'inspecteur navigateur → onglet _Application → Local Storage_.
### Une commande créée dans WooCommerce n'apparaît pas côté Next.js
Vérifiez que l'événement _Commandes_ est bien coché dans les événements ISR et que le webhook part sans erreur (activez `WP_DEBUG_LOG`).
## Aller plus loin
Le starter est un point de départ, pas un produit fini. Selon votre projet, envisagez d'ajouter :
- Un moteur de recherche instantané (Algolia, Meilisearch, Typesense) alimenté par les mêmes webhooks ISR
- Un CMS de contenu éditorial côté WordPress avec le plugin ACF ou similaire, et une page Next.js dédiée
- Une PWA avec service worker pour le mode hors-ligne (voir aussi notre module _dfpwa_)
- De la personnalisation IA temps-réel (voir _dfsmartcontent_)
Pour toute question technique, contactez le support DataFirefly avec vos logs et les résultats de l'onglet Diagnostics.
---
### Image au Survol & Badges Automatiques — Guide de configuration
_Source :_
> Ce guide explique comment installer et configurer le module Image au Survol & Badges Automatiques pour PrestaShop 8 et 9. Le module affiche la deuxième image du produit au survol…
Ce guide explique comment installer et configurer le module **Image au Survol & Badges Automatiques** pour PrestaShop 8 et 9. Le module affiche la deuxième image du produit au survol dans les listings et applique automatiquement des badges Nouveau, Promo et Stock faible selon des règles que vous définissez, sans surcharger votre thème.
## Installation
L'installation se fait comme pour tout module PrestaShop :
1. Depuis le back-office, allez dans **Modules > Module Manager**.
2. Cliquez sur **Installer un module** et déposez l'archive ZIP du module.
3. Une fois l'installation terminée, cliquez sur **Configurer** pour ouvrir la page de réglages.
Le module enregistre le hook `actionFrontControllerSetMedia` et charge ses assets (CSS et JavaScript) uniquement sur les pages de listing et la page produit. Aucun fichier de template n'est surchargé.
## Configuration de l'image au survol
Le premier bloc de configuration pilote le remplacement d'image au survol :
- **Afficher la seconde image au survol** : active ou désactive l'effet. Les produits qui n'ont qu'une seule image sont ignorés automatiquement.
- **Effet de transition** : _Fondu_, _Fondu + zoom_ ou _Instantané_.
- **Position des badges** : coin où s'affichent les badges (haut gauche, haut droite, bas gauche, bas droite). Ce réglage est commun à tous les badges.
L'image de survol correspond à la **deuxième image du produit** selon l'ordre de position défini dans l'onglet Images de la fiche produit. Pour changer l'image affichée au survol, réordonnez simplement les images du produit.
## Les trois badges automatiques
Chaque badge peut être activé indépendamment, avec son propre libellé multilingue, sa couleur de fond et sa couleur de texte.
### Badge « Nouveau »
Il s'affiche pendant un nombre de jours configurable après la date de création du produit. La valeur par défaut reprend le réglage PrestaShop `PS_NB_DAYS_NEW_PRODUCT`. Réglez la durée souhaitée dans le champ **Produit considéré comme nouveau pendant (jours)**.
### Badge « Promo »
Il s'affiche lorsqu'un produit est marqué « En promotion » ou qu'un **prix spécifique avec réduction** est actif pour le contexte du visiteur (boutique, devise, pays, groupe client et dates de validité). L'option **Afficher le pourcentage de remise** remplace le libellé par la valeur, par exemple `-20 %`, lorsque la réduction est exprimée en pourcentage.
### Badge « Stock faible »
Il s'affiche lorsque la quantité disponible du produit est strictement supérieure à 0 et inférieure ou égale au **seuil de stock faible** que vous définissez. La quantité est lue dans la table `stock_available` avec résolution multiboutique (la boutique courante est prioritaire sur le groupe de boutiques).
## Libellés multilingues
Les libellés Nouveau, Promo et Stock faible sont fournis par défaut en français, anglais, espagnol, allemand et italien. Chaque libellé est éditable langue par langue depuis la page de configuration : sélectionnez la langue dans le sélecteur du champ, puis saisissez le texte voulu.
## Performance et compatibilité
- **Un seul appel AJAX groupé** par page récupère les données de tous les produits visibles (jusqu'à 120 produits par lot).
- L'image de survol est chargée en **lazy load**, uniquement au premier survol de la souris.
- Le script est en **JavaScript vanilla**, sans dépendance jQuery.
- Le module détecte les miniatures produit en JavaScript : il est compatible avec le thème _classic_ et les thèmes enfants, et se réadapte automatiquement après la navigation à facettes et la pagination AJAX.
- Sur mobile tactile, le remplacement d'image au survol est désactivé automatiquement.
## Dépannage
**Le survol ne montre pas de seconde image.** Vérifiez que le produit possède au moins deux images dans l'onglet Images de sa fiche, et que l'option d'image au survol est activée.
**Un badge n'apparaît pas.** Assurez-vous que le badge est activé, que son libellé n'est pas vide pour la langue courante, et que la condition est remplie (produit récent, prix spécifique actif, ou quantité sous le seuil).
**Rien ne s'affiche après un filtre.** Le module se réadapte après la navigation à facettes ; si votre thème utilise un mécanisme de rendu personnalisé, videz le cache PrestaShop (Paramètres avancés > Performances) après installation.
---
### Import Export CSV & XML pour PrestaShop — Guide complet
_Source :_
> Guide d'installation, de configuration et d'utilisation du module DF CSV & XML Pro pour PrestaShop 8 et 9 : profils, mapping visuel, formats de colonnes, sources FTP/SFTP/URL, planification par cron, journaux et dépannage.
DF CSV & XML Pro est un moteur d'import/export universel pour PrestaShop 8 et 9. Il relie n'importe quel fichier CSV ou XML à votre boutique grâce à un mapping visuel des colonnes, enregistre chaque configuration dans un profil réutilisable, et peut rapatrier automatiquement vos flux fournisseurs depuis FTP, SFTP ou une URL. Ce guide couvre l'installation, la création de profils, les formats de colonnes attendus, la planification par cron, les journaux et le dépannage.
## Installation
Rendez-vous dans **Modules > Gestionnaire de modules > Ajouter un module**, envoyez le fichier `dfcsvpro.zip` puis cliquez sur **Installer**. Une fois installé, un onglet **DF CSV Pro** apparaît sous **Paramètres avancés**.
Le module n'ajoute aucun override du cœur PrestaShop et se désinstalle proprement. Deux tables sont créées (profils et journaux) ainsi que quelques variables de configuration ; elles sont supprimées à la désinstallation.
## Créer un profil
Un **profil** décrit une opération complète : sens (import ou export), entité, format, source, mapping des colonnes, options et planification. Il se relance en un clic ou se déclenche automatiquement par cron. Cliquez sur **Nouveau profil** : un assistant vous guide en quatre étapes.
### 1. Général
Choisissez le **sens** (import / export), l'**entité**, le **format** (CSV ou XML) et la **langue** visée. Pour le CSV, réglez le délimiteur (ou laissez en auto-détection), l'encodage (UTF-8, ISO-8859-1 ou Windows-1252), le nombre de lignes à ignorer avant l'en-tête et le séparateur multi-valeurs (virgule par défaut). Pour le XML, vous pouvez préciser le nœud d'item ou laisser le module le détecter.
Entités disponibles à l'**import** : produits, déclinaisons, catégories, clients, stock & prix. À l'**export** : produits, catégories, clients, commandes.
### 2. Source
Sélectionnez d'où provient le fichier (import) ou où déposer le résultat (export) : **upload manuel**, **URL** (HTTP/HTTPS), **FTP**, **SFTP** ou **chemin local**. Pour FTP/SFTP, renseignez hôte, port, utilisateur et mot de passe, puis utilisez le bouton **Tester la connexion** pour valider avant d'enregistrer.
### 3. Mapping visuel
Chargez un fichier d'exemple (ou récupérez-le depuis la source distante) : le module détecte les colonnes, affiche un aperçu des premières lignes et associe automatiquement chaque colonne au bon champ PrestaShop grâce à une reconnaissance FR/EN (référence/SKU, prix/price, quantité/stock, EAN/gencod, TVA/VAT, etc.). Ajustez les associations dans le tableau ; toute colonne laissée sur « non mappé » est simplement ignorée.
La **clé de correspondance** (étape 4) détermine comment un produit existant est retrouvé : ID, référence/SKU, EAN-13 ou MPN. Assurez-vous que la colonne correspondante est bien mappée.
### 4. Options & planification
Définissez le comportement d'import : créer les éléments manquants, mettre à jour les existants, créer les catégories à la volée, télécharger les images depuis des URLs, remplacer ou non les images existantes à la mise à jour, et la taille de lot (lignes traitées par appel AJAX). Activez éventuellement la **planification** et choisissez la fréquence (horaire, quotidienne ou hebdomadaire). Enregistrez : le profil apparaît dans la liste, prêt à être lancé ou planifié.
## Formats de colonnes
Le module comprend les formats métier de PrestaShop. Voici les conventions attendues dans vos fichiers :
ChampFormat attenduPrixDécimal, virgule ou point : `19,90` ou `19.90`Booléens (actif, etc.)`1/0`, `yes/no`, `oui/non`, `true/false`CatégoriesNoms ou IDs séparés par le séparateur multi-valeurs (défaut `,`). Création à la volée en option.ImagesURLs séparées par le séparateur multi-valeurs. La première devient l'image de couverture.Caractéristiques`Nom:Valeur|Nom:Valeur`Déclinaisons`Groupe:Valeur|Groupe:Valeur` (ex. `Taille:M|Couleur:Rouge`)Taux de TVAValeur numérique (ex. `20`), reliée au groupe de taxes du pays par défaut
### Déclinaisons
La colonne des attributs suit le format `Groupe:Valeur|Groupe:Valeur`. Les groupes et valeurs d'attributs manquants sont créés automatiquement, et la déclinaison est identifiée par son jeu exact d'attributs — relancer l'import ne crée donc pas de doublon. Le produit parent est retrouvé par sa référence ou son ID selon la clé de correspondance.
### Caractéristiques
Utilisez le format `Nom:Valeur|Nom:Valeur`. Chaque caractéristique et sa valeur sont créées si elles n'existent pas encore.
### Catégories, images et tags
Ces champs acceptent plusieurs valeurs, séparées par le séparateur multi-valeurs défini dans le profil. Pour les catégories, vous pouvez mélanger noms et IDs ; la première image listée sert de couverture.
## Sources distantes et sécurité
À l'import, le module récupère le fichier depuis une URL (HTTP/HTTPS, avec authentification basique si nécessaire), un serveur FTP (mode passif ou actif), un serveur SFTP ou un chemin local restreint au répertoire de la boutique. À l'export, il peut déposer le fichier généré sur FTP/SFTP ou dans un dossier local, ou le proposer en téléchargement.
Le **SFTP** nécessite l'extension PHP `ssh2`. Si elle est absente de votre hébergement, l'interface l'indique clairement et vous pouvez utiliser FTP ou une URL à la place.
Les mots de passe FTP/SFTP sont chiffrés au repos en base (AES-256-CBC, clé dérivée de la clé de chiffrement de votre boutique) et ne sont jamais renvoyés au navigateur en clair.
## Import par lots et reprise
Les imports manuels s'effectuent par lots successifs en AJAX, avec une barre de progression et des compteurs en temps réel (OK / erreurs / total). Après chaque lot, la position exacte est mémorisée : un fichier de plusieurs dizaines de milliers de lignes s'importe sans provoquer de timeout PHP, même sur un hébergement mutualisé. En mode cron, le traitement s'enchaîne de façon synchrone jusqu'à la dernière ligne.
## Export
Créez un profil d'export en choisissant l'entité (produits, catégories, clients, commandes), le format (CSV ou XML) et les champs à inclure. Le fichier généré est proposé en téléchargement immédiat et/ou déposé automatiquement sur la destination distante configurée. Les exports sont générés par lots pour rester performants sur de gros volumes.
## Planification (cron)
Pour automatiser un profil, activez sa planification (étape 4) puis appelez l'URL de cron du module à intervalle régulier. À chaque appel, seuls les profils dont la fréquence est échue s'exécutent.
```
*/15 * * * * curl -s "https://votre-boutique.tld/index.php?fc=module&module=dfcsvpro&controller=cron&token=VOTRE_TOKEN" > /dev/null
```
L'URL exacte et le token se trouvent dans l'onglet **Scheduling / Cron** du module, avec un bouton pour régénérer le token. Deux paramètres facultatifs :
- `&id_profile=N` : n'exécute que le profil indiqué.
- `&force=1` : ignore la vérification de fréquence et lance le profil immédiatement.
La boutique doit être accessible pour que le cron fonctionne : le mode maintenance bloque les contrôleurs front, y compris cet endpoint.
## Journaux et alertes e-mail
Chaque exécution est journalisée avec son statut, ses compteurs et le détail des erreurs ligne par ligne (les 200 premières). L'onglet **Logs** liste l'historique et permet de consulter les erreurs d'un import. Dès qu'un import échoue ou contient des lignes en erreur, une alerte e-mail (modèle FR ou EN) est envoyée automatiquement vers l'adresse configurée dans les réglages.
## Réglages
Dans l'onglet **Réglages**, activez ou désactivez les alertes e-mail, définissez l'adresse destinataire, la taille de lot par défaut et la durée de rétention des journaux (les logs plus anciens sont purgés automatiquement). Les fichiers temporaires d'import/export sont nettoyés après 48 heures.
## Format XML
À l'import XML, le nœud d'item répété est détecté automatiquement (ou précisé dans le profil). Les items sont aplatis : les éléments imbriqués deviennent des colonnes `parent/enfant`, les attributs deviennent `@attribut`, et les éléments répétés sont suffixés `nom#1`, `nom#2`. Vous mappez ensuite ces colonnes aplaties comme pour un CSV.
## Compatibilité et notes techniques
- Compatible PrestaShop 8.0 à 9.x, PHP 7.4 à 8.3, multiboutique.
- CSV : détection automatique du délimiteur, gestion du BOM, conversion des encodages ISO-8859-1 et Windows-1252.
- Clients importés avec mot de passe haché en bcrypt et rattachés à un groupe par nom.
- Aucun override du cœur ; l'AJAX legacy utilise les conventions PS9.
## Dépannage
**L'interface du module reste vide ou les listes déroulantes ne se remplissent pas.** Videz le cache PrestaShop puis forcez le rechargement du navigateur (Ctrl+Maj+R). Si un gestionnaire de cache/CCC est actif, régénérez les assets.
**Le SFTP échoue.** Vérifiez que l'extension PHP `ssh2` est installée sur le serveur ; sinon, utilisez FTP ou une URL.
**Le cron ne se déclenche pas.** Vérifiez le token, que la boutique n'est pas en maintenance, et que le profil a bien une planification activée et une source automatique (les profils en upload manuel ne peuvent pas être planifiés).
**Des lignes sont en erreur.** Ouvrez le détail du log : chaque erreur indique le numéro de ligne et la cause (colonne clé manquante, valeur invalide, etc.).
---
### Import Fournisseurs & Dropshipping pour PrestaShop 8 & 9
_Source :_
> Guide complet d'installation et de configuration du module Import Fournisseurs & Dropshipping pour PrestaShop 8 et 9 : fournisseurs, flux CSV/XML/JSON, mapping, règles de marge, priorité EAN et synchronisation du stock par cron.
## Présentation
Le module **Import Fournisseurs & Dropshipping** (nom technique `dfsupplierfeed`) importe et synchronise automatiquement les catalogues de vos fournisseurs dans PrestaShop 8 et 9. Il gère plusieurs fournisseurs et plusieurs flux aux formats CSV, XML et JSON, applique vos règles de marge pour calculer les prix de vente à partir du coût d'achat, synchronise le stock toutes les heures via cron, et arbitre les doublons EAN13 entre sources grâce à une priorité par fournisseur.
Le module ne remplace pas l'import CSV natif de PrestaShop (fait pour un chargement manuel unique) : il industrialise des imports _récurrents_ depuis plusieurs sources, avec marges et synchronisation de stock automatiques.
## Installation
1. Depuis le back-office, allez dans **Modules > Gestionnaire de modules**, puis **Téléverser un module**.
2. Sélectionnez le fichier `dfsupplierfeed.zip` et validez.
3. Une fois installé, cliquez sur **Configurer**.
À l'installation, le module crée cinq tables (`dfsf_supplier`, `dfsf_feed`, `dfsf_rule`, `dfsf_product`, `dfsf_log`) et génère un jeton de cron unique.
## Vue d'ensemble de l'interface
La page de configuration est organisée en onglets :
- **Dashboard** — compteurs (fournisseurs, flux, produits liés, règles) et rappel du fonctionnement.
- **Suppliers** — création des fournisseurs et de leur priorité.
- **Feeds** — définition des flux et de leur mapping.
- **Margin rules** — règles de calcul des prix de vente.
- **Logs** — historique des imports.
- **Settings & Cron** — réglages généraux et URLs de cron prêtes à copier.
## Étape 1 — Créer vos fournisseurs
Dans l'onglet **Suppliers**, ajoutez un fournisseur avec :
- **Nom** — libellé du fournisseur.
- **Priorité** — entier, `1` étant la priorité la plus forte. Elle sert à trancher les doublons EAN13 (voir plus bas).
- **Actif** — un fournisseur inactif est ignoré par le cron.
- **Créer le fournisseur natif PrestaShop** — recommandé : associe un fournisseur PrestaShop standard, ce qui remplit aussi le coût d'achat dans `product_supplier`.
Attribuez les meilleures priorités (chiffres les plus bas) aux fournisseurs les plus fiables ou les moins chers : ce sont eux qui « posséderont » les produits partagés.
## Étape 2 — Configurer un flux
Dans l'onglet **Feeds**, chaque flux est rattaché à un fournisseur et comporte :
- **Type de source** — _URL_ distante ou _fichier local_ (chemin relatif à la racine de la boutique, restreint à ce répertoire pour des raisons de sécurité).
- **Source** — l'URL ou le chemin du fichier. Les réponses compressées gzip sont décodées automatiquement.
- **Format** — CSV, XML ou JSON.
- **Prix TTC ?** et **Taux de taxe** — si le flux fournit des coûts TTC, le module les convertit en HT avec ce taux.
- **Catégorie par défaut** — catégorie des produits créés sans catégorie explicite.
- **Créer les produits manquants**, **Importer les images**, **Inclure dans la sync horaire**, **Actif**.
### Le mapping des champs
Le mapping est un objet JSON qui relie les colonnes/nœuds de votre flux aux champs produit normalisés. Les 13 champs canoniques disponibles sont : `name`, `reference`, `ean13`, `cost`, `quantity`, `description`, `description_short`, `category`, `manufacturer`, `weight`, `tax_rate`, `image`, `mpn`.
### Mapping CSV
Reliez chaque champ à un **en-tête de colonne** (ou à un index de colonne à partir de 0). Le délimiteur est détecté automatiquement (`;`, `,`, tabulation ou `|`) et les virgules décimales sont acceptées.
```
{
"fields": {
"name": "product_name",
"reference": "sku",
"ean13": "ean",
"cost": "price",
"quantity": "stock",
"image": "image_url"
}
}
```
### Mapping XML
Renseignez `items_path`, le chemin des nœuds répétés (ex. `products/product`), puis mappez chaque champ à un chemin relatif. Un préfixe `@` lit un attribut, et les sous-éléments se séparent par des barres obliques.
```
{
"items_path": "products/product",
"fields": {
"reference": "@sku",
"name": "title",
"ean13": "ean",
"cost": "pricing/wholesale",
"quantity": "stock/quantity"
}
}
```
### Mapping JSON
Renseignez `items_path`, le chemin du tableau d'articles en notation pointée (ex. `data.products`), puis mappez chaque champ. Les index de tableau s'écrivent comme des segments numériques (ex. `images.0`).
```
{
"items_path": "data.products",
"fields": {
"reference": "sku",
"name": "name",
"ean13": "barcode",
"cost": "prices.cost",
"quantity": "inventory.available",
"image": "images.0"
}
}
```
Une ligne est ignorée si elle n'a ni EAN13 ni référence fournisseur : ce sont les deux clés de rapprochement. Les EAN sont validés puis normalisés sur 13 chiffres.
## Étape 3 — Définir vos marges
Dans l'onglet **Margin rules**, chaque règle calcule le prix de vente HT à partir du coût d'achat HT :
- **Pourcentage** — `coût × (1 + valeur/100)`. Ex. valeur 35 → +35 %.
- **Coefficient** — `coût × valeur`. Ex. valeur 1,8 → ×1,8.
- **Addition fixe** — `coût + valeur`.
Un **arrondi psychologique** optionnel s'applique ensuite : `x.99`, `x.95`, `x.90` ou arrondi à l'entier supérieur.
### Portée et résolution des règles
Une règle peut viser un fournisseur, une catégorie, les deux, ou être globale. Lorsqu'un produit correspond à plusieurs règles, la plus spécifique gagne, selon cet ordre :
1. fournisseur **+** catégorie
2. fournisseur seul
3. catégorie seule
4. règle globale
Les règles de catégorie s'appliquent aussi aux sous-catégories : une règle sur la catégorie exacte du produit l'emporte sur une règle placée sur une catégorie parente. En l'absence de toute règle, la **marge par défaut** (onglet Settings) est utilisée.
## La priorité EAN entre sources
C'est le cœur du module en multi-fournisseurs. Quand le même `ean13` apparaît dans plusieurs flux :
- Le fournisseur dont la priorité est la meilleure (chiffre le plus bas) **possède** le produit ; les prix, stock et coût proviennent de son flux.
- Les autres sources sont **ignorées** pour cette référence (statut « skipped » dans les logs).
- Si un fournisseur mieux priorisé apporte ensuite cet EAN, il **reprend automatiquement** la propriété du produit.
Vous décidez qui fait autorité en jouant sur les priorités : commander la même référence chez plusieurs grossistes devient sûr, sans que les flux se contredisent.
## Lancer un import manuellement
Depuis l'onglet **Feeds**, chaque flux dispose de deux boutons :
- **Import complet** (icône lecture) — met à jour les produits liés _et_ crée les produits manquants (si le flux l'autorise).
- **Sync stock** (icône rafraîchir) — met à jour uniquement prix et quantités des produits déjà liés.
## Automatiser avec le cron
L'onglet **Settings & Cron** affiche deux URLs prêtes à copier, protégées par un jeton. Configurez-les dans le planificateur de tâches de votre serveur :
```
# Synchro stock toutes les heures (prix + quantités des produits liés)
0 * * * * curl -s "https://votreboutique.tld/index.php?fc=module&module=dfsupplierfeed&controller=cron&token=VOTRE_TOKEN&mode=stock" > /dev/null
# Import complet chaque nuit (créations + mises à jour)
30 3 * * * curl -s "https://votreboutique.tld/index.php?fc=module&module=dfsupplierfeed&controller=cron&token=VOTRE_TOKEN&mode=full" > /dev/null
```
Ajoutez `&id_feed=N` pour ne traiter qu'un flux précis. L'endpoint renvoie un rapport JSON (créés, mis à jour, ignorés, erreurs par flux).
Si vous régénérez le jeton dans les réglages, pensez à mettre à jour vos tâches cron : l'ancienne URL renverra une erreur 403.
## Réglages généraux
- **Produits créés actifs immédiatement** — désactivé par défaut : les produits créés par les flux sont en brouillon pour que vous les validiez avant publication.
- **Marge par défaut** — appliquée quand aucune règle ne correspond.
- **Rétention des logs** — nombre de jours avant purge automatique.
- **Régénérer le jeton de cron**.
## Suivi et journaux
L'onglet **Logs** liste chaque exécution avec le flux concerné, le mode, les compteurs (créés / mis à jour / ignorés / erreurs), le temps d'exécution et le détail des premières erreurs rencontrées. Les journaux sont purgés automatiquement selon la rétention configurée.
## Dépannage
### « Feed file not found or outside shop directory »
Pour une source fichier, le chemin doit pointer vers un fichier lisible situé dans le répertoire de la boutique. Utilisez un chemin relatif à la racine ou une URL.
### Les produits sont créés mais invisibles en front
C'est le comportement par défaut : les produits créés sont désactivés. Vérifiez-les puis activez-les, ou activez « Produits créés actifs immédiatement » dans les réglages.
### Un fournisseur n'écrase jamais un produit partagé
Sa priorité est probablement moins bonne (chiffre plus élevé) que celle du fournisseur propriétaire. Ajustez les priorités dans l'onglet Suppliers.
### Les prix semblent trop élevés/bas
Vérifiez si le flux fournit des coûts TTC (option « Prix TTC ? » + taux de taxe) et contrôlez la règle de marge qui s'applique réellement via l'ordre de résolution.
## Compatibilité
- PrestaShop 8.0 à 9.x, PHP 7.4 à 8.3.
- Sans override du cœur PrestaShop.
- Module traduit en FR, EN, ES, DE, IT.
---
### Indicatif Téléphone International (dfphoneintl)
_Source :_
> Présentation DataFirefly International Phone Input (dfphoneintl) ajoute un sélecteur d'indicatif téléphonique avec drapeau sur les champs Téléphone et Téléphone mobile de PrestaShop, et uniformise les numéros au format international E.164…
## Présentation
DataFirefly International Phone Input (`dfphoneintl`) ajoute un sélecteur d'indicatif téléphonique avec drapeau sur les champs **Téléphone** et **Téléphone mobile** de PrestaShop, et uniformise les numéros au format international E.164 en base de données. Le module agit sur deux niveaux : côté navigateur pour l'expérience utilisateur, et côté serveur pour garantir que toute insertion ou mise à jour d'adresse — y compris via API, back-office ou import — produit un numéro normalisé.
Format de stockage : pour un client français saisissant `0633547864`, la valeur enregistrée en base est `+33633547864` — indicatif du pays, suppression du 0 initial (trunk prefix), aucun espace ni séparateur.
## Prérequis
- PrestaShop 8.0.0 à 9.99.99
- PHP 7.4 minimum (8.1+ recommandé)
- Aucune dépendance externe — le module n'embarque aucune librairie tierce
## Installation
1. Téléchargez l'archive `dfphoneintl-1.0.0.zip` depuis votre compte client DataFirefly.
2. Dans le back-office PrestaShop, allez dans **Modules → Gestionnaire de modules → Installer un module**.
3. Glissez-déposez le fichier ZIP puis cliquez sur **Installer**.
4. Le module s'enregistre automatiquement sur les hooks nécessaires. Aucune table SQL n'est créée — le module lit les indicatifs depuis la table native `ps_country`.
## Configuration
Rendez-vous dans **Modules → Gestionnaire de modules → DataFirefly International Phone Input → Configurer**. Trois réglages sont disponibles :
- **Activer sur le champ « Téléphone »** — active ou désactive le sélecteur et la normalisation sur le champ `phone`.
- **Activer sur le champ « Téléphone mobile »** — idem pour le champ `phone_mobile`.
- **Pays préférés** — liste de codes ISO2 séparés par des virgules (ex. `fr,be,lu,ch,gb,us,de`). Ces pays sont épinglés en haut de la liste déroulante. Valeur par défaut : `fr,be,lu,ch,gb,us,de,es,it,nl`.
La liste des pays affichés dans le sélecteur provient des pays **activés** dans votre boutique (Livraison → Zones géographiques → Pays). Un pays désactivé ou sans indicatif renseigné dans la colonne `call_prefix` n'apparaît pas.
## Fonctionnement côté client
### Pages concernées
Le sélecteur s'affiche sur toutes les pages front où figurent des champs téléphone : création de compte, inscription, gestion des adresses, tunnel de commande (5 étapes et one-page checkout), page identité, page contact et suivi de commande invité.
### Synchronisation avec le pays
Lorsque le client change le pays dans le formulaire d'adresse, l'indicatif du sélecteur se met à jour automatiquement. Sélectionner Belgique passe l'indicatif à +32, Allemagne à +49, etc. Cette synchronisation fonctionne aussi lors des rechargements AJAX du checkout natif : le module écoute les évènements PrestaShop `updatedAddressForm`, `updatedAddress`, `updateCustomerAddressForm` et `changedCheckoutStep`, avec un MutationObserver debouncé en filet de sécurité pour les thèmes fortement personnalisés.
### Détection sur adresses existantes
Si le champ contient déjà un numéro au format international (édition d'une adresse existante), le module détecte le pays correspondant par correspondance du plus long indicatif (longest dial-code match) : `+1242...` est reconnu comme Bahamas et non comme États-Unis.
## Fonctionnement côté serveur
La normalisation serveur est branchée sur les hooks `actionObjectAddressAddBefore` et `actionObjectAddressUpdateBefore`. Avant chaque INSERT ou UPDATE sur la table `ps_address`, les champs `phone` et `phone_mobile` passent par la classe `DfPhoneFormatter`. Cela couvre tous les canaux d'écriture : formulaires front, back-office, webservice, imports CSV, et modules tiers manipulant la classe `Address`.
### Règles de normalisation
Pour une adresse rattachée à un pays d'indicatif +33 :
- Numéro commençant par `+` → conservé tel quel, seuls les séparateurs sont retirés : `+33 6 33 54 78 64` devient `+33633547864`.
- Numéro commençant par `00` → le `00` est remplacé par `+` : `0033633547864` devient `+33633547864`.
- Numéro commençant par `0` (trunk prefix) → le `0` est retiré et l'indicatif est préfixé : `0633547864` devient `+33633547864`.
- Numéro commençant déjà par l'indicatif sans `+` → le `+` est simplement ajouté : `33633547864` devient `+33633547864`.
- Autre numéro composé uniquement de chiffres → l'indicatif est préfixé.
Les adresses existantes ne sont **pas** modifiées rétroactivement à l'installation. La normalisation s'applique à la prochaine sauvegarde de chaque adresse. Pour une normalisation massive de l'existant, contactez le support — un script SQL suivant la même logique est disponible sur demande.
## Compatibilité thèmes et checkout
- Thème Classic PS 8 (Bootstrap 4) et thème PS 9 (Bootstrap 5) supportés nativement.
- Checkout 5 étapes et one-page checkout (OPC) supportés.
- Les drapeaux sont des emojis Unicode (Regional Indicator Symbols) : aucun sprite ni CDN, rendu natif par tous les navigateurs et OS modernes.
- Multiboutique : paramètres globaux, liste de pays filtrée par boutique.
- Multilangue : noms de pays affichés dans la langue du visiteur.
## Dépannage
### Le sélecteur ne s'affiche pas
- Vérifiez que le champ est activé dans la configuration du module.
- Vérifiez que votre thème utilise bien les noms de champs standards `phone` / `phone_mobile` (ou `address[phone]` / `address[phone_mobile]`). Pour un champ renommé par un thème custom, contactez le support.
- Videz le cache PrestaShop (Paramètres avancés → Performances) après l'installation.
### Les drapeaux s'affichent comme des lettres (FR, BE...)
Comportement attendu sur certains anciens systèmes Windows qui ne rendent pas les emojis drapeaux. L'indicatif `+33` reste affiché et le module reste pleinement fonctionnel.
### L'indicatif ne suit pas le changement de pays
Sur un thème très personnalisé dont le select pays n'utilise pas le nom `id_country`, la synchronisation automatique ne peut pas s'accrocher. Le MutationObserver ré-initialise néanmoins le widget, et le client peut choisir manuellement son indicatif. Contactez le support avec l'URL de votre boutique pour une adaptation.
## Désinstallation
La désinstallation supprime les trois clés de configuration du module. Les numéros déjà normalisés en base restent au format international — aucune donnée client n'est modifiée ni supprimée.
## Support
Support par email inclus, mises à jour incluses pendant 12 mois. Garantie satisfait ou remboursé 14 jours sur tous les modules DataFirefly.
---
### Injecteur de code Header/Footer (CSS/JS) — Guide complet
_Source :_
> Présentation L'Injecteur de code Header/Footer permet d'ajouter du code CSS, JavaScript ou HTML à votre boutique PrestaShop sans modifier le moindre fichier du thème. Tout se gère depuis le back-office…
## Présentation
L'**Injecteur de code Header/Footer** permet d'ajouter du code CSS, JavaScript ou HTML à votre boutique PrestaShop sans modifier le moindre fichier du thème. Tout se gère depuis le back-office sous forme de _snippets_ : chaque bloc de code possède son emplacement, son ciblage de pages, son ordre d'injection et son statut actif ou inactif.
Cas d'usage typiques : Google Tag Manager, Google Analytics, Meta Pixel, balises de vérification (Search Console, Pinterest...), styles CSS personnalisés, scripts de chat ou bandeau de consentement cookies.
## Installation
1. Téléchargez l'archive `dfcodeinjector.zip` depuis votre compte DataFirefly.
2. Dans le back-office, ouvrez **Modules > Gestionnaire de modules**, cliquez sur **Envoyer un module** et déposez l'archive.
3. Cliquez sur **Configurer** pour ouvrir le gestionnaire de snippets.
Compatible PrestaShop 8.0 à 9.x, PHP 8.1 et supérieur, multiboutique. Aucune dépendance externe.
## Créer un snippet
Depuis le gestionnaire, cliquez sur **Ajouter un snippet** et renseignez les champs ci-dessous.
### Champs du formulaire
- **Nom** — identifiant interne du snippet (ex. « Google Tag Manager »).
- **Emplacement** — l'endroit où le code est injecté (voir ci-dessous).
- **Code** — collez votre code complet, balises comprises. Il est injecté tel quel, sans transformation ni purification.
- **Pages ciblées** — laissez vide pour toutes les pages, ou sélectionnez des pages précises.
- **Ordre d'affichage** — les snippets d'un même emplacement sont injectés par ordre croissant.
- **Actif** — active ou désactive le snippet sans le supprimer.
### Les trois emplacements
- **Header (balise head)** — pour les styles, balises meta et balises de vérification. Injecté via le hook `displayHeader`.
- **Début du body** — juste après l'ouverture du body, pour les conteneurs de balisage (ex. la partie noscript de GTM). Hook `displayAfterBodyOpeningTag`.
- **Fin du body** — juste avant la fermeture du body, pour les scripts de performance et de suivi. Hook `displayBeforeBodyClosingTag`.
### Ciblage par page
Chaque snippet peut être diffusé partout (champ vide) ou restreint à certaines pages : accueil, fiche produit, catégorie, CMS, recherche, panier, tunnel de commande, etc. Le module compare la page courante au contrôleur front (`php_self`) ; si une liste est renseignée et que la page n'en fait pas partie, le snippet n'est pas injecté.
## Exemples
### Google Tag Manager
GTM se pose en deux parties. Créez deux snippets :
1. Snippet « GTM head » — emplacement **Header**, collez le premier script fourni par Google :
```
(function(w,d,s,l,i){ ... })(window,document,'script','dataLayer','GTM-XXXXXX');
```
1. Snippet « GTM body » — emplacement **Début du body**, collez la partie noscript fournie par Google.
### CSS personnalisé
Emplacement **Header**, entourez votre CSS d'une balise style :
```
.header-banner { background:#0f172a; color:#fff; }
```
### Balise de vérification
Pour Search Console ou un réseau social, emplacement **Header** :
```
```
## Multiboutique
En contexte multiboutique, chaque snippet peut être global (toutes les boutiques) ou réservé à une boutique précise via le champ **Boutique**. En mono-boutique, ce champ est masqué et le snippet s'applique à la boutique courante.
## Compatibilité des thèmes
L'injection dans la **balise head** fonctionne avec tous les thèmes. Les emplacements **début** et **fin de body** reposent sur les hooks `displayAfterBodyOpeningTag` et `displayBeforeBodyClosingTag`, présents dans le thème Classic de PrestaShop. Sur un thème personnalisé, vérifiez que ces hooks sont bien appelés dans les templates.
## Dépannage
- **Le code n'apparaît pas** — vérifiez que le snippet est actif, que l'emplacement est correct et que la page courante fait partie des pages ciblées (ou que ce champ est vide).
- **Rien en début ou fin de body** — votre thème n'appelle probablement pas les hooks correspondants ; utilisez l'emplacement Header ou ajoutez ces hooks au thème.
- **Conflit d'ordre** — ajustez le champ Ordre d'affichage pour contrôler la séquence d'injection.
Le code étant injecté sans purification, vérifiez votre syntaxe (balises bien fermées) avant d'activer un snippet sur une boutique en production.
---
### Journal d'audit BO — Guide complet
_Source :_
> Présentation Le module Journal d'audit BO enregistre qui a modifié quoi et quand dans votre back-office PrestaShop. Pour chaque création, modification ou suppression, il conserve l'employé concerné, son profil, l'adresse…
## Présentation
Le module **Journal d'audit BO** enregistre qui a modifié quoi et quand dans votre back-office PrestaShop. Pour chaque création, modification ou suppression, il conserve l'employé concerné, son profil, l'adresse IP, le contrôleur, la méthode HTTP, l'URL, l'horodatage et — pour les modifications — le détail champ par champ (ancienne valeur → nouvelle valeur). Il trace également le début de session de chaque employé et, sur PrestaShop 8, les tentatives de connexion échouées et les déconnexions.
Le module s'appuie exclusivement sur les hooks natifs d'ObjectModel et n'effectue aucune surcharge (override) du cœur. Il est compatible PrestaShop 8 et 9, en mono comme en multi-boutique, et multilingue.
Le journal est conçu pour la sécurité et la conformité RGPD : il fournit une piste d'audit fiable (responsabilité et traçabilité des traitements) sans modifier le fonctionnement de votre boutique.
## Installation
1. Depuis le back-office, ouvrez **Modules > Gestionnaire de modules**.
2. Cliquez sur **Installer un module** et déposez l'archive ZIP du module.
3. Une fois l'installation terminée, cliquez sur **Configurer**.
À l'installation, le module crée deux tables dédiées (le journal et le détail des champs modifiés), enregistre ses hooks et ajoute l'entrée de menu **Paramètres avancés > Journal d'audit**. Aucune configuration n'est obligatoire pour démarrer : un ensemble d'entités pertinent est déjà activé par défaut.
## Fonctionnement
Le module écoute les hooks génériques d'ObjectModel présents dans PrestaShop 8 et 9 (ajout, mise à jour et suppression d'objets) ainsi que le hook d'affichage du back-office. À chaque opération sur une entité surveillée :
- il identifie l'employé connecté, son profil et la boutique active ;
- pour une modification, il compare l'état avant et après et n'enregistre que les champs réellement changés ;
- pour une création ou une suppression, il enregistre (en option) l'ensemble des champs de l'objet ;
- il écrit l'entrée directement en base de données.
Les écritures se font en SQL direct, sans repasser par ObjectModel : il n'y a donc aucun risque de récursion des hooks, et l'audit ne peut jamais interrompre une opération métier.
## Configuration
### Entités surveillées
Cochez les entités à tracer, regroupées par domaine : **Catalogue** (produits, catégories, fabricants, fournisseurs, déclinaisons, prix spécifiques, images, stocks…), **Clients & commandes** (commandes, états de commande, clients, adresses, groupes, règles panier), **Transport & localisation** (transporteurs, pays, zones, devises, taxes), **Contenu** (pages et catégories CMS, métadonnées) et **Administration & sécurité** (employés, profils, clés webservice, boutiques, configuration).
Seules les entités cochées sont enregistrées. Un jeu pertinent et peu verbeux est activé par défaut ; la _Configuration_ est désactivée par défaut car très bavarde.
### Tracer les connexions BO
Lorsque cette option est active, le module enregistre le **début de session** de chaque employé. Sur PrestaShop 8, il enregistre aussi les **tentatives de connexion échouées** (avec l'e-mail saisi) et les **déconnexions**.
Sur PrestaShop 9, la page de connexion est gérée par Symfony : les connexions réussies sont tracées, mais les échecs et déconnexions sur l'écran de login ne sont pas captés. Toutes les modifications de données restent tracées sur les deux versions.
### Conserver le détail des créations/suppressions
Active l'enregistrement de l'ensemble des champs lors d'un ajout ou d'une suppression. Désactivez cette option pour ne conserver que l'évènement (qui, quoi, quand) sans le détail complet de l'objet.
### Tracer aussi les actions hors back-office
Par défaut, seules les actions effectuées par un employé connecté au back-office sont enregistrées. Activez cette option pour tracer également les modifications déclenchées en front-office, par une tâche CRON ou via le webservice. Le volume d'entrées peut alors augmenter sensiblement.
### Rétention
Définissez la durée de conservation en jours (365 par défaut). Une purge automatique quotidienne supprime les entrées plus anciennes. Réglez la valeur sur **0** pour une conservation illimitée.
### Employés exclus
Saisissez les identifiants d'employés (séparés par des virgules) dont les actions ne doivent pas être tracées — par exemple un compte technique d'intégration.
### Limites de volume
Deux réglages protègent la base : le **nombre maximum de champs** enregistrés par entrée et la **longueur maximale** d'une valeur (au-delà, la valeur est tronquée). Un garde-fou interne limite par ailleurs le nombre d'entrées écrites par requête pour préserver les performances lors des imports de masse.
## Consulter le journal
Rendez-vous dans **Paramètres avancés > Journal d'audit**. La liste affiche, pour chaque entrée : la date, le type d'action (badge coloré), l'entité, l'identifiant et le libellé de l'objet, le nombre de champs modifiés, l'employé, le profil, l'adresse IP et le contrôleur. Vous pouvez filtrer et trier sur ces colonnes.
### Vue détaillée
Cliquez sur une entrée pour ouvrir sa vue détaillée. Elle présente le contexte complet (employé, IP, contrôleur, méthode, URL, User-Agent) et, pour une modification, un **tableau de différences** champ par champ : l'ancienne valeur (sur fond rosé, barrée) et la nouvelle (sur fond verdâtre).
## Sécurité des données sensibles
Les champs sensibles ne sont jamais enregistrés en clair. Tout champ dont le nom contient un terme sensible (mot de passe, `secure_key`, token, clé d'API, clé webservice…) est automatiquement remplacé par des astérisques. Le journal indique qu'un champ sensible a changé sans en révéler la valeur.
## Conformité, rétention et export
Le journal conserve le nom de l'employé même après sa suppression, garantissant une piste d'audit durable. Depuis l'écran du journal, le bouton **Exporter en CSV** génère un fichier UTF-8 (compatible Excel) reprenant toutes les colonnes : date, action, entité, objet, employé, profil, IP, contrôleur, méthode et URL. Le bouton **Purger** supprime l'ensemble des entrées (action réservée aux profils disposant du droit de suppression).
L'export CSV est idéal pour fournir vos preuves d'audit à un DPO, un commissaire aux comptes ou un auditeur de sécurité.
## Désinstallation
La désinstallation supprime les tables du journal, l'ensemble de l'historique, les hooks et l'entrée de menu. Cette opération est définitive : pensez à exporter le journal au préalable si vous devez en conserver une trace.
## FAQ
### Le module ralentit-il le back-office ?
L'impact est minime : écritures en SQL direct, filtrage par entité et garde-fou de volume. Vous pouvez réduire encore la charge en limitant les entités surveillées.
### Les mots de passe sont-ils enregistrés ?
Non. Les champs sensibles sont masqués par des astérisques avant stockage.
### Le module modifie-t-il le cœur de PrestaShop ?
Non, aucun override. Le module utilise uniquement les hooks officiels d'ObjectModel et un autoloader interne.
### Les actions du front-office sont-elles tracées ?
Par défaut non : le journal se concentre sur les actions des employés en back-office. Vous pouvez activer la traçabilité des actions front-office, CRON et webservice dans la configuration.
### Le module est-il compatible PrestaShop 9 ?
Oui, compatible PrestaShop 8.x et 9.x, en mono comme en multi-boutique et multilingue.
---
### Liste de Naissance, Mariage & Cadeaux — Guide complet
_Source :_
> Présentation et prérequis Le module Liste de Naissance, Mariage & Cadeaux ajoute à votre boutique un système complet de listes de cadeaux partagées. Vos clients créent leur liste depuis leur…
## Présentation et prérequis
Le module Liste de Naissance, Mariage & Cadeaux ajoute à votre boutique un système complet de listes de cadeaux partagées. Vos clients créent leur liste depuis leur compte, y ajoutent des produits de votre catalogue et partagent un lien public. Leurs proches réservent les cadeaux, qui sont ajoutés au panier puis confirmés à la validation de la commande. Le propriétaire de la liste est alors notifié par email.
- Compatible PrestaShop 8.0 à 9.x.
- PHP 7.4 à 8.3, MySQL 5.7+ / MariaDB 10.3+.
- Multiboutique et multilingue (FR/EN/ES/DE/IT).
- Architecture ObjectModel et contrôleurs front legacy, sans dépendance Symfony, sans surcharge du cœur.
Le module crée trois tables dédiées (`df_giftregistry`, `df_giftregistry_item`, `df_giftregistry_reservation`) et n'altère aucun fichier du cœur. La désinstallation supprime ces tables, l'onglet d'administration et les réglages.
## Installation
1. Téléchargez l'archive `dfgiftregistry.zip` depuis votre compte client.
2. Dans le back-office, allez dans **Modules > Gestionnaire de modules**.
3. Cliquez sur **Installer un module** et déposez l'archive.
4. L'installation crée les tables, enregistre les hooks (`displayCustomerAccount`, `displayProductAdditionalInfo`, `actionFrontControllerSetMedia`, `actionValidateOrder`) et ajoute l'onglet d'administration sous **Clients**.
Une fois installé, le module est immédiatement actif : le bloc de liste apparaît dans l'espace client et le bouton d'ajout sur la fiche produit.
## Réglages du module
Cliquez sur **Configurer** depuis le Gestionnaire de modules pour accéder à la page de réglages :
- **Bouton sur la fiche produit** : affiche ou masque le bouton « Ajouter à une liste de cadeaux » sur les pages produit.
- **Don par les invités** : autorise les visiteurs non connectés à offrir un cadeau, en indiquant leur nom et un email facultatif.
- **Notification du propriétaire** : envoie un email au propriétaire à chaque cadeau confirmé.
- **Révélation des noms** : affiche le nom du donateur au propriétaire, sauf si le donateur a choisi de rester anonyme.
- **Délai de rétention** (`DFGR_HOLD_MINUTES`, 180 min par défaut) : durée au-delà de laquelle une réservation en attente non finalisée est libérée automatiquement.
- **Nombre maximum de listes par client** (`DFGR_MAX_PER_CUSTOMER`, 5 par défaut).
## Côté client : créer et gérer une liste
### Créer une liste
Depuis son compte, le client ouvre la rubrique des listes de cadeaux et crée une nouvelle liste. Il choisit un type (naissance, mariage, anniversaire, crémaillère, autre), saisit un titre, et peut renseigner une date d'événement, un message d'accueil, une description et une adresse de livraison. La liste est publique par défaut, mais peut être rendue privée.
### Ajouter des produits
Deux possibilités :
- Depuis la **fiche produit** : le client sélectionne une de ses listes, choisit la quantité souhaitée et clique sur « Ajouter ». La déclinaison sélectionnée sur la fiche est prise en compte.
- Depuis l'**espace de gestion** de la liste : il ajuste la quantité souhaitée et la priorité de chaque produit.
Si un produit est déjà présent dans la liste, l'ajout depuis la fiche produit incrémente simplement la quantité souhaitée.
### Partager la liste
Chaque liste dispose d'un lien public unique. Un bouton « Copier » place ce lien dans le presse-papiers, prêt à être envoyé aux proches par email ou messagerie.
### Suivre les cadeaux reçus
Dans l'espace de gestion, le propriétaire visualise pour chaque produit une barre de progression réservé / restant, ainsi que la liste des cadeaux reçus, avec le nom du donateur selon le réglage de révélation des noms.
## Côté visiteur : offrir un cadeau
En ouvrant le lien public, un proche découvre la liste : type, nom du propriétaire, date de l'événement, message d'accueil et grille des produits. Chaque produit affiche sa progression réservé / restant.
1. Le visiteur clique sur **Offrir ce cadeau** sous le produit choisi.
2. Il indique la quantité (plafonnée au restant), un petit mot facultatif, et — s'il n'est pas connecté — son nom et un email facultatif.
3. Il peut cocher « Rester anonyme » si le réglage de révélation des noms est activé.
4. En validant, le produit est réservé et ajouté à son panier ; il est redirigé vers le panier pour finaliser la commande.
Si le don par les invités est désactivé, seuls les clients connectés peuvent offrir un cadeau.
## Le cycle de réservation
Une réservation passe par les états suivants :
- **En attente** : créée dès que le visiteur clique sur « Offrir ce cadeau » et que le produit est ajouté au panier.
- **Confirmée** : à la validation de la commande (hook `actionValidateOrder`), la réservation liée au panier est confirmée et rattachée à la commande.
- **Libérée** : une réservation en attente non finalisée, liée à un panier abandonné, est supprimée automatiquement après le délai de rétention.
Le restant d'un produit est égal à la quantité souhaitée moins la somme des réservations en attente et confirmées. Lorsqu'un produit est entièrement réservé, il est verrouillé et ne peut plus être offert, ce qui évite les doublons.
## Côté marchand : back-office
L'onglet **Listes de cadeaux** (sous Clients) liste toutes les listes de la boutique : client, type, nombre de produits, nombre de cadeaux, statut actif/inactif et date de création.
La vue détaillée d'une liste affiche :
- les informations de la liste et du client ;
- les produits avec quantités souhaitée, réservée et restante ;
- les réservations avec le donateur, la quantité, le message, le statut et un lien direct vers la commande associée.
Les listes sont créées par les clients : l'action de création n'est pas disponible côté back-office. Le marchand peut consulter et supprimer.
## Emails de notification
Lorsque la notification du propriétaire est activée, un email est envoyé au propriétaire de la liste à chaque cadeau confirmé. Il reprend le titre de la liste, le produit offert, la quantité, le nom du donateur (selon le réglage de révélation et le choix d'anonymat) et le message éventuel. Les modèles d'email sont fournis en français et en anglais, et sont personnalisables.
## Multilingue et multiboutique
Les libellés du module sont traduisibles via le système de traduction des modules PrestaShop. L'affichage respecte le contexte boutique courant : une liste créée sur une boutique reste rattachée à cette boutique.
## FAQ et dépannage
### Le bouton « Ajouter à une liste » n'apparaît pas sur la fiche produit
Vérifiez que l'option **Bouton sur la fiche produit** est activée dans les réglages, et que le hook `displayProductAdditionalInfo` est bien positionné sur votre thème.
### La page publique affiche « liste introuvable »
La liste est peut-être privée, inactive, ou rattachée à une autre boutique. Vérifiez son statut dans l'espace client ou le back-office.
### Un produit reste bloqué alors que la commande n'a pas été passée
Il s'agit d'une réservation en attente. Elle est libérée automatiquement après le délai de rétention défini dans les réglages. Vous pouvez réduire ce délai si nécessaire.
### Le propriétaire ne reçoit pas d'email
Vérifiez que la notification du propriétaire est activée et que l'envoi d'emails est correctement configuré dans **Paramètres avancés > E-mail**.
### Que se passe-t-il à la désinstallation ?
La désinstallation supprime les trois tables du module, l'onglet d'administration et les réglages. Aucune donnée résiduelle ne subsiste.
---
### Live Search Intelligent — Guide complet
_Source :_
> Présentation et prérequis DFLiveSearch remplace la recherche native de PrestaShop par un moteur live en AJAX : un panneau de résultats s'ouvre dès les premiers caractères, avec l'image, le nom,…
## Présentation et prérequis
DFLiveSearch remplace la recherche native de PrestaShop par un moteur live en AJAX : un panneau de résultats s'ouvre dès les premiers caractères, avec l'image, le nom, le prix et les badges promotionnels de chaque produit. Le module ajoute aussi un moteur de recherche intelligent (synonymes, tolérance aux fautes de frappe, pertinence pondérée), des carousels de suggestions (recherches populaires et produits recommandés), un tableau de bord analytique complet et des alertes email sur les recherches sans résultat.
- Compatible PrestaShop 8.0 à 9.x, thème Classic et thèmes dérivés.
- PHP 8.1 et supérieur.
- Multiboutique et multilingue (FR/EN/ES/DE/IT).
- Aucune surcharge de fichiers : uniquement des hooks natifs.
Le module s'appuie sur les hooks `displayHeader`, `displayTop`, `displaySearch`, `displayBackOfficeHeader` et `actionOrderStatusPostUpdate`. Il crée six tables : `dflivesearch_stats`, `dflivesearch_log`, `dflivesearch_alerts`, `dflivesearch_popular`, `dflivesearch_synonyms` et `dflivesearch_lexicon`.
## Installation
Installez le module comme n'importe quel module PrestaShop :
1. Téléchargez l'archive `dflivesearch.zip` depuis votre compte client.
2. Dans le back-office, allez dans **Modules > Gestionnaire de modules**.
3. Cliquez sur **Installer un module** et déposez l'archive.
4. Une fois installé, cliquez sur **Configurer**.
À l'installation, le module enregistre ses hooks, crée ses tables et pré-remplit un texte d'invite (placeholder) traduit dans les cinq langues. Quelques groupes de synonymes courants sont également pré-remplis et le dictionnaire de correction des fautes est construit à partir de votre catalogue. Le champ de recherche live est immédiatement actif sur votre boutique.
## Mise à jour
La mise à jour s'effectue normalement depuis le Gestionnaire de modules. Le script d'upgrade intégré crée les nouvelles tables, applique les valeurs par défaut des nouvelles options (synonymes, pertinence, tolérance aux fautes, apparence de la barre) sans toucher à votre configuration existante, puis reconstruit le dictionnaire de correction. Aucune action manuelle n'est requise. Après mise à jour, videz le cache PrestaShop et régénérez les assets pour purger l'ancien JavaScript.
Après un import catalogue important, pensez à reconstruire le dictionnaire de correction (voir la section « Recherche intelligente ») pour que la correction des fautes reflète votre catalogue à jour.
## Configuration générale
La page de configuration regroupe les réglages du comportement de la recherche :
- **Activer le module** : active ou désactive le champ de recherche live sur la boutique.
- **Texte d'invite (placeholder)** : texte affiché dans le champ, traduisible par langue.
- **Nombre de caractères minimum** : seuil de déclenchement de la recherche (2 par défaut).
- **Nombre maximum de produits** : limite de résultats affichés dans le panneau.
- **Recherches populaires** et **recherches récentes** : affichage des carousels de suggestions avant la frappe.
- **Autocomplétion** : suggestions de termes (produits, catégories, recherches populaires) pendant la saisie, avec navigation au clavier (flèches haut/bas, Entrée, Échap) et surlignage du terme saisi. Le nombre maximum de suggestions est configurable.
- **Ajout rapide au panier** et **sélecteur de quantité** : options permettant d'ajouter un produit directement depuis les résultats.
- **Produits personnalisés** : prend en compte l'historique du client connecté pour les recommandations automatiques.
## Apparence
La section **Apparence** permet d'adapter la recherche à votre charte graphique :
- **Couleur principale** : couleur des boutons et accents (par défaut `#2196F3`).
- **Couleur principale (survol)** : couleur au survol des boutons (par défaut `#1976D2`).
- **Largeur max de la fenêtre** : largeur maximale du panneau de recherche. Accepte une valeur CSS comme `900px`, `1200px` ou `100%`.
- **Taille de la barre de recherche** (depuis la version 1.4.0) : Small, Medium ou Large. Ajuste la hauteur, la taille du texte et celle de l'icône de la barre affichée dans votre en-tête.
- **Largeur de la barre de recherche** : largeur maximale de la barre elle-même (`400px`, `50%`, `30rem`…). Laissez le champ vide pour occuper toute la largeur du conteneur du thème.
- **Arrondi des angles de la barre** : de `0` (angles droits) à `50` px (forme pilule).
- **Raccourci clavier** : ouvre la recherche avec `Ctrl+K` (`Cmd+K` sur Mac) ou la touche `/` depuis n'importe où sur la page. Un badge indicatif (« Ctrl K » ou « ⌘K ») s'affiche dans la barre sur desktop. L'option est désactivable.
Ces valeurs sont injectées en CSS sur le front. Pour une barre de style « pilule » à la Algolia, choisissez un arrondi de 50 et une taille Large. Pour une fenêtre pleine largeur sur mobile comme sur desktop, saisissez `100%` dans la largeur de fenêtre.
Depuis la version 1.4.0, la fenêtre de recherche est entièrement accessible au clavier : la barre est focusable et s'ouvre avec Entrée ou Espace, le focus reste dans la fenêtre pendant la navigation Tab, Échap ferme la fenêtre et le focus revient sur la barre. Un bouton d'effacement apparaît dans le champ dès qu'un texte est saisi, et les animations respectent la préférence système `prefers-reduced-motion`.
## Produits recommandés
Les produits recommandés s'affichent en carousel dès l'ouverture du champ de recherche. Deux modes sont disponibles via le réglage **Source des produits recommandés** :
- **Automatique** : le module sélectionne les meilleures ventes (et tient compte de l'historique client si l'option « Produits personnalisés » est activée).
- **Manuel** : vous choisissez précisément les produits mis en avant.
En mode manuel, un sélecteur dédié apparaît : recherchez un produit par nom ou référence, cliquez pour l'ajouter, puis réorganisez les vignettes par glisser-déposer. L'ordre défini est respecté à l'affichage côté boutique.
Seuls les produits actifs et visibles sont proposés dans le sélecteur. L'ordre des vignettes détermine l'ordre d'apparition dans le carousel.
## Comportement de la recherche
### Recherche par mots
La recherche fonctionne par mots : chaque mot saisi doit être trouvé (dans le nom, la référence, le code EAN ou la description courte), dans n'importe quel ordre. Une requête comme « stéthoscope simple pavillon » trouve donc le produit même si ces mots ne se suivent pas dans le nom. Depuis la version 1.2.0, chaque mot est aussi étendu à ses synonymes et la recherche couvre les références de déclinaisons (voir la section « Recherche intelligente »).
### Produits à déclinaisons
Pour un produit comportant des déclinaisons, le bouton d'ajout au panier est remplacé par un bouton **« Voir les options »** qui renvoie vers la fiche produit, afin que le client choisisse sa déclinaison avant l'ajout. Lorsque le client a recherché la référence exacte d'une déclinaison, ce bouton mène directement à la variante concernée.
### Disponibilité et stock
Les produits en rupture restent affichés dans les résultats et portent un badge « Rupture de stock ». Ce badge n'apparaît pas pour les produits dont la commande hors stock est autorisée (réglage « Accepter les commandes » de PrestaShop) : ceux-ci restent ajoutables au panier.
Si vous saisissez une quantité supérieure au stock disponible d'un produit non commandable hors stock, le module n'ajoute pas le produit et affiche un message indiquant la quantité restante.
## Recherche intelligente : synonymes, fautes de frappe et pertinence
Depuis la version 1.2.0, DFLiveSearch intègre un moteur de recherche intelligent. Tous ces réglages se trouvent dans la section **Recherche intelligente** de la page de configuration.
### Synonymes
Le dictionnaire de synonymes relie des termes équivalents : un client qui cherche « tv » trouve aussi les produits nommés « télévision » ou « téléviseur ». L'éditeur est multilingue (un onglet par langue). Saisissez **un groupe par ligne**, les termes étant séparés par des virgules :
```
tv, télé, télévision, téléviseur
ordinateur, pc, laptop, ordi
casque, écouteurs, headphones
```
Tous les termes d'une même ligne sont considérés comme équivalents : rechercher l'un d'eux étend automatiquement la requête aux autres. Activez ou désactivez la fonctionnalité via l'option **Activer les synonymes**. Quelques groupes courants sont pré-remplis à l'installation ; adaptez-les à votre catalogue.
Les synonymes sont stockés par boutique et par langue. Pensez à renseigner chaque onglet de langue pour couvrir l'ensemble de votre clientèle.
### Tolérance aux fautes de frappe
Lorsqu'une recherche ne renvoie aucun résultat, le module tente automatiquement de corriger la faute à partir d'un dictionnaire construit depuis votre catalogue (noms de produits, références, catégories). Si la correction donne des résultats, ils sont affichés directement avec la mention **« Résultats pour… »** et un lien permettant de revenir à l'orthographe d'origine.
- **Tolérance aux fautes de frappe** : active ou désactive la correction automatique.
- **Distance de correction max** : nombre maximum de caractères différents toléré (1 à 3 ; 2 recommandé). Une valeur plus élevée corrige davantage de fautes mais augmente le risque de faux positifs.
- **Afficher « Vouliez-vous dire ? »** : affiche le bandeau de correction. Désactivée, la correction s'applique silencieusement.
La correction repose sur une présélection phonétique (SOUNDEX) suivie d'un calcul de distance de Levenshtein : elle retrouve par exemple « téléviseur » à partir de « televiseir ». Les mots de moins de trois caractères ne sont pas corrigés ; les équivalences courtes (comme « tv ») relèvent des synonymes.
### Dictionnaire de correction
Le dictionnaire de correction (table `dflivesearch_lexicon`) est construit à l'installation, puis peut être reconstruit à tout moment via le bouton **Reconstruire le dictionnaire** de la page de configuration. La zone d'information affiche le nombre de mots indexés et la date de dernière reconstruction.
Reconstruisez le dictionnaire après un import catalogue important ou un changement massif de noms de produits, afin que la correction des fautes reflète votre catalogue à jour. Vous pouvez aussi automatiser cette reconstruction via une tâche planifiée.
### Pertinence des résultats
Les résultats sont classés par un score de pertinence pondéré : correspondance exacte du nom (score le plus élevé), nom commençant par la requête, requête contenue dans le nom, puis référence et EAN. Deux boosts complètent ce classement :
- **Boost produits en stock** : à pertinence comparable, les produits disponibles remontent en haut de liste.
- **Boost meilleures ventes** : favorise les produits les plus vendus, à partir des statistiques de ventes PrestaShop.
Ces deux options sont activables indépendamment dans la section **Recherche intelligente**.
### Recherche par référence de déclinaison
La recherche couvre désormais les identifiants propres aux déclinaisons : **référence, EAN, UPC et référence fournisseur** de chaque variante. Taper la référence ou le code-barres d'une déclinaison remonte donc le produit parent. Lorsque la requête ressemble à un code, le résultat pointe directement sur la bonne déclinaison (lien vers la variante exacte) et la carte affiche la référence et le prix de cette variante.
Les références purement alphabétiques (sans chiffre) restent trouvables mais ouvrent la fiche sur la déclinaison par défaut. Les références contenant des chiffres (EAN, la plupart des SKU) déclenchent le lien direct vers la variante exacte.
## Tableau de bord et statistiques
Le module enregistre chaque recherche (terme saisi, nombre de résultats, clic éventuel sur un produit, conversion en commande). Le tableau de bord du back-office présente :
- le total des recherches et le nombre de recherches uniques ;
- les taux de succès, de clic et de conversion ;
- un graphique d'évolution des recherches par jour ;
- le top 20 des recherches avec clics et conversions ;
- le top 20 des recherches sans résultat ;
- un export CSV de l'ensemble des données.
Le suivi des conversions s'effectue via le hook `actionOrderStatusPostUpdate` : une commande passée après un clic dans les résultats de recherche est comptabilisée comme convertie. Depuis la version 1.3.0, chaque commande n'est comptabilisée qu'une seule fois, quels que soient les changements de statut ultérieurs.
## Alertes email
Le système d'alerte surveille les termes qui ne renvoient aucun résultat. Dès qu'un terme dépasse le seuil configurable (5 par défaut), une alerte email est envoyée à l'adresse de votre choix et une notification apparaît dans l'en-tête du back-office. Chaque alerte peut être marquée comme lue ou supprimée. Les templates d'email sont fournis dans les cinq langues (FR/EN/ES/DE/IT) et le sujet est envoyé dans la langue par défaut de la boutique. Ces recherches sans résultat sont une source précieuse pour détecter les lacunes du catalogue, les fautes de frappe fréquentes ou les synonymes manquants à ajouter.
## Rétention des données
Les logs de recherche sont conservés 90 jours par défaut (durée configurable). Un bouton de nettoyage manuel est disponible dans le back-office, et depuis la version 1.3.0 une purge automatique s'applique en continu selon la durée de rétention configurée.
## FAQ et dépannage
### Comment configurer les synonymes ?
Dans la section « Recherche intelligente » de la configuration, saisissez un groupe de synonymes par ligne (termes séparés par des virgules) dans l'onglet de chaque langue, puis enregistrez. Vérifiez que l'option « Activer les synonymes » est active.
### Comment changer la taille ou la forme de la barre de recherche ?
Dans la section « Apparence », choisissez la taille (Small / Medium / Large), la largeur maximale et l'arrondi des angles de la barre. Un arrondi de 50 donne une barre en forme de pilule. Ces réglages ne concernent que la barre affichée dans l'en-tête ; la fenêtre de résultats se règle via « Largeur max de la fenêtre ».
### Comment désactiver le raccourci Ctrl+K ?
Dans la section « Apparence », passez l'option « Raccourci clavier » sur Non. Le badge disparaît de la barre et les touches Ctrl+K, Cmd+K et / ne déclenchent plus l'ouverture de la recherche.
### Une recherche avec une faute renvoie une page vide
Vérifiez que l'option « Tolérance aux fautes de frappe » est activée et que le dictionnaire de correction contient des mots (zone d'information de la configuration). Après un import important, cliquez sur « Reconstruire le dictionnaire ». Vous pouvez aussi augmenter la « Distance de correction max ».
### La recherche ne trouve pas une référence de déclinaison
La recherche par référence de variante (réf, EAN, UPC, réf fournisseur) est disponible depuis la version 1.2.0. Mettez à jour, videz le cache et régénérez les assets. Pour obtenir le lien direct vers la variante exacte, la requête doit ressembler à un code (contenir au moins un chiffre).
### La recherche ne renvoie rien pour plusieurs mots
La recherche fonctionne par mots indépendants de l'ordre. Si vous venez de mettre à jour, videz le cache PrestaShop et régénérez les assets pour charger le nouveau JavaScript.
### Le panneau d'autocomplétion masque les résultats
L'autocomplétion se ferme automatiquement lorsque le champ perd le focus ou avec la touche Échap. Assurez-vous d'utiliser la dernière version et videz le cache si l'ancien comportement persiste.
### Un badge « rupture de stock » apparaît sur un produit commandable
Le module lit le réglage « Accepter les commandes » dans **Quantités** de la fiche produit (stocké côté `StockAvailable` sur PrestaShop 8). Vérifiez ce réglage : s'il autorise la commande, aucun badge ne sera affiché.
### Que se passe-t-il à la désinstallation ?
La désinstallation supprime proprement les hooks, les variables de configuration et les six tables du module. Aucune donnée résiduelle n'est laissée en base.
---
### LLMs.txt & AEO Shopware — Guide complet
_Source :_
> Présentation DataFirefly LLMs.txt & AEO est un plugin Shopware 6.7 qui rend votre boutique visible et compréhensible par les moteurs de réponse IA (ChatGPT, Claude, Perplexity, Gemini). Il agit sur…
## Présentation
DataFirefly LLMs.txt & AEO est un plugin Shopware 6.7 qui rend votre boutique visible et compréhensible par les moteurs de réponse IA (ChatGPT, Claude, Perplexity, Gemini). Il agit sur trois plans complémentaires :
- **llms.txt / llms-full.txt** — deux fichiers conformes à la spécification [llmstxt.org](https://llmstxt.org), générés automatiquement à la racine de chaque sales-channel, dans chaque langue active.
- **Schema.org JSON-LD** — injection automatique de données structurées sur toutes les pages : Organization, Product enrichi, BreadcrumbList, FAQPage, HowTo et Speakable.
- **Pilotage des crawlers IA** — un endpoint `/robots-ai.txt` avec contrôle individuel de 9 bots (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended, Bingbot, Meta-ExternalAgent, CCBot, cohere-ai).
**Prérequis :** Shopware 6.7.0+, PHP 8.2+, MySQL 8.0+ ou MariaDB 10.6+. Le plugin fonctionne sur le storefront standard et les thèmes personnalisés (héritage Twig).
## Installation
### Via ZIP (recommandé)
1. Téléchargez `DataFireflyLlmsAeo.zip` depuis votre compte client.
2. Administration Shopware → **Extensions → Mes extensions → Téléverser une extension**.
3. Cliquez sur **Installer**, puis **Activer**.
4. Videz le cache : **Paramètres → Système → Cache & index**, ou en CLI :
```
bin/console cache:clear
```
### Via CLI
```
unzip DataFireflyLlmsAeo.zip -d custom/plugins/
bin/console plugin:refresh
bin/console plugin:install --activate DataFireflyLlmsAeo
bin/console cache:clear
```
À l'activation, le plugin installe automatiquement le set de champs personnalisés `datafirefly_aeo` sur les produits, catégories, pages CMS et fabricants. Aucune migration manuelle n'est nécessaire.
### Compilation des assets administration
Si le module d'administration n'apparaît pas sous Marketing après activation :
```
bin/console bundle:dump
./bin/build-administration.sh
bin/console cache:clear
```
## Configuration
La configuration se trouve dans **Paramètres → Système → Extensions → DataFirefly llms.txt & AEO**. Elle est scopée par sales-channel : sélectionnez un canal spécifique dans le sélecteur en haut pour surcharger les valeurs globales.
### Carte « Général »
- **Activer le module** — interrupteur global (par sales-channel).
- **Auteur du site** — utilisé dans l'en-tête du llms.txt.
- **Description du site** — blockquote d'en-tête du llms.txt ; décrivez votre boutique en 1-2 phrases orientées IA.
- **Durée du cache** — TTL en secondes (défaut : 3600).
### Carte « llms.txt »
- Inclure les **pages CMS**, **catégories**, **marques** et/ou **produits**.
- **Nombre maximum de produits** listés dans l'index.
- **Inclure les produits inactifs** — désactivé par défaut, à laisser désactivé en production.
### Carte « AEO & Schema.org »
- Toggles individuels : Organization, Product enrichi, BreadcrumbList, FAQPage, HowTo, Speakable.
- **Logo et URL de l'organisation** — surchargent les valeurs du sales-channel.
- **Téléphone, email de contact, profils sociaux** — alimentent le schéma Organization (`contactPoint`, `sameAs`).
### Carte « Crawlers IA »
Pour chacun des 9 bots, trois modes :
- **Autorisé** — accès complet (aucune directive restrictive).
- **Refusé** — `Disallow: /` pour ce bot.
- **Sélectif** — `Disallow` sur les chemins que vous listez (un par ligne, ex. `/checkout/`, `/account/`).
Le contenu de `/robots-ai.txt` n'est pas fusionné automatiquement dans votre `robots.txt` principal. Copiez son contenu dans votre robots.txt, ou ajoutez une règle de réécriture serveur (voir la section [Intégration robots.txt](#robots-integration)).
## Les trois endpoints
URLContenuEn-têtes`/llms.txt`Index synthétique : Pages, Catégories, Marques, Produits, Optional`text/plain; charset=UTF-8`, `X-Robots-Tag: noindex`, cache public`/llms-full.txt`Contenu intégral : descriptions nettoyées, SKU, EAN, marque, caractéristiques groupées, FAQidem`/robots-ai.txt`Bloc de directives User-agent pour les 9 crawlers IAidem
Vérification rapide après installation :
```
curl -I https://votre-boutique.tld/llms.txt
curl -I https://votre-boutique.tld/llms-full.txt
curl -I https://votre-boutique.tld/robots-ai.txt
```
Chaque sales-channel expose ses propres fichiers sur son propre domaine, dans chaque langue active (les URL localisées suivent la configuration de domaine du canal).
## Champs personnalisés AEO
Le set `datafirefly_aeo` est disponible sur les **produits, catégories, pages CMS et fabricants**, dans l'onglet Champs personnalisés de chaque entité.
ChampTypeUsage`datafirefly_aeo_summary`TexteRésumé 1-2 phrases utilisé dans le llms.txt à la place de la description tronquée`datafirefly_aeo_faq`JSONFAQ structurée, injectée en FAQPage JSON-LD`datafirefly_aeo_howto`JSONTutoriel structuré, injecté en HowTo JSON-LD`datafirefly_aeo_speakable`TexteTexte court pour assistants vocaux (30-40 mots énonçables)`datafirefly_aeo_exclude`BooléenExclut l'entité du llms.txt et du llms-full.txt
### Format du champ FAQ
```
[
{
"q": "Combien de temps dure la livraison ?",
"a": "La livraison standard prend 2 à 4 jours ouvrés en France métropolitaine."
},
{
"q": "Quelle est votre politique de retour ?",
"a": "Vous disposez de 30 jours pour retourner un produit non utilisé."
}
]
```
### Format du champ HowTo
```
{
"name": "Comment installer le produit",
"totalTime": "PT15M",
"steps": [
{ "name": "Préparation", "text": "Déballez les composants." },
{ "name": "Montage", "text": "Suivez le schéma fourni." },
{ "name": "Vérification", "text": "Testez le fonctionnement." }
]
}
```
Les champs personnalisés Shopware sont traduisibles : renseignez la FAQ dans chaque langue via le sélecteur de langue de la fiche produit. Le plugin lit la valeur dans la langue du contexte de la requête.
## Données structurées Schema.org
Le plugin injecte du JSON-LD dans le `` via le template `storefront/layout/meta.html.twig` (héritage Twig, compatible thèmes personnalisés). Schémas générés :
- **Organization** — sur toutes les pages : nom, logo, URL, `contactPoint`, `sameAs` (profils sociaux).
- **Product enrichi** — sur les fiches produit : `gtin13` (depuis l'EAN), `mpn`, `sku`, `brand` (fabricant), `additionalProperty` (caractéristiques groupées par groupe de propriétés), `aggregateRating` (depuis les avis natifs Shopware si présents).
- **BreadcrumbList** — fil d'Ariane complet de la page courante.
- **FAQPage** — si le champ `datafirefly_aeo_faq` est renseigné sur l'entité de la page.
- **HowTo** — si le champ `datafirefly_aeo_howto` est renseigné.
- **Speakable** — sélecteurs CSS `h1`, `.product-detail-name`, `.product-detail-description-text`, `.cms-element-text`, `[data-speakable]`, plus le texte du champ dédié.
Validation recommandée après mise en production :
- [Schema.org Validator](https://validator.schema.org/) — coller l'URL d'une fiche produit.
- [Google Rich Results Test](https://search.google.com/test/rich-results).
## Module d'administration
Sous **Marketing → DataFirefly llms.txt & AEO** :
- **Prévisualisation en direct** du llms.txt ou du llms-full.txt, avec rendu monospace.
- **Sélecteur de sales-channel** — prévisualisez chaque canal indépendamment.
- **Invalidation du cache** en un clic (par canal ou globale).
- **Ouverture de l'URL publique** et **copie dans le presse-papier**.
## Commandes CLI et automatisation
### datafirefly:llms-txt:generate
```
# Générer le llms.txt d'un sales-channel (affiché en sortie standard)
bin/console datafirefly:llms-txt:generate --sales-channel=
# Version complète, écrite dans un fichier, sans passer par le cache
bin/console datafirefly:llms-txt:generate --sales-channel= --full --output=/tmp/llms-full.txt --no-cache
```
### datafirefly:llms-txt:warm
```
# Réchauffer le cache de tous les sales-channels x toutes les langues actives
bin/console datafirefly:llms-txt:warm
# Forcer la régénération même si le cache est encore valide
bin/console datafirefly:llms-txt:warm --force
# Ne réchauffer que le llms.txt (sans le llms-full.txt)
bin/console datafirefly:llms-txt:warm --skip-full
```
### Cron recommandé
```
# Réchauffement quotidien à 03h15
15 3 * * * cd /var/www/shopware && php bin/console datafirefly:llms-txt:warm --quiet
```
Une **tâche planifiée Shopware** est également enregistrée à l'activation : si votre worker Messenger et le scheduled task runner tournent, le cache se réchauffe automatiquement sans cron système.
## Intégration robots.txt
Deux approches pour exposer les directives IA dans votre robots.txt principal :
### Copie manuelle
Ouvrez `/robots-ai.txt`, copiez le bloc généré et collez-le dans votre robots.txt existant. À refaire après chaque changement de configuration des bots.
### Réécriture serveur (recommandé si robots.txt entièrement géré par le plugin)
```
# nginx
location = /robots.txt {
rewrite ^ /robots-ai.txt last;
}
# Apache (.htaccess)
RewriteRule ^robots.txt$ /robots-ai.txt [L]
```
N'utilisez la réécriture complète que si vous n'avez pas d'autres directives robots.txt à préserver (sitemap, exclusions SEO existantes). Dans le doute, préférez la copie manuelle du bloc IA.
## Cache et performances
- Cache **PSR-6** sur le pool `cache.object` de Shopware, tagué `datafirefly_llms_aeo`.
- Clés scopées par **sales-channel + langue** : chaque combinaison a sa propre entrée.
- TTL configurable (défaut 3600 s).
- Invalidation : bouton admin (par canal ou globale), commande `warm --force`, ou expiration naturelle.
- Compatible cache clusterisé (Redis) : l'invalidation par tags fonctionne sur tous les adaptateurs taggables.
## Dépannage
### Les endpoints renvoient 404
1. Vérifiez que le plugin est bien **activé** (pas seulement installé).
2. Videz le cache HTTP et le cache d'application : `bin/console cache:clear`.
3. Si vous utilisez un reverse proxy/CDN, purgez-le également.
### Erreur « Attempted to call an undefined method named getHeader » sur les pages de navigation
Bug corrigé en **version 1.0.1** : sur certaines installations Shopware 6.7, `NavigationPage` n'expose pas `getHeader()`. Mettez à jour vers la 1.0.1 (extraction défensive de la catégorie active). Si vous êtes déjà en 1.0.1 et voyez encore l'erreur, videz le cache d'opcode PHP (`opcache_reset` ou redémarrage PHP-FPM).
### Le module admin n'apparaît pas sous Marketing
Compilez les assets d'administration (voir [Installation](#installation-assets)) puis forcez le rechargement du navigateur (Ctrl+Maj+R).
### Le llms.txt est vide ou incomplet
1. Vérifiez les toggles d'inclusion (pages CMS / catégories / marques / produits) dans la carte « llms.txt ».
2. Vérifiez que la limite de produits n'est pas à 0.
3. Contrôlez le champ `datafirefly_aeo_exclude` sur les entités absentes.
4. Invalidez le cache puis rechargez.
### Le JSON-LD n'apparaît pas dans le code source
1. Vérifiez que « Activer le module » et les toggles Schema.org sont actifs pour le bon sales-channel.
2. Si votre thème surcharge `storefront/layout/meta.html.twig` sans `{{ parent() }}` sur le block concerné, l'injection est perdue : rétablissez l'appel parent.
## Changelog
### 1.0.1 — 2026-05-21
- Correctif : extraction défensive de la catégorie active sur les pages de navigation (erreur `getHeader()` sur certaines installations 6.7).
### 1.0.0 — 2026-05-21
- Version initiale : llms.txt + llms-full.txt, 6 schémas JSON-LD, robots-ai.txt (9 bots), champs personnalisés AEO, module admin Vue 3, 2 commandes CLI, tâche planifiée, snippets FR/EN/DE.
---
## Hubs d'expertise
### AEO & llms.txt e-commerce
_Source :_
> AEO e-commerce : llms.txt multi-langue, JSON-LD enrichi, robots.txt crawlers IA, contenu answer-engine. Visibilité ChatGPT, Perplexity, Gemini, Claude. À partir de 1 800 €.
Pour avancer en autonomie avant de nous confier le chantier : nos sélections de modules pour être visible dans ChatGPT [sur PrestaShop](https://www.datafirefly.com/solutions/prestashop/referencement-ia-aeo/) et [sur WooCommerce](https://www.datafirefly.com/solutions/wordpress/referencement-ia-aeo/), l'article [comprendre l'AEO](https://www.datafirefly.com/2026/05/01/aeo-answer-engine-optimization-avenir-seo/) et [l'AEO appliqué à PrestaShop 8](https://www.datafirefly.com/2026/05/21/aeo-2026-optimiser-prestashop-8-chatgpt-perplexity-google-ai-overviews/).
---
### Agence e-commerce
_Source :_
> Agence e-commerce spécialisée PrestaShop, WordPress / WooCommerce et Shopware — du cadrage à la maintenance, en équipe restreinte.
On est une agence de développement e-commerce, mais sans le côté _agence_ qui pèse. Pas de chargé de compte qui fait l'intermédiaire, pas de slides à n'en plus finir : vous parlez directement aux développeurs qui font le travail.
## Trois plateformes, une équipe
PrestaShop, WordPress / WooCommerce et Shopware. On ne fait pas Magento, Salesforce Commerce ni Shopify — pas par snobisme, juste parce qu'on préfère être très bons sur trois plateformes que moyens sur dix.
## Comment on travaille
Engagement chiffré sur scope précis (pas de TJM open-bar), livraison régulière en sprints courts, code propre et documenté, et on reste joignables après la livraison. Si vous cherchez une agence "premium" avec brand strategy et workshops UX, ce n'est pas nous. Si vous cherchez une équipe technique solide qui livre, on est là.
---
### Audit PrestaShop
_Source :_
> Audit complet de boutique PrestaShop — code, sécurité, performance, SEO. Rapport détaillé et plan d'action chiffré sous 5 jours.
Vous avez repris une boutique PrestaShop existante, ou vous suspectez que quelque chose ne va pas (perf, sécurité, modules dans tous les sens), et vous voulez un avis extérieur. C'est exactement ce qu'on fait avec l'audit PrestaShop.
## Ce qui est analysé
Code (modules tiers et surcharges), sécurité (CVE connues, hardening, dépendances), performance (Core Web Vitals, requêtes SQL, cache, assets), SEO technique (sitemap, hreflang, JSON-LD, redirections), et la dette d'infrastructure (PHP, MySQL, serveur, CDN).
## Livrable
Un rapport PDF d'une vingtaine de pages avec : constat par catégorie, gravité, captures d'écran et extraits de code, plan d'action priorisé, et chiffrage des correctifs (en jours-homme et en euros). Vous pouvez ensuite faire faire les correctifs par votre équipe ou par nous, c'est vous qui voyez.
---
### Audit Shopware
_Source :_
> Audit complet d'instance Shopware 6 — code, plugins Store et custom, performance cache, sécurité, configuration. Rapport et plan d'action chiffré sous 5 jours. À partir de 2 200 €.
---
### Audit WooCommerce
_Source :_
> Audit complet de boutique WooCommerce — code, plugins, performance, sécurité, HPOS, SEO. Rapport détaillé et plan d'action chiffré sous 5 jours. À partir de 1 800 €.
---
### Automatisation et IA Shopify
_Source :_
> Automatisation et IA pour Shopify — Shopify Flow, génération de fiches produit IA, agent service client (RAG), synchronisation back-office, merchandising et AEO. OpenAI, Mistral, Claude. À partir de 2 000 €.
## Automatiser ce qui est répétitif, ajouter l'IA là où elle rapporte
Sur Shopify, beaucoup de temps part en tâches manuelles : rédaction de fiches produit, tri des collections, synchronisation de stock, réponses au support, taggage des commandes. On automatise ces tâches avec Shopify Flow et l'API, et on branche l'IA (OpenAI, Mistral, Claude) uniquement là où elle a un vrai retour sur investissement — pas du gadget.
## Ce qu'on met en place
- **Automatisations Shopify Flow** : workflows sur commandes, stock, clients, fraude, tags, notifications.
- **Fiches produit IA** : génération et optimisation en masse, traductions multilingues, meta et textes alternatifs.
- **Agent IA service client** : connecté à votre catalogue et à vos commandes, réponses sourcées, escalade humaine.
- **Synchronisation back-office** : ERP, PIM, 3PL — mises à jour stock/prix, déduplication, jobs planifiés.
- **Merchandising & visibilité IA** : tri intelligent des collections, recommandations, AEO et llms.txt pour être cité par les moteurs de réponse.
## Pourquoi nous
Plus de dix ans d'e-commerce, une vraie pratique de l'IA en production (RAG, génération de contenu, agents) et la rigueur du code propre. On vous livre les automatisations documentées, mesurables et maintenables — sources à vous.
---
### Connecteur Cegid PrestaShop
_Source :_
> Connecteur Cegid PrestaShop sur mesure : Cegid Retail Y2, Quadra, Business, XRP Flex. Synchro catalogue, stocks multi-magasin, click & collect, commandes, factures. Devis 24h, livraison 4-6 sem. À partir de 6 000 €.
Pour avancer en autonomie avant de nous confier le chantier : notre sélection de [modules pour connecter votre ERP et votre CRM](https://www.datafirefly.com/solutions/prestashop/connecteurs-erp-crm/) et celle pour [gérer votre catalogue en masse](https://www.datafirefly.com/solutions/prestashop/gestion-catalogue/).
---
### Connecteur Cegid WooCommerce
_Source :_
> Connecteur Cegid WooCommerce sur mesure, compatible HPOS : Cegid Retail Y2, Quadra, Business, XRP Flex. Synchro catalogue, stocks multi-magasin, click & collect, commandes via Action Scheduler. À partir de 6 000 €.
---
### Connecteur Sage PrestaShop
_Source :_
> Connecteur Sage PrestaShop sur mesure : synchro produits, stocks, clients, commandes, factures. Compatible Sage 100c, 50c, X3, 1000. Devis ferme, livraison en 4-6 semaines. À partir de 6 000 €.
Pour avancer en autonomie avant de nous confier le chantier : notre sélection de [modules pour connecter votre ERP et votre CRM](https://www.datafirefly.com/solutions/prestashop/connecteurs-erp-crm/) et celle pour [gérer votre catalogue en masse](https://www.datafirefly.com/solutions/prestashop/gestion-catalogue/).
---
### Connecteur Sage WooCommerce
_Source :_
> Connecteur Sage WooCommerce sur mesure, compatible HPOS : synchro produits, stocks, clients, commandes, factures via Action Scheduler. Sage 100c, 50c, X3. Devis 24h, livraison 4-6 sem. À partir de 6 000 €.
---
### Création de site PrestaShop
_Source :_
> Création de boutique PrestaShop 8/9 sur mesure — du cadrage à la mise en production, avec un code propre, performant et maintenable. À partir de 8 000 €.
Vous lancez une boutique en ligne et vous voulez partir sur PrestaShop, sans tomber sur un thème acheté 60 € bricolé par-dessus. On construit des boutiques PrestaShop complètes : architecture propre, performance soignée dès le premier jour, et un code qu'un autre développeur pourra reprendre sans jurer.
## Ce qu'on construit
Boutique PrestaShop 8 ou 9 de A à Z : arborescence catalogue, fiches produit, tunnel de commande optimisé, moyens de paiement et de livraison, multi-langue et multi-devise si besoin, et tous les modules métier nécessaires (B2B, RGPD, SEO, ERP). Le thème est intégré proprement, sans override sauvage qui casse à la prochaine mise à jour.
## Pourquoi PrestaShop
Pas de commission sur vos ventes, pas de dépendance à un éditeur SaaS, un contrôle total sur le code et les données. PrestaShop est taillé pour les catalogues riches et les besoins métier spécifiques. En contrepartie il faut quelqu'un qui maîtrise la plateforme — c'est précisément ce qu'on fait depuis plus de 10 ans.
## Performance et SEO dès le départ
Core Web Vitals dans le vert, structure d'URL propre, données structurées, balises hreflang en multi-langue. On ne livre pas une boutique rapide qu'il faudra « optimiser plus tard » : la performance est cadrée dès la conception.
Vous voulez un chiffrage avant de vous lancer ?
[Obtenir un devis site PrestaShop →](https://www.datafirefly.com/devis-site-prestashop/)
---
### Création de site Shopify
_Source :_
> Création de boutique Shopify sur mesure — thème personnalisé ou headless Hydrogen, catalogue, paiement et performance, sans empiler les apps. À partir de 4 000 €.
Vous voulez lancer vite, sans gérer d'hébergement ni de mises à jour serveur : Shopify est fait pour ça. On construit des boutiques Shopify propres — thème personnalisé ou sur mesure, pas un template générique installé à la va-vite et bourré d'apps payantes qui plombent la marge et la performance.
## Ce qu'on construit
Boutique Shopify de A à Z : thème personnalisé (Online Store 2.0) ou développement headless (Hydrogen), catalogue et collections, tunnel de commande, paiement et livraison, et les sections sur mesure qui font la différence. On code en Liquid proprement et on limite les apps au strict nécessaire.
## Pourquoi Shopify
Mise en ligne rapide, hébergement et sécurité gérés, fiabilité du checkout, écosystème d'apps mûr. C'est le bon choix pour démarrer vite ou pour une marque qui ne veut pas gérer d'infrastructure. Les limites à connaître : abonnement mensuel, commission selon la passerelle de paiement, et un thème vite illisible si on empile les apps — c'est là qu'un dev propre change tout.
## Performance et SEO dès le départ
Thème léger, Liquid optimisé, apps maîtrisées, Core Web Vitals dans le vert. Shopify peut être très rapide quand le thème est bien codé. On cadre la performance et le SEO dès la conception, pas en rustine.
## Vous migrez depuis Shopify ?
Si à l'inverse vous voulez quitter Shopify pour reprendre la main sur le code et supprimer les commissions, on gère aussi la migration vers WooCommerce ou PrestaShop, catalogue et clients compris.
---
### Création de site Shopware
_Source :_
> Création de boutique Shopware 6 sur mesure — catalogue, B2B natif, multi-canal et performance, du cadrage à la mise en production. À partir de 12 000 €.
Vous montez un projet e-commerce ambitieux et vous regardez du côté de Shopware. Bon réflexe : c'est la plateforme open source la plus solide pour le B2B, les gros catalogues et les besoins complexes en Europe. Mais Shopware demande de vrais développeurs — pas un intégrateur qui découvre le système d'admin sur votre budget. On construit des boutiques Shopware 6 complètes, propres et taillées pour l'échelle.
## Ce qu'on construit
Boutique Shopware 6.6 / 6.7 de A à Z : Shopping Experiences, catalogue et règles produit, tunnel de commande, paiement et livraison, B2B (offres, listes de prix, comptes entreprise), multi-langue et multi-canal. Plugins sur mesure quand le standard ne suffit pas, connecteurs ERP, et thème Storefront propre.
## Pourquoi Shopware
Architecture moderne (Symfony, API-first, Vue.js côté admin), B2B natif puissant, multi-canal et headless prêts à l'emploi. C'est le choix pertinent quand vous quittez Magento ou que vous visez un projet d'envergure. La contrepartie est le ticket d'entrée technique — et c'est exactement notre terrain.
## Performance et SEO dès le départ
Cache HTTP, ESI, Core Web Vitals soignés, structure d'URL et hreflang propres en multi-langue. Shopware est rapide quand l'architecture est bien posée. On cadre la performance dès la conception, pas en correctif tardif.
---
### Création de site WordPress / WooCommerce
_Source :_
> Création de site WordPress / WooCommerce sur mesure — boutique + contenu sur un socle propre, rapide et maintenable, sans empilement de plugins. À partir de 6 000 €.
Vous voulez un site e-commerce sur WordPress, en WooCommerce. C'est un excellent choix quand on veut coupler boutique et contenu (blog, SEO, pages éditoriales) sur le même socle. Encore faut-il l'installer proprement : un WooCommerce mal monté, surchargé de plugins qui se marchent dessus, finit lent et ingérable. On construit des boutiques WooCommerce propres, rapides et durables.
## Ce qu'on construit
Site WordPress complet avec boutique WooCommerce : catalogue, fiches produit, panier et tunnel de commande optimisés, paiement et livraison, comptes clients, et toute la partie éditoriale (pages, blog, landing pages SEO). On choisit les extensions avec parcimonie et on code sur mesure ce qui doit l'être, plutôt que d'empiler 30 plugins.
## Pourquoi WooCommerce
Open source, pas de commission sur les ventes, un écosystème énorme, et la force de WordPress pour le contenu et le SEO. C'est la plateforme idéale quand votre stratégie repose autant sur le contenu que sur la vente. Le revers : sans rigueur technique, ça devient vite une usine à gaz — c'est là qu'on intervient.
## Performance et SEO dès le départ
HPOS activé, base de données saine, hébergement adapté, Core Web Vitals dans le vert. WordPress et WooCommerce peuvent être très rapides quand c'est bien fait. On cadre la performance et le SEO technique dès la conception, pas en rustine après coup.
---
### Développeur d'app Shopify
_Source :_
> Développement d'apps Shopify sur mesure — app custom (single-merchant) ou publique (App Store), Shopify Functions, Checkout Extensibility, intégrations GraphQL Admin API. Remix, Polaris. À partir de 4 000 €.
## Des apps Shopify codées proprement, pas bricolées
Shopify ne se personnalise pas comme PrestaShop ou WooCommerce : pas de surcharge directe du cœur, tout passe par des apps et des extensions encadrées par l'API. On développe vos apps Shopify dans les règles de la plateforme — app custom dédiée à votre boutique, ou app publique destinée à l'App Store — avec un code maintenable que vous gardez.
## Ce qu'on développe
- **App custom** pour un seul marchand : automatisations, tableaux de bord admin, intégrations métier, sans passer par le App Store.
- **App publique** : conception, billing, onboarding, listing et validation jusqu'au label Built for Shopify.
- **Shopify Functions** : remises, personnalisation du checkout, règles de livraison et de paiement exécutées côté serveur.
- **Checkout Extensibility** : migration des anciens scripts checkout.liquid vers les Checkout UI Extensions React.
- **Intégrations** : ERP, CRM, PIM, marketing — via la GraphQL Admin API, les webhooks et les bulk operations.
## Pourquoi nous
Plus de dix ans sur l'e-commerce, une vraie culture du code propre et testé, et une habitude des contraintes de plateforme (PrestaShop, WooCommerce, Shopware, Shopify). On vous livre les sources, la documentation et un accompagnement après mise en ligne.
---
### Développeur d'extension WooCommerce
_Source :_
> Création d'extensions WooCommerce sur mesure — paiement, shipping, B2B, abonnements. Compatible HPOS, livraison sous 2 à 4 semaines.
WooCommerce a son propre écosystème d'extensions. La plupart des fonctionnalités existent déjà dans le marketplace officiel ou ailleurs — mais quand ça ne colle pas exactement à votre métier, on développe l'extension qui manque.
## Extension WooCommerce sur mesure
On part du besoin métier (et pas d'un canevas générique), on chiffre fermement, on développe en compatibilité HPOS, on teste avec WooCommerce 9+, et on livre. Le code est conforme aux standards WC, hooks documentés, prêt pour publication marketplace si vous le souhaitez.
---
### Développeur de module PrestaShop
_Source :_
> Conception, développement et maintenance de modules PrestaShop 8 sur mesure — devis ferme, livraison sous 2 à 4 semaines.
Le catalogue de modules PrestaShop est immense, mais il y a toujours _ce_ module qui manque : celui qui colle exactement à votre métier, votre flux, vos clients. C'est ce qu'on fait.
## Le module exact qu'il vous manque
On part de votre besoin (et pas d'un canevas générique), on rédige un périmètre fonctionnel clair, on chiffre fermement, on développe, on teste sur votre environnement de recette, et on livre. Pas de feature creep, pas de devis qui dérive.
## Ce qu'on a déjà fait
Connecteurs ERP (Sage 100, Cegid, Sellsy), passerelles de paiement, modules de pricing B2B (tiered, devis, paliers de quantité), gestion d'abonnements Stripe, RGPD complet, modules SEO (sitemap, JSON-LD, gestion canonique), bandeaux promotionnels conditionnels, modules de retours produit avec QR scan, etc.
---
### Développeur de plugin Shopware
_Source :_
> Plugins Shopware 6 sur mesure — Storefront, Admin, custom entities, intégrations API. Compatible 6.5 / 6.6 / 6.7.
Le store Shopware compte des milliers de plugins, mais beaucoup sont obsolètes ou mal maintenus. Quand vous avez besoin d'un plugin spécifique à votre métier — ou quand un plugin existant ne fait pas exactement ce qu'il faut — on développe le plugin manquant.
## Plugin Shopware sur mesure
On part du besoin, on rédige le périmètre fonctionnel, on chiffre fermement, on développe en respectant les bonnes pratiques Shopware (services Symfony, Twig, ESI, custom entities, migrations DAL), on teste sur 6.5, 6.6 et 6.7, et on livre.
---
### Développeur de plugin WordPress
_Source :_
> Création de plugins WordPress sur mesure — code testé, hooks documentés, livraison avec ZIP installable et 12 mois de maintenance.
Un plugin WordPress, c'est facile à mal coder. Hooks au mauvais endroit, requêtes non préparées, options non sanitizées, désactivation propre négligée. On fait l'inverse : un plugin propre, testé, qui ne casse pas votre site et qui survit aux mises à jour de WordPress.
## Plugin sur mesure de A à Z
On part de votre brief, on rédige le périmètre fonctionnel, on chiffre fermement, on développe avec tests PHPUnit pour la logique critique, on documente les hooks pour qu'un autre dev puisse étendre, et on livre un ZIP installable + le code source + la documentation.
---
### Développeur PrestaShop
_Source :_
> Développement, audit et optimisation de boutiques PrestaShop 8 — par une équipe qui livre du code propre, testé et maintenu.
Vous tenez une boutique PrestaShop et vous avez besoin d'aide d'un développeur qui connaît la plateforme à fond. Pas un freelance qui découvre PrestaShop sur votre projet : on développe, on optimise et on maintient des boutiques PrestaShop depuis plus de 10 ans.
## Ce qu'on fait sur PrestaShop
Modules sur mesure (paiement, B2B, ERP, RGPD, SEO), surcharge de thème, optimisation Core Web Vitals, audit de sécurité et migration 1.7 → 8. Le code est propre, conforme aux standards PrestaShop, et systématiquement testé en multi-boutique avant livraison.
## Pourquoi nous
Trois choses : on code uniquement sur PrestaShop (pas de dispersion), on livre à prix fixe sous délai engageant, et on inclut 12 mois de mises à jour de compatibilité. Si PrestaShop sort une 8.2 demain, votre module suit sans surcoût.
---
### Développeur Shopware
_Source :_
> Plugins Shopware 6, intégrations Storefront / Admin SDK, migration 6.5 → 6.6 / 6.7, optimisation perf catégories.
Shopware 6 est une plateforme moderne, mais aussi exigeante : Symfony, Twig, Vue.js, Vite, Storefront SDK, Admin SDK. Beaucoup de freelances WordPress ou PrestaShop s'y cassent les dents. On code Shopware 6 depuis sa sortie en 2019.
## Plugins, performance, migrations
On développe des plugins Shopware 6 (Storefront, Admin, modèles de données custom), on optimise les pages catégorie qui ralentissent (un grand classique), on migre les boutiques de 6.5 à 6.6 / 6.7, et on intègre des APIs tierces avec respect du contexte de cache HTTP.
---
### Développeur WooCommerce
_Source :_
> Boutiques WooCommerce — extensions sur mesure, optimisation perf, intégration ERP, mise en place HPOS et Stripe / PayPal.
WooCommerce, ce n'est pas juste un plugin WordPress. C'est un système e-commerce complet qui demande une vraie expertise pour tenir la charge, intégrer un ERP, gérer le multi-boutique, et garder de bonnes Core Web Vitals quand le catalogue grossit.
## Ce qu'on fait sur WooCommerce
Extensions sur mesure (paiement, shipping, B2B, abonnements), migration vers HPOS (High-Performance Order Storage), intégration ERP / 3PL, optimisation perf catalogue, audit sécurité PCI-DSS, et reprise de boutiques laissées en mauvais état.
---
### Développeur WordPress
_Source :_
> Plugins, thèmes et intégrations WordPress sur mesure, par une équipe qui code propre et qui maintient son travail dans le temps.
WordPress fait tourner 40 % du web et 95 % des plugins du dépôt sont… perfectibles. Quand vous avez besoin que ça marche vraiment, sans ralentir le site et sans casser au prochain update, on est là pour ça.
## Plugins, thèmes, intégrations
On développe des plugins WordPress sur mesure, on construit des thèmes Gutenberg / FSE, on intègre des APIs tierces (CRM, ERP, marketing, paiement), et on remet d'aplomb les sites WordPress dont les performances ou la sécurité ne suivent plus.
## Code, perf, sécurité
WP_Query optimisées, transients quand il faut, hooks documentés, code conforme PSR-12 + WordPress Coding Standards, tests PHPUnit pour la logique critique. La sécurité (nonce, escaping, capabilities) est intégrée par défaut, pas ajoutée à la fin.
---
### Headless WooCommerce
_Source :_
> Boutique headless WooCommerce sur mesure : frontend Next.js / Astro / Remix + backend WC. WC REST API ou GraphQL, ISR, edge deployment, auth + checkout custom, multi-canal mobile. À partir de 18 000 €.
---
### Maintenance PrestaShop
_Source :_
> Maintenance PrestaShop : mises à jour, patches sécurité, monitoring, bugfix, hotline française, reporting mensuel. Forfait mensuel sans surprise. À partir de 290 €/mois.
Pour avancer en autonomie avant de nous confier le chantier : notre sélection de [modules pour sécuriser votre boutique](https://www.datafirefly.com/solutions/prestashop/securite-protection/) et celle pour [l'accélérer](https://www.datafirefly.com/solutions/prestashop/performance-vitesse/).
---
### Maintenance Shopware
_Source :_
> Maintenance Shopware 6 : mises à jour core / plugins Store, patches sécurité, monitoring cache + Messenger queue, bugfix, hotline FR / EN, reporting mensuel. À partir de 490 €/mois.
---
### Maintenance WooCommerce
_Source :_
> Maintenance WooCommerce : mises à jour core / plugins, patches sécurité, monitoring Action Scheduler, bugfix, HPOS, hotline française, reporting mensuel. À partir de 290 €/mois.
---
### Migration Magento vers Shopware
_Source :_
> Migration Magento ou Adobe Commerce vers Shopware 6.7 : audit, mapping data, réécriture des modules custom, redirections SEO. Bascule en fenêtre courte, sans perte de commandes ni de positions.
---
### Migration PrestaShop 8 vers 9
_Source :_
> Migration PrestaShop 8 vers 9 par des développeurs PrestaShop : audit gratuit, devis fixe sous 24h, migration sur staging avant la prod. Livraison sous 8 jours, 0 perte de données ni de SEO.
Pour avancer en autonomie avant de nous confier le chantier : notre sélection de [modules pour migrer vers PrestaShop](https://www.datafirefly.com/solutions/prestashop/migration-prestashop/), l'article [PrestaShop 9 vs PrestaShop 8](https://www.datafirefly.com/2026/05/01/prestashop-9-vs-prestashop-8-changements/) et la [checklist migration PrestaShop 1.7 vers 8](https://www.datafirefly.com/2026/06/10/migration-prestashop-1-7-vers-8-checklist-2026/).
---
### Migration Shopify vers WooCommerce
_Source :_
> Migration Shopify vers WooCommerce : reprise des produits, clients, commandes, abonnements actifs. Plan SEO complet, redirections 301, bascule en fenêtre courte. À partir de 4 500 €.
---
### Optimisation Core Web Vitals PrestaShop
_Source :_
> Optimisation Core Web Vitals PrestaShop : audit perf, plan d'action chiffré, correctifs LCP / INP / CLS / TTFB. Scores en "good" en 2-4 semaines. À partir de 2 500 €.
Pour avancer en autonomie avant de nous confier le chantier : notre sélection de [modules pour accélérer votre boutique PrestaShop](https://www.datafirefly.com/solutions/prestashop/performance-vitesse/), le [guide complet Core Web Vitals](https://www.datafirefly.com/2026/05/01/core-web-vitals-guide-prestashop-wordpress-2026/) et la [checklist technique LCP, INP, CLS](https://www.datafirefly.com/2026/05/09/performance-prestashop-8-checklist-core-web-vitals-2026-lcp-inp-cls/).
---
### Optimisation Core Web Vitals WooCommerce
_Source :_
> Optimisation Core Web Vitals WooCommerce : audit perf, plan d'action chiffré, correctifs LCP / INP / CLS / TTFB / HPOS / Action Scheduler. Scores en "good" en 2-4 semaines. À partir de 2 500 €.
Pour avancer en autonomie avant de nous confier le chantier : notre sélection de [plugins pour accélérer votre boutique WooCommerce](https://www.datafirefly.com/solutions/wordpress/performance-vitesse/) et le [guide complet Core Web Vitals](https://www.datafirefly.com/2026/05/01/core-web-vitals-guide-prestashop-wordpress-2026/).
---
### PrestaShop B2B
_Source :_
> Boutique B2B sur PrestaShop sur mesure : prix par client, devis, comptes entreprise avec sous-utilisateurs, paiement à terme, TVA intra-communautaire, ERP intégré (Sage, Cegid). À partir de 12 000 €.
Pour avancer en autonomie avant de nous confier le chantier : notre sélection de [modules PrestaShop pour vendre en B2B](https://www.datafirefly.com/solutions/prestashop/vente-b2b/) et celle dédiée à la [facturation et au recouvrement B2B](https://www.datafirefly.com/solutions/prestashop/facturation-recouvrement-b2b/).
---
### PrestaShop vs Shopify
_Source :_
> PrestaShop vs Shopify : comparatif honnête sur votre cas précis. TCO 3 ans, SEO, contrôle, scalabilité, ops quotidiennes. Recommandation argumentée. Audit conseil de 590 €.
---
### Shopware B2B
_Source :_
> Build B2B sur Shopware 6.7 sur mesure : B2B Suite officielle ou plugins custom, sous-utilisateurs, prix client, devis, paiement à terme, TVA intra, ERP Sage / Cegid intégré. À partir de 15 000 €.
Pour avancer en autonomie avant de nous confier le chantier : notre sélection de [plugins Shopware pour la vente B2B](https://www.datafirefly.com/solutions/shopware/vente-b2b/) et celle dédiée à la [facture électronique](https://www.datafirefly.com/solutions/shopware/facturation-conforme/).
---
### Shopware vs Magento
_Source :_
> Shopware vs Magento : comparatif honnête sur votre cas ETI / B2B. TCO 3 ans, recrutement, B2B Suite, scalabilité, avenir. Recommandation argumentée. Audit conseil de 1 200 €.
---
### WooCommerce abonnements
_Source :_
> Boutique abonnement WooCommerce sur mesure : WC Subscriptions ou Stripe direct custom, dunning, customer portal, proration upgrade/downgrade, métriques MRR. À partir de 6 000 €.
---
### WooCommerce vs Shopify
_Source :_
> WooCommerce vs Shopify : comparatif honnête sur votre cas. TCO 3 ans, SEO content, blog intégré, contrôle, scalabilité. Recommandation argumentée. Audit conseil de 590 €.
---
## Hubs Solutions
### Nos meilleurs modules IA PrestaShop pour aider vos clients à choisir
_Source :_
> Conseiller de taille IA, essayage virtuel, recherche visuelle, synthèse IA des avis et personnalisation par segment : la sélection pour supprimer le doute sur PrestaShop 8 & 9 — pas pour persuader.
## Le client ne part pas à cause du prix — il part à cause du doute
On croit qu'il est parti parce que c'était trop cher. La plupart du temps, il est parti parce qu'il **n'était pas sûr**. Pas sûr de la taille. Pas sûr que ça lui aille. Pas sûr que ça ressemble à la photo.
Et ce doute a un prix mesurable : soit il n'achète pas — soit il achète et il retourne. Les deux vous coûtent.
## L'IA ne vend pas — elle supprime le doute
C'est le seul critère qui compte. Un module d'IA qui _persuade_ le client est un module qui génère des retours. Un module d'IA qui l'aide à choisir _correctement_ augmente la conversion et fait baisser les retours en même temps.
C'est pour ça que le conseiller de taille est en premier sur cette page, et pas l'essayage virtuel : il est moins spectaculaire et il bouge les deux métriques à la fois.
## La seule question avant d'acheter
Quel doute retient réellement votre client au moment de cliquer sur « Acheter » ? Vos motifs de retour y répondent. Installez le module qui supprime _ce_ doute-là — pas celui qui est le plus joli.
---
### Nos meilleurs modules PrestaShop pour accélérer votre boutique
_Source :_
> Optimisation d'images WebP et AVIF, mesure réelle des Core Web Vitals et purge automatique du cache : la sélection pour accélérer votre boutique PrestaShop 8 & 9 — pour la conversion, pas pour le score.
## La vitesse n'est pas un sujet SEO — c'est un sujet de conversion
On vous vend la performance comme un facteur de classement. C'en est un — mais un facteur _faible_. Une boutique lente au contenu excellent dépasse régulièrement une boutique ultra-rapide qui n'a rien à dire.
Là où la vitesse décide vraiment, c'est **dans le panier de votre client**. Un visiteur qui attend une page n'attend pas : il part. Et il ne vous le dira pas — il n'apparaîtra simplement jamais dans vos chiffres.
## Le coupable est presque toujours le même
Pas votre hébergement. Pas PrestaShop. **Vos images.** Sur une page e-commerce typique, les images représentent de très loin la plus grosse part du poids — et la plupart des boutiques les servent en JPEG de 2010, en pleine résolution, sans lazy loading.
## Et on n'optimise pas ce qu'on ne mesure pas
Un score dans un outil de test est une mesure de laboratoire. Ce qui compte, ce sont les chiffres _réels_ de vos vrais visiteurs, sur leurs vrais appareils, sur leur vrai réseau. Le reste est de la décoration.
## Pour aller plus loin
Trois guides du blog complètent cette sélection : [le guide complet Core Web Vitals](https://www.datafirefly.com/2026/05/01/core-web-vitals-guide-prestashop-wordpress-2026/), [la checklist technique LCP, INP, CLS](https://www.datafirefly.com/2026/05/09/performance-prestashop-8-checklist-core-web-vitals-2026-lcp-inp-cls/) et [cache, Critical CSS et images next-gen](https://www.datafirefly.com/2026/06/15/core-web-vitals-2026-optimiser-prestashop-cache-critical-css-images/).
---
### Nos meilleurs modules PrestaShop pour auditer et piloter votre SEO
_Source :_
> Search Console dans le back-office, rank tracker, détecteur de cannibalisation, contenu pauvre, audit sémantique, topic clusters et SEO prédictif : la sélection complète pour piloter votre SEO sur PrestaShop 8 & 9.
## On n'optimise pas ce qu'on ne mesure pas
La plupart des boutiques font du SEO à l'aveugle. Elles écrivent du contenu, corrigent des balises, attendent — et ne savent jamais si ça a servi. Pas par paresse : parce que les données sont dans la Search Console, dans un rank tracker, dans un tableur, et que personne ne les croise.
Cette sélection les ramène **dans votre back-office, à côté des produits qu'elles concernent**. C'est ça, la vraie différence : pas plus de données, mais des données là où vous agissez.
## Les quatre questions qui comptent
**Où j'en suis ?** Positions, impressions, clics. Sans ligne de base, il n'y a pas de progrès — il n'y a qu'une impression.
**Qu'est-ce qui est cassé ?** La cannibalisation (deux pages qui se disputent la même requête), le contenu pauvre (des pages qui ne disent rien). Deux maladies que personne ne voit, parce qu'elles ne produisent aucun symptôme — elles produisent juste une absence.
**Qu'est-ce qui manque ?** L'audit sémantique et les topic clusters révèlent les trous de votre couverture : les sujets dont vous auriez dû parler et dont vous n'avez pas parlé.
**Où je vais ?** Prévision et veille concurrentielle. La seule partie qui reste spéculative — et qu'il faut traiter comme telle.
## Le piège du tableau de bord
Un outil qui mesure et ne change rien est un outil qui vous rassure pendant que vous stagnez. Chaque métrique ici doit déboucher sur une décision : réécrire cette page, fusionner celles-là, rediriger celle-ci. Si un chiffre ne mène à rien, ne le regardez pas.
## Pour aller plus loin
Trois guides du blog complètent cette sélection : [Indexing API, IndexNow et bots IA](https://www.datafirefly.com/2026/06/07/indexation-2026-google-indexing-api-indexnow-bots-ia-prestashop/), [redirections 301 et monitoring 404](https://www.datafirefly.com/2026/07/04/redirections-301-monitoring-404-changement-slug-seo-prestashop-2026/) et [le guide complet du SEO e-commerce](https://www.datafirefly.com/2026/05/01/seo-ecommerce-guide-complet-2026/).
---
### Nos meilleurs modules PrestaShop pour augmenter votre panier moyen
_Source :_
> Cross-sell intelligent, offres groupées apprises de vos commandes, barre de livraison gratuite, cadeau au seuil, prix dégressifs, emballage cadeau et assurance colis : la sélection complète pour faire monter le panier moyen sur PrestaShop 8 & 9.
## Le levier le moins cher de tous
Augmenter le panier moyen est la seule optimisation qui ne coûte rien en acquisition. Vous avez déjà payé pour faire venir ce visiteur, il a déjà décidé d'acheter : chaque euro supplémentaire qu'il dépense tombe presque intégralement en marge. C'est pour cela qu'un point de panier moyen vaut souvent bien plus qu'un point de taux de conversion.
Mais tous les mécanismes ne se valent pas, et surtout, **ils ne s'appliquent pas au même moment**. Proposer un accessoire à quelqu'un qui n'a pas encore choisi son produit principal, c'est du bruit. Le lui proposer une fois qu'il a mis ce produit au panier, c'est un service.
## Trois familles de leviers
**Les leviers de recommandation** ajoutent des produits : cross-sell, offres groupées, produits complémentaires. Ils fonctionnent d'autant mieux qu'ils sont pertinents — un moteur qui apprend des commandes réelles bat toujours une liste figée d'accessoires.
**Les leviers de seuil** poussent le client à dépenser plus pour débloquer quelque chose : livraison gratuite, cadeau offert, palier de remise. Ils sont d'une efficacité redoutable parce qu'ils transforment une dépense en gain perçu.
**Les leviers d'options** vendent du service plutôt que du produit : emballage cadeau, assurance colis. Marge élevée, aucun stock, zéro logistique supplémentaire.
## La règle qui décide de tout
Un levier de panier moyen ne doit _jamais_ mettre en danger la commande de base. Un pop-up d'upsell qui s'interpose entre le client et le bouton de paiement peut vous coûter plus cher en abandons qu'il ne vous rapporte en additionnel. Le bon réflexe : mesurer la conversion globale, pas seulement le montant du panier.
---
### Nos meilleurs modules PrestaShop pour automatiser votre service client
_Source :_
> Agent IA relié à votre catalogue, helpdesk, WhatsApp, forum communautaire, synthèse IA des avis : la sélection pour désengorger votre SAV sur PrestaShop 8 & 9 — sans remplacer l'humain.
## Votre SAV répond aux mêmes dix questions — depuis des années
« Où est mon colis ? » « Est-ce compatible avec… ? » « Comment je le retourne ? » Triez vos tickets et vous découvrirez qu'une grande partie se ramène à **une poignée de questions identiques**.
Et à chaque fois, un humain répond. Une par une. Comme si c'était la première fois. Ce n'est pas un problème de SAV — **c'est une information placée au mauvais endroit**.
## Automatiser ne veut pas dire remplacer l'humain
La question n'est pas « IA ou humain ». Elle est : _quelles questions méritent un humain ?_ Un humain qui cherche un numéro de suivi pour la quarantième fois perd son temps. Un humain qui récupère un client mécontent sauve une vente.
Un agent IA qui répond correctement aux dix questions les plus fréquentes ne vend pas plus — il rend à votre équipe le temps de s'occuper de celles qui comptent.
## La meilleure réponse est celle qu'on n'a jamais demandée
Avant d'automatiser le SAV, demandez-vous si la question aurait dû naître. Une FAQ produit, une page de suivi, un guide des tailles : ce ne sont pas des outils de SAV, ce sont **des outils qui rendent le SAV inutile**.
---
### Nos meilleurs modules PrestaShop pour booster votre SEO technique
_Source :_
> Redirections 301, SEO tout-en-un, facettes SEO, hreflang, Indexing API, 404 intelligente, robots.txt et Core Web Vitals : la sélection complète pour un SEO technique solide sur PrestaShop 8 & 9.
## Le SEO technique n'est pas de l'optimisation, c'est de l'entretien
Il y a deux SEO. Celui qui crée de la valeur : écrire du contenu, répondre aux questions, construire de l'autorité. Et celui qui empêche la valeur de fuir : s'assurer que Google puisse vous lire, vous comprendre et vous indexer sans friction.
Cette sélection appartient au second. Elle est **moins spectaculaire et plus rentable** — parce qu'aucune quantité de contenu ne sauve une boutique techniquement cassée. Un 404 sur une page qui rankait vous coûte immédiatement. Un hreflang défectueux envoie vos visiteurs allemands sur la page française. Le contenu dupliqué des filtres cannibalise vos propres pages.
## PrestaShop a des pièges structurels
La navigation à facettes génère des URL par milliers, qui montrent toutes la même chose. Les slugs changent quand on renomme un produit, sans qu'aucune redirection ne soit créée. La page 404 par défaut est un cul-de-sac. Le multilingue sans hreflang propre — et c'est Google qui décide seul quelle version de langue afficher.
Aucun de ces pièges n'est insoluble. Tous sont invisibles jusqu'à ce que le trafic chute.
## Ce qu'il faut faire en premier
Les redirections. Avant tout le reste. Chaque 301 que vous oubliez après une migration ou un changement de slug est de l'autorité perdue — et elle ne revient jamais toute seule. Le reste peut attendre. _Ça_, non.
## Pour aller plus loin
Trois guides du blog complètent cette sélection : [redirections 301, monitoring 404 et changements de slug après une migration](https://www.datafirefly.com/2026/07/04/redirections-301-monitoring-404-changement-slug-seo-prestashop-2026/), [l'indexation via Google Indexing API et IndexNow](https://www.datafirefly.com/2026/06/07/indexation-2026-google-indexing-api-indexnow-bots-ia-prestashop/), et [la checklist Core Web Vitals pour PrestaShop 8](https://www.datafirefly.com/2026/05/09/performance-prestashop-8-checklist-core-web-vitals-2026-lcp-inp-cls/).
---
### Nos meilleurs modules PrestaShop pour connecter votre ERP et votre CRM
_Source :_
> Synchronisation Google Sheets bidirectionnelle, connecteurs Odoo, Sellsy et Axonaut, webhooks pour Zapier/Make/n8n : la sélection complète pour supprimer la double saisie sur PrestaShop 8 & 9.
## La double saisie est un impôt que vous vous prélevez à vous-même
Vos commandes vivent dans PrestaShop. Vos clients vivent dans le CRM. Vos factures vivent dans l'ERP. Et entre les trois : **un humain qui retape**.
Cette personne n'a pas cette tâche dans sa fiche de poste. Elle le fait parce qu'il faut bien le faire. Elle le fait tous les jours, et tous les jours ça produit des fautes de frappe que personne ne repère — jusqu'au jour où le stock ne tombe plus juste ou une facture part à la mauvaise adresse.
## Ce qu'un connecteur règle vraiment
Pas le temps. La **vérité**. Tant que la même information est maintenue à la main à deux endroits, il n'y a pas de source de vérité — il y a deux versions qui divergent. Un connecteur décide laquelle gagne.
## L'outil que tout le monde sous-estime
Google Sheets. Ce n'est pas un ERP, et c'est précisément sa force : votre équipe sait déjà s'en servir. Éditer prix, stocks et titres dans un tableur qui se synchronise tout seul règle quatre-vingts pour cent des cas — pour une fraction du coût et sans aucune formation.
---
### Nos meilleurs modules PrestaShop pour créer une urgence crédible
_Source :_
> Vente flash avec date de fin réelle, compteurs de stock, de visiteurs et de ventes branchés sur la base, alerte retour en stock, badge meilleure vente et produits tendance : la sélection complète pour créer l'urgence sans tomber sous le coup de la directive Omnibus.
## La rareté ne se décrète pas, elle se constate
L'urgence est le levier de conversion le plus puissant du e-commerce, et le plus mal utilisé. La raison est simple : il est trivial de _simuler_ la rareté — un compte à rebours en JavaScript, un « plus que 3 en stock » écrit en dur dans le thème, un compteur de visiteurs qui tire un nombre au hasard. Cela prend dix minutes et ne coûte rien.
Sauf que la rareté simulée a deux prix. Le premier est commercial : vos clients réguliers finissent par comprendre que le chronomètre repart à chaque visite, et à partir de là plus aucune de vos échéances n'est crédible. Le second est juridique, et il est autrement plus lourd.
## Ce que dit le droit européen
Déclarer faussement qu'un produit ne sera disponible que pendant une durée très limitée, afin d'emporter une décision immédiate, figure dans la **liste noire de l'annexe I de la directive 2005/29/CE** : c'est une pratique commerciale réputée déloyale _en toutes circonstances_, sans qu'il soit nécessaire de démontrer un préjudice. La directive Omnibus a renforcé les sanctions : jusqu'à 4 % du chiffre d'affaires annuel dans les États membres concernés.
Le compte à rebours qui se réinitialise à chaque nouvelle session tombe exactement dans cette case. Ce n'est pas un usage limite : c'est l'exemple canonique.
## Trois familles de leviers honnêtes
**Les leviers de temps** : vente flash avec une date de fin réelle, fixée en back-office, identique pour tous les visiteurs, et un prix qui remonte effectivement quand elle tombe.
**Les leviers de stock** : compteurs branchés sur le stock réel, alerte de retour en stock qui capte la demande au lieu de la perdre. La rareté subie devient une liste d'attente qualifiée.
**Les leviers de popularité** : nombre de ventes affiché, badge meilleure vente, produits tendance. Ils fonctionnent parce que le chiffre est vrai — et ils s'affichent seulement quand le seuil est réellement atteint.
## Ce que personne ne vous dira
Une urgence permanente n'est plus une urgence. Si chacune de vos fiches produit affiche un chronomètre, un compteur de visiteurs et un stock critique, vous n'avez pas construit de la pression : vous avez construit du bruit, et vous avez appris à vos clients à l'ignorer.
---
### Nos meilleurs modules PrestaShop pour documenter vos produits techniques
_Source :_
> Centre de documents et téléchargements avec page indexable, Q&R produit avec balisage QAPage et lecture audio : la sélection pour documenter vos produits techniques sur PrestaShop 8 & 9 — et en faire du trafic.
## La documentation n'est pas une annexe — c'est un argument de vente
La plupart des boutiques traitent les notices, les fiches techniques et les certificats CE comme une _contrainte administrative_ : uploadés quelque part, enterrés dans un onglet, trouvés par personne.
Or sur un produit technique, la documentation est précisément ce que le client cherche **avant** d'acheter. « Est-ce que cette pompe s'adapte à mon installation ? » La réponse est dans la fiche technique — et s'il ne la trouve pas, il achète ailleurs.
## Et Google la cherche aussi
Un PDF de fiche technique qui n'est lié de nulle part n'existe pas pour Google. Une page de documentation indexable, elle, capte une recherche très précise et très prête à acheter : celle de la référence, de la norme, du modèle.
## La question qu'on pose deux fois
« Est-ce compatible avec… ? » Votre SAV y répond chaque semaine. Votre fiche produit n'y répond jamais. **La même question, deux coûts :** le temps de votre équipe, et les clients qui n'ont pas demandé — et qui sont partis.
---
### Nos meilleurs modules PrestaShop pour être visible dans ChatGPT et les moteurs IA
_Source :_
> llms.txt, AI Crawler Manager, Traffic Radar, questions PAA, serveur MCP et support ACP : la sélection complète pour être visible dans ChatGPT, Claude et Perplexity sur PrestaShop 8 & 9.
## La recherche ne se fait plus seulement sur Google
Une part croissante de vos futurs clients ne découvrira jamais vos produits via une liste de résultats classique. Ils poseront la question à ChatGPT, à Perplexity ou à Claude — et obtiendront **un nom en réponse**, pas dix liens bleus. Ce nom, c'est le vôtre ou celui de votre concurrent.
Ce n'est pas de la prospective : ces assistants crawlent déjà votre boutique, avec leurs propres bots, leurs propres règles et leur propre idée de ce qu'est une source citable. La plupart des marchands ignorent même qu'ils passent.
## L'AEO n'est pas du SEO rebaptisé
Le SEO classique optimise pour le _classement_. L'AEO (Answer Engine Optimisation) optimise pour la _citabilité_. Un assistant ne classe pas : il sélectionne, résume et attribue à une source. Pour être choisi, votre contenu doit être lisible par la machine : structuré sans ambiguïté, factuel, répondant directement.
Concrètement, cela veut dire : un fichier llms.txt qui décrit votre boutique aux modèles ; un format questions-réponses propre ; des données structurées qui ne laissent rien deviner ; et la maîtrise de quels bots vous laissez passer.
## L'étape que presque personne n'a franchie
Le commerce agentique. L'assistant ne se contente plus de découvrir votre produit : il l'_achète_, au nom de l'utilisateur. Un serveur MCP et le support du protocole ACP rendent votre boutique connectable par les agents. Aujourd'hui, c'est une avance. Dans dix-huit mois, ce sera le minimum requis.
## Pour aller plus loin
Trois guides du blog complètent cette sélection : [comprendre l'AEO](https://www.datafirefly.com/2026/05/01/aeo-answer-engine-optimization-avenir-seo/), [l'AEO appliqué à PrestaShop 8](https://www.datafirefly.com/2026/05/21/aeo-2026-optimiser-prestashop-8-chatgpt-perplexity-google-ai-overviews/) et [topic clusters et autorité thématique](https://www.datafirefly.com/2026/06/09/topic-clusters-autorite-thematique-seo-semantique-ecommerce-2026/).
---
### Nos meilleurs modules PrestaShop pour fidéliser vos clients
_Source :_
> Wishlist avec alertes, web push, abonnements, relance d'échantillons, liste de cadeaux et centre de notifications : la sélection pour faire revenir vos clients sur PrestaShop 8 & 9 — sans détruire votre marge.
## La deuxième vente coûte cinq fois moins cher que la première
Vous payez pour chaque visiteur qui arrive sur votre site. Pour celui qui a déjà acheté, vous ne payez rien — il vous connaît, il vous fait confiance, son adresse est enregistrée. Et pourtant, la plupart des boutiques mettent tout leur budget en acquisition et **rien dans le retour**.
Pas par bêtise : parce que l'acquisition est visible et mesurable, alors que la fidélisation se joue en silence. Un client qui ne revient pas ne se plaint pas — il disparaît, simplement.
## La fidélisation n'est pas un problème de remise
Le réflexe consiste à envoyer un bon de réduction. Or un client qui revient uniquement pour la remise n'est pas un client fidèle — **c'est un client qui attend un prix**. Et vous venez de lui apprendre à ne plus jamais acheter au prix fort.
Ce qui marche, c'est autre chose : tomber au bon moment. Le client dont le consommable arrive à bout. Celui dont le produit souhaité est de retour en stock. Celui qui a commandé un échantillon et n'est jamais revenu.
## Le canal que personne n'utilise
Vous envoyez des emails. Votre taux d'ouverture est de 20 %, au mieux. La notification web push atteint 90 % — et ne coûte rien à l'envoi. Elle ne remplace pas l'email : elle touche les 80 % qui ne l'ont jamais ouvert.
---
### Nos meilleurs modules PrestaShop pour fixer vos preuves sociales
_Source :_
> Avis vérifiés avec rich snippets, synthèse IA des avis, Q&R produit, compteurs de ventes réels et badges best-seller : la sélection complète pour installer la preuve sociale sur PrestaShop 8 & 9.
## Pourquoi la preuve sociale décide de la vente
Sur une boutique PrestaShop, le visiteur qui arrive sur une fiche produit se pose toujours la même question, consciemment ou non : **est-ce que d'autres l'ont acheté, et est-ce qu'ils l'ont regretté ?** Tant que la page ne répond pas, elle demande un acte de foi. La preuve sociale est le mécanisme qui transforme cet acte de foi en décision rationnelle.
Elle ne se limite pas aux étoiles. Elle se construit par couches, et chaque couche répond à une objection différente : les avis répondent à « est-ce que ça tient ses promesses », les questions-réponses à « est-ce que ça marche dans mon cas », les compteurs de ventes à « est-ce que je suis le premier à tenter », les badges d'origine à « est-ce que je peux faire confiance au vendeur ».
## Le SEO en profite autant que la conversion
Les avis et les questions-réponses ne servent pas qu'à rassurer : correctement balisés, ils alimentent les **rich snippets** de Google. Les étoiles dans les résultats de recherche augmentent le taux de clic, et le balisage QAPage ouvre l'accès aux blocs de réponse directe. Un module d'avis sans schema.org valide, c'est la moitié de la valeur laissée sur la table.
Le contenu généré par vos clients est aussi la seule source de contenu frais qui grossit sans que vous écriviez une ligne — un signal que les moteurs, classiques comme génératifs, valorisent de plus en plus.
## Le piège de la preuve sociale fabriquée
Un compteur « 47 personnes regardent ce produit » sur une boutique qui fait trois visites par jour, cela se voit. Pire, depuis la directive européenne sur les pratiques commerciales déloyales, cela vous expose. Nos modules affichent des chiffres **réels**, issus de votre base : ventes effectives, paniers en cours, stock restant. Quand il n'y a rien à afficher, ils n'affichent rien plutôt que d'inventer.
---
### Nos meilleurs modules PrestaShop pour gérer les retours produits
_Source :_
> Portail de retours avec scan QR et motifs structurés, prédiction IA des retours et mention vente ferme : la sélection pour transformer les retours en levier de marge sur PrestaShop 8 & 9.
## Le retour n'est pas un incident, c'est une métrique
La plupart des boutiques traitent les retours comme une friction à subir. Ils sont en réalité **le signal le plus honnête que produit votre catalogue** : ils vous disent exactement où votre fiche produit a menti.
Un vêtement retourné pour une histoire de taille, c'est un guide des tailles manquant. Un appareil retourné parce qu'« il ne correspondait pas », c'est une photo qui trompe. Un retour sans motif déclaré, c'est un formulaire qui n'a jamais posé la question.
## La facture que personne n'ouvre
Un retour vous coûte le port aller, le port retour, le traitement, la remise en stock — et souvent une perte de valeur sur la marchandise. À 30 % de marge, un retour efface le bénéfice de trois commandes. C'est pour ça que le taux de retour n'est pas une métrique de service qu'on peaufine : c'est un levier de marge.
## Et pourtant : durcir le retour est une erreur
Un processus de retour difficile ne fait pas baisser les retours — il fait baisser les _réachats_. Le client retourne quand même, vous en veut, et ne revient jamais. Ce qui marche, ce n'est pas de freiner le retour, c'est **de supprimer la cause avant que la commande existe**.
---
### Nos meilleurs modules PrestaShop pour gérer un multiboutique
_Source :_
> Synchronisation multiboutique des produits et stocks, duplication de catégories, prix par pays, sélecteur de pays, balises hreflang et correctif back-office : la sélection pour un multiboutique PrestaShop maîtrisé.
## Un back-office, plusieurs boutiques, un risque de chaos
Le multiboutique PrestaShop permet plusieurs vitrines sur une seule installation : par pays, par marque ou par segment client. Mais le cœur ne fournit que le squelette. Garder les produits synchrones, piloter les prix par boutique, dupliquer les catalogues, référencer proprement chaque version linguistique : tout cela reste à votre charge.
## Synchroniser plutôt que copier
La différence entre un multiboutique tenu et un multiboutique à la dérive, c'est l'automatisation : des produits et stocks qui s'alignent entre boutiques, des catégories dupliquées complètes en un clic, des prix qui suivent un coefficient par pays.
## Et ne pas oublier le volet SEO
Plusieurs boutiques, c'est plusieurs domaines ou langues : sans balises hreflang propres, vos propres boutiques se cannibalisent sur Google. Le sélecteur de pays amène chaque visiteur sur la bonne boutique au lieu de le laisser deviner.
---
### Nos meilleurs modules PrestaShop pour gérer votre catalogue en masse
_Source :_
> Corbeille produits, import CSV/XML avec mapping visuel, flux fournisseurs, mise à jour de prix en masse, catégories et caractéristiques en masse, ordre en glisser-déposer : la sélection complète pour gérer votre catalogue sur PrestaShop 8 & 9.
## Un catalogue n'est pas du contenu, c'est une base de données
Tant que vous avez vingt produits, vous les éditez un par un. À deux cents, chaque action que vous exécutez « une fois » est en réalité exécutée deux cents fois — et ça change tout.
Une hausse de prix de 3 % : deux clics sur un produit, une journée perdue sur deux cents. Une nouvelle catégorie : une seconde sur un, un après-midi sur deux cents. C'est pour ça que l'édition en masse **n'est pas un confort mais une condition de survie passé une certaine taille de catalogue**.
## L'import n'est pas le problème
N'importe qui sait importer un CSV une fois. Ce qui échoue, c'est la _répétition_ : le flux fournisseur qui change toutes les nuits, les colonnes que le fournisseur renomme sans prévenir, les images qui ne passent pas. Un import ni mappé ni planifié est un import que vous reprenez à la main à chaque fois.
## L'action que personne ne peut annuler
La suppression. Dans PrestaShop, un produit supprimé est perdu définitivement — avec son historique, ses avis, son SEO. Une corbeille ne coûte presque rien et c'est le seul module de cette sélection qui vous protège _de vous-même_.
---
### Nos meilleurs modules PrestaShop pour Google Shopping et les réseaux
_Source :_
> Flux Google Shopping pour le Merchant Center, pixel Meta et API Conversions, publication sociale automatisée : la sélection pour ouvrir vos canaux de vente sur PrestaShop 8 & 9.
## Un canal n'est pas une audience — c'est un format
L'erreur la plus courante consiste à publier le même catalogue partout et à espérer. Or Google Shopping, Meta et les réseaux sociaux **ne vendent pas la même chose, ni de la même façon**.
Google Shopping capte une _intention_ : l'utilisateur cherche déjà. Meta crée un _désir_ : l'utilisateur ne cherche rien. Ce n'est pas le même rôle dans le tunnel — et traiter les deux avec le même flux et le même budget, c'est perdre des deux côtés.
## Ce qui décide du succès, c'est le flux — pas la campagne
On discute pendant des heures d'enchères et d'audiences. Or un produit refusé par le Merchant Center est **un produit invisible** : aucune enchère au monde ne le ramène. Et les refus viennent presque toujours d'attributs manquants, pas de la stratégie.
## Et le tracking décide si vous vous en apercevez
Sans tracking server-side, vous ne voyez pas une partie de vos ventes — et vous coupez la campagne qui marche vraiment. Cette sélection est donc inutile si vous ne mesurez pas correctement d'abord.
---
### Nos meilleurs modules PrestaShop pour l'accessibilité et la conformité EAA
_Source :_
> Widget EAA avec corrections WCAG automatiques, lecture audio des fiches, mode sombre et polices auto-hébergées : la sélection accessibilité pour PrestaShop 8 & 9.
## L'accessibilité est obligatoire depuis juin 2025
L'European Accessibility Act (EAA) s'applique au e-commerce : les boutiques en ligne doivent être utilisables par les personnes en situation de handicap, selon les critères WCAG. Cela couvre les contrastes, la navigation, les textes alternatifs et les formulaires, autrement dit le cœur de chaque fiche produit et du checkout.
## Corriger, pas seulement recouvrir
Un widget seul ne rend pas une boutique conforme. La sélection combine des corrections WCAG automatiques dans le code (textes alternatifs, focus, ARIA) avec des outils utilisateur : réglage de police et de contraste, lecture audio des fiches, mode sombre pour les yeux sensibles à la lumière.
## L'accessibilité vend
Environ un quart de la population vit avec une forme de limitation, permanente ou temporaire. Une boutique accessible est plus simple pour tout le monde : zones de clic plus grandes, contrastes plus nets, structure plus propre. La conformité et la conversion tirent dans le même sens.
---
### Nos meilleurs modules PrestaShop pour la facturation et le recouvrement B2B
_Source :_
> Facture mensuelle consolidée, relances automatiques avec pénalités et e-reporting 2026 : notre sélection classée de modules PrestaShop pour la facturation B2B — où vendre, c'est faire crédit.
## Vendre en B2B, c'est faire crédit
C'est la vérité qu'aucune facture ne dit tout haut. Un client B2B ne paie pas au clic — il paie à 30, 45, 60 jours. **Entre la vente et l'arrivée de l'argent, vous avez livré, facturé et financé. Vous êtes fournisseur et banque à la fois.**
## Et une facture par commande est une erreur en B2B
Votre client entreprise commande dix fois par mois et veut une facture, pas dix. _Dix factures, c'est dix paiements à suivre, dix occasions de litige, dix lignes dans sa compta — et dans la vôtre._
## La bonne question n'est pas « comment je facture »
C'est : comment je consolide, comment je recouvre sans casser la relation, et suis-je prêt pour l'e-reporting 2026. Trois questions, une seule trésorerie.
---
### Nos meilleurs modules PrestaShop pour la location, la réservation et la billetterie
_Source :_
> Location de produits avec calendrier et caution, prise de rendez-vous et créneaux, billetterie avec jauges : la sélection pour vendre du temps et de la disponibilité sur PrestaShop 8 & 9.
## Vendez du temps, pas seulement des objets
Une location, un rendez-vous ou un billet ne sont pas des produits classiques : ils ont une date, une durée et une disponibilité limitée. PrestaShop ne gère pas cela nativement, et c'est exactement là que naissent les doubles réservations, les appels téléphoniques et les calendriers Excel.
## Trois formats, un principe
La location de produits avec calendrier de disponibilité et caution. La prise de rendez-vous avec créneaux et confirmations. La billetterie avec jauges et billets. Les trois remplacent la gestion manuelle par un calendrier qui se tient tout seul.
## Le calendrier, c'est le stock
Quand une période est réservée, elle disparaît des choix : pas de double réservation, pas de rappels. Le client voit en direct ce qui est libre et paie immédiatement. L'objet peut revenir, le créneau non.
---
### Nos meilleurs modules PrestaShop pour la maintenance, la sauvegarde et la fiabilité
_Source :_
> Sauvegarde chiffrée, environnement de staging, nettoyage de base, vérification des liens morts, corbeille produits, Adminer en back-office et purge de cache : la sélection pour un PrestaShop qui encaisse les incidents.
## Une boutique qui tourne est une boutique qu'on entretient
On ne s'en rend compte que trop tard : une base que personne ne sauvegarde, une mise à jour testée directement en production, un produit supprimé par erreur sans retour possible. La maintenance ne se voit pas, mais elle décide si un incident coûte cinq minutes ou cinq jours.
## Prévenir, tester, nettoyer
La sauvegarde chiffrée crée le chemin retour. Le staging teste mises à jour et modules sans risque. Le nettoyage retire ce qui ralentit la base : paniers orphelins, logs, associations mortes. Le reste de la sélection attrape les erreurs du quotidien avant qu'elles n'atteignent le client.
## Et quand quelque chose arrive malgré tout
La corbeille produits restaure une fiche supprimée en quelques secondes, le gestionnaire de base donne un accès direct sans détour par phpMyAdmin, et la purge de cache rend chaque correctif immédiatement visible.
---
### Nos meilleurs modules PrestaShop pour la recherche et la navigation
_Source :_
> Live Search avec analytics des recherches, moteur de facettes SEO, navigation mobile, sélecteur de véhicule, recherche visuelle, recherches populaires, quick view et produits récemment consultés : la sélection pour que vos clients trouvent sur PrestaShop 8 & 9 — au lieu de partir.
## Celui qui ne trouve pas n'achète pas — et ne se plaint pas
Votre visiteur a cliqué vers votre site. Il voulait acheter. Il n'a pas trouvé ce qu'il cherchait. **Alors il est parti — et vous ne saurez jamais pourquoi.**
C'est la source de perte la plus silencieuse du e-commerce. Un client qui trouve ça trop cher le dit. Un client qui doute pose une question. Un client qui ne trouve pas ne dit rien : il ferme l'onglet.
## La recherche n'est pas une fonctionnalité — c'est un vendeur
Quand quelqu'un tape dans votre barre de recherche, il vous livre _l'intention d'achat la plus forte_ de toute votre boutique : il sait ce qu'il veut, et il vous le dit. Et à ce moment précis, la plupart des boutiques lui affichent « Aucun résultat ».
## Et les filtres ne sont pas un détail
Avec deux cents produits dans une catégorie, le filtre est la seule voie. Celui qui ne peut pas filtrer devrait feuilleter — et personne ne feuillette. C'est pour ça que des caractéristiques incomplètes sont un problème de vente, pas un problème de données.
---
### Nos meilleurs modules PrestaShop pour la TVA transfrontalière
_Source :_
> OSS/IOSS avec surveillance du seuil, contrôle VIES et autoliquidation, règle de taxe automatique : notre sélection classée de modules PrestaShop pour la TVA transfrontalière.
## Le seuil de 10 000 € se franchit sans prévenir
C'est le piège de la TVA transfrontalière. Tant que vos ventes vers d'autres pays de l'UE restent sous 10 000 € par an, vous appliquez votre TVA nationale. **Dès que vous le franchissez, vous devez appliquer la TVA du pays de votre client — pour chaque pays, dès le premier euro au-dessus.**
## Et une mauvaise TVA n'est pas une erreur d'arrondi
C'est une facture fausse, une déclaration fausse et un montant que vous finissez par porter vous-même. _Le client a payé ce qui était affiché ; l'écart avec le bon taux, c'est pour vous._
## La bonne question n'est pas « quel taux j'applique »
C'est : ma boutique applique-t-elle le bon automatiquement, connaît-elle le cas B2B, et puis-je déclarer en fin de trimestre sans calcul manuel. Trois questions, un seul sujet.
---
### Nos meilleurs modules PrestaShop pour le commerce agentique et les agents IA
_Source :_
> Serveur MCP, checkout ChatGPT via ACP, llms.txt, gestionnaire de crawlers IA, radar temps réel et webhooks : la sélection pour vendre aux agents IA sur PrestaShop 8 & 9.
## Le prochain client est un agent
ChatGPT, Claude et Perplexity ne se contentent plus de recommander des produits : ils commencent à les acheter. Le commerce agentique signifie qu'un assistant IA cherche, compare et commande pour le compte du client. Une boutique qu'un agent ne peut ni lire ni opérer n'existe pas pour ce canal.
## Devenir lisible, puis achetable
llms.txt rend le catalogue lisible pour les modèles de langage. Le gestionnaire de crawlers contrôle quels bots IA voient quoi. Le serveur MCP expose catalogue, stocks et commandes comme des outils qu'un agent peut appeler. Et l'Agentic Commerce Protocol permet à ChatGPT de payer directement dans votre boutique.
## Et voir le nouveau trafic
Le trafic IA apparaît à peine dans les analytics classiques. Le radar temps réel distingue humains et crawlers IA, et les webhooks connectent les commandes au reste de votre automatisation.
---
### Nos meilleurs modules PrestaShop pour le dropshipping
_Source :_
> Import de flux fournisseurs, export automatique des commandes, outils CSV et XML, suivi multi-transporteurs et page de tracking brandée : la sélection dropshipping pour PrestaShop 8 & 9.
## Le dropshipping vit ou meurt par ses flux
Pas d'entrepôt à soi signifie : votre stock est celui du fournisseur, votre délai celui de son expédition. Le modèle ne fonctionne que si les flux de données fonctionnent : catalogues fournisseurs en entrée, commandes en sortie, tracking en retour vers le client.
## Automatiser les trois flux
L'import fournisseurs synchronise catalogues, prix et stocks depuis des flux CSV, XML et JSON. L'export de commandes envoie chaque commande automatiquement au bon fournisseur ou logisticien. Et le tracking revient : le client suit son colis chez vous, pas chez le fournisseur.
## La marge vit dans la discipline
Règles de prix par flux, coussins de stock contre les ruptures, statuts qui se mettent à jour seuls : le dropshipping ne passe à l'échelle qu'avec des règles qui tournent sans vous.
---
### Nos meilleurs modules PrestaShop pour le merchandising visuel
_Source :_
> Zoom HD, vue 360° et look shoppable avec hotspots : notre sélection classée de modules PrestaShop pour le merchandising visuel — pour que le client voie ce qu'il toucherait en magasin.
## En ligne, on n'achète pas ce qu'on ne peut pas inspecter
C'est la limite de toute boutique en ligne. En magasin, le client tourne le produit, touche la matière, voit la taille. **En ligne, il a une photo — et tout ce que la photo ne montre pas est un doute qui freine l'achat.**
## Et une belle photo n'est pas la même chose qu'une photo utile
Une image de catalogue est jolie. Un zoom qui montre la couture, une vue 360° qui montre le dos, un look qui montre le produit porté : _voilà ce qui répond à la question que le client se pose avant de partir._
## La bonne question n'est pas « comment faire de plus belles images »
C'est : quel doute chaque image lève. Parce qu'un merchandising qui ne convainc pas ne produit pas moins de ventes — il produit des retours.
---
### Nos meilleurs modules PrestaShop pour le RGPD et les cookies
_Source :_
> Bandeau cookies avec vrai blocage et Consent Mode v2, suppression de compte RGPD, journal d'audit, vérification d'âge et d'emails : la sélection complète pour le RGPD et la vie privée sur PrestaShop 8 & 9.
## Le RGPD, ce n'est pas un bandeau
La plupart des boutiques se croient conformes parce qu'elles ont un bandeau cookies. Mais le bandeau, c'est la partie la plus visible — et la moins contrôlée. Ce qu'on vérifie vraiment, c'est : **déposez-vous des traceurs avant le consentement ? Refuser est-il aussi simple qu'accepter ? Pouvez-vous prouver ce que l'utilisateur a cliqué ?**
À ces trois questions, la majorité des boutiques européennes répond non — avec un bandeau sur la page.
## Les trois piliers qui comptent
**Le consentement**, techniquement appliqué : aucun script ne doit se charger avant le clic. Un bandeau qui n'est que de l'affichage pendant que Google Analytics tourne déjà est pire qu'aucun bandeau — il documente votre manquement.
**Les droits des personnes** : accès, rectification, effacement. Le droit à l'oubli n'est pas un principe, c'est un bouton que le client doit pouvoir presser — et qui ne doit pas détruire votre comptabilité.
**La démontrabilité** : en cas de contrôle, vous devez pouvoir montrer qui a fait quoi et quand. Sans journal d'audit, votre déclaration n'est qu'une affirmation.
## Le Consent Mode v2 n'est plus une option
Si vous utilisez Google Ads ou GA4 en Europe, Google exige désormais le Consent Mode v2. Sans lui, vous perdez des données de conversion et de la portée en remarketing. À partir de là, la conformité RGPD et l'efficacité de votre publicité tiennent au même fil.
---
### Nos meilleurs modules PrestaShop pour le social commerce
_Source :_
> Live shopping, galerie UGC shoppable, Shop the Look, achat groupé, publication sociale automatique, connexion sociale et WhatsApp : la sélection social commerce pour PrestaShop 8 & 9.
## Du feed au panier
Vos clients passent leur temps sur Instagram, TikTok et WhatsApp, mais ils achètent dans votre boutique. Le social commerce referme cet écart : des contenus qui vendent, des achats qui se partagent, et des canaux qui mènent droit au panier.
## Des contenus qui nourrissent la boutique
Le live shopping ramène l'événement de vente sur votre propre site. La galerie UGC rend les photos clients shoppables. Shop the Look transforme les images d'inspiration en paniers. Et la publication automatique garde les profils sociaux à jour sans travail manuel.
## Et les mécaniques qui récompensent le partage
L'achat groupé donne au client une raison de faire suivre le lien : plus il y a d'acheteurs, plus le prix descend. La connexion sociale et le contact WhatsApp suppriment le dernier obstacle entre l'intérêt et la commande.
---
### Nos meilleurs modules PrestaShop pour les temps forts et l'animation saisonnière
_Source :_
> Décoration saisonnière planifiée, barre d'annonce avec compte à rebours et vidéo en fond : notre sélection classée de modules PrestaShop pour les temps forts — pour qu'un temps fort ait lieu sans que personne ne veille la nuit.
## Un temps fort qui se prépare à la main n'a pas lieu
C'est le piège de la vente saisonnière. Black Friday, Noël, soldes d'été : vous savez un an à l'avance quand ils arrivent. **Et pourtant la décoration est mise en ligne à minuit la veille — ou pas du tout, parce que la journée était trop chargée.**
## Et un temps fort sans compte à rebours est un temps fort sans urgence
Une offre sans échéance visible est une offre qui peut attendre. _Un compte à rebours transforme « un jour » en « maintenant » — et c'est exactement ce qui sépare la campagne planifiée de celle qu'on rate._
## La bonne question n'est pas « comment décorer plus joliment »
C'est : est-ce que ça se déclenche tout seul à la bonne heure. Parce qu'un temps fort qui dépend de la disponibilité d'une personne le soir n'est pas un plan — c'est un risque.
---
### Nos meilleurs modules PrestaShop pour mesurer vos conversions
_Source :_
> Tracking server-side, Google Tag sans gestionnaire de balises, API Conversions Meta, heatmap et tunnel, flux Merchant Center : la sélection complète pour bien mesurer vos conversions sur PrestaShop 8 & 9.
## Votre tracking ment — et il ment depuis des années
Si vous ne comptez que sur un pixel navigateur, vous perdez une part considérable de vos conversions. Pas à cause d'un bug : **parce que le pixel est systématiquement bloqué**. Bloqueurs de pub, Safari ITP, Firefox, iOS. L'achat a eu lieu — votre campagne ne l'a simplement jamais su.
La conséquence est perverse : votre publicité paraît moins bonne qu'elle ne l'est. Vous baissez le budget d'une campagne qui vend. Vous montez celui d'une campagne mal trackée mais qui _semble_ meilleure. Et pendant des mois, vous optimisez contre des chiffres faux.
## Le server-side n'est pas une amélioration — c'est une réparation
Le tracking server-side envoie l'événement de conversion depuis votre serveur, pas depuis le navigateur. Aucun bloqueur ne peut le supprimer, parce qu'il ne se passe pas dans le navigateur. Les conversions récupérées ne sont pas inventées — **ce sont les vôtres, celles que vous n'avez jamais vues**.
## Et ensuite, ce qu'aucun chiffre ne vous dira
Analytics vous dit que 40 % abandonnent au checkout. Il ne vous dit pas _pourquoi_. Pour ça, il faut une heatmap et un tunnel — et la réponse n'est presque jamais celle que vous attendiez.
---
### Nos meilleurs modules PrestaShop pour mettre vos produits en conformité
_Source :_
> GPSR, prix de référence Omnibus, garantie légale, indice de réparabilité, pièces détachées, allergènes INCO, Nutri-Score et passeport ESPR : la sélection complète pour la conformité produit sur PrestaShop 8 & 9.
## La conformité n'est plus une option, c'est une autorisation d'exercer
En cinq ans, la réglementation européenne de la vente de produits est passée de la formalité au terrain de contrôle. GPSR, INCO, ESPR, indice de réparabilité, garantie légale, Omnibus, AI Act : chaque texte ajoute des mentions obligatoires qui doivent figurer **sur la fiche produit** — pas dans les CGV, pas dans les mentions légales.
Et contrairement au SEO, il n'y a pas de délai de grâce. Une mention manquante n'est pas un classement perdu, c'est un manquement.
## Ce que la plupart des marchands sous-estiment
Ces obligations s'appliquent _par produit_, pas par boutique. Sur deux cents références, cela signifie deux cents identifications de fabricant, deux cents avertissements de sécurité, deux cents listes d'allergènes. À la main : impossible. C'est exactement comme ça que naît la non-conformité — pas par mauvaise foi, mais par volume.
## Le meilleur effet de bord, et personne ne l'attend
Ces mentions sont des **informations d'achat**. Un indice de réparabilité rassure. Un Nutri-Score visible vend. Une disponibilité de pièces détachées clairement indiquée justifie le prix. La conformité, bien faite, n'est pas un centre de coût — c'est un argument de vente que vos concurrents cachent parce qu'il les agace.
## Pour aller plus loin
Trois guides du blog complètent cette sélection : [la checklist GPSR](https://www.datafirefly.com/2026/06/04/gpsr-2026-checklist-conformite-produit-prestashop/), [l'accessibilité WCAG 2.2 et l'EAA](https://www.datafirefly.com/2026/07/16/accessibilite-wcag-2-2-european-accessibility-act-prestashop-2026/) et [la directive Omnibus et le prix de référence](https://www.datafirefly.com/2026/06/22/directive-omnibus-prix-reference-promotions-prestashop-2026/).
---
### Nos meilleurs modules PrestaShop pour migrer vers PrestaShop
_Source :_
> Migration Shopify et WooCommerce avec redirections 301, synchronisation Etsy : la sélection pour passer à PrestaShop 8 & 9 sans perdre votre SEO.
## Une migration ne perd pas des produits — elle perd de l'autorité
Tout le monde craint la même chose : perdre des produits, des commandes, des comptes clients. C'est la partie facile. Ce qui se perd réellement est invisible : **votre SEO**.
Vos anciennes URL disparaissent. Google trouve des 404 là où il connaissait des pages qui rankaient. Et en un trimestre, la moitié de votre trafic organique est partie — sans incident, sans alerte, sans que personne n'ait rien remarqué.
## Le seul chiffre qui compte
Pas le nombre de produits migrés. Le nombre de **redirections 301 mises en place**. Une migration sans plan de redirections n'est pas une migration — c'est un redémarrage à zéro avec un catalogue plein.
## Ce qu'il faut trancher avant de commencer
Voulez-vous _déménager_ ou _vendre en plus_ ? Quitter Shopify, c'est déménager. Rester sur Etsy et ajouter PrestaShop, c'est opérer deux canaux — et ça demande de la synchronisation, pas de la migration. Ce sont deux projets complètement différents, et on les confond en permanence.
## Pour aller plus loin
Deux guides du blog complètent cette sélection : [la checklist migration PrestaShop 1.7 vers 8](https://www.datafirefly.com/2026/06/10/migration-prestashop-1-7-vers-8-checklist-2026/) et [PrestaShop 9 vs PrestaShop 8](https://www.datafirefly.com/2026/05/01/prestashop-9-vs-prestashop-8-changements/).
---
### Nos meilleurs modules PrestaShop pour offrir et pour les occasions
_Source :_
> Emballage cadeau avec message, liste d'occasions et cagnotte partagée : notre sélection classée de modules PrestaShop pour offrir — où une vente amène deux clients.
## Un cadeau, c'est deux clients pour une vente
C'est le calcul que la plupart des boutiques manquent. Celui qui achète un cadeau paie — mais celui qui le reçoit découvre votre marque. **Une vente, deux contacts : l'acheteur qui paie et le futur client qui ouvre votre colis.**
## Et acheter un cadeau est plus difficile qu'acheter pour soi
L'acheteur ne connaît pas la taille, connaît à moitié le goût, connaît la date exactement. _Chaque friction — pas d'emballage, pas de liste, pas de paiement partagé — l'envoie vers le concurrent qui lui simplifie la vie._
## La bonne question n'est pas « comment vendre plus »
C'est : comment rendre le fait d'offrir aussi simple que d'acheter pour soi. Parce qu'une occasion est une date fixe — et une date qu'on ne peut pas rater est la meilleure raison d'acheter qui soit.
---
### Nos meilleurs modules PrestaShop pour optimiser vos fiches produit
_Source :_
> Swatches de variantes, vidéo produit, guide des tailles, FAQ produit, quick view, personnalisation, boutons de quantité et lecture audio : la sélection complète pour optimiser vos fiches produit sur PrestaShop 8 & 9.
## Votre fiche produit est votre vendeur
En boutique, un vendeur répond aux questions, montre les coloris, fait essayer, rassure. En ligne, c'est la fiche produit qui fait tout ça — seule, sans relance, en quelques secondes. Tout ce qu'elle ne répond pas devient un doute. Et le doute ne met rien au panier.
Optimiser une fiche produit, ce n'est pas « la rendre plus jolie ». C'est **répondre, dans l'ordre, aux questions que le client se pose vraiment** — et dans l'ordre où il se les pose.
## Quatre questions, quatre réponses
**« À quoi ça ressemble ? »** Une photo suffit rarement. Les swatches de variantes montrent les vraies couleurs, la vidéo montre l'échelle et le mouvement.
**« Est-ce que ça me convient ? »** Guide des tailles, fiche technique, personnalisation. C'est la question dont l'absence de réponse coûte le plus cher : elle génère des retours.
**« Et si… ? »** La FAQ produit devance les questions récurrentes du SAV — et devient du contenu indexable au passage.
**« Puis-je comparer vite ? »** Le quick view évite au client de faire cinq allers-retours entre la liste et la fiche avant de décider.
## L'erreur : tout ajouter
Une fiche produit qui montre tout ne montre plus rien. Chaque module de cette sélection doit gagner sa place _en répondant à une vraie question_. Si vous ne vendez pas de vêtements, le guide des tailles est du bruit. Si votre produit n'a qu'une variante, les swatches sont du bruit. Installez ce que votre client demande — pas ce que la concurrence affiche.
## Pour aller plus loin
Trois guides du blog complètent cette sélection : [vidéos produit et Core Web Vitals](https://www.datafirefly.com/2026/06/02/videos-produit-conversion-vs-core-web-vitals-prestashop-8-2026/), [le FAQ schema et les rich snippets](https://www.datafirefly.com/2026/05/09/prestashop-faq-schema-rich-snippets-google-guide-2026/) et [Schema.org Product en 2026](https://www.datafirefly.com/2026/07/20/schema-org-product-2026-hasmerchantreturnpolicy-shippingdetails-prestashop-woocommerce/).
---
### Nos meilleurs modules PrestaShop pour optimiser votre logistique
_Source :_
> Date de livraison estimée, expédition partielle, page de suivi brandée, polling transporteur automatique, export 3PL, multi-entrepôt, picking au scan et surcoût de livraison : la sélection complète pour la logistique sur PrestaShop 8 & 9.
## La logistique est la seule étape que le client ressent vraiment
Votre client regarde votre catalogue pendant une heure. Il attend son colis pendant trois jours. Et c'est dans ces trois jours qu'il décide s'il reviendra — pas dans votre checkout.
Pourtant, la plupart des défauts logistiques sont **invisibles jusqu'à ce qu'ils deviennent des tickets de SAV** : une commande qui attend parce qu'un article manque ; un colis qui dort dans le mauvais entrepôt ; un client qui demande cinq fois où en est sa livraison.
## Les trois coûts que personne ne calcule
**La commande qui bloque.** Un article manque, alors toute la commande attend. Le client attend cinq produits à cause d'un seul. L'expédition partielle règle ça — et personne ne l'active.
**Les tickets « où est mon colis ? ».** Ils sont le premier volume de n'importe quel SAV e-commerce. Une bonne page de suivi les efface presque entièrement — ce n'est pas de la cosmétique, c'est une baisse de coût.
**Le mauvais prix de livraison.** La Corse, les DOM, la montagne : un tarif forfaitaire vous fait perdre de l'argent à chaque commande dans ces zones — ou fait fuir tous les autres.
## Ce qu'il faut faire en premier
La date de livraison estimée. C'est le module le moins cher de cette sélection, le plus rapide à installer — et le seul qui _simultanément_ augmente la conversion et fait baisser les demandes au SAV. Tout le reste peut attendre.
---
### Nos meilleurs modules PrestaShop pour produire du contenu SEO à l'échelle
_Source :_
> Générateur IA de balises meta, FAQ produit automatique, blog SEO planifié, glossaire SEO avec maillage interne : la sélection complète pour produire du contenu SEO à l'échelle sur PrestaShop 8 & 9 — sans produire du contenu pauvre.
## Le vrai problème n'est pas d'écrire — c'est le volume
Écrire un bon article, tout le monde sait faire. Doter deux cents fiches produit de balises meta uniques, d'une FAQ et d'une vraie description : personne ne le fait à la main. C'est exactement là que le SEO de contenu échoue en e-commerce — pas sur la qualité, mais sur la **masse de pages qui auraient quelque chose à dire et qui se taisent**.
Un catalogue de deux cents produits, c'est un catalogue avec deux cents meta descriptions vides, deux cents questions sans réponse, et un blog que personne n'a touché depuis huit mois. Ça ne vous coûte pas un classement — ça vous coûte l'existence sur des centaines de requêtes.
## L'IA règle le problème de volume, pas celui de qualité
Un modèle de langage n'écrit pas un meilleur article que vous. Il en écrit _deux cents pendant que vous en écrivez un_. C'est tout l'enjeu, et c'est aussi la limite : du contenu IA que personne ne relit est du contenu que personne ne lit.
Le bon partage : la machine produit le brouillon en volume, l'humain relit et corrige. Supprimez cette seconde moitié et vous produisez exactement le contenu pauvre que Google sanctionne depuis des années.
## Commencez par l'existant
Avant d'écrire le moindre nouvel article : remplissez les balises meta de vos pages existantes. Ces pages sont déjà indexées, elles ont déjà de l'autorité, elles reçoivent déjà des impressions. Leur donner un bon titre produit un effet en quelques jours — un nouvel article, en quelques mois.
## Pour aller plus loin
Deux guides du blog complètent cette sélection : [topic clusters et autorité thématique](https://www.datafirefly.com/2026/06/09/topic-clusters-autorite-thematique-seo-semantique-ecommerce-2026/) et [le guide complet du SEO e-commerce](https://www.datafirefly.com/2026/05/01/seo-ecommerce-guide-complet-2026/).
---
### Nos meilleurs modules PrestaShop pour rassurer vos visiteurs
_Source :_
> Vrais avis, synthèse IA avec avantages et inconvénients, disponibilité des pièces, garantie légale visible, Made in France et badge meilleure vente sur de vrais chiffres : la sélection pour prouver au lieu d'affirmer sur PrestaShop 8 & 9.
## La confiance ne s'affirme pas — elle se prouve
Toutes les boutiques écrivent « Paiement sécurisé » et « Livraison rapide ». Personne n'y croit, parce que **toutes les boutiques l'écrivent** — y compris celles qui disparaîtront demain. Une affirmation que tout le monde fait ne prouve rien.
Ce qui prouve, c'est un _fait vérifiable_ : un avis qui mentionne un défaut. Une origine qu'on peut contrôler. Une disponibilité de pièces qui vous engage. Une garantie légale que vous affichez au lieu de l'enterrer.
## La preuve que vos concurrents cachent
La plupart des boutiques enterrent leurs mentions obligatoires dans les petits caractères — garantie légale, indice de réparabilité, pièces détachées — parce qu'elles les vivent comme une contrainte. Or ce sont précisément ces mentions qui **vous engagent à quelque chose**. Et ce qui engage rassure.
## Et l'avis qui mentionne un défaut
Un produit noté 5,0 sur 5 sur deux cents avis a l'air faux — parce qu'il l'est généralement. Un produit à 4,3 avec une critique visible a l'air vrai. Le défaut que vous montrez est la preuve que les avantages sont réels.
---
### Nos meilleurs modules PrestaShop pour réduire l'abandon de panier
_Source :_
> Relance multi-étapes, sauvegarde de panier par lien magique, panier latéral, alertes prix et retour en stock : la sélection complète pour récupérer les paniers abandonnés sur PrestaShop 8 & 9.
## L'abandon n'est pas un accident, c'est un signal
Sept paniers sur dix n'arrivent jamais au paiement. On traite souvent ce chiffre comme une fatalité, alors qu'il recouvre **des causes très différentes qui appellent des réponses très différentes**. Le visiteur qui hésite sur le prix, celui qui compare, celui qui est interrompu, celui qui bute sur un formulaire : ce sont quatre problèmes distincts, et un seul module ne les couvre pas tous.
La bonne façon d'aborder le sujet n'est pas « comment relancer », mais « à quel moment le panier meurt ». Chaque module de cette sélection intervient à un moment précis de cette agonie.
## Trois fenêtres, trois mécaniques
**Avant l'ajout au panier**, le visiteur bloque sur le prix ou sur une rupture. Il n'y a pas encore de panier à sauver, mais il y a une intention à capturer : alerte prix, alerte retour en stock. Ce sont les seuls outils qui récupèrent un revenu autrement définitivement perdu.
**Pendant la session**, le panier existe mais reste invisible. Un panier latéral et un rappel sticky maintiennent la charge mentale de l'achat présente sans forcer la navigation vers une page dédiée.
**Après le départ**, tout se joue sur la capacité à revenir _au même panier_. Un lien magique qui restaure le panier exact, et une séquence de relance en plusieurs temps, valent mieux qu'un mail unique avec un code promo.
## Le piège du code promo réflexe
La relance qui offre 10 % dès le premier email apprend à vos clients réguliers à abandonner leur panier exprès. C'est un coût que vous vous infligez. Une séquence bien construite commence par un simple rappel, ajoute de la réassurance au deuxième temps, et ne dégaine l'incitation commerciale qu'en dernier recours — quand elle est encore rentable.
---
### Nos meilleurs modules PrestaShop pour sécuriser votre boutique
_Source :_
> Double authentification du back-office, connexion sans mot de passe, vérification d'e-mails anti-faux-comptes et journal d'audit : la sélection pour blinder les accès au lieu d'afficher un cadenas, sur PrestaShop 8 & 9.
## La sécurité ne s'affiche pas — elle se met en place
Toutes les boutiques collent un cadenas « paiement sécurisé » dans le pied de page. Il ne protège rien de ce qui compte vraiment. La porte par laquelle on entre, c'est le back-office ; la faille qu'on exploite, c'est un mot de passe ; le fantôme qui pollue, c'est un faux compte.
## Cinq portes, cinq serrures
Sécuriser une boutique PrestaShop, ce n'est pas un badge : c'est fermer une à une les portes que le cœur laisse ouvertes. Une seconde authentification pour l'admin, un accès sans mot de passe pour le client, une base sans faux comptes, et la trace de qui a fait quoi.
## Des standards, pas du théâtre
TOTP RFC 6238, chiffrement AES-256, hooks natifs, aucune dépendance externe. Ce qui protège une boutique, ce n'est pas ce qu'on affiche — c'est ce qu'on met réellement en place.
---
### Nos meilleurs modules PrestaShop pour un checkout rapide
_Source :_
> Checkout en une page, paiement express Apple Pay et Google Pay, autocomplétion d'adresse, connexion sociale, lien magique, indicatif téléphonique normalisé : la sélection complète pour raccourcir le tunnel de commande sur PrestaShop 8 & 9.
## Le tunnel le plus court est celui qu'on ne traverse pas
La plupart des projets de « refonte du checkout » commencent par la mauvaise question : combien d'étapes faut-il ? Une, trois, cinq ? C'est une question de designer, pas de marchand. La bonne question est plus prosaïque : **combien de choses demande-t-on au client, et combien pouvait-on ne pas lui demander ?**
Un checkout en une seule page qui exige vingt champs, une création de compte et une confirmation d'e-mail convertit moins bien qu'un tunnel en trois étapes qui en demande huit. Le nombre d'étapes est une métrique de vanité. Le nombre de saisies, de décisions et de surprises, lui, se paie comptant.
## Trois familles de leviers
**Les leviers de saisie** réduisent ce que le client tape : autocomplétion d'adresse, sélecteur d'indicatif téléphonique, pré-remplissage. Peu spectaculaires, très rentables, et ils améliorent au passage la qualité de vos données.
**Les leviers d'identification** suppriment le mot de passe du chemin critique : commande invité, connexion sociale, lien de connexion par e-mail. Le client qui a oublié son mot de passe au moment de payer est un client perdu, pas un client à réinitialiser.
**Les leviers de contournement** font disparaître le tunnel plutôt que de l'optimiser : Apple Pay, Google Pay, Amazon Pay. L'adresse et le moyen de paiement viennent du portefeuille du téléphone. Il n'y a plus de formulaire du tout.
## Ce qui tue vraiment une commande
Ce n'est presque jamais l'esthétique du tunnel. C'est le coût inattendu découvert à la dernière étape — frais de port qui apparaissent au paiement, frais de moyen de paiement ajoutés en fin de parcours, taxes non annoncées. Un client qui voit son total changer au moment de sortir sa carte ne cherche pas à comprendre : il ferme l'onglet.
Aucun module ne rattrape cela. La transparence des coûts est un choix, pas une fonctionnalité.
---
### Nos meilleurs modules PrestaShop pour un commerce responsable et durable
_Source :_
> Passeport numérique produit ESPR, indice de réparabilité, disponibilité des pièces L111-4, badges d'origine, garantie légale de deux ans et arrondi solidaire : la sélection commerce responsable pour PrestaShop 8 & 9.
## La durabilité n'est pas un logo, c'est une déclaration
Passeport numérique produit, indice de réparabilité, disponibilité des pièces détachées, affichage d'origine : l'UE transforme la promesse de durabilité en données vérifiables. Les afficher proprement vend mieux et prend de l'avance sur la réglementation.
## Ce qui est déjà obligatoire et ce qui arrive
Le règlement ESPR introduit progressivement le passeport numérique produit (DPP). En France, le L111-4 impose l'information sur les pièces détachées et l'indice de réparabilité couvre des catégories précises. La garantie légale de deux ans s'applique dans toute l'UE. Implémenter tôt, c'est éviter la mise à niveau dans l'urgence.
## Et ce qui convainc volontairement
Les badges d'origine avec filtres et l'arrondi solidaire au checkout rendent l'engagement visible sans greenwashing : des déclarations concrètes et vérifiables plutôt que des adjectifs verts.
---
### Nos meilleurs modules PrestaShop pour une facturation conforme
_Source :_
> Factur-X, export comptable (FEC, Sage, EBP, Pennylane), pont ERP, facture proforma, règle de taxe automatique et douane DDP/DAP : la sélection complète pour une facturation conforme sur PrestaShop 8 & 9.
## La facture électronique n'est plus une option
En France, en Allemagne, en Italie, en Espagne : la facturation électronique devient obligatoire par étapes. Pas un PDF envoyé par email — une **facture structurée qu'une machine peut lire**, au format Factur-X, ZUGFeRD ou XRechnung.
La différence n'est pas cosmétique. Une facture PDF est une image de facture. Une facture Factur-X est cette même image _plus_ les données qu'elle contient, lisibles par la machine, vérifiables deux ans plus tard. Votre comptable, votre client et l'administration lisent le même fichier — et personne ne le retape.
## Ce que la plupart des boutiques oublient
La facture n'est que le bout de la chaîne. Avant elle : la règle de taxe oubliée à la création du produit ; les frais de douane facturés au client après la livraison ; l'export comptable repris à la main chaque mois. Chacun de ces trous est petit — et chacun vous coûte plus cher que la facture elle-même.
## Le frais qui transforme un client en ennemi
Un colis hors UE qui arrive avec des frais de douane surprise n'est pas un désagrément mineur. C'est un retour, un avis négatif, et un client qui ne revient jamais. Le DDP vous coûte d'avance ce que le DAP vous coûte après — en plus cher.
---
### Nos meilleurs modules PrestaShop pour vendre à l'international
_Source :_
> Traduction IA du catalogue et du SEO, sélecteur de pays, hreflang et douane DDP/DAP : la sélection pour vendre à l'international sur PrestaShop 8 & 9 — sans ouvrir un marché qu'on ne peut pas servir.
## Traduire n'est pas vendre
On croit qu'il suffit de traduire le catalogue et d'afficher les drapeaux. Or un client allemand qui atterrit sur une page mal traduite, avec un prix dans la mauvaise devise et des frais de port qu'il découvre à la fin, **n'achète pas** — et il ne vous dira pas pourquoi.
La vente à l'étranger échoue rarement sur le produit. Elle échoue sur des _détails qu'on prend pour des détails_ : une description qui sonne comme une machine, un pays qu'on ne peut pas sélectionner, une douane qui apparaît à la porte.
## La traduction qui vous coûte plus cher que pas de traduction
Une mauvaise traduction est pire qu'une page en anglais : elle signale au client que vous ne le prenez pas au sérieux. C'est pour ça que le seul critère acceptable est : **le texte est-il relu par un humain ?** L'IA produit le volume — un humain valide la langue.
## Et le SEO ne suit pas automatiquement
Vos pages traduites ne se positionnent pas parce qu'elles existent. Sans hreflang propre, Google décide seul quelle version de langue afficher — et il se trompe.
---
### Nos meilleurs modules PrestaShop pour vendre de l'électronique et du high-tech
_Source :_
> Indice de réparabilité, disponibilité des pièces détachées L111-4, garantie légale 2 ans, GPSR, comparateur de produits, cross-sell d'accessoires, assurance colis et livraison d'objets lourds : la sélection complète pour vendre de l'électronique et du high-tech sur PrestaShop 8 & 9.
## Vendre de l'électronique : la conformité la plus lourde du e-commerce
L'indice de réparabilité est né sur l'électronique : smartphones, ordinateurs, téléviseurs, lave-linge. L'afficher sur chaque fiche produit concernée n'est pas une option — c'est une obligation, et l'électronique est le premier secteur visé.
Il vient rarement seul : disponibilité des pièces détachées, garantie légale de 2 ans, GPSR sur les appareils importés. L'électronique cumule des obligations que la plupart des marchands n'ont jamais croisées.
## Pièces détachées, garantie, GPSR : le reste de l'obligation
L'électronique tombe en panne, se retourne, s'échange. Sans disponibilité des pièces détachées affichée ni mention de garantie légale, chaque litige part du mauvais pied. Trois modules posent ces affichages proprement sur chaque fiche.
## Un achat qui se compare et s'équipe
Le client compare les fiches techniques. Si votre boutique ne propose pas de comparaison, il compare dans l'onglet d'à côté — et achète là-bas. Un comparateur de produits le retient sur votre page ; le panier sticky et le cross-sell IA proposent la coque, le câble, l'accessoire au bon moment.
## Un colis qui vaut cher — et parfois très lourd
Un téléphone à 1000 €, un écran fragile : l'assurance transport au checkout couvre l'envoi de valeur. Et pour le gros électroménager — réfrigérateur, lave-linge, grand téléviseur — le formulaire de conditions d'accès demande étage et ascenseur avant que l'envoi encombrant ne parte.
---
### Nos meilleurs modules PrestaShop pour vendre des articles de sport
_Source :_
> Comparateur technique de produits, conseiller de taille IA, livraison encombrant pour vélo et fitness, disponibilité des pièces détachées, garantie légale, prise de rendez-vous essai et atelier, devis club et commande rapide : la sélection complète pour vendre des articles de sport sur PrestaShop 8 & 9.
## Vendre des articles de sport : du technique, de l'encombrant et des clubs
L'équipement sportif s'achète sur des caractéristiques techniques : taille de cadre, poids, pointure, résistance. Ne pas laisser comparer, c'est envoyer le client comparer dans un autre onglet — et c'est là qu'il achète.
## La taille qui fait revenir le colis
Chaussures de running, textile technique : ici comme dans la mode, la taille et la coupe sont la première cause de retour. Un conseiller de taille IA sur la fiche réduit la part de devinette.
## Un vélo ne rentre pas dans un carton
Vélo, rameur, tapis de course : de l'encombrant qui réclame des conditions d'accès demandées au checkout. Et l'équipement sportif s'utilise, donc s'entretient : disponibilité des pièces affichée et mention de garantie font partie du lot.
## Le club servi comme un particulier
Clubs, collectivités, établissements scolaires et comités d'entreprise commandent en volume, sur devis, et réassortissent chaque saison. La demande de devis et la commande rapide par référence ouvrent ce canal que la plupart des boutiques de sport ne servent tout simplement pas.
---
### Nos meilleurs modules PrestaShop pour vendre des cosmétiques
_Source :_
> Avis vérifiés avec résumé IA, échantillon offert au seuil de panier, cross-sell IA pour la routine, contenu personnalisé, badges Made in France, emballage cadeau, vente flash et arrondi solidaire : la sélection complète pour vendre des cosmétiques sur PrestaShop 8 & 9.
## Vendre des cosmétiques : la confiance avant le produit
En beauté, personne n'achète sur la fiche technique. On achète sur ce que disent les autres : une crème inconnue sans avis ne se vend pas, quelle que soit la qualité de sa formule. Les avis vérifiés, avec leurs rich snippets dans Google et un résumé qui donne l'essentiel en trois lignes, sont le premier levier de la cosmétique en ligne.
## Faire essayer sans boutique physique
Le drame du e-commerce beauté : on ne teste ni la texture, ni le parfum, ni la tenue. L'échantillon offert au-delà d'un seuil de panier règle une partie du problème — c'est le classique du secteur, et il fait deux choses à la fois : il pousse le panier vers le seuil, et il met un futur achat entre les mains de la cliente.
## Vendre la routine, pas le produit isolé
Un nettoyant seul rapporte moins qu'une routine. Le cross-sell IA propose le sérum après le nettoyant, la crème après le sérum ; la personnalisation par segment adapte le message au profil et à l'historique. C'est ce qui transforme un achat en habitude mensuelle.
## Origine, cadeau, engagement
La fabrication française est un argument fort en cosmétique : affichée en badge et filtrable, elle devient un critère de navigation. Ajoutez l'emballage cadeau — la beauté s'offre massivement — la vente flash pour les lancements et éditions limitées, et l'arrondi solidaire pour les marques engagées.
---
### Nos meilleurs modules PrestaShop pour vendre des jouets et de la puériculture
_Source :_
> Sécurité CE et avertissements d'âge, GPSR, disponibilité des pièces détachées, indice de réparabilité, liste de naissance, emballage cadeau, cagnotte et badges Made in France : la sélection complète pour vendre des jouets et de la puériculture sur PrestaShop 8 & 9.
## Vendre des jouets : la sécurité n'est pas une option
Un jouet n'est pas un produit comme un autre : il finit entre les mains d'un enfant. Le marquage CE, les avertissements d'âge (0-3 ans, petites pièces), les mentions de sécurité ne sont pas des ornements de fiche produit — ce sont des obligations. Les afficher au bon endroit, correctement, c'est la première chose à régler avant même de penser à vendre.
Le GPSR complète le tableau : responsable UE, traçabilité, avertissements. Sur le jouet, il s'ajoute à la réglementation sectorielle, il ne s'y substitue pas.
## La durabilité, désormais affichée
Disponibilité des pièces détachées, indice de réparabilité : la loi impose d'afficher ces informations, y compris sur les jouets et les articles de puériculture durables — poussettes, porteurs, jouets d'éveil électroniques. Deux modules, et l'obligation est couverte proprement sur chaque fiche.
## Le cœur du métier : le cadeau
L'essentiel de vos ventes sont des cadeaux : anniversaires, naissances, Noël. Une boutique de jouets qui ne propose ni liste de naissance, ni emballage cadeau, ni cagnotte laisse l'occasion — et la valeur — à la concurrence. Trois modules transforment le panier en cadeau, et le proche en client.
## Rassurer le parent qui hésite
Un parent regarde d'où vient le jouet et qui le garantit. Les badges Origine France et Made in UE, affichés et filtrables, lèvent le doute au moment décisif.
---
### Nos meilleurs modules PrestaShop pour vendre des pièces auto
_Source :_
> Sélecteur de véhicule année/marque/modèle avec espace Mon Garage, disponibilité des pièces détachées L111-4, garantie légale deux ans, GPSR, commande rapide B2B, devis flotte, livraison encombrant et prise de rendez-vous atelier : la sélection complète pour vendre des pièces auto sur PrestaShop 8 & 9.
## Vendre des pièces auto : une seule question compte
En pièces auto, tout commence par une seule question : est-ce que ça va sur ma voiture ? Y répondre mal, c'est un retour garanti — et un retour de pièce coûte deux fois : le transport et la marchandise remise en stock. Le sélecteur de véhicule par année, marque et modèle est la seule réponse sérieuse.
## La pièce a ses obligations
Disponibilité des pièces détachées, garantie légale de deux ans, GPSR sur les pièces importées : le secteur cumule les obligations d'affichage. Trois modules les posent proprement sur chaque fiche produit.
## Le garage n'achète pas comme un particulier
Un professionnel ne navigue pas dans les catégories : il tape sa référence. Commande rapide par SKU, import CSV et réachat depuis l'historique — plus la demande de devis PDF pour les flottes et les ateliers.
## Pneus, carrosserie et pose
Pneus, pare-chocs, échappement : de l'encombrant qui réclame des conditions d'accès demandées au checkout. Et la prise de rendez-vous atelier réunit la pièce et sa pose au même endroit.
---
### Nos meilleurs modules PrestaShop pour vendre des produits personnalisés et sur-mesure
_Source :_
> Personnalisation gravure, texte et image avec aperçu live, configurateur de produit par étapes, box builder mix and match, nomenclatures d'assemblage et commande d'échantillons : la sélection sur-mesure pour PrestaShop 8 & 9.
## Le produit que le client fabrique avec vous
Un produit personnalisé ne se compare pas sur Google Shopping : il n'existe que chez vous. Gravure, texte, configuration par étapes ou coffret composé, la personnalisation sort la boutique de la guerre des prix.
## De la gravure au configurateur complet
La personnalisation simple (texte, image, gravure avec aperçu live) couvre les cadeaux et objets marqués. Le configurateur par étapes gère les produits techniques à options et impacts prix. Le box builder laisse le client composer son coffret en mix and match.
## Et en coulisses, l'assemblage
Les nomenclatures (BOM) décomptent les composants au bon moment, et la commande d'échantillons convertit les acheteurs qui hésitent devant un produit qu'ils ne peuvent pas toucher.
---
### Nos meilleurs modules PrestaShop pour vendre des produits pour animaux
_Source :_
> Personnalisation par profil d'animal, avis vérifiés, comparatif des compositions, friandises offertes au seuil de panier, cross-sell IA, créneau de toilettage, arrondi solidaire pour les refuges et commande rapide B2B pour les éleveurs : la sélection complète pour vendre des produits pour animaux sur PrestaShop 8 & 9.
## Vendre des produits pour animaux : on achète pour un animal, pas pour soi
En animalerie, le client n'achète jamais pour lui. Il achète pour un chien ou un chat, avec un âge, un poids, une race et parfois des intolérances. Un catalogue qui n'adapte rien à ce profil le laisse seul devant trois cents sacs de croquettes.
## Sur l'alimentation, c'est la santé qui est en jeu
Composition, taux de protéines, provenance : les maîtres lisent les étiquettes et les avis. Les avis vérifiés et un comparatif des compositions ne sont pas ici des fonctions de confort, ce sont l'aide à la décision.
## Le panier grossit avec l'échantillon et l'accessoire
Un paquet de friandises offert au-delà d'un seuil de panier fait essayer et revenir ; le cross-sell IA complète les croquettes par une friandise, une gamelle ou un jouet.
## Toilettage, refuges et professionnels
Beaucoup d'animaleries proposent du toilettage : la prise de rendez-vous réunit produit et service. L'arrondi solidaire au profit des refuges parle à un public qui aime ses animaux. Et éleveurs, pensions, refuges et cabinets achètent en volume — un canal professionnel qu'ouvre la commande rapide par référence.
---
### Nos meilleurs modules PrestaShop pour vendre des vêtements et de la mode
_Source :_
> Conseiller de taille IA, guide des tailles de référence, recherche visuelle & shop the look, cross-sell IA, badges Made in France, garantie légale 2 ans, GPSR et emballage cadeau : la sélection complète pour vendre de la mode et du textile sur PrestaShop 8 & 9.
## Vendre de la mode : le secteur qui vit avec les retours
La mode a un ennemi que les autres secteurs n'ont pas : le retour. On commande deux tailles, on en renvoie une — quand ce n'est pas les deux. Aider le client à choisir la bonne taille, inspirer la tenue complète, et poser le cadre provenance et conformité : voilà ce qui fait vendre le textile sans se noyer sous les retours.
## La taille : la première bataille
La taille est la première cause de retour dans la mode. Un conseiller de taille IA recommande la taille à partir des mensurations ; un guide des tailles clair sert de référence. Ensemble, ils réduisent le « je prends deux tailles pour être sûr ».
## Inspirer la tenue, pas vendre la pièce
Une pièce isolée se vend moins qu'une tenue. La recherche visuelle et le « shop the look » IA permettent au client de trouver des articles similaires et de compléter sa tenue ; le panier sticky avec cross-sell IA propose l'accessoire assorti au bon moment.
## Provenance, cadre légal, cadeau
Dans le textile, l'origine française fait vendre : badges Origine France et Made in UE, affichés et filtrables. Et le cadre : garantie légale 2 ans, GPSR sur les produits de consommation, plus l'emballage cadeau pour les nombreux cadeaux de mode.
---
### Nos meilleurs modules PrestaShop pour vendre du matériel médical
_Source :_
> Accès réservé aux pros, commande rapide de consommables, comptes multi-utilisateurs, devis, facturation mensuelle consolidée, validation VIES, relances d'impayés et livraison d'objets lourds : la sélection complète pour vendre du matériel médical aux professionnels sur PrestaShop 8 & 9.
## Vendre du matériel médical : vous ne vendez pas à des particuliers
Une boutique grand public encaisse, expédie, et c'est réglé. Une boutique de matériel médical vend à des cabinets, des cliniques, des pharmacies, des EHPAD — des acheteurs professionnels avec leurs propres règles : un catalogue en partie réservé, des commandes récurrentes de consommables, plusieurs personnes qui commandent sous le même toit, une comptabilité qui attend une facture mensuelle et l'autoliquidation de TVA. Le checkout grand public ne sait rien faire de tout ça.
Et pendant ce temps, l'équipement — lit médicalisé, fauteuil roulant, table d'examen — est lourd et volumineux : la livraison peut échouer au pied de l'immeuble, exactement comme pour le mobilier.
## L'accès d'abord : réservez le catalogue pro
Une partie de votre catalogue ne devrait pas être visible ou commandable par le premier visiteur venu. Une modale bloquante en mode « pro de santé » réserve ces références aux visiteurs qui confirment leur qualité, tout en laissant le reste de la boutique ouvert. C'est le premier réglage à poser : il conditionne tout le reste.
## Le compte professionnel : commander, facturer, relancer
Un professionnel ne commande pas comme un particulier. Il réachète les mêmes consommables chaque mois, il a plusieurs acheteurs dans son équipe, il veut un devis pour l'équipement, une facture mensuelle consolidée, l'autoliquidation de TVA s'il est dans l'UE — et il paie souvent en retard. Cinq modules couvrent cette chaîne de bout en bout, sans ressaisie ni second site.
## Et l'équipement, lui, est lourd
Le formulaire de conditions d'accès demande étage, ascenseur, largeur de porte au checkout, pour que votre logistique sache avant d'expédier un lit ou un fauteuil s'il faut deux livreurs. C'est le même levier que dans le mobilier, appliqué à votre gamme d'équipement.
---
### Nos meilleurs modules PrestaShop pour vendre du mobilier
_Source :_
> Formulaire de livraison objets lourds, expédition partielle, garantie légale, pièces détachées L111-4, indice de réparabilité, GPSR, badges Made in France et devis B2B : la sélection complète pour vendre du mobilier sur PrestaShop 8 & 9.
## Vendre du mobilier en ligne : deux problèmes que les autres n'ont pas
Une boutique de mode rate parfois une taille. Une boutique de mobilier rate des livraisons entières : un canapé d'angle qui ne passe pas la cage d'escalier, une armoire au quatrième sans ascenseur, un camion qui ne peut pas approcher du bâtiment. Chaque échec coûte un second passage transporteur, parfois un monte-meuble commandé en urgence — et presque toujours le client.
Et pendant que la logistique se complique, la réglementation s'empile : garantie légale de conformité, disponibilité des pièces détachées (article L111-4), indice de durabilité, exigences GPSR sur les meubles importés. Le mobilier cumule des obligations que la plupart des e-commerçants n'ont jamais croisées.
## La livraison d'abord
La cause n°1 des livraisons de meubles qui échouent n'est pas le transporteur : c'est l'information manquante. Personne n'a demandé au client s'il y avait un ascenseur, combien de marches, quelle largeur de porte. Le formulaire de conditions d'accès pose ces questions au checkout, au seul moment où le client les connaît par cœur — et votre logistique sait, avant d'expédier, s'il faut deux livreurs ou un monte-meuble.
## La conformité ensuite — elle s'empile sur le mobilier
Garantie légale 2 ans sur chaque fiche, disponibilité des pièces détachées affichée produit par produit, indice de durabilité, coordonnées fabricant GPSR sur l'importé : quatre obligations distinctes, quatre affichages distincts. Les modules de cette sélection les couvrent sans ressaisie, directement depuis vos fiches produits.
## Et le B2B, souvent oublié
Hôtels, restaurants, bureaux, collectivités : le mobilier est un des rares secteurs où le B2C et le contract cohabitent sur la même boutique. Un simple bouton « demander un devis » qui transforme le panier en PDF ouvre ce canal — sans deuxième site, sans échange d'emails interminable.
---
### Nos meilleurs modules PrestaShop pour vendre du vin et de l'épicerie fine
_Source :_
> Vérification d'âge en mode alcool, badges Made in France, assurance transport, emballage cadeau, cagnotte, vente flash à compte à rebours, cross-sell IA et arrondi solidaire : la sélection complète pour vendre du vin et de l'épicerie fine sur PrestaShop 8 & 9.
## Vendre du vin : tout commence par l'âge
Vendre du vin et des spiritueux, c'est d'abord vérifier l'âge à l'entrée. Une modale bloquante en mode alcool exige la confirmation avant que le catalogue d'alcool ne soit accessible. Ce n'est pas une formalité mais une obligation — et le premier réglage qui doit être en place.
## Une bouteille fragile qui voyage cher
Le verre voyage mal. Sans assurance transport, chaque colis cassé est une perte sèche — et un client mécontent. L'upsell d'assurance au checkout couvre la bouteille fragile.
## Le terroir, premier argument
L'origine fait vendre le vin. Les badges et filtres Origine France et Made in UE transforment l'origine et l'élaboration en critères de navigation — votre atout n° 1, enfin visible.
## Cadeau, cagnotte, vente flash : les occasions du vin
Le vin s'offre et se vend par allocations. L'emballage cadeau, une cagnotte pour une bouteille de prestige et une vente flash à compte à rebours captent ces occasions ; le cross-sell IA propose la seconde cuvée ou l'accessoire, et l'arrondi solidaire ajoute un beau geste à l'achat.
---
### Nos meilleurs modules PrestaShop pour vendre en B2B
_Source :_
> Commande rapide par SKU et CSV, demande de devis, devis PDF express, comptes multi-utilisateurs avec rôles et connexion en tant que client : la sélection complète pour vendre en B2B sur PrestaShop 8 & 9.
## Le B2B n'est pas du B2C avec des prix HT
L'erreur la plus courante consiste à prendre la boutique B2C, masquer la TVA, et appeler ça « espace pro ». Or l'acheteur professionnel **n'achète pas — il s'approvisionne**. Et l'approvisionnement obéit à des règles complètement différentes.
Il connaît ses références par cœur. Il ne veut pas naviguer. Il commande la même chose tous les mois. Il a besoin d'un devis avant d'avoir le droit d'acheter. Et souvent, la personne qui commande n'est pas celle qui paie.
## Les quatre frictions qui tuent le B2B
**Le catalogue qu'il faut fouiller.** Votre client a quarante références dans un tableur. L'obliger à les chercher une par une est une insulte.
**Le devis qui manque.** Dans beaucoup d'entreprises, aucune commande ne se déclenche sans devis préalable. Pas de devis, pas de commande — c'est aussi simple que ça.
**Le compte unique.** Les achats commandent, la comptabilité paie, le patron valide. Un seul identifiant pour trois personnes est une impasse organisationnelle.
**La commande par téléphone.** Quand votre client appelle au lieu de commander, votre boutique a échoué — et vous payez le temps de votre commercial pour compenser.
---
### Nos meilleurs modules PrestaShop pour vendre par abonnement et créer du revenu récurrent
_Source :_
> Abonnements Stripe, commandes récurrentes programmées, espace membre avec paywall, alertes retour en stock et baisse de prix : la sélection pour construire un revenu prévisible sur PrestaShop 8 & 9.
## Le chiffre d'affaires qui revient tout seul
Une vente ponctuelle repart de zéro chaque mois. Un abonnement, une commande programmée ou un espace membre transforment le même client en revenu prévisible : vous savez le 1er du mois ce que le 30 rapportera.
## Trois mécaniques, un même objectif
Le paiement récurrent Stripe pour les produits consommables, la commande programmée pour le réassort sans engagement, le contenu payant pour monétiser votre expertise. Les trois se combinent sur une même boutique PrestaShop 8 ou 9.
## Et pour les clients pas encore prêts
L'alerte retour en stock et l'alerte baisse de prix capturent l'intention d'achat au moment où elle existe, puis la convertissent quand les conditions sont réunies. Un revenu différé plutôt qu'une visite perdue.
---
### Nos meilleurs plugins IA WooCommerce pour aider vos clients à choisir
_Source :_
> Essayage virtuel, recherche sémantique, FAQ IA et photo produit IA : notre sélection classée de plugins IA pour WooCommerce — choisis pour ce qui réduit les retours, pas pour ce qui génère du texte.
## L'IA ne fait pas vendre plus — elle fait vendre moins deux fois
C'est l'inversion utile. Le vrai coût d'un client qui hésite n'est pas la vente perdue : c'est **la vente que vous faites deux fois** — une à l'achat, une au retour. Aller, retour, contrôle, remise en stock — et la marge a disparu.
## La mauvaise IA écrit. La bonne répond
Une IA qui génère vos descriptions à la chaîne produit surtout du texte que personne ne lit — et que Google reconnaît pour ce qu'il est. _L'IA utile n'écrit pas votre fiche : elle répond à la question précise que le client se pose devant elle._
## Et la recherche qui ne trouve rien
« Aucun résultat » n'est pas un état technique. C'est une vente perdue horodatée. Une recherche par mots-clés ne comprend pas l'intention : celui qui tape « clavier silencieux pour bureau » ne cherche pas un mot — il cherche une propriété.
---
### Nos meilleurs plugins Shopware pour créer une urgence crédible
_Source :_
> Compte à rebours réel, précommande et liste d'attente, alerte de retour en stock : notre sélection classée de plugins Shopware pour l'urgence — celle qui marche parce qu'elle est vraie.
## La rareté inventée n'est pas du marketing — c'est un manquement
Un compte à rebours qui redémarre une fois expiré. Un « plus que 2 en stock » qui reste éternellement à 2. **Ce ne sont pas des tactiques agressives, ce sont des pratiques commerciales trompeuses** — et la réglementation européenne est explicite, avec des amendes calculées sur le chiffre d'affaires.
## Et l'amende n'est pas le plus cher
Le plus cher, c'est que le client s'en aperçoive. Celui qui a compris que votre compte à rebours ment ne croira pas non plus le vrai. _Vous avez dévalué votre propre urgence._
## La bonne nouvelle : la rareté réelle suffit
Une vente qui se termine vraiment. Un stock qui baisse vraiment. Une liste d'attente qui existe vraiment. Ça marche mieux — parce que c'est vrai, et parce que vous pourrez recommencer.
---
### Nos meilleurs plugins Shopware pour être visible dans ChatGPT et les moteurs IA
_Source :_
> llms.txt et schéma AEO, maillage interne automatique et gestion des 301/404 : notre sélection classée de plugins Shopware pour la visibilité IA — pour que ChatGPT, Perplexity et Claude sachent ce que vous vendez.
## Un front découplé est presque invisible pour un modèle de langage
C'est le paradoxe Shopware. Votre API est propre, votre catalogue structuré — mais un modèle ne lit pas une API. Il lit la page qu'on lui sert. **Et si votre storefront est découplé, il reçoit souvent une coquille sans contenu : prix, variations et disponibilité chargent en JavaScript.**
## La citabilité n'est pas une question de classement
Un assistant ne classe pas. Il _sélectionne_, résume et attribue à _une_ source. Pour être choisi, vos données doivent être structurées sans ambiguïté — pas jolies, mais lisibles par la machine.
## Et le maillage interne décide de ce qui est trouvé tout court
Un modèle suit les liens pour comprendre votre catalogue. Pages orphelines, 404 mortes, aucun maillage : ce qui n'est pas lié n'existe presque pas pour la machine — aussi bien écrit soit-il.
---
### Nos meilleurs plugins Shopware pour fidéliser vos clients
_Source :_
> WhatsApp, push web, alerte de retour en stock et programme de points : notre sélection classée de plugins Shopware pour la fidélisation, en commençant par le canal.
## Un client qui achète une fois n'est pas un client — c'est une transaction
C'est la distinction qui change tout. L'acquisition vous a coûté de l'argent : pub, remise, temps. **Si le deuxième achat n'arrive jamais, vous n'avez jamais amorti ce coût.** Le premier achat paie l'acquisition ; le deuxième est le bénéfice.
## Et un programme de fidélité n'est pas l'outil numéro un
Il récompense souvent ceux qui seraient revenus de toute façon. Le vrai levier est plus proche, plus banal : _une raison de revenir, et un canal pour la transmettre_. Les points viennent après.
## L'erreur la plus coûteuse : attendre le prochain achat sans pouvoir le déclencher
Sans canal direct, le retour dépend du fait que le client se souvienne tout seul. Ce n'est pas un plan — c'est un espoir.
---
### Nos meilleurs plugins Shopware pour la collecte d'emails
_Source :_
> Popup avec timing, push web et alerte de retour en stock : notre sélection classée de plugins Shopware pour la collecte d'emails — l'audience propre qu'on ne peut pas vous éteindre.
## Un popup qui apparaît immédiatement n'est pas un canal — c'est une porte qu'on claque
C'est l'erreur la plus fréquente. Une fenêtre newsletter qui surgit à la première seconde demande son email à quelqu'un avant qu'il ait une raison de le donner. **Vous ne collectez pas une adresse — vous entraînez un réflexe de fermeture.**
## Et un email acheté n'est pas une audience
C'est une location. Tant que vous payez de la pub, les visiteurs viennent ; dès que vous arrêtez, ils disparaîvent. _Votre propre liste est la seule chose qui vous appartient_ — le seul canal qu'aucun algorithme ne peut éteindre.
## La bonne question n'est pas « comment collecter », c'est « quand »
Après le premier regard sur un produit. À la sortie avec un panier plein. Quand un article est épuisé. Le moment décide plus que l'offre.
---
### Nos meilleurs plugins Shopware pour la facture électronique
_Source :_
> ZUGFeRD et XRechnung conformes à EN 16931, proforma et connecteur ERP : notre sélection classée de plugins Shopware pour la facture électronique — en commençant par la phrase qui prend tout le monde de court.
## Un PDF n'est pas une facture électronique
C'est la phrase qui prend la plupart des boutiques de court. Une facture PDF envoyée par email est un _document numérique_ — pas une facture électronique au sens de la norme. **Une facture électronique est structurée : du XML, lisible par une machine, conforme à la norme EN 16931.** XRechnung ou ZUGFeRD (l'équivalent allemand du Factur-X).
## Et en Allemagne, il faut déjà pouvoir en recevoir
L'obligation de _recevoir_ des factures B2B structurées s'applique déjà. L'obligation de les _émettre_ arrive par paliers dans les années qui suivent — et celui qui commence à ce moment-là commence dans l'urgence.
## Shopware ne le produit pas tout seul
La boutique connaît la commande, pas le format. Sans extension, vos clients B2B reçoivent un PDF que leur comptabilité ne sait pas lire — et qu'elle n'aura bientôt plus le droit d'accepter.
---
### Nos meilleurs plugins Shopware pour la vente B2B
_Source :_
> Proforma avec acceptation en ligne, facture électronique et connexion ERP : notre sélection classée de plugins Shopware pour la vente B2B — parce que le B2B n'est pas du B2C avec moins de TVA.
## Le B2B n'est pas du B2C avec moins de TVA
C'est l'erreur qui coûte cher à la plupart des boutiques Shopware. En B2C, une personne décide et paie immédiatement. En B2B, une personne décide, une deuxième valide, une troisième paie — **et personne n'achète avant d'avoir un document à présenter en interne.**
## Ce document, c'est la proforma — et elle manque presque toujours
Sans elle, vous demandez à un acheteur d'appuyer sur un bouton « acheter maintenant » avant que sa comptabilité, son supérieur ou son budget aient donné leur accord. _Vous exigez une décision qu'il n'a pas le droit de prendre seul._
## Et la facture qui suit n'est pas un détail
Elle doit être électronique — XRechnung, ZUGFeRD — et arriver dans son ERP, pas dans sa boîte mail. Le client B2B ne vous juge pas au prix, mais à votre capacité à entrer dans son processus.
---
### Nos meilleurs plugins Shopware pour la vitesse
_Source :_
> Optimisation d'images WebP et AVIF, contrôle de vos propres scripts et PWA : notre sélection classée de plugins Shopware pour la vitesse — pesée, pas mesurée au score.
## Un bon score PageSpeed n'est pas une boutique rapide
C'est le piège où tout le monde tombe. Lighthouse mesure une page de laboratoire, sur une connexion simulée, sans vos cookies, sans votre script de consentement, sans vos tags marketing. **Votre client vit l'inverse : un vrai téléphone, un réseau chargé, tous les scripts à la fois.**
## Et le plus gros poids est presque toujours le même
Les images. Pas votre thème, pas Shopware. _Une seule image produit non optimisée pèse plus lourd que tout votre CSS._ Avant de toucher à autre chose, pesez ce qui passe vraiment sur le fil.
## Et le bon ordre n'est pas celui qu'on croit
Les images d'abord — le plus gros poids. Puis les scripts que vous avez ajoutés vous-même. Ensuite seulement, le réglage fin. Dans l'autre sens, vous optimisez des millisecondes en ignorant des mégaoctets.
---
### Nos meilleurs plugins Shopware pour le design et la personnalisation
_Source :_
> Page builder visuel, mode sombre avec préférence sauvegardée et gestionnaire de snippets : notre sélection classée de plugins Shopware pour le design — parce que la bonne question est qui peut le modifier.
## Une boutique magnifique qu'on ne peut modifier qu'à travers un développeur est une boutique morte
C'est le piège que personne ne voit venir. On construit un thème, il est superbe — et ensuite chaque petit changement coûte un ticket, une attente, un budget. **À la fin, vous ne changez plus rien, parce que c'est trop cher de changer quoi que ce soit.**
## La bonne question n'est pas « à quoi ça ressemble », c'est « qui peut le modifier »
Une landing page pour une campagne, une bannière pour une promo, un bloc saisonnier : ce ne sont pas des projets de développement. _Quand ils le deviennent, votre boutique cesse de bouger._
## Et les détails de design ne sont pas cosmétiques
Un mode sombre qui respecte la préférence du client. Un snippet qui se place exactement où il faut. De petites choses qu'il faut pouvoir changer sans déploiement — sinon on ne les change jamais.
---
### Nos meilleurs plugins Shopware pour le RGPD et les cookies
_Source :_
> Consentement avec vrai blocage, Consent Mode v2 réellement transmis et server-side qui respecte le consentement : notre sélection classée de plugins RGPD pour Shopware — en commençant par le piège de la gestion native.
## Sur Shopware, la gestion des cookies existe — mais elle ne signale rien
C'est le piège que tout le monde manque. Shopware a une gestion native des cookies : groupes, catégories, un bandeau propre. **Mais elle gère en local et ne transmet rien à Google.** Le Consent Mode v2 n'est pas une case à cocher — c'est un câblage.
## Un bandeau qui ne bloque rien est une pièce à conviction
Si votre GTM se déclenche déjà pendant que le bandeau s'affiche, le bandeau documente votre manquement au lieu de l'empêcher. Et il le documente _bien_ : vous connaissiez la règle.
## Et les trois règles réellement sanctionnées
Aucun traceur avant le consentement. Refuser aussi simple qu'accepter. La preuve, conservée. Tout le reste est cosmétique — ces trois-là décident de l'amende.
---
### Nos meilleurs plugins Shopware pour mesurer vos conversions
_Source :_
> Server-side gratuit, consentement avec Consent Mode v2 et GTM avec GA4 e-commerce : notre sélection classée de plugins Shopware pour le tracking — en commençant là où il casse vraiment.
## Sur Shopware, le tracking casse là où personne ne regarde
Pas sur la page d'accueil. Dans le **checkout en plusieurs étapes** — et dans les fronts découplés. Un pixel navigateur qui attend des pages vues ne voit presque plus rien dans une storefront headless. L'achat a eu lieu ; votre pixel ne l'a jamais vu.
## Et la gestion native des cookies n'est pas le Consent Mode
Shopware gère des groupes de cookies — proprement, mais localement. Il _ne signale rien à Google_. Le Consent Mode v2 est une transmission, pas un affichage : ce que le visiteur a choisi doit arriver jusqu'au tag. Sinon vous avez une interface correcte et des données fausses.
## La commande est la seule source qui ne ment pas
Elle est dans votre base, avec le montant, les lignes et l'horodatage. Un événement envoyé depuis là ne peut pas être bloqué — il ne se passe pas dans le navigateur.
---
### Nos meilleurs plugins WooCommerce contre les ruptures et le surstock
_Source :_
> Prévision de la demande, précommande et alerte de retour en stock : notre sélection classée de plugins WooCommerce pour le stock — en partant du fait qu'une rupture est une commande non capturée.
## Une rupture n'est pas une vente perdue — c'est une vente non capturée
C'est la distinction qui décide de votre année. Le client voulait acheter. Il était sur la fiche, avec l'intention. **Ce que vous avez perdu, ce n'est pas l'envie — c'est le moyen de la retenir.**
## Et le surstock n'est pas un problème de place
C'est de l'_argent mort dans un carton_. Chaque palette à l'arrêt, c'est de la trésorerie que vous n'avez pas pour ce qui tourne vraiment. L'entrepôt ne pardonne ni l'un ni l'autre — mais un seul des deux se voit.
## WooCommerce sait ce qu'il vous reste. Pas ce qu'il vous faudra
Le compteur de stock est un temps du passé. Il ne vous dit rien de la saisonnalité, du délai fournisseur ni de la tendance — et ce sont ces trois-là qui décident si vous serez en rupture dans six semaines.
---
### Nos meilleurs plugins WooCommerce pour accélérer votre boutique
_Source :_
> Optimisation d'images (WebP/AVIF), PWA et headless : notre sélection classée de plugins de performance pour WooCommerce — avec le seul poste qui rapporte vraiment sans refonte.
## WooCommerce n'est pas lent. Ce sont vos quarante plugins
WooCommerce est une extension de WordPress — et WordPress a été conçu pour être étendu. Cette extensibilité même, celle qui vous permet d'ajouter une fonction en deux clics, est la cause de votre temps de chargement. **La cause n'est pas un bug : c'est la fonctionnalité.**
## Un score Lighthouse à 100 ne prouve presque rien
Google ne juge pas votre boutique avec le test qui tourne sur votre machine. Il juge des _données terrain_ — de vrais utilisateurs, de vrais téléphones, de vrais réseaux. Un beau score de laboratoire n'est pas une preuve : c'est un réconfort.
## Et le seul poste qui rapporte sans refonte
Ce sont les images. Sur une fiche produit, elles représentent l'essentiel du poids. Ensuite, vous n'achetez plus de la vitesse mais de la **vitesse perçue** — et à un moment, la réponse honnête n'est plus un plugin, c'est une autre architecture.
## Pour aller plus loin
Un guide du blog complète cette sélection : [le guide complet Core Web Vitals](https://www.datafirefly.com/2026/05/01/core-web-vitals-guide-prestashop-wordpress-2026/).
---
### Nos meilleurs plugins WooCommerce pour augmenter votre panier moyen
_Source :_
> Packs, remises sur quantité conditionnées, segmentation et paliers de fidélité : notre sélection classée de plugins WooCommerce pour le panier moyen — mesuré à la marge, pas au tableau de bord.
## Un upsell ne monte pas le panier — il déplace la marge
C'est le calcul que personne ne fait. Un upsell adossé à une remise fait monter le panier moyen et baisser la marge. **Vous avez acheté du chiffre — avec votre propre argent.**
## Le vrai levier, c'est le nombre de décisions
Un pack ne vend pas plus d'articles : il vend _une décision au lieu de trois_. Le client n'a plus à chercher ce qui va avec quoi — et c'est précisément cette recherche qui vous coûtait les deux articles supplémentaires.
## Et la métrique n'est pas le panier moyen
Un panier qui monte parce que vous avez remisé n'est pas un panier qui monte. Le chiffre qui compte, c'est la **marge par commande** — et elle peut baisser pendant que votre tableau de bord est au vert.
---
### Nos meilleurs plugins WooCommerce pour automatiser votre service client
_Source :_
> Agent IA en lecture seule, portail de retours, notifications, FAQ IA et WhatsApp : notre sélection classée de plugins de service client pour WooCommerce — en commençant par les tickets qui n'auraient jamais dû exister.
## Le meilleur ticket est celui qui n'existe pas
Regardez vos tickets de niveau 1 : l'essentiel tient en deux questions. **« Où est ma commande ? » et « Je veux retourner un article. »** Ce ne sont pas des questions de service client. Ce sont des trous dans votre parcours, qui vous reviennent sous forme de tickets.
## Un chatbot traite le symptôme
Il répond plus vite à une question qui n'aurait pas dû exister. C'est utile — mais ce n'est pas la même chose que supprimer la question. _D'abord on bouche le trou. Ensuite on automatise ce qui reste._
## Et une IA autorisée à tout faire n'est pas une bonne IA
Un agent capable de modifier une commande ou de rembourser n'est pas un progrès — c'est un risque avec une fenêtre de chat. Le bon agent lit, répond, et **escalade quand il ne sait pas**. L'aveu est la fonctionnalité.
---
### Nos meilleurs plugins WooCommerce pour être visible dans ChatGPT et les moteurs IA
_Source :_
> llms.txt et schéma AEO, moniteur de visibilité IA sur cinq modèles et recherche sémantique native : la sélection pour être visible dans ChatGPT, Perplexity et Claude — sur WordPress et WooCommerce.
## WordPress est lisible — WooCommerce ne l'est pas
C'est le paradoxe : WordPress produit un HTML propre et sémantique que les modèles lisent sans effort. Mais dès qu'on ajoute WooCommerce, l'essentiel disparaît **dans le JavaScript, dans les variations et dans des prix qui n'apparaissent qu'au clic**.
Un modèle de langage qui lit votre fiche produit voit alors un titre, une image — et pas grand-chose d'autre. Il ne peut pas vous citer, parce qu'il ne sait pas ce que vous vendez.
## La citabilité n'est pas une question de classement
Un assistant ne classe pas. Il _sélectionne_, résume et attribue à _une_ source. Pour être choisi, vos données doivent être structurées sans ambiguïté — pas jolies, mais **lisibles par la machine**.
## Et on n'optimise pas ce qu'on ne mesure pas
Apparaissez-vous dans ChatGPT ? Dans Perplexity ? Sur quelles questions — et avec quel concurrent à côté de vous ? Sans réponse à ces trois questions, vous optimisez à l'aveugle.
## Pour aller plus loin
Deux guides du blog complètent cette sélection : [comprendre l'AEO](https://www.datafirefly.com/2026/05/01/aeo-answer-engine-optimization-avenir-seo/) et [topic clusters et autorité thématique](https://www.datafirefly.com/2026/06/09/topic-clusters-autorite-thematique-seo-semantique-ecommerce-2026/).
---
### Nos meilleurs plugins WooCommerce pour fidéliser vos clients
_Source :_
> Prédiction du churn, paliers de fidélité, WhatsApp, push web et centre de notifications : notre sélection classée de plugins de rétention pour WooCommerce — en commençant par savoir qui s'en va.
## Un programme de fidélité récompense surtout ceux qui allaient revenir
C'est la partie inconfortable. Distribuez des points à tout le monde, et vous distribuez de la marge à vos meilleurs clients — ceux qui auraient commandé sans la moindre remise. **Ce n'est pas de la fidélisation, c'est une remise mieux emballée.**
## La bonne question n'est pas qui est fidèle
C'est _qui est sur le point de partir_. Et ce n'est pas la même liste. Un client qui va churner ressemble encore aujourd'hui à un bon client : il a acheté, il n'a pas réclamé, il a juste… arrêté.
Cette information est déjà dans votre base. Intervalles entre commandes, trajectoire du panier, catégories, retours : WooCommerce enregistre tout — et personne ne le lit.
## La rétention coûte de la marge — alors visez
Chaque point de remise sort de votre marge. Sans connaître la valeur vie de vos segments, vous offrez de l'argent à des clients qui restaient — et vous vous taisez face à ceux qui partent.
---
### Nos meilleurs plugins WooCommerce pour la preuve sociale
_Source :_
> Avis vérifiés avec réponse IA, synthèse IA des avantages/inconvénients et carrousel Google : notre sélection classée de plugins WooCommerce pour la preuve sociale — celle qui convainc parce qu'elle est crédible.
## Un 5,0 parfait vend moins bien qu'un 4,7
C'est la vérité contre-intuitive de la preuve sociale. Une note impeccable ne déclenche pas un achat — elle déclenche un soupçon. **Le client sait que personne n'a que des acheteurs satisfaits, et lit un 5,0 comme filtré, acheté ou faux.**
## Et un avis sans preuve d'achat n'est pas un avis
C'est une opinion. Ce qui fait la différence, ce n'est pas le nombre d'étoiles, c'est de savoir si une vraie commande se trouve derrière. _Un commentaire vérifié à trois étoiles pèse plus lourd que dix cinq étoiles anonymes._
## La bonne question n'est pas « comment collecter de bons avis »
C'est : comment rendre les vrais visibles, crédibles et utiles — y compris les négatifs. Parce que la réponse à un mauvais avis vend plus que le mauvais avis ne coûte.
---
### Nos meilleurs plugins WooCommerce pour le commerce agentique et les agents IA
_Source :_
> Serveur MCP OAuth sur mesure, llms.txt et schémas AEO, suivi de visibilité dans ChatGPT et les moteurs IA, recherche sémantique et agent de service client : la sélection pour vendre aux agents IA sur WooCommerce.
## Le prochain client est un agent
ChatGPT, Claude et Perplexity ne se contentent plus de recommander des produits : ils commencent à chercher, comparer et opérer pour le compte du client. Une boutique WooCommerce qu'un agent ne peut ni lire ni interroger n'existe pas pour ce canal.
## Devenir lisible, puis opérable
llms.txt et les schémas AEO rendent le catalogue lisible pour les modèles de langage. Le serveur MCP avec OAuth expose jusqu'à 40 outils sur mesure : catalogue, stocks, commandes, tout ce qu'un assistant compatible MCP peut appeler avec les droits que vous accordez. La recherche sémantique fait comprendre le catalogue par le sens, pas par le mot-clé.
## Et mesurer le nouveau canal
Le trafic IA apparaît à peine dans les analytics classiques. Le moniteur AEO suit votre visibilité dans les réponses de ChatGPT, Perplexity, Claude, Gemini et Mistral, et l'agent IA de service client répond aux demandes que ce canal génère.
---
### Nos meilleurs plugins WooCommerce pour le RGPD et les cookies
_Source :_
> Consentement avec vrai blocage, Consent Mode v2, server-side qui respecte le consentement et protection des accès : notre sélection classée de plugins RGPD pour WooCommerce — en commençant par la seule question qui compte sur WordPress.
## Sur WordPress, un plugin affiche le consentement — et vingt autres chargent les scripts
C'est le problème structurel que personne ne dit à voix haute. Votre bandeau cookies est un plugin. Votre analytics en est un autre. Votre pixel, un troisième. Votre thème charge une police depuis l'extérieur. **Aucun d'eux ne demande la permission au bandeau.**
## Un bandeau qui ne bloque rien est une pièce à conviction
Si votre analytics tourne déjà pendant que le bandeau s'affiche, le bandeau documente votre manquement au lieu de l'empêcher. Et il le documente _bien_ : vous connaissiez la règle.
## Sur WordPress, une seule question compte : le bandeau entre-t-il dans les autres plugins ?
Il existe un standard prévu exactement pour ça — et la plupart des plugins ne l'implémentent pas. Un bandeau qui ne sait pas retenir votre plugin GA4 ne le retient pas.
---
### Nos meilleurs plugins WooCommerce pour mesurer vos conversions
_Source :_
> Tracking server-side gratuit sans double comptage, GTM Pro, Consent Mode v2 et tableau de bord des marges : la sélection pour bien mesurer vos conversions sur WooCommerce.
## Le tracking WooCommerce est cassé deux fois
La première cassure est la même que partout : **le pixel est bloqué**. Bloqueurs de pub, Safari ITP, iOS. L'achat a eu lieu — votre campagne ne l'a simplement jamais su.
La seconde est propre à WordPress et n'est jamais mentionnée : **vos plugins trackent tous le même événement.** Trois plugins, trois événements d'achat, une seule commande. Vous ne voyez pas plus de ventes — vous voyez les mêmes ventes trois fois. Et vous optimisez contre un chiffre qui n'existe pas.
## Le server-side n'est pas une amélioration — c'est une réparation
L'événement part de votre serveur, pas du navigateur. Aucun bloqueur ne peut le supprimer. Et la commande est remontée _une fois_, parce qu'elle vient de la base de données — pas de trois scripts qui ne se connaissent pas.
## Et non, ça ne vous dispense pas du consentement
Le Consent Mode v2 reste nécessaire. Le server-side règle un problème _technique_. Confondre les deux vous en construit un juridique.
---
### Nos meilleurs plugins WooCommerce pour mettre votre boutique en conformité
_Source :_
> Accessibilité EAA, passeport numérique produit (ESPR), consentement RGPD et empreinte carbone : notre sélection classée de plugins de conformité pour WooCommerce, avec les seuils qui vous concernent — et ceux qui ne vous concernent pas.
## La conformité WooCommerce ne se joue pas dans WooCommerce
C'est le malentendu de départ. L'accessibilité, le RGPD, l'affichage réglementaire : rien de tout ça ne dépend du cœur de WooCommerce. **Ça dépend du HTML que produisent votre thème et vos quarante plugins** — et c'est ce HTML-là que le contrôleur regarde.
Vous pouvez donc être parfaitement à jour côté WooCommerce, et parfaitement non conforme côté rendu. Les deux n'ont rien à voir.
## Et d'abord : êtes-vous seulement concerné ?
Personne ne vous le dira, parce que la peur se vend mieux que la nuance. La directive accessibilité prévoit **une exemption pour les micro-entreprises de services** — en gros, moins de 10 salariés et un chiffre d'affaires modeste — et chaque pays l'a transposée à sa façon.
Avant d'acheter quoi que ce soit, vérifiez votre transposition nationale. C'est gratuit, et ça change tout.
## La conformité n'est pas un coût — c'est une condition d'accès
Le passeport numérique produit (ESPR) ne vise pas les boutiques : il vise _des catégories de produits_. Si vous vendez du textile ou des batteries, l'échéance n'est pas une opinion. Si vous vendez des tasses, vous avez le temps.
---
### Nos meilleurs plugins WooCommerce pour piloter vos prix et vos marges
_Source :_
> Revalorisation en masse avec arrondi psychologique, règles de prix dynamiques, marge réelle par commande et segmentation prédictive : notre sélection de plugins WooCommerce pour piloter les prix au lieu de les subir.
## Un prix n'est pas un réglage, c'est un processus
La plupart des prix WooCommerce datent du jour où le produit a été créé. Depuis, les coûts d'achat, le transport et l'énergie ont bougé. La différence entre ces deux dates sort directement de votre marge, et personne ne la voit.
## Revaloriser sans casser la conversion
Une hausse de 2 à 4 % avec un arrondi psychologique passe sous le seuil d'attention de la plupart des acheteurs. Ce qui se remarque, c'est un prix cassé comme 21,47. La revalorisation en masse traite tout le catalogue en une passe, avec prévisualisation avant application. Les règles de prix prennent ensuite le relais : segments, quantités, périodes.
## Et mesurer la marge, pas le chiffre
WooCommerce affiche le chiffre d'affaires, jamais le profit. On peut vendre plus et gagner moins sans le voir. Le chiffre qui pilote une stratégie de prix, c'est la marge nette par commande, coûts déduits.
---
### Nos meilleurs plugins WooCommerce pour une facturation conforme
_Source :_
> TVA européenne et OSS, export comptable, proforma et connecteur CRM : notre sélection classée de plugins de facturation pour WooCommerce — en commençant par ce qui coûte cher rétroactivement.
## WooCommerce ne produit pas une facture — il produit une confirmation
C'est la première surprise. L'email que reçoit votre client après sa commande est une _confirmation de commande_, pas un document fiscal. Une facture, ça exige une numérotation séquentielle sans trou, des mentions obligatoires, le bon taux de TVA — et ça ne doit plus bouger ensuite.
## Mais le vrai piège n'est pas la facture. C'est la TVA
Il existe un seuil européen pour les ventes transfrontalières aux particuliers. En dessous, vous appliquez votre taux national. Au-dessus, vous devez appliquer **le taux du pays où vit votre client** — à partir de la vente qui a franchi le seuil.
## Et ce jour-là, personne ne vous prévient
WooCommerce ne compte pas. Vous l'apprenez des mois plus tard, quand quelqu'un additionne les chiffres et découvre que vous facturez au mauvais taux depuis.
---
### Nos meilleurs plugins WooCommerce pour vendre à l'international
_Source :_
> TVA européenne, traduction IA (gratuite et Pro) et portail de retours : notre sélection classée de plugins WooCommerce pour vendre à l'étranger — dans l'ordre qui économise de l'argent.
## Traduire n'est pas vendre
Une boutique traduite mais non conforme fiscalement, et non préparée aux retours transfrontaliers, vend une fois — puis perd de l'argent. **La langue, c'est la partie visible. Les parties coûteuses sont invisibles.**
## La traduction automatique n'est pas votre problème
Google ne pénalise pas la traduction automatique en tant que telle : il pénalise le contenu sans valeur. Ce qui vous nuit vraiment, c'est autre chose : _la demi-traduction_. Une fiche en anglais avec les attributs en français, un checkout qui change de langue en cours de route — l'incohérence coûte plus cher que l'accent.
## Et l'ordre n'est pas celui qu'on attend
La TVA d'abord — parce qu'elle joue rétroactivement. Puis la langue. Puis les retours. Dans l'autre sens, vous obtenez une jolie boutique et un redressement.
---
### Nos meilleurs plugins WooCommerce pour vendre en B2B
_Source :_
> Devis, prix par client, proforma et synchronisation CRM : notre sélection classée de plugins B2B pour WooCommerce — en commençant là où la vente se perd vraiment.
## En B2B, la vente ne se perd pas au checkout — elle se perd avant le prix
Un acheteur professionnel ne veut pas payer par carte. Il veut un devis, un délai de paiement, un numéro de commande interne et une facture que sa compta acceptera. **Le bouton « Ajouter au panier » est une hypothèse B2C** — et WooCommerce la fait par défaut.
## Un prix unique pour tout le monde, en B2B, c'est un message
Il dit à votre plus gros client : _vous n'êtes pas spécial ici._ En B2B, le prix n'est pas un nombre, c'est une relation — volume, contrat, groupe client, négociation. Un prix public unique n'est pas un état neutre : c'est une déclaration.
## Et là où ça casse vraiment : la double saisie
Le devis existe dans la boutique. Puis une seconde fois dans le CRM. Puis une troisième en compta. Chaque ressaisie est une erreur qui attend son moment — généralement celui où le client vérifie la facture.
---
## Mentions légales
### Conditions Générales de Vente B2B
_Source :_
> Conditions Générales de Vente B2B — Datafirefly Limited Version 3.1 Effective : 2026-05-10 Langue de référence en cas de divergence : version anglaise 1. Définitions Dans les présentes conditions :…
# Conditions Générales de Vente B2B — Datafirefly Limited
**Version 3.1****Effective : 2026-05-10****Langue de référence en cas de divergence : version anglaise**
---
## 1. Définitions
Dans les présentes conditions :
- **« Datafirefly »** ou **« DF Ltd »** désigne **Datafirefly Limited**, société à responsabilité limitée par actions de droit irlandais, immatriculée au Companies Registration Office (CRO) sous le numéro 810100, dont le siège social est situé 15A Main Street, Blackrock, Dublin, A94 T8P8, Irlande.
- **« Client »** désigne toute personne morale ou professionnelle ayant souscrit un Service Datafirefly via signature électronique d'un devis, acceptation d'une facture, ou souscription en ligne.
- **« Services »** désigne tout produit ou prestation fourni par Datafirefly, incluant sans s'y limiter : modules e-commerce, applications SaaS, intégrations sur mesure, conseil technique, hébergement, formations.
- **« Abonnement »** désigne un Service à facturation récurrente (mensuelle, trimestrielle ou annuelle).
- **« Contrat ferme »** désigne un Abonnement avec engagement de durée minimale (12 mois sauf mention contraire), tel que défini au §6.
- **« Abonnement standard »** désigne un Abonnement résiliable à tout moment sans engagement de durée minimale.
- **« CGV »** désigne les présentes Conditions Générales de Vente B2B.
---
## 2. Objet et acceptation
**2.1** Les présentes CGV régissent l'ensemble des relations contractuelles entre Datafirefly et le Client, à l'exclusion de toute autre condition (notamment les conditions générales d'achat du Client).
**2.2** Le Client reconnaît avoir pris connaissance des présentes CGV et les accepter sans réserve par : (a) signature électronique d'un devis, (b) paiement d'une facture, (c) usage des Services, ou (d) souscription en ligne. L'acceptation peut être prouvée par tout moyen, notamment via le mécanisme de signature électronique avancée (AES) au sens du Règlement eIDAS (UE) n°910/2014.
**2.3** Datafirefly se réserve le droit de modifier les présentes CGV. Toute modification substantielle est notifiée au Client par e-mail au moins trente (30) jours avant son entrée en vigueur. Le Client peut résilier ses Abonnements en cours dans ce délai sans frais ; à défaut de résiliation, les nouvelles CGV s'appliquent.
---
## 3. Services et obligations de Datafirefly
**3.1** Datafirefly s'engage à fournir les Services avec la diligence et la compétence raisonnablement attendues d'un professionnel du secteur, conformément aux dispositions de la **Sale of Goods and Supply of Services Act 1980** (§39, §40 implied warranties).
**3.2** Datafirefly s'efforce de garantir la disponibilité des Services SaaS à hauteur de 99% sur une base mensuelle, hors maintenance planifiée annoncée et cas de force majeure (cf §11).
**3.3** Datafirefly n'est pas responsable des indisponibilités résultant de : (a) panne du Client ou de ses prestataires (hébergement, FAI, navigateur), (b) maintenance planifiée, (c) cas de force majeure, (d) usage non conforme par le Client.
---
## 4. Tarifs et facturation
**4.1** Les tarifs en vigueur sont ceux indiqués sur le devis ou la facture acceptés par le Client. Sauf mention contraire, les tarifs sont **hors taxes (HT)** ; la TVA applicable est ajoutée selon le régime fiscal du Client.
**4.2** Datafirefly Limited bénéficie actuellement du régime de **franchise en base de TVA** (Section 6, VAT Consolidation Act 2010, Ireland) — pas de TVA collectée sur les Services. Cette mention est susceptible d'évoluer si DF Ltd dépasse le seuil de €42 500 et obtient un numéro de TVA intracommunautaire.
**4.3** Sauf mention contraire, les factures sont payables à 30 jours nets à compter de leur date d'émission, par virement bancaire ou via les moyens de paiement proposés (Stripe, Wise).
**4.4** Tout retard de paiement entraîne, de plein droit et sans mise en demeure préalable, des intérêts de retard au taux de la Banque centrale européenne majoré de 8 points de pourcentage, conformément au **Statutory Instrument 580/2012** (transposition de la Directive 2011/7/UE sur les retards de paiement). Une indemnité forfaitaire pour frais de recouvrement de 40 € est également due par facture impayée.
---
## 5. Abonnements standards
**5.1** Un Abonnement standard est résiliable à tout moment par le Client, sans frais ni indemnité.
**5.2** La résiliation prend effet à la fin de la période de facturation en cours. L'accès aux Services correspondants est maintenu jusqu'à cette date.
**5.3** Aucun remboursement au prorata de la période de facturation en cours n'est dû, sauf disposition légale impérative contraire.
**5.4** La résiliation s'effectue par : (a) le portail client Stripe Customer Portal, (b) un e-mail au support `contact@datafirefly.com`, ou (c) tout autre canal contractuellement prévu.
---
## 6. Contrats fermes (engagement à durée déterminée)
**6.1 Définition et engagement.** Un Contrat ferme implique un engagement du Client pour une durée minimale de **douze (12) mois** à compter de la première période facturée. Le type d'engagement est clairement identifié sur le devis signé ou la facture initiale. Par sa signature, le Client reconnaît et accepte expressément cet engagement minimal et ses conséquences en cas de résiliation anticipée.
**6.2 Justification commerciale.** Le Contrat ferme correspond à une allocation de ressources spécifiques par Datafirefly au profit du Client (développements sur mesure, environnements dédiés, intégrations spécifiques, formations, support priorisé). Cette allocation représente un coût engagé que Datafirefly ne peut redéployer sans préjudice. Le Contrat ferme protège ainsi un **intérêt commercial légitime** au sens de la jurisprudence applicable (notamment _Cavendish Square Holding BV v Makdessi_ [2015] UKSC 67, principe adopté en droit irlandais).
**6.3 Frais de résiliation anticipée.** En cas de résiliation par le Client avant l'échéance des 12 mois fermes, le Client doit à Datafirefly une **indemnité de résiliation anticipée** égale au montant des mensualités restant dues sur la période ferme. Calcul : `mensualité × nombre de mois restants jusqu'à la fin de la période ferme`.
> _Exemple :_ Contrat ferme à 199 € HT/mois signé le 1er mars, résilié le 1er mai. Mensualités payées : 2 (mars, avril). Mensualités restant dues : 10. **Indemnité = 10 × 199 € = 1 990 € HT**, exigible à la date de résiliation.
**6.4 Modalités de paiement de l'indemnité.** L'indemnité fait l'objet d'une facture distincte (Facture de Résiliation), exigible à la date de résiliation. Datafirefly peut procéder à un prélèvement automatique sur le moyen de paiement enregistré (carte bancaire via Stripe), conformément au mandat de paiement récurrent accepté lors de la souscription (consentement PSD2).
**6.5 Nature de l'indemnité.** Les Parties reconnaissent expressément que l'indemnité de résiliation anticipée :
(a) **n'est pas une clause pénale** au sens de l'article 1231-5 du Code civil français ni des principes équivalents en droit irlandais ;
(b) constitue une **liquidation conventionnelle des dommages** (liquidated damages) reflétant un coût économique réel pour Datafirefly ;
(c) protège un intérêt commercial légitime de Datafirefly (allocation de ressources sur la base de l'engagement) ;
(d) est proportionnée à cet intérêt et ne représente pas une sanction disproportionnée.
**6.6 Exceptions — résiliation sans frais.** L'indemnité ne s'applique pas en cas de résiliation pour :
(a) **Manquement substantiel de Datafirefly** non remédié dans les trente (30) jours suivant une mise en demeure écrite du Client ;
(b) **Force majeure** d'une durée supérieure à soixante (60) jours consécutifs (cf §11) ;
(c) **Insolvabilité de Datafirefly** : ouverture d'une procédure collective, dissolution, ou cessation d'activité ;
(d) Tout autre motif **expressément reconnu par les dispositions impératives** du droit irlandais ou du droit applicable au Client en B2B.
**6.7 Reconduction tacite.** Sauf résiliation notifiée par écrit (e-mail au support suffit) au moins **trente (30) jours avant l'échéance** de la période ferme initiale, le Contrat ferme est automatiquement reconduit pour des périodes successives de douze (12) mois, chacune soumise aux dispositions du présent §6.
**6.8 Résiliation pour faute du Client.** En cas de manquement du Client à ses obligations (notamment paiement, conformité d'usage), Datafirefly peut suspendre puis résilier le Contrat ferme après mise en demeure infructueuse de quinze (15) jours. Dans ce cas, l'indemnité de résiliation anticipée demeure due.
---
## 7. Propriété intellectuelle
**7.1** Tous les droits de propriété intellectuelle relatifs aux Services (code source, marques, logos, contenus, documentation) demeurent la propriété exclusive de Datafirefly, sous réserve des droits de tiers (logiciels open source, prestataires).
**7.2** Datafirefly concède au Client une **licence d'usage non exclusive, non cessible, limitée à la durée de l'Abonnement**, pour l'utilisation des Services dans le cadre de son activité professionnelle.
**7.3** Le Client conserve la propriété de ses **données et contenus** (Customer Data) hébergés ou traités via les Services. Datafirefly s'interdit toute exploitation à d'autres fins que la fourniture des Services.
---
## 8. Confidentialité
**8.1** Chaque Partie s'engage à conserver confidentielles toutes informations non publiques échangées dans le cadre de l'exécution du contrat (informations commerciales, techniques, financières, données clients).
**8.2** Cette obligation perdure pendant la durée du contrat et **trois (3) années** après son terme.
**8.3** L'obligation ne s'applique pas aux informations : (a) déjà publiques, (b) connues de la Partie réceptrice avant divulgation, (c) divulguées légitimement par un tiers, (d) exigées par autorité judiciaire ou administrative.
---
## 9. Protection des données personnelles (RGPD)
**9.1** Les Parties respectent le **Règlement (UE) 2016/679 (RGPD)** et la **Data Protection Act 2018** (Ireland).
**9.2** Lorsque Datafirefly traite des données personnelles pour le compte du Client (Sous-traitant au sens RGPD), un **Accord de Traitement de Données (DPA)** distinct est conclu, conforme à l'article 28 RGPD.
**9.3** Datafirefly met en place les mesures techniques et organisationnelles appropriées (chiffrement, contrôle d'accès, journalisation, sauvegardes) pour protéger les données personnelles traitées.
**9.4** Le Client garantit avoir le droit de transmettre les données personnelles à Datafirefly et avoir obtenu les consentements nécessaires auprès des personnes concernées.
---
## 10. Limitation de responsabilité
**10.1 Plafond de responsabilité.** La responsabilité totale cumulée de Datafirefly envers le Client, tous chefs de préjudice confondus, est limitée au **montant des sommes effectivement payées par le Client à Datafirefly au cours des douze (12) mois précédant le fait générateur** du dommage.
**10.2 Exclusion de dommages indirects.** Datafirefly n'est en aucun cas responsable des dommages **indirects, immatériels ou consécutifs** : perte de chance, perte de bénéfices, perte de chiffre d'affaires, perte de clientèle, perte de données (sauf faute lourde caractérisée), atteinte à l'image.
**10.3 Exceptions.** Les limitations du présent §10 ne s'appliquent pas en cas de : (a) faute lourde ou intentionnelle de Datafirefly, (b) atteinte à la vie ou à l'intégrité corporelle, (c) violation des obligations du §9 (RGPD) imputable à Datafirefly.
**10.4 Mitigation.** Le Client s'engage à prendre toutes mesures raisonnables pour limiter ses dommages (sauvegardes, plan de continuité, alertes).
---
## 11. Force majeure
**11.1** Aucune Partie n'est responsable d'un manquement à ses obligations résultant d'un cas de **force majeure** au sens de la jurisprudence applicable, notamment : catastrophe naturelle, guerre, attentat, pandémie, grève générale, défaillance majeure des infrastructures publiques (électricité, télécommunications), décision gouvernementale, panne majeure d'un fournisseur tiers critique (AWS, Stripe, etc.) hors du contrôle raisonnable de la Partie concernée.
**11.2** La Partie affectée notifie l'autre Partie sans délai. Les obligations affectées sont suspendues pour la durée de l'événement.
**11.3** Si la force majeure perdure au-delà de **soixante (60) jours consécutifs**, chaque Partie peut résilier le contrat sans indemnité, par notification écrite.
---
## 12. Notifications
**12.1** Toute notification au titre des présentes CGV est valablement effectuée par e-mail :
- Vers Datafirefly : `contact@datafirefly.com` (avec copie `sasha@datafirefly.com` pour les notifications formelles).
- Vers le Client : à l'adresse e-mail communiquée lors de la souscription ou à l'adresse e-mail principale du compte.
**12.2** Une notification est réputée reçue le jour ouvré suivant son envoi, sauf preuve contraire (rejet de remise serveur).
---
## 13. Droit applicable et juridiction
**13.1** Les présentes CGV sont régies par le **droit irlandais** (Irish law), à l'exclusion de ses règles de conflit de lois.
**13.2** Tout litige relatif à l'interprétation, l'exécution ou la résiliation des présentes CGV est soumis à la **compétence exclusive des tribunaux de Dublin, Irlande**, après tentative préalable de résolution amiable d'une durée de trente (30) jours.
**13.3** Les Parties peuvent convenir d'un mode alternatif de résolution des différends (médiation, arbitrage CCI Dublin) par accord écrit.
---
## 14. Divisibilité
**14.1** Si une stipulation des présentes CGV est jugée invalide, illégale ou inapplicable par une juridiction compétente, cette stipulation est réputée non écrite et les autres stipulations conservent leur plein effet.
**14.2** Les Parties s'efforcent de bonne foi de remplacer la stipulation invalide par une stipulation valable produisant des effets économiques équivalents.
---
## 15. Intégralité de l'accord
**15.1** Les présentes CGV, ensemble avec le devis signé et toute annexe (DPA, SLA, conditions particulières), constituent l'**intégralité de l'accord** entre Datafirefly et le Client concernant les Services.
**15.2** Toute modification doit faire l'objet d'un écrit signé par les Parties (un échange d'e-mails confirmé suffit pour les modifications mineures).
**15.3** En cas de divergence entre les CGV et un devis ou contrat particulier, le devis ou contrat particulier prévaut, sous réserve qu'il soit signé par un représentant habilité de Datafirefly.
---
## 16. Mentions légales
**Datafirefly Limited**
Société à responsabilité limitée par actions de droit irlandais (Private Company Limited by Shares)
Numéro CRO : **810100**
Siège social : 15A Main Street, Blackrock, Dublin, A94 T8P8, Irlande
E-mail : `contact@datafirefly.com`
Site web : `https://datafirefly.com`
Régime TVA : franchise en base (Section 6, VAT Consolidation Act 2010)
Capital social : 100 € (100 actions × 1 €)
Directeur : Sasha El Mogherbi (IPN 5033475)
---
_Dernière mise à jour : 2026-05-10 — Version 3.1__Précédente version (v3.0, 2026-04-18) : archivée, applicable aux contrats signés avant le 2026-05-10._
---
### Legal
_Source :_
> Legal documentation — Datafirefly This section centralises Datafirefly Limited's legal pages applicable to the Datafirefly Ads platform. Privacy Policy Terms of Service The interactive (FR + EN) versions are available…
# Legal documentation — Datafirefly
This section centralises Datafirefly Limited's legal pages applicable to the Datafirefly Ads platform.
- [Privacy Policy](/legal/privacy/)
- [Terms of Service](/legal/terms/)
The interactive (FR + EN) versions are available inside the application:
- [Datafirefly Ads — Terms of Service](https://ads.datafirefly.com/terms)
- [Datafirefly Ads — Privacy Policy](https://ads.datafirefly.com/privacy)
---
**Datafirefly Limited** — CRO 810100 — 15A Main Street, Blackrock, Dublin, A94 T8P8, Ireland.
Contact: [contact@datafirefly.com](mailto:contact@datafirefly.com)
---
### Mentions légales
_Source :_
> Mentions légales Éditeur du site DataFirefly LimitedSociété privée à responsabilité limitée (Private Limited Company)Enregistrée en Irlande sous le numéro CRO : 810100Siège social : Blackrock, Co. Dublin, Irlande Contact :…
# Mentions légales
## Éditeur du site
**DataFirefly Limited**
Société privée à responsabilité limitée (Private Limited Company)
Enregistrée en Irlande sous le numéro CRO : **810100**
Siège social : Blackrock, Co. Dublin, Irlande
Contact : [contact@datafirefly.com](mailto:contact@datafirefly.com)
## Hébergeur
**o2switch**
Société par actions simplifiée au capital de 100 000 €
222-224 Boulevard Gustave Flaubert, 63000 Clermont-Ferrand, France
SIRET : 510 909 807 00032
Site web : [www.o2switch.fr](https://www.o2switch.fr)
## Propriété intellectuelle
L'ensemble du contenu de ce site (textes, images, graphismes, logos, icônes, sons, logiciels, etc.) est la propriété exclusive de DataFirefly Limited et est protégé par les lois françaises et internationales relatives à la propriété intellectuelle. Toute reproduction, représentation, modification, publication ou adaptation de tout ou partie des éléments du site, quel que soit le moyen ou le procédé utilisé, est interdite sans autorisation écrite préalable de DataFirefly Limited.
## Modules et logiciels
Les modules commercialisés par DataFirefly Limited sont des œuvres logicielles protégées par le droit d'auteur. Leur acquisition confère à l'acheteur une licence d'utilisation personnelle, non exclusive et non transférable. Toute revente, redistribution ou décompilation est strictement interdite.
## Limitation de responsabilité
DataFirefly Limited s'efforce d'assurer l'exactitude et la mise à jour des informations diffusées sur ce site. Toutefois, elle ne peut garantir l'exactitude, la précision ou l'exhaustivité des informations mises à disposition. DataFirefly Limited décline toute responsabilité pour toute imprécision, inexactitude ou omission portant sur des informations disponibles sur ce site.
## Droit applicable
Le présent site et les présentes mentions légales sont soumis au droit irlandais. Tout litige relatif à l'utilisation du site sera soumis à la compétence exclusive des juridictions irlandaises.
---