Axe 5 : Procédures

Onboarding des PME

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

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

Pour les entrepreneurs à partir du niveau d'activité secondaire

L'entrée peut commencer par un scénario très simple : GCDMS pour l'archivage des justificatifs, GCPN pour les chaînes de preuve. Étendre ensuite : politiques OSCAL, validation OPA, multi-tenant.

Onboarding interactif : la « Compliance City »

Au lieu de questionnaires classiques, l'onboarding prend 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 (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 fournit le cadre normalisé (les picots) sur lequel tout vient s'emboîter.
• Les briques : Configuration modulaire et fichiers de service. Ce n'est qu'une fois qu'une brique s'enclenche (commit Git) que la fonction ou le contrôle de conformité correspondant devient actif.

Phase 1 – Poser la plaque de base (initialisation et identité) :

Le système crée automatiquement le dépôt par défaut du tenant. L'assistant d'onboarding détermine l'identité de l'entreprise. Les données sont stocké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. D'ailleurs : 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'approvisionnement) :

L'assistant recense le paysage informatique : poste de travail portable, serveur de fichiers, cloud-first ou infrastructure hybride. Des paramètres tels que la connexion Internet, le domaine, les chemins de stockage, etc., sont intégrés aux informations d'infrastructure et préparent les chemins pour les interconnexions (others.json).

Phase 3 – Ériger les bâtiments (périmètre métier) :

L'utilisateur décide de manière modulaire quels domaines réglementaires 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 entièrement auditable conformément à la GoBD et à l'AO.

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

Claims OIDC et others.json

L'association des claims OIDC avec le fichier others.json est la voie royale pour des environnements de conformité multi-tenant et sûrs pour les non-spécialistes. Dans others.json se trouvent :

1. Routes canoniques vers les dépôts Git propres au tenant
2. Interconnexions 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). Un pipeline d'admission lit le fichier others.json selon le claim utilisateur et injecte les chemins autorisés comme prompt système :

Tu es l'agent GitCover pour le 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 associe ces claims à des chemins de dépôt :

{
  "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. Cela 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 peut agir.

Saisie de données assistée par IA via le pontage de formulaires

Les interfaces de chat conviennent aux contextes et aux analyses, mais pas à la saisie stricte de types de données (IBAN, codes postaux, schémas OSCAL). Le GCBoK recommande donc un pontage de formulaires :

1. L'IA détecte le besoin : L'utilisateur dit « Je souhaite ajouter un nouvel établissement. »
2. URL de formulaire dynamique : L'IA émet 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 – validé de manière stricte avant enregistrement.
4. Écriture directe dans Git : Le formulaire écrit le résultat sous forme de fichier structuré directement dans le répertoire de travail 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 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 du répertoire .gitcover/

Le répertoire .gitcover/ à la racine d'un dépôt GitCover est l'archive centrale de tous les artefacts non-code. Il sert à la sécurité de révision, à la conformité (GoBD/AO) et à la tenue de la piste d'audit.

Arborescence du répertoire

.gitcover/
├── issues/              # Gitea-Issues als .gc.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 : {YYMMDD}_{human-readable-key}_{Beschreibung}.gc.md

La V7GUID et le docUid figurent dans l'artefact de données, pas dans le nom de fichier ; le nom de fichier porte la signature temporelle {YYMMDD}.

Artefact de données (.gc.md)

L'artefact de données suit le modèle « lisible par l'humain d'abord, JSON en dernier » (JSON-First, pas de frontmatter YAML) :

{
  "docUid": "018e312f-3e4f-7000-8000-000000000000",
  "v7guid": "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"
  },
  "compliance": {
    "gobd_relevant": true,
    "audit_trail": true,
    "signature": "GPG-Signatur-Hash",
    "timestamp": "ELSTER-2026-06-29-120000"
  }
}

Automatisation via hooks Git et webhooks

Les dépôts GitCover sont automatiquement configurés avec des hooks/webhooks lors de l'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 projet, suivi du temps – déclenchent chacun l'export sous .gc.md
• Claim de conformité : activation immédiate des mécanismes OSCAL/OPA

Le versionnement de ces hooks/webhooks s'effectue également via Git, de sorte que les modifications sont traçables et auditables (autoréférentiel, versionné, sécurisé pour la révision). Les hooks eux-mêmes peuvent être des artefacts de code versionnés qui se trouvent dans .gitcover/hooks/ et sont mis à jour si nécessaire, et documentés conformément à la GoBD ou à NIS2.

