**Cahier des charges**

Application de gestion de crèche

*Version 4.1 — corrections finales avant envoi en consultation*

# 1. Contexte et objectifs

Développement d'une application de gestion de crèche, découpée en modules fonctionnels, avec une architecture applicative découplée :

- Une application Symfony classique (Twig) pour le web, où toute la logique métier vit dans une couche de **Services** indépendante du contrôleur

- Pas de dépendance à un framework API lourd (type API Platform)

- Le jour où l'appli mobile est nécessaire, on ajoute simplement des **contrôleurs API** (JSON) qui appellent les mêmes Services que le front web

Priorité de **valeur perçue** : l'espace parents reste ce qui est mis en avant dans la présentation du projet. L'ordre réel de construction suit une logique différente — voir §3.

# 2. Choix techniques

| **Aspect** | **Choix** | **Justification** |
| --- | --- | --- |
| Framework backend | Symfony 7.4 LTS | Support bugs jusqu'à nov. 2028, sécurité jusqu'à nov. 2029. Compatible à partir de PHP 8.2. |
| Langage | PHP 8.3+ | Compatible 7.4 LTS |
| Architecture | Contrôleur → Service → Repository | Stack simple, maîtrisée de bout en bout |
| Front web | Twig (+ Symfony UX / Stimulus si besoin) | Rendu côté serveur classique |
| Authentification web | Session (form login Symfony Security) | Standard pour une appli Twig monolithique |
| Authentification API (future) | JWT (LexikJWTAuthenticationBundle) | Ajouté au moment du besoin |
| Base de données | MySQL | — |
| Application mobile (V2) | Décorrélée du choix techno web | Consommera l'API JSON exposée le moment venu |
| Rôles applicatifs | Parent / Éducateur / Comptabilité / Direction / Admin | Base de la matrice de permissions (§11) |

## 2.1 Principe d'architecture en couches

Contrôleur Web (Twig)   ─┐

                          ├──►  Service (logique métier)  ──►  Repository (Doctrine / MySQL)

Contrôleur API (JSON)   ─┘

Un contrôleur ne contient jamais de logique métier. L'appli mobile n'ajoutera que des contrôleurs API légers réutilisant les Services déjà écrits pour le web.

**Modèle de données prêt pour le multi-site, même en mono-site aujourd****'****hui :** une entité **Etablissement** est créée dès la conception. Coût quasi nul aujourd'hui, évite une refonte lourde demain.

## 2.2 Cadre de protection des données — à confirmer selon le pays d'exploitation

*Correction importante par rapport aux versions précédentes : le document raisonnait par défaut comme pour une crèche française (RGPD, CNIL). Pour une crèche exploitée en Côte d**'**Ivoire, le cadre principal est différent.*

**Pour la Côte d****'****Ivoire :**

- Le texte de référence est la **loi n° 2013-450 du 19 juin 2013** relative à la protection des données à caractère personnel

- L'autorité de contrôle est l'**ARTCI** (Autorité de Régulation des Télécommunications/TIC de Côte d'Ivoire), Autorité de Protection

- Selon la nature des données traitées (données de santé des enfants notamment), certains traitements peuvent être soumis à une **déclaration ou une autorisation préalable auprès de l****'****ARTCI** — **point à vérifier spécifiquement avant le lancement**, idéalement avec un conseil local

- Les recommandations de la CNIL française peuvent servir de **référentiel complémentaire de bonnes pratiques** quand elles sont plus protectrices — mais elles ne sont pas le droit applicable

**Conséquences sur le reste du document :**

- Toute notification de violation de données est reformulée : notification à l'autorité compétente dans les conditions et délais prévus par le droit applicable (pas de délai français "72h CNIL" imposé par défaut)

- Les durées de conservation (§2.4) restent des propositions prudentes inspirées de bonnes pratiques, pas une obligation légale ivoirienne chiffrée

## 2.3 Sécurité

- HTTPS systématique, chiffrement des sauvegardes, gestion séparée des clés

- Mots de passe hachés (jamais chiffrés de façon réversible)

- Double authentification (2FA) obligatoire pour **Direction, Comptabilité et Admin**, ainsi que pour tout compte disposant d'un accès à des données financières ou médicales sensibles (les éducateurs habilités à gérer des médicaments peuvent conserver une connexion simplifiée sur tablette, avec réauthentification uniquement au moment de valider une administration sensible)

- Déconnexion automatique après inactivité, limitation des tentatives de connexion

- Accès des éducateurs strictement limité à leur(s) groupe(s)

- Revue périodique des comptes actifs

- **Suppression immédiate d****'****un compte au départ d****'****un salarié**

- Sauvegardes testées régulièrement

- Procédure de gestion des violations de données, avec notification à l'autorité compétente dans les conditions et délais prévus par le droit applicable

- Hébergeur et lieu d'hébergement identifiés et documentés

- Liste des sous-traitants et de leurs garanties de sécurité

- Journal d'accès non modifiable : qui a consulté/créé/modifié/supprimé quoi, et quand

## 2.4 Durées de conservation (propositions, à valider avec un conseil local)

| **Donnée** | **Base active** | **Archivage intermédiaire** | **Suppression** | **Motif** |
| --- | --- | --- | --- | --- |
| Suivi quotidien | Durée d'accueil | 6 mois après départ | Suppression | Continuité + contestation |
| Photos / vidéos | Durée d'accueil | 3 à 6 mois après départ | Suppression | Accès familial |
| Dossier administratif | Durée d'accueil | 1 an après départ | Suppr./anonymisation | Réinscription, litige |
| Factures | Durée d'accueil | Durée légale locale | Suppression après ce délai | Obligation comptable |
| Messagerie | Durée d'accueil | 1 an après départ | Suppression | Cohérence dossier |
| Journaux de sécurité | En continu | À définir (ex. 1 an) | Suppr. automatique | Détection d'incidents |

*Ces durées s**'**inspirent de bonnes pratiques (dont certaines recommandations de la CNIL française, qui plafonne à 3 ans après le départ pour ce type de structure) mais restent des propositions à valider selon le droit applicable en Côte d**'**Ivoire.*

## 2.5 Stockage des photos et vidéos

Les médias seront probablement la partie la plus lourde et la plus coûteuse du système à héberger. À préciser avant le développement :

- Compression automatique à l'import, formats autorisés, taille maximale par fichier

- Génération automatique de miniatures

- **Stockage hors base de données** (stockage objet type compatible S3), la base ne garde que les références

- Accès via des **liens temporaires signés**, jamais d'URL publique permanente

- Suppression réelle des fichiers physiques lors d'une purge

- Décision à prendre : médias inclus dans les sauvegardes, ou considérés remplaçables ?

- Quota de stockage par établissement, traçabilité des téléchargements

- Contrôle antivirus/anti-malware des fichiers uploadés

# 3. Ordre de réalisation (lots)

L'espace parents ne produit quasiment aucune donnée : ce sont l'équipe éducative et la direction qui créent les enfants, groupes, présences, repas et photos.

| **Lot** | **Contenu** | **Remarque** |
| --- | --- | --- |
| Lot 0 | Socle technique minimal : comptes & rôles, fiche enfant de base, responsables légaux, groupes, consentements | Invisible pour l'utilisateur, mais tout en dépend |
| Lot 1 | Espace Équipe éducative (Module 2) | C'est l'équipe qui produit la donnée consultée ensuite |
| Lot 2 | Espace Parents (Module 1) | Consomme les données du Lot 1 — priorité de valeur perçue |
| Lot 3 | Gestion administrative (Module 3) + Facturation (Module 4) |  |
| Lot 4 | Pilotage (Module 5) + Communication (Module 6) |  |

***Découpage fonctionnel en modules***

| **#** | **Module** | **Lot** | **Utilisateurs principaux** |
| --- | --- | --- | --- |
| 1 | Espace Parents | 2 | Parents |
| 2 | Espace Équipe éducative | 1 | Éducateurs, auxiliaires |
| 3 | Gestion administrative & dossiers enfants | 0 / 3 | Direction, secrétariat |
| 4 | Facturation & gestion financière | 3 | Direction, comptabilité |
| 5 | Pilotage / Reporting | 4 | Direction |
| 6 | Communication générale | 4 | Tous |
| 7 | Exigences d'exploitation | Continu | Équipe technique |

# 4. Détail — Module 1 : Espace Parents

## 4.1 Acteurs

- **Responsable légal (parent)** : 1 ou 2 maximum par enfant

- **Personne(s) autorisée(s) à récupérer l****'****enfant**

- Un compte parent peut être rattaché à plusieurs enfants (fratrie)

## 4.2 Fonctionnalités

**a) Authentification ****&**** compte**

