statuts & projects
Rapport d'estimation — YofeedApp
Rapport d'estimation — YofeedApp
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
YofeedApp (dossier /stages_flutter, nom technique stages_flutter) est le client mobile Android du projet yofeed.liismaiil.org — un portage Flutter de l'architecture web déjà auditée (voir rapport yofeed.liismaiil.org), couvrant :
- Une authentification Firebase (
/signin) - Un suivi de progression par stage — vue liste, répétition (rehearsal) et plateau ouvert (openboard)
- Une lecture seule des données Firestore (les écritures passent par l'API Next.js du projet web, pas directement depuis l'app)
- Des écrans interns et gifts avec graphiques (équivalent mobile des visualisations D3 du web), codés mais pas encore branchés à la navigation
C'est un projet court et ciblé (27 fichiers Dart, ~3 400 lignes), pensé comme portage rapide plutôt que comme développement de zéro : l'architecture de données et la logique métier existaient déjà côté web.
Architecture applicative
Routes enregistrées
| Route | Écran | Binding |
|---|---|---|
/signin | Authentification | AuthBinding |
/stages | Vue d'ensemble des stages | StagesBinding |
/stages/rehearsal | Répétition d'évaluation | StagesBinding |
/stages/openboard | Plateau d'évaluation ouvert | StagesBinding + OpenBoardBinding |
Écrans codés mais non branchés à la navigation
Les dossiers views/interns, views/gifts ainsi que leurs contrôleurs et bindings associés (InternsController, GiftsController, InternsBinding, GiftsBinding) existent et sont fonctionnels dans le code, mais ne sont référencés dans aucune route (AppPages/AppRoutes) ni appelés ailleurs dans l'app. Ils représentent un travail réel (statistiques + graphiques fl_chart stacked bar, équivalent mobile des modules D3 insight/gifts du web) mais ne sont pas accessibles à un utilisateur final dans l'état actuel du build.
Modules internes
| Dossier | Rôle |
|---|---|
app/controllers (5) | AuthController, StagesController, InternsController, GiftsController, OpenboardController — logique métier GetX (GetxController, Rx) |
app/bindings (5) | Injection de dépendances GetX, une par écran/groupe d'écrans |
app/views (6) | Signin, Stages, StagesRehearsal, StagesOpenboard, Interns, Gifts |
app/models (5) | StageModel, InternModel, GiftModel, GuestModel, AyahModel |
app/services (1) | FirestoreService — accès Firestore en lecture |
data/flag_options.dart | 10 pays avec URLs de drapeaux (Cloudinary) |
Volume et complexité technique
Chiffres mesurés directement sur le codebase
| Indicateur | Valeur |
|---|---|
| Fichiers source (Dart) | 27 fichiers |
| Lignes de code | ~3 400 lignes |
| Routes enregistrées | 4 (+ 2 écrans codés non branchés : interns, gifts) |
| Contrôleurs GetX | 5 |
| Bindings (DI) | 5 |
| Modèles de données | 5 |
| Services | 1 (FirestoreService) |
| Tests | 1 fichier — test placeholder (expect(true, isTrue)), pas de couverture réelle |
| Dépendances | 13 packages (10 production + 3 dev) |
| Plateformes cibles | Android uniquement (flutter_launcher_icons a ios: false explicitement) |
Stack technique
| Couche | Technologie | Usage |
|---|---|---|
| Framework | Flutter 3.38 / Dart 3.10 | App mobile Android |
| État & routing | GetX (get) | GetxController, Rx, GetMaterialApp, GetPage |
| Base de données | Firebase/Firestore | Lecture directe côté client ; écritures via l'API Next.js du projet web (pas de write client) |
| Authentification | Firebase Auth | + shared_preferences pour la persistance de session (remplace le cookie JWT web) |
| Suivi d'erreurs | Firebase Crashlytics | Configuré (google-services.json présent, appId Firebase enregistré) |
| Graphiques | fl_chart | Barres empilées pour Interns et Gifts — équivalent mobile des visualisations D3 du web |
| Images | cached_network_image + url_launcher | Drapeaux pays (Cloudinary) |
| Tests | flutter_test | Configuré, mais un seul test placeholder |
| Lints | flutter_lints | Config par défaut (analysis_options.yaml) |
Estimation financière
Méthodologie
Estimation basée sur le volume de code mesuré, la nature de portage (architecture et logique déjà validées côté web) et les standards du marché pour un développeur Flutter/mobile senior.
Décomposition par module
| Module | Heures |
|---|---|
| Architecture Flutter/GetX (routes, bindings, DI, restauration de session) | 15h |
| Authentification (Firebase Auth + écran signin + persistance session) | 20h |
| Module stages (vue d'ensemble + rehearsal + openboard) | 35h |
Écrans interns & gifts (statistiques + graphiques fl_chart) | 25h |
| Intégration Firestore (lecture) + modèles de données | 20h |
| Configuration Firebase multi-service (Auth, Firestore, Crashlytics) | 10h |
Icônes & configuration Android (flutter_launcher_icons) | 5h |
| Qualité (lints, test placeholder) | 10h |
| Total | 140 heures |
Équivalent : ~18 jours de travail (base 8h/jour), soit environ 1 mois pour un développeur à temps plein — cohérent avec un portage rapide plutôt qu'un développement de zéro.
Valorisation selon profil et marché
| Profil | Tarif journalier | Estimation totale |
|---|---|---|
| Développeur senior — France (freelance) | 600 €/j | 10 800 € |
| Agence web — France | 800 €/j | 14 400 € |
| Développeur senior — Europe (freelance) | 400 €/j | 7 200 € |
| Développeur senior — Maghreb (freelance) | 250 €/j | 4 500 € |
Comparaison avec le marché
| Type de projet comparable | Fourchette marché |
|---|---|
| App mobile simple (auth + une vue de données) | 5 000 € — 12 000 € |
| Client mobile d'une plateforme web existante (portage) | 8 000 € — 18 000 € |
| YofeedApp (portage GetX/Firebase, écrans additionnels non finalisés) | 8 000 € — 16 000 € |
Résumé exécutif
Ce que représente ce projet
YofeedApp est un client mobile Android ciblé, portage de l'architecture déjà développée côté web :
- Une authentification Firebase avec persistance de session locale
- Un suivi de stage mobile — vue d'ensemble, répétition, plateau d'évaluation ouvert
- Des écrans interns/gifts codés (statistiques + graphiques) mais pas encore branchés à la navigation
- Une architecture Firestore en lecture seule, cohérente avec la séparation lecture/écriture du système web (écritures via l'API Next.js)
- Un périmètre Android uniquement à ce stade — le portage iOS n'est pas configuré
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é (config par défaut) |
| Tests | 🔴 1 seul fichier, test placeholder sans assertion réelle |
| Écrans codés mais non routés | 🟠 2 (interns, gifts) |
| Firebase configuré | 🟢 google-services.json présent, Auth + Firestore + Crashlytics |
| Plateformes | 🟠 Android uniquement (iOS non configuré) |
| Durée du projet | 🔵 Portage court, quelques semaines (volume de code cohérent avec ~1 mois de travail) |
Estimation finale
Entre 8 000 € et 16 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"