Remises programmées : créer des promotions qui démarrent et s’arrêtent automatiquement

Dernière vérification : juin 2026. Validé avec PrestaShop 1.7, 8 et 9. Note PS9 : le back-office des remises est en cours d’unification autour de quatre types de remises (Catalog, Cart, Free-Shipping, Free-Gift) derrière une option expérimentale, mais chaque type conserve la fenêtre de dates sur laquelle s’appuie ce guide.

Il est 23 h un jeudi soir et vous vous souvenez que la promotion du Black Friday devait démarrer à minuit. Vous créez des règles panier et modifiez des prix dans l’urgence, en espérant ne pas vous tromper de décimale sous pression. Ou la version plus discrète de la même erreur : vous configurez une remise « week-end seulement » le vendredi, vous l’oubliez le lundi, et vous laissez partir de la marge pendant trois jours de plus avant que quelqu’un s’en aperçoive. Dans les deux cas, la cause est la même : c’est un humain qui sert d’interrupteur.

PrestaShop peut jouer ce rôle à votre place. Les deux mécanismes de remise de la plateforme — règles panier et prix spécifiques — possèdent leurs propres horodatages de début et de fin, que la boutique évalue à chaque chargement de page. Définissez les dates une seule fois, et la promotion s’active puis se désactive toute seule, que vous soyez réveillé ou non. Ce guide porte précisément sur cette couche de planification : où se trouvent les champs de date, comment PrestaShop décide qu’une remise est « active » à un instant donné, le piège du fuseau horaire qui peut décaler silencieusement votre lancement, et les contenus à programmer en parallèle du prix. Pour choisir quel type de remise utiliser au départ, consultez organiser une opération promotionnelle dans PrestaShop ; pour savoir quand les lancer dans l’année, voyez le calendrier des promotions saisonnières.

Comment PrestaShop décide réellement qu’une remise est « en ligne »

Comprendre ce qui se passe sous le capot aide beaucoup, car c’est ce qui détermine tout le reste. PrestaShop ne lance pas de tâche planifiée à minuit pour activer votre promotion. Il n’y a ni tâche cron, ni file d’attente. À la place, les règles panier comme les prix spécifiques stockent un date_from et un date_to en base de données, puis le prix est recalculé au moment de la requête : quand un client charge une fiche produit ou actualise son panier, le cœur compare ces horodatages à maintenant et inclut la remise uniquement si l’instant courant se situe dans la fenêtre.

Qu’est-ce que cela change pour vous ? Trois choses très concrètes. D’abord, l’activation est instantanée et fiable : aucune tâche ne peut oublier de se lancer, donc une promotion définie pour 00:00 démarre réellement à 00:00. Ensuite, le « maintenant » est évalué selon le fuseau horaire configuré pour la boutique / l’environnement PHP, pas selon le fuseau local du visiteur (c’est le piège du fuseau horaire expliqué plus bas). Enfin, comme le prix est calculé en direct puis mis en cache, une promotion qui devrait déjà avoir commencé peut encore afficher l’ancien prix tant que le cache de page n’a pas été reconstruit ; c’est pourquoi les caches pleine page agressifs et les remises programmées doivent être coordonnés, comme nous le verrons plus loin.

Programmer une règle panier (Catalogue → Remises)

Les règles panier sont le moteur de bons de réduction de PrestaShop : aussi bien les codes saisis par le client que les remises automatiques appliquées silencieusement lorsque les conditions sont réunies. Vous en créez une depuis Catalogue → Remises → Nouvelle règle panier (dans PrestaShop 1.6, le chemin est Règles de prix → Règles panier). Pour la programmer, ouvrez l’onglet Conditions et définissez Valable à partir du / Valable jusqu’au :

• Valable à partir du — date et heure à partir desquelles la règle devient utilisable. Stocké dans date_from.
• Valable jusqu’au — date et heure d’expiration. Stocké dans date_to.