- Création de compte (invitation par la crèche), connexion sécurisée, mot de passe oublié

- Gestion multi-enfants sur un même compte

- Jusqu'à 2 responsables légaux distincts par enfant, sous réserve des restrictions de consultation éventuelles (§6.2.b)

**b) Suivi quotidien de l****'****enfant**

- Repas, sommeil/siestes, soins, humeur, activités — historique consultable

**c) Photos et vidéos du jour**

- Consultation selon le type de consentement enregistré (§6.2.b), téléchargement si autorisé

**d) Présence ****&**** planning**

- Consultation du planning prévu, déclaration d'absence, historique des présences

**e) Personnes autorisées à récupérer l****'****enfant**

- **Ajout permanent** : proposé par le parent, activé après validation de la crèche

- **Autorisation ponctuelle**, avec réauthentification du parent, nom/prénom/téléphone obligatoires, date et plage horaire, identification du créateur

- **Expiration automatique en fin de journée** — ne reste jamais active par oubli

- **Blocage automatique** si une restriction familiale/judiciaire est active sur la fiche enfant

- Toute modification déclenche une notification à l'autre responsable légal et est journalisée de façon non modifiable

- L'équipe vérifie systématiquement une pièce d'identité à la sortie

**f) Messagerie**

- Fil de discussion avec l'équipe de la crèche

**g) Notifications**

- Nouveau contenu, message reçu, personne autorisée activée, incident signalé

**h) Facturation et services optionnels**

- Consultation des factures (scolarité + cantine séparément), téléchargement PDF

- Souscription / résiliation du service cantine à tout moment

**i) Documents ****&**** informations enfant (lecture)**

- Fiche enfant en lecture seule, modification soumise à validation de la crèche

- Visibilité adaptée aux restrictions de consultation éventuelles

## 4.3 Écrans principaux

- Accueil / tableau de bord du jour

- Fil du jour

- Historique / calendrier

- Messagerie

- Planning, absences & autorisations de sortie

- Factures

- Profil enfant

- Paramètres du compte

# 5. Détail — Module 2 : Espace Équipe éducative

## 5.1 Acteurs

- **Éducateur / auxiliaire de puériculture**

- **Remplaçant** (accès temporaire, à durée bornée)

## 5.2 Fonctionnalités

**a) Authentification ****&**** organisation**

- Connexion sécurisée, vue par groupe/section

**b) Saisie du suivi quotidien**

- Repas / sieste / soins / humeur / activités, saisie groupée quand pertinent

**c) Photos et vidéos**

- Publication contrôlée selon le consentement détaillé : blocage automatique si un enfant non consentant est visible, ou recadrage/floutage

**d) Présences ****&**** départs**

- Présence prévue vs réelle, retard, départ anticipé, personne ayant remis/récupéré l'enfant

- Affichage des personnes autorisées au moment du départ (liste permanente + autorisations ponctuelles du jour, non expirées)

- Signalement d'une tentative de départ non autorisée

- Correction d'un pointage a posteriori avec justification obligatoire

- Liste d'évacuation consultable en temps réel

**e) Transmissions / relève d****'****équipe**

- Note interne non visible des parents

