Révolution financière : reporting avancé pour les propriétaires de boutiques PrestaShop

Dernière révision en juin 2026, les chemins des champs du back-office et les noms de tables ci-dessous s’appliquent à PrestaShop 1.7, 8 et 9 ; les libellés de menu varient légèrement selon les versions, si bien que le libellé exact dans votre administration peut différer.

PrestaShop vous indiquera sans problème combien vous avez vendu. Ouvrez Statistiques (le contrôleur AdminStats, dans le menu Tableau de bord / Statistiques selon votre version) et vous obtenez les ventes dans le temps, les produits les plus vendus, les répartitions par transporteur, un tableau de bord ventes-commandes et une liste triable des meilleures ventes. Ce qu’aucun de ces écrans ne vous donnera, c’est le seul chiffre qui décide si votre boutique est réellement une entreprise : combien d’argent vous avez conservé. Le chiffre d’affaires est ce que PrestaShop mesure par défaut. Le bénéfice est ce que vous gardez vraiment, et l’écart entre les deux est bien plus important que ne l’imaginent la plupart des marchands. Cet article explique comment combler cet écart : le reporting financier dont une boutique PrestaShop a besoin pour piloter par la marge plutôt que par le chiffre d’affaires, ce que le back-office vous offre, où il s’arrête, et comment obtenir le bénéfice réel par produit, par commande et par client.

Posons d’abord une limite, pour rester dans le bon périmètre. Il s’agit ici de reporting financier, l’argent qui entre, l’argent qui sort, et ce qu’il reste. Ce n’est pas de l’analyse web. D’où viennent vos visiteurs, comment ils se comportent sur la page, quelle source de trafic convertit, c’est une autre discipline, que nous couvrons dans ce qu’il faut suivre et ce qu’il faut ignorer ainsi que dans les métriques GA4 qui comptent vraiment. Ici, nous restons sur le compte de résultat.

Pourquoi les statistiques natives de PrestaShop ne peuvent pas vous dire si vous êtes rentable

Le moteur de statistiques natif est construit autour du chiffre d’affaires et des volumes, parce que ce sont les données qui vivent proprement dans les tables de commandes. Quand PrestaShop enregistre une vente, il stocke le prix payé par le client, la taxe, les frais de livraison facturés et l’état de la commande. En revanche, il ne stocke pas, sous une forme exploitable pour le reporting, ce que cette commande vous a coûté. Ce coût est réparti dans des endroits que les écrans de statistiques ne recoupent jamais :

• Coût d’achat. PrestaShop dispose bien d’un champ pour cela, wholesale_price sur le produit, défini dans Catalogue → Produits → [produit] → Prix → Prix d’achat, stocké dans ps_product et copié dans ps_order_detail.original_wholesale_price au moment de la vente. Le problème : presque personne ne le renseigne, et même lorsqu’il l’est, les endroits natifs où il apparaît, le chiffre de marge bénéficiaire dans Statistiques → Statistiques du catalogue et la colonne de bénéfice par produit dans Statistiques → Produits les plus vendus / Détails du produit. Restent des vues agrégées ou par produit, jamais par commande ni par client.
• Frais de traitement des paiements. Les 1,4 à 3 % conservés par Stripe, PayPal ou le prestataire carte bancaire n’entrent jamais dans PrestaShop. Une commande de 100 € est enregistrée comme 100 € de chiffre d’affaires, même si seulement 97,10 € arrivent sur votre compte.
• Coût réel de livraison. La commande stocke ce que le client a payé pour la livraison, jamais ce que le transporteur vous a facturé. Offrez la livraison et le total natif affiche un revenu de livraison à zéro et un coût à zéro, alors que vous avez réellement payé 6 € au transporteur.
• Remboursements et retours. Une commande remboursée peut encore se trouver dans un état comptabilisé comme chiffre d’affaires « valide », selon votre configuration des états de commande, ce qui gonfle discrètement le haut du compte de résultat.