À l’intérieur de cette fenêtre, la règle est active ; en dehors, le code est rejeté avec le message « ce bon de réduction n’est pas valide » et une règle automatique ne s’applique tout simplement pas. Deux champs que la plupart des marchands ignorent méritent d’être réglés volontairement :

• Total disponible et Total disponible pour chaque utilisateur — plafonds d’utilisation. Une plage de dates programmée répond à la question « quand » ; ces champs répondent à la question « combien de fois », ce qui permet d’éviter qu’un code divulgué soit exploité pendant toute la durée de la fenêtre.
• Mettre en avant et Utilisation partielle — dans l’onglet Actions. La mise en avant oriente le client vers un bon applicable dans le panier ; l’utilisation partielle décide si le reliquat non dépensé d’un bon à montant fixe survit jusqu’à la prochaine commande.

Une chose que le back-office ne vous empêchera pas de faire : définir « Valable jusqu’au » avant « Valable à partir du ». Il n’y a pas de garde-fou ; la règle ne s’active simplement jamais, et vous le découvrez quand un client vous écrit pour demander pourquoi EARLY20 ne fonctionne pas. Relisez les deux dates avant d’enregistrer.

Programmer une baisse de prix sur les produits (prix spécifiques)

Les règles panier remisent le panier. Pour afficher un prix barré directement sur la fiche produit — la présentation classique d’une promotion, ancien prix rayé, nouveau prix en rouge — vous utilisez un prix spécifique, défini par produit via Catalogue → Produits → [votre produit] → Prix → Prix spécifiques → Ajouter un prix spécifique. La même fenêtre apparaît lorsque vous attribuez en masse une règle de prix catalogue via Catalogue → Remises → Règles de prix catalogue, ce qui permet de programmer une remise sur toute une catégorie ou tout un fournisseur d’un coup, plutôt que produit par produit.

Cette fenêtre possède ses propres champs date-heure Du et Au — les mêmes colonnes from/to dans la table ps_specific_price — ainsi que des contrôles que les règles panier n’ont pas :

• Pour (groupe de clients) — limiter le prix programmé à un groupe, afin qu’une « semaine grossistes, −20 % pour les revendeurs » coexiste avec le tarif normal au détail dans la même fenêtre.
• Quantité disponible / À partir de la quantité — moduler la remise par nombre d’unités achetées, sur une plage de dates programmée.
• Laisser les dates vides — et le prix spécifique devient permanent. Ce sont les champs de date qui transforment un prix permanent en promotion limitée dans le temps ; les vider est la façon de rendre volontairement un prix remisé « durable ».

La différence visible pour l’acheteur est précisément ce qui guide le choix entre les deux mécanismes : un prix spécifique apparaît dans le catalogue et sur la fiche produit avant tout ajout au panier, donc il met l’offre en avant ; une règle panier se révèle généralement au niveau du panier. Si vous ne savez pas quel mécanisme convient à une promotion donnée, le comparatif règles panier vs prix spécifiques sert de cadre de décision.

Auditer vos fenêtres programmées avec une seule requête

Quand vous avez préparé un trimestre de promotions à l’avance, mieux vaut tout relire au même endroit que cliquer sur chaque produit. Les vérifications ci-dessous sont en lecture seule : elles ne modifient rien. Pour voir toutes les règles panier dont la fenêtre s’ouvrira dans le futur ou est actuellement active (adaptez le préfixe ps_ à votre installation) :

-- Cart rules with their scheduled windows, soonest first.
SELECT id_cart_rule, code, active, date_from, date_to,
       quantity, quantity_per_user
FROM ps_cart_rule
WHERE date_to >= NOW()
ORDER BY date_from;

Et pour repérer l’erreur classique « Valable jusqu’au antérieur à Valable à partir du » sur toutes les règles à la fois, avant qu’un client ne la trouve pour vous :

