Kartier
Prendre les commandes en ligne sans céder sa marge ni sa clientèle à une marketplace.
Un snack qui veut vendre en ligne a le choix entre s’inscrire sur une marketplace — qui prélève un pourcentage sur chaque vente et met sa propre marque devant le client — ou ne rien faire. Kartier est la troisième option : une boutique en ligne à son nom, sur abonnement fixe, sans commission.
- Catégorie
- Plateforme SaaS multi-établissements
- Plateformes
- Web · PWA
Le point de départ
Le produit s’adresse aux snacks et restaurants de La Réunion, en click and collect : le client commande et paie en ligne, puis vient chercher sa commande. Pas de livraison. C’est un produit que je conçois et que j’exploite, pas une commande client — ce qui change la façon de le construire : chaque décision se paie en temps de support ou en résiliation trois mois plus tard.
Deux problèmes distincts se posent au même endroit. Côté commerçant, la commission d’une marketplace ampute une marge déjà faible, et le client final appartient à la plateforme, pas au restaurant. Côté comptoir, l’heure de pointe est le vrai goulot : les commandes prises à l’oral sont mal notées, la file s’allonge, et une commande payée que personne ne voit passer coûte un client et une réputation.
Ce qui a été construit
Chaque établissement reçoit sa propre boutique en ligne, générée à partir d’une seule couleur de marque : pas de travail de design par client, pas de déploiement à refaire. Le client commande sans créer de compte, choisit un créneau de retrait et paie en ligne. Le commerçant travaille sur une tablette au comptoir : un tableau des commandes lisible à deux mètres, une alarme qui se répète jusqu’à ce que quelqu’un l’acquitte, et un changement de statut en un geste. Il gère lui-même sa carte, ses prix, sa TVA, ses horaires — et dispose d’un bouton d’arrêt d’urgence quand la cuisine est débordée.
Ce que le produit fait
Une boutique à votre nom
Vos clients commandent à une adresse qui vous appartient, à vos couleurs. Vous construisez votre propre clientèle, pas celle d’une marketplace.
Aucune commission sur les ventes
Un abonnement fixe, et rien qui grimpe avec votre volume. Votre marge ne diminue pas quand vous vendez plus.
Un tableau de commandes pensé pour le coup de feu
Trois colonnes lisibles à deux mètres et une alarme qui se répète jusqu’à ce qu’on l’acquitte : une commande payée n’est jamais manquée pendant le service.
Des créneaux de retrait plafonnés
Le client réserve un créneau de quinze minutes, dans la limite que vous fixez. Les commandes arrivent étalées au lieu de tomber toutes à midi.
Votre carte, vos prix, votre stock
TVA par produit, groupes d’options, photos, et un « épuisé aujourd’hui » qui se remet à zéro tout seul le lendemain — sans passer par moi.
Arrêt d’urgence et retards annoncés
Un bouton pour ne plus prendre de commandes, et des boutons de retard qui décalent l’heure de retrait en prévenant le client. La cuisine reste honnête même débordée.
Exports mensuels prêts pour le comptable
Un CSV et un PDF générés côté serveur, avec la TVA ventilée par taux et la répartition espèces/en ligne. La fin de mois devient un téléchargement.
Tampons de fidélité et codes promo
Des tampons acquis au retrait et des codes de réduction limités par client, sans ajouter un second outil à gérer.
Les décisions qui comptent
Écrire la commande avant de débiter la carte
La commande, le recalcul du total côté serveur et la réservation du créneau sont écrits dans une seule transaction ; la demande de paiement n’est créée qu’ensuite. L’ordre n’est pas indifférent : ainsi une écriture qui échoue n’a jamais débité personne, et le cas « client débité, commande inexistante » devient structurellement impossible. Reste le cas inverse — débité, commande bloquée — qu’un contrôle automatique rattrape toutes les dix minutes en interrogeant Stripe. Conséquence côté client : quelqu’un qui a été débité voit toujours « votre paiement est bien passé », jamais un message d’échec.
Trois filets contre le double traitement d’un paiement
Stripe garantit de livrer ses notifications au moins une fois, sans garantir l’ordre ni l’unicité. Le traitement écarte donc les doublons sur l’identifiant de l’événement, mais aussi sur le couple objet + type d’événement — parce que deux événements distincts peuvent décrire le même fait. Enfin, chaque transition est écrite pour être rejouable sans effet : appliquer « payée » à une commande déjà payée ne fait rien. Trois protections indépendantes, parce qu’un paiement compté deux fois est un litige client.
Retrouver sa commande depuis un autre téléphone
Le lien de suivi envoyé par SMS s’ouvre dans le navigateur par défaut du téléphone — presque jamais celui où la commande a été passée. Sans mécanisme dédié, le client perd l’accès à sa propre commande. La solution ne stocke que l’empreinte du jeton, jamais le jeton lui-même : une fuite de la base ne donne accès à rien. Et l’autorisation est délibérément limitée au couple établissement + commande, parce que deux établissements peuvent avoir des commandes portant le même identifiant.
Interdire les retours en arrière sur le statut d’une commande
Les règles d’accès contrôlaient quels champs pouvaient changer, jamais vers quelles valeurs. Résultat : une commande remboursée pouvait repasser en préparation, et un équipier dont l’écran avait deux secondes de retard faisait reculer une commande de « prête » à « en préparation » — après le départ du SMS au client. Les statuts modifiables depuis le comptoir sont désormais limités à quatre, et le remboursement passe par une fonction dédiée : laisser une tablette marquer « remboursé » reviendrait à enregistrer un remboursement que personne n’a versé.
Un fuseau horaire qui n’est pas celui du client
La Réunion est à UTC+4 et ne change pas d’heure, alors que le téléphone du client peut être réglé sur Paris, qui en change deux fois par an. Une journée de service mal calculée range une commande dans le mauvais jour, voire dans le mauvais mois comptable. Le sujet a sa propre série de tests, y compris aux dates de changement d’heure, et un contrôle en navigateur réel dont la consigne est explicitement de régler le téléphone sur Paris — pas sur l’heure locale.
Une garde contre les suites de tests qui rétrécissent en silence
Sur une machine neuve, un dossier absent a fait disparaître huit fichiers de tests de la collecte. Le rapport affichait « 192 réussis », en vert — et personne ne compare 192 à 260 de tête quand la couleur est la bonne. Chaque tâche publie désormais son nombre de tests, et une étape finale les compare à un plancher. Des planchers plutôt que des chiffres exacts, volontairement : un chiffre exact demande une mise à jour à chaque test ajouté, et ce rituel finit par être expédié.
Comment c’est assemblé
Application client
Une boutique en ligne par établissement, à ses couleurs, sans rien à installer
Console de service
L’écran du comptoir : les commandes en cours, lisibles à deux mètres
Fonctions serveur
Tout ce qui touche à l’argent et aux statuts : recalcul, paiement, transitions
Cloud Firestore
Les données cloisonnées par établissement, avec les règles comme seule frontière
Les technologies utilisées
Frontend
- Flutter Web
- Dart
- BLoC
- go_router
- PWA
Backend
- Cloud Functions
- TypeScript
- Node.js
Infrastructure
- Firebase
- Cloud Firestore
- Firebase Hosting
- GitLab CI
Services
- Stripe Connect
- OVH SMS
Ce qui a été livré
Plateforme conçue et développée seul : trois applications web, vingt-six fonctions serveur, environ 87 000 lignes de Dart et 37 000 lignes de TypeScript, et près de 2 800 tests automatisés dont plus de 500 portant uniquement sur les règles d’accès entre établissements. L’intégration continue refuse de construire quoi que ce soit si ces règles échouent. La plateforme est déployée et accessible publiquement, en phase de rodage : les paiements tournent en environnement de test, aucune transaction réelle n’a encore eu lieu. Les résultats d’exploitation seront ajoutés lorsqu’ils existeront.
- Web
- PWA
Besoin d’un produit similaire ?
Parlons de ce que vous voulez construire. Je vous réponds personnellement, généralement sous 24 heures.