Préférences privées du HITL – convention et règle pour les agents

En plus de la documentation de conformité versionnée, chaque personne qui travaille tient ses préférences personnelles – c'est-à-dire la manière dont elle veut elle-même travailler, se délimiter et prioriser. Cette couche est privée et protégée : elle reste locale et non versionnée (généralement dans un répertoire exclu par .gitignore de son propre contexte de travail ; modèle : projections/). Elle ne fait donc pas partie du corpus de documentation de conformité et n'a pas non plus sa place dans des dépôts commités, des issues, des pull requests, des rapports ou des affichages.

À quoi elle sert : Elle constitue le matériau d'entrée de ce qui est documenté – pour les documentations de décision (ADR), pour les modèles, pour la pondération des projets et pour la conception des outils. C'est le résultat qui est documenté, pas l'évaluation qui le sous-tend.

Règle pour les agents (impérative) :

1. Respecter – les préférences 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 dans le texte courant, le code, les documents de décision, les justificatifs, les tickets, les rapports ou les affichages, sauf si le HITL l'autorise expressément pour la documentation.
3. Ne pas publier – la couche reste locale ; pour les exemples dans la communauté, l'OSS ou le matériel de formation, elle est anonymisée et décrite uniquement comme modèle.
4. Limite de preuve – la chaîne de justificatifs versionnée référence l'effet d'une préférence (par exemple « attribution selon les préférences du HITL »), jamais sa formulation protégée.

Sidecars GitCover (.gc.md)

Un sidecar GitCover est un fichier de métadonnées *.gc.md déposé à côté d'un document original numérique – p. ex. Rechnung_2026.pdf reçoit Rechnung_2026.pdf.gc.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 – hash SHA-256 du document original numérique (preuve d'intégrité).

En complément, il contient généralement l'identité, la taxonomie et la localisation (modèle voir Axe 6 : Modèles).

Attribution du DocID

Si le document n'est pas encore géré dans le DMS, un nouveau DocID est généré. Le DocID est l'uuidv7 pur – l'identificateur d'instance concret (Object ID) du double identificateur qui matérialise le document individuel (cf. Axe 2 : Concepts). Il se distingue ainsi de la v7guid catégorisée, qui encode le contexte métier (classe, tenant, sphère).

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

1. Outil : Un outil de sidecar génère un UUIDv7 à partir d'un argument TimeStamp comme DocID.
2. Source par défaut : l'horodatage 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 de décision), celle-ci est utilisée à la place de la mtime – le DocID se lie ainsi à la date de création du document.

Les deux identificateurs – DocID (uuidv7) et v7guid catégorisée – sont tenus dans le sidecar et reliés via le composite_key ({v7guid}:{uuidv7}).

Lien avec V7GUID et le registre

• 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).
• Registre : Le bloc locations documente l'emplacement de stockage physique (chemin UNC, période de validité). Les identifiants de tenant enregistrés sont tenus dans le registre central des tenants (Registre central des tenants, Axe 2).

Structure (exemple)

# GitCover 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-2.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 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 reconstructibles en cas de perte de la base de données Gitea. Les commits ne référencent les issues que textuellement (Fixes #123) ; cette référence n'est pas interprétée par Git.

Solution : export automatisé sous .gc.md

Le workflow de la base de données Gitea vers la base de faits sécurisée pour la révision :

1. Issue Gitea créée → le webhook déclenche l'export
2. Export sous .gc.md → enregistrement dans .gitcover/issues/
3. Extraire les métadonnées → UUID, hashes, 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

Préparation à l'audit

La préparation à l'audit signifie : chaque audit peut avoir lieu à tout moment – sans post-traitement.

