Audit d’une app React Native : quoi vérifier, combien de temps, quels livrables

On demande un audit quand quelque chose inquiète : un taux de sessions sans crash qui recule, une montée de version qui bloque, une app héritée d’un prestataire, une levée de fonds qui approche. L’audit n’a qu’un but : vous permettre de décider. Ce guide décrit ce qu’il doit couvrir point par point, avec les références officielles qui fixent les exigences, ce que vous pouvez vérifier vous-même avant de payer quiconque, les livrables à exiger et les signaux d’alerte dans une offre.

Ce que doit couvrir un audit

Domaine	Ce qu’on vérifie	Référence
Versions et montée	Version de React Native ou du SDK Expo, écart avec les versions maintenues, chemin de montée	Releases React Native (nouvelle fenêtre)
New Architecture	Activation, compatibilité de chaque librairie, modules natifs maison	React Native 0.82 (nouvelle fenêtre)
Dépendances	Failles connues, libs archivées ou non maintenues, versions non alignées sur le SDK Expo, patches	React Native Directory (nouvelle fenêtre), Expo Doctor (nouvelle fenêtre)
Modules natifs	Code Swift, Objective-C, Kotlin ou Java maison, SDK tiers, config plugins	Lecture du code
Build et CI	Reproductibilité, versions de Xcode et du JDK, EAS ou CI maison, signature, temps de build	Exigences Apple (nouvelle fenêtre)
Mises à jour OTA	Canal, runtime version, stratégie de rollback	Runtime versions Expo (nouvelle fenêtre)
Performance	Démarrage à froid, navigation, listes, réseau, taille du bundle, sur build de production	Performance React Native (nouvelle fenêtre)
Crashs et observabilité	Crash reporter, symbolication, taux de crash et d’ANR	Android vitals (nouvelle fenêtre)
Sécurité de base	Secrets dans le bundle, stockage des tokens, variables publiques	Sécurité React Native (nouvelle fenêtre)
Conformité stores	SDK cible, API à justification obligatoire, suppression de compte	Target API Google Play (nouvelle fenêtre), App Review Guidelines (nouvelle fenêtre)
Code et tests	Structure, frontières entre modules, tests sur les parcours critiques	Lecture du code

Versions et chemin de montée

L’équipe React Native s’engage à maintenir (nouvelle fenêtre) « the latest 3 minor series », avec une nouvelle version mineure environ tous les deux mois. Une version plus ancienne ne reçoit plus de correctifs. L’audit doit dire où vous en êtes, quelle cible viser, et par quels paliers passer. L’Upgrade Helper (nouvelle fenêtre) montre le diff des fichiers natifs entre deux versions ; sur Expo, chaque SDK cible une version de React Native.

New Architecture

Depuis React Native 0.82 (nouvelle fenêtre) (8 octobre 2025), la New Architecture est la seule : newArchEnabled=false et RCT_NEW_ARCH_ENABLED=0 sont ignorés. L’équipe recommande de passer d’abord par React Native 0.81 ou Expo SDK 54, « the last versions that allow you to use the Legacy Architecture ». Pour une app encore sur l’ancienne architecture, c’est souvent le chantier principal, et l’audit doit lister les librairies et modules natifs qui le bloquent.

Santé des dépendances

C’est la partie la plus mécanique, et celle que vous pouvez faire vous-même (voir plus bas). L’audit va plus loin : il regarde les patches appliqués avec patch-package, les forks internes, et les dépendances natives transitives. React Native Directory (nouvelle fenêtre) recensait fin octobre 2026 environ 2 800 packages, dont 71 % compatibles New Architecture : environ trois librairies sur dix ne le sont pas ou ne l’ont pas déclaré.

Modules natifs, build et CI

Le code natif maison est souvent ce qui coûte le plus cher en montée de version. L’audit l’inventorie, vérifie qu’il tourne sur la New Architecture, et regarde s’il pourrait devenir un config plugin ou un Expo Module. Côté build, la question est simple : un nouveau développeur peut-il produire un build de release depuis une machine neuve, et la CI le fait-elle sans intervention ? Les versions d’outils comptent : depuis le 28 avril 2026, Apple exige (nouvelle fenêtre) que les apps soient « built with Xcode 26 or later using an SDK for iOS 26 ». À partir d’avril 2027, ce sera le SDK iOS 27, avec une migration obligatoire vers le cycle de vie UIScene : voir notre guide Xcode 27.

