Files
decision/docs/content/user/7.sanctuary.md
Yvv 403b94fa2c Sprint 5 : integration et production -- securite, performance, API publique, documentation
Backend: rate limiter, security headers, blockchain cache service avec RPC,
public API (7 endpoints read-only), WebSocket auth + heartbeat, DB connection
pooling, structured logging, health check DB. Frontend: API retry/timeout,
WebSocket auth + heartbeat + typed events, notifications toast, mobile hamburger
+ drawer, error boundary, offline banner, loading skeletons, dashboard enrichi.
Documentation: guides utilisateur complets (demarrage, vote, sanctuaire, FAQ 30+),
guide deploiement, politique securite. 123 tests, 155 fichiers.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-28 15:12:50 +01:00

205 lines
8.9 KiB
Markdown

---
title: Sanctuaire
description: Guide de l'archivage immuable sur Glibredecision
---
# Sanctuaire
## Qu'est-ce que le Sanctuaire ?
Le Sanctuaire est la couche d'**archivage immuable** de Glibredecision. C'est l'endroit ou les decisions adoptees, les documents archives et les resultats de vote sont preserves de maniere permanente et verifiable.
Le principe est simple : une fois qu'un contenu entre dans le Sanctuaire, il ne peut plus etre modifie ni supprime. Meme si la plateforme Glibredecision disparaissait, les preuves resteraient accessibles et verifiables de maniere independante.
## Triple preuve : SHA-256 + IPFS + Blockchain
Le Sanctuaire repose sur trois mecanismes complementaires qui forment une **triple preuve** d'integrite :
### 1. Hash SHA-256 -- Preuve d'integrite
Un hash SHA-256 est un empreinte numerique unique du contenu. Si ne serait-ce qu'un seul caractere du document change, le hash est completement different. En recalculant le hash et en le comparant a celui enregistre, on peut verifier que le contenu n'a pas ete modifie.
**Analogie** : C'est comme une empreinte digitale. Deux documents differents n'auront jamais la meme empreinte.
### 2. IPFS -- Stockage distribue et contenu adressable
IPFS (InterPlanetary File System) est un reseau de stockage distribue. Le contenu n'est pas stocke sur un seul serveur mais replique sur plusieurs noeuds du reseau. Chaque contenu est identifie par un **CID** (Content Identifier) qui est derive de son contenu meme.
**Analogie** : Au lieu de dire "le document est a l'adresse www.example.com/doc1" (localisation), on dit "le document dont l'empreinte est Qm1234..." (contenu). Peu importe ou il est stocke, tant que l'empreinte correspond, c'est le bon document.
**Avantages** :
- **Resilience** : le contenu reste accessible meme si un serveur tombe.
- **Integritegarantie** : le CID change si le contenu change, toute falsification est detectable.
- **Perennite** : tant qu'au moins un noeud heberge le contenu, il est accessible.
### Acceder au contenu via IPFS
Chaque entree du Sanctuaire possede un **CID IPFS** qui permet d'acceder au contenu :
- **Passerelle publique** : `https://ipfs.io/ipfs/{CID}`
- **Passerelle locale** (si vous executez un noeud kubo) : `http://localhost:8080/ipfs/{CID}`
En cliquant sur le lien CID dans l'interface, le contenu s'ouvre directement dans votre navigateur.
Si vous avez un noeud IPFS local (kubo), vous pouvez aussi utiliser la ligne de commande :
```bash
# Afficher le contenu
ipfs cat {CID}
# Telecharger le contenu
ipfs get {CID} -o document_archive.txt
```
### 3. Ancrage on-chain -- Preuve horodatee et infalsifiable
L'ancrage on-chain consiste a enregistrer le hash SHA-256 du contenu sur la blockchain Duniter V2, via un appel `system.remark`. Cette transaction est incluse dans un bloc de la blockchain, ce qui fournit :
- **Horodatage** : la date du bloc prouve que le contenu existait a cette date.
- **Immutabilite** : une fois inscrit dans la blockchain, le remark ne peut pas etre modifie.
- **Independance** : la preuve est verifiable sur la blockchain, independamment de Glibredecision.
Le format du remark est :
```
glibredecision:sanctuary:{hash_sha256_du_contenu}
```
**Analogie** : C'est comme publier un hash dans un journal date et immuable. N'importe qui peut verifier que le hash etait bien la a cette date.
## Pourquoi le Sanctuaire ?
La gouvernance exige la transparence et la tracabilite. Le Sanctuaire garantit que :
- **Aucune decision adoptee ne peut etre modifiee retroactivement** : le hash et l'ancrage on-chain rendent toute falsification detectable.
- **Tout membre peut verifier l'authenticite** d'un document ou d'un resultat de vote de maniere independante.
- **L'historique des decisions est preserve** independamment de la plateforme : meme sans Glibredecision, les preuves restent sur IPFS et la blockchain.
## Types d'entrees
| Type | Description |
| ------------ | ------------------------------------------------ |
| Document | Version adoptee d'un document de reference |
| Decision | Decision finalisee avec son resultat |
| Vote result | Resultat detaille d'une session de vote |
## Consulter le Sanctuaire
1. Rendez-vous dans la section **Sanctuaire**.
2. Filtrez par type d'entree si necessaire.
3. Chaque entree affiche :
- Le titre
- Le hash SHA-256 du contenu
- Le CID IPFS (lien vers le contenu sur IPFS)
- Le hash de la transaction on-chain
- Le numero de bloc
- La date d'archivage
## Consulter les entrees par document de reference
Pour retrouver toutes les entrees du Sanctuaire liees a un document, une decision ou une session de vote specifique :
1. Depuis la fiche du document (ou de la decision), cliquez sur **Voir dans le Sanctuaire**.
2. La liste affiche toutes les entrees archivees associees a cette entite source.
3. Vous pouvez aussi acceder directement a cette vue via l'URL : `/sanctuaire/par-reference/{id}`.
Cette fonctionnalite permet de retracer l'historique complet d'archivage d'un document au fil de ses modifications adoptees.
## Comment verifier une archive
### Verification automatique
Glibredecision propose une verification automatique d'integrite pour chaque entree du Sanctuaire :
1. Ouvrez l'entree a verifier dans le Sanctuaire.
2. Cliquez sur **Verifier l'integrite**.
3. Le systeme effectue automatiquement trois controles :
- **Hash SHA-256** : le hash est recalcule a partir du contenu source et compare avec le hash enregistre.
- **IPFS** : le contenu est recupere via le CID IPFS et verifie (si le CID est renseigne).
- **On-chain** : le hash est recherche dans le `system.remark` du bloc reference sur la blockchain Duniter V2 (si le hash de transaction est renseigne).
4. Le resultat affiche pour chaque controle un indicateur **valide** ou **invalide**.
::callout{type="info"}
Si les trois controles sont valides, le contenu est authentique et n'a pas ete modifie depuis son archivage.
::
### Verification manuelle (independante de la plateforme)
Pour une verification totalement independante de Glibredecision, suivez ces etapes :
#### Etape 1 : Recuperer le contenu via IPFS
Utilisez le CID affiche sur l'entree du Sanctuaire pour telecharger le contenu :
```bash
# Via un noeud IPFS local
ipfs cat QmXyz... > document.txt
# Via une passerelle publique
curl https://ipfs.io/ipfs/QmXyz... > document.txt
```
#### Etape 2 : Calculer le hash SHA-256
```bash
sha256sum document.txt
```
Comparez le hash obtenu avec le hash affiche dans le Sanctuaire. Ils doivent etre identiques.
#### Etape 3 : Verifier l'ancrage on-chain
1. Copiez le **hash de transaction** affiche sur l'entree du Sanctuaire.
2. Ouvrez un explorateur de la blockchain Duniter V2 (par exemple Polkadot.js Apps connecte au reseau Duniter).
3. Recherchez la transaction par son hash ou parcourez le **bloc** indique.
4. Dans les extrinsics du bloc, reperez l'appel `system.remark` contenant le hash SHA-256.
5. Verifiez que le hash dans le remark correspond a celui que vous avez calcule.
#### Resultat
Si les trois hash correspondent (calcul local, Sanctuaire, on-chain), le contenu est authentique, integre et horodate. La triple preuve est confirmee.
::callout{type="tip"}
L'ancrage on-chain fournit une preuve horodatee et infalsifiable de l'existence du contenu a la date du bloc. Meme si la plateforme Glibredecision disparait, la preuve reste verifiable sur la blockchain.
::
## Comprendre les informations d'ancrage on-chain
Chaque entree du Sanctuaire affiche des informations relatives a son ancrage sur la blockchain Duniter V2 :
| Information | Description |
| -------------------- | -------------------------------------------------------- |
| Hash de transaction | Identifiant unique de la transaction `system.remark` contenant le hash du contenu |
| Numero de bloc | Le bloc de la blockchain dans lequel la transaction a ete incluse |
| Date d'archivage | Horodatage de la creation de l'entree dans le Sanctuaire |
## Automatisation
L'archivage dans le Sanctuaire est declenche automatiquement lorsqu'un processus decisionnel est finalise :
- Quand une version d'item de document est **acceptee**, le nouveau texte est archive.
- Quand une session de vote est **cloturee**, le resultat detaille est archive.
- Quand une decision est **executee**, l'ensemble de la decision est archive.
- Quand un document est **archive** via le bouton d'archivage, l'integralite du document est archivee dans le Sanctuaire.
## Resume : la chaine de confiance
```
Contenu adopte
|
v
[Calcul SHA-256] --> hash = empreinte unique du contenu
|
+---> [Upload IPFS] --> CID = identifiant distribue du contenu
|
+---> [system.remark on-chain] --> preuve horodatee et immuable
|
v
[Entree Sanctuaire] = hash + CID + tx_hash + block_number
|
v
Verification : recalculer le hash, comparer avec IPFS et on-chain
= Triple preuve d'integrite
```