Julien Martin
48b01ed3fe
- Création du dossier docs/ pour centraliser la documentation - Ajout de API.md : documentation complète de tous les endpoints - Ajout de DATABASE.md : schéma complet de la base de données - Ajout de AUDIT.md : audit du projet YNOV - Déplacement des README-ARCHITECTURE.md et README-DEPLOYMENT.md vers docs/ - Ajout d'un README.md index dans docs/
99 lines
5.0 KiB
Markdown
99 lines
5.0 KiB
Markdown
# 🕵️ Rapport d'Audit Technique & Fonctionnel - Projet P'titsPas (Ynov)
|
|
|
|
**Date** : 23 Novembre 2025
|
|
**Auditeur** : Assistant IA (Deploy Infra V2)
|
|
**Objet** : État des lieux avant reprise des développements pour finalisation.
|
|
|
|
---
|
|
|
|
## 🚨 Synthèse Exécutive
|
|
|
|
Le projet dispose d'une **base technique saine** (NestJS, PostgreSQL, Docker) et d'une structure de code propre. Cependant, **plusieurs fonctionnalités critiques du Cahier des Charges (CDC) sont manquantes ou incomplètes**, rendant l'application inutilisable en l'état pour le workflow principal (Inscription -> Validation -> Utilisation).
|
|
|
|
**Score d'avancement estimé : 25%**
|
|
(Backend: 60%, Frontend: 10% [Coquille vide], Infra: 80%)
|
|
|
|
---
|
|
|
|
## 1. 🏗️ Infrastructure & Docker
|
|
|
|
### ✅ Points Positifs
|
|
* **Stack propre** : Architecture micro-services (Backend, Frontend, Database, PgAdmin).
|
|
* **Configuration Traefik** : Les labels et le routing (`ynov.ptits-pas.fr`) sont corrects.
|
|
* **Images optimisées** : Utilisation de builds multi-stage.
|
|
|
|
### ⚠️ Problèmes & Correctifs
|
|
1. **Processus Zombies (Critique)** :
|
|
* **Constat** : Plus de 9000 processus zombies détectés.
|
|
* **Cause** : Le conteneur Backend lance `node` en PID 1 sans gestionnaire de signaux (`init`).
|
|
* **Action** : Ajouter `tini` ou `dumb-init` dans le `Dockerfile` Backend.
|
|
2. **Base de Données (Seed)** :
|
|
* **Constat** : Le script d'initialisation (`01_init.sql`) insère un administrateur avec le mot de passe `"admin123"` **en clair**.
|
|
* **Impact** : Impossible de se connecter (le Backend attend un hash Bcrypt).
|
|
* **Action** : Remplacer l'insertion SQL par un vrai hash ou un script de seed NestJS.
|
|
|
|
---
|
|
|
|
## 2. 🔙 Backend (NestJS)
|
|
|
|
### ✅ Points Positifs
|
|
* **Architecture** : Modulaire (Auth, User, Parents, Enfants...).
|
|
* **Qualité Code** : Typage fort, DTOs validés (`class-validator`), Entités TypeORM claires.
|
|
|
|
### ❌ Écarts Fonctionnels Majeurs
|
|
| Fonctionnalité | État | Problème Identifié |
|
|
| :--- | :---: | :--- |
|
|
| **Envoi d'E-mails** | 🔴 **ABSENT** | Aucune librairie mail (Nodemailer) installée. Aucune logique d'envoi. |
|
|
| **Inscription** | 🟠 **Incomplet** | L'utilisateur est créé, mais sa fiche métier (`Parents` ou `AssistanteMaternelle`) **n'est pas générée**. Elle n'est créée qu'à la validation, ce qui empêche le remplissage du profil en amont. |
|
|
| **Validation Compte** | 🟠 **Partiel** | Le changement de statut fonctionne, mais **aucune notification mail** n'est envoyée (requis par CDC). |
|
|
| **Gestionnaire** | ✅ **OK** | La route de création par SuperAdmin existe et est sécurisée. |
|
|
|
|
---
|
|
|
|
## 3. 📱 Frontend (Flutter)
|
|
|
|
### ✅ Points Positifs
|
|
* Structure du projet cohérente.
|
|
* Authentification (Login) implémentée.
|
|
|
|
### ❌ Écarts Fonctionnels Majeurs
|
|
| Écran / Fonction | État | Problème Identifié |
|
|
| :--- | :---: | :--- |
|
|
| **Création Gestionnaire** | 🔴 **VIDE** | Le fichier `gestionnaires_create.dart` contient uniquement un texte placeholder. **Aucun formulaire.** |
|
|
| **Dashboard Admin** | 🔴 **FAKE** | L'écran existe mais affiche des données simulées "en dur" (Mock). **Non connecté à l'API.** Impossible de valider les comptes. |
|
|
| **Dashboard Parent** | 🔴 **FAKE** | L'écran existe, architecture propre (Service/Controller), mais toutes les données (Enfants, Contrats) sont mockées (`TODO: API Call`). |
|
|
| **Dashboard AssMat** | 🔴 **INEXISTANT** | Aucun écran trouvé pour l'accueil des Assistantes Maternelles. |
|
|
| **Contact Support** | 🔴 **Fake** | Bouton présent mais code vide (`// TODO`). |
|
|
| **Signalement Bug** | 🔴 **Fake** | Idem, code non implémenté. |
|
|
|
|
---
|
|
|
|
## 4. 📝 Plan d'Action Prioritaire (Roadmap de Réparation)
|
|
|
|
Pour rendre l'application fonctionnelle selon le "Workflow attendu", voici les étapes techniques à réaliser dans l'ordre :
|
|
|
|
### Étape 1 : Réparation Socle (Infra & Data)
|
|
1. **Fixer le Dockerfile Backend** (Tini pour les zombies).
|
|
2. **Fixer le mot de passe Admin** : Créer un script pour mettre à jour le hash du mot de passe `admin123` en base de données.
|
|
|
|
### Étape 2 : Implémentation Backend (Mail & Workflow)
|
|
3. **Installer `nodemailer`** et configurer le service SMTP (via le serveur mail Host).
|
|
4. **Corriger `register`** : Créer l'entité `Parent`/`AssMat` dès l'inscription (vide mais existante).
|
|
5. **Corriger `validateUser`** : Ajouter l'envoi de mail de notification (Validé/Refusé).
|
|
|
|
### Étape 3 : Implémentation Frontend (Écrans Manquants)
|
|
6. **Développer l'écran "Créer Gestionnaire"** : Formulaire (Nom, Prénom, Email, MDP) + Appel API.
|
|
7. **Vérifier/Finir le Dashboard Gestionnaire** : Liste des utilisateurs "En attente" + Boutons Valider/Refuser.
|
|
|
|
### Étape 4 : Connexion (Workflow Complet)
|
|
8. Tester le cycle complet :
|
|
* Login SuperAdmin -> Création Gestionnaire.
|
|
* Login Gestionnaire -> Vue vide.
|
|
* Inscription Parent -> Apparition dans la liste Gestionnaire.
|
|
* Validation par Gestionnaire -> Mail reçu par Parent.
|
|
* Login Parent -> Accès autorisé.
|
|
|
|
---
|
|
*Ce document sert de référence pour la suite des travaux.*
|
|
|