[Full-stack] Audit / traçabilité des modifications dossier et profils (parent/AM) #128

New Issue

2026-05-13T14:55:16Z

jmartin commented

2026-05-13 14:55:16 +00:00

Contexte

Pour la sécurité et le suivi des dossiers (familles et assistantes maternelles), il faut pouvoir savoir qui a modifié quoi, quand sur les données d'un dossier ou d'un profil. C'est essentiel en cas de litige ou désaccord entre co-parents, de support / audit, et pour la conformité minimale.

Aujourd'hui :

Certaines entités ont déjà des timestamps cree_le / modifie_le (dossier_famille, utilisateurs), mais ils ne disent pas qui a modifié, ni quels champs, ni les événements transverses (refus, validation, fusion de comptes…).
Il n'existe aucun journal d'audit structuré.

Objectif

Mettre en place un journal d'audit (qui / quand / quoi) couvrant :

Dossier famille (parents, enfants, présentation / motivation).
Dossier assistante maternelle (identité, infos pro, photo, champs métier).

…sans logger tout le bruit applicatif.

Périmètre & règles produit

1. Règle simple — alignée inscription

À chaque modification d'une information fournie lors de la création du dossier parent ou AM, un événement est loggé. La liste exacte est dérivée des champs persistés à l'inscription (RegisterParentCompletDto, RegisterAMCompletDto et entités liées), ce qui couvre notamment :

