Accueil · Nos articles

L'application

Une seule application pour tout un réseau, sans développement par ouverture

Une application par restaurant, c'est vingt applications à maintenir, vingt fiches sur les magasins d'applications et vingt occasions de casser quelque chose. Les choix qui l'évitent se prennent au début, et ils sont peu nombreux.

Écrit par l'équipe RassineLecture 6 minutesMis à jour en août 2026

Le réflexe, quand un réseau grandit, est de faire une application pour le premier restaurant qui la demande. Elle marche, un deuxième la veut, on la duplique, et c'est là que la dette commence : chaque duplication est un projet, chaque mise à jour se multiplie, et chaque nouveauté doit être déployée autant de fois qu'il y a d'adresses.

Une application de réseau se conçoit à l'envers : une seule application, qui sait dans quel restaurant se trouve le client, et qui affiche ce qui est vrai à cet endroit.

Les quatre choix qui décident de tout

1 · L'isolation par restaurant

Chaque restaurant a ses horaires, son stock, ses indisponibilités, ses services. L'application doit traiter ces informations comme des données, pas comme du code. Concrètement : un franchisé qui ferme un mardi le déclare lui-même et c'est appliqué en quelques secondes, sans mise à jour de l'application.

2 · Le catalogue commun, les prix locaux

Les références et les descriptions appartiennent au réseau. Le prix, la disponibilité et les horaires appartiennent au restaurant. Cette séparation est la plus structurante de toutes : sans elle, chaque adaptation locale devient une exception dans le code, et vous ne pouvez plus rien changer globalement.

3 · La fidélité, partagée ou non

C'est un choix de modèle plus qu'un choix technique, et il faut le trancher avant de développer. Une fidélité partagée à l'échelle du réseau donne un vrai avantage au client et renforce la marque, mais elle suppose de régler entre franchisés qui supporte la remise quand le point cumulé chez l'un est dépensé chez l'autre. Une fidélité par restaurant évite cette discussion et affaiblit l'intérêt de l'application.

4 · Une seule fiche sur les magasins d'applications

Une application, une fiche, un historique d'avis, un budget d'acquisition. Vingt fiches, c'est vingt notes moyennes qui démarrent à zéro et aucun effet de notoriété.

Ce qu'il ne faut pas mettre dans l'application

• La gestion interne du franchisé. Elle a sa place dans son portail, pas dans l'application ouverte aux clients.
• Les fonctions qu'un seul restaurant réclame. Elles deviennent une exception à maintenir pour tout le monde. Si le besoin est réel, il finira par remonter d'ailleurs, et là il sera légitime.
• Un compte client obligatoire pour commander. C'est la première cause d'abandon. Le compte se propose après la première commande, quand il apporte quelque chose.
• Tout le catalogue dès le premier jour. Les meilleures ventes suffisent pour démarrer, et la première version sort trois mois plus tôt.

Comment la déployer sur un réseau existant

1. Commencez par deux ou trois restaurants volontaires, de formats différents. Un pilote homogène ne révèle rien.
2. Laissez tourner un mois complet, jours creux compris. La plupart des problèmes apparaissent le premier samedi de forte affluence.
3. Corrigez avant d'élargir, jamais pendant. Un déploiement réseau qui rencontre un bug connu détruit la confiance pour un an.
4. Ouvrez ensuite par vagues, en accompagnant chaque vague. Un franchisé qui découvre l'application par un mail ne l'utilisera pas.

Ce qu'il faut retenir

Une seule application, un catalogue commun avec des prix locaux, tout ce qui est propre au restaurant traité comme une donnée, et la question de la fidélité tranchée avant la première ligne de code. Ces quatre décisions prises au départ font qu'une vingtième ouverture ne coûte rien. Prises trop tard, elles coûtent une réécriture.