# Politique de signature et de preuve Contraktia

Identifiant : contraktia-sig-policy-v1
Version : 1 du 25 septembre 2026
Éditeur : Contraktia, plateforme de préparation, de signature et de suivi des contrats

Cette politique décrit le procédé de signature électronique mis en œuvre par Contraktia, les éléments de preuve qu'il produit, leur conservation et leur vérification. Son identifiant et son empreinte SHA-256 figurent dans chaque dossier de preuve émis sous cette version.

## 1. Niveau de signature et limites

- Signature électronique simple (règlement eIDAS, article 3 ; Code civil, article 1367). Ce n'est ni une signature avancée ni une signature qualifiée : elle ne bénéficie pas de la présomption de fiabilité prévue par le décret n° 2017-1416. Sa fiabilité s'établit par les éléments décrits ci-dessous et, entre les parties, par la convention de preuve (identifiant contraktia-evidence-agreement).
- Le code envoyé par courriel prouve le contrôle de l'adresse électronique utilisée ; il ne prouve pas à lui seul l'identité civile du signataire ni ses pouvoirs de représentation.
- Le procédé ne convient pas aux actes pour lesquels la loi exige une forme particulière (acte authentique, mentions manuscrites, signature qualifiée).

## 2. Gel du document

- Avant l'ouverture de la signature, le document est figé : son contenu (titre, parties, clauses, signataires et ordre de signature) est enregistré sous forme d'instantané. Son empreinte SHA-256 est calculée sur le JSON canonique de cet instantané (clés triées, sans espaces).
- Le document figé ne peut plus être modifié : pour changer le texte, la campagne de signature doit être annulée et le document figé de nouveau, ce qui produit une nouvelle empreinte. Tous les signataires d'une campagne signent la même empreinte.
- Les signataires signent dans l'ordre défini ; chacun est invité par courriel.

## 3. Accès et identification du signataire

- Membre de l'organisation émettrice : compte Contraktia personnel.
- Partie externe : lien personnel envoyé par courriel, puis code d'accès à usage unique envoyé à la même adresse. Ce code ouvre une session limitée au document ; il ne vaut jamais signature.
- Mandataire : membre signant au nom d'un autre membre en vertu d'un mandat confirmé par le mandant, limité à des types de documents et à une période. Le mandat est vérifié au moment exact de la signature et le mandant est notifié.

## 4. Parcours de signature

1. Lecture et consentement : le document figé complet est affiché. Le signataire coche une case non précochée, dont le texte exact est enregistré, et accepte la convention de preuve par une seconde case non précochée (version, langue et empreinte enregistrées).
2. Code à usage unique : un code de 6 chiffres est envoyé à l'adresse du signataire (à celle du mandataire lorsqu'il agit). Paramètres par défaut : validité de 15 minutes ; seul le dernier code émis est valable ; usage unique ; au plus 3 envois par adresse en 5 minutes et 10 envois par adresse IP ; 5 échecs consécutifs bloquent la vérification pendant 15 minutes. Le code n'est jamais conservé en clair (seule une empreinte à clé HMAC l'est) et n'apparaît dans aucun journal ni dossier de preuve.
3. Confirmation finale : une case distincte reprend le titre, la référence et la mention de signature. Au clic, le serveur revérifie dans une même transaction l'état du contrat, la campagne, l'ordre de signature, l'échéance, l'empreinte recalculée du document figé, le consentement et le code vérifiés depuis moins de 15 minutes par la même personne, l'acceptation de la convention de preuve et le mandat invoqué. En cas d'échec, rien n'est signé et le parcours reprend à l'étape 1.

## 5. Éléments de preuve enregistrés

Pour chaque signature : identité, qualité et organisation déclarées ; adresse électronique ; type d'accès (compte ou partie externe) ; texte exact et langue des cases cochées ; acceptation de la convention de preuve (identifiant, version, langue, empreinte, date, adresse IP, navigateur) ; dates et heures du consentement, de l'envoi et de la vérification du code et de la confirmation ; identifiant du défi de code (jamais le code) ; adresse IP et navigateur ; mention de signature ; empreinte signée ; le cas échéant, instantané du mandat. Les dates sont celles des serveurs de la plateforme, en temps universel coordonné (UTC).

