Choisir un socle technique est devenu la partie la plus facile d'un projet de développement d'application mobile, et la plus mal arbitrée. En 2026, Flutter, React Native et Kotlin Multiplatform produisent tous une application d'entreprise crédible sur les deux magasins. La vraie question s'est déplacée : combien de temps votre application restera-t-elle exploitable sans que personne n'y touche, et qui saura la reprendre dans trois ans.

Ce qui a bougé en 2026 sur les trois socles

Les événements qui comptent pour une PME ne sont pas des nouveautés fonctionnelles, mais des changements de gouvernance et de cycle de vie.

React Native a quitté Meta. Le 24 février 2026, la React Foundation a été officiellement lancée sous l'égide de la Linux Foundation. React, React Native et les projets associés comme JSX ne sont plus la propriété de Meta. La fondation compte huit membres fondateurs de rang Platinum, dont Amazon, Microsoft, Vercel et Meta, et la direction technique reste entre les mains des mainteneurs. Pour un dirigeant, c'est une bonne nouvelle de fond : le socle ne dépend plus des arbitrages d'une seule entreprise.

La version 0.84 a accéléré le nettoyage. Publiée le 11 février 2026, elle fait de Hermes V1 le moteur JavaScript par défaut, livre des binaires iOS précompilés et retire du build iOS le code de l'ancienne architecture. Elle exige aussi Node.js 22.11 au minimum. Le détail qui vous concerne se trouve en fin de note de version : à sa sortie, la branche 0.81 est passée non supportée.

Flutter termine ses grands chantiers. La feuille de route 2026, publiée le même 24 février, annonce l'achèvement de la migration vers le moteur de rendu Impeller sur Android, avec le retrait de Skia sur Android 10 et supérieur, et une prise en charge dès le premier jour pour Android 17. Elle acte aussi le découplage des bibliothèques Material et Cupertino en paquets autonomes, effectif depuis la rentrée. Google note au passage que les contributeurs extérieurs à l'entreprise sont désormais plus nombreux que les siens.

Kotlin Multiplatform est sorti du statut d'option exotique. Depuis Compose Multiplatform 1.8.0 en mai 2025, l'interface partagée sur iOS est déclarée stable et prête pour la production, avec un surcoût d'environ 9 Mo par rapport à une application SwiftUI native équivalente. La série a continué, avec une version 1.12.0 publiée en août 2026.

Le critère qui compte n'est plus la capacité technique

Les trois socles savent faire une liste, un formulaire, une prise de photo, une carte, une notification. Si votre prestataire justifie son choix par une démonstration de fluidité, il répond à une question qui ne se pose plus. La bonne est ailleurs : à quel rythme ce socle m'obligera-t-il à repasser dans le code, et combien coûtera chaque passage ?

La politique de support de React Native est explicite : seules la dernière version stable et les deux mineures précédentes sont maintenues, soit une fenêtre de l'ordre de neuf à douze mois. Une application livrée puis laissée tranquille deux ans se retrouve donc mécaniquement hors support, sur une chaîne d'outils qui exige entre-temps une version de Node, un JDK et un Xcode plus récents. Le coût n'est pas le correctif, c'est la remise à niveau de tout l'environnement de construction.

Flutter impose un rythme comparable, avec des ruptures moins fréquentes mais des chantiers de fond comme le passage à Impeller. Kotlin Multiplatform, lui, vous fait suivre deux calendriers, celui de Kotlin et celui des plateformes natives : plus prévisible, mais pas plus léger.

Quatre questions pour trancher

Voici la grille que nous utilisons en cadrage, dans cet ordre, avant d'ouvrir un éditeur de code.

  1. Qui maintiendra l'application dans trois ans ? Si la réponse est votre informaticien interne ou un prestataire local, le socle doit être celui pour lequel vous trouverez quelqu'un à cinquante kilomètres, pas celui qui gagne les comparatifs de performance.
  2. Avez-vous déjà une équipe et un existant ? Une équipe web qui travaille en TypeScript ira plus loin avec React Native ; une équipe qui maintient déjà une application Android en Kotlin partagera sa logique métier avec Kotlin Multiplatform sans rien jeter.
  3. L'application touche-t-elle du matériel particulier ? Lecteur de badge, imprimante d'étiquettes, terminal durci : chaque périphérique inhabituel se paie en passerelle à écrire et à maintenir, quel que soit le socle.
  4. Quel budget annuel acceptez-vous de consacrer à la seule compatibilité ? Cette ligne n'apporte aucune fonctionnalité, elle maintient l'application publiable. Si elle n'est pas budgétée, le socle le moins exigeant en maintenance l'emporte, même s'il est moins élégant.

