Checklist des opérations de production React Native avec exemples pratiques

Introduction

La production est un autre jeu que le développement. Cette checklist opérationnelle vous donne un chemin éprouvé sur le terrain pour publier et exploiter une application en production React Native : durcir les builds, sécuriser données et paiements, ajouter la supervision, améliorer les performances, planifier les sorties, et savoir réagir aux incidents sur Android, iOS et Expo. Elle vise des opérations React Native robustes, centrées sur des exemples concrets et des étapes vérifiables.

Vue d'ensemble du flux

Adoptez un flux simple et explicite pour réduire les retours arrière et les surprises :

Planifier: définir appareils cibles, versions d'OS et métriques de succès (sessions sans crash, cold start p50, taux d'erreur, taux de succès des paiements).
Configurer: flags de release (Hermes, minification, resource shrinking, inline requires), versioning et séparation des environnements.
Sécuriser: protéger les secrets, verrouiller le transport réseau et auditer les permissions.
Instrumenter: crash reporting, gestion des erreurs JS, métriques de performance et business.
Tester: smoke tests sur appareils d'entrée et haut de gamme; sandbox de paiement; offline et réseau fluctuant.
Sortir progressivement: testeurs internes, déploiement par paliers, surveillance des tableaux de bord.
Opérer: monitoring, astreinte/ownership, sauvegardes et montées de version régulières.

Configuration et flags de build

Durcissez vos builds Release sur Android et iOS.

Général
Définir App ID/bundle ID, version semver (ex. 1.7.0) et build number.
Désactiver bibliothèques et logs réservés au debug en Release.
Séparer endpoints et clefs pour dev, staging et production.

Metro config: accélérer le démarrage en différant les requires

// metro.config.js
module.exports = {
  transformer: {
    getTransformOptions: async () => ({
      transform: { inlineRequires: true }
    })
  }
};

Android (Gradle)
Activer Hermes et R8, réduire les ressources, et splitter les ABIs pour alléger l'APK.

// android/app/build.gradle
project.ext.react = [ enableHermes: true ]
android {
  buildTypes {
    release {
      minifyEnabled true
      shrinkResources true
      proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
    }
  }
  splits {
    abi { enable true; reset(); include 'armeabi-v7a','arm64-v8a','x86_64'; universalApk false }
  }
}

Supprimer ou remplacer les logs en Release (ex. remplacer console.* via Babel en build Release ou garder des gardes).
Configurer une Network Security Config stricte; éviter le clair sauf si indispensable et strictement borné.
Activer Play App Signing et sécuriser les keystores.

iOS (Xcode)
Activer Hermes dans le Podfile si vous l'utilisez; régler les flags Release (dead code stripping, optimisation, bitcode off selon l'outillage courant).
Imposer ATS (HTTPS) avec des exceptions rares, documentées et temporaires.
Configurer provisioning et signature corrects pour Release.

Secrets et sécurité

