3Smiles est en production. Le site est en ligne sur 3smiles.eu, le back-office restaurateur sur app.3smiles.eu, et l'infrastructure Azure tourne avec de vrais abonnements, de vrais e-mails transactionnels et de vraies données de restaurant. C'est la première application métier livrée par FlorisNexus qui n'est pas un site vitrine — et l'occasion de raconter honnêtement ce qu'un tel projet demande.
Le problème : une demande simple coûte une traversée de salle
Dans une salle de restaurant, la plupart des demandes clients sont minuscules : l'addition, une carafe d'eau, un couvert manquant. Le coût n'est pas dans l'exécution — il est dans la transmission. Un client lève la main, croise un regard, attend. Un serveur traverse la salle pour seulement entendre la demande, puis la traverse une seconde fois pour y répondre.
Le constat de départ du projet était donc celui-ci : il manque un canal direct entre la table et l'équipe. Avec trois contraintes non négociables. Pas de matériel à installer — le boîtier à bouton posé sur chaque table est la solution d'un concurrent, pas la nôtre. Rien à télécharger côté client — un restaurant ne peut pas demander à un couple de trente-cinq ans d'installer une application pour commander de l'eau. Et surtout : ne pas remplacer le contact humain, mais lui éviter les allers-retours inutiles.
Ce que fait 3Smiles, concrètement
Chaque table porte un QR code. Le client le scanne avec l'appareil photo de son téléphone — pas d'installation, pas de compte, pas de mot de passe — et arrive sur un écran qui liste les services proposés par ce restaurant. Il choisit. Le serveur en charge de cet espace reçoit la demande instantanément, sur sa tablette ou son téléphone, avec le numéro de table.
Ce n'est pas une carte en ligne et il n'y a pas de commande de plats : le produit résout le canal d'appel, pas la prise de commande. Derrière, le restaurateur dispose d'un back-office complet : ses établissements, ses espaces (terrasse, salle, étage), ses tables, la liste des services qu'il veut proposer, ses membres d'équipe, et son abonnement. Le tout en trois langues — français, anglais, néerlandais — parce qu'un restaurant belge sert les trois dans la même soirée.
Pourquoi ce n'était pas un site vitrine
Nous avons publié un guide comparant site vitrine et application métier. 3Smiles est l'illustration exacte du second cas, et la frontière se lit à quatre signes.
Il y a un état à maintenir. Une demande de service naît, est prise en charge, se termine ou est annulée. Une session client s'ouvre au scan et se ferme. Un site vitrine, lui, ne se souvient de rien.
Il y a du temps réel. Une notification qui arrive trente secondes trop tard est inutile : le client a déjà levé la main.
Il y a plusieurs clients dans le même produit. Chaque restaurant est un locataire (tenant) qui ne doit jamais voir les données d'un autre.
Il y a de l'argent. Un abonnement mensuel ou annuel, des paiements qui échouent, des factures, de la TVA.
Chacun de ces quatre points multiplie le travail par rapport à une vitrine. C'est pour cela que la question « site ou application ? » n'est pas un détail de vocabulaire : elle change le budget, le calendrier, et ce qu'il faudra maintenir pendant des années.
Les choix techniques — et ce qu'ils protègent
3Smiles tourne sur .NET 10, avec un front-office et un back-office en Blazor WebAssembly, du temps réel en SignalR, une base Azure SQL unique et une infrastructure Azure entièrement décrite en Bicep. Ce ne sont pas des choix de mode ; chacun protège quelque chose de précis.
SignalR plutôt qu'un rafraîchissement périodique : la demande arrive sur l'écran serveur en une poignée de secondes, sans que l'application interroge le serveur en boucle pour rien.
Une seule base, isolée par identifiant de locataire plutôt qu'une base par restaurant : les filtres d'isolation sont appliqués globalement au niveau de l'accès aux données, ce qui rend « oublier de filtrer » très difficile — et permet de déployer une seule fois pour tous les clients.
Microsoft Entra External ID pour l'identité : ni mots de passe ni jetons stockés par nous, MFA disponible, et une surface d'attaque déléguée à Microsoft plutôt que réécrite maison.
Stripe pour l'abonnement : aucune donnée de carte ne transite par l'application.
Bicep pour l'infrastructure : l'environnement de production est décrit dans un fichier versionné, et un environnement de test lui reste séparé. C'est ce qui permet de tester une modification d'infrastructure sans jouer avec la production d'un restaurant en service.
D'abord la Belgique, ensuite l'Europe
3Smiles démarre sur le marché belge : c'est là que se trouvent les premiers restaurants, et c'est le marché que le porteur du projet connaît. Mais le produit n'est pas fait pour s'y arrêter — et cela se joue dans l'architecture, pas dans un discours. Une seule instance multi-locataire sert tous les clients : un pays supplémentaire n'est pas un déploiement supplémentaire. L'interface est trilingue dès le premier jour, parce qu'ajouter les langues après coup est la version la plus chère de l'exercice. Stripe facture dans plus de 40 pays. Et comme l'infrastructure est décrite en Bicep, elle se redéploie dans une autre région Azure sans être réécrite.
L'ordre, lui, est volontaire : prouver le produit dans une salle belge, puis élargir à l'Europe — et pourquoi pas au-delà. Les produits qui veulent parler au monde entier dès le premier jour ne convainquent en général personne en particulier.
Ce que le terrain a changé dans le produit
La partie la plus instructive du projet n'est pas l'architecture — c'est la liste des choses qu'aucune spécification n'avait prévues.
L'ordre des espaces. La liste des espaces était triée par ordre alphabétique. Conséquence : un restaurateur dont la salle principale s'appelle « Terrasse » la voyait systématiquement en dernière colonne de l'écran serveur, sans aucun moyen de la remonter. Il a fallu ajouter un ordre choisi par le restaurateur.
Des flèches, pas du glisser-déposer. Pour réordonner cette liste, le réflexe de développeur est le glisser-déposer. Mauvaise idée : les événements correspondants ne se déclenchent pas au toucher sur la plupart des navigateurs mobiles, et ce back-office s'utilise sur une tablette, debout, en salle. Deux flèches font le travail et fonctionnent partout.
Le rescan du QR code. Un client rescanne le code au milieu du repas, ou son voisin scanne la même table. Le cycle de vie des sessions et des demandes a demandé plusieurs passes avant d'être juste dans tous ces cas.
Le paiement refusé. Une carte qui expire ne doit pas couper le service d'un restaurant en pleine soirée : une période de grâce a été ajoutée à la facturation. La bonne réaction technique à un échec de paiement est rarement « bloquer immédiatement ».
Mettre en production, ce n'est pas déployer
C'est la leçon que je retiens le plus de ce projet. Le code fonctionnait depuis longtemps quand la mise en production a commencé. Ce qui a réellement occupé cette phase, ce sont des choses invisibles pour l'utilisateur :
Un domaine d'envoi dédié. Les invitations partaient d'une adresse Azure générée automatiquement — le genre d'expéditeur qu'un restaurateur classe en spam sans l'ouvrir. Basculer sur une adresse du domaine du client a impliqué un sous-domaine dédié et une configuration DNS d'authentification propre, pour ne pas casser la boîte professionnelle existante.
Le back-office exclu des moteurs de recherche. L'application n'avait ni robots.txt ni en-tête équivalent — et l'absence de ce fichier autorise l'exploration au lieu de l'interdire.
Des en-têtes de sécurité réellement appliqués. Ceux du site vitrine étaient bien écrits mais n'étaient jamais servis en production, parce que le fichier de configuration n'était pas dans le dossier publié. Écrit ≠ déployé : il faut vérifier sur l'URL de production.
Le dimensionnement et les migrations. Passer la production au bon plan d'hébergement, et s'assurer qu'une migration de base de données ne puisse pas s'appliquer à la production avant l'heure.
Le socle juridique. CGU, politique de confidentialité, mentions légales et accord de sous-traitance (DPA) en trois langues, avec acceptation horodatée et versionnée au premier accès du gérant. Sur un produit qui traite des données pour le compte d'autres entreprises, ce n'est pas une formalité de fin de projet.
Aucun de ces points n'apparaît dans une démonstration. Tous sont bloquants pour un vrai lancement. Si un prestataire vous annonce une application métier « terminée » sans avoir parlé de ces sujets, elle ne l'est pas.
Ce que nous mesurons, et ce que nous n'avons pas encore
Le site 3Smiles est mesuré comme tous nos projets, en production, à l'outil Lighthouse : 97 en performance, 97 en accessibilité, 100 en bonnes pratiques et 100 en SEO sur ordinateur ; 86, 96, 100 et 100 sur mobile (médiane de trois passes, 10 août 2026). Ces chiffres sont publiés bruts, y compris quand ils ne sont pas flatteurs, sur notre page réalisations.
En revanche, nous ne publierons aucun chiffre d'usage aujourd'hui : temps d'attente économisé, demandes traitées par service, satisfaction client. Le produit vient d'entrer en production. Ces mesures existeront quand elles auront été observées en salle, sur plusieurs semaines — pas avant. Un chiffre inventé ou extrapolé est le genre de détail qui décrédibilise tout le reste d'une étude de cas.
Ce que ce projet dit du vôtre
Si vous êtes indépendant, commerçant ou gérant de PME en Belgique et que vous avez identifié une friction précise dans votre métier — un appel qui n'arrive pas au bon endroit, une information recopiée trois fois, un planning tenu sur papier — trois enseignements de ce projet valent pour le vôtre.
Commencez par la friction, pas par la fonctionnalité. 3Smiles ne fait pas « tout ce qu'un restaurant pourrait vouloir ». Il supprime un aller-retour. Un périmètre étroit et réellement utile se livre ; une liste de souhaits ne se livre jamais.
Le terrain a toujours raison contre la maquette. Les corrections les plus importantes de ce projet sont venues d'une tablette tenue à la main dans une salle, pas d'une réunion.
Prévoyez la phase invisible. Domaines, e-mails, sécurité, RGPD, facturation : comptez-la dans le calendrier dès le départ, sinon elle repoussera votre lancement de plusieurs semaines.
Et une dernière chose, sur laquelle FlorisNexus ne transige pas : l'infrastructure et les comptes restent au nom du client. L'abonnement Azure de 3Smiles appartient au porteur du projet, pas à nous. Vous devez pouvoir changer de prestataire sans changer de produit.