FES — La signature numérique faite maison — conforme à l'UE et aux GoBD dans son propre dépôt Git
La thèse
La signature électronique avancée (FES) est aujourd'hui une affaire à faire soi-même. Les briques — identification déterministe (V7GUID), chaîne d'intégrité (SHA-256), catalogage (schémas JSON + sidecars), graphique de signature positionné (Fac-similé dans la couche PDF) et liaison cryptographique (PAdES) — sont des standards ouverts et des outils libres. Ce qu'un service de signature emballe à grand prix, 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 solide face aux GoBD (chaîne de preuve révisable qui ne se trouve 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ù se trouve l'obligation de preuve : chez l'organisation elle-même, dans son dépôt Git. La différence n'est pas la crypto — celle-ci est standard. La différence est le siège de la preuve : DocuSign vit dans un cloud dont l'examinateur ne peut pas inspecter les procédés ; la chaîne GitCover se trouve dans le dépôt, est vérifiable sans outil spécial (sha256sum + jq) et survit au prestataire de services.
La série démontre cette thèse en trois parties :
- Forme textuelle (Partie I) : § 126b BGB en libre appréciation des preuves — sans crypto, uniquement par la chaîne (doc de signature, événements, sidecars).
- FES et fac-similé (Partie II) : arrimage conforme à eIDAS — graphique positionné dans la couche PDF, plaque de signature, rapport d'enveloppe, paquet conteneur.
- PII, GPG et Governikus (Partie III, prévue) : niveau des clés — identité de signature, registre de confiance, cycle de vie des clés, certification OpenPGP soutenue par le BSI (pgp.governikus.de).
Pourquoi cette série ?
Toute entreprise se trouve tôt ou tard face à la question : Comment signer des documents numériquement, sans qu'un examinateur (administration fiscale, auditeur, tribunal en libre appréciation des preuves, BSFZ, notaire) rejette la signature comme insuffisante ?
La pratique donne à cette question les réponses habituelles : acheter un compte DocuSign, réserver des services de signature qualifiés, ou — pire — continuer à imprimer, signer, scanner. Les trois réponses ne résolvent pas 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 preuve se rompt précisément là où elle promet la sécurité de révision.
Cette série montre la voie GitCover : la signature devient arrimable dans le dépôt. Le document reste le fichier MD dans le dépôt du tenant ; autour de lui se forme un ensemble d'artefacts basé sur des schémas JSON (doc de signature, événement d'acceptation/de refus, vérification par sidecar), qui satisfait suffisamment à l'exigence de forme textuelle du § 126b BGB en libre appréciation des preuves — et peut ensuite, si le partenaire commercial l'exige, être équipé pour la procédure FES/ADES (signature électronique avancée, à la manière de DocuSign), sans quitter le dépôt.
Limites de la thèse
La thèse « FES faite maison » doit être comprise avec précision :
- Faite maison = la procédure, la chaîne et la preuve restent entre ses propres mains (dépôt, standards ouverts, outils libres). Elle ne remplace pas le certificat : la liaison cryptographique a besoin d'un certificat de signature — E1 l'a obtenu via un service de signature ou un certificat propre (par ex. personnel qualifié — non : la FES n'a pas besoin d'un certificat qualifié ; un certificat régulier suffit).
- Conforme à l'UE = conforme à eIDAS. La FES satisfait à l'art. 25 (2) eIDAS (équivalent à la signature manuscrite, § 126 al. 3 BGB). La QES (substitut à la forme écrite, § 126a BGB) reste externe (liste de confiance) — la série l'arrime, ne la remplace pas.
- Solide face aux GoBD = la chaîne de preuve (document source → doc de signature → événements → graphique → PDF) est native au dépôt, vérifiable par sha256sum, conservable 10 ans (§ 147 AO) — sans dépendance à un prestataire 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 sous forme textuelle | Comment satisfaire au § 126b BGB de manière native à Git, en libre appréciation des preuves, sans services de signature externes ? | DS01–DS05 |
| Partie II — FES et fac-similé | Un partenaire commercial exige une signature électronique avancée | Comment arrimer 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 | Le premier véritable processus de signature (gain de recherche) | Comment rendre la procédure lisible par machine — comme schéma JSON normatif sans redondance interne ? | DS12–DS15 |
| Partie IV — PII, GPG et Governikus (détachée) | Gestion des clés, SSH vs OpenPGP, registre de confiance, certification officielle (gpg.governikus.de) | Comment gérer les clés privées et le modèle d'identité de signature — et arrimer la certification GPG soutenue par le BSI — sans faire fuiter de PII dans Git ? | Prévue (DS16–DS21) |
| Partie V — Mobile et communauté | Utilisation mobile avec des outils GPG sur smartphones/appareils | Comment l'entrepreneur signe-t-il et vérifie-t-il en mobilité — et quelles solutions développer comme domaine de travail communautaire ? | Esquisse (pas de numéros DS) |
| Partie VI — Documents signés par Git | Un contrat doit être présenté/approuvé de manière traçable avant la signature | Comment consigner les événements (affichage/approbation/signature) par document, sans modifier le doc original immuable ? | Artefact de signature *.gcsig.md par doc original dès l'ébauche |
Remarque sur la séparation : les thèmes PII/GPG (matériel de clé, schémas JSON d'identité, mécanique de signature GPG/SSH, gestion du trousseau de clés) sont volontairement traités seulement dans la Partie IV — ils constituent un cercle de conformité à part (gestion des PII dans le dépôt TOP, répertoires gitignored, registres de confiance) et ne doivent pas être mélangés avec le niveau document des parties I–III.
La saga : modèle des déclencheurs
Comme dans la série Entrepreneur-Diary, chaque article est déclenché par un
déclencheur concret dans la vie de l'entreprise — ici les événements de signature
d'une PME (organisation fictive ORG-1, espace réservé E1 comme entrepreneur) :
| Déclencheur | Événement | Conséquence |
|---|---|---|
| S1 — La résolution | Une assemblée des associés (GVB) doit être tenue sous forme textuelle — tous les associés sont une seule personne (E1), mais la résolution doit être « signée » de manière traçable et sûre en révision | Modèle de forme textuelle : doc MD + artefacts JSON dans le dépôt (Partie I) |
| S2 — La question de vérification | Un examinateur demande : « Le document est-il authentique ? Qui l'a "signé" ? » | Vérification par sidecar : SHA-256, V7GUID, tampon guid (Partie I) |
| S3 — Le partenaire externe | (Espace réservé PARTNER-1) exige DocuSign pour un contrat de projet/d'achat |
Arrimage FES : doc de signature comme artefact propre, 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) | Fac-similé PNG/SVG avec SHA-256 + tampon guid, plaque de signature (Partie II) |
| S5 — La question des clés | Comment signer nous-mêmes les commits Git — GPG ou SSH — et où se trouvent les clés privées ? | Cercle PII/GPG, schémas JSON d'identité (Partie III, prévue) |
Ce que la série n'est pas
- Pas un conseil juridique. Le § 126b BGB, le règlement eIDAS, le § 371a ZPO et les normes GOB sont cités comme cadre ; l'appréciation juridique du cas particulier reste laissée à la libre appréciation des preuves et, le cas échéant, à un conseil d'avocat.
- Pas un substitut à la QES. Là où une loi exige la signature électronique qualifiée (par ex. actes notariés, certains formats administratifs), il n'existe pas de voie native à Git — la série montre au contraire comment le contrat QES est ancré et référencé dans le dépôt.
- Pas de gestion des clés. Les clés privées, les trousseaux de clés, la mécanique GPG/SSH relèvent de la matière de la Partie III — volontairement séparés, car ce sont des thèmes de PII et d'infrastructure.
Renvois
- Série Entrepreneur-Diary — la ligne illustrative de la série ED ; la saga de la signature commence là où naissent les documents qui doivent être signés (GVB, contrats, reçus).
- Chapitre 04 du GCBoK « Signature GPG » — cadre normatif ; la série le concrétise au niveau du document.
- Spécification V7GUID — tampon guid, clé composite
V7GUID:uuidV7, obligation de sidecar.
Créé : 260913 | Éditeur : ORG-1 (espace réservé, point de vue de l'éditeur) | Série : digital-signage