Étude de cas · Événements & Billetterie · Mobile
Comment nous avons construit Move2Armenia — une application native iOS et Android pour découvrir des événements, réserver une place et acheter des billets QR dans Erevan et d'autres villes arméniennes. Le produit dessert le marché arménien ; le build a été conçu aux standards qu'attend notre clientèle américaine et européenne, sur un backend Symfony et React avec des clients mobiles entièrement natifs publiés sur l'App Store et Google Play.
L'équipe produit de Move2Armenia souhaitait une application d'événements qui aide les nouveaux arrivants et les locaux à Erevan et dans d'autres villes arméniennes à trouver quelque chose à faire ce soir et à le réserver en un seul flux — pas d'onglet navigateur, pas de billet PDF, pas de copier-coller d'une adresse de lieu dans une application de cartographie. Le niveau d'exigence était celui des applications grand public américaines et européennes que le public avait déjà sur ses téléphones : un fil d'événements rapide avec un rail de sélection de l'éditeur, des filtres par catégorie et date qui semblent instantanés, une page de détail d'événement qui répond à « où, quand, combien, et est-ce complet », et un billet intégré qui fonctionne à l'entrée même avec une connexion instable. Le client apportait une fondation backend existante ; nous avons pris en charge le frontend React et les clients mobiles natifs iOS et Android, et avons été intégrés par YuSMP Group précisément parce que l'équipe avait déjà livré ce type de produit grand public. Le résultat est une application native, disponible sur l'App Store et Google Play, construite selon les standards d'ingénierie et de confidentialité qu'attendent nos clients américains et européens même si le marché du produit est l'Arménie.
Un aperçu de ce que le build Move2Armenia a permis de réaliser sur iOS, Android et un backend Symfony au cours de son premier cycle de production. Les chiffres sont des faits de livraison et des plages typiques, non des métriques confidentielles du client.
Le choix de plateforme détermine chaque autre décision dans une application d'événements grand public. Nous avons développé Move2Armenia en iOS natif avec Swift et Android natif avec Kotlin, avec un backend Symfony partagé et un frontend web React, plutôt qu'une enveloppe multiplateforme unique. Une application d'événements accomplit son travail le plus important à l'entrée du lieu, où elle s'appuie sur la caméra, le portefeuille, les notifications push et un billet QR qui doit s'afficher même sans signal. Les clients natifs donnent un accès prévisible à ces capacités, un défilement fluide des listes sur les fils longs, et un chemin d'affichage du billet qui ne dépend pas d'une webview survivant à une connexion morte. Le compromis — deux bases de code au lieu d'une — est compensé en gardant toute la logique de réservation, d'inventaire et de tarification dans le backend Symfony afin que les clients restent légers.
Le web uniquement a été éliminé rapidement : un onglet navigateur ne peut pas tenir un billet scannable de façon fiable à une entrée, et les rappels push « votre événement commence dans une heure » constituent la boucle d'engagement dont le produit dépend. Une enveloppe multiplateforme était une décision plus proche, mais le fil d'événements long et chargé en images et l'exigence de billet hors ligne nous ont poussés vers le natif pour les deux stores. C'est le même équilibre que nous recommandons dans notre pratique de développement d'applications mobiles pour les clients américains et européens publiant des applications grand public sur l'App Store et Google Play.
| Dimension | Natif (Move2Armenia) | Shell multiplateforme | Web uniquement / PWA |
|---|---|---|---|
| Billet QR hors-ligne à l'entrée | Fiable — en cache, s'affiche sans signal | Généralement correct ; dépend du bridge | Fragile — éviction onglet, sans signal ça casse |
| Rappels push | APNs / FCM de première classe | Pris en charge via plugins | Limité, surtout sur iOS |
| Performance de défilement de fil long | Recyclage de liste natif — fluide | Bon avec optimisation | Saccadé sur appareils bas de gamme |
| Accès caméra / portefeuille | APIs plateforme directes | Via plugin | Contraint par le navigateur |
| Logique métier partagée | Centralisée dans le backend Symfony | UI + backend partagés | Backend uniquement |
| Présence App Store / Play | Applications store de première classe | Applications store via wrapper | Pas de fiche store native |
| Finition par plateforme | Complète — idiomes Swift / Kotlin | Compromis au dénominateur commun le plus bas | Lié au navigateur |
Références : Apple Swift documentation, Android Kotlin guides, Symfony documentation.
Le client iOS est développé en Swift, l'écran d'accueil étant organisé autour d'un fil d'événements rapide : un champ de recherche, une bande de dates horizontale, un menu déroulant de catégories et des chips d'étiquettes, suivis d'un rail de sélection de l'éditeur et d'une section « recommandé pour vous » pilotée par les intérêts qu'un utilisateur sélectionne lors de l'intégration. Le filtrage est conçu pour sembler instantané — les catégories et dates réduisent le fil contre les résultats mis en cache localement d'abord, puis se réconcilie avec le backend en arrière-plan, de sorte que la liste ne clignote jamais en blanc pendant qu'une requête est en cours. Les cartes d'événements portent une étiquette de lieu et un badge « complet » afin que l'utilisateur puisse trier d'un coup d'œil avant d'appuyer.
La page de détail d'événement est là où la découverte se transforme en intention : elle répond aux restrictions d'âge, conditions spéciales, date et heure approximative, coût et lieu, puis condense la décision en une seule action de réservation. Le flux de réservation est transmis au backend Symfony, qui réserve l'inventaire et traite le paiement avant d'émettre le billet. Ces mêmes écrans font partie de l'ingénierie iOS et Android que nous gérons pour les clients américains et européens, les builds iOS et Android étant maintenus en parallèle afin qu'une fonctionnalité atterrisse sur les deux stores dans le même train de publication plutôt que de diverger.
Le client Android est développé en Kotlin et porte la même surface de fonctionnalités qu'iOS : fil, recherche, filtres, détail d'événement, réservation et le billet QR universel. Après une réservation réussie, l'application émet un seul billet scannable — un QR code lié à un ID de billet opaque plus le nom du participant — que l'utilisateur montre au personnel à l'entrée. Le billet s'affiche depuis les données en cache, de sorte qu'il s'affiche même lorsque la connectivité du lieu est mauvaise, et le backend suit l'état d'utilisation afin qu'un billet ne puisse pas être réutilisé une fois scanné.
Le calendrier personnel rassemble les événements réservés de l'utilisateur dans une vue « mes événements », regroupés par date avec des rappels, de sorte que l'application devient le seul endroit pour gérer ce à quoi vous assistez cette semaine. Les intérêts qu'un utilisateur sélectionne lors de l'intégration alimentent à la fois le rail de recommandation et un paramètre de ville (Erevan par défaut) qui cadre le fil. Tout cela est soutenu par la couche de contrôle Symfony dans le cadre de notre pratique de développement logiciel sur mesure, les règles de réservation, d'inventaire et de remboursement étant maintenues côté serveur afin que les deux clients natifs restent légers et cohérents.
Le backend est un service Symfony / PHP qui possède le catalogue d'événements, la logique de réservation et d'inventaire, les flux de paiement et de remboursement, et l'émission et la validation des billets ; un frontend web React partage cette surface API, et les deux clients natifs consomment les mêmes points de terminaison. La localisation est de première classe : le premier écran qu'un utilisateur voit est un sélecteur de langue — arménien, anglais ou russe — et le choix se propage dans le fil, le détail d'événement et le billet. Maintenir les règles de réservation et de remboursement côté serveur signifie que l'application peut changer une politique sans livrer un nouveau binaire dans l'un ou l'autre des stores.
Bien que le produit dessert le marché arménien, nous avons conçu le modèle de données selon les standards de confidentialité qu'attend notre clientèle américaine et européenne. Les données personnelles sont minimisées, les identifiants de billets sont opaques plutôt que liés à un e-mail ou un identifiant de compte en transit, et les chemins de consentement et de suppression sont délimités afin que la même base de code puisse être configurée pour satisfaire les obligations RGPD pour l'Union européenne et les obligations CCPA / CPRA pour les États-Unis lorsque la même ingénierie est réutilisée pour un lancement américain et européen. Cela fait d'une future revue de confidentialité indépendante un exercice de documentation plutôt qu'une refonte architecturale.
Posture de conformité : Conforme RGPD · prêt ISO 27001 · SOC 2 Type II en cours · compatible HIPAA · CCPA reconnu.
Un build Agile en cinq phases qui a conduit Move2Armenia de la spécification produit à la production sur iOS, Android et un backend Symfony, avec le travail de découverte et d'analytique chargé en amont pour réduire les révisions en cours de build.
Clarifier les règles de réservation, la politique de remboursement, le flux de validation des billets et le modèle fil/filtre en amont. Ce passage d'analytique chargé en amont est le meilleur levier pour maintenir le calendrier prévisible pour les parties prenantes américaines et européennes.
Définir le contrat backend Symfony pour le catalogue, la réservation, l'inventaire, le paiement, les remboursements et l'émission des billets ; convenir de l'API partagée que consomment le frontend web React et les deux clients natifs.
Client iOS Swift et client Android Kotlin développés en parallèle — fil, recherche, filtres par catégorie et date, détail d'événement, réservation intégrée, billet QR et le calendrier d'événements personnel.
Localisation arménien, anglais et russe sur toutes les surfaces ; assurance qualité de réservation, paiement, remboursement et validation des billets ; tests d'affichage hors ligne des billets pour le scénario à l'entrée du lieu.
Soumission sur App Store et Google Play, calibration des fiches stores, et une feuille de route de sélection de sièges avec plans de salles, notifications push et profils d'organisateurs enrichis.
La couche de monétisation de Move2Armenia a été conçue pour qu'une seule source de vérité régisse chaque place. Le backend Symfony conserve le catalogue d'événements et le grand livre d'inventaire ; lorsqu'un utilisateur appuie pour réserver, le backend réserve la place, traite le paiement, et seulement alors émet un billet lié à un ID de billet opaque. Comme l'inventaire réside côté serveur, les mêmes règles s'appliquent de façon identique sur le client iOS, le client Android et le frontend web React — il n'existe aucun chemin pour qu'un client survende un événement. Les remboursements passent par le même grand livre : un remboursement libère l'inventaire dans le pool et invalide le billet afin qu'un QR remboursé ne puisse plus être utilisé à l'entrée. L'ensemble du sous-système a été conçu pour l'extension — ajouter la sélection de sièges avec plans de salles, les contingents gérés par les organisateurs ou un modèle de tarification multi-villes est un changement de configuration et de backend plutôt qu'une réécriture des clients mobiles, ce qui est précisément ce qui a maintenu la feuille de route post-lancement peu coûteuse à exécuter et est le schéma que nous réutilisons pour les produits d'événements et de commerce dans notre clientèle américaine et européenne.
Le marché propre de Move2Armenia est l'Arménie — les événements, les lieux et les villes sont locaux à Erevan et au-delà. Notre mission, en revanche, a été conduite selon le standard qu'attendent nos clients américains et européens, et le build a été structuré afin que le même stack puisse alimenter un lancement aux États-Unis ou dans l'Union européenne sans réécriture. Lorsque nous réutilisons cette architecture pour un produit d'événements américain et européen, la version en langue anglaise est prête à desservir les utilisateurs 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, depuis une seule base de code. Les pratiques de traitement des données sont conçues pour s'aligner sur le RGPD pour les utilisateurs européens et sur l'ensemble de lois américaines sur la confidentialité — CCPA / CPRA (Californie), VCDPA (Virginie), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) et Oregon CPA — de sorte que le passage d'un marché à plusieurs est un exercice de configuration, non un exercice architectural.
Comme la logique de réservation et de billetterie est centralisée dans le backend Symfony et que les données personnelles sont minimisées par conception, la conformité régionale se réduit à une divulgation honnête et un consentement par juridiction plutôt qu'au maintien d'un build distinct par région. L'équipe derrière le build travaille sur le fuseau CET avec un chevauchement côte Est US (9h–13h ET) pour les stand-ups, la coordination des soumissions en store et la gestion des incidents — la fenêtre de fuseau horaire qui permet à une équipe produit américaine et une équipe d'ingénierie européenne de partager quatre heures de chevauchement en direct chaque jour. Nous documentons le traitement des données directement par rapport aux obligations RGPD et aux obligations CCPA de Californie afin qu'un déploiement américain et européen parte d'une posture défendable.
La feuille de route active de développement logiciel sur mesure pour Move2Armenia comprend un flux d'inscription affiné, la sélection de sièges pilotée par des plans de salles interactifs, des notifications push pour les événements à venir et recommandés, et des profils de lieux et d'organisateurs plus riches. Sur le plan de la plateforme, une logique de recommandation plus approfondie basée sur le graphe d'intérêts de l'utilisateur et des villes arméniennes supplémentaires sont planifiées, le sous-système de réservation et d'inventaire étant déjà structuré pour les contingents multi-villes et gérés par les organisateurs. La feuille de route d'infrastructure — observabilité, automatisation du déploiement et un chemin vers un déploiement américain et européen du même stack — est intégrée à notre pratique cloud & DevOps afin que le scaling du produit soit un changement opérationnel plutôt qu'une re-architecture.
Si vous planifiez une plateforme d'événements, un produit de réservation ou toute application mobile où le paiement intégré et un billet qui doit fonctionner à l'entrée sont essentiels — pour des audiences aux États-Unis et dans l'UE — nous avons livré ce stack de bout en bout et pouvons réduire sensiblement le délai de développement. Le produit en production est disponible sur move2.am sur iOS et Android, et l'équipe d'ingénierie derrière lui fait partie de YuSMP Group. Nous travaillons au prix fixe pour les MVP bien définis et avec des équipes de développement dédiées pour la livraison continue, avec une journée de travail CET et une fenêtre garantie de chevauchement côte Est US (9h–13h ET) pour les stand-ups, les démonstrations et la gestion des incidents.
Un MVP d'événements et de billetterie couvrant des clients iOS et Android natifs avec un fil d'événements, une recherche, des filtres par catégorie et date, le détail d'événement, la réservation intégrée et l'émission de billets QR coûte généralement entre 90k et 220k USD. L'ajout de la sélection de sièges avec plans de salles, des remboursements, des notifications push, des tableaux de bord d'organisateurs et du support multi-langue porte un produit complet à 250k–500k USD. Les principaux facteurs de coût sont la logique de réservation et d'inventaire, les flux de paiement et de remboursement, et les builds iOS et Android natifs maintenus en parallèle entre les publications.
Une application d'événements et de billetterie réside dans la poche de l'utilisateur à l'entrée du lieu, s'appuyant fortement sur la caméra, le portefeuille, les notifications push et l'affichage hors ligne des billets. iOS natif en Swift et Android natif en Kotlin donnent un accès prévisible à ces capacités de plateforme, un défilement fluide des listes sur les fils d'événements longs, et un rendu QR fiable même sans signal à l'entrée. Un backend React et Symfony partagé maintient la logique métier en un seul endroit tandis que chaque client reste entièrement natif, ce qui est l'équilibre dont Move2Armenia avait besoin pour une clientèle américaine et européenne publiant sur les deux stores.
Un utilisateur ouvre un événement, voit la classification par âge, le programme, le lieu et le prix, puis appuie pour réserver. Le backend Symfony réserve l'inventaire, traite le paiement et émet un billet lié à un ID de billet opaque. Le client mobile rend cet ID sous forme de billet QR universel que l'utilisateur montre à l'entrée, où le personnel le scanne pour valider l'accès. Les billets s'affichent depuis les données en cache afin qu'ils soient visibles même hors ligne, et le backend suit l'état d'utilisation afin qu'un seul billet ne puisse pas être réutilisé une fois scanné.
Un MVP ciblé avec un fil d'événements, une recherche, des filtres, le détail d'événement, la réservation et la billetterie QR sur les deux stores prend généralement 12 à 20 semaines. L'ajout de la sélection de sièges avec plans de salles, des remboursements, des outils d'organisateurs, des notifications push et du support multi-langue ajoute 6 à 12 semaines. Le travail de découverte et d'analytique en amont — clarifier les règles de réservation, la politique de remboursement et le flux de validation des billets avant le début du code — est le meilleur levier pour maintenir le calendrier prévisible et réduire les révisions en cours de build.
Oui. Bien que Move2Armenia dessert le marché arménien, nos pratiques de build ciblent une clientèle américaine et européenne, de sorte que le modèle de données est structuré pour le RGPD dans l'Union européenne et l'ensemble de lois CCPA / CPRA aux États-Unis dès le premier jour. Les données personnelles sont minimisées, les ID de billets sont opaques, et les flux de consentement et de suppression sont délimités afin que la même base de code puisse être configurée par juridiction sans build distinct par région.
Cas connexes
Une plateforme de réservation et de location avec disponibilité, planification et paiement pour une clientèle US & UE.
Voir le cas →
Une application de réservation de loisirs grand public avec réservation de créneaux, paiements et clients iOS et Android natifs.
Voir le cas →
Une application de mobilité avec découverte sur carte, paiement in-app et état véhicule en temps réel sur US & UE.
Voir le cas →
Applications iOS, Android et multiplateformes natives avec pipelines prêts pour les stores.
Explorer le développement d'applications mobiles →
Plateformes sur mesure conçues pour votre modèle d'entreprise, du MVP à des millions d'utilisateurs.
Explorer le développement de logiciels sur mesure →
Automatisation du déploiement, observabilité et infrastructure scalable pour les produits grand public.
Explorer Cloud & DevOps →Partagez quelques détails et un consultant senior vous répondra dans un jour ouvrable.