# Doc de reprise — Application de gestion de crèche

*À coller/uploader en début de nouvelle discussion pour enchaîner sur le Lot 1.*

## Contexte

Projet : application de gestion de crèche (Côte d'Ivoire), basée sur le
cahier des charges **v4.1** (`Cahier-des-charges-creche_5_.docx`) et sa
grille de réponse prestataires associée.

Architecture validée (§2 du cahier des charges) :
- **Symfony 7.4 LTS**, PHP 8.3+, MySQL
- Contrôleur → Service → Repository ; toute la logique métier vit dans une
  couche Service indépendante du contrôleur (préparation à une future API
  JSON pour mobile, qui réutilisera les mêmes Services)
- Twig pour le web, pas d'API Platform
- Auth web par session (Symfony Security form login) ; JWT (Lexik) prévu
  plus tard pour l'API mobile
- Cadre légal : loi ivoirienne n° 2013-450 + ARTCI (pas RGPD/CNIL par défaut)

Ordre de réalisation (§3) :
| Lot | Contenu |
| --- | --- |
| **Lot 0 ✅ fait** | Socle technique : comptes & rôles, fiche enfant de base, responsables légaux, groupes, consentements |
| **Lot 1 → à faire** | Espace Équipe éducative (Module 2, §5) |
| Lot 2 | Espace Parents (Module 1, §4) |
| Lot 3 | Gestion administrative (Module 3) + Facturation (Module 4) |
| Lot 4 | Pilotage (Module 5) + Communication (Module 6) |

## Ce qui a été livré au Lot 0

Scaffold Symfony 7.4 (composer.json, config Doctrine/Security, Kernel,
bin/console) + 8 entités Doctrine (attributs PHP 8, ORM 3) :

- **Etablissement** — racine multi-site posée dès la conception (§2.1)
- **User** — comptes & rôles (Parent/Éducateur/Comptabilité/Direction/Admin
  technique), champs 2FA
- **Groupe** — sections/tranches d'âge, `ManyToMany` avec User pour
  l'affectation des éducateurs
- **Enfant** — fiche **de base uniquement** : identité, dates
  entrée/sortie, groupe. Pas d'infos médicales ni familiales.
- **ResponsableLegal** + **EnfantResponsableLegal** (pivot) — le pivot
  porte le statut d'autorité parentale, `estPersonnePayeuse`,
  `estContactUrgence` (propres à chaque lien enfant↔responsable, pas au
  responsable en général — utile pour fratries/familles recomposées)
- **ConsentementImage** — une ligne par (enfant, type d'usage), conforme à
  la décision §12 "détaillé par type d'usage"
- **JournalAudit** — journal d'accès non modifiable (append-only), livré
  dès le socle car tous les modules en dépendent (§2.3)

**Volontairement exclu du Lot 0** (à ajouter plus tard, pas maintenant) :
- Fiche enfant complète (allergies, PAI, situations familiales sensibles) → Lot 3, §6.2.b
- `PersonneAutorisee` → fonctionnalité Module 1/Lot 2, validation Module 3
- `AccesExceptionnel` (Super-admin de secours, §11) → entité séparée, pas un champ sur `User`
- Facturation, contrats, trésorerie, pilotage, communication

**État d'avancement réel** : le code des entités/config est livré (zip
`creche-app-lot0.zip`), mais `composer install` n'a pas pu être exécuté
dans l'environnement de génération (pas de PHP/Packagist). À faire côté
utilisateur : `composer install`, `.env.local`, première migration
(`make:migration` + `doctrine:migrations:migrate`).

## Contenu détaillé du Lot 1 à modéliser/développer (§5 du cahier des charges)

**Acteurs** : Éducateur/auxiliaire de puériculture, Remplaçant (accès temporaire borné)

**Fonctionnalités clés à couvrir** :
- Saisie du suivi quotidien (repas, sieste, soins, humeur, activités), saisie groupée
- Photos/vidéos avec blocage automatique si un enfant non consentant est visible (branchement sur `ConsentementImage` du Lot 0), recadrage/floutage
- Présences & départs : prévu vs réel, retard, départ anticipé, personne ayant récupéré l'enfant ; affichage des personnes autorisées (⚠️ `PersonneAutorisee` n'existe pas encore, à créer ici) ; signalement tentative non autorisée ; correction a posteriori avec justification obligatoire ; liste d'évacuation
- Transmissions/relève d'équipe (note interne non visible des parents)
- Messagerie avec les parents (par parent ou par groupe)
- Alertes prioritaires (allergies, PAI, consignes médicales, restrictions familiales/judiciaires) — nécessite d'introduire les entités médicales/familiales normalement prévues pour le Lot 3 ; à trancher : les faire maintenant en version minimale, ou stubber les alertes
- Administration de médicaments avec préconditions (ordonnance, autorisation parentale, période de validité, posologie), alerte sur incohérence dose/horaire, **double validation nominative et horodatée** pour traitements sensibles, aucune modification rétroactive sans trace
- Mode dégradé (panne réseau) : export/impression automatique des données critiques (pas de sync offline complète, choix assumé §5.2.i)
- Ergonomie de saisie dès la V1 (responsive tablette/mobile, boutons rapides, brouillons, distinction champs obligatoires/facultatifs)

**Entités probables à modéliser pour le Lot 1** (à confirmer en discussion) :
`JourneeType`/`SuiviQuotidien`, `Repas`, `Photo` (stockage objet, §2.5),
`Presence`, `PersonneAutorisee`, `Incident`, `AdministrationMedicament`,
`Message`, `TransmissionEquipe` (relève).

## Fichiers disponibles

- `Cahier-des-charges-creche_5_.docx` (v4.1, source de vérité fonctionnelle)
- `Grille-de-reponse-prestataires.docx` (grille consultation, non technique)
- `creche-app-lot0.zip` (scaffold Symfony 7.4 + entités Lot 0)

## Pour démarrer la nouvelle discussion

Réuploader le cahier des charges (et idéalement le zip du Lot 0 si vous
voulez que le code soit modifié directement plutôt que régénéré), coller
ce document, et dire "on attaque le Lot 1".