Axe 1 : Fondamentaux

Git-native Compliance

La thèse centrale du GCBoK :

La Git-native Compliance signifie que tous les artefacts de conformité, décisions, identités et preuves vivent principalement dans des dépôts Git — versionnés, signés GPG, lisibles par machine au format OSCAL, validables par OPA — sans nécessiter de store de conformité secondaire.

Positionnement dans le spectre des paradigmes

Les trois piliers de la Git-native Compliance

1. Ancrage cryptographique - Chaque entrée dans un dépôt Git est sécurisée par un hash, éventuellement avec des signatures GPG. Cela permet de prouver : qui, quoi, quand. Cela correspond aux exigences GoBD en matière d'immuabilité — mais de manière native, grâce à l'architecture Git.

2. Lisibilité par machine - OSCAL (Open Security Controls Assessment Language) pour les contrôles de sécurité et les résultats d'évaluation. OPA/Rego (Open Policy Agent) pour les règles de conformité sous forme de code, vérifiées automatiquement par rapport à l'état Git.

3. Déterminisme par V7GUID - Chaque objet de conformité est adressable de manière globalement unique (UUIDv7), triable dans le temps (horodatage 48 bits), classifiable (identifiant de classe 14 bits) et chaînable dans des chaînes de preuves.

Délimitation : patrimoine de conformité et consignes privées

La Git-native Compliance a une portée volontairement étroite : dans les dépôts Git d'une entreprise se trouvent les artefacts pertinents pour la conformité — justificatifs, décisions, preuves et référentiels nécessaires au contrôle et à la traçabilité. Ce qui n'est pas pertinent pour la conformité n'a pas sa place dans ce patrimoine.

Cela exclut expressément la collecte des consignes personnelles de la personne qui accorde les validations (ci-après « HITL » – Human In The Loop) : ses appréciations privées, opinions, pondérations et critères d'arbitrage. De telles collections constituent des informations privées protégées et ne sont donc pas versionnées — généralement localement dans un répertoire de son propre contexte de travail exclu via .gitignore (modèle : projections/) — et ne sont pas reprises dans la documentation de conformité.

Elles ne sont toutefois pas dépourvues d'importance : c'est à partir d'elles que naissent les modèles d'ADR, les documentations de décision et autres faits qui, ensuite — et seulement ensuite — sont pertinents pour la conformité et ont leur place dans les dépôts. Ce qui est documenté, c'est le résultat, pas l'évaluation.

Mémento pour les agents : Les consignes privées du HITL doivent être respectées — elles façonnent les attentes, le ton, les délimitations et les priorités. Elles ne doivent être ni documentées ni citées, que ce soit dans le texte courant ou dans les documents de décision, les justificatifs ou les rapports — sauf si le HITL les autorise expressément à être documentées.

Complément : axe 5 (Procédures), section « Consignes privées du HITL – convention et règle pour les agents », et axe 7 (Gouvernance), section « De l'appréciation privée au résultat justifiable ».

Auto-référencement sans Vendor Lock-In

La Git-native Compliance est auto-référentielle : tous les éléments GitCover — sources, références, mesures, documents — sont adressés et gérés exclusivement via des dépôts Git. La vérité réside dans le .git lui-même (commits, trees, hashes), et non dans des services externes, wikis ou tickets. Cela évite le Vendor Lock-In : chaque dépôt est, en soi, auditable, portable et sans dépendances propriétaires.

Standard de hachage : toujours SHA-256, jamais SHA-1

Chaque dépôt GitCover est initialisé avec SHA-256 comme fonction de hachage d'objets (git init --object-format=sha256 ou extensions.objectformat = sha256). SHA-1 est explicitement interdit (attaques par collision). L'ancrage cryptographique (pilier 1) repose ainsi sur un standard de hachage dont la sécurité est démontrée.

Emplacement des outils GitCover

