HugoBoulicaut–Raffort

En deux lignes

App mobile cross-plateforme (iOS, Android, Web, macOS). 15 écrans d'onboarding construisent un profil nutritionnel côté serveur (BMR, TDEE, macros), puis un backend VPS orchestre un LLM pour générer repas, recettes et planning — ajustés au profil réel, pas à un régime standard.

Ce qu'il fallait résoudre

Manger équilibré selon son budget, ses goûts et son temps demande un vrai effort quotidien. Les apps de diète imposent des plans rigides, ignorent le contexte (courses, envie, timing) et laissent peu la main à l'utilisateur.

L'approche retenue

L'onboarding bâtit un profil complet en 15 étapes. Le serveur calcule les macros, construit les prompts, appelle le LLM, renvoie du JSON strict. Le client Flutter — MVVM + Provider — parse avec défense, affiche via GoRouter, gère l'achat via RevenueCat. Les réponses LLM sont normalisées avant d'atteindre la présentation.

Ce que le projet fait

• 01

  Onboarding 15 écrans

  Profil complet : objectif, morphologie, contraintes, activité. Le serveur calcule BMR, TDEE et macros cibles, mis en cache local pour la session.

• 02

  Repas suggérés par LLM

  Onglet Home — idées contextualisées (petit-déj, déjeuner, dîner, snack) selon les contraintes. Recette détaillée à la demande.

• 03

  Planning hebdomadaire

  Onglet Week — grille 7 jours × repas. Re-génération case par case, export des ingrédients vers les Courses.

• 04

  Courses agrégées

  Les ingrédients du planning groupés par catégorie, quantités ajustées. Cochables, persistants entre sessions.

• 05

  Paywall RevenueCat

  Abonnement natif sur App Store, Play Store, Web. Gate les fonctions premium (planning illimité, recettes avancées).

• 06

  Une base, quatre plateformes

  iOS, Android, Web, macOS. Une seule base Flutter, transitions GoRouter adaptées à chaque plateforme.

Comment c'est construit

Client Flutter en trois couches : Presentation (Screens + widgets Material 3), ViewModels (ChangeNotifier Provider), Services (API, auth, billing). Domain models immutables avec fromJson/toJson défensifs. Navigation GoRouter, transitions custom par plateforme. Côté serveur, une API REST sur VPS orchestre : profil → calculs nutritionnels → prompts → LLM → normalisation JSON stricte → réponse. Credentials dans un .env chargé au boot via flutter_dotenv. RevenueCat gère les trois stores de facturation. SharedPreferences persiste profil, planning et courses en local.

À retenir

• 01

  MVVM strict — 8 ViewModels découplés, chacun testé isolément.

• 02

  Backend VPS orchestre le LLM. Le client ne voit jamais le prompt brut, uniquement du JSON typé.

• 03

  Parsing défensif : les sorties LLM arrivent parfois enrobées de markdown ou de texte parasite. Les fromJson nettoient et isolent le JSON valide avant de planter.

• 04

  Domain models immutables. Toute mutation passe par copyWith, zéro surprise d'état partagé.

• 05

  Calculs BMR/TDEE/macros côté serveur. Une seule source de vérité, les formules évoluent sans re-livrer l'app.

• 06

  Google Sign-In v7 + Sign in with Apple. Sessions unifiées, tokens rafraîchis en silence.

Ce qui a demandé des choix

