Inaltérabilité des Données — NF525

Exigence NF525 : Les données de règlement enregistrées par le logiciel ne peuvent être modifiées après leur enregistrement définitif.

1. Mécanismes d'inaltérabilité

1.1 Chaîne de signatures cryptographiques

Chaque commande et chaque entrée du journal d'audit est signée individuellement via ECDSA-SHA256 et chaînée à l'enregistrement précédent (cf. 02_signature_chain.md).

Toute modification, suppression ou insertion d'un enregistrement rompt mécaniquement la chaîne et est détectée automatiquement par le système de vérification.

1.3 Inaltérabilité Structurelle (Schema-First)

Au-delà des données elles-mêmes, la structure des données fiscales est protégée par un mécanisme de "Source de Vérité" unique situé dans shared/schemas/. - Toute modification de la structure (ajout/suppression de champ fiscal) doit impérativement passer par le schéma central. - La génération automatique du code (Python/TypeScript) garantit qu'aucune règle métier divergente ne peut être introduite manuellement dans un des composants, supprimant le risque d'altération par erreur de développement.

1.2 Absence de fonctions de modification/suppression sur les données de caisse

Table	CREATE	READ	UPDATE	DELETE
orders	✅	✅	⚠️ (Status only)	❌
order_items	✅	✅	❌	❌
audit_logs	✅	✅	❌	❌

Les données fiscales (montants, lignes, signature) sont strictement immuables. Seul le statut de la commande (pending → paid) peut être mis à jour, et cette action génère systématiquement une entrée ORDER_PAID dans le journal d'audit. Aucune suppression n'est possible.

1.3 Annulation vs. Suppression

En cas d'annulation d'une commande : - La commande originale reste intacte dans la base de données - Une écriture d'annulation (ORDER_CANCELLED) est ajoutée au journal d'audit - L'annulation est elle-même signée et chaînée

Cela garantit la traçabilité complète de l'opération.

2. Vérification d'intégrité

2.1 Endpoint de vérification

GET /api/v1/audit/verify

Réponse en cas de chaîne intacte :

{
    "valid": true,
    "total_entries": 1523,
    "first_entry": "2026-01-01T00:00:00",
    "last_entry": "2026-02-16T10:49:53",
    "message": "Chaîne de signatures intacte"
}

Réponse en cas de rupture détectée :

{
    "valid": false,
    "total_entries": 1523,
    "broken_at": 847,
    "message": "Chaîne rompue à l'entrée #847 (ORDER_MODIFIED)"
}

2.2 Vérification automatique

La vérification peut être lancée : - Manuellement par l'administrateur via l'interface Admin - Automatiquement lors de chaque clôture journalière (Z de caisse) - Par un auditeur LNE via l'API directement

3. Protection contre les modifications base de données

Menace	Protection
Modification d'un montant	Chaîne de signatures rompue → détecté par /audit/verify
Suppression d'une commande	Chaîne de signatures rompue → gap dans la séquence
Insertion d'une fausse commande	Previous_signature incorrect → chaîne rompue
Modification du journal d'audit	Même protection par chaîne de signatures
Accès direct à la BDD	Clé privée ECDSA nécessaire pour recalculer les signatures