Migrer une app native vers React Native : cinq questions

Réponse courte

Migrer une application Swift ou Kotlin vers React Native se décide sur les coûts futurs, la capacité de l'équipe à livrer et le périmètre à reconstruire. Si l'app native fonctionne, reste maintenable et ne bloque pas la roadmap, garde-la. Si deux équipes refont les mêmes parcours et que les changements deviennent trop lents, une refonte ciblée mérite un audit. Le brief situe une migration de taille moyenne entre 20 000 et 80 000 € HT et sur plusieurs mois, selon le code à conserver et les intégrations. Ces montants sont des repères, pas un devis automatique. Inyka chiffre après examen des parcours et des dépendances natives.

Première question : quel coût veux-tu vraiment réduire ?

Une facture de maintenance élevée ne prouve pas que Swift ou Kotlin sont en cause. Elle peut venir d'un backend instable, de tests absents, d'une dette produit ou d'un prestataire difficile à remplacer. Migrer l'interface ne corrigera pas une API qui tombe chaque semaine.

Écris d'abord le coût actuel sur une période comparable : maintenance iOS, maintenance Android, corrections répétées, délais de publication et fonctionnalités bloquées. Distingue ce qui touche le client mobile de ce qui restera identique après la migration. Si une seule plateforme sert la majorité des usages et avance vite, je garderais le natif jusqu'à ce qu'un problème précis apparaisse. Deux bases de code ne coûtent cher que si elles imposent réellement deux développements et deux maintenances.

Le calcul d'amortissement doit comparer dépenses et délais futurs, pas seulement le coût du nouveau projet. Un changement de stack crée lui aussi une période où l'ancien produit doit rester entretenu. Notre article sur le coût de maintenance d'une app mobile aide à établir cette ligne de départ.

Deuxième question : l'équipe peut-elle encore livrer ?

Le problème peut être le recrutement, la transmission ou la dépendance à une seule personne. Note combien de temps prend une correction ordinaire, combien de développeurs savent publier l'app et qui peut intervenir si le responsable actuel part. Ces réponses valent plus qu'une statistique générale sur le marché du recrutement.

React Native peut rapprocher les compétences autour de TypeScript et partager des composants ou une logique entre iOS et Android. Cela n'efface pas les besoins de connaissances natives. Les notifications, achats intégrés, permissions et modules spécifiques demandent encore des vérifications sur chaque système. Une équipe qui ignore ces sujets remplacera une dépendance par une autre.

Je migrerais si le manque de capacité bloque régulièrement des fonctions attendues et si l'entreprise est prête à investir dans une base commune maintenue. Si l'équipe native reste disponible et livre vite, la migration cherche un bénéfice hypothétique. Le choix entre React Native et Flutter vient seulement après cette décision.

Troisième question : les parcours iOS et Android divergent-ils ?

Deux applications peuvent avoir le même logo et vivre à des rythmes différents. Compare les fonctions ouvertes sur iOS et Android, les bugs encore actifs, les écarts de navigation et les dates de sortie. Si chaque nouveau parcours est conçu, développé et corrigé deux fois, une base React Native commune peut simplifier le travail produit.

Ne déduis pas pour autant qu'une base commune produit des interfaces identiques sans effort. Les comportements système, les permissions et les achats doivent être testés séparément. Le bon objectif est un même contrat fonctionnel, avec les ajustements nécessaires à chaque plateforme.

Un tableau d'écarts fait gagner du temps au cadrage. Pour chaque fonction, note « identique », « différent pour une raison produit » ou « différent par retard ». Les différences voulues restent dans le cahier des charges. Les retards, eux, sont une occasion de réduire le périmètre. Refaire toutes les fonctions héritées sans examen ramène les mêmes lenteurs dans une nouvelle stack.

Quatrième question : que partage-t-on avec le backend et le back-office ?

React Native n'absorbe pas magiquement un back-office web existant. Les interfaces restent différentes. En revanche, certains types, règles de validation et appels API peuvent être partagés si l'architecture s'y prête. Le gain doit être prouvé module par module.

