Axe 5 : Approches

Onboarding des PME

Le point de départ des PME dans la conformité native Git suit un parcours progressif :

1. Initialiser le dépôt Git - Structure avec un répertoire .gitcover/ et une configuration V7GUID
2. Sélectionner un catalogue OSCAL - Base GoBD, modules BSI ou profil individuel
3. Activer les politiques OPA - Hooks pre-receive pour la validation avant commit
4. Configurer la signature GPG - Une paire de clés GPG par acteur
5. Démarrer la chaîne de preuve - Attribuer les premiers V7GUID et lancer le chaînage prev-hash

Pour les entrepreneurs dès le niveau de l’activité d’appoint

Le point de départ peut reposer sur un scénario très simple : GCDMS pour l’archivage des pièces justificatives, GCPN pour les chaînes de preuve. Élargir ensuite : politiques OSCAL, validation OPA, multi-tenant.

Onboarding interactif : la « Compliance City »

Au lieu de questionnaires classiques, l’onboarding se déroule sous la forme d’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 ensemble de briques (Lego-Set), qui est déposé et versionné sous forme de module structuré dans le nouveau dépôt Git initialisé par défaut.

L’analogie pour l’utilisateur :

• La plaque de base : Le dépôt Git vide, nouvellement créé pour le tenant dans son infrastructure. Il offre le cadre normalisé (les tenons) auquel tout se raccorde.
• Les briques : Configuration modulaire et fichiers de service. Ce n’est que lorsqu’une brique s’emboîte (commit Git) que la fonction ou le contrôle de conformité correspondant est activé.

Phase 1 - Agencer la plaque de base (initialisation et identité) :

Le système crée automatiquement le dépôt Git par défaut du 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 constitue déjà le premier processus de conformité auditable. À noter : les tenants peuvent bien sûr aussi être organisés de manière hiérarchique, comme les structures d’entreprise auxquelles ils appartiennent.

Phase 2 - Câblage de l’infrastructure (réseau de distribution) :

L’assistant recense le paysage informatique : 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 relatives à l’infrastructure et préparent les chemins des connexions transversales (others.json).

Phase 3 - Construire les bâtiments (périmètre métier) :

L’utilisateur décide de manière modulaire des domaines réglementaires que sa ville doit sécuriser :

L’utilisateur ne voit à aucun moment de fichiers de configuration ni de code. Comme chaque étape génère immédiatement un commit Git propre, le système est documenté dès la première minute de manière à garantir entièrement la traçabilité conformément à GoBD et AO.

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

Claims OIDC et others.json

Le lien entre les claims OIDC et others.json est la voie royale vers des environnements de conformité multitenant sûrs pour les non-spécialistes. others.json rassemble :

1. Des routes canoniques vers les dépôts Git propres au tenant
2. Des connexions transversales vers les dépôts Git d’autres tenants, lorsque le tenant est membre d’un groupe

L’accès est contrôlé par les claims OIDC (rôles et claims personnalisés comme tenant_id, org_unit_id et appartenances à des groupes). Un pipeline Inlet lit others.json en fonction du claim utilisateur et injecte les chemins autorisés comme prompt système :

Tu es l’agent GitCover du tenant X. Tu as exclusivement accès aux dépôts suivants : [Pfad 1], [Pfad 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) :

others.json associe ces claims aux chemins des 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 disposant de org_unit_id = ORG-1-Portfolio accède à PII/ORG-1-Portfolio, mais pas à PII/ORG-2-IT — même avec le même tenant_id. Cela met en œuvre le principe du moindre privilège (NIS2 Art. 21) au niveau du dépôt.

Pour l’utilisateur final, cet appareillage de sécurité reste invisible. Il se connecte, retrouve son environnement de travail habituel, et l’IA sait automatiquement où elle est autorisée à agir.

Saisie de données assistée par IA par passerelle de formulaire

