Anatomie d'une borne en marque blanche

Notre borne fonctionnait bien, en France, sous Windows, écrite en WinDev. Puis l'objectif est devenu clair : attaquer le marché américain. Traduire les écrans n'aurait rien changé. Il fallait qu'un même produit puisse porter la marque, le parcours et les règles de n'importe quelle enseigne, sans une ligne de développement par client.

Je n'ai pas écrit le code : la R&D l'a réalisé et la QA l'a testé. J'ai porté la direction produit, les spécifications et prototypes sur Axure, le design sur Adobe XD et les arbitrages. Voici comment ce produit fonctionne, pièce par pièce.

Une borne ressemble à un seul produit. C'est en réalité trois projets en un : l'application que voit le client final, l'administration que manipule l'enseigne, et une partie technique que personne ne voit mais qui décide de tout.

Partie 1 : l'application du client final

Le premier enjeu tient en deux mots : fluidité et rapidité.

Concevoir pour quelqu'un qui est debout

Une borne n'est pas un site web posé sur un grand écran. La personne est debout, souvent pressée, avec une file derrière elle, et n'a jamais lu de mode d'emploi. Elle touche l'écran avec le doigt, à une hauteur qui doit aussi convenir à une personne en fauteuil.

Tout le design part de là. De grandes cibles tactiles. Le choix de la langue dès le premier écran. Une seule décision à la fois. Un fil simple : accueil, choix, panier, paiement, confirmation. Un mode pour les personnes à mobilité réduite, qui ramène l'interface à portée de main. Et le paiement par carte, sans contact ou espèces, sans jamais perdre la vente.

Android, Linux, Windows, et parfois plus de réseau

L'application client devait aussi survivre au monde réel. D'un client à l'autre, la machine change : Android, Linux, Windows, écrans de tailles différentes, périphériques différents. Et le réseau d'un point de vente coupe toujours au pire moment.

C'est ce qui rend la réponse rapide possible : le parcours ne dépend pas d'un aller-retour vers un serveur à chaque toucher. Ce qui compte pour le client se joue sur place.

Partie 2 : l'administration de l'enseigne

La deuxième partie s'adresse à un autre utilisateur : l'exploitant, le siège d'un réseau de franchise, la personne qui doit changer un prix sans appeler un développeur.

Une marque, c'est de la donnée

En WinDev, adapter la borne à un client voulait dire développer. C'était incompatible avec notre ambition, car chaque enseigne voulait sa borne.

Nous avons donc séparé ce qui appartient au produit de ce qui appartient à la marque. Les composants React, boutons, cartes produit, grilles et carrousels, sont les mêmes pour tout le monde. Le logo, les couleurs, les images, les noms affichés et les langues sont de la configuration. Une nouvelle enseigne ne demande pas de nouveau code, seulement un nouveau jeu de données.

Le passage à React n'était donc pas un choix de mode. WinDev nous enfermait dans Windows, alors qu'une technologie web pouvait tourner sur tout matériel, se connecter aux paiements modernes et se recruter partout.

Le back-office écrit une configuration JSON versionnée. La borne la lit et se dessine à partir d'elle. Une copie locale lui permet de continuer si le réseau coupe, puis de synchroniser. Si une publication pose problème, on revient à la version précédente.

Tout part de la carte

Le cœur du CMS est une hiérarchie simple. Une enseigne possède des boutiques, et chaque boutique a sa carte. Le fil d'Ariane de l'écran le dit à chaque instant : le catalogue, l'enseigne, la boutique, la carte, la section.

Sous la carte, on retrouve les briques que le client manipule : les catégories, les articles, les tags pour filtrer, les options, les allergènes et les parcours.

Le back-office actuel, en environnement de démonstration.

Les options en sont un bon exemple : une taille, plusieurs valeurs, et une seule valeur par défaut. Le client décrit ses produits, et l'interface de la borne se déduit de cette description.

Même le back-office se configure. Pour une catégorie, l'écran propose les champs disponibles d'un côté et les champs actifs de l'autre. Chaque enseigne ne voit que ce dont elle a besoin.

Le parcours en glisser-déposer

C'est la partie la plus difficile à concevoir, et la plus importante. Un parcours de commande n'est pas une page, c'est un enchaînement de décisions. Les CMS standards gèrent du contenu, pas ce type de logique.

Nous avons donc construit un éditeur visuel. Le client place et relie les éléments de sa carte, colonne après colonne, et voit la structure de son parcours se former.

La brique qui a tout simplifié est l'étape. Une étape, c'est un choix proposé au client final pendant sa commande. Elle peut servir à plusieurs articles, et se personnaliser selon l'article qui la déclenche. On ne recrée donc pas le même choix cinquante fois. On le crée une fois, on le relie, et on l'adapte. Une catégorie peut même devenir une étape, avec une règle claire sur le prix appliqué. Les ventes additionnelles fonctionnent sur le même principe.

Avant toute publication, le client doit voir ce qu'il a fait. Sans aperçu, personne n'ose toucher à une borne en service.

Plusieurs boutiques, une seule vérité

Le vrai danger d'un CMS en libre-service, c'est la modification en pleine journée. Nous avons donc posé une règle stricte, que l'écran rappelle lui-même : une seule carte par boutique peut être en production, et elle n'est pas modifiable. Toute modification se fait sur une copie.

Le siège peut dupliquer une carte, la publier ou planifier sa mise en ligne, boutique par boutique ou sur plusieurs en même temps. Un réseau garde ainsi une base commune, et une boutique peut avoir ses différences sans casser celle des autres.

Là où tout se complique : les spécificités

Une enseigne n'est jamais uniforme. Un même article peut être vendu sur place et pas en livraison, sur la borne et pas sur l'application. Dans la boutique de démonstration, on compte trois modes de vente et sept supports de vente.

Nous avons traité cela comme une matrice. Pour chaque article, le client active ou coupe la visibilité par mode de vente et par support : borne, caisse, application, web, plateformes de livraison. Une seule fiche produit, et autant d'exceptions que nécessaire, sans la dupliquer.

Partie 3 : paiements, commandes et liaison avec les caisses

La troisième partie est celle que personne ne voit. C'est là que se joue la confiance. Une borne doit dialoguer avec plusieurs types de terminaux de paiement, récupérer chaque commande, la transmettre aux autres caisses et aux écrans du magasin, et ne jamais perdre ce qui a été payé.

La bonne question n'est pas « est-ce que ça marche ? ». C'est « que se passe-t-il quand ça ne marche pas ? ». Choisissez un scénario.

Ce qui devait rester hors de portée

Cette liberté n'existe que parce que le reste est verrouillé. Aucun réglage ne permet de toucher à l'intégrité des ventes exigée par NF525, au comportement du paiement, à la liaison avec les caisses en place ou au mode dégradé. À l'international, les règles changent encore : aux États-Unis, la taxe de vente varie selon l'État et même la ville.

La Réunion, à plus de 9 000 kilomètres

Notre premier client pilote était Burger King à La Réunion, avec du vrai matériel, un vrai réseau et de vrais clients dans la file. C'est là que le produit a vraiment rencontré ses contraintes. Si je devais refaire ce projet, j'irais plus tôt sur le terrain.

Le produit a ensuite été déployé dans des contextes très différents, de Burger King à La Réunion à des enseignes italiennes, chacune avec sa carte, sa marque et son parcours, sur le même code.

La liberté des clients ne fonctionnait que parce que les parties dangereuses étaient hors de portée. Les agents IA ont besoin exactement de cette frontière.