FES — Signature numérique faite maison — conforme à l'UE et à GoBD dans son propre dépôt Git
La thèse
La signature électronique avancée (FES) est aujourd'hui une affaire de « fait maison ». Les éléments constitutifs — identification déterministe (V7GUID), chaîne d'intégrité (SHA-256), catalogage (JSON-Schemas + Sidecars), graphique de signature positionné (Facsimile dans la couche PDF) et liaison cryptographique (PAdES) — sont des standards ouverts et des outils libres. Ce qu'un service de signature emballe à prix d'or, une organisation le construit elle-même avec Git, JSON et un outil de signature PDF : conforme à l'UE (règlement eIDAS, § 126b/126a BGB, § 371a ZPO) et à l'épreuve de la GoBD (une chaîne de preuves à l'épreuve des audits qui ne réside pas chez le prestataire, mais dans son propre dépôt).
Pas « fait maison » au sens de moins bien que DocuSign — mais au sens de là où repose l'obligation de preuve : au sein de l'organisation elle-même, dans son dépôt Git. La différence ne tient pas à la cryptographie — celle-ci est standard. La différence, c'est le siège de la preuve : DocuSign vit dans un cloud dont le vérificateur ne peut pas examiner les procédés ; la chaîne GitCover réside dans le dépôt, est vérifiable sans outil spécialisé (sha256sum + jq) et survit au fournisseur de services.
La série démontre la thèse en trois parties :
- Forme textuelle (partie I) : § 126b BGB dans le cadre de la libre appréciation des preuves — sans cryptographie, uniquement grâce à la chaîne (document de signature, Events, Sidecars).
- FES & Facsimile (partie II) : raccordement conforme à eIDAS — graphique positionné dans la couche PDF, plaque de signature, Envelope-Report, paquet conteneur.
- PII, GPG & Governikus (partie III, prévue) : niveau des clés — Signing-Identity, Trust Registry, Key-Lifecycle, certification OpenPGP avec appui du BSI (pgp.governikus.de).
Pourquoi cette série ?
Toute entreprise se trouve tôt ou tard confrontée à la question : comment signer des documents numériquement sans qu'un vérificateur (administration fiscale, auditeur, tribunal dans le cadre de la libre appréciation des preuves, BSFZ, notaire) ne rejette la signature comme insuffisante ?
La pratique apporte à cette question les réponses habituelles : acheter un compte DocuSign, souscrire des services de signature qualifiés, ou — pire — continuer à imprimer, signer, scanner. Aucune de ces trois réponses ne résout le véritable problème : elles génèrent une activité de signature en dehors du dépôt Git dans lequel vit le document. La chaîne de preuves se rompt précisément là où elle promet la sécurité d'audit.
Cette série montre la voie GitCover : la signature devient raccordable dans le dépôt. Le document reste le fichier MD dans le dépôt du tenant ; autour de lui se constitue un jeu d'artefacts basé sur des JSON-Schemas (document de signature, Accept-/Deny-Event, vérification Sidecar) qui satisfait suffisamment l'exigence de forme textuelle du § 126b BGB dans le cadre de la libre appréciation des preuves — et qui peut ensuite, lorsque le partenaire commercial l'exige, être mis à niveau vers un procédé FES/ADES (signature électronique avancée, de type DocuSign), sans quitter le dépôt.
Limites de la thèse
La thèse « FES faite maison » doit être comprise avec précision :
- Fait maison = le procédé, la chaîne et la preuve sont entre ses propres mains (dépôt, standards ouverts, outils libres). Elle ne remplace pas le certificat : la liaison cryptographique exige un certificat de signature — E1 se le procurait via un service de signature ou son propre certificat (p. ex. un certificat qualifié personnel — non : la FES n'a pas besoin d'un qualifié ; un certificat ordinaire suffit).
- Conforme à l'UE = conforme à eIDAS. La FES satisfait eIDAS Art. 25 (2) (équivalente à la signature manuscrite, § 126 Abs. 3 BGB). La QES (substitut de la forme écrite, § 126a BGB) reste externe (Trust-Liste) — la série la raccorde, elle ne la remplace pas.
- À l'épreuve de la GoBD = la chaîne de preuves (document source → document de signature → Events → graphique → PDF) est native au dépôt, vérifiable via sha256sum, conservable pendant 10 ans (§ 147 AO) — sans dépendance envers un fournisseur de services dont le portail n'existera peut-être plus dans 10 ans.
La série en un coup d'œil
| Partie | Déclencheur | Question centrale | Articles |
|---|---|---|---|
| Partie I — Forme textuelle | Un contrat (GVB) doit être conclu en forme textuelle | Comment satisfaire le § 126b BGB de manière native dans Git, dans le cadre de la libre appréciation des preuves, sans services de signature externes ? | DS01–DS05 |
| Partie II — FES & Facsimile | Un partenaire commercial exige une signature électronique avancée | Comment raccorder une FES au dépôt — à la manière de DocuSign, avec un graphique positionné dans la couche PDF ? | DS06–DS11 |
| Partie III — Schéma de conteneur GCPN | La première véritable opération de signature (Forschungsgewinn) | Comment rendre le procédé lisible par la machine — comme un JSON-Schema normatif sans redondance interne ? | DS12–DS15 |
| Partie IV — PII, GPG & Governikus (détachée) | Gestion des clés, SSH vs. OpenPGP, Trust Registry, certification officielle (gpg.governikus.de) | Comment gérons-nous les clés privées et le modèle de Signing-Identity — et comment raccordons-nous la certification GPG soutenue par le BSI — sans divulguer de PII dans Git ? | Prévue (DS16–DS21) |
| Partie V — Mobile & Community | Utilisation mobile avec des GPG-Tools sur smartphones/appareils | Comment l'entrepreneur signe-t-il et vérifie-t-il en mobilité — et quelles solutions faut-il développer comme domaine de travail communautaire ? | Esquisse (pas de numéros DS) |
Remarque de séparation : les thèmes PII/GPG (matériel de clés, JSON-Schemas d'identité, mécanique de signature GPG/SSH, gestion des keyrings) sont délibérément traités seulement dans la partie IV — ils constituent un cercle de conformité à part entière (gestion des PII dans le TOP-Repo, répertoires gitignored, Trust-Registries) et ne doivent pas être mélangés au niveau documentaire des parties I–III.
La saga : modèle des déclencheurs
Comme dans la série Entrepreneur-Diary, chaque article est initié par un déclencheur concret dans la vie de l'entreprise — ici les événements de signature d'une PME (organisation fictive ORG-1, placeholder E1 en tant qu'entrepreneur) :
| Déclencheur | Événement | Conséquence |
|---|---|---|
| S1 — La résolution | Une résolution d'assemblée des associés (GVB) doit être adoptée en forme textuelle — tous les associés ne forment qu'une seule personne (E1), mais la résolution doit être « signée » de manière traçable et à l'épreuve des audits | Modèle de forme textuelle : MD-Doc + artefacts JSON dans le dépôt (partie I) |
| S2 — La question de vérification | Un vérificateur demande : « Le document est-il authentique ? Qui l'a “signé” ? » | Vérification Sidecar : SHA-256, V7GUID, tampon guid (partie I) |
| S3 — Le partenaire externe | (placeholder PARTNER-1) exige DocuSign pour un contrat de projet/vente |
Raccordement FES : document de signature en tant qu'artefact distinct, paquet conteneur (partie II) |
| S4 — La couche de signature | La signature FES doit apparaître comme graphique positionné dans la couche PDF (à la manière de DocuSign) | PNG/SVG Facsimile avec SHA-256 + tampon guid, plaque de signature (partie II) |
| S5 — La question des clés | Comment signons-nous nous-mêmes les Git-Commits — GPG ou SSH — et où se trouvent les clés privées ? | Cercle PII/GPG, JSON-Schemas d'identité (partie III, prévue) |
Ce que la série n'est pas
- Pas de conseil juridique. Le § 126b BGB, le règlement eIDAS, le § 371a ZPO et les GOB/normes sont cités comme cadre ; l'appréciation juridique du cas d'espèce reste du ressort de la libre appréciation des preuves et, le cas échéant, d'une consultation d'avocat.
- Pas de substitut à la QES. Là où une loi exige la signature électronique qualifiée (p. ex. actes notariés, certains formats administratifs), il n'existe pas de voie native Git — la série montre en revanche comment le contrat QES est ancré et référencé dans le dépôt.
- Pas de gestion des clés. Les Private Keys, les keyrings et la mécanique GPG/SSH relèvent de la partie III — délibérément séparés, car ce sont des thèmes PII et d'infrastructure.
Références croisées
- Série Entrepreneur-Diary — la ligne d'illustration de la série ED ; la saga des signatures démarre là où naissent des documents qui doivent être signés (GVB, contrats, Receipts).
- Chapitre 04 du GCBoK « Signature GPG » — cadre normatif ; la série le concrétise au niveau des documents.
- V7GUID-Spec — tampon guid, clé composite
V7GUID:uuidV7, obligation de Sidecar.
Créé : 260913 | Éditeur : ORG-1 (placeholder, point de vue de l'éditeur) | Série : digital-signage