Commence par identifier les données dont la définition diverge aujourd'hui : statuts de commande, rôles, champs de profil ou règles de prix. Si le mobile et le back-office ne s'accordent pas sur ces notions, une migration de l'app seule ne suffit pas. Il faut clarifier le contrat de données. Un backend stable peut rester en place pendant que le client mobile change.

Inyka livre un back-office seulement lorsqu'il accompagne une application mobile. Si le besoin principal est de refaire un logiciel web autonome, ce n'est pas le bon périmètre. La méthode de cadrage d'un MVP mobile sert à choisir ce qui doit vraiment entrer dans la nouvelle app.

Cinquième question : quelles fonctions exigent du natif spécifique ?

Avant de promettre un calendrier, liste les SDK propriétaires, appareils connectés, tâches en arrière-plan, vidéo, cartes, capteurs et achats intégrés. Une bibliothèque React Native maintenue peut couvrir certains besoins. D'autres demandent un module natif ou rendent la migration peu intéressante. Le devis doit nommer ces dépendances et prévoir une preuve technique pour les plus risquées.

La taille du dépôt n'est pas un raccourci fiable. Cent écrans simples peuvent être plus faciles à refaire qu'un petit module de communication avec un appareil médical ou industriel. Le critère est la complexité des comportements qu'il faut préserver, pas un seuil arbitraire de lignes de code.

Inyka travaille avec React Native et Expo. Expo peut intégrer du code natif quand le projet le demande, mais une fonctionnalité native nouvelle implique un build adapté. Les mises à jour EAS doivent rester compatibles avec le code natif déjà installé. Notre comparaison Expo et React Native bare aide à discuter cette contrainte sans slogans.

Trois chemins de migration

Chemin	Quand l'envisager	Risque principal
Refonte complète de l'app	Périmètre resserré et peu de modules natifs spécifiques	Régressions sur des habitudes installées
Ajout progressif d'écrans React Native	App native vaste qui doit continuer à évoluer	Cohabitation technique à maintenir
Nouvelle app à côté	Produit et parcours à revoir en profondeur	Deux versions actives pendant la transition

La documentation React Native décrit l'intégration de nouveaux écrans dans une app native existante. Cela rend l'approche progressive possible, pas automatiquement simple. Elle exige un plan d'architecture, de tests et de publication des deux parties.

Le bon choix dépend aussi des utilisateurs actifs. Une app déjà publiée avec abonnements et données ne se remplace pas comme un prototype. Il faut maintenir les comptes et mesurer les régressions, puis préparer une bascule ou une mise à jour. Pour une app neuve sans base active, une refonte complète peut être plus lisible.

Ce que le devis doit contenir

Une migration n'est pas une « conversion » automatique de Swift ou Kotlin vers TypeScript. Le devis doit lister les parcours à garder, les fonctions supprimées, les interfaces avec le backend, les modules natifs, les tests sur appareils et le mode de publication. Ajoute une ligne pour la période pendant laquelle l'app actuelle et la nouvelle coexistent.

Le brief avance 20 000 à 80 000 € HT comme fourchette de discussion pour une migration de taille moyenne. Une app simple et un système avec plusieurs SDK spécifiques ne peuvent pas partager le même forfait. L'offre Scale d'Inyka débute à 24 000 € HT, puis le prix se fixe après cadrage. Le guide du prix d'une application mobile donne les bases pour lire les postes du devis.

Demande surtout un critère de sortie : quels parcours doivent fonctionner, sur quels appareils et avec quelles données avant l'arrêt de l'ancien code ? Une date sans ces preuves invite à publier trop tôt.

Les erreurs qui font déraper la refonte

Promettre une équivalence sans inventaire. « Refaire la même app » laisse de côté des états peu visibles : lien profond, reprise après interruption, refus de permission ou retour d'un paiement. Dresse une liste de parcours observables et donne à chacun un résultat attendu.

Sous-estimer la publication. Une app peut fonctionner sur un téléphone de test et échouer à la revue store ou à la signature du build. Vérifie tôt les comptes, identifiants, certificats et réglages de confidentialité.

Traiter les modules natifs à la fin. Un SDK matériel ou une tâche en arrière-plan peut imposer une architecture différente. Fais un prototype de la dépendance la plus risquée avant de promettre un forfait global.

