Votre client demande une app iOS. Vous ouvrez la documentation d'Expo, parcourez rapidement le guide d'installation, et vous pensez : Ça ne peut pas être si difficile, non ? Trois semaines plus tard, vous déboguez une librairie de navigation à 23h, votre designer vous demande pourquoi les polices s'affichent différemment sur Android, et votre marge bénéficiaire s'est évaporée en raison de particularités propres à chaque plateforme que vous n'aviez pas facturées. J'ai appris React Native de la manière difficile — en livrant quatre projets d'agence avant de maîtriser les mathématiques du partage de code qui protègent vraiment votre calendrier. Le marché mobile de 935 milliards de dollars s'est imposé en 2025, les clients attendent désormais des apps natives aux côtés de vos builds Next.js, et si vous écrivez déjà du React, vous êtes à 68% du chemin. Mais il y a un champ de mines entre « fonctionne sur mon simulateur » et livrer des apps en production qui ne vous coûtent pas vos week-ends. C'est le playbook d'expansion que j'aurais aimé avoir en 2023 — les vrais coûts, la stack Expo + EAS Build qui vous sauve de l'enfer Xcode, et la structure de tarification qui transforme le mobile d'un risque en votre service avec la plus haute marge.

Cet article est le guide que j'aurais souhaité avoir quand nous avons commencé à prendre les clients mobiles au sérieux. Il couvre la réalité technique, l'économie commerciale, et le pipeline de déploiement dont vous aurez besoin. Pas de discours creux sur les « synergies » — juste des leçons durement gagnées en livrant des apps en production.

Table des matières

React Native for Web Agencies: Ajouter le Mobile à Votre Pratique Next.js en 2026

Pourquoi 2026 est le bon moment pour que les agences web se lancent dans le mobile

L'argument temporel ne concerne pas juste la taille du marché. Il s'agit de trois changements spécifiques qui ont convergé :

La nouvelle architecture de React Native est stable. Le rendu Fabric et TurboModules qui étaient « à venir » pendant des années sont maintenant par défaut. Les écarts de performance entre React Native et le Swift/Kotlin natif ont rétréci à une pertinence quasi nulle pour 90% des catégories d'applications. Le JSI (JavaScript Interface) signifie que vous ne traversez plus un pont pour chaque appel natif — c'est synchrone et rapide.

Expo est devenu une plateforme complète. Expo SDK 53 (sorti début 2026) supporte pratiquement toutes les API natives dont vous auriez besoin. L'époque d'éjecter d'Expo pour des fonctionnalités basiques comme Bluetooth ou la localisation en arrière-plan est révolue. EAS Build gère tout le pipeline de compilation. Vous n'avez jamais besoin de Xcode sur votre machine pour la plupart des projets.

La demande des clients a changé. Je remarque un modèle parmi les agences de notre réseau : les clients qui avaient l'habitude de demander « un site web » demandent maintenant « un produit numérique ». Ils attendent une présence web ET une app mobile, et ils s'attendent à ce qu'elles partagent un système de design. Si vous pouvez livrer les deux avec une seule équipe, vous ne concurrencez pas des boutiques web et mobile séparées — vous les remplacez toutes les deux.

Les chiffres du marché

Selon les données 2025 de Statista, le revenu mondial des apps mobiles devrait atteindre 1,1 trillion de dollars d'ici 2027. Mais plus pertinent pour les agences : le budget moyen d'une app mobile pour un client entreprise en 2026 se situe entre 150K-500K dollars pour un MVP. C'est 2-3 fois ce que la plupart des projets web d'agence commandent.

Le chevauchement de l'écosystème React : ce qui se transfère vraiment

Tuons d'abord le mythe : React Native n'est pas « juste React pour les téléphones ». Vos développeurs auront une courbe d'apprentissage. Mais c'est une courbe beaucoup plus courte que d'apprendre Swift et Kotlin à partir de zéro.

Voici une répartition honnête de ce qui se transfère et de ce qui ne se transfère pas :

