Mises à jour de prix en masse : modifier des centaines de prix sans perdre la tête

Votre fournisseur envoie l’e-mail que tout marchand redoute : les prix augmentent de 8 % à partir du premier jour du mois. Vous avez 400 produits. Ouvrir chaque fiche dans le back-office PrestaShop, retaper le prix, cliquer sur enregistrer et attendre le rechargement de la page représente une journée complète de travail — et une journée pendant laquelle une simple faute de frappe peut tranquillement faire partir un produit à 269 € pour 26,90 €. La bonne nouvelle, c’est que PrestaShop vous offre plusieurs vraies méthodes pour modifier des centaines de prix à la fois. La mauvaise, c’est que chacune touche vos données différemment, et qu’un mauvais choix peut fausser vos marges, votre affichage des taxes ou vos flux produits plus vite que vous ne pouvez dire « annuler ». Ce guide explique comment le faire à grande échelle sans prendre de risques inutiles — quelle méthode convient à quel besoin, et quels pièges propres à PrestaShop peuvent transformer une mise à jour rapide en week-end de nettoyage.

Dernière mise à jour : juin 2026.

Une chose doit être claire avant de commencer : derrière « modifier mes prix » se cachent deux opérations totalement différentes. Augmenter durablement vos prix de base (le cas d’une hausse fournisseur) n’a rien à voir avec lancer une vente promotionnelle ou une remise temporaire. Les méthodes ci-dessous sont classées selon le besoin auquel elles répondent — les confondre est la façon la plus courante pour les marchands de créer le désordre.

Les quatre approches — et le besoin auquel chacune répond

Avant de cliquer sur quoi que ce soit, posez le cadre. PrestaShop propose quatre méthodes pratiques pour modifier de nombreux prix à la fois, et elles ne sont pas interchangeables :

Et concrètement ? Si vous utilisez une règle panier alors que vous vouliez augmenter durablement vos prix de base, votre catalogue affichera toujours l’ancien prix partout — listes, flux, comparateurs — et la remise n’apparaîtra qu’à la toute dernière étape. Si vous modifiez les prix de base alors que vous vouliez lancer une promotion de deux semaines, vous avez écrasé les prix d’origine et vous n’avez plus rien à restaurer. Choisir la bonne ligne dès le départ, c’est déjà la moitié de la sécurité.

Méthode 1 : import/export CSV — l’outil de référence pour les changements permanents

Pour une vraie modification permanente des prix de base sur des centaines de produits, le CSV est la méthode prévue pour cela. Le chemin d’import est Paramètres avancés → Import dans PrestaShop 1.7, 8 et 9. Obtenir un CSV de départ en export est moins uniforme : un bouton Exporter existe dans certaines versions et certaines grilles du back-office, mais pas dans toutes. Si votre grille ne le propose pas, passez par un export de base de données, le webservice ou un module d’export dédié. Le déroulé :

• Exportez d’abord votre catalogue. Depuis Catalogue → Produits, utilisez le bouton Exporter si la grille produits de votre version le propose ; sinon, récupérez les données via un export de base de données, le webservice ou un module d’export. Dans tous les cas, vous voulez un CSV de tous les produits comme image avant modification — enregistrez-le tel quel. Si quelque chose se passe mal, réimporter ce fichier restaure vos anciens prix.
• Modifiez dans un tableur. Les colonnes importantes sont ID (ou Référence comme clé de correspondance), Prix HT et, éventuellement, Prix d’achat si vous suivez vos marges. Pour augmenter tout le catalogue de 8 %, une seule colonne de formule — =B2*1.08 — suffit. PrestaShop stocke et attend le prix hors taxe ; le prix TTC vu par les clients est calculé à partir de la règle de taxe. Travaillez donc toujours en hors taxe et laissez PrestaShop ajouter la taxe.
• Réimportez avec « mettre à jour l’existant ». De retour dans Paramètres avancés → Import, choisissez le type d’entité Produits, associez vos colonnes et, point essentiel, cochez "Update existing products" en faisant correspondre les lignes sur l’ID ou la Référence. Si vous oubliez cette case, selon la manière dont vos identifiants sont reconnus, PrestaShop peut créer des produits en double au lieu de mettre à jour les produits existants (ou simplement rejeter les lignes) — une erreur vraiment pénible à corriger, ce qui explique pourquoi il faut d’abord tester avec un petit fichier.

