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)
8 KiB
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
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
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)
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.