Migration React Native qui a mal tourné : diagnostic et plan de rattrapage

Une migration React Native qui a mal tourné se rattrape presque toujours, à condition d'arrêter d'empiler les correctifs et de reprendre dans l'ordre : geler le périmètre, sécuriser la version en production, faire un audit de migration pour savoir précisément ce qui casse, puis remonter les versions par paliers, tester sur de vrais appareils et republier progressivement sur les stores.

Les informations ci-dessous sont à jour à la date d'octobre 2026.

À quoi reconnaît-on une migration React Native qui a mal tourné ?

Une migration React Native a mal tourné quand l'équipe ne peut plus livrer une version stable de l'app dans un délai prévisible. Les symptômes se recoupent souvent :

• la branche de migration ne compile plus sur iOS, sur Android ou les deux, et chaque correctif fait apparaître une nouvelle erreur ;
• l'app compile mais plante, parfois uniquement en build de production ;
• deux versions coexistent : l'ancienne en production, la nouvelle jamais assez stable pour la remplacer ;
• une échéance des stores approche et la seule version capable de la respecter n'est pas prête.

Le diagnostic est le même pour une migration vers React Native (depuis une app native, Cordova, Ionic ou web) et pour une montée de version de React Native ou d'Expo.

Quelles sont les causes les plus fréquentes d'une migration React Native ratée ?

Les causes les plus fréquentes d'une migration React Native ratée sont les dépendances natives incompatibles, la New Architecture, les sauts de versions trop grands, les régressions de performance mal mesurées et une base de code restée à moitié migrée. Elles se cumulent souvent.

Des librairies natives incompatibles

Navigation, cartes, paiement, caméra : ces librairies contiennent du code natif, et chaque montée de version peut en casser une. Une librairie abandonnée ne publiera jamais la version compatible attendue. C'est le blocage le plus courant, souvent découvert tard faute d'inventaire.

La New Architecture : Fabric et TurboModules

La New Architecture remplace l'ancien « bridge » entre JavaScript et le code natif par Fabric (le rendu) et TurboModules (les modules natifs). Selon l'annonce officielle de React Native 0.82, elle est depuis le 8 octobre 2025 la seule architecture disponible : newArchEnabled=false sur Android et RCT_NEW_ARCH_ENABLED=0 sur iOS sont ignorés. Les interop layers, qui font fonctionner de nombreuses librairies écrites pour l'ancienne architecture, sont conservées, mais la documentation Expo précise que cette compatibilité n'est pas parfaite. Les modules natifs maison écrits pour l'ancien bridge sont une source fréquente de plantages. Voir notre article sur la New Architecture obligatoire.

Des sauts de version d'Expo SDK trop grands

Sauter plusieurs versions d'Expo SDK cumule toutes les ruptures intermédiaires. La documentation Expo recommande de monter les versions une par une, pour identifier ce qui casse à chaque étape.

Des régressions de performance

Avant de conclure à une régression, vérifiez la mesure. La documentation React Native rappelle que le thread JavaScript est beaucoup plus lent en mode développement et qu'il faut toujours tester la performance sur des builds de release. Les régressions confirmées en release doivent ensuite être localisées écran par écran.

Une base de code à moitié migrée

Depuis une app native, React Native peut être intégré progressivement : la documentation React Native indique qu'il convient aussi pour ajouter une seule vue ou un seul parcours à une app existante. C'est légitime, à condition d'avoir un plan pour terminer. Sans ce plan, l'équipe maintient durablement deux stacks et chaque fonctionnalité coûte deux fois.

Des builds iOS et Android cassés

Erreurs CocoaPods, Gradle ou Android Gradle Plugin incompatibles, Xcode inadapté : les corriger un par un, sans repartir des prérequis de la version de React Native visée, prolonge la crise.

Que faire en premier quand une migration React Native a déraillé ?

La première chose à faire est de geler le périmètre : plus de nouvelle fonctionnalité ni de montée de dépendance « au passage » tant que l'app n'est pas stable. Ensuite :

1. Sécuriser la production. Vérifiez que la dernière version publiée peut être recompilée et republiée en cas de correctif urgent, et notez les versions d'outils (Node, Xcode, JDK) qui le permettent.
2. Figer la branche de migration. Arrêtez les essais successifs et documentez ce qui compile, ce qui ne compile pas et les erreurs observées.
3. Vérifier les échéances des stores, qui déterminent votre marge (voir plus bas).

Comment réaliser un audit de migration React Native ?

Un audit de migration React Native établit un état des lieux complet de l'app avant de reprendre le travail, pour répondre à une question : qu'est-ce qui empêche de livrer, et dans quel ordre le traiter ? Notre check-list de diagnostic :

Pour un projet Expo, npx expo-doctor confronte les dépendances à React Native Directory, l'annuaire communautaire des librairies, selon la documentation Expo. Sans Expo, la vérification se fait dépendance par dépendance.

Quel plan de rattrapage suivre après une migration ratée ?

Le plan de rattrapage suit un ordre précis : repartir d'une base saine, traiter les dépendances, monter les versions par paliers, tester sur appareils réels, puis publier progressivement.