Étape de sécurité critique : ne lancez jamais l’import complet en premier. Réduisez votre CSV à 5–10 produits, importez-les, puis ouvrez-les dans le back-office et vérifiez que les prix sont arrivés exactement comme prévu — affichage TTC compris. Vous ne lancez le fichier complet que lorsque ce lot de test est correct. Une virgule mal placée ou une formule qui a pris la mauvaise colonne peut passer des centaines de prix à 0 € ou 999999 € le temps de lire cette phrase, et l’import CSV le fait sans deuxième écran de confirmation.

Un piège propre à PrestaShop : l’import produit standard met à jour le prix de base, mais ne touche pas aux impacts de prix des déclinaisons ni aux prix spécifiques. Si vos variantes ont leurs propres ajustements de prix, lisez la note sur les déclinaisons ci-dessous.

Méthode 2 : prix spécifiques — pour les promotions, pas les changements permanents

Si votre objectif réel est une promotion temporaire — soldes de printemps, déstockage, tarifs réservés au B2B — ne touchez pas du tout aux prix de base. La fonctionnalité de prix spécifique de PrestaShop existe précisément pour cela. Vous pouvez l’appliquer en masse via Catalogue → Promotions (règles de prix catalogue), ou produit par produit dans l’onglet Prix de la fiche produit :

• Appliquez une remise en pourcentage ou un montant fixe à toute une catégorie, un fabricant ou un fournisseur avec une seule règle.
• Définissez une plage de dates de début/fin pour que le prix revienne automatiquement — pas de rappel dans l’agenda, pas de « ai-je oublié de remettre les prix ? » le lundi après les soldes.
• Ciblez un groupe client précis (grossistes, niveau fidélité) afin que la remise reste invisible pour les autres.

Un mot précis sur l’outil de masse ici, car il est facile de lui prêter plus qu’il ne fait : une règle de prix catalogue (Catalogue → Promotions → Règles de prix catalogue) crée un prix spécifique sur une partie du catalogue sélectionnée par devise, pays, groupe client, fabricant, fournisseur, catégorie ou attribut — avec une date de début/fin et une réduction en pourcentage ou en montant fixe. Ce qu’elle ne fait pas, c’est réécrire vos prix de base : elle ajoute une remise par-dessus. C’est exactement pour cela que c’est le bon outil pour une promotion et le mauvais outil pour une hausse fournisseur permanente. Si vous avez lancé une règle de prix catalogue en pensant modifier vos prix de base, rien n’a bougé dans ps_product — vous avez seulement ajouté une réduction temporaire qui expirera selon les dates définies.

L’avantage est que vos prix de base restent intacts. Vous n’avez jamais besoin de vous souvenir du prix d’origine, vos calculs de marge et de coût restent fiables, et la page produit affiche le vrai rendu « ancien prix/nouveau prix » barré qui signale une offre réelle. Plusieurs prix spécifiques qui se chevauchent peuvent coexister sans suivi manuel de votre part. La question de savoir s’il faut afficher ce prix barré, et comment, rejoint directement la psychologie des prix — nous l’abordons séparément ici.

Méthode 3 : règles panier — pour « X % sur toute la boutique »

Pour une promotion globale et simple (« 20 % sur toute la boutique ce week-end »), une seule règle panier dans Catalogue → Promotions → Règles panier est plus simple que de toucher aux produits :

• Créez une règle, avec ou sans code promo (laissez le code vide pour une remise automatique).
• Définissez le pourcentage et une plage de dates ; limitez-la éventuellement à certaines catégories ou certains produits.

