Aller au contenu principal
document légal

Charte audit log signé GPG

Politique d'audit log immutable, signature GPG, conservation.

CHARTE AUDIT LOG IMMUTABLE SIGNÉ GPG

Version : 1.0 Date d'entrée en vigueur : 2026-04-28 Document : CHARTE-AUDIT-LOG-EXIOR-V1 Niveaux concernés : Augment, Sovereign (et niveaux inférieurs sur option)


1. Objet

La présente Charte définit les principes, garanties et modalités opérationnelles de l'audit log immutable signé GPG délivré par Exior aux Clients des niveaux Augment et Sovereign. Ce document est partie intégrante des contrats Augment et Sovereign correspondants.


2. Principe doctrinal P11

Conformément au principe P11 de la doctrine Exior (docs/governance/DOCTRINE.md) :

Chaque décision majeure logée dans data/governance/decision_log.jsonl. JSONL append-only. Aucune réécriture.

L'audit log constitue la mémoire judiciaire de l'exocortex : il consigne en continu, de manière immutable et signée cryptographiquement, les décisions, exécutions et événements significatifs survenus dans le tenant Client, dans un format opposable à toute autorité régulatrice.


3. Format technique

3.1 Structure JSONL

Chaque entrée est une ligne JSON conforme au schéma suivant :


{
  "timestamp": "2026-04-28T14:30:00.123Z",
  "iteration": 12345,
  "tenant_id": "client_xyz",
  "candidate_id": "lever-cash-optimization-2026Q2",
  "score": 0.847,
  "outcome": "executed",
  "artifacts": ["docs/governance/...", "exior/governance/..."],
  "session_id": "abc123",
  "commit_sha": "f3a9b2...",
  "actor": "exior_agent_v2.4.1",
  "rationale_hash": "sha256:...",
  "permits_evaluated": {...},
  "safety_constraints_checked": [...],
  "rollback_pattern": "..."
}

3.2 Append-only

Aucune réécriture, aucune modification, aucune suppression. Seul l'ajout en fin de fichier est autorisé. Tout écart est immédiatement détecté par la vérification d'intégrité (article 4).

3.3 Granularité

Sont consignés au minimum :

  • toute décision majeure du scorer (candidat exécuté, rejeté, escaladé) ;
  • toute action mutante effective ;
  • toute évaluation de permit cellulaire ayant abouti à un downgrade ;
  • toute violation de safety constraint détectée ;
  • toute escalade humaine déclenchée ;
  • toute connexion administrateur sensible (création/modification compte, escalade privilège) ;
  • tout incident sécurité de niveau P1 ou P2.

4. Signature GPG et horodatage

4.1 Clé GPG dédiée

Une clé GPG dédiée par tenant Client (RSA 4096 bits ou ed25519) est générée à l'onboarding. La clé privée est stockée dans un HSM (Hardware Security Module) dédié au niveau Sovereign, ou dans un KMS isolé pour Augment.

4.2 Signature des entrées

Chaque entrée du journal est signée individuellement (signature détachée) avec horodatage RFC 3161 fourni par une autorité de certification reconnue (LegalAct, Universign, Docusign Standards). La signature est jointe au JSONL dans un fichier compagnon decision_log.sig.

4.3 Double signature Sovereign

Pour les Clients Sovereign disposant d'un PKI interne, double signature Exior + Client, avec configuration définie au Bon de Commande.

4.4 Rotation des clés

  • Augment : rotation annuelle de la clé de signature, avec re-signature des entrées de l'année écoulée par chaînage cryptographique (Merkle tree).
  • Sovereign : rotation semestrielle, avec procédure équivalente.

4.5 Vérification d'intégrité

Vérification automatique en continu (toutes les 5 minutes pour Sovereign, toutes les heures pour Augment) :

  • vérification que chaque ligne porte une signature valide ;
  • vérification que le chaînage des hashs Merkle est intact ;
  • vérification que l'horodatage RFC 3161 est valide.

Toute anomalie est notifiée au Client < 30 minutes (Sovereign) ou < 1h (Augment).


5. Archivage et accès

5.1 Durée de rétention

| Niveau | Rétention minimale | |---|---| | Augment | 5 ans | | Sovereign | 10 ans (institutions bancaires standard) ou 15 ans (DORA, OIV) |

Voir docs/security/data_retention_policy.md.

5.2 Accès Client

Les administrateurs Augment et Sovereign accèdent en lecture à l'audit log via le dashboard ou par export (téléchargement chiffré). Les requêtes d'export sont elles-mêmes consignées (méta-audit).

5.3 Réplication SIEM Client

Pour Sovereign, réplication quasi-temps-réel des entrées sur le SIEM du Client (Splunk, Elastic SIEM, ArcSight, ou équivalent) via flux chiffré dédié.

5.4 Accès régulateur

Sur réquisition légale (ACPR, AMF, ANSSI, CNIL, autorité de tutelle Cliente, autorité judiciaire), Exior fournit l'export sous 5 jours ouvrés, accompagné des éléments de vérification cryptographique permettant à l'autorité de valider l'intégrité.


6. Valeur probante

L'audit log est conçu pour être admissible comme preuve technique au sens :

  • article 1366 Code civil — équivalence preuve écrite et signature électronique permettant d'identifier l'auteur et de garantir l'intégrité ;
  • article 1367 Code civil — signature électronique présumée fiable jusqu'à preuve contraire si conformité aux exigences eIDAS ;
  • règlement eIDAS (UE) 910/2014 — signature électronique qualifiée acceptable au niveau européen ;
  • instruction ACPR 2017-I-09 — preuve de contrôle anti-blanchiment ;
  • instruction AMF 2020-04 — preuve de contrôle cybersécurité ;
  • règlement DORA (UE) 2022/2554 article 17 — ICT incident reporting et preuve de gestion des risques ;
  • directive NIS2 (UE) 2022/2555 — preuve de conformité opérationnelle.

7. Limites

7.1 Pas de preuve de raisonnement humain

L'audit log ne saurait se substituer à la décision humaine du Client. Il atteste de ce que l'exocortex Exior a effectivement raisonné, recommandé ou exécuté, dans le respect des permits et des lignes rouges, mais la responsabilité de la décision finale revient au Client (cf. article 9 RGPD relatif aux décisions automatisées).

7.2 Périmètre

L'audit log couvre uniquement ce qui transite dans l'exocortex Exior. Il ne capture pas les décisions ou actions Client effectuées en dehors du Service.


8. Engagement de transparence

Exior s'engage à :

  • ne jamais altérer un log existant ;
  • documenter publiquement la procédure de vérification d'intégrité ;
  • publier la clé publique GPG correspondante sur un canal vérifiable (site exior.fr, keyservers Ubuntu/MIT) ;
  • coopérer avec tout audit tier extérieur sur l'intégrité du log.

9. Lien avec les lignes rouges (P7)

L'audit log enregistre toute tentative de franchissement des 4 lignes rouges Exior (KYC, paiement, premier contact éditorial, destruction externe irréversible — cf. docs/legal/lignes_rouges.md), même rejetée par les hooks safety. Cette traçabilité permet au Client de prouver, le cas échéant, qu'aucune ligne rouge n'a été franchie en son nom.


Fait à Paris, version 1.0 — 2026-04-28

EXIOR SAS — RCS Paris [NUMERO_RCS_A_COMPLETER]