Axe 1 : Fondements

Git-native Compliance

La thèse centrale du GCBoK :

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 via OSCAL, validables par OPA - sans nécessiter de magasin 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 rend démontrable : Qui, Quoi, Quand. Cela correspond aux exigences de la GoBD en matière d'inaltérabilité - 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é en tant que code, vérifiées automatiquement par rapport à l'état Git.

3. Déterminisme grâce au 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 en chaînes de justificatifs.

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, des wikis ou des tickets. Cela évite le Vendor Lock-In : chaque dépôt est en soi inaltérable, 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'objets (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 prouvé sûr.

Emplacement des outils GitCover

Tous les outils, services et (à l'avenir) serveurs MCP de GitCover sont stockés conformément au plan sous /opt/GitCover/ (p. ex. la CLI WebStaticBuilder sous /opt/GitCover/webstatic). Cela évite les emplacements système non versionnés. Après l'onboarding, /opt/GitCover devient lui-même un dépôt Git qui documente de manière versionnée les paramètres d'environnement conformes à la 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 faibles possibles - Open Source, aucune licence propriétaire
• Sécurité maximale - Ancré 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 (comptabilité financière, gestion des temps, paie, ERP, stock) restent indépendantes sur le fond 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 aux catalogues OSCAL, aux politiques OPA, aux signatures GPG et aux chaînes de justificatifs V7GUID - sans middleware propriétaire et sans magasin de conformité secondaire.

Cadre juridique

Le GCBoK aborde les cadres réglementaires suivants :

GoBD - Principes des systèmes de comptabilité régulière assistés par informatique

La GoBD (Rz. 151-157) exige un système de contrôle interne, la traçabilité, l'inaltérabilité et le respect des délais. La Git-native Compliance satisfait ces exigences de manière native :

NIS2 - Network and Information Security Directive

La directive NIS2 de l'UE exige une 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.

BSI GS++ & GCBoK Compliance-as-Code

Le BSI IT-Grundschutz-Kompendium définit des normes 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 les contrôles BSI directement sur des processus de conformité Git-native automatisés (Compliance-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 le Privacy by Design. Le GCBoK définit des preuves d'identité décentralisées (également des identités PGP), qui ancrent les données à caractère personnel non pas dans des bases de données centralisées, mais dans des structures Git.

Compréhension de l'application

Les principes d'architecture du GCBoK doivent être tangibles pour les utilisateurs ayant de faibles connaissances en informatique. Cette section transmet les modèles mentaux qui rendent le travail avec la Git-native Compliance compréhensible pour les profanes.

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'arborescence 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'exportation constitue une nécessité ultérieure. Avec la Git-native Compliance, l'exportation 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 sujet aux 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 confus, mais un classeur numérique avec copieur intégré et registre (Git).
• La règle : un agent d'IA n'a le droit de lire et d'é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 marquée comme modification (statut Git). Le profane voit : « L'IA a modifié la ligne 4 de la documentation des procédures. »
• La sécurité : la zone de staging Git devient une fenêtre d'aperçu et de validation. L'utilisateur n'a pas besoin de comprendre Git - il comprend le principe : « L'IA propose une modification, je clique sur Appliquer (Commit). »

Principe du bac à sable

Pour la conformité GoBD et NIS2, la délimitation du périmètre d'accès est fondamentale. Un agent d'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 Prompt-Injection, 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é.

Comparaison des environnements de travail IA

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

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 (centrale) : 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 à cet endroit.
2. Poste de travail client minimal : l'utilisateur final n'a pas à se soucier de Docker local, de Python ou de Git sur son poste. Il accède exclusivement à l'interface web via le navigateur (sous forme de PWA).
3. Flux d'interaction : l'utilisateur utilise les fonctions de chat et de notes. S'il souhaite vérifier ou générer des documents de conformité, l'agent d'IA travaille en arrière-plan directement sur les répertoires du serveur de fichiers central. L'agent effectue le staging, le commit et le push vers le dépôt Gitea - l'utilisateur voit une liste de contrôle visuelle dans l'UI.

L'objectif : l'utilisateur ne vit pas une « IA qui pilote l'ordinateur », mais un gestionnaire intelligent dédié au dossier de conformité spécifique. Il sait où l'IA travaille, voit chaque étape dans l'historique Git et conserve la pleine souveraineté qu'exige 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 : Démarches.