Les interfaces de chat sont adaptées aux contextes et aux analyses, et non à la saisie stricte de données typées (IBAN, codes postaux, schémas OSCAL). Le GCBoK recommande donc une passerelle vers un formulaire :

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

Avantage : La validation avant l’enregistrement protège la source unique de vérité. Les LLM ne manipulent pas le processus d’écriture. La validation par hook Git/OPA est déclenchée immédiatement.

La structure du répertoire .gitcover/

Le répertoire .gitcover/ à la racine d’un dépôt GitCover constitue l’archive centrale de tous les artefacts non liés au code. Il sert à la traçabilité, à la conformité (GoBD/AO) et à la gestion de la piste d’audit.

Arborescence 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 dénomination des fichiers

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

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

---
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 les hooks Git et les webhooks

Lors de l’init ou de l’onboarding du tenant, les dépôts GitCover sont automatiquement configurés avec des hooks/webhooks :

• post-commit : Met à jour .gitcover/ lors des nouveaux commits
• pre-push : Valide .gitcover/ avant le push
• Webhooks : Création d’une issue, modifications d’un projet, saisie du temps - déclenchent chacune un export au format .v7g.md
• Claim de conformité : Activation immédiate des mécanismes OSCAL/OPA

Le versionnement de ces hooks/webhooks s’effectue également par Git, ce qui rend les modifications traçables et auditables (autoréférentiel, versionné, sécurisé en termes de traçabilité). Les hooks eux-mêmes peuvent être des artefacts de code versionnés, résidant dans .gitcover/hooks/, puis être mis à jour si nécessaire et être documentés de manière conforme à GoBD ou NIS2.

Consignes privées du HITL - Convention et règle pour les agents

Outre la documentation de conformité versionnée, chaque personne active tient ses consignes personnelles - à savoir la manière dont elle veut travailler, délimiter son travail et établir ses priorités. Cette couche est privée et protégée : elle reste locale et non versionnée (en règle générale dans un répertoire du contexte de travail propre, exclu par .gitignore, modèle : projections/). Elle ne fait ainsi pas partie du corpus de documentation de conformité et n’appartient pas non plus aux dépôts commités, issues, pull requests, rapports ou notifications.

À quoi elle sert : Elle constitue le matériau d’entrée de ce qui est documenté - pour les décisions documentées (ADR), les modèles, la pondération des projets et la conception des outils. Ce qui est documenté, c’est le résultat, et non l’évaluation qui le sous-tend.

Règle pour les agents (obligatoire) :

1. Respecter - Les consignes façonnent les attentes, le ton, les délimitations et les priorités ; elles sont lues et respectées.
2. Ne pas documenter, ne pas citer - Aucun contenu de cette couche ne doit figurer dans les corps de texte, le code, les documents de décision, les pièces justificatives, les tickets, les rapports ou les notifications, sauf si le HITL l’autorise expressément à être documenté.
3. Ne pas publier - La couche reste locale ; pour les exemples destinés à la communauté, à l’OSS ou au matériel de formation, elle est anonymisée et décrite uniquement comme modèle.
4. Limite de la preuve - La chaîne de preuve versionnée référence l’effet d’une consigne (par exemple « Attribution conformément aux consignes du HITL »), jamais son libellé protégé.

Sidecars V7GUID

Un sidecar V7GUID est un fichier de métadonnées *.v7g.md déposé à côté d’un document numérique d’origine - par exemple, 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 dans un fichier binaire (PDF, DOCX, EML, image) et ancre ainsi l’original dans la chaîne de preuve et le GCDMS.

Informations minimales

Chaque sidecar contient obligatoirement :

• sha256 - Hash SHA-256 du document numérique d’origine (preuve d’intégrité).

