LNK Estimated Delivery, date de livraison estimée par transporteur et par zone

La plupart des boutiques affichent une phrase fixe écrite dans le thème. Cette phrase ignore le jour de la commande et les jours fériés comme le 15 août. Elle annonce le même délai pour la Corse et pour le centre de Paris.

Le module s'appuie sur les informations que vous connaissez :

• le temps de préparation d'une commande, par transporteur ;
• le temps de transport, par transporteur et par zone ;
• l'heure à laquelle vous arrêtez d'expédier pour la journée ;
• vos jours travaillés et vos jours de fermeture.

Il en déduit une date avec le calcul que vous feriez à la main, refait à chaque affichage de page.

Le client compare les offres sur la fiche produit, et le délai fait partie de sa comparaison. Le module s'y place dès l'installation, sur le point d'accroche standard de PrestaShop.

Quatre présentations sont proposées dans le back-office :

• badge en ligne, une ligne discrète avec l'icône de camion ;
• carte frise, avec les dates de commande, préparation, expédition et livraison ;
• compte à rebours, par exemple « Commandez dans les 02:14:37 pour une expédition aujourd'hui » ;
• texte simple, sans cadre, pour un thème sobre.

À l'étape livraison du tunnel de commande, le module affiche la date sous chaque transporteur, avec son propre délai de préparation et son propre temps de transit. La plupart des modules n'exploitent pas cet emplacement.

Le client compare alors deux prix et deux dates. C'est à cette étape qu'il choisit l'option plus chère ou qu'il abandonne son panier.

Le calcul se fait en jours ouvrés. Vous cochez les jours travaillés et le module saute les autres. Il saute aussi les jours fériés, avec un calendrier par pays d'expédition :

• France, Belgique, Luxembourg, Suisse, Allemagne, Espagne, Italie, Portugal, Pays-Bas, Royaume-Uni ;
• ou aucun calendrier, si vous préférez saisir vos propres dates.

Les fêtes mobiles (Pâques, Ascension, Pentecôte, Fête-Dieu) sont calculées chaque année. Elles restent justes en 2030 comme en 2026, sans mise à jour du module. Pour le Royaume-Uni, les jours fériés qui tombent un week-end sont reportés automatiquement, selon l'usage local.

Vos fermetures exceptionnelles (congés d'été, inventaire, pont) s'ajoutent en une ligne.

Chaque transporteur a son heure limite. Une commande passée après cette heure part le jour ouvré suivant. Avec une heure limite à 14 h, la date affichée se met à jour d'elle-même à 14 h 01.

En présentation « compte à rebours », le client voit le temps qui lui reste. Si l'heure limite passe pendant qu'il consulte la page, le bloc affiche la nouvelle date sans rechargement. Le serveur calcule les deux états à l'avance et le navigateur passe de l'un à l'autre, la date affichée reste donc toujours exacte.

L'heure limite est lue dans le fuseau horaire de votre boutique. Le fuseau du serveur et celui du visiteur n'entrent pas dans le calcul, et un hébergement réglé en UTC ne décale donc rien.

Après la commande, le module affiche une frise de suivi sur la page de confirmation et sur le détail de la commande. Elle reprend les étapes commande, préparation, expédition et livraison.

Les étapes franchies portent les dates réelles, lues dans l'historique de la commande. Les étapes à venir portent la date estimée, calculée depuis la date de commande. Cette date reste identique d'une visite à l'autre et ne recule pas quand le client rafraîchit sa page.

Le client suit sa commande lui-même, ce qui vous évite une partie des courriels « où en est ma commande ? ».

Les PDF comportent une ligne avec la date estimée, remplacée par la date réelle une fois la commande livrée. Cet emplacement s'active ou se désactive comme les autres.

Le back-office règle la couleur d'accent, la couleur du texte, le fond, la bordure, l'arrondi, les marges, la taille de police, la graisse, l'alignement, l'icône et la pleine largeur.

L'aperçu de la page de configuration est rendu par le serveur, avec les gabarits du front et votre transporteur par défaut. Il montre exactement ce que verra le client.

Aucun fichier n'est écrit sur le disque. Les réglages sont transmis en variables CSS posées sur le bloc. Le module fonctionne donc correctement en multiboutique, et un CDN ne peut pas servir un ancien habillage.

Deux paquets du même module, un par branche de PrestaShop :

Sur PrestaShop 9, la page de configuration est un contrôleur Symfony natif, avec le gabarit Twig et la mise en page du nouveau back-office. Le paquet 2.9.0 ne s'installe que sur PrestaShop 9 ; aucun fichier Symfony n'est livré aux boutiques 1.7 et 8.

Avant chaque publication, chaque version listée est installée, configurée, affichée puis désinstallée dans notre matrice d'intégration.

Ce module n'installe aucun override. Il ne contient pas de dossier override/ et se branche uniquement sur les points d'accroche prévus par PrestaShop.

Pour une agence, cela écarte plusieurs problèmes :

• le conflit avec un autre module qui surchargerait la même classe ;
• les fichiers orphelins après une mise à jour de PrestaShop ;
• le dossier override/ à purger avant une migration.

Chiffres mesurés sur le module livré, compressé en gzip (niveau 9). En front : une feuille de style de 2 034 octets (2,0 Ko) et deux scripts sans jQuery. Le compte à rebours (1 144 octets, 1,1 Ko) ne se charge que si cette présentation est choisie, sur la fiche produit ou dans le tunnel ; sinon, aucune page n'en charge un octet. Celui qui place la date sous chaque transporteur (978 octets) ne se charge que dans le tunnel de commande. L'estimation est calculée par le serveur et écrite dans le HTML de la page : aucun appel externe, aucun CDN.