Application mobile Flutter qui transforme les habitudes du quotidien en quêtes RPG. L'utilisateur photographie sa preuve, un modèle de vision l'analyse et attribue un score, la récompense tombe en XP, en or et en objets. Conçue, développée et déployée en solo, de l'architecture à la chaîne de livraison, comme projet de certification RNCP 39583.
L'utilisateur crée ses propres quêtes (ranger, cuisiner, étudier, faire du sport) réparties en domaines de vie. Les accomplir rapporte de l'expérience, de l'or et des objets, avec une progression de niveau et un suivi de série.
La faiblesse des applications d'habitudes est la validation déclarative : cocher une case ne prouve rien. Sameva demande une photo ou une courte vidéo, analysée par un modèle de vision qui rend un score sur 100. Au-delà de 70, la récompense est pleine.
Principe produit non négociable : si l'analyse échoue ou refuse, l'utilisateur valide manuellement avec une récompense réduite. Aucune panne réseau, aucun faux négatif ne peut enfermer quelqu'un dans un échec. Ce choix est traduit dans le code par un service de repli systématique.
La thèse du produit tient en une phrase : atteindre un objectif réel mérite une récompense réelle. D'où la couche de méta-jeu, collection de companions, invocations, inventaire d'objets et classement, qui donne une raison de revenir le lendemain.
Chiffres relevés sur la version 1.0.4, dernière livrée.
MVVM sur quatre couches (données, domaine, présentation, interface), état géré via Provider et ChangeNotifier. Environ cent fichiers organisés par responsabilité, ce qui rend chaque règle métier testable indépendamment de l'interface.
Les données sont écrites d'abord en local avec Hive, puis synchronisées avec le serveur. L'application reste utilisable sans réseau : on peut créer une quête, la valider et voir sa progression, la remontée se fait au retour de la connexion.
Supabase pour PostgreSQL, l'authentification et le stockage, avec des politiques de sécurité au niveau des lignes pour que chaque utilisateur ne voie que ses propres données. Cinq Edge Functions en Deno et TypeScript portent la logique qui ne doit pas vivre côté client.
L'entrée se fait sans inscription grâce à une session anonyme : on joue immédiatement. L'utilisateur peut ensuite créer un compte par e-mail ou via Google, et sa progression est conservée par liaison d'identité plutôt que par création d'un nouveau compte.
Modèle freemium adossé à Stripe, avec un abonnement mensuel. L'état premium est déterminé côté serveur et jamais côté application, pour qu'aucune modification locale ne puisse débloquer les fonctions payantes.
Trois chaînes GitHub Actions : analyse statique et exécution des 505 tests à chaque poussée, déploiement du backend, et production de l'APK signé sur étiquette de version. Le paquet livré est reproductible, signé avec un magasin de clés stable.
MougiBot est l'assistant qui juge les preuves. Derrière ce personnage, un modèle de vision appelé depuis une Edge Function : la clé d'API ne quitte jamais le serveur et l'application mobile ne connaît que le score.
L'utilisateur photographie sa preuve depuis l'application.
Le média part vers le stockage Supabase, jamais vers un tiers en direct.
Une Edge Function construit la requête et appelle le modèle de vision.
Le modèle rend un score sur 100 et un commentaire écrit.
Au-delà de 70, récompense pleine. En dessous, validation manuelle réduite.
Un service de validation simulé est interchangeable avec le service réel derrière la même interface. Il permet de faire tourner l'application entière sans aucune clé d'API, ce qui sert autant à l'exécution des tests automatisés qu'à la démonstration hors ligne.
C'est le même mécanisme qui garantit le principe « jamais bloqué » : une indisponibilité du modèle dégrade l'expérience, elle ne l'interrompt pas.
La preuve visuelle couvre les quêtes dont le résultat est observable : une chambre rangée, un repas préparé, une plante arrosée. Elle ne couvre pas les quêtes de durée, parce qu'aucune image ne démontre trente minutes de course à pied.
Ces quêtes-là relèvent d'autres modes de preuve, chronomètre intégré, trace GPS ou connexion à une application de santé, identifiés et spécifiés mais volontairement hors du périmètre de cette première version.
L'identité repose sur Paco, un chat tuxedo au style mascotte cartoon, et sur sa déclinaison MougiBot qui incarne l'assistant d'analyse. Paco porte la marque, il n'est pas une unité de jeu : les personnages jouables et les companions relèvent d'un registre graphique distinct, en cours de conception.
PacoMascotte de la marque
MougiBotVisage de l'assistant d'analyse
CélébrationÉcran de récompense
WordmarkItalique, contour violet
Objets à collectionner : registre streetwear, palette contrainte.
La direction artistique définitive, notamment les quatre classes de personnages et le bestiaire de companions, sera confiée à un illustrateur professionnel après la certification. Les visuels présentés ici sont des recherches de production servant à cadrer la commande.
Sameva est un produit en construction, pas une vitrine. Voici précisément la frontière entre ce qui tourne, ce qui est en cours et ce qui reste devant.
Sameva est le projet support du titre Expert en développement logiciel, niveau 7, RNCP 39583, préparé à YNOV Campus sur la promotion 2025-2026. Il est conduit comme une prestation pour un client fictif, ce qui impose de tenir seul l'ensemble des rôles : cadrage, architecture, développement, qualité, déploiement et pilotage.
Soutenance orale. Analyse du besoin, étude comparative, faisabilité technique et budgétaire.
Dossier écrit remis. Architecture applicative, choix techniques, qualité logicielle.
Dossier écrit remis. Chaîne de livraison, supervision, sécurité et maintien en condition opérationnelle.
Soutenance orale à venir, accompagnée d'une démonstration de l'application en fonctionnement.