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 (placeholder 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 mail. Ruptures de preuve garanties.

GitCover s'y raccorde : le rapport d'enveloppe documente l'opération en natif dans le dépôt — en tant qu'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",
  "uuidV7": "<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 même si 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 justificatifs GoBD/AO — le rapport est une pièce justificative d'entrée (avec sidecar .v7g.md, catalogage V7GUID) ; le PDF signé est la pièce justificative originale. Les deux migrent vers le conteneur GCPN (DS05) ou le paquet du conteneur (DS10).

Catalogage sidecar

Le rapport d'enveloppe reçoit un sidecar (.v7g.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 justificative originale)
`FES_CERTIFICATE_OF_COMPLETION`	Rapport du service (vue de la plateforme)

Les trois sont des candidats Promote pour 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.v7g.md"
},
{
  "role": "fes-signed-document",
  "kind": "pdf",
  "location": "contract-agreement-signed.pdf",
  "sha256": "7a054fa5…272b",
  "note": "physisch im Container-Paket (DS10)"
}

Constat pratique : un exemple d'opération (anonymisée)

La saga se concrétise à travers un exemple d'opération (placeholder) : contrat d'achat (initiation → enveloppe FES ENV-EXAMPLE-0001… → signature → paiement → livraison → clôture), traité exactement selon ce schéma — le rapport d'enveloppe, le PDF signé (ancré par SHA-256), le Certificate-of-Completion et les documents subséquents se trouvent dans le dépôt et forment la chaîne ininterrompue : initiation → signature → paiement → livraison → clôture. Tous les noms, ID et dates sont des placeholders ; la structure est la leçon.

Résumé

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

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