‍

Un scénario dans lequel vous pourriez vous reconnaître

Imaginez, vous avez un nouveau projet d'application métier pour vos commerciaux terrain. Il s'agit d'un simple portage de la version iOS et Android, qui par ailleurs tourne déjà très bien. Les utilisateurs l'aiment, les retours sont bons. La direction métier veut aller plus loin : équiper les commerciaux de Surface Pro pour qu'ils puissent l'utiliser aussi en clientèle, en mode tablette, avec stylet.

Votre tech lead vous dit : « Pas de souci, c'est du cross-platform. On réutilise 80 % du code, on ajoute Windows comme cible, et c'est plié. »

Vous vous lancez... Six mois plus tard, c'est la douche froide, vous découvrez ce que ce fameux « 80 % » cachait : des composants qui ne marchent pas pareil, une bibliothèque d'authentification qui pose problème, un framework dont le support Windows est distillé par nulle autre que les équipes de Microsoft, et qui viennent d'annoncer qu'ils avaient revu leurs priorités.

Loin d'être un comparatif technique, cet article se veut comme une grille de décision pour ceux qui se porteront responsables du succès ou de l'échec de la mise en œuvre d'un tel projet. Le plus grand risque étant d'être pris au milieu d'une guerre de chapelle : le choix entre React Native et Flutter sur Windows n'est pas un détail d'implémentation, c'est un pari stratégique sur l'écosystème.

Voyons comment vous aider à prendre une décision éclairée.

Pourquoi la question se pose de plus en plus

Le besoin tri-platform (iOS + Android + Windows) explose dans les contextes B2B. Trois raisons :

1. Les Surface Pro et autres 2-en-1 ont gagné le terrain. Les commerciaux, les opérateurs en entrepôt, les inspecteurs, autant de profils sur site qui veulent un seul appareil qui fait laptop le matin et tablette l'après-midi. On ne jongle plus entre un PC fixe et une tablette de prêt.
2. Le coût d'un parc multi-OS est devenu insupportable. Maintenir trois codebases pour la même app interne, ça ne passe plus en budget. Dès lors, la promesse du cross-platform, c'est de diviser ce coût par deux, voire par trois.
3. L'IT veut un déploiement unifié. Intune, l'outil de MDM de Microsoft, gère aujourd'hui aussi bien des iPhone que des tablettes Android ou des PC Windows depuis une même console. Conséquence : les DSI ne veulent plus de cas particulier dans leur parc. Quand l'app métier tourne déjà sur iOS et Android, ajouter une cible tablette Windows à la même politique de déploiement est un réflexe naturel c'est dailleurs ce qui pousse Windows dans le scope des projets B2B mobilité.

En 2026, mais depuis quelques années déjà, deux frameworks dominent ce paysage : React Native (Meta) et Flutter (Google). Tous deux supportent Windows. Mais ce support n'a pas la même histoire, le même statut et offre surtout des garanties diamétralement opposées.

Deux philosophies opposées

Avant d'entrer dans les critères, une métaphore qui clarifie tout.

Flutter, c'est un peintre. Il dessine lui-même chaque pixel de l'écran via son propre moteur de rendu. Votre app aura exactement le même look sur iPhone, sur Android, sur Surface Pro. Sur le papier ça semble être ce qu'on souhaite, mais en approfondissant la réflexion, cela implique qu'elle ne ressemble jamais parfaitement à un vrai composant natif. Cela peut perdre en particulier les utilisateurs non experts, notamment terrain, qui ont leurs repères sur la grammaire d'utilisation de leur OS.

React Native, c'est un traducteur. Il prend votre code JavaScript et l'instancie en composants natifs de chaque OS. Sur Windows, il s'appuie sur XAML et WinUI, les briques natives du système. Ça ressemblera vraiment à du Windows, avec tout ce que Microsoft décide d'y mettre. Toutefois, il faut que quelqu'un maintienne le traducteur à jour.

Cette différence philosophique gouverne tout le reste.

Trois acteurs pour deux repo

C'est particulièrement sur ce point que le choix ne devient plus technique.

