Remplacer WinDev Mobile par Flutter ou React Native

Les applications WinDev Mobile en circulation sont majoritairement des outils de terrain : inventaire, tournées, saisie en entrepôt ou en atelier. Les remplacer se joue entre deux frameworks multiplateformes, Flutter et React Native, qui partagent la même promesse (un seul code pour Android et iOS) avec des philosophies différentes. Voici comment trancher pour une application métier.

Flutter et React Native face à face

Règle simple : si votre trajectoire web passe par React, React Native mutualise les compétences ; si le mobile est un chantier autonome à l'ergonomie très contrôlée, Flutter part souvent favori. Les deux mènent au but ; c'est la cohérence avec le reste de votre stack qui départage.

Mode hors ligne et synchronisation

C'est le sujet numéro un des applications de terrain, et celui que WinDev Mobile traitait avec ses mécanismes propriétaires. En cible moderne, le motif standard s'appuie sur une base locale embarquée (SQLite le plus souvent) et une file de synchronisation vers l'API centrale, avec gestion explicite des conflits. Ce comportement doit être spécifié fonctionnellement, cas par cas : que se passe-t-il si deux agents modifient la même fiche hors réseau ? La réponse est métier avant d'être technique.

Accès matériel : scan, NFC, impression

Les applications de terrain vivent de leurs périphériques : douchettes et scanners intégrés (Zebra, Honeywell), NFC, imprimantes mobiles. Flutter comme React Native y accèdent via des modules dédiés, y compris les SDK constructeurs des terminaux durcis. Le point de méthode : inventorier les matériels réellement en parc dès l'audit et prototyper les accès critiques en tout début de projet. Un scan qui fonctionne au premier jour du développement évite une mauvaise surprise au dernier.

Publication sur les stores

Deux canaux selon l'usage. Distribution publique : App Store et Play Store, avec leurs règles de validation et leurs délais, à intégrer au calendrier. Distribution interne : la gestion de flotte (MDM) déploie l'application directement sur les terminaux de l'entreprise, sans passage par les stores publics, ce qui correspond au mode de déploiement de la plupart des applications WinDev Mobile existantes. Les mises à jour deviennent centralisées et traçables, là où le redéploiement manuel de terminaux était une charge récurrente.

Points de vigilance à l'audit d'une application WinDev Mobile

• L'inventaire exact des terminaux en circulation (modèles, versions d'OS, périphériques embarqués) : c'est souvent plus hétérogène que ne le pense l'équipe qui gère le parc au quotidien.
• Les scénarios de conflit de synchronisation réellement rencontrés sur le terrain, à recueillir auprès des utilisateurs plutôt qu'à deviner depuis le bureau.
• Les habitudes d'usage hors ligne : durée moyenne d'une session sans réseau, volume de données saisies avant reconnexion.
• Les intégrations du côté central (API existante ou à construire, système de gestion de flotte) qui conditionnent le calendrier autant que le développement mobile lui-même.

Ce diagnostic matériel se mène idéalement avec les utilisateurs de terrain eux-mêmes, pas seulement avec l'encadrement : ce sont eux qui connaissent les gestes réels, les zones sans réseau et les périphériques qui posent problème au quotidien. Les impliquer tôt réduit le risque de découvrir un blocage d'usage après la mise en production.

Coût et délai d'une réécriture mobile

Une application de terrain se réécrit plus vite qu'un back-office complet : le périmètre fonctionnel est resserré, les écrans peu nombreux, et la valeur se concentre dans la fiabilité du hors-ligne et des périphériques. Le calendrier se compte en mois, portés surtout par la spécification de la synchronisation et les tests sur matériel réel. Le chiffrage précis sort de l'audit, qui inventorie écrans, flux et matériels en parc.