Partie I — Forme textuelle

Déclencheur S1/S2 : Une GVB doit être établie sous forme textuelle ; ensuite, un auditeur en interroge l’authenticité. La partie I définit le niveau documentaire : MD-Doc

artefacts JSON dans le dépôt, sans services de signature externes.

Aperçu des articles (DS01–DS05)

Art.	Titre (DE)	Question centrale
DS01	L’exigence de forme textuelle et la libre appréciation des preuves	Que exige réellement § 126b BGB — et qu’est-ce qui suffit en cas de libre appréciation des preuves ?
DS02	Le document de signature comme type de données (schéma JSON)	Comment décrivons-nous « signature » comme artefact lisible par machine dans le dépôt ?
DS03	Le processus de signature (Accept/Deny/Sign)	Comment une opération de signature est-elle documentée de manière déterministe et traçable pour l’audit ?
DS04	Catalogage Sidecar et chaîne de vérification	Comment un auditeur vérifie-t-il l’authenticité et l’intégrité — sans lire l’historique Git ?
DS05	Le conteneur de signature GCPN	Comment rattachons-nous tous les artefacts (document source, FES-Doc, opération) à un document MD ?

L’idée de base : les signatures comme artefacts du dépôt

Un document dans le système GitCover n’est pas un fichier, mais un ensemble d’artefacts : le fichier MD (document source), un sidecar (.gc.md, SHA-256 + catalogage V7GUID), en cas d’opérations commerciales, un conteneur GCPN. C’est précisément sur ce modèle que vient se greffer la signature :

Quell-Dokument (MD)                .gc.md Sidecar            GCPN-Container
   │                           │                          │
   │ sha256                    │ sha256(Quell-Dokument)           │ referenziert alle
   │                           │ V7GUID                   │ Artefakte des Vorgangs
   ▼                           ▼                          ▼
Signatur-Doc (JSON) ──── Accept/Sign-Event ──────── GCPN-Signatur-Container

Chaque artefact suit un schéma JSON (règle Schema-First du GCBoK), chaque relation est une référence SHA-256, chaque opération est un événement descriptible de manière déterministe. Un auditeur peut vérifier toute la chaîne avec sha256sum et jq — sans historique Git, sans outils propriétaires.

Pourquoi pas DocuSign dès le départ ?

Trois raisons de ne pas raccorder prématurément des services de signature externes :

Coûts et frictions : La majorité des documents courants d’une PME (GVB, documentations internes de procédures, reçus) n’a pas besoin de signature qualifiée — la forme textuelle suffit (§ 126b BGB : « peut être remplacée par la forme textuelle »).
Ruptures de preuve : chaque service externe crée son propre historique (ID d’enveloppe, pistes d’audit dans le cloud du fournisseur). La chaîne de preuve quitte le dépôt — précisément là où GitCover GoBD promet la sécurité d’audit.
Seuil du tiers de la force probante : dans le cadre de la libre appréciation des preuves (§ 286 ZPO), une chaîne interne bien documentée (chaîne SHA-256 + horodatage + rôle identifié du signataire) pèse souvent plus lourd qu’un « bonus de signature » d’un fournisseur dont la procédure n’est pas divulguée.

Le raccordement FES (partie II) n’entre en jeu que lorsqu’un partenaire contractuel externe l’exige — pas comme une fin en soi.

Cadre juridique (citation abrégée)

Norme	Énoncé	Interprétation GitCover
§ 126b BGB	Forme textuelle : « la forme de transmission électronique par laquelle le document est rendu accessible à d’autres et est apte à être reproduit sous forme de texte à l’écran »	Le fichier MD dans le dépôt peut être reproduit sous forme de texte ; le document de signature rend la volonté identifiable
§ 371a ZPO	Les actes sous seing privé avec eS sont réputés dûment signés « lorsque l’émettrice ou l’émetteur y appose son nom »	Le nom dans le document de signature + la référence à la clé/au graphique satisfont à l’apposition du nom
eIDAS-règlement Art. 50–51	eS avancée (AdES/AdEE), eS qualifiée (QES)	Partie II : raccordement FES comme niveau supérieur à la forme textuelle
§ 286 ZPO	Libre appréciation des preuves	La chaîne interne (SHA-256 + temps + rôles) constitue un moyen de preuve à part entière

Avertissement : Ceci n’est pas un conseil juridique. L’appréciation au cas par cas reste soumise à la libre appréciation des preuves et, le cas échéant, à la consultation d’un avocat.

Ordre de lecture

Les articles s’appuient les uns sur les autres :

DS01 — Pourquoi la forme textuelle suffit et ce que signifie « suffisant » en cas de libre appréciation des preuves.
DS02 — Le schéma JSON du document de signature (type de données « signature » dans le système de fichiers).
DS03 — Le processus de signature comme schéma d’événement (Accept/Deny/Sign).
DS04 — Vérification Sidecar : comment l’auditeur vérifie la chaîne.
DS05 — Le conteneur de signature GCPN : document source + doc FES + opération dans un seul artefact.

Créé : 260913 | Partie I de la série digital-signage