Compétence/Technologie Se transfère à React Native ? Remarques
Modèles de composants React ✅ Oui, directement Hooks, context, gestion d'état — tous identiques
TypeScript ✅ Oui, directement Même langage, mêmes outils
Gestion d'état (Zustand, Jotai, Redux) ✅ Oui, directement Compatible drop-in
React Query / TanStack Query ✅ Oui, directement Même API, mêmes stratégies de mise en cache
CSS / Tailwind ⚠️ Partiellement Pas de cascade CSS. NativeWind comble cet écart
Routage Next.js ⚠️ Partiellement Expo Router est basé sur fichiers aussi, mais les paradigmes de navigation diffèrent
Manipulation du DOM ❌ Non Il n'y a pas de DOM. Point final.
Éléments HTML ❌ Non <View>, <Text>, <Pressable> à la place
API du navigateur ❌ Non Besoin de modules Expo ou modules natifs
Animations CSS ❌ Non Utilisez Reanimated 3 (qui est en réalité meilleur)

Le sweet spot est celui-ci : vos développeurs React peuvent être productifs en React Native en 2-3 semaines. Ils ne seront pas experts, mais ils peuvent livrer des fonctionnalités. C'est un énorme avantage par rapport à l'embauche de développeurs natifs.

Ce qui m'a le plus surpris

Ce qui s'est mieux transféré que prévu, c'est le modèle mental. La composition de composants de React, le flux de données unidirectionnel, et le paradigme d'interface utilisateur déclaratif — ce sont les parties difficiles à apprendre. Les différences de surface d'API (<div> vs <View>) sont triviales en comparaison.

Ce qui s'est moins bien transféré que prévu, c'est la mise en page. Oui, React Native utilise Flexbox. Mais c'est Flexbox avec flexDirection: 'column' comme défaut, pas display: grid, pas de media queries (vous utilisez useWindowDimensions), et pas de styles en cascade. Chaque développeur de notre équipe a trébuché là-dessus pendant la première semaine.

Expo en 2026 : la plateforme qui a tout changé

Si vous avez essayé React Native en 2019-2020 et avez abandonné, je comprends. L'expérience développeur était difficile. Expo a transformé cela fondamentalement.

Voici ce qu'Expo vous donne en 2026 :

  • Expo Router v4 : routage basé sur fichiers qui reflète les conventions Next.js. Vos devs se sentiront immédiatement chez eux.
  • API Expo Modules : écrivez des modules natifs en Swift/Kotlin avec une interface TypeScript propre. Plus de code de pont bâclé.
  • EAS Build : constructions basées sur le cloud pour iOS et Android. Pas besoin de Mac pour les builds iOS.
  • EAS Submit : envois automatisés à l'App Store et au Play Store.
  • EAS Update : mises à jour over-the-air qui contournent la révision de l'app store pour les changements JS uniquement.
  • Expo Dev Client : des builds de développement personnalisées qui incluent vos modules natifs mais conservent l'expérience DX fast refresh.
# Création d'un nouveau projet Expo en 2026
npx create-expo-app@latest my-app --template tabs
cd my-app
npx expo start

C'est tout. Vous exécutez le simulateur iOS et l'émulateur Android (ou appareils physiques via Expo Go) en moins de deux minutes.

Expo Router : le pont depuis Next.js

Expo Router mérite une attention particulière car c'est la raison unique la plus importante pour laquelle les développeurs Next.js s'adaptent rapidement. Regardez la structure :

app/
  (tabs)/
    index.tsx        # Onglet Accueil
    settings.tsx     # Onglet Paramètres
    _layout.tsx      # Disposition des onglets
  profile/
    [id].tsx         # Route dynamique
  _layout.tsx        # Disposition racine

Si vous construisez avec Next.js App Router, cette structure est presque identique. Routes dynamiques, layouts, navigation imbriquée — les concepts se mappent directement. La principale différence est que la navigation mobile utilise des piles et des onglets au lieu de pages et de chemins d'URL, mais Expo Router abstrait cela magnifiquement.

React Native for Web Agencies: Ajouter le Mobile à Votre Pratique Next.js en 2026 - architecture