• Domestiquer le LLM

  Les réponses arrivent propres, parfois enrobées de ```json, parfois en texte libre avec des retours à la ligne parasites. Les fromJson nettoient et isolent le JSON valide avant qu'il atteigne la couche présentation.

• Quatre plateformes, une logique

  iOS et Android demandent deux providers d'auth natifs (Google, Apple) et deux stores de billing. Le Web et macOS exigent une dégradation propre quand l'API native n'existe pas.

• 15 écrans sans perdre l'utilisateur

  Chaque étape capture un champ ou un choix et autorise le retour arrière sans perte. Un seul ViewModel porte l'état jusqu'à la soumission finale.

Client mobile

Flutter 3.5+DartMaterial 3GoRouterProvider (ChangeNotifier)

Auth & Billing

Google Sign-In v7Sign in with AppleRevenueCat (purchases_flutter)

Back / Data

API REST (VPS)Orchestration LLMSharedPreferencesflutter_dotenv

Média & UX

Lottieflutter_svgPexels (photos de repas)permission_handler

Outillage

flutter_test (8 ViewModels sous test)Mocks APIEnv stagé .env

En deux lignes

Projet de recherche backend. Une API FastAPI sur Azure génère des agents, délègue le calcul à un Raspberry Pi branché au bureau d'étude via WebSocket sortant, persiste dans Supabase, et renvoie la distribution — tout se calcule, rien ne s'invente.

Ce qu'il fallait résoudre

Demander à un LLM unique « que pense le public ? », c'est demander à une seule tête. Cher, lent, imprévisible, aucune distribution en sortie — une moyenne n'a jamais fait un sondage.

L'approche retenue

100 agents tirés sur 5 clusters politiques français : centre-gauche progressiste, centre-droite conservateur, gauche radicale, droite radicale, divers. Chaque agent porte 4 axes idéologiques et 5 axes démographiques. Le moteur détecte les topics via 22 regex, pondère les axes, applique les modificateurs démographiques, injecte un bruit gaussien seedé par paire agent × question — et sort une distribution en moins de 200 ms.

Ce que le projet fait

• 01

  5 clusters politiques français

  Population tirée sur gaussiennes centrées autour des cinq pôles du paysage français. Les axes démographiques — âge, éducation, classe sociale, urbain/rural — corrèlent avec les axes idéologiques, pas à l'aveugle.

• 02

  Moteur heuristique 22 topics

  Immigration, nucléaire, retraites, pouvoir d'achat, Europe, laïcité… Chaque topic est un couple (regex, poids par axe). Une question transversale matche plusieurs topics, les poids se moyennent automatiquement.

• 03

  100 % reproductible

  Même seed, mêmes agents, mêmes réponses. Chaque paire agent × question a son propre RNG dérivé d'un hash MD5 — indispensable pour comparer deux scénarios ou calibrer les poids sans bruit parasite.

• 04

  Calcul sur Raspberry Pi

  Le moteur tourne sur un Pi physique, au bureau d'étude. Connexion WebSocket sortante vers le backend, aucun port exposé, aucune IP publique requise. Reconnexion automatique avec backoff 1 s → 60 s.

• 05

  Calibration contre sondages IFOP

  10 cas de référence tirés de sondages IFOP. Chaque modification de poids est évaluée contre ces distributions avant merge — le moteur ne dérive pas en silence.

• 06

  Trois formats de questions

  Stance (pour/contre/mitigé), likert (échelle numérique), QCM (choix multiples). Les trois cohabitent dans un même questionnaire, agrégation automatique par type.

Comment c'est construit

Deux dépôts, trois étages physiquement séparés. Le backend FastAPI vit containerisé sur un VPS Azure, derrière un Nginx qui termine le TLS et proxifie HTTP comme WebSocket (timeout 3600 s). L'API parle à Supabase — 11 tables métier, relations tracées avec CASCADE et RESTRICT réfléchis — et délègue tout le calcul de simulation à un Raspberry Pi branché au bureau d'étude. Le Pi ouvre lui-même la connexion WebSocket, pas l'inverse ; chaque appel est corrélé par un task_id UUID géré par PiWsManager. Redis porte les sessions et la canalisation realtime. Côté livraison, deux workflows GitHub Actions : le CI lint (ruff), teste (pytest, cov ≥ 90 %), build l'image Docker et push sur GHCR ; le CD, déclenché au succès du CI, SCP le compose, SSH pour pull/up --force-recreate, boucle un healthcheck 30 fois, prune les images, recharge Nginx. Dev bascule sur staging, main sur prod.

À retenir

• 01

  Architecture hexagonale — endpoints, services, repositories, infrastructure. Les tests injectent FakePiClient et FakeRepository, zéro accès réseau.

• 02

  WebSocket sortant initié par le Pi — aucun port ouvert derrière le NAT domestique, aucun DynDNS à maintenir.

• 03

  Corrélation backend ↔ Pi par task_id UUID. PiWsManager expose un call_sync aux endpoints HTTP synchrones.

• 04

  Moins de 200 ms pour 100 agents × 5 questions. Zéro LLM, zéro appel externe en prod.

• 05

  Deux environnements mappés sur des GitHub environments distincts — dev bascule sur staging, main sur prod.

• 06

  Déploiement SSH avec healthcheck actif (30 tentatives, 2 s d'intervalle) — aucune validation avant que l'API réponde.

Ce qui a demandé des choix

• Encoder une opinion dans un scalaire

  Le vrai travail de fond. Trouver les bons poids par axe pour chaque topic, pour que la distribution colle à celle d'un vrai sondage. Beaucoup d'allers-retours sur la polarité (réduire / renforcer / négation) et les modificateurs démographiques — calibrés contre 10 sondages IFOP de référence.

• Tunneler le Pi sans l'exposer

  Le Pi vit derrière un NAT domestique. Contrainte : zéro port entrant, zéro IP publique, zéro DynDNS. Réponse : un WebSocket sortant permanent initié par le Pi, avec reconnexion automatique (backoff 1 s → 60 s) et corrélation des appels par task_id UUID côté backend.

• CI/CD zéro-intervention

  Rendre le déploiement impossible à casser à la main. Pipeline : lint → tests → build Docker → push GHCR → SCP compose → SSH pull/up --force-recreate → healthcheck 30 tentatives → prune → nginx reload. Dev bascule sur staging, main sur prod, via GitHub environments distincts — aucun SSH manuel requis.

API (cloud)

FastAPIPython 3.13PydanticUvicorn

Worker (edge)

Raspberry PiwebsocketssystemdMoteur heuristique (pure stdlib)

Data

SupabasePostgreSQLRedis

Infra

VPS AzureDocker ComposeNginx (TLS + WSS)GHCR

CI/CD

GitHub Actions (CI + CD)ruff check & formatpytest cov ≥ 90 %SSH deploy + healthcheck 30 tentatives