Étude de cas · Restaurant · Commande de repas
Comment nous avons entièrement refondu les applications mobiles d'une chaîne de restauration rapide — clients iOS et Android natifs sur un backend Laravel propre, un catalogue de formules, un panier en temps réel, un chemin d'acquisition de carte stable avec paiements récurrents, un solde de fidélité et une planification de l'heure de retrait — publiées sur l'App Store et Google Play et conçues pour les audiences aux États-Unis et dans l'Union européenne avec les exigences RGPD et CCPA.
L'équipe produit Vilka-Lozhka s'est adressée à YuSMP Group avec deux applications mobiles qui avaient cessé d'accomplir la seule chose qu'une application de commande de repas doit faire de manière fiable : encaisser les paiements. Le code legacy avait accumulé des bugs critiques, et l'intégration de paiement — reposant sur un câblage défaillant d'Apple Pay et Google Pay — échouait suffisamment souvent pour que les clients abandonnent leurs commandes à la caisse. La chaîne avait besoin d'une refonte complète et d'une reconstruction fonctionnelle, non d'un correctif : éliminer les défauts hérités, remplacer le chemin de paiement par un flux d'acquisition de carte stable prenant en charge les paiements ponctuels et récurrents, et moderniser l'interface pour que les applications réussissent la révision App Store et Google Play et aient l'air actuelles face aux concurrents axés sur la livraison. La réalisation devait servir les acheteurs aux États-Unis et dans l'Union européenne depuis une seule codebase, avec la posture de confidentialité et les divulgations qu'un public US et UE attend désormais de toute application qui détient un token de carte et une identité de fidélité. Nous l'avons abordé comme une réécriture from scratch du domaine commande et paiement — un backend Laravel et React propre, Swift natif sur iOS et Kotlin sur Android — tout en préservant le catalogue de menus et les données de fidélité.
Un aperçu de ce que la refonte Vilka-Lozhka a permis de livrer sur iOS, Android et un backend de commande propre au cours de son premier cycle de production.
La décision structurante de ce projet était : refaire ou corriger. Les applications legacy présentaient deux classes de défaillance particulièrement dangereuses à corriger de manière incrémentale : le câblage de paiement défaillant et l'arithmétique de panier peu fiable. Ces deux points se trouvent sur le chemin de l'argent, où une correction négligente double-facture un client ou perd une commande — poursuivre les régressions dans du code accumulé est plus lent et plus risqué qu'une réécriture disciplinée du domaine commande et paiement. Nous avons également évalué les SDK de commande restaurant white-label et les avons écartés : leurs flux de paiement ne pouvaient pas accueillir les règles de fidélité existantes de la chaîne, leurs options d'acquisition n'incluaient pas le chemin de paiement récurrent dont l'entreprise avait besoin, et leurs bundles gonflaient les IPA et APK au-delà des seuils appliqués par l'App Store pour les installations en données mobiles.
Opter pour le natif sur une stack propre de développement d'applications mobiles — Swift sur iOS, Kotlin sur Android, un backend Laravel et React — nous a permis de conserver le catalogue de menus et les données de fidélité tout en réécrivant tout ce qui touche au paiement, à l'état du panier et au statut de commande. Le tableau de comparaison ci-dessous est le raisonnement que nous avons présenté au client avant de s'engager dans la refonte.
| Dimension | Refonte native (Vilka-Lozhka) | Correctif du code legacy | SDK white-label |
|---|---|---|---|
| Stabilité du chemin de paiement | Réécrit avec un seul acquéreur et idempotence | Câblage Apple/Google Pay défaillant hérité | Fixé par le vendeur ; récurrent souvent indisponible |
| Paiements récurrents | Tokenisés, supportés dès le premier jour | Absent ; difficile à ajouter en toute sécurité | Dépend du vendeur ; rarement flexible |
| Règles de fidélité | Grand livre sur mesure, règles propres à la chaîne conservées | Compteurs fragiles sujets à corruption | Modèle de fidélité du vendeur, pas de la chaîne |
| Taille du bundle applicatif | Binaires natifs allégés par plateforme | Transporte du code mort et d'anciennes dépendances | Gonflement SDK dépassant les limites d'installation en données mobiles |
| Risque de validation store | Divulgations de confidentialité propres, interface moderne | Rejets legacy susceptibles de persister | Les rejets SDK partagés affectent tous les clients |
| Migration catalogue et données | Menu + fidélité conservés intacts | Bloqué dans l'ancien schéma | Remodélisation dans le schéma du vendeur |
| Propriété à long terme | Le client possède le code source complet et la feuille de route | Possède un code fragile, la dette s'accumule | Lié aux tarifs et à la feuille de route du vendeur |
Références : Apple StoreKit and in-app payment documentation, Google Play Billing reference, PCI Security Standards Council.
Le client iOS est développé en Swift, et la première chose que nous avons simplifiée est le flux d'inscription. Les applications legacy demandaient trop d'informations avant qu'un client puisse voir un prix ; le flux refondu s'ouvre sur un seul champ numéro de téléphone avec un clavier numérique et un consentement aux conditions d'utilisation intégré, de sorte qu'un nouvel acheteur est à un code SMS de la navigation dans le catalogue. Le catalogue met en avant les formules déjeuner de la chaîne — les articles à marge la plus élevée et rotation la plus rapide — suivis des salades, plats de poisson, soupes et accompagnements, chacun avec une miniature, un prix et un sélecteur qui écrit directement dans le panier sans modal plein écran intermédiaire.
Le catalogue est piloté par les données du backend Laravel, ce qui permet à l'équipe opérationnelle de modifier les prix, remplacer la formule du jour et activer ou désactiver la disponibilité par emplacement sans release d'application. La messagerie orientée retrait est intégrée à l'écran d'accueil — une adresse de livraison et un contrôle « préciser l'heure de retrait » se trouvent au-dessus du catalogue, et l'onboarding pose l'attente qu'une commande fraîche est prête en environ 40 minutes. La même équipe d'ingénierie maintient iOS et Android en parallèle dans le cadre de notre pratique d'ingénierie iOS et Android, de sorte que le modèle de catalogue, l'arithmétique du panier et les règles de fidélité se comportent de manière identique sur les deux plateformes.
Le client Android est développé en Kotlin et partage le modèle de panier et de commande avec iOS via le backend Laravel. Le panier est l'endroit où une application de commande de repas gagne la confiance : les articles sont regroupés, chacun porte sa propre charge d'emballage lorsque le menu l'exige, et le total se recalcule instantanément lorsque les sélecteurs changent — aucun indicateur de chargement, aucun aller-retour par appui, car les règles de tarification sont dupliquées côté client et réconciliées avec le serveur uniquement à la validation. Ce modèle miroir-puis-réconcilié est ce qui a éliminé les bugs d'arithmétique de panier qui affectaient la version legacy, où le total affiché et le total facturé pouvaient diverger.
La validation de commande regroupe trois décisions en un seul écran : l'emplacement de retrait, un commentaire de commande optionnel et une heure de retrait que le client peut modifier, avec l'application affichant l'estimation réaliste « prêt dans environ 40 minutes » plutôt que de promettre un créneau impossible. Le bouton de fidélité se trouve également ici — un client peut appliquer des bonus pour une remise allant jusqu'à 30 % du total de la commande, et la remise est calculée côté serveur pour que le chiffre vu par le client corresponde à celui vu par la cuisine et l'équipe financière. Développer le panier et la validation sur une base saine est le type de développement logiciel sur mesure qui se rentabilise dès la première semaine où une chaîne cesse de perdre des commandes à l'étape de paiement.
La refonte du paiement était au cœur de la mission. Nous avons remplacé le câblage de portefeuille défaillant par une intégration d'acquisition de carte directe pilotée par le backend, prenant en charge à la fois un paiement ponctuel et un chemin récurrent tokenisé pour qu'un client récurrent passe une nouvelle commande sans ressaisir ses coordonnées bancaires. L'application ne stocke jamais un numéro de carte — le prestataire d'acquisition retourne un token opaque associé au dossier client, et chaque débit s'effectue contre ce token dans un traitement conforme aux normes PCI-DSS. Les webhooks de règlement confirment la réception des fonds avant que la commande ne soit transmise à la cuisine, les clés d'idempotence rendent les nouvelles tentatives sûres pour qu'un réseau instable ne produise jamais une double facturation, et les remboursements sont réconciliés contre le même token pour que le tableau de bord opérateur ne soit jamais en désaccord avec la réalité. La confirmation « votre commande a été payée avec succès » n'est affichée qu'après la validation du webhook, jamais de manière optimiste.
Côté données, la refonte a été structurée dès le début pour des audiences aux États-Unis et en UE. Les données personnelles sont limitées au numéro de téléphone et à l'historique de commandes dont une commande à emporter a réellement besoin ; le solde de fidélité est un grand livre en ajout uniquement plutôt qu'un champ mutable ; et le consentement est recueilli explicitement lors de l'inscription. La posture s'aligne sur les obligations du RGPD pour les utilisateurs dans l'Union européenne et sur les obligations CCPA / CPRA pour les utilisateurs en Californie et plus largement aux États-Unis.
Posture de conformité : Aligné RGPD · Prêt ISO 27001 · SOC 2 Type II en cours · Compatible HIPAA · CCPA reconnu.
Une refonte en cinq phases qui a conduit Vilka-Lozhka d'une application legacy défaillante à une version stable approuvée par les stores sur iOS, Android et un backend de commande propre.
Recensement des bugs critiques legacy, cartographie du chemin de paiement défaillant, périmètre du catalogue et des données de fidélité à conserver, et établissement de la posture RGPD + CCPA pour les audiences US et UE.
Backend propre Laravel + React, schéma du catalogue et du grand livre de fidélité, conception de l'intégration d'acquisition avec paiements ponctuels et récurrents tokenisés et webhooks de règlement idempotents.
Client Swift iOS et client Kotlin Android partageant un modèle de commande unique : inscription par téléphone, catalogue de formules, panier en temps réel, planification du retrait et bouton de rachat fidélité.
QA de paiement de bout en bout — prévention des doubles facturations, réconciliation des remboursements, parité arithmétique du panier entre client et serveur, et gestion des tokens conforme PCI-DSS sous charge.
Soumission App Store et Google Play avec interface modernisée et divulgations de confidentialité sur les storefronts US et UE, suivi d'une fenêtre de retour opérateur et de stabilisation.
Le programme de fidélité était le sous-système auquel nous avons apporté le plus grand soin, car une chaîne de restauration vit ou meurt selon que le chiffre qu'un client voit à la caisse correspond à ce que voient la cuisine et l'équipe financière dans le back-office. Nous avons développé le solde comme un grand livre en ajout uniquement plutôt qu'un compteur mutable : les points ne s'accumulent que sur les commandes réglées, les rachats sont plafonnés par commande selon une règle métier — une remise allant jusqu'à 30 % du total de la commande — et chaque accumulation ou consommation est une entrée de grand livre que le tableau de bord opérateur lit directement. Cette conception rend les litiges auditables et permet à la chaîne de lancer des promotions sans corrompre les historiques de soldes, car une promotion n'est qu'une nouvelle règle d'accumulation superposée à la même histoire immuable. Le back-office opérateur lit la même source de vérité unique que l'application, de sorte qu'un responsable réconciliant la caisse n'a jamais besoin de deviner quel système fait autorité. L'ensemble du sous-système a été développé pour l'extensibilité : l'ajout d'un niveau de fidélité multi-emplacements, d'un bonus de parrainage ou d'un programme de compte entreprise est une modification de configuration dans le service de grand livre et de droits plutôt qu'une release client, ce qui évite à la chaîne le cycle de révision App Store et Google Play pour les changements marketing courants.
Les applications Vilka-Lozhka ont été développées pour être publiées sur Apple App Store et Google Play avec des storefronts actifs aux États-Unis et dans l'Union européenne depuis une seule codebase. La même version sert les acheteurs en Californie, New York, Texas, Floride et Washington aux États-Unis, et aux Pays-Bas, en Allemagne, en France, en Irlande et en Suède dans l'UE, sans application séparée par région. Les flux de consentement sont conscients de la région au niveau du client : les utilisateurs dans l'UE et l'EEE reçoivent un écran de consentement granulaire conforme au RGPD avec des interrupteurs distincts pour les analyses produit optionnelles, tandis que les utilisateurs en Californie reçoivent une divulgation conforme CCPA « Ne pas vendre ni partager mes informations personnelles » dans le même flux. Les pratiques de traitement des données sont alignées sur le RGPD pour les utilisateurs européens et sur le patchwork de lois étatiques américaines — CCPA / CPRA (Californie), VCDPA (Virginie), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) et Oregon CPA. Comme l'application réduit les données personnelles à un numéro de téléphone et un historique de commandes, la conformité régionale se résume à une divulgation honnête plutôt qu'à une ségrégation des données par juridiction.
Le paiement et l'acquisition ont été le domaine que nous avons le plus renforcé pour un déploiement cross-marché : la couche d'acquisition tokenisée abstrait le prestataire derrière une interface unique, de sorte que changer ou ajouter un acquéreur régional pour les États-Unis ou l'UE est une modification de configuration backend plutôt qu'une reconstruction client. La classification d'âge App Store et la classification Google Play ont toutes deux été calibrées pour un ensemble de fonctionnalités de commande de repas avec paiements, citant directement les obligations RGPD et les obligations CCPA californien dans la politique de confidentialité intégrée. L'équipe d'ingénierie travaille selon une journée CET avec un chevauchement côte Est US (9 h–13 h ET) pour les points quotidiens, la coordination des révisions store et les interventions — le fuseau horaire qui permet à une équipe produit US et à une équipe d'ingénierie UE de partager quatre heures de chevauchement en direct chaque jour.
La feuille de route active de développement logiciel sur mesure pour Vilka-Lozhka inclut un mode de livraison aux côtés du flux de retrait actuel avec dispatch des coursiers, un niveau de fidélité multi-emplacements avec comptes entreprise, des rappels de recommande pilotés par notifications push liés au grand livre de fidélité et une surface de commande web partageant le même backend Laravel. Les plans d'infrastructure comprennent l'ajout d'un second acquéreur régional derrière l'interface de paiement tokenisé existante pour la couverture US et UE, et des analyses opérateur plus riches intégrées dans la feuille de route Cloud & DevOps pour que la chaîne puisse voir la taille du panier, le taux de rachat et la précision de l'heure de retrait par emplacement en quasi temps réel.
Si vous planifiez une application de commande restaurant ou restauration rapide, remplacez une intégration de paiement défaillante ou refondez une application alimentaire legacy qui a cessé de convertir à la caisse pour des audiences aux États-Unis et en UE, nous avons livré cette stack de bout en bout et pouvons réduire significativement le délai de développement. Le cas complet est documenté sur yusmpgroup.com/cases/vilka-losja (iOS et Android), et l'équipe d'ingénierie qui le soutient est au sein de YuSMP Group. Nous travaillons à prix fixe pour les MVP bien définis et en équipes dédiées pour la livraison continue, avec une journée CET et un chevauchement garanti côte Est US (9 h–13 h ET) pour les points quotidiens, démonstrations et interventions.
Un MVP ciblé pour une chaîne de restauration couvrant des clients iOS et Android natifs, un catalogue de formules, un panier en temps réel, un prestataire d'acquisition et la planification du retrait coûte généralement entre 90 k€ et 200 k€. L'ajout d'un programme de fidélité, d'une facturation récurrente, du support multi-emplacements, d'intégrations cuisine et opérateur, et d'analyses porte un produit complet à 220 k€–450 k€. Les principaux postes de coût sont l'intégration du paiement et de l'acquisition, la logique de fidélité et de droits, et le maintien de deux clients natifs en parallèle sur iOS et Android.
Les applications de commande alimentaire legacy échouent généralement d'abord sur le chemin de paiement et l'arithmétique du panier, et ce sont les endroits les plus difficiles à corriger en toute sécurité, car chaque correctif risque une double facturation ou la perte d'une commande. Lorsque l'intégration d'acquisition est défaillante et que la codebase a accumulé des bugs critiques, une refonte disciplinée sur un backend Laravel propre avec des clients Swift et Kotlin natifs est plus rapide vers une version stable approuvée par les stores que de chasser les régressions dans l'ancien code. Nous avons conservé le catalogue et les données de fidélité tout en réécrivant le flux de commande et de paiement depuis les principes premiers.
L'acquisition par carte pour une application alimentaire nécessite à la fois des paiements ponctuels et un chemin récurrent tokenisé pour que les clients récurrents puissent commander à nouveau sans ressaisir leurs coordonnées bancaires. L'application ne stocke jamais le numéro de carte complet — le prestataire d'acquisition retourne un token opaque associé au dossier client, et le backend débite contre ce token dans un traitement conforme PCI-DSS. Les webhooks confirment le règlement avant que la commande ne soit transmise à la cuisine, les clés d'idempotence empêchent les doubles facturations lors des nouvelles tentatives, et les remboursements sont réconciliés contre le même token pour que le tableau de bord opérateur reste cohérent.
Un programme de fidélité nécessite une source de vérité unique pour le solde que l'application et le back-office opérateur lisent tous deux, pour que le chiffre qu'un client voit à la caisse corresponde toujours à ce que voient la cuisine et l'équipe financière. Les points ne s'accumulent que sur les commandes réglées, les rachats sont plafonnés par commande selon une règle métier (ici, une remise allant jusqu'à 30 % du total de la commande), et chaque accumulation ou consommation est une entrée de grand livre en ajout uniquement plutôt qu'un compteur mutable. Ce grand livre rend les litiges auditables et permet à la chaîne de lancer des promotions sans corrompre les historiques de soldes.
Un MVP ciblé avec des clients iOS et Android natifs, un catalogue de formules, un panier en temps réel, un prestataire d'acquisition et la planification du retrait prend généralement 10 à 16 semaines. L'ajout d'un programme de fidélité, d'une facturation récurrente, du support multi-emplacements et des intégrations opérateur ajoute 6 à 10 semaines. La passe d'approbation store — divulgations de confidentialité, révision de la politique de paiement, et orchestration de soumission App Store et Google Play — est fréquemment sous-estimée et devrait être budgétée à 3 à 5 semaines de travail dédié.
Cas connexes
Plateforme de livraison de repas avec commande en temps réel, dispatch de coursiers et flux de paiement aux États-Unis et en UE.
Voir le cas →
Expérience de commande restaurant avec catalogue de menus, panier et retrait — application mobile native pour les clients US et UE.
Voir le cas →
Réalisation de commerce retail omnicanal avec catalogue, panier, fidélité et paiement sur les storefronts US et UE.
Voir le cas →
Applications iOS, Android et cross-platform natives avec pipelines de déploiement prêts pour les stores.
Explorer le développement d'applications mobiles →
Plateformes personnalisées conçues selon votre modèle d'affaires, évoluant facilement de l'MVP à des millions d'utilisateurs.
Explorer le développement logiciel sur mesure →
Infrastructure résiliente, CI/CD et observabilité pour que les flux de paiement et de commande restent opérationnels sous charge.
Explorer le Cloud & DevOps →Partagez quelques détails et un consultant senior vous répondra dans un délai d'un jour ouvrable.