Axe 3 : Composants

Vue d'ensemble

Le GCBoK définit six composants centraux du stack GitCover :

GCDMS - GitCover Document Management System

Système de gestion des preuves et des documents basé sur des conteneurs .v7g.md et leurs métadonnées. Chaîne d'outils : v7g-pack, v7g-verify, v7g-sign, v7g-export.

GCPN - GitCover PrimaNota

Mécanisme de métadonnées pour la formation de chaînes de preuves à l'épreuve des audits (prédécesseur/successeur) pour les documents d'affaires. Le terme historique PrimaNota désigne une clé de classement qui attribue à une opération d'affaires - p. ex. une écriture de la comptabilité en partie double ou un processus comptable en plusieurs parties (créance, TVA, répartition centre de coûts/support de coûts) - une clé unique marquant l'appartenance. GCPN transpose ce principe sur une base UUIDv7 : chaque document reçoit un identifiant ordonné dans le temps (RFC 9562) et est chaîné, via des références Predecessor/Successor, à ses documents prédécesseurs et successeurs.

Le chaînage s'effectue de manière non chronologique : un document saisi ultérieurement peut être inséré comme prédécesseur (Predecessor-Insert) dans une chaîne existante - décisif pour GoBD Rz. 80 (vérification progressive et rétrograde). Les champs Match-Key (numéro de commande, débiteur, montant brut, etc.) permettent une association automatique des chaînes sans affectation manuelle.

Le format de conteneur .v7g.md combine des métadonnées lisibles par l'humain (YAML + Markdown) avec des données d'affaires exploitables par la machine (JSON intégré) et est stocké dans des dépôts Git dont le hash de commit sert de preuve d'intégrité cryptographique.

Domaines d'application au-delà de la comptabilité : registres des traitements RGPD (Art. 30), chaînes d'incidents NIS2, décisions d'architecture MADR, cycle de vie des jetons OIDC/OAuth, OSCAL-Assessment-Results.

Conteneur de signature GCPN (`.gcpn.md`) — accompagnement du processus plutôt que fichiers individuels

Pour les opérations de signature, GCPN se concrétise comme un Prozess-Ur-Doc autonome : un fichier .gcpn.md à côté du Referenced-Doc (convention de nommage <Referenced-Doc-Basisname>.gcpn.md) accompagne le processus de création et de signature — il n'est pas le sidecar du Referenced-Doc, mais le conteneur de processus.

Conception essentielle :

Mutable Doc, artefacts JSON immuables : le MD du conteneur est complété à chaque nouvelle étape du processus ; les artefacts JSON déjà intégrés (schéma gcpn-container-1.0 : referenced_doc, actor, retention décrits chacun une seule fois ; events comme Flags-Enum avec masque de bits events_result, p. ex. 11 = offered + accepted + sign ; summary) restent inchangés.
Sécurité d'audit grâce à Git : l'historique du conteneur (quelles étapes ont été complétées, et quand) se trouve dans l'historique Git du dépôt — le hash de commit sert de preuve d'intégrité cryptographique.
Pas de gonflement JSON : les artefacts JSON sont toujours intégrés (MD-Fence) — pas de fichiers .json autonomes dans l'arborescence du dépôt.
Fonction d'index GCDMS : dans le DMS optionnellement raccordé, le conteneur sert d'index — navigation de processus vers les docs individuels et vers la description du processus, au lieu de n8n ou de moteurs de workflow similaires.
Passage à l'immuable : un Referenced-Doc signé devient ensuite immuable ; le conteneur reste mutable et continue de documenter le processus (historique Git = preuve).

Première utilisation : signature GVB avec signature fac-similé (partie I de la Signature numérique, DS02–DS05).

Protection par modèle d'utilité : dossier n° 20 2026 000 272.7 - en vigueur. Objet protégé : structure de données de conteneur pour une gestion de documents d'affaires basée sur UUIDv7, à l'épreuve des audits, avec chaînage dynamique Predecessor/Successor. Demande de brevet déposée (47 revendications).

GCUCB - GitCover Unified Context Bus

Bus de contexte pour la coordination runtime entre agents d'IA, validateurs de politiques et systèmes d'audit — avec adressage déterministe des objets de contexte par V7GUID. GCUCB répond au problème de surcharge de coordination des workflows d'agents multi-étapes (coûts de sérialisation et de tokens du transfert de contexte) par un bus typé, directement adressable, au lieu de couches intermédiaires textuelles.

OPA/Rego sert de couche de garde-fous déterministe : la vérification des politiques naît d'un ensemble de règles, et non du prompt engineering.

