Migration React Native vers Expo
Passez votre application React Native sur Expo.
Vos builds, vos montées de version ou vos publications mobilisent trop votre équipe ? Lezo migre votre application vers Expo et divise par 4 environ le coût de sa maintenance et de ses prochaines fonctionnalités.
01Situations
Quand envisager une migration
Des builds fragiles
Les builds iOS ou Android échouent de façon intermittente ou ne passent que sur un poste en particulier.
Une publication complexe
Signer, versionner et publier sur les stores demande des étapes manuelles mal documentées.
Une maintenance native pesante
Les dossiers ios/ et android/ accumulent des modifications que personne n’ose toucher, et chaque montée de React Native devient un chantier.
Le départ d’un développeur clé
La connaissance du projet repose sur une personne qui s’en va, ou sur un prestataire que vous remplacez.
La volonté d’adopter Expo
Votre équipe veut profiter de l’outillage Expo : builds et soumissions EAS, mises à jour, configuration du natif par plugins.
Une évolution importante à venir
Une refonte ou une fonctionnalité majeure est prévue, et vous voulez d’abord assainir la base.
02Coût
Une application Expo coûte environ 4 fois moins cher à faire évoluer
Sur une application React Native ancienne, la maintenance représente souvent autour de 30 000 € par an, et une nouvelle fonctionnalité environ 10 000 €, entre builds à réparer et code natif à adapter. Une fois l’application sur Expo, ces coûts sont divisés par 4 environ.
- Maintenance, par an
- React Native ancien: 30 000 €Après migration Expo: 7 500 €
- Une nouvelle fonctionnalité
- React Native ancien: 10 000 €Après migration Expo: 2 500 €
Ordres de grandeur indicatifs : le chiffrage réel dépend de votre périmètre.
D’où vient l’économie
- 01
Moins de natif à maintenir
Les dossiers ios/ et android/ sont générés à partir de la configuration : plus de modifications manuelles à reporter à chaque mise à jour.
- 02
Des montées de version planifiées
Le SDK Expo regroupe des versions compatibles entre elles : une montée de version redevient une tâche courante.
- 03
Des builds et publications automatisés
EAS construit, signe et soumet l’application aux stores, sans dépendre d’un poste en particulier.
- 04
Une migration accélérée par l’IA
L’IA prend en charge les adaptations répétitives ; chaque étape est validée par les builds et les parcours clés.
03Déroulement
Quatre étapes, des résultats présentés à chaque fois
01
Diagnostic
- Travail réalisé
- Examiner l’existant, les dépendances, les contraintes et les objectifs.
- Ce que vous obtenez
- Une décision claire : migrer ou non, et sur quel périmètre.
02
Plan de migration
- Travail réalisé
- Définir les adaptations, l’ordre de réalisation et la validation.
- Ce que vous obtenez
- Un plan discuté avec votre équipe et une estimation propre au projet.
03
Réalisation et validation
- Travail réalisé
- Adapter le projet, puis vérifier les builds et les parcours clés.
- Ce que vous obtenez
- Une version livrée avec les résultats des vérifications.
04
Transmission
- Travail réalisé
- Documenter les choix et passer la main à votre équipe.
- Ce que vous obtenez
- Une équipe autonome pour construire et publier.
04Après le diagnostic
Ce qui est décidé ensemble
Il n’existe pas de recette unique. Le diagnostic permet de trancher, avec votre équipe :
Les outils retenus
Quels outils Expo adopter (prebuild, EAS Build, EAS Submit, mises à jour) et lesquels conserver parmi vos outils actuels.
Le rythme d’adoption
Une adoption progressive, partie par partie, ou une bascule plus large en une fois.
Les intégrations natives
Pour chaque dépendance native : module Expo équivalent, config plugin existant, plugin à écrire ou code natif à conserver.
La chaîne de publication
Signature, environnements, profils de build et responsabilités de publication sur les stores.
Ce qu’une migration ne règle pas à elle seule
Les bénéfices dépendent de votre projet. Une migration simplifie la configuration native et la chaîne de build ; elle ne corrige pas automatiquement la dette fonctionnelle, les performances ou l’architecture de l’application. Le diagnostic distingue clairement ce qui relève de la migration et ce qui n’en relève pas.
Livrables
Ce que vous recevez
- Un diagnostic écrit de l’existant et des dépendances.
- Un plan d’intervention et l’ordre des adaptations.
- Les adaptations du code et de la configuration.
- Les résultats de validation : builds et parcours testés.
- Une documentation des choix et du nouveau fonctionnement.
- Une session de transmission avec votre équipe.
Les accès nécessaires, les responsabilités de publication, les délais, le suivi et les critères d’acceptation sont précisés dans la proposition.
Étude de cas
Chouic : trois applications migrées vers Expo en un mois
Chouic, studio de jeux mobiles joués par des millions de personnes, a confié à Lezo la migration de trois applications React Native. Son équipe a ensuite migré une quatrième application seule, et constate un gain de productivité et une baisse du coût de maintenance.
Lire l’étude de cas ChouicLezo développe aussi avec Expo sa propre application mobile, Questovery, qu’elle publie et maintient depuis sa création.
Questions fréquentes
Vos questions sur la migration Expo
La migration implique-t-elle de réécrire l’application ?
Non, ce n’est pas l’objectif. L’essentiel du code applicatif est généralement conservé ; ce sont surtout la configuration native, certaines dépendances et la chaîne de build qui évoluent. Le diagnostic identifie les parties qui demandent une adaptation plus profonde.
Comment sont traitées les dépendances et intégrations natives ?
Chaque dépendance est examinée : équivalent Expo, config plugin existant, plugin à écrire ou code natif conservé. Les choix sont documentés dans le plan et validés avec votre équipe.
Quels accès sont nécessaires pour examiner le projet ?
Pour le diagnostic : un accès en lecture au dépôt de code et une description des environnements. Les accès aux comptes de publication et aux services tiers ne sont demandés que si la migration le nécessite, selon des règles fixées avec vous.
Comment prépare-t-on la reprise par notre équipe ?
Vos développeurs participent à la validation, la documentation décrit le nouveau fonctionnement et une session de transmission est prévue. L’objectif : que votre équipe construise et publie sans dépendre de Lezo.
Comment le prix et le calendrier sont-ils établis ?
Après le diagnostic, à partir des dépendances natives à traiter, de la validation attendue et de la disponibilité de votre équipe. Le plan de migration s’accompagne d’une estimation propre au projet. Une fois l’application migrée, sa maintenance et ses nouvelles fonctionnalités coûtent en général environ 4 fois moins.
Où en est votre application ?
Quelle application souhaitez-vous migrer ? Quel est votre principal blocage ? Ces deux réponses suffisent pour préparer un premier échange.