Migrer vers la New Architecture en React Native : Fabric, TurboModules et Bridgeless (2026)

Mis à jour : 31 mai 2026

Migrer vers la New Architecture en React Native (Fabric, TurboModules et mode Bridgeless) consiste à désactiver l'ancien pont JavaScript et à compiler votre app avec le moteur de rendu Fabric, les modules natifs typés générés par Codegen, et l'exécution sans pont (Bridgeless) activée par défaut depuis la version 0.76. En 2026, la New Architecture est le mode par défaut de tout nouveau projet créé avec npx @react-native-community/cli init ou Expo SDK 53+. Ce guide explique comment basculer un projet existant sans casser vos écrans en production.

Qu'est-ce que la New Architecture en React Native ?

La New Architecture est la refonte des fondations natives de React Native commencée en 2018 et finalisée en 2024 avec la version 0.76. Elle remplace le pont asynchrone JSON (le « bridge ») par JSI (JavaScript Interface), une couche C++ qui expose directement les objets natifs au moteur JavaScript Hermes. Concrètement, un appel JS vers un module natif n'est plus sérialisé en JSON : il devient un appel de fonction C++ synchrone, ce qui réduit la latence de plusieurs millisecondes par interaction et débloque des cas d'usage comme l'animation pilotée par le worklet UI.

Cette refonte s'articule autour de trois piliers : Fabric (le nouveau renderer), TurboModules (le nouveau système de modules natifs), et Codegen (l'outil qui génère du C++/Java/Objective-C typé à partir de vos spécifications TypeScript). En 2026, ces trois piliers sont matures et alimentent Meta Messenger, Microsoft Office Mobile, Shopify et la majorité des nouvelles apps Expo. J'ai migré quatre apps cette année, et le gain mesurable sur le temps de démarrage à froid tourne autour de 15 à 25 % selon la taille du bundle.

Fabric, TurboModules et Bridgeless : qui fait quoi ?

Comprendre ces trois briques évite de chercher le mauvais bug dans la mauvaise couche. Voici la répartition des responsabilités :

L'erreur classique consiste à penser « j'ai activé la New Arch donc tout est TurboModule ». Faux : tant qu'une librairie n'a pas publié de spec Codegen, elle continue d'utiliser la couche d'interop, ce qui fonctionne mais sans gagner les performances JSI. Consultez le React Native Directory filtré sur New Architecture avant de planifier votre migration : il liste plus de 600 librairies compatibles avec un statut explicite.

Prérequis avant de migrer

Avant de toucher au moindre fichier de build, faites cet inventaire :

1. Version React Native : mettez-vous au minimum sur 0.76, idéalement 0.78 ou 0.79. En dessous, la New Arch existe mais reste expérimentale. Utilisez l'Upgrade Helper officiel pour suivre le diff exact entre votre version et la cible.
2. Hermes activé : JSC fonctionne encore, mais le couple New Arch + Hermes est le combo testé en priorité par l'équipe core. C'est l'option par défaut depuis 0.70.
3. Xcode 16+ et Android Gradle Plugin 8.6+ : requis pour la compilation C++ moderne et les nouveaux templates de Codegen.
4. Audit des modules natifs custom : listez tous vos modules dans android/app/src/main/java et ios/. Chacun devra être migré ou conservé via l'interop.
5. Suite de tests E2E : Maestro ou Detox. Sans cela, les régressions de layout passent inaperçues jusqu'au crash production.

Si vous démarrez un nouveau projet, ce travail est gratuit (la CLI génère déjà une app New Arch). Si vous partez d'un projet de 2022 sur 0.68, prévoyez deux jours rien que pour atteindre 0.76 avant de commencer la vraie migration. Mon conseil de pragmatique : faites les bumps de version un par un, validez chaque palier en CI, puis activez la New Arch en dernier.

Comment activer la New Architecture étape par étape