**f) Messagerie avec les parents**

- Répondre / envoyer à un parent ou à tout un groupe

**g) Alertes prioritaires**

- Allergies, PAI, consignes médicales, restrictions familiales/judiciaires — visibles dès l'ouverture de la fiche

**h) Sécurité ****&**** santé — avec préconditions, pas seulement un enregistrement a posteriori**

- Le logiciel aide à empêcher qu'un médicament soit donné à tort, pas seulement à l'enregistrer après coup

- Chaque traitement programmé s'appuie sur : ordonnance/protocole, autorisation parentale, période de validité, posologie attendue

- **Alerte automatique en cas de dose ou d****'****horaire incohérent**

- **Double validation par deux membres du personnel** pour les traitements sensibles : le premier prépare et administre, le second vérifie l'enfant/le médicament/la dose/l'heure/le protocole — les deux validations sont nominatives et horodatées séparément

- Motif obligatoire si une prise prévue n'a pas été administrée

- Registre des incidents/accidents, appel du responsable légal tracé, fiche d'urgence imprimable

- **Aucune donnée médicale modifiable rétroactivement sans laisser de trace**

**i) Mode dégradé (panne réseau) — fonctions précisées**

- Restent accessibles : liste des enfants présents, contacts d'urgence, allergies/PAI, personnes autorisées, restrictions de retrait, liste d'évacuation

- Pointage provisoire des arrivées/départs, à synchroniser dès le retour du réseau

- **Option recommandée** : export/impression automatique quotidien de ces données critiques plutôt qu'une synchronisation hors-ligne complète — plus simple à fiabiliser qu'une vraie résolution de conflits, et cohérent avec le choix de stack simple (§2.1)

**j) Exigences d****'****ergonomie de saisie (dès la V1)**

- Interface responsive tablette/mobile dès la V1

- Boutons rapides, valeurs favorites, saisie groupée, duplication, enregistrement automatique

- Brouillons, complément possible en fin de journée

- Distinction claire champs obligatoires / facultatifs

## 5.3 Écrans principaux

- Tableau de bord du groupe

- Fiche de saisie par enfant

- Présences & départs

- Registre incidents & santé

- Relève d'équipe

- Messagerie

- Galerie photos à publier

# 6. Détail — Module 3 : Gestion administrative & dossiers enfants

## 6.1 Acteurs

- **Direction**

- **Secrétariat / administratif**

## 6.2 Fonctionnalités

**a) Inscriptions ****&**** admissions**

- Pré-inscription, liste d'attente, dossier d'admission

**b) Fiche enfant complète**

- Identité, groupe/section, jusqu'à 2 responsables légaux avec statut d'autorité parentale explicite

- Informations médicales : allergies (niveau de gravité), PAI, traitements, contact médecin

- Situations familiales sensibles : autorité exclusive, interdiction de remise, restriction de consultation/retrait, décision judiciaire, validation obligatoire par la direction, alerte visible pour l'équipe

- Séparation personne payeuse / responsable légal / contact d'urgence

- Consentement image détaillé par type d'usage

- Documents administratifs (règlement signé, assurance, vaccins)

**c) Personnes autorisées à récupérer l****'****enfant**

- Validation obligatoire par la direction avant activation d'un ajout permanent

- Journal d'audit complet et non modifiable

**d) Contrats d****'****accueil**

- Jours/horaires, période, tarif convenu, historique des avenants

**e) Places, capacité ****&**** personnel**

- Capacité par groupe/tranche d'âge, création des groupes, affectation du personnel

- Départ d'un salarié : révocation immédiate des accès

- Remplacement temporaire : accès à durée bornée

**f) Gestion RH ****&**** données**

- Archivage d'un enfant en fin de présence, fusion de doublons

- Import initial Excel, export complet

- Journal des actions, modèles de documents, suivi des notifications échouées

## 6.3 Écrans principaux

- Liste des dossiers enfants

- Fiche enfant (édition complète)

- Gestion des inscriptions

- Gestion des contrats

- Vue capacité / occupation

- Gestion des groupes & du personnel

- Journal des actions

# 7. Détail — Module 4 : Facturation & gestion financière

*Ce module couvre la facturation et une gestion de trésorerie simplifiée ; il ne remplace pas un logiciel de comptabilité générale — il produit les exports nécessaires pour l**'**expert-comptable.*

## 7.1 Acteurs

- **Comptabilité** (saisie courante)

- **Direction** (validation des opérations sensibles)

## 7.2 Fonctionnalités

**a) Grille tarifaire (libre, propre à la crèche)**

- Tarifs horaires, journaliers ou forfait mensuel, tarifs additionnels, réduction fratrie éventuelle

**b) Génération des factures — deux modes, renommés pour éviter toute ambiguïté**

- **Forfait fixe** : montant fixe, quel que soit le nombre de jours

- **Facturation selon le planning contractuel** (anciennement "au réel") : calculée sur les jours/heures prévus au contrat, pas sur un pointage quotidien — renommé car "réel" laissait penser que les absences seraient déduites automatiquement, ce qui n'est pas le cas

- **La présence physique réelle n****'****a aucune incidence sur la facturation, quel que soit le mode** (confirmé)

- Génération PDF, mise à disposition dans l'espace parent

**c) Retrait de l****'****enfant en cours de contrat**

- Le système calcule automatiquement une **proposition** de solde

- **La validation et l****'****exécution du remboursement restent une action manuelle**

- Frais de préavis non remboursables possibles si prévus au contrat

**d) Suivi des paiements**

- État des factures, relances, historique par enfant/famille

**e) Acomptes ****&**** dépôt de garantie**

- Gestion d'un éventuel acompte à l'inscription

**f) Avances et apports du fondateur**

- Catégories neutres : avance remboursable, apport non remboursable, subvention, don, dépense payée personnellement à rembourser

- Pièce justificative obligatoire, statut décidé à la saisie

- Le logiciel enregistre la catégorie, il ne qualifie jamais juridiquement le mouvement

