🔄 Diagrammes d’états CV-builder

Note

📺 Diagrammes SVG de ce document

etats-cv.svg — cycle de vie du document CV (Nouveau → Persisté → Édité ⇄ Enregistré → Supprimé)
etats-export-pdf.svg — états de l’export PDF (100 % navigateur, window.print())
etats-lien-partage.svg — états du partage (shareEnabled sur cvDocuments)

Documents liés : Cas d’utilisation · Diagramme de classes · Architecture backend

Track Fonctionnel 2TUP — Phase 2 : Modèle dynamique

Les diagrammes d’états complètent le modèle statique (classes) en décrivant comment les objets à cycle de vie significatif transitionnent entre leurs états. Notation UML : état initial (●), état final (◉), transitions événement( args ) / action, délais after( … ).

Point important : le CvDocument backend ne possède aucun champ status — il n’existe pas de statut DRAFT/PUBLISHED/ARCHIVED persisté côté serveur (le statut affiché dans l’écran liste est purement visuel, côté interface). Les états modélisés ici sont donc des états observables : présence d’un currentCvId côté frontend, debounce d’autosave en attente, lastSavedAt, shareEnabled en base.

Trois objets ont un cycle de vie significatif : le document CV (cvDocuments), l'export PDF (processus navigateur) et le partage (shareToken/shareSlug/shareEnabled).

Cycle de vie du document CV

De Vers Transition

De	Vers	Transition
● initial	Nouveau (non persisté)	ouverture du builder — `currentCvId = null`, données en mémoire (store Pinia)
Nouveau	Persisté	wizard Clara / import PDF / import profil / premier autosave (UC01–UC03, UC19) `/ POST /cv-documents` — id Mongo attribué, `shareToken` UUID généré
Persisté	Édité	`modifier cvData` — toute édition de section (UC06–UC09)
Édité	Édité	nouvelle frappe — réarme le debounce de 2 s (`watchDebounced`, deep)
Édité	Enregistré	`after( 2 s ) / PUT /cv-documents/{id}` (UC19) ; les actions IA validées dans le chat déclenchent `autoSave()` immédiatement (UC16)
Enregistré	Édité	`modifier cvData` — le cycle reprend
Enregistré	Snapshot de version	`créerVersion` (UC14) — copie immuable dans `cvDocumentVersions`, rotation FIFO max 10
Snapshot de version	Enregistré	`restaurer` — le contenu du snapshot recharge `data`
Persisté / Enregistré	Supprimé	`DELETE /cv-documents/{id}` (UC05) — confirmation requise, suppression définitive (pas de corbeille, pas de soft delete)
Supprimé	◉ final	immédiat — aucune restauration possible

● initial

Nouveau (non persisté)

ouverture du builder — currentCvId = null, données en mémoire (store Pinia)

Nouveau

Persisté

wizard Clara / import PDF / import profil / premier autosave (UC01–UC03, UC19) / POST /cv-documents — id Mongo attribué, shareToken UUID généré

Persisté

Édité

modifier cvData — toute édition de section (UC06–UC09)

Édité

nouvelle frappe — réarme le debounce de 2 s (watchDebounced, deep)

Édité

Enregistré

after( 2 s ) / PUT /cv-documents/{id} (UC19) ; les actions IA validées dans le chat déclenchent autoSave() immédiatement (UC16)

Enregistré

Édité

modifier cvData — le cycle reprend

Enregistré

Snapshot de version

créerVersion (UC14) — copie immuable dans cvDocumentVersions, rotation FIFO max 10

Snapshot de version

Enregistré

restaurer — le contenu du snapshot recharge data

Persisté / Enregistré

Supprimé

DELETE /cv-documents/{id} (UC05) — confirmation requise, suppression définitive (pas de corbeille, pas de soft delete)

Supprimé

◉ final

immédiat — aucune restauration possible

États de l’export PDF

L’export (UC11) est entièrement réalisé par le navigateur : exportVectorPdf() prépare le rendu (nextTick + requestAnimationFrame, composant CvPrintDocument téléporté dans body#cv-print-root, règles @media print et @page A4 marge 12 mm) puis appelle window.print(). La boîte d’impression s’ouvre : l’utilisateur enregistre le PDF (vectoriel, texte sélectionnable — événement Plausible cv_exported) ou annule et revient à l’aperçu. Il n’existe aucun état serveur : l’endpoint POST /api/v1/cvs/{id}/export répond 501 NOT_IMPLEMENTED et aucun PDF n’est stocké côté backend.

États du partage

Le shareToken (UUID) existe dès la création du document ; c’est le booléen shareEnabled (défaut false) qui gouverne l’accès public. Deux états seulement :

État Description

État	Description
Partage désactivé (défaut)	`shareEnabled = false` — le lien public répond 404 ; le token n’est jamais détruit
Partage activé	`shareEnabled = true` — le CV est servi au visiteur via `GET /cv-documents/shared/{token}` ou `/shared/s/{slug}` (UC13), route publique frontend `/cv/:token`, en-tête `X-Robots-Tag: noindex`

Partage désactivé (défaut)

shareEnabled = false — le lien public répond 404 ; le token n’est jamais détruit

Partage activé

shareEnabled = true — le CV est servi au visiteur via GET /cv-documents/shared/{token} ou /shared/s/{slug} (UC13), route publique frontend /cv/:token, en-tête X-Robots-Tag: noindex

Transitions : activation/désactivation par PUT /cv-documents/{id}/share (UC12) — réversibles à volonté, le token restant identique. Sur l’état activé, la mise à jour du slug est validée par la regex ^[a-z0-9][a-z0-9-]{1,58}[a-z0-9]$ et renvoie 409 CONFLICT si le slug est déjà pris. Il n’y a ni expiration, ni révocation par date, ni mot de passe, ni compteur de vues.

Sync Gate — Cohérence statique ↔ dynamique

Les états du document CV ne correspondent à aucun champ status : ils reflètent currentCvId, le debounce d’autosave et lastSavedAt du store useCvBuilderStore, côté frontend, et les champs réels de CvDocument (shareEnabled, updatedAt) du modèle de classes.
Chaque transition serveur est portée par un service documenté dans l’architecture backend (CvDocumentService, CvVersionService, CvShareService).
Aucune transition automatique planifiée côté serveur : la seule échéance temporelle est le debounce de 2 s du frontend (UC19) ; la rotation FIFO des versions (max 10) s’applique de façon synchrone à chaque créerVersion.

Verdict : modèle dynamique aligné avec le code réel et les 19 cas d’utilisation — validé.