Soyons honnêtes : il y a trois ans, j'aurais dit à toute agence web me posant des questions sur le mobile de simplement construire une PWA et c'est tout. Ce conseil a mal vieilli. Le marché des applications mobiles a atteint 935 milliards de dollars de revenus en 2025, les attentes des clients ont changé de manière drastique, et React Native est devenu quelque chose que j'aime vraiment utiliser. Si votre agence construit déjà avec Next.js et React, vous disposez d'une mine d'or de compétences transférables. Mais il y a de vrais pièges, et je suis tombé dans la plupart d'entre eux pour que vous n'ayez pas à le faire.

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

Table des matières

React Native pour les agences web : ajouter le mobile à votre pratique Next.js en 2026

Pourquoi 2026 est le bon moment pour que les agences web passent au mobile

L'argument du timing n'est pas seulement une question de taille de marché. C'est à propos de trois changements spécifiques qui ont convergé :

La New Architecture de React Native est stable. Le renderer Fabric et TurboModules qui arrivent « bientôt » depuis des années sont maintenant le standard. Les écarts de performance entre React Native et le Swift/Kotlin natif se sont réduits à un niveau quasi-négligeable pour 90 % des catégories d'applications. La JSI (JavaScript Interface) signifie que vous ne franchissez plus un pont pour chaque appel natif — c'est synchrone et rapide.

Expo est devenu une plateforme complète. Expo SDK 53 (libéré début 2026) supporte pratiquement chaque API native dont vous auriez besoin. Le temps d'éjecter d'Expo pour des fonctionnalités basiques comme Bluetooth ou la localisation en arrière-plan est révolu. 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 vois un motif à travers les agences de notre réseau : les clients qui avaient l'habitude de demander « un site web » demandent maintenant un « produit numérique ». Ils s'attendent à une présence web ET une application mobile, et ils s'attendent à ce qu'elles partagent un système de design. Si vous pouvez livrer les deux à partir d'une seule équipe, vous ne concurrencez pas les magasins web et mobiles séparés — vous les remplacez tous les deux.

Les chiffres du marché

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

Le chevauchement de l'écosystème React : ce qui transfère réellement

Tuons d'abord le mythe : React Native n'est pas « simplement 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 transfère et ce qui ne transfère pas :

Compétence/Technologie Transfère vers React Native ? Notes
Motifs de composants React ✅ Oui, directement Hooks, context, gestion d'état — tous identiques
TypeScript ✅ Oui, directement Même langage, même outillage
Gestion d'état (Zustand, Jotai, Redux) ✅ Oui, directement Compatible d'usine
React Query / TanStack Query ✅ Oui, directement Même API, mêmes stratégies de cache
CSS / Tailwind ⚠️ Partiellement Pas de cascade CSS. NativeWind comble ce fossé
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 navigateur ❌ Non Besoin de modules Expo ou de modules natifs
Animations CSS ❌ Non Utilisez Reanimated 3 (qui est en fait mieux)

Le sweet spot est celui-ci : vos développeurs React peuvent être productifs en React Native en 2-3 semaines. Ils ne seront pas des 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 surpris le plus

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

Ce qui a transféré moins bien que je m'y attendais était la mise en page. Oui, React Native utilise Flexbox. Mais c'est Flexbox avec flexDirection: 'column' par défaut, pas de display: grid, pas de media queries (vous utilisez useWindowDimensions), et pas de styles en cascade. Chaque développeur de notre équipe a trébuché sur cela la première semaine.

Expo en 2026 : la plateforme qui a tout changé

Si vous avez essayé React Native en 2019-2020 et vous avez renoncé, je comprends. L'expérience développeur était rude. 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 de Next.js. Vos développeurs se sentiront immédiatement à la maison.
  • API des modules Expo : écrivez des modules natifs en Swift/Kotlin avec une interface TypeScript propre. Pas plus de code de pont janky.
  • EAS Build : constructions basées sur le cloud pour iOS et Android. Mac non requiert pour les constructions iOS.
  • EAS Submit : soumissions automatisées à l'App Store et au Google Play Store.
  • EAS Update : mises à jour over-the-air qui contournent l'examen de l'app store pour les modifications JS uniquement.
  • Expo Dev Client : constructions de développement personnalisées qui incluent vos modules natifs tout en conservant l'expérience développeur avec rafraîchissement rapide.