Complémentairement, il consigne généralement l’identité, la taxonomie et l’emplacement (modèle voir 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 pure - l’identifiant d’instance concret (Object ID) du double identifiant qui matérialise le document individuel (cf. Axe 2 : Concepts). Elle doit ainsi être distinguée de la v7guid catégorisée, qui encode 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 sortable :

1. Outil : Un outil de sidecar génère un UUIDv7 à partir d’un argument TimeStamp en tant que DocID.
2. Source par défaut : l’horodatage du fichier (mtime) du document d’origine.
3. Source métier (si disponible) : Si le nom ou le contenu du fichier fournissent une date significative sur le plan métier (p. ex. date de facture, d’e-mail ou de décision), cette date est utilisée à la place de la mtime - la DocID se lie ainsi à la date d’établissement du document.

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

Relation avec V7GUID et le registre

• V7GUID : Le bloc v7g_taxonomy affecte le document, au moyen de sa v7guid catégorisée, à la hiérarchie métier à six niveaux et à la sphère du tenant (voir Axe 2 : Concepts).
• Registre : Le bloc locations documente l’emplacement physique de stockage (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",
  "docUid": "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 factuelle 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 textuellement (Fixes #123) ; Git n’interprète pas cette référence.

Solution : export automatisé au format .v7g.md

Le workflow de la base de données Gitea à la base factuelle Git sécurisée en termes de traçabilité :

1. Issue Gitea créée → Le webhook déclenche l’export
2. Export au format .v7g.md → Stockage dans .gitcover/issues/
3. Extraction des métadonnées → UUID, hashes, signatures
4. Commit Git signé → 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

Préparation à l’audit

La préparation à l’audit signifie que tout audit peut être réalisé à tout moment - sans travail de rattrapage.

Thèse : La forensique est le dépôt Git, le HTML n’est que de la présentation Le paquet de contrôle HTML (site Web d’audit, rapports générés) est un dérivé destiné à la lisibilité humaine. La valeur probante forensique réside exclusivement dans le dépôt Git lui-même : historique de commits immuable, commits signés GPG, chaînes de preuve V7GUID, registres/dictionnaires .gitcover/ au format JSON/JSONL. Lors d’un audit dix ans plus tard, un git clone (ou l’extraction d’un git bundle) suffit — aucune infrastructure Web, aucune base de données, aucun service en cours d’exécution n’est nécessaire. Ceci correspond à la hiérarchisation des schémas (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 une conformité native Git :

1. Clôturer la période - Figer la branche Git FY2026 (tag)
2. Valider la chaîne de preuve - Vérifier le chaînage V7GUID (script)
3. Générer les résultats d’évaluation OSCAL - Automatisé à partir des validations OPA
4. Émettre le sceau GPG - Commit de clôture avec signature GF
5. Archiver - Conteneur .v7g.zip, export v7g

Analyse de risque NIS2

L’analyse de risque NIS2 sur une base Git :

1. Inventaire des actifs - Dépôts Git comme registre d’actifs
2. Identification des risques - Politiques OPA pour les scénarios de menace
3. Évaluation - Classification V7GUID pour les catégories de risque
4. Mitigation - Hooks pre-receive pour l’application des politiques
5. Rapport - Résultats d’évaluation OSCAL comme preuve NIS2

Traitement des incidents de sécurité (Incident Response)

Principe : d'abord prouver, ensuite évaluer. Un rapport d'incident est un artefact Git doté d'un historique des modifications — y compris notre propre erreur d'appréciation. Une affirmation défendable n'est jamais « nous sommes sûrs », mais : « Pour cette période, ces systèmes et ces couches de journaux, aucun indice d'exploitation — avec la limite de preuve suivante. »

Procédure en sept étapes

1. Recenser et trier. Que sait-on (CVE, avis, observation), quels systèmes et services sont concernés, quelle période examiner ? Consigner le déclencheur et les horodatages.
2. Déterminer l'exposition par inventaire. Non pas « nous utilisons le produit X », mais : quelle SAPI, quels services, quels points exposés ? Indiquer séparément chemins internes, ports limités au LAN et sites orphelins.
3. Fournir la preuve du correctif et de la configuration. Version du paquet et exécution (redémarrage du service), intégrité des fichiers, efficacité de la configuration. Pour chaque affirmation de configuration, une contre-épreuve : le fichier existe-t-il, croît-il, tourne-t-il ?
4. Évaluer les journaux sur plusieurs couches. Une couche ne répond jamais à tout ; chacune a un angle mort à nommer dans le rapport. Documenter l'espace de recherche (chemins, profondeur, fenêtre temporelle) — un constat négatif sans espace de recherche documenté n'est pas un constat.
5. Évaluer et vérifier les obligations de notification. L'art. 23 de NIS2 exige, pour un incident de sécurité important, un avertissement précoce (24 h), une notification (72 h) et un rapport final (un mois). La décision « notifiable / non notifiable » est motivée, pas prise en silence.
6. Sécuriser mesures et preuves. Mesures immédiates, durcissement, démantèlement des services orphelins. Sécuriser les preuves avant la rotation suivante sous forme d'archive : compressée, propriétaire root, droits 640, somme de contrôle dans le rapport.
7. Clôturer. Lessons Learned, mesures sous forme de tâches avec référence de contrôle, version du rapport avec historique des modifications. Les faux constats sont corrigés et documentés comme corrections.

Couches de journaux et leurs angles morts

En complément : gestionnaire de paquets (moment du correctif), Fail2ban (force brute), historique de configuration (ce qui a changé et quand). Seule la combinaison porte une affirmation.

Faux constats typiques

Artefacts de la chaîne de preuve

Lien avec les autres axes

• Fondamentaux (axe 1) : obligations NIS2 et délais de notification.
• Techniques (axe 4) : identités et signatures vérifiables pour les rapports et les preuves (GPG, uuidV7, Git comme IdP).
• Modèles (axe 6) : le rapport d'incident suit la même structure que les autres rapports d'audit — résumé de direction, périmètre, preuve, appréciation, mesures, annexe.

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 centralement 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 relie, pour l’inférence et la recherche Web, aux 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 dépassent le bac à sable des conteneurs, l’agent utilise un SSH Script Host - une sortie du bac à sable, contrôlée par clé, 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 de l’hôte
3. Processus natif : La commande est exécutée dans le contexte réel 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 est analysée dans le contexte LLM

Condition de sécurité : La clé SSH générée dans le conteneur doit être ajoutée à authorized_keys sur l’hôte. La communication s’effectue uniquement 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 le poste de travail, le conteneur et le Script-Host, les partages du serveur de fichiers sont montés aux mêmes points de montage sur tous les systèmes. À tout moment, les agents d’IA et les développeurs humains référencent des chemins absolus identiques.

Capacité multi-appareils

Grâce à la centralisation sur le serveur d’IA, plusieurs terminaux peuvent accéder simultanément au même environnement :

• Le développeur lance une analyse de code sur son poste
• Il suit l’avancement de l’agent en temps réel sur le smartphone via VPN
• Aucun blocage mutuel - le Script-Host ouvre des processus shell séparés et de courte durée

Frontends de partage : Nextcloud comme interface en lecture seule

Répartition des rôles

Conditions d’utilisation

Nextcloud peut être utilisé de manière ciblée pour les partages dans un environnement fondé sur le GCBoK, si :

1. Uniquement des partages 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, S3 Gateway ou GCSYNC)
3. Validation des politiques - GCPN définit les règles d’accès (OPA/Rego) ; Nextcloud se contente de les appliquer
4. Journalisation d’audit - Les journaux Nextcloud sont transmis à GCAL (Syslog/Loki)
5. Conformité open source - Uniquement la Community-Edition, aucun plugin propriétaire

Critères d’exclusion

• Accès en écriture via Nextcloud (en violation du stockage natif Git)
• Extensions Nextcloud propriétaires (en violation des principes OSS)
• Absence d’intégration Git (Nextcloud doit pouvoir accéder aux dépôts Git)

Voir aussi : Modèles de catalogues OSCAL et de politiques OPA dans Axe 6 : Modèles.