L’avantage, c’est qu’il s’agit d’un seul objet : aucun enregistrement produit ne change, et vous désactivez toute la promo en désactivant une seule règle. Le compromis, qui surprend souvent les marchands : une règle panier s’applique au panier/paiement, donc la remise ne s’affiche pas dans les listes de produits ni sur la page produit. Les clients voient le plein tarif jusqu’au panier. Si vous voulez que le prix réduit soit visible directement sur la page produit, il faut un prix spécifique (méthode 2), pas une règle panier.

Méthode 4 : SQL direct — rapide, puissant, sans pardon

Modifier directement la base de données est la façon la plus rapide de déplacer des prix, et aussi la plus simple de casser une boutique. Dans Paramètres avancés → Base de données → Gestionnaire SQL (ou directement dans la base pour les plus téméraires), une seule instruction remplace mille clics :

UPDATE ps_product SET price = price * 1.08 WHERE id_category_default = 5;

Cela augmente de 8 % tous les produits dont la catégorie par défaut est 5 en environ une seconde — mais c’est aussi incomplet, et c’est le piège expliqué ci-dessous : sur toute installation avec multiboutique, le front-office lit le prix depuis ps_product_shop. Vous devez donc exécuter l’instruction correspondante sur cette table également, sinon votre boutique affichera toujours les anciens prix :

UPDATE ps_product_shop SET price = price * 1.08 WHERE id_category_default = 5;

Et il n’y a aucun bouton d’annulation. Avant d’exécuter quoi que ce soit qui écrit dans la base de données :

• Faites une sauvegarde complète de la base de données. C’est votre seul chemin de retour. Le Gestionnaire SQL lui-même ne vous sauvera pas — utilisez Paramètres avancés → Base de données → Sauvegarde BDD (ou un vrai dump fourni par votre hébergeur) avant toute écriture.
• Lancez d’abord le SELECT. Remplacez UPDATE...SET par SELECT id_product, price avec la même clause WHERE et lisez le résultat — confirmez que vous ciblez bien les produits voulus, et seulement ceux-là.
• N’oubliez pas ps_product_shop. C’est le piège classique de PrestaShop : le prix est stocké à la fois dans ps_product et dans ps_product_shop. Sur une installation multiboutique, le front-office lit ps_product_shop, donc une mise à jour de ps_product seule ne change rien à ce que vos clients voient. Mettez à jour les deux tables.
• Videz le cache ensuite. PrestaShop met fortement en cache les données produit ; les anciens prix peuvent rester dans Smarty et dans le cache pleine page tant que vous ne les purgez pas (voir la checklist ci-dessous).

Cette méthode est réellement destinée aux développeurs à l’aise avec le modèle de données de PrestaShop. Si « ps_product_shop » est une découverte pour vous, utilisez plutôt le CSV — c’est presque aussi rapide et cela ne peut pas désynchroniser silencieusement vos tables.

Le piège des déclinaisons que la plupart des mises à jour en masse oublient

Les produits vendus en variantes — tailles, couleurs, modèles — stockent leurs impacts de prix séparément, dans ps_product_attribute (et ps_product_attribute_shop en multiboutique). Lorsque vous augmentez un prix de base, l’impact de déclinaison reste fixe : augmentez la base de 8 % et le supplément « XL = +2 € » reste à +2 €, pas +2,16 €. Selon votre politique tarifaire, cela peut être correct ou non, mais c’est une décision à prendre volontairement — un import CSV de prix de base ne mettra pas ces impacts à l’échelle pour vous, et les oublier est exactement ce qui laisse la moitié de vos variantes avec de mauvais prix après une mise à jour pourtant « terminée ». Si vous êtes encore en train de décider si votre catalogue doit utiliser des déclinaisons ou des produits séparés, c’est un autre sujet — nous le traitons ici.

Arrondis : décidez avant l’import, pas après

