Projet démo : application mobile React Native avec API Node.js

Ce projet démonstratif illustre notre approche du développement mobile multiplateforme. Il n'est pas issu d'une mission client : c'est une application que nous maintenons pour montrer, sur un cas concret, les choix techniques que nous recommandons.

Le cas modélisé est une application pour des équipes terrain (techniciens, livreurs, enquêteurs) qui reçoivent des interventions, saisissent des comptes rendus avec photos et doivent pouvoir travailler dans des zones sans réseau.

L'application est publiée sur iOS et Android à partir d'une seule base de code, et une API Node.js centralise les données et les notifications.

Les applications terrain échouent souvent sur trois points : elles ne fonctionnent pas sans réseau, elles perdent des saisies en cas de conflit de synchronisation, et chaque correction impose de repasser par les magasins d'applications.

Il faut donc concevoir dès le départ le stockage local, la synchronisation et la stratégie de mise à jour, plutôt que de les ajouter après coup.

L'application est développée en React Native avec Expo et TypeScript ; la navigation, l'accès à la caméra et à la géolocalisation passent par les modules Expo.

Une base SQLite locale stocke les interventions et les comptes rendus ; une file de synchronisation enregistre les modifications faites hors ligne et les rejoue vers l'API.

L'API Node.js (Fastify) expose des points de terminaison REST avec authentification par jetons ; PostgreSQL, accédé via Prisma, stocke les données avec un numéro de version sur chaque enregistrement pour la détection des conflits.

Les notifications push sont envoyées via le service de notifications Expo, déclenchées par l'API lors de la création ou de la modification d'une intervention.

EAS Build produit les binaires iOS et Android dans le cloud, et EAS Update diffuse les mises à jour du code JavaScript directement aux appareils (OTA).

La couche de données de l'application est conçue autour du mode hors ligne : toutes les lectures se font dans SQLite, et toutes les écritures y sont d'abord enregistrées avec un identifiant généré localement. Un module de synchronisation envoie ensuite les changements à l'API, dans l'ordre, avec reprise en cas d'échec.

Les conflits sont détectés côté API grâce à la version portée par chaque enregistrement. La règle par défaut conserve la modification la plus récente, mais certains champs (le statut d'une intervention, par exemple) appliquent des règles métier explicites, et les conflits non résolus sont signalés à l'utilisateur.

Les notifications push servent à signaler un événement et à déclencher une synchronisation en arrière-plan ; elles ne transportent jamais de données sensibles. Les jetons d'appareils sont gérés par l'API et invalidés à la déconnexion.

Les builds sont produits par EAS Build avec des profils distincts (développement, recette, production) et les mises à jour OTA sont publiées par canal, ce qui permet de tester un correctif sur les appareils de recette avant de le diffuser à tous.