Partage de code entre Next.js et React Native

C'est ici que les agences obtiennent le vrai ROI. Partager le code entre le web et le mobile n'est pas juste un plus — c'est la justification économique pour offrir les deux services.

Quoi partager

Partagez agressivement :

  • Logique métier et utilitaires
  • Clients API et hooks de récupération de données
  • Stores de gestion d'état
  • Définitions de types et schémas de validation (Zod fonctionne bien ici)
  • Logique d'authentification

Partagez avec prudence :

  • Tokens de design (couleurs, espacement, échelles typographiques)
  • Logique de composant (mais pas rendu de composant)

Ne partagez pas :

  • Composants d'interface utilisateur directement (les primitives de rendu sont différentes)
  • Logique de navigation
  • Animations spécifiques à la plateforme

Configuration du monorepo

L'approche standard en 2026 est un monorepo Turborepo ou Nx. Voici une structure typique :

packages/
  shared/
    src/
      hooks/
        useAuth.ts
        useProducts.ts
      utils/
        formatCurrency.ts
        validateEmail.ts
      types/
        user.ts
        product.ts
      api/
        client.ts
apps/
  web/          # App Next.js
  mobile/       # App Expo

// packages/shared/src/hooks/useProducts.ts
import { useQuery } from '@tanstack/react-query';
import { apiClient } from '../api/client';
import type { Product } from '../types/product';

export function useProducts(categoryId: string) {
  return useQuery<Product[]>({
    queryKey: ['products', categoryId],
    queryFn: () => apiClient.get(`/products?category=${categoryId}`),
    staleTime: 5 * 60 * 1000,
  });
}

Ce hook fonctionne de manière identique dans votre app Next.js et votre app React Native. La récupération de données, la mise en cache et la gestion d'état sont complètement partagées. Seule la couche UI qui affiche les produits diffère.

L'approche Solito / Universelle

Pour les agences qui veulent pousser le partage de code encore plus loin, Solito (par Fernando Rojo) permet la navigation universelle et certains composants partagés entre Next.js et Expo. En 2026, la librairie React Native react-native-web est également suffisamment mature pour le partage de système de design, bien que je recommande cela uniquement pour les équipes qui ont livré au moins un projet React Native. Cela ajoute de la complexité.

Notre ratio de partage de code typique : 40-60% du codebase total est partagé entre le web et le mobile. Ce n'est pas de la poudre aux yeux — c'est mesuré sur six projets clients.

EAS Build et déploiement : votre pipeline CI/CD

Le déploiement est l'endroit où le développement mobile a historiquement été difficile. Signature d'application, profils de provisioning, conformité de l'App Store — c'est un labyrinthe. EAS le rend gérable.

Tarification EAS Build (2026)

Plan Prix Crédits de build/mois Vitesse de build
Gratuit 0$ 30 iOS + 30 Android ~40 min par build
Production 99$/mois 200 total ~15 min par build
Entreprise 999$/mois Illimité ~8 min par build (priorité)

Pour la plupart des agences, le plan Production est le sweet spot. Vous épuiserez rapidement les crédits du niveau gratuit une fois que vous avez plus d'un projet actif.

Un vrai pipeline CI/CD

Voici le pipeline que nous utilisons, et il a bien fonctionné sur plusieurs projets clients :

# .github/workflows/mobile-deploy.yml
name: Mobile Deploy
on:
  push:
    branches: [main]
    paths:
      - 'apps/mobile/**'
      - 'packages/shared/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx eas-cli build --platform all --non-interactive --profile production
        env:
          EXPO_TOKEN: ${{ secrets.EXPO_TOKEN }}

  submit:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx eas-cli submit --platform all --non-interactive
        env:
          EXPO_TOKEN: ${{ secrets.EXPO_TOKEN }}

Pour les mises à jour JavaScript uniquement qui ne touchent pas le code natif, utilisez EAS Update à la place d'une build complète :

# Poussez une mise à jour OTA — les utilisateurs l'obtiennent au prochain lancement de l'app
eas update --branch production --message "Corriger l'alignement du bouton de paiement"