Une hausse en pourcentage produit des nombres peu élégants — 24,99 € × 1,08 = 26,9892 € — et PrestaShop stockera plus de précision que ce qu’un acheteur verra jamais (le prix affiché est limité par la précision et les paramètres d’arrondi de votre devise, donc les clients ne verront normalement pas le « 26,9892 » brut). Malgré cela, fixez votre règle d’arrondi dans le tableur, avant l’import, afin de contrôler vous-même le prix final affiché au lieu d’espérer que la plateforme le nettoie correctement : arrondi à .99 pour les prix psychologiques, au .50 le plus proche pour des étiquettes nettes, ou à l’unité. Cela compte au-delà de la simple propreté, car le point de prix exact sur lequel vous tombez influence mesurablement la conversion — la psychologie des prix est un sujet à part entière, et « 26,9892 » n’aide personne.

Surveillez aussi le sens de la taxe. Comme vous modifiez les prix hors taxe mais que les clients voient les prix TTC, une hausse de 8 % sur la base peut se traduire par un saut visible légèrement différent selon la règle de taxe attachée à chaque produit. Après tout changement en masse, vérifiez à l’œil le prix TTC côté client sur quelques produits, pas seulement le chiffre du back-office.

Calendrier et communication d’une hausse de prix

Au-delà de la mécanique, une hausse de prix est un moment sensible dans la relation client, et quelques bonnes habitudes évitent d’y perdre de la confiance :

• Prévenez les clients B2B et les abonnés à l’avance — « les prix augmentent le 1er, commandez maintenant aux tarifs actuels » adoucit le changement et avance une partie des commandes.
• Lancez la mise à jour pendant les heures creuses afin que le moins de clients possible soient en pleine navigation pendant que les prix changent sous leurs yeux.
• Honorez les paniers déjà en cours pendant une courte période de grâce — un client qui a ajouté un article à l’ancien prix et revient à un prix plus élevé au paiement risque fortement d’abandonner.
• Rafraîchissez immédiatement vos flux de comparaison. Des prix obsolètes dans Google Shopping ou les comparateurs font cliquer les clients sur un ancien prix bas avant d’arriver sur un prix plus élevé — une perte de confiance et, de plus en plus, un risque de refus du flux. La même rigueur de données s’applique aux statistiques que vous affichez sur le site, comme les compteurs en direct de ventes et de vues.

Checklist après mise à jour

Quelle que soit la méthode utilisée, ne considérez jamais une modification de prix en masse comme « terminée » tant que vous n’avez pas parcouru cette liste :

• Vérifiez manuellement 10 à 15 produits répartis entre différentes catégories, fabricants et gammes de prix.
• Contrôlez à la fois les montants hors taxe (back-office) et TTC (front-office).
• Confirmez que les prix des déclinaisons restent corrects — le piège évoqué plus haut.
• Videz les caches en jeu : cache PrestaShop et cache Smarty, ainsi que tout cache de thème, module, serveur, CDN ou couche de cache pleine page que vous utilisez — les anciens prix survivent dans le cache tant que vous ne le faites pas.
• Régénérez vos flux produits (Google Shopping et tout comparateur).
• Quelques jours plus tard, consultez vos rapports financiers pour confirmer que les marges correspondent à ce que vous aviez prévu.

Quand vous faites cela tous les mois

Les méthodes CSV et SQL conviennent pour une hausse annuelle sur tout le catalogue. Elles deviennent vite pénibles si vous réajustez les prix en permanence — changements saisonniers des fournisseurs, variations de devise, réglage des marges par fournisseur. Cette répétition, et les pièges de déclinaisons, d’arrondis et de taxes qui rendent chaque passage risqué, sont précisément ce que notre module Mass Price Updater est conçu pour supprimer. Alors, qu’est-ce qu’il fait concrètement pour vous ? Il applique des modifications en pourcentage ou en montant fixe, votre règle d’arrondi choisie et un ciblage sélectif par catégorie, fabricant ou fournisseur — depuis un seul écran du back-office, avec la gestion des déclinaisons et des tables multiboutique intégrée au lieu d’être laissée comme piège. L’objectif n’est pas la vitesse pour la vitesse : c’est de transformer une opération capable de mettre 400 prix à zéro en une tâche que vous pouvez lancer pendant une pause café sans retenir votre souffle.

