Un paiement n’est pas encore un service.

LE POINT DE DÉPART

Servir sans ajouter une nouvelle file d’attente.

Hop’n Bar part d’un geste simple : un client se présente, s’autorise, reçoit un service continu, puis le système s’arrête. Derrière ce geste, paiement, contrôle machine, mesure et sécurité ne sont pas la même chose.

CE QU’ON A OBSERVÉ

Le physique refuse les raccourcis logiciels.

LA VRAIE QUESTION

Comment garder une expérience fluide sans confondre intention et réalité ?

Le logiciel peut demander un service et le paiement peut le financer. La machine, elle, reste responsable de ce qui se passe réellement au bec. C’est cette séparation qui structure le développement.

LE RAISONNEMENT

Trois confusions ont été refusées.

1. 01
   Paiement ≠ ouverture.

   Une transaction validée ne doit pas hériter automatiquement de l’autorité physique.

2. 02
   Écran ≠ mesure.

   Le volume réel doit venir d’une mesure physique, pas d’une animation d’interface.

3. 03
   Simulation ≠ terrain.

   Les simulations et tests avant validation matérielle permettent d’avancer, mais ils ne deviennent jamais une preuve de validation matérielle.

CE QU’ON A CONSTRUIT

Un moteur, des interfaces stables et une voie de preuve avant le matériel.

Le socle sépare moteur métier, paiement, contrôle physique, interface, configuration et services. Il permet de rejouer des scénarios sans matériel et prépare la validation des interfaces physiques réelles.

LA CHAÎNE, MAILLON PAR MAILLON

Huit étapes, chacune avec son état public.

Voici les huit étapes, avec ce que chacune fait et ce qui est aujourd’hui testé en logiciel ou encore simulé.

1. 01

   Commande

   Le client choisit une dose fixe, à un prix figé au moment du service.

   testé en logiciel

2. 02

   Paiement

   Le paiement est autorisé dans une limite définie à l’avance.

   simulé

3. 03

   Autorisation

   Servir exige en plus une décision locale : demande signée, valable une fois, limitée dans le temps.

   testé en logiciel

4. 04

   Service

   Le service s’ouvre sous dose, durée et délais bornés.

   testé en logiciel

5. 05

   Mesure

   Le volume vient du débitmètre, pas de l’écran.

   simulé

6. 06

   Arrêt

   Fin de flux, seuil, délai ou erreur ferment le service.

   testé en logiciel

7. 07

   Réconciliation

   On règle le volume réellement mesuré, sous le plafond autorisé, et on rapproche ce qui a été encaissé de ce qui a été servi.

   testé en logiciel

8. 08

   Preuve

   Chaque étape laisse un événement vérifiable dans un journal chaîné.

   testé en logiciel

CE QU’ON PEUT DIRE, ET CE QUE ÇA NE PROUVE PAS

Huit faits, huit limites, au même niveau de lecture.

1. 01

   Un paiement accepté ne donne pas le droit de servir. La décision reste locale, et chaque étape peut dire non.

   Limite Prouvé en logiciel et en simulation ; aucune carte électronique réelle n’a exécuté cette décision.

2. 02

   Chaque service correspond à une demande signée, valable une seule fois et limitée dans le temps.

   Limite La signature est vérifiée dans le moteur ; le programme de référence de la carte ne la vérifie pas encore lui-même.

3. 03

   Dix cas de panne ont été écrits et testés. Dans chacun, la vanne se ferme.

   Limite Trois détections restent des points à valider sur banc et ne sont pas implémentées dans le programme de la carte.

4. 04

   On facture ce qui a réellement coulé, jamais plus que ce qui a été autorisé, y compris après une coupure.

   Limite Le volume est simulé dans la version actuelle. La calibration réelle reste à faire sur banc.

5. 05

   Tant qu’un paiement n’est pas confirmé, on le dit au client, on alerte l’exploitant, et personne ne peut le déclarer réussi à sa place.

   Limite Validé avec un fournisseur de paiement simulé. Le comportement d’un vrai fournisseur reste à confirmer.

6. 06

   Chaque événement est journalisé de façon vérifiable. Les défauts trouvés sont reproduits avant d’être corrigés.

   Limite Journal local ; pas de stockage immuable externe, pas de signature qualifiée.

7. 07

   Exploité dans un établissement pilote à Pau, avec plusieurs milliers de tirages enregistrés en conditions réelles.

   Limite Génération précédente, sur une autre pile logicielle. Cela ne prouve rien sur la version actuelle.

8. 08

   Ce qui est simulé est dit simulé. Ce qui n’est pas validé est dit non validé.

   Limite La discipline documentaire ne remplace pas la validation matérielle.

CE QU’ON PEUT PROUVER

Le socle logiciel avant validation matérielle existe. La validation terrain, non.

Architecture

Le socle porte des responsabilités séparées pour moteur, paiement, contrôle physique, interface et configuration.

Simulation

Des scénarios moteur peuvent être rejoués sans matériel grâce aux simulations et à la console locale.

Doctrine physique

Le service reste en refus par défaut : paiement et intention amont ne suffisent pas à imposer l’action physique.

État réel

La campagne de bout en bout sur matériel réel reste une preuve distincte à produire.

CE QU’ON A APPRIS

Un produit physique doit pouvoir contredire son interface.

Quand le monde réel est en jeu, la bonne architecture n’est pas celle où tout « réussit » parce que l’écran le dit. Elle doit conserver une voie de refus, de mesure et de preuve jusqu’au geste physique.

LE PROBLÈME QU’ON RETROUVE AILLEURS

Une action peut se terminer sans que le bon résultat soit prouvé.

Ce cas montre une chose simple : un système peut terminer une action — ici, un paiement — sans avoir encore prouvé que le résultat attendu, un service réellement servi, a eu lieu. Le même écart entre « l’action s’est terminée » et « le résultat est prouvé » se retrouve dans le cas OXANN OBD, où un code défaut n’est lui non plus qu’un indice tant qu’il n’est pas relié à une mesure.

La question générale est posée à part : terminé ne veut pas dire obtenu.