Axe 5 : Démarches

Onboarding des PME

L'entrée des PME dans la conformité Git-native suit un parcours pas à pas :

1. Initialiser le dépôt Git - structure avec répertoire .gitcover/, configuration V7GUID
2. Sélectionner un catalogue OSCAL - baseline GoBD, modules BSI ou profil individuel
3. Activer les policies OPA - hooks pre-receive pour la validation avant commit
4. Mettre en place la signature GPG - une paire de clés GPG par acteur
5. Démarrer la chaîne de justificatifs - attribuer les premiers V7GUIDs, commencer le chaînage prev-hash

Pour les entrepreneurs dès le niveau d'activité accessoire

Le démarrage peut commencer par une histoire très simple : GCDMS pour l'archivage des justificatifs, GCPN pour les chaînes de preuves. Extension ultérieure : policies OSCAL, validation OPA, multi-tenant.

Onboarding interactif : la « Compliance City »

Au lieu de questionnaires classiques, l'onboarding se déroule comme une construction modulaire selon le concept d'une ville sur une plaque de base Lego. Chaque décision architecturale et chaque exigence métier correspond à une brique ou à un assemblage (set Lego) qui est déposé et versionné comme module structuré dans le dépôt Git par défaut nouvellement initialisé.

L'analogie pour l'utilisateur :

• La plaque de base : le dépôt Git vide, fraîchement créé pour le tenant dans son infrastructure. Il offre le cadre normalisé (les picots) sur lequel tout vient s'arrimer.
• Les briques : configuration modulaire et fichiers de service. Ce n'est que lorsqu'une brique s'enclenche (commit Git) que la fonction correspondante ou le contrôle de conformité devient actif.

Phase 1 - Poser la plaque de base (initialisation & identité) :

Le système crée automatiquement le dépôt par défaut pour le tenant. L'assistant d'onboarding détermine l'identité de l'entreprise. Les données sont déposées de manière structurée dans le dépôt 'TOP' (Tenant Organization Profile) - le premier commit Git est déjà le premier processus de conformité auditable. Au fait : les tenants peuvent bien sûr aussi être organisés hiérarchiquement, à l'image des structures d'entreprise auxquelles ils appartiennent.

Phase 2 - Câblage de l'infrastructure (réseau d'alimentation) :

L'assistant recense le paysage IT : poste de travail portable, serveur de fichiers, infrastructure cloud-first ou hybride. Des paramètres tels que la connexion Internet, le domaine, les chemins de stockage, etc. alimentent les informations d'infrastructure et préparent les chemins pour les connexions croisées (others.json).

Phase 3 - Ériger les bâtiments (scope métier) :

L'utilisateur décide de manière modulaire quels domaines réglementaires sa ville doit sécuriser :

À aucun moment l'utilisateur ne voit de fichiers de configuration ni de code. Comme chaque étape produit immédiatement un commit Git propre, le système est documenté dès la première minute, entièrement à l'épreuve des audits selon GoBD et AO.

Isolation des tenants et contrôle d'accès

Claims OIDC et others.json

L'association des claims OIDC au fichier others.json est la voie royale pour des environnements de conformité multi-tenants et sûrs pour les profanes. Dans others.json s'accumulent :

1. Les routes canoniques vers les dépôts Git propres au tenant
2. Les connexions croisées vers les dépôts Git d'autres tenants, lorsque le tenant est membre d'un groupe

L'accès est contrôlé via des claims OIDC (rôles et custom claims tels que tenant_id, org_unit_id et appartenances à des groupes). Une Inlet-Pipeline lit le others.json en fonction du claim de l'utilisateur et injecte les chemins autorisés en tant que system prompt :

Tu es l'agent GitCover du tenant X. Tu as exclusivement accès aux dépôts suivants : [chemin 1], [chemin 2]. N'exécute aucune commande en dehors de ces répertoires.

Modèle de claims à deux niveaux pour l'accès aux PII

Pour l'accès aux données à caractère personnel (PII), le GCBoK définit une hiérarchie de claims à deux niveaux (voir Techniques : Git comme IdP :

Le fichier others.json mappe ces claims sur des chemins de dépôts :

{
  "tenant_id": "0197a3b2-f3c0-7b00-8001-000000000042",
  "org_unit_id": "ORG-1-Portfolio",
  "allowed_repos": [
    "TOP",
    "PII/ORG-1-Portfolio"
  ]
}

Un utilisateur avec org_unit_id = ORG-1-Portfolio obtient l'accès à PII/ORG-1-Portfolio, mais pas à PII/ORG-2-IT — même avec le même tenant_id. Ceci met en œuvre le principe du moindre privilège (NIS2 Art. 21) au niveau du dépôt.

