Étude de cas · Micromobilité · Mobile & IoT
Comment nous avons construit une plateforme complète de location de trottinettes électriques — des applications conductrices natives iOS et Android, un plan de contrôle télématique IoT, du géofençage et un tableau de bord opérationnel — pour un opérateur de micromobilité qui possédait les trottinettes et les permis municipaux mais avait besoin du logiciel. Le produit sert désormais plus de 5 000 utilisateurs satisfaits aux États-Unis et dans l'UE.
Le client était un opérateur de micromobilité disposant de véritables actifs — une flotte de trottinettes électriques et les permis municipaux pour les exploiter — mais sans capacité interne pour la télématique complexe et l'ingénierie mobile dont dépend réellement une activité de partage de trottinettes. Posséder le matériel ne représente que la moitié du modèle économique ; l'autre moitié est le logiciel qui transforme une trottinette garée en un actif découvrable, déverrouillable, traçable et facturable pour les conducteurs aux États-Unis et dans l'Union européenne. Le brief portait sur une plateforme informatique complète : applications conductrices natives pour iOS et Android, un tableau de bord d'administration pour gérer la flotte, la tarification et les zones d'exploitation, et — la partie qui fait ou défait un produit de micromobilité — une couche de communication fiable entre l'application et les contrôleurs des trottinettes pour le verrouillage, le déverrouillage et le contrôle de vitesse à distance. Nous l'avons construit depuis les principes fondamentaux avec YuSMP Group, en commençant par une analyse matérielle concrète d'un prototype physique de trottinette plutôt que de simples fiches techniques fournisseur, et avons livré un produit qui sert désormais plus de 5 000 utilisateurs sur l'App Store et Google Play.
Un aperçu de ce que le build de partage de trottinettes a permis de réaliser sur iOS, Android et un plan de contrôle télématique IoT au cours de son premier cycle de production.
La décision architecturale qui domine un build de micromobilité est la manière dont le téléphone du conducteur atteint la trottinette. Nous avons délibérément choisi un modèle télématique relayé par serveur — l'application ne commande jamais directement le contrôleur — plutôt qu'un chemin de contrôle direct appareil-à-téléphone. Lorsqu'un conducteur scanne un QR code, l'application envoie un intent au backend ; le backend authentifie le trajet, vérifie le solde du portefeuille et les règles de zone, puis relaie une commande signée via le canal télématique cellulaire vers le contrôleur sur la trottinette. Le contrôleur accuse réception, et c'est seulement alors que l'application change l'état du trajet. Cette indirection est ce qui rend la plateforme sûre pour la facturation : chaque action de déverrouillage, de verrouillage et de géofençage est un événement côté serveur avec une piste d'audit, et non un message Bluetooth envoyé et oublié qui peut être falsifié ou perdu sans trace. La même discipline du plan de contrôle se retrouve dans notre pratique de développement logiciel sur mesure pour les produits de mobilité.
Nous avons cartographié le protocole requête-réponse du contrôleur de la manière difficile : une équipe pluridisciplinaire — un analyste métier, un architecte systèmes et un directeur backend — a travaillé à partir d'un prototype physique de trottinette, et pas seulement d'une fiche technique contrôleur, et a produit des diagrammes de séquence détaillés couvrant chaque interaction conducteur. La comparaison ci-dessous résume pourquoi le modèle de relais a gagné pour une flotte qui doit satisfaire les régulateurs municipaux américains et européens.
| Dimension | Relais serveur (ce build) | Bluetooth direct | SDK marque blanche |
|---|---|---|---|
| Piste d'audit des commandes | Chaque action est un événement serveur journalisé | Local uniquement — difficile à réconcilier avec la facturation | Contrôlé par le vendeur, souvent opaque |
| Portée vers la trottinette | N'importe où avec réseau cellulaire — aucune proximité requise | Le téléphone doit être à côté de la trottinette | Varie selon le vendeur |
| Application du géofençage | Le serveur pousse vitesse/arrêt lors du franchissement de limite | Requiert l'app en premier plan & proximité | Inclus mais non personnalisable |
| Sécurité en cas de perte de signal | File de commandes + protocole d'accusé de réception | Échec silencieux — le conducteur peut être mal facturé | Dépend de l'implémentation du SDK |
| Intégrité de la facturation | Facturer uniquement sur déverrouillage/verrouillage confirmé | Difficile à garantir | Défini par le vendeur |
| Observabilité de la flotte | Tableau de bord admin central, carte en temps réel | Pas de vue centrale | Portail vendeur — limité |
| Personnalisation & propriété | Source complète — propriété de l'opérateur | Côté app uniquement | Licencié, risque de verrouillage |
Références de la plateforme : Documentation Apple Core Location, Référence des services de localisation Android.
Le client iOS est développé en Swift avec un flux d'un seul écran pour débuter un trajet : une carte en direct des trottinettes à proximité, un point d'entrée scan-QR et une fiche de détail de la trottinette affichant la batterie, l'autonomie estimée, les frais de démarrage et le prix par minute avant que le conducteur ne s'engage. La couche cartographique utilise Core Location d'Apple pour la position du conducteur et diffuse en streaming les positions GPS des trottinettes depuis le backend, de sorte que le sélecteur reflète la flotte réelle sans bloquer sur un aller-retour réseau lent. Le chemin de déverrouillage QR est là où la plupart des conducteurs forment leur première impression du produit, et là où nous avons consacré un effort d'ingénierie disproportionné : scanner, valider l'éligibilité du portefeuille et de la zone, envoyer l'intent de déverrouillage, et afficher clairement l'état de trajet démarré au moment où le contrôleur accuse réception.
Comme l'accusé de réception du contrôleur peut prendre du retard sur un réseau cellulaire faible, le flux iOS est construit autour d'états de trajet explicites — au repos, déverrouillage, trajet démarré, en cours de fin — plutôt qu'une UI optimiste qui prétend que la trottinette est déverrouillée avant confirmation. Un conducteur n'est jamais placé dans un trajet facturable tant que le backend n'a pas reçu un déverrouillage confirmé du contrôleur, ce qui est la propriété de correction la plus importante dans une application de trottinettes. La surface iOS de bout en bout est livrée dans le cadre de notre pratique de développement d'applications mobiles.
Le client Android est développé en Kotlin et exécute le trajet actif dans un service au premier plan. Ce service est obligatoire : sur les familles de terminaux Samsung, Xiaomi, OnePlus et Pixel, les optimiseurs de batterie agressifs terminent les processus en arrière-plan uniquement en quelques minutes, et un trajet en trottinette ne peut pas se permettre de perdre sa connexion à la logique de comptage et de géofençage en cours de route. Le service maintient la session de trajet en vie, diffuse en streaming la position GPS du conducteur vers le backend pour le suivi de la flotte et les vérifications de géofence, et met à jour la distance en direct, le temps écoulé et le prix courant à l'écran tout en exposant un contrôle de verrouillage en cours de trajet.
La logique de géofençage est le cœur réglementaire de la plateforme. Pendant que le conducteur se déplace, le backend compare la position GPS de la trottinette avec les polygones de zones d'exploitation configurés dans le tableau de bord d'administration. Le franchissement d'une zone lente pousse une commande de limitation de vitesse vers le contrôleur ; le franchissement d'une limite stricte arrête la trottinette ; l'atteinte d'une zone de stationnement active la fin du trajet. Cette application côté serveur est ce qui permet à une ville américaine ou européenne d'homologuer la flotte, et elle fonctionne sur le même plan de contrôle qui gère la référence de streaming de localisation décrite dans les services de localisation Android. La même équipe d'ingénierie assure iOS et Android en parallèle dans le cadre de notre pratique d'ingénierie iOS et Android.
Le portefeuille intégré permet à un conducteur de précharger un solde et de définir un plafond de dépenses, de sorte qu'un seul état de paiement de qualité abonnement se résout proprement sur les trajets sans réautoriser une carte à chaque voyage. En dessous réside le plan de contrôle télématique — un backend qui détient la carte de la flotte, les polygones de zones d'exploitation, la file de commandes par trottinette et le grand livre de facturation. La file de commandes est la couche de sécurité : si une commande de verrouillage ou de déverrouillage est envoyée et que le contrôleur ne l'accuse pas réception — perte de signal cellulaire, batterie épuisée, redémarrage du contrôleur — la file effectue de nouvelles tentatives avec backoff et réconcilie l'état du trajet afin qu'un conducteur ne soit jamais facturé pour une trottinette qui n'a pas répondu. Les identifiants sont limités strictement : le flux de localisation du conducteur alimente les vérifications de géofence et le suivi de la flotte, et est conservé comme historique de trajet sous consentement explicite et adapté à la région, plutôt qu'exploité comme profil de suivi continu.
Le traitement des données est conçu pour s'aligner sur les obligations du RGPD pour les conducteurs dans l'Union européenne et les obligations du CCPA / CPRA pour les conducteurs en Californie et dans l'ensemble des États-Unis — les données de localisation sont collectées pour l'objectif opérationnel du trajet et du géofençage, divulguées clairement et non réutilisées. La console opérationnelle de flotte, construite avec React, offre au personnel une carte en temps réel, un éditeur de zones, des contrôles de tarification et la santé télématique par trottinette.
Posture de conformité : Conforme RGPD · prêt ISO 27001 · SOC 2 Type II en cours · compatible HIPAA · CCPA reconnu.
Un build en cinq phases qui a conduit la plateforme d'un prototype physique de trottinette à la production sur iOS, Android et un plan de contrôle télématique IoT.
Analyse concrète d'un prototype physique de trottinette, cartographie du protocole requête-réponse du contrôleur, diagrammes de séquence d'interaction conducteur, exigences de permis municipaux et de géofençage US + UE, cartographie de posture RGPD + CCPA.
Squelette backend Laravel, modèle de commande relayée par serveur, file de commandes de sécurité avec accusé de réception et backoff, carte de la flotte, modèle de polygone de zone d'exploitation, grand livre de facturation.
Application conductrice iOS Swift et application conductrice Android Kotlin — carte GPS en direct, déverrouillage QR, états de trajet, comptage de trajet en service au premier plan, portefeuille intégré et plafond de dépenses.
Application du géofençage avec limitation automatique de vitesse et zones d'arrêt, QA de sécurité perte de signal et batterie faible, tests d'intégrité de facturation, tableau de bord opérationnel React admin.
Soumission App Store + Google Play sur les storefronts américains et européens, déploiement de la flotte, observabilité de la flotte en temps réel et télémétrie au niveau du trajet pour l'ajustement tarifaire et des zones.
Une activité de partage de trottinettes vit ou meurt par sa console opérationnelle, c'est pourquoi le tableau de bord d'administration React a été traité comme un livrable de premier ordre plutôt qu'une réflexion après coup. Le personnel dispose d'une carte en temps réel de chaque trottinette avec son niveau de batterie, son état de verrouillage et sa santé télématique, et peut dépêcher des opérations terrain pour les échanges de batterie faible ou les relocalisations. La tarification est entièrement configurable — frais de démarrage, tarif par minute et ajustements selon l'heure ou la zone — sans publication de code, car la tarification de la micromobilité est constamment ajustée selon la demande et les accords municipaux. L'éditeur de zones est l'outil réglementaire : le personnel dessine et édite les zones sans trajet, les zones lentes et les zones de stationnement sous forme de polygones cartographiques, et ces polygones alimentent directement le moteur de géofençage qui les applique sur les trottinettes en temps réel. Étant donné que les zones d'exploitation, la tarification et l'inventaire de la flotte résident tous derrière le même plan de contrôle, un opérateur peut intégrer une nouvelle ville américaine ou européenne comme un exercice de configuration — nouveaux polygones, nouvelle tarification, nouveaux paramètres de permis — plutôt qu'un fork de code, ce qui est précisément l'effet de levier qu'une plateforme logicielle est censée apporter à une entreprise matérielle.
La plateforme a été lancée sur l'App Store d'Apple et Google Play avec des storefronts actifs aux États-Unis et dans l'Union européenne, et sert désormais plus de 5 000 utilisateurs sur un seul build en langue anglaise par plateforme. La micromobilité est l'une des catégories logicielles les plus réglementées localement qui soit, c'est pourquoi l'architecture pousse les règles spécifiques à chaque ville dans la configuration : chaque zone d'exploitation, limite de vitesse et contrainte de stationnement est une donnée dans le tableau de bord d'administration, et non une base de code par ville. Les flux de consentement sont adaptés par région au niveau du client — les conducteurs dans l'UE et l'EEE reçoivent un écran de consentement granulaire de type RGPD couvrant le traitement de la localisation du trajet, et les conducteurs en Californie reçoivent une divulgation de type CCPA « Ne pas vendre ou 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 confidentialité des États américains — CCPA/CPRA (Californie), VCDPA (Virginie), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) et Oregon CPA — les données de localisation du trajet étant limitées à l'objectif opérationnel du voyage et du géofençage.
Côté européen, la plateforme est structurée pour supporter le déploiement dans les villes des Pays-Bas, d'Allemagne, de France, de Suède et d'Irlande, où les permis de trottinettes partagées reposent sur la démonstration du géofençage et du contrôle de vitesse — précisément la capacité autour de laquelle le plan de contrôle a été construit. L'équipe d'ingénierie derrière ce build travaille en journée CET avec un chevauchement côte Est des États-Unis (9h–13h ET) pour les stand-ups, la chorégraphie des révisions de stores et la réponse aux incidents, la fenêtre qui permet à une équipe produit orientée États-Unis et à une équipe d'ingénierie européenne de partager quatre heures de chevauchement en direct chaque jour. La classification d'âge App Store et la classification de contenu Google Play ont toutes deux été calibrées pour une application de transport gérant la localisation en direct.
La feuille de route active de développement logiciel sur mesure comprend une tarification dynamique basée sur la demande, une vérification de fin de trajet avec photo pour les dommages, un palier de récompenses conducteur et une analytique de santé de la flotte plus approfondie qui signale les trottinettes s'orientant vers la maintenance avant qu'elles ne tombent en panne sur le terrain. Les plans d'infrastructure incluent une automatisation plus poussée du pipeline de commandes télématiques et un plan de contrôle durci et observable intégré à la feuille de route cloud & DevOps, afin que l'opérateur puisse ajouter des villes américaines et européennes sans réarchitecturer. La plateforme sert le domaine plus large de la logistique et mobilité, où les mêmes schémas de suivi GPS et de contrôle IoT se retrouvent dans les véhicules partagés et les flottes du dernier kilomètre.
Si vous planifiez un produit de trottinette électrique ou de mobilité partagée où le logiciel doit transformer une flotte matérielle en un service facturable et conforme aux réglementations pour des audiences aux États-Unis et en UE, nous avons livré ce stack de bout en bout — applications conductrices, plan de contrôle télématique, géofençage et tableau de bord opérationnel — et pouvons réduire significativement le délai de build. Le cas est documenté sur yusmpgroup.ru, et l'équipe d'ingénierie derrière ce projet est au sein d'YuSMP Group. Nous travaillons à prix fixe pour les MVP bien cadrés et sur 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 des États-Unis (9h–13h ET) pour les stand-ups, démonstrations et réponses aux incidents.
Un MVP de micromobilité couvrant les applications conductrices iOS et Android, une carte GPS des trottinettes, le déverrouillage QR, le comptage de trajet et un tableau de bord d'administration de base coûte généralement entre 140 000 € et 280 000 €. L'ajout d'un plan de contrôle télématique IoT complet, du géofençage avec limitation automatique de vitesse, de la gestion de sécurité des verrouillages, d'un portefeuille intégré et d'une tarification dynamique porte une plateforme complète à 320 000 €–700 000 €. Les principaux postes de coût sont la couche de communication avec le contrôleur de la trottinette, le moteur de géofençage et le tableau de bord opérationnel pour la gestion de la flotte, de la tarification et des zones.
L'application conductrice ne communique jamais directement avec la trottinette. Un scan QR ou un tap envoie un intent au backend, qui relaie une commande signée de verrouillage ou déverrouillage via le canal télématique vers le contrôleur sur la trottinette. Le contrôleur accuse réception, et l'application met à jour l'état du trajet. La partie difficile est le chemin de sécurité : la file de commandes doit gérer la perte de signal cellulaire, la batterie faible et les accusés de réception partiels afin qu'un conducteur ne soit jamais facturé pour une trottinette qui ne s'est pas réellement déverrouillée.
Le géofençage définit des limites virtuelles sur la carte — zones sans trajet, zones lentes et zones de stationnement. Lorsque la position GPS d'une trottinette franchit une limite, la plateforme envoie au contrôleur une commande de réduction de vitesse ou d'arrêt. C'est une exigence fondamentale de sécurité urbaine et réglementaire : la plupart des villes américaines et européennes autorisent les trottinettes partagées à condition que les opérateurs puissent appliquer les limites de vitesse et maintenir les trottinettes hors des zones piétonnes, donc le moteur de géofençage n'est pas optionnel, c'est le permis lui-même.
Un MVP ciblé avec une carte GPS des trottinettes, le déverrouillage QR, le comptage de trajet, un portefeuille intégré et les soumissions aux deux stores prend généralement 16 à 22 semaines. L'ajout du plan de contrôle télématique IoT complet, du géofençage avec limitation automatique de vitesse, de la gestion de sécurité des verrouillages et du tableau de bord opérationnel ajoute 8 à 12 semaines. La découverte d'intégration matérielle — travailler avec un prototype physique de trottinette pour cartographier le protocole requête-réponse du contrôleur — est fréquemment sous-estimée et devrait être budgétée comme une phase distincte.
Posséder le matériel et les permis municipaux représente une moitié de l'activité ; l'autre moitié est le logiciel qui transforme une trottinette garée en un actif louable, traçable et facturable. La télématique complexe, le suivi GPS de la flotte, le géofençage et un portefeuille de trajet de qualité paiement sont des domaines d'ingénierie spécialisés. Une équipe qui a livré ce stack pour iOS et Android peut cartographier le protocole du contrôleur à partir d'un prototype physique, construire la couche de commande de sécurité et déployer la plateforme d'administration bien plus rapidement que de développer cette capacité en interne à partir de zéro.
Cas connexes
Plateforme de réservation iOS + Android native avec disponibilité en direct et découverte géo-consciente sur US & UE.
Voir le cas →
Plateforme mobile grand public avec cartes, services de géolocalisation et build multilingue pour utilisateurs internationaux.
Voir le cas →
Marketplace de location avec flux de réservation, paiements et back-office opérations 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 →
Plans de contrôle robustes et observables et infrastructure Terraform évoluant sur les régions US et UE.
Explorer Cloud & DevOps →Partagez quelques détails et un consultant senior vous répondra dans un jour ouvrable.