Le chiffre natif de « marge bénéficiaire » peut donc donner une tendance pour vérifier que rien n’est absurde, mais il est inutilisable pour prendre une décision. Il ne peut pas vous dire lequel de deux produits vous devriez mettre en avant, puisqu’il ne voit pas que l’un supporte 2 € de frais de carte et un taux de retour de 30 %, tandis que l’autre est expédié sans ces handicaps.

Le chiffre d’affaires est le nombre le plus trompeur de votre boutique

Prenons deux boutiques PrestaShop côte à côte. La boutique A réalise 50 000 € par mois ; la boutique B, 20 000 €. Le tableau de bord natif donne clairement l’avantage à A. Ajoutez maintenant les coûts que PrestaShop ne suit pas : A vend de l’électronique à faible marge avec 12 % de retours, paie 1,9 % de frais carte et subventionne la livraison ; B vend des produits de marque propre à 60 % de marge avec presque aucun retour. Faites le vrai calcul : B conserve davantage d’euros chaque mois. Le marchand qui regarde l’écran Statistiques natif optimiserait exactement la mauvaise boutique.

Tout l’intérêt du reporting financier tient dans cet exemple. Les métriques qui font réellement avancer une boutique sont de second niveau, elles n’existent qu’une fois les coûts soustraits du chiffre d’affaires :

• Marge brute par produit, prix de vente moins coût d’achat, moins les frais de paiement, la subvention de livraison et les frais généraux proportionnels attribuables à cette ligne. Le produit qui semble être votre champion dans la liste des meilleures ventes est parfois celui qui perd discrètement de l’argent dès que les frais et les retours entrent dans le calcul.
• Contribution par commande, ce qu’une commande donnée laisse réellement après ses propres coûts variables. Deux commandes de 80 € ne se valent pas si l’une a été expédiée gratuitement à l’autre bout du pays et l’autre retirée en magasin.
• Bénéfice par segment de clientèle, relier la valeur vie client à l’acquisition. La relation entre ce qu’un client vaut et ce qu’il coûte à acquérir est un sujet à part entière ; nous ne la redéveloppons pas ici, les données sur la valeur client par rapport au coût d’acquisition se trouvent dans ce qu’il faut suivre et ce qu’il faut ignorer.
• Taux de retour réel par produit et par catégorie, un taux de retour de 30 % n’est pas une meilleure vente, c’est un défaut produit ou une description trompeuse qui grignote votre marge deux fois : vous payez l’expédition aller, vous absorbez le retour, et vous ne pourrez peut-être pas revendre l’article.

Ce que vous pouvez obtenir de PrestaShop aujourd’hui, et le mur de l’export

Avant d’ajouter quoi que ce soit, il vaut la peine de savoir exactement jusqu’où l’outil natif vous emmène, car pour un petit catalogue, cela peut suffire.

C’est sur cette dernière ligne que finissent la plupart des marchands, exporter les commandes vers un tableur, raccorder à la main les grilles de frais et les factures transporteurs, puis reconstruire le même tableau croisé dynamique chaque mois. Cela fonctionne une fois. Cela ne fonctionne pas comme habitude hebdomadaire, et un rapport que vous ne lancez que lorsque vous vous inquiétez est un rapport qui détecte les problèmes avec un mois de retard. Le plafond natif honnête est celui-ci : PrestaShop peut vous afficher le chiffre d’affaires dans un tableau de bord et le coût seulement si vous fouillez dans le Gestionnaire SQL avec vos propres requêtes. Fusionner les deux dans une vue de bénéfice permanente, planifiée et explorable en détail, c’est le mur que le back-office ne vous permet pas de franchir.

Si vous êtes à l’aise avec le Gestionnaire SQL, vous pouvez réellement aller loin, une requête qui joint ps_orders, ps_order_detail et original_wholesale_price peut vous donner une vraie marge brute par commande. Ce que vous ne pouvez pas faire facilement à cet endroit, c’est intégrer des données de coûts externes (votre grille de frais Stripe, vos factures transporteurs), planifier le rapport ou le confier à un collègue non technique. C’est la frontière entre une requête astucieuse et un système de reporting.