Remplacer les tests par la comparaison visuelle. Deux écrans semblables peuvent calculer des droits différents ou perdre un brouillon. La recette doit comparer les sorties du métier et les états de données, pas seulement les pixels.

Couper l'ancien code dès la première sortie. Des utilisateurs actifs restent parfois sur un ancien build. Définis les versions supportées, les messages de mise à jour et la date de retrait à partir des usages constatés.

Ce qu'Inyka refuse dans une migration native

• Un devis fixe sur une grande base inconnue sans phase de lecture et de preuve technique. Les dépendances natives doivent être nommées avant le prix.
• Une promesse de performance identique sur tout appareil et toute fonction sans mesure. On teste les parcours exigeants sur les terminaux visés.
• Une conversion ligne à ligne de Swift ou Kotlin. La nouvelle application doit conserver le comportement utile, pas reproduire la structure de l'ancien dépôt.
• Une refonte native pure hors du périmètre React Native et Expo, ou un produit soumis aux exclusions certifiées d'Inyka.

Checklist de décision avant le lancement du chantier

Cette vérification tient en une réunion de cadrage si les personnes qui connaissent l'app sont présentes :

1. Les coûts de maintenance iOS, Android et backend sont séparés.
2. Les blocages de livraison sont illustrés par des demandes récentes.
3. Les différences voulues entre plateformes sont documentées.
4. Les parcours que l'on retire ont un propriétaire qui valide la décision.
5. Chaque SDK natif, capteur et tâche de fond a un responsable technique.
6. Le backend actuel a un contrat d'API et un environnement de test.
7. Les achats et abonnements existants ont un plan de continuité.
8. Le build de référence peut être installé et testé sur de vrais appareils.
9. Les comptes store et les identifiants d'app sont sous contrôle du propriétaire.
10. Les critères de sortie incluent tests, données et support après publication.

Si plusieurs réponses manquent, le premier achat doit être un audit limité, pas la refonte entière. Le rapport peut ensuite comparer maintien du natif, migration progressive et nouvelle app sur le même périmètre. Cette comparaison est plus utile qu'un argument général sur la popularité des frameworks.

FAQ

Une app React Native sera-t-elle moins performante ? La réponse dépend du parcours. Une interface métier classique peut fonctionner très bien ; un traitement très spécifique ou un rendu exigeant demande une preuve sur appareil avant engagement.

Peut-on garder le même compte App Store ? Oui, si le propriétaire contrôle la fiche existante et publie une mise à jour compatible. La migration de technologie ne demande pas, à elle seule, une nouvelle fiche.

Doit-on refaire le backend ? Non si ses API, données et règles tiennent le nouveau produit. Une migration mobile peut même servir à stabiliser d'abord le contrat avec un backend déjà utile.

React Native peut-il cohabiter avec Swift ou Kotlin ? Oui. C'est une approche documentée, mais elle ajoute du travail d'intégration et de maintenance pendant la transition.

Quand refuser la migration ? Quand le natif livre vite, que le problème principal est ailleurs ou qu'un module matériel spécifique ferait du nouveau client un projet disproportionné.

Que faire des fonctionnalités que plus personne n'utilise ? Vérifie leur usage et leur rôle avant de les retirer. Certaines fonctions rares, comme la récupération de compte, restent nécessaires malgré peu d'ouvertures.

Peut-on sortir iOS avant Android ? Oui si le plan de publication et de données supporte deux versions de client pendant un temps. Il faut définir les fonctions disponibles et le support de chaque plateforme.

Qui maintient l'ancien code pendant la migration ? Nomme une personne ou une équipe pour les incidents de production. Le budget de transition doit inclure cette maintenance, même si le nouveau développement avance ailleurs.

Trancher sur le produit existant

Si ton application native coûte du temps sans faire avancer la roadmap, cadre sa migration avec Inyka. Apporte un build, la liste des parcours, les coûts de maintenance et les dépendances natives : ce sont les éléments qui rendent la décision défendable.

Réserver un appel découverte de 30 minutes pour comparer la situation actuelle aux chemins de migration possibles.