Réécrire votre application
WinDev Mobile en Flutter.

Pourquoi passer de WinDev Mobile à Flutter ?

WinDev Mobile a permis à beaucoup d'entreprises de mettre une application dans la poche de leurs équipes terrain, souvent reliée à une application WinDev de bureau ou à un ERP. Mais une application mobile vit dans un environnement qui bouge vite : nouvelles versions d'Android et d'iOS, exigences des magasins d'applications, attentes des utilisateurs habitués aux applications grand public.

Flutter est un framework open source pour construire des applications mobiles à partir d'une seule base de code, en langage Dart. Il apporte :

• Une interface moderne, fluide et identique sur Android et iOS, construite à partir de composants (widgets) ;
• Un vaste écosystème de bibliothèques pour la caméra, la géolocalisation, les notifications, la lecture de codes-barres ou la signature ;
• Une communauté de développeurs importante, ce qui facilite le recrutement et la reprise du code ;
• Une séparation nette entre l'application et le serveur, qui communiquent par une API.

Flutter n'est pas la seule cible : React Native et .NET MAUI sont aussi des choix solides selon vos équipes et votre back-end. Nous vous aidons à choisir pendant l'audit.

Équivalence des concepts WinDev Mobile → Flutter

Exemple : la liste des interventions

Un écran très courant : à l'ouverture, l'application affiche les interventions du jour dans une zone répétée. En WinDev Mobile, la fenêtre lit la base HFSQL embarquée et remplit la zone ligne par ligne.

// FEN_Interventions · traitement d'initialisation
ZoneRépétéeSupprimeTout(ZR_Interventions)

HLitRecherchePremier(Intervention, DateIntervention, DateDuJour())
TANTQUE HTrouve(Intervention)
    ZoneRépétéeAjouteLigne(ZR_Interventions, ...
        Intervention.Client, Intervention.Adresse, Intervention.Statut)
    HLitSuivant(Intervention, DateIntervention)
FIN

En Flutter, l'écran ne lit pas la base lui-même. Il demande la liste à un dépôt de données, affiche un indicateur de chargement, puis construit une ligne par intervention. Ici, la vue passe du jour à la semaine, comme dans notre propre application.

class InterventionsPage extends StatefulWidget {
  const InterventionsPage({super.key, required this.repo});
  final InterventionRepository repo;

  @override
  State<InterventionsPage> createState() => _InterventionsPageState();
}

class _InterventionsPageState extends State<InterventionsPage> {
  late final Future<List<Intervention>> _semaine = widget.repo.semaineEnCours();

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Mes interventions')),
      body: FutureBuilder<List<Intervention>>(
        future: _semaine,
        builder: (context, snapshot) {
          if (!snapshot.hasData) {
            return const Center(child: CircularProgressIndicator());
          }
          final items = snapshot.data!;
          return ListView.builder(
            itemCount: items.length,
            itemBuilder: (context, i) => InterventionTile(items[i]),
          );
        },
      ),
    );
  }
}

Le dépôt de données centralise la question qui compte le plus sur le terrain : que se passe-t-il sans réseau ? L'écran lit toujours la base locale, et la synchronisation avec le serveur se fait à part.

class InterventionRepository {
  InterventionRepository(this.db, this.api);
  final LocalDatabase db;   // SQLite sur le téléphone
  final InterventionApi api; // API REST du serveur

  // Lecture locale : l'écran s'affiche même sans réseau
  Future<List<Intervention>> semaineEnCours() => db.interventionsDeLaSemaine();

  // Envoi des modifications faites hors ligne, puis récupération des nouveautés
  Future<void> synchroniser() async {
    await api.envoyer(await db.modificationsEnAttente());
    await db.enregistrer(await api.interventionsDeLaSemaine());
  }
}

Ce découpage rend chaque morceau testable : on peut vérifier la synchronisation sans écran, et l'écran sans réseau.

Les pièges d'une migration WinDev Mobile

Le mode hors ligne et les conflits

Une application terrain doit fonctionner dans un sous-sol, une chaufferie ou une zone blanche. Si deux personnes modifient la même intervention hors ligne, laquelle gagne ? Ces règles sont souvent implicites dans l'ancienne synchronisation. Il faut les écrire noir sur blanc avant de coder.

Les données déjà présentes sur les appareils

Au moment de la bascule, des téléphones peuvent contenir des saisies pas encore synchronisées. Il faut prévoir une procédure : synchroniser l'ancienne application une dernière fois, ou reprendre ses données locales dans la nouvelle.

Les permissions et les règles des systèmes

Android et iOS encadrent de plus en plus la géolocalisation en arrière-plan, les notifications et l'accès aux fichiers. Une fonction qui marchait dans une ancienne application peut demander une autorisation explicite ou une autre approche dans la nouvelle.

Les périphériques métier

Imprimante Bluetooth, lecteur de codes-barres intégré, terminal durci : chaque matériel doit être testé avec la nouvelle application. On les inventorie dès l'audit pour vérifier qu'une bibliothèque existe ou prévoir un développement spécifique.

Reproduire l'ancien écran à l'identique

Copier les fenêtres WinDev Mobile champ par champ produit une application neuve qui a l'air ancienne. La migration est le bon moment pour repenser l'ergonomie avec les utilisateurs : vue semaine plutôt que jour par jour, urgences en tête, actions principales accessibles d'un pouce.

Notre méthode

1. Audit. Inventaire des fenêtres, des règles métier, de la base embarquée, de la synchronisation et des périphériques. Voir notre audit d'application WinDev.
2. API. Une API moderne est construite au-dessus des données existantes. Elle servira la nouvelle application, et pourra servir un site web ou une application de bureau .NET.
3. Nouvelle UX terrain. Les écrans sont conçus avec vos utilisateurs, pour leurs vraies conditions de travail.
4. Développement Flutter. Écrans, base locale, synchronisation, intégration des périphériques, tests.
5. Déploiement progressif. Un premier groupe d'utilisateurs, puis la généralisation, pendant que l'ancienne application reste disponible.
6. Évolutions. Maintenance, mises à jour liées aux nouvelles versions d'Android et d'iOS, nouvelles fonctions.

Si votre base serveur est en HFSQL, elle peut être reprise dans un second temps : voir HFSQL vers PostgreSQL. Pour une vue d'ensemble de notre démarche, consultez la page migration et refonte d'applications WinDev Mobile.