**g) Cantine (service optionnel)**

- Consommation enregistrée via un événement dédié dans l'écran de saisie quotidienne de l'équipe (Module 2)

- Gestion des repas apportés par les parents et des repas annulés/offerts

**h) Suivi de trésorerie (entrants / sortants)**

- Entrants et sortants catégorisés, solde visible à tout instant

**i) Comptabilité générale**

- Export CSV/Excel, attestations si nécessaire

**j) Séparation des rôles ****&**** validations financières**

| **Action** | **Saisie** | **Validation** |
| --- | --- | --- |
| Créer une dépense | Comptabilité / Direction | Une autre personne que le saisissant |
| Enregistrer une avance du fondateur | Comptabilité | Direction (ou le fondateur si distinct) |
| Effectuer un remboursement | Comptabilité | Direction |
| Annuler une facture | Comptabilité | Direction (avoir / contre-écriture) |
| Modifier un paiement clôturé | Interdit — écriture corrective uniquement | Validation obligatoire |

**Précision sur la validation à effectif réduit :** une auto-validation n'est pas une double validation — c'est une validation simple. Si la structure ne dispose provisoirement que d'une seule personne habilitée, l'opération peut être exécutée avec une auto-validation horodatée, mais elle doit apparaître dans un **rapport distinct soumis à un contrôle périodique par une seconde personne désignée** (ex. une seconde directrice pour la saisie, vérification périodique par le directeur).

Contrôles complémentaires : clôture périodique, numérotation continue des factures, justificatifs attachés à chaque dépense, historique complet des modifications, rapprochement banque/caisse, gestion des moyens de paiement.

## 7.3 Écrans principaux

- Grille tarifaire (paramétrage)

- Génération / liste des factures

- Suivi des paiements et relances

- Gestion des retraits / résiliations (propositions à valider)

- Avances & apports du fondateur

- Cantine (souscriptions, facturation)

- Trésorerie (entrants / sortants, solde)

- File d'attente de validation

- Export comptable

# 8. Détail — Module 5 : Pilotage / Reporting

## 8.1 Acteurs

- **Direction**

## 8.2 Fonctionnalités

**Fonctionnalités**

- Tableau de bord : taux d'occupation, effectif par groupe

- Statistiques : inscriptions, chiffre d'affaires, impayés

- Reporting RH basique

## 8.3 Écrans principaux

- Dashboard direction

- Rapports & exports statistiques

*Conçu pour un seul établissement aujourd**'**hui. Grâce à l**'**entité Etablissement posée dès le modèle de données, un passage au multi-site restera un refactor ciblé.*

# 9. Détail — Module 6 : Communication générale

## 9.1 Acteurs

- **Direction / équipe** → tous les parents

## 9.2 Fonctionnalités

**Fonctionnalités**

- Annonces générales, calendrier des événements, sondages simples

## 9.3 Écrans principaux

- Liste des annonces

- Calendrier des événements

# 10. Module 7 : Exigences d'exploitation (transverse, avec objectifs mesurables)

Pour qu'un prestataire puisse être évalué et comparé sur des bases communes, ces exigences doivent être chiffrées, pas seulement déclarées en intention.

| **Exigence** | **Objectif proposé (à valider)** |
| --- | --- |
| Disponibilité visée | À définir — ex. disponibilité en heures d'ouverture |
| Fréquence des sauvegardes | Quotidienne minimum |
| Perte de données max. acceptable (RPO) | ≤ 24h |
| Délai maximal de restauration (RTO) | À définir — ex. quelques heures |
| Durée de conservation des sauvegardes | À définir — ex. 30 jours glissants |
| Temps de réponse des écrans principaux | À définir — ex. quelques secondes |
| Navigateurs / appareils pris en charge | Dernières versions des navigateurs principaux, desktop + mobile |
| Volumétrie prévue | Enfants, utilisateurs, photos/mois, messages/mois — à chiffrer ensemble |
| Taille maximale des fichiers uploadés | À définir (voir §2.5) |
| Durée de conservation des journaux techniques | À définir (ex. 1 an) |
| Réversibilité en fin de contrat | Export complet dans un format exploitable (CSV/JSON), délai à définir |

Autres exigences (non chiffrées mais nécessaires) :

- Environnements distincts : développement / recette / production

- Procédure de restauration documentée et testée

- Supervision applicative (alertes en cas de panne)

- Politique de mise à jour des dépendances et correctifs de sécurité

- Support utilisateur : canal de contact, délai de réponse visé

- Formation initiale de l'équipe et de la direction

- Documentation utilisateur, au moins un guide par rôle

- Checklist de critères de recette avant chaque mise en production

# 11. Matrice des rôles

