Votre logiciel de bar doit fonctionner quand internet ne fonctionne plus

Tous les festivals racontent la même histoire. Le site se remplit, trente mille téléphones saturent les antennes locales, le routeur 4G derrière le bar tombe à zéro, et quelque chose cesse de fonctionner. Si ce quelque chose est votre bar, vous avez un problème très coûteux pour le reste de la soirée.

Ce n’est pas un cas limite. C’est la condition normale d’un site événementiel en pointe, et c’est la raison pour laquelle une machine à boissons doit être conçue hors-ligne d’abord, pas cloud d’abord.

Ce que « hors-ligne d’abord » signifie réellement

L’expression s’emploie à la légère. Concrètement, elle signifie que la machine détient localement tout ce dont elle a besoin pour servir un verre :

• Recettes et affectation des pompes stockées sur la machine, pas récupérées à la demande
• Prix résolus localement
• Interface client servie par la machine elle-même, pas par un CDN
• Niveaux de stock suivis localement et réconciliés plus tard
• Soldes de paiement, en cashless, lisibles et débitables sans aller-retour réseau - le plus difficile des cinq, et celui que nous ne faisons pas aujourd’hui

Le cloud reçoit les données ensuite. C’est une destination pour ce qui s’est passé, pas une dépendance pour ce qui est en train de se passer.

Le test est simple : débranchez internet en plein service et regardez si le client suivant obtient son verre. Si la réponse est non, le système dépend du cloud, quoi qu’en dise la plaquette commerciale.

Où les conceptions cloud-first cassent

Les modes de défaillance méritent d’être nommés, car ils ne sont pas évidents avant de les voir :

La tablette est un client léger. Si l’interface client est hébergée à distance, une coupure transforme votre kiosque en page d’erreur. La servir depuis la machine sur le réseau local supprime toute une catégorie de pannes.

La licence appelle le serveur. Celle-ci frappe au pire moment. Si le logiciel valide sa licence auprès d’un serveur à chaque démarrage, une coupure réseau plus un redémarrage donnent une machine qui refuse de fonctionner. Cocktail-O-Matic traite le cas avec une période de grâce configurable - sept jours par défaut - pendant laquelle tout continue normalement sans connectivité. Le modèle de licence est conçu pour qu’un problème réseau ne devienne jamais un problème de service.

Le paiement exige une autorisation. C’est la seule dépendance réellement difficile à supprimer, et autant être direct sur notre propre position : le cashless NFC de Cocktail-O-Matic garde le portefeuille dans le cloud, le débit est donc un appel réseau. Les verres continuent d’être servis sans connectivité, mais pas ce chemin de paiement. Un solde local réconcilié ensuite est la conception qui supprime totalement la dépendance, au prix d’un problème de double dépense plus difficile entre bars. Si votre site a une connectivité incertaine, prévoyez une liaison dédiée jusqu’aux bars plutôt que de supposer que l’étape de paiement se dégradera en douceur.

L’heure vient du réseau. Les machines sans horloge sauvegardée prennent l’heure par NTP. Démarrez-en une sans réseau et elle peut se croire en 1970, ce qui casse silencieusement tout ce qui dépend du temps : expiration de session, fenêtres d’événement, ordre des enregistrements.

Le problème de la réconciliation

Fonctionner hors ligne est la moitié facile. La moitié difficile, c’est ce qui se passe au retour du réseau quand deux sources de vérité ont toutes deux évolué.

Les règles qui gardent cela sain :

• La machine fait foi pour ce qu’elle a observé. C’est elle qui a versé, elle sait. Le cloud, non.
• Envoyez des événements, pas des états. Transmettez « versé 40 ml de gin à 21h04 » plutôt que « le stock vaut 1,2 litre ». Les événements fusionnent, les instantanés d’état s’écrasent entre eux.
• Rendez chaque événement idempotent. Une reprise après expiration ne doit pas compter une vente deux fois. Attribuez un identifiant généré sur la machine et dédupliquez à l’arrivée.
• Anticipez la dérive d’horloge. Deux machines dont les horloges diffèrent d’une minute produisent une chronologie réconciliée subtilement désordonnée. Enregistrez l’heure machine et l’heure de réception serveur.

Rater cela ne produit pas un plantage, mais des statistiques en désaccord discret avec la caisse. C’est pire, car vous pouvez les croire pendant des mois.

Ce que vous perdez légitimement hors ligne

Soyons honnêtes sur l’échange : machine déconnectée, vous perdez des choses.

• La supervision de flotte en direct : l’état de la machine n’est plus visible depuis le portail cloud jusqu’à sa reconnexion
• La vue consolidée des stocks sur un site multi-bars
• Les modifications de configuration à distance
• Les chiffres de recette en temps réel

Rien de tout cela n’empêche de servir, et c’est le point. L’objectif n’est pas « aucune dégradation », mais « aucune dégradation de ce pour quoi le client est planté devant vous ».

Les questions à poser à un fournisseur

Si vous évaluez une solution d’automatisation, ces quatre questions séparent vite le hors-ligne d’abord du cloud d’abord :

1. Si internet tombe en plein service, qu’est-ce qui s’arrête ?
2. Si la machine redémarre hors ligne, sert-elle encore ?
3. Combien de temps peut-elle tourner déconnectée avant que quoi que ce soit se dégrade ?
4. À la reconnexion, comment évitez-vous de compter les ventes deux fois ?

Un fournisseur qui répond vraiment aux quatre a réfléchi aux sites événementiels. Un fournisseur qui doit se renseigner, non.

Pourquoi cela dépasse les festivals

On classe facilement le sujet dans « problème de festival », mais la même conception paye dans un établissement permanent. Les box tombent. Les opérateurs ont des pannes. Quelqu’un débranche ce qu’il ne fallait pas pendant des travaux. Un bar dont la capacité à servir dépend d’une connexion internet a ajouté une dépendance qu’il n’avait pas avant l’automatisation - alors que toute la promesse était de rendre le service plus fiable, pas moins.