Aller au contenu
useffect.sh
Planifier 30 min avec un senior
Scale · de bare React Native à Expo

Migration vers Expo : prebuild, config plugins, EAS

Des dossiers ios et android maintenus à la main, des patches de Podfile, des builds qui ne passent que sur un seul Mac. Expo génère les projets natifs à partir de votre configuration. On fait la migration dans votre repo, étape par étape, sans réécrire l’app.

Réponse courte

La migration vers Expo de useffect.sh fait passer une app React Native existante, dite « bare », sur Expo : le SDK, le prebuild, les config plugins, les development builds et, si vous le souhaitez, EAS pour les builds, la soumission aux stores et les mises à jour OTA. Elle s’adresse aux équipes qui maintiennent leurs projets iOS et Android à la main, dont les builds ne passent que sur une machine, ou qui veulent livrer des correctifs JavaScript sans repasser par la revue des stores. On commence par un diagnostic de cinq jours : inventaire des modifications natives, des dépendances et du pipeline de release. Ensuite, un ou plusieurs seniors migrent dans votre repo, par PRs relues selon votre process, avec une démo chaque semaine : installation du SDK et des Expo Modules, puis chaque modification native transformée en config plugin, jusqu’à pouvoir supprimer les dossiers natifs. Vous récupérez une app dont les projets natifs se régénèrent avec npx expo prebuild, et un runbook de release.

de diagnostic
5 jours
apps publiées sur les stores
100+
par semaine, dans votre repo
1 démo

01

Quand faire appel à nous

  • Les dossiers ios et android sont modifiés à la main.

    Personne ne sait plus quelles lignes du Podfile, du build.gradle ou de l’AppDelegate ont été ajoutées, ni pourquoi. Chaque montée de version rejoue le même diff à l’aveugle.

  • Le build ne passe que sur une machine.

    Un Mac précis, une version de Xcode précise, un profil de signature que personne n’ose régénérer. Les builds de release dépendent d’une seule personne.

  • Un correctif JS attend la revue des stores.

    Une typo ou un bug de logique repasse par une revue complète, voire plusieurs en cas de rejet. Une mise à jour OTA pousserait le correctif sans nouveau binaire.

  • Une lib Expo que vous ne pouvez pas installer.

    expo-camera, expo-notifications ou un config plugin tiers réglerait le problème, mais le projet n’a pas le SDK Expo.

  • Un nouveau développeur met une semaine à obtenir un build.

    Ruby, CocoaPods, JDK, SDK Android, certificats. Avec un development build, il installe l’app et branche Metro.

  • Plusieurs apps, la config native dupliquée.

    Marques blanches ou variantes par pays : la configuration native est copiée d’un projet à l’autre. Prebuild et config plugins la décrivent une fois.

02

Comment ça se passe

  1. 1 / Jours 1–5

    Diagnostic de migration

    Diff entre vos dossiers natifs et le template Expo de référence, inventaire des libs, des modules natifs maison et des étapes de release. Diagnostic écrit de trois pages max, avec le chemin et les points durs.

  2. 2 / Semaines 1–2

    Installer Expo sans rien casser

    Le SDK Expo et les Expo Modules entrent dans le projet existant, dossiers natifs conservés. Development build distribué à toute l’équipe, Metro inchangé.

  3. 3 / Semaines 2–N

    Déplacer chaque modif native dans un config plugin

    Permissions, schémas d’URL, entitlements, SDK tiers, modules maison : chaque modification manuelle devient un config plugin ou un Expo Module. Quand npx expo prebuild --clean redonne un build identique, les dossiers natifs sortent du repo.

  4. 4 / Dernières semaines

    Release et transmission

    EAS Build, Submit et Update configurés si vous les adoptez, runtime version posée, profils de build par environnement. Runbook de release et passation à votre équipe.

03

Ce que vous recevez

  • Diagnostic écrit avec le chemin de migration
  • App sur le SDK Expo, projets natifs générés par prebuild
  • Config plugins pour chaque modification native
  • Modules natifs maison portés sur Expo Modules
  • Development builds pour toute l’équipe
  • Pipeline EAS Build, Submit et Update, si adopté
  • Runbook de release

04

Missions comparables

05

Questions fréquentes

Combien coûte une migration vers Expo ?

Ça dépend du nombre de modifications natives à transformer en config plugins, des modules maison à porter et du nombre d’apps ou de cibles. Le diagnostic de cinq jours sert à le chiffrer sur pièces, avant la première PR.

Faut-il réécrire l’app ?

Non. Le code React Native reste le même. Ce qui change, c’est la façon dont les projets natifs sont produits : décrits dans la config Expo et des config plugins plutôt que maintenus à la main. Vos écrans, votre navigation et vos stores ne bougent pas.

Est-ce qu’on perd le contrôle du natif ?

Non. Prebuild génère les projets, et vous pouvez les ouvrir dans Xcode ou Android Studio à tout moment. Un besoin que les config plugins ne couvrent pas se code en Swift ou Kotlin dans un Expo Module. Et vous pouvez garder vos dossiers natifs dans le repo si vous préférez.

EAS est-il obligatoire ?

Non. Expo fonctionne avec votre CI actuelle : prebuild, puis build en local ou sur vos runners. EAS apporte les builds cloud, la soumission aux stores et les mises à jour OTA. On le met en place si vous le choisissez.

Que peut-on livrer en OTA ?

Le JavaScript, les styles et les assets. Pas le code natif, pas une nouvelle permission, pas un changement de SDK : ceux-là passent par un nouveau binaire. La runtime version garantit qu’une mise à jour n’atteint que les builds compatibles.

Combien de temps dure la migration ?

Cinq jours pour le diagnostic. La migration elle-même dépend du nombre de modifications natives à transformer et de modules maison à porter : c’est ce que le diagnostic chiffre. L’app reste livrable pendant tout le chantier.

Voir aussi

Les termes de cette page

Mis à jour le 26 octobre 2026

Vos projets natifs peuvent se régénérer.

30 minutes avec un senior pour estimer le chemin vers Expo. Gratuit, réponse sous 48 h.

Planifier 30 minRetour à l’accueil