React Native
Une application mobile coûte cher quand on la construit deux fois. C'est le point de départ. Un projet iOS d'un côté, un projet Android de l'autre, deux équipes, deux codes, deux backlogs, deux dettes techniques à entretenir en parallèle. Pour la plupart des cas que les organismes publics, les plateformes professionnelles ou les acteurs touristiques rencontrent, ce dédoublement est un luxe sans contrepartie. React Native existe pour cette raison : écrire une fois, publier sur les deux stores, et garder un seul code à faire évoluer. La logique d'écran, la connexion au serveur, la navigation entre vues, tout se mutualise. Seules les rares zones spécifiques à un OS demandent un traitement particulier.
Le choix se prend au cadrage, sur ce que l'app doit faire. Si elle sert à consulter du contenu, à effectuer des actions métier, à recevoir des notifications, à se logger sur un compte, à dialoguer avec un serveur, React Native fait le travail. Ce sont les usages les plus courants. Là où le calcul change, c'est sur les apps qui exploitent le matériel à fond : traitement vidéo temps réel, jeux 3D, capteurs spécialisés, intégration profonde avec des fonctions système rares. Pour ces cas, le natif pur reste le bon outil et on le dit. La règle qu'on tient, c'est de ne pas vendre React Native comme la réponse à tout : on choisit la stack pour l'usage réel, pas pour la mode.
On a deux cas qui montrent comment le parti pris tient en production. Visit'Agadir est l'application officielle pour découvrir Agadir et sa région, une des plus grandes stations balnéaires de la côte atlantique africaine. L'app donne accès aux établissements touristiques, aux activités et aux événements de la ville, et elle se met à jour en temps réel depuis un Système d'Information Touristique qu'on a aussi développé, côté Symfony. Le mobile n'est pas un brochure-ware figé, c'est un terminal qui suit ce que les équipes éditoriales publient. Côté visiteur, ça change tout : l'information vue dans l'app correspond à ce qui se passe vraiment, pas à un PDF figé il y a six mois.
RAVIe by Iperia, l'autre cas, illustre un usage très différent. Iperia est la plateforme nationale de professionnalisation de l'emploi à domicile en France, et RAVIe est l'application des assistants de vie. Une fois on-boardés, ils continuent l'expérience post-relais avec les participants, montent en compétence par l'échange entre pairs, échangent en temps réel autour des problématiques du métier, et gèrent les urgences de remplacement en contactant d'autres assistants. C'est un réseau communautaire professionnel qui vit dans le téléphone des utilisateurs. L'app pousse sur les deux stores, le back-office Symfony pilote la donnée et les droits, et la même base React Native sert iOS comme Android.
Ces deux projets ont un point commun structurant : aucun des deux n'est une app isolée. Chaque application mobile qu'on conçoit se branche sur un système d'information métier. C'est souvent un back Symfony qu'on construit en parallèle, ou un système existant qu'on connecte via une API REST. Le téléphone affiche ce que le serveur expose, l'utilisateur agit, l'action remonte, la donnée se met à jour. Cette architecture suppose qu'on pense l'API et l'app ensemble, pas l'un puis l'autre. C'est plus exigeant au démarrage. C'est ce qui évite, six mois plus tard, de devoir patcher des écarts entre ce que l'app demande et ce que le serveur peut donner.
Le passage par les stores fait partie du projet, pas après le projet. Apple et Google ont leurs règles, leurs validations, leurs cycles de relecture. Publier une app, ce n'est pas appuyer sur un bouton : il faut préparer les fiches, les visuels, les politiques de confidentialité, gérer les comptes développeurs, soumettre les builds, répondre aux retours des équipes de review. On prend en charge cette partie, du compte développeur à la mise en ligne effective. Pour les organismes publics et les structures qui n'ont pas une équipe mobile interne, c'est un travail qui se sous-estime souvent et qui peut bloquer un lancement pendant des semaines si personne ne le tient.
Les mises à jour suivent ensuite le même fil. Une app installée n'évolue pas comme un site web : chaque correctif, chaque évolution, chaque ajustement passe par un build, une soumission, une validation, puis une diffusion. Les utilisateurs mettent à jour à leur rythme, ce qui veut dire que plusieurs versions de l'app coexistent dans la nature. On en tient compte côté serveur, en gardant un contrat d'API stable et en préparant les évolutions pour qu'elles soient rétro-compatibles. Cette discipline n'est pas glamour, c'est elle qui évite que la sortie d'une nouvelle version casse les téléphones qui n'ont pas encore mis à jour.
Le design des écrans demande un autre angle que sur le web. Sur un téléphone, l'écran est petit, l'utilisateur tient l'appareil à la main, il passe d'une app à l'autre en quelques secondes. Une UX mobile qui marche, c'est une UX qui se comprend sans mode d'emploi, où chaque écran porte une action claire, où la navigation suit les conventions du système. On respecte les patterns iOS et Android quand ils diffèrent, pour que l'app se sente à sa place sur chaque plateforme. React Native permet ces ajustements quand ils sont nécessaires : on garde le code commun pour la logique, on adapte les détails d'interface là où ça compte vraiment.
La performance perçue, sur mobile, se joue dans les détails. Un délai de 300 millisecondes après un tap se sent. Un écran qui se charge en deux temps, d'abord la structure puis le contenu, donne l'impression que l'app rame, même si tout est rapide. On traite ces points pendant la conception : on précharge ce qui peut l'être, on affiche des états intermédiaires lisibles, on évite les listes qui se rechargent à chaque retour. React Native a ses pièges sur ces sujets, et on les connaît. Le cadre n'absout pas du travail de finition, il le rend juste plus rapide à exécuter sur les deux plateformes en même temps.
L'accès aux fonctions du téléphone, géolocalisation, appareil photo, notifications, partage, biométrie, scan de QR code, se branche via des modules. La majorité des besoins courants sont couverts par des bibliothèques maintenues. Pour les fonctions plus rares, on écrit un pont vers du code natif, en Swift côté iOS et en Kotlin côté Android. C'est ce qui rend le cross-platform soutenable : on n'est pas bloqué quand un besoin sort du standard, on ouvre juste une zone native ciblée et le reste de l'app continue de partager son code. La limite, c'est qu'il faut savoir le faire, et on le sait.
Sur la durée, ce qui fait tenir une app mobile, c'est la capacité à la maintenir et à la faire évoluer sans la réécrire. On organise le code pour qu'une autre équipe puisse reprendre, on isole la logique des écrans, on documente les choix non évidents, on garde les dépendances à jour. Une app React Native qui n'a pas été tenue pendant deux ans devient pénible à reprendre : les versions d'iOS et d'Android avancent, les outils de build évoluent, les bibliothèques se déprécient. La TMA, sur ce type de projet, n'est pas une option de confort, c'est ce qui garde l'app vivante face aux changements imposés par Apple et Google.
On ne sort pas React Native quand l'app n'a pas vraiment besoin d'être une app. Un site mobile responsive bien fait suffit dans beaucoup de cas, et il évite tout le travail des stores, des mises à jour et des comptes développeurs. La question qu'on pose au cadrage est simple : l'utilisateur a-t-il besoin de notifications push, d'un accès hors-ligne, de fonctions du téléphone que le navigateur ne donne pas, d'une présence sur l'écran d'accueil ? Si oui, l'app mobile se justifie. Sinon, on construit un site bien pensé pour mobile et on s'arrête là. C'est la même logique que sur le reste de nos arbitrages : on choisit l'outil pour ce qu'il apporte, pas pour ce qu'il représente.