C'est énorme pour les agences. Les correctifs de bugs qui prendraient 1-3 jours en attente de révision de l'App Store atteindront désormais les utilisateurs en minutes.

Économie d'agence : tarification, effectifs et marges

Parlons argent. C'est là que je vois les agences commettre les plus grandes erreurs.

Tarification des projets mobiles

Ne tarifiez pas les projets mobiles comme les projets web. Ils sont plus coûteux à construire, plus coûteux à maintenir, et sont assortis de coûts de plateforme continus. Voici ce qui a fonctionné pour nous :

Type de projet Taux d'agence typique Calendrier Plage totale
App simple (contenu, auth, CRUD basique) 180-250$/h 8-12 semaines 90K-180K$
App moyenne (paiements, temps réel, intégrations) 180-250$/h 12-20 semaines 180K-400K$
App complexe (offline-first, fonctionnalités natives lourdes) 200-300$/h 20-32 semaines 350K-750K$
Bundle Web + Mobile (codebase partagée) 180-250$/h 16-28 semaines 250K-550K$

Le bundle web + mobile est votre arme concurrentielle. Un client obtenant les deux pour 350K$ obtient une meilleure affaire que de payer 200K$ pour le web et 300K$ pour le mobile à des boutiques séparées. Et vos marges sont meilleures grâce au partage de code.

Modèle de personnel

Vous n'avez pas besoin d'embaucher des développeurs mobiles dédiés immédiatement. Voici la progression qui fonctionne :

  1. Phase 1 (premier projet mobile) : Votre développeur React senior dirige, avec un contractant ayant expérience React Native comme guide. Budget 15-25K$ pour le contractant.
  2. Phase 2 (2-3 projets dans) : Votre équipe a assez d'expérience. Embauchez un développeur avec un solide antécédent React Native pour être le leader mobile.
  3. Phase 3 (le mobile représente 30%+ du revenu) : Construisez un pod mobile dédié de 2-3 développeurs.

Le flux de revenu de maintenance

Voici ce que personne ne vous dit sur le mobile : cela nécessite une maintenance continue même si le client n'ajoute pas de fonctionnalités. iOS et Android sortent des versions majeures annuellement. Les dépendances ont besoin de mises à jour. Les politiques de l'App Store changent. C'est un revenu récurrent.

Nous facturons 3 000-8 000$/mois pour les contrats de maintenance d'app mobile selon la complexité de l'app. Sur 8-10 clients, c'est un revenu récurrent significatif qui lisse la volatilité des revenus basés sur des projets.

Quand dire oui (et non) aux clients mobiles

Tous les projets mobiles ne sont pas adaptés à votre agence. J'ai appris cela de la manière difficile.

Dites oui quand :

  • Le client a déjà un produit web que vous avez construit — vous connaissez le domaine, l'API, la logique métier. Vous êtes à 40% du travail avant le jour un.
  • L'app est principalement basée sur les données — Apps CRUD, tableaux de bord, e-commerce, livraison de contenu. React Native excelle là.
  • Le client a des délais réalistes — 8 semaines minimum pour quelque chose de significatif.
  • Le budget est de 80K$+ — En dessous, vous ne pouvez pas livrer la qualité et maintenir les marges.

Dites non quand :

  • L'app nécessite une intégration GPU/graphiques lourde — Jeux, expériences AR, 3D complexe. Utilisez Unity ou natif.
  • L'app a besoin d'intégration matérielle approfondie — Périphériques Bluetooth LE, pipelines de caméra personnalisés, traitement de paiement NFC. Possible en React Native, mais le développement de module natif dépassera votre budget.
  • Le client veut un design « pixel-perfect native » de plateforme — S'ils veulent que leur app iOS sente exactement comme une app SwiftUI et leur app Android sente exactement comme Jetpack Compose, React Native ajoute de la surcharge.
  • Le budget est inférieur à 50K$ — Vous perdrez de l'argent. Renvoyez-les à un freelancer ou une plateforme no-code.
  • Le client n'a pas d'API — Si vous devez construire le backend, l'app mobile, ET une app web, délimitez soigneusement. Ce sont trois projets, pas un.