## 6. Journal d'audit chaîné

- Chaque action significative est inscrite dans un journal d'audit en ajout seul, propre à chaque organisation.
- L'empreinte de chaque événement est le SHA-256 de la concaténation de l'empreinte de l'événement précédent de l'organisation (en hexadécimal, chaîne vide pour le premier) et du JSON canonique de son contenu : portée, organisation, contrat, type et identifiants de l'acteur, libellé de l'acteur, action, type et identifiant de l'objet, résultat, adresse IP, navigateur, accès support, détails, date à la milliseconde. Toute modification ou suppression d'un événement rompt la chaîne.
- Le dossier de preuve reprend les événements de la phase de signature du contrat (aucune note interne), avec l'intégralité de leur contenu haché, leur empreinte, l'empreinte précédente et leur numéro d'ordre, ainsi que le résultat du contrôle de la chaîne de l'organisation au moment du scellement et l'empreinte de tête de cette chaîne.

## 7. Scellement

- Lorsque toutes les signatures sont recueillies, la plateforme produit : l'exemplaire final PDF (document figé, bloc de signatures avec les mentions exactes, certificat de signature) ; le fichier proof.json (instantané figé, preuves de chaque signature, mandats, événements d'audit, références de la présente politique et de la convention de preuve) ; le rapport de preuve PDF, lisible par un non-spécialiste.
- Un manifeste de scellement (version 2) indique les empreintes SHA-256 de ces trois fichiers, l'empreinte du document figé, les signatures, la date de scellement, le niveau de signature, l'identifiant et l'empreinte de la présente politique, les versions et empreintes de la convention de preuve acceptées, l'adresse de publication des clés, les règles d'horodatage appliquées (norme, algorithme d'empreinte, éléments horodatés, service actif ou non au scellement, qualification déclarée du prestataire) et l'empreinte de tête du journal d'audit de l'organisation au moment du scellement. Il est signé en Ed25519 sur son JSON canonique (clés triées, sans espaces) avec la clé de scellement de la plateforme.
- La clé privée de scellement est générée par la plateforme et conservée chiffrée (AES-256-GCM) dans son coffre ; elle n'est jamais journalisée ni transmise. Chaque clé est identifiée par les 16 premiers caractères hexadécimaux du SHA-256 de sa clé publique (SPKI, encodage DER). Les clés publiques, actuelles et passées, sont publiées avec leurs dates de validité.
- Le scellement est idempotent ; un échec laisse le contrat en attente de scellement, peut être relancé et n'altère pas les signatures recueillies.
- Un dossier de preuve émis n'est jamais modifié. Les dossiers émis avant la présente politique (manifeste version 1) restent vérifiables selon les règles en vigueur lors de leur émission.

## 8. Horodatage et ancrage