| **Fonctionnalité** | **Parent** | **Éducateur** | **Comptabilité** | **Direction** | **Admin technique** |
| --- | --- | --- | --- | --- | --- |
| Consulter suivi enfant | ✅ (ses enfants) | ✅ (son groupe) | ❌ | ✅ (tous) | ❌* |
| Saisir suivi enfant | ❌ | ✅ | ❌ | ✅ | ❌ |
| Proposer une personne autorisée permanente | ✅ (ses enfants) | ❌ | ❌ | — | — |
| Valider une personne autorisée permanente | ❌ | ❌ | ❌ | ✅ | ❌ |
| Déclarer une autorisation ponctuelle | ✅ (réauthentification) | ❌ (consult.) | ❌ | ✅ | ❌ |
| Vérifier identité au départ | ❌ | ✅ | ❌ | ✅ | ❌ |
| Administrer un traitement (préconditions) | ❌ | ✅ (si habilité) | ❌ | ✅ (si habilité) | ❌ |
| Messagerie avec les parents | ✅ | ✅ | ❌ | ✅ | ❌ |
| Consulter facture | ✅ (ses enfants) | ❌ | ✅ | ✅ | ❌* |
| Définir la grille tarifaire | ❌ | ❌ | ❌ | ✅ | ❌ |
| Saisir une facture / dépense | ❌ | ❌ | ✅ | ✅ | ❌ |
| Valider un remboursement / une annulation | ❌ | ❌ | ❌ | ✅ | ❌ |
| Saisir une avance / un apport du fondateur | ❌ | ❌ | ✅ | ✅ | ❌ |
| Valider la qualification d'une avance/apport | ❌ | ❌ | ❌ | ✅ | ❌ |
| Souscrire / gérer la cantine de son enfant | ✅ (ses enfants) | ❌ | ❌ | ✅ | ❌ |
| Consulter la trésorerie | ❌ | ❌ | ✅ | ✅ | ❌* |
| Gérer dossiers/inscriptions | ❌ | ❌ | ❌ | ✅ | ❌ |
| Valider une situation familiale sensible | ❌ | ❌ | ❌ | ✅ | ❌ |
| Comptes, rôles, configuration, supervision technique | ❌ | ❌ | ❌ | ❌ | ✅ |
| Créer une nouvelle caisse (§14) | ❌ | ❌ | ❌ | ✅ | ❌ |
| Saisir un mouvement (dépense/entrant) dans une caisse existante (§14) | ❌ | ❌ | ✅ | ✅ | ❌ |
| Enregistrer un accueil ponctuel / garderie (§15) | ❌ | ❌ | ❌ | ✅ | ❌ |
| Gérer le catalogue produits vendus & stock (§18) | ❌ | ❌ | ❌ | ✅ | ❌ |
| Gérer les contrats de travail (§19.2.a) | ❌ | ❌ | ❌ | ✅ | ❌ |
| Confirmer un virement de salaire (§19.2.d) | ❌ | ❌ | ✅ (1) | ✅ | ❌ |

** Accès de support exceptionnel possible (**"**Super-admin de secours**"**) : temporaire, limité dans le temps, justifié par un motif enregistré, et systématiquement journalisé — jamais un accès permanent par défaut.*

*(1) Décision client 2026-08-10 : accès individuel (montant par salarié), pas seulement une masse salariale agrégée — la Comptabilité confirme elle-même chaque virement. Ne donne pas accès au contrat de travail (poste, type, clauses), réservé Direction. Cf. §19.2.e.*

**Principe du moindre privilège — trois niveaux distincts, pas deux :**

- **Admin technique** : comptes, rôles, configuration, supervision. Pas d'accès normal au contenu métier (dossiers médicaux, judiciaires, financiers)

- **Super-admin de secours** : accès exceptionnel au contenu métier, activé ponctuellement, avec justification et traçabilité renforcée

- **Direction** : accès métier complet, en usage courant

Distinction complémentaire : le rôle applicatif (Éducateur, Direction) donne accès à l'écran de saisie, mais l'habilitation réelle à administrer un traitement ou à vérifier une identité au départ reste une compétence métier à part, cochée individuellement par compte.

# Propriété du code & réversibilité technique

*Ces points relèvent souvent d**'**une annexe contractuelle plutôt que du cahier des charges fonctionnel, mais méritent d**'**être actés avant la consultation de prestataires :*

- **Propriété du code source** : le code développé spécifiquement pour la crèche est **cédé à la crèche**, avec remise du code source et des droits patrimoniaux nécessaires à son exploitation, sa modification et sa reprise par un tiers. Les composants génériques ou tiers (bibliothèques open-source) restent soumis à leurs licences respectives et doivent être identifiés dans l'offre du prestataire

- **Dépôt de code (Git)** : hébergement identifié, accès transférable à la crèche ou à un tiers de son choix en fin de contrat

- **Accès administrateur** (serveur, base de données, hébergement) : détenus ou transférables à la crèche, pas seulement conservés par le prestataire

- **Documentation technique** : remise à la crèche (architecture, schéma de données, procédures de déploiement)

- **Réversibilité** : un autre prestataire doit pouvoir reprendre le projet sans dépendance cachée au premier développeur

- **Bibliothèques tierces** utilisées et leurs licences : listées et tenues à jour

# 12. Décisions validées

| **Sujet** | **Décision** |
| --- | --- |
| Cadre légal applicable | Loi ivoirienne n° 2013-450 et ARTCI en cadre principal ; CNIL utilisée comme référentiel de bonnes pratiques complémentaire |
| Déclaration/autorisation ARTCI | À vérifier avant lancement, vu le traitement de données de santé de mineurs |
| Responsables légaux | 1 ou 2 maximum par enfant |
| Personnes autorisées — ajout permanent | Proposé par le parent, activé après validation de la crèche |
| Personnes autorisées — autorisation ponctuelle | Réauthentification, champs obligatoires, expiration en fin de journée, blocage si restriction active |
| Mode de facturation | Forfait fixe ou facturation selon planning contractuel (renommé) ; présence physique sans incidence |
| Retrait anticipé de l'enfant | Proposition de calcul automatique ; validation et exécution manuelles |
| Avances / apports du fondateur | Catégories neutres, qualification finale validée par la direction/l'expert-comptable |
| Séparation des rôles financiers | Comptabilité = saisie, Direction = validation ; à effectif réduit, auto-validation + contrôle périodique par une seconde personne |
| Administration de médicaments | Précondition obligatoire, alerte sur incohérence, double validation pour traitements sensibles |
| Mode dégradé (panne réseau) | Export/impression automatique des données critiques plutôt qu'une synchronisation hors-ligne complète |
| Consentement image | Détaillé par type d'usage |
| Situations familiales sensibles | Champs dédiés, validation direction obligatoire |
| Stockage photos/vidéos | Hors base de données, liens temporaires signés |
| Multi-site | Un seul établissement aujourd'hui, entité Etablissement posée dès le modèle de données |
| Cantine | Événement de consommation dédié, intégré à l'écran de saisie de l'équipe |
| Ordre de réalisation | Lots 0 à 4 (§3) |

