Planifier les changements de prix dans PrestaShop : produits, catégories et limites de l'automatisation

Dernière mise à jour : 1er juillet 2026. Vérifié avec le comportement tarifaire natif de PrestaShop et les modules mypresta.rocks livrés mprdynamicscheduleddiscounts 1.1.0 et mprmasspriceupdate 1.1.0.

Auteur : équipe éditoriale mypresta.rocks. Nous développons des modules PrestaShop et exploitons nous-mêmes des boutiques PrestaShop ; ce guide s’appuie donc sur le comportement réel du back-office et sur le code des modules livrés, pas seulement sur la théorie des prix.

« Puis-je programmer tous mes prix pour qu’ils changent le premier du mois prochain ? » Parfois oui. Parfois non. L’erreur consiste à traiter chaque changement de prix comme la même tâche.

Dans PrestaShop, la tarification planifiée se divise en trois cas différents : une remise temporaire, une modification permanente du prix de base et une règle déclenchée par les ventes ou le stock. Utilisez l’outil natif pour le premier cas. Utilisez un éditeur en masse pour les changements de prix permanents. Utilisez l’automatisation uniquement lorsque la règle dépend de l’âge du stock, de l’historique des ventes ou d’une vérification cron.

Comparaison rapide

Commencez par nommer la tâche

• Promotion planifiée : une réduction de prix temporaire avec une date de début et une date de fin. Le prix d’origine revient lorsque la fenêtre de dates se ferme.
• Changement permanent du prix de base : le prix produit enregistré change et reste modifié. C’est fréquent après une évolution des coûts fournisseur.
• Automatisation déclenchée : le prix réagit aux ventes ou à l’état du stock, par exemple en l’absence de vente récente alors que le stock reste en entrepôt.

Nous exploitons nous-mêmes des boutiques PrestaShop. Les erreurs de prix qui posent problème sont souvent petites : une règle catalogue laissée active trop longtemps, une remise par volume comprise comme un déclencheur de ventes à vie, ou une mise à jour du prix de base faite sans données de rollback. C’est pourquoi ce guide sépare les couches de remise des modifications de prix enregistrés.

Méthode native 1 : planifier un produit avec les prix spécifiques

Pour un produit et une fenêtre de dates, n’installez rien. Utilisez l’écran de tarification du produit.

1. Ouvrez Catalogue > Produits.
2. Modifiez le produit.
3. Ouvrez l’onglet Prix.
4. Ajoutez un Prix spécifique.
5. Définissez À partir de la quantité sur 1, sauf s’il s’agit d’une remise par volume.
6. Choisissez un prix fixe ou une réduction.
7. Définissez les dates Du et Au.
8. Enregistrez et testez la page produit pendant la fenêtre de dates.

Specific Price example
Product: Example Jacket
From quantity: 1
Available from: 2026-08-08 00:00:00
Available to:   2026-08-11 23:59:59
Reduction:      20 percent

Use this for:
"This product is 20 percent off next weekend."

Conclusion pratique : c’est le chemin natif le moins risqué lorsque la remise concerne un seul produit. PrestaShop vérifie déjà la plage de dates pendant le calcul du prix.

Méthode native 2 : planifier une remise de catégorie avec les règles de prix catalogue

Lorsque la remise couvre un groupe de produits, utilisez une règle de prix catalogue. Le libellé exact dans le back-office varie entre PrestaShop 1.7, 8 et 9, mais le principe reste le même : définir la règle de prix, puis définir les conditions.

1. Ouvrez Catalogue > Réductions.
2. Créez une Règle de prix catalogue.
3. Nommez-la clairement, en incluant la campagne ou la saison.
4. Définissez À partir de la quantité sur 1, sauf si vous voulez une remise par volume dans le panier.
5. Définissez la plage de dates.
6. Choisissez le type et la valeur de réduction.
7. Ajoutez des conditions comme catégorie, fabricant, attribut, caractéristique, fournisseur ou tranche de prix, selon votre version de PrestaShop et l’écran utilisé.
8. Enregistrez la règle et vérifiez un produit inclus et un produit hors du jeu de conditions.

Catalog Price Rule example
Name: Weekend Outdoor 15 percent
From quantity: 1
From: 2026-08-07 00:00:00
To:   2026-08-10 23:59:59
Reduction: 15 percent
Conditions:
  Category = Outdoor

Use this for:
"Everything in Outdoor is 15 percent off this weekend."

Le point important : une règle de prix catalogue reste une couche de remise. Elle ne réécrit pas vos prix de base produits enregistrés.

Le piège du « à partir de la quantité »

PrestaShop utilise à partir de la quantité pendant le calcul du prix courant. En clair : combien d’unités se trouvent dans le panier actuel ou dans la ligne de commande. Ce n’est pas un compteur de ventes à vie.

• « Achetez 5 articles ou plus, économisez 10 % » : les prix spécifiques natifs peuvent le gérer.
• « Après avoir vendu 100 unités au total, augmentez le prix » : ce n’est pas natif.

Ne lisez pas cela comme une promesse de fonctionnalité pour nos modules actuels. Un déclencheur « après la 100e unité cumulée vendue » n’est pas livré dans les modules abordés ici. Il relève d’une phase d’automatisation ultérieure, car les remboursements, retours, déclinaisons et états multiboutique influencent tous le comptage.

-- Concept only: a cumulative sales trigger needs order history,
-- not the current cart quantity used by from_quantity.

SELECT
  od.product_id,
  SUM(
    od.product_quantity
    - COALESCE(od.product_quantity_refunded, 0)
    - COALESCE(od.product_quantity_return, 0)
  ) AS net_units_sold
FROM ps_order_detail od
INNER JOIN ps_orders o ON o.id_order = od.id_order
WHERE o.valid = 1
  AND o.id_shop = 1
  AND od.product_id = 123
GROUP BY od.product_id;

Une vraie automatisation doit vérifier quelles colonnes de quantités remboursées ou retournées existent dans votre version de PrestaShop avant d’exécuter une requête comme celle-ci. L’évaluateur de stock dormant livré effectue ce type de vérification de colonnes compatible avec les versions pour sa propre logique de dernière vente.

Les changements permanents du prix de base sont une autre tâche

Si votre fournisseur augmente ses coûts et que vous voulez que chaque produit d’une catégorie augmente de 8 % à partir du 1er août, une règle de prix catalogue est le mauvais outil. Vous ne voulez pas une couche de remise temporaire. Vous voulez que le prix de base enregistré change selon un calendrier.

Mass Price Updater 1.1.0 gère cela comme une tâche planifiée. Dans le code, le module crée une ligne dans mprmasspriceupdate_job, attend jusqu’à run_at, puis met à jour les champs de prix product et product_shop via cron. Avant de modifier les lignes de prix, il écrit les données de rollback dans mprmasspriceupdate_job_snapshot.

1. Choisissez le périmètre : tous les produits, catégorie, fabricant ou fournisseur.
2. Choisissez le champ : prix de base ou prix d’achat.
3. Choisissez la formule : augmentation en pourcentage, baisse en pourcentage, augmentation fixe ou baisse fixe.
4. Prévisualisez les produits et les nouveaux prix.
5. Définissez la date et l’heure de planification.
6. Laissez cron exécuter la tâche, puis utilisez l’écran des tâches planifiées pour le statut et le rollback.

Scheduled base-price job example
Module: mprmasspriceupdate 1.1.0
Scope: category
Scope ID: 12
Field: price
Formula action: increase_percent
Formula value: 8
Run at: 2026-08-01 00:05:00
Preview required before scheduling: yes
Rollback table: mprmasspriceupdate_job_snapshot

L’automatisation du stock dormant demande plus que des dates

Le stock dormant ne se résume pas à « remiser le produit X entre deux dates ». La règle que les marchands veulent généralement est conditionnelle :

IF product has no valid sale for 30 days
AND stock quantity is greater than 3
AND no active discount already applies
AND the final price stays above the floor
THEN apply a clearance discount

PrestaShop natif ne combine pas ces contrôles pour vous. Smart Dynamic & Scheduled Discounts 1.1.0 ajoute une automatisation du stock dormant avec des enregistrements de règles, de périmètres, d’applications, d’exécutions et des journaux dans ces tables :

mprdsd_automation_rule
mprdsd_automation_rule_scope
mprdsd_automation_application
mprdsd_automation_run
mprdsd_automation_log

Le module n’écrit pas de lignes natives ps_specific_price pour cette automatisation et n’écrase pas les prix de base produits. Il génère des cibles de campagne internes, puis la remise est appliquée pendant le calcul du prix PrestaShop via actionProductPriceCalculation. Cela garde le rollback plus propre : supprimer les cibles générées arrête la remise automatisée sans essayer de reconstruire les prix natifs.

Dead-stock rule example
Rule name: Warehouse clearance - slow movers
Active: yes
No Sale Days: 30
Stock Threshold: 3
Discount Type: Percentage
Discount Value: 15
Price Floor: Minimum margin percent
Floor Value: 20
Exclude Already Discounted Products: yes
Scope:
  Include category: Clearance candidates
  Exclude product: protected-margin SKU

Dry-run preview shows:
  scanned
  would discount
  would expire
  eligible
  skipped
  base price
  discount
  floor
  final price

Dry-run writes: 0

À quoi ressemble la partie cron

La tâche d’automatisation de stock dormant enregistrée par Smart Dynamic & Scheduled Discounts est evaluate_dead_stock_automation, planifiée comme every:1800 dans le module. Le runner cron partagé MPR exécute les tâches arrivées à échéance. Utilisez le point d’entrée cron généré dans votre boutique et gardez le token privé.

# Example MPR cron runner. Use the cron entry point generated in your shop.
*/5 * * * * php /var/www/html/modules/YOUR_MPR_CRON_MODULE/cron.php --token=YOUR_CRON_TOKEN --context=cron --max-tasks=20

# Registered task checked by the runner:
module=mprdynamicscheduleddiscounts
task_key=evaluate_dead_stock_automation
schedule=every:1800

Quel chemin choisir ?

• Remise temporaire sur un produit : utilisez les prix spécifiques natifs.
• Remise temporaire sur une catégorie ou un segment de catalogue : utilisez les règles de prix catalogue natives.
• Changement permanent du prix de base en masse : utilisez Mass Price Updater ou un autre processus de modification en masse contrôlé, avec aperçu et données de rollback.
• Changement permanent futur du prix de base : utilisez les tâches planifiées dans Mass Price Updater.
• Déstockage de stock dormant basé sur l’absence de vente récente et le niveau de stock : utilisez Smart Dynamic & Scheduled Discounts.
• Après N unités cumulées vendues : traitez-le comme une automatisation personnalisée. Ce n’est pas natif dans PrestaShop et ce n’est pas un déclencheur livré dans ces modules aujourd’hui.

FAQ

PrestaShop peut-il planifier des changements de prix nativement ?

Oui, pour les remises temporaires. Utilisez les prix spécifiques pour un produit et les règles de prix catalogue pour les groupes de produits. PrestaShop natif ne vous donne pas le même flux en un seul écran pour planifier une future modification permanente en masse des prix de base.

« À partir de la quantité » signifie-t-il les unités vendues à vie ?

Non. Dans les prix spécifiques et les règles de prix catalogue, « à partir de la quantité » est lié à la quantité dans le panier actuel ou dans la ligne de commande. Ce n’est pas un compteur de ventes historiques.

Puis-je planifier une remise de catégorie sans module ?

Oui. Utilisez une règle de prix catalogue avec une plage de dates et une condition de catégorie. C’est le chemin natif pour une remise temporaire de catégorie.

PrestaShop peut-il remiser automatiquement le stock dormant ?

Pas nativement. Une règle de stock dormant a besoin de l’historique des commandes, de la quantité en stock, du périmètre, de contrôles de prix plancher, d’un aperçu, de cron et d’une expiration. Smart Dynamic & Scheduled Discounts ajoute cette automatisation.

Smart Dynamic & Scheduled Discounts change-t-il mes prix de base ?

Non pour l’automatisation de stock dormant décrite ici. Il applique la remise à l’exécution via le calcul du prix PrestaShop et des cibles de campagne internes générées. Il n’écrit pas de prix spécifiques natifs et n’écrase pas les prix de base produits pour cette automatisation.

Quel module utiliser pour les changements permanents du prix de base ?

Utilisez Mass Price Updater lorsque vous voulez modifier des prix de base ou des prix d’achat enregistrés avec une formule, prévisualiser les produits concernés, planifier la tâche et conserver des snapshots de rollback.