# Example — Acadenice formation-hub

Cet exemple montre **un cas d'usage parmi d'autres** du bridge generique
DocAdenice / Notion-like : le suivi d'heures formateurs et developpeurs pour
le **CFA + Agence Acadenice**.

## Contexte

Acadenice est :
- un CFA (Centre de Formation des Apprentis) — heures de formation a tracer
- une Agence dev — heures de prestations a tracer

Une meme personne peut porter plusieurs roles : formateur (CFA), developpeur
(Agence), admin/direction/support transverse. La capacite annuelle est
splittee entre les deux activites.

## Pourquoi un exemple et pas du code metier dans le bridge

Le bridge DocAdenice est un **proxy generique style Notion**. Il expose
n'importe quelle table Baserow via `/api/v1/tables/*` sans rien savoir du
metier. La modelisation Acadenice (9 tables, formules de rollup, regles de
gestion) vit :

- **cote Baserow** : schema des 9 tables + formules + vues (cf
  `seed-baserow.md`)
- **cote DocAdenice** : RBAC dynamique avec roles custom (Formateur,
  Developpeur, Direction, Support) qui produisent des claims OIDC
  `acadenice_permissions[]` (cf `example-roles.md`)
- **cote frontend** : interface metier (dashboards capacite, attribution
  modules, saisie heures) consomme l'API generique du bridge

## Comment rejouer cet exemple

1. Provisionner Baserow avec les 9 tables decrites dans `seed-baserow.md`
2. Creer les roles custom DocAdenice de `example-roles.md`
3. Configurer le bridge : il proxie tout, pas de config metier specifique
4. Construire le frontend (Tiptap node-views ou pages dediees Docmost)

## Mapping bridge generique <-> ce metier

| Generique bridge          | Vu dans cet exemple                          |
|---------------------------|----------------------------------------------|
| `/tables`                 | 9 tables : Personne, Formation, Bloc, ...    |
| `/tables/:id/rows`        | CRUD sur une de ces tables                   |
| Webhooks invalidation     | Cache Redis invalide par tableId touche      |
| Cascades cross-table      | Faites cote Baserow via formules + lookups   |
| Permissions `read:tables` | Donnees globalement par DocAdenice via OIDC  |
| Permissions specifiques   | Filtrees cote frontend selon role custom     |

## Autres exemples envisageables

Le meme bridge pourrait servir :

- un CRM custom (3 tables : Contacts, Opportunites, Notes)
- un tracker de bugs (2 tables : Issues, Comments)
- une base d'inventaire IT (5 tables : Asset, Owner, Site, Maintenance, Log)

Aucun de ces cas ne necessite de modification du bridge — juste une config
Baserow + DocAdenice.