shikanime · Oct 14, 2026 · Oct 14, 2026
diff --git a/docs/guide/rbac/console-cpin.md b/docs/guide/rbac/console-cpin.md
@@ -2,8 +2,6 @@
 
 Ce document décrit le **modèle d'accès** de la Console CPiN elle-même : comment ses rôles admin et projet se traduisent en permissions, et comment ils sont propagés vers Keycloak.
 
----
-
 ## Vue par rôle
 
 Ce que chaque rôle peut réellement faire dans la Console CPiN. Les chemins `/console/<rôle>` sont **réservés à l'administration plateforme** et distincts des rôles projet `/<slug>/console/<rôle>` :
@@ -20,15 +18,11 @@ Ce que chaque rôle peut réellement faire dans la Console CPiN. Les chemins `/c
 | Security (administration)               | `/console/security`         | Lecture transverse (tous projets, audit)                                                                                        |
 | Guest (utilisateur externe sans groupe) | —                           | Aucun accès jusqu'à ajout à un projet                                                                                           |
 
----
-
 ## 1. Authentification : OIDC via Keycloak
 
 - La Console authentifie ses utilisateurs via **OIDC Keycloak**.
 - Les permissions effectives d'un utilisateur = agrégation (OU binaire) des `permissions` de tous ses rôles (admin + projet).
 
----
-
 ## 2. Rôles projet et permissions
 
 Chaque projet reçoit 4 rôles système par défaut, liés aux groupes `/<slug>/console/*`.
@@ -44,8 +38,6 @@ Chaque projet reçoit 4 rôles système par défaut, liés aux groupes `/<slug>/
 
 `GUEST(0)`, `MANAGE(1)`, `MANAGE_MEMBERS(2)`, `MANAGE_ENVIRONMENTS(3)`, `MANAGE_REPOSITORIES(4)`, `MANAGE_ROLES(5)`, `SEE_SECRETS(6)`, `REPLAY_HOOKS(7)`, `LIST_ENVIRONMENTS(8)`, `LIST_REPOSITORIES(9)`, `LIST_MEMBERS(10)`, `LIST_ROLES(11)`, `MANAGE_DEPLOYMENTS(12)`, `LIST_DEPLOYMENTS(13)`.
 
----
-
 ## 3. Rôles admin et permissions
 
 | Rôle Console                                     | Groupe Keycloak (chemin) | Permissions (`ADMIN_PERMS`)                                                         |
@@ -62,8 +54,6 @@ Chaque projet reçoit 4 rôles système par défaut, liés aux groupes `/<slug>/
 >
 > **Seul un rôle admin peut être lié à un groupe Keycloak existant** via un groupe d'application externe (chemin commençant par `/`). Les rôles projet ont leur groupe d'application préfixé automatiquement par `/<slug>`.
 
----
-
 ## 4. Points d'attention
 
 - **Permissions = masque de bits.** Un rôle est la somme de permissions ; l'agrégation inter-rôles se fait en OU binaire.
@@ -72,8 +62,6 @@ Chaque projet reçoit 4 rôles système par défaut, liés aux groupes `/<slug>/
 - **DevOps sans déploiement applicatif.** Le déploiement applicatif n'est pas couvert par le rôle DevOps par défaut ; ses droits portent sur les environnements, dépôts, hooks et secrets.
 - **Groupe `everyonePerms`.** Un projet peut définir des permissions pour _Tout le monde_, appliquées au-delà des rôles nominatifs.
 
----
-
 ## 5. Qui gère quoi ?
 
 | Élément                           | Géré par                           |
@@ -82,5 +70,3 @@ Chaque projet reçoit 4 rôles système par défaut, liés aux groupes `/<slug>/
 | Rôles admin / projet, permissions | **Console** (base de données)      |
 | Groupes Keycloak dérivés          | **Console** (automatique)          |
 | Application des droits            | **Console** + outils consommateurs |
-
----
diff --git a/docs/guide/rbac/grafana.md b/docs/guide/rbac/grafana.md
@@ -2,8 +2,6 @@
 
 Ce document décrit le **modèle d'accès** mis en place dans Grafana pour chaque projet DSO. Contrairement aux autres outils, l'accès Grafana est **scopé par environnement** (prod / hors-prod) et non par rôle projet.
 
----
-
 ## Vue par rôle
 
 Ce que chaque rôle Console obtient réellement dans Grafana (scopé par environnement). Les chemins `/console/<rôle>` sont **réservés à l'administration plateforme** et distincts des rôles projet `/<slug>/console/<rôle>` :
@@ -21,15 +19,11 @@ Ce que chaque rôle Console obtient réellement dans Grafana (scopé par environ
 
 > L'accès réel dépend de la capacité Console par bucket d'environnement : `MANAGE_ENVIRONMENTS` → Editor, `LIST_ENVIRONMENTS` → Viewer, séparément pour hors-prod (`hprod`) et prod.
 
----
-
 ## 1. Authentification : Grafana via OIDC Keycloak
 
 - Grafana est fédéré au fournisseur OIDC Keycloak. Le mapping **groupe Keycloak → rôle Grafana** est configuré côté Grafana (son fichier de configuration OIDC), pas par la Console.
 - La Console crée et maintient, **sous le groupe racine `/<slug>`**, le sous-groupe `grafana` et ses sous-groupes `hprod-RO/RW` et `prod-RO/RW`.
 
----
-
 ## 2. Groupes Keycloak et rôle Grafana résultant
 
 | Groupe Keycloak              | Rôle Grafana (mapping OIDC) | Portée                     |
@@ -45,22 +39,16 @@ Ce que chaque rôle Console obtient réellement dans Grafana (scopé par environ
 | `/<slug>/grafana/prod-RW`              | **Editor** (prod)           | Projet `<slug>`, prod      |
 | `/<slug>/grafana/prod-RO`              | **Viewer** (prod)           | Projet `<slug>`, prod      |
 
----
-
 ## 3. Points d'attention
 
 - **Scoping prod / hors-prod.** Un utilisateur avec droits sur un environnement `prod` est ajouté aux sous-groupes `prod-*` ; sinon aux `hprod-*` (hors-prod). Les deux peuvent coexister.
 - **RW vs RO.** `RW` ⇔ capacité `MANAGE_ENVIRONMENTS` (édition) ; `RO` ⇔ `LIST_ENVIRONMENTS` (visualisation). Le propriétaire du projet est toujours RW.
 - **Le rôle Grafana réel est défini par la config OIDC de Grafana**, pas par la Console. La Console se contente de maintenir l'arborescence de groupes Keycloak.
 
----
-
 ## 4. Qui gère quoi ?
 
 | Élément                              | Géré par                  |
 | ------------------------------------ | ------------------------- |
 | Identité OIDC / groupes Keycloak     | **Keycloak**              |
 | Arborescence des groupes `grafana/*` | **Console** (automatique) |
 | Mapping groupe → rôle Grafana        | **Grafana** (config OIDC) |
-
----
diff --git a/docs/guide/rbac/harbor.md b/docs/guide/rbac/harbor.md
@@ -2,8 +2,6 @@
 
 Ce document décrit comment la Console propage les **groupes Keycloak** en **rôles Harbor** (membres d'un projet Harbor), et quels droits en résultent.
 
----
-
 ## Vue par rôle
 
 Ce que chaque rôle Console obtient réellement dans Harbor. Les chemins `/console/<rôle>` sont **réservés à l'administration plateforme** et distincts des rôles projet `/<slug>/console/<rôle>` :
@@ -20,15 +18,11 @@ Ce que chaque rôle Console obtient réellement dans Harbor. Les chemins `/conso
 | Security              | `/console/security`         | **Guest** sur **tous** les projets (lecture transverse) |
 | Guest                 | —                           | Aucun accès                                             |
 
----
-
 ## 1. Authentification : Harbor via OIDC Keycloak
 
 - Harbor est fédéré au fournisseur OIDC Keycloak ; les utilisateurs se connectent sans mot de passe local.
 - La Console approvisionne, pour chaque projet, le **projet Harbor** et y ajoute les groupes Keycloak comme **membres** avec un rôle (Admin / Developer / Guest).
 
----
-
 ## 2. Groupes Keycloak et rôle Harbor résultant
 
 La Console mappe chaque groupe OIDC vers un **rôle Harbor** et une **portée** (projet ou global).
@@ -46,21 +40,15 @@ La Console mappe chaque groupe OIDC vers un **rôle Harbor** et une **portée**
 
 > Le groupe racine du projet (`/<slug>`) est ajouté en tant que membre avec un niveau **Limited Guest** (lecture seule : pull d'images sans administration) pour l'ensemble de ses membres.
 
----
-
 ## 3. Points d'attention
 
 - **Seul `/<slug>/console/admin` pousse des images.** Tous les autres rôles projet (`devops`, `developer`, `security`, `reader`) sont en **Guest** (pull/lecture uniquement).
 - **Groupes `security`/`reader` = Guest transverse.** Ils sont ajoutés en Guest sur **tous** les projets Harbor (portée plateforme), ce qui donne une lecture globale des registres.
 
----
-
 ## 4. Qui gère quoi ?
 
 | Élément                          | Géré par                  |
 | -------------------------------- | ------------------------- |
 | Identité OIDC / groupes Keycloak | **Keycloak**              |
 | Projets Harbor, membres & rôles  | **Console** (automatique) |
 | Application des droits           | **Harbor**                |
-
----
diff --git a/docs/guide/rbac/keycloak.md b/docs/guide/rbac/keycloak.md
@@ -2,8 +2,6 @@
 
 Ce document décrit le **modèle d'accès** de l'IdP central du socle : Keycloak. Keycloak est la **source de vérité** de l'identité et de la hiérarchie de groupes qui est propagée vers tous les autres outils de la chaîne DSO.
 
----
-
 ## Vue par rôle
 
 En tant qu'IdP, Keycloak ne « donne » pas d'écran de droits : il place chaque rôle dans un groupe, et c'est ce groupe qui propage les droits en aval. Les chemins `/console/<rôle>` sont **réservés à l'administration plateforme** et distincts des rôles projet `/<slug>/console/<rôle>`. Conséquence par rôle :
@@ -21,15 +19,11 @@ En tant qu'IdP, Keycloak ne « donne » pas d'écran de droits : il place chaque
 | Security              | `/console/security`         | Audit/lecture transverse plateforme          |
 | Guest                 | —                           | Aucun droit jusqu'à ajout manuel à un projet |
 
----
-
 ## 1. Authentification OIDC
 
 - Keycloak est le fournisseur d'identité (IdP) ; tous les outils DSO fédèrent dessus en OIDC.
 - Les utilisateurs proviennent d'un IdP externe (ex. Passage2 / ProConnect) ou sont locaux. Les **rôles admin Console** sont liés à des groupes Keycloak existants via `oidcGroup`.
 
----
-
 ## 2. Hiérarchie de groupes maintenue par la Console
 
 La Console crée et réconcilie automatiquement l'arborescence suivante, propagée vers les outils consommateurs :
@@ -51,23 +45,17 @@ La Console crée et réconcilie automatiquement l'arborescence suivante, propag
 
 > ℹ️ Les **rôles projet Console** (`Administrateur`, `DevOps`, `Développeur`, `Lecture seule`) sont systématiquement créés avec le projet et liés aux groupes `/<slug>/console/{admin,devops,developer,reader}`. Le groupe `/<slug>/console/security` n'existe pas par défaut : il n'est alimenté que si un outil (ou un admin) le référence. Les rôles admin (`AdminRole`) sont les **seuls** pouvant être liés à un groupe Keycloak **existant** via `oidcGroup` (le préfixe `/` est obligatoire).
 
----
-
 ## 3. Points d'attention
 
 - **`/admin` est le seul groupe plateforme admin.** Groupe d'amorçage géré en dehors de la Console ; il ne porte des droits que sur la Console CPiN (aucune propagation vers les outils).
 - **Groupes environnement vs groupes projet.** ArgoCD et Grafana s'appuient sur des sous-groupes **environment-scoped** (`<env>/RO|RW`, `grafana/<hprod|prod>-RO|RW`). Les autres outils s'appuient sur les groupes **projet-role** (`/<slug>/console/{admin,devops,developer,reader,security}`).
 - **Security / Reader sont des portées de lecture/audit**, jamais d'écriture, sur la plupart des outils.
 - **Utilisateurs tiers (IDP externe).** Aucun groupe par défaut n'est attribué ; ils n'ont aucun droit tant qu'un membre les ajoute à un projet avec le niveau adéquat.
 
----
-
 ## 4. Qui gère quoi ?
 
 | Élément                                   | Géré par                                         |
 | ----------------------------------------- | ------------------------------------------------ |
 | Fournisseur d'identité / realm            | **Keycloak** (socle)                             |
 | Hiérarchie de groupes projet/admin        | **Console** (automatique)                        |
 | Appartenance des utilisateurs aux groupes | **Console** (selon rôles/membres) + **Keycloak** |
-
----
diff --git a/docs/guide/rbac/nexus.md b/docs/guide/rbac/nexus.md
@@ -2,8 +2,6 @@
 
 Ce document décrit le **modèle d'accès** mis en place dans Nexus pour chaque projet DSO : qui peut publier ou télécharger des artefacts, et comment les rôles sont synchronisés depuis les groupes Keycloak.
 
----
-
 ## Vue par rôle
 
 Ce que chaque rôle Console obtient réellement dans Nexus. Les chemins `/console/<rôle>` sont **réservés à l'administration plateforme** et distincts des rôles projet `/<slug>/console/<rôle>` :
@@ -20,15 +18,11 @@ Ce que chaque rôle Console obtient réellement dans Nexus. Les chemins `/consol
 | Security              | `/console/security`         | Lecture de tous les dépôts (plateforme)         |
 | Guest                 | —                           | Aucun accès                                     |
 
----
-
 ## 1. Authentification : Nexus via OIDC Keycloak
 
 - Les utilisateurs se connectent à Nexus via **OIDC** (Keycloak).
 - La Console approvisionne, pour chaque projet, un **rôle de sécurité** (`<name>-ID` / `<name>-role`) et y rattache les groupes OIDC comme membres avec des _privileges_ de lecture ou d'écriture.
 
----
-
 ## 2. Groupes Keycloak et portée Nexus
 
 La Console répartit les chemins de groupes OIDC en deux ensembles : **écriture** (publish/deploy) et **lecture** (download/browse).
@@ -44,20 +38,14 @@ La Console répartit les chemins de groupes OIDC en deux ensembles : **écriture
 | `/<slug>/console/security`         | **Lecture**                              | Dépôt du projet `<name>`       |
 | `/<slug>/console/readonly`         | **Lecture** (packages)                   | Dépôt du projet `<name>`       |
 
----
-
 ## 3. Points d'attention
 
 - **DevOps = déployer, Developer = télécharger.** Les groupes `admin`/`devops` projet écrivent (publish artefacts, deploy) ; `developer`/`security`/`readonly` ne font que lire/télécharger.
 - **Rôles agrégés par projet Nexus.** Le rôle `<name>-ID` agrège les privilèges de tous les projets Nexus activés ; un groupe OIDC est rattaché à ce rôle avec le bon niveau (read/write).
 
----
-
 ## 4. Qui gère quoi ?
 
 | Élément                          | Géré par                  |
 | -------------------------------- | ------------------------- |
 | Identité OIDC / groupes Keycloak | **Keycloak**              |
 | Rôles & privilèges Nexus         | **Console** (automatique) |
-
----
diff --git a/docs/guide/rbac/sonarqube.md b/docs/guide/rbac/sonarqube.md
@@ -2,8 +2,6 @@
 
 Ce document décrit le **modèle d'accès** mis en place dans SonarQube pour chaque projet DSO : qui accède à l'analyse, avec quelles permissions, et comment les rôles sont synchronisés depuis les groupes Keycloak.
 
----
-
 ## Vue par rôle
 
 Ce que chaque rôle Console obtient réellement dans SonarQube. Les chemins `/console/<rôle>` sont **réservés à l'administration plateforme** et distincts des rôles projet `/<slug>/console/<rôle>` :
@@ -20,15 +18,11 @@ Ce que chaque rôle Console obtient réellement dans SonarQube. Les chemins `/co
 | Security              | `/console/security`                | identique DevOps (tous projets)                                              |
 | Guest                 | —                                  | Aucun accès                                                                  |
 
----
-
 ## 1. Authentification : SonarQube via OIDC Keycloak
 
 - Les utilisateurs se connectent à SonarQube via **OIDC** (Keycloak). Aucun compte/mot de passe local à gérer.
 - La Console approvisionne, pour chaque projet, un **groupe Sonar** et lui applique un **modèle de permissions** (permission template) déduit des groupes OIDC.
 
----
-
 ## 2. Groupes Keycloak et permissions SonarQube
 
 La Console mappe chaque groupe OIDC vers un ensemble de **permissions projet SonarQube**.
@@ -45,20 +39,14 @@ La Console mappe chaque groupe OIDC vers un ensemble de **permissions projet Son
 
 > **Égalité devops = developer = security.** Sur un projet, les trois rôles `devops`, `developer` et `security` reçoivent **exactement les mêmes permissions** (`scan`, `user`, `codeviewer`, `issueadmin`, `securityhotspotadmin`). Seul `admin` ajoute `admin`. `reader` se limite à `user` + `codeviewer`.
 
----
-
 ## 3. Points d'attention
 
 - **Developer et Security ne sont pas en lecture seule.** Contrairement à Vault, ils disposent de `scan` (exécution d'analyse) et de `issueadmin`/`securityhotspotadmin` (traitement des tickets de sécurité).
 
----
-
 ## 4. Qui gère quoi ?
 
 | Élément                               | Géré par                  |
 | ------------------------------------- | ------------------------- |
 | Identité OIDC / groupes Keycloak      | **Keycloak**              |
 | Groupes Sonar, permissions, templates | **Console** (automatique) |
 | Application des droits                | **SonarQube**             |
-
----
diff --git a/docs/guide/rbac/vault.md b/docs/guide/rbac/vault.md
@@ -2,8 +2,6 @@
 
 Ce document décrit le **modèle d'accès** mis en place dans Vault pour chaque projet DSO : qui peut lire/écrire quels secrets, et comment ces droits sont synchronisés depuis les groupes Keycloak.
 
----
-
 ## Vue par rôle
 
 Ce que chaque rôle Console obtient réellement dans Vault. Les chemins `/console/<rôle>` sont **réservés à l'administration plateforme** et distincts des rôles projet `/<slug>/console/<rôle>` :
@@ -20,16 +18,12 @@ Ce que chaque rôle Console obtient réellement dans Vault. Les chemins `/consol
 | Security              | `/console/security`         | Audit & posture plateforme : `sys/audit`, `sys/policies`, `<name>/metadata`, jamais le contenu |
 | Guest                 | —                           | Aucun accès Vault                                                                              |
 
----
-
 ## 1. Authentification : Vault via OIDC Keycloak
 
 - Vault expose une méthode d'auth **OIDC** (`oidc/`) dont le fournisseur d'identité est Keycloak.
 - La Console crée, pour chaque projet, un **mount KV v2** nommé d'après le slug du projet (`<name>`), ainsi que les _policies_ et les **groupes d'identité externes** (type `external`) dont l'alias pointe vers le groupe OIDC Keycloak correspondant.
 - Les applications consomment leurs secrets via un **AppRole** projet (`role-id` / `secret-id`) rattaché aux _policies_ techniques (`tech--<name>--ro` + `app--<name>--admin`), jamais via OIDC.
 
----
-
 ## 2. Groupes Keycloak et _policies_ associées
 
 La Console génère, pour chaque projet, les groupes d'identité Vault suivants (nom canonique `project-<name>-<scope>`), chacun lié à une _policy_ et à un alias OIDC.
@@ -47,17 +41,13 @@ La Console génère, pour chaque projet, les groupes d'identité Vault suivants
 
 > Un projet possède également un rôle AppRole technique (`<name>`) pour les robots CI, rattaché aux _policies_ `tech--<name>--ro` (lecture d'un secret de registre dédié) et `app--<name>--admin`.
 
----
-
 ## 3. Points d'attention
 
 - **Développeur = liste seule.** Le rôle `developer` ne dispose que de la capacité `list` sur `<name>/data/*` : il ne peut ni lire ni écrire le contenu d'un secret.
 - **Security = audit, pas données.** Les groupes `security` (plateforme et projet) n'ont accès qu'aux _métadonnées_ et à la posture (`sys/audit`, `<name>/metadata`, `transit/keys`) ; jamais au contenu (`<name>/data`).
 - **Admin projet ≠ admin plateforme.** `/<slug>/console/admin` est confiné au mount `<name>/*` ; seul le groupe `/console/admin` obtient `sys/*`.
 - **Noms canoniques.** le chemin Keycloak réel créé par la Console dépend de la configuration déployée.
 
----
-
 ## 4. Qui gère quoi ?
 
 | Élément                                         | Géré par                              |
@@ -66,5 +56,3 @@ La Console génère, pour chaque projet, les groupes d'identité Vault suivants
 | Mounts, _policies_, groupes d'identité, AppRole | **Console** (automatique)             |
 
 > Pour donner accès à un utilisateur, on l'ajoute au rôle/groupe adéquat côté Console / OIDC ; la Console répercute la _policy_ dans Vault.
-
----