---
title: "Page produit, panier ou checkout : où placer votre sélecteur de date de livraison"
description: "Les trois emplacements ne sont pas classés — ce sont des compromis, et votre forfait Shopify décide lesquels vous sont seulement accessibles. Ce que chacun vous coûte, la panne dont personne ne parle, et comment choisir."
contentType: "blog"
locale: "fr"
localized: true
source: "https://orderrules.com/fr/blog/where-to-put-delivery-date-picker-shopify"
slug: "where-to-put-delivery-date-picker-shopify"
date: "2026-09-23"
tags:
  - "shopify"
  - "delivery date picker"
  - "checkout"
  - "shopify plus"
  - "cart"
  - "delivery dates"
  - "checkout extensibility"
---
Toute boutique qui vend quelque chose de sensible au temps finit par poser la même question : où placer concrètement le sélecteur de date de livraison ?

Les réponses que l'on trouve portent généralement sur le comment, pas sur le où — un snippet de thème par ici, une extension de checkout par là. L'emplacement lui-même est traité comme un détail. Ce n'en est pas un. Il détermine quels clients vous donnent une date, lesquels passent sans en donner, et à quelle fréquence vous l'apprenez au mauvais moment.

Il y a trois endroits. Aucun n'est le meilleur.

![Emplacements du sélecteur de date OrderRules comparés — page produit, panier et checkout Shopify Plus, avec les forfaits qui autorisent chacun et l'endroit où une date peut se perdre](/images/blog/where-to-put-delivery-date-picker-shopify.png)

## Ce que votre forfait Shopify autorise

Commencez par là, car cela élimine des options avant même que la préférence n'intervienne.

| Emplacement | Forfaits | Fonctionnement |
| --- | --- | --- |
| Page produit | Tous | Theme app block dans le formulaire produit |
| Panier | Tous | Theme app block sur la page panier ou le tiroir |
| Checkout | **Shopify Plus uniquement** | Checkout UI extension |

Les checkout UI extensions ne s'exécutent que sur les checkouts Plus. C'est une limite de la plateforme, pas une limite applicative, et aucune app ne peut vous la vendre autrement.

Un point mérite d'être démêlé ici, car le calendrier prête à confusion. `checkout.liquid` et les Additional Scripts ont cessé de s'exécuter pour les boutiques **non-Plus** en août 2026. Les boutiques Plus avaient déjà migré, en 2024 et 2025. Donc si vous arrivez sur cette question parce que votre personnalisation de checkout s'est cassée récemment, vous êtes presque certainement sur un forfait non-Plus — et la solution pour vous est l'emplacement page produit ou panier, pas une extension de checkout que vous ne pouvez pas exécuter.

## Page produit

La date se trouve dans le formulaire d'ajout au panier, elle est donc choisie avant que l'article ne soit dans le panier.

**Choisissez-la quand la date fait partie de la décision.** Un gâteau pour samedi ne vaut pas la peine d'être acheté si samedi est complet. Un bouquet qui ne peut pas arriver le 14 n'est pas un achat, c'est une déception. Montrer la disponibilité au moment du choix, c'est la différence entre une vente et un remboursement.

C'est aussi le seul emplacement qui survit à **Buy Now**. Parce qu'il vit à l'intérieur du formulaire produit, un client qui utilise le bouton de paiement dynamique emporte quand même une date.

**Ce qu'il vous coûte.** Vous demandez un engagement avant même que le panier n'existe, ce qui est une friction au point le plus précoce. Et sur les commandes multi-articles, la forme n'est pas la bonne : un client qui achète quatre choses ne veut pas choisir quatre dates, sauf si les articles partent réellement séparément.

## Panier

Une date pour la commande, choisie une fois que tout est dans le panier.

**Choisissez-le quand la date s'applique à toute la commande** plutôt qu'à des articles individuels — une livraison de courses hebdomadaire, une commande de traiteur, un seul créneau planifié.

**Ce qu'il vous coûte, et c'est là que les gens se font avoir.** Le bouton **Buy Now** saute entièrement le panier. Un client qui l'utilise atterrit directement au checkout sans que votre sélecteur de page panier ne se soit affiché, et cette commande arrive sans date attachée. Vous ne verrez pas d'erreur. Vous verrez une commande que vous ne pouvez pas planifier.

Il y a aussi le problème du type de panier. L'approche documentée par Shopify pour un sélecteur de date dans le panier ne fonctionne que sur la *page* panier — son article d'aide indique clairement qu'elle ne fonctionnera pas avec les paniers en tiroir ou en pop-up. Beaucoup de boutiques le découvrent après être passées à un panier en tiroir pour des raisons sans rapport.

## Checkout — Shopify Plus

Le sélecteur apparaît à l'étape finale, dans le checkout lui-même.

**Choisissez-le quand la date est une confirmation plutôt qu'un choix**, ou quand vous voulez garder le chemin vers le panier épuré. C'est aussi le seul emplacement qui attrape chaque commande quel que soit le chemin emprunté par le client, puisque tout le monde passe par le checkout.

**Le piège pratique.** Activer la fonctionnalité ne suffit pas. Le sélecteur n'apparaît que si les dates de livraison sont activées, qu'au moins une règle de disponibilité existe, que l'interrupteur checkout est activé, *et* que le bloc a été placé dans l'éditeur de checkout de Shopify. Trois de ces conditions vivent dans l'app et la quatrième vit dans Shopify, ce qui explique pourquoi « je l'ai activé et rien ne s'est passé » est de loin la question la plus fréquente sur cet emplacement.

**Ce qu'il vous coûte.** Le client est aussi avancé dans le tunnel qu'il le sera jamais. Une date qui s'avère indisponible à ce moment-là est la pire découverte possible — c'est exactement pour cela que la capacité doit aussi être appliquée en amont, et pas seulement à la dernière étape. Et cela exige Plus.

## Par article ou par commande ?

L'emplacement et la *granularité* de la date sont deux décisions distinctes, mais elles se contraignent mutuellement, et les choisir indépendamment est la façon dont les boutiques finissent par reconstruire tout cela deux fois.

**Par commande** signifie une date pour tout le panier. Cela convient aux épiceries, au traiteur, aux paniers hebdomadaires — tout ce qui part dans une camionnette un jour donné. Les emplacements panier et checkout s'y prêtent naturellement, car à ce stade le panier est connu.

**Par article** signifie que chaque ligne porte sa propre date. Cela convient aux boutiques où les articles ont réellement des temps de production différents : un coussin en stock qui part demain à côté d'un fauteuil tapissé qui prend dix semaines. Cela ne fonctionne vraiment que sur la **page produit**, car c'est le seul endroit où le client regarde un article unique et son propre délai.

L'erreur est de choisir des dates par article puis de les collecter dans le panier. On pose plusieurs fois la même question au client, et les réponses sont difficiles à réconcilier avec une tournée de livraison unique. Si les articles partent ensemble, une seule date est le modèle honnête. S'ils partent réellement séparément, dites-le au niveau du produit.

## La panne dont personne ne parle

Posez la question dans n'importe quelle communauté Shopify et vous trouverez les deux mêmes fils encore et encore : *la date que j'ai choisie dans le panier n'apparaît pas au checkout*, et *la date n'est pas enregistrée sur la commande*.

C'est le vrai risque avec les dates de livraison, et il ne s'agit pas d'emplacement — il s'agit de savoir si la valeur survit aux sauts. Une date est collectée dans la vitrine, doit atteindre le checkout, doit être écrite sur la commande, et doit atteindre ce dans quoi vous travaillez réellement : une vue admin, un tag de commande, un export CSV pour la tournée.

Cassez n'importe quel maillon et le sélecteur a toujours l'air de fonctionner. Le calendrier s'affiche, le client choisit, la commande se termine. Vous le découvrez sur la table d'emballage.

Quand vous évaluez une approche — un snippet de thème, une app, une extension sur mesure — la question n'est pas « est-ce que le calendrier s'affiche ». C'est : **passez une commande de test, puis vérifiez la commande dans votre admin, vérifiez ses tags, et vérifiez l'export CSV.** Si la date est dans les trois, la chaîne tient.

## Choisir

| Votre situation | Emplacement |
| --- | --- |
| La date décide de l'achat (gâteaux, fleurs, événements) | **Page produit** |
| Une date pour toute la commande (courses, traiteur, paniers hebdomadaires) | **Panier** |
| Vous utilisez beaucoup Buy Now / le paiement dynamique | **Page produit**, ou checkout sur Plus |
| Vous avez un panier en tiroir ou en pop-up | **Page produit** ou checkout — testez l'emplacement panier avant de compter dessus |
| La date confirme quelque chose de choisi plus tôt | **Checkout** (Plus) |
| Vous voulez que chaque commande porte une date, sans exception | **Checkout** (Plus), avec la capacité appliquée en amont |
| Pas sur Plus et votre personnalisation de checkout vient de casser | **Page produit ou panier** — la voie checkout ne vous est pas ouverte |

La plupart des boutiques se posent sur produit ou panier. Les boutiques Plus finissent généralement avec deux emplacements, pas un.

## Comment cela fonctionne dans OrderRules

Les trois emplacements lisent les **mêmes** règles de disponibilité, délais, heures limites, dates de fermeture et capacité. Il n'y a pas de seconde configuration à maintenir, et aucun moyen pour la vue checkout de contredire la vue produit, puisqu'elles lisent une source unique.

- Une date choisie plus tôt **est reportée**. Au checkout, le client la confirme au lieu de choisir à nouveau, et lorsque les articles portent leurs propres dates, le checkout les affiche en confirmation en lecture seule.
- **La capacité s'applique partout.** Une date complète est grisée dans le sélecteur produit, dans le panier et au checkout.
- **La date atteint les endroits depuis lesquels vous travaillez vraiment** — enregistrée sur la commande, ajoutée en [tag de commande](/docs/delivery/order-auto-tagging), et incluse dans l'[export CSV](/docs/delivery/carrier-csv-export) pour votre tournée.
- Sur Plus, l'[emplacement checkout](/docs/delivery/delivery-date-at-checkout) est un ajout plutôt qu'un remplacement. Sur tous les autres forfaits, les sélecteurs produit et panier fonctionnent exactement comme avant.

Si votre contrainte porte sur ce que vous pouvez produire un jour donné plutôt que sur les jours où vous livrez, c'est un réglage différent — voir [date de commande ou date de livraison](/blog/order-date-vs-delivery-date), qui traite du comptage d'une limite quotidienne sur la date de livraison plutôt que sur la date de commande.

## La limite honnête

Une chose mérite d'être dite clairement, car elle s'applique où que vous placiez le sélecteur.

La capacité est appliquée au checkout, et elle tient pour tous les cas normaux, y compris les checkouts express. Ce qu'elle ne fait pas, c'est poser un verrou. La validation du checkout lit un instantané de ce qui est déjà réservé : deux clients qui finalisent leur commande à peu près à la même seconde, pour la même date, avec une seule place restante, peuvent donc passer tous les deux.

Il faut des checkouts quasi simultanés sur une date réduite à sa dernière place, c'est donc rare. Mais ce n'est pas impossible, et là où la capacité d'une date est faible, mieux vaut la dimensionner avec une place de marge plutôt qu'au maximum exact. Une app qui vous dit le contraire prétend quelque chose que la plateforme n'offre pas.

## Pour aller plus loin

- [Date de livraison au checkout](/docs/delivery/delivery-date-at-checkout) — l'emplacement Plus, et les quatre conditions qu'il exige
- [Démarrer avec les dates de livraison](/docs/delivery/getting-started-delivery-dates) — les sélecteurs produit et panier, sur n'importe quel forfait
- [Installation du theme app block](/docs/delivery/theme-app-block-setup) — placer le bloc dans votre thème
- [Limites de capacité de livraison](/docs/delivery/capacity-limits) — pourquoi une date est grisée quand elle est complète
- [Les meilleures apps de sélecteur de date Shopify](/blog/best-shopify-delivery-date-picker-apps) — si vous cherchez encore un outil