Nouvelle Architecture React Native en 2026 : Hermes V1, Mode Bridgeless et Questions d'Entretien

La Nouvelle Architecture de React Native a atteint sa pleine maturité en 2026. Avec React Native 0.84 livrant Hermes V1 comme moteur par défaut et la version 0.85 supprimant toute trace du bridge historique, le framework offre désormais des performances quasi natives sans que les développeurs aient à se soucier de flags d'architecture ou de couches de compatibilité.

Ce qui a changé dans la pile architecturale de React Native

L'ancienne architecture de React Native reposait sur un bridge JSON asynchrone mono-thread pour transmettre les messages entre JavaScript et le code natif. Chaque interaction passait par ce goulot d'étranglement : événements tactiles, calculs de mise en page, appels de modules. La Nouvelle Architecture remplace chaque couche de ce pipeline par une alternative directe et synchrone.

| Couche | Ancienne Architecture | Nouvelle Architecture | |--------|----------------------|----------------------| | Moteur JS | JavaScriptCore | Hermes V1 (bytecode + JIT) | | Rendu | Paper (bridge async) | Fabric (synchrone, C++ partagé) | | Modules Natifs | Bridge Modules (sérialisation JSON) | TurboModules (JSI, appels directs) | | Communication | Bridge JSON Async | JSI (JavaScript Interface) | | Initialisation | Init bridge + enregistrement modules | Bridgeless (lazy, à la demande) |

JSI (JavaScript Interface) constitue le fondement. Au lieu de sérialiser chaque appel en JSON et de le faire transiter par une file d'attente, JSI expose des objets hôtes C++ directement au JavaScript. Un appel TurboModule qui nécessitait auparavant un encodage JSON, une mise en file sur le bridge et un décodage JSON s'exécute désormais comme un simple appel de fonction direct.

Hermes V1 : le moteur JavaScript par défaut

Hermes V1 est devenu le moteur par défaut dans React Native 0.84, publié en février 2026. Il s'agit d'une réécriture complète du compilateur et de la VM, et non d'une simple mise à jour incrémentale des versions précédentes de Hermes.

Les améliorations couvrent quatre domaines : un compilateur réécrit avec un nouveau format de bytecode, un compilateur JIT amélioré, le ramasse-miettes concurrent Hades, et une meilleure prise en charge des patterns JavaScript modernes utilisés par React 19.

// Comparing startup and runtime metrics

// Hermes V1 bytecode is pre-compiled at build time
// No parse-compile step at runtime = faster cold starts

// Cold start comparison (production build, Pixel 8):
// Hermes V1:  ~850ms TTI
// JSC:        ~1200ms TTI  (29% slower)

// Memory footprint (complex app, 50+ screens):
// Hermes V1:  ~45MB baseline
// JSC:        ~72MB baseline (38% more)

// GC pause comparison (FlatList, 500+ complex cells):
// Hermes V1 (Hades):  <12ms max pause
// Old Hermes:         ~45ms occasional pauses
// Result: zero dropped frames in scroll benchmarks

Hades, le ramasse-miettes concurrent, mérite une attention particulière. Les versions précédentes de Hermes utilisaient un GC en mode stop-the-world qui provoquait occasionnellement des saccades visibles lors du défilement de listes. Hades exécute la collecte de manière concurrente sur un thread d'arrière-plan, maintenant les pauses GC sous les 12 ms. Pour les applications affichant de longues listes avec des cellules complexes, cela élimine la dernière source de pertes d'images côté JavaScript.

Fabric : rendu et mise en page synchrones

Fabric remplace le moteur de rendu Paper par un cœur C++ partagé entre iOS et Android. La différence fondamentale : les calculs de mise en page s'effectuent de manière synchrone sur le thread JavaScript au lieu de passer de manière asynchrone par le bridge.

Ce modèle synchrone ouvre deux possibilités qui étaient impossibles avec Paper :

1. Support du rendu concurrent : Fabric s'intègre aux fonctionnalités concurrentes de React 19. Les transitions, les frontières Suspense et useTransition fonctionnent correctement car Fabric peut interrompre et reprendre le rendu.

2. Mise en page C++ directe : Yoga (le moteur de mise en page) s'exécute dans le même espace mémoire que le runtime JavaScript. Aucun surcoût de sérialisation pour les calculs flexbox.

