Créer une application de livraison de repas : l’exemple de Nibblify

Trois publics, trois applications : qui fait quoi dans une commande ?

Une commande de repas met en jeu trois personnes aux gestes et aux écrans différents. Le client cherche un plat, compose son panier, paie et suit sa livraison. Le restaurant accepte la commande, la prépare et tient à jour son menu, ses offres et ses horaires. Le livreur prend son service, accepte une course, suit l’itinéraire jusqu’au restaurant puis jusqu’au client, et confirme la remise.

Réunir ces rôles dans une seule application imposerait à chaque utilisateur des écrans qui ne le concernent pas, et chaque mise à jour toucherait tout le monde. Séparées, les applications s’adaptent à leur public : selon l’article « Comment nous avons construit Nibblify », celle des livreurs est conçue pour rester légère sur les téléphones d’entrée de gamme qu’ils utilisent réellement.

Nibblify applique ce découpage : une application par rôle, sur l’App Store et Google Play. Les trois écrans ci-dessous suivent les étapes d’une commande.

Étape 1 · Le client commande

Nibblify Food

Le client parcourt le menu d’un restaurant, filtre les plats et remplit son panier.

App Store Google Play

Étape 2 · Le restaurant prépare

Nibblify Partner

L’écran cuisine liste les nouvelles commandes, à accepter ou à refuser, puis celles en préparation, à marquer comme prêtes.

App Store Google Play

Étape 3 · Le livreur livre

Nibblify Driver

Une demande de livraison indique le restaurant où récupérer la commande, la distance et le gain estimé, avec un compte à rebours pour l’accepter.

App Store Google Play

Visuels des applications avec des données de démonstration : les restaurants, montants, distances et gains affichés sont fictifs.

Le rôle de Zakaryae Ait Ouamer, les technologies et l’état d’avancement du projet sont résumés dans l’étude de cas Nibblify.

Que fait le backend d’une application de livraison ?

Le backend est la partie invisible dont tout dépend : il identifie les utilisateurs, enregistre les commandes, calcule les montants, attribue les courses et prévient chacun au bon moment. Chez Nibblify, les trois applications et le portail d’opérations partagent un seul backend Firebase. L’article « Comment nous avons construit Nibblify », publié le 5 août 2026, en liste les services : Authentication, Firestore, Storage, Messaging, Remote Config, App Check, Crashlytics et Analytics. Des règles de sécurité écrites à la main, 1 119 lignes au total, protègent ses 47 collections : selon l’article, la base de données est le contrat entre les quatre applications.

Les décisions sensibles se prennent côté serveur

Chez Nibblify, la logique sensible tourne dans 238 Cloud Functions écrites en JavaScript, environ 25 500 lignes d’après le même article. Elles gèrent les commandes, les versements, l’attribution des livreurs, le chiffrement AES-256 des données personnelles, l’export de ces données à la demande, les notifications push et l’API d’administration. Google Maps fournit la localisation.

Pourquoi côté serveur ? Une application installée sur un téléphone peut être ancienne, modifiée ou hors ligne ; un prix, une course ou un versement doivent être décidés à un seul endroit, que toutes les applications consultent. La confidentialité suit la même logique : d’après la page « À propos » de Nibblify, les données personnelles sont chiffrées en AES-256 avant d’atteindre la base.

Le portail d’opérations, l’application que les clients ne voient pas

Une plateforme de livraison demande aussi du travail en coulisses : vérifier un restaurant avant sa mise en ligne, contrôler les documents des livreurs, aider un client dont la commande pose problème. Chez Nibblify, ces tâches passent par un portail interne en Flutter Web, séparé des applications grand public et absent des stores.

L’article « Comment nous avons construit Nibblify » en décrit le périmètre : vérification des restaurants, documents et portefeuilles des livreurs, assistance sur les commandes, cartes en direct, statistiques et supervision, avec 102 Cloud Functions réservées aux administrateurs. Avec 49 900 lignes de code, c’est, par sa taille, la deuxième des quatre applications, derrière l’application client. Conclusion pour votre budget : l’outil d’opérations n’est pas une option de dernière minute, c’est une application à part entière.