Si l’app utilise les mises à jour OTA, l’audit vérifie la runtime version. Expo la décrit comme la propriété qui « guarantees compatibility between a build’s native code and an update » ; une runtime version qui ne suit pas les changements natifs envoie du JavaScript sur un build qui ne peut pas l’exécuter.

Performance

Une mesure en mode développement ne vaut rien. La documentation React Native (nouvelle fenêtre) est claire : « JavaScript thread performance suffers greatly when running in dev mode », et « Always make sure to test performance in release builds ». L’audit mesure donc sur un build de production, sur de vrais téléphones, y compris des Android d’entrée de gamme : démarrage à froid, navigation, listes longues, requêtes réseau, taille du bundle. La même page rappelle que les console.log laissés dans un bundle de production « can cause a big bottleneck in the JavaScript thread ».

Crashs et observabilité

Un crash reporter doit être en place et ses traces symbolisées sur les deux plateformes. Côté Android, Google publie des seuils : dans Android vitals (nouvelle fenêtre) (page mise à jour le 19 octobre 2026), le taux de crash perçu par les utilisateurs doit rester sous 1,09 % en moyenne et sous 8 % par modèle de téléphone, le taux d’ANR sous 0,47 % et 8 %. Au-delà, « Play may reduce the visibility of your title ». L’audit relève ces chiffres et les relie à leurs causes.

Sécurité de base

Un audit d’app n’est pas un test d’intrusion, mais il doit vérifier les bases. La documentation React Native (nouvelle fenêtre) est explicite : « Never store sensitive API keys in your app code », car tout ce qui est dans le bundle peut être lu en clair. Async Storage est « unencrypted » et ne doit pas contenir de tokens ; il faut un stockage sécurisé comme expo-secure-store, qui s’appuie sur le Keychain iOS et sur des clés protégées par le Keystore Android. Sur Expo, les variables EXPO_PUBLIC_ sont visibles (nouvelle fenêtre) « in plain-text in your compiled application ». Ce sont les erreurs que l’on retrouve le plus souvent dans les apps générées trop vite.

Conformité aux stores

Les exigences bougent chaque année, et une vieille version de React Native finit par ne plus passer. Depuis le 31 août 2026, Google Play exige (nouvelle fenêtre) que les nouvelles apps et mises à jour ciblent Android 16 (API 36). Depuis le 1er mai 2024, Apple demande (nouvelle fenêtre) de justifier l’usage de certaines API, « including from third-party SDKs ». Et la règle 5.1.1(v) des App Review Guidelines (nouvelle fenêtre) impose, si l’app permet de créer un compte, d’en permettre la suppression depuis l’app.

Qualité du code et tests

C’est ce qui détermine le coût de chaque évolution future. L’audit regarde les frontières entre modules, la gestion de l’état, la duplication, et surtout l’existence de tests sur les parcours critiques : connexion, paiement, données. Une app sans tests n’est pas forcément mauvaise, mais chaque correction y est un pari.

Vous auto-évaluer avant de payer

Une partie de l’audit est automatisable, et vous pouvez la faire avant d’appeler qui que ce soit.

1. Lancer notre audit de stack gratuit. Collez votre package.json, ajoutez votre lockfile pour des versions exactes : en 30 secondes, il signale les failles connues, les mises à jour majeures en retard, les libs archivées ou non maintenues, la compatibilité New Architecture selon React Native Directory, une partie des vérifications d’Expo Doctor et l’âge de vos dépendances en libyears. Rien n’est conservé.
2. Sur un projet Expo, lancer npx expo-doctor. L’outil sert à diagnostiquer les problèmes d’un projet Expo et peut vérifier vos packages (nouvelle fenêtre) auprès de React Native Directory. npx expo install --fix réaligne les versions sur votre SDK.
3. Comparer votre version aux versions maintenues sur la page des releases (nouvelle fenêtre).
4. Ouvrir Android vitals et les rapports de crash des trente derniers jours, et noter les trois crashs les plus fréquents.
5. Chercher des secrets dans le code : clés d’API, tokens, URL d’administration, variables EXPO_PUBLIC_ sensibles.
6. Produire un build de release depuis une machine neuve, en suivant uniquement la documentation du repo.