## Compléments 2026-08-10 (retour client, cf. `documentation/retour_clients` et `documentation/suivi-caisses-rh.md`)

| **Sujet** | **Décision** |
| --- | --- |
| Caisses internes (§14) | Concept générique et extensible — Direction peut créer de nouvelles caisses librement, pas de liste figée dans le code |
| Accès aux caisses | Usage interne, ni parent ni autre profil. Direction : création + consultation ; Comptabilité : peut saisir des mouvements dans une caisse existante mais ne peut pas en créer une nouvelle |
| Facturation | Facture libre, sans contrat de scolarité obligatoire, pour les achats ponctuels rattachés à une caisse ou à un accueil ponctuel |
| Accueil ponctuel / garderie (§15) | Réutilise l'entité Enfant (statut dédié) plutôt qu'un circuit parallèle — pas de compte parent créé, contact ponctuel + restitution du suivi à la récupération : email si une adresse a été renseignée, sinon impression sur place |
| Scolarité en tranches (§16.1.b) | Échéancier de paiement à ajouter, distinct du forfait mensuel existant |
| Dépenses fixes (§16.1.c) | Liste permanente + pointage manuel payé/non payé, combinée aux caisses pour un indicateur de marge de dépense réelle |
| Cantine saisonnière (§17) | Catalogue informatif uniquement, aucune contrainte automatique sur les prix saisis |
| Produits vendus (§18) | Suivi de stock (quantités) demandé, pas seulement l'enregistrement de la vente |
| RH du personnel (§19) | Chantier séparé des caisses/comptabilité interne — périmètre détaillé validé le 2026-08-10 (§19.2) |

# 13. Prochaines étapes proposées

- Vérifier les obligations de déclaration/autorisation ARTCI avant tout traitement réel de données

- Modélisation des entités de données : Etablissement, Enfant, ResponsableLegal, PersonneAutorisee, SituationFamiliale, ConsentementImage, Groupe, JourneeType, Repas, EvenementCantine, Incident, AdministrationMedicament, Message, Photo, Contrat, Facture, GrilleTarifaire, AvanceFondateur, MouvementTresorerie, JournalAudit

- Wireframes du parcours Équipe et du parcours Parents en parallèle

- Poser le socle technique (init projet Symfony 7.4, structure Contrôleur/Service/Repository, rôles/auth) — avant le prototype, pour éviter un prototype jetable suivi d'une reprise complète

- Développement du prototype de la saisie Équipe (Lot 1)

- Test de l'ergonomie terrain (avec une éducatrice réelle si possible)

- Construction de l'espace Parents à partir des données validées par le Lot 1

---

*Les modules ci-dessous (§14 à §19) sont des compléments ajoutés le
2026-08-10, à la suite d'un retour client (`documentation/retour_clients`)
recueilli après la mise en production des Lots 0 à 6. Statut détaillé et
questions encore ouvertes tenus à jour dans
`documentation/suivi-caisses-rh.md` — ce cahier des charges reste la
référence fonctionnelle une fois chaque point validé.*

# 14. Détail — Module 8 : Caisses internes (fonds de gestion)

*Besoin exprimé par la direction : plusieurs "caisses" de suivi interne
(fournitures scolaires, uniformes/tenue de sport, macarons, produits
vendus...), certaines pour des achats ponctuels (rentrée scolaire), la
cantine restant gérée par son circuit existant (§7.2.g).*

## 14.1 Acteurs

- **Direction** : création des caisses (exclusif — cf. §11), consultation
  d'ensemble.

- **Comptabilité** : peut saisir des mouvements (dépenses, entrants)
  dans une caisse déjà créée, comme pour une dépense classique (§7.2.j)
  — mais ne peut pas créer de nouvelle caisse (décision client
  2026-08-10, confirmée). Ni Parent ni aucun autre profil n'a accès aux
  caisses.

## 14.2 Fonctionnalités

**a) Caisse — concept générique et extensible**

- Une caisse est un fonds de suivi interne à nom libre. La Direction
  peut créer de nouvelles caisses librement — aucune liste figée dans
  le code (contrairement, par exemple, aux catégories de dépense qui
  existent déjà mais restent purement côté dépenses).

- Chaque caisse a un mode : **ponctuel** (achat en une fois, ex. pack
  fournitures de rentrée), **récurrent**, ou **saisonnier** (fenêtre de
  dates connue — cf. §17 pour la déclinaison cantine).

- Une caisse agrège recettes (ce que les familles paient) et dépenses
  (ce que la crèche débourse), avec un solde calculé — mêmes principes
  que la trésorerie existante (§7.2.h), mais vue par caisse plutôt que
  globale.

**b) Facturation libre, rattachée à une caisse**

- Les achats ponctuels ne sont pas liés à un enfant/contrat de
  scolarité : la facture doit pouvoir être émise librement, rattachée à
  une caisse plutôt qu'à un `Contrat`. Rappel de la direction : la
  facture sert avant tout de preuve d'achat pour la famille et de trace
  de sortie/entrée d'argent pour la crèche — elle n'a pas besoin d'un
  contrat de scolarité pour exister (cf. §16.1.a).

**c) Consultation**

- Chaque caisse a son propre écran : mouvements, solde courant,
  historique — consultable par Direction et Comptabilité (celle-ci y
  saisit des mouvements, cf. §14.1), mais création d'une caisse
  réservée à Direction.

## 14.3 Écrans principaux

- Liste des caisses, avec solde de chacune

- Création d'une nouvelle caisse (nom, mode)

- Détail d'une caisse : mouvements, solde, nouvelle facture libre /
  nouvelle dépense rattachée

# 15. Détail — Module 9 : Accueil ponctuel non-inscrit (« garderie »)

*Besoin exprimé : la crèche garde parfois des enfants non-inscrits pour
1 jour ou plus, avec paiement à la journée (garde et/ou cantine).*

## 15.1 Décision validée

