Ramen Joe a commencé comme un restaurant à Lisbonne. Aujourd'hui, ce sont cinq établissements, une application iOS publiée sur l'App Store, une application Android publiée sur Google Play, un programme de fidélité avec Apple Wallet et Google Wallet, et un back-office qui pilote les opérations du groupe. Le tout repose sur une seule plateforme.
Cet article raconte ce que cette plateforme a résolu, ce que sa construction a coûté au lieu d'acheter du SaaS sur étagère, et là où la plupart des groupes de restauration se trompent lorsqu'ils tentent de faire la même chose.
Résumé exécutif
Un groupe de restauration comptant plus de deux adresses a, typiquement, trois problèmes techniques que personne ne dimensionne bien au départ. Des réservations éclatées par établissement. Un programme de fidélité qui ne suit pas le client d'une adresse à l'autre. Des données opérationnelles qui vivent dans des fichiers locaux et des conversations WhatsApp.
Ramen Joe a consolidé toute l'opération dans un seul système. Réservations partagées, client unique, fidélité, carte numérique, gestion du personnel et analyse centralisée. Le résultat concret : le client qui fait tamponner sa carte à Lisbonne voit le même solde à Porto, tandis que l'équipe administre cinq établissements — et peut en ajouter d'autres — depuis le même back-office.
Le coût de ce choix n'est pas anodin. Mais le coût de ne pas le faire apparaît plus tard, déguisé en churn, en personnel qui répète le même travail, et en décisions d'expansion prises à l'aveugle.
Le problème métier
Quand un restaurant unique devient un groupe, le logiciel qui servait bien pour une adresse commence à craquer. Pas parce qu'il est mauvais. Parce qu'il a été conçu pour un contexte qui n'est plus le tien.
Le symptôme classique : chaque adresse finit avec son propre module de réservations, souvent branché sur Google ou un outil SaaS spécifique. Les clients fidélisés vivent dans une base de données par établissement, ou pire, dans un cahier papier. Quand tu veux savoir combien de clients récurrents tu as sur le groupe, il n'y a pas de réponse. Il n'y a que des estimations.
Le point critique est celui-ci. Dans un seul établissement, le CRM, c'est le manager. Il connaît les habitués, sait qui préfère la table du fond, sait qui vient avec sa famille le dimanche. Dans cinq établissements, cette mémoire distribuée cesse de fonctionner. Et le client le remarque.
Pourquoi ça compte
La fidélisation en restauration n'est pas un détail opérationnel. C'est la colonne vertébrale du modèle. Le coût d'acquisition d'un nouveau client est plusieurs fois supérieur au coût de faire revenir un client existant. C'est vrai dans presque tous les secteurs, et la restauration n'échappe pas à la règle.
Si ton programme de fidélité ne suit pas le client d'une adresse à l'autre, tu traites chaque visite comme si c'était la première. Elle ne l'est pas. Le client s'en souvient. C'est le système qui ne s'en souvient pas.
Le second angle est opérationnel. Un groupe de cinq établissements génère assez de données pour prendre des décisions métier éclairées. Quels créneaux se remplissent en premier. Quels jours de la semaine ont besoin de campagnes. Quelle adresse a le plus de no-shows. Sans plateforme unique, ces données existent, mais personne n'arrive à les lire.
Ce que fait la plateforme
L'architecture de Ramen Joe repose sur trois blocs qui dialoguent entre eux. Un backend Express avec base de données relationnelle, un frontend Next.js public pour les clients finaux, et un ensemble d'applications natives (iOS SwiftUI et Android) qui reproduisent l'expérience du site en contexte mobile.
Le choix d'avoir des applications natives plutôt qu'une PWA mérite explication. Ce n'est pas de la vanité technique. C'est une décision produit motivée par trois éléments concrets.
- Apple Wallet et Google Wallet s'intègrent proprement dans des applications natives — la carte de fidélité arrive directement dans le portefeuille du téléphone et reçoit des mises à jour automatiques dès que le solde change.
- Les push notifications sur iOS ont des restrictions que le web ne permet pas de contourner sans dégrader l'expérience.
- Le tap-to-scan du personnel en restaurant exige une caméra avec autofocus rapide et une latence quasi nulle. Le web perd encore ici.
Côté réservations, le système est désynchronisé du calendrier de chaque établissement. Quand un client réserve à Lisbonne, la table est bloquée uniquement à Lisbonne. Mais la fiche client, l'historique, la préférence de table — tout cela est global.
Carte numérique et expansion sans dépendance technique
La plateforme centralise également la carte numérique des cinq adresses. L'équipe gère produits, informations et configuration de chaque établissement depuis le même back-office, en gardant une expérience cohérente sur le site et dans les applications, sans dupliquer le travail par canal.
La gestion multi-adresses a été pensée pour que l'expansion du groupe ne dépende pas d'une nouvelle intervention technique. L'équipe elle-même peut créer une adresse, définir horaires, contacts, carte, tables, règles de réservation et le reste des paramètres opérationnels.
Une fois configuré, le nouvel établissement devient disponible sur le site et dans les applications mobiles à partir de la même source de données. Il n'y a pas besoin de développer une nouvelle version du site ou des apps juste pour ajouter une unité. Cela réduit le coût et le délai entre la décision d'expansion et l'arrivée effective de la nouvelle adresse dans les canaux numériques.
Fidélité entre établissements : la décision qui change tout
Le point de friction le plus courant dans les groupes de restauration est celui-ci. Chaque établissement veut avoir son programme. Chaque manager veut voir ses clients fidélisés. Et chaque campagne marketing tend à rester bloquée sur une adresse.
Ramen Joe a opté pour l'inverse. Un seul programme, un seul portefeuille de points, un seul client. Cela a des implications non triviales en comptabilité — qui « paie » le tampon donné à Lisbonne et échangé à Porto ? — mais cela se règle avec des règles internes d'imputation, pas avec une fragmentation du système.
Le client ne devrait pas avoir à y penser. Et, en fait, il n'y pense même pas. Il installe l'application une fois, ajoute la carte au Wallet, et l'expérience est la même dans n'importe quel établissement du groupe. C'est ça, le product-market fit en fidélisation.
Le rôle du personnel
Un système de fidélité numérique ne fonctionne que si le personnel joue le jeu. Si la procédure de tampon prend plus de temps que l'ancienne procédure consistant à poser un tampon physique sur une carte en carton, le personnel sabote — non par mauvaise volonté, mais par surcharge aux heures de rush.
Le scanner de Ramen Joe a été conçu avec cette contrainte à l'esprit. Un membre du personnel connecté ouvre l'application, pointe la caméra vers le QR code du client, et le tampon est validé en moins de deux secondes. Sans menus, sans confirmations intermédiaires, sans saisie.
L'autorisation de valider des tampons est séparée de l'autorisation d'accéder au back-office. Un serveur tamponne. Un manager consulte les rapports. Un administrateur du groupe modifie les règles. Cette séparation est banale en SaaS d'entreprise, mais elle est fréquemment ignorée dans les logiciels de restauration — et on se demande ensuite pourquoi il y a eu de la fraude interne sur les points.
Réservations : moins d'automatisation, plus de contrôle
Il y a une tentation dans tout système de réservation moderne : tout automatiser. Confirmation automatique, rappel automatique, réponse automatique aux modifications. Et, dans la plupart des cas, ça marche bien.
En restauration de qualité, ça marche moins bien. Une réservation pour douze personnes un samedi soir ne devrait pas être confirmée automatiquement sans que quelqu'un jette un œil à la salle. Une demande de table précise devrait passer par quelqu'un qui connaît la maison. Et les exceptions de dernière minute ont besoin d'un humain.
La plateforme de Ramen Joe permet les deux modèles, établissement par établissement. Les réservations standard sont automatiques. Les grosses réservations ou celles avec demandes spéciales entrent dans une file d'attente pour validation. Et il y a un canal SMS via Telnyx qui envoie un rappel une heure avant la réservation, ce qui a réduit les no-shows sans générer de spam.
Le SMS est court par conception. Prénom, heure, adresse. Un lien pour annuler. Rien de plus. Le pack commercial a été dimensionné avec une estimation initiale de 1 500 SMS par an, calculée à partir du volume attendu de réservations. Ce n'est pas une limite technique : la capacité peut être ajustée à mesure que l'opération grandit.
Les applications : iOS et Android lancées en simultané
Les versions iOS et Android ont été lancées en même temps. L'application Android est arrivée un peu plus tard parce que le processus de revue de Google Play a pris plus de temps, non par choix de phaser le produit ou de privilégier une plateforme.
Les deux applications ont été développées en parallèle, avec la même proposition de valeur : réservations, fidélité et une expérience cohérente sur les deux plateformes. La différence de visibilité dans les stores découle uniquement des délais de validation de chaque marketplace.
Le coût est évident : deux codebases natives au lieu d'un framework cross-platform comme React Native ou Flutter. C'était un trade-off assumé. Le gain, c'est une application qui se comporte comme la plateforme l'exige, pas comme le dénominateur commun le permet.
Ce qui déraille dans ces projets
La plupart des groupes de restauration qui tentent de construire une plateforme comme celle-ci commettent les trois mêmes erreurs. Ça vaut la peine de les nommer.
- Ils commencent par l'application. Sans backend mature ni règles métier claires, l'app devient une jolie coquille qui reproduit le chaos opérationnel sur des écrans mobiles.
- Ils font confiance aux plugins WordPress pour réservations et fidélité. Ça tient debout pour un établissement. Ça casse à cinq.
- Ils recrutent des agences qui construisent au forfait et disparaissent. Le logiciel ne s'achève pas au lancement. Il y commence.
L'antidote aux trois est le même. Traite le logiciel comme une infrastructure, pas comme une campagne. Investis d'abord dans les fondations — backend, base de données, authentification, permissions, déploiement continu — et seulement ensuite dans la surface visible.
Bonnes pratiques qui ont payé
Certaines décisions paraissent mineures mais ont eu un impact disproportionné sur le fonctionnement du système en production.
D'abord : git comme source unique de vérité. Chaque modification passe par un commit, chaque déploiement est automatique via GitHub Actions. Cela élimine la catégorie de bugs du type « ça marche sur ma machine » et permet de revenir en arrière en quelques minutes si quelque chose casse en production. La documentation officielle de GitHub sur le continuous deployment couvre bien les principes.
Ensuite : de l'internationalisation sérieuse. Le site fonctionne en portugais et en anglais, avec des chaînes centralisées dans des fichiers de traduction. Ça semble excessif pour un restaurant à Lisbonne, jusqu'à ce que tu réalises que 30 % des clients en zone touristique ne parlent pas portugais. Et qu'étendre l'activité vers une nouvelle ville est plus simple quand le système supporte déjà plusieurs langues.
Enfin : séparer sandbox et production avec des règles claires. Ramen Joe dispose d'une version sandbox qui reproduit la production mais avec des données de test. Toute modification y passe en premier. Cela réduit la probabilité de casser une vraie réservation en testant une nouvelle fonctionnalité.
Où ce modèle s'applique
L'architecture de Ramen Joe n'a rien de spécifique au ramen. Elle est applicable à n'importe quel commerce de détail ou d'hospitalité avec plusieurs adresses et une clientèle récurrente. Groupes de restaurants, chaînes de cafés, réseaux de salons de coiffure, cliniques multi-sites, salles de sport avec plusieurs implantations.
Le dénominateur commun est celui-ci : le client est unique, mais l'opération est distribuée. Si ton logiciel ne reflète pas cela, tu paies en friction opérationnelle ce que tu devrais gagner en fidélisation.
Idées clés
- Un groupe de restauration avec plusieurs adresses a besoin d'une plateforme unifiée — des réservations éclatées coûtent plus cher que le logiciel qui les consolide.
- Une plateforme réellement multi-adresses permet d'ajouter de nouvelles adresses, cartes et règles opérationnelles sans réclamer d'intervention technique sur le site ou les apps.
- La fidélité entre établissements n'est pas optionnelle si tu veux de la vraie rétention. Le client se moque de savoir dans quel établissement il a dépensé.
- Les applications natives se justifient quand Wallet, push notifications et caméra rapide sont au cœur de l'expérience.
- Le personnel est utilisateur du système au même titre que le client. Si le flux prend plus de temps que l'ancien processus, le système est saboté par surcharge.
- Git comme source unique, sandbox séparée de la production, i18n dès le premier jour. Ce sont des décisions de fondation qui évitent des refactors coûteux plus tard.
- L'erreur la plus onéreuse, c'est de commencer par l'application avant d'avoir un backend mature.
L'étape naturelle suivante pour un groupe à ce stade n'est pas d'ajouter plus de fonctionnalités. C'est de mesurer. Quels tampons se convertissent en deuxième visite. Quels établissements retiennent le mieux. Quelles campagnes font vraiment bouger l'aiguille. Une plateforme unifiée rend cette analyse possible. Ensuite, il suffit de regarder.