// Concurrent features work correctly with Fabric
import React, { useState, useTransition } from 'react'
import { View, Text, FlatList, TextInput, StyleSheet } from 'react-native'

type Item = { id: string; name: string; category: string }

function SearchableList({ items }: { items: Item[] }) {
  const [query, setQuery] = useState('')
  const [filtered, setFiltered] = useState(items)
  const [isPending, startTransition] = useTransition()

  const handleSearch = (text: string) => {
    setQuery(text) // Urgent: update input immediately
    startTransition(() => {
      // Non-urgent: filter can be deferred
      const result = items.filter(item =>
        item.name.toLowerCase().includes(text.toLowerCase())
      )
      setFiltered(result)
    })
  }

  return (
    <View style={styles.container}>
      <TextInput
        value={query}
        onChangeText={handleSearch}
        placeholder="Search items..."
        style={styles.input}
      />
      {isPending && <Text style={styles.pending}>Filtering...</Text>}
      <FlatList
        data={filtered}
        keyExtractor={item => item.id}
        renderItem={({ item }) => (
          <View style={styles.row}>
            <Text>{item.name}</Text>
          </View>
        )}
      />
    </View>
  )
}

const styles = StyleSheet.create({
  container: { flex: 1, padding: 16 },
  input: { borderWidth: 1, borderColor: '#ccc', padding: 12, marginBottom: 8 },
  pending: { color: '#888', marginBottom: 4 },
  row: { padding: 12, borderBottomWidth: 1, borderBottomColor: '#eee' },
})

Le hook useTransition dans cet exemple illustre pourquoi Fabric est essentiel. Avec Paper, startTransition n'avait aucun effet car le moteur de rendu ne pouvait pas interrompre un rendu en cours. L'intégration de Fabric avec le mode concurrent de React 19 permet aux mises à jour différées de fonctionner comme prévu, gardant le champ de saisie réactif tout en filtrant des milliers d'éléments en arrière-plan.

TurboModules et JSI : élimination du surcoût de sérialisation

Les TurboModules remplacent l'ancien système NativeModules. Le gain de performance provient de l'élimination totale de la sérialisation JSON. Un appel via le bridge suivait ce chemin : objet JS -> JSON.stringify -> file d'attente bridge -> JSON.parse -> appel natif -> JSON.stringify -> file d'attente bridge -> JSON.parse -> callback JS. Un appel TurboModule est une invocation directe de fonction C++ via JSI.

// TurboModule spec using the Codegen
import type { TurboModule } from 'react-native'
import { TurboModuleRegistry } from 'react-native'

export interface Spec extends TurboModule {
  // Synchronous: returns immediately, no bridge round-trip
  getDeviceModel(): string
  getOSVersion(): string
  getBatteryLevel(): number

  // Asynchronous: for operations that genuinely need async
  getStorageUsage(): Promise<{ used: number; total: number }>
}

export default TurboModuleRegistry.getEnforcing<Spec>('DeviceInfo')

// Native Android implementation of the TurboModule
package com.app.modules

import com.facebook.react.bridge.ReactApplicationContext
import com.facebook.react.bridge.ReadableMap
import com.facebook.react.bridge.WritableNativeMap
import com.facebook.react.module.annotations.ReactModule

@ReactModule(name = "DeviceInfo")
class DeviceInfoModule(reactContext: ReactApplicationContext) :
  NativeDeviceInfoSpec(reactContext) {

  // Synchronous via JSI - no bridge, no JSON, no queue
  override fun getDeviceModel(): String {
    return android.os.Build.MODEL
  }

  override fun getOSVersion(): String {
    return "Android ${android.os.Build.VERSION.RELEASE}"
  }

  override fun getBatteryLevel(): Double {
    val manager = reactApplicationContext
      .getSystemService(android.content.Context.BATTERY_SERVICE)
      as android.os.BatteryManager
    return manager.getIntProperty(
      android.os.BatteryManager.BATTERY_PROPERTY_CAPACITY
    ).toDouble()
  }

  override fun getStorageUsage(
    promise: com.facebook.react.bridge.Promise
  ) {
    val stat = android.os.StatFs(
      android.os.Environment.getDataDirectory().path
    )
    val map = WritableNativeMap().apply {
      putDouble("used", (stat.totalBytes - stat.availableBytes).toDouble())
      putDouble("total", stat.totalBytes.toDouble())
    }
    promise.resolve(map)
  }

  override fun getName(): String = "DeviceInfo"
}