Coûts d'ingénierie : les chiffres dont personne ne parle

Au-delà des salaires des développeurs, le mobile ajoute des coûts que les agences web ne considèrent pas :

Coût Montant annuel Remarques
Compte développeur Apple 99$/an par client Requis pour l'App Store
Compte développeur Google Play 25$ une seule fois par client Requis pour le Play Store
EAS Build (Production) 1 188$/an Partagé sur les projets
Captures d'écran App Store & assets 500-2 000$ par app Souvent oubliées dans le périmètre
Labo de test d'appareils 2 000-5 000$/an Appareils physiques ou BrowserStack
Service de notification push 0-500$/mois Firebase est gratuit pour commencer, puis augmente
Certificats de signature de code Inclus dans le compte Apple Dev Mais les gérer prend du temps
Optimisation App Store 500-2 000$/lancement Si vous faites cela pour les clients

Le coût sournois est le test sur appareils réels. Les simulateurs mentent. Nous maintenons un labo de test avec 6 iPhones (différents modèles) et 4 appareils Android (Samsung, Pixel, un téléphone bon marché pour tester les performances). Budgétisez cela.

Coûts en temps

L'avis de révision de l'App Store prend 24-48 heures généralement, mais peut prendre une semaine pendant les vacances. L'avis du Play Store est généralement plus rapide (heures à un jour). Prenez cela en compte dans vos calendriers de projet — vous ne pouvez pas juste « déployer le vendredi » comme vous le faites avec les apps web.

Les premières soumissions d'app prennent plus de temps. Apple en particulier examine les nouveaux comptes développeur. Nous avons eu des premières soumissions prendre 5-7 jours avec des cycles de rejet-resoumission.

Un parcours de migration pratique pour les agences web

Si vous êtes convaincu d'ajouter le mobile à votre pratique, voici le chemin que je recommande :

Mois 1-2 : Projet interne Constituez une app simple interne utilisant Expo. Un suivi du temps, un tableau de bord de projet, peu importe. Familiarisez votre équipe avec les outils sans pression client. Utilisez cela pour mettre en place votre structure de monorepo, votre pipeline CI/CD, et votre processus de test d'appareils.

Mois 3-4 : Upsell client existant Abordez votre meilleur client existant sur une app mobile compagne. Vous connaissez déjà leur domaine, leur API, leur équipe. Offrez-la à un léger rabais en échange d'être un cas de référence.

Mois 5-8 : Premier client mobile externe Acceptez un projet mobile avec un périmètre réaliste. Limitez-le à 12 semaines max. Utilisez votre projet interne et le premier projet client comme preuve de capacité.

Mois 9+ : Productionisez Créez un modèle de projet mobile standard, une feuille de calcul d'estimation, et un processus d'intégration. C'est quand le mobile devient une vraie ligne de service, pas une expérience.

Tout au long de ce processus, investissez dans vos capacités de CMS headless — les apps mobiles pilotées par contenu qui tirent du même CMS que le web sont l'un des bundles de plus haute valeur que vous pouvez offrir aux clients.

Recommandation de stack technologique

Pour les agences commençant en 2026, voici le stack sur lequel je parierais :

  • Expo SDK 53+ avec Expo Router v4
  • NativeWind v4 pour le style (Tailwind CSS pour React Native)
  • TanStack Query pour l'état du serveur
  • Zustand pour l'état client
  • React Native Reanimated 3 pour les animations
  • Turborepo pour la gestion du monorepo
  • EAS Build + EAS Update pour CI/CD

Si votre pratique web utilise Astro au lieu de Next.js, la stratégie de partage de code fonctionne toujours — vous partagez juste la couche de données et les packages de logique métier plutôt que les composants React.

FAQ

Combien de temps faut-il pour qu'un développeur React/Next.js devienne productif en React Native ?