Une seule base de code Flutter pour iOS, Android et le web

Selon l’article « Comment nous avons construit Nibblify », les quatre applications partagent un même langage, Dart 3.10, et une même boîte à outils d’interface, Flutter, avec Riverpod, Provider et go_router : iOS, Android et le web sortent ainsi d’une seule base de code. Concrètement, chaque application mobile est écrite une fois puis publiée sur les deux stores, et le portail utilise la même technologie dans le navigateur.

Le tableau reprend les volumes publiés dans l’article, mesurés le 2 août 2026, hors dépendances et fichiers générés : ils indiquent le poids relatif de chaque partie, pas un délai ni un coût.

Sur l’ensemble de la plateforme, y compris des parties absentes du tableau, l’article dénombre 307 000 lignes écrites à la main, hors fichiers générés, par une seule personne travaillant avec des modèles d’IA de pointe, une méthode baptisée « vibe engineering ». Zakaryae Ait Ouamer y fixe l’intention, l’architecture et le modèle de données ; les modèles rédigent les premiers jets, relus ligne à ligne ; le dépôt apporte la preuve, avec 296 fichiers de tests Dart, des tests d’intégration sur émulateur et des tests des règles de sécurité.

Deux détails qui comptent en production

En production, un prix change pendant qu’un client hésite et un même plat s’écrit de plusieurs façons. Nibblify traite ces deux cas, à prévoir dans toute application de livraison.

Publier trois applications sur deux stores : dates, frais et délais

Trois applications sur deux stores, ce sont six fiches à préparer, à faire examiner et à tenir à jour. Les applications Nibblify sont publiées sous le nom de développeur « Zakaryae Ait Ouamer », avec un compte par store, et sont gratuites. Elles sont arrivées sur l’App Store l’une après l’autre :

1. 16 janvier 2026 : Nibblify Partner, l’application des restaurants
2. 9 mars 2026 : Nibblify Food, l’application des clients
3. 8 septembre 2026 : Nibblify Driver, l’application des livreurs

Les trois ont reçu une mise à jour sur l’App Store le 16 octobre 2026.

Les comptes des stores sont ouverts à votre nom, et un compte publie plusieurs applications : trois applications coûtent en frais de store autant qu’une seule.

Combien coûte une application de livraison, et en combien de temps ?

Une plateforme de livraison correspond à mon offre Plateforme multi-apps : à partir de 16 900 € HT, pour un délai habituel de 4 à 6 mois. Elle réunit les briques décrites dans ce guide :

C’est un prix de départ hors taxes, valable jusqu’au 31 décembre 2026 ; le devis écrit fixe le prix final selon les écrans, les rôles et les intégrations. Ce prix ne dit rien du coût de Nibblify, qui n’est pas publié. Comptes des stores, hébergement et usage de Firebase vous sont facturés directement par leurs fournisseurs.

Pour le prix d’une application seule, de ses options et de sa maintenance, consultez le guide « Combien coûte une application mobile ? ».

Ce qui n’est pas encore fait

Ce guide s’appuie sur un produit publié, pas sur un service en activité. Au 22 octobre 2026 :

• les commandes clients de Nibblify ne sont pas encore ouvertes : son site annonce que la livraison se prépare au Mans ;
• Nibblify a signé le 4 août 2026 un accord de pré-incubation avec Le Mans Innovation, toujours en place pendant la préparation du lancement ;
• aucun chiffre d’usage n’est publié : ni commandes, ni chiffre d’affaires, ni nombre d’utilisateurs ;
• les écrans présentés ici contiennent des données de démonstration ;
• la tenue en charge, avec de vrais clients et de vrais livreurs, reste à observer après l’ouverture.

Vérifiable dès aujourd’hui : les trois applications sur les stores, leurs dates de publication et l’architecture décrite par leur développeur.