Thèse : la forensique, c'est le dépôt Git ; le HTML n'est que présentation Le paquet de vérification HTML (site web 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 de commits immuable, commits signés GPG, chaînes de justificatifs V7GUID, registres/dictionnaires .gitcover/ au format JSON/JSONL. Lors d'un audit 10 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 n'est nécessaire. Cela 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 conformité native Git :

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 résultats d'évaluation OSCAL – automatiquement à partir des validations OPA
4. Émission du sceau GPG – commit de clôture avec signature de la direction (GF)
5. Archivage – conteneur .gc.zip, gc-dms pack

Analyse des risques NIS2

L'analyse des risques NIS2 sur base Git :

1. Inventaire des actifs – les 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. Atténuation – hooks pre-receive pour l'application des politiques
5. Rapport – résultats d'évaluation OSCAL comme preuve NIS2

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

Principe : d'abord prouver, ensuite évaluer. Un rapport d'incident est un artefact Git avec historique des modifications — même sa propre erreur d'appréciation doit y figurer. L'affirmation solide n'est jamais « nous sommes sûrs », mais : « Pour cette période, ces systèmes et ces niveaux de logs, il n'existe aucun indice d'exploitation — dans la limite de preuve suivante. »

Déroulement en sept étapes

1. Recenser et trier. Que sait-on (CVE, alerte, observation), quels systèmes et services sont dans le périmètre d'effet, quelle période faut-il considérer ? Consigner le déclencheur et l'horodatage.
2. Déterminer l'exposition via l'inventaire. Non pas « nous utilisons le produit X », mais : quelles SAPI, quels services, quels endpoints exposés ? Indiquer séparément les chemins internes, les ports LAN-only et les sites orphelins.
3. Apporter la preuve du patch 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, faire une contre-vérification : le fichier existe-t-il, croît-il, est-il soumis à rotation ?
4. Analyser les logs sur plusieurs niveaux. Un niveau ne répond jamais à toutes les questions ; chacun a un angle mort qu'il faut mentionner dans le rapport. Documenter le périmètre de recherche (chemins, profondeur, fenêtre temporelle) — un constat négatif sans périmètre de recherche n'est pas un constat.
5. Évaluer et vérifier l'obligation de notification. L'art. 23 NIS2 exige, en cas d'incident de sécurité important, une alerte précoce (24 h), une notification (72 h) et un rapport final (un mois). La décision « soumis à notification / non soumis à notification » est motivée, pas prise tacitement.
6. Sécuriser les mesures et les preuves. Mesures immédiates, durcissement, démantèlement des services orphelins. Sauvegarder les preuves avant la prochaine rotation sous forme d'archive : compressées, propriétaire root, droits 640, somme de contrôle dans le rapport.
7. Assurer le suivi. Lessons Learned, mesures sous forme de tâches avec référence au contrôle, version du rapport avec historique des modifications. Les constats erronés sont corrigés et documentés comme correction.

Niveaux de logs et leurs angles morts

En complément : gestionnaire de paquets (moment du patch), Fail2ban (bruteforce), historique de configuration (qu'est-ce qui a changé et quand). Seule la combinaison permet une affirmation.

Constats erronés typiques

Artefacts de la chaîne de preuve

Lien avec les autres axes

• Fondements (Axe 1) : obligations NIS2 et délais de notification.
• Techniques (Axe 4) : identités prouvables et signatures 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 de vérification — Résumé managérial, périmètre d'application, preuve, évaluation, mesures, annexe.

Intégration d'un 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 conteneurisé isolé (Podman rootless), 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 dépassent la sandbox du conteneur, l'agent utilise un SSH Script Host – une évasion contrôlée et basée sur des 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 contexte réel du système d'exploitation
4. Retour en flux : stdout/stderr sont renvoyés sous forme de flux texte
5. L'agent analyse : la sortie du compilateur dans le contexte LLM

Condition de sécurité : La clé SSH générée dans le conteneur doit être ajoutée sur l'hôte dans authorized_keys. La communication se fait exclusivement via les flux standard (stdin, stdout, stderr) – sans transfert de fichiers.

Adressage cohérent des chemins (FQN)

Afin d'éviter des incohérences de chemins entre poste de travail, conteneur et hôte de scripts, les partages du serveur de fichiers sont montés aux mêmes points de montage sur tous les systèmes. 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 le poste de travail
• Il suit la progression de l'agent en temps réel sur son smartphone via VPN
• Aucun blocage mutuel – l'hôte de scripts ouvre des processus shell séparés 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 les partages dans un environnement basé sur 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, passerelle S3 ou GCSYNC)
3. Validation des politiques – GCPN définit les règles d'accès (OPA/Rego) ; Nextcloud ne fait que 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 (enfreint le stockage natif Git)
• Extensions Nextcloud propriétaires (enfreint les principes OSS)
• Absence d'intégration Git (Nextcloud doit pouvoir accéder aux dépôts Git)

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