La requête du Gestionnaire SQL qui vous donne la vraie marge brute par commande

Voici une requête de départ à coller dans Paramètres avancés → Base de données → Gestionnaire SQL. Elle additionne le chiffre d’affaires de chaque commande en regard du coût d’achat capturé au moment de la vente, afin d’obtenir la marge brute par commande, ce que les écrans natifs ne vous montrent pas. Ajustez le préfixe de table (ps_) si le vôtre est différent, ainsi que le filtre des commandes valides pour l’adapter à vos états de commande :

SELECT
    o.id_order,
    o.reference,
    o.total_paid_tax_excl                              AS revenue_excl_tax,
    SUM(od.product_quantity * od.original_wholesale_price) AS cost_of_goods,
    o.total_paid_tax_excl
        - SUM(od.product_quantity * od.original_wholesale_price) AS gross_margin,
    ROUND(
        100 * (o.total_paid_tax_excl
            - SUM(od.product_quantity * od.original_wholesale_price))
        / NULLIF(o.total_paid_tax_excl, 0)
    , 1)                                               AS margin_pct
FROM ps_orders o
JOIN ps_order_detail od ON od.id_order = o.id_order
WHERE o.valid = 1
GROUP BY o.id_order
ORDER BY gross_margin ASC;

Deux réserves importantes. Il s’agit uniquement de marge brute, elle soustrait le coût des marchandises, mais pas les frais de paiement, le coût réel de livraison ni les retours, parce que PrestaShop ne stocke pas ces éléments (c’est précisément le sujet de cet article). Et elle n’est fiable que si vos données original_wholesale_price le sont : les commandes passées quand le champ de coût était vide afficheront 100 % de marge et fausseront la liste. Le tri ascendant (gross_margin ASC) place vos pires commandes en haut, ce qui est généralement ce que vous voulez examiner en premier.

Des données aux décisions : ce qui change quand vous voyez le bénéfice

Et alors ? Le but de tout cela n’est pas d’avoir un tableau de bord plus joli, c’est que quatre décisions quotidiennes cessent d’être des paris :

• Prix. Augmenter de 5 % un produit à marge saine et demande stable devient une décision solide lorsque vous voyez sa marge réelle actuelle à côté de sa tendance de ventes. Sans visibilité sur les coûts, la même décision revient à jouer à pile ou face.
• Ce qu’il faut promouvoir. Le reporting de bénéfice réordonne régulièrement la liste des meilleures ventes. Le champion en volume et le champion en bénéfice sont souvent deux produits différents, et vous voulez que votre emplacement en page d’accueil, vos dépenses publicitaires et vos offres groupées pointent vers le second.
• Stock. Ce qu’il faut réapprovisionner, arrêter ou écouler doit suivre la marge, pas le volume. Un produit lent avec 65 % de marge peut mériter plus de visibilité ; un produit rapide à 4 % peut nécessiter une hausse de prix ou une sortie discrète.
• Stratégie de remise. Une vente flash qui enregistre 10 000 € de chiffre d’affaires mais 500 € de bénéfice après la remise, les frais et la livraison n’est pas la victoire que suggère le graphique du chiffre d’affaires. Un reporting sensible à la marge vous le dit le lendemain matin, pas à la fin du trimestre.

Combler l’écart avec le module Financial Revolution

C’est précisément le rôle de notre module Financial Revolution : prendre le chiffre d’affaires que PrestaShop enregistre déjà, vous permettre de saisir les coûts et dépenses qu’il ne suit pas du tout, puis transformer le résultat en une vue permanente de compte de résultat dans le back-office, sans tableur mensuel, sans SQL à la main. Qu’est-ce que cela vous apporte concrètement ?

