Axe 3 : Composants
Vue d'ensemble
Le GCBoK définit six composants principaux de la stack GitCover :
GCDMS - GitCover Document Management System
Système de gestion des preuves et des documents pour les dépôts Git. Le stockage suit la famille d'extensions .gc.* : sidecar générique <artefakt>.<orig-ext>.gc.md, conteneur d'opération .gcpn.md, artefact de signature .gcsig.md, artefact de données .gc.json. Outils : gc-dms (registre : scan, validate, pack, verify, check), gc-sidecar (création de sidecar), gc-docsign (GCSIG/signature), gc-v7guid (classes et identités).
Le registre DMS est un répertoire, pas un stockage : les originaux restent à leur emplacement de stockage ; le registre conserve pour chaque document le SHA-256, l'object_id et les storage_locations avec leur provenance. L'object_id est le docUid du sidecar (pas une seconde identité) ; stored_by_pgid est l'action d'ingestion DMS enregistrée (par ex. pgid 183), stored_by_user_id l'uuidV7 de la personne. L'action productrice (produced_by_pgid, par ex. 180 pour la facture) figure séparément dans le jeu de métadonnées de facture/GCPN. Catalogue du registre : GCUV/TOP/compliance/process_gateways.json ; valeurs normatives : OSS/TOP/.gitcover/dictionaries/gateway_ids.json.
Identités (à ne pas confondre) : docUid (instance), sha256 (ancre de contenu), V7GUID (classe) et GCPN-docUid (opération) sont quatre axes distincts. Seul le docUid du document — issu du sidecar de base ou, pour un sidecar intégré, de source.v7g_docUid dans le .gcsig.md — devient l'object_id du document ; un docUid GCSIG reste un artefact de signature (subject.sha = SHA du document), un docUid GCPN reste une opération. La détection est pilotée par le contenu (instance de schéma JSON intégrée), et non par l'extension.
Ordre (déterministe) : documents[] est trié par sha256 ; storage_locations[] par source_root_id, unc_path (null en dernier), original_path et stored_at_utc. La sérialisation maintient l'ordre des clés stable. Les filtres temporels et le tri passent par le docUid d'instance uuidV7, non par le V7GUID de classe.
GCPN - GitCover PrimaNota
Mécanisme de métadonnées permettant de constituer des chaînes de preuve 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 comptabilité en partie double ou une opération comptable en plusieurs parties (créance, TVA, centre de coûts/répartition par centre de coûts) — une clé unique de rattachement. GCPN transpose ce principe sur une base UUIDv7 : chaque document reçoit un identifiant ordonné dans le temps (RFC 9562) et est chaîné à ses documents prédécesseurs et successeurs via des références Predecessor/Successor.
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îne sans affectation manuelle.
Le format .gc.md sépare la partie lisible par l'humain en haut (titre, tableaux, prose) de l'artefact de données en bas (bloc de code JSON) ; JSON doit être préféré à YAML comme support de données (JSON-First). Le fichier réside 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, résultats d'évaluation OSCAL.
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 l'opération de création et de signature — il n'est pas le sidecar du Referenced-Doc, mais le conteneur de processus. Un .gcpn.md.gc.md séparé n'est pas nécessaire : le conteneur porte son propre GCPN-docUid et est en même temps l'index de l'opération.
Principes essentiels :
- Doc mutable, artefacts JSON immuables : le MD du conteneur est complété pour chaque nouvelle étape du processus ; les artefacts JSON déjà intégrés (schéma
gcpn-container-2.7, autonome et compatible avec l'arborescence :referenced_doc,actor,retentiondécrits une fois chacun ;eventsen tant qu'énumération de drapeaux avec bitmaskevents_resultetenum_refvers la collection immuable ; arborescence 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 vers l'immuabilité : un Referenced-Doc signé devient ensuite immuable ; le conteneur reste mutable et continue à documenter le processus (historique Git = preuve).
Première utilisation : signature GVB avec signature par 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 sécurisée en audit, basée sur UUIDv7, 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 à l'exécution entre agents IA, validateurs de politiques et systèmes d'audit — avec adressage déterministe par V7GUID des objets de contexte. GCUCB adresse le problème du surcoût de coordination des workflows d'agents à plusieurs étapes (coûts de sérialisation et de jetons liés au transfert de contexte) par un bus typé et directement adressable au lieu de couches intermédiaires textuelles.
OPA/Rego agit comme une couche de garde-fou déterministe : le contrôle des politiques découle d'un ensemble de règles, et 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 demande et ne sont présentées ici que sous forme générale jusqu'à la publication.
Délimitation
| Composant | Couche | Délimitation par rapport à GCUCB |
|---|---|---|
| GCEP | Persistance (Git-to-Git) | Instance à instance ; GCUCB = bus runtime |
| GCSYNC | Sortant (Git -> RAG) | Canal externe ; GCUCB = bus interne |
| GCPN | Logique de chaînage | Chaînes de preuve (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 fondamentale — 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 » (types d'entités, relations, graphe GQL, liaisons OneLake). Il s'agit d'une couche de données et de sémantique, pas d'une architecture de transport à l'exécution.
GCUCB attaque la même problématique au niveau du transport et de l'accès : objets de contexte typés, adressage déterministe par V7GUID, couplage des preuves et des politiques à l'exécution. La distinction terminologique claire est intentionnelle : une ontologie décrit ce que signifient les termes (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 à l'exécution. 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 nativement dans Git au sein du 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.
Piste IETF prévue (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 sécurisation de l'état entre instances Git physiques |
La combinaison est très 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 gestionnaire humain — peuvent modifier simultanément les mêmes dépôts et produire des états incohérents (conditions de course).
| 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 délai d'attente | L'agent peut réagir stratégiquement : déplacer un sous-objectif, émettre une notification UI | Souvent des états système morts (interblocages) |
| Adéquation aux agents IA | Élevée — l'agent interroge l'état du verrou au préalable (par ex. via un serveur MCP Git) | 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 à GCEP : avant que deux instances échangent des données, un verrou doit garantir un transfert atomique.
Les actions et règles OPA sont identifiées via uuidV7 (jointure GCAL/GCEP) ; les UUID de gates/politiques enregistrés se trouvent dans GCUV/TOP/compliance/{gates.json,policies/registry.json}. rule_text n'est que l'affichage ; les classes/types passent par les catalogues V7GUID.
GCSYNC - GitCover Sync
Canal sortant de GitCover vers d'autres systèmes de stockage de données. Fournit des données aux systèmes RAG, aux serveurs MCP et aux Nextcloud Shares.
Voir aussi : droits de protection et statut des brevets dans Droits de protection. Reconnaissance de la recherche dans Projets de recherche.