NON : techniquement WinDev Mobile réutilise le WLangage et l'analyse, mais transposer telle quelle une application de bureau sur un téléphone donne un résultat inutilisable. Il faut REPENSER l'usage, l'interface et le fonctionnement hors ligne. Ce qui se réutilise réellement : (1) Le WLANGAGE et vos compétences de développement. (2) L'ANALYSE : le modèle de données, souvent partagé. (3) Une partie des PROCÉDURES métier (les calculs, les règles) — d'autant mieux qu'elles sont bien séparées de l'interface, ce qui est un argument supplémentaire pour ne jamais mettre le métier dans les boutons. (4) Les concepts et les réflexes de l'atelier. Ce qui doit être REPENSÉ : (1) Le PÉRIMÈTRE fonctionnel. C'est le point le plus important. Une application de gestion complète comporte des dizaines d'écrans ; sur mobile, on ne veut généralement qu'une poignée de tâches précises : consulter une fiche client en clientèle, saisir un relevé sur site, scanner un article, faire signer un bon de livraison. Le mobile n'est pas une version réduite : c'est un usage DIFFÉRENT. Demandez-vous ce que l'utilisateur fait vraiment sur le terrain. (2) L'INTERFACE. Un écran de saisie dense avec trente champs, conçu pour un grand écran et un clavier, est inutilisable sur un téléphone. Il faut hiérarchiser, découper, agrandir les zones de touche, réduire la saisie au strict minimum. (3) Le MODE DE SAISIE : taper du texte sur un téléphone est lent et pénible. Privilégiez les listes de choix, les valeurs par défaut, la géolocalisation, le SCAN de codes-barres, la photo, la signature à l'écran. Souvent, un scan remplace avantageusement une saisie manuelle. (4) La CONNEXION : sur le terrain, le réseau est incertain (sous-sol, zone blanche, entrepôt). Une application qui exige une connexion permanente sera rejetée. Il faut penser HORS LIGNE et SYNCHRONISATION dès la conception — ce n'est pas un ajout de dernière minute, cela structure l'architecture. (5) Le CONTEXTE d'usage : debout, en marchant, avec une seule main, parfois avec des gants, en extérieur (lisibilité au soleil), dans l'urgence. La méthode recommandée : (1) Partez des BESOINS TERRAIN, pas de l'application existante. Observez les utilisateurs mobiles. (2) Définissez un périmètre RESTREINT et utile. (3) Concevez des écrans MOBILES (pas des écrans de bureau rétrécis). (4) Traitez la synchronisation et les conflits explicitement. (5) TESTEZ sur de vrais appareils, en conditions réelles (extérieur, réseau faible, une main). (6) Prévoyez la maintenance liée aux stores et aux évolutions des systèmes. En résumé : NON. WinDev Mobile permet de RÉUTILISER l'essentiel — WLangage, ANALYSE, procédures métier (surtout si elles sont bien séparées de l'interface), compétences et réflexes — ce qui évite d'apprendre le développement natif Android et iOS, et c'est un atout considérable. Mais un simple portage produit une application inutilisable, car le mobile relève d'un USAGE DIFFÉRENT, pas d'une version réduite. Il faut d'abord repenser le PÉRIMÈTRE : sur le terrain, l'utilisateur n'a besoin que de quelques tâches précises (consulter une fiche, saisir un relevé, scanner, faire signer), pas des dizaines d'écrans de l'application de bureau. Il faut ensuite repenser l'INTERFACE (hiérarchiser, découper, agrandir les zones de touche) et le MODE DE SAISIE, car taper sur un téléphone est lent : privilégiez listes, valeurs par défaut, scan de codes-barres, photo, GPS et signature à l'écran. Surtout, traitez dès la CONCEPTION le fonctionnement HORS LIGNE et la SYNCHRONISATION avec ses conflits, car le réseau est incertain sur le terrain et une application qui exige une connexion permanente sera rejetée. Enfin, tenez compte du contexte réel d'usage — debout, une main, gants, plein soleil, urgence — et testez sur de vrais appareils dans ces conditions.

En stockant les données LOCALEMENT sur l'appareil, en enregistrant les modifications effectuées hors réseau, puis en SYNCHRONISANT au retour de la connexion — avec une stratégie EXPLICITE de résolution des conflits, qui est le vrai point difficile. Pourquoi c'est indispensable : (1) Sur le terrain, le réseau manque : sous-sol, entrepôt, zone rurale, bâtiment industriel, déplacement. (2) Une application qui exige une connexion permanente devient inutilisable là où l'on en a le plus besoin — et sera abandonnée par les utilisateurs. (3) C'est souvent LE critère de succès ou d'échec d'un projet mobile professionnel. Les principes de fonctionnement : (1) Base LOCALE sur l'appareil : l'application travaille sur des données stockées localement (HFSQL est disponible sur mobile). L'utilisateur consulte et saisit sans dépendre du réseau. (2) File d'ATTENTE des modifications : les créations et modifications faites hors ligne sont mémorisées, avec leur horodatage. (3) SYNCHRONISATION au retour du réseau : envoi des modifications locales vers le serveur, réception des mises à jour du serveur. (4) Idéalement AUTOMATIQUE et discrète, avec possibilité de déclenchement manuel. (5) Ne synchronisez que le NÉCESSAIRE (données du secteur de l'utilisateur, période récente) : rapatrier toute la base sur un téléphone est inutile et lent. Le point difficile : les CONFLITS : (1) Le problème : pendant que le commercial modifiait la fiche client hors ligne, quelqu'un l'a aussi modifiée au siège. Laquelle des deux versions garder ? (2) Il n'y a pas de réponse universelle : la stratégie dépend du MÉTIER. C'est une décision fonctionnelle, pas seulement technique — associez les utilisateurs à ce choix. (3) Stratégies possibles : le serveur gagne toujours (simple, mais l'utilisateur perd sa saisie), le mobile gagne, la dernière modification l'emporte (attention aux horloges mal réglées), fusion par champ (plus fin : chacun a modifié des rubriques différentes), ou signalement pour ARBITRAGE humain. (4) Réduire les conflits à la source : c'est la meilleure approche. Cloisonnez les données (chaque commercial ne modifie que ses clients), limitez les modifications hors ligne aux cas nécessaires, privilégiez l'AJOUT (un relevé, une intervention, une commande) plutôt que la modification concurrente — un ajout ne crée pratiquement jamais de conflit. (5) TRACEZ les synchronisations et les conflits pour pouvoir diagnostiquer. Les bonnes pratiques : (1) Informez l'utilisateur : état de la connexion, données en attente de synchronisation, dernière synchronisation réussie. L'incertitude est anxiogène : il doit savoir si son travail est « remonté ». (2) Ne perdez JAMAIS une saisie : c'est la règle absolue. Un travail effectué sur le terrain, parfois dans des conditions difficiles, ne doit jamais disparaître silencieusement. (3) Gérez les échecs de synchronisation (reprise, nouvelle tentative) sans intervention complexe de l'utilisateur. (4) TESTEZ réellement : coupez le réseau, saisissez, reconnectez ; provoquez délibérément des conflits. Ces scénarios ne se testent pas « au bureau avec du wifi ». (5) Prévoyez la volumétrie et la durée de la première synchronisation. En résumé : gérez le hors ligne par une base LOCALE sur l'appareil (l'utilisateur consulte et saisit sans réseau), une file des modifications horodatées, puis une SYNCHRONISATION automatique et discrète au retour de la connexion — en ne rapatriant que les données nécessaires (secteur, période) plutôt que toute la base. Le vrai point difficile est la résolution des CONFLITS, lorsque la même donnée a été modifiée des deux côtés : il n'existe pas de réponse universelle, c'est une décision MÉTIER à prendre avec les utilisateurs (le serveur gagne, le mobile gagne, la dernière modification l'emporte — attention aux horloges —, fusion par champ, ou arbitrage humain). La meilleure stratégie reste de RÉDUIRE les conflits à la source : cloisonner les données par utilisateur, limiter les modifications hors ligne et privilégier l'AJOUT (relevé, intervention, commande), qui ne crée pratiquement jamais de conflit. Enfin, deux règles absolues : INFORMER l'utilisateur (état de connexion, éléments en attente, dernière synchronisation réussie) et ne JAMAIS perdre une saisie effectuée sur le terrain. Et testez réellement en coupant le réseau et en provoquant des conflits : ces scénarios ne se valident pas au bureau en wifi.