Rapport d'estimation — lami1aBerry

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

lami1aBerry (dossier /stages.loc) est un produit à part : la même famille fonctionnelle que yofeed.liismaiil.org (suivi de stages, interns, insight, sprints), mais repensée pour tourner entièrement hors connexion internet, sur un boîtier Raspberry Pi 4 faisant office de point d'accès WiFi autonome.

Le package.json porte encore le nom hérité yofeed.liismaiil.org (fork historique), mais le produit réel est différent :

Base de données locale SQLite (Prisma 7 + adapter @prisma/adapter-libsql) au lieu de Firebase/Firestore cloud — la migration Firebase → Prisma dans /actions/ (le vrai backend applicatif) est terminée
Zéro dépendance internet en fonctionnement normal — sur site, l'Ethernet reste branché en continu pour l'administration/NTP, et le WiFi (wlan0) sert uniquement de point d'accès local ("StagesLoc") pour les téléphones des invités
Paiement Stripe réellement branché (checkout + session, pour la boutique de cadeaux), contrairement à yofeed.liismaiil.org où seuls des champs de données préparatoires existaient
Plateaux d'évaluation en drag & drop modernisés (@dnd-kit, 9 fichiers) et graphiques ApexCharts en complément de D3
Un boîtier Raspberry Pi réellement déployé et testé en conditions réelles — pas seulement documenté sur le papier

Le Pi (hostname lami1a1) a été testé fonctionnel depuis un vrai téléphone le 12 juillet 2026 (signin, signup, carte intern, connexion au hotspot StagesLoc), avec la base de données de production déjà chargée : 294 stages, 114 templates, 311 ayah_templates. Capacité estimée : 20 à 40 invités simultanés sur un Pi 4 (4 Go). Le clonage en série (plusieurs unités identiques) est planifié et documenté, mais pas encore réalisé — prochaine étape du projet, pas un acquis.

Architecture applicative

Routes web (193 fichiers, ~26 500 lignes)

Route	Rôle
`/`, `/signin`, `/about`	Accueil, authentification, présentation
`/interns`	Dashboard de suivi des stagiaires
`/insight` (+ parallel routes `@souras`, `@template`)	Visualisations D3 + ApexCharts
`/stages` (+ parallel route `@steps`)	Suivi de progression, plateaux d'évaluation `@dnd-kit`
API : `auth`, `guests`, `hosts`, `domain`, `sprints`, `stages`, `templates`, `stripe/checkout`, `stripe/session`	Backend applicatif complet, y compris un vrai tunnel de paiement Stripe

98 composants React, 5 slices Redux actives (stageSlice, guestPrismaSlice, searchSlice, lessonSlice, coursSlice).

Note nettoyage (non traité dans cet audit) : comme pour le projet /stages déjà audité, components/ contient encore des fichiers .txt désactivés (37 constatés, dont 3 slices Redux productSlice.txt, viewerSlice.txt, snackbarSlice.txt) — même lignée de code, mêmes résidus. Je ne les ai pas supprimés ici, contrairement à /stages où tu me l'avais explicitement demandé ; dis-moi si tu veux le même nettoyage sur ce dépôt.

Modèle de données — 15 modèles Prisma/SQLite

Guest, Favorite, Stage, Sprint, StatTayseer, GuestStage, GuestSprint, Template, AyahTemplate, Viewer, Session, Stat, TayfeedStage, TayfeedRecord, Gift — un schéma relationnel complet, cohérent avec un fonctionnement 100% local (pas de synchronisation cloud requise). Deux modèles (Session, Stat) sont présents dans schema.prisma mais leur migration vers la DB de production n'était pas encore appliquée à la dernière session de travail documentée — point à vérifier plutôt qu'à considérer acquis.

La validation de progression est fine : chaque GuestStage a un gridIndex, un validatedAt (horodatage réel de validation, utilisé directement dans le diagramme D3 de /interns) et un nbErrors — la visualisation /interns n'est pas une maquette, elle reflète l'historique réel d'un guest.

Infrastructure d'exploitation — le vrai différenciateur

C'est la partie qui distingue le plus ce projet des autres rapports déjà produits : un travail d'ingénierie systèmes/réseau généralement absent d'un projet web classique.