Réutiliser l'entité `Enfant` existante plutôt qu'un circuit parallèle,
avec un statut distinguant "inscription régulière" de "accueil
ponctuel" — permet de réutiliser tel quel le suivi quotidien (repas,
sieste, activités, santé, Module 2) déjà construit pour les enfants
inscrits, ce qui répond directement à l'exigence : *"le parent doit
avoir un suivi détaillé en fin de récupération, et nous devons garder
la trace."*

## 15.2 Restitution du suivi sans compte parent

Pas de compte `ROLE_PARENT` créé pour un accueil ponctuel — pas de
besoin d'accès permanent à un espace en ligne pour une visite d'un ou
deux jours.

- Un **contact ponctuel** (nom, téléphone, éventuellement email) est
  enregistré à l'inscription du jour, sans compte applicatif — sert à
  l'identification/autorisation de récupération (même logique que les
  "personnes autorisées" existantes, §6.2.c).

- **Décision validée (2026-08-10)** : le suivi détaillé de fin de
  journée est **envoyé par email si le contact a renseigné une
  adresse**, sinon **imprimé sur place** au moment de la récupération.
  Pas de canal SMS (aucune passerelle SMS dans l'application
  aujourd'hui — l'envoi d'email réutilise le mailer déjà en place pour
  les emails d'activation de compte, cf. §7.2.f).

- Dans tous les cas, la crèche garde la trace en base : le suivi
  quotidien de l'enfant reste enregistré normalement, consultable
  ensuite comme pour un enfant inscrit.

## 15.3 Fonctionnalités

**a) Enregistrement rapide d'un accueil ponctuel** — identité enfant
(nom, prénom, âge/date de naissance, allergies/informations de
sécurité), contact du jour, période (1 jour ou plus), tarif (journalier,
cantine à la journée).

**b) Suivi quotidien identique à un enfant inscrit** — pas de nouveau
formulaire, réutilisation du Module 2.

**c) Facturation à la journée**, rattachée à la caisse garderie (§14)
plutôt qu'à un contrat de scolarité classique (cf. §16.1.a, facture
libre).

**d) Restitution du suivi à la récupération** (cf. §15.2).

## 15.4 Écrans principaux

- Enregistrement d'un accueil ponctuel (formulaire allégé, sans le
  parcours complet de pré-inscription)

- Suivi quotidien (réutilisé du Module 2)

- Récapitulatif de fin de journée : envoi par email (si adresse
  renseignée) ou impression sur place (§15.2)

# 16. Compléments — Module 4 : Facturation & gestion financière

## 16.1 Fonctionnalités complémentaires

**a) Facture sans contrat obligatoire**

- La contrainte actuelle (une facture référence toujours un contrat de
  scolarité) est levée pour les achats ponctuels rattachés à une caisse
  (§14) ou à un accueil ponctuel (§15). Le contrat de scolarité
  classique reste inchangé pour la facturation régulière.

**b) Échéancier / paiement en plusieurs tranches**

- Cas cité : scolarité maternelle (550 000 F/an) payée en 4 tranches à
  des dates convenues, à la différence du forfait mensuel de la crèche
  (100 000 F/mois, déjà couvert par le mode "forfait fixe" existant,
  §7.2.b).

- Besoin : un plan de paiement avec plusieurs échéances datées pour un
  même contrat, distinct d'une simple facturation mensuelle répétée —
  suivi de ce qui est dû/payé par échéance.

**c) Dépenses fixes & marge de dépense réelle**

- Une liste permanente des dépenses fixes connues (loyer, salaires...),
  avec un traitement **manuel** indiquant, pour chaque échéance, si
  elle a été payée ou non — pas de génération automatique de dépense,
  un suivi/pointage.

- Objectif : combiner ce suivi avec les soldes des caisses (§14) et la
  trésorerie existante (§7.2.h) pour afficher un indicateur "argent
  réellement disponible" = solde de trésorerie actuel, diminué des
  dépenses fixes dues et pas encore payées sur la période en cours.
  Vient compléter l'écran Trésorerie existant plutôt que d'en créer un
  isolé.

## 16.2 Écrans principaux (compléments)

- Facture libre (hors contrat), rattachée à une caisse ou à un accueil
  ponctuel

- Échéancier d'un contrat (création, suivi des tranches)

- Dépenses fixes (liste, pointage payé/non payé)

- Trésorerie : indicateur "marge réelle disponible" (complément à
  l'écran existant)

# 17. Détail — Module 10 : Cantine — catalogue saisonnier

*Besoin exprimé : aider la personne en charge des achats cantine à
savoir quels produits sont de saison (prix plus abordable,
disponibilité), et orienter la cuisine en conséquence.*

## 17.1 Décision validée

Usage **informatif uniquement** — pas de contrainte ni de validation
automatique des prix saisis lors d'un achat cantine (écran existant,
§7.2.g), juste un catalogue consultable.

## 17.2 Fonctionnalités

**a) Catalogue de produits de saison** — nom du produit, période
indicative (date de début/fin, ex. "mangue : mars-juin"), prix probable
indicatif.

**b) Consultable depuis l'écran de saisie des achats cantine**, à titre
de suggestion pour la personne qui fait les courses.

*Note de conception : même patron que le catalogue "Thèmes d'activités"
déjà en place (période de validité facultative sur une entrée de
catalogue) — réutilisable directement.*

## 17.3 Écrans principaux

- Gestion du catalogue de produits de saison (Direction)

- Rappel des produits de saison en cours sur l'écran de saisie Cantine

# 18. Détail — Module 11 : Produits vendus & stock

*Besoin exprimé : la crèche revend certains articles aux familles
(uniformes, tenues de sport...), en plus de la possibilité pour le
parent d'acheter la liste par lui-même (§14).*

## 18.1 Décision validée

Suivi de **stock** demandé (quantités disponibles), pas seulement un
enregistrement de vente.

## 18.2 Fonctionnalités

**a) Catalogue de produits vendus** — nom, prix, quantité en stock.

