Étude de cas · Logistique · Dernier kilomètre · Mobile
Comment nous avons pris en charge une application Android legacy en état critique — en production chez un opérateur logistique allemand et saignant des revenus sur des livraisons échouées — l'avons stabilisée, refactorisé son cœur de routage, puis livré une contrepartie iOS prête à publier. Optimisation d'itinéraires multipoints, suivi de conducteur en temps réel, facturation et paiements intégrés, livrés pour des flottes en production en Allemagne et prêts à s'étendre dans l'Union européenne et aux États-Unis.
xRouten est un produit de navigation et de planification d'itinéraires pour les flottes d'entreprises, construit et opéré depuis l'Allemagne. Lorsque le client a engagé YuSMP, l'application Android existante était en production chez des opérateurs logistiques payants mais souffrait de faibles performances, d'erreurs fréquentes et de bugs critiques qui perturbaient directement les opérations commerciales — livraisons échouées, fenêtres de ramassage manquées et pertes financières réelles pour les clients finaux de l'opérateur. L'équipe produit avait besoin de deux choses dans un seul engagement : premièrement, un passage de stabilisation d'urgence sur l'application Android en production pour stopper l'attrition des utilisateurs et rétablir la confiance ; deuxièmement, une contrepartie iOS avec pleine parité des fonctionnalités afin que l'opérateur puisse étendre sa flotte de conducteurs sur le matériel iPhone. Nous avons pris en charge les deux — refactorisation legacy de la base de code Android instable en Kotlin, suivie d'une construction iOS de zéro en Swift partageant le même backend — et livré un produit prêt à publier pour les deux Google Play et l'App Store Apple, en production chez un opérateur logistique allemand et prêt à s'étendre sur les marchés plus larges de l'Union européenne et des États-Unis.
Un instantané de ce que l'engagement xRouten a livré sur la refonte Android et la nouvelle construction iOS.
La surface la plus critique pour l'activité dans xRouten est le constructeur d'itinéraires. Un répartiteur ou un conducteur fournit à l'application une liste d'arrêts — parfois quelques-uns, souvent des dizaines — et l'application doit retourner une séquence optimisée dans un délai suffisamment court pour paraître instantané. Dans la construction legacy, ce calcul était peu fiable : les itinéraires échouaient à se calculer, dépassaient les délais ou retournaient des séquences manifestement sous-optimales qui gaspillaient des heures de conducteur et brûlaient du carburant. Nous avons réécrit le cœur de routage contre une API matricielle de SDK de cartographie : le client soumet la liste des arrêts à un optimiseur côté serveur qui récupère la distance et l'ETA par paire, exécute une heuristique 2-opt sur la matrice résultante et retourne une séquence d'arrêts quasi-optimale avec des directions étape par étape pour chaque tronçon.
Le client mobile affiche l'itinéraire, prend en charge la re-optimisation incrémentale lorsque des arrêts sont ajoutés en cours de quart ou marqués comme complétés, et met en cache la matrice par itinéraire de sorte qu'une seule livraison terminée ne déclenche pas un recalcul complet. Le résultat est un constructeur d'itinéraires qui retourne un calcul instantané des chemins optimaux entre des dizaines d'arrêts — exactement le comportement orienté utilisateur que le client avait demandé depuis le début de la relation. La même architecture est réutilisée dans la construction iOS sans modifications du backend : l'optimiseur est agnostique à la plateforme et les clients mobiles sont de simples afficheurs sur une stack de développement de logiciels sur mesure partagée.
| Dimension | Construction legacy (avant l'engagement) | Construction refactorisée (après l'engagement) |
|---|---|---|
| Calcul d'itinéraires multipoints | Délais dépassés et séquences manifestement sous-optimales | Calcul instantané contre une API matricielle + solveur 2-opt |
| Suivi de localisation conducteur | Mises à jour sporadiques, marqueurs de carte saccadés | Diffusion en temps réel fluide avec échantillonnage adaptatif |
| Facture & paiement | Contournement hors appli — les conducteurs utilisaient des outils externes | Génération de factures intégrée + système de paiement fonctionnel |
| Erreurs critiques en production | Multiples — entraînant des livraisons échouées et des pertes de revenus | Éliminées lors de la refonte |
| Interface & perception de marque | Dépassée ; plaintes des utilisateurs visibles dans les avis du store | Interface moderne redessinée améliorant l'UX |
| Disponibilité iOS | Aucune — Android uniquement | Construction Swift prête à publier avec parité des fonctionnalités |
Références de plateformes : Kotlin, Swift, Services de premier plan Android, Apple CoreLocation.
La deuxième fonctionnalité principale était la diffusion fiable de localisation en temps réel pour les conducteurs de l'opérateur, rendue fluidement sur une carte répartiteur sans les saccades et les lacunes qui affectaient la construction legacy. Sur Android, nous nous appuyons sur un service de premier plan Kotlin pour maintenir l'échantillonnage GPS actif en mode Doze et les optimiseurs de batterie agressifs livrés par les familles d'appareils Samsung, Xiaomi, OnePlus et Pixel — sans cela, les mises à jour de localisation s'arrêtent en quelques minutes après l'extinction de l'écran. Sur iOS, la surface équivalente utilise CoreLocation avec l'autorisation de localisation en arrière-plan appropriée, couplée à une surveillance des changements significatifs comme solution de repli économe en énergie.
L'échantillonnage est adaptatif : à faible vitesse dans la circulation urbaine dense, les coordonnées du conducteur sont mises à jour toutes les cinq à dix secondes ; sur l'autoroute entre les villes allemandes, la fréquence d'échantillonnage s'allonge, car le répartiteur n'a pas besoin d'une précision de 1 Hz lorsqu'un véhicule se déplace en ligne droite à 120 km/h. La vue répartiteur interpole entre les échantillons pour que le marqueur glisse plutôt que de sauter, ce qui donne l'impression d'une fréquence d'échantillonnage grossière fluide pour l'opérateur. Les mises à jour de localisation sont diffusées via un WebSocket persistant — le même choix de transport utilisé pour le chat dans notre travail de développement d'applications mobiles grand public — de sorte qu'une brève coupure de connectivité (basculement opérateur entre LTE et 5G, courant sur les itinéraires longue distance allemands) se rétablit en moins de deux secondes sans perdre la dernière position connue.
Le troisième pilier de la refonte était un module de documentation numérique : au point de livraison, le conducteur génère une facture pour le client directement depuis l'application, l'envoie depuis le même écran et encaisse le paiement sans quitter le flux de travail. Dans le produit legacy, les conducteurs avaient improvisé autour de cette lacune en utilisant du papier ou des applications sans rapport — une piste de documentation qui brisait les attentes de conformité allemandes et ralentissait chaque livraison. Le nouveau module produit une facture structurée (PDF pour le client, données structurées pour le back-office de l'opérateur), joint la preuve de livraison et route le paiement via une passerelle de paiement intégrée — pas l'achat intégré de l'App Store, qu'Apple exclut explicitement pour les biens et services physiques.
La fiabilité provient d'un double commit entre l'émission de la facture et l'intention de paiement : une coupure réseau sur le terrain ne peut pas résulter en un débit sans une facture correspondante, et ne peut pas résulter en une facture sans un résultat de paiement enregistré. Le flux accepte une capture réussie, une capture différée (le conducteur est dans un sous-sol et hors ligne — la facture est mise en file d'attente pour synchronisation à la prochaine connexion) et un échec sévère (carte refusée — le conducteur voit une erreur en ligne et peut prendre un paiement alternatif dans le même écran). Le résultat est le système de paiement fonctionnel que le client avait demandé depuis le début, avec une fiabilité des transactions qui correspond à ce que les clients de l'opérateur attendent de tout service moderne de livraison du dernier kilomètre en Allemagne.
Posture de conformité : Aligné RGPD · Prêt ISO 27001 · SOC 2 Type II en cours · Compatible HIPAA · CCPA reconnu.
Trois caractéristiques du projet ont rendu xRouten un engagement non trivial et ont façonné notre façon de gérer le travail. Premièrement, la base de code était un produit legacy avec une surface existante instable — nous ne construisions pas sur un espace vide, nous stabilisions un système en cours d'exécution dont de vrais conducteurs dépendaient. Cela signifiait que chaque changement devait être défendable vis-à-vis de la base d'utilisateurs existante : refactoriser par couches, contrôler les nouveaux chemins de code derrière des drapeaux de fonctionnalités, livrer des releases intermédiaires qui retiraient progressivement les pires classes de bugs plutôt qu'une réécriture totale qui aurait laissé les opérateurs sur une construction cassée pendant des semaines.
Deuxièmement, les enjeux étaient élevés d'une façon que les applications grand public ont rarement : une erreur d'application ne produisait pas une mauvaise expérience utilisateur, elle produisait une livraison échouée et une perte financière réelle pour le client final de l'opérateur. Cette asymétrie nous a poussés vers une ingénierie défensive — états d'erreur explicites exposés au conducteur, nouvelles tentatives avec recul exponentiel pour toute opération réseau qui mutait l'état, et comportement hors ligne en priorité pour les surfaces sur le terrain afin qu'une coupure de connectivité ne perde jamais silencieusement du travail.
Troisièmement, il y avait des barrières linguistiques et géographiques : l'intégralité de l'interface du produit et de la documentation est en allemand, et la validation de la couche de routage nécessitait des tests sur des cartes et des conventions d'adresses allemandes par une équipe d'ingénierie basée en Russie. Nous avons traité cela comme une discipline d'ingénierie plutôt que comme un problème — révision par des locuteurs germanophones de chaque chaîne de l'interface utilisateur, fixtures d'adresses allemandes dans la suite de tests de routage, et une matrice d'assurance qualité qui testait l'application par rapport aux vrais schémas de ramassage Deutsche Post et DHL plutôt que des données de test synthétiques. Cette discipline est la même que nous appliquons lorsque nous gérons une équipe de développement dédiée pour tout client US ou UE où le marché opérationnel n'est pas la première langue de l'équipe d'ingénierie.
Un engagement en cinq phases qui a emmené xRouten d'une application Android en production instable à une paire iOS et Android prête à publier.
Audit de la base de code Android legacy, inventaire des bugs critiques, priorisation par impact sur l'activité (livraisons échouées en premier), releases de correctifs urgents pour stopper l'attrition des utilisateurs pendant que la refonte plus profonde est délimitée.
Réécriture du constructeur d'itinéraires multipoints en Kotlin contre une API matricielle de SDK de cartographie avec une heuristique 2-opt, suite de régression sur des fixtures d'adresses allemandes réelles, déploiement progressif derrière un drapeau de fonctionnalité.
Diffusion de localisation en temps réel basée sur un service de premier plan, interpolation fluide côté répartiteur, générateur de factures intégré et intégration de passerelle de paiement avec sémantique de double commit.
Interface moderne redessinée appliquée aux deux plateformes, client iOS Swift construit contre le même backend avec parité des fonctionnalités pour le routage, le suivi, la facturation et les paiements.
Release Google Play en production pour l'application Android refactorisée, construction iOS prête à publier pour soumission à l'App Store, passage d'assurance qualité en langue allemande, runbook et transfert de permanence au client.
À la fin de l'engagement, le produit xRouten était passé d'une application Android instable générant des escalades de support à une release prête pour la production pour l'App Store et Google Play. Les erreurs critiques qui entraînaient des livraisons échouées dans la version legacy ont été éliminées ; l'interface moderne redessinée a amélioré à la fois l'expérience utilisateur et la perception de marque pour les conducteurs et clients de l'opérateur ; le système de paiement intégré a livré une fiabilité des transactions que la construction précédente n'offrait tout simplement pas ; et l'architecture refactorisée est structurée de sorte que l'équipe produit de l'opérateur peut ajouter de nouvelles fonctionnalités — méthodes de paiement supplémentaires, analytique au niveau de la flotte, support multi-locataires pour les sous-traitants — sans hériter de la dette technique de la construction originale. Le même backend partagé sert à la fois la refonte Android et la nouvelle construction iOS, de sorte qu'une seule feuille de route produit pilote les deux plateformes à l'avenir.
xRouten est en production chez un opérateur logistique allemand du dernier kilomètre et construit sur la même posture d'ingénierie que nous utilisons dans l'ensemble de notre travail pour les clients aux États-Unis et dans l'Union européenne. L'application est aujourd'hui allemande en priorité — interface allemande, documentation en langue allemande, validée contre des adresses, réseaux routiers et schémas de livraison allemands — mais l'architecture est agnostique à la région. L'abstraction du SDK de cartographie prend en charge les réseaux de rues et les formats d'adresses américains sans modifications de code, l'intégration de la passerelle de paiement peut échanger des processeurs régionaux par marché, et les stacks de service de premier plan et CoreLocation se comportent identiquement sur les appareils émis aux États-Unis et dans l'UE.
La posture de confidentialité reflète le reste de notre portefeuille : l'application est alignée avec le RGPD pour les utilisateurs européens — pertinent immédiatement en Allemagne, France, Pays-Bas, Irlande et Suède — et prête à répondre au patchwork de confidentialité des États américains : CCPA / CPRA en Californie, VCDPA en Virginie, CPA au Colorado, CTDPA au Connecticut, UCPA en Utah, TDPSA au Texas et Oregon CPA. Les données de localisation des conducteurs sont la surface la plus sensible dans une application logistique — ce sont, par définition, des données de surveillance des employés — et l'architecture sépare les flux de localisation de l'identité au niveau de la couche de stockage, avec des fenêtres de rétention configurables par opérateur pour correspondre aux attentes du Comité d'entreprise allemand qui régit cette catégorie de données dans l'UE.
La feuille de route pour xRouten étend la fondation refactorisée dans des directions que l'opérateur ne pouvait pas tenter en toute sécurité sur la construction legacy : analytique au niveau de la flotte (productivité des conducteurs, coût d'itinéraire par livraison, variance carburant et temps par rapport au plan optimisé), support multi-locataires afin que les coursiers sous-contractés puissent gérer leurs propres pools de conducteurs dans le compte de l'opérateur, méthodes de paiement régionales supplémentaires (prélèvement SEPA, Klarna, Apple Pay et Google Pay) et une console web côté répartiteur qui reflète le modèle de données de l'application mobile. Les plans d'infrastructure incluent un SLO plus strict sur l'optimiseur de routage (réponse inférieure à la seconde pour les itinéraires jusqu'à 50 arrêts) et des engagements de résidence des données UE soutenus par des partitions de base de données fixées par région pour correspondre aux attentes de confidentialité de l'opérateur allemand en vertu du RGPD.
Un passage de stabilisation legacy ciblé sur une application Android — élimination des erreurs critiques, refactorisation du cœur de routage et livraison d'une version prête pour la production — coûte généralement entre 80 k€ et 180 k€ selon la taille de la base de code et la couverture des tests. La construction d'une contrepartie iOS avec parité des fonctionnalités (routage multipoint, suivi en temps réel, facturation, paiements) par-dessus un backend partagé ajoute généralement 120 k€–250 k€. Les facteurs de coût incluent le choix du SDK de cartographie, les intégrations de passerelle de paiement et l'effort d'assurance qualité nécessaire pour valider l'optimisation des itinéraires par rapport aux adresses et données de trafic allemandes réels.
L'optimisation d'itinéraires multipoints sur mobile est une variante du problème du voyageur de commerce. Pour les flottes d'entreprises avec des dizaines d'arrêts par itinéraire, le calcul s'exécute côté serveur contre l'API matricielle d'un fournisseur de cartographie (distance et ETA entre chaque paire d'arrêts), avec un solveur heuristique — typiquement une variante 2-opt ou Lin-Kernighan — trouvant une séquence quasi-optimale en quelques millisecondes. Le client mobile affiche le résultat et gère la re-optimisation incrémentale lorsque des arrêts sont ajoutés, supprimés ou complétés sur le terrain. La mise en cache de la matrice par itinéraire et la ré-interrogation uniquement des paires modifiées maintient des temps de réponse faibles même lorsque les conducteurs avancent dans leurs livraisons.
Le suivi de conducteur en temps réel en production comporte trois éléments mouvants : un service de premier plan sur Android (et une autorisation de localisation en arrière-plan sur iOS) qui maintient l'échantillonnage GPS actif en mode Doze et les optimiseurs de batterie ; une couche de transport — WebSocket ou MQTT — qui diffuse les mises à jour de localisation vers un backend avec une latence inférieure à la seconde ; et une vue répartiteur qui interpole entre les échantillons pour afficher un mouvement fluide sur une carte sans saccades. La batterie est la contrainte dominante : l'échantillonnage à 1 Hz vide rapidement un téléphone, donc une vraie construction échantillonne de façon adaptative à intervalles de 5 à 30 secondes selon la vitesse et la géométrie de l'itinéraire.
La facturation intégrée pour un flux de travail logistique génère un document de facture structuré (PDF ou données conformes au style XRechnung allemand) au point de livraison, joint la signature du conducteur et la preuve de livraison, et l'envoie au client par e-mail ou lien intégré. Le paiement est généralement géré par une passerelle de paiement séparée (Stripe, Adyen ou un processeur du marché allemand) plutôt que par l'achat intégré de l'App Store, car les biens payés sont des livraisons physiques, pas du contenu numérique — les règles IAP de l'App Store excluent explicitement cette catégorie. La fiabilité provient d'un double commit entre l'émission de la facture et l'intention de paiement, de sorte qu'une coupure réseau sur le terrain ne peut pas créer un débit sans un enregistrement de facture correspondant.
Un passage de stabilisation Android legacy — audit des bugs critiques, refactorisation du cœur de routage et livraison d'une version corrigée sur Google Play — prend généralement 10 à 16 semaines pour une application de la taille de xRouten. La construction de la contrepartie iOS avec pleine parité des fonctionnalités, y compris les flux de facturation et de paiement, ajoute 14 à 20 semaines. Les principaux risques de calendrier sont l'alignement des licences du SDK de cartographie, l'assurance qualité du marché allemand (test des itinéraires par rapport aux vrais schémas de ramassage Deutsche Post et DHL) et les cycles de révision App Store / Google Play lorsqu'une application auparavant instable re-entre dans le store avec des autorisations substantiellement modifiées.
Si vous opérez un produit logistique du dernier kilomètre ou de flotte — n'importe où aux États-Unis, dans l'Union européenne ou sur un marché comme l'Allemagne où la conformité et les nuances linguistiques comptent — et que vous réfléchissez à une refonte legacy, une extension iOS ou Android, ou une nouvelle construction, nous avons livré cette stack de bout en bout pour un opérateur allemand en production et pouvons réduire significativement le délai de construction. L'équipe d'ingénierie derrière xRouten se trouve dans YuSMP Group. Nous travaillons à prix fixe pour les refontes bien spécifiées et sur des équipes de développement dédiées pour la livraison continue, avec une journée CET et une fenêtre garantie de chevauchement US Est (9h–13h ET) pour les points quotidiens, les démos et la réponse aux incidents.
Posture de conformité : Aligné RGPD · Prêt ISO 27001 · SOC 2 Type II en cours · Compatible HIPAA · CCPA reconnu.
Services connexes
Applications iOS, Android et multiplateformes du concept à l'App Store avec un niveau de qualité App Store.
Explorer le développement mobile →
Migrations AWS, Azure et GCP, plateformes Kubernetes, CI/CD et observabilité pour les équipes US & UE.
Explorer Cloud & DevOps →
Ingénierie produit de bout en bout pour les entreprises ambitieuses aux États-Unis & dans l'UE, construite par des équipes seniors avec des pratiques alignées RGPD et conformes SOC 2.
Explorer le développement sur mesure →Cas connexes
Plateforme sociale native iOS + Android avec découverte par géo-radar, chat en temps réel et économie de pièces virtuelles — App Store + Google Play, US & UE.
Voir le cas →
Plateforme web concessionnaire avec synchronisation CRM Bitrix24, pré-remplissage Dadata et alertes vocales en temps réel — canal de prise en charge unique pour chaque demande de financement auto.
Voir le cas →
VPN natif iOS + Android avec WireGuard, backend sans logs, tunnel partagé et lancement App Store + Google Play pour US & UE.
Voir le cas →
Plateformes d'entreprise orientées architecture avec conformité prête pour l'audit et intégration avec SAP, Salesforce, Workday, Okta.
En savoir plus →
Migration par étranglement des stacks legacy (.NET Framework, Java 8, monolithe) sans risque de remplacement complet.
En savoir plus →Plateformes AWS, Azure, GCP avec IaC, observabilité et déploiements sans interruption.
En savoir plus →Partagez quelques détails et un consultant senior vous répondra dans un délai d'un jour ouvré.