Weldom, réseau de magasins de proximité
À l’origine le service et les les outils pour le rendre possible n’existait pas. Les collaborateurs n’avaient aucun moyen de coordonner la préparation d’une commande : pas de visibilité partagée, pas de stock synchronisé, pas de notification.
On est intervenus sur tout le périmètre : conception des usages métier, architecture technique, développement, intégration dans le SI existant.
Au final : 5 applications distinctes couvrant la préparation de commande, la remise au client, la gestion du programme de fidélité, le stock produit et les retours.
Dès qu’une commande est passée en ligne, le préparateur reçoit une alerte. Il scanne les articles avec un terminal Zebra ou un smartphone Android, le stock se met à jour instantanément. Et les autres membres de l’équipe voient en direct si la commande est déjà prise en charge.
Si quelqu’un est interrompu en pleine préparation, une autre personne peut reprendre exactement là où il s’était arrêté. L’état est partagé en temps réel entre tous les appareils connectés au même magasin.
L’application de remise permet d’attester du retrait et de traiter le paiement selon le mode retenu : encaissement sur place ou validation d’un paiement déjà effectué en ligne.
Les retours se gèrent directement depuis une application dédiée : scan des articles, déclenchement du remboursement, ré-injection immédiate en stock. En parallèle, une application de gestion de la fidélité permet de créer ou modifier un compte client et d’ajuster ses préférences de communication.
Tenir une promesse de 2h à l’échelle d’un réseau national, ça ne s’improvise pas côté infrastructure.
L’architecture repose sur un système de messaging événementiel (Google Cloud Pub/Sub) qui capte chaque modification du cycle de vie d’une commande côté Magento et la propage instantanément. Un applicatif Node.js agit comme orchestrateur : il reçoit ces événements, applique la logique métier, puis redistribue l’information aux bonnes applications via des souscriptions GraphQL maintenues en WebSocket.
Ce qui rend le système scalable, c’est la notion de channel par magasin. Chaque point de vente dispose de son propre canal de diffusion. Par exemple, les événements du magasin de Linselles ne transitent pas par les écrans des autres magasins. Il y a 300 magasins donc 300 canaux isolés chacun avec ses propres abonnés connectés en temps réel. Ainsi la charge est distribuée entre les magasins et les flux temps réels sont ciblées.
Grâce a cette infrastructure tous les écrans (préparation, remise, stock, retours) reflètent l’état réel d’une commande à l’instant T, sans polling ou sans rafraîchissement manuel.
Applications mobiles
Magasins
collaborateurs actifs
flux temps réels
Weldom avait déjà un SI en production : Magento pour le site public et la prise de commande, une base de données de fidélité, des stocks gérés par magasin. L’enjeu n’était pas de tout remplacer mais d’y greffer une couche temps réel sans rien casser.
Le point d’entrée naturel était Magento. Chaque événement du cycle de vie d’une commande déclenche un message publié dans un système Pub/Sub. Un applicatif Node.js reçoit ces messages, applique la logique métier et redistribue l’information aux applications mobiles via des souscriptions GraphQL. Les cinq applications sont ainsi tenues à jour en continu, sans interroger Magento à intervalles réguliers.
Elles sont aussi connectées à la base de fidélité client et aux stocks par magasin, mis à jour à chaque scan d’article, que ce soit en préparation ou en retour. La synchronisation est bidirectionnelle : quand un collaborateur scanne un article, le stock descend immédiatement côté Magento. Le client qui navigue au même moment voit le stock réel.
Les cinq applications partagent une base de code unique, construite avec Ionic et Capacitor, différenciée par rôle via SSO. Ce choix a permis de déployer vite sur 300 magasins, de maintenir une cohérence d’expérience entre les services, et de limiter le coût des évolutions futures. Un seul pipeline, cinq surfaces métier.
Le scénario nominal (commande passée, préparée, remise) n’est qu’une minorité des cas réels. On l’a compris assez vite en allant écouter les équipes terrain.
Avant de faire la conception UX du projet, nous avons passé du temps en magasin avec les collaborateurs. Notamment pour analyser ce qui se passe vraiment quand la journée type. Ce sont ces échanges qui ont fait émerger les vrais scénarios qui sortent du parcours idéal.
Voici quelques exemples de cas réels que nous avons identifiés et pris en compte dans les applications :
Chacun de ces cas a été remonté du terrain et nous avons essayé de les prendre en compte dans les applications. C’est comme cela que nous avons déployé un système fiable à l’échelle d’un réseau national.
Une app Android native conçue et développée par Yoozly : optimisation de la préparation Click & Collect, gestion des stocks temps réel et scan contextuel Zebra pour optimiser les process internes.
Une application performante conçue sur Flutter orchestrant des flux temps réel GTFS-RT et s’appuyant sur une infrastructure souveraine SecNumCloud haute disponibilité afin de gérer les pics de trafic jusqu’à 50k usagers.
Yoozly accompagne Rennes School of Business et ses 5 000 étudiants dans sa transformation digitale avec la création d’une application mobile Flutter avec architecture Cloud Azure sécurisée.
Miroir de l’expérience client offerte par SALTI, l’espace client propose une app mobile iOS/Android et un accès web unifiés pour suivre et agir sur ses locations et valider ses devis en ligne.
Nos experts vous accompagnent sur le pilotage de votre roadmap stratégique en mettant la valeur produit au coeur des décisions.