CrysDelivery
Une base de code. Plusieurs marques. Un suivi de livraison en direct.
CrysDelivery est une plateforme de commande et de livraison en marque blanche, pensée pour l’avitaillement professionnel. Une base de code Flutter unique se décline en applications de marques indépendantes : nom, couleurs, logo et backend Firebase sont injectés à la compilation, sans modifier une ligne de code applicatif.
- Catégorie
- Marketplace & livraison
- Plateformes
- Web · iOS · Android
Le point de départ
Décliner une application de commande pour plusieurs marques implique normalement autant de projets à maintenir que de clients. Le projet a été construit sur le principe inverse : un socle unique, configuré par fichier, avec trois configurations de marques présentes dans le dépôt. Le guide d’installation est d’ailleurs rédigé pour permettre le lancement d’une nouvelle instance client sans compétence en développement.
Deux exigences opposées devaient se rejoindre. Côté client final : parcourir un catalogue, composer des paniers réutilisables, commander avec un créneau de livraison et suivre le livreur en direct. Côté exploitant : éviter la multiplication des bases de code, chaque nouvelle marque devant être livrable sans duplication ni dette de maintenance.
Ce qui a été construit
L’identité de marque a été sortie du code vers une configuration externe injectée au build — jusqu’aux fichiers web (titre, thème, manifeste) générés depuis des templates. L’application repose sur une Clean Architecture stricte, où les entités métier sont séparées des modèles de données et où les dépôts sont masqués derrière des interfaces, ce qui isole la logique de Firebase. Le temps réel s’appuie sur les flux Firestore : commandes, messagerie et position du livreur se mettent à jour sans rafraîchissement.
Ce que le produit fait
Marque blanche
Une base de code produit plusieurs applications de marques distinctes, chacune avec son nom, ses couleurs et son backend.
Suivi de livraison en temps réel
Le client suit la position du livreur, l’itinéraire et l’heure d’arrivée estimée, en direct.
Catalogue hiérarchique
Catégories, sous-catégories et produits, avec une recherche instantanée servie par un cache local.
Paniers réutilisables
Plusieurs paniers nommés, conservés et réutilisables d’une commande à l’autre.
Commande en trois étapes
Localisation sur carte, choix de la date et du créneau, puis récapitulatif avant validation.
Messagerie temps réel
Un fil de discussion direct entre le client et l’exploitant, sans quitter l’application.
Back-office complet
Gestion du catalogue, des commandes, des clients et des demandes d’inscription.
Bilingue et sécurisé
Application française et anglaise, avec connexion biométrique par empreinte ou reconnaissance faciale.
Les décisions qui comptent
Un suivi GPS qui ne vide pas la batterie
Le suivi de livraison diffuse la position du livreur vers le client tout en calculant l’itinéraire et l’heure d’arrivée. Diffuser chaque point GPS aurait vidé la batterie et fait grimper le coût des appels de cartographie. Les mises à jour sont donc filtrées selon la distance réellement parcourue, et le recalcul d’itinéraire est temporisé, avec une détection d’écart à la route pour ne relancer un calcul que lorsque c’est utile.
La marque blanche sans dette de maintenance
Le vrai coût de la marque blanche n’est pas de créer la deuxième application : c’est de maintenir la dixième. L’identité a donc été entièrement sortie du code vers une configuration injectée au build, jusqu’aux fichiers web générés depuis des templates. Une correction écrite une fois profite à toutes les marques, à condition de ne jamais coder en dur une valeur de marque — une discipline qui structure tout le projet.
Isoler la logique métier de Firebase
Une Clean Architecture stricte sépare les entités métier des modèles de données et masque les dépôts derrière des interfaces. Les erreurs sont traitées comme des valeurs typées plutôt que des exceptions. Le bénéfice est concret : la logique du produit ne dépend pas de Firebase, et reste testable et remplaçable.
Un démarrage rapide malgré un gros catalogue
Le catalogue est mis en cache localement avec une invalidation par numéro de version : l’application ne retélécharge les données que lorsqu’elles ont réellement changé. Le démarrage est plus rapide, la recherche instantanée, et les lectures réseau — donc la facture — restent contenues.
Comment c’est assemblé
Flutter
Une base de code unique pour le web, iOS et Android
Cloud Firestore
Base temps réel : commandes, messagerie, position du livreur
Cloud Functions
Ce qui ne peut pas tourner sur l’appareil : e-mails, notifications, clés d’API
Google Maps
Itinéraire et heure d’arrivée estimée
Les technologies utilisées
Frontend
- Flutter
- Dart
- BLoC
- Clean Architecture
Backend
- Cloud Functions
- TypeScript
Infrastructure
- Firebase
- Cloud Firestore
Services
- Google Maps
- Firebase Cloud Messaging
Ce qui a été livré
Projet livré sur web et mobile, avec trois configurations de marques présentes dans le dépôt et une expérience temps réel de bout en bout, du catalogue au suivi du livreur. Les résultats chiffrés seront ajoutés une fois validés avec le client.
- Web
- iOS
- Android
Besoin d’un produit similaire ?
Parlons de ce que vous voulez construire. Je vous réponds personnellement, généralement sous 24 heures.