Sur un projet bare React Native ≥ 0.76, l'activation tient en deux flags. Sur Expo, en une ligne de config.

Pour un projet React Native CLI

Éditez android/gradle.properties :

# Activer Fabric, TurboModules et Bridgeless
newArchEnabled=true
hermesEnabled=true

Côté iOS, vous avez deux options. La plus simple en 2026 est de poser le flag dans ios/Podfile :

# ios/Podfile
ENV['RCT_NEW_ARCH_ENABLED'] = '1'

require Pod::Executable.execute_command('node', ['-p',
  'require.resolve("react-native/scripts/react_native_pods.rb", {paths: [process.argv[1]]})',
  __dir__]).strip

platform :ios, min_ios_version_supported
prepare_react_native_project!

Puis lancez la régénération des pods et la compilation :

cd ios && bundle exec pod install && cd ..
npx react-native run-ios
npx react-native run-android

Pour un projet Expo (SDK 53+)

La New Arch est déjà activée par défaut sur les nouveaux projets. Pour un projet existant, ajoutez le plugin expo-build-properties dans app.json :

{
  "expo": {
    "plugins": [
      ["expo-build-properties", {
        "android": { "newArchEnabled": true },
        "ios": { "newArchEnabled": true }
      }]
    ]
  }
}

Puis régénérez le projet natif avec npx expo prebuild --clean et reconstruisez via EAS Build. Si vous utilisez Expo Go pour le dev, sachez que depuis SDK 52 il tourne lui-même en New Arch, donc votre code JS y est déjà testé sous Fabric. Pour un guide détaillé sur l'écosystème Expo, voyez notre guide d'Expo Router v4.

Auditer vos dépendances et la couche d'interop

La couche d'interop est l'aspect le plus mal compris de la migration. Elle permet à un module écrit pour l'ancienne architecture (Paper) de tourner sous Fabric sans modification. C'est ce qui rend la migration faisable en quelques jours plutôt qu'en quelques mois, mais elle a des limites précises :

• Les view managers legacy fonctionnent à condition que le module déclare RCT_EXPORT_VIEW_PROPERTY avec un type connu. Les types id opaques échouent silencieusement.
• Les commandes impératives (ex. this._ref.scrollToIndex()) passent par un adaptateur qui ajoute un délai de un frame.
• Les callbacks et promesses sont supportés, mais les modules qui appellent callback() plusieurs fois (anti-pattern legacy) lèvent une exception sous Bridgeless.

Pour auditer rapidement, lancez :

npx react-native config | jq '.dependencies | to_entries[] | {name: .key, platforms: .value.platforms | keys}'

Puis croisez la liste avec le React Native Directory. Toute librairie marquée « Untested » mérite une issue ouverte sur son repo avant la migration. Sur ma dernière app, deux libs sur quarante-trois étaient bloquantes : un SDK analytics maison et un wrapper de paiement. Le SDK analytics a été migré en une journée, le wrapper de paiement a été remplacé par la lib officielle du provider, qui supportait déjà la New Arch.

Migrer un module natif custom vers TurboModules

Si vous avez un module natif maison, voici le squelette minimal pour le convertir en TurboModule. Première étape : la spec TypeScript, qui sera la source de vérité pour Codegen.

// NativeAnalytics.ts
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
  track(event: string, properties: Object): void;
  identify(userId: string): Promise<boolean>;
  getInstallationId(): string; // synchrone, possible avec JSI
}

export default TurboModuleRegistry.getEnforcing<Spec>('Analytics');

Dans package.json, déclarez la config Codegen :

{
  "codegenConfig": {
    "name": "AppSpecs",
    "type": "modules",
    "jsSrcsDir": "./src/specs"
  }
}

Côté Android (Kotlin), implémentez la classe abstraite générée :

// android/src/main/java/com/myapp/AnalyticsModule.kt
package com.myapp

import com.facebook.react.bridge.ReactApplicationContext
import com.appspecs.NativeAnalyticsSpec