Pour l'utilisateur final, ce dispositif de sécurité reste invisible. Il se connecte, voit son environnement de travail habituel et l'IA sait automatiquement où elle est autorisée à agir.

Saisie de données assistée par IA via le Formular-Bridging

Les interfaces de chat conviennent pour les contextes et les analyses, pas pour la saisie stricte de types de données (IBAN, codes postaux, schémas OSCAL). Le GCBoK recommande donc un Formular-Bridging :

1. L'IA détecte le besoin : l'utilisateur dit : « Je souhaite ajouter un nouvel établissement. »
2. URL de formulaire dynamique : l'IA fournit un lien vers un masque de saisie web validé (Blazor WASM/PWA), couplé à la gestion des sessions et des utilisateurs.
3. Saisie encapsulée : l'utilisateur remplit le formulaire - validation stricte avant enregistrement.
4. Écriture directe dans Git : le formulaire écrit le résultat sous forme de fichier structuré directement dans le working directory du dépôt du tenant et déclenche le commit.
5. L'IA reprend la main : le serveur MCP signale « Fichier mis à jour », l'IA le confirme dans le chat.

Avantage : la validation avant enregistrement protège la Single Source of Truth. Les LLM ne manipulent pas le processus d'écriture. La validation Git-Hook/OPA est déclenchée immédiatement.

La structure de répertoires .gitcover/

Le répertoire .gitcover/ à la racine d'un dépôt GitCover est l'archive centrale de tous les artefacts autres que le code. Il sert à la fiabilité pour les audits, à la conformité (GoBD/AO) et à la tenue de l'audit trail.

Layout des répertoires

.gitcover/
├── issues/              # Gitea-Issues als .v7g.md
├── projects/            # Projekt-Management-Daten
├── time_tracking/       # Zeiterfassung und Aufwandsnachweise
├── workflows/           # Workflow-Zustände und Genehmigungen
├── compliance/
│   ├── oscals/          # OSCAL-Dokumente (System Security Plans)
│   ├── opa/             # OPA-Regeln (Rego-Policies)
│   └── hooks/           # Git-Hooks für Automatisierung
├── audit/
│   ├── signatures/      # Kryptografische Signaturen
│   ├── timestamps/      # Zeitstempel (ELSTER/Bundesanzeiger)
│   └── logs/            # Protokolle
└── README.md            # Dokumentation der Struktur

Convention de nommage des fichiers

Format général : {uuidV7}_{human-readable-key}_{Beschreibung}.v7g.md

Schéma de métadonnées (.v7g.md Frontmatter)

---
uuid: 018e312f-3e4f-7000-8000-000000000000
key: "#123"
type: "issue"
title: "Bugfix: Login-Modul"
original_source: "Gitea"
original_repo_hash: "a1b2c3d4e5f6..."
related_commits: ["abc123", "def456"]
related_elements:
  project: "Projekt-X"
  milestone: "v1.0"
forensic_attributes:
  created_at: "2026-06-29T12:00:00Z"
  updated_at: "2026-06-29T14:30:00Z"
  created_by: "Person A"
compliance:
  gobd_relevant: true
  audit_trail: true
  signature: "GPG-Signatur-Hash"
  timestamp: "ELSTER-2026-06-29-120000"
---

Automatisation par Git-Hooks et Webhooks

Les dépôts GitCover sont configurés automatiquement avec des hooks/webhooks lors du init ou de l'onboarding du tenant :

• post-commit : met à jour .gitcover/ lors de nouveaux commits
• pre-push : valide .gitcover/ avant le push
• Webhooks : création d'issues, modifications de projets, suivi du temps - déclenchent chacun un export en .v7g.md
• Compliance-Claim : activation immédiate des mécanismes OSCAL/OPA

Le versionnage de ces hooks/webhooks s'effectue également via Git, de sorte que les modifications sont traçables et auditables (autoréférentiel, versionné, à l'épreuve des audits). Les hooks eux-mêmes peuvent être des artefacts de code versionnés, qui se trouvent dans .gitcover/hooks/, sont mis à jour au besoin et sont documentés conformément à GoBD ou NIS2.

Sidecars V7GUID

Un sidecar V7GUID est un fichier de métadonnées *.v7g.md déposé à côté d'un document original numérique - p. ex. Rechnung_2026.pdf reçoit Rechnung_2026.pdf.v7g.md dans le même répertoire. Le sidecar porte les métadonnées que Git ne peut pas stocker à l'intérieur d'un fichier binaire (PDF, DOCX, EML, image) et ancre ainsi l'original dans la chaîne de justificatifs et dans le GCDMS.

