Luniqo
Logiciel de gestion de crèches : enfants et familles, pointage des présences sur
tablette, personnel, fiche de ménage, portail des parents.
Ce README s'adresse aux développeurs qui rejoignent le projet. Pour contribuer
(branches, versions, tickets, PR), lire ensuite CONTRIBUTING.md.
Nouvel arrivant ? Commencer par ONBOARDING.md : le parcours
pas à pas, du premier accès à la première PR fusionnée.
TP Docker (M2, Ynov Toulouse) : tout le rendu est dans le dossier
docker/, sur cette branche par défaut (develop), figé au tag
tp-docker-v2.
Le projet
D'où il vient
Luniqo est né d'un besoin réel : la directrice d'une micro-crèche de
Haute-Garonne remplissait chaque jour à la main ses fiches de ménage et devait
les conserver. Le premier module les a digitalisées. Le projet s'est ensuite
étendu à la cuisine (HACCP), puis à tout ce qu'une crèche gère au quotidien,
pour viser les micro-crèches, les crèches et les groupes qui en possèdent
plusieurs.
Ce qu'il fait : le parcours central
Une entreprise (compte commercial) gère une ou plusieurs crèches. Le
parcours qui doit fonctionner de bout en bout :
- La direction crée une crèche et donne accès à son personnel.
- Sur la tablette de la crèche, un employé tape son PIN et pointe l'arrivée
puis le départ d'un enfant. Le départ est refusé si la personne venue le
chercher n'y est pas autorisée.
- La direction consulte les présences du jour.
- Un parent, invité par la crèche, ne voit que ses propres enfants.
- Un accès à une crèche d'une autre entreprise est refusé.
| Rôle | Ce qu'il fait |
|---|
Direction (owner) | Gère les crèches de son entreprise, le personnel, les familles. Second facteur obligatoire |
Employé (employee) | Pointe sur la tablette avec son PIN, consulte les crèches qui lui sont accordées |
Famille (guardian) | Consulte les présences de ses enfants |
Éditeur (developer) | Administre la plateforme, sans accès aux données des crèches |
Deux versions dans le même dépôt
| v1 (racine du dépôt) | v2 (dossiers api/ et front/) |
|---|
| Rôle | Application d'origine, gelée : seuls les correctifs de sécurité y entrent | Réécriture progressive avec un vrai backend |
| Technologies | Next.js 16, React 18, Supabase Cloud (accès direct à la base depuis le navigateur) | API : FastAPI (Python 3.14), PostgreSQL 18, SQLAlchemy asynchrone, Alembic. Front : React + Vite, TanStack Router et Query, client typé généré depuis le schéma OpenAPI, Storybook (ADR-002) |
| État au 2026-10-27 | En production sur Vercel, gelée jusqu'à la bascule vers la v2 | Parcours central et fiche de ménage complets côté API, second facteur, purge RGPD. Front v2 : connexion avec second facteur et premier écran (LUN-107) |
Pourquoi réécrire : ADR-001. La
logique métier et les contrôles d'accès de la v1 s'exécutent dans le navigateur.
Navigateur ──HTTP :8080──▶ web (nginx) ──/──────▶ front (nginx : fichiers du front v2, React + Vite)
└─/api/──▶ api (FastAPI, v2) ──SQL──▶ db (PostgreSQL)
v1 : Vercel (Next.js) ──▶ Supabase Cloud, hors de la pile Docker
Installer le projet
Prérequis
| Outil | Version | Pour |
|---|
| Git | récent | tout |
Docker avec Compose v2 (docker compose) | | la pile complète, la base de test |
| Python | 3.14 (version de l'image et de la CI) | l'API v2 |
| Node.js et pnpm | Node 22.12+, pnpm 11 pour le front v2 (corepack pnpm), pnpm 10 suffit pour la v1 | le front v2, le front v1 |
git clone https://github.com/zharrow/Luniqo.git
cd Luniqo
git switch develop # branche d'intégration : on part toujours d'elle
Option 1 : toute la pile avec Docker (le plus simple)
cd docker
docker compose up -d --build # construit les 5 images et lance les 4 services
docker compose ps # db, api, front et web doivent être "healthy"
Pour avoir des comptes de démonstration (données synthétiques, adresses en
.test), créer un fichier .env à la racine du dépôt (jamais versionné) :
API_SEED_DEMO_PASSWORD=une-phrase-de-passe-d-au-moins-15-caracteres
puis lancer depuis docker/ : docker compose --env-file .env --env-file ../.env up -d --build.
Comptes créés : [email protected], [email protected]… La direction doit
enregistrer une application d'authentification (TOTP) à sa première connexion.
Option 2 : travailler sur l'API v2
cd api
python3 -m venv .venv && . .venv/bin/activate
pip install -r requirements-dev.txt
pytest # tests unitaires, sans base (quelques secondes)
scripts/test-db.sh up # PostgreSQL jetable, affiche la ligne export à copier
export TEST_DB_ADDR=127.0.0.1:55432 TEST_DB_NAME=luniqo_test TEST_DB_PASSWORD=luniqo-test
pytest # unitaires + intégration sur la vraie base
scripts/test-db.sh down
ruff check . # lint, comme en CI
Lancer l'API en local, nouvelle migration, variables d'environnement :
api/README.md.
Option 3 : le front v2
cd front
corepack pnpm install
corepack pnpm dev # http://localhost:5173, l'API passe par la pile Docker (port 8080)
corepack pnpm test # tests unitaires, de composants et stories
corepack pnpm storybook # documentation des composants, http://127.0.0.1:6006
Tout le détail : front/README.md.
Option 4 : le front v1
pnpm install
# Créer .env.local (non versionné) avec les variables listées dans CLAUDE.md
# (NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY…)
pnpm dev # http://localhost:3000
La v1 interroge directement un projet Supabase. Ne jamais lancer pnpm seed
sans savoir quelle base est visée : le script écrit avec la clé
d'administration.
Travailler ensemble
| Sujet | Où |
|---|
| Branches, versions (SemVer), cycle de vie d'un ticket, PR, Definition of Done | CONTRIBUTING.md |
| Tickets, sprints, boards | Jira, projet LUN (lien communiqué à l'équipe) |
| Configuration de Jira et de son lien avec GitHub | docs/projet/JIRA.md |
| Versions publiées | CHANGELOG.md et les tags vX.Y.Z |
| Personas et story map (vision produit, MVP) | docs/produit/ : personas, story map |
| Choix techniques et leurs raisons | M2/decisions/, dont le registre |
Équipe du cours « Coordination Front & Back »
| Membre | Rôle |
|---|
| Florent | Chef de projet |
| Thomas | Développeur fullstack |
| Pauline | Développeuse frontend |
| Julien | Développeur backend |
Luniqo est aussi le projet fil rouge du M2 de Florent (Ynov Toulouse) : le
dossier M2/ contient les preuves et la documentation de ce diplôme.
Lancer Luniqo avec Docker (cours Docker, M2)
Le dossier docker/ répond au TP « Projet - Docker Cloud » du M2
(Ynov Toulouse) : concevoir ses propres images, sans Docker Hub, et les
orchestrer avec docker compose. Rendu : tag
tp-docker-v2
(2026-10-29, avec la consigne supplémentaire) ; le sujet initial avait été rendu
au tag tp-docker-v1.
cd docker && docker compose up -d --build # http://localhost:8080
./pipeline.sh --no-deploy # conteneurs lint puis test
bench/bench.sh # consommation CPU de chaque conteneur (pile démarrée)
| Image | Rôle pour le TP | Contenu |
|---|
base | socle commun | Alpine Linux construit depuis scratch, tini, utilisateur non-root |
web | serveur web | nginx, seul point d'entrée : relaie vers le front et l'API |
front | front | le front v2 (React + Vite), construit puis servi par un nginx dédié |
api | back | l'API FastAPI de la v2 (dossier api/) |
db | base de données | PostgreSQL 18, données dans un volume |
lint, test | CI (consigne supplémentaire) | lint (ruff, ShellCheck, refus de toute image Docker Hub) puis tests de l'API sur une base jetable, enchaînés par docker/pipeline.sh |
bench | banc de mesure | générateur de charge wrk pour mesurer la consommation CPU des conteneurs |
| Exigence | Réponse |
|---|
| Aucune image Docker Hub | Toutes les images partent de scratch (archive officielle d'Alpine) ou de notre image base ; compose ne fait jamais de pull |
| Au moins un front, un back et un serveur web | front, api et web, plus db |
| Arguments de ressources au run et dans le compose | Limites CPU, mémoire et processus réglées dans docker/.env, plus des arguments applicatifs alignés sur ces limites (workers, connexions, pool de la base...) |
| Dépendances, manipulations sur l'OS, arguments, entrypoints expliqués | Un README par image : base, db, api, front, web, lint, test, bench |
| Limitations de ressources expliquées | Justifiées par des mesures réelles (repos et charge) dans le README du dossier docker |
| SIGTERM gérés | Chaque service s'arrête proprement (signal adapté à chaque programme) ; toute la pile s'arrête en moins d'une seconde |
Tout le détail (architecture, choix, mesures, problèmes rencontrés) est dans
docker/README.md.
Au tag tp-docker-v1, l'image front était le serveur Next.js de la v1. Depuis
ADR-002, elle construit et sert le front v2
(LUN-117).
Carte du dépôt
app/, components/, lib/ front v1 (Next.js), gelé
api/ API v2 (FastAPI) : code, migrations, tests
front/ front v2 (React + Vite) : écrans, Storybook, tests
docker/ conteneurisation : 5 images de la pile, 3 de CI et de mesure, composes
supabase/ migrations SQL de la v1
.github/ CI, conventions de PR, étiquettes, modèle de PR
docs/projet/ organisation du projet : Jira, import du backlog
docs/produit/ vision produit : personas, story map
docs/ documentation historique de la v1 (à vérifier)
M2/ preuves du diplôme : décisions (ADR), anomalies, cours
