DS09 — Le rapport d’enveloppe FES

Déclencheur S3, suite

Le contrat de projet / d’achat avec PARTNER-1 est conclu via un service FES (espace réservé FES-PROVIDER, de type DocuSign). La pratique classique : l’enveloppe vit dans le cloud du fournisseur ; une confirmation par e-mail atterrit dans la boîte de réception. Ruptures de preuve garanties.

GitCover s’y raccorde : le rapport d’enveloppe documente l’opération nativement dans le dépôt — sous forme d’artefact JSON avec toutes les métadonnées fournies par le service.

La structure de l’enveloppe

{
  "$schema": "https://gitcover.org/schemas/fes-envelope-1.0.schema.json",
  "docUid": "<deterministische uuidV7>",
  "type": "fes-envelope-report",
  "envelope_id": "ENV-EXAMPLE-0001-XXXX-XXXX-XXXXXXXXXXXX",
  "provider": {
    "name": "FES-PROVIDER",
    "service": "DocuSign-artig",
    "report_source": "Web-UI-Export / API"
  },
  "matter": {
    "title": "Trademark and Domain Purchase and Transfer Agreement",
    "contract_date": "2026-08-24",
    "ur_doc_ref": {
      "kind": "external-doc",
      "note": "Vertrag als PDF beim Dienst; Quell-Dokument-SHA im Report verankert",
      "sha256": "7a054fa53ef6ec09053fc925d264ca0a8b7c140ff49e157fef393257d476272b"
    }
  },
  "signers": [
    {
      "name": "Erich Mustermann",
      "role": "Seller (Verkäufer)",
      "entity": "E1 (natürliche Person)",
      "status": "signed",
      "signed_at": "2026-08-24T14:12:00Z",
      "cert_fingerprint": "…",
      "auth_method": "provider-identity-check"
    },
    {
      "name": "PARTNER-1 (PARTNER-2)",
      "role": "Purchaser (Käufer)",
      "entity": "PARTNER-2 (Platzhalter: Vertragspartner-Sitz, EU-Ausland)",
      "status": "signed",
      "signed_at": "2026-08-24T14:15:00Z",
      "cert_fingerprint": "…",
      "auth_method": "provider-identity-check"
    }
  ],
  "documents": [
    {
      "kind": "contract-pdf",
      "filename": "contract-agreement-signed.pdf",
      "sha256": "7a054fa53ef6ec09053fc925d264ca0a8b7c140ff49e157fef393257d476272b",
      "pages": 12,
      "signature_format": "[PAdES](../../glossar.html#pades "PDF Advanced Electronic Signature — Glossar")-B-T"
    },
    {
      "kind": "certificate-of-completion",
      "filename": "DocuSign_Certificate-of-Completion.pdf",
      "sha256": "…",
      "note": "Dienst-Report (Sicht der Plattform)"
    }
  ],
  "timeline": [
    {"event": "envelope-created", "at": "2026-08-22T09:00:00Z"},
    {"event": "sent-to-signers", "at": "2026-08-22T09:05:00Z"},
    {"event": "signed", "by": "Seller", "at": "2026-08-24T14:12:00Z"},
    {"event": "signed", "by": "Purchaser", "at": "2026-08-24T14:15:00Z"},
    {"event": "completed", "at": "2026-08-24T14:15:30Z"}
  ],
  "verification": {
    "method": "sha256-Verifikation der PDFs + pdfsig-Prüfung der Signatur",
    "verified_at": "2026-09-13T16:30:00Z",
    "verified_by": "E1"
  }
}

Pourquoi le rapport a sa place dans le dépôt

Trois raisons probatoires :

Indépendance vis-à-vis du service — le rapport d’enveloppe existe aussi lorsque le fournisseur modifie ou ferme son portail. Les métadonnées (ID d’enveloppe, signataires, horodatages, hachages) sont vérifiables de manière autonome.
Chaînage avec la chaîne du dépôt — le rapport se lie par SHA-256 à la version du document source et au document de signature (partie I) ; la routine de vérification (DS04) couvre également la partie FES.
Chaîne de pièces justificatives GoBD/AO — le rapport est une pièce justificative d’entrée (avec sidecar .gc.md, catalogage V7GUID) ; le PDF signé est la pièce originale. Les deux rejoignent le conteneur GCPN (DS05) ou le paquet de conteneur (DS10).

Catalogage du sidecar

Le rapport d’enveloppe reçoit un sidecar (.gc.md) avec une taxonomie de classes FES :

Classe	Signification
`FES_ENVELOPE_REPORT`	Le rapport lui-même (JSON)
`FES_SIGNED_DOCUMENT`	Le PDF signé (pièce originale)
`FES_CERTIFICATE_OF_COMPLETION`	Rapport du service (point de vue de la plateforme)

Les trois sont candidats à la promotion vers l’OSS-Normative-Root.

Le rapport dans le conteneur GCPN

Le conteneur (DS05) étend sa liste artifacts :

{
  "role": "fes-envelope-report",
  "kind": "json",
  "location": "260913_fes-envelope-report.json",
  "sha256": "<SHA-256>",
  "sidecar": "260913_fes-envelope-report.json.gc.md"
},
{
  "role": "fes-signed-document",
  "kind": "pdf",
  "location": "contract-agreement-signed.pdf",
  "sha256": "7a054fa5…272b",
  "note": "physisch im Container-Paket (DS10)"
}

Constat pratique : un cas d’exemple (anonymisé)

La saga se concrétise dans un cas d’exemple (espace réservé) : contrat d’achat (mise en relation → enveloppe FES ENV-EXAMPLE-0001… → signature → paiement → livraison → clôture), traité exactement selon ce modèle — rapport d’enveloppe, PDF signé (SHA-256 ancré), certificat d’achèvement et les documents subséquents se trouvent dans le dépôt et forment la chaîne sans lacune : mise en relation → signature → paiement → livraison → clôture. Tous les noms, IDs et dates sont des espaces réservés ; la structure est le cas d’école.

Résumé

Le rapport d’enveloppe documente l’opération FES nativement dans le dépôt — indépendamment du service, chaîné à la chaîne de forme textuelle, compatible GoBD.
Les trois classes FES (FES_ENVELOPE_REPORT, FES_SIGNED_DOCUMENT, FES_CERTIFICATE_OF_COMPLETION) cataloguent les artefacts.
Article suivant (DS10) : le paquet de conteneur — la livraison physique de toute la chaîne.

Créé : 260913 | Partie II, article DS09 | Série : digital-signage