Caisse hors ligne : des caisses qui continuent de vendre quand Internet coupe

Étude de cas

Caisse hors ligne : des caisses qui continuent de vendre quand Internet coupe

Toutes les études de cas

J'ai conçu une suite de caisse pour la restauration, le commerce de détail et l'épicerie qui permet à chaque caisse de continuer à vendre pendant les coupures d'Internet. Un hub local sur le réseau du magasin enregistre chaque vente puis la synchronise avec le cloud dès le retour de la connexion, et les trois secteurs tournent sur un seul code. Un exploitant l'utilise aujourd'hui en production.

3
Secteurs sur un seul code
3
Applications dans la suite
2
Bases de données synchronisées

Le problème

La plupart des caisses cloud supposent, sans le dire, une connexion stable. Dès qu'Internet tombe, la caisse n'encaisse plus, ce qui veut dire en pratique que le magasin arrête de vendre. En Tunisie, ce n'est pas un cas limite, c'est un mardi ordinaire.

Les alternatives n'étaient pas meilleures :

  • Les systèmes 100 % locaux continuent de vendre hors ligne, mais un propriétaire de plusieurs magasins n'a alors aucune vue consolidée des ventes et du stock.
  • Restauration, commerce de détail et épicerie vendent de façons vraiment différentes. Service à table, passage en caisse au code-barres et produits pesés impliquent en général trois produits distincts ou trois copies du même code.
  • Les copies divergent. Une correction écrite pour un secteur doit être reportée à la main dans les autres, et tôt ou tard elle ne l'est pas.

L'approche

J'ai construit la suite autour d'une règle : une vente ne doit jamais dépendre d'un aller-retour avec un data center.

Un hub local entre les caisses et le cloud

Un hub de bureau développé avec Electron est installé sur le réseau du magasin, avec son propre serveur et sa base SQLite intégrés. Chaque caisse dialogue avec le hub, donc la vente continue quand Internet disparaît. Au retour de la connexion, les ventes locales sont rejouées vers PostgreSQL dans le cloud et les changements de catalogue redescendent vers le hub, ce qui préserve la vue consolidée entre magasins.

Un seul code, trois façons de vendre

Plutôt que de dupliquer le produit par secteur, j'ai modélisé les différences entre restauration, commerce de détail et épicerie sous forme de configuration. Les trois partagent un catalogue, un moteur de prix et un journal des ventes uniques : le reporting n'a jamais à fusionner des sources incompatibles, et un nouveau secteur est un profil de paramètres, pas une copie du code.

Plusieurs magasins, un seul compte

L'authentification repose sur Firebase, avec des custom claims qui portent le locataire et le rôle. Un propriétaire de plusieurs magasins les gère tous depuis le même compte, sans qu'aucune donnée ne passe d'une entreprise à l'autre.

Une caisse qui s'installe comme une application

L'écran de caisse est une application web progressive mise en cache pour fonctionner hors ligne, et se lance comme une application native. L'API cloud tourne sur Cloud Run, qui réduit la capacité entre les coups de feu et la remonte pendant le service.

Résultat

La suite tourne aujourd'hui en production chez un exploitant.

  • La vente ne s'arrête plus avec Internet : les caisses fonctionnent via le hub et se réconcilient automatiquement ensuite.
  • Une vue consolidée : les ventes de chaque magasin rejoignent la même base cloud dès le retour de la connexion.
  • Un seul produit à maintenir : une correction est livrée une fois et touche en même temps la restauration, le détail et l'épicerie.
  • Prête pour le prochain exploitant : accueillir une nouvelle entreprise revient à créer un locataire et choisir un profil de secteur, pas à monter un autre système.

L'architecture est détaillée sur la page du projet de caisse multi-secteur.

Stack technique

React
TypeScript
Electron
SQLite
PostgreSQL
Express.js
Cloud Run
Firebase
PWA

Services associés