Axe 1 : Fondements

Conformité Git-native

La thèse centrale du GCBoK :

La conformité Git-native 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 machine via OSCAL, validables par OPA - sans nécessiter de magasin de conformité secondaire.

Positionnement dans le spectre des paradigmes

Les trois piliers de la conformité Git-native

1. Ancrage cryptographique - Chaque entrée dans un dépôt Git est sécurisée par un hachage, optionnellement avec des signatures GPG. Cela permet de prouver : Qui, Quoi, Quand. Cela correspond aux exigences GoBD en matière d'intégrité - mais de manière native grâce à l'architecture Git.

2. Lisibilité 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é en tant que code, vérifiées automatiquement contre l'état Git.

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

Auto-référence sans verrouillage fournisseur

La conformité Git-native est auto-référencielle : 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, arbres, hachages), et non dans des services externes, des wikis ou des tickets. Cela évite le verrouillage fournisseur : chaque dépôt est en soi révisionnable, portable et sans dépendances propriétaires.

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

Chaque dépôt GitCover est créé avec SHA-256 comme fonction de hachage d'objet (git init --object-format=sha256 ou extensions.objectformat = sha256). SHA-1 est expressément interdit (attaques par collision). L'ancrage cryptographique (pilier 1) repose ainsi sur un standard de hachage démontré comme sûr.

Localisation des outils GitCover

Tous les outils, services et (à l'avenir) serveurs MCP GitCover sont stockés conformément au plan sous /opt/GitCover/ (par exemple, la CLI WebStaticBuilder sous /opt/GitCover/webstatic). Cela évite les stockages système non versionnés. Après l'intégration, /opt/GitCover devient lui-même un dépôt Git, documentant de manière versionnée les paramètres d'environnement conformes aux GoBD (BASE_URL, CDN, chemins, versions d'outils).

La conformité comme infrastructure

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

• Coûts les plus bas possibles - Open Source, aucune licence propriétaire
• Sécurité maximale - Ancrée cryptographiquement, 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, pointage, paie, ERP, entrepôt) restent indépendantes sur le plan du contenu et autonomes sur le plan métier. GitCover forme la couche horizontale : les dépôts Git comme backbone de conformité continu, reliant chaque application verticale avec des catalogues OSCAL, des politiques OPA, des signatures GPG et des chaînes de preuves V7GUID - sans middleware propriétaire et sans magasin de conformité secondaire.

Cadre juridique

Le GCBoK s'adresse aux cadres réglementaires suivants :

GoBD - Principes d'un système de comptabilité assisté par informatique dûment ordonné

Les GoBD (Rz. 151-157) exigent un système de contrôle interne, une traçabilité, une intégrité et une ponctualité. La conformité Git-native satisfait ces exigences de manière native :

NIS2 - Directive sur la sécurité des réseaux et des systèmes d'information

La directive NIS2 de l'UE exige la gestion des risques et les 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.

BSI GS++ & GCBoK Conformité-as-Code

Le compendium de protection de base informatique du BSI définit des normes de sécurité de l'information et les met de plus en plus à disposition dans des formats lisibles machine (tels qu'OSCAL). Le GCBoK utilise ces catalogues OSCAL standardisés et mappe les contrôles BSI directement sur des processus de conformité automatisés Git-natifs (Conformité-as-Code). Il transforme les exigences réglementaires du BSI en routines de vérification opérationnalisables au sein de l'écosystème GitCover.

RGPD - Règlement général sur la protection des données

Le RGPD exige la confidentialité par conception. Le GCBoK définit des preuves d'identité décentralisées (y compris les identités PGP) qui ancrent les données personnelles non dans des bases de données centralisées, mais dans des structures Git.

Compréhension par l'utilisateur

Les principes d'architecture du GCBoK doivent être accessibles aux utilisateurs ayant des connaissances informatiques limitées. Cette section transmet les modèles mentaux qui rendent le travail avec la conformité Git-native compréhensible pour les non-initiés.

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 d'applications propriétaires. Les conversations, documents, preuves et politiques sont des fichiers Markdown, YAML ou JSON dans l'arbre Git - versionnés, signables, auditable. Les applications sont interchangeables ; les fichiers sont durables.

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

Le dossier numérique - Modèle mental

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

• Le répertoire de travail Git n'est pas un dossier PC illisible, mais un dossier 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 est en dehors n'existe pas pour lui.
• La visibilité : Chaque modification effectuée par l'IA est immédiatement marquée comme modification (Git-Status). Le non-initié voit : « L'IA a modifié la ligne 4 de la documentation de procédure. »
• La sécurité : La zone de staging Git devient la fenêtre d'aperçu et d'approbation. L'utilisateur n'a pas besoin de comprendre Git - il comprend le principe : « L'IA propose une modification, je clique sur Appliquer (Commit). »

Principe bac à sable

Pour la conformité GoBD et NIS2, la limitation du périmètre d'accès est fondamentale. Un agent IA qui ne peut accéder qu'au répertoire de travail Git qui lui est assigné 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 la pleine souveraineté.

Environnements de travail IA en comparaison

Le GCBoK est technologiquement neutre concernant l'environnement de travail IA. Trois paradigmes sont proposés :

Recommandation : Modèle d'appliance hybride

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

1. Encapsulation de l'infrastructure (centralisée) : Un serveur IA headless dans le LAN prend en charge l'inférence LLM et la gestion Git. La complexité est entièrement déportée là-bas.
2. Poste client minimal : L'utilisateur final n'a pas à gérer de Docker local, de Python ou de Git sur son bureau. Il accède exclusivement via le navigateur (en tant que PWA) à l'interface Web.
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 liste de contrôle visuelle dans l'interface.

L'objectif : l'utilisateur ne vit pas une « IA qui pilote l'ordinateur », mais un gestionnaire intelligent pour le dossier de conformité spécifique. Il sait où l'IA travaille, voit chaque étape dans l'historique Git et conserve la pleine souveraineté que le GCBoK exige.

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