Vous avez commandé une pizza. Vous ouvrez l'app. Vous voyez un petit point se déplacer sur la carte, en temps réel, à 800 mètres de chez vous. Une notification s'affiche : "Votre livreur arrive dans 3 minutes." Vous allez ouvrir la porte.
Cette expérience — banalisée par Uber Eats, Deliveroo ou Stuart — semble simple côté utilisateur. Côté technique, c'est l'une des fonctionnalités les plus complexes à bien implémenter dans une application mobile. Le tracking en temps réel implique une chaîne de composants qui doivent tous fonctionner ensemble, de façon fiable, à grande échelle, et sans vider la batterie du livreur en 20 minutes.
Ce guide vous explique comment ça marche vraiment — et comment bien le construire.
Pourquoi le tracking en temps réel est devenu indispensable
Un client qui voit où est son colis n'a plus besoin d'appeler pour obtenir des informations. Cela libère les équipes support et améliore l'expérience client. Les transporteurs peuvent identifier un retard en amont et prévenir le client avant qu'il ne s'inquiète. Le suivi en direct rassure les clients : ils savent exactement quand leur colis arrivera et peuvent s'organiser en conséquence
Les chiffres le confirment : les applications qui proposent un tracking en temps réel affichent un taux de satisfaction client significativement supérieur à celles qui se limitent à des notifications de statut (commande confirmée, en préparation, en route). Le tracking n'est plus un différenciateur — c'est une attente de base.
Ce qui change en 2026 : le standard GPS polling qui met à jour la position toutes les 10 à 30 secondes est désormais insuffisant. Une architecture push en temps réel met à jour la position toutes les 3 à 5 secondes — c'est ce que vos utilisateurs voient sur Uber Eats, et c'est ce qu'ils attendent.
L'architecture : les 4 composants essentiels
Un système de tracking en temps réel repose sur quatre composants : une source GPS côté appareil via l'API de géolocalisation native, un WebSocket ou une file de messages pour le transport des données, une API cartographique comme Google Maps ou Mapbox pour l'affichage, et une base de données back-end pour diffuser l'état de la position.</cite>
Voici comment ces composants s'assemblent en pratique.
Composant 1 — La collecte GPS côté livreur
C'est le point de départ de toute la chaîne. L'application livreur collecte la position GPS de l'appareil et l'envoie au serveur à intervalle régulier.
En React Native, deux approches coexistent :
Le foreground tracking (app au premier plan) : simple à implémenter, mais inutilisable en pratique — le livreur ne peut pas garder son téléphone allumé sur l'app en permanence.
Le background tracking (app en arrière-plan) : indispensable en production, mais soumis à des restrictions strictes d'iOS et Android. C'est ici que la plupart des implémentations ratent.
iOS impose des contraintes sévères sur l'usage GPS en arrière-plan pour préserver la batterie. Il faut déclarer explicitement le mode location dans Info.plist, utiliser le mode significant-change pour les faibles mouvements, et basculer sur la CLLocationManager native pour le tracking haute fréquence. Sur Android, le ForegroundService avec une notification persistante est la solution recommandée depuis Android 8.
La librairie de référence en React Native : react-native-background-geolocation (Transistor Software) — elle gère les modes foreground/background, l'économie de batterie adaptative, et les spécificités iOS/Android de façon transparente. C'est l'option la plus mature et la plus utilisée en production sur des apps de livraison réelles.
La fréquence d'envoi : toutes les 3 à 5 secondes en déplacement actif, toutes les 30 secondes à l'arrêt. Cette distinction est cruciale pour l'autonomie de la batterie : envoyer une position toutes les 5 secondes en permanence peut vider une batterie standard en moins de 4 heures.</cite> Un bon système adapte automatiquement la fréquence selon la vitesse de déplacement détectée.
Composant 2 — Le transport temps réel : WebSocket
C'est le cœur de l'architecture temps réel. La position GPS du livreur doit parvenir à l'app client en moins d'une seconde — les requêtes HTTP classiques (polling) ne permettent pas ça de façon efficiente.
Le WebSocket maintient une connexion bidirectionnelle persistante entre le client et le serveur. Dès que le back-end reçoit une nouvelle position du livreur, il la pousse instantanément vers tous les clients concernés (le client qui attend sa commande, l'interface dispatcher de la plateforme).
La carte est rafraîchie via WebSocket — pas besoin de recharger : les véhicules glissent en direct sur l'écran.
En pratique, deux options selon l'échelle du projet :
Socket.io : la solution la plus utilisée pour les MVPs et les plateformes à taille humaine. Simple à implémenter, bien documentée, gère automatiquement le fallback vers le polling HTTP si le WebSocket n'est pas disponible.
Apache Kafka ou AWS SQS :pour gérer des centaines de livreurs qui envoient des mises à jour de position simultanément, une file de messages entre la couche WebSocket et la base de données est nécessaire pour absorber le volume. C'est l'architecture des plateformes à grande échelle — Uber, Deliveroo. Pour un MVP, c'est surdimensionné.
Firebase Realtime Database : Firebase fonctionne bien pour les MVPs avec moins de 50 000 connexions simultanées. C'est une bonne option pour valider le concept sans construire l'infrastructure WebSocket from scratch. La migration vers une architecture custom interviendra quand le volume le justifiera.
Par où commencer ?
Le tracking en temps réel est une fonctionnalité qui paraît simple et qui cache une complexité réelle. Les erreurs les plus coûteuses sont presque toujours les mêmes : sous-estimer les contraintes du background GPS sur iOS, ne pas penser à l'optimisation batterie dès le départ, et construire une infrastructure qui ne scale pas.
Le bon point de départ : commencez par Firebase pour valider l'expérience utilisateur avec un MVP, puis migrez vers une architecture custom quand le volume le justifie. Ne construisez pas l'infrastructure Kafka d'Uber avant d'avoir vos 100 premiers livreurs actifs.
Vous développez une application de livraison et vous vous posez des questions sur l'architecture du tracking ? Parlez-nous en — c'est exactement le type de sujet qu'on cadre en phase de discovery.
Article rédigé par l'équipe Le Backyard — agence spécialisée React Native et développement mobile sur mesure, Paris.
Composant 3 — Le geofencing et le calcul d'ETA
Le geofencing consiste à définir des zones géographiques virtuelles (un cercle autour du restaurant, un périmètre autour de l'adresse de livraison) et à déclencher des actions automatiques quand le livreur les franchit.
Le geofencing déclenche des mises à jour de statut automatiques à des distances définies du point de collecte et de livraison. Une API de routage recalcule l'ETA à chaque changement significatif de position du livreur.Ì
Concrètement, le geofencing gère :
- "Votre livreur est arrivé au restaurant" → le restaurant commence à préparer la commande
- "Votre livreur est à 5 minutes" → notification push client
- "Livraison effectuée" → déclenchement du paiement, demande d'avis
Pour le calcul d'ETA, deux options : l'API Google Maps Directions (simple, fiable, payante à l'usage) ou Mapbox Navigation (plus flexible, tarification différente). L'ETA doit être recalculé dynamiquement en fonction du trafic en temps réel — un ETA calculé au départ et non mis à jour en cours de route génère des frustrations importantes quand il y a des embouteillages.
Composant 4 — L'affichage cartographique côté client
C'est la partie visible par l'utilisateur — le petit point qui avance sur la carte. Simple à afficher, difficile à rendre fluide.
Google Maps SDK vs Mapbox : Google Maps est plus facile à intégrer et plus familier pour les utilisateurs. Mapbox offre plus de personnalisation visuelle (couleurs, styles de carte, animations) et une tarification potentiellement plus avantageuse à grande échelle.
L'animation du marqueur est un détail qui fait toute la différence perçue. Si le marqueur "saute" d'une position à l'autre toutes les 5 secondes, l'expérience est saccadée. La bonne approche : interpoler la position entre deux points GPS reçus pour créer une animation fluide de déplacement. En React Native, react-native-maps avec Animated de React Native ou react-native-reanimated permet de gérer cette interpolation proprement.
La rotation du marqueur (orienter la flèche dans le sens de déplacement) nécessite de calculer le bearing entre deux positions GPS consécutives — un calcul trigonométrique simple mais souvent oublié dans les implémentations basiques.
Les pièges techniques à anticiper
Le GPS drift. Les restrictions du mode arrière-plan sur iOS et la dérive GPS sont les deux raisons les plus fréquentes pour lesquelles le tracking échoue après le lancement.</cite> En milieu urbain dense (immeubles, tunnels, parkings souterrains), le signal GPS peut sauter de plusieurs dizaines de mètres sans que le livreur ait bougé. Il faut filtrer ces positions aberrantes côté serveur avant de les diffuser — un filtre de Kalman simplifié ou un seuil de vitesse maximum acceptable suffit dans la plupart des cas.
La consommation batterie. Un tracking GPS haute fréquence mal optimisé vide une batterie en moins de 4 heures. Pour un livreur qui travaille 8 heures, c'est rédhibitoire. Les optimisations essentielles : adapter la fréquence de collecte à la vitesse de déplacement, couper le GPS quand le livreur est à l'arrêt depuis plus de 2 minutes, utiliser le réseau cell-based positioning (moins précis mais beaucoup plus économe) en complément du GPS.
La reconnexion WebSocket. Les connexions mobiles sont instables — tunnels, zones blanches, changement de réseau WiFi vers 4G. Le client doit implémenter une logique de reconnexion automatique avec exponential backoff, et le serveur doit gérer proprement la perte et le rétablissement de connexion sans perdre l'état de la livraison.
La gestion multi-commandes. Quand un livreur gère plusieurs commandes simultanément (pratique courante sur Uber Eats), l'affichage côté client doit rester cohérent : montrer uniquement le trajet pertinent pour chaque client, gérer les changements d'ordre de livraison en temps réel.
Le stack recommandé par Le Backyard
Pour un MVP de tracking en temps réel dans une app de livraison :
Composant Solution MVPSolution scaleGPS mobilereact-native-background-geolocation
idemTransport temps réelSocket.ioApache Kafka + WebSocket customBase de données positionsPostgreSQL + PostGISTimescaleDB + PostGISCartographieGoogle Maps SDKMapbox ETAGoogle Maps Directions APIHERE Routing APIInfrastructureFirebase (< 50k connexions) AWS avec autoscaling
Combien ça coûte ?
Le coût de développement d'un système de tracking en temps réel démarre à environ 15 000€. L'infrastructure mensuelle représente entre 100€ et 5 000€ selon le volume d'utilisateurs.
En contexte français avec une agence spécialisée :
Budget estimé
MVP tracking GPS + WebSocket + carte basique 10 000 – 35 000 €
Tracking production+ geofencing, ETA, background mode optimisé 35 000 – 60 000€
Plateforme complète+ multi-livreurs, dispatcher, analytics 60 000 – 120 000 €
À noter : le tracking en temps réel est rarement un projet standalone — il s'intègre dans une application de livraison complète (app client, app livreur, back-office restaurant). Ces budgets correspondent à la composante tracking seule.
%20(1).png)
%20(1)%20(1).png)