1. Repartir d'une base qui fonctionne. Si la branche de migration est trop dégradée, il est souvent plus rapide de repartir de la version stable et de refaire la migration proprement, en récupérant seulement les changements utiles. Une base saine permet d'attribuer chaque erreur à une cause.
2. Décider pour chaque dépendance bloquante : mettre à jour, remplacer, forker ou réécrire. La documentation Expo suggère une branche dédiée où l'on retire temporairement les librairies incompatibles jusqu'à ce que l'app démarre. Pour une dépendance tierce bloquante, l'équipe React Native recommande de contacter ses mainteneurs.
3. Monter les versions par paliers, avec un build et des tests à chaque étape :
   • Expo : une version de SDK à la fois, puis npx expo install --fix et npx expo-doctor, comme le décrit la documentation Expo ;
   • React Native sans Expo : l'Upgrade Helper, recommandé par la documentation React Native, qui affiche tous les changements entre deux versions, y compris dans les fichiers natifs à reporter à la main ;
   • New Architecture : passer d'abord en React Native 0.81 ou Expo SDK 54, l'y activer et valider l'app, puis monter en 0.82 ou au-delà, comme le recommande l'équipe React Native.
4. Tester sur de vrais appareils, en build de release : parcours critiques (connexion, paiement, notifications, liens profonds, caméra) sur plusieurs iPhone et Android, dont un appareil ancien, en comparant avec la version en production.
5. Publier progressivement, avec les outils des stores décrits ci-dessous.

Comment publier une app React Native migrée sans tout risquer ?

Pour publier une app migrée sans tout risquer, passez par les canaux de test des stores (TestFlight, tests Play Console), puis par une publication progressive que vous pouvez arrêter.

Sur Google Play, selon l'aide Play Console, un déploiement par étapes atteint le pourcentage d'utilisateurs que vous choisissez et augmentez vous-même. L'interrompre empêche de nouveaux utilisateurs de recevoir la version, mais ceux qui l'ont la conservent : un problème se corrige par une nouvelle version. Il n'est possible que pour une mise à jour, pas une première publication.

Sur l'App Store, selon l'aide App Store Connect, la publication progressive diffuse la mise à jour sur 7 jours aux utilisateurs en mises à jour automatiques, de 1 % à 100 %, avec jusqu'à 30 jours de pause au total. Tout utilisateur peut néanmoins la télécharger manuellement pendant ce temps. Surveillez les plantages à chaque palier.

Que faire si une échéance Google Play ou Apple tombe pendant la migration ?

Si une échéance des stores tombe pendant une migration bloquée, évaluez d'abord si la version en production peut être mise en conformité seule, sans attendre la fin de la migration. À la date d'octobre 2026 :

• Google Play : selon la documentation Android Developers, depuis le 31 août 2026, les nouvelles apps et mises à jour doivent cibler Android 16 (API 36), avec une prolongation possible jusqu'au 1er novembre 2026 sur demande. Les apps existantes ciblant Android 14 (API 34) ou moins ne sont plus proposées aux nouveaux utilisateurs sur les versions d'Android plus récentes. Détails dans notre article sur l'exigence Google Play API 36.
• Apple : selon les exigences publiées par Apple, depuis le 28 avril 2026, les apps envoyées sur App Store Connect doivent être compilées avec Xcode 26 ou plus récent.

Une version ancienne de React Native peut ne pas compiler avec ces outils ; la mise en conformité impose alors une montée de version minimale. Et selon la politique de versions de React Native, seules les trois dernières séries mineures sont maintenues : le retard ne fait que s'accumuler.

Quand faut-il arrêter une migration React Native et la repenser ?

Il faut arrêter une migration React Native et la repenser quand la terminer coûte plus cher qu'une autre approche, d'après un inventaire chiffré. Les signaux :

• l'essentiel du code devra être réécrit de toute façon (modules natifs maison, librairies abandonnées sans remplaçant) ;
• la montée de version est devenue une refonte sans que personne ne l'ait décidé ;
• deux stacks cohabitent sans date de fin ;
• la cible n'était pas la bonne : une app essentiellement web migrée vers React Native alors qu'une approche hybride aurait suffi. Pour une app Cordova ou Ionic, la documentation Capacitor indique que Capacitor peut fonctionner aux côtés de Cordova, ce qui permet une migration moins lourde.

Repenser ne signifie pas tout jeter : réduire le périmètre aux parcours critiques, changer de cible technique ou reprendre sur une base saine sont autant d'options. Dans notre expérience, la pire est de continuer sans décider, en ajoutant des correctifs sur une branche que personne ne sait plus stabiliser.

Si la migration fait partie d'un projet plus large qui a mal tourné, notre guide Refonte d'application ratée : que faire maintenant ? couvre la récupération des accès et le choix entre sauver et refaire.

Se faire accompagner par GUIGUI Tech

GUIGUI Tech propose un Audit Migration React Native à 1 500€ HT, livré en 5 jours ouvrés : analyse du code, des dépendances et des points bloquants, plan de migration chiffré et priorisé, rapport et appel de restitution. Si vous nous confiez ensuite la migration complète ou la mise à jour Expo / New Architecture, l'audit est déduit du prix final à condition de confirmer dans les 30 jours. Si le problème dépasse la migration (prestataire parti, accès perdus, app instable sur tout le périmètre), l'Audit de reprise d'application, au même prix, commence par récupérer vos accès et tranche entre sauver, reprendre en partie ou refaire.

Selon le résultat de l'audit de migration, le rattrapage peut prendre la forme d'une Migration React Native complète, à partir de 18 000€ HT sur 4 à 8 semaines, d'une Mise à jour Expo SDK & New Architecture, à partir de 6 500€ HT sur 2 à 4 semaines, ou d'une Migration Cordova / Ionic vers Capacitor, à partir de 9 500€ HT sur 3 à 6 semaines. Nathan Guigui, fondateur du studio, pratique React Native depuis dix ans.