- Les dates enregistrées proviennent des horloges des serveurs de la plateforme.
- Lorsque le service d'horodatage est activé, deux jetons d'horodatage conformes à la norme RFC 3161 (empreintes SHA-256) sont demandés à une autorité d'horodatage tierce après chaque scellement : l'un sur l'exemplaire final PDF, l'autre sur le manifeste de scellement. Seule l'empreinte est transmise à l'autorité. Chaque jeton est vérifié à sa réception : empreinte, signature de l'autorité, usage d'horodatage de son certificat et chaîne de certification jusqu'à la racine de l'autorité désignée par l'exploitant ; le service ne peut pas être activé sans cette racine.
- Une autorité indisponible n'empêche jamais le scellement : la demande est renouvelée automatiquement, à intervalles croissants, et l'exploitant est alerté après plusieurs échecs. Un jeton obtenu après le scellement (reprise, ou contrat scellé avant l'activation du service) atteste l'existence du document à la date qu'il porte, et non à la date de signature ; il est présenté comme tel.
- Ancrage du journal d'audit : lorsque le service est activé, la plateforme établit, périodiquement (par défaut toutes les 24 heures) et à chaque scellement, un relevé de chaque chaîne d'audit : segment couvert, nombre d'événements, empreinte de tête, racine d'un arbre de Merkle (RFC 6962) des empreintes des événements du segment et référence du relevé précédent. L'empreinte de ce relevé est horodatée par l'autorité, dans les 72 heures suivant sa création au plus tard. Une réécriture ultérieure du journal, même recalculée entièrement, contredirait un relevé daté par un tiers ; la plateforme vérifie régulièrement qu'aucun relevé n'est contredit et alerte l'exploitant dans le cas contraire. Chaque relevé horodaté est inscrit, par les seules empreintes du relevé et du jeton et par sa date, sans organisation ni contenu, dans un journal public en ajout seul (/.well-known/contraktia-audit-anchors.json) dont les entrées sont chaînées : quiconque en conserve une copie peut constater une suppression ou une modification ultérieure.
- Les jetons, les relevés d'ancrage couvrant les événements du contrat et les preuves d'inclusion de ces événements dans les relevés (empreintes seulement, sans aucun contenu d'un autre contrat ou d'une autre organisation) sont joints au dossier de preuve comme fichiers additionnels, sans modifier les pièces scellées. Ils sont recensés par un index signé en Ed25519 avec une clé de scellement publiée, et se vérifient avec la commande openssl ts -verify et avec le vérificateur indépendant.
- La qualification « eIDAS » d'une autorité d'horodatage est une déclaration de l'exploitant, reprise telle quelle dans le dossier de preuve ; seule l'inscription de l'autorité sur la liste de confiance européenne rend l'horodatage qualifié.
- L'absence d'horodatage ou d'ancrage (service désactivé ou indisponible) est visible dans le dossier de preuve et n'affecte pas les autres éléments.

## 9. Conservation

- L'exemplaire final, proof.json, le rapport de preuve, le manifeste signé et le journal d'audit sont conservés durablement avec l'archive contractuelle de l'organisation émettrice, chiffrés (AES-256-GCM) ; l'empreinte de chaque fichier est contrôlée à chaque lecture.
- Les données techniques de courte durée (défis de code, sessions) sont purgées selon la politique de confidentialité ; les éléments utiles à la preuve sont recopiés dans la preuve de signature au moment de la signature.
- Chaque signataire reçoit l'exemplaire final et le rapport de preuve par courriel. Le dossier de preuve complet (ZIP) est téléchargeable par les membres autorisés de l'organisation émettrice et par les signataires authentifiés.

## 10. Vérification

- Page publique de vérification (/verify) : un exemplaire PDF déposé est comparé aux exemplaires scellés et le sceau de son manifeste est contrôlé. Le fichier n'est pas conservé.
- Vérification indépendante : chaque dossier de preuve contient un vérificateur autonome (verify.mjs, Node.js, sans dépendance) et des instructions pour vérifier à la main avec sha256sum et OpenSSL : empreintes des fichiers, signature Ed25519 du manifeste, correspondance de la clé avec les clés publiées, empreinte du document figé, événements du journal d'audit, documents de référence, jetons d'horodatage, relevés d'ancrage et preuves d'inclusion. Le vérificateur ne se fie pas à la clé jointe au dossier : il la compare aux clés publiées à l'adresse officielle inscrite dans son code, jamais à une adresse indiquée par le dossier. Il ne tient un horodatage pour établi que si la chaîne de certification de l'autorité aboutit à une racine qu'il reconnaît ou que l'utilisateur lui désigne. La copie jointe à un dossier provient du même serveur que lui : la version officielle est téléchargeable sur la page /seal-keys, qui publie l'empreinte SHA-256 de chaque version.
- Clés publiques de scellement : /.well-known/contraktia-seal-keys.json et page /seal-keys ; journal public des ancrages : /.well-known/contraktia-audit-anchors.json.

## 11. Évolutions

Toute modification du procédé donne lieu à une nouvelle version de la présente politique, sous un nouvel identifiant. Une version publiée n'est jamais modifiée. Un dossier de preuve reste vérifiable selon la version sous laquelle il a été émis.