petitspas/docs/24_DECISIONS-PROJET.md

📋 Décisions Projet - P'titsPas

Version : 1.1
Date : 9 Février 2026
Auteur : Équipe PtitsPas

---

🎯 Objectif de ce document

Ce document trace toutes les décisions importantes prises lors de la conception du projet P'titsPas. Il sert de référence pour comprendre les choix techniques et fonctionnels.

---

📊 Décisions Architecture

1. Mono-repo vs Multi-repo

Décision : ✅ Mono-repo

Justification :

• Code cohérent dans un seul dépôt Git
• Commits atomiques (frontend + backend + BDD en même temps)
• CI/CD simplifié (un seul webhook)
• Facilite le travail collaboratif

Structure :

ptitspas-app/
├── frontend/          # Application Flutter
├── backend/           # API NestJS
├── database/          # Migrations SQL/Prisma
├── api-contracts/     # Contrats OpenAPI + Prisma
├── docs/              # Documentation
└── docker-compose.yml # Orchestration

---

2. Déploiement On-Premise

Décision : ✅ Application on-premise avec configuration dynamique

Justification :

• Chaque collectivité a son infrastructure (SMTP, domaines, ports)
• Autonomie totale (pas de dépendance à notre infra)
• Conformité aux politiques IT locales
• Sécurité (données restent dans le SI de la collectivité)

Solution technique :

• Table configuration en BDD (clé/valeur)
• Panneau Paramètres (3 sections) dans le dashboard à la première connexion ; navigation bloquée jusqu'à sauvegarde
• Configuration SMTP dynamique
• Personnalisation (nom app, logo, URL)

Référence : 21_CONFIGURATION-SYSTEME.md

---

3. Gestion des fichiers uploadés

Décision : ✅ Système de fichiers local avec volume Docker

Justification :

• Simplicité (pas de S3/MinIO pour on-premise)
• Performance (accès direct au disque)
• Coût (pas de service externe)

Solution technique :

• Stockage dans /uploads/photos/
• Volume Docker persistant
• Service Upload avec Multer
• Validation taille (depuis config)

Alternatives rejetées :

• ❌ Base de données (BYTEA) : Mauvaise performance
• ❌ S3/MinIO : Overkill pour on-premise

---

4. Documents légaux (CGU/Privacy)

Décision : ✅ Versioning automatique avec traçabilité RGPD

Justification :