Le détail essentiel : getDeviceModel(), getOSVersion() et getBatteryLevel() sont synchrones. Le thread JavaScript appelle directement le code natif et reçoit la valeur de retour sur le même tick. Pas de promesses, pas de callbacks, pas d'aller-retour via le bridge. Cela n'est rendu possible que par JSI.

Mode Bridgeless : ce qu'il supprime et pourquoi c'est important

Le Mode Bridgeless, introduit dans React Native 0.73 et devenu le défaut dans la 0.74, achève la migration architecturale en supprimant entièrement l'initialisation du bridge. Même après l'adoption de Fabric et des TurboModules, l'ancien bridge s'initialisait encore au démarrage pour gérer les émetteurs d'événements globaux, les timers et la gestion des erreurs. Le Mode Bridgeless migre ces systèmes restants vers des implémentations basées sur JSI.

L'impact concret :

• Démarrage plus rapide : pas de surcoût d'initialisation du bridge. Le runtime ne démarre que ce que l'application utilise réellement grâce au chargement paresseux.
• Mémoire réduite : pas de structures de données bridge allouées au démarrage.
• Gestion d'erreurs plus propre : les error boundaries et les gestionnaires d'erreurs globaux fonctionnent via la nouvelle architecture sans recourir au bridge.

React Native 0.82 a définitivement désactivé l'ancien bridge. React Native 0.85, publié en avril 2026, a supprimé tout le code restant lié au bridge de la base de code. Il n'existe aucun chemin de repli.

Migration en production : benchmarks de performance réels

Les migrations en production de l'ancienne architecture vers la Nouvelle Architecture montrent des améliorations constantes sur les métriques clés :

| Métrique | Ancienne Architecture | Nouvelle Architecture | Amélioration | |----------|----------------------|----------------------|-------------| | Démarrage à froid (TTI) | 1,4s | 0,8s | 43 % plus rapide | | Transition d'écran | 180ms | 110ms | 39 % plus rapide | | Mémoire de base | 89 Mo | 66 Mo | 26 % de moins | | Appel JS-vers-natif | ~5ms (async) | ~0,1ms (sync) | 40x plus rapide | | Pause GC max | 45ms | 12ms | 73 % plus courte | | Défilement FlatList (1000 éléments) | Saccades occasionnelles | 60fps fluide | Aucune image perdue |

L'amélioration la plus significative pour la qualité perçue par l'utilisateur est la réduction des pauses GC. Hades maintient les pauses de collecte sous le budget d'une image (16,6 ms à 60 fps), éliminant la source la plus courante de saccades visibles dans les applications React Native complexes.

Compatibilité de l'écosystème en 2026

L'écosystème a entièrement convergé vers la Nouvelle Architecture. Expo SDK 55 et les versions ultérieures fonctionnent exclusivement sur la Nouvelle Architecture, sans option pour la désactiver. Points clés de compatibilité :

• React Navigation 7.2+ : support complet de Fabric avec les écrans native-stack
• Reanimated 3.5+ : backend d'animation partagé avec React Native 0.85
• Gesture Handler 2.16+ : reconnaissance gestuelle directe basée sur JSI
• Vision Camera 4.0+ : traitement d'images via JSI
• Detox : tests E2E compatibles avec la Nouvelle Architecture

Pour les équipes utilisant Expo, npx create-expo-app génère un projet avec la Nouvelle Architecture activée par défaut. Aucune configuration nécessaire.

Questions d'entretien : Nouvelle Architecture React Native

Ces questions apparaissent fréquemment dans les entretiens React Native de niveau senior en 2026. Chaque réponse couvre la profondeur attendue à un niveau staff/senior.

Q1 : Expliquer la différence entre l'ancien Bridge et JSI. Pourquoi JSI permet-il des appels natifs synchrones ?

Le bridge sérialisait chaque message JS-vers-natif en JSON, le poussait dans une file d'attente asynchrone et le désérialisait côté natif. JSI (JavaScript Interface) expose des objets hôtes C++ directement dans la VM JavaScript. Les fonctions natives enregistrées via JSI apparaissent comme des fonctions JavaScript ordinaires qui exécutent du code natif en ligne, sans sérialisation ni mise en file d'attente. Les appels synchrones sont possibles car JSI opère dans le même contexte de thread sans file de messages intermédiaire.

Q2 : Quel problème le moteur de rendu Fabric résout-il que Paper ne pouvait pas résoudre ?

Paper effectuait le rendu de manière asynchrone via le bridge, rendant impossible le support des fonctionnalités concurrentes de React. Un appel à startTransition n'avait aucun effet car Paper ne pouvait pas interrompre un arbre de rendu en cours de traitement. Fabric implémente le rendu en C++ partagé, s'intègre directement au réconciliateur de React 19 et supporte le rendu concurrent, Suspense et les transitions. Les calculs de mise en page via Yoga s'effectuent également de manière synchrone dans le même espace mémoire, éliminant la latence du bridge.

Q3 : Pourquoi Hermes est-il requis pour la Nouvelle Architecture ? Un autre moteur pourrait-il être utilisé ?

La Nouvelle Architecture dépend de JSI, qui nécessite que le moteur JavaScript supporte l'enregistrement d'objets hôtes C++. Hermes a été conçu dès le départ avec l'intégration JSI. JavaScriptCore pourrait théoriquement supporter JSI, mais l'implémentation officielle et les tests sont construits autour de Hermes. Hermes V1 fournit en outre la pré-compilation en bytecode (éliminant le parsing au runtime), le GC concurrent Hades (pauses sous les 12 ms) et le support WebAssembly, autant de fonctionnalités indisponibles via l'intégration JSC de React Native.

Q4 : En quoi les TurboModules diffèrent-ils de l'ancienne API NativeModules du point de vue du développeur ?

Les TurboModules requièrent une spécification Codegen (une interface TypeScript étendant TurboModule) qui génère des bindings natifs typés au moment du build. L'ancien NativeModules utilisait la réflexion au runtime sans vérification de types. Les TurboModules supportent les valeurs de retour synchrones (pas uniquement des promesses), l'initialisation paresseuse (les modules ne se chargent qu'au premier accès) et les appels JSI directs sans sérialisation JSON. Le développeur écrit une spécification TypeScript, lance Codegen et implémente l'interface native générée.

Q5 : Décrire le Mode Bridgeless et ce qu'il supprime par rapport à la seule utilisation de Fabric et TurboModules.

Même après l'adoption de Fabric et des TurboModules, l'ancien bridge s'initialisait encore au démarrage pour gérer les émetteurs d'événements globaux, les timers, la gestion des erreurs et d'autres infrastructures runtime. Le Mode Bridgeless remplace ces systèmes résiduels dépendant du bridge par des implémentations basées sur JSI. Il élimine le surcoût d'initialisation du bridge, réduit la consommation mémoire de base et garantit que l'ensemble du runtime fonctionne via JSI. Depuis React Native 0.85, le Mode Bridgeless est le seul mode opérationnel.

Pratiquer ces questions avec des exemples de code concrets renforce à la fois la compréhension conceptuelle et la mémoire pratique. Le module Nouvelle Architecture React Native de SharpSkill couvre plus de 40 questions supplémentaires sur Fabric, les TurboModules, le fonctionnement interne de Hermes et les stratégies de migration.

Conclusion

• Hermes V1 offre des démarrages à froid 29 % plus rapides, une consommation mémoire réduite de 38 % et des pauses GC inférieures à 12 ms dès React Native 0.84+
• Fabric active les fonctionnalités concurrentes de React 19 (transitions, Suspense) que Paper ne pouvait jamais supporter
• Les TurboModules éliminent la sérialisation JSON, rendant les appels JS-vers-natif 40x plus rapides grâce à l'invocation directe via JSI
• Le Mode Bridgeless supprime les dernières dépendances au bridge ; React Native 0.85 ne contient plus aucun code bridge
• L'écosystème est pleinement compatible : Expo SDK 55+, React Navigation 7.2+, Reanimated 3.5+ et toutes les bibliothèques majeures supportent exclusivement la Nouvelle Architecture
• La préparation aux entretiens doit se concentrer sur la mécanique JSI, les compromis Fabric vs Paper, le workflow Codegen des TurboModules et les changements runtime du Mode Bridgeless