• Une vraie vue de compte de résultat, pas seulement un tableau de bord de chiffre d’affaires, chiffre d’affaires, coûts saisis et charges d’exploitation, taxes/TVA et bénéfice final, ventilés par catégorie, afin que le résultat que vous lisez soit celui que vous conservez réellement, et non un simple volume de ventes.
• Le suivi des coûts et dépenses que PrestaShop ne sait pas stocker, enregistrez les coûts et frais généraux que la plateforme ne conserve jamais (frais de prestataire de paiement, livraison réelle, charges d’exploitation) et déduisez-les automatiquement du chiffre d’affaires au lieu de les ajouter après coup dans un tableur.
• Reporting de trésorerie, taxes et TVA au même endroit, mouvements de trésorerie, rapports de taxes et de TVA, factures et corrections gérés dans le back-office plutôt que rapprochés à la main après coup.
• Il vit dans votre administration, consultez-le depuis le back-office au même rythme hebdomadaire que vos commandes, au lieu d’exporter et de reconstruire, avec un export CSV lorsque vous devez transmettre les chiffres à votre comptable.

Limite honnête : un module de reporting produit des rapports, il ne fixe pas vos prix et ne rembourse pas vos frais de carte bancaire. Son rôle est de rendre le vrai chiffre impossible à manquer afin que vous puissiez agir. Et il n’est aussi précis que les données de coût qui l’alimentent, ce qui nous amène au point suivant.

Rendre le reporting fiable : renseignez d’abord les données de coût

En reporting financier, de mauvaises données en entrée donnent de mauvais résultats en sortie, et la raison la plus fréquente pour laquelle un rapport de bénéfice semble faux est simple : les champs de coût sont vides. Avant de faire confiance à une marge, native ou issue d’un module, faites le travail de base, peu spectaculaire mais indispensable :

• Renseignez le prix d’achat / coût sur chaque produit (Catalogue → Produits → Prix → Prix d’achat). Modifiez-les en masse ou importez-les via l’import catalogue si vous avez des centaines de références ; un rapport de marge construit sur des coûts à moitié vides est pire qu’aucun rapport, parce qu’il a l’air fiable alors qu’il ne l’est pas.
• Connaissez votre vraie grille de frais, le pourcentage réel et les frais fixes par transaction facturés par votre prestataire de paiement, lus sur un relevé Stripe ou PayPal, pas le taux affiché en vitrine.
• Obtenez vos coûts transporteurs réels, et non le prix de livraison affiché au client, depuis vos factures de transport, surtout si vous proposez la livraison gratuite ou forfaitaire, situations dans lesquelles le montant payé par le client ne vous apprend rien.
• Nettoyez vos états de commande afin que les commandes remboursées et annulées ne soient pas comptabilisées silencieusement comme chiffre d’affaires valide. Vérifiez quels états sont marqués comme logable/payés dans Paramètres de la boutique → Commandes → États.

Installez l’habitude du reporting

Le rapport le plus précis du monde ne vaut rien si personne ne l’ouvre. Les boutiques qui progressent sont celles où un chiffre, et non une intuition, tranche la discussion, et cela n’arrive que si le rythme existe :

• Chaque semaine : le bénéfice total (pas le chiffre d’affaires), vos meilleurs et pires produits par marge, et toute variation qui mérite un second regard. Cinq minutes depuis le back-office.
• Chaque mois : les tendances et la saisonnalité, et le fait de savoir si une initiative précise, changement de prix, nouveau fournisseur, promotion, a réellement fait progresser le bénéfice plutôt que seulement le chiffre d’affaires.
• Chaque trimestre : toute la stratégie confrontée aux données. Quelles catégories méritent leur place, quels clients valent la peine d’être conservés, où se trouve le poids mort du catalogue.