Tous les outils, services et (à l'avenir) serveurs MCP GitCover sont placés conformément au plan sous /opt/GitCover/ (par ex. le CLI WebStaticBuilder sous /opt/GitCover/webstatic). Cela évite les stockages non versionnés à l'échelle du système. Après l'onboarding, /opt/GitCover devient lui-même un dépôt Git qui documente, avec versionnement, les paramètres d'environnement conformes aux GoBD (BASE_URL, CDN, chemins, versions des outils).

La conformité comme infrastructure

GitCover n'est pas un outil pour les passionnés de conformité. C'est une infrastructure pour toutes celles et ceux qui veulent traiter la conformité. Cela signifie :

• Coûts les plus faibles possibles - open source, aucune licence propriétaire
• Sécurité maximale - ancrage cryptographique, et non par des couches logicielles
• Traçabilité complète - l'historique Git comme piste d'audit intégrée

Modèle d'architecture : applications métier verticales et backbone de conformité horizontal

Lecture : Les applications métier verticales (FiBu, saisie des temps, paie, ERP, stockage) restent indépendantes sur le plan du contenu et autonomes sur le plan métier. GitCover constitue la couche horizontale : des dépôts Git comme backbone de conformité continu, qui relie chaque application verticale à des catalogues OSCAL, des politiques OPA, des signatures GPG et des chaînes de preuves V7GUID — sans middleware propriétaire et sans store de conformité secondaire.

Cadre juridique

Le GCBoK traite les cadres réglementaires suivants :

GoBD - principes d'une comptabilité appropriée pour les systèmes comptables informatisés

Les GoBD (marges 151-157) exigent un système de contrôle interne, la traçabilité, l'immuabilité et la conformité temporelle. La Git-native Compliance satisfait nativement à ces exigences :

NIS2 - Network and Information Security Directive

La directive européenne NIS2 exige la gestion des risques et des obligations de notification pour les infrastructures critiques. Le GCBoK définit des méthodes d'analyse des risques NIS2 sur la base de dépôts Git.

AI Act - règlement (UE) 2024/1689

Le règlement sur l'IA (AI Act) régule les systèmes d'IA selon une approche fondée sur les risques (interdits / à haut risque / à risque limité / à risque minimal) et exige, pour les systèmes à haut risque, notamment des données d'entraînement documentées, des preuves du cycle de vie des modèles, une supervision humaine et une documentation des incidents. Positionnement git-native : le GCBoK ne fournit pas de systèmes d'IA et ne les certifie pas non plus — il rend les preuves (origine des données d'entraînement, versions des modèles/prompts, validations, incidents) reproductibles sous forme d'artefacts Git. La Git-native Compliance est donc une infrastructure de preuve pour les obligations de l'AI Act, et non une présomption de conformité pour le système d'IA lui-même.

Cyber Resilience Act (CRA) - règlement (UE) 2024/2847

Le CRA oblige les fabricants de produits comportant des éléments numériques à appliquer la sécurité dès la conception, la gestion des vulnérabilités et des obligations de notification (délais de notification à partir de l'automne 2026, exigences produit à partir de fin 2027). Positionnement git-native : les simples dépôts Git et utilitaires OSS ne sont en règle générale pas des « produits comportant des éléments numériques » au sens du CRA ; un produit connecté (par ex. une distribution basée sur serveur) peut être concerné. La Git-native Compliance soutient les preuves CRA (SBOM, historique des vulnérabilités/correctifs, documentation de conformité), mais ne remplace pas le marquage CE.

Data Act - règlement (UE) 2023/2854

Le Data Act établit des obligations de mise à disposition et de portabilité des données pour les produits connectés et les services associés (obligations produit notamment à partir du 12.09.2026), ainsi que des règles sur le changement de fournisseur cloud. Positionnement git-native : les dépôts Git sont portables by design (clone/mirror/export) — la Git-native Compliance soutient la préparation au Data Act (export dans des formats ouverts : JSON, CSV, OSCAL), mais ne fonde pas une conformité générale du système global au Data Act.

eIDAS 2.0 - règlement (UE) 2024/1183

eIDAS 2.0 crée le European Digital Identity Wallet et élargit les services de confiance qualifiés. Positionnement git-native : GitCover s'interface avec les signatures Wallet/Trust (conteneurs de signature, GCSIG, facsimile), sans les remplacer ; les FES/QES restent des services de confiance fournis en externe.

RGPD/GDPR - règlement (UE) 2016/679

Le RGPD exige la protection de la vie privée dès la conception (Privacy by Design). Le GCBoK définit des preuves d'identité décentralisées (y compris des identités PGP), qui ancrent les données personnelles non pas dans des bases de données centrales, mais dans des structures Git ; les PII sont conservées dans des dépôts séparés (pas dans Git) (responsabilité à deux niveaux, voir axe 4).

Délimitation : infrastructure de preuve vs conformité produit

Clarification centrale (canonique) : le GCBoK est un recueil normatif de connaissances et de preuves. Les actes juridiques de l'UE mentionnés (AI Act, CRA, Data Act, eIDAS 2.0, RGPD) sont des cadres pour lesquels la Git-native Compliance fournit des preuves. GitCover n'est pas fabricant d'un système régulé d'IA/produit/confiance et ne délivre aucune déclaration de conformité pour des tiers. La responsabilité de la conformité juridique du système utilisé reste celle de l'exploitant (cf. GoBD Rn. 21 ; matrice de responsabilités dans gitcover.de/rechtliches).

BSI GS++ & GCBoK Compliance-as-Code

Le compendium BSI IT-Grundschutz définit des standards de sécurité de l'information et les met de plus en plus à disposition dans des formats lisibles par machine (comme OSCAL). Le GCBoK utilise ces catalogues OSCAL standardisés et mappe directement les contrôles BSI sur des processus de conformité automatisés et Git-native (Compliance-as-Code). Il transforme les exigences réglementaires du BSI en routines de contrôle opérationnalisables au sein de l'écosystème GitCover.

Compréhension de l'usage

Les principes d'architecture du GCBoK doivent être accessibles aux utilisateurs ayant peu de connaissances en informatique. Cette section présente les modèles mentaux qui rendent le travail avec la Git-native Compliance compréhensible pour les non-spécialistes.

Files over Apps - principe directeur

Le GCBoK suit le principe directeur Files over Apps : les artefacts de conformité vivent sous forme de fichiers dans des dépôts Git, et non dans des bases de données applicatives propriétaires. Les conversations, documents, justificatifs et politiques sont des fichiers Markdown, YAML ou JSON dans l'arbre Git — versionnés, signables, auditables. Les applications sont interchangeables ; les fichiers sont durables.

Cela diffère fondamentalement du paradigme applicatif classique, dans lequel un logiciel conserve les données dans ses propres bases de données et où l'export est une nécessité a posteriori. Avec la Git-native Compliance, l'export est l'état normal.

Le classeur numérique - modèle mental

Pour les utilisateurs ayant peu de connaissances informatiques, le concept d'un système de fichiers complet est abstrait et source d'erreurs. La métaphore du classeur numérique résout ce problème :

• Le répertoire de travail Git n'est pas un dossier PC encombré, mais un classeur numérique avec copieur et registre intégrés (Git).
• La règle : un agent IA ne peut lire et écrire que dans ce dossier spécifique. Tout ce qui se trouve à l'extérieur n'existe pas pour lui.
• La visibilité : chaque modification effectuée par l'IA est immédiatement signalée comme modification (Git-Status). Le non-spécialiste voit : « L'IA a modifié la ligne 4 de la documentation de procédure. »
• La sécurité : la zone de staging Git devient une fenêtre de prévisualisation et de validation. L'utilisateur n'a pas besoin de comprendre Git — il comprend le principe : « L'IA propose une modification, je clique sur Accepter (Commit). »

Principe du bac à sable

Pour la conformité GoBD et NIS2, la délimitation de la zone d'accès est fondamentale. Un agent IA qui ne peut accéder qu'au répertoire de travail Git qui lui est attribué est physiquement enfermé :

• Même si l'agent hallucine ou est manipulé par injection de prompt, il ne peut pas s'échapper du dépôt Git.
• L'explication pour l'utilisateur : « L'IA est enfermée dans ce dossier de projet. Elle ne peut causer aucun dommage dans le reste du système. »
• Chaque activité de conformité est documentée dans l'historique Git comme filet de sécurité — l'utilisateur conserve toute sa souveraineté.

Environnements de travail pour l'IA en comparaison

Le GCBoK est neutre sur le plan technologique concernant l'environnement de travail de l'IA. Trois paradigmes sont disponibles :

Recommandation : modèle d'appliance hybride

Pour les utilisateurs de PME sans connaissances informatiques approfondies, le GCBoK recommande un modèle d'appliance hybride :

1. Encapsulation de l'infrastructure (centralisée) : un serveur d'IA headless dans le LAN prend en charge l'inférence LLM et la gestion Git. La complexité est entièrement déplacée vers celui-ci.
2. Poste de travail client minimal : on n'impose à l'utilisateur final ni Docker local, ni Python, ni Git sur son poste. Il accède exclusivement à l'interface web via le navigateur (en tant que PWA).
3. Flux d'interaction : l'utilisateur utilise les fonctions de chat et de notes. Lorsqu'il souhaite vérifier ou générer des documents de conformité, l'agent IA travaille en arrière-plan directement sur les répertoires du serveur de fichiers central. L'agent prend en charge le staging, le commit et le push vers le dépôt Gitea — l'utilisateur voit une checklist visuelle dans l'UI.

L'objectif : l'utilisateur ne perçoit pas une « IA qui contrôle l'ordinateur », mais un gestionnaire de dossier intelligent pour le dossier de conformité spécifique. Il sait où l'IA travaille, voit chaque étape dans l'historique Git et conserve toute la souveraineté exigée par le GCBoK.

Architecture de référence : modèle d'appliance hybride

Voir aussi : la mise en œuvre pratique de ces cadres est décrite dans Axe 5 : Procédures.