identité, coordonnées (adresse, téléphone, ville, code postal, …),
photo (parent, AM, enfants),
enfants (parcours parent : prénom/nom, dates, genre, consentement, …),
texte de présentation / motivation,
champs métier AM (NIR, agrément, capacité d'accueil, places dispo, biographie, …).

Exclus par défaut (sauf décision ultérieure) : lectures, listings, requêtes purement techniques, heartbeats, etc.

2. Actions structurelles et événements métier (toujours loggés)

Association / fusion de deux comptes, rattachement co-parent, affectation ou changement de numero_dossier, tout regroupement ou scission identifiable → événement dédié (qui, quand, identifiants concernés, type d'opération).
Cycle de vie dossier / compte : refus, validation, suspension (et équivalents) → une ligne d'audit par action, pour une timeline lisible côté gestionnaire.

Architecture proposée

Journal d'audit en BDD (recommandé vs simple fichier)

Permet requêtes / filtres par numero_dossier ou user_id, sauvegardes PG, cohérence transactionnelle.
Colonnes typiques (à figer en spec technique) :
- id
- occurred_at (timestamptz)
- actor_user_id (nullable si action système) + actor_role
- numero_dossier (dénormalisé pour filtrage)
- entity_type (utilisateur | parent | assistante_maternelle | enfant | dossier_famille | …)
- entity_id
- action (create | update | delete | événement métier : refus, validation, suspension, fusion_comptes, affectation_numero_dossier, …)
- changes JSON (ancien / nouveau ou patch, ou résumé pour les événements)
- optionnels : request_id, ip, source (gestionnaire_ui, selfservice_reprise, …)
Écriture dans la même transaction que la modification métier (ou outbox si async).

Colonnes « création / dernière modification »

Ne pas dupliquer sur chaque table : cree_le / modifie_le existent déjà sur dossier_famille et utilisateurs.
Faire un inventaire des entités du dossier (parents, enfants, AM, pièces jointes…) et compléter uniquement où il manque des @UpdateDateColumn / triggers.
Si besoin d'une « dernière modification dossier » unique par numero_dossier : soit vue / requête sur max(modifie_le), soit colonne dérivée sur une entité pivot — à trancher en spec.

Fichier

Réservé éventuellement en complément (export append-only, intégration SI) ; pas comme source unique si l'app affiche l'historique.

Accès gestionnaire (exigence métier)

Le gestionnaire doit pouvoir consulter facilement l'historique des modifications d'un dossier (numero_dossier), notamment en cas de litige entre co-parents.
Backend : endpoint dédié (ex. GET …/dossiers/:numeroDossier/audit ou sous-ressource des routes gestionnaire existantes), pagination, tri par date, contrôle d'accès gestionnaire / admin (même périmètre que la validation dossier).
Frontend : entrée visible depuis le parcours d'examen d'un dossier (wizard / fiche dossier) — onglet ou panneau « Historique des modifications », pas une page cachée.
Contenu affiché minimum : date / heure, acteur (identité + rôle), nature du changement (champs ou résumé JSON lisible) ; distinction claire parent 1 / parent 2 / AM / gestionnaire / admin.

Visibilité parents & AM (phase suivante)

À terme, lorsque les parents et les AM auront leur tableau de bord, un sous-menu discret (non mis en avant, mais accessible) donnera accès au même historique côté demandeur, incluant toutes les lignes d'audit (gestionnaire, admin, parent, AM).

→ Le ticket peut être livré en deux temps si nécessaire : MVP (API + écran gestionnaire), phase dashboard (entrée parent/AM dans leur tableau de bord, dépend de l'avancée des dashboards).

Points transverses

Sécurité / secrets : exigence implicite — pas de mots de passe, tokens en clair, etc. dans les payloads d'audit.
RGPD / rétention : durée de conservation des lignes d'audit, anonymisation à la suppression compte → pas urgent pour la V1, peut faire l'objet d'une issue dédiée.
Export CSV / PDF gestionnaire : hors périmètre V1 — ticket séparé en phase 2.
Alignement avec les flux modification dossier (en attente + refusé, mêmes DTO / même apply…(context)) : l'audit doit recevoir un source ou correlation_id pour distinguer gestionnaire vs demandeur.

Critères de done (V1)

Migration / mise à jour database/BDD.sql : table d'audit + index utiles (numero_dossier, occurred_at, actor_user_id).
Inventaire & complétion @CreateDateColumn / @UpdateDateColumn manquants sur les entités du dossier.
Service applicatif appendAuditLog(...) (ou équivalent) branché sur :
- création / modification des champs « inscription parent / AM » ;
- refus, validation, suspension ;
- affectation / changement numero_dossier, fusion / association de comptes.
API GET …/dossiers/:numeroDossier/audit (gestionnaire / admin) — pagination, tri par date.
Écran / panneau gestionnaire « Historique des modifications » sur la fiche dossier (famille et AM).
Tests unitaires / intégration sur les chemins critiques.
OpenAPI à jour.

Hors périmètre (à scinder en autres tickets si besoin)

Export CSV / PDF de l'historique.
Durée de rétention RGPD + anonymisation à la suppression compte.
Entrée « historique » dans le tableau de bord parent / AM (dépend des dashboards).

## Contexte Pour la sécurité et le suivi des dossiers (familles et assistantes maternelles), il faut pouvoir **savoir qui a modifié quoi, quand** sur les données d'un dossier ou d'un profil. C'est essentiel en cas de **litige ou désaccord entre co-parents**, de support / audit, et pour la conformité minimale. Aujourd'hui : - Certaines entités ont déjà des timestamps **`cree_le` / `modifie_le`** (`dossier_famille`, `utilisateurs`), mais ils ne disent pas **qui** a modifié, ni **quels champs**, ni les **événements transverses** (refus, validation, fusion de comptes…). - Il n'existe **aucun journal d'audit** structuré. ## Objectif Mettre en place un **journal d'audit** (qui / quand / quoi) couvrant : - **Dossier famille** (parents, enfants, présentation / motivation). - **Dossier assistante maternelle** (identité, infos pro, photo, champs métier). …sans logger tout le bruit applicatif. ## Périmètre & règles produit ### 1. Règle simple — alignée inscription À **chaque modification** d'une information **fournie lors de la création** du dossier **parent** ou **AM**, un événement est **loggé**. La liste exacte est dérivée des champs persistés à l'inscription (`RegisterParentCompletDto`, `RegisterAMCompletDto` et entités liées), ce qui couvre notamment : - identité, coordonnées (adresse, téléphone, ville, code postal, …), - **photo** (parent, AM, enfants), - enfants (parcours parent : prénom/nom, dates, genre, consentement, …), - texte de présentation / motivation, - champs métier AM (NIR, agrément, capacité d'accueil, places dispo, biographie, …). **Exclus par défaut** (sauf décision ultérieure) : lectures, listings, requêtes purement techniques, heartbeats, etc. ### 2. Actions structurelles et événements métier (toujours loggés) - **Association / fusion de deux comptes**, **rattachement co-parent**, **affectation ou changement de `numero_dossier`**, tout regroupement ou scission identifiable → événement dédié (qui, quand, identifiants concernés, type d'opération). - **Cycle de vie** dossier / compte : **refus**, **validation**, **suspension** (et équivalents) → une ligne d'audit par action, pour une **timeline lisible** côté gestionnaire. ## Architecture proposée ### Journal d'audit en BDD (recommandé vs simple fichier) - Permet requêtes / filtres par `numero_dossier` ou `user_id`, sauvegardes PG, cohérence transactionnelle. - **Colonnes typiques** (à figer en spec technique) : - `id` - `occurred_at` (timestamptz) - `actor_user_id` (nullable si action système) + `actor_role` - `numero_dossier` (dénormalisé pour filtrage) - `entity_type` (`utilisateur` | `parent` | `assistante_maternelle` | `enfant` | `dossier_famille` | …) - `entity_id` - `action` (`create` | `update` | `delete` | événement métier : `refus`, `validation`, `suspension`, `fusion_comptes`, `affectation_numero_dossier`, …) - `changes` JSON (ancien / nouveau ou patch, ou résumé pour les événements) - optionnels : `request_id`, `ip`, `source` (`gestionnaire_ui`, `selfservice_reprise`, …) - Écriture **dans la même transaction** que la modification métier (ou outbox si async). ### Colonnes « création / dernière modification » - Ne **pas dupliquer** sur chaque table : `cree_le` / `modifie_le` existent déjà sur `dossier_famille` et `utilisateurs`. - Faire un **inventaire** des entités du dossier (parents, enfants, AM, pièces jointes…) et **compléter** uniquement où il manque des `@UpdateDateColumn` / triggers. - Si besoin d'une **« dernière modification dossier »** unique par `numero_dossier` : soit **vue / requête** sur `max(modifie_le)`, soit colonne dérivée sur une entité pivot — à trancher en spec. ### Fichier Réservé éventuellement en **complément** (export append-only, intégration SI) ; **pas** comme source unique si l'app affiche l'historique. ## Accès gestionnaire (exigence métier) - Le **gestionnaire** doit pouvoir consulter **facilement** l'historique des modifications d'un dossier (`numero_dossier`), notamment **en cas de litige entre co-parents**. - **Backend** : endpoint dédié (ex. `GET …/dossiers/:numeroDossier/audit` ou sous-ressource des routes gestionnaire existantes), pagination, tri par date, contrôle d'accès **gestionnaire / admin** (même périmètre que la validation dossier). - **Frontend** : entrée visible depuis le parcours d'examen d'un dossier (wizard / fiche dossier) — onglet ou panneau **« Historique des modifications »**, pas une page cachée. - **Contenu affiché minimum** : date / heure, acteur (identité + rôle), nature du changement (champs ou résumé JSON lisible) ; distinction claire **parent 1 / parent 2 / AM / gestionnaire / admin**. ## Visibilité parents & AM (phase suivante) À terme, lorsque les **parents** et les **AM** auront leur **tableau de bord**, un **sous-menu discret** (non mis en avant, mais accessible) donnera accès au **même historique** côté demandeur, **incluant toutes** les lignes d'audit (gestionnaire, admin, parent, AM). → Le ticket peut être livré en deux temps si nécessaire : **MVP** (API + écran gestionnaire), **phase dashboard** (entrée parent/AM dans leur tableau de bord, dépend de l'avancée des dashboards). ## Points transverses - **Sécurité / secrets** : exigence implicite — **pas** de mots de passe, tokens en clair, etc. dans les payloads d'audit. - **RGPD / rétention** : durée de conservation des lignes d'audit, anonymisation à la suppression compte → **pas urgent pour la V1**, peut faire l'objet d'une issue dédiée. - **Export CSV / PDF** gestionnaire : **hors périmètre V1** — ticket séparé en phase 2. - **Alignement** avec les flux **modification dossier** (en attente + refusé, mêmes DTO / même `apply…(context)`) : l'audit doit recevoir un `source` ou `correlation_id` pour distinguer gestionnaire vs demandeur. ## Critères de done (V1) - [ ] Migration / mise à jour [`database/BDD.sql`](database/BDD.sql) : table d'audit + index utiles (`numero_dossier`, `occurred_at`, `actor_user_id`). - [ ] Inventaire & complétion `@CreateDateColumn` / `@UpdateDateColumn` manquants sur les entités du dossier. - [ ] Service applicatif `appendAuditLog(...)` (ou équivalent) branché sur : - création / modification des champs « inscription parent / AM » ; - refus, validation, suspension ; - affectation / changement `numero_dossier`, fusion / association de comptes. - [ ] API `GET …/dossiers/:numeroDossier/audit` (gestionnaire / admin) — pagination, tri par date. - [ ] Écran / panneau **gestionnaire** « Historique des modifications » sur la fiche dossier (famille et AM). - [ ] Tests unitaires / intégration sur les chemins critiques. - [ ] OpenAPI à jour. ## Hors périmètre (à scinder en autres tickets si besoin) - Export CSV / PDF de l'historique. - Durée de rétention RGPD + anonymisation à la suppression compte. - Entrée « historique » dans le tableau de bord parent / AM (dépend des dashboards).

jmartin added the backend database frontend gestionnaire p2 phase-1 rgpd security v0.1.0 labels 2026-05-13 14:55:29 +00:00

jmartin added this to the 0.1.0 milestone 2026-05-13 14:55:29 +00:00

jmartin removed this from the 0.1.0 milestone 2026-05-13 14:58:59 +00:00

jmartin referenced this issue

2026-07-17 15:05:00 +00:00

[Epic] Gestion de la suppression des utilisateurs / dossiers / enfants / AM #154

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jmartin/petitspas#128