Composant	Détail
Cross-compilation Docker arm64	`Dockerfile` multi-stage, build depuis un poste de dev via `docker buildx build --platform linux/arm64`, sortie Next.js standalone
SQLite en production	Adapter `@prisma/adapter-libsql` en WASM (pas de moteur natif à recompiler pour arm64) ; PM2 en cluster limité à 2 instances — commentaire explicite dans `ecosystem.config.js` sur la contention d'écriture SQLite au-delà
Point d'accès WiFi dédié	`hostapd` + `dnsmasq`, `wlan0` en IP statique `192.168.4.1` (réseau "StagesLoc") géré hors NetworkManager ; `eth0` reste disponible en continu sur le lieu réel des sessions pour l'administration/NTP — pas de bascule client→AP dynamique (`wifi-sync-then-ap.sh` existe dans le repo mais ce n'est pas le mécanisme réellement utilisé en production, cf. note ci-dessous)
Supervision systemd	`hostapd-watchdog.timer` (20 min — le chipset WiFi du Pi 4 est connu pour se figer en mode AP), `wal-checkpoint.timer` (6h — évite que le fichier SQLite `-wal` grossisse indéfiniment), `reboot-check.timer` (reboot contrôlé uniquement si patch noyau en attente, jamais surprise), watchdog matériel — objectif documenté : ~1 an sans reboot surprise
Reverse proxy	`nginx-stages-loc.conf` → `stages.loc` proxy vers PM2 `127.0.0.1:3015`
Procédure de déploiement — exécutée, pas juste écrite	`deploy/DEPLOY.md` suivi de bout en bout sur un vrai Pi 4 (reflash 64-bit, Node 24, PM2, nginx, hostapd/dnsmasq) ; 8 pièges réels documentés en cours de route (ex : `.yarnrc.yml` pin Yarn 3.8.7, exclure `.yarn/` d'un rsync casse `yarn install` ; `prisma.config.ts` chargeait un chemin DB différent du runtime → "no such table" ; `dnsmasq` sur Debian Trixie a ses `conf-dir=` commentés par défaut → pas d'IP distribuée en WiFi malgré un handshake WPA réussi)
Clonage en série — planifié, pas encore fait	`deploy/CLONE-CARDS.md` décrit la méthode prévue (image réduite via PiShrink, régénération d'identité machine/SSH au premier boot) mais c'est un plan pour une prochaine session, pas une procédure déjà validée sur une 2ᵉ carte

Volume et complexité technique

Chiffres mesurés directement sur le codebase

Indicateur	Valeur
Fichiers source (TypeScript + React)	193 fichiers
Lignes de code	~26 500 lignes
Composants React	98 composants
Modèles de données (Prisma/SQLite)	15 modèles
Slices Redux actives	5 (+ 3 fichiers désactivés `.txt` non comptés)
Fichiers liés à Stripe (checkout + session réels)	10 fichiers
Fichiers utilisant `@dnd-kit` (plateaux drag & drop)	9 fichiers
Fichiers utilisant ApexCharts	1 fichier
Tests automatisés	0 — `playwright.config.ts` présent, aucun fichier de test trouvé
Dépendances	78 packages (54 production + 24 dev)
Services systemd d'exploitation	5 (watchdog WiFi, reboot check, checkpoint WAL, IP statique, point d'accès)

Stack technique

Couche	Technologie	Usage
Framework	Next.js 14 (App Router)	Route groups + parallel routes, sortie standalone
Interface	HeroUI + Tailwind CSS + Framer Motion	Design system + animations
State	Redux Toolkit	Gestion d'état globale
Base de données	SQLite locale via Prisma + `@prisma/adapter-libsql` (WASM)	Fonctionnement 100% offline, pas de cloud
Authentification	JWT (`jose`)	Local, sans dépendance Firebase Auth cloud
Paiement	Stripe (checkout + session)	Tunnel de paiement réellement implémenté
Visualisation de données	D3.js + ApexCharts	Graphiques custom et standards combinés
Interactions	`@dnd-kit`	Plateaux d'évaluation drag & drop
Déploiement	Docker (cross-build arm64), PM2 cluster, systemd	Boîtier Raspberry Pi 4 autonome
Réseau	hostapd + dnsmasq (wlan0) + Ethernet continu (eth0)	Point d'accès WiFi dédié aux invités, Ethernet pour l'admin/NTP
Tests	Playwright (configuré, non utilisé)	0 test écrit

Estimation financière

Méthodologie

Estimation basée sur le volume de code mesuré, la complexité applicative (paiement réel, drag & drop, 15 modèles de données) et le travail d'ingénierie systèmes/réseau nécessaire au fonctionnement offline sur Raspberry Pi — un poste généralement absent des projets web classiques déjà audités.

Décomposition par module

Module	Heures
Architecture Next.js App Router (route groups, parallel routes, middleware)	45h
Authentification JWT locale	40h
Dashboard interns	100h
Module insight (D3 + ApexCharts)	110h
Module stages (plateaux d'évaluation `@dnd-kit`)	130h
Abonnement & paiement Stripe (checkout + session, branché)	60h
Modèle de données Prisma/SQLite (15 modèles) + migrations	70h
Portage offline Raspberry Pi (Docker arm64, adapter SQLite WASM, PM2, systemd, WiFi hotspot, nginx, clonage SD)	90h
Qualité du code	20h
Total	665 heures

Équivalent : ~83 jours de travail (base 8h/jour), soit environ 4 mois pour un développeur à temps plein.
Le poste "portage offline Raspberry Pi" mobilise des compétences réseau/systèmes (hostapd, systemd, SQLite en production, cross-compilation arm64) distinctes du développement web pur — sur le marché, ce type de travail se facture souvent à un tarif spécialisé plus élevé que les tarifs de développeur web utilisés ci-dessous, qui restent une estimation conservatrice à tarif unique.

Valorisation selon profil et marché

Profil	Tarif journalier	Estimation totale
Développeur senior — France (freelance)	600 €/j	50 000 €
Agence web — France	800 €/j	66 000 €
Développeur senior — Europe (freelance)	400 €/j	33 000 €
Développeur senior — Maghreb (freelance)	250 €/j	21 000 €

Comparaison avec le marché

Type de projet comparable	Fourchette marché
SaaS B2B avec dashboard, paiement et drag & drop	30 000 € — 55 000 €
Solution offline/edge sur boîtier dédié (réseau, supervision, déploiement série)	20 000 € — 40 000 €
lami1aBerry (cumul des deux : app complète + ingénierie offline Raspberry Pi)	45 000 € — 70 000 €

Résumé exécutif

Ce que représente ce projet

lami1aBerry est un produit hybride rare : une application web complète et un appareil physique autonome prêt à être dupliqué :

Une plateforme complète — stages, interns, insight, paiement Stripe réel, drag & drop moderne
Un fonctionnement 100% offline — SQLite locale, aucune dépendance cloud en usage normal
Un boîtier Raspberry Pi réellement testé — validé depuis un vrai téléphone le 12 juillet 2026 (signin, signup, hotspot StagesLoc), avec des données de production déjà chargées (294 stages, 114 templates)
Une supervision système pensée pour la fiabilité — watchdogs, redémarrages contrôlés, checkpoint SQLite, objectif ~1 an sans incident
Une prochaine étape identifiée mais pas encore faite — le clonage de cartes SD pour dupliquer l'unité vers d'autres Pi est planifié et documenté, pas encore validé sur une deuxième unité

Indicateurs vérifiables statiquement

(Aucun audit Lighthouse, build ou déploiement live n'a été lancé pour ce rapport — indicateurs vérifiables directement dans le code et les fichiers de configuration.)

Critère	Résultat
TypeScript strict	🟢 Présent sur l'essentiel du codebase
Tests automatisés	🔴 Aucun (Playwright configuré, 0 fichier de test)
Fichiers `.txt` désactivés dans `components/`	🟠 37 constatés, non traités (hors périmètre de cet audit)
Migrations Prisma en attente	🟠 `Session`, `Stat` définis dans le schéma, migration DB à vérifier
Documentation de déploiement	🟢 Runbook complet (`DEPLOY.md`) suivi de bout en bout, 8 pièges réels documentés
Déploiement réel constaté	🟢 Unité `lami1a1` testée depuis un vrai téléphone le 12 juillet 2026 (signin, signup, hotspot), DB de prod déjà chargée (294 stages)
Clonage de cartes SD en série	🟠 Planifié (`CLONE-CARDS.md`), pas encore exécuté sur une 2ᵉ carte
Durée du projet	🔵 Non déterminable via git (historique réécrit) — volume de code cohérent avec ~4 mois de travail

Estimation finale

Entre 45 000 € et 70 000 € selon les standards du marché français, pour une application + solution de déploiement offline développée par 1 à 2 développeurs en environ 4 mois.

Rapport généré le 2 août 2026 — données extraites directement du codebase et des fichiers de déploiement (comptages de fichiers, lignes, dépendances, routes, configuration systemd) Aucun audit Lighthouse, build ou test live n'a été exécuté pour produire ce rapport — voir section "Indicateurs vérifiables statiquement"