Partie I — Forme textuelle

Déclencheur S1/S2 : une GVB doit être rédigée sous forme textuelle ; ensuite, un vérificateur s'enquiert de 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	Qu'exige réellement le § 126b BGB — et qu'est-ce qui suffit en cas de libre appréciation des preuves ?
DS02	Le Signatur-Doc comme type de données (schéma JSON)	Comment décrivons-nous « Signatur » comme artefact lisible par la machine dans le dépôt ?
DS03	L'opération de signature (Accept/Deny/Sign)	Comment une opération de signature est-elle documentée de manière déterministe et à l'épreuve de l'audit ?
DS04	Catalogage des sidecars et chaîne de vérification	Comment un vérificateur contrôle-t-il l'authenticité et l'intégrité — sans lire l'historique Git ?
DS05	Le GCPN-Signatur-Container	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 (.v7g.md, SHA-256 + catalogage V7GUID), et, pour les transactions, un conteneur GCPN. C'est précisément à ce schéma que se raccorde la signature :

Quell-Dokument (MD)                .v7g.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. Avec sha256sum et jq, un vérificateur peut vérifier l'ensemble de la chaîne — sans historique Git, sans outils propriétaires.

Pourquoi pas de DocuSign dès le départ ?

Trois raisons qui plaident contre un raccordement prématuré des services de signature externes :

Coûts & friction : la majeure partie des documents du quotidien d'une PME (GVB, documentations internes de procédures, reçus) n'a pas besoin d'une signature qualifiée — la forme textuelle suffit (§ 126b BGB : « peut être remplacée par la forme textuelle »).
Ruptures de la chaîne de preuve : chaque service externe génère son propre historique (Envelope-IDs, pistes d'audit dans le cloud du fournisseur). La chaîne de preuve quitte le dépôt — précisément là où GitCover promet une sécurité d'audit GoBD.
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 du signataire identifié) pèse souvent plus lourd qu'un « reçu de signature » d'un fournisseur dont le procédé n'est pas divulgué.

Le raccordement FES (Partie II) entre en jeu précisément lorsqu'un partenaire contractuel externe l'exige — pas comme une fin en soi.

Cadre juridique (citations abrégées)

Norme	Énoncé	Interprétation GitCover
§ 126b BGB	Forme textuelle : « la forme de transmission électronique par laquelle le document est rendu accessible à autrui et apte à être reproduit sous forme de texte sur un écran »	Le fichier MD dans le dépôt est reproduisible sous forme de texte ; le Signatur-Doc 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 ajoute son nom »	Le nom dans le Signatur-Doc + la référence à la clé/au graphique satisfait à l'exigence d'ajout du nom
eIDAS-VO Art. 50–51	eS avancée (AdES/AdEE), eS qualifiée (QES)	Partie II : le raccordement FES comme niveau au-dessus de la forme textuelle
§ 286 ZPO	Libre appréciation des preuves	La chaîne interne (SHA-256 + horodatage + rôles) est un moyen de preuve à part entière

Avertissement : ceci ne constitue pas un avis juridique. L'évaluation au cas par cas reste soumise à la libre appréciation des preuves et, le cas échéant, à une consultation d'avocat.

Ordre de lecture

Les articles s'appuient les uns sur les autres :

DS01 — Pourquoi la forme textuelle suffit et ce que signifie « suffisant » dans le cadre de la libre appréciation des preuves.
DS02 — Le schéma JSON du Signatur-Doc (type de données « Signatur » dans le système de fichiers).
DS03 — L'opération de signature comme schéma d'événements (Accept/Deny/Sign).
DS04 — Vérification du sidecar : comment le vérificateur contrôle la chaîne.
DS05 — Le GCPN-Signatur-Container : document source + FES-Doc + opération dans un seul artefact.

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