Paniers abandonnés : les voir, les relancer

Dans l'exploitation quotidienne d'un commerce en ligne, la perte de commandes en cours d'élaboration représente une friction majeure. Conçue par Alexandre Carette, la plateforme CodeMyShop aborde cette réalité opérationnelle avec un outillage dédié aux relances commerciales. Cette fonctionnalité est actuellement disponible en version bêta. Elle ne prétend pas remplacer les politiques de fidélisation complexes, mais apporte un cadre sobre et direct pour réactiver les intentions d'achat inachevées. En tant que PaaS e-commerce open source, sous licence AGPL-3.0, présenté comme souverain et européen, conçu en France, CodeMyShop repose sur une stack 100 % TypeScript articulée autour de Nuxt 4, Drizzle, PostgreSQL, avec IA intégrée. La solution applique 0 % de commission sur les ventes et propose un auto-hébergement gratuit, accessible directement via le code source public de CodeMyShop sous licence AGPL-3.0 dans son édition Community.

L'abandon de commande en ligne : le problème concret du marchand

Pour tout commerçant, qu'il vende à des particuliers ou à des professionnels, l'interruption du parcours d'achat constitue un manque à gagner immédiat. Lorsqu'un visiteur remplit une commande puis quitte le site sans finaliser son règlement, le marchand se retrouve souvent sans visibilité. Le problème ne tient pas seulement au panier non payé : il réside dans l'incapacité d'analyser ce qui s'est passé et d'intervenir au bon moment avec le bon message. Dans une logique de canal direct, comme nous l'évoquions dans notre analyse sur le tunnel de conversion et la progression de l'attention, chaque étape franchie par l'acheteur a nécessité des efforts d'acquisition et de catalogage.

Le commerçant fait face à plusieurs difficultés concrètes :

• L'absence de centralisation : les paniers inachevés restent éparpillés dans la base de données sans vue unifiée pour l'équipe commerciale.
• Le risque d'écrire à l'aveugle : relancer un client sans savoir si un message a déjà été envoyé engendre des doublons embarrassants et dégrade l'image de marque.
• La confusion entre panier grand public et demande d'affaires : dans le commerce interentreprises, un panier abandonné est fréquemment une estimation non validée qui exige un traitement adapté.
• La crainte des envois massifs mal maîtrisés : lancer une campagne sans vérifier au préalable le rendu réel auprès d'adresses de contrôle expose à des anomalies de diffusion.

Sans outil dédié, le commerçant est contraint de surveiller manuellement les lignes de commande non finalisées ou de négliger totalement ces contacts. Les équipes techniques, de leur côté, doivent régulièrement bâtir des requêtes spécifiques pour extraire les e-mails exploitables, ce qui alourdit la maintenance sans offrir d'autonomie au gestionnaire de la boutique.

La gestion des paniers abandonnés dans CodeMyShop : ce que fait la fonctionnalité

La fonctionnalité intégrée dans CodeMyShop se concentre sur un ensemble strict et vérifié de capacités. Elle est intégrée dans l'édition Community de la plateforme, ce qui garantit aux équipes de développement une visibilité complète sur la mise en œuvre technique et les schémas de données.

Voici les capacités effectives du système :

• Affichage de la liste de tous les paniers constitués sur la boutique.
• Filtrage multicritère de cette liste par client, par adresse e-mail ou par nombre d'articles.
• Indication claire du nombre de relances déjà envoyées pour chaque panier, évitant ainsi toute sollicitation redondante.
• Réglage des critères de relance permettant d'encadrer les déclenchements : ancienneté du panier, montant minimum et délai entre deux relances.
• Envoi des e-mails de relance avec un mode test pour contrôler la diffusion avant tout contact réel avec les acheteurs.
• Prise en charge de la relance des demandes de devis restées sans suite, un besoin crucial pour les circuits B2B.

En conservant une logique d'autonomie, cette approche évite de dépendre d'outils tiers fermés. Cela s'inscrit pleinement dans la démarche d'indépendance technique analysée dans notre dossier sur la comparaison entre les architectures headless et les plateformes centralisées.

À retenir : la relance des paniers dans CodeMyShop centralise les commandes non finalisées et les devis en attente, tout en sécurisant chaque contact grâce à un mode test et un comptage strict des messages déjà expédiés.

Parcours opérationnel : comment exploiter la relance écran par écran

L'exploitation de la fonctionnalité s'effectue au sein de l'environnement d'administration. Le marchand et le développeur disposent d'écrans pour consulter les paniers, régler les critères de relance et déclencher les envois.

L'écran de consultation et de filtrage des paniers

Le premier écran affiche la liste de tous les paniers. Cette vue tabulaire offre une lecture directe des encours de la boutique. Pour traiter efficacement des volumes variables de données, le gestionnaire dispose de filtres ciblés. Il peut isoler les enregistrements par client, rechercher une adresse e-mail précise ou trier les lignes selon le nombre d'articles présents dans la commande. Chaque ligne récapitule l'état du panier et mentionne explicitement le nombre de relances déjà envoyées. Cette information visuelle permet d'identifier d'un coup d'œil les dossiers n'ayant encore reçu aucun rappel et ceux qui ont déjà fait l'objet d'échanges.

Les critères de relance