PrestaShop mesure le chiffre d’affaires par défaut parce que c’est le nombre le plus simple à stocker. Le bénéfice est le nombre qui fait tourner l’entreprise, et y accéder signifie soustraire les coûts que la plateforme disperse ou ignore, achat, frais, livraison réelle, retours. Que vous y arriviez avec une requête soigneuse dans le Gestionnaire SQL, un tableur rigoureux ou un module qui effectue les rapprochements pour vous, la discipline reste la même : piloter par ce que vous gardez, pas par ce que vous encaissez, et le consulter assez souvent pour repérer la dérive avant qu’elle n’ait un trimestre de retard.

Questions fréquentes

Pourquoi la marge bénéficiaire native de PrestaShop semble-t-elle fausse ou vide ?

Presque toujours parce que le champ du prix d’achat est vide. La marge de Statistiques → Statistiques du catalogue dans PrestaShop est calculée à partir de wholesale_price, et si vous ne l’avez jamais renseigné sur vos produits, le chiffre ne veut rien dire. Même lorsqu’il est rempli, le chiffre natif reste un pourcentage global moyen qui ignore les frais de paiement, le coût réel de livraison et les retours, il convient donc pour une vérification grossière, mais pas pour décider quel produit promouvoir. Renseignez d’abord les prix d’achat ; ensuite seulement, décidez si la vue native suffit ou si vous avez besoin du détail par commande.

Puis-je calculer le bénéfice réel par commande sans module ?

Oui, pour la marge brute, la requête du Gestionnaire SQL ci-dessus joint ps_orders et ps_order_detail sur original_wholesale_price et vous donne la marge par commande. Ce que vous ne pouvez pas faire dans le Gestionnaire SQL sans un vrai effort, c’est intégrer les coûts externes (votre grille de frais Stripe, vos factures transporteurs), planifier le rapport ou le confier à un collègue non technique. Cet écart, intégrer des données de coûts externes dans un compte de résultat permanent et explorable en détail, marque la différence entre une requête astucieuse et un système de reporting comme Financial Revolution.

Où PrestaShop stocke-t-il le prix d’achat, et comment le renseigner en masse ?

Le prix d’achat se trouve dans wholesale_price sur ps_product (et par déclinaison lorsque vous le définissez), modifié dans Catalogue → Produits → Prix → Prix d’achat. Au moment de la vente, PrestaShop le copie dans ps_order_detail.original_wholesale_price, ce qui explique pourquoi les commandes historiques conservent le coût qui était vrai lorsqu’elles ont été passées. Pour des centaines de références, renseignez-le via l’import CSV du catalogue plutôt qu’à la main, et n’oubliez pas que les commandes passées avant son renseignement n’afficheront aucun coût, donc ne faites pas confiance à la marge sur les anciennes commandes.

Financial Revolution suit-il automatiquement les frais de paiement et les coûts de livraison ?

Il vous donne l’endroit où les enregistrer et les déduit automatiquement du chiffre d’affaires une fois qu’ils sont saisis, mais il ne peut pas lire votre relevé Stripe ni votre facture transporteur à votre place. Le rôle du module est de capturer les coûts que PrestaShop ne sait pas stocker (frais de prestataire de paiement, livraison réelle, charges d’exploitation) et de les intégrer dans un compte de résultat back-office afin que vous arrêtiez de reconstruire un tableur. La précision dépend toujours de la saisie de votre vraie grille de frais et de vos coûts transporteurs ; de mauvaises données en entrée donnent de mauvais résultats en sortie, ici comme ailleurs.

Est-ce la même chose que mes données GA4 ou analytics ?

Non, et les confondre est une erreur fréquente. Il s’agit ici de reporting financier : l’argent qui entre, l’argent qui sort, ce qu’il reste. GA4 et les outils similaires relèvent de l’analyse web : d’où viennent les visiteurs, comment ils se comportent, quel canal convertit. Ils répondent à des questions différentes et aucun ne remplace l’autre. Pour la partie analyse web, commencez par ce qu’il faut suivre et ce qu’il faut ignorer et les métriques GA4 qui comptent vraiment.