**b) Vente à une famille** — décrémente le stock, génère une facture
libre (§16.1.a) rattachée à la caisse "Produits vendus".

**c) Réapprovisionnement** — entrée de stock, rattachée en dépense à la
même caisse.

**d) Alerte simple** si le stock passe sous un seuil (seuil à définir).

## 18.3 Écrans principaux

- Catalogue produits (gestion, stock)

- Vente (sélection produit + quantité, génère la facture)

- Réapprovisionnement

# 19. Détail — Module 12 : Gestion RH du personnel

*À ne pas confondre avec le §6.2.f ("Gestion RH & données"), qui
concerne en réalité les dossiers enfants (archivage, doublons, export)
— nommé "RH" dans le cahier des charges d'origine mais sans lien avec
le personnel salarié.*

*Besoin exprimé : gestion des congés, jours posés de façon
exceptionnelle, salaires, contrats de travail du personnel — absent du
périmètre initial (Lots 0-6), qui ne couvrait que l'affectation aux
groupes et la gestion des accès (§6.2.e).*

## 19.1 Décision validée

À construire, mais traité comme un chantier **séparé** des Modules 8-11
ci-dessus (caisses/comptabilité interne) — périmètre plus large,
données sensibles (salaires). Règles d'accès précisées en §19.2.e.

## 19.2 Décisions validées (2026-08-10, suite)

**a) Contrats de travail**

- Accès en lecture/écriture : **Direction exclusivement**. Décision
  client : "ça ne concerne pas la compta, à la limite une équipe
  juridique" — distinct du suivi des salaires (§19.2.d), qui lui
  concerne Comptabilité.

- Champs proposés (à ajuster) : type de contrat (CDI / CDD / période
  d'essai), poste, date de début, date de fin (si CDD), salaire de
  base, régime horaire, numéro CNPS.

**b) Congés**

- Décision : suivi **déclaratif simple** au démarrage (pas de calcul
  automatique de solde).

- Vérification droit ivoirien (Code du travail 2015, art. 25.1-25.10) :
  un salarié acquiert 2,2 jours ouvrables de congé par mois de service
  effectif, soit **24 jours ouvrables/an**, +1 jour par tranche de 5
  ans d'ancienneté (jusqu'à 30 jours à 30 ans), et des jours
  supplémentaires pour les salariées ayant des enfants à charge sous
  conditions d'âge. Un calcul automatique du solde est donc réalisable
  à partir de la date d'embauche (déjà nécessaire pour le contrat,
  §19.2.a) ; la règle "enfants à charge" demande une donnée
  supplémentaire par salarié, à évaluer séparément si le besoin se
  confirme.

- Proposition : démarrer en déclaratif simple (conforme à la décision),
  mais conserver la date d'embauche en base dès le départ, pour ne pas
  avoir à la reprendre le jour où un calcul automatique (avec
  ajustement manuel toujours possible) serait ajouté.

- *Sources : wageindicator.org, africapaierh.com — comme pour l'ARTCI
  (§2.2), à confirmer avec un conseil juridique local avant tout calcul
  automatique appliqué en production.*

- **Exigence fonctionnelle (décision client 2026-08-10)** : l'écran de
  saisie d'un congé affiche un rappel visible citant les seuils du Code
  du travail (2,2 jours ouvrables/mois, paliers d'ancienneté à 5 ans,
  jours supplémentaires enfants à charge) et invite explicitement la
  personne qui saisit à faire vérifier ces seuils par une juriste avant
  de s'y fier — la donnée saisie reste déclarative (§19.2.b), ce rappel
  ne bloque jamais la saisie, il alerte seulement.

**c) Jours posés exceptionnels**

- Décision : reste un type de "congé", mais **sans solde associé**
  (accordé au cas par cas, ne décompte rien).

**d) Salaires**

- Décision : simple montant à enregistrer par salarié/période, avec
  confirmation manuelle du virement effectué (avec sa date) — le
  montant n'entre dans la trésorerie qu'une fois cette confirmation
  faite.

- *Note de conception : c'est le même mécanisme que les "dépenses
  fixes" déjà spécifiées (§16.1.c) — un salaire est, techniquement, une
  dépense fixe récurrente rattachée à un salarié plutôt qu'à un
  intitulé libre ("Loyer"). Proposition : réutiliser le même
  écran/mécanisme de pointage payé/non payé plutôt que d'en construire
  un second en parallèle — un salaire apparaît dans la même liste de
  dépenses fixes, catégorisé "Salaire — [nom]".*

**e) Accès**

- Décision (affinée) : la Comptabilité gère la confirmation des
  virements de salaire, donc a besoin d'un accès **individuel**
  (montant par salarié), pas seulement une masse salariale agrégée.

- Distinction retenue : **Contrat de travail** (poste, type, dates,
  clauses) = Direction exclusivement (§19.2.a) ; **Salaire** (montant,
  confirmation de virement) = Comptabilité + Direction, au même titre
  qu'une dépense fixe classique. Un compte cumulant Direction +
  Comptabilité voit les deux ; un compte Comptabilité seul voit
  uniquement les montants/salaires, pas le détail contractuel.

## 19.3 Fonctionnalités

**a)** Fiche contrat de travail par membre du personnel (Direction)

**b)** Déclaration de congés et de jours posés exceptionnels (sans
solde pour ces derniers, §19.2.c) — rappel des seuils légaux affiché à
la saisie, invitant à vérification par une juriste (§19.2.b)

**c)** Salaires : liste par salarié, pointage payé/non payé avec date
de virement — même mécanisme que les dépenses fixes (§16.1.c/§16.2),
accessible Comptabilité + Direction

## 19.4 Écrans principaux

- Fiche contrat de travail par membre du personnel (Direction
  exclusivement)

- Congés et absences exceptionnelles (déclaration, calendrier d'équipe)

- Salaires (liste, pointage payé/non payé — Comptabilité + Direction),
  intégré à l'écran "Dépenses fixes" (§16.2)