statuts & projects
Rapport d'estimation — Yo3eenApp
Rapport d'estimation — Yo3eenApp
Document préparé le : 2 août 2026
Destinataires : Associés / Investisseurs
Objet : Évaluation technique, architecture applicative et estimation financière du projet
Vue d'ensemble du projet
Yo3eenApp (dossier /sprints_flutter, nom technique sprints_flutter) est le client mobile Android d'une plateforme de mémorisation coranique en duo ("binome") — le README du projet la nomme lui-même sprints.liismaiil.org (nom interne différent du libellé de navigation "Yo3eenApp" utilisé dans ce site).
L'application couvre :
- Une authentification Firebase (tokenId + token)
- Un tableau de bord de sessions (sprints) — créer/rejoindre une session avec un partenaire
- Un jeu en duo temps réel (binome) — reclassement de versets coraniques mélangés, tour par tour, avec suivi des erreurs par joueur
- Un module de catégories (categories) — sélection par sourate/catégorie, avec inter-app Android : un bouton ouvre directement l'app sœur YofeedApp (
org.liismaiil.stages_flutter) via un intent Android natif
Comme YofeedApp, c'est un portage Flutter/GetX ciblé — mais plus abouti : les 5 écrans prévus sont tous branchés à la navigation (aucun écran fantôme constaté), et le test présent exécute une vraie assertion (pas un simple placeholder).
Architecture applicative
Routes enregistrées (toutes branchées)
| Route | Écran | Binding |
|---|---|---|
/signin | Authentification | AuthBinding |
/categories | Sélection sourate/catégorie + lien inter-app vers YofeedApp | CategoriesBinding |
/stages | Vue stages (partagée avec l'écosystème stages) | (aucun binding dédié) |
/sprints | Tableau de bord des sessions | SprintsBinding |
/sprints/:sessionId | Jeu en duo (binome) | BinomeBinding |
Modules internes
| Dossier | Contenu |
|---|---|
app/controllers (4) | AuthController, CategoriesController, SprintsController, BinomeController |
app/bindings (4) | Une par écran/groupe d'écrans |
app/views (7 fichiers) | Signin, Categories, Stages, Sprints (+ SessionCard), Binome (+ BinomeSuits) |
app/widgets (2) | TokenIdBadge, SprintsNavBar — composants partagés |
app/models (4) | SessionModel, SprintStageModel, GuestModel, AyahModel |
app/services (1) | FirestoreService — flux temps réel Firestore |
data/ (2) | surah_names.dart, flag_options.dart |
Écart README / code réel — implémentation Firestore temps réel, pas de polling HTTP
Le README.md du projet décrit une architecture avec un backend Node.js/Express + Redis et un service BinomeApiService faisant du polling HTTP toutes les 3 secondes (kBaseUrl, endpoints /api/binome/session, /api/binome/move...). Ce service n'existe pas dans le code : aucune trace de BinomeApiService, kBaseUrl ni d'appel HTTP dans lib/. L'implémentation réelle de binome_controller.dart s'appuie entièrement sur un flux Firestore temps réel (onSnapshot via FirestoreService.sessionStream), un commentaire du code le confirme explicitement : "Tout l'état vient du doc Firestore via onSnapshot".
Le README semble décrire une version antérieure ou planifiée de l'architecture ; le code livré est en réalité plus simple et plus moderne (temps réel natif Firestore) que ce qui est documenté — un point positif pour la maintenabilité, mais une documentation à mettre à jour.
Intégration inter-applications
categories_view.dart utilise android_intent_plus pour lancer directement l'app YofeedApp (org.liismaiil.stages_flutter) depuis Yo3eenApp via un intent Android natif, avec message de repli si l'app n'est pas installée — un vrai travail d'intégration entre les deux applications mobiles de l'écosystème.
Volume et complexité technique
Chiffres mesurés directement sur le codebase
| Indicateur | Valeur |
|---|---|
| Fichiers source (Dart) | 28 fichiers |
| Lignes de code | ~3 340 lignes |
| Routes enregistrées | 5 — toutes branchées, aucun écran fantôme |
| Contrôleurs GetX | 4 |
| Bindings (DI) | 4 |
| Modèles de données | 4 |
| Services | 1 (FirestoreService) |
| Composants UI partagés | 2 (TokenIdBadge, SprintsNavBar) |
| Tests | 1 fichier — test réel (vérifie que l'app démarre et affiche un Scaffold), pas un simple placeholder |
| Dépendances | 14 packages (11 production + 3 dev) |
| Plateformes cibles | Android uniquement (ios: false explicite, comme YofeedApp) |
Stack technique
| Couche | Technologie | Usage |
|---|---|---|
| Framework | Flutter 3.10+ / Dart 3.10 | App mobile Android |
| État & routing | GetX (get) | GetxController, Rx, GetMaterialApp, GetPage |
| Base de données | Firebase/Firestore | Flux temps réel (sessions + état de jeu) — pas de backend HTTP séparé malgré ce que dit le README |
| Authentification | Firebase Auth | + shared_preferences pour la persistance de session |
| Suivi d'erreurs | Firebase Crashlytics | Configuré (google-services.json partagé avec YofeedApp, projet Firebase lami1a-off) |
| Inter-app | android_intent_plus | Lancement natif de l'app sœur YofeedApp |
| Images | cached_network_image + url_launcher | Drapeaux pays |
| Tests | flutter_test | 1 test avec assertion réelle |
| Lints | flutter_lints | Config par défaut |
Estimation financière
Méthodologie
Estimation basée sur le volume de code mesuré, la complexité du jeu temps réel en duo (synchronisation Firestore, logique tour par tour) et les standards du marché pour un développeur Flutter/mobile senior.
Décomposition par module
| Module | Heures |
|---|---|
| Architecture Flutter/GetX (routes, bindings, DI, session) | 15h |
| Authentification (Firebase Auth + persistance session) | 15h |
| Module categories (sélection sourate + intégration inter-app Android) | 25h |
| Tableau de bord sprints (créer/rejoindre une session) | 30h |
| Jeu binome temps réel (logique tour par tour, suivi d'erreurs, synchronisation Firestore) | 45h |
| Configuration Firebase multi-service (Auth, Firestore, Crashlytics) | 10h |
| Icônes & configuration Android | 5h |
| Qualité (lints, test) | 10h |
| Total | 155 heures |
Équivalent : ~19 jours de travail (base 8h/jour), soit environ 1 mois pour un développeur à temps plein.
Valorisation selon profil et marché
| Profil | Tarif journalier | Estimation totale |
|---|---|---|
| Développeur senior — France (freelance) | 600 €/j | 11 600 € |
| Agence web — France | 800 €/j | 15 500 € |
| Développeur senior — Europe (freelance) | 400 €/j | 7 700 € |
| Développeur senior — Maghreb (freelance) | 250 €/j | 4 800 € |
Comparaison avec le marché
| Type de projet comparable | Fourchette marché |
|---|---|
| App mobile simple (auth + une vue de données) | 5 000 € — 12 000 € |
| Jeu mobile temps réel en duo (synchronisation live) | 10 000 € — 20 000 € |
| Yo3eenApp (portage GetX/Firebase, jeu temps réel + intégration inter-app) | 9 000 € — 17 000 € |
Résumé exécutif
Ce que représente ce projet
Yo3eenApp est le client mobile le plus abouti des deux portages Flutter audités à ce jour :
- 5 écrans, tous branchés — pas de code mort constaté côté navigation, contrairement à YofeedApp
- Un jeu en duo temps réel — reclassement de versets coraniques synchronisé via Firestore, sans backend HTTP séparé
- Une intégration inter-applications réelle — lancement natif de l'app sœur YofeedApp
- Un test avec assertion réelle, pas un simple placeholder
- Une documentation (README) partiellement obsolète — décrit une architecture polling/Redis qui n'existe plus dans le code, remplacée par du Firestore temps réel
Indicateurs vérifiables statiquement
(Aucun flutter analyze/flutter test/build n'a été exécuté pour ce rapport — indicateurs vérifiables directement dans le code.)
| Critère | Résultat |
|---|---|
| Lints Flutter | 🟢 flutter_lints configuré |
| Tests | 🟢 1 fichier avec assertion réelle (vs. placeholder chez YofeedApp) |
| Écrans codés mais non routés | 🟢 Aucun détecté |
| Firebase configuré | 🟢 google-services.json présent, Auth + Firestore + Crashlytics |
| Cohérence documentation/code | 🟠 README décrit un backend HTTP/Redis absent du code réel (Firestore temps réel utilisé à la place) |
| Plateformes | 🟠 Android uniquement (iOS non configuré, comme YofeedApp) |
| Durée du projet | 🔵 Portage court, quelques semaines (volume de code cohérent avec ~1 mois de travail) |
Estimation finale
Entre 9 000 € et 17 000 € selon les standards du marché français, pour un portage mobile développé par 1 développeur en environ 1 mois.
Rapport généré le 2 août 2026 — données extraites directement du codebase (comptages de fichiers, lignes, dépendances, routes) Aucun audit flutter analyze/test/build n'a été exécuté pour produire ce rapport — voir section "Indicateurs vérifiables statiquement"