Shopify abandonne React Native : ce que ça signifie

Shopify tourne le dos à React Native. Le 10 septembre 2026, le responsable Mobile de l'entreprise, Mustafa Ali, a publié deux articles techniques annonçant que les applications Shopify sont en cours de reconstruction en Swift et Kotlin — une base de code par plateforme, à nouveau. L'application Shop a déjà été livrée en version entièrement native. L'application principale de Shopify, avec plus de 300 écrans, une application Watch et des widgets d'écran de verrouillage, est la prochaine sur la liste, et elle est attendue pour la fin de l'année.

Ce qui rend cela intéressant à lire, c'est le timing. En janvier 2025, la même personne a publié un article intitulé « Five years of React Native at Shopify » et a dit à l'industrie que si vous n'aviez pas essayé React Native depuis un moment, c'était le bon moment pour y jeter un œil. Vingt mois plus tard, il en migre. Ce n'est pas une entreprise qui s'est désenchantée d'un framework. C'est une entreprise qui a vu l'une de ses hypothèses fondamentales changer et qui a eu le courage de le dire publiquement.

L'hypothèse portait sur le coût. Shopify est passé à React Native en 2020 pour ne plus avoir à construire chaque fonctionnalité deux fois. Ali est direct : le framework a fait son travail : « Les applications React Native peuvent être rapides. Les nôtres le sont. » La raison du départ n'est pas la performance. C'est que les agents de codage IA sont devenus suffisamment bons pour que l'écriture d'une même fonctionnalité en Swift et Kotlin ne coûte plus ce qu'elle coûtait avant. Une fois qu'un agent peut prendre en charge une grande partie de la deuxième implémentation, l'argument principal en faveur d'une base de code partagée s'affaiblit, tandis que les avantages du natif — plus proche de la plateforme et moins de couches de dépendances — restent exactement là où ils étaient.

Les chiffres sont réels. Reconstruit en natif, l'application Shop a réduit le démarrage à froid de 23 % sur iOS et de 50 % sur Android. Les sessions avec plantage ont chuté d'environ dix fois, passant d'une stabilité de session de 99,5 % à 99,95 %. Les builds de release Android sont devenus environ 75 % plus rapides, le binaire Android a diminué de 109 Mo, et le fil d'actualité tient à 120 FPS lors du défilement. Six ingénieurs l'ont amené du proof of concept à l'App Store en 12 semaines, après qu'un seul ingénieur ait passé une semaine à prouver que l'idée pouvait fonctionner.

Là où nous vous ralentirions

Le titre que tout le monde a partagé est « L'IA a tué le cross-platform. » Le détail le plus utile est enfoui dans le bilan de la migration : le plus grand gain de vitesse de Shopify est venu du découplage de la logique métier de l'interface utilisateur, de sorte qu'elle s'exécute en mode headless, pilotée par un outil en ligne de commande plutôt que par un simulateur. Leurs agents pouvaient alors itérer en millisecondes au lieu de surveiller un simulateur pendant des minutes par changement. Cette astuce n'a rien à voir avec Swift ou Kotlin. Vous pouvez le faire dans React Native aujourd'hui. Poussez votre logique dans des modules simples sans imports d'interface utilisateur, exécutez-les sous Node derrière une CLI légère, et vos agents, ainsi que vos tests, bénéficient du même cycle rapide. Dans notre travail iOS et Android natif, et dans les applications de santé et d'IoT que nous avons construites où la correction importe plus que les pixels, cette séparation est le seul changement qui porte ses fruits, que des agents touchent un jour le code ou non.

Deuxième point à dire clairement : Shopify avait encore besoin d'experts natifs. Leur propre article reconnaît que le code généré a introduit des duplications, une dérive architecturale et des problèmes de performance, et que l'expertise native est restée essentielle. Le coût de deux bases de code n'a pas disparu. Il s'est déplacé de l'écriture du code à sa révision. Réviser du Swift que vous n'avez pas écrit, et savoir si c'est vraiment de qualité, c'est la partie coûteuse, et elle ne se parallélise pas de la même manière que la génération. Une startup de cinq personnes n'a pas l'équipe de révision de Shopify. Copiez la décision sans copier la capacité de révision et vous vous retrouvez avec deux bases de code et la moitié de la confiance.

Donc, le conseil concret : ne lisez pas ceci comme un signal pour réécrire quoi que ce soit. Lisez-le comme une incitation à mener une expérience. Choisissez un écran, extrayez sa logique de l'interface utilisateur dans un module headless avec ses propres tests, et mesurez à quelle vitesse vos ingénieurs et vos agents travaillent avec. C'est une journée de refactoring, c'est réversible, et cela vous en dit plus sur votre propre base de code que n'importe quelle métrique de Shopify.

Il y a aussi une leçon de sécurité plus discrète dans l'article d'Ali de 2025. Il a signalé que la dépendance de React Native aux bibliothèques tierces élargit votre surface d'attaque de la chaîne d'approvisionnement. Toujours vrai, et pas unique à React Native. Chaque projet natif s'appuie également sur des packages. Lors de nos engagements de pentest, l'arbre de dépendances est l'un des premiers endroits où nous regardons, car un package transitif compromis est un moyen d'entrée beaucoup plus courant qu'un bug dans votre propre code. Moins de couches de framework peut signifier moins de composants à auditer, mais seulement si vous suivez réellement ce que vous importez.

Rien de tout cela ne signifie que React Native est terminé. Shopify est un cas très spécifique : des applications énormes, un budget pour l'inférence IA et les réviseurs natifs, et une migration vers la Nouvelle Architecture imminente qui a rendu une reconstruction from scratch compétitive par rapport à une mise à niveau sur place. La plupart des équipes ne sont pas dans cette position. La bonne pile technologique dépend toujours de votre équipe, de vos applications et de la mesure dans laquelle vous pouvez honnêtement faire confiance à un agent pour porter la deuxième construction.

Si le choix entre natif, cross-platform ou un refactoring headless pour votre prochaine version mobile vous est familier, parlons-en. Nous avons livré des applications à la fois natives et cross-platform, et nous vous dirons franchement quand une réécriture est le mauvais choix.