Application mobile pour franchise : 5 critères d'architecture à valider avant de signer

Une application mobile mono-restaurant et une application mobile multi-franchise sont deux produits radicalement différents. La seconde nécessite des décisions architecturales structurantes dès la conception. Mal faites, vous vous retrouvez à 18 mois avec une app qui ne tient pas la charge ou qui demande 2x plus d'effort de gestion qu'elle ne devrait.

Voici les 5 critères techniques à valider avec votre prestataire avant de signer.

Critère 1, Multi-tenant ou single-tenant ?

Le choix structurant

Multi-tenant : tous les restaurants partagent la même infrastructure (base de données, serveurs, code). Chaque restaurant est isolé logiquement via un identifiant (tenant_id), mais physiquement c'est la même chose.

Single-tenant : chaque restaurant a sa propre instance (base, serveurs, parfois même son propre code dupliqué).

Pourquoi c'est critique

Le multi-tenant est 2-5x moins cher à maintenir et à faire évoluer. Quand vous corrigez un bug, vous le corrigez une fois pour tout le monde. Le single-tenant nécessite des déploiements et corrections par site.

Cependant, le multi-tenant exige une discipline architecturale forte : chaque requête doit filtrer par tenant_id, sinon risque de fuite de données entre franchisés (catastrophe RGPD).

Question à poser au prestataire

"Comment est isolée la donnée entre franchisés ? Pouvez-vous garantir qu'un bug ne peut pas exposer les données d'un restaurant à un autre ?"

Réponse à attendre : isolation par tenant_id appliquée dans chaque requête, audit régulier, tests automatisés qui vérifient l'isolation.

Critère 2, Catalogue national vs catalogue local

Le choix structurant

Vos 50 restaurants servent-ils tous exactement les mêmes plats (chaîne homogène type Big Mamma) ou chaque franchisé peut-il avoir sa carte (groupe de marques de quartier) ?

Trois modèles possibles :

1. Catalogue 100 % national : tous les restaurants ont la même carte, gérée centralement
2. Catalogue national + ajouts locaux : un catalogue de base obligatoire, chaque franchisé ajoute ses spécialités
3. Catalogue 100 % local : chaque franchisé fait sa carte indépendamment

Pourquoi c'est critique

Le choix détermine la hiérarchie des droits dans l'application :

• Modèle 1 : seul le siège modifie la carte. Les franchisés n'ont pas accès en écriture.
• Modèle 2 : siège pousse la base obligatoire, franchisés ajoutent leurs lignes. Workflow de validation possible.
• Modèle 3 : chaque franchisé est autonome. Le siège a une vue lecture seule.

Changer de modèle en cours de route = refonte majeure. Décidez avant de signer.

Question à poser

"Comment gérez-vous le catalogue ? Est-ce qu'un franchisé peut ajouter un plat sans validation du siège, ou est-ce qu'un workflow de validation est imposé ?"

Critère 3, Programme de fidélité partagé ou cloisonné

Le choix structurant

Quand un client cumule des points à votre restaurant Paris 11e, peut-il les utiliser à votre restaurant Lyon Part-Dieu ?

Programme partagé : les points et le statut suivent le client à travers tous les restaurants du groupe. Effet réseau.

Programmes cloisonnés : chaque restaurant a son propre programme. Le client doit s'inscrire à chacun. Pas d'effet réseau.

Programme partagé avec spécificités locales : points partagés, mais récompenses propres à chaque restaurant.

Pourquoi c'est critique

Le programme partagé est un argument commercial fort pour les franchisés : "rejoignez la marque, votre clientèle accède immédiatement à la base nationale". Mais la mise en place est plus complexe :

• Gestion des soldes de points en multi-sites (qui paie quand un client utilise des points à un autre restaurant ?)
• Reporting consolidé groupe vs reporting franchisé
• Risque de fraude inter-sites

Question à poser

"Si un client cumule 100 € de points chez Paris et les dépense chez Lyon, comment est traitée la compensation comptable entre les deux franchisés ?"

Réponse à attendre : système de clearing centralisé, validation comptable mensuelle ou trimestrielle, contrats franchise mis à jour pour intégrer cette mécanique.

Critère 4, Géolocalisation et routage des commandes

Le choix structurant

Quand un client ouvre l'app, quel restaurant lui est présenté par défaut ?

Options :

• Restaurant le plus proche (géolocalisation GPS)
• Restaurant dernier visité (mémoire de session)
• Restaurant favori (préférence client)
• Sélection manuelle obligatoire à chaque ouverture

Et quand un client commande sans préciser le restaurant : où sa commande atterrit-elle ?

Pourquoi c'est critique

Les erreurs de routage = commandes parties dans le mauvais restaurant = clients mécontents. Sur une franchise mature, c'est une source de friction quotidienne si l'architecture est mal pensée.

