Axe 3 : Composants
Aperçu
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 et métadonnées .v7g.md. 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 auditables (prédécesseur/successeur) pour les documents commerciaux. Le terme historique PrimaNota désigne une clé d'ordonnancement qui attribue à une opération commerciale - par ex. une écriture de la comptabilité en partie double ou une opération comptable en plusieurs parties (créance, TVA, répartition centre de coûts/porteur de coûts) - une clé unique d'appartenance. GCPN transpose ce principe sur 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 avec ses documents prédécesseurs et successeurs.
Le chaînage s'effectue de manière non chronologique : un document saisi plus tard peut être inséré comme prédécesseur (Predecessor-Insert) dans une chaîne existante - déterminant pour GoBD Rz. 80 (contrôle progressif et rétrograde). Les champs Match-Key (numéro de commande, débiteur, montant brut, etc.) permettent une association automatique de chaînes sans attribution manuelle.
Le format .v7g.md sépare la partie lisible par l'homme en haut (titre, tableaux, prose) de l'artefact de données en bas (JSON-Code-Fence) ; JSON est à préférer au YAML comme support de données (JSON-First). Le fichier se trouve 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 de traitement 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 de l'opération au lieu de fichiers individuels
Pour les opérations de signature, GCPN se concrétise sous la forme d'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 conteneur est complété à chaque nouvelle étape de processus ; les artefacts JSON déjà intégrés (schéma
gcpn-container-2.4, self-contained et compatible Tree :referenced_doc,actor,retentiondécrits une fois chacun ;eventscomme Flags-Enum avec bitmaskevents_result; Tree viaparents[]/children[]/documents[];summary— les artefacts JSON intégrés restent inchangés). - Sécurité d'audit par Git : l'historique du conteneur (quelles étapes ont été ajouté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 JSON-Bloat : les artefacts JSON sont toujours intégrés (MD-Fence) — pas de fichiers
.jsonautonomes dans l'arborescence du dépôt. - Fonction d'index GCDMS : dans le DMS optionnellement rattaché, le conteneur sert d'index — navigation de processus vers les documents individuels et vers la description du processus, au lieu de n8n ou de moteurs de workflow similaires.
- Transition Immutable : un Referenced-Doc signé devient ensuite immutable ; 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 Signature numérique, DS02–DS05).
Protection par modèle d'utilité : Az 20 2026 000 272.7 - en vigueur. Objet protégé : structure de données de conteneur pour la gestion de documents commerciaux basée sur UUIDv7 et sécurisée pour l'audit, 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 IA, validateurs de politiques et systèmes d'audit — avec adressage V7GUID déterministe des objets de contexte. GCUCB adresse le problème de surcoût de coordination des workflows d'agents à plusieurs étapes (coûts de sérialisation et de tokens du transfert de contexte) par un bus typé et directement adressable au lieu de couches intermédiaires basées sur du texte.
OPA/Rego agit comme couche de garde-fou déterministe : le contrôle des politiques résulte d'un ensemble de règles, non du prompt-engineering.
La situation en matière de droits de protection (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 que sous forme générale jusqu'à leur publication.
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é traite actuellement la même problématique de fond — les agents ont besoin d'un contexte d'entreprise cohérent et lisible par 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, pas d'une architecture de transport runtime.
GCUCB aborde la même problématique au niveau du transport et de l'accès : objets de contexte typés, adressage V7GUID déterministe, couplage preuve et politique au runtime. La distinction terminologique claire est intentionnelle : une ontologie décrit ce que les termes signifient (chez GitCover : les dictionnaires L1–L6, voir Concepts : hiérarchie métier comme ontologie) ; GCUCB détermine comment les agents, validateurs et systèmes d'audit y accèdent au runtime. Les 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 si elle vit de manière Git-native dans le dépôt.
GCEP - GitCover Exchange Protocol
Protocole d'échange instance à instance entre dépôts Git sur différents supports. Sémantiquement déterminé par des catalogues OSCAL et des hooks/callbacks définis par OPA.
IETF-Track prévu (I-D, forme courte : 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 IA. Tous trois résolvent des problèmes différents à des niveaux différents :
(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 (par 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 |
La combinaison est hautement pertinente pour le management : l'agent travaille via ACP/MCP à grande vitesse ; GCEP garantit, au niveau du 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 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 opérateur 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 l'écriture | Le système d'exploitation impose le verrou de manière stricte |
| Comportement en cas de timeout | L'agent peut réagir stratégiquement : décaler un sous-objectif, émettre une notification UI | Souvent des états système bloqués (deadlocks) |
| Adéquation pour les agents IA | Élevée - l'agent interroge l'état du verrou au préalable (par ex. via un serveur Git MCP) | Faible - bloque le pipeline de l'agent |
Un agent IA peut interroger au préalable l'état du verrou GCEP (« Ce dépôt est-il verrouillé pour un autre site d'exploitation ? ») et adapter sa planification en conséquence - au lieu de bloquer de manière stricte.
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. Condition préalable pour GCEP : avant que deux instances n'échangent des données, un verrou doit garantir un transfert atomique.
GCSYNC - GitCover Sync
Canal outbound de GitCover vers d'autres systèmes de stockage de données. Fournit des données pour les systèmes RAG, les serveurs MCP et les Nextcloud Shares.
Voir aussi : droits de protection et statut des brevets dans Droits de protection. Reconnaissance de la recherche dans Projets de recherche.