La situation des droits de propriété (modèle d'utilité, dépôt DPMA 260909) est ancrée ; les caractéristiques concrètes d'architecture et de procédé sont décrites dans les documents de dépôt et ne sont présentées ici, jusqu'à publication, que sous une forme générale.

Délimitation

Composant	Couche	Délimitation par rapport à GCUCB
GCEP	Persistance (Git-to-Git)	Instance-à-instance ; GCUCB = bus runtime
GCSYNC	Outbound (Git -> RAG)	Canal externe ; GCUCB = bus interne
GCPN	Logique de chaînage	Chaînes de preuves (prédécesseur/successeur) ; GCUCB = transport/accès

Contexte de marché : « Ontology » n'est pas GCUCB

Le marché aborde actuellement la même problématique fondamentale — les agents ont besoin d'un contexte d'entreprise cohérent et lisible par la machine — sous le terme « Ontology » : Microsoft, par exemple, fournit avec « Fabric IQ » (Preview) un « governed, self-service knowledge graph » comme couche sémantique que les agents consomment comme « shared context layer » (Entity types, Relationships, GQL-Graph, OneLake-Bindings). Il s'agit d'une couche de données et de sémantique, et non d'une architecture de transport à l'exécution.

GCUCB s'attaque à la même problématique au niveau du transport et de l'accès : objets de contexte typés, adressage V7GUID déterministe, couplage des preuves et des politiques à l'exécution. La séparation claire des termes est délibérée : une ontologie décrit ce que les termes signifient (chez GitCover : les dictionnaires L1–L6, voir Concepts : hiérarchie d'entreprise comme ontologie) ; GCUCB détermine comment les agents, les validateurs et les systèmes d'audit y accèdent à l'exécution. Ces deux niveaux se complètent — GCUCB n'est pas un produit d'ontologie, et l'ontologie n'a pas besoin d'un graphe de plateforme quand elle vit nativement dans Git au sein du dépôt.

GCEP - GitCover Exchange Protocol

Protocole d'échange d'instance à instance entre dépôts Git sur des supports différents. Sémantique déterminée par des catalogues OSCAL et des hooks/callbacks définis par OPA.

Piste IETF prévue (I-D, forme abrégée : gcep). Demande de brevet : 10 2025 003 359.1.

Niveaux de protocole : ACP, MCP et GCEP

GCEP ne doit pas être confondu avec les protocoles d'agents d'IA. Les trois résolvent des problèmes différents à des niveaux différents :

graph TD A["Präsentations-Ebene / UI
(z. B. VS Code)"] -->|"Agent Client Protocol (ACP)"| B["Logik-Ebene / KI-Agent"] B -->|"Model Context Protocol (MCP)"| C["Infrastruktur- & Daten-Ebene"] C -->|"GitCover Exchange Protocol (GCEP)
mit Advisory Locks"| D["Verteilte Git-Server / VCS"] style A fill:#bbdefb style B fill:#c8e6c9 style C fill:#ffe0b2 style D fill:#f8bbd0

Niveau	Protocole	Direction	Objectif
Pont UI	ACP (Agent Client Protocol)	UI ↔ Agent	Relie l'interface utilisateur (p. ex. VS Code) à la logique de l'agent
Pont de contexte IA	MCP (Model Context Protocol)	Agent ↔ Données	Accès structuré de l'agent aux sources de données (documents, outils)
Niveau dépôt	GCEP	Serveur ↔ Serveur	Réplication, synchronisation et sauvegarde de l'état entre instances Git physiques

Cette combinaison est hautement pertinente pour le management : l'agent travaille via ACP/MCP à grande vitesse ; GCEP garantit, au niveau dépôt sous-jacent, que les chemins de commit et de synchronisation restent cohérents.

Advisory Locks à l'ère de l'IA

Les agents d'IA autonomes génèrent des accès en écriture à haute fréquence. Sans protocole de verrouillage au niveau Git, deux agents agissant en parallèle - ou un agent et un gestionnaire humain - peuvent modifier simultanément les mêmes dépôts et produire des états incohérents (Race Conditions).

Aspect	Advisory Lock	Mandatory Lock
Mécanisme d'action	Les processus vérifient volontairement l'état du verrou avant d'écrire	Le système d'exploitation impose le verrou de manière stricte
Comportement en cas de timeout	L'agent peut réagir de manière stratégique : déplacer le sous-objectif, émettre une notification UI	Souvent des états système bloqués (Deadlocks)
Adéquation pour les agents d'IA	Élevée - l'agent interroge l'état du verrou au préalable (p. ex. via un serveur MCP-Git)	Faible - bloque le pipeline de l'agent

Un agent d'IA peut interroger au préalable l'état de verrouillage GCEP (« Ce dépôt est-il verrouillé pour un autre établissement ? ») et adapter sa planification en conséquence - au lieu de se bloquer de manière rigide.

GCAL - GitCover Advisory Lock

Mécanisme de verrou distribué entre dépôts Git - analogue au PostgreSQL Advisory Lock, mais au niveau du dépôt. Prérequis pour GCEP : avant que deux instances n'échangent des données, un verrou doit garantir un transfert atomique.

GCSYNC - GitCover Sync

Canal sortant (outbound) depuis GitCover vers d'autres systèmes de stockage de données. Met des données à disposition des systèmes RAG, des serveurs MCP et des Nextcloud Shares.

Voir aussi : droits de propriété et statut des brevets dans Droits de propriété. Reconnaissance de recherche dans Projet de recherche.