Question à poser

"Quel est le flow de routage d'une commande ? Que se passe-t-il si un client se déplace pendant qu'il commande (par ex. il commence en gare de Lyon, finit dans le train) ?"

Réponse à attendre : sélection explicite du restaurant à chaque commande, validation au moment du paiement, possibilité d'annuler / changer avant la préparation.

Critère 5, Reporting consolidé et droits d'accès

Le choix structurant

Qui voit quoi dans l'application back-office ?

Hiérarchie typique :

• Siège (DG/marketing) : tout, en lecture seule sur les données restaurant, en écriture sur le catalogue national et les paramètres groupe
• Manager régional : tous les restaurants de sa zone (3-15 sites)
• Gérant restaurant : son restaurant uniquement
• Comptable groupe : reporting financier consolidé, pas d'accès opérationnel

Pourquoi c'est critique

Les droits d'accès ne se rajoutent pas après. Si l'app n'est pas pensée multi-rôle dès le départ, vous vous retrouvez à :

• Donner à un gérant un accès qu'il ne devrait pas avoir
• Ne pas pouvoir donner à un régional une vue agrégée
• Limiter le siège dans son reporting

Question à poser

"Combien de rôles d'utilisateurs back-office sont prévus ? Pouvez-vous me montrer le modèle de permissions ?"

Réponse à attendre : au moins 4 rôles (siège, régional, gérant, comptable), avec possibilité d'en ajouter, et permissions paramétrables par fonctionnalité.

Les drapeaux rouges dans les devis franchise

Si vous voyez un de ces signes dans une proposition pour votre projet franchise, soyez vigilant :

Drapeau rouge 1, "On verra ça après"

Si l'architecte ne peut pas décrire ces 5 critères avant de chiffrer, c'est qu'il n'a pas réfléchi à votre cas spécifique. Le devis sera fragile.

Drapeau rouge 2, "C'est la même chose qu'un restaurant indépendant, juste plus de sites"

Faux. Un projet franchise nécessite 2-3x plus d'effort de conception qu'un mono-restaurant. Si le prestataire ne le reconnaît pas, il sous-estime, vous le paierez en délais.

Drapeau rouge 3, "Nous adaptons notre template franchise existant"

Le mot "template" est ambigu : soit ils ont une vraie architecture multi-tenant testée (excellent), soit ils ont juste copié 5 fois leur produit mono-restaurant (catastrophe). Demandez à voir 2 projets franchise déjà livrés.

Drapeau rouge 4, Pas de mention de la migration de données

Si vous avez déjà une app ou un SaaS pour vos restaurants existants, il faut migrer les données. Si ce sujet n'est pas dans le devis, c'est qu'il n'a pas été pensé.

Drapeau rouge 5, Pas de phase pilote prévue

Le déploiement à 50 restaurants en un jour est une recette pour le chaos. Le devis devrait prévoir une phase pilote sur 2-3 restaurants avant le déploiement national. Voir notre guide de digitalisation franchise.

Cas pratique : 2 architectures pour 2 réalités

Cas 1, Franchise homogène (chaîne de pizzas)

50 restaurants, même carte, même image, même mécanique de fidélité.

Architecture :

• Multi-tenant
• Catalogue 100 % national
• Fidélité partagée
• Géolocalisation auto vers le restaurant le plus proche
• 3 rôles back-office : siège, régional, gérant

Cas typique, projet en 14-16 semaines, budget 25-35 k€.

Cas 2, Groupe multi-marques (5 enseignes différentes)

15 restaurants, 5 marques, chacune avec son image, sa carte, sa clientèle.

Architecture :

• Multi-tenant avec sous-tenants par marque
• Catalogue par marque, déclinable localement
• Fidélité par marque (pas inter-marques, sauf si c'est votre stratégie)
• 5 apps distinctes téléchargeables OU 1 app avec sélection marque
• 5 rôles back-office incluant rôle "directeur marque"

Plus complexe, projet en 18-22 semaines, budget 40-60 k€.

En résumé

Avant de signer un projet application mobile pour franchise, valider avec le prestataire :

1. Multi-tenant correctement implémenté avec isolation des données
2. Modèle de catalogue (national, mixte, local) explicitement défini
3. Programme de fidélité partagé ou cloisonné, avec mécanique de clearing
4. Routage des commandes avec sélection explicite par le client
5. Hiérarchie de droits d'accès avec au moins 4 rôles paramétrables

Si le prestataire ne peut pas répondre à ces 5 questions avec précision avant le chiffrage, trouvez un autre prestataire.

Pour discuter de l'architecture de votre application franchise, demandez-nous une estimation, ou explorez notre approche application mobile pour franchise.