DS01 — L'exigence de la forme textuelle et la libre appréciation des preuves
Déclencheur S1
L'associée unique (placeholder E1 en tant qu'entrepreneur, organisation
ORG-1) adopte une résolution d'associés (GVB) — par exemple l'approbation
d'une indemnité de dépenses. Les statuts exigent que les résolutions soient
prises en forme textuelle. E1 demande : Puis-je faire cela dans le dépôt
Git — et à quoi ressemble une résolution qu'un vérificateur reconnaîtra plus
tard comme « prise en forme textuelle » ?
Ce que le § 126b BGB exige
§ 126b BGB (forme textuelle) : « Lorsque la loi ne prescrit pas la forme écrite mais prévoit la forme textuelle, la forme textuelle peut être remplacée par toute forme appropriée de transmission électronique, à condition (1) que la personne à laquelle le document est destiné ait accès au document via l'adresse indiquée par le destinataire, (2) que le document soit rendu accessible à autrui et apte à être restitué sur un écran sous forme de texte littéral, et (3) que la personne qui remet le document l'ait clairement identifié comme émanant d'elle, afin de sauvegarder les intérêts qu'elle représente. »
Trois conditions, trois interprétations GitCover :
| § 126b BGB | Interprétation GitCover |
|---|---|
| (1) Accès via l'adresse du destinataire | Le dépôt tenant (Gitea) est l'adresse ; le destinataire (associé, gérant) dispose d'un accès en lecture |
| (2) Accessible, restituable en texte littéral | Le document Markdown est le texte littéral — cat, Typora, n'importe quel navigateur le restitue |
| (3) Attribution d'origine (« clairement identifié comme émanant d'elle ») | Le Signatur-Doc attribue le document de manière reconnaissable au signataire : nom + rôle + référence au fac-similé dans un artefact JSON ancré par SHA-256 (DS02) |
Le point (3) n'exige pas de signature qualifiée. Il exige une attribution d'origine clairement reconnaissable : le destinataire doit pouvoir reconnaître qui remet le document. C'est précisément là qu'interviennent le Signatur-Doc (DS02) et le processus de signature (DS03).
La libre appréciation des preuves (§ 286 ZPO)
En droit processuel civil, le document en forme textuelle n'est pas un événement soumis à une preuve stricte — il relève de la libre appréciation des preuves. Le tribunal apprécie si les moyens de preuve présentés « forment une conviction selon la libre conviction ». Cela signifie :
- Il n'existe aucune forme rigide qui « suffise » — il n'existe que des preuves plus ou moins convaincantes.
- Un processus documenté sans lacune et résistant à la révision (qui a remis le document, à quel moment, avec quelle clé/quel graphisme, comment l'intégrité pouvait être vérifiée) convainc davantage qu'un unique « bon de signature ».
- Inversement : une capture d'écran unique d'une signature par courriel convainc à peine ; un ensemble d'artefacts catalogué et adossé au SHA-256, si.
GitCover traduit cela en une chaîne favorable à l'appréciation des preuves :
- Intégrité : SHA-256 du document source, du Signatur-Doc, du Sidecar.
- Attribution d'origine : le Signatur-Doc identifie le signataire (nom, rôle, référence de clé/de graphisme) et le lie par SHA-256 au document source.
- Ordre temporel : horodatage uuidV7 dans chaque artefact (RFC 9562).
- Catalogisation : taxonomie de classes V7GUID dans le Sidecar ; le vérificateur peut reconnaître le type d'artefact sans connaissance du contexte.
- Résistance à la révision : l'historique Git n'est pas le seul moyen de preuve — la chaîne est également vérifiable sans Git (avec jq, sha256sum, n'importe quel éditeur).
§ 371a ZPO — l'acte sous seing privé revêtu de la forme électronique
§ 371a ZPO : « Les actes sous seing privé revêtus d'une forme électronique ont la force probante des actes sous seing privé revêtus de la forme écrite lorsque l'émettrice ou l'émetteur y ajoute son nom et indique la remise de la déclaration sous forme électronique, ou lorsqu'ils sont munis d'une signature électronique qualifiée ou d'un sceau certifié comparable. »
Trois observations pour la voie GitCover :
- L'ajout du nom + l'indication de la forme suffisent — le Signatur-Doc (DS02) fait exactement cela : nom/rôle du signataire + indication explicite de la forme (« remise de la déclaration sous forme électronique »).
- La QES est l'alternative de fer — si un contrat doit avoir force probante en tant qu'acte sous seing privé avec QES, la qualification FES vient s'y raccorder (partie II). La base en forme textuelle reste toutefois, même alors, le niveau du dépôt.
- La valeur probante réside dans la chaîne — et non dans une caractéristique isolée. DS04 montre la routine de vérification complète.
L'erreur la plus fréquente : la signature par courriel
Le scénario pratique que GitCover veut éviter :
unterschrieben"] B --> C["Gescannt"] C --> D["Per Mail
gesendet"] D --> E["Mail-Verzeichnis
im Postfach"] E --> F["Prüfung: Wo ist die
Original-Unterschrift?"] style F fill:#f3d9d9,stroke:#8b2635
Ruptures de preuve : pas de SHA-256, pas d'horodatage, pas d'attribution de rôle, pas de résistance à la révision — l'« original » circule entre l'imprimante, le scanner et le client de messagerie. Un document GitCover évite cela en faisant de chaque étape un artefact dans le dépôt.
Résumé
- Le § 126b BGB exige accès + texte littéral + attribution d'origine — le document MD + le Signatur-Doc le satisfont de manière native dans Git.
- En cas de libre appréciation des preuves, la chaîne sans lacune (SHA-256 + temps + rôles + catalogisation) convainc davantage qu'un bon de signature externe.
- Le § 371a ZPO le confirme : l'ajout du nom + l'indication de la forme suffisent pour la force probante des actes sous seing privé ; la QES est l'alternative de fer, pas une obligation pour la forme textuelle.
- L'article suivant (DS02) définit le Signatur-Doc comme schéma JSON.
Créé : 260913 | Partie I, article DS01 | Série : digital-signage