• Conformité juridique (preuve d'acceptation)
• Flexibilité (chaque collectivité adapte ses CGU)
• Traçabilité (hash SHA-256, IP, User-Agent)
• Sécurité juridique (pas de retour en arrière)

Solution technique :

• Table documents_legaux (versioning auto-incrémenté)
• Table acceptations_documents (traçabilité RGPD)
• Upload PDF par l'admin
• Activation manuelle après prévisualisation
• Documents génériques v1 fournis par défaut

Référence : 22_DOCUMENTS-LEGAUX.md

---

🔧 Décisions Fonctionnelles

5. Workflow inscription sans mot de passe

Décision : ✅ Pas de mot de passe lors de l'inscription, lien email après validation

Justification :

• Simplifie l'inscription (moins de friction)
• Adapté aux parents séparés/divorcés (communication difficile)
• Sécurité (token UUID avec expiration)
• Validation gestionnaire avant activation

Workflow :

1. Parent/AM s'inscrit (sans MDP)
2. Gestionnaire valide
3. Email envoyé avec lien création MDP (valable 7 jours)
4. Utilisateur crée son MDP
5. Compte activé

Référence : 20_WORKFLOW-CREATION-COMPTE.md

---

6. Genre enfant obligatoire (H/F)

Décision : ✅ Genre obligatoire (H/F uniquement)

Justification :

• Contexte métier : Enfants à garder (pas de genre neutre)
• Conformité CDC
• Simplicité

Implémentation :

• Champ genre ENUM('H', 'F') NOT NULL dans table enfants

---

7. Suppression champs téléphone

Décision : ✅ Un seul champ "Téléphone" (mobile privilégié)

Justification :

• Simplification (plus besoin de "Mobile" et "Téléphone fixe")
• Réalité terrain : Tout le monde a un mobile
• Note dans l'interface : "(mobile privilégié)"

Implémentation :

• Supprimer mobile et telephone_fixe
• Garder uniquement telephone

---

8. NIR obligatoire pour Assistantes Maternelles

Décision : ✅ NIR (Numéro de Sécurité sociale) obligatoire

Justification :

• Conformité CDC
• Nécessaire pour génération automatique du contrat
• Stockage sécurisé (chiffrement recommandé)

Implémentation :

• Champ nir_chiffre VARCHAR(15) NOT NULL dans assistantes_maternelles
• Validation : 15 chiffres exactement
• Affichage masqué dans l'interface (XXX XX XX XX XXX 123)

---

9. Suppression notifications SMS

Décision : ✅ Supprimer les notifications SMS, garder uniquement Email

Justification :

• Pas de plus-value identifiée
• Coût supplémentaire (service SMS)
• Complexité (intégration Twilio/OVH)
• Email suffit largement

Action :

• Amender le CDC v1.4
• Remplacer "Email OU SMS" par "Email"
• Supprimer toute mention de SMS

Référence : Ticket #57

---

🚫 Décisions Phase 2 (reportées)

10. Gestion erreurs SMTP (renvoyer email)

Décision : ⏸️ Phase 2 ou cas par cas

Justification :

• Pas prioritaire pour MVP
• Downtime SMTP rare (< 24h)
• Recréation dossier acceptable en phase de test
• Peut être ajouté plus tard si besoin terrain

---

11. Sauvegarde & Restauration automatique

Décision : ⏸️ Phase finale (quand tout fonctionne)

Justification :

• Pas bloquant pour développement
• Nécessite application stable
• Script pg_dump simple à ajouter
• Documentation pour admins sys

À faire :

• Script backup.sh avec cron
• Guide sauvegarde/restauration
• Test restauration

---

12. RGPD avancé (droit à l'oubli, export données)

Décision : ⏸️ Phase 2

Justification :

• Conformité de base assurée (consentement, traçabilité)
• Droit à l'oubli : Peu de demandes en phase test
• Export données : Peut être fait manuellement en phase test

À faire :

• API suppression compte (soft delete)
• API export données personnelles (JSON)
• Anonymisation comptes inactifs

---

13. Statistiques dashboard

Décision : ⏸️ Phase 2 (besoin d'utilisateurs d'abord)

Justification :

• Pas de données = pas de statistiques
• Fonctionnalité importante pour vente
• Nécessite application en production

À faire :

• API statistiques (comptes, enfants, AM, validations)
• Widgets dashboard (graphiques)
• Export rapports

---

14. Migration de données

Décision : ❌ Pas de migration prévue

Justification :

• Pas de système existant à migrer
• Application nouvelle
• Import CSV peut être ajouté cas par cas si besoin

---

15. Documentation utilisateur

Décision : ⏸️ Phase 2 (formation présentiel prioritaire)

Justification :

• Premiers utilisateurs : Formation directe par l'équipe
• Documentation nécessaire pour scalabilité
• Vidéos tutoriels utiles mais pas bloquant

À faire :

• Guide utilisateur gestionnaire
• Guide utilisateur parent/AM
• FAQ
• Vidéos tutoriels

---

🔐 Décisions Sécurité

16. Chiffrement mots de passe configuration

Décision : ✅ AES-256-CBC pour mots de passe SMTP

Justification :

• Sécurité (mots de passe SMTP en clair = risque)
• Conformité sécurité
• Déchiffrement uniquement en mémoire

Implémentation :

• Type encrypted dans table configuration
• Clé de chiffrement dans .env (32 caractères)
• Service ConfigService gère chiffrement/déchiffrement

---

17. Hash mots de passe utilisateurs

Décision : ✅ Bcrypt avec 12 rounds

Justification :

• Standard industrie
• Résistant aux attaques brute-force
• Configurable (rounds dans config)

---

18. Tokens création mot de passe

Décision : ✅ UUID avec expiration 7 jours

Justification :

• Sécurité (UUID impossible à deviner)
• Expiration (limite fenêtre d'attaque)
• Durée configurable (dans table configuration)

---

19. JWT sessions

Décision : ✅ JWT avec expiration 24h

Justification :

• Stateless (pas de session en BDD)
• Performance (pas de lookup BDD à chaque requête)
• Durée configurable

---

📊 Décisions Base de Données

20. PostgreSQL vs autres SGBD

Décision : ✅ PostgreSQL 17

Justification :

• Open-source
• Robuste et performant
• Support JSON (flexibilité)
• Support UUID natif
• Communauté active

---

21. ORM : Prisma vs TypeORM

Décision : ✅ Prisma (mais TypeORM déjà en place)

Justification Prisma :

• Type-safety
• Migrations claires
• Génération client automatique

Note : Le projet YNOV utilise TypeORM. À évaluer si migration vers Prisma nécessaire.

---

22. Migrations versionnées

Décision : ✅ Migrations SQL versionnées

Justification :

• Traçabilité des changements schéma
• Rollback possible
• Déploiement automatisé

Implémentation :

• Fichiers XX_nom_migration.sql
• Exécution via prisma migrate deploy
• User app_admin pour DDL
• User app_user pour DML (runtime)

---

🧪 Décisions Tests

23. Stratégie de tests

Décision : ✅ Tests unitaires + intégration + E2E

Justification :

• Qualité code
• Confiance déploiement
• Détection régression

Couverture cible :

• Tests unitaires : > 80%
• Tests intégration : Workflows complets
• Tests E2E : Parcours utilisateurs critiques

---

📝 Décisions Documentation

24. Structure documentation

Décision : ✅ Documentation centralisée dans /docs/ avec numérotation

Justification :

• Lisibilité (ordre logique)
• Maintenance (tout au même endroit)
• Versioning (Git)

Structure :

docs/
├── 00_INDEX.md
├── 01_CAHIER-DES-CHARGES.md
├── 02_ARCHITECTURE.md
├── 03_DEPLOYMENT.md
├── 10_DATABASE.md
├── 11_API.md
├── 20_WORKFLOW-CREATION-COMPTE.md
├── 21_CONFIGURATION-SYSTEME.md
├── 22_DOCUMENTS-LEGAUX.md   # pointeur → juridique/
├── 27_BRIEFING-FRONTEND.md
├── PROCEDURE-API-GITEA.md   # pointeur → 26_GITEA-API.md
├── juridique/
│   ├── README.md
│   ├── cgu.md
│   ├── cgc.md
│   └── 22_DOCUMENTS-LEGAUX.md
├── archive/
│   ├── README.md
│   ├── temporaires/
│   └── obsolete/
├── 23_LISTE-TICKETS.md
├── 24_DECISIONS-PROJET.md (ce document)
├── 90_AUDIT.md
└── test-data/

---

🔄 Décisions Workflow

25. Gitea + Webhook + Déploiement automatique

Décision : ✅ Déploiement automatique sur push master

Justification :

• Productivité (pas de déploiement manuel)
• Fiabilité (script testé)
• Rapidité (feedback immédiat)

Workflow :

1. Push sur master
2. Webhook Gitea déclenché
3. Script deploy-ptitspas.sh exécuté
4. Git pull + Migrations + Docker rebuild + Restart

---

26. Branches Git

Décision : ✅ Stratégie simple : master + feature branches

Justification :

• Simplicité (petite équipe)
• Flexibilité

Branches :

• master : Production
• archive/* : Archives (ex: maquette initiale)
• migration/* : Migrations (ex: intégration YNOV)
• feature/* : Nouvelles fonctionnalités

---

🎫 Décisions Ticketing

27. Taille des tickets

Décision : ✅ Tickets relativement petits (2-6h)

Justification :

• Granularité (suivi précis)
• Motivation (tickets terminables rapidement)
• Revue de code facilitée

---

28. Organisation tickets

Décision : ✅ 1 ticket = 1 fonctionnalité complète (Front + Back + BDD si nécessaire)

Justification :

• Cohérence (toute la feature développée ensemble)
• Testable (end-to-end immédiatement)
• Atomique (livraison de valeur fonctionnelle)

Alternative rejetée :

• ❌ 1 ticket Front + 1 ticket Back + 1 ticket BDD = Dépendances complexes

---

🚀 Décisions Déploiement

29. Docker Compose vs Kubernetes

Décision : ✅ Docker Compose

Justification :

• Simplicité (on-premise petite/moyenne collectivité)
• Pas de besoin de scalabilité horizontale
• Maintenance facile

Alternative rejetée :

• ❌ Kubernetes : Overkill pour on-premise mono-instance

---

30. Traefik comme reverse proxy

Décision : ✅ Traefik

Justification :

• Configuration automatique (labels Docker)
• SSL Let's Encrypt automatique
• Dashboard intégré

---

📊 Logs & Monitoring

31. Système de logs

Décision : ✅ Winston avec rotation quotidienne

Justification :

• Standard NestJS
• Rotation automatique (pas de disque plein)
• Niveaux de log (info, warn, error)
• Transports multiples (console + fichier)

Logs à capturer :

• Logs applicatifs (info, warn, error)
• Logs emails (succès/échec SMTP)
• Logs connexions (qui se connecte quand)
• Logs validations (qui valide quoi)

---

📋 Résumé des décisions critiques

#	Décision	Statut	Impact
1	Mono-repo	✅ Phase 1	Architecture
2	On-premise avec config dynamique	✅ Phase 1	Déploiement
3	Système de fichiers pour uploads	✅ Phase 1	Stockage
4	Versioning documents légaux	✅ Phase 1	RGPD
5	Inscription sans MDP	✅ Phase 1	UX
6	Genre enfant obligatoire (H/F)	✅ Phase 1	Métier
7	Un seul champ téléphone	✅ Phase 1	Simplification
8	NIR obligatoire AM	✅ Phase 1	Conformité
9	Suppression SMS	✅ Phase 1	Simplification
10	Renvoyer email	⏸️ Phase 2	Nice-to-have
11	Sauvegarde auto	⏸️ Phase finale	Ops
12	RGPD avancé	⏸️ Phase 2	Conformité
13	Statistiques	⏸️ Phase 2	Business
14	Migration données	❌ Rejeté	N/A
15	Doc utilisateur	⏸️ Phase 2	Formation
31	Logs Winston	✅ Phase 1	Monitoring

---

🔄 Historique des modifications

Date	Version	Modifications
25/11/2025	1.0	Création du document - Toutes les décisions initiales
09/02/2026	1.1	Configuration initiale : un seul panneau Paramètres (3 sections) dans le dashboard, plus de Setup Wizard dédié ; navigation bloquée jusqu'à sauvegarde

---

Dernière mise à jour : 9 Février 2026
Version : 1.1
Statut : ✅ Document validé