Click-and-collect omnicanal : stocks magasin en temps réel, retrait rapide en caisse
Un client qui arrive en magasin pour un article indisponible renonce souvent à sa commande. La synchronisation ERP/WMS en temps réel et une interface caisse pensée pour le vendeur — pas pour le DSI — sont les deux conditions non négociables d'un click-and-collect qui convertit.
Nos clients types
Le click-and-collect est devenu un standard de service dans le retail physique. Mais derrière ce succès se cache une réalité opérationnelle souvent désastreuse pour les enseignes qui n'ont pas investi dans l'intégration de leurs systèmes. Le problème numéro un est la désynchronisation des stocks. L'ERP central — Cegid Y2, SAP Business One, Sage X3 selon les enseignes — met à jour les niveaux de stock quelques fois par jour selon les cycles de synchronisation. Le WMS du dépôt central (Manhattan Associates, Reflex, Hardis) fonctionne avec ses propres cycles de batch. Les caisses magasin (Cegid POS, NCR, Zelty) remontent les ventes en temps différé. Résultat : le stock affiché sur le site e-commerce reflète une réalité vieille de plusieurs heures. Pendant les périodes de forte rotation (soldes, Black Friday, Noël), ce décalage génère des commandes click-and-collect en rupture réelle à l'arrivée du client. Le problème numéro deux est l'expérience côté magasin. Dans la majorité des enseignes non intégrées, les commandes click-and-collect arrivent au magasin par email ou via une interface web basique, sont imprimées et glissées dans un bac à commandes en attente. Le vendeur qui réceptionne le client doit retrouver la commande papier, localiser l'article dans le stock magasin (parfois sans terminal dédié), et gérer le règlement éventuel du solde. En période de pointe, ce processus prend plusieurs minutes — durée incompatible avec un service perçu comme premium. Le problème numéro trois est la perte de l'opportunité commerciale. Le moment du retrait en magasin est l'un des rares points de contact physique avec un client qui a déjà décidé d'acheter. C'est le moment idéal pour proposer un produit complémentaire, présenter une nouveauté, ou recueillir un avis. Sans interface caisse intégrée affichant le profil du client (historique d'achats, programme de fidélité, préférences), le vendeur opère en aveugle et la recommandation est générique ou absente. Le problème numéro quatre est l'absence de communication proactive avec le client. Un client qui a commandé à 9h pour un retrait en matinée et ne reçoit aucune confirmation de mise à disposition avant midi s'impatiente — et parfois annule. Les notifications automatisées (email, SMS, push) à chaque changement de statut de la commande (confirmée, en préparation, prête, non retirée) réduisent les contacts entrants au service client.
La solution Nehos repose sur une architecture middleware d'orchestration centrale qui agrège les flux de stock de tous les systèmes en présence et expose une API unifiée consommée par le site e-commerce, les interfaces caisses magasin et les systèmes de notification. Le middleware est développé en Nest.js (TypeScript) et déployé sur un hébergement français (par exemple OVHcloud Managed Kubernetes). Il s'interface avec l'ERP via l'API REST propriétaire de Cegid Y2 ou via les APIs BAPI de SAP selon l'existant, avec le WMS via webhook ou polling EDI EDIFACT INVRPT (Inventory Report), et avec les caisses magasin via leur API locale ou via un agent léger installé sur chaque terminal. La synchronisation des niveaux de stock est assurée toutes les 5 minutes en régime normal, avec un fallback WebSocket pour les pics de charge (Black Friday, soldes) ramenant la latence à quelques dizaines de secondes. Côté site e-commerce (Shopify, Prestashop, WooCommerce ou custom), l'intégration s'appuie sur une API de disponibilité par SKU par magasin, consommée via un widget JavaScript de sélection de magasin. Le client voit en temps réel la disponibilité dans les magasins les plus proches (géolocalisation IP ou adresse saisie), avec un indicateur de délai de préparation (standard 2h, express 30 min selon les magasins configurés). La réservation du stock est déclenchée immédiatement à la validation du panier, bloquant l'unité dans le WMS pour une durée définie par la politique commerciale. L'interface caisse magasin est une PWA iPad (React + Tailwind), compatible avec les lecteurs de code-barres Zebra et les imprimantes thermiques Epson. Elle affiche les commandes click-and-collect du jour par ordre de priorité (retrait imminent en tête), le profil client (prénom, historique des dernières commandes, score de fidélité, préférences déclarées), et les suggestions de produits complémentaires générées par un modèle de recommandation léger entraîné sur l'historique d'achats. Le vendeur valide le retrait en scannant le QR code client (affiché dans l'email de confirmation ou l'app mobile de l'enseigne), ce qui déclenche automatiquement la mise à jour du statut commande et la notification client. Les notifications sont orchestrées via Brevo (transactionnel email + SMS) ou Twilio selon l'existant. Cinq événements déclenchent une notification automatique : commande reçue, commande en cours de préparation, commande prête au retrait, commande non retirée sous 24h (relance), commande annulée et remboursement initié. Ces communications sont personnalisées avec le prénom du client, le nom du magasin et les horaires d'ouverture du jour.
5 min
synchronisation du stock ERP/WMS en régime normal, avec bascule WebSocket pour les pics de charge
API stock
disponibilité par SKU et par magasin, consommée par le site, la caisse et les notifications
PWA iPad
interface caisse sur les tablettes existantes, sans remplacer les terminaux de caisse
5 événements
notifications client : commande reçue, en préparation, prête, non retirée, annulée
#Le problème : pourquoi click-and-collect omnicanal est un enjeu critique
Le click-and-collect est devenu un standard de service dans le retail physique. Mais derrière ce succès se cache une réalité opérationnelle souvent désastreuse pour les enseignes qui n'ont pas investi dans l'intégration de leurs systèmes.
Le problème numéro un est la désynchronisation des stocks. L'ERP central — Cegid Y2, SAP Business One, Sage X3 selon les enseignes — met à jour les niveaux de stock quelques fois par jour selon les cycles de synchronisation. Le WMS du dépôt central (Manhattan Associates, Reflex, Hardis) fonctionne avec ses propres cycles de batch.
Les caisses magasin (Cegid POS, NCR, Zelty) remontent les ventes en temps différé. Résultat : le stock affiché sur le site e-commerce reflète une réalité vieille de plusieurs heures. Pendant les périodes de forte rotation (soldes, Black Friday, Noël), ce décalage génère des commandes click-and-collect en rupture réelle à l'arrivée du client.
Le problème numéro deux est l'expérience côté magasin. Dans la majorité des enseignes non intégrées, les commandes click-and-collect arrivent au magasin par email ou via une interface web basique, sont imprimées et glissées dans un bac à commandes en attente. Le vendeur qui réceptionne le client doit retrouver la commande papier, localiser l'article dans le stock magasin (parfois sans terminal dédié), et gérer le règlement éventuel du solde. En période de pointe, ce processus prend plusieurs minutes — durée incompatible avec un service perçu comme premium.
Le problème numéro trois est la perte de l'opportunité commerciale. Le moment du retrait en magasin est l'un des rares points de contact physique avec un client qui a déjà décidé d'acheter. C'est le moment idéal pour proposer un produit complémentaire, présenter une nouveauté, ou recueillir un avis.
Sans interface caisse intégrée affichant le profil du client (historique d'achats, programme de fidélité, préférences), le vendeur opère en aveugle et la recommandation est générique ou absente.
Le problème numéro quatre est l'absence de communication proactive avec le client. Un client qui a commandé à 9h pour un retrait en matinée et ne reçoit aucune confirmation de mise à disposition avant midi s'impatiente — et parfois annule. Les notifications automatisées (email, SMS, push) à chaque changement de statut de la commande (confirmée, en préparation, prête, non retirée) réduisent les contacts entrants au service client.
#Notre approche en 4 phases
#Phase 1 : Audit des flux de stock et cartographie SI (semaines 1-3)
Inventaire des systèmes de gestion de stock existants (ERP Cegid/SAP/Sage, WMS Manhattan/Reflex), analyse des flux EDI inter-systèmes, identification des points de désynchronisation. Définition du modèle de disponibilité stock par magasin et du seuil de réservation.
Voir notre expertise : intégration ERP e-commerce.
#Phase 2 : Développement middleware d'intégration et API stocks (semaines 4-8)
Développement du middleware d'orchestration (Nest.js + TypeScript) exposant une API REST/GraphQL de disponibilité stock par SKU par magasin. Connexion ERP via API propriétaire ou EDI X12/EDIFACT. Synchronisation toutes les 5 minutes avec fallback WebSocket pour les pics de charge.
Voir notre expertise : stratégie omnicanale retail.
#Phase 3 : Développement interfaces e-commerce et caisse (semaines 9-13)
Intégration côté site e-commerce (Shopify ou custom) du widget de sélection de magasin et de disponibilité stock. Développement de l'interface caisse magasin (PWA iPad, compatible lecteur code-barres et imprimante thermique). Connexion au système de notification client (SMS via Twilio, push via Firebase).
Voir notre expertise : synchronisation stocks temps réel.
#Phase 4 : Pilote, formation équipes et déploiement réseau (semaines 14-16)
Pilote sur quelques magasins test (volumes variés), recette avec équipes terrain, ajustements UX interface caisse selon retours vendeurs. Formation des managers et des vendeurs. Déploiement progressif sur l'ensemble du réseau avec activation par vagues de magasins.
Voir notre expertise : interface WMS/ERP e-commerce B2B.
#Repères
| Repère | Ce que c'est |
|---|---|
| 5 min | synchronisation du stock ERP/WMS en régime normal, avec bascule WebSocket pour les pics de charge |
| API stock | disponibilité par SKU et par magasin, consommée par le site, la caisse et les notifications |
| PWA iPad | interface caisse sur les tablettes existantes, sans remplacer les terminaux de caisse |
| 5 événements | notifications client : commande reçue, en préparation, prête, non retirée, annulée |
#Exemple de situation
#Contexte
Une enseigne de magasins avec un site e-commerce, un ERP central, un WMS dans le dépôt et des caisses en magasin. Les commandes click-and-collect arrivent par email dans une boîte partagée consultée de temps en temps, une part des commandes ne peut pas être honorée faute de stock réel, et le retrait en magasin est lent.
#Défi
Réduire le taux de rupture sans refondre le système d'information existant (ERP, WMS et caisses conservés), améliorer l'expérience caisse sans imposer un changement radical aux équipes terrain, et maintenir le click-and-collect actif pendant le déploiement.
#Approche
Middleware d'orchestration Nest.js exposant une API unifiée de disponibilité par SKU et par magasin, connecté à l'ERP, au WMS et aux caisses. Intégration côté site e-commerce par une application privée. Interface caisse PWA déployée sur les tablettes existantes. Notifications SMS et email sur cinq événements. Pilote sur quelques magasins, formation des équipes, puis déploiement par vagues.
#Ce qu'on mesure
Le taux de rupture post-commande web, le temps de retrait en magasin, la satisfaction client sur le click-and-collect, le panier moyen des retraits. On mesure ces points pendant le pilote, avant d'étendre au réseau, sans résultat promis à l'avance.
#Pourquoi Nehos pour click-and-collect omnicanal
Nehos Groupe n'est pas un intégrateur généraliste qui adapte une solution standard à votre contexte. On conçoit des architectures sur mesure, calibrées sur vos contraintes métier, réglementaires et techniques. Chaque projet démarre par un audit de faisabilité qui pose les limites avant les promesses — si le ROI ne tient pas, on le dit avant de signer quoi que ce soit.
Notre méthode ROI-First impose un cadrage chiffré dès la phase d'audit : coût actuel documenté, gains projetés avec hypothèses conservatrices, critères de go/no-go factuels. En production, on mesure les résultats réels et on les compare aux projections — transparence totale, y compris quand les chiffres sont en dessous des attentes.
Nos expertises connexes : synchronisation stocks temps réel, interface WMS/ERP e-commerce B2B, guide click-and-collect retail.
Côté hébergement, nous pouvons déployer chez un hébergeur français (par exemple OVHcloud, datacenters en France) et recourir à des modèles open source (Mistral) quand la performance le permet. Le choix se fait avec vous, selon vos contraintes de souveraineté.
#Pour aller plus loin
Cas d'usage connexes :
Questions & réponses
Questions fréquentes sur le click-and-collect omnicanal
Non — c'est même l'un des principes fondateurs de l'approche Nehos. Le middleware d'intégration s'adapte aux systèmes existants, qu'il s'agisse de Cegid Y2, SAP Business One, Sage X3, Generix ou d'un ERP sur-mesure. La connexion se fait via l'API REST ou SOAP de l'ERP, via des flux EDI EDIFACT (INVRPT pour les stocks, ORDERS pour les commandes), ou via des webhooks selon ce que le système expose. Les caisses magasin ne sont pas remplacées : l'interface caisse click-and-collect est une PWA déployée sur tablette (iPad ou tablette Android), qui coexiste avec la caisse existante. C'est une couche complémentaire, pas un remplacement. Voir notre service intégration ERP e-commerce.
La synchronisation standard est toutes les 5 minutes en régime normal. En période de forte charge (Black Friday, soldes du premier jour, campagne promotionnelle), le middleware bascule automatiquement en mode WebSocket avec une latence de synchronisation fortement réduite pour les SKUs identifiés comme à forte rotation. La réservation du stock intervient à la validation du panier — pas à l'affichage de la disponibilité — ce qui garantit qu'aucune commande n'est confirmée sur un stock déjà épuisé entre deux cycles. On suit le taux de rupture post-commande en régime normal et en pic promotionnel.
Le workflow de non-retrait est entièrement automatisé. Si la commande n'est pas retirée sous 24 heures (délai paramétrable selon la politique commerciale), une notification SMS et email de relance est envoyée avec un lien de report de retrait ou d'annulation. À 48 heures (délai également paramétrable), si le client n'a pas réagi, une notification d'annulation automatique est envoyée, le stock est libéré dans le WMS et le remboursement est initié via l'API Shopify ou la passerelle de paiement. L'équipe magasin reçoit un récapitulatif quotidien des commandes non retirées dans leur tableau de bord. Aucune action manuelle n'est requise.
Oui, sous conditions. Le click-and-collect express (30 minutes ou 1 heure) nécessite un processus de préparation magasin dédié : un emplacement de stock réservé aux commandes web dans l'arrière-boutique, un agent ou vendeur assigné à la préparation express sur les créneaux de pointe, et une notification client en temps réel dès que la commande est prête. Techniquement, l'API de disponibilité stock supporte un flag express_available par magasin, activé selon les plages horaires et la capacité de préparation. On l'active d'abord sur quelques magasins pilotes, puis on l'étend selon l'adoption.
L'intégration fidélité est native dans le design de l'interface caisse. Au moment du retrait, le vendeur voit le solde de points du client, son niveau de fidélité et les avantages disponibles. Les points sont crédités automatiquement à la validation du retrait, via l'API du programme de fidélité (Loyaltylion, Yotpo Loyalty, ou programme sur-mesure). Si le client n'est pas encore membre, le vendeur peut lui proposer l'inscription depuis l'interface caisse. Les données de retrait (date, magasin, produits) sont remontées dans le CRM pour segmentation comportementale (clients click-and-collect vs purement e-commerce vs purement magasin).
Le calendrier est confirmé à l'audit initial et dépend du nombre de magasins. Les premières semaines couvrent l'audit des flux de stock, le développement du middleware d'intégration ERP/WMS et les tests avec le système d'information existant. La phase suivante porte sur l'interface caisse, les notifications et les tests en conditions réelles dans quelques magasins pilotes. La dernière phase est dédiée à la formation des équipes et au déploiement réseau par vagues. Plus le réseau est étendu, plus la phase de déploiement est longue.