Conception complete (Phase 0) pour formation-hub Acadenice : - 19 docs Merise Agile + UML + GitOps + plans (tests/deploy/ops/api) cf docs/00-readme.md pour l'index complet - Stack Docker compose (Docmost + Baserow + Postgres + Redis + MinIO local FS) compose.yml + compose.staging.yml + compose.prod.yml - CI/CD GitHub Actions skeleton (ci, deploy-staging, deploy-prod) - Bridge service skeleton (Hono + TS + Biome + Vitest + zod + pino) - Templates GitHub : PR + 3 issue types + CODEOWNERS + dependabot.yml - Scripts ops : healthcheck, backup quotidien, smoke-test post-deploy - LICENSE AGPL-3.0 + SECURITY.md + CONTRIBUTING.md + CHANGELOG.md - Diagramme drawIO archi infra (XML importable dans diagrams.net) Decisions structurelles enregistrees : - Scope CFA + Agence avec entite PERSONNE pivot multi-roles (ADR-001) - Stack composite Docmost AGPL + Baserow MIT + bridge custom (ADR-001) - Path B : UX quasi-unified via Tiptap node-views custom (ADR-002) - Monorepo trunk-based development (ADR-003) - Postgres separe Docmost/Baserow (ADR-004) - Bridge stack Node 22 + Hono (ADR-005) - Repo neuf prefere a fork Docmost - Prod-like des le jour 1 (pas MVP)
207 lines
8 KiB
Markdown
207 lines
8 KiB
Markdown
# Scope etendu — CFA + Agence + Internes
|
|
|
|
> **APPROVED le 2026-05-07 par Corentin** — Option B retenue (CFA + Agence via PERSONNE pivot).
|
|
> **Etudiants : non modelises en Baserow**, juste users Docmost avec spaces libres (heritent des templates et integrations qu'on construit).
|
|
> Refacto des docs Merise effectue dans la foulee.
|
|
> Date : 2026-05-07.
|
|
> Source : Document Fondateur Acadenice (KxvipVcxNV) lu sur le wiki.
|
|
|
|
## 1. Constat
|
|
|
|
Mon modele initial couvre uniquement le **CFA** (formations / blocs / modules / formateurs / heures). C'est partiel.
|
|
|
|
Acadenice est en realite **trois activites coordonnees** :
|
|
|
|
| Activite | Description | Entites cles |
|
|
|----------|-------------|--------------|
|
|
| **CFA** (Centre de Formation des Apprentis) | Formation : dev, graphisme, marketing, IoT, cybersec. Max 15 etudiants/classe. | FORMATION, BLOC, MODULE, FORMATEUR, ETUDIANT, INSCRIPTION |
|
|
| **AGENCE dev** | Developpement de projets pour clients reels. Les formateurs y bossent en parallele de leurs cours. | CLIENT, PROJET, TACHE, SITE_WEB, SERVEUR, INTERVENTION |
|
|
| **OPERATIONS internes** | RH, comm, batiment, evenements, vision strategique. | SALARIE, EVENEMENT, COMMUNICATION |
|
|
|
|
**Le lien clef** : un FORMATEUR est souvent aussi DEVELOPPEUR sur projets agence. Sa capacite annuelle se split entre les deux activites.
|
|
|
|
C'est ce qui fait l'ADN d'Acadenice (cf doc fondateur) — pas un detail qu'on peut ignorer.
|
|
|
|
## 2. Question structurante
|
|
|
|
**Le projet "formation-hub" doit-il modeliser :**
|
|
|
|
- **Option A — CFA only** (mon modele actuel) : on reste sur formation/heures formateurs. L'Agence et les Operations ont leurs propres outils (Linear/Notion/etc) ou ne sont pas modelises.
|
|
- **Option B — CFA + Agence unifies** : on ajoute le suivi projets clients. La capacite Formateur-Dev est tracee unifiee. Vue 360 d'une personne (cours + projets).
|
|
- **Option C — Toute l'organisation** : CFA + Agence + Internes. Outil ERP-leger complet.
|
|
|
|
Mon vote : **Option B**. Justification :
|
|
- Le lien CFA-Agence est central a la vision Acadenice (cf doc fondateur, section "Le lien agence-formation"). Le modeliser = capter la vraie valeur.
|
|
- L'Option C ajoute beaucoup de scope (RH, batiment, comm) qui ne tirent pas le projet vers ses objectifs immediats.
|
|
- L'Option A laisse de la valeur sur la table — la capacite Formateur-Dev est un differentiateur metier reel.
|
|
|
|
## 3. Extension du modele propose (Option B)
|
|
|
|
### 3.1 Nouvelle entite pivot : PERSONNE
|
|
|
|
```mermaid
|
|
classDiagram
|
|
class Personne {
|
|
+int id
|
|
+string nom
|
|
+string prenom
|
|
+Email email
|
|
+decimal capacite_annuelle_totale
|
|
+decimal split_formation_pct
|
|
+decimal split_agence_pct
|
|
+Statut statut
|
|
}
|
|
class RoleFormateur {
|
|
+decimal heures_attribuees_formation
|
|
+decimal heures_restantes_formation
|
|
}
|
|
class RoleDeveloppeur {
|
|
+decimal heures_attribuees_agence
|
|
+decimal heures_restantes_agence
|
|
}
|
|
class RoleAdmin {
|
|
+permissions[]
|
|
}
|
|
class RoleEtudiant {
|
|
+Date date_inscription
|
|
+Formation formation_courante
|
|
}
|
|
|
|
Personne "1" --> "0..*" RoleFormateur
|
|
Personne "1" --> "0..*" RoleDeveloppeur
|
|
Personne "1" --> "0..*" RoleAdmin
|
|
Personne "1" --> "0..*" RoleEtudiant
|
|
```
|
|
|
|
Une PERSONNE peut cumuler plusieurs roles. La capacite annuelle est splittee entre formation et agence selon un pourcentage configurable.
|
|
|
|
### 3.2 Nouvelles entites Agence
|
|
|
|
```mermaid
|
|
erDiagram
|
|
CLIENT ||--o{ PROJET : "1,N a"
|
|
PROJET ||--o{ TACHE : "1,N comporte"
|
|
TACHE ||--o{ INTERVENTION : "0,N realisee via"
|
|
PERSONNE ||--o{ INTERVENTION : "0,N realise"
|
|
PROJET }o--o{ SITE_WEB : "0,N livre"
|
|
PROJET }o--o{ SERVEUR : "0,N deploie"
|
|
|
|
CLIENT {
|
|
int client_id PK
|
|
string client_nom UNIQUE
|
|
string client_contact_email
|
|
string client_telephone
|
|
text client_notes
|
|
enum client_statut "prospect|actif|inactif|archive"
|
|
}
|
|
PROJET {
|
|
int projet_id PK
|
|
int projet_client_id FK
|
|
string projet_nom
|
|
decimal projet_charge_heures
|
|
decimal projet_heures_realisees "rollup"
|
|
date projet_date_debut
|
|
date projet_date_fin_prevue
|
|
enum projet_statut "devis|en_cours|livre|cloture|abandonne"
|
|
}
|
|
TACHE {
|
|
int tache_id PK
|
|
int tache_projet_id FK
|
|
string tache_titre
|
|
decimal tache_charge_heures
|
|
decimal tache_heures_realisees "rollup"
|
|
enum tache_statut "todo|in_progress|done|abandoned"
|
|
}
|
|
INTERVENTION {
|
|
int intervention_id PK
|
|
int intervention_tache_id FK
|
|
int intervention_personne_id FK
|
|
decimal intervention_heures
|
|
date intervention_date
|
|
text intervention_notes
|
|
}
|
|
```
|
|
|
|
### 3.3 Modele global combine (CFA + Agence + Personne pivot)
|
|
|
|
```mermaid
|
|
erDiagram
|
|
PERSONNE ||--o{ ATTRIBUTION : "FORMATEUR : enseigne"
|
|
PERSONNE ||--o{ INTERVENTION : "DEVELOPPEUR : realise"
|
|
PERSONNE ||--o{ INSCRIPTION : "ETUDIANT : suit"
|
|
|
|
FORMATION ||--o{ BLOC : "contient"
|
|
BLOC ||--o{ MODULE : "comprend"
|
|
MODULE ||--o{ ATTRIBUTION : "attribue"
|
|
|
|
CLIENT ||--o{ PROJET : "a"
|
|
PROJET ||--o{ TACHE : "comporte"
|
|
TACHE ||--o{ INTERVENTION : "realisee"
|
|
|
|
FORMATION ||--o{ INSCRIPTION : "regroupe etudiants"
|
|
|
|
PROJET }o--o{ FORMATION : "lien optionnel : projet pedagogique"
|
|
```
|
|
|
|
Le **lien optionnel PROJET ↔ FORMATION** capte le cas Acadenice ou des etudiants travaillent sur de vrais projets clients comme exercice pedagogique.
|
|
|
|
### 3.4 Capacite cumulee Personne
|
|
|
|
Pour une PERSONNE qui a plusieurs roles :
|
|
|
|
```
|
|
Personne.heures_attribuees_total =
|
|
SUM(ATTRIBUTION.heures_attribuees) WHERE attribution_personne_id = personne_id
|
|
+ SUM(INTERVENTION.heures) WHERE intervention_personne_id = personne_id
|
|
|
|
Personne.heures_restantes =
|
|
Personne.capacite_annuelle_totale - Personne.heures_attribuees_total
|
|
```
|
|
|
|
L'admin voit en un coup d'oeil sur la fiche d'un formateur-dev :
|
|
- Cours attribues : 400h
|
|
- Projets attribues : 600h
|
|
- Capacite totale : 1500h
|
|
- Restant : 500h
|
|
|
|
## 4. Impact sur les docs existants
|
|
|
|
| Doc | Impact | Effort refacto |
|
|
|-----|--------|---------------|
|
|
| 01 - Discovery | Mise a jour scope | 15 min |
|
|
| 02 - Decision Records | Ajouter ADR-006 sur l'extension scope | 15 min |
|
|
| 03 - Data Dictionary | Ajouter PERSONNE, CLIENT, PROJET, TACHE, INTERVENTION, ETUDIANT, INSCRIPTION | 1h |
|
|
| 04 - MCD | Etendre ER diagram, ajouter cardinalites | 30 min |
|
|
| 05 - MLD | Ajouter tables + FK | 30 min |
|
|
| 06 - UML Use Cases | Ajouter acteurs Developpeur, Client, et leurs UC | 30 min |
|
|
| 07 - State Diagrams | Ajouter cycle CLIENT, PROJET, TACHE | 30 min |
|
|
| 08 - MCT | Ajouter operations Agence | 1h |
|
|
| 09 - MOT | Ajouter ligne pour les ops Agence | 30 min |
|
|
| 10 - Class Diagram | Ajouter classes Personne, Client, Projet, Tache, Intervention | 30 min |
|
|
| 11 - Activity Diagrams | Detailler AD-04 et AD-05 | 30 min |
|
|
|
|
**Effort refacto total : ~6-7h** si Option B validee.
|
|
|
|
## 5. Impact sur l'implementation
|
|
|
|
Stack reste identique (Docmost + Baserow + bridge). Mais :
|
|
|
|
- Plus de tables Baserow (12 au lieu de 5)
|
|
- Bridge service plus important (gere la vue unifiee Personne)
|
|
- UI : tableaux de bord par personne (cours + projets en parallele)
|
|
|
|
Capacite estime ajout dev sur Phase 2 : **+2-3 semaines** par rapport au scope CFA-only.
|
|
|
|
## 6. Question pour validation
|
|
|
|
**Tu confirmes Option B ?**
|
|
|
|
- [ ] Option A — CFA only (mon modele actuel reste)
|
|
- [ ] **Option B — CFA + Agence (extension via PERSONNE pivot)** — ma recommandation
|
|
- [ ] Option C — Tout (CFA + Agence + Operations)
|
|
- [ ] Autre — tu precises
|
|
|
|
Si **Option B** : je refacto les docs (effort ~6-7h sur 1 session) et on continue sur le scope etendu.
|
|
Si **Option A** : on reste sur le CFA, et tu modelises l'Agence dans un autre projet plus tard.
|
|
|
|
Une autre validation a faire : **les "Etudiants" doivent-ils avoir leur propre entite dans Baserow** (avec inscription a une formation, suivi pedagogique, etc.) **ou rester juste des spaces Docmost** sans modelisation structuree ? C'est independant de A/B/C — choix metier orthogonal.
|