Questions fréquentes

Quelle est la façon la plus sûre d’augmenter durablement des centaines de prix de base ? L’import/export CSV. Exportez d’abord votre catalogue et conservez ce fichier intact comme image avant modification, modifiez les prix dans un tableur (une seule colonne =B2*1.08 suffit pour une hausse de 8 %), puis réimportez en cochant "Update existing products" et en faisant la correspondance sur l’ID ou la Référence. Testez toujours sur 5–10 produits avant de lancer le fichier complet — l’import CSV s’applique sans écran de confirmation.

Dois-je utiliser une règle panier, un prix spécifique ou modifier le prix de base ? Faites correspondre l’outil au besoin. Hausse fournisseur permanente = prix de base (CSV ou SQL). Promotion temporaire ou remise propre à un groupe = prix spécifique / règle de prix catalogue, avec retour automatique à la date de fin et affichage de l’ancien prix barré. Promotion simple « X % sur tout » = une seule règle panier, mais elle ne s’applique qu’au panier ; la remise ne s’affiche donc pas dans les listes ni sur les pages produits.

Pourquoi mon changement de prix SQL ne s’affiche-t-il pas sur la boutique ? Presque toujours parce que vous avez mis à jour ps_product, mais pas ps_product_shop. Le prix vit dans les deux tables, et sur une installation multiboutique le front-office lit ps_product_shop. Mettez à jour les deux tables, puis videz le cache PrestaShop et le cache Smarty — les anciens prix restent en cache tant que vous ne les purgez pas.

Qu’en est-il des prix des variantes (déclinaisons) ? Un import CSV de prix de base ne met pas à l’échelle les impacts de prix des déclinaisons. Si « XL = +2 € », augmenter la base de 8 % laisse ce supplément à +2 €, pas +2,16 €. À vous de décider si c’est correct, mais cela doit être volontaire — les impacts de déclinaison vivent dans ps_product_attribute (et ps_product_attribute_shop), et les oublier est la raison pour laquelle une mise à jour « terminée » laisse la moitié de vos variantes avec de mauvais prix.

Comment gérer les arrondis ? Décidez dans le tableur avant l’import, pas après — arrondi à .99 pour les prix psychologiques, à .50 pour des étiquettes nettes, ou à l’unité. Vérifiez ensuite à l’œil le montant TTC (front-office) sur quelques produits, car vous modifiez les prix hors taxe alors que les clients voient les prix TTC ; le saut visible varie donc selon la règle de taxe de chaque produit.

Modules et lectures associés

Si vous réajustez souvent vos prix — changements saisonniers des fournisseurs, variations de devise, réglage des marges — les méthodes manuelles CSV/SQL deviennent rapidement pénibles et risquées. Notre module Mass Price Updater applique des modifications en pourcentage ou en montant fixe avec la règle d’arrondi de votre choix et un ciblage sélectif par catégorie, fabricant ou fournisseur depuis un seul écran du back-office, avec la gestion des déclinaisons et des tables multiboutique intégrée au lieu d’être laissée comme piège (transparence : c’est notre propre module PrestaShop). Après toute modification en masse, vérifiez que les marges correspondent à vos prévisions avec Financial Revolution, et gardez vos chiffres affichés sur le site cohérents — des prix obsolètes affaiblissent les Product Sales & Views Live Stats et les flux que lisent les clients comme Google.

Quelle que soit la méthode adaptée à votre cas, le principe reste le même avec PrestaShop : sachez quel travail vous effectuez (prix de base permanent ou remise temporaire), sachez que le prix vit dans plus de tables qu’on ne l’imagine, testez sur une poignée de produits avant de valider, et conservez l’image avant modification pour que l’« annulation » existe toujours. Faites cela, et modifier des centaines de prix cesse d’être la journée que vous redoutez pour devenir une tâche de dix minutes dans laquelle vous avez confiance.