jmartin/petitspas
1
0
Fork 0
Code Issues 52 Pull Requests Actions Packages Projects Releases Wiki Activity
petitspas/docs/24_DECISIONS-PROJET.md

14 KiB
Raw Blame History

📋 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

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
├── 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é