Migration appli vers technologie flutter

Nous disposons d’une application mobile de prise de commande pour serveurs de restaurant, utilisée par les serveurs en salle pour saisir les commandes des clients depuis leur mobile/tablette, et également pour encaisser (CB, espèces, tickets restaurant — sans intégration à un terminal de paiement physique, juste l’enregistrement du mode de règlement choisi). Cette application est reliée à la base de données de la caisse principale du restaurant (HFSQL, sur serveur distant).
L’application est actuellement développée sous WinDev Mobile (WLangage), et nous souhaitons la faire migrer vers Flutter par un développeur/une équipe expérimenté(e). Il ne s’agit pas d’une conversion automatique : c’est une réécriture complète, écran par écran, avec une nouvelle architecture.
L’appli gère : la prise de commande (sélection de produits, gestion des couverts/tables), l’encaissement (CB/espèces/tickets restaurant, sans terminal physique), le login des serveurs par code numérique, l’envoi des commandes en cuisine (impression), et la connexion à la base de données HFSQL de la caisse principale.

PÉRIMÈTRE DU PROJET SOURCE
* 21 997 lignes de code (≈11 800 hors commentaires), 1 736 traitements
* 39 fenêtres + 19 fenêtres internes (≈58 écrans/composants UI)
* 39 requêtes base de données
* 103 classes métier
* 4 collections de procédures
* Données actuellement en HFSQL (accès client-serveur sur serveur distant)

NOUVELLE EXIGENCE IMPORTANTE : MODE OFFLINE
L’application actuelle ne fonctionne PAS en mode déconnecté — c’est une limite que nous voulons corriger dans la nouvelle version. Les serveurs doivent pouvoir continuer à prendre des commandes sur leur appareil même en cas de coupure wifi (zone morte en salle, coupure box internet), avec synchronisation vers la caisse principale dès que la connexion revient.
Cela implique probablement :
* Un cache local (SQLite ou équivalent) sur l’appareil du serveur
* Une logique de synchronisation avec la base de la caisse principale (gestion des conflits, file d’attente d’opérations)
* Une attention particulière à la fiabilité des encaissements enregistrés hors-ligne (aucune perte, aucun double-enregistrement lors de la synchronisation) — il ne s’agit pas d’intégration avec un terminal de paiement physique, seulement de l’enregistrement fiable du mode de règlement choisi par le serveur
* Une réflexion sur ce qui peut fonctionner offline (prise de commande, encaissement) vs ce qui nécessite une connexion (vérification de licence, par exemple)
C’est un point sur lequel nous attendons des propositions concrètes de la part des candidats.

STACK TECHNIQUE CIBLE
* Flutter (Dart) pour le mobile (Android + iOS)
* Backend : WebService REST à créer (exposant les données HFSQL existantes) — ouvert à discussion sur la technologie (WebService WinDev natif, ou couche intermédiaire type Node.js)
* State management : Riverpod (déjà amorcé, ouvert à discussion si argumenté)
* Authentification API à définir avec le prestataire

LIVRABLES ATTENDUS
* Application Flutter complète, fonctionnellement équivalente à l’application WinDev actuelle
* Mode offline avec synchronisation vers la base de la caisse principale
* WebService REST (ou équivalent) exposant les données de la caisse nécessaires à l’app serveurs
* Documentation technique de l’architecture mise en place
* Accompagnement à la mise en production sur les stores (Android/iOS)

PROFIL RECHERCHÉ
* Expérience confirmée en Flutter/Dart sur des applications métier complexes (idéalement du secteur restauration/hôtellerie ou applications de prise de commande terrain)
* Expérience sur des architectures offline-first (cache local, synchronisation)
* À l’aise pour reprendre et comprendre du code existant dans un autre langage (WLangage/WinDev), ou capacité à travailler avec un développeur WinDev en parallèle sur la partie backend
* Autonomie sur le découpage et la planification d’un projet de cette taille (livraison probable en plusieurs lots/écrans
Modalités :
* Merci de proposer un chiffrage détaillé par lot (architecture, écrans, backend, mode offline, tests) plutôt qu’un forfait global, afin de pouvoir comparer les offres sereinement.
* Merci d’indiquer dans votre candidature : vos réalisations similaires, votre approche pour le mode offline, et votre disponibilité.