class AnalyticsModule(reactContext: ReactApplicationContext)
  : NativeAnalyticsSpec(reactContext) {

  override fun getName() = "Analytics"

  override fun track(event: String, properties: ReadableMap) {
    AnalyticsSDK.track(event, properties.toHashMap())
  }

  override fun identify(userId: String, promise: Promise) {
    AnalyticsSDK.identify(userId) { success -> promise.resolve(success) }
  }

  override fun getInstallationId(): String = AnalyticsSDK.installationId
}

Le code Objective-C++/Swift pour iOS suit le même schéma. La grosse différence avec l'ancien système : les méthodes synchrones (comme getInstallationId) deviennent possibles. Avant, tout devait passer par une callback. Pour un projet avec une logique de secret stockée localement, ce point change le design (vous pouvez relire notre article sur l'authentification biométrique avec SecureStore) qui exploite déjà ce pattern.

Tester et déboguer après la migration

Une fois la New Arch active, le premier réflexe est de vérifier visuellement que l'app boot. C'est insuffisant. Voici la checklist que j'applique systématiquement :

1. Inspecter l'arbre de rendu avec React DevTools 6.x. Fabric expose les fibers exactement comme le web, ce qui aide à repérer les re-renders parasites.
2. Profiler le démarrage à froid via npx react-native profile-hermes. Comparez avant/après ; un écart de moins de 10 % en faveur de la New Arch indique un autre goulot d'étranglement.
3. Tester les gestes avec react-native-gesture-handler en mode strict. La New Arch utilise un système de hit-testing différent et certains PanGestureHandler imbriqués cessent de fonctionner sans configuration explicite des priorités.
4. Vérifier les modales et les portails. Les libs comme react-native-modal antérieures à la version 14 ne respectent pas la nouvelle API de ViewManager.
5. Activer LogBox en mode verbeux avec LogBox.ignoreLogs([]) commenté pendant la phase de test, pour voir tous les warnings de l'interop layer.

Pour mesurer l'impact sur le rendu, l'outil le plus utile en 2026 reste le tracé Perfetto recommandé par l'équipe React Native. Il montre la file d'attente JSI en temps réel et expose les ponts encore actifs si vous n'êtes pas réellement en mode Bridgeless.

Pièges fréquents et comment les éviter

Six migrations m'ont appris six leçons, justement. Voici les régressions qui reviennent le plus souvent :

Layout cassé sur les ScrollView avec contenu mesuré

Fabric mesure de façon synchrone, contrairement à Paper. Si votre code lit onLayout dans le premier render et déclenche un setState, vous risquez une boucle infinie ou un flash visuel. La fix : utilisez useLayoutEffect ou passez par la nouvelle API useEvent de Reanimated 4. Pour les listes lourdes, comparez avec notre benchmark FlatList vs FlashList vs LegendList. Toutes les trois ont des comportements spécifiques sous Fabric.

Animations Reanimated qui se figent

Sous Bridgeless, les worklets s'exécutent dans un runtime JSI dédié. Si vous capturez une référence à une closure JS depuis un worklet, vous obtenez l'erreur cryptique ReanimatedError: Tried to access a worklet from a different runtime. La solution est de marquer explicitement 'worklet' en première ligne de la fonction et d'utiliser runOnJS pour rappeler le thread JS.

Modules natifs qui appellent les callbacks deux fois

Pattern toléré en Paper, fatal en Bridgeless. Auditez vos modules avec grep -rn "callback(" android/app/src et garantissez un seul appel par chemin d'exécution. Préférez les promesses, qui sont rejetées si vous les résolvez deux fois.

Tailles de bundle qui explosent

Codegen génère du code natif pour chaque spec. Si vous déclarez dix specs mais n'en utilisez qu'une seule, vous embarquez tout. Découpez vos modules en packages npm distincts ou utilisez jsSrcsDir ciblé sur le minimum nécessaire.