Axe 1 : Fondamentaux

Conformité native Git

La thèse centrale du GCBoK :

La conformité native Git 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 magasin de conformité secondaire.

Positionnement dans le spectre des paradigmes

Les trois piliers de la conformité native Git

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, automatiquement vérifiées par rapport à l'état Git.

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

Délimitation : inventaire de conformité et prescriptions privées

La conformité native Git 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 corpus de règles nécessaires à l'audit et à la traçabilité. Ce qui n'est pas pertinent pour la conformité n'a pas sa place dans cet inventaire.

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

Elles ne sont pas pour autant dénuées de sens : c'est à partir d'elles que naissent d'abord les modèles d'ADR, les documentations de décision et autres faits, qui sont alors – et seulement alors – pertinents pour la conformité et ont leur place dans les dépôts. C'est le résultat qui est documenté, non l'évaluation.

Aide-mémoire pour les agents : les prescriptions 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 pas être documentées ni citées, ni dans le corps du texte, ni 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 « Prescriptions 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 verrouillage propriétaire

La conformité native Git est auto-référençante : 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 verrouillage propriétaire : chaque dépôt est, à lui seul, auditable, portable et exempt de 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'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 dont la sûreté est démontrée.

Emplacement des outils GitCover

Tous les outils, services et (à l'avenir) serveurs MCP GitCover sont stockés conformément au plan sous /opt/GitCover/ (par ex. le CLI WebStaticBuilder sous /opt/GitCover/webstatic). Cela évite les stockages à l'échelle du système et 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 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 aussi bas que possible – 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 dorsale de conformité horizontale

Lecture : Les applications métier verticales (FiBu, saisie des temps, paie, ERP, gestion des stocks) 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 dorsale de conformité continue, qui relie chaque application verticale à des catalogues OSCAL, des politiques OPA, des signatures GPG et des chaînes de justificatifs V7GUID – sans intergiciel propriétaire et sans magasin de conformité secondaire.

Cadre juridique

Le GCBoK aborde les cadres réglementaires suivants :

GoBD – Principes d'une tenue de comptabilité conforme assistée par informatique

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

NIS2 – directive sur la sécurité des réseaux et de l'information

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 fondées sur des 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 de cycle de vie du modèle, une surveillance humaine et une documentation des incidents. Positionnement native Git : 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 en tant qu'artefacts Git. La conformité native Git est donc une infrastructure de preuve pour les obligations de l'AI Act, et non une présomption de conformité du 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 native Git : les dépôts Git purs et les 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 conformité native Git prend en charge 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 native Git : les dépôts Git sont portables by design (clone/mirror/export) — la conformité native Git favorise la préparation au Data Act (export dans des formats ouverts : JSON, CSV, OSCAL), mais ne fonde pas une conformité globale du système dans son ensemble 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 native Git : GitCover se raccorde aux 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 corpus 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 conformité native Git 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 mis en œuvre 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 IT-Grundschutz du BSI 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 directement les contrôles BSI sur des processus de conformité natifs Git automatisés (Compliance-as-Code). Il transforme les prescriptions 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 architecturaux 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 conformité native Git 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 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.

Les artefacts GitCover portent une famille d'extensions fermée : .gc.md (sidecar générique et artefact Markdown normalisé), .gcpn.md (conteneur de dossier), .gcsig.md (artefact de signature), .gcadr.md (décision d'architecture) ainsi que .gc.json/.gc.xml (artefacts de données). La V7GUID reste l'identité en tant que v7guid dans le contenu ; le nom de fichier ne la porte pas. La découverte passe par le registre fermé plus les métadonnées obligatoires, et non par un glob large.

Cela se distingue 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 conformité native Git, 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 désordonné, mais un classeur numérique doté d'un copieur et d'un journal 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 en dehors n'existe pas pour lui.
• La visibilité : chaque modification effectuée par l'IA est immédiatement signalée comme une 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 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 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 exclusivement qu'au répertoire de travail Git qui lui est attribué est physiquement enfermé :

• Même si l'agent hallucine ou est manipulé par une 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é.

Comparaison des environnements de travail pour l'IA

Le GCBoK est neutre sur le plan technologique en ce qui concerne 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 de travail. 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 liste de contrôle 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 la pleine 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.