569 lines
14 KiB
Markdown
569 lines
14 KiB
Markdown
# 📋 Décisions Projet - P'titsPas
|
||
|
||
**Version** : 1.0
|
||
**Date** : 25 Novembre 2025
|
||
**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)
|
||
- Setup Wizard à la première connexion
|
||
- Configuration SMTP dynamique
|
||
- Personnalisation (nom app, logo, URL)
|
||
|
||
**Référence** : [21_CONFIGURATION-SYSTEME.md](./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](./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](./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
|
||
├── 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 |
|
||
|
||
---
|
||
|
||
**Dernière mise à jour** : 25 Novembre 2025
|
||
**Version** : 1.0
|
||
**Statut** : ✅ Document validé
|
||
|