L'écran de relance réunit, au-dessus de la liste des paniers à relancer, les paramètres gouvernant l'admissibilité des paniers à une relance. Plutôt que de contacter indistinctement tous les visiteurs, le commerçant configure ici trois critères fondamentaux :

• L'ancienneté du panier : permet de cibler les paniers selon le temps écoulé depuis leur création ou leur dernière modification.
• Le montant minimum : permet de concentrer les relances sur les commandes dont la valeur globale justifie une action commerciale.
• Le délai entre deux relances : permet d'écarter de la liste les paniers relancés trop récemment.

L'envoi et le mode test

Ce même écran régit l'envoi effectif des messages. C'est ici que l'opérateur prépare la diffusion des courriers électroniques vers les acheteurs sélectionnés. Cet écran met à disposition un mode test indispensable : avant de transmettre les messages aux destinataires finaux, le marchand peut expédier des exemplaires de vérification vers une adresse de test qu'il saisit. Ce contrôle préventif assure la conformité du texte, la justesse du nombre d'articles et du montant affichés et le bon fonctionnement des liens de reprise du panier.

Le traitement spécifique des demandes de devis

Un volet de l'interface est dédié aux demandes de devis restées sans suite. Dans les modèles de vente interentreprises, la constitution d'un panier débouche fréquemment sur une demande de tarification formelle. Cet écran permet de repérer les devis transmis pour lesquels aucun retour n'a été enregistré et d'exécuter une relance ciblée. Le tableau ci-dessous récapitule les fonctionnalités de ces différents écrans de travail :

Pour qui c'est fait, et pour qui ça ne l'est pas

L'intégration native de la relance répond à des contextes d'exploitation bien précis. Déterminer si cette fonction convient à votre structure évite de fausses attentes et permet d'adopter l'organisation la plus pertinente face aux enjeux de souveraineté numérique, comme nous l'avons souligné dans notre étude sur les moyens de s'affranchir des intermédiaires en e-commerce.

Le dispositif est particulièrement adapté pour :

• Les PME e-commerce recherchant un mécanisme direct et lisible, sans devoir installer d'extensions tierces complexes.
• Les commerçants opérant en B2B qui gèrent simultanément des commandes directes et des demandes de devis nécessitant un suivi commercial régulier.
• Les marchands souhaitant conserver une totale maîtrise sur le moment exact où les relances partent vers leurs clients.
• Les développeurs exploitant Nuxt 4 et Drizzle qui souhaitent auditer le code de relance au sein de l'édition Community sous licence AGPL-3.0 sans dépendre d'une couche logicielle opaque.

En revanche, le dispositif ne convient pas aux cas d'usage suivants :

• Les équipes recherchant des scénarios comportementaux automatisés multi-étapes avec déclenchements programmés à la minute près.
• Les organisations exigeant une automatisation intégrale sans surveillance humaine depuis le panneau d'administration.
• Les structures nécessitant une synchronisation multi-boutiques avec des règles de routage spécifiques non couvertes par les trois critères de base (ancienneté, montant, délai).

Les limites actuelles du dispositif, analysées en toute franchise

Adopter une solution open source exige de connaître précisément ses frontières techniques. La fonctionnalité de relance des paniers dans CodeMyShop est en phase bêta, et plusieurs limites opérationnelles doivent être prises en compte par les exploitants :

Premièrement, aujourd'hui l'envoi se déclenche depuis le hub. L'envoi entièrement automatique n'est pas encore actif. Cela signifie qu'un opérateur doit se connecter à l'interface pour initier l'expédition des e-mails une fois les critères validés. Il n'existe pas, à ce jour, de processus d'arrière-plan autonome assurant la distribution continue des messages sans action manuelle dans le hub.

Deuxièmement, les critères de sélection se limitent strictement aux paramètres définis : l'ancienneté du panier, le montant minimum et le délai entre deux relances. Il n'y a pas de segmentation par zone géographique ou par catégorie de produits. Le montant pris en compte est une estimation calculée à partir du prix catalogue des articles du panier, et non le total exact du panier (remises comprises).

Troisièmement, le mode test permet de contrôler la bonne réception des gabarits mais requiert une manipulation délibérée de l'utilisateur pour basculer vers l'expédition réelle. Cela demande une rigueur d'exécution de la part de l'équipe marchande.

Architecture technique et perspectives pour la reprise de commande

L'intégration de la gestion des paniers au sein d'une stack 100 % TypeScript (Nuxt 4, Drizzle, PostgreSQL) offre aux développeurs un confort d'audit et une cohérence architecturale rare. Contrairement aux systèmes dispersés où les données des paniers transitent par de multiples routeurs externes, les paniers, commandes et devis sont lus directement dans la base PostgreSQL de la boutique.

La présence d'un mode test natif illustre cette volonté de robustesse : tester ses e-mails en environnement contrôlé avant de solliciter un client réel est un prérequis pour préserver la délivrabilité du domaine expéditeur. Cette approche rejoint les principes d'autonomie développés dans notre réflexion sur la maîtrise de son infrastructure face aux écosystèmes fermés.

Pour mettre en place cette solution sur votre propre infrastructure ou tester l'environnement complet, vous pouvez consulter le code source public de la plateforme ou démarrer sur CodeMyShop dès maintenant.

À lire aussi

• PrestaShop vs Shopify en 2026 : posséder sa boutique ou la louer ?