# Créer 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 fonctionnez sur le simulateur iOS et l'émulateur Android (ou les 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 seule raison la plus importante pour laquelle les développeurs Next.js s'adaptent rapidement. Regardez la structure :

app/
  (tabs)/
    index.tsx        # Onglet d'accueil
    settings.tsx     # Onglet Paramètres
    _layout.tsx      # Mise en page des onglets
  profile/
    [id].tsx         # Route dynamique
  _layout.tsx        # Mise en page racine

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

React Native pour les agences web : ajouter le mobile à votre pratique Next.js en 2026 - architecture

Partage de code entre Next.js et React Native

C'est là que les agences obtiennent le vrai retour sur investissement. Le partage de code entre le web et le mobile n'est pas seulement agréable à avoir — 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
  • Magasins de gestion d'état
  • Définitions de types et schémas de validation (Zod fonctionne très bien ici)
  • Logique d'authentification

Partagez avec prudence :

  • Jetons de design (couleurs, espacement, échelles typographiques)
  • Logique de composant (mais pas le 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/          # Application Next.js
  mobile/       # Application 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 application Next.js et votre application 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 d'interface utilisateur qui rend les produits diffère.

L'approche Solito / Universal

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 bibliothèque react-native-web de React Native est également suffisamment mature pour le partage de système de design, bien que je recommande cela uniquement pour les équipes qui ont expédié au moins un projet React Native. Cela ajoute de la complexité.

Notre ratio de partage de code typique : 40-60 % de la base de code totale est partagé entre le web et le mobile. Ce n'est pas du battage publicitaire — c'est mesuré sur six projets clients.

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

Le déploiement est là où le développement mobile a toujours été douloureux. Signature d'application, profils de provisionnement, conformité de l'App Store — c'est un labyrinthe. EAS le rend gérable.

Tarification d'EAS Build (2026)

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

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

Un pipeline CI/CD réel

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 au code natif, utilisez EAS Update au lieu d'une construction complète :

# Poussez une mise à jour OTA — les utilisateurs l'obtiennent au prochain lancement de l'application
eas update --branch production --message "Fix checkout button alignment"

C'est énorme pour les agences. Les corrections de bogues qui prendraient 1-3 jours en attente d'examen de l'App Store atteindront maintenant les utilisateurs en quelques minutes.

Économie des agences : tarification, personnel et marges

Parlons argent. C'est là que je vois les agences faire 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 s'accompagnent de coûts de plateforme continus. Voici ce qui a bien fonctionné :

Type de projet Taux d'agence typique Chronologie Plage totale
Application simple (contenu, authentification, CRUD basique) 180-250 $/h 8-12 semaines 90 K$-180 K$
Application moyenne (paiements, temps réel, intégrations) 180-250 $/h 12-20 semaines 180 K$-400 K$
Application complexe (hors ligne en premier, fonctionnalités natives lourdes) 200-300 $/h 20-32 semaines 350 K$-750 K$
Bundle Web + Mobile (base de code partagée) 180-250 $/h 16-28 semaines 250 K$-550 K$

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

Modèle de dotation

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 entrepreneur qui a de l'expérience en React Native comme guide. Budget 15-25 K$ pour l'entrepreneur.
  2. Phase 2 (2-3 projets) : votre équipe a suffisamment d'expérience. Embauchez un développeur avec un solide antécédent React Native pour être le responsable mobile.
  3. Phase 3 (le mobile représente 30 %+ du chiffre d'affaires) : construisez un pod mobile dédié de 2-3 développeurs.

Le flux de revenus 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 libèrent des versions majeures du système d'exploitation chaque année. 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 retenues de maintenance des applications mobiles selon la complexité de l'application. Sur 8-10 clients, c'est un revenu récurrent significatif qui lisse la volatilité des revenus basés sur projet.

Quand dire oui (et non) aux clients mobiles

Tous les projets mobiles ne conviennent pas à votre agence. Je l'ai appris de la manière la plus 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 chemin avant le premier jour.
  • L'application est principalement axée sur les données — applications CRUD, tableaux de bord, commerce électronique, livraison de contenu. React Native excelle ici.
  • Le client a des chronologies réalistes — minimum 8 semaines pour quelque chose de significatif.
  • Le budget est 80 K$+ — En dessous, vous ne pouvez pas fournir de qualité et maintenir les marges.

Dites non quand :

  • L'application nécessite des graphiques GPU/lourds — Jeux, expériences AR, 3D complexe. Utilisez Unity ou natif.
  • L'application a besoin d'une intégration matérielle profonde — Périphériques Bluetooth LE, pipelines de caméra personnalisés, traitement des paiements NFC. Possible en React Native, mais le développement du module natif explosera votre budget.
  • Le client veut un design « pixel-perfect natif de plateforme » — S'ils veulent que leur application iOS se sente exactement comme une application SwiftUI et que leur application Android se sente exactement comme Jetpack Compose, React Native ajoute une surcharge.
  • Le budget est inférieur à 50 K$ — Vous perdrez de l'argent. Renvoyez-les à un freelancer ou à une plateforme sans code.
  • Le client n'a pas d'API — Si vous devez construire le backend, l'application mobile ET une application web, limitez le périmètre avec soin. C'est 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 Notes
Compte développeur Apple 99 $/an par client Requis pour l'App Store
Compte développeur Google Play 25 $ forfait par client Requis pour le Google Play Store
EAS Build (Production) 1 188 $/an Partagé entre les projets
Captures d'écran et actifs de l'App Store 500-2 000 $ par application Souvent oublié dans la délimitation du périmètre
Laboratoire de test d'appareil 2 000-5 000 $/an Appareils physiques ou BrowserStack
Service de notification push 0-500 $/mois Firebase est gratuit au départ, augmente avec l'échelle
Certificats de signature de code Inclus dans le compte développeur Apple Mais les gérer prend du temps
Optimisation de l'App Store 500-2 000 $/lancement Si vous faites cela pour les clients

Le coût sournois est les tests sur les appareils réels. Les simulateurs mentent. Nous maintenons un laboratoire d'appareils avec 6 iPhones (différents modèles) et 4 appareils Android (Samsung, Pixel, un téléphone bon marché pour les tests de performance). Budget pour cela.

Coûts de temps

L'examen de l'App Store prend 24-48 heures généralement, mais peut prendre une semaine pendant les périodes de vacances. L'examen du Google Play Store est généralement plus rapide (heures à un jour). Tenez compte de cela dans les chronologies de votre projet — vous ne pouvez pas simplement « déployer vendredi » comme vous le faites avec les applications web.

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

Un chemin de migration pratique pour les agences web

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

Mois 1-2 : Projet interne Construisez une application interne simple en utilisant Expo. Un suivi du temps, un tableau de bord de projet, ce que vous voulez. Faites que votre équipe se familiarise avec l'outillage sans pression client. Utilisez ceci pour configurer votre structure de monorepo, votre pipeline CI/CD et votre processus de test d'appareils.

Mois 3-4 : Vente incitative au client existant Approchez votre meilleur client existant au sujet d'une application mobile compagnon. Vous connaissez déjà leur domaine, leur API, leur équipe. Proposez-le à un léger rabais en échange d'être un cas de référence.

Mois 5-8 : Premier client mobile externe Prenez un projet mobile avec une portée réaliste. Gardez-le à maximum 12 semaines. Utilisez votre projet interne et le premier projet client comme preuve de capacité.

Mois 9+: Productiser Créez un modèle de projet mobile standard, un tableur 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 système de gestion de contenu découplé — les applications mobiles axées sur le contenu qui tirent du même système de gestion de contenu que le web sont l'un des bundles de plus haute valeur que vous pouvez offrir aux clients.

Recommandation de pile technologique

Pour les agences commençant en 2026, voici la pile sur laquelle je parierais :

  • Expo SDK 53+ avec Expo Router v4
  • NativeWind v4 pour la stylisation (Tailwind CSS pour React Native)
  • TanStack Query pour l'état du serveur
  • Zustand pour l'état du 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 simplement la couche de données et les paquets de logique métier plutôt que les composants React.

FAQ

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

Sur la base de notre expérience d'intégration de cinq développeurs web, attendez-vous à 2-3 semaines pour la productivité de base (peut construire des écrans et implémenter des fonctionnalités) et 2-3 mois pour ce que j'appellerais l'indépendance confiante (peut architecturer des fonctionnalités, déboguer les problèmes natifs, gérer les cas limites spécifiques à la plateforme). La courbe d'apprentissage initiale concerne surtout les motifs de navigation, les conventions d'expérience utilisateur spécifiques au mobile et les différences de stylisation.

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 des jetons de design et utiliser des bibliothèques comme Solito ou react-native-web pour combler le fossé. En pratique, nous partageons 40-60 % du code total entre les plates-formes, principalement la logique métier et le code de la couche de données.

Combien coûte la maintenance d'une application React Native chaque année ?

Pour une application de complexité moyenne typique, attendez-vous à 36 K$-96 K$ par an en coûts de maintenance. Cela couvre les mises à jour de compatibilité du système d'exploitation (iOS et Android libèrent des versions majeures chaque année), les mises à jour de dépendances, les corrections de bogues, les petits ajouts de fonctionnalités et la conformité aux politiques de l'App Store. C'est un coût réel que les clients doivent budgéter.

React Native est-il suffisamment rapide pour les applications de production en 2026 ?

Oui, définitivement. Avec la New Architecture (Fabric + TurboModules + JSI) maintenant par défaut, les applications React Native atteignent 60 images par seconde de manière cohérente pour l'interface utilisateur standard. Des applications comme Discord, Shopify Shop et Coinbase utilisent React Native à grande échelle. L'écart de performance avec natif est négligeable pour 90 %+ des catégories d'applications. Où cela lague encore est pour les animations lourdes ou les charges de travail intensives en GPU.

Dois-je utiliser Expo ou bare React Native ?

Expo. Ce n'est même pas un appel proche en 2026. Expo supporte pratiquement chaque API native, l'API des modules Expo 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. L'ancien conseil de « éjecter d'Expo si vous avez besoin de X » est dépassé. Environ 85-90 % des applications React Native de production utilisent maintenant Expo, y compris les applications majeures.

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

Deux développeurs et un designer qui comprend les conventions mobiles. L'un des développeurs devrait avoir de l'expérience en React Native (même 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. Pour votre premier projet, envisagez un entrepreneur React Native à temps partiel comme filet de sécurité.

Comment gérer les soumissions et les examens de l'App Store ?

EAS Submit automatise le processus de téléchargement binaire. Mais vous devrez toujours gérer manuellement App Store Connect et Google Play Console pour les métadonnées, les captures d'écran, les déclarations de confidentialité et les réponses d'examen. Le processus d'examen 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.

Vaut-il la peine d'offrir le développement mobile si nous n'avons que 5-10 développeurs ?

Absolument — c'est en fait la taille idéale pour commencer. Vous n'avez pas besoin d'une équipe mobile dédiée dès le premier jour. Commencez par former 2-3 de vos développeurs React les plus forts, prenez un projet mobile à la fois et développez à 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 plates-formes avec des fondations partagées. Consultez notre page de tarification ou contactez-nous directement si vous souhaitez discuter de la manière dont les autres agences de taille similaire ont effectué cette transition.