-- Any rule whose window can never open (to is before from).
SELECT id_cart_rule, code, date_from, date_to
FROM ps_cart_rule
WHERE date_to < date_from;

L’équivalent pour les baisses de prix produit lit la table ps_specific_price : les colonnes from et to sont les mêmes champs de planification que ceux écrits par la fenêtre, et une ligne où les deux valent 0000-00-00 00:00:00 correspond à un prix permanent (non daté), pas à une promotion programmée.

Le piège du fuseau horaire qui décale votre lancement

C’est la cause la plus fréquente d’échec d’une remise programmée, et elle reste invisible jusqu’au moment où elle vous atteint. PrestaShop évalue date_from / date_to par rapport au fuseau horaire configuré pour la boutique, défini dans International → Localisation → Fuseau horaire (en interne, cette valeur est stockée sous PS_TIMEZONE) — ce qui ne correspond pas forcément à l’horloge système de votre hébergement, et presque jamais à celle d’un client qui navigue depuis un autre pays.

L’échec ressemble à ceci : le fuseau horaire de votre boutique est resté sur une valeur par défaut choisie par l’hébergeur, ou sur UTC, alors que votre activité et vos clients fonctionnent en CET (UTC+1). Vous programmez le début de la promotion à 00:00. Pour vos clients d’Europe centrale, elle démarre en réalité à 01:00 — et l’opération « flash de minuit » annoncée par e-mail est morte pendant sa première heure. Les heures de fin glissent de la même manière : une clôture « dimanche 23:59 » en UTC se termine à 00:59 le lundi en heure locale, soit une heure offerte que vous n’aviez pas prévue.

Avant tout lancement à enjeu, vérifiez d’abord le fuseau horaire de la boutique, puis lisez votre heure de début comme « 00:00 dans ce fuseau horaire » plutôt que « 00:00 chez moi ».

Le détail que presque tout le monde oublie : le cache et le visuel

Deux éléments se placent entre une remise correctement datée et le fait qu’un client la voie réellement.

Cache. Comme les prix sont calculés au moment de la requête puis mis en cache, une boutique utilisant un cache pleine page, le cache Smarty ou un CDN peut continuer à servir le prix d’avant-promotion après le passage de date_from — et continuer à servir le prix remisé après la fin. Pour une opération avec démarrage strict, la méthode fiable consiste à programmer les dates normalement puis à vider le cache au moment du lancement (Paramètres avancés → Performances → Vider le cache) afin que le premier rendu recalcule le prix. Si vous utilisez un long cache en périphérie, intégrez son TTL au moment réel où vous purgez.

Si l’heure de début de votre promotion est réellement fixe (un flash à minuit), vous pouvez aussi retirer l’humain de la purge du cache. PrestaShop ne programme pas l’activation de la remise, mais votre serveur peut programmer le vidage du cache : une ligne cron qui lance la commande console de purge au moment de la mise en ligne, afin que le premier rendu après lancement recalcule les prix sans que vous ayez à vous connecter :

# crontab entry: clear PrestaShop's cache at 00:00 on 27 Nov 2026,
# the minute a hard-start sale opens. Run as the web user.
# (path to the PrestaShop root; --no-debug for prod)
0 0 27 11 * cd /var/www/html && php bin/console cache:clear --env=prod --no-debug

Cela n’active pas la remise — la fenêtre de dates le fait toute seule — mais garantit simplement que la page d’avant-promotion mise en cache disparaît dès l’ouverture de la fenêtre. Sur un CDN ou un cache en périphérie, vous l’associeriez à la purge du fournisseur à la même minute. Considérez cela comme une précaution supplémentaire pour les opérations où la première minute compte, pas comme une exigence pour les programmations du quotidien.