Flutter Windows est maintenu par Google (l'éditeur de Flutter), directement dans le repo principal de Flutter. Le support Windows est une cible officielle du produit Flutter, au même titre qu'iOS ou Android. Stable depuis février 2022, il fait partie intégrante de chaque release.

React Native Windows est maintenu par Microsoft (alors que c'est Meta l'éditeur de React Native), dans un fork séparé (le repo microsoft/react-native-windows). C'est donc l'équipe Microsoft qui doit, à chaque nouvelle version de React Native, faire l'effort de porter les changements vers leur cible Windows. À l'heure où j'écris ces lignes, la dernière version stable de React Native est 0.85.1 (sortie le 13 avril 2026), tandis que la dernière version stable de React Native Windows est la 0.82.0, sortie le 17 mars 2026. Soit trois versions mineures de retard, et ce n'est pas un accident de calendrier, c'est un pattern structurel qui se répète à chaque cycle ^[1].

Meta a fait le choix  de se concentrer sur iOS/Android comme cibles primaires, en déléguant le support Windows à Microsoft via un fork séparé, tout en y contribuant ponctuellement quand ça sert ses propres produits (par exemple Messenger).

Cette différence de gouvernance n'est pas qu'un détail d'organigramme. Elle a une conséquence très concrète : les bibliothèques tierces de l'écosystème, celles qui font le vrai travail de votre application, n'ont pas le même niveau de support Windows selon le framework choisi. C'est précisément ce qu'on va cartographier maintenant.

Les dix capacités d'une application B2B mobilité

Toute application B2B en mobilité repose sur un sous-ensemble de capacités techniques relativement stables. Que vous fassiez de l'inspection terrain, de la visite client, de la maintenance industrielle ou de la collecte de données métier, la même boîte à outils revient à chaque fois. Voici les dix capacités que nous retenons comme représentatives :

1. Authentification entreprise : connexion par OpenID Connect ou SAML, intégration SSO (Keycloak, Entra ID, Okta), conservation sécurisée des jetons.
2. Stockage local structuré : base de données relationnelle locale (SQLite typiquement), requêtes complexes, modèle de données métier.
3. Synchronisation différée : capacité à fonctionner offline puis à synchroniser dès que ça reconnecte, gestion des conflits, mécanisme de replay.
4. Stockage de fichiers volumineux : gestion d'attachements (photos, PDF, documents), volumétrie significative en local.
5. Capture photo et caméra : prise de photos avec contrôle de qualité, métadonnées EXIF, annotation.
6. Géolocalisation : positionnement GPS, suivi de trajet, intégration cartographique.
7. Signature électronique : capture de signature manuscrite, ou signature certifiée par OIDC.
8. Scan de codes et OCR : codes-barres, QR codes, reconnaissance de texte sur image.
9. Notifications push : réception de notifications côté serveur, gestion des permissions, deep linking.
10. Impression : vers imprimantes Bluetooth, réseau, ou systèmes type AirPrint / Mopria.

Evaluation de la maturité de prise en charge

Pour chaque capacité et chaque combinaison framework × plateforme, on peut classer le niveau de support en trois zones :

• Natif — il existe une bibliothèque mature, supportée officiellement, avec une communauté active. Vous l'installez, vous l'utilisez. Risque : faible.
• Dégradé — la capacité existe mais avec des restrictions : statut expérimental, fonctionnalités manquantes, dépendance peu maintenue, performance moindre, ou nécessité d'écrire du code de glue. Risque : modéré, à anticiper.
• Indisponible — pas de support officiel du tout, ou seule option un module natif entièrement à développer. Risque : élevé, plusieurs semaines de R&D pour combler chaque capacité.

Authentification entreprise

• React Native Windows : indisponible. La bibliothèque standard d'authentification de l'écosystème ne supporte officiellement que iOS et Android 2. Sur Windows, les équipes doivent bricoler avec les briques natives de Microsoft ou intégrer manuellement des bibliothèques .NET. Pour une connexion à un Keycloak ou un Azure AD, cela peut vite représenter plusieurs semaines de développement custom, et autant à maintenir derrière.
• Flutter Windows : dégradé. Le plugin officiel équivalent ne couvre pas non plus Windows 3, mais une alternative en pur Dart, sans dépendance native, fonctionne sur toutes les plateformes desktop. Ça nécessite un peu de plomberie côté navigation, mais c'est une voie de contournement standard et documentée.

Stockage local structuré

• React Native Windows : dégradé. Le standard de fait pour le stockage relationnel performant en React Native a un support Windows étiqueté « expérimental ». Avec des restrictions explicites : pas de synchronisation accélérée, fonctionnement contraint à l'architecture moderne uniquement, gestion incomplète du cycle de vie 4. Utilisable, mais à vos risques.
• Flutter Windows : natif. Les deux solutions standard de stockage SQLite couvrent Windows sans réserve, avec une documentation et une communauté actives 5.

Synchronisation différée

Le verdict suit naturellement celui du stockage local : la sync repose sur la base, donc si la base est dégradée, la synchronisation l'est aussi. RNW dégradé, Flutter natif.

Stockage de fichiers volumineux

Bonne nouvelle sur ce critère : les deux frameworks le prennent en charge. Pas de souci pour stocker des photos, des PDF, ou des attachements de toute taille.

Capture photo et caméra

C'est le critère le plus critique pour les apps de mobilité terrain. Et c'est aussi celui où l'écart entre les deux frameworks est le plus marqué.

• React Native Windows : indisponible. La bibliothèque standard de capture caméra de l'écosystème ne supporte pas Windows, l'issue de support a été fermée sans implémentation 6. La bibliothèque alternative de sélection d'image non plus. Quant au seul plugin historique qui supportait Windows, il est déprécié depuis 2022. Le verdict : pour faire de la photo sur React Native Windows, il faut écrire un module natif en C++ qui pilote directement les API caméra de Windows. Comptez plusieurs semaines de développement spécialisé, et de la maintenance à vie.
• Flutter Windows : dégradé. Le plugin officiel existe mais reste explicitement marqué comme « pas prêt pour la production », avec des fonctionnalités de base manquantes (le streaming d'image notamment) 7. Utilisable pour des cas simples, mais à dérisquer impérativement par un POC avant de s'engager.

Géolocalisation

• React Native Windows : dégradé. L'API de géolocalisation native du framework fonctionne en partie, mais le module communautaire enrichi (celui utilisé en pratique sur la majorité des projets) n'a pas de support Windows officiel. Un ticket ouvert depuis 2020 sur le repo Microsoft en témoigne 8.
• Flutter Windows : natif. L'implémentation Windows du package standard de géolocalisation est officiellement endossée par l'équipe mainteneuse, dans la structure de plugin fédéré standard de Flutter 9.

Signature électronique

Les deux frameworks sont en dégradé sur ce point. Aucun plugin de capture de signature manuscrite n'est officiellement supporté sur Windows, ni d'un côté ni de l'autre. Pour Flutter, on peut s'en sortir avec une bibliothèque communautaire et un peu de code custom. Pour React Native Windows, à nouveau, module natif à écrire.

Scan de codes et OCR

• React Native Windows : indisponible. Pour la même raison que la photo : sans plugin caméra fonctionnel, pas de scan possible. Tout est à écrire en module natif.
• Flutter Windows : dégradé. Possible en passant par le plugin caméra Windows, mais avec les limitations déjà mentionnées. Pas de plugin clé en main pour le scan de codes-barres sur Windows desktop, c'est encore très artisanal.

Notifications push

• React Native Windows : dégradé. Le support du service de notifications push Windows existe mais n'est pas trivial à intégrer. Des issues ouvertes depuis plusieurs années montrent que les développeurs ont du mal à le faire fonctionner sans assistance Microsoft directe 10.
• Flutter Windows : natif. Les notifications locales sont couvertes en standard. Pour les notifications distantes, les solutions habituelles ont étendu leur support desktop progressivement.

La carte ci-dessous synthétise la situation à mi-2026, sources à l'appui.

‍

Conclusion

Sur les smartphones et tablettes iOS/Android, les deux frameworks ont évidemment une prise en charge sur quasiment toutes les capacités. Rien d'étonnant : c'est leur terrain historique, l'écosystème est mature, les bibliothèques sont mûres et largement utilisées en production.

Le verdict

Quand on regarde la silhouette globale, le constat est sans ambiguïté : sur tablette Windows, Flutter offre une couverture significativement plus mûre que React Native. Là où React Native cumule trois capacités non prises en chage (auth, photo, scan) et six capacités dégradées, Flutter n'a aucune exclusion de prise en charge et la moitié en dégradée mais dont une bonne partie peuvent être contournées par des bibliothèques en pur Dart.

Toutefois, ce verdict mérite trois nuances qui changent la lecture selon votre contexte :

1. Si votre stack fonctionnelle est légère côté Windows, les deux frameworks tiennent. Une application qui se contente d'authentification, stockage de fichiers et notifications push peut tourner en React Native Windows sans trop souffrir. C'est quand on cumule les capacités « hors scope » (auth d'entreprise + photo + scan) que la facture explose. Il est donc essentiel de ne pas se focaliser sur une vision MVP du produit mais également de s'interroger sur l'après

2. Le coût de prise en charge de capacités non gérées n'est pas seulement développement initial, c'est aussi maintenance. Un module natif C++/WinRT que vous avez écrit pour combler un trou RNW devra être maintenu, débuggé et évoluer pendant toute la vie de l'application. Chaque montée de version RNW peut générer de la régression. C'est de la dette technique structurelle, qui finit par peser lourd et qui est systématiquement sous-estimée.

3. Le contexte d'équipe. Une équipe expérimentée en React Native, avec un POC mobile déjà validé, peut rationnellement décider de garder RN et d'accepter le coût Windows, plutôt que de tout réécrire en Flutter. C'est un arbitrage légitime, à condition d'avoir pu évaluer le surcoût que cela peut générer à moyen / long terme.

En une phrase

La promesse « cross-platform » ne dit rien sur la maturité d'une plateforme cible donnée pour vos besoins fonctionnels précis. La tablette Windows reste, en 2026, la cible la moins bien servie par les écosystèmes React Native et Flutter : chacun à sa manière. Choisir un framework sans avoir cartographié vos capacités critiques sur cette cible, c'est signer un chèque en blanc qu'on encaissera six mois plus tard, en jours-homme et en frustration.

Notes

‍

‍