Le contexte
Un marchand découvre souvent les problèmes trop tard : une rupture de stock repérée au moment où un
client s’en plaint, une demande de retour vue trois jours après, une grosse commande passée inaperçue
un dimanche. Les emails natifs de PrestaShop existent, mais ils se noient dans la boîte de réception
et ne se configurent pas finement.
Le défi
Router les événements opérationnels d’une boutique (nouvelle commande, changement de statut,
stock bas, demande de retour, nouveau client, message de contact) vers les canaux où l’équipe
travaille vraiment (Slack, Discord ou email) avec des règles du type « si commande > 500 €,
prévenir le canal #ventes ». Et surtout : que l’envoi d’une alerte ne coûte jamais une milliseconde
au parcours d’achat.
Chaque événement est capté par hook puis déposé dans une file d’attente durable ; un drainer
(cron sécurisé par jeton) se charge de la livraison, avec reprise en cas d’échec. Le back-office
embarque un dashboard Vue 3 : historique des alertes envoyées, statut de livraison et rejeu
d’une alerte en un clic. L’architecture est en PSR-4 (Compat, Installer, Queue, Pipeline, Rule,
Channel…) pour couvrir PrestaShop 1.7.7 à 9 et PHP 7.4 à 8.3.
Comme pour Cockpit Analytics, le développement se fait en binôme avec Claude Code, sur la base
des conventions communes de la gamme Cockpit (structure, i18n .xlf, packaging Addons).
Ce que j’en retire
La conception d’un pipeline d’événements fiable dans les contraintes réelles de PrestaShop
(hébergements mutualisés, pas de worker permanent) : c’est le genre d’architecture directement
transposable aux besoins sur-mesure de mes clients : notifications logistiques, synchronisations,
intégrations métier.