Si tout est vert, vous partez d’une bonne base ; restent la performance sur de vrais appareils, l’architecture et la priorisation, que cette liste ne couvre pas. Si plusieurs points sont rouges, vous saurez au moins quoi demander.

Combien de temps prévoir

La durée dépend de la taille de l’app, du nombre de plateformes et de repos, et de l’état de la CI : il faut pouvoir produire un build de production pour mesurer. Il n’existe pas de norme publique ; voici comment raisonner.

Un audit doit laisser le temps de trois choses distinctes. Lire le code et son historique, pour comprendre comment l’app a été construite et où sont les zones fragiles. Mesurer, sur un build de release et sur de vrais appareils, ce que vivent les utilisateurs. Écrire, enfin, un document qui classe et chiffre, et le présenter à l’équipe. Un audit qui saute l’une de ces étapes rend un avis, pas un diagnostic.

Chez useffect.sh, le format est fixe : cinq jours avec un senior. Le premier jour sert aux accès et à la lecture de l’historique, les jours deux à quatre au profiling sur build de production et à la revue de l’architecture, des dépendances, de la sécurité et du pipeline de release, et le cinquième au diagnostic écrit et à la restitution. Le périmètre couvert (plateformes, repos) se cadre en 30 minutes d’échange, avant de commencer.

Les livrables à exiger

Un audit utile se termine par un document court, pas par un export de linter. Exigez :

• Un diagnostic écrit, lisible par un fondateur comme par un développeur.
• Des risques classés par impact et par effort, pas une liste à plat.
• Des mesures de performance sur build de production, avec les appareils utilisés.
• Une revue des dépendances et le chemin de montée de version.
• Des options chiffrées, de la correction ciblée à la reprise complète.
• Une restitution orale avec votre équipe, questions comprises.

C’est exactement le format de notre audit d’application React Native : cinq jours, un senior dans votre repo en lecture seule, un diagnostic de trois pages maximum, risques classés, options chiffrées et restitution orale. Le document vous appartient, quelle que soit la suite.

Les signaux d’alerte dans une offre d’audit

• Pas d’accès au code. Un audit sur entretiens et captures d’écran est un avis, pas un diagnostic.
• Pas de mesure sur build de production. Une performance mesurée en mode développement ne dit rien de ce que vivent vos utilisateurs.
• Un rapport de cinquante pages. Personne ne le lira. La valeur est dans le classement, pas dans l’exhaustivité.
• Une conclusion connue d’avance. Si l’offre annonce déjà une réécriture avant d’avoir lu le code, la conclusion n’est pas un diagnostic.
• Pas de nom. Vous devez savoir quel ingénieur lira votre code, et quelle est son expérience React Native et native.
• Pas d’engagement de confidentialité. NDA avant tout accès, et des règles claires sur l’usage d’outils d’IA avec votre code.
• Un document inutilisable sans l’auditeur. Un bon diagnostic se transmet à votre équipe ou à un autre prestataire.

Sources

• React Native, releases et politique de support (nouvelle fenêtre), mis à jour le 27 juillet 2026
• React Native 0.82 (nouvelle fenêtre), 8 octobre 2025
• React Native, performance (nouvelle fenêtre) et sécurité (nouvelle fenêtre)
• Upgrade Helper (nouvelle fenêtre)
• React Native Directory (nouvelle fenêtre), consulté le 27 octobre 2026
• Expo, outils de développement (Expo Doctor) (nouvelle fenêtre), New Architecture et React Native Directory (nouvelle fenêtre), variables d’environnement (nouvelle fenêtre), runtime versions (nouvelle fenêtre)
• Android vitals (nouvelle fenêtre), mis à jour le 19 octobre 2026
• Google Play, exigences de target API (nouvelle fenêtre), mis à jour le 16 octobre 2026
• Apple, upcoming requirements (nouvelle fenêtre), consulté le 27 octobre 2026
• Apple, App Review Guidelines (nouvelle fenêtre), consulté le 27 octobre 2026