Eric / documentation

rm unnecessary file

EBO <eric.bouhana@softalys.com> committé le 2026-04-17 17:13

00e3694d8608f304c055f8d40bcd2043ebb89492

1 parent(s)

2 fichiers modifiés +0 -663

D .plans/001-scaffold-initial.md

+0 -582

@@ -1,582 +0,0 @@

1		-# Plan — Documentation officielle gitrust (girust_doc)
2		-
3		-## Contexte
4		-
5		-Le dépôt `/home/monsieurb/Documents/devel/girust_doc` est actuellement vide (3 dossiers `administration_manual/`, `user_manual/`, `template/` + un README de 9 lignes). Il doit héberger la documentation officielle publique de la plateforme gitrust (forge Git self-hosted en Rust, similaire à Gitea, déployée sur `demo.gitrust.eu`).
6		-
7		-La plateforme cible (explorée dans `/home/monsieurb/Documents/devel/gitrust`) est un monorepo Rust à 6 crates (rustwarden-core, gitrust-core, gitrust-git, gitrust-web, gitrust-ssh, gitrust-hooks), fournit un serveur HTTP (:4000) + SSH (:2222), PostgreSQL, CI Dagger intégrée, SBOM + Dependency-Track, i18n (6 langues : fr, en, de, es, pt, it), et vise l'auto-hébergement pour équipes de 3-20 personnes avec conformité ANSSI PA-074.
8		-
9		-Cette documentation doit être :
10		-- Multilingue : fr, en, de, es, pt, it (aligné avec les langues de l'UI gitrust)
11		-- Structurée selon Diátaxis : Tutorials / How-to / Reference / Explanation
12		-- Publiée via mdBook (natif Rust, cohérent avec la stack), Markdown brut lisible sans build
13		-- Riche en diagrammes Mermaid et en exemples réutilisables (configs, CI, code)
14		-
15		-## Objectif
16		-
17		-Scaffolder un dépôt documentaire complet, prêt à être rempli de contenu, avec :
18		-1. Une structure mdBook multilingue (6 langues) sur base FR → EN → autres
19		-2. Quatre manuels organisés selon Diátaxis :
20		- - `user_manual/` — utilisateurs finaux
21		- - `administration_manual/` — ops / self-hosters
22		- - `developer_manual/` — contributeurs core + utilisateurs API (nouveau)
23		- - `template/` — exemples copiables (hors Diátaxis par nature)
24		-3. Une bibliothèque de templates de configuration réutilisables
25		-4. Les outils d'automatisation (CI de build, lint Markdown, validation Mermaid)
26		-5. Réutilisation maximale du contenu existant de `gitrust/docs/` — 9 fichiers publiables quasi tels quels, 8 fichiers à extraire partiellement (voir § Manuel développeur)
27		-
28		-## Objectifs par manuel
29		-
30		-Chaque manuel a un public distinct, un objectif propre, et un périmètre explicitement délimité. Le respect strict de ces périmètres garantit qu'un lecteur trouve ce qu'il cherche sans traverser du contenu qui ne le concerne pas.
31		-
32		-### `user_manual/` — Manuel utilisateur
33		-
34		-- Public : utilisateurs finaux de gitrust (développeurs qui utilisent la forge : push/pull, code review, issues, notifications).
35		-- Objectif : rendre autonome quelqu'un qui se connecte à une instance gitrust existante pour collaborer sur du code.
36		-- Couvre : inscription, 2FA, gestion des clés SSH, création/clonage/push de dépôts, pull requests et stratégies de merge, issues et labels hiérarchiques, équipes et permissions, notifications, personal access tokens, usage de la CI intégrée (`.gitrust-ci.yml`), lecture du SBOM.
37		-- Ne couvre pas : l'installation de la plateforme, l'administration multi-utilisateurs, le code source gitrust, l'API programmatique avancée.
38		-- Prérequis lecteur : savoir utiliser Git en ligne de commande.
39		-
40		-### `administration_manual/` — Manuel d'administration
41		-
42		-- Public : ops et self-hosters qui déploient, configurent et maintiennent une instance gitrust en production.
43		-- Objectif : installer, exploiter et superviser une instance, depuis le premier démarrage jusqu'à la mise à jour et la restauration après incident.
44		-- Couvre : installation Docker / systemd, reverse-proxy TLS (Nginx/Caddy/Traefik), configuration SMTP et OAuth, CI runner distant, intégration Dependency-Track et Syft (SBOM), durcissement Fail2ban, tuning rate limiting, forçage 2FA global, sauvegarde/restauration (PostgreSQL + dépôts bare + clés SSH), procédure de mise à jour, dépannage SSH/CI, administration via `/admin`, conformité ANSSI PA-074.
45		-- Ne couvre pas : l'utilisation quotidienne par un développeur, la contribution au code source, le développement de clients API.
46		-- Prérequis lecteur : administration Linux, notions de réseau et TLS.
47		-
48		-### `developer_manual/` — Manuel développeur
49		-
50		-- Public : double — (a) contributeurs au code gitrust (core ou via fork rustwarden), (b) développeurs externes qui construisent des intégrations sur l'API publique.
51		-- Objectif : fournir tout le nécessaire pour comprendre l'architecture, contribuer du code conforme aux standards du projet, ou bâtir un client qui parle à l'API gitrust.
52		-- Couvre : architecture des 6 crates (rustwarden-core, gitrust-core, gitrust-git, gitrust-web, gitrust-ssh, gitrust-hooks), schéma de la base de données et ERD, modèle RBAC 4 niveaux, diagrammes de séquence (auth SSH, push, merge PR, import repo), patrons de contribution (ajouter une route, un service, une migration, un worker async), stratégie de tests unitaires et E2E (Playwright), règles QA et gates ANSSI, workflow de PR et contribution upstream rustwarden, référence complète de l'API REST v1 (auth, pagination, codes erreur, exemples de clients), fonctionnement interne de features (2FA, labels hiérarchiques, CI Dagger Easy vs Power Mode, décisions UI HTMX).
53		-- Ne couvre pas : l'installation d'une instance de production, l'usage utilisateur de la forge.
54		-- Prérequis lecteur : Rust (pour contribuer) ou un langage client (pour l'API) ; familiarité avec HTTP, Git, PostgreSQL.
55		-
56		-### `template/` — Bibliothèque d'exemples copiables
57		-
58		-- Public : tous les profils précédents, chaque fois qu'ils cherchent un point de départ prêt à l'emploi pour une config ou un script.
59		-- Objectif : fournir des fichiers standalone, copiables tels quels, couvrant les cas d'usage concrets rencontrés par les 3 autres manuels. Un fichier = un cas d'usage, nom explicite, commentaires internes suffisants, mais pas de prose explicative autour.
60		-- Couvre : fichiers `.env` par profil (dev local, production mono-machine, production CI-heavy, tests E2E), variantes `docker-compose.yml` (minimal, production avec Redis+SMTP, avec CI runner), reverse-proxy (Nginx TLS, Caddyfile, Traefik dynamique), unit systemd avec hardening AppArmor/seccomp + timer de sauvegarde, `.gitrust-ci.yml` par langage (Rust, Go, Python, Node) + squelette Dagger Power Mode, scripts de backup/restore, clients API d'exemple (Python, Rust, curl+PAT), scripts de migration depuis Gitea et Forgejo, alternative Podman Quadlet.
61		-- Particularité : hors cadre Diátaxis par nature — c'est un atelier, pas un texte pédagogique. L'unique fichier de prose est `template/index.md` qui sert de catalogue. Les manuels Diátaxis pointent vers ces templates depuis leurs how-to (ex. `administration_manual/how-to/configurer-smtp.md` → « copiez `template/env/production-mono-machine.env` puis... »).
62		-- Ne couvre pas : toute explication pédagogique (cela appartient aux 3 manuels).
63		-
64		-### Relations entre les 4 parties
65		-
66		-```mermaid
67		-graph LR
68		- U[user_manual] --> API[developer_manual/reference/api]
69		- U --> T[template/api-clients/]
70		- A[admin_manual] --> T
71		- D[developer_manual] --> T
72		- T -. référencé depuis .-> U
73		- T -. référencé depuis .-> A
74		- T -. référencé depuis .-> D
75		-```
76		-
77		-- Chaque manuel narratif (U/A/D) est lisible seul.
78		-- `template/` est la boîte à outils commune — les trois manuels y pointent depuis leurs how-to sans jamais dupliquer le contenu du template dans la prose.
79		-- Pas de dépendance circulaire : `template/` ne pointe jamais vers les manuels ; `user_manual` ne référence jamais `administration_manual` (publics distincts).
80		-
81		-## Principes directeurs
82		-
83		-- FR comme langue source (aligné avec le projet gitrust french-first) ; les autres langues sont des traductions dérivées via `mdbook-i18n-helpers` (patterns `po/xx.po`) — le même workflow que `rust-lang/book`.
84		-- Diátaxis par manuel : chaque manuel (user / admin) contient ses propres `tutorials/`, `how-to/`, `reference/`, `explanation/`.
85		-- Les templates sont du code/config copiable, pas de la prose : un fichier = un cas d'usage.
86		-- Mermaid partout où une séquence, un flux ou une topologie clarifie plus que 10 lignes de texte.
87		-- Documentation autonome : la doc est déconnectée des sources gitrust. Tout exemple (config, extrait de code, schéma, diagramme) est copié dans la doc, jamais référencé par lien local ni par chemin relatif sortant de `girust_doc/`. Un lecteur sur `demo.gitrust.eu` doit pouvoir tout trouver sans checkout du repo. Seule exception : lien HTTP vers le dépôt public (pour pointer vers le code de référence), mais le contenu reste dans la doc. Quand gitrust évolue, sync manuelle documentée dans `CONTRIBUTING.md`.
88		-- Exigence pédagogique : Diátaxis répond à « où placer le contenu », la pédagogie répond à « comment le contenu fait apprendre ». Les deux s'appliquent ensemble dans `tutorials/` et `explanation/` (voir § Principes pédagogiques).
89		-
90		-## Principes pédagogiques (tutorials + explanation)
91		-
92		-Les tutoriels et explanations doivent construire une compétence chez le lecteur, pas seulement l'informer. Quatre leviers sont imposés :
93		-
94		-### 1. Objectifs d'apprentissage mesurables (Bloom)
95		-
96		-Chaque tutoriel déclare en tête ses objectifs en verbes observables (lister, exécuter, configurer, diagnostiquer, comparer, concevoir). Interdits : comprendre, maîtriser, savoir, connaître, se familiariser avec.
97		-
98		-```markdown
99		-## Objectifs
100		-À la fin de ce tutoriel, vous saurez :
101		-- O1. [verbe Bloom] [objet concret]
102		-- O2. [verbe Bloom] [objet concret]
103		-- O3. [verbe Bloom] [objet concret]
104		-```
105		-
106		-Tutoriels débutants : Bloom niveaux 1-3 (mémoriser, comprendre, appliquer). Explanations : Bloom 2, 4, 5 (comprendre, analyser, évaluer).
107		-
108		-### 2. Charge cognitive maîtrisée (Sweller)
109		-
110		-- ≤ 3 concepts nouveaux par tutoriel débutant.
111		-- ≤ 7 étapes séquentielles sans checkpoint récapitulatif.
112		-- Texte et code côte-à-côte (pas de bloc de code sans annotation adjacente).
113		-- Jargon défini à sa première apparition.
114		-- Digressions/options/alternatives déportées en `reference/` (charge extrinsèque).
115		-
116		-### 3. Scaffolding — étayage dégressif entre tutoriels
117		-
118		-Le niveau d'aide recule d'exactement un cran entre deux tutoriels consécutifs :
119		-
120		-\| Niveau \| Nature \| Position dans le parcours \|
121		-\|---\|---\|---\|
122		-\| 1 \| Copier-coller intégral (100 % fourni) \| Tutoriel 01-02 \|
123		-\| 2 \| Compléter un trou (80 % fourni) \| Tutoriel 03-04 \|
124		-\| 3 \| Combiner des recettes existantes (50 %) \| Tutoriel capstone \|
125		-\| 4 \| Résoudre avec recettes dispo (20 %) \| How-to (post-parcours) \|
126		-
127		-Sauter deux crans = décrochage garanti.
128		-
129		-### 4. Feedback formatif — checkpoints observables
130		-
131		-Aucun apprenant n'avance plus de 2 étapes sans feedback observable :
132		-- Sortie console attendue affichée verbatim
133		-- Capture d'écran UI (ou description textuelle du résultat visible)
134		-- Commande de vérification (« pour confirmer, exécutez `git status` — vous devriez voir… »)
135		-- Section « Et si ça ne marche pas » avec les 3 erreurs les plus probables et leur correction
136		-
137		-### 5. Ancrage mental avant la pratique
138		-
139		-Chaque tutoriel et explanation commence par installer le modèle mental avant toute commande :
140		-- Une analogie avec le connu
141		-- Un schéma Mermaid des acteurs et flux
142		-- Un contre-exemple le cas échéant
143		-- Un exemple prototype mémorable
144		-
145		-## Parcours d'apprentissage par persona
146		-
147		-Chaque manuel est un parcours explicite, pas un sac de tutoriels isolés.
148		-
149		-### user_manual — parcours utilisateur (≈ 90 min)
150		-
151		-```mermaid
152		-graph LR
153		- A[Compte créé] --> B[01-premier-pas<br/>20 min]
154		- B --> C[02-cloner-pousser<br/>25 min]
155		- C --> D[03-collaborer<br/>25 min]
156		- D --> E[04-automatiser-ci<br/>20 min]
157		- E --> F[Utilisateur autonome]
158		-```
159		-
160		-- État initial : a un compte gitrust, Git installé
161		-- État final : pousse du code, ouvre et review des PR, configure une CI
162		-- Scaffolding : 01 = copier-coller intégral → 04 = compose à partir de recettes
163		-
164		-### administration_manual — parcours admin (≈ 3 h)
165		-
166		-```mermaid
167		-graph LR
168		- A[VM prête<br/>Docker installé] --> B[01-installation-docker<br/>30 min]
169		- B --> C[02-installation-systemd<br/>45 min]
170		- C --> D[03-premier-demarrage<br/>20 min]
171		- D --> E[04-mise-en-production<br/>90 min]
172		- E --> F[Admin opérationnel]
173		-```
174		-
175		-- État initial : Linux admin, DNS prêt, TLS compris
176		-- État final : instance prod qui tourne, sauvegardée, monitorée
177		-
178		-### developer_manual — parcours contributeur (≈ 4 h)
179		-
180		-```mermaid
181		-graph LR
182		- A[Utilisateur autonome] --> B[01-getting-started<br/>45 min]
183		- B --> C[02-premiere-contribution<br/>90 min]
184		- C --> D[03-creer-un-worker-async<br/>capstone 120 min]
185		- D --> E[Core contributor]
186		-```
187		-
188		-- État initial : Rust ≥ 3 mois, connaît Git/HTTP/PostgreSQL
189		-- État final : capable d'ajouter une feature gitrust de A à Z avec tests
190		-- Capstone : tuto 03 (worker async) consolide sans guide pas-à-pas
191		-
192		-### Checkpoints de parcours
193		-
194		-Entre deux tutoriels, l'`index.md` du manuel affiche un encart : « Vous devriez maintenant savoir faire X avant de passer au suivant — si ce n'est pas le cas, relisez le tutoriel précédent ».
195		-
196		-## Templates pédagogiques imposés
197		-
198		-### Template tutoriel (augmente Diátaxis)
199		-
200		-```markdown
201		-# [Titre promettant une expérience concrète]
202		-
203		-## Objectifs
204		-À la fin de ce tutoriel, vous saurez :
205		-- O1. [verbe Bloom 1-3] [objet concret]
206		-- O2. [verbe Bloom 1-3] [objet concret]
207		-- O3. [verbe Bloom 1-3] [objet concret]
208		-
209		-## Pré-requis
210		-- Technique : [outils/versions installés]
211		-- Pédagogique : tutoriel [précédent] complété
212		-- Temps estimé : ~N minutes
213		-
214		-## Vue d'ensemble
215		-[1 paragraphe + 1 schéma Mermaid qui installe le modèle mental]
216		-
217		-## Étape 1 : [action à l'impératif]
218		-[1-2 phrases de contexte]
219		-
220		-```bash
221		-[commande exacte]
222		-```
223		-
224		-Sortie attendue :
225		-```
226		-[sortie verbatim]
227		-```
228		-
229		-Checkpoint : [vérification observable par l'apprenant]
230		-
231		-## Étape 2 : …
232		-## Étape N : …
233		-
234		-## Récapitulatif
235		-- ✓ O1 accompli en [faisant X]
236		-- ✓ O2 accompli en [faisant Y]
237		-- ✓ O3 accompli en [faisant Z]
238		-
239		-## Et si ça ne marche pas
240		-
241		-\| Symptôme \| Cause probable \| Correction \|
242		-\|---\|---\|---\|
243		-\| `erreur 1` \| … \| … \|
244		-\| `erreur 2` \| … \| … \|
245		-\| `erreur 3` \| … \| … \|
246		-
247		-## Prochaine étape
248		-→ [tutoriel suivant dans le parcours]
249		-```
250		-
251		-### Template explanation
252		-
253		-```markdown
254		-# Comprendre [concept]
255		-
256		-## Ce que vous allez comprendre
257		-- [objectif Bloom niveau 2, 4 ou 5]
258		-
259		-## Le problème concret
260		-[Situation réelle observable]
261		-
262		-## L'analogie
263		-[Rapport au connu : « c'est comme… »]
264		-
265		-## Le modèle
266		-[Schéma Mermaid + 2-3 paragraphes]
267		-
268		-## Alternatives et compromis
269		-[Ce qui aurait pu être choisi, pourquoi pas ici]
270		-
271		-## Vérifier votre compréhension
272		-1. [Question ouverte Bloom 2]
273		-2. [Question ouverte Bloom 4]
274		-
275		-## Pour aller plus loin
276		-- [Reference des détails techniques]
277		-- [How-to qui applique ce concept]
278		-```
279		-
280		-## Arborescence cible
281		-
282		-```
283		-girust_doc/
284		-├── README.md # Présentation + lien vers demo.gitrust.eu
285		-├── book.toml # Config mdBook globale (FR source)
286		-├── theme/ # Thème custom gitrust (logo, couleurs)
287		-├── po/ # Traductions gettext (mdbook-i18n-helpers)
288		-│ ├── en.po # Anglais (prioritaire)
289		-│ ├── de.po es.po pt.po it.po # Autres langues (stubs initiaux)
290		-├── src/ # Source mdBook (FR, canonique)
291		-│ ├── SUMMARY.md # Sommaire global avec 3 manuels
292		-│ ├── introduction.md # Qu'est-ce que gitrust, philosophie, roadmap
293		-│ ├── user_manual/ # → monté depuis ../user_manual/
294		-│ ├── administration_manual/ # → monté depuis ../administration_manual/
295		-│ └── template/ # → monté depuis ../template/
296		-├── user_manual/ # MANUEL UTILISATEUR (Diátaxis)
297		-│ ├── index.md
298		-│ ├── tutorials/ # Apprentissage guidé pas-à-pas
299		-│ │ ├── 01-premier-pas.md # Inscription, 2FA, premier dépôt
300		-│ │ ├── 02-cloner-pousser.md # SSH keys + git clone/push
301		-│ │ ├── 03-collaborer.md # Équipes, issues, pull requests
302		-│ │ └── 04-automatiser-ci.md # Premier .gitrust-ci.yml
303		-│ ├── how-to/ # Recettes orientées tâche
304		-│ │ ├── gerer-cles-ssh.md
305		-│ │ ├── configurer-2fa.md
306		-│ │ ├── creer-personal-access-token.md
307		-│ │ ├── gerer-equipes-permissions.md
308		-│ │ ├── ouvrir-pull-request.md
309		-│ │ ├── fusionner-strategies.md # ff / squash / merge commit
310		-│ │ ├── utiliser-labels-issues.md
311		-│ │ ├── importer-depot-externe.md
312		-│ │ └── consulter-sbom.md
313		-│ ├── reference/
314		-│ │ ├── modele-permissions.md # 4 rôles (Reader/Dev/Maint/Owner)
315		-│ │ ├── api-rest-v1.md # Lien Swagger + auth flow + pagination
316		-│ │ ├── .gitrust-ci-yml-schema.md # Schéma YAML complet Easy Mode
317		-│ │ ├── markdown-et-syntaxe.md # Syntaxe supportée dans README/issues
318		-│ │ └── notifications.md # SSE + email + préférences
319		-│ └── explanation/
320		-│ ├── modele-collaboration.md # Philosophie code review gitrust
321		-│ ├── securite-utilisateur.md # Pourquoi 2FA, hash PAT, audit log
322		-│ └── cycle-vie-pull-request.md # Avec diagramme Mermaid
323		-├── developer_manual/ # MANUEL DÉVELOPPEUR (Diátaxis) — NOUVEAU
324		-│ ├── index.md
325		-│ ├── tutorials/
326		-│ │ ├── 01-getting-started.md # ← gitrust/docs/GETTING_STARTED.md (as-is)
327		-│ │ ├── 02-premiere-contribution.md # Clone, build, test, première PR
328		-│ │ └── 03-creer-un-worker-async.md # TDD pas-à-pas (adapté de plans/import-async-worker.md)
329		-│ ├── how-to/
330		-│ │ ├── contribuer-workflow-pr.md # Workflow Git + review + QA
331		-│ │ ├── lancer-tests-unitaires.md # ← gitrust/docs/TESTING.md (section unitaires)
332		-│ │ ├── lancer-tests-e2e.md # ← gitrust/docs/TESTS_E2E.md (section playwright)
333		-│ │ ├── ajouter-route-web.md # Patron rustwarden → axum handler
334		-│ │ ├── ajouter-service-metier.md # Patron service + injection + tests
335		-│ │ ├── ajouter-migration-db.md # SeaORM, ordre, rollback
336		-│ │ ├── implementer-webhooks.md # ← extrait GUIDE_DEVELOPPEMENT_PHASE5.md (LOT 5.1)
337		-│ │ ├── implementer-endpoint-api.md # ← extrait GUIDE_DEVELOPPEMENT_PHASE5.md (LOT 5.2)
338		-│ │ ├── importer-depot-externe-code.md # ← gitrust/docs/IMPORT_FLOW.md
339		-│ │ ├── contribuer-a-rustwarden.md # ← gitrust/docs/UPSTREAM_RUSTWARDEN.md
340		-│ │ └── passer-la-qa-avant-merge.md # Checklist pre-merge (extrait QA_RULES.md)
341		-│ ├── reference/
342		-│ │ ├── architecture-crates.md # ← gitrust/docs/ARCHITECTURE.md (as-is)
343		-│ │ ├── services-api-interne.md # ← gitrust/docs/SERVICES_REFERENCE.md (à compléter)
344		-│ │ ├── schema-base-donnees.md # ← gitrust/docs/DATABASE.md (ERD + tables)
345		-│ │ ├── regles-qa-anssi.md # ← gitrust/docs/QA_RULES.md (gates, lints, ANSSI)
346		-│ │ ├── api-rest-v1.md # Swagger link + auth + pagination + errors
347		-│ │ ├── git-hooks-post-receive.md # Référence des hooks exposés
348		-│ │ └── rustwarden-core-api.md # Helpers, extracteurs, middleware rustwarden
349		-│ └── explanation/
350		-│ ├── vue-ensemble-architecture.md # ← gitrust/docs/ARCHITECTURE.md (partie narrative)
351		-│ ├── flux-requetes.md # ← gitrust/docs/SEQUENCES.md (diagrammes Mermaid)
352		-│ ├── modele-permissions-rbac.md # 4 rôles × teams × repo scope
353		-│ ├── 2fa-fonctionnement.md # ← extrait CHANGELOG_2FA_EMAIL_LOGIN.md
354		-│ ├── hierarchie-labels.md # ← extrait REALISE_LOT12.md
355		-│ ├── ci-dagger-easy-vs-power.md # ← extrait DAGGER_CI_ANALYSIS.md
356		-│ ├── decisions-ui-htmx.md # ← extrait PLAN_UI_TRANSFORMATION.md
357		-│ └── patron-worker-async.md # ← extrait plans/import-async-worker.md
358		-├── administration_manual/ # MANUEL D'ADMINISTRATION (Diátaxis)
359		-│ ├── index.md
360		-│ ├── tutorials/
361		-│ │ ├── 01-installation-docker.md # Stack docker-compose complète
362		-│ │ ├── 02-installation-systemd.md # Binaire natif + service
363		-│ │ ├── 03-premier-demarrage.md # Admin bootstrap, SSH host key, migrations
364		-│ │ └── 04-mise-en-production-192-168.md # ← plans/deploiement-local-192-168-1-57.md (as-is, généralisé)
365		-│ ├── how-to/
366		-│ │ ├── sauvegarder-restaurer.md # pg_dump + repos bare + SSH keys
367		-│ │ ├── mettre-a-jour.md # Upgrade checklist (migrations auto)
368		-│ │ ├── configurer-smtp.md
369		-│ │ ├── configurer-oauth.md # Google/GitHub providers via rustwarden
370		-│ │ ├── configurer-ci-runner-remote.md # ← gitrust/docs/CI_REMOTE_RUNNER.md
371		-│ │ ├── integrer-dependency-track.md # ← gitrust/docs/CI_AND_DEPENDENCY_TRACKER.md
372		-│ │ ├── durcir-avec-fail2ban.md # ← gitrust/docs/FAIL2BAN_DEPLOYMENT.md (as-is)
373		-│ │ ├── tuner-rate-limiting.md
374		-│ │ ├── forcer-2fa-globalement.md # ← extrait CHANGELOG_FORCE_2FA.md
375		-│ │ ├── depanner-ssh.md # Keys, ports, fingerprints
376		-│ │ ├── depanner-ci.md
377		-│ │ ├── gerer-utilisateurs-admin.md # Panel /admin
378		-│ │ └── auditer-instance.md # Logs journalctl, audit log, métriques
379		-│ ├── reference/
380		-│ │ ├── variables-environnement.md # Index thématique du .env (lien vers .env.example)
381		-│ │ ├── parametres-dynamiques.md # Table app_settings, /admin/settings
382		-│ │ ├── schema-base-de-donnees.md # Résumé + lien vers ../gitrust/docs/DATABASE.md
383		-│ │ ├── ports-et-services.md # 4000 HTTP, 2222 SSH, 5432 PG
384		-│ │ └── conformite-anssi-pa074.md # Checklist QA_RULES appliquée
385		-│ └── explanation/
386		-│ ├── architecture-globale.md # Diagramme composants + flux requête
387		-│ ├── modele-deploiement.md # Mono-machine vs HA, limites
388		-│ ├── ci-dagger.md # Pourquoi Dagger, Easy vs Power Mode
389		-│ └── strategie-sauvegarde.md # Rationale 3-2-1 adapté gitrust
390		-├── template/ # EXEMPLES RÉUTILISABLES (code/config pur)
391		-│ ├── index.md # Index des templates avec cas d'usage
392		-│ ├── env/
393		-│ │ ├── dev-local.env
394		-│ │ ├── production-mono-machine.env
395		-│ │ ├── production-ci-heavy.env
396		-│ │ └── tests-e2e.env
397		-│ ├── docker/
398		-│ │ ├── docker-compose.minimal.yml
399		-│ │ ├── docker-compose.production.yml # + Redis sessions + SMTP
400		-│ │ ├── docker-compose.with-ci-runner.yml
401		-│ │ └── podman-quadlet.container # Alternative Docker
402		-│ ├── reverse-proxy/
403		-│ │ ├── nginx-tls.conf
404		-│ │ ├── caddy-Caddyfile
405		-│ │ └── traefik-dynamic.yml
406		-│ ├── systemd/
407		-│ │ ├── gitrust.service # + hardening AppArmor/seccomp
408		-│ │ └── gitrust-backup.timer
409		-│ ├── ci/
410		-│ │ ├── rust.gitrust-ci.yml
411		-│ │ ├── go.gitrust-ci.yml
412		-│ │ ├── python.gitrust-ci.yml
413		-│ │ ├── node.gitrust-ci.yml
414		-│ │ └── dagger-power-mode/ # Squelette .dagger/
415		-│ │ ├── dagger.json
416		-│ │ └── main.go
417		-│ ├── backup/
418		-│ │ ├── backup.sh # pg_dump + rsync repos
419		-│ │ └── restore.sh
420		-│ ├── api-clients/
421		-│ │ ├── python-create-repo.py
422		-│ │ ├── rust-list-repos.rs
423		-│ │ └── curl-pat-auth.sh
424		-│ └── migration/
425		-│ ├── from-gitea.sh # Import en masse via worker
426		-│ └── from-forgejo.sh
427		-├── diagrams/ # Sources Mermaid partagées
428		-│ ├── architecture-globale.mmd
429		-│ ├── flux-auth-ssh.mmd # (adapté de gitrust/docs/SEQUENCES.md)
430		-│ ├── cycle-vie-pr.mmd
431		-│ ├── pipeline-ci-dagger.mmd
432		-│ └── topologie-deploiement.mmd
433		-├── .github/workflows/ # Ou .gitrust-ci.yml si hébergé sur gitrust
434		-│ └── build-docs.yml # mdBook build + lint + deploy demo.gitrust.eu
435		-├── .markdownlint.yaml # Règles lint (longueur ligne, headings, etc.)
436		-├── CONTRIBUTING.md # Workflow traduction po, conventions FR
437		-├── CLAUDE.md # Directives projet pour Claude Code (voir § Directives projet)
438		-└── .plans/ # Plans de travail (tous plans futurs ici, pas dans ~/.claude/plans/)
439		- └── 001-scaffold-initial.md # Copie/déplacement du présent plan
440		-```
441		-
442		-## Directives projet (CLAUDE.md local)
443		-
444		-Un fichier `CLAUDE.md` est créé à la racine de `girust_doc/` avec au minimum :
445		-
446		-- Plans de travail : tout plan (issu de `/plan`, `ExitPlanMode`, autopilot, etc.) doit être écrit dans `./.plans/` à la racine du projet, jamais dans `~/.claude/plans/`. Numérotation séquentielle `NNN-slug.md`. Les plans restent versionnés avec le dépôt.
447		-- Langue canonique : FR pour les sources, EN prioritaire en traduction.
448		-- Diátaxis strict : aucun nouveau fichier de contenu hors des 4 dossiers `tutorials/`, `how-to/`, `reference/`, `explanation/` de chaque manuel.
449		-- Templates = code pur : pas de prose dans `template/` (sauf `index.md`).
450		-- Mermaid centralisé : sources `.mmd` dans `diagrams/`, référencées depuis les `.md` via include mdBook.
451		-
452		-Ce plan lui-même est copié vers `./.plans/001-scaffold-initial.md` dans le premier commit.
453		-
454		-## Fichiers critiques à créer en priorité (ordre d'exécution)
455		-
456		-1. `CLAUDE.md` racine + `.plans/001-scaffold-initial.md` (copie de ce plan) — avant tout le reste, pour verrouiller la convention.
457		-2. `book.toml` — config mdBook avec `[preprocessor.gettext]`, `[output.html]` thème, `[preprocessor.mermaid]`.
458		-3. `src/SUMMARY.md` — squelette complet de l'arborescence ci-dessus (placeholders).
459		-4. `README.md` racine — présentation du dépôt doc (pas de la plateforme), comment contribuer.
460		-5. `CONTRIBUTING.md` — workflow `po/*.po` pour traduction, conventions nommage, règles Mermaid.
461		-6. 4 `index.md` — `user_manual/`, `administration_manual/`, `developer_manual/`, `template/` avec carte de navigation Diátaxis.
462		-7. Import en bloc des fichiers "or" de `gitrust/docs/` (13 fichiers) vers les destinations listées dans le mapping — copie + ajustement d'en-tête + vérification Diátaxis.
463		-8. 4 tutoriels phares (1 par manuel) pour prouver que le scaffold fonctionne bout en bout :
464		- - `user_manual/tutorials/01-premier-pas.md`
465		- - `administration_manual/tutorials/01-installation-docker.md`
466		- - `developer_manual/tutorials/01-getting-started.md` (import direct)
467		- - `template/env/dev-local.env` + `template/docker/docker-compose.minimal.yml`
468		-9. `diagrams/architecture-globale.mmd` + `flux-requetes.mmd` (extraits des Mermaid existants dans `docs/SEQUENCES.md`).
469		-10. `.markdownlint.yaml` + `.github/workflows/build-docs.yml` — CI de build + lint dès le début.
470		-
471		-## Mapping gitrust/docs → girust_doc (basé sur audit complet, 44 fichiers)
472		-
473		-> Rappel : `girust_doc` est autonome. Toutes les flèches `←` ci-dessous signifient copier le contenu dans le fichier cible, pas un lien. Une fois copié, la doc ne dépend plus du dépôt source.
474		-
475		-### Fichiers "or" — publiables tels quels (copier + adapter en-tête + Diátaxis)
476		-
477		-\| Source (gitrust/) \| Destination (girust_doc/) \| Manuel \| Mode \|
478		-\|---\|---\|---\|---\|
479		-\| `docs/GETTING_STARTED.md` \| `developer_manual/tutorials/01-getting-started.md` \| dev \| tutorial \|
480		-\| `docs/ARCHITECTURE.md` \| `developer_manual/reference/architecture-crates.md` + `developer_manual/explanation/vue-ensemble-architecture.md` (scindé) \| dev \| reference + explanation \|
481		-\| `docs/SEQUENCES.md` \| `developer_manual/explanation/flux-requetes.md` + sources `.mmd` dans `diagrams/` \| dev \| explanation \|
482		-\| `docs/TESTING.md` \| `developer_manual/how-to/lancer-tests-unitaires.md` \| dev \| how-to \|
483		-\| `docs/TESTS_E2E.md` \| `developer_manual/how-to/lancer-tests-e2e.md` \| dev \| how-to \|
484		-\| `docs/QA_RULES.md` \| `developer_manual/reference/regles-qa-anssi.md` \| dev \| reference \|
485		-\| `docs/SETTINGS.md` \| `administration_manual/reference/parametres-dynamiques.md` \| admin \| reference \|
486		-\| `docs/CI_AND_DEPENDENCY_TRACKER.md` \| `administration_manual/how-to/integrer-dependency-track.md` \| admin \| how-to \|
487		-\| `docs/CI_REMOTE_RUNNER.md` \| `administration_manual/how-to/configurer-ci-runner-remote.md` \| admin \| how-to \|
488		-\| `docs/FAIL2BAN_DEPLOYMENT.md` \| `administration_manual/how-to/durcir-avec-fail2ban.md` \| admin \| how-to \|
489		-\| `docs/plans/deploiement-local-192-168-1-57.md` \| `administration_manual/tutorials/04-mise-en-production-192-168.md` (généralisé) \| admin \| tutorial \|
490		-\| `docs/UPSTREAM_RUSTWARDEN.md` \| `developer_manual/how-to/contribuer-a-rustwarden.md` \| dev \| how-to \|
491		-\| `docs/IMPORT_FLOW.md` \| `developer_manual/how-to/importer-depot-externe-code.md` \| dev \| how-to \|
492		-
493		-### Fichiers "mine" — extraits partiels à recomposer
494		-
495		-\| Source \| Extraits à publier \| Destination \| Mode \|
496		-\|---\|---\|---\|---\|
497		-\| `docs/DATABASE.md` \| ERD + tables publiques (pas le SQL interne brut) \| `developer_manual/reference/schema-base-donnees.md` \| reference \|
498		-\| `docs/SERVICES_REFERENCE.md` \| Structure + signatures — à compléter (inachevé à 100 lignes) \| `developer_manual/reference/services-api-interne.md` \| reference \|
499		-\| `docs/CHANGELOG_2FA_EMAIL_LOGIN.md` \| Transformer "changelog" en doc conceptuelle \| `developer_manual/explanation/2fa-fonctionnement.md` \| explanation \|
500		-\| `docs/CHANGELOG_FORCE_2FA.md` \| Feature flag + impact admin uniquement \| `administration_manual/how-to/forcer-2fa-globalement.md` \| how-to \|
501		-\| `docs/DAGGER_CI_ANALYSIS.md` \| Comparaison Easy vs Power Mode \| `developer_manual/explanation/ci-dagger-easy-vs-power.md` \| explanation \|
502		-\| `docs/PLAN_UI_TRANSFORMATION.md` \| Décisions design (DaisyUI, HTMX) — pas la roadmap \| `developer_manual/explanation/decisions-ui-htmx.md` \| explanation \|
503		-\| `docs/GUIDE_DEVELOPPEMENT_PHASE5.md` \| Diviser en deux : LOT 5.1 webhooks + LOT 5.2 API \| `developer_manual/how-to/implementer-webhooks.md` + `implementer-endpoint-api.md` \| how-to \|
504		-\| `docs/plans/import-async-worker.md` \| Patron TDD + worker + SSE (généraliser hors contexte import) \| `developer_manual/explanation/patron-worker-async.md` + `tutorials/03-creer-un-worker-async.md` \| explanation + tutorial \|
505		-\| `docs/plans/import-repository-externe.md` \| Démarche TDD MVP (généraliser) \| Fusionné avec précédent \| — \|
506		-\| `docs/REALISE_LOT1.md` \| Patron navigation arbre de fichiers \| `developer_manual/how-to/ajouter-route-web.md` (exemple illustratif) \| how-to \|
507		-\| `docs/REALISE_LOT12.md` \| Hiérarchie 2-niveaux des labels \| `developer_manual/explanation/hierarchie-labels.md` \| explanation \|
508		-
509		-### Fichiers à ignorer (obsolètes, internes, ou confidentiels)
510		-
511		-\| Fichier \| Raison \|
512		-\|---\|---\|
513		-\| `ARCHITECTURE.md` racine (pas `docs/`) \| Généré par wizard rustwarden, obsolète — `docs/ARCHITECTURE.md` fait foi \|
514		-\| `DEVELOPER.md` racine \| Générique rustwarden, remplacé par le nouveau manuel dev \|
515		-\| `docs/MIGRATION_GUIDE.md` \| V1→V2 obsolète (daté 2026-03-26) \|
516		-\| `docs/LOTS_RESTANTS.md` \| TODO interne obsolète \|
517		-\| `docs/ORDONNANCEMENT.md` \| Planification interne des lots \|
518		-\| `docs/evaluations.md` \| Notes internes produit (49K tokens), pas pour publication \|
519		-\| `docs/eval-credentials.local.md` \| Confidentiel — secrets, ne jamais publier \|
520		-\| `docs/Update_rustwarden_db_getter.md` + `project_rustwarden_db_getter.md` \| Notes tech debt internes \|
521		-\| `docs/REALISE_LOT2-11, 13-14, LOT_SSH` \| Rétros sprints sans valeur pédagogique publique \|
522		-
523		-### Autres fichiers existants (hors `docs/`) à copier dans la doc
524		-
525		-\| Fichier source \| Contenu copié dans la doc \|
526		-\|---\|---\|
527		-\| `.env.example` \| Contenu complet copié dans `administration_manual/reference/variables-environnement.md` (avec annotations et regroupement thématique) \|
528		-\| `deployment/gitrust.service`, `nginx-gitrust.conf` \| Contenu copié dans `template/systemd/gitrust.service` et `template/reverse-proxy/nginx-tls.conf` — fichiers standalone \|
529		-\| `static/api-docs/openapi.yaml` \| Copie embarquée dans `developer_manual/reference/openapi.yaml` + page `api-rest-v1.md` qui documente l'auth, la pagination, les codes erreur et intègre un rendu Swagger UI local (ou équivalent statique) \|
530		-
531		-## Stratégie multilingue (les 6 langues)
532		-
533		-- FR : langue source, canonique, tous les fichiers `.md` dans `src/` et sous-dossiers.
534		-- EN : traduction prioritaire, via `po/en.po` généré par `mdbook-xgettext`.
535		-- DE / ES / PT / IT : fichiers `po/*.po` créés vides au scaffold, traduction progressive.
536		-- Build mdBook produit 6 sites statiques (`book/fr/`, `book/en/`, ...) déployés sous `demo.gitrust.eu/docs/{lang}/`.
537		-- Une page d'accueil statique avec sélecteur de langue redirige selon `Accept-Language`.
538		-- Hors-scope de ce plan : traduire effectivement le contenu — seul le scaffold bilingue (FR + EN squelette) est livré ; les autres langues restent en stubs jusqu'à ce que la matière FR soit stable.
539		-
540		-## Scope de ce chantier (itération 1)
541		-
542		-Inclus :
543		-- Toute l'arborescence de dossiers et fichiers index (vides ou avec TODO) listée ci-dessus — incluant `developer_manual/`
544		-- `book.toml` fonctionnel, build local `mdbook serve` opérationnel
545		-- Import en bloc des 13 fichiers "or" depuis `gitrust/docs/` vers leurs destinations (copie + ajustement d'en-tête + placement Diátaxis correct)
546		-- 4 tutoriels phares rédigés (un par manuel : user, admin, dev, template) — respectant le template pédagogique : objectifs Bloom, prérequis explicites, modèle mental avant pratique, checkpoints observables toutes les 2 étapes max, sortie verbatim, section « Et si ça ne marche pas » avec 3 erreurs top, récap qui reprend chaque objectif, lien vers la suite du parcours
547		-- 4 templates critiques rédigés (env dev, docker-compose minimal, nginx TLS, systemd)
548		-- Diagrammes Mermaid architecture globale + flux-requetes (extraits de `docs/SEQUENCES.md`)
549		-- CI de build + lint Markdown
550		-- `README.md` + `CONTRIBUTING.md`
551		-- Pipeline de traduction `po/` en place (en.po généré, autres stubs vides)
552		-
553		-Exclus (itérations ultérieures) :
554		-- Extraction fine des 8 fichiers "mine" (recomposition manuelle nécessaire)
555		-- Complétion de `SERVICES_REFERENCE.md` (inachevé à 100 lignes — nécessite lecture du code)
556		-- Rédaction exhaustive des how-to et reference hors import (placeholders `TODO` listés)
557		-- Traduction réelle des langues autres que FR
558		-- Captures d'écran UI (nécessitent instance démo déployée)
559		-- Documentation API interactive au-delà du lien Swagger existant
560		-- Nettoyage du dépôt source `gitrust/docs/` (suppression des fichiers obsolètes identifiés — hors périmètre de ce dépôt doc)
561		-
562		-## Vérification
563		-
564		-1. Build local : `mdbook build` dans `/home/monsieurb/Documents/devel/girust_doc` produit `book/` sans erreur et sans warning de lien cassé.
565		-2. Serveur de dev : `mdbook serve --open` affiche le sommaire, les 4 manuels (user / admin / dev / template), les 4 tutoriels phares rédigés avec diagrammes Mermaid rendus correctement, et les 13 fichiers importés depuis `gitrust/docs/` accessibles via la navigation.
566		-3. Lint Markdown : `markdownlint-cli2 "*/.md"` passe sans erreur.
567		-4. Validation Mermaid : chaque fichier `.mmd` dans `diagrams/` est parsable via `mermaid-cli` (`mmdc -i x.mmd -o x.svg`).
568		-5. Sommaire : chaque entrée de `src/SUMMARY.md` pointe vers un fichier qui existe (pas de lien mort).
569		-6. Templates copiables : `cp template/env/dev-local.env ../gitrust/.env && cd ../gitrust && cargo run` doit démarrer l'instance sans modification (validation du contrat avec `gitrust/.env.example`).
570		-7. i18n : `mdbook build` avec `MDBOOK_BOOK__LANGUAGE=en` produit `book/en/` avec fichiers traduits pour les pages où `po/en.po` contient des entrées, et fallback FR pour le reste.
571		-8. CI GitHub/gitrust : le workflow de build passe sur une PR factice ajoutant un `.md` incorrect (doit échouer) et sur un `.md` valide (doit passer).
572		-9. Audit pédagogique des 4 tutoriels phares : chacun coche toute la checklist :
573		- - [ ] Objectifs Bloom observables déclarés (`O1..On`)
574		- - [ ] Prérequis technique + pédagogique + temps estimé explicites
575		- - [ ] Modèle mental / schéma Mermaid avant la première commande
576		- - [ ] ≤ 3 concepts nouveaux dans la page
577		- - [ ] ≤ 2 étapes consécutives sans checkpoint observable
578		- - [ ] Sortie verbatim à chaque commande
579		- - [ ] Section « Et si ça ne marche pas » avec ≥ 3 erreurs top
580		- - [ ] Récap reprend explicitement chaque `Oi`
581		- - [ ] Lien vers la prochaine étape du parcours
582		-10. Audit de parcours : chaque manuel (user, admin, dev) a dans son `index.md` un diagramme Mermaid du parcours complet avec temps, scaffolding dégressif d'exactement 1 cran entre tutoriels, pas de saut > 1 niveau Bloom.

D CLAUDE.md

+0 -81

@@ -1,81 +0,0 @@

1		-# CLAUDE.md
2		-
3		-Directives projet pour Claude Code lorsqu'il intervient dans `girust_doc/`.
4		-
5		-## Mission du dépôt
6		-
7		-Documentation officielle publique de la plateforme gitrust (forge Git self-hosted en Rust). Publiée sur `https://demo.gitrust.eu`. Source : dépôt gitrust voisin `/home/monsieurb/Documents/devel/gitrust`.
8		-
9		-## Conventions inviolables
10		-
11		-### Plans de travail
12		-
13		-Tout plan issu de `/plan`, `ExitPlanMode`, `autopilot` ou tout autre workflow doit être écrit dans `./.plans/` à la racine du projet, jamais dans `~/.claude/plans/`. Numérotation séquentielle `NNN-slug.md`. Les plans sont versionnés avec le dépôt pour rester visibles par l'équipe.
14		-
15		-### Langue canonique
16		-
17		-- Source : français (FR) — tous les `.md` dans `src/` et sous-dossiers de contenu.
18		-- Traductions : via `mdbook-i18n-helpers` dans `po/{en,de,es,pt,it}.po`. Aligné avec les 6 langues de l'UI gitrust.
19		-- Ne jamais traduire manuellement en éditant un fichier `.md` non-FR : tout passe par `po/`.
20		-
21		-### Framework documentaire : Diátaxis strict
22		-
23		-Chaque manuel (`user_manual/`, `administration_manual/`) possède exactement quatre dossiers :
24		-
25		-- `tutorials/` — apprentissage guidé pas-à-pas (quand l'utilisateur apprend)
26		-- `how-to/` — recettes orientées tâche (quand l'utilisateur veut résoudre un problème précis)
27		-- `reference/` — description technique exhaustive (quand l'utilisateur cherche une information)
28		-- `explanation/` — contexte, rationale, concepts (quand l'utilisateur veut comprendre)
29		-
30		-Aucun fichier de contenu hors de ces quatre dossiers. Interdit : `guides/`, `docs/`, `misc/`, etc.
31		-
32		-### Templates = code pur
33		-
34		-Le dossier `template/` contient uniquement des fichiers copiables (configs, scripts, exemples de code). Pas de prose explicative sauf dans `template/index.md`. Tout contexte narratif va dans un `how-to/` qui référence le template.
35		-
36		-### Mermaid
37		-
38		-Sources Mermaid dans `diagrams/*.mmd`. Les `.md` incluent les diagrammes via un bloc de code Mermaid ou une directive d'inclusion mdBook. Ne jamais dupliquer un diagramme dans plusieurs fichiers : un fichier `.mmd` = une source de vérité.
39		-
40		-### Documentation autonome (déconnectée des sources)
41		-
42		-Ce dépôt est autosuffisant. Un lecteur sur `demo.gitrust.eu` n'a pas accès au code de `gitrust/`. Tout exemple (config, extrait de code, schéma SQL, diagramme) doit être copié dans la doc, pas référencé par lien local.
43		-
44		-- `.env.example` de gitrust → son contenu est copié dans `administration_manual/reference/variables-environnement.md`
45		-- Diagrammes Mermaid de `gitrust/docs/SEQUENCES.md` → copiés dans `diagrams/*.mmd`
46		-- Modèles de données, patrons de code, recettes d'installation → intégrés dans les pages correspondantes
47		-- Pas de liens `file://` ni de chemins relatifs sortant de `girust_doc/`
48		-- Seule exception admise : lien HTTP vers le dépôt public `demo.gitrust.eu/gitrust/gitrust` pour pointer vers le "code de référence", mais le contenu pertinent reste présent dans la doc
49		-- Conséquence : quand gitrust évolue, un travail de synchronisation manuel est nécessaire (documenté dans `CONTRIBUTING.md`)
50		-
51		-## Build et vérification
52		-
53		-```bash
54		-mdbook build # produit book/ (FR)
55		-mdbook serve --open # serveur de dev
56		-MDBOOK_BOOK__LANGUAGE=en mdbook build # produit book/en/
57		-markdownlint-cli2 "*/.md" # lint
58		-mmdc -i diagrams/x.mmd -o /tmp/x.svg # validation Mermaid individuelle
59		-```
60		-
61		-CI : `.github/workflows/build-docs.yml` enchaîne build + lint + validation Mermaid sur chaque PR.
62		-
63		-## Structure imposée
64		-
65		-```
66		-girust_doc/
67		-├── CLAUDE.md # ce fichier
68		-├── .plans/ # plans de travail versionnés
69		-├── book.toml # config mdBook
70		-├── src/SUMMARY.md # sommaire mdBook
71		-├── user_manual/ # Diátaxis × 4
72		-├── administration_manual/ # Diátaxis × 4
73		-├── template/ # code/config copiables
74		-├── diagrams/ # sources Mermaid
75		-├── po/ # traductions gettext
76		-└── theme/ # thème mdBook custom
77		-```
78		-
79		-## Projet source (gitrust)
80		-
81		-Tous les liens vers le code ou la config gitrust pointent vers `/home/monsieurb/Documents/devel/gitrust` en local et vers `https://demo.gitrust.eu/gitrust/gitrust` une fois publié. Toujours vérifier que le lien existe encore avant de le référencer dans une page publiée.