Aucune de ces quatre questions ne porte sur le framework lui-même, et c'est volontaire. Un cahier des charges qui fige la technologie dès la première page se prive des meilleures propositions et transforme un arbitrage d'ingénierie en décision d'achat à l'aveugle.

Les cas où le natif reste le bon choix

Le multiplateforme n'est pas une réponse universelle. Trois situations justifient encore d'écrire deux applications distinctes, en Swift et en Kotlin.

  • L'application est le produit vendu, et la moindre friction d'interface se traduit en désinstallation.
  • Elle repose sur des fonctions système de pointe, extensions, widgets avancés, IA embarquée, qui arrivent d'abord sur les interfaces natives.
  • Elle ne cible qu'une seule plateforme, parce que le parc d'appareils est fourni par l'entreprise : le multiplateforme ajoute alors une couche sans rien économiser.

Pour tout le reste, c'est-à-dire l'immense majorité des applications internes, portails de terrain et outils de saisie, le code partagé reste le choix par défaut. Une voie intermédiaire mérite d'être connue : partager la logique métier et la couche de données tout en gardant une interface native. Kotlin Multiplatform a été conçu pour cela, souvent le compromis le plus sain quand une application native existe déjà.

Ce qu'il faut écrire au contrat

Le choix technique se protège par trois lignes, pas par une annexe de trente pages.

  • Une enveloppe annuelle de maintenance de compatibilité, distincte du budget d'évolutions, avec l'engagement de rester dans la fenêtre de support du socle retenu.
  • La propriété des comptes éditeurs et du dépôt de code au nom de votre entreprise, et non à celui du prestataire : c'est ce qui rend un changement d'équipe possible sans repartir de zéro.
  • Une clause de réversibilité qui précise ce qui est restitué et sous quelle forme, testée une fois pendant la vie du contrat plutôt que découverte le jour de la rupture.

Et une règle de méthode : ne décidez pas du socle sur la foi d'un comparatif, mais d'un premier lot restreint, livré sur appareil réel à cinq ou dix utilisateurs. Six à huit semaines suffisent à savoir si l'équipe tient le rythme et si l'application est réellement utilisée. C'est l'objet de notre approche prototypage et MVP.

Questions fréquentes

Faut-il choisir Flutter ou React Native en 2026 ?

Les deux conviennent à une application d'entreprise. Si vos développeurs travaillent déjà en JavaScript ou TypeScript, React Native réduit le temps d'apprentissage. Si vous partez de zéro et voulez une interface identique partout, Flutter est plus prévisible. Le critère décisif reste la disponibilité des compétences pour la maintenance, pas le framework.

Le développement natif est-il encore justifié ?

Oui, dans trois cas : quand l'application est le produit vendu, quand elle dépend de fonctions système de pointe, ou quand une seule plateforme est ciblée parce que l'entreprise fournit les appareils.

Combien de temps une application mobile tient-elle sans intervention ?

Rarement plus de douze à dix-huit mois. La politique de support de React Native ne couvre que la dernière version stable et les deux mineures précédentes, et les magasins imposent régulièrement de nouvelles versions d'outils et de cibles.

Kotlin Multiplatform convient-il à une PME ?

Il est pertinent quand une application Android en Kotlin existe déjà, ou quand vous voulez partager la logique métier tout en gardant des interfaces natives. L'interface partagée sur iOS est stable depuis Compose Multiplatform 1.8.0, en mai 2025. Le point de vigilance reste le vivier de compétences, plus étroit qu'ailleurs.

Peut-on changer de technologie en cours de route ?

Pas sans réécrire l'interface. En revanche, si la logique métier et les appels de services ont été isolés dans une couche distincte dès le départ, cette partie se transpose. C'est la précaution la moins coûteuse à prendre au démarrage, et la plus souvent oubliée.

Vous hésitez entre plusieurs socles, ou vous héritez d'une application mobile devenue impossible à republier ? Parlons de votre projet : nous regardons votre existant, vos compétences internes et votre budget de maintenance avant de parler technologie.