Démonstration de la recherche par effet Geiger
Un magasin de vélos avec 150 unités en stock — neuf et occasion confondus — fait face à une question récurrente : où est passé le Lapierre rouge taille M que le client est venu voir ? Le vélo a été déplacé par un vendeur pour un essai, accroché dans une autre zone le temps d’un nettoyage, ou rangé dans la réserve pour libérer l’espace de vente. La recherche à vue prend dix minutes et énerve tout le monde. CRM Cycles Radar résout ce problème en équipant chaque vélo sérialisé d’un tag Bluetooth Low Energy, et en fournissant aux vendeurs une application Android qui les guide vers le bon vélo par effet Geiger — plus on s’approche, plus le téléphone bipe vite.
Côté commerce : l’usage en magasin
Chaque vélo en stock reçoit à la réception un petit tag BLE (~3 g, ~5 €, autonomie 2 ans sur pile bouton CR2032). Le tag est associé à son vélo via le module Tags BLE de CRM Cycles : le vendeur scanne l’ID du tag, le rattache à la fiche du vélo sérialisé, voilà.
Quand un client demande un modèle précis, le vendeur ouvre l’application Radar sur son téléphone Android. Il tape les premières lettres de la marque ou du modèle, sélectionne le vélo cible dans la liste, et l’écran passe en mode radar : un indicateur de distance estimée affiche en gros la valeur approximative (« ~3 mètres »), une jauge horizontale visualise la proximité, et un signal sonore — le fameux effet Geiger — accélère son tempo à mesure qu’on se rapproche. À moins d’un mètre, le téléphone émet un bip continu, le vendeur a le vélo en main.
L’application gère également la liste complète des vélos détectables dans le rayon Bluetooth (~30 mètres en environnement ouvert, ~10 mètres avec des cloisons), classés par distance estimée. C’est utile pour inventaire rapide : un coup d’œil et le vendeur sait quelles unités sont effectivement présentes dans le magasin à l’instant T, sans devoir faire le tour du parc à pied.
Côté technique
L’application est développée en Flutter (Dart SDK ≥ 3.0), ciblant Android exclusivement pour l’instant — iOS est techniquement faisable mais Apple restreint l’accès aux UUID BLE arbitraires, ce qui complique l’usage de tags génériques. La détection BLE utilise le package flutter_blue_plus qui expose les API Bluetooth Low Energy native d’Android, et lit en continu le RSSI (signal force) de chaque tag détecté.
L’estimation de distance à partir du RSSI passe par une formule classique : distance ≈ 10^((TxPower - RSSI) / (10 × n)), où TxPower est la puissance d’émission calibrée du tag (typiquement -59 dBm à 1 mètre pour un tag iBeacon standard) et n est le facteur de propagation (entre 2 en air libre et 4 en environnement dense). L’application calibre n par environnement (« magasin ouvert » vs « réserve cloisonnée ») via un mode d’apprentissage où le vendeur place un tag à distance connue pour ajuster la courbe.
L’effet Geiger sonore est implémenté avec un PCM généré dynamiquement (sample audio court, fréquence de répétition inversement proportionnelle à la distance estimée). À 10 mètres, le bip est espacé de 800 ms ; à 1 mètre, il devient continu. Le visuel est synchronisé sur le même rythme, avec un fond qui pulse en synchro pour un feedback multimodal.
La liste des vélos cibles est synchronisée avec CRM Cycles via API REST au lancement de l’application, puis stockée localement en shared_preferences pour fonctionner même sans réseau (typique d’une réserve magasin en sous-sol). La synchronisation reverse — un vélo nouvellement reçu avec son tag — passe par un push notification ou un refresh manuel.
Côté magasin : la réception des vélos avec association tag
L’application ne se limite pas à la recherche. Elle prend également en charge la réception en magasin des vélos commandés. Quand un fournisseur livre un lot, le vendeur ouvre l’application en mode « Réception », scanne le tag BLE qu’il colle sur le vélo, puis renseigne sur place :
- Le numéro de série du vélo (lecture manuelle sur le cadre ou scan du code-barres si présent)
- L’emplacement de stockage dans le magasin (zone, étage, rack — choix dans une liste pré-configurée côté CRM Cycles)
- Une photo de référence (utile pour confirmer l’état à la livraison)
Toutes ces informations remontent vers CRM Cycles via API REST, où elles atterrissent dans une file « Réceptions à valider ». Le gérant ou le responsable magasin n’a plus qu’à vérifier la cohérence avec le bon de commande fournisseur et valider — la fiche du vélo sérialisé est créée automatiquement avec son tag associé, prêt pour la mise en rayon et la recherche par effet Geiger.
Cette répartition des tâches entre l’application mobile (saisie terrain) et CRM Cycles (validation, intégration au stock, lien avec la commande fournisseur) évite la double saisie classique « cahier puis ordinateur » qui était la norme avant. Le vendeur qui réceptionne ne quitte pas le quai de livraison, l’inventaire est à jour en temps réel, et le risque d’erreur de saisie (numéro de série mal recopié, zone confondue) est réduit puisque tout passe par l’application avec validation.
Pourquoi le Bluetooth plutôt que NFC, QR ou RFID actif
Plusieurs technologies de tracking étaient envisageables. Le NFC nécessite un contact direct, donc inutile pour de la recherche à distance. Le QR code suppose de voir le vélo pour le scanner — c’est exactement ce qu’on cherche à éviter. La RFID active à longue portée existe mais les lecteurs coûtent plusieurs centaines d’euros et la calibration est complexe.
Le BLE coche toutes les cases : tags à ~5 €, autonomie 2 ans, lecteur intégré dans n’importe quel smartphone Android récent, et portée largement suffisante pour un magasin (jusqu’à 30 mètres en ouvert). L’effet Geiger sonore permet au vendeur de regarder où il marche plutôt que son téléphone — détail UX qui fait toute la différence en condition réelle de magasin où il faut éviter les vélos posés au sol.