Le visuel. La remise est programmée ; le diaporama de la page d’accueil affiche encore « Soldes d’été » pendant que la promotion d’automne est active, ou la bannière qui annonce le code expire trois jours avant le code lui-même. Dans PrestaShop, la planification des prix et celle des contenus sont des systèmes séparés, et le second n’a pas de champs de date natifs sur le diaporama par défaut. Associez chaque remise programmée à un remplacement créatif programmé, afin que le message et le prix changent à la même minute — notre approche des bannières promotionnelles explique comment les produire sans faire intervenir de designer.

Remises qui se chevauchent : qui gagne quand deux règles se rencontrent ?

Dès que vous programmez plus d’une promotion, vous pouvez les empiler par accident. Un produit avec un prix spécifique de 20 % qui entre aussi dans le périmètre d’une règle panier automatique de 15 % ne se comporte pas toujours comme le client (ou votre marge) s’y attend. PrestaShop résout cela avec des priorités et des paramètres de combinaison, plutôt qu’en additionnant simplement tout :

• Prix spécifiques — lorsque plusieurs peuvent s’appliquer, les conflits sont résolus par les règles de priorité des prix spécifiques de PrestaShop et par les critères de correspondance (boutique/devise/pays/groupe, plus quantité et dates correspondantes) ; testez le prix produit obtenu.
• Les règles panier ont leur propre Priorité et une option par règle qui contrôle si elle peut être combinée avec d’autres bons de réduction dans le même panier.
• Une réduction par prix spécifique et une remise par règle panier sont calculées à des étapes différentes (prix de ligne vs total du panier), elles peuvent donc se cumuler si ce n’est pas ce que vous voulez.

La logique est franchement délicate et ne mérite pas d’être raisonnée dans l’abstrait. Avant toute fenêtre où des promotions se chevauchent, faites le test qui tranche : passez une vraie commande de test avec les remises programmées actives et regardez le montant final. S’il est plus bas que prévu, ajustez la priorité / compatibilité des règles panier, les restrictions produit, ou excluez les produits déjà remisés, puis retestez. Les mécanismes plus profonds de superposition des réductions sont détaillés dans le guide des stratégies promotionnelles ; pour les produits qui doivent rester à l’écart de toute remise programmée, consultez l’exclusion de remise.

Checklist avant lancement pour toute promotion programmée

Configurez chaque promotion environ une semaine avant son lancement, afin de relire les paramètres au calme plutôt qu’à 23 h. Avant la mise en ligne, passez cette liste en revue :

• Dates correctement relues — « Valable jusqu’au » est réellement postérieur à « Valable à partir du », et les deux dates sont dans le fuseau horaire de votre boutique, pas celui de l’horloge sur votre mur.
• Périmètre correct — une règle « -20 % sur les accessoires » qui s’applique discrètement à tout le catalogue peut coûter cher en quelques heures. Confirmez la catégorie, le groupe ou la condition produit.
• Plafonds d’utilisation définis — limites totales et par utilisateur pour tout code susceptible de fuiter.
• Chevauchement testé — une vraie commande de test avec les remises programmées ; relisez le total final.
• Plan de cache — sachez si vous videz le cache au lancement et à la fin.
• Créations programmées — bannière, diaporama et e-mails calés sur la même fenêtre que le prix.

Quand le calendrier dépasse les limites du back-office

Les champs de date natifs gèrent proprement une promotion isolée. La tension apparaît quand vous exploitez un calendrier roulant : opérations saisonnières enchaînées, offres récurrentes du week-end, ventes flash bornées dans le temps — et que vous modifiez maintenant à la main des dizaines de règles panier et de prix spécifiques, chacun avec son propre raisonnement de fuseau horaire et sa purge de cache. C’est précisément la charge de travail que nos modules d’automatisation sont conçus pour supprimer. Sales Revolution exécute des ventes flash programmées et expirant automatiquement sous forme de campagne gérée, plutôt qu’une pile de règles manuelles : définissez la fenêtre, les produits et le niveau de remise, et il gère le début comme la fin de l’opération ; nous l’avons présenté dans les ventes flash automatisées pour PrestaShop. Le bénéfice est le même que dans tout cet article, mais à plus grande échelle : l’interrupteur marche/arrêt n’est plus une personne debout à minuit. Pour aborder honnêtement la psychologie de ces offres limitées dans le temps — vrais comptes à rebours, pas de minuteurs qui se réinitialisent artificiellement — consultez les ventes flash sans manipulation.