En fonction de notre expérience de montée en charge de cinq développeurs web, attendez-vous à 2-3 semaines pour une productivité basique (peut construire des écrans et implémenter des fonctionnalités) et 2-3 mois pour ce que j'appellerais une indépendance confiante (peut architecturer des fonctionnalités, déboguer des problèmes natifs, gérer les cas limites spécifiques à la plateforme). La courbe d'apprentissage initiale concerne surtout les modèles de navigation, les conventions UX spécifiques au mobile, et les différences de style.

Puis-je utiliser les mêmes composants dans Next.js et React Native ?

Pas directement — les primitives de rendu sont différentes (<div> vs <View>, <span> vs <Text>). Cependant, vous pouvez partager la logique de composant via des hooks personnalisés, partager les tokens de design, et utiliser des librairies comme Solito ou react-native-web pour combler l'écart. En pratique, nous partageons 40-60% du code total entre les plateformes, principalement le code de logique métier et de couche de données.

Combien coûte la maintenance d'une app React Native annuellement ?

Pour une app de complexité moyenne typique, attendez-vous à 36K-96K$/année en coûts de maintenance. Cela couvre les mises à jour de compatibilité OS (iOS et Android sortent des versions majeures annuellement), les mises à jour de dépendances, les corrections de bugs, les petits ajouts de fonctionnalités, et la conformité aux politiques de l'App Store. C'est un vrai coût que les clients doivent budgétiser.

React Native est-il assez rapide pour les apps en production en 2026 ?

Oui, définitivement. Avec la nouvelle architecture (Fabric + TurboModules + JSI) maintenant par défaut, les apps React Native atteignent 60fps de manière cohérente pour l'UI standard. Les apps comme Discord, Shopify Shop, et Coinbase utilisent React Native à grande échelle. L'écart de performance avec le natif est négligeable pour 90%+ des catégories d'apps. Où cela stagne toujours, c'est l'animation lourde ou les charges de travail intensives en GPU.

Devrais-je utiliser Expo ou React Native brut ?

Expo. Ce n'est même pas une question proche en 2026. Expo supporte pratiquement toutes les APIs natives, l'API Expo Modules vous permet d'écrire du code natif personnalisé si nécessaire, et EAS Build élimine les maux de tête de la chaîne d'outils native. Le vieux conseil d'« éjecter d'Expo si vous avez besoin de X » est dépassé. Environ 85-90% des apps React Native en production utilisent maintenant Expo, y compris les apps majeures.

Quelle est l'équipe minimale viable pour un projet mobile ?

Deux développeurs et un designer qui comprend les conventions mobiles. Un développeur doit avoir une expérience React Native (même si via votre projet de formation interne). Vous pouvez augmenter à partir de là, mais faire un projet mobile client en solo est risqué — il y a trop de connaissances spécifiques à la plateforme nécessaires. Pour votre premier projet, envisagez un contractant React Native à temps partiel comme filet de sécurité.

Comment gérer les soumissions App Store et les révisions ?

EAS Submit automatise le processus de chargement binaire. Mais vous devrez toujours gérer manuellement App Store Connect et Google Play Console pour les métadonnées, captures d'écran, déclarations de confidentialité, et les réponses de révision. Le processus de révision d'Apple prend 24-48 heures généralement. Budget 1-2 semaines pour les premières soumissions en raison des rejets potentiels. Les raisons de rejet courantes : politique de confidentialité manquante, fonctionnalité de connexion inadéquate, et métadonnées incomplètes.

Cela vaut-il le coup d'offrir le développement mobile si nous n'avons que 5-10 développeurs ?

Absolument — c'est en réalité la taille idéale pour commencer. Vous n'avez pas besoin d'une équipe mobile dédiée dès le départ. Commencez par former 2-3 de vos plus forts développeurs React, acceptez un projet mobile à la fois, et grandissez à partir de là. Le partage de code entre le web et le mobile signifie que votre équipe n'est pas divisée — ils travaillent sur les plateformes avec des fondations partagées. Consultez notre page de tarification ou contactez-nous directement si vous voulez discuter de la façon dont d'autres agences de taille similaire ont effectué cette transition.