L'essentiel
En 2026, Expo n'est plus une simple surcouche simplifiée de React Native : c'est devenu la méthode recommandée par Meta pour démarrer un projet. Expo SDK 52, sorti en décembre 2025, embarque EAS Build (compilation cloud), EAS Update (OTA sans repasser par les stores), expo-router v4 (navigation fichier-based inspirée de Next.js) et plus de 60 packages natifs pré-intégrés.
Le bare workflow (CLI classique npx react-native init) reste pertinent pour les projets nécessitant des modules natifs non supportés par Expo, une intégration profonde avec des SDK propriétaires (SDK bancaire, IoT industriel) ou un contrôle total sur les builds Xcode et Gradle.
Chez Nehos, 70 % de nos nouveaux projets React Native utilisent désormais Expo managed workflow avec des ejections ponctuelles via les Config Plugins. Les 30 % restants démarrent en bare workflow pour des raisons d'intégration SDK spécifiques.
Le choix entre Expo et bare workflow impacte surtout la vélocité de développement (Expo accélère de 25 à 40 % les premières semaines) et la complexité de la CI/CD. Il n'impacte pas significativement les performances finales de l'application.
React Native avec ou sans Expo : quelle différence concrète en 2026 ?
Expo SDK 52 simplifie radicalement le développement React Native, mais le bare workflow garde des atouts décisifs pour certains projets. EAS Build, OTA updates, expo-router, modules natifs : le comparatif complet pour faire le bon choix.
Adapté à toute taille de structure
En 2026, démarrer un projet React Native pose immédiatement une question structurante : utiliser Expo ou partir en bare workflow avec la CLI classique ? Ce choix conditionne votre pipeline de build, votre accès aux modules natifs, votre vitesse d'itération et votre autonomie sur la CI/CD. Après plus de 40 projets React Native livrés chez Nehos, voici notre retour d'expérience complet.
#Expo en 2026 : bien plus qu'un outil pour débutants
Expo a longtemps souffert d'une réputation réductrice : un outil pour prototyper rapidement, mais inadapté aux projets sérieux. Cette perception est obsolète depuis Expo SDK 49 (2023) et l'introduction des Config Plugins. En 2026, avec le SDK 52, Expo est devenu l'approche recommandée par Meta pour la majorité des projets React Native.
Les composants clés d'Expo SDK 52 :
EAS Build (Expo Application Services) remplace la nécessité d'installer Xcode et Android Studio en local. Les builds iOS et Android sont exécutés dans le cloud d'Expo. Un développeur Windows peut builder une app iOS sans posséder de Mac. Le temps de build moyen est de 8 à 12 minutes pour une app de taille moyenne, contre 15 à 25 minutes en local sur un MacBook Pro M3.
EAS Update permet de déployer des mises à jour JavaScript Over-The-Air (OTA) sans repasser par la review de l'App Store ou du Play Store. Concrètement, un correctif de bug ou une modification d'interface peut être en production en 5 minutes au lieu de 24 à 48 heures. Cette fonctionnalité est conforme aux guidelines Apple et Google à condition de ne pas modifier le code natif ni le comportement fondamental de l'application.
expo-router v4 apporte un système de navigation basé sur le système de fichiers, inspiré de Next.js App Router. Chaque fichier dans le dossier app/ devient une route. Les layouts imbriqués, le deep linking et le typage TypeScript des routes sont natifs. Pour les équipes venant du web React/Next.js, c'est un gain de productivité considérable : la structure du projet est immédiatement lisible.
60+ packages natifs pré-intégrés couvrent les besoins les plus courants : caméra (expo-camera), géolocalisation (expo-location), notifications push (expo-notifications), stockage sécurisé (expo-secure-store), biométrie (expo-local-authentication), partage (expo-sharing), fichiers (expo-file-system). Ces packages sont maintenus directement par l'équipe Expo et garantis compatibles entre eux à chaque version du SDK.
#Le bare workflow : contrôle total sur le natif
Le bare workflow correspond à la commande classique npx react-native init MonProjet. Vous obtenez un projet avec les dossiers ios/ et android/ exposés, et un contrôle total sur les fichiers natifs Xcode (.xcworkspace, Podfile) et Gradle (build.gradle, AndroidManifest.xml).
Quand le bare workflow est nécessaire :
Intégration de SDK natifs propriétaires. Certains SDK B2B ne fournissent qu'un .framework iOS ou un .aar Android sans wrapper JavaScript. C'est fréquent dans la banque (SDK d'authentification forte), l'industrie (SDK IoT de capteurs spécifiques) et la santé (SDK de dispositifs médicaux connectés). En bare workflow, vous écrivez directement le bridge natif en Objective-C/Swift ou Java/Kotlin.
Configuration native avancée. Certains projets exigent des modifications profondes du AppDelegate.swift, du MainActivity.kt, des entitlements iOS (App Groups, HealthKit, CarPlay) ou de la configuration ProGuard Android. En bare workflow, ces fichiers sont directement éditables.
Builds sur infrastructure propre. Les entreprises avec des contraintes de sécurité (secteur défense, finance réglementée) exigent parfois que le code source ne quitte jamais leur infrastructure. EAS Build envoie le code sur les serveurs Expo pour la compilation, ce qui est incompatible avec ces contraintes. Le bare workflow permet des builds 100 % on-premise via Fastlane + Jenkins/GitLab CI.
#Tableau comparatif : Expo managed vs bare workflow
| Critère | Expo managed (SDK 52) | Bare workflow (CLI) | Avantage |
|---|---|---|---|
| Temps de setup initial | 5 minutes | 30–60 minutes | Expo |
| Build iOS sans Mac | Oui (EAS Build cloud) | Non (Xcode requis) | Expo |
| Mises à jour OTA | Oui (EAS Update natif) | Possible (CodePush, custom) | Expo |
| Navigation fichier-based | Oui (expo-router v4) | Non (React Navigation manuelle) | Expo |
| Accès modules natifs custom | Config Plugins + dev clients | Direct (bridge natif) | Bare |
| SDK propriétaires (.framework, .aar) | Complexe (Config Plugins) | Simple (édition directe) | Bare |
| Builds on-premise | Non | Oui (Fastlane, Jenkins) | Bare |
| Configuration Xcode/Gradle directe | Non (abstrait par Expo) | Oui | Bare |
| Taille bundle finale | Identique* | Identique* | Égalité |
| Performances runtime | Identique | Identique | Égalité |
| Temps moyen premier build | 10 min (cloud) | 20 min (local) | Expo |
| Mise à jour React Native | Automatique (SDK bump) | Manuelle (react-native upgrade) | Expo |
*Depuis Expo SDK 50, le tree-shaking supprime les packages non utilisés du bundle final.
#Les Config Plugins : le meilleur des deux mondes
Les Config Plugins sont la fonctionnalité qui a transformé Expo d'un outil limité en une plateforme complète. Un Config Plugin est un script JavaScript qui modifie les fichiers natifs iOS et Android au moment du build, sans que le développeur ait besoin de toucher directement ces fichiers.
Exemple concret : pour intégrer Firebase Cloud Messaging dans un projet Expo, vous installez @react-native-firebase/messaging et son Config Plugin. Au build, le plugin modifie automatiquement le Podfile iOS, le build.gradle Android, l'AppDelegate et le google-services.json. Sans Config Plugin, ces 4 modifications doivent être faites manuellement.
Chez Nehos, nous avons écrit des Config Plugins custom pour des cas spécifiques : intégration d'un SDK de signature électronique pour un client notarial, configuration d'entitlements Apple Pay pour une app de paiement B2B, et ajout d'un module Bluetooth Low Energy pour une application de maintenance industrielle. Le temps de développement d'un Config Plugin custom est de 2 à 8 heures selon la complexité.
#Expo Development Builds : tester le natif sans éjecter
Les Development Builds (anciennement appelés « custom dev clients ») permettent de créer une version de développement de l'application qui inclut des modules natifs custom tout en restant dans l'écosystème Expo. C'est une alternative à l'éjection complète.
Le workflow : vous créez un Development Build avec EAS (eas build --profile development), vous l'installez sur votre appareil ou simulateur, puis vous continuez à développer avec le rechargement rapide d'Expo Go. La différence : votre Development Build inclut les modules natifs que vous avez ajoutés, contrairement à Expo Go qui est limité aux packages inclus dans le SDK.
Cette approche élimine 90 % des cas où l'éjection était nécessaire il y a encore deux ans. Chez Nehos, nous n'éjectons plus que pour les 3 cas mentionnés plus haut (SDK propriétaires lourds, config native très avancée, builds on-premise obligatoires).
→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.
#Performances : Expo vs bare workflow en production
Nos mesures sur des applications déployées en production montrent que les performances sont identiques entre Expo managed et bare workflow. C'est logique : au moment du build, Expo produit exactement le même binaire natif qu'un projet bare workflow. Expo est un outil de développement, pas un runtime.
→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.
Benchmarks Nehos (Samsung Galaxy A55, iPhone 13) :
- Temps de démarrage à froid : 1,58 s (Expo) vs 1,61 s (bare) sur Android — différence non significative
- FPS scroll liste 500 items : 52 fps (Expo) vs 52 fps (bare) — identique
- Taille APK : 14,2 MB (Expo) vs 14,0 MB (bare) — écart de 1,4 %, non significatif
- Consommation RAM après 10 min usage : 142 MB (Expo) vs 140 MB (bare) — identique
La seule différence mesurable concerne le temps de build CI/CD : EAS Build est 15 à 20 % plus lent qu'un build local optimisé sur une machine dédiée (Mac Mini M2 avec cache Gradle/CocoaPods warm). Mais EAS Build est 30 à 40 % plus rapide qu'un build CI classique sur GitHub Actions runners standard.
#Quand choisir Expo : les 5 signaux décisifs
1. L'équipe vient du web React/Next.js. Expo-router, le hot reload instantané et l'abstraction des fichiers natifs permettent à un développeur React web de livrer des fonctionnalités mobiles dès la première semaine. En bare workflow, les mêmes développeurs passent 2 à 3 semaines à comprendre la chaîne de build native.
2. Le projet est un MVP avec timeline serrée. Expo réduit le temps de setup de 2 jours à 30 minutes. Sur un projet MVP de 8 semaines, cela représente un gain de 5 % du budget total — soit 1 500 à 3 000 euros sur un projet à 30-60K euros.
3. Les mises à jour fréquentes sont critiques. Les applications B2B avec des règles métier qui changent souvent (promotions, tarifs, workflows d'approbation) bénéficient massivement d'EAS Update. Un correctif peut être en production en 5 minutes sans review store.
4. L'équipe n'a pas de Mac pour le développement iOS. EAS Build permet de compiler pour iOS depuis Windows ou Linux. C'est un avantage pragmatique pour les équipes distribuées ou les entreprises qui n'équipent pas tous les développeurs en Mac.
5. Le projet cible des fonctionnalités couvertes par les packages Expo. Si votre application utilise principalement la caméra, la géolocalisation, les notifications, le stockage local et des API REST, les packages Expo couvrent 100 % des besoins sans aucun code natif.
#Quand choisir le bare workflow : les 4 cas irréductibles
1. SDK natifs propriétaires sans wrapper JS. Si votre client impose l'intégration d'un SDK fourni uniquement en .framework (iOS) ou .aar (Android) sans documentation JavaScript, le bare workflow permet d'écrire le bridge natif directement. Les Config Plugins ne suffisent pas quand le SDK nécessite des modifications du cycle de vie de l'application (AppDelegate, Application class).
2. Builds sur infrastructure on-premise obligatoires. Pour les secteurs réglementés (défense, finance, santé HDS), le code source ne doit pas transiter par des serveurs tiers. EAS Build est incompatible avec cette contrainte. Le bare workflow + Fastlane + serveur de build interne est la seule option.
3. Configuration native très spécifique. App Clips iOS, Widgets iOS 17+, CarPlay, WatchOS companion, Android Auto : ces fonctionnalités nécessitent une configuration native avancée que les Config Plugins ne couvrent pas encore complètement.
4. Migration d'une app React Native existante en bare. Si vous maintenez déjà une application React Native en bare workflow depuis plusieurs années, la migration vers Expo managed est possible mais coûteuse (2 à 4 semaines de travail). Le ROI n'est positif que si le projet a encore plus de 18 mois de développement devant lui.
#Notre recommandation Nehos pour 2026
Pour les nouveaux projets React Native en 2026, nous recommandons de démarrer avec Expo managed workflow par défaut. Si un besoin natif spécifique se présente en cours de projet, les Config Plugins et Development Builds permettent d'y répondre sans éjection dans 90 % des cas.
L'éjection vers le bare workflow n'est plus un aller sans retour comme c'était le cas avant 2024. Avec les Development Builds, vous gardez les avantages d'Expo (EAS Build, EAS Update, expo-router) tout en ayant accès au code natif quand c'est nécessaire.
Pour un accompagnement sur le choix de votre architecture React Native, consultez notre page développement d'applications mobiles ou notre comparatif Flutter vs React Native 2026.
Découvrez l'ensemble de nos services de développement et nos expertises en agents IA pour enrichir vos applications mobiles avec de l'intelligence artificielle.
Pour évaluer le budget de votre projet mobile, consultez notre guide combien coûte une application mobile sur mesure en 2026.