Ne jamais embarquer de secrets longue durée dans l'app. Gardez les clefs privées côté serveur.
Stocker les tokens d'accès en stockage sécurisé:
iOS: Keychain (grouper et régler l'accessibility selon le besoin).
Android: EncryptedSharedPreferences ou stockage adossé au Keystore.
Éviter AsyncStorage pour les secrets.
Paiements
Stripe: conserver la clef publishable dans l'app, générer des clefs éphémères côté serveur. Ne pas stocker de secrets client sur l'appareil.
Google Play Billing: valider les achats côté serveur; ne jamais se baser uniquement sur le client.
Permissions: ne demander que le nécessaire; fournir une explication in-app; gérer le refus proprement.
Transport: forcer HTTPS/TLS, pinner les domaines sous votre contrôle; définir des timeouts raisonnables.

Monitoring et crash reporting

Ajouter un crash reporter (natif + JS) et des métriques de performance.
Initialiser tôt dans le cycle de démarrage et inclure release, build number, appareil, et un identifiant de session (respect de la vie privée/consentement).
Capturer les erreurs JS non gérées et les rejets:

import { setJSExceptionHandler, setNativeExceptionHandler } from 'react-native-exception-handler';

setJSExceptionHandler((e, isFatal) => {
  // envoyer vers votre service de crash
}, true);

setNativeExceptionHandler(errorString => {
  // envoyer les infos de crash natif
});

Suivre: temps de démarrage (froid/tiède), gels d'UI, échecs réseau, résultats de flux de paiement, timings de transitions d'écrans.
Alertes: seuils pour sessions sans crash, pics d'erreurs, chutes du paiement.

Performance et démarrage

Utiliser Hermes pour un démarrage plus rapide et une mémoire plus faible.
Activer inlineRequires et lazy-loader les écrans/modules lourds.
Éviter le travail coûteux au démarrage; différer analytics et fetch non critiques.
Optimiser les images: webp/avif si supportés, tailles correctes, cache.
Utiliser FlatList/SectionList avec keyExtractor, getItemLayout si possible; limiter les re-renders (memo, useCallback/useMemo avec parcimonie).

Réseau et résilience API

Définir timeouts et retries avec backoff exponentiel + jitter.

import axios from 'axios';

const api = axios.create({ baseURL: 'https://api.example.com', timeout: 10000 });

api.interceptors.response.use(undefined, async error => {
  const cfg = error.config;
  cfg.__retryCount = cfg.__retryCount || 0;
  if (cfg.__retryCount < 3 && shouldRetry(error)) {
    cfg.__retryCount++;
    await delay(Math.min(1000 * 2 ** cfg.__retryCount, 8000));
    return api(cfg);
  }
  return Promise.reject(error);
});

Employer des clefs d'idempotence pour les écritures (surtout paiements).
Support offline: mettre en cache les lectures, mettre en file les écritures, réconcilier à la reconnexion (NetInfo pour l'état réseau).
Valider SSL et appliquer ATS sur iOS. Éviter le trafic en clair; si inévitable, borner hôtes et chemins.

Paiements: Play Billing et Stripe

Google Play Billing (achats in-app/abonnements)
Utiliser la dernière BillingClient.
Gérer les états d'achat: Purchased, Pending, Unspecified; afficher une UI pour Pending (ex. paiements cash dans certaines régions).
Toujours accuser réception des achats dans le délai requis.
Vérifier les tokens côté serveur via l'API Play Developer.
Gérer upgrades/downgrades et proration des abonnements.
Tester avec comptes de licence et produits sandbox.

Stripe (cartes, wallets)
Préférer PaymentSheet pour un flux standard et sûr.
Générer des clefs éphémères côté serveur; ne jamais embarquer de clefs secrètes dans l'app.
Gérer 3DS, l'app switching et le cycle de vie Activity/UIViewController.
Utiliser des clefs d'idempotence pour PaymentIntents afin d'éviter les doublons avec les retries.
Journaliser les résultats des tentatives et les corréler avec les logs backend.

Considérations Expo

Choisir managed vs bare selon les besoins natifs.
EAS Build
Définir des profils pour développement, preview et production.
Utiliser runtime versions et channels pour segmenter les mises à jour.
Updates
Employer les OTA pour des correctifs JS/assets conformes aux politiques des stores.
Tout changement de module natif/permission requiert un nouveau build store.
Config
Garder app.json/app.config alignés avec les métadonnées du store (icônes, permissions, deep links, schemes).

Gestion de release: Android et iOS

Android
Piste de test interne pour smoke tests, test fermé pour QA élargie, puis rollout progressif (ex. 5%, 25%, 50%, 100%).
Activer Play App Signing et protections d'intégrité.
Plan de retour arrière: arrêter le déploiement ou revenir à une release antérieure.

iOS
TestFlight pour testeurs internes et externes.
Envisager un déploiement échelonné.
Renseigner les métadonnées de conformité et des descriptions de permissions précises.

Versioning et métadonnées
Utiliser semver pour la version marketing et incrémenter les build numbers.
Tenir des changelogs clairs et des notes de mise à jour utiles.

Données, stockage et sauvegardes

Classer les données: identifiants/tokens, contenus utilisateurs, cache API, analytics.
Stocker le sensible en stockage sécurisé; jamais en clair ni dans AsyncStorage.
Migrations: versionner le schéma (SQLite/KV) et tester upgrades/downgrades.
Sauvegardes Android
Contrôler Auto Backup avec un XML fullBackupContent pour exclure les chemins sensibles.
Sauvegardes iOS
Marquer les fichiers à ne pas sauvegarder avec l'attribut do-not-backup si pertinent.
Les items Keychain peuvent migrer lors de restaurations; prévoir l'invalidation des tokens.
Coordination backend: garantir sauvegardes, rétention et exercices de restauration côté serveur alignés avec le client.

Maintenance et SLO

Définir des cibles
Sessions sans crash: ex. > 99,5%.
Seuils p50/p90 de démarrage à froid.
Taux d'erreur API, taux de succès paiements.
Revues
Revue hebdo: crashes, ANR, performance.
Revue mensuelle des dépendances: sécurité et compatibilité.
Accès et clefs
Rotation régulière des identifiants et nettoyage des accès inutilisés.

Mises à niveau et compatibilité OS

Planifier des upgrades trimestriels de React Native et bibliothèques; éviter les grands sauts.
Suivre Android Gradle Plugin, Kotlin, Java, Xcode, Swift et les cibles SDK Android/iOS.
Tester sur les bêtas d'OS avant sortie publique; corriger tôt les dépréciations.
Épingler les versions d'outillage pour réduire les cassures inattendues.

Réponse aux incidents et retours arrière

Feature flags et kill switches pour désactiver des fonctionnalités risquées sans mise à jour store.
Stratégie de rollback OTA (là où autorisée) pour correctifs JS uniquement.
Contrôles des stores
Android: arrêter ou annuler un déploiement progressif dans Play Console.
iOS: retirer de la vente ou soumettre une review accélérée pour hotfixes si nécessaire.
Runbooks
Détailler les étapes en cas de panne de paiement, panne d'API, pic de crash.
Inclure points de contact, liens de logs, tableaux de bord et arbres de décision.

Plan pilote local

Démarrez petit pour vérifier vite et en sécurité.

Portée

Activer Hermes et inlineRequires.
Ajouter un crash reporting et capturer les erreurs JS non gérées.
Envelopper un appel API critique avec timeouts et backoff, plus idempotence en écriture.

Vérification

Mesurer le cold start sur deux appareils et comparer avant/après.
Déclencher une erreur JS gérée pour valider la remontée.
Simuler des pannes réseau et confirmer retries et messages à l'utilisateur.

Déploiement

Publier sur une piste interne (Android) ou TestFlight (iOS) avec 10-20 testeurs.
Critères de succès: pas de nouveaux crashes liés aux changements, amélioration du p50 de démarrage, et gestion d'erreurs API vérifiée.

Conclusion

Une release fiable découle d'opérations répétables: builds durcis, secrets sécurisés, supervision robuste, performance maîtrisée, réseau résilient, paiements prudents, et sorties disciplinées. Commencez par un pilote restreint, validez les gains, puis étendez au reste de l'app. Gardez un rythme de maintenance prévisible et entraînez-vous aux chemins de rollback avant d'en avoir besoin.