Tout l’intérêt des remises programmées est volontairement banal : vous décidez une fois, en pleine journée, avec les dates et le périmètre sous les yeux, puis la boutique les applique exactement. Réglez correctement le fuseau horaire, tenez compte du cache, programmez les créations en même temps que le prix et testez les chevauchements ; ensuite, laissez tourner. Votre futur vous, un jeudi soir à 23 h, n’aura plus à y penser.

Remises programmées : questions fréquentes

PrestaShop a-t-il besoin d’une tâche cron pour activer une remise à son heure de début ?

Non. L’activation n’est pas une tâche planifiée : aucune tâche cron ne bascule les promotions sur « actif ». PrestaShop stocke un date_from/date_to sur chaque règle panier et chaque prix spécifique, puis recalcule le prix au moment de la requête, en incluant la remise uniquement lorsque « maintenant » tombe dans la fenêtre. C’est pourquoi une promotion réglée pour 00:00 démarre vraiment à 00:00, sans tâche qui pourrait ne pas s’exécuter. Un cron n’est utile que pour la purge du cache au lancement, pas pour la remise elle-même.

La date de ma promotion était passée, mais l’ancien prix restait affiché : pourquoi ?

Le cache. Les prix sont calculés au moment de la requête puis mis en cache ; un cache pleine page, le cache Smarty ou un CDN peut donc continuer à servir le prix d’avant-promotion après l’ouverture de la fenêtre. Videz le cache au lancement (Paramètres avancés → Performances → Vider le cache) et, si vous utilisez un cache en périphérie ou un CDN, purgez-le aussi en tenant compte de son TTL. Pour une opération à démarrage strict, programmez cette purge afin que le premier rendu après lancement recalcule les prix.

La promotion a démarré avec une heure de retard : que s’est-il passé ?

Le piège du fuseau horaire. PrestaShop évalue la fenêtre par rapport au fuseau horaire configuré de la boutique (PS_TIMEZONE, dans International → Localisation → Fuseau horaire), et non par rapport à l’horloge du serveur ou à l’heure locale du visiteur. Si votre boutique reste en UTC alors que votre marché fonctionne en CET, un début à « 00:00 » se déclenche à 01:00 pour vos clients. Réglez le fuseau horaire de la boutique sur votre marché principal, puis lisez chaque horaire de promo comme « minuit dans ce fuseau horaire ».

Puis-je définir une fenêtre de remise sans date de fin ?

Oui : laissez vide le champ Au / Valable jusqu’au. Sur un prix spécifique, vider les deux champs de date rend le prix permanent (une baisse durable plutôt qu’une promotion limitée dans le temps). Sur une règle panier, un champ Valable jusqu’au ouvert signifie que la règle reste utilisable jusqu’à ce que vous la désactiviez ou que ses plafonds d’utilisation soient épuisés. Ce sont précisément les champs de date qui transforment un prix permanent en prix limité dans le temps ; des champs vides sont donc un choix, pas un oubli.

Comment empêcher deux remises programmées de se cumuler jusqu’à générer une perte ?

Ne raisonnez pas dans l’abstrait : testez. Passez une vraie commande avec les deux remises programmées actives et regardez le total final. Si la remise est plus forte que prévu, les leviers sont les suivants : la Priorité de la règle panier, l’option par règle « combiner avec d’autres bons de réduction », et « Exclure les produits en promotion » sur une règle panier en pourcentage afin qu’elle ignore tout produit déjà porté par un prix spécifique. Ajustez, puis retestez. Pour les références qui ne doivent jamais être touchées par une promotion, consultez l’exclusion de remise.