Informations minimales

Chaque sidecar contient obligatoirement :

• sha256 - hachage SHA-256 du document original numérique (preuve d'intégrité).

En complément, il renseigne en règle générale l'identité, la taxonomie et la localisation (voir le modèle Axe 6 : Modèles).

Attribution de la DocID

Si le document n'est pas encore géré dans le DMS, une nouvelle DocID est générée. La DocID est l'uuidv7 pur - l'identifiant d'instance concret (Object ID) du double identifiant qui matérialise le document individuel (cf. Axe 2 : Concepts). Elle est ainsi à distinguer de la v7guid catégorisée, qui code le contexte métier (classe, tenant, sphère).

La DocID est générée à partir d'un horodatage, de sorte qu'elle est liée au temps et triable :

1. Outil : un outil sidecar génère une UUIDv7 à partir d'un argument TimeStamp comme DocID.
2. Source par défaut : la marque temporelle du fichier (mtime) du document original.
3. Source métier (si disponible) : si le nom de fichier ou le contenu fournit une date significative sur le plan métier (p. ex. date de facture, d'e-mail ou d'avis officiel), celle-ci est utilisée à la place de la mtime - la DocID se lie ainsi à la date de création du document.

Les deux identifiants - la DocID (uuidv7) et la v7guid catégorisée - sont gérés dans le sidecar et liés via le composite_key ({v7guid}:{uuidv7}).

Lien avec V7GUID et la Registry

• V7GUID : le bloc v7g_taxonomy classe le document, via sa v7guid catégorisée, dans la hiérarchie métier à six niveaux et dans la sphère du tenant (voir Axe 2 : Concepts).
• Registry : le bloc locations documente l'emplacement de stockage physique (chemin UNC, période de validité). Les identifiants de tenant enregistrés sont gérés dans le registre central des tenants (Registre central des tenants, Axe 2).

Structure (exemple)

# V7G Sidecar - Rechnung_2026.pdf

**SHA-256:** `7d4e2f...`
**Tenant:** ORG-1
**Kategorie:** Finanzen und Buchführung
**Sphäre:** ideell

```json
{
  "$schema": "https://gitcover.org/schemas/v7g-sidecar-1.0.schema.json",
  "uuidV7": "0197a3b2-f3c0-7b00-8001-000000000042",
  "sha256": "7d4e2f...",
  "original_filename": "Rechnung_2026.pdf",
  "locations": [
    { "unc_path": "./ORG-1/FY2026/Rechnung_2026.pdf", "from": "260506", "to": null, "note": "Primärspeicherort" }
  ],
  "v7g_taxonomy": [
    { "v7guid": "0197a3b2-...-8001-...", "taxonomy": "ORG-1/Financial", "valid_from": "260506", "valid_to": null }
  ],
  "verification": { "verified_by": "auto", "method": "sha256_file", "intact": true }
}
```

Archivage des issues : de la base de données Gitea à la base de faits Git

Problématique

Les issues Gitea sont des entrées de base de données - pas des objets Git natifs. Elles ne sont pas versionnées et ne sont pas reconstituables en cas de perte de la base de données Gitea. Les commits ne référencent les issues que de manière textuelle (Fixes #123) ; cette référence n'est pas interprétée par Git.

Solution : export automatisé en .v7g.md

Le workflow de la base de données Gitea vers la base de faits à l'épreuve des audits :

1. Issue Gitea créé → le webhook déclenche l'export
2. Export en .v7g.md → enregistrement dans .gitcover/issues/
3. Extraction des métadonnées → UUID, hachages, signatures
4. Commit Git avec signature → git commit -S
5. Validation OSCAL/OPA → contrôle de conformité
6. Horodatage → intégration ELSTER/Bundesanzeiger (si nécessaire)

Exemple de règle OPA pour la validation des issues

package gcbok.compliance

violation[msg] {
  input.path == "issues"
  file := input.files[_]
  not startswith(file.name, "018")  # UUIDv7-Prüfung
  msg := sprintf("Issue %s hat keine gueltige UUIDv7 im Dateinamen", [file.name])
}

Conformité GoBD/AO

Audit-Readiness

L'Audit-Readiness signifie : chaque audit peut avoir lieu à tout moment - sans préparation supplémentaire.

Thèse : la forensique est le dépôt Git, le HTML n'est que la présentation Le paquet de contrôle HTML (site d'audit, rapports générés) est un dérivé destiné à la lisibilité humaine. La force probante forensique réside exclusivement dans le dépôt Git lui-même : historique des commits inaltérable, commits signés GPG, chaînes de justificatifs V7GUID, Registries/Dictionaries .gitcover/ au format JSON/JSONL. Pour un audit 10 ans plus tard, un git clone suffit (ou le décompactage d'un git bundle) — pas d'infrastructure web, pas de base de données, aucun service en cours d'exécution nécessaire. Ceci correspond au Schema-Tiering (voir Modèles : Schéma V7GUID) et au dérivé gcbok-audit-evidence-docs/docs/02-audit-website-als-pruefungsartefakt.

Clôture annuelle GoBD

La clôture annuelle GoBD avec la conformité Git-native :

1. Clôturer la période - geler la branche Git FY2026 (tag)
2. Valider la chaîne de justificatifs - vérifier le chaînage V7GUID (script)
3. Générer les OSCAL-Assessment-Results - automatisé à partir des validations OPA
4. Délivrance du sceau GPG - commit de clôture avec signature GF
5. Archivage - conteneur .v7g.zip, v7g-export

Analyse de risques NIS2

L'analyse de risques NIS2 sur la base de Git :

1. Inventaire des actifs - dépôts Git comme registre d'actifs
2. Identification des risques - policies OPA pour les scénarios de menace
3. Évaluation - classification V7GUID pour les catégories de risques
4. Atténuation - hooks pre-receive pour l'application des policies
5. Rapport - OSCAL-Assessment-Results comme preuve NIS2

Intégration du serveur d'IA dans le LAN

Principe d'architecture

Le GCBoK décrit un modèle de référence pour l'intégration d'un serveur d'IA headless dans le LAN, qui fournit de manière centralisée l'inférence LLM et des agents de conformité assistés par RAG. L'environnement d'IA s'exécute dans un environnement de conteneurs isolé (Rootless Podman), mais se couple, pour l'inférence et la recherche web, à des services installés nativement sur l'hôte.

SSH Script Host (OSSH)

Pour les tâches exigeantes (compilation de code, opérations Git, contrôles de conformité) qui vont au-delà de la sandbox de conteneurs, l'agent utilise un SSH Script Host - une sortie contrôlée, basée sur les clés, vers le système hôte :

1. L'agent décide : « Exécute dotnet-build »
2. Canal SSH : connexion chiffrée via id_rsa.pub vers l'utilisateur hôte
3. Processus natif : la commande est exécutée dans le véritable contexte du système d'exploitation
4. Retour en flux : stdout/stderr sont renvoyés sous forme de flux de texte
5. L'agent analyse : la sortie du compilateur dans le contexte LLM

Prérequis de sécurité : la clé SSH générée dans le conteneur doit être enregistrée sur l'hôte dans authorized_keys. La communication s'effectue exclusivement via les flux de données standard (stdin, stdout, stderr) - sans transfert de fichiers.

Adressage cohérent des chemins (FQN)

Pour éviter les incohérences de chemins entre la station de travail, le conteneur et le script host, les partages du serveur de fichiers sont montés sur tous les systèmes aux mêmes points de montage. Les agents d'IA et les développeurs humains référencent à tout moment des chemins absolus identiques.

Capacité multi-appareils

Grâce à la centralisation sur le serveur d'IA, plusieurs terminaux peuvent accéder en parallèle au même environnement :

• Le développeur lance une analyse de code sur son desktop
• Il suit la progression de l'agent en temps réel sur son smartphone via VPN
• Aucun blocage mutuel - le script host ouvre des processus shell distincts et éphémères

Frontends de partage : Nextcloud comme frontend en lecture seule

Répartition des rôles

Conditions d'utilisation

Nextcloud peut être utilisé ponctuellement pour des shares dans un environnement basé sur le GCBoK, si :

1. Uniquement des shares en lecture seule - aucune modification via Nextcloud ; toutes les mutations passent par Git
2. Intégration Git - Nextcloud monte les dépôts Git comme stockage externe (WebDAV, passerelle S3 ou GCSYNC)
3. Validation des policies - GCPN définit les règles d'accès (OPA/Rego) ; Nextcloud se contente de les appliquer
4. Journalisation d'audit - les logs Nextcloud sont transmis à GCAL (Syslog/Loki)
5. Conformité open source - uniquement l'édition Community, pas de plugins propriétaires

Critères d'exclusion

• Accès en écriture via Nextcloud (va à l'encontre du stockage Git-native)
• Extensions Nextcloud propriétaires (va à l'encontre des principes OSS)
• Absence d'intégration Git (Nextcloud doit pouvoir accéder aux dépôts Git)

Voir aussi : les modèles